Re: RFR(XS): 8075071: [TEST_BUG] TimSortStackSize2.java: OOME: Java heap space: MaxHeap shrinked by MaxRAMFraction

2015-03-16 Thread David Holmes
Hi Lev, On 17/03/2015 6:30 AM, Lev Priima wrote: Please reviewand push: Issue:https://bugs.openjdk.java.net/browse/JDK-8075071 Patch: http://cr.openjdk.java.net/~lpriima/8075071/0/webrev/ Tested locally: jtreg -vmoptions:"-XX:MaxRAMFraction=9223372036854775807 -XX:-UseCompressedOops" test/java

Re: 8026049: (bf) Intrinsify ByteBuffer.put{Int, Double, Float, ...} methods

2015-03-16 Thread David Holmes
On 17/03/2015 5:16 AM, John Rose wrote: On Mar 16, 2015, at 2:29 AM, Andrew Haley wrote: On 16/03/15 00:40, David Holmes wrote: Experimental options are supposed to be opt-in only via UnlockExperimentalVMOptions. You presently have the experimental UseUnalignedAccesses being turned on uncondi

RFR JDK-8074678: JCK test api/java_util/regex/MatchResult/index.html starts failing after JDK-8071479

2015-03-16 Thread Xueming Shen
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 match" sanity check in ImmutableMatchResult. Thanks, -Sherman

Re: [9] RFR (S): 8075263: MHI::checkCustomized isn't eliminated for inlined MethodHandles

2015-03-16 Thread Vladimir Kozlov
Good. thanks, Vladimir K On 3/16/15 12:05 PM, John Rose wrote: Reviewed. — John On Mar 16, 2015, at 11:47 AM, Vladimir Ivanov wrote: http://cr.openjdk.java.net/~vlivanov/8075263/webrev.00/hotspot http://cr.openjdk.java.net/~vlivanov/8075263/webrev.00/jdk https://bugs.openjdk.java.net/brow

Re: [9] RFR of 8075222: RandomAccessFile.getChannel changed to non-final in error

2015-03-16 Thread Brian Burkhalter
On Mar 16, 2015, at 1:43 PM, Alan Bateman wrote: >> -public FileChannel getChannel() { >> +public final FileChannel getChannel() { >> > Looks fine, sorry we missed this when agreeing that patch. Sorry I missed it! Thanks, Brian

Re: [9] RFR of 8075222: RandomAccessFile.getChannel changed to non-final in error

2015-03-16 Thread Alan Bateman
On 16/03/2015 19:59, Brian Burkhalter wrote: Please review at your convenience. Issue: https://bugs.openjdk.java.net/browse/JDK-8075222 Diff: --- a/src/java.base/share/classes/java/io/RandomAccessFile.java +++ b/src/java.base/share/classes/java/io/RandomAccessFile.java @@ -276,7 +276,7 @@

RFR(XS): 8075071: [TEST_BUG] TimSortStackSize2.java: OOME: Java heap space: MaxHeap shrinked by MaxRAMFraction

2015-03-16 Thread Lev Priima
Please reviewand push: Issue:https://bugs.openjdk.java.net/browse/JDK-8075071 Patch: http://cr.openjdk.java.net/~lpriima/8075071/0/webrev/ Tested locally: jtreg -vmoptions:"-XX:MaxRAMFraction=9223372036854775807 -XX:-UseCompressedOops" test/java/util/Arrays/TimSortStackSize2.java Test results:

[9] RFR of 8075222: RandomAccessFile.getChannel changed to non-final in error

2015-03-16 Thread Brian Burkhalter
Please review at your convenience. Issue: https://bugs.openjdk.java.net/browse/JDK-8075222 Diff: --- a/src/java.base/share/classes/java/io/RandomAccessFile.java +++ b/src/java.base/share/classes/java/io/RandomAccessFile.java @@ -276,7 +276,7 @@ * @since 1.4 * @spec JSR-51 */ -

Re: RFR 8075230 Optimized count operations incorrectly declare the stream shape

2015-03-16 Thread Aggelos Biboudis
Sry, for the incorrect shapes. Thanks Paul! Aggelos. On Mon, Mar 16, 2015 at 4:04 PM, Paul Sandoz wrote: > Hi, > > This is a fix for a silly regression introduced with JDK-8067969 > (optimized count operations) that i should have caught in review. > > > http://cr.openjdk.java.net/~psandoz/jdk

Re: [9] RFR (S): 8075263: MHI::checkCustomized isn't eliminated for inlined MethodHandles

2015-03-16 Thread Vladimir Ivanov
Thanks, John! Best regards, Vladimir Ivanov On 3/16/15 10:05 PM, John Rose wrote: Reviewed. — John On Mar 16, 2015, at 11:47 AM, Vladimir Ivanov wrote: http://cr.openjdk.java.net/~vlivanov/8075263/webrev.00/hotspot http://cr.openjdk.java.net/~vlivanov/8075263/webrev.00/jdk https://bugs.op

Re: 8026049: (bf) Intrinsify ByteBuffer.put{Int, Double, Float, ...} methods

2015-03-16 Thread John Rose
On Mar 16, 2015, at 2:29 AM, Andrew Haley wrote: > > On 16/03/15 00:40, David Holmes wrote: >> Experimental options are supposed to be opt-in only via >> UnlockExperimentalVMOptions. You presently have the experimental >> UseUnalignedAccesses being turned on unconditionally on those >> archite

Re: [9] RFR (S): 8075263: MHI::checkCustomized isn't eliminated for inlined MethodHandles

2015-03-16 Thread John Rose
Reviewed. — John On Mar 16, 2015, at 11:47 AM, Vladimir Ivanov wrote: > > http://cr.openjdk.java.net/~vlivanov/8075263/webrev.00/hotspot > http://cr.openjdk.java.net/~vlivanov/8075263/webrev.00/jdk > https://bugs.openjdk.java.net/browse/JDK-8075263

[9] RFR (S): 8075263: MHI::checkCustomized isn't eliminated for inlined MethodHandles

2015-03-16 Thread Vladimir Ivanov
http://cr.openjdk.java.net/~vlivanov/8075263/webrev.00/hotspot http://cr.openjdk.java.net/~vlivanov/8075263/webrev.00/jdk https://bugs.openjdk.java.net/browse/JDK-8075263 When MethodHandle is a compile-time constant and it is inlined in MethodHandle.invoke/invokeExact there's no need in MHI::che

Re: 8026049: (bf) Intrinsify ByteBuffer.put{Int, Double, Float, ...} methods

2015-03-16 Thread Andrew Haley
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 > used instead. > > - I suspect that test needs to be located

Re: 8026049: (bf) Intrinsify ByteBuffer.put{Int, Double, Float, ...} methods

2015-03-16 Thread Andrew Haley
Hi, On 03/16/2015 12:43 PM, Peter Levart wrote: > On 03/16/2015 01:25 PM, Andrew Haley wrote: >> We need a flag which defaults to whatever is right for the platform >> (so it must be set in the back ends) but can be overridden by testing. >> What we have right now fits that requirement. I can see

Re: RFR 8075230 Optimized count operations incorrectly declare the stream shape

2015-03-16 Thread Chris Hegarty
On 16/03/15 14:04, Paul Sandoz wrote: Hi, This is a fix for a silly regression introduced with JDK-8067969 (optimized count operations) that i should have caught in review. I also missed it :-( http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8075230-count-prims-shape/webrev/ Looks fine

RFR 8075230 Optimized count operations incorrectly declare the stream shape

2015-03-16 Thread Paul Sandoz
Hi, This is a fix for a silly regression introduced with JDK-8067969 (optimized count operations) that i should have caught in review. http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8075230-count-prims-shape/webrev/ The count operations for int, long and double incorrectly declare a stream sha

Re: 8026049: (bf) Intrinsify ByteBuffer.put{Int, Double, Float, ...} methods

2015-03-16 Thread Peter Levart
On 03/16/2015 01:25 PM, Andrew Haley wrote: On 03/16/2015 11:36 AM, David Holmes wrote: On 16/03/2015 7:29 PM, Andrew Haley wrote: On 16/03/15 00:40, David Holmes wrote: Experimental options are supposed to be opt-in only via UnlockExperimentalVMOptions. You presently have the experimental Use

Re: 8026049: (bf) Intrinsify ByteBuffer.put{Int, Double, Float, ...} methods

2015-03-16 Thread Andrew Haley
On 03/16/2015 11:36 AM, David Holmes wrote: > On 16/03/2015 7:29 PM, Andrew Haley wrote: >> On 16/03/15 00:40, David Holmes wrote: >>> Experimental options are supposed to be opt-in only via >>> UnlockExperimentalVMOptions. You presently have the experimental >>> UseUnalignedAccesses being turned o

Re: Build error on sparc Re: 8026049: (bf) Intrinsify ByteBuffer.put{Int, Double, Float, ...} methods

2015-03-16 Thread Andrew Haley
On 03/16/2015 11:54 AM, Andrew Haley wrote: > On 03/16/2015 11:41 AM, David Holmes wrote: >> VM_BIG_ENDIAN does not exist in the sources. The only place it exists is in: >> >> ./bsd/makefiles/ppc.make:CFLAGS += -DVM_BIG_ENDIAN >> ./linux/makefiles/ppc.make:CFLAGS += -DVM_BIG_ENDIAN >> >> The expect

Re: Build error on sparc Re: 8026049: (bf) Intrinsify ByteBuffer.put{Int, Double, Float, ...} methods

2015-03-16 Thread Andrew Haley
On 03/16/2015 11:41 AM, David Holmes wrote: > VM_BIG_ENDIAN does not exist in the sources. The only place it exists is in: > > ./bsd/makefiles/ppc.make:CFLAGS += -DVM_BIG_ENDIAN > ./linux/makefiles/ppc.make:CFLAGS += -DVM_BIG_ENDIAN > > The expectation is that if VM_LITTLE_ENDIAN is not defined t

Re: Build error on sparc Re: 8026049: (bf) Intrinsify ByteBuffer.put{Int, Double, Float, ...} methods

2015-03-16 Thread David Holmes
On 16/03/2015 8:39 PM, Andrew Haley wrote: On 03/16/2015 10:30 AM, Paul Sandoz wrote: On Mar 16, 2015, at 11:03 AM, Paul Sandoz wrote: I am running this patch though our JPRT test system right now. I am getting a build error on spark: "... /hotspot/src/share/vm/prims/unsafe.cpp", line

Re: 8026049: (bf) Intrinsify ByteBuffer.put{Int, Double, Float, ...} methods

2015-03-16 Thread David Holmes
On 16/03/2015 7:29 PM, Andrew Haley wrote: On 16/03/15 00:40, David Holmes wrote: Experimental options are supposed to be opt-in only via UnlockExperimentalVMOptions. You presently have the experimental UseUnalignedAccesses being turned on unconditionally on those architectures that support it.

Re: Build error on sparc Re: 8026049: (bf) Intrinsify ByteBuffer.put{Int, Double, Float, ...} methods

2015-03-16 Thread Andrew Haley
On 03/16/2015 10:30 AM, Paul Sandoz wrote: > > On Mar 16, 2015, at 11:03 AM, Paul Sandoz wrote: > >> I am running this patch though our JPRT test system right now. >> > > I am getting a build error on spark: > > "... /hotspot/src/share/vm/prims/unsafe.cpp", line 335: Error: #error > VM_LITT

Build error on sparc Re: 8026049: (bf) Intrinsify ByteBuffer.put{Int, Double, Float, ...} methods

2015-03-16 Thread Paul Sandoz
On Mar 16, 2015, at 11:03 AM, Paul Sandoz wrote: > I am running this patch though our JPRT test system right now. > I am getting a build error on spark: "... /hotspot/src/share/vm/prims/unsafe.cpp", line 335: Error: #error VM_LITTLE_ENDIAN or VM_BIG_ENDIAN must be defined. The assumption

Re: 8026049: (bf) Intrinsify ByteBuffer.put{Int, Double, Float, ...} methods

2015-03-16 Thread Andrew Haley
On 16/03/15 10:03, 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 used instead. OK. > - I suspect that test needs to be located

Re: 8026049: (bf) Intrinsify ByteBuffer.put{Int, Double, Float, ...} methods

2015-03-16 Thread Paul Sandoz
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 used instead. - I suspect that test needs to be located in the hotspot test area, which likely means it gets run

Re: 8026049: (bf) Intrinsify ByteBuffer.put{Int, Double, Float, ...} methods

2015-03-16 Thread Andrew Haley
On 16/03/15 00:40, David Holmes wrote: > Experimental options are supposed to be opt-in only via > UnlockExperimentalVMOptions. You presently have the experimental > UseUnalignedAccesses being turned on unconditionally on those > architectures that support it. Well, it works. I guess this coul

Re: Unsafe.{get,put}-X-Unaligned performance

2015-03-16 Thread Andrew Haley
On 16/03/15 06:12, John Rose wrote: > BTW, I like Peter's suggestion to perform localized merging of > bytes to shorts (etc.) based on exact alignment. But, I'd rather > see it done further down the pipeline, after vectorization. That makes sense. Thanks, Andrew.