RFR: 8316180: Thread-local backoff for secondary_super_cache updates [v11]
Fei Yang
fyang at openjdk.org
Wed Oct 18 07:14:51 UTC 2023
On Tue, 17 Oct 2023 14:10:27 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`
>
> Aleksey Shipilev has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 22 additional commits since the last revision:
>
> - Merge branch 'master' into JDK-8316180-backoff-secondary-super
> - Touchup benchmark metadata
> - S390 implementation
> - Merge branch 'master' into JDK-8316180-backoff-secondary-super
> - Correct type for flag
> - Option is diagnostic, platform-dependent
> - Merge branch 'master' into JDK-8316180-backoff-secondary-super
> - Init with backoff right away
> - x86 cleanup
> - Denser AArch64
> - ... and 12 more: https://git.openjdk.org/jdk/compare/7fc0b6b7...8dd00325
RISC-V implementation:
[15718-riscv.txt](https://github.com/openjdk/jdk/files/12995775/15718-riscv.txt)
JMH data on hifive unmatched board for reference:
-XX:SecondarySuperMissBackoff=0
Benchmark Mode Cnt Score Error Units
SecondarySuperCache.contended avgt 15 511.595 ? 35.062 ns/op
SecondarySuperCache.uncontended avgt 15 73.155 ? 8.891 ns/op
-XX:SecondarySuperMissBackoff=10
Benchmark Mode Cnt Score Error Units
SecondarySuperCache.contended avgt 15 200.010 ? 17.197 ns/op
SecondarySuperCache.uncontended avgt 15 73.766 ? 9.232 ns/op
-XX:SecondarySuperMissBackoff=100
Benchmark Mode Cnt Score Error Units
SecondarySuperCache.contended avgt 15 167.544 ? 17.544 ns/op
SecondarySuperCache.uncontended avgt 15 68.551 ? 5.460 ns/op
-XX:SecondarySuperMissBackoff=1000
Benchmark Mode Cnt Score Error Units
SecondarySuperCache.contended avgt 15 156.470 ? 21.725 ns/op
SecondarySuperCache.uncontended avgt 15 72.963 ? 9.210 ns/o
-XX:SecondarySuperMissBackoff=10000
Benchmark Mode Cnt Score Error Units
SecondarySuperCache.contended avgt 15 162.363 ? 14.920 ns/op
SecondarySuperCache.uncontended avgt 15 75.536 ? 11.916 ns/op
-------------
PR Comment: https://git.openjdk.org/jdk/pull/15718#issuecomment-1767811133
More information about the hotspot-dev
mailing list