Hi, Tim! Thanks for reminder :) Let me explain the situation for DRL VM performance. There two main points of degradation caused by your patch: 1. Break of scalar replacement on instanceof operation, solved by HARMONY-5014. 2. Changes in inline tree caused by increased method sizes in HashMap.
This (2) is main concern, the problem is method findNonNullKeyEntry, which double its size with your change. I had played with inliner heuristic in OPT, but can't find optimal configuration for it. By "optimal" I mean configuration that show at least same performance that original HashMap does. That mean even with HARMONY-5014 onboard we have a *degradation*. Today I realize that we can try to split this method in two chunks (specialized and not specialized) and thus not interfere much with inliner heuristics, if we can force inliner to leave cold chunk not inlined. I'm gonna try this approach this week. So, can we revisit this discussion after additional data is available? It also will be great to have your version in form of the JIRA with patch against current state of trunk. Thanks, Aleksey, ESSD, Intel. On Jan 8, 2008 5:46 PM, Tim Ellison <[EMAIL PROTECTED]> wrote: > A while ago I committed an optimization to HashMap [1] that showed good > improvements to SPEC benchmarks on the IBM VME, but it turned out caused > problems to the OPT JIT [2], so we rolled it back. > > The JIT has been improved so I'm going to go ahead an re-apply the > optimizations for Integer keys. It would be good to hear that people > see the same improvements now on DRLVM benchmarks too. > > [1] http://svn.apache.org/viewvc?rev=575658&view=rev > [2] http://issues.apache.org/jira/browse/HARMONY-5014 > > Regards, > Tim >
