RFR: Elastic TLABs for Shenandoah

[Aleksey Shipilev]

On 07/12/2018 07:17 PM, Roman Kennke wrote:
> Does it have any performance impact?

On most benchmarks that run with decently-sized heaps, it does not. This is the flip side of our
earlier decision to go with TLAB trimming hack: it did not affect allocation performance
substantially, so the reversal has the same non-substantial effect.

On allocation torture tests, though, we have immense improvements, because having 8x larger max
TLABs is not something to frown about:

Benchmark                           (size)  Mode  Cnt       Score      Error   Units

# -XX:-ShenandoahElasticTLAB
IntArray.test                       10000  avgt    5    1294.432 ±   22.439   ns/op
IntArray.test:·gc.alloc.rate        10000  avgt    5  429188.240 ± 7100.911  MB/sec
IntArray.test:·gc.churn.Shenandoah  10000  avgt    5  429916.078 ± 3291.589  MB/sec
IntArray.test:·gc.count             10000  avgt    5     240.000             counts
IntArray.test:·gc.time              10000  avgt    5    1712.000                 ms

# -XX:+ShenandoahElasticTLAB
IntArray.test                       10000  avgt    5      197.233 ±     0.930   ns/op
IntArray.test:·gc.alloc.rate        10000  avgt    5  2815814.234 ± 17601.432  MB/sec
IntArray.test:·gc.churn.Shenandoah  10000  avgt    5  2815938.878 ± 34226.391  MB/sec
IntArray.test:·gc.count             10000  avgt    5     1516.000              counts
IntArray.test:·gc.time              10000  avgt    5    10819.000                  ms

Thanks,
-Aleksey