Assert number of allocations on critical flows

[shakuzen]

It would be nice if we can add tests and assertions about allocations to avoid more allocations than necessary on the critical path where invocations may be very frequent.

Originally posted by @shakuzen in https://github.com/micrometer-metrics/micrometer/issues/3193#issuecomment-1145674995

[jjank]

@shakuzen I've recently stumbled across jfrunit, Gunnar Morling has a blog post about exactly this topic - detecting an increase in memory allocation.

I haven't played with it myself but it might be a place to start with such tests 🤷

[shakuzen]

@jjank Thanks for sharing. That does sound promising. I haven't had a chance since creating this issue to work on it, so if it is something you're interested in doing and you have the time, feel free to open a pull request with a proposal. You can start with something small so we can review the approach. No problem if you don't get to it either.

[jjank]

@shakuzen in case I actually find time for this:

What would be a good place to start / which code paths are especially allocation-sensitive?

[shakuzen]

The recording of metrics is the hottest path. So a counter increment or timer record call.

Next would be creating/retrieving a meter from the registry. Creation will be more costly, but subsequent calls to register should return already created meters. If all tag values are known up front, a reference to the Meter can be kept which makes the creation a one-time cost and thus not a particularly hot path. However, dynamic meters are typically created/retrieved when recording since the tag values aren't constant. This involves a Builder intermediate so there will be allocations due to that.

[shakuzen]

I just remembered I started writing up some info about the criticality of different code paths and choices made in this wiki.