(cc squeak-dev per Bert's suggestion)
Hi Dan,
Indeed it is "#define SQ_VI_BYTES_PER_WORD 8". This macro is the one used in sqMemoryAccess.h, so BYTES_PER_WORD and BASE_HEADER_SIZE are set from SQ_VI_BYTES_PER_WORD. It turned out that it is possible to rearrange some class and instance variables in ObjectMemory and Intepreter such that the generated C code is the same for 32 and 64 bit object memory, controlled at compile time by the SQ_VI_BYTES_PER_WORD macro. I'm afraid it makes the Smalltalk source less readable, but it's nice not to need to generate different sets of C sources for src32 and src64.
I should mention that recent versions of VMMaker can no longer be loaded into a Squeak 3.8 image, primarily due to the use of pragmas, e.g. "<inline: true>" rather than "self inline: true", which in turn means that at the moment one cannot genererate a current VM from the Squeak 3.8 based 64-bit image. I will have a bit of time to play with this on Tuesday, so I'll see if I can find a way to either load current VMMaker into the 3.8 image, or to trace an up-to-date Squeak 4.1 image to 64 bits. I'll let you know before Wednesday if I have made any progress.
Dave
On Fri, Oct 29, 2010 at 10:40:39PM -0700, Dan Ingalls wrote:
Hi David -
Thanks for the pointers. I'm assuming you meant BYTES_PER_WORD 8, right? Do let me know if you gather more infor in the next few days. I think I'm not going to have a chance at this until after next Wed.
All the best
- Dan
On Fri, Oct 29, 2010 at 09:48:11AM +0200, Bert Freudenberg wrote:
On 29.10.2010, at 06:25, Dan Ingalls wrote:
Hi Guys ;-)
Anyone have experience with running super huge Squeaks? I have the chance to use an absurdly big machine. I'd appreciate advice (offline unless you think it would be generally useful) regarding the relative stability of, say, linux and windoze builds of 64-bit Squeaks known (or thought) to run with over a terabyte of objects, and also where there may be some pre-built 64-bit images (sorry if this is in an obvious place). Finally (since I've mainly used a Mac for Squeak) I guess I'll have to know how to tell it how big to be, or would it grow gracefully if I just said "(String new: 1000000000000) size" in a normal image?
Thanks
- Dan
Dave Lewis has been working on 64 bit stuff, he surely will respond (and please keep responses on list, this is rather interesting). A recent image is here:
http://squeakvm.org/squeak64/sq64-dtl.zip
I think there isn't even much experience with a Gigabyte-sized image ...
Hi Dan,
The image that Bert mentions is an updated version of your original 64-bit image, suitable for running on a current Squeak VM. I have not tried tracing the latest Squeak trunk image (sounds like a good project for this weekend though :)
The quickest way to get a VM running is to start with an up to date Squeak image, load latest VMMaker from www.squeaksource.com/VMMaker and platform sources from Subversion. The "64-bit VM" button is gone from the VMMaker tool, all that is needed to build the 64 bit version is to set a macro either in ./build/config.h or in ./src/vm/interp.h:
#define SQ_VI_BYTES_PER_WORD 4
I use Linux for running this stuff, so I can't speak to Windows or OS X. On a unix platform, if you evaluate "(String new: 1000000000000) size" in sq64-dtl.image, you will get a low space notifier. I remember adding some checks to the VM to prevent address overflows for allocations that are "unreasonably large), and I think this notifier reflects hitting that limit (sorry I can't recall the details, I'll check later). It would be fun to see how big "unreasonably large" could be though :)
A gigabyte is no problem though. The following succeeds on a 64-bit image:
(String new: 1000000000) size ==> 1000000000
For allocation requests that are within the current VM limits, what you can expect to see on a unix box is that your VM will cheerfully keep allocating memory from the OS until your system starts swapping pages to disk, at which point everything on the system slows to a crawl. It will be interesting to see what happens on a really big box with lots of memory.
Dave
squeak-dev@lists.squeakfoundation.org