Status Update
No update yet.
Comments
cc...@google.com
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.
cc...@google.com
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
We should also make sure that the BenchmarkPlugin correctly sets release { isDefault = true } to ensure that the default build variant when running benchmarks in studio is also "release". Otherwise, conflicting testBuildType in Gradle and build variant set int Studio will cause benchmarks to fail to compile.