Kami baru-baru ini menulis tentang trik apa yang Alibaba lakukan untuk membuat hidup dengan OpenJDK lebih dapat diterima. Ada komentar seperti "ternyata sementara kita menderita dengan Jawa biasa, Cina sudah membuat spesial mereka sendiri." Alibaba, tentu saja, mengesankan - tetapi Rusia juga memiliki proyek fundamentalnya sendiri, di mana mereka juga membuat "Jawa khusus".
Di Novosibirsk, selama 18 tahun sekarang mereka telah membuat JVM sendiri , ditulis sepenuhnya secara mandiri dan laris jauh di luar perbatasan Rusia. Ini bukan hanya semacam garpu HotSpot yang melakukan hal yang sama, tetapi sedikit lebih baik. Excelsior JET adalah rangkaian solusi yang memungkinkan Anda melakukan hal-hal yang sangat berbeda dalam hal kompilasi AOT. "Pff, AOT ada di GraalVM," bisa Anda katakan. Tetapi GraalVM masih merupakan hal yang sangat eksploratif, dan JET adalah solusi yang terbukti untuk digunakan dalam produksi.
Ini adalah wawancara dengan salah satu pengembang Excelsior JET. Saya harap ini akan sangat menarik bagi semua orang yang ingin menemukan hal-hal baru yang dapat dilakukan dengan Java. Atau orang-orang yang tertarik dengan kehidupan insinyur JVM dan mereka sendiri ingin berpartisipasi dalam ini.
Pada musim gugur, saya terbang ke salah satu konferensi Java Novosibirsk, kami duduk bersama Ivan Uglyansky dbg_nsk dan Nikita Lipsky pjBooms (salah satu pengembang JET) dan merekam wawancara ini. Ivan terlibat dalam runtime JET: GC, pemuatan kelas, dukungan multithreading, profiling, plugin untuk GDB. Nikita - salah satu penggagas proyek JET, berpartisipasi dalam penelitian dan pengembangan hampir semua komponen produk dari kernel ke properti produk - OSGi di tingkat JVM, Java Runtime Slim Down (modul Java di JET sudah pada 2007), dua verifier bytecode, dukungan Boot musim semi dan sebagainya.
Oleg Chirukhin: Bisakah Anda memberi tahu orang-orang yang tidak tahu tentang produk Anda?
Nikita Lipsky: Tentu saja mengejutkan, bahwa kami telah berada di pasar selama 18 tahun, dan kami tidak tahu banyak. Kami melakukan JVM yang tidak biasa. Taruhan yang tidak biasa pada kompilasi AOT, mis. kami mencoba mengkompilasi bytecode Java menjadi kode mesin terlebih dahulu.
Awalnya, ide proyek ini adalah untuk membuat Java cepat. Produktivitas adalah apa yang kami tuju dengan pasar. Dan ketika kami berjalan, Java masih diinterpretasikan, dan kompilasi statis menjadi kode mesin berjanji untuk meningkatkan kinerja Java bahkan tidak berkali-kali, tetapi atas perintah besarnya. Tetapi bahkan di hadapan JIT, jika Anda mengkompilasi semuanya terlebih dahulu, maka Anda tidak menghabiskan sumber daya saat runtime pada kompilasi, dan dengan demikian, Anda dapat menghabiskan lebih banyak waktu dan memori dan akhirnya mendapatkan kode yang lebih optimal.
Selain kinerja, efek samping dari kompilasi bytecode statis adalah perlindungan aplikasi Java dari dekompilasi. Karena setelah kompilasi tidak ada bytecode yang tersisa, hanya kode mesin yang tersisa. Jauh lebih sulit untuk mendekompilasi menjadi kode sumber daripada bytecode Java. Padahal, tidak mungkin. Artinya, dapat dibongkar, tetapi Anda tidak akan melahirkan kode sumber. Tetapi kode sumber Java dapat dihasilkan dari bytecode hingga nama variabel dengan mudah, ada banyak alat untuk ini.
Selain itu, sekali waktu diasumsikan bahwa Java diinstal pada semua komputer, Anda mendistribusikan aplikasi Java Anda dalam bentuk bytecode, dan mereka mengeksekusi yang sama di mana-mana. Tetapi pada kenyataannya, semuanya tidak begitu baik, karena satu memiliki satu Jawa, yang lain memiliki yang lain. Karena itu, jika Anda mendistribusikan program dalam bentuk bytecode, semua jenis kejutan dapat terjadi, dimulai dengan fakta bahwa pengguna tidak dapat memulai program Anda, diakhiri dengan beberapa perilaku aneh yang tidak dapat Anda tunjukkan dalam diri Anda. Produk kami selalu memiliki keuntungan bahwa Anda mendistribusikan aplikasi Java Anda hanya sebagai aplikasi asli. Anda tidak memiliki ketergantungan pada runtime bahwa pengguna (atau tidak layak).
Ivan Uglyansky: Secara umum, Anda tidak perlu meminta Java untuk diinstal.
Oleg: Masih ada ketergantungan pada sistem operasi, kan?
Nikita: Benar. Banyak yang mengkritik bahwa jika Anda mengkompilasi ke dalam kode asli, maka slogan Anda “Tulis sekali - jalankan di mana saja” berhenti bekerja. Tapi ini tidak benar. Saya secara berkala menceritakannya dalam laporan saya bahwa "tulis sekali" terdengar seperti "tulis sekali" dan bukan "bangun sekali". Artinya, Anda dapat membangun aplikasi Java di setiap platform, dan itu akan berfungsi di mana-mana.
Oleg: Langsung ke mana-mana, di mana saja?
Nikita: Di mana pun didukung. Kami memiliki solusi yang kompatibel dengan Java. Jika Anda menulis dalam Java, ini akan berfungsi di mana Java bekerja. Dan jika Anda menggunakan yang dikompilasi oleh kami, maka di mana kami mendukungnya - Windows, Linux, Mac, x86, amd64, ARM32. Tetapi di mana kami tidak mendukungnya, Anda masih dapat menggunakan Java biasa untuk aplikasi Anda, yaitu, portabilitas aplikasi Java Anda dalam hal ini tidak akan terganggu.
Oleg: Apakah ada desain seperti itu yang diterapkan secara berbeda pada platform yang berbeda? Potongan-potongan platform yang tidak sepenuhnya diimplementasikan, beberapa perpustakaan standar.
Ivan: Itu terjadi, tetapi itu tidak spesifik JET. Anda dapat melihat, misalnya, pada implementasi AsynchronousFileChannel di JDK itu sendiri, itu benar-benar berbeda pada Windows yang berbeda dan pada Posix, yang logis. Beberapa hal hanya diterapkan pada platform tertentu, dukungan untuk SCTP (lihat sun.nio.ch.sctp.SctpChannelImpl pada Windows) dan SDP (lihat sun.net.sdp.SdpSupport). Tidak ada kontradiksi khusus dalam hal ini, tetapi ternyata “Tulis sekali, jalankan di mana saja” tidak sepenuhnya benar.
Berbicara secara khusus tentang implementasi JVM, maka pada OS yang berbeda perbedaannya, tentu saja, bisa sangat besar. Apa fakta bahwa pada OS X di utas utama Anda perlu menjalankan loop acara Kakao, jadi peluncuran di sana berbeda dari yang lain.
Nikita: Meskipun demikian, dari luar, untuk pengguna, semuanya terlihat dan berfungsi hampir sama.
Oleg: Bagaimana dengan kinerjanya? Apakah sama di semua platform?
Nikita: Ada perbedaan. Sebagai contoh, sistem file Linux berfungsi lebih baik dan lebih cepat daripada sistem file Windows.
Oleg: Dan memindahkan antar prosesor?
Nikita: Ini kegiatan yang menyenangkan! Seluruh tim tiba-tiba mulai port. Hiburan biasanya selama enam bulan hingga satu tahun.
Oleg: Kebetulan beberapa kode di platform lain mulai melambat?
Ivan: Ini mungkin karena fakta bahwa kami tidak punya waktu untuk membuat atau mengadaptasi semacam optimasi. Ini bekerja dengan baik pada x86, kemudian kami beralih ke AMD64, dan tidak berhasil mengadaptasinya. Karena itu, ini bisa lebih lambat.
Contoh kinerja lain. ARM memiliki model memori yang lemah, Anda harus meletakkan lebih banyak penghalang di sana agar semuanya berfungsi dengan benar. Kami memiliki AMD64, beberapa tempat bekerja, berpikir, gratis, karena ada model memori yang berbeda. Pada ARM, Anda perlu menempatkan lebih banyak penghalang, tetapi ini tidak gratis.
Oleg: Mari kita bicara tentang topik hangat sekarang - "Java pada perangkat yang disematkan."
Katakanlah saya membuat pesawat terbang dengan kendali atas Raspberry Pi. Apa saja masalah khas yang dimiliki seseorang ketika melakukan ini? Dan bagaimana JET dan umumnya kompilasi AOT membantu dalam hal ini?
Nikita: Pesawat di Raspberry Pi tentu saja merupakan topik yang menarik. Kami membuat ARM32, dan sekarang JET ada di Raspberry Pi. Kami memiliki jumlah pelanggan tak terbatas untuk disematkan, tetapi tidak banyak yang bisa dibicarakan tentang masalah "tipikal" mereka. Meskipun mereka memiliki beberapa masalah dengan Java, tidak sulit ditebak.
Ivan: Apa masalah dengan Java pada Raspberry Pi? Ada masalah dengan konsumsi memori. Jika Anda terlalu membutuhkannya, maka aplikasi dan JVM mengalami kesulitan hidup dengan Raspberry Pi yang malang. Selain itu, penting untuk memulai dengan cepat pada perangkat yang disematkan agar aplikasi tidak berakselerasi terlalu lama di sana. AOT menyelesaikan kedua masalah ini dengan baik, jadi kami berupaya untuk meningkatkan dukungan yang tertanam. Khususnya, mengenai Raspberry Pi, perlu disebutkan tentang Bellsoft , yang sekarang aktif terlibat dalam hal ini dengan HotSpot. Java normal sepenuhnya hadir di sana.
Nikita: Selain itu, ada beberapa sumber daya pada sistem embedded, kompiler JIT tidak memiliki tempat untuk menyebarkan. Karenanya, kompilasi AOT dengan sendirinya mempercepat kinerja.
Sekali lagi, perangkat tertanam tanpa terhubung ke jaringan, menggunakan baterai. Mengapa ada baterai untuk kompiler JIT jika Anda dapat merakit semuanya terlebih dahulu?
Oleg: Fitur apa yang Anda miliki? Saya mengerti bahwa JET adalah sistem kompleks yang sangat besar dengan banyak segalanya. Anda memiliki kompilasi AOT, yaitu, Anda dapat mengkompilasi executable. Apa lagi Apa saja komponen menarik yang layak dibicarakan?
Ivan: Kami memiliki sejumlah fitur yang terkait dengan kinerja.
Baru-baru ini, saya berbicara tentang PGO, fitur kami yang relatif baru. Kami memiliki profiler bawaan langsung di JVM, serta serangkaian optimisasi berdasarkan profil yang dikumpulkannya. Setelah dikompilasi ulang berdasarkan profil, kami sering mendapatkan peningkatan kinerja yang serius. Faktanya adalah bahwa informasi kinerja ditambahkan ke analisis dan optimisasi statis kami yang kuat. Ini adalah pendekatan yang sedikit hybrid untuk mengambil yang terbaik dari kompilasi JIT dan AOT.
Kami memiliki dua fitur luar biasa untuk akselerasi peluncuran yang lebih cepat. Yang pertama adalah ketika Anda melihat urutan halaman memori yang ditusuk pada awalnya, Anda cukup memantaunya dan menghubungkan eksekusi yang sesuai.
Nikita: Kedua - ketika Anda menjalankan file yang dapat dieksekusi, Anda memahami bagian memori mana yang sedang ditarik, dan bukannya menariknya dalam urutan apa pun, Anda segera menarik bagian yang diinginkan. Juga sangat mempercepat peluncuran.
Ivan: Ini adalah fitur grosir.
Nikita: Yang pertama disebut Startup Optimizer, dan yang kedua adalah Startup Accelerator. Fitur bekerja secara berbeda. Untuk menggunakan yang pertama, Anda harus menjalankan aplikasi sebelum kompilasi, ia akan mengingat urutan kode yang dieksekusi. Kemudian, dalam urutan yang benar, kode ini akan ditautkan. Dan yang kedua meluncurkan aplikasi Anda setelah kompilasi, maka kita sudah tahu apa yang terjadi di mana dan di mana, dan setelah itu kami menusuk segala sesuatu dengan urutan yang benar saat peluncuran.
Selain fitur yang terkait dengan kinerja, ada sejumlah fitur produk yang membuat JET lebih nyaman untuk digunakan.
Sebagai contoh, kita dapat mengemas, katakanlah, distribusi Windows. Sekali - dan mendapat installer Windows. Anda dapat mendistribusikan aplikasi Java sebagai aplikasi asli asli. Masih banyak lagi. Sebagai contoh, ada masalah standar dengan kompiler AOT dan Java ketika aplikasi menggunakan loader kelasnya sendiri. Jika Anda memiliki pemuat kelas sendiri, tidak jelas kelas mana yang akan dikompilasi AOT? Karena di sana logika resolusi antar kelas bisa apa saja. Karenanya, tidak ada kompiler Java AOT tunggal, kecuali kompiler Java kami, yang bekerja dengan loader kelas non-standar. Kami memiliki dukungan khusus dalam AOT untuk beberapa kelas aplikasi, di mana kami tahu bagaimana loader kustom mereka bekerja, bagaimana tautan antar kelas diselesaikan. Misalnya, kami memiliki dukungan untuk Eclipse RCP dan ada klien yang menulis aplikasi desktop di Eclipse RCP dan mengkompilasi bersama kami. Ada dukungan untuk Tomcat, loader kustom juga digunakan di sana. Anda dapat mengkompilasi aplikasi Tomcat dengan kami. Kami juga baru-baru ini merilis versi Spring Boot JET di luar kotak.
Oleg: Server mana yang ada "di bawah"?
Nikita: Apa pun yang kamu inginkan. Dukungan Boot Musim Semi mana yang akan bekerja dengan ini. Tomcat, Undertow, Jetty, Webflux.
Ivan: Di sini perlu disebutkan bahwa untuk Jetty kita tidak mendapat dukungan dari classloader kustomnya.
Nikita: Jetty, sebagai server web yang berdiri sendiri, memiliki classloader khusus. Tetapi ada yang namanya Jetty Embedded, yang dapat bekerja tanpa pemuat kustom. Jetty Embedded berjalan dengan tenang di Excelsior JET. Di dalam Spring Boot, Jetty akan berfungsi di versi berikutnya, seperti server lain yang didukung oleh Spring Boot.
Oleg: Sebenarnya, antarmuka pengguna dengan JET adalah javac dan Java, atau yang lainnya?
Ivan: Tidak. Untuk pengguna, kami memiliki beberapa opsi untuk menggunakan JET. Pertama, ini adalah GUI di mana pengguna menembus semua fitur, setelah itu ia menekan tombol dan kompilasi aplikasinya. Ketika dia ingin membuat beberapa installer agar pengguna dapat menginstal aplikasi, dia sekali lagi menekan tombol. Tetapi pendekatan ini agak ketinggalan jaman (GUI dikembangkan kembali pada tahun 2003), jadi sekarang kita memiliki Nikita mengembangkan dan mengembangkan plugin untuk Maven dan Gradle, yang jauh lebih nyaman dan akrab bagi pengguna modern.
Nikita: Ganti tujuh baris dalam pom.xml atau build.gradle, katakanlah mvn jet:build , dan Anda memiliki stik sosis pada hasilnya.
Oleg: Dan sekarang semua orang sangat mencintai Docker dan Kubernetes, bisakah Anda membangun untuk mereka?
Nikita: Docker adalah topik selanjutnya. Kami memiliki parameter seperti itu - kemasan dalam plugin Maven / Gradle. Saya dapat menambahkan aplikasi pengemasan untuk Docker.
Ivan: Ini masih dalam proses. Namun secara keseluruhan, kami mencoba aplikasi yang dikompilasi JET untuk berjalan di Docker.
Nikita: Berhasil . Tanpa jawa Naked Linux, tempelkan aplikasi yang dikompilasi JET di sana, dan itu dimulai.
Oleg: Dan dengan kemasan buruh pelabuhan, apa yang akan menjadi output? Untuk mendorong wadah atau file yang dapat dieksekusi dengan tangan Anda di file Docker?
Nikita: Sekarang Anda baru saja menulis file Docker spesifik-JET - ini adalah tiga baris. Selanjutnya, semuanya berfungsi melalui alat Docker biasa.
Saya sedang bermain dengan layanan microser saat ini. Saya mengkompilasi mereka dengan JET, menjalankannya, mereka menemukan satu sama lain, berkomunikasi. JVM tidak perlu melakukan apa pun untuk ini.
Oleg: Sekarang segala macam penyedia cloud telah meluncurkan hal-hal seperti Amazon Lambda, Fungsi Google Cloud, dapatkah saya menggunakannya di sana?
Nikita: Saya pikir kita perlu pergi ke penyedia semua hal ini dan mengatakan bahwa jika Anda menggunakan kami, maka semua lambda Anda akan bekerja lebih cepat. Tapi ini masih sebuah ide.
Oleg: Jadi mereka benar-benar akan bekerja lebih cepat!
Nikita: Ya, kemungkinan besar, lebih banyak pekerjaan harus dilakukan ke arah ini.
Oleg: Saya melihat masalah dalam waktu kompilasi lambda. Apa waktu kompilasi Anda?
Ivan: Itu ada, dan ini adalah masalah yang tidak dipikirkan oleh pengguna JVM biasa dengan JIT. Biasanya, bagaimana pun, bagaimana - saya meluncurkan aplikasi, ini berfungsi (walaupun lambat pada awalnya karena kompilasi). Dan inilah langkah terpisah untuk AOT-mengkompilasi seluruh aplikasi. Ini bisa sensitif, jadi kami berupaya mempercepat fase ini. Misalnya, kami memiliki kompilasi tambahan ketika hanya bagian aplikasi yang diubah yang dikompilasi ulang. Kami menyebutnya kompilasi ulang cerdas. Kami hanya melakukan ini pada periode perawan terakhir dengan Nikita, kami berpasangan.
Nikita: Ada masalah tertentu dengan Java dan kompilasi ulang cerdas, misalnya, dependensi melingkar dalam aplikasi Java - mereka ada di mana-mana.
Ivan: Ada banyak masalah yang agak tidak jelas di sana, sampai Anda memikirkan tugas ini. Jika Anda memiliki kompiler AOT statis yang melakukan berbagai optimasi global, maka tidak mudah untuk menghitung apa yang sebenarnya perlu dikompilasi ulang. Anda perlu mengingat semua optimasi ini. Dan optimisasi bisa menjadi non-trivial. Misalnya, Anda dapat melakukan segala macam devirtualisasi kompleks, sebariskan sesuatu yang diketahui iblis di mana. Jika Anda mengubah satu klasik atau satu JAR, ini tidak berarti bahwa hanya perlu dikompilasi ulang dan hanya itu. Tidak, ini jauh lebih membingungkan. Anda perlu menghitung dan mengingat semua optimasi yang telah dilakukan kompiler.
Nikita: Sebenarnya, melakukan hal yang sama seperti yang JIT lakukan ketika membuat keputusan tentang de-optimisasi, tetapi hanya di kompiler AOT. Hanya solusinya bukan tentang deoptimisasi, tetapi tentang kompilasi.
Oleg: Tentang kecepatan kompilasi cerdas. Jika saya mengambil "Halo, Dunia", kompilasi, lalu ubah dua huruf dalam kata "Halo" ...
Nikita: Kompilasi dengan cepat.
Oleg: Maksudku, tidak sebentar?
Nikita: Detik.
Ivan: Tapi itu masih tergantung pada apakah kita menyertakan kelas platform dalam executable.
Oleg: Dan apa yang mungkin tanpa ini?
Nikita: Ya, secara default, platform kami digergaji menjadi beberapa DLL. Kami menerapkan Jigsaw di awal :-) Yaitu, kami menggergaji kelas Java SE pada komponen yang sangat lama, kembali sekitar 90 tahun yang lalu.
Ivan: Intinya adalah kelas runtime plus platform kami - semuanya dikompilasi oleh kami, dan ya - dibagi menjadi DLL. Saat Anda menjalankan aplikasi yang dikompilasi oleh JET, runtime dan seluruh platform disajikan dalam bentuk DLL ini. Artinya, hasilnya seperti ini: Anda mengambil "Halo, dunia", kompilasi, Anda benar-benar mengkompilasi satu kelas. Ini terjadi dalam beberapa detik.
Nikita: Dalam 4 detik, jika di global; dalam beberapa detik, jika tidak di global. "Global" adalah ketika Anda menautkan: semua kelas platform dikompilasi ke dalam kode asli menjadi satu yang dapat dieksekusi besar.
Oleg: Bisakah saya melakukan isi ulang panas?
Nikita: Tidak.
Oleg: Tidak? Kesedihan. Tetapi akan mungkin untuk menghasilkan satu DLL, tautkan lagi dan kemudian ...
Nikita: Karena kita memiliki JIT (omong-omong, ya, kita juga memiliki JIT!), Tentu saja, Anda dapat memuat, membongkar, memuat ulang potongan kode. Misalnya, semua kode yang berfungsi melalui JIT kami berada dalam OSGI yang sama - Anda dapat memuatnya kembali jika Anda mau. Tapi inilah hot reload yang dimiliki HotSpot, ketika Anda duduk di debugger dan mengubah kode dengan cepat, kami tidak. Ini tidak dapat dilakukan tanpa kehilangan kinerja.
Oleg: Pada tahap pengembangan, kinerja tidak begitu penting.
Nikita: Pada tahap pengembangan, Anda menggunakan HotSpot, dan Anda tidak membutuhkan yang lain. Kami adalah solusi yang sesuai dengan Java. Jika Anda menggunakan HotSpot dan menggunakan hot reload dalam debugging, semuanya baik-baik saja. Debet, kompilasi JET, dan semuanya berfungsi seperti di HotSpot. Seharusnya seperti itu. Biasanya seperti itu. Jika tidak, Anda menulis untuk mendukung, kami mengerti.
Oleg: Bagaimana dengan debugging di JET? JVM TI? Berapa semuanya didukung?
Ivan: Salah satu nilai inti dari menggunakan JET adalah keamanan. Kode khusus tidak akan tersedia untuk siapa pun. Karena semuanya dikompilasi menjadi asli. Ada beberapa kontradiksi dengan ini, apakah kami mendukung JVM TI? Jika kami mendukung, itu berarti setiap pengembang maju yang tahu cara kerja JVM TI akan dapat dengan cepat mengakses apa pun. Kami tidak mendukung TI JVM sekarang.
Nikita: Ini adalah item spesifikasi opsional. Mungkin didukung oleh pelaksana platform, mungkin tidak didukung.
Ivan: Ada banyak alasan. Ini opsional dan melanggar keamanan, yang berarti bahwa pengguna tidak akan mengatakan "terima kasih" kepada kami. Dan dia di dalam sangat spesifik HotSpot. Belum lama berselang, orang-orang kami mendukung JVM TI sebagai proyek percobaan, mereka mencapai tahap tertentu, tetapi sepanjang waktu mereka dihadapkan pada kenyataan bahwa itu sangat fokus pada HotSpot. Pada prinsipnya, ini mungkin, tetapi tugas bisnis apa yang akan diselesaikan?
Nikita: Setelah Anda menghasilkan uang di HotSpot, tetapi tidak mendapatkan uang dengan jet - ini bukan masalah Anda. Ini masalah kita.
Oleg: Mengerti. Apakah Anda memiliki fitur tambahan, yang
tidak di HotSpot, tetapi apakah Anda memilikinya, dan mereka memerlukan kontrol langsung? Yang saya ingin debug, urutkan mereka.
Nikita: Tepat satu fitur. Kami memiliki ekstensi resmi dari platform yang disebut Windows Services, yaitu, Anda dapat mengkompilasi aplikasi Java dalam bentuk layanan Windows nyata yang akan dipantau melalui alat Windows standar untuk layanan Windows dan sebagainya. Dalam hal ini, Anda harus mengambil JAR kami sendiri untuk mengkompilasi aplikasi tersebut.
Oleg: Ini bukan masalah terbesar.
Nikita: Antarmuka sangat sederhana untuk layanan ini. Dan untuk debugging, Anda menggunakan metode memulai aplikasi Anda sendiri bukan sebagai Layanan Windows, tetapi melalui main. Semacam debugging khusus layanan, saya tidak tahu apakah itu diperlukan.
Oleg: Misalkan pengembang baru yang sebelumnya bekerja untuk HotSpot ingin mengembangkan sesuatu menggunakan JET, apakah dia perlu mempelajari sesuatu, memahami sesuatu secara umum tentang kehidupan atau tentang JET?
Ivan: Dia perlu menyalin tujuh baris ke pom.xml, jika Maven digunakan, kemudian jalankan jet: build, dan jika JET ada di mesin, maka aplikasi Java akan dikompilasi menjadi executable. Idenya adalah sederhana, Anda tidak melakukan sesuatu yang istimewa, Anda hanya mengambilnya, mendapatkan yang dapat dieksekusi, dan hanya itu.
Nikita: Entah Anda tahu baris perintah dengan mana aplikasi Anda diluncurkan, maka Anda menempatkan baris perintah ini di GUI kami, itu akan mengetahuinya. Anda memberi perintah build, Anda dapat dieksekusi, itu saja.
Ivan: Ini sangat sederhana, Anda tidak perlu menemukan sesuatu yang baru. Cara kerja hotspot AOT, Anda sendiri menunjukkan pada laporan bahwa Anda perlu mendapatkan daftar semua metode ke dalam file, menyapu, mengubah - kami tidak perlu melakukan hal seperti ini. Cukup ambil baris peluncuran Anda di HotSpot, rekatkan ke GUI khusus, atau tambahkan potongan kecil ke pom.xml, dan, tepuk tangan, setelah beberapa saat (karena ini masih merupakan kompilasi AOT), Anda mendapatkan file exe, yang bisa dijalankan.
Oleg: Apakah saya perlu belajar bekerja dengan GC?
Nikita: Ya, kami memiliki GC sendiri, kami perlu menyetelnya dengan cara yang berbeda, tidak seperti di HotSpot. Kami memiliki sangat sedikit pena publik.
Oleg: Apakah ada pena "untuk melakukannya dengan baik" atau "tidak untuk melakukan"?
Ivan: Ada pena seperti itu. Ada pena "set Xmx", ada pena "set jumlah pekerja" ... Banyak pena, tetapi mengapa Anda perlu tahu tentang mereka? Jika sesuatu yang tidak terduga terjadi pada Anda - tulis.
Tentu saja, kami memiliki banyak hal untuk dikonfigurasi untuk GC. Kita bisa menyetel generasi yang lebih muda, kita dapat frekuensi kedatangan GC. Semua ini disetel, tetapi ini bukan opsi yang diterima secara umum. Kami memahami bahwa orang tahu -Xmx dan menunjukkannya, jadi kami menguraikannya. Ada beberapa opsi yang lebih umum diterima yang bekerja dengan JET, tetapi secara umum, semuanya berbeda.
Nikita: Kami juga memiliki opsi publik yang memungkinkan Anda untuk mengatur berapa banyak Anda mengizinkan GC untuk menghabiskan waktu pada aplikasi Anda.
Oleg: Persentase?
Nikita: Sepersepuluh persen. Kami menyadari bahwa bunga terlalu banyak, kasar.
Ivan: Jika Anda menghabiskan bunga untuk GC, ada sesuatu yang salah dengan Anda.
Oleg: Dan ini semua orang dari perusahaan yang melakukan semua yang mereka lakukan selama jam kerja - mereka membuka cetakan karya GC dengan jadwal dan bermeditasi. Bisakah kamu bermeditasi?
Nikita: Kami memiliki orang-orang istimewa di dalam perusahaan yang bermeditasi.
Ivan: Kami memiliki format log kami sendiri, jadi orang tidak mungkin memahami sesuatu darinya. Meskipun, Anda tidak pernah tahu? Jika mereka menatapnya untuk waktu yang lama, mungkin mereka bisa mengerti. Semuanya tertulis di sana. Tetapi, kemungkinan besar, lebih baik mengirim kami, dan kami akan bermeditasi.
Oleg: Tapi tentu saja, Anda akan melakukannya demi uang, tetapi Anda bisa mencari freebie sendiri.
Nikita: Jika Anda adalah klien kami, maka Anda memiliki dukungan, dan kami melakukan ini, tentu saja, sebagai bagian dari dukungan.
Ivan: Tetapi jika Anda memiliki masalah yang jelas, kami bahkan dapat mengatakannya tanpa dukungan.
Oleg: Jika ini semacam bug?
Nikita: Jika ada bug, maka, tentu saja, kami terima dari semua orang dan selalu. Ini tidak begitu, "sampai Anda membeli, kami tidak akan memperbaiki bug." Jika ada bug, maka kami memperbaikinya. Secara umum, pengguna menyukai dukungan kami. Biasanya mereka mengatakan bahwa kualitasnya sangat tinggi, dan mereka belum pernah melihat yang seperti ini di mana pun. Mungkin faktanya adalah bahwa kita sendiri mendukung, berputar secara bergantian.
Oleg: Siapa mereka sendiri?
Nikita: Pengembang, Insinyur JVM.
Oleg: Seberapa sering?
Nikita: Frekuensinya berbeda. Biasanya kami duduk bergiliran selama dua minggu. Tetapi jika Anda berkewajiban membuat megapha dalam beberapa hari tertentu, maka pada saat itu Anda akan menerima kekebalan dari dukungan sehingga Anda dapat fokus pada tugas ini.
Ivan: Secara teori, setiap orang harus melakukan ini pada gilirannya. Tetapi kadang-kadang seseorang dengan heroik mengambil dosis kedua dan dukungan selama sebulan atau lebih, dan bukan dua minggu. Secara pribadi, saya suka mendukung, tetapi jika Anda melakukan ini terlalu lama, maka Anda lupa sedikit apa yang Anda lakukan dalam hidup, karena Anda hanya mulai menjawab surat. Tapi Anda masih ingin sosis JVM. Karena itu, setelah beberapa waktu Anda harus kembali.
Oleg: Dan Anda memiliki hierarki, ada berapa level manajemen? 20 atau lebih?
Nikita: Apa yang kamu, kami hanya 10 orang dalam satu tim.
Ivan: 15 dengan siswa.
Oleg: Maksud saya, pihak berwenang terlibat dalam hal ini atau hanya melihat?
Nikita: Tentang para bos. Tentu saja, ada orang utama, dan ada banyak pemimpin lokal.
Oleg: Apakah setiap orang memiliki area sendiri?
Nikita: Seseorang yang mengambil tugas besar dan mengelolanya. Berputar juga. Anda dapat mengambil tugas besar dan memimpin sekali, dan lain kali mereka akan memimpin Anda.
Ivan: Secara umum, kami tidak memiliki hierarki yang besar. Kami memiliki bos setingkat. Dan tentang melihat dari atas - sama sekali tidak. Terkadang bos kita dengan gagah berani mendukung jika pembebasan sudah dekat.
Nikita: Para bos adalah satu orang, namanya Vitaly Mikheev.
Oleg: Bisakah kamu melihatnya di suatu tempat? Di konferensi atau di tempat lain?
Nikita: Secara umum, pidato saya di konferensi dimulai dengan fakta bahwa St. Petersburg Java Day datang kepada kami di Novosibirsk, ini diselenggarakan oleh Belokrylov dari Oracle, yang sekarang di Bellsoft. Dia bertanya apakah kami ingin berbicara, dan kemudian kami tampil bersama Vitaly. Kemudian saya menyarankan agar dia terus tampil bersama, tetapi dia memutuskan bahwa dia tidak mau lagi.
Oleg: Dan laporan macam apa?
Nikita: "Kisah satu JVM dalam gambar . "
Ivan: Saya ingat laporan ini, lalu saya magang atau hanya berhenti menjadi magang. Dan saya masih berpikir bahwa ini adalah salah satu laporan terbaik yang pernah saya lihat.
Nikita: Mungkin itu adalah "efek perdana" ketika Anda tampil untuk pertama kalinya dalam hidup Anda, Anda menekan dengan baik dengan energi.
Oleg: Apa yang kamu bicarakan?
Nikita: Mereka berbicara bersama tentang JET dari awal hingga akhir selama 20 menit.
Oleg: Selama dua, hanya 20 menit? Biasanya, ketika ada beberapa orang, waktu untuk laporan hanya bertambah.
Nikita: Kami dengan penuh semangat dan bersemangat membicarakan semua topik utama.
Oleg: Vanya, apakah ini memengaruhi keputusan Anda tentang apa yang harus dilakukan selanjutnya? Apakah Anda bekerja untuk perusahaan?
Ivan: Bisa jadi!
Oleg: Hanya saja orang biasanya bertanya mengapa menghadiri konferensi, presentasi, mengapa mendengarkan sesuatu, jika Anda dapat google itu.
Nikita: Tentu saja, menurut pendapat saya, menghadiri konferensi sangat berguna. Saat Anda memiliki kontak langsung, partisipasi langsung, itu sama sekali tidak terlihat di YouTube. Adalah penting bahwa Anda secara langsung, tidak benar-benar berpartisipasi. Anda berhubungan dengan sumbernya. Perbedaannya hampir sama dengan menghadiri konser langsung atau mendengarkannya di rekaman. Mungkin bahkan besar, karena seberapa banyak Anda dapat berbicara dengan artis favorit Anda setelah konser? Tetapi di konferensi Anda dapat menemukan pembicara yang Anda butuhkan dan memintanya untuk semua yang Anda butuhkan - tidak ada masalah.
Ivan: Ngomong-ngomong, mengenai keputusan untuk "tetap di perusahaan", ini adalah cerita yang berbeda. Kami memiliki sistem rekrutmen yang cukup unik untuk karyawan / magang. Kami mengambil magang untuk 2-3 program, biasanya dari fakultas atau dari departemen fisika. Trainee sangat tenggelam dalam topik ini, kurator membantu mereka memahami berbagai mekanisme VM, detail implementasi, dll. - harganya banyak.
Setelah beberapa waktu, mereka mulai memberikan misi tempur, menulis kode nyata dalam produksi. Anda membuat perubahan pada JVM, melihat ulasan, tes, tolok ukur - periksa apakah itu tidak merosot. Anda berkomitmen untuk pertama kalinya. Setelah itu, Anda fokus pada diploma Anda. Biasanya diploma juga merupakan bagian keren dari JVM, eksperimental, penelitian. Ini biasanya dilakukan oleh siswa. Maka Anda dapat memproduksinya - atau mungkin tidak. Saya belum pernah melihat hal seperti itu sehingga begitu banyak waktu dihabiskan untuk magang. Dan saya pribadi sangat menghargainya, karena saya ingat berapa banyak waktu yang saya habiskan untuk saya. Outputnya adalah insinyur JVM. Di mana lagi pabrik seperti itu tentang produksi insinyur JVM?
Oleg: Dan Anda tidak takut bocornya informasi dari magang, maka mereka akan secara terbuka menggambarkan semua ini dalam diploma?
Nikita: Ini bukan masalah, karena kita takut kebocoran di luar negeri, dan terutama tidak ada yang akan membaca bahasa Rusia - ini adalah perlindungan seperti itu, kebingungan :-)
Ivan: Saya memiliki seorang siswa yang membela tahun ini, saya adalah seorang pemimpin, dan ada masalah sehingga tidak semua orang ingin menulis dalam diploma. Kami mengungkapkan sesuatu dari topik yang benar-benar tertutup, dan, misalnya, seorang pengulas bertanya kepada kami mengapa kami tidak membicarakan hal-hal tertentu. Saya mengatakan kepadanya bahwa Anda tidak dapat membicarakannya, ini sangat rahasia, kami tidak bisa. Ya, saya akan memberitahu Anda di telinga Anda, tetapi itu tidak akan pergi ke tempat lain. Jadi kami agak takut dengan hal ini, tetapi secara umum, Anda dapat menemukan banyak hal menarik dalam diploma.
Oleg: Dan bagaimana mencari diploma yang melibatkan Excelsior?
Nikita: Datanglah ke kantor dekan dan minta baca diploma semacam itu.
Ivan: Kami memiliki daftar diploma yang berhasil dipertahankan di situs kami, tetapi hanya nama, tanpa tautan. Dan kami tidak memiliki yang berhasil dipertahankan.
Oleg: Mereka mati atau membela diri.
Ivan: Itu! Kami memiliki skor rata-rata 5,0 lulusan, ada yang tidak melanjutkan ke diploma.
Oleg: Dalam pelatihan ini, pabrik insinyur JVM, memberi tahu kami apa tahapan menjadi Jedi? Ketika mereka memberi Anda lightsaber, kapan Anda bisa mulai melambaikannya?
Nikita: Cukup cepat. Sekarang para pemuda sangat cepat menjadi Jedi, saya bangga dengan mereka.
Ivan: Ngomong-ngomong, Nikita adalah kurator pertamaku ketika aku masih magang. Mengenai magang: pertama Anda melalui seleksi: Anda menyelesaikan masalah, datang ke satu atau lebih wawancara. Jika semuanya baik-baik saja, maka Anda menjadi peserta pelatihan. Pada awalnya, Anda membaca artikel ilmiah tentang topik-topik yang kemungkinan besar terkait dengan diploma masa depan Anda, atau hanya tentang-JVM-topik dalam bahasa Inggris untuk mendapatkan konteksnya. Anda membaca, menulis esai tentang mereka, menjelaskan apa yang terjadi di sana. Mereka sangat tangguh padanya. Beberapa sarjana akan iri dengan proofreading dan persiapan esai semacam itu. Ternyata artikel lengkap dalam bahasa Rusia. Setelah itu, saatnya bagi Anda untuk menulis kode, dan Anda secara perlahan diperkenalkan pada esensi masalah - bagaimana semuanya bekerja.
Nikita: Dan di sinilah ilmu berakhir.
Ivan: Belum tentu!
Nikita: Sayang sekali, pada awal nol kami menerbitkan artikel yang kami bawa ke majalah ACM.
Ivan: Baiklah, kita sedang melakukannya sekarang, apa masalahnya?
Nikita: Apa artikel terakhir kami di majalah ACM?
Ivan: Jadi di ACM, kami tidak mencoba! Sekarang kami ngeblog - ini hal yang sama, hanya orang yang membacanya. Ini adalah kegiatan serupa.
Kembali ke topik Jedi, setelah ini pertama kali Anda melakukan sesuatu dalam produksi di bawah kendali ketat. Dibutuhkan tugas kecil yang tidak terkait dengan diploma masa depan Anda.
Oleg: Misalnya, menulis komentar.
Ivan: Tidak. Fungsionalitas sejati. Siswa harus memberikan kontribusi nyata pertamanya sehingga ia tetap berada dalam produk.Kemudian dia mulai terlibat dalam diploma, ini adalah semacam proyek penelitian, yang kemudian berubah menjadi diploma. Maka, dengan cara yang baik, ia harus menghasilkan penelitian ini - ini adalah tahap keempat. Ini tidak selalu terjadi, karena tidak setiap penelitian diperlukan dan dapat diproduksi saat ini. Bagaimanapun, setelah langkah-langkah ini seorang insinyur JVM baru diperoleh.
Oleg: Dan tahap apa yang paling sulit? Apa yang orang menghabiskan banyak waktu? Apakah ada jenis matematika, atau pemahaman tentang standar, atau hal-hal mendalam lainnya? Terdiri dari apa struktur pengetahuan?
: , . - — - , , , , , , JVM. , , , . , : « !». .
: JET?
: , JVM .
: - , JET — JET. , - , : baseline-. , . , , JET .
: ?
: , . , .
: - , baseline .
: , baseline JIT. , JIT , . , baseline. . - , baseline, .
: - UI-? .
: . . Windows.
: , . , Mac.
: Android ?
: . , Android Linux-, Linux . Linux Android . - . .
: ?
: ? Tidak.
: Android Native SDK. DLL .
: , - , . SO- - , , Linux, , , . Java Android, , SO-, Java Dalvik . 90 , , -.
: iOS ?
: . Android, iOS. , , .
: , 15 .
: iOS . , .
: , .
: ?
: , — .
: . ?
: — JVM, JVM — , , , , , — , . , . . GC - , , . , , , .
: , , , . , , . GDB .
: , . , .. , .. managed- Java/Scala, ( ) IDEA, . — GDB .
: , , unit- , !
: . . , , , . JVM. -, . , : , - « - ( ) . ».
, , — , JVM.
: ?
: .
: . . Spring Boot , JET , .
: , - . , , , — . , JIT, . , .
: JIT — , ?
: , .
: , - , .
: , ? , -, , .
: , , - -. - , , . , . , - . issue-, , . , , .
, . , — , -. , . check-in , 1.5-2 .
: Visual Source Safe, check-in. VSS , check-in . VSS, check-in .
: , JET, JVM , . 1.5-2 . JET, , . - , , , — . ? . .
: JET Scala?
: Scala.
JET Scala, JET-. JET- . , . , Scala-, scalac, …
: check-in Java- , , , .
: - , C++ ?
: , . , , .
: JVM- — , - , . — . , , , — , . , . « ». . , , , :-) — . , GC, - - . , - , , . , - . .
: , ?
: . , . , . QA-, — , . , .
: ?
: , . , , . , . C GC . , , - . , GC - — . - . ? ?
: , .
: , -, . . , — . . - .
: , , , .
: , - ?
: - , .
: JIT?
: JIT . assert, , -, , . .
: , . JCK . - JCK, , . , . UI-, GUI-, JET. - . , GitHub JET-. JET- . QA- , .
: , ? , , ?
: QA Lead — -. QA, . , . , , . , .
: , QA ? , QA-, , — , , . , , - -.
: , . , , , - . , QA Lead , . JVM-, , .
: ? - , QA- , — ?
: JCK, Oracle. Oracle , . - . JCK, - , , , .
: , JCK?
: Oracle. , JVM, - , Oracle.
: . , Open JDK, JCK.
: - , , - , — , . , , - Oracle. , , Oracle .
: ?
: . , - , «value add». JCK, Java, . JCK , — .
: ! , OpenJDK, ?
: . , 70 . , JCK, , , . , , JET , HotSpot . .
: ? .
: Oracle JVM. . « JVM» Joker.
: ?
: , . JVM. : JVM- , , , . , .
: , JCK ?
: , . mailing list, (Alex Buckley), , Java/JVM-, JVM Specification 12.
: JCK .
: JCK, Sun . , — .
: — , ?
: , . . , , CORBA. , - , . 6 , CORBA . , , HotSpot, , , .
: , — ?
: . CORBA , . Swing . JCK Swing, , . .
: « JCK».
: , , JCK . .
: ?
: , , , , , .
: , .
: - , . , . .
: , ?
: , .
: . , . : , . , JCK, Java.
, . - .
: — . , , — . , - . , . , .
: - , ? ?
: — . , - - , - - . Java - ! , GC. — — , .
: , , . (, JVM ). , ? Tapi tidak ada apa-apa. , - - , . JVM , . , .
Java . , , — . Loom Metropolis, Java. - JVM, , , , , . Loom , , . . , — .
. , Java — , 5-6 Java- JPoint . , Java- (Simon Ritter, Rafael Winterhalter). , Call for Papers 31 . . , YouTube. JPoint!