Re: Ada 0Y plans for garbage collection?

[Dmitry A. Kazakov <mailbox@dmitry-kazakov.de>]

On Fri, 12 Sep 2003 17:20:27 GMT, "Robert I. Eachus"
<rieachus@attbi.com> wrote:

>Dmitry A. Kazakov wrote:
>
>> But reference counting could be made much more easy and attractive if
>> smart pointers have more light-weighted implementation than controlled
>> types in generic packages. There are too many problems with that...
>
>Agreed, which is why you want to use a reference counted storage pool. 
>That way the count is stored with the object, and you only incur the 
>overhead when you create a new counted access value.

Sounds great, really!

It also solves nasty problems when a GC object is allocated on the
stack, or with [unsupported] MI (:-)), because the reference count is
no more a part of the object.

But I suppose that this would require massive compiler support. If so,
then why not to make access types to counted storage pool more
transparent. At least when:

1. passing to a subprogram expecting the designated object.

2. dispatching. Named access types do not dispatch and define no
primitive operations.

I mean, to finally kick GC off, access types to reference counted
objects should fully mimic the designated types. I.e. ".all" dropped,
"null" is not a valid value etc. AFAIK access types with no "null" are
planned (?), so dropping ".all" would be a logical consequence.
Assignment should then just copy the reference. BUT, what about
cloning [non-limited] objects when they are modified through a counted
access, while the reference count is greater than 1? This is not so
easy.

>I've done this to create a pool of fixed sized objects.  I keep 
>intending to rewrite it to support variable sized objects, but it is 
>always easier to create a fixed-sized reference-counted object with an 
>access value into the normal heap, and do explicit deallocation of that 
>object when the reference count reaches zero.
>
>Anyone want to work with me on a "standard" reference counted storage 
>pool for Ada 200Y?  The storage pool will only be a couple of pages of 
>code.  The real effort is in documenting it and providing examples of use.

If I can help...

>Or did you mean that the fact that the storage pool was a controlled 
>type was a problem?

No. The problem was that the reference type has to be controlled.

> I don't see that.  Typically a program will create 
>a storage pool once and then just use it.  The controlled overhead 
>really only comes into play if the storage pool is located inside a 
>nested procedure.

---
Regards,
Dmitry Kazakov
www.dmitry-kazakov.de