On Fri, 19 Sep 2025 14:40:20 GMT, Patricio Chilano Mateo
<[email protected]> 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
