How-to on using the adacl-gc packages

How-to on using the adacl-gc packages

[Erik J Pessers]

Dear all,

I tried to play around with the  Martin Krischik garbage
collection routines in the AdaCL packages, but the doc
supplied with the package is very terse indeed (at least
for some-one with my limited background in garbage
collection and pool management matters).

Any-one around that would be willing to share some
actual snippets of code using the AdaCL.GC.Managed
and AdaCL.GC.Managed_Controlled  packages, that could
be a clue for me on how things fit in?

Also: any general feelings on whether including
garbage collection is something to really worry
about in practice?

TIA

Re: How-to on using the adacl-gc packages

[Steve Whalen]

As for rationales against garbage collection in Ada, you'll probably
hear more along these lines:

Ada is a language intended to be used to engineer high quality, high
reliability software. Garbage Collection generally is a tool to that is
used to cover up a failure to know and control your program. An
application should be written in such a way that there are no memory
leaks or memory kept allocated after you've finished using it.

Developing very high quality software requires active engineering on
the part of the programmer / designer, not a adding a tool that tries
to clean up the mess after you've created it.  In Ada, you're not
supposed to create a "mess" (though it's perfectly possible to make a
mess of a program in Ada just as in any programming language).

While I don't completely subscribe to this line of thinking, I do think
that before including garbage collection in an Ada program, you should
carefully review _why_ you want to use it (instead of maintaining
positive memory control throughout the application) and you should be
very sure you can live with the impact of garbage collection on the
timing and other performance requirements of the program.

Steve

Erik J Pessers wrote:
>
...
>
> Also: any general feelings on whether including
> garbage collection is something to really worry
> about in practice?
> ...

Re: How-to on using the adacl-gc packages

[Martin Krischik]

Steve Whalen wrote:

> Ada is a language intended to be used to engineer high quality, high
> reliability software. Garbage Collection generally is a tool to that is
> used to cover up a failure to know and control your program. An
> application should be written in such a way that there are no memory
> leaks or memory kept allocated after you've finished using it.

I know at least one memory allocation problem where I have not yet
found a solution for - no matter how much engineering I have put into
the problem:

task type T;
type T_Access is access T;

...

X : T_Access := new T;

The last I read only recently here was: task types are small - don't
bother deallocating them. Anybody got any better advice?

Martin

Re: How-to on using the adacl-gc packages

[Martin Krischik]

Erik J Pessers wrote:
> Dear all,
>
> I tried to play around with the  Martin Krischik garbage
> collection routines in the AdaCL packages, but the doc
> supplied with the package is very terse indeed (at least
> for some-one with my limited background in garbage
> collection and pool management matters).
>
> Any-one around that would be willing to share some
> actual snippets of code using the AdaCL.GC.Managed
> and AdaCL.GC.Managed_Controlled  packages, that could
> be a clue for me on how things fit in?

Well there are examples in AdaCL itself: just look for 'Storage_Pool.
There indeed not much which you need to do apart from choosing the
right storrage pool.

Inside the Subversion archive, in branch Ada_2005 you also find some
new stress tests for the collector. Start at

http://svn.sourceforge.net/viewcvs.cgi/adacl/branches/Ada_2005/adacl/Source/testgc.ads?view=markup

> Also: any general feelings on whether including
> garbage collection is something to really worry
> about in practice?

Honest answer:

since I found out about the power 'Class and generic type T (<>) is
private I don't think it is worth that much.

Also: the stress tests reveiled a weeknees inside the collector
library: Sometimes GNAT internaly caches pointers to objects. The
collector correctly find the reference and won't release the object.

Read: http://en.wikipedia.org/wiki/Weak_reference

Especialy controled objects are hit.

Martin

Re: How-to on using the adacl-gc packages

[Simon Wright]

"Martin Krischik" <krischik@users.sourceforge.net> writes:

> I know at least one memory allocation problem where I have not yet
> found a solution for - no matter how much engineering I have put into
> the problem:
>
> task type T;
> type T_Access is access T;
>
> ...
>
> X : T_Access := new T;

What I do in ColdFrame is (with a bit of concatenation and elision)

   type Instance (<>)
   is new ---- with private;
   type Handle is access all Instance;

private

   task type T (This : access Instance) is
      -----
      entry -----;
   end T;
   type T_P is access T;
   procedure Free is new Ada.Unchecked_Deallocation (T, T_P);

   type Instance is new ----- with record
      The_T : T_P;
      -----
   end record;

   procedure Free is new Ada.Unchecked_Deallocation (Instance, Handle);

   procedure Delete (This : in out Handle) is
      -----
   begin
      -----
      abort This.The_T.all;
      Free (This.The_T);
      -----
      Free (This);
   end Delete;

which has caused us no problems (GNAT, NT, Linux, MacOS, VxWorks)[1];
but I'm always prepared to be told I'm wrong.

A while back AdaCore pointed me towards LRM 13.11.2(9):

   Free(X), when X is not equal to null [...] deallocates the storage
   occupied by the object designated by X. [...] There is one
   exception: if the object being freed contains tasks, the object
   might not be deallocated.

It's not clear to me quite what 'contains tasks' means. From a
position of ignorance, I could argue that The_T.all doesn't _contain_
a task, it _is_ a task.

> The last I read only recently here was: task types are small - don't
> bother deallocating them. Anybody got any better advice?

It all depends how often you do it and what your platform's memory
availability is! On VxWorks (5.4, PowerPC) you are stuck with the
physical memory ...


[1] except when people called Delete from the task that was to be
deleted. I catch this now.

Re: How-to on using the adacl-gc packages

[Steve Whalen]

Martin Krischik wrote:
> I know at least one memory allocation problem where I have not yet
> found a solution for - no matter how much engineering I have put into
> the problem:
>
> task type T;
> type T_Access is access T;
>
> ...
>
> X : T_Access := new T;
>
> The last I read only recently here was: task types are small - don't
> bother deallocating them. Anybody got any better advice?

Why this is a problem? I think you should control task memory just like
any other. I disagree with those who said it's small so don't bother
deallocating them.

You can create and use Unchecked_Deallocation on X which works fine, as
long as the task is terminated. If the task is not terminated then the
deallocation will fail (silently I believe). If you have a situation
where you're not certain that a task is really "completely" terminated
(completed finalization, etc.), you should check X'Terminated first and
do the deallocation only after X'Terminated returns true.

I don't have code readily available, but one approach I remember that
worked well went something like I describe below. If your application
is doing a lot of tasking, using a more complex approach like this is
worth the effort. An approach like this can also have many benefits
besides memory control (like saving on task creation overhead). The
approach went something like this:

1) Create an array or linked list in which all task access variables
are maintained.

2) Keep additional information about the task access variables in the
list, like a task status, etc....

3) Keep appropriate counters about the tasks like "total number of
tasks", "number of task variables free for reuse" and "number of
terminating tasks", etc.

4) Periodically scan the list if the "number of terminating tasks"
counter is > 0, and confirm task'Terminated for any that were
terminating. Then based on your counters and the needs of the
application, either free the memory from the access variable and task
using unchecked deallocation, or mark it free and/or add it to a "free
list" (keeping a separate free list obviously being a design decision
based on if the task list can get very long, etc.).

5) When starting up a new task, re-use one of the existing task
variables if one is available to save on overhead and minimize growth
of memory.

This can get fairly involved, but approaches like this allow pretty
thorough control over task memory.

Or did I completely misunderstand the problem you were referring to?

Steve