[Oberon] DISPOSE
Gérard Meunier
gmeunier at club-internet.fr
Tue Sep 3 00:17:33 CEST 2002
> Gérard_Meunier <gmeunier at club-internet.fr> wrote:
> > Garbage collection is a blessing for most programmers, and makes system
and
> > applications more robust. But sometimes it's a bane. I've written, in
> > Bluebottle, an interpreter for a language whose one of most important
> > features is that it produces no garbage. It allocates a lot of stuff in
the
> > heap, but it knows exactly the lifetime of each chunk of memory.
Therefore
> > it would be very interesting and efficient to dispose memory by hand. Is
> > there any way to do that?
>
> Not currently, but it would not be too difficult to add a Dispose
procedure
> in AosHeap if someone would like to try. Basically the block to be
disposed
> has to be added to the correct free list (global variable "freeList").
>
> I'm not sure if this should be done, since disposing manually is
error-prone
> and dangling pointers are horrible to debug.
Yes, of course. I'm sure that using a collector is much more secure. But I'm
sure too, that in some unusual cases, a DISPOSE should be used, with great
care. Such a procedure could be part of the SYSTEM module. It's well
accepted that modules importing SYSTEM are not safe, so...
> Do you currently have an efficiency problem with the garbage collector?
Yes.
> By setting the "TraceHeap" config string you can see trace info about
> heap procedures in the kernel log, including the times of various phases
> of the collection. See the end of AosHeap.Mod for flag values for
> "TraceHeap". For accurate timings, set the config string "MHz" to
> the speed of your processor (e.g. "MHz=400").
I don't understand all the outputs, but I can see clearly (with TraceHeap=
DR+DA+DS+DP= 824) the moments where the collector is called and the
approximate duration of the calls (the system, including the mouse pointer,
is freezed during calls). My program allocates a great amount of records on
the stack and frees a large part of them, so that the number of non-free
records increases slowly. Little by little, the garbage collector is called
more and more often and the duration of these calls are longer and longer.
When the amount of non-free memory reaches about 100Mb (out of a total of
256Mb available), the system is quite freezed. A manual DISPOSE would not
behave this way (and, in my case, its use would be perfectly safe). The
problem with the garbage collector is that its duration (for the first phase
at least) is proportionnal to the number of non-free blocks.
> The current collector still includes some debug code by default, viz.
> clearing all deallocated storage to the constant "0DEADDEADH". This
> can be quite an overhead. To disable, set DebugValue = 0 in AosHeap,
> recompile, relink the kernel and reinstall it on the boot device
> (see Aos.Tool).
I didn't try, but I don't think it would change the problem.
Regards.
Gérard
More information about the Oberon
mailing list