Fix jvm classes semantic conventions

[jack-berg]

What are you trying to achieve?
The jvm classes semantic conventions aren't quite right:

• process.runtime.jvm.classes.loaded - up down counter: number of currently loaded classes. equal to total loaded + total unloaded since application start.
• process.runtime.jvm.classes.unloaded - up down counter: number of total classes unloaded since application start.

The metrics are asymmetric in that one reflects the current while the other reflects the total. The current is necessarily an up down counter. The total is monotonically increasing and can thus be a counter, but is marked as an up down counter so it can be consistent with the current metric.

What did you expect to see?

More consistency and better adherence to recommended instrument types. Let's do the following instead:

• process.runtime.jvm.classes.loaded - counter: number of total classes loaded since application start.
• process.runtime.jvm.classes.unloaded - counter: number of total classes unloaded since application start.
• process.runtime.jvm.classes.current_loaded - up down counter: number of classes currently loaded. Under stable conditions, this is equal to loaded - unloaded. However, we can't atomically collect loaded and unloaded so most accurate to report this separately. Also, since up down counters always export as cumulative, users will always have a cumulative "current" count of classes loaded in the JVM, regardless of whether their backend is cumulative or delta. Nice.

Additional context.

We discussed and agreed on this solution in the Java JVM runtime working group.

[Oberon00]

However, we can't atomically collect loaded and unloaded

Is this a limitation of the JVM, or of the metric API? API-wise, I think you'd need something like the old BatchObserver / BatchRecorder to record multiple metrics atomically (not sure what the state is here in the new one).

[carlosalberto]

SGTM - @jmacd maybe has something to say.

[bogdandrutu]

Also, since up down counters always export as cumulative

This is not true, the "always" part.

[jack-berg]

This is not true, the "always" part.

You're correct, typically is more accurate.

Is this a limitation of the JVM, or of the metric API?

Limitation of the JVM. The ClassLoadingMXBean has separate methods for accessing loading and unloaded, so changes can take place between successive calls.