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

Tim Rowledge tim at sumeru.stanford.edu
Sat Jan 25 21:30:59 UTC 2003


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.

> - 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?

> - 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.

> [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? When you grow one, where
do you stop so that others might have room - or do you? 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.

> 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.

> 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.

> 4) What would need to be the stack representation of partitioned 
> references?
Huh?
> 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.

tim
-- 
Tim Rowledge, tim at sumeru.stanford.edu, http://sumeru.stanford.edu/tim
Nobody has ever, ever, EVER learned all of WordPerfect.



More information about the Squeak-dev mailing list