This is the mail archive of the
java@gcc.gnu.org
mailing list for the Java project.
Re: copile java 1.5 code
- From: Tom Tromey <tromey at redhat dot com>
- To: "Boehm, Hans" <hans dot boehm at hp dot com>
- Cc: "Jens Fransson" <fransson at fransson dot de>, <java at gcc dot gnu dot org>
- Date: 27 Jan 2005 09:49:03 -0700
- Subject: Re: copile java 1.5 code
- References: <65953E8166311641A685BDF71D865826058C5D@cacexc12.americas.cpqcorp.net>
- Reply-to: tromey at redhat dot com
>>>>> "Hans" == Boehm, Hans <hans.boehm@hp.com> writes:
Hans> _Jv_MonitorEnter and _Jv_MonitorExit are high, with 3.27 seconds
Hans> each. It looks like hash synchronization is enabled here? We know we
Hans> don't do this as well as we should. The compiler could probably help
Hans> by passing the hash table address from one to the other, and by
Hans> avoiding checks in MonitorExit when it knows we hold the
Hans> lock.
Interesting ideas. For the latter I think this could only be done
when there are no intervening calls as there is no guarantee that a
call preserve the count on a lock.
Hans> But I would guess that switching to StringBuilder might
Hans> have more of an impact, in just eliminating all those silly calls,
Hans> especially since this is a P4, where the cmpxchg instructions are
Hans> likely to dominate everything else.
Due to its goofy (wrong :-) semantics, StringBuilder implies a copy
of its result in all cases. If you compile source->object, gcj will
instead use our unsynchronized version of StringBuffer that doesn't
need a copy of the string data. The only way I know of to replicate
this with the class->object compiler would be to implement some form
(perhaps ad hoc) of escape analysis.
Tom