ResourceScope attachment

[Maurizio Cimadamore]

This is a somewhat obscure corner of the API. Of course this is another 
thing that can be pruned, but let's talk about where it comes from first.

The main use case for this is native global variables.

A global variable is just an address. You can convert that address 
(unsafely) into a segment.

```
LibraryLookup lookup = ....
MemoryAddress address = lookup.lookup("errno").get().address();
MemorySegment errno = address.asSegmentRestricted(8, ...);
...
//dereference errno?
```

Now, LibraryLookup are auto-cleaned using GC. Meaning that when the last 
LibraryLookup pointing to a given library L goes unreachable, the 
library is unloaded. We could add support for scopes here, but we didn't 
do so (yet), so library unloading is implicit.

This means that a strong reference must be kept on that LibraryLookup: 
now, the javadoc says that the MemoryAddress generated by the library 
keep a strong reference to the lookup they come from.

But in the above we use the address to create a new segment, so that 
invisible link is gone. Creating a segment with a lookup attachment 
makes sure that the lookup is not unreachable prematurely, as the 
segment points to it.

I can imagine other similar circumstances where stuff like this might be 
handy.

As for native image, what you say is true, but if that was the case, 
we'd start running afoul of what reachability means. For instance, the 
ByteBuffer API implementation also uses attachment objects all over the 
place, so I'd have to assume that there has to be a way to say "I want 
to keep that field even if nobody uses it".

In other words, I think you touch on a valid question here, although I 
don't agree on the "why this is wrong" explanation you give.

What I could understand one of either:

1) the problem you are seeing with LibraryLookup is caused by the fact 
that, again, an implicit choice is made on scoping. Give users control 
of that scope parameter, and now you can know _exactly_ when the lookup 
is closed.
2) the problem is that the segment obtained by an address (obtained from 
a LibraryLookup) doesn't point automatically back to the lookup (e.g. 
users has to add reachability link on their own). This is error prone.

The reason I didn't go for (1), at least now, is that the library 
loading mechanism is quite complex - in the sense that it is possible to 
load the same library multiple times (e.g. using different 
classloaders). This is a difference from JNI, for instance.

This means we can only close a library when _all_ the library lookups 
associated with it have been closed (as a library can be used by 
multiple clients at the same time). So it's not sufficient to use a 
_single_ ResourceScope here, we need many.

Now, with ResourceScope we can probably set up a cleanup action which 
checks some atomic counter (per library) and unloads the library when 
the counter reaches zero. But it's not a slamdunk.

Maurizio


On 27/03/2021 12:16, Remi Forax wrote:

> I see ways to add an attachment when creating a scope
> (the ref Object in the MemoryScope implementation)
> but no way to get that object from the scope.
>
> I'm also wondering if theoretically a VM like native-image (the Substrate VM) can just not create the field "ref" since it's not used as an optimization ?
> You also have to be sure that nobody access this field by reflection but this is exactly the kind of information native-image is asking.
>
> Rémi