Changes

Jump to: navigation, search

Platform/Features/IonMonkey

4,764 bytes added, 01:54, 22 July 2011
no edit summary
See [[/RegisterAllocator]] for information on the register allocator interfaces.
|Feature implementation notes=Note: time estimates here are total guesswork, erring on the safe side. Items are in no particular order. # '''Bailouts'''## What: Bailouts are the heart of the optimizing compiler. When speculation fails (triggering a type, shape, overflow guard, etc), or C++ throws an exception, or needs to GC, we must be able to inspect the JIT frame, and if needed, reconstruct an interpreter frame.## Dependencies:### Register allocator### Code Generator## Work involved:### Implementing guards### Snapshot building at guard points### Bailout trampoline### Frame reconstruction## Priority: Critical, blocks testing## Time: 2-3 weeks## Owner: dvander# '''Calls out to C++'''## What: Ability to call into C++ from JIT code.## Dependencies: Bailouts## Work involved:### Macro assembler interface for managing calls.### Ability to recover bailout information from within C++.### C++ function calling convention (bake in JSCompartment, hold active ion cx?)### Protocol for dealing with exceptions returned from C++ functions### GC needs to walk Ion frames## Priority: Very high## Time: 3-4 weeks## Owner: TBD# '''Property Access and Inline Caches'''## What: Code to handle property access sites## Dependencies: Bailouts, Calls out to C++## Work involved:### TypeOracle interface for learning about property accesses.### Four cases of knowledge: Monomorphic, Polymorphic, Megamorphic, and Unknown (IC)### Building JM-like IC structures into IM, solving old memory management problems like reset-on-GC, bloated IC structs## Priority: High## Time: 4-5 weeks?## Owner: TBD# '''Function calls'''## What: Ability to call other Ion or interpreter JS functions## Dependencies: Bailouts, maybe ICs?## Work involved:### Handle monomorphic versus polymorphic calls (ICs).### Handle arity mismatches.### Modify trampolines and calling convention so frame reconstruction can restore nested frames.## Priority: High## Time: 2-3 weeks## Owner: TBD# '''Baseline Compiler'''## What: A compiler that replaces JägerMonkey as an untyped and fast compiler.## Dependencies: None, but needs close integration with ICs and type profiling## Work involved: Explore problem space. Ideally, we want to use IonMonkey as the baseline compiler, but whether the compiler itself is fast enough is an open question. Similarly, the expense of taking and translating snapshots must be measured on scripts with a huge number of local variables.### If IonMonkey is fast enough, we can just use it.### If optimization passes are expensive, we can turn them off.### If snapshots are too expensive, we can eliminate them and insert IR nodes to incrementally sync the stack.### If IonMonkey is too slow, we can write a new baseline compiler and possibly consider it generating off MIR.### Further work stems from this decision.## Priority: High## Time: 4 months## Owner: TBD# '''Type Feedback'''## What: Feedback mechanism to inform IonMonkey about likely types of access sites.## Dependencies: ICs## Work involved:### Explore problem space. Ideally we want to learn about types from ICs, using either previous IonMonkey runs or information from the baseline compiler (Ion or not). Therefore we should aim to share IC structures between all compilers.### Implement a TypeOracle derivation that uses run-time profiling to inform IonMonkey.## Priority: High## Time: 4 weeks## Owner: TBD# '''Type Inference Integration'''## What: Integrate IonMonkey's type system to Brian Hackett's type inference engine.## Dependencies: None## Work involved:### Explore problem space. Ideally we want to use the same TypeOracle interface for both inference and profiling.### Make a TypeOracle that uses inference results to inform IonMonkey.## Priority: Medium## Time: ???## Owner: TBD (maybe bhackett?)# '''Method Inlining'''## What: Inline methods## Dependencies: Bailouts, either profiling, ICs, or calls out to C++## Work involved:### Some heuristic to determine whether methods should be inlined (this can be totally bogus, but maybe better to start with simple methods).### Changing IonBuilder such that JSScripts bytecode parsing can be "stacked" so inner SSA graph is inlined.### Change M/LSnapshots to be nested, so snapshots in an inner frame all point to the same outer snapshot.### Change snapshot encoding and frame reconstruction to support inlining.## Priority: Medium## Time: 4-6 weeks## Owner: TBD# '''On-Stack Replacement'''## What: Jump into JIT code at loop headers, possibly by profiling off-thread.## Work involved:### Explore ways to monitor hotness of JIT code.### Implement the ability to jump into Ion-compiled code at loop headers, possibly by inserting special OSR nodes in the IR.## Priority: Medium## Time: ??? Probably less than a month## Owner: TBD# '''Debugging'''## What: Work with jsd/jsdbg2 or whatever debugging APIs are required.## Dependencies: Bailouts, Baseline JIT## Work involved:### Deoptimizing from within C++### Calling debug hooks/probes### Implementing breakpoints, EvalInFrame## Priority: Low (for now)## Time: ???## Owner: TBD
test
# Implement method inlining
# Implement advanced linear-scan register allocation
# Implement loop invariant code motion
# Implement constant sub-expression elimination
# Implement type-profiling
# Implement enough functionality to replace existing JITs
# Implement proper memory management of code
# Implement interval analysis
}}
{{FeatureInfo
Confirm
156
edits

Navigation menu