[M3devel] blue sky proposal :)

[Tony Hosking]

Messing with VM protection mechanisms *will* impact performance, both  
to set things up and to maintain.  For example, the GC needs to write  
to those pages as it operates, so you are going to put extra work on  
the GC.  Yuck!

Here is the germ of an alternative idea -- let add a READONLY  
declaration, with enforcement by the compiler.   Should READONLY be a  
property of types?  i.e.,

READONLY RECORD f: T;  g: T; END (* records of this type can never be  
modified (i.e., f, g can only be initialized in a constructor) *)

Or should READONLY be a property of designators?  i.e.,

RECORD READONLY f: T; g: T END (* READONLY fields can never be  
modified (i.e., f cannot be modified, but g can be modified) *)

This needs fleshing out.  For example, if READONLY attaches to types,  
then what are the assignment rules for non-readonly and readonly?   
More complicated still, what are the subtype rules?

Food for thought...

On Mar 22, 2008, at 9:17 AM, Dragiša Durić wrote:

> Now that VM mechanism is fully obsoleted by Mr. Hoskings GC... Why  
> would
> not we make something like this...
>
> <* READONLY object *>  - to move object to VM protected pages of  
> traced
> heap, so we can have RuntimeError.E when some code tries to write into
> object
>
> <* WRITEABLE object *> - to return it back to normal traced heap pages
>
> Pragmas... Can be ignored by non-compatible compiler, and totally are
> not changing language semantics. They just offer great debugging tool
> and help us define/enforce some static properties of our structures.
>
> This, of course, is something for GC people to do...  As I see current
> situation (as deep as I went into it) it will not affect performance  
> at
> all, and it will (IMHO) help straighten GC code even more :).
>
> dd
> -- 
> Dragiša Durić <dragisha at m3w.org>