 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
Java Forum / General / January 2006doubt abt finalizer method
hi i heard grabase collector vll reclaim the space for nameless objects immediately after execution.because no wa y after that stmt v can refer it like it vll reclaim spce after System.out.println((new A()).i));this stmt's execution it vll reclaim space.if this is correct the finalizer class of class A has to be executed but it is not executing(some print stm i hav written in fainalize() method); next cont i xpect out put of finalize() method tell me plese as earli possible "chandu" <chandu.penjarla@gmail.com> wrote in news:1135960261.446106.117170 @g47g2000cwa.googlegroups.com: > hi > i heard grabase collector vll reclaim the space for nameless objects [quoted text clipped - 7 lines] > cont i xpect out put of finalize() method > tell me plese as earli possible I gave up on decyphering your message after the first sentence. Please write correct sentences. I appreciate that not everyone speaks perfect English, but I'm sure you can do better than this.  SignatureBeware the False Authority Syndrome > hi > i heard grabase collector vll reclaim the space for nameless objects [quoted text clipped - 7 lines] > cont i xpect out put of finalize() method > tell me plese as earli possible No, the object becomes immediately unavailable for use, but when it actually gets garbage collected is the same as any object - its up to the garbage collector to decide. So there is no difference between those and other objects. >hi >i heard grabase collector vll reclaim the space for nameless objects [quoted text clipped - 7 lines] > cont i xpect out put of finalize() method >tell me plese as earli possible I will first attempt a translation. I have never seen English like that. I would be curious to learn how it came about. I heard the garbage collector will reclaim the space for nameless objects e.g. new Thing() in an expression not assigned to a variable) immediately after execution because there is no way a variable can refer to it. For example, it will reclaim space after System.out.println ( (new A()).i)); This statement's execution will reclaim space. If this is correct the finalizer for class A has to be executed, but when I try it, I discover the finalizer is not being called. Please explain this as soon as possible. First of all there is no guarantee the finalizer will be called. Java won't call it unless it is desperate for space. In a simple test you will exit without any finalizers called. // Force finalize methods to be run on exit // Without this, unreachable objects may not // have had finalize run when you quit. System.runFinalizersOnExit( true ); Next the finalizer has to have a particular pattern: protected void finalize() throws Throwable {...} Next finalize is an almost deprecated feature of Java. It is better to keep track yourself of which elements need some sort of close called, the way you do with files. For more details see http://mindprod.com/jgloss/finalize.html SignatureCanadian Mind Products, Roedy Green. http://mindprod.com Java custom programming, consulting and coaching. Roedy, Coming back to deprecating of this feature, I would say it was a good feature, of course you need to make sure that it gets executed (runFinalizerOnExit and the signature). so many times it happens that you dont want to relinquish some objects unless the parent object is GC'd. I think I am trying to recollect one such experience of mine, but this may not hold good if the parent object is a singleton. What do you say? Sanjay runFinalizerOnExit and shutdown hooks (if any are added) can interfere, leading to mysterious synchronization behavior. Avoid it at all costs. You're much better off keeping track of what you're creating and what you don't need handles to anymore, yourself. > runFinalizerOnExit and shutdown hooks (if any are added) can interfere, > leading to mysterious synchronization behavior. Avoid it at all costs. What feature of shutdown hooks causes mysterious synchronisation behaviour? There can be problems with refusing threads to start, but I'm not aware of any problem along the lines of those afflicting finalisers. Tom Hawtin SignatureUnemployed English Java programmer http://jroller.com/page/tackline/ See http://java.sun.com/j2se/1.4.2/docs/guide/misc/threadPrimitiveDeprecation.html (snipped) "Because it is inherently unsafe. It may result in finalizers being called on live objects while other threads are concurrently manipulating those objects, resulting in erratic behavior or deadlock. While this problem could be prevented if the class whose objects are being finalized were coded to "defend against" this call, most programmers do not defend against it. They assume that an object is dead at the time that its finalizer is called. Further, the call is not "thread-safe" in the sense that it sets a VM-global flag. This forces every class with a finalizer to defend against the finalization of live objects! " On 2 Jan 2006 14:07:39 -0800, "Mandar Amdekar" <mandar.amdekar@gmail.com> wrote, quoted or indirectly quoted someone who said : >finalizers being >called on live objects egad. under what circumstances does that happen? SignatureCanadian Mind Products, Roedy Green. http://mindprod.com Java custom programming, consulting and coaching. Roedy Green <my_email_is_posted_on_my_website@munged.invalid> might have written, quoted or indirectly quoted something like: >>finalizers being >>called on live objects > egad. under what circumstances does that happen? I just made up this: public class Main { protected void finalize() throws Throwable{ super.finalize(); } public void alive(){ java.lang.System.out.println( "I am." ); } public static void main( final java.lang.String[] args )throws Throwable { final Main main = new Main(); main.finalize(); main.alive(); }} > I just made up this: > [quoted text clipped - 3 lines] > public static void main( final java.lang.String[] args )throws Throwable > { final Main main = new Main(); main.finalize(); main.alive(); }} I don't think you are ever supposed to call finalize yourself. If you did such a goofy thing on your own head be it. SignatureCanadian Mind Products, Roedy Green. http://mindprod.com Java custom programming, consulting and coaching. Roedy Green <my_email_is_posted_on_my_website@munged.invalid> might have written, quoted or indirectly quoted something like: >I don't think you are ever supposed to call finalize yourself. >If you did such a goofy thing on your own head be it. I have canceled the message you replied to, /and/ - to make sure - also have superseded it -- but to no avail. But, since you already have replied, let me quote JLS3, 12.6: "A finalizer may be invoked explicitly, just like any other method." OK, it might still be goofy to do so. Well, was it about the safety of finalize that we were discussing? Any way, its hard for me to imagine how the finalize will be called on an object which is not out of scope. Just reiterating Roedy's question again. >finalizers being >called on live objects egad. under what circumstances does that happen? > Well, was it about the safety of finalize that we were discussing? > Any way, its hard for me to imagine how the finalize will be called on > an object which is not out of scope. Objects are never "in scope" or "out of scope". They exist or they don't. (Roedy...) > >finalizers being > >called on live objects > > egad. under what circumstances does that happen? When you call System.runFinalizersOnExit and there exists any daemon thread anywhere in the application, it's almost guaranteed to happen. It's not necessarily guaranteed to cause deadlock or race conditions, but it very well might. Signaturewww.designacourse.com The Easiest Way To Train Anyone... Anywhere. Chris Smith - Lead Software Developer/Technical Trainer MindIQ Corporation >When you call System.runFinalizersOnExit and there exists any daemon >thread anywhere in the application, it's almost guaranteed to happen. >It's not necessarily guaranteed to cause deadlock or race conditions, >but it very well might. With System.runFinalizersOnExit( true ) does it run finalize on ALL objects even reachable ones, or just unreachable ones? If reachable ones too, I think that deserves a gotcha. I would never have expected that. SignatureCanadian Mind Products, Roedy Green. http://mindprod.com Java custom programming, consulting and coaching. > With System.runFinalizersOnExit( true ) does it run finalize on ALL > objects even reachable ones, or just unreachable ones? All objects. > If reachable ones too, I think that deserves a gotcha. I would never > have expected that. To me, "gotcha" implies that there's some surprising aspect of an API, but you should learn that bit and then still use it. This doesn't fall into that category. If you can convince people not to use the API, then go for it. Signaturewww.designacourse.com The Easiest Way To Train Anyone... Anywhere. Chris Smith - Lead Software Developer/Technical Trainer MindIQ Corporation (Sorry, this posting just supersedes another posting with an inapplicable response.) > See > http://java.sun.com/j2se/1.4.2/docs/guide/misc/threadPrimitiveDeprecation.html > > (snipped) > > "Because it is inherently unsafe. It may result in finalizers being It would help if you quoted what you are replying to. The message you appear to be replying to asks: "What feature of shutdown hooks causes mysterious synchronisation behaviour?" Your reply appears to have nothing to do with the question. Indeed, the deprecations mentioned in the linked page were made years before the shutdown hook feature was added. Tom Hawtin SignatureUnemployed English Java programmer http://jroller.com/page/tackline/ > "Because it is inherently unsafe. It may result in finalizers being > called on live objects while other threads are concurrently [quoted text clipped - 3 lines] > programmers do not defend against it. They assume that an object is > dead at the time that its finalizer is called. Your reply describes runFinalizersOnExit. It is not an accurate description of shutdown hooks. These latter things were added to provide a SAFE answer to exactly those circumstances in which runFinalizersOnExit is appealing but unsafe. Convincing people to avoid shutdown hooks because of the unsafeness of runFinalizersOnExit would be quite counterproductive. Signaturewww.designacourse.com The Easiest Way To Train Anyone... Anywhere. Chris Smith - Lead Software Developer/Technical Trainer MindIQ Corporation Another question from myside, I have an object which is a singleton. Now when this object was constructed it created an object, let us say 'context' object. This 'context' is the only way for JDBC connection, Logger objects, and set of application cached resources. Now the 'context' object expects a free() API to be called explicitly after the parent object is done with 'context'. The parent object which is holding 'context' really doesnt know when to free this 'context' simply because parent class provides API's that use this 'context'. Now my question is Can I safely assume that the parent class will never get GC'd (Since its a singleton) and not bother about free'ing the context. Also this class has overridden finalize which calls free on this object( Defensive in nature ;) ). P.S: I can think of one way which is to create the context object in every API, but rest assured that this is not very performant. Thanks Sanjay > Another question from myside, Don't worry about the garbage collector collecting objects that you're still using. If you can still use the object, the garbage collector will not collect it. There is nothing you can do wrong that will change that fact. Worrying about that happening is just wasted time. Signaturewww.designacourse.com The Easiest Way To Train Anyone... Anywhere. Chris Smith - Lead Software Developer/Technical Trainer MindIQ Corporation Chris, May be my question was not very clear, but what I meant is >Don't worry about the garbage collector collecting objects that you're >still using. In the scenario that I mentioned I wouldnt have to worry about final()? Right? Sanjay > Coming back to deprecating of this feature, > > I would say it was a good feature, of course you need to make sure that > it gets executed (runFinalizerOnExit and the signature). Finalizers are not actually deprecated (Roedy said "almost" for good reason). You should, though, be very careful about how you use them, and you should NEVER use runFinalizersOnExit. Finalization needs to be confined to very small objects that are essentially nothing more than thin wrappers for native resources. One big reason for this is that finalization delays garbage collection... if you run into a situation where the main objects filling the heap have overridden finalize() methods, you can get an unnecessary OutOfMemoryException. The more and the larger the finalizable objects on the heap, the higher the chance that this may occur. > so many times it happens that you dont want to relinquish some objects > unless the parent object is GC'd. So many times? If you are interested in keeping an object, then don't throw away your reference to it. If this happens often, you are doing something seriously wrong. Signaturewww.designacourse.com The Easiest Way To Train Anyone... Anywhere. Chris Smith - Lead Software Developer/Technical Trainer MindIQ Corporation Free MagazinesGet these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...
|
Reply to this Message
|
 Sign In
 Join
 My Latest Posts My Monitored Threads My Blog My Photo Gallery My Profile My Homepage Start New Thread Enable EMail Alerts Rate this Thread
|
©2008 Advenet LLC Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.