/LS,
I am not sure you argue with or against me, but you also fail to use the
proper terminology, and total solution of state transition.
I must stress to go back to the JLS and do the hardwork of understanding the
state transitions. All other texts I have seen so far fail to explain in
detail what actually happens.
For instance, a finalizer-reachable/finalizable object becomes
reachable(!)/finalized, just prior to the execution of the finalize() method
is called (because the object is basically assigned to the queue of the
finalizer thread).
Niclas
On Tuesday 16 December 2003 02:51, Leo Sutic wrote:
> > After the finalize method has been invoked for an object, <bold>no
> > further action is taken until the Java virtual machine has again
> > determined that there is no longer any means by which this object can
> > be accessed by any thread that has not yet died, <bolder>including
> > possible actions by other objects or classes which are ready to be
> > finalized, at which point the object may be discarded.
> > </bolder></bold>
> >
> >
> > INCLUDING POSSIBLE ACTIONS BY OTHER OBJECTS OR CLASSES
> > WHICH ARE READY TO BE FINALIZED
>
> Note:
>
> There's a difference between "discarded" and "finalized".
>
> If you have two objects, A and B, and A references B, and both of them
> are unreachable from the root set of references (i.e. both are eligible
> for GC), then A and B may be *finalized* in any order.
>
> However, B may not be *discarded* before A. That is, when A's finalize()
> runs, B may already be finalized. But B must still exist - the reference
> to B that A holds may not be an pointer into a random memory area that
> used to contain B.
>
> For the C++ people, B may have had its finalize() method run, but nobody
> has
> yet freed its memory.
>
> So the JVM can do this:
>
> 1. Figure out all objects eligible for GC. ("garbage objects")
>
> 2. Run finalize() on them in any order.
>
> 3. Free the memory associated with them in any order.
>
> Note that after step (2), no garbage object will do anything. Thus, the
> garbage is
> guaranteed to be "inert" - there will be no code that can possibly
> access
> these objects any more. A garbage object won't access another garbage
> object, becuase they are all finalized. A non-garbage object won't
> access
> a garbage object, because if it could, the garbage object would not be
> garbage.
>
> /LS
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
