scopes writeup

[Maurizio Cimadamore]

Slightly updated webrev:

http://cr.openjdk.java.net/~mcimadamore/panama/scope-ownership_v3/

I realized that the library scope was incorrect - in the sense that it 
was a 'static' scope shared across all instances of a given library 
class. To rectify this required some major surgery to HeaderImplGenerator.

The second thing this patch does is it removes the (odd) requirement for 
@NativeHeader interface to extend from Scope.Resource (just to be able 
to get a scope out of them). Libraries are not resources, they might 
*use* resources, but that's a different matter.

To expose library scopes to client I opted for a simple helper method on 
the Libraries class:

Libraries::libraryScope(Object o)

That is, you pass the library instance to the static method and it gives 
you the scope object associated with that library back. I think this is 
a decent trade-off.

Maurizio

On 22/01/2019 16:27, Maurizio Cimadamore wrote:
> Hi,
> at the end of last year I tried coming up with a proposal [1] which 
> aimed at finding the basic concepts behind Panama scopes - I've been 
> iterating (with the help of some internal feedback) on that proposal, 
> and put it back together in a different form which, all things 
> considered, it's not too far off from where we are now.
>
> https://cr.openjdk.java.net/~mcimadamore/panama/scopes.html
>
> That is, we still have a Scope abstraction - memory regions are still 
> hidden under Scopes, and not part of the public API (in an attempt to 
> limit the number of concepts exposed by the API - at least for now). 
> Pointer is an immutable cursor into a memory region. Resources are 
> just things with a scope (turns out, a native library is another such 
> thing, since a native library needs a library-wide scope for 
> allocating its own globals, etc.).
>
> On top of what we have now, this writeup pushes forward an improved 
> ownership model, as well as some discussions concerning 
> thread-confinement of scopes.
>
> I think this tweaked API proposal has the potential of fixing the 
> current lifecycle issues, w/o making the API too complex to use. 
> Additional abstraction (such as MemoryRegion) can be added back to the 
> public API on a by need basis (e.g. provided relevant use cases).
>
> An experimental patch implementing the proposed approach can be found 
> here:
>
> http://cr.openjdk.java.net/~mcimadamore/panama/scope-ownership_v2/
>
> Comments welcome!
>
> Maurizio
>
> [1] - 
> https://mail.openjdk.java.net/pipermail/panama-dev/2018-December/003605.html
>