[foreign-memaccess] RFR 8227394: Add MemorySegment::asByteBuffer convenience method

[Maurizio Cimadamore]

Hi Jorn,
I gave some thought about this in the past, and my conclusion was mixed 
- and I filed this in the "you ain't gonna need it" bucket (YAGNI).

The motivations are that (i) it is really simple to emulate the API with 
the existing methods (as the implementation of the new method shows), 
and that (ii) the new API is, by necessity, a partial API - not all 
segments can be mapped onto a byte buffer - some are too large; while 
the existing API on memory address is total (thanks to the explicit int 
parameter).

In other words, the existing API on MemoryAddress supports what I 
believe to be the most important interop idiom: slicing a big memory 
segment into multiple < 32bits buffer views. I'm less convinced on the 
usefulness of turning an entire memory segment into a bytebuffer: if you 
really wanted to view the entire memory segment as a BB, maybe you just 
wanted to create a (direct) BB in the first place?

The current model is kind of easy to explain - the moves we allow are:

* ByteBuffer -> MemorySegment

* MemoryAddress + int -> ByteBuffer

This feels minimal. If we add another dimension, as per your patch:

* MemorySegment -> ByteBuffer

Then the next question is - should we allow also:

* ByteBuffer -> MemoryAddress? (e.g. create a big segment from the byte 
buffer and then have a memory address point at the BB offset)

Which feels a bit like a slippery slope. I'd be more confident in adding 
a facility like this after some real world validation.

What do you think?

Maurizio

On 11/07/2019 12:28, Jorn Vernee wrote:
> Hi,
>
> Please review this small patch that adds an asByteBuffer convenience 
> method to MemorySegment that returns a buffer the size of the segment.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8227394
> Webrev: 
> http://cr.openjdk.java.net/~jvernee/panama/webrevs/8227394/webrev.00/
>
> (note that the javadoc is largely taken from 
> MemoryAddress::asByteBuffer).
>
> My reason for adding this is that I wanted to reach for this method a 
> few times when playing with the API, but it didn't exist. So, I 
> thought it would be useful to have.
>
> (Also, I originally wanted to upload this to GitHub [1] to test out 
> the Skara [2] tools, but apparently that's not operational yet :) )
>
> Thanks,
> Jorn
>
> [1] : https://github.com/openjdk/panama/pull/1
> [2] : https://github.com/openjdk/skara#openjdk-project-skara