[prev in list] [next in list] [prev in thread] [next in thread] 

List:       openjdk-serviceability-dev
Subject:    Re: RFR [8057744] (process) Synchronize exiting of threads and process [win]
From:       "Daniel D. Daugherty" <daniel.daugherty () oracle ! com>
Date:       2014-09-10 17:27:08
Message-ID: 541089EC.2070904 () oracle ! com
[Download RAW message or body]

Ioi is (relatively) happy with the 2014-09-09 RT_Baseline nightly
and has his snapshot ready for pushing to Main_Baseline.

I've submitted these bits to JPRT-west:

2014-09-10-171329.ddaugher.8057744_for_jdk9_hs_rt

Dan


On 9/8/14 7:31 AM, Daniel D. Daugherty wrote:
> Ivan,
>
> I'll sponsor the change, but I want to push it after this week's
> RT_Baseline snapshot. We snapshot on Tuesday (2014.09.09 at 1900 PT)
> and if the nightly test results look reasonable Wednesday morning,
> then I'll push it on Wednesday.
>
> Does this sound acceptable to you?
>
> Dan
>
>
> On 9/7/14 10:03 PM, Ivan Gerasimov wrote:
>> Thanks Daniel and David!
>>
>> I'll need a sponsor to help me push the change.
>>
>> Sincerely yours,
>> Ivan
>>
>>
>> On 08.09.2014 6:03, David Holmes wrote:
>>> Hi Ivan,
>>>
>>> On 7/09/2014 4:07 PM, Ivan Gerasimov 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/
>>>
>>> As per preliminary discussions this all looks okay.
>>>
>>> One small concern I have is that the exit() may be arbitrarily 
>>> delayed if the mutexes are not assigned fairly, and the application 
>>> (more likely a test) is creating shortlived threads concurrently 
>>> with the exit attempt. But I guess we will just have to deal with 
>>> that if it arises.
>>>
>>> Thanks,
>>> David
>>>
>>>> Sincerely yours,
>>>> Ivan
>>>
>>>
>>
>
>
>
>

[prev in list] [next in list] [prev in thread] [next in thread]