RMI and GC.Interval

[Kirk Pepperdine]

Hey Mikael,

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.

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?

Kind regards,
Kirk Pepperdine

On Jan 28, 2015, at 11:36 AM, Mikael Gerdin <mikael.gerdin at oracle.com> wrote:

> 
> 
> On 2015-01-28 11:28, Mikael Gerdin wrote:
>> Hi Kirk,
>> 
>> On 2015-01-28 09:12, Kirk Pepperdine wrote:
>>> Hi,
>>> 
>>> I was looking at G1 code and found this.
>>> 
>>> jlong G1CollectedHeap::millis_since_last_gc() {
>>> // assert(false, "NYI");
>>>  return 0;
>>> }
>> 
>> I've noticed this as well when I was reading through the code at one
>> point but for some reason I didn't file a CR for it, this time I will :)
> 
> I filed https://bugs.openjdk.java.net/browse/JDK-8071770
> 
> Thanks for the bug report, Kirk!
> 
> /Mikael
> 
>> 
>>> 
>>> 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?
>> 
>> The most likely reason is that not any of the current G1 developers had
>> any idea that this wasn't implemented and nobody has pointed this out
>> before.
>> 
>>> 
>>> Kind regards,
>>> Kirk Pepperdine
>>> 

-------------- 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/20150130/983a817b/signature.asc>