Support for 64-bit pointers

[leerho]

Hi Radosław & Florian,

On a related topic, I have wished for years that Java would finally support
unsigned integral types (byte, short, int, and long).  I'm sure that I'm
not the first to mention this, so forgive me if this has been hashed out
before.  But I do not understand why there would be resistance to this.
For example, packing and unpacking "C-struct" -like data structures is a
PITA in Java,  Bytes and shorts have to be masked when upcasting to ints
and ints have to be masked when upcasting to longs all because of the
automatic sign-extension.   Not having unsigned types creates a ripe area
for bugs that can be hard to find.

Is there any hope of Java finally getting full support of unsigned types?

Cheers, and Happy New Year,

Lee.



On Fri, Jan 1, 2021 at 9:49 AM Radosław Smogura <mail at smogura.eu> wrote:

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