[jira] Updated: (TS-577) Is SDKAllocator really necessary? Or can we at least minimize the amount of mallocs ?

["Leif Hedstrom (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/TS-577?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Leif Hedstrom updated TS-577:
-----------------------------

    Attachment: TS-577.diff

Proposed changes, which replaced the SDKAllocator with a class allocator, and removes the "garbage collection" feature.

> Is SDKAllocator  really necessary? Or can we at least minimize the amount of mallocs ?
> --------------------------------------------------------------------------------------
>
>                 Key: TS-577
>                 URL: https://issues.apache.org/jira/browse/TS-577
>             Project: Traffic Server
>          Issue Type: Bug
>          Components: TSAPI
>            Reporter: Leif Hedstrom
>            Assignee: Leif Hedstrom
>             Fix For: 2.1.5
>
>         Attachments: TS-577.diff
>
>
> 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.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.