<html><head><meta http-equiv="Content-Type" content="text/html charset=windows-1252"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">FYI, Kirk and I had a short offline discussion about this … in general stepping back and asking what might the desirable behavior for most folks using G1 when an invocation of System.gc() happens.<div class=""><br class=""></div><div class="">I added some note from that discussion to the bug that Mikael had filed for the specific issue of G1 missing some implementation for RMI / DGC:</div><div class=""><a href="https://bugs.openjdk.java.net/browse/JDK-8071770" class="">https://bugs.openjdk.java.net/browse/JDK-8071770</a></div><div class=""><br class=""></div><div class="">Though the default behavior for G1 upon seeing a System.gc() is probably something that should be tracked under a different bug / enhancement, I decided to add a comment to the already filed bug so we would not lose some the thoughts Kirk and I had discussed.</div><div class=""><br class=""></div><div class="">thanks,</div><div class=""><br class=""></div><div class="">charlie</div><div class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Jan 30, 2015, at 2:43 AM, Kirk Pepperdine <<a href="mailto:kirk@kodewerk.com" class="">kirk@kodewerk.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class="">Hey Mikael,<br class=""><br class="">I was thinking about how one might “”fix” that G1 returns 0 for this message and that thinking lead into a rats nest of issues with reference objects. To call for a System.gc() in the G1 seems like a recipe for suicide! You would not want to run anything other than a concurrent mark phase in a large heap! If you only run concurrent mark phases than you never get the “benefits" of a sweep of the entire tenured space that you get when running a concurrent cycle or a full in a generational heap. It seems as if the decision to have DGC trigger a full if it’s not happened for a while didn't consider the nuances of using a regional instead of a generational heap.<br class=""><br class="">Do you believe it’s good enough just to return the time since the last concurrent mark cycle? And should, for the G1, the ExplicitGCInvokesConcurrent flag be true for G1?<br class=""><br class="">Kind regards,<br class="">Kirk Pepperdine<br class=""><br class="">On Jan 28, 2015, at 11:36 AM, Mikael Gerdin <<a href="mailto:mikael.gerdin@oracle.com" class="">mikael.gerdin@oracle.com</a>> wrote:<br class=""><br class=""><blockquote type="cite" class=""><br class=""><br class="">On 2015-01-28 11:28, Mikael Gerdin wrote:<br class=""><blockquote type="cite" class="">Hi Kirk,<br class=""><br class="">On 2015-01-28 09:12, Kirk Pepperdine wrote:<br class=""><blockquote type="cite" class="">Hi,<br class=""><br class="">I was looking at G1 code and found this.<br class=""><br class="">jlong G1CollectedHeap::millis_since_last_gc() {<br class="">// assert(false, "NYI");<br class=""> return 0;<br class="">}<br class=""></blockquote><br class="">I've noticed this as well when I was reading through the code at one<br class="">point but for some reason I didn't file a CR for it, this time I will :)<br class=""></blockquote><br class="">I filed <a href="https://bugs.openjdk.java.net/browse/JDK-8071770" class="">https://bugs.openjdk.java.net/browse/JDK-8071770</a><br class=""><br class="">Thanks for the bug report, Kirk!<br class=""><br class="">/Mikael<br class=""><br class=""><blockquote type="cite" class=""><br class=""><blockquote type="cite" class=""><br class="">As long as this method returns 0, this code in sun.misc.GC always fails<br class="">as maxObjectInspectionAge() is a native call that tunnels back to<br class="">millis_since_last_gc().<br class=""><br class="">public void run() {<br class="">for (;;) {<br class="">long l;<br class="">synchronized (lock) {<br class=""><br class=""> l = latencyTarget;<br class="">if (l == NO_TARGET) {<br class="">/* No latency target, so exit */<br class=""> GC.daemon = null;<br class="">return;<br class=""> }<br class=""><br class="">long d = maxObjectInspectionAge();<br class="">if (d >= l) {<br class="">/* Do a full collection. There is a remote possibility<br class=""> * that a full collection will occurr between<br class="">the time<br class=""> * we sample the inspection age and the time<br class="">the GC<br class=""> * actually starts, but this is sufficiently<br class="">unlikely<br class=""> * that it doesn't seem worth the more<br class="">expensive JVM<br class=""> * interface that would be required.<br class=""> */<br class=""> System.gc();<br class=""> d = 0;<br class=""> }<br class=""><br class="">/* Wait for the latency period to expire,<br class=""> * or for notification that the period has changed<br class=""> */<br class="">try {<br class=""> lock.wait(l - d);<br class=""> } catch (InterruptedException x) {<br class="">continue;<br class=""> }<br class=""> }<br class=""> }<br class=""> }<br class=""><br class="">My guess is; this is intentional?<br class=""></blockquote><br class="">The most likely reason is that not any of the current G1 developers had<br class="">any idea that this wasn't implemented and nobody has pointed this out<br class="">before.<br class=""><br class=""><blockquote type="cite" class=""><br class="">Kind regards,<br class="">Kirk Pepperdine<br class=""><br class=""></blockquote></blockquote></blockquote><br class=""></div></blockquote></div><br class=""></div></body></html>