RFR(S): 8224580: Matcher can cause oop field/array element to be reloaded
rkennke at redhat.com
Wed May 29 20:31:11 UTC 2019
> 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.
> 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:
>> (8224584: Shenandoah: Eliminate forwarding pointer word)
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 833 bytes
Desc: OpenPGP digital signature
More information about the hotspot-compiler-dev