This is the mail archive of the
mailing list for the Java project.
RE: GC latency in GCJ
- From: "Boehm, Hans" <hans dot boehm at hp dot com>
- To: "Andrew Haley" <aph at redhat dot com>, "P.O. Gaillard" <pierre-olivier dot gaillard at fr dot thalesgroup dot com>
- Cc: <java at gcc dot gnu dot org>
- Date: Mon, 24 Apr 2006 13:40:11 -0700
- Subject: RE: GC latency in GCJ
> -----Original Message-----
> From: Andrew Haley
> P.O. Gaillard writes:
> > I am testing the latency of programs compiled with GCJ and
> the GC > stops everything when it runs (I run Fedora Core 5,
> GCJ 4.1 and > Linux Trace Toolkit showed me that all the
> tasks are suspended > during GC as described by Hans Boehm
> in a message on this list).
> > I would like to test my little test program without GC but
> could > not find any runtime option to stop the garbage
> collector. Do I > really need to recompile GCC or can I
> change some runtime parameter > ?
> I don't think so. Hans will have to answer that one. You
> might get better results on one of the gc lists.
Various environment variables that control the GC are described in
doc/README.environment in the GC directory. I think that setting
GC_DONT_GC should do the trick. But you might not like the results.
> > Also, I was surprised to see that my test program
> allocates memory > all the time (the size shown by ps
> increases until the gc starts) > when compiled with gcj.
> This does not seem to happen with JDK > 1.5.
> I don't understand what you're saying here. Until the gc
> starts, memory use increases continuously? What would you expect?
> > So I tried to use valgrind, gdb, oprofile to find where
> _Jv_Malloc > is called but I ran into problems (like the
> fact that libgc seems > to be lacking debugging symbols on
> my machine).
> Well, you have the source. However, _Jv_Malloc is not what
> you're looking for: most of the memory is allocated from
> GC_local_gcj_malloc or GC_gcj_malloc.
I think that actually depends on the application. We've seen some were
GC_malloc_atomic ended up dominating. GC_malloc is also usually called
for reference arrays. Try GC_DUMP_REGULARLY to see what's in the heap.
GC_PRINT_STATS is often useful to get a better idea of what the GC is
> > 2) is there a way to force the GC to work in 500us/1ms increments ?
> I don't think so. You might get better results on one of the
> gc lists.
No. It doesn't claim to be a real-time GC. (Note that 1 ms is normally
much less than the page fault time, or the timeout granularity on many
Linux systems. Thus this would be less latency than you normally get on
a Linux system without the GC.)
Depending on your environment, the GC supports two different facilities
that might help you reduce latency:
1) Parallel marking. If you are dealing with a machine with multiple
processors, you probably want to turn that on. I believe that,
depending on your platform, that should just work with
--enable-parallel-mark. For large heaps and small numbers of processors
(4, maybe more) with sufficient memory bandwidth, this should reduce
latency almost in proportion to processor count. This should probably
become the gcj default on some common platforms within the next year or
2) Incremental GC. With luck, this should get you down to the 20-50msec
range. (You can specify a target, but specifying 1ms isn't likely to
work well.) But I'm not sure what it's current status is with gcj. It
was tried unsuccessfully a while ago. But I think some issues have been
fixed since then.
Andrew's efforts to reduce gcj root sizes should reduce GC latency
appreciably by just speeding up the GC. Depending on your platform,
there may be other ways to do that. But it probably won't get you a
factor of 1.5, so if you need much more than that ...
> > 3) what is the easiest way to find out where memory is
> allocated > with GCJ ? I would like to obtain something like
> what gnatmem, > valgrind, jdk (-Xrunhprof:heap=sites) do.
> That is obtain backtraces > of the call stack for all the
> allocation sites in a program.
> Every time a piece of memory is allocated, you want the stack trace?
> That should be easy enough to add to _Jv_AllocObj and
> _Jv_AllocPtrFreeObj, simply by doing a backtrace() and
> printing the results to a file somewhere.
It used to be that if you built libgcj with --enable-gc-debug, the
collector would write an abbreviated stack trace in each object, and you
could use that for some low-tech heap profiling, etc. I believe that
still works at the GC level, but I'm not sure the gcj infrastructure
still works. I haven't tried it very recently.