Niclas Hedhman wrote:
On Saturday 13 December 2003 03:29, Stephen McConnell wrote:
a) It is possible that the finalize() of the component, or theNo - its not possible. The proxy holds a hard reference to 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.
component so the component cannot be finalized before the proxy.
If you haven't gotten the point from Daniel and Timothy, you are wrong;
Holding a strong reference guarantee nothing, only if you can guarantee something else is holding a strong reference to the Proxy, in which case the finalize() on the proxy won't be called either....
This is the case - the proxy exists as a result of one of the following two cases:
(a) an activation of startup policy declared in the component metadata (b) an active request for a service via a service manager
In the first case - the managing appliance holds a reference to the proxy for the life of the appliance. In the second case the consumer holds a reference for as long as it needs to. Once the proxy reference is released - we then have the potential for the collection of the proxy by the garbage collector. The issue raised by Daniel is that the component may potentially be garbage collected before the proxy is garbage collected. My assertion is that this is not the case - on the grounds that the proxy holds the reference to the component - therefore the component will not be included in a GC pass until the proxy has be GC'ed. If the component held a reference to its proxy - then - and only then - would the proxy and component instance potentially be subject to GC'ing in the same pass. Timothy's email confirms the assumptions I'm making - in particular the fact that the reference by the proxy to the component instance cannot be ignored by a GC system - because finalize is a method acting of valid variables within the scope of the proxy class.
The point of contention is the subject of the unreachable status of the component instance. I agree that the specs on what is and what isn't unreachable are vauge - and I also would agree that the strategy in Merlin is leveraging demonstrated behaviour (in partiular - the proxy and component do *not* get gc'ed in the same pass). So on one hand we have a default behaviour which equates to hard references that depend on release by the client, while enabling more liberal policies that simply make a lot of sense with transient component handling. But I would also assert that you cannot (at the system level) do it differently - a variable assigned in a non-finalized instance cannot magically dissapear (and if it could the finalize method would make absolutely no sense). In particular - the implementation of finalize makes the proxy reachable by a thread and therfore all variables held by the proxy are reachable therefore all referenced instances cannot be colected before the proxy is itself collected (i.e. post execution of finalize).
Wow - this is getting deep!
IMHO, we DO have an issue. Adding harm to the above is the fact that GC is not guaranteed to run, other than "prior to throwing an OutOfMemoryException", so typically GC is delayed much longer than necessary.
I'm not experiencing this. In fact I'm experiencing GC runs during deployment - for example - if I run up James I will typically see a GC run before james is fully operational (JDK 1.4).
Not only does these objects occupy memory, which is easier to accept, but they may hold external resources, which should be released ASAP.
In which case you use release!
Furthermore, I would say that the ServiceManager.release() should be "compulsory", i.e. if the the object is GCed without release() being called, some form of "Serious Error in Usage" should be signalled.
But that's not possible. If release can be called, then the calling thread has a reference to the object to be released - therefore its not a candidate for garbage collection.
I wouldn't know if anything can be solved by using java.lang.ref.Reference classes, I am not experienced enough with them, but to me it seems they don't. It is still the GC that is in control of determination of whether an object is reachable or not, and the execution of the GC is non-deterministic.
Me personally .. I'm kind of happy with the Reference classes.
Cheers, Stephen.
--
Stephen J. McConnell mailto:[EMAIL PROTECTED]
|------------------------------------------------| | Magic by Merlin | | Production by Avalon | | | | http://avalon.apache.org/merlin | | http://dpml.net/ | |------------------------------------------------|
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
