RFR (S): 8248221: G1: millis_since_last_gc updated at wrong time

Thomas Schatzl thomas.schatzl at oracle.com
Thu Jun 25 08:04:09 UTC 2020


Hi all,

   can I have reviews for this change that fixes the location at which 
the millis_since_last_gc timestamp is updated.

The spec of the only user in sun.rmi.transport.GC.maxObjectInspectionAge 
says:

* Returns the maximum <em>object-inspection age</em>, which is the number
* of real-time milliseconds that have elapsed since the
* least-recently-inspected heap object was last inspected by the garbage
* collector.

Currently we do that update only at young gc, which is wrong. We should 
do that if/when a complete liveness analysis cycle has finished instead, 
i.e. end of marking/end of full gc.

I did some testing using the TestMillisSinceLastGC.java jtreg test in 
http://cr.openjdk.java.net/~tschatzl/8248221/webrev.test/. As expected, 
it failed for G1 but all other GCs tested there pass (Epsilon will 
probably also fail, because it never does any gc so I did not even try).

However the test intrinsically depends on timing i.e. the duration 
between some GC and checking the CollectedHeap::millis_since_last_gc() 
result, so I did not add it to this webrev. While in my ci testing it 
did not fail, I deemed it too risky to add.
I also eyeballed that the output is still reasonable (i.e. no unit 
problem introduced by 8165501) using its log output for all affected 
collectors.

Depends on 8243974.

CR:
https://bugs.openjdk.java.net/browse/JDK-8248221
Webrev:
http://cr.openjdk.java.net/~tschatzl/8248221/webrev/
Testing:
tier1-5 with 8243974 and 8165501, manual testing as described above.

Thanks,
   Thomas



More information about the hotspot-gc-dev mailing list