<html><head>
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
</head><body bgcolor="#FFFFFF" text="#000000">
<blockquote style="border: 0px none;"
cite="mid:CAJTgH0n0t4rVDqCb6TuZKpjm1q2eHCASb9kUsMeEC1G65ZuFRw@mail.gmail.com"
type="cite">
<div style="margin:30px 25px 10px 25px;" class="__pbConvHr"><div
style="width:100%;border-top:2px solid #EDF1F4;padding-top:10px;"> <div
style="display:inline-block;white-space:nowrap;vertical-align:middle;width:49%;">
<a moz-do-not-send="true" href="mailto:gps@mozilla.com"
style="color:#485664
!important;padding-right:6px;font-weight:500;text-decoration:none
!important;">Gregory Szorc</a></div> <div
style="display:inline-block;white-space:nowrap;vertical-align:middle;width:48%;text-align:
right;"> <font color="#909AA4"><span style="padding-left:6px">2016
December 13 at 22:36</span></font></div> </div></div>
</blockquote>
<blockquote style="border: 0px none;"
cite="mid:CAJTgH0n0t4rVDqCb6TuZKpjm1q2eHCASb9kUsMeEC1G65ZuFRw@mail.gmail.com"
type="cite">
<div style="color: rgb(144, 154, 164); margin-left: 24px;
margin-right: 24px;" __pbrmquotes="true" class="__pbConvBody">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">As a build system maintainer, I have a
few more questions:<br><br></div>
<div class="gmail_quote">* Do we need to compile Node and libuv as part
of the build? If so, how will that impact build times?<br></div></div>
</div>
</div>
</blockquote>
Yes, we would need to compile Node and libuv (along with other libraries
that Node entrains) as part of the build, which would increase build
times.<br>
<br>
<blockquote style="border: 0px none;"
cite="mid:CAJTgH0n0t4rVDqCb6TuZKpjm1q2eHCASb9kUsMeEC1G65ZuFRw@mail.gmail.com"
type="cite">
<div style="color: rgb(144, 154, 164); margin-left: 24px;
margin-right: 24px;" __pbrmquotes="true" class="__pbConvBody">
<div dir="ltr">
<div class="gmail_extra"><div class="gmail_quote">* Will Node
enforce a filesystem layout for e.g. packages? If so, is that compatible
with our source layout? Or, how much overhead will putting it in place
add to the build?<br></div></div>
</div>
</div>
</blockquote>
In my experience with Positron, Node's source layout has been compatible
with Mozilla's for the core modules. I suspect the same would be true
for third-party modules we vendor via NPM, although I haven't confirmed
that.<br>
<br>
<blockquote style="border: 0px none;"
cite="mid:CAJTgH0n0t4rVDqCb6TuZKpjm1q2eHCASb9kUsMeEC1G65ZuFRw@mail.gmail.com"
type="cite">
<div style="color: rgb(144, 154, 164); margin-left: 24px;
margin-right: 24px;" __pbrmquotes="true" class="__pbConvBody">
<div dir="ltr">
<div class="gmail_extra"><div class="gmail_quote">* What about
Windows (since Windows is typically an unloved OS for developers)?<br></div></div>
</div>
</div>
</blockquote>
Node supports Windows, but SpiderNode doesn't yet. We'd need to fix
that, perhaps by first enhancing mozbuild's GYP reader to generate
moz.build configurations from SpiderNode GYP files. Ted Mielczarek's
recent work on the GYP reader will help there, although there's more
work to do.<br>
<br>
<blockquote style="border: 0px none;"
cite="mid:CAJTgH0n0t4rVDqCb6TuZKpjm1q2eHCASb9kUsMeEC1G65ZuFRw@mail.gmail.com"
type="cite">
<div style="color: rgb(144, 154, 164); margin-left: 24px;
margin-right: 24px;" __pbrmquotes="true" class="__pbConvBody">
<div dir="ltr">
<div class="gmail_extra"><div class="gmail_quote">* Many tools in
the Node ecosystem require running Node as part of building. How will
this work with cross-compile builds? (See my comments in bug 1320607 on
the challenges of requiring "host binaries.")<br></div></div>
</div>
</div>
</blockquote>
I'm unsure exactly which tools you're referring to, but Node itself (and
hence SpiderNode) doesn't require an existing Node binary in order to
build. Supporting other use cases, such as Node programs generally
(including Node-based build tools/toolchains), would be a different
project.<br>
<br>
<blockquote style="border: 0px none;"
cite="mid:CAJTgH0n0t4rVDqCb6TuZKpjm1q2eHCASb9kUsMeEC1G65ZuFRw@mail.gmail.com"
type="cite">
<div style="color: rgb(144, 154, 164); margin-left: 24px;
margin-right: 24px;" __pbrmquotes="true" class="__pbConvBody">
<div dir="ltr">
<div class="gmail_extra"><div class="gmail_quote">And some other
general questions:<br><br></div><div class="gmail_quote">* Will Node
modules require yet another event loop? How does Node's event loop
interact with existing event loops?<br></div></div>
</div>
</div>
</blockquote>
Yes, libuv has yet another event loop that we'd integrate with the Gecko
event loop by posting runnables to the Gecko loop when libuv events
occur. We've done this for Positron and SpiderWeb (our POC of SpiderNode
for Firefox). It's similar to what Electron did to integrate libuv and
Chromium, as described in this section of a blog post:<br>
<br>
<a class="moz-txt-link-freetext" href="http://electron.atom.io/blog/2016/07/28/electron-internals-node-integration#polling-nodes-event-loop-in-a-separate-thread">http://electron.atom.io/blog/2016/07/28/electron-internals-node-integration#polling-nodes-event-loop-in-a-separate-thread</a><br>
<br>
<blockquote style="border: 0px none;"
cite="mid:CAJTgH0n0t4rVDqCb6TuZKpjm1q2eHCASb9kUsMeEC1G65ZuFRw@mail.gmail.com"
type="cite">
<div style="color: rgb(144, 154, 164); margin-left: 24px;
margin-right: 24px;" __pbrmquotes="true" class="__pbConvBody">
<div dir="ltr">
<div class="gmail_extra"><div class="gmail_quote">* What's the
memory overhead? Does Node have granular memory management/monitoring
that we've worked into JSMs via e.g. compartments and about:memory?<br></div></div>
</div>
</div>
</blockquote>
I don't have a good sense of this yet.<br>
<br>
<blockquote style="border: 0px none;"
cite="mid:CAJTgH0n0t4rVDqCb6TuZKpjm1q2eHCASb9kUsMeEC1G65ZuFRw@mail.gmail.com"
type="cite">
<div style="color: rgb(144, 154, 164); margin-left: 24px;
margin-right: 24px;" __pbrmquotes="true" class="__pbConvBody">
<div dir="ltr">
<div class="gmail_extra"><div class="gmail_quote">* What's the
multi-thread/process story?<br></div></div>
</div>
</div>
</blockquote>
Node programs themselves are single-threaded, although libuv uses
threads to parallelize operations. We've also prototyped running Node in
a child process, which would be useful for certain use cases, although I
suspect not for Firefox chrome code.<br>
<br>
<blockquote style="border: 0px none;"
cite="mid:CAJTgH0n0t4rVDqCb6TuZKpjm1q2eHCASb9kUsMeEC1G65ZuFRw@mail.gmail.com"
type="cite">
<div style="color: rgb(144, 154, 164); margin-left: 24px;
margin-right: 24px;" __pbrmquotes="true" class="__pbConvBody">
<div dir="ltr">
<div class="gmail_extra"><div class="gmail_quote">* Is there
overhead e.g. passing thousands of strings between Node modules and
JSMs?<br></div></div>
</div>
</div>
</blockquote>
I don't think so, given that Node would be using the same JS
context/runtime as JSMs that are running in the same Firefox
chrome/parent process, so any string optimizations (like interning)
should apply. But there may be some overhead from the SpiderShim
functions that translate V8 string operations into their SpiderMonkey
equivalents.<br>
<br>
<blockquote style="border: 0px none;"
cite="mid:CAJTgH0n0t4rVDqCb6TuZKpjm1q2eHCASb9kUsMeEC1G65ZuFRw@mail.gmail.com"
type="cite">
<div style="color: rgb(144, 154, 164); margin-left: 24px;
margin-right: 24px;" __pbrmquotes="true" class="__pbConvBody">
<div dir="ltr">
<div class="gmail_extra"><div class="gmail_quote">* Do we care
about implications for sandboxing?<br></div></div>
</div>
</div>
</blockquote>
I'm unsure, but my current thinking would be to make this available
first in the parent process.<br>
<br>
<blockquote style="border: 0px none;"
cite="mid:CAJTgH0n0t4rVDqCb6TuZKpjm1q2eHCASb9kUsMeEC1G65ZuFRw@mail.gmail.com"
type="cite">
<div style="color: rgb(144, 154, 164); margin-left: 24px;
margin-right: 24px;" __pbrmquotes="true" class="__pbConvBody">
<div dir="ltr">
<div class="gmail_extra"><div class="gmail_quote">* If we're going
to perform a giant refactor of core components currently implemented in
JS, would the time better be spent converting to Rust?<br></div></div>
</div>
</div>
</blockquote>
This is a difficult question to answer, as it depends on a variety of
factors. If Node were available, then I suspect that there would be a
subset of core components that it would make sense to refactor into Node
modules, another subset that would be better converted to Rust, and a
third subset that we should leave alone.<br>
<br>
-myk<br>
<br>
</body></html>