[foreign-abi] RFR 8237899: Add support for scoped allocation

[Jorn Vernee]

Looks good.

Minor nits:
- in AllocationScope::allocate(long, long), you could replace `sp += 
(start - sp) + bytesSize;` with just `sp = start  + bytesSize;`.
- in the test you have `assertTrue(!address.segment().isAlive());` but 
could also use `assertFalse` and drop the negation.

Cheers,
Jorn

On 27/01/2020 20:14, Maurizio Cimadamore wrote:
> Hi,
> after having programmed a quite a bit with both the old and new 
> jextract bindings, I noted a mismatch (which was recently pointed out 
> by Michael too); in C local variables are just... variables allocated 
> on stack. If you need a pointer to them, you can just use C's 
> dereference operator (&) and be done.
>
> In Panama-ized code, going from a regular variable (e.g. an int) to a 
> variable that can be dereferenced (e.g. a MemoryAddress containing an 
> int) is quite convoluted - and involves creating a segment and filling 
> its contents with the desired value (in the old API, we could use 
> Pointer - but same story holds). Even worse, the Panama model forces a 
> malloc for each variable, where in the C code all such variables are 
> stack-allocated at basically zero cost.
>
> On top of the performance issue, there's also a usability issue, in 
> that the user is responsible for manually cleaning up all such 
> variable segments at the end of the method.
>
> The solution is to build a so called AllocationScope on top of a 
> segment, of fixed size, which makes a single upfront allocation 
> request (using malloc, for now) and then keeps returning slices from 
> that same segment. The allocation scope makes use of the acquire() 
> API, to make sure that returned segments cannot be closed by the user 
> - deallocation happens when the entire allocation scope is closed.
>
> A number of overloads allows to support the allocate/initialize 
> pattern so that a new int variable can be created as follows:
>
> scope.allocate(C_INT, 42)
>
> This relatively simple API massively simplifies the task of turning C 
> code into Panama code, at least in the examples I've come across, and 
> should help reducing allocation bottlenecks too (although we should do 
> more investigation as to whether something better than malloc/free can 
> be used here).
>
> Webrev:
>
> http://cr.openjdk.java.net/~mcimadamore/panama/8237899/
>
> Maurizio
>
>
>