Sebuah decompiler Java baharu yang dipanggil garlic-decompiler telah muncul, ditulis sepenuhnya dalam C dan mendakwa peningkatan prestasi yang ketara berbanding alat tradisional berasaskan Java. Projek ini bertujuan untuk menukar bytecode Java yang telah dikompil kembali kepada kod sumber yang boleh dibaca, menyokong fail .class, arkib JAR, dan fail WAR.
Jenis Fail yang Disokong:
- Fail .class (bytecode Java)
- Fail .jar (arkib Java)
- Fail .war (arkib aplikasi web)
- Fail .dex (dirancang, pada masa ini tidak disokong)
Dakwaan Prestasi vs Pemeriksaan Realiti
Pembangun mendakwa garlic-decompiler berjalan kira-kira 10 kali lebih pantas daripada alternatif berasaskan Java sambil menggunakan sumber sistem yang lebih sedikit. Binary yang dikompil mempunyai saiz hanya 300KB, menjadikannya sangat ringan. Walau bagaimanapun, ujian awal oleh ahli komuniti mendedahkan beberapa masalah pertumbuhan yang tipikal bagi program C yang menangani struktur data yang kompleks.
Seorang pengguna melaporkan segmentation fault semasa memproses fail JAR dengan multiple threads diaktifkan, menonjolkan cabaran pengurusan memori dalam C apabila mengendalikan parsing bytecode Java. Pembangun bertindak balas dengan pantas, meminta fail bermasalah untuk membetulkan isu tersebut.
Tuntutan Prestasi:
- 10x lebih pantas daripada penyahkompil berasaskan Java
- Penggunaan sumber yang lebih rendah berbanding alternatif Java
- Sokongan pemprosesan berbilang benang (lalai: 4 benang)
Cabaran Pengurusan Memori Muncul
Perbincangan teknikal dalam komuniti telah memberi tumpuan kepada pendekatan pengurusan memori projek ini. Decompiler menggunakan perpustakaan string tersuai dan melaksanakan kumpulan memori berasingan untuk operasi multi-threaded, dengan kumpulan global untuk mod single-threaded.
Walau bagaimanapun, pembangun berpengalaman telah mengenal pasti isu berpotensi di mana kod mencampurkan string statik dengan string yang diperuntukkan heap secara tidak konsisten. Ini mewujudkan situasi di mana fungsi pemanggil tidak dapat menentukan dengan betul sama ada memori yang dikembalikan perlu dibebaskan, berpotensi membawa kepada kebocoran memori atau kerosakan.
Pendekatan Pembangunan dan Rancangan Masa Depan
Projek ini mewakili usaha yang sebahagian besarnya manual, dengan pembangun menyatakan ia adalah 90% secara manual, 10% AI - nisbah yang dilihat oleh ramai dalam komuniti sebagai ideal untuk projek berfokuskan pembelajaran. Motivasi nampaknya adalah pendidikan dan praktikal, bertujuan untuk memahami dalaman JVM sambil mencipta alat yang lebih pantas.
Saya sedang menulis bahagian decompiling dex dan apk. Kelajuan semasa adalah kira-kira 10 kali lebih pantas daripada Java, dan ia menggunakan sumber yang lebih sedikit daripada Java.
Pembangunan masa depan termasuk sokongan yang dirancang untuk fail Android DEX, walaupun ciri ini masih belum dilaksanakan. Projek ini juga termasuk mod seperti javap untuk analisis bytecode yang lebih pantas, dengan atribut LineNumber dan StackMapTable dilumpuhkan untuk prestasi yang lebih baik.
Keperluan Pembinaan:
- cmake >= 3.26
- Tiada kebergantungan lain
- Saiz binari yang dikompil: ~300KB
Kesimpulan
Walaupun garlic-decompiler menunjukkan potensi dengan dakwaan kelajuan dan reka bentuk ringannya, ia menghadapi cabaran tipikal program C yang mengendalikan tugas parsing yang kompleks. Respons aktif pembangun terhadap laporan pepijat dan sifat pendidikan projek ini menunjukkan ia boleh matang menjadi alternatif yang berdaya maju kepada decompiler Java sedia ada, dengan syarat isu pengurusan memori diselesaikan. Buat masa ini, pengguna harus menjangkakan beberapa kekasaran yang tipikal bagi projek C peringkat awal yang menangani analisis bytecode yang rumit.
Rujukan: garlic-decompiler