RFR: 8253429: Error reporting should report correct state of terminated/aborted threads

[David Holmes]

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
>