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 <btc@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 <craig@blackpagedigital.com> wrote:
>
>
> 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 <tim@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
<vm-dev@lists.squeakfoundation.org>



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!
>
tim