[vm][q] what's needed to support multiple, disjoint ObjectMemories?

Robert Withers rwithers12 at attbi.com
Sun Jan 26 02:48:50 UTC 2003

guys, I can't answer in depth or respond to Lex' and Andreas' replies, 
immediately, but I will try later tonight.  I gotta cook 3 gallons of 
ragu alla bolognese, for the game tomorrow.  Go bucs!  :)

Very little if any of these ideas are my own original thoughts.  There 
is just this vast depth to so many really good ideas inside and all 
around this community.  I like exploring in-between-and-betwixt all of 
these ideas.

Tim, when did you help me hack into the vm and figure out where to hook 
in the redirectors?  I think it was Oct, 2000.   I have been working on 
this area for quite awhile (~18 months) and it is only about 70k of 
code (other parts that I use total about 200 kb currently).   I am not 
looking to finish this by squeak's seventh birthday.  I appreciate 
Andreas' question the best, because it does open the way to have an 
in-depth, long-term discussion about this, starting from commonly 
understood terminology and requirements.

My core approach is to take the time and do it robustly, and that most 
certainly includes this discussion we've begun.  I am most interested 
in allowing for shared resources, in the sense that more than one 
person can use them safely.  The implementation is more interesting 
that the theory.  However, while we are at it, let us consider the best 
we could do to support the highest quality of security and performance 
that we can.  One might view this as supporting B3 level military 
security (which was mentioned by the guys on elang, recently - I guess 
that's strong security.   http://www.dynamoo.com/orange/summary.htm)

...comments interspersed...

On Saturday, January 25, 2003, at 04:30 PM, Tim Rowledge wrote:

> Robert Withers <rwithers12 at attbi.com> appears to have written:
>> [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.
> Um, since we don't already have such spaces in use you're already
> talking about a total rewrite! I think you're getting confused here 
> with
> the VW object memory, which by the way already makes use of multiple
> oldspace segments when neccessary.

Oh, right.  I got ahead of myself on that one.  :)

>> - 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.
> Keeping to entirely separate spaces would at least avoid the problems 
> of
> compacting across areas (what do you do when there is spare room but 
> not
> for the object you're curently trying to move? skip it and see if there
> is something of the right size? If so, how are you going to remember to
> try again with the skipped object? etc) but you are still I think going
> to cost a good few cycles to do the boundary checking all the time. How
> do you specify which memory an object lives in? Can you copy from space
> to space?

what  implications does the following have:  squeak image-level 
processes can only access one object memory, ever.  Their stack is 
inside of a single object memory, and the vm always creates immutable 
references, in those stack-frames, to only reference that stack's 
object memory.

no moving can occur.  copying happens in the image, through a secure 
connection.  There could be shared data-only objects, like bitmaps, 
that could be  written to, and read from, by more than one process.  It 
is data, not capability.  (but it does represent what is called a 
"covert channel")

>> - 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.
> Oh, is that all :-) ? No problems cobber.

:)  I have another 3 years to go on this project, so anything is 

>> [questions and comments]
>> 1) What problems or difficulties would there be in allowing
>> ObjectMemory to be multiply instantiated?
> Lots. How to share memory on a friendly basis?

data-only resources, perhaps.

>  When you grow one, where
> do you stop so that others might have room - or do you?

I dunno.  What do you think?

> What about the
> memory cost of having to have headroom in many separate spaces; maybe
> you rely on virtual memory for this, but that has costs too.

on-demand grow from the heap?  again, I dunno, it's not my area.

>> 2) How would the interpreter need to be changed for allocation?
> You'd have to have a way to specify which space the objectis to live 
> in.

all roots into an object memory are in that object memory, and they are 
either local objects, or FarReferences to other spaces  (spaceId:oid).

>> 3) How would the interpreter need to be changed for collection?
> Mostly obviously, stoppping tracing at the right boundaries, running
> through the list of spaces, having forwarding tables etc.

trace from per space roots?   We take a hit having multiple spaces to 
GC, I suppose.  this could be the fatal issue with this approach.   :(

>> 4) What would need to be the stack representation of partitioned
>> references?
> Huh?

it's now a redundant question, given the above discussion on stacks.

>> 5) Do you think this is an interesting direction of research in 
>> squeak?
> Only if somebody has money to pay for it, in which case it is
> fascinating.

that is just completely awesome!  let's friggen build something 
transcendental.   Squeak is in some part the cup of our humanity, 
expressed through our ability to create beautiful and interesting 
systems within it.  ;-)

I think this is the kind of thing that we could possibly get funded 
through the squeak-foundation.  There are nsf and nist grants out 
there, and perhaps a matching funds argument is the best.  course, SqF 
could match the funds with resource and asset assignments to the 
project.   I would donate a few machines for that purpose, but someone 
more familiar with these areas should probably take the initiative.

more later...I must start cooking.


More information about the Squeak-dev mailing list