RFR: 8157023: Integrate NMT with JFR

[Stefan Johansson]

On Thu, 1 Dec 2022 16:59:20 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

>> I think we should design the events as if we could take everything in one snapshot. That way, we can improve the implementation later. It would be good to write in the event description of NativeMemoryUsage event that it may not add exactly up to the sum of NativeMemoryUsagePart events due to timing issues.
>> 
>> I will look into adding support for snapshots, but it will have to be a later release.
>
> Today, the call into JVM has the signature JVM::emitEvent(long eventTypeId, long timestamp, long when). If the timestamp is stored in jfr_periodic_timestamp when the call gets into native and the part event is emitted first, then it could look something like this:
> 
> 
> static u8 jfr_periodic_timestamp;
> 
> struct JfrNmtTotal {
>   u8 timestamp;
>   u8 reserved;
>   u8 committed;
> };
> 
> static JfrNmtTotal last_nmt;
> 
> TRACE_REQUEST_FUNC(NativeMemoryUsagePart) {
>    ...
>    last_nmt.timestamp = jfr_periodic_timestamp;
>    last_nmt.reserved = sum of reserved;
>    last_nmt.committed = sum of committed;
> }
> 
> TRACE_REQUEST_FUNC(NativeMemoryUsage) {
>    if (jfr_periodic_timestamp == last_nmt.timestamp) {
>        // use last_nmt
>    } else {
>       // calculate reserved and committed independently
>   }
> }
> 
> 
> Periodic events are run in the same thread.
> 
> I don't know if the order of periodic event is the same as in metadata.xml but it could be fixed. This will handle the case where the events have different periods.

I just realized there is another problem with trying to share the baseline, the events might be configured to have different periods and then sharing will be strange. So step one: document it.

-------------

PR: https://git.openjdk.org/jdk/pull/11449