e-Indonesia Initiative 2008 (eII2008) Konferensi dan Temu Nasional Teknologi Informasi dan Komunikasi untuk Indonesia 21-23 Mei 2008, Jakarta

Abstrak—Pengukuran kinerja komputer adalah salah satu masalah besar dalam riset teknologi komputer. Salah satu teknik pengukuran adalah dengan menggunakan pemodelan. Untuk meningkatkan akurasi pemodelan, diperlukan masukan yang direkam dari kondisi nyata. Rekaman yang biasa dipergunakan adalah rekaman referensi memori (memory reference trace) dari suatu program yang sedang berjalan. Proses untuk menghasilkan referensi trace tidaklah mudah. Salah satu cara yang dipergunakan oleh penulis adalah membuat simulator memori Java. Java dipilih karena informasi tentang bagaimana alokasi memori program Java terdokumentasi dengan baik. Dalam makalah ini penulis akan menampilkan hasil rekaman dari simulasi program sederhana dengan menggunakan suatu format rekaman yang dimodifikasi dari format DINERO [8]. Penggunaan format baru ini dipergunakan untuk mengakomodasi informasi tentang obyek-obyek yang diakses oleh program Java.

Keywords—Arsitektur Komputer, Java, Memory Reference Trace, Pengukuran Kinerja, Simulator

1. PENDAHULUAN

Pengukuran kinerja komputer adalah salah satu masalah besar dalam riset teknologi komputer. Pemodelan komputer menjadi salah satu metoda yang sangat penting dalam pengukuran kinerja. Pengukuran kinerja komputer dapat digambarkan seperti pada Gambar 1. Pemodelan yang berdasarkan model-model statistik kadangkala masih belum cukup akurat. Salah satu cara meningkatkan akurasi pemodelan adalah dengan menggunakan masukan yang direkam dari kondisi nyata. Rekaman yang biasa dipergunakan adalah rekaman referensi memori (memory reference trace) dari suatu program yang sedang berjalan [7][10][19].

Pada kenyataannya merekam referensi memori untuk suatu program yang sedang berjalan tidaklah mudah. Teknik yang biasa dipergunakan adalah dengan menggunakan hardware yang dirancang khusus untuk merekam semua referensi memori yang dikeluarkan prosesor. Metoda ini sangatlah mahal dan juga sangat sulit. Salah satu metoda lain adalah dengan memodifikasi sistem operasi agar dapat merekam semua referensi memori untuk program yang sedang berjalan. Tentunya metoda ini membutuhkan pengetahuan yang sangat detil tentang sistem operasi yang digunakan. Karena kebanyakan sistem operasi dibuat perusahaan komersil, kita tidak mungkin memodifikasi

sistem operasi tersebut. Walaupun kita bisa mendapatkan source program dari suatu sistem operasi, modifikasi sistem operasi tidaklah mudah. Maka karena faktor-faktor inilah, rekaman memori referensi tidak banyak tersedia untuk kebutuhan riset.

Java adalah bahasa pemrograman sangat populer dipergunakan untuk membuat aplikasi internet dan cell-phones. Informasi tentang cara kerja Java Virtual Machine sudah terdokumentasi dengan baik [20]. Sehingga kita dapat dengan mudah mengetahui cara kerja dari bahasa assembly Java yang disebut sebagai Java bytecode. Pengertian tentang Java bytecode sangat esensial untuk mengetahui akses memori yang terjadi pada saat Java bytecode dieksekusi. Dengan alasan ini maka penulis membuat simulator memori Java yang dapat menghasilkan memory reference trace. Dengan menggunakan Java sebagai wahana perekaman, proses perekaman bisa menjadi lebih murah dan mudah.

Hasil kompilasi Java program adalah Java bytecode. Simulator Memori Java menerima masukan Java bytecode dan akan mensimulasikan eksekusi program Java tersebut dan pada saat yang sama akan merekam referensi-referensi memori yang dihasilkan oleh program tersebut. Proses ini terlihat pada Gambar 2.

Rekaman referensi memori akan disimpan dalam file dengan format DINERO. DINERO adalah format file standar untuk merekam referensi memori. DINERO merekam referensi memori baik untuk data dan instruksi. Dalam penelitian ini, modifikasi format DINERO dilakukan untuk juga merekam nama objek dan juga jenis objek.

Dalam makalah ini penulis akan menyampaikan penjelasan mengenai struktur memori Java, Simulator Memori Java yang dibuat, dan format hasil rekaman memory reference trace yang sudah dimodifikasi.

2. STRUKTUR MEMORI JAVA

Simulator Memori Java untuk Menghasilkan Memory Reference Trace

1Yudi S. Gondokaryono, 1Bagus Prasetyo Wibowo & 1Andry Ongkinata

1Sekolah Teknik Elektro dan Informatika – ITB Contact Person:

Yudi S. Gondokaryono Sekolah Teknik Elektro dan Informatika

Jalan Ganesha 10 Bandung Phone: 22-2500985

ygondokaryono@stei.itb.ac.id

Gambar 1 Pengukuran Kinerja Komputer

e-Indonesia Initiative 2008 (eII2008) Konferensi dan Temu Nasional Teknologi Informasi dan Komunikasi untuk Indonesia 21-23 Mei 2008, Jakarta

Setiap program Java yang dijalankan oleh Java Virtual Machine (JVM) akan memiliki alokasi memori yang dibagi menjadi dua bagian. Bagian pertama disebut sebagai JVM stack yang dialokasikan untuk setiap thread. Bagian kedua adalah heap area yang dialokasikan untuk semua thread. Alokasi memori tersebut dapat dilihat pada Gambar 3.

Heap area dialokasikan pada saat JVM pertama kali dijalankan. Heap area dipergunakan untuk menyimpan instance dari class dan array. Heap area dipergunakan bersama oleh semua thread. Penyimpanan objek dalam heap area diatur oleh automatic management system (garbage collector) dari JVM.

Method Area Method area dipergunakan untuk menyimpan semua bagian

instruksi dari program. Bagian ini dapat dianalogikan sebagai text segment dalam Unix proses. Bagian ini juga menyimpan juga semua class termasuk di dalamnya konstanta, field, dan method [20].

Runtime Constant Pool Constant Pool berisikan data yang dipergunakan setiap

class. Bagian ini dapat dianalogikan sebagai symbol table seperti biasanya terdapat dalam bahasa pemrograman lainnya [20].

Java Stack adalah tempat penyimpanan untuk setiap thread. Bagian memori stack dialokasikan pada saat thread dijalankan. JVM stack dapat dianalogikan seperti stack pada bahasa pemrograman konvensional seperti C. JVM stack berisikan local variable, hasil sementara, dan dipergunakan pada saat invokasi method dan pada saat kembali dari method.

Dalam JVM stack terdapat bagian memori yang dialokasikan setiap saat suatu method dijalankan. Bagian memori ini disebut sebagai frame. Frame akan didealokasi setelah method selesai dijalankan. Setiap method hanya akan memiliki sebuah frame. Frame berisikan local variable, operand stack, dan referensi untuk constant pool dan class method.

Local Variables

Setiap frame berisikan berbagai local variable. Panjang dari local variable ditentukan pada saat kompilasi. Jenis dari local variable dapat berupa boolean, byte, char, short, int, float, reference, atau return Address. Sepasang local variable dapat menyimpan jenis long atau double. Pengalamatan local variable menggunakan index addessing, Jadi local variable yang pertama memiliki index nol [20].

Operand Stacks Setiap frame berisikan stack yang dipergunakan untuk

menyimpan operand untuk operasi setiap instruksi. Kedalaman dari setiap stack ditentukan pada saat kompilasi. Instruksi

JVM (bytecode) bisa melakukan proses load konstanta dan data dari local variable ke operand stack. Instruksi lainnya dapat mengambil operand dari operand stack, melakukan operasi dengan data tersebut, dan menyimpan kembali hasilnya ke dalam operand stack. Operand stack juga dapat dipergunakan untuk parameter passing pada saat invokasi method [20].

3. SIMULATOR MEMORI JAVA

Simulator Memori Java dibuat untuk mensimulasikan memori akses yang terjadi pada saat suatu program Java sedang berjalan. Setiap ada akses memori baik untuk operasi baca ataupun tulis akan direkam dalam trace file. Secara garis besar, program ini akan membaca sebuah program Java yang sudah dikompilasi dengan file extension .class. Setiap instruksi dibaca dari file .class berbentuk Java bytecode. Setiap Java bytecode akan dieksekusi seolah-olah dijalankan pada JVM. Gambar 4 menggambarkan cara kerja program.

Saat program dijalankan, simulator akan membaca program dari file .class. Pembacaan ini dimulai dengan mengelompokkan bagian dalam file .class. Bagian tersebut dapat berupa constant pool, interface, method, serta attribute. Setiap bagian tersebut dapat berupa array dengan ukuran yang tidak konstan. Simulator kemudian mengalokasikan memori untuk menampung bagian-bagian tersebut. Proses ini diulang kembali hingga bagian-bagian dalam file .class selesai dikelompokkan semua.

Untuk dapat mengakses data-data bagian yang telah dikelompokkan tadi, dibuat name and index relation tables. Tabel ini dibuat untuk memudahkan dalam proses mengakses constant pool, interface, method, attribute, serta mengakses sub-sub bagiannya (misal instruksi dari method). Dengan tabel ini juga dapat dengan mudah memperoleh informasi yang berhubungan dengan pengalokasian memori lainnya, seperti ukuran stack serta ukuran variable lokal.

Setelah proses ini selesai, simulator akan menjalankan tiga langkah sebagai berikut:

Gambar 2 Alokasi Memori untuk Program Java [20]

Gambar 3 Proses Perekaman Referensi Memori dengan menggunakan

Simulator Memori Java

e-Indonesia Initiative 2008 (eII2008) Konferensi dan Temu Nasional Teknologi Informasi dan Komunikasi untuk Indonesia 21-23 Mei 2008, Jakarta

• Membaca sebuah instruksi Java bytecode Instruksi Java bytecode memiliki panjang yang variable. Jika

diketahui bahwa instruksi yang akan dijalankan memiliki lebih dari satu byte, maka simulator akan membaca byte-byte selanjutnya sebagai informasi penunjang dalam menjalankan instruksi. Dalam setiap akses memori untuk memperoleh instruksi Java bytecode, diambil juga informasi mengenai memori tersebut untuk kemudian direkam sebagai referensi memori.

• Menjalankan instruksi tersebut Instruksi yang diperoleh dalam langkah sebelumnya

kemudian dijalankan secara native. Dengan demikian, simulator mengikuti jalannya program Java yang disimulasikan.

• Mensimulasikan akses memori yang dilakukan oleh

instruksi tersebut Saat eksekusi instruksi membutuhkan akses memori,

simulator mengakses memori secara native. Informasi tentang memori yang diakses, baik untuk membaca maupun untuk menulis, kemudian direkam sebagai referensi memori.

Jumlah Java bytecode yang harus disimulasikan cukup banyak. Java bytecode dapat kita kategorikan ke dalam beberapa jenis sesuai dengan operasi yang dilakukan. Sebagai gambaran, jenis-jenis bytecode dapat dilihat pada Gambar 5.

Push/Pop Stack

Instruksi push atau pop stack diproses secara native. Proses push dan pop dilakukan pada memori yang telah dialokasikan sebagai frame. Setiap proses akses memori ini, informasi mengenai akses memori tersebut direkam sebagai memori referensi.

Write/Read Local Variable Instruksi baca atau tulis variable lokal akan mengakses

bagian variable lokal dalam frame. Setiap akses memori, informasi mengenai akses memori tersebut juga direkam sebagai memori referensi.

Method Call Saat ditemukan adanya pemanggilan suatu method,

dilakukan pembacaan data dari Constant Pool untuk memperoleh informasi yang berhubungan dengan method. Informasi ini biasanya berupa indeks dari method pada .class file, jumlah argumen dalam method, jumlah variable lokal yang dibutuhkan, serta jumlah stack yang dibutuhkan. Setelah informasi tersebut didapatkan, dibuat sebuah frame baru sebagai frame untuk method yang dipanggil. Setiap informasi akses memori yang dilakukan dalam proses ini direkam sebagai referensi memori.

Method Return Saat suatu method berakhir, frame yang berasosiasi

dengan method tersebut dihapus dari memori. Untuk selanjutnya, instruksi yang akan diambil adalah instruksi yang terdapat dalam return address. Setiap informasi akses memori yang dilakukan dalam proses ini direkam sebagai referensi memori.

Arithmetic Instruksi aritmatika akan mengambil data dari stack frame

untuk kemudian diproses. Hasil dari proses tersebut kemudian disimpan kembali dalam stack frame. Dengan demikian, instruksi aritmatika berhubungan dengan instruksi push/pop stack.

Control Instruksi Control akan mengatur arah pengambilan

instruksi selanjutnya. Jika dibutuhkan, instruksi ini akan mengakses memori untuk melakukan perbandingan yang kemudian digunakan sebagai acuan pengambilan keputusan arah. Setiap informasi akses memori yang dilakukan dalam proses ini kemudian direkam sebagai referensi memori.

4. FORMAT REKAMAN REFERENSI MEMORI

Rekaman referensi memori biasanya menggunakan format DINERO[8]. Rekaman memori dengan format DINERO merekam tiga jenis informasi. Ketiga informasi tersebut adalah:

Instruction Execute

Push stack Pop stack

Set Local Variabel(Offset, DataIn)

Read Local Variabel

Method Call Method return Arithmetic

(+, -, *)Control

(If, switch, loop)

POPPUSHLocal

Variable Access

Create Frame

Constant Pool

Access

Terminate Frame

END

Gambar 4 Jenis-jenis bytecode dan operasinya

Gambar 5 Simulator Memori Java

e-Indonesia Initiative 2008 (eII2008) Konferensi dan Temu Nasional Teknologi Informasi dan Komunikasi untuk Indonesia 21-23 Mei 2008, Jakarta

• Jenis memori akses yang dikodekan dalam tiga angka yaitu 0- baca, 1- tulis, 2- mengambil instruksi

• Alamat segmen memori yang diakses • Offset dari segmen memori yang diakses

Untuk kebutuhan riset yang berkaitan dengan program-program berorientasi objek, dibutuhkan juga informasi mengenai nama objek yang sedang diakses dan juga jenis dari setiap objek tersebut. Modifikasi format DINERO dilakukan dengan menambahkan dua informasi di atas. Sehingga hasil rekaman referensi memori dengan format yang dimodifikasi terlihat dalam Gambar 6.

Gambar 6 Contoh hasil rekaman dengan format DINERO yang dimodifikasi

Keterangan setiap kolom adalah sebagai berikut: Kolom Keterangan 1 Jenis memori akses (0-baca, 1-tulis, 2-mengambil

instruksi) 2 Alamat segmen memori dalam heksadesimal 3 Offset dari alamat segmen memori

dalamheksadesimal 4 Jenis objek

‘i’ – instruction ‘c’ – constant pool ‘v’ – local variable ‘s’ – operand stack ‘o’ – object instances

5 Nama Objek

5. HASIL IMPLEMENTASI SIMULATOR MEMORI JAVA

Simulator Memori Java yang telah dibuah sudah dapat mengeksekusi program Java. Gambar 7 menunjukkan kode dalam bahasa Java yang dieksekusi oleh Simulator Memori Java.

Gambar 7 Program Java yang digunakan sebagai input Java Memori Simulator

Setelah program Java tersebut dikompilas, hasil kompilasi dari program tersebut digunakan sebagai input dari program Simulator Memori Java. Simulator kemudian menampilkan referensi-referensi memori apa saja yang diakses pada saat program Java tersebut dijalankan. Untuk program Java pada Gambar 7, keluaran dari program simulator yang dibuat dapat dilihat pada Gambar 8.

Gambar 8 Output program Java Memori Simulator

6. KESIMPULAN

Penulis telah berhasil untuk membuat sebuah program yang mensimulasikan akses memori untuk suatu program Java. Dengan mengetahui setiap akses memori maka dengan mudah kita dapat membuat suatu memory reference trace file yang merupakan tujuan utama dari penelitian ini. Simulator Memori Java ini dijadikan sebagai sebuah alat bantu para peneliti yang membutuhkan trace file.

7. ACKNOWLEDGEMENT

Penelitian ini dibiayai oleh Riset ITB berdasarkan Surat Perjanjian Pelaksanaan Penelitian No: 147/K01.16/PL/2007, tanggal 10 Januari 2007.

8. REFERENCES

[1] B. Cmelik and D. Shade Keppel, “A fast instruction-set simulator for executing profilling,” Proceedings of the 1994 SIGMETRICS Conference on Measurement and Modeling of Computer Systems, Nashville, TN, ACM, pp. 127-137, 1994.

[2] Vinodh Cuppu, Bruce Jacob, Brian Davis and Trevor Mudge, “A Performance Comparison of Contemporary DRAM Architectures,” Proceeding of 26th International Symposium Computer Architecture, June 1999.

[3] A. Eustace, and A. Srivastava, “ATOM: a flexible interface for building high performance program analysis tools,” Proceedings of the USENIX Winter 1995 Technical Conference on UNIX and Advanced Computing Systems, New Orleans, Louisiana, pp. 303-314, January, 1995.

[4] C. Fuentes, Hardware support for operating systems. University of Michigan Technical Report, 1993.

[5] J. Gee, M. Hill, D. Pnevmatikatos, and A. J. Smith, “Cache Performance of the SPEC92 Benchmark Suite,” IEEE Micro, August, pp. 17-27, 1993.

[6] Yudi Gondokaryono, “Capability-based Memory Management Unit”, New Mexico State University Ph. D Distertation, December, 2003.

[7] J. L. Hennesy and D. A. Patterson, Computer Architecture: A Quantitive Approach, Morgan Kaufmann, Palo Alto, CA, third edition, 2002.

[8] M. D. Hill, dineroIII documentation, unpublished, Unix-style Man Page, University of California, Berkeley, October 1985.

[9] M. Holliday, “Techniques for cache and memory simulation using address reference traces,” International Journal in Computer Simulation, 1, pp, 129-151, 1991.

[10] Raj Jain, The Art of Computer System Performance Analysis, John Wiley & Sons, New York, 1991.

[11] Eric E. Johnson, “PDATS II: Improved compression of address traces” IEEE International Performance, Computing, and Communications Conference, February 1999.

[12] A. Lebeck, and D. Wood, “Active Memory: A new abstraction for memory-system simulation,” Proceedings of the 1995 SIGMETRICS Conference on the Measurement and Modeling of Computer Systems,

Start tracing... 1 014E2D10 0 v bootstrap 2 883DD0C0 0 i bootstrap 0 014E2D10 0 v bootstrap 1 FF428520 0 s bootstrap 2 883DD0C1 1 i bootstrap 2 883DD0E0 0 i java.lang.String.<init> 1 FF428548 0 s java.lang.String.<init> 2 883DD0E2 2 i java.lang.String.<init> .... 1 014E2D3C 3 v java.lang.String.<init> 2 883DD0EA A i java.lang.String.<init> 2 883DD0C4 4 i bootstrap

public class sample1 { public static void main (String[] args) { int x, y, z; x = 10; y = 12; z = x + y; } }

2 88000004 1 i Java.lang.String.<init> 2 88000004 2 i Java.lang.String.<init> 0 d4000004 0 c Java.lang.String.<init> 0 ff000003 2 s Java.lang.String.<init> 0 ff000003 3 s Java.lang.String.<init> 1 b3000090 1 o Java.lang.String

e-Indonesia Initiative 2008 (eII2008) Konferensi dan Temu Nasional Teknologi Informasi dan Komunikasi untuk Indonesia 21-23 Mei 2008, Jakarta

May, pp. 220-230, 1995. [13] A. M. Maynard, C. Donnelly, and B. Olszewski, “Contrasting

characteristics and cache performance of technical and multi-user commercial workloads,” Proceesings of the Sixth International Conference on Architectural Support for Programming Languages and Operating Systems, San Jose, CA, ACM, pp. 145-156, 1994.

[14] D. Nagle, R. Uhlig, and T. Mudge, Monster: A tool for analyzing the interaction between operating systems and computer architectures, University of Michigan Technical Report CSE-TR-147-92, 1992.

[15] New Mexico State University, “NMSU Tracebase”, http://tracebase.nmsu.edu/tracebase.html.

[16] A. D. Samples, “Mache: No-Loss Trace Compaction,” Proceedings of ACM SIGMETRICS, pp. 89-97, 1989.

[17] A. J. Smith, “Cache memories”, Computing Surveys, 14(3), pp. 473-530, 1982.

[18] Standard Performance Evaluation Corporation, “SPEC 92 Benchmarks,” http://www.spec.org/osg/cpu92/.

[19] R. A. Uhlig and T. N. Mudge, “Trace-Driven Memory Simulation: A Survey,” ACM Computing Surveys, 29(2), pp. 128-170, June 1997.

[20] Frank Yelin and Tim Lindholm, The JavaTM Virtual Machine Specification, Second Edition, Addison Wesley, 1999.