2015-02-26 14:04 GMT+01:00 stepharo <[email protected]>: > Thierry > > this is really interesting. Could you add the logic in some class comments > for the future? >
Done in the v3 of the slice. A MCLazyVersionInfo puts ancestor and stepChilds data in WeakArrays to allow their memory to be reclaimed and reloaded on demand. For all purposes, a MCLazyVersionInfo behaves exactly like a MCVersionInfo with the same data, but: - let the ancestry (and step children) be garbage collected - and reload that ancestry (and stepChildren) from the MC repositories when accessed (MCLazyVersionInfo>>loadAncestorsAndStepChildren for the reload, MCLazyVersionInfo>>ancestors and MCLazyVersionInfo>>stepChildren for the access). MCLazyVersionInfo is installed just as the ancestor in a MCWorkingAncestry (the direct ancestry of a WorkingCopy, which is the state all packages take when they are loaded in an image). It allows a MCWorkingAncestry to still know which package it is coming from, and, of course, the MCLazyVersionInfo to be able to reload the relevant ancestry from the right package. Once installed, by flushing the Monticello package cache, all the stored ancestry is garbage collected, except the roots of those ancestry trees, which are the MCLazyVersionInfo instances inside the MCWorkingAncestry instances. Warnings: - Algorithms which traverse the entire ancestry chain of all packages will force a reload of all the packages contained in the image, which is a time and memory and network consuming process... - It should degrades gracefully when reloading becomes impossible (returns an empty ancestry, but keeps knowledge of the fact some ancestry is missing). But this has not been tested. Thierry > > Stef > > Le 26/2/15 10:15, Thierry Goubier a écrit : > > Ok, > > a first slice is in, it's the first solution for now (second is just > extending the scheme). > > Loading the slice should install the lazy version and flush the caches > (does merging would initialize the class?) > > Thierry > > 2015-02-26 9:33 GMT+01:00 Marcus Denker <[email protected]>: > >> >> >>> >> And it behaves as the non-lazy one. >> >> There are a few things to change GUI-side to avoid an unnecessary >> loading of the complete ancestry of all the packages in the image, but this >> is workable. >> >> I see two ways of using it: >> >> as an "install, flush package cache before release and gain 5MB of RAM". >> If you start regularly developping (loading packages, etc...) then new >> packages will revert to non-lazy version info (without: 'please wait, I'm >> loading ancestry' moments). >> >> as a permanent change in MC. The change is a bit more intrusive (need >> to change how working copies are created) but, well, as long as the worked >> on packages are inside the in-memory MC package cache, behavior is exactly >> the same as a non-lazy version info. >> >> As you prefer. >> >> >> My focus is that we ship an image that is not growing indefinitely... so >> this means it needs to be part of the release. >> >> I don't care too much that the image is large when I work, but it >> should not come with all this data in memory when it can be calculated (or >> lazyly loaded) when needed. >> >> I added an issue: >> >> https://pharo.fogbugz.com/default.asp?14997 >> >> >> Thanks! >> >> Marcus >> >> > >
