State of x86_32 port of JEP 425: Virtual Threads (Preview)

Aleksey Shipilev shade at redhat.com
Wed Jun 15 16:54:19 UTC 2022


Hi,

Adding to the pile of port reports for Loom.

x86_32 port work is tracked under:
   https://bugs.openjdk.org/browse/JDK-8286642

...and relevant changes are in this tree:
   https://github.com/shipilev/jdk/tree/JDK-8286642-loom-x86-32-port

Current status for that port is:
   - Interpreter and C1 paths are working fine; hotspot_loom and jdk_loom pass reliably;
   - C2 seems to corrupt the stack somehow, I suspect during the deopt, after running for quite a 
while; the failures are all over the place, but they are only with C2;
   - New C2 intrinsics are known to break tests, disabling them makes more tests pass.

(I *suspect* that somewhere we stash the "current" thread onto stack, and then remount to another 
thread, which makes "current" thread obsolete. Assuming current thread does not change is quite 
pervasive, and saving "current thread" on architectures without dedicated thread register is rather 
common.)

Anyhow, the choice between "ship x86_32 without VM continuations" or "ship x86_32 without C2" is 
obvious: VM continuations are out. So, barring some debugging miracle, I don't expect x86_32 port to 
be fully ready for JDK 19.

The problems I saw during this work go beyond the x86_32 port work, and should be discussed in 
separate thread, I'll just mention that the existing implementation is hairy and full of subtle 
details. Alas, the code and comments do not make it clear what those details are, and which are part 
of the design, which are clever hacks, and which are the concessions to particular architectures.

In fact, it is not even clear to me if the "shared" code is actually fully architecture-independent, 
or just happens to work on x86_64 and AArch64. The current code needs to have significant cleanup, 
refactoring and (re-)documentation for sane porting/debugging work. This, I think, should be #1 
priority, and before that is done and ports are able to catch up, it would be unwise to pile more 
Loom stuff on.

-- 
Thanks,
-Aleksey



More information about the loom-dev mailing list