Hacker News Reader

Comment by curveship | Hacker News Reader

> It has the concept of explicitly capturing variables from the surrounding context inside closures, like PHP does, instead of keeping the entire context alive forever like Ruby or JS.

Just as a point of fact, javascript -- at least the v8 implementation I'm most knowledgeable of -- doesn't "keep the entire context alive forever." Only variables used in the closure are allocated into the closure (i.e. on the heap), the others are allocated on the stack and disappear as soon as the function returns.

I don't use iTunes so can't read their book, but I wanted to ask: you say that ARC is still their GC strategy, correct? So reference cycles are still an issue? I'm surprised at this. I can see reference counting being a strategy for moving a non-GC'd language to GC (like Objective-C), but to start a new language with that constraint is surprising.

View on HN

> Only variables used in the closure are allocated into the closure

I'm not sure that's true. Look at the following code:

  var x = 123;

  var f = function(xname) {
    eval('console.log('+xname+');');
  }

  f('x');

It's a dynamically named variable. Clearly, f() has access to the entire context that surrounds it, not just the objects explicitly used in the function code. In this example, the compiler could not possibly have known I was going to access x.

This means in Javascript, as well as in Ruby, when you hand a closure to my code, I can access the entire environment of that closure.

Contrast that with Lua, for example, where the compiler does indeed check whether an outer variable is being used and then it imports that variable from the context only.

PHP does it most explicitly, forcing the developer to declare what outer objects they want to have available within the function.

> In this example, the compiler could not possibly have known I was going to access x.

Right, but it knew you were going to use eval, and to support that, it had to allocate all local variables in the closure. That's why you saw this behavior. The same would happen if you used a 'with' construct.

> Right, but it knew you were going to use eval, and to support that, it had to allocate all local variables in the closure.

Wow, so there is actually special handling in the engine for this? So it does static analysis whenever it can, but not in these two cases?

Yes, the V8 compiler bails out of several optimizations if your function uses eval. You can see this in the profiler: functions which V8 wasn't able to optimize will have an alert sign next to them, and if you click it, it'll tell you what the issue was.

This is a bit troublesome!

  function f() {var x = 99; return function(a,b) {return a(b)};}
  f()(eval, 'console.log(x);')
  ReferenceError: x is not defined
  function f() {var x = 99; return function(a,b) {return eval(b)};}
  f()(eval, 'console.log(x);')
  99
  undefined

Yep, this is as per spec: http://www.ecma-international.org/ecma-262/5.1/#sec-10.4.2 . "Indirect" calls to eval (i.e. assigning eval to another variable, like you did by passing it as a param) are evaluated in terms of the global environment. "Direct" calls, like in your second example, use the local environment.

Very cool, thanks for clearing that up!

Yes, and in articles describing it (v8), they explicitly warn you to not use "eval" or "with" for the performance impact.

In your example, X is still in scope when f('x') is called. It doesn't require closure to work.

I think you misunderstand what I'm trying to say. The point is not that x should be out of scope (why would it be?)

The original assertion by curveship was that the outer context is not kept alive for the function, and that f() only gets access to the variables it explicitly imports from the outer context. And I thought this might be wrong, so I cooked up the example.

Again, this is not about scope. This is about the fact that the function itself keeps a reference to the entire context it was created in, as opposed to just the things it explicitly imports.

In this, it appears, Javascript works exactly as Ruby, which again makes the entire outer context available through the binding facility.

I'm sorry if that wasn't clear from my description.

Swift reuses the Objective-C runtime, so it had to be compatible in terms of memory management.

OK, thanks. I guess that makes sense. Now that the website is working, I see that they're aiming at fairly seamless interop between Swift and Objective-C, so I guess they need a similar memory strategy.

This is not accurate. SpiderMonkey and V8 still retain the entire outer scope if any of the variables are used.

See here for an example: https://www.meteor.com/blog/2013/08/13/an-interesting-kind-o...

This bug is still not fixed. There's an issue open for it on the V8 tracker, I believe. It seems to have not gotten fixed in either engine because it's a difficult problem that affects a small subset of JS applications.

So go ahead and run his test. Things have changed :). Memory builds up 1mb/second, then after a few seconds, you'll see it drop back to zero, as the GC runs.

V8 has seen a lot of really nice optimizations to closures over the last year. My favorite is that closures are no longer considered megamorphic.

Oh wow, when did that land? I was getting hit by that leak with JSIL in the last couple months. Can you link to the commit?

Not sure the date. I first noticed the change back in April, when I was profiling some code. Ask vegorov: http://mrale.ph/blog/2012/09/23/grokking-v8-closures-for-fun... .

Reply on news.ycombinator.com