RFC (M): Purge ShenandoahVerifyReadsToFromSpace

[Roman Kennke]

> Ping.
> 
> On 04/17/2017 07:08 PM, Aleksey Shipilev wrote:
>> 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.
>>
> 

I am all for purging the VerifyReads part, it has never been very
useful, for the reasons you mention.

While VerifyWrites is more useful, it is also very suspicious, because
we need to unprotect from-space all the time during evac, only to poke
in the new brooks ptrs. And since this is not possible to do
thread-local (unless you've got special-feature-kernel stuff which,
iirc, Intel did for one of their new processors a while ago), we open up
the doors for plenty of from-space-writes to slip through. The
compiler-generated verification code for stores is more helpful (but
depends on us first having to find all the places where compilers
generate stores, which sortof defeats the purpose too).

Maybe wait for Christine to voice her opinions too.

Roman