Win a copy of Five Lines of Code this week in the OO, Patterns, UML and Refactoring forum!
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Bear Bibeault
  • Ron McLeod
  • Jeanne Boyarsky
  • Paul Clapham
Sheriffs:
  • Tim Cooke
  • Liutauras Vilda
  • Junilu Lacar
Saloon Keepers:
  • Tim Moores
  • Stephan van Hulst
  • Tim Holloway
  • fred rosenberger
  • salvin francis
Bartenders:
  • Piet Souris
  • Frits Walraven
  • Carey Brown

Reg : Use of Finalize Method

 
Ranch Hand
Posts: 48
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
When GC is running it first checks if the class under considertaion has finalize(). If it does then GC schedules a background thread to collect it later. Hope all of you will accept this point.
But if we override the finalize() method, so that it does nothing, in every class we create aren't we decreasing the performance of the application??
 
Marshal
Posts: 67415
173
Mac Mac OS X IntelliJ IDE jQuery Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

But if we override the finalize() method, so that it does nothing,


Why would you do this?
bear
 
Arvind Varma
Ranch Hand
Posts: 48
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Nothing important but jus to poke around ....wanted to make sure that finalize() shud not abused and if it is overridden then it shud do the appropriate work(release the resources)... do confirm this or let me know if i'm off the track
 
Ranch Hand
Posts: 1873
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
hi arvind
if we don't implement finalize() then what so big performance "degrade"??? because it will run into "calling a method" overhead as we defined blank finalize() method but we have to gauge how much that would be..
world is made of practical ppl. as pointed our earlier, why one would make his/her own code performing less knowing all hazards before hands? only if this happens by a chance, we have to consider the effect of such behavior and in this case as i mentioned earlier, if the method is having no implemention then it should not be big overhead of calling.
regards
maulin
 
Arvind Varma
Ranch Hand
Posts: 48
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Maulin,
I wanted to make a point that its not imperative to implement finalize() in every class without knowing its consequences. Though everyone suggests its a good practice to have finalize method i think we should have finalize if and only if we have resources that need to be released and not in all cases.
Being 'practical' i believe the effect might be negligable when ur working with smaller projects but when you are in big projects working with hundreds of classes or more you might feel the effect.
I too thought the same way like you until i saw this article
web page
The author did have a valid point..so i posted the question in the forum and as i said earlier i was trying to get others views on it by poking around
Thanks
Arvind
 
Wanderer
Posts: 18671
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Though everyone suggests its a good practice to have finalize method
They do? I don't think this view is very widespread. Many people recommend against using finalizers most of the time. E.g. the Book of Joshua, Item 6: Avoid Finalizers. The usual objection to finalize() has little to do with GC performance, but rather with reliability. You can't guarantee that a finalizer will run in a timely manner, or even run at all. If an object is completely reclaimed by GC, then finalize() must run as part of that process - but there's no guarantee that any object will be completely GC'ed. So in most cases, whatever you're trying to do with finalize, it's better to try to find some alternate method of guaranteeing that necessary cleanup will be performed. The most popular choice is a try/finally block. But whether this is feasible depends on the application.
It is possible that a finalize(), even a blank one will degrade performance in some situations, as GC is forced to do more work to make sure objects are really available for GC. However I wan't able to produce a good example of this behavior - from my limited testing, a blank finalize has no real effect on performance. But maybe it depends on the JVM, or maybe there are other circumstances that can aggravate the situation. Here's the code I tried:

[ July 12, 2003: Message edited by: Jim Yingst ]
 
Bear Bibeault
Marshal
Posts: 67415
173
Mac Mac OS X IntelliJ IDE jQuery Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Though everyone suggests its a good practice to have finalize method


Like Jim, this is news to me. In fact, I have never had a reason to implement a finalize method.
I'd say that conventional wisdom would recommend against creating one unless you absolutely needed to. And, if you think you needed to, to think long and hard about whether your reasons are valid.
hth,
bear
[ July 12, 2003: Message edited by: Bear Bibeault ]
 
Ranch Hand
Posts: 35
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator


It is possible that a finalize(), even a blank one will degrade performance in some situations...


I don't think so. The reason is from Java API:

The finalize method of class Object performs no special action; it simply returns normally. Subclasses of Object may override this definition.

 
Jim Yingst
Wanderer
Posts: 18671
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Right, but if you're writing a garbage collector and you have determined that an object has no references, it can get tricky. Prior to reclaiming the object, you need to run the finalizer. If the finalizer actually does anything, there's a change that it could create a new reference to itself which would then prevent GC of the object. Which means that you may need to delay completely reclaiming the object until you have performed another scan to establish that after finalize(), the object is still eligible for GC. This takes additional time, and it's frequently unnecessary as most objects don't resurrect themselves in the finalizer. But how can you tell? Is there some way of avoiding this extra work in cases where you know resurrection is impossible? You would have to look at the finalize() method. Ideally maybe you would analyze the code of the finalize() method to determine whether it could create a new reference to the object. But, this is more work, and that's what we're trying to avoid. Alternately, you can at least catch the most common case by testing to see if the class even overrides finalize() at all. If it doesn't, well, we know in advance that Object's finalize()isn't going to resutrrect an object. So for any object that doesn't override finalize(), we can skip the extra scan to confirm GC eligibility. Cool. Can we go further? Well, maybe. I suppose that for classes that do override finalize() there may be some cases that are easy to analyze. E.g. if the method body is completely empty, that's pretty simple. But realistically how often would that occur? I suspect most GC implementors figure it's not worth the time to test for that particular case, as it's exceedingly rare. (Present discussion excepted._
So, it seems plausible that GC authors could decide to test for finalize() overriding as a way to speed up GC for the most common case. If that's the case, overriding finalize() could indeed degrade performance. Though as I said, I haven't been able to create a scenario that actually demonstrates this. Maybe I'm being too imaginative in my conjectures about how GC operates. I vaguely remember reading about this sort of thing sometime in the past, but can't seem to locate any authoritative articles on the matter. If anyone else has some useful links, please post 'em.
 
Pavel Halas
Ranch Hand
Posts: 35
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Originally posted by Jim Yingst:
... many, many, many words ...


Yes. You're good. I tried to find simple and reasonable answer. You found big trouble. You could earn big money on analysis...
I mean it very serious, if there're doubts.
Surely it depends on VM implementation. You're right.
 
Ranch Hand
Posts: 219
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Jim,
I am sure you might have already seen these.. but if not... ( or I may be totally off the radar here)
There are a set of 3 articles on garbage collection from developer works written by Sam Borman at IBM.
http://www-106.ibm.com/developerworks/ibm/library/i-garbage1/
http://www-106.ibm.com/developerworks/ibm/library/i-garbage2/
http://www-106.ibm.com/developerworks/ibm/library/i-garbage3/
These might be of some value..
Best Regards,
Prasad.
 
Jim Yingst
Wanderer
Posts: 18671
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thanks, Prasad. The article doesn't say much abou this issue - which may be because it isn'tan issue. But on page 2 we do have:

Objects associated with a finalizer are "registered" with the Finalizer class on creation. The result is the creation of a FinalReference object that is associated with the Finalizer queue and refers to the object to be finalized.


(This is in reference to changes made as of JDK 1.2.2.) It's not 100% clear what is meant by "objects associated with a finalizer". We know that all objects have a finalize() method, inherited from Object, but that inherited method doesn't do anything. The article makes it sound like not all objects are registered with the Finalizer class though. So I think it's reasonable to guess that "objects associated with a finalizer" does not include objects which merely inherit Object's finalize(), but it probably includes any class that overrides finalize(), and any further subclasses which inherit this overridden method. Of maybe I'm just seeing what I want to see here...
 
Jim Yingst
Wanderer
Posts: 18671
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Ah, here we go: see this JLS discussion of finalization and GC (with diagram). The dotted line from O to I is the shortcut we'd like to take to speed things up.
 
Ranch Hand
Posts: 1923
Scala Postgres Database Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Originally posted by Arvind Varma:
... Though everyone suggests its a good practice to have finalize method ...


Who everyone?
Drop some names, please!
In my opinion NOBODY (except Arvind Varma) suggests using of finalize mehtod.
In Future, please say: 'Though everyone except S. Wagner suggests ....'.
 
It's never done THAT before. Explain it to me tiny ad:
Thread Boost feature
https://coderanch.com/t/674455/Thread-Boost-feature
    Bookmark Topic Watch Topic
  • New Topic