• Type: Bug
• Component: other-libs
• Sub-Component: other
• Affected Version: 1.4.0

• Priority: P3
• Status: Resolved
• Resolution: Fixed
• OS: generic
• CPU: generic,sparc

• Submitted: 2001-03-22
• Updated: 2002-08-01
• Resolved: 2002-07-23

Other
1.4.1 rcFixed

CONVERTED DATA BugTraq+ Release Management Values COMMIT TO FIX: hopper-rc FIXED IN: hopper-rc INTEGRATED IN: hopper-rc tiger-b08 14-06-2004 EVALUATION I am working on a pair of tools that 1) instrument a .so and 2) use the data from one or more instrumentation runs to produce an ordering for the .so. The instrumentation tool gathers first use and frequency of use for functions as well as function pair frequencies. Both entry and return transitions are noted, and a small ring buffer is used to capture recently visited functions. Example: suppose A and B are called from outside the .so. If all the calls to A precede all of the calls to B, they could occupy the same icache lines with little cost. If calls to A and B alternate, the A-B pair frequency is high and it is worthwhile to put A and B in different icache lines. The arrangement tool can accept data sets from a series of instrumentation runs. It arranges functions mentioned in the first data set first, followed by newly mentioned functions from each of the remaining data sets. Optionally, the functions that are common to two adjacent data sets (the intersection) can be arranged after those that are unique to the first data set and before those unique to the second. Each set of functions can be arranged with a choice of four algorithms. 1) Arrange in order of first use. 2) Arrange by frequency of use 3) Use the Pettis and Hanson algorithm which builds a graph of functions with edge frequencies and collapses node pairs by decreasing edge weight. 4) (not yet implemented) Use an algorithm by Kalamatianos, et. al., which is based on a graph like the Pettis and Hansen algorithm, but uses the cache properties to color the graph, a take-off on the Chaitin register allocation algorithm. Development of these tools is nearing completion. A series of instrumentation runs will then be made with a variety of benchmark and other programs. Lastly, a cherry-picking process will determine which arrangement algorithm(s) best reduce icache misses. It is expected that once we detemine the best options, they will be used for all subsequent arrangement runs. The effect on icache misses can be monitored with cpustat. A script to instrument and arrange can be run at whatever interval is deemed appropriate. It will not be part of the build process, per se. mathew.myszewski@East 2001-04-04 Additional fine tuning of orders has not been found to be profitable; the benefit, at least to server workloads, is neutral to negative. At this point linker directives that refer to methods that have disappeared should be removed, but additional work on ordering is not expected to buy much. ###@###.### 2001-11-17 The orderings on sparc 32b were recreated for Hopper RC. They will be put back to Mantis as well. Performance studies showed very little performance difference, so no attempt was made to recreate the orders for other platforms. This will be done for Mantis if time permits. I'm marking this as "integrated", although it was put back to hopper-b18 under the related tuning bug 4674776. Note that there are both JDK and JVM workspace changes for reordering. ###@###.### 2002-07-23 23-07-2002