RMI and GC.Interval
Kirk Pepperdine
kirk at kodewerk.com
Wed Jan 28 08:12:32 UTC 2015
Hi,
I was looking at G1 code and found this.
jlong G1CollectedHeap::millis_since_last_gc() {
// assert(false, "NYI");
return 0;
}
As long as this method returns 0, this code in sun.misc.GC always fails as maxObjectInspectionAge() is a native call that tunnels back to millis_since_last_gc().
public void run() {
for (;;) {
long l;
synchronized (lock) {
l = latencyTarget;
if (l == NO_TARGET) {
/* No latency target, so exit */
GC.daemon = null;
return;
}
long d = maxObjectInspectionAge();
if (d >= l) {
/* Do a full collection. There is a remote possibility
* that a full collection will occurr between the time
* we sample the inspection age and the time the GC
* actually starts, but this is sufficiently unlikely
* that it doesn't seem worth the more expensive JVM
* interface that would be required.
*/
System.gc();
d = 0;
}
/* Wait for the latency period to expire,
* or for notification that the period has changed
*/
try {
lock.wait(l - d);
} catch (InterruptedException x) {
continue;
}
}
}
}
My guess is; this is intentional?
Kind regards,
Kirk Pepperdine
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/hotspot-gc-dev/attachments/20150128/0d75997e/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 496 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <https://mail.openjdk.org/pipermail/hotspot-gc-dev/attachments/20150128/0d75997e/signature.asc>
More information about the hotspot-gc-dev
mailing list