[foreign-abi] [Rev 01] RFR: 8241017: Enhance AllocationScope to support "unbounded" mode

[Maurizio Cimadamore]

On Mon, 16 Mar 2020 03:37:52 GMT, Athijegannathan Sundararajan <sundar at openjdk.org> wrote:

>> Maurizio Cimadamore has updated the pull request incrementally with three additional commits since the last revision:
>> 
>>  - Update src/jdk.incubator.foreign/share/classes/jdk/incubator/foreign/AllocationScope.java
>>    
>>    Co-Authored-By: Jorn Vernee <JornVernee at users.noreply.github.com>
>>  - Update src/jdk.incubator.foreign/share/classes/jdk/incubator/foreign/AllocationScope.java
>>    
>>    Co-Authored-By: Jorn Vernee <JornVernee at users.noreply.github.com>
>>  - Update src/jdk.incubator.foreign/share/classes/jdk/incubator/foreign/AllocationScope.java
>>    
>>    Co-Authored-By: Jorn Vernee <JornVernee at users.noreply.github.com>
>
> Looks good!

> I have some disagreements on the implementation. The expected behaviour,
> in my mind anyway, is that the returned MemoryAddress is *ALWAYS* just
> an offset of a larger, always same MemorySegment,

The goal of AllocationScope is to provide some extra aid to those clients who need to allocate multiple segments which
feature the same temporal bounds - e.g. so that they can be closed all at once. It gives you back an address to the
allocated memory. How it's implemented inside, it's well, an implementation detail, and I don't really see why a client
should assume certain behavior out of the addresses that it gets out of AllocationScope. Do you expect that all
addresses given back to you via malloc are consecutive? I hope not!

As for resizing a segment dynamically, I've said many times that the design centre for memory segment API is that to
have immutable segments, so that bound checks can be better optimized. If that's the constraint, then, in order to have
unbounded allocation, you have to allocate multiple segments and keep them in a list. Maybe we can do some tuning on
the threshold and make the impl smarter at reusing the memory, but this is mostly beyond the point - as this is not
supposed to be an highly efficient allocator - this is just supposed to be an help for clients building native
application - one thing that we found was pretty common for clients to do when we started porting more and more code
using the new bindings.

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

PR: https://git.openjdk.java.net/panama-foreign/pull/53