Saturday, December 13, 2003, 6:34:55 AM, Stephen McConnell wrote: > Daniel Dekany wrote: [snip] >>>>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...) >> > > The proxy and the component are not finalized in the same pass. What > happens is that the actual component instance does not get onto the > finalize queue so long as the proxy has a has a hard reference to it. [snip]
As you probably already know, holding hard ref to something doesn't mean that is "accessible", thus it doesn't mean it couldn't be finalized. > The proxy itself gets finalized when there are no references to proxy > (which triggers the decommissioning of the component and the releasing > of the hard reference by the proxy to the component). At this point the > component can be finalized by the GC (which is ok because it has been > fully decommissioned). > >>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. >> > > I agree that the circular reference creates a case where the two objects > get placed into the queue at the same time - however - this is not our > case. In our case it is explicity the proxy that holds a hard reference > and according to the spec for soft and weak refs - the GC will collect > the proxy in a pass *before* attempting to collect the component > (because the component is referenced and therefore is excluded from > collection on the current GC pass). Well, it is possible that such rule exist (i.e. if there is no circular dependency then the finalization is ordered as the common sense dictates), but I didn't seen that written in "official" text. It is not clear for me if you have found something about that since that or not? If so, is that information VM-implementation independent? >>And still, what's about the normal VM termination and the >>never-finalized objects? >> >> > > Normal VM termination triggers a shutdown hook. The shutdown hook > triggers shutdown of the kernel. Kernel shutdown triggers > decommissioning of the root application block. Block decomissioning > triggers orderly decommissioning of the appliances contained within it. > Appliance decommissioning trigers disposal of the associated lifestyle > handler. The lifestyle handler maintains a soft references queue and > from this can locate and non-finalized component instances and invoke > component decommissioning. Are you sure? A soft reference to object O my cleared (=> get() returns null, so you can access O anymore) before O.finlaize() is invoked. So it can happen that you can't access O with soft reference, but it is not finalized yet either. >>(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...) [snip] > For any component the default collection policy is CONSERVATIVE which > basically transles to a component that will stick around until its > appliance terminates it. Alternative collection policies include > DEMOCRAT and LIBERAL. A DEMOCRAT sticks around unless there is memory > contention (soft ref) and a LIBERAL basically translates to a weak > ref. If I quess well, the appliance object stores a reference to the proxy (where the proxy wraps the actual component instance). And this reference (applicance -ref-> proxy) is soft for DEMOCRAT and weak for LIBERAL? And, for CONSERVATIVE it is hard? That would be a dangerous default for transient objects, as that will leak memory. > To kick in LIBERAL or DEMOCRAT collection policies you nbeed to declare > this at the component type level. For example, the following declares > that a component implementation expects weak reference semantics: > > @avalon.component name="fred" collection="liberal" I see... then cleanly the lack of "collection" setting causes the problem in my case. (However, I use the 3.2 release, and seems it doesn't understand "collection"...) -- Best regards, Daniel Dekany --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
