summaryrefslogtreecommitdiff
path: root/compiler/optimizing/code_generator.cc
diff options
context:
space:
mode:
author Vladimír Marko <vmarko@google.com> 2023-01-03 14:31:22 +0000
committer Vladimír Marko <vmarko@google.com> 2023-01-19 14:35:09 +0000
commitc451312e7b766c715bd283ce7278a879f079fbba (patch)
treee5a40d9bf413c10281424471b4ae525ccc6b9d3b /compiler/optimizing/code_generator.cc
parent4a954a57d79e7b07f7d1d58322337e22970501a0 (diff)
Reland "ARM64: Enable implicit suspend checks after CCCR."
This reverts commit 2de08ed613903526279512c7f6114b52cbf5e993. Reason for revert: Reland with app startup performance impact mitigation. Replace `MADV_FREE` with `MADV_DONTNEED` in `Thread::MadviseAwayAlternateSignalStack()`. Some regressions are expected but this change should provide a good trade-off overall. The benefits for memory use thanks to reduced code size can be seen in b/263509016 that tracked the system server RSS regression when we disabled implicit suspend checks the last time. The startup regression b/263319992 has been partially mitigated by https://android-review.googlesource.com/2375891 and is being partially mitigated by using the `MADV_FREE`, see above. Based on some test runs, the `MADV_FREE` roughly halves the regression we would incur with `MADV_DONTNEED`. On the flip side, the `MADV_FREE` does not immediatelly reclaim the committed memory of the alternate signal stacks, so we may see regressions in some memory benchmarks. These regressions would not be true regressions, however, because that memory is indeed reclaimable under memory pressure, so it should be considered as any other temporary allocation. Some Golem micro-benchmarks show significant improvements on Odroid-C2 while showing significant regressions on Raspberry Pi 4 on the very same benchmark. The implicit suspend check is a single LDR while the explicit check is LDR+TST+BNE and it seems reasonable to expect better performance on in-order CPUs due to fewer instructions being executed. However, out-of-order CPUs may prefer the LDR for explicit checks as it uses a "constant" address over the LDR for implicit check which uses the previously loaded value as the the address for the next check, presumably preventing scheduling these LDRs closely together, for example in a tight loop. Test: run-gtests.sh Test: testrunner.py --target --64 --optimizing --jit Bug: 38383823 Bug: 215310343 Change-Id: I274a5417293e6d926579ec97190085387137d7c2
Diffstat (limited to 'compiler/optimizing/code_generator.cc')
0 files changed, 0 insertions, 0 deletions