Tim, a little update here. I have managed to split problematic method into two chunks, I will attach new patch to JIRA in few minutes. So far the picture is following:
Windows x86_64: 100% Harmony-clean 97.7% Harmony-clean + H5374 (old) 99.6% Harmony-clean + H5374 (new) Windows x86: 100% Harmony-clean 97.9% Harmony-clean + H5374 (old) 99.6% Harmony-clean + H5374 (new) I will spend more time considering what can be done to beat current implementation, gathering new profile and making accurate measurements. But since there is a little degradation remain, I would propose to wait some more time for clearer picture. What do you think? Thanks, Aleksey. On Jan 8, 2008 7:58 PM, Tim Ellison <[EMAIL PROTECTED]> wrote: > Aleksey Shipilev wrote: > > 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. > > Ok, that wasn't clear to me, so thanks for explaining. > > > 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. I have uploaded the current patch to HARMONY-5374. > It would be good to figure out how we can make a single version work > well for both VMs. > > Regards, > Tim >
