On Thu, 22 Jan 2026 13:49:59 GMT, Aleksey Shipilev <[email protected]> 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@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@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@entry=0x7ffec7065e00, __the_thread__=__the_thread__@entry=0x7ffff002c570) #15 0x00007ffff6f05c13 in InlineKlass::allocate_instance (this=this@entry=0x7ffec7065e00, __the_thread__=__the_thread__@entry=0x7ffff002c570) #16 0x00007ffff6f065e4 in InlineKlass::read_payload_from_addr (this=this@entry=0x7ffec7065e00, src=..., offset=offset@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@entry=0, __the_thread__=__the_thread__@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
