[Oberon] Wojtek's comment (garbage collector question)

[skulski at pas.rochester.edu]

Jan:

> before I address some issues you raise I want to ask you a question:
> I seem to think that you very much need some kind of a real time response
> out of the software.
> Where does the Oberon garbage collection fit into your scheme of things?
> It takes quite some time you know (relatively speaking).

Good question. I vaguely remember that NW has relegated garbage collector
from his real time designs, did he not? If the code is not calling NEW
then the GC is not needed.

There were some suggestions that NEW can be used to map the structures to
the BRAM. Is this necessary, or can static allocation be used instead? It
means that the arrays to be BRAMed will be global and there needs to be
some sort of syntax to put them at a given address.

Alternatively, how about NEW that would be one-way without the GC? (I
remember seeing DISPOSE somewhere in one of the Oberons. Am I dreaming?)
Perhaps there is no need for either the GC or DISPOSE. Perhaps NEW can be
used to associate the structure with a BRAM. Imagine the syntax, where I
intentionally used ALLOCATE rather than NEW:

  arr_ptr1 := ALLOCATE (arr_type, physical_address); (*1*)

>From now on arr_ptr can be dereferenced. It points to some memory. Now you
execute it again with the same type and the same address:

  arr_ptr2 := ALLOCATE (arr_type, physical_address); (*2*)

Now both arr_ptr1 and arr_ptr2 point at the same memory. Is this a bug?
Logically yes, but nothing bad will happen. You just have two pointers
both pointing at the same thing.

Now imagine arr_ptr1 := NIL; arr_ptr2 := NIL;

Now you cannot access this memory, but there is no memory leak. Nothing
bad happens, because you can re-execute eithe (*1*) or (*2*) and reclaim
the same memory and start using it again. The GC is not needed.

The key observation is that ALLOCATE is not using the heap. It rather
overlays the high-level structure over a given address range. Since the
heap is not involved, there is no need for heap management either. Hence,
ALLOCATE does not rely on GC.

This was the reason why I wrote ALLOCATE rather than NEW. The former is
heap-less. The latter does involve the heap and thus the GC.

As a corrolary, if the program never uses NEW, then GC can be safely
disabled. So it is a way to have a cake and eat the cake: keep NEW in the
system to make it general. However, deeply embedded programs will never
use NEW and then the GC can be disabled in order to provide determinism.

Does it make sense?

Thank you,
Wojtek