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 sergey.i.salishev@gmail.com
 designates 72.14.246.246 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references;
        b=M3l3OHSg5tb9dXry8+snzg4VBhwGriisyxuR0zyjFfgLTEaeNJQN8OQpRSxIRVQ1Fj23hAjCPl5wjfeuq1CKcDWh6oBuzfpDGxZItSchIdCXGGxhfidOKGz6TW07+Rrpy1LPJ3iKftCD3M9qUYfWc0wgt9gRORg1MyoLByX4Q9Y=
Message-ID: <728dc7fa0804181226q4bc1d5d7g6df20929da024edc@mail.gmail.com>
Date: Fri, 18 Apr 2008 23:26:20 +0400
From: "Sergey Salishev" <sergey.i.salishev@gmail.com>
To: dev@harmony.apache.org
Subject: Re: [classlib][luni][performance] Improvements in Collections
In-Reply-To: <4bebff790804181221w9ce6ad8u97ceaa8b590c877a@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_Part_3232_25839775.1208546780478"
References: <4bebff790804172350r15419dd4v95e9c7a7adb8f14d@mail.gmail.com>
	 <728dc7fa0804180946y4a2ba333m9e7bba043b2942e@mail.gmail.com>
	 <3b3f27c60804180955q1d2e7d89y8c00173618a46241@mail.gmail.com>
	 <728dc7fa0804181057s3e82721cva72a3cf1f2150918@mail.gmail.com>
	 <3b3f27c60804181141w77182695j9c777dd1a6173311@mail.gmail.com>
	 <728dc7fa0804181153p2f90f3edncb29d0c3a7d348dc@mail.gmail.com>
	 <3b3f27c60804181206l65d6454ew37620598736d23e0@mail.gmail.com>
	 <4bebff790804181210s245bcc7aj8891ee10163e4900@mail.gmail.com>
	 <3b3f27c60804181214p12a569c7t27f04615e76d6a1e@mail.gmail.com>
	 <4bebff790804181221w9ce6ad8u97ceaa8b590c877a@mail.gmail.com>

------=_Part_3232_25839775.1208546780478
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

Nathan,

Do you have any problems with applying the
https://issues.apache.org/jira/browse/HARMONY-4064 patch to the WeakHashMap?

Thanks,
Sergey.


On Fri, Apr 18, 2008 at 11:21 PM, Aleksey Shipilev <
aleksey.shipilev@gmail.com> wrote:

> Ok, let's start over. Current implementation of *HM does not guarantee
> the storage size is 2^k. On the other hand such the requirement is the
> _prerequisite_ for performance optimization done in the patch. Thus
> the rounding code is the essential part of the patch and can't be
> removed. Removal of this code will lead to performance degradations.
> We can inline this method into computeCapacity for convenience reasons
> (I'm sorry now I hadn't done that already).
>
> Is there any problem with my arguments?
>
> Thanks,
> Aleksey.
>
> On Fri, Apr 18, 2008 at 11:14 PM, Nathan Beyer <ndbeyer@apache.org> wrote:
> >  I think the capacity calculation should be removed from the patch. It's
> NOT
> >  the performance boost, correct?
>

------=_Part_3232_25839775.1208546780478--