[Cs-dev] Csound 6 API request: TREE memory management
| Date | 2013-06-02 01:41 |
| From | Richard Henninger |
| Subject | [Cs-dev] Csound 6 API request: TREE memory management |
| Attachments | None None |
|
I was very happy to see the new csoundParseOrc/csoundCompileTree functions that split parsing and compiling apart by exposing the intermediate TREE structure. These functions’ existence opens up possibilities for working with or creating AST nodes directly
in a host program’s compiler or object model before they become INSTRTXT’s and INSDS’s for performance.
Currently, the memory used in building an AST by csoundParseOrc is released internally via csoundCompileTree as it calls an internal routine, delete_tree, which walks the AST freeing memory as it goes. This handles the standard use case where a TREE set
created by csoundParseOrc is immediately consumed and released by csoundCompileTree.
To realize the potential of creating or modifying AST’s in a host program, there should a way for a host program to free memory of potentially pruned or discarded nodes originally created by csoundParseOrc. This could be done by exposing the delete_tree
function to the API.
There really should also be a way to keep csoundCompileTree from deleting the memory (possibly pinned) of its AST nodes especially when created in managed languages like java or .net in the host program’s heap. This might be as simple as adding an extra
argument in csoundCompileTree to not call delete_tree when it finishes.
I would like to think that the program which allocs memory should be the one to free it in order to minimize the opportunities for memory leaks due to confusion over who owns what.
Richard Henninger
richard@rghmusic.com |
| Date | 2013-06-02 03:49 |
| From | Michael Gogins |
| Subject | Re: [Cs-dev] Csound 6 API request: TREE memory management |
| Attachments | None None |
So perhaps there should also be an allocator plugin. On Jun 1, 2013 8:41 PM, "Richard Henninger" <richard@rghmusic.com> wrote:
|
| Date | 2013-06-02 11:40 |
| From | Victor Lazzarini |
| Subject | Re: [Cs-dev] Csound 6 API request: TREE memory management |
| Attachments | None None |
On 2 Jun 2013, at 01:41, Richard Henninger wrote:
Dr Victor Lazzarini Senior Lecturer Dept. of Music NUI Maynooth Ireland tel.: +353 1 708 3545 Victor dot Lazzarini AT nuim dot ie |
| Date | 2013-06-02 12:48 |
| From | Victor Lazzarini |
| Subject | Re: [Cs-dev] Csound 6 API request: TREE memory management |
| Attachments | None None |
Actually, no, the memory created in csoundParseOrc() is not released in csoundCompileTree(). The frontend function csoundCompileOrc() calls those two functions and then releases the memory. So if you build your AST and compile it with csoundCompileTree(), the tree should still be preserved after compilation. Victor On 2 Jun 2013, at 01:41, Richard Henninger wrote: Currently, the memory used in building an AST by csoundParseOrc is released internally via csoundCompileTree as it calls an internal routine, delete_tree, which walks the AST freeing memory as it goes. This handles the standard use case where a TREE set created by csoundParseOrc is immediately consumed and released by csoundCompileTree. Dr Victor Lazzarini Senior Lecturer Dept. of Music NUI Maynooth Ireland tel.: +353 1 708 3545 Victor dot Lazzarini AT nuim dot ie |
| Date | 2013-06-02 13:10 |
| From | Victor Lazzarini |
| Subject | Re: [Cs-dev] Csound 6 API request: TREE memory management |
| Attachments | None None |
Some further thoughts below
We could expose delete_tree(), but that can only be used with trees build with csoundParseOrc(), because the mem allocation is done with Csound's own routines for that (and not standard malloc/free). That is fairly simple.
As I said in my previous e-mail, that is not needed because csoundCompileTree() does not free the tree memory. CsoundCompileOrc() does, but rightly so as it creates a new tree with csoundParseOrc().
Definitely so. I think there are two scenarios at the moment 1) host program creates its TREE using its own code, and then calls csoundCompileTree(). This is already OK, since there is no freeing of the TREE involved and it's up to the program to do it. 2) host program creates a TREE with csoundParseOrc() and calls csoundCompileTree(). This needs a delete_tree() in the API. Note that the memory will be freed when Csound is destroyed because that is implemented by the Csound memory management. But I see that it's important to have means of freeing the resources at an earlier stage. I'll add that to the API. Victor
Dr Victor Lazzarini Senior Lecturer Dept. of Music NUI Maynooth Ireland tel.: +353 1 708 3545 Victor dot Lazzarini AT nuim dot ie |
| Date | 2013-06-02 14:59 |
| From | Richard Henninger |
| Subject | Re: [Cs-dev] Csound 6 API request: TREE memory management |
| Attachments | None None |
|
Well analyzed. Thanks, Victor. I fooled myself into thinking I was reading csoundCompileTree when it was actually csoundCompileOrc. Sorry about that. I agree that exposing the delete_tree function is all that is needed to cover all scenarios I can
think of.
Richard Henninger
richard@rghmusic.com From: Victor
Lazzarini
Sent: Sunday, June 02, 2013 8:11 AM To: Developer discussions Some further thoughts below
We could expose delete_tree(), but that can only be used with trees build with csoundParseOrc(), because the mem allocation is done with Csound's own
routines for that (and not standard malloc/free). That is fairly simple.
As I said in my previous e-mail, that is not needed because csoundCompileTree() does not free the tree memory. CsoundCompileOrc() does, but rightly so as it creates a new tree with csoundParseOrc().
Definitely so. I think there are two scenarios at the moment
1) host program creates its TREE using its own code, and then calls csoundCompileTree(). This is already OK, since
there is no freeing of the TREE involved and it's up to the program to do it.
2) host program creates a TREE with csoundParseOrc() and calls csoundCompileTree(). This needs a delete_tree() in
the API. Note that the memory will be freed when Csound is destroyed because that is implemented by the Csound memory management.
But I see that it's important to have means of freeing the resources at an earlier stage. I'll add that to the API.
Victor
Dr Victor Lazzarini
Senior Lecturer
Dept. of Music
NUI Maynooth Ireland
tel.: +353 1 708 3545
Victor dot Lazzarini AT nuim dot ie
|