Garbage collector quiz

R

Razvan

Hi !





Take a look at the following code:

public class CDummy
{
public static void main(String args[])
{
System.out.println("CDummy.");

for(int ii=10; ii>=0; ii--)
{
String tmp = Integer.toString(ii);
System.out.println(tmp);
}

System.out.println("END");
}
}

When the program reached the line that prints "END", how many 'tmp'
string objects are elligible for
garbage collection ?

Valid answers:
1
10
11
20
none


I choosed 10, the right answer is 11. The reason for this is the fact
that even if the variable tmp is out of scope it is STILL holding a
reference to the last 'tmp' string. Is that true ?!! At the above
mentionated line there is no way in the whole program to access any
temporary string. Normally they should ALL be garbage collected. Can
the out of scope variable tmp prevent the garbage collector from
collecting the last string ?




Regards,
Razvan
 
J

Joona I Palaste

Razvan said:

Could you please only put one blank row between each paragraph?
Take a look at the following code:
public class CDummy
{
public static void main(String args[])
{
System.out.println("CDummy.");
for(int ii=10; ii>=0; ii--)
{
String tmp = Integer.toString(ii);
System.out.println(tmp);
}

System.out.println("END");
}
}
When the program reached the line that prints "END", how many 'tmp'
string objects are elligible for
garbage collection ?
Valid answers:
1
10
11
20
none
I choosed 10, the right answer is 11. The reason for this is the fact
that even if the variable tmp is out of scope it is STILL holding a
reference to the last 'tmp' string. Is that true ?!! At the above
mentionated line there is no way in the whole program to access any
temporary string. Normally they should ALL be garbage collected. Can
the out of scope variable tmp prevent the garbage collector from
collecting the last string ?

The right answer is anything between 0 and 11 (inclusive). To be more
specific, I define "an object is eligible for garbage collection" as
"an object *STILL EXISTS* and may be freely swept up any time by the
garbage collector".
Nothing prevents the garbage collector from running *EVERY TIME* the
loop iterates, sweeping up the object the variable tmp used to refer to.
OTOH, nothing prevents it from only sweeping up anything at the end of
the whole program either.

--
/-- Joona Palaste ([email protected]) ------------- Finland --------\
\-------------------------------------------------------- rules! --------/
"And according to Occam's Toothbrush, we only need to optimise the most frequent
instructions."
- Teemu Kerola
 
E

Edwin Martin

Razvan said:
Take a look at the following code:

public class CDummy
{
public static void main(String args[])
{
System.out.println("CDummy.");

for(int ii=10; ii>=0; ii--)
{
String tmp = Integer.toString(ii);
System.out.println(tmp);
}

System.out.println("END");
}
}

When the program reached the line that prints "END", how many 'tmp'
string objects are elligible for
garbage collection ?

Valid answers:
1
10
11
20
none


I choosed 10, the right answer is 11.

Well, it is 11: the loop is executed 11 times:
ii becomes 10 9 8 7 6 5 4 3 2 1 0. That's 11 times.
The reason for this is the fact
that even if the variable tmp is out of scope it is STILL holding a
reference to the last 'tmp' string. Is that true ?!!

I think that's up to the garbage collector. I doubt this behaviour is in
the Java specification.

So the answer is 11, but not because of the GC.

Edwin Martin.
 
T

Thomas Fritsch

So it was more a "for loop quiz" than a "garbage collector quiz". ;-)
The loop runs from 10 to 0 inclusive, that's 11 by my reckoning.

Take a look at the following code:

public class CDummy
{
public static void main(String args[])
{
System.out.println("CDummy.");
for(int ii=10; ii>=0; ii--)
{
String tmp = Integer.toString(ii);
System.out.println(tmp);
}
System.out.println("END");
}
}

When the program reached the line that prints "END", how many 'tmp'
string objects are elligible for
garbage collection ?
 
C

Chris Uppal

Razvan said:
I choosed 10, the right answer is 11.

I think you meant that the other way around ?

The reason for this is the fact
that even if the variable tmp is out of scope it is STILL holding a
reference to the last 'tmp' string. Is that true ?!!

Joona is correct, but I wanted to expand on this a little.

There are several issues that can confuse this.

One is that, as Joona says, some or all of the temporary Strings may already
have been garbage collected, rather than still merely being "eligible" for
collection.

Another is that the compiler is within its rights (as I read the spec) to
re-write the code as if it said:

public static void main(String args[])
{
System.out.println("CDummy.");
for(int ii=10; ii>=0; ii--)
{
String tmp = Integer.toString(ii);
System.out.println(tmp);
tmp = null;
}
System.out.println("END");
}

or the equivalent (which is not expressible in Java) where the store used for
the "tmp" variable is overwritten after the inner loop has completed.

So it is possible that /all/ the temporary Strings have become eligible for GC
by the time we read the final println("END").

However, what the question is presumably trying to get at is that, if you
ignore the above complexities, then in a typical implementation the last
temporary String is not available for collection until main() returns.

The reason for that is quite simple, it's that although Java-the-language has a
concept of local variables with a scope smaller than a whole method, the
language understood by the JVM (i.e. the classfile format) does not have that
concept. In "JVM-speak" (never forget that JVM bytecodes are a high-level
language too -- at least as high-level as Java -- so the Java "compiler" should
really be called a translator) there are no named local variables, just a fixed
size list of "slots" which hold values that are local to each method
invocation. Those slots come into existence when the method is called, and
their contents only become eligible for GC (typically) when the method returns.

So the Java compiler (sorry, "translator") has used one of the slots to hold
the values of "tmp", and -- unless it either takes special steps to null-out
that slot before the method returns (which no standard compiler does AFAIK), or
happens to re-use that slot for some other variable -- then the last value of
"tmp" will still be in that slot until the method returns.

-- chris
 
R

Razvan

I choosed 10, the right answer is 11. The reason for this is the fact
that even if the variable tmp is out of scope it is STILL holding a
reference to the last 'tmp' string. Is that true ?!! At the above
mentionated line there is no way in the whole program to access any
temporary string. Normally they should ALL be garbage collected. Can
the out of scope variable tmp prevent the garbage collector from
collecting the last string ?




Regards,
Razvan


I really mess it up: the right answer was 10, I choosed 11. The
reason for this is that the out of scope variable 'tmp' holds a
reference to the last temporary string, thus this one cannot be
garbage collected. So, this is the question: can an out of scope
variable count as a VALID reference ?



Regards,
Razvan
 
J

Joona I Palaste

I really mess it up: the right answer was 10, I choosed 11. The
reason for this is that the out of scope variable 'tmp' holds a
reference to the last temporary string, thus this one cannot be
garbage collected. So, this is the question: can an out of scope
variable count as a VALID reference ?

As has already been said, there is nothing preventing objects whose all
references have gone out of scope from still existing. A legal Java
implementation could have a garbage collector that only ever runs when
the whole program exits, and then sweeps up every object ever created in
the program.
 
C

Chris Uppal

Razvan said:
So, this is the question: can an out of scope
variable count as a VALID reference ?

Depends on what you mean. For the JVM, the variable/slot is still valid, the
object is still refered to from that stack frame, and it can't be gc-ed. It
neither knows nor cares about the Java souce code. OTOH, as far as legal Java
is concerned, the variable has gone, it is dead, you cannot use it in any way,
and if that variable held the only reference to the object, then you cannot get
at the object either.

Where it gets interesting is in contexts that bridge both the worlds. E.g. in
a Java debugger, what the debugger sees is what the JVM is really doing, but
the chances are that it wants to present that to the user as if it were proper
Java. So it has a problem, does it "admit" that the slot, and hence the
reference, still exists (though no actual variable corresponds to it anymore),
or does it "pretend" that the reference has gone away ? Your choice, decide
which you'd rather see, and then write your debugger to work that way ;-)

-- chris
 
D

Doug Pardee

What Joona and Chris said. If I may add to this part:

Chris Uppal said:
The reason for that is quite simple, it's that although Java-the-language
has a concept of local variables with a scope smaller than a whole method,
the language understood by the JVM (i.e. the classfile format) does not
have that concept. In "JVM-speak" (never forget that JVM bytecodes are
a high-level language too -- at least as high-level as Java -- so the
Java "compiler" should really be called a translator) there are no named
local variables, just a fixed size list of "slots" which hold values that
are local to each method invocation. Those slots come into existence when
the method is called, and their contents only become eligible for GC
(typically) when the method returns.

So the Java compiler (sorry, "translator") has used one of the slots to
hold the values of "tmp", and -- unless it either takes special steps to
null-out that slot before the method returns (which no standard compiler
does AFAIK), or happens to re-use that slot for some other variable --
then the last value of "tmp" will still be in that slot until the method
returns.

Sun calls these "invisible objects" (not the term that I would have
chosen). They are discussed at
http://java.sun.com/docs/books/performance/1st_edition/html/JPAppGC.fm.html#997414
 
C

Chris Smith

It actually depends on the question. The question as written is
ambiguous. It could mean either of the following, for example:

1. How many object would it be legal for the garbage collector to have
collected?, or

2. How many objects would it be possible that the garbage collector
would have collected in the current version of the Sun reference
implementation of the Java virtual machine?

I also rephrased the questions here to avoid the matter of whether
objects have already been collected.

The answer to #1 is 11. The answer to #2 is 10. (Incidentally,
question #1 narrowly avoids a dispute I have had with Dale on
interpreting the JLS, but since the variable is out of scope I assume
that even Dale would agree with me here that the answer is 11.)

--
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

Forum statistics

Threads
473,744
Messages
2,569,483
Members
44,902
Latest member
Elena68X5

Latest Threads

Top