Re: Compiling ooc-951220

[Frank Copeland <fjc@wossname.apana.org.au>]

On Jan 8 Michael van Acken wrote:

> >  An interesting comparison: Compiling frontend/ParseStatm.mod with OOC
> >  itself requires about 3.5M of free RAM, while compiling it with Oberon-A's
> >  OC requires about 600K. Both these figures include the RAM consumed by the
> >  compiler's code and stack.
> >
> I'm really surprised that you only needed 3.5M.  I need >5.0M when
> running it on my Linux box.  But I'm only using a conswervative, C
> based garbage collector.  Btw, the GSA code grows even more with the
> most recent version (fixed a bug with $mem arguments), so you'll need
> a few K more.

It wasn't an exact measurment, but I typically have around 3.7M free and
compiling this module just about exhausted free memory. I don't have
virtual memory like you do on Linux, so its quite a serious concern. The
last time I tried to install VMM (a virtual memory manager) I got nothing
but crashes, but there is a new version out so I might try again.

> You probably want to know why it uses so much memory.  First of all,
> GSA code representation uses lots of memory blocks to store its
> instructions, operands, results, etc.  Some of this data is quite
> large, others are allocated in huge quantities.  Here is the size of
> some types:
[...]

On top of that my allocator adds an overhead of 8-12 bytes for record
allocations and 12-16 bytes for dynamically allocated open arrays. The
exact amount depends on rounding by the OS. Allocating lots of small
structures is *bad* news. I keep meaning to implement a more efficient
allocator, and this may be the right incentive :-).

[...]
> Doing the whole translation process on a per function basis should
> decrease memory requirements drastically.  That is, if each procedure
> is converted to GSA, optimized, put into the object file, and
> discarded, the total amount of memory needed (for GSA) is basically
> the size of the largest procedure.
>
> This approach has the disadvantage, that not all information is
> available when the code generation is done on every procedure in turn:
[...]

Most of these situations are reasonably uncommon. I think if it was made
optional, with perhaps warnings generated when the compiler detected
one of these conditions, it would be the best of both worlds.

Frank