RFR 8064694: Kitchensink: WaitForMultipleObjects failed in hotspot\src\os\windows\vm\os_windows.cpp: 3844

Daniel D. Daugherty daniel.daugherty at oracle.com
Fri Nov 14 23:22:23 UTC 2014


On 11/14/14 5:35 AM, Ivan Gerasimov wrote:
> Hello!
>
> The recent fix for JDK-8059533 ((process) Make exiting process wait 
> for exiting threads [win]) caused the warning message to be printed in 
> some test environments:
> -----------
> os_windows.cpp:3844 is in the newly updated 
> os::win32::exit_process_or_thread(Ept what, int exit_code)
> -----------
>
> This has been observed with debug builds on highly loaded systems.
>
>
> To address the issue it is proposed to do three things:
> 1) increase the timeout for debug builds,
> 2) increase the maximum number of the thread handles to be stored,
> 3) rise the priority of the exiting threads, if we need to wait for them.
>
> Would you please help review the fix?
>
> BUGURL: https://bugs.openjdk.java.net/browse/JDK-8064694
> WEBREV: http://cr.openjdk.java.net/~igerasim/8064694/0/webrev/

src/os/windows/vm/os_windows.cpp

   line 3784: #define MAX_EXIT_HANDLES NOT_DEBUG(32) DEBUG_ONLY(128)
     Instead of NOT_DEBUG can you use PRODUCT_ONLY?
     Instead of DEBUG_ONLY can you used NOT_PRODUCT?

     That uses the smaller value for only one build config (PRODUCT).

   line 3785: #define EXIT_TIMEOUT     NOT_DEBUG(1000) DEBUG_ONLY(4000) 
/*1 sec in product, 4 sec in debug*/
     Instead of NOT_DEBUG can you use PRODUCT_ONLY?
     Instead of DEBUG_ONLY can you used NOT_PRODUCT?
     Please add spaces between the comment delimiters and the comment text.

     That uses the smaller timeout for only one build config (PRODUCT).

   line 3836           // Rise the priority...
     Typo: 'Rise' -> 'Raise'

     About the general idea of raising the exiting thread's priority,
     if the exiting thread is looping in some Win* OS code after this
     point, will raising the priority make the machine unusable?

Dan


>
> The fix was tested on all available platforms, with the hotspot 
> testset. No failures.
>
> Sincerely yours,
> Ivan
>



More information about the serviceability-dev mailing list