Hacker News Reader

Comment by kgeist | Hacker News Reader

>In Java 20, MemorySegment::address returns a raw memory address in the form of a long rather than a MemoryAddress object

So the API assumes pointers can't be larger than 64 bit?

View on HN

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.

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.

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

Real question: What is a reasonable solution? Java has strictly defined primitive types: The largest integral type (long) is 8 bytes/64 bits. Please remember that Java does not have typedef, so it is not as simple as hiding the solution behind an opaque typedef that is #define'd at compile time.

More likely: If 128-bit address space really takes off, they can create a new largest integral type long128 that is 16 bytes/128 bits, and either extend the existing MemorySegment, or create MemorySegmentLarge to allow for bizarrely large address spaces, like up to 1024-bit.

Another one that people like to pick on Java about: Arrays are limited to max size of 2^31-1 (non-negative part of a 32-bit signed int). To rephrase your question: <<So the API assumes arrays can't be larger than a 32 bit signed int?>> Yeah, I guess.

The Array limitation is easy to deal with (in my opinion). If you're needing arrays larger than Integer.MAX_VALUE, then you're probably doing something wrong to begin with. Usually you want to partition your data and maintain multiple arrays in some reasonable way hiearchical way, if you're getting that big. Or more likely, at that point, you're building your own memory structures using a ByteBuffer (and possibly in the future, MemorySegment).

Point is, your reply is exactly right. Arrays can't be 64-bit large? Yeah, I guess.

I read this post a couple of times before it hit me: Your comment about Arrays and "doing it wrong" actually works without trolling the original question. Your main point: The question isn't hardly useful vis-a-vis arrays. However, for pointers -- if you really have 128-bit pointers -- then, yes, you are screwed and that interface/impl won't work. Excellent reply!

>Real question: What is a reasonable solution?

I thought of something like IntPtr in C# (native size int). Although, to be portable, JVM would have to disallow doing pointer math on it, to make IntPtr fully opaque.

16 billion gigabytes not enough for you?

2 EiB to be precise.

2.305843009213694 ;-)

2^64 bites should be exactly 2EiB.

CHERI[1] anyone?

[1] https://www.cl.cam.ac.uk/research/security/ctsrd/cheri/

This is probably posted in jest, but there was a time - not so long ago - where folks firmly believed nobody would need more than 16 memory bits, and even 1 Gigabyte of storage was considered outlandish.

Things have gotten exponentially larger in the meantime... with your average home computer going from < 1GB of RAM to 8GB and ever increasingly larger (my cell phone has 12GB of RAM and 512GB of storage for what it's worth).

Having storage ranging in the Terabyte category is simply the norm, and things like Petabytes of storage are rapidly becoming more accessible for average users.

Saying "X is enough" - ever - in computing is foolhardy.

but there was a time - not so long ago - where folks firmly believed nobody would need more than 16 memory bits

This is not true, no one seriously thought 65 KB was ever going to be any sort of a limit. If you're talking about the Bill Gates quote, it's basically a myth that never happened or was taken WAY out of context. Bill Gates himself has given interview where he talks about the entire state of released and upcoming computers of that time and exactly what everyone thought was going to happen and what actually did happen.

No, it was not just Gates that thought this. Look around you, all of your old tech was designed for smaller numbers. Even IP addresses were designed with "we'll never need more than X", and look at the mess we're in today.

Every time someone in tech has said "that number is large enough", the number gets surpassed in no time.

So while 64 bit memory addresses seems way more than ample today, it will not be forever. That was the point...

No, that's not how it went. People were not stupid and lacking any foresight in the past. Constrained storage space has been a concern since Charles Babbage's analytical engine, that is since forever in computing. No one ever thought let's stop at 16 bit pointers or whatever and it will be enough for the rest of time. It's an engineering tradeoff to make the best of the technology available at the time. Pointer sizes are not just a number, they correspond to realities down to the electronics and physical design of your system. Longer pointers mean larger address bus, larger registers, more transistors on your chip that won't be available for something else. They are more wasteful if you don't actually have that much memory to address. It's incredibly naive to think today's standards were even a possibility decades ago.

> No, that's not how it went. People were not stupid and lacking any foresight in the past

It truly is in so many cases. Not stupidity, but perhaps hubris. The same hubris that says nobody will need more than 64 bits today. Given time, 64 bits will fall waste to 128 bits and more.

The people who designed IPv4 truly thought the number of IP's would be more than enough forever. They literally had no concept that one day your average person would own multiple computing devices and require multiple IP's just to get through a normal day. They were very wrong, and found out in only a few year's time.

The only constant in tech is our assumptions today will be wrong tomorrow. Assuming "X" is big enough is foolhardy in just about every scenario.

Well, they had no idea IP was going to be used by consumers full stop.

You realize that limitations like 16 bit addressing was because of the extreme limitations of the time right? The 6502 can address 65KB of memory, had 13 address modes, 55 instructions and was made out of 3,510 transistors. Modern CPUs have over a million times the transistor count.

Every year was another iteration of these limits being updated, no one ever thought any of these numbers were going to stay static. It took 1MB of memory just to have a 24 bit color frame buffer at NTSC resolution.

IP addresses were set at 4 billion when you could print out a list of known computers and put it in a binder and we still use it today.

This idea that people had a general lack of foresight was completely untrue. What people did with limitations like 3,510 transistors is astounding.

Upvote from me. I have been at 32GB of RAM for more than 5 years. I am genuinely surprised. I'm basically a big corporate programmer that runs Microsoft Outlook (surprisingly low memory), a giant (8GB RAM) IDE, and a squillion Google Chrome tabs. I struggle to think how/when I will need more than 32GB RAM. I have 64GB at home from a COVID-era new build, only because it seemed short sighted to "only" buy 32GB RAM in 2021. I have never once come close to needing it. :)

That said, I completely agree with your sentiment about "X is enough". What has changed in the last 20 years: When we double RAM/storage/network now, the increase is enormous. It does feel like GPUs are still in the insane growth period. Very soon they will be more powerful and have more on-board RAM than whole rest of the computer.

An internet search tells me there are somewhere between 10^76 and 10^82 atoms in the universe. We must not rest until all atoms are mmap-able. That should require at least a 273-bit length type to be safe. Since we need a power of two, 512-bit length. This size also gives us a little room for fat pointers.

So the computer that simulates the universe is likely a 512-bit machine.

How does it simulate subatomic particles then?

It doesn't seem there are many orders of magnitude more subatomic particles. 3 quarks in a proton. At most O(10^2) protons in a atom. So it should all fit comfortably in a 512-bit type.

* As for photons, this estimate finds 4*10^84 photons since start of universe:

https://cosmosmagazine.com/science/physics/how-many-photons-...

“3 quarks in a proton” is an oversimplification; the reality involves “zillions” of particles, as per https://profmattstrassler.com/articles-and-posts/largehadron...

Maybe we need to use 1024-bit types?

The universe is expanding, we need it to be scalable

It’s virtual memory and it has a TLB.

> That should require at least a 273-bit length type to be safe. Since we need a power of two, 512-bit length.

The size of memory is a power of two because the bits in a pointer have two possible values.

But why do you need the length of a pointer to also be a power of two? Are you addressing the bits in the pointer?

Beats having to expand later with Gate A272.

>But why do you need the length of a pointer to also be a power of two? Are you addressing the bits in the pointer?

Indeed. The entanglement code will crawl without easy direct addressing of the bits. We wouldn't want the universe to run even slower, would we now? It would also make the development emulator impossible to run leading to even more bugs and missed deadlines.

But that is just a raw representation of a pointer, what you actually pass and use as a pointer is not long values, but MemorySegments (formerly MemoryAddresses) — so the actual size is just an implementation detail.

Plus Panama won’t go stable until Valhalla, which is necessary to actually have a “long long” in the language.

Most CPUs in common use can only address 48 bits of memory, which is about 280 terabytes.

Here's a few:

  6502: 8-bit registers / 16-bit address space (1975-)
  68000: 16 / 24 (1985-1992 then 32/32)
  ARM1: 32 / 26 (1985- 32/32 in 1992 and finally 64/64 in 2011)
  X86: a complete address space mess but lately 57-bit:

https://en.wikipedia.org/wiki/X86

The morale of the story is humans are insecure fragile little creatures, half of us are blind and the other half are pessimists because we can imagine what the truth/future looks like. Lies only last the time you can use energy to hide them.

Anyhow the arch of binary evolution is over; to build a MMU that can adress 64-bits of data is probably impossible with electrons. Just going from 64GB to 256GB is hard and makes things slower! Caches appeared in 1985, so since then the bottle neck has been RAM latency:

https://gettotext.com/largest-ram-bar-in-the-world-consumes-...

The biggest server from Oracle currently has 16 TB of RAM, good luck multiplying that by the difference in energy content per mass difference between oil and uranium (1.000.000x).

And good luck paying your energy bill. 64-bit RAM would consume 5120W * 1.000.000 = 5GW (you want 5x nuclear power plants with that server?)

Personally I'm staying on 32-bit for my ARMv8 cluster, my processes are limited to 4GB RAM each but since I only have 8GB of total RAM there is ZERO difference in switching to 64-bit as it effectively halves the RAM.

I made a comment about the virtual memory space of most desktop CPUs in use. I have no idea what you are talking about, did you mean to reply to me?

Anyhow the arch of binary evolution is over;

I don't think these words together mean anything.

to build a MMU that can adress 64-bits of data is probably impossible with electrons.

It's strange to call something impossible when it has already been done.

And that is virtual memory, one is free to basically use 280 terabytes per process, or whatever they choose as a context boundary.

Reply on news.ycombinator.com