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