RFR 8066863: bigapps/runThese/nowarnings fails: Java HotSpot(TM) 64-Bit Server VM warning: WaitForMultipleObjects

Daniel D. Daugherty daniel.daugherty at oracle.com
Thu Dec 11 16:05:15 UTC 2014


On 12/11/14 3:01 AM, David Holmes wrote:
> On 11/12/2014 7:48 PM, David Holmes wrote:
>> Hi Ivan,
>>
>> On 11/12/2014 4:52 PM, Ivan Gerasimov wrote:
>>> Hello!
>>>
>>> After the fix for JDK-8064694 some more failures of
>>> WaitForMultipleObjects() were observed under heavy load.
>>> The reason was that the limitation on wait object number was 
>>> overlooked.
>>> The total number of the objects should not be greater than
>>> MAXIMUM_WAIT_OBJECTS (= 64).
>>>
>>> The proposed fix is to get rid of constant MAX_EXIT_HANDLES and use
>>> MAXIMUM_WAIT_OBJECTS instead for all kinds of builds.
>>> I also added the last error code to the failure reports, so it would be
>>> easier to identify the cause of a failure.
>>>
>>> Would you please help review the fix?
>>>
>>> BUGURL: https://bugs.openjdk.java.net/browse/JDK-8066863
>>> WEBREV: http://cr.openjdk.java.net/~igerasim/8064694/0/webrev/
>>
>> The webrev changes do not correspond to the description you gave above.
>
> Correct webrev URL:
>
> http://cr.openjdk.java.net/~igerasim/8066863/0/webrev/

src/os/windows/vm/os_windows.cpp
     Thanks for adding the GetLastError() info to the messages.

Thumbs up.

RT_Baseline has already pushed to Main_Baseline for this week
so you should be good to go if you're happy with your pre-push
testing.


> Seems this saga will never end. :( Changes seem okay.

On the plus side, we're seeing fewer and fewer exit_code stomping
failures in nightly so things are getting better...

Dan


>
> Thanks,
> David
>
>> David
>>
>>
>>> Sincerely yours,
>>> Ivan



More information about the serviceability-dev mailing list