[vm][q] what's needed to support multiple, disjoint
John M McIntosh
johnmci at smalltalkconsulting.com
Mon Jan 27 19:35:43 UTC 2003
On Saturday, January 25, 2003, at 01: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
>> 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
> the VW object memory, which by the way already makes use of multiple
> oldspace segments when neccessary.
Well it's best not to loose track of these thoughts, although the
discussion is focusing around security concerns much of above really
address issues with GC performance and simplifies object memory access
by external DLLs which want non-movable objects.
I'll summarize the issues:
a) Writing all this and ensuring it's correct.
b) Watching the issue of machines/os with simple memory both in
implementation and space, many of the problem mentioned by Tim can be
solved by taking the attitude that memory is unlimited. However this
isn't quite a reasonable choice for pocketpc machines. So ensuring low
end clients aren't affected by high-end choices is an interesting issue.
e) mmm I could ask is such complexity needed? I seem to recall John
Maloney told me that the current GC, amongst many tried gave good
performance, but it was also simple, a good thing.
Mind if you want radical changes, perhaps one should following in some
other Smalltalk VM footsteps and construct the image at startup time
from definitions thus create a memory space optimal for the machine and
memory characteristics you are running on, and use a custom VMs created
for a particular memory usage pattern instead of having one Vm that
fits all. I'll point to the GNU smalltalk usage of os virtual memory
routines to assist in old/new pointer recognition, a performance
feature well known to VM implementors yet unused by Squeak because of
one-size fits all thinking.
PS One should also look to VisualAge for it's usage of chunks of memory
containing objects which then have various attributes (new, old,
fixed, read-only, etc).
John M. McIntosh <johnmci at smalltalkconsulting.com> 1-800-477-2659
Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com
More information about the Squeak-dev