On Thu, Feb 16, 2017 at 6:10 PM, Sven Van Caekenberghe <[email protected]> wrote:
> Thanks, Clément, for this update, really exciting news. Is the new GC > faster too ? > The full GC is indeed much faster as the previous compaction algorithm was very slow. But unless you were executing memory intensive code in very large heaps, you won't see much difference as full GC are uncommon. We still need to make the GC incremental to avoid pauses ... > > 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 > > > > >
