RFR: Fix ResolveMethodTable for Shenandoah

[Aleksey Shipilev]

On 07/13/2017 08:57 PM, Roman Kennke wrote:
> Am 13.07.2017 um 17:30 schrieb Aleksey Shipilev:
>> Hi,
>>
>> I have read the ResolveMethodTable changeset that seem to cause bugs from
>> yesterday:
>> http://mail.openjdk.java.net/pipermail/shenandoah-dev/2017-July/002966.html
>>
>> ...and here are the fixes:
>>   http://cr.openjdk.java.net/~shade/shenandoah/rmt-fixes/webrev.01/
>>
>> The actual fix for test failure is SATB part: this is why ResolvedMethodName got
>> unmarked on some paths. Barriers are added on theoretical grounds.
>>
>> Testing: hotspot_gc_shenandoah, jcstress -m quick
>>
>> Thanks,
>> -Aleksey
>>
> Great! Please push!
> 
> If you have *any* idea how to catch this earlier/better... that would
> help a ton. OTOH, we do already have lots of checking stuff, and with
> Erik Ö's barrier set refactoring, life should become easier still...

Verifier, as it should, helped to pinpoint the exact pair of source -> dst thing
that was broken. From that on, just carefully reading to code around
ResolvedMethodName handling.

I can't yet come up with a plausible way to capture this automatically, short of
intercepting all movptrs and verifying to-space heap reads with explicit checks.
(Good luck doing that without touching registers though).

-Aleksey