Re: RFR (14) 8235837: Memory access API refinements

2020-01-16 Thread Andrew Haley
On 1/16/20 2:51 PM, Maurizio Cimadamore wrote: > I think characterizing this specific instance as a case of "too late to > change anything" is a tad harsh. Sorry, I can be like that. :-) > The memory access API has been made available via an _incubating_ > module for precisely this reason - to

Re: RFR (14) 8235837: Memory access API refinements

2020-01-16 Thread Maurizio Cimadamore
Hi Andrew, I think characterizing this specific instance as a case of "too late to change anything" is a tad harsh. The memory access API has been made available via an _incubating_ module for precisely this reason - to make it more widely accessible, so that developers (like you!) could try

Re: RFR (14) 8235837: Memory access API refinements

2020-01-16 Thread Andrew Haley
On 1/15/20 6:48 PM, Maurizio Cimadamore wrote: > Maybe this would be best moved on panama-dev? OK, I'll do that, but this affects everyone. It's one of the difficulties of OpenJDK development that no-one sees the proposals of projects like this except on the dev list; by the time everyone else

Re: RFR (14) 8235837: Memory access API refinements

2020-01-16 Thread Andrew Haley
On 1/15/20 6:48 PM, Maurizio Cimadamore wrote: > That said, even w/o that performance fix, I wouldn't expect the memory > access API to be 4x slower. I'd start by dropping the acquire() [which > you probably don't need and it's doing a CAS], and moving to indexed var > handle (by replicating

Re: RFR (14) 8235837: Memory access API refinements

2020-01-15 Thread Maurizio Cimadamore
Maybe this would be best moved on panama-dev? In any case, for obtaining best performances, it is best to use an indexed (or strided) var handle - your loop will create a new memory address on each new iteration, which will not be a problem once MemoryAddress will be an inline type, but in

Re: RFR (14) 8235837: Memory access API refinements

2020-01-15 Thread Andrew Haley
On 1/9/20 4:37 PM, Maurizio Cimadamore wrote: > There you go > > cr.openjdk.java.net/~mcimadamore/8235837_javadoc Thank you. So I've been kicking the tyres, and I'm rather surprised at how poor the performance seems to be. My simple test, like this: @Benchmark public void

Re: RFR (14) 8235837: Memory access API refinements

2020-01-15 Thread Chris Hegarty
> On 14 Jan 2020, at 18:30, Maurizio Cimadamore > wrote: > > Another revision which addresses some additional CSR feedback: > > * SequenceLayout::withElementCount should throw if new element count < 0 > * MemoryLayout::hasSize should clarify that certain layout (e.g. ValueLayout) > always

Re: RFR (14) 8235837: Memory access API refinements

2020-01-14 Thread Paul Sandoz
+1 Paul. > On Jan 14, 2020, at 10:30 AM, Maurizio Cimadamore > wrote: > > Another revision which addresses some additional CSR feedback: > > * SequenceLayout::withElementCount should throw if new element count < 0 > * MemoryLayout::hasSize should clarify that certain layout (e.g. ValueLayout)

Re: RFR (14) 8235837: Memory access API refinements

2020-01-14 Thread Maurizio Cimadamore
Another revision which addresses some additional CSR feedback: * SequenceLayout::withElementCount should throw if new element count < 0 * MemoryLayout::hasSize should clarify that certain layout (e.g. ValueLayout) always have a size Webrev: http://cr.openjdk.java.net/~mcimadamore/8235837_v3

Re: RFR (14) 8235837: Memory access API refinements

2020-01-13 Thread Chris Hegarty
> On 9 Jan 2020, at 18:36, Maurizio Cimadamore > wrote: > > New revision: > > http://cr.openjdk.java.net/~mcimadamore/8235837_v2 > > delta from previous iteration: > > http://cr.openjdk.java.net/~mcimadamore/8235837_v2_delta > > javadoc > >

Re: RFR (14) 8235837: Memory access API refinements

2020-01-09 Thread Maurizio Cimadamore
New revision: http://cr.openjdk.java.net/~mcimadamore/8235837_v2 delta from previous iteration: http://cr.openjdk.java.net/~mcimadamore/8235837_v2_delta javadoc http://cr.openjdk.java.net/~mcimadamore/8235837_v2_javadoc specdiff

Re: RFR (14) 8235837: Memory access API refinements

2020-01-09 Thread Maurizio Cimadamore
On 09/01/2020 17:48, Chris Hegarty wrote: Maurizio, On 9 Jan 2020, at 14:36, Maurizio Cimadamore wrote: Hi, following the JEP 370 code review and CSR, certain comments that have not been addressed have been added to the tracker issue: https://bugs.openjdk.java.net/browse/JDK-8235837

Re: RFR (14) 8235837: Memory access API refinements

2020-01-09 Thread Chris Hegarty
Maurizio, > On 9 Jan 2020, at 14:36, Maurizio Cimadamore > wrote: > > Hi, > following the JEP 370 code review and CSR, certain comments that have not > been addressed have been added to the tracker issue: > > https://bugs.openjdk.java.net/browse/JDK-8235837 > > For further evaluation. After

Re: RFR (14) 8235837: Memory access API refinements

2020-01-09 Thread Maurizio Cimadamore
There you go cr.openjdk.java.net/~mcimadamore/8235837_javadoc Cheers Maurizio On 09/01/2020 15:36, Andrew Haley wrote: On 1/9/20 2:36 PM, Maurizio Cimadamore wrote: following the JEP 370 code review and CSR, certain comments that have not been addressed have been added to the tracker issue:

Re: RFR (14) 8235837: Memory access API refinements

2020-01-09 Thread Andrew Haley
On 1/9/20 2:36 PM, Maurizio Cimadamore wrote: > following the JEP 370 code review and CSR, certain comments that have > not been addressed have been added to the tracker issue: > > https://bugs.openjdk.java.net/browse/JDK-8235837 Where is the spec? I can't find it linked from anywhere --

RFR (14) 8235837: Memory access API refinements

2020-01-09 Thread Maurizio Cimadamore
Hi, following the JEP 370 code review and CSR, certain comments that have not been addressed have been added to the tracker issue: https://bugs.openjdk.java.net/browse/JDK-8235837 For further evaluation. After some discussion in the Panama channel (see [1] and [2]), the Panama team has come