RMI and GC.Interval

[charlie hunt]

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.

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:
https://bugs.openjdk.java.net/browse/JDK-8071770 <https://bugs.openjdk.java.net/browse/JDK-8071770>

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.

thanks,

charlie

> On Jan 30, 2015, at 2:43 AM, Kirk Pepperdine <kirk at kodewerk.com> wrote:
> 
> 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 --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/hotspot-gc-dev/attachments/20150130/16eedb1d/attachment.htm>