[14] RFR (XXS): 8235143: C2: No memory state needed in Thread::currentThread() intrinsic

[Doerr, Martin]

Hi Vladimir,

thanks for your additional comments.

> It's not the case that  j.l.Thread oop couldn't be alive across a
> safepoint before and now it can.
Right, but the j.l.Thread oop loads can move across safepoints, now. So they can possibly become additional GC roots in registers at safepoints. That should be fine.

Best regards,
Martin


> -----Original Message-----
> From: Vladimir Ivanov <vladimir.x.ivanov at oracle.com>
> Sent: Freitag, 6. Dezember 2019 16:28
> To: Doerr, Martin <martin.doerr at sap.com>; hotspot compiler <hotspot-
> compiler-dev at openjdk.java.net>
> Subject: Re: [14] RFR (XXS): 8235143: C2: No memory state needed in
> Thread::currentThread() intrinsic
> 
> Thanks, Martin.
> 
> > The j.l.Thread Oop for Thread::current() is allowed to live in a register with
> this change.
> > GC will find it via OopMap at safepoints. So I think it's correct.
> 
> FTR nothing changes in that respect: with the patch it behaves as if a
> j.l.Thread is cached in a local after the first Thread::currentThread()
> call. But it can be done explicitly on bytecode level in a user code.
> It's not the case that  j.l.Thread oop couldn't be alive across a
> safepoint before and now it can.
> 
> Best regards,
> Vladimir Ivanov
> 
> >> -----Original Message-----
> >> From: hotspot-compiler-dev <hotspot-compiler-dev-
> >> bounces at openjdk.java.net> On Behalf Of Vladimir Ivanov
> >> Sent: Donnerstag, 5. Dezember 2019 13:44
> >> To: hotspot compiler <hotspot-compiler-dev at openjdk.java.net>
> >> Subject: [14] RFR (XXS): 8235143: C2: No memory state needed in
> >> Thread::currentThread() intrinsic
> >>
> >> http://cr.openjdk.java.net/~vlivanov/8235143/webrev.00/
> >> https://bugs.openjdk.java.net/browse/JDK-8235143
> >>
> >> Thread::currentThread() intrinsic doesn't need memory state:
> >> though multiple threads can execute same code, "current thread" can't
> >> change in the context of a single method activation. So, once it is
> >> observed, it's safe to share among all users.
> >>
> >> One of the use cases which benefit a lot from such optimization is
> >> ownership checks for thread confined resources (fast path check for
> >> owner thread to avoid heavy-weight synchronization).
> >>
> >> The patch was part of foreign-memaccess branch in Project Panama and
> >> showed good performance results on Memory Access API
> implementation
> >> [1].
> >>
> >> Testing: tier1-4
> >>
> >> PS: the optimization should be disabled in Project Loom: the assumption
> >> doesn't hold for continuations (in their current form).
> >>
> >> Best regards,
> >> Vladimir Ivanov
> >>
> >> [1] https://openjdk.java.net/jeps/370
> >>       JEP 370: Foreign-Memory Access API (Incubator)