[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