Support for 64-bit pointers

[Radosław Smogura]

Hi Florian,

That’s correct, even more there’s only 48 bits addressable.

I’m not sure what I was thinking - I was doing some performance checks and was concerned that unrestricted access looked like doing range checks and... well found this unrelated topic.

However just to mention, some Linux distribution uses vsyscalls (which is going to be deprecated) and this is mapped to the tail of memory ([1] nice asm code)

So even it’s not addressable it’s usable. I’m not sure if it’s worth handling.

Kind regards,
Rado

[1] https://stackoverflow.com/questions/7266813/how-does-the-gettimeofday-syscall-work

On Jan 1, 2021, at 2:04 PM, Florian Weimer <fw at deneb.enyo.de> wrote:

* Radosław Smogura:

In current version of implementation (many places), there’s a lot of
range checks. However longs in Java are signed, and C pointers are
unsigned so, at least for x86-64 architectures this should be taken
on account, otherwise we would not be able to address whole memory
in straightforward way (largest block size is 2^31, can directly
address upper half of memory).

The x86-64 architecture actually has signed addresses in the sense
that some number of upper bits of pointers must match the sign bit.
On Linux, userspace addresses always have a zero sign bit.  I think
this is not true on Solaris.  I don't know about Windows.

On some architectures, C struggles with similar issues because
ptrdiff_t is signed and does not cover the entire address space.  It's
therefore undefined to create objects whose size is greater than what
can be expressed as a ptrdiff_t value, despite the underlying
architecture supporting this.