harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Aleksey Shipilev" <aleksey.shipi...@gmail.com>
Subject Re: [classlib] HashMap optimization (again)
Date Thu, 10 Jan 2008 15:35:54 GMT

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?


On Jan 8, 2008 7:58 PM, Tim Ellison <t.p.ellison@gmail.com> 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

View raw message