soft references
1) The only difference that I know between soft references and weak references is that weak references are guaranteed to be garbage collected, however soft references would be garbage collected only if JVM is running out of memory. Now my question is would the JVM rather resort to using virtual memory in case required than garbage collecting soft references or would it garbage collect befor that.
2) Phantom references are objects on which finalize method has been run. So finalize method does not run on phantom references. Now when would you in real life use classjava.lang.ref.PhantomReference for large objects which you dont want to take the risk of being resurrected. But as per my information if youo don't override the finalize method, there is no chance of resurrection. Can anybody point out any real life examples when it might be useful to use phantom references.
[900 byte] By [
kilyasa] at [2007-10-3 5:21:29]
Virtual memory? You mean in terms of OS management of memory and in particular as it impacts disk swapping?I doubt the Sun VM knows whether disk swapping is occurring.
>Can anybody point out any real life examples when it might be useful to use phantom references.Distributed Garbage Collection
> I doubt the Sun VM knows whether disk swapping is> occurring.In that case Soft references might be slow in performance under certain conditions.Could you also advise on my question on phantom references.
> > I doubt the Sun VM knows whether disk swapping is
> > occurring.
>
> In that case Soft references might be slow in
> performance under certain conditions.
>
As would any class in java.
> Could you also advise on my question on phantom
> references.
Not really. I have seen suggestions that the only use is internal to a VM. I have no idea if that is correct.
I do not recall a question on the forums on their use except where it appeared that they were being used incorrectly.
> > > I doubt the Sun VM knows whether disk swapping
> is
> > > occurring.
> >
> > In that case Soft references might be slow in
> > performance under certain conditions.
> >
>
> As would any class in java.
true, but the whole point of a soft reference is better performance. Now it makes sense with a weak reference but in case of a softreference it would not be collected after the first cycle but once JVM is running out of memory, especially considering that a particular object might at the same time hold some strong references as well.
>
> > Could you also advise on my question on phantom
> > references.
>
> Not really. I have seen suggestions that the only
> use is internal to a VM. I have no idea if that is
> correct.
>
> I do not recall a question on the forums on their use
> except where it appeared that they were being used
> incorrectly.
As far as the phantom references are concerned, the only reason I have been able to find out uptil now is "Phantom references are for scheduling premortem cleanup actions" I am yet to find any examples of what these premortem operations could be.
http://saloon.javaranch.com/cgi-bin/ubb/ultimatebb.cgi?ubb=get_topic&f=1&t=014681
> 1) The only difference that I know between soft
> references and weak references is that weak
> references are guaranteed to be garbage collected,
> however soft references would be garbage collected
> only if JVM is running out of memory.
Untrue and not in agreement with the Javadoc. There is no guarantee that any object or reference is guaranteed to be garbage-collected, including weak references. Soft references are stronger than weak references and AFAIK they are GC'd before them if GC ever happens.
> Now my question is would the JVM rather resort to using
> virtual memory in case required than garbage
> collecting soft references or would it garbage
> collect befor that.
This question doesn't make sense. The JVM always uses virtual memory, because the operating system does. The JVM will GC when it feels it needs to. There isn't a strong relationship between these things.
> 2) Phantom references are objects on which finalize
> method has been run.
Nope. Phantom references are references, not objects. ' An object is phantom reachable if it is neither strongly, softly, nor weakly reachable, it has been finalized, and some phantom reference refers to it.'
> So finalize method does not run
> on phantom references.
Make up your mind. You just said they have already been finalized. Both statements are wrong.
> Can anybody point out any real life examples when it
> might be useful to use phantom references.
You would use phantom references plus a queue instead of finalize() methods, e.g. where you can't add finalize() methods to the classes but you still want to know when the instances have disappeared.
ejpa at 2007-7-14 23:28:26 >
> > 1) The only difference that I know between soft
> > references and weak references is that weak
> > references are guaranteed to be garbage collected,
> > however soft references would be garbage collected
> > only if JVM is running out of memory.
>
> Untrue and not in agreement with the Javadoc. There
> is no guarantee that any object or reference
> is guaranteed to be garbage-collected, including weak
> references. Soft references are stronger than weak
> references and AFAIK they are GC'd before them if GC
> ever happens.
Can you post any links which proves its not true. As per
http://java.sun.com/developer/technicalArticles/ALT/RefObj/
Weakly Reachable
An object is weakly reachable when the garbage collector finds no strong or soft references, but at least one path to the object with a weak reference. Weakly reachable objects are finalized some time after their weak references have been cleared. The only real difference between a soft reference and a weak reference is that the garbage collector uses algorithms to decide whether or not to reclaim a softly reachable object, but always reclaims a weakly reachable object.
>
> > Now my question is would the JVM rather resort to
> using
> > virtual memory in case required than garbage
> > collecting soft references or would it garbage
> > collect befor that.
>
> This question doesn't make sense. The JVM always uses
> virtual memory, because the operating system does.
> The JVM will GC when it feels it needs to. There
> isn't a strong relationship between these things.
Yes JVM will GC whenever it feels like but the whole idea behind having the reference classes was to The main feature of the reference classes is the ability to refer to an object that can still be reclaimed by the garbage collector for better memory mgmt.
>
> 2) Phantom references are objects on which finalize
> > method has been run.
>
> Nope. Phantom references are references, not objects.
> ' An object is phantom reachable if it is neither
> strongly, softly, nor weakly reachable, it has been
> finalized, and some phantom reference refers to it.'
>
yeah i should have been careful with my wording. An object is phantomly reachable when the garbage collector finds no strong, soft, or weak references, but at least one path to the object with a phantom reference. Phantomly reachable objects are objects that have been finalized, but not reclaimed.
> > So finalize method does not run
> > on phantom references.
>
> Make up your mind. You just said they have already
> been finalized. Both statements are wrong.
I was talking about instantiantions of java.lang.ref.PhantomReference that finalize method won't run on these objects.
>
> > Can anybody point out any real life examples when
> it
> > might be useful to use phantom references.
>
> You would use phantom references plus a queue
> instead of finalize() methods, e.g. where you
> can't add finalize() methods to the classes but you
> still want to know when the instances have
> disappeared.
finally I did find some reasonable explanation to these references
Phantom references
A phantom reference is quite different than either SoftReference or WeakReference. Its grip on its object is so tenuous that you can't even retrieve the object -- its get() method always returns null. The only use for such a reference is keeping track of when it gets enqueued into a ReferenceQueue, as at that point you know the object to which it pointed is dead. How is that different from WeakReference, though?
The difference is in exactly when the enqueuing happens. WeakReferences are enqueued as soon as the object to which they point becomes weakly reachable. This is before finalization or garbage collection has actually happened; in theory the object could even be "resurrected" by an unorthodox finalize() method, but the WeakReference would remain dead. PhantomReferences are enqueued only when the object is physically removed from memory, and the get() method always returns null specifically to prevent you from being able to "resurrect" an almost-dead object.
What good are PhantomReferences? I'm only aware of two serious cases for them: first, they allow you to determine exactly when an object was removed from memory. They are in fact the only way to determine that. This isn't generally that useful, but might come in handy in certain very specific circumstances like manipulating large images: if you know for sure that an image should be garbage collected, you can wait until it actually is before attempting to load the next image, and therefore make the dreaded OutOfMemoryError less likely.
Second, PhantomReferences avoid a fundamental problem with finalization: finalize() methods can "resurrect" objects by creating new strong references to them. So what, you say? Well, the problem is that an object which overrides finalize() must now be determined to be garbage in at least two separate garbage collection cycles in order to be collected. When the first cycle determines that it is garbage, it becomes eligible for finalization. Because of the (slim, but unfortunately real) possibility that the object was "resurrected" during finalization, the garbage collector has to run again before the object can actually be removed. And because finalization might not have happened in a timely fashion, an arbitrary number of garbage collection cycles might have happened while the object was waiting for finalization. This can mean serious delays in actually cleaning up garbage objects, and is why you can get OutOfMemoryErrors even when most of the heap is garbage.
With PhantomReference, this situation is impossible -- when a PhantomReference is enqueued, there is absolutely no way to get a pointer to the now-dead object (which is good, because it isn't in memory any longer). Because PhantomReference cannot be used to resurrect an object, the object can be instantly cleaned up during the first garbage collection cycle in which it is found to be phantomly reachable. You can then dispose whatever resources you need to at your convenience.
Arguably, the finalize() method should never have been provided in the first place. PhantomReferences are definitely safer and more efficient to use, and eliminating finalize() would have made parts of the VM considerably simpler. But, they're also more work to implement, so I confess to still using finalize() most of the time. The good news is that at least you have a choice.
http://weblogs.java.net/blog/enicholas/archive/2006/05/understanding_w.html
> Can you post any links which proves its not true. As
> per
> http://java.sun.com/developer/technicalArticles/ALT/Re
> fObj/
I don't need a link, I just need to understand English. You said 'weak
references are guaranteed to be garbage collected,
however soft references would be garbage collected
only if JVM is running out of memory'. This isn't supported by the Javadoc or the link you provided. What you quoted only says that if GC happens a weakly reachable object will be GC'd while a softly reachable is GC'd depending on 'algorithms'. This is not at all the same thing as 'weak references are guaranteed to be garbage collected', not even close.
> Yes JVM will GC whenever it feels like but the whole
> idea behind having the reference classes was to The
> main feature of the reference classes is the ability
> to refer to an object that can still be reclaimed by
> the garbage collector for better memory mgmt.
That relates to virtual memory how? Or is it just a new statement?
> I was talking about instantiantions of
> java.lang.ref.PhantomReference that finalize
> method won't run on these objects.
Reference please? This statement may or may not be true but there is no way of finding out so I don't know what the point it.
ejpa at 2007-7-14 23:28:26 >
> > fObj/
>
> I don't need a link, I just need to understand
> English. You said 'weak
then I would rather doubt your understanding of English and rather refer to urls I posted than your words.
> references are guaranteed to be garbage collected,
> however soft references would be garbage collected
> only if JVM is running out of memory'. This isn't
> supported by the Javadoc or the link you provided.
> What you quoted only says that if GC happens a
> weakly reachable object will be GC'd while a
> softly reachable is GC'd depending on 'algorithms'.
> This is not at all the same thing as 'weak references
> are guaranteed to be garbage collected', not even
> close.
>
read again. I dont like posting the same words again and again.
but always reclaims a weakly reachable object
does it ring a bell?
> > Yes JVM will GC whenever it feels like but the
> whole
> > idea behind having the reference classes was to
> The
> > main feature of the reference classes is the
> ability
> > to refer to an object that can still be reclaimed
> by
> > the garbage collector for better memory mgmt.
>
> That relates to virtual memory how? Or is it just a
> new statement?
I thought I mentioned "memory mgmt" and that would be to improve performance while using virtual memory would just do the opposite.
>
> I was talking about instantiantions of
> java.lang.ref.PhantomReference that finalize
> method won't run on these objects.
>
> Reference please? This statement may or may not be
> true but there is no way of finding out so I don't
> know what the point it.
when I post references you rely on your English. I have posted references. Read the post again its very explanatory.
OK, have it your way: weak references are guaranteed to be GC'd. You are in for some surprises if you rely on this guarantee. A counter-example is remarkably easy to construct.
Your claim that the finalizer of a PhantomReference is never run does not appear in the Javadoc, in http://java.sun.com/developer/technicalArticles/ALT/RefObj/
or in http://saloon.javaranch.com/cgi-bin/ubb/ultimatebb.cgi?ubb=get_topic&f=1&t=014681.
Where did you get it from?
ejpa at 2007-7-14 23:28:26 >
> I do not recall a question on the forums on
> their use except where it appeared that they
> were being used incorrectly.
I've found one fairly reasonable use case: Memory leak detection.
Instrument possible offending classes such that a phantom reference subclass is enqueued (also holding the type name) upon creation and bump an object count for that type.
A count for the relevant type is decremented when the reference is dequeued.
This can allow an app to expose live graphs showing object growth, and perform statistical analysis to "guess" at the most likely offending candidates.
The benefit is that this sort of stuff is much less costly than running an app under profiling - so you can detect memory leaks which only occur when an application is under high load (e.g. caused by dodgy non thread safe code for example).
~D
> OK, have it your way: weak references are guaranteed
> to be GC'd. You are in for some surprises if you rely
> on this guarantee. A counter-example is remarkably
> easy to construct.
public static void correct() throws FileNotFoundException
{
System.out.println("");
System.out.println("Executing method correct");
FileReader obj = recreateIt();
ReferenceQueue rq = new ReferenceQueue();
Reference wr = new WeakReference(obj, rq);
System.out.println("wr refers to object 4" + wr.get());
System.out.println("Now, clear the reference and run GC");
//Clear the strong reference, then run GC to collect obj
obj = null;
System.gc();
System.out.println("wr refers to object 5" + wr.get());
//Now see if obj was collected and recreate it if it was.
obj = (FileReader) wr.get();
if (obj == null)
{
System.out.println("Now, recreate the object and wrap it in a WeakReference");
obj = recreateIt();
System.gc(); //FileReader is pinned, this will not affect
//anything.
wr = new WeakReference(obj);
}
System.out.println("wr refers to object 6" + wr.get());
}
}
output
Executing method correct
wr refers to object 4java.io.FileReader@3a8c1d96
Now, clear the reference and run GC
wr refers to object 5null
Now, recreate the object and wrap it in a WeakReference
wr refers to object 6java.io.FileReader@3aa65d96
Once you have run the abovr code run the following
public static void correct() throws FileNotFoundException
{
System.out.println("");
System.out.println("Executing method correct");
FileReader obj = recreateIt();
ReferenceQueue rq = new ReferenceQueue();
Reference wr = new SoftReference(obj, rq);
System.out.println("wr refers to object 4" + wr.get());
System.out.println("Now, clear the reference and run GC");
//Clear the strong reference, then run GC to collect obj
obj = null;
System.gc();
System.out.println("wr refers to object 5" + wr.get());
//Now see if obj was collected and recreate it if it was.
obj = (FileReader) wr.get();
if (obj == null)
{
System.out.println("Now, recreate the object and wrap it in a WeakReference");
obj = recreateIt();
System.gc(); //FileReader is pinned, this will not affect
//anything.
wr = new WeakReference(obj);
}
System.out.println("wr refers to object 6" + wr.get());
}
and the output will change to
Executing method correct
wr refers to object 4java.io.FileReader@3a8fdee5
Now, clear the reference and run GC
wr refers to object 5java.io.FileReader@3a8fdee5
wr refers to object 6java.io.FileReader@3a8fdee5
I said a counter-example.
Also System.gc() is only a hint to the JVM (despite what it says in the Javadoc). This is all very well-known.
Actually the statement that 'weak references are guaranteed to be garbage-collected' makes no sense by itself, as there is no way of telling. Unless you want to run a large-scale test where weak references refer to weak references?
ejpa at 2007-7-21 11:00:18 >
> Exactly. Your second version provides a
> counter-example at step 5. The weakly-referenced
> object wasn't GC'd. However this proves nothing
> really because System.gc() is only a hint to the JVM
> (despite what it says in the Javadoc).
>
Come on buddie, how did you get this idea that I was trying to prove anything to you. No I am not!!!
This discussion is not about System.gc()
> This is all very well-known.
>
so?
> Actually the statement that 'weak references are
> guaranteed to be garbage-collected' makes no sense by
> itself, as there is no way of telling. Unless you
Anybody with a slightest hint of what weak references are is not going to say that.
> want to run a large-scale test where weak references
> refer to weak references?
ok?
> > references are guaranteed to be garbage collected,
> > however soft references would be garbage collected
> > only if JVM is running out of memory'. This isn't
> > supported by the Javadoc or the link you provided.
> > What you quoted only says that if GC happens
> a
> > weakly reachable object will be GC'd while
> a
> > softly reachable is GC'd depending on
> 'algorithms'.
> > This is not at all the same thing as 'weak
> references
> > are guaranteed to be garbage collected', not even
> > close.
> >
>
> read again. I dont like posting the same words again
> and again.
I assume that "GC always cleans up weak references" means, IF GC runs, then it is guaranteed to clean up WRs. It's a pretty strong given that GC never has to run unless the VM can't allocate memory it needs. It wouldn't make any sense for the mere use of a WR to change that.
jverda at 2007-7-21 11:00:18 >
You're not trying to prove anything, you're just posting two programs with different results for no reason at all?You don't seem to be amenable to rational discussion so I will finish here.
ejpa at 2007-7-21 11:00:18 >
> > > references are guaranteed to be garbage
> collected,
> > > however soft references would be garbage
> collected
> > > only if JVM is running out of memory'. This
> isn't
> > > supported by the Javadoc or the link you
> provided.
> > > What you quoted only says that if GC
> happens
> > a
> > > weakly reachable object will be GC'd
> while
> > a
> > > softly reachable is GC'd depending on
> > 'algorithms'.
> > > This is not at all the same thing as 'weak
> > references
> > > are guaranteed to be garbage collected', not
> even
> > > close.
> > >
> >
> > read again. I dont like posting the same words
> again
> > and again.
>
>
> I assume that "GC always cleans up weak references"
> means, IF GC runs, then it is guaranteed to
exactly!!!!
> clean up WRs. It's a pretty strong given that GC
> never has to run unless the VM can't allocate memory
True. But would this GC cycle be a minor cycle or a major collection. Yes it does depend on what algorithm is being used or chosen, Whether its Mark Sweep, Mark Compact, Generational, Reference counting or tracing? Different sorts of applications will have different requirements for garbage collection -- real-time applications will demand short and bounded-duration collection pauses, whereas enterprise applications may tolerate longer or less predictable pauses in favor of higher throughput. But e.g. in case it is generational IMHO a minor cycle might not guarantee the collection of soft references which would/might have to wait for a major cycle but would always collect weak references.
yes in case a "stop the world" collector algo is being used instead of a "concurrent one" there wouldnot be much difference between a SR and WR
> it needs. It wouldn't make any sense for the mere use
> of a WR to change that.
Ofcourse use of WR wouldnot change the GC cycle.
> > I assume that "GC always cleans up weak
> references"
> > means, IF GC runs, then it is guaranteed to
>
> exactly!!!!
Okay. I thought you were saying that it was guaranteed that WRs would be GCed no matter what--i.e. their existence could force a GC.
> True. But would this GC cycle be a minor cycle or a
> ...
***WHOOOSH!!!*** (< The sound of all that shrieking supersonically over my head.)
I'm very out-of-date and rusty on GC details, but I would assume from the wording of the docs that any GC will force GCing of WRs.
I supposed you could gin up a test, although it might be hard to make it work and would only show how one particular VM works. Tweak your heap size, full, etc. GC parameters so as to minimize the likelihood of a full GC. Set up your WR so that it's ready for GC, then do new Object(); in a tight loop to force an Eden GC (or whatever it's called). Er sumpin' like dat.
jverda at 2007-7-21 11:00:18 >
If the GC runs, weak references will be collected before soft references. In practice, I have seen the Sun JVM collect all weak references on a major collection, but still leave soft references around. I don't believe that either soft or weak references get collected on a minor collection (but am expecting to be proven wrong).
The Javadoc talks about soft references being used for a memory sensitive cache. In my opinion, this isn't a very good use, as the cached objects have to be pretty large to be worthwhile (with small objects, you have to clear a lot of references).
Where I believe that soft references are very useful is during the processing of a conversational request. For example, let's say that you're retrieving data from a database, and will respond back to the requester. You could do nothing, but then the conversation would be broken by an out-of-memory error. You could catch the OOM, but it's difficult to recover from one of those. Or you could wrap each row of data in a soft reference, terminate the retrieval if any of those references get cleared, and let the requester know that the request could not be processed.
The javadoc talks about weak references for use with a canonicalizing map, and this is an excellent use for them. The idea of a canonicalizing map is that you pass any arbitrary object in, and get a single canonical instance of that object out. Pretty much what String.intern() does (although it doesn't use weak references). Also useful when deserializing an object graph (although again, ObjectInputStream doesn't use weak references) -- if the program holds no strong references to the canonical object, then there's no need for the map to do so.
Phantom references are a whole 'nother beast. There was a relatively recent (last few months) post where I commented on their use; maybe it's still in my posting history.
