RMI and GC.Interval

[Kirk Pepperdine]

Gosh, I should have kept quiet. I was quite happy that G1 didn’t trigger System.gc() for RMI.

Regards,
Kirk

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/20150128/7b55dd69/signature.asc>