Status Update
Comments
du...@google.com <du...@google.com> #2
After some review and discussion with ART, it doesn't appear that there's any issue with tracking our allocations as such, but it can happen that allocations we request don't occur due to optimizations at compilation time.
We may need a black hole, e.g. passing objects to JNI to ensure it's not optimized out.
ap...@google.com <ap...@google.com> #3
Is there any documentation on the specifics of Microbenchmark allocation tracking? Is it counting just the Java allocs in the benchmarked code or is its 'count' also including allocs that occur via any associated DSOs underneath? (I'm inferring that this is what this ticket was originally about - apologies if I've misunderstood)
Essentially, I'd like to know whether it's possible to identify/collect allocs from invoking a Java entry-point method which subsequently calls through to some underlying DSO (inclusive of the allocations within that DSO). Macrobenchmarks seem too heavyweight with regard to this. Is there a specific mode, for the Runner say, that identifies this? As I say, some details on this would be useful. Thanks!
Description
- benchmark instrumentation runner default
- disabling code coverage
- changing test output APK name
Consider instead
androidx {
...
isBenchmark = true
}
Or
plugins {
id("AndroidXBenchmarkPlugin")
}
The latter could also help with
Could also investigate controlling debug in a similar way, but we need to keep it easy to toggle for perf tools.