On Sun, Nov 24, 2013 at 8:34 PM, Ben Kloosterman <[email protected]> wrote:
> On Mon, Nov 25, 2013 at 4:15 AM, Jonathan S. Shapiro <[email protected]>wrote: > >> Unfortunately, the false retention rate for conservative collectors is >> astonishingly high, and rises rapidly as a function of heap size (I speak >> from *bitter* experience). This can easily turn that 10% stuck object >> number into 30%, which is a different set of conditions entirely. >> >> Non-relocation and conservative retention are two different issues. >> Conservative collectors, of necessity, can't relocate anything that has >> been conservatively marked, but it's the fact that pointer identification >> is conservative that leads to the high false retention rate. >> > > Interesting , though a lot of lit. says these false references are very > low i didnt think it was that bad when using boehm with mono (whi is the > lit wrong does it require high virt memory address to avoid false > references ?).. anyway im not advocating non precise but they are still > better of with RC-Immix. > IIRC, Mono uses Boehm in a hybrid mode. Boehm has a way to allocate objects with an associated pointer map. Any object that has an associated pointer map is traced precisely. This reduces the conservative portion of the tracing to the stack and the registers. You still get false accusals, but it's from a much smaller pool of candidate words. But if you stop and think about it, you'll conclude that for any given word that is examined conservatively, there is a k% chance that this value, when imagined to be a pointer, falls within an object. That percent k is the percentage of the VA space that is utilized. As the heap gets to be around 1G on a 4G VA machine, the false hit rate hits a tipping point. Using the reference maps helps a lot, but it's not perfect. Actually, the hit rate is slightly worse than the % heap utilization, because Boehm considers pointers *after* an object to point to the object too if they fall within a bound. This is to deal with optimizations that produce pointers that are off the ends of vectors and may be the only surviving live pointer. > The worst case is not a unsustained growth because new blocks are not >>> needed you can reallocate holes at decreasing mutator efficiency until all >>> space is used. We do have to be concerned about the fragmentation cost. >>> >> >> I've been wondering about that. My version of this question is: "How many >> islands can a 'free' block have and still reasonably be treated as free?" >> > > The rate is configurable and they found 1 was best. > In the paper, they said that a free block had to be entirely free. If we are using the term "island" the same way, you are now saying that a block can have a single contiguous region of surviving allocations and still usefully be treated as free. Can you point me at where you saw this discussion? I must have missed it. > I suspect it might work out to define a free block as "a block having at >> least *k* free regions suitable for mid-sized object allocation". >> > > Yes that is the right way .. but you will favour groups of contiguous > lines not number of free lines for mid size. > Yes. Though if you then re-use the block as a recycled block that may become less important. > Malloc could certainly relocate and defragment / compact but we dont as >> we think the pain is not worth the memory cost. >> > Most current implementations of malloc use a buddy allocator. They coalesce. Malloc actually *can't* defragment/compact, because it is used in languages that don't have a pointer map. If you move an object, there is no way to update the references. Note by having 8K blocks we push a lot of objects to the LOB ( compare CLR > where its 80K) .... it is likely this has a higher fragmentation . > Who said anything about 8K blocks? I was thinking 32K. LOB objects have a minimum size of one page and are allocated in page multiples. Compacting the LOB is *much* easier than compacting the general heap. That's probably the easiest part of the problem. shap
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
