4 ms·

Java made a bunch of optimistic assumptions about the future of hardware when it was designed. UTF-16 strings, 64 bit pointers, enormous object headers. While

Java made a bunch of optimistic assumptions about the future of hardware when it was designed. UTF-16 strings, 64 bit pointers, enormous object headers. While great for future-proofing, it's been hard to deny it's had overhead. Glad to see it's slowly getting undone: Compressed Oops, Compact Strings, now this.

iainmerrick 4y ago
64-bit pointers isn't really an optimistic assumption, it's just the normal pointer size on 64-bit systems.
- Bjartr 4y ago
  It was optimistic because Java came out long before 64 bit systems were common.
  - formerly_proven 4y ago
    Common in desktops, yes, but Sun being a UNIX workstation vendor they switched in the 90s.
    - oefrha 4y ago
      Well, the 3 billion devices (r) Java ran on certainly weren’t Sun workstations.
  - iainmerrick 4y ago
    Optimistic to represent object references with native pointers? C and C++ usually do that too.
  - prpl 4y ago
    UltraSPARC says hello
  - zactato 4y ago
    The DEC Alpha was a 64 bit CPU architecture that came out in 1992. Java support it from Java 1.0 to ~ Java 3 Interestingly, I can't find any information on Google about this, but ChatGPT does support this. Unfortunately all the primary sources it gave me are for docs that no longer exist on the web. The Wayback machine was no help. The old web is dead :(
    - cesarb 4y ago
      > Interestingly, I can't find any information on Google about this, but ChatGPT does support this. Unfortunately all the primary sources it gave me are for docs that no longer exist on the web. Or perhaps that never existed. It's well known that ChatGPT often hallucinates non-existing references (see for instance the discussion at https://news.ycombinator.com/item?id=33841672 https://news.ycombinator.com/item?id=33841672).
    - fweimer 4y ago
      Apparently, there was a Java port for Windows NT running on the DEC Alpha: https://archive.org/details/jdk-v1-alpha_nt https://archive.org/details/jdk-v1-alpha_nt It's unclear whether it's actually a 64-bit build. Did Windows even have a 64-bit userspace on Alpha, or was it all ILP32? Anyway, it's not really possible to implement the Java memory model on Alpha: https://www.cs.umd.edu/~pugh/java/memoryModel/AlphaReordering.html https://www.cs.umd.edu/~pugh/java/memoryModel/AlphaReorderin... So it's not really a natural target for Java code.
      - twoodfin 4y ago
        Wikipedia matches my recollection: Windows NT was actually ported to 64-bit using Alpha workstations, so there were probably some pre-release versions floating around. But by the time 64-bit Windows was ready, Alpha was a dying platform and the original release was only for the 64-bit platform with a real future, Itanium.
        iainmerrick 4y ago
        the 64-bit platform with a real future, Itanium Ouch!
- marginalia_nu 4y ago
  Right, but in the mid '90s when Java was designed, 64 bit machines were basically an exotic architecture and its practicalities weren't well understood, which is quite clear when CompressedOOPs is basically the sane default. The weird inconsistency is apparent as you fairly frequently stub your toe on the 2 billion size limits of Java arrays, which is an area where 64 bit pointers would have made much more size than in object references.
  - znpy 4y ago
    > Right, but in the mid '90s when Java was designed, 64 bit machines were basically an exotic architecture No they weren't, not in the enterprise market. At home? sure. SUN Microsystems released the Sparc v9 architecture in 1993. SUN also made the Java language and JVM.
    - krzyk 4y ago
      Wasn't java targeted at embedded? AFAIR at some point it was marketed that it will be in every washing machine, fridge. There a was HotJava browser, weren't servers just a small part of its target?
      - jbverschoor 4y ago
        "Write Once, Run Everywhere" was their slogan. There's Java Card for smartcards yes. There was also Java Micro Edition (j2me) for phones.
    - fweimer 4y ago
      Most binaries were still 32-bit for performance reason, and I don't think that Java 1.2 had a 64-bit port yet, not even on Solaris/SPARC. The situation that an x86-64 build is faster than an i386 build of most applications (exception extremely pointer-heavy ones) is a bit of an exception because x86-64 added additional registers and uses a register-based calling convention everywhere. That happens to counteract the overhead of 64-bit pointers in most cases. Other 64-bit architectures with 32-bit userspace compatibility kept using 32-bit userspace for quite some time.
masklinn 4y ago
> 64 bit pointers 64 bit pointers was not "optimistic assumptions" about anything, it was just 64 bit pointers on 64 bits systems like most everyone else. And compressed oops were added more than a decade ago (https://wiki.openjdk.org/display/HotSpot/CompressedOops https://wiki.openjdk.org/display/HotSpot/CompressedOops). For reference that's about when x32 was added to the linux kernel, and unlike x32 compressed oops have not been on the chopping block for 5 years. > enormous object headers. Hardly? They're two words a class pointer, and a "mark words" for GC integration.
- marginalia_nu 4y ago
  > And compressed oops were added more than a decade ago That is still recent on a Java timescale. > Hardly? They're two words a class pointer, and a "mark words" for GC integration. Well compare with for example C++, that can fly commando with no header, just (optional) alignment padding. In many Java objects, the header is more than half the size of the object. That's just not good data locality. The speed-up from switching from an array of objects that has n fields to an object which has an n arrays of fields can be very significant.
  - kaba0 4y ago
    Your array of objects are just tightly packed pointers, so the data locality (or its lack) doesn’t come from that (especially that the order of objects in memory may be different than the order in the array).
    - masklinn 4y ago
      I'm going on a limb as they're going in every direction and trebuchet-ing goalposts, but I'd assume they're talking about using an SoA structure, so instead of having a bunch of Foo objects each with a header and, say, an `int` field (so two words of header for half a word of payload) you have a single header at the top of the array, then an int value per record in the packed array.
komadori 4y ago
64-bit longs and doubles take up two slots in the JVM's local variable table, whereas Object references only take one. So, if anything, the design of Java bytecode assumed 32-bit pointers.
- kaba0 4y ago
  They can just use 64-bit slots for everything (it does leave unused 32bit for each 32bit local variable, but there are not many, and you get the benefit of the same logic no matter what you store there, plus it has the same performance on 64-bit systems) Edit: mind explaining the downvote ?
  - ternaryoperator 4y ago
    Not sure why you're being downvoted. The Jacobin JVM [0] does exactly what you suggest: 64-bit operand stack and local variables. Longs and doubles still occupy two slots on the operand stack, so as to avoid having to recompile Java classes that assume the two-slot allocation, but the design avoids having to smash together two 32-bit values every time a long or double is operated on. [0] http://jacobin.org/ http://jacobin.org/
- skitter 4y ago
  Relatedly the JVM specification section 4.4.5 says (as the same holds for the cp and stack): In retrospect, making 8-byte constants take two constant pool entries was a poor choice.

iainmerrick 4y ago

64-bit pointers isn't really an optimistic assumption, it's just the normal pointer size on 64-bit systems.

Bjartr 4y ago
It was optimistic because Java came out long before 64 bit systems were common.
- formerly_proven 4y ago
  Common in desktops, yes, but Sun being a UNIX workstation vendor they switched in the 90s.
  - oefrha 4y ago
    Well, the 3 billion devices (r) Java ran on certainly weren’t Sun workstations.
- iainmerrick 4y ago
  Optimistic to represent object references with native pointers? C and C++ usually do that too.
- prpl 4y ago
  UltraSPARC says hello
- zactato 4y ago
  The DEC Alpha was a 64 bit CPU architecture that came out in 1992. Java support it from Java 1.0 to ~ Java 3 Interestingly, I can't find any information on Google about this, but ChatGPT does support this. Unfortunately all the primary sources it gave me are for docs that no longer exist on the web. The Wayback machine was no help. The old web is dead :(
  - cesarb 4y ago
    > Interestingly, I can't find any information on Google about this, but ChatGPT does support this. Unfortunately all the primary sources it gave me are for docs that no longer exist on the web. Or perhaps that never existed. It's well known that ChatGPT often hallucinates non-existing references (see for instance the discussion at https://news.ycombinator.com/item?id=33841672 https://news.ycombinator.com/item?id=33841672).
  - fweimer 4y ago
    Apparently, there was a Java port for Windows NT running on the DEC Alpha: https://archive.org/details/jdk-v1-alpha_nt https://archive.org/details/jdk-v1-alpha_nt It's unclear whether it's actually a 64-bit build. Did Windows even have a 64-bit userspace on Alpha, or was it all ILP32? Anyway, it's not really possible to implement the Java memory model on Alpha: https://www.cs.umd.edu/~pugh/java/memoryModel/AlphaReordering.html https://www.cs.umd.edu/~pugh/java/memoryModel/AlphaReorderin... So it's not really a natural target for Java code.
    - twoodfin 4y ago
      Wikipedia matches my recollection: Windows NT was actually ported to 64-bit using Alpha workstations, so there were probably some pre-release versions floating around. But by the time 64-bit Windows was ready, Alpha was a dying platform and the original release was only for the 64-bit platform with a real future, Itanium.
      - iainmerrick 4y ago
        the 64-bit platform with a real future, Itanium Ouch!
marginalia_nu 4y ago
Right, but in the mid '90s when Java was designed, 64 bit machines were basically an exotic architecture and its practicalities weren't well understood, which is quite clear when CompressedOOPs is basically the sane default. The weird inconsistency is apparent as you fairly frequently stub your toe on the 2 billion size limits of Java arrays, which is an area where 64 bit pointers would have made much more size than in object references.
- znpy 4y ago
  > Right, but in the mid '90s when Java was designed, 64 bit machines were basically an exotic architecture No they weren't, not in the enterprise market. At home? sure. SUN Microsystems released the Sparc v9 architecture in 1993. SUN also made the Java language and JVM.
  - krzyk 4y ago
    Wasn't java targeted at embedded? AFAIR at some point it was marketed that it will be in every washing machine, fridge. There a was HotJava browser, weren't servers just a small part of its target?
    - jbverschoor 4y ago
      "Write Once, Run Everywhere" was their slogan. There's Java Card for smartcards yes. There was also Java Micro Edition (j2me) for phones.
  - fweimer 4y ago
    Most binaries were still 32-bit for performance reason, and I don't think that Java 1.2 had a 64-bit port yet, not even on Solaris/SPARC. The situation that an x86-64 build is faster than an i386 build of most applications (exception extremely pointer-heavy ones) is a bit of an exception because x86-64 added additional registers and uses a register-based calling convention everywhere. That happens to counteract the overhead of 64-bit pointers in most cases. Other 64-bit architectures with 32-bit userspace compatibility kept using 32-bit userspace for quite some time.

masklinn 4y ago

> 64 bit pointers 64 bit pointers was not "optimistic assumptions" about anything, it was just 64 bit pointers on 64 bits systems like most everyone else. And compressed oops were added more than a decade ago (https://wiki.openjdk.org/display/HotSpot/CompressedOops https://wiki.openjdk.org/display/HotSpot/CompressedOops). For reference that's about when x32 was added to the linux kernel, and unlike x32 compressed oops have not been on the chopping block for 5 years. > enormous object headers. Hardly? They're two words a class pointer, and a "mark words" for GC integration.

marginalia_nu 4y ago
> And compressed oops were added more than a decade ago That is still recent on a Java timescale. > Hardly? They're two words a class pointer, and a "mark words" for GC integration. Well compare with for example C++, that can fly commando with no header, just (optional) alignment padding. In many Java objects, the header is more than half the size of the object. That's just not good data locality. The speed-up from switching from an array of objects that has n fields to an object which has an n arrays of fields can be very significant.
- kaba0 4y ago
  Your array of objects are just tightly packed pointers, so the data locality (or its lack) doesn’t come from that (especially that the order of objects in memory may be different than the order in the array).
  - masklinn 4y ago
    I'm going on a limb as they're going in every direction and trebuchet-ing goalposts, but I'd assume they're talking about using an SoA structure, so instead of having a bunch of Foo objects each with a header and, say, an `int` field (so two words of header for half a word of payload) you have a single header at the top of the array, then an int value per record in the packed array.

komadori 4y ago

64-bit longs and doubles take up two slots in the JVM's local variable table, whereas Object references only take one. So, if anything, the design of Java bytecode assumed 32-bit pointers.

kaba0 4y ago
They can just use 64-bit slots for everything (it does leave unused 32bit for each 32bit local variable, but there are not many, and you get the benefit of the same logic no matter what you store there, plus it has the same performance on 64-bit systems) Edit: mind explaining the downvote ?
- ternaryoperator 4y ago
  Not sure why you're being downvoted. The Jacobin JVM [0] does exactly what you suggest: 64-bit operand stack and local variables. Longs and doubles still occupy two slots on the operand stack, so as to avoid having to recompile Java classes that assume the two-slot allocation, but the design avoids having to smash together two 32-bit values every time a long or double is operated on. [0] http://jacobin.org/ http://jacobin.org/
skitter 4y ago
Relatedly the JVM specification section 4.4.5 says (as the same holds for the cp and stack): In retrospect, making 8-byte constants take two constant pool entries was a poor choice.