Separation between MemorySegment and MemoryScope

[Maurizio Cimadamore]

Noted. (I've expanded a bit more on the "whys" in a separate email).

What you say is defensible, and is where we started from. The only thing 
I noted, after using the new API a bit is that the default "invite" 
mistakes (by allowing you to "forget" about the scope parameter).

I don't know how much of a problem that is, but it did happened a couple 
of times.

Overall, I think the default has to be justified in terms of usages - 
e.g. is a use case so overwhelmingly common that it deserves some kind 
of "shortcut" ? My feeling is that, with the Foreign API, things are 
probably even - e.g. 50/50 or 60/40 (in either direction) split between 
implicit and explicit deallocation, depending on cases. I don't think 
one case clearly dominates the other, for several reasons.

So, given that the work around (just pass the "gcScope()" to the method) 
is cheap, and that there doesn't seem to be a case of "clear default" 
here (e.g. 80/20), I think the argument in favor of removing the 
"default" overloads is strong-ish. This is also a similar reasoning we 
followed with the scope -> allocator conversion, where we opted for 
simplicity, explicit-ness and composition over convenience.

In other words, I think having these overloads, and calling the gc scope 
"default" scope largely plays into a long-term story where we think the 
GC will be able to cater for most use cases (so, in 10 years users will 
look at the API and will say "of course!"). But - see my other email - 
I'm not convinced we will ever land in a place where implicit scopes are 
a "clear default" - especially when it comes to interacting with native 
libraries (I could agree if we were only talking about foreign memory 
access).

Maurizio

On 29/03/2021 22:07, Paul Sandoz wrote:
> I conveyed more than intended! I was attempting to express support for the current behavior e.g.:
>
> ResourceScope.ofDefault()
> MemorySegment.allocateNative(long bytesSize);
> etc.
>
> Which is what I meant by "apply that default to Panama”.
>
> Paul.
>
>> On Mar 29, 2021, at 1:52 PM, Maurizio Cimadamore <Maurizio.Cimadamore at Oracle.COM> wrote:
>>
>>
>> On 29/03/2021 20:16, Paul Sandoz wrote:
>>> 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.
>> While I don't necessarily disagree, in the world, as it is now, GC is not enough (which is the whole point for doing scopes in the first place).
>>
>> If we ever get to a place where GCs will be smarter, such no-arg overload can be added later, if needs be (not saying they should - just pointing out the possibility).
>>
>> Maurizio
>>
>>> 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
>>>>
>>>>
>>>>