Ok, I had updated both JIRAs [1, 2]. I think we can commit WeakHashMap
ariphmetics [1], but postpone improvements in IdentityHashMap
ariphmetics [2].
We can start moving IdentityHashMap to HashMap [3] if nobody objects.
Thanks,
Aleksey.
[1] https://issues.apache.org/jira/browse/HARMONY-5761
[2] https://issues.apache.org/jira/browse/HARMONY-5718
[3] https://issues.apache.org/jira/browse/HARMONY-5771
On Mon, Apr 21, 2008 at 4:47 PM, Aleksey Shipilev
<aleksey.shipilev@gmail.com> wrote:
> Hi Tim,
>
> Yeah, I think it makes sense to get IdentityHashMap and WeakHashMap to
> be internally consistent with HashMap implementation. It would be
> better to just inline roundTo2K() method to computeCapacity() and
> that's all.
>
> I will update JIRAs a little later, if Jimmy didn't help out there already.
>
> Thanks,
> Aleksey.
>
>
>
>
> On Mon, Apr 21, 2008 at 4:38 PM, Tim Ellison <t.p.ellison@gmail.com> wrote:
> > Just catching up with this thread...
> >
> > So it seems everyone agrees that making the number of buckets a power of
> > two, and calculating that number using the same mechanism as already applied
> > to HashMap is the way to go?
> >
> > Regards,
> > Tim
> >
> >
> >
> > Nathan Beyer wrote:
> >
> > > That patch wasn't applied 'as-is', so I wouldn't agree to that. However, I
> > > would agree to making WeakHashMap and IdendityHashMap consistent, if not
> > > just use the same code, with HashMap.
> > >
> > > -Nathan
> > >
> > > On Fri, Apr 18, 2008 at 2:26 PM, Sergey Salishev <
> > > sergey.i.salishev@gmail.com> wrote:
> > >
> > >
> > > > 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<https://mail.google.com/mail?view=cm&tf=0&to=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<https://mail.google.com/mail?view=cm&tf=0&to=ndbeyer@apache.org>>
> > > > >
> > > > wrote:
> > > >
> > > > >
> > > > > > I think the capacity calculation should be removed from the
patch.
> > > > > >
> > > > >
> > > > It's
> > > >
> > > > > NOT
> > > > >
> > > > > > the performance boost, correct?
> > > > > >
> > > > >
> > > >
> > >
> > >
> >
>
|