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

[Vladimir Ivanov]

Thanks for review, John.

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

Yes, it looks appealing, but there are some cases which need special 
handling. For example, it doesn't respect instance initialization which 
can manifest as observing partially constructed instance.

Best regards,
Vladimir Ivanov

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