GC - again, :-)

GC - again, :-)

[Jon S Anthony]

Robert Eachus sez:

>   > I strongly agree with this.  Of course (as you all know by now) I
>   > would go further and say that GC is really the only good solution
>   > here.  Even if it were only for strings.  Finalization and user
>   > defined assignment are typically going to be rather more expensive.
> 
>     The cost of finalization and user defined assignment are
> implementation concerns.  But in what sense is Ada.Strings.Unbounded
> not exactly the "Even if it were only for strings," functionality?

Oh, I meant that to apply to GC, as in the only place where GC was
actually used.  I agree that F/UDA are impl. concerns, but those are
still valid concerns.  The best that F/UDA can do here is RC and RC is
inherently more expensive than tracing style GCs.  Even if you avail
yourself things such as "non recursive freeing" and deferred counting
techniques.

>    Robert Dewar said:
> 
>    > What I think would be a nice compromise is to have a storage pool
>    > specially for unbounded strings (or similar gizmos) where you got
>    > GC in that storage pool -- something to keep looking at ...

This is definitely something to pursue.  What is more, I think you can
generalize this notion.  I'm working on this sort of thing right now.


>    This is definitely an area where the language can and should
> evolve.  Ada.Strings.Unbounded is a nice package to have, but a
> generic which exported a Garbage_Collected type would be even more
> useful in places:

Absolutely.  I am working on a whole set of these (related in
subsystem hierarchies) which will offer wide ranges of GC options.
While you can't do this completely transparently *within* the language
(i.e., without compiler support), it is surprising how close you can
in fact get.  What is more, it is very efficient and very flexible.


>    generic
>      type Data(<>) is private;
>      type Reference is access all Data;
>    package Garbage_Collected is 
> 
>      type Collected is private;
> 
>      function Create(Contents: in Data) return Collected;
> 
>      function Get_Ref(Item: in Collected) return Reference;
> 
>      function Contents(Item: in Collected) return Data;

>    If done right, Get_Ref would probably be a type conversion...

In some cases that is exactly correct.  In particular, when the
collector will work across a class of types this is the most natural
approach.  Collected needs to be limited as well (OTOH, with proper
compiler support that could be relaxed).

/Jon
-- 
Jon Anthony
Organon Motives, Inc.
Belmont, MA 02178
617.484.3383
jsa@organon.com

Re: GC - again, :-)

[Brian Rogoff]

On 29 Apr 1997, Jon S Anthony wrote:
> Robert Eachus sez:
> >    Robert Dewar said:
> > 
> >    > What I think would be a nice compromise is to have a storage pool
> >    > specially for unbounded strings (or similar gizmos) where you got
> >    > GC in that storage pool -- something to keep looking at ...
> 
> This is definitely something to pursue.  What is more, I think you can
> generalize this notion.  I'm working on this sort of thing right now.

I've been looking at something similar, since I've been writing an
interpreter for a Lisp-like language in Ada. Obviously I can write a 
GC for a set of objects as part of the interpreter proper, since I 
know the lifetimes of many objects, and all of the roots, but I'd
prefer to be able to say something like 

	type SExpr_ID is access all SExpr_Type'Class;
	for SExpr_ID'Storage_Pool use Garbage_Collected_Pool;
	...
	-- These are ugly, but might be useful
	Register_Root ( Garbage_Collected_Pool, Root_1 );
	...
        Register_Root ( Garbage_Collected_Pool, Root_n );

and thus be able to reuse the collector easily in other contexts. 
	
> >    This is definitely an area where the language can and should
> > evolve.  Ada.Strings.Unbounded is a nice package to have, but a
> > generic which exported a Garbage_Collected type would be even more
> > useful in places:
> 
> Absolutely.  I am working on a whole set of these (related in
> subsystem hierarchies) which will offer wide ranges of GC options.
> While you can't do this completely transparently *within* the language
> (i.e., without compiler support), it is surprising how close you can
> in fact get.  What is more, it is very efficient and very flexible.

Well, now I'm curious! Do you have working source code? 

-- Brian

Re: GC - again, :-)

[Jon S Anthony]

In article <Pine.SGI.3.95.970430110433.18224A-100000@shellx.best.com> Brian Rogoff <bpr@best.com> writes:

> > Absolutely.  I am working on a whole set of these (related in
> > subsystem hierarchies) which will offer wide ranges of GC options.
> > While you can't do this completely transparently *within* the language
> > (i.e., without compiler support), it is surprising how close you can
> > in fact get.  What is more, it is very efficient and very flexible.
> 
> Well, now I'm curious! Do you have working source code? 

Yes.  But as I mentioned in another thread I don't know when this
stuff will be more or less readily available.  I believe, sometime
this summer.

/Jon

-- 
Jon Anthony
Organon Motives, Inc.
Belmont, MA 02178
617.484.3383
jsa@organon.com

Re: GC - again, :-)

[Nick Roberts]

Brian Rogoff <bpr@best.com> wrote in article
<Pine.SGI.3.95.970430110433.18224A-100000@shellx.best.com>...
> [...] since I've been writing an
> interpreter for a Lisp-like language in Ada. Obviously I can write a 
> GC for a set of objects as part of the interpreter proper, since I 
> know the lifetimes of many objects, and all of the roots, but I'd
> prefer to be able to say something like 
> 
> 	type SExpr_ID is access all SExpr_Type'Class;
> 	for SExpr_ID'Storage_Pool use Garbage_Collected_Pool;
> 	...
> 	-- These are ugly, but might be useful
> 	Register_Root ( Garbage_Collected_Pool, Root_1 );
> 	...
>         Register_Root ( Garbage_Collected_Pool, Root_n );
> 
> and thus be able to reuse the collector easily in other contexts. 


It seems to me that a representation clause would be the much the best way
to specify what sort of storage reclamation strategy is applied to a
storage pool. I would (quite strongly) suggest that full reclamation ought
to be the default, with agreed-upon clauses for selecting other strategies.
There would surely be an option No_Reclamation to switch garbage collection
off completely, for those occasions when it was required.

I would greatly appreciate opinions on this.

Nick.

Re: GC - again, :-)

[Jon S Anthony]

In article <01bc5742$bf3c7640$d5fd82c1@xhv46.dial.pipex.com> "Nick Roberts" <Nick.Roberts@dial.pipex.com> writes:

> It seems to me that a representation clause would be the much the best way
> to specify what sort of storage reclamation strategy is applied to a
> storage pool. I would (quite strongly) suggest that full reclamation ought

I disagree.  I think the best way to approach this is via a subsystem
of generic packages which present a set of techniques and
implementation strategies.  Any storage pools used in the
implementation would not even be visible to clients.

/Jon

-- 
Jon Anthony
Organon Motives, Inc.
Belmont, MA 02178
617.484.3383
jsa@organon.com

Re: GC - again, :-)

[Robert Dewar]

Nick Roberts said

<<It seems to me that a representation clause would be the much the best way
to specify what sort of storage reclamation strategy is applied to a
storage pool. I would (quite strongly) suggest that full reclamation ought
to be the default, with agreed-upon clauses for selecting other strategies.
There would surely be an option No_Reclamation to switch garbage collection
off completely, for those occasions when it was required.

I would greatly appreciate opinions on this.>>

If you were designing the language out of the blue with no history, this is
a reasonable position (it is the position adopted by Algol-68, Modula-3,
and Java, to name languages that are of a comparable semantic level to Ada).

However, at this stage, no implementor is likely to make a change like
this, since it would disrupt the existing user base too severely. I would
crtainly think that a configuration pragma that specified the default
pool for all access types as being the GC one would be quite appropriate.

Note in all this discussion the need for another important pragma which
is something like

   pragma Storage_Finalization (type-name)

This says to the compiler for a controlled type that the finalizatoin routine
is there only for storage reclamation (the normal case) and that thus calls to
it can be eliminated in a GC environment.

Actually this pragma is useful in a non-GC environment for inhibiting
silly finalization overhead and calls on objects that are allocated on
the outer level heap. Unlike C++, Ada takes finalization seriously, so
it ensures that finalizatoin must occur for all objects. In C++, destructors
are not called for outer level heap objects at the termination of the 
program. In Ada they are. The Ada approach is much cleaner,. and the C++
feature has surprised more than one programmer, but in 99% of real cases,
the C++ approach is what you want, since the destructor is there only to
free storae, and it is silly to waste time freeing storage just before
you free the entire heap!