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