On Mon, Oct 14, 2013 at 9:30 AM, david j <[email protected]> wrote: > Sorry, when I say "non allocating threads" I don't mean threads that never > allocate, I mean threads that are not allocating *right now*. > > In other words, I'm fine if there is some kind of concurrency dependence > between two threads that call malloc, but other threads not calling malloc > should be (mostly) unaffected. This is the world-stop problem that makes GC > so much harder to use than malloc/free for soft-real-time interactive -- > *regardles* of overhead. >
OK. That makes more sense, and it's a reasonable goal. I think the "world stop" designs are increasingly a thing of the past, by the way. > 2) alloc/dealloc overhead (more) proportional to rate and memory >>> overhead, not total heap size >>> >> Proportional to rate of *what*? >> > > Alloc/dealloc rate, i.e. churn rate. (especially tenured churn) > But part of the problem is that we don't *know* the dealloc rate. Is it sufficient to be proportional to the alloc rate and the *mutate* rate? > >> I don't think that "proportional" is what you mean to say. If we define >> the overhead as "100 ms per 100Mbytes allocated", then a system that >> allocates 10 gigabytes between 10 second pauses meets the specification. >> > > The word "pause" here is dangerous, as it implies something happening to > other threads, which I've said in #1 is really bad. > That is definitely not what I intend it to mean, and it is not the accepted meaning in the literature. But for clarity, let me offer the pompous opinion that anybody doing multithreaded programming who *isn't* using a thread-local allocator is making a mistake. > Honestly, if a thread which churns 100Mbytes pays 10ms in cost to the > allocator, I can deal with that. What I have trouble dealing with is when > that cost overflows into other threads, or occurs outside of the > malloc/free calls. This is part of why RC is attractive, and why it's > become the second-most-dominant allocation scheme for interactive > client-side software (COM, iOS, etc), the first being manual malloc/free. > I don't buy that, mainly because the use of RC is orthogonal to the problem of cross-thread interactions. I do agree that cross-thread interactions are things worth avoiding. shap
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
