[bitc-dev] Choice of runtime/VM
bklooste at gmail.com
Sat Jul 31 01:02:44 PDT 2010
>> re the summary , I would agree the bounds check is > the GC . I
>> say its insignificant if you include the GC mark , sweep and
>> costs ( which a lot of benchmarks leave out)...
>I can't say that I have ever seen such a mis-reported benchmark
>published. In the end, there are only two times that matter:
>1. The total time to execute the application under realistic
>conditions, including any and all GC costs
>2. The mean and standard deviation of the GC-associated pause times.
I completely agree ( and most paper are good in this area) and 1. is
diminishing with concurrent GCs .
My comment was for all those "language shoot outs" and micro benches.
These can be so rigged by an environment by allocating slabs of memory and
not collecting till the app finishes etc.
>> What is worth discussing though is the write barrier .. used in most
>> generational GCs. The cost of this is increasing the cost of memory
>Yes. It's an issue. If you have a fast syscall path you can make very
>effective use of the OS-level dirty bits and avoid an explicit write
>barrier entirely. They do this in CLR on Windows, for example. It's a
>very old technique. The problem is that it isn't fine grain, and you
>are forced to scan old space a page at a time. On a microkernel I
>might even consider implementing a variant of that idea by reflecting
>page faults to a scheduler activation handler.
>But it also should be said that the cost of the write barrier depends
>a lot on the processor. On multi-issue machines, a lot of that
>overhead disappears into the out of order issue behavior. And of
>course, many writes are performed during initialization between sync
>points, and no checks are required for objects that are known to have
>been allocated in a single generation.
Yes even on single core a lot of this write can be moved around to be no
cost.. Except in the cases of those language shootouts like the Seive which
just blasts out writes and is hence unrealistic.
>But I agree with the main point you are making: there is no universal
>GC, and techniques appropriate to one platform may not be appropriate
Can you discuss how far MS got in this area ? I note Singularity had 7 CGs ,
I figure Midor must have looked at it more.
>> The fact the guys at Mono (and MS) have spent years on GCs which
>> evolve makes me suspect its a much harder problem bolting in a GC...
>I don't know what the story is for Mono, but from the outside it looks
>to me like they are suffering from the early decision to adopt a
>conservative collector. This is one of those cases where doing the
>easy thing initially let them off the hook on a bunch of code
>generation design issues that they now have to rework. The problem may
>not be so much the complexity of the GC as the complexity of replacing
>a code generator that never had to deal with root sets and barriers.
>That being said, even now their attempts at a precise GC look pretty
>amateurish - considerably less there than David Ungar wast doing
>almost 20 years ago.
And they have had 3 bods for 3 years on that new Gen GC.
>But in fairness, we should acknowledge that they have a much harder
>problem, because they need to deal with uncooperative native code, and
>that's undeniably hard. In fact, let me come back to that in another
>subject thread in a moment.
>As to CLR, a lot of that work was done by Bjarne Steensgaard. There
>are various things in the Windows environment that conspire to make
>> Yes I was considering the same but I kind of feel unless you have a
>> runtime its hard to get tractions and decent means web calls , tcp ,
>> threading, web apps , GUI apps , XML etc which is a monumental task
>> is not so simple as creating native wrappers...
>Hang on. This isn't language runtime you are talking about. It's OS
>ecosystem and native code interface. Which is an important question,
>but not the one that I initially took you to be asking.
Yes , using Java and .NET for 10 years I tend to think of the stdlib a bit
more than I used to in C..Though I lament that core lib cant be used without
More information about the bitc-dev