[squeak-dev] Re: Using V8 for other languages

karl ramberg karlramberg at gmail.com
Wed Sep 3 13:27:53 UTC 2008


I read about the new IE8 from microsoft that they start a new thread
per tab etc and that it was using more threads and memory than
WindowsXP. It was ok on multiprocessor machines but a pig on single
cpu.

karl

On 9/3/08, David Griswold <david.griswold.256 at gmail.com> wrote:
> 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
>>>
>>>
>>> ------------------------------------------------------------------------
>>>
>>>
>>>
>>
>>
>



More information about the Squeak-dev mailing list