RFR: 8257831: Suspend with handshakes [v2]

Robbin Ehn rehn at openjdk.java.net
Wed Mar 31 11:22:32 UTC 2021


On Tue, 30 Mar 2021 08:20:21 GMT, Richard Reingruber <rrich at openjdk.org> wrote:

>> Robbin Ehn has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits:
>> 
>>  - Merge branch 'master' into SuspendInHandshake
>>  - 8257831: Suspend with handshake (review baseline)
>
> src/hotspot/share/prims/jvmtiRawMonitor.cpp line 318:
> 
>> 316:   if (self->is_Java_thread()) {
>> 317:     jt = self->as_Java_thread();
>> 318:     while (true) {
> 
> From the PR description:
> 
>> Some code can be simplified or done in a smarter way but I refrained from doing such changes instead tried to keep existing code as is as far as possible. This concerns especially raw monitors.
> 
> I read this section but then forgot about it. So you can skip the following comment.
> 
> Possible follow-up: It could be worth the attempt to make use of the generic state transition classes provided by interface.hpp. Directly I don't see why this wouldn't be feasible and I doubt the [old comment in JvmtiEnv::RawMonitorEnter()](https://github.com/reinrich/jdk/blob/aefc1560b51f0ce96d8f5ce396ba0d2fe08fd650/src/hotspot/share/prims/jvmtiEnv.cpp#L3208-L3214).
> This would make the custom suspend logic here superfluous.
> If ThreadBlockInVM was changed to take a generic callback for unlocking, then this could replace the custom logic in L360-L374.

You are right on, this has been briefly discussed off-line.

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

PR: https://git.openjdk.java.net/jdk/pull/3191


More information about the hotspot-runtime-dev mailing list