Re: Garbage collection
From: Chris Uppal (chris.uppal_at_metagnostic.REMOVE-THIS.org)
Date: 03/30/04
- Next message: Josef Garvi: "Re: Garbage collection"
- Previous message: Steve Webb: "Netbeans output window colors ?"
- In reply to: Josef Garvi: "Re: Garbage collection"
- Next in thread: Tony Morris: "Re: Garbage collection"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Tue, 30 Mar 2004 16:07:46 +0100
Josef Garvi wrote:
> Tony Morris wrote:
> > This is implementation dependant behaviour.
>
> Are you sure about this? (The other replies to my post seem to think
> differently). But if so, it has quite some implications for code writing.
Let's start with the bottom line: you don't have to worry about using circular
references, they will be cleaned up for you just fine.
However, Tony is right and this *is* implementation dependent.
What you have to realise is that there are *no* guarantees about how the GC
works, when it will run, or even whether there *is* a garbage collector. The
only thing that the spec tells you is that space won't be re-used while an
existing (reachable) object still needs it.
But there's more to it than just the spec. You also have to consider whether a
JVM implementation is usable for a specific purpose. Most JVMs are intended to
be general purpose, so they *have* to use a GC implementation that is able to
reclaim reference cycles. And they do. All of them.
So why go on about it being implementation dependent ? There are two points
here.
One is that you can't, or shouldn't, generalise from what one implementation
does to what *all* implementations do. For instance a JVM designed for hard
real-time processing might (at least as an option) not have GC at all (on the
grounds that it wouldn't be needed, and only slows things down and takes up
space). Another JVM implementation might use (only) reference counting if it
were targeted at applications that needed good incremental GC but never
generated significant reference cycles. The JVM implementer has a good deal of
freedom here as far as the spec goes. In practice of course, such
special-purpose JVMs are going to be the exception rather than the rule, and
ones that break the customary assumptions (even assumptions that aren't defined
as part of the spec) will make it very clear that they don't work in the
"normal" way.
The other point is that GC is a complex and delicate science. The state of the
art continues to advance, and what is true today may not be true tomorrow. The
Java spec (just for once) is sensible about this and doesn't attempt to pin
down implementations to techniques that might be superseded in the next few
years. As an example of this, although pure reference counting can never be
appropriate for a general-purpose JVM, GC schemes that use a hybrid of
reference counting and "classic" GC seem to be coming back into fashion in GC
research. One potential effect of that is that reference cycles might be
collected less readily than non-cyclic references -- objects might be finalised
later if they were in part of cycles than if they were not.
You can never tell, the spec gives no guarantees. But if you *need* to know
then the chances are that that's because of a flaw in your own design. If not
then you just have to ensure that your code is running on a JVM that implements
GC in the way you depend on.
So, yes it is implementation dependent, but no, you don't need to worry about
it.
-- chris
- Next message: Josef Garvi: "Re: Garbage collection"
- Previous message: Steve Webb: "Netbeans output window colors ?"
- In reply to: Josef Garvi: "Re: Garbage collection"
- Next in thread: Tony Morris: "Re: Garbage collection"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
