Thanks, Clément, for this update, really exciting news. Is the new GC faster
too ?
> On 16 Feb 2017, at 17:16, Clément Bera <[email protected]> wrote:
>
> Hi all,
>
> A temporary solution had been integrated in the VM a year ago, but only part
> of the problem was solved.
>
> This issue has been entirely solved in the VM through the implementation of a
> new compactor for the full GC. The new compactor (called the planning
> compactor) has been marked as the default full GC compactor for further VM
> builds yesterday, replacing the existing Pig compactor. However it seems that
> the new compactor has not yet passed all the validation infrastructure
> (several builds are currently marked as 'error').
>
> I would expect VM builds in the incoming days to feature the new compactor.
> This problem should therefore be solved very soon in the latest pharo VMs.
>
> In any case, this problem does not require any image-side changes. It will be
> in Pharo 6 if the Pharo 6 release VM features the new compactor.
>
> Best,
>
> Clement
>
> On Thu, Feb 16, 2017 at 4:26 PM, denker <[email protected]> wrote:
>
> > On 16 Feb 2017, at 16:22, Sven Van Caekenberghe <[email protected]> wrote:
> >
> >
> >> On 16 Feb 2017, at 16:16, denker <[email protected]> wrote:
> >>
> >> No,
> >>
> >> Our image is not 47 MB… more like 28.
> >>
> >> My understanding is:
> >> -> Cog works with “pages” (is that the term?) of memory.
> >> -> if a page is empty, it gets cleaned up and does not cost space
> >> when saving.
> >> -> if there is some object still allocated, the whole page will be
> >> saved (partly empty)
> >>
> >> Not sure if that is completely right, but it explains why the image with
> >> lots of objects allocated new can shrink again, while the 47MB never
> >> shrinks, even though the
> >> image for sure is much smaller.
> >>
> >> => what is missing is a “cleanup” phase that sweeps together all the
> >> half-empty pages.
> >>
> >> What is fun is that we now ship a 47MB image and nobody ever complains.
> >> (or even asks)
> >
> > Yeah, that proves it is not such a big deal, today.
> > But still, we have to fix this discrepancy between 28 and 47.
> >
>
>
> As I tried to explain: the VM is missing a “condenser” that cleans up half
> allocated pages.
>
> > Is the 'release cleanup' done on this image each time ?
>
> Yes.
>
> Marcus
>
