v0.8 Roadmap

[Ryan Dahl]

We're just starting development on the new branch of Node. New
development continues in the master branch - bug fixes go into the
v0.6 branch. The current target for a v0.8 release is early January.
We will continue weekly v0.6 releases throughout v0.8 development.

Node v0.8 roadmap
-----------------

- Move the remaining platform functions from src/platform-*.cc into
libuv. (Everyone)
https://github.com/joyent/node/issues/2132

- Get rid of WAF. All platforms will build using GYP. (Ben, Ryan)
https://github.com/joyent/node/issues?labels=gyp&sort=created&direction=desc&state=open&page=1

- Isolates. Node will allow users to spawn "child processes" that actually
run in a thread. We have to get rid of all the global variables in node.
Compiled extensions need know which isolate they're targeting, and we need
to decide if we want to load the extension multiple times or just once.
Also, some changes to libuv are necessary, since we will have to completely
clean up a loop. Finally we'll have to deal with debugging a multi-threaded
node process. (Ben, Ryan)
https://github.com/joyent/node/issues/2133

- Domains. Domains provide a lightweight isolation mechanism for all i/o
related to a particular network connection (e.g. an incoming http request).
If an unhandled error is encountered, all i/o local to that particular
domain is canceled and all handles are cleaned up. An experimental
implementation can be found at https://github.com/joyent/node/commits/domains.
Some of the early work for domains will be used in Isolate support (e.g.
cleaning up handles when an Isolate is killed) (Bert, Ryan)
https://github.com/joyent/node/issues/2134

- Better allocator. Currently node uses a memory pool allocator to provide
read buffers for incoming data streams. This allocator is only
reasonably efficient for network connections and local pipes on Unix, and on
Windows when zero reads are used. For file i/o and buffered reads on Windows
we need a better story. (Igor)
https://github.com/joyent/node/issues/2135

- Addons. We need to define an easy and suggested way of building
extensions, which should be similar across all supported platforms. (Everyone)
https://github.com/joyent/node/issues/2136

[Mikeal Rogers]

On Nov 16, 2011, at November 16, 20111:36 PM, Ryan Dahl wrote:

> - Isolates. Node will allow users to spawn "child processes" that actually
> run in a thread. We have to get rid of all the global variables in node.
> Compiled extensions need know which isolate they're targeting, and we need
> to decide if we want to load the extension multiple times or just once.
> Also, some changes to libuv are necessary, since we will have to completely
> clean up a loop. Finally we'll have to deal with debugging a multi-threaded
> node process. (Ben, Ryan)
> https://github.com/joyent/node/issues/2133

I'm wondering what the plan is intended use is for isolates.

If I remember correctly, the main reason we want to use them to get away from using multiple system processes as we do now for processing concurrency, mainly because Windows really wants you to use threads.

If that is the case, will the current cluster APIs, and most node APIs in general, remain unchanged and as "dumb" or "smart" about clustering as they are today? For example: using cluster today you will have an http module per process with a separate pool global to that process. When I see notes like "remove all global variables" I wonder if there is a plan to change this behavior.

[Liam]

On Nov 16, 1:58 pm, Mikeal Rogers <mikeal.rog...@gmail.com> wrote:
> On Nov 16, 2011, at November 16, 20111:36 PM, Ryan Dahl wrote:
>
> > - Isolates. Node will allow users to spawn "child processes" that actually
> >  run in a thread. We have to get rid of all the global variables in node.
> >  Compiled extensions need know which isolate they're targeting, and we need
> >  to decide if we want to load the extension multiple times or just once.

Will this break most compiled modules again?

> If I remember correctly, the main reason we want to use them to get away from using multiple system processes as we do now for processing concurrency, mainly because Windows really wants you to use threads.

Seems like we'd prefer processes to threads for cp.fork() & cluster
(at least on Unixes) so that a failure in one (e.g. module segfault)
won't take them all down?

[Tomasz Janczuk]

Isolates support is a very interesting feature. I've run some experiments related to application density using various isolation constructs V8 offers (details at http://github.com/tjanczuk/denser and http://cloud.github.com/downloads/tjanczuk/denser/High%20density%20server%20side%20JavaScript.pdf). In the results I got using multiple V8 isolates to run several copies of the same JS application in a single process resulted in ~2x reduction of memory use compared to running the same number of applications each in its own process. 

[Liam]

On Nov 16, 1:36 pm, Ryan Dahl <r...@tinyclouds.org> wrote:
> - Domains. Domains provide a lightweight isolation mechanism for all i/o
>   related to a particular network connection (e.g. an incoming http request).
>   If an unhandled error is encountered, all i/o local to that particular
>   domain is canceled and all handles are cleaned up. An experimental

>   implementation can be found athttps://github.com/joyent/node/commits/domains.

>   Some of the early work for domains will be used in Isolate support (e.g.
>   cleaning up handles when an Isolate is killed) (Bert, Ryan)
>  https://github.com/joyent/node/issues/2134

If the main purpose of a Domain is to turn a thrown exception into an
event, why not try/catch/finally terminology?

var ta = process.tryAsync // or tryCatch, etc
ta.on('catch', function(err) {}) // called if obstreperous
ta.on('finally', function() {}) // called either way

io.async(..., function(obstreperous) {
if (obstreperous) throw obstreperous;
ta.finally();
})

[Dave Clements]

I was under the impression that threads create problems that node had
solved?

[Liam]

On Nov 16, 3:32 pm, Dave Clements <huperekch...@googlemail.com> wrote:
> I was under the impression that threads create problems that node had
> solved?

Managing concurrent access to shared state is the main problem with
threads. These threads would not share any state; they're functionally
equivalent to multiple Node processes.

[Dave Clements]

Ahh right, thanks Liam.

[Liam]

Tomasz, your project says it only runs on Windows. Done any testing on
Unixes?

Your slides don't show how the RAM per thread+isolate scales over N
threads. How many threads per process have you tried?

Also what if any of the app environment is in shared libraries? If
none, wouldn't that reduce per-process overhead?

On Nov 16, 2:27 pm, Tomasz Janczuk <tom...@janczuk.org> wrote:
> Isolates support is a very interesting feature. I've run some experiments
> related to application density using various isolation constructs V8 offers

> (details athttp://github.com/tjanczuk/denserandhttp://cloud.github.com/downloads/tjanczuk/denser/High%20density%20se...).

[jmar777]

I don't think this was ever discussed in the context of a particular
version, but I recall at one point there were discussions about
bringing Promises back into core. Is this now off the road map
entirely, or just not currently slated for 0.8?

[Aikar]

jmar: do you mean "if a CB is not specified, return a promise instead" kind of approach?

I don't think that works because not all async functions have undefined returns (ie: they actually return something, for example stream.write)

For cases like that, you would need yet another function to return a promise...

[Axel Kittenberger]

> (ie: they actually return something, for example stream.write)

stream.write has no callback. Just saying.

[Aikar]

ah... net stream.write is what i meant... thought .write was down on the stream level.

[Dean Landolt]

On Thu, Nov 17, 2011 at 10:35 AM, Aikar <xdr...@gmail.com> wrote:

jmar: do you mean "if a CB is not specified, return a promise instead" kind of approach?

I don't believe it was ever the idea to bring promises back into the API, just to use them for some core functionality. So it's not really something that would belong in the roadmap.

[jmar777]

> I don't believe it was ever the idea to bring promises back into the API,
> just to use them for some core functionality. So it's not really something
> that would belong in the roadmap.

Ahh, cool. I personally kind of liked the idea, but was more so just
curious. Thanks!

[Mikeal Rogers]

I think what Ryan meant was that "promisey" objects were going to go back in to core and that we may want to standardize them a bit more.

We have several domain specific objects, which are streams, which also resolve several states at some time in the future. Files, sockets, and http among them. While the stream interface is specified there are several other states in the objects that is not specified nor is the interface entirely implemented for people to extend.

-Mikeal

--
Job Board: http://jobs.nodejs.org/
Posting guidelines: https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
You received this message because you are subscribed to the Google
Groups "nodejs" group.
To post to this group, send email to nod...@googlegroups.com
To unsubscribe from this group, send email to
nodejs+un...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/nodejs?hl=en?hl=en

[Ryan Dahl]

It's not off the roadmap but it's not a "must have" for 0.8. This is
something Isaac will be looking at after NPM is fully functioning on
Windows. Bring your API proposals to him.

[Dean Landolt]

On Thu, Nov 17, 2011 at 11:36 AM, Mikeal Rogers <mikeal...@gmail.com> wrote:

I think what Ryan meant was that "promisey" objects were going to go back in to core and that we may want to standardize them a bit more.

We have several domain specific objects, which are streams, which also resolve several states at some time in the future. Files, sockets, and http among them. While the stream interface is specified there are several other states in the objects that is not specified nor is the interface entirely implemented for people to extend.

Thanks for the clarification Mikeal -- I know exactly what you mean. It's refreshing to hear that this will get some intention.

[Liam]

Hoping for thoughts on this...

[Liam]

Anyone else with me or against on this?

[Mikeal Rogers]

The complexity of maintaining two paths (processes and threads) across posix and windows might be a pain in the ass.

Also, in the future there are optimizations we can make if we are all in the same process.

For instance, WebWorkers are shared nothing as well but Chrome has done some recent work to allow you to pass messages to them by reference rather than suffering serialization.

-Mikeal

[Tomasz Janczuk]

The particular numbers I show on the slide were obtained by running 50
instances of an HTTP long polling web application (https://github.com/
tjanczuk/denser/blob/master/src/denser/samples/chat2.js) either as 50
separate processes or 50 isolates each on its own thread in a single
process, averaged over the number of apps. The memory metric I used is
"private working set", which on Windows is the amount of physical
memory utilized by a process that cannot be shared with other
processes (so shared libs are excluded; in this case the v8.dll on
windows was excluded).

I did not run an experiment on a *nix that would utilize V8 isolates.
I did however experiment with running multiple apps in a single node
process on Linux using the vm module, using separate script contexts
for each app. This is of course much more lightweight than using
isolates and does not provide that level of resource isolation, plus
does not support multi-threading, but from the perspective of memory
measurements it provides an idea of the memory footprint below which
isolates will never let you get. So again I took 100 instances of a
node.js http long polling web chat application (https://github.com/
tjanczuk/denser/blob/master/src/nodejs/samples/chat2.js) and run
either in 100 processes on linux or 100 script contexts inside a
single process. The memory metric I used was non-shared memory
utilized by the process(es) averaged over the number of apps. V8 was
linked in as a shared lib. The variant using script contexts ended up
utilizing 21x less memory per application that the variant using
processes.

On Nov 16, 10:11 pm, Liam <networkimp...@gmail.com> wrote:
> Tomasz, your project says it only runs on Windows. Done any testing on
> Unixes?
>
> Your slides don't show how the RAM per thread+isolate scales over N
> threads. How many threads per process have you tried?
>
> Also what if any of the app environment is in shared libraries? If
> none, wouldn't that reduce per-process overhead?
>
> On Nov 16, 2:27 pm, Tomasz Janczuk <tom...@janczuk.org> wrote:
>
>
>
>
>
>
>
> > Isolates support is a very interesting feature. I've run some experiments
> > related to application density using various isolation constructs V8 offers

> > (details athttp://github.com/tjanczuk/denserandhttp://cloud.github.com/downloads......).

[Liam]

On Nov 17, 11:40 am, Tomasz Janczuk <tom...@janczuk.org> wrote:
> The particular numbers I show on the slide were obtained by running 50
> instances of an HTTP long polling web application (https://github.com/
> tjanczuk/denser/blob/master/src/denser/samples/chat2.js) either as 50
> separate processes or 50 isolates each on its own thread in a single
> process, averaged over the number of apps. The memory metric I used is
> "private working set", which on Windows is the amount of physical
> memory utilized by a process that cannot be shared with other
> processes (so shared libs are excluded; in this case the v8.dll on
> windows was excluded).

It would be interesting to see the numbers across a range of threads.
(It'd also be nice to have a script to automate the tests so ppl can
run it in different contexts.)

It would also be helpful to see an application that has far higher
memory demands, and uses some common third party modules...

[Ryan Dahl]

There is no memory sharing between isolates.

[Liam]

On Nov 17, 11:57 am, Ryan Dahl <r...@tinyclouds.org> wrote:

Exactly, so the 2x benefit described seems unlikely for real-world
apps.

[Bert Belder]

I don't think Tomasz' experiments used memory sharing. He was just
measuring the 'overhead' of running a separate process.

[Tomasz Janczuk]

I agree the benefit would greatly diminish for memory-bound node
applications since the shared global state of the process would be a
very small fraction of the private non-shared state across isolates. I
am curious if you have you seen a lot of node apps with large memory
consumption in the "real world"? I chose HTTP long polling web chat
app as a benchmark based on the assumption that node works
particularly well the class of apps that need to orchestrate IO while
doing a lot of non-CPU and non-memory intensive waiting in between. I
think such apps would actually show reduced average memory footprint
when hosted in isolates as opposed to individual processes.

[Liam]

Right, so shouldn't that be given as KB per process (on various OSes)
not a ratio?

And then the question is whether that cost is worth the benefits of a
process, e.g. it can't crash other processes.

Maybe it's not; I don't have an opinion. Ryan's on the record saying
"processes are the tool for concurrency," so this seems like a
significant shift?

[Ryan Dahl]

We're giving people the option of starting a new Node either as a
standalone process or as a new thread/isolate. Most people will want
to continue using processes as their method of parallelizing because
it's most robust. However some people will want to use threads because
with an addon they can do fancy synchronization between the isolates.
The isolates feature is to enable advanced parallelizing techniques in
Node addons.

[Liam]

On Nov 17, 12:53 pm, Tomasz Janczuk <tom...@janczuk.org> wrote:
> I agree the benefit would greatly diminish for memory-bound node
> applications since the shared global state of the process would be a
> very small fraction of the private non-shared state across isolates. I
> am curious if you have you seen a lot of node apps with large memory
> consumption in the "real world"?

I think it's safe to say that the appeal of Javascript will draw in
developers who push Node into every conceivable role, so "Node is for
x & y sorts of apps" probably isn't a durable assertion. I think we'll
see Node displace Java to some extent, as its ecosystem matures.

It's not hard to eat memory in JS. For instance, it's natural to use
an Object as a key:value cache, and an Array as a queue. I suspect
those aren't the most efficient structures for those needs, but it
will be common practice.

[Liam]

On Nov 17, 1:31 pm, Ryan Dahl <r...@tinyclouds.org> wrote:

Aha. Got it. Good idea.

Synchronization like... sharing data via a Buffer?

[Mark Hahn]

>  He asked a question in a silly way and some of us were pretty rude to him.  

We did not get rude until the skit got really silly.  He kept repeating the same mantra over and over even though he got a lot of replies explaining the same thing to him over and over.  We went for an extended period of time being very polite.

[Liam]

Mark I think you missed your intended thread target :-)