Deleting V8 bindings (was Cleaning House)

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

Deleting V8 bindings (was Cleaning House)

Ryosuke Niwa-2
On Thu, Apr 4, 2013 at 7:08 PM, Maciej Stachowiak <[hidden email]> wrote:
On Apr 4, 2013, at 4:54 PM, Per Bothner <[hidden email]> wrote:
On 04/04/2013 10:21 AM, Oliver Hunt wrote:
Supporting V8 places a considerable burden on webkit, there are a number of
large, cumbersome and expensive abstractions required for to support multiple
JS engines (see the original discussions on the topic from many years ago).

We at Oracle are working on using WebKit with our own JavaScript engine,
Nashorn: http://openjdk.java.net/projects/nashorn/
This is for the WebView component of JavaFX:
http://docs.oracle.com/javafx/2/api/javafx/scene/web/package-summary.html

This is still experimental, and no committed deliverable.  However,
it is obviously preferable in the eat-your-own-dogfood way that we
use our own JavaScript engine, especially once that engine becomes
part of the Java distribution.

This is still in pretty rough shape, but we would find it
unfortunate if if becomes more difficult to build WebKit
with an alternative JavaScript engine.  For the Nashorn "port",
I created a new WebCore/bindings/nashorn directory in
parallel to WebCore/bindings/js and WebCore/bindings/v8.
We generate .java class from the .idl file.  No "JavaScript
classes" are ever created.  Instead Nashorn provides an
on-the-fly bridge to the Java objects.

I think we'd be pretty reluctant to support this. Supporting multiple JS engines has been a pain, and we only agreed to it because it was a showstopper for Google, and we had the expectation that Google would be a valuable high-volume contributor. Which they were, during their time in the WebKit project. Even so, it caused significant code complexity, divergence of efforts, and friction on architectural direction, because of the differing characteristics of JSC and V8.

I'm with Maciej and others.  There is a huge opportunity in front us to improve the performance of WebKit by making more aggressive architectural changes if we only had to worry about one JS engine.

On the other hand, I don't think optimizing WebCore for JSC doesn't necessarily mean it'll become impossible for you to have a custom build of WebKit that uses some other binding code.  For example, Mac has Objective-C bindings and that's not going anywhere in the foreseeable future.

- R. Niwa


_______________________________________________
webkit-dev mailing list
[hidden email]
https://lists.webkit.org/mailman/listinfo/webkit-dev
Reply | Threaded
Open this post in threaded view
|

Re: Deleting V8 bindings (was Cleaning House)

Per Bothner-5
On 04/04/2013 09:14 PM, Ryosuke Niwa wrote:
> On the other hand, I don't think optimizing WebCore for JSC doesn't
> necessarily mean it'll become impossible for you to have a custom build
> of WebKit that uses some other binding code.  For example, Mac has
> Objective-C bindings and that's not going anywhere in the foreseeable
> future.

True, but Objective-C bindings are *in addition* to JSC.
Our use of Nashorn *replaces* JSC.

Still, we can certainly have local changes in the code-base,
like we currently do.  My worry is about the places the code
hard-wires in an assumption on JSC - if those proliferate
it will complicate us keeping updated with WebKit.

I can see the logic for simplifying, and I'm not asking you
to support an alternative JavaScript engine where it
complicates the code.  Just please keep in mind there are people
who use WebKit *without* JSC.
--
        --Per Bothner
[hidden email]   [hidden email]   http://per.bothner.com/
_______________________________________________
webkit-dev mailing list
[hidden email]
https://lists.webkit.org/mailman/listinfo/webkit-dev
Reply | Threaded
Open this post in threaded view
|

Re: Deleting V8 bindings (was Cleaning House)

Oliver Hunt-2
There are plenty of other bindings - Gtk has a set of dom bindings i believe, there used to be COM (shudder) bindings as well, but those aren't the problem.  We could have as many binding languages as we want, there's no major architectural reason not to.

But supporting javascript isn't simply a matter of another binding.  The complexity comes from javascript being the internal scripting language used by webcore for script tags, etc.  It's that complexity that creates the need for massive abstraction when supporting multiple distinct JS engines.  There is simply no way to support multiple JS engines without retaining the current abstraction - the fact that it's currently only present in order to support the existence of V8 isn't relevant - the same machinery would be necessary to support _any_ other JS engine in addition to JSC.

There is strictly no advantage to WebKit in keeping that machinery, it is purely performance and opportunity cost.  You need an _extremely_ compelling argument to outweigh those costs.

--Oliver

On Apr 4, 2013, at 11:15 PM, Per Bothner <[hidden email]> wrote:

> On 04/04/2013 09:14 PM, Ryosuke Niwa wrote:
>> On the other hand, I don't think optimizing WebCore for JSC doesn't
>> necessarily mean it'll become impossible for you to have a custom build
>> of WebKit that uses some other binding code.  For example, Mac has
>> Objective-C bindings and that's not going anywhere in the foreseeable
>> future.
>
> True, but Objective-C bindings are *in addition* to JSC.
> Our use of Nashorn *replaces* JSC.
>
> Still, we can certainly have local changes in the code-base,
> like we currently do.  My worry is about the places the code
> hard-wires in an assumption on JSC - if those proliferate
> it will complicate us keeping updated with WebKit.
>
> I can see the logic for simplifying, and I'm not asking you
> to support an alternative JavaScript engine where it
> complicates the code.  Just please keep in mind there are people
> who use WebKit *without* JSC.
> --
> --Per Bothner
> [hidden email]   [hidden email]   http://per.bothner.com/
> _______________________________________________
> webkit-dev mailing list
> [hidden email]
> https://lists.webkit.org/mailman/listinfo/webkit-dev

_______________________________________________
webkit-dev mailing list
[hidden email]
https://lists.webkit.org/mailman/listinfo/webkit-dev