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. Mark --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
