Bug ID: JDK-8071770 G1 does not implement millis_since_last

Versions (Unresolved/Resolved/Fixed)

The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.

JDK 9
9 b133Fixed

G1 does not return a correct value for the CollectedHeap::millis_since_last_gc which is called from the JVM_MaxObjectInspectionAge, used by the RMI "distributed gc".

This is a day-1 issue in G1 and an implementation should be added for completeness.

ILW=
L, objects may not be garbage collected as regularly as expected
M, likelihood of setting sun.rmi.dgc.{client,server}.gcInterval is unclear, default value is 1h
M, switch to a different GC

Why does G1 use os::elasped_counter() for a timestamp? + jlong now = os::elapsed_counter() / NANOSECS_PER_MILLISEC; elapsed_counter(), particularly on Windows, is not a time value.
16-08-2016
Test files. javac GC.java gcc -D_JNI_IMPLEMENTATION -shared -o GC.so -fPIC -I $JAVA_HOME/include -I $JAVA_HOME/include/linux GC.c java GC
13-07-2016
Updating ILW, since G1 is going to be default for JDK 9. ILW= M, objects may not be garbage collected as regularly as expected M, likelihood of setting sun.rmi.dgc.{client,server}.gcInterval is unclear, default value is 1h H, No workaround for G1 => P3
19-04-2016
Adding some comments here based on a conversation with Kirk Pepperdine and Charlie Hunt. These comments kind of step back and ask a few questions which might influence the default behavior for System.gc() under G1. One might step back and ask if the default behavior under G1 for a call to System.gc() would be to initiate a G1 concurrent cycle. In other words, this would imply making -XX:+ExplicitGCInvokesConcurrent the default for G1. I suppose one might have reservations about G1 doing an invocation of a concurrent cycle in the case where the JVM is running short on available regions (space) and needed a more timely / urgent GC action. But, in that "not timely enough" case, G1 would likely run into a "to-space exhausted" which would fall back to a Full GC any way. Granted that Full GC initiated from a to-space exhausted is gonna be a little slower because you have to do some collection in place because there is not an available region to evacuate too. I suppose another consideration would be that anyone who wanted a concurrent cycle initiated on System.gc() could just enable ExplicitGCInvokesConcurrent at the command line. Yet, at the same time, if one wanted the stop the world, single threaded Full GC behavior for G1, he or she could disable ExplicitGCInvokesConcurrent. I think what should be taken under consideration is what is the most desirable "out of the box" behavior upon someone call System.gc(). Should it be a single threaded stop the world GC (a very long pause), or should it be an initiation of a G1 concurrent cycle? There is probably a better user experience for most folks with G1 with a default of ExplicitGCInvokesConcurrent for G1. I suppose this discussion could be expanded to looking at where in the JDK a call to System.gc() is made, and perhaps in each of those cases try to reason about what would be most desirable behavior.
30-01-2015

Cloners :	JDK-8164482 - [REDO] G1 does not implement millis_since_last_gc which is needed by RMI GC
Relates :	JDK-8160392 - Consider making XX:+ExplicitGCInvokesConcurrent the default for G1
Relates :	JDK-8164404 - Backout change for 8071770 which implements millis_since_last_gc()
Relates :	JDK-8164124 - [BACKOUT] G1 does not implement millis_since_last_gc which is needed by RMI GC
Relates :	JDK-8164018 - "clock going backwards" warning is confusing sun/tools/jstatd tests