> 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. 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. > 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. 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....). On Tue, Mar 15, 2016 at 3:10 PM, 'Bill Hart' via julia-users <[email protected]> wrote: >> >> > I see. That is a relief. We'll stick with & for now. >> > >> >> more than 2 collection* >> > >> > >> > I see, so collections can happen at any time, not when some block of >> > memory >> > is "full". >> >> Yes, it happens whenever the GC thinks there are enough allocation >> since the last time. > > > So for you a "generation" has no relation to a "collection"? > > If not, what is your definition of a generation? > > Does Julia just have two generations, short term and long term? 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"? > > Bill.
