| 43eb5015ca8bc0c859100b659d9c12934011a42e |
|
02-Feb-2010 |
Andy McFadden <fadden@android.com> |
Reduce VM shutdown verbosity.
Adds -verbose:shutdown flag, defaulted to "false". Cuts out most of the
log noise associated with shell commands.
|
| 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.
|
| 96516932f1557d8f48a8b2dbbb885af01a11ef6e |
|
29-Oct-2009 |
Andy McFadden <fadden@android.com> |
Change the way breakpoints work.
This replaces the breakpoint mechanism with a more efficient approach.
We now insert breakpoint instructions into the bytecode stream instead of
maintaining a table. This requires mapping DEX files as private instead
of shared, which allows copy-on-write to work. mprotect() is used to
guard the pages against inadvertent writes.
Unused opcode EC is now OP_BREAKPOINT. It's not recognized by dexdump or
any interpreter except portdbg, but it can be encountered by the bytecode
verifier (the debugger can request breakpoints in unverified code).
Breakpoint changes are blocked while the verifier runs to avoid races.
This eliminates method->debugBreakpointCount, which is no longer needed.
(Also, it clashed with LinearAlloc's read-only mode.)
The deferred verification error mechanism was using a code-copying
approach to modify the bytecode stream. That has been changed to use
the same copy-on-write modification mechanism.
Also, normalized all PAGE_SIZE/PAGESIZE references to a single
SYSTEM_PAGE_SIZE define.
Simple Fibonacci computation test times (opal-eng):
JIT, no debugger: 10.6ms
Fast interp, no debugger: 36ms
Portable interp, no debugger: 43.8ms
ORIG debug interp, no breakpoints set: 458ms
ORIG debug interp, breakpoint set nearby: 697ms
NEW debug interp, no breakpoints set: 341ms
NEW debug interp, breakpoints set nearby: 341ms
Where "nearby" means there's a breakpoint in the method doing the
computation that isn't actually hit -- the VM had an optimization where
it flagged methods with breakpoints and skipped some of the processing
when possible.
The bottom line is that code should run noticeably faster while a
debugger is attached.
|
| 72e93344b4d1ffc71e9c832ec23de0657e5b04a5 |
|
13-Nov-2009 |
Jean-Baptiste Queru <jbq@google.com> |
eclair snapshot
|
| 92fa476a8802023b443af893817eb14fef18aaea |
|
23-Oct-2009 |
Andy McFadden <fadden@android.com> |
Add a reference table dump call.
This adds a hidden method to android.os.Debug that causes the contents
of various reference tables to be dumped. Currently it's the local,
global, and pinned array tables from JNI.
Bug 2075355
|
| 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.
|
| 09239e366ba1c253d62fdb06be314b823afd4707 |
|
30-Sep-2009 |
Elliott Hughes <enh@google.com> |
Report all RegisterNatives failures, not just the first.
(It seems that when I make one mistake, I generally make
several at once.)
|
| 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.
|
| c26bb63b50c7a855d25b396b1bf23a3aa6929b48 |
|
21-Aug-2009 |
Andy McFadden <fadden@android.com> |
Move array pinning out of global references table.
We have to pin primitive arrays for certain JNI operations (it's that or
return a copy of the contents). We don't move objects around in the
virtual heap, so simply creating a global reference is enough to ensure
the correct behavior of the calls.
The global reference implementation is changing in a way that makes
this approach inconvenient, so we now have a separate table for pinned
primitive arrays.
As a bonus, if GREF tracking is enabled, we will scan through the table
when a pin entry is added. If there are 10 or more entries for the same
array, a complaint is logged. This should allow us to find mismatched
Get/Release sequences much more easily (before you had to wait until the
global reference table exploded).
We currently scan pin table entries at the same time as the JNI global
references, so they'll still show up in hprof dumps as such. (Could
also add a new Android-specific hprof root category, but that seems like
more trouble than it's worth.)
|
| 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.)
|
| 03bd0d5b9b9d769e6e5245274204fbfd470de7f0 |
|
19-Aug-2009 |
Andy McFadden <fadden@android.com> |
Minor tweaks to JNI logging.
Reduced a LOGI to LOGD, normalized format, added a similar message for a
field ID lookup that was failing (due to a bad flash, as it turns out).
|
| 8e696dc0271299433cb3297e7aafc7bd0ee1b2b7 |
|
25-Jul-2009 |
Andy McFadden <fadden@android.com> |
JNI direct buffer function speedup, part 3.
This caches the effective address in a new field in the base Buffer
object. The first time something calls through one of the various
getEffectiveAddress calls, the value is set. (This seemed easier than
chasing down the constructors and factories, and also prevents bit rot
on the "slow path" in the VM.)
|
| 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.
|
| 5f612b82bbc2fcfb13865acd3c3835febab23466 |
|
23-Jul-2009 |
Andy McFadden <fadden@android.com> |
JNI direct buffer function speedup, part 1.
This is a fairly straightforward improvement to GetDirectBufferAddress,
caching classes and methodIDs instead of looking them up on every call.
This is the best we can do without making the function more vulnerable
to internal changes to Harmony's NIO implementation.
It looks like we need to take this farther, but this way we have a
relatively fast and relatively safe version to fall back on.
For internal bug 1943379.
|
| 72d61fba8ad3d3c720e6df61c7ae07baa4fd7838 |
|
25-Jun-2009 |
Andy McFadden <fadden@android.com> |
Check for failure in GetDirectBufferAddress.
We now check for a null result or a pending exception in the JNI
GetDirectBufferAddress function. This prevents a VM crash when somebody
tries to get the address of a non-direct buffer.
For internal bug 1926596.
|
| cda8f8abd1d02f5ab58add1ebb23f20fdab6341c |
|
24-Jun-2009 |
Andy McFadden <fadden@android.com> |
Merge 137552-p9 to donut.
Since we're apparently using these calls now, we probably ought to pull
the bug fix over. It's been in master for more than 3 months so it
should be safe. It'll also make future merges easier.
Prequel to fix for internal bug #1926596.
|
| 3a73bd95c7ea75a8e3814f76f4059c9ee7822fe0 |
|
05-Jun-2009 |
Andy McFadden <fadden@android.com> |
Fix JNI GetDirectBufferAddress.
The GetDirectBufferAddress JNI function was using the buffer's base
address, rather than it's "effective" base address. The difference
becomes important when you create a direct buffer by "slicing" it off
of another at a nonzero offset.
For internal bug 1898762.
|
| 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).
|
| 99409883d9c4c0ffb49b070ce307bb33a9dfe9f1 |
|
19-Mar-2009 |
The Android Open Source Project <initial-contribution@android.com> |
auto import //branches/master/...@140412
|
| 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
|
| 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
|