Status Update
No update yet.
Comments
ap...@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.
na...@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!
dw...@gmail.com
It counts the benchmarked code + allocations incurred by its associated data structures (a.k.a. the implementation detail).
Description
Component used: macrobenchmark 1.2.0-beta01
TraceSectionMetricqueries the trace sections across the whole system. This is probably fine for custom sections that you write for your app, but let's say you'd want to measure how longCompiling %sections take to measure how much JIT happens during startup and have that results for tuning Baseline Profiles.You might get some sections that are not part of the target app.
Can we add something like
useOnlyTargetPackage: Booleanoptional parameter that would add filtering similar to whatFrameTimingMetricdoes?