weakreferences - my understanding

I

Indbond

hi all,
This is w.r.t. the Class WeakReference. The java docs says whenever an
object is weakly reachable i.e there is not strong or soft references
to it , the object will be garbage collected.

As i understand with this is that the object is no longer referred by
anyone in the active thread or in any other secondary thread so it
will be garbage collected But isn't this how the GC is suppose to
work? Whenever the reference count of the object is 0 it is eligible
to get garbage collected (after finalize is called ) so why is the
preference given to the object contained in the class WeakReference
for GC and not the other objects whose ref. count is 0

I hope i am clear with my question ?

regards
Indbond
 
R

Roedy Green

Whenever the reference count of the object is 0 it is eligible
to get garbage collected (after finalize is called ) so why is the
preference given to the object contained in the class WeakReference
for GC and not the other objects whose ref. count is 0

There are no reference counts. See
http://mindprod.com/jgloss/garbagecollection.html

The basic idea is first ordinary dead objects are garbage collected.
If ram is still tight, the gc algorithm may optionally start garbage
collecting objects with only a weak reference to them.
 
T

Tony Morris

Indbond said:
hi all,
This is w.r.t. the Class WeakReference. The java docs says whenever an
object is weakly reachable i.e there is not strong or soft references
to it , the object will be garbage collected.

No, the object is *eligible* for garbage collection
As i understand with this is that the object is no longer referred by
anyone in the active thread or in any other secondary thread so it
will be garbage collected But isn't this how the GC is suppose to
work? Whenever the reference count of the object is 0 it is eligible
to get garbage collected (after finalize is called ) so why is the
preference given to the object contained in the class WeakReference
for GC and not the other objects whose ref. count is 0

I hope i am clear with my question ?

regards
Indbond

http://java.sun.com/developer/Books/performance/performance2/appendixa.pdf

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

Filip Larsen

Roedy Green wrote
The basic idea is first ordinary dead objects are garbage collected.
If ram is still tight, the gc algorithm may optionally start garbage
collecting objects with only a weak reference to them.

As I understand it, there is no difference in the specified GC behaviour
for normal (non-referenced) objects and weak references, so weak
references get cleared in same situtations where normal objects become
garbage collected. Thisis different from soft references where
implementations are encouraged to apply memory-cache-like behaviour in
addition to the requirement of clearing soft references before signaling
out-of-memory.


Regards,
 
S

Silvio Bierman

Filip Larsen said:
Roedy Green wrote


As I understand it, there is no difference in the specified GC behaviour
for normal (non-referenced) objects and weak references, so weak
references get cleared in same situtations where normal objects become
garbage collected. Thisis different from soft references where
implementations are encouraged to apply memory-cache-like behaviour in
addition to the requirement of clearing soft references before signaling
out-of-memory.


Regards,

Which is theoretically very usefull. Unfortunately the JVM (Sun's at least)
could not care less and treats them just like plain garbage. I tried to
build a memory sensitive cache using Weak/Soft References but to no avail.
It is still listed as a JVM bug on the Sun website but I do not have the ID
at hand.

Silvio Bierman
 
R

Roedy Green

As I understand it, there is no difference in the specified GC behaviour
for normal (non-referenced) objects and weak references, so weak
references get cleared in same situtations where normal objects become
garbage collected. Thisis different from soft references where
implementations are encouraged to apply memory-cache-like behaviour in
addition to the requirement of clearing soft references before signaling
out-of-memory.

oops. I get these two confused often. See
http://mindprod.com/jgloss/soft.html
http://mindprod.com/jgloss/weak.html

I had this sorted out once and wrote little essays.
 
F

FISH

Filip Larsen said:
Roedy Green wrote


As I understand it, there is no difference in the specified GC behaviour
for normal (non-referenced) objects and weak references, so weak
references get cleared in same situtations where normal objects become
garbage collected. Thisis different from soft references where
implementations are encouraged to apply memory-cache-like behaviour in
addition to the requirement of clearing soft references before signaling
out-of-memory.


I believe Sun's own tutorial on the matter had the best way of
describing weak references. It used the metaphore of blocks
suspended by ropes and elastic bands. One or more ropes are
enough to carry the weight of the block, but once all the ropes
are removed the elastic bands will snap, and the block will fall.

There is one minor difference in behaviour between between non-
referenced and weak referenced objects - the ReferenceQueue can
be used with weak references to give some degree of control over
whether the weakly reachable object *will* actually become
available for garbage collection.


-FISH- ><>
 
P

Phillip Lord

Roedy> On Thu, 22 Apr 2004 08:32:59 +0200, "Filip Larsen"

Roedy> oops. I get these two confused often. See
Roedy> http://mindprod.com/jgloss/soft.html
Roedy> http://mindprod.com/jgloss/weak.html

Roedy> I had this sorted out once and wrote little essays.


The specification doesn't guarantee that there is any difference as
far as I can see. There's just this warm touchy-feely idea that
SoftReferences will get collected after the WeakReferences, and that
SoftReferences will be more memory sensitive. But as exactly what this
means is not clear it's up to the JVM.


Phil
 
A

Adam Maass

Roedy Green said:
There are no reference counts. See
http://mindprod.com/jgloss/garbagecollection.html

The basic idea is first ordinary dead objects are garbage collected.
If ram is still tight, the gc algorithm may optionally start garbage
collecting objects with only a weak reference to them.

My understanding of the spec is that the VM *will* collect
objects that are weakly reachable, and *may* collect objects
that are softly reachable.

Open question about how this all plays out in a generational GC
system.
 
I

Indbond

Thanks for pdf link.It cleared all my doubts.But there is no example
given for soft and phantom references.

Thanks
Indbond
 
J

John C. Bollinger

Adam said:
My understanding of the spec is that the VM *will* collect
objects that are weakly reachable, and *may* collect objects
that are softly reachable.

There is not much "will" applicable to Java-specified GC behavior. The
ones I can think of are: (1) if an object with a non-trivial finalizer
is selected for GC then its finalizer _will_ be invoked exactly once
before its memory is freed; (2) the GC _will_ make its best effort to
free sufficient memory to satisfy a requested allocation before the VM
throws an OutOfMemoryError. There is also one "will not" I can think
of: (3) the GC / memory management system _will not_ collect objects
that are strongly reachable.

Other than those guarantees, you have to go to the level of specific
implementations to be able to predict GC behavior. As others have
noted, at least some existing VMs make no observable distinction between
softly- and weakly-reachable objects with respect to when or whether
they are GC'd.


John Bollinger
(e-mail address removed)
 

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,482
Members
44,901
Latest member
Noble71S45

Latest Threads

Top