In-Depth

July Response Time

• 07/01/1999

I just read [Dick Brodine’s] article ("A Case for Dynamically Allocted Memory," page 74) in the May Enterprise Systems Journal, and I agree with your case. We needed a Getmain function for Fortran IV quite some time ago. So I wrote a Fortran callable ALC subroutine that would do a Getmain and return a bias that the Fortran programmer would add to the left-most subscript of a supplied dummy array to get to the gotten array. The good old days! Now they have me writing in C, and C just loves alloc.

We at Gulf Research, back in the ’70s, wrote assembler Getmain constructs for use with Fortran G compiler applications. Seems like a number of people have had the same idea.

____________________

In the article "A Case for Dynamically Allocated Memory," [Dick Brodine] makes a lot of good points about dynamic memory allocation, but almost completely disregards the negative aspects. Sure, not having to modify code is ideal, but it’s as valid as "one-size-fits-all."

Don’t get me wrong. As an avid ALC programmer, I use dynamic allocation and pointers often; even with C, COBOL and other languages. But, one must also consider the negatives when deciding whether or not to dynamically allocate storage, and just how it should be implemented.

Dynamic allocation involves an enormous amount of operating system overhead. And when allocating and freeing many different size areas, there’s a risk of checkerboarding memory so much that you "run out," even when most of it is free.

His method (example 3) for determining the number of entries to allocate for the table can be worse than allocating a huge area to begin with. The SQL "select count(*) into n from adb2table" causes the database to return in a variable (n) the number of rows in the database table (adb2table). Some databases can only determine this by physically reading the data sequentially until the end is reached. You effectively read the database twice just to load the table.

And his mention of page swaps, in support of exact-size allocation, baffles me. A page is not swapped into memory unless a page fault occurs, which won’t until a byte that has been swapped-out (not in real memory) is accessed. Allocating 64K for a table, but only using the first 3K results in no more page swap-ins than allocating only 3K. Sure, the other 60K might get swapped-out at some time, but the overhead it could take to determine how big to make the table often outweighs the possibility of that swap-out and its associated overhead.

To build a true dynamic size table, I define it as a linked list, then allocate blocks of memory as needed while loading the table. This eliminates the need to determine the actual table size before loading the table, supports variable length table rows, if not accessing the table randomly, and helps minimize the number of requests for storage.

Finally, there must be some kind of limit to table size whether it is physical (actual bytes allocated) or logical (warning message when a threshold is reached). The "limit" would notify the programming staff that a table is becoming too large and an alternative processing method might be more appropriate. Then again, there’s nothing like a good ol’ ABEND to get everybody’s attention.

Mr. Pearce levels several valid criticisms with regard to the disadvantages of utilizing dynamically allocated memory. These are criticisms from a computer performance perspective. From a maintainability and understandability perspective, I still think that it is time that COBOL includes dynamic memory allocation constructs.

Dynamic memory allocation can be less efficient with regard to system resource usage, but the code is much easier to maintain. The days of concern for system resource usage is becoming a thing of the past due to large gains made in hardware processing power. Furthermore, Pl/i, C, C++, Assembler, Java and Visual Basic applications do not require the resolution of "table dimension exceeded." Such applications are thus easier to maintain.

If you have maintained large-scale legacy applications written in COBOL over an extended period of time, how many times have you been forced to repair a subcomponent of the system in order to accommodate "table bounds exceeded"?

I think it is about time that COBOL join the rest of the programming world by providing dynamic memory allocation constructs. Once again, Mr. Pearce’s performance criticisms with regard to the issue are valid and I accept the critique. But, computer performance is no longer the pivotal issue in application programming that it was years ago. Today, maintainability is more important, from a cost point of view.

Finally, I believe the performance concerns are valid with one exception: The over-allocation of arrays has paging implications. And that’s the point. I should have clearly stated "paging implications" as opposed to page swaps. Unreferenced statically allocated memory in an executable may not result in additional page swaps, but the number of pages in the executable would certainly be larger and the pages would have to be managed by the operating systems. Hence, I think the correct statement is that over allocation of static memory has "paging implications."