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

[John Rose]

Looks good, although it’s a little more complicated to read.

It makes me wonder what’s wrong with the various overloadings
of GraphKit::make_load, that you have to open-code a special call.
If this happens a lot, we should try to figure out a new way to call
GK::make_load.  I would have thought there would be an adr_idx
value for C->immutable_memory!

Feeding from immutable_memory will probably be a good thing to
do in more circumstances as we get more reliably immutable data.

— John

> On Dec 5, 2019, at 4:43 AM, Vladimir Ivanov <vladimir.x.ivanov at oracle.com> wrote:
> 
> 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)