lib0029.html

Memory Management—Algorithms and implementation in C/C++ Introduction Chapter 1 - Memory Manag

</tr>
<tr valign="top">
<td class="td" align="left">
<p class="table-para">C + +</p>
</td><td class="td" align="left">
<p class="table-para">object-oriented</p>
</td><td class="td" align="left">
<p class="table-para">10,000,000 lines</p>
</td>
</tr>
</tbody>
</table>
<p class="para">Inevitably, the languages that survive, and perhaps pass on their features to new languages, will be the ones that are the most effective at managing complexity. In the early days of UNIX, almost every bit of system code was written in C. As operating systems have grown, the use of C, as a matter of necessity, has given way to implementation in C+ + . According to an article in the July 29, 1996, <I>Wall Street Journal</I>, the Windows NT operating system consists of 16.5 million lines of code. It is no surprise, then, that Microsoft has begun building some of its primary OS components entirely in C + +. For example, a fundamental component of the Windows NT kernel, the <a name="364"></a><a name="IDX-171"></a>Graphics Device Interface (<span class="fixed">GDI32.DLL</span>), was written completely in C+ + .</p>
<div class="qandaset">
<table border="0" cellpadding="0">
<tr class="qandaentry">
<td class="td" valign="top" width="2%">
<p class="first-para">
<a name="LiB18"><b>1.&nbsp;</b></a>
</p>
</td><td class="td" valign="top" width="90%">
<p class="first-para">What does any of this have to do with memory management?</p>
</td><td class="td" valign="top" width="8%">
<p class="first-para">
<a href="#LiB17"><img src="images/question.gif" height="24" width="24" alt="The evolution of programming languages has basically mirrored the development of memory management since the 1950s. As I mentioned earlier, higher-level languages like COBOL and FORTRAN were born around the same time as the transistor. In the beginning, computer memory was entirely visible to a program. There was no segmentation and no protection. In fact, the program typically took up all the available memory. Likewise, the first computer programming languages were also fairly primitive. As time passed, both memory management and programming languages matured into the powerful tools that they are today. There are memory managers today that allow dozens of tightly coupled processors to share the same address space, and there are elegant object-oriented languages that allow complexity to be constrained. " border="0"></a>
</p>
</td>
</tr>
</table>
<p class="bold">Answers</p>
<table border="0" cellpadding="0">
<tr class="qandaentry-answer">
<td class="td" valign="top" width="2%">
<p class="first-para">
<a class="internaljump" name="answer.nr-qandaentry.DEDE26A7-4671-4553-8FDF-0EC3AB9ACEA2" href="#LiB18"><b>1.</b></a>&nbsp;</p>
</td><td class="td" valign="top" width="90%">
<p class="first-para">The evolution of programming languages has basically mirrored the development of memory management since the 1950s. As I mentioned earlier, higher-level languages like COBOL and FORTRAN were born around the same time as the transistor. In the beginning, computer memory was entirely visible to a program. There was no segmentation and no protection. In fact, the program typically took up all the available memory. Likewise, the first computer programming languages were also fairly primitive. As time passed, both memory management and programming languages matured into the powerful tools that they are today. There are memory managers today that allow dozens of tightly coupled processors to share the same address space, and there are elegant object-oriented languages that allow complexity to be constrained.</p>
</td>
</tr>
</table>
</div>
<p class="para">In the following sections, I am going to provide a brief survey of several programming languages in order to demonstrate how different languages make use of the different high-level memory services. I will begin with early languages and work my way slowly to the present day. Along the way, I will try to offer examples and insight whenever I have the opportunity.</p>
<div class="example">
<span class="example-title"><span class="example-titlelabel">Case Study: </span>COBOL</span><a name="365"></a><a></a>
<div class="formalbody">
<table class="BlueLine" border="0" cellspacing="0" cellpadding="0" width="100%">
<tr>
<td bgcolor="000080" class="bluecell"><font size="2" face="Arial" color="010100"><b><img src="_.gif" width="1" height="2" alt="Start example" border="0"></b></font></td>
</tr>
</table>
<p class="first-para">COBOL &mdash; this one word stirs up all sorts of different reactions in people. COmmon Business Oriented Language was formally defined in 1959 by the Conference On DAta SYstems Language (CODASYL). COBOL has its roots in the FLOW-MATIC language that was developed by Rear Admiral Grace Murray Hopper. Admiral Hopper is considered the mother of modern business computing.</p>
<p class="para">"It's always easier to ask forgiveness than it is to get permission." &mdash; Grace Murray Hopper</p>
<p class="para">In 1997, the Gartner Group estimated that there were over 180 billion lines of COBOL code in use and five million new lines of COBOL code being written each year. Authors like Carol Baroudi even estimated the number of lines of legacy COBOL code at 500 billion lines. Needless to say, this mountain of code has taken on a <a name="366"></a><a name="IDX-172"></a>life of its own and probably developed enough inertia to last at least another hundred years.</p>
<p class="para">The preponderance of COBOL is partially due to historical forces. COBOL was adopted by the United States Department of Defense (DoD) in 1960 and became a de facto standard. The reason for this is that the DoD, the largest purchaser of computer hardware both then and now, would not buy hardware for data processing unless the vendor provided a COBOL compiler. Another reason COBOL is so widespread is due to the fact that COBOL is very good at what it is designed for &mdash; executing business calculations. When it comes to performing financial computations to fractions of a cent without introducing rounding errors, COBOL is still the king of the hill. The language features that support financial mathematics in COBOL are a very natural part of the language and extremely easy to use.</p>
<blockquote class="blockquote">
<div class="qandaset">
<table border="0" cellpadding="0">
<tr class="qandaentry">
<td class="td" valign="top" width="2%">
<p class="first-para">
<a name="LiB20"><b>1.&nbsp;</b></a>
</p>
</td><td class="td" valign="top" width="90%">
<p class="first-para">Will COBOL ever die? Will it be replaced?</p>
</td><td class="td" valign="top" width="8%">
<p class="first-para">
<a href="#LiB19"><img src="images/question.gif" height="24" width="24" alt="I would like to assume that someday COBOL will be retured. However, I suspect that COBOL houses will probably, fundamentally, stay COBOL houses. 180 billion lines is a lot of source code. They may occasionally renovate with Object COBOL or slap on a new layer of paint with Java, but replacing the plumbing of an aging mansion is a very expensive proposition. In fact, it's often cheaper to just tear the house down and build a new one. Try explaining this to the CFO of a Fortune 100 company. Legacy code may be old, but it supports core business functionality and has been painstakingly debugged. In this kind of situation, legacy code is seen as a corporate asset that represents the investment of hundreds of thousands of man-hours. An architect who actually does want to overhaul a system will, no doubt, face resistance from a CFO whose orientation tends toward dollars and cents. If a system does what it's supposed to and helps to generate income, then why fix it? Throwing everything away for the sake of technology alone is a ridiculously poor excuse. Another factor that inhibits the replacement of legacy code is the sheer size of an existing code base. In order to replace old code with new code, you have to completely understand the functionality that the old code provides. In a million-line labyrinth of 80-column code, business logic is hard to extract and duplicate. Often, the people who wrote the code have left the company or have been promoted to different divisions. Instituting even  relatively simple changes can prove to be expensive and involve months of reverse engineering and testing. I've known Y2K programmers who were too scared to modify legacy code. The old code was so convoluted that they didn't know what kind of repercussions their changes would have. " border="0"></a>
</p>
</td>
</tr>
</table>
<p class="bold">Answers</p>
<table border="0" cellpadding="0">
<tr class="qandaentry-answer">
<td class="td" valign="top" width="2%">
<p class="first-para">
<a class="internaljump" name="answer.nr-qandaentry.A252763A-D146-4265-9580-FCA239259198" href="#LiB20"><b>1.</b></a>&nbsp;</p>
</td><td class="td" valign="top" width="90%">
<p class="first-para">I would like to assume that someday COBOL will be retured. However, I suspect that COBOL houses will probably, fundamentally, stay COBOL houses. 180 billion lines is a lot of source code. They may occasionally renovate with Object COBOL or slap on a new layer of paint with Java, but replacing the plumbing of an aging mansion is a very expensive proposition. In fact, it's often cheaper to just tear the house down and build a new one. Try explaining this to the CFO of a Fortune 100 company.<p class="first-para">Legacy code may be old, but it supports core business functionality and has been painstakingly debugged. In this kind of situation, legacy code is seen as a corporate asset that represents the investment of hundreds of thousands of man-hours. An architect who actually does want to overhaul a system will, no doubt, face resistance from a CFO whose orientation tends toward dollars and cents. If a system does what it's supposed to and helps to generate income, then why fix it? Throwing everything away for the sake of technology alone is a ridiculously poor excuse.</p>
<p class="last-para">Another factor that inhibits the replacement of legacy code is the sheer size of an existing code base. In order to replace old code with new code, you have to completely understand the functionality that the old code provides. In a million-line labyrinth of 80-column code, business logic is hard to extract and duplicate. Often, the people who wrote the code have left the company or have been promoted to different divisions. Instituting even <a name="367"></a><a name="IDX-173"></a>relatively simple changes can prove to be expensive and involve months of reverse engineering and testing. I've known Y2K programmers who were too scared to modify legacy code. The old code was so convoluted that they didn't know what kind of repercussions their changes would have.</p>
</p>
</td>
</tr>
</table>
</div>
</blockquote>
<p class="para">COBOL has been through several revisions. In 1968, the American National Standards Institute (ANSI) released a standard for COBOL. This COBOL standard was revisited in 1974. The current ANSI standard for COBOL, however, is a combination of the ANSI standard that was developed in 1985 coupled with some extensions that were added on in 1989. There have been moves toward a form of object-oriented COBOL and vendors have come out with their own forms of it. Nevertheless, when someone talks about ANSI COBOL, they are referring to COBOL 85 with the additions that were made in 1989. In the following discussion, I will use COBOL 85. I will also compile my code using Fujitsu's COBOL85 V30L10 compiler. If you are running Windows, you can download a copy from Fujitsu's web site.</p>
<p class="para">COBOL is a structured language that does not use a stack or a heap. All that a COBOL program has at its disposal is a single global data section and blocks of instructions. In COBOL parlance, a program consists of four divisions:</p>
<ol class="orderedlist">
<li class="first-listitem">
<p class="first-para">Identification division</p>
</li>
<li class="listitem">
<p class="first-para">Environment division</p>
</li>
<li class="listitem">
<p class="first-para">Data division</p>
</li>
<li class="listitem">
<p class="first-para">Procedure division</p>
</li>
</ol>
<p class="para">The <i class="emphasis">identification division</i> is used to let the COBOL compiler know the name of the program it is translating. The identification division doesn't get translated in machine code; it is more of a directive. The environment division is used to describe the platform that a program will be built on and run on, as well as to specify the files that it will use. Again, this is mostly metadata that is intended for use by the compiler.</p>
<p class="para">The data division contains, among other things, a working storage section that is basically a large static memory region that serves all of a program's storage needs. As I said before, there is no heap and no stack that a COBOL program can utilize. All that exists is one big chunk of fixed-size, global memory.</p>
<p class="para">The procedure division consists of blocks of instructions. These blocks of code do not have formal parameters or local variables like functions in C. This would require a stack, which COBOL programs <a name="368"></a><a name="IDX-174"></a>do not have. If you want to create storage for a particular block of code, you will need to use some sort of naming convention in the working storage section to help distinguish all the global variables. So the next time someone asks you "what's in a name?", you can tell them.</p>
<p class="para">In general, divisions are composed of sections and sections are composed of paragraphs. Paragraphs are likewise composed of sentences in an effort to make COBOL resemble written English. To this end, COBOL sentences are always terminated with periods.</p>
<p class="para">Division <span class="unicode">&rarr;</span> Section <span class="unicode">&rarr;</span> Paragraph <span class="unicode">&rarr;</span> Sentence.</p>
<p class="para">Here is a simple example so that you can get a feel for how these divisions, sections, and paragraphs are implemented in practice.</p>
<div class="informalexample">
<pre class="literallayout">
<span style="background-color:d9d9d9">000010 @OPTIONS MAIN</span>
<span style="background-color:d9d9d9">000013 IDENTIFICATION DIVISION.</span>
<span style="background-color:d9d9d9">000020 PROGRAM-ID. FIRSTAPP.</span>
<span style="background-color:d9d9d9">000021* ----------------------------------------------</span>
<span style="background-color:d9d9d9">000022 ENVIRONMENT DIVISION.</span>
<span style="background-color:d9d9d9">000023 CONFIGURATION SECTION.</span>
<span style="background-color:d9d9d9">000024 SOURCE-COMPUTER. INTEL.</span>
<span style="background-color:d9d9d9">000025 OBJECT-COMPUTER. INTEL.</span>
<span style="background-color:d9d9d9">000026 INPUT-OUTPUT SECTION.</span>
<span style="background-color:d9d9d9">000027*-----------------------------------------------</span>
<span style="background-color:d9d9d9">000028 DATA DIVISION.</span>
<span style="background-color:d9d9d9">000029 WORKING-STORAGE SECTION.</span>
<span style="background-color:d9d9d9">000030 01 ASSETS  PIC 9(3)v99    VALUE 000.00.</span>
<span style="background-color:d9d9d9">000031 01 DEBT    PIC 9(3)v99    VALUE 000.00.</span>
<span style="background-color:d9d9d9">000032 01 NET     PIC S9(3)v99   VALUE 000.00.</span>
<span style="background-color:d9d9d9">000033 01 PRINT   PIC ZZZ.ZZ.</span>
<span style="background-color:d9d9d9">000034*-----------------------------------------------</span>
<span style="background-color:d9d9d9">000035 PROCEDURE DIVISION.</span>
<span style="background-color:d9d9d9">000036 MAIN-CODE SECTION.</span>
<span style="background-color:d9d9d9">000037 MAIN.</span>
<span style="background-color:d9d9d9">000038 MOVE 120.34 TO ASSETS.</span>
<span style="background-color:d9d9d9">000039 MOVE 50.20  TO DEBT.</span>
<span style="background-color:d9d9d9">000040 PERFORM COMPUTE-NET-WORTH.</span>
<span style="background-color:d9d9d9">000050 STOP RUN.</span>
<span style="background-color:d9d9d9">000060 SUBROUTINE SECTION.</span>
<span style="background-color:d9d9d9">000070 COMPUTE-NET-WORTH.</span>
<span style="background-color:d9d9d9">000080 MOVE ASSETS TO NET.</span>
<span style="background-color:d9d9d9">000090 SUBTRACT DEBT FROM NET.</span>
<span style="background-color:d9d9d9">000091 MOVE NET TO PRINT.</span>
<span style="background-color:d9d9d9">000100 DISPLAY  " NET: " PRINT.</span>
</pre>
</div>
<p class="para">The above program prints out:</p>
<div class="informalexample">
<pre class="literallayout">
NET:  70.14<a name="369"></a><a name="IDX-175"></a>
</pre>
</div>
<p class="para">I have tried to help delineate the different program divisions using comment lines. As you can see, the program consists primarily of data and code. The memory model that this program uses is probably closely akin to the one displayed in <a class="internaljump" href="#ch03fig14">Figure 3.14</a>.</p>
<p class="para">
<div class="figure">
<a name="370"></a><a name="ch03fig14"></a><span class="figuremediaobject"><a href="images/fig203%5F01%5F0%2Ejpg" NAME="IMG_63" target="_parent"><img src="images/fig203_01.jpg" height="308" width="350" alt="Click To expand" border="0"></a></span>
<br style="line-height: 1">
<span class="figure-title"><span class="figure-titlelabel">Figure 3.14</span></span>
</div>
</p>
<p class="para">
<table border="0" cellspacing="0" cellpadding="0" class="note">
<tr>
<td valign="top" class="admon-check"></td><td valign="top" class="admon-title">Note&nbsp;</td><td valign="top" class="admon-body">
<p class="first-para">You might notice line numbers in the previous program's listing. This is a holdover from the days when punch cards were fed to mainframes. The motivation was that if you dropped your box of cards and they became mixed up, you could use the line numbering to sort your cards back to the proper order.</p>
</td>
</tr>
</table>
</p>
<p class="para">
<table border="0" cellspacing="0" cellpadding="0" class="note">
<tr>
<td valign="top" class="admon-check"></td><td valign="top" class="admon-title">Note&nbsp;</td><td valign="top" class="admon-body">
<p class="first-para">The arrangement of a COBOL application is closer to that of an assembly language program than it is to any structured language. Data is clumped together in one section, and the code consists of very crude blocks of instructions. Take a look at the following Intel assembly language program, and you will see what I mean. COBOL is, without a doubt, a prehistoric language.</p>
</td>
</tr>
</table>
</p>
<div class="informalexample">
<pre class="literallayout">