This is the mail archive of the
java@gcc.gnu.org
mailing list for the Java project.
Re: Performance comparison (update)
- From: Jeff Sturm <jsturm at one-point dot com>
- To: Norman Hendrich <hendrich at informatik dot uni-hamburg dot de>
- Cc: java at gcc dot gnu dot org
- Date: Tue, 30 Jul 2002 07:34:24 -0400 (EDT)
- Subject: Re: Performance comparison (update)
On Tue, 30 Jul 2002, Norman Hendrich wrote:
> For the numbers reported below, there should be very little object
> allocation while the simulation is running. Naturally, I could have
> missed (again) something that happens im my code. Is there some
> magic GC flag or hook to print messages, whenever objects are created?
export GC_PRINT_STATS=1
will give you an idea of frequency & duration of collections, roughly the
same as -verbose:gc.
> Note: For older 1.1.x generation JDKs and "real" workloads for our
> simulator, garbage collection would often use 80+ percent of CPU...
> JDK 1.3 behaves *much* better in this regard.
That sounds like the "classic" VM. It had a compacting collector.
Back when were we using it I often found the majority of collection time
was spent compacting, vs. mark and sweep.
> GCJ -O3 -fno-bounds-check -fno-store-check ev/sec= 948711
> GCJ -O2 -fno-bounds-check -fno-store-check ev/sec= 981954
> GCJ -static -O2 -fno-bounds-check -fno-store-check ev/sec= 988823
> GCJ -static -O3 -fno-bounds-check -fno-store-check ev/sec= 1072332
Looks like there may be a little fluctuation in your runtimes. There's
no good reason -static would help at -O3 but not -O2.
Static builds are generally a little faster due to the absence of PIC and
a smaller root set. I've seen as much as %30 depending on workload.
Jeff