Simulator Memori Java untuk Menghasilkan Memory Reference Trace

advertisement
Simulator Memori Java untuk Menghasilkan Memory Reference Trace
1
Yudi S. Gondokaryono, 1Bagus Prasetyo Wibowo & 1Andry Ongkinata
1
Sekolah Teknik Elektro dan Informatika – ITB
Contact Person:
Yudi S. Gondokaryono
Sekolah Teknik Elektro dan Informatika
Jalan Ganesha 10 Bandung
Phone: 22-2500985
[email protected]
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
Gambar 1 Pengukuran Kinerja Komputer
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.
e-Indonesia Initiative 2008 (eII2008)
Konferensi dan Temu Nasional Teknologi Informasi dan Komunikasi untuk Indonesia
21-23 Mei 2008, Jakarta
2.
STRUKTUR MEMORI JAVA
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.
menyimpan operand untuk operasi setiap instruksi. Kedalaman
dari setiap stack ditentukan pada saat kompilasi. Instruksi
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
Gambar 2 Alokasi Memori untuk Program Java [20]
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 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 subsub 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:
e-Indonesia Initiative 2008 (eII2008)
Konferensi dan Temu Nasional Teknologi Informasi dan Komunikasi untuk Indonesia
21-23 Mei 2008, Jakarta
Gambar 3 Proses Perekaman Referensi Memori dengan menggunakan
Simulator Memori Java
SIMULATOR MEMORI JAVA
•
Membaca sebuah instruksi Java bytecode
Instruksi Java bytecode memiliki panjang yang variable. Jika
Method Call
Saat ditemukan adanya pemanggilan suatu method,
Instruction
Execute
Push stack
Pop stack
PUSH
POP
Set Local
Variabel
(Offset,
DataIn)
Method
Call
Method return
Constant
Pool
Access
Terminate
Frame
Read Local
Variabel
Local
Variable
Access
Arithmetic
(+, -, *)
Control
(If, switch,
loop)
Create
Frame
END
Gambar 4 Jenis-jenis bytecode dan operasinya
Gambar 5 Simulator Memori Java
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.
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.
Push/Pop Stack
Control
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.
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.
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.
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:
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
•
•
Start tracing...
1 014E2D10
2 883DD0C0
0 014E2D10
1 FF428520
2 883DD0C1
2 883DD0E0
1 FF428548
2 883DD0E2
....
1 014E2D3C
2 883DD0EA
2 883DD0C4
Untuk kebutuhan riset yang berkaitan dengan programprogram 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.
2
2
0
0
0
1
88000004
88000004
d4000004
ff000003
ff000003
b3000090
1
2
0
2
3
1
i
i
c
s
s
o
Java.lang.String.<init>
Java.lang.String.<init>
Java.lang.String.<init>
Java.lang.String.<init>
Java.lang.String.<init>
Java.lang.String
Gambar 6 Contoh hasil rekaman dengan format DINERO yang dimodifikasi
Keterangan setiap kolom adalah sebagai berikut:
Kolom
1
5
Keterangan
Jenis memori akses (0-baca, 1-tulis, 2-mengambil
instruksi)
Alamat segmen memori dalam heksadesimal
Offset dari alamat segmen memori
dalamheksadesimal
Jenis objek
‘i’ – instruction
‘c’ – constant pool
‘v’ – local variable
‘s’ – operand stack
‘o’ – object instances
Nama Objek
5.
HASIL IMPLEMENTASI SIMULATOR MEMORI JAVA
2
3
4
Simulator Memori Java yang telah dibuah sudah dapat
mengeksekusi program Java. Gambar 7 menunjukkan kode
dalam bahasa Java yang dieksekusi oleh Simulator Memori
Java.
public class sample1
{
public static void main (String[] args)
{
int x, y, z;
}
x = 10;
y = 12;
z = x + y;
}
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.
0
0
0
0
1
0
0
2
v
i
v
s
i
i
s
i
bootstrap
bootstrap
bootstrap
bootstrap
bootstrap
java.lang.String.<init>
java.lang.String.<init>
java.lang.String.<init>
3 v java.lang.String.<init>
A i java.lang.String.<init>
4 i bootstrap
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.
[1]
REFERENCES
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,
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.
e-Indonesia Initiative 2008 (eII2008)
Konferensi dan Temu Nasional Teknologi Informasi dan Komunikasi untuk Indonesia
21-23 Mei 2008, Jakarta
Download