VolanoMark findings

Wed Jan 29 17:54:00 GMT 2003

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.