Dolphin 6 feature question ?

Hi,

D6 will have Immutability support (like VW) ?
(lets you mark objects as immutable which results in throwing exceptions
when you try to modify them.
The obvious thing to do is to mark all objects as immutable when you read
them from the database, and catch the exception to do an automatic
markDirty)

Regards Bruno


---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.585 / Virus Database: 370 - Release Date: 11/02/2004

Bruno,

> The obvious thing to do is to mark all objects as immutable when you read
> them from the database, and catch the exception to do an automatic
> markDirty)

At the risk of telling you something you already know, you could wrap the
objects, and use DNU in the wrapper to forward changes to each altered
object, and mark it (or its wrapper) as dirty.

Have a good one,

Bill

--
Wilhelm K. Schwab, Ph.D.
[hidden email]

"Bruno" <[hidden email]> wrote in message
news:c0e9so$160bv2$[hidden email]...
> Hi,
>
> D6 will have Immutability support (like VW) ?
> (lets you mark objects as immutable which results in throwing exceptions
> when you try to modify them.
> The obvious thing to do is to mark all objects as immutable when you read
> them from the database, and catch the exception to do an automatic
> markDirty)

This feature is on our list of potential future enhancements, but it will
certainly not be in Dolphin 6. There are a couple of approaches to this:
1) Include a flag in the object header somewhere, and test this before
performing any mutate operation.
2) Allocate (or move) immutable objects to a heap held in virtual memory
that is marked as read-only at a hardware/os level when user code is
running.

(1) is the easiest approach to this - there aren't actually that many places
that memory writes occur inside the VM, so these could all be guarded
reasonably easily. However it violates the principle of not incurring
overhead in the general case just to support a specific case. Every object
write would potentially incur the cost of an extra test to verify if the
object was marked as immutable. It is possible that this cost could be
hidden by combining it with some other necessary test, however.

(2) is our preferred approach. It absolutely guarantees that an object is
immutable, even if you try to write to it through a memory pointer, for
example when passing a supposedly constant byte buffer to an external
library call. It carries no overhead for normal mutable objects. There are
other advantages which I won't go into here, but it is considerably more
complex to implement. I am also not sure that it would necessarily support
your requirement best, since what you really want is not constant objects,
but either a notification that a write has occurred to an object, or some
way to test if it is dirty. I think there may be cleaner and more efficient
ways to implement those features than marking objects as immutable and
catching an exception in the image, though they would also need VM support.

Regards

Blair

Blair,

> what you really want is not constant objects,
> but either a notification that a write has occurred to an object, or some
> way to test if it is dirty.

I've occasionally thought that it would be nice to be able to errect a
read-barrier around an object as well as a write-barrier.

I know one can get a roughly similar effect my using proxies and DNU handling,
but I don't really like that approach very much.  (I think it's fragile, and a
rather obscurely indirect expression of the intent of the code).

Possibly it could be implemented by swizzling the pointer in the object table.

    -- chris