Right mailing list. Wrong assumptions. I guessed it would *just*work*.
Thanks for the correction.
On Mon, Sep 19, 2016 at 3:51 PM, Clément Bera <bera.clem...@gmail.com> wrote:
> I am not sure this is the right mailing list.
> Spur32BitPreen could be used as part of the Pharo release process as long as
> the compactor is not working well. This way released images can be more
> compact. If the Pharo folks wants to run Spur32BitPreen from Pharo to
> compact the image, the time spent to make things work may not be worth it as
> the mid-term solution is a new compactor.
> On Mon, Sep 19, 2016 at 1:42 AM, Ben Coman <b...@openinworld.com> wrote:
>> Forwarded from squeak & vm lists in case its useful to others...
>> On Sun, Sep 18, 2016 at 5:11 AM, Craig Latta <cr...@blackpagedigital.com>
>> > Hi--
>> > I've got the mass unused-method removal from Spoon working in Spur
>> > in Squeak 5.1. But now I have a juicy 12-megabyte chunk of free space in
>> > the middle of the 35-megabyte image that won't go away. There's just one
>> > Spur segment (I was expecting several?), with no pinned objects.
>> > Is there a known Squeak image with multiple segments? Is there some
>> > way to split a segment? Am I just supposed to play with the grow
>> > overhead and shrink threshold in the VM simulator, until the compaction
>> > I want is triggered?
>> > thanks!
>> > Craig Latta
>> ---------- Forwarded message ----------
>> From: tim Rowledge <t...@rowledge.org>
>> Date: Mon, Sep 19, 2016 at 1:17 AM
>> Subject: Re: [Vm-dev] unused-method removal vs. Spur compaction
>> To: Squeak Virtual Machine Development Discussion
>> Eliot mentioned using the vmaker sim to load the image and then save
>> it after removing the empty space. Ah, found it -
>> > 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!