Rustem Rafikov wrote: > DRLVM has "scalar replacement" JIT optimization implemented. It allows to > avoid calling Integer.equals method as well as excessive Integer objects > creation. This optimization gives us noticeable boost on SPECjbb2005 > benchmark. JIT optimization is more general and effective.
Hi Rustem, cool -- I can see that is a useful general optimization technique. > Unfortunately, HashMap optimization you suggested causes ~5% degradation on > SPECjbb2005 with DRLVM. Hmm, not so good :-( I'm interested to learn why it would cause such a large degradation. In effect, what I did was to improve the CPU cache hit rate, by avoiding the dereference of the Integer key object during the map look-up. IMHO the optimization doesn't increase the code path length excessively, so I might have expected you say that DRLVM scalar replacement means it doesn't benefit much from avoiding the Integer dereference cache miss, but why would it make the benchmark score so much worse? > I'd suggest to revert this commit for a while. Can do. I'm interested to learn a bit more. Regards, Tim
