RFR (S) 8225357: Rewire ShenandoahHeap::maybe_update_with_forwarded for contending fixups

Aleksey Shipilev shade at redhat.com
Thu Jun 6 16:41:43 UTC 2019


Currently the method can return NULL on the path where something else is contending over the write.
In most current cases, that path works correctly, but not when something else (for example, inline
fixup in barrier taken by Java thread) updates the references on their own.

Then, the CAS might fail (as it should), and the GC code would think that thread is responsible to
show the object to the marking code. This is risky and would lead to bugs. Instead, we would want to
reply with the most actual reference at all times.


Testing: hotspot_gc_shenandoah


-------------- 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-gc-dev/attachments/20190606/4a5c4fbf/signature.asc>

More information about the hotspot-gc-dev mailing list