Bug ID: JDK-4881356 Fix for 4514097 (MONITOR_WAITED event value) should be revisited

Type: Bug
Component: vm-legacy
Sub-Component: jvmpi
Affected Version: 6

Priority: P4
Status: Resolved
Resolution: Fixed
OS: generic
CPU: generic

Submitted: 2003-06-19
Updated: 2004-08-30
Resolved: 2004-08-30

JDK 6
6 mustangFixed

###@###.### 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.

CONVERTED DATA BugTraq+ Release Management Values COMMIT TO FIX: mustang FIXED IN: mustang INTEGRATED IN: mustang
31-08-2004
EVALUATION ###@###.### 2004-01-16 os::elapsed_counter() is probably the better way to go for fixing this bug. The only open question is whether we should even bother since JVM/PI is going away in the next major release (1.6). Name: dd4877 Date: 07/22/2004 daniel.daugherty@Sun 2004-07-22 Hotspot has an elapsedCounter helper class that provides just the functionality we need. Since the removal of JVM/PI in Mustang (1.6) is not guaranteed, I'm going ahead with these changes. ======================================================================
31-08-2004
WORK AROUND
31-08-2004
SUGGESTED FIX Name: dd4877 Date: 07/22/2004 daniel.daugherty@Sun 2004-07-22 Here are the context diffs for the changes: ------- src/os/linux/vm/objectMonitor_linux.cpp ------- * /tmp/sccs.ODayXs Thu Jul 22 15:38:00 2004 --- objectMonitor_linux.cpp Thu Jul 22 13:27:23 2004 *********** * 568,576 ** if (jvmpi::is_event_enabled(JVMPI_EVENT_MONITOR_WAIT)) { jvmpi::post_monitor_wait_event((oop)object(), millis); } ! struct timeval start_wait; if (jvmpi::is_event_enabled(JVMPI_EVENT_MONITOR_WAITED)) { ! gettimeofday(&start_wait, NULL); } intptr_t save = _recursions; // record the old recursion count --- 568,576 ---- if (jvmpi::is_event_enabled(JVMPI_EVENT_MONITOR_WAIT)) { jvmpi::post_monitor_wait_event((oop)object(), millis); } ! elapsedTimer waitTimer; if (jvmpi::is_event_enabled(JVMPI_EVENT_MONITOR_WAITED)) { ! waitTimer.start(); } intptr_t save = _recursions; // record the old recursion count *********** * 691,703 **** jt->set_current_waiting_monitor(NULL); ! if (jvmpi::is_event_enabled(JVMPI_EVENT_MONITOR_WAITED)) { ! struct timeval end_wait; ! gettimeofday(&end_wait, NULL); ! long millis_waited = (end_wait.tv_sec - start_wait.tv_sec) * 1000; ! millis_waited += (end_wait.tv_usec - start_wait.tv_usec) / 1000; ! jvmpi::post_monitor_waited_event((oop)object(), millis_waited); ! } _recursions = save; // restore the old recursion count _waiters--; // decrement the number of waiters --- 691,700 ---- jt->set_current_waiting_monitor(NULL); ! if (jvmpi::is_event_enabled(JVMPI_EVENT_MONITOR_WAITED)) { ! waitTimer.stop(); ! jvmpi::post_monitor_waited_event((oop)object(), waitTimer.milliseconds()); ! } _recursions = save; // restore the old recursion count _waiters--; // decrement the number of waiters ------- src/os/solaris/vm/objectMonitor_solaris.cpp ------- * /tmp/sccs.MOa4Ut Thu Jul 22 15:39:23 2004 --- objectMonitor_solaris.cpp Thu Jul 22 13:23:15 2004 *********** * 571,579 ** if (jvmpi::is_event_enabled(JVMPI_EVENT_MONITOR_WAIT)) { jvmpi::post_monitor_wait_event((oop)object(), millis); } ! hrtime_t start_wait; if (jvmpi::is_event_enabled(JVMPI_EVENT_MONITOR_WAITED)) { ! start_wait = os::javaTimeNanos(); } intptr_t save = _recursions; // record the old recursion count --- 571,579 ---- if (jvmpi::is_event_enabled(JVMPI_EVENT_MONITOR_WAIT)) { jvmpi::post_monitor_wait_event((oop)object(), millis); } ! elapsedTimer waitTimer; if (jvmpi::is_event_enabled(JVMPI_EVENT_MONITOR_WAITED)) { ! waitTimer.start(); } intptr_t save = _recursions; // record the old recursion count *********** * 695,702 ** jt->set_current_waiting_monitor(NULL); if (jvmpi::is_event_enabled(JVMPI_EVENT_MONITOR_WAITED)) { ! hrtime_t end_wait = os::javaTimeNanos(); ! jvmpi::post_monitor_waited_event((oop)object(), (end_wait - start_wait)/1000000L); } _recursions = save; // restore the old recursion count _waiters--; // decrement the number of waiters --- 695,702 ---- jt->set_current_waiting_monitor(NULL); if (jvmpi::is_event_enabled(JVMPI_EVENT_MONITOR_WAITED)) { ! waitTimer.stop(); ! jvmpi::post_monitor_waited_event((oop)object(), waitTimer.milliseconds()); } _recursions = save; // restore the old recursion count _waiters--; // decrement the number of waiters ------- src/os/win32/vm/objectMonitor_win32.cpp ------- * /tmp/sccs.vRa4dv Thu Jul 22 15:41:13 2004 --- objectMonitor_win32.cpp Thu Jul 22 13:19:02 2004 ************* * 286,294 ** if (jvmpi::is_event_enabled(JVMPI_EVENT_MONITOR_WAIT)) { jvmpi::post_monitor_wait_event((oop)object(), millis); } ! DWORD start_wait; if (jvmpi::is_event_enabled(JVMPI_EVENT_MONITOR_WAITED)) { ! start_wait = GetTickCount(); } intptr_t save = _recursions; // record the old recursion count _waiters++; // increment the number of waiters --- 286,294 ---- if (jvmpi::is_event_enabled(JVMPI_EVENT_MONITOR_WAIT)) { jvmpi::post_monitor_wait_event((oop)object(), millis); } ! elapsedTimer waitTimer; if (jvmpi::is_event_enabled(JVMPI_EVENT_MONITOR_WAITED)) { ! waitTimer.start(); } intptr_t save = _recursions; // record the old recursion count _waiters++; // increment the number of waiters *********** * 359,370 **** jt->set_current_waiting_monitor(NULL); if (jvmpi::is_event_enabled(JVMPI_EVENT_MONITOR_WAITED)) { ! DWORD end_wait = GetTickCount(); ! // the following code is to handle the GetTickCount() ! // wrap as documented by MSDN ! long millis_wait = (end_wait >= start_wait) ? (end_wait - start_wait) : ! (ULONG_MAX - start_wait + end_wait); ! jvmpi::post_monitor_waited_event((oop)object(), millis_wait); } _recursions = save; // restore the old recursion count _waiters--; // decrement the number of waiters --- 359,366 ---- jt->set_current_waiting_monitor(NULL); if (jvmpi::is_event_enabled(JVMPI_EVENT_MONITOR_WAITED)) { ! waitTimer.stop(); ! jvmpi::post_monitor_waited_event((oop)object(), waitTimer.milliseconds()); } _recursions = save; // restore the old recursion count _waiters--; // decrement the number of waiters ======================================================================
31-08-2004
PUBLIC COMMENTS
31-08-2004