Hi Rob,

I think it would be helpful if you could say something about the thought
process that brought you to the point where you believe that "multiple
object memories in one Squeak process" are really a good (or even the best)
way to solve this problem. Personally, I am not convinced but I'd like to
hear your arguments. It seems to me that using "multiple Squeak VMs" (e.g.,
multiple object memories in multiple Squeak processes) are very much
equivalent to what you are looking at and by far simpler to do since you
have "only" to concentrate on the inter-process communication (and not to
deal with GC, allocation etc). In fact, I would claim that something pretty
good can be mocked up using sockets for communication which then might be
optimized using shared memory.

Cheers,
 - Andreas


-----Original Message-----
From: squeak-dev-bounces at lists.squeakfoundation.org
[mailto:squeak-dev-bounces at lists.squeakfoundation.org] On Behalf Of Robert
Withers
Sent: Saturday, January 25, 2003 10:04 PM
To: squeak-dev
Subject: [vm][q] what's needed to support multiple, disjoint ObjectMemories?


folks,

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 GC
agents. 
- 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 references.

[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 references?
5) Do you think this is an interesting direction of research in squeak?

cheers,
robert


squeaker maxim:
A small hack can fix a small problem
A big problem is really many small problems
Hack the image!