[Oberon] Oberon for a C++ user.

Andreas Pirklbauer andreas_pirklbauer at yahoo.com
Wed Oct 5 21:28:06 CEST 2016


All,
To see what the additional complexity of implementing the “safe module unloading” (as discussed in this thread) would be, I have implemented it.
Answer: About 10 lines of code (1 in ORG + 9 in Kernel) plus 10 lines in the tools module System.
It has been added to Experimental Oberon https://github.com/andreaspirklbauer/Oberon-experimental <https://github.com/andreaspirklbauer/Oberon-experimental> :
  - Kernel.Scan0 and Kernel.Scan (10 lines added at the end of procedure Scan0)
  - ORP.BuildTD (1 line added) and ORP.FindFlds (1 line changed, renamed from ORP.FindPtrFlds)
  - System.SecureFree (new command added)
So it is really quite straightforward. The additional complexity remains within tolerable bounds.
It can of course be debated whether it makes sense to provide such an additional protection layer in the base system or whether "module life cycle management” should be handled at a higher level.
I would tend to argue for the latter. However, in the absence of an “application management” layer (and/or app store) in Oberon, it is nice to have the "secure version" of module unloading around as a separate command System.SecureFree (I kept it separate from the System.Free command for now, so that if users who want to *force* the unloading of a module, they can just continue to use System.Free).
For now it’s just a quick experiment - so I’d be interested in hearing about suggestions, potential improvements, etc. The documentation of Experimental Oberon (see the pdf file on its GitHub page) explains what I have done. But in a nutshell: I extended the information in the type descriptor with additional entries containing offsets to *procedure variables* of a record type, and combined the unloading with the scan phase of the garbage collector (so unloading a module automatically also collects garbage from the heap). Other ways to achieve the same goal are of course possible. For example, one might integrate it into (a modified version of) the routine for the *mark* phase instead, without actually collecting garbage in the process (which was the approach chosen in the Ceres version). It’s nice to play around with various approaches..
Andreas

- - -

(*) For the details see https://github.com/andreaspirklbauer/Oberon-experimental <https://github.com/andreaspirklbauer/Oberon-experimental>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.inf.ethz.ch/pipermail/oberon/attachments/20161005/c8d89f65/attachment.html>


More information about the Oberon mailing list