commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Phil Steitz <phil.ste...@gmail.com>
Subject Re: [POOL2] Java 1.5 or 1.6?
Date Fri, 06 May 2011 17:52:28 GMT
On 5/6/11 10:31 AM, sebb wrote:
> On 6 May 2011 16:35, Mark Thomas <markt@apache.org> wrote:
>> 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.
> I can see why removal of arbitrary entries is needed, but why do we
> need insertion of elements other than at head or tail?

When the Evictor visits an idle instance for validation, it removes
it from the queue (so it does not get handed out to a client while
it is being examined) and then puts it back when validation has been
completed.
>> 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.

This may not be advisable given the potential for "entanglements,"
but a logical option might be to look into bringing in the Harmony
sources for the 1.6 class.  Could end up with an intractable mess of
dependencies, but it is a logical option.

Phil
>> Mark
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Mime
View raw message