
Node.js on mozilla spidermonkey - franze
http://blog.zpao.com/post/4620873765/about-that-hybrid-v8monkey-engine/
======
FooBarWidget
Are people doing this just for fun or are there advantages in switching to
Spidermonkey?

~~~
bnoordhuis
V8 is a single-threaded VM and I don't see that changing any time soon, it's
very much married to Chrome's per-process model. SpiderMonkey doesn't have
that drawback, it supports threads just fine.

These guys have their work cut out for them if they want to support the V8 API
from within SM. It's a well designed API but large and fast moving.

Still, an interesting project. I'm going to watch it, maybe submit a few
patches.

~~~
udp
I had some problems with SpiderMonkey's thread safe mode. If you have your own
lock system, and you lock a resource while running JS, SM might do garbage
collection at _any time_ , for which it has its own lock. This causes deadlock
very quickly indeed.

I had to resort to having a pool of JS runtimes from which each thread would
borrow a runtime when it wanted to execute code, and return it when it was
finished. This got messy quickly when I found out that script objects can't be
shared, and I needed to load an individual copy of each script for each
runtime.

Furthermore, JS objects weren't able to be shared between threads even when I
didn't have separate runtimes, and I needed to (this was actually the
recommended approach) write them to a binary format using
JS_WriteStructuredClone when one thread was finished with them, and reassemble
them with JS_ReadStructuredClone on the other end.

In the end, I gave up trying to do multithreaded Javascript and went for a
nice, single threaded event driven model. I don't regret it. Heck, since it's
lock-free - and structured clone free - it's probably more scalable!

~~~
bnoordhuis
I hear you, threading in SM is indeed fraught with dangers.

On the off chance that you're going to revisit it, the way to go is to compile
with -DJS_THREADSAFE and register a callback with JS_SetGCCallback() that
tells the VM when it's safe to run the garbage collector.

Actually, the approach I took was to always tell the VM 'no' and invoke
JS_GC() manually from time to time. Conceptually easy and performance is
mostly amortized.

PS: Feel free to contact me if you have follow-up questions, my email is in my
profile.

------
skrebbel
I always wondered why Node.js is based on V8 in the first place; to my
(limited) experience, SpiderMonkey's API is both simpler in use and better
documented. Was it a speed thing in Node's early days?

Cool move, nevertheless. Sounds like a pain to maintain, though.

~~~
dspillett
> I always wondered why Node.js is based on V8 in the first place

Probably just a case of that engine being the one he was playing with at the
time (or had some/more experience with) so it was the one his experiment that
became node.js got implemented in.

A lot of implementation decisions get made this waym, especially with projects
that start out as an experiment or a proof of concept for a thought
experiment: if the list of reasons why _not_ to use the tool you currently
have in your hand are insignificant at the time, why mess around looking for
other tools to try as well?

Sometimes this means a project gets tied to a particular tool even though
another tool might offer some useful features, which is the case with the
current node.js implementation. In the grand scheme of things it may not
matter: is node.js suffering (or likely to suffer in future) because it is
tied V8? Would making node.js flexible about its JS engine add enough overhead
that it is undesirable? It is certainly worth experimenting with other JS
engines though, so they have answers to those questions (maybe is isn't worth
it, but now that is known for sure, and maybe it _is_ worth it and the
benefits of a change (or generalisation) can be demonstrated with real
examples).

------
robin_reala
I was wondering a few months ago why there wasn’t a Spidermonkey
implementation for Node; didn’t realise it was tied so tightly into V8. This
should be good.

