JDK-8160887 : os::elapsedVTime() is not consistent across platforms
  • Type: Enhancement
  • Component: hotspot
  • Sub-Component: gc
  • Affected Version: 9
  • Priority: P3
  • Status: Closed
  • Resolution: Duplicate
  • OS: generic
  • CPU: generic
  • Submitted: 2016-07-06
  • Updated: 2025-06-26
  • Resolved: 2025-06-26
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
Other
tbdResolved
Related Reports
Duplicate :  
JDK-8274051 - Remove supports_vtime()/elapsedVTime()
Relates :  
JDK-8232211 - Remove dead code from os.hpp|cpp
Relates :  
JDK-8160350 - cannot truss jdk9 [ solaris ]
Description
This bug is a followup of JDK-8160350 - cannot truss jdk9 [ solaris ]. During investigation of that bug it became clear that the implementation, behaviour and usage of os::elapsedVTime() and the associated functions os::supports_vtime(), os::enable_vtime() and os::vtime_enabled() are inconsistent between platforms.

The issues are:

* Calls to os::elapsedVTime() are not being guarded in some places by a call to os::supports_vtime(), e.g. G1CMTask::do_marking_step() / G1CMTask::regular_clock_call()

* When thread CPU time is unavailable on a particular platform (e.g. BSD), total process CPU time is used instead, so on BSD the GC marking tasks may expire much earlier than on other platforms.

* If the underlying system call to get vtime fails, platforms may either return 0 or fall back to returning total process CPU time. That means that delta calculations based on sucessive values returned by os::elapsedVTime() could give bizarre results.

This area needs looking at carefully and decisions making about what the required cross-platform behaviour should be before the code is cleaned up.

See also the discussion at http://mail.openjdk.java.net/pipermail/hotspot-dev/2016-July/023784.html
Comments
Hi [~kbarrett] , should we maybe just call os::current_thread_cpu_time(false) on macOS in os::elapedVtime ? From what I see this would give us the user time.
23-04-2025
Another issue is that we have the pre-existing os::current_thread_cputime[_info] (to support jvmti) which is largely duplicative in functionality (though with a different interface and implementation). I don't know why the vtime stuff was added when we already had those functions.
12-07-2024
At present, all callers of elapsedVTime are in GC code, and more specifically in G1 code. The vtime API was added to os as part of the initial G1 integration. Perhaps this ought to be reassigned to gc to figure out how to clean things up.
15-05-2017
Yes, I pondered about that as well when I was doing the Solaris patch, it all seemed the wrong way around to me. In the end I decided to do the bare minimum to fix the truss issue.
06-07-2016
os::vtime_enabled() has no callers. And a good thing too, as a caller might be confused by all existing implementations (except solaris before JDK-8160350 is fixed) always returning false. And all implementations of os::enable_vtime() (except solaris before JDK-8160350 is fixed) do nothing and return false. There is presently only one caller of it, which ignores the returned value.
06-07-2016