[15] RFR 8239926: Shenandoah: Shenandoah needs to mark nmethod's metadata

[Zhengyu Gu]

Traversal GC has the same issue, also need to remark on stack code roots 
in final traversal.

@@ -263,11 +263,12 @@
      if (!_heap->is_degenerated_gc_in_progress()) {
        ShenandoahTraversalRootsClosure roots_cl(q, rp);
        ShenandoahTraversalSATBThreadsClosure tc(&satb_cl);
        if (unload_classes) {
          ShenandoahRemarkCLDClosure remark_cld_cl(&roots_cl);
-        _rp->strong_roots_do(worker_id, &roots_cl, &remark_cld_cl, 
NULL, &tc);
+        MarkingCodeBlobClosure code_cl(&roots_cl, 
CodeBlobToOopClosure::FixRelocations);
+        _rp->strong_roots_do(worker_id, &roots_cl, &remark_cld_cl, 
&code_cl, &tc);
        } else {
          CLDToOopClosure cld_cl(&roots_cl, ClassLoaderData::_claim_strong);
          _rp->roots_do(worker_id, &roots_cl, &cld_cl, NULL, &tc);
        }
      } else {


Updated webrev: http://cr.openjdk.java.net/~zgu/JDK-8239926/webrev.01/

Thank,

-Zhengyu

On 2/25/20 12:13 PM, Zhengyu Gu wrote:
> Shenandoah encounters a few test failures with tools/javac. Verifier 
> catches unmarked oops in nmethod's metadata during root evacuation in 
> final mark phase.
> 
> The problem is that, Shenandoah marks on stack nmethods in init mark 
> pause, but it does not mark nmethod's metadata during concurrent mark 
> phase, when new nmethod is about to be executed.
> 
> The solution:
> 1) Use nmethod_entry_barrier to keep nmethod's metadata alive when the 
> nmethod is about to be executed, when nmethod entry barrier is supported.
> 
> 2) Remark on stack nmethod's metadata at final mark pause.
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8239926
> Webrev: http://cr.openjdk.java.net/~zgu/JDK-8239926/webrev.00/
> 
> Test:
>    hotspot_gc_shenandoah (fastdebug and release)
>    tools/javac with ShenandoahCodeRootsStyle = 1 and 2 (fastdebug and 
> release)
> 
> Thanks,
> 
> -Zhengyu