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

[Maurizio Cimadamore]

On Mon, 16 Mar 2020 15:47:15 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>>> 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.
>
> /integrate

> If this is the intended purpose then it should, IMO, be changed to
> "BlockScope". "UnboundedAllocationScope" implies same-segment, dynamic
> allocation.

This thread is essentially a request for adding something that you asked already few weeks ago - adding support for
realloc. I've explained then why it's not a great idea, and how it doesn't fit into where we wanna go (other people
chimed in too, saying that you might be reading too much into what realloc does).

Anyway, this being Java, I find it funny that we have an interface, and we're arguing over whether the implementation
is desirable or not. The interface allows you to allocate multiple chunks of memory, making _no guarantees_ as to
whether the chunks will be allocated. What you are asking is _not_ just an implementation change. You want the
interface to make stronger guarantees about the fact that all the memory that will ever be returned by the scope will
be _contiguous_. That's not going to happen.

As for the name, an allocation scope just provides a 'scope' within which all allocation happens, so that you can close
everything at once. In the bounded case, you can come up with a block size ahead of time, hence the single segment. In
the unbounded case, we're doing what the old Panama/foreign scope was doing; which I think is fine enough for simple
use cases (which is what this interface is for).

If you want to support a realloc-based strategy on top of memory segment you would have to invalidate the existing
segments on each realloc call (because you don't know whether realloc has decided to just realloc, or to alloc + copy +
free, in which case old segments are just invalid).

Using stdlib is possible - in fact we have a test for it - maybe you should look there:

https://github.com/openjdk/panama-foreign/blob/686b4fafad1c198273b218f6df39deba5268d7da/test/jdk/java/foreign/StdLibTest.java

To get to the standard library you need LibraryLookup::ofDefault.

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

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