-
Notifications
You must be signed in to change notification settings - Fork 5
/
Memory-Allocation-in-JikesRVM_196640936.html
61 lines (49 loc) · 10.4 KB
/
Memory-Allocation-in-JikesRVM_196640936.html
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
<!DOCTYPE html>
<html>
<head>
<title>RVM : Memory Allocation in JikesRVM</title>
<link rel="stylesheet" href="styles/site.css" type="text/css" />
<META http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body class="theme-default aui-theme-default">
<div id="page">
<div id="main" class="aui-page-panel">
<div id="main-header">
<div id="breadcrumb-section">
<ol id="breadcrumbs">
<li class="first">
<span><a href="index.html">RVM</a></span>
</li>
<li>
<span><a href="User-Guide_73933.html">User Guide</a></span>
</li>
<li>
<span><a href="Architecture_73917.html">Architecture</a></span>
</li>
<li>
<span><a href="MMTk_73767.html">MMTk</a></span>
</li>
</ol>
</div>
<h1 id="title-heading" class="pagetitle">
<span id="title-text">
RVM : Memory Allocation in JikesRVM
</span>
</h1>
</div>
<div id="content" class="view">
<div class="page-metadata">
Created by <span class='author'> Robin Garner</span>, last modified by <span class='editor'> David Grove</span> on Dec 21, 2011
</div>
<div id="main-content" class="wiki-content group">
<p>The way that objects are allocated in JikesRVM can be difficult to grasp for someone new to the code base. This document provides a detailed look at some of the paths through the JikesRVM - MMTk interface code to help bootstrap understanding of the process. The process and code illustrated below is current as of March 2011, svn revision 16052 (between JikesRVM 3.1.1 and 3.1.2).</p><h2 id="MemoryAllocationinJikesRVM-MemoryManagerInterface">Memory Manager Interface</h2><p>The best starting place to understand the allocation sequence is in the class org.jikesrvm.mm.mminterface.MemoryManager, which is a facade class for the MMTk allocators. MMTk provides a variety of memory management plans which are designed to be independent of the actual language being implemented. The MemoryManager class orchestrates the services of MMTk to allocate memory, and adds the structure necessary to make the allocated memory into Java objects.</p><p>The method <em>allocateScalar</em> is where all scalar (ie non-array) objects are allocated. The parameters of this method specify the object to be allocated in sufficient detail that when this method is compiled by the opt compiler, all of the parameters are compile-time constants, allowing maximum optimization. Working through the body of the method,</p><pre>Selected.Mutator mutator = Selected.Mutator.get();</pre><p>As mentioned above, MMTk provides many different memory management plans, one of which is selected at build time. This call acquires a pointer to the thread-local per-mutator component of MMTk. Much of MMTk's performance comes from providing unsynchronized thread-local data structures for the frequently used operations, so rather than provide a single interface object, it provides a per-thread interface object for both mutator and collector threads.</p><pre>allocator = mutator.checkAllocator(org.jikesrvm.runtime.Memory.alignUp(size, MIN_ALIGNMENT), align, allocator);</pre><p>An MMTk plan in general provides several spaces where objects can be allocated, each with their own characteristics. JikesRVM is free to request allocation in any of these spaces, but sometimes there are constraints only available on a per-allocation basis that might force MMTk to override JikesRVM's request. For example, JikesRVM may specify that objects allocated by a particular class are allocated in MMTk's non-moving space. At execution time, one such object may turn out to be too large for allocation in the general non-moving space provided by that particular plan, and so MMTk needs to promote the object to the Large Object Space (LOS), which is also non-moving, but has high space overheads. This call will generally compile down to 0 or a small handful of instructions.</p><pre>Address region = allocateSpace(mutator, size, align, offset, allocator, site);</pre><p>This calls a method of MemoryManager, common to all allocation methods (for Arrays and other special objects), that calls</p><pre>Address region = mutator.alloc(bytes, align, offset, allocator, site);</pre><p>to actually allocate memory from the current MMTk plan.</p><pre>Object result = ObjectModel.initializeScalar(region, tib, size);</pre><p>Now we call the JikesRVM object model to initialize the allocated region as a scalar object, and then</p><pre>mutator.postAlloc(ObjectReference.fromObject(result), ObjectReference.fromObject(tib), size, allocator);</pre><p>we call MMTk's <em>postAlloc</em> method to perform initialization that can only be performed after an object has been initialized by the virtual machine.</p><h2 id="MemoryAllocationinJikesRVM-Compilerintegration">Compiler integration</h2><p>The <em>allocateScalar</em> method discussed above is only actually called from one place, the method <em>resolvedNewScalar(int ...)</em> in the class org.jikesrvm.runtime.RuntimeEntrypoints. This class provides methods that are accessed directly by the compilers, via fields in the org.jikesrvm.runtime.Entrypoints class. The 'resolved' part of the method name indicates that the class of object being allocated is resolved at compile time (recall that the Java Language Spec requires that classes are only loaded, resolved etc when they are needed - sometimes it's necessary to compile code that performs classloading and then allocate the object).</p><p>RuntimeEntrypoints also contains an overload, <em>resolvedNewScalar(RVMClass)</em>, that is used by the reflection API to allocate objects. It's instructive to look at this method, as it performs essentially the same operations as the compiler when compiling the call to <em>resolvedNewScalar(int...)</em>.</p><p>Working backwards from this point requires delving into the individual compilers.</p><h3 id="MemoryAllocationinJikesRVM-BaselineCompiler">Baseline Compiler</h3><p>There is a different baseline compiler for each architecture. The relevant code in the baseline compiler for the ia32 architecture is in the class org.jikesrvm.compilers.baseline.ia32.BaselineCompilerImpl. The method <em>emit_resolved_new(RVMClass)</em> is responsible for generating code to execute the 'new' bytecode when the target class is already resolved. Looking at this method, you can see it does essentially what the <em>resolvedNewScalar(RVMClass)</em> method in RuntimeEntrypoints does, then generates Intel machine code to perform the call to the resolvedNewScalar entrypoint. Note how the work of calculating the size, alignment etc of the object is performed <em>by the compiler</em>, <strong><em>at compile time</em></strong>.</p><p>Similar code exists in the PPC baseline compiler.</p><h3 id="MemoryAllocationinJikesRVM-OptimizingCompiler">Optimizing Compiler</h3><p>The optimizing compiler is paradoxically somewhat simpler than the baseline compiler, in that injection of the call to the entrypoint is done in an architecture independent level of compiler IR. (An overview of the JikesRVM optimizing compiler can be found in [1]).</p><p>In HIR (the high-level Intermediate Representation), allocation is expressed as a 'new' opcode. During the translation from HIR to LIR (Low-level IR), this and other opcodes are translated into instructions by the class org.jikesrvm.compilers.opt.hir2lir.ExpandRuntimeServices. The method <em>perform(IR)</em> performs this translation, selecting particular operations via a large switch statement. The NEW_opcode case performs the task we're interested in, doing essentially the same job as the baseline compiler, but generating IR rather than machine instructions. The compiler generates a 'call' operation, and then (if the compilation policy decides it's required) inlines it.</p><p>At this point in code generation, all the methods called by RuntimeEntrypoints.resolvedNewScalar(int...) which are annotated @Inline are also inlined into the current method. This inlining extends through to the MMTk code so that the allocation sequence can be optimized down to a handful of instructions.</p><p>It can be instructive to look at the various levels of IR generated for object allocation using a simple test program and the OptTestHarness utility described elsewhere in the user guide.</p><p>[1] <a href="http://www.stanford.edu/%7Ejwhaley/papers/javagrande99.pdf" class="external-link" rel="nofollow">The Jalapeño Dynamic Optimizing Compiler for Java</a></p><ul><li>Michael Burke, <a href="http://www.research.ibm.com/people/j/jdchoi" class="external-link" rel="nofollow">Jong-Deok Choi</a>, <a href="http://www.research.ibm.com/people/s/sfink" class="external-link" rel="nofollow">Stephen Fink</a>, <a href="http://www.research.ibm.com/people/d/dgrove" class="external-link" rel="nofollow">David Grove</a>, <a href="http://www.research.ibm.com/people/h/hind" class="external-link" rel="nofollow">Michael Hind</a>, <a href="http://www.research.ibm.com/people/v/vsarkar" class="external-link" rel="nofollow">Vivek Sarkar</a>, Mauricio Serrano, V.C. Sreedhar, and Harini Srinivasan.</li><li>''1999 ACM Java Grande Conference'', San Francisco, June 12-14, 1999.</li><li>'''(Source code available as of version 2.0.0 of Jikes RVM.)'''</li></ul><p>The class </p>
</div>
</div> </div>
<div id="footer" role="contentinfo">
<section class="footer-body">
<p>Document generated by Confluence on Apr 01, 2015 16:25</p>
<div id="footer-logo"><a href="http://www.atlassian.com/">Atlassian</a></div>
</section>
</div>
</div> </body>
</html>