Using V8 for other languages

[David Griswold]

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

[David Griswold]

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 <andrea...@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

------------------------------------------------------------------------

[pako]

It's generally a good idea to pick some external VM and built on top
of it - less work, more power, more compatibility with other
languages.
But using VM desgined with one language in mind - there should be
strong reasons for that.
How about Parrot VM? Dynamic languages designers is their target
audience.
And V8 is (for now) aimed at browser developers only.

[Alejandro F. Reimondo]

Hi,

> It's generally a good idea to pick some external VM and built on top
> of it - less work, more power, more compatibility with other
> languages.

When you build on top of some architecture you must consider
obsolescence factors.
From Java up today, all platforms has been discarded
and speed of changes has been increased in the last decade.
The recent history confirm that it will continue happening.

IMHO, a better idea is to do not have a VM;
e.g. make all operations requiered to build aplications
in practice (and not in "abstract") manageable by the system itself
(the system modeled in OO way or not... the same applies).

Changing to another semantics can be good for someone
that think that he has nothing to loose (e.g. someone too young
in the industry); or for someone with very "special" needs;
it si not something good to promote for "all the word"
(as was done repeatedly by M$ and other recent companies
selling that something will happen this year :)

In practice, using well known semantics (e.g. smalltalk semantics)
let companies do not loose investment in education (new
companies and companies that use resources of others
do not have possibility to loose, and has the freedom
to try and waste one to 5 years, upto the next version
of a new "refactored" concept :-)

Returning to the no-VM proposal...
Smalltalk is not a LOO, and it is not a VM design,
it is a system that can be changed at any place
(identity is preserved, Smalltalk is NOT it's contents
at a point in time; it is the flow of contents in a sustainable
system through time and guided by external actions
-e.g. human actions-)

In the past, most architectures supporting smalltalk systems
was designed minimizing the primitive operations
but the VM itself was implemented outside (unmanegeable by)
the system because dynamic generation of low-level behavior
was not possible.
Today, there is more power for dynamic generation
of low-level efficient code; and exists the posibility
to reduce the (Smalltalk)VM to minimal expression,
putting most of the operations relegated to the VM
in the past as responsibility of objects in the system.

e.g. It was frecuent, in smalltalk that lookUp and
evaluate operations was solved in one stage as one VM
operation and objects can´t refine/change the VM behavior.
In recent object models desings[*], new implementations
of object architectures where basic operations (responsibility
of "the VM" in the past) managed by objects in the system
are emerging; we have the posibility to extend/refine/change
any basic behavior WITHOUT loosing robust tools
for systems development...

If we do a good work from any Smalltalk platform
removing the VM as much as possible, it will continue
been a Smalltalk and companies that have invested a lot
in the past, promoting and using smalltalk, will not be
forced to return to languages... (nor move to
"scripting" languages)

I know that the paragraphs put here can be void for
someone young (focused in his/her future and not
in what he/she has already done), but I also know that
not all people/companies are happy about loosing their
investments... again.

w/best regards,
Ale.

p.d.: I have copied to Smalltalking list because we use
to talk about this topics, but in Spanish; and I am interested
in reflecting about how we feel when "new" alternatives
are proposed for all-the-world ignoring peculiarities
of people using marginal development alternatives as Smalltalk.

[*] See objectsAsMethods proposal for Squeak (1999?)
available at current Squeak implementation and Moebius
project ( http://groups.google.com/group/moebius-project-discussion?hl=en )

[John Cowan]

On Wed, Sep 3, 2008 at 2:55 AM, David Griswold
<david.gri...@gmail.com> wrote:

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

(Disclaimer: I work for Google, but have no inside information about
Chrome or V8.)

As I understand it, each tab (and a fortiori each window, with some
exceptions) is a separate OS-level process, and shares nothing except
the code segment and, transparently, any COW data that may exist under
operating systems that support it. Consequently, there is no reason
for V8 to do anything special for concurrency, as the only concurrency
present is that needed for timers etc. I don't know whether the
in-memory page cache is shared or not.

> There's going to be a lot to find out!

Indeed.

--
GMail doesn't have rotating .sigs, but you can see mine at
http://www.ccil.org/~cowan/signatures

[pako]

> If we do a good work from any Smalltalk platform
>  removing the VM as much as possible, it will continue
>  been a Smalltalk and companies that have invested a lot
>  in the past, promoting and using smalltalk, will not be
>  forced to return to languages... (nor move to
>  "scripting" languages)

We probably have different opinions on what VM is and what
architecture constraints it introduces.
To me "removing the VM" is like removing crossplatform 3d rendering
and audio engines from a long living 3d-action game.

Whatever your approach (to VM or not to VM) you will still have a
platform independent layer and OS specific interfaces.
You will have some code for threading support and garbage collection,
etc. Does that really matter for some company where that code
originates from - was it written by the strongtalk team or was
implemented by some opensource VM community?
As long as interface doesn't change - what's the difference? Nobody
will be forced to "return to languages"/"move to scripting languages"
(I probably don't understand your thoughts at all, but I respond to
what I've actually read)

> I know that the paragraphs put here can be void for
>  someone young (focused in his/her future and not
>  in what he/she has already done), but I also know that
>  not all people/companies are happy about loosing their
>  investments... again.

So, some things "already done" will be lost.

But there is always a trade off.
Suppose I have a working implementation and decide to start utilizing
some platform:
I have to learn that new thing
I have to throw some my low level code away and rewrite/refactor a lot
to use the external VM

Yep, that's bad.
But will I probably gain anything?
A huge community that develops new features, adds optimizations, ports
to different OSes, tests "your" code there.
In order for the language implementation to be successful a lot of
work has to be done.
Does strongtalk has that many contributors? I actually don't see them
in this mailing list.

It is not so obvious what's better. But it seems to me that strongtalk
team has to do something to get project popular, to get many features
and users. At least to get linux and macos ports binaries at the
downloads page.

And "outsourcing" some code is among the solutions to consider.