RFR: JDK-8211279: Verify missing object equals barriers

Roman Kennke rkennke at redhat.com
Mon Oct 1 12:48:40 UTC 2018


Hi Per,


>> GCs like Shenandoah require an extra barrier for comparing objects
>> (oop==oop). It is easy to forget or overlook this. It would be very
>> useful to have a flag to turn on extra verification that catches missing
>> object equality barriers.
>>
>> This change inserts an assert into == and != operators for the oop class
>> in oopsHierarchy.hpp. This only gets compiled in fastdebug builds (when
>> CHECK_UNHANDLED_OOPS is on).
>>
>> It also adds a develop flag VerifyObjectEquals that is used to turn on
>> this verification.
>>
>> It also adds a method oopDesc::unsafe_equals(..) to be used in cases
>> where you know what what you are doing, and really want to use direct ==
>> comparison without using barriers. This is used in e.g.
>> ReferenceProcessor or all over the place in ShenandoahGC.
>>
>> The change also fixes a couple of places where oops are compared to
>> non-oops like Universe::non_oop_word() to use the oop==void* operator
>> instead, so those don't falsely trip the verification.
>>
>> It doesn't make sense to turn this check on if you're not running a GC
>> that needs it, unless you want to go fix all the oop==oop in the GC
>> itself.
>>
>> Bug:
>> https://bugs.openjdk.java.net/browse/JDK-8211279
>> Webrev:
>> http://cr.openjdk.java.net/~rkennke/JDK-8211279/webrev.00/
>>
>> What do you think?
> 
> So this means we would have a verification option that, when enabled,
> always crashes the VM unless you run Shenandoah? That doesn't sound
> quite right to me. This should just be a noop when not using Shenandoah,
> don't you think?


Hmm, right. Let's add some BarrierSet-infrastructure to handle this, and
remove the option (it would be a GC-'private' option). It would probably
have looked slightly better to do this in BarrierSet::Access, next to
the Access::equals() API, but I don't feel like adding tons of
boilerplate just to add this. (Infact, this is a big red warning signal
regarding the Access API...)

http://cr.openjdk.java.net/~rkennke/JDK-8211279/webrev.01/

How does this look now?

It still passes hotspot/jtreg:tier1 here.

Thanks for looking at this!
Roman

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/attachments/20181001/172a2dda/signature.asc>


More information about the hotspot-gc-dev mailing list