Re: Ada and GC. Was: Re: Ammo-zilla

["Vladimir Olensky" <vladimir_olensky@yahoo.com>]

Tucker Taft wrote in message <381DD258.B6B11153@averstar.com>...
>Vladimir Olensky wrote:
>> ...
>> 1. In a system that gives you a choice to use TRACED or UNTRACED
>> by GC objects just do not use TRACED objects if you don't want
>> them to be moved by GC from one memory location to another.
>
>By the way, don't you generally need to do reference
>counting rather than tracing-based GC if you have some
>traced and some untraced objects?  If not, how do you deal with
>pointers to traced objects that exist in untraced objects?
>(Perhaps disallow at compile-time?)


To be clearer I just used Modula-3 terminology that uses UNTRACED
 keyword to denote  REF TYPES that are pointers that are not
controlled by the GC. So in this context TRACED word denotes
 pointers that are controlled by GC and nothing more (it does not
imply any GC mechanism).

So I was saying that if one uses TRACED REF TYPE (default in M3)
or in Ada "TRACED" ACCESS TYPE that means that this access
type and operations with it are provided by the particular
GC_storage_manager and that  "TRACED" ACCESS TYPE is under
full control of that GC manager. This GC_Pointer is of
Ada.Finalization.Controlled type.

GC manager provides Initialize, Adjust and Finalize operations for
the "TRACED" ACCESS TYPE that it exports. Another operation
is Create (GC_Ptr, Object_Type)  that returns instance of that
"TRACED" ACCESS TYPE which essentially is reference to the entry
in GC Address Descriptor Table for the created object. That table entry
may contain other information needed to implement particular GC
management mechanism (it may be Reference_Count field for reference
counting mechanism or may be something else).
How pool management is implemented is  private matter
of that GC storage manager.

So idea is that externally GC provides control over
"TRACED" ACCESS TYPES via Initialize, Adjust
and Finalize operations and internally over allocated
objects referenced by  "TRACED" ACCESS TYPES
as well as dereferencing operations.

Taking all that into consideration it does not matter where
such "TRACED" ACCESS TYPE object (GC_Pointer) is located.
Nulling-out such pointer or freeing any dynamically allocated object
(which may be allocated by another GC manager) where such
GC_Pointer is located will automatically reclaim storage when
GC manager will see that there is no more references
to the allocated object.

As I mentioned in my other post when using such kind of storage
pool controlled by GC via it's Address Descriptor Table actual storage
pool may even be located on one or several remote machines that may
act as Objects Storage Servers for many other machines.
In this case local GC storage manager is a client of the remote
GC_Storage_Server and we will have some kind of
NETWORK_WIDE_VIRTUAL_GARBAGE_COLLECTED_MEMORY.

May be I am wrong somewhere. I am not a big expert in GCs.
I just let my imagination go where it wants to go.

Regards,
Vladimir Olensky