diff options
author | Android Partner Docs <noreply@android.com> | 2017-10-30 14:17:31 -0700 |
---|---|---|
committer | Billy Lamberta <blamb@google.com> | 2017-10-30 14:25:52 -0700 |
commit | b4d6e7c64809106953f045fb5e88415028416a1a (patch) | |
tree | 39368fb820331b06cf8f1a4f1019618fbd9f121e /en/devices | |
parent | 96deba20c83e0d2756e4c7861622a554955fe8db (diff) | |
download | source.android.com-b4d6e7c64809106953f045fb5e88415028416a1a.tar.gz |
Docs: Changes to source.android.com
- 173948031 Add OWNERS.android file for find-owners plugin. Used by G... by Billy Lamberta <blamb@google.com>
- 173776667 Update debuggerd docs for O. by Android Partner Docs <noreply@android.com>
- 173720411 Add section for faster native methods. by Billy Lamberta <blamb@google.com>
- 173689528 Devsite localized content from translation request fe9324... by Android Partner Docs <noreply@android.com>
- 173689519 Devsite localized content from translation request 2d4a7b... by Android Partner Docs <noreply@android.com>
- 173558006 Devsite localized content from translation request 923cb2... by Android Partner Docs <noreply@android.com>
- 173409559 Devsite localized content from translation request 5edac3... by Android Partner Docs <noreply@android.com>
- 173409556 Devsite localized content from translation request cb5732... by Android Partner Docs <noreply@android.com>
- 173409550 Devsite localized content from translation request cf8a60... by Android Partner Docs <noreply@android.com>
- 173268562 Devsite localized content from translation request 4cfd64... by Android Partner Docs <noreply@android.com>
- 173209155 Update build numbers for Oreo DR releases by Android Partner Docs <noreply@android.com>
- 173187065 Devsite localized content from translation request 6733e6... by Android Partner Docs <noreply@android.com>
- 173150380 Add parentheses after .bash_profile function name for rea... by Christina Nguyen <cqn@google.com>
PiperOrigin-RevId: 173948031
Change-Id: Ia1ad2f2bed814cbd407cca162c700496fde40da7
Diffstat (limited to 'en/devices')
-rw-r--r-- | en/devices/tech/dalvik/improvements.html | 365 | ||||
-rw-r--r-- | en/devices/tech/debug/index.html | 58 |
2 files changed, 268 insertions, 155 deletions
diff --git a/en/devices/tech/dalvik/improvements.html b/en/devices/tech/dalvik/improvements.html index aa41a1f0..9317e336 100644 --- a/en/devices/tech/dalvik/improvements.html +++ b/en/devices/tech/dalvik/improvements.html @@ -22,131 +22,161 @@ --> <p> -The Android runtime (ART) has been improved significantly in the Android 8.0 -release. The list below summarizes enhancements device manufacturers can expect -in ART. + The Android runtime (ART) has been improved significantly in the Android 8.0 + release. The list below summarizes enhancements device manufacturers can expect + in ART. </p> <h2 id="concurrent-compacting-gc">Concurrent compacting garbage collector</h2> -<p>As announced at Google I/O, ART features a new concurrent compacting garbage -collector (GC) in Android 8.0. This collector compacts the heap every time GC -runs and while the app is running, with only one short pause for processing -thread roots. Here are its benefits:</p> +<p> + As announced at Google I/O, ART features a new concurrent compacting garbage + collector (GC) in Android 8.0. This collector compacts the heap every time GC + runs and while the app is running, with only one short pause for processing + thread roots. Here are its benefits: +</p> <ul> - <li>GC always compacts the heap: 32% smaller heap sizes on average compared - to Android 7.0.</li> - <li>Compaction enables thread local bump pointer object allocation: - Allocations are 70% faster than in Android 7.0.</li> - <li>Offers 85% smaller pause times for the H2 benchmark compared to the - Android 7.0 GC.</li> - <li>Pause times no longer scale with heap size; apps should be able to use - large heaps without worrying about jank.</li> + <li> + GC always compacts the heap: 32% smaller heap sizes on average compared to + Android 7.0. + </li> + <li> + Compaction enables thread local bump pointer object allocation: Allocations + are 70% faster than in Android 7.0. + </li> + <li> + Offers 85% smaller pause times for the H2 benchmark compared to the Android + 7.0 GC. + </li> + <li> + Pause times no longer scale with heap size; apps should be able to use large + heaps without worrying about jank. + </li> <li>GC implementation detail - Read barriers: <ul> - <li>Read barriers are a small amount of work done for each object field - read.</li> - <li>These are optimized in the compiler, but might slow down some use - cases.</li> + <li> + Read barriers are a small amount of work done for each object field read. + </li> + <li> + These are optimized in the compiler, but might slow down some use cases. + </li> </ul> </ul> <h2 id="loop-optimizations">Loop optimizations</h2> <p> -A wide variety of loop optimizations are employed by ART in the Android 8.0 -release: -</p> - <ul> - <li>Bounds check eliminations - <ul> - <li>Static: ranges are proven to be within bounds at compile-time - <li>Dynamic: run-time tests ensure loops stay within bounds (deopt otherwise) - </ul> - <li>Induction variable eliminations - <ul> - <li>Remove dead induction - <li>Replace induction that is used only after the loop by closed-form expressions - </ul> - <li>Dead code elimination inside the loop-body, removal of whole loops that -become dead - <li>Strength reduction - <li>Loop transformations: reversal, interchanging, splitting, unrolling, -unimodular, etc. - <li>SIMDization (also called vectorization)</li> - </ul> - -<p> -The loop optimizer resides in its own optimization pass in the ART compiler. -Most loop optimizations are similar to optimizations and simplification -elsewhere. Challenges arise with some optimizations that rewrite the CFG in a -more than usual elaborate way, because most CFG utilities (see nodes.h) focus on -building a CFG, not rewriting one. + A wide variety of loop optimizations are employed by ART in the Android 8.0 + release: +</p> + +<ul> + <li>Bounds check eliminations + <ul> + <li>Static: ranges are proven to be within bounds at compile-time</li> + <li> + Dynamic: run-time tests ensure loops stay within bounds (deopt otherwise) + </li> + </ul> + </li> + <li>Induction variable eliminations + <ul> + <li>Remove dead induction</li> + <li> + Replace induction that is used only after the loop by closed-form + expressions + </li> + </ul> + </li> + <li> + Dead code elimination inside the loop-body, removal of whole loops that + become dead + </li> + <li>Strength reduction</li> + <li> + Loop transformations: reversal, interchanging, splitting, unrolling, + unimodular, etc. + </li> + <li>SIMDization (also called vectorization)</li> +</ul> + +<p> + The loop optimizer resides in its own optimization pass in the ART compiler. + Most loop optimizations are similar to optimizations and simplification + elsewhere. Challenges arise with some optimizations that rewrite the CFG in a + more than usual elaborate way, because most CFG utilities (see nodes.h) focus + on building a CFG, not rewriting one. </p> <h2 id="class-hierarchy-analysis">Class hierarchy analysis</h2> <p> -ART in Android 8.0 uses Class Hierarchy Analysis (CHA), a compiler optimization -that devirtualizes virtual calls into direct calls based on the information -generated by analyzing class hierarchies. Virtual calls are expensive since they -are implemented around a vtable lookup, and they take a couple of dependent -loads. Also virtual calls cannot be inlined. -</p> - -<p> -Here is a summary of related enhancements: -</p> - <ul> - <li>Dynamic single-implementation method status updating - At the end of class -linking time, when vtable has been populated, ART conducts an entry-by-entry -comparison to the vtable of the super class.</li> - <li>Compiler optimization - The compiler will take advantage of the -single-implementation info of a method. If a method A.foo has -single-implementation flag set, compiler will devirtualize the virtual call into -a direct call, and further try to inline the direct call as a result.</li> - <li>Compiled code invalidation - Also at the end of class linking time when -single-implementation info is updated, if method A.foo that previously had -single-implementation but that status is now invalidated, all compiled code that -depends on the assumption that method A.foo has single-implementation needs to -have their compiled code invalidated.</li> - <li>Deoptimization - For live compiled code that's on stack, deoptimization will -be initiated to force the invalidated compiled code into interpreter mode to -guarantee correctness. A new mechanism of deoptimization which is a hybrid of -synchronous and asynchronous deoptimization will be used.</li> + ART in Android 8.0 uses Class Hierarchy Analysis (CHA), a compiler optimization + that devirtualizes virtual calls into direct calls based on the information + generated by analyzing class hierarchies. Virtual calls are expensive since + they are implemented around a vtable lookup, and they take a couple of + dependent loads. Also virtual calls cannot be inlined. +</p> + +<p>Here is a summary of related enhancements:</p> + +<ul> + <li> + Dynamic single-implementation method status updating - At the end of class + linking time, when vtable has been populated, ART conducts an entry-by-entry + comparison to the vtable of the super class. + </li> + <li>Compiler optimization - The compiler will take advantage of the + single-implementation info of a method. If a method A.foo has + single-implementation flag set, compiler will devirtualize the virtual call + into a direct call, and further try to inline the direct call as a result. + </li> + <li> + Compiled code invalidation - Also at the end of class linking time when + single-implementation info is updated, if method A.foo that previously had + single-implementation but that status is now invalidated, all compiled code + that depends on the assumption that method A.foo has single-implementation + needs to have their compiled code invalidated. + </li> + <li> + Deoptimization - For live compiled code that's on stack, deoptimization will + be initiated to force the invalidated compiled code into interpreter mode to + guarantee correctness. A new mechanism of deoptimization which is a hybrid of + synchronous and asynchronous deoptimization will be used. + </li> </ul> <h2 id="inline-caches-in-oat-files">Inline caches in .oat files</h2> <p> -ART now employs inline caches and optimizes the call sites for which enough data -exists. The inline caches feature records additional runtime information into -profiles and uses it to add dynamic optimizations to ahead of time compilation. + ART now employs inline caches and optimizes the call sites for which enough + data exists. The inline caches feature records additional runtime information + into profiles and uses it to add dynamic optimizations to ahead of time compilation. </p> <h2 id="dexlayout">Dexlayout</h2> <p> -Dexlayout is a library introduced in Android 8.0 to analyze dex files and reorder -them according to a profile. Dexlayout aims to use runtime profiling information -to reorder sections of the dex file during idle maintenance compilation on -device. By grouping together parts of the dex file that are often accessed -together, programs can have better memory access patterns from improved -locality, saving RAM and shortening start up time. + Dexlayout is a library introduced in Android 8.0 to analyze dex files and + reorder them according to a profile. Dexlayout aims to use runtime profiling + information to reorder sections of the dex file during idle maintenance + compilation on device. By grouping together parts of the dex file that are + often accessed together, programs can have better memory access patterns from + improved locality, saving RAM and shortening start up time. </p> <p> -Since profile information is currently available only after apps have been run, -dexlayout is integrated in dex2oat's on-device compilation during idle -maintenance. + Since profile information is currently available only after apps have been run, + dexlayout is integrated in dex2oat's on-device compilation during idle + maintenance. </p> <h2 id="dex-cache-removal">Dex cache removal</h2> <p> -Up to Android 7.0, the DexCache object owned four large arrays, proportional to the -number of certain elements in the DexFile, namely: + Up to Android 7.0, the DexCache object owned four large arrays, proportional to + the number of certain elements in the DexFile, namely: </p> <ul> @@ -172,60 +202,145 @@ number of certain elements in the DexFile, namely: <h2 id="interpreter-performance">Interpreter performance</h2> <p> -Interpreter performance significantly improved in the Android 7.0 release with the -introduction of "mterp" - an interpreter featuring a core fetch/decode/interpret -mechanism written in assembly language. Mterp is modelled after the fast Dalvik -interpreter, and supports arm, arm64, x86, x86_64, mips and mips64. For -computational code, Art's mterp is roughly comparable to Dalvik's fast -interpreter. However, in some situations it can be significantly - and even -dramatically - slower: + Interpreter performance significantly improved in the Android 7.0 release with + the introduction of "mterp" - an interpreter featuring a core + fetch/decode/interpret mechanism written in assembly language. Mterp is + modelled after the fast Dalvik interpreter, and supports arm, arm64, x86, + x86_64, mips and mips64. For computational code, Art's mterp is roughly + comparable to Dalvik's fast interpreter. However, in some situations it can be + significantly - and even dramatically - slower: </p> - <ol> - <li>Invoke performance.</li> - <li>String manipulation, and other heavy users of methods recognized as -intrinsics in Dalvik.</li> - <li>Higher stack memory usage.</li> - </ol> +<ol> + <li>Invoke performance.</li> + <li> + String manipulation, and other heavy users of methods recognized as + intrinsics in Dalvik. + </li> + <li>Higher stack memory usage.</li> +</ol> -<p> -Android 8.0 addresses these issues. -</p> +<p>Android 8.0 addresses these issues.</p> <h2 id="more-inlining">More inlining</h2> <p> -Since Android 6.0, ART can inline any call within the same dex files, but could -only inline leaf methods from different dex files. There were two reasons for -this limitation: + Since Android 6.0, ART can inline any call within the same dex files, but could + only inline leaf methods from different dex files. There were two reasons for + this limitation: </p> - <ol> - <li>Inlining from another dex file requires to use the dex cache of that other -dex file, unlike same dex file inlining, which could just re-use the dex cache -of the caller. The dex cache is needed in compiled code for a couple of -instructions like static calls, string load, or class load. - <li>The stack maps are only encoding a method index within the current dex -file.</li> - </ol> +<ol> + <li> + Inlining from another dex file requires to use the dex cache of that other + dex file, unlike same dex file inlining, which could just re-use the dex cache + of the caller. The dex cache is needed in compiled code for a couple of + instructions like static calls, string load, or class load. + <li> + The stack maps are only encoding a method index within the current dex file. + </li> +</ol> -<p> -To address these limitations, Android 8.0: -</p> +<p>To address these limitations, Android 8.0:</p> - <ol> - <li>Removes dex cache access from compiled code (also see section "Dex cache +<ol> + <li>Removes dex cache access from compiled code (also see section "Dex cache removal")</li> - <li>Extends stack map encoding.</li> - </ol> + <li>Extends stack map encoding.</li> +</ol> <h2 id="synchronization-improvements">Synchronization improvements</h2> + +<p> + The ART team tuned the MonitorEnter/MonitorExit code paths, and reduced our + reliance on traditional memory barriers on ARMv8, replacing them with newer + (acquire/release) instructions where possible. +</p> + +<h2 id="faster-native-methods">Faster native methods</h2> + +<p> + Faster native calls to the Java Native Interface (JNI) are available using + the <a class="external" +href="https://android.googlesource.com/platform/libcore/+/master/dalvik/src/main/java/dalvik/annotation/optimization/FastNative.java" +><code>@FastNative</code></a> and <a class="external" +href="https://android.googlesource.com/platform/libcore/+/master/dalvik/src/main/java/dalvik/annotation/optimization/CriticalNative.java" +><code>@CriticalNative</code></a> annotations. These built-in ART runtime + optimizations speed up JNI transitions and replace the now deprecated + <em>!bang JNI</em> notation. The annotations have no effect on non-native + methods and are only available to platform Java Language code on the + <code>bootclasspath</code> (no Play Store updates). +</p> <p> -The ART team tuned the MonitorEnter/MonitorExit code paths, and reduced our -reliance on traditional memory barriers on ARMv8, replacing them with newer -(acquire/release) instructions where possible. + The <code>@FastNative</code> annotation supports non-static methods. Use this + if a method accesses a <code>jobject</code> as a parameter or return value. </p> +<p> + The <code>@CriticalNative</code> annotation provides an even faster way to run + native methods, with the following restrictions: +</p> + +<ul> + <li> + Methods must be static—no objects for parameters, return values, or an + implicit <code>this</code>. + </li> + <li>Only primitive types are passed to the native method.</li> + <li> + The native method does not use the <code>JNIEnv</code> and + <code>jclass</code> parameters in its function definition. + </li> + <li> + The method must be registered with <code>RegisterNatives</code> instead of + relying on dynamic JNI linking. + </li> +</ul> + +<aside class="caution"> + <p> + The <code>@FastNative</code> and <code>@CriticalNative</code> annotations + disable garbage collection while executing a native method. Do not use with + long-running methods, including usually-fast, but generally unbounded, + methods. + </p> + <p> + Pauses to the garbage collection may cause deadlock. Do not acquire locks + during a fast native call if the locks haven't been released locally (i.e. + before returning to managed code). This does not apply to regular JNI calls + since ART considers the executing native code as suspended. + </p> +</aside> + +<p> + <code>@FastNative</code> can improve native method performance up to 3x, and + <code>@CriticalNative</code> up to 5x. For example, a JNI transition measured + on a Nexus 6P device: +</p> + +<table> + <tr> + <th>Java Native Interface (JNI) invocation</th> + <th>Execution time (in nanoseconds)</th> + </tr> + <tr> + <td>Regular JNI</td> + <td>115</td> + </tr> + <tr> + <td><em>!bang JNI</em></td> + <td>60</td> + </tr> + <tr> + <td><code>@FastNative</code></td> + <td>35</td> + </tr> + <tr> + <td><code>@CriticalNative</code></td> + <td>25</td> + </tr> +</table> + </body> </html> diff --git a/en/devices/tech/debug/index.html b/en/devices/tech/debug/index.html index 702b7a14..67b2fee2 100644 --- a/en/devices/tech/debug/index.html +++ b/en/devices/tech/debug/index.html @@ -35,8 +35,10 @@ characters. This meant that to create a wrap property with the name of the app, it was necessary to truncate the name to fit. In Android O and later, this limit is much greater and should require no truncation.</p> -<p>This page covers use of <code>debuggerd</code>, a daemon process for -collecting error information after applications crash. Other pages explore system services with +<p>This page covers the basics surrounding crash dumps found in logcat output. +Other pages have far more detail about +<a href="/devices/tech/debug/native-crash.html">diagnosing native crashes</a>, +exploring system services with <a href="https://developer.android.com/studio/command-line/dumpsys.html"> <code>dumpsys</code></a>, viewing @@ -46,26 +48,28 @@ collecting error information after applications crash. Other pages explore syste <a href="/devices/tech/debug/asan.html">AddressSanitizer</a> to detect memory bugs in native code, evaluating <a href="/devices/tech/debug/eval_perf.html"> performance issues</a> (includes -<a href="/devices/tech/debug/systrace">systrace</a>), and using -<a href="/devices/tech/debug/gdb.html">GNU Project debugger (GDB)</a> and +<a href="/devices/tech/debug/systrace">systrace</a>), and using the +<a href="/devices/tech/debug/gdb.html">GNU debugger (GDB)</a> and other debugging tools.</p> -<h2 id=debuggerd>Using debuggerd</h2> +<h2 id=debuggerd>Crash dumps</h2> -<p>The <code>debuggerd</code> process dumps registers and unwinds the stack. -When a dynamically linked executable starts, several signal handlers are -registered that connect to <code>debuggerd</code> (or <code>debuggerd64)</code> -in the event that signals (such as SIGSEGV or SIGABRT) are sent to the process.</p> +<p>When a dynamically linked executable starts, several signal handlers are +registered that, in the event of a crash, cause a basic crash dump to be written to logcat +and a more detailed "tombstone" file to be written to <code>/data/tombstones/</code>. +The tombstone is a file with extra data about the crashed process. In particular, it contains +stack traces for all the threads in the crashing process (not just the thread that caught the +signal), a full memory map, and a list of all open file descriptors.</p> -<p>It's possible for <code>debuggerd</code> to attach only if nothing else is +Before Android 8.0, crashes were handled by the +<code>debuggerd</code> and <code>debuggerd64</code> daemons. In Android O and later, +<code>crash_dump32</code> and <code>crash_dump64</code> are spawned as needed.</p> + +<p>It's possible for the crash dumper to attach only if nothing else is already attached, which means using tools such as <code>strace</code> or -<code>gdb</code> will prevent <code>debuggerd</code> from working. You can also -explicitly prevent <code>debuggerd</code> from attaching by calling -<code>prctl(PR_SET_DUMPABLE, 0)</code>, which can be useful when you need to -opt out of crash reporting.</p> +<code>gdb</code> will prevent crash dumps from occurring.</p> -<p>Example <code>debuggerd</code> output (with timestamps and extraneous -information removed):</p> +<p>Example output (with timestamps and extraneous information removed):</p> <pre class="devsite-click-to-copy"> *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** @@ -90,18 +94,13 @@ backtrace: Tombstone written to: /data/tombstones/tombstone_06 </pre> -<p>The last line of <code>debuggerd</code> output dumps a summary to the log and -writes a full <em>tombstone</em> to disk. The tombstone is simply a file with -extra data about the crashed process; it contains information that can be -helpful in debugging a crash, in particular the stack traces for all threads in -the crashing process (not just the thread that caught the signal) and a full -memory map.</p> +<p>The last line of output gives the location of the full <em>tombstone</em> on disk.</p> -<p>Assuming the unstripped binaries can be found, you can get a more detailed -unwind with line number information by pasting the above example into +<p>Assuming you have the unstripped binaries available, you can get a more detailed +unwind with line number information by pasting the stack into <code>development/scripts/stack</code>:</p> -<p class="key-point"><strong>Tip:</strong> For convenience, if you've lunched +<p class="key-point"><strong>Tip:</strong> For convenience, if you've run <code>lunch</code> <code>stack</code> will be on your $PATH already so you don't need to give the full path.</p> @@ -109,7 +108,7 @@ full path.</p> development/tools/stack </pre> -<p>Example output:</p> +<p>Example output (based on the logcat output above):</p> <pre class="devsite-click-to-copy"> Reading native crash info from stdin 03-02 23:53:49.477 17951 17951 F DEBUG : *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** @@ -156,8 +155,7 @@ Stack Trace: <p class="note"><strong>Note:</strong> Some system libraries are built with <code>LOCAL_STRIP_MODULE := keep_symbols</code> to provide usable backtraces -directly from <code>debuggerd</code> without taking up anywhere near as much -space as an unstripped version.</p> +directly without taking up anywhere near as much space as an unstripped version.</p> <p>You can also <code>stack</code> an entire tombstone. Example:</p> <pre class="devsite-terminal devsite-click-to-copy"> @@ -170,8 +168,8 @@ For more information about diagnosing native crashes and tombstones, see <h2 id="tombstone">Getting a stack trace/tombstone from a running process</h2> -<p>You can also use <code>debuggerd</code> on a running process. From the -command line, invoke <code>debuggerd</code> using a process ID (PID) to dump the +<p>You can also use the <code>debuggerd</code> tool to get a stack dump from a running process. +From the command line, invoke <code>debuggerd</code> using a process ID (PID) to dump a full tombstone to <code>stdout</code>. To get just the stack for every thread in the process, include the <code>-b</code> or <code>--backtrace</code> flag.</p> |