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. Statically allocated strings can be handled as an exception by pre-positioning them in a non-compacted constant data section at compile time, but that doesn't alter the general issue. > Ignore UCS sizes for a moment; if you create a 64Kbyte string, you're > basically *done* talking about interactive pause times (because of copy > delays). So even if the unit size is uniform, a large string must be made of > chunks. > > > > > > You still need to handle image blobs … > That's really not clear. The only place where it is *essentially* true is when you do low-level composite buffer interactions, and in those cases you're stepping out of the GC memory model in a very fundamental way. > I'm very hesitant about using static typing too heavily here. Strings are > processed in lots and lots of places, and having all of that code > proliferate in replacted form seems potentially very unhealthy. > > > > Are you stating it would stress the type system .. optimizations would > remove the unused code..and the libs will mostly use a single piece of > string code. > In the absence of runtime or whole-program optimization (both of which I like, but reject as assumptions in design), neither statement is true. What will instead happen is that every bit of code that touches a string will get replicated for every case. We need a better API than we've got to this point in the discussion. I think I know what it looks like, and I'll send it out in a few minutes - need to process the email backlog and reboot first. shap
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
