Garbage Collection

A

Alex Bushell

Is this legal Java, and when is the Thread instance collected...

....

private SomeObjectThatImplementsRunnable _an_object = new
SomeObjectThatImplementsRunnable;

....

public void someMethod( )
{
new Thread( _an_object ).start( );
}

....
 
T

Tony Morris

Alex Bushell said:
Is this legal Java, and when is the Thread instance collected...

...

private SomeObjectThatImplementsRunnable _an_object = new
SomeObjectThatImplementsRunnable;

...

public void someMethod( )
{
new Thread( _an_object ).start( );
}

...

Yes - it is legal (Assuming the missing body, there is no compile-time
error).
The Thread instance will be garbage collected when the object becomes
eligible for garbage collection and whenever the GC decides it is time.
This can be said about any object instance.
 
M

Michael Borgwardt

Alex said:
Is this legal Java,

Except for the syntax errors, yes.
and when is the Thread instance collected...

It becomes *egligible* for garbage collection when its run() method
has finished executing. When it will actually *be* garbage collected
is up to the JVM to decide.
 
M

Michael Borgwardt

Tony said:
Yes - it is legal (Assuming the missing body, there is no compile-time
error).

No. the first line is not legal syntax (missing parentheses for
constructor arguments).

The Thread instance will be garbage collected when the object becomes
eligible for garbage collection and whenever the GC decides it is time.
This can be said about any object instance.

i.e. it's a truism that doesn't answer the question.

Running Thread objects are among the *roots* of the reachability trees used in
today's garbage collectors.
 
C

Chris Smith

Michael said:
It becomes *egligible* for garbage collection when its run() method
has finished executing. When it will actually *be* garbage collected
is up to the JVM to decide.

It would be more accurate to say that it will not be eligible for
garbage collection until after its run() method is completed. Thread
instances are not immune to general considerations of reachability, so
the thread is free to store off references to its Thread instance, which
could be obtained from Thread.currentThread(), where ever it likes,
which could cause that Thread instance to greatly outlive the thread
itself.

In any case, it's rarely of use to enumerate all the conditions for a
specific object to become eligible for garbage collection. You're
better off going by the geberal rule that an object is always eligible
for garbage collection the instant that it becomes inaccessible. Since
the current Thread instance is accessible for a running thread (via
Thread.currentThread()), everything said so far falls within that
statement... but it's not nearly so complex as all that.

--
www.designacourse.com
The Easiest Way to Train Anyone... Anywhere.

Chris Smith - Lead Software Developer/Technical Trainer
MindIQ Corporation
 
P

P.Hill

Chris said:
but it's not nearly so complex as all that.

I have to agree with Chris, it certainly isn't so complex.

My hunch is that the OP was wondering that since HE didn't hold
onto a reference to it, he was expecting something else surely
had reference to it and was hoping for a reasonable programmers
model which he could think about to understand when the thread
really does become eligible. I assume the various others in this
thread have provided enough information.

-Paul
 
J

John C. Bollinger

P.Hill said:
My hunch is that the OP was wondering that since HE didn't hold
onto a reference to it, he was expecting something else surely
had reference to it and was hoping for a reasonable programmers
model which he could think about to understand when the thread
really does become eligible. I assume the various others in this
thread have provided enough information.

And I suspect that the particular thing he worried about is that the
Thread, its Runnable, or some of the other Objects it works on might be
GC'd before the Thread was done, thus leading to corrupt data, execution
of random instructions, or other badness. That cannot ever happen in
Java. (Which is to say that it would represent a JVM bug if it ever did
happen.)
 
T

Tony Morris

No. the first line is not legal syntax (missing parentheses for
constructor arguments).

An assumed oversight by the OP - apologies for not stating so.
i.e. it's a truism that doesn't answer the question.

It answers the question in as much as there was never any intent shown for a
more detailed answer.
Running Thread objects are among the *roots* of the reachability trees used in
today's garbage collectors.


--
Tony Morris
(BInfTech, Cert 3 I.T.)
Software Engineer
(2003 VTR1000F)
Sun Certified Programmer for the Java 2 Platform (1.4)
Sun Certified Developer for the Java 2 Platform
 
R

Roedy Green

It becomes *egligible* for garbage collection when its run() method
has finished executing. When it will actually *be* garbage collected
is up to the JVM to decide.

Be careful. If you instantiate a Thread but never get around to
calling the start method, it will hang around forever,
even if you drop all references to it.

see http://mindprod.com/jgloss/packratting.html
 
M

Michael Borgwardt

Roedy said:
Be careful. If you instantiate a Thread but never get around to
calling the start method, it will hang around forever,
even if you drop all references to it.

Very interesting detail. Then what can you do to reclaim the memory if you
come to a point where you have instantiated a Thread but change your mind
about running it? I can't seem to find anything in the Thread class that
could be used to handle this case.
 
G

Gordon Beaton

Very interesting detail. Then what can you do to reclaim the memory
if you come to a point where you have instantiated a Thread but
change your mind about running it? I can't seem to find anything in
the Thread class that could be used to handle this case.

It seems you have to run it in that case. If you expect that you'll
create threads and later change your mind, you could always set a
field checked by the run method, then run the thread anyway:

public void run() {
if (!cancelled) {
...
}
}

/gordon
 
X

xarax

Roedy Green said:
Be careful. If you instantiate a Thread but never get around to
calling the start method, it will hang around forever,
even if you drop all references to it.

see http://mindprod.com/jgloss/packratting.html

There is nothing the JavaDoc for Thread or ThreadGroup
that indicates that a JVM implementation is required
to hold an inactive Thread reference in the ThreadGroup.

When instantiating the Thread, there is nothing that
indicates that the Thread instance is referenced in the
ThreadGroup before the thread is started. The Thread
instance may hold a reference to the ThreadGroup to
which the thread will belong after the start() method
is called. The start() method could add the Thread
reference to the ThreadGroup at that time.

Your glossary is quite likely describing a particular
implementation detail that can change across different
JVM releases and almost certainly across different JVM
vendors.
 
R

Roedy Green

There is nothing the JavaDoc for Thread or ThreadGroup
that indicates that a JVM implementation is required
to hold an inactive Thread reference in the ThreadGroup.

Correct. But it does.
 
C

Chris Smith

Roedy said:
Correct. But it does.

The conveniently missed point here is that this statement is meaningless
unless you define "it". If "it" is a Sun release of the JVM prior to
1.5, then you're right.

--
www.designacourse.com
The Easiest Way to Train Anyone... Anywhere.

Chris Smith - Lead Software Developer/Technical Trainer
MindIQ Corporation
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,733
Messages
2,569,440
Members
44,830
Latest member
ZADIva7383

Latest Threads

Top