Halo semua! Ini adalah postingan kedua dalam seri kami di Quarkus - hari ini kita akan membahas tentang kompilasi asli.
adalah tumpukan Java yang dirancang untuk . Meskipun masih banyak yang harus dilakukan di sini, kami telah melakukan banyak pekerjaan baik di banyak aspek, termasuk mengoptimalkan JVM dan sejumlah kerangka kerja. Salah satu fitur Quarkus yang semakin menarik minat para pengembang adalah pendekatannya yang komprehensif dan lancar dalam mengubah kode Java menjadi file yang dapat dieksekusi untuk sistem operasi tertentu (disebut βkompilasi asliβ), mirip dengan C dan C++, di mana kompilasi tersebut biasanya terjadi pada akhir siklus pembuatan, pengujian, dan penerapan.
Dan meskipun kompilasi asli itu penting, seperti yang akan kami tunjukkan di bawah, perlu dicatat bahwa Quarkus berjalan dengan sangat baik di mesin Java yang paling umum, OpenJDK Hotspot, berkat peningkatan kinerja yang kami terapkan di seluruh tumpukan. Oleh karena itu, kompilasi asli harus dianggap sebagai bonus tambahan yang dapat digunakan sesuai keinginan atau kebutuhan. Faktanya, Quarkus sangat bergantung pada OpenJDK dalam hal gambar asli. Dan mode dev, yang diterima dengan hangat oleh pengembang, memastikan pengujian perubahan yang hampir seketika karena kemampuan eksekusi kode dinamis tingkat lanjut yang diterapkan di Hotspot. Selain itu, saat membuat gambar GraalVM asli, perpustakaan kelas OpenJDK dan kemampuan HotSpot digunakan.
Jadi mengapa Anda memerlukan kompilasi asli jika semuanya sudah dioptimalkan dengan sempurna? Kami akan mencoba menjawab pertanyaan ini di bawah.
Mari kita mulai dengan yang sudah jelas: Red Hat memiliki pengalaman luas dalam mengoptimalkan JVM, tumpukan, dan kerangka kerja selama pengembangan proyek , Π°:
- Server aplikasi pertama yang bekerja di cloud pada platform .
- Server aplikasi pertama yang dijalankan di komputer .
- Server aplikasi pertama yang dijalankan .
- Berbagai proyek yang berjalan di perangkat .
Kami telah menghadapi tantangan dalam menjalankan aplikasi Java di cloud dan pada perangkat dengan sumber daya terbatas (baca: IoT) selama bertahun-tahun dan telah belajar untuk memaksimalkan JVM dalam hal kinerja dan optimalisasi memori. Seperti banyak orang lain, kami telah lama bekerja dengan kompilasi asli aplikasi Java , , dan bahkan dan kami sangat menyadari pro dan kontra dari pendekatan ini (misalnya, dilema dalam memilih antara universalitas βbuild sekali β dijalankan di mana sajaβ dan fakta bahwa aplikasi yang dikompilasi lebih kecil dan berjalan lebih cepat).
Mengapa penting untuk mempertimbangkan pro dan kontra ini? Karena dalam beberapa situasi rasio mereka menjadi penentu:
- Misalnya, dalam lingkungan tanpa server/berbasis peristiwa di mana dalam waktu nyata (keras atau lunak) agar memiliki waktu untuk merespons peristiwa. Tidak seperti layanan persisten yang berumur panjang, di sini durasi cold start secara signifikan meningkatkan waktu respons terhadap permintaan. JVM masih membutuhkan banyak waktu untuk memulai, dan meskipun dalam beberapa kasus hal ini dapat dikurangi dengan metode perangkat keras murni, perbedaan antara satu detik dan 5 milidetik dapat menjadi perbedaan antara hidup dan mati. Ya, di sini Anda dapat bermain-main dengan membuat cadangan panas mesin Java (yang, misalnya, kami lakukan dengan itu ), tetapi hal ini sendiri tidak menjamin bahwa akan ada cukup JVM untuk memproses permintaan seiring dengan skala beban. Dan dari sudut pandang ekonomi, ini mungkin bukan pilihan yang paling tepat.
- Selain itu, ada aspek lain yang sering muncul: multitenancy. Terlepas dari kenyataan bahwa JVM telah mendekati sistem operasi dalam kemampuannya, mereka masih belum mampu melakukan apa yang biasa kita lakukan di Linux - mengisolasi proses. Oleh karena itu, kegagalan satu thread dapat mematikan seluruh mesin Java. Banyak orang mencoba mengatasi kelemahan ini dengan mendedikasikan JVM terpisah untuk setiap aplikasi pengguna untuk meminimalkan konsekuensi kegagalan. Ini cukup logis, namun tidak cocok dengan penskalaan.
- Selain itu, untuk aplikasi berorientasi cloud, indikator penting adalah kepadatan layanan pada host. Transisi ke metodologi , layanan mikro dan Kubernetes meningkatkan jumlah mesin Java per aplikasi. Artinya, di satu sisi, semua ini memberikan elastisitas dan keandalan, tetapi pada saat yang sama konsumsi memori dasar dalam hal layanan juga meningkat, dan beberapa dari biaya ini tidak selalu diperlukan. File executable yang dikompilasi secara statis mendapat manfaat di sini karena berbagai teknik pengoptimalan, seperti penghapusan kode mati tingkat rendah, ketika gambar akhir hanya menyertakan bagian kerangka kerja (termasuk JDK itu sendiri) yang sebenarnya digunakan oleh layanan. Oleh karena itu, kompilasi asli Quarkus membantu menempatkan instance layanan secara padat di host tanpa mengorbankan keamanan.
Sebenarnya argumen di atas sudah cukup untuk memahami pembenaran kompilasi asli dari sudut pandang peserta proyek Quarkus. Namun, ada alasan lain yang non-teknis, namun juga penting: dalam beberapa tahun terakhir, banyak pemrogram dan perusahaan pengembangan telah meninggalkan Java demi bahasa pemrograman baru, percaya bahwa Java, bersama dengan JVM, tumpukan, dan kerangka kerjanya, telah menjadi terlalu ketinggalan jaman. haus memori, terlalu lambat, dll.
Namun, kebiasaan menggunakan alat yang sama untuk menyelesaikan masalah apa pun adalah hal yang biasa . Terkadang lebih baik mengambil langkah mundur dan mencari hal lain. Dan jika Quarkus membuat orang berhenti sejenak dan berpikir, itu bagus untuk ekosistem Java secara keseluruhan. Quarkus mewakili pandangan inovatif tentang cara membangun aplikasi yang lebih efisien, menjadikan Java lebih relevan dengan arsitektur aplikasi baru seperti tanpa server. Selain itu, karena sifatnya yang dapat diperluas, Quarkus diharapkan akan memiliki keseluruhan ekosistem ekstensi Java, sehingga secara signifikan meningkatkan jumlah kerangka kerja yang akan mendukung kompilasi asli dalam aplikasi yang siap digunakan.
Sumber: www.habr.com