[bitc-dev] Choice of runtime/VM

[Jonathan S. Shapiro]

On Thu, Jul 29, 2010 at 2:34 AM, Ben Kloosterman <bklooste at gmail.com> wrote:
> re the summary , I would agree the bounds check is >  the GC  . I would not
> say its insignificant if you include the GC mark , sweep and compaction
> 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.

> What is worth discussing though is the write barrier .. used in most
> generational GCs. The cost of this is increasing the cost of memory heap
> writes...

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.

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
to another.

> The fact the guys at Mono (and MS) have spent years on GCs which slowly
> evolve makes me suspect it’s 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.

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
things hard.

> Yes I was considering the same but I kind of feel unless you have a decent
> runtime it’s hard to get tractions and decent means web calls , tcp  ,
> threading,  web apps , GUI apps , XML etc which is a monumental task and it
> 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.


shap