You need an IBM ID to vote, should you be inclined to do so.
Description: Since many releases, Enterprise PL/I allows the allocation of defined amounts of heap using the "ALLOCATE" builtin, to quote the manual:
"ALLOCATE allocates storage of size n in heap storage and returns the pointer to the allocated storage."
It would be highly advantageous if this builtin function could be enhanced to allocate a defined (rounded to 8/16 bytes) number of bytes inside an AREA, while returning a pointer.
Use case: Parsing XML (and similar) documents frequently result in complex list or tree structures. Clearing up those structures does require a substantial amount of processing as each node needs to be FREE'd individually in the correct order to avoid memory leaks.
By building such lists and/or trees inside an AREA, removal of the entire list or tree is reduced to a single "AREA=EMPTY();" statement, which saves significant amounts of CPU time.
Joined: 09 Mar 2011 Posts: 7309 Location: Inside the Matrix
You click on the link if you think it is a good idea and add your support. It's a fairly recent feature, I think, to allow request for enhancements to be submitted across the web.
Joined: 27 Oct 2009 Posts: 2481 Location: Netherlands, Amstelveen
Memory leaks are as old as the world. If they are not solved now what the heck are we doing. Its getting some piece of memory and playing around with it. But if someone wants to allocate storage for every node in a list, its just freeing the memory in the right order. And there is a lot of memory management software build into operating systems.
Joined: 07 Feb 2009 Posts: 1306 Location: Vilnius, Lithuania
PeterHolland wrote:
Memory leaks are as old as the world. If they are not solved now what the heck are we doing. Its getting some piece of memory and playing around with it. But if someone wants to allocate storage for every node in a list, its just freeing the memory in the right order. And there is a lot of memory management software build into operating systems.
The point is not freeing the memory, which is not very hard. The point is that freeing a tree with a few hundred nodes will take a considerable amount of time. Being able to wipe it out with a single instruction (which is in essence what an "AREA=EMPTY();" statement should generate under ideal circumstances will save a substantial amount of CPU time.
