- DotNet has application domains. Communication between each one requires serialisation and deserialisation. - If interdomain objects were stored in a seperate memory space, shared by all appdomains, such serialisation/deserialisation wouldn't occur. - Objects would need to be "owned" by a domain though, to prevent errors. - A simple example of this is of information flowing from a network interface (in AppDomain A), through to a process (in AppDomain B), another process (in AppDomain B), then back again to the network inferface, through the other domains. - The simple example can be implemented by asking for a large amount of unmanaged memory. The memory is treated as an infinate circular address space. When data is allocated it is taken from the end, when data is deallocated, the space is marked as dead, and when a consecutive set of dead space is straight after the start, it is reclaimed, by moving the definition of start. So AppDomain A, would create an array of received bytes, it would pass the reference to AppDomain B, which after processing would pass the reference to AppDomain C. Eliminating, serialisation/deserialisaion between. The memory access would need to be syncronised for thread safety. Each appdomain would only need to deserialise. - A more complicated version is to create the SharedObject class which every inter-appdomain data class needs to inherit. The unmanaged memory wrapper would need to implement a GC similar to .NETs. On construction the SharedObject class would obtain a memory handle, the SharedObject. All primatives would need to be reimplemented as SharedString, SharedInt etc.. The outcome would be that, no deserialisation will need to occur between appdomains either. - Of course running out of memory in the first chunk of allocated memory would require more being allocated, then joined together to form a single logical block. - I'm sure there's much more that would need to be done but... - This would be heaps easier if the CLR was simply coded to support AppDomain SharedMemory.
-- toadth, May 08 2009

I thought of a way to implement this, and a slight change which makes it better.

Mono is an open source CLR. You could create a branch which implements Portable memory space, for use between AppDomains.

Because you're not copying the object, it's possible to have object handles in both AppDomains, but the object should only be allowed to be accessed by one at a time.

The changes would require adding an extra bit to each object, which indicates if it's a shared object. The object would also need a field to store which appdomain has control.

The programmer would need to make sure that references are nulled in a AppDomain relinquishing control. The JIT could enforce that this happens, either doing for the programmer, issuing warnings that the programmer forgot, or even throwing an exception. References on the stack which are blocked to to a Syncronous call to another AppDomain would not need to be nulled.

Other challenges. The shared object's class must be consistent between AppDomains.

Application of AppDomain shared memory. Any pipeline oriented application. Such as application servers, which use AppDomains to isolate and protect from erroneous code.

Performance of AppDomains (as well as complexity of using them), hinders widespread use and reaping the benefits from having more reliable applications.

Perhaps this is the wrong way to go about it? Maybe we need another layer of container - an ExceptionDomain? It all runs in one AppDomain, has the same single security context, but you can have different isolated areas, where memory, thread and stack errors can be isolated.
-- toadth, Dec 02 2009



random, halfbakery