Mailing-List: contact dev-help@harmony.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@harmony.apache.org
Received-SPF: pass (athena.apache.org: domain of t.p.ellison@gmail.com
 designates 209.85.128.185 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=message-id:date:from:user-agent:mime-version:to:subject:references:in-reply-to:x-enigmail-version:content-type:content-transfer-encoding;
        b=sAhdLklkpxR+j95f4Srv2dwxn3AF6VnNjBor5SjsEkFevA4QCysV2C/jshJTfQn6tLb3zEO++qA1TUIP+fFTtkobKjBUGauMMGOtCScsFjxM1YB5Wt+/Ex7w8s04sxhiH1FgAmRqPwRr2yUHu3rtCeckdZEavQIGEuiq7poNAgE=
Message-ID: <4783ABA9.8010203@gmail.com>
Date: Tue, 08 Jan 2008 16:58:17 +0000
From: Tim Ellison <t.p.ellison@gmail.com>
User-Agent: Thunderbird 2.0.0.9 (Windows/20071031)
MIME-Version: 1.0
To: dev@harmony.apache.org
Subject: Re: [classlib] HashMap optimization (again)
References: <47838CD7.2000509@gmail.com>
 <4bebff790801080807s2b634409n62632159071ddc69@mail.gmail.com>
In-Reply-To: <4bebff790801080807s2b634409n62632159071ddc69@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

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