The current JDK1.2beta4 implementation of JVM_StopThread sets the stillborn bit if the asynchronous exception delivered is a ThreadDeath, and otherwise not. The stillborn bit is also set when a thread terminates normally.

(JDK1.1, the stillborn bit was always set by java_lang_Thread_stop0).

The stillborn bit in a thread serves two purposes: it prevents a thread which has never run and has been stopped from being started, and makes isAlive return false.

If a thread has never been started it is of course not capable of handling an asynchronous exception, so in this case is makes sense that JVM_StopThread sets stillborn. However, if the thread is running the ThreadDeath exception can be caught in order to run cleanup code. The handler code will then be running in a thread answering false to isAlive, which could cause spurious behavior. It is of course recommended that the handler rethrows ThreadDeath, but it is not guaranteed to do so.

The suggestion is for JVM_StopThread not to set the stillborn bit if the thread is running. If the handler code doesn't catch ThreadDeath or retrows it, the thread termination code will eventually set stillborn. If the thread chooses to ignore ThreadDeath, it should still answer true to isAlive.

This is based on a discussion between Tim and I. Please tell us if we missed something!