RE: VolanoMark findings

[Andrew Haley <aph at redhat dot com>]

Boehm, Hans writes:
 > That's very roughly consistent with my (slightly dated) SPECjbb experiments.  An Itanium profile suggested the top culprits there were:
 > 
 > 1. _Jv_MonitorEnter (about 7%)
 > 2. GC_mark_from (probably unavoidable and no worse than on other JVMs with the same heap size)
 > 3. The B-tree access routine in the benchmark
 > 4. _Jv_MonitorExit (about 5%)
 > 5. _Jv_CheckCast

 > out of line division (> 5% total, in various routines)

That's evil.  Fixing this for IA-64 would not be very hard, but I
always assumed it was not very important.

 > memory allocation (not GC)
 > a few poorly tuned java.lang.String routines

Yes.  I noticed that we performed badly on the CaffieneMark string benchmark.

 > __gettimeofday (about 2% !?)
 > 
 > The most likely sources of possible generally applicable improvement seemed to be:
 > 
 > 1. (Selective or partial?) inlining of MonitorEnter/Exit.

Not too hard, I wouldn't have thoght.

 > Being able to remember some state between the two would help
 > appreciably.  (But there's a limit, since the compare-and-swap
 > instructions themselves use up a significant fraction of the time
 > on most platforms.  It would be great to avoid that in the
 > MonitorExit case, but I think it's quite hard, given our other
 > constraints.)
 > 
 > 2. (Selective?) inlining of division.

We do that, but only on x86.  It requires some faily hairy recovery
code for when things go wrong.

 > 3. Improvements to some of the String routines.  (I may still have
 > a partial patch or two hanging around, though it may be obsolete. I
 > got sidetracked ...)
 > 
 > 4. Further shortening of the allocation path.
 > 
 > 5. (Almost certainly the most important, though the hardest) Gcc
 > optimizer improvements.

In particular, cross-file inlining and some loop optimizations.

Andrew.