RFR: JDK-8206457: Code paths from oop_iterate() must use barrier-free access
Roman Kennke
rkennke at redhat.com
Fri Jul 6 14:46:59 UTC 2018
We have several code paths going out from oop_iterate() methods that
lead to GC barriers. This is not only inefficient but outright wrong.
oop_iterate() is normally used by GC and GC need to see the raw stuff,
not some resolved objects. In Shenandoah's full-GC it's fatal to attempt
to read objects's forwarding pointers, because it's temporarily pointing
to nowhere land.
I propose to selectively use _raw() variants of the various accessors
that are used on oop_iterate() paths. This means to introduce an
oopDesc::int_field_raw(). I also propose to change metadata_field()
accessors to always use raw access wholesale. This is only used to load
the Klass* field, which is immutable and thus doesn't require barriers.
The log_* statements in instanceRefKlass.inline.hpp surely don't need
barriers. I turned them into raw accessors as well.
Bug:
https://bugs.openjdk.java.net/browse/JDK-8206457?filter=-1
Webrev:
http://cr.openjdk.java.net/~rkennke/JDK-8206457/webrev.00/
Test: passes hotspot-tier1 here.
Can I please get review?
Roman
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: OpenPGP digital signature
URL: <https://mail.openjdk.org/pipermail/hotspot-gc-dev/attachments/20180706/03cbda58/signature.asc>
More information about the hotspot-gc-dev
mailing list