harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Nathan Beyer" <nbe...@gmail.com>
Subject Re: [classlib][luni] TreeMap woes
Date Sat, 08 Dec 2007 18:51:05 GMT
It depends. Have we learned our lesson?

-Nathan

On Dec 8, 2007 12:04 PM, Alexey Petrenko <alexey.a.petrenko@gmail.com> wrote:
> So I think that we should keep the patch.
>
> Objections? Tim?
>
> SY, Alexey
>
> 2007/12/7, Sergey Kuksenko <sergey.kuksenko@gmail.com>:
>
> > Hi All,
> >
> > I really found a bug. But I wish to note, that it is a bug in Eclipse.
> > The story:
> > In order to caught that I've created a "mixed" TreeMap. The mixed tree map
> > aggregates two TreeMaps - old implementation and new implementation. Also
> > mixed TreeMap performs all operation on both maps and compared results.
> > Using that I've cought the place where differentce occures.
> > It was operation remove originally from TreeSet.
> > Let see.
> > Before we have two identical maps:
> >
> > Old -  { 43731146; 91780893; 92440425; }
> > New - { 43731146; 91780893; 92440425; }
> >
> > Numbers are identityHashCode values.
> > Element "91780893" comes to remove.
> > After remove we got two different maps:
> >
> > Old -  { 43731146; 92440425; }
> > New - { 43731146; 91780893; 92440425; }
> >
> >  If we have (before remove) elements in this order(for both threes) - it
> > means that elements has the following order  43731146 < 91780893 < 92440425
> > BUT! I found that Eclipse's comparator used here changed the behaviour.
> > According to my logs,  sign(cmp(43731146,91780893)) == 1 that means that
> > 43731146 > 91780893
> >
> > If we compare "key to remove" with all element we got the follwoing signs:
> > -1,0,-1. This is a error.
> > Why RI doesn't fail at this case. It's happiness. Because of on RI 91780893
> > (key to remove) is on root and we compare key with the root first, got
> > equality and all ok. Occaisionally.
> > On my implementation we do the comparison 91780893 with 43731146(first
> > element), got the fact that "key to remove" is less then smallest element in
> > Tree and we have nothing to remove.
> >
> > So I think we shouldn't rollback the pacth, but it makes sence to find a
> > error in Eclipse and fill a bug against them.
> >
> >
> > Note, as wrote before, I found one bug in TreeMap. But, the can't impact on
> > Eclipse unit tests, because of according my logs all trees in EUT smaller
> > then 100. But the bug can took a place with small probability for trees more
> > then 64*3 elemens and can't be for trees with size smaller then 3*64.
> >
> >
> > On 12/7/07, Tim Ellison <t.p.ellison@gmail.com> wrote:
> > >
> > > Sergey Kuksenko wrote:
> > > > I found a bug.
> > > > Let's wait until I am checking.
> > >
> > > Only if you promise it is the last bug ;-)  Why cram it in now and
> > > suffer these new bugs and crashes?
> > >
> > > I believe the skill in making a release is knowing what to leave out,
> > > not how much you can squeeze in at the last minute.
> > >
> > > Regards,
> > > Tim
> > >
> > > > On 12/7/07, Tim Ellison <t.p.ellison@gmail.com> wrote:
> > > >> This change to TreeMap seems to have introduced an instability, and
I
> > > >> would say it is a candidate for reverting in M4.
> > > >>
> > > >> WDYT?
> > > >>
> > > >> ---
> > > >> Sergey Kuksenko.
> > > >> Intel Enterprise Solutions Software Division.
> > > >
> > >
> >
> >
> >
> > --
> > Best regards,
> > ---
> > Sergey Kuksenko.
> > Intel Enterprise Solutions Software Division.
> >
>

Mime
View raw message