Re: 答复: Should JVM know an app is in a shutdown state when a timeout event occurs?

David Holmes david.holmes at oracle.com
Mon May 15 05:12:53 UTC 2017


Re-sending to hotspot-runtime-dev at openjdk.java.net

On 15/05/2017 7:31 AM, David Holmes wrote:
> The specification for add/removeShutdownHook states:
>
>      * @throws  IllegalStateException
>      *          If the virtual machine is already in the process of
> shutting
>      *          down
>
> So if the VM is shutting down and calls to those functions are made then
> they will throw the IllegalStateException.
>
> SIGTERM is one of the shutdown signals that the hotspot VM will respond
> to.Or more accurately it is communicated through to the signal handling
> thread which will create a new Java thread to perform an orderly
> shutdown of the JVM.
>
> The exact way in which signals are processed is not specified so may
> vary across different JVMs.
>
> If I understand the stack trace you supplied it seems that decapo
> installed a shutdownhook thread and then as part of its normal
> termination process it will remove that hook. If you are terminating the
> JVM externally using "timeout" then you have introduced a race
> condition. If the shutdown has commenced when the hook is removed then
> the exception will be thrown; otherwise it won't.
>
> I can't comment on any specifics of the J9 VM.
>
> HTH.
>
> David
>
> On 14/05/2017 4:08 AM, 陈雨亭 wrote:
>> I quickly went through the "Troubleshooting guide for HotSpot VM" (
>> http://docs.oracle.com/javase/7/docs/webnotes/tsg/TSG-VM/html/signals.html#g
>>
>> bzbl).
>>
>> In my case, the -Xrs option is not specified.
>>
>> The guide does not explain very clearly about my test case: when the JVM
>> itself is in
>> a shutting down progress, should the IllegalStateException be thrown out
>> when
>> it attempts to remove the shutdown hook?
>>
>> Regards,
>> Yuting
>>
>> -----邮件原件-----
>> 发件人: 陈雨亭 [mailto:chenyt at cs.sjtu.edu.cn]
>> 发送时间: 2017年5月13日 10:31
>> 收件人: 'David Holmes' <david.holmes at oracle.com>;
>> 'hotspot-runtime-dev at openjdk.java.net'
>> <hotspot-runtime-dev at openjdk.java.net>
>> 主题: 答复: Should JVM know an app is in a shutdown state when a timeout
>> event occurs?
>>
>> Besides, the TERM signal kills any process that does not block or
>> catch that
>> signal (https://linux.die.net/man/1/timeout). Does the test case indicate
>> that J9 can catch the TERM signal, while HotSpot cannot? :)
>>
>> Yuting
>>
>> -----邮件原件-----
>> 发件人: 陈雨亭 [mailto:chenyt at cs.sjtu.edu.cn]
>> 发送时间: 2017年5月13日 10:23
>> 收件人: 'David Holmes' <david.holmes at oracle.com>;
>> 'hotspot-runtime-dev at openjdk.java.net'
>> <hotspot-runtime-dev at openjdk.java.net>
>> 主题: 答复: Should JVM know an app is in a shutdown state when a timeout
>> event occurs?
>>
>> Hi,David,
>>
>> I tested and compared JVMs on Ubuntu 16.04 using
>>     timeout 20s java ...
>> The command kills the jvm if it is still running after 20seconds (i.e.,
>> after 20 seconds, the TERM signal is sent and then the jvm will be in the
>> process of shutting down).
>>
>> Runtime. getRuntime().removeShutdownHook() may throw
>> IllegalStateException
>> if the virtual machine is already in the process of shutting down.
>>
>> Indeed, IBM's J9 can throw the IllegalStateException (when it removes the
>> hook and the JVM is shutting down), while HotSpot cannot.
>> I'm curious about the difference (I rethought about this. Possibly
>> J9 should not throw out the exception when it is shutting down.).
>>
>> Yuting
>>
>>
>> -----邮件原件-----
>> 发件人: David Holmes [mailto:david.holmes at oracle.com]
>> 发送时间: 2017年5月13日 1:02
>> 收件人: 陈雨亭 <chenyt at cs.sjtu.edu.cn>;
>> hotspot-runtime-dev at openjdk.java.net
>> 主题: Re: Should JVM know an app is in a shutdown state when a timeout
>> event
>> occurs?
>>
>> Hi,
>>
>> What "timeout events" are you referring to?
>>
>> What you show below indicates an attempt to remove a shutdown hook
>> after the
>> shutdown sequence has started - that is all in the JDK library code,
>> nothing
>> to do with hotspot.
>>
>> Cheers,
>> David
>>
>> On 13/05/2017 8:29 AM, 陈雨亭 wrote:
>>> I recently observed that there is a minor difference between HotSpot
>>> and IBM's J9 when they process the timeout events. I downloaded the
>>> dacapo benchmark
>>> (http://dacapobench.org/) and ran
>>>        "timeout 20s java Harness avrora"
>>> . J9 sometimes throws a (java.lang.IllegalStateException: Shutdown in
>>> progress) while HotSpot cannot.
>>> The IllegalStateException may be thrown by J9 when
>>> Runtime.getRuntime().removeShutdownHook(shutdownThread)
>>> (see line 103, avrora.actions.SimAction) is executed and at the same
>>> time the timeout event arrives.
>>>
>>> In order to reproduce the event, I slightly rewrote avrora.Main.main a
>>> little so that avrora.Main.runAction will be called for 30 times. I
>>> also ran the command "timeout 20s java Harness avrora" for 30+ times
>>> so that Runtime.getRuntime().removeShutdownHook(shutdownThread) (the
>>> code at line 103, avrora.actions.SimAction) is running when "timeout
>>> 20s java" completes.
>>>
>>> It seems that when the timeout event occurs, the app is in a shutdown
>> state.
>>> J9 is able to detect it, while
>>> HotSpot may miss catching it.
>>>
>>> I wonder what can be the real cause of the difference, the JVMs, or
>>> the API implementations (i.e., Runtime.
>>> getRuntime().addShutdownHook), or the application itself. Which JVM is
>>> correct? Actually when the timeout event occurs, HotSpot will
>>> terminate without executing the following statements, while J9 throws
>>> the exception and enters the exception handling block.
>>>
>>> avrora.actions.SimAction
>>> 84        public void run(String[] args) throws Exception {
>>> 85            SimUtil.REPORT_SECONDS = REPORT_SECONDS.get();
>>> 86            SimUtil.SECONDS_PRECISION = (int)SECONDS_PRECISION.get();
>>> 87
>>> 88            simulation = Defaults.getSimulation(SIMULATION.get());
>>> 89            simulation.process(options, args);
>>> 90
>>> 91            ShutdownThread shutdownThread = new ShutdownThread();
>>> 92            Runtime.getRuntime().addShutdownHook(shutdownThread);
>>> 93            printSimHeader();
>>> 94            try {
>>> 95                startms = System.currentTimeMillis();
>>> 96                simulation.start();
>>> 97                simulation.join();
>>> 98            } catch (Throwable t) {
>>> 99                exitSimulation(t);
>>> 100
>>> Runtime.getRuntime().removeShutdownHook(shutdownThread);
>>> 101            } finally {
>>> 102                exitSimulation(null);
>>> 103
>>> Runtime.getRuntime().removeShutdownHook(shutdownThread);
>>> 104            }
>>> 105        }
>>>
>>> The exception message is given as the follows:
>>>
>>> java.lang.reflect.InvocationTargetException
>>> java.lang.reflect.InvocationTargetException
>>>     at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>>>     at
>>> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.j
>>> ava:95
>>> )
>>>     at
>>> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccess
>>> orImpl
>>> .java:55)
>>>     at java.lang.reflect.Method.invoke(Method.java:508)
>>>     at org.dacapo.harness.Avrora.iterate(Avrora.java:42)
>>>     at org.dacapo.harness.Benchmark.run(Benchmark.java:166)
>>>     at org.dacapo.harness.TestHarness.runBenchmark(TestHarness.java:218)
>>>     at org.dacapo.harness.TestHarness.main(TestHarness.java:171)
>>>     at Harness.main(Harness.java:17)
>>> Caused by: java.lang.IllegalStateException: Shutdown in progress
>>>     at
>>>
>> java.lang.ApplicationShutdownHooks.remove(ApplicationShutdownHooks.java:93)
>>
>>>     at java.lang.Runtime.removeShutdownHook(Runtime.java:250)
>>>     at avrora.actions.SimAction.run(SimAction.java:103)
>>>     at avrora.Main.runAction(Unknown Source)
>>>     at avrora.Main.main(Unknown Source)
>>>     ... 9 more
>>>
>>


More information about the hotspot-runtime-dev mailing list