Hi Andreas,

No, I haven't had time yet to look at the google code site for V8 (I'm
leaving early tomorrow morning on vacation), and as you may imagine they are
too busy to talk much right now.   I guess I should have said multi-process,
since I was referring to the ability to run many separate fully independent
processes from a shared VM, which probably translates to some form of
concurrency inside the VM.

But as I think you are pointing out, that isn't the same as JavaScript
in-language multi-threading or concurrency; I don't know of anything new
there.   If they wanted to do fancy concurrency, they certainly know how,
since we did all that for the JVM (unlike Strongtalk, which is still in
'yield' land), but of course that doesn't mean they did.  I believe Lars
will be giving a more detailed talk on the architecture at the JAOO
conference in Denmark on Sept 30th.

I guess to be more precise, I think the sort of multi-process architecture
they are using will be very well suited to apps that want to start, stop,
and isolate lots of VM instances compactly and quickly.  That sounds great
for servers, and desktops too, where each app can run (and maybe garbage
collect?) independently in lightweight VM instances.

To me, that sounds quite a bit more OS-like than existing VMs.  If each app
runs in a different process, then they can't block each other during i/o or
callouts (or whatever the plugin equivalent is), and they will be run
concurrently on multi-core processors, which are capabilities I normally
associate with a multi-threaded VM.  But data sharing and communication is
another matter, and I don't have an answer there.

There's going to be a lot to find out!
-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
>
> David Griswold wrote:
>
>> A little more info on V8.
>>
>> I talked briefly with Lars Bak and Robert Griesemer today, (both are on
>> the V8 team, and Lars is the lead) and got a little bit of their perspective
>> on using V8 for other languages.  As was to be expected, the VM is targeted
>> to JavaScript semantics, and given the gnarliness of those semantics, there
>> are a few caveats to think about.
>>
>>    * V8 will get faster as it matures, of course, however:
>>    * There will be issues around things like immediate object
>>      semantics, which don't exactly match up with any other language.
>>  Yucky JavaScript!
>>    * A bigger long-term performance issue is that given the dynamic
>>      nature of JavaScript objects (i.e. adding/removing slots on the
>>      fly) there apparently isn't any way around adding an additional
>>      indirection to deal with the object size changing dynamically.
>>  That is something that will just have to be lived with.  I was
>>      hoping they had some magic there, but apparently not.
>>
>> I'm sure that these sorts of things can be worked around, but they do mean
>> that V8 will never in its pure form quite reach the pinnacle of theoretical
>> performance possible for a VM targeted specifically to Smalltalk etc.  So it
>> won't be as fast as Strongtalk, although it may get fairly close to
>> VisualWorks performance.
>>
>> Nonetheless, I still think it or some derivative will quickly become the
>> dominant dynamic language VM, for the following reasons:
>>
>>    * Given who the developers are, and with Google behind it, it will
>>      be the fastest JavaScript VM for a long time to come.
>>    * For the same reason, it will be reliable and secure (as much as it
>>      can be, anyway; nothing is perfect).
>>    * It will be supported on the three major platforms (Windows, Linux,
>>      Mac).    * It can be used with other browsers, so I'm sure it will be
>> ported
>>      to Firefox (if only as an option).  Some or all of the other
>>      browsers may also adopt it, given that it will have a very
>>      hard-to-overcome performance advantage (these sorts of VMs can't
>>      be pulled out of a hat).  Although MS and maybe Safari may have
>>      too much of a Not Invented Here problem with it, as well as
>>      standards war issues.
>>    * those things, plus the other architectural advantages it brings,
>>      will make it a primary target for serious web app development,
>>      esp. Google apps.
>>    * So it will be ubiquitous
>>
>> So it will be an irresistible platform for other dynamic languages, even
>> if they could theoretically run a bit faster on a custom VM.  Remember it
>> will still be a lot easier to run other dynamic languages on JavaScript than
>> it is to run them on Java, since at least JavaScript is fully dynamic,
>> unlike Java.
>>
>> And remember, the bottom line is that it is a clean, supported,
>> state-of-the-art multi-threaded design that is fully open-source.  So as a
>> last resort, there is always FORK!
>>
>> -Dave
>>
>>
>> ------------------------------------------------------------------------
>>
>>
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20080902/d1f8bb2a/attachment.htm