Re: [squeak-dev] [ANN] Squeak 5.1 Feature Freeze -- Trunk closed for new features; only bug fixes or text updates
Hi Tim,
On Aug 11, 2016, at 11:14 AM, tim Rowledge tim@rowledge.org wrote:
[snip]
The image is frikkin’ huge. How on earth do we have 22Mb of ByteArray/BitMap/ByteString around? And it looks like we are keeping a very large amount of MC stuff; 13018 instances of MCVersionInfo/MCVersionName/DateAndTime/Date/Time/UUID. Is that smart? Simply flushing the cached ancestry from the MC browser gets rid of 60% of them and appears to save 3Mb. Except the damn saved image afterwards is exactly the same size! Sigh.
Sorry about this. This is due to the immaturity (brokenness) of the Spur compactor. There is a reasonable solution for the release process, which is to modify the 32- to 64-bit bootstrap to allow the VM simulator to clone a 32-bit image having squeezed the free space out of it. I'll try and get in this asap. By year end I hope that Clément and I will have rewritten the compactor to eliminate this embarrassingly bad behaviour.
tim
tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Strange OpCodes: RDR: Rotate Disk Right
On 14 Aug 2016, at 13:03, Eliot Miranda eliot.miranda@gmail.com wrote:
Hi Tim,
On Aug 11, 2016, at 11:14 AM, tim Rowledge tim@rowledge.org wrote:
[snip]
The image is frikkin’ huge. How on earth do we have 22Mb of ByteArray/BitMap/ByteString around? And it looks like we are keeping a very large amount of MC stuff; 13018 instances of MCVersionInfo/MCVersionName/DateAndTime/Date/Time/UUID. Is that smart? Simply flushing the cached ancestry from the MC browser gets rid of 60% of them and appears to save 3Mb. Except the damn saved image afterwards is exactly the same size! Sigh.
Sorry about this. This is due to the immaturity (brokenness) of the Spur compactor. There is a reasonable solution for the release process, which is to modify the 32- to 64-bit bootstrap to allow the VM simulator to clone a 32-bit image having squeezed the free space out of it. I'll try and get in this asap. By year end I hope that Clément and I will have rewritten the compactor to eliminate this embarrassingly bad behaviour.
+1
tim
tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Strange OpCodes: RDR: Rotate Disk Right
On 14-08-2016, at 4:03 AM, Eliot Miranda eliot.miranda@gmail.com wrote:
Hi Tim,
On Aug 11, 2016, at 11:14 AM, tim Rowledge tim@rowledge.org wrote:
[snip]
The image is frikkin’ huge. How on earth do we have 22Mb of ByteArray/BitMap/ByteString around? And it looks like we are keeping a very large amount of MC stuff; 13018 instances of MCVersionInfo/MCVersionName/DateAndTime/Date/Time/UUID. Is that smart? Simply flushing the cached ancestry from the MC browser gets rid of 60% of them and appears to save 3Mb. Except the damn saved image afterwards is exactly the same size! Sigh.
Sorry about this. This is due to the immaturity (brokenness) of the Spur compactor. There is a reasonable solution for the release process, which is to modify the 32- to 64-bit bootstrap to allow the VM simulator to clone a 32-bit image having squeezed the free space out of it. I'll try and get in this asap. By year end I hope that Clément and I will have rewritten the compactor to eliminate this embarrassingly bad behaviour.
Argh, yes, I remember you mentioning this in the past.
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim If you think C++ is not overly complicated, just what is a protected abstract virtual base pure virtual private destructor and when was the last time you needed one? -- Tom Cargin
Hi Tim,
On Sun, Aug 14, 2016 at 11:44 AM, tim Rowledge tim@rowledge.org wrote:
On 14-08-2016, at 4:03 AM, Eliot Miranda eliot.miranda@gmail.com
wrote:
Hi Tim,
On Aug 11, 2016, at 11:14 AM, tim Rowledge tim@rowledge.org wrote:
[snip]
The image is frikkin’ huge. How on earth do we have 22Mb of
ByteArray/BitMap/ByteString around? And it looks like we are keeping a very large amount of MC stuff; 13018 instances of MCVersionInfo/MCVersionName/DateAndTime/Date/Time/UUID. Is that smart? Simply flushing the cached ancestry from the MC browser gets rid of 60% of them and appears to save 3Mb. Except the damn saved image afterwards is exactly the same size! Sigh.
Build a VMMaker image with image/buildspurtrunkvmmaker.sh and you can now use Spur32BitPreen to rewrite the image to be more compact. We can use this as part of the release process until Clément and I have fixed Spur compaction. e.g.
Spur32BitPreen new preenImage: '../oscogvm/image/trunk50' Looking for module ... loaded...computing accessor depths...done Looking for module ... loaded...computing accessor depths...done::::.............................................done. old heap size: 41,897,472 initial new heap size: 26,818,472 change: -35.99% final new heap size: 26,818,472 change: -35.99%
Done!
HTH _,,,^..^,,,_ best, Eliot
vm-dev@lists.squeakfoundation.org
-
Eliot Miranda -
Esteban Lorenzano -
tim Rowledge