Hi Kay,
Kay Ramme - Sun Germany - Hamburg wrote:
-D- Defer the problem, e.g. delegate the release calls out of the
finalizer thread into another thread. But, because of this other thread
waiting for the mutex, this eventually leads to the same problems we see
currently. => IMHO also not viable.
Why?
The problem is not that releasing UNO objects (which live elsewhere)
happens too late or takes too long. The problem is that a sort of
deadlock occurs between the Java finalizer thread and another thread
that needs the garbage collected memory. When the finalizer thread is
blocked no garbage collection takes place any more, not even garbage
collection of objects that live entirely inside the JVM.
If you delegate release calls to a releaser thread, then finalization of
a UNO proxy object only involves submitting a release-job to a queue, so
the proxy object itself can be garbage collected and the JVM garbage
collection can continue happily collecting other objects. Thus the
ordinary threads will get their memory and can continue and will
ultimately release the mutex that blocks the releaser thread from
continuing. As noone waits for anything from the releaser thread, no
deadlock can occur.
The important point is that global Java memory management (which should
never be blocked for an extended period of time) and UNO reference
cleanup, which might become blocked for a while, are decoupled.
In the worst case a release call hangs for a while, so the release job
queue grows longer and longer. This is still better(and should block far
less memory) than getting no memory reclaimed in the entire JVM any more
at all.
Ciao, Jörg
--
Joerg Barfurth Sun Microsystems - Desktop - Hamburg
>>>>>>>>>>>>>>>>>> using std::disclaimer <<<<<<<<<<<<<<<<<<<<<<<
Software Engineer [EMAIL PROTECTED]
OpenOffice.org Configuration http://util.openoffice.org
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
