Hi Volker!
Yes, I do hope to port this fix to jdk8u, once it is proved to fix the bug.
However, as you correctly noticed, it will require some reorganization
of the code: the initialization of the critical section will be done
with initialization of other global variables.
I preferred to do it with InitOnceExecuteOnce, since it helps keep all
this workaround code in one place.
JDK-8057744 is subtask of another confidential bug (due to internal
links), and Jira does not allow to set different visibility level for
subtask.
Sincerely yours,
Ivan
On 23.12.2014 17:31, Volker Simonis wrote:
Hi Ivan,
I have just realized that the change 8057744 breaks HotSpot on Windows
Server 2003 because the InitOnceExecuteOnce function isn't supported
there. I suppose you're aware of this as the change contains the
following comment in os_windows.cpp:
// Must be at least Windows Vista or Server 2008 to use InitOnceExecuteOnce
#define _WIN32_WINNT 0x0600
I just wanted to ask if there are any plans to downport this change to
jdk8 because we currently still still support jdk8 HotSpot on Server
2003. Unfortunately the bug 8057744 is closed so I can not subscribe
for notifications. If there are no special reasons for keeping it
closed, can you please make it visible to everybody.
Thank you and best regards,
Volker
On Sun, Sep 7, 2014 at 8:07 AM, Ivan Gerasimov
<ivan.gerasi...@oracle.com> wrote:
Hello!
This is a proposal to address issue with wrong exit codes from a Java
processes on Windows.
In order to avoid a race, calls to _endthread(), exit and _exit() are
explicitly synchronized.
We allow simultaneous calls to _endthread() by multiple threads.
However, at the time exit() or _exit() is called, no calls to _endthread()
are allowed.
Some instrumentation added with JDK-8055338 remain in the code to help
diagnose the failures if they still occur.
BUGURL: https://bugs.openjdk.java.net/browse/JDK-8057744
WEBREV: http://cr.openjdk.java.net/~igerasim/8057744/0/webrev/
Sincerely yours,
Ivan
