Martin Gallwey wrote:
Hi all,
OutOfMemoryError in a JVM happens because (1) too many objects are
reachable at a given point in time, or (2) the finalizer is blocked,
so that otherwise reclaimable garbage piles up.
The problem under discussion is 2. If we solve it by adding one or
multiple threads, we may run into 1 in different ways (e.g., if we
have only one thread to do the releases, that thread may block and its
queue may grow too large; if we have multiple threads, it is unlikely
that all of them block at the same time, etc.).
I've written a somewhat reduced test case (it's still a bit big), which
is suitable to demonstrate the problem. It is attached to issue i#57753#
here:
http://www.openoffice.org/nonav/issues/showattachment.cgi/31513/CrashFilter.tgz
If you untar it into the top level of a 2.0 SDK and do 'make' then 'make
run', you should run into problems fairly quickly. These problems do not
occur if you compile a version of java_uno.dll with the patches also
attached to issue #i57753#. These are checked into CVS on CWS 'mtg1' or
branch 'cws_src680_mtg1' here:
http://udk.openoffice.org/source/browse/udk/bridges/source/jni_uno/?only_with_tag=cws_src680_mtg1
I also run the JVM with the following parameters:
<param>-XX:MaxPermSize=128m</param>
<param>-XX:NewSize=128m</param>
<param>-XX:MaxNewSize=128m</param>
<param>-XX:PermSize=128m</param>
<param>-Xincgc</param>
<param>-Xmx512m</param>
<param>-Xms512m</param>
</vmParameters>
The above solution (huge heap, 10 finalizer threads) is too brute force
and needs to be finessed somewhat! But it should represent a starting
point for discussion.
Martin
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. However:
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.)
If there are no objections, I will happily add this to CWS mtg1.
-Stephan
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
