<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">Just a final remark that “completely safe module unloading" is now fully implemented in Experimental Oberon.<div class=""><br class=""></div><div class="">- System.Free M … does not unload a module if references to M exist (pointer refs, procedure refs, type refs)</div><div class="">- System.Free M/f … forces module unload in spite of references, but in such a way as to never crash the system</div><div class=""><br class=""></div><div class="">The experiment showed that it can be done with less than 50 lines of code (without the /f option) and less than 100 lines (with the /f option), but I would not recommend implementing the /f option (persisting type descriptors used by other modules is a bit cumbersome indeed).</div><div class=""><br class=""></div><div class="">Andreas<br class=""><div class=""><br class=""></div><div class=""><div class=""><div class=""><pre style="background-color: rgb(255, 255, 255);" class=""><span style="white-space: pre-wrap;" class="">————————————————————————————</span></pre><pre style="background-color: rgb(255, 255, 255);" class=""><span style="white-space: pre-wrap;" class="">Wojtek,
The “safe module unloading” solution is now almost fully implemented in the (inner) core of Experimental Oberon. After unloading, references to the unloaded module are set to NIL (global pointer references are set to NIL explicitly in procedure Modules.Free, references from dynamic heap objects are collected by the garbage collector which is invoked when a module is unloaded, see Modules.Free and System.Free).
This means that the system will no longer crash when a module is (force-)unloaded and another module tries to execute a procedure variable that previously pointed to the now unloaded module. Now, it will merely produce a TRAP 5 message (“illegal procedure call”) in the system log viewer.
The only remaining problem is the case where a structure rooted in a variable of base type T declared in a module M contains elements of an extension T' defined in module M'. In Oberon 2013, the system can crash after module M' is unloaded (namely when the space previously occupied by module M' - containing its type descriptors - is overwritten by another module N that is small enough to fill the hole left behind after the unloading of M’). In Ceres-Oberon this problem was circumvented by persisting type descriptors in main memory which was achieved by allocating them in the heap rather than placing them as constants (which is what they are) in the module block space. In Experimental Oberon, module M’ normally simply cannot be unloaded, eliminating the problem altogether. But it becomes a problem if a user forces the unloading of module M' via the /f option. This can be addressed in various ways, I just haven’t done it yet.
Total implementation cost (inner core and compiler):
- Kernel: + 18 lines
- Modules: + 25 lines
- ORG: + 7 lines (needed to produce an extended object file format)
Total: 50 lines
Andreas
——————————————————————
Skulski, Wojciech skulski at <a href="http://pas.rochester.edu" class="">pas.rochester.edu</a> <mailto:oberon%<a href="http://40lists.inf.ethz.ch" class="">40lists.inf.ethz.ch</a>?Subject=Re:%20Re%3A%20%5BOberon%5D%20Safe%20module%20unloading%20%28was%3A%20Re%3A%20Oberon%20for%20a%20C%2B%2B%20user.%29&In-Reply-To=%3CCY1PR07MB22136B7AE4F42CE9F473B5C6FFDA0%<a href="http://40CY1PR07MB2213.namprd07.prod.outlook.com" class="">40CY1PR07MB2213.namprd07.prod.outlook.com</a>%3E>
Tue Oct 11 15:47:58 CEST 2016
Andreas:
it looks like a great development to me. Given the simplicity of your solutions, I wonder if they should not just become a standard part of the "official" 2013 Oberon System. Should they not get backpropagated to Professor NW, with a note that it shows the strength and vitality of the Oberon community which he started?
Wojtek
________________________________________
From: Oberon [oberon-bounces at <a href="http://lists.inf.ethz.ch" class="">lists.inf.ethz.ch</a> <<a href="https://lists.inf.ethz.ch/mailman/listinfo/oberon" class="">https://lists.inf.ethz.ch/mailman/listinfo/oberon</a>>] on behalf of Andreas Pirklbauer [andreas_pirklbauer at <a href="http://yahoo.com" class="">yahoo.com</a> <<a href="https://lists.inf.ethz.ch/mailman/listinfo/oberon" class="">https://lists.inf.ethz.ch/mailman/listinfo/oberon</a>>]
Sent: Monday, October 10, 2016 1:21 PM
To: Oberon List
Subject: [Oberon] Safe module unloading (was: Re: Oberon for a C++ user.)
1. I have uploaded a new version of System.SecureFree that now performs *all* checks (including the check whether there are any global procedure variables in other modules that reference procedures of the module to be unloaded).
2. Writing NIL to all references (and type tags!) when unloading is forced via a /f option is in fact included, but only in the version that is integrated with the garbage collector. The reason is that if it were done outside the existing garbage collector (as is the case in the proof-of-concept version that is currently published), it would immediately break the garbage collector (because it references tags without checking whether they are NIL - see procedure Kernel.Scan for example). If I decide to include “safe module unloading” in the Oberon core, there would also be a /f option and, if selected, all references and tags to unloaded modules would be set to NIL. That’s the holy grail. It is fully implemented. Meanwhile, you can just use System.Free (which does not perform the checks).
Andreas
———————————————————————
On Mon, 10 Oct 2016 12:51:39 +CEAR, Chris wrote:
><i class=""> On Sat, 8 Oct 2016 19:28:55 +0200, Andreas Pirklbauer wrote:
</i>
><i class=""> > I’d welcome more input on this topic.. all I wanted to show is that
</i>><i class=""> > it is *doable* (proof of concept) and that the effort is very small.
</i>><i class=""> >
</i>><i class=""> >Whether it *should* be done is another question. It remains open.
</i>
><i class=""> Thanks for this great write-up. I think the effort is so small that it
</i>><i class=""> should be included in the system. This would close the biggest hole in
</i>><i class=""> the Oberon system.
</i>
><i class=""> I would prefer to improve the forced unload function by writing NIL to
</i>><i class=""> all references that would close the last hole (I hope) in the system
</i>><i class=""> for the occurrence of dangling pointers.
</i>
><i class=""> Greetings, chris</i></span></pre><div class=""><br class=""></div></div></div></div></div></body></html>