RE: copile java 1.5 code

["Boehm, Hans" <hans dot boehm at hp dot com>]

Thanks. 

Unfortunately, unless I'm missing something, the profile seems to be
missing > 2/3 of the count (26 seconds vs. 90).  Most importantly,
we seem to not be getting samples in the cygwin or system libraries,
a common problem with gprof.  Nonetheless, it gives us some hints.

I can't quite tell whether the GC itself is a major part of the problem.
GC_mark_from is at the top, but it's only 4.58 seconds.  4.58 seconds
out of 90 is probably fine.  Even out of 17 it might be tolerable.
(For heavy users of short-lived strings, Sun's JDK will usually win here,
due to the generational collector.  But a factor of 5 is way too much.)

_Jv_MonitorEnter and _Jv_MonitorExit are high, with 3.27 seconds
each.  It looks like hash synchronization is enabled here?  We know we
don't do this as well as we should.  The compiler could probably help
by passing the hash table address from one to the other, and by
avoiding checks in MonitorExit when it knows we hold the
lock.  But I would guess that switching to StringBuilder might
have more of an impact, in just eliminating all those silly calls,
especially since this is a P4, where the cmpxchg instructions are
likely to dominate everything else.

I suspect the actual allocation calls are also a big part of the problem.
They only show up as about 0.8 seconds.  But thread-local allocation
isn't enabled on this platform, so I think each one should make calls
to EnterCrticalSection and LeaveCriticalSection (pthread_mutex_lock
and pthread_mutex_unlock for cygwin).  We're not seeing those, but they
may account for a big chunk of the missing time.  If it is a problem, it
shouldn't be very hard to use the spin-sleep locks that are used on Linux.

This is a uniprocessor machine?  Is there more than one active thread
in the application? 

I should really add thread-local allocation for win32.

Hans


> -----Original Message-----
> From: Jens Fransson [mailto:fransson@fransson.de]
> Sent: Wednesday, January 26, 2005 2:53 PM
> To: Boehm, Hans
> Cc: java@gcc.gnu.org
> Subject: Re: copile java 1.5 code
> 
> 
> Hello Hans!
> 
> HB> On Wed, 26 Jan 2005, Jens Fransson wrote:
> 
> >> TOW> Is the performance better than gcj?
> >>
> >> Yes, definitely. The performance with my memory- and cpu-hungry app
> >> with Jet is exactly the same as with JRE 1.5. Native compiled GCJ
> >> code is about 2 to 5 times slower - looks like it has some serious
> >> memory allocation/garbage collection related performance problems.
> >>
> HB> What platform was this on?  Could you post a profile?
> 
> I have to admit that it is just a guess that the performance problems
> are related to memory management. After I noticed the bad performance
> of GCJ, I tried to optimize the application and found that removing an
> unnecessary creation of a new object boosted GCJ's performance by
> about 100% while Sun's JRE 1.5.0 did not show any noticable change.
> This is what made me think of a memory management issue.
> 
> Even after all optimizations GCJ (ca. 90 sec) is far behind Sun's JRE
> (ca. 14 sec) for a specific run of my program. Attached you find the
> output of gprof produced during that run.
> 
> The platform is Windows XP on a Pentium 4 (2.4 GHz). The GCJ version
> is a MinGW-Special gcc 3.4.2. The output of gcj -v is attached below.
> 
> With kind regards,
> Jens
> 
> _______________________________
> | Fransson Software
> | Softwareentwicklung
> | Jens Fransson
> | Dipl.-Inform. B.Sc.
> | Bornstraße 33 * 20146 Hamburg
> | E-Mail: fransson@fransson.de
> | Internet: www.fransson.de
> 
> 
> 
> C:\data\develop\java\projects\compare\build\gcj>gcj -v Reading specs
> from C:/program/mingw/bin/../lib/gcc/mingw32/3.4.2/specs Reading specs
> from
> C:/program/mingw/bin/../lib/gcc/mingw32/3.4.2/../../../libgcj.spec
> rename spec lib to liborig Configured with: ../gcc/configure
> --with-gcc --with-gnu-ld --with-gnu-as --host=mingw32 --target=mingw32
> --prefix=/mingw --enable-threads --disable-nls
> --enable-languages=c,c++,f77,ada,objc,java --disable-win32-registry
> --disable-shared --e nable-sjlj-exceptions --enable-libgcj
> --disable-java-awt --without-x --enable-java-gc=boehm
> --disable-libgcj-debug --ena ble-interpreter
> --enable-hash-synchronization --enable-libstdcxx-debug
> Thread model: win32 gcc version 3.4.2 (mingw-special)
>