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

Amit Kumar amitkumar at openjdk.org
Thu Nov 7 08:47:14 UTC 2024


On Wed, 6 Nov 2024 17:38:59 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> Good work! I'll approve the GC related changes.
>> 
>> There are some simplifications I think can be done in the ObjectMonitor layer, but nothing that should go into this PR.
>> 
>> Similarly, (even if some of this is preexisting issues) I think that the way we describe the frames and the different frame transitions should be overhauled and made easier to understand. There are so many unnamed constants and adjustments which are spread out everywhere, which makes it hard to get an overview of exactly what happens and what interactions are related to what.  You and Dean did a good job at simplifying and adding comments in this PR. But I hope this can be improved in the fututre.
>> 
>> A small note on `_cont_fastpath`, as it is now also used for synchronised native method calls (native wrapper) maybe the comment should be updated to reflect this.
>> 
>> // the sp of the oldest known interpreted/call_stub frame inside the
>> // continuation that we know about
>
>> A small note on `_cont_fastpath`, as it is now also used for synchronised native method calls (native wrapper) maybe the comment should be updated to reflect this.
>> 
>> ```
>> // the sp of the oldest known interpreted/call_stub frame inside the
>> // continuation that we know about
>> ```
>>
> Updated comment.

@pchilano `CancelTimerWithContention.java` test is failing on s390x with Timeout Error. One weird thing is that it only fails when I run whole tier1 test suite. But when ran independently test passes.

One thing I would like to mention is that I ran test by **disabling** VMContinuations, as Vthreads are not yet supported by s390x. 

[CancelTimerWithContention.log](https://github.com/user-attachments/files/17658594/CancelTimerWithContention.log)

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

PR Comment: https://git.openjdk.org/jdk/pull/21565#issuecomment-2461640546


More information about the serviceability-dev mailing list