apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sander Striker" <stri...@apache.org>
Subject RE: SMS as Pools Patch
Date Thu, 12 Jul 2001 10:41:23 GMT
[...]
> Here's a possible taxonomy of allocation types:
> 
> Type 1: Allocations that will not be returned to the SMS (and will
>         get freed only when the SMS itself is destroyed)
> 
> Type 2: Allocations that will be returned to the SMS during its
>         lifetime

And this can be accomplished by choosing the type of sms to
use at create time.

> The first type includes most appliation data structures
> allocated from per-request pools in the httpd: small strings
> and structs.  For these, the optimal implementation uses O(1)
> pointer arithmetic for allocation (like apr_sms_trivial or
> the original pool code), and deallocation is a no-op.

Yes.

> The second category includes bigger allocations: the messages
> in your RPC example, and subrequests in the httpd.  For these,
> the deallocation can't be a no-op.  Instead, the space being
> returned to the SMS should actually be made available for
> subsequent allocation requests.  And the allocation/deallocation
> logic needs to be fast yet avoid too much fragmentation.  To
> perform well in the general case, it basically needs to be a
> well-tuned malloc implementation.
> 
> Using this model, an SMS itself could figure out the type of
> each allocation request based on the number of bytes requested:
> small requests would get allocated out of the pool as in
> apr_sms_trivial, and large requests would get delegated to
> a root SMS that called malloc.  (I guess an SMS that did this
> would be a hybrid tracking/trivial SMS?)

I think a hybrid power of 2/tracking would do the trick very well.
This allows for fast reallocs which is what you need in RPC.

Sander


Mime
View raw message