Hari-hari terakhir masih tersisa sebelum Joker, dan aku benar-benar ingin membawa ke Habr bukan wawancara biasa, tetapi beberapa permainan yang kuat. Baru-baru ini, orang-orang telah tertarik pada server di Arm, dan kebetulan kami memiliki pakar nyata tentang topik ini.
Alexander (
alexbel ) Belokrylov dan Lesha Voitylov, bersama dengan Grigory Labzovsky, yang memimpin pusat pengembangan Oracle di St. Petersburg, mendirikan BellSoft sedikit lebih dari setahun yang lalu. Sekarang perusahaan ini berhasil beroperasi, berkembang dan telah mendapatkan ketenaran di dunia Jawa.
Dengan volume komitmen di OpenJDK selama setahun terakhir, mereka berada di tempat kelima, dan sekarang hanya Oracle, Red Hat, SAP dan Google yang ada di depan:
Anda perlu memahami bahwa BellSoft tidak hanya Arm:
- Liberica JDK 11 telah dirilis , Linux x86_64, Windows, Linux ARMv8, Linux ARMv7 (termasuk Raspberry Pi) didukung. Akan membangun perakitan untuk Mac dan Solaris Sparc.
- Gambar untuk semua arsitektur diterbitkan di Docker Hub untuk Debian, CentOS, Alpine. Gambar untuk Alpine dibuat dari versi lite dengan
--compress 2 karena itu secara signifikan lebih kecil dari JDK biasa.
Dalam wawancara ini, kami hanya akan menyentuh Arm, dan meninggalkan sisanya untuk waktu berikutnya.
Jadi hari ini di studio virtual kami:
Alexander Belokrylov
Lesha Voytylov
Oleg Chirukhin - editor Grup JUG.ru
Ceritakan lebih banyak tentang perusahaan ini?
Perusahaan BellSoft bergerak di beberapa bidang. Semua orang mungkin tahu bahwa Oracle di St. Petersburg memiliki keahlian tingkat rendah yang sangat serius dalam pengembangan Java Runtime, dalam pengembangan kompiler, dalam pengembangan sistem layanan Oracle Cloud. Dan keahlian dari Oracle ini bermigrasi ke BellSoft. Hari ini, perusahaan kami mengembangkan Java Runtime, kami adalah kontributor OpenJDK aktif, kami sedang mengembangkan kompiler gcc dan llvm, kami akan berkontribusi pada Apache, tumpukan Graal. Kami terlibat dalam pembangunan sistem analisis data besar, sistem rekomendasi, dan telah membangun proyek kecil di IoT, untuk mengumpulkan data dari perangkat dari dunia nyata. Pada titik tertentu, kami melihat bahwa Oracle berhenti merilis distribusi Java untuk platform Arm, dan kami merilis distribusi kami sendiri, yang disebut Liberica JDK untuk Raspberry Pi. Sejak itu, kami berhasil mendukungnya.
Mari kita lihat lebih dekat. Apa itu tumpukan Apache, misalnya?
Kami mulai berkontribusi pada Yayasan Apache dengan Hadoop - banyak yang terkait dengan bagian-bagian tertentu dari proyek ini. OpenJDK dan proyek Apache besar, walaupun tidak secara langsung, tetapi sangat saling berhubungan.
Mengapa semua ini diperlukan? Sebagai contoh, beberapa kelas yang memperlambatnya dapatkah mereka di-overclock?
Ya, ini adalah salah satu bidang yang kami kerjakan - meningkatkan produktivitas. Sebagai contoh, bagian platform tertentu, akselerasi yang ada di OpenJDK dapat membantu mempercepat Hadoop. Jika tertarik, kita bisa membicarakannya.
Ketika Anda memecahkan masalah kinerja, masuk akal untuk melihat sesuatu yang dekat. Mungkin ada masalah yang sama di suatu tempat. Anda sangat sering melihat bahwa setelah diperbaiki di satu tempat, Anda perlu mengoreksi di beberapa tempat, sehingga secara umum menjadi lebih baik. Kadang-kadang (dan sangat sering) optimasi kinerja didekomposisi menjadi kontribusi ke beberapa proyek. Jika Anda ingin meningkatkan, misalnya, kinerja checksum , Anda melihat bagian paling bawah tumpukan. Katakanlah itu Jawa. Jika Anda terlihat sedikit lebih tinggi, itu akan menjadi Hadoop, Spark atau yang lainnya. Biasanya, memahami bagaimana meningkatkan satu tempat, Anda dapat memahami bagaimana melakukannya di tempat lain. Tentu saja, masuk akal dalam hal ini untuk pergi dan meningkatkan di sana juga.
Semua orang tahu bahwa Anda adalah Liberica :-) Mari kita bicarakan ini.
Ya, kami adalah Liberica JDK. Liberica mulai dengan fakta bahwa kami melihat bahwa tidak ada port untuk ARM32, dan hal itu perlu segera dilakukan, karena Raspberry Pi dibiarkan tanpa Java 9 dan Java 10. Ini pada tahun 2017 ketika Java keluar. Sekarang Liberica JDK mendukung banyak arsitektur dan sistem operasi.
Menjadi jelas bahwa Oracle tidak akan mengembangkan lebih lanjut kode untuk Arm, dan kami mulai secara aktif mendistribusikan dan merilis distribusi kami untuk menutup celah ini. Menjadi jelas bahwa orang membutuhkannya.
Jadi, sekarang ada beberapa distribusi Arm?
Ya, ada beberapa distribusi Java untuk Arm, mereka berbeda. Di kami, Anda benar-benar mendapatkan apa yang digunakan untuk menjadi bagian dari kit distribusi port Oracle. Distribusi kami memiliki JavaFX, input / output perangkat, dan API yang dapat disematkan. Ini adalah paket, dan semuanya bekerja dengan modul, dimulai dengan JDK 9. Menggunakan sistem modular, Anda dapat membangun Runtime seperti yang Anda inginkan. Jika mau, Anda bisa membuat Runtime 16 megabyte kecil. Jika Anda ingin mengaktifkan lebih banyak fitur, misalnya, server web, maka Anda harus menghabiskan sekitar 32 megabita ruang statis. Anda bisa mendapatkan Runtime yang berfungsi untuk kebutuhan Anda.
Sejauh yang saya mengerti, kami berbicara tentang server tentara. Bukan untuk mengatakan bahwa kami telah menggunakannya secara besar-besaran. Ceritakan tentang server? Dalam kehidupan nyata apakah mereka ada?
Kisah ini telah ada selama bertahun-tahun. Server Arm pertama dibuat berdasarkan arsitektur ARMv7 32-bit. Itu adalah kotak yang sangat bising, yang praktis tidak berfungsi, karena BIOS, Linux tidak bekerja di sana, semuanya menghilang setelah beberapa jam. Perusahaan yang memulainya, Calxeda, tutup seiring waktu. Tetapi gagasan untuk mengembangkan arsitektur alternatif untuk server ditaburkan di masyarakat. Arm akhirnya merilis spesifikasi baru untuk arsitektur ARMv8, yang mendukung 32 dan 64 bit. Berdasarkan versi 64-bit dari spesifikasi ini, beberapa produsen sekarang membangun implementasi prosesor mereka untuk server. Misalnya, Ampere Computing, Cavium, yang sekarang dibeli oleh Marvell, dan Qualcomm. Dan ada perusahaan lain - AMD, beberapa tahun yang lalu, juga merilis server berdasarkan arsitektur Arm. Menurut pendapat saya, mereka masih terus melakukan ini.
Jika Anda menghapus satu huruf L dari Marvell, Anda mendapatkan pahlawan super. Cara yang baik untuk mengingat nama-nama semua kantor ini.
Para pahlawan super sebenarnya ada Cavium / Marvell, karena mereka semua adalah mereka yang berhasil merakit chip paling produktif hingga 128 thread pada satu CPU, dan sebanding atau lebih baik dalam kinerja dengan Xeon Gold dan Platinum. Anda dapat menempatkan beberapa CPU dalam satu server, Anda mendapatkan hal yang mengerikan dengan memori cepat yang dapat digunakan untuk tugas-tugas serius.
Bagaimana batas skalabilitas tumbuh untuk aplikasi umum? Berapa banyak CPU yang masuk akal untuk tetap di satu server?
Semuanya tergantung pada tugas apa yang Anda inginkan untuk membangun server. Pabrikan yang berbeda dipandu oleh ceruk yang berbeda, tetapi jika kita berbicara tentang Cavium / Marvell, mereka jelas dipandu oleh ceruk komputasi, di mana Anda perlu dengan cepat mengunyah sejumlah besar data secara paralel. Mereka tidak fokus pada kinerja super besar dari satu utas (pada saat yang sama, itu sangat bagus), yaitu, secara umum, untuk CPU ini menunjukkan kinerja tinggi dengan konsumsi biaya rendah.
Mengapa Arm, bukan Intel? Kami memiliki server Intel yang luar biasa, mengapa harus mencari yang lain?
Sulit dan mudah untuk menjawab pertanyaan ini. Pertama, tempat suci tidak boleh kosong. Kami melihat bahwa AMD juga mencoba membangun semacam Intel alternatif untuk aplikasi server. Dan tentu saja, akan selalu ada beberapa bagian pasar alternatif dari produsen alternatif.
Tidak ada yang mau hidup dengan satu perusahaan monopoli.
Komentar yang sangat benar. Semua konsumen prosesor, dan ini terutama penyedia Cloud, menginginkan peluang untuk alternatif. Sehingga Anda dapat memilih, membandingkan biaya dengan biaya dan untuk aplikasi spesifik pilih arsitektur yang lebih menguntungkan.
Dan bagaimana dengan biayanya? Berapa jauh lebih mahal daripada solusi Intel?
Ini pertanyaan yang sulit. Pertama, seperti kata Alexey, produsen sudah cukup. Jelas bahwa sekarang produsen Arm-prosesor tidak bersaing satu sama lain, tetapi bersaing dengan orang lain. Mereka menempati ceruk yang sedikit berbeda. Jika Cavium adalah komputasi kinerja tinggi, maka Qualcomm adalah server kelas menengah, Ampere adalah workstation atau server kelas bawah.
Jika saya ingat dengan benar, harga CPU itu sendiri dari Ampere Computing adalah $ 600-900, dan mereka bersaing dengan Intel, CPU yang harganya sekitar $ 1.500. Kavium agak mahal. Sekali lagi, mereka akan bersaing dengan Intel, yang jauh lebih mahal. Anda perlu memahami bahwa harga server tidak hanya harga CPU. Harga server juga memori, disk, dukungan, konsumsi. Jika Anda menang pada satu parameter, misalnya, biaya CPU - itu bagus, tetapi Anda hanya akan sedikit lebih murah. Jika Anda menang dengan dua cara, misalnya, lebih murah, menawarkan kinerja yang lebih baik, mereka akan melihat Anda lebih dekat. Dan jika dalam tiga, misalnya, Anda juga dapat melakukan semua ini dengan konsumsi daya yang lebih sedikit, maka ini sudah merupakan aplikasi untuk kemenangan.
Selain besi dan dukungannya, dukungan dalam perangkat lunak juga penting. Anda tidak dapat menggunakan Arm segala sesuatu yang sekarang Anda putar di Intel.
Tentu saja Saya harus mengatakan bahwa ekosistem perangkat lunak Arm telah melangkah jauh ke depan. Jika lima tahun lalu ada masalah untuk mengangkat sepotong besi, sekarang tidak ada masalah seperti itu. Anda baru saja datang dan semuanya bekerja di luar kotak untuk Anda. Semua yang Anda gunakan untuk bekerja - Linux, Docker, Kubernetes, Xen, Java, Hadoop, Spark, Kafka, apa pun.
Bagaimana dengan java? Beri tahu kami cara kerjanya, apa bedanya dengan yang "biasa"?
Tidak beda, inilah keunggulan utamanya. Itu cukup produktif untuk mengatasi tugas-tugas yang ditugaskan untuk Java untuk server. Anda mentransfer aplikasi Anda (saya harap itu tidak memiliki bagian asli, jika tidak Anda harus mengkompilasi ulang), ke server Arm, periksa kinerja dan, dalam banyak kasus, bersukacita. Baru-baru ini, sebuah artikel diterbitkan di mana kami membandingkan kinerja server Arm dengan server Intel . Artikel itu keluar di Java Magazine.
Apakah Oracle membiarkan Anda pada dasarnya beriklan di jurnal Anda sendiri? Serius.
Ternyata, ada permintaan. Ternyata Java Arm-server untuk Java-workloads bekerja dengan cukup baik. Mereka sama, atau bahkan lebih baik daripada rekan Intel.
Siapa yang harus membaca artikel Anda?
Bagi yang ingin melihat, coba arsitektur baru, apakah cocok untuk muatannya. Coba Java dan Arm-server yang sama. Dorong Arm Server Cloud ke Google, dan Anda mendapatkan beberapa penyedia cloud, Anda dapat memegang kartu dan mencoba apa yang Anda butuhkan.
Apakah Java sudah diinstal sebelumnya di sana?
Ya OpenJDK polos.
Apakah OpenJDK reguler dan distribusi Liberica Anda adalah hal yang sama? Saya melihat bahwa ada komitmen Anda - apakah itu atau sesuatu yang lain?
Secara umum, sejarah port Arm dan OpenJDK cukup menarik dan penuh hiasan. Awalnya, Oracle mengembangkan port Arm, dan ketika Arm merilis arsitektur ARMv8, port tambahan ditambahkan ke port Arm ini yang memungkinkan Java berjalan pada ARMv8. Sejalan dengan ini, Red Hat juga bekerja ke arah ini dan menuangkan port-nya di OpenJDK untuk arsitektur ini. Kebetulan komunitas itu berfokus pada pelabuhan Red Hat. Oleh karena itu, sekarang kami memiliki aksesori yang ada di OpenJDK untuk port ARM32, yang sebenarnya menduplikasi fungsi port aarch64 - kami akan menghapusnya dari sana di JDK 12. Dengan melakukan ini, kami memiliki JEP 340.
Saya harus mengatakan bahwa Oracle menuangkan OpenJDK semua pencapaiannya dari embedded, semua port Arm sebelum menghentikan dukungan. Sekarang semua fitur untuk Arm yang dibuat di Oracle dimasukkan.
Ini logis, karena itu adalah pabrikan dari besi dan pabrikan dari spesifikasi yang terutama harus tertarik agar ekosistem perangkat lunak dapat bekerja pada perangkat keras mereka dan kompatibel dengan spesifikasinya. Untuk ini, kode harus terbuka.
Saya melihat infografis yang menunjukkan angka-angka yang mengejutkan bahwa perusahaan tertentu BellSoft, yang berlokasi di St. Petersburg, membanjiri sejumlah besar komitmen.
Ya, kami berada di 5 komuter OpenJDK teratas. Tentu saja, Oracle keluar dari persaingan, ada sekitar 4 ribu komit per tahun.
Berikutnya adalah Red Hat, SAP, Google dan BellSoft. Kami tidak menjangkau Google sedikit pun. Dan tepat setelah kami adalah IBM.
Berapa persentase karyawan Anda yang pernah bekerja di Oracle?
100 persen. BellSoft terdiri dari mantan karyawan Oracle.
Ini adalah kompetisi yang tidak adil karena Google tidak terdiri dari 100 persen karyawan Oracle. Komitmen macam apa, beri tahu saya? Bagaimana cara mencapai kesuksesan seperti itu? Bagaimana masuk ke 5 commuter top?
Kami bekerja di beberapa arah. Sekarang arah utama kemana komit kita pergi adalah port ARM64, yang merupakan port server yang sama. Sangat menarik bagi produsen besi. Mereka tertarik pada Java dengan cepat mengerjakan perangkat keras mereka, mengatasi beban. Hal kedua yang kami komit adalah port ARM32, yang kami dukung, ini adalah port embedded. Yang ketiga adalah komitmen yang bertujuan mendukung, memperbaiki, dan meningkatkan fungsionalitas Java secara keseluruhan.
Kami baru saja berbicara tentang 64 bit di server. Mengapa port 32-bit masih hidup?
Karena digunakan dalam embedded.
Karena begitu banyak perusahaan telah menerapkan CPU untuk arsitektur ARMv7 untuk aplikasi tertanam. Mereka memiliki banyak chip di gudang mereka. Jika ingatanku benar, maka dari seluruh variasi chip ini adalah ARM32, yang paling populer adalah ARMv5. Arsitektur ini telah ada selama bertahun-tahun, tetapi bagaimanapun, CPU cukup murah, dan produsen masih mempertimbangkan untuk membuat perangkat baru pada arsitektur ini.
Berapa jumlah yang kita bicarakan ketika kita berbicara tentang membangun? Bisakah orang biasa membeli sesuatu untuk diri mereka sendiri dan bereksperimen?
Platform ARM32 yang paling populer adalah Raspberry Pi, mulai dari versi kedua - versi kedua dan ketiga, ditambah semua ini didukung oleh port ARM32. Salah satu distribusi kami adalah yang untuk ARM32 yang diuji dan dijalankan pada Raspberry Pi. Kami melihat bahwa ini adalah platform paling umum untuk khalayak luas, dan oleh karena itu kami merilis port khusus untuk Raspberry Pi. Kami memiliki port yang lebih spesifik untuk besi yang sangat khusus, tapi itu cerita lain.
Mungkin Anda tidak perlu membeli. Anda dapat melihat apa yang Anda miliki di router rumah Anda. Sangat mungkin ada sesuatu seperti itu.
Berapa banyak keterampilan pengembang harus sesuai di sana?
Anda harus menjadi pengembang Java.
Apakah Anda memerlukan cara yang rumit untuk mengetahui hukum Kirchhoff untuk membuat kode?
Anda hanya memiliki komputer yang dapat Anda hubungkan melalui SSH. Tidak perlu menginstalnya. Anda mengambil kartu microSD dengan gambar Linux untuk Raspberry Pi, masukkan, dan semuanya dimulai. Ini adalah keunggulan utama Raspberry Pi dibandingkan dengan semua komputer papan tunggal lainnya. Kesederhanaan konfigurasinya, mendapatkan sistem yang bisa diterapkan.
Dan bagaimana cara bekerja dengan sensor? Kami melakukan semua ini demi sistem eksternal, bukan?
Raspberry Pi memiliki sistem GPIO dan pin yang dapat digunakan untuk menghubungkan apa saja. Pada apa yang biasanya semua penggemar menghubungkan semua perangkat ke Raspberry Pi.
Seperti apa API itu? Apa yang perlu ditulis, seperti, "dapatkan saya nomor dari termostat"?
Anda perlu membaca lembar data termostat, dan memahami apa itu register, cara menginisialisasi, cara mengkonfigurasinya. Jika I2C, panggil metode untuk konfigurasi, berikan semua parameter di sana. Lalu katakan padanya i2c.open, dan bekerja dengannya sebagai objek Java.
Apakah mungkin untuk menulis pembungkus objek yang indah di sekitar termostat untuk bekerja dalam model objek murni? Bisakah itu dilakukan agar tidak membaca lembar data lagi, untuk menutupnya dengan fasad?
Akan lebih baik jika pembuat sensor ini membuat konfigurasi yang sudah jadi, dan kami, sebagai programmer Java, hanya mengambil dan menggunakannya. Perpustakaan bekerja dengan satu sensor, perpustakaan untuk bekerja dengan sensor lain. Perpustakaan seperti itu atau sesuatu yang dekat dengan ini disebut Pi4J. Ini berkembang sekarang tidak secepat di hari-hari ketika Oracle pindah Java tertanam, tetapi masih tidak mati, beberapa pembaruan muncul secara berkala. Ada pilihan: bekerja dengan sesuatu yang ada di OpenJDK - GPIO, atau bekerja dengan perpustakaan Pi4J.
Jika saya produsen perangkat keras, saya tidak tahu apa-apa tentang Java, tetapi saya ingin programmer Java menggunakannya, siapa yang harus saya hubungi? Untuk menghubungi Anda? Atau adakah spesialis yang melakukan ini?
Ya, kami adalah spesialis seperti itu.
Sejauh ini kita belum berlari jauh. Saya ingat bahwa Anda memiliki beberapa JEP Anda, bukan?
OpenJDK versi 11 mencakup 17 JEP. 14 dibuat oleh Oracle, 1 - Google, 1 - Red Hat, 1 - BellSoft bersamaan dengan Cavium. JEP kami adalah gado-gado peningkatan kinerja Java pada platform ARM64 untuk beban kerja tertentu. JEP, masing-masing, disebut Meningkatkan Aarch64 Intrinsics . Singkatnya, kami telah meningkatkan kinerja operasi dengan String, dengan array, dan sedikit dengan matematika dan trigonometri.
Apa itu intrinsik? Tidak semua orang tahu.
Ketika mesin virtual mempertimbangkan sinus, alih-alih mengeksekusi kode Java langsung, ia dapat menggantikan insert assembler yang dioptimalkan untuk arsitektur tertentu.
Yang langsung memanggil prosesor yang memiliki perintah sinus?
Yang akan menghitungnya sesuai dengan algoritma yang kompleks. Ada intrinsik yang memanggil semacam perintah assembler. Misalnya, intrinsik yang terkait dengan perhitungan checksum. Instruksi perakitan semacam itu ada untuk hampir semua arsitektur. Ada intrinsik yang lebih kompleks ketika, untuk mendapatkan peningkatan kinerja yang baik, tulis banyak halaman assembler.
Dan enkripsi, apakah itu di perangkat keras?
Ya, ini biasanya panggilan ke instruksi yang ada dari prosesor tertentu. Terkadang - bekerja dengan ekstensi pada chip tersebut di mana mereka berada.
Kembali ke JEP Anda: bagaimana menentukan kode mana yang sangat panas sehingga sangat layak untuk hardcode?
Pertanyaan yang bagus Ketika kami mulai mengoptimalkan sesuatu untuk platform ARM64, kami tidak memiliki banyak alat, selain perf. Ya, dan dia tidak bekerja di mana-mana. Tidak ada implementasi JFR untuk port ARM64, Oracle belum memasukkannya ke Open Source pada saat itu. Berbagai alat untuk mengukur kinerja yang biasa kami gunakan, misalnya, async-profiler, jujur-profiler - mereka juga tidak berfungsi untuk platform ARM64. Hal pertama yang kami lakukan adalah mendapatkan semua alat ini pada arsitektur ini.
Mengapa tidak bekerja di luar kotak?
Karena ada semacam bagian khusus CPU.
Selanjutnya, jalankan alat-alat ini pada beban kerja yang Anda coba optimalkan, lihat layar untuk waktu yang lama, coba pahami metode apa yang panas di sana, tempat apa yang panas di dalamnya. Ada beberapa kasus sederhana ketika beberapa assembler insert untuk arsitektur tertentu tidak diimplementasikan. Dalam kasus ini, fallback terjadi dalam kode Java. Hanya dengan menerapkan sisipan assembler ini Anda bisa mendapatkan peningkatan kinerja. Ada lebih banyak tempat rumit ketika Anda perlu memahami assembler baru apa yang Anda butuhkan di Jawa untuk membuat semua arsitektur. Pekerjaan seperti itu.
Set data Sam ke mana harus mendapatkan? Mengempiskan seluruh github dan menjalankannya di bawah JIT?
Jelas bahwa beberapa tolok ukur atau beban kerja sedang dioptimalkan. Tolok ukur terkenal - SpecJBB, SpecJVM. Ada beban kerja khusus yang menarik minat pelanggan tertentu. Jalankan saja beban kerja ini dan lihat kemacetan.
Semua SpecJVM ini adalah tes yang sangat lama, bukan? Bagaimana dengan lambda baru, aliran, kencan besar?
Tidak ada Itu tidak ada di sana.
Dan di mana mendapatkannya?
Beban kerja baru.
Misalnya, tumpukan apachevsky?
YaHadoop memiliki patokan TeraSort standar, yang ingin diukur oleh produsen perangkat keras. Juga salah satu tugas menarik untuk optimasi.
Apa saja fitur utama untuk dioptimalkan sekarang? Misalnya, bagian atas dari JEP yang sama.
Area masalah utama untuk arsitektur ini yang ada di sana, kami tutup. Di sana, tentu saja, masih ada bidang yang belum dibajak tentang apa yang belum kita lakukan dan apa yang akan terus kita lakukan. Kami akan terus bekerja dengan trigonometri, kami akan melihat intrinsik baru yang akan muncul. Mereka belum ada di sana, tetapi kami mengerti bahwa mereka akan segera muncul. Kita harus melihat proyek Panama, dimana Intel berkontribusi secara aktif.
Bagaimana kompiler akan melihat apa yang Anda lakukan? Secara relatif, secara ajaib mengerti bahwa Anda mempertimbangkan beberapa formula terkenal dan mengoptimalkan?
Math.sin , Java- sin .
- , sin ?
Ya , .
- , , ?
C2, .
- . , ?
.
, Linaro Connect OpenJDK ARM64. Linaro Foundation Arm-.
?
Arm, . .
?
. . Joker, .
!
, . floating point. , , , . — , . , , — . , .
. , , ?
Ya Arm … , — . , . - - , — . , , . , , . , Java- , .
, - , . ?
OpenJDK BellSoft.
, , ? ? Oracle, . JVM-?
, OpenJDK. ()
, 250 . ?
, 250 . .
— ? .
, . . , — . - .
, ?
.
?
. . , - , , . , , , . - . , . , , . , OpenJDK .
?
Mailing list. - mailing list, .
-?
Jira. OpenJDK Jira, , , .
Jira Jira, , ?
OpenJDK . , Jira.
? , , , , , Arm?
Arm, , , . shared-, , . , . .
, . , .
, . HotSpot, , , . , , - — .
- ?
Ya HotSpot tiers. smoke- . , , . , performance-, stress-.
. , , JDK, . JDK, . , ?
JDK, , JVM. JVM 4 : runtime, serviceability, garbage collector, compiler. - . , runtime. - out of order execution, , GC . , JIT, . community OpenJDK — JIT.
, , ?
, . , . . . , -, , .
? ? ? , , - ?
. , .
, , - , . .
. , OpenJDK Arm. , , IT. -, , Arm . , Arm, Arm , . , OpenJDK, Arm. , , . Arm Intel SPEC-. , . . !
, ?
, ?
, .
. . , ARM64? . , Arm .
.
— , , -, . ? - , Arm?
, .
?
Arm . . , , ? . .
, . , , , . - 10 , GPU - , . Cloud- . , , -. GPU, CPU. -, HTTP 404. , . , .
, - , ? - ?
. , . 30 ? . , . - , , . : 20% , 20%, — 10%, - . , Arm .
, Java, , . , , .
Arm , BellSoft — Arm, . OpenJDK, - . Liberica Liberica Arm 32 64, Liberica Linux (64 ), Windows Liberica Mac. Liberica Solaris Sparc. .
Liberica Mac? -.
? Oracle , … . ?
?
, Oracle. , Java- .
Java- .
, . , .
.
Ya -, support . - — , , Cloud-. , , - , .
, Oracle JDK , API. -XX:+UnlockCommercialFeatures . , . , Oracle , .
, Oracle - Oracle, . . Java , .
, , OpenJDK . . BellSoft , , .
, , . . , , OpenJDK — .
!
. , — . - ?
. , , , . .
- OpenJDK.
. ?
Liberica, . Raspberi Pi, Linux-. , Java, -.
Joker, , BellSoft — .
. , , . , :-) Joker — .
, . !
. Joker 2018 «, ARM? , » . .