RFR: Support VerifyBeforeGC and VerifyAfterGC VM options

Aleksey Shipilev shade at redhat.com
Sat Oct 20 09:13:35 UTC 2018


On 10/20/2018 02:24 AM, Zhengyu Gu wrote:
>> But why final-evac? I think should be final-mark.

When cycle coalesces UR with next cycle mark, the final VMOp is final-evac. But you are right too:
when cycle shortcuts, the final VMOp is final-mark. The block in op_final_mark does not make it all
too obvious, I shall fix it up in a follow-up.

>> Webrev: http://cr.openjdk.java.net/~zgu/shenandoah/verify_before_after_gc/webrev.01/index.html
>>
> Passed tier3_gc_shenandoah and  gc/TestVerifySubSet.java
> (fastdebug and release)

I still think putting things near ShenandoahVerify is more straightforward. First, we are guaranteed
to run in the same conditions as Verifier (i.e. at safepoint), and Verifier has a chance to run
first when all verification is enabled. This also avoids accidentally placing ::verify in concurrent
ops, as in your patch in op_updaterefs().

See:
  http://cr.openjdk.java.net/~shade/shenandoah/verify-beforeafter/webrev.01/

This passes tier3_gc_shenandoah (fastdebug|release) and gc/TestVerifySubSet.java. I can push it for you.

Thanks,
-Aleksey





More information about the shenandoah-dev mailing list