RFR: 8265753: Remove manual JavaThread transitions to blocked [v3]

[Richard Reingruber]

On Wed, 12 May 2021 08:04:47 GMT, Robbin Ehn <rehn at openjdk.org> wrote:

>> Please consider this change which removes the manual transitions to blocked.
>> This adds a preprocess template/functor which is executed in the destructor of 'ThreadBlockInVM' if we are going to do any processing.
>> This gives us a way to backout of the object/raw monitor before suspend or other processing, such as a safepoint.
>> 
>> The object monitor code could be straight forward changed to use this instead of manual transitions.
>> 
>> Raw monitors on the other hand are a bit more complicated due to 'implicit' rules (consequences of the specs).
>> Added a comment in hpp trying to explain it; we cannot simply transition with a raw monitor held.
>> This caused the change in the destructor ~ThreadInVMfromNative() (this specific change have also been tested in unrelated exploration of transition), now this RAII does the same as we do when going to native from Java, just setting the state.
>> Since we are going from an unsafe state, in VM, to a safe state, in native, we do not need to check the poll.
>> That made it possible to careful use ThreadInVMfromNative in raw monitors.
>> 
>> I also remove the early CAS in raw_enter.
>> We lock a lock to do a CAS, in the uncontended case means CAS on lock then CAS raw monitor.
>> Now we instead do a transitions, in the uncontended case means fence, CAS raw monitor, fence.
>> (multiple fence (CAS is also a fence) very close to each other have little additional performance impact on contemporary hardware)
>> 
>> Passes t1-t7 and manual stressing relevant test groups.
>
> Robbin Ehn has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fixes for Dan

> 
> 
> _Mailing list message from [David Holmes](mailto:david.holmes at oracle.com) on [hotspot-runtime-dev](mailto:hotspot-runtime-dev at mail.openjdk.java.net):_
> 
> On 12/05/2021 8:56 pm, Robbin Ehn wrote:
> 
> > On Wed, 12 May 2021 08:27:33 GMT, Richard Reingruber <rrich at openjdk.org> wrote:
> > > Hi Robbin,
> > > I haven't found the time for a proper review yet but I've experimented a little bit with lambdas. I could not make it work because g++ created references to ::new which isn't allowed.
> > > Thanks, Richard.
> > 
> > 
> > Hi Richard,
> > I tested lamdba, which is just a fancy way to write a crazy typed functor, we need to capture the lamdba so we can run it in the destructor. AFAICT the way to do that is using std::function.
> > Regarding ThreadClosure, we could use it, maybe that is preferable?!
> 
> Isn't a ThreadClosure for applying an operation to a set of threads?
> That is not what we are doing here.

No it isn't. A closure is just a set of variable bindings and a function that can be executed. And yes we're doing just that.

A ThreadClosure is just an instance of this general concept. E.g. an AsyncHandshakeClosure (subclass of ThreadClosure) is a function (plus variable bindings) that is passed by a requesting thread to a target thread to be executed by it.

Thanks,
Richard.

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

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