RFR: Fast synchronizer root scanning

[Zhengyu Gu]

OK.

-Zhengyu

On 05/10/2017 04:15 PM, Roman Kennke wrote:
> When scanning synchronizer roots, we are scanning everything in
> gBlockList, which, as far as I can tell, are all active monitor blocks
> of all threads, plus any free blocks that have piled up. Doing this
> appears to be quite inefficient.
>
> I have implemented an alternative way to scan synchronizer roots: each
> Thread maintains its own thread-local list of in-use monitors and a
> free-list. The global in-use list is only used for 'moribund' threads. I
> think it is sufficient scan each Thread's local in-use list plus the
> global list. I checked with SPECjvm and jcstress and found no ill
> issues. Performance wise, it looks *much* better:
>
> baseline:
> [14,393s][info][gc,stats]     S: Thread Roots         =     0,34 s (a
> =    37748 us) (n =     9) (lvls, us =    36523,    36523,    36914,
> 37305,    42215)
> [14,393s][info][gc,stats]     S: Synchronizer Roots   =     0,14 s (a
> =    15115 us) (n =     9) (lvls, us =     9746,    10938,    14258,
> 14648,    25847)
> [14,393s][info][gc,stats]     UR: Thread Roots        =     0,22 s (a
> =    24967 us) (n =     9) (lvls, us =    12305,    24219,    25977,
> 27148,    27758)
> [14,393s][info][gc,stats]     UR: Synchronizer Roots  =     0,11 s (a
> =    11906 us) (n =     9) (lvls, us =     8340,     9082,    12109,
> 12695,    13787)
>
> patched:
> [14,293s][info][gc,stats]     S: Thread Roots         =     0,36 s (a
> =    40365 us) (n =     9) (lvls, us =    32031,    32031,    34570,
> 37109,    67224)
> [14,293s][info][gc,stats]     S: Synchronizer Roots   =     0,00 s (a
> =        0 us) (n =     9) (lvls, us =        0,        0,
> 0,        0,        0)
> [14,294s][info][gc,stats]     UR: Thread Roots        =     0,22 s (a
> =    24459 us) (n =     9) (lvls, us =    15820,    20508,    22070,
> 26172,    32573)
> [14,294s][info][gc,stats]     UR: Synchronizer Roots  =     0,00 s (a
> =        0 us) (n =     9) (lvls, us =        0,        0,
> 0,        0,        0)
>
>
> I.e. even though the work of scanning synchronizer roots is added to
> thread roots scanning, thread-roots scanning does not very significantly
> take longer, but sync roots scanning drops to 0 (there's usually nothing
> to do for global in-use list).
>
> I guarded this new behaviour with -XX:+ShenandoahFastSyncRoots, and
> defaulting to false for now. This will allow us to do more testing and
> get feedback from hotspot-runtime-dev, before enabling it by default.
>
> http://cr.openjdk.java.net/~rkennke/fastsyncroots/webrev.00/
> <http://cr.openjdk.java.net/%7Erkennke/fastsyncroots/webrev.00/>
>
> Testing: hotspot_gc_shenandoah, jcstress -m quick, jmh-specjvm
>
> Ok?
>
>