Don't do ClassLoader prep in dexopt.
The code to cache the method info for ClassLoader.loadClass() was
happening in dexopt, which is a problem when you're optimizing core.jar.
This splits it out into a different function, which the dexopt startup
doesn't call.
Change-Id: I0bd5b9323b65e8f152b2ab4ea8e58fcf0039e53c
diff --git a/vm/oo/Class.c b/vm/oo/Class.c
index abe8330..9bf7118 100644
--- a/vm/oo/Class.c
+++ b/vm/oo/Class.c
@@ -355,10 +355,18 @@
if (gDvm.bootClassPath == NULL)
return false;
- /*
- * We should be able to find classes now. Get the vtable index for
- * the class loader loadClass() method.
- */
+ return true;
+}
+
+/*
+ * We should be able to find classes now. Get the vtable index for
+ * the class loader loadClass() method.
+ *
+ * This doesn't work in dexopt when operating on core.jar, because
+ * there aren't any classes to load.
+ */
+bool dvmBaseClassStartup(void)
+{
ClassObject* clClass = dvmFindSystemClassNoInit("Ljava/lang/ClassLoader;");
Method* meth = dvmFindVirtualMethodByDescriptor(clClass, "loadClass",
"(Ljava/lang/String;)Ljava/lang/Class;");