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

[Henry Jen]

> On Aug 28, 2019, at 3:29 AM, Maurizio Cimadamore <maurizio.cimadamore at oracle.com> wrote:
> 
> Hi,
> the concerns you raise are fair.
> 
> In general pointers have two kinds of extra info attached onto them:
> 
> * a scope, which gives details about _when_ a pointer can be used
> 
> * a boundary, which gives details about how big the pointed memory region actually is
> 
> When you allocate a pointer from a scope you have all the info. You know the scope (since you had to use a scope to obtain a pointer in the first place). And you know boundaries (e.g. from a LayoutType).
> 
> But when a pointer is allocated from the binder because of (a) a native call or (b) a struct access, things get a bit harder. Even leaving aside the scope problem at the moment, you don't really know if a Pointer<Byte> is really a pointer to one byte, or (more likely) a pointer to a region containing an unspecified amount of bytes. While layouts could help here, very often the C APIs layouts are derived from are ambiguous on this point. Which means that when we retrieve a pointer from native code, or from a struct, we don't really know much about size info either. Hence the Pointer::limit API, which turns an 'infinite' pointer into a finite size one (provided the programmer knows about its size).
> 
> I think what you are really saying here is that temporal info should work in a similar way - e.g. you get an opaque pointer from some struct access/native API and you should be able to superimpose your own liveness. I think that's a fair point, and, as pointed out above, closely follows the pattern we've been using for managing size info.
> 
> So, I think it's fair to say that Pointer should have two 'limit' methods:
> 
> limit(long) -> specify new length
> 
> limit(Scope) -> specify new scope
> 
> in both cases the new constraint has to be stricter than the old one - that is, new size has to be smaller, and new scope has to be shorter-lived.
> 
> Of course, an unchecked pointer typically has infinite size and infinite scope, so that means you can always "narrow" it down as needed.
> 

I think that works too. I have no intention to make this operation feels like hand-over or pass-down, that is to allow it to be from one scope to another. The condition is more strict that only a Pointer with unknown/unchecked/null scope can be associated with a new one that developer is certain, thus the name assertScope. :)

One thing is not very clear to me is that if close a scope means all pointers in that scope is “released” or simply “not accessible”. I am assuming the later, as I believe the guideline should always be whoever allocates the resource is responsible to release it unless it is explicitly “hand-over” to another. So the scope should free all memory allocated by itself upon close, but not necessary all Pointers associated with the scope will be freed, but rather “not accessible”, then pass-down as you mentioned could work.

> 
> I also agree with your point that you should not be able to allocate from an unchecked scope - that said, I guess I don't follow why you'd want to make the UNCHECKED scope publicly accessible?
> 

Sometimes we need to test if a Pointer is unchecked. Just like we need to check if a Pointer is nullPointer. We either added a method, or need to provide an instance to compare with.

We can use null if spec that way, but I am not sure if we want to use a special implementation of Scope instead of null to be UNCHECKED.

Cheers,
Henry


> Maurizio
> 
> 
> On 20/08/2019 19:58, Henry Jen wrote:
>> Hi,
>> 
>> Please review a webrev[1] that change the scope of dereferenced Pointer to unchecked instead of using the scope of containing Pointer.
>> 
>> A Pointer to a pointer is storing the address of target pointer in the containing Pointer, where the scope is not necessary related. A Pointer instance with address allocated from Java land will have a Scope, but an address obtained from the native code doesn’t(as the runtime would not know, only developer can know).
>> 
>> In cases where a Java allocated Pointer was send to native side and receive back, it’s possible to implement some scope inference to maintaining a table(limited or complete) for Pointers passed into native side. Otherwise, when a Pointer is used only on Java side, the scope is always there.
>> 
>> This webrev does not implement a scope inference mechanism, but rather provide an API for developer to explicitly assign a Scope that developer believe the Pointer should have if the Pointer doesn’t have one already.
>> 
>> This webrev also move the UNCHECKED into Scope, and use null value for now. I believe UNCHECKED scope should be different from global scope as it should be very limited and not allowing any allocation from it. Basically, an Pointer with UNCHECKED scope is just an address.
>> 
>> Thoughts?
>> 
>> Cheers,
>> Henry
>> 
>> [1] http://cr.openjdk.java.net/~henryjen/panama/8229857/0/webrev