JDK-8225215 : gc/logging/TestMetaSpaceLog.java doesn't work for ZGC
  • Type: Bug
  • Component: hotspot
  • Sub-Component: gc
  • Priority: P4
  • Status: Closed
  • Resolution: Won't Fix
  • Submitted: 2019-06-04
  • Updated: 2019-06-05
  • Resolved: 2019-06-05
Related Reports
Relates :  
JDK-8225216 - gc/logging/TestMetaSpaceLog.java doesn't work for Shenandoah
Relates :  
JDK-8212630 - jtreg/gc/logging/TestMetaSpaceLog.java failed with Agent timed out
Description
The test gc/logging/TestMetaSpaceLog.java is disabled (after JDK-8212630) for ZGC because it would fail if run.

I think it's partially a ZGC bug that it doesn't work.  The test expects to find the output from a call to print_metaspace_chage(), but ZGC never calls that function.  (Unless it's intentional that ZGC doesn't call that function and can't pass this test.)

The test also seems to be wrong; it expects "[gc,metaspace" info log messages only of the form produced by print_metaspace_change, but ZGC has ZStatMetaspace::print(), which produces a log message not expected by the test.
Comments
Closing this issue as won't fix, as motivated above.
05-06-2019
ZGC intentionally doesn't call print_metaspace_change(). One reason is that with concurrent class unloading, X and Y are not stable snapshots like they are in the STW case. This makes the X->Y notation tricky and sometimes hard to interpret. For example, X could be smaller than Y, if lots of new classes where loaded while we where unloading a few dead ones. In ZGC we instead just print the current values (in ZStatMetaspace::print()). Another reason is that this function doesn't fit that well into ZGC approach to logging, where we typically gather data (in hot paths) and later print it. print_metaspace_change() doesn't just print data, it also gathers some of it (used_bytes/reserved_bytes) to produce the output.
05-06-2019