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