On Tue, Mar 15, 2016 at 3:32 PM, 'Bill Hart' via julia-users <[email protected]> wrote: > > > On 15 March 2016 at 20:24, Yichao Yu <[email protected]> wrote: >> >> > I wonder what the issue was, and whether the person who fixed it even >> > realised they had fixed it. :-) >> >> There were many GC related PRs. Some of them are for mem-leak. I don't >> remember any one in particular about malloc though.... >> >> > Actually, let me ask this a bit more precisely. >> > >> > Suppose a collection has occurred. Then there are big gaps where memory >> > has been reclaimed, between blocks that are still in use. If there is no >> > copying collector, how does the gc avoid fragmentation? >> > >> > I see that each page of memory is released as it is found to contain no >> > objects still in use. Is that the only mechanism used to control >> > fragmentation? >> >> It doesn't avoid fragmentation. This isn't a big issue for julia's >> allocator since the pools are size segregated and it is never >> necessary to find a slot of large enough size by walking the free >> list. > > > Yeah I wondered about that. > >> >> This will cause more memory usage and I don't think there's a way >> around it without moving. We'd like to try implement moving but as you >> may guess this is a relatively hard problem. Fortunately I think >> there's a relatively clear upgrade path although there are a lot of >> other improvement we'd like to implement before that. > > > Sure. GC at least has a reputation for being "hard". > >> >> >> > So for you a "generation" has no relation to a "collection"? >> >> I use collection only as in the "collection" in "doing a garbage >> collection" >> >> > >> > If not, what is your definition of a generation? >> >> Julia GC has two generations. Objects are allocated in the young gen >> and are promoted to the old gen if they survive long enough. >> This is not much different from a traditional generational collector >> although instead of using the memory space (address range) to keep >> track of the metadata (the generation an object is in) we use the GC >> bit to keep track of that info inline and avoid the moving. >> >> > >> > Does Julia just have two generations, short term and long term? >> >> Yes, young and old. >> >> > And each object in the short term generation has a collection count. >> > Once the collection count hits 2 the object is promoted to long term >> > generation by marking it, but it stays right where it is in the same >> > "pool"? >> >> Right. > > > Great, thanks. I understand better now. Not all the ins and outs, but a much > better overall picture. > >> >> >> The generational part of the GC is a little messy. This is mainly >> because the new GC was designed to be an incremental GC and then >> gradually transformed into a generational GC....... (they are >> suprisingly similar....). >> > > Oh I didn't even realise that LOL. I thought Julia just switched to a > generational gc and that's it. Probably at the time I didn't even know there
On master, yes, that's all, the incremental GC never hit the master. I'm just talking about the PR that did this. In fact the original PR still has the "wrong" title https://github.com/JuliaLang/julia/pull/5227. > was a difference between incremental and generational. I probably couldn't > write down a definition of either even now. But at least I have nonzero > knowledge of the Julia GC which will help me answer all the questions I keep > getting from my colleagues on it. > > Bill.
