[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
possible.
>
>> [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.
cheers,
rob
More information about the Squeak-dev
mailing list
|