Hi Ivan,
It is a nice step in the investigation of this nasty and very old issue!
The fix looks good in general.
A minor comment:
Is it possible to make the exit code more consistent in the os_windows.cpp?
For instance, make them 70115, 80115 and 90115 instead of 70115, 80211
and 90223?
Thanks,
Serguei
On 8/19/14 5:57 AM, Ivan Gerasimov wrote:
Hello again!
I updated the patch to cover situations when the exiting thread isn't
daemon.
I also added load_acquire/store_release for the sake of accuracy, even
though on Windows they seem to add nothing to the volatile access.
http://cr.openjdk.java.net/~igerasim/8055338/1/webrev/
If the updated patch looks Okay, I'll need a sponsor to push it.
Sincerely yours,
Ivan
On 19.08.2014 6:42, David Holmes wrote:
On 19/08/2014 10:12 AM, Ioi Lam wrote:
With the Windows/x86/x64 memory model, is the write to
vm_getting_terminated guaranteed to be observable by java_start()?
In the general case, not immediately. For the threads actually of
interest the logic that tells the threads to terminate happens after
the write to the flag, and that logic contains sufficient
"synchronization" that if the termination logic is correct then the
flag must also be visible.
David
- Ioi
On 8/18/14, 2:19 PM, Ivan Gerasimov wrote:
Hello!
This is a request to temporarily add some instrumentation code to
hotspot to help diagnose the intermittent failure on Windows, which
results in a wrong exit code of (sub-)process.
BUGURL: https://bugs.openjdk.java.net/browse/JDK-8055338
WEBREV: http://cr.openjdk.java.net/~igerasim/8055338/0/webrev/
Sincerely yours,
Ivan
