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.
ap...@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!
ap...@google.com
It counts the benchmarked code + allocations incurred by its associated data structures (a.k.a. the implementation detail).
Description
There are new flags we can pass to improve method tracing performance, such as
0x10for the wall clock, and we should also look into streaming traces, if that improves performance.As part of this, want to enable measuring cost of method tracing easily with microbenchmark and macrobenchmark.