Separation between MemorySegment and MemoryScope

[forax at univ-mlv.fr]

----- Mail original -----
> De: "Maurizio Cimadamore" <maurizio.cimadamore at oracle.com>
> À: "Paul Sandoz" <paul.sandoz at oracle.com>
> Cc: "John Rose" <john.r.rose at oracle.com>, "Remi Forax" <forax at univ-mlv.fr>, "panama-dev at openjdk.java.net'"
> <panama-dev at openjdk.java.net>
> Envoyé: Lundi 29 Mars 2021 23:26:28
> Objet: Re: Separation between MemorySegment and MemoryScope

> 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.

It happens to me too, and it takes me some time to find it because the native segment was allocated inside a try(scope) so it tricks my brain to think that it was somehow acquires using that scope
(exactly the example you have given below).

> 
> 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

Rémi

> 
> 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
>>>>>
>>>>>