On Thu, Apr 10, 2008 at 11:10 PM, Matthew Toseland
<toad at amphibian.dyndns.org> wrote:
>
> On Thursday 10 April 2008 01:15, Daniel Cheng wrote:
> > On Thu, Apr 10, 2008 at 6:26 AM, Matthew Toseland
> > <toad at amphibian.dyndns.org> wrote:
> > > On Wednesday 09 April 2008 17:01, you wrote:
> > > > Author: j16sdiz
> > > > Date: 2008-04-09 16:01:28 +0000 (Wed, 09 Apr 2008)
> > > > New Revision: 19114
> > > >
> > > > Modified:
> > > > trunk/freenet/src/freenet/support/DoublyLinkedList.java
> > > > trunk/freenet/src/freenet/support/DoublyLinkedListImpl.java
> > > >
> > >
>
> trunk/freenet/src/freenet/support/math/BootstrappingDecayingRunningAverage.java
> > > > Log:
> > > > javadoc and style fix
> > > >
> > > >
> > > > Modified: trunk/freenet/src/freenet/support/DoublyLinkedList.java
> > > > ===================================================================
> > > > --- trunk/freenet/src/freenet/support/DoublyLinkedList.java
> 2008-04-09
> > > 16:01:05 UTC (rev 19113)
> > > > +++ trunk/freenet/src/freenet/support/DoublyLinkedList.java
> 2008-04-09
> > > 16:01:28 UTC (rev 19114)
> > > > @@ -7,30 +7,54 @@
> > > > * @author tavin
> > > > */
> > > > public interface DoublyLinkedList {
> > > > + public abstract Object clone();
> > > >
> > > > - public abstract Object clone();
> > > > -
> > > > + /**
> > > > + * List element
> > > > + */
> > > > public interface Item {
> > > > + /**
> > > > + * Get next {@link Item}. May or may not return
> > > > + * <code>null</code> if this is the last
> <code>Item</code>.
> > >
> > > IIRC we have a bumper stopper item, don't we? Hmm, but we do check for
> null...
> > >
> >
> > No, we have two different method / behavior when that is the last item.
> > 1. DoublyLinkedList.getNext(Item)
> > --> always return null
> >
> > 2. DoublyLinkedList.Item.getNext() .
> > --> return null /or/ DoublyLinkedListImpl._tailptr
> >
> > The second one involve some implementation details, hence the "may or may
> not"
> > phase. I did wondered why we need two different method.
> >
> > Eventually, I want to migrate all DoublyLinkedList usage to
> > java.util.LinkedList / ArrayList / SortedSet. They are better tested
> > and optimized by jre vendors. But this migration would take some time.
>
> Yes and no.
>
> We should only use DoublyLinkedList where we need it. But there are places
> where we do need it. Specifically, anywhere where an element needs to be able
> to remove itself - LRUHashtable for example, and IIRC there are other classes
> in support/ that need it. Using DoublyLinkedList gives us a significant
> performance gain here.
Except if we can use java.util.concurrent.ConcurrentHashMap, which is
a thread-safe,
yet lock-free alternative.
I am not saying I would try to remove DoublyLinkedList now, I said
"eventually",
which could be years later.
Regards,
Daniel Cheng
