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

[Ty Young]

On 3/18/20 6:02 AM, Maurizio Cimadamore wrote:
> 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.


There was also the issue of BLOCK_SIZE being 4KB. Allocating big chunks 
of memory like that might be good for performance if you actually use 
it, but otherwise seems like a waste.


>
> 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).


Right, final isn't possible here.


I'm not 100% sure it'll work out, but I just want to explore it a bit.


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


Yes, this works perfectly. Thank you.


Anything that I should be aware of when using stdlib directly by chance? 
malloc seems to work like any other function but as for the rest I don't 
know if there is any "gotchas" I need to know about.


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