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

[Maurizio Cimadamore]

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

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