- "Execution Time" - always provided - shows the total "wall clock" time
it took the method to execute. This is computed by capturing the system
timer at the beginning and end of the method, and subtracting the "start
time" from the "end time".

- "CPU Time" - configurable - shows the actual time the method was
executing in the CPU. It should provide an estimate for the actual CPU
cycles used to execute this CPU, not counting idle time, context
switches etc. This value is captured from the JVM directly, using some
JVMTI functions (see GetThreadCPUTime function here: http://java.sun.com/j2se/1.5.0/docs/guide/jvmti/jvmti.html#t imers).
The problem with CPU Time is that the data provided by the JVM is not
very accurate and is not granular enough. In fact, on most current JVMs,
any method which keeps the CPU busy for less than a millisecond (which
is quite a lot of CPU time on a modern CPU) will be reported with a CPU
time of 0. Therefore, I think this counter is not very usable.

According to the documentation (in the link you provided):
"The CPU time provided by this interface has nanosecond precision but
not necessarily nanosecond accuracy"

This looks similar to JVMTI, and I won't be surprised if both methods
use the same JVM counters. However, you may want to post a question on
the Sun Java newsgroup to get more information.

As for finding which JVMs support CPU counter and at what precision -
this is probably a trial-and-error experience....
As far as I know, the implementation on Sun and JRockit is the same for
1.5 and 1.6.