[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
|