Android 官方的文件,可直接看 android/dalvik/docs/embedded-vm-control.html

 

Controlling the Embedded VM

Overview

The Dalvik VM supports a variety of command-line arguments (use adb shell dalvikvm -help to get a summary), but it's not possible to pass arbitrary arguments through the Android application runtime. It is, however, possible to affect the VM behavior through certain system properties.

For all of the features described below, you would set the system property with setprop, issuing a shell command on the device like this:

adb shell setprop <name> <value>

 

The Android runtime must be restarted before the changes will take effect (adb shell stop; adb shell start). This is because the settings are processed in the "zygote" process, which starts early and stays around "forever".

You may not be able to set this as an unprivileged user. You can use adb root or run the su command from the device shell on "userdebug" builds to become root first. When in doubt,

adb shell getprop <name>

will tell you if the setprop took.

 

If you don't want the property to evaporate when the device reboots, add a line to /data/local.prop that looks like:

<name> = <value>

 

Such changes will survive reboots, but will be lost if the data partition is wiped. (Hint: create a local.prop on your workstation, then adb push local.prop /data . Or, use one-liners like adb shell "echo name = value >> /data/local.prop" -- note the quotes are important.)

Extended JNI Checks

JNI, the Java Native Interface, provides a way for code written in the Java programming language interact with native (C/C++) code. The extended JNI checks will cause the system to run more slowly, but they can spot a variety of nasty bugs before they have a chance to cause problems.

There are two system properties that affect this feature, which is enabled with the -Xcheck:jni command-line argument. The first is ro.kernel.android.checkjni. This is set by the Android build system for development builds. (It may also be set by the Android emulator unless the -nojni flag is provided on the emulator command line.) Because this is an "ro." property, the value cannot be changed once the device has started.

To allow toggling of the CheckJNI flag, a second property, dalvik.vm.checkjni, is also checked. The value of this overrides the value from ro.kernel.android.checkjni.

If neither property is defined, or dalvik.vm.checkjni is set to false, the -Xcheck:jni flag is not passed in, and JNI checks will be disabled.

To enable JNI checking:

adb shell setprop dalvik.vm.checkjni true

 

You can also pass JNI-checking options into the VM through a system property. The value set for dalvik.vm.jniopts will be passed in as the -Xjniopts argument. For example:

adb shell setprop dalvik.vm.jniopts forcecopy

 

For more information about JNI checks, see JNI Tips.

Assertions

Dalvik VM supports the Java programming language "assert" statement. By default they are off, but the dalvik.vm.enableassertions property provides a way to set the value for a -ea argument.

The argument behaves the same as it does in other desktop VMs. You can provide a class name, a package name (followed by "..."), or the special value "all".

For example, this:

adb shell setprop dalvik.vm.enableassertions all

enables assertions in all non-system classes.

 

The system property is much more limited than the full command line. It is not possible to specify more than one -ea entry, and there is no way to specify a -da entry. There is presently no equivalent for -esa/-dsa.

Bytecode Verification and Optimization

The system tries to pre-verify all classes in a DEX file to reduce class load overhead, and performs a series of optimizations to improve runtime performance. Both of these are done by the dexopt command, either in the build system or by the installer. On a development device, dexopt may be run the first time a DEX file is used and whenever it or one of its dependencies is updated ("just-in-time" optimization and verification).

There are two command-line flags that control the just-in-time verification and optimization, -Xverify and -Xdexopt. The Android framework configures these based on the dalvik.vm.dexopt-flags property.

If you set:

adb shell setprop dalvik.vm.dexopt-flags v=a,o=v

then the framework will pass -Xverify:all -Xdexopt:verified to the VM. This enables verification, and only optimizes classes that successfully verified. This is the safest setting, and is the default.

 

You could also set dalvik.vm.dexopt-flags to v=n to have the framework pass -Xverify:none -Xdexopt:verified to disable verification. (We could pass in -Xdexopt:all to allow optimization, but that wouldn't necessarily optimize more of the code, since classes that fail verification may well be skipped by the optimizer for the same reasons.) Classes will not be verified by dexopt, and unverified code will be loaded and executed.

Enabling verification will make the dexopt command take significantly longer, because the verification process is fairly slow. Once the verified and optimized DEX files have been prepared, verification incurs no additional overhead except when loading classes that failed to pre-verify.

If your DEX files are processed with verification disabled, and you later turn the verifier on, application loading will be noticeably slower (perhaps 40% or more) as classes are verified on first use.

For best results you should force a re-dexopt of all DEX files when this property changes. You can do this with:

adb shell "rm /data/dalvik-cache/*"

This removes the cached versions of the DEX files. Remember to stop and restart the runtime (adb shell stop; adb shell start).

 

(Previous version of the runtime supported the boolean dalvik.vm.verify-bytecode property, but that has been superceded by dalvik.vm.dexopt-flags.)

Execution Mode

The current implementation of the Dalvik VM includes three distinct interpreter cores. These are referred to as "fast", "portable", and "debug". The "fast" interpreter is optimized for the current platform, and might consist of hand-optimized assembly routines. In constrast, the "portable" interpreter is written in C and expected to run on a broad range of platforms. The "debug" interpreter is a variant of "portable" that includes support for profiling and single-stepping.

The VM may also support just-in-time compilation. While not strictly a different interpreter, the JIT compiler may be enabled or disabled with the same flag. (Check the output of dalvikvm -help to see if JIT compilation is enabled in your VM.)

The VM allows you to choose between "fast", "portable", and "jit" with an extended form of the -Xint argument. The value of this argument can be set through the dalvik.vm.execution-mode system property.

To select the "portable" interpreter, you would use:

adb shell setprop dalvik.vm.execution-mode int:portable

If the property is not specified, the most appropriate interpreter will be selected automatically. At some point this mechanism may allow selection of other modes, such as JIT compilation.

 

Not all platforms have an optimized implementation. In such cases, the "fast" interpreter is generated as a series of C stubs, and the result will be slower than the "portable" version. (When we have optimized versions for all popular architectures the naming convention will be more accurate.)

If profiling is enabled or a debugger is attached, the VM switches to the "debug" interpreter. When profiling ends or the debugger disconnects, the original interpreter is resumed. (The "debug" interpreter is substantially slower, something to keep in mind when evaluating profiling data.)

Deadlock Prediction

If the VM is built with WITH_DEADLOCK_PREDICTION, the deadlock predictor can be enabled with the -Xdeadlockpredict argument. (The output from dalvikvm -help will tell you if the VM was built appropriately -- look for deadlock_predictionon the Configured with: line.) This feature tells the VM to keep track of the order in which object monitor locks are acquired. If the program attempts to acquire a set of locks in a different order from what was seen earlier, the VM logs a warning and optionally throws an exception.

The command-line argument is set based on the dalvik.vm.deadlock-predict property. Valid values are off to disable it (default), warn to log the problem but continue executing, err to cause a dalvik.system.PotentialDeadlockError to be thrown from the monitor-enter instruction, and abort to have the entire VM abort.

You will usually want to use:

adb shell setprop dalvik.vm.deadlock-predict err

unless you are keeping an eye on the logs as they scroll by.

 

Please note that this feature is deadlock prediction, not deadlock detection -- in the current implementation, the computations are performed after the lock is acquired (this simplifies the code, reducing the overhead added to every mutex operation). You can spot a deadlock in a hung process by sending a kill -3 and examining the stack trace written to the log.

This only takes monitors into account. Native mutexes and other resources can also be the cause of deadlocks, but will not be detected by this.

Stack Dumps

Like other desktop VMs, when the Dalvik VM receives a SIGQUIT (Ctrl-\ or kill -3), it dumps stack traces for all threads. By default this goes to the Android log, but it can also be written to a file.

The dalvik.vm.stack-trace-file property allows you to specify the name of the file where the thread stack traces will be written. The file will be created (world writable) if it doesn't exist, and the new information will be appended to the end of the file. The filename is passed into the VM via the -Xstacktracefile argument.

For example:

adb shell setprop dalvik.vm.stack-trace-file /tmp/stack-traces.txt

 

If the property is not defined, the VM will write the stack traces to the Android log when the signal arrives.

DEX File Checksums

For performance reasons, the checksum on "optimized" DEX files is ignored. This is usually safe, because the files are generated on the device, and have access permissions that prevent modification.

If the storage on a device becomes unreliable, however, data corruption can occur. This usually manifests itself as a repeatable virtual machine crash. To speed diagnosis of such failures, the VM provides the -Xcheckdexsum argument. When set, the checksums on all DEX files are verified before the contents are used.

The application framework will provide this argument during VM creation if the dalvik.vm.check-dex-sum property is enabled.

To enable extended DEX checksum verification:

adb shell setprop dalvik.vm.check-dex-sum true

 

Incorrect checksums will prevent the DEX data from being used, and will cause errors to be written to the log file. If a device has a history of problems it may be useful to add the property to /data/local.prop.

Note also that the dexdump tool always verifies DEX checksums, and can be used to check for corruption in a large set of files.

Copyright © 2008 The Android Open Source Project
部分翻譯

來源: http://blog.chinaunix.net/u2/85193/showart_2094869.html

嵌入式虛擬機控制

    *概述
    *擴展JNI檢查
    *斷言
    *字節碼驗證和優化
    *執行模式
    *死鎖預測
    *堆棧轉儲

#############################################
概覽

Dalvik虛擬機支持各種命令行參數(通過adb shell dalvikvm - help來獲取幫助手冊),但它不可能通過Android應用程序運行環境傳遞任意參數。此外,可以通過設置某些系統屬影響虛擬機的行為。 

對於下面描述的所有功能,均可以通過setprop命令設置系統屬性,例如:

adb shell setprop <name> <value>

這些命令需要重啟Android運行環境才能生效。(adb shell stop;adb shell start). 這是因為所有的設置均在"zygote"守護進程中處理。

你還可以通過在/data/local.prop中增加:

<name> = <value>

來設置系統屬性。

這些改動需要在系統重啟後生效,但是會被wipe data(清除Data分區)命令刪除。

(提示: 可以在本地創建local.prop,並且通過adb push local.pro /data傳入)

################################################

擴展JNI檢查

JNI, 即Java本地接口,提供用Java編程語言編寫的代碼與C/C++代碼交互的一種方式。擴展的JNI檢查會導致系統運行變慢,但是他們可以在很多Bug導致嚴重問題前發現這些Bug.

可以通過-Xcheck:jni命令行參數啟用擴展JNI檢查。
有兩個系統屬性影響這項功能:
首先是ro.kernel.android.checkjni,這個在Android編譯系統中編譯開發版本時設置。(在Android模擬器上,除非啟動模擬器時設置了模擬器命令行參數-nojni,否則該功能都默認被啟用)。因為這是一個"ro."屬性,一旦設備啟動,該屬性便不能被改變。

譯者添加:
PS: Android編譯系統裡設置ro.kernel.android.checkjni 位於 build/core/main.mk 中。

為了允許切換該CheckJNI標誌,第二個屬性即dalvik.vm.checkjni,也會被檢查。
這個屬性值會覆蓋ro.kernel.android.checkjni.

如果這兩個系統屬性值均沒有被定義,或者dalvik.vm.checkjni被設置為false.
-Xcheck:jni 設置的參數也不會被傳入,並且也不會啟用JNI檢查。

打開JNI檢查:

adb shell setprop dalvik.vm.checkjni true

也可以通過 -Xjniopts 參數設置dalvik.vm.jniopts值,打開虛機的JNI-checking選項。

瞭解更多 JNI checks信息,請看 JNI tips.

################################################
斷言

Dalvik虛擬機支持Java編程語言“斷言”.默認情況下該支持是關閉的,但是提供通過 -ea參數設置dalvik.vm.enableassertion值。

該參數與在其他VM中的作用相同。你可以傳入一個類名,包名,或者特殊值"all".

例如:

adb shell setprop dalvik.vm.enableassertions all

在所有非系統類裡,可以進行斷言。

該系統屬性比起full command line有很多限制。 這是因為不能指定多個-ea入口,並且也無法指定一個-da入口。目前沒有提供與-esa/-dsa等價的功能。

################################################
字節碼驗證與優化 

系統試圖預先驗證dex文件中的所有類,以減少類加載開銷,並進行一系列優化來提高運行性能。無論是在編譯還是安裝,預驗證與優化均通過調用dexopt命令執行。在開發版本中,dexopt將會在dex文件第一次被使用以及該文件或其依賴的文件被更新時執行(“just-in-time”實時優化和驗證)。

有兩個命令標誌來控制實時驗證和優化,即-Xverify以及-Xdexopt.Android framework會基於dalvik vm.dexopt標誌來配置這些屬性。

如果設置:

adb shell setprop dalvik.vm.dexopt-flags v=a,o=v

framework則會傳遞 -Xverify:all -Xdexopt:verified 參數到vm.打開驗證,並且驗證成功後進行類的優化。這是最安全的,也是默認的設置。

也可以設置dalvik.vm.dexopt-flags為v=n,framwork則會傳遞 -Xvreify:none -Xdexopt:verified參數來禁止驗證。(我們可以傳遞 -Xdexopt:all 來允許優化,但是不一定會優化更多的代碼,因為類驗證失敗很可能會導致跳過類的優化)。沒有經過dexopt驗證的類,將會作為未經核實的代碼加載並執行。

啟用驗證將會似的dexopt命令執行時間大大延長,因為驗證過程是非常耗時的。一旦dex文件已經經過驗證和優化,除非之前的驗證失敗,再次驗證則不會花費額外的開銷。

如果一開始禁用了驗證,而之後又將驗證打開,加在應用程序的速度將會顯著下降(大約40%或更多),因為在第一次使用時會進行類的驗證。

為了獲得最佳效果,應當在該屬性改變時就對所有dex文件強制執行re-dexopt。

adb shell "rm /data/dalvik-cache/*"

這會清除dex文件的緩存版本。記住要停止並且重啟運行環境。

(adb shell stop;adb shell start)

################################################

huenlil 發表在 痞客邦 PIXNET 留言(0) 人氣()