diff src/share/vm/prims/jvm.cpp @ 14336:c025990068c4

8028073: race condition in ObjectMonitor implementation causing deadlocks Summary: Move redo of ParkEvent.unpark() after JVMTI_EVENT_MONITOR_WAITED event handler is called. Reviewed-by: dholmes, sspitsyn, dice, acorn
author dcubed
date Mon, 10 Feb 2014 12:48:54 -0800
parents 0f2de9d724a9
children 78fde43dc07d
line wrap: on
line diff
--- a/src/share/vm/prims/jvm.cpp	Mon Feb 10 17:49:17 2014 +0100
+++ b/src/share/vm/prims/jvm.cpp	Mon Feb 10 12:48:54 2014 -0800
@@ -1,5 +1,5 @@
 /*
- * Copyright (c) 1997, 2013, Oracle and/or its affiliates. All rights reserved.
+ * Copyright (c) 1997, 2014, Oracle and/or its affiliates. All rights reserved.
  * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
  *
  * This code is free software; you can redistribute it and/or modify it
@@ -518,6 +518,12 @@
   JavaThreadInObjectWaitState jtiows(thread, ms != 0);
   if (JvmtiExport::should_post_monitor_wait()) {
     JvmtiExport::post_monitor_wait((JavaThread *)THREAD, (oop)obj(), ms);
+
+    // The current thread already owns the monitor and it has not yet
+    // been added to the wait queue so the current thread cannot be
+    // made the successor. This means that the JVMTI_EVENT_MONITOR_WAIT
+    // event handler cannot accidentally consume an unpark() meant for
+    // the ParkEvent associated with this ObjectMonitor.
   }
   ObjectSynchronizer::wait(obj, ms, CHECK);
 JVM_END