Mercurial > hg > graal-compiler

comparison graal/Compiler/src/com/sun/c1x/package-info.java @ 2507:9ec15d6914ca

Find changesets by keywords (author, files, the commit message), revision number or hash, or revset expression.
Pull over of compiler from maxine repository.
author Thomas Wuerthinger <thomas@wuerthinger.net>
date Wed, 27 Apr 2011 11:43:22 +0200
parents
children
comparison
equal deleted inserted replaced
2506:4a3bf8a5bf41 2507:9ec15d6914ca
1 /*
2 * Copyright (c) 2010, 2011, Oracle and/or its affiliates. All rights reserved.
3 * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
4 *
5 * This code is free software; you can redistribute it and/or modify it
6 * under the terms of the GNU General Public License version 2 only, as
7 * published by the Free Software Foundation.
8 *
9 * This code is distributed in the hope that it will be useful, but WITHOUT
10 * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
11 * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License
12 * version 2 for more details (a copy is included in the LICENSE file that
13 * accompanied this code).
14 *
15 * You should have received a copy of the GNU General Public License version
16 * 2 along with this work; if not, write to the Free Software Foundation,
17 * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA.
18 *
19 * Please contact Oracle, 500 Oracle Parkway, Redwood Shores, CA 94065 USA
20 * or visit www.oracle.com if you need additional information or have any
21 * questions.
22 */
23
24 /**
25 * The top-level package in C1X containing options, metrics, timers and the main compiler class
26 * {@link com.sun.c1x.C1XCompiler}.
27 *
28 * <H2>{@code C1XCompiler} Overview</H2>
29 *
30 * C1X is intended to be used with multiple JVM's so makes no use of or reference to classes for a specific JVM, for
31 * example Maxine.
32 *
33 * The compiler is represented by the class {@code C1XCompiler}. {@code C1XCompiler} binds a specific target
34 * architecture and JVM interface to produce a usable compiler object. There are
35 * two variants of {@code compileMethod}, one of which is used when doing <i>on stack replacement</i> (OSR), discussed
36 * later. The main variant takes {@link com.sun.cri.ri.RiMethod} and {@link com.sun.cri.xir.RiXirGenerator} arguments.
37 * {@code RiMethod} is C1X's representation of a Java method and {@code RiXirGenerator} represents the interface through
38 * which the compiler requests the XIR for a given bytecode from the runtime system.
39 *
40 * <H3>The C1X Compilation Process</H3>
41 *
42 * {@link com.sun.c1x.C1XCompiler#compileMethod} creates a {@link C1XCompilation} instance and then returns the result of calling its
43 * {@link com.sun.c1x.C1XCompilation#compile} method. The {@code C1XCompilation} instance records whether {@code compileMethod} was invoked with
44 * the OSR variant, which is used later in the IR generation.
45 * <p>
46 * While there is only one {@code C1XCompiler} instance, there may be several compilations proceeding concurrently, each of
47 * which is represented by a unique {@code C1XCompilation} instance. The static method {@link com.sun.c1x.C1XCompilation#current}} returns the
48 * {@code C1XCompilation} instance associated with the current thread, and is managed using a {@link java.lang.ThreadLocal} variable. It
49 * is used when assigning the unique id that is used for tracing output to an HIR node. Each {@code C1XCompilation} instance
50 * has an associated {@link com.sun.cri.ci.CiStatistics} object that accumulates information about the compilation process, but is also
51 * used as a generator of, for example, basic block identifiers.
52 * <p>
53 * The compilation begins by calling {@link com.sun.c1x.C1XCompilation#emitHIR}, which creates the high-level intermediate representation (HIR) from the
54 * bytecodes of the method. The HIR is managed by the {@link com.sun.c1x.graph.IR} class, an instance of which is created by
55 * {@code emitHR}, which then calls the {{@link com.sun.c1x.graph.IR#build}} method and returns the result. The {@code C1XCompilation} and {@code IR}
56 * instances are are bi-directionally linked.
57 *
58 * <H3>Supported backends</H3>
59 *
60 * <ul>
61 * <li>AMD64/x64 with SSE2</li>
62 * </ul>
63 *
64 * <H2>Notes and Todos</H2> This is a collection of notes about the C1X compiler, including future directions,
65 * refactorings, missing features, broken features, etc.
66 *
67 *
68 * <h3>Anticipated Refactorings</h3>
69 *
70 * <ul>
71 * <li>
72 * The HIR nodes {@link com.sun.c1x.ir.UnsafePrefetch}, {@link com.sun.c1x.ir.UnsafePutObject}, etc should be replaced by uses of the newer
73 * {@link com.sun.c1x.ir.LoadPointer} and {@link com.sun.c1x.ir.StorePointer} nodes. Currently, the unsafe nodes are only generated by
74 * the creation of an OSR entry. Benefit: reduce the number of different IR nodes.</li>
75 *
76 * <li>
77 * Add a field to optionally store an {@link com.sun.c1x.ir.Info} object for each HIR node, and remove the
78 * {@link com.sun.c1x.ir.Instruction#exceptionHandlers} field, the {@link com.sun.c1x.ir.Instruction#bci} field, and any fields to store the Java
79 * frame state in subclasses. Benefit: saves space if most HIR nodes do not have exception handlers, a bci or Java frame
80 * state. Removes virtual dispatch on accessing debug information for nodes. Allows any node, regardless of its type, to
81 * have info attached.</li>
82 *
83 * <li>
84 * Migrate all HIR nodes to use the immutable {@link com.sun.c1x.value.FrameStateInfo} for debugging information. The {@link com.sun.c1x.value.FrameState}
85 * class is mutable and used throughout graph building. Benefit: {@code FrameStateInfo} would save both total space in
86 * the IR graph prevent many bugs due to the mutability of {@code FrameState}.</li>
87 *
88 * <li>
89 * Move the {@code FrameState} class to an inner class, or combine entirely, with the {@link com.sun.c1x.graph.GraphBuilder} class. After
90 * the introduction of the {@code FrameStateInfo} into HIR nodes, the mutable value stack should only need to be
91 * accessed from the graph builder.</li>
92 *
93 * </ul>
94 *
95 * <h3>Missing or incomplete features</h3>
96 *
97 * There are some features of C1 that were not ported forward or finished given the time constraints for the C1X port. A
98 * list appears below.
99 *
100 * <ul>
101 * <li>
102 * Deoptimization metadata. The locations of all local variables and stack values are not communicated back to the
103 * runtime system through the {@link com.sun.cri.ci.CiDebugInfo} class yet. Such values are known to the register allocator, and there
104 * vestigial logic to compute them still there in the
105 * {@link com.sun.c1x.alloc.LinearScan#computeDebugInfo} method. To complete this metadata, the
106 * {@link com.sun.c1x.alloc.LinearScan} class must implement the {@link ValueLocator} interface and pass it to the
107 * {@link com.sun.c1x.lir.LIRDebugInfo#createFrame} method after register allocation. The
108 * resulting debug info will be fed back to the runtime system by the existing logic that calls
109 * {@link com.sun.cri.ci.CiTargetMethod#recordCall(int, Object, CiDebugInfo, boolean)} and other methods. Obviously the runtime
110 * system will need to encode this metadata in a dense format, because it is huge.</li>
111 *
112 *
113 * <li>
114 * Tiered compilation support. C1 supported the ability to add instrumentation to branches, invocations, and checkcasts
115 * in order to feed profile information to the C2 compiler in a tiered compilation setup. It relied on adding some
116 * information to the HIR nodes that represent these operations ({@link Invoke}, {@link CheckCast}, etc). All of this
117 * logic was removed to simplify both the front end and back end in anticipation of designing a future instrumentation
118 * API. XIR should be general enough to allow instrumentation code to be added to invocation and checkcast sites, but
119 * currently has no support for adding code at branches.
120 *
121 * </li>
122 *
123 * <li>
124 * SPARC and other architecture support. There pretty well-delineated separation between the architecture-independent
125 * part of LIR backend and the architecture-dependent, but the only implementation that current exists is the X86
126 * backend ({@link com.sun.c1x.target.amd64.AMD64Backend}, {@link com.sun.c1x.target.amd64.AMD64LIRGenerator}, {@link com.sun.c1x.target.amd64.AMD64LIRAssembler}, etc).</li>
127 *
128 * <li>
129 * XIR for safepoints. The C1X backend should use XIR to get the code for safepoints, but currently it still uses the
130 * handwritten logic (currently only compatible with Maxine).</li>
131 *
132 * </ul>
133 *
134 * <h3>Untested features</h3>
135 *
136 * <ul>
137 *
138 * <li>
139 * Reference map for outgoing overflow arguments. If a C1X method calls another method that has overflow arguments, it
140 * is not clear if the outgoing overflow argument area, which may contain references, has the appropriate bits set in
141 * the reference map for the C1X method's frame. Such arguments may be live in the called method.</li>
142 *
143 * <li>
144 * Although it should work, inlining synchronized methods or methods with exception handlers hasn't been tested.</li>
145 * <li>
146 * On-stack replacement. C1X retains all of the special logic for performing an OSR compilation. This is basically a
147 * compilation with a second entrypoint for entry from the interpreter. However, the generation of a runtime-specific
148 * entry sequence was never tested.</li>
149 *
150 * <li>
151 * {@link com.sun.c1x.C1XIntrinsic Intrinsification} is the mechanism by which the compiler recognizes calls to special JDK or
152 * runtime methods and replaces them with custom code. It is enabled by the {@link com.sun.c1x.C1XOptions#OptIntrinsify} compiler
153 * option. The C1X backend has never been tested with intrinsified arithmetic or floating point operations. For best
154 * performance, it should generate specialized machine code for arithmetic and floating point, perhaps using global
155 * stubs for complex floating point operations. <br>
156 * <i>Note</i>: Folding of special intrinsified methods is supported, tested, and working. The runtime system may
157 * register methods to be folded by using the
158 * {@link com.sun.c1x.C1XIntrinsic#registerFoldableMethod(RiMethod, java.lang.reflect.Method)} call. When the compiler encounters a
159 * call to such a registered method where the parameters are all constants, it invokes the supplied method with
160 * reflection. If the reflective call produces a value and does not throw an exception, C1X replaces the call to the
161 * method with the result.</li>
162 * </ul>
163 *
164 * <h3>Broken features</h3>
165 *
166 * <ul>
167 * <li>
168 * {@link com.sun.c1x.opt.LoopPeeler Loop peeling} was written by Marcelo Cintra near the end of his internship. It was never completed
169 * and should be considered broken. It only remains as a sketch of how loop peeling would be implemented in C1X, or in
170 * case he would finish the implementation and test it.</li>
171 *
172 * <li>
173 * Calls to global stubs should allocate space on the caller's stack. On AMD64 currently, calls to global stubs poke the
174 * arguments onto the stack below the RSP (i.e. in the callee's stack). While normally this code sequence is
175 * uninterruptible and works fine in the VM, signal handlers triggered when debugging or inspecting this code sequence
176 * may destroy these values when the OS calls the signal handler. This requires knowing which global stubs are called
177 * before finalizing the frame size; currently only the calls to
178 * {@link com.sun.c1x.target.amd64.AMD64MacroAssembler#callRuntimeCalleeSaved}
179 * do not fit this pattern. This needs to be fixed so that all global stubs that are called by the assembled code are
180 * known before beginning assembling. The {@link com.sun.c1x.target.amd64.AMD64GlobalStubEmitter} controls how the global stubs accept their
181 * parameters. See {@link com.sun.c1x.target.amd64.AMD64GlobalStubEmitter#callerFrameContainsArguments} and its usages.
182 *
183 * </li>
184 * </ul>
185 */
186 package com.sun.c1x;