RFR(xs): 8227031: Print NMT statistics on fatal errors

Baesken, Matthias matthias.baesken at sap.com
Tue Jul 9 07:15:20 UTC 2019

Hi Thomas,   In wonder  about  the following :

MemTracker::final_report   is called also from  print_statistics()  :

void print_statistics() {
353  // Native memory tracking data
354  if (PrintNMTStatistics) {
355    MemTracker::final_report(tty);
356  }

Would this mean  that when  called  before  from  print_statistics() , we would not call it again  from vmError because of the  g_final_report_did_run  check ?


179 static volatile bool g_final_report_did_run = false;
180 void MemTracker::final_report(outputStream* output) {
181   // This function is called during both error reporting and normal VM exit.
182   // However, it should only ever run once.  E.g. if the VM crashes after
183   // printing the final report during normal VM exit, it should not print
184   // the final report again. In addition, it should be guarded from
185   // recursive calls in case NMT reporting itself crashes.
186   if (Atomic::cmpxchg(true, &g_final_report_did_run, false) == false) {
187     NMT_TrackingLevel level = tracking_level();
188     if (level >= NMT_summary) {
189       report(level == NMT_summary, output);
190     }
191   }
192 }

Is  this really what we want ?   Of course we want to avoid printing it twice (or more than that ) from error reporting.
But I think we would miss it from error reporting in some situations when we want it there .

Otherwise looks okay to me .

Best regards, Matthias

>Hi all,
>We have -XX:+-PrintNMTStatistics, a very useful switch which will cause the
>VM to print out the NMT statistics if the VM exits normally.
>Currently it does not work if the VM exits due to a fatal error. But
>especially in fatal exits due to native OOM a NMT report would be very
>JBS: https://bugs.openjdk.java.net/browse/JDK-8227031
>Changes in this patch:
>- handle PrintNMTStatistics on fatal error
>- make sure the final report is not called twice accidentally and it is not
>called recursively due to secondary error handling
>- change the Metaspace report portion of the NMT report to only include the
>brief metaspace report - that one can be called at any time, it does not
>lock nor require any resources.
>Please note: this will not work when we are in an OOM situation and request
>a detailed NMT report; that scenario needs more work since NMT detailed
>reports need memory as well. That is a separate issue.

More information about the hotspot-runtime-dev mailing list