###@###.### 2003-06-19

During the code review cycle for the following bug fix:

4514097 4/5 JVMPI_MONITOR_WAITED value returned is wrong

Jim Holmlund proposed a more platform independent means of fixing
the bug:

From: Jim Holmlund <###@###.###>
Date: Fri, 9 May 2003 10:47:50 -0700
To: ###@###.###, ###@###.###
Subject: Re: URGENT: need quick code review for escalated bug (4514097)

Daniel D. Daugherty writes:
 > Greetings,
 >
 > Tao Ma has created a fix for the following JVM/PI bug:
 >
 > 4514097 4/5 JVMPI_MONITOR_WAITED value returned is wrong
 >
 > This bug is being escalated by IBM for JDK1.3.1. The fix is short,
 > sweet and to the point. Tao has generated a version of the fix for
 > Mantis and needs one more code reviewer. I have done the first review.
 >
 > The webrev is here:
 >
 > http://javaweb/~tao/4514097_mantis/webrev/
 >
 > If you can take this review ticket, please respond so that others
 > know the ticket is already gone.
 >
 > Dan
 
I know alan took the ticket, but I was bored so I looked at it too.

Why shouldn't he use os::elapsed_counter which would make
the code for all os's be identical?

It is defined in, for example, src/os/linux/vm/os_linux.cpp:

jlong os::elapsed_counter() {
  timeval time;
  int status = gettimeofday(&time, NULL);
  return jlong(time.tv_sec) * 1000 * 1000 + jlong(time.tv_usec) - initial_time_count;
}

It is used in various places, eg, .../prims/perf.cpp:

PERF_ENTRY(jlong, Perf_HighResCounter(JNIEnv *env, jobject perf))

  PerfWrapper("Perf_HighResCounter");

  // this should be a method in java.lang.System. This value could
  // be acquired through access to a PerfData performance counter, but
  // doing so would require that the PerfData monitoring overhead be
  // incurred by all Java applications, which is unacceptable.

  return os::elapsed_counter();

PERF_END

This bug serves as a placeholder for resolving the issue in Tiger.