On Wed, 31 Dec 2008 18:57:59 +0100, Andreas Raab wrote:
If you're running 2.x make sure you actually have enough free space for the operation - I don't recall if we had dynamic memory growth in 2.x and unless you specify sufficient memory the VM will start with a default allocation (don't remember how much) and not grow. If that isn't it, check if you have SmallInts or other objects in there that the VM cannot become - this might simply be a bug in your porting process and may have nothing to do with the become operation.
Lots of directions which I didn't think about, thanks very much for taking care Andreas.
Okay: in order to rule out SmallInts etc and also to see if does dynamic host mem alloc, I set the debugging/F2 and then repeatedly did
Smalltalk garbageCollect. ((1 to: 366666) collect: [:m | Object new]) elementsExchangeIdentityWith: ((1 to: 366666) collect: [:m | Object new])
This causes growth/shrinkage activity (good VM/GC :) albeit the primitive fails every 2nd time in a 19.8 MB .image :(
But the primitive fails *constantly* doing the same expression in a "fresh"/"clean" 5.51 MB .image :(( and the smaller .image is the one I have to use to make the larger one ...
O.K., so, did some more experiments and at the moment it works when #elementsExchangeIdentityWith: is performed with up to 64K oops (incrementally so to speak). This is needed only during class initialization and so I was reluctant to spending better optimized code for such a single happening task.
Perhaps the 64K oops approach made it already :) I hope so. I dont' want to put "give it memory" into installation instructions (too J-ish for my taste ;) and figuring out possible/working language-level GC parameters for the 2.x VM is beyond my horizon at the moment.
Thanks again for your good advice, and <de>guten Rutsch ins neue Jahr</de> :-D
/Klaus
Cheers,
- Andreas
Klaus D. Witzel wrote:
Hi, I'm backporting code to Squeak2.x and an ivocation of #elementsExchangeIdentityWith: which works fine with some 117k elements, fails under the Squeak2.x VM :( Searched the list archive to no avail. Was there something in the past, a limit on the # of elements? What directions can there be towards a solution, TIA. /Klaus