On Wed, 12 May 2021 08:04:47 GMT, Robbin Ehn <r...@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.hol...@oracle.com) on > [hotspot-runtime-dev](mailto:hotspot-runtime-...@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
