4th International Conference on Principles and Practices ... - MADOC

More documents

Recommendations

Info

Heap protection for Java virtual machines Yuji Chiba Systems Development Laboratory, Hitachi, Ltd. 1099 Ozenji, Asao, Kawasaki, Kanagawa, Japan yuji@sdl.hitachi.co.jp ABSTRACT Java virtual machine (JVM) crashes are often due to an invalid memory reference to the JVM heap. Before the bug that caused the invalid reference can be fixed, its location must be identified. It can be in either the JVM implementation or the native library written in C language invoked from Java applications. To help system engineers identify the location, we implemented a feature using page protection that prevents threads executing native methods from referring to the JVM heap. This feature protects the JVM heap during native method execution, and when native method execution refers to the JVM heap invalidly, it interrupts the execution by generating a page-fault exception and then reports the location where the page-fault exception was generated. This helps the system engineer to identify the location of the bug in the native library. The runtime overhead for using this feature averaged 4.4% based on an estimation using the SPECjvm98, SPECjbb2000, and JFCMark benchmark suites. Categories and Subject Descriptors D.3.4 [Programming Languages]: Processors—memory management General Terms Reliability, Languages 1. INTRODUCTION Servers are being equipped with more and more memory, and some server applications, such as application servers, now use several gigabytes of memory for the heap. Therefore, if a server application is executed on a 32-bit operating system (OS) that provides a 4-Gigabyte (GByte) logical address space for its processes, the server application commits tens of percent of its logical address space as its heap. This reduces the use of page protection, which has long been used Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. To copy otherwise, to republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee. PPPJ 2006, August 30 – September 1, 2006 Mannheim, Germany Copyright 2006 ACM ... ...$5.00. to detect invalid memory references, because most of the logical address space is committed as heap and is thus valid for reference. Developers of Java TM1 runtime environments (JREs) often face this problem because server applications running on them sometimes crash due to corrupted heap. If the engineer trying to debug the problem does find that the heap is corrupted, he or she will likely ask the JRE developer to perform the debugging, simply because the heap has been allocated by the JRE. The engineer will not suspect that the bug is in a server application if the application is implemented in Java, because Java does not permit invalid memory references. While the bug may be in native libraries used by the server applications, the engineer may not ask a native library developer to perform the debugging because it is often not easy for an engineer to tell which native library contains the bug. This is because JRE may crash long after the bug corrupted the heap, so all that the engineer can tell from the core file of the crashed JRE process is that the heap is corrupted and that it had been allocated by the JRE. To cope with this problem, we implemented a JRE that uses page protection to protect its heap from invalid references due to bugs in the native libraries. The JRE protects its heap during native method execution, and when the native method execution refers to the heap invalidly 2 ,itinterrupts the execution by generating a page-fault exception and then reports the location where the page-fault exception was generated. This helps the engineer to identify which native library contains the bug. This heap protection feature permits a thread to write to the heap only when the thread is executing a Java method. When the thread calls a native method through the Java Native Interface[21] (JNI), it is not granted permission to write to the heap because our JNI implementation deprives the thread of this permission. This protection feature controls permission to write to the heap by thread, while mainstream operating systems such as Windows R○3 and Linux R○4 control 1 Java and HotSpot are trademarks of Sun Microsystems, Inc. in the United States and other countries. 2 Basically, native methods should refer to the JRE heap via the Java Native Interface (JNI). Any direct reference is invalid if the JNI implementation does not permit native methods to refer directly to the body of a Java array, as that of HotSpot VM (jdk1.5.0 06) doesnot. 3 Windows is a registered trademark of Microsoft Corporation in the United States and other countries. 4 Linux is a trademark or a registered trademark of Linus Torvalds in the United States and other countries. 103
permission by process. In other words, they provide only one protection domain 5 to each process, not to each thread. Thus the protection domain supported by these operating systems is not appropriate for implementing our heap protection feature. We thus modified Linux and implemented a per-thread protection domain for heap. We call it the ’heap protection domain’. It is used as follows. 1. If a program component (a set of procedures) uses its local heap, that is accessed only by the program component if there is no bug, the program component asks the OS to create a heap protection domain for the program component. This is usually done during the program component initialization, before the allocation of the local heap. 2. The program component then allocates the local heap, and asks the OS to give its heap protection domain permission to reference the heap. • A heap protection domain is a property of a process. Every thread in a process belongs to one of the process’ heap protection domains. The OS permits a thread to reference memory based on the heap protection domain to which it belongs. 3. At every entry to the program component, the developer of the program component adds code asking the OS to modify the heap protection domain, so that a thread that executes the code acquires permission to refer to the heap for the program component. The code asks the OS to let the thread belong to the protection domain for the program component. The entries to the program component reside in the prologs to the public procedures of the program component and after the external procedure calls. 4. At every exit from the program component, the developer of the program component adds code asking the OS to modify the heap protection domain, so that the thread that executed the code gives up the permission to refer to the heap for the program component. The exits from the program component reside in the epilogs of the public procedures of the program component and before the external procedure calls. Our JVM product supports a wide range of platforms (processors and operating systems), thus we want to protect the JVM heap on as many platforms as possible. Since we implemented our approach on IA32/Linux platform in April 2006, we have encountered one case of a JVM crash that we could have easily debugged using our work, but we couldn’t, because the crash happened on the IA64/Linux platform. In order to prevent such crashes, operating systems have to support the heap protection domain, and this limits the practicality of our work. However, since our heap protection domain implementation requires only a conventional page protection feature provided by most processors, it can be implemented on most operating systems. We hope 5 A protection domain is a row of an access matrix. Every subject belongs to one of protection domains at a time, and operating systems permits a subject to access each of their resource based on the protection domain to which the subject belongs. operating systems provide a feature like our heap protection domain in the future. Using the heap protection domain, we implemented this heap protection feature on a JVM and estimated the runtime overhead. The result of this evaluation, i.e. whether the heap protection feature is practical or not, is the main contribution of this paper. To ensure that the results are reliable, we implemented the heap protection feature on a practical JVM and OS (HotSpot TM virtual machine[24] (HotSpot VM) and Linux) and evaluated the runtime overhead using three benchmark suites (SPECjvm98[27], SPECjbb2000[28], and JFCMark TM6 [11]) consisting of practical Java applications. To the best of our knowledge, such evaluation data has not been previously presented. This paper is organized as follows. In section 2 we explore previous related work. In section 3 we describe our implementation of the heap protection domain, and in section 4 we describe our implementation of the heap protection feature. In section 5 we discuss the implementation of setpd(), which is a system call to modify the protection domain to which a thread belongs (and generates most of the runtime overhead related to using the heap protection feature), and in section 6 we evaluate the runtime overhead. In section 7 we summarize the key points. 2. RELATED WORK Invalid memory references have plagued program developers since the dawn of computing, and many attempts have been made to eliminate them, mainly by people working in four fields: programming languages, virtual machines, hardware and operating systems. In this section, we survey their contributions and compare them with the heap protection domain. 2.1 Programming Languages Programming in traditional languages such as C language and assembly language enable a programmer to cast any value to a pointer and then refer to memory through the pointer, but this often results in an invalid memory reference. Modern programming languages such as Java[2] and C#[22] thus do not provide pointers. They provide references instead. References differ from pointers in that a reference may not be a raw memory address. They also provide such features as array index checking, which prevents invalid memory accesses through references. Programs written in these modern programming languages thus cannot cause invalid memory accesses. While the modern programming languages are an effective way to avoid invalid memory accesses, not all programs that can be easily written in the modern languages, and there is vast number of existing written in traditional languages. SafeC[3] and CCured[23] insert range checks to prevent legacy C code from making invalid memory accesses, but their practicality is limited because of the runtime overhead for range checks and because their pointer implementation (a fat pointer) is not compatible with the conventional one (address only).CCured suffers less runtime overhead (30% to 150%) than SafeC (130% to 540%) because it statically verifies pointer operations and inserts a range check only if one is needed. Both SafeC and CCured implement range checks using fat pointers, thus their pointer 6 JFCMark is a trademark of Excelsior, LLC. 104
Page 1 and 2:
Edited by: Ralf Gitzel, Markus Alek
Page 3 and 4:
Message from the Chairs Dear confer
Page 5 and 6:
Sam Midkiff, Purdue University (USA
Page 7 and 8:
Session F: Novel Uses of Java______
Page 10 and 11:
The Project Maxwell Assembler Syste
Page 12 and 13:
tomated assembler and disassembler
Page 14 and 15:
memory address offset mnemonic argu
Page 16 and 17:
5.2 Instruction Templates The assem
Page 18 and 19:
ange for a very short restart/debug
Page 20 and 21:
Tatoo: an innovative parser generat
Page 22 and 23:
In the grammar file an error termin
Page 24 and 25:
Figure 3: Push parsers and lexers L
Page 26 and 27:
eturn visit((Expr)p1, param); } R v
Page 28:
Session B Program and Performance A
Page 31 and 32:
Table 1: Use of interfaces and deco
Page 33 and 34:
Table 3: Comparison of the situatio
Page 35 and 36:
will trigger the creation of many n
Page 37 and 38:
Appendix A 10 9 8 7 6 5 4 3 2 1 0 1
Page 39 and 40:
Throughout this paper, we make no a
Page 41 and 42:
instrumented program and obtained t
Page 43 and 44:
Figure 5: Investigation of garbage
Page 45 and 46:
to the same category—again, this
Page 47 and 48:
Investigating Throughput Degradatio
Page 49 and 50:
Figure 1: Apache. Throughput degrad
Page 51 and 52:
Minor GC Full GC Workload # of Avg.
Page 53 and 54:
Figure 6: Comparing memory and pagi
Page 55 and 56:
GenRC on the other hand, allows the
Page 58:
Session C Mobile and Distributed Sy
Page 61 and 62: ing a continuous buffer for raw dat
Page 63 and 64: the data arrival speed is more impo
Page 65 and 66: public class StreamingClient { publ
Page 67 and 68: importance of β in our aggregation
Page 69 and 70: Enabling Java Mobile Computing on t
Page 71 and 72: A strongly mobile thread has the ab
Page 73 and 74: a context switch occur. The invoked
Page 75 and 76: above phases. Now, the new stack ha
Page 77 and 78: 5 frames 15 frames 25 frames Pure d
Page 79 and 80: Juxta-Cat: A JXTA-based platform fo
Page 81 and 82: Figure 1: JXTA Architecture. 3. JUX
Page 83 and 84: • Send a discovery query to the p
Page 85 and 86: The best candidate is then the one
Page 87 and 88: Local Hosts=2 Hosts=4 Hosts=8 Hosts
Page 90: Session D Resource and Object Manag
Page 93 and 94: Enterprise Edition (J2EE). It enabl
Page 95 and 96: As pictured in Figure 4, JDOSecure
Page 97 and 98: Methods of a PersistenceManager, th
Page 99 and 100: Datenmodell abstrahiert user role,
Page 101 and 102: An Extensible Mechanism for Long-Te
Page 103 and 104: missing object references in the de
Page 105 and 106: 4.2 Mapping the name spaces of the
Page 107 and 108: (a) (b) ColorSliderPanel0 color
Page 109: 8. REFERENCES [1] Abu-Ghazaleh, N.,
Page 113 and 114: The processor then refers to the en
Page 115 and 116: 1: // Protection domain 2: struct p
Page 117 and 118: Table 3: Frequency of JNI calls tha
Page 119 and 120: [13] Intel Corporation. IA-32 Intel
Page 121 and 122: 01 try { 02 ... 03 } finally { 04 t
Page 123 and 124: 2. FRAMEWORK The Framework for Unif
Page 125 and 126: ManagedInputStream ResourceGroup Ma
Page 127 and 128: 18. throw ‡ 1. release 17. cleanu
Page 129 and 130: 3. FUTURE WORK The ability to split
Page 131 and 132: 124
Page 133 and 134: UML sequence diagrams are among the
Page 135 and 136: diagrams, and behavioral (dynamic)
Page 137 and 138: the official scripting language for
Page 139 and 140: Apache's XML Graphics Project. A cu
Page 141 and 142: Java Debug Interface (JDI). In Revi
Page 143 and 144: 1.3 JML 1.3.1 Overview JML, the Jav
Page 145 and 146: The Usage of CANAPA is fairly strai
Page 147 and 148: *@non_null@*/ String str = attribut
Page 149 and 150: 142
Page 151 and 152: parallel and distributed versions o
Page 153 and 154: RingElem CextendsRingElem GenPolyno
Page 155 and 156: RingElem +isZERO():bolean CextendsR
Page 157 and 158: class constructors with the actual
Page 159 and 160: plemented via a distributed hash ta
Page 161 and 162:
which are common nowadays. The reus
Page 163 and 164:
Derivative Contract Component Repos
Page 165 and 166:
stepwise execution create Derivativ
Page 167 and 168:
5.4.1 Structural Constraints Struct
Page 169 and 170:
into the conceptual foundation of n
Page 171 and 172:
different implementation and is mor
Page 173 and 174:
the service from the root. It allow
Page 175 and 176:
model: 1. Servlet [6] adapter compo
Page 177 and 178:
y possibly different service, where
Page 179 and 180:
or the fact that widgets extend ser
Page 181 and 182:
174
Page 183 and 184:
The idea of Java 5.0 type inference
Page 185 and 186:
Source := (class | interface)∗ cl
Page 187 and 188:
5. IMPLEMENTATION In order to prese
Page 189 and 190:
Infinite Streams in Java Dominik Gr
Page 191 and 192:
} private static LinkedStream fibon
Page 193 and 194:
of the f stream in order to compute
Page 195 and 196:
Interaction among Objects via Roles
Page 197 and 198:
(a) (b) (c) (d) (e) Figure 1: The p
Page 199 and 200:
class Printer { private int totalPr
Page 201 and 202:
Experiences of using the Dagstuhl M
Page 203 and 204:
Metric Definition Java .class files
Page 205 and 206:
scription of the metric values. Non
Page 207 and 208:
Figure 1: Results from the J-vestig
Page 209 and 210:
an error is subsequently generated
Page 211 and 212:
3. BASIC TERMINOLOGY As object-orie
Page 213 and 214:
• subtyping • (implementation)
Page 215 and 216:
Improving the Quality of Programmin
Page 217 and 218:
Results of online checks (shortened
Page 219 and 220:
212
Page 221 and 222:
214
Page 223 and 224:
Experiences With Hierarchy-Based Co
Page 225 and 226:
Sub View Child DataField 0..n Ke
Page 227 and 228:
Figure 8 - Actual State Charts elem
Page 229 and 230:
associations, which may result in r
Page 231 and 232:
M3PS: A Multi-Platform P2P System B
Page 233 and 234:
In following, we will explain in de
Page 235 and 236:
Figure 10. JDP in Windows XP. Figur
Page 237 and 238:
Mapping Clouds of SOA- and Business
Page 239 and 240:
the technical SOA events (from the
Page 241 and 242:
component and the business process
Page 243 and 244:
Figure 13. “Business Value of Dat
Page 245 and 246:
Solaris of SUN. This platform provi
Page 247 and 248:
status change of an application is
Page 249 and 250:
coming up, is presently discussing
Page 251:
ISBN: 3-939352-05-5 ISBN: 978-3-939
show all

4th International Conference on Principles and Practices ... - MADOC

You also want an ePaper? Increase the reach of your titles

Delete template?

Save as template?