Google berkomitmen untuk mendorong terwujudnya keadilan ras bagi komunitas Kulit Hitam. Lihat caranya.

Peningkatan ART Android 8.0

Waktu proses Android (ART) telah ditingkatkan secara signifikan dalam rilis Android 8.0. Daftar di bawah ini merangkum peningkatan yang diharapkan produsen perangkat dalam ART.

Pengumpul sampah pemadatan serentak

Seperti yang diumumkan di Google I / O, ART menghadirkan pengumpul sampah pemadatan (GC) serentak baru di Android 8.0. Kolektor ini memadatkan heap setiap kali GC berjalan dan saat aplikasi berjalan, hanya dengan satu jeda singkat untuk memproses root thread. Berikut manfaatnya:

  • GC selalu memadatkan heap: rata-rata 32% lebih kecil ukuran heap dibandingkan dengan Android 7.0.
  • Pemadatan mengaktifkan alokasi objek pointer bump lokal thread: Alokasi 70% lebih cepat daripada di Android 7.0.
  • Menawarkan waktu jeda 85% lebih kecil untuk tolok ukur H2 dibandingkan dengan Android 7.0 GC.
  • Waktu jeda tidak lagi diskalakan dengan ukuran heap; aplikasi harus dapat menggunakan banyak tumpukan tanpa khawatir tentang jank.
  • Detail implementasi GC - Hambatan baca:
    • Hambatan baca adalah sejumlah kecil pekerjaan yang dilakukan untuk setiap bidang objek yang dibaca.
    • Ini dioptimalkan dalam kompiler, tetapi mungkin memperlambat beberapa kasus penggunaan.

Pengoptimalan loop

Berbagai macam pengoptimalan loop digunakan oleh ART dalam rilis Android 8.0:

  • Eliminasi pemeriksaan batas
    • Statis: rentang terbukti dalam batas pada waktu kompilasi
    • Dinamis: pengujian run-time memastikan loop tetap dalam batas (tidak berlaku jika tidak)
  • Penghapusan variabel induksi
    • Hapus induksi mati
    • Ganti induksi yang hanya digunakan setelah pengulangan dengan ekspresi bentuk tertutup
  • Penghapusan kode mati di dalam loop-body, penghapusan seluruh loop yang menjadi mati
  • Pengurangan kekuatan
  • Transformasi loop: pembalikan, pertukaran, pemisahan, pembukaan gulungan, unimodular, dll.
  • SIMDization (juga disebut vektorisasi)

Pengoptimal loop berada pada jalur pengoptimalannya sendiri di kompiler ART. Kebanyakan pengoptimalan loop mirip dengan pengoptimalan dan penyederhanaan di tempat lain. Tantangan muncul dengan beberapa pengoptimalan yang menulis ulang CFG dengan cara yang lebih rumit dari biasanya, karena sebagian besar utilitas CFG (lihat node.h) fokus pada membangun CFG, bukan menulis ulang.

Analisis hierarki kelas

ART di Android 8.0 menggunakan Class Hierarchy Analysis (CHA), pengoptimalan compiler yang mendevirtualisasikan panggilan virtual menjadi panggilan langsung berdasarkan informasi yang dihasilkan dengan menganalisis hierarki kelas. Panggilan virtual mahal karena diimplementasikan di sekitar pencarian vtable, dan mereka mengambil beberapa beban dependen. Juga panggilan virtual tidak dapat disebariskan.

Berikut ringkasan penyempurnaan terkait:

  • Pembaruan status metode implementasi tunggal yang dinamis - Pada akhir waktu penautan kelas, ketika vtable telah diisi, ART melakukan perbandingan entri-demi-entri ke vtabel kelas super.
  • Optimasi kompilator - Kompilator akan memanfaatkan info implementasi tunggal dari suatu metode. Jika metode A.foo memiliki set flag implementasi tunggal, compiler akan mendevirtualisasikan panggilan virtual menjadi panggilan langsung, dan selanjutnya mencoba untuk menyebariskan panggilan langsung sebagai hasilnya.
  • Tidak validasi kode yang dikompilasi - Juga di akhir waktu penautan kelas ketika info implementasi tunggal diperbarui, jika metode A.foo yang sebelumnya memiliki implementasi tunggal tetapi status itu sekarang tidak valid, semua kode yang dikompilasi yang bergantung pada asumsi bahwa metode A. foo memiliki kebutuhan implementasi tunggal agar kode yang dikompilasi tidak valid.
  • Deoptimization - Untuk kode terkompilasi langsung yang ada di stack, deoptimization akan dimulai untuk memaksa kode terkompilasi yang tidak valid ke mode interpreter untuk menjamin kebenaran. Mekanisme baru deoptimisasi yang merupakan gabungan dari deoptimisasi sinkron dan tidak sinkron akan digunakan.

Cache sebaris dalam file .oat

ART sekarang menggunakan cache inline dan mengoptimalkan situs panggilan yang memiliki cukup data. Fitur cache sebaris mencatat informasi waktu proses tambahan ke dalam profil dan menggunakannya untuk menambahkan pengoptimalan dinamis ke kompilasi sebelumnya.

Dexlayout

Dexlayout adalah pustaka yang diperkenalkan di Android 8.0 untuk menganalisis file dex dan menyusunnya kembali menurut profil. Dexlayout bertujuan untuk menggunakan informasi profil runtime untuk menyusun ulang bagian dari file dex selama kompilasi pemeliharaan idle pada perangkat. Dengan mengelompokkan bersama bagian file dex yang sering diakses bersama, program dapat memiliki pola akses memori yang lebih baik dari lokalitas yang ditingkatkan, menghemat RAM, dan mempersingkat waktu mulai.

Karena informasi profil saat ini hanya tersedia setelah aplikasi dijalankan, dexlayout terintegrasi dalam kompilasi di perangkat dex2oat selama pemeliharaan idle.

Penghapusan cache Dex

Hingga Android 7.0, objek DexCache memiliki empat larik besar, sebanding dengan jumlah elemen tertentu di DexFile, yaitu:

  • string (satu referensi per DexFile :: StringId),
  • jenis (satu referensi per DexFile :: TypeId),
  • metode (satu penunjuk asli per DexFile :: MethodId),
  • bidang (satu penunjuk asli per DexFile :: FieldId).

Larik ini digunakan untuk pengambilan cepat objek yang sebelumnya kami selesaikan. Di Android 8.0, semua larik telah dihapus kecuali larik metode.

Performa penerjemah

Performa interpreter meningkat secara signifikan dalam rilis Android 7.0 dengan diperkenalkannya "mterp" - interpreter yang dilengkapi mekanisme pengambilan / dekode / interpretasi inti yang ditulis dalam bahasa assembly. Mterp dimodelkan setelah interpreter Dalvik cepat, dan mendukung arm, arm64, x86, x86_64, mips, dan mips64. Untuk kode komputasi, mterp Art secara kasar sebanding dengan interpreter cepat Dalvik. Namun, dalam beberapa situasi ini bisa sangat - dan bahkan secara dramatis - lebih lambat:

  1. Panggil kinerja.
  2. Manipulasi string, dan metode pengguna berat lainnya yang dikenali sebagai intrinsik di Dalvik.
  3. Penggunaan memori tumpukan lebih tinggi.

Android 8.0 mengatasi masalah ini.

Lebih sebaris

Sejak Android 6.0, ART dapat menyebariskan panggilan apa pun dalam file dex yang sama, tetapi hanya dapat menggunakan metode daun sebaris dari file dex yang berbeda. Ada dua alasan untuk pembatasan ini:

  1. Sebaris dari file dex lain perlu menggunakan cache dex dari file dex lain itu, tidak seperti file dex yang sama, yang bisa saja menggunakan kembali cache dex pemanggil. Cache dex diperlukan dalam kode yang dikompilasi untuk beberapa instruksi seperti panggilan statis, pemuatan string, atau pemuatan kelas.
  2. Peta tumpukan hanya mengenkode indeks metode dalam file dex saat ini.

Untuk mengatasi batasan ini, Android 8.0:

  1. Menghapus akses cache dex dari kode yang dikompilasi (juga lihat bagian "Penghapusan cache Dex")
  2. Memperluas encoding peta tumpukan.

Peningkatan sinkronisasi

Tim ART menyetel jalur kode MonitorEnter / MonitorExit, dan mengurangi ketergantungan kami pada hambatan memori tradisional pada ARMv8, menggantinya dengan instruksi (perolehan / rilis) yang lebih baru jika memungkinkan.

Metode asli lebih cepat

Panggilan cepat asli ke Native Interface Java (JNI) yang tersedia dengan menggunakan @FastNative dan @CriticalNative penjelasan. Pengoptimalan waktu proses ART bawaan ini mempercepat transisi JNI dan menggantikan notasi ! Bang JNI yang sekarang sudah usang. Anotasi tidak berpengaruh pada metode non-native dan hanya tersedia untuk kode Bahasa Java platform di bootclasspath (tidak ada pembaruan Play Store).

Anotasi @FastNative mendukung metode non-statis. Gunakan ini jika metode mengakses jobject sebagai parameter atau nilai kembalian.

Anotasi @CriticalNative menyediakan cara yang lebih cepat untuk menjalankan metode asli, dengan batasan berikut:

  • Metode harus statis — tidak ada objek untuk parameter, nilai kembalian, atau implisit this .
  • Hanya tipe primitif yang diteruskan ke metode native.
  • Metode asli tidak menggunakan JNIEnv dan jclass parameter dalam definisi fungsi.
  • Metode ini harus terdaftar di RegisterNatives alih-alih mengandalkan penautan JNI dinamis.

@FastNative dapat meningkatkan performa metode asli hingga 3x, dan @CriticalNative hingga 5x. Misalnya, transisi JNI yang diukur pada perangkat Nexus 6P:

Pemanggilan Java Native Interface (JNI) Waktu eksekusi (dalam nanodetik)
JNI Reguler 115
! bang JNI 60
@FastNative 35
@CriticalNative 25