[Oberon] Oberon for a C++ user.

[Srinivas Nayak]

> Peter: procedure variables are "pointers" as well, just to a piece of code instead of a RECORD.

This is very much true from GC's point of view...
Thanks for proposing GC as an alternative solution.

The idea behind using GC is that,
GC can keep the unloaded module in memory till referrers vanish.

However, while using GC, we don't *explicitly* delete the object.
We just pretend that old object doesn't exist.
We reuse the pointer with a new object.
That means both objects exist in memory, till GC comes.
But we unload modules *explicitly*.

And often we load a new *updated* module with same name.
In such cases, can both old module and new module co-exist in memory, till GC comes to play?

The biggest problem is, object identity is just an address,
But module identity is its name.

> Wojtek: You can also look at it from the point of view of the client/ server. At the point of assignment procvar := Mod.Proc, the client gets the asset and the server Mod makes the promise. When the server is unloaded, it breaks the promise without telling the client "I am gone, do not rely on my assets". The client thinks it still has a good asset, tries to use it, and it gets duped. The client is perfectly innocent. It was the server who broke the contract.

Say, we unloaded the old server module and loaded a new
updated server module (interface remaining intact),
does procvar := Mod.Proc points to new updated server Proc?

If answer is Yes, that means old module and new module doesn't co-exist in memory.
Don't know if GC can help in such cases.
Then, I think, as long as interface remains same, no problem.
When interface differs, client or base or imported module
has to be compiled and reloaded. So no problem.

If the answer is No, that means module when loaded,
have to always assign procvar := Mod.Proc automatically,
may be inside module BEGIN...END.
[Do we generally make procvar := Mod.Proc inside module BEGIN...END?]

True that server broke the promise.
So, I think, he should make procvar := NIL;
Where and when is the problem...

If procvar := Mod.Proc is done automatically while module loading,
(through code sitting inside module BEGIN...END)
we should have an automatic means of making it NIL while unloading.
But...we don't have a place like BEGIN...END to execute when module gets unloaded!

Can we have something like this...
A  procedure UnloadMe() which a module will implement.
And when the module is unloaded, UnloadMe() will be called.

Hope that could be simpler to implement.
No language change!
Only implementation correction.



With thanks and best regards,

Yours sincerely,
Srinivas Nayak

Home: http://www.mathmeth.com/sn/
Blog: http://srinivas-nayak.blogspot.in/

On 10/05/2016 05:06 AM, Peter Fröhlich wrote:
> Hi Andreas,
>
> On Mon, Oct 3, 2016 at 12:38 PM, Andreas Pirklbauer
> <andreas_pirklbauer at yahoo.com> wrote:
>> The main question is of course how does one find out whether a particular
>> record found on the heap does indeed contain a procedure variable or not -
>> given that the structure of the Oberon-1 type descriptor only contains
>> offsets (but no "method table” as is typically used in implementations of
>> Object Oberon or Oberon-2 with its type-bound procedures).
>
> The problem is not (in my humble opinion) that you only have offsets.
> The offsets are to POINTER fields of the RECORD, and (whether one uses
> the word or not) procedure variables are "pointers" as well, just to a
> piece of code instead of a RECORD. The problem is more that this is
> *all* they are.
>
> 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 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.
>
> (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?)
>
> Best,
> Peter
> --
> Oberon at lists.inf.ethz.ch mailing list for ETH Oberon and related systems
> https://lists.inf.ethz.ch/mailman/listinfo/oberon
>