Major Description
The SDKAllocator is used to 'wrap' internal structures into handles, that does a couple of things:
1) Validate that the object is of appropriate type before calling "release" on them (for example)
2) it keeps a linked list of all allocated object on the header heap. When the header heap goes out of scope, anything remaining gets automatically released.
#2 is, as far as I can tell, there for being backwards compatible with previous APIs (which we never supported). It also provides a means of lazy programming (or easy programming, depending on how you see it), where even if a plugin doesn't release resources properly, it still won't leak memory.
Now, I'm still investigating, but I suspect we could get away from most of the allocations at all, and effectively eliminate the release requirements as well. But even so, I think there's plenty of improvements that can be done in this area, which will eliminate a significant amount of malloc()'s (since the SDKAllocator uses xmalloc and xfree liberally, with no pools).
Comments in this area is much welcomed, since it might affect how our APIs will work in this area.