harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alexey Petrenko" <alexey.a.petre...@gmail.com>
Subject Re: [classlib][luni] TreeMap woes
Date Sat, 08 Dec 2007 18:04:57 GMT
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