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. The GC only roll should be to track and then when there is no references to request the memory to be released. 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. It was just stated that type classes also prevent inlining ( probably can be overcome with another pass though ? ) and that is too big a sacrifice anyway.. Ben
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
