doubt abt finalizer method

[chandu]

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

 

[zero]

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

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.

 

[Andrew McDonagh]

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

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.

 

[Roedy Green]

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

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

 

[Sanjay]

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

 

[Mandar Amdekar]

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.

 

[Thomas Hawtin]

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

 

[Mandar Amdekar]

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! "

 

[Roedy Green]

finalizers being
called on live objects

egad. under what circumstances does that happen?

 

[Stefan Ram]

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(); }}

 

[Stefan Ram]

(Sorry, this posting just supersedes another posting with
an inapplicable response.)

 

[Roedy Green]

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 don't think you are ever supposed to call finalize yourself. If you
did such a goofy thing on your own head be it.

 

[Stefan Ram]

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.

 

[Sanjay]

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?

 

[Thomas Hawtin]

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

 

[Chris Smith]

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.

--
www.designacourse.com
The Easiest Way To Train Anyone... Anywhere.

Chris Smith - Lead Software Developer/Technical Trainer
MindIQ Corporation

 

[Chris Smith]

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...)

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.

--
www.designacourse.com
The Easiest Way To Train Anyone... Anywhere.

Chris Smith - Lead Software Developer/Technical Trainer
MindIQ Corporation

 

[Chris Smith]

"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.

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.

--
www.designacourse.com
The Easiest Way To Train Anyone... Anywhere.

Chris Smith - Lead Software Developer/Technical Trainer
MindIQ Corporation

 

[Sanjay]

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

 

[Chris Smith]

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.

--
www.designacourse.com
The Easiest Way To Train Anyone... Anywhere.

Chris Smith - Lead Software Developer/Technical Trainer
MindIQ Corporation