[foreign] RFR: 8229857: scope inference on pointer to pointer is not friendly

[Henry Jen]

> On Aug 28, 2019, at 10:23 AM, Maurizio Cimadamore <maurizio.cimadamore at oracle.com> wrote:
> 
> 
>> That said, I think I'd like to learn more about the problem you faced, with some real code. The idea of scope inference is really tied to how close/merge work - and the fact that the runtime checks for the ancestor relationship when you store a pointer into another memory region (to check that the liveness range of the stored pointer outlives the containing pointer).
>> 
> I see such an example here:
> 
> https://bugs.openjdk.java.net/browse/JDK-8229857
> 
> thanks for taking the time to write such a detailed issue.
> 

Glad it explains the issue well enough, that’s what I would expect from a bug report.
 
> So, from what I see the problem here is that you create a 'local' array which contains some values that should be made available more globally.
> 

The content at the pointer is belong to the scope, that’s reasonable. But the content, the address of the dereferenced Pointer, maybe completely irrelevant to the scope of the output Pointer. So the inference is not working. For example,

Scope a = globalScope().fork();
Pointer<Byte> ptr = a.allocate();
try (Scope stack = globalScope().fork) {
	// Struct is a struct with a pointer field
	Struct struct = stack.allocateStruct(Struct);
	struct.ptr$set(ptr);
	a.close();
	Pointer<Byte> p2 = struct.ptr$get()
}

Of course this is silly code, but that just simulate something we pass down to native and come back. As you can see inference is still not helping here at all. My pointe is, inference need to have basis to have merit.

> In other words, the program is not behaving according to the desired ownership model. The ownership model is strict but also prevents mistakes. So it's a constant trade off.
> 
> In this case I see two options:
> 
> 1) use a global scope for the allocation of the temp array
> 

As I pointed out in the bug report, this is just causing leak for buffer we don’t need to keep.

> 2) keep using a local scope, but then copy the contents to pointers that are allocated outside
> 

My first edition is implementing this, something like have Pointer.unchecked(Pointer) to instantiated a Pointer in UNCHECKED scope.

> In other words, now that I look more closely at the problem you are trying to solve, it's not like scope inference is misbehaving and need to be fixed - you are essentially saying: I don't need protection (at least in case of pointers created in a native lib - although that automatically extends to pointers generated from struct reads), I just want pointers to be freely assignable.
> 
> Do we agree on the description of the issue here? Then we can talk on how to fix it.

+1. Let’s figure out how to fix this.

Cheers,
Henry