Re: Beware: Rep spec on an enumeration type causes code explosion

[gwinn@res.ray.com (Joe Gwinn)]

In article <EKrsrr.LD7.0.-s@inmet.camb.inmet.com>,
stt@houdini.camb.inmet.com (Tucker Taft) wrote:

> Joe Gwinn (gwinn@res.ray.com) wrote:
> 
> : ...
> : Exception handlers.  We were declaring a number of exception handlers at
> : the beginning of each and every module, so every time the module was
> : entered, the context had to be saved, and every time the module was
> : exited, the context was popped off the exception stack and discarded,
> : regardless of if an exception was ever raised.  This was easily solved;
> : now, only tasks declare exception handlers, not modules.
> 
> I believe Green Hills is beginning to work on an implementation of
> exceptions that uses a PC-indexed table rather than setjmp/longjmp.  
> However, as Robert points out, using such a table is significantly more
> machine-dependent, and generally requires coordination with the linker
> and more complex out-of-line algorithms in the run-time.

This sounds good, but I would guess that it won't arrive in time for the
current project.  

Probably two thirds of the high-end embedded realtime market will target
the PowerPC, so that's one place where some machine dependency may be
worthwhile.

 
> As far as enumeration types, as others have pointed out, the Ada 95
> standard requires that the internal codes for enumeration types are
> contiguous and start at zero, so you are not in any danger if you leave
> out your "confirming" representation clauses.  It would be nice if
> our front end recognized "confirming" enumeration representation 
> clauses, but as usual, there are many possible "optimizations" 
> and this one never made it to the top of the list.
> One might argue that this is not really an optimization, but 
> it does require special code to recognize, and so represents
> yet another "special case" that you have to decide the priority
> of recognizing.

The key issue was that we had no way of knowing the dire consequences of
this innocent looking bit of standard Ada, until we had gone a fair
distance down that wrong road.  One wonders what other surprises lay in
wait.

A number of folk have cited chapter and verse that enumerations do start
at zero if left alone.  This was not widely known, apparently, perhaps
because Ada83 didn't govern this.  


> : ...
> : Memory Management.  The Ada Runtime System makes extensive calls to the C
> : functions malloc() and free(), a cause for worry.  
> 
> It might be interesting to identify where this is really happening.
> Were these from calls in your source code to "new" and instances
> of Unchecked_Deallocation, or were they "implicit"?

They were implicit.  Our programmers are in fact forbidden to deallocate
using the Ada RTE, to avoid fragmentation etc.  The profiler caught no
miscreant applications.

Now that use of exception handlers and rep specs on enumerations have been
restricted, the calls to malloc and free dropped to near zero.  We will
trap and inspect all callers of free, so if any of our programmers are
using malloc/free, they will be caught.  

What to do about Ada RTE implicit use of malloc/free is quite another issue.

By the way, the issue is use of free, not malloc per se.  The applications
are allowed to allocate structures during startup, but they are not
allowed to use free.  They must instead keep the memory and manage it
themselves, using a simple and obviously fragmentation proof algorithm.


> We have versions of our runtime which only use the heap "implicitly" 
> for task control blocks (and these are recycled explicitly rather than 
> using free) and for task stacks (and again, these are recycled rather
> than using free).  So the only calls on "free" should be in response
> to an explicit call on an instance of unchecked-deallocation. 

This sounds good, but I don't know that it's draconian enough for embedded
realtime.  I don't know that I would give random users the choice of
versions.  As I said above, we forbid users to use deallocation (and thus
free).  Is that runtime set up so I can flip a compiler switch to catch
any users that didn't understand that they are not allowed to use
deallocate?


> ... Furthermore,
> we also have our own implementation of malloc/free which uses 
> "quick fit" rather than the traditional C "first fit."  This may
> be the algorithm

Quick-fit algorithms also can fragment; what's different is the spectrum
of request sizes needed to provoke trouble.  Actually, many quick-fit
algorithms generate worse fragmentation than the worst-fit algorithms. 
All the variable-length memory management algorithms have their advantages
and disadvantages, but the biggest disadvantage is that they are
inherently statistical in nature, so there is always a request spectrum
that will kill them.  

Historically, we have found that the only approach that always works, even
when the system is straining under the load, is a fixed-block allocator
offering three or four project-specific sizes of block.


Joe Gwinn