comparison src/share/vm/memory/genCollectedHeap.cpp @ 4712:e7dead7e90af

7117303: VM uses non-monotonic time source and complains that it is non-monotonic Summary: Replaces calls to os::javaTimeMillis(), which does not (and cannot) guarantee monotonicity, in GC code to an equivalent expression that uses os::javaTimeNanos(). os::javaTimeNanos is guaranteed monotonically non-decreasing if the underlying platform provides a monotonic time source. Changes in OS files are to make use of the newly defined constants in globalDefinitions.hpp. Reviewed-by: dholmes, ysr
author johnc
date Mon, 19 Dec 2011 10:02:05 -0800
parents 3c648b9ad052
children 441e946dc1af
comparison
equal deleted inserted replaced
4711:adedfbbf0360 4712:e7dead7e90af
1458 _time = MIN2(_time, gen->time_of_last_gc(_now)); 1458 _time = MIN2(_time, gen->time_of_last_gc(_now));
1459 } 1459 }
1460 }; 1460 };
1461 1461
1462 jlong GenCollectedHeap::millis_since_last_gc() { 1462 jlong GenCollectedHeap::millis_since_last_gc() {
1463 jlong now = os::javaTimeMillis(); 1463 // We need a monotonically non-deccreasing time in ms but
1464 // os::javaTimeMillis() does not guarantee monotonicity.
1465 jlong now = os::javaTimeNanos() / NANOSECS_PER_MILLISEC;
1464 GenTimeOfLastGCClosure tolgc_cl(now); 1466 GenTimeOfLastGCClosure tolgc_cl(now);
1465 // iterate over generations getting the oldest 1467 // iterate over generations getting the oldest
1466 // time that a generation was collected 1468 // time that a generation was collected
1467 generation_iterate(&tolgc_cl, false); 1469 generation_iterate(&tolgc_cl, false);
1468 tolgc_cl.do_generation(perm_gen()); 1470 tolgc_cl.do_generation(perm_gen());
1469 // XXX Despite the assert above, since javaTimeMillis() 1471
1470 // doesnot guarantee monotonically increasing return 1472 // javaTimeNanos() is guaranteed to be monotonically non-decreasing
1471 // values (note, i didn't say "strictly monotonic"), 1473 // provided the underlying platform provides such a time source
1472 // we need to guard against getting back a time 1474 // (and it is bug free). So we still have to guard against getting
1473 // later than now. This should be fixed by basing 1475 // back a time later than 'now'.
1474 // on someting like gethrtime() which guarantees
1475 // monotonicity. Note that cond_wait() is susceptible
1476 // to a similar problem, because its interface is
1477 // based on absolute time in the form of the
1478 // system time's notion of UCT. See also 4506635
1479 // for yet another problem of similar nature. XXX
1480 jlong retVal = now - tolgc_cl.time(); 1476 jlong retVal = now - tolgc_cl.time();
1481 if (retVal < 0) { 1477 if (retVal < 0) {
1482 NOT_PRODUCT(warning("time warp: %d", retVal);) 1478 NOT_PRODUCT(warning("time warp: "INT64_FORMAT, retVal);)
1483 return 0; 1479 return 0;
1484 } 1480 }
1485 return retVal; 1481 return retVal;
1486 } 1482 }