Only look for method optimization annotations in the bootstrap class loader.
When checking for an optimization annotation (FastNative or
CriticalNative) on a method, do not resolve the method's annotations'
classes as a side effect -- instead, look them up in the bootstrap
class loader's resolved types. This is to prevent exceptions from being
thrown (during class resolution) in JNI transitions.
This change does not affect annotation lookup rules in the context of
reflection.
Test: art/test/testrunner/testrunner.py -t 656-annotation-lookup-generic-jni
Bug: 38454151
Bug: 34659969
Change-Id: Ie6b8b30b96a08baa629c449e3803a031515508d1
diff --git a/runtime/entrypoints/quick/quick_trampoline_entrypoints.cc b/runtime/entrypoints/quick/quick_trampoline_entrypoints.cc
index 4e54045..2c99aeb 100644
--- a/runtime/entrypoints/quick/quick_trampoline_entrypoints.cc
+++ b/runtime/entrypoints/quick/quick_trampoline_entrypoints.cc
@@ -2192,6 +2192,11 @@
self->SetTopOfStack(sp);
uint32_t shorty_len = 0;
const char* shorty = called->GetShorty(&shorty_len);
+ // Optimization annotations lookup does not try to resolve classes,
+ // as this may throw an exception, which is not supported by the
+ // Generic JNI trampoline at this stage; instead, method's
+ // annotations' classes are looked up in the bootstrap class
+ // loader's resolved types (which won't trigger an exception).
bool critical_native = called->IsAnnotatedWithCriticalNative();
// ArtMethod::IsAnnotatedWithCriticalNative should not throw
// an exception; clear it if it happened anyway.