JEP 370 - text example leads to exception

[Maurizio Cimadamore]

Thanks Chris, both for catching the mistake and for testing out the 
feature - as you can imagine we'd like to collect as much feedback as 
possible to make sure the API gets finalized right.

Cheers
Maurizio

On 11/02/2020 02:12, Chris T wrote:
> Paul, thank you very much!
>
>    In the meantime I did more reading about VarHandles and understood better
> the "philosophy" of coordinates and it made sense (eventually I was able to
> fix my own issues).
>    Also, thank you for sharing Maurizio's talk - I will refer it in my
> examples. Speaking of sharing - these days I will finish my examples on JEP
> 370 and will share them with you as well (there will be a github + some
> youtube introduction to the feature).
>    I think that the capability to allocate more than 2GB of memory is going
> to be a hit!
>
> Cheers!
>    Chris T
>
> On Mon, Feb 10, 2020 at 12:58 PM Paul Sandoz <paul.sandoz at oracle.com> wrote:
>
>> Thanks for pointing out the inconsistencies.
>>
>> I modified the JEP with updated code snippets that compile against the
>> latest API in JDK 14 [*].
>>
>> The handle created “withStride” requires an additional coordinate the is
>> an offset from the base address.
>>
>> You may find Maurizio’s recent talk at Fosdem 2020 helpful and informative:
>>
>>    https://fosdem.org/2020/schedule/event/bytebuffers/
>>
>> Hth,
>> Paul.
>>
>> [*] I wish there was a way to automate the compile and test of such
>> snippets without duplication.
>>
>>
>> On Feb 7, 2020, at 7:23 PM, Chris T <tech.meshter at gmail.com> wrote:
>>
>> I tried to build an example on top of this code snippet (from the JEP
>> text):
>>
>> VarHandle intHandle = MemoryHandles.varHandle(int.class);
>> VarHandle intElemHandle = MemoryHandles.withStride(intHandle, 4);
>>
>> try (MemorySegment segment = MemorySegment.allocateNative(100)) {
>>    MemoryAddress base = segment.baseAddress();
>>    for (int i = 0 ; i < 25 ; i++) {
>>         intElemHandle.set(base, (long)i);
>>    }
>> }
>>
>> The first issue was that the API for the first line need to get the
>> ByteOrder parameter (that's not a big deal). I ended up with this:
>>
>>     VarHandle intHandle = MemoryHandles.varHandle(int.class, order);
>>     VarHandle intElemHandle = MemoryHandles.withStride(intHandle, 4);
>>
>>     try (MemorySegment segment = MemorySegment.allocateNative(100)) {
>>       MemoryAddress base = segment.baseAddress();
>>       for (int i = 0; i < 25; i++) {
>>         // this is the line where the app crashes:
>>         intElemHandle.set(base, (long) i);
>>       }
>>     }
>>
>> The issue that I have is that the code crashes with:
>> java.lang.invoke.WrongMethodTypeException: cannot convert
>> MethodHandle(VarHandle,MemoryAddressProxy,long,int)void to
>> (VarHandle,MemoryAddress,long)void
>> at
>>
>> java.base/java.lang.invoke.MethodHandle.asTypeUncached(MethodHandle.java:880)
>> at java.base/java.lang.invoke.MethodHandle.asType(MethodHandle.java:865)
>> at
>>
>> java.base/java.lang.invoke.VarHandleGuards.guard_LJ_V(VarHandleGuards.java:184)
>> at
>>
>> com.github.kbnt.java14.fma.ForeignMemoryAccessExamples.exampleXXStrides(ForeignMemoryAccessExamples.java:65)
>> at
>>
>> com.github.kbnt.java14.fma.ForeignMemoryAccessExamples.main(ForeignMemoryAccessExamples.java:25)
>>
>> Any idea why this happens (and more importantly how the code can be
>> changed)?
>>
>> Thanks!
>>   Chris T
>>
>>
>>