Jar Files and memory footprint...

[Maxim Kizub]

Hello.

Anyway, I belive there is a memory leak somewere...
You see - kaffe reports usage of 35 Mb for full
compilation, and this number grows constantly
(from 8 Mb to 35 Mb for compilation of kiev itself)
at compilation time, not simply allocating
30 Mb and growing from 30 to 35.

I have an internal profile for my compiler.
You may invoke it with "-debug profile" switch.
It counts all allocation/deallocation of
my own objects (without system objects). It
shows, that kaffe GC is about the same quality
as Sun's (I do not mean speed - I mean how
precise it is). An I did tests for per-object
memory allocation (18 bytes for kaffe vs 16 for Sun).
I do not see any other reason, except memory leak.
Well, it may or may not be related to jar, but
I do belive it's there.

PS There was an error with mail delivery
for kaffe at rufus.w3.org
My message about the way to adding extensions
was lost :-(
In short - I agree that this sources have to
be separated from other sourses as much as possible.
I'm currently working on this. But it's not possible
to make it a separate engine, since extensions should
work both with jit and interpreter.
Currently _all_ code my is wrapped in
#ifdef PARAM_CLASSES
// my code
#else
// you original code without changes
#endif
I'm currently moving as much as possible
to separate files.

PPS Type parametrization already works. But...
looks like I need method pointers too, or I need
to make too many changes in my compiler...
I'd better delay submitting of my code until
method pointers will work too ;-)


Godmar Back wrote:
> 
>  Maxim,
> 
> >
> > Godmar, this may be the reason of enormouse
> > memory usage for kiev compiler too, isn't it?
> >
> > We've fixed one memory leaking bug with zip files,
> > and I get 50% of memory usage decrease.
> > There may be another memory leak bug somewere
> > there. Remember my statistic - it was
> > 50-60 Mb for kaffe before bugfix and about 35 Mb
> > after, while Sun spends only 8 Mb. I expect kaffe
> > to spend not more 10-12 Mb normally, so, there
> > must be another bug like that fixed one.
> 
> Actually, the way I interpret Amancio's numbers is that there may not
> be a memory leak at all.
> 
> Kaffe simply mmaps all the jar files it accesses, and such files
> are never unmapped.  However, ps reports them as memory usage.
> 
> We could add a switch or option to kaffe that disables mmapping
> jar files, at the costs of more system calls.  Remember that mmapping
> jar files also helped us overcome the problems with not being able to
> use stdio when from these files.
> 
> I do not know enough about how various OSs actually implement mmap
> to know whether mmapping files is costly.  However, in an OS like Linux
> that integrates buffer cache and virtual memory, I don't see any reason
> why we should bother to avoid mmap.  Some of the BSDs might be a slight
> disadvantage here.  If somebody has more insight in these matters, we'd
> certainly like to know about it.  Also, I think in linux the /proc system
> provides information about what regions of the virtual addr space of a
> process are used.
> 
> We would certainly like to disable mmap on systems that merely fake it
> by reserving memory and copying the data from the disk.
> 
> Jason Baker is working on further reducing the memory footprint of
> kaffe.  The next target is the ridiculously large 10 byte per object
> overhead we are currently paying.
> 
>         - Godmar