8 ms·

>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

by kgeist 4y ago

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

lbhdc 4y ago
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.
- deleted 4y ago
  [deleted]
- bitwize 4y ago
  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.
- cesarb 4y ago
  > 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/ https://faultlore.com/blah/fix-rust-pointers/ and https://faultlore.com/blah/tower-of-weakenings/ https://faultlore.com/blah/tower-of-weakenings/), and also on GCC and glibc (https://lwn.net/Articles/909265/ 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.
  - lbhdc 4y ago
    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?
    - solomatov 4y ago
      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-asplos-cheriabi.pdf https://www.cl.cam.ac.uk/research/security/ctsrd/pdfs/201904...
  - skitter 4y ago
    MemorySegment::adress only returns an address, which fits in 64 bit even on CHERI.
  - TedDoesntTalk 4y ago
    > 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.
- gavinray 4y ago
  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/6a80673e73cfcf773212ee068b808f2b9d628df6/lib/src/test/java/panama/liburing/LibraryTest.java#L65 https://github.com/GavinRay97/panama-liburing/blob/6a80673e7...
  - lbhdc 4y ago
    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.
    - gavinray 4y ago
      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);
      - lbhdc 4y ago
        Ahhh that makes sense, and more reasonable why they removed the class. Thanks for sharing!
        gavinray 4y ago
        No problem =) Finally had somewhere to post this obscure project, haha
  - throwaway2037 4y ago
- kgeist 4y ago
  >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.
bullen 4y ago
16 billion gigabytes not enough for you?
- littlestymaar 4y ago
  CHERI[1] anyone? [1] https://www.cl.cam.ac.uk/research/security/ctsrd/cheri/ https://www.cl.cam.ac.uk/research/security/ctsrd/cheri/
- Ygg2 4y ago
  2 EiB to be precise.
  - thangalin 4y ago
    2.305843009213694 ;-)
    - Ygg2 4y ago
      2^64 bites should be exactly 2EiB.
- Alupis 4y ago
  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.
  - CyberDildonics 4y ago
    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.
CyberDildonics 4y ago
Most CPUs in common use can only address 48 bits of memory, which is about 280 terabytes.
- bullen 4y ago
  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 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-80-watts/ 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.
  - CyberDildonics 4y ago
    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. 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.
throwaway2037 4y ago
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.
- taftster 4y ago
  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.
  - throwaway2037 4y ago
    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!
- kgeist 4y ago
  >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.
kaba0 4y ago
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.

by kgeist 4y ago

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

lbhdc 4y ago

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.

deleted 4y ago
[deleted]
bitwize 4y ago
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.
cesarb 4y ago
> 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/ https://faultlore.com/blah/fix-rust-pointers/ and https://faultlore.com/blah/tower-of-weakenings/ https://faultlore.com/blah/tower-of-weakenings/), and also on GCC and glibc (https://lwn.net/Articles/909265/ 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.
- lbhdc 4y ago
  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?
  - solomatov 4y ago
    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-asplos-cheriabi.pdf https://www.cl.cam.ac.uk/research/security/ctsrd/pdfs/201904...
- skitter 4y ago
  MemorySegment::adress only returns an address, which fits in 64 bit even on CHERI.
- TedDoesntTalk 4y ago
  > 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.
gavinray 4y ago
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/6a80673e73cfcf773212ee068b808f2b9d628df6/lib/src/test/java/panama/liburing/LibraryTest.java#L65 https://github.com/GavinRay97/panama-liburing/blob/6a80673e7...
- lbhdc 4y ago
  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.
  - gavinray 4y ago
    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);
    - lbhdc 4y ago
      Ahhh that makes sense, and more reasonable why they removed the class. Thanks for sharing!
      - gavinray 4y ago
        No problem =) Finally had somewhere to post this obscure project, haha
- throwaway2037 4y ago
kgeist 4y ago
>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.

bullen 4y ago

16 billion gigabytes not enough for you?

littlestymaar 4y ago
CHERI[1] anyone? [1] https://www.cl.cam.ac.uk/research/security/ctsrd/cheri/ https://www.cl.cam.ac.uk/research/security/ctsrd/cheri/
Ygg2 4y ago
2 EiB to be precise.
- thangalin 4y ago
  2.305843009213694 ;-)
  - Ygg2 4y ago
    2^64 bites should be exactly 2EiB.
Alupis 4y ago
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.
- CyberDildonics 4y ago
  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.

CyberDildonics 4y ago

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

bullen 4y ago
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 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-80-watts/ 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.
- CyberDildonics 4y ago
  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. 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.

throwaway2037 4y ago

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.

taftster 4y ago
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.
- throwaway2037 4y ago
  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!
kgeist 4y ago
>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.

kaba0 4y ago

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.