Hari ini mengakhiri KTT JVM keduabelas. Seperti biasa, itu adalah acara hardcore dengan presentasi teknis pada mesin virtual dan bahasa yang berjalan di atasnya. Seperti biasa, KTT diadakan di Santa Clara, di kampus Oracle. Seperti biasa, ada lebih banyak orang yang ingin ke sini daripada di tempat-tempat lain: jumlah pesertanya tidak melebihi 120. Seperti biasa, tidak ada pemasaran, hanya jeroan.
KTT ini sudah yang ketiga bagi saya, dan setiap kali saya mengunjunginya dengan senang hati, terlepas dari jetlag yang mengerikan. Di sini Anda tidak hanya dapat mendengarkan laporan, tetapi juga mengenal orang-orang yang lebih baik dari dunia JVM, mengambil bagian dalam percakapan informal, mengajukan pertanyaan di lokakarya dan umumnya merasa terlibat dalam pencapaian besar.
Jika Anda tidak menghadiri KTT, itu tidak masalah. Sebagian besar laporan diposting di YouTube segera setelah pertemuan puncak. Sebenarnya mereka sudah tersedia . Untuk mempermudah navigasi, saya akan menjelaskan secara singkat di sini semua laporan dan lokakarya yang berhasil saya hadiri.
29 Juli
Ini bukan tentang fitur kompilasi Masa Depan dalam bahasa Clojure , seperti yang dipikirkan banyak orang, tetapi hanya tentang pengembangan bahasa, seluk-beluk pembuatan kode dan masalah yang mereka hadapi. Sebagai contoh, ternyata di Clojure penting untuk membatalkan variabel lokal setelah penggunaan terakhir, karena jika kepala daftar yang dihasilkan secara malas dalam variabel lokal, maka memintasnya, node yang telah dilewati mungkin tidak dikumpulkan oleh pengumpul sampah, dan program mungkin macet dengan OutOfMemory . Secara umum, kompiler J2 CIT sendiri melepaskan variabel setelah penggunaan terakhir, tetapi standar tidak menjamin ini dan, katakanlah, penerjemah HotSpot tidak.
Itu juga menarik untuk belajar tentang penerapan pengiriman fungsi panggilan dinamis. Saya juga belajar bahwa sampai saat ini, Clojure menargetkan JVM 6 dan hanya baru-baru ini beralih ke JVM 8. Sekarang penulis kompiler melihat invokedynamic.
Proyek Loom adalah utas ringan untuk Java. Setahun yang lalu, Alan dan Ron sudah membicarakan proyek ini, dan sepertinya semuanya berjalan dengan baik dan akan siap. Namun, proyek ini belum secara resmi memasuki Jawa dan masih sedang dikembangkan di cabang repositori yang terpisah. Tentu saja, ternyata perlu menyelesaikan banyak detail.
Banyak API standar dari ReentrantLock.lock ke Socket.accept sudah disesuaikan untuk serat: jika panggilan seperti itu dilakukan di dalam serat, status eksekusi akan disimpan, tumpukan akan dibatalkan dan benang sistem operasi akan dibebaskan untuk tugas-tugas lain sampai suatu peristiwa membangkitkan serat (misalnya, ReentrantLock.unlock). Namun, misalnya, blok lama yang disinkronkan masih tidak berfungsi dan, sepertinya, tidak akan ada tanpa refactoring serius semua dukungan sinkronisasi di JVM. Pelonggaran tumpukan lainnya tidak akan berfungsi jika ada bingkai asli di tumpukan antara awal serat dan breakpoint. Dalam kedua kasus ini, tidak ada yang akan meledak, tetapi serat tidak akan membebaskan aliran.
Ada banyak pertanyaan mengenai bagaimana Fiber membandingkan dengan kelas java.lang.Thread lama. Setahun yang lalu, ada ide untuk menjadikan Fiber sebagai subclass dari Thread. Sekarang mereka telah menolaknya dan menjadikannya entitas yang independen, karena meniru dalam setiap serat semua perilaku aliran reguler cukup mahal. Dalam hal ini, Thread.currentThread () di dalam fiber akan mengembalikan blende yang dihasilkan, dan bukan thread asli di mana semuanya dijalankan. Namun halangan tersebut akan berperilaku cukup baik (meskipun dapat memperlambat pekerjaan). Ide penting adalah untuk tidak memberikan aliran media aktual di mana serat berjalan di dalam serat. Ini bisa berbahaya karena serat dapat dengan mudah dipindahkan ke utas lainnya. Tipuan akan terus berlanjut.
Sangat mengherankan bahwa para peserta proyek telah mendorong beberapa perubahan persiapan ke dalam repositori JDK utama untuk membuat hidup mereka lebih mudah. Sebagai contoh, di Java 13, metode doPrivileged ditulis ulang dari kode asli seluruhnya di Jawa, memperoleh peningkatan kinerja sekitar 50 kali lipat. Mengapa ini proyek Loom? Faktanya adalah bahwa metode khusus ini sangat sering muncul di tengah tumpukan, dan meskipun asli, serat dengan tumpukan ini tidak berhenti. Dengan satu atau lain cara, proyek ini sudah menguntungkan.
Pada halaman proyek, Anda dapat membaca dokumentasi dan mengunduh source tree, dan ada juga rakitan biner yang dapat Anda ambil dan mainkan hari ini. Kami berharap di tahun-tahun mendatang semuanya akan terintegrasi.
Brian Goetz - Workshop "Project Amber"
Secara paralel, sebuah lokakarya sedang berlangsung tentang proyek Loom, tetapi saya pergi ke Amber. Di sini kita secara singkat membahas tujuan proyek dan JEP utama di mana pekerjaan sedang berlangsung - Pencocokan pola , Catatan dan jenis-jenis yang disegel . Kemudian seluruh diskusi menjadi masalah pribadi pelingkupan. Saya membicarakan hal ini di konferensi Joker tahun lalu, pada prinsipnya, tidak ada yang sangat baru yang dikatakan. Saya mencoba untuk mendorong sebuah ide dengan tipe serikat implisit seperti if(obj instanceof Integer x || obj instanceof Long x) use(x.longValue()) , tetapi saya tidak melihat antusiasme.
Dalam segala hal, proyek luar biasa dari Google untuk mencari balapan menggunakan data dalam bentuk membaca dan menulis bidang non-volatil yang sama atau elemen array dari aliran yang berbeda tanpa mengatur hubungan yang terjadi sebelumnya. Proyek ini awalnya ditulis sebagai modul LLVM untuk kode asli, dan sekarang telah diadaptasi untuk HotSpot. Ini adalah proyek OpenJDK resmi dengan milis dan repositori.
Menurut penulis, masalahnya sekarang cukup bekerja, Anda bisa berkumpul dan bermain. Selain itu, ia menemukan balap tidak hanya dalam kode Java, tetapi juga dalam kode perpustakaan asli. Ras dalam kode mesin virtual itu sendiri tidak dicari, karena di sana semua sinkronisasi primitif ditulis dengan cara mereka sendiri, dan TSan tidak dapat mendeteksi mereka. Menurut penulis, TSan tidak memberikan positif palsu.
Masalah utama adalah kinerja. Sekarang hanya interpreter yang diinstrumentasi untuk kode Java, masing-masing, kompilasi JIT benar-benar dinonaktifkan, dan interpreter, yang sudah lambat, melambat beberapa kali. Tetapi jika Anda memiliki sumber daya yang cukup (Google memiliki, tentu saja, cukup), Anda kadang-kadang dapat menjalankan suite pengujian menggunakan TSan. Juga direncanakan untuk menambah instrumentasi ke dalam JIT, tetapi ini adalah intervensi yang jauh lebih serius dalam JVM.
Seseorang bertanya apakah menonaktifkan kompilasi JIT tidak memengaruhi hasil, karena beberapa ras mungkin tidak muncul pada penerjemah. Pembicara tidak mengesampingkan kemungkinan ini, tetapi mengatakan bahwa mereka telah menemukan sejumlah besar balapan yang akan memakan waktu sangat lama untuk dikerjakan. Jadi berhati-hatilah saat menjalankan proyek Anda di bawah TSan: Anda mungkin menemukan kebenaran yang tidak menyenangkan.
Semua orang menunggu tipe nilai di Jawa, tetapi tidak ada yang tahu kapan mereka akan muncul. Namun, gerakannya semakin serius. Sudah ada majelis uji biner dengan tonggak L2 saat ini. Dalam rencana saat ini, Valhalla penuh akan datang pada tonggak L100, tetapi penulis masih optimis dan percaya bahwa lebih dari dua persen telah dilakukan.
Jadi, dari sudut pandang bahasa, kami memiliki kelas dengan pengubah inline, yang diproses secara khusus oleh mesin virtual. Contoh kelas seperti itu dapat tertanam dalam objek lain, dan array datar yang mengandung instance kelas inline juga dimungkinkan. Contoh tidak memiliki header, yang berarti tidak ada identitas, kode hash dianggap oleh bidang, == juga oleh bidang, upaya untuk menyinkronkan atau Object.wait() pada kelas seperti itu akan meningkatkan IllegalMonitorStateException. Menulis null ke variabel jenis ini, tentu saja, tidak akan berfungsi. Namun, penulis menawarkan alternatif: jika Anda telah mendeklarasikan Point inline-class, maka Anda dapat mendeklarasikan field atau variabel tipe (surprise-surprise!) Point? , dan kemudian akan ada objek penuh pada heap (seperti tinju) dengan header, identitas, dan null muat di sana.
Pertanyaan terbuka yang serius tetap menjadi spesialisasi generik dan migrasi kelas yang ada (misalnya, Optional ) ke kelas inline agar tidak memecah kode yang ada (ya, orang menulis null ke variabel tipe Optional ). Meskipun demikian, gambar tampak, dan celahnya terlihat.
Itu mengejutkan bagi saya bahwa Neil Gufter yang sama, co-author dari Java puzzlers asli, sekarang bekerja di Microsoft pada .Net runtime. Itu juga mengejutkan untuk melihat laporan tentang CLR (yang disebut .Net runtime) pada JVM LS. Tetapi untuk berkenalan dengan pengalaman rekan kerja dari dunia lain selalu bermanfaat. Laporan ini berbicara tentang variasi referensi dan petunjuk dalam CLR, tentang instruksi bytecode yang digunakan untuk tipe nilai, dan tentang betapa indahnya fungsi umum seperti pengurangan. Sangat menarik untuk mengetahui bahwa salah satu tujuan dari tipe nilai dalam. Net adalah interop dengan kode asli. Karena itu, lokasi bidang dalam tipe nilai benar-benar diperbaiki dan dapat diproyeksikan ke struktur tanpa transformasi. JVM tidak pernah memiliki tugas seperti itu, dan apa yang harus dilakukan dengan interop asli - lihat di bawah.
Sekali lagi perbarui laporan tahun lalu . Sekali lagi, pertanyaannya adalah mengapa mereka masih belum merilis apa pun, jika setahun yang lalu semuanya terlihat cukup bagus.
Vektor adalah kumpulan beberapa angka, yang dalam perangkat keras dapat diwakili oleh register vektor tunggal seperti zmm0 untuk AVX512. Dalam vektor, Anda dapat memuat data dari array, melakukan operasi padanya seperti perkalian elemen-bijaksana, dan melemparkannya kembali. Semua operasi yang terdapat instruksi prosesor diinstrusi oleh kompiler JIT ke dalam instruksi ini. Jumlah operasi sangat besar. Jika ada yang hilang, implementasi lambat alternatif digunakan. Objek perantara vektor idealnya tidak dibuat, analisis pelarian berfungsi. Semua algoritma komputasi standar di-vektor-kan dengan bang, menggunakan semua kekuatan prosesor Anda.
Sayangnya, sulit bagi penulis untuk tidak memiliki valgalla: analisis pelarian rapuh dan mungkin tidak bekerja dengan mudah. Vektor ini hanya harus kelas inline, maka semua masalah akan hilang. Tidak jelas apakah API ini bahkan dapat dirilis sebelum versi pertama Valgalla. Tampaknya jauh lebih siap. Di antara masalah yang disebut kesulitan dengan dukungan kode. Ada banyak potongan berulang untuk ukuran register yang berbeda dan tipe data yang berbeda, sehingga sebagian besar kode dihasilkan dari templat dan menyakitkan untuk mempertahankannya.
Penggunaannya juga tidak sempurna. Tidak ada operator kelebihan di Jawa, sehingga matematika terlihat jelek: bukannya max(va-vb*42, 0) Anda harus menulis va.lanewise(SUB, vb.lanewise(MUL, 42)).lanewise(MAX, 0) . Akan menyenangkan untuk memiliki akses ke AST lambdas seperti di C #. Maka akan mungkin untuk menghasilkan operasi lambda kustom seperti MYOP = binOp((va, vb) -> max(va-vb*42, 0)) dan menggunakannya.
30 Juli
Hari kedua berlalu di bawah bendera kompilasi.
Seorang karyawan IBM, anggota proyek JVM OpenJ9, berbicara tentang pengalaman mereka dengan kompilasi JIT dan AOT. Selalu ada masalah: JIT adalah startup yang lambat, karena sedang memanas; Biaya CPU untuk kompilasi. AOT - kinerja suboptimal karena kurangnya profil (dimungkinkan untuk profil, tetapi non-sepele dan tidak selalu profil selama kompilasi cocok dengan profil saat eksekusi), lebih sulit untuk digunakan, mengikat ke platform target, OS, pengumpul sampah. Beberapa masalah dapat diselesaikan dengan menggabungkan pendekatan: mulai dengan kode yang dikompilasi AOT dan kemudian diakhiri dengan JIT. Alternatif yang baik untuk semua ini adalah caching JIT. Jika Anda memiliki banyak mesin virtual (halo, microservices), semuanya beralih ke layanan terpisah - kompiler JIT (ya, JITaaS), di mana semuanya seperti orang dewasa, orkestrasi, penyeimbangan beban. Layanan ini mengkompilasi. Cukup sering, ia dapat memberikan kode yang sudah jadi ke metode tertentu, karena metode ini sudah dikompilasi di JVM lain. Ini sangat meningkatkan pemanasan, menghilangkan konsumsi sumber daya dari layanan JVM Anda, dan umumnya mengurangi total konsumsi sumber daya.
Secara umum, JITaaS bisa menjadi kata kunci berikutnya di dunia JVM. Sayangnya, saya tidak mengetahui apakah ini bisa dimainkan sekarang atau masih merupakan pengembangan tertutup.
GraalVM Native Image adalah aplikasi Java yang dikompilasi ke dalam kode asli yang berjalan tanpa JVM (tidak seperti modul yang dikompilasi menggunakan kompiler AOT seperti jaotc). Lebih tepatnya, ini bukan aplikasi Java. Untuk bekerja dengan benar, ia membutuhkan dunia tertutup, yaitu, semua kode harus terlihat pada tahap kompilasi, tanpa Class.forName. Anda dapat refleksi dan menangani metode, tetapi ketika Anda mengkompilasi Anda harus secara khusus memberitahu kelas dan metode mana yang akan digunakan melalui refleksi.
Hal lain yang menyenangkan adalah inisialisasi kelas. Banyak kelas diinisialisasi selama kompilasi. Yaitu, bidang statis Anda akan dihitung secara default oleh kompiler dan hasilnya akan ditulis ke gambar yang dikumpulkan, dan ketika Anda memulai aplikasi, itu hanya dibaca. Ini diperlukan untuk mencapai kualitas kompilasi yang lebih baik: setiap pelipatan konstan dapat dilakukan jika nilai-nilai bidang statis diketahui oleh kompiler. Semuanya baik-baik saja dengan JIT, penerjemah melakukan inisialisasi statis, dan kemudian mengetahui konstanta, Anda dapat mengkompilasi. Dan ketika membangun aplikasi asli, Anda harus menipu. Ini, tentu saja, mengarah pada efek psikedelik yang menyenangkan. Jadi kelas biasanya diinisialisasi dalam urutan mereka diakses, dan selama kompilasi urutan ini tidak diketahui dan inisialisasi di tempat lain dimungkinkan. Jika ada referensi melingkar antara inisialisasi kelas, Anda dapat melihat perbedaan dalam perilaku kode JVM dan pada gambar asli.
Workshop Schatzl - Hotspot GC.
Mengatasi semua rasa sakit yang terkait dengan pengumpul sampah. Sayangnya, saya paling banyak mendengarkan. Saya ingat bahwa memori memori OS telah dibahas, termasuk Xmx menjijikkan untuk semua orang. Ada kabar baik: di Java 13 opsi baru -XX ditambahkan: SoftMaxHeapSize. Sejauh ini, hanya didukung oleh kolektor ZGC, tetapi G1 juga dapat mengejar ketinggalan. Ini menetapkan batas ukuran tumpukan, yang tidak boleh dilampaui kecuali dalam situasi darurat, ketika itu tidak berhasil secara berbeda. Dengan demikian, Anda dapat mengatur Xmx besar (katakanlah, sama dengan ukuran seluruh RAM) dan beberapa SoftMaxHeapSize yang masuk akal. Maka JVM akan menjaga dirinya sendiri dalam sebagian besar waktu, tetapi pada beban puncak itu masih tidak akan membuang OutOfMemoryError, tetapi akan mengambil lebih banyak memori dari OS. Saat beban turun, memori akan kembali.
Microsoft Mei-Chin Tsai berbicara tentang fitur kompilasi JIT dan AOT di CLR. Kompilasi AOT telah berkembang untuk mereka untuk waktu yang lama, tetapi awalnya (ngen.exe) dilakukan pada platform target, semacam seperti pertama kali dimulai (jika Anda memiliki Windows, cari file * .ni.dll di folder Windows). File diperoleh tergantung pada versi Windows lokal dan bahkan pada DLL-ek lainnya. Dengan demikian, jika ketergantungan diperbarui, semua modul asli harus dikompilasi ulang. Pada generasi kedua (crossgen), penulis mengkompilasi aplikasi dan modul yang relatif tidak tergantung pada versi dan dependensi perangkat keras dan OS. Ini memperlambat kode karena panggilan ketergantungan sekarang harus dibuat secara virtual virtual. Masalah ini diselesaikan dengan menghubungkan JIT dan mengkompilasi ulang kode panas selama aplikasi. Kemudian kami berbicara tentang kompilasi multi-level (berjenjang) (sepertinya di CLR ini masih dalam masa pertumbuhan, sementara itu telah berkembang di Jawa selama setidaknya sepuluh tahun) dan tentang rencana masa depan untuk membuat AOT benar-benar lintas platform.
Rekan-rekan Alibaba mempresentasikan pendekatan mereka terhadap masalah pemanasan JVM. Mereka menggunakan JVM untuk banyak layanan web. Pada prinsipnya, startup yang sangat cepat tidak begitu penting, karena penyeimbang selalu dapat menunggu sampai mesin dinyalakan dan baru kemudian mulai mengirim permintaan ke sana. Namun, masalahnya adalah bahwa mesin tidak melakukan pemanasan tanpa permintaan: kode yang menjelaskan logika untuk memproses permintaan tidak dipanggil, yang berarti tidak dikompilasi. Ini akan dikompilasi ketika permintaan pertama tiba, yaitu, tidak peduli berapa banyak penyeimbang menunggu, akan ada kegagalan kinerja pada permintaan pertama. Sebelumnya, mereka mencoba menyelesaikan ini dengan melemparkan permintaan palsu ke layanan yang akan datang sebelum mengirim permintaan nyata ke sana. Pendekatannya menarik, tetapi agak sulit untuk menghasilkan aliran palsu yang akan menyebabkan kompilasi semua kode yang diperlukan.
Masalah yang terpisah adalah deoptimisasi. Dalam ribuan kueri pertama, satu if selalu berjalan di sepanjang cabang pertama, kompiler JIT umumnya melemparkan yang kedua, memasukkan perangkap deoptimisasi di sana untuk mengurangi ukuran kode. Tetapi permintaan 1001 pergi ke cabang kedua, deoptimisasi berhasil dan seluruh metode pergi ke penerjemah. Sementara statistik sedang dikompilasi lagi, sementara metode ini dikompilasi oleh kompiler C1, kemudian oleh profil lengkap oleh kompiler C2, pengguna akan mengalami penurunan. Dan kemudian dalam metode yang sama lain if dapat dioptimalkan, dan semuanya akan berjalan pada yang baru.
JWarmUp memecahkan masalah sebagai berikut. Selama menjalankan pertama dari layanan, log kompilasi ditulis selama beberapa menit: ia mencatat metode mana yang dikompilasi dan informasi profil yang diperlukan oleh cabang, jenis, dll. Jika layanan ini dimulai kembali, segera setelah startup, semua kelas dari log diinisialisasi dan metode log dikompilasi dengan mempertimbangkan profil sebelumnya. Akibatnya, kompiler akan bekerja dengan baik pada saat startup, setelah itu penyeimbang akan mulai mengirim permintaan ke JVM ini. Pada saat ini, semua kode panas dia sudah dikompilasi.
Perlu dicatat bahwa masalah mulai cepat tidak diselesaikan di sini. Peluncuran bahkan bisa lebih lambat karena banyak metode dikompilasi, beberapa di antaranya mungkin diperlukan hanya beberapa menit setelah peluncuran. Tetapi log ternyata dapat digunakan kembali: tidak seperti AOT, Anda dapat meningkatkan layanan pada arsitektur yang berbeda atau dengan pengumpul sampah yang berbeda dan menggunakan kembali log sebelumnya.
Penulis telah mencoba untuk waktu yang lama untuk mendorong JWarmUp ke OpenJDK. Sejauh ini tidak berhasil, tetapi pekerjaan terus berjalan. Masalah utamanya adalah tambalan lengkap cukup mudah diakses oleh Anda sendiri di server Code Review, sehingga Anda dapat dengan mudah menerapkannya ke sumber HotSpot dan membangun JVM sendiri dengan JWarmUp.
Ini adalah makalah penelitian dari Manchester, tetapi penulis mengklaim bahwa proyek tersebut telah dilaksanakan di beberapa tempat. Ini juga merupakan add-on untuk OpenJDK, yang membuatnya cukup mudah untuk mentransfer kode Java tertentu ke GPU, iGPU, FPGA atau hanya memparalelkannya ke inti prosesornya. Untuk mengkompilasi pada GPU, mereka menggunakan GraalVM di mana mereka membangun backend mereka - TornadoJIT. Metode Java yang ditulis dengan benar pergi secara transparan ke perangkat yang sesuai. Benar, mereka mengatakan kompilasi pada FPGA bisa memakan waktu beberapa jam, tetapi jika tugas Anda dianggap sebulan, mengapa tidak. Beberapa tolok ukur (misalnya, transformasi Fourier diskrit) lebih dari seratus kali lebih cepat dari Jawa telanjang, yang pada prinsipnya diharapkan. Proyek ini sepenuhnya diunggah ke GitHub , di mana Anda juga dapat menemukan publikasi ilmiah tentang topik tersebut.
Semua lagu yang sama - proyek lama, setiap presentasi puncak, setahun yang lalu semuanya tampak cukup siap, tetapi masih belum ada rilis. Ternyata sejak itu fokusnya telah bergeser.
Gagasan proyek adalah peningkatan interope dengan kode asli. Semua orang tahu betapa menyakitkannya menggunakan JNI. Sangat menyakitkan. Proyek Panama membatalkan rasa sakit ini: menggunakan kelas Java jextract dihasilkan dari file * .h perpustakaan asli, yang cukup nyaman untuk digunakan dengan memanggil metode asli. Di sisi C / C ++, Anda tidak perlu menulis satu baris sama sekali. Selain itu, semuanya menjadi jauh lebih cepat: overhead pada panggilan ke Jawa-> asli dan asli-> Jawa jatuh pada waktu. Apa lagi yang Anda inginkan?
Ada masalah yang telah ada selama beberapa waktu - mentransfer array data ke kode asli. Hingga saat ini, metode yang direkomendasikan adalah DirectByteBuffer, yang memiliki banyak masalah. Salah satu yang paling serius adalah seumur hidup yang tidak dikelola (buffer akan hilang ketika pemungut sampah mengambil objek Java yang sesuai). Karena ini dan masalah lain, orang menggunakan Unsafe, yang, dengan uji tuntas, dapat dengan mudah menempatkan seluruh mesin virtual.
Ini berarti Anda memerlukan akses memori normal baru di luar heap Java. Alokasi, pengakses terstruktur, penghapusan eksplisit. Accessors terstruktur - sehingga Anda tidak perlu menghitung sendiri offset jika Anda perlu menulis, misalnya, struct { byte x; int y; }[5] struct { byte x; int y; }[5] struct { byte x; int y; }[5] . Sebaliknya, Anda pernah menggambarkan tata letak struktur ini dan kemudian melakukan, misalnya, VarHandle , yang dapat membaca semua x dengan melompati y . Dalam hal ini, tentu saja, harus selalu ada pemeriksaan perbatasan, seperti pada array Java biasa. Selain itu, harus ada larangan akses ke area yang sudah ditutup. Dan ini ternyata menjadi tugas yang tidak sepele jika kita ingin mempertahankan kinerja pada tingkat Tidak Aman dan memungkinkan akses dari banyak utas. Singkatnya, tonton videonya, sangat menarik.
Workshop: Vladimir Kozlov - Proyek Metropolis
Proyek Metropolis menggabungkan semua upaya untuk menulis ulang bagian JVM di Jawa. Bagian utamanya hari ini adalah kompiler Graal. Dalam beberapa tahun terakhir, telah berkembang sangat baik dan sudah ada pembicaraan nyata tentang penggantian penuh untuk C2 yang menua. Dulu ada masalah bootstrap: grail mulai perlahan, karena ia sendiri harus dikompilasi atau ditafsirkan JIT. Kemudian kompilasi AOT muncul (ya, tujuan utama proyek kompilasi AOT adalah bootstrap dari grail itu sendiri). Tetapi dengan AOT, grail memakan porsi yang cukup dari tumpukan aplikasi Java yang mungkin tidak benar-benar ingin berbagi tumpukannya. Sekarang kita telah belajar bagaimana mengubah grail menjadi perpustakaan asli menggunakan Graal Native Image, yang pada akhirnya memungkinkan kita untuk mengisolasi kompiler dari tumpukan umum. Dengan kinerja puncak dari kode yang disusun oleh grail, masih ada masalah pada beberapa tolok ukur. Sebagai contoh, grail tertinggal C2 dalam intrinsik dan vektorisasi. Namun, berkat analisis pembalikan dan pelarian yang sangat kuat, ia hanya memecah C2 pada kode fungsional, di mana banyak objek yang tidak dapat diubah dan banyak fungsi kecil dibuat. Jika Anda menulis di Rock dan masih tidak menggunakan grail, jalankan untuk menggunakan. Selain itu, dalam versi terbaru JDK cukup sepele untuk melakukan beberapa kunci, semuanya sudah ada dalam kit.
31 Juli
Kevin Bourrillion - Anotasi Nullness untuk Java
Kevin mengumumkan proyek baru, tetapi meminta untuk tidak berbicara di depan umum dan tidak memposting rekaman pidatonya di YouTube. Maaf sekali , .
Sorbet (!) Ruby, Ruby . , Stripe Ruby , , . , .
Lightning Talks
- . Remi Forax , , . , :
, - , .
ML AI , . , Facebook — getafix , --, , . . , , . , , .
. . OpenJDK Committer Workshop.