I have (perhaps wrongly?) assumed this is something we might want - it's the reason I pulled in Gil's "hdr" histogram: https://github.com/LatencyUtils/LatencyUtils This method is aimed at eliminating a long gc pause's very strong influence on the reported avg/percentiles. Using this method we should add measuring time spent in GC too (can be done, got the beans already), I think?

The default Metrics(library) histograms are based on: https://github.com/dropwizard/metrics/blob/master/metrics-core/src/main/java/com/codahale/metrics/ExponentiallyDecayingReservoir.java#L36 which does another form of  of modifying the data... (comment linked) Metrics also providers others, like `SlidingTimeWindowReservoir` etc.

I guess this comes down to the question what we want from these measurements. If some rough estimate maybe the simplest histogram will do, if "more" then this or other smarter impls, if "really good data" then we'll have to go full JMH I guess. Reimplementing histograms or adding `x > maxMeasureable => ignore` here is an option, but maybe we need a brainstorm on what exactly we need out of this? (there are loads of discussions on mechanical sympathy and one get's to panic "oh god, everything i measure is wrong anyway" in a way...).

Let's talk more in deptht about all this maybe?