Sergey Kuksenko adalah seorang insinyur kinerja yang telah melihat Java versi 1.0. Selama waktu ini, ia berhasil berpartisipasi dalam pengembangan ponsel, klien, aplikasi server dan mesin virtual. Sejak 2005, Java telah terlibat dalam kinerja dan saat ini bekerja di Oracle untuk meningkatkan kinerja JDK. Salah satu pembicara paling populer di Joker dan JPoint.
Habrapost ini adalah wawancara hebat dengan Sergey, yang didedikasikan untuk topik-topik berikut:
- Kultus Kinerja;
- Kapan dan apa yang perlu dioptimalkan, desain awal bahasa dan perpustakaan;
- Area yang menjanjikan untuk optimasi lebih lanjut;
- Bagaimana cara berpartisipasi dalam pengembangan dan apa yang bisa dilanggar oleh optimisasi;
- Trik penyusun, daftar penempatan;
- Apakah mungkin untuk mengumpulkan kucing dari daging cincang;
- Ketika tes bekerja selama lima hari berturut-turut dan rutinitas rumah tangga lainnya;
- Bagaimana menjadi insinyur kinerja;
- Mempersiapkan laporan untuk Joker berikutnya.
Tentang kultus Produktivitas
Oleg: Anda adalah pembicara lama kami, dan ini bukan wawancara pertama kami. Ceritakan sedikit, siapa kamu sekarang, apa yang kamu lakukan?
Sergey: Saya sama dengan yang saya lakukan bertahun-tahun yang lalu, dan saya melakukan hal yang sama. Saya bekerja di tim Java Performance dan bertanggung jawab atas kinerja mesin Oracle Java, OpenJDK.
Oleg: Lalu saya punya pertanyaan yang agak aneh: di sini Anda adalah insinyur kinerja, dan laporan Anda tentang semua jenis kinerja. Tidakkah menurut Anda masalah kinerja agak berlebihan? Semua orang bergegas bersamanya, tetapi apakah ini bahkan perlu?
Sergey: Ini pertanyaan yang bagus. Itu semua tergantung yang lain. Perhatian penonton seperti ini bisa dianggap berlebihan. Produktivitas bisnis, di sisi lain, adalah uang.
Ini adalah uang nyata yang dihabiskan orang untuk perangkat keras, pada beberapa jenis awan di Amazon. Jika Anda tidak memproses permintaan Anda dengan cukup cepat - itu saja, Anda kehilangan pelanggan, kehilangan uang, kehilangan segalanya. Karena itu, permintaan kinerja tentu saja selalu ada. Pertanyaannya adalah seberapa penting hal itu dalam setiap kasus. Saya diam tentang perdagangan frekuensi tinggi.
Oleg: Omong-omong, apakah menurut Anda Java cocok untuk ini?
Sergey: Apakah Anda memiliki kesempatan untuk bertemu orang seperti Peter Lawrey ?
Oleg: Siapa CEO dari Chronicle Software, pengembang OpenHFT?
Sergey: Ini adalah teman yang sangat terkenal dari London yang sering bepergian dalam konferensi. Mereka bekerja di Jawa dalam perdagangan frekuensi tinggi, mereka hidup hebat.
Oleg: Apakah mereka melakukannya di Jawa atau itu disebut kode asli dari Jawa? Meski begitu, ada perbedaan.
Sergey: Saya tidak tahu pada tingkat ini, dia tidak mengatakannya. Pada prinsipnya, jika diinginkan, semua yang dibutuhkan dapat dicapai di Jawa itu sendiri.
Oleg: Menarik. Jika Anda mengambil, misalnya, komunitas pythonists, maka mereka memiliki produktivitas yang jauh lebih rendah. Bagaimana mungkin ini yang terjadi di komunitas kita? Mungkin Anda memprovokasi kultus kinerja dengan laporan Anda? Anda, Shipilev, Pangin, Ivanov dan sebagainya.
Sergey: Saya tidak tahu bagaimana itu terjadi. Kultus produktivitas di konferensi Rusia jauh lebih tinggi daripada di Amerika. Mungkin ini mencerminkan audiens itu sendiri. Pada kami orang ingin lebih terlibat dalam produktivitas, itu menarik bagi mereka. Dan di Amerika, mereka ingin melakukan lebih banyak untuk apa yang mereka bayar lebih banyak. Tapi ini hipotesis, dugaan. Itu terjadi begitu saja.
Kapan dan apa yang perlu dioptimalkan
Oleg: Anda mengatakan bahwa masih ada permintaan untuk kinerja. Pada titik apa Anda perlu mulai memikirkan kinerja? Kapan guntur akan menyerang?
Sergey: Ini adalah pertanyaan abstrak umum. Lebih baik beralih sekali lagi ke keynote Alexey Shipilev dari salah satu konferensi sebelumnya, di mana ia melukis semua ini dengan cukup baik.
Oleg: Ya, saya ingat "lekukan nama Sh".
Sergey: Anda harus melakukan kinerja segera, tetapi tergantung pada level apa. Tidak perlu segera menulis tolok ukur. Diketahui, misalnya, bahwa pembatasan dangkal tingkat arsitektur API antara Set sebagai himpunan dan SortedSet sudah menerapkan batasan algoritmik mendasar pada kami.
Jika kita memasukkan SortedSet ke dalam API (meskipun tidak ada yang membutuhkan yang diurutkan), dan kemudian menyebar ke seluruh sistem kita, maka hal ini harus ditarik keluar dengan susah payah dan keras.
Pertanyaannya dimulai dari tingkat desain - ini adalah pertanyaan tentang pembatasan minimal. Batasan sekecil mungkin harus digunakan agar Anda dapat bermain dengannya nanti. Misalnya, ketika saya memutar berbagai keping Jawa, kata-kata yang sangat buruk muncul di benak saya. Saya ingin melakukan sesuatu dengan salah satu kelas dasar, tetapi saya tidak bisa melakukan apa-apa, karena API sudah diperbaiki, Anda tidak bisa mengubahnya lagi, sudah merangkak keluar. Tetapi untuk melakukan beberapa trik dan overclocking, Anda perlu menyembunyikan beberapa detail.
Studi kasus: Saya biasa berjongkok di sekitar kelas java.math.BigDecimal. Ada permintaan besar dari berbagai pihak untuk membubarkannya. Ada kasus khusus yang cukup bagus ketika BigDecimal kami bukan "Besar", hanya Decimal, dan Anda perlu membacanya.
Sekarang, tentu saja, pembungkus yang tepat telah dibuat untuk ini. Tetapi jika tidak ada konstruktor publik yang menonjol dari BigDecimal, tetapi beberapa metode dan pabrik statis, orang dapat membuat BigDecimal abstrak, dan mengeluarkan dua implementasi berbeda yang bekerja sesuai kebutuhan. Tapi ini tidak mungkin, karena konstruktor menonjol. Karena itu, Anda harus melakukan pemeriksaan runtime yang tidak perlu di dalam, yang memungkinkan Anda mengikuti jalur cepat dalam beberapa kasus.
Oleg: Apakah mengikuti dari ini bahwa ketika mengembangkan perpustakaan standar layak meninggalkan para desainer dan membuat pembangun di mana-mana?
Sergey: Sudah terlambat.
Oleg: Jika tidak terlambat, apakah itu ide yang bagus?
Sergey: Dia akan memberi lebih banyak ruang untuk bermanuver. Lihat: kami sedang menulis baru, dan ini baru berdiri di luar konstruktor. Dua operasi diperoleh: pertama kita membuat objek, lalu kita memanggil konstruktor yang mengisinya. Dan kadang-kadang akan sangat berguna untuk menyembunyikan penciptaan objek dan membuat objek yang salah yang kita miliki di luar. Ini adalah batasan bahasa, asli, dari masa-masa awal Jawa.
Oleg: Baiklah, sekarang semua orang menggunakan DI-frameworks yang memungkinkan Anda untuk memutar proksi sesuka Anda dan menambahkan apa pun, melewati batasan ini. Dalam desain asli bahasa tersebut, dapatkah Anda menambahkan sesuatu seperti ini, wadah injeksi ketergantungan bawaan?
Sergey: Saya punya pendapat yang sangat spesifik tentang desain awal bahasa. Jika Anda mengingat sejarah Java 1.0, itu keluar tekanan waktu yang cukup serius, semuanya harus dilakukan dengan cepat.
Ada ribuan hal yang secara pribadi ingin saya perbaiki dari versi pertama. Tetapi saya takut bahwa bahkan jika satu dari seribu ini dipilih, satu-dua-tiga, dan mereka akan mulai dibuat pada saat rilis Jawa pertama, maka Jawa tidak akan keluar. Ini adalah contoh standar bahwa yang terbaik adalah musuh dari yang baik.
Apa lagi yang bisa dioptimalkan di Jawa
Oleg: Orang-orang biasa dapat memperbaiki sesuatu hanya dalam proyek mereka, dan Anda, sebagai insinyur kinerja di JDK, segera mempengaruhi ratusan ribu proyek. Timbul pertanyaan: selama lebih dari 20 tahun pembangunan Jawa, apakah ada area di JDK di mana intervensi oleh insinyur inti dapat menyebabkan efek yang nyata? Dan seberapa nyata "efek nyata" ini?
Sergey: Pertama, sekarang Java tidak berfungsi sama sekali pada perangkat keras itu, katakanlah, 10 tahun yang lalu. Besi sekarang dan besi 10 tahun lalu adalah dua perbedaan besar, dan disarankan untuk melakukan berbagai optimasi.
Kedua, tentu saja, luar biasa ketika seorang insinyur kinerja duduk dan mempercepat sesuatu, mendapat jumlah besar, melapor kepada atasannya, merogoh uang untuk bonus setelah overclock ini. Tetapi sejumlah besar pekerjaan sedang dilakukan pada proyek-proyek baru. Fitur ditambahkan, dan tugas insinyur kinerja bukanlah untuk overclock fitur tersebut, tetapi untuk memastikan bahwa semuanya baik-baik saja di fitur ini. Atau jika tidak ok, maka datanglah dengan semacam koreksi.
Oleg: Bagaimana kamu bisa yakin? Anda tidak memverifikasi kode secara formal. Apa itu "pastikan"?
Sergey: Untuk memastikan bahwa semuanya baik-baik saja dari sudut pandang kinerja adalah pendapat ahli subjektif dari seorang insinyur kinerja yang akan menulis laporan dan mengatakan bahwa "semuanya normal dalam fitur ini". Tergantung pada ukuran fitur, ini kadang-kadang menyiratkan sedikit aksi, kadang-kadang banyak upaya yang berbeda. Mulai dari fakta bahwa Anda hanya perlu duduk dengan bodoh, perhatikan apa yang sedang dilakukan di sana, patok area ini, buat tolok ukur, lihat apa yang terjadi di pintu keluar, dan buat keputusan yang masuk akal.
Oleg: Dan dari sudut pandang kinerja dan fitur-fitur baru - apakah Java umumnya bergerak maju? Apakah ada sesuatu di sana? Karena perangkat keras kita tidak banyak berubah, misalnya, jika kita berbicara tentang Intel.
Sergey: Untuk periode berapa ini tidak berubah?
Oleg: Misalnya, 10 tahun terakhir.
Sergey: Ya, adakah AVX-512 pada perangkat keras satu dekade lalu?
Oleg: Tidak. Dia, mungkin, tidak selalu hadir di zaman modern?
Sergey: Saya jelas tidak. Kami memilikinya di lab kami, tetapi semuanya ditempati oleh kompiler. Mereka mengacaukan sejauh ini, jadi saya belum melihat.
Oleg: Bisakah dukungan AVX-512 dianggap sebagai contoh fitur khas?
Sergey: Mungkin saja. Apa yang sebenarnya saya lakukan: kami memiliki lapisan besar pekerjaan pada kenyataan bahwa ada persyaratan modern untuk menambahkan algoritma kriptografi baru. Ini adalah hal di mana algoritma kriptografi berusia sepuluh tahun tidak bisa diandalkan. Kami membutuhkan algoritma baru, kunci yang lebih besar. Dan penambahan algoritma kriptografi baru terjadi, saya akan katakan, terus-menerus.
Oleg: Apakah mereka entah bagaimana mempercepat perangkat keras?
Sergey: Itu semua tergantung pada algoritma tertentu. Ada algoritma yang dipercepat dengan sangat baik. By the way, 10 tahun yang lalu ini tidak akan bekerja pada perangkat keras Intel, tetapi sekitar 5-6 seberapa baik instruksi muncul, hingga AES-unit dengan akselerasi. Semua ini diimplementasikan dengan interval waktu minimum.
Oleg: Bagaimana dengan GPU, apakah mereka juga dapat melipatgandakan matriks?
Sergey: Tentang GPU - percakapan terpisah. Kami memiliki untuk ini ada proyek Panama di mana semua pekerjaan ini dilakukan, dan suatu hari nanti akan mencapai garis utama Jawa dengan semua barang.
Oleg: Saya punya beberapa kenalan yang terlibat, secara kondisional, dalam matematika keuangan. Sejak saat itu, mereka selalu beralih ke C ++ untuk komputasi dan mengklaim bahwa sangat tidak nyaman untuk menggunakan semua optimasi dan perangkat keras ini dari platform yang dikelola. Bisakah ini diperbaiki?
Sergey: Kami juga memiliki permintaan besar untuk ini dan ada sejumlah persyaratan internal. Misalnya, untuk membuat sesuatu bekerja lebih baik di bidang pembelajaran mesin. Sebagai aturan, ini adalah perkalian matriks dangkal, yang dapat dibuang pada GPU. Bekerja pada ini sedang berlangsung, katakanlah begitu.
Kami memiliki dua proyek payung besar: Valhalla dan Panama, yang seharusnya mengumpulkan fitur seperti GPU. Di persimpangan Valhalla dan Panama duduk API vektor yang bekerja dengan instruksi SIMD / SSE / AVX kami langsung dari kode Java, dan Valhalla sendiri dengan tipe inline adalah semua langkah besar ke arah itu.
Apa yang bisa dilanggar oleh optimasi, bagaimana berpartisipasi dalam pengembangan
Oleg: Payung yang Anda sebutkan mirip satu sama lain. Apakah mungkin satu proyek mempengaruhi yang lain, termasuk dalam hal kode dan profil kinerja? Sebagai contoh, apakah Anda memperbaiki sesuatu, dan Ron Presler yang malang, menuangkan air mata, sedang memperbaiki tes-tesnya di suatu sudut di malam hari?
Sergey: Ini terjadi setiap saat. Contoh konkret adalah Vector API. Agar API Vector berfungsi dengan baik, vektor asli kami akhirnya harus menjadi tipe nilai, atau seperti yang sekarang disebut dalam Java, tipe inline. Anda dapat membuat solusi di hotspot dan menerapkannya, tetapi saya ingin memiliki solusi umum. Di sisi lain, fitur utama tipe inline adalah tepatnya tidak perlu khawatir tentang tata letak data ini, dan tata letak data ini sangat penting untuk Vector API.
Karena itu, pada kenyataannya, secara langsung sesuai dengan AVX-512 dan semua itu. Jelas bahwa Anda perlu melakukan beberapa squat, beberapa optimasi, yang, di satu sisi, akan membuat tipe inline menjadi tipe normal, tetapi yang akan memiliki tata letak berbasis perangkat keras. Secara alami, persimpangan terjadi. Jika Anda melihat kelompok orang yang memindahkan Panama dan memindahkan Valhalla, mereka berpotongan lebih dari setengah.
Oleg: Benar-benar organisasi, di sini Anda memiliki sebuah proyek, semacam masalah dengan kinerja, tetapi itu ada di persimpangan beberapa proyek. Apa yang harus dilakukan selanjutnya? Bagaimana cara mengatasinya? Ternyata ini sudah merupakan pertukaran antara proyek dan orang, dan bukan antara beberapa tugas abstrak.
Sergey: Semuanya sangat sederhana di sini: jika ini adalah masalah kinerja dengan fitur yang baru saja dirancang, Anda harus mengunjungi orang-orang yang mendesain dan berkata, “Terus dan terus, apa yang akan kita lakukan? Mari kita lakukan secara berbeda. " Diskusi dimulai, dan masalahnya terpecahkan.
Jika kode sudah ada, sudah berfungsi. Dalam kasus yang ideal, Anda memperbaiki masalah ini, atau, jika Anda tidak dapat memperbaikinya sepenuhnya, Anda mengeluarkan prototipe, lalu Anda kembali ke pemilik kode dan berkata: "Ini prototipe, apa yang akan kita lakukan?" Selanjutnya, kami memecahkan masalah ini secara khusus untuk setiap kasus.
Oleg: Kami memiliki orang yang tertarik di sini yang tidak dapat berpartisipasi dalam proses ini, ini adalah pengguna akhir.
Sergey: Mereka tidak dapat berpartisipasi dengan cukup tepat sehingga mereka tidak akan dibayar untuk gaji mereka di Oracle. Jika Anda tidak membutuhkan gaji, datanglah ke OpenJDK dan ikut serta.
Oleg: Seberapa nyata itu? OpenJDK memiliki beberapa orang jenius sialan seperti Anda, dan di mana orang-orang biasa berada, dan di mana Anda berada. Katakanlah ada sesuatu yang melambat untuk saya, apa yang harus saya lakukan dan bagaimana?
Sergey: Jika Anda tidak tahu masalahnya, ini adalah pertanyaan terpisah, apakah seseorang akan mencari solusi untuk Anda, ini adalah pertanyaan sebagai area, contoh, dan sebagainya. Bahkan jika Anda tidak tahu masalahnya, mungkin masuk akal untuk menulis di OpenJDK dan bertanya. Jika ini adalah sesuatu yang segera diklik seseorang di kepala, orang-orang akan mengambilnya. Jika itu tidak menarik bagi siapa pun, itu akan menggantung tidak dijawab.
Oleg: Misalkan saya tahu masalahnya dan bahkan tahu apa yang perlu diperbaiki.
Sergey: Jika Anda tahu masalahnya, Anda datang ke OpenJDK, menandatangani semua kertas yang diperlukan, menawarkan tambalan, itu direvisi dan dituangkan.
Oleg: Apakah sesederhana itu?
Sergey: Ya, birokrasi kecil, tunggu sebentar. Kemarin Tagir ( lany ) mengambil satu perbaikan kecil yang saya tinggalkan. Dia hanya ingin dibawa sampai akhir. Dia mulai mengingatnya sendiri. Dia berkata: "Sialan, ada apa, aku sudah melakukan segalanya, ditata, tidak ada yang meninjau." Ya, tidak ada yang meninjau. Ini bulan Juli, setengah dari kantor Jawa sedang berlibur. Mereka akan keluar dari liburan dan akan melakukannya.
Oleg: Liburan di AS kira-kira sama dengan tanggal di Rusia?
Sergey: Tidak, sistem liburan di AS sama sekali berbeda dari yang ada di Rusia. Pertama, mereka secara signifikan lebih kecil. Dan juga, di AS, sistem liburan terikat ke sekolah. Ketika Anda memiliki anak berlibur - maka liburan. Begitu liburan dimulai, seluruh Amerika mulai bergerak. Dan karena kelas di sini berakhir pada pertengahan Juni dan dimulai pada pertengahan Agustus, delta untuk liburan ini tidak begitu besar - hanya dua bulan.
Trik penyusun, daftar penempatan
Oleg: Pernahkah terjadi bahwa Anda mengoptimalkan sesuatu di rumah, dan setelah itu pengguna harus menulis kode secara berbeda? Secara relatif, jika operasi memilih substring digunakan untuk mengambil rentang, dan sekarang membuat salinan lengkap, maka refactoring ini mengubah cara Anda menulis kode.
Sergey: Pasti, tapi saya tidak akan memberikan contoh spesifik sekarang. Pertanyaannya adalah, apa yang orang meletakkan ketika menulis kode. Jika mereka perlu memeras kinerja maksimum, dan untuk ini mereka melakukan semua jenis trik khusus-kompiler, mereka harus siap untuk kompiler untuk berkembang dari waktu ke waktu, dan mereka harus terus-menerus mengubah kode mereka sesuai dengan keadaan saat ini dari kompiler. Dan itu bagus.
Misalkan, tiba-tiba, setelah 20 tahun, Graal akan datang sebagai kompiler utama untuk HotSpot - maka orang-orang miskin ini harus menulis ulang semuanya. Ini hanya terjadi jika Anda mengambil tugas teknis seperti itu - untuk melacak perubahan dalam kompiler. Jauh lebih mudah untuk menulis kode yang benar tanpa ikatan langsung, dengan implementasi umum yang lebih atau kurang normal.
By the way, tentang kompiler - bukan hanya tentang kompiler Java, tetapi secara umum. Ada hukum Moore, yang bukan hukum, tetapi hanya pengamatan empiris bahwa jumlah transistor berlipat ganda setiap setengah tahun.
Dan ada hukum yang persis sama (Hukum Proebsting ) bahwa kinerja kode tanpa modifikasi meningkat sebesar 4 persen setiap satu setengah hingga dua tahun. 4 persen ini adalah apa yang pengguna dapatkan secara cuma-cuma dari evolusi kompiler. Bukan perangkat keras, yaitu kompiler.
Oleg: Saya ingin tahu dari mana persentase ini berasal. Apakah ini semacam inefisiensi awal? Tetapi suatu hari nanti stok inefisiensi ini akan berakhir.
Sergey: Tidak, ini hanya masalah pengembangan teknologi. Saya keluar dari kompiler ketika saya mulai bekerja pada kinerja. Tapi begitu saya bertunangan, dan penemuan terbesar bagi saya dibuat pada 2005 atau 2006. Saya mengetahuinya sama sekali pada tahun 2008 karena saya tidak membaca artikel tersebut tepat waktu.
Tugas yang sangat penting dari setiap pembuatan kode adalah alokasi register. Diketahui bahwa secara umum, masalah ini adalah NP-complete. Sangat sulit untuk menyelesaikannya, dan oleh karena itu semua kompiler mencoba untuk menggerakkan semacam algoritma perkiraan dengan berbagai tingkat kualitas.
Dan inilah artikel di mana orang-orang membuktikan bahwa dalam beberapa kasus yang mencakup sejumlah besar kompiler dan sejumlah besar representasi internal dengan batasan tertentu, ada algoritma polinomial yang tepat untuk tugas mengalokasikan alokasi register. Hore, ayo pergi!
Ini terjadi pada 2005, kompiler yang dibuat sebelumnya tidak mengetahui hal ini.
Oleg: Sekarang Anda dapat membuat pengalokasi baru untuk Java?
Sergey: Sekarang ada solusi teoretis, itu bisa ditulis ulang. Saya tidak merinci, tetapi saya tahu bahwa orang-orang dari Excelsior menerapkan algoritma.
Oleg: Kami baru-baru ini melakukan wawancara dengan Cliff Click, dan dia berbicara tentang pengalokasi jenius yang sangat kompleks dan gila yang ditulisnya untuk Jawa. Tidak ingin menulis yang lain?
Sergey: Tidak.
Oleg: Adakah yang normal?
Sergey: Tidak, dia tidak normal. Dari sudut pandang utilitarian saya, saya akan mengatakan bahwa saya mencari assembler dan kadang-kadang saya melihat: "Ya, di sini registernya rusak". Jika saya mencoba menendang kompiler kami, dan kami menulis ulang pengalokasi, lalu apa yang akan kami dapatkan? Kami akan mendapatkan beberapa keuntungan, tetapi saya tidak akan melihatnya kecuali pada contoh-contoh di mana saya melihat alokasi register yang tidak efisien. Selama tidak ada kegagalan besar di bidang ini, selalu ada sesuatu untuk dilakukan dan mendapatkan lebih banyak kemenangan.
Oleg: Apakah ada area kerja di JDK di mana semua kompartemen kompartemen engine atau magic kinerja pecah ke permukaan? Anda mengatakan bahwa Anda perlu menulis kode normal normal dan semuanya akan baik-baik saja, tetapi kedengarannya mencurigakan.
Sergey: Semuanya akan baik-baik saja sampai Anda membutuhkan super duper. Jika Anda membutuhkannya dengan sangat cepat, bersiaplah untuk selalu menulis ulang. Saat ini, jika Anda mengambil aplikasi besar abstrak, pada umumnya, seperti yang tertulis - umumnya tidak berperan dalam hal kinerja.
Di satu sisi, begitu pemicu sampah dipicu, ia memakan 10-20% nya, di sisi lain, arsitektur aplikasi mulai muncul. Masalah besar yang saya lihat di tumpukan aplikasi adalah mereka menggeser data. Kami mengambil data dari sini, mentransfernya ke sana, membuat beberapa transformasi di sana. Secara umum, program apa pun tidak hanya itu. Ini mentransfer data dari satu tempat ke tempat lain dalam beberapa cara. Tetapi jika Anda memiliki terlalu banyak perubahan dalam program, maka kompiler tidak akan membantu.
Oleg: Anda dapat mencoba melacak beberapa hal sederhana, seperti: memori ini mengubah pemilik dan bergerak di antara benda-benda ke arah ini.
Sergey: Tidak, ini masalah desain. Tapi saya tidak hanya bergeser, tetapi bergeser dengan modifikasi, saya melakukan sesuatu dengan mereka. Manfaat terbesar dalam aplikasi nyata dan masif dapat diperoleh jika Anda memikirkannya: apakah ada begitu banyak perubahan yang diperlukan. Alih-alih sepuluh, membuat tujuh sudah bagus.
(Sepertinya video yang sama tidak sengaja diduplikasi di sini. Faktanya, semuanya lebih sederhana, Habr cache gambar yang salah dari YouTube)
Kami mengumpulkan kucing dari daging cincang
Oleg: Kami baru saja mengadakan konferensi Hydra tentang komputasi terdistribusi. Dan begitu banyak orang sangat peduli dengan hal-hal seperti model biaya, menentukan biaya setiap operasi - sangat terperinci, sangat akurat. Orang-orang benar-benar ingin menuliskan semua instruksi, menambahkan biaya masing-masing dan melihat berapa banyak bar yang akan diambil kode Anda. Saya bertanya-tanya bagaimana pendekatan ini bekerja dalam realitas modern. , ?
: , . , . , . , . , , , . ?
: : « ».
: , . , . , ? . — , . , , - , .
: , ?
: , ? , . ?
: , - ?
: , — , . - . ? , , , , . , .
: .
: , 1 . , , . , - , - .
: OpenJDK . ? C++ . — -?
: , , . . OpenJDK 15 . 15 .
: , , . .
: ! , , . , , , , , . , . : , , ( , ), — . , , .
: , ?
: , , Java.
: ?
: , , Valhalla.
: - , , — , ? ? .
: , . — . , , , . , , . . 2-3 , , , , — , .
, , inline-, Java Joker. . , Java- , runtime-. red flag: runtime- 0. ? , out of order- — .
, . , . ? . . baseline, , 5-6 , — . , , - 2 — - . 3% - , . 3% ?
: , ?
: , . performance-, . , , — .
, , . performance- — , - performance- - , . , , .
, , , , performance- — class libraries hotspot, .
: , - performance-, . , , ?
: . ? , performance- performance-.
, : , , Oracle, Twitter, Netflix , - . , — . , performance- , .
- , , performance- , ? , , .
, performance- — . : - performance review, , , , , . — performance .
: « , ...», , — . , - — , , , .
Joker
: Joker . ?
: inline-, .
: , value-?
: , , . . , . value Java- . value, value, by value, - by value, value type. , .
. , , , Rémi Forax - , inline-. , , Kotlin inline- , value- Java, .
. value-, , , mvt (minimum value types), LW 1. LW 2 — , . , , , . , , , , performance- , , , , .
: , - -?
: , - . , , , , invokedynamic .
: , , , , .
: , , , . — , , . , ?
: , , , .
: . , , inline- generic- , inline-. , .
: , - ?
: : inline- LW2 . value-, generic, .
« Java -? Valhalla» Joker , - 25-26 2019 . , .