RFR: 8316180: Thread-local backoff for secondary_super_cache updates
Aleksey Shipilev
shade at openjdk.org
Fri Sep 15 17:01:14 UTC 2023
On Wed, 13 Sep 2023 14:02:19 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:
> Work in progress, submitting for broader attention.
>
> See more details in the bug and related issues.
>
> This is the attempt to mitigate [JDK-8180450](https://bugs.openjdk.org/browse/JDK-8180450), while the more complex fix that would obviate the need for `secondary_super_cache` is being worked out. The goal for this fix is to improve performance in pathological cases, while keeping non-pathological cases out of extra risk, *and* staying simple enough and reliable for backports to currently supported JDK releases.
>
> This implements the mitigation for AArch64 and x86_64. More platforms can be implemented in this PR, or deferred to later PRs. Port maintainers, feel free to suggest the patches for your arches, I'll be happy to fold them in.
>
> Note that the code is supposed to be rather compact, because it is inlined in generated code. That is why, for example, we cannot easily do x86_32 version: we need a thread, so the easiest way would be to call into VM. But we cannot that easily: the code blowout would make some forward branches in external code non-short. I think we we cannot implement this mitigation on some architectures, so be it, it would be a sensible tradeoff for simplicity.
>
> Setting backoff at `0` effectively disables the mitigation, and gives us safety hatch if something goes wrong.
>
> Current PR deliberately sets backoff at `1000` to simplify testing. The actual value should be chosen by broader experiments.
>
> Additional testing:
> - [x] Linux x86_64 fastdebug, `tier1 tier2 tier3`
> - [x] Linux AArch64 fastdebug, `tier1 tier2 tier3`
Motivational improvements for new benchmark shows that `contended` case improves a lot the larger backoff values we set, and `uncontended` does not regress.
$ make test TEST=micro:SecondarySuperCache TEST_VM_OPTS="-XX:+UnlockExperimentalVMOptions -XX:SecondarySuperMissBackoff=..."
== AArch64 (Mac M1, 10 cores)
# SecondarySuperMissBackoff=0 (current JDK)
SecondarySuperCache.contended avgt 15 956,819 ± 26,373 ns/op
SecondarySuperCache.uncontended avgt 15 2,797 ± 0,111 ns/op
# SecondarySuperMissBackoff=1
SecondarySuperCache.contended avgt 15 401,065 ± 144,172 ns/op
SecondarySuperCache.uncontended avgt 15 2,763 ± 0,077 ns/op
# SecondarySuperMissBackoff=10
SecondarySuperCache.contended avgt 15 45,953 ± 24,371 ns/op
SecondarySuperCache.uncontended avgt 15 2,787 ± 0,096 ns/op
# SecondarySuperMissBackoff=100
SecondarySuperCache.contended avgt 15 17,581 ± 2,910 ns/op
SecondarySuperCache.uncontended avgt 15 2,771 ± 0,084 ns/op
# SecondarySuperMissBackoff=1000
SecondarySuperCache.contended avgt 15 7,841 ± 0,413 ns/op
SecondarySuperCache.uncontended avgt 15 2,739 ± 0,010 ns/op
# SecondarySuperMissBackoff=10000
SecondarySuperCache.contended avgt 15 6,780 ± 0,082 ns/op
SecondarySuperCache.uncontended avgt 15 2,781 ± 0,045 ns/op
=== x86_64 (Xeon, 18 cores)
Benchmark Mode Cnt Score Error Units
# SecondarySuperMissBackoff=0 (current JDK)
SecondarySuperCache.contended avgt 15 2380.915 ± 159.350 ns/op
SecondarySuperCache.uncontended avgt 15 9.165 ± 0.017 ns/op
# SecondarySuperMissBackoff=1
SecondarySuperCache.contended avgt 15 1523.914 ± 19.694 ns/op
SecondarySuperCache.uncontended avgt 15 9.173 ± 0.026 ns/op
# SecondarySuperMissBackoff=10
SecondarySuperCache.contended avgt 15 736.271 ± 6.554 ns/op
SecondarySuperCache.uncontended avgt 15 9.169 ± 0.039 ns/op
# SecondarySuperMissBackoff=100
SecondarySuperCache.contended avgt 15 254.527 ± 3.167 ns/op
SecondarySuperCache.uncontended avgt 15 9.175 ± 0.053 ns/op
# SecondarySuperMissBackoff=1000
SecondarySuperCache.contended avgt 15 91.392 ± 1.006 ns/op
SecondarySuperCache.uncontended avgt 15 9.172 ± 0.025 ns/op
# SecondarySuperMissBackoff=10000
SecondarySuperCache.contended avgt 15 67.798 ± 0.575 ns/op
SecondarySuperCache.uncontended avgt 15 9.173 ± 0.047 ns/op
-------------
PR Comment: https://git.openjdk.org/jdk/pull/15718#issuecomment-1721574298
More information about the hotspot-dev
mailing list