scopes writeup

[Maurizio Cimadamore]

On 23/01/2019 01:03, Samuel Audet wrote:
> Hi, Maurizio,
>
> I see there is an "interface Resource", but it doesn't allow us to 
> provide custom allocators and deallocators. How could we, for example, 
> manage all resources including those that are not pointers, structs, 
> etc with a single Scope? Do we need to provide a new implementation of 
> Scope for each type of Resource?

In the current proposal, the only kind of resources available are coming 
directly from Scope, so Scope knows how to clean them up. Note also that 
the name 'Scope' is too general, and will probably be changed to 
something more specific like MemoryScope (to align with what's done in 
other projects - see Loom's FiberScope).

In the future (provided we have concrete use cases for it) we can evolve 
the Scope API to cater for custom deallocation strategies - not sure if 
the custom deallocation goes in Resource - probably should be passed as 
a lambda when you call Scope::allocateXYZ.

But in any case, as mentioned in the email, this proposal starts (very) 
simple, we can add to it as use cases pop up.

Maurizio

>
> Samuel
>
> On 1/23/19 1:27 AM, 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 
>>
>>
>