This is the mail archive of the
kawa@sourceware.org
mailing list for the Kawa project.
Re: Kawa fails if used in multithreading
On 08/05/2010 05:08 AM, Daniele Benegiamo wrote:
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...
The "$Lsstring$Gr" is the mangling of "<string>", which is the "file name"
of the string-input-port that eval uses - see
gnu.mapping.CharrArrayInPort.stringPath.
The class compiled for each module defaults to matching the main part of the
input file name - hence the "<string>".
It's possible jhat gets confused by many classes with the same name
- I could make a temportary patch to generate a new class name each time.
The fib field contains the value of fib as a Procedure object.
So the still-answered question is why the $Lsstring$Gr classes aren't
getting garbage-collected.
More later ...
--
--Per Bothner
per@bothner.com http://per.bothner.com/