[foreign] Handling pointers with special (negative) values

Maurizio Cimadamore maurizio.cimadamore at oracle.com
Thu Oct 25 16:03:27 UTC 2018


All good points raised here.

I think I'm with Florian: the check is incorrect, or at least partially 
so. Let me explain what I mean by that; Unsafe uses two different kind 
of addressing mode, as documented here:

http://hg.openjdk.java.net/jdk/jdk/file/9c260a6b6471/src/java.base/share/classes/jdk/internal/misc/Unsafe.java#l129

If the 'base' object is set, then the long becomes a (positive) offset. 
But if there's no 'base' object, then the long argument is simply an 
absolute address, which can be anything.

So, I think it could be fine to enforce that the offset is positive, but 
only if the underlying memory region has a non-null base.

Thoughts?

Maurizio


On 25/10/2018 04:27, Jorn Vernee wrote:
> Florian Weimer schreef op 2018-10-25 13:06:
>> Isn't the check simply incorrect?  I was under the impression that
>> Solaris has userspace pointers in the upper region of the address space
>> on x86-64 (i.e, where the 17 or so most significant bits are set).
>
> I think it is incorrect, but I'm not sure how to proceed. We use 
> `long` to model pointers everywhere, but as far as I can tell the size 
> of a pointer is an implementation detail, and all the C standard says 
> about them is that the size must be sufficient to cover anything you 
> might want to get a pointer to.
>
> The value is used in several places to calculate a memory offset to 
> pass to `Unsafe` routines. I'm not sure if removing the check will 
> break anything, it's hard to test on my machine (Windows) since I'm 
> not running all the tests currently, and it's hard to check manually 
> since afaik you can't just ask the OS for a dereferenceable pointer 
> with it's high-order bit set.
>
> Jorn
>
>> Thanks,
>> Florian


More information about the panama-dev mailing list