RMI and GC.Interval
Mikael Gerdin
mikael.gerdin at oracle.com
Wed Jan 28 10:36:09 UTC 2015
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
>>
More information about the hotspot-gc-dev
mailing list