[foreign-memaccess+abi] RFR: 8315769: Add support for sliced allocation [v3]

[Maurizio Cimadamore]

On Wed, 6 Sep 2023 13:49:39 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> This PR adds a new method in `SegmentAllocator`:
>> 
>> 
>> default MemorySegment allocateFrom(ValueLayout elementLayout, MemorySegment source,
>>                                        ValueLayout sourceElementLayout, long sourceOffset, long srcElementCount) {
>> 
>> 
>> This method allows clients to allocate a new memory segment and copy the contents of a portion of an existing segment into the newly allocated region of memory. As such it can be used to address the following use cases:
>> 
>> * allocate from a `ByteBuffer`
>> * allocate from another memory segment
>> * allocate from a Java array slice
>> 
>> All these cases were not covered by the existing API points, which meant that developers had to use a more general allocation request (such as `allocate(long, long)`) and then pay a performance cost (because of memory zeroing). In other words, the new method in this PR completes the allocation API, by providing a flexible way to allocate a new segment from an existing source (another segment) with given offset and length.
>> 
>> Given that the new method is more general than the existing array-accepting `allocateFrom`, this PR rewires the existing array-accepting method to be rewritten on top of the new overload (and tweaks the javadoc of such methods accordingly).
>> 
>> One detail to note is that the new method takes _two_ element layouts - one is the layout of the newly allocated segment, whereas the other is the layout of the source segment. Such layouts must have same alignment and same carrier - but they can have different endianness (in which case a bulk copy with swap is performed). This is not too different from the most general `MemorySegment::copy` static overload.
>
> Maurizio Cimadamore has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Add `throws` clause re. hyper-aligned layouts
>  - Address review comments

src/java.base/share/classes/java/lang/foreign/SegmentAllocator.java line 324:

> 322:      * @param elements the short elements to be copied to the newly allocated memory block.
> 323:      * @return a segment for the newly allocated memory block.
> 324:      * @throws IllegalArgumentException if {@code elementLayout.byteAlignment() > elementLayout.byteSize()}.

I've added this to all the array-accepting allocateFrom, as I think this will be thrown by the underlying copy op. There are a lot of other exceptions that memory copy could throw, in the following conditions:
1. layout size * element count is too big
2. offset/elementCount < 0
3. the interval (offset, size) falls outside the spatial bounds of the segment
4. access occurs from a thread other than the thread owning segment
5. access occurs when segment scope is no longer alive
6. start of segment is not aligned according to provided layout

Now, I think 1-5 are impossible because:
1. number of bytes is always derived from an array size, no overflow is possible
2. default impl guarantees positive lengths/offsets
3. access is provably in bounds (from 0 to array size)
4. array segment can be accessed from any thread
5. array segment is always alive

As for (6), I think right now it can happen, but I think we should probably rectify the implementation of the array-accepting `allocateFrom` to pass `JAVA_SHORT`, `JAVA_CHAR`, ... as the "source layout element" rather than just passing a modified version of the input destination layout. If we do that, then access would be aligned by construction.

-------------

PR Review Comment: https://git.openjdk.org/panama-foreign/pull/878#discussion_r1317432836