RFC (M): Purge ShenandoahVerifyReadsToFromSpace

Aleksey Shipilev ashipile at redhat.com
Mon Apr 17 17:08:32 UTC 2017


Hi,

I was looking into our mprotect verification mechanics, and had the suspicion
that verifying reads from from-space is dubious. Mostly because we do have
legitimate cases where we strip read barriers and can do from-space reads
without breaking semantics (e.g. final fields).

This seems to be partially catered by emitting more read barriers when
ShenandoahVerifyReadsToFromSpace is enabled? It is double-dubious to me that
verification code adds new barriers, thus hiding the potential issues.

Therefore, I propose we purge the VerifyReads part:
  http://cr.openjdk.java.net/~shade/shenandoah/purge-verifyreads/webrev.01/

Or maybe there is some legitimate use that outweights the costs?

Testing: hotspot_gc_shenandoah

Thanks,
-Aleksey

P.S. VerifyWrites part, on the other hand, enforces very strong tospace
invariant, and thus look salvageable if we somehow manage to accept fwdptr writes.



More information about the shenandoah-dev mailing list