This is the mail archive of the java@gcc.gnu.org mailing list for the Java project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: copile java 1.5 code


>>>>> "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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]