[Oberon] Oberon for a C++ user.

[Skulski, Wojciech]

Chris:

  now I feel lost. The whole point of unloading is to get rid of the old code. Conceptually speaking unloading should work something like this:

1. Find all the references to the old (still loaded) code.
2. Get rid of the references.
3. Remove the code from the memory.

Now you are ready to load the fresh code. At any given time there is only one copy of the code loaded to RAM. Since all is being done by the GC, and the machine is a single threaded machine with no preemption, it is not possible to interrupt the process.

The above is a non-expert view of how this could (should?) work. With my non expert eyes I do not see any potential for different versions of code for the same procedure . 

What am I missing?

Cheers,
W.

________________________________________
From: Oberon [oberon-bounces at lists.inf.ethz.ch] on behalf of chris [chris at gcjd.org]
Sent: Thursday, October 6, 2016 11:45 AM
To: ETH Oberon and related systems
Subject: Re: [Oberon] Oberon for a C++ user.

On Wed, 5 Oct 2016 13:23:52 +0000, Skulski, Wojciech wrote:
> I also seem to remember that the procedure code is in the 2nd heap
> which is typically much smaller than the heap devoted to records.
> Traversing the procedure heap should be lightning fast even if the
> machine has a gigabyte on board. You do not need to scan the entire
> gigabyte, but rather the code hep only. Correct me if I am mistaken.

Yes, but that was not my point. I don't expect any performance
problems. What I don' like about this is, what I would consider an
inconsistent state of the system.

There can be different versions of code for the same procedure  around
at the same time after an unload / reload cycle of a module.

I am not sure if this situation is a better solution than writing NIL
to all references to unloaded procedures so that calling an unloaded
procedure's code would trap instead of running outdated code which does
not reflect the actal code of the module as loaded.

Greetings, chris