NativeScript
Use the newly added Webkit's LLInt ASM interpreter without enabling the JIT
Hi, Just wanted to share with you that following a discussion in WebKit's mailing list, and thanks to @Constellation, WebKit now supports using LLInt ASM interpreter without enabling the JIT.
This is great, as it should improve compilation time and binary size for NativeScript's iOS Runtime. I haven't tested it in node-jsc yet so I can't tell you by how much.
Koby
Thanks a lot, @MCE-KobyBo! We can try and see how it will work out in {N} when we find time for it.
We tend upgrade only to official WebKit tags so we'll have to wait for it to be released officially in order to upgrade to it. But we can definitely experiment with the master branch when we find the resources for that! Hopefully it will make a difference in size and/or performance!
BTW I think that you might find our WebKit upgrade procedure useful. You can take a look if you like. Also any thoughts or suggestions that you may have will be more than welcome.
That seems great, I really need a more defined procedure for upgrading node-jsc's webkit. The way I've been working so far (and need to properly define) is to have my own Webkit fork, like NativeScript, and every once in a while just merge upstream (master branch) changes to my fork. In node-jsc's repo I follow node's method, which is basically copying the engine's source code to it's repo, and update it\cherry pick changes when wanted\needed.
BTW, I've also made some changes\additions to WebKit, which you also seem to have done. I've started the process of sending my patches back to WebKit, and WebKit's developers have been really welcoming so far. I don't know if you've tried it, but hopefully merging as much of our changes as possible back to WebKit will make this process easier (and share our work with WebKit) :)
That's nice. It's good to know that they're open for outside contributions.
We haven't tried sending patches upstream, to some extend for historical reasons, and to some because we think that some of the changes don't seem to be meaningful for the project, outside of the {N} context. There are even changes in the inspector that are related to crashes and malfunction that we don't understand why we had to make them in the first place and why haven't they caused problems in the original WebKit builds.
But definitely it's worth to try and contribute back whenever we face the need for the next modification in WebKit.