On Thu, Mar 17, 2011 at 7:53 PM, Ben Kloosterman <[email protected]> wrote:
> > > *From:* [email protected] [mailto:[email protected]] > *On Behalf Of *Jonathan S. Shapiro > *Sent:* Friday, March 18, 2011 2:33 AM > *To:* [email protected]; Discussions about the BitC language > *Subject:* Re: [bitc-dev] String encoding, again > > > > On Wed, Mar 16, 2011 at 8:52 PM, Ben Kloosterman <[email protected]> > wrote: > > One Q on large strings , since strings are immutable and cant contain > pointers ( like images) why not put large ones on the OS heap with malloc. . > Since they cant have references you can easily check when they have no > references in a mark. > > > Because the mark phase isn't the problem. The problem is the compact phase. > The reason that you need strings and vectors to have a bounded chunk size is > so that you have an upper bound on the most expensive interlocked unit of > operation that is performed by the compact engine. > > > > 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. 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. shap
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
