[lworld] RFR: 8368002: [lworld] Crash in ThawBase::remove_top_compiled_frame_from_chunk

[Coleen Phillimore]

On Fri, 19 Sep 2025 14:40:20 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

> Please review this small fix. When thawing in the fast path, the top frame could be a runtime stub due to preempting on monitorenter. In the changes for JDK-8336845 I missed this, leading to a crash when dereferencing the nullptr returned by `f.cb()->as_nmethod_or_null()` in `ThawBase::remove_top_compiled_frame_from_chunk`.
> 
> I was able to reproduce the failure locally and verified it is now fixed. I did run into a pre-existing crash with Jetty (filed JDK-8368099). I also run all tests in java/lang/Thread/virtual stressing this path, tests Fuzz.java and TestVirtualThreads.java, plus extra mach5 tier testing.
> 
> Thanks,
> Patricio

src/hotspot/share/runtime/continuationFreezeThaw.cpp line 2075:

> 2073: }
> 2074: 
> 2075: int ThawBase::remove_scalarized_frames(StackChunkFrameStream<ChunkFrames::CompiledOnly>& f, stackChunkOop chunk, int frames_size, int &argsize) {

Thanks for explaining this change to me.  I think this parameter is confusing.  It's the incoming frame_size from the stub frame, and this adds in all the frame sizes from the frames that need a stack repair.
It might make more sense to me to distinguish these things, have the parameter be "stub_frame_size" or "top_frame_size" and to have a local to accumulate the visited frames sizes like:
int frames_size = stub_frame_size;

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1603#discussion_r2365648753