Leo Simons wrote:
Niclas Hedhman wrote:
I'm not into politics, but please explain why a "Socket Server" should hang around in memory if it is not referenced?
IIUIC, a socket server will be listening on a socket, i.e. the thread is blocked, and the thread management will maintain the reference to its Runnable entry and GC will not mark it as "garbage". No?
I doubt that's guaranteed....
class MyServer
{
initialize()
{
new Thread( new Runnable { /*...*/ } ).start();
}
}
I just tested this and the results I'm getting are that the instance is not GC'ed if a thread is runing.
nothing references the thread, only the thread references the runnable, only the runnable references the socket, nothing references myserver.
Yes, the thread management references the thread, but I think that's (allowed to be) a weak reference.
According to:
http://developer.java.sun.com/developer/Books/performance/performance2/appendixa.pdf
-------------
It’s important to note that not just any strong reference will hold an object in
memory. These must be references that chain from a garbage collection root. GC
roots are a special class of variable that includes
• Temporary variables on the stack (of any thread)
• Static variables (from any class)
• Special references from JNI native code
-------------
Potentially unsafe. Icky. Depends on some JVM characterstic. It seems to me the "principle of too much magic" applies. Better to be conservative.
Another point of view .... If a component anywhere in a system (including all components it aggregates) is subject to garbage collection *and* a no collection handling is provided - then all of these component will *not* be subject to the formal Avalon decommissioining sequence. I.e. disposal will never be invoked. That's potentially unsafe and icky.
Now, I think its vital to have a setup that reclaims resources in long-running appservers, and I think this is a cool feature Steve's putting into place, but I'm weary of changing default policies. An assembler had better known darn well a component can be reclaimed and make a conscious choice to enable that (the lifecycle tags seem feasible for that).
I'm also concerned about default policies - don't want to screw up the servers I'm running! What I have done is a bunch of tests the confirms to me that objects with active threads don't become candidates for GC (specifically - test results show that a component that creates a thread without any internal variable will only become a candidate when the thread ceases to execute and the component itself is not referenced).
I think the important questions are the default behaviours:
* when is a component deployed (subject to a lifestyle policy) - on startup if a startup activation policy is defined - on demand (the default)
* when is a component decommissioned (subject to lifestyle policy) - on release (under developer control), or - in accordance with a collection policy, or - on jvm exit
As far as I can see - the primary issue concerns pooled objects. In this scenario, there are two important factors. Firstly, a developer knows when they are invoking frequent component aquisitions - and as such a developer should actively release the aquired objects. But what if the developer does not? In this scenario the responsibility falls on the container to to declare to the lifestyle handler that the object is no longer available (irrespective of any resettable marker). The pool can then handle re-population by deploying a new instance as and when required. Keeping in mind that this is only of concern within the context of Merlin internals and given the more predictable behaviour of assured decommissioning - I'm in favour of the approach. However - I want to run some long term tests on some complex applications in order to get a better feeling for the implications and emergent patterns that fall out of this.
Cheers, Steve.
--
Stephen J. McConnell mailto:[EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
