| d394371bd84bacc51e96e2d2eacb8549d9110b1e |
|
09-Sep-2010 |
Dan Bornstein <danfuzz@android.com> |
Remove the functionality in ReduceConstants.[ch].
It was a good experiment to try, but it was never made production-ready,
and it doesn't look like it would be a net win at this point. We
metaphorically pour out a beer in its honor.
Change-Id: I7f6ac95f5b7c963df0a3015ed33595fa1a928636
|
| fb119e6cf8b47d53f024cae889487a17eacbf19f |
|
29-Jun-2010 |
Andy McFadden <fadden@android.com> |
Emit volatile field access instructions.
Easier said than done. The trick is that we need to ensure that the
instruction replacement happens even if the verifier and optimizer
are not enabled in dexopt.
We're currently doing the -wide-volatile replacement during
verification, but that's not so great, since we collapse things like
iget-byte and iget-char into a single iget-volatile, losing the field
width. We could recover it from the field declaration, but doing it
during verification is really just sort of wrong to begin with.
The substitution isn't technically an "optimization", but it's easiest
to do it during the opt pass, and we already have a convenient "is
optimized" flag that helps ensure that we do the replacement pass
exactly once.
Optimizing at run time means making a private copy of shared pages,
because the pages are mapped shared/read-only out of the DEX file.
We could use up a lot of physical memory if we applied all possible
optimizations, so we need a notion of "essential" and "non-essential"
optimizations. If we're not running in dexopt, we only do the
essential ones, which should leave most methods untouched.
Replacement of 32-bit instructions is only strictly necessary when
we're building for SMP. On a uniprocessor, the 32-bit operations
are inherently atomic, and memory barriers aren't required. However,
the JIT may benefit from having volatile accesses identified by opcode.
Since the current branch doesn't support any SMP products, I'm enabling
the instruction generation for all platforms so that we can give it
some exercise.
While making this change I noticed that the exclusion mechanism for
breakpoints and optimization/verification was only serving to avoid
a data race (e.g. breakpoint being overwritten by an instruction
rewrite). It wasn't guaranteed to prevent races when two threads
toggled pages between read-write and read-only while making an update,
since a 4K page can hold code for more than one class. This has been
corrected by adding a mutex.
This change:
- Introduces the notion of essential vs. non-essential optimizations.
- Adds generation of 32-bit *-volatile instructions for all platforms.
- Moves generation of *-wide-volatile from the verifier to the optimizer.
- Allows the optimizer to modify code at run time.
- Tweaks optimizeMethod() for "best effort" rather than "fail early".
- Adds a DEX-granularity mutex to the bytecode update functions.
This also begins the removal of PROFILE_FIELD_ACCESS, which hasn't been
used for much and is mostly just in the way.
Change-Id: I4ac9fa5e1ac5f9a1d106c662c3deee90d62895aa
|
| 7365493ad8d360c1dcf9cd8b6eee62747af01cae |
|
09-Jun-2010 |
Carl Shapiro <cshapiro@google.com> |
Remove repeated newlines at the end of files.
Change-Id: I1e3d103a7b932ef21acedb6438c0f26b315df28f
|
| b5ebe47515c9750c7347557075d3714ba7671aa9 |
|
17-Nov-2009 |
Andy McFadden <fadden@android.com> |
Restore support for DEX on FAT.
The recent change to mmap(read-write)+mprotect(read-only) doesn't seem
to work on FAT filesystems like /sdcard. This caused problems for the
code that opens Zip files and the code that opens DEX files.
This change splits the "map file" function into "read only" and
"writable read only" versions, using the former for Zip and the latter
for DEX. Further, failure to mprotect(read-only) is now considered a
soft failure and only causes a warning.
The only apps that will be affected by this are those using /sdcard to
hold optimized DEX data for "plugin" APKs.
Also: moved the non-HAVE_POSIX_FILEMAP implementation of file mapping
into a shared function. (Could probably go away entirely.)
Also: fixed the expected output for test 071.
|
| 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
|
| e1f560a62949e9a673a58a37a8c72dc8b15d9563 |
|
02-Apr-2009 |
Andy McFadden <> |
AI 144244: Don't try to verify the checksum of a partially-created DEX file.
BUG=1749836
Automated import of CL 144244
|
| 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
|
| 5d709784bbf5001012d7f25172927d46f6c1abe1 |
|
11-Feb-2009 |
The Android Open Source Project <initial-contribution@android.com> |
auto import from //branches/cupcake/...@130745
|
| 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
|