Comments (3)
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.
Related Issues (20)
- See if we can simply `listFormulaIsEmpty()` with introduction of `undef`
- `SyntaxNode` don't distinguish between exclusive record type without fields and map
- Distinguish `record {| T...; |}` vs `map<T>` in ST and AST HOT 1
- Implement backend support for optional record fields
- Assigning a vararg function to a function value whose type has a fixed number of args is failing
- `testBirCompile` test is failling with 2201.5.0 RC1 HOT 6
- Parsing binary type descriptors with function types is failing
- Invalid record subtype relation HOT 5
- Use property based testing to validate function subtyping and application
- Add support for `never` type
- Add support for object type HOT 1
- Make complement op for function type explicit
- Confusing behaviour around compliment for "sugared" types HOT 1
- Implement closures for final values
- Make it possible for older jBallerina versions to use nBallerina for validation HOT 2
- Implement escape analysis for closures
- Type testing with `FunctionConstOperands` fail to compile
- Use exact bit to check function value exactness
- Calculating sub-element address using GEP fails on AArch64 HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from nballerina.