Replace SDKAllocator with a ClassAllocator instance?

[Leif Hedstrom <zw...@apache.org>]

Hi all,

as a final effort to eliminate some "malloc" on the critical path for 
some very commonly used APIs, I have a proposal for removing the 
SDKAllocator entirely, and replace it with a simple ClassAllocator 
instance. The patch is attached to TS-577 for review.

Here's the executive summary:

* Replacing SDKAllocator with a ClassAllocator eliminates many 
malloc/free on the critical path (when plugins are in used). There's 
also some overhead of the SDKAllocator being copied/instantiated fairly 
often during a transaction (but that is probably marginal, it's a tiny 
class).

* Poorly written plugins will leak memory with this change. It is 
already required in all docs that you have to release these MLoc 
handles, but the way the SDKallocator works, when the header heap goes 
out of scope, it will automatically release (and therefore free) any 
MLoc handles that the plugin has created but not released. It's 
basically doubling as a garbage collector right now.

* The main reason, as far as I can understand, for having the 
SDKAllocator with garbage collection,  was for backwards compatibility 
with older versions of Inktomi Traffic Server, which did not require the 
"release" of these resources. Since we don't care about such backward 
comparability, I think that is a non-issue.


Any objections to doing this change?

-- Leif