commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Thomas <>
Subject Re: [POOL2] Java 1.5 or 1.6?
Date Fri, 06 May 2011 15:35:27 GMT
On 06/05/2011 16:24, Phil Steitz wrote:
> On 5/6/11 3:43 AM, Mark Thomas wrote:
>> Before I go too far down the road of the re-writing the core object
>> allocation code for pool2, I'd like to get some clarity on what the
>> minimum Java version targeted by pool2 should be.
> It is also logical to ask at this point if the rewrite is desirable
> / necessary and what we expect to gain from it.  I have pretty
> consistently advocated this, but given the work and inevitable
> stabilization required, we should at least ask the question.  Seems
> to me the goals should be 0) performance 1) maintainability 2)
> robustness 3) (configurable?) fairness.  Do you agree with these and
> are you sure the rewrite is necessary to get them?

Yes I agree. To address 0), we need to remove most/all of the
synchronisation around object allocation. That means a re-write, almost
certainly with java.u.c. I still have concerns around 1) & 2). The more
I think about this problem, the more I realise I need to spend more time
thinking about the problem. At the moment, I would rather take the time
and get this right.

>> It is currently 1.5.
>> It would make the implementation of the FIFO/LIFO allocation option
>> considerably easier if that was changed to 1.6.
> Can you explain a little what the problem is?

Sure. In pool1 we have the ability (via CursorableLinkedList) to remove
and insert idle objects at any point in the queue. We use this for the
evictor and idle validation. It we switch to java.u.c (and I think it is
almost certain we will have to to get the performance we want) there are
far fewer options over object insertion/creation.

In Java 1.5, LinkedBlockingQueue only supports FIFO. It is not possible
to remove from the tail of the queue or insert at the head. That makes
LIFO pretty much impossible to implement.

In Java 1.6, LinkedBlockingDeque allows inserts and removals at either
end of the queue. That solves the LIFO/FIFO issue but not the eviction /
idle validation questions. I have some ideas about this but I am trying
to avoid creating lots of complexity. I am also mulling over how to
ensure that maxActive and friends are adhered to.


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message