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 Tue, 08 Jan 2008 16:07:07 GMT
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 <t.p.ellison@gmail.com> 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
>

Mime
View raw message