RFR: JDK-8325158: Revert JDK-8248657 for X86

[Nagata-Haruhito]

On Fri, 2 Feb 2024 09:42:15 GMT, Nagata-Haruhito <duke at openjdk.org> wrote:

> [JDK-8248657](https://bugs.openjdk.org/browse/JDK-8248657) affects AARCH64 Windows.
> In this fix, always WaitForSingleObject() is called, but it is low performance in multi processes with heavy stress.
> 
> So, I propose threadCritical_windows.cpp move to os_cpu, and revert
> [JDK-8248657](https://bugs.openjdk.org/browse/JDK-8248657) at threadCritical_windows_x86.cpp.

I found this performance regression between 11.0.8 and 11.0.15 first on Windows x64 only.
So, I doubt JDK-8248657 cause this regression.

I have tried to log ThreadCritical() constructor performance as below:

--- src/hotspot/os/windows/threadCritical_windows.cpp   2024-01-17 17:57:03.887768500 +0900
+++ ../threadCritical_windows.cpp_log   2022-06-15 19:43:32.031019300 +0900
@@ -26,6 +26,8 @@
 #include "runtime/atomic.hpp"
 #include "runtime/thread.inline.hpp"
 #include "runtime/threadCritical.hpp"
+#include "utilities/defaultStream.hpp"
+#include "jvm.h"

 // OS-includes here
 # include <windows.h>
@@ -39,6 +41,7 @@
 static int lock_count = 0;
 static HANDLE lock_event;
 static DWORD lock_owner = 0;
+static DWORD prev_owner = 0;

 //
 // Note that Microsoft's critical region code contains a race
@@ -58,6 +61,7 @@
 }

 ThreadCritical::ThreadCritical() {
+  DWORD start = GetTickCount();
   InitOnceExecuteOnce(&initialized, &initialize, NULL, NULL);

   DWORD current_thread = GetCurrentThreadId();
@@ -65,8 +69,13 @@
     // Grab the lock before doing anything.
     DWORD ret = WaitForSingleObject(lock_event,  INFINITE);
     assert(ret == WAIT_OBJECT_0, "unexpected return value from WaitForSingleObject");
+    prev_owner = lock_owner;
     lock_owner = current_thread;
   }
+  DWORD end = GetTickCount();
+  if ((end - start) > 0) {
+    jio_fprintf(defaultStream::error_stream(), "ThreadCritical() %d msec at %x to %x\n", end-start, prev_owner, current_thread);
+  }
   // Atomicity isn't required. Bump the recursion count.
   lock_count++;
 }



Then, I got 27000 over output. Also 150 over lines took more 100msecs.
When revert JDK-8248657 (as PR), the output is only 500 over.
And almost prev_owner is 0, that shows non-blocked WaitForSingleObject() takes long time.

At latest glassfish environment (glassfish7 + JDK21), this regression still exists. 
So I propose this PR in mainline.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17682#issuecomment-1926533242