RFR(S): 8224580: Matcher can cause oop field/array element to be reloaded

[Roman Kennke]

> It seems to do what you want, but I'm curious, what's the worse that can
> happen if we call set_shared() on a node that doesn't need it?

What would that be?

set_shared() has been there before the change, but only if it's preceded
by an address. The only case where this is different is loads from
offset==0, in other words, loads of the mark-word. That would be locking
code (which needs stricter access, e.g. volatile, anyway) or hashcode,
as far as I can tell. In other words, the worst that can happen is that
hashcode is not reloaded, where it could have been reloaded before?
Doesn't sound like a problem to me.

However, reloading in case of Shenandoah's barrier is a severe
*correctness* problem. And a fairly nasty one too.

Roman


> dl
> 
> On 5/27/19 4:57 AM, Roland Westrelin wrote:
>>> The change looks reasonable to me.
>>>
>>> I have run tests with the patch and can confirm that the original bug
>>> went away. I've also run a bunch of other tests and workloads and looks
>>> good too.
>> Thanks Roman. Anyone else for this?
>> Shenandoah needs this for a key change that's also out for review:
>>
>> https://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2019-May/025931.html
>>
>> (8224584: Shenandoah: Eliminate forwarding pointer word)
>>
>> Roland.
> 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <https://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20190529/ad556c1b/signature.asc>