Thinking about the issue a little longer, I came to the following
conclusion:
1 I still think it is bad to have C++ objects that implement UNO
objects and do substantial things in their destructors, and that those
implementations should ideally be fixed.
Maybe when Kai & Kay proceed further with their grand work on improving
the multi-threaded behaviour of Office, they can catch some of these
kinds of problems. The CrashFilter test case showed up at least 4 cases
where the SolarMutex is locked in a destructor (SwXNumberingRules
destructor, XMLRedlineImportHelper destructor,
SfxBaseModel::removeEventListener ( Ref < XEventListener> ) and
SfxBaseModel::removeEventListener ( Ref < XDocEventListener )). It would
be easy to improve the granularity of the mutex in the SwXNumberingRules
destructor, but the others would require a little more work, and
possibly are only the tip of the iceberg anyway!
2 GC within typical JVMs of today seems to be flawed in that a
long-running finalize method can lead to OutOfMemoryError in cases
where this could be avoidable. We can make UNO more robust against
this problem, without unduly sacrificing performance: Asynchronously
shift the execution of potentially long-running finalize methods
(i.e., com.sun.star.bridges.jni_uno.JNI_proxy.finalize() and
com.sun.star.lib.uno.bridges.java_remote.ProxyFactory.Handler.finalize())
into some extra thread (finalize is already called asynchronously, so
delaying it a little further and moving it to yet another thread
should cause no problems). I experimentally added a
com.sun.star.lib.util.AsynchronousFinalizer and modified the two
finalize methods mentioned previously, and afterwards your testcase
runs fine (which also shows that the claim that one additional thread
should be enough is right). The advantage of this solution is that it
works for both the intra-process JNI bridge and the inter-process Java
URP bridge. (Also, once JVMs have matured to be more robust against
long-running finalize methdos, we can think of removing this "hack"
again.)
Sounds good. I think the reason that 1 extra finalizer thread didn't
work for me was because I didn't make the second call above
(com.sun.star.lib.uno.bridges.java_remote.ProxyFactory.Handler.finalize())
asynchronous also.
One thing that did occur to me was that we could use the 'Concurrent Low
Pause Collector' :
http://java.sun.com/docs/hotspot/gc1.4.2/#4.4.%20The%20Concurrent%20Low%20Pause%20Collector|outline
or the 'Throughput Collector'
http://java.sun.com/docs/hotspot/gc1.4.2/#4.2.%20The%20Throughput%20Collector|outline
However, both seem to only really work on multi-processor machines, with
both still using a single thread to do the 'major' collections. Neither
collector seems to change substantially between 1.4.2 and 1.5 either.
If there are no objections, I will happily add this to CWS mtg1.
Yes, please do. I will test it with the non-reduced test case.
Thanks,
Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
