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

Thank you, Andrew I will file a separate bug to address this issue - Interpreter and compiled code should produce the same result! And I will push your changes today. Regards, Vladimir On 3/31/15 7:33 AM, Andrew Haley wrote: On 03/25/2015 09:13 AM, Andrew Haley wrote: On 24/03/15 23:40, Vla

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

On 03/25/2015 09:13 AM, Andrew Haley wrote: > On 24/03/15 23:40, Vladimir Kozlov wrote: > >> The test failed when run it in JPRT with 32-bit fastdebug *Client* VM >> (-client) on linux-x86: >> >> java.lang.RuntimeException >> at MyByteBuffer.ck(HeapByteBufferTest.java:201) >> at MyByteB

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

Looks like only 32-bit is affected. Both Server (C2) and Client (C1) VMs. 64-bit VM pass all combinations: Tiered, C2 only (-TieredCompilation), C1 only (-XX:+TieredCompilation -XX:TieredStopAtLevel=1) with and without intrinsics. 32-bit Client VM (C1) fails with both, -XX:-UseUnalignedAccess

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

On 24/03/15 23:40, Vladimir Kozlov wrote: > The test failed when run it in JPRT with 32-bit fastdebug *Client* VM > (-client) on linux-x86: > > java.lang.RuntimeException > at MyByteBuffer.ck(HeapByteBufferTest.java:201) > at MyByteBuffer.getLong(HeapByteBufferTest.java:211) >

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

On 25/03/2015 4:07 AM, Vladimir Kozlov wrote: Got it. I missed that you changed code in unsafe.cpp. Let me prepare closed changes and get it reviewed before we can push this. Copyright notices need updating too. And the copyright dates on the test look like they have been copied from another f

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

Andrew, The test failed when run it in JPRT with 32-bit fastdebug *Client* VM (-client) on linux-x86: java.lang.RuntimeException at MyByteBuffer.ck(HeapByteBufferTest.java:201) at MyByteBuffer.getLong(HeapByteBufferTest.java:211) at HeapByteBufferTest.step(HeapByteBuffer

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

Got it. I missed that you changed code in unsafe.cpp. Let me prepare closed changes and get it reviewed before we can push this. Thanks, Vladimir On 3/24/15 1:15 AM, Andrew Haley wrote: On 23/03/15 21:10, Vladimir Kozlov wrote: Hotspot make files changes? There's no need: I think we came to

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

On 23/03/15 21:10, Vladimir Kozlov wrote: > Hotspot make files changes? There's no need: I think we came to the conclusion that we wouldn't define BIG_ENDIAN. Andrew.

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

Hotspot make files changes? Otherwise looks fine. Vladimir On 3/23/15 11:31 AM, Andrew Haley wrote: On 03/21/2015 04:32 PM, Vladimir Kozlov wrote: On 3/21/15 4:36 AM, Andrew Haley wrote: On 20/03/15 22:00, Vladimir Kozlov wrote: On 3/20/15 9:08 AM, Andrew Haley wrote: Webrev at http://cr.

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

On 03/21/2015 04:32 PM, Vladimir Kozlov wrote: > On 3/21/15 4:36 AM, Andrew Haley wrote: >> On 20/03/15 22:00, Vladimir Kozlov wrote: >>> On 3/20/15 9:08 AM, Andrew Haley wrote: Webrev at http://cr.openjdk.java.net/~aph/unaligned.hotspot.7/ >>> >>> I don't see changes to VM's makefil

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

On 3/21/15 4:36 AM, Andrew Haley wrote: On 20/03/15 22:00, Vladimir Kozlov wrote: On 3/20/15 9:08 AM, Andrew Haley wrote: Webrev at http://cr.openjdk.java.net/~aph/unaligned.hotspot.7/ I don't see changes to VM's makefiles to set VM_BIG_ENDIAN. Or consider it is set if VM_LITTLE_ENDIAN is no

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

If you say so, John, I am okay with BE. Vladimir On 3/20/15 10:21 PM, John Rose wrote: I'm glad to see this coming along… The code, javadoc, and spec all look good. On Mar 20, 2015, at 3:00 PM, Vladimir Kozlov mailto:vladimir.koz...@oracle.com>> wrote: http://cr.openjdk.java.net/~aph/unali

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

On 20/03/15 22:00, Vladimir Kozlov wrote: > On 3/20/15 9:08 AM, Andrew Haley wrote: >> Webrev at >> >> http://cr.openjdk.java.net/~aph/unaligned.hotspot.7/ > > I don't see changes to VM's makefiles to set VM_BIG_ENDIAN. Or consider > it is set if VM_LITTLE_ENDIAN is not set in prims/unsafe.cpp co

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

I'm glad to see this coming along… The code, javadoc, and spec all look good. On Mar 20, 2015, at 3:00 PM, Vladimir Kozlov wrote: > >> http://cr.openjdk.java.net/~aph/unaligned.jdk.7/ >> > > My only comment for jdk change is to use bigEndian

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

On 3/20/15 9:08 AM, Andrew Haley wrote: Webrev at http://cr.openjdk.java.net/~aph/unaligned.hotspot.7/ I don't see changes to VM's makefiles to set VM_BIG_ENDIAN. Or consider it is set if VM_LITTLE_ENDIAN is not set in prims/unsafe.cpp code. In globals.hpp the empty line after flag descript

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

Webrev at http://cr.openjdk.java.net/~aph/unaligned.hotspot.7/ http://cr.openjdk.java.net/~aph/unaligned.jdk.7/ I've moved the test case into the hotspot repo The test case is diagnostic, not experimental Andrew.

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

On 19/03/2015 16:53, Vladimir Kozlov wrote: New code did not change API of existing X-Buffer methods. It changed only how they are implementation. And already existing nio/Buffer tests should test these methods already. Okay, although I've made a note to check the test coverage to see that the

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

New code did not change API of existing X-Buffer methods. It changed only how they are implementation. And already existing nio/Buffer tests should test these methods already. Regards, Vladimir On 3/19/15 9:33 AM, Alan Bateman wrote: On 19/03/2015 15:59, Vladimir Kozlov wrote: If you are ask

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

On 03/19/2015 04:43 PM, Andrew Haley wrote: > On 03/19/2015 04:33 PM, Alan Bateman wrote: >> On 19/03/2015 15:59, Vladimir Kozlov wrote: >>> If you are asking about HeapByteBufferTest.java test put it into: >>> >>> hotspot/test/compiler/intrinsics/unsafe/ >>> >>> Vladimir >> The existing tests for

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

On 03/19/2015 04:33 PM, Alan Bateman wrote: > On 19/03/2015 15:59, Vladimir Kozlov wrote: >> If you are asking about HeapByteBufferTest.java test put it into: >> >> hotspot/test/compiler/intrinsics/unsafe/ >> >> Vladimir > The existing tests for buffers are in jdk/test/java/nio/Buffer and would >

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

On 19/03/2015 15:59, Vladimir Kozlov wrote: If you are asking about HeapByteBufferTest.java test put it into: hotspot/test/compiler/intrinsics/unsafe/ Vladimir The existing tests for buffers are in jdk/test/java/nio/Buffer and would nice to have all the tests for this API together if possible.

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

If you are asking about HeapByteBufferTest.java test put it into: hotspot/test/compiler/intrinsics/unsafe/ Vladimir On 3/19/15 2:03 AM, Andrew Haley wrote: People, please. I have been working on this for weeks. All I am waiting on now is a decision about where the test case should go. Can I

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

Hi Andrew, Given no further advice, my inclination is move it to hotspot tests as i suspect the scope is at least as good, if not better. I agree we should not be blocked on this, so it's up to you :-) If left as is, we can/should revisit. Paul. On Mar 19, 2015, at 10:03 AM, Andrew Haley wro

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

People, please. I have been working on this for weeks. All I am waiting on now is a decision about where the test case should go. Can I have a decision so we can get this in? Thanks, Andrew.

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

On 03/17/2015 10:38 AM, Paul Sandoz wrote: > > On Mar 16, 2015, at 6:19 PM, Andrew Haley 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 i

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

On Mar 16, 2015, at 6:19 PM, Andrew Haley 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 >>

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

On 16/03/15 19:16, John Rose wrote: > On Mar 16, 2015, at 2:29 AM, Andrew Haley 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 Disable*

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

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

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

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: 8026049: (bf) Intrinsify ByteBuffer.put{Int, Double, Float, ...} methods

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

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: 8026049: (bf) Intrinsify ByteBuffer.put{Int, Double, Float, ...} methods

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

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

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

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

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

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

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

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

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

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

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: 8026049: (bf) Intrinsify ByteBuffer.put{Int, Double, Float, ...} methods

Andrew, 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. David On 14/03/2015 4:47 AM, Andrew Haley wrote: I've tried to addre

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

Hi Andrew, Looks good to me. Rémi On 03/13/2015 07:47 PM, Andrew Haley wrote: I've tried to address all the points that have been made. I haven't changed the way the sub-words are read and written because the code I'm seeing is fairly nearly optimal right now and anything more complex runs the

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

I've tried to address all the points that have been made. I haven't changed the way the sub-words are read and written because the code I'm seeing is fairly nearly optimal right now and anything more complex runs the risk of tripping inlining limits, thus pessimizing performance. We need a genera

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

I've tried to address all the points that have been made. I haven't changed the way the sub-words are read and written because the code I'm seeing is fairly nearly optimal right now and anything more complex runs the risk of tripping inlining limits, thus pessimizing performance. We need a genera