[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