tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Aaron Bannert <>
Subject Re: J-T-C and Ajp12
Date Wed, 07 Nov 2001 18:43:32 GMT
On Wed, Nov 07, 2001 at 10:08:57AM -0800, wrote:
> > 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.

I was merely speaking about APR as I am unfamiliar with the internals
of mod_jk. Having just browsed through the jk_pool.c code I have
a question: Is this intended to be threadsafe? (I'm guessing not, since
it was targeted at apache-1.3, no?)

> 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.

APR also implements it this way, mostly to reduce the number of calls to
malloc but most importantly to reduce memory fragmentation and freelist
management (ala the O(1) freeing I mentioned before). We have experimented
with a per-thread freelist in APR, but the overhead of managing multiple
allocation schemes seemed to outweight the benefits.


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

View raw message