John,
I've been running into this problem at various times - turns out that #standardTime: on any recent Windows machine will give you anything _but_ standard conditions (due to swapping etc). The best thing you can do is just ignore it ;-) With respect to #copySmartsRoot: you will notice that there's an upper limit set for the initial size, so that actually works quite well.
Cheers, - Andreas
-----Original Message----- From: squeak-dev-admin@lists.squeakfoundation.org [mailto:squeak-dev-admin@lists.squeakfoundation.org] On Behalf Of John M McIntosh Sent: Tuesday, February 19, 2002 2:41 AM To: squeak-dev@lists.squeakfoundation.org Subject: A problem with standardTime:
standardTime: aBlock "Times the execution of aBlock in milliseconds, under the following standard conditions: exactly 10Mb of free space is available and compacted, and the recent VM statistics are reset immediately before execution." | spaceLeft tieDown | spaceLeft _ Smalltalk garbageCollect. spaceLeft < 1e7 ifTrue: [self error: 'not enough space for standard conditions']. tieDown _ ByteArray new: spaceLeft - 1e7. "Leave exactly 10MB free"
Now the problem comes in when the VM can autosize, but the autosizing doesn't take Virtual Memory considerations into account. The Smalltalk garbageCollect returns the maximum size we can grow to, versus say a size that won't cause page swapping.
So on my mac this returns
517759868
As you can see we then run off and allocate 517759868 - 10000000.
But on a machine that only *has* 512MB of memory, lots of things are paged out and a historically significant event called *page thrashing* occurs.
Now I think Dan wrote this, and perhaps it needs to be rethinked.
I'm not sure on unix machines you can really ask what the 'safe' limit it, after all the objective of VM operating systems is to allow you to run applications that don't fit into real memory boundaries.
So I'll welcome a change set
Also the max size is used in ImageSegment>>copySmartRootsExport: rootArray for some decision on characteristics of an algorithm to be run.
--
==============================================================
John M. McIntosh johnmci@smalltalkconsulting.com 1-800-477-2659 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com
==============================================================