New candidate JEP: 501: Deprecate the 32-bit x86 Port for Removal

Julian Waters tanksherman27 at gmail.com
Fri Nov 15 18:00:41 UTC 2024


Hi David,

Zero is a port of the Java Virtual Machine that is written purely in
C++, with absolutely no Assembly whatsoever (Well, for the most part.
I think orderAccess and atomic both sneak in some Assembly, but in
tiny quantities only). Anything that requires Assembly (Think Just in
Time Compilers, the supercharged Interpreter that the default JVM
ships, miscellaneous VM Assembly codelets) is simply not present in
Zero. Before you get your hopes up, the platform non-specificity that
Zero presents is good for initial porting to new platforms, but, to
put it bluntly, Zero performs very poorly when compared to the default
JVM (On my Windows device, it took the Zero VM nearly 1 minute to run
through the startup process of a Minecraft Server while the default
Server VM zoomed through the process in seconds!). In practice this
will mean that Java programs that run on 32 bit x86 will suffer
massive performance degradation since Zero is now the only way they
can be executed, so while they can still be run, it likely will not be
worthwhile to do so

Additionally, quite counterintuitively, Zero is not available for
every OS, Windows being one (Actually I think the only, not counting
JDK forks) platform where support for Zero is missing. Although, now
that Magnus has fully removed the 32 bit Windows Port recently, I
wonder if anyone would mind a Windows/Zero Port, the changes to
support it were quite minimal, with the most confusing changes being
in os_windows.cpp and in several places where zero size arrays were
being created inside HotSpot classes when targeting Zero. I ultimately
fixed those by not defining them when in a Zero build

I actually have a curious question of my own too. Is the secondary
Interpreter that Zero uses the original Java Interpreter from Java's
very first release (JDK 1.0)? From what I can tell, this was a time
before even HotSpot existed, so it would be interesting if the
original legacy Interpreter lives on through Zero

best regards,
Julian


More information about the jdk-dev mailing list