That doesn't answer why to not create them from the system memory manager and not compact / move...
Sorry - I somehow failed to answer this before. Not at all sure why. What you are basically proposing is to have a distinguished string heap. Whether it lives in system memory or not is actually not the issue. What will happen if you do not compact this heap is that it will fragment in the usual way, and at some point you will be forced to do something about that. No difference to the way its done now in C . Buddy allocation does a pretty good job for large objects. 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 ? . Ben
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
