RFR: 8253429: Error reporting should report correct state of terminated/aborted threads
David Holmes
david.holmes at oracle.com
Wed Sep 30 00:48:37 UTC 2020
Hi Thomas,
On 30/09/2020 1:21 am, Thomas Stuefe wrote:
> On Mon, 28 Sep 2020 04:47:47 GMT, David Holmes <dholmes at openjdk.org> wrote:
>
>>> For thread, e.g. G1ConcurrentMarkThread, there is nothing to prevent calling _cm_thread->print_on(tty) after it
>>> terminated, although, I can not find a case right now.
>>> You prefer an assertion instead?
>>
>> I prefer no change to this method. I don't see that we need to do anything special even if a ZOMBIE could be
>> encountered.
>
> If Thread::print_on() (and ThreadsSMRSupport::print_info_on(Thread..)) cannot be called for a Zombie thread, I'd prefer
> an assertion testing that.
There is nothing to say they can't be called (even if not presently),
hence no reason for an assert or any change in these methods.
>>> so, you prefer "ShouldNotReachHere()" ?
>>
>> There's no point putting a ShouldNotReachHere() in error handling code as we will just trip a secondary error.
>> If we want to print something the perhaps "unknown state (no osThread)" ?
>> Also I only wanted the ThreadSMRSupport::print_info_on to be excluded for Zombies, but you've excluded it for the
>> no-osThread case as well. I think based on what Dan said we can just put that back and call it unconditionally. Thanks.
>
> +1 for "unknown state". "Aborted" is misleading since we do not know. Could have crashed right at thread creation (or
> is that what "Aborted" means?)
"aborted" will mean different things to different people.
Cheers,
David
> -------------
>
> PR: https://git.openjdk.java.net/jdk/pull/341
>
More information about the hotspot-runtime-dev
mailing list