maximum memory for gcj-compiled executable?

[Boehm, Hans]

I would be very interested in more information about an application that grows to 100MB, if it never has more than 10MB of live data.  In particular, the GC log, with the GC compiled without -DSILENT would be interesting.  That can theoretically happen, but I've never seen it, and it should be extremely unlikely.

I believe the gcj collector is always compiled to never shrink the heap, which is its default.  Thus an application with a high peak memory usage would continue to run with a large heap.  On some platforms the collector does have support to unmap entirely empty pages if they haven't been needed for a while.  This might solve this problem.  (Entirely empty pages are usually much more common than you might think.)  It has been tested less than the default configuration.  It should work, though you probably have to turn it on rather manually with -DUSE_MUNMAP.

Is there a reason to prefer command line arguments  to environment variables for setting the heap size?  I would prefer the latter, both because it's already done that way in later GC versions, and because the code can be isolated to the GC.  (I think Sun compatibility is not an issue here.  The executable command line is different anyway, and I definitely don't want to impose a maximum heap size by default.)

There are also some known reasons that heap size is currently suboptimal, but these shouldn't normally add more than 10MB or so to the heap:

1) The root size is way too big.  This has been discussed here before, and I think we agree on at least an approach for fixing it.  This causes the collector to grow the heap to much to compensate for the root scanning time.  (You can tune the collector to compensate, but then it runs slowly.)

2) Under win32, it tends to scan system malloced memory as roots.  This is a misfeature, since it can't be relied on.  My current version attempts to fix it, but the fix is heuristic, since I don't know of a way to identify malloced memory sections.  (The fix works well on a small toy example :-) .)  This affects only Windows.

Hans

> -----Original Message-----
> From: Lars Andersen [mailto:lars@rimfaxe.com]
> Sent: Wednesday, April 02, 2003 7:07 AM
> To: Erik Poupaert
> Cc: java@gcc.gnu.org
> Subject: RE: maximum memory for gcj-compiled executable?
> 
> 
> 
> Lots of people, myself included, thinks that some sort of compiler
> option that sets minimum and maximum heap size is desirable.
> 
> Many apps uses a lot of memory in short bursts, and then discards it.
> The default behaviour of the GC is to weigh in performance over size.
> This is great news performancewise, since you don't want the 
> GC to slow
> down your app when there is lots of memory available. 
> 
> Some apps have a different nature, however. They need to coexist with
> other apps, and share resources. Here it is important to 
> control memory
> usage. I have seen this many times now. The gcj app grows and 
> grows, but
> when i debug the heap usage it may be 90%+ unused. 
> I've seen gcj compiled programs that ran just fine with <10MB 
> heap, grow
> to more than 100MB. For some apps space is the most important 
> resource,
> not performance.
> 
> Suggested solution :
> 
> add options to control heap, in particular initial and max sizes.
> 
> gcc/java/jvgenmain.c line 141 reads :
> 
> >>>>>>>>>>>>>>>>>>>>
> 
> fprintf (stream, "int main (int argc, const char **argv)\n");
> fprintf (stream, "{\n");
> fprintf (stream, "   _Jv_Compiler_Properties = props;\n");
> fprintf (stream, "   JvRunMain (&%s, argc, 
> argv);\n",mangled_classname);
> fprintf (stream, "}\n");
> 
> <<<<<<<<<<<<<<<<<<<<
> 
> Erik Poupart wrote earlier : 
> > libjava/prims.cc/_Jv_SetMaximumHeapSize() and 
> _Jv_SetInitialHeapSize()
> > would
> > be interesting, but they have to be called before calling
> >_Jv_RunMain(). Are
> > they connected in one way or another to gcj compilation options?
> 
> How about adding those options to jvgenmain, and add
> _Jv_SetInitialHeapSize() and _Jv_SetMaximumHeapSize() to jvgenmain.c
> before JvRunMain()
> 
> Please correct me, if I'm way off here.
> 
> /Lars
>