[wip] update to spidermonkey 17

[marianoguerra]

update erlang_js to use spidermonkey version 17 (latest published) and nspr 4.9.3 (required by this version of spidermonkey)

the current status is:

it builds, the examples in the readme run, test pass .... when it doesn't segfault.

also there are some notes on the changes that may need to be discussed.

it would be cool if you helped to try the pull request and help me troubleshoot the segfault, it seems to be when the vm is shutting down.

[marianoguerra]

I got a reply on the spidermonkey mailing list:

Multithreaded environments are no longer supported in SpiderMonkey. You'll need
to use a separate JSRuntime per thread.

can the erlang driver move a context between threads?

[marianoguerra]

from the erlang driver docs (http://www.erlang.org/doc/man/erl_driver.html):

In the runtime system with SMP support, drivers are locked either on driver level or port level (driver instance level). By default driver level locking will be used, i.e., only one emulator thread will execute code in the driver at a time. If port level locking is used, multiple emulator threads may execute code in the driver at the same time. There will only be one thread at a time calling driver call-backs corresponding to the same port, though.

Previously, in the runtime system without SMP support, specific driver call-backs were always called from the same thread. This is not the case in the runtime system with SMP support. Regardless of locking scheme used, calls to driver call-backs may be made from different threads, e.g., two consecutive calls to exactly the same call-back for exactly the same port may be made from two different threads. This will for most drivers not be a problem, but it might. Drivers that depend on all call-backs being called in the same thread, have to be rewritten before being used in the runtime system with SMP support.
Note

Regardless of locking scheme used, calls to driver call-backs may be made from different threads.

[tisba]

bump

is there any news on this? The currently used SpiderMonkey 1.8 is indeed pretty old, and even SpiderMonkey 17 is pretty outdated already with SpiderMonkey 24 (JavaScript 1.8.5) released last December. Is there anything on (Basho's) roadmap to catch up with those releases?

[marianoguerra]

@tisba I will see if I have time to update it to latest SpiderMonkey

[tisba]

@marianoguerra that would be great!

Disclaimer: I'm an Erlang newbe :) But...

I also found https://github.com/systra/erlang_js. I haven't looked into it, but maybe you can take a look. Especially the Jiffy JSON Parser looks far supirior in comparison to json2.js.

[lemenkov]

Ok, I've got it working (I believe). At least it passes tests now. My patch is just a slight modification of @marianoguerra 's one, adjusted to apply cleanly on top of my previous attempt to build against js185 (PR #32).

https://github.com/lemenkov/erlang_js/tree/fedora-1.3.0-mosjz17

I just wonder is there interest to continue this? I'm asking because maybe it's better to skip mozjs17 and build against more recent versions (24, 31, 38, 45):

https://developer.mozilla.org/docs/Mozilla/Projects/SpiderMonkey/Releases

[marianoguerra]

IIRC I tried updating to 24 back then and I had a problem where the external API was no longer pure C, can't remember exactly since it was 3 years ago :)

but if it's possible to move straight to 45 then better, if it works, passes tests and no merge happens we can keep a fork.

[lemenkov]

@marianoguerra I've just made it to compile / run / pass the tests against mozjs24

https://github.com/lemenkov/erlang_js/tree/test-mozjs24

Patches / suggestions / advices /critics are very much welcome!