[Oberon] Oberon for a C++ user.

[chris]

On Tue, 4 Oct 2016 19:36:05 -0400, Peter Fröhlich wrote:
> With a POINTER to a RECORD, I can find another type descriptor at the
> "destination" and that's how the garbage collector's mark phase
> proceeds through the heap. From what I can tell, adding a "procedure
> descriptor" and a "module descriptor" of some sort would allow
> extending the garbage collection approach to those constructs as well
> (with detailed semantics obviously needing to be settled).

I think it is no big problem to extend the garbage collector. 

> I consider something else "problematic" namely that you'd have to know
> if a procedure is currently running; then it should obviously not be
> "garbage collected" from under the CPU, regardless whether the last
> "pointer" to it has been reassigned. But *if* the current Oberon still
> follows the old approach of running the GC only *between* commands and
> not at any other time, and *if* the current Oberon is still
> single-threaded, then that "problem" actually disappears.

No real problem either. If you do garbage collection while commands are 
running you have to do a conservative scan of the stack anyway. There 
you will find a pointer into the procedure's code as a return address. 
Just treat them like all the other (heap) pointers.

> (Sorry, it has been too long since I seriously looked at Oberon System
> variants. I demoed one for my students last year as part of the OS
> course, but I didn't actually study it in any detail. It certainly
> *looked* like from 1985, so maybe my knowledge of the system *is*
> still applicable?)

More or less. Several Oberon systems used different approaches, but 
Oberon 2013 is close to the original. 

I see one problem with the pure garbage collection strategy.
If there are still references to procedures and after unloading and 
reloading a module like in a typical development cycle there are two 
(or more) versions of the same procedure in the system. That can lead 
to some confusion for example for a symbolic debugger or any other 
reflection service.

Therefore I am not totally convinced that writing NIL to proc 
references is such a bad idea if it is done when the user explicitly 
requested to unload a module. That I would not consider magic behind 
the back.

Greetings,  Chris

P.S. Nice to hear from you again, did not see you here since the 
Lagoona days if you still remember ;-)