RFR [8055338]: (process) Add instrumentation to help diagnose JDK-6573254

[serguei.spitsyn at oracle.com]

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
>>>>
>>>
>>
>>
>