[lworld] RFR: 8336845: [lworld] Virtual threads don't support the value class calling convention

[Coleen Phillimore]

On Tue, 9 Sep 2025 12:50:49 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

> Please review the following patch which adds virtual thread support for the value class calling convention. Most of the changes are needed to handle extended frames, i.e c1 or c2 frames that use more stack space for arguments than the stack space allocated by the caller. These include changes in freeze and thaw code, plus changes in the stackChunk walking code where we now need a similar repair of the caller sp as in the current sender code. In this case though, we only adjust _unextended_sp and keep the value of _sp. This is because frames are walked without a full RegisterMap, but we still need to be able to access the saved fp in the callee for gc purposes. The remaining changes deal with saving and restoring the extra return registers when calling thaw.
> 
> Thanks to Tobias for working on the initial changes and for providing the very useful new test TestVirtualThreads.java, included in this PR, which has been great for catching many bugs. I also run the changes with the valhalla-comp-stress job in mach5. It uncovered a couple of extra failures in TestVirtualThreads.java, but I was able to reproduce them with platform threads as well (8367151 and 8367258). I also added extra testing for value classes in existing test Fuzz.java which has proven very useful too.
> 
> Thanks,
> Patricio

src/hotspot/cpu/x86/stackChunkFrameStream_x86.inline.hpp line 54:

> 52:                         RegisterMap::WalkContinuation::skip);
> 53:         frame caller = to_frame().sender(&map);
> 54:         assert(caller.is_compiled_frame() && caller.cb()->as_nmethod()->is_compiled_by_c2(), "");

All these asserts with no messages could be precond().  Or they could have strings why these conditions are expected.

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1556#discussion_r2340990577