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 >
