xxxxx@xxxxx   2000-11-09

While working on the following bug:

4379126 3/5 Internal Error at os_linux.cpp, 1689 (Linux)

Karen noticed that the HotSpot implementation of GetCurrentThreadCpuTime()
was returning incorrect information. On Solaris and Linux, it returns
information relative to current system time and not current thread CPU
time.

My fix for the Linux crash leverages off os::elapsed_counter() and
I noticed that this function returns different information on Solaris
and Linux. On Solaris, the return is current_time - VM_start_time,
which is effectively how much time the VM has been up and running.
On Linux, the return is current_time. Not the same thing at all.

N/A

  xxxxx@xxxxx   2003-11-06

JVM/TI has the same GetCurrentThreadCpuTime() API so this problem applies
there also. Or it did until Bob V fixed it using the following bug ID:

4879931 3/3 Add new GetThreadCpuTime APIS needed to support JVMTI

The fix for 4879931 was integrated in Tiger-B11 and modified the
following files:

    update: src/os/linux/vm/os_linux.cpp
    update: src/os/solaris/vm/os_solaris.cpp
    update: src/os/win32/vm/os_win32.cpp
    update: src/share/vm/prims/jvmpi.cpp
    update: src/share/vm/runtime/os.hpp

The webrev for Bob V's changes is at:

file:/net/prt-archiver.sfbay/export1/imgr_archive/main/rt_baseline/2003/20030626130037.bobv.rt_baseline/webrev/index.html

From the webrev and from poking around in the code, it appears that
this should now work for JVM/PI in addition to JVM/TI. However, there
isn't a good test case for exercising this API. The NSK jvmpi subsuite
has a test, but it simply verifies that the API returns continually
increasing values.


  xxxxx@xxxxx   2003-11-06 (update 1)

The failures modes of pre-fix code are different between the
various platforms. The best way to describe it is to assume
two different calls to GetCurrentThreadCpuTime() which yield
two different values: V1 and V2.

Linux   - (V2 - V1) is the same as elapsed time in seconds
Solaris - (V2 - V1) is the same as elapsed time in milliseconds
Win32   - (V2 - V1) is the same as user time in milliseconds

Win32 had the closest implementation; its only problem was it
did not include kernel time consumed by the thread. Linux was
wrong in two ways: elapsed times and wrong scale. The wrong
scale issue will impact the hprof sample agent also. Code will
appear a lot quicker on Linux versus other platforms :-)
Solaris (SPARC and X86) were wrong in just type of time:
elapsed time versus CPU time.


  xxxxx@xxxxx   2003-11-07

With the new test, I verified that Bob V's fix for 4879931 does also
fix the problem for the JVM/PI API (as expected). Rather than close
this bug as a duplicate of 4879931, I'm going to mark it as integrated
in Tiger. This should allow Paul Jiang to work on the backport to
JDK1.3.1 (and JDK1.4.*).

very bad bug. We need this interface for a big bunch of 
different projects in the Dresdner Bank AG. Because almost 
all our machines run under Solaris (several hundred!) we 
have indeed a big problem. We didn' found a workaround.

I am surprised to see that it's almost two years since the bug 
is first reported, but there is no word on a fix or a 
workaround. We need this bug fixed to get a true idea on the 
CPU hogs while the application runs in production.

Why is there not going on anything on this bug?

It is over two years ago and the only platform this method 
works on seems to be windows.

Fixing this for Solaris probably means a call to gethrtime()

Unfortunately, on linux this means a call to get gettimeofday()
as gethrtime() is only available with the linux real-time
extensions.