Hi Michael,

on Tue, 08 Aug 2006 11:19:37 +0200, you wrote:
> Klaus D. Witzel wrote:
>> Hi Michael,
>>  since I cannot see what memory usage (or resource usage, for that  
>> matter)  has to do with security, I suggest to refer to "planning for   
>> contingencies", like in
>>  - http://en.wikipedia.org/wiki/Defensive_design
>> - http://www.google.com/search?q=%22planning+for+contingencies%22
>
> In this case, the domaining *is* my defensive design :-). I'm trying to  
> write a system where untrusted foreign code can run locally in a  
> sandboxed environment within the image.

O.K. when untrusted code (and/or the untrusted user) is in the scope I  
agree that your defensive design has something to do with security :)

>> A while back I had a discussion with Alexandre Bergel on "coloring"  
>> object  memory (as part of the Goya project) and your description looks  
>> like an  application of that idea. What we concluded by that time (pure  
>> theory ;-)  was that the metaclass is sufficient for coloring memory  
>> resources (i.e.  usage of memory, as in your case).
>>  Your "domain" members can be a (sub)set of instances of Metaclass,  
>> your  "domain" can be a clone of Metaclass. Think that today's  
>> Metaclass belongs  to the builtin *system* domain and that every domain  
>> user (or application  instance, as you mentioned in your posting) gets  
>> a clone of Metaclass (and  consequently the respective instances of  
>> Metaclass), on demand.
>>  So finding the total memory usage for one of your domains is pretty  
>> easy  and the pointer which does it is the *class* pointer (no change  
>> to the  VM), like (roughly) in
>>   domain "clone of Metaclass" allInstances inject: 0 into: [:accum   
>> :aDomainClass |
>>    aDomainClass allInstances ... + accum]
>>  Since I planned for a short response, I stop here (many more  
>> implications  can be discussed, of course).
>>  I'm sure that coloring of object memory is something which is easy to   
>> implement and to maintain.
>
> Doesn't this implementation limit you to having all objects of one class  
> bound to the same domain?

Hhm, no: domain membership is an implication of organization (IMO).  
Depends on how (besides: where) you implement "make instances of  
*this*class* belong to domain X under condition Y". Today's system runs  
with X := #system, Y := true, the default.

In a kiss approach, classes "know" whether their instances are shared a)  
by everybody in the system (today's default), b) per application (for  
services and the like), c) per application *instance* (for clients and the  
like), d) per process (regardless of other organizational aspects), e) per  
user (regardless of other organizational aspects), and so on. Of course,  
kiss implies that all instances of the same class belong to the same  
domain but, I hope it can be seen that it's a matter of what is decided by  
X and Y in the scheme above.

> How would you have two domains sharing the same implementation?

That's the easy part: clones of classes share their method dictionary (in  
form of a pointer, not as a copy). Only the class pointer of per domain  
created instances is changed, nothing more and nothing else. A very good  
ROI, that is :)

> For example, an "alicesEmail" domain and a "bobsEmail" domain would both  
> share the classes implementing email stuff.

Sure.

/Klaus

> Michael.
>
>
>