RFR: Workaround possible ResolvedMethodTable bug

[Roman Kennke]

Hmmhmm, OK. But we need to understand and fix this soon.

The gotcha is that 'weak' doesn't always mean the same ;-)

Roman

Am 12. Juli 2017 20:25:29 MESZ schrieb Aleksey Shipilev <shade at redhat.com>:
>I *think* there is a bug within a new ResolvedMethodTable machinery,
>coming from
>here:
>  http://hg.openjdk.java.net/jdk10/hs/hotspot/rev/da4c9eef4316
>
>The oops in that table are now weakly reachable, achieved by:
>
>void SystemDictionary::roots_oops_do(OopClosure* strong, OopClosure*
>weak) {
>  ...
>  if (weak != NULL) {
>    ResolvedMethodTable::oops_do(weak);
>  }
>}
>
>But here is a problem: Shenandoah init mark is passing (weak == NULL)
>if
>reference processing is enabled:
>
>  _rp->process_strong_roots(&mark_cl,
>                          _process_refs ? NULL : &mark_cl, // <--- here
>                            &cldCl, &blobsCl, worker_id);
>
>I think "normal" weak references get processed fine, because they will
>get
>registered with ReferenceProcessor, and will get marked if actually
>reachable.
>But not ResolvedMethodNames now! Which makes Verifier barf like this:
>http://cr.openjdk.java.net/~shade/shenandoah/rmt-weak-bug/hs_err_pid25252.log
>
>Notice that ResolvedMethodName is not marked.
>
>Let us work that around for now, until we figure out more:
>  http://cr.openjdk.java.net/~shade/shenandoah/rmt-weak-bug/webrev.01/
>
>This fix makes jcstress pass longer with Shenandoah verification
>enabled.
>
>Thanks,
>-Aleksey

-- 
Diese Nachricht wurde von meinem Android-Gerät mit K-9 Mail gesendet.