RFR (S): Shenandoah matrix update barriers should be conditional

Roman Kennke rkennke at redhat.com
Thu Mar 9 17:33:44 UTC 2017


Am 09.03.2017 um 17:30 schrieb Aleksey Shipilev:
> ...otherwise we are contending on matrix updates a lot.
>
> Case in point. Storing the object in different threads to different fields:
>
> Benchmark          Mode  Cnt    Score   Error  Units
>
> # -Xint
> Plain.test_Object  avgt    5  152.070 ± 0.378  ns/op  # baseline
> Plain.test_Object  avgt    5  129.156 ± 6.325  ns/op  # patched
>
> # C1
> Plain.test_Object  avgt    5   42.110 ± 1.008  ns/op  # baseline
> Plain.test_Object  avgt    5    7.693 ± 0.031  ns/op  # patched
>
> # C2
> Plain.test_Object  avgt    5   41.746 ± 0.120  ns/op  # baseline
> Plain.test_Object  avgt    5    6.792 ± 0.109  ns/op  # patched
>
> Patch:
>   http://cr.openjdk.java.net/~shade/shenandoah/matrix-update-cond/webrev.01/
Wow. Yes, of course!
Out of curiousity, how do the numbers look without matrix?
> P.S. I am seriously considering to change bool* to char*, to avoid this C++ bool
> mess.
Please go ahead. If we ever encounter a platform that compiles bool to
more than one byte, our matrix goes through the roof ;-)

Roman



More information about the shenandoah-dev mailing list