Cool, I think you're saying, once the signed oop is fixed, there should be no problem with memory locations beyond 4GB. Curious though, why the signed-oop bug also affects where images *start* in memory instead of only how large they could be.. Given (theoretical) unlimited memory, then, does the signed-oop fix allow an unlimited number of running Squeak images?
I wasn't sure because of the image being referred as "direct-pointer"; thought that might mean hard-referenced memory locations limited to 32 bits.
thanks.
On 5/30/07, John M McIntosh johnmci@smalltalkconsulting.com wrote:
On May 30, 2007, at 6:17 PM, Chris Muller wrote:
I don't want a 4GB image, but I may want a lot of normal-sized Squeak images running on a piece of "big-iron". But I guess the current VM's have some problem where the oop was defined as signed, so images cannot even *reside* above 1GB (or whatever it is).
2GB, and lurking are changes to fix that issue, but someone has to buckle down and do testing, then mmm say oh yes should be fixed. But how would you know?
So even if that was fixed, that would take 32-bit Squeak up to 4GB boundary, only if all 32-bits were for the oop.
... I saw this ad on the back of InfoRag earlier today. Some IBM blade, multi-Xeon-multi-core, up to 48GB high-speed RAM, "starting" at $2K. Cool, this could probably run a lot of images simultaneously, but how far could you go with 32-bit Squeak on this?
Depends on the image footprint, 3GB images then what 15 or so Plus then one cpu needed for each Squeak VM, plus a couple of spares to do operating system I/O, housekeeping etc. etc.
--
=== John M. McIntosh johnmci@smalltalkconsulting.com Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com ======================================================================== ===