EVALUATION

http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/d903bf750e9f
                                     

EVALUATION

http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/d903bf750e9f
                                     

EVALUATION

http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/d903bf750e9f
                                     

SUGGESTED FIX

Change remaining calls to os::javaTimeMillis() in GC code (used to update _time_since_last_gc or _millis_since_last_gc) to use os::javaTimeNanos() and convert to milliseconds.
                                     

EVALUATION

As David points out - in the changes for 7117303, I missed a few calls to os::javaTimeMillis() in the GC code (specifically associated with updating the _time_of_last_gc field in the different generation types.

I believe that they can all be changed to us an alternative to os::javaTimeMillis().
                                     

EVALUATION

It appears that various parts of the GC code still use os::javaTimeMillis to record GC times. These are not comparable with the value of javaTimeNanos() converted to ms that was put in place by 7117303.

./share/vm/memory/genMarkSweep.cpp:  gch->update_time_of_last_gc(os::javaTimeMillis());
./share/vm/memory/defNewGeneration.cpp:  update_time_of_last_gc(os::javaTimeMillis());
./share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp:  update_time_of_last_gc(os::javaTimeMillis());
./share/vm/gc_implementation/parNew/parNewGeneration.cpp:  update_time_of_last_gc(os::javaTimeMillis());

However it may be that GC times are expected to correlate to time-of-day values, which would mean we have a basic conflict in how these timestamps are used as they can not be both time-of-day values and monotonic.