Planning for contingencies in Squeak
Klaus D. Witzel
klaus.witzel at cobss.com
Tue Aug 8 10:25:19 UTC 2006
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.
>
>
>
More information about the Squeak-dev
mailing list
|