harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tim Ellison <t.p.elli...@gmail.com>
Subject Re: [classlib] HashMap optimization (again)
Date Tue, 08 Jan 2008 16:58:17 GMT
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.


View raw message