After sleeping on it, I woke up and realized that V8 is almost certainly not
multi-threaded at the client code level (within a single VM instance), since
they have that indirection... the indirection sounds more like a traditional
object table, like VisualWorks, and I don't see how they could possibly have
made something like that multi-threaded since performance would critically
depend on caching the body pointer within a method activation.  But they
can't do that because another method might be adding or removing properties
while the method is running, and that is way too fine-grained to be doing
any kind of check.

Having an object-table indirection isn't as bad for performance as it sounds
because you can cache the body pointer within a method activation, which I
seem to remember L. Peter Deutsch pointing out a long time ago.   But if the
average method is very small it will have very few instvar/property
accesses, which reduces the effectiveness of the caching (although if there
are *no* property accesses you can skip the indirection altogether, which
helps compensate).   So that is something that can benefit tremendously from
inlining à la Strongtalk, which merges activations and thus increases the
possible scope of the cached pointer.  But if they are not inlining, the
performance sounds like it would be more restricted to a sort of VisualWorks
kind of range (which of course is not bad, but wouldn't threaten
Strongtalk).

Plus, the additional word for the indirection is one more word of overhead
in the header, so I don't see how they could get less than a two word
header.  I thought Lars told me it was one word, but I don't see how they
could do that; maybe he wasn't counting the indirection as part of the
header.
-Dave

On Tue, Sep 2, 2008 at 11:15 PM, Andreas Raab <andreas.raab at gmx.de> wrote:

> > state-of-the-art multi-threaded design
>
> Can you say more about this? I can't find any information about V8's thread
> handling and concurrency options.
>
> Cheers,
>  - Andreas
>
> [...]
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20080903/0c7e0483/attachment.htm