You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@trafficserver.apache.org by "Leif Hedstrom (JIRA)" <ji...@apache.org> on 2010/12/03 00:56:11 UTC

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

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
             Fix For: 2.1.5


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.


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

Posted by "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 resolved TS-577.
------------------------------

    Resolution: Fixed

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


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

Posted by "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.


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

Posted by "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 reassigned TS-577:
--------------------------------

    Assignee: Leif Hedstrom

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