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.
Edit: mind explaining the downvote ?
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.
In retrospect, making 8-byte constants take two constant pool entries was a poor choice.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).
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.
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.
C and C++ usually do that too.
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 :(
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).
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/AlphaReorderin... So it's not really a natural target for Java code.
Ouch!
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.
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.
There a was HotJava browser, weren't servers just a small part of its target?
There's Java Card for smartcards yes. There was also Java Micro Edition (j2me) for phones.
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.