[lworld] RFR: 8376103: [lworld] Basic Zero support

[Aleksey Shipilev]

On Thu, 22 Jan 2026 13:49:59 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> On the way to stabilizing Valhalla for inclusion into mainline, we want to have Zero builds at least buildable and lightly runnable, e.g. for creating their own CDS archives. There is likely to be some bugtail to pass all the tests, this is out of scope for this basic support. We need to pull some fixes from mainline to make this work going smoother.
> 
> I have also enabled Zero Hotspot build in GHA back to keep it buildable.
> 
> Additional testing:
>  - [x] Linux x86_64 zero fastdebug, build works
>  - [x] Linux x86_64 zero fastdebug, bootcycle build works

For reference, Zero enters the new allocation path from here:


#8  0x00007ffff6f9e065 in JavaThread::check_for_valid_safepoint_state (this=this at entry=0x7ffff002c570)
#9  0x00007ffff7198d1a in MemAllocator::Allocation::check_for_valid_allocation_state (this=<optimized out>)
#10 MemAllocator::Allocation::verify_before (this=<optimized out>) at /home/shade/trunks/shipilev-valhalla/src/hotspot/share/gc/shared/memAllocator.cpp:146
#11 0x00007ffff719b2a2 in MemAllocator::Allocation::Allocation (obj_ptr=0x7ffff7b42388, allocator=..., this=0x7ffff7b42310)
#12 MemAllocator::allocate (this=this at entry=0x7ffff7b42390) at /home/shade/trunks/shipilev-valhalla/src/hotspot/share/gc/shared/memAllocator.cpp:353
#13 0x00007ffff6f11a4a in CollectedHeap::obj_allocate (__the_thread__=0x7ffff002c570, size=<optimized out>, klass=0x7ffec7065e00, this=<optimized out>)
#14 InstanceKlass::allocate_instance (this=this at entry=0x7ffec7065e00, __the_thread__=__the_thread__ at entry=0x7ffff002c570)
#15 0x00007ffff6f05c13 in InlineKlass::allocate_instance (this=this at entry=0x7ffec7065e00, __the_thread__=__the_thread__ at entry=0x7ffff002c570)
#16 0x00007ffff6f065e4 in InlineKlass::read_payload_from_addr (this=this at entry=0x7ffec7065e00, src=..., offset=offset at entry=384, 
#17 0x00007ffff697914e in flatArrayOopDesc::obj_at (__the_thread__=0x7ffff002c570, index=<optimized out>, this=<optimized out>)
#18 flatArrayOopDesc::obj_at (index=<optimized out>, this=<optimized out>)
#19 objArrayOopDesc::obj_at (this=<optimized out>, index=<optimized out>) at /home/shade/trunks/shipilev-valhalla/src/hotspot/share/oops/objArrayOop.inline.hpp:52
#20 0x00007ffff6a0e88e in BytecodeInterpreter::run<false, true> (istate=<optimized out>)
#21 0x00007ffff76e401d in ZeroInterpreter::main_loop (recurse=recurse at entry=0, __the_thread__=__the_thread__ at entry=0x7ffff002c570)
#22 0x00007ffff76e4f54 in ZeroInterpreter::normal_entry (method=<optimized out>, UNUSED=<optimized out>, __the_thread__=0x7ffff002c570)
#23 0x00007ffff76e407c in ZeroEntry::invoke (__the_thread__=0x7ffff002c570, method=<optimized out>, this=<op


It is in `_in_Java` state at the moment, but allocation path checks that we are in `_in_VM` state. Hence the new transition. Normal Zero (slow-path) allocations go through InterpreterRuntime. It is fairly awkward to do it there, but the allocation is really buried in `flatArrayOopDesc`. So the fix unbreaks Zero for a moment, letting us concentrate on other stuff.

-------------

PR Comment: https://git.openjdk.org/valhalla/pull/1943#issuecomment-3785489988