Hi Robin,
Adding in hotspot-runtime-dev as all the hotspot changes belong to runtime.
I had an initial look through this.
To be honest I don't like it. We seem to have to record little bits of
information all over the place just so they can be reported by the
shutdown event. It seems untidy. :(
Can you rename _starting_thread to _main_thread please. The use of
"starting" in thread.hpp/cpp is really a naming anomaly. The main thread
is the thread that loads the JVM. And that would be consistent with
set_exception_in_main_thread.
Though why do we care if the main thread exited with an unhandled
exception? And if we do care, why do we only care when the shutdown
reason is ""No remaining non-daemon Java threads"?
I don't like the need to add os::get_abort_exit_code. Do we really need
it? What useful information does it convey?
It is unfortunate that you need to add beforeHalt to deal with the event
mechanism itself being turned off (?) by a shutdown hook. That would
seem to potentially lose a lot of event information given hooks can run
in arbitrary order and execute arbitrary Java code. And essentially you
end up recording the initial reason shutdown started, though potentially
it could end up terminating for a different reason.
Let's see what others think ...
Thanks,
David
On 8/02/2018 1:18 AM, Robin Westberg wrote:
Hi all,
Please review the following change that adds an event-based tracing
event that is generated when the VM shuts down. The intent is to capture
shutdowns that occur after the VM has been properly initialized (as
initialization problems would most likely mean that the tracing
framework hasn’t been properly started either).
Issue: https://bugs.openjdk.java.net/browse/JDK-8041626
Webrev: http://cr.openjdk.java.net/~rwestberg/8041626/webrev.00/
Testing: hs-tier1,hs-tier2,jdk-tier1,jdk-tier2
Best regards,
Robin
