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