前文「對 String 操作的改進」與「Android Dalvik VM vs. Java VM」談及基於 CVM 引擎的 Java VM 與 Dalvik 的效能差異後，最近 0xlab 內部也因為挑選硬體平台，持續分析 Embedded CaffeineMark 一類量化效能的報告。參考的硬體組態是 OMAP3/ARMv7 500 MHz，粗略的效能評比如下圖：

Dalvik 取自 0xdroid (cupcake + backported from donut)，而 CVM-jit 則源自 phoneME CVM svn r19264，整體分數為：

• Dalvik VM : 1034
• CVM + jit : 7526

CVM 的組態設定：

• cached constant
• cached constant inlining
• array init bounds check elimination
• Hardware fpu = NEON
• AAPCS

當然 Just-In-Time compiler 不是萬靈丹，從上述效能評比可發現，CVM 在若干地方做了重要的微調，比方說透過 CNI 實做若干 class library 的關鍵 method，以及善用硬體 floating-point 操作 (注意：本組態未引入 ARMv6 與 ARMv7 的 Thumb2/Thumb-EE 指令集)。儘管 Android 團隊中 Dalvik 開發者 fadden 在郵件討論群組談及：

Four String methods -- charAt, compareTo, equals, and length -- are
"inlined" by the VM, and are not going to get much faster.

There are probably a few others that could benefit from this
treatment, but I'm guessing that most string-centric processing in
Java will likely be dominated by the cost of String allocations. (The
above weren't inlined because of a measured performance need -- the
inlining was an experiment that needed a test subject.)

Dalvik 理論上可施加這些優化技術 (string allocation / native method inlining)，不過目前開放的實做中，尚未引入 (至少在 donut branch 中)。即便在保持 pure interpreter 的架構下，現有 class library 與 GC (garbage collector) 仍可作些調整，以改善 Android 的應用程式執行效能與 (圖形應用導向的) 使用者互動反應表現。

read on

本日仍在追蹤 0xdroid 的穩定性與效能議題，進行壓力測試時，順便將知名的 SDL 函式庫移植到 Android window system，更具體來說，就是允許在 Android Surface Manager (SurfaceFlinger) 上運作 SDL 應用程式，背景知識請參考 0xlab 圖形處理達人 olv 的簡報 "Introduction to Android Window System" (PDF)。依據 olv 提供的範例 SurfaceFlinger 操作程式，libSDL 可很快地加上 Android video backend，接著透過 libui 的 EventHub 取得來自 Linux input subsystem 的事件。現在初步的移植成果可參考下圖：
上圖展示一個以 SDL 撰寫的 NES 任天堂模擬器，顯示更新於新建立的 Android Surface 上，筆者將該 Android surface 的起始座標位置挪到 (100, 100)，並設定其半透明度值，載入筆者最愛的泡泡龍 (Bubble Bobble) 遊戲 ROM。目前僅算堪用的狀態，未來要考慮到 Android Surface 限制 color space 為 RGB565 (針對 16-bit depth 顯示所做的優化限制)，勢必得在 libSDL 引入若干 color space 轉換的繁瑣運算，可透過 ARM NEON 一類的硬體加速機制去改善效能。

read on

之前的文章「Android Dalvik VM vs. Java VM」提及純 interpreter 的 Dalvik VM 與具備 Just-In-Time compiler 的 JBend JVM (基於 CVM 引擎) 的效能比較，以修改過的 Embedded CaffeineMark 作為量化的依據，可發現 String 測試項目差了一個數量級 (491 vs. 5109)，整體的分數是 1:4.18 (1811:433)。稍早 ansoncat 做了初步分析：

「這部分應該是由於在 CVM 中，使用了 CNI 來實作 String class 的重要操作 ... 因為 String 的分數拉高了平均，其它 benchmark 的效能差異會比平均分數的差異大的多」

目前 0xdroid 在不更動 Dalvik VM 實做的前提 (後續再談改進的途徑)，對 bionic libc 的 string 相關函式作調整，移植來自 CodeSourcery/ARM 的 ARMv7 Thumb2 優化實做，就 micro-benchmark 的角度來說，效能改進約有 25% (初步分析，要考慮到不同的環境配置)，但整合到 Android/Dalvik 的表現又是如何呢？筆者的實驗結果如下： (score 大者為佳)

測試環境是 Beagleboard (500MHz) 運作 0xdroid，以 ARMv7 GNU Toolchain 編譯，"armv7" 是 bionic 更動前的數據，而 "armv7-opt" 則是更動後的表現。很顯然發現，String 一項的改進大幅受到壓抑 (score = 1898:2140)，致使兩者最終僅有些微的落差，可見 JNI 帶來 overhead 的著實不小。又，大部分應用程式的效能瓶頸往往在於圖形處理、系統資源的調度、檔案讀寫等 I/O 操作，所以現階段我們的想法是儘量調整 native 的部份，針對 ARM core 與 SoC 的特性作調整，並提出可行的輕量級 native method invocation 實做。

read on

Android 預設的 shell 就是 /system/bin/sh 這個 process，移植自 NetBSD 早期的 sh 程式，原本功能算是完整，但被 Android 開發團隊移去相當多功能，致使在 shell 下的操作苦不堪言，只好透過 adb 作遠端指令的下達，但問題是，移植 Android 的平台在初期往往缺乏有效的連線機制，又需要作些調整與嘗試，實在很不方便。所以筆者就在 0xlab 最近釋出的 0xdroid 專案上，引入來自 Busybox 的 ash 實做，試著保持相近的 footprint 的前提下，提供更多的功能。

因此，我們有以下考量：

• 必須動態連結到 bionic libc
• 簡化 Busybox 的實做，修改 libbb 與對應的 applet
• 保有 bash 相容模式, Line edit, history, readline 等 Busybox 特徵

稍早，0xlab 的成員 walkingice 就做了評估與實驗，讓整個 Busybox 得以動態連結到 bionic libc 並確保功能可運作，這部份有很多 hacking，暫時不談。現在這些更動已初步提交到 system/core repository。在 0xdroid 的 beagle-cupcake branch 下，相關的 ash 設定組態如下：

• CONFIG_ASH_BASH_COMPAT
• CONFIG_ASH_READ_NCHARS
• CONFIG_ASH_READ_TIMEOUT
• CONFIG_ASH_ALIAS
• CONFIG_ASH_GETOPTS
• CONFIG_ASH_BUILTIN_ECHO
• CONFIG_ASH_OPTIMIZE_FOR_SIZE
• CONFIG_ASH_EXPAND_PRMT

佔用的磁碟空間：

[build_host]$ ls -lh system/bin/{ash,sh}
87K 2009-08-13 02:24 system/bin/ash
98K 2009-08-13 01:15 system/bin/sh

佔用的記憶體空間：

[beagleboard] # ps
USER     PID   PPID  VSIZE RSS   WCHAN    PC         NAME
root     1     0     300   192   c00b2394 0000ca6c S /init
root     777   1     736   324   c0057648 afe0c3fc S /system/bin/sh
root     835   777   744   356   c0057648 afe0c3fc S /system/bin/ash

可以發現，新引入的 /system/bin/ash 佔用的磁碟與記憶體空間相似，但功能完整度卻大不相同，後者允許我們回顧歷史指令並編輯， 以及在 Embedded Linux 熟悉的操作環境。目前 ash 的移植還有很多調整改進的空間，不過算是堪用了，可在 init.rc 檔案中，將預設的 shell 指定為 /system/bin/ash。

read on

這幾周，0xlab 的開發者都在準備新的 Android distribution，標的平台是 Beagleboard，可望在 COSCUP 到來前釋出，過程中順便寫了一個簡單易用的 Image Installer，可從 SD card 開機並將可運作的 Android system image 植入 Beagleboard 之上的 NAND flash，而不必依據繁瑣的流程，才能體驗我們的新創作。目前已有初步成果，可參見下圖：
已實做的特徵有：

• 僅需要放置單一檔案 (uImage.bin) 到 VFAT 格式的 SD card 中，在 Beagleboard 插入 SD 開機進入 Image Installer，即有簡單俐落的 UI
• 整個 Image Installer (kernel + busybox + file system + MTD tools + UI) 佔用不到 2Mb 的空間
• 預設讀取 SD card 裡頭的 android_beagle.ubi 與 0xkernel-beagle.bin 兩個檔案，自動寫入 NAND flash，並設定必要的 u-boot 環境參數。放置 image 檔案的動作可在多數的作業系統平台下進行，舉凡 MS-Windows, GNU/Linux, Mac OS X 等等，只要支援 VFAT 與 SD/MMC 讀寫即可

貌似單純的 Image Installer 開發，卻折騰了好幾天，歸納有若干因素：

• 準備在 Beagleboard/OMAP3 環境下可最小可啟動的 Linux image，需要考慮到 device driver 間的相依性，比方說若將 USB subsystem 完全移除的話，很可能無法正常開機。又，OMAP3 內建的 MFD (Multi-Function Device) 要注意到驅動順序的議題，不然功能無法正確運作
• 要留意 TI OMAP3 / Beagleboard 啟動順序，即使 boot from SD，但 u-boot 與其 u-boot bootenv 很可能仍讀取自 NAND flash，這導致後續啟動的 Linux kernel 採用了預設值，致使 Image Installer 無法在預期的環境參數下啟動
• ARM/Linux 啟動過程中，會試圖自一段特別的記憶體空間讀取 command line parameters，這空間稱為 ATAGS，係由 boot loader (以 Beagleboard 來說就是由 X-Loader 帶起的 u-boot) 填寫的記憶體內容，也就是所謂的 u-boot bootenv。但對 Image Installer 來說，雖然 u-boot 給予頗大的彈性，但也使得執行環境充滿不確定性

關於 ARM/Linux 的 ATAGS 實做程式碼可參考 arch/arm/boot/compressed/head.S 與 arch/arm/kernel/setup.c 兩個檔案，筆者做了簡單的 hack 以迴避：

--- android-omap.orig/arch/arm/kernel/setup.c 2009-08-08 18:40:30.000000000 +0800
+++ android-omap/arch/arm/kernel/setup.c 2009-08-08 18:43:09.000000000 +0800
@@ -613,7 +613,6 @@

static int __init parse_tag_cmdline(const struct tag *tag)
{
- strlcpy(default_command_line, tag->u.cmdline.cmdline, COMMAND_LINE_SIZE);
return 0;
}

由此可見，原本的動作是將 u-boot 對 ATAGS 寫入的資料寫入預設的 command line。至於安裝 Linux kernel image 與 root file system image 到 NAND flash 後，還得作 (NAND 裡頭的) u-boot bootenv 的編輯動作，這部份的工作原理可參考 Openmoko 開發的 Devirginator。喔，忘了說，這些惱人的限制，會在轉換到 Qi boot-loader 後迎刃而解 :)

read on