Separation between MemorySegment and MemoryScope

[Paul Sandoz]

The reduction in methods (a simplification) and that it’s easy to forget the scope where one is intended are persuasive arguments.

Paul. 

> On Mar 29, 2021, at 3:22 PM, forax at univ-mlv.fr wrote:
> 
> ----- 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