From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.5-pre1 (2020-06-20) on ip-172-31-74-118.ec2.internal X-Spam-Level: X-Spam-Status: No, score=-0.5 required=3.0 tests=BAYES_05 autolearn=ham autolearn_force=no version=3.4.5-pre1 Date: Sun, 19 Sep 1993 13:40 EDT From: HARBAUGH@ROO.FIT.EDU Subject: re:Problems with Alsys 386 V5.1.1 Compiler Message-ID: <9309191743.AA20127@ajpo.sei.cmu.edu> List-Id: >Subject: Problems with Alsys 386 V5.1.1 Compiler >I'm developing an application for the U.S. Air Force using CompuAdd 333 >computer with 8MB of memory. We're running under DOS 5.0 using the ALSYS 386 >Version 5.1.1 compiler. We're at the tail end of the project and we've run >into a real problem. After some period of time, usually twenty minutes or >so, the system begins to slow down. The longer the system runs the slower >things get. This set of symptoms suggests to me a dynamic memory problem. Two possible problems come to mind; a) the heap is getting fragmented and it is taking longe r and longer to find a place on the heap or b) the task control block chain is getting longer and longer and it is taking longer and longer to find the head o r tail of the chain or to find the proper place to link in a new task control block. >In an attempt to debug the system, I'm tracking how long a DELAY >statement takes by getting the time before the delay and the time after the >delay and displaying the difference. When the application first begins, a >one second delay actually takes 1.04 seconds (I've been using the low res >timer). Then, after some period of time, that delay time begins to get >longer and longer. After an hour of execution, it might be as long as two or >three seconds. This suggests that maybe the number of task control blocks is growing larger an d larger with time. >Alsys has provided me with several object files that fix >known tasking and memory allocation problems. This affects the problem, but >doesn't fix. I hope some one out there could provide me with some insight >into the problem. The above may provide some insight. >Or even better, if you know how to fix the problem. > How to fix the problem. Step 1: identify the possible problems. Perform a code inspection and look for reasons for dynamic memory allocation. Look for the keyword "new". Look for task objects created at runtime. Look for "unchecked_deallocation" usage. Step 2: examine each possible problem. Look for dynamically allocated objects which you believe you have freed using unchecked_deallocation. Read the Alsys Appendix F and see what unchecked_deallocation actually does. Run tests on the runtime to confirm its behavior. Look at dynamically created tasks. See if the amount of them grows without bound as a result of your program code. See if you believe that the tasks are destroyed by completion. Read Appendix F and see if the task control block is really destroyed upon completion. There is an AI that allows the runtime to keep a common "death certificate" for all completed tasks and therefore totally destroy the TCB. Determine what Alsys does. I have seen a runtime that does nothing special, one that keeps only one word of the TCB and others that implement the AI and make the problem go away. Maybe you fell into the abstraction & hiding trap where you hide a task in a package, export a procedure call and then each time the procedure is called a new task (and task control block) is created. The Ada language does not give you resource control. Resource control is done by the Ada Runtime system and whatever other resource managers are present in the execution environment (VMS, Unix etc). To avoid problems with dynamic memory management statically allocate everything, do no dynamic allocation. (Patient: "It hurts when I do this.", Doctor: "Don't do that.") > > Thanks, > > Charles Zinsmeyer > Southwest Research Institute > CZinsmeyer@SWRI.EDU > Post or send more data about your program, its execution environment and the symptoms and I will be happy to respond with whatever occurs to me. sam harbaugh HARBAUGH@ROO.FIT.EDU