Extend BIR to support closures about nballerina HOT 3 CLOSED

I suggest we change FunctionDefn to Function, where a Function is either a FunctionDefn or an AnonFunction. AnonFunction has a ref to its parent, which for now is either an AnonFunction or a FunctionDefn, but could allow another top-level construct in the future. Then we replace getFunctionDefns by getFunctions returniing Function[]. The index into this is a handle for the FunctionCode. FunctionCode then includes an int[] giving the indices of the child AnonFunctions. We have a FunctionConstructInsn which has gives a handle to the AnonFunction.

We then have CaptureRegister which is an additional kind of register used for references to captured variables (analogous to NarrowRegister). It always refers to the parent and has an int giving the index in the parent.

For nested capturing, every level captures. For example:

function foo() returns int {
  int x = 1;
  var f = function() returns int {
    var g = function() returns int { return x; }
    return g();
  }
  return f();
}

The function f has a CaptureRegister that refers to x in foo. Then g has a CaptureRegister that refers to the CaptureRegister in the function bound to f.

If you think about it, evaluating the outer anon function expression does not evaluate the inner anon function expression, so the evaluation of the outer function expression has to capture x so it can be captured when f() is evaluated (which will cause evaluation of the inner anon function expression). Phew!

from nballerina.

Variables that are captured may need to be stored on the heap. But there's an optimization called "escape analysis" that is typically done to allow some captured variables to be stored on the stack. So it's probably best to leave analysis of capturing to the backend. In the BIR captured variables are not treated specially in the function that declares them. So in the above example, x in foo is just a VarRegister as normal. The backend will need to determine that it's captured. Note that in this case, it's not actually necessary to store x on the heap, because the f's lifetime does not extend past x's lifetime. But that's an optimization that the backend may or may not want to do.

from nballerina.

Variables that are captured may need to be stored on the heap. But there's an optimization called "escape analysis" that is typically done to allow some captured variables to be stored on the stack. So it's probably best to leave analysis of capturing to the backend. In the BIR captured variables are not treated specially in the function that declares them. So in the above example, x in foo is just a VarRegister as normal. The backend will need to determine that it's captured. Note that in this case, it's not actually necessary to store x on the heap, because the f's lifetime does not extend past x's lifetime. But that's an optimization that the backend may or may not want to do.

LLVM has an analysis pass called CaptureTracking which is used by other optimization passes (though I don't think llvm has optimizers can move values from heap to stack).

from nballerina.