[concurrency-interest] PooledLinkedBlockingQueue

Adam Messinger adam@bea.com
Fri, 5 Nov 2004 17:51:59 -0800


> -----Original Message-----
> From: concurrency-interest-admin@cs.oswego.edu 
> [mailto:concurrency-interest-admin@cs.oswego.edu] On Behalf 
> Of Jean Morissette
> Sent: Wednesday, November 03, 2004 5:25 PM
> To: Jeff Schultz
> Cc: concurrency-interest@altair.cs.oswego.edu
> Subject: Re: [concurrency-interest] PooledLinkedBlockingQueue
> Jeff Schultz wrote:
> > Try it with a
> > smaller number of nodes in use, or change the GC parameters to 
> > increase the size of the nursery and I'd expect you to see 
> different 
> > performance.
> I have changed the test in the 'warn up loop' to remove a 
> node after adding it to the list, so there is no more than 
> one node all the time. 
> Now, the performance difference is much lesser, but 
> PooledLinkedList is a little more fast.
>        LinkedList:  12000 ms
> PooledLinkedList:   9500 ms

I believe that pooling can be made to perform well in the context of
some single-threaded data structures, like your new example.  The
original question was in the context of a data-structure which has
multi-threaded access.  In this case the pooling logic will be much more
expensive (to handle concurrency either via thread local pools or via a
shared concurrent pool) and I doubt you will ever make up this gap.

In my experiments I've noticed a big difference depending upon the JVM
being used.  With JRockit I see no measurable difference between the two
implementations.  With HotSpot server I see that the pooled
implementation is significantly faster.  With HotSpot client I see that
the pooled implementation is only very slightly faster.