Decide which JVM metrics should be included in initial stability

[trask]

If we don't want to include some of them in the initial stability we can split them out into a separate section in runtime-environment-metrics.md titled "JVM Metrics (experimental)".

[trask]

The process.runtime.jvm.buffer.* don't seem critical for initial release if we want to leave them out.

[roberttoyonaga]

What do we think about stabilizing the JFR gathered metrics? There's some useful ones like network IO, monitors, etc. But they would only apply to JDK17+.

[trask]

• process.runtime.jvm.memory.usage
• process.runtime.jvm.memory.committed
• process.runtime.jvm.memory.limit (.max?)
• process.runtime.jvm.memory.usage_after_last_gc
• process.runtime.jvm.gc.duration
• process.runtime.jvm.threads.count
• process.runtime.jvm.classes.loaded
• process.runtime.jvm.classes.unloaded
• process.runtime.jvm.classes.current_loaded
• process.runtime.jvm.available_processors
• process.runtime.jvm.cpu.time
• process.runtime.jvm.cpu.utilization -> process.runtime.jvm.cpu.load

these would be nice but .system is confusing under .process (and under .jvm):

• process.runtime.jvm.system.cpu.utilization -> process.runtime.jvm.system.cpu.load
• process.runtime.jvm.system.cpu.load_1m

proposal is to make them opt-in and not include them in stability, and later explore putting them under system.*

No:

• process.runtime.jvm.memory.init
• process.runtime.jvm.buffer.usage
• process.runtime.jvm.buffer.limit
• process.runtime.jvm.buffer.count

[vijaysun-omr]

Could you please clarify the thinking behind process.runtime.jvm.memory.committed being in the "No" list ?

[jack-berg]

I'm in favor of including process.runtime.jvm.memory.committed for initial stability.