This is the mail archive of the
kawa@sourceware.org
mailing list for the Kawa project.
Re: Kawa fails if used in multithreading
Per Bothner wrote:
On 08/03/2010 04:16 AM, Daniele Benegiamo wrote:
Placing a "synchronized" in front of ModuleContext.findInstance() (seems
to) solve the problem, but maybe it's too coarse-grained.
I already checked in that fix yesterday (revision 6645).
That would solve a race condition - I'm surprised it might solve
a deadlock, but I guess it could happen. Please clarify/verify
that 6645 fixes these deadlocks.
I tested 6647 and it works fine, no deadlocks or race conditions. The
strange thing about the deadlock is that it happens into
java.lang.Class.getDeclaredField(), maybe it is some bug in Sun's
implementation...
This showed up another problem: analyzing the PermGen space, it
continuously increase in time; with (very) high LOOPS values threads
dead due missing available PermGen space. It seems to depend on
reflection or leaking when compiling scheme programs: the number of
total loaded classes continuously increase in time as PermGen space. You
can monitor all this with the standard Java VisualVM (jvisualvm).
Could you try to follow up on this? What data is leaking and why?
I haven't used jvisualvm, but I have used jhat, which is useful for
chasing down leaks.
I don't attach any heap dump because they are too big (around some
hundred of MB each one). But attached you can find a screen-shot of
PermGen exhaustion; as you can see, the number of loaded classes
continue to increase.
I've also attached some screen-shots of main sources of instances after
1, 4 and 5 seconds of running the program (before the crash); I don't
know if that can help you. As you can see Object[], int[] and IntNum
instances are continuously growing occupying the most of resources.
Analyzing the heap dumps with both jvisualvm and jhat I've found a
discrepancy: jvisualvm reports a lot of classes named "$Lsstring$Gr",
each one instantiated 1 time only, jhat (that I've never used before, so
can be my fault) reports only 1 class instantiated 1 time... For sure
exists a lot of instances of that class, so seems jvisualvm is right.
Unfortunately I've not still found a way to count them.
Analyzing these "$Lsstring$Gr" instances, I've found that they have a
"fib" field that points always to different ModuleMethod instances:
Class name - % instances - instances - size
gnu.expr.ModuleMethod 0.5561269994989371 11554 (0.6%) 554592 (0.3%)
gnu.expr.ModuleMethod 0.20462370822651668 13926 (0.2%) 668448 (0.2%)
gnu.expr.ModuleMethod 0.47662061550387347 14695 (0.5%) 705360 (0.3%)
As a consequence, the number of "$Lsstring$Gr" should be (at least) the
same number...
Let me know if I can give you further details,
Daniele
P.S. I send the attachments to your private email address because the ML
daemon don't like them.