Most programs either got faster or stayed unchanged. _201_compress is the only program that got significantly slower when the profiling scheme was changed. See http://jikesrvm.anu.edu.au/cattrack/results/rvmx86lnx32.anu.edu.au/perf.1400/performance_report
Investigate to see if we can avoid this hit while still maintaining the gains in the other benchmarks.
Is it because of profiling overhead or a change in inlining decisions? If a change in inlining decisions, is it because we're not inlining something we should, or have we started to get an inlining we missed before and as a result the opt compiler is generating worse code for one of the two main loops in compress?