re:Problems with Alsys 386 V5.1.1 Compiler

re:Problems with Alsys 386 V5.1.1 Compiler

[HARBAUGH]

>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