RFR (S): Enable ShenandoahConcurrentCodeRoots

[Aleksey Shipilev]

Hi,

While investigating the cause for the bimodal behavior for Init-Mark:

 [14.162s][info][gc] GC(1) Pause Init-Mark 3.810ms
 [17.943s][info][gc] GC(2) Pause Init-Mark 3.327ms
 [20.599s][info][gc] GC(3) Pause Init-Mark 3.442ms
 [22.953s][info][gc] GC(4) Pause Init-Mark 0.819ms
 [25.357s][info][gc] GC(5) Pause Init-Mark 2.861ms
 [27.838s][info][gc] GC(6) Pause Init-Mark 3.013ms
 [30.602s][info][gc] GC(7) Pause Init-Mark 3.440ms
 [33.417s][info][gc] GC(8) Pause Init-Mark 3.113ms
 [36.279s][info][gc] GC(9) Pause Init-Mark 0.838ms
 [39.098s][info][gc] GC(10) Pause Init-Mark 3.264ms
 [41.880s][info][gc] GC(11) Pause Init-Mark 2.713ms
 [44.635s][info][gc] GC(12) Pause Init-Mark 2.832ms
 [47.135s][info][gc] GC(13) Pause Init-Mark 2.876ms
 [49.514s][info][gc] GC(14) Pause Init-Mark 0.856ms

...found that scanning code cache when class_unload=false takes a few
milliseconds. Then discovered ShenandoahConcurrentCodeRoots, which scans the
code roots in concurrent marking workers under the CodeCache_lock. Enabling it
seems to help with Init-Mark times!

 before: Initial Mark Pauses (net)   =     0.51 s (a =     2648 us) (n =   193)
    (lvls, us =      686,     2734,     2969,     3125,     4058)

  after: Initial Mark Pauses (net)   =     0.24 s (a =     1173 us) (n =   202)
    (lvls, us =      752,     1113,     1172,     1250,     3046)

I cannot see the theoretical problems with enabling it. Both jcstress and
hotspot_gc_shenandoah pass with the flag turned on by default too. So, let's do it:
  http://cr.openjdk.java.net/~shade/shenandoah/codecache-scan/webrev.01/

Thanks,
-Aleksey