This is the mail archive of the
mailing list for the Java project.
Re: gcj/SWT gc() and memory
The environment variables are somewhat documented in
boehm-gc/doc/README.environment. I'm not sure if that gets installed.
The most complete GC API documentation is the gc.h header file.
GC_set_max_heap_size should be documented elsewhere but I don't think it
is. It was intended to be rarely used. The fact that you need to use
it suggests a problem elsewhere.
I'm still guessing that something like the graphics memory is being
treated as roots. Your workaround will limit the heap, but in doing
so, you are circumventing the collectors heap expansion strategy, which is
designed to bound the amount of time it spends in the collector.
Thus you may see an unreasonable fraction of the execution time in the
If you notice such a problem, it's still worth tracking this down.
If you can alwasy identify the extra memory being traced, you can
use GC_exclude_static_roots() to eliminate the problem. But the
locatin of graphics memory tends to be a bit elusive. Otherwise the
collector would already do this automatically.
On Sun, 20 Jun 2004, Heitzso wrote:
> I'm using Mohan Embar's recent (6/7) toolkit for compiling
> SWT apps on Windows and have not attempted the equiv.
> on Linux (my primary dev box).
> I had not been aware of GC_MAXIMUM_HEAP_SIZE
> and GC_set_max_heap_size(). Using GC_MAXIMUM_HEAP_SIZE
> I am able to restrain the gcj version to the same memory
> usage as the JRE version. _Thank you!_
> I googled on GC_set_max_heap_size() and I didn't find
> usage documentation for calling that function from within
> a Java program. I found lots of .h files with the function
> signature on the internet but no usage documentation.
> Is there a 'howto' doc that covers setting memory constraints
> similar to -Xms, -Xmx, and other gcj gc settings in the context
> of gcj?
> Thank you again.
> Boehm, Hans wrote:
> >You are observing the large heap size under Windows? Or also
> >under Linux?
> >If it's under Windows, you might be running into a known issue
> >with the collector scanning graphics memory for roots. You
> >can get more information about what's going on by either calling
> >GC_dump() explicitly, or by running the executable with
> >the GC_DUMP_REGULARLY environment variable defined. Especially the
> >latter will produce huge volumes of output. You are really interested
> >in its description of the root set after the heap has grown.
> >>-----Original Message-----
> >>From: firstname.lastname@example.org
> >>[mailto:email@example.com]On Behalf Of
> >>Sent: Saturday, June 19, 2004 10:02 AM
> >>To: firstname.lastname@example.org
> >>Subject: gcj/SWT gc() and memory
> >>I have a SWT 3.0RC app that generates hundreds of
> >>thousands of small short life objects, plus some larger
> >>objects. Run under Linux (IBM JRE) or Win (Sun JRE)
> >>it stabilizes out around 32M. The same code compiled
> >>to native with gcj stabilizes around 100+M. I need
> >>to be able to run on old Win98 128M machines so 100+M
> >>is too large.
> >>Is there a better garbage collector I should be
> >>turning on or using?