Re: Memory leak in java.lang.Thread ?

[Chris Gray]

On Saturday 11 December 2004 01:32, David Holmes wrote:
> > [Stuart Ballard]
> > Would it be possible to keep a list of weak references and use one of
> > those magic queue things that notifies you when your objects become
> > unreachable?
> [David]
> A weak-reference (whichever kind is needed - I don't recall details) would
> solve the problem and be subclass safe, but would involve even more
> overhead that a finalizer. Keeping a notStartedCount is trivial, but
> keeping a set of references requires array management etc. I don't think it
> is worth it.

My own feeling (FWIW) is that the "legacy" Thread API is so ill-defined that 
it's acceptable to leak memory in cases like Jeroen's hilariously awful 
example, or even in other cases such as removing a shutdown hook. I do say 
this with some regret, because in my heart I believe that a VM should be able 
to run for the lifetime of the apparatus it runs on, but when bad APIs meet 
bad programmers there's not much a poor class library can do.

That much being said, I'm not sure I agree with David's assertion. If the 
reference from a ThreadGroup to an unstarted Thread were a PhantomReference, 
then IMO it would be enough to associate that reference with some 
ReferenceQueue <rq>. <rq> needs to be scanned from time to time(*), and the 
undead threads removed from the ThreadGroup to which they already implicitly 
refer. (*) Could be done by a system thread, or a per-ThreadGroup daemon, or 
simply as a side-effect of creating oe starting a new thread.

> [David]
> BTW in discussing with other JSR-166 members the consensus is that the
> ThreadGroup methods should be specified in terms of the new ThreadState
> enum.

Well if you ask me around half of the methods of ThreadGroup coul dbest be 
improved by shredding them, incinerating the remains and dispersing the ashes 
to the furhtest corners of the galaxy. For the remaining half, a 
clarification of the semantics would be most welcome. :-)

Chris