Every 30 seconds (configurable by --code-collection-interval),
before a MarkSweep collection, this change halves a function's
usage count if it is unoptimized. If the function's usage count
reaches 0 as a result of this halving, it sets the function's
code pointers to null. Then, if the code object isn't marked
during the MarkSweep, it will be collected.
This change also checks for null code pointers in various
places, and recompiles/reconnects code if needed.
R=srdjan@google.com
Review URL: https://codereview.chromium.org//27802002
git-svn-id: https://dart.googlecode.com/svn/branches/bleeding_edge/dart@29209 260f80e4-7a28-3924-810f-c04153c831b5
By inserting the necessary checks for null inside the callee
at the AST level, the code generation of == operations can be
greatly simplified.
This is a performance-neutral change and a step for allowing
generic inlining of arbitrary == methods. So far we could only
inline them for a common set of types in the flow graph
optimizer.
R=srdjan@google.com
Review URL: https://codereview.chromium.org//24203004
git-svn-id: https://dart.googlecode.com/svn/branches/bleeding_edge/dart@28084 260f80e4-7a28-3924-810f-c04153c831b5
number (or bad name) of arguments is passed.
The frame of the wrong method (the one invoked with the wrong number or name of
arguments) is not left on the stack and therefore not visible in the stack trace
anymore, which is much cleaner, especially since the leftover frame was not
fully initialized.
This change was already done on ARM.
R=zra@google.com
Review URL: https://codereview.chromium.org//17857008
git-svn-id: https://dart.googlecode.com/svn/branches/bleeding_edge/dart@24485 260f80e4-7a28-3924-810f-c04153c831b5
Add profiling support to select OSR candidates and launch the compiler
for OSR, followed by entry to the function at the OSR entry point.
Implemented only on IA32 and X64. The initial implementation can be
improved in various ways --- specifically: tuning of profiling
parameters and incorporation of feedback about the actual values seen
at OSR entry.
R=fschneider@google.com
Review URL: https://codereview.chromium.org//16693006
git-svn-id: https://dart.googlecode.com/svn/branches/bleeding_edge/dart@24024 260f80e4-7a28-3924-810f-c04153c831b5
Introduce a new PcDescriptor kind to distinguish closure calls from other runtime calls. The debugger can patch these calls to set a breakpoint. When stepping into a closure call, the debugger must fish out the closure object from the stack, find the function and set breakpoints in it.
Arm and Mips breakpoint stubs are not implemented yet. ia32 and x64 stubs tested by hand. Automated test to follow.
R=srdjan@google.com
Review URL: https://codereview.chromium.org//14858033
git-svn-id: https://dart.googlecode.com/svn/branches/bleeding_edge/dart@22596 260f80e4-7a28-3924-810f-c04153c831b5
AllocationSinking pass discovers non-escaping allocations that have no input uses other than uses in the stores into its own fields.
Every environment use of such allocation is replaced by a state snapshot (MaterializeObject instruction) that describes the state of each initialized field in the object. State snapshots are computed through an additional round of load-forwarding.
Once snapshots are computed allocations are removed from the graph.
MaterializeObject instructions are not compiled into native code but produce deoptimization instructions instead that describe how object should be materialized at deoptimization.
Deoptimization instructions now follow the following format:
[mat obj #1]...[mat obj #N][ret addr][... mat arguments ...][... real frames ...]
- the prefix describes each object to materialize on deopt via kMaterializeObject instruction;
- actual values that are needed for materialization are emited as a part of bottom-most stack frame. This is done to simplify implementation: they need to be discoverable by a GC during materialization phase. At the end of deoptimization they will be removed from the stack;
- normal stack slots can refer to materialized objects via kMaterializedObjectRef instruction.
Additionally this change contains fixes in load-forwarding that are needed to guarantee that all artificial LoadField instructions inserted during AllocationSinking are correctly replaced with actual values.
Limitations of the current implementation:
- can't eliminate allocations that flow into phis but otherwise don't actually escape;
- can't sink allocations out of loops;
- allocation with type arguments are not handled.
R=regis@google.com, srdjan@google.com, zra@google.com
Review URL: https://codereview.chromium.org//14935005
git-svn-id: https://dart.googlecode.com/svn/branches/bleeding_edge/dart@22485 260f80e4-7a28-3924-810f-c04153c831b5
Maintain a separate top_exit_frame_info for simulated frames and use it to
verify that longjumps are safe.
Make sure unwinding of scopes works in the presence of a simulator.
Support inline allocation of objects.
Support checking of inline cache and instance calls.
Support subtype test cache.
Support (some) equality checks.
Support for (some) conditional branches.
Support for pool pointer setup in stubs.
Review URL: https://codereview.chromium.org//13502002
git-svn-id: https://dart.googlecode.com/svn/branches/bleeding_edge/dart@20890 260f80e4-7a28-3924-810f-c04153c831b5
- Read the saved context from the entry frame when straddling across C++ frames while iterating over a stack trace in the debugger. This ensures that the correct context is setup in the ActivationFrame structure in these scenarios (instead of the empty context).
- Read the saved context from the caller's frame when iterating over a stack trace in the debugger. The compiler saves the context in the caller frame before invoking closures, we read this saved context when iterating the stack trace.
Review URL: https://codereview.chromium.org//12179020
git-svn-id: https://dart.googlecode.com/svn/branches/bleeding_edge/dart@18235 260f80e4-7a28-3924-810f-c04153c831b5
The code can be patched if it should not be executed any longer.
The code can be now patched at other location than at entry, the requirement is still that patching code does not overwrite an inlined object.
Intrinsic methods that do not have a fall through cannot be patched.
Review URL: https://codereview.chromium.org//11783066
git-svn-id: https://dart.googlecode.com/svn/branches/bleeding_edge/dart@16897 260f80e4-7a28-3924-810f-c04153c831b5
asiva@google.com