[kaffe] memory leak in jit3 ?

Dalibor Topic robilad at yahoo.com
Sat Dec 28 10:03:35 PST 2002


Hi,

I've taken a second look at the pure java zip from GNU
Classpath.
I compared memory consumption using -verbosemem on
i386-linux with
jit3. I saw a big difference between jit-temp-data for
the pure java
zip and native zip version.

Here are the stats for the pure java version:

<GC: heap 8192K, total before 7595K, after 5119K
(73072/24090 objs)
 37.5% free, alloced 2526K (#50620), marked 344K,
swept 2475K (#48982)
 104 objs (2K) awaiting finalization>
Memory statistics:
------------------
    j.l.String: Nr   1464  Mem     57K    
other-nowalk: Nr      4  Mem      0K
  obj-no-final: Nr   1704  Mem     49K     
prim-arrays: Nr   1505  Mem    185K
    ref-arrays: Nr     21  Mem      9K       
j.l.Class: Nr    195  Mem     30K
     obj-final: Nr    202  Mem      4K   
java-bytecode: Nr   1265  Mem     55K
     exc-table: Nr    101  Mem      5K         
jitcode: Nr   5187  Mem    327K
   static-data: Nr     76  Mem      2K       
constants: Nr    167  Mem    118K
   other-fixed: Nr   8357  Mem    276K          
dtable: Nr    165  Mem     11K
       methods: Nr    167  Mem    225K          
fields: Nr    105  Mem     15K
    utf8consts: Nr   3031  Mem    147K      
interfaces: Nr     93  Mem      1K
         locks: Nr      0  Mem      0K    
thread-ctxts: Nr      8  Mem     48K
       gc-refs: Nr    196  Mem      4K   
jit-temp-data: Nr     74  Mem   3419K
j.l.ClassLoade: Nr      1  Mem      0K             
jar: Nr      2  Mem    121K

Here are the stats for the native zip version:

<GC: heap 5120K, total before 2339K, after 1783K
(29609/19183 objs)
 65.2% free, alloced 891K (#11223), marked 297K, swept
555K (#10426)
 68 objs (1K) awaiting finalization>
Memory statistics:
------------------
    j.l.String: Nr   1460  Mem     57K    
other-nowalk: Nr      4  Mem      0K
  obj-no-final: Nr   1924  Mem     54K     
prim-arrays: Nr   1478  Mem    130K
    ref-arrays: Nr     19  Mem      8K       
j.l.Class: Nr    185  Mem     28K
     obj-final: Nr    440  Mem     10K   
java-bytecode: Nr   1264  Mem     54K
     exc-table: Nr    101  Mem      4K         
jitcode: Nr    495  Mem    189K
   static-data: Nr     66  Mem      2K       
constants: Nr    157  Mem    110K
   other-fixed: Nr   7988  Mem    304K          
dtable: Nr    157  Mem     11K
       methods: Nr    157  Mem    213K          
fields: Nr     95  Mem     13K
    utf8consts: Nr   2886  Mem    141K      
interfaces: Nr     90  Mem      1K
         locks: Nr      0  Mem      0K    
thread-ctxts: Nr      8  Mem     48K
       gc-refs: Nr    186  Mem      4K   
jit-temp-data: Nr      8  Mem    191K
j.l.ClassLoade: Nr      1  Mem      0K             
jar: Nr     14  Mem    201K

The funny thing is that the jit-temp-data doesn't go
away after a
while, as the name "temp-data" implies. My question is
: how can I
figure out if this is a memory leak?

This seems to be the reason why the pure java zip
needs approximately
3 MB of memory more than the native version.

I've also looked at the JanosVM 0.8 sources for jit3
and found that
they are using a resetConst call to reset the constant
pool. There is
no such thing in current kaffe sources. Could merging
in the JanosVM
jit3 changes have a positive result on jit-temp-data
usage ?

best regards,

dalibor topic

__________________________________________________
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com




More information about the kaffe mailing list