Hacker News Reader

Comment by lbhdc | Hacker News Reader

This is perhaps a naive question, but are there many machines that need more than 64bits of address space?

One of the things that jumped out to me about that changes, was that I assume that this will allow for unsafe pointer math. I suppose this is a low level api, but I thought that was an interesting choice.

View on HN

> This is perhaps a naive question, but are there many machines that need more than 64bits of address space?

Not many machines currently, but CHERI has 129-bit pointers (yes, 129), and there's already some work on for instance Rust to be able to work with that (see https://faultlore.com/blah/fix-rust-pointers/ and https://faultlore.com/blah/tower-of-weakenings/), and also on GCC and glibc (https://lwn.net/Articles/909265/), and it's not completely improbable that this becomes more common. Creating a brand-new API today which cannot handle pointers wider than 64 bits seems a bit short-sighted.

That is very interesting, I hadn't heard of CHERI. 129 bit pointers sound like a bit of an oddity to me. What is the story behind choosing that size?

It's not just a pointer, but a pointer + metadata.

See this paper for details: https://www.cl.cam.ac.uk/research/security/ctsrd/pdfs/201904...

MemorySegment::adress only returns an address, which fits in 64 bit even on CHERI.

> Creating a brand-new API today which cannot handle pointers wider than 64 bits seems a bit short-sighted

2^64 can address over 16 petabytes. I’m not sure when I’ll be working on that scale, but n by the time it happens, Java can introduce new data types like BigLong to handle it.

It does allow for unsafe pointer math, I have some examples here where I've ported io_uring to use native Java Foreign Memory API with no external headers/bindings:

https://github.com/GavinRay97/panama-liburing/blob/6a80673e7...

It seems like you are using the `MemoryAddress` object. The article says that api was removed in 20. I may be misunderstanding what you are doing though :)

    In Java 19, there was a notion named MemoryAddress used for “pointers to memory” and  function 
    addresses. In Java 20,  MemorySegment::address returns a raw memory address in the form of a 
    long rather than a MemoryAddress object.

Same difference, the "MemoryAddress" was a wrapper class around a long that pointed to the underlying address

You can see that a bit further down below when ".toRawLongValue()" is called:

        long iovecs_ptr = fi.address().toRawLongValue() + file_info.sizeof();
        liburing.io_uring_prep_readv(sqe_ptr, file_fd, MemoryAddress.ofLong(iovecs_ptr), blocks, 0);
        liburing.io_uring_sqe_set_data(sqe_ptr, fi.address());
        int ret = liburing.io_uring_submit(ring_ptr);

Ahhh that makes sense, and more reasonable why they removed the class. Thanks for sharing!

No problem =)

Finally had somewhere to post this obscure project, haha

This is insanely cool. Thank you to share.

>This is perhaps a naive question, but are there many machines that need more than 64bits of address space?

I thought a potential CPU of the future could have 128 bit "word size" for integer calculations and as a side effect also 128 bit pointers to reuse registers/instructions for both of them (just like today with 64 bit CPUs, indeed you don't need to map the entire address space but pointers are still 64 bit because it's the CPU's word size). And then address space layout randomization in a future OS could choose to map very high address ranges for the process, which can't be represented with Java's long.

Even leaving alone the fact that we may wish for a computer architecture that could theoretically mmap(), say, the internet... things like CHERI are gonna bring fat pointers back.

Reply on news.ycombinator.com