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

[Chris Burrows]

> -----Original Message-----
> From: skulski at pas.rochester.edu [mailto:skulski at pas.rochester.edu]
> Sent: Friday, 28 August 2015 11:18 AM
> To: ETH Oberon and related systems
> Subject: Re: [Oberon] Wojtek's comment (garbage collector question)
> 
> 
> > 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.
> 

Project Oberon does have a garbage collector and it also handles the problem
of preventing the GC from interfering with manually allocated pointers (as
opposed to those automatically allocated by NEW). This is alluded to in the
following quote from the documentation: 

"However, there exists a pitfall that is easily overlooked: All opened files
would permanently remain accessible via root, and the garbage collector
could (i.e should) never remove a file descriptor nor its associated
buffers. This would be unacceptable. In order to hide this list from the
garbage collector, it is represented by integers (addresses) instead of
pointers."

Instead of randomly speculating, read Chapter 6 "The module loader", Chapter
7 "The file system" and Chapter 8 "Storage layout and management" and study
the associated source code. If particular look out for the way that
SYSTEM.VAL is used for pointer assignment, mapping disk sectors to file
structures etc.

Regards,
Chris

Chris Burrows
CFB Software
http://www.astrobe.com