Re-evaluate all hot-path methods in terms of memory churn: reduce allocations in the hot-path to a minimum and avoid copying static arrays at all costs. Instead pre-initialize static arrays (like buckets, tags, etc) during initialization and re-use it across the board.

Could you please be more specific? Which hot-path are you referring to? Static buckets for timers are already preinitialized. Tags are not static and passed as arguments to report<Something> methods. All array allocations happen only during the initialization of Prometheus collectors, calculation of canonical metric IDs and passing tags values to Prometheues collectors' collect methods. We cannot do much about it unless rewriting the collectors implementations ourself.
If there is something particular in the implementation, which you think can be improved, please be more specific and I'd love to improve it. As a follow up I'm planning to add benchmark tests for all the implementations of Reporter interface, which would give us more clear picture about performance.

+1 to both points--yes we should optimize; doing it as a followup with benchmarks makes reasonable sense to me.

@alexeykudinkin on the benchmarking point--any suggestions on good approaches for profiling allocations/garbage creation?

Instead pre-initialize static arrays (like buckets, tags, etc) during initialization and re-use it across the board.

Good call; we could probably do this kind of thing even in absence of good data (though of course, it'd be hard to tell the impact...).

Nice, thanks for adding these! Could you confirm that they don't flake if you run them multiple times? (I tend to do 1000 if they're fast, 100 if they're slow).

https://stackoverflow.com/questions/1492856/easy-way-of-running-the-same-junit-test-over-and-over suggests just temporarily using a parametrized test for it, or looks like Intellij can just do it in the run config--whatever's easy :)

Nifty!

Nit: why not just throw here? You'll get a better error message out of it by default. Also, it gives you an early return here to reduce nesting:

if (expected == null) {
   throw e
}

// else

Nice, I like this approach.