###@###.### 2004-02-17

This RFE has been opened as result of discussion around fix of the bug:
   Fixed 4963071: PERF: GetCurrentThreadCpuTime() performance on Solaris
We agreed (with Karen and Mandy) to create an RFE to track this issue to be
fixed in 1.6 release when the JVMPI is gone.

In the 1.6 release both os::thread_cpu_time() and os::current_thread_cpu_time()
have to return -1 if os::is_thread_cpu_time_supported() returns 'false'.
This is supposed to be fixed in 1.6, because we are not going to break
compatibility for existing JVMPI applications.
JVMPI applications can use os::thread_cpu_time() and os::current_thread_cpu_time()
even if os::is_thread_cpu_time_supported() returns 'false'.

For example, thread_cpu_time() is not supported on Solaris-8 with T1 threads.
Both os::thread_cpu_time() and os::current_thread_cpu_time() return incorrect
data with T1 because there is no 1:1 mapping between java threads and LWP's.
But it can not break JVMPI applications which get incorrect timing data.

Current solution for 1.5 release is to return -1 in the M&M and JVMTI versions
of GetThreadCpuTime() and GetCurrentThreadCpuTime() if thread_cpu_time() is not
supported. And we don't change the JVMPI behavior.

-Serguei