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

Doerr, Martin martin.doerr at sap.com
Thu Dec 5 16:13:00 UTC 2019


Hi Vladimir,

looks good to me.

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.

Best regards,
Martin


> -----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)


More information about the hotspot-compiler-dev mailing list