harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Xiao-Feng Li" <xiaofeng...@gmail.com>
Subject Re: [jira] Commented: (HARMONY-3883) [classlib]WeakHashMap.keySet().toArray() intermittently throws NoSuchElementException in java.lang.ThreadTest of DRLVM kernel test
Date Thu, 24 May 2007 12:02:43 GMT
I've done thread already, strange my action and comments didn't come
to this list.

On 5/24/07, Mikhail Markov <mikhail.a.markov@gmail.com> wrote:
> Xiao-Feng,
>
> Could you please revert the last patch2 and re-open JIRA - i've found the
> real issue and want to post it there.
> (See my comment in JIRA).
>
> Thanks,
> Mikhail
>
>
> On 5/24/07, Xiao-Feng Li (JIRA) <jira@apache.org> wrote:
> >
> >
> >    [
> > https://issues.apache.org/jira/browse/HARMONY-3883?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12498449]
> >
> > Xiao-Feng Li commented on HARMONY-3883:
> > ---------------------------------------
> >
> > Mike, I will commit your patch2, and close this issue, while opening
> > another JIRA for the java.lang.ThreadGroup.java issue. The goal is to
> > solve this java.lang.ThreadTest failure finally.
> >
> > Thanks,
> > xiaofeng
> >
> >
> >
> > --
> > http://xiao-feng.blogspot.com
> >
> >
> > > [classlib]WeakHashMap.keySet().toArray() intermittently throws
> > NoSuchElementException in java.lang.ThreadTest of DRLVM kernel test
> > >
> > ----------------------------------------------------------------------------------------------------------------------------------
> > >
> > >                 Key: HARMONY-3883
> > >                 URL: https://issues.apache.org/jira/browse/HARMONY-3883
> > >             Project: Harmony
> > >          Issue Type: Bug
> > >          Components: Classlib
> > >         Environment: win/linux 32/64
> > >            Reporter: Li-Gang Wang
> > >         Attachments: H-3883.patch, H-3883_add_alt1.patch,
> > H-3883_add_alt2.patch, WeakHashmapTest.java
> > >
> > >
> > > I found there is a design bug in WeakHashMap.keySet().toArray() .
> > > WeakHashMap.keySet().toArray() inherits AbstractCollection.toArray().
> > Its implementation is as follows:
> > >       public Object[] toArray() {
> > >               int size = size(), index = 0;
> > >               Iterator<?> it = iterator();
> > >               Object[] array = new Object[size];
> > >               while (index < size) {
> > >             array[index++] = it.next();
> > >         }
> > >               return array;
> > >       }
> > > After assigning 'size()' to 'size', the 'while' loop expects 'size'
> > elements in the iterator 'it'. But actually GC might happen and clear some
> > weak keys of the WeakHashMap instance in the meantime. The iterator will
> > skip the cleared weak keys in 'it.hasNext()' called by 'it.next()', so the
> > actual number of the elements in 'it' is smaller than 'size'. When 'it' runs
> > out its elements, 'it.next()' will throw a NoSuchElementException. Parts
> > of HashIterator implementation in WeakHashMap is as follows:
> > >         public boolean hasNext() {
> > >             if (nextEntry != null) {
> > >                 return true;
> > >             }
> > >             while (true) {
> > >                 if (nextEntry == null) {
> > >                     while (position < elementData.length) {
> > >                         if ((nextEntry = elementData[position++]) !=
> > null) {
> > >                             break;
> > >                         }
> > >                     }
> > >                     if (nextEntry == null) {
> > >                         return false;
> > >                     }
> > >                 }
> > >                 // ensure key of next entry is not gc'ed
> > >                 nextKey = nextEntry.get();
> > >                 if (nextKey != null || nextEntry.isNull) {
> > >                     return true;
> > >                 }
> > >                 nextEntry = nextEntry.next;
> > >             }
> > >         }
> > >         public R next() {
> > >             if (expectedModCount == modCount) {
> > >                 if (hasNext()) {
> > >                     currentEntry = nextEntry;
> > >                     nextEntry = currentEntry.next;
> > >                     R result = type.get(currentEntry);
> > >                     // free the key
> > >                     nextKey = null;
> > >                     return result;
> > >                 }
> > >                 throw new NoSuchElementException();
> > >             }
> > >             throw new ConcurrentModificationException();
> > >         }
> > > I suspect the intermittent failure in java.lang.ThreadTest may disappear
> > if this bug is fixed.
> >
> > --
> > This message is automatically generated by JIRA.
> > -
> > You can reply to this email to add a comment to the issue online.
> >
> >
>


-- 
http://xiao-feng.blogspot.com

Mime
View raw message