[webkit-dev] node-jsc: A node.js port to the JavaScriptCore engine and iOS

Fri Sep 21 22:35:53 PDT 2018

On Sun, Sep 16, 2018 at 6:09 PM Koby Boyango <koby.b at mce.systems> wrote:

> Thanks for taking the time to look into the project :)
>
> Filip - I would love to. Should I create one bug for all of the patches,
> or a bug for each patch?
> Also, there is an existing bug that I've reported a while ago, but worked
> around it for now: https://bugs.webkit.org/show_bug.cgi?id=184232. It
> isn't relevant in newer versions of node (it came from node's Buffer
> constructor, which have changed since), but I'll still be happy to send a
> patch if needed.
>
> Yusuke - It's interesting to compare, especially on an iOS device. I will
> also try to do some measurements :) Do you have a benchmark you recommend?
> But assuming it is worth it, enabling LLInt ASM without the JIT would be
> great as it would probably reduce the binary size and compilation time by
> quite a bit.
> NativeScript is also using it without the JIT (and they link to an article
> containing some benchmarks), so they would profit from this too.
>
> https://github.com/NativeScript/ios-runtime/commit/1528ed50f85998147b190c22a390b5eca36c5acb
>

Actually, LLInt ASM interpreter shows 15% performance win in Kraken
benchmark[1].
Based on this fact, I've just enabled LLInt ASM interpreter when using
`ENABLE_JIT=OFF` for x64 and ARM64 environments[2].

[1]:
https://lists.webkit.org/pipermail/webkit-dev/2018-September/030157.html
[2]: https://trac.webkit.org/r236381

>
>
> Koby
>
> On Sat, Sep 15, 2018 at 2:51 AM Yusuke Suzuki <yusukesuzuki at slowstart.org>
> wrote:
>
>> Really great!
>>
>> node-jsc sounds very exciting to me. From the users' view, t is nice if
>> we run app constructed in node.js manner in iOS devices.
>> In addition, from the JSC developers' view, it is also awesome. It allows
>> us to easily run node.js libraries / benchmarks / tests on JSC, which is
>> really great since,
>>
>> 1. We can run tests designed for node.js, it makes our JSC implementation
>> more solid.
>> 2. We can run benchmarks designed for node.js including JS libraries. JS
>> libraries distributed in npm are more and more used in both node.js and
>> browser world.
>> If we can have a way to run benchmarks in popular libraries on JSC
>> easily, that offers great opportunities to optimize JSC on them.
>>
>> On Sat, Sep 15, 2018 at 5:20 AM Filip Pizlo <fpizlo at apple.com> wrote:
>>
>>> Wow!  That’s pretty cool!
>>>
>>> I think that it would be great for this to be upstreamed. Can you create
>>> a bug on bugs.webkit.org and post your patches for review?
>>>
>>> -Filip
>>>
>>> On Sep 13, 2018, at 4:02 PM, Koby Boyango <koby.b at mce.systems> wrote:
>>>
>>> Hi,
>>>
>>> I'm Koby Boyango, a senior researcher and developer at mce, and I've
>>> created node-jsc <https://github.com/mceSystems/node-jsc>, an
>>> experimental port of node.js to the JavaScriptCore engine and iOS
>>> specifically.
>>>
>>> node-jsc's core component, "jscshim" (deps/jscshim)
>>> <https://github.com/mceSystems/node-jsc/tree/master/deps/jscshim>,
>>> implements (parts of) v8 API on top of JavaScriptCore. It contains a
>>> stripped down version of WebKit's source code (mainly JSC and WTF). To
>>> build WebKit, I'm using CMake to build the JSCOnly port, with JSC\WTF
>>> compiled as static libraries. For iOS I'm using my own build script
>>> <https://github.com/mceSystems/node-jsc/blob/master/deps/jscshim/tools/build_jsc.py>
>>> with a custom toolchain file
>>> <https://github.com/mceSystems/node-jsc/blob/master/deps/jscshim/tools/ios.toolchain.cmake>.
>>>
>>>
>>> I'm really happy to hear that your node-jsc is using JSCOnly ports :)
>>
>>> The project also includes node-native-script
>>> <https://github.com/mceSystems/node-native-script>, NativeScript's iOS
>>> runtime refactored as node-jsc native module, allowing access to native iOS
>>> APIs directly from javascript.
>>>
>>> So first of all, I wanted to share this project with the WebKit
>>> developer community.
>>> It's my first time working with WebKit, and node-jsc has been a great
>>> opportunity to experiment with it.
>>>
>>> Second, as I needed to make some minor changes\additions, I'm using my
>>> own fork <https://github.com/mceSystems/webkit>. I would love to
>>> discuss some of the changes I've made, and offer some patches if you'll
>>> find them useful.
>>> "WebKit Fork and Compilation
>>> <https://github.com/mceSystems/node-jsc/blob/master/deps/jscshim/docs/webkit_fork_and_compilation.md>"
>>> describes WebKit's usage in node-jsc and the major changes\additions I've
>>> made in my fork (node-jsc's README
>>> <https://github.com/mceSystems/node-jsc/blob/master/README.md> and jschim's
>>> documentation
>>> <https://github.com/mceSystems/node-jsc/blob/master/deps/jscshim/docs/jscshim.md>
>>> contains some more information).
>>>
>>> Great, it is really nice if you have a patch for upstream :)
>> Looking through the documents, I have one question on LLInt v.s. CLoop.
>>
>>
>> https://github.com/mceSystems/node-jsc/blob/master/deps/jscshim/docs/webkit_fork_and_compilation.md#webkit-port-and-compilation
>> > Use the optimized assembly version of LLInt (JSC's interpreter), not
>> cloop. This requires enabling JIT support, although we won't be using the
>> JIT (but we can omit the FTL jit).
>>
>> I would like to know how fast LLInt ASM interpreter is when comparing
>> CLoop interpreter.
>> If it shows nice speedup, enabling LLInt ASM interpreter without JIT for
>> major architectures (x64, ARM64) sounds nice.
>> As a bonus, if we offer this build configuration (using LLInt ASM
>> interpreter without JIT), we can enable SamplingProfiler for this, which is
>> disabled for CLoop builds.
>>
>> Personally, I'm also interested in this thing. I'll set up the
>> environment to measure it later too :)
>>
>>
>>> Besides that, I will appreciate any opinions\ideas\insights\suggestions
>>> :)
>>>
>>>
>>
>>
>>
>>
>>
>>> Koby
>>>
>>> _______________________________________________
>>> webkit-dev mailing list
>>> webkit-dev at lists.webkit.org
>>> https://lists.webkit.org/mailman/listinfo/webkit-dev
>>>
>>> _______________________________________________
>>> webkit-dev mailing list
>>> webkit-dev at lists.webkit.org
>>> https://lists.webkit.org/mailman/listinfo/webkit-dev
>>>
>>

-- 
Best regards,
Yusuke Suzuki
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20180922/03e64ca1/attachment.html>