jdk.vm.ci.code.stack.StackIntrospection.iterateFrames permits modifying the locals of a materialized frame but it relies on JVMTI deferred locals support which doesn't work with virtual threads. This is a limitation for Truffle based languages, as it mean they cannot use this facility on virtual threads, which can limit language functionality.

This is primarily a bookkeeping problem as the JvmtiDeferredUpdates are stored in the JavaThread, and heap frames can move between JavaThreads so the deferred local information needs to move around with the heap frame.

The most straightforward way of doing this would be to store the pointer to the deferred local information in a slot of the frame. With clever bookkeeping, the orig_pc slot that holds the original pc for deopt could store the deferred locals pointer but it would also be possible to require a second slot to store this pointer. The lifetime of the deferred locals data structure is exactly the same as the original_pc tracking for deoptimization, so it fits rather neatly into this strategy.

Additionally the current deoptimization path doesn't handle deoptimizing heap frames but that's fairly simple to add.

The JVMCI iterateFrames logic also needs to be rewritten to be friendly to seeing heap frames. This means eliminating the use of the frame id as it isn't support on heap frames.

Adding this machinery could also permit JVMTI to support all the normal frame modification features on virtual threads but I don't know how important this would be to the serviceability group. So this could be something which is only supported for JVMCI but it could also be expanded to include full support for JVMTI without huge changes.

Storing the data in the frame does assume that we will always have a chance to free this C heap data before the frame goes away. Assuming everything JavaThread, including virtual ones, goes through JavaThread::exit will permit the safe cleanup of this storage.