Quark Anatomi JVM

 (shipilev.net)
1 poin oleh GN⁺ 2024-11-12 | 1 komentar | Bagikan ke WhatsApp
  • Seri mini post progresif yang membahas pengetahuan internal JVM dalam unit kecil, dengan tiap tulisan berfokus pada satu topik, pengujian, benchmark, atau observasi
  • Setiap post ditujukan untuk selesai dibaca dalam 5–10 menit, dengan asumsi bahwa elemen-elemen JVM saling berinteraksi satu sama lain
  • Dasar dan pembahasannya bisa bersifat anekdotal, dan mungkin belum ditinjau cukup untuk kesalahan, konsistensi, gaya, tata bahasa, atau duplikasi, sehingga perlu hati-hati untuk langsung mempercayainya
  • Paket lengkap tersedia dalam ePUB, MOBI, PDF, dan PDF berukuran puluhan MB karena konversi berkualitas tinggi
  • Indeks tulisan individual dibagi ke dalam kategori Compiler, Runtime, GC, dan Library, mencakup topik internal JVM seperti optimisasi lock, TLAB, jeda GC, String.intern(), safepoint, compressed references, dan conditional moves

Prasyarat saat membaca seri ini

  • JVM Anatomy Quarks adalah seri mini post progresif yang merangkum pengetahuan dasar JVM dalam tulisan-tulisan singkat
  • Setiap post berbentuk pembahasan mendalam atas satu topik, pengujian, benchmark, atau observasi
  • Jika hanya melihat satu post secara terpisah, konteksnya bisa kurang, dan sebagian besar elemen yang dibahas mudah saling berinteraksi
  • Dasar dan pembahasannya bisa bersifat anekdotal, dan mungkin belum cukup ditinjau dari sisi kesalahan, konsistensi, gaya, tata bahasa, makna, maupun duplikasi
  • Saat menggunakan atau mempercayai isi tersebut, pembaca harus menanggung risikonya sendiri

Struktur paket dan indeks

  • Paket lengkap seri ini disediakan dalam tiga format
    • ePUB adalah yang paling kecil, kurang dari 1 MB, dan berbasis Pandoc HTML-to-ePUB
    • MOBI berukuran kecil, sekitar hitungan MB, dan berbasis KindleGen ePUB-to-MOBI
    • PDF sangat besar, mencapai puluhan MB, dan merupakan keluaran berkualitas tinggi berbasis wkhtmltopdf HTML-to-PDF
  • Indeks individual disusun dalam klasifikasi Compiler, Runtime, GC, Library

Daftar tulisan per topik

  • Entri berfokus pada Compiler

    • #1: Lock Coarsening and Loops
    • #14: Constant Variables
    • #15: Just-In-Time Constants
    • #16: Megamorphic Virtual Calls
    • #17: Trust Non-Static Final Fields
    • #18: Scalar Replacement
    • #19: Lock Elision
    • #20: FPU Spills
    • #25: Implicit Null Checks
    • #27: Compiler Blackholes
    • #28: Frequency-Based Code Layout
    • #29: Uncommon Traps
    • #30: Conditional Moves

  • Entri yang mencakup Runtime dan GC

    • Tulisan-tulisan yang membahas memori dan perilaku jeda saat JVM berjalan
    • #2: Transparent Huge Pages
    • #4: TLAB Allocation
    • #5: TLABs and Heap Parsability
    • #6: New Object Stages
    • #7: Object Initialization Costs
    • #9: JNI Critical and GC Locker
    • #22: Safepoint Polls

  • Entri berfokus pada GC

    • Berpusat pada desain collector dan perilaku heap
    • #3: GC Design and Pauses
    • #11: Moving GC and Locality
    • #13: Intergenerational Barriers
    • #21: Heap Uncommit

  • Entri berfokus pada Runtime

    • Tulisan-tulisan yang membahas lingkungan eksekusi JVM dan representasi objek
    • #12: Native Memory Tracking
    • #23: Compressed References
    • #24: Object Alignment
    • #26: Identity Hash Code

  • Entri Library atau klasifikasi gabungan

    • Entri yang juga mencakup Library, yaitu #10: String.intern()
    • Entri yang ditandai sekaligus sebagai Compiler dan Runtime adalah #16, #25, #29, #30

Bacaan terkait

1 komentar

 
GN⁺ 2024-11-12
Pendapat di Hacker News

  • https://shipilev.net/jvm/anatomy-quarks/17-trust-nonstatic-f... adalah contoh yang benar-benar disayangkan
    Karena sebagian framework menyalahgunakan JNI dan refleksi untuk mengubah field final yang semestinya immutable, kode pengguna kehilangan optimisasi penting yang hanya mungkin untuk class yang disediakan sistem
    Platform, khususnya compiler dan runtime, harus menegakkan batasan semantik dengan sangat ketat demi menjaga ruang optimisasi di masa depan

    • Sebagai bagian dari strategi integrity by default kami [1], kami sedang mengubah bagian ini, dan JEP terkait akan segera hadir
      Tidak banyak kode yang benar-benar perlu mengubah final, dan saat ini pun operasi itu dibatasi pada class di dalam modulnya sendiri atau class yang secara eksplisit di-open, jadi ke depannya modelnya adalah aplikasi harus memberi izin kepada modul yang ingin mengubah final
      Mirip dengan pendekatan yang baru-baru ini kami terapkan pada pemanggilan native dan akses memori yang tidak aman
      [1]: https://openjdk.org/jeps/8305968
    • Rasanya sebagian orang yang mengikuti Effective Java secara membabi buta mungkin telah menciptakan dosa asal berupa anjuran beri final pada segala hal
      Akibatnya sekarang class final tidak bisa dengan mudah di-mock dalam pengujian, dan tool mocking bahkan harus melakukan manipulasi bytecode untuk memock class final
      Misalnya, di internal Google, Effective Java adalah persyaratan sehingga API GDrive publik pun memiliki class final, padahal API eksternal justru merupakan sesuatu yang ingin kita mock
    • Kasus System.out adalah masalah Java itu sendiri
      https://docs.oracle.com/javase/specs/jls/se7/html/jls-17.htm...
      Dengan preseden seperti ini, tidak mengherankan jika orang lain menganggapnya sebagai cara yang dapat diterima
    • Modifier field adalah batasan semantik, bukan batasan keamanan
      Seharusnya memang bisa dilewati jika melalui prosedur bypass yang tepat
      Intinya adalah safety, karena mengubah sesuatu yang tidak bisa dimodifikasi dapat memicu SEGV, dan itulah kekhawatiran yang ingin ditangani oleh access modifier
    • Saya mengakui bahwa dulu saya pernah menulis sendiri tiga baris kode jahat untuk menghindari refactoring yang merepotkan di sebuah library internal yang sudah lama hilang: membuat member menjadi “un-final”, mengubahnya, lalu membuatnya seolah-olah final lagi
      Seandainya saja itu diblokir, tapi ada kebutuhan bisnis

  • Sedikit berbeda topik, Apple baru merilis bridge Swift Java dan itu cukup keren
    Mendukung JNI maupun Panama, dan minggu lalu saya sedang mem-porting-nya ke Android
    https://github.com/swiftlang/swift-java

    • Jika bisa disebut “modern”, pendekatan cross-platform belakangan ini menarik
      Interoperabilitas antarbahasa memungkinkan satu library dibagikan ke beberapa platform ketika memang cocok
      Selama ini hal itu dilakukan hanya dengan C++, ditambah C API jika perlu, tetapi ketika C++ sendiri tidak dibutuhkan, jelas itu bukan bahasa yang disukai
      Namun saya khawatir soal biayanya. Jika Swift bisa dengan mudah memanggil library Kotlin di aplikasi mobile, bukankah aplikasi iOS harus memuat sesuatu yang mirip JVM dalam bentuk tertentu? Sebaliknya, jika aplikasi Android memanggil Swift, sepertinya ia akan memuat runtime Swift
      Pada akhirnya ada overhead
      Saya khawatir suatu saat akan menjadi umum bagi developer untuk bergantung pada library Swift, lalu library itu bergantung pada library Kotlin yang menyalakan JVM, lalu kembali memanggil C++ melalui JNI
      Ini mirip dengan situasi pada package manager modern: meski dependensi langsung hanya sedikit, karena “terlalu mudah sehingga tidak dipikirkan”, sebuah program tiba-tiba memiliki lebih dari 100 dependensi transitif

  • Senang melihat kumpulan tulisan bagus ini dibagikan di sini. Saya belajar banyak tentang JVM dari seri ini
    Saya khususnya suka tulisan ini yang menjelaskan bahwa ungkapan yang sering disebut “alokasi stack” di Java itu keliru: https://shipilev.net/jvm/anatomy-quarks/18-scalar-replacemen...
    Yang sebenarnya dilakukan JVM adalah escape analysis + scalar replacement

  • Saya suka panjang tulisan-tulisan ini
    Enak karena bisa membaca satu tulisan sampai selesai dalam beberapa menit, lalu menjalankan benchmark secara lokal jika mau

  • Jika pernah bekerja beberapa tahun dengan bahasa berbasis JVM, kumpulan tulisan ini benar-benar menarik
    Saya masih ingat saat pertama kali membacanya beberapa tahun lalu

  • Ada yang tahu kenapa nama seri ini berubah dari ‘JVM Anatomy Park’?

    • Sepertinya namanya diubah ketika perilaku online Justin Rolland mulai terungkap

  • Saya jadi hampir melupakan Java
    Saya sama sekali tidak terpikir untuk memulai proyek baru dengan Java
    Kalau butuh pengembangan cepat dan fleksibilitas, saya mungkin memilih Python; kalau ingin menangani banyak konkurensi I/O dengan garbage collection, Go; kalau butuh bahasa yang dikompilasi dan seimbang serta bagus, Swift; kalau butuh bahasa kompilasi dengan performa dan keamanan, Rust
    Ini hanya selera pribadi, dan saya tahu Kotlin membuat Java lebih nyaman dipakai, tapi tetap saja rasanya begitu

    • Saya mungkin bukan satu-satunya, tetapi sepertinya ini situasi di mana Java memang tidak diperlukan
      Kekuatan utama Java adalah jumlah developer berpengalaman Java yang nyaris tak terbatas, pustaka yang sudah ada sangat luas dan banyak di antaranya berorientasi enterprise, mudah mengelola codebase yang sangat besar dengan banyak kontributor, serta VM standar yang dikembangkan selama puluhan tahun sangat kokoh dan cukup cepat, dan didukung di hampir semua platform
      Dominasinya tidak lagi sekuat awal 2000-an, bahkan di enterprise sekalipun, dan memang merupakan bahasa “blub” yang tipikal, tetapi jika memperkirakan skala enterprise dan perlu melakukan scaling dengan banyak developer lebih daripada performa murni, Java tetap pilihan yang cukup masuk akal
      Saya suka Rust, tetapi Java-lah yang memberi saya nafkah
    • Menambahkan jawaban lain, Java juga punya cukup banyak karakteristik yang dibutuhkan startup, jadi masuk akal juga dipakai untuk proyek baru
      Berkat framework modern dan bantuan AI, backend yang layak bisa dinaikkan dalam hitungan hari
      Jika Anda co-founder teknis tunggal, untuk cepat membuat MVP Anda cukup tahu Java atau Kotlin, ditambah stack frontend, dan pada kenyataannya Anda akan menghabiskan jauh lebih banyak waktu untuk pekerjaan di luar coding, sehingga perbedaan fitur bahasa menjadi kurang penting
      Jika masuk ke mobile native, Swift bisa menjadi bahasa kedua
      Selain itu, kemungkinan besar skalabilitas bukan masalah pertama untuk sementara waktu. Ekspansi tim akan datang lebih dulu, sementara bottleneck performa kemungkinan baru terlihat jauh kemudian
      Java cocok untuk tim besar
      Dari sudut pandang bisnis, jika menginginkan talent pool yang lebih besar, siklus delivery cepat, dan sesuatu yang bisa tetap menjadi stack inti dalam jangka panjang, Java atau Kotlin mungkin pilihan terbaik
      Jika ingin mempromosikan teknologi keren semacam benefit untuk menarik kelompok developer tertentu, atau punya kasus bisnis yang langka, Anda bisa memilih Go atau Rust
      Python populer di akademia dan bootcamp, tetapi sejujurnya saya kurang melihat nilai bisnisnya untuk backend serbaguna
    • Di atas JVM ada banyak bahasa yang sangat nyaman dipakai, seperti Clojure
      Saya tidak akan mengabaikan JVM secara keseluruhan. JVM adalah mahakarya rekayasa, dan belakangan ini berevolusi cepat. Lihat saja Loom, Panama, Leyden, dan sebagainya
    • Untuk memberi jawaban yang mudah memicu perdebatan pada komentar yang juga mudah memicu perdebatan: Java lebih baik daripada Go dalam segala hal, dan 90% dari hampir semua kasus yang Anda sebutkan bisa ditangani dengan Java
      Jadi untuk hampir semua hal, Java adalah pilihan yang cukup jelas bagus
    • Anda mungkin bukan satu-satunya, tetapi bukan berarti semua orang begitu
      Kotlin dengan Java 21+ adalah kombinasi pilihan utama saya, baik untuk layanan yang berfokus pada I/O maupun praktis layanan apa pun
      Sangat nyaman dipakai, dan berkat virtual thread, memungkinkan kode yang sesederhana dan seefisien Go, sambil tetap memanfaatkan salah satu ekosistem pustaka terbesar dan terbaik di dunia
      Saya tidak bermaksud merendahkan Go atau Python. Jika itu alat pilihan Anda, keduanya sepenuhnya oke
      Namun Java belum menjadi setidak relevan yang Anda kira