Re: forcing finalize()
nukleus wrote:
In article <45ce0e0d$0$49206$14726298@news.sunsite.dk>,
=?ISO-8859-1?Q?Arne_Vajh=F8j?= <arne@vajhoej.dk> wrote:
nukleus wrote:
Btw, I just read some posts on memory allocation/deallocation issues,
and I did not quite expect the behavior described.
I thought that object is gc'ed when there are no references left.
Java does not use reference counting.
Objects that are not reachable from the executing program can be
GC'ed.
Interesting. But how do they know they are not reachable?
"They" the objects don't know. The garbage collector
works hard to find out.
Secondly, if i have a string and then set it to a new value,
does the old value become a subject to gc?
Yes.
Sting s = "abc";
s = "def";
There are some special handling for string literals where Java
only have one object for the same literal.
Well, i didn't mean string literal,
but string as such.
Any object instance that is unreachable by a chain of
sufficiently strong references[*] is eligible for garbage
collection.
[*] To support caches of various kinds, Java provides
some specialized weaker-than-normal reference types. I'm
not familiar with the ins and outs of all of them: weak
references, phantom references, unsubstantiated references,
unattributed references (a.k.a. plagiarism), and whatever
other flavors might exist. Some of these are too weak to
shield an instance from garbage collection, yet strong
enough to locate it if the collector hasn't reaped it first.
It's my understanding that String.intern() uses one of these
weaker forms, so even a String[**] literal could perhaps be
collected. (Probably not unless all the classes that contain
it are also collected, but I believe it's possible nonetheless.)
[**] I don't know what happens to Sting objects.
What happens to "abc" string in terms of deallocation?
Is it the same as new String("def")
meaning that there is no longer a reference
to "abc" and it, therefore, is subject to gc?
Ignoring the special handling of String literals, then
as soon as there are no way to reach an object it can be GC'ed.
Sorry, but I don't get it.
How does it know it can't reach something?
The garbage collector begins from a set of known "root"
references, and finds other references (or possible references)
in the Thread stacks. Then it follows all these references to
their referenced objects, and follows all the references found
inside those objects, and so on, until it's located every object
that is referencable. Everything not located is unreachable and
hence garbage, eligible for collection.
The details of how this search is carried out vary from one
implementation to another. I believe there's still a lot of
active research on how to make GC pleasanter in various ways.
How do I release memory held by StringBuffer?
Just let the reference run out of scope.
Well, but when I am in a loop, reusing the same string
buffer that has large amounts of buffer for each iteration,
what happens to the old data?
Should I just create a new buffer every iteration
just to make sure the old stuff gets gc'ed?
I am talking about 10s of megs of data being shuffled.
For specificity, let's consider two different loops:
// Loop A
StringBuffer buff = new StringBuffer();
for (...) {
buff.setLength(0);
... fill up buff and use it ...
}
// Loop B
for (...) {
StringBuffer buff = new StringBuffer();
... fill up buff and use it ...
}
Loop A uses the same StringBuffer over and over, changing its
contents each time around. Loop B creates a fresh StringBuffer
at each iteration. Which is more efficient? Much depends on
the nature of "use it." For example, if you "use it" by making
a String out of it, the String seizes ownership of the underlying
char[] array and retains it until the String itself becomes garbage.
In this (common) case, the only memory you're "recycling" are the
dribs and drabs that give a StringBuffer its StringBuffer-nature,
not the zillions of megabytes of character data its various
incarnations contain. On the other hand, if you work entirely
within the StringBuffer and never generate a String from it, the
multimegs may well be recycled by Loop A, garbage-collected by
Loop B.
--
Eric Sosman
esosman@acm-dot-org.invalid