«

Hi, I am doing some work with Java and C++ and am curious as to whether self
references in Java cause memory leaks.

For example:

class Test{
Object foo =this;
}

If I instantiate Test, the reference count of any Test object will never
become zero (as it always keeps a reference to itself) so long as the foo
variable is never re-assigned.

Does this present a problem for Java's garbage collection?

Thanks,
Novice

"Novice" <> wrote:
> Hi, I am doing some work with Java and C++ and am curious as to whether
self
> references in Java cause memory leaks.
>
> For example:
>
> class Test{
> Object foo =this;
> }
>
> If I instantiate Test, the reference count of any Test object will never
> become zero (as it always keeps a reference to itself) so long as the foo
> variable is never re-assigned.
>
> Does this present a problem for Java's garbage collection?
>

Garbage collection in Java does not use reference counting. Rather, most
simple gc systems use a mark-and-sweep method.

-- Adam Maass

"Adam Maass" <> wrote in message
news:...
|
| "Novice" <> wrote:
| > Hi, I am doing some work with Java and C++ and am curious as to whether
| self
| > references in Java cause memory leaks.
| >
| > For example:
| >
| > class Test{
| > Object foo =this;
| > }
| >
| > If I instantiate Test, the reference count of any Test object will never
| > become zero (as it always keeps a reference to itself) so long as the
foo
| > variable is never re-assigned.
| >
| > Does this present a problem for Java's garbage collection?
| >
|
| Garbage collection in Java does not use reference counting. Rather, most
| simple gc systems use a mark-and-sweep method.
|

Is there somewhere I can find this documented?

The impression I get from the very high level documents I've read on
java.sun.com's website is:
"The Java runtime environment has a garbage collector that periodically
frees the memory used by objects that are no longer referenced."

So if an object references itself and never stops referencing itself that
object will always have at least one reference.

Thanks,
Novice

In fact I found this article:
http://java.sun.com/docs/books/perfo...PAppGC.fm.html

on the sun website and it says that:
"Circular strong references don't necessarily cause memory leaks."

This statement doesn't seem to indicate that all objects which are no longer
referenced (except by themselves) will be removed/deleted.

In fact, it goes on further to say:
"although the VM might not actually collect these objects for an indefinite
amount of time"

Which to me says that the VM may not remove/delete these objects from memory
until the VM is shut-down.

Is there any reason to believe otherwise?

Thanks,
Novice

|
| The VM might not collect any object for an indefinite amount of time. So
yes,
| uncollected objects may remain in memory until the VM is shut down.
|

This to me is a problem - I mean server programs would eventually run out of
memory if they made use of classes with circular dependencies...

Can anyone provide any clarification on this?

Or do most people know to try to avoid circular dependencies?

Thanks,
Novice

"Novice" <> wrote:
> "Adam Maass" <> wrote:
> |
> | "Novice" <> wrote:
> | > Hi, I am doing some work with Java and C++ and am curious as to
whether
> | self
> | > references in Java cause memory leaks.
> | >
> | > For example:
> | >
> | > class Test{
> | > Object foo =this;
> | > }
> | >
> | > If I instantiate Test, the reference count of any Test object will
never
> | > become zero (as it always keeps a reference to itself) so long as the
> foo
> | > variable is never re-assigned.
> | >
> | > Does this present a problem for Java's garbage collection?
> | >
> |
> | Garbage collection in Java does not use reference counting. Rather, most
> | simple gc systems use a mark-and-sweep method.
> |
>
> Is there somewhere I can find this documented?

OK, this isn't exactly crystal-clear from the specs, but here's the
definition of an object's lifecycle:

http://java.sun.com/docs/books/jls/s...doc.html#74701

And here's the definition of the term "reachable," which is part of the
lifecycle definition:

http://java.sun.com/docs/books/jls/s...doc.html#44762


The short answer is that an object that refers to itself may be garbage
collected if there are no references to it from any live thread.

Java garbage collection does not use (a naive implementation of)
reference-counting.



-- Adam Maass

In article <bev5h3$18a$>,
Novice <> wrote:
>
>This to me is a problem - I mean server programs would eventually run out of
>memory if they made use of classes with circular dependencies...

The VM will always do garbage collection - and a complete garbage
collection if necessary - before reporting an out of memory condition.

The case of not having had anything collected until program shutdown
will only occur for programs that did not run out of memory during
execution.

>Can anyone provide any clarification on this?
>
>Or do most people know to try to avoid circular dependencies?

Circular dependencies aren't a problem. If you're using an
experimental VM, of course, you might want to make a point out of
checking its documentation on this point.

I believe some older VMs did conservative GC, which is a bit of a
mess.

Cheers
Bent D
--
Bent Dalager - - http://www.pvv.org/~bcd
powered by emacs

>>>>> "Novice" == Novice <> writes:

Novice> | The VM might not collect any object for an indefinite
Novice> amount of |time. So yes, uncollected objects may remain in
Novice> memory until the VM is shut |down.
Novice> |

Novice> This to me is a problem - I mean server programs would
Novice> eventually run out of memory if they made use of classes
Novice> with circular dependencies...

Novice> Can anyone provide any clarification on this?

Novice> Or do most people know to try to avoid circular
Novice> dependencies?


No. The JVM does not have to collect objects until it feels it wants
to. Maybe never.

However it is required to free all available memory before it throws
an out of memory error.

So, for instance, a JVM might choose not to GC until it runs short of
memory. This makes sense, as GC is expensive. Why do it if you don't
need to. If you are running out of memory, of course, this is a
different issue. Then you do need to.

In short, don't worry about circular dependencies. They will not cause
the GC problems. And generally don't worry about when objects that are
our of scope, are actually GC'd. Its an implementation issue, and it
will differ between JVM's.

Cheers

Phil

I think it might be worthwhile talking about the mark-and-sweep GC
that you had previously mentioned. Mark-and-sweep involves the GC
first looking at the main program and looking for object references
there, and "marking" them as valid. It then looks at the references
that those hold, marking them, and so on.

After it completes the marking, it then deletes the objects that
weren't marked, (since it has has a complete list of all the new'ed
objects), first calling finalize on the objects before removing the
memory.

Mark-and-sweep been in place since at least 1.1 (maybe before)..

"Adam Maass" <> wrote in message news:<>...
> "Novice" <> wrote:
> > "Adam Maass" <> wrote:
> > |
> > | "Novice" <> wrote:
> > | > Hi, I am doing some work with Java and C++ and am curious as to
> whether
> self
> > | > references in Java cause memory leaks.
> > | >
> > | > For example:
> > | >
> > | > class Test{
> > | > Object foo =this;
> > | > }
> > | >
> > | > If I instantiate Test, the reference count of any Test object will
> never
> > | > become zero (as it always keeps a reference to itself) so long as the
> foo
> > | > variable is never re-assigned.
> > | >
> > | > Does this present a problem for Java's garbage collection?
> > | >
> > |
> > | Garbage collection in Java does not use reference counting. Rather, most
> > | simple gc systems use a mark-and-sweep method.
> > |
> >
> > Is there somewhere I can find this documented?
>
> OK, this isn't exactly crystal-clear from the specs, but here's the
> definition of an object's lifecycle:
>
> http://java.sun.com/docs/books/jls/s...doc.html#74701
>
> And here's the definition of the term "reachable," which is part of the
> lifecycle definition:
>
> http://java.sun.com/docs/books/jls/s...doc.html#44762
>
>
> The short answer is that an object that refers to itself may be garbage
> collected if there are no references to it from any live thread.
>
> Java garbage collection does not use (a naive implementation of)
> reference-counting.
>
>
>
> -- Adam Maass

On Mon, 14 Jul 2003 17:01:33 -0400, "Novice" <>
wrote or quoted :

>This to me is a problem - I mean server programs would eventually run out of
>memory if they made use of classes with circular dependencies...

You are imagining Java gc works by reference counting where circular
references are a problem. See
http://mindprod.com/jgloss/reference.html and
http://mindprod.com/jgloss/garbagecollection.html
for how Java's mark sweep or generational gc works.

--
Canadian Mind Products, Roedy Green.
Coaching, problem solving, economical contract programming.
See http://mindprod.com/jgloss/jgloss.html for The Java Glossary.