RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning [v17]

[Patricio Chilano Mateo]

On Wed, 30 Oct 2024 23:02:28 GMT, Dean Long <dlong at openjdk.org> wrote:

>> We read this value from the freeze/thaw code in several places. Since the only compiled native frame we allow to freeze is Object.wait0 the old value would be zero too. But I think the correct thing is to just set it to zero always since a value > 0 is only meaningful for Java methods.
>
> Isn't it possible that we might allow more compiled native frames in the future, and then we would have to undo this change?  I think this change should be reverted.  If continuations code wants to assert that this is 0, then that should be in continuations code, the nmethod code doesn't need to know how this field is used.  However, it looks like continuations code is the only client of this field, so I can see how it would be tempting to just set it to 0 here, but it doesn't feel right.

Any compiled native frame would still require a value of zero. This field should be read as the size of the argument area in the caller frame that this method(callee) might access during execution. That's why we set it to zero for OSR nmethods too. The thaw code uses this value to see if we need to thaw a compiled frame with stack arguments that reside in the caller frame. The freeze code also uses it to check for overlap and avoid copying these arguments twice. Currently we have a case for "nmethods" when reading this value, which includes both Java and native. I'd rather not add branches to separate these cases, specially given that we already have this field available in the nmethod class.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1824785565