RMI and GC.Interval

[Mikael Gerdin]

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 :)

>
> 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
>