[Oberon] SystemV- Heap + Module Space

Jörg joerg.straube at iaeth.ch
Tue Jan 1 18:57:51 CET 2019


Tomas

Generally, System.Free is not safe. Here some examples where Free might freeze the system:
- if you installed a background task in the Oberon loop and unload the handler module without having deinstalled the task handler first.
- If you use call back procedures in you modules, and unload only half of your modules.

As the added code decreases AllocPtr, the probablitity that subsequent module loads overwrite still referenced code increases.
I assume the freeze is not caused by the added lines per se, but rather that you freed some modules that should not be freed.

br
Jörg

Am 01.01.19, 16:06 schrieb "Oberon im Auftrag von Tomas Kral" <oberon-bounces at lists.inf.ethz.ch im Auftrag von thomas.kral at email.cz>:

    > It depends on what heuristics you want to use to find the gap.
    
    Hi,
    Thank you. I am testing a new core with these changes in `Modules.Mod'
    
    [1]
    PROCEDURE Load*
    ...
    IF res = 0 THEN (*search for a hole in the list allocate and link - BOTTOM -> TOP*)
      INC(size, DescSize); (*mod*) m := root; mod := NIL;
      (*WHILE (mod # NIL) & ~((mod.name[0] = 0X) & (mod.size >= size)) DO mod := mod.next END ;*)
      WHILE m # NIL DO IF (m.name[0] = 0X) & (m.size >= size) THEN mod := m
      END ; m := m.next END ;
    
    The above works as expected, modules are filled in holes bottom up fashion which I believe conserves module store better then then top bottom approach.
    
    Is there a system pointer marking modules' origin?
    mod := org; WHILE (mod # root) DO mod := mod.next END ;
    
    [2]
    PROCEDURE Free*
    ...
     IF mod = root THEN (*increase size of available module space*)
      p := mod.size; mod := mod.next;
      WHILE (mod # NIL) & (mod.name[0] = 0X) DO INC(p, mod.size); mod :=
      mod.next END ; AllocPtr := AllocPtr - p; root := mod
     END
    ELSE res := 1
    ...
    The above has sometimes problems, cannot figure out why yet.  I tried commenting  (*mod # NIL) &*). It sometimes locks the system.
    
    -- 
    Tomas Kral <thomas.kral at email.cz>
    --
    Oberon at lists.inf.ethz.ch mailing list for ETH Oberon and related systems
    https://lists.inf.ethz.ch/mailman/listinfo/oberon
    




More information about the Oberon mailing list