[vm][q] what's needed to support multiple, disjoint ObjectMemories?
rwithers12 at attbi.com
Sat Jan 25 21:04:02 UTC 2003
I am trying to think what facilities we could build that generates the
most secure squeak environment. After a lot of reading, my approach
has been to create special object references, partition them, and
modify the way they react to message sending. Other complimentary
approaches establish filtered method-dictionaries, at the meta-level.
I believe these two approaches will start to integrate.
In focusing on reference partitioning, a minimalist implementation
would be vm-supported partitioning. To really ensure that two
different secured areas (vats) don't leak in undetectable ways, I
believe that the capability to instantiate multiple instances of
ObjectMemory is the most effective.
[requirements for multiple Objectmemories in one squeak process]
- Each ObjectMemory would have an eden space, survivor spaces, old
space segments, a large space, a fixed space, a compiled code cache and
a stack space.
- The memory layout, in squeak's heap, would have a partition table
referencing these objectMemories, and they wouldn't overlap in the heap.
- Each would be garbage collected separately and have all appropriate
- The only limit to the number and size of these objectMemories will be
available memory, a limit to the total overhaed cost and optimizing the
success of QoS constraints.
- Out pointers and in pointers between objectMemories would be
implemented using a vm implementation of the EventualSend references
(found at http://minnow.cc.gatech.edu/squeak/2410).
- An optimization to asynchronous eventual sending would be to
immediately evaluate message invocations and resolve the promises to
[questions and comments]
1) What problems or difficulties would there be in allowing
ObjectMemory to be multiply instantiated?
2) How would the interpreter need to be changed for allocation?
3) How would the interpreter need to be changed for collection?
4) What would need to be the stack representation of partitioned
5) Do you think this is an interesting direction of research in squeak?
A small hack can fix a small problem
A big problem is really many small problems
Hack the image!
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 2302 bytes
Desc: not available
Url : http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20030125/c98156ee/attachment.bin
More information about the Squeak-dev