gcj mingw32 and java memory footprint.

Mon Feb 17 18:11:00 GMT 2003

Hi!
Congratulations to your Mingw32 build of gcj!
I have just downloaded the compiler from Mohan Embars site and compiled the 
SWT-Application i am developing for one of my customers. I was surprised 
that it works without problems. The .exe is small enough to fit into a ~2 
mb installer. This makes distributing java programs much easier, because 
the jvm is not required anymore. It is also a great idea to bundle gcj with 
the swt-library.
There is one issue, which seems to be a general java problem:
The memory footprint of my application is as bad as with jre 1.4.1 
(hotspot). My app grows to about 20mb right in the beginning, which is 
shocking to anyone looking at the task-manager.
I guess memory footprint is a general problem of the design of the java 
language. It encourages people to encapsulate everything into 
classes/objects (like events...) and to hope they get cleaned away by the gc.
The garbage collector simply does not know when a program needs to be 
optimized for speed or wants to be lean in terms of memory footprint. For 
instance it might be good to be fast on Application startup, but then 
reduce the heap size to give room to other applications.
What do you think? Would it make sense to give programmers more control on 
garbage-collection at runtime. Perhaps with an additional API which allows to
* request the imidiate disposal of certain objects. (without running a 
complete garbage-collection cycle)
* telling the heap-mamagement to follow a grow / shrink strategy... (i 
don't like the idea of limiting the heap to a fixed size).
i'm not an expert on the internals of the java runtime, so maybe my 
suggestions don't make sense at all.
best regards,
norbert