Hi Joerg,
Joerg Barfurth wrote:
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.
This was more or less a theoretical analysis, basically leading to the
cognition, that introducing a UNO release thread eventually leads to the
same problems as we currently see ("it somehow leaks memory").
From a theoretical standpoint there are only three "correct" solutions:
- destruct the objects synchronously,
- ensure objects are destructable asynchronously, or
- do not construct objects while doing UNO remote calls.
BUT, as the above solutions seem to be unreachable, I agree that the
most practical approach is to queue the UNO releases, despite that this
may introduce a performance penalty.
Ciao, Jörg
Kay
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
