[webkit-dev] WebKit branch to support multiple VMs (e.g., Dart)

[Anton Muhin]

Good day, Zoltan,

On Tue, Dec 6, 2011 at 1:23 PM, Zoltan Herczeg <zherczeg at inf.u-szeged.hu> wrote:
> Hi Anton,
>
>> Of course, we're doing this because of our work on Dart, but our
>> intent was to solicit a feedback from the WebKit community if there is
>> any interest in supporting runtimes additional to JS (and not JS +
>> Dart) in the first place.
>
> The question they raised was what we need to sacrifice for this support.
> JS is heavily tied with WK internals, lots of JS specific things
> everywhere (yeah, you can change the JS engine in WK, but only to another
> JS engine). Change that to something general affects maintenance (new
> abstraction layers / API) and performance (probably memory as well), and
> its drawbacks are unknown yet (and its advantages are questionable),
> especially in a mixed environment.

I absolutely share this concern.  We really hope (and hopefully patch
proves it), that as of now, burden is minimal: outside of bindings, we
only touch a handful of stuff:

1) Source/WebCore/dom/ScriptElement.cpp: to tag ScriptSourceCode with
mimetype (+10 trivial lines imho)
2) and changes in inspector.  AFAIK, some of them are beneficial on
its own, while others are more related with devtools support for other
languages (Objective-C dev tools anyone :).

And no full fledged abstraction levels, just a couple of reasonable (I
am biased, I know) interfaces.

And we did preliminary experiments on perf impact and found no perf
implications for mutli-vm patch by itself.

I don't want to say we have no burden, any change has, but if there is
a minimal merit in multi-vm support, I believe the burden is minimal
enough.

>
> I think you should start this work in a private branch (code.google.com?)
> and tell us your experiences later. It is difficult to judge this feature
> at the moment.

What would you recommend as a measure of success?  Something we can
report back and ask if we're ready?

We're definitely considering hosting the work in some other place and
have no technical difficulties with this.  We just want to be as close
to the WebKit community as possible.

Thanks again for your thoughts,
anton.