| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
| |
Bug: 15310540
Also, narrow scope of catch/deoptimize stack visitors that are specific to
quick exception delivery.
Change-Id: Ib13a006ce1347acb93a36b0186550d4c3ec2034b
|
| |
|
|
|
|
|
| |
Reverts change 72b3e430d880ef57eaa6a34a0822165994052202 but keeps unit test and
missing delete that would fail assertions on long jump context recycling.
Change-Id: I926755e8b831b208aa7e1ce46421bef3793a1441
|
| |
|
|
|
|
|
|
|
|
|
|
| |
The thrown exception is always resolved, as we have an instance of
it. What is potentially not resolved is the catch handler's exception
type.
The resolution failure will trigger a NoClassDefFoundError, which
should replace the original exception. For this, the API has to be
changed a little bit to tell callers that there was this change.
Change-Id: Id51d54a15c732ed175eb617b3b0331b89cbb2051
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Delete SirtRef and replaced it with Handle. Handles are value types
which wrap around StackReference*.
Renamed StackIndirectReferenceTable to HandleScope.
Added a scoped handle wrapper which wraps around an Object** and
restores it in its destructor.
Renamed Handle::get -> Get.
Bug: 8473721
Change-Id: Idbfebd4f35af629f0f43931b7c5184b334822c7a
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This CL refactors the exception handling (on the quick side) by isolating the
search of catch handler and the preparation of deoptimization.
We rename the CatchFinder class to QuickExceptionHandler so it's less specific
to catch handler search.
Finding catch handler happens in QuickExceptionHandler::FindCatch. Since the
CatchBlockStackVisitor resolves exception types, it may cause thread suspension
and breaks the assertion current thread can't be suspended. Therefore, we place
the exception in a SirtRef (while it is detached from the current thread) and
remove the thread suspension assertion.
Deoptimization now happens in QuickExceptionHandler::DeoptimizeStack. It uses
the new DeoptimizeStackVisitor class to create shadow frames.
We also add the Thread::GetDeoptimizationException method to get the definition
of the fake exception in only one place.
Change-Id: I01b19fa72af64329b5c3b6c7f0c3339d2d724978
|
| |
|
|
|
|
|
|
| |
FindCatchBlock now uses ResolveType to get the exception type,
since it might not be able to find it in the dex cache.
Bug: 13948502
Change-Id: Ia6f1c7dc743206ae1c8551bf6239f48ee4d3a784
|
|
|
While debugging a throwing exception, we may end up updating instrumentation
stack frame after having already walked the native stack. This leads to not pop
instrumentation frames prior to catch handler (or upcall if exception is not
caught) and get it desynchronized with the native stack.
To solve this issue, we need to walk the stack again after having reporting the
exception to the instrumentation listener (for example: the debugger) which
may push new instrumentation stack frames. However we do it only when we know
instrumentation is enabled to not slow down exception delivery when executing
code without instrumentation.
Here are the main changes:
- Creates InstrumentationStackVisitor to compute the number of instrumentation
frames to pop (previously done in CatchBlockStackVisitor). We only count frames
prior to catch handler (or upcall). Popping instrumentation frames is done
after having reported the exception to the instrumentation listener.
- Updates the CatchBlockStackVisitor to remove instrumentation frame handling
and focus only on finding the catch handler and prepare deoptimization.
- Creates CatchFinder class to control both visitors and do the long jump.
Change-Id: I29b3871403f297bfb8c087e27f1330b002f5d56d
|
