From dev-return-126062-apmail-commons-dev-archive=commons.apache.org@commons.apache.org Fri May 6 15:55:13 2011 Return-Path: X-Original-To: apmail-commons-dev-archive@www.apache.org Delivered-To: apmail-commons-dev-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id EFBF9322D for ; Fri, 6 May 2011 15:55:13 +0000 (UTC) Received: (qmail 74530 invoked by uid 500); 6 May 2011 15:55:13 -0000 Delivered-To: apmail-commons-dev-archive@commons.apache.org Received: (qmail 74434 invoked by uid 500); 6 May 2011 15:55:13 -0000 Mailing-List: contact dev-help@commons.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: "Commons Developers List" Delivered-To: mailing list dev@commons.apache.org Received: (qmail 74426 invoked by uid 99); 6 May 2011 15:55:13 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 06 May 2011 15:55:13 +0000 X-ASF-Spam-Status: No, hits=-0.7 required=5.0 tests=FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,RFC_ABUSE_POST,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of paulus.benedictus@gmail.com designates 209.85.220.171 as permitted sender) Received: from [209.85.220.171] (HELO mail-vx0-f171.google.com) (209.85.220.171) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 06 May 2011 15:55:07 +0000 Received: by vxc40 with SMTP id 40so4361632vxc.30 for ; Fri, 06 May 2011 08:54:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type :content-transfer-encoding; bh=nZ4EK9h6GMFDU5o598yxQYCfo4TvZTnwKsWrOrStX3g=; b=aJx+X9vlFo74T+1JxgM6G7T99iOJ6T7BE+sGjnEKEkDSxKF5R+SFtR1bCOO2baq5dN mtjCJlwjJR3ldqDfw4sirNcboCmmsfAJXWF8d70L9HG0StDEFHI1LJcxviWvx82TXHmN PRBIlSg12lh23c8iQnxQtqnaz+OEA/ibqaSlY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type :content-transfer-encoding; b=lYRjmHLcbACigN2jkBgrDawdL00A+jWWLvx6ASKNR+8bVXz98nKyWJGn6BfBzR2G0P lOM74rlaUH9RTV00pK/VPBtnFZ6xAR4ihTAhz0xqODgoJrPnH64ZERjAAIvWjJ9i4RPd 0fce1iOKZZmXH+kKgOfRCaDjio9+muYXOnMoA= MIME-Version: 1.0 Received: by 10.52.175.68 with SMTP id by4mr845558vdc.17.1304697285985; Fri, 06 May 2011 08:54:45 -0700 (PDT) Sender: paulus.benedictus@gmail.com Received: by 10.220.176.10 with HTTP; Fri, 6 May 2011 08:54:45 -0700 (PDT) In-Reply-To: <4DC4153F.1040303@apache.org> References: <4DC3D0DD.5080101@apache.org> <4DC412B3.4060409@gmail.com> <4DC4153F.1040303@apache.org> Date: Fri, 6 May 2011 10:54:45 -0500 X-Google-Sender-Auth: UjmdfSPiREsrmXUfDEg2-3O2zYY Message-ID: Subject: Re: [POOL2] Java 1.5 or 1.6? From: Paul Benedict To: Commons Developers List Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Is it too radical to suggest POOL 2 be 1.5 and POOL 3 be 1.6? Just bump up major version every time you target a new major JDK. On Fri, May 6, 2011 at 10:35 AM, Mark Thomas 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. =A0I have pretty >> consistently advocated this, but given the work and inevitable >> stabilization required, we should at least ask the question. =A0Seems >> to me the goals should be 0) performance 1) maintainability 2) >> robustness 3) (configurable?) fairness. =A0Do 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-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