AOT - Ahead Of Time - Part 2
Pendahuluan
Untuk pendahuluan mengenai AOT bisa di lihat di AOT - Part 1
Ahead Of Time (AOT) compiler adalah konsep yang sering kita temui di perkembangan teknologi belakangan ini.
Dengan AOT, maka source code kita akan di-compile di waktu build timeke code executable native yang bisa langsung dijalankan di platform tertentu.
Tujuannya biasanya untuk :
- Optimasi Code, sesuai dengan platform dimana code tersebut dieksekusi.
- Ukuran file/artifact yang lebih kecil.
- Penggunaan memori yang lebih kecil.
- Efisiensi dari code dan sumber daya lainnya.
Tapi apakah memang benar ?
Coba kalau kita lihat kasus AOT compiler untuk aplikasi/program dalam bahasa Java.
Dengan menggunakan AOT compiler untuk Java, misalnya dengan GraalVM compiler, maka kelebihannya :
-
Tidak perlu melakukan instalasi JVM / JRE di server dimana program tersebut dijalankan. Hal ini karena program tersebut sudah dioptimasi untuk platform yang ada dan dalam bentuk executable file yang bisa langsung dijalankan. Tidak perlu lagi sibuk mengecek kompatibilitas dari aplikasi dengan JRE yang ada di server. Eh iya, biasanya memang akan digunakan container, jadi memang sudah akan terisolasi, tetapi tanpa perlu instalasi JVM/JRE didalamnya.
-
Ukuran file aplikasi yang lebih kecil, karena AOT compiler (seperti GraalVM) akan mengeleminasi code yang tidak digunakan (termasuk class, attribute, logic looping, method yang tidak digunakan). AOT compiler akan melakukan point to point analysis , region_anaylisyst agar bisa tercapai ukuran file yang benar-benar dibutuhkan saja.
-
Komsumsi memori yang lebih rendah. Hal ini dikarenakan jumlah total class/object yang diload waktu pertama kali aplikasi dijalankan secara drastis berkurang.
-
Waktu yang dibutuhkan disaat aplikasi dijalankan agar siap menerima request juga berkurang. Hal ini karena eksekusinya tidak melalui JVM lagi yang perlu diinterpreted oleh JVM ke platform dibawahnya, tetapi langsung sebagai executable file yang langsung dijalankan.
-
Mudah di package di dalam container, seperti docker, podman, dll. Efeknya juga mudah juga nantinya kalau di horizontal scaling kalau ternyata kebutuhan sumber daya nya meningkat.
Hmm, tapi ada pertanyaan tambahan :
Bagaimana dengan fitur JVM yang biasanya ada sebelumnya, yang juga dibutuhkan sebenarnya di waktu runtime seperti :
- Garbage Collector
- Thread Scheduler
- Deoptimizer
- dll
Fitur-fitur JVM diatas tentunya tidak bisa serta merta di exclude dari file executable yang ada.
Kalau tidak, tentunya tidak ada Garbage Collector yang membersihkan memori dari object-object Java yang tidak dipakai lagi, tidak ada lagi Thread Scheduler yang menentukan prioritas Thread di dalam aplikasi.
Oleh karena pentingnya fitur diatas, maka fitur-fitur diatas tetap ada dimasukkan dalam komponen hasil kompilasi AOT, dalam bentuk runtime component atau embeddable.
Untuk kasus GraalVM, runtime component ini disebut Substrate VM, yang bisa dijalankan terpisah sebagai komponen runtime atau diembed diaplikasi yang ada.
Apa kekurangan memakai AOT ini ?
Setiap ada kelebihan, tentunya ada kekurangan yang menyertainya.
Apakah ada kekurangan memakai AOT ini ?
Tentu saja…
Coba kita lihat :
- Agar bisa menggunakan AOT compiler ini, maka semuanya harus terdefinisi disaat build time. Atau kasarnya, fitur-fitur dinamis di dalam aplikasi, yang biasanya kita dapatkan diwaktu runtime tidak bisa kita gunakan dengan AOT compiler ini.
Misalnya :
- Java Native Interface (JNI), yang memungkinkan kita berinteraksi dengan program lain pada saat runtime yang ditulis bukan dengan bahasa Java.
- Java Reflection, yang memungkinkan kita untuk memodifikasi class, method, atau interfaces waktu runtime.
- Dynamic Proxy objects, yang memungkinkan kita untuk melakukan ektensi dari class yang sudah ada pada saat runtime.
- Classpath resources ataupun Dynamic class loading pada saat runtime.
- dll.
-
Proses kompilasi menggunakan AOT compiler ini akan cukup lama dibandingkan kalau kita melakukan kompilasi biasa. Hal ini karena kompilasinya menggunakan point to point , region anaylysist. Semua code akan ditrace, dipilih yang berguna saja di saat runtime, dieliminasi mana saja yang tidak perlu. Dan hal ini membutuhkan waktu yang lebih lama dibandingkan pakai kompilasi biasa.
-
Optimasi di saat build time tidak selalu optimal waktu dijalankan di saat runtime. Bisa saja di saat runtime perlu dilakukan deoptimizer agar sesuai dengan kondisi runtime yang ada.
cukup segitu dulu, kita lanjutkan lain kali..