[foreign] RFR 8217414: Remove bounds check in BoundedPointer constructor

[Jorn Vernee]

There is a `checkAlive()` that gets called when a pointer is unboxed 
[1], I thought you were talking about that check. But, I don't think we 
should do a bounds check before passing a pointer to native code. The 
"one past the end of a container" pointer idiom is common and some APIs 
might expect to be passed such a pointer. It seems too restrictive to 
require that pointers passed to native code have to be in bounds (tbh I 
have my doubts about the liveliness check as well).

Jorn

[1] : 
http://hg.openjdk.java.net/panama/dev/file/tip/src/java.base/share/classes/jdk/internal/foreign/memory/BoundedPointer.java#l75

Maurizio Cimadamore schreef op 2019-01-21 13:56:
> I agree that the check should removed from the constructor - but we
> should make sure that checks happen when the pointer is used.
> Dereference is one situation, function call is another. I guess
> dereference is already covered (after all, a memory read will fail if
> outside the boundaries), but I don't think passing an out of bound
> pointer to a function is currently being checked, and it should if we
> remove the constructor eager check
> 
> Maurizio
> 
> On 21/01/2019 12:00, Jorn Vernee wrote:
>> Hi,
>> 
>> I have a patch addressing 2 vacuously passing tests (api/PointerTest 
>> and api/ArrayTest). The patch fixes the tests, and to make that happen 
>> removes the bounds check in BoundedPointer's constructor. As discussed 
>> offline; this check is not needed since we already de a check when 
>> dereferencing a pointer in BoundedMemoryRegion, and the check in the 
>> constructor is overly restrictive since it should be fine to create 
>> out-of-bounds pointers as long as it is not dereferenced. This does 
>> mean the tests needed to be tweaked since now an access exception is 
>> throw at a later point.
>> 
>> Please review the following.
>> 
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8217414
>> Webrev: 
>> http://cr.openjdk.java.net/~jvernee/panama/webrevs/8217414/webrev.00
>> 
>> Thanks,
>> Jorn