tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From <>
Subject Re: J-T-C and Ajp12
Date Wed, 07 Nov 2001 18:08:57 GMT
On Wed, 7 Nov 2001, Aaron Bannert wrote:

> On Wed, Nov 07, 2001 at 09:04:06AM -0800, wrote:
> > The big challenge will be replacing the pools - and I would like to delay
> > this a bit ( and maybe have a transition period where we can use both ). (
> > the fact that APR allocation is synchronized worries me a bit from
> > performance point of view - I know C is not java :-))
> Malloc has its own locks, and pools are just a layer on malloc. Just
> like anything you should limit the number of allocation calls you make,
> but it won't be worse than using malloc directly. The biggest gain that
> pools give you are a way to "checkpoint" the memory at points where you
> would usually do a whole bunch of calls to free(), since in pools they
> become a constant operation.

My understanding ( at least the code in jk_pool ) is a bit different.

The jk_pool is created it with an initial ( malloc-ed ) buffer, and all
allocations are done inside this buffer, without sync. ( the
original malloc requires sync ). If the initial buffer is full we continue
to allocate using malloc, but that shouldn't happen in the common case.

AFAIK java uses a similar procedure to optimize allocations.

We can ( should ) recycle the pool and make it a per-thread data - that
would give sync-free allocation in most cases.

AFAIK APR pools are also implementing a 'local' allocation, but they seem
to sync. Probably not a big deal, as C sync is much cheaper than java
sync, but I would like to check first.


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

View raw message