Tweak native allocation GC triggering thresholds
There is some evidence that collecting more frequently for small Java heap apps sometimes causes problems. Relative to the original P state, we should now collect less frequently, if we are either at the beginning of a Java GC cycle, or the Java heap is large. Otherwise, we should be similar to the original, modulo accounting changes. Report a better cause if native allocation ends up waiting for the GC. Increase kNotifyNativeInterval on host, since mallinfo() cost appears to be the cause of a Kotlin benchmark regression on host. Increase kHugeNativeAllocs enough so that we should normally never block for a GC we trigger. It looks like 175-alloc-big-bignums still passes on walleye in spite of this, but we may have to disable that test on target if it becomes flakey. Bug: 121052300 Bug: 121039645 Bug: 122099093 Test: Treehugger, art/test/testrunner/testrunner.py --host --64 -t 175-alloc-big-bignums Change-Id: I6fbd107d4a2519225f628f2c1f96dad034849d12
Loading
Please sign in to comment