Friday, December 12, 2003, 8:29:41 PM, Stephen McConnell wrote: [snip] >>>The trick is that a proxy is generated that holds a reference to the >>>actual component. If the proxy is finalized it knows that the component >>>it is referencing has no outstanding references - but the proxy has a >>>reference to the appliance managing the component - so the proxy invokes >>>the decommissioning cycle on the appliance which invokes decomissioning >>>actions on the component which results in component disposal. >>> >>> >> >>It's not accident that I asked this. It's something I waned to solve >>earlier. This proxy trick was occurred to me, but I found that it is not >>correct: >> >>a) It is possible that the finalize() of the component, or the >>finalize() of any other object referred by the component is already >>invoked before the finalize() of the proxy is invoked. So dispose() will >>find itself in an abnormal situation, where some of the object are >>already finalized, or even worst, just being concurrently finalized in >>another thread. >> > > No - its not possible. The proxy holds a hard reference to the > component so the component cannot be finalized before the proxy.
This what all programmer would thing first, but I believe it does not stand. At least I don't find anything the VM spec that states this. (But I find "12.6.2 Finalizer Invocations are Not Ordered" which is not too encouraging...) Anyway, just consider this example: O1 stores hard reference to O2, and O2 stores hard reference to O1. Now, if it would be guaranteed what you assume regarding the finalization order, it would be impossible GC this two objects because of the circularly decency. But, as a matter of fact, they can be GC-ed, so the assumption regarding finalization order must not strand. And still, what's about the normal VM termination and the never-finalized objects? I'm hurry to note: It's not that I want to dispute with you. I would love if I'm mistaken, because I would like to hook this damn GC too... but I didn't find solution yet. >>(Also, note that as I said earlier in this thread, seems to me that with >>Merling 3.2 transient objects were never GC-ed. Maybe that's a bug.) >> >> > > There is a special case with coponents that are maked as startup policy > enabled. (Ammm... I don't know what's "startup policy enabled" :), but these were plain simple components. They had no entry in block.xml or something like that... I smell bug here...) > They exist until the kernel is decommissioned. > > Stephen. -- Best regards, Daniel Dekany --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
