changeset 2693:bcbda467e1ae

Clean up; removed subroutine block flag.
author Thomas Wuerthinger <thomas@wuerthinger.net>
date Wed, 18 May 2011 14:37:57 +0200
parents 8fcf5179aafd
children 773189811d10
files doc/design/graal_compiler.pdf graal/GraalCompiler/.classpath graal/GraalCompiler/src/com/sun/c1x/debug/CFGPrinter.java graal/GraalCompiler/src/com/sun/c1x/doc/IRInterpreter.txt graal/GraalCompiler/src/com/sun/c1x/doc/LoopPeeling.txt graal/GraalCompiler/src/com/sun/c1x/doc/backend_open_issues.txt graal/GraalCompiler/src/com/sun/c1x/doc/differences.txt graal/GraalCompiler/src/com/sun/c1x/doc/performance.txt graal/GraalCompiler/src/com/sun/c1x/graph/BlockMap.java graal/GraalCompiler/src/com/sun/c1x/ir/BlockBegin.java graal/GraalCompiler/src/com/sun/c1x/lir/LIRList.java graal/GraalRuntime/.classpath runtests.sh
diffstat 13 files changed, 23 insertions(+), 409 deletions(-) [+]
line wrap: on
line diff
Binary file doc/design/graal_compiler.pdf has changed
--- a/graal/GraalCompiler/.classpath	Wed May 18 09:44:05 2011 +0200
+++ b/graal/GraalCompiler/.classpath	Wed May 18 14:37:57 2011 +0200
@@ -1,10 +1,10 @@
-<?xml version="1.0" encoding="UTF-8"?>
-<classpath>
-	<classpathentry kind="src" path="src"/>
-	<classpathentry kind="con" path="org.eclipse.jdt.launching.JRE_CONTAINER"/>
-	<classpathentry combineaccessrules="false" exported="true" kind="src" path="/CRI"/>
-	<classpathentry combineaccessrules="false" kind="src" path="/GraalGraph"/>
-	<classpathentry combineaccessrules="false" kind="src" path="/GraalGraphviz"/>
-	<classpathentry combineaccessrules="false" kind="src" path="/com.oracle.max.asm"/>
-	<classpathentry kind="output" path="bin"/>
-</classpath>
+<?xml version="1.0" encoding="UTF-8"?>
+<classpath>
+	<classpathentry kind="src" path="src"/>
+	<classpathentry kind="con" path="org.eclipse.jdt.launching.JRE_CONTAINER"/>
+	<classpathentry combineaccessrules="false" kind="src" path="/GraalGraph"/>
+	<classpathentry combineaccessrules="false" kind="src" path="/GraalGraphviz"/>
+	<classpathentry combineaccessrules="false" kind="src" path="/com.oracle.max.asm"/>
+	<classpathentry combineaccessrules="false" kind="src" path="/com.oracle.max.cri"/>
+	<classpathentry kind="output" path="bin"/>
+</classpath>
--- a/graal/GraalCompiler/src/com/sun/c1x/debug/CFGPrinter.java	Wed May 18 09:44:05 2011 +0200
+++ b/graal/GraalCompiler/src/com/sun/c1x/debug/CFGPrinter.java	Wed May 18 14:37:57 2011 +0200
@@ -153,9 +153,6 @@
         if (block.isExceptionEntry()) {
             out.print("\"ex\" ");
         }
-        if (block.isSubroutineEntry()) {
-            out.print("\"sr\" ");
-        }
         if (block.isBackwardBranchTarget()) {
             out.print("\"bb\" ");
         }
--- a/graal/GraalCompiler/src/com/sun/c1x/doc/IRInterpreter.txt	Wed May 18 09:44:05 2011 +0200
+++ /dev/null	Thu Jan 01 00:00:00 1970 +0000
@@ -1,26 +0,0 @@
-Current status and remaining issues in the IRInterpreter for HIR (September/18/09)
-=================================================================================
-
-Known Problems:
-With InterpretInvokedMethods disabled in C1XOptions:
-(2 fails)
-304: jtt/jvmni/JVM_GetClassContext01.java: (0) failed with false (expected true)
-557: jtt/reflect/Class_newInstance02.java: (0) failed with true (expected !java.lang.IllegalAccessException)
-
-The first problem is caused by the use of reflection in the IRInterpreter, and the calling stack is not as 
-expected by the JVM_GetClassContext01 test case. The second one is due to the private constructor of Class_newInstance01.
-Again, we are using reflection to call the newInstance() method to create an instance of class Class_newInstance01
-from the IRInterpreter class, which raises an IllegalAccessException.
-These are the only problems with all optimization levels.
-
-With InterpretInvokedMethods enabled in C1XOptions:
-(7 fails)
-245: jtt/except/Catch_StackOverflowError_03.java: (0) failed with !java.lang.InstantiationException (expected 0)
-304: jtt/jvmni/JVM_GetClassContext01.java: (0) failed with false (expected true)
-311: jtt/lang/Bridge_method01.java: (0) failed with unexpected com.sun.c1x.ci.CiBailout (expected 1)
-557: jtt/reflect/Class_newInstance02.java: (0) failed with true (expected !java.lang.IllegalAccessException)
-572: jtt/reflect/Invoke_virtual01.java: (1) failed with unexpected com.sun.c1x.ci.CiBailout (expected 55)
-575: jtt/reflect/Reflection_getCallerClass01.java: (1) failed with com.sun.c1x.debug.IRInterpreter$Evaluator (expected jtt.reflect.Reflection_getCallerClass01$Caller1)
-592: jtt/threads/Thread_isInterrupted04.java: (0) failed with false (expected true)
-
-Those are also due to reflection usage. The last problem has not been investigated.
\ No newline at end of file
--- a/graal/GraalCompiler/src/com/sun/c1x/doc/LoopPeeling.txt	Wed May 18 09:44:05 2011 +0200
+++ /dev/null	Thu Jan 01 00:00:00 1970 +0000
@@ -1,43 +0,0 @@
-Remaining Issues in the Loop Peeling optimization (September/18/09)
-===================================================================
-
-Known Problems:
-Currently loop peeling is not working when the loop has exception
-blocks. The algorithm has to be updated to handle these cases.
-
-Limitations:
-The algorithm performs loop peeling only on innermost loops. However,
-this is not a limitation. If one wants to peel the outermost loop(s),
-after peeling the innermost loop, an additional pass is necessary
-to update the blocks of the outermost loop, since after peeling
-the innermost loop, newer blocks are added to the CFG.
-
-Current status as of 09/18/2009
-After running using hir configuration, with optimization level 3, the
-following test cases produce wrong results:
-(4 fails)
-233: jtt/except/Catch_Loop01.java: (4) failed with unexpected com.sun.c1x.ci.CiBailout (expected -170)
-234: jtt/except/Catch_Loop02.java: (4) failed with unexpected com.sun.c1x.ci.CiBailout (expected -170)
-245: jtt/except/Catch_StackOverflowError_03.java: (0) failed with unexpected com.sun.c1x.ci.CiBailout (expected 0)
-272: jtt/hotpath/HP_array04.java: (80) failed with unexpected java.lang.AssertionError (expected 15645)
-
-All of them are related the known problem aforementioned.
-All the tests have the innermost loops peeled, and produce right results.
-
-Future Work:
-1- Add more loop tests to jtt. New tests should run the loop 0, 1, 2 or more iterations.
-
-2- Peel loops with exception blocks. 
-
-3- Currently, all innermost loops are peeled. Should we add logic to filter out some loops from loop peeling?
-
-4- Improve the way instructions are cloned. Now the algorithm visits the blocks in BFS order, which
-might produce errors depending on the order the blocks are visited.
-
-5- After inserting new phi instructions at exit blocks, we need to iterate over the remaining CFG to update instructions
-that may use the new phi. The way it's done now might me inefficient if the block has more than one exit node, since
-we can iterate over the same block more than once. This needs to be improved.
-
-5- For performance reasons, improve the way loops are represented, for example, to use a bitmap to represent the loop blocks.
-
-
--- a/graal/GraalCompiler/src/com/sun/c1x/doc/backend_open_issues.txt	Wed May 18 09:44:05 2011 +0200
+++ /dev/null	Thu Jan 01 00:00:00 1970 +0000
@@ -1,22 +0,0 @@
-Remaining Issues in the C1X backend (after the port July-Sep 09)
-======================================================================
-
-Maxine/Inspector Related Open Issues:
-   - Global stubs: Change calling convention (no longer write to callee stack as this makes stepping through the instructions for saving the parameters to global stubs impossible in the inspector)
-   - Reference maps: Corrently implement TargetMethod.prepareReferenceMap for C1XTargetMethod (checking for the need to stack walk a possible callee saved target method) and call it from Maxine
-   - Disassembler: The Maxine disassembler still does not correctly display every machine code instruction issued by C1X
-   - MaxRiRuntime and C1XTargetMethod have fixed dependencies on the X86 parts (instruction decoding, registers, calling convention), should be factored out
-
-Compile-Time Performance Improvements:
-   - Consider deleting the LIRItem class
-   - Make sure that LIROperand objects are not shared among LIR instructions and can therefore be directly modified by the LinearScan register allocator (no more need for the lazy creation of LIRAddress objects in the LIRInstruction class)
-   
-Run-Time Performance Improvements:
-   - Store mapping between machine code location and bytecode index in the target method (remove arguments from global stub calls), this decreases the number of necessary parameters especially for resolution instructions.
-   - Use Inline Cache on virtual method calls
-
-Better Portability:
-   - Integrate XIR; consider using CiLocation / CiConstant in XIR
-   - The JIT adapter frames should be a more general mechanism that receives two calling conventions (in form of an array of locations) and adapts between them automatically
-   - Have the possibility to register intrinsics by specifying XIR code
-   
\ No newline at end of file
--- a/graal/GraalCompiler/src/com/sun/c1x/doc/differences.txt	Wed May 18 09:44:05 2011 +0200
+++ /dev/null	Thu Jan 01 00:00:00 1970 +0000
@@ -1,154 +0,0 @@
-Differences between C1 and C1X, including upgrades and limitations
-(and some general information about C1)
-======================================================================
-
-StrictFP:
-   - C1X has removed the backend code to deal with the FPU stack, and therefore
-     requires SSE2 currently. StrictFP is still tracked in the front end.
-   - C1 will not inline methods with different strictfp-ness. C1X does not have this
-     limitation because it only targets SSE2 x86 processors.
-
-JSR/RET
-   - C1 will bail out if it encounters strange JSR/RET patterns
-       - recursive JSRs
-       - JSR regions that are shared with non-JSR code
-       - RET encountered out of JSR (would not verify)
-
-Exceptions
-   -  C1 will bailout if the code of an exception handler can be reached via normal
-      control flow.
-   => C1X might be extended to introduce a phi for the exception
-      object in this case.
-   -  C1 will bailout if an exception handler covers itself
-
-Verification
-   -  C1 does not rely on bytecode verification having been run. However, if it detects
-      type errors in its building the IR graph it will usually bail out.
-   -  C1 requires a bitmap of the bytecode, where a bit for
-      each byte of the bytecode indicates if the bytecode at that location starts a
-      basic block. It uses this to construct the basic block list in a single pass.
-   => Assertion failures and/or bugs in C1X that cause exceptions to be thrown bail out
-      the compilation instead of crashing the VM.
-   => C1X's BlockMap does not computes the basic block starts in one pass over the bytecode
-      and one pass over the successor lists.
-   => C1X computes the "stores in loops" only when loops are encountered in the CFG.
-      An option can select conservative mode (all locals stored in all loops) trades
-      faster parse speed for fewer optimization opportunities
-   => C1X includes an IRChecker that typechecks the entire IR and checks for CFG
-      consistency that can be run after each pass.
-
-Constants
-   => C1X allows unrestricted use of object constants throughout the code, including
-      folding reads of static final fields that reference objects.
-
-Pinning
-   => C1X pins fewer instructions than C1
-   ** C1X will eventually allow certain kinds of instructions to float outside the CFG
-      and be scheduled with a C2-lite scheduling pass.
-
-Synchronization
-   -  C1 will refuse to compile methods with unbalanced synchronization. This property is
-      computed by the bytecode verifier and supplied to C1.
-   ** C1X will not rely on the bytecode verifier to compute this but should do so itself.
-   => C1 relied on the backend to generate synchronization code for the root method's
-      synchronization operations. C1X inserts code into the start block and generates
-      and exception handler to do this explicitly.
-
-Optimizations
-   => C1X has many more options to turn on individual passes, parts of passes, approximations,
-      etc. It is designed to have three optimization levels:
-      0 = super-fast: essentially no optimization
-      1 = fast:       inlining, constant folding, and local optimizations
-      2 = optimized:  inlining, constant folding, local and global optimizations, including
-                      iterative versions of all algorithms
-   ** Planned optimizations for C1X that C1 does not have:
-      TypeCheckElimination:        remove redundant casts and devirtualize more call sites
-      ArrayBoundsCheckElimination: remove redundant array bounds checks and/or restructure
-                                   code to deoptimize when bounds checks within loops will fail
-      LoopPeeling:                 replicate the first iteration of a loop
-      LoopUnrolling:               replicate the body of certain shapes of loops
-      LoopInvariantCodeMotion:     move invariant code out of a loop
-      ProfileGuidedInlining:       use receiver method profiles to emit guarded inlines
-      ProfileGuidedBlockLayout:    use profiling information for code placement
-      Peephole:                    peephole optimize backend output
-
-Block Merging
-   ** C1X will replace branches to blocks with a single Goto with a branch to the
-      block's successor, if the blocks cannot be merged otherwise.
-
-Constant Folding / Strength reduction
-   -  C1 had some of its strength reduction logic built into the GraphBuilder because
-      the Canonicalizer could not return multiple instructions.
-   => C1X added this ability, moved the logic to Canonicalizer, and added a few new
-      strength reductions.
-   => C1X should have an interface for doing folding of @FOLD method calls
-   => C1X folds many intrinsic operations that don't have side effects
-   => C1X folds all the basic floating point operations
-   => C1X strength reduces (e >> C >> K) to (e >> (C + K)) when C and K are constant
-   => Multiplies of power-of-2 constants are reduced to shifts in the canonicalizer
-      (instead of the backend)
-   ** C1X will be able to run a global sparse conditional constant propagation phase
-      to catch any missed canonicalization opportunities after graph building.
-
-Switches
-   -  C1 did not detect back edges in tableswitch/lookupswitch default branches
-   => C1X does detect these back edges
-   => C1X moved the canonicalization code of 1 and 2 branch switches to canonicalizer,
-      where it belongs
-
-Inlining
-   -  C1 cannot inline:
-      -  native methods (or their stubs), except some intrinsics
-      -  methods whose class has not been initialized
-      -  methods with unbalanced monitors
-      -  methods with JSRs (this is probably technically possible now)
-
-   -  C1 will not inline:
-      -  methods with exception handlers (optional)
-      -  synchronized methods (optional)
-      -  if the maximum inline depth is reached (default = 9)
-      -  if the maximum recursive inline depth is reached (default = 1)
-      -  if the callee is larger than the maximum inline size (reduced to 90% at each level, starting at 35)
-      -  constructors for subclasses of Throwable
-      -  if the strictfp-ness of the callee is different than the caller (on x87)
-      -  abstract methods
-      -  synchronized intrinsics
-
-Load/store elimination
-   => C1X may eliminate loads of static fields, which C1 did not
-   => C1X distinguishes loads/stores to different fields in MemoryBuffer
-   => C1X assumes that RiField instances are unique when .isLoaded() is true
-
-Local/Global Value Numbering
-   => C1X improved local load elimination and no longer value numbers fields, reducing the
-      logic necessary in ValueMap, simplifying it and improving its performance.
-   => C1X reuses the same simplified ValueMap for GVN. Since heap accesses are no longer
-      value numbered, the logic to kill values is unnecessary, greatly simplifying
-      GVN.
-   ** A global version of load elimination will compensate for this loss in the future.
-   => C1X value numbers are always or'd with a high order bit when value numbering is possible
-      to prevent value numbering failing if the value number is accidentally 0.
-
-Nullcheck elimination
-   => A new flag, NonNull, indicates instructions that produce values that are guaranteed
-      to be non-null (e.g. NewXXX and Local 0, NullCheck). Instructions that require null
-      checks check this flag for their inputs in their constructors, eliminating most
-      redundant null checks immediately, without requiring the NullCheckEliminator to run.
-   => C1X uses a more efficient block ordering for null check elimination. The first pass is
-      optimistic and attempts to visit the blocks in reverse post-order. For acyclic graphs,
-      this almost always succeeds, requiring no iteration. Full iterative data flow analysis
-      can be enabled separately. Bitmaps used during the fixpoint calculation are much
-      smaller due to local numbering of instructions (as opposed to global IDs).
-   ** C1X will recognize If's that check against null and propagate the non-nullness across
-      the appropriate branches.
-
-BlockListBuilder
-   -  C1 had a vestigial loop map in BlockListBuilder which was not really used.
-   => C1X does not need to compute a complete loop map in order to do selective phi creation,
-      it builds the "storesInLoops" BitMap in BlockMap.
-
-Types
-   => C1X adds the declared type of method parameters to Local instructions, which
-      may help with devirtualization
-   => C1X makes local 0 of instance methods non-null at the start
-
--- a/graal/GraalCompiler/src/com/sun/c1x/doc/performance.txt	Wed May 18 09:44:05 2011 +0200
+++ /dev/null	Thu Jan 01 00:00:00 1970 +0000
@@ -1,85 +0,0 @@
-Issues that can be addressed for improving performance in C1X
-----------------------------------------------------------------
-
-- indicates not done
-* indicates done
-
-Backend:
-	- better handling of constants, especially immediates
-	- (non XIR) checkcast, instanceof: use nullity
-	- (non XIR) checkcast, instanceof: emit fastpath direct compare
-	- use LEA instruction on x86
-	- recognize pointer arithmetic addressing modes
-	- recognize multiply by 3, 5, 9 and emit lea rk, [rs, rs*2], etc
-	- Maxine XIR: make direct runtime calls instead of through global stub
-	- Maxine XIR: implement inline allocation
-	- Maxine XIR: implement biased locking fastpath
-	- Maxine XIR: faster subtype checks for classes, leaves
-	- Maxine XIR: make use of XirSite nullity, range check information
-	- better handling of tableswitch bytecode
-	- better handling of two operand LIR form
-	- Make the following bytecode implementations inline:
-		- f2i f2l f2d d2i d2l d2f (SSE2)
-		* lrem ldiv (64 bit)
-		- fneg dneg
-	- Make the following bytecode implementations global stubs:
-		- frem drem
-	- Global stubs: use EAX for return value as normal instead of [rsp - 16]
-    - Emit direct call to runtime for new instance, monitorenter, monitorexit
-
-	* XIR: expose nullity, range checkness across XIR interface
-	- XIR: make use of CSE'd array length
-	- XIR: generate special if-instanceof XIR variant with label parameters
-    - Optimize special cases of bytecodes:
-        - (MIN_INT / -1) in IDIV,IREM
-        - (MIN_LONG / -1) in LDIV,LREM
-        - (-infinity, Nan, +infinity) in F2I, F2L, D2I, D2L
-
-
-Frontend:
-    - Remove redundant null check branches in NullCheckEliminator
-	- XIR: implement HIR -> HIR xir translation
-	- Refactor exception edges to allow removal, optimization
-	- Implement typecast elimination
-	- Implement constant propagation
-	- Implement GVN of memory loads / stores
-	- Implement memory reordering
-	- Implement loop invariant code motion
-	- Optimize endianness conversions and endian-writes
-	      (e.g. (x >> 24 & 0xff) | (....)) and a[0] = x >> 24 ...
-	- Finish loop peeling
-	- Implement loop unrolling
-	- Allow value numbering of constant loads
-	- Finish loop peeling
-	- Guarded and multiple inlining
-	- Maxine: speculative leaf class and leaf method assumption
-	- Maxine: adjust static / dynamic inlining heuristics
-		  (e.g. static: trivial methods only in cold spots)
-    - Aggressive optimization of array copy
-
-Compilation speed:
-    - Make special iterators for LIROperand input, temp, output
-    - Add analysisInfo field to Value and use in NullCheckEliminator
-	- Remove RiConstantPool, cpi from unresolved HIR instructions (move to RiField, RiMethod)
-	- Use BlockList instead of ArrayList<Block> where appropriate
-	- Use FrameState instead of ValueStack
-	- Remove exceptionHandlers, make DebugInfo hold FrameState, CiCodePos,
-		exception flags and exception handlers
-	- Clean up and simplify LIRInstruction constructor
-	- Create fewer LIRAddresses
-	- Simplify LIRGenerator logic (forcing of loading, etc)
-	- LIROperand: split into virtual register table?
-	- Cleanup assembler and remove dead code, useless assertions
-	- Chain assembler byte buffers and only assemble at the end
-	- Pick optimal initial assembler byte buffer size
-	- Pick good initial sizes for LinearScan data structures
-	- Remove unnecessary uses of ArrayList and replace with arrays or other list
-	- Use iteration over ArrayList instead of explicit loop
-	- Revisit manual editing / removal of items from ArrayList
-	- Remove non-XIR backend
-	- Pre-assemble XIR for backend
-
-	* Initialize compilation-unique instruction id's lazily with thread local compilation
-	* Remove dead LIROpcodes
-	* Remove dead code in LIRGenerator, X86LIRGenerator, LIRAssembler, X86LIRAssembler
-		(remove commented out code)
--- a/graal/GraalCompiler/src/com/sun/c1x/graph/BlockMap.java	Wed May 18 09:44:05 2011 +0200
+++ b/graal/GraalCompiler/src/com/sun/c1x/graph/BlockMap.java	Wed May 18 14:37:57 2011 +0200
@@ -615,42 +615,4 @@
 
         out.print("loop_depth ").println(Integer.bitCount(block.loops));
     }
-
-//
-//    private static StringBuilder append(StringBuilder sb, BlockBegin block) {
-//        return sb.append('B').append(block.blockID).append('@').append(block.bci());
-//    }
-//
-//    @Override
-//    public String toString() {
-//        StringBuilder sb = new StringBuilder();
-//        for (int bci = 0; bci < blockMap.length; ++bci) {
-//            BlockBegin block = blockMap[bci];
-//            if (block != null) {
-//                append(sb, block);
-//                if (loopBlocks != null && loopBlocks.contains(block)) {
-//                    sb.append("{loop-header}");
-//                }
-//                if (successorMap != null) {
-//                    BlockBegin[] succs = successorMap[bci];
-//                    if (succs != null && succs.length > 0) {
-//                        sb.append(" ->");
-//                        for (BlockBegin succ : succs) {
-//                            append(sb.append(' '), succ);
-//                        }
-//                    }
-//                }
-//                Collection<BlockBegin> handlers = getHandlers(block);
-//                if (!handlers.isEmpty()) {
-//                    sb.append(" xhandlers{");
-//                    for (BlockBegin h : handlers) {
-//                        append(sb, h).append(' ');
-//                    }
-//                    sb.append('}');
-//                }
-//                sb.append(String.format("%n"));
-//            }
-//        }
-//        return sb.toString();
-//    }
 }
--- a/graal/GraalCompiler/src/com/sun/c1x/ir/BlockBegin.java	Wed May 18 09:44:05 2011 +0200
+++ b/graal/GraalCompiler/src/com/sun/c1x/ir/BlockBegin.java	Wed May 18 14:37:57 2011 +0200
@@ -94,7 +94,6 @@
     public enum BlockFlag {
         StandardEntry,
         ExceptionEntry,
-        SubroutineEntry,
         BackwardBranchTarget,
         IsOnWorkList,
         WasVisited,
@@ -497,14 +496,6 @@
         setBlockFlag(BlockFlag.ExceptionEntry);
     }
 
-    public boolean isSubroutineEntry() {
-        return checkBlockFlag(BlockFlag.SubroutineEntry);
-    }
-
-    public void setSubroutineEntry() {
-        setBlockFlag(BlockFlag.SubroutineEntry);
-    }
-
     public boolean isOnWorkList() {
         return checkBlockFlag(BlockFlag.IsOnWorkList);
     }
@@ -555,7 +546,6 @@
 
     public void copyBlockFlags(BlockBegin other) {
         copyBlockFlag(other, BlockBegin.BlockFlag.ParserLoopHeader);
-        copyBlockFlag(other, BlockBegin.BlockFlag.SubroutineEntry);
         copyBlockFlag(other, BlockBegin.BlockFlag.ExceptionEntry);
         copyBlockFlag(other, BlockBegin.BlockFlag.WasVisited);
     }
@@ -697,9 +687,6 @@
         if (isExceptionEntry()) {
             sb.append('E');
         }
-        if (isSubroutineEntry()) {
-            sb.append('s');
-        }
         if (isParserLoopHeader()) {
             sb.append("LH");
         }
--- a/graal/GraalCompiler/src/com/sun/c1x/lir/LIRList.java	Wed May 18 09:44:05 2011 +0200
+++ b/graal/GraalCompiler/src/com/sun/c1x/lir/LIRList.java	Wed May 18 14:37:57 2011 +0200
@@ -414,9 +414,6 @@
         if (x.checkBlockFlag(BlockBegin.BlockFlag.ExceptionEntry)) {
             TTY.print("ex ");
         }
-        if (x.checkBlockFlag(BlockBegin.BlockFlag.SubroutineEntry)) {
-            TTY.print("jsr ");
-        }
         if (x.checkBlockFlag(BlockBegin.BlockFlag.BackwardBranchTarget)) {
             TTY.print("bb ");
         }
--- a/graal/GraalRuntime/.classpath	Wed May 18 09:44:05 2011 +0200
+++ b/graal/GraalRuntime/.classpath	Wed May 18 14:37:57 2011 +0200
@@ -1,11 +1,11 @@
-<?xml version="1.0" encoding="UTF-8"?>
-<classpath>
-	<classpathentry kind="src" path="src"/>
-	<classpathentry kind="con" path="org.eclipse.jdt.launching.JRE_CONTAINER/org.eclipse.jdt.internal.debug.ui.launcher.StandardVMType/JavaSE-1.6"/>
-	<classpathentry combineaccessrules="false" kind="src" path="/Assembler"/>
-	<classpathentry combineaccessrules="false" kind="src" path="/CRI"/>
-	<classpathentry combineaccessrules="false" kind="src" path="/GraalCompiler"/>
-	<classpathentry combineaccessrules="false" kind="src" path="/com.oracle.max.asm"/>
-	<classpathentry combineaccessrules="false" kind="src" path="/com.oracle.max.base"/>
-	<classpathentry kind="output" path="bin"/>
-</classpath>
+<?xml version="1.0" encoding="UTF-8"?>
+<classpath>
+	<classpathentry kind="src" path="src"/>
+	<classpathentry kind="con" path="org.eclipse.jdt.launching.JRE_CONTAINER/org.eclipse.jdt.internal.debug.ui.launcher.StandardVMType/JavaSE-1.6"/>
+	<classpathentry combineaccessrules="false" kind="src" path="/GraalCompiler"/>
+	<classpathentry combineaccessrules="false" kind="src" path="/com.oracle.max.asm"/>
+	<classpathentry combineaccessrules="false" kind="src" path="/com.oracle.max.base"/>
+	<classpathentry combineaccessrules="false" kind="src" path="/com.oracle.max.asmdis"/>
+	<classpathentry combineaccessrules="false" kind="src" path="/com.oracle.max.cri"/>
+	<classpathentry kind="output" path="bin"/>
+</classpath>
--- a/runtests.sh	Wed May 18 09:44:05 2011 +0200
+++ b/runtests.sh	Wed May 18 14:37:57 2011 +0200
@@ -11,4 +11,5 @@
   echo "GRAAL is not defined. It must point to a maxine repository directory."
   exit 1;
 fi
-${JDK7}/bin/java -client -d64 -graal -ea -esa -Xcomp -XX:+PrintCompilation -XX:CompileOnly=jtt -Xbootclasspath/p:"${MAXINE}/VM/bin" -Xbootclasspath/p:"${MAXINE}/com.oracle.max.base/bin" $1 test.com.sun.max.vm.compiler.JavaTester -verbose=1 -gen-run-scheme=false -run-scheme-package=all ${MAXINE}/VM/test/jtt/bytecode ${MAXINE}/VM/test/jtt/except ${MAXINE}/VM/test/jtt/hotpath ${MAXINE}/VM/test/jtt/jdk ${MAXINE}/VM/test/jtt/lang ${MAXINE}/VM/test/jtt/loop ${MAXINE}/VM/test/jtt/micro ${MAXINE}/VM/test/jtt/optimize ${MAXINE}/VM/test/jtt/reflect ${MAXINE}/VM/test/jtt/threads
+TESTDIR=${MAXINE}/com.oracle.max.vm/test
+${JDK7}/bin/java -client -d64 -graal -ea -esa -Xcomp -XX:+PrintCompilation -XX:CompileOnly=jtt -Xbootclasspath/p:"${MAXINE}/com.oracle.max.vm/bin" -Xbootclasspath/p:"${MAXINE}/com.oracle.max.base/bin" $1 test.com.sun.max.vm.compiler.JavaTester -verbose=1 -gen-run-scheme=false -run-scheme-package=all ${TESTDIR}/jtt/bytecode ${TESTDIR}/jtt/except ${TESTDIR}/jtt/hotpath ${TESTDIR}/jtt/jdk ${TESTDIR}/jtt/lang ${TESTDIR}/jtt/loop ${TESTDIR}/jtt/micro ${TESTDIR}/jtt/optimize ${TESTDIR}/jtt/reflect ${TESTDIR}/jtt/threads