On Wed, Mar 23, 2011 at 11:02 PM, Ben Kloosterman <[email protected]>wrote:
> But it's just as well that I delayed my response, because it forced me to > think about your question a bit further, and to conclude that large strings > probably do not require fragmentation. Because string payload is immutable, > it's perfectly OK to use a distinct rearrangement strategy for the string > heap. You can safely move strings around in chunks, and simply defer the > update of the forwarding pointer until the move has completed. > > > > > > Yes immutability allows a few optimization’s even in .NET this is done ie > the CLR GC segregates strings in a separate heap ( separate from large > objects which are > 32K which are just done with malloc and tracked) this > is done since a GC doesn’t need to mark this space as there are no > references. Should immutable objects which have different behaviour to > mutable objects be also segregated ? . > It seems to me that any object that is (a) immutable and (b) untraced can effectively be placed in what is now considered the string heap. The space doesn't need to be marked or relocated, and it is subject to bounded-chunk compaction without regard to object size. The compaction strategy need not be naive. Objects that are immutable at the language level are not immutable at the runtime level. In particular, they are likely to contain references that require relocation after a relocating GC. So my guess is that immutable objects may not look as different at the GC level as you seem to imagine. But I don't know. The hidden assumption behind the large object allocator is that you won't run out of virtual address space in the large object heap. More precisely: you don't ever need to relocate at the physical page content layer, and compaction w.r.t. the virtual address map can be done using the MMU using a technique that is conceptually similar to the one I sketched for compacting the string heap. The curious consequence of this is that the only compactions that cannot be done in a real-time concurrent fashion are those for mid-sized objects. BTW thanks. This considerably relieves my concerns about having a non-chunked vector implementation. shap
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
