ac175b4faa3c3c5cc0298fd30a5b38636eeee596 |
|
17-Dec-2009 |
Andy McFadden <fadden@android.com> |
Two minor JNI fixes. (1) In the CheckJNI return type scanner, don't assume that the caller's class loader is already listed as an initiating loader for the type being returned. (2) Make sure the PlatformAddress class is initialized before calling one of its static methods from NewDirectByteBuffer.
|
4c691d1a66c4c721dbc156b5e765edb49c7c67e4 |
|
11-Dec-2009 |
Andy McFadden <fadden@android.com> |
Minor CheckJNI tweak. Check for "L;" class names, e.g. "Ljava/lang/String;", in CheckJNI. If we see one passed in, give a specific failure message instead of just allowing the inevitable NoClassDefFoundError to propagate back. Also, add a message string to the pre-formed NoClassDefFoundError used by the bootstrap class loader so that it's obvious where it comes from.
|
a7a9a1478c6e426c1c6e74d56e16a980426b7834 |
|
02-Dec-2009 |
Andy McFadden <fadden@android.com> |
Rudimentary JNI method arg checking. This adds basic checking of reference arguments passed to interpreted methods from native code when CheckJNI is enabled. The various method calls and NewObject variants are checked. Currently only tests to see if objects are valid references; does not attempt to verify that the objects are of the correct type. Also: renamed checkCallCommon for clarity.
|
72e93344b4d1ffc71e9c832ec23de0657e5b04a5 |
|
13-Nov-2009 |
Jean-Baptiste Queru <jbq@google.com> |
eclair snapshot
|
b18992f6e3c168742bc7c7d19d662d7719aef5dd |
|
25-Sep-2009 |
Andy McFadden <fadden@android.com> |
Implement JNI "weak global" references. The VM now supports the NewWeakGlobalRef and DeleteWeakGlobalRef calls, which create a kind of weak reference that's directly visible to native code. While the JNI spec says that these can be used directly, the only safe way to use them is to convert them to a strong local or global reference first, so this is enforced. The net result is very similar to manually creating a global reference to a WeakReference object and manipulating it with method calls from native code, but the JNI calls are faster and more convenient.
|
c19d2a1d798d8626f196d878abcf23a14bee40af |
|
02-Sep-2009 |
Elliott Hughes <enh@google.com> |
Fix two calls to memset(3) whose arguments were reversed. External bug 3358 reported the libcore/x-net instance. Manual inspection turned up another instance in vm, but nothing else in the dalvik package. Tested by booting sapphire-eng and running the x-net tests. Bug: 1999244
|
eb9cbc33ee450d9c237a48273595d9f2a05be342 |
|
28-Aug-2009 |
Andy McFadden <fadden@android.com> |
Expand indirect reference ifdefs. This excludes some things that used to be common between the direct and indirect reference implementations. The goal is to restore the original method call performance. In particular, we no longer convert native method arguments to local references when USE_INDIRECT_REF is not defined.
|
0423f0e813a3807168fe5524405eb96675532097 |
|
26-Aug-2009 |
Andy McFadden <fadden@android.com> |
Fix some JNI indirect reference stuff. Convert where needed, don't convert where not needed, and make sure we're using the right one. With this, my ad-hoc tests pass, and the boot proceeds until we hit a failure that looks like it might be due to logic outside the VM.
|
d5ab726b65d7271be261864c7e224fb90bfe06e0 |
|
25-Aug-2009 |
Andy McFadden <fadden@android.com> |
Another round of scary indirect ref changes. This change adds a not-really-working implementation to Jni.c, with various changes #ifdefed throughout the code. The ifdef is currently disabled, so the old behavior should continue. Eventually the old version will be stripped out and the ifdefs removed. This renames the stack's "localRefTop" field, which nudged a bunch of code. The name wasn't really right before (it's the *bottom* of the local references), and it's even less right now. This and one other mterp-visible constant were changed, which caused some ripples through mterp and the JIT, but the ifdeffing was limited to one in asm-constants.h (and the constant is the same both ways, so toggling the ifdef won't require rebuilding asm sources). Some comments and arg names in ReferenceTable were updated for the correct orientation of bottom vs. top. Some adjustments were made to the JNI code, e.g. dvmCallMethod now needs to understand if it needs to convert reference arguments from local/global refs to pointers (it's called from various places throughout the VM).
|
0083d37b0e1c9e542f671cbca2e9db6819ecccba |
|
21-Aug-2009 |
Andy McFadden <fadden@android.com> |
Use local references for native method args. This changes the JNI method call mechanism to register all reference arguments as local refs, as well as the "this" argument (for virtual calls) and the class object (for static calls). Before now we skipped this part, because we're handing raw object pointers around, and we know that all of the arguments can be found by the GC on the interpreted stack. In fact, there's no need to add the arguments for GC-correctness; rather, we need to do this to rewrite the pointers we hand to native code. This change impacts JNI method call performance, especially for functions with a large number of reference arguments. To improve things a little, there are now four "call bridge" functions: (1) general handler (2) synchronized method handler (grabs lock, calls #1) (3) virtual method, no reference args (4) static method, no reference args While booting the system, the virtual/static no-ref handlers are used for about 70% of calls. Since these don't have to scan the method signature to look for reference arguments, they're a bit faster. At this point we're still passing raw pointers around, so nothing should really change.
|
ab00d455ea67fbf4090567bb09ead8017896ea61 |
|
19-Aug-2009 |
Andy McFadden <fadden@android.com> |
Progress toward indirect JNI references. Switch from simple typecasts to conversion functions for the objects passed in and out of JNI calls. No real change here; object references are still just pointers. Use explicit pin/unpin calls for primitive arrays. For GetStringChars we now pin the char[] rather than the String object. (Which doesn't make much difference in the grand scheme of things, since you need to keep the String to pass into the release function anyway.)
|
8e5c78470229fd2f5474574081eaa4a2286aafea |
|
24-Jul-2009 |
Andy McFadden <fadden@android.com> |
JNI direct buffer function speedup, part 2. This converts the three direct buffer functions from JNI to internal VM calls. As a bonus, we grab PlatformAddress.osaddr directly instead of retrieving it with PlatformAddress.toLong(). We're still calling through getEffectiveAddress(), which is where most of the complexity lies. Nudged a couple of comments.
|
702e2486cdabe6df3ec64e752db2958537a11b35 |
|
23-Jul-2009 |
Andy McFadden <fadden@android.com> |
Minor fixes to CheckJNI. We weren't always switching to "running" mode before playing with objects. Now checkObject() always changes modes, and things that called checkObject while in "running" mode now do so after switching back to "native" (which shouldn't matter now, but I don't want to require nested switching to work if I don't have to). Vaguely related to internal bug 1943379, since I think we want to do some updates to CheckJNI there.
|
59b6177e2fa9c9f1f16d7eff57e481f5282afbda |
|
14-May-2009 |
Andy McFadden <fadden@android.com> |
Check object types when native code returns. Object references returned by native code were not being type checked, so it was possible to (for example) return a byte[] when an InetAddress was expected. This sort of thing can lead to extremely strange behavior. Now, when "check JNI" is enabled, we insert another layer in the JNI call sequence that verifies the type of the returned object. This makes calls to native methods returning an object a bit slower on engineering builds, but the added type safety is helpful. I found two failures with this. One fairly harmless one was fixed in master 1594, the other is filed as internal bug 1851257. The latter does not seem to cause problems for anything other than the socks5 app that uncovered it (but it does render SOCKS less than useful).
|
25b68266e06c0217b4c8871323da4d665795fa8a |
|
13-May-2009 |
Andy McFadden <fadden@android.com> |
Strip some cruft from the CheckJNI method invocation macros.
|
1cf3b27e857824af08bab76489b6e25a213edc8d |
|
04-May-2009 |
Andy McFadden <fadden@android.com> |
Test for null object in the Get<Type>Field and Set<Type>Field JNI functions. Also adds some "return" calls after abortMaybe(), since it won't actually abort if "warnonly" is set.
|
44a3484d9ba75aa88c0f3187a9c0ef56e892771b |
|
30-Apr-2009 |
Andy McFadden <fadden@android.com> |
Changed the way we check the magic number in guard pages. Use memcmp instead of "==" so that, if the pointer is unaligned on a platform where alignment matters, we fail with a nice warning instead of a bus error. Found while tracking down bug 1823434.
|
f6c387128427e121477c1b32ad35cdcaa5101ba3 |
|
04-Mar-2009 |
The Android Open Source Project <initial-contribution@android.com> |
auto import from //depot/cupcake/@135843
|
f72d5de56a522ac3be03873bdde26f23a5eeeb3c |
|
04-Mar-2009 |
The Android Open Source Project <initial-contribution@android.com> |
auto import from //depot/cupcake/@135843
|
cc05ad238516f1303687aba4a978e24e57c0c07a |
|
10-Jan-2009 |
The Android Open Source Project <initial-contribution@android.com> |
auto import from //branches/cupcake/...@125939
|
89c1feb0a69a7707b271086e749975b3f7acacf7 |
|
18-Dec-2008 |
The Android Open Source Project <initial-contribution@android.com> |
Code drop from //branches/cupcake/...@124589
|
2ad60cfc28e14ee8f0bb038720836a4696c478ad |
|
21-Oct-2008 |
The Android Open Source Project <initial-contribution@android.com> |
Initial Contribution
|