This RFR proposes to remove the duplicate FDTest from “jdk” repo.
FDTest exists in both “jdk” and “langtools”:
http://hg.openjdk.java.net/jdk9/dev/jdk/file/tip/test/jdk/lambda/FDTest.java
On 16/03/15 19:16, John Rose wrote:
On Mar 16, 2015, at 2:29 AM, Andrew Haley a...@redhat.com wrote:
Since the option provides control for product behavior, without an explicit
opt-in, it should either be a product flag or a diagnostic flag.
I suggest keeping the more direct name (Use* not
On Mar 16, 2015, at 11:00 PM, Xueming Shen xueming.s...@oracle.com wrote:
Please help review the change for
issue: https://bugs.openjdk.java.net/browse/JDK-8074678
webrev: http://cr.openjdk.java.net/~sherman/8074678
The proposed fix is to implement the same whether or not there
is a
Peter, Alan,
After further thought I think that requiring all final fields to be set is
reasonable behaviour. Since there is no compile time checking, this is a
reasonable runtime effort to catch what is likely to be developer errors. To
address Alan’s comments, I beefed up the API docs and
On 17/03/2015 09:57, Chris Hegarty wrote:
Peter, Alan,
After further thought I think that requiring all final fields to be
set is reasonable behaviour. Since there is no compile time checking,
this is a reasonable runtime effort to catch what is likely to be
developer errors. To address
On Mar 16, 2015, at 6:19 PM, Andrew Haley a...@redhat.com wrote:
On 03/16/2015 10:03 AM, Paul Sandoz wrote:
I am running this patch though our JPRT test system right now.
The test looks good, two comments on it:
- IMO it does not need the internal PRNG FastRandom, SplittableRandom can be
Hi Lev,
On 18/03/2015 9:07 AM, Lev Priima wrote:
Possible, by determining of disabled UseCompressedOops option and
forking vm again with required minimum heap value(-Xms).
Please review update: http://cr.openjdk.java.net/~lpriima/8075071/1/webrev/
Yes that is the approach that is needed. But
Possible, by determining of disabled UseCompressedOops option and
forking vm again with required minimum heap value(-Xms).
Please review update: http://cr.openjdk.java.net/~lpriima/8075071/1/webrev/
Lev
On 03/17/2015 03:23 PM, David Holmes wrote:
So this is a problem that needs to be resolved.
Follow-on to correct some insufficiencies pointed out in
http://mail.openjdk.java.net/pipermail/core-libs-dev/2015-March/032289.html
Please review at your convenience.
Issue: https://bugs.openjdk.java.net/browse/JDK-8075362
Diff: See below (Properties.java change did not show up in
Hi David,
Explicit -Xmx does not allow explicit MaxRAMFraction to shrink
MaxHeapSize down to -Xms(or even less down to default InitialHeapSize in
case if -Xms also wasn't set explicitly). In other words explicit -Xmx
has priority over explicit MaxRAMFraction if both are set and contradict
On 03/17/2015 11:39 AM, Alan Bateman wrote:
On 17/03/2015 09:57, Chris Hegarty wrote:
Peter, Alan,
After further thought I think that requiring all final fields to be
set is reasonable behaviour. Since there is no compile time checking,
this is a reasonable runtime effort to catch what is
On 17/03/2015 9:15 PM, Lev Priima wrote:
Hi David,
Explicit -Xmx does not allow explicit MaxRAMFraction to shrink
MaxHeapSize down to -Xms(or even less down to default InitialHeapSize in
case if -Xms also wasn't set explicitly). In other words explicit -Xmx
has priority over explicit
On 03/17/2015 10:57 AM, Chris Hegarty wrote:
Peter, Alan,
After further thought I think that requiring all final fields to be set is
reasonable behaviour. Since there is no compile time checking, this is a
reasonable runtime effort to catch what is likely to be developer errors. To
address
Yes.
Lev
On 03/17/2015 02:56 PM, David Holmes wrote:
On 17/03/2015 9:15 PM, Lev Priima wrote:
Hi David,
Explicit -Xmx does not allow explicit MaxRAMFraction to shrink
MaxHeapSize down to -Xms(or even less down to default InitialHeapSize in
case if -Xms also wasn't set explicitly). In other
So this is a problem that needs to be resolved. The memory requirements
of the test are platform dependent but can't be satisfied on all
platforms. Though I am surprised that 770M is needed given that two
incarnations ago we set -Xmx to 385M!
But it is appearing to be impossible to run this
On 17/03/2015 12:21, Peter Levart wrote:
Hi Alan,
I agree that not calling defaultReadObject() from readObject() and
having a final field is potentially a bug. But need not be in case
some other means of setting final fields was used (Unsafe or
reflection). Some readObject() implementations
On 03/17/2015 10:38 AM, Paul Sandoz wrote:
On Mar 16, 2015, at 6:19 PM, Andrew Haley a...@redhat.com wrote:
On 03/16/2015 10:03 AM, Paul Sandoz wrote:
I am running this patch though our JPRT test system right now.
The test looks good, two comments on it:
- IMO it does not need the
17 matches
Mail list logo
