RFR: 8157023: Integrate NMT with JFR

[Erik Gahlin]

On Thu, 1 Dec 2022 13:22:42 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

>> I agree, it would have been best if just one snapshot could have been used, but as you say the current infrastructure doesn't really support that. What we could do is to use the same event-type for total as for the parts and just let it have the "Memory Type" "Total", but that also feels kind of like a hack. I also agree that the difference should be small, but it might make sense to add a release note or something stating this information. 
>> 
>> I would really like the events to be fine grained and I think that would make us more forward compatible and it would support more use cases. When it comes to out of the box visualization I don't think there will be any, it will be up to however consumes the JFR/NMT data.
>
> 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.

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

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