Mailing-List: contact tomcat-dev-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Tomcat Developers List" <tomcat-dev@jakarta.apache.org>
Message-ID: <BBDCA5B56D25F843A025AE850BA70F0604DED6@css8.slib.com>
From: GOMEZ Henri <hgomez@slib.fr>
To: Tomcat Developers List <tomcat-dev@jakarta.apache.org>
Subject: RE: Jk2: pools and memory
Date: Fri, 7 Dec 2001 10:40:23 +0100 
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"

>The current code is using some 'interesting' tricks with the jk_pools -
>it does some funny buffer allocations on the stack and use the buffer
>to create a pool ( which itself is allocated on the stack ).
>
>While this may have some performance benefits, the code is 
>extremely hard
>to read, and doesn't 'map' to the new APR pool.
>
>What I would like to do ( if nobody objects ) is to use:
> struct jk_pool {
>
>  ...
>  jk_pool_t *(*createChild)( jk_pool_t *_this, int sizeHint );
>  ...
> }
>
>The pool_open, etc will be removed - same for the buf[] based 
>allocation.

why not. Frankly you love too much java :)

>Given that we recycle the endpoint ( and it's pool ) - I don't 
>think we'll
>loose too much. If APR is used we'll use apr pools anyway ( which don't
>have support for the funny stack allocation ). For non-APR case, malloc
>will be fine.
>
>I'll also go ahead and replace all mallocs in the code to use the
>pools.
>
>However, I'm not an C expert ( or even a C programmer ) - if 
>I'm missing
>something please let me know.

free must match malloc, that's all for now :=)
Question could be about recycling pools.

PS: Costin, you go too fast, I didn't recognize anything in jk2 ;)

--
To unsubscribe, e-mail:   <mailto:tomcat-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:tomcat-dev-help@jakarta.apache.org>