Separation between MemorySegment and MemoryScope

[Paul Sandoz]

Our GC’s are getting better and better. The Java approach is a developer should not, in general, have to manage memory: let the GC do it. My view is if we can apply that default to Panama we all win in the long run. I suspect it will make API design easier to when building on top of Panama.

Still, there will always be the need for more advanced use-cases, and Panama caters for that too. 

I am still intrigued by whether there is any advantage to a GC being taught that a small managed object refers to, and manages via cleaner, a larger allocated region of native memory.

Paul.

> On Mar 29, 2021, at 2:47 AM, Maurizio Cimadamore <Maurizio.Cimadamore at Oracle.COM> wrote:
> 
> Some of the consideration (see below) are correct John, but here the choice is not between the choice you picture - e.g. "safe-but-slow vs. fast-but-unsafe".
> 
> If you construct a memory segment, w/ or w/o explicit parameters, you always get a safe memory segment, and actually, unless I'm mistaken, the speed won't really change by much (I believe they all perform the same now).
> 
> The choice here is whether to make implicit GC allocation the default or not (the current API says yes, partly out of a desire to offer ByteBuffer users a relatively gentle ramp).
> 
> But, I must stress, whether you chose one or the other _the segment you get back is still safe_.
> 
>> So, make it explicit.
> 
> I might agree with this, and what Remi proposed earlier, but for more pragmatic reasons: when using the API, I found that the current API makes it perhaps a little too easy for the user to "forget" about the scope argument - example:
> 
> ```
> try (ResourceScope scope = ResourceScope.ofConfined()) {
>    // ok I have a scope here
>    MemorySegment segment = MemorySegment.allocateNative(100); // bug??
>    ...
> }
> ```
> 
> The call to MemorySegment::allocateNative is missing the scope parameter which, because of the overloads, is effectively an optional parameter. This might mean that developer might sometime get GC deallocation semantics "accidentally" (it happened to me on a couple of tests and jextract samples, so I have to conclude that this can happen to other folks too).
> 
> To me, that is the most compelling argument in favor of removing the default: e.g. extra overload don't buy you that much (e.g. you can have a  more aptly named `gcScope` factory which gives you the current default), and it introduces potential for mistakes. Since the cost for going explicit here is fairly low, I can see the argument.
> 
> Maurizio
> 
> 
>