Re: Ada GC (was Ammo-zilla)

[Nick Roberts <nickroberts@callnetuk.com>]

Vladimir Olensky wrote:
> ...
> This restriction could be done using  language support for GC.
> Let's suppose that we have additional keyword TRACED
> that applied to the ACCESS TYPES controlled by GC.
> (This TRACED ACCESS TYPE could be bound
> to particular GC using standard Ada construct:
> for T'Storage_Pool use Ada.GC.GC_Name_Storage_Pool).
> 
> When access type is declared to be traced compiler should
> not allow any unchecked conversions with that type in standard
> mode.
> In may allowed only using  additional pragmas.

Rather than introducing a new reserved word into the Ada syntax, I think
all that would be necessary would be for a new standard (abstract) pool
type to be defined, derived from Root_Storage_Pool, called
Root_Managed_Pool, say. Managed (garbage collecting) pools would all be
derived from this type. I think Root_Managed_Pool would have at least
one extra primitive operation, to induce a garbage collection and/or
object compaction cycle.

In order to cause objects referenced by a certain access type to be
allocated into a managed pool, one would simply declare a Storage_Pool
representation clause for the access type, naming an object of the
appropriate managed pool type. Notice how this leaves implementations
free to choose to provide garbage collection by default or not (or to
select this by pragma, compiler switch, or other option).

It would then be the responsibility of the compiler to ensure that all
objects of this access type were 'traced', as Vladimir puts it. This
means, in practice, that: a type descriptor for the access type must be
entered into a 'type descriptor table'; every single object of the
access type must be entered into a 'frame object table'; every instance
of a value of the access type being loaded into or saved out of a
register must be entered into a 'register loading table'; every compound
type which can contain one or more values of a traced type is also
traced (and so on recursively). The three tables would form part of the
static data of the program, and would enable managed pools to determine
the size and alignment of every object they contain, and to move those
objects about in memory, correcting variables and registers as
necessary. In addition, the compiler must provide facilities (to the
pool managers) for identifying and freezing those tasks using a managed
pool, for reading from and writing to the stack frames and register sets
of those tasks, etc. (Or, to put it in simpler terms, no-one should be
in doubt as to the complexity of adding GC, nor, for that matter, to the
possibility of doing so.)

It may well behove a compiler to issue a serious warning for any use of
unchecked conversion, deallocation, or access for any traced type. But
ultimately, as ever, if the user (Ada programmer) screws up, after
having been so warned, he or she only has himself or herself to blame.

It would undoubtedly be very useful (and not overly difficult, I think)
for the implementor of a managed pool to provide an alternative
implementation or mode which (sacrificing some efficiency perhaps)
provided various (extra) profiling and debugging facilities relating to
the use of the pool.

It would be particularly incumbent upon the implementors of managed
pools to make special efforts to ensure the correctness of their
implementations, since the results of a garbage collector going wrong
are always likely to be particularly unfortunate.

-- 
Nick Roberts
Computer Consultant (UK)
http://www.callnetuk.com/home/nickroberts
http://www.adapower.com/lab/adaos