From doug.simon at oracle.com Thu May 1 01:00:06 2014 From: doug.simon at oracle.com (doug.simon at oracle.com) Date: Thu, 01 May 2014 01:00:06 +0000 Subject: hg: graal/graal: 7 new changesets Message-ID: <201405010100.s4110G6k018617@aojmv0008> Changeset: 951647e16782 Author: Andreas Woess Date: 2014-04-30 19:38 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/951647e16782 Backed out changeset: d44e138f7020 ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/extended/UnsafeCastNode.java Changeset: 3b2cd5f6d7a5 Author: Andreas Woess Date: 2014-04-30 19:40 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/3b2cd5f6d7a5 Truffle: use PiNode for unsafe type casts ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/nodes/typesystem/UnsafeTypeCastMacroNode.java Changeset: cb2eef41371c Author: Andreas Woess Date: 2014-04-30 19:40 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/cb2eef41371c PiNode: merge object stamps using castTo ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/PiNode.java Changeset: be0c151d912b Author: Michael Van De Vanter Date: 2014-04-29 12:05 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/be0c151d912b Truffle/Instrumentation: API revisions ! graal/com.oracle.truffle.api/src/com/oracle/truffle/api/ExecutionContext.java ! graal/com.oracle.truffle.api/src/com/oracle/truffle/api/impl/AbstractExecutionContext.java ! graal/com.oracle.truffle.api/src/com/oracle/truffle/api/instrument/Instrument.java ! graal/com.oracle.truffle.api/src/com/oracle/truffle/api/instrument/Visualizer.java - graal/com.oracle.truffle.api/src/com/oracle/truffle/api/instrument/impl/DefaultInstrument.java ! graal/com.oracle.truffle.api/src/com/oracle/truffle/api/instrument/impl/DefaultVisualizer.java ! graal/com.oracle.truffle.api/src/com/oracle/truffle/api/instrument/impl/InstrumentationImpl.java + graal/com.oracle.truffle.api/src/com/oracle/truffle/api/instrument/impl/InstrumentationNode.java - graal/com.oracle.truffle.api/src/com/oracle/truffle/api/instrument/impl/InstrumentationNodeImpl.java Changeset: 3774b6f4319b Author: Michael Van De Vanter Date: 2014-04-29 12:43 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/3774b6f4319b Merge with 2f684eda1938cc92a72a35461c8d00f1871fe389 - graal/com.oracle.graal.baseline/src/com/oracle/graal/baseline/LIRBlock.java - graal/com.oracle.graal.baseline/src/com/oracle/graal/baseline/LIRControlFlowGraph.java - graal/com.oracle.graal.baseline/src/com/oracle/graal/baseline/LIRFrameStateBuilder.java - graal/com.oracle.graal.baseline/src/com/oracle/graal/baseline/LIRLoop.java - graal/com.oracle.graal.compiler.amd64/src/com/oracle/graal/compiler/amd64/AMD64MemoryPeephole.java - graal/com.oracle.graal.compiler.common/src/com/oracle/graal/compiler/common/spi/LIRProviders.java - graal/com.oracle.graal.compiler.common/src/com/oracle/graal/compiler/common/spi/LIRTypeTool.java - graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/gen/LIRGenerationResult.java - graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/gen/LIRGenerationResultBase.java - graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/gen/LIRGenerator.java - graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/target/LIRGenLowerable.java - graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/target/LIRGenResLowerable.java - graal/com.oracle.graal.graph/src/com/oracle/graal/graph/FieldIntrospection.java - graal/com.oracle.graal.graph/src/com/oracle/graal/graph/UnsafeAccess.java - graal/com.oracle.graal.hotspot.amd64/src/com/oracle/graal/hotspot/amd64/AMD64HotSpotMemoryPeephole.java - graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/BinaryLogicNode.java - graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/java/LoadExceptionObjectNode.java - graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/spi/ArithmeticLIRGenerator.java - graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/spi/LIRGeneratorTool.java - graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/spi/MemoryArithmeticLIRLowerable.java - graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/spi/MemoryArithmeticLIRLowerer.java - graal/com.oracle.graal.test/src/com/oracle/graal/test/GraalLongUnitTest.java - graal/com.oracle.graal.test/src/com/oracle/graal/test/LongTest.java - test/baseline_whitelist.txt Changeset: 625f779255a7 Author: Michael Van De Vanter Date: 2014-04-30 11:27 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/625f779255a7 Merge with cb2eef41371c7e61e16c0076b0a1ad855dab86cc Changeset: 100306ae985b Author: Tom Rodriguez Date: 2014-04-30 12:27 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/100306ae985b switch MatchRule from class to method annotation and fix review feedback ! graal/com.oracle.graal.api.meta/src/com/oracle/graal/api/meta/Value.java ! graal/com.oracle.graal.compiler.amd64/src/com/oracle/graal/compiler/amd64/AMD64NodeLIRBuilder.java ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/GraalDebugConfig.java ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/gen/NodeLIRBuilder.java ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/match/ComplexMatchResult.java ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/match/ComplexMatchValue.java ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/match/GraalMatchableNodes.java ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/match/MatchContext.java ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/match/MatchPattern.java ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/match/MatchProcessor.java ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/match/MatchRule.java ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/match/MatchRuleRegistry.java ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/match/MatchRules.java ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/match/MatchStatement.java ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/match/MatchableNode.java ! graal/com.oracle.graal.hotspot.amd64/src/com/oracle/graal/hotspot/amd64/AMD64HotSpotNodeLIRBuilder.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/nodes/HotSpotMatchableNodes.java ! graal/com.oracle.graal.lir.amd64/src/com/oracle/graal/lir/amd64/AMD64Arithmetic.java From java at stefan-marr.de Thu May 1 16:52:14 2014 From: java at stefan-marr.de (Stefan Marr) Date: Thu, 1 May 2014 18:52:14 +0200 Subject: Math.exact vs. ExactMath Message-ID: Hi: While trying to optimize some bits in TruffleSOM, I was looking through Java 8?s Math class which has a couple more operations covered than ExactMath, however a quick experiment indicates that Java 8?s Math class is not handled in the same way yet as ExactMath. At least a simple summation loop using addExact() was about 40% slower using Math instead of ExactMath. Is it planed to provide the same support for Java 8?s Math class as there is for ExactMath in the short term? Originally, I was actually looking for a bit shift with an exception on overflow, since it is used in the Mandelbrot benchmark. But I guess, there are too few use cases to really worry about it. Best regards Stefan -- Stefan Marr INRIA Lille - Nord Europe http://stefan-marr.de/research/ From duboscq at ssw.jku.at Thu May 1 17:28:46 2014 From: duboscq at ssw.jku.at (Gilles Duboscq) Date: Thu, 1 May 2014 19:28:46 +0200 Subject: Math.exact vs. ExactMath In-Reply-To: References: Message-ID: Hello, I think the plan is to move to the Java 8 methods and deprecate/remove the ExactMath methods that now have an equivalent in Java 8. I don't really know when this will be done though. -Gilles On Thu, May 1, 2014 at 6:52 PM, Stefan Marr wrote: > Hi: > > While trying to optimize some bits in TruffleSOM, I was looking through Java 8?s Math class which has a couple more operations covered than ExactMath, however a quick experiment indicates that Java 8?s Math class is not handled in the same way yet as ExactMath. At least a simple summation loop using addExact() was about 40% slower using Math instead of ExactMath. > > Is it planed to provide the same support for Java 8?s Math class as there is for ExactMath in the short term? > > Originally, I was actually looking for a bit shift with an exception on overflow, since it is used in the Mandelbrot benchmark. > But I guess, there are too few use cases to really worry about it. > > Best regards > Stefan > > -- > Stefan Marr > INRIA Lille - Nord Europe > http://stefan-marr.de/research/ > > > From D.Sturm42 at gmail.com Thu May 1 22:06:47 2014 From: D.Sturm42 at gmail.com (D.Sturm) Date: Fri, 2 May 2014 00:06:47 +0200 Subject: Lowerable FloatRemNode Message-ID: To handle some edge cases for floating point remainder operation (pesky -0.0) I have to lower FloatRemNodes so I can write some snippets that handle the special cases. Is there any problem with removing the final modifier on the class and making it implement Lowerable? Brings it in line with the Integer versions of those nodes and seems to be working fine for me. The changes come down to changing the signature to public class FloatRemNode extends FloatArithmeticNode implements Canonicalizable, Lowerable { and a boilerplate lowerable implementation: @Override public void lower(LoweringTool tool) { tool.getLowerer().lower(this, tool); } -- Daniel From doug.simon at oracle.com Fri May 2 01:00:06 2014 From: doug.simon at oracle.com (doug.simon at oracle.com) Date: Fri, 02 May 2014 01:00:06 +0000 Subject: hg: graal/graal: 10 new changesets Message-ID: <201405020100.s4210KR4020926@aojmv0008> Changeset: 0e0c24424d14 Author: twisti Date: 2014-04-30 15:08 -1000 URL: http://hg.openjdk.java.net/graal/graal/rev/0e0c24424d14 added com.oracle.graal.api.code.RegisterSaveLayout.registerToSlot(Register) ! graal/com.oracle.graal.api.code/src/com/oracle/graal/api/code/RegisterSaveLayout.java Changeset: 6e036e2a2091 Author: twisti Date: 2014-04-30 15:09 -1000 URL: http://hg.openjdk.java.net/graal/graal/rev/6e036e2a2091 added com.oracle.graal.lir.FrameMap.stackSlotSize() ! graal/com.oracle.graal.lir/src/com/oracle/graal/lir/FrameMap.java Changeset: bb97b75d1d65 Author: twisti Date: 2014-04-30 15:41 -1000 URL: http://hg.openjdk.java.net/graal/graal/rev/bb97b75d1d65 AMD64: implemented DeoptimizationStub.deoptimizationHandler ! graal/com.oracle.graal.asm.amd64/src/com/oracle/graal/asm/amd64/AMD64MacroAssembler.java ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/match/MatchRuleRegistry.java ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/match/MatchStatement.java ! graal/com.oracle.graal.hotspot.amd64/src/com/oracle/graal/hotspot/amd64/AMD64DeoptimizationStub.java ! graal/com.oracle.graal.hotspot.amd64/src/com/oracle/graal/hotspot/amd64/AMD64DeoptimizeOp.java ! graal/com.oracle.graal.hotspot.amd64/src/com/oracle/graal/hotspot/amd64/AMD64HotSpotBackend.java ! graal/com.oracle.graal.hotspot.amd64/src/com/oracle/graal/hotspot/amd64/AMD64HotSpotDeoptimizeCallerOp.java ! graal/com.oracle.graal.hotspot.amd64/src/com/oracle/graal/hotspot/amd64/AMD64HotSpotEnterUnpackFramesStackFrameOp.java ! graal/com.oracle.graal.hotspot.amd64/src/com/oracle/graal/hotspot/amd64/AMD64HotSpotForeignCallsProvider.java ! graal/com.oracle.graal.hotspot.amd64/src/com/oracle/graal/hotspot/amd64/AMD64HotSpotLIRGenerator.java ! graal/com.oracle.graal.hotspot.amd64/src/com/oracle/graal/hotspot/amd64/AMD64HotSpotLeaveCurrentStackFrameOp.java ! graal/com.oracle.graal.hotspot.amd64/src/com/oracle/graal/hotspot/amd64/AMD64HotSpotLeaveDeoptimizedStackFrameOp.java ! graal/com.oracle.graal.hotspot.amd64/src/com/oracle/graal/hotspot/amd64/AMD64HotSpotLeaveUnpackFramesStackFrameOp.java + graal/com.oracle.graal.hotspot.amd64/src/com/oracle/graal/hotspot/amd64/AMD64UncommonTrapStub.java ! graal/com.oracle.graal.hotspot.hsail/src/com/oracle/graal/hotspot/hsail/HSAILHotSpotLIRGenerator.java ! graal/com.oracle.graal.hotspot.ptx/src/com/oracle/graal/hotspot/ptx/PTXHotSpotLIRGenerator.java ! graal/com.oracle.graal.hotspot.sparc/src/com/oracle/graal/hotspot/sparc/SPARCDeoptimizeOp.java ! graal/com.oracle.graal.hotspot.sparc/src/com/oracle/graal/hotspot/sparc/SPARCHotSpotBackend.java ! graal/com.oracle.graal.hotspot.sparc/src/com/oracle/graal/hotspot/sparc/SPARCHotSpotDeoptimizeCallerOp.java ! graal/com.oracle.graal.hotspot.sparc/src/com/oracle/graal/hotspot/sparc/SPARCHotSpotForeignCallsProvider.java ! graal/com.oracle.graal.hotspot.sparc/src/com/oracle/graal/hotspot/sparc/SPARCHotSpotLIRGenerator.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/HotSpotBackend.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/HotSpotCompiledRuntimeStub.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/HotSpotHostBackend.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/HotSpotLIRGenerator.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/HotSpotVMConfig.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotHostForeignCallsProvider.java + graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/nodes/DeoptimizationFetchUnrollInfoCallNode.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/nodes/EnterUnpackFramesStackFrameNode.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/nodes/LeaveCurrentStackFrameNode.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/nodes/LeaveUnpackFramesStackFrameNode.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/stubs/DeoptimizationStub.java + graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/stubs/UncommonTrapStub.java ! src/share/vm/graal/graalCompilerToVM.cpp ! src/share/vm/runtime/deoptimization.cpp Changeset: c0e1a8693e0e Author: Doug Simon Date: 2014-05-01 11:51 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/c0e1a8693e0e mx: added --jdt-warning-as-error when building annotation processor jars ! mxtool/mx.py Changeset: cd34df9f84b1 Author: Doug Simon Date: 2014-05-01 17:05 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/cd34df9f84b1 commented out MatchProcessor logging ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/match/MatchProcessor.java Changeset: 0dae565d9289 Author: Doug Simon Date: 2014-05-01 18:26 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/0dae565d9289 fixed code that ecj had a problem compiling ! graal/com.oracle.truffle.dsl.processor/src/com/oracle/truffle/dsl/processor/node/NodeCodeGenerator.java Changeset: 7d24ff89dc7d Author: Doug Simon Date: 2014-05-01 23:54 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/7d24ff89dc7d mx: parallelized Java builds (GRAAL-350) ! mxtool/mx.py Changeset: f73fc9309f12 Author: Doug Simon Date: 2014-05-01 23:55 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/f73fc9309f12 gate: use parallelized Java building in the gate ! mx/mx_graal.py Changeset: 05d3f069cff2 Author: Doug Simon Date: 2014-05-02 00:17 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/05d3f069cff2 fixed pylint warning ! mxtool/mx.py Changeset: a20be10ad437 Author: Doug Simon Date: 2014-05-02 00:36 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/a20be10ad437 made Graal work with the HotSpot compiler queue and compiler threads, enabled by -XX:-UseGraalCompilationQueue ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/CompilationTask.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/CompileTheWorld.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/HotSpotCompiledNmethod.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/HotSpotVMConfig.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/HotSpotVMFlag.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/bridge/VMToCompiler.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/bridge/VMToCompilerImpl.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotCodeCacheProvider.java ! src/share/vm/classfile/systemDictionary.cpp ! src/share/vm/classfile/vmSymbols.hpp ! src/share/vm/compiler/compileBroker.cpp ! src/share/vm/compiler/compileBroker.hpp ! src/share/vm/graal/graalCodeInstaller.cpp ! src/share/vm/graal/graalCompiler.cpp ! src/share/vm/graal/graalCompiler.hpp ! src/share/vm/graal/graalGlobals.hpp ! src/share/vm/graal/graalJavaAccess.hpp ! src/share/vm/graal/graalVMToCompiler.cpp ! src/share/vm/graal/graalVMToCompiler.hpp ! src/share/vm/interpreter/linkResolver.cpp ! src/share/vm/oops/method.cpp ! src/share/vm/prims/jni.cpp ! src/share/vm/runtime/javaCalls.cpp ! src/share/vm/runtime/thread.cpp ! src/share/vm/runtime/thread.hpp ! src/share/vm/runtime/vmStructs.cpp ! src/share/vm/utilities/exceptions.cpp From tom.deneau at amd.com Fri May 2 17:21:57 2014 From: tom.deneau at amd.com (Deneau, Tom) Date: Fri, 2 May 2014 17:21:57 +0000 Subject: VirtualObjects at deoptimization points. In-Reply-To: References: Message-ID: Hi Gilles -- Could I get an update on the support for VirtualObjects in the host deopt trampoline code? -- Tom D. > -----Original Message----- > From: gilwooden at gmail.com [mailto:gilwooden at gmail.com] On Behalf Of > Gilles Duboscq > Sent: Thursday, April 03, 2014 5:04 AM > To: Deneau, Tom > Cc: graal-dev at openjdk.java.net > Subject: Re: VirtualObjects at deoptimization points. > > Hello Tom, > > The reason I delayed the implementation of VirtualObjects is that we > have to reverse the process that transforms VirtualObjectNodes into > VirtualObjects (that's in > com.oracle.graal.compiler.gen.DebugInfoBuilder.build(FrameState, > LabelRef)). > It shouldn't be so complicated to add this support. I'll give it a try. > > -Gilles > > On Tue, Apr 1, 2014 at 1:07 AM, Tom Deneau wrote: > > Gilles -- > > > > > > > > I noticed in one of our java8 lambda tests (not yet pushed to trunk) > > we had some object allocation that was eliminated by escape analysis. > > But when we try to run this with the trunk now, we get > > > > > > > > com.oracle.graal.graph.GraalInternalError: unimplemented > > > > at > > com.oracle.graal.graph.GraalInternalError.unimplemented(GraalInternalE > > rror.java:38) > > > > at > > com.oracle.graal.hotspot.hsail.HSAILHotSpotLIRGenerator.getNodeForValu > > eFromFrame(HSAILHotSpotLIRGenerator.java:182) > > > > at > > com.oracle.graal.hotspot.hsail.HSAILHotSpotLIRGenerator.createFrameSta > > te(HSAILHotSpotLIRGenerator.java:149) > > > > at > > com.oracle.graal.hotspot.hsail.HSAILHotSpotLIRGenerator.createHostDeop > > tBranch(HSAILHotSpotLIRGenerator.java:140) > > > > > > > > where the line 182 in getNodeForValueFromFrame has > > > > > > > > > > > > } else if (localValue instanceof VirtualObject) { > > > > throw GraalInternalError.unimplemented(); > > > > } > > > > > > > > > > > > What would we need to do to support VirtualObjects at our > > deoptimization infopoints? > > > > > > > > > > > > (We also don't support stack slots yet, but I think I understand what > > is needed to support those). > > > > > > > > -- Tom > > > > From doug.simon at oracle.com Fri May 2 20:40:22 2014 From: doug.simon at oracle.com (Doug Simon) Date: Fri, 2 May 2014 22:40:22 +0200 Subject: webrev to extend HSAIL backend deoptimization to support live values in stack slots In-Reply-To: References: Message-ID: <81CD5512-D059-4AB2-9DD3-BA41520D48AE@oracle.com> Hi Tom, I?ve integrated this patch with the following small fixes: o Made it pass ?mx eclipseformat? o Made it pass ?mx unittest CheckGraalInvariants? o Made OopSaver subclass StackObj to ensure it is only ever stack allocated o Fixed ?mx ?vm server-nograal build? compile errors in vmStructs.cpp due to missing #ifdef GRAAL guards. Some of these issues were found by running ?mx gate?. It would be great if you could do this for future patches. -Doug On May 1, 2014, at 12:28 AM, Deneau, Tom wrote: > I have placed a webrev up at > http://cr.openjdk.java.net/~tdeneau/graal-webrevs/webrev-hsail-stackslot-deopt/webrev > which we would like to get checked into the graal trunk. > > This webrev extends the existing hsail deoptimization logic (which > only supports deoptimization points where the live values are in > registers) to handle the case where the live values are in stackslots. > > Here are the major areas that get affected by stack slot deoptimization: > > 1) At the deopt exit point of a kernel, need to save the required > stack slot variables into the hsail frame. This is some new > code in HSAILHotSpotBackend. > > 2) The host trampoline code needs to handle the case where a > deoptimization value is in a stack slot. See > getNodeForStackSlotFromFrame in HSAILHotSpotBackend. > > * In doing this I realized that we have only one deopt exit from > an hsail kernel, so all the saved hsailFrames for a given > kernel have the same num_s_regs, num_d_regs, etc. So we can > treat num_s_regs, num_d_regs, etc as compile time constants > (for that kernel). This simplified the LocationNodes for > building the hostgraph. > > 3) The oopmap data that can be used from the JVM side to take care > of the case where oops might move under GC needs to handle the > case that stack slot variables could also be oops. > > > Regarding #3 above, the way the current hsail oopmap data is saved (as > a single 16-bit integer in each frame representing the $d registers) > needed some redesign. Now that we will also need an intderminately > longer set of bits to represent stack slots oops, a better strategy > would be to not save the oopsmap at deopt time but instead have some > deopt metadata in a form that the JVM side could access which would > map a deopt "PC" to an oopmap (set of bits) for that PC. This was > done thru OopMapArrayBuilder in HSAILHotSpotBackend (at compile time), > and OopSaver class in gpu_hsail.cpp (at execute time). > > I added fields to ExternalCompilationResult and create a > HSAILHotSpotNmethod to pass the oopMapArray from the compile time > environment to the execute time. > > The deopt save area (allocated on the C++ side) used to allocate an > area for each workitem that was a fixed size big enough to handle a > deopt that saved all the registers. Now it is computed based on the > actual number of s registers, d registers and stack slots saved for > that compilation. See gpu_hsail.cpp and gpu_hsail.hpp. > > Similarly the temporaray oopSave array allocated from the java side > now uses the register and stack slot counts to determine how big an > Object Array to allocate. (this oopSave array will go away some day > when we implement the better oops_do support for the oops in the > HSAILFrame). > > Other changes: > > * Some old junit tests that had been designed to test stack slots > had been disabled once deoptimization logic was added because some > of their deopt points needed to save stack slots, which was not > supported. These tests were re-enabled in this webrev. (Note: > these tests never actually deopted). > > * Some HSAIL backend LIR Ops had @Use annotations that incorrectly > included STACK. These were fixed and some existing Ops (that did > not declare @Use(STACK) had their names changed to better reflect > what they were doing. > > * In DeoptimizeOp, (HSAILControlFlow) and HSAILHotSpotSafepointOp, > removed code that computed the $d register oopmap for that > deoptimization point. This is all computed now in the > OopMapArrayBuilder so doesn't need to be computed and saved at > each deopt point. > > * Some new junit tests to specifically test deoptimizations that > used stack slots (and had oops in stack slots). Including a > forceDeopt call which uses @MethodSubtitution > (ForceDeoptSubstitutions.java) > From doug.simon at oracle.com Sat May 3 01:00:07 2014 From: doug.simon at oracle.com (doug.simon at oracle.com) Date: Sat, 03 May 2014 01:00:07 +0000 Subject: hg: graal/graal: 24 new changesets Message-ID: <201405030100.s4310dE2009079@aojmv0008> Changeset: 8df78fe6d84c Author: Doug Simon Date: 2014-05-02 09:12 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/8df78fe6d84c re-enabled use of Graal compilation queue by default until regression when using HotSpot queue is understood/resolved ! src/share/vm/graal/graalGlobals.hpp Changeset: f52961f15275 Author: Roland Schatz Date: 2014-05-02 10:46 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/f52961f15275 Ignore unit test. ! graal/com.oracle.graal.compiler.hsail.test/src/com/oracle/graal/compiler/hsail/test/lambda/ArrayListGetTest.java Changeset: 4b75c567aa62 Author: Roland Schatz Date: 2014-05-02 11:33 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/4b75c567aa62 Merge. Changeset: 4e3c2247daf4 Author: Lukas Stadler Date: 2014-05-02 12:02 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/4e3c2247daf4 simplify ReentrantNodeIterator ! graal/com.oracle.graal.hotspot.test/src/com/oracle/graal/hotspot/test/WriteBarrierVerificationTest.java ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/FloatingReadPhase.java ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/FrameStateAssignmentPhase.java ! graal/com.oracle.graal.phases/src/com/oracle/graal/phases/graph/ReentrantNodeIterator.java ! graal/com.oracle.graal.replacements/src/com/oracle/graal/replacements/CollapseFrameForSingleSideEffectPhase.java Changeset: 43b3dbfa367d Author: Lukas Stadler Date: 2014-05-02 12:02 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/43b3dbfa367d small cosmetic fix in GraphUtil ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/util/GraphUtil.java Changeset: 5c05f3666abf Author: Lukas Stadler Date: 2014-05-02 14:10 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/5c05f3666abf allow BoundMethodHandles in AheadOfTime verification ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/phases/AheadOfTimeVerificationPhase.java Changeset: c55f44b3c5e5 Author: Lukas Stadler Date: 2014-05-02 12:02 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/c55f44b3c5e5 remove NodesToDoubles, refactoring of node probability and inlining relevance computation ! graal/com.oracle.graal.alloc/src/com/oracle/graal/alloc/ComputeBlockOrder.java ! graal/com.oracle.graal.baseline/src/com/oracle/graal/baseline/BaselineBytecodeParser.java ! graal/com.oracle.graal.compiler.common/src/com/oracle/graal/compiler/common/cfg/AbstractBlock.java ! graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/BoxingEliminationTest.java ! graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/DegeneratedLoopsTest.java ! graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/FinalizableSubclassTest.java ! graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/InvokeExceptionTest.java ! graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/InvokeHintsTest.java ! graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/LockEliminationTest.java ! graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/MemoryScheduleTest.java ! graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/MonitorGraphTest.java ! graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/ea/EATestBase.java ! graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/ea/EarlyReadEliminationTest.java ! graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/ea/PEAReadEliminationTest.java ! graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/ea/PartialEscapeAnalysisTest.java ! graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/ea/PoorMansEATest.java ! graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/inlining/InliningTest.java ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/GraalCompiler.java ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/phases/HighTier.java ! graal/com.oracle.graal.hotspot.test/src/com/oracle/graal/hotspot/test/WriteBarrierAdditionTest.java ! graal/com.oracle.graal.hotspot.test/src/com/oracle/graal/hotspot/test/WriteBarrierVerificationTest.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/CompilationTask.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/HotSpotOptions.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/MonitorSnippets.java ! graal/com.oracle.graal.java/src/com/oracle/graal/java/BciBlockMapping.java + graal/com.oracle.graal.java/src/com/oracle/graal/java/ComputeLoopFrequenciesClosure.java ! graal/com.oracle.graal.java/src/com/oracle/graal/java/GraphBuilderPhase.java ! graal/com.oracle.graal.loop/src/com/oracle/graal/loop/LoopPolicies.java ! graal/com.oracle.graal.loop/src/com/oracle/graal/loop/phases/LoopTransformHighPhase.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/InvokeNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/MergeNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/StructuredGraph.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/cfg/Block.java - graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/cfg/BlocksToDoubles.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/cfg/ControlFlowGraph.java - graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/util/NodesToDoubles.java - graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/InliningPhase.java - graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/InliningUtil.java ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/ProfileCompiledMethodsPhase.java ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/TailDuplicationPhase.java + graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/inlining/ComputeInliningRelevance.java + graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/inlining/InliningPhase.java + graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/inlining/InliningUtil.java - graal/com.oracle.graal.phases/src/com/oracle/graal/phases/graph/ComputeInliningRelevanceClosure.java - graal/com.oracle.graal.phases/src/com/oracle/graal/phases/graph/ComputeProbabilityClosure.java + graal/com.oracle.graal.phases/src/com/oracle/graal/phases/graph/FixedNodeProbabilityCache.java ! graal/com.oracle.graal.printer/src/com/oracle/graal/printer/BinaryGraphPrinter.java ! graal/com.oracle.graal.replacements.test/src/com/oracle/graal/replacements/test/ArraysSubstitutionsTest.java ! graal/com.oracle.graal.replacements.test/src/com/oracle/graal/replacements/test/MethodSubstitutionTest.java ! graal/com.oracle.graal.replacements/src/com/oracle/graal/replacements/GraphKit.java ! graal/com.oracle.graal.replacements/src/com/oracle/graal/replacements/ReplacementsImpl.java ! graal/com.oracle.graal.replacements/src/com/oracle/graal/replacements/SnippetTemplate.java ! graal/com.oracle.graal.replacements/src/com/oracle/graal/replacements/nodes/MacroNode.java ! graal/com.oracle.graal.truffle.hotspot/src/com/oracle/graal/truffle/hotspot/HotSpotTruffleRuntime.java ! graal/com.oracle.graal.truffle.test/src/com/oracle/graal/truffle/test/PartialEvaluationTest.java ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/PartialEvaluator.java ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/TruffleCacheImpl.java ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/phases/ReplaceIntrinsicsPhase.java ! graal/com.oracle.graal.virtual/src/com/oracle/graal/virtual/phases/ea/IterativeInliningPhase.java ! graal/com.oracle.graal.virtual/src/com/oracle/graal/virtual/phases/ea/PartialEscapePhase.java ! mx/projects Changeset: ef315dfdda35 Author: Lukas Stadler Date: 2014-05-02 14:47 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/ef315dfdda35 new GraphUtil.predecessorIterable ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/BeginNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/util/GraphUtil.java ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/ConvertDeoptimizeToGuardPhase.java ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/inlining/InliningUtil.java Changeset: 1f4d56a1fdef Author: Lukas Stadler Date: 2014-05-02 14:47 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/1f4d56a1fdef small fix in CompareNode.evaluate ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/calc/CompareNode.java Changeset: 9fa849f665cc Author: Lukas Stadler Date: 2014-05-02 14:48 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/9fa849f665cc cleanup phase within PartialEscapePhase ! graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/ea/EATestBase.java ! graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/ea/PEAReadEliminationTest.java ! graal/com.oracle.graal.virtual/src/com/oracle/graal/virtual/phases/ea/EffectsPhase.java ! graal/com.oracle.graal.virtual/src/com/oracle/graal/virtual/phases/ea/PartialEscapePhase.java Changeset: dd624471bd30 Author: Andreas Woess Date: 2014-05-02 15:59 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/dd624471bd30 Truffle: remove deprecated Node#adoptChild, Node#adoptChildren. ! CHANGELOG.md ! graal/com.oracle.truffle.api/src/com/oracle/truffle/api/nodes/Node.java Changeset: 42f4d703bf0b Author: Andreas Woess Date: 2014-05-02 15:47 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/42f4d703bf0b TruffleDSL: NodeCodeGenerator: add copy constructor factory method ! graal/com.oracle.truffle.dsl.processor/src/com/oracle/truffle/dsl/processor/node/NodeCodeGenerator.java Changeset: 97ee50d15882 Author: Andreas Woess Date: 2014-05-02 15:49 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/97ee50d15882 TruffleDSL: NodeCodeGenerator: add constructor factory method for uninitialized/default node ! graal/com.oracle.truffle.dsl.processor/src/com/oracle/truffle/dsl/processor/node/NodeCodeGenerator.java Changeset: fd18fa50a8e0 Author: Andreas Woess Date: 2014-05-02 15:49 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/fd18fa50a8e0 TruffleDSL: NodeCodeGenerator: avoid referencing BaseNode class in factory ! graal/com.oracle.truffle.dsl.processor/src/com/oracle/truffle/dsl/processor/node/NodeCodeGenerator.java Changeset: dd95dff835f9 Author: Andreas Woess Date: 2014-05-02 15:51 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/dd95dff835f9 TruffleDSL: add class loading test + graal/com.oracle.truffle.api.dsl.test/src/com/oracle/truffle/api/dsl/test/LazyClassLoadingTest.java Changeset: 4f397be8f424 Author: Andreas Woess Date: 2014-05-02 17:07 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/4f397be8f424 TruffleDSL: NodeCodeGenerator: remove always-true assertion ! graal/com.oracle.truffle.dsl.processor/src/com/oracle/truffle/dsl/processor/node/NodeCodeGenerator.java Changeset: 1a7ebcf3ae22 Author: Andreas Woess Date: 2014-05-02 17:14 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/1a7ebcf3ae22 Truffle: fix javadoc ! graal/com.oracle.truffle.api.test/src/com/oracle/truffle/api/test/ChildNodeTest.java Changeset: 09d721bcffe2 Author: Christian Wimmer Date: 2014-05-02 11:04 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/09d721bcffe2 Introduce API for lookup of VM-internals of method handles + graal/com.oracle.graal.api.replacements/src/com/oracle/graal/api/replacements/MethodHandleAccessProvider.java ! graal/com.oracle.graal.hotspot.amd64/src/com/oracle/graal/hotspot/amd64/AMD64HotSpotBackendFactory.java ! graal/com.oracle.graal.hotspot.hsail/src/com/oracle/graal/hotspot/hsail/HSAILHotSpotBackendFactory.java ! graal/com.oracle.graal.hotspot.ptx/src/com/oracle/graal/hotspot/ptx/PTXHotSpotBackendFactory.java ! graal/com.oracle.graal.hotspot.sparc/src/com/oracle/graal/hotspot/sparc/SPARCHotSpotBackendFactory.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/HotSpotGraalRuntime.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/HotSpotReplacementsImpl.java + graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotMethodHandleAccessProvider.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotProviders.java - graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/AbstractMethodHandleNode.java - graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/MethodHandleInvokeBasicNode.java - graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/MethodHandleLinkToInterfaceNode.java - graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/MethodHandleLinkToSpecialNode.java - graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/MethodHandleLinkToStaticNode.java - graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/MethodHandleLinkToVirtualNode.java + graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/MethodHandleNode.java Changeset: a250a512434d Author: Doug Simon Date: 2014-05-02 21:58 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/a250a512434d HSAIL: support for object values in stack slots at deoptimization points Contributed-by: Tom Deneau ! graal/com.oracle.graal.asm.hsail/src/com/oracle/graal/asm/hsail/HSAILAssembler.java + graal/com.oracle.graal.compiler.hsail.test.infra/src/com/oracle/graal/compiler/hsail/test/infra/ForceDeoptSubstitutions.java ! graal/com.oracle.graal.compiler.hsail.test.infra/src/com/oracle/graal/compiler/hsail/test/infra/GraalKernelTester.java + graal/com.oracle.graal.compiler.hsail.test/src/com/oracle/graal/compiler/hsail/test/DVec3.java + graal/com.oracle.graal.compiler.hsail.test/src/com/oracle/graal/compiler/hsail/test/ObjSpillDeoptBase.java + graal/com.oracle.graal.compiler.hsail.test/src/com/oracle/graal/compiler/hsail/test/ObjSpillDeoptMany20000Test.java + graal/com.oracle.graal.compiler.hsail.test/src/com/oracle/graal/compiler/hsail/test/ObjSpillDeoptMany5000Test.java + graal/com.oracle.graal.compiler.hsail.test/src/com/oracle/graal/compiler/hsail/test/ObjSpillDeoptMany99999Test.java + graal/com.oracle.graal.compiler.hsail.test/src/com/oracle/graal/compiler/hsail/test/ObjSpillDeoptManyBase.java + graal/com.oracle.graal.compiler.hsail.test/src/com/oracle/graal/compiler/hsail/test/ObjSpillDeoptMost20000Test.java + graal/com.oracle.graal.compiler.hsail.test/src/com/oracle/graal/compiler/hsail/test/ObjSpillDeoptMost5000Test.java + graal/com.oracle.graal.compiler.hsail.test/src/com/oracle/graal/compiler/hsail/test/ObjSpillDeoptMost99999Test.java + graal/com.oracle.graal.compiler.hsail.test/src/com/oracle/graal/compiler/hsail/test/ObjSpillDeoptMostBase.java + graal/com.oracle.graal.compiler.hsail.test/src/com/oracle/graal/compiler/hsail/test/ObjSpillDeoptSingle100Test.java + graal/com.oracle.graal.compiler.hsail.test/src/com/oracle/graal/compiler/hsail/test/ObjSpillDeoptSingle20000Test.java + graal/com.oracle.graal.compiler.hsail.test/src/com/oracle/graal/compiler/hsail/test/StaticDoubleSpillBoundsCatchOneTest.java + graal/com.oracle.graal.compiler.hsail.test/src/com/oracle/graal/compiler/hsail/test/StaticDoubleSpillBoundsCatchTest.java ! graal/com.oracle.graal.compiler.hsail.test/src/com/oracle/graal/compiler/hsail/test/StaticDoubleSpillTest.java ! graal/com.oracle.graal.compiler.hsail.test/src/com/oracle/graal/compiler/hsail/test/StaticIntSpillTest.java ! graal/com.oracle.graal.compiler.hsail/src/com/oracle/graal/compiler/hsail/HSAILLIRGenerator.java ! graal/com.oracle.graal.gpu/src/com/oracle/graal/gpu/ExternalCompilationResult.java ! graal/com.oracle.graal.hotspot.hsail/src/com/oracle/graal/hotspot/hsail/HSAILHotSpotBackend.java ! graal/com.oracle.graal.hotspot.hsail/src/com/oracle/graal/hotspot/hsail/HSAILHotSpotRegisterConfig.java ! graal/com.oracle.graal.hotspot.hsail/src/com/oracle/graal/hotspot/hsail/HSAILHotSpotSafepointOp.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/HotSpotVMConfig.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotNmethod.java ! graal/com.oracle.graal.hsail/src/com/oracle/graal/hsail/HSAIL.java ! graal/com.oracle.graal.lir.hsail/src/com/oracle/graal/lir/hsail/HSAILArithmetic.java ! graal/com.oracle.graal.lir.hsail/src/com/oracle/graal/lir/hsail/HSAILCompare.java ! graal/com.oracle.graal.lir.hsail/src/com/oracle/graal/lir/hsail/HSAILControlFlow.java ! graal/com.oracle.graal.lir.hsail/src/com/oracle/graal/lir/hsail/HSAILMove.java ! src/gpu/hsail/vm/gpu_hsail.cpp ! src/gpu/hsail/vm/gpu_hsail.hpp ! src/gpu/hsail/vm/gpu_hsail_Frame.hpp ! src/gpu/hsail/vm/vmStructs_hsail.hpp ! src/share/vm/runtime/vmStructs.cpp Changeset: 01a8820c1228 Author: Miguel Garcia Date: 2014-05-02 21:05 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/01a8820c1228 [flow-sensitive] minor refactorings for readability, documentation ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/cfs/BaseReduction.java ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/cfs/CheckCastReduction.java ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/cfs/EquationalReasoner.java ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/cfs/FixedGuardReduction.java ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/cfs/FlowSensitiveReduction.java ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/cfs/FlowUtil.java ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/cfs/GuardingPiReduction.java ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/cfs/Histogram.java Changeset: bc4ade38c890 Author: Miguel Garcia Date: 2014-05-02 20:25 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/bc4ade38c890 [flow-sensitive] skip OSR methods ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/cfs/FlowSensitiveReductionPhase.java Changeset: 2e56c2096ac5 Author: Miguel Garcia Date: 2014-05-02 22:26 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/2e56c2096ac5 Merge Changeset: 8f09b84f325f Author: Michael Van De Vanter Date: 2014-05-02 16:12 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/8f09b84f325f Truffle/Instrumentation: Revise DefaultVisualizer ! graal/com.oracle.truffle.api/src/com/oracle/truffle/api/instrument/impl/DefaultVisualizer.java Changeset: 07fac8558d7b Author: Tom Rodriguez Date: 2014-05-02 17:03 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/07fac8558d7b update state flag after initialization to allow other compiler threads to execute ! src/share/vm/compiler/compileBroker.cpp ! src/share/vm/graal/graalCompiler.cpp From doug.simon at oracle.com Sun May 4 01:00:05 2014 From: doug.simon at oracle.com (doug.simon at oracle.com) Date: Sun, 04 May 2014 01:00:05 +0000 Subject: hg: graal/graal: 3 new changesets Message-ID: <201405040100.s44109BV006031@aojmv0008> Changeset: d370d87e528f Author: Doug Simon Date: 2014-05-03 18:04 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/d370d87e528f fixed clang compilation error ! src/gpu/hsail/vm/gpu_hsail.cpp Changeset: d0e3f6963ed7 Author: Doug Simon Date: 2014-05-04 01:26 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/d0e3f6963ed7 mx: made parallel Java builds interact correctly with management of subprocesses upon abort/quit ! mxtool/mx.py Changeset: 5d0dd6a6f6b3 Author: Doug Simon Date: 2014-05-04 01:28 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/5d0dd6a6f6b3 mx: improved heuristics for sorting remaining tasks in parallel Java build worklist ! mxtool/mx.py From duboscq at ssw.jku.at Sun May 4 17:17:23 2014 From: duboscq at ssw.jku.at (Gilles Duboscq) Date: Sun, 4 May 2014 19:17:23 +0200 Subject: VirtualObjects at deoptimization points. In-Reply-To: References: Message-ID: Hello, I currently have a prototype [1] that i would like to test. Before creating my own tests, i was wondering if you already have tests for this or if you know of tests that have escaping objects? -Gilles [1] http://cr.openjdk.java.net/~gdub/HSAILVirtualObjectDeopt.patch On Fri, May 2, 2014 at 7:21 PM, Tom Deneau wrote: > Hi Gilles -- > > Could I get an update on the support for VirtualObjects in the host deopt trampoline code? > > -- Tom D. > >> -----Original Message----- >> From: gilwooden at gmail.com [mailto:gilwooden at gmail.com] On Behalf Of >> Gilles Duboscq >> Sent: Thursday, April 03, 2014 5:04 AM >> To: Deneau, Tom >> Cc: graal-dev at openjdk.java.net >> Subject: Re: VirtualObjects at deoptimization points. >> >> Hello Tom, >> >> The reason I delayed the implementation of VirtualObjects is that we >> have to reverse the process that transforms VirtualObjectNodes into >> VirtualObjects (that's in >> com.oracle.graal.compiler.gen.DebugInfoBuilder.build(FrameState, >> LabelRef)). >> It shouldn't be so complicated to add this support. I'll give it a try. >> >> -Gilles >> >> On Tue, Apr 1, 2014 at 1:07 AM, Tom Deneau wrote: >> > Gilles -- >> > >> > >> > >> > I noticed in one of our java8 lambda tests (not yet pushed to trunk) >> > we had some object allocation that was eliminated by escape analysis. >> > But when we try to run this with the trunk now, we get >> > >> > >> > >> > com.oracle.graal.graph.GraalInternalError: unimplemented >> > >> > at >> > com.oracle.graal.graph.GraalInternalError.unimplemented(GraalInternalE >> > rror.java:38) >> > >> > at >> > com.oracle.graal.hotspot.hsail.HSAILHotSpotLIRGenerator.getNodeForValu >> > eFromFrame(HSAILHotSpotLIRGenerator.java:182) >> > >> > at >> > com.oracle.graal.hotspot.hsail.HSAILHotSpotLIRGenerator.createFrameSta >> > te(HSAILHotSpotLIRGenerator.java:149) >> > >> > at >> > com.oracle.graal.hotspot.hsail.HSAILHotSpotLIRGenerator.createHostDeop >> > tBranch(HSAILHotSpotLIRGenerator.java:140) >> > >> > >> > >> > where the line 182 in getNodeForValueFromFrame has >> > >> > >> > >> > >> > >> > } else if (localValue instanceof VirtualObject) { >> > >> > throw GraalInternalError.unimplemented(); >> > >> > } >> > >> > >> > >> > >> > >> > What would we need to do to support VirtualObjects at our >> > deoptimization infopoints? >> > >> > >> > >> > >> > >> > (We also don't support stack slots yet, but I think I understand what >> > is needed to support those). >> > >> > >> > >> > -- Tom >> > >> > > From doug.simon at oracle.com Mon May 5 01:00:05 2014 From: doug.simon at oracle.com (doug.simon at oracle.com) Date: Mon, 05 May 2014 01:00:05 +0000 Subject: hg: graal/graal: 5 new changesets Message-ID: <201405050100.s4510DFI002755@aojmv0008> Changeset: 7f492a524ca7 Author: Miguel Garcia Date: 2014-05-04 14:44 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/7f492a524ca7 [flow-sensitive] bug fix, simplify ShortCircuitOrNode when of check-cast form ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/cfs/EquationalReasoner.java ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/cfs/State.java Changeset: 45a54859fd7d Author: Miguel Garcia Date: 2014-05-03 16:19 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/45a54859fd7d [flow-sensitive] simplify to nullConstant ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/cfs/EquationalReasoner.java Changeset: 49a917f9fa07 Author: Miguel Garcia Date: 2014-05-04 16:12 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/49a917f9fa07 [flow-sensitive] refactoring, factor out evidence-search ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/cfs/EquationalReasoner.java + graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/cfs/Evidence.java ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/cfs/FixedGuardReduction.java ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/cfs/State.java Changeset: e20a45d17181 Author: Gilles Duboscq Date: 2014-04-30 11:48 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/e20a45d17181 Move CIPrintCompilerName handling into CompileTask::print_compilation_impl ! src/share/vm/code/nmethod.cpp ! src/share/vm/compiler/compileBroker.cpp Changeset: 9c66a589ef63 Author: Doug Simon Date: 2014-05-05 00:16 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/9c66a589ef63 fixed assertion in debug VM ! src/share/vm/graal/graalCompiler.cpp From thomas.wuerthinger at oracle.com Mon May 5 14:33:55 2014 From: thomas.wuerthinger at oracle.com (Thomas Wuerthinger) Date: Mon, 5 May 2014 16:33:55 +0200 Subject: Lowerable FloatRemNode In-Reply-To: References: Message-ID: This change is fine. We can integrate it. - thomas On 02 May 2014, at 00:06, D.Sturm wrote: > To handle some edge cases for floating point remainder operation (pesky > -0.0) I have to lower FloatRemNodes so I can write some snippets that > handle the special cases. > > Is there any problem with removing the final modifier on the class and > making it implement Lowerable? Brings it in line with the Integer versions > of those nodes and seems to be working fine for me. > > The changes come down to changing the signature to > > public class FloatRemNode extends FloatArithmeticNode implements > Canonicalizable, Lowerable { > > > and a boilerplate lowerable implementation: > > @Override public void lower(LoweringTool tool) { > tool.getLowerer().lower(this, tool); } > > > > -- Daniel From java at stefan-marr.de Mon May 5 21:40:21 2014 From: java at stefan-marr.de (Stefan Marr) Date: Mon, 5 May 2014 23:40:21 +0200 Subject: General Steps for Optimizing Truffle-based Languages? Message-ID: Dear all: After adding support for primitive value storage in the object layout, similar to how it is solved in JRuby, I am slowly running out of general optimizations that seem to be worthwhile to apply to TruffleSOM, however, performance is still far from impressive. While TruffleSOM outperforms it?s RPython based counterpart on many simple microbenchmarks, it?s not really close on larger benchmarks. Now I am wondering how to continue. For RPython, they got their trace viewer which is rather intuitive after a brief introduction, because the information presented is directly related to a trace of code and it doesn?t take a lot of guessing and experience to see what?s going on and what is coming from where, because it is really closely related to the code of the implementation. So, it is more or less trivial to pick all the low hanging fruit and indicate for instance things that should be constant with their annotations. For Truffle and Graal, I am just not having anywhere near enough experience to understand what I am seeing in the graph viewer. So, I am rather lost when it comes to trying to optimize TruffleSOM on the same level. One thing I still would like to achieve is to get simple microbenchmarks that aren?t doing anything useful to compile to nothing. For example [1]: benchmark = ( 1 to: 20000 do: [ :i | self method: i ] ) method: argument = ( ^argument ) I would guess, it should be possible to compile that to an empty method body for the ?benchmark? method. And consequently the inner loop of the benchmark harness. In RPython, that?s not possible, because they do not do empty loop detection, but just guessing, with the data-dependency-based approach in Graal, that should not really be a problem, right? So, I was trying to understand what I see in the graph viewer for that benchmark but didn?t get very far. Also, the FAQ isn?t really helpful in terms of advise to me. It says things like simplify nodes further, but well, when I look at ZipPy and JRuby, the nodes I got do look already very simple. So, I guess, I am looking for more concrete advise of some sort. What could be a good next step to identify issues that block the optimizer from doing its best, and what would be the best tools that could help me with it? Thanks and best regards Stefan [1] in a TruffleSOM repo the benchmark is executed with: ./graal.sh -cp Smalltalk:Examples/Benchmarks/Richards Examples/Benchmarks/BenchmarkHarness.som Dispatch 1000 0 10000 -- Stefan Marr INRIA Lille - Nord Europe http://stefan-marr.de/research/ From tbaldridge at gmail.com Mon May 5 21:53:20 2014 From: tbaldridge at gmail.com (Timothy Baldridge) Date: Mon, 5 May 2014 15:53:20 -0600 Subject: Implementing generators in Truffle Message-ID: For a language I'm writing (based on Truffle) I would love to be able to support yield at a language level. What's the best way to go about this? Am I stuck implementing yield via state machines like C# does, or is there some sort of delimited continuation system in Truffle? Thanks, Timothy From thomas.wuerthinger at oracle.com Mon May 5 22:17:42 2014 From: thomas.wuerthinger at oracle.com (Thomas Wuerthinger) Date: Tue, 6 May 2014 00:17:42 +0200 Subject: Implementing generators in Truffle In-Reply-To: References: Message-ID: <777283F1-CC20-4278-A2B9-D724CF377FE1@oracle.com> Timothy, We have currently no support for continuations in Truffle - it is however on the list of features we would like to add. Lukas Stadler (CC?d) has done some work on continuations in the context of HotSpot that we plan to port. Maybe you can provide us with some details on what kind of delimited continuation system would fit your needs. The ZipPy guys (e.g., Wei Zhang, CC?d) have done some work on optimizing generators in Truffle as they require high-performance generators for their Python implementation. Maybe they can share with you some of their experiences. - thomas On 05 May 2014, at 23:53, Timothy Baldridge wrote: > For a language I'm writing (based on Truffle) I would love to be able to > support yield at a language level. What's the best way to go about this? Am > I stuck implementing yield via state machines like C# does, or is there > some sort of delimited continuation system in Truffle? > > Thanks, > > Timothy From tbaldridge at gmail.com Mon May 5 23:31:34 2014 From: tbaldridge at gmail.com (Timothy Baldridge) Date: Mon, 5 May 2014 17:31:34 -0600 Subject: Implementing generators in Truffle In-Reply-To: <777283F1-CC20-4278-A2B9-D724CF377FE1@oracle.com> References: <777283F1-CC20-4278-A2B9-D724CF377FE1@oracle.com> Message-ID: I'm mostly interested in this for creating cheap co-routines and/or generators in languages. I have a fair amount of experience with RPython and implementation of yield semantics in that language is rather straight forward. From my reading of the Truffle documentation it didn't seem to be so straightforward. So I'd prefer to have true delimited continuations where a yield in one function could bounce up through several frames (as exceptions do), but I could settle for Python/C# style "within this method only" support. Timothy On Mon, May 5, 2014 at 4:17 PM, Thomas Wuerthinger < thomas.wuerthinger at oracle.com> wrote: > Timothy, > > We have currently no support for continuations in Truffle - it is however > on the list of features we would like to add. Lukas Stadler (CC?d) has done > some work on continuations in the context of HotSpot that we plan to port. > Maybe you can provide us with some details on what kind of delimited > continuation system would fit your needs. > > The ZipPy guys (e.g., Wei Zhang, CC?d) have done some work on optimizing > generators in Truffle as they require high-performance generators for their > Python implementation. Maybe they can share with you some of their > experiences. > > - thomas > > On 05 May 2014, at 23:53, Timothy Baldridge wrote: > > > For a language I'm writing (based on Truffle) I would love to be able to > > support yield at a language level. What's the best way to go about this? > Am > > I stuck implementing yield via state machines like C# does, or is there > > some sort of delimited continuation system in Truffle? > > > > Thanks, > > > > Timothy > > -- ?One of the main causes of the fall of the Roman Empire was that?lacking zero?they had no way to indicate successful termination of their C programs.? (Robert Firth) From ndrzmansn at gmail.com Tue May 6 00:01:27 2014 From: ndrzmansn at gmail.com (Wei Zhang) Date: Mon, 5 May 2014 17:01:27 -0700 Subject: Implementing generators in Truffle In-Reply-To: References: <777283F1-CC20-4278-A2B9-D724CF377FE1@oracle.com> Message-ID: Hi Timothy, I don't think there is Truffle level support for generators yet. In ZipPy we encode the control flow state of a generator in the heap. When resuming the generator uses the control flow data to resume to the right node. So there is an extra overhead to keep track of the program location for generators. The source code of generator related nodes in ZipPy: https://bitbucket.org/ssllab/zippy/src/5d112f1b56877c656ebe00af16d35082ef09bd2e/graal/edu.uci.python.nodes/src/edu/uci/python/nodes/generator/?at=default There is a refactoring going on, so not all the classes are well organized as they should be... Hope this is helpful. Any further question is welcomed. Thanks, /Wei On Mon, May 5, 2014 at 4:31 PM, Timothy Baldridge wrote: > I'm mostly interested in this for creating cheap co-routines and/or > generators in languages. I have a fair amount of experience with RPython > and implementation of yield semantics in that language is rather straight > forward. From my reading of the Truffle documentation it didn't seem to be > so straightforward. > > So I'd prefer to have true delimited continuations where a yield in one > function could bounce up through several frames (as exceptions do), but I > could settle for Python/C# style "within this method only" support. > > Timothy > > > On Mon, May 5, 2014 at 4:17 PM, Thomas Wuerthinger < > thomas.wuerthinger at oracle.com> wrote: > >> Timothy, >> >> We have currently no support for continuations in Truffle - it is however >> on the list of features we would like to add. Lukas Stadler (CC?d) has done >> some work on continuations in the context of HotSpot that we plan to port. >> Maybe you can provide us with some details on what kind of delimited >> continuation system would fit your needs. >> >> The ZipPy guys (e.g., Wei Zhang, CC?d) have done some work on optimizing >> generators in Truffle as they require high-performance generators for their >> Python implementation. Maybe they can share with you some of their >> experiences. >> >> - thomas >> >> On 05 May 2014, at 23:53, Timothy Baldridge wrote: >> >> > For a language I'm writing (based on Truffle) I would love to be able to >> > support yield at a language level. What's the best way to go about >> this? Am >> > I stuck implementing yield via state machines like C# does, or is there >> > some sort of delimited continuation system in Truffle? >> > >> > Thanks, >> > >> > Timothy >> >> > > > -- > ?One of the main causes of the fall of the Roman Empire was that?lacking > zero?they had no way to indicate successful termination of their C > programs.? > (Robert Firth) > From doug.simon at oracle.com Tue May 6 01:00:06 2014 From: doug.simon at oracle.com (doug.simon at oracle.com) Date: Tue, 06 May 2014 01:00:06 +0000 Subject: hg: graal/graal: 23 new changesets Message-ID: <201405060100.s4610b34011307@aojmv0008> Changeset: f5eba273a4f2 Author: Doug Simon Date: 2014-05-05 13:17 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/f5eba273a4f2 mx: factored out detection of JDT compilation ! mxtool/mx.py Changeset: 1f28c463e452 Author: Doug Simon Date: 2014-05-05 13:24 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/1f28c463e452 mx: slight tweak of parallel Java build heuristics ! mxtool/mx.py Changeset: e30d7eaa290d Author: Miguel Garcia Date: 2014-05-04 18:36 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/e30d7eaa290d [flow-sensitive] more metrics, documentation ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/cfs/BaseReduction.java ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/cfs/EquationalReasoner.java ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/cfs/FlowSensitiveReduction.java ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/cfs/State.java Changeset: 229537218983 Author: Miguel Garcia Date: 2014-05-05 11:55 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/229537218983 [flow-sensitive] internal consistency asserts, state tracking ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/cfs/EquationalReasoner.java ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/cfs/State.java Changeset: f2132fab8a6f Author: Josef Eisl Date: 2014-05-05 11:33 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/f2132fab8a6f Add custom GraalJUnitCore. + graal/com.oracle.graal.test/src/com/oracle/graal/test/GraalJUnitCore.java + graal/com.oracle.graal.test/src/com/oracle/graal/test/GraalJUnitRunListener.java + graal/com.oracle.graal.test/src/com/oracle/graal/test/GraalJUnitRunListenerDecorator.java + graal/com.oracle.graal.test/src/com/oracle/graal/test/GraalTextListener.java ! mx/JUnitWrapper.java ! mx/mx_graal.py Changeset: 008a8c905d7e Author: Josef Eisl Date: 2014-05-05 11:34 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/008a8c905d7e Add GraalVerboseTextListener. + graal/com.oracle.graal.test/src/com/oracle/graal/test/GraalVerboseTextListener.java Changeset: a26be2c9b81b Author: Josef Eisl Date: 2014-05-05 16:07 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/a26be2c9b81b Add command line support for JUnit. ! graal/com.oracle.graal.test/src/com/oracle/graal/test/GraalJUnitCore.java ! mx/JUnitWrapper.java ! mx/mx_graal.py Changeset: c62e120e8cd9 Author: Josef Eisl Date: 2014-05-05 11:34 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/c62e120e8cd9 Add TimingDecorator. ! graal/com.oracle.graal.test/src/com/oracle/graal/test/GraalJUnitCore.java + graal/com.oracle.graal.test/src/com/oracle/graal/test/TimingDecorator.java ! mx/mx_graal.py Changeset: 97b49458b616 Author: Doug Simon Date: 2014-05-05 17:27 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/97b49458b616 made FloatRemNode implement Lowerable ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/DefaultHotSpotLoweringProvider.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/calc/FloatRemNode.java Changeset: 51c6ce89d4dd Author: henryjen Date: 2014-02-05 21:24 -0800 URL: http://hg.openjdk.java.net/graal/graal/rev/51c6ce89d4dd 8033289: clang: clean up unused function warning Reviewed-by: coleenp, dholmes, mgerdin ! src/cpu/x86/vm/templateTable_x86_64.cpp ! src/share/vm/prims/jvmtiTagMap.cpp ! src/share/vm/runtime/mutex.cpp Changeset: d250613801fb Author: Bernhard Urban Date: 2014-05-05 18:03 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/d250613801fb gate: make unittests verbose ! mx/mx_graal.py Changeset: 5fcbf87a58b7 Author: Lukas Stadler Date: 2014-05-05 18:36 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/5fcbf87a58b7 fix block probabilities ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/cfg/ControlFlowGraph.java Changeset: eb9fa3d34314 Author: Lukas Stadler Date: 2014-05-05 18:37 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/eb9fa3d34314 Merge (clean phase within PartialEscapePhase) Changeset: 6f23b90c4129 Author: Lukas Stadler Date: 2014-05-05 18:38 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/6f23b90c4129 Merge (Truffle: fix javadoc) Changeset: a900caddcd60 Author: Lukas Stadler Date: 2014-05-05 18:38 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/a900caddcd60 Merge (Merge) - graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/AbstractMethodHandleNode.java - graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/MethodHandleInvokeBasicNode.java - graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/MethodHandleLinkToInterfaceNode.java - graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/MethodHandleLinkToSpecialNode.java - graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/MethodHandleLinkToStaticNode.java - graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/MethodHandleLinkToVirtualNode.java Changeset: ef1342e0f9f2 Author: Lukas Stadler Date: 2014-05-05 18:39 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/ef1342e0f9f2 Merge (update state flag after initialization to allow other compiler threads to execute) Changeset: d968c2db220b Author: Lukas Stadler Date: 2014-05-05 18:39 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/d968c2db220b Merge ([flow-sensitive] refactoring, factor out evidence-search) Changeset: 130e0183b7e2 Author: Lukas Stadler Date: 2014-05-05 18:40 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/130e0183b7e2 Merge (made FloatRemNode implement Lowerable) Changeset: 77eca555014f Author: Lukas Stadler Date: 2014-05-05 18:45 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/77eca555014f Merge (gate: make unittests verbose) Changeset: 2eb6330e13a3 Author: Miguel Garcia Date: 2014-05-05 16:59 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/2eb6330e13a3 [flow-sensitive] fix in knownNotToConform ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/cfs/CheckCastReduction.java ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/cfs/EquationalReasoner.java ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/cfs/FlowSensitiveReduction.java ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/cfs/State.java Changeset: 8653634b9d11 Author: Miguel Garcia Date: 2014-05-05 17:06 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/8653634b9d11 [flow-sensitive] readability, baseCaseIsNullNode ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/cfs/EquationalReasoner.java Changeset: 4f603d776ecc Author: Miguel Garcia Date: 2014-05-05 17:45 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/4f603d776ecc [flow-sensitive] too many type-refinements didn't improve performance ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/cfs/EquationalReasoner.java ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/cfs/FlowSensitiveReduction.java Changeset: fbe9e7088e35 Author: Miguel Garcia Date: 2014-05-05 21:23 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/fbe9e7088e35 Merge From java at stefan-marr.de Tue May 6 16:58:18 2014 From: java at stefan-marr.de (Stefan Marr) Date: Tue, 6 May 2014 18:58:18 +0200 Subject: General Steps for Optimizing Truffle-based Languages? In-Reply-To: References: Message-ID: <8F55B840-2597-403F-97AC-AE93938B8C40@stefan-marr.de> Dear all: Just to give a little more information, here some numbers: http://soft.vub.ac.be/~smarr/downloads/truffle/perf-overview.html The most important part: Runtime factor compared to Java8 DeltaBlue Mandelbrot Richards Java8 1.00 1.00 1.00 JRubyTruffle 2.13 1.26 6.04 TruffleSOM 1.19 15.66 28.43 So, DeltaBlue is pretty good on TruffleSOM and Chris said he didn?t do anything yet to optimize JRuby for that one, so I guess, they?ll be closer in the end. Well, but I didn?t do anything in particular for DeltaBlue either. On the other hand, Mandelbrot and Richards are one order of magnitude slower. Any tips on how to go about fixing that are highly appreciate. One thing that I noticed is that JRuby warms up much faster. DeltaBlue takes an insane amount of time to warmup on TruffleSOM, and I don?t think that its just slow warmup in general. I guess, there might be something going on, but don?t know whether that?s just the inlining propagating through the tree more slowly than in JRuby. Best regards Stefan On 05 May 2014, at 23:40, Stefan Marr wrote: > Dear all: > > After adding support for primitive value storage in the object layout, similar to how it is solved in JRuby, I am slowly running out of general optimizations that seem to be worthwhile to apply to TruffleSOM, however, performance is still far from impressive. > While TruffleSOM outperforms it?s RPython based counterpart on many simple microbenchmarks, it?s not really close on larger benchmarks. > > Now I am wondering how to continue. > > For RPython, they got their trace viewer which is rather intuitive after a brief introduction, because the information presented is directly related to a trace of code and it doesn?t take a lot of guessing and experience to see what?s going on and what is coming from where, because it is really closely related to the code of the implementation. So, it is more or less trivial to pick all the low hanging fruit and indicate for instance things that should be constant with their annotations. > > For Truffle and Graal, I am just not having anywhere near enough experience to understand what I am seeing in the graph viewer. > So, I am rather lost when it comes to trying to optimize TruffleSOM on the same level. > > One thing I still would like to achieve is to get simple microbenchmarks that aren?t doing anything useful to compile to nothing. > > For example [1]: > benchmark = ( > 1 to: 20000 do: [ :i | self method: i ] > ) > method: argument = ( ^argument ) > > I would guess, it should be possible to compile that to an empty method body for the ?benchmark? method. And consequently the inner loop of the benchmark harness. > In RPython, that?s not possible, because they do not do empty loop detection, but just guessing, with the data-dependency-based approach in Graal, that should not really be a problem, right? > So, I was trying to understand what I see in the graph viewer for that benchmark but didn?t get very far. > > Also, the FAQ isn?t really helpful in terms of advise to me. It says things like simplify nodes further, but well, when I look at ZipPy and JRuby, the nodes I got do look already very simple. So, I guess, I am looking for more concrete advise of some sort. > > What could be a good next step to identify issues that block the optimizer from doing its best, and what would be the best tools that could help me with it? > > Thanks and best regards > Stefan > > [1] in a TruffleSOM repo the benchmark is executed with: > ./graal.sh -cp Smalltalk:Examples/Benchmarks/Richards Examples/Benchmarks/BenchmarkHarness.som Dispatch 1000 0 10000 > > > > > -- > Stefan Marr > INRIA Lille - Nord Europe > http://stefan-marr.de/research/ > > > -- Stefan Marr INRIA Lille - Nord Europe http://stefan-marr.de/research/ From chris at chrisseaton.com Tue May 6 17:19:43 2014 From: chris at chrisseaton.com (Chris Seaton) Date: Tue, 6 May 2014 18:19:43 +0100 Subject: General Steps for Optimizing Truffle-based Languages? In-Reply-To: <8F55B840-2597-403F-97AC-AE93938B8C40@stefan-marr.de> References: <8F55B840-2597-403F-97AC-AE93938B8C40@stefan-marr.de> Message-ID: I'm still intending and sitting down to go through the TruffleSOM code in depth at some point, but haven't managed it yet. In the mean time, about warmup. Your while loops are a method on a block that calls itself (self restart), right? Is that tail recursion then? I don't see how you're not blowing the stack. But my point was - however you are implementing loops, is Truffle seeing the loop count, or does only the body of the loop get optimised? In my while loop in Ruby (while loops are like in C in Ruby - not method calls) I report the number of iterations. If I didn't do that, warmup of whatever contains the loop would take a long time. Maybe this doesn't apply to SOM as you have no primitive loop operation. Chris On 6 May 2014 17:58, Stefan Marr wrote: > Dear all: > > Just to give a little more information, here some numbers: > http://soft.vub.ac.be/~smarr/downloads/truffle/perf-overview.html > > The most important part: > > Runtime factor compared to Java8 > DeltaBlue Mandelbrot Richards > Java8 1.00 1.00 1.00 > JRubyTruffle 2.13 1.26 6.04 > TruffleSOM 1.19 15.66 28.43 > > So, DeltaBlue is pretty good on TruffleSOM and Chris said he didn?t do > anything yet to optimize JRuby for that one, so I guess, they?ll be closer > in the end. Well, but I didn?t do anything in particular for DeltaBlue > either. On the other hand, Mandelbrot and Richards are one order of > magnitude slower. > > Any tips on how to go about fixing that are highly appreciate. > > One thing that I noticed is that JRuby warms up much faster. > DeltaBlue takes an insane amount of time to warmup on TruffleSOM, and I > don?t think that its just slow warmup in general. > I guess, there might be something going on, but don?t know whether that?s > just the inlining propagating through the tree more slowly than in JRuby. > > Best regards > Stefan > > On 05 May 2014, at 23:40, Stefan Marr wrote: > > > Dear all: > > > > After adding support for primitive value storage in the object layout, > similar to how it is solved in JRuby, I am slowly running out of general > optimizations that seem to be worthwhile to apply to TruffleSOM, however, > performance is still far from impressive. > > While TruffleSOM outperforms it?s RPython based counterpart on many > simple microbenchmarks, it?s not really close on larger benchmarks. > > > > Now I am wondering how to continue. > > > > For RPython, they got their trace viewer which is rather intuitive after > a brief introduction, because the information presented is directly related > to a trace of code and it doesn?t take a lot of guessing and experience to > see what?s going on and what is coming from where, because it is really > closely related to the code of the implementation. So, it is more or less > trivial to pick all the low hanging fruit and indicate for instance things > that should be constant with their annotations. > > > > For Truffle and Graal, I am just not having anywhere near enough > experience to understand what I am seeing in the graph viewer. > > So, I am rather lost when it comes to trying to optimize TruffleSOM on > the same level. > > > > One thing I still would like to achieve is to get simple microbenchmarks > that aren?t doing anything useful to compile to nothing. > > > > For example [1]: > > benchmark = ( > > 1 to: 20000 do: [ :i | self method: i ] > > ) > > method: argument = ( ^argument ) > > > > I would guess, it should be possible to compile that to an empty method > body for the ?benchmark? method. And consequently the inner loop of the > benchmark harness. > > In RPython, that?s not possible, because they do not do empty loop > detection, but just guessing, with the data-dependency-based approach in > Graal, that should not really be a problem, right? > > So, I was trying to understand what I see in the graph viewer for that > benchmark but didn?t get very far. > > > > Also, the FAQ isn?t really helpful in terms of advise to me. It says > things like simplify nodes further, but well, when I look at ZipPy and > JRuby, the nodes I got do look already very simple. So, I guess, I am > looking for more concrete advise of some sort. > > > > What could be a good next step to identify issues that block the > optimizer from doing its best, and what would be the best tools that could > help me with it? > > > > Thanks and best regards > > Stefan > > > > [1] in a TruffleSOM repo the benchmark is executed with: > > ./graal.sh -cp Smalltalk:Examples/Benchmarks/Richards > Examples/Benchmarks/BenchmarkHarness.som Dispatch 1000 0 10000 > > > > > > > > > > -- > > Stefan Marr > > INRIA Lille - Nord Europe > > http://stefan-marr.de/research/ > > > > > > > > -- > Stefan Marr > INRIA Lille - Nord Europe > http://stefan-marr.de/research/ > > > > From java at stefan-marr.de Tue May 6 17:35:01 2014 From: java at stefan-marr.de (Stefan Marr) Date: Tue, 6 May 2014 19:35:01 +0200 Subject: General Steps for Optimizing Truffle-based Languages? In-Reply-To: References: <8F55B840-2597-403F-97AC-AE93938B8C40@stefan-marr.de> Message-ID: <72D084D8-0A0D-4A1C-9F73-3D1EE75F376A@stefan-marr.de> Hi Chris: On 06 May 2014, at 19:19, Chris Seaton wrote: > In the mean time, about warmup. Your while loops are a method on a block that calls itself (self restart), right? They are specialized nodes, no method calls. > Is that tail recursion then? I don?t see how you're not blowing the stack. No, it?s very much the same as your WhileNode or ZipPy?s loops. Even simpler, because there isn?t anything like break or continue supported. https://github.com/SOM-st/TruffleSOM/blob/master/src/som/interpreter/nodes/specialized/WhileWithStaticBlocksNode.java#L83 And, the loops are fast in microbenchmarks. Would be surprised if they would have major issues. > But my point was - however you are implementing loops, is Truffle seeing the loop count, or does only the body of the loop get optimised? In my while loop in Ruby (while loops are like in C in Ruby - not method calls) I report the number of iterations. If I didn't do that, warmup of whatever contains the loop would take a long time. Maybe this doesn?t apply to SOM as you have no primitive loop operation. According to blame, that?s properly done since Christmas: https://github.com/SOM-st/TruffleSOM/blob/master/src/som/interpreter/nodes/specialized/WhileWithStaticBlocksNode.java#L101 Thanks for trying, but I fear, and hope, that?s nothing superficial. Beside what I don?t understand, I think, I did my homework. That?s why I am running out of ideas again? Also another classic, which was an issue until recently: activation of lambdas/blocks, but even there I am caching the call target properly. If I look at the Truffle graphs in the viewer, everything gets properly inlined and the terminal nodes are all trivial operations, no method calls. So, the ?compilation unit? should be complete and provide all the necessary information to the optimizer. I guess, something is confusing it. But since I can?t make sense of what I see in the graph viewer, I have no idea what?s going on. Thanks Stefan -- Stefan Marr INRIA Lille - Nord Europe http://stefan-marr.de/research/ From chris at chrisseaton.com Tue May 6 17:50:09 2014 From: chris at chrisseaton.com (Chris Seaton) Date: Tue, 6 May 2014 18:50:09 +0100 Subject: General Steps for Optimizing Truffle-based Languages? In-Reply-To: <72D084D8-0A0D-4A1C-9F73-3D1EE75F376A@stefan-marr.de> References: <8F55B840-2597-403F-97AC-AE93938B8C40@stefan-marr.de> <72D084D8-0A0D-4A1C-9F73-3D1EE75F376A@stefan-marr.de> Message-ID: Ah sorry didn't see that node - I was reading the library code and assumed that was what was running. I'll try and do an in-depth comparison against my Mandelbrot soon, since I understand that one the best. Chris On 6 May 2014 18:35, Stefan Marr wrote: > Hi Chris: > > On 06 May 2014, at 19:19, Chris Seaton wrote: > > > In the mean time, about warmup. Your while loops are a method on a block > that calls itself (self restart), right? > They are specialized nodes, no method calls. > > > Is that tail recursion then? I don?t see how you're not blowing the > stack. > No, it?s very much the same as your WhileNode or ZipPy?s loops. > Even simpler, because there isn?t anything like break or continue > supported. > > https://github.com/SOM-st/TruffleSOM/blob/master/src/som/interpreter/nodes/specialized/WhileWithStaticBlocksNode.java#L83 > > And, the loops are fast in microbenchmarks. Would be surprised if they > would have major issues. > > > But my point was - however you are implementing loops, is Truffle seeing > the loop count, or does only the body of the loop get optimised? In my > while loop in Ruby (while loops are like in C in Ruby - not method calls) I > report the number of iterations. If I didn't do that, warmup of whatever > contains the loop would take a long time. Maybe this doesn?t apply to SOM > as you have no primitive loop operation. > > According to blame, that?s properly done since Christmas: > > https://github.com/SOM-st/TruffleSOM/blob/master/src/som/interpreter/nodes/specialized/WhileWithStaticBlocksNode.java#L101 > > Thanks for trying, but I fear, and hope, that?s nothing superficial. > Beside what I don?t understand, I think, I did my homework. That?s why I > am running out of ideas again? > > Also another classic, which was an issue until recently: activation of > lambdas/blocks, but even there I am caching the call target properly. If I > look at the Truffle graphs in the viewer, everything gets properly inlined > and the terminal nodes are all trivial operations, no method calls. So, the > ?compilation unit? should be complete and provide all the necessary > information to the optimizer. I guess, something is confusing it. But since > I can?t make sense of what I see in the graph viewer, I have no idea what?s > going on. > > Thanks > Stefan > > -- > Stefan Marr > INRIA Lille - Nord Europe > http://stefan-marr.de/research/ > > > > From doug.simon at oracle.com Wed May 7 01:00:06 2014 From: doug.simon at oracle.com (doug.simon at oracle.com) Date: Wed, 07 May 2014 01:00:06 +0000 Subject: hg: graal/graal: 25 new changesets Message-ID: <201405070100.s4710dOD024837@aojmv0008> Changeset: f8cf483ba31e Author: Tom Rodriguez Date: 2014-05-05 16:13 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/f8cf483ba31e update description of the MatchRule syntax ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/match/MatchRule.java Changeset: 4cdc787681d4 Author: Tom Rodriguez Date: 2014-05-05 16:13 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/4cdc787681d4 add support for more nodes inputs ! graal/com.oracle.graal.compiler.amd64/src/com/oracle/graal/compiler/amd64/AMD64NodeLIRBuilder.java ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/match/GraalMatchableNodes.java ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/match/MatchNodeAdapter.java ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/match/MatchPattern.java ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/match/MatchProcessor.java ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/match/MatchableNode.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/nodes/HotSpotMatchableNodes.java Changeset: 76213c9350ad Author: Tom Rodriguez Date: 2014-05-05 16:13 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/76213c9350ad improve annotation error reporting ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/gen/NodeLIRBuilder.java ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/match/MatchContext.java ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/match/MatchProcessor.java ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/match/MatchRuleRegistry.java ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/match/MatchStatement.java Changeset: 589c3627fab8 Author: Tom Rodriguez Date: 2014-05-05 20:33 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/589c3627fab8 special cases for addresses involving compressed references ! graal/com.oracle.graal.compiler.amd64/src/com/oracle/graal/compiler/amd64/AMD64LIRGenerator.java ! graal/com.oracle.graal.compiler.amd64/src/com/oracle/graal/compiler/amd64/AMD64NodeLIRBuilder.java ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/match/GraalMatchableNodes.java ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/match/MatchContext.java ! graal/com.oracle.graal.hotspot.amd64/src/com/oracle/graal/hotspot/amd64/AMD64HotSpotNodeLIRBuilder.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/nodes/CompressionNode.java Changeset: 44d700e2faba Author: bharadwaj Date: 2014-05-06 10:35 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/44d700e2faba made GraphKit.inlineInvoke recursively inline all invoke ! graal/com.oracle.graal.replacements/src/com/oracle/graal/replacements/GraphKit.java Changeset: 901b4440a451 Author: Thomas Wuerthinger Date: 2014-04-30 13:36 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/901b4440a451 Add two more ObjectStampJoinTest unit tests. ! graal/com.oracle.graal.nodes.test/src/com/oracle/graal/nodes/test/ObjectStampJoinTest.java Changeset: b3fbf52f34be Author: Thomas Wuerthinger Date: 2014-04-30 13:40 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/b3fbf52f34be Merge. - graal/com.oracle.graal.compiler.amd64/src/com/oracle/graal/compiler/amd64/AMD64MemoryPeephole.java - graal/com.oracle.graal.hotspot.amd64/src/com/oracle/graal/hotspot/amd64/AMD64HotSpotMemoryPeephole.java - graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/spi/MemoryArithmeticLIRLowerable.java - graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/spi/MemoryArithmeticLIRLowerer.java Changeset: 5ecbed00da23 Author: Thomas Wuerthinger Date: 2014-05-02 02:45 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/5ecbed00da23 Merge. - graal/com.oracle.truffle.api/src/com/oracle/truffle/api/instrument/impl/DefaultInstrument.java - graal/com.oracle.truffle.api/src/com/oracle/truffle/api/instrument/impl/InstrumentationNodeImpl.java Changeset: ff5cacf47b68 Author: Thomas Wuerthinger Date: 2014-05-03 21:46 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/ff5cacf47b68 Merge. - graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/AbstractMethodHandleNode.java - graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/MethodHandleInvokeBasicNode.java - graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/MethodHandleLinkToInterfaceNode.java - graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/MethodHandleLinkToSpecialNode.java - graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/MethodHandleLinkToStaticNode.java - graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/MethodHandleLinkToVirtualNode.java - graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/cfg/BlocksToDoubles.java - graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/util/NodesToDoubles.java - graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/InliningPhase.java - graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/InliningUtil.java - graal/com.oracle.graal.phases/src/com/oracle/graal/phases/graph/ComputeInliningRelevanceClosure.java - graal/com.oracle.graal.phases/src/com/oracle/graal/phases/graph/ComputeProbabilityClosure.java Changeset: a3f897fb3289 Author: Thomas Wuerthinger Date: 2014-05-05 22:18 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/a3f897fb3289 Merge. Changeset: c5ce68561b75 Author: Thomas Wuerthinger Date: 2014-05-06 04:07 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/c5ce68561b75 Fix stamp of LoweredAtomicReadAndWriteNode to only inherit kind from written value. ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/java/LoweredAtomicReadAndWriteNode.java Changeset: a51d48ac96d3 Author: Thomas Wuerthinger Date: 2014-05-06 04:14 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/a51d48ac96d3 Fix bug in CanonicalizerPhase that could remove fixed nodes with side effects in a corner case. ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/CanonicalizerPhase.java Changeset: a71192a503fe Author: Thomas Wuerthinger Date: 2014-05-06 11:34 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/a71192a503fe Fix stamp of LoweredAtomicReadAndWriteNode. ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/nodes/CompressionNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/java/LoweredAtomicReadAndWriteNode.java Changeset: fd47de8808fc Author: Thomas Wuerthinger Date: 2014-05-06 11:34 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/fd47de8808fc Merge. ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/nodes/CompressionNode.java Changeset: d6c80b8b414f Author: Bernhard Urban Date: 2014-05-06 12:14 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/d6c80b8b414f mx/projects: add sha1 checksums to external dependencies ! mx/projects Changeset: 4bd6ad45ee0a Author: Josef Eisl Date: 2014-05-05 11:10 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/4bd6ad45ee0a Encapsulate members of Loop. ! graal/com.oracle.graal.alloc/src/com/oracle/graal/alloc/ComputeBlockOrder.java ! graal/com.oracle.graal.baseline/src/com/oracle/graal/baseline/BaselineControlFlowGraph.java ! graal/com.oracle.graal.compiler.common/src/com/oracle/graal/compiler/common/cfg/Loop.java ! graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/NestedLoopTest.java ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/alloc/LinearScan.java ! graal/com.oracle.graal.java.decompiler/src/com/oracle/graal/java/decompiler/DecompilerLoopSimplify.java ! graal/com.oracle.graal.java.decompiler/src/com/oracle/graal/java/decompiler/block/DecompilerLoopBlock.java ! graal/com.oracle.graal.loop/src/com/oracle/graal/loop/LoopEx.java ! graal/com.oracle.graal.loop/src/com/oracle/graal/loop/LoopFragment.java ! graal/com.oracle.graal.loop/src/com/oracle/graal/loop/LoopFragmentWhole.java ! graal/com.oracle.graal.loop/src/com/oracle/graal/loop/LoopsData.java ! graal/com.oracle.graal.loop/src/com/oracle/graal/loop/phases/LoopSafepointEliminationPhase.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/cfg/Block.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/cfg/CFGVerifier.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/cfg/ControlFlowGraph.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/cfg/HIRLoop.java ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/DeoptimizationGroupingPhase.java ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/GuardLoweringPhase.java ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/ProfileCompiledMethodsPhase.java ! graal/com.oracle.graal.phases/src/com/oracle/graal/phases/graph/ReentrantBlockIterator.java ! graal/com.oracle.graal.phases/src/com/oracle/graal/phases/schedule/SchedulePhase.java ! graal/com.oracle.graal.printer/src/com/oracle/graal/printer/CFGPrinter.java ! graal/com.oracle.graal.truffle.test/src/com/oracle/graal/truffle/test/PartialEvaluationTest.java ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/PartialEvaluator.java ! graal/com.oracle.graal.virtual/src/com/oracle/graal/virtual/phases/ea/EffectsClosure.java Changeset: 706bb8271128 Author: Josef Eisl Date: 2014-04-24 09:55 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/706bb8271128 mx shortunittest: test jtt.loop.* and jtt.except.*. ! test/whitelist_shortunittest.txt Changeset: d897375b372a Author: Josef Eisl Date: 2014-04-24 13:38 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/d897375b372a SimpleCFGTest: check postOrder(). ! graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/SimpleCFGTest.java Changeset: 8117e9cadb48 Author: Josef Eisl Date: 2014-04-24 14:00 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/8117e9cadb48 Use List instead of an array in AbstractControlFlowGraph. ! graal/com.oracle.graal.baseline/src/com/oracle/graal/baseline/BaselineControlFlowGraph.java ! graal/com.oracle.graal.compiler.common/src/com/oracle/graal/compiler/common/cfg/AbstractControlFlowGraph.java ! graal/com.oracle.graal.compiler.common/src/com/oracle/graal/compiler/common/cfg/BlockMap.java ! graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/MemoryScheduleTest.java ! graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/SimpleCFGTest.java ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/GraalCompiler.java ! graal/com.oracle.graal.java.decompiler/src/com/oracle/graal/java/decompiler/Decompiler.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/cfg/CFGVerifier.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/cfg/ControlFlowGraph.java ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/ProfileCompiledMethodsPhase.java ! graal/com.oracle.graal.printer/src/com/oracle/graal/printer/BinaryGraphPrinter.java ! graal/com.oracle.graal.printer/src/com/oracle/graal/printer/CFGPrinterObserver.java Changeset: 9398d53c15b4 Author: Josef Eisl Date: 2014-04-28 16:48 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/9398d53c15b4 Add BaselineControlFlowGraph.compute() factory. ! graal/com.oracle.graal.baseline/src/com/oracle/graal/baseline/BaselineBytecodeParser.java ! graal/com.oracle.graal.baseline/src/com/oracle/graal/baseline/BaselineControlFlowGraph.java Changeset: c2f4d7dd944d Author: Josef Eisl Date: 2014-04-29 18:06 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/c2f4d7dd944d AbstractBlock: add setLoop. ! graal/com.oracle.graal.compiler.common/src/com/oracle/graal/compiler/common/cfg/AbstractBlock.java ! graal/com.oracle.graal.java/src/com/oracle/graal/java/BciBlockMapping.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/cfg/Block.java Changeset: 57131f2e001c Author: Josef Eisl Date: 2014-05-06 11:09 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/57131f2e001c BciBlockMapping: make loop information more accessible. ! graal/com.oracle.graal.java/src/com/oracle/graal/java/BciBlockMapping.java Changeset: 667c911b97c4 Author: Josef Eisl Date: 2014-05-06 11:10 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/667c911b97c4 BaselineControlFlowGraph: compute loop information. ! graal/com.oracle.graal.baseline/src/com/oracle/graal/baseline/BaselineControlFlowGraph.java Changeset: e46312e7ac27 Author: Josef Eisl Date: 2014-05-06 11:29 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/e46312e7ac27 BaselineBytecodeParser: add BciBlockMapping debug scope. ! graal/com.oracle.graal.baseline/src/com/oracle/graal/baseline/BaselineBytecodeParser.java Changeset: 0aa45f53abde Author: Josef Eisl Date: 2014-05-06 11:30 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/0aa45f53abde Baseline: re-enable simple loop tests. ! test/whitelist_baseline.txt From tom.deneau at amd.com Wed May 7 18:56:14 2014 From: tom.deneau at amd.com (Deneau, Tom) Date: Wed, 7 May 2014 18:56:14 +0000 Subject: Using a java port of fdlibm on the hsail backend Message-ID: Sending to Azeem representing the hotspot team and to the graal team... On the hsail backend, we would like to implement the various java.lang.Math routines and we need a solution that is completely hsail, since we can't call out to any host C routines. An easy solution for us would be to use a java implementation of java.lang.Math. I saw this mail back in the hotspot-dev archives describing a port of FDLIBM to Java which looked promising. http://mail.openjdk.java.net/pipermail/hotspot-dev/2009-August/001992.html I have tried the sin() routine out of this port in the hsail backend and it seems to work well functionally and performance-wise. Is there any problem with using this code as part of the graal project as @MethodSubstitutions? -- Tom Deneau From doug.simon at oracle.com Wed May 7 20:43:14 2014 From: doug.simon at oracle.com (Doug Simon) Date: Wed, 7 May 2014 22:43:14 +0200 Subject: Using a java port of fdlibm on the hsail backend In-Reply-To: References: Message-ID: Given that it was contributed under an OCA, I don?t see why we couldn?t use. However, otherwise with more legal knowledge can confirm that. I wonder why there was no interest shown in this contribution on the hotspot-dev mailing list. It makes me wonder if the Java port is really 100% compliant. -Doug On May 7, 2014, at 8:56 PM, Deneau, Tom wrote: > Sending to Azeem representing the hotspot team and to the graal team... > > On the hsail backend, we would like to implement the various java.lang.Math routines and we need a solution that is completely hsail, since we can't call out to any host C routines. An easy solution for us would be to use a java implementation of java.lang.Math. I saw this mail back in the hotspot-dev archives describing a port of FDLIBM to Java which looked promising. > > http://mail.openjdk.java.net/pipermail/hotspot-dev/2009-August/001992.html > > I have tried the sin() routine out of this port in the hsail backend and it seems to work well functionally and performance-wise. > > Is there any problem with using this code as part of the graal project as @MethodSubstitutions? > > -- Tom Deneau > From java at stefan-marr.de Wed May 7 21:23:16 2014 From: java at stefan-marr.de (Stefan Marr) Date: Wed, 7 May 2014 23:23:16 +0200 Subject: Again Trouble with Non-local Returns Message-ID: <1F5E8A64-2008-4347-BA03-90391813A218@stefan-marr.de> Dear all: I think, I might have identified one of the potential issues holding back TruffleSOM. A lucky guess let me to look into the performance of non-local returns once more. The key part of the micro benchmark looks like this: first: a = ( ^ self second: a ) second: a = ( ^ self third: a ) third: a = ( a value ) nlr = ( self first: [^ 1] ) Meaning, the #nlr method catches the non-local return of the value 1 and returns to the caller. The main problem I am seeing is that one of the involved call targets is triggering uncommon traps again. Think, we had a similar issue a while back, but I didn?t notice any regressions around non-local returns, so, I presume its a slightly different case this time. The uncommon trap looks like this: Uncommon trap occurred in com.oracle.graal.truffle.OptimizedCallTarget::callRoot (Graal: installed code has no name) (@0x0000000110318b2c) thread=6403 reason=null_assert|unreached0 action=none unloaded_class_index=-1 debug_id=0 Uncommon trap bci=0 pc=271682348, relative_pc=268, method=com.oracle.graal.truffle.OptimizedCallTarget.callRoot([Ljava/lang/Object;)Ljava/lang/Object;, debug_id=0 No speculation To reproduce you can execute the following: git clone --recursive https://github.com/SOM-st/TruffleSOM.git cd TruffleSOM ant mx --vm server vm -XX:+UnlockDiagnosticVMOptions -XX:+TraceDeoptimization -Xbootclasspath/a:build/classes:libs/truffle.jar som.vm.Universe -cp Smalltalk Examples/Benchmarks/BenchmarkHarness.som NonLocalReturn 20 0 1000 Any thoughts on the issue, could it be something in Graal? Thanks Stefan -- Stefan Marr INRIA Lille - Nord Europe http://stefan-marr.de/research/ From java at stefan-marr.de Wed May 7 22:35:39 2014 From: java at stefan-marr.de (Stefan Marr) Date: Thu, 8 May 2014 00:35:39 +0200 Subject: Again Trouble with Non-local Returns In-Reply-To: References: <1F5E8A64-2008-4347-BA03-90391813A218@stefan-marr.de> Message-ID: <5C6127E3-A75B-41A1-9886-231AE9FAB952@stefan-marr.de> Hi Gilles: On 08 May 2014, at 00:21, Gilles Duboscq wrote: > action=none indicates that the code is not invalidated. > Thus there is no chance to produce better code. This can be because a transferToInterpreter is used where a transferToInterpreterAndInvalidate was intended. Thanks, but that doesn?t seem to be it. I tried to replace all transferToInterpreter with transfer and invalidate, but to no avail. And, I also checked, the only case where I have them is in [Non]LocalVariableWriteNode, where they are used exactly like in JRuby and ZipPy. One thing that might be interesting, I think, the method that is relevant here has a SequenceNode, with an uninitialized node at the end. Specifically, #nlr has a node to read `self`, and return it at the end, but because of the non-local return, that?s never executed and never initialized. Might that confuse the system? Best regards Stefan > On 7 May 2014 23:26, "Stefan Marr" wrote: > Dear all: > > I think, I might have identified one of the potential issues holding back TruffleSOM. > > A lucky guess let me to look into the performance of non-local returns once more. > > The key part of the micro benchmark looks like this: > > first: a = ( ^ self second: a ) > second: a = ( ^ self third: a ) > third: a = ( a value ) > > nlr = ( > self first: [^ 1] > ) > > Meaning, the #nlr method catches the non-local return of the value 1 and returns to the caller. > > The main problem I am seeing is that one of the involved call targets is triggering uncommon traps again. > Think, we had a similar issue a while back, but I didn?t notice any regressions around non-local returns, so, I presume its a slightly different case this time. > > The uncommon trap looks like this: > > Uncommon trap occurred in com.oracle.graal.truffle.OptimizedCallTarget::callRoot (Graal: installed code has no name) (@0x0000000110318b2c) thread=6403 reason=null_assert|unreached0 action=none unloaded_class_index=-1 debug_id=0 > Uncommon trap bci=0 pc=271682348, relative_pc=268, method=com.oracle.graal.truffle.OptimizedCallTarget.callRoot([Ljava/lang/Object;)Ljava/lang/Object;, debug_id=0 > No speculation > > > To reproduce you can execute the following: > > git clone --recursive https://github.com/SOM-st/TruffleSOM.git > cd TruffleSOM > ant > mx --vm server vm -XX:+UnlockDiagnosticVMOptions -XX:+TraceDeoptimization -Xbootclasspath/a:build/classes:libs/truffle.jar som.vm.Universe -cp Smalltalk Examples/Benchmarks/BenchmarkHarness.som NonLocalReturn 20 0 1000 > > > Any thoughts on the issue, could it be something in Graal? > > Thanks > Stefan > > -- > Stefan Marr > INRIA Lille - Nord Europe > http://stefan-marr.de/research/ > > > -- Stefan Marr INRIA Lille - Nord Europe http://stefan-marr.de/research/ From andreas.woess at jku.at Wed May 7 23:52:47 2014 From: andreas.woess at jku.at (Andreas Woess) Date: Thu, 08 May 2014 01:52:47 +0200 Subject: Again Trouble with Non-local Returns In-Reply-To: <1F5E8A64-2008-4347-BA03-90391813A218@stefan-marr.de> References: <1F5E8A64-2008-4347-BA03-90391813A218@stefan-marr.de> Message-ID: <536AC74F.5080400@jku.at> Hi Stefan, I'm having trouble running this. After adding TestSuite/BasicInterpreterTests to the -cp, I get: > Exception in thread "main" java.lang.RuntimeException: Recheck > implementation, do we really need to convert here? and what's with the > receiver? - andreas On 2014-05-07 23:23, Stefan Marr wrote: > Dear all: > > I think, I might have identified one of the potential issues holding back TruffleSOM. > > A lucky guess let me to look into the performance of non-local returns once more. > > The key part of the micro benchmark looks like this: > > first: a = ( ^ self second: a ) > second: a = ( ^ self third: a ) > third: a = ( a value ) > > nlr = ( > self first: [^ 1] > ) > > Meaning, the #nlr method catches the non-local return of the value 1 and returns to the caller. > > The main problem I am seeing is that one of the involved call targets is triggering uncommon traps again. > Think, we had a similar issue a while back, but I didn?t notice any regressions around non-local returns, so, I presume its a slightly different case this time. > > The uncommon trap looks like this: > > Uncommon trap occurred in com.oracle.graal.truffle.OptimizedCallTarget::callRoot (Graal: installed code has no name) (@0x0000000110318b2c) thread=6403 reason=null_assert|unreached0 action=none unloaded_class_index=-1 debug_id=0 > Uncommon trap bci=0 pc=271682348, relative_pc=268, method=com.oracle.graal.truffle.OptimizedCallTarget.callRoot([Ljava/lang/Object;)Ljava/lang/Object;, debug_id=0 > No speculation > > > To reproduce you can execute the following: > > git clone --recursive https://github.com/SOM-st/TruffleSOM.git > cd TruffleSOM > ant > mx --vm server vm -XX:+UnlockDiagnosticVMOptions -XX:+TraceDeoptimization -Xbootclasspath/a:build/classes:libs/truffle.jar som.vm.Universe -cp Smalltalk Examples/Benchmarks/BenchmarkHarness.som NonLocalReturn 20 0 1000 > > > Any thoughts on the issue, could it be something in Graal? > > Thanks > Stefan > From doug.simon at oracle.com Thu May 8 01:00:06 2014 From: doug.simon at oracle.com (doug.simon at oracle.com) Date: Thu, 08 May 2014 01:00:06 +0000 Subject: hg: graal/graal: 8 new changesets Message-ID: <201405080100.s4810HM1009234@aojmv0008> Changeset: 217c721b1ee1 Author: Doug Simon Date: 2014-05-07 11:44 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/217c721b1ee1 adding missing header ! src/gpu/hsail/vm/gpu_hsail_Frame.hpp Changeset: 9d456ffc6120 Author: Doug Simon Date: 2014-05-07 11:51 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/9d456ffc6120 HSAIL: fixed Windows build ! graal/com.oracle.graal.hotspot.hsail/src/com/oracle/graal/hotspot/hsail/HSAILHotSpotBackend.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/HotSpotVMConfig.java ! src/gpu/hsail/vm/gpu_hsail.hpp ! src/gpu/hsail/vm/gpu_hsail_Frame.hpp ! src/gpu/hsail/vm/vmStructs_hsail.hpp Changeset: 240083895914 Author: Lukas Stadler Date: 2014-05-07 15:31 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/240083895914 simplification in FixedNodeProbabilityCache ! graal/com.oracle.graal.phases/src/com/oracle/graal/phases/graph/FixedNodeProbabilityCache.java Changeset: cab432461b8b Author: Tom Rodriguez Date: 2014-05-07 10:58 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/cab432461b8b use NodeClass.Position when matching graphs, rearrange MatchableNode annotations, improve error reporting ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/gen/NodeLIRBuilder.java - graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/match/GraalMatchableNodes.java - graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/match/MatchNodeAdapter.java ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/match/MatchPattern.java ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/match/MatchProcessor.java ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/match/MatchStatement.java ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/match/MatchStatementSet.java ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/match/MatchableNode.java - graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/match/MatchableNodeImport.java ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/match/MatchableNodes.java ! graal/com.oracle.graal.hotspot.amd64/src/com/oracle/graal/hotspot/amd64/AMD64HotSpotNodeLIRBuilder.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/HotSpotNodeLIRBuilder.java - graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/nodes/HotSpotMatchableNodes.java Changeset: 23dbc25b10a8 Author: Tom Rodriguez Date: 2014-05-07 11:54 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/23dbc25b10a8 share position computations in MatchStatements ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/match/MatchProcessor.java Changeset: ff05eeb654d4 Author: Thomas Wuerthinger Date: 2014-05-07 23:58 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/ff05eeb654d4 Added write barriers for LoweredAtomicReadAndWriteNode. ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/phases/WriteBarrierAdditionPhase.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/java/LoweredAtomicReadAndWriteNode.java Changeset: 3882866b6ff9 Author: Thomas Wuerthinger Date: 2014-05-07 23:58 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/3882866b6ff9 Merge. - graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/match/GraalMatchableNodes.java - graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/match/MatchNodeAdapter.java - graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/match/MatchableNodeImport.java - graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/nodes/HotSpotMatchableNodes.java Changeset: 33cedbce5b23 Author: Doug Simon Date: 2014-05-08 02:22 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/33cedbce5b23 added CollectionsProvider and NodeCollectionsProvider and replaced (almost) all allocations of IdentityHashMaps to go through these providers + graal/com.oracle.graal.api.collections/src/com/oracle/graal/api/collections/CollectionsProvider.java + graal/com.oracle.graal.api.collections/src/com/oracle/graal/api/collections/DefaultCollectionsProvider.java ! graal/com.oracle.graal.api.runtime/src/com/oracle/graal/api/runtime/Graal.java ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/gen/DebugInfoBuilder.java + graal/com.oracle.graal.graph/src/com/oracle/graal/graph/DefaultNodeCollectionsProvider.java ! graal/com.oracle.graal.graph/src/com/oracle/graal/graph/NodeClass.java + graal/com.oracle.graal.graph/src/com/oracle/graal/graph/NodeCollectionsProvider.java + graal/com.oracle.graal.graph/src/com/oracle/graal/graph/util/CollectionsAccess.java ! graal/com.oracle.graal.hotspot.server/src/com/oracle/graal/hotspot/server/ReplacingStreams.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/HotSpotGraalRuntime.java ! graal/com.oracle.graal.loop/src/com/oracle/graal/loop/InductionVariables.java ! graal/com.oracle.graal.loop/src/com/oracle/graal/loop/LoopFragmentInside.java ! graal/com.oracle.graal.loop/src/com/oracle/graal/loop/LoopsData.java ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/ConditionalEliminationPhase.java ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/FloatingReadPhase.java ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/GuardLoweringPhase.java ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/cfs/EquationalReasoner.java ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/cfs/State.java ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/inlining/ComputeInliningRelevance.java ! graal/com.oracle.graal.phases/src/com/oracle/graal/phases/graph/FixedNodeProbabilityCache.java ! graal/com.oracle.graal.phases/src/com/oracle/graal/phases/graph/PostOrderNodeIterator.java ! graal/com.oracle.graal.phases/src/com/oracle/graal/phases/graph/ReentrantBlockIterator.java ! graal/com.oracle.graal.phases/src/com/oracle/graal/phases/graph/ReentrantNodeIterator.java ! graal/com.oracle.graal.phases/src/com/oracle/graal/phases/util/GraphOrder.java ! graal/com.oracle.graal.replacements/src/com/oracle/graal/replacements/SnippetTemplate.java ! graal/com.oracle.graal.truffle.hotspot/src/com/oracle/graal/truffle/hotspot/HotSpotTruffleRuntime.java ! graal/com.oracle.graal.virtual/src/com/oracle/graal/virtual/phases/ea/EffectsClosure.java ! graal/com.oracle.graal.virtual/src/com/oracle/graal/virtual/phases/ea/PartialEscapeBlockState.java ! graal/com.oracle.graal.virtual/src/com/oracle/graal/virtual/phases/ea/PartialEscapeClosure.java ! graal/com.oracle.graal.virtual/src/com/oracle/graal/virtual/phases/ea/VirtualUtil.java ! mx/projects From christian.thalinger at oracle.com Thu May 8 02:35:54 2014 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Wed, 7 May 2014 16:35:54 -1000 Subject: Using a java port of fdlibm on the hsail backend In-Reply-To: References: Message-ID: On May 7, 2014, at 10:43 AM, Doug Simon wrote: > Given that it was contributed under an OCA, I don?t see why we couldn?t use. However, otherwise with more legal knowledge can confirm that. > > I wonder why there was no interest shown in this contribution on the hotspot-dev mailing list. It makes me wonder if the Java port is really 100% compliant. This was a long time ago and I?m also curious why there was no interest. Anyway, I filed a tracking bug because we didn?t have one: [#JDK-8042716] Java port of fdlibm 5.3 to java.lang.StrictMath - Java Bug System > > -Doug > > On May 7, 2014, at 8:56 PM, Deneau, Tom wrote: > >> Sending to Azeem representing the hotspot team and to the graal team... >> >> On the hsail backend, we would like to implement the various java.lang.Math routines and we need a solution that is completely hsail, since we can't call out to any host C routines. An easy solution for us would be to use a java implementation of java.lang.Math. I saw this mail back in the hotspot-dev archives describing a port of FDLIBM to Java which looked promising. >> >> http://mail.openjdk.java.net/pipermail/hotspot-dev/2009-August/001992.html >> >> I have tried the sin() routine out of this port in the hsail backend and it seems to work well functionally and performance-wise. >> >> Is there any problem with using this code as part of the graal project as @MethodSubstitutions? >> >> -- Tom Deneau >> > From christian.thalinger at oracle.com Thu May 8 02:35:54 2014 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Wed, 7 May 2014 16:35:54 -1000 Subject: Using a java port of fdlibm on the hsail backend In-Reply-To: References: Message-ID: On May 7, 2014, at 10:43 AM, Doug Simon wrote: > Given that it was contributed under an OCA, I don?t see why we couldn?t use. However, otherwise with more legal knowledge can confirm that. > > I wonder why there was no interest shown in this contribution on the hotspot-dev mailing list. It makes me wonder if the Java port is really 100% compliant. This was a long time ago and I?m also curious why there was no interest. Anyway, I filed a tracking bug because we didn?t have one: [#JDK-8042716] Java port of fdlibm 5.3 to java.lang.StrictMath - Java Bug System > > -Doug > > On May 7, 2014, at 8:56 PM, Deneau, Tom wrote: > >> Sending to Azeem representing the hotspot team and to the graal team... >> >> On the hsail backend, we would like to implement the various java.lang.Math routines and we need a solution that is completely hsail, since we can't call out to any host C routines. An easy solution for us would be to use a java implementation of java.lang.Math. I saw this mail back in the hotspot-dev archives describing a port of FDLIBM to Java which looked promising. >> >> http://mail.openjdk.java.net/pipermail/hotspot-dev/2009-August/001992.html >> >> I have tried the sin() routine out of this port in the hsail backend and it seems to work well functionally and performance-wise. >> >> Is there any problem with using this code as part of the graal project as @MethodSubstitutions? >> >> -- Tom Deneau >> > From andreas.woess at jku.at Thu May 8 02:59:15 2014 From: andreas.woess at jku.at (Andreas Woess) Date: Thu, 08 May 2014 04:59:15 +0200 Subject: Again Trouble with Non-local Returns In-Reply-To: References: <1F5E8A64-2008-4347-BA03-90391813A218@stefan-marr.de> <536AC74F.5080400@jku.at> Message-ID: <536AF303.1080607@jku.at> (my bad, I thought a "git checkout master" in core-lib would do, too. thanks) I couldn't tell for sure now, but the deoptimization is likely coming from an UnexpectedResultException. Anyway, the actual problem is another. You can observe it when you add these two options -Dtruffle.TraceRewrites=true -Dtruffle.DetailedRewriteReasons=true: We see a ValueNonePrimGenericNode that constantly rewrites itself to ValueNonePrimGenericNode (sic). Obviously, there's something with this. On top of it all, the actual value is an SBlock, so we don't get an UnsupportedSpecializationException, too. But what are we even doing in the generic node, if we only ever saw SBlock (the only supported type)? Let's have a look the code: > public void executeEvaluatedVoid(VirtualFrame frameValue, Object > receiverValueEvaluated) { > Object[] receiverValue; > try { > receiverValue = TYPES.expectObjectArray(receiverValueEvaluated); > } catch (UnexpectedResultException ex) { > executeAndSpecialize0(2, frameValue, ex.getResult(), "Expected > receiverValue instanceof Object[]"); > return; > } > this.executePreEvaluated(frameValue, receiverValue); > } For some reason, the DSL has picked executePreEvaluated here and stubbornly tries to cast the receiver to its parameter type, Object[]. My dumb and easy quickfix was to rename UnaryExpressionNode.executePreEvaluated to something that doesn't start with "execute". After: > public void executeEvaluatedVoid(VirtualFrame frameValue, Object > receiverValueEvaluated) { > Object receiverValue = receiverValueEvaluated; > this.executeEvaluated(frameValue, receiverValue); > } I'll assign a bug to Christian Humer. - andreas On 2014-05-08 02:31, Stefan Marr wrote: > Is the core-lib sub module updated? git submodules update or something > like that should do it. > > On Thursday, May 8, 2014, Andreas Woess > wrote: > > Hi Stefan, > > I'm having trouble running this. After adding > TestSuite/BasicInterpreterTests to the -cp, I get: > > Exception in thread "main" java.lang.RuntimeException: Recheck > > implementation, do we really need to convert here? and what's > with the > > receiver? > > - andreas > > On 2014-05-07 23:23, Stefan Marr wrote: > > Dear all: > > > > I think, I might have identified one of the potential issues > holding back TruffleSOM. > > > > A lucky guess let me to look into the performance of non-local > returns once more. > > > > The key part of the micro benchmark looks like this: > > > > first: a = ( ^ self second: a ) > > second: a = ( ^ self third: a ) > > third: a = ( a value ) > > > > nlr = ( > > self first: [^ 1] > > ) > > > > Meaning, the #nlr method catches the non-local return of the > value 1 and returns to the caller. > > > > The main problem I am seeing is that one of the involved call > targets is triggering uncommon traps again. > > Think, we had a similar issue a while back, but I didn?t notice > any regressions around non-local returns, so, I presume its a > slightly different case this time. > > > > The uncommon trap looks like this: > > > > Uncommon trap occurred in > com.oracle.graal.truffle.OptimizedCallTarget::callRoot (Graal: > installed code has no name) (@0x0000000110318b2c) thread=6403 > reason=null_assert|unreached0 action=none unloaded_class_index=-1 > debug_id=0 > > Uncommon trap bci=0 pc=271682348, relative_pc=268, > method=com.oracle.graal.truffle.OptimizedCallTarget.callRoot([Ljava/lang/Object;)Ljava/lang/Object;, > debug_id=0 > > No speculation > > > > > > To reproduce you can execute the following: > > > > git clone --recursive https://github.com/SOM-st/TruffleSOM.git > > cd TruffleSOM > > ant > > mx --vm server vm -XX:+UnlockDiagnosticVMOptions > -XX:+TraceDeoptimization > -Xbootclasspath/a:build/classes:libs/truffle.jar som.vm.Universe > -cp Smalltalk Examples/Benchmarks/BenchmarkHarness.som > NonLocalReturn 20 0 1000 > > > > > > Any thoughts on the issue, could it be something in Graal? > > > > Thanks > > Stefan > > > From tom.rodriguez at oracle.com Thu May 8 03:41:46 2014 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Wed, 7 May 2014 20:41:46 -0700 Subject: Using a java port of fdlibm on the hsail backend In-Reply-To: References: Message-ID: <1B912CB8-72AD-4BB4-A0C7-4C198D296575@oracle.com> On May 7, 2014, at 7:35 PM, Christian Thalinger wrote: > > On May 7, 2014, at 10:43 AM, Doug Simon wrote: > >> Given that it was contributed under an OCA, I don?t see why we couldn?t use. However, otherwise with more legal knowledge can confirm that. >> >> I wonder why there was no interest shown in this contribution on the hotspot-dev mailing list. It makes me wonder if the Java port is really 100% compliant. > > This was a long time ago and I?m also curious why there was no interest. From the hotspot side fdlibm is a solved problem. Replacing it with a Java version might be better in some ways but it perturbs the universe without much clear upside. It also introduces maintenance concerns since fdlibm is fairly broadly used but the Java version probably isn?t. Joe Darcy would be the one to ask about the quality of the Java port. If it were ever adopted by the JDK he would also likely be the one to do it. tom > Anyway, I filed a tracking bug because we didn?t have one: > > [#JDK-8042716] Java port of fdlibm 5.3 to java.lang.StrictMath - Java Bug System > >> >> -Doug >> >> On May 7, 2014, at 8:56 PM, Deneau, Tom wrote: >> >>> Sending to Azeem representing the hotspot team and to the graal team... >>> >>> On the hsail backend, we would like to implement the various java.lang.Math routines and we need a solution that is completely hsail, since we can't call out to any host C routines. An easy solution for us would be to use a java implementation of java.lang.Math. I saw this mail back in the hotspot-dev archives describing a port of FDLIBM to Java which looked promising. >>> >>> http://mail.openjdk.java.net/pipermail/hotspot-dev/2009-August/001992.html >>> >>> I have tried the sin() routine out of this port in the hsail backend and it seems to work well functionally and performance-wise. >>> >>> Is there any problem with using this code as part of the graal project as @MethodSubstitutions? >>> >>> -- Tom Deneau >>> >> > From miguel.m.garcia at oracle.com Thu May 8 08:45:05 2014 From: miguel.m.garcia at oracle.com (Miguel Garcia Gutierrez) Date: Thu, 8 May 2014 01:45:05 -0700 (PDT) Subject: state tracking by PostOrderNodeIterator, holding to states longer than needed Message-ID: <76a7eeb3-0ad0-467e-abac-4af87a214368@default> Hi, I was thinking about ways to lower the memory-footprint of ConditionalEliminationPhase and FlowSensitiveReductionPhase. Both rely on PostOrderNodeIterator that tracks program-state on a per program-point basis. PostOrderNodeIterator is used to realize a single-pass visit of nodes, as opposed to multi-pass as in iterative dataflow. (Actually, the "single-pass" property is not intrinsic to PostOrderNodeIterator, but determined by the subclass of MergeableState in use: an override of merge() that always returns true makes PostOderNodeIterator perform a single-pass visit). Back to lowering memory-footprint. PostOrderNodeIterator tracks states in a map from FixedNode to state, a map that is used to grab states for loop begins and ends, for merge forward-ends, and for the predecessor of begin-nodes. That map is cleared only at the end of the single-pass visit. However, some entries are accessed for a last time well before that. For example, after all forward-ends of a merge have been visited, which entries won't be ever looked up again? I'm trying to visualize the above, comments are welcome! Miguel From lukas.stadler at oracle.com Thu May 8 10:04:28 2014 From: lukas.stadler at oracle.com (Lukas Stadler) Date: Thu, 8 May 2014 12:04:28 +0200 Subject: state tracking by PostOrderNodeIterator, holding to states longer than needed In-Reply-To: <76a7eeb3-0ad0-467e-abac-4af87a214368@default> References: <76a7eeb3-0ad0-467e-abac-4af87a214368@default> Message-ID: In general, single compilations (and especially single compilation phases) don?t last very long. Or at least they shouldn?t :-) Thus the fact that something is still referenced, and therefore cannot be collected, is not an issue. However, never removing states that aren?t needed any more makes the hash map grow bigger and bigger? So we could remove them as soon as they aren?t used any more. Some investigations into whether this is a win would be good. Going further, it might be a good idea to look some more at how the nodeStates map is used: - it holds the states for merge and loop ends - it holds the state for ControlSplit successors that have been queued For the latter case, the map isn?t really needed at all, since we could have a second queue with the states for queued nodes (or use the more hacky way of making the queue a Queue and always putting node and state into it). With those entries out of the way, the map should be created lazily (if end nodes are encountered or by querying graph.hasNode(MergeNode.class)). Some of this could also be applied to the other iterators. There?s definitely room for improvement. On the other hand, it?s a relatively simple and easy to understand piece of code, which is also a good thing? so we should only optimize it if it really is a problem. - Lukas On 08 May 2014, at 10:45, Miguel Garcia Gutierrez wrote: > Hi, > > I was thinking about ways to lower the memory-footprint of ConditionalEliminationPhase and FlowSensitiveReductionPhase. > > Both rely on PostOrderNodeIterator that tracks program-state on a per program-point basis. PostOrderNodeIterator is used to realize a single-pass visit of nodes, as opposed to multi-pass as in iterative dataflow. > > (Actually, the "single-pass" property is not intrinsic to PostOrderNodeIterator, but determined by the subclass of MergeableState in use: an override of merge() that always returns true makes PostOderNodeIterator perform a single-pass visit). > > Back to lowering memory-footprint. > > PostOrderNodeIterator tracks states in a map from FixedNode to state, a map that is used to grab states for loop begins and ends, for merge forward-ends, and for the predecessor of begin-nodes. > > That map is cleared only at the end of the single-pass visit. However, some entries are accessed for a last time well before that. For example, after all forward-ends of a merge have been visited, which entries won't be ever looked up again? > > I'm trying to visualize the above, comments are welcome! > > > Miguel From azeem.jiva at oracle.com Thu May 8 13:23:44 2014 From: azeem.jiva at oracle.com (Azeem Jiva) Date: Thu, 8 May 2014 06:23:44 -0700 Subject: Using a java port of fdlibm on the hsail backend In-Reply-To: <1B912CB8-72AD-4BB4-A0C7-4C198D296575@oracle.com> References: <1B912CB8-72AD-4BB4-A0C7-4C198D296575@oracle.com> Message-ID: Joe and I have talked about this on and off for quite some time. I?ve CCed him to see what his current thoughts are on this. On May 7, 2014, at 8:41 PM, Tom Rodriguez wrote: > > On May 7, 2014, at 7:35 PM, Christian Thalinger wrote: > >> >> On May 7, 2014, at 10:43 AM, Doug Simon wrote: >> >>> Given that it was contributed under an OCA, I don?t see why we couldn?t use. However, otherwise with more legal knowledge can confirm that. >>> >>> I wonder why there was no interest shown in this contribution on the hotspot-dev mailing list. It makes me wonder if the Java port is really 100% compliant. >> >> This was a long time ago and I?m also curious why there was no interest. > > From the hotspot side fdlibm is a solved problem. Replacing it with a Java version might be better in some ways but it perturbs the universe without much clear upside. It also introduces maintenance concerns since fdlibm is fairly broadly used but the Java version probably isn?t. > > Joe Darcy would be the one to ask about the quality of the Java port. If it were ever adopted by the JDK he would also likely be the one to do it. > > tom > >> Anyway, I filed a tracking bug because we didn?t have one: >> >> [#JDK-8042716] Java port of fdlibm 5.3 to java.lang.StrictMath - Java Bug System >> >>> >>> -Doug >>> >>> On May 7, 2014, at 8:56 PM, Deneau, Tom wrote: >>> >>>> Sending to Azeem representing the hotspot team and to the graal team... >>>> >>>> On the hsail backend, we would like to implement the various java.lang.Math routines and we need a solution that is completely hsail, since we can't call out to any host C routines. An easy solution for us would be to use a java implementation of java.lang.Math. I saw this mail back in the hotspot-dev archives describing a port of FDLIBM to Java which looked promising. >>>> >>>> http://mail.openjdk.java.net/pipermail/hotspot-dev/2009-August/001992.html >>>> >>>> I have tried the sin() routine out of this port in the hsail backend and it seems to work well functionally and performance-wise. >>>> >>>> Is there any problem with using this code as part of the graal project as @MethodSubstitutions? >>>> >>>> -- Tom Deneau >>>> >>> >> > From java at stefan-marr.de Thu May 8 13:42:55 2014 From: java at stefan-marr.de (Stefan Marr) Date: Thu, 8 May 2014 15:42:55 +0200 Subject: Again Trouble with Non-local Returns In-Reply-To: <536AF303.1080607@jku.at> References: <1F5E8A64-2008-4347-BA03-90391813A218@stefan-marr.de> <536AC74F.5080400@jku.at> <536AF303.1080607@jku.at> Message-ID: <9ADC931C-A573-4488-9DC9-E06F7013259C@stefan-marr.de> Hi: On 08 May 2014, at 04:59, Andreas Woess wrote: > I couldn't tell for sure now, but the deoptimization is likely coming > from an UnexpectedResultException. Anyway, the actual problem is > another. You can observe it when you add these two options > -Dtruffle.TraceRewrites=true -Dtruffle.DetailedRewriteReasons=true: > We see a ValueNonePrimGenericNode that constantly rewrites itself to > ValueNonePrimGenericNode (sic). Sorry for wasting your time with trivial stuff :( Was to excited to have a small test case that I forgot to check for rewriting issues. > For some reason, the DSL has picked executePreEvaluated here and > stubbornly tries to cast the receiver to its parameter type, Object[]. > My dumb and easy quickfix was to rename > UnaryExpressionNode.executePreEvaluated to something that doesn't start > with "execute". After: And, I even ran into issues with executePreEvaluated before. Oh well, I renamed it now. Unfortunately, the change didn?t have any impact on overall performance. But the test case is fixed, thanks! Best regards Stefan -- Stefan Marr INRIA Lille - Nord Europe http://stefan-marr.de/research/ From christian.thalinger at oracle.com Thu May 8 22:16:43 2014 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Thu, 8 May 2014 12:16:43 -1000 Subject: Using a java port of fdlibm on the hsail backend In-Reply-To: <536BFF1D.4050504@oracle.com> References: <1B912CB8-72AD-4BB4-A0C7-4C198D296575@oracle.com> <536BFF1D.4050504@oracle.com> Message-ID: <9A4E5670-FDCB-4DB2-BA29-EDCCAB30746F@oracle.com> On May 8, 2014, at 12:03 PM, Joe Darcy wrote: > Hello, > > The C code in fdlibm is written in a very particular style. I don't trust many people to do the port; I happen to be one of the people I trust to do this ;-) > > Reviewing someone else's port of this code would be an effort on par with doing the port myself, so I prefer to do the port myself. I intend to do this port in 9 (this time for real!). Hear! Hear! Thank you, I really appreciate this. If there is anything I can help with, let me know. > Having this code in Java will reduce our exposure to C compiler vagaries when upgrade compilers or port Java to new platforms. (The C code in fdlibm uses long / double aliasing and thus runs afoul of most optimizers.) > > HTH, > > -Joe > > On 05/08/2014 06:23 AM, Azeem Jiva wrote: >> Joe and I have talked about this on and off for quite some time. I?ve CCed him to see what his current thoughts are on this. >> >> >> On May 7, 2014, at 8:41 PM, Tom Rodriguez wrote: >> >>> On May 7, 2014, at 7:35 PM, Christian Thalinger wrote: >>> >>>> On May 7, 2014, at 10:43 AM, Doug Simon wrote: >>>> >>>>> Given that it was contributed under an OCA, I don?t see why we couldn?t use. However, otherwise with more legal knowledge can confirm that. >>>>> >>>>> I wonder why there was no interest shown in this contribution on the hotspot-dev mailing list. It makes me wonder if the Java port is really 100% compliant. >>>> This was a long time ago and I?m also curious why there was no interest. >>> From the hotspot side fdlibm is a solved problem. Replacing it with a Java version might be better in some ways but it perturbs the universe without much clear upside. It also introduces maintenance concerns since fdlibm is fairly broadly used but the Java version probably isn?t. >>> >>> Joe Darcy would be the one to ask about the quality of the Java port. If it were ever adopted by the JDK he would also likely be the one to do it. >>> >>> tom >>> >>>> Anyway, I filed a tracking bug because we didn?t have one: >>>> >>>> [#JDK-8042716] Java port of fdlibm 5.3 to java.lang.StrictMath - Java Bug System >>>> >>>>> -Doug >>>>> >>>>> On May 7, 2014, at 8:56 PM, Deneau, Tom wrote: >>>>> >>>>>> Sending to Azeem representing the hotspot team and to the graal team... >>>>>> >>>>>> On the hsail backend, we would like to implement the various java.lang.Math routines and we need a solution that is completely hsail, since we can't call out to any host C routines. An easy solution for us would be to use a java implementation of java.lang.Math. I saw this mail back in the hotspot-dev archives describing a port of FDLIBM to Java which looked promising. >>>>>> >>>>>> http://mail.openjdk.java.net/pipermail/hotspot-dev/2009-August/001992.html >>>>>> >>>>>> I have tried the sin() routine out of this port in the hsail backend and it seems to work well functionally and performance-wise. >>>>>> >>>>>> Is there any problem with using this code as part of the graal project as @MethodSubstitutions? >>>>>> >>>>>> -- Tom Deneau >>>>>> > From tom.deneau at amd.com Thu May 8 22:59:19 2014 From: tom.deneau at amd.com (Deneau, Tom) Date: Thu, 8 May 2014 22:59:19 +0000 Subject: Using a java port of fdlibm on the hsail backend In-Reply-To: <9A4E5670-FDCB-4DB2-BA29-EDCCAB30746F@oracle.com> References: <1B912CB8-72AD-4BB4-A0C7-4C198D296575@oracle.com> <536BFF1D.4050504@oracle.com> <9A4E5670-FDCB-4DB2-BA29-EDCCAB30746F@oracle.com> Message-ID: Thanks for the response, Joe. We might experiment with the existing Java port that I mentioned, just to have something to use in the hsail backend while we are waiting for the official java port that you will do for Java 9. So far I have only used the sin routine from this java port and in the small amount of testing I did, the result was within 1 ulp of the standard java.lang.Math.sin result. (this was whether I ran the java version on the cpu or on the hsail gpu). -- Tom > -----Original Message----- > From: Christian Thalinger [mailto:christian.thalinger at oracle.com] > Sent: Thursday, May 08, 2014 5:17 PM > To: Joe Darcy > Cc: Azeem Jiva; Tom Rodriguez; Douglas Simon; graal- > dev at openjdk.java.net; Deneau, Tom > Subject: Re: Using a java port of fdlibm on the hsail backend > > > On May 8, 2014, at 12:03 PM, Joe Darcy wrote: > > > Hello, > > > > The C code in fdlibm is written in a very particular style. I don't > trust many people to do the port; I happen to be one of the people I > trust to do this ;-) > > > > Reviewing someone else's port of this code would be an effort on par > with doing the port myself, so I prefer to do the port myself. I intend > to do this port in 9 (this time for real!). > > Hear! Hear! Thank you, I really appreciate this. If there is anything > I can help with, let me know. > > > Having this code in Java will reduce our exposure to C compiler > vagaries when upgrade compilers or port Java to new platforms. (The C > code in fdlibm uses long / double aliasing and thus runs afoul of most > optimizers.) > > > > HTH, > > > > -Joe > > > > On 05/08/2014 06:23 AM, Azeem Jiva wrote: > >> Joe and I have talked about this on and off for quite some time. > I've CCed him to see what his current thoughts are on this. > >> > >> > >> On May 7, 2014, at 8:41 PM, Tom Rodriguez > wrote: > >> > >>> On May 7, 2014, at 7:35 PM, Christian Thalinger > wrote: > >>> > >>>> On May 7, 2014, at 10:43 AM, Doug Simon > wrote: > >>>> > >>>>> Given that it was contributed under an OCA, I don't see why we > couldn't use. However, otherwise with more legal knowledge can confirm > that. > >>>>> > >>>>> I wonder why there was no interest shown in this contribution on > the hotspot-dev mailing list. It makes me wonder if the Java port is > really 100% compliant. > >>>> This was a long time ago and I'm also curious why there was no > interest. > >>> From the hotspot side fdlibm is a solved problem. Replacing it with > a Java version might be better in some ways but it perturbs the universe > without much clear upside. It also introduces maintenance concerns > since fdlibm is fairly broadly used but the Java version probably isn't. > >>> > >>> Joe Darcy would be the one to ask about the quality of the Java > port. If it were ever adopted by the JDK he would also likely be the > one to do it. > >>> > >>> tom > >>> > >>>> Anyway, I filed a tracking bug because we didn't have one: > >>>> > >>>> [#JDK-8042716] Java port of fdlibm 5.3 to java.lang.StrictMath - > Java Bug System > >>>> > >>>>> -Doug > >>>>> > >>>>> On May 7, 2014, at 8:56 PM, Deneau, Tom > wrote: > >>>>> > >>>>>> Sending to Azeem representing the hotspot team and to the graal > team... > >>>>>> > >>>>>> On the hsail backend, we would like to implement the various > java.lang.Math routines and we need a solution that is completely hsail, > since we can't call out to any host C routines. An easy solution for > us would be to use a java implementation of java.lang.Math. I saw this > mail back in the hotspot-dev archives describing a port of FDLIBM to > Java which looked promising. > >>>>>> > >>>>>> http://mail.openjdk.java.net/pipermail/hotspot-dev/2009- > August/001992.html > >>>>>> > >>>>>> I have tried the sin() routine out of this port in the hsail > backend and it seems to work well functionally and performance-wise. > >>>>>> > >>>>>> Is there any problem with using this code as part of the graal > project as @MethodSubstitutions? > >>>>>> > >>>>>> -- Tom Deneau > >>>>>> > > From doug.simon at oracle.com Fri May 9 01:00:07 2014 From: doug.simon at oracle.com (doug.simon at oracle.com) Date: Fri, 09 May 2014 01:00:07 +0000 Subject: hg: graal/graal: 16 new changesets Message-ID: <201405090100.s4910T5W019071@aojmv0008> Changeset: 385df32e0fd6 Author: Lukas Stadler Date: 2014-05-08 09:52 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/385df32e0fd6 moved ExceptionObjectNode lowering back to runtime independent part ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/DefaultHotSpotLoweringProvider.java - graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/nodes/LoadExceptionObjectNode.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/LoadExceptionObjectSnippets.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/java/ExceptionObjectNode.java + graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/java/LoadExceptionObjectNode.java Changeset: b3e84bf5718b Author: Josef Eisl Date: 2014-05-08 14:02 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/b3e84bf5718b Remove unused member in PTXNodeLIRBuilder. ! graal/com.oracle.graal.compiler.ptx/src/com/oracle/graal/compiler/ptx/PTXNodeLIRBuilder.java Changeset: cf994cc23b54 Author: Josef Eisl Date: 2014-05-08 11:35 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/cf994cc23b54 Move emitNullCheck from NodeLIRBuilderTool to LIRGeneratorTool. ! graal/com.oracle.graal.compiler.amd64/src/com/oracle/graal/compiler/amd64/AMD64NodeLIRBuilder.java ! graal/com.oracle.graal.compiler.hsail/src/com/oracle/graal/compiler/hsail/HSAILNodeLIRBuilder.java ! graal/com.oracle.graal.compiler.ptx/src/com/oracle/graal/compiler/ptx/PTXLIRGenerator.java ! graal/com.oracle.graal.compiler.ptx/src/com/oracle/graal/compiler/ptx/PTXNodeLIRBuilder.java ! graal/com.oracle.graal.compiler.sparc/src/com/oracle/graal/compiler/sparc/SPARCNodeLIRBuilder.java ! graal/com.oracle.graal.hotspot.amd64/src/com/oracle/graal/hotspot/amd64/AMD64HotSpotLIRGenerator.java ! graal/com.oracle.graal.hotspot.hsail/src/com/oracle/graal/hotspot/hsail/HSAILHotSpotLIRGenerator.java ! graal/com.oracle.graal.hotspot.sparc/src/com/oracle/graal/hotspot/sparc/SPARCHotSpotLIRGenerator.java ! graal/com.oracle.graal.lir/src/com/oracle/graal/lir/gen/LIRGeneratorTool.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/extended/NullCheckNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/spi/NodeLIRBuilderTool.java Changeset: 8c19ffc672fd Author: Josef Eisl Date: 2014-05-08 11:52 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/8c19ffc672fd mx unittest: add support for regular expressions. ! mx/mx_graal.py Changeset: 6cc1c153e5f1 Author: Josef Eisl Date: 2014-05-06 20:09 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/6cc1c153e5f1 BytecodeLIRBuilder: add getArrayLengthOffset(). ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/gen/BytecodeLIRBuilder.java ! graal/com.oracle.graal.hotspot.amd64/src/com/oracle/graal/hotspot/amd64/AMD64HotSpotBytecodeLIRBuilder.java Changeset: 8a66b661ed49 Author: Josef Eisl Date: 2014-05-06 20:10 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/8a66b661ed49 BaselineBytecodeParser: initial genArrayLength(). ! graal/com.oracle.graal.baseline/src/com/oracle/graal/baseline/BaselineBytecodeParser.java Changeset: b8bb78808495 Author: Josef Eisl Date: 2014-05-07 20:05 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/b8bb78808495 AbstractFrameStateBuilder enable access to locks. ! graal/com.oracle.graal.java/src/com/oracle/graal/java/AbstractFrameStateBuilder.java ! graal/com.oracle.graal.java/src/com/oracle/graal/java/HIRFrameStateBuilder.java Changeset: 9440ab398f49 Author: Josef Eisl Date: 2014-05-07 20:06 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/9440ab398f49 BaselineCompiler: implement genArrayLength(). ! graal/com.oracle.graal.baseline/src/com/oracle/graal/baseline/BaselineBytecodeParser.java Changeset: db5e9c70d829 Author: Josef Eisl Date: 2014-05-08 14:57 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/db5e9c70d829 Make BC_arraylength unit test only check for arraylength. ! graal/com.oracle.graal.jtt/src/com/oracle/graal/jtt/bytecode/BC_arraylength.java Changeset: 0fc035104370 Author: Josef Eisl Date: 2014-05-08 10:04 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/0fc035104370 Baseline: add support for getstatic. ! graal/com.oracle.graal.baseline/src/com/oracle/graal/baseline/BaselineBytecodeParser.java ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/gen/BytecodeLIRBuilder.java ! graal/com.oracle.graal.hotspot.amd64/src/com/oracle/graal/hotspot/amd64/AMD64HotSpotBytecodeLIRBuilder.java ! test/whitelist_baseline.txt Changeset: de3dca7cc6fd Author: Josef Eisl Date: 2014-05-08 15:00 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/de3dca7cc6fd BaselineCompiler: add arraylength test. ! test/whitelist_baseline.txt Changeset: 5699bb48a436 Author: Miguel Garcia Date: 2014-05-08 16:44 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/5699bb48a436 [flow-sensitive] consolidating nullness-tracking in typeRefinements ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/cfs/State.java ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/cfs/Witness.java Changeset: a3b0ecef8a15 Author: Thomas Wuerthinger Date: 2014-05-08 22:53 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/a3b0ecef8a15 Truffle: Provide default implementation on non-Graal VMs for stack trace functionality. ! graal/com.oracle.graal.truffle.hotspot/src/com/oracle/graal/truffle/hotspot/HotSpotTruffleRuntime.java ! graal/com.oracle.truffle.api/src/com/oracle/truffle/api/impl/DefaultCallTarget.java ! graal/com.oracle.truffle.api/src/com/oracle/truffle/api/impl/DefaultDirectCallNode.java ! graal/com.oracle.truffle.api/src/com/oracle/truffle/api/impl/DefaultTruffleRuntime.java ! graal/com.oracle.truffle.sl/src/com/oracle/truffle/sl/builtins/SLStackTraceBuiltin.java Changeset: 6b7c5c7d0d81 Author: Thomas Wuerthinger Date: 2014-05-08 22:53 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/6b7c5c7d0d81 Merge. Changeset: f2988cdf41ee Author: Thomas Wuerthinger Date: 2014-05-08 22:56 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/f2988cdf41ee Small addition to changelog. ! CHANGELOG.md Changeset: 10732e1421ee Author: Thomas Wuerthinger Date: 2014-05-09 01:47 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/10732e1421ee changelog: graal-0.3 ! .hgtags ! CHANGELOG.md From joe.darcy at oracle.com Thu May 8 22:03:09 2014 From: joe.darcy at oracle.com (Joe Darcy) Date: Thu, 08 May 2014 15:03:09 -0700 Subject: Using a java port of fdlibm on the hsail backend In-Reply-To: References: <1B912CB8-72AD-4BB4-A0C7-4C198D296575@oracle.com> Message-ID: <536BFF1D.4050504@oracle.com> Hello, The C code in fdlibm is written in a very particular style. I don't trust many people to do the port; I happen to be one of the people I trust to do this ;-) Reviewing someone else's port of this code would be an effort on par with doing the port myself, so I prefer to do the port myself. I intend to do this port in 9 (this time for real!). Having this code in Java will reduce our exposure to C compiler vagaries when upgrade compilers or port Java to new platforms. (The C code in fdlibm uses long / double aliasing and thus runs afoul of most optimizers.) HTH, -Joe On 05/08/2014 06:23 AM, Azeem Jiva wrote: > Joe and I have talked about this on and off for quite some time. I?ve CCed him to see what his current thoughts are on this. > > > On May 7, 2014, at 8:41 PM, Tom Rodriguez wrote: > >> On May 7, 2014, at 7:35 PM, Christian Thalinger wrote: >> >>> On May 7, 2014, at 10:43 AM, Doug Simon wrote: >>> >>>> Given that it was contributed under an OCA, I don?t see why we couldn?t use. However, otherwise with more legal knowledge can confirm that. >>>> >>>> I wonder why there was no interest shown in this contribution on the hotspot-dev mailing list. It makes me wonder if the Java port is really 100% compliant. >>> This was a long time ago and I?m also curious why there was no interest. >> From the hotspot side fdlibm is a solved problem. Replacing it with a Java version might be better in some ways but it perturbs the universe without much clear upside. It also introduces maintenance concerns since fdlibm is fairly broadly used but the Java version probably isn?t. >> >> Joe Darcy would be the one to ask about the quality of the Java port. If it were ever adopted by the JDK he would also likely be the one to do it. >> >> tom >> >>> Anyway, I filed a tracking bug because we didn?t have one: >>> >>> [#JDK-8042716] Java port of fdlibm 5.3 to java.lang.StrictMath - Java Bug System >>> >>>> -Doug >>>> >>>> On May 7, 2014, at 8:56 PM, Deneau, Tom wrote: >>>> >>>>> Sending to Azeem representing the hotspot team and to the graal team... >>>>> >>>>> On the hsail backend, we would like to implement the various java.lang.Math routines and we need a solution that is completely hsail, since we can't call out to any host C routines. An easy solution for us would be to use a java implementation of java.lang.Math. I saw this mail back in the hotspot-dev archives describing a port of FDLIBM to Java which looked promising. >>>>> >>>>> http://mail.openjdk.java.net/pipermail/hotspot-dev/2009-August/001992.html >>>>> >>>>> I have tried the sin() routine out of this port in the hsail backend and it seems to work well functionally and performance-wise. >>>>> >>>>> Is there any problem with using this code as part of the graal project as @MethodSubstitutions? >>>>> >>>>> -- Tom Deneau >>>>> From jules_gosnell at yahoo.com Fri May 9 19:47:15 2014 From: jules_gosnell at yahoo.com (Julian Gosnell) Date: Fri, 9 May 2014 12:47:15 -0700 (PDT) Subject: Clojure/Graal/Okra - Real world problem - advice sought - long ! Message-ID: <1399664835.66660.YahooMailNeo@web122403.mail.ne1.yahoo.com> Guys, I've been thinking about this for a while, have implemented it once, thought about it a bit more and decided that that best way to get the best solution is to put it out there and see what comes back :-) The problem: Efficiently map a function over a Clojure vector. The background: A Clojure vector is (roughly) a Trie of object[array]s with a branching factor of 32 with a nice api wrapped around it permitting constant time random access etc... A Clojure Function is a Java Class/Method... My current thinking: Define a Branch and Leaf Okra Kernel. The Leaf Kernel is used to apply the function to an input Object[32] at the bottom of the Trie putting the results into an output Object[32] that it has been given. The Branch Kernel is used at all other nodes in the Trie. It receives an input Object[32][32]... and enqueues 32 x Branch/Leaf Kernels on an input Object[32]... allocating a new output Object[32]... for each one. It puts the results in another output Object[32][32]... passed to it from the Branch Kernel above. You start with a Branch Kernel at the root of the Trie and recurse to the bottom and back up, resulting in an output Trie that mirrors the structure of its input. I have some demo code in Clojure that implements this sequentially and in parallel on fork/join - but not yet on Okra - I know I am jumping the gun in terms of where the impl is, but it is fun to think about this stuff. I like this solution because not only the function is run in parallel, but the allocation of output arrays on the way down and their recombination into an output Trie on the way up is also done in parallel. The whole thing is simple, elegant and extremely fast. Now the problem. The Trie branching factor is 32. The wavefront size on my A10-7850K is 64 (as I understand it I have 4 x cpu cores + 8 compute-unit x 64 gpu cores). How should I arrange my work in order to help Okra queue/schedule it as efficiently as possible against the GPU ? Should I just enqueue lots of the same kernel with a wavefront of 32 and expect Okra to pair them off onto available 64-way compute-units, translating work-ids as and when needed ? Can I ask a Kernel to do more that 64 pieces of work in parallel and expect Okra to similarly split the Kernel over as many available 64-way compute-units as are required to get the work done ? Or should I go to lengths to ensure that I present the work to Okra in mouthfuls of size 64 ? I have been wondering about encapsulating pairs of Object[32] in another object which supports their sequential reading and writing as if a single Object[64] and handing these of to Okra for execution. I'd be very interested to hear what you guys think about this, thanks for your time, Jules From tom.deneau at amd.com Fri May 9 20:38:56 2014 From: tom.deneau at amd.com (Deneau, Tom) Date: Fri, 9 May 2014 20:38:56 +0000 Subject: Memory allocation in HSAIL In-Reply-To: <39D8C101-5569-4315-A455-83C9FCF5AA01@oracle.com> References: <52C71D6F-E8A2-4BDD-95CE-BC7B62964955@oracle.com> <39D8C101-5569-4315-A455-83C9FCF5AA01@oracle.com> Message-ID: Doug -- I found a bug introduced in the recent hsail-deopt-windows-build-fixes webrev (which won't show up in the junits, it requires the maximum # of concurrent workitems to actually deopt ). http://cr.openjdk.java.net/~tdeneau/graal-webrevs/webrev-hsail-deopt-savearea-cleanup In addition, I tried implementing a few more of your suggestions. * I didn't see a good way to get rid of the operator new for the outer HSAILDeoptimizationInfo. I guess I could have hidden it behind a new_HSAILDeoptimizationInfo static routine. (I noticed that new_nmethod eventually called operator new for nmethod) * I did remove the ResourceObj declaration for HSAILDeoptimizationInfo since as you said it didn't make sense when we were allocating from the heap. * cleaned up some NPEs when UseHSAILDeoptimization was turned off. Also marked some junit tests not to run in that case. We still get some failures if we run the junits with UseHSAILDeoptimization off. I understand these, they are based on the wide net we cast to decide if allocation is being used for a particular graph. See HSAILHotSpotBackend.java line 491. Couldn't think of a quick way to fix this but we should. * some other small cleanups * I didn't see how to use the CodeBlob::allocation_size() so I didn't stick that in. I did make the HSAILDeoptimizationInfo end in a pointer so that the end of the header/ start of the save area was 8-byte aligned. -- Tom > -----Original Message----- > From: Doug Simon [mailto:doug.simon at oracle.com] > Sent: Wednesday, May 07, 2014 6:27 AM > To: Deneau, Tom > Cc: Gilles Duboscq; Christian Wirth > Subject: Re: Memory allocation in HSAIL > > I'm pushing these changes now... > > On May 7, 2014, at 12:22 AM, Deneau, Tom wrote: > > > OK -- > > > > http://cr.openjdk.java.net/~tdeneau/graal-webrevs/webrev-hsail-deopt-w > > indows-build-fixes/webrev/ > > > > is a small step in the direction below, mainly to solve the windows > build issue. > > It still passes the junits on linux. > > > > I actually started going a little beyond the specific windows build > > issue but decided to postpone those fixes until later. > > > > -- Tom > > > > > >> -----Original Message----- > >> From: Doug Simon [mailto:doug.simon at oracle.com] > >> Sent: Tuesday, May 06, 2014 12:56 AM > >> To: Deneau, Tom > >> Cc: Gilles Duboscq; Christian Wirth > >> Subject: Re: Memory allocation in HSAIL > >> > >> > >> On May 6, 2014, at 1:15 AM, Deneau, Tom wrote: > >> > >>> Doug -- > >>> > >>> I've been tied up in meetings today... > >>> Not sure what your timeframe is, but I can send you a solution that > >> builds on windows. > >> > >> That would be great. > >> > >>> But it doesn't address some of the other issues below, including how > >> the HSAILDeoptimizationInfo is allocated. > >> > >> Ok - that is not urgent. > >> > >>> I don't currently have a way to actually run the hsail backend on > >> windows but I can test building there and running elsewhere. > >> > >> That's fine. The main thing is to have the build work on Windows. > >> > >> Thanks. > >> > >> -Doug > >> > >>>> -----Original Message----- > >>>> From: Doug Simon [mailto:doug.simon at oracle.com] > >>>> Sent: Monday, May 05, 2014 3:52 PM > >>>> To: Deneau, Tom > >>>> Cc: Gilles Duboscq; Christian Wirth > >>>> Subject: Re: Memory allocation in HSAIL > >>>> > >>>> Something like the pattern in nmethod::new_nmethod should work. > >>>> > >>>> -Doug > >>>> > >>>> On May 5, 2014, at 10:42 PM, Deneau, Tom > wrote: > >>>> > >>>>> Doug -- > >>>>> > >>>>> Can you point me to an example of how you want the > >>>> HSAILDeoptimizationInfo allocation to be structured? > >>>>> In particular, for invoking the new operator for ResourceObj. > >>>>> > >>>>> -- Tom > >>>>> > >>>>> > >>>>>> -----Original Message----- > >>>>>> From: Doug Simon [mailto:doug.simon at oracle.com] > >>>>>> Sent: Monday, May 05, 2014 5:51 AM > >>>>>> To: Deneau, Tom > >>>>>> Cc: Gilles Duboscq; Christian Wirth > >>>>>> Subject: Memory allocation in HSAIL > >>>>>> > >>>>>> Hi Tom, > >>>>>> > >>>>>> The way memory is currently allocated for HSAIL deoptimization > >>>>>> info departs somewhat from the way HotSpot manages variable > >>>>>> size/embedded data structures. One immediate side effect of this > >>>>>> is that your recent changes broke the Windows build with the > >>>>>> following compiler > >>>> warnings: > >>>>>> > >>>>>> \src\gpu\hsail\vm\gpu_hsail_Frame.hpp(15): error C2220: warning > >>>>>> treated as error - no 'object' file generated [c:\oracl > >>>>>> \src\gpu\hsail\vm\gpu_hsail_Frame.hpp(15): warning C4200: > >>>>>> nonstandard extension used : zero-sized array in struct/union > >>>>>> > >>>>>> Gilles and I have looked at the code and have the following > >>>>>> recommendations: > >>>>>> > >>>>>> Since HSAILDeoptimizationInfo subclasses ResourceObj, it should > >>>>>> not override the new operator. Instead, at the allocation site it > >>>>>> should do whatever size computation is necessary (probably in a > >>>>>> static method of > >>>>>> HSAILDeoptimizationInfo) and call one of the existing new > >>>>>> operators defined by ResourceObj. At is currently stands, it's > >>>>>> strange to have a ResourceObj subclass that allocates directly > >>>>>> from the C > >> heap. > >>>>>> > >>>>>> The bytesPerSaveArea is computed information that does not need > >>>>>> to be stored in a _bytesPerSaveArea. Same goes for _deopt_span. > >>>>>> > >>>>>> Since both HSAILKernelDeoptimization and HSAILFrame are really > >>>>>> overlays on a HSAILDeoptimizationInfo, they should both use > >>>> VALUE_OBJ_CLASS_SPEC. > >>>>>> For example: > >>>>>> > >>>>>> class HSAILKernelDeoptimization VALUE_OBJ_CLASS_SPEC { ... } > >>>>>> > >>>>>> The _num_s_regs, _num_d_regs and _num_stack_slots value are fixed > >>>>>> for a given HSAILDeoptimizationInfo and do not need to be stored > >>>>>> in each HSAILFrame (I can't even see where they are currently > >> initialized). > >>>>>> > >>>>>> You should probably think about alignment for the objects > >>>>>> embedded in a HSAILDeoptimizationInfo. See > >>>>>> CodeBlob::allocation_size() for inspiration. > >>>>>> > >>>>>> The HSAILFrame::_save_area and > >>>>>> HSAILDeoptimizationInfo::_deopt_save_states fields should go > away. > >>>>>> Accessing them should be done like the access to the objects > >>>>>> embedded in an nmethod (e.g. nmethod::scopes_pcs_begin()). > >>>>>> > >>>>>> The highest priority is to fix the Windows build. > >>>>>> > >>>>>> -Doug > >>> > > From doug.simon at oracle.com Sat May 10 01:00:06 2014 From: doug.simon at oracle.com (doug.simon at oracle.com) Date: Sat, 10 May 2014 01:00:06 +0000 Subject: hg: graal/graal: 20 new changesets Message-ID: <201405100100.s4A10YGl026239@aojmv0008> Changeset: 857ab1f388a5 Author: Bernhard Urban Date: 2014-05-09 08:29 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/857ab1f388a5 backout 10732e1421ee ! .hgtags ! CHANGELOG.md Changeset: 9535eccd2a11 Author: Bernhard Urban Date: 2014-05-09 09:49 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/9535eccd2a11 changelog: graal-0.3 ! CHANGELOG.md Changeset: 1b5b1471b3f3 Author: Bernhard Urban Date: 2014-05-09 09:49 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/1b5b1471b3f3 Added tag graal-0.3 for changeset 9535eccd2a11 ! .hgtags Changeset: 9a5b5a5b2246 Author: Lukas Stadler Date: 2014-05-09 14:45 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/9a5b5a5b2246 more accurately determine if a IntegerStamp is illegal ! graal/com.oracle.graal.compiler.common/src/com/oracle/graal/compiler/common/type/IntegerStamp.java Changeset: 01bce59c2749 Author: Lukas Stadler Date: 2014-05-09 15:52 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/01bce59c2749 test for integer stamp join ! graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/TypeSystemTest.java ! graal/com.oracle.graal.nodes.test/src/com/oracle/graal/nodes/test/IntegerStampTest.java Changeset: 5696af217fe2 Author: Andreas Woess Date: 2014-05-09 15:53 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/5696af217fe2 Truffle: getCallNode() should return null for call target frames ! graal/com.oracle.graal.truffle.hotspot/src/com/oracle/graal/truffle/hotspot/HotSpotFrameInstance.java Changeset: d79501a10e5b Author: Andreas Woess Date: 2014-05-09 15:55 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/d79501a10e5b Truffle: remove obsolete HotSpotFrameInstance.getTargetCallTarget() ! graal/com.oracle.graal.truffle.hotspot/src/com/oracle/graal/truffle/hotspot/HotSpotFrameInstance.java Changeset: cb2f3c49deb2 Author: Bernhard Urban Date: 2014-05-09 13:21 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/cb2f3c49deb2 mx unittest: compile junitwrapper with right classpath ! mx/mx_graal.py Changeset: 0c0b479903bb Author: Bernhard Urban Date: 2014-05-09 13:56 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/0c0b479903bb mx trufflejar: use distribution feature of mx instead (`mx archive @TRUFFLE') ! mx/mx_graal.py ! mx/projects Changeset: 406a94c03ffa Author: Bernhard Urban Date: 2014-05-09 16:11 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/406a94c03ffa truffle distrubtion: move dsl processor in a separated jar, such that it can be a build-time only dependency ! mx/mx_graal.py ! mx/projects ! mxtool/mx.py Changeset: 24aa5dbcf92d Author: Bernhard Urban Date: 2014-05-09 14:24 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/24aa5dbcf92d truffle distrubtions: generate source jar ! mx/projects Changeset: c3869fe3d917 Author: Bernhard Urban Date: 2014-05-09 15:30 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/c3869fe3d917 mx clean: make it more reliable on windows ! mxtool/mx.py Changeset: ce201bb843b4 Author: Bernhard Urban Date: 2014-05-09 16:43 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/ce201bb843b4 mx clean: try to change permission if deletion fails on windows ! mx/mx_graal.py Changeset: 0dc0926cf0d8 Author: Doug Simon Date: 2014-05-09 17:59 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/0dc0926cf0d8 added -G:TrackMemUse for measuring memory usage within scopes ! graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/FlowSenReduTest.java ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/GraalDebugConfig.java ! graal/com.oracle.graal.debug/src/com/oracle/graal/debug/Debug.java ! graal/com.oracle.graal.debug/src/com/oracle/graal/debug/DebugConfig.java + graal/com.oracle.graal.debug/src/com/oracle/graal/debug/DebugMemUseTracker.java ! graal/com.oracle.graal.debug/src/com/oracle/graal/debug/DebugTimer.java ! graal/com.oracle.graal.debug/src/com/oracle/graal/debug/DelegatingDebugConfig.java ! graal/com.oracle.graal.debug/src/com/oracle/graal/debug/internal/DebugScope.java + graal/com.oracle.graal.debug/src/com/oracle/graal/debug/internal/MemUseTrackerImpl.java ! graal/com.oracle.graal.hotspot.test/src/com/oracle/graal/hotspot/test/WriteBarrierVerificationTest.java ! graal/com.oracle.graal.phases/src/com/oracle/graal/phases/BasePhase.java ! graal/com.oracle.graal.printer/src/com/oracle/graal/printer/DebugEnvironment.java Changeset: 063ec2920d21 Author: Doug Simon Date: 2014-05-09 18:46 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/063ec2920d21 made Graal runtime initialization in hosted mode lazy ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/bridge/VMToCompiler.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/bridge/VMToCompilerImpl.java ! src/cpu/sparc/vm/graalCodeInstaller_sparc.cpp ! src/cpu/x86/vm/graalCodeInstaller_x86.cpp ! src/gpu/hsail/vm/gpu_hsail.cpp ! src/gpu/ptx/vm/gpu_ptx.cpp ! src/share/vm/classfile/vmSymbols.hpp ! src/share/vm/graal/graalCodeInstaller.cpp ! src/share/vm/graal/graalCompiler.cpp ! src/share/vm/graal/graalCompiler.hpp ! src/share/vm/graal/graalRuntime.cpp ! src/share/vm/graal/graalRuntime.hpp ! src/share/vm/graal/graalVMToCompiler.cpp ! src/share/vm/graal/graalVMToCompiler.hpp ! src/share/vm/prims/jni.cpp ! src/share/vm/runtime/deoptimization.cpp ! src/share/vm/runtime/java.cpp ! src/share/vm/runtime/javaCalls.cpp ! src/share/vm/runtime/mutexLocker.cpp ! src/share/vm/runtime/mutexLocker.hpp Changeset: d331b7c3d7c4 Author: Miguel Garcia Date: 2014-05-09 16:22 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/d331b7c3d7c4 [single-pass-iter] start of evolution towards a node iterator less memory-hungry ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/ConditionalEliminationPhase.java ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/ValueAnchorCleanupPhase.java ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/cfs/BaseReduction.java + graal/com.oracle.graal.phases/src/com/oracle/graal/phases/graph/SinglePassNodeIterator.java Changeset: 56ab99b480af Author: Miguel Garcia Date: 2014-05-09 16:50 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/56ab99b480af [single-pass-iter] lifecycle of single-pass iterators ! graal/com.oracle.graal.phases/src/com/oracle/graal/phases/graph/SinglePassNodeIterator.java Changeset: 4d5b1e7a4d93 Author: Miguel Garcia Date: 2014-05-09 17:33 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/4d5b1e7a4d93 [single-pass-iter] early pruning of state map, visit a whole method ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/ConditionalEliminationPhase.java ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/ValueAnchorCleanupPhase.java ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/cfs/BaseReduction.java ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/cfs/CheckCastReduction.java ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/cfs/FixedGuardReduction.java ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/cfs/FlowSensitiveReduction.java ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/cfs/GuardingPiReduction.java ! graal/com.oracle.graal.phases/src/com/oracle/graal/phases/graph/SinglePassNodeIterator.java Changeset: 642bd083a5cc Author: Miguel Garcia Date: 2014-05-09 20:05 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/642bd083a5cc [single-pass-iter] offloading tracking successor-pre-states to nodeQueue ! graal/com.oracle.graal.phases/src/com/oracle/graal/phases/graph/SinglePassNodeIterator.java Changeset: cad72380191d Author: Miguel Garcia Date: 2014-05-09 20:22 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/cad72380191d Merge From jules_gosnell at yahoo.com Sat May 10 17:51:10 2014 From: jules_gosnell at yahoo.com (Jules Gosnell) Date: Sat, 10 May 2014 18:51:10 +0100 Subject: Clojure/Graal/Okra - Real world problem - advice sought - long ! (reformatted) Message-ID: <536E670E.9050505@yahoo.com> Guys, I've been thinking about this for a while, have implemented it once, thought about it a bit more and decided that that best way to get the best solution is to put it out there and see what comes back :-) The problem: Efficiently map a function over a Clojure vector. The background: A Clojure vector is (roughly) a Trie of object[array]s with a branching factor of 32 and a nice api wrapped around it permitting constant time random access etc... A Clojure Function is a Java Class/Method... My current thinking: Define a Branch and Leaf Okra Kernel. The Leaf Kernel is used to apply the function to an input Object[32] at the bottom of the Trie putting the results into an output Object[32] that it has been given. The Branch Kernel is used at all other nodes in the Trie. It receives an input Object[32][32]... and enqueues 32 x Branch/Leaf Kernels on an input Object[32]... allocating a new output Object[32]... for each one. It puts the results in another output Object[32][32]... passed to it from the Branch Kernel above. You start with a Branch Kernel at the root of the Trie and recurse to the bottom and back up, resulting in an output Trie that mirrors the structure of its input. I have some demo code in Clojure that implements this sequentially and in parallel on fork/join - but not yet on Okra - I know that I am jumping the gun in terms of what Graal is able to compile to HSAIL at the moment, but it is fun to think about this stuff. I like this solution because not only the function is run in parallel, but the allocation of output arrays on the way down and their recombination into an output Trie on the way up is also done in parallel. The whole thing is simple, elegant and extremely fast. Now the problem. The Trie branching factor is 32. The wavefront size on my A10-7850K is 64 (as I understand it I have 4 x cpu cores + 8 compute-unit x 64 gpu cores). How should I arrange my work in order to help Okra queue/schedule it as efficiently as possible against the GPU ? Should I just enqueue lots of the same kernel with a wavefront of 32 and expect Okra to pair them off onto available 64-way compute-units, translating work-ids as and when needed ? Can I ask a Kernel to do more that 64 pieces of work in parallel and expect Okra to similarly split the Kernel over as many available 64-way compute-units as are required to get the work done ? Or should I go to lengths to ensure that I present the work to Okra in mouthfuls of size 64 ? I have been wondering about encapsulating pairs of Object[32] in another object which supports their sequential reading and writing as if a single Object[64] and handing these of to Okra for execution. I'd be very interested to hear what you guys think about this, thanks for your time, Jules From doug.simon at oracle.com Sun May 11 01:00:06 2014 From: doug.simon at oracle.com (doug.simon at oracle.com) Date: Sun, 11 May 2014 01:00:06 +0000 Subject: hg: graal/graal: [single-pass-iter] additional documentation and assertions Message-ID: <201405110100.s4B10AxM020865@aojmv0008> Changeset: 9a63ccd66007 Author: Miguel Garcia Date: 2014-05-10 15:37 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/9a63ccd66007 [single-pass-iter] additional documentation and assertions ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/ConditionalEliminationPhase.java ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/cfs/FlowSensitiveReduction.java ! graal/com.oracle.graal.phases/src/com/oracle/graal/phases/graph/SinglePassNodeIterator.java From doug.simon at oracle.com Sun May 11 13:37:48 2014 From: doug.simon at oracle.com (doug.simon at oracle.com) Date: Sun, 11 May 2014 13:37:48 +0000 Subject: hg: graal/graal: 2 new changesets Message-ID: <201405111337.s4BDbqWh013913@aojmv0008> Changeset: ddb3ef30fcd2 Author: Doug Simon Date: 2014-05-11 13:43 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/ddb3ef30fcd2 fixed livelock issue introduced by 063ec2920d21 ! src/share/vm/graal/graalRuntime.cpp ! src/share/vm/graal/graalRuntime.hpp Changeset: 1e63e4b5ef6d Author: Doug Simon Date: 2014-05-11 13:43 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/1e63e4b5ef6d fixed initialization issue caused by 063ec2920d21 ! graal/com.oracle.graal.printer/src/com/oracle/graal/printer/DebugEnvironment.java From doug.simon at oracle.com Mon May 12 01:00:05 2014 From: doug.simon at oracle.com (doug.simon at oracle.com) Date: Mon, 12 May 2014 01:00:05 +0000 Subject: hg: graal/graal: fixed assertion position and documented critical class initialization dependency Message-ID: <201405120100.s4C107cO022621@aojmv0008> Changeset: 55977f9fa56f Author: Doug Simon Date: 2014-05-11 22:00 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/55977f9fa56f fixed assertion position and documented critical class initialization dependency ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/HotSpotOptions.java ! graal/com.oracle.graal.printer/src/com/oracle/graal/printer/DebugEnvironment.java From mahroug.said at gmail.com Sun May 11 22:47:09 2014 From: mahroug.said at gmail.com (macbook) Date: Sun, 11 May 2014 23:47:09 +0100 Subject: Problem in Graal instalation Message-ID: <928A9622-B236-4666-872B-105F7057723D@gmail.com> Hello, I'm a Tunisian student, I'm studying the Grall and Truffle projects. Since 3 days I'm trying to install Grall on Ubuntu os, but It fail after building (mx build : seen here https://wiki.openjdk.java.net/display/Graal/Instructions) The problem is seen when I installing the graal VM : Excluding com.oracle.graal.api.meta (JDK with compliance level 1.8 not available) Excluding com.oracle.graal.replacements.test (JDK with compliance level 1.8 not available) hp at ubuntu:~/Bureau$ mx vm Error occurred during initialization of VM Unable to load native library: /home/hp/Bureau/graal/jdk1.7.0_51/product/jre/lib/amd64/libjava.so: symbol JVM_SetProtectionDomain, version SUNWprivate_1.1 not defined in file libjvm.so with link time reference I tried also to install it on OS X, but if fail also. I installed 5 version of oracle jdk 7, and jdk 8. Can you help me please to resolve this problem. Best regards Said From duboscq at ssw.jku.at Mon May 12 09:42:21 2014 From: duboscq at ssw.jku.at (Gilles Duboscq) Date: Mon, 12 May 2014 11:42:21 +0200 Subject: Problem in Graal instalation In-Reply-To: <928A9622-B236-4666-872B-105F7057723D@gmail.com> References: <928A9622-B236-4666-872B-105F7057723D@gmail.com> Message-ID: Hello Said, The Java version you are specifying as JAVA_HOME seems to be 1.7. It has to be 1.8. You can set JAVA_HOME in the mx/env file. For example: JAVA_HOME=/usr/java/jdk1.8.0 EXTRA_JAVA_HOMES=/usr/java/jdk1.7.0_51 You need to adapt those path to the correct location for your machine. We currently accept 1.7 as the main java version but, as you experienced, this is confusing. I think we should specify 1.8 as the minimum supported version. -Gilles On Mon, May 12, 2014 at 12:47 AM, macbook wrote: > Hello, > I'm a Tunisian student, I'm studying the Grall and Truffle projects. > Since 3 days I'm trying to install Grall on Ubuntu os, but It fail after building (mx build : seen here https://wiki.openjdk.java.net/display/Graal/Instructions) > The problem is seen when I installing the graal VM : > > > Excluding com.oracle.graal.api.meta (JDK with compliance level 1.8 not available) > Excluding com.oracle.graal.replacements.test (JDK with compliance level 1.8 not available) > hp at ubuntu:~/Bureau$ mx vm > Error occurred during initialization of VM > Unable to load native library: /home/hp/Bureau/graal/jdk1.7.0_51/product/jre/lib/amd64/libjava.so: symbol JVM_SetProtectionDomain, version SUNWprivate_1.1 not defined in file libjvm.so with link time reference > > > I tried also to install it on OS X, but if fail also. > I installed 5 version of oracle jdk 7, and jdk 8. > Can you help me please to resolve this problem. > Best regards > Said From tom.deneau at amd.com Mon May 12 19:35:04 2014 From: tom.deneau at amd.com (Deneau, Tom) Date: Mon, 12 May 2014 19:35:04 +0000 Subject: HotspotProfilingInfo for xxx-morphic inlining Message-ID: I am interested in getting HotspotProfilingInfo for a method that we will be compiling in the HSAIL backend. (after running the method on the cpu first to get profiling info) When I get to HotSpotResolvedJavaMethod.getProfilingInfo, the metaspaceMethodData is always 0 and methodData is always null, so we get DefaultProfilingInfo instead. I am using -XX:TypeProfileWidth=3 -G:MegamorphicInliningMinMethodProbability=0.001 and my OptimisticOptimizations include UseTypedCheckInlining and UseTypeCheckHints. Is there some hotspot or graal option I am missing? From yudi.zheng at usi.ch Mon May 12 20:10:52 2014 From: yudi.zheng at usi.ch (Yudi Zheng) Date: Mon, 12 May 2014 20:10:52 +0000 Subject: buggy behavior in AMD64NodeLIRBuilder.emitCompareBranchMemory Message-ID: Hi, 1. A minor problem is that the default TypeProfileWidth is 2, resulting in lots of megamorphic-inlining with a probability of 60~70% in many cases, instead of polymorphic-inlining. 2. When running with -XX:TypeProfileWidth=8, I observed buggy behavior: > mx vm -XX:+BootstrapGraal -XX:TypeProfileWidth=8 -version Bootstrapping Graal.......................com.oracle.graal.compiler.common.GraalInternalError: should not reach here at lir instruction: B192 at 1350 LCMP (address: [rax|j + 24], y: long[33286881400|0x7c00d8078]{HotSpotType}) kind: long [B0, B2, B3, B5, B6, B8, B416, B419, B9, B11, B12, B14, B16, B17, B19, B21, B413, B23, B25, B26, B28, B29, B31, B409, B412, B32, B33, B35, B36, B38, B39, B41, B42, B44, B45, B47, B49, B50, B52, B54, B53, B55, B56, B57, B59, B61, B63, B65, B66, B67, B69, B70, B72, B74, B77, B79, B80, B94, B96, B98, B99, B101, B102, B103, B104, B107, B108, B109, B110, B113, B114, B115, B117, B118, B120, B122, B125, B127, B128, B129, B143, B145, B147, B148, B160, B126, B119, B149, B116, B130, B132, B153, B133, B136, B138, B139, B141, B142, B137, B140, B150, B134, B168, B105, B166, B171, B180, B181, B183, B186, B188, B190, B192, B194, B196, B198, B200, B197, B161, B170, B179, B177, B178, B184, B403, B78, B193, B202, B203, B204, B209, B211, B212, B214, B399, B401, B215, B216, B218, B220, B222, B397, B71, B208, B205, B206, B100, B195, B201, B187, B189, B68, B191, B199, B219, B224, B226, B228, B229, B231, B233, B394, B395, B221, B223, B82, B84, B173, B174, B154, B155, B51, B48, B232, B235, B239, B393, B236, B238, B234, B85, B87, B89, B90, B92, B93, B88, B240, B242, B284, B286, B288, B289, B291, B294, B296, B297, B299, B300, B302, B304, B307, B308, B310, B311, B313, B315, B317, B318, B320, B322, B323, B325, B326, B327, B343, B345, B346, B348, B349, B351, B354, B356, B357, B358, B360, B362, B364, B365, B367, B369, B372, B368, B373, B83, B371, B46, B352, B237, B287, B316, B330, B332, B333, B335, B336, B337, B244, B246, B247, B249, B250, B252, B254, B257, B258, B260, B261, B263, B265, B267, B268, B270, B273, B275, B276, B370, B266, B207, B285, B314, B264, B91, B355, B295, B245, B339, B384, B301, B306, B251, B256, B390, B391, B281, B283, B167, B282, B347, B382, B344, B30, B27, B378, B379, B175, B385, B388, B324, B386, B34, B407, B259, B280, B402, B312, B387, B309, B62, B389, B24, B410, B210, B392, B165, B230, B278, B159, B415, B396, B135, B404, B262, B169, B157, B10, B381, B15, B331, B376, B277, B405, B414, B37, B1, B213, B398, B417, B279, B418, B408, B400, B176, B338, B58, B40, B151, B274, B411, B380, B375, B334, B7, B340, B64, B4, B377, B406, B60, B13, B172, B163, B106, B86, B217, B18, B112, B383] at com.oracle.graal.compiler.common.GraalInternalError.shouldNotReachHere(GraalInternalError.java:44) at com.oracle.graal.lir.amd64.AMD64Compare$CompareMemoryOp.emitMemAccess(AMD64Compare.java:129) at com.oracle.graal.lir.amd64.AMD64Move$MemOp.emitCode(AMD64Move.java:129) at com.oracle.graal.lir.amd64.AMD64LIRInstruction.emitCode(AMD64LIRInstruction.java:36) at com.oracle.graal.lir.asm.CompilationResultBuilder.emitOp(CompilationResultBuilder.java:350) at com.oracle.graal.lir.asm.CompilationResultBuilder.emitBlock(CompilationResultBuilder.java:341) at com.oracle.graal.lir.asm.CompilationResultBuilder.emit(CompilationResultBuilder.java:323) at com.oracle.graal.hotspot.amd64.AMD64HotSpotBackend.emitCodeBody(AMD64HotSpotBackend.java:301) at com.oracle.graal.hotspot.amd64.AMD64HotSpotBackend.emitCode(AMD64HotSpotBackend.java:254) at com.oracle.graal.compiler.GraalCompiler.emitCode(GraalCompiler.java:288) at com.oracle.graal.compiler.GraalCompiler.emitBackEnd(GraalCompiler.java:200) at com.oracle.graal.compiler.GraalCompiler.compileGraph(GraalCompiler.java:141) at com.oracle.graal.hotspot.CompilationTask.runCompilation(CompilationTask.java:302) at com.oracle.graal.hotspot.CompilationTask.run(CompilationTask.java:159) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) at java.lang.Thread.run(Thread.java:745) at com.oracle.graal.compiler.CompilerThread.run(CompilerThread.java:48) The potential bug can be tracked in com.oracle.graal.compiler.amd64.AMD64NodeLIRBuilder.emitCompareBranchMemory (-G:Dump= -G:MethodFilter=com.oracle.graal.compiler.amd64.AMD64NodeLIRBuilder.emitCompareBranchMemory), and can be bypassed either by not inlining com.oracle.graal.compiler.amd64.AMD64NodeLIRBuilder.getMemoryKind, or by skipping the TailDuplicationPhase. I guess that the TailDuplicationPhase dropped some of the IfNode. Could be verified using the following code: protected ComplexMatchResult emitCompareBranchMemory(IfNode ifNode, CompareNode compare, ValueNode value, Access access) { Condition cond = compare.condition(); Kind kind = getMemoryKind(access); if (kind != Kind.Long) { notInlinedMethodPlaceHolder(kind); } After tail duplication at some merge node, the IfNode disappeared.. - Yudi From doug.simon at oracle.com Mon May 12 20:31:31 2014 From: doug.simon at oracle.com (Doug Simon) Date: Mon, 12 May 2014 22:31:31 +0200 Subject: HotspotProfilingInfo for xxx-morphic inlining In-Reply-To: References: Message-ID: On May 12, 2014, at 9:35 PM, Deneau, Tom wrote: > I am interested in getting HotspotProfilingInfo for a method that we will be compiling in the HSAIL backend. > (after running the method on the cpu first to get profiling info) You have to ensure the method has been run enough for the interpreter to create a profile for a method. Usually, executing it about 10000 times is a sure thing. For more info, see ProfilingInfoTest. > When I get to HotSpotResolvedJavaMethod.getProfilingInfo, the metaspaceMethodData is always 0 and methodData is always null, so we get DefaultProfilingInfo instead. > > I am using > -XX:TypeProfileWidth=3 -G:MegamorphicInliningMinMethodProbability=0.001 > > and my OptimisticOptimizations include UseTypedCheckInlining and UseTypeCheckHints. > > Is there some hotspot or graal option I am missing? -Doug From tom.deneau at amd.com Mon May 12 21:04:34 2014 From: tom.deneau at amd.com (Deneau, Tom) Date: Mon, 12 May 2014 21:04:34 +0000 Subject: HotspotProfilingInfo for xxx-morphic inlining In-Reply-To: References: Message-ID: Another question related to inlining... We have a junit test (lambda.InstanceOopNBodyTest) that only very occasionally fails, the failure reason being that an invokevirtual that we thought would have only a single target ends up not getting inlined. (and we have not yet implemented invoke#direct). When this happens we see the following from Log=InliningDecisions @ 74 com.oracle.graal.compiler.hsail.test.lambda.Body.getX():float (5 bytes) not inlining no type profile exists which I thought would only happen if there were two or more implementations of getX(). Now the junit test directory actually does have a class (called lambda.ObjectArrayInstanceDerivedTest) that extends Body and overrides getX(), but the things marked with @Test in that file are also marked @Ignore. So I would not think that this particular override of getX() would come into play. Or would it? I suppose we could log some extra information when we get this " not inlining no type profile exists" error. -- Tom > -----Original Message----- > From: Doug Simon [mailto:doug.simon at oracle.com] > Sent: Monday, May 12, 2014 3:32 PM > To: Deneau, Tom > Cc: graal-dev at openjdk.java.net > Subject: Re: HotspotProfilingInfo for xxx-morphic inlining > > > On May 12, 2014, at 9:35 PM, Deneau, Tom wrote: > > > I am interested in getting HotspotProfilingInfo for a method that we > will be compiling in the HSAIL backend. > > (after running the method on the cpu first to get profiling info) > > You have to ensure the method has been run enough for the interpreter to > create a profile for a method. Usually, executing it about 10000 times > is a sure thing. For more info, see ProfilingInfoTest. > > > When I get to HotSpotResolvedJavaMethod.getProfilingInfo, the > metaspaceMethodData is always 0 and methodData is always null, so we get > DefaultProfilingInfo instead. > > > > I am using > > -XX:TypeProfileWidth=3 - > G:MegamorphicInliningMinMethodProbability=0.001 > > > > and my OptimisticOptimizations include UseTypedCheckInlining and > UseTypeCheckHints. > > > > Is there some hotspot or graal option I am missing? > > -Doug From tom.deneau at amd.com Mon May 12 21:14:24 2014 From: tom.deneau at amd.com (Deneau, Tom) Date: Mon, 12 May 2014 21:14:24 +0000 Subject: HotspotProfilingInfo for xxx-morphic inlining In-Reply-To: References: Message-ID: Doug -- Not sure if I am reading ProfilingInfoTest correctly but it seems to only execute methods 10 times? private static final int N = 10; Anyway, in my case bumping up to 10000 did get us past the no profiling info point. -- Tom > -----Original Message----- > From: Doug Simon [mailto:doug.simon at oracle.com] > Sent: Monday, May 12, 2014 3:32 PM > To: Deneau, Tom > Cc: graal-dev at openjdk.java.net > Subject: Re: HotspotProfilingInfo for xxx-morphic inlining > > > On May 12, 2014, at 9:35 PM, Deneau, Tom wrote: > > > I am interested in getting HotspotProfilingInfo for a method that we > will be compiling in the HSAIL backend. > > (after running the method on the cpu first to get profiling info) > > You have to ensure the method has been run enough for the interpreter to > create a profile for a method. Usually, executing it about 10000 times > is a sure thing. For more info, see ProfilingInfoTest. > > > When I get to HotSpotResolvedJavaMethod.getProfilingInfo, the > metaspaceMethodData is always 0 and methodData is always null, so we get > DefaultProfilingInfo instead. > > > > I am using > > -XX:TypeProfileWidth=3 - > G:MegamorphicInliningMinMethodProbability=0.001 > > > > and my OptimisticOptimizations include UseTypedCheckInlining and > UseTypeCheckHints. > > > > Is there some hotspot or graal option I am missing? > > -Doug From doug.simon at oracle.com Mon May 12 21:38:03 2014 From: doug.simon at oracle.com (Doug Simon) Date: Mon, 12 May 2014 23:38:03 +0200 Subject: HotspotProfilingInfo for xxx-morphic inlining In-Reply-To: References: Message-ID: On May 12, 2014, at 11:14 PM, Deneau, Tom wrote: > Doug -- > > Not sure if I am reading ProfilingInfoTest correctly but it seems to only execute methods 10 times? > private static final int N = 10; Ah yes, I see that we force creation of a profile there with a call to ResolvedJavaMethod.reprofile(). This is another option you can use in a test scenario but is probably best avoid for non-test code. > Anyway, in my case bumping up to 10000 did get us past the no profiling info point. Great. -Doug >> -----Original Message----- >> From: Doug Simon [mailto:doug.simon at oracle.com] >> Sent: Monday, May 12, 2014 3:32 PM >> To: Deneau, Tom >> Cc: graal-dev at openjdk.java.net >> Subject: Re: HotspotProfilingInfo for xxx-morphic inlining >> >> >> On May 12, 2014, at 9:35 PM, Deneau, Tom wrote: >> >>> I am interested in getting HotspotProfilingInfo for a method that we >> will be compiling in the HSAIL backend. >>> (after running the method on the cpu first to get profiling info) >> >> You have to ensure the method has been run enough for the interpreter to >> create a profile for a method. Usually, executing it about 10000 times >> is a sure thing. For more info, see ProfilingInfoTest. >> >>> When I get to HotSpotResolvedJavaMethod.getProfilingInfo, the >> metaspaceMethodData is always 0 and methodData is always null, so we get >> DefaultProfilingInfo instead. >>> >>> I am using >>> -XX:TypeProfileWidth=3 - >> G:MegamorphicInliningMinMethodProbability=0.001 >>> >>> and my OptimisticOptimizations include UseTypedCheckInlining and >> UseTypeCheckHints. >>> >>> Is there some hotspot or graal option I am missing? >> >> -Doug From tom.rodriguez at oracle.com Mon May 12 22:40:14 2014 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Mon, 12 May 2014 15:40:14 -0700 Subject: buggy behavior in AMD64NodeLIRBuilder.emitCompareBranchMemory In-Reply-To: References: Message-ID: <0617F35B-7FED-43C4-999B-945E2A279E01@oracle.com> Thanks for the report. I?m looking into it. tom On May 12, 2014, at 1:10 PM, Yudi Zheng wrote: > Hi, > > 1. A minor problem is that the default TypeProfileWidth is 2, resulting in lots of megamorphic-inlining with a probability of 60~70% in many cases, > instead of polymorphic-inlining. > > 2. When running with -XX:TypeProfileWidth=8, I observed buggy behavior: > >> mx vm -XX:+BootstrapGraal -XX:TypeProfileWidth=8 -version > Bootstrapping Graal.......................com.oracle.graal.compiler.common.GraalInternalError: should not reach here > at lir instruction: B192 at 1350 LCMP (address: [rax|j + 24], y: long[33286881400|0x7c00d8078]{HotSpotType}) kind: long > [B0, B2, B3, B5, B6, B8, B416, B419, B9, B11, B12, B14, B16, B17, B19, B21, B413, B23, B25, B26, B28, B29, B31, B409, B412, B32, B33, B35, B36, B38, B39, B41, B42, B44, B45, B47, B49, B50, B52, B54, B53, B55, B56, B57, B59, B61, B63, B65, B66, B67, B69, B70, B72, B74, B77, B79, B80, B94, B96, B98, B99, B101, B102, B103, B104, B107, B108, B109, B110, B113, B114, B115, B117, B118, B120, B122, B125, B127, B128, B129, B143, B145, B147, B148, B160, B126, B119, B149, B116, B130, B132, B153, B133, B136, B138, B139, B141, B142, B137, B140, B150, B134, B168, B105, B166, B171, B180, B181, B183, B186, B188, B190, B192, B194, B196, B198, B200, B197, B161, B170, B179, B177, B178, B184, B403, B78, B193, B202, B203, B204, B209, B211, B212, B214, B399, B401, B215, B216, B218, B220, B222, B397, B71, B208, B205, B206, B100, B195, B201, B187, B189, B68, B191, B199, B219, B224, B226, B228, B229, B231, B233, B394, B395, B221, B223, B82, B84, B173, B174, B154, B155, B51, B48, B232, B235, B239, B393, B236, B238, B234, B85, B87, B89, B90, B92, B93, B88, B240, B242, B284, B286, B288, B289, B291, B294, B296, B297, B299, B300, B302, B304, B307, B308, B310, B311, B313, B315, B317, B318, B320, B322, B323, B325, B326, B327, B343, B345, B346, B348, B349, B351, B354, B356, B357, B358, B360, B362, B364, B365, B367, B369, B372, B368, B373, B83, B371, B46, B352, B237, B287, B316, B330, B332, B333, B335, B336, B337, B244, B246, B247, B249, B250, B252, B254, B257, B258, B260, B261, B263, B265, B267, B268, B270, B273, B275, B276, B370, B266, B207, B285, B314, B264, B91, B355, B295, B245, B339, B384, B301, B306, B251, B256, B390, B391, B281, B283, B167, B282, B347, B382, B344, B30, B27, B378, B379, B175, B385, B388, B324, B386, B34, B407, B259, B280, B402, B312, B387, B309, B62, B389, B24, B410, B210, B392, B165, B230, B278, B159, B415, B396, B135, B404, B262, B169, B157, B10, B381, B15, B331, B376, B277, B405, B414, B37, B1, B213, B398, B417, B279, B418, B408, B400, B176, B338, B58, B40, B151, B274, B411, B380, B375, B334, B7, B340, B64, B4, B377, B406, B60, B13, B172, B163, B106, B86, B217, B18, B112, B383] > at com.oracle.graal.compiler.common.GraalInternalError.shouldNotReachHere(GraalInternalError.java:44) > at com.oracle.graal.lir.amd64.AMD64Compare$CompareMemoryOp.emitMemAccess(AMD64Compare.java:129) > at com.oracle.graal.lir.amd64.AMD64Move$MemOp.emitCode(AMD64Move.java:129) > at com.oracle.graal.lir.amd64.AMD64LIRInstruction.emitCode(AMD64LIRInstruction.java:36) > at com.oracle.graal.lir.asm.CompilationResultBuilder.emitOp(CompilationResultBuilder.java:350) > at com.oracle.graal.lir.asm.CompilationResultBuilder.emitBlock(CompilationResultBuilder.java:341) > at com.oracle.graal.lir.asm.CompilationResultBuilder.emit(CompilationResultBuilder.java:323) > at com.oracle.graal.hotspot.amd64.AMD64HotSpotBackend.emitCodeBody(AMD64HotSpotBackend.java:301) > at com.oracle.graal.hotspot.amd64.AMD64HotSpotBackend.emitCode(AMD64HotSpotBackend.java:254) > at com.oracle.graal.compiler.GraalCompiler.emitCode(GraalCompiler.java:288) > at com.oracle.graal.compiler.GraalCompiler.emitBackEnd(GraalCompiler.java:200) > at com.oracle.graal.compiler.GraalCompiler.compileGraph(GraalCompiler.java:141) > at com.oracle.graal.hotspot.CompilationTask.runCompilation(CompilationTask.java:302) > at com.oracle.graal.hotspot.CompilationTask.run(CompilationTask.java:159) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) > at java.lang.Thread.run(Thread.java:745) > at com.oracle.graal.compiler.CompilerThread.run(CompilerThread.java:48) > > > The potential bug can be tracked in com.oracle.graal.compiler.amd64.AMD64NodeLIRBuilder.emitCompareBranchMemory > (-G:Dump= -G:MethodFilter=com.oracle.graal.compiler.amd64.AMD64NodeLIRBuilder.emitCompareBranchMemory), > and can be bypassed either by not inlining com.oracle.graal.compiler.amd64.AMD64NodeLIRBuilder.getMemoryKind, > or by skipping the TailDuplicationPhase. > > I guess that the TailDuplicationPhase dropped some of the IfNode. Could be verified using the following code: > > protected ComplexMatchResult emitCompareBranchMemory(IfNode ifNode, CompareNode compare, ValueNode value, Access access) { > Condition cond = compare.condition(); > Kind kind = getMemoryKind(access); > > if (kind != Kind.Long) { > notInlinedMethodPlaceHolder(kind); > } > > After tail duplication at some merge node, the IfNode disappeared.. > > - Yudi > > From tom.deneau at amd.com Mon May 12 22:45:44 2014 From: tom.deneau at amd.com (Deneau, Tom) Date: Mon, 12 May 2014 22:45:44 +0000 Subject: UnsatisfiedLinkError Message-ID: Did anything change in the build steps? I have updated to the latest default and everything builds fine but at runtime I get java.lang.UnsatisfiedLinkError: com.oracle.graal.hotspot.bridge.CompilerToVMImpl.initializeConfiguration(Lcom/oracle/graal/hotspot/HotSpotVMConfig;)V at com.oracle.graal.hotspot.bridge.CompilerToVMImpl.initializeConfiguration(Native Method) at com.oracle.graal.hotspot.HotSpotVMConfig.(HotSpotVMConfig.java:74) at com.oracle.graal.hotspot.HotSpotGraalRuntime.(HotSpotGraalRuntime.java:230) at com.oracle.graal.hotspot.HotSpotGraalRuntime.(HotSpotGraalRuntime.java:57) From doug.simon at oracle.com Mon May 12 22:47:22 2014 From: doug.simon at oracle.com (doug.simon at oracle.com) Date: Mon, 12 May 2014 22:47:22 +0000 Subject: hg: graal/graal: 13 new changesets Message-ID: <201405122247.s4CMlePb018590@aojmv0008> Changeset: 07ca8c86d31c Author: Gilles Duboscq Date: 2014-05-07 15:58 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/07ca8c86d31c CanonicalizerPhase, on constant stamp, only replace at value usages. ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/CanonicalizerPhase.java Changeset: e381346a8223 Author: Gilles Duboscq Date: 2014-05-08 15:05 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/e381346a8223 JMH: do not abort on missing jar file. Create necessary output directory if needed ! mx/mx_graal.py Changeset: 62738ce98804 Author: Gilles Duboscq Date: 2014-05-12 11:43 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/62738ce98804 mx: set _minVersion to 1.8 ! mx/mx_graal.py Changeset: 804326a882f0 Author: Lukas Stadler Date: 2014-05-12 16:38 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/804326a882f0 don't delete snippet MemoryAnchorNodes if they are used in the memory map ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/MemoryMapNode.java ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/FloatingReadPhase.java ! graal/com.oracle.graal.replacements/src/com/oracle/graal/replacements/SnippetTemplate.java Changeset: 7903324bc739 Author: Miguel Garcia Date: 2014-05-12 19:10 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/7903324bc739 [inlining] refactor: move InliningIterator to upper level + graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/inlining/InliningIterator.java ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/inlining/InliningPhase.java Changeset: a027048a2e5f Author: Miguel Garcia Date: 2014-05-12 19:25 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/a027048a2e5f [inlining] the constructor of InliningIterator now takes only the data it needs ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/inlining/InliningIterator.java ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/inlining/InliningPhase.java Changeset: 98dbd88812c6 Author: Miguel Garcia Date: 2014-05-12 19:52 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/98dbd88812c6 [inlining] refactor, GraphInfo constructor can populate the callsite list ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/inlining/InliningPhase.java Changeset: f0254bab4c6b Author: Bernhard Urban Date: 2014-05-12 22:32 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/f0254bab4c6b SchedulePhase: improve KillSet implementation by using a lazy initialized ArrayList ! graal/com.oracle.graal.phases/src/com/oracle/graal/phases/schedule/SchedulePhase.java ! graal/com.oracle.graal.phases/src/com/oracle/graal/phases/util/ArraySet.java Changeset: 2a5f05654bc6 Author: Bernhard Urban Date: 2014-05-12 20:29 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/2a5f05654bc6 changelog: note about truffle.jar separation ! CHANGELOG.md Changeset: 4aeb0b80324f Author: Bernhard Urban Date: 2014-05-12 22:37 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/4aeb0b80324f mx distributions: allow to specify dependencies between distributions ! mx/projects ! mxtool/mx.py Changeset: c73df62cbaee Author: Doug Simon Date: 2014-05-12 22:37 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/c73df62cbaee removed unused symbols ! src/share/vm/classfile/vmSymbols.hpp Changeset: b7fb36e57da8 Author: Doug Simon Date: 2014-05-12 23:27 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/b7fb36e57da8 made Graal initialization be driven from Java to simplify sequencing and synchronization ! CHANGELOG.md ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/HotSpotGraalRuntime.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/HotSpotOptions.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/bridge/VMToCompiler.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/bridge/VMToCompilerImpl.java ! graal/com.oracle.truffle.api/src/com/oracle/truffle/api/Truffle.java ! src/share/vm/graal/graalCompiler.cpp ! src/share/vm/graal/graalRuntime.cpp ! src/share/vm/graal/graalRuntime.hpp ! src/share/vm/prims/jni.cpp ! src/share/vm/prims/nativeLookup.cpp Changeset: d556971b409c Author: Doug Simon Date: 2014-05-12 23:27 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/d556971b409c Merge. ! CHANGELOG.md From doug.simon at oracle.com Mon May 12 22:57:16 2014 From: doug.simon at oracle.com (Doug Simon) Date: Tue, 13 May 2014 00:57:16 +0200 Subject: UnsatisfiedLinkError In-Reply-To: References: Message-ID: This changeset (just pushed) should fix that: http://hg.openjdk.java.net/graal/graal/rev/b7fb36e57da8 -Doug On May 13, 2014, at 12:45 AM, Deneau, Tom wrote: > Did anything change in the build steps? > I have updated to the latest default and everything builds fine but at runtime I get > > java.lang.UnsatisfiedLinkError: com.oracle.graal.hotspot.bridge.CompilerToVMImpl.initializeConfiguration(Lcom/oracle/graal/hotspot/HotSpotVMConfig;)V > at com.oracle.graal.hotspot.bridge.CompilerToVMImpl.initializeConfiguration(Native Method) > at com.oracle.graal.hotspot.HotSpotVMConfig.(HotSpotVMConfig.java:74) > at com.oracle.graal.hotspot.HotSpotGraalRuntime.(HotSpotGraalRuntime.java:230) > at com.oracle.graal.hotspot.HotSpotGraalRuntime.(HotSpotGraalRuntime.java:57) From tom.deneau at amd.com Mon May 12 22:59:40 2014 From: tom.deneau at amd.com (Deneau, Tom) Date: Mon, 12 May 2014 22:59:40 +0000 Subject: UnsatisfiedLinkError In-Reply-To: References: Message-ID: Yes, it did fix it for me > -----Original Message----- > From: Doug Simon [mailto:doug.simon at oracle.com] > Sent: Monday, May 12, 2014 5:57 PM > To: Deneau, Tom > Cc: graal-dev at openjdk.java.net > Subject: Re: UnsatisfiedLinkError > > This changeset (just pushed) should fix that: > > http://hg.openjdk.java.net/graal/graal/rev/b7fb36e57da8 > > -Doug > > On May 13, 2014, at 12:45 AM, Deneau, Tom wrote: > > > Did anything change in the build steps? > > I have updated to the latest default and everything builds fine but at > runtime I get > > > > java.lang.UnsatisfiedLinkError: > com.oracle.graal.hotspot.bridge.CompilerToVMImpl.initializeConfiguration > (Lcom/oracle/graal/hotspot/HotSpotVMConfig;)V > > at > com.oracle.graal.hotspot.bridge.CompilerToVMImpl.initializeConfiguration > (Native Method) > > at > com.oracle.graal.hotspot.HotSpotVMConfig.(HotSpotVMConfig.java:74) > > at > com.oracle.graal.hotspot.HotSpotGraalRuntime.(HotSpotGraalRuntime. > java:230) > > at > com.oracle.graal.hotspot.HotSpotGraalRuntime.(HotSpotGraalRuntim > e.java:57) From doug.simon at oracle.com Tue May 13 13:49:56 2014 From: doug.simon at oracle.com (Doug Simon) Date: Tue, 13 May 2014 15:49:56 +0200 Subject: Memory allocation in HSAIL In-Reply-To: References: <52C71D6F-E8A2-4BDD-95CE-BC7B62964955@oracle.com> <39D8C101-5569-4315-A455-83C9FCF5AA01@oracle.com> Message-ID: <376CCB3D-0B6C-4B09-9372-55D24143D52F@oracle.com> I?ve integrated these changes with the following small modification: - The initialization and deletion of _never_ran_array is now in HSAILDeoptimizationInfo constructor and destructor. -Doug On May 9, 2014, at 10:38 PM, Deneau, Tom wrote: > Doug -- > > I found a bug introduced in the recent hsail-deopt-windows-build-fixes webrev (which won't show up in the junits, it requires the maximum # of concurrent workitems to actually deopt ). > > http://cr.openjdk.java.net/~tdeneau/graal-webrevs/webrev-hsail-deopt-savearea-cleanup > > In addition, I tried implementing a few more of your suggestions. > > * I didn't see a good way to get rid of the operator new for the outer HSAILDeoptimizationInfo. > I guess I could have hidden it behind a new_HSAILDeoptimizationInfo static routine. > (I noticed that new_nmethod eventually called operator new for nmethod) > > * I did remove the ResourceObj declaration for HSAILDeoptimizationInfo since as you said it didn't > make sense when we were allocating from the heap. > > * cleaned up some NPEs when UseHSAILDeoptimization was turned off. Also marked some junit tests not > to run in that case. We still get some failures if we run the junits with UseHSAILDeoptimization > off. I understand these, they are based on the wide net we cast to decide if allocation is being > used for a particular graph. See HSAILHotSpotBackend.java line 491. > Couldn't think of a quick way to fix this but we should. > > * some other small cleanups > > * I didn't see how to use the CodeBlob::allocation_size() so I didn't stick that in. I did make > the HSAILDeoptimizationInfo end in a pointer so that the end of the header/ start of the save > area was 8-byte aligned. > > -- Tom > > >> -----Original Message----- >> From: Doug Simon [mailto:doug.simon at oracle.com] >> Sent: Wednesday, May 07, 2014 6:27 AM >> To: Deneau, Tom >> Cc: Gilles Duboscq; Christian Wirth >> Subject: Re: Memory allocation in HSAIL >> >> I'm pushing these changes now... >> >> On May 7, 2014, at 12:22 AM, Deneau, Tom wrote: >> >>> OK -- >>> >>> http://cr.openjdk.java.net/~tdeneau/graal-webrevs/webrev-hsail-deopt-w >>> indows-build-fixes/webrev/ >>> >>> is a small step in the direction below, mainly to solve the windows >> build issue. >>> It still passes the junits on linux. >>> >>> I actually started going a little beyond the specific windows build >>> issue but decided to postpone those fixes until later. >>> >>> -- Tom >>> >>> >>>> -----Original Message----- >>>> From: Doug Simon [mailto:doug.simon at oracle.com] >>>> Sent: Tuesday, May 06, 2014 12:56 AM >>>> To: Deneau, Tom >>>> Cc: Gilles Duboscq; Christian Wirth >>>> Subject: Re: Memory allocation in HSAIL >>>> >>>> >>>> On May 6, 2014, at 1:15 AM, Deneau, Tom wrote: >>>> >>>>> Doug -- >>>>> >>>>> I've been tied up in meetings today... >>>>> Not sure what your timeframe is, but I can send you a solution that >>>> builds on windows. >>>> >>>> That would be great. >>>> >>>>> But it doesn't address some of the other issues below, including how >>>> the HSAILDeoptimizationInfo is allocated. >>>> >>>> Ok - that is not urgent. >>>> >>>>> I don't currently have a way to actually run the hsail backend on >>>> windows but I can test building there and running elsewhere. >>>> >>>> That's fine. The main thing is to have the build work on Windows. >>>> >>>> Thanks. >>>> >>>> -Doug >>>> >>>>>> -----Original Message----- >>>>>> From: Doug Simon [mailto:doug.simon at oracle.com] >>>>>> Sent: Monday, May 05, 2014 3:52 PM >>>>>> To: Deneau, Tom >>>>>> Cc: Gilles Duboscq; Christian Wirth >>>>>> Subject: Re: Memory allocation in HSAIL >>>>>> >>>>>> Something like the pattern in nmethod::new_nmethod should work. >>>>>> >>>>>> -Doug >>>>>> >>>>>> On May 5, 2014, at 10:42 PM, Deneau, Tom >> wrote: >>>>>> >>>>>>> Doug -- >>>>>>> >>>>>>> Can you point me to an example of how you want the >>>>>> HSAILDeoptimizationInfo allocation to be structured? >>>>>>> In particular, for invoking the new operator for ResourceObj. >>>>>>> >>>>>>> -- Tom >>>>>>> >>>>>>> >>>>>>>> -----Original Message----- >>>>>>>> From: Doug Simon [mailto:doug.simon at oracle.com] >>>>>>>> Sent: Monday, May 05, 2014 5:51 AM >>>>>>>> To: Deneau, Tom >>>>>>>> Cc: Gilles Duboscq; Christian Wirth >>>>>>>> Subject: Memory allocation in HSAIL >>>>>>>> >>>>>>>> Hi Tom, >>>>>>>> >>>>>>>> The way memory is currently allocated for HSAIL deoptimization >>>>>>>> info departs somewhat from the way HotSpot manages variable >>>>>>>> size/embedded data structures. One immediate side effect of this >>>>>>>> is that your recent changes broke the Windows build with the >>>>>>>> following compiler >>>>>> warnings: >>>>>>>> >>>>>>>> \src\gpu\hsail\vm\gpu_hsail_Frame.hpp(15): error C2220: warning >>>>>>>> treated as error - no 'object' file generated [c:\oracl >>>>>>>> \src\gpu\hsail\vm\gpu_hsail_Frame.hpp(15): warning C4200: >>>>>>>> nonstandard extension used : zero-sized array in struct/union >>>>>>>> >>>>>>>> Gilles and I have looked at the code and have the following >>>>>>>> recommendations: >>>>>>>> >>>>>>>> Since HSAILDeoptimizationInfo subclasses ResourceObj, it should >>>>>>>> not override the new operator. Instead, at the allocation site it >>>>>>>> should do whatever size computation is necessary (probably in a >>>>>>>> static method of >>>>>>>> HSAILDeoptimizationInfo) and call one of the existing new >>>>>>>> operators defined by ResourceObj. At is currently stands, it's >>>>>>>> strange to have a ResourceObj subclass that allocates directly >>>>>>>> from the C >>>> heap. >>>>>>>> >>>>>>>> The bytesPerSaveArea is computed information that does not need >>>>>>>> to be stored in a _bytesPerSaveArea. Same goes for _deopt_span. >>>>>>>> >>>>>>>> Since both HSAILKernelDeoptimization and HSAILFrame are really >>>>>>>> overlays on a HSAILDeoptimizationInfo, they should both use >>>>>> VALUE_OBJ_CLASS_SPEC. >>>>>>>> For example: >>>>>>>> >>>>>>>> class HSAILKernelDeoptimization VALUE_OBJ_CLASS_SPEC { ... } >>>>>>>> >>>>>>>> The _num_s_regs, _num_d_regs and _num_stack_slots value are fixed >>>>>>>> for a given HSAILDeoptimizationInfo and do not need to be stored >>>>>>>> in each HSAILFrame (I can't even see where they are currently >>>> initialized). >>>>>>>> >>>>>>>> You should probably think about alignment for the objects >>>>>>>> embedded in a HSAILDeoptimizationInfo. See >>>>>>>> CodeBlob::allocation_size() for inspiration. >>>>>>>> >>>>>>>> The HSAILFrame::_save_area and >>>>>>>> HSAILDeoptimizationInfo::_deopt_save_states fields should go >> away. >>>>>>>> Accessing them should be done like the access to the objects >>>>>>>> embedded in an nmethod (e.g. nmethod::scopes_pcs_begin()). >>>>>>>> >>>>>>>> The highest priority is to fix the Windows build. >>>>>>>> >>>>>>>> -Doug >>>>> >>> > From doug.simon at oracle.com Tue May 13 15:34:00 2014 From: doug.simon at oracle.com (doug.simon at oracle.com) Date: Tue, 13 May 2014 15:34:00 +0000 Subject: hg: graal/graal: 10 new changesets Message-ID: <201405131534.s4DFYELD026631@aojmv0008> Changeset: bb9473723904 Author: Michael Van De Vanter Date: 2014-05-12 20:17 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/bb9473723904 Truffle/Instrumentation: - Merge instrumentation support into the general execution context; remove separate Instrumentation interface and implementation - Generalize the ?tagging? mechanism for extensibility: the enum PhylumTag is now an interface, and the standard tags moved to the new enum StandardTag - A new ?trap? mechanism interrupts program execution at any probed node holding a specified PhylumTag; this replaces some other special-purpose code. - Refine several interface by factoring out callback methods and simplifying collaboration among key implementation classes. ! graal/com.oracle.truffle.api/src/com/oracle/truffle/api/ExecutionContext.java ! graal/com.oracle.truffle.api/src/com/oracle/truffle/api/impl/AbstractExecutionContext.java ! graal/com.oracle.truffle.api/src/com/oracle/truffle/api/instrument/ASTProber.java ! graal/com.oracle.truffle.api/src/com/oracle/truffle/api/instrument/Instrument.java - graal/com.oracle.truffle.api/src/com/oracle/truffle/api/instrument/InstrumentEventListener.java - graal/com.oracle.truffle.api/src/com/oracle/truffle/api/instrument/Instrumentation.java - graal/com.oracle.truffle.api/src/com/oracle/truffle/api/instrument/InstrumentationFactory.java ! graal/com.oracle.truffle.api/src/com/oracle/truffle/api/instrument/PhylumTag.java ! graal/com.oracle.truffle.api/src/com/oracle/truffle/api/instrument/PhylumTagged.java + graal/com.oracle.truffle.api/src/com/oracle/truffle/api/instrument/PhylumTrap.java ! graal/com.oracle.truffle.api/src/com/oracle/truffle/api/instrument/Probe.java + graal/com.oracle.truffle.api/src/com/oracle/truffle/api/instrument/SourceListener.java + graal/com.oracle.truffle.api/src/com/oracle/truffle/api/instrument/StandardTag.java ! graal/com.oracle.truffle.api/src/com/oracle/truffle/api/instrument/Visualizer.java ! graal/com.oracle.truffle.api/src/com/oracle/truffle/api/instrument/Wrapper.java - graal/com.oracle.truffle.api/src/com/oracle/truffle/api/instrument/impl/InstrumentationImpl.java ! graal/com.oracle.truffle.api/src/com/oracle/truffle/api/instrument/impl/InstrumentationNode.java - graal/com.oracle.truffle.api/src/com/oracle/truffle/api/instrument/impl/NullInstrumentEventListener.java + graal/com.oracle.truffle.api/src/com/oracle/truffle/api/instrument/impl/SourceCallback.java Changeset: 357e7202de5b Author: Michael Van De Vanter Date: 2014-05-12 21:29 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/357e7202de5b Merge with d556971b409ca9f5ff13900d8b7b82549fd1f17a - graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/match/GraalMatchableNodes.java - graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/match/MatchNodeAdapter.java - graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/match/MatchableNodeImport.java - graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/nodes/HotSpotMatchableNodes.java - graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/nodes/LoadExceptionObjectNode.java Changeset: e0e1aa1b9295 Author: Lukas Stadler Date: 2014-05-13 11:06 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/e0e1aa1b9295 verbose assertion in ComputeInliningRelevance ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/inlining/ComputeInliningRelevance.java Changeset: 4e12cac4e51e Author: Doug Simon Date: 2014-05-13 11:55 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/4e12cac4e51e removed unnecessary mutex ! src/share/vm/runtime/mutexLocker.cpp ! src/share/vm/runtime/mutexLocker.hpp Changeset: 66d31e70bd79 Author: Doug Simon Date: 2014-05-13 14:35 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/66d31e70bd79 HSAIL: fixed deopt bug; cleaned up C++ code Contributed-by: Tom Deneau ! graal/com.oracle.graal.compiler.hsail.test.infra/src/com/oracle/graal/compiler/hsail/test/infra/GraalKernelTester.java ! graal/com.oracle.graal.compiler.hsail.test/src/com/oracle/graal/compiler/hsail/test/ObjSpillDeoptBase.java ! graal/com.oracle.graal.compiler.hsail.test/src/com/oracle/graal/compiler/hsail/test/StaticDoubleSpillBoundsCatchOneTest.java ! graal/com.oracle.graal.compiler.hsail.test/src/com/oracle/graal/compiler/hsail/test/StaticDoubleSpillBoundsCatchTest.java ! graal/com.oracle.graal.hotspot.hsail/src/com/oracle/graal/hotspot/hsail/HSAILHotSpotBackend.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/HotSpotVMConfig.java ! src/gpu/hsail/vm/gpu_hsail.cpp ! src/gpu/hsail/vm/gpu_hsail.hpp ! src/gpu/hsail/vm/vmStructs_hsail.hpp Changeset: c44cf62d1c97 Author: Roland Schatz Date: 2014-05-13 14:45 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/c44cf62d1c97 Simplify code generation of reinterpret-memory. ! graal/com.oracle.graal.compiler.amd64/src/com/oracle/graal/compiler/amd64/AMD64NodeLIRBuilder.java Changeset: 9129a2237dd8 Author: Lukas Stadler Date: 2014-05-13 16:16 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/9129a2237dd8 clean up frame states during FrameStateAssignmentPhase ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/FrameStateAssignmentPhase.java Changeset: cf430b3e838b Author: Doug Simon Date: 2014-05-13 15:39 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/cf430b3e838b moved assertEquals and MultiCauseAssertionError from GraalCompilerTest to GraalTest ! graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/GraalCompilerTest.java ! graal/com.oracle.graal.test/src/com/oracle/graal/test/GraalTest.java Changeset: cd58e98bafa4 Author: Doug Simon Date: 2014-05-13 15:40 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/cd58e98bafa4 made GraalVerboseTestListener eagerly print stack trace for failure which is useful if the VM crashes before completing all unit tests ! graal/com.oracle.graal.test/src/com/oracle/graal/test/GraalVerboseTextListener.java Changeset: 25ccd455f751 Author: Doug Simon Date: 2014-05-13 16:51 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/25ccd455f751 Merge. From doug.simon at oracle.com Tue May 13 15:34:23 2014 From: doug.simon at oracle.com (Doug Simon) Date: Tue, 13 May 2014 17:34:23 +0200 Subject: Proposal to reuse existing equality testing in unit tests In-Reply-To: <376CCB3D-0B6C-4B09-9372-55D24143D52F@oracle.com> References: <52C71D6F-E8A2-4BDD-95CE-BC7B62964955@oracle.com> <39D8C101-5569-4315-A455-83C9FCF5AA01@oracle.com> <376CCB3D-0B6C-4B09-9372-55D24143D52F@oracle.com> Message-ID: Tom, I noticed the special logic in KernelTester for comparing results of Okra based executions and sequential executions. As far as I can tell, this duplicates code that already exists in Graal and Junit. Could you please review this patch to remove the redundant logic: http://cr.openjdk.java.net/~dnsimon/use-existing-equality-testing/ -Doug From tom.deneau at amd.com Tue May 13 17:25:31 2014 From: tom.deneau at amd.com (Deneau, Tom) Date: Tue, 13 May 2014 17:25:31 +0000 Subject: Proposal to reuse existing equality testing in unit tests In-Reply-To: References: <52C71D6F-E8A2-4BDD-95CE-BC7B62964955@oracle.com> <39D8C101-5569-4315-A455-83C9FCF5AA01@oracle.com> <376CCB3D-0B6C-4B09-9372-55D24143D52F@oracle.com> Message-ID: Doug -- To make it work I had to extend GraalCompilerTest rather than GraalTest (new patch attached). Otherwise it didn't do the deep equals for arrays. But with that, this new patch works for me. Thanks for noticing this duplication. One question, I know we weren't really using it yet but we had made an overrideable method that would determine whether two floats or two doubles were equal so they wouldn't have to be exactly equal. Is there any provision for that in your infrastructure? -- Tom > -----Original Message----- > From: Doug Simon [mailto:doug.simon at oracle.com] > Sent: Tuesday, May 13, 2014 10:34 AM > To: Deneau, Tom > Cc: graal-dev at openjdk.java.net > Subject: Proposal to reuse existing equality testing in unit tests > > Tom, > > I noticed the special logic in KernelTester for comparing results of > Okra based executions and sequential executions. As far as I can tell, > this duplicates code that already exists in Graal and Junit. Could you > please review this patch to remove the redundant logic: > > http://cr.openjdk.java.net/~dnsimon/use-existing-equality-testing/ > > -Doug From doug.simon at oracle.com Tue May 13 20:25:51 2014 From: doug.simon at oracle.com (doug.simon at oracle.com) Date: Tue, 13 May 2014 20:25:51 +0000 Subject: hg: graal/graal: 9 new changesets Message-ID: <201405132026.s4DKQ3XS011280@aojmv0008> Changeset: e90ec3e5e45b Author: Miguel Garcia Date: 2014-05-13 13:20 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/e90ec3e5e45b [inlining] documentation ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/inlining/InliningPhase.java Changeset: 58bf117e18d8 Author: Miguel Garcia Date: 2014-05-13 14:54 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/58bf117e18d8 [inlining] place to host depth-search related utilities + graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/inlining/DepthSearchUtil.java Changeset: 7988771f7191 Author: Miguel Garcia Date: 2014-05-13 15:05 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/7988771f7191 [inlining] preparing to move depth-search utilities ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/inlining/InliningPhase.java Changeset: 64dc2584a3f0 Author: Miguel Garcia Date: 2014-05-13 15:11 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/64dc2584a3f0 [inlining] uncluttering InliningPhase, depth-search utilities moved out ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/inlining/DepthSearchUtil.java ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/inlining/InliningPhase.java Changeset: 610b064eb8f9 Author: Miguel Garcia Date: 2014-05-13 19:03 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/610b064eb8f9 [inlining] preparing to move processNextInvoke() closer to the data it mutates ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/inlining/InliningPhase.java Changeset: c6ba248e9941 Author: Miguel Garcia Date: 2014-05-13 19:11 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/c6ba248e9941 [inlining] moved processNextInvoke() ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/inlining/InliningPhase.java Changeset: 396a483ccaa5 Author: Miguel Garcia Date: 2014-05-13 19:17 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/396a483ccaa5 [inlining] processNextInvoke(), readability ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/inlining/InliningPhase.java Changeset: 7b09605b29c5 Author: Doug Simon Date: 2014-05-13 21:47 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/7b09605b29c5 renamed GraalTest.assertEquals* to assertDeepEquals to avoid confusion with JUnit API methods ! graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/BoxingEliminationTest.java ! graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/CompareCanonicalizerTest.java ! graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/ConditionalEliminationTest.java ! graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/FlowSenReduTest.java ! graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/FlowSensitiveReductionTest.java ! graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/GraalCompilerTest.java ! graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/InfopointReasonTest.java ! graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/LockEliminationTest.java ! graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/MemoryScheduleTest.java ! graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/MergeCanonicalizerTest.java ! graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/SimpleCFGTest.java ! graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/ea/EAMergingTest.java ! graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/ea/IterativeInliningTest.java ! graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/ea/PEAReadEliminationTest.java ! graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/ea/PartialEscapeAnalysisTest.java ! graal/com.oracle.graal.hotspot.test/src/com/oracle/graal/hotspot/test/AheadOfTimeCompilationTest.java ! graal/com.oracle.graal.hotspot.test/src/com/oracle/graal/hotspot/test/ExplicitExceptionTest.java ! graal/com.oracle.graal.hotspot.test/src/com/oracle/graal/hotspot/test/HotSpotMethodSubstitutionTest.java ! graal/com.oracle.graal.hotspot.test/src/com/oracle/graal/hotspot/test/HotSpotMonitorValueTest.java ! graal/com.oracle.graal.hotspot.test/src/com/oracle/graal/hotspot/test/HotSpotNmethodTest.java ! graal/com.oracle.graal.jtt/src/com/oracle/graal/jtt/JTTTest.java ! graal/com.oracle.graal.replacements.test/src/com/oracle/graal/replacements/test/ArraysSubstitutionsTest.java ! graal/com.oracle.graal.replacements.test/src/com/oracle/graal/replacements/test/NewArrayTest.java ! graal/com.oracle.graal.replacements.test/src/com/oracle/graal/replacements/test/NewInstanceTest.java ! graal/com.oracle.graal.replacements.test/src/com/oracle/graal/replacements/test/StandardMethodSubstitutionsTest.java ! graal/com.oracle.graal.replacements.test/src/com/oracle/graal/replacements/test/StringSubstitutionsTest.java ! graal/com.oracle.graal.replacements.test/src/com/oracle/graal/replacements/test/UnsafeSubstitutionsTest.java ! graal/com.oracle.graal.test/src/com/oracle/graal/test/GraalTest.java ! graal/com.oracle.graal.truffle.test/src/com/oracle/graal/truffle/test/AssumptionPartialEvaluationTest.java Changeset: 3c1a88470123 Author: Doug Simon Date: 2014-05-13 21:49 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/3c1a88470123 HSAIL: converted KernelTester to re-use existing mechanism for deep equality testing ! graal/com.oracle.graal.compiler.hsail.test.infra/src/com/oracle/graal/compiler/hsail/test/infra/KernelTester.java ! graal/com.oracle.graal.compiler.hsail.test/src/com/oracle/graal/compiler/hsail/test/BoundsCatchManyBase.java ! graal/com.oracle.graal.compiler.hsail.test/src/com/oracle/graal/compiler/hsail/test/FloatDivPrecisionTest.java ! mx/projects From doug.simon at oracle.com Tue May 13 20:26:52 2014 From: doug.simon at oracle.com (Doug Simon) Date: Tue, 13 May 2014 22:26:52 +0200 Subject: Proposal to reuse existing equality testing in unit tests In-Reply-To: References: <52C71D6F-E8A2-4BDD-95CE-BC7B62964955@oracle.com> <39D8C101-5569-4315-A455-83C9FCF5AA01@oracle.com> <376CCB3D-0B6C-4B09-9372-55D24143D52F@oracle.com> Message-ID: <53E30AB6-F1A8-4FC9-8859-4182EBE397BA@oracle.com> On May 13, 2014, at 7:25 PM, Deneau, Tom wrote: > Doug -- > > To make it work I had to extend GraalCompilerTest rather than GraalTest (new patch attached). > Otherwise it didn't do the deep equals for arrays. You must be not on tip as I moved the necessary methods from GraalCompilerTest to GraalTest. > But with that, this new patch works for me. Thanks for noticing this duplication. > > One question, I know we weren't really using it yet but we had made > an overrideable method that would determine whether two floats or two doubles were equal > so they wouldn't have to be exactly equal. > > Is there any provision for that in your infrastructure? Yes. The junit mechanism for this is to supply a ?delta? parameter when comparing floats or doubles. I?ve ensured this mechanism is also exposed in the GraalTest API and you can see an example of it being used in FloatDivPrecisionTest once you pull the latest changes: http://hg.openjdk.java.net/graal/graal/rev/3c1a88470123#l3.9 -Doug >> -----Original Message----- >> From: Doug Simon [mailto:doug.simon at oracle.com] >> Sent: Tuesday, May 13, 2014 10:34 AM >> To: Deneau, Tom >> Cc: graal-dev at openjdk.java.net >> Subject: Proposal to reuse existing equality testing in unit tests >> >> Tom, >> >> I noticed the special logic in KernelTester for comparing results of >> Okra based executions and sequential executions. As far as I can tell, >> this duplicates code that already exists in Graal and Junit. Could you >> please review this patch to remove the redundant logic: >> >> http://cr.openjdk.java.net/~dnsimon/use-existing-equality-testing/ >> >> -Doug > From christian.thalinger at oracle.com Tue May 13 20:45:46 2014 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Tue, 13 May 2014 13:45:46 -0700 Subject: Memory allocation in HSAIL In-Reply-To: References: <52C71D6F-E8A2-4BDD-95CE-BC7B62964955@oracle.com> <39D8C101-5569-4315-A455-83C9FCF5AA01@oracle.com> Message-ID: Oh. I missed the push of these: @HotSpotVMConstant(name = "sizeof(HSAILFrame)") @Stable public int hsailFrameHeaderSize; @HotSpotVMConstant(name = "sizeof(Hsail::HSAILKernelDeoptimization)") @Stable public int hsailKernelDeoptimizationHeaderSize; - @HotSpotVMField(name = "Hsail::HSAILDeoptimizationInfo::_deopt_save_states[0]", type = "Hsail::HSAILKernelDeoptimization", get = HotSpotVMField.Type.OFFSET) @Stable public int hsailSaveStatesOffset0; + @HotSpotVMConstant(name = "sizeof(Hsail::HSAILDeoptimizationInfo)") @Stable public int hsailDeoptimizationInfoHeaderSize; sizeof types should be handled differently with HotSpotVMType like: @HotSpotVMType(name = "vtableEntry", get = HotSpotVMType.Type.SIZE) @Stable public int vtableEntrySize; Tom, can you change that? On May 9, 2014, at 1:38 PM, Deneau, Tom wrote: > Doug -- > > I found a bug introduced in the recent hsail-deopt-windows-build-fixes webrev (which won't show up in the junits, it requires the maximum # of concurrent workitems to actually deopt ). > > http://cr.openjdk.java.net/~tdeneau/graal-webrevs/webrev-hsail-deopt-savearea-cleanup > > In addition, I tried implementing a few more of your suggestions. > > * I didn't see a good way to get rid of the operator new for the outer HSAILDeoptimizationInfo. > I guess I could have hidden it behind a new_HSAILDeoptimizationInfo static routine. > (I noticed that new_nmethod eventually called operator new for nmethod) > > * I did remove the ResourceObj declaration for HSAILDeoptimizationInfo since as you said it didn't > make sense when we were allocating from the heap. > > * cleaned up some NPEs when UseHSAILDeoptimization was turned off. Also marked some junit tests not > to run in that case. We still get some failures if we run the junits with UseHSAILDeoptimization > off. I understand these, they are based on the wide net we cast to decide if allocation is being > used for a particular graph. See HSAILHotSpotBackend.java line 491. > Couldn't think of a quick way to fix this but we should. > > * some other small cleanups > > * I didn't see how to use the CodeBlob::allocation_size() so I didn't stick that in. I did make > the HSAILDeoptimizationInfo end in a pointer so that the end of the header/ start of the save > area was 8-byte aligned. > > -- Tom > > >> -----Original Message----- >> From: Doug Simon [mailto:doug.simon at oracle.com] >> Sent: Wednesday, May 07, 2014 6:27 AM >> To: Deneau, Tom >> Cc: Gilles Duboscq; Christian Wirth >> Subject: Re: Memory allocation in HSAIL >> >> I'm pushing these changes now... >> >> On May 7, 2014, at 12:22 AM, Deneau, Tom wrote: >> >>> OK -- >>> >>> http://cr.openjdk.java.net/~tdeneau/graal-webrevs/webrev-hsail-deopt-w >>> indows-build-fixes/webrev/ >>> >>> is a small step in the direction below, mainly to solve the windows >> build issue. >>> It still passes the junits on linux. >>> >>> I actually started going a little beyond the specific windows build >>> issue but decided to postpone those fixes until later. >>> >>> -- Tom >>> >>> >>>> -----Original Message----- >>>> From: Doug Simon [mailto:doug.simon at oracle.com] >>>> Sent: Tuesday, May 06, 2014 12:56 AM >>>> To: Deneau, Tom >>>> Cc: Gilles Duboscq; Christian Wirth >>>> Subject: Re: Memory allocation in HSAIL >>>> >>>> >>>> On May 6, 2014, at 1:15 AM, Deneau, Tom wrote: >>>> >>>>> Doug -- >>>>> >>>>> I've been tied up in meetings today... >>>>> Not sure what your timeframe is, but I can send you a solution that >>>> builds on windows. >>>> >>>> That would be great. >>>> >>>>> But it doesn't address some of the other issues below, including how >>>> the HSAILDeoptimizationInfo is allocated. >>>> >>>> Ok - that is not urgent. >>>> >>>>> I don't currently have a way to actually run the hsail backend on >>>> windows but I can test building there and running elsewhere. >>>> >>>> That's fine. The main thing is to have the build work on Windows. >>>> >>>> Thanks. >>>> >>>> -Doug >>>> >>>>>> -----Original Message----- >>>>>> From: Doug Simon [mailto:doug.simon at oracle.com] >>>>>> Sent: Monday, May 05, 2014 3:52 PM >>>>>> To: Deneau, Tom >>>>>> Cc: Gilles Duboscq; Christian Wirth >>>>>> Subject: Re: Memory allocation in HSAIL >>>>>> >>>>>> Something like the pattern in nmethod::new_nmethod should work. >>>>>> >>>>>> -Doug >>>>>> >>>>>> On May 5, 2014, at 10:42 PM, Deneau, Tom >> wrote: >>>>>> >>>>>>> Doug -- >>>>>>> >>>>>>> Can you point me to an example of how you want the >>>>>> HSAILDeoptimizationInfo allocation to be structured? >>>>>>> In particular, for invoking the new operator for ResourceObj. >>>>>>> >>>>>>> -- Tom >>>>>>> >>>>>>> >>>>>>>> -----Original Message----- >>>>>>>> From: Doug Simon [mailto:doug.simon at oracle.com] >>>>>>>> Sent: Monday, May 05, 2014 5:51 AM >>>>>>>> To: Deneau, Tom >>>>>>>> Cc: Gilles Duboscq; Christian Wirth >>>>>>>> Subject: Memory allocation in HSAIL >>>>>>>> >>>>>>>> Hi Tom, >>>>>>>> >>>>>>>> The way memory is currently allocated for HSAIL deoptimization >>>>>>>> info departs somewhat from the way HotSpot manages variable >>>>>>>> size/embedded data structures. One immediate side effect of this >>>>>>>> is that your recent changes broke the Windows build with the >>>>>>>> following compiler >>>>>> warnings: >>>>>>>> >>>>>>>> \src\gpu\hsail\vm\gpu_hsail_Frame.hpp(15): error C2220: warning >>>>>>>> treated as error - no 'object' file generated [c:\oracl >>>>>>>> \src\gpu\hsail\vm\gpu_hsail_Frame.hpp(15): warning C4200: >>>>>>>> nonstandard extension used : zero-sized array in struct/union >>>>>>>> >>>>>>>> Gilles and I have looked at the code and have the following >>>>>>>> recommendations: >>>>>>>> >>>>>>>> Since HSAILDeoptimizationInfo subclasses ResourceObj, it should >>>>>>>> not override the new operator. Instead, at the allocation site it >>>>>>>> should do whatever size computation is necessary (probably in a >>>>>>>> static method of >>>>>>>> HSAILDeoptimizationInfo) and call one of the existing new >>>>>>>> operators defined by ResourceObj. At is currently stands, it's >>>>>>>> strange to have a ResourceObj subclass that allocates directly >>>>>>>> from the C >>>> heap. >>>>>>>> >>>>>>>> The bytesPerSaveArea is computed information that does not need >>>>>>>> to be stored in a _bytesPerSaveArea. Same goes for _deopt_span. >>>>>>>> >>>>>>>> Since both HSAILKernelDeoptimization and HSAILFrame are really >>>>>>>> overlays on a HSAILDeoptimizationInfo, they should both use >>>>>> VALUE_OBJ_CLASS_SPEC. >>>>>>>> For example: >>>>>>>> >>>>>>>> class HSAILKernelDeoptimization VALUE_OBJ_CLASS_SPEC { ... } >>>>>>>> >>>>>>>> The _num_s_regs, _num_d_regs and _num_stack_slots value are fixed >>>>>>>> for a given HSAILDeoptimizationInfo and do not need to be stored >>>>>>>> in each HSAILFrame (I can't even see where they are currently >>>> initialized). >>>>>>>> >>>>>>>> You should probably think about alignment for the objects >>>>>>>> embedded in a HSAILDeoptimizationInfo. See >>>>>>>> CodeBlob::allocation_size() for inspiration. >>>>>>>> >>>>>>>> The HSAILFrame::_save_area and >>>>>>>> HSAILDeoptimizationInfo::_deopt_save_states fields should go >> away. >>>>>>>> Accessing them should be done like the access to the objects >>>>>>>> embedded in an nmethod (e.g. nmethod::scopes_pcs_begin()). >>>>>>>> >>>>>>>> The highest priority is to fix the Windows build. >>>>>>>> >>>>>>>> -Doug >>>>> >>> > From christian.thalinger at oracle.com Tue May 13 20:45:46 2014 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Tue, 13 May 2014 13:45:46 -0700 Subject: Memory allocation in HSAIL In-Reply-To: References: <52C71D6F-E8A2-4BDD-95CE-BC7B62964955@oracle.com> <39D8C101-5569-4315-A455-83C9FCF5AA01@oracle.com> Message-ID: Oh. I missed the push of these: @HotSpotVMConstant(name = "sizeof(HSAILFrame)") @Stable public int hsailFrameHeaderSize; @HotSpotVMConstant(name = "sizeof(Hsail::HSAILKernelDeoptimization)") @Stable public int hsailKernelDeoptimizationHeaderSize; - @HotSpotVMField(name = "Hsail::HSAILDeoptimizationInfo::_deopt_save_states[0]", type = "Hsail::HSAILKernelDeoptimization", get = HotSpotVMField.Type.OFFSET) @Stable public int hsailSaveStatesOffset0; + @HotSpotVMConstant(name = "sizeof(Hsail::HSAILDeoptimizationInfo)") @Stable public int hsailDeoptimizationInfoHeaderSize; sizeof types should be handled differently with HotSpotVMType like: @HotSpotVMType(name = "vtableEntry", get = HotSpotVMType.Type.SIZE) @Stable public int vtableEntrySize; Tom, can you change that? On May 9, 2014, at 1:38 PM, Deneau, Tom wrote: > Doug -- > > I found a bug introduced in the recent hsail-deopt-windows-build-fixes webrev (which won't show up in the junits, it requires the maximum # of concurrent workitems to actually deopt ). > > http://cr.openjdk.java.net/~tdeneau/graal-webrevs/webrev-hsail-deopt-savearea-cleanup > > In addition, I tried implementing a few more of your suggestions. > > * I didn't see a good way to get rid of the operator new for the outer HSAILDeoptimizationInfo. > I guess I could have hidden it behind a new_HSAILDeoptimizationInfo static routine. > (I noticed that new_nmethod eventually called operator new for nmethod) > > * I did remove the ResourceObj declaration for HSAILDeoptimizationInfo since as you said it didn't > make sense when we were allocating from the heap. > > * cleaned up some NPEs when UseHSAILDeoptimization was turned off. Also marked some junit tests not > to run in that case. We still get some failures if we run the junits with UseHSAILDeoptimization > off. I understand these, they are based on the wide net we cast to decide if allocation is being > used for a particular graph. See HSAILHotSpotBackend.java line 491. > Couldn't think of a quick way to fix this but we should. > > * some other small cleanups > > * I didn't see how to use the CodeBlob::allocation_size() so I didn't stick that in. I did make > the HSAILDeoptimizationInfo end in a pointer so that the end of the header/ start of the save > area was 8-byte aligned. > > -- Tom > > >> -----Original Message----- >> From: Doug Simon [mailto:doug.simon at oracle.com] >> Sent: Wednesday, May 07, 2014 6:27 AM >> To: Deneau, Tom >> Cc: Gilles Duboscq; Christian Wirth >> Subject: Re: Memory allocation in HSAIL >> >> I'm pushing these changes now... >> >> On May 7, 2014, at 12:22 AM, Deneau, Tom wrote: >> >>> OK -- >>> >>> http://cr.openjdk.java.net/~tdeneau/graal-webrevs/webrev-hsail-deopt-w >>> indows-build-fixes/webrev/ >>> >>> is a small step in the direction below, mainly to solve the windows >> build issue. >>> It still passes the junits on linux. >>> >>> I actually started going a little beyond the specific windows build >>> issue but decided to postpone those fixes until later. >>> >>> -- Tom >>> >>> >>>> -----Original Message----- >>>> From: Doug Simon [mailto:doug.simon at oracle.com] >>>> Sent: Tuesday, May 06, 2014 12:56 AM >>>> To: Deneau, Tom >>>> Cc: Gilles Duboscq; Christian Wirth >>>> Subject: Re: Memory allocation in HSAIL >>>> >>>> >>>> On May 6, 2014, at 1:15 AM, Deneau, Tom wrote: >>>> >>>>> Doug -- >>>>> >>>>> I've been tied up in meetings today... >>>>> Not sure what your timeframe is, but I can send you a solution that >>>> builds on windows. >>>> >>>> That would be great. >>>> >>>>> But it doesn't address some of the other issues below, including how >>>> the HSAILDeoptimizationInfo is allocated. >>>> >>>> Ok - that is not urgent. >>>> >>>>> I don't currently have a way to actually run the hsail backend on >>>> windows but I can test building there and running elsewhere. >>>> >>>> That's fine. The main thing is to have the build work on Windows. >>>> >>>> Thanks. >>>> >>>> -Doug >>>> >>>>>> -----Original Message----- >>>>>> From: Doug Simon [mailto:doug.simon at oracle.com] >>>>>> Sent: Monday, May 05, 2014 3:52 PM >>>>>> To: Deneau, Tom >>>>>> Cc: Gilles Duboscq; Christian Wirth >>>>>> Subject: Re: Memory allocation in HSAIL >>>>>> >>>>>> Something like the pattern in nmethod::new_nmethod should work. >>>>>> >>>>>> -Doug >>>>>> >>>>>> On May 5, 2014, at 10:42 PM, Deneau, Tom >> wrote: >>>>>> >>>>>>> Doug -- >>>>>>> >>>>>>> Can you point me to an example of how you want the >>>>>> HSAILDeoptimizationInfo allocation to be structured? >>>>>>> In particular, for invoking the new operator for ResourceObj. >>>>>>> >>>>>>> -- Tom >>>>>>> >>>>>>> >>>>>>>> -----Original Message----- >>>>>>>> From: Doug Simon [mailto:doug.simon at oracle.com] >>>>>>>> Sent: Monday, May 05, 2014 5:51 AM >>>>>>>> To: Deneau, Tom >>>>>>>> Cc: Gilles Duboscq; Christian Wirth >>>>>>>> Subject: Memory allocation in HSAIL >>>>>>>> >>>>>>>> Hi Tom, >>>>>>>> >>>>>>>> The way memory is currently allocated for HSAIL deoptimization >>>>>>>> info departs somewhat from the way HotSpot manages variable >>>>>>>> size/embedded data structures. One immediate side effect of this >>>>>>>> is that your recent changes broke the Windows build with the >>>>>>>> following compiler >>>>>> warnings: >>>>>>>> >>>>>>>> \src\gpu\hsail\vm\gpu_hsail_Frame.hpp(15): error C2220: warning >>>>>>>> treated as error - no 'object' file generated [c:\oracl >>>>>>>> \src\gpu\hsail\vm\gpu_hsail_Frame.hpp(15): warning C4200: >>>>>>>> nonstandard extension used : zero-sized array in struct/union >>>>>>>> >>>>>>>> Gilles and I have looked at the code and have the following >>>>>>>> recommendations: >>>>>>>> >>>>>>>> Since HSAILDeoptimizationInfo subclasses ResourceObj, it should >>>>>>>> not override the new operator. Instead, at the allocation site it >>>>>>>> should do whatever size computation is necessary (probably in a >>>>>>>> static method of >>>>>>>> HSAILDeoptimizationInfo) and call one of the existing new >>>>>>>> operators defined by ResourceObj. At is currently stands, it's >>>>>>>> strange to have a ResourceObj subclass that allocates directly >>>>>>>> from the C >>>> heap. >>>>>>>> >>>>>>>> The bytesPerSaveArea is computed information that does not need >>>>>>>> to be stored in a _bytesPerSaveArea. Same goes for _deopt_span. >>>>>>>> >>>>>>>> Since both HSAILKernelDeoptimization and HSAILFrame are really >>>>>>>> overlays on a HSAILDeoptimizationInfo, they should both use >>>>>> VALUE_OBJ_CLASS_SPEC. >>>>>>>> For example: >>>>>>>> >>>>>>>> class HSAILKernelDeoptimization VALUE_OBJ_CLASS_SPEC { ... } >>>>>>>> >>>>>>>> The _num_s_regs, _num_d_regs and _num_stack_slots value are fixed >>>>>>>> for a given HSAILDeoptimizationInfo and do not need to be stored >>>>>>>> in each HSAILFrame (I can't even see where they are currently >>>> initialized). >>>>>>>> >>>>>>>> You should probably think about alignment for the objects >>>>>>>> embedded in a HSAILDeoptimizationInfo. See >>>>>>>> CodeBlob::allocation_size() for inspiration. >>>>>>>> >>>>>>>> The HSAILFrame::_save_area and >>>>>>>> HSAILDeoptimizationInfo::_deopt_save_states fields should go >> away. >>>>>>>> Accessing them should be done like the access to the objects >>>>>>>> embedded in an nmethod (e.g. nmethod::scopes_pcs_begin()). >>>>>>>> >>>>>>>> The highest priority is to fix the Windows build. >>>>>>>> >>>>>>>> -Doug >>>>> >>> > From tom.deneau at amd.com Tue May 13 21:34:22 2014 From: tom.deneau at amd.com (Deneau, Tom) Date: Tue, 13 May 2014 21:34:22 +0000 Subject: Memory allocation in HSAIL In-Reply-To: References: <52C71D6F-E8A2-4BDD-95CE-BC7B62964955@oracle.com> <39D8C101-5569-4315-A455-83C9FCF5AA01@oracle.com> Message-ID: Yes, I will send a patch shortly... From: Christian Thalinger [mailto:christian.thalinger at oracle.com] Sent: Tuesday, May 13, 2014 3:46 PM To: Deneau, Tom Cc: Doug Simon; graal-dev at openjdk.java.net Subject: Re: Memory allocation in HSAIL Oh. I missed the push of these: @HotSpotVMConstant(name = "sizeof(HSAILFrame)") @Stable public int hsailFrameHeaderSize; @HotSpotVMConstant(name = "sizeof(Hsail::HSAILKernelDeoptimization)") @Stable public int hsailKernelDeoptimizationHeaderSize; - @HotSpotVMField(name = "Hsail::HSAILDeoptimizationInfo::_deopt_save_states[0]", type = "Hsail::HSAILKernelDeoptimization", get = HotSpotVMField.Type.OFFSET) @Stable public int hsailSaveStatesOffset0; + @HotSpotVMConstant(name = "sizeof(Hsail::HSAILDeoptimizationInfo)") @Stable public int hsailDeoptimizationInfoHeaderSize; sizeof types should be handled differently with HotSpotVMType like: @HotSpotVMType(name = "vtableEntry", get = HotSpotVMType.Type.SIZE) @Stable public int vtableEntrySize; Tom, can you change that? On May 9, 2014, at 1:38 PM, Deneau, Tom > wrote: Doug -- I found a bug introduced in the recent hsail-deopt-windows-build-fixes webrev (which won't show up in the junits, it requires the maximum # of concurrent workitems to actually deopt ). http://cr.openjdk.java.net/~tdeneau/graal-webrevs/webrev-hsail-deopt-savearea-cleanup In addition, I tried implementing a few more of your suggestions. * I didn't see a good way to get rid of the operator new for the outer HSAILDeoptimizationInfo. I guess I could have hidden it behind a new_HSAILDeoptimizationInfo static routine. (I noticed that new_nmethod eventually called operator new for nmethod) * I did remove the ResourceObj declaration for HSAILDeoptimizationInfo since as you said it didn't make sense when we were allocating from the heap. * cleaned up some NPEs when UseHSAILDeoptimization was turned off. Also marked some junit tests not to run in that case. We still get some failures if we run the junits with UseHSAILDeoptimization off. I understand these, they are based on the wide net we cast to decide if allocation is being used for a particular graph. See HSAILHotSpotBackend.java line 491. Couldn't think of a quick way to fix this but we should. * some other small cleanups * I didn't see how to use the CodeBlob::allocation_size() so I didn't stick that in. I did make the HSAILDeoptimizationInfo end in a pointer so that the end of the header/ start of the save area was 8-byte aligned. -- Tom -----Original Message----- From: Doug Simon [mailto:doug.simon at oracle.com] Sent: Wednesday, May 07, 2014 6:27 AM To: Deneau, Tom Cc: Gilles Duboscq; Christian Wirth Subject: Re: Memory allocation in HSAIL I'm pushing these changes now... On May 7, 2014, at 12:22 AM, Deneau, Tom > wrote: OK -- http://cr.openjdk.java.net/~tdeneau/graal-webrevs/webrev-hsail-deopt-w indows-build-fixes/webrev/ is a small step in the direction below, mainly to solve the windows build issue. It still passes the junits on linux. I actually started going a little beyond the specific windows build issue but decided to postpone those fixes until later. -- Tom -----Original Message----- From: Doug Simon [mailto:doug.simon at oracle.com] Sent: Tuesday, May 06, 2014 12:56 AM To: Deneau, Tom Cc: Gilles Duboscq; Christian Wirth Subject: Re: Memory allocation in HSAIL On May 6, 2014, at 1:15 AM, Deneau, Tom > wrote: Doug -- I've been tied up in meetings today... Not sure what your timeframe is, but I can send you a solution that builds on windows. That would be great. But it doesn't address some of the other issues below, including how the HSAILDeoptimizationInfo is allocated. Ok - that is not urgent. I don't currently have a way to actually run the hsail backend on windows but I can test building there and running elsewhere. That's fine. The main thing is to have the build work on Windows. Thanks. -Doug -----Original Message----- From: Doug Simon [mailto:doug.simon at oracle.com] Sent: Monday, May 05, 2014 3:52 PM To: Deneau, Tom Cc: Gilles Duboscq; Christian Wirth Subject: Re: Memory allocation in HSAIL Something like the pattern in nmethod::new_nmethod should work. -Doug On May 5, 2014, at 10:42 PM, Deneau, Tom > wrote: Doug -- Can you point me to an example of how you want the HSAILDeoptimizationInfo allocation to be structured? In particular, for invoking the new operator for ResourceObj. -- Tom -----Original Message----- From: Doug Simon [mailto:doug.simon at oracle.com] Sent: Monday, May 05, 2014 5:51 AM To: Deneau, Tom Cc: Gilles Duboscq; Christian Wirth Subject: Memory allocation in HSAIL Hi Tom, The way memory is currently allocated for HSAIL deoptimization info departs somewhat from the way HotSpot manages variable size/embedded data structures. One immediate side effect of this is that your recent changes broke the Windows build with the following compiler warnings: \src\gpu\hsail\vm\gpu_hsail_Frame.hpp(15): error C2220: warning treated as error - no 'object' file generated [c:\oracl \src\gpu\hsail\vm\gpu_hsail_Frame.hpp(15): warning C4200: nonstandard extension used : zero-sized array in struct/union Gilles and I have looked at the code and have the following recommendations: Since HSAILDeoptimizationInfo subclasses ResourceObj, it should not override the new operator. Instead, at the allocation site it should do whatever size computation is necessary (probably in a static method of HSAILDeoptimizationInfo) and call one of the existing new operators defined by ResourceObj. At is currently stands, it's strange to have a ResourceObj subclass that allocates directly from the C heap. The bytesPerSaveArea is computed information that does not need to be stored in a _bytesPerSaveArea. Same goes for _deopt_span. Since both HSAILKernelDeoptimization and HSAILFrame are really overlays on a HSAILDeoptimizationInfo, they should both use VALUE_OBJ_CLASS_SPEC. For example: class HSAILKernelDeoptimization VALUE_OBJ_CLASS_SPEC { ... } The _num_s_regs, _num_d_regs and _num_stack_slots value are fixed for a given HSAILDeoptimizationInfo and do not need to be stored in each HSAILFrame (I can't even see where they are currently initialized). You should probably think about alignment for the objects embedded in a HSAILDeoptimizationInfo. See CodeBlob::allocation_size() for inspiration. The HSAILFrame::_save_area and HSAILDeoptimizationInfo::_deopt_save_states fields should go away. Accessing them should be done like the access to the objects embedded in an nmethod (e.g. nmethod::scopes_pcs_begin()). The highest priority is to fix the Windows build. -Doug From tom.deneau at amd.com Tue May 13 21:49:58 2014 From: tom.deneau at amd.com (Deneau, Tom) Date: Tue, 13 May 2014 21:49:58 +0000 Subject: Memory allocation in HSAIL In-Reply-To: References: <52C71D6F-E8A2-4BDD-95CE-BC7B62964955@oracle.com> <39D8C101-5569-4315-A455-83C9FCF5AA01@oracle.com> Message-ID: Christian, Doug -- Attached is the small patch to take care of this... -- Tom From: Christian Thalinger [mailto:christian.thalinger at oracle.com] Sent: Tuesday, May 13, 2014 3:46 PM To: Deneau, Tom Cc: Doug Simon; graal-dev at openjdk.java.net Subject: Re: Memory allocation in HSAIL Oh. I missed the push of these: @HotSpotVMConstant(name = "sizeof(HSAILFrame)") @Stable public int hsailFrameHeaderSize; @HotSpotVMConstant(name = "sizeof(Hsail::HSAILKernelDeoptimization)") @Stable public int hsailKernelDeoptimizationHeaderSize; - @HotSpotVMField(name = "Hsail::HSAILDeoptimizationInfo::_deopt_save_states[0]", type = "Hsail::HSAILKernelDeoptimization", get = HotSpotVMField.Type.OFFSET) @Stable public int hsailSaveStatesOffset0; + @HotSpotVMConstant(name = "sizeof(Hsail::HSAILDeoptimizationInfo)") @Stable public int hsailDeoptimizationInfoHeaderSize; sizeof types should be handled differently with HotSpotVMType like: @HotSpotVMType(name = "vtableEntry", get = HotSpotVMType.Type.SIZE) @Stable public int vtableEntrySize; Tom, can you change that? On May 9, 2014, at 1:38 PM, Deneau, Tom > wrote: Doug -- I found a bug introduced in the recent hsail-deopt-windows-build-fixes webrev (which won't show up in the junits, it requires the maximum # of concurrent workitems to actually deopt ). http://cr.openjdk.java.net/~tdeneau/graal-webrevs/webrev-hsail-deopt-savearea-cleanup In addition, I tried implementing a few more of your suggestions. * I didn't see a good way to get rid of the operator new for the outer HSAILDeoptimizationInfo. I guess I could have hidden it behind a new_HSAILDeoptimizationInfo static routine. (I noticed that new_nmethod eventually called operator new for nmethod) * I did remove the ResourceObj declaration for HSAILDeoptimizationInfo since as you said it didn't make sense when we were allocating from the heap. * cleaned up some NPEs when UseHSAILDeoptimization was turned off. Also marked some junit tests not to run in that case. We still get some failures if we run the junits with UseHSAILDeoptimization off. I understand these, they are based on the wide net we cast to decide if allocation is being used for a particular graph. See HSAILHotSpotBackend.java line 491. Couldn't think of a quick way to fix this but we should. * some other small cleanups * I didn't see how to use the CodeBlob::allocation_size() so I didn't stick that in. I did make the HSAILDeoptimizationInfo end in a pointer so that the end of the header/ start of the save area was 8-byte aligned. -- Tom -----Original Message----- From: Doug Simon [mailto:doug.simon at oracle.com] Sent: Wednesday, May 07, 2014 6:27 AM To: Deneau, Tom Cc: Gilles Duboscq; Christian Wirth Subject: Re: Memory allocation in HSAIL I'm pushing these changes now... On May 7, 2014, at 12:22 AM, Deneau, Tom > wrote: OK -- http://cr.openjdk.java.net/~tdeneau/graal-webrevs/webrev-hsail-deopt-w indows-build-fixes/webrev/ is a small step in the direction below, mainly to solve the windows build issue. It still passes the junits on linux. I actually started going a little beyond the specific windows build issue but decided to postpone those fixes until later. -- Tom -----Original Message----- From: Doug Simon [mailto:doug.simon at oracle.com] Sent: Tuesday, May 06, 2014 12:56 AM To: Deneau, Tom Cc: Gilles Duboscq; Christian Wirth Subject: Re: Memory allocation in HSAIL On May 6, 2014, at 1:15 AM, Deneau, Tom > wrote: Doug -- I've been tied up in meetings today... Not sure what your timeframe is, but I can send you a solution that builds on windows. That would be great. But it doesn't address some of the other issues below, including how the HSAILDeoptimizationInfo is allocated. Ok - that is not urgent. I don't currently have a way to actually run the hsail backend on windows but I can test building there and running elsewhere. That's fine. The main thing is to have the build work on Windows. Thanks. -Doug -----Original Message----- From: Doug Simon [mailto:doug.simon at oracle.com] Sent: Monday, May 05, 2014 3:52 PM To: Deneau, Tom Cc: Gilles Duboscq; Christian Wirth Subject: Re: Memory allocation in HSAIL Something like the pattern in nmethod::new_nmethod should work. -Doug On May 5, 2014, at 10:42 PM, Deneau, Tom > wrote: Doug -- Can you point me to an example of how you want the HSAILDeoptimizationInfo allocation to be structured? In particular, for invoking the new operator for ResourceObj. -- Tom -----Original Message----- From: Doug Simon [mailto:doug.simon at oracle.com] Sent: Monday, May 05, 2014 5:51 AM To: Deneau, Tom Cc: Gilles Duboscq; Christian Wirth Subject: Memory allocation in HSAIL Hi Tom, The way memory is currently allocated for HSAIL deoptimization info departs somewhat from the way HotSpot manages variable size/embedded data structures. One immediate side effect of this is that your recent changes broke the Windows build with the following compiler warnings: \src\gpu\hsail\vm\gpu_hsail_Frame.hpp(15): error C2220: warning treated as error - no 'object' file generated [c:\oracl \src\gpu\hsail\vm\gpu_hsail_Frame.hpp(15): warning C4200: nonstandard extension used : zero-sized array in struct/union Gilles and I have looked at the code and have the following recommendations: Since HSAILDeoptimizationInfo subclasses ResourceObj, it should not override the new operator. Instead, at the allocation site it should do whatever size computation is necessary (probably in a static method of HSAILDeoptimizationInfo) and call one of the existing new operators defined by ResourceObj. At is currently stands, it's strange to have a ResourceObj subclass that allocates directly from the C heap. The bytesPerSaveArea is computed information that does not need to be stored in a _bytesPerSaveArea. Same goes for _deopt_span. Since both HSAILKernelDeoptimization and HSAILFrame are really overlays on a HSAILDeoptimizationInfo, they should both use VALUE_OBJ_CLASS_SPEC. For example: class HSAILKernelDeoptimization VALUE_OBJ_CLASS_SPEC { ... } The _num_s_regs, _num_d_regs and _num_stack_slots value are fixed for a given HSAILDeoptimizationInfo and do not need to be stored in each HSAILFrame (I can't even see where they are currently initialized). You should probably think about alignment for the objects embedded in a HSAILDeoptimizationInfo. See CodeBlob::allocation_size() for inspiration. The HSAILFrame::_save_area and HSAILDeoptimizationInfo::_deopt_save_states fields should go away. Accessing them should be done like the access to the objects embedded in an nmethod (e.g. nmethod::scopes_pcs_begin()). The highest priority is to fix the Windows build. -Doug From christian.thalinger at oracle.com Tue May 13 22:01:07 2014 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Tue, 13 May 2014 15:01:07 -0700 Subject: Memory allocation in HSAIL In-Reply-To: References: <52C71D6F-E8A2-4BDD-95CE-BC7B62964955@oracle.com> <39D8C101-5569-4315-A455-83C9FCF5AA01@oracle.com> Message-ID: <5F9C2B12-861B-4D07-9541-DF07CC881D84@oracle.com> Thanks. I will push this. On May 13, 2014, at 2:49 PM, Deneau, Tom wrote: > Christian, Doug -- > > Attached is the small patch to take care of this? > > -- Tom > > From: Christian Thalinger [mailto:christian.thalinger at oracle.com] > Sent: Tuesday, May 13, 2014 3:46 PM > To: Deneau, Tom > Cc: Doug Simon; graal-dev at openjdk.java.net > Subject: Re: Memory allocation in HSAIL > > Oh. I missed the push of these: > @HotSpotVMConstant(name = "sizeof(HSAILFrame)") @Stable public int hsailFrameHeaderSize; > @HotSpotVMConstant(name = "sizeof(Hsail::HSAILKernelDeoptimization)") @Stable public int hsailKernelDeoptimizationHeaderSize; > - @HotSpotVMField(name = "Hsail::HSAILDeoptimizationInfo::_deopt_save_states[0]", type = "Hsail::HSAILKernelDeoptimization", get = HotSpotVMField.Type.OFFSET) @Stable public int hsailSaveStatesOffset0; > + @HotSpotVMConstant(name = "sizeof(Hsail::HSAILDeoptimizationInfo)") @Stable public int hsailDeoptimizationInfoHeaderSize; > > sizeof types should be handled differently with HotSpotVMType like: > > @HotSpotVMType(name = "vtableEntry", get = HotSpotVMType.Type.SIZE) @Stable public int vtableEntrySize; > > Tom, can you change that? > > On May 9, 2014, at 1:38 PM, Deneau, Tom wrote: > > > Doug -- > > I found a bug introduced in the recent hsail-deopt-windows-build-fixes webrev (which won't show up in the junits, it requires the maximum # of concurrent workitems to actually deopt ). > > http://cr.openjdk.java.net/~tdeneau/graal-webrevs/webrev-hsail-deopt-savearea-cleanup > > In addition, I tried implementing a few more of your suggestions. > > * I didn't see a good way to get rid of the operator new for the outer HSAILDeoptimizationInfo. > I guess I could have hidden it behind a new_HSAILDeoptimizationInfo static routine. > (I noticed that new_nmethod eventually called operator new for nmethod) > > * I did remove the ResourceObj declaration for HSAILDeoptimizationInfo since as you said it didn't > make sense when we were allocating from the heap. > > * cleaned up some NPEs when UseHSAILDeoptimization was turned off. Also marked some junit tests not > to run in that case. We still get some failures if we run the junits with UseHSAILDeoptimization > off. I understand these, they are based on the wide net we cast to decide if allocation is being > used for a particular graph. See HSAILHotSpotBackend.java line 491. > Couldn't think of a quick way to fix this but we should. > > * some other small cleanups > > * I didn't see how to use the CodeBlob::allocation_size() so I didn't stick that in. I did make > the HSAILDeoptimizationInfo end in a pointer so that the end of the header/ start of the save > area was 8-byte aligned. > > -- Tom > > > > -----Original Message----- > From: Doug Simon [mailto:doug.simon at oracle.com] > Sent: Wednesday, May 07, 2014 6:27 AM > To: Deneau, Tom > Cc: Gilles Duboscq; Christian Wirth > Subject: Re: Memory allocation in HSAIL > > I'm pushing these changes now... > > On May 7, 2014, at 12:22 AM, Deneau, Tom wrote: > > > OK -- > > http://cr.openjdk.java.net/~tdeneau/graal-webrevs/webrev-hsail-deopt-w > indows-build-fixes/webrev/ > > is a small step in the direction below, mainly to solve the windows > build issue. > > It still passes the junits on linux. > > I actually started going a little beyond the specific windows build > issue but decided to postpone those fixes until later. > > -- Tom > > > > -----Original Message----- > From: Doug Simon [mailto:doug.simon at oracle.com] > Sent: Tuesday, May 06, 2014 12:56 AM > To: Deneau, Tom > Cc: Gilles Duboscq; Christian Wirth > Subject: Re: Memory allocation in HSAIL > > > On May 6, 2014, at 1:15 AM, Deneau, Tom wrote: > > > Doug -- > > I've been tied up in meetings today... > Not sure what your timeframe is, but I can send you a solution that > builds on windows. > > That would be great. > > > But it doesn't address some of the other issues below, including how > the HSAILDeoptimizationInfo is allocated. > > Ok - that is not urgent. > > > I don't currently have a way to actually run the hsail backend on > windows but I can test building there and running elsewhere. > > That's fine. The main thing is to have the build work on Windows. > > Thanks. > > -Doug > > > -----Original Message----- > From: Doug Simon [mailto:doug.simon at oracle.com] > Sent: Monday, May 05, 2014 3:52 PM > To: Deneau, Tom > Cc: Gilles Duboscq; Christian Wirth > Subject: Re: Memory allocation in HSAIL > > Something like the pattern in nmethod::new_nmethod should work. > > -Doug > > On May 5, 2014, at 10:42 PM, Deneau, Tom > wrote: > > > > Doug -- > > Can you point me to an example of how you want the > HSAILDeoptimizationInfo allocation to be structured? > > In particular, for invoking the new operator for ResourceObj. > > -- Tom > > > > -----Original Message----- > From: Doug Simon [mailto:doug.simon at oracle.com] > Sent: Monday, May 05, 2014 5:51 AM > To: Deneau, Tom > Cc: Gilles Duboscq; Christian Wirth > Subject: Memory allocation in HSAIL > > Hi Tom, > > The way memory is currently allocated for HSAIL deoptimization > info departs somewhat from the way HotSpot manages variable > size/embedded data structures. One immediate side effect of this > is that your recent changes broke the Windows build with the > following compiler > warnings: > > > \src\gpu\hsail\vm\gpu_hsail_Frame.hpp(15): error C2220: warning > treated as error - no 'object' file generated [c:\oracl > \src\gpu\hsail\vm\gpu_hsail_Frame.hpp(15): warning C4200: > nonstandard extension used : zero-sized array in struct/union > > Gilles and I have looked at the code and have the following > recommendations: > > Since HSAILDeoptimizationInfo subclasses ResourceObj, it should > not override the new operator. Instead, at the allocation site it > should do whatever size computation is necessary (probably in a > static method of > HSAILDeoptimizationInfo) and call one of the existing new > operators defined by ResourceObj. At is currently stands, it's > strange to have a ResourceObj subclass that allocates directly > from the C > heap. > > > The bytesPerSaveArea is computed information that does not need > to be stored in a _bytesPerSaveArea. Same goes for _deopt_span. > > Since both HSAILKernelDeoptimization and HSAILFrame are really > overlays on a HSAILDeoptimizationInfo, they should both use > VALUE_OBJ_CLASS_SPEC. > > For example: > > class HSAILKernelDeoptimization VALUE_OBJ_CLASS_SPEC { ... } > > The _num_s_regs, _num_d_regs and _num_stack_slots value are fixed > for a given HSAILDeoptimizationInfo and do not need to be stored > in each HSAILFrame (I can't even see where they are currently > initialized). > > > You should probably think about alignment for the objects > embedded in a HSAILDeoptimizationInfo. See > CodeBlob::allocation_size() for inspiration. > > The HSAILFrame::_save_area and > HSAILDeoptimizationInfo::_deopt_save_states fields should go > away. > > Accessing them should be done like the access to the objects > embedded in an nmethod (e.g. nmethod::scopes_pcs_begin()). > > The highest priority is to fix the Windows build. > > -Doug > > > > > From tom.deneau at amd.com Tue May 13 22:52:59 2014 From: tom.deneau at amd.com (Deneau, Tom) Date: Tue, 13 May 2014 22:52:59 +0000 Subject: VirtualObjects at deoptimization points. In-Reply-To: References: Message-ID: Gilles -- Sorry for the delay in responding... There is one test checked in trunk that currently fails because of lack of VirtualObjectsInDeopt support. The test is com.oracle.graal.compiler.hsail.test.lambda.VecmathNBodyTest It is currently disabled from running by the following (canHandleDeoptVirtualObjects() returns false) but you can comment that out to make it run. @Override protected boolean supportsRequiredCapabilities() { return (canHandleDeoptVirtualObjects()); } I was going to say it should pass if -XX:-UseHSAILDeoptimization is on the command line but I see there is a bug in that it still tries to create the host graph even if UseHSAILDeoptimization is false. This logic can be fixed in HSAILHotSpotBackend.java by this little patch. --- a/graal/com.oracle.graal.hotspot.hsail/src/com/oracle/graal/hotspot/hsail/HSAILHotSpotBackend.java Tue May 13 15:38:56 2014 -0500 +++ b/graal/com.oracle.graal.hotspot.hsail/src/com/oracle/graal/hotspot/hsail/HSAILHotSpotBackend.java Tue May 13 17:49:29 2014 -0500 @@ -924,7 +924,9 @@ ExternalCompilationResult compilationResult = (ExternalCompilationResult) crb.compilationResult; HSAILHotSpotLIRGenerationResult lirGenRes = ((HSAILCompilationResultBuilder) crb).lirGenRes; - compilationResult.setHostGraph(prepareHostGraph(method, lirGenRes.getDeopts(), getProviders(), config, numSRegs, numDRegs)); + if (useHSAILDeoptimization) { + compilationResult.setHostGraph(prepareHostGraph(method, lirGenRes.getDeopts(), getProviders(), config, numSRegs, numDRegs)); + } } -- Tom > -----Original Message----- > From: gilwooden at gmail.com [mailto:gilwooden at gmail.com] On Behalf Of > Gilles Duboscq > Sent: Sunday, May 04, 2014 12:17 PM > To: Deneau, Tom > Cc: graal-dev at openjdk.java.net > Subject: Re: VirtualObjects at deoptimization points. > > Hello, > > I currently have a prototype [1] that i would like to test. Before > creating my own tests, i was wondering if you already have tests for > this or if you know of tests that have escaping objects? > > -Gilles > > [1] http://cr.openjdk.java.net/~gdub/HSAILVirtualObjectDeopt.patch > > On Fri, May 2, 2014 at 7:21 PM, Tom Deneau wrote: > > Hi Gilles -- > > > > Could I get an update on the support for VirtualObjects in the host > deopt trampoline code? > > > > -- Tom D. > > > >> -----Original Message----- > >> From: gilwooden at gmail.com [mailto:gilwooden at gmail.com] On Behalf Of > >> Gilles Duboscq > >> Sent: Thursday, April 03, 2014 5:04 AM > >> To: Deneau, Tom > >> Cc: graal-dev at openjdk.java.net > >> Subject: Re: VirtualObjects at deoptimization points. > >> > >> Hello Tom, > >> > >> The reason I delayed the implementation of VirtualObjects is that we > >> have to reverse the process that transforms VirtualObjectNodes into > >> VirtualObjects (that's in > >> com.oracle.graal.compiler.gen.DebugInfoBuilder.build(FrameState, > >> LabelRef)). > >> It shouldn't be so complicated to add this support. I'll give it a > try. > >> > >> -Gilles > >> > >> On Tue, Apr 1, 2014 at 1:07 AM, Tom Deneau > wrote: > >> > Gilles -- > >> > > >> > > >> > > >> > I noticed in one of our java8 lambda tests (not yet pushed to > >> > trunk) we had some object allocation that was eliminated by escape > analysis. > >> > But when we try to run this with the trunk now, we get > >> > > >> > > >> > > >> > com.oracle.graal.graph.GraalInternalError: unimplemented > >> > > >> > at > >> > com.oracle.graal.graph.GraalInternalError.unimplemented(GraalIntern > >> > alE > >> > rror.java:38) > >> > > >> > at > >> > com.oracle.graal.hotspot.hsail.HSAILHotSpotLIRGenerator.getNodeForV > >> > alu > >> > eFromFrame(HSAILHotSpotLIRGenerator.java:182) > >> > > >> > at > >> > com.oracle.graal.hotspot.hsail.HSAILHotSpotLIRGenerator.createFrame > >> > Sta > >> > te(HSAILHotSpotLIRGenerator.java:149) > >> > > >> > at > >> > com.oracle.graal.hotspot.hsail.HSAILHotSpotLIRGenerator.createHostD > >> > eop > >> > tBranch(HSAILHotSpotLIRGenerator.java:140) > >> > > >> > > >> > > >> > where the line 182 in getNodeForValueFromFrame has > >> > > >> > > >> > > >> > > >> > > >> > } else if (localValue instanceof VirtualObject) { > >> > > >> > throw GraalInternalError.unimplemented(); > >> > > >> > } > >> > > >> > > >> > > >> > > >> > > >> > What would we need to do to support VirtualObjects at our > >> > deoptimization infopoints? > >> > > >> > > >> > > >> > > >> > > >> > (We also don't support stack slots yet, but I think I understand > >> > what is needed to support those). > >> > > >> > > >> > > >> > -- Tom > >> > > >> > > > From tom.deneau at amd.com Tue May 13 22:59:22 2014 From: tom.deneau at amd.com (Deneau, Tom) Date: Tue, 13 May 2014 22:59:22 +0000 Subject: VirtualObjects at deoptimization points. References: Message-ID: Gilles -- I noticed you had a link to a patch, I applied your patch and the one test mentioned below did not get an error at prepareHostGraph time as it usually did. I should add that while this test failed in prepareHostGraph, trying to handle a Virtual Object, this test doesn't actually deopt so it doesn't really test whether the virtual object can be handled correctly in the face of deopt. I can try to modify it so that it does deopt. -- Tom > -----Original Message----- > From: Deneau, Tom > Sent: Tuesday, May 13, 2014 5:53 PM > To: 'Gilles Duboscq' > Cc: graal-dev at openjdk.java.net > Subject: RE: VirtualObjects at deoptimization points. > > Gilles -- > > Sorry for the delay in responding... > There is one test checked in trunk that currently fails because of lack > of VirtualObjectsInDeopt support. > > The test is com.oracle.graal.compiler.hsail.test.lambda.VecmathNBodyTest > It is currently disabled from running by the following > (canHandleDeoptVirtualObjects() returns false) > but you can comment that out to make it run. > > @Override > protected boolean supportsRequiredCapabilities() { > return (canHandleDeoptVirtualObjects()); > } > > I was going to say it should pass if -XX:-UseHSAILDeoptimization is on > the command line > but I see there is a bug in that it still tries to create the host graph > even if > UseHSAILDeoptimization is false. This logic can be fixed in > HSAILHotSpotBackend.java by > this little patch. > > --- > a/graal/com.oracle.graal.hotspot.hsail/src/com/oracle/graal/hotspot/hsai > l/HSAILHotSpotBackend.java Tue May 13 15:38:56 2014 -0500 > +++ > b/graal/com.oracle.graal.hotspot.hsail/src/com/oracle/graal/hotspot/hsai > l/HSAILHotSpotBackend.java Tue May 13 17:49:29 2014 -0500 > @@ -924,7 +924,9 @@ > > ExternalCompilationResult compilationResult = > (ExternalCompilationResult) crb.compilationResult; > HSAILHotSpotLIRGenerationResult lirGenRes = > ((HSAILCompilationResultBuilder) crb).lirGenRes; > - compilationResult.setHostGraph(prepareHostGraph(method, > lirGenRes.getDeopts(), getProviders(), config, numSRegs, numDRegs)); > + if (useHSAILDeoptimization) { > + compilationResult.setHostGraph(prepareHostGraph(method, > lirGenRes.getDeopts(), getProviders(), config, numSRegs, numDRegs)); > + } > } > > -- Tom > > > > -----Original Message----- > > From: gilwooden at gmail.com [mailto:gilwooden at gmail.com] On Behalf Of > > Gilles Duboscq > > Sent: Sunday, May 04, 2014 12:17 PM > > To: Deneau, Tom > > Cc: graal-dev at openjdk.java.net > > Subject: Re: VirtualObjects at deoptimization points. > > > > Hello, > > > > I currently have a prototype [1] that i would like to test. Before > > creating my own tests, i was wondering if you already have tests for > > this or if you know of tests that have escaping objects? > > > > -Gilles > > > > [1] http://cr.openjdk.java.net/~gdub/HSAILVirtualObjectDeopt.patch > > > > On Fri, May 2, 2014 at 7:21 PM, Tom Deneau wrote: > > > Hi Gilles -- > > > > > > Could I get an update on the support for VirtualObjects in the host > > deopt trampoline code? > > > > > > -- Tom D. > > > > > >> -----Original Message----- > > >> From: gilwooden at gmail.com [mailto:gilwooden at gmail.com] On Behalf Of > > >> Gilles Duboscq > > >> Sent: Thursday, April 03, 2014 5:04 AM > > >> To: Deneau, Tom > > >> Cc: graal-dev at openjdk.java.net > > >> Subject: Re: VirtualObjects at deoptimization points. > > >> > > >> Hello Tom, > > >> > > >> The reason I delayed the implementation of VirtualObjects is that > we > > >> have to reverse the process that transforms VirtualObjectNodes into > > >> VirtualObjects (that's in > > >> com.oracle.graal.compiler.gen.DebugInfoBuilder.build(FrameState, > > >> LabelRef)). > > >> It shouldn't be so complicated to add this support. I'll give it a > > try. > > >> > > >> -Gilles > > >> > > >> On Tue, Apr 1, 2014 at 1:07 AM, Tom Deneau > > wrote: > > >> > Gilles -- > > >> > > > >> > > > >> > > > >> > I noticed in one of our java8 lambda tests (not yet pushed to > > >> > trunk) we had some object allocation that was eliminated by > escape > > analysis. > > >> > But when we try to run this with the trunk now, we get > > >> > > > >> > > > >> > > > >> > com.oracle.graal.graph.GraalInternalError: unimplemented > > >> > > > >> > at > > >> > > com.oracle.graal.graph.GraalInternalError.unimplemented(GraalIntern > > >> > alE > > >> > rror.java:38) > > >> > > > >> > at > > >> > > com.oracle.graal.hotspot.hsail.HSAILHotSpotLIRGenerator.getNodeForV > > >> > alu > > >> > eFromFrame(HSAILHotSpotLIRGenerator.java:182) > > >> > > > >> > at > > >> > > com.oracle.graal.hotspot.hsail.HSAILHotSpotLIRGenerator.createFrame > > >> > Sta > > >> > te(HSAILHotSpotLIRGenerator.java:149) > > >> > > > >> > at > > >> > > com.oracle.graal.hotspot.hsail.HSAILHotSpotLIRGenerator.createHostD > > >> > eop > > >> > tBranch(HSAILHotSpotLIRGenerator.java:140) > > >> > > > >> > > > >> > > > >> > where the line 182 in getNodeForValueFromFrame has > > >> > > > >> > > > >> > > > >> > > > >> > > > >> > } else if (localValue instanceof VirtualObject) { > > >> > > > >> > throw GraalInternalError.unimplemented(); > > >> > > > >> > } > > >> > > > >> > > > >> > > > >> > > > >> > > > >> > What would we need to do to support VirtualObjects at our > > >> > deoptimization infopoints? > > >> > > > >> > > > >> > > > >> > > > >> > > > >> > (We also don't support stack slots yet, but I think I understand > > >> > what is needed to support those). > > >> > > > >> > > > >> > > > >> > -- Tom > > >> > > > >> > > > > From tom.deneau at amd.com Tue May 13 23:11:49 2014 From: tom.deneau at amd.com (Deneau, Tom) Date: Tue, 13 May 2014 23:11:49 +0000 Subject: VirtualObjects at deoptimization points. In-Reply-To: References: Message-ID: Gilles -- You can try applying the attached patch to create a new test uses virtual objects and does force a deopt. When I tried this test with your patch, I did not get the correct results but I didn't try to trace down whether it was due to anything with virtual objects or not. -- Tom > -----Original Message----- > From: Deneau, Tom > Sent: Tuesday, May 13, 2014 5:59 PM > To: Deneau, Tom; Gilles Duboscq > Cc: graal-dev at openjdk.java.net > Subject: RE: VirtualObjects at deoptimization points. > > Gilles -- > > I noticed you had a link to a patch, I applied your patch and the one > test mentioned below did not get an error at prepareHostGraph time as it > usually did. > > I should add that while this test failed in prepareHostGraph, trying to > handle a Virtual Object, this test doesn't actually deopt so it doesn't > really test whether the virtual object can be handled correctly in the > face of deopt. > > I can try to modify it so that it does deopt. > > -- Tom > > > > -----Original Message----- > > From: Deneau, Tom > > Sent: Tuesday, May 13, 2014 5:53 PM > > To: 'Gilles Duboscq' > > Cc: graal-dev at openjdk.java.net > > Subject: RE: VirtualObjects at deoptimization points. > > > > Gilles -- > > > > Sorry for the delay in responding... > > There is one test checked in trunk that currently fails because of > > lack of VirtualObjectsInDeopt support. > > > > The test is > > com.oracle.graal.compiler.hsail.test.lambda.VecmathNBodyTest > > It is currently disabled from running by the following > > (canHandleDeoptVirtualObjects() returns false) but you can comment > > that out to make it run. > > > > @Override > > protected boolean supportsRequiredCapabilities() { > > return (canHandleDeoptVirtualObjects()); > > } > > > > I was going to say it should pass if -XX:-UseHSAILDeoptimization is > > on the command line but I see there is a bug in that it still tries to > > create the host graph even if UseHSAILDeoptimization is false. This > > logic can be fixed in HSAILHotSpotBackend.java by this little patch. > > > > --- > > > a/graal/com.oracle.graal.hotspot.hsail/src/com/oracle/graal/hotspot/hsai > > l/HSAILHotSpotBackend.java Tue May 13 15:38:56 2014 -0500 > > +++ > > > b/graal/com.oracle.graal.hotspot.hsail/src/com/oracle/graal/hotspot/hsai > > l/HSAILHotSpotBackend.java Tue May 13 17:49:29 2014 -0500 > > @@ -924,7 +924,9 @@ > > > > ExternalCompilationResult compilationResult = > > (ExternalCompilationResult) crb.compilationResult; > > HSAILHotSpotLIRGenerationResult lirGenRes = > > ((HSAILCompilationResultBuilder) crb).lirGenRes; > > - compilationResult.setHostGraph(prepareHostGraph(method, > > lirGenRes.getDeopts(), getProviders(), config, numSRegs, numDRegs)); > > + if (useHSAILDeoptimization) { > > + compilationResult.setHostGraph(prepareHostGraph(method, > > lirGenRes.getDeopts(), getProviders(), config, numSRegs, numDRegs)); > > + } > > } > > > > -- Tom > > > > > > > -----Original Message----- > > > From: gilwooden at gmail.com [mailto:gilwooden at gmail.com] On Behalf Of > > > Gilles Duboscq > > > Sent: Sunday, May 04, 2014 12:17 PM > > > To: Deneau, Tom > > > Cc: graal-dev at openjdk.java.net > > > Subject: Re: VirtualObjects at deoptimization points. > > > > > > Hello, > > > > > > I currently have a prototype [1] that i would like to test. Before > > > creating my own tests, i was wondering if you already have tests for > > > this or if you know of tests that have escaping objects? > > > > > > -Gilles > > > > > > [1] http://cr.openjdk.java.net/~gdub/HSAILVirtualObjectDeopt.patch > > > > > > On Fri, May 2, 2014 at 7:21 PM, Tom Deneau > wrote: > > > > Hi Gilles -- > > > > > > > > Could I get an update on the support for VirtualObjects in the > > > > host > > > deopt trampoline code? > > > > > > > > -- Tom D. > > > > > > > >> -----Original Message----- > > > >> From: gilwooden at gmail.com [mailto:gilwooden at gmail.com] On Behalf > > > >> Of Gilles Duboscq > > > >> Sent: Thursday, April 03, 2014 5:04 AM > > > >> To: Deneau, Tom > > > >> Cc: graal-dev at openjdk.java.net > > > >> Subject: Re: VirtualObjects at deoptimization points. > > > >> > > > >> Hello Tom, > > > >> > > > >> The reason I delayed the implementation of VirtualObjects is that > > we > > > >> have to reverse the process that transforms VirtualObjectNodes > > > >> into VirtualObjects (that's in > > > >> com.oracle.graal.compiler.gen.DebugInfoBuilder.build(FrameState, > > > >> LabelRef)). > > > >> It shouldn't be so complicated to add this support. I'll give it > > > >> a > > > try. > > > >> > > > >> -Gilles > > > >> > > > >> On Tue, Apr 1, 2014 at 1:07 AM, Tom Deneau > > > wrote: > > > >> > Gilles -- > > > >> > > > > >> > > > > >> > > > > >> > I noticed in one of our java8 lambda tests (not yet pushed to > > > >> > trunk) we had some object allocation that was eliminated by > > escape > > > analysis. > > > >> > But when we try to run this with the trunk now, we get > > > >> > > > > >> > > > > >> > > > > >> > com.oracle.graal.graph.GraalInternalError: unimplemented > > > >> > > > > >> > at > > > >> > > > com.oracle.graal.graph.GraalInternalError.unimplemented(GraalIntern > > > >> > alE > > > >> > rror.java:38) > > > >> > > > > >> > at > > > >> > > > com.oracle.graal.hotspot.hsail.HSAILHotSpotLIRGenerator.getNodeForV > > > >> > alu > > > >> > eFromFrame(HSAILHotSpotLIRGenerator.java:182) > > > >> > > > > >> > at > > > >> > > > com.oracle.graal.hotspot.hsail.HSAILHotSpotLIRGenerator.createFrame > > > >> > Sta > > > >> > te(HSAILHotSpotLIRGenerator.java:149) > > > >> > > > > >> > at > > > >> > > > com.oracle.graal.hotspot.hsail.HSAILHotSpotLIRGenerator.createHostD > > > >> > eop > > > >> > tBranch(HSAILHotSpotLIRGenerator.java:140) > > > >> > > > > >> > > > > >> > > > > >> > where the line 182 in getNodeForValueFromFrame has > > > >> > > > > >> > > > > >> > > > > >> > > > > >> > > > > >> > } else if (localValue instanceof VirtualObject) { > > > >> > > > > >> > throw GraalInternalError.unimplemented(); > > > >> > > > > >> > } > > > >> > > > > >> > > > > >> > > > > >> > > > > >> > > > > >> > What would we need to do to support VirtualObjects at our > > > >> > deoptimization infopoints? > > > >> > > > > >> > > > > >> > > > > >> > > > > >> > > > > >> > (We also don't support stack slots yet, but I think I > > > >> > understand what is needed to support those). > > > >> > > > > >> > > > > >> > > > > >> > -- Tom > > > >> > > > > >> > > > > > From doug.simon at oracle.com Wed May 14 01:00:07 2014 From: doug.simon at oracle.com (doug.simon at oracle.com) Date: Wed, 14 May 2014 01:00:07 +0000 Subject: hg: graal/graal: 6 new changesets Message-ID: <201405140100.s4E10Fiu022974@aojmv0008> Changeset: 29e8926ac631 Author: twisti Date: 2014-05-12 17:26 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/29e8926ac631 remove unused com_oracle_graal_hotspot_meta_HotSpotJavaType ! src/share/vm/classfile/systemDictionary.hpp ! src/share/vm/classfile/vmSymbols.hpp ! src/share/vm/graal/graalJavaAccess.hpp Changeset: 7bbc7fb44264 Author: twisti Date: 2014-05-12 17:26 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/7bbc7fb44264 remove unused com_oracle_graal_api_meta_ConstantPool ! src/share/vm/classfile/vmSymbols.hpp Changeset: d5ae22306650 Author: twisti Date: 2014-05-12 17:31 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/d5ae22306650 remove unused com_oracle_graal_api_meta_ResolvedJavaField ! src/share/vm/classfile/vmSymbols.hpp Changeset: 4612497da67f Author: twisti Date: 2014-05-12 17:44 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/4612497da67f remove unused HotSpotResolvedJavaMethod fields in graalJavaAccess.hpp ! src/share/vm/graal/graalJavaAccess.hpp Changeset: 4e9176d70690 Author: twisti Date: 2014-05-13 14:13 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/4e9176d70690 add documentation to HotSpotVM* annotatations ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/HotSpotVMConstant.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/HotSpotVMField.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/HotSpotVMFlag.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/HotSpotVMType.java Changeset: 55be15d24e45 Author: twisti Date: 2014-05-13 15:03 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/55be15d24e45 use HotSpotVMType for sizeof information ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/HotSpotVMConfig.java ! src/gpu/hsail/vm/vmStructs_hsail.hpp ! src/share/vm/runtime/vmStructs.cpp From duboscq at ssw.jku.at Wed May 14 08:18:25 2014 From: duboscq at ssw.jku.at (Gilles Duboscq) Date: Wed, 14 May 2014 10:18:25 +0200 Subject: VirtualObjects at deoptimization points. In-Reply-To: References: Message-ID: Ok, thanks, I will use that. -Gilles On Wed, May 14, 2014 at 1:11 AM, Tom Deneau wrote: > Gilles -- > > You can try applying the attached patch to create a new test uses virtual > objects and does force a deopt. > When I tried this test with your patch, I did not get the correct results > but I didn't try to trace down whether it was due to anything with > virtual objects or not. > > -- Tom > >> -----Original Message----- >> From: Deneau, Tom >> Sent: Tuesday, May 13, 2014 5:59 PM >> To: Deneau, Tom; Gilles Duboscq >> Cc: graal-dev at openjdk.java.net >> Subject: RE: VirtualObjects at deoptimization points. >> >> Gilles -- >> >> I noticed you had a link to a patch, I applied your patch and the one >> test mentioned below did not get an error at prepareHostGraph time as it >> usually did. >> >> I should add that while this test failed in prepareHostGraph, trying to >> handle a Virtual Object, this test doesn't actually deopt so it doesn't >> really test whether the virtual object can be handled correctly in the >> face of deopt. >> >> I can try to modify it so that it does deopt. >> >> -- Tom >> >> >> > -----Original Message----- >> > From: Deneau, Tom >> > Sent: Tuesday, May 13, 2014 5:53 PM >> > To: 'Gilles Duboscq' >> > Cc: graal-dev at openjdk.java.net >> > Subject: RE: VirtualObjects at deoptimization points. >> > >> > Gilles -- >> > >> > Sorry for the delay in responding... >> > There is one test checked in trunk that currently fails because of >> > lack of VirtualObjectsInDeopt support. >> > >> > The test is >> > com.oracle.graal.compiler.hsail.test.lambda.VecmathNBodyTest >> > It is currently disabled from running by the following >> > (canHandleDeoptVirtualObjects() returns false) but you can comment >> > that out to make it run. >> > >> > @Override >> > protected boolean supportsRequiredCapabilities() { >> > return (canHandleDeoptVirtualObjects()); >> > } >> > >> > I was going to say it should pass if -XX:-UseHSAILDeoptimization is >> > on the command line but I see there is a bug in that it still tries to >> > create the host graph even if UseHSAILDeoptimization is false. This >> > logic can be fixed in HSAILHotSpotBackend.java by this little patch. >> > >> > --- >> > >> a/graal/com.oracle.graal.hotspot.hsail/src/com/oracle/graal/hotspot/hsai >> > l/HSAILHotSpotBackend.java Tue May 13 15:38:56 2014 -0500 >> > +++ >> > >> b/graal/com.oracle.graal.hotspot.hsail/src/com/oracle/graal/hotspot/hsai >> > l/HSAILHotSpotBackend.java Tue May 13 17:49:29 2014 -0500 >> > @@ -924,7 +924,9 @@ >> > >> > ExternalCompilationResult compilationResult = >> > (ExternalCompilationResult) crb.compilationResult; >> > HSAILHotSpotLIRGenerationResult lirGenRes = >> > ((HSAILCompilationResultBuilder) crb).lirGenRes; >> > - compilationResult.setHostGraph(prepareHostGraph(method, >> > lirGenRes.getDeopts(), getProviders(), config, numSRegs, numDRegs)); >> > + if (useHSAILDeoptimization) { >> > + compilationResult.setHostGraph(prepareHostGraph(method, >> > lirGenRes.getDeopts(), getProviders(), config, numSRegs, numDRegs)); >> > + } >> > } >> > >> > -- Tom >> > >> > >> > > -----Original Message----- >> > > From: gilwooden at gmail.com [mailto:gilwooden at gmail.com] On Behalf Of >> > > Gilles Duboscq >> > > Sent: Sunday, May 04, 2014 12:17 PM >> > > To: Deneau, Tom >> > > Cc: graal-dev at openjdk.java.net >> > > Subject: Re: VirtualObjects at deoptimization points. >> > > >> > > Hello, >> > > >> > > I currently have a prototype [1] that i would like to test. Before >> > > creating my own tests, i was wondering if you already have tests for >> > > this or if you know of tests that have escaping objects? >> > > >> > > -Gilles >> > > >> > > [1] http://cr.openjdk.java.net/~gdub/HSAILVirtualObjectDeopt.patch >> > > >> > > On Fri, May 2, 2014 at 7:21 PM, Tom Deneau >> wrote: >> > > > Hi Gilles -- >> > > > >> > > > Could I get an update on the support for VirtualObjects in the >> > > > host >> > > deopt trampoline code? >> > > > >> > > > -- Tom D. >> > > > >> > > >> -----Original Message----- >> > > >> From: gilwooden at gmail.com [mailto:gilwooden at gmail.com] On Behalf >> > > >> Of Gilles Duboscq >> > > >> Sent: Thursday, April 03, 2014 5:04 AM >> > > >> To: Deneau, Tom >> > > >> Cc: graal-dev at openjdk.java.net >> > > >> Subject: Re: VirtualObjects at deoptimization points. >> > > >> >> > > >> Hello Tom, >> > > >> >> > > >> The reason I delayed the implementation of VirtualObjects is that >> > we >> > > >> have to reverse the process that transforms VirtualObjectNodes >> > > >> into VirtualObjects (that's in >> > > >> com.oracle.graal.compiler.gen.DebugInfoBuilder.build(FrameState, >> > > >> LabelRef)). >> > > >> It shouldn't be so complicated to add this support. I'll give it >> > > >> a >> > > try. >> > > >> >> > > >> -Gilles >> > > >> >> > > >> On Tue, Apr 1, 2014 at 1:07 AM, Tom Deneau >> > > wrote: >> > > >> > Gilles -- >> > > >> > >> > > >> > >> > > >> > >> > > >> > I noticed in one of our java8 lambda tests (not yet pushed to >> > > >> > trunk) we had some object allocation that was eliminated by >> > escape >> > > analysis. >> > > >> > But when we try to run this with the trunk now, we get >> > > >> > >> > > >> > >> > > >> > >> > > >> > com.oracle.graal.graph.GraalInternalError: unimplemented >> > > >> > >> > > >> > at >> > > >> > >> > com.oracle.graal.graph.GraalInternalError.unimplemented(GraalIntern >> > > >> > alE >> > > >> > rror.java:38) >> > > >> > >> > > >> > at >> > > >> > >> > com.oracle.graal.hotspot.hsail.HSAILHotSpotLIRGenerator.getNodeForV >> > > >> > alu >> > > >> > eFromFrame(HSAILHotSpotLIRGenerator.java:182) >> > > >> > >> > > >> > at >> > > >> > >> > com.oracle.graal.hotspot.hsail.HSAILHotSpotLIRGenerator.createFrame >> > > >> > Sta >> > > >> > te(HSAILHotSpotLIRGenerator.java:149) >> > > >> > >> > > >> > at >> > > >> > >> > com.oracle.graal.hotspot.hsail.HSAILHotSpotLIRGenerator.createHostD >> > > >> > eop >> > > >> > tBranch(HSAILHotSpotLIRGenerator.java:140) >> > > >> > >> > > >> > >> > > >> > >> > > >> > where the line 182 in getNodeForValueFromFrame has >> > > >> > >> > > >> > >> > > >> > >> > > >> > >> > > >> > >> > > >> > } else if (localValue instanceof VirtualObject) { >> > > >> > >> > > >> > throw GraalInternalError.unimplemented(); >> > > >> > >> > > >> > } >> > > >> > >> > > >> > >> > > >> > >> > > >> > >> > > >> > >> > > >> > What would we need to do to support VirtualObjects at our >> > > >> > deoptimization infopoints? >> > > >> > >> > > >> > >> > > >> > >> > > >> > >> > > >> > >> > > >> > (We also don't support stack slots yet, but I think I >> > > >> > understand what is needed to support those). >> > > >> > >> > > >> > >> > > >> > >> > > >> > -- Tom >> > > >> > >> > > >> > >> > > > From yudi.zheng at usi.ch Wed May 14 17:56:04 2014 From: yudi.zheng at usi.ch (Yudi Zheng) Date: Wed, 14 May 2014 17:56:04 +0000 Subject: buggy behavior in AMD64NodeLIRBuilder.emitCompareBranchMemory In-Reply-To: <0617F35B-7FED-43C4-999B-945E2A279E01@oracle.com> References: <0617F35B-7FED-43C4-999B-945E2A279E01@oracle.com> Message-ID: In case you might need it, please find attached the simplified test case. During the TailDuplicationPhase when compiling TailDuplicatoinTest.bar, some ObjectEqualsNode is evaluated to false.. (com.oracle.graal.nodes.calc.ObjectEqualsNode.java#64) - Yudi On 13 May 2014, at 00:40, Tom Rodriguez > wrote: Thanks for the report. I?m looking into it. tom On May 12, 2014, at 1:10 PM, Yudi Zheng > wrote: Hi, 1. A minor problem is that the default TypeProfileWidth is 2, resulting in lots of megamorphic-inlining with a probability of 60~70% in many cases, instead of polymorphic-inlining. 2. When running with -XX:TypeProfileWidth=8, I observed buggy behavior: mx vm -XX:+BootstrapGraal -XX:TypeProfileWidth=8 -version Bootstrapping Graal.......................com.oracle.graal.compiler.common.GraalInternalError: should not reach here at lir instruction: B192 at 1350 LCMP (address: [rax|j + 24], y: long[33286881400|0x7c00d8078]{HotSpotType}) kind: long [B0, B2, B3, B5, B6, B8, B416, B419, B9, B11, B12, B14, B16, B17, B19, B21, B413, B23, B25, B26, B28, B29, B31, B409, B412, B32, B33, B35, B36, B38, B39, B41, B42, B44, B45, B47, B49, B50, B52, B54, B53, B55, B56, B57, B59, B61, B63, B65, B66, B67, B69, B70, B72, B74, B77, B79, B80, B94, B96, B98, B99, B101, B102, B103, B104, B107, B108, B109, B110, B113, B114, B115, B117, B118, B120, B122, B125, B127, B128, B129, B143, B145, B147, B148, B160, B126, B119, B149, B116, B130, B132, B153, B133, B136, B138, B139, B141, B142, B137, B140, B150, B134, B168, B105, B166, B171, B180, B181, B183, B186, B188, B190, B192, B194, B196, B198, B200, B197, B161, B170, B179, B177, B178, B184, B403, B78, B193, B202, B203, B204, B209, B211, B212, B214, B399, B401, B215, B216, B218, B220, B222, B397, B71, B208, B205, B206, B100, B195, B201, B187, B189, B68, B191, B199, B219, B224, B226, B228, B229, B231, B233, B394, B395, B221, B223, B82, B84, B173, B174, B154, B155, B51, B48, B232, B235, B239, B393, B236, B238, B234, B85, B87, B89, B90, B92, B93, B88, B240, B242, B284, B286, B288, B289, B291, B294, B296, B297, B299, B300, B302, B304, B307, B308, B310, B311, B313, B315, B317, B318, B320, B322, B323, B325, B326, B327, B343, B345, B346, B348, B349, B351, B354, B356, B357, B358, B360, B362, B364, B365, B367, B369, B372, B368, B373, B83, B371, B46, B352, B237, B287, B316, B330, B332, B333, B335, B336, B337, B244, B246, B247, B249, B250, B252, B254, B257, B258, B260, B261, B263, B265, B267, B268, B270, B273, B275, B276, B370, B266, B207, B285, B314, B264, B91, B355, B295, B245, B339, B384, B301, B306, B251, B256, B390, B391, B281, B283, B167, B282, B347, B382, B344, B30, B27, B378, B379, B175, B385, B388, B324, B386, B34, B407, B259, B280, B402, B312, B387, B309, B62, B389, B24, B410, B210, B392, B165, B230, B278, B159, B415, B396, B135, B404, B262, B169, B157, B10, B381, B15, B331, B376, B277, B405, B414, B37, B1, B213, B398, B417, B279, B418, B408, B400, B176, B338, B58, B40, B151, B274, B411, B380, B375, B334, B7, B340, B64, B4, B377, B406, B60, B13, B172, B163, B106, B86, B217, B18, B112, B383] at com.oracle.graal.compiler.common.GraalInternalError.shouldNotReachHere(GraalInternalError.java:44) at com.oracle.graal.lir.amd64.AMD64Compare$CompareMemoryOp.emitMemAccess(AMD64Compare.java:129) at com.oracle.graal.lir.amd64.AMD64Move$MemOp.emitCode(AMD64Move.java:129) at com.oracle.graal.lir.amd64.AMD64LIRInstruction.emitCode(AMD64LIRInstruction.java:36) at com.oracle.graal.lir.asm.CompilationResultBuilder.emitOp(CompilationResultBuilder.java:350) at com.oracle.graal.lir.asm.CompilationResultBuilder.emitBlock(CompilationResultBuilder.java:341) at com.oracle.graal.lir.asm.CompilationResultBuilder.emit(CompilationResultBuilder.java:323) at com.oracle.graal.hotspot.amd64.AMD64HotSpotBackend.emitCodeBody(AMD64HotSpotBackend.java:301) at com.oracle.graal.hotspot.amd64.AMD64HotSpotBackend.emitCode(AMD64HotSpotBackend.java:254) at com.oracle.graal.compiler.GraalCompiler.emitCode(GraalCompiler.java:288) at com.oracle.graal.compiler.GraalCompiler.emitBackEnd(GraalCompiler.java:200) at com.oracle.graal.compiler.GraalCompiler.compileGraph(GraalCompiler.java:141) at com.oracle.graal.hotspot.CompilationTask.runCompilation(CompilationTask.java:302) at com.oracle.graal.hotspot.CompilationTask.run(CompilationTask.java:159) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) at java.lang.Thread.run(Thread.java:745) at com.oracle.graal.compiler.CompilerThread.run(CompilerThread.java:48) The potential bug can be tracked in com.oracle.graal.compiler.amd64.AMD64NodeLIRBuilder.emitCompareBranchMemory (-G:Dump= -G:MethodFilter=com.oracle.graal.compiler.amd64.AMD64NodeLIRBuilder.emitCompareBranchMemory), and can be bypassed either by not inlining com.oracle.graal.compiler.amd64.AMD64NodeLIRBuilder.getMemoryKind, or by skipping the TailDuplicationPhase. I guess that the TailDuplicationPhase dropped some of the IfNode. Could be verified using the following code: protected ComplexMatchResult emitCompareBranchMemory(IfNode ifNode, CompareNode compare, ValueNode value, Access access) { Condition cond = compare.condition(); Kind kind = getMemoryKind(access); if (kind != Kind.Long) { notInlinedMethodPlaceHolder(kind); } After tail duplication at some merge node, the IfNode disappeared.. - Yudi From tom.rodriguez at oracle.com Wed May 14 18:01:38 2014 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Wed, 14 May 2014 11:01:38 -0700 Subject: buggy behavior in AMD64NodeLIRBuilder.emitCompareBranchMemory In-Reply-To: References: <0617F35B-7FED-43C4-999B-945E2A279E01@oracle.com> Message-ID: Thanks for the test case. I?ve been narrowing it down in between a few other things but I was seeing an issue with a mirrored unsigned compare. It generates bad code in the compiler itself and then fails much later. It?s possible there are multiple things going on. Anyway, I hope to have it resolved today. tom On May 14, 2014, at 10:56 AM, Yudi Zheng wrote: > In case you might need it, please find attached the simplified test case. > During the TailDuplicationPhase when compiling TailDuplicatoinTest.bar, > some ObjectEqualsNode is evaluated to false.. > (com.oracle.graal.nodes.calc.ObjectEqualsNode.java#64) > > - Yudi > > > On 13 May 2014, at 00:40, Tom Rodriguez > wrote: > > Thanks for the report. I?m looking into it. > > tom > > On May 12, 2014, at 1:10 PM, Yudi Zheng > wrote: > > Hi, > > 1. A minor problem is that the default TypeProfileWidth is 2, resulting in lots of megamorphic-inlining with a probability of 60~70% in many cases, > instead of polymorphic-inlining. > > 2. When running with -XX:TypeProfileWidth=8, I observed buggy behavior: > > mx vm -XX:+BootstrapGraal -XX:TypeProfileWidth=8 -version > Bootstrapping Graal.......................com.oracle.graal.compiler.common.GraalInternalError: should not reach here > at lir instruction: B192 at 1350 LCMP (address: [rax|j + 24], y: long[33286881400|0x7c00d8078]{HotSpotType}) kind: long > [B0, B2, B3, B5, B6, B8, B416, B419, B9, B11, B12, B14, B16, B17, B19, B21, B413, B23, B25, B26, B28, B29, B31, B409, B412, B32, B33, B35, B36, B38, B39, B41, B42, B44, B45, B47, B49, B50, B52, B54, B53, B55, B56, B57, B59, B61, B63, B65, B66, B67, B69, B70, B72, B74, B77, B79, B80, B94, B96, B98, B99, B101, B102, B103, B104, B107, B108, B109, B110, B113, B114, B115, B117, B118, B120, B122, B125, B127, B128, B129, B143, B145, B147, B148, B160, B126, B119, B149, B116, B130, B132, B153, B133, B136, B138, B139, B141, B142, B137, B140, B150, B134, B168, B105, B166, B171, B180, B181, B183, B186, B188, B190, B192, B194, B196, B198, B200, B197, B161, B170, B179, B177, B178, B184, B403, B78, B193, B202, B203, B204, B209, B211, B212, B214, B399, B401, B215, B216, B218, B220, B222, B397, B71, B208, B205, B206, B100, B195, B201, B187, B189, B68, B191, B199, B219, B224, B226, B228, B229, B231, B233, B394, B395, B221, B223, B82, B84, B173, B174, B154, B155, B51, B48, B232, B235, B239, B393, B236, B238, B234, B85, B87, B89, B90, B92, B93, B88, B240, B242, B284, B286, B288, B289, B291, B294, B296, B297, B299, B300, B302, B304, B307, B308, B310, B311, B313, B315, B317, B318, B320, B322, B323, B325, B326, B327, B343, B345, B346, B348, B349, B351, B354, B356, B357, B358, B360, B362, B364, B365, B367, B369, B372, B368, B373, B83, B371, B46, B352, B237, B287, B316, B330, B332, B333, B335, B336, B337, B244, B246, B247, B249, B250, B252, B254, B257, B258, B260, B261, B263, B265, B267, B268, B270, B273, B275, B276, B370, B266, B207, B285, B314, B264, B91, B355, B295, B245, B339, B384, B301, B306, B251, B256, B390, B391, B281, B283, B167, B282, B347, B382, B344, B30, B27, B378, B379, B175, B385, B388, B324, B386, B34, B407, B259, B280, B402, B312, B387, B309, B62, B389, B24, B410, B210, B392, B165, B230, B278, B159, B415, B396, B135, B404, B262, B169, B157, B10, B381, B15, B331, B376, B277, B405, B414, B37, B1, B213, B398, B417, B279, B418, B408, B400, B176, B338, B58, B40, B151, B274, B411, B380, B375, B334, B7, B340, B64, B4, B377, B406, B60, B13, B172, B163, B106, B86, B217, B18, B112, B383] > at com.oracle.graal.compiler.common.GraalInternalError.shouldNotReachHere(GraalInternalError.java:44) > at com.oracle.graal.lir.amd64.AMD64Compare$CompareMemoryOp.emitMemAccess(AMD64Compare.java:129) > at com.oracle.graal.lir.amd64.AMD64Move$MemOp.emitCode(AMD64Move.java:129) > at com.oracle.graal.lir.amd64.AMD64LIRInstruction.emitCode(AMD64LIRInstruction.java:36) > at com.oracle.graal.lir.asm.CompilationResultBuilder.emitOp(CompilationResultBuilder.java:350) > at com.oracle.graal.lir.asm.CompilationResultBuilder.emitBlock(CompilationResultBuilder.java:341) > at com.oracle.graal.lir.asm.CompilationResultBuilder.emit(CompilationResultBuilder.java:323) > at com.oracle.graal.hotspot.amd64.AMD64HotSpotBackend.emitCodeBody(AMD64HotSpotBackend.java:301) > at com.oracle.graal.hotspot.amd64.AMD64HotSpotBackend.emitCode(AMD64HotSpotBackend.java:254) > at com.oracle.graal.compiler.GraalCompiler.emitCode(GraalCompiler.java:288) > at com.oracle.graal.compiler.GraalCompiler.emitBackEnd(GraalCompiler.java:200) > at com.oracle.graal.compiler.GraalCompiler.compileGraph(GraalCompiler.java:141) > at com.oracle.graal.hotspot.CompilationTask.runCompilation(CompilationTask.java:302) > at com.oracle.graal.hotspot.CompilationTask.run(CompilationTask.java:159) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) > at java.lang.Thread.run(Thread.java:745) > at com.oracle.graal.compiler.CompilerThread.run(CompilerThread.java:48) > > > The potential bug can be tracked in com.oracle.graal.compiler.amd64.AMD64NodeLIRBuilder.emitCompareBranchMemory > (-G:Dump= -G:MethodFilter=com.oracle.graal.compiler.amd64.AMD64NodeLIRBuilder.emitCompareBranchMemory), > and can be bypassed either by not inlining com.oracle.graal.compiler.amd64.AMD64NodeLIRBuilder.getMemoryKind, > or by skipping the TailDuplicationPhase. > > I guess that the TailDuplicationPhase dropped some of the IfNode. Could be verified using the following code: > > protected ComplexMatchResult emitCompareBranchMemory(IfNode ifNode, CompareNode compare, ValueNode value, Access access) { > Condition cond = compare.condition(); > Kind kind = getMemoryKind(access); > > if (kind != Kind.Long) { > notInlinedMethodPlaceHolder(kind); > } > > After tail duplication at some merge node, the IfNode disappeared.. > > - Yudi > > > > > From tom.deneau at amd.com Wed May 14 21:00:43 2014 From: tom.deneau at amd.com (Deneau, Tom) Date: Wed, 14 May 2014 21:00:43 +0000 Subject: recording that a certain lowering took place Message-ID: If I call GraalCompiler.compileGraph and in my HSAILLoweringProvider I want to record that a certain lowering took place for this compilation and then possibly act on that in HSAILHotSpotBackend (for this same compilation), is there a good way to do that? Reason: we have to add some instructions in our HSAIL prologue based on whether any allocations are in the compilation. The way we do it now, we cast too wide a net. Ideally I would want a solution where we don't have to search thru all the LIR nodes but I guess we could search if it were unambiguous. -- Tom From tom.deneau at amd.com Wed May 14 22:57:46 2014 From: tom.deneau at amd.com (Deneau, Tom) Date: Wed, 14 May 2014 22:57:46 +0000 Subject: exception from javaCall but no StackTraceElements Message-ID: We are seeing an occasional failure on one of our hsail junit tests, I will describe here... There is a flag, UseHSAILSafepoints and one effect of that is that if a kernel is executing and sees that the VM is desiring a safepoint, then new workitems will not get started. This occurs even if the hsail code in the kernel itself has no "compiler safepoints". The workitems that do not start as mentioned above are marked as never-rans and are then after all the workitems finish each never-ran is run as a javaCall to the underlying java method. All of this is done in "thread-in-VM" mode. This particular test is set up to have 589824 workitems and the very last workitem is designed to cause an ArrayOutOfBoundsException. A try block surrounding the kernel call and we catch any exceptions and compare the first frame of the stack trace of the exception with the first frame that occurred when the kernel was run in pure java mode. We always get an exception thrown from the last javaCall but occasionally the exception has no stackTraceElements so our comparison fails in that case. I assume an exception in a javaCall is recorded in the thread and then when the thread returns from VM mode to Java mode. Does anyone know why the exception would sometimes have no stackTraceElements? -- Tom From christian.thalinger at oracle.com Wed May 14 23:31:45 2014 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Wed, 14 May 2014 16:31:45 -0700 Subject: exception from javaCall but no StackTraceElements In-Reply-To: References: Message-ID: On May 14, 2014, at 3:57 PM, Deneau, Tom wrote: > We are seeing an occasional failure on one of our hsail junit tests, I will describe here... > > There is a flag, UseHSAILSafepoints and one effect of that is that if a kernel is executing and sees that the VM is desiring a safepoint, then new workitems will not get started. This occurs even if the hsail code in the kernel itself has no "compiler safepoints". > > The workitems that do not start as mentioned above are marked as never-rans and are then after all the workitems finish each never-ran is run as a javaCall to the underlying java method. All of this is done in "thread-in-VM" mode. > > This particular test is set up to have 589824 workitems and the very last workitem is designed to cause an ArrayOutOfBoundsException. A try block surrounding the kernel call and we catch any exceptions and compare the first frame of the stack trace of the exception with the first frame that occurred when the kernel was run in pure java mode. > > We always get an exception thrown from the last javaCall but occasionally the exception has no stackTraceElements so our comparison fails in that case. > > I assume an exception in a javaCall is recorded in the thread and then when the thread returns from VM mode to Java mode. > > Does anyone know why the exception would sometimes have no stackTraceElements? Not sure if I?m following correctly but the ?empty? exception is coming from running Java code on the CPU, correct? It might be related to OmitStackTraceInFastThrow. Try to turn it off. > > -- Tom > > From doug.simon at oracle.com Thu May 15 01:00:06 2014 From: doug.simon at oracle.com (doug.simon at oracle.com) Date: Thu, 15 May 2014 01:00:06 +0000 Subject: hg: graal/graal: 21 new changesets Message-ID: <201405150100.s4F10Y5C007862@aojmv0008> Changeset: 2d63ce48d222 Author: Michael Van De Vanter Date: 2014-05-13 18:28 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/2d63ce48d222 Truffle/Source Attribution: Replace direct creation of SourceSection objects with factory methods on Source; two of these greatly simplify source attribution by automatically computing either the row/column start location from a character offset or vice versa, depending on what?s made available from the parser. Minor API change on Visualizer. ! graal/com.oracle.truffle.api/src/com/oracle/truffle/api/Source.java ! graal/com.oracle.truffle.api/src/com/oracle/truffle/api/SourceSection.java - graal/com.oracle.truffle.api/src/com/oracle/truffle/api/impl/DefaultSourceSection.java ! graal/com.oracle.truffle.api/src/com/oracle/truffle/api/instrument/Visualizer.java ! graal/com.oracle.truffle.api/src/com/oracle/truffle/api/instrument/impl/DefaultVisualizer.java ! graal/com.oracle.truffle.api/src/com/oracle/truffle/api/source/SourceManager.java Changeset: 8de99b84c9cd Author: Michael Van De Vanter Date: 2014-05-13 18:29 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/8de99b84c9cd SL: correct to use new SourceAttribution factory methods. ! graal/com.oracle.truffle.sl/src/com/oracle/truffle/sl/parser/SLNodeFactory.java Changeset: dcaf3993ad17 Author: Michael Van De Vanter Date: 2014-05-13 18:31 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/dcaf3993ad17 Merge with 55be15d24e45e5636ee14d657616c6ffac039178 Changeset: f02fb7c5a1cc Author: Tom Rodriguez Date: 2014-05-13 20:20 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/f02fb7c5a1cc convert signed range tests into an unsigned compare ! graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/IfCanonicalizerTest.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/IfNode.java Changeset: 172484b8f800 Author: Tom Rodriguez Date: 2014-05-13 20:20 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/172484b8f800 don't deopt on large array allocations ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/NewObjectSnippets.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/stubs/NewArrayStub.java Changeset: 3b6f898a2384 Author: Tom Rodriguez Date: 2014-05-14 01:24 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/3b6f898a2384 add missing case in assertDeepEquals ! graal/com.oracle.graal.test/src/com/oracle/graal/test/GraalTest.java Changeset: 92a939e551c4 Author: Tom Rodriguez Date: 2014-05-14 01:25 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/92a939e551c4 fix unsigned compare, expand test ! graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/IfCanonicalizerTest.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/IfNode.java Changeset: 40f13c935d8b Author: Bernhard Urban Date: 2014-05-14 11:08 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/40f13c935d8b mx: fix constructor call ! mx/mx_graal.py Changeset: 83c69954bbaa Author: Bernhard Urban Date: 2014-05-14 11:19 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/83c69954bbaa mxtool: distribution dependency should be a list ! mx/mx_graal.py ! mx/projects ! mxtool/mx.py Changeset: 19ec9885ce6e Author: Doug Simon Date: 2014-05-14 12:37 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/19ec9885ce6e added metric to count the input graph sizes for phases ! graal/com.oracle.graal.phases/src/com/oracle/graal/phases/BasePhase.java Changeset: 2208a130d636 Author: Gilles Duboscq Date: 2014-05-04 18:58 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/2208a130d636 HSAIL Deopt support for VirtualObjects. Only create the host graph is there are deopts. Add a test provided by Tom Deneau. ! graal/com.oracle.graal.compiler.hsail.test.infra/src/com/oracle/graal/compiler/hsail/test/infra/GraalKernelTester.java + graal/com.oracle.graal.compiler.hsail.test/src/com/oracle/graal/compiler/hsail/test/lambda/VecmathNBodyDeoptTest.java ! graal/com.oracle.graal.hotspot.hsail/src/com/oracle/graal/hotspot/hsail/HSAILHotSpotBackend.java ! graal/com.oracle.graal.virtual/src/com/oracle/graal/virtual/nodes/VirtualObjectState.java Changeset: e500d6900328 Author: Lukas Stadler Date: 2014-05-14 13:50 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/e500d6900328 cleanup after ReplaceIntrinsicsPhase ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/PartialEvaluator.java Changeset: 88a03dfdf712 Author: Lukas Stadler Date: 2014-05-14 17:23 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/88a03dfdf712 remove some debug code in HotSpotTruffleRuntime ! graal/com.oracle.graal.truffle.hotspot/src/com/oracle/graal/truffle/hotspot/HotSpotTruffleRuntime.java Changeset: a130d38c9d28 Author: Miguel Garcia Date: 2014-05-13 21:40 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/a130d38c9d28 [inlining] privatizing methods in InliningData ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/inlining/InliningPhase.java Changeset: cd436bc5d63a Author: Miguel Garcia Date: 2014-05-14 18:13 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/cd436bc5d63a [inlining] moving InlineInfo and subclasses to package inlining.info ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/inlining/InliningPhase.java ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/inlining/InliningUtil.java + graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/inlining/info/AbstractInlineInfo.java + graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/inlining/info/AssumptionInlineInfo.java + graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/inlining/info/ExactInlineInfo.java + graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/inlining/info/InlineInfo.java + graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/inlining/info/MultiTypeGuardInlineInfo.java + graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/inlining/info/TypeGuardInlineInfo.java Changeset: c93c3dc57f53 Author: Miguel Garcia Date: 2014-05-14 16:07 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/c93c3dc57f53 [single-pass-iter] readability and one more assertion ! graal/com.oracle.graal.phases/src/com/oracle/graal/phases/graph/SinglePassNodeIterator.java Changeset: 2bc323b43467 Author: Miguel Garcia Date: 2014-05-14 16:13 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/2bc323b43467 [single-pass-iter] sharpening the declared type of PathStart.node ! graal/com.oracle.graal.phases/src/com/oracle/graal/phases/graph/SinglePassNodeIterator.java Changeset: 84cf47e9c9f3 Author: Miguel Garcia Date: 2014-05-14 16:52 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/84cf47e9c9f3 [single-pass-iter] owner-is-mutator access protocol for queued states ! graal/com.oracle.graal.phases/src/com/oracle/graal/phases/graph/SinglePassNodeIterator.java Changeset: 9c9bb06a6b83 Author: Miguel Garcia Date: 2014-05-14 17:16 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/9c9bb06a6b83 [single-pass-iter] skipping redundant state-cloning ! graal/com.oracle.graal.phases/src/com/oracle/graal/phases/graph/SinglePassNodeIterator.java Changeset: bfbbf69fc507 Author: Miguel Garcia Date: 2014-05-14 18:55 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/bfbbf69fc507 [inlining] re-adding file header lost during refactoring ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/inlining/info/AssumptionInlineInfo.java Changeset: 034a5acbae14 Author: Miguel Garcia Date: 2014-05-14 19:11 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/034a5acbae14 [single-pass-iter] same check formulated differently so as to appease findbugs ! graal/com.oracle.graal.phases/src/com/oracle/graal/phases/graph/SinglePassNodeIterator.java From tom.rodriguez at oracle.com Thu May 15 04:12:51 2014 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Wed, 14 May 2014 21:12:51 -0700 Subject: buggy behavior in AMD64NodeLIRBuilder.emitCompareBranchMemory In-Reply-To: References: <0617F35B-7FED-43C4-999B-945E2A279E01@oracle.com> Message-ID: <1A858417-AF09-4CF3-BABD-7328223AF5DD@oracle.com> I think this is actually a bug in tail duplication. I?ve been chasing my tail a bit on this because the code that reports the error is only compiled when exercising the matching code, so I assumed they were causally connected. I just added logic that allows the matching logic to run but never installs the match result, so the code is exercised but doesn?t actually change code generation and it still shows up. Looking at the graph I can see if the isInt guard disappear during tail duplication which causes the problem I?m seeing. https://lafo.ssw.uni-linz.ac.at/jira/browse/GRAAL-791 has a patch that makes it easy to reproduce. Hopefully Lukas can get to the bottom of it. tom On May 14, 2014, at 11:01 AM, Tom Rodriguez wrote: > Thanks for the test case. I?ve been narrowing it down in between a few other things but I was seeing an issue with a mirrored unsigned compare. It generates bad code in the compiler itself and then fails much later. It?s possible there are multiple things going on. Anyway, I hope to have it resolved today. > > tom > > On May 14, 2014, at 10:56 AM, Yudi Zheng wrote: > >> In case you might need it, please find attached the simplified test case. >> During the TailDuplicationPhase when compiling TailDuplicatoinTest.bar, >> some ObjectEqualsNode is evaluated to false.. >> (com.oracle.graal.nodes.calc.ObjectEqualsNode.java#64) >> >> - Yudi >> >> >> On 13 May 2014, at 00:40, Tom Rodriguez > wrote: >> >> Thanks for the report. I?m looking into it. >> >> tom >> >> On May 12, 2014, at 1:10 PM, Yudi Zheng > wrote: >> >> Hi, >> >> 1. A minor problem is that the default TypeProfileWidth is 2, resulting in lots of megamorphic-inlining with a probability of 60~70% in many cases, >> instead of polymorphic-inlining. >> >> 2. When running with -XX:TypeProfileWidth=8, I observed buggy behavior: >> >> mx vm -XX:+BootstrapGraal -XX:TypeProfileWidth=8 -version >> Bootstrapping Graal.......................com.oracle.graal.compiler.common.GraalInternalError: should not reach here >> at lir instruction: B192 at 1350 LCMP (address: [rax|j + 24], y: long[33286881400|0x7c00d8078]{HotSpotType}) kind: long >> [B0, B2, B3, B5, B6, B8, B416, B419, B9, B11, B12, B14, B16, B17, B19, B21, B413, B23, B25, B26, B28, B29, B31, B409, B412, B32, B33, B35, B36, B38, B39, B41, B42, B44, B45, B47, B49, B50, B52, B54, B53, B55, B56, B57, B59, B61, B63, B65, B66, B67, B69, B70, B72, B74, B77, B79, B80, B94, B96, B98, B99, B101, B102, B103, B104, B107, B108, B109, B110, B113, B114, B115, B117, B118, B120, B122, B125, B127, B128, B129, B143, B145, B147, B148, B160, B126, B119, B149, B116, B130, B132, B153, B133, B136, B138, B139, B141, B142, B137, B140, B150, B134, B168, B105, B166, B171, B180, B181, B183, B186, B188, B190, B192, B194, B196, B198, B200, B197, B161, B170, B179, B177, B178, B184, B403, B78, B193, B202, B203, B204, B209, B211, B212, B214, B399, B401, B215, B216, B218, B220, B222, B397, B71, B208, B205, B206, B100, B195, B201, B187, B189, B68, B191, B199, B219, B224, B226, B228, B229, B231, B233, B394, B395, B221, B223, B82, B84, B173, B174, B154, B155, B51, B48, B232, B235, B239, B393, B236, B238, B234, B85, B87, B89, B90, B92, B93, B88, B240, B242, B284, B286, B288, B289, B291, B294, B296, B297, B299, B300, B302, B304, B307, B308, B310, B311, B313, B315, B317, B318, B320, B322, B323, B325, B326, B327, B343, B345, B346, B348, B349, B351, B354, B356, B357, B358, B360, B362, B364, B365, B367, B369, B372, B368, B373, B83, B371, B46, B352, B237, B287, B316, B330, B332, B333, B335, B336, B337, B244, B246, B247, B249, B250, B252, B254, B257, B258, B260, B261, B263, B265, B267, B268, B270, B273, B275, B276, B370, B266, B207, B285, B314, B264, B91, B355, B295, B245, B339, B384, B301, B306, B251, B256, B390, B391, B281, B283, B167, B282, B347, B382, B344, B30, B27, B378, B379, B175, B385, B388, B324, B386, B34, B407, B259, B280, B402, B312, B387, B309, B62, B389, B24, B410, B210, B392, B165, B230, B278, B159, B415, B396, B135, B404, B262, B169, B157, B10, B381, B15, B331, B376, B277, B405, B414, B37, B1, B213, B398, B417, B279, B418, B408, B400, B176, B338, B58, B40, B151, B274, B411, B380, B375, B334, B7, B340, B64, B4, B377, B406, B60, B13, B172, B163, B106, B86, B217, B18, B112, B383] >> at com.oracle.graal.compiler.common.GraalInternalError.shouldNotReachHere(GraalInternalError.java:44) >> at com.oracle.graal.lir.amd64.AMD64Compare$CompareMemoryOp.emitMemAccess(AMD64Compare.java:129) >> at com.oracle.graal.lir.amd64.AMD64Move$MemOp.emitCode(AMD64Move.java:129) >> at com.oracle.graal.lir.amd64.AMD64LIRInstruction.emitCode(AMD64LIRInstruction.java:36) >> at com.oracle.graal.lir.asm.CompilationResultBuilder.emitOp(CompilationResultBuilder.java:350) >> at com.oracle.graal.lir.asm.CompilationResultBuilder.emitBlock(CompilationResultBuilder.java:341) >> at com.oracle.graal.lir.asm.CompilationResultBuilder.emit(CompilationResultBuilder.java:323) >> at com.oracle.graal.hotspot.amd64.AMD64HotSpotBackend.emitCodeBody(AMD64HotSpotBackend.java:301) >> at com.oracle.graal.hotspot.amd64.AMD64HotSpotBackend.emitCode(AMD64HotSpotBackend.java:254) >> at com.oracle.graal.compiler.GraalCompiler.emitCode(GraalCompiler.java:288) >> at com.oracle.graal.compiler.GraalCompiler.emitBackEnd(GraalCompiler.java:200) >> at com.oracle.graal.compiler.GraalCompiler.compileGraph(GraalCompiler.java:141) >> at com.oracle.graal.hotspot.CompilationTask.runCompilation(CompilationTask.java:302) >> at com.oracle.graal.hotspot.CompilationTask.run(CompilationTask.java:159) >> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) >> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) >> at java.lang.Thread.run(Thread.java:745) >> at com.oracle.graal.compiler.CompilerThread.run(CompilerThread.java:48) >> >> >> The potential bug can be tracked in com.oracle.graal.compiler.amd64.AMD64NodeLIRBuilder.emitCompareBranchMemory >> (-G:Dump= -G:MethodFilter=com.oracle.graal.compiler.amd64.AMD64NodeLIRBuilder.emitCompareBranchMemory), >> and can be bypassed either by not inlining com.oracle.graal.compiler.amd64.AMD64NodeLIRBuilder.getMemoryKind, >> or by skipping the TailDuplicationPhase. >> >> I guess that the TailDuplicationPhase dropped some of the IfNode. Could be verified using the following code: >> >> protected ComplexMatchResult emitCompareBranchMemory(IfNode ifNode, CompareNode compare, ValueNode value, Access access) { >> Condition cond = compare.condition(); >> Kind kind = getMemoryKind(access); >> >> if (kind != Kind.Long) { >> notInlinedMethodPlaceHolder(kind); >> } >> >> After tail duplication at some merge node, the IfNode disappeared.. >> >> - Yudi >> >> >> >> >> > From yudi.zheng at usi.ch Thu May 15 06:11:14 2014 From: yudi.zheng at usi.ch (Yudi Zheng) Date: Thu, 15 May 2014 06:11:14 +0000 Subject: buggy behavior in AMD64NodeLIRBuilder.emitCompareBranchMemory In-Reply-To: <1A858417-AF09-4CF3-BABD-7328223AF5DD@oracle.com> References: <0617F35B-7FED-43C4-999B-945E2A279E01@oracle.com> <1A858417-AF09-4CF3-BABD-7328223AF5DD@oracle.com> Message-ID: <6601CE83-C5E2-4A3F-8D64-7FDAF9978720@usi.ch> The simplified test case I sent yesterday is the following: public class TailDuplicationTest { interface I { } enum P implements I { A, B } final static I CONST_I = new I() { }; public static I foo(int i) { if (i < 32) { return P.A; } else if (i < 64) { return P.B; } else { return CONST_I; } } public int bar(int i) { P instance = (P) foo(i); if (instance != P.B) { return 0; } return 1; } public static void main(String[] args) { TailDuplicationTest t = new TailDuplicationTest(); for (int i = 0; i < 100000; i++) { foo(i % 128); t.bar(i % 64); } } } Look at the graph of TailDuplicationTest.bar, the "return 1" branch is dropped between LoopFullUnroll and TailDuplication. It is caused by a stamp evaluation which compares an illegal "a!# -" with "a!# LTailDuplicationTest$P;" The illegal "a!# -" is generated by ValuePhiNode.inferPhiStamp? I inserted graph dumping at TailDuplicationPhase#328 and ObjectEqualsNode#64. Please have a look at the stamp changes on "48 ValuePhi()" (hopefully the same ID), diff -r 55977f9fa56f graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/calc/ObjectEqualsNode.java --- a/graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/calc/ObjectEqualsNode.java Sun May 11 22:00:06 2014 +0200 +++ b/graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/calc/ObjectEqualsNode.java Thu May 15 08:07:39 2014 +0200 @@ -25,6 +25,7 @@ import com.oracle.graal.api.meta.*; import com.oracle.graal.api.meta.ProfilingInfo.*; import com.oracle.graal.compiler.common.calc.*; +import com.oracle.graal.debug.*; import com.oracle.graal.graph.*; import com.oracle.graal.graph.spi.*; import com.oracle.graal.nodes.*; @@ -62,6 +63,10 @@ if (GraphUtil.unproxify(forX) == GraphUtil.unproxify(forY)) { return TriState.TRUE; } else if (forX.stamp().alwaysDistinct(forY.stamp())) { + if ("bar".equals(graph().method().getName())) { + Debug.dump(graph(), "During canonicalizer phase in tail duplication, ObjectEqualsNode#64"); + } + return TriState.FALSE; } else { return super.evaluate(constantReflection, forX, forY); @@ -119,7 +124,7 @@ /* * One of the two objects has identity, the other doesn't. In code, this looks like * "Integer.valueOf(a) == new Integer(b)", which is always false. - * + * * In other words: an object created via valueOf can never be equal to one created * by new in the same compilation unit. */ diff -r 55977f9fa56f graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/TailDuplicationPhase.java --- a/graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/TailDuplicationPhase.java Sun May 11 22:00:06 2014 +0200 +++ b/graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/TailDuplicationPhase.java Thu May 15 08:07:39 2014 +0200 @@ -326,6 +326,9 @@ phi.setMerge(mergeAfter); } } + if ("bar".equals(graph.method().getName())) { + Debug.dump(graph, "Before canonicalizer phase in tail duplication, TailDuplicationPhase#328"); + } canonicalizer.applyIncremental(graph, phaseContext, startMark); Debug.dump(graph, "After tail duplication at %s", merge); } - Yudi On 15 May 2014, at 06:12, Tom Rodriguez > wrote: I think this is actually a bug in tail duplication. I?ve been chasing my tail a bit on this because the code that reports the error is only compiled when exercising the matching code, so I assumed they were causally connected. I just added logic that allows the matching logic to run but never installs the match result, so the code is exercised but doesn?t actually change code generation and it still shows up. Looking at the graph I can see if the isInt guard disappear during tail duplication which causes the problem I?m seeing. https://lafo.ssw.uni-linz.ac.at/jira/browse/GRAAL-791 has a patch that makes it easy to reproduce. Hopefully Lukas can get to the bottom of it. tom On May 14, 2014, at 11:01 AM, Tom Rodriguez > wrote: Thanks for the test case. I?ve been narrowing it down in between a few other things but I was seeing an issue with a mirrored unsigned compare. It generates bad code in the compiler itself and then fails much later. It?s possible there are multiple things going on. Anyway, I hope to have it resolved today. tom On May 14, 2014, at 10:56 AM, Yudi Zheng > wrote: In case you might need it, please find attached the simplified test case. During the TailDuplicationPhase when compiling TailDuplicatoinTest.bar, some ObjectEqualsNode is evaluated to false.. (com.oracle.graal.nodes.calc.ObjectEqualsNode.java#64) - Yudi On 13 May 2014, at 00:40, Tom Rodriguez > wrote: Thanks for the report. I?m looking into it. tom On May 12, 2014, at 1:10 PM, Yudi Zheng > wrote: Hi, 1. A minor problem is that the default TypeProfileWidth is 2, resulting in lots of megamorphic-inlining with a probability of 60~70% in many cases, instead of polymorphic-inlining. 2. When running with -XX:TypeProfileWidth=8, I observed buggy behavior: mx vm -XX:+BootstrapGraal -XX:TypeProfileWidth=8 -version Bootstrapping Graal.......................com.oracle.graal.compiler.common.GraalInternalError: should not reach here at lir instruction: B192 at 1350 LCMP (address: [rax|j + 24], y: long[33286881400|0x7c00d8078]{HotSpotType}) kind: long [B0, B2, B3, B5, B6, B8, B416, B419, B9, B11, B12, B14, B16, B17, B19, B21, B413, B23, B25, B26, B28, B29, B31, B409, B412, B32, B33, B35, B36, B38, B39, B41, B42, B44, B45, B47, B49, B50, B52, B54, B53, B55, B56, B57, B59, B61, B63, B65, B66, B67, B69, B70, B72, B74, B77, B79, B80, B94, B96, B98, B99, B101, B102, B103, B104, B107, B108, B109, B110, B113, B114, B115, B117, B118, B120, B122, B125, B127, B128, B129, B143, B145, B147, B148, B160, B126, B119, B149, B116, B130, B132, B153, B133, B136, B138, B139, B141, B142, B137, B140, B150, B134, B168, B105, B166, B171, B180, B181, B183, B186, B188, B190, B192, B194, B196, B198, B200, B197, B161, B170, B179, B177, B178, B184, B403, B78, B193, B202, B203, B204, B209, B211, B212, B214, B399, B401, B215, B216, B218, B220, B222, B397, B71, B208, B205, B206, B100, B195, B201, B187, B189, B68, B191, B199, B219, B224, B226, B228, B229, B231, B233, B394, B395, B221, B223, B82, B84, B173, B174, B154, B155, B51, B48, B232, B235, B239, B393, B236, B238, B234, B85, B87, B89, B90, B92, B93, B88, B240, B242, B284, B286, B288, B289, B291, B294, B296, B297, B299, B300, B302, B304, B307, B308, B310, B311, B313, B315, B317, B318, B320, B322, B323, B325, B326, B327, B343, B345, B346, B348, B349, B351, B354, B356, B357, B358, B360, B362, B364, B365, B367, B369, B372, B368, B373, B83, B371, B46, B352, B237, B287, B316, B330, B332, B333, B335, B336, B337, B244, B246, B247, B249, B250, B252, B254, B257, B258, B260, B261, B263, B265, B267, B268, B270, B273, B275, B276, B370, B266, B207, B285, B314, B264, B91, B355, B295, B245, B339, B384, B301, B306, B251, B256, B390, B391, B281, B283, B167, B282, B347, B382, B344, B30, B27, B378, B379, B175, B385, B388, B324, B386, B34, B407, B259, B280, B402, B312, B387, B309, B62, B389, B24, B410, B210, B392, B165, B230, B278, B159, B415, B396, B135, B404, B262, B169, B157, B10, B381, B15, B331, B376, B277, B405, B414, B37, B1, B213, B398, B417, B279, B418, B408, B400, B176, B338, B58, B40, B151, B274, B411, B380, B375, B334, B7, B340, B64, B4, B377, B406, B60, B13, B172, B163, B106, B86, B217, B18, B112, B383] at com.oracle.graal.compiler.common.GraalInternalError.shouldNotReachHere(GraalInternalError.java:44) at com.oracle.graal.lir.amd64.AMD64Compare$CompareMemoryOp.emitMemAccess(AMD64Compare.java:129) at com.oracle.graal.lir.amd64.AMD64Move$MemOp.emitCode(AMD64Move.java:129) at com.oracle.graal.lir.amd64.AMD64LIRInstruction.emitCode(AMD64LIRInstruction.java:36) at com.oracle.graal.lir.asm.CompilationResultBuilder.emitOp(CompilationResultBuilder.java:350) at com.oracle.graal.lir.asm.CompilationResultBuilder.emitBlock(CompilationResultBuilder.java:341) at com.oracle.graal.lir.asm.CompilationResultBuilder.emit(CompilationResultBuilder.java:323) at com.oracle.graal.hotspot.amd64.AMD64HotSpotBackend.emitCodeBody(AMD64HotSpotBackend.java:301) at com.oracle.graal.hotspot.amd64.AMD64HotSpotBackend.emitCode(AMD64HotSpotBackend.java:254) at com.oracle.graal.compiler.GraalCompiler.emitCode(GraalCompiler.java:288) at com.oracle.graal.compiler.GraalCompiler.emitBackEnd(GraalCompiler.java:200) at com.oracle.graal.compiler.GraalCompiler.compileGraph(GraalCompiler.java:141) at com.oracle.graal.hotspot.CompilationTask.runCompilation(CompilationTask.java:302) at com.oracle.graal.hotspot.CompilationTask.run(CompilationTask.java:159) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) at java.lang.Thread.run(Thread.java:745) at com.oracle.graal.compiler.CompilerThread.run(CompilerThread.java:48) The potential bug can be tracked in com.oracle.graal.compiler.amd64.AMD64NodeLIRBuilder.emitCompareBranchMemory (-G:Dump= -G:MethodFilter=com.oracle.graal.compiler.amd64.AMD64NodeLIRBuilder.emitCompareBranchMemory), and can be bypassed either by not inlining com.oracle.graal.compiler.amd64.AMD64NodeLIRBuilder.getMemoryKind, or by skipping the TailDuplicationPhase. I guess that the TailDuplicationPhase dropped some of the IfNode. Could be verified using the following code: protected ComplexMatchResult emitCompareBranchMemory(IfNode ifNode, CompareNode compare, ValueNode value, Access access) { Condition cond = compare.condition(); Kind kind = getMemoryKind(access); if (kind != Kind.Long) { notInlinedMethodPlaceHolder(kind); } After tail duplication at some merge node, the IfNode disappeared.. - Yudi From gilwooden at gmail.com Thu May 15 06:28:54 2014 From: gilwooden at gmail.com (Gilles Duboscq) Date: Thu, 15 May 2014 08:28:54 +0200 Subject: VirtualObjects at deoptimization points. In-Reply-To: References: Message-ID: I pushed something which passed the existing tests as well as your new test: http://hg.openjdk.java.net/graal/graal/rev/2208a130d636 -Gilles Ok, thanks, I will use that. -Gilles On Wed, May 14, 2014 at 1:11 AM, Tom Deneau wrote: > Gilles -- > > You can try applying the attached patch to create a new test uses virtual > objects and does force a deopt. > When I tried this test with your patch, I did not get the correct results > but I didn't try to trace down whether it was due to anything with > virtual objects or not. > > -- Tom > >> -----Original Message----- >> From: Deneau, Tom >> Sent: Tuesday, May 13, 2014 5:59 PM >> To: Deneau, Tom; Gilles Duboscq >> Cc: graal-dev at openjdk.java.net >> Subject: RE: VirtualObjects at deoptimization points. >> >> Gilles -- >> >> I noticed you had a link to a patch, I applied your patch and the one >> test mentioned below did not get an error at prepareHostGraph time as it >> usually did. >> >> I should add that while this test failed in prepareHostGraph, trying to >> handle a Virtual Object, this test doesn't actually deopt so it doesn't >> really test whether the virtual object can be handled correctly in the >> face of deopt. >> >> I can try to modify it so that it does deopt. >> >> -- Tom >> >> >> > -----Original Message----- >> > From: Deneau, Tom >> > Sent: Tuesday, May 13, 2014 5:53 PM >> > To: 'Gilles Duboscq' >> > Cc: graal-dev at openjdk.java.net >> > Subject: RE: VirtualObjects at deoptimization points. >> > >> > Gilles -- >> > >> > Sorry for the delay in responding... >> > There is one test checked in trunk that currently fails because of >> > lack of VirtualObjectsInDeopt support. >> > >> > The test is >> > com.oracle.graal.compiler.hsail.test.lambda.VecmathNBodyTest >> > It is currently disabled from running by the following >> > (canHandleDeoptVirtualObjects() returns false) but you can comment >> > that out to make it run. >> > >> > @Override >> > protected boolean supportsRequiredCapabilities() { >> > return (canHandleDeoptVirtualObjects()); >> > } >> > >> > I was going to say it should pass if -XX:-UseHSAILDeoptimization is >> > on the command line but I see there is a bug in that it still tries to >> > create the host graph even if UseHSAILDeoptimization is false. This >> > logic can be fixed in HSAILHotSpotBackend.java by this little patch. >> > >> > --- >> > >> a/graal/com.oracle.graal.hotspot.hsail/src/com/oracle/graal/hotspot/hsai >> > l/HSAILHotSpotBackend.java Tue May 13 15:38:56 2014 -0500 >> > +++ >> > >> b/graal/com.oracle.graal.hotspot.hsail/src/com/oracle/graal/hotspot/hsai >> > l/HSAILHotSpotBackend.java Tue May 13 17:49:29 2014 -0500 >> > @@ -924,7 +924,9 @@ >> > >> > ExternalCompilationResult compilationResult = >> > (ExternalCompilationResult) crb.compilationResult; >> > HSAILHotSpotLIRGenerationResult lirGenRes = >> > ((HSAILCompilationResultBuilder) crb).lirGenRes; >> > - compilationResult.setHostGraph(prepareHostGraph(method, >> > lirGenRes.getDeopts(), getProviders(), config, numSRegs, numDRegs)); >> > + if (useHSAILDeoptimization) { >> > + compilationResult.setHostGraph(prepareHostGraph(method, >> > lirGenRes.getDeopts(), getProviders(), config, numSRegs, numDRegs)); >> > + } >> > } >> > >> > -- Tom >> > >> > >> > > -----Original Message----- >> > > From: gilwooden at gmail.com [mailto:gilwooden at gmail.com] On Behalf Of >> > > Gilles Duboscq >> > > Sent: Sunday, May 04, 2014 12:17 PM >> > > To: Deneau, Tom >> > > Cc: graal-dev at openjdk.java.net >> > > Subject: Re: VirtualObjects at deoptimization points. >> > > >> > > Hello, >> > > >> > > I currently have a prototype [1] that i would like to test. Before >> > > creating my own tests, i was wondering if you already have tests for >> > > this or if you know of tests that have escaping objects? >> > > >> > > -Gilles >> > > >> > > [1] http://cr.openjdk.java.net/~gdub/HSAILVirtualObjectDeopt.patch >> > > >> > > On Fri, May 2, 2014 at 7:21 PM, Tom Deneau >> wrote: >> > > > Hi Gilles -- >> > > > >> > > > Could I get an update on the support for VirtualObjects in the >> > > > host >> > > deopt trampoline code? >> > > > >> > > > -- Tom D. >> > > > >> > > >> -----Original Message----- >> > > >> From: gilwooden at gmail.com [mailto:gilwooden at gmail.com] On Behalf >> > > >> Of Gilles Duboscq >> > > >> Sent: Thursday, April 03, 2014 5:04 AM >> > > >> To: Deneau, Tom >> > > >> Cc: graal-dev at openjdk.java.net >> > > >> Subject: Re: VirtualObjects at deoptimization points. >> > > >> >> > > >> Hello Tom, >> > > >> >> > > >> The reason I delayed the implementation of VirtualObjects is that >> > we >> > > >> have to reverse the process that transforms VirtualObjectNodes >> > > >> into VirtualObjects (that's in >> > > >> com.oracle.graal.compiler.gen.DebugInfoBuilder.build(FrameState, >> > > >> LabelRef)). >> > > >> It shouldn't be so complicated to add this support. I'll give it >> > > >> a >> > > try. >> > > >> >> > > >> -Gilles >> > > >> >> > > >> On Tue, Apr 1, 2014 at 1:07 AM, Tom Deneau >> > > wrote: >> > > >> > Gilles -- >> > > >> > >> > > >> > >> > > >> > >> > > >> > I noticed in one of our java8 lambda tests (not yet pushed to >> > > >> > trunk) we had some object allocation that was eliminated by >> > escape >> > > analysis. >> > > >> > But when we try to run this with the trunk now, we get >> > > >> > >> > > >> > >> > > >> > >> > > >> > com.oracle.graal.graph.GraalInternalError: unimplemented >> > > >> > >> > > >> > at >> > > >> > >> > com.oracle.graal.graph.GraalInternalError.unimplemented(GraalIntern >> > > >> > alE >> > > >> > rror.java:38) >> > > >> > >> > > >> > at >> > > >> > >> > com.oracle.graal.hotspot.hsail.HSAILHotSpotLIRGenerator.getNodeForV >> > > >> > alu >> > > >> > eFromFrame(HSAILHotSpotLIRGenerator.java:182) >> > > >> > >> > > >> > at >> > > >> > >> > com.oracle.graal.hotspot.hsail.HSAILHotSpotLIRGenerator.createFrame >> > > >> > Sta >> > > >> > te(HSAILHotSpotLIRGenerator.java:149) >> > > >> > >> > > >> > at >> > > >> > >> > com.oracle.graal.hotspot.hsail.HSAILHotSpotLIRGenerator.createHostD >> > > >> > eop >> > > >> > tBranch(HSAILHotSpotLIRGenerator.java:140) >> > > >> > >> > > >> > >> > > >> > >> > > >> > where the line 182 in getNodeForValueFromFrame has >> > > >> > >> > > >> > >> > > >> > >> > > >> > >> > > >> > >> > > >> > } else if (localValue instanceof VirtualObject) { >> > > >> > >> > > >> > throw GraalInternalError.unimplemented(); >> > > >> > >> > > >> > } >> > > >> > >> > > >> > >> > > >> > >> > > >> > >> > > >> > >> > > >> > What would we need to do to support VirtualObjects at our >> > > >> > deoptimization infopoints? >> > > >> > >> > > >> > >> > > >> > >> > > >> > >> > > >> > >> > > >> > (We also don't support stack slots yet, but I think I >> > > >> > understand what is needed to support those). >> > > >> > >> > > >> > >> > > >> > >> > > >> > -- Tom >> > > >> > >> > > >> > >> > > > From lukas.stadler at oracle.com Thu May 15 14:15:39 2014 From: lukas.stadler at oracle.com (Lukas Stadler) Date: Thu, 15 May 2014 16:15:39 +0200 Subject: buggy behavior in AMD64NodeLIRBuilder.emitCompareBranchMemory In-Reply-To: <6601CE83-C5E2-4A3F-8D64-7FDAF9978720@usi.ch> References: <0617F35B-7FED-43C4-999B-945E2A279E01@oracle.com> <1A858417-AF09-4CF3-BABD-7328223AF5DD@oracle.com> <6601CE83-C5E2-4A3F-8D64-7FDAF9978720@usi.ch> Message-ID: Hi guys, thanks so much for the detailed bug report, and for narrowing it down further. It was a bug that happened when inferring stamps within the canonicalizer (which is run after tail duplication). In rare cases, meeting multiple ObjectStamps to determine the stamp of a phi, with one of the phi inputs being illegal, led to an illegal stamp on the phi. The correct behavior is to just ignore the illegal type, since this corresponds to an unreachable path. Comparing something with an illegal stamp to anything led to ?false?, since there?s no value that can fulfill ?illegal?. This subsequently removed the isInt check. I just pushed a fix, should be through later today (look for "(f6264f499455) correctly handle illegal stamps in ObjectStamp.meet?). - Lukas On 15 May 2014, at 8:11, Yudi Zheng wrote: > The simplified test case I sent yesterday is the following: > > public class TailDuplicationTest { > > interface I { > } > > enum P implements I { > A, B > } > > final static I CONST_I = new I() { > }; > > public static I foo(int i) { > if (i < 32) { > return P.A; > } else if (i < 64) { > return P.B; > } else { > return CONST_I; > } > } > > public int bar(int i) { > P instance = (P) foo(i); > > if (instance != P.B) { > return 0; > } > > return 1; > } > > public static void main(String[] args) { > TailDuplicationTest t = new TailDuplicationTest(); > > for (int i = 0; i < 100000; i++) { > foo(i % 128); > t.bar(i % 64); > } > } > > } > > Look at the graph of TailDuplicationTest.bar, the "return 1" branch is dropped between LoopFullUnroll and TailDuplication. > It is caused by a stamp evaluation which compares an illegal "a!# -" with "a!# LTailDuplicationTest$P;" > The illegal "a!# -" is generated by ValuePhiNode.inferPhiStamp? > > I inserted graph dumping at TailDuplicationPhase#328 and ObjectEqualsNode#64. Please have a look at the stamp changes > on "48 ValuePhi()" (hopefully the same ID), > > diff -r 55977f9fa56f graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/calc/ObjectEqualsNode.java > --- a/graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/calc/ObjectEqualsNode.java Sun May 11 22:00:06 2014 +0200 > +++ b/graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/calc/ObjectEqualsNode.java Thu May 15 08:07:39 2014 +0200 > @@ -25,6 +25,7 @@ > import com.oracle.graal.api.meta.*; > import com.oracle.graal.api.meta.ProfilingInfo.*; > import com.oracle.graal.compiler.common.calc.*; > +import com.oracle.graal.debug.*; > import com.oracle.graal.graph.*; > import com.oracle.graal.graph.spi.*; > import com.oracle.graal.nodes.*; > @@ -62,6 +63,10 @@ > if (GraphUtil.unproxify(forX) == GraphUtil.unproxify(forY)) { > return TriState.TRUE; > } else if (forX.stamp().alwaysDistinct(forY.stamp())) { > + if ("bar".equals(graph().method().getName())) { > + Debug.dump(graph(), "During canonicalizer phase in tail duplication, ObjectEqualsNode#64"); > + } > + > return TriState.FALSE; > } else { > return super.evaluate(constantReflection, forX, forY); > @@ -119,7 +124,7 @@ > /* > * One of the two objects has identity, the other doesn't. In code, this looks like > * "Integer.valueOf(a) == new Integer(b)", which is always false. > - * > + * > * In other words: an object created via valueOf can never be equal to one created > * by new in the same compilation unit. > */ > diff -r 55977f9fa56f graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/TailDuplicationPhase.java > --- a/graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/TailDuplicationPhase.java Sun May 11 22:00:06 2014 +0200 > +++ b/graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/TailDuplicationPhase.java Thu May 15 08:07:39 2014 +0200 > @@ -326,6 +326,9 @@ > phi.setMerge(mergeAfter); > } > } > + if ("bar".equals(graph.method().getName())) { > + Debug.dump(graph, "Before canonicalizer phase in tail duplication, TailDuplicationPhase#328"); > + } > canonicalizer.applyIncremental(graph, phaseContext, startMark); > Debug.dump(graph, "After tail duplication at %s", merge); > } > > > - Yudi > > On 15 May 2014, at 06:12, Tom Rodriguez > wrote: > > I think this is actually a bug in tail duplication. I?ve been chasing my tail a bit on this because the code that reports the error is only compiled when exercising the matching code, so I assumed they were causally connected. I just added logic that allows the matching logic to run but never installs the match result, so the code is exercised but doesn?t actually change code generation and it still shows up. Looking at the graph I can see if the isInt guard disappear during tail duplication which causes the problem I?m seeing. https://lafo.ssw.uni-linz.ac.at/jira/browse/GRAAL-791 has a patch that makes it easy to reproduce. Hopefully Lukas can get to the bottom of it. > > tom > > On May 14, 2014, at 11:01 AM, Tom Rodriguez > wrote: > > Thanks for the test case. I?ve been narrowing it down in between a few other things but I was seeing an issue with a mirrored unsigned compare. It generates bad code in the compiler itself and then fails much later. It?s possible there are multiple things going on. Anyway, I hope to have it resolved today. > > tom > > On May 14, 2014, at 10:56 AM, Yudi Zheng > wrote: > > In case you might need it, please find attached the simplified test case. > During the TailDuplicationPhase when compiling TailDuplicatoinTest.bar, > some ObjectEqualsNode is evaluated to false.. > (com.oracle.graal.nodes.calc.ObjectEqualsNode.java#64) > > - Yudi > > > On 13 May 2014, at 00:40, Tom Rodriguez > wrote: > > Thanks for the report. I?m looking into it. > > tom > > On May 12, 2014, at 1:10 PM, Yudi Zheng > wrote: > > Hi, > > 1. A minor problem is that the default TypeProfileWidth is 2, resulting in lots of megamorphic-inlining with a probability of 60~70% in many cases, > instead of polymorphic-inlining. > > 2. When running with -XX:TypeProfileWidth=8, I observed buggy behavior: > > mx vm -XX:+BootstrapGraal -XX:TypeProfileWidth=8 -version > Bootstrapping Graal.......................com.oracle.graal.compiler.common.GraalInternalError: should not reach here > at lir instruction: B192 at 1350 LCMP (address: [rax|j + 24], y: long[33286881400|0x7c00d8078]{HotSpotType}) kind: long > [B0, B2, B3, B5, B6, B8, B416, B419, B9, B11, B12, B14, B16, B17, B19, B21, B413, B23, B25, B26, B28, B29, B31, B409, B412, B32, B33, B35, B36, B38, B39, B41, B42, B44, B45, B47, B49, B50, B52, B54, B53, B55, B56, B57, B59, B61, B63, B65, B66, B67, B69, B70, B72, B74, B77, B79, B80, B94, B96, B98, B99, B101, B102, B103, B104, B107, B108, B109, B110, B113, B114, B115, B117, B118, B120, B122, B125, B127, B128, B129, B143, B145, B147, B148, B160, B126, B119, B149, B116, B130, B132, B153, B133, B136, B138, B139, B141, B142, B137, B140, B150, B134, B168, B105, B166, B171, B180, B181, B183, B186, B188, B190, B192, B194, B196, B198, B200, B197, B161, B170, B179, B177, B178, B184, B403, B78, B193, B202, B203, B204, B209, B211, B212, B214, B399, B401, B215, B216, B218, B220, B222, B397, B71, B208, B205, B206, B100, B195, B201, B187, B189, B68, B191, B199, B219, B224, B226, B228, B229, B231, B233, B394, B395, B221, B223, B82, B84, B173, B174, B154, B155, B51, B48, B232, B235, B239, B393, B236, B238, B234, B85, B87, B89, B90, B92, B93, B88, B240, B242, B284, B286, B288, B289, B291, B294, B296, B297, B299, B300, B302, B304, B307, B308, B310, B311, B313, B315, B317, B318, B320, B322, B323, B325, B326, B327, B343, B345, B346, B348, B349, B351, B354, B356, B357, B358, B360, B362, B364, B365, B367, B369, B372, B368, B373, B83, B371, B46, B352, B237, B287, B316, B330, B332, B333, B335, B336, B337, B244, B246, B247, B249, B250, B252, B254, B257, B258, B260, B261, B263, B265, B267, B268, B270, B273, B275, B276, B370, B266, B207, B285, B314, B264, B91, B355, B295, B245, B339, B384, B301, B306, B251, B256, B390, B391, B281, B283, B167, B282, B347, B382, B344, B30, B27, B378, B379, B175, B385, B388, B324, B386, B34, B407, B259, B280, B402, B312, B387, B309, B62, B389, B24, B410, B210, B392, B165, B230, B278, B159, B415, B396, B135, B404, B262, B169, B157, B10, B381, B15, B331, B376, B277, B405, B414, B37, B1, B213, B398, B417, B279, B418, B408, B400, B176, B338, B58, B40, B151, B274, B411, B380, B375, B334, B7, B340, B64, B4, B377, B406, B60, B13, B172, B163, B106, B86, B217, B18, B112, B383] > at com.oracle.graal.compiler.common.GraalInternalError.shouldNotReachHere(GraalInternalError.java:44) > at com.oracle.graal.lir.amd64.AMD64Compare$CompareMemoryOp.emitMemAccess(AMD64Compare.java:129) > at com.oracle.graal.lir.amd64.AMD64Move$MemOp.emitCode(AMD64Move.java:129) > at com.oracle.graal.lir.amd64.AMD64LIRInstruction.emitCode(AMD64LIRInstruction.java:36) > at com.oracle.graal.lir.asm.CompilationResultBuilder.emitOp(CompilationResultBuilder.java:350) > at com.oracle.graal.lir.asm.CompilationResultBuilder.emitBlock(CompilationResultBuilder.java:341) > at com.oracle.graal.lir.asm.CompilationResultBuilder.emit(CompilationResultBuilder.java:323) > at com.oracle.graal.hotspot.amd64.AMD64HotSpotBackend.emitCodeBody(AMD64HotSpotBackend.java:301) > at com.oracle.graal.hotspot.amd64.AMD64HotSpotBackend.emitCode(AMD64HotSpotBackend.java:254) > at com.oracle.graal.compiler.GraalCompiler.emitCode(GraalCompiler.java:288) > at com.oracle.graal.compiler.GraalCompiler.emitBackEnd(GraalCompiler.java:200) > at com.oracle.graal.compiler.GraalCompiler.compileGraph(GraalCompiler.java:141) > at com.oracle.graal.hotspot.CompilationTask.runCompilation(CompilationTask.java:302) > at com.oracle.graal.hotspot.CompilationTask.run(CompilationTask.java:159) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) > at java.lang.Thread.run(Thread.java:745) > at com.oracle.graal.compiler.CompilerThread.run(CompilerThread.java:48) > > > The potential bug can be tracked in com.oracle.graal.compiler.amd64.AMD64NodeLIRBuilder.emitCompareBranchMemory > (-G:Dump= -G:MethodFilter=com.oracle.graal.compiler.amd64.AMD64NodeLIRBuilder.emitCompareBranchMemory), > and can be bypassed either by not inlining com.oracle.graal.compiler.amd64.AMD64NodeLIRBuilder.getMemoryKind, > or by skipping the TailDuplicationPhase. > > I guess that the TailDuplicationPhase dropped some of the IfNode. Could be verified using the following code: > > protected ComplexMatchResult emitCompareBranchMemory(IfNode ifNode, CompareNode compare, ValueNode value, Access access) { > Condition cond = compare.condition(); > Kind kind = getMemoryKind(access); > > if (kind != Kind.Long) { > notInlinedMethodPlaceHolder(kind); > } > > After tail duplication at some merge node, the IfNode disappeared.. > > - Yudi > > > > > > > > From tom.deneau at amd.com Thu May 15 14:22:56 2014 From: tom.deneau at amd.com (Deneau, Tom) Date: Thu, 15 May 2014 14:22:56 +0000 Subject: VirtualObjects at deoptimization points. In-Reply-To: References: Message-ID: Great, I will give it a try today From: Gilles Duboscq [mailto:gilwooden at gmail.com] Sent: Thursday, May 15, 2014 1:29 AM To: Deneau, Tom Cc: graal-dev at openjdk.java.net Subject: Re: VirtualObjects at deoptimization points. I pushed something which passed the existing tests as well as your new test: http://hg.openjdk.java.net/graal/graal/rev/2208a130d636 -Gilles Ok, thanks, I will use that. -Gilles On Wed, May 14, 2014 at 1:11 AM, Tom Deneau > wrote: > Gilles -- > > You can try applying the attached patch to create a new test uses virtual > objects and does force a deopt. > When I tried this test with your patch, I did not get the correct results > but I didn't try to trace down whether it was due to anything with > virtual objects or not. > > -- Tom > >> -----Original Message----- >> From: Deneau, Tom >> Sent: Tuesday, May 13, 2014 5:59 PM >> To: Deneau, Tom; Gilles Duboscq >> Cc: graal-dev at openjdk.java.net >> Subject: RE: VirtualObjects at deoptimization points. >> >> Gilles -- >> >> I noticed you had a link to a patch, I applied your patch and the one >> test mentioned below did not get an error at prepareHostGraph time as it >> usually did. >> >> I should add that while this test failed in prepareHostGraph, trying to >> handle a Virtual Object, this test doesn't actually deopt so it doesn't >> really test whether the virtual object can be handled correctly in the >> face of deopt. >> >> I can try to modify it so that it does deopt. >> >> -- Tom >> >> >> > -----Original Message----- >> > From: Deneau, Tom >> > Sent: Tuesday, May 13, 2014 5:53 PM >> > To: 'Gilles Duboscq' >> > Cc: graal-dev at openjdk.java.net >> > Subject: RE: VirtualObjects at deoptimization points. >> > >> > Gilles -- >> > >> > Sorry for the delay in responding... >> > There is one test checked in trunk that currently fails because of >> > lack of VirtualObjectsInDeopt support. >> > >> > The test is >> > com.oracle.graal.compiler.hsail.test.lambda.VecmathNBodyTest >> > It is currently disabled from running by the following >> > (canHandleDeoptVirtualObjects() returns false) but you can comment >> > that out to make it run. >> > >> > @Override >> > protected boolean supportsRequiredCapabilities() { >> > return (canHandleDeoptVirtualObjects()); >> > } >> > >> > I was going to say it should pass if -XX:-UseHSAILDeoptimization is >> > on the command line but I see there is a bug in that it still tries to >> > create the host graph even if UseHSAILDeoptimization is false. This >> > logic can be fixed in HSAILHotSpotBackend.java by this little patch. >> > >> > --- >> > >> a/graal/com.oracle.graal.hotspot.hsail/src/com/oracle/graal/hotspot/hsai >> > l/HSAILHotSpotBackend.java Tue May 13 15:38:56 2014 -0500 >> > +++ >> > >> b/graal/com.oracle.graal.hotspot.hsail/src/com/oracle/graal/hotspot/hsai >> > l/HSAILHotSpotBackend.java Tue May 13 17:49:29 2014 -0500 >> > @@ -924,7 +924,9 @@ >> > >> > ExternalCompilationResult compilationResult = >> > (ExternalCompilationResult) crb.compilationResult; >> > HSAILHotSpotLIRGenerationResult lirGenRes = >> > ((HSAILCompilationResultBuilder) crb).lirGenRes; >> > - compilationResult.setHostGraph(prepareHostGraph(method, >> > lirGenRes.getDeopts(), getProviders(), config, numSRegs, numDRegs)); >> > + if (useHSAILDeoptimization) { >> > + compilationResult.setHostGraph(prepareHostGraph(method, >> > lirGenRes.getDeopts(), getProviders(), config, numSRegs, numDRegs)); >> > + } >> > } >> > >> > -- Tom >> > >> > >> > > -----Original Message----- >> > > From: gilwooden at gmail.com [mailto:gilwooden at gmail.com] On Behalf Of >> > > Gilles Duboscq >> > > Sent: Sunday, May 04, 2014 12:17 PM >> > > To: Deneau, Tom >> > > Cc: graal-dev at openjdk.java.net >> > > Subject: Re: VirtualObjects at deoptimization points. >> > > >> > > Hello, >> > > >> > > I currently have a prototype [1] that i would like to test. Before >> > > creating my own tests, i was wondering if you already have tests for >> > > this or if you know of tests that have escaping objects? >> > > >> > > -Gilles >> > > >> > > [1] http://cr.openjdk.java.net/~gdub/HSAILVirtualObjectDeopt.patch >> > > >> > > On Fri, May 2, 2014 at 7:21 PM, Tom Deneau > >> wrote: >> > > > Hi Gilles -- >> > > > >> > > > Could I get an update on the support for VirtualObjects in the >> > > > host >> > > deopt trampoline code? >> > > > >> > > > -- Tom D. >> > > > >> > > >> -----Original Message----- >> > > >> From: gilwooden at gmail.com [mailto:gilwooden at gmail.com] On Behalf >> > > >> Of Gilles Duboscq >> > > >> Sent: Thursday, April 03, 2014 5:04 AM >> > > >> To: Deneau, Tom >> > > >> Cc: graal-dev at openjdk.java.net >> > > >> Subject: Re: VirtualObjects at deoptimization points. >> > > >> >> > > >> Hello Tom, >> > > >> >> > > >> The reason I delayed the implementation of VirtualObjects is that >> > we >> > > >> have to reverse the process that transforms VirtualObjectNodes >> > > >> into VirtualObjects (that's in >> > > >> com.oracle.graal.compiler.gen.DebugInfoBuilder.build(FrameState, >> > > >> LabelRef)). >> > > >> It shouldn't be so complicated to add this support. I'll give it >> > > >> a >> > > try. >> > > >> >> > > >> -Gilles >> > > >> >> > > >> On Tue, Apr 1, 2014 at 1:07 AM, Tom Deneau > >> > > wrote: >> > > >> > Gilles -- >> > > >> > >> > > >> > >> > > >> > >> > > >> > I noticed in one of our java8 lambda tests (not yet pushed to >> > > >> > trunk) we had some object allocation that was eliminated by >> > escape >> > > analysis. >> > > >> > But when we try to run this with the trunk now, we get >> > > >> > >> > > >> > >> > > >> > >> > > >> > com.oracle.graal.graph.GraalInternalError: unimplemented >> > > >> > >> > > >> > at >> > > >> > >> > com.oracle.graal.graph.GraalInternalError.unimplemented(GraalIntern >> > > >> > alE >> > > >> > rror.java:38) >> > > >> > >> > > >> > at >> > > >> > >> > com.oracle.graal.hotspot.hsail.HSAILHotSpotLIRGenerator.getNodeForV >> > > >> > alu >> > > >> > eFromFrame(HSAILHotSpotLIRGenerator.java:182) >> > > >> > >> > > >> > at >> > > >> > >> > com.oracle.graal.hotspot.hsail.HSAILHotSpotLIRGenerator.createFrame >> > > >> > Sta >> > > >> > te(HSAILHotSpotLIRGenerator.java:149) >> > > >> > >> > > >> > at >> > > >> > >> > com.oracle.graal.hotspot.hsail.HSAILHotSpotLIRGenerator.createHostD >> > > >> > eop >> > > >> > tBranch(HSAILHotSpotLIRGenerator.java:140) >> > > >> > >> > > >> > >> > > >> > >> > > >> > where the line 182 in getNodeForValueFromFrame has >> > > >> > >> > > >> > >> > > >> > >> > > >> > >> > > >> > >> > > >> > } else if (localValue instanceof VirtualObject) { >> > > >> > >> > > >> > throw GraalInternalError.unimplemented(); >> > > >> > >> > > >> > } >> > > >> > >> > > >> > >> > > >> > >> > > >> > >> > > >> > >> > > >> > What would we need to do to support VirtualObjects at our >> > > >> > deoptimization infopoints? >> > > >> > >> > > >> > >> > > >> > >> > > >> > >> > > >> > >> > > >> > (We also don't support stack slots yet, but I think I >> > > >> > understand what is needed to support those). >> > > >> > >> > > >> > >> > > >> > >> > > >> > -- Tom >> > > >> > >> > > >> > >> > > > From doug.simon at oracle.com Thu May 15 14:32:27 2014 From: doug.simon at oracle.com (doug.simon at oracle.com) Date: Thu, 15 May 2014 14:32:27 +0000 Subject: hg: graal/graal: 14 new changesets Message-ID: <201405151432.s4FEWldY011494@aojmv0008> Changeset: ca2a8fe16037 Author: Tom Rodriguez Date: 2014-05-14 21:14 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/ca2a8fe16037 fix action comparison when comparing DeoptimizeNodes ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/IfNode.java Changeset: 3397e82e2f35 Author: Tom Rodriguez Date: 2014-05-14 21:24 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/3397e82e2f35 fix printing of pc in deopt message ! src/share/vm/runtime/deoptimization.cpp Changeset: 74d3a86cbac8 Author: Tom Rodriguez Date: 2014-05-14 21:24 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/74d3a86cbac8 slighty stronger assert in verify ! graal/com.oracle.graal.lir.amd64/src/com/oracle/graal/lir/amd64/AMD64Compare.java Changeset: 4735aabe8444 Author: Josef Eisl Date: 2014-05-14 20:15 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/4735aabe8444 Add AnsiColor. + graal/com.oracle.graal.debug/src/com/oracle/graal/debug/AnsiColor.java Changeset: ec29b2d3bdb4 Author: Josef Eisl Date: 2014-05-14 20:58 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/ec29b2d3bdb4 mx unittest: add color support. + graal/com.oracle.graal.test/src/com/oracle/graal/test/AnsiTerminalDecorator.java ! graal/com.oracle.graal.test/src/com/oracle/graal/test/GraalJUnitCore.java ! mx/mx_graal.py ! mx/projects Changeset: fcf6e5683082 Author: Josef Eisl Date: 2014-05-14 20:59 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/fcf6e5683082 mx unittest: add --eager-stacktrace. + graal/com.oracle.graal.test/src/com/oracle/graal/test/EagerStackTraceDecorator.java ! graal/com.oracle.graal.test/src/com/oracle/graal/test/GraalJUnitCore.java ! graal/com.oracle.graal.test/src/com/oracle/graal/test/GraalVerboseTextListener.java ! mx/mx_graal.py Changeset: 50740bac9679 Author: Josef Eisl Date: 2014-05-14 20:43 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/50740bac9679 mx unittest: simplify argument passing. ! mx/mx_graal.py Changeset: 304e1c30adaf Author: Josef Eisl Date: 2014-05-15 11:13 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/304e1c30adaf GraalVerboseTextListener: fix testFailed printing. ! graal/com.oracle.graal.test/src/com/oracle/graal/test/GraalVerboseTextListener.java Changeset: e19950ee2ec4 Author: Lukas Stadler Date: 2014-05-15 14:12 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/e19950ee2ec4 implement NodeBitMap.toString ! graal/com.oracle.graal.graph/src/com/oracle/graal/graph/NodeBitMap.java Changeset: 9c75a5e29052 Author: Lukas Stadler Date: 2014-05-15 14:13 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/9c75a5e29052 tests for ObjectStamp.meet ! graal/com.oracle.graal.nodes.test/src/com/oracle/graal/nodes/test/ObjectStampJoinTest.java + graal/com.oracle.graal.nodes.test/src/com/oracle/graal/nodes/test/ObjectStampMeetTest.java + graal/com.oracle.graal.nodes.test/src/com/oracle/graal/nodes/test/ObjectStampTest.java Changeset: f6264f499455 Author: Lukas Stadler Date: 2014-05-15 14:13 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/f6264f499455 correctly handle illegal stamps in ObjectStamp.meet ! graal/com.oracle.graal.compiler.common/src/com/oracle/graal/compiler/common/type/ObjectStamp.java Changeset: 50fbda571d99 Author: Doug Simon Date: 2014-05-15 15:31 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/50fbda571d99 mx: added jrelibrary dependency type mx: once mx/projects is loaded, projects and libraries that depend on non-existent JRE library or have a javaCompliance higher than any available JDK are ignored ! CHANGELOG.md ! mxtool/mx.py Changeset: 7340fe377764 Author: twisti Date: 2014-05-15 15:32 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/7340fe377764 added Java Flight Recorder (JFR) event support + graal/com.oracle.graal.hotspot.jfr/src/com/oracle/graal/hotspot/jfr/events/JFREventProvider.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/CompilationTask.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/HotSpotGraalRuntime.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/HotSpotVMConfig.java + graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/events/EmptyEventProvider.java + graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/events/EventProvider.java ! mx/projects Changeset: 8d0242a07f7e Author: Doug Simon Date: 2014-05-15 15:35 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/8d0242a07f7e Merge. From tom.deneau at amd.com Thu May 15 16:04:55 2014 From: tom.deneau at amd.com (Deneau, Tom) Date: Thu, 15 May 2014 16:04:55 +0000 Subject: exception from javaCall but no StackTraceElements In-Reply-To: References: Message-ID: Christian -- Yes, you were correct. I turned off OmitStackTraceInFastThrow and I don't see this issue occurring anymore. I assume from looking at the hotspot code that this optimization kicks in during C2 compilation so the reason we weren't seeing it all the time is that it depended on the hotness of the method being called thru javaCall. Now asking for some advice--- In those of our junit tests that we expect to throw a single exception, we had it set up to catch exceptions in the framework outside the kernel, and then capture the exception class and the first stack trace element expecting them to be the same between the pure java run and the hsail kernel run. But it sounds like we can't count on the stack trace being recorded. And my understanding is we can't turn off Hotspot options from the junit framework. Is there any good way to test that not just the exception class matched but also the point at which the exception occurred? -- Tom > -----Original Message----- > From: Christian Thalinger [mailto:christian.thalinger at oracle.com] > Sent: Wednesday, May 14, 2014 6:32 PM > To: Deneau, Tom > Cc: graal-dev at openjdk.java.net > Subject: Re: exception from javaCall but no StackTraceElements > > > On May 14, 2014, at 3:57 PM, Deneau, Tom wrote: > > > We are seeing an occasional failure on one of our hsail junit tests, I > will describe here... > > > > There is a flag, UseHSAILSafepoints and one effect of that is that if > a kernel is executing and sees that the VM is desiring a safepoint, then > new workitems will not get started. This occurs even if the hsail code > in the kernel itself has no "compiler safepoints". > > > > The workitems that do not start as mentioned above are marked as > never-rans and are then after all the workitems finish each never-ran is > run as a javaCall to the underlying java method. All of this is done in > "thread-in-VM" mode. > > > > This particular test is set up to have 589824 workitems and the very > last workitem is designed to cause an ArrayOutOfBoundsException. A try > block surrounding the kernel call and we catch any exceptions and > compare the first frame of the stack trace of the exception with the > first frame that occurred when the kernel was run in pure java mode. > > > > We always get an exception thrown from the last javaCall but > occasionally the exception has no stackTraceElements so our comparison > fails in that case. > > > > I assume an exception in a javaCall is recorded in the thread and then > when the thread returns from VM mode to Java mode. > > > > Does anyone know why the exception would sometimes have no > stackTraceElements? > > Not sure if I'm following correctly but the "empty" exception is coming > from running Java code on the CPU, correct? It might be related to > OmitStackTraceInFastThrow. Try to turn it off. > > > > > -- Tom > > > > From tom.deneau at amd.com Thu May 15 17:04:02 2014 From: tom.deneau at amd.com (Deneau, Tom) Date: Thu, 15 May 2014 17:04:02 +0000 Subject: VirtualObjects at deoptimization points. In-Reply-To: References: Message-ID: Gilles -- Yes this looks good. One question: I noticed the infopoint where we are deopting in the new test does indeed use a virtual object and I see that the fields of the vobject are mapped to registers. But what is the purpose of those float constants being in the frame. I see they are marked in graal as PrimitiveConstants but why would constants even need to be stored in the locals in the ByteCodeFrame? -- Tom 4386[] registerMap[ r40 r42 r43] com.oracle.graal.compiler.hsail.test.lambda.VecmathNBodyDeoptTest$Body.computeAcc(VecmathNBodyDeoptTest.java:65) [bci: 20] #locals=12 #expr=0 at com.oracle.graal.compiler.hsail.test.lambda.VecmathNBodyDeoptTest$Body.computeAcc(VecmathNBodyDeoptTest.java:65) [bci: 20] |0 |1 |2 |3 |4 |5 |6 |7 |8 |9 |10 |11 locals: |d3|a |- |float[1.0|0x3f800000] |float[0.005|0x3ba3d70a] |vobject:Vector3f:0{x=s7|f,y=s6|f,z=s5|f} |d2|a |s1|i |s8|i |- |- |- |- at com.oracle.graal.compiler.hsail.test.lambda.VecmathNBodyDeoptTest.lambda$runTest$37(VecmathNBodyDeoptTest.java:109) [bci: 22] |0 |1 |2 |3 |4 |5 locals: |- |s0|i |d3|a |d0|a |- |- From: Gilles Duboscq [mailto:gilwooden at gmail.com] Sent: Thursday, May 15, 2014 1:29 AM To: Deneau, Tom Cc: graal-dev at openjdk.java.net Subject: Re: VirtualObjects at deoptimization points. I pushed something which passed the existing tests as well as your new test: http://hg.openjdk.java.net/graal/graal/rev/2208a130d636 -Gilles Ok, thanks, I will use that. -Gilles On Wed, May 14, 2014 at 1:11 AM, Tom Deneau > wrote: > Gilles -- > > You can try applying the attached patch to create a new test uses virtual > objects and does force a deopt. > When I tried this test with your patch, I did not get the correct results > but I didn't try to trace down whether it was due to anything with > virtual objects or not. > > -- Tom > >> -----Original Message----- >> From: Deneau, Tom >> Sent: Tuesday, May 13, 2014 5:59 PM >> To: Deneau, Tom; Gilles Duboscq >> Cc: graal-dev at openjdk.java.net >> Subject: RE: VirtualObjects at deoptimization points. >> >> Gilles -- >> >> I noticed you had a link to a patch, I applied your patch and the one >> test mentioned below did not get an error at prepareHostGraph time as it >> usually did. >> >> I should add that while this test failed in prepareHostGraph, trying to >> handle a Virtual Object, this test doesn't actually deopt so it doesn't >> really test whether the virtual object can be handled correctly in the >> face of deopt. >> >> I can try to modify it so that it does deopt. >> >> -- Tom >> >> >> > -----Original Message----- >> > From: Deneau, Tom >> > Sent: Tuesday, May 13, 2014 5:53 PM >> > To: 'Gilles Duboscq' >> > Cc: graal-dev at openjdk.java.net >> > Subject: RE: VirtualObjects at deoptimization points. >> > >> > Gilles -- >> > >> > Sorry for the delay in responding... >> > There is one test checked in trunk that currently fails because of >> > lack of VirtualObjectsInDeopt support. >> > >> > The test is >> > com.oracle.graal.compiler.hsail.test.lambda.VecmathNBodyTest >> > It is currently disabled from running by the following >> > (canHandleDeoptVirtualObjects() returns false) but you can comment >> > that out to make it run. >> > >> > @Override >> > protected boolean supportsRequiredCapabilities() { >> > return (canHandleDeoptVirtualObjects()); >> > } >> > >> > I was going to say it should pass if -XX:-UseHSAILDeoptimization is >> > on the command line but I see there is a bug in that it still tries to >> > create the host graph even if UseHSAILDeoptimization is false. This >> > logic can be fixed in HSAILHotSpotBackend.java by this little patch. >> > >> > --- >> > >> a/graal/com.oracle.graal.hotspot.hsail/src/com/oracle/graal/hotspot/hsai >> > l/HSAILHotSpotBackend.java Tue May 13 15:38:56 2014 -0500 >> > +++ >> > >> b/graal/com.oracle.graal.hotspot.hsail/src/com/oracle/graal/hotspot/hsai >> > l/HSAILHotSpotBackend.java Tue May 13 17:49:29 2014 -0500 >> > @@ -924,7 +924,9 @@ >> > >> > ExternalCompilationResult compilationResult = >> > (ExternalCompilationResult) crb.compilationResult; >> > HSAILHotSpotLIRGenerationResult lirGenRes = >> > ((HSAILCompilationResultBuilder) crb).lirGenRes; >> > - compilationResult.setHostGraph(prepareHostGraph(method, >> > lirGenRes.getDeopts(), getProviders(), config, numSRegs, numDRegs)); >> > + if (useHSAILDeoptimization) { >> > + compilationResult.setHostGraph(prepareHostGraph(method, >> > lirGenRes.getDeopts(), getProviders(), config, numSRegs, numDRegs)); >> > + } >> > } >> > >> > -- Tom >> > >> > >> > > -----Original Message----- >> > > From: gilwooden at gmail.com [mailto:gilwooden at gmail.com] On Behalf Of >> > > Gilles Duboscq >> > > Sent: Sunday, May 04, 2014 12:17 PM >> > > To: Deneau, Tom >> > > Cc: graal-dev at openjdk.java.net >> > > Subject: Re: VirtualObjects at deoptimization points. >> > > >> > > Hello, >> > > >> > > I currently have a prototype [1] that i would like to test. Before >> > > creating my own tests, i was wondering if you already have tests for >> > > this or if you know of tests that have escaping objects? >> > > >> > > -Gilles >> > > >> > > [1] http://cr.openjdk.java.net/~gdub/HSAILVirtualObjectDeopt.patch >> > > >> > > On Fri, May 2, 2014 at 7:21 PM, Tom Deneau > >> wrote: >> > > > Hi Gilles -- >> > > > >> > > > Could I get an update on the support for VirtualObjects in the >> > > > host >> > > deopt trampoline code? >> > > > >> > > > -- Tom D. >> > > > >> > > >> -----Original Message----- >> > > >> From: gilwooden at gmail.com [mailto:gilwooden at gmail.com] On Behalf >> > > >> Of Gilles Duboscq >> > > >> Sent: Thursday, April 03, 2014 5:04 AM >> > > >> To: Deneau, Tom >> > > >> Cc: graal-dev at openjdk.java.net >> > > >> Subject: Re: VirtualObjects at deoptimization points. >> > > >> >> > > >> Hello Tom, >> > > >> >> > > >> The reason I delayed the implementation of VirtualObjects is that >> > we >> > > >> have to reverse the process that transforms VirtualObjectNodes >> > > >> into VirtualObjects (that's in >> > > >> com.oracle.graal.compiler.gen.DebugInfoBuilder.build(FrameState, >> > > >> LabelRef)). >> > > >> It shouldn't be so complicated to add this support. I'll give it >> > > >> a >> > > try. >> > > >> >> > > >> -Gilles >> > > >> >> > > >> On Tue, Apr 1, 2014 at 1:07 AM, Tom Deneau > >> > > wrote: >> > > >> > Gilles -- >> > > >> > >> > > >> > >> > > >> > >> > > >> > I noticed in one of our java8 lambda tests (not yet pushed to >> > > >> > trunk) we had some object allocation that was eliminated by >> > escape >> > > analysis. >> > > >> > But when we try to run this with the trunk now, we get >> > > >> > >> > > >> > >> > > >> > >> > > >> > com.oracle.graal.graph.GraalInternalError: unimplemented >> > > >> > >> > > >> > at >> > > >> > >> > com.oracle.graal.graph.GraalInternalError.unimplemented(GraalIntern >> > > >> > alE >> > > >> > rror.java:38) >> > > >> > >> > > >> > at >> > > >> > >> > com.oracle.graal.hotspot.hsail.HSAILHotSpotLIRGenerator.getNodeForV >> > > >> > alu >> > > >> > eFromFrame(HSAILHotSpotLIRGenerator.java:182) >> > > >> > >> > > >> > at >> > > >> > >> > com.oracle.graal.hotspot.hsail.HSAILHotSpotLIRGenerator.createFrame >> > > >> > Sta >> > > >> > te(HSAILHotSpotLIRGenerator.java:149) >> > > >> > >> > > >> > at >> > > >> > >> > com.oracle.graal.hotspot.hsail.HSAILHotSpotLIRGenerator.createHostD >> > > >> > eop >> > > >> > tBranch(HSAILHotSpotLIRGenerator.java:140) >> > > >> > >> > > >> > >> > > >> > >> > > >> > where the line 182 in getNodeForValueFromFrame has >> > > >> > >> > > >> > >> > > >> > >> > > >> > >> > > >> > >> > > >> > } else if (localValue instanceof VirtualObject) { >> > > >> > >> > > >> > throw GraalInternalError.unimplemented(); >> > > >> > >> > > >> > } >> > > >> > >> > > >> > >> > > >> > >> > > >> > >> > > >> > >> > > >> > What would we need to do to support VirtualObjects at our >> > > >> > deoptimization infopoints? >> > > >> > >> > > >> > >> > > >> > >> > > >> > >> > > >> > >> > > >> > (We also don't support stack slots yet, but I think I >> > > >> > understand what is needed to support those). >> > > >> > >> > > >> > >> > > >> > >> > > >> > -- Tom >> > > >> > >> > > >> > >> > > > From duboscq at ssw.jku.at Thu May 15 17:30:05 2014 From: duboscq at ssw.jku.at (Gilles Duboscq) Date: Thu, 15 May 2014 19:30:05 +0200 Subject: VirtualObjects at deoptimization points. In-Reply-To: References: Message-ID: Well there must be some local that contain those constant, for example the delT1 argument of computeAcc. When a value is know to be constant, the constant is directly embedded in the debug info. Maybe I didn't understand your question? -Gilles On 15 May 2014 19:04, "Deneau, Tom" wrote: > Gilles -- > > > > Yes this looks good. > > One question: I noticed the infopoint where we are deopting in the new > test does indeed use a virtual object and I see that the fields of the > vobject are mapped to registers. > > > > But what is the purpose of those float constants being in the frame. I > see they are marked in graal as PrimitiveConstants but why would constants > even need to be stored in the locals in the ByteCodeFrame? > > > > -- Tom > > > > 4386[] registerMap[ r40 r42 r43] > com.oracle.graal.compiler.hsail.test.lambda.VecmathNBodyDeoptTest$Body.computeAcc(VecmathNBodyDeoptTest.java:65) > [bci: 20] #locals=12 #expr=0 > > at > com.oracle.graal.compiler.hsail.test.lambda.VecmathNBodyDeoptTest$Body.computeAcc(VecmathNBodyDeoptTest.java:65) > [bci: 20] > > |0 |1 |2 |3 > |4 |5 |6 |7 |8 |9 > |10 |11 > > locals: |d3|a |- |float[1.0|0x3f800000] |float[0.005|0x3ba3d70a] > |vobject:Vector3f:0{x=s7|f,y=s6|f,z=s5|f} |d2|a |s1|i |s8|i |- |- > |- |- > > at > com.oracle.graal.compiler.hsail.test.lambda.VecmathNBodyDeoptTest.lambda$runTest$37(VecmathNBodyDeoptTest.java:109) > [bci: 22] > > |0 |1 |2 |3 |4 |5 > > locals: |- |s0|i |d3|a |d0|a |- |- > > > > > > *From:* Gilles Duboscq [mailto:gilwooden at gmail.com] > *Sent:* Thursday, May 15, 2014 1:29 AM > *To:* Deneau, Tom > *Cc:* graal-dev at openjdk.java.net > *Subject:* Re: VirtualObjects at deoptimization points. > > > > I pushed something which passed the existing tests as well as your new > test: > > http://hg.openjdk.java.net/graal/graal/rev/2208a130d636 > > -Gilles > > Ok, thanks, I will use that. > > -Gilles > > On Wed, May 14, 2014 at 1:11 AM, Tom Deneau wrote: > > Gilles -- > > > > You can try applying the attached patch to create a new test uses virtual > > objects and does force a deopt. > > When I tried this test with your patch, I did not get the correct results > > but I didn't try to trace down whether it was due to anything with > > virtual objects or not. > > > > -- Tom > > > >> -----Original Message----- > >> From: Deneau, Tom > >> Sent: Tuesday, May 13, 2014 5:59 PM > >> To: Deneau, Tom; Gilles Duboscq > >> Cc: graal-dev at openjdk.java.net > >> Subject: RE: VirtualObjects at deoptimization points. > >> > >> Gilles -- > >> > >> I noticed you had a link to a patch, I applied your patch and the one > >> test mentioned below did not get an error at prepareHostGraph time as it > >> usually did. > >> > >> I should add that while this test failed in prepareHostGraph, trying to > >> handle a Virtual Object, this test doesn't actually deopt so it doesn't > >> really test whether the virtual object can be handled correctly in the > >> face of deopt. > >> > >> I can try to modify it so that it does deopt. > >> > >> -- Tom > >> > >> > >> > -----Original Message----- > >> > From: Deneau, Tom > >> > Sent: Tuesday, May 13, 2014 5:53 PM > >> > To: 'Gilles Duboscq' > >> > Cc: graal-dev at openjdk.java.net > >> > Subject: RE: VirtualObjects at deoptimization points. > >> > > >> > Gilles -- > >> > > >> > Sorry for the delay in responding... > >> > There is one test checked in trunk that currently fails because of > >> > lack of VirtualObjectsInDeopt support. > >> > > >> > The test is > >> > com.oracle.graal.compiler.hsail.test.lambda.VecmathNBodyTest > >> > It is currently disabled from running by the following > >> > (canHandleDeoptVirtualObjects() returns false) but you can comment > >> > that out to make it run. > >> > > >> > @Override > >> > protected boolean supportsRequiredCapabilities() { > >> > return (canHandleDeoptVirtualObjects()); > >> > } > >> > > >> > I was going to say it should pass if -XX:-UseHSAILDeoptimization is > >> > on the command line but I see there is a bug in that it still tries to > >> > create the host graph even if UseHSAILDeoptimization is false. This > >> > logic can be fixed in HSAILHotSpotBackend.java by this little patch. > >> > > >> > --- > >> > > >> a/graal/com.oracle.graal.hotspot.hsail/src/com/oracle/graal/hotspot/hsai > >> > l/HSAILHotSpotBackend.java Tue May 13 15:38:56 2014 -0500 > >> > +++ > >> > > >> b/graal/com.oracle.graal.hotspot.hsail/src/com/oracle/graal/hotspot/hsai > >> > l/HSAILHotSpotBackend.java Tue May 13 17:49:29 2014 -0500 > >> > @@ -924,7 +924,9 @@ > >> > > >> > ExternalCompilationResult compilationResult = > >> > (ExternalCompilationResult) crb.compilationResult; > >> > HSAILHotSpotLIRGenerationResult lirGenRes = > >> > ((HSAILCompilationResultBuilder) crb).lirGenRes; > >> > - compilationResult.setHostGraph(prepareHostGraph(method, > >> > lirGenRes.getDeopts(), getProviders(), config, numSRegs, numDRegs)); > >> > + if (useHSAILDeoptimization) { > >> > + compilationResult.setHostGraph(prepareHostGraph(method, > >> > lirGenRes.getDeopts(), getProviders(), config, numSRegs, numDRegs)); > >> > + } > >> > } > >> > > >> > -- Tom > >> > > >> > > >> > > -----Original Message----- > >> > > From: gilwooden at gmail.com [mailto:gilwooden at gmail.com] On Behalf Of > >> > > Gilles Duboscq > >> > > Sent: Sunday, May 04, 2014 12:17 PM > >> > > To: Deneau, Tom > >> > > Cc: graal-dev at openjdk.java.net > >> > > Subject: Re: VirtualObjects at deoptimization points. > >> > > > >> > > Hello, > >> > > > >> > > I currently have a prototype [1] that i would like to test. Before > >> > > creating my own tests, i was wondering if you already have tests for > >> > > this or if you know of tests that have escaping objects? > >> > > > >> > > -Gilles > >> > > > >> > > [1] http://cr.openjdk.java.net/~gdub/HSAILVirtualObjectDeopt.patch > >> > > > >> > > On Fri, May 2, 2014 at 7:21 PM, Tom Deneau > >> wrote: > >> > > > Hi Gilles -- > >> > > > > >> > > > Could I get an update on the support for VirtualObjects in the > >> > > > host > >> > > deopt trampoline code? > >> > > > > >> > > > -- Tom D. > >> > > > > >> > > >> -----Original Message----- > >> > > >> From: gilwooden at gmail.com [mailto:gilwooden at gmail.com] On Behalf > >> > > >> Of Gilles Duboscq > >> > > >> Sent: Thursday, April 03, 2014 5:04 AM > >> > > >> To: Deneau, Tom > >> > > >> Cc: graal-dev at openjdk.java.net > >> > > >> Subject: Re: VirtualObjects at deoptimization points. > >> > > >> > >> > > >> Hello Tom, > >> > > >> > >> > > >> The reason I delayed the implementation of VirtualObjects is that > >> > we > >> > > >> have to reverse the process that transforms VirtualObjectNodes > >> > > >> into VirtualObjects (that's in > >> > > >> com.oracle.graal.compiler.gen.DebugInfoBuilder.build(FrameState, > >> > > >> LabelRef)). > >> > > >> It shouldn't be so complicated to add this support. I'll give it > >> > > >> a > >> > > try. > >> > > >> > >> > > >> -Gilles > >> > > >> > >> > > >> On Tue, Apr 1, 2014 at 1:07 AM, Tom Deneau > >> > > wrote: > >> > > >> > Gilles -- > >> > > >> > > >> > > >> > > >> > > >> > > >> > > >> > I noticed in one of our java8 lambda tests (not yet pushed to > >> > > >> > trunk) we had some object allocation that was eliminated by > >> > escape > >> > > analysis. > >> > > >> > But when we try to run this with the trunk now, we get > >> > > >> > > >> > > >> > > >> > > >> > > >> > > >> > com.oracle.graal.graph.GraalInternalError: unimplemented > >> > > >> > > >> > > >> > at > >> > > >> > > >> > com.oracle.graal.graph.GraalInternalError.unimplemented(GraalIntern > >> > > >> > alE > >> > > >> > rror.java:38) > >> > > >> > > >> > > >> > at > >> > > >> > > >> > com.oracle.graal.hotspot.hsail.HSAILHotSpotLIRGenerator.getNodeForV > >> > > >> > alu > >> > > >> > eFromFrame(HSAILHotSpotLIRGenerator.java:182) > >> > > >> > > >> > > >> > at > >> > > >> > > >> > com.oracle.graal.hotspot.hsail.HSAILHotSpotLIRGenerator.createFrame > >> > > >> > Sta > >> > > >> > te(HSAILHotSpotLIRGenerator.java:149) > >> > > >> > > >> > > >> > at > >> > > >> > > >> > com.oracle.graal.hotspot.hsail.HSAILHotSpotLIRGenerator.createHostD > >> > > >> > eop > >> > > >> > tBranch(HSAILHotSpotLIRGenerator.java:140) > >> > > >> > > >> > > >> > > >> > > >> > > >> > > >> > where the line 182 in getNodeForValueFromFrame has > >> > > >> > > >> > > >> > > >> > > >> > > >> > > >> > > >> > > >> > > >> > > >> > } else if (localValue instanceof VirtualObject) { > >> > > >> > > >> > > >> > throw GraalInternalError.unimplemented(); > >> > > >> > > >> > > >> > } > >> > > >> > > >> > > >> > > >> > > >> > > >> > > >> > > >> > > >> > > >> > > >> > What would we need to do to support VirtualObjects at our > >> > > >> > deoptimization infopoints? > >> > > >> > > >> > > >> > > >> > > >> > > >> > > >> > > >> > > >> > > >> > > >> > (We also don't support stack slots yet, but I think I > >> > > >> > understand what is needed to support those). > >> > > >> > > >> > > >> > > >> > > >> > > >> > > >> > -- Tom > >> > > >> > > >> > > >> > > >> > > > > From tom.deneau at amd.com Thu May 15 18:19:28 2014 From: tom.deneau at amd.com (Deneau, Tom) Date: Thu, 15 May 2014 18:19:28 +0000 Subject: VirtualObjects at deoptimization points. In-Reply-To: References: Message-ID: I guess I would have thought these constants would already be in the bytecode and so wouldn't have to be in the debuginfo. But maybe these are things that the compiler deduced were constant and were not in the bytecode? -- Tom From: gilwooden at gmail.com [mailto:gilwooden at gmail.com] On Behalf Of Gilles Duboscq Sent: Thursday, May 15, 2014 12:30 PM To: Deneau, Tom Cc: graal-dev at openjdk.java.net Subject: RE: VirtualObjects at deoptimization points. Well there must be some local that contain those constant, for example the delT1 argument of computeAcc. When a value is know to be constant, the constant is directly embedded in the debug info. Maybe I didn't understand your question? -Gilles On 15 May 2014 19:04, "Deneau, Tom" > wrote: Gilles -- Yes this looks good. One question: I noticed the infopoint where we are deopting in the new test does indeed use a virtual object and I see that the fields of the vobject are mapped to registers. But what is the purpose of those float constants being in the frame. I see they are marked in graal as PrimitiveConstants but why would constants even need to be stored in the locals in the ByteCodeFrame? -- Tom 4386[] registerMap[ r40 r42 r43] com.oracle.graal.compiler.hsail.test.lambda.VecmathNBodyDeoptTest$Body.computeAcc(VecmathNBodyDeoptTest.java:65) [bci: 20] #locals=12 #expr=0 at com.oracle.graal.compiler.hsail.test.lambda.VecmathNBodyDeoptTest$Body.computeAcc(VecmathNBodyDeoptTest.java:65) [bci: 20] |0 |1 |2 |3 |4 |5 |6 |7 |8 |9 |10 |11 locals: |d3|a |- |float[1.0|0x3f800000] |float[0.005|0x3ba3d70a] |vobject:Vector3f:0{x=s7|f,y=s6|f,z=s5|f} |d2|a |s1|i |s8|i |- |- |- |- at com.oracle.graal.compiler.hsail.test.lambda.VecmathNBodyDeoptTest.lambda$runTest$37(VecmathNBodyDeoptTest.java:109) [bci: 22] |0 |1 |2 |3 |4 |5 locals: |- |s0|i |d3|a |d0|a |- |- From: Gilles Duboscq [mailto:gilwooden at gmail.com] Sent: Thursday, May 15, 2014 1:29 AM To: Deneau, Tom Cc: graal-dev at openjdk.java.net Subject: Re: VirtualObjects at deoptimization points. I pushed something which passed the existing tests as well as your new test: http://hg.openjdk.java.net/graal/graal/rev/2208a130d636 -Gilles Ok, thanks, I will use that. -Gilles On Wed, May 14, 2014 at 1:11 AM, Tom Deneau > wrote: > Gilles -- > > You can try applying the attached patch to create a new test uses virtual > objects and does force a deopt. > When I tried this test with your patch, I did not get the correct results > but I didn't try to trace down whether it was due to anything with > virtual objects or not. > > -- Tom > >> -----Original Message----- >> From: Deneau, Tom >> Sent: Tuesday, May 13, 2014 5:59 PM >> To: Deneau, Tom; Gilles Duboscq >> Cc: graal-dev at openjdk.java.net >> Subject: RE: VirtualObjects at deoptimization points. >> >> Gilles -- >> >> I noticed you had a link to a patch, I applied your patch and the one >> test mentioned below did not get an error at prepareHostGraph time as it >> usually did. >> >> I should add that while this test failed in prepareHostGraph, trying to >> handle a Virtual Object, this test doesn't actually deopt so it doesn't >> really test whether the virtual object can be handled correctly in the >> face of deopt. >> >> I can try to modify it so that it does deopt. >> >> -- Tom >> >> >> > -----Original Message----- >> > From: Deneau, Tom >> > Sent: Tuesday, May 13, 2014 5:53 PM >> > To: 'Gilles Duboscq' >> > Cc: graal-dev at openjdk.java.net >> > Subject: RE: VirtualObjects at deoptimization points. >> > >> > Gilles -- >> > >> > Sorry for the delay in responding... >> > There is one test checked in trunk that currently fails because of >> > lack of VirtualObjectsInDeopt support. >> > >> > The test is >> > com.oracle.graal.compiler.hsail.test.lambda.VecmathNBodyTest >> > It is currently disabled from running by the following >> > (canHandleDeoptVirtualObjects() returns false) but you can comment >> > that out to make it run. >> > >> > @Override >> > protected boolean supportsRequiredCapabilities() { >> > return (canHandleDeoptVirtualObjects()); >> > } >> > >> > I was going to say it should pass if -XX:-UseHSAILDeoptimization is >> > on the command line but I see there is a bug in that it still tries to >> > create the host graph even if UseHSAILDeoptimization is false. This >> > logic can be fixed in HSAILHotSpotBackend.java by this little patch. >> > >> > --- >> > >> a/graal/com.oracle.graal.hotspot.hsail/src/com/oracle/graal/hotspot/hsai >> > l/HSAILHotSpotBackend.java Tue May 13 15:38:56 2014 -0500 >> > +++ >> > >> b/graal/com.oracle.graal.hotspot.hsail/src/com/oracle/graal/hotspot/hsai >> > l/HSAILHotSpotBackend.java Tue May 13 17:49:29 2014 -0500 >> > @@ -924,7 +924,9 @@ >> > >> > ExternalCompilationResult compilationResult = >> > (ExternalCompilationResult) crb.compilationResult; >> > HSAILHotSpotLIRGenerationResult lirGenRes = >> > ((HSAILCompilationResultBuilder) crb).lirGenRes; >> > - compilationResult.setHostGraph(prepareHostGraph(method, >> > lirGenRes.getDeopts(), getProviders(), config, numSRegs, numDRegs)); >> > + if (useHSAILDeoptimization) { >> > + compilationResult.setHostGraph(prepareHostGraph(method, >> > lirGenRes.getDeopts(), getProviders(), config, numSRegs, numDRegs)); >> > + } >> > } >> > >> > -- Tom >> > >> > >> > > -----Original Message----- >> > > From: gilwooden at gmail.com [mailto:gilwooden at gmail.com] On Behalf Of >> > > Gilles Duboscq >> > > Sent: Sunday, May 04, 2014 12:17 PM >> > > To: Deneau, Tom >> > > Cc: graal-dev at openjdk.java.net >> > > Subject: Re: VirtualObjects at deoptimization points. >> > > >> > > Hello, >> > > >> > > I currently have a prototype [1] that i would like to test. Before >> > > creating my own tests, i was wondering if you already have tests for >> > > this or if you know of tests that have escaping objects? >> > > >> > > -Gilles >> > > >> > > [1] http://cr.openjdk.java.net/~gdub/HSAILVirtualObjectDeopt.patch >> > > >> > > On Fri, May 2, 2014 at 7:21 PM, Tom Deneau > >> wrote: >> > > > Hi Gilles -- >> > > > >> > > > Could I get an update on the support for VirtualObjects in the >> > > > host >> > > deopt trampoline code? >> > > > >> > > > -- Tom D. >> > > > >> > > >> -----Original Message----- >> > > >> From: gilwooden at gmail.com [mailto:gilwooden at gmail.com] On Behalf >> > > >> Of Gilles Duboscq >> > > >> Sent: Thursday, April 03, 2014 5:04 AM >> > > >> To: Deneau, Tom >> > > >> Cc: graal-dev at openjdk.java.net >> > > >> Subject: Re: VirtualObjects at deoptimization points. >> > > >> >> > > >> Hello Tom, >> > > >> >> > > >> The reason I delayed the implementation of VirtualObjects is that >> > we >> > > >> have to reverse the process that transforms VirtualObjectNodes >> > > >> into VirtualObjects (that's in >> > > >> com.oracle.graal.compiler.gen.DebugInfoBuilder.build(FrameState, >> > > >> LabelRef)). >> > > >> It shouldn't be so complicated to add this support. I'll give it >> > > >> a >> > > try. >> > > >> >> > > >> -Gilles >> > > >> >> > > >> On Tue, Apr 1, 2014 at 1:07 AM, Tom Deneau > >> > > wrote: >> > > >> > Gilles -- >> > > >> > >> > > >> > >> > > >> > >> > > >> > I noticed in one of our java8 lambda tests (not yet pushed to >> > > >> > trunk) we had some object allocation that was eliminated by >> > escape >> > > analysis. >> > > >> > But when we try to run this with the trunk now, we get >> > > >> > >> > > >> > >> > > >> > >> > > >> > com.oracle.graal.graph.GraalInternalError: unimplemented >> > > >> > >> > > >> > at >> > > >> > >> > com.oracle.graal.graph.GraalInternalError.unimplemented(GraalIntern >> > > >> > alE >> > > >> > rror.java:38) >> > > >> > >> > > >> > at >> > > >> > >> > com.oracle.graal.hotspot.hsail.HSAILHotSpotLIRGenerator.getNodeForV >> > > >> > alu >> > > >> > eFromFrame(HSAILHotSpotLIRGenerator.java:182) >> > > >> > >> > > >> > at >> > > >> > >> > com.oracle.graal.hotspot.hsail.HSAILHotSpotLIRGenerator.createFrame >> > > >> > Sta >> > > >> > te(HSAILHotSpotLIRGenerator.java:149) >> > > >> > >> > > >> > at >> > > >> > >> > com.oracle.graal.hotspot.hsail.HSAILHotSpotLIRGenerator.createHostD >> > > >> > eop >> > > >> > tBranch(HSAILHotSpotLIRGenerator.java:140) >> > > >> > >> > > >> > >> > > >> > >> > > >> > where the line 182 in getNodeForValueFromFrame has >> > > >> > >> > > >> > >> > > >> > >> > > >> > >> > > >> > >> > > >> > } else if (localValue instanceof VirtualObject) { >> > > >> > >> > > >> > throw GraalInternalError.unimplemented(); >> > > >> > >> > > >> > } >> > > >> > >> > > >> > >> > > >> > >> > > >> > >> > > >> > >> > > >> > What would we need to do to support VirtualObjects at our >> > > >> > deoptimization infopoints? >> > > >> > >> > > >> > >> > > >> > >> > > >> > >> > > >> > >> > > >> > (We also don't support stack slots yet, but I think I >> > > >> > understand what is needed to support those). >> > > >> > >> > > >> > >> > > >> > >> > > >> > -- Tom >> > > >> > >> > > >> > >> > > > From doug.simon at oracle.com Thu May 15 18:59:30 2014 From: doug.simon at oracle.com (Doug Simon) Date: Thu, 15 May 2014 20:59:30 +0200 Subject: VirtualObjects at deoptimization points. In-Reply-To: References: Message-ID: <33D34EB8-4BA8-4E94-9307-DF0F51956B42@oracle.com> This is almost certainly because the deopt restart point is after the bytecode that loads the constant(s). -Doug On May 15, 2014, at 8:19 PM, Deneau, Tom wrote: > I guess I would have thought these constants would already be in the bytecode > and so wouldn't have to be in the debuginfo. But maybe these are things that > the compiler deduced were constant and were not in the bytecode? > > -- Tom > > > From: gilwooden at gmail.com [mailto:gilwooden at gmail.com] On Behalf Of Gilles Duboscq > Sent: Thursday, May 15, 2014 12:30 PM > To: Deneau, Tom > Cc: graal-dev at openjdk.java.net > Subject: RE: VirtualObjects at deoptimization points. > > > Well there must be some local that contain those constant, for example the delT1 argument of computeAcc. > > When a value is know to be constant, the constant is directly embedded in the debug info. > > Maybe I didn't understand your question? > > -Gilles > On 15 May 2014 19:04, "Deneau, Tom" > wrote: > Gilles -- > > Yes this looks good. > One question: I noticed the infopoint where we are deopting in the new test does indeed use a virtual object and I see that the fields of the vobject are mapped to registers. > > But what is the purpose of those float constants being in the frame. I see they are marked in graal as PrimitiveConstants but why would constants even need to be stored in the locals in the ByteCodeFrame? > > -- Tom > > 4386[] registerMap[ r40 r42 r43] com.oracle.graal.compiler.hsail.test.lambda.VecmathNBodyDeoptTest$Body.computeAcc(VecmathNBodyDeoptTest.java:65) [bci: 20] #locals=12 #expr=0 > at com.oracle.graal.compiler.hsail.test.lambda.VecmathNBodyDeoptTest$Body.computeAcc(VecmathNBodyDeoptTest.java:65) [bci: 20] > |0 |1 |2 |3 |4 |5 |6 |7 |8 |9 |10 |11 > locals: |d3|a |- |float[1.0|0x3f800000] |float[0.005|0x3ba3d70a] |vobject:Vector3f:0{x=s7|f,y=s6|f,z=s5|f} |d2|a |s1|i |s8|i |- |- |- |- > at com.oracle.graal.compiler.hsail.test.lambda.VecmathNBodyDeoptTest.lambda$runTest$37(VecmathNBodyDeoptTest.java:109) [bci: 22] > |0 |1 |2 |3 |4 |5 > locals: |- |s0|i |d3|a |d0|a |- |- > > > From: Gilles Duboscq [mailto:gilwooden at gmail.com] > Sent: Thursday, May 15, 2014 1:29 AM > To: Deneau, Tom > Cc: graal-dev at openjdk.java.net > Subject: Re: VirtualObjects at deoptimization points. > > > I pushed something which passed the existing tests as well as your new test: > > http://hg.openjdk.java.net/graal/graal/rev/2208a130d636 > > -Gilles > Ok, thanks, I will use that. > > -Gilles > > On Wed, May 14, 2014 at 1:11 AM, Tom Deneau > wrote: >> Gilles -- >> >> You can try applying the attached patch to create a new test uses virtual >> objects and does force a deopt. >> When I tried this test with your patch, I did not get the correct results >> but I didn't try to trace down whether it was due to anything with >> virtual objects or not. >> >> -- Tom >> >>> -----Original Message----- >>> From: Deneau, Tom >>> Sent: Tuesday, May 13, 2014 5:59 PM >>> To: Deneau, Tom; Gilles Duboscq >>> Cc: graal-dev at openjdk.java.net >>> Subject: RE: VirtualObjects at deoptimization points. >>> >>> Gilles -- >>> >>> I noticed you had a link to a patch, I applied your patch and the one >>> test mentioned below did not get an error at prepareHostGraph time as it >>> usually did. >>> >>> I should add that while this test failed in prepareHostGraph, trying to >>> handle a Virtual Object, this test doesn't actually deopt so it doesn't >>> really test whether the virtual object can be handled correctly in the >>> face of deopt. >>> >>> I can try to modify it so that it does deopt. >>> >>> -- Tom >>> >>> >>>> -----Original Message----- >>>> From: Deneau, Tom >>>> Sent: Tuesday, May 13, 2014 5:53 PM >>>> To: 'Gilles Duboscq' >>>> Cc: graal-dev at openjdk.java.net >>>> Subject: RE: VirtualObjects at deoptimization points. >>>> >>>> Gilles -- >>>> >>>> Sorry for the delay in responding... >>>> There is one test checked in trunk that currently fails because of >>>> lack of VirtualObjectsInDeopt support. >>>> >>>> The test is >>>> com.oracle.graal.compiler.hsail.test.lambda.VecmathNBodyTest >>>> It is currently disabled from running by the following >>>> (canHandleDeoptVirtualObjects() returns false) but you can comment >>>> that out to make it run. >>>> >>>> @Override >>>> protected boolean supportsRequiredCapabilities() { >>>> return (canHandleDeoptVirtualObjects()); >>>> } >>>> >>>> I was going to say it should pass if -XX:-UseHSAILDeoptimization is >>>> on the command line but I see there is a bug in that it still tries to >>>> create the host graph even if UseHSAILDeoptimization is false. This >>>> logic can be fixed in HSAILHotSpotBackend.java by this little patch. >>>> >>>> --- >>>> >>> a/graal/com.oracle.graal.hotspot.hsail/src/com/oracle/graal/hotspot/hsai >>>> l/HSAILHotSpotBackend.java Tue May 13 15:38:56 2014 -0500 >>>> +++ >>>> >>> b/graal/com.oracle.graal.hotspot.hsail/src/com/oracle/graal/hotspot/hsai >>>> l/HSAILHotSpotBackend.java Tue May 13 17:49:29 2014 -0500 >>>> @@ -924,7 +924,9 @@ >>>> >>>> ExternalCompilationResult compilationResult = >>>> (ExternalCompilationResult) crb.compilationResult; >>>> HSAILHotSpotLIRGenerationResult lirGenRes = >>>> ((HSAILCompilationResultBuilder) crb).lirGenRes; >>>> - compilationResult.setHostGraph(prepareHostGraph(method, >>>> lirGenRes.getDeopts(), getProviders(), config, numSRegs, numDRegs)); >>>> + if (useHSAILDeoptimization) { >>>> + compilationResult.setHostGraph(prepareHostGraph(method, >>>> lirGenRes.getDeopts(), getProviders(), config, numSRegs, numDRegs)); >>>> + } >>>> } >>>> >>>> -- Tom >>>> >>>> >>>>> -----Original Message----- >>>>> From: gilwooden at gmail.com [mailto:gilwooden at gmail.com] On Behalf Of >>>>> Gilles Duboscq >>>>> Sent: Sunday, May 04, 2014 12:17 PM >>>>> To: Deneau, Tom >>>>> Cc: graal-dev at openjdk.java.net >>>>> Subject: Re: VirtualObjects at deoptimization points. >>>>> >>>>> Hello, >>>>> >>>>> I currently have a prototype [1] that i would like to test. Before >>>>> creating my own tests, i was wondering if you already have tests for >>>>> this or if you know of tests that have escaping objects? >>>>> >>>>> -Gilles >>>>> >>>>> [1] http://cr.openjdk.java.net/~gdub/HSAILVirtualObjectDeopt.patch >>>>> >>>>> On Fri, May 2, 2014 at 7:21 PM, Tom Deneau > >>> wrote: >>>>>> Hi Gilles -- >>>>>> >>>>>> Could I get an update on the support for VirtualObjects in the >>>>>> host >>>>> deopt trampoline code? >>>>>> >>>>>> -- Tom D. >>>>>> >>>>>>> -----Original Message----- >>>>>>> From: gilwooden at gmail.com [mailto:gilwooden at gmail.com] On Behalf >>>>>>> Of Gilles Duboscq >>>>>>> Sent: Thursday, April 03, 2014 5:04 AM >>>>>>> To: Deneau, Tom >>>>>>> Cc: graal-dev at openjdk.java.net >>>>>>> Subject: Re: VirtualObjects at deoptimization points. >>>>>>> >>>>>>> Hello Tom, >>>>>>> >>>>>>> The reason I delayed the implementation of VirtualObjects is that >>>> we >>>>>>> have to reverse the process that transforms VirtualObjectNodes >>>>>>> into VirtualObjects (that's in >>>>>>> com.oracle.graal.compiler.gen.DebugInfoBuilder.build(FrameState, >>>>>>> LabelRef)). >>>>>>> It shouldn't be so complicated to add this support. I'll give it >>>>>>> a >>>>> try. >>>>>>> >>>>>>> -Gilles >>>>>>> >>>>>>> On Tue, Apr 1, 2014 at 1:07 AM, Tom Deneau > >>>>> wrote: >>>>>>>> Gilles -- >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> I noticed in one of our java8 lambda tests (not yet pushed to >>>>>>>> trunk) we had some object allocation that was eliminated by >>>> escape >>>>> analysis. >>>>>>>> But when we try to run this with the trunk now, we get >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> com.oracle.graal.graph.GraalInternalError: unimplemented >>>>>>>> >>>>>>>> at >>>>>>>> >>>> com.oracle.graal.graph.GraalInternalError.unimplemented(GraalIntern >>>>>>>> alE >>>>>>>> rror.java:38) >>>>>>>> >>>>>>>> at >>>>>>>> >>>> com.oracle.graal.hotspot.hsail.HSAILHotSpotLIRGenerator.getNodeForV >>>>>>>> alu >>>>>>>> eFromFrame(HSAILHotSpotLIRGenerator.java:182) >>>>>>>> >>>>>>>> at >>>>>>>> >>>> com.oracle.graal.hotspot.hsail.HSAILHotSpotLIRGenerator.createFrame >>>>>>>> Sta >>>>>>>> te(HSAILHotSpotLIRGenerator.java:149) >>>>>>>> >>>>>>>> at >>>>>>>> >>>> com.oracle.graal.hotspot.hsail.HSAILHotSpotLIRGenerator.createHostD >>>>>>>> eop >>>>>>>> tBranch(HSAILHotSpotLIRGenerator.java:140) >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> where the line 182 in getNodeForValueFromFrame has >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> } else if (localValue instanceof VirtualObject) { >>>>>>>> >>>>>>>> throw GraalInternalError.unimplemented(); >>>>>>>> >>>>>>>> } >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> What would we need to do to support VirtualObjects at our >>>>>>>> deoptimization infopoints? >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> (We also don't support stack slots yet, but I think I >>>>>>>> understand what is needed to support those). >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> -- Tom >>>>>>>> >>>>>>>> >>>>>> From tom.deneau at amd.com Thu May 15 19:11:21 2014 From: tom.deneau at amd.com (Deneau, Tom) Date: Thu, 15 May 2014 19:11:21 +0000 Subject: VirtualObjects at deoptimization points. In-Reply-To: <33D34EB8-4BA8-4E94-9307-DF0F51956B42@oracle.com> References: <33D34EB8-4BA8-4E94-9307-DF0F51956B42@oracle.com> Message-ID: ah, that makes sense... > -----Original Message----- > From: Doug Simon [mailto:doug.simon at oracle.com] > Sent: Thursday, May 15, 2014 2:00 PM > To: Deneau, Tom > Cc: Gilles Duboscq; graal-dev at openjdk.java.net > Subject: Re: VirtualObjects at deoptimization points. > > This is almost certainly because the deopt restart point is after the > bytecode that loads the constant(s). > > -Doug > > On May 15, 2014, at 8:19 PM, Deneau, Tom wrote: > > > I guess I would have thought these constants would already be in the > > bytecode and so wouldn't have to be in the debuginfo. But maybe these > > are things that the compiler deduced were constant and were not in the > bytecode? > > > > -- Tom > > > > > > From: gilwooden at gmail.com [mailto:gilwooden at gmail.com] On Behalf Of > > Gilles Duboscq > > Sent: Thursday, May 15, 2014 12:30 PM > > To: Deneau, Tom > > Cc: graal-dev at openjdk.java.net > > Subject: RE: VirtualObjects at deoptimization points. > > > > > > Well there must be some local that contain those constant, for example > the delT1 argument of computeAcc. > > > > When a value is know to be constant, the constant is directly embedded > in the debug info. > > > > Maybe I didn't understand your question? > > > > -Gilles > > On 15 May 2014 19:04, "Deneau, Tom" > > wrote: > > Gilles -- > > > > Yes this looks good. > > One question: I noticed the infopoint where we are deopting in the > new test does indeed use a virtual object and I see that the fields of > the vobject are mapped to registers. > > > > But what is the purpose of those float constants being in the frame. > I see they are marked in graal as PrimitiveConstants but why would > constants even need to be stored in the locals in the ByteCodeFrame? > > > > -- Tom > > > > 4386[] registerMap[ r40 r42 r43] > > > com.oracle.graal.compiler.hsail.test.lambda.VecmathNBodyDeoptTest$Body.c > omputeAcc(VecmathNBodyDeoptTest.java:65) [bci: 20] #locals=12 #expr=0 > at > com.oracle.graal.compiler.hsail.test.lambda.VecmathNBodyDeoptTest$Body.c > omputeAcc(VecmathNBodyDeoptTest.java:65) [bci: 20] > > |0 |1 |2 |3 > |4 |5 |6 |7 |8 |9 > |10 |11 > > locals: |d3|a |- |float[1.0|0x3f800000] |float[0.005|0x3ba3d70a] > |vobject:Vector3f:0{x=s7|f,y=s6|f,z=s5|f} |d2|a |s1|i |s8|i |- |- > |- |- > > at > com.oracle.graal.compiler.hsail.test.lambda.VecmathNBodyDeoptTest.lambda > $runTest$37(VecmathNBodyDeoptTest.java:109) [bci: 22] > > |0 |1 |2 |3 |4 |5 > > locals: |- |s0|i |d3|a |d0|a |- |- > > > > > > From: Gilles Duboscq > > [mailto:gilwooden at gmail.com] > > Sent: Thursday, May 15, 2014 1:29 AM > > To: Deneau, Tom > > Cc: graal-dev at openjdk.java.net > > Subject: Re: VirtualObjects at deoptimization points. > > > > > > I pushed something which passed the existing tests as well as your new > test: > > > > http://hg.openjdk.java.net/graal/graal/rev/2208a130d636 > > > > -Gilles > > Ok, thanks, I will use that. > > > > -Gilles > > > > On Wed, May 14, 2014 at 1:11 AM, Tom Deneau > > wrote: > >> Gilles -- > >> > >> You can try applying the attached patch to create a new test uses > >> virtual objects and does force a deopt. > >> When I tried this test with your patch, I did not get the correct > >> results but I didn't try to trace down whether it was due to anything > >> with virtual objects or not. > >> > >> -- Tom > >> > >>> -----Original Message----- > >>> From: Deneau, Tom > >>> Sent: Tuesday, May 13, 2014 5:59 PM > >>> To: Deneau, Tom; Gilles Duboscq > >>> Cc: graal-dev at openjdk.java.net > >>> Subject: RE: VirtualObjects at deoptimization points. > >>> > >>> Gilles -- > >>> > >>> I noticed you had a link to a patch, I applied your patch and the > >>> one test mentioned below did not get an error at prepareHostGraph > >>> time as it usually did. > >>> > >>> I should add that while this test failed in prepareHostGraph, trying > >>> to handle a Virtual Object, this test doesn't actually deopt so it > >>> doesn't really test whether the virtual object can be handled > >>> correctly in the face of deopt. > >>> > >>> I can try to modify it so that it does deopt. > >>> > >>> -- Tom > >>> > >>> > >>>> -----Original Message----- > >>>> From: Deneau, Tom > >>>> Sent: Tuesday, May 13, 2014 5:53 PM > >>>> To: 'Gilles Duboscq' > >>>> Cc: graal-dev at openjdk.java.net > >>>> Subject: RE: VirtualObjects at deoptimization points. > >>>> > >>>> Gilles -- > >>>> > >>>> Sorry for the delay in responding... > >>>> There is one test checked in trunk that currently fails because of > >>>> lack of VirtualObjectsInDeopt support. > >>>> > >>>> The test is > >>>> com.oracle.graal.compiler.hsail.test.lambda.VecmathNBodyTest > >>>> It is currently disabled from running by the following > >>>> (canHandleDeoptVirtualObjects() returns false) but you can comment > >>>> that out to make it run. > >>>> > >>>> @Override > >>>> protected boolean supportsRequiredCapabilities() { > >>>> return (canHandleDeoptVirtualObjects()); > >>>> } > >>>> > >>>> I was going to say it should pass if -XX:-UseHSAILDeoptimization > >>>> is on the command line but I see there is a bug in that it still > >>>> tries to create the host graph even if UseHSAILDeoptimization is > >>>> false. This logic can be fixed in HSAILHotSpotBackend.java by this > little patch. > >>>> > >>>> --- > >>>> > >>> a/graal/com.oracle.graal.hotspot.hsail/src/com/oracle/graal/hotspot/ > >>> hsai > >>>> l/HSAILHotSpotBackend.java Tue May 13 15:38:56 2014 -0500 > >>>> +++ > >>>> > >>> b/graal/com.oracle.graal.hotspot.hsail/src/com/oracle/graal/hotspot/ > >>> hsai > >>>> l/HSAILHotSpotBackend.java Tue May 13 17:49:29 2014 -0500 @@ > >>>> -924,7 +924,9 @@ > >>>> > >>>> ExternalCompilationResult compilationResult = > >>>> (ExternalCompilationResult) crb.compilationResult; > >>>> HSAILHotSpotLIRGenerationResult lirGenRes = > >>>> ((HSAILCompilationResultBuilder) crb).lirGenRes; > >>>> - compilationResult.setHostGraph(prepareHostGraph(method, > >>>> lirGenRes.getDeopts(), getProviders(), config, numSRegs, > >>>> numDRegs)); > >>>> + if (useHSAILDeoptimization) { > >>>> + > >>>> + compilationResult.setHostGraph(prepareHostGraph(method, > >>>> lirGenRes.getDeopts(), getProviders(), config, numSRegs, > >>>> numDRegs)); > >>>> + } > >>>> } > >>>> > >>>> -- Tom > >>>> > >>>> > >>>>> -----Original Message----- > >>>>> From: gilwooden at gmail.com > >>>>> [mailto:gilwooden at gmail.com] On Behalf > >>>>> Of Gilles Duboscq > >>>>> Sent: Sunday, May 04, 2014 12:17 PM > >>>>> To: Deneau, Tom > >>>>> Cc: graal-dev at openjdk.java.net > >>>>> Subject: Re: VirtualObjects at deoptimization points. > >>>>> > >>>>> Hello, > >>>>> > >>>>> I currently have a prototype [1] that i would like to test. Before > >>>>> creating my own tests, i was wondering if you already have tests > >>>>> for this or if you know of tests that have escaping objects? > >>>>> > >>>>> -Gilles > >>>>> > >>>>> [1] http://cr.openjdk.java.net/~gdub/HSAILVirtualObjectDeopt.patch > >>>>> > >>>>> On Fri, May 2, 2014 at 7:21 PM, Tom Deneau > >>>>> > > >>> wrote: > >>>>>> Hi Gilles -- > >>>>>> > >>>>>> Could I get an update on the support for VirtualObjects in the > >>>>>> host > >>>>> deopt trampoline code? > >>>>>> > >>>>>> -- Tom D. > >>>>>> > >>>>>>> -----Original Message----- > >>>>>>> From: gilwooden at gmail.com > >>>>>>> [mailto:gilwooden at gmail.com] On > >>>>>>> Behalf Of Gilles Duboscq > >>>>>>> Sent: Thursday, April 03, 2014 5:04 AM > >>>>>>> To: Deneau, Tom > >>>>>>> Cc: > >>>>>>> graal-dev at openjdk.java.net > >>>>>>> Subject: Re: VirtualObjects at deoptimization points. > >>>>>>> > >>>>>>> Hello Tom, > >>>>>>> > >>>>>>> The reason I delayed the implementation of VirtualObjects is > >>>>>>> that > >>>> we > >>>>>>> have to reverse the process that transforms VirtualObjectNodes > >>>>>>> into VirtualObjects (that's in > >>>>>>> com.oracle.graal.compiler.gen.DebugInfoBuilder.build(FrameState, > >>>>>>> LabelRef)). > >>>>>>> It shouldn't be so complicated to add this support. I'll give it > >>>>>>> a > >>>>> try. > >>>>>>> > >>>>>>> -Gilles > >>>>>>> > >>>>>>> On Tue, Apr 1, 2014 at 1:07 AM, Tom Deneau > >>>>>>> > > >>>>> wrote: > >>>>>>>> Gilles -- > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> I noticed in one of our java8 lambda tests (not yet pushed to > >>>>>>>> trunk) we had some object allocation that was eliminated by > >>>> escape > >>>>> analysis. > >>>>>>>> But when we try to run this with the trunk now, we get > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> com.oracle.graal.graph.GraalInternalError: unimplemented > >>>>>>>> > >>>>>>>> at > >>>>>>>> > >>>> com.oracle.graal.graph.GraalInternalError.unimplemented(GraalIntern > >>>>>>>> alE > >>>>>>>> rror.java:38) > >>>>>>>> > >>>>>>>> at > >>>>>>>> > >>>> com.oracle.graal.hotspot.hsail.HSAILHotSpotLIRGenerator.getNodeForV > >>>>>>>> alu > >>>>>>>> eFromFrame(HSAILHotSpotLIRGenerator.java:182) > >>>>>>>> > >>>>>>>> at > >>>>>>>> > >>>> com.oracle.graal.hotspot.hsail.HSAILHotSpotLIRGenerator.createFrame > >>>>>>>> Sta > >>>>>>>> te(HSAILHotSpotLIRGenerator.java:149) > >>>>>>>> > >>>>>>>> at > >>>>>>>> > >>>> com.oracle.graal.hotspot.hsail.HSAILHotSpotLIRGenerator.createHostD > >>>>>>>> eop > >>>>>>>> tBranch(HSAILHotSpotLIRGenerator.java:140) > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> where the line 182 in getNodeForValueFromFrame has > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> } else if (localValue instanceof VirtualObject) { > >>>>>>>> > >>>>>>>> throw GraalInternalError.unimplemented(); > >>>>>>>> > >>>>>>>> } > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> What would we need to do to support VirtualObjects at our > >>>>>>>> deoptimization infopoints? > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> (We also don't support stack slots yet, but I think I > >>>>>>>> understand what is needed to support those). > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> -- Tom > >>>>>>>> > >>>>>>>> > >>>>>> From tom.deneau at amd.com Thu May 15 21:11:08 2014 From: tom.deneau at amd.com (Deneau, Tom) Date: Thu, 15 May 2014 21:11:08 +0000 Subject: nodeIntrinsic to load an hsail kernarg Message-ID: I would like to create special HSAILNode with a @NodeIntrinsic which would end up generating HSAIL code to load from a named kernarg. So for instance if the kernel prologue had align 8 kernarg_f64 %_foo, I could write snippet code something like double someVar = HSAILKernArgNode.loadDouble("%_foo"); and have it end up generating the following HSAIL ld_kernarg_f64 $dxx, [%_foo] where $dxx represents the register assigned to someVar. I'm not sure of the best template to use for such a node. I tried the one shown below and when I compile with the HSAIL backend, it appears not be recognizing the @NodeIntrinsic annotation but just generating the regular body of the loadDouble method. I should add that at the moment I have not fully implemented this in the LIR and so in the HSAILLIRGenerator we have public Value emitLoadKernArg(Kind kind, String argName) { throw GraalInternalError.unimplemented(); } =========================== public class HSAILKernArgNode extends FloatingNode implements Canonicalizable { private final String argName; public String getArgName() { return argName; } /** * Creates a new HSAILKernArgNode. * */ public HSAILKernArgNode(Kind kind, String argName) { super(StampFactory.forKind(kind)); this.argName = argName; } public void generate(NodeLIRBuilderTool gen) { HSAILLIRGenerator hsailgen = (HSAILLIRGenerator)(gen.getLIRGeneratorTool()); Value result = hsailgen.emitLoadKernArg(getKind(), getArgName()); gen.setResult(this, result); } @Override public Node canonical(CanonicalizerTool tool) { return this; } @NodeIntrinsic public static double loadDouble(Kind kind, @ConstantNodeParameter String argName) { return 42.1; // filler code } public static double loadDouble(String argName) { return loadDouble(Kind.Double, argName); } } -- Tom From tom.deneau at amd.com Thu May 15 22:36:05 2014 From: tom.deneau at amd.com (Deneau, Tom) Date: Thu, 15 May 2014 22:36:05 +0000 Subject: small webrev to enable some hsail virtual call inlining Message-ID: I submitted a small webrev that enables some hsail virtual call inlining in a few junit tests... http://cr.openjdk.java.net/~tdeneau/graal-webrevs/webrev-hsail-virtual-inlining/webrev/ Changes * tests that want to inline multiple target calls need to have enough profile information so the graal Hsail backend knows which targets to inline. Increased the kernel range to accomplish this. * The StrategySwitch implementation didn't handle switches of type Object. * The basic VirtualCallTest had two targets. I added variations that had 3 and 4 targets. These can only be run successfully with -XX:TypeProfileWidth being set to 3 or 4. However they check TypeProfileWidth and just don't run if is not enough, so they do not fail under the default hotspot configuration (TypeProfileWidth = 2). Note: I had hoped to enable passing of some other tests had virtual targets, for instance HashMapGetTest. However HSAIL still requires complete inlining and the complete inlining of HashMap.Get fails because of maximum recursive depth being exceeded. I believe this is on the TreeNode part of HashMap support, Treenode.find(). Maybe it is possible to do a substitution that does not use recursion. I've noticed recursion hitting us in a few other places as well, some of which I would not expect for instance Float.toString() which ends up trying to inline FDBigInteger.big5powRec -- Tom From doug.simon at oracle.com Fri May 16 01:00:08 2014 From: doug.simon at oracle.com (doug.simon at oracle.com) Date: Fri, 16 May 2014 01:00:08 +0000 Subject: hg: graal/graal: 33 new changesets Message-ID: <201405160100.s4G10sP5021807@aojmv0008> Changeset: 4ead444b15aa Author: Gilles Duboscq Date: 2014-05-15 16:44 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/4ead444b15aa Fix inverted condition in Debug.create(Metric|Timer) ! graal/com.oracle.graal.debug/src/com/oracle/graal/debug/Debug.java Changeset: 1b0141150854 Author: Gilles Duboscq Date: 2014-05-15 16:45 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/1b0141150854 Use replaceAtPredecessor rather than predecessor().replaceFirstSuccessor in DeoptimizationGroupingPhase ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/DeoptimizationGroupingPhase.java Changeset: aa7956c4778d Author: Miguel Garcia Date: 2014-05-15 10:52 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/aa7956c4778d [inlining] better distinguishable name, GraphInfo becomes CallsiteHolder ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/inlining/InliningPhase.java Changeset: 382009d82874 Author: Miguel Garcia Date: 2014-05-15 11:01 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/382009d82874 [inlining] moving CallsiteHolder to upper level + graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/inlining/CallsiteHolder.java ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/inlining/InliningPhase.java Changeset: af9580a11c87 Author: Miguel Garcia Date: 2014-05-15 11:09 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/af9580a11c87 [inlining] moved InliningPolicy to newly created package inlining.policy ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/inlining/InliningPhase.java ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/inlining/InliningUtil.java + graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/inlining/policy/InliningPolicy.java Changeset: f7b2dfc5b78f Author: Miguel Garcia Date: 2014-05-15 11:16 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/f7b2dfc5b78f [inlining] moved AbstractInliningPolicy to inlining.policy ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/inlining/InliningPhase.java + graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/inlining/policy/AbstractInliningPolicy.java Changeset: c80794ec690b Author: Miguel Garcia Date: 2014-05-15 11:22 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/c80794ec690b [inlining] moved GreedyInliningPolicy to inlining.policy ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/inlining/InliningPhase.java + graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/inlining/policy/GreedyInliningPolicy.java Changeset: 6da6cba882f6 Author: Miguel Garcia Date: 2014-05-15 12:16 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/6da6cba882f6 [inlining] access levels in AbstractInliningPolicy back to what they were ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/inlining/InliningUtil.java ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/inlining/policy/AbstractInliningPolicy.java Changeset: 9205a047fc86 Author: Miguel Garcia Date: 2014-05-15 12:18 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/9205a047fc86 [inlining] moved InlineEverythingPolicy to inlining.policy ! graal/com.oracle.graal.hotspot.test/src/com/oracle/graal/hotspot/test/WriteBarrierAdditionTest.java ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/inlining/InliningPhase.java + graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/inlining/policy/InlineEverythingPolicy.java Changeset: 9e5730b9cbe5 Author: Miguel Garcia Date: 2014-05-15 13:46 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/9e5730b9cbe5 [inlinin] assertion-aided code understanding at work ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/inlining/InliningPhase.java Changeset: ac62e3a72e02 Author: Miguel Garcia Date: 2014-05-15 14:32 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/ac62e3a72e02 [inlining] preparing to extract loop body from InliningPhase.run to InliningData ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/inlining/InliningPhase.java Changeset: 7ce628bae4a5 Author: Miguel Garcia Date: 2014-05-15 14:43 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/7ce628bae4a5 [inlining] part 2, preparing to move tryToInline() and doInline() ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/inlining/InliningPhase.java Changeset: 1b5ea45f0b87 Author: Miguel Garcia Date: 2014-05-15 14:48 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/1b5ea45f0b87 [inlining] moved doInline() to InliningData, as prereq for upcoming steps ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/inlining/InliningPhase.java Changeset: d8a79b70778c Author: Miguel Garcia Date: 2014-05-15 14:51 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/d8a79b70778c [inlining] moved tryToInline() to InliningData, as prereq for upcoming steps ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/inlining/InliningPhase.java Changeset: 33d9741ccfe3 Author: Miguel Garcia Date: 2014-05-15 14:53 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/33d9741ccfe3 [inlining] extracted loop-body, for now as InliningPhase.moveForward() ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/inlining/InliningPhase.java Changeset: 1efd95f6e1ba Author: Miguel Garcia Date: 2014-05-15 15:01 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/1efd95f6e1ba [inlining] readability improvements for (by now extracted) loop-body ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/inlining/InliningPhase.java Changeset: 0d0ce3c657df Author: Miguel Garcia Date: 2014-05-15 15:07 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/0d0ce3c657df [inlining] side-effects moved out from just-extracted method ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/inlining/InliningPhase.java Changeset: 6bc784b8e66b Author: Miguel Garcia Date: 2014-05-15 15:17 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/6bc784b8e66b [inlining] working the InliningData stack now done by InliningData.moveForward() ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/inlining/InliningPhase.java Changeset: dde1b26804c2 Author: Miguel Garcia Date: 2014-05-15 15:35 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/dde1b26804c2 [inlining] start of another refactoring trail ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/inlining/CallsiteHolder.java - graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/inlining/InliningIterator.java + graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/inlining/walker/InliningIterator.java Changeset: d5270e276765 Author: Miguel Garcia Date: 2014-05-15 15:37 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/d5270e276765 [inlining] grouping inlining-space walking-related classes in package walker - graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/inlining/CallsiteHolder.java ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/inlining/InliningPhase.java + graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/inlining/walker/CallsiteHolder.java Changeset: 947f62e98c07 Author: Miguel Garcia Date: 2014-05-15 15:41 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/947f62e98c07 [inlining] moved helper class MethodInvocation to package inlining.walker ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/inlining/InliningPhase.java + graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/inlining/walker/MethodInvocation.java Changeset: 26cedd987c83 Author: Miguel Garcia Date: 2014-05-15 15:45 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/26cedd987c83 [inlining] moved class InliningData to package with related classes ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/inlining/DepthSearchUtil.java ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/inlining/InliningPhase.java ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/inlining/InliningUtil.java + graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/inlining/walker/InliningData.java Changeset: ce1444862ec2 Author: Miguel Garcia Date: 2014-05-15 16:12 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/ce1444862ec2 [inlining] moved ComputeInliningRelevance closer to its single user - graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/inlining/ComputeInliningRelevance.java ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/inlining/walker/CallsiteHolder.java + graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/inlining/walker/ComputeInliningRelevance.java Changeset: 8af4f23b3847 Author: Miguel Garcia Date: 2014-05-15 16:17 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/8af4f23b3847 [inlining] moved DepthSearchUtil closer to its single user - graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/inlining/DepthSearchUtil.java + graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/inlining/walker/DepthSearchUtil.java ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/inlining/walker/InliningData.java Changeset: 54011d1d1ae3 Author: Miguel Garcia Date: 2014-05-15 17:25 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/54011d1d1ae3 Merge Changeset: d3c33144cab5 Author: Gilles Duboscq Date: 2014-05-15 18:13 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/d3c33144cab5 make TypeProfileWidth pd ! src/share/vm/runtime/globals.hpp Changeset: 6a13c422fca4 Author: Roland Schatz Date: 2014-05-15 19:03 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/6a13c422fca4 API for high word multiplication. ! graal/com.oracle.graal.asm.amd64/src/com/oracle/graal/asm/amd64/AMD64Assembler.java ! graal/com.oracle.graal.compiler.amd64/src/com/oracle/graal/compiler/amd64/AMD64LIRGenerator.java ! graal/com.oracle.graal.compiler.hsail/src/com/oracle/graal/compiler/hsail/HSAILLIRGenerator.java ! graal/com.oracle.graal.compiler.ptx/src/com/oracle/graal/compiler/ptx/PTXLIRGenerator.java ! graal/com.oracle.graal.compiler.sparc/src/com/oracle/graal/compiler/sparc/SPARCLIRGenerator.java ! graal/com.oracle.graal.lir.amd64/src/com/oracle/graal/lir/amd64/AMD64Arithmetic.java ! graal/com.oracle.graal.lir/src/com/oracle/graal/lir/gen/ArithmeticLIRGenerator.java ! graal/com.oracle.graal.truffle.test/src/com/oracle/graal/truffle/test/ExactMathTest.java + graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/nodes/arithmetic/IntegerMulHighNode.java + graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/nodes/arithmetic/UnsignedMulHighNode.java ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/substitutions/ExactMathSubstitutions.java ! graal/com.oracle.truffle.api/src/com/oracle/truffle/api/ExactMath.java Changeset: 5ec52f033e58 Author: Bernhard Urban Date: 2014-05-15 22:25 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/5ec52f033e58 mxtool: minor fix of optional field usage ! mxtool/mx.py Changeset: 807090ddbbf2 Author: Doug Simon Date: 2014-05-15 22:42 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/807090ddbbf2 use JDK with highest compliance level for generated Eclipse attach launcher ! mxtool/mx.py Changeset: 7b999df1dabc Author: Doug Simon Date: 2014-05-15 22:43 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/7b999df1dabc ensure Graal C++ shutdown routines are called exactly once during VM shutdown ! src/share/vm/runtime/java.cpp Changeset: 128359d7cddc Author: Doug Simon Date: 2014-05-15 22:46 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/128359d7cddc once the Graal compilation queue has been shutdown, don't process any pending compilations and be more defensive about preventing future compilations to be queued ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/CompilationTask.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/CompileTheWorld.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/bridge/VMToCompilerImpl.java Changeset: 5f1373b3527d Author: Doug Simon Date: 2014-05-15 22:47 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/5f1373b3527d make CompilationTask.threadMXBean static ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/CompilationTask.java Changeset: e563b7668db5 Author: Doug Simon Date: 2014-05-15 23:12 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/e563b7668db5 Merge. ! mxtool/mx.py From doug.simon at oracle.com Fri May 16 09:27:42 2014 From: doug.simon at oracle.com (Doug Simon) Date: Fri, 16 May 2014 11:27:42 +0200 Subject: nodeIntrinsic to load an hsail kernarg In-Reply-To: References: Message-ID: <69EE2E6F-78B2-4B30-8978-CC951F265382@oracle.com> On May 15, 2014, at 11:11 PM, Deneau, Tom wrote: > I would like to create special HSAILNode with a @NodeIntrinsic which would end up generating HSAIL code to load from a named kernarg. So for instance if the kernel prologue had > align 8 kernarg_f64 %_foo, > > I could write snippet code something like > double someVar = HSAILKernArgNode.loadDouble("%_foo?); This should work as long as the above call is in a @Snippet annotated method. Is that the case? If so, you need to find out why NodeIntrinsificationPhase is not being called for the snippet. -Doug From christian.thalinger at oracle.com Fri May 16 16:54:28 2014 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Fri, 16 May 2014 09:54:28 -0700 Subject: small webrev to enable some hsail virtual call inlining In-Reply-To: References: Message-ID: + if ((key.getKind() == Kind.Int) || (key.getKind() == Kind.Long) || (key.getKind() == Kind.Object)) { Maybe you should make this a switch now and the comment and exception message is not correct anymore: // Throw an exception if the keys aren't ints. throw GraalInternalError.unimplemented("Switch statements are only supported for keys of type int or long, not " + key.getKind()); On May 15, 2014, at 3:36 PM, Deneau, Tom wrote: > I submitted a small webrev that enables some hsail virtual call inlining in a few junit tests... > > http://cr.openjdk.java.net/~tdeneau/graal-webrevs/webrev-hsail-virtual-inlining/webrev/ > > Changes > > * tests that want to inline multiple target calls need to have enough profile information so the graal Hsail backend knows which targets to inline. Increased the kernel range to accomplish this. > > * The StrategySwitch implementation didn't handle switches of type Object. > > * The basic VirtualCallTest had two targets. I added variations that had 3 and 4 targets. These can only be run successfully with -XX:TypeProfileWidth being set to 3 or 4. However they check TypeProfileWidth and just don't run if is not enough, so they do not fail under the default hotspot configuration (TypeProfileWidth = 2). > > Note: I had hoped to enable passing of some other tests had virtual targets, for instance HashMapGetTest. However HSAIL still requires complete inlining and the complete inlining of HashMap.Get fails because of maximum recursive depth being exceeded. I believe this is on the TreeNode part of HashMap support, Treenode.find(). Maybe it is possible to do a substitution that does not use recursion. > > I've noticed recursion hitting us in a few other places as well, some of which I would not expect for instance Float.toString() which ends up trying to inline FDBigInteger.big5powRec > > -- Tom > From doug.simon at oracle.com Sat May 17 01:00:06 2014 From: doug.simon at oracle.com (doug.simon at oracle.com) Date: Sat, 17 May 2014 01:00:06 +0000 Subject: hg: graal/graal: 24 new changesets Message-ID: <201405170100.s4H10biv007191@aojmv0008> Changeset: eaeba148bb15 Author: Tom Rodriguez Date: 2014-05-15 20:11 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/eaeba148bb15 more aggressively fold implicit nulls into memory operations ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/extended/NullCheckNode.java ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/UseTrappingNullChecksPhase.java Changeset: 423bf61c9c32 Author: Tom Rodriguez Date: 2014-05-16 00:12 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/423bf61c9c32 use inner classes instead of reflection during matching ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/match/MatchGenerator.java ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/match/MatchProcessor.java ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/match/MatchStatement.java Changeset: 98423229008c Author: Tom Rodriguez Date: 2014-05-16 00:12 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/98423229008c allow overriding the NodeClass lookup when building MatchStatements ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/match/MatchPattern.java ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/match/MatchProcessor.java ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/match/MatchRuleRegistry.java ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/match/MatchStatementSet.java Changeset: 16059f6f5661 Author: Doug Simon Date: 2014-05-16 12:06 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/16059f6f5661 mx: drain *all* output from subprocess if redirecting to functions ! mxtool/mx.py Changeset: c66c28e1f866 Author: Doug Simon Date: 2014-05-16 12:23 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/c66c28e1f866 minor spelling and modifier fix ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/CompilationTask.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/bridge/VMToCompilerImpl.java Changeset: bd9be86ce634 Author: Lukas Stadler Date: 2014-05-16 14:01 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/bd9be86ce634 do not reprofile upon exceptions thrown in NewArrayStub or NewInstanceStub ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/stubs/StubUtil.java Changeset: c5ff0e1e53cf Author: Miguel Garcia Date: 2014-05-16 11:59 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/c5ff0e1e53cf [inlining] fixing input as instance final rather than passing it over and over ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/inlining/InliningPhase.java ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/inlining/walker/InliningData.java Changeset: 619b194bb2a3 Author: Miguel Garcia Date: 2014-05-16 12:03 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/619b194bb2a3 [inlining] consumer becomes initializer of the probabilities map ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/inlining/InliningPhase.java ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/inlining/walker/InliningData.java Changeset: 8e2ed3a0812a Author: Miguel Garcia Date: 2014-05-16 13:39 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/8e2ed3a0812a [inlining] typos in source comment ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/inlining/InliningPhase.java Changeset: eee32e28151a Author: Miguel Garcia Date: 2014-05-16 14:44 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/eee32e28151a [inlining] reduced verbosity in checkTargetConditions() ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/inlining/InliningUtil.java Changeset: e5876a0f2453 Author: Miguel Garcia Date: 2014-05-16 14:20 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/e5876a0f2453 [inlining] replaced method body with call to code duplicate ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/inlining/InliningUtil.java Changeset: b67a0a440ecb Author: Miguel Garcia Date: 2014-05-16 14:47 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/b67a0a440ecb [inlining] one less logging method to worry about ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/inlining/InliningUtil.java Changeset: 8344485d71bd Author: Miguel Garcia Date: 2014-05-16 14:57 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/8344485d71bd [inlining] pulling side-effects (logging) out of method that evals a condition ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/inlining/InliningUtil.java Changeset: 1e3be4d992f3 Author: Miguel Garcia Date: 2014-05-16 15:14 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/1e3be4d992f3 [inlining] tradeoff: "return null" still shorter than "return ...AndReturnNull" ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/inlining/InliningUtil.java Changeset: 1d26d24a572e Author: Miguel Garcia Date: 2014-05-16 15:24 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/1d26d24a572e [inlining] "return null" favored again over "return ...AndReturnNull" ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/inlining/InliningUtil.java Changeset: b68907673c8e Author: Miguel Garcia Date: 2014-05-16 15:28 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/b68907673c8e [inlining] shorter and equally informative, logNotInlined vs logNotInlinedMethod ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/inlining/InliningUtil.java Changeset: da81af70a3ef Author: Miguel Garcia Date: 2014-05-16 15:30 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/da81af70a3ef [inlining] another case of logNotInlined vs logNotInlinedMethod ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/inlining/InliningUtil.java Changeset: bf6db624bf62 Author: Miguel Garcia Date: 2014-05-16 15:46 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/bf6db624bf62 [inlining] no need for the suspense about return value ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/inlining/InliningUtil.java ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/inlining/policy/GreedyInliningPolicy.java Changeset: 9e697dbc28a7 Author: Miguel Garcia Date: 2014-05-16 15:54 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/9e697dbc28a7 [inlining] redux, no need for the suspense about return value ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/inlining/InliningUtil.java ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/inlining/policy/GreedyInliningPolicy.java Changeset: 13fa2732a8bd Author: Miguel Garcia Date: 2014-05-16 16:00 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/13fa2732a8bd [inlining] readability by means of import static ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/inlining/policy/GreedyInliningPolicy.java Changeset: 7af25e98aa36 Author: Miguel Garcia Date: 2014-05-16 16:02 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/7af25e98aa36 [inlining] untangling concerns, micro-step by micro-step ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/inlining/InliningUtil.java Changeset: a508335e5ee8 Author: Miguel Garcia Date: 2014-05-16 16:29 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/a508335e5ee8 [inlining] no need for guessing a return value that doesn't matter ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/inlining/InliningUtil.java Changeset: 0b363d4ceb84 Author: Miguel Garcia Date: 2014-05-16 16:36 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/0b363d4ceb84 [inlining] behavior becomes less argument-dependent, arguments become redundant ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/inlining/InliningUtil.java ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/inlining/policy/GreedyInliningPolicy.java Changeset: 1e3f19292a32 Author: Miguel Garcia Date: 2014-05-16 19:59 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/1e3f19292a32 [inlining] reverting refactoring trail until spoiling commit(s) are discovered ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/inlining/InliningPhase.java ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/inlining/InliningUtil.java ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/inlining/policy/GreedyInliningPolicy.java ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/inlining/walker/InliningData.java From duboscq at ssw.jku.at Sat May 17 16:38:03 2014 From: duboscq at ssw.jku.at (Gilles Duboscq) Date: Sat, 17 May 2014 18:38:03 +0200 Subject: Problem in Graal instalation In-Reply-To: <6344FEC9-73BB-455C-BDE8-17BD365AC3A7@gmail.com> References: <928A9622-B236-4666-872B-105F7057723D@gmail.com> <6344FEC9-73BB-455C-BDE8-17BD365AC3A7@gmail.com> Message-ID: Hi, Ok, In Eclipse (in "Installed JREs") you need to have both Java 7 and Java 8 configured. Also you will need an Eclipse version that supports Java 8: either Eclipse 4.3.2 (Kepler SR2) with the Java 8 extension [1] or Eclipse 4.4 (Luna) M7 [2]. -Gilles [1] http://www.eclipse.org/downloads/java8/ [2] http://eclipse.org/downloads/index-developer.php On Sat, May 17, 2014 at 4:59 PM, macbook wrote: > Hello dear Gilles, > Thank you for your response. Unfortunately, it is not working. I have done > all your instructions but it seams a jdk problem. > I have 1.7 java version > hp at ubuntu:~$ java -version > java version "1.7.0_51" > Java(TM) SE Runtime Environment (build 1.7.0_51-b13) > Java HotSpot(TM) 64-Bit Server VM (build 24.51-b03, mixed mode) > And in the project the error come from the annotation > @SupressWorning("sync-override") > Please take a look into the attached images captures. > Best regards > > Le 17 mai 2014 ? 11:58, Gilles Duboscq a ?crit : > > Hello Said, > > Could it be that some of the projects where not imported? > It looks like a lot of projects have errors. > While eclipse is closed, you can try to clean using "mx ideclean" then > rebuild the project files with "mx ideinit" then reopen eclipse and make > sure all projects are imported. > If you still have errors, you can try to clean in eclipse by using > Project->Clean... and cleaning all projects. > > -Gilles > > > On Fri, May 16, 2014 at 4:31 PM, macbook wrote: > >> Hello dear Gilles, >> I'm sorry to send you an email every time when I have problem. >> Now I'm starting with Graal Simple language. I'm following the tutorial, >> but after building the project (mx ideinit), I have a problem when I call >> this package : com.oracle.truffle.api >> Please find attached a picture with can show you the problem. >> Thank you very much for your help. >> Best regards >> >> Le 12 mai 2014 ? 10:42, Gilles Duboscq a ?crit : >> >> Hello Said, >> >> The Java version you are specifying as JAVA_HOME seems to be 1.7. It >> has to be 1.8. >> You can set JAVA_HOME in the mx/env file. >> For example: >> >> JAVA_HOME=/usr/java/jdk1.8.0 >> EXTRA_JAVA_HOMES=/usr/java/jdk1.7.0_51 >> >> You need to adapt those path to the correct location for your machine. >> >> >> We currently accept 1.7 as the main java version but, as you >> experienced, this is confusing. I think we should specify 1.8 as the >> minimum supported version. >> >> -Gilles >> >> >> On Mon, May 12, 2014 at 12:47 AM, macbook wrote: >> >> Hello, >> I'm a Tunisian student, I'm studying the Grall and Truffle projects. >> Since 3 days I'm trying to install Grall on Ubuntu os, but It fail after >> building (mx build : seen here >> https://wiki.openjdk.java.net/display/Graal/Instructions) >> The problem is seen when I installing the graal VM : >> >> >> Excluding com.oracle.graal.api.meta (JDK with compliance level 1.8 not >> available) >> Excluding com.oracle.graal.replacements.test (JDK with compliance level >> 1.8 not available) >> hp at ubuntu:~/Bureau$ mx vm >> Error occurred during initialization of VM >> Unable to load native library: >> /home/hp/Bureau/graal/jdk1.7.0_51/product/jre/lib/amd64/libjava.so: symbol >> JVM_SetProtectionDomain, version SUNWprivate_1.1 not defined in file >> libjvm.so with link time reference >> >> >> I tried also to install it on OS X, but if fail also. >> I installed 5 version of oracle jdk 7, and jdk 8. >> Can you help me please to resolve this problem. >> Best regards >> Said >> >> >> > > From doug.simon at oracle.com Sun May 18 01:00:06 2014 From: doug.simon at oracle.com (doug.simon at oracle.com) Date: Sun, 18 May 2014 01:00:06 +0000 Subject: hg: graal/graal: 12 new changesets Message-ID: <201405180100.s4I10Pa9003630@aojmv0008> Changeset: c583759bbcfd Author: Gilles Duboscq Date: 2014-04-18 13:50 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/c583759bbcfd ResolvedJavaType.resolveMethod now takes a callerType that is used to check access rules. Make it work for default methods. + graal/com.oracle.graal.api.meta.test/src/com/oracle/graal/api/meta/test/ResolvedJavaTypeResolveMethodTest.java ! graal/com.oracle.graal.api.meta.test/src/com/oracle/graal/api/meta/test/TestResolvedJavaType.java ! graal/com.oracle.graal.api.meta/src/com/oracle/graal/api/meta/ResolvedJavaType.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/bridge/CompilerToVM.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/bridge/CompilerToVMImpl.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotResolvedJavaMethod.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotResolvedObjectType.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotResolvedPrimitiveType.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/java/MethodCallTargetNode.java ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/ConditionalEliminationPhase.java ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/cfs/FlowSensitiveReduction.java ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/inlining/InliningUtil.java ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/inlining/info/MultiTypeGuardInlineInfo.java ! graal/com.oracle.graal.word/src/com/oracle/graal/word/phases/WordTypeRewriterPhase.java ! graal/com.oracle.graal.word/src/com/oracle/graal/word/phases/WordTypeVerificationPhase.java ! src/share/vm/graal/graalCompilerToVM.cpp ! src/share/vm/interpreter/linkResolver.hpp Changeset: 50306276af41 Author: Gilles Duboscq Date: 2014-05-16 18:08 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/50306276af41 Remove unused import ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/stubs/StubUtil.java Changeset: a9f969e65b61 Author: Gilles Duboscq Date: 2014-05-17 11:41 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/a9f969e65b61 Use non-bold/bright colors in AnsiTerminalDecorator ! graal/com.oracle.graal.test/src/com/oracle/graal/test/AnsiTerminalDecorator.java Changeset: ef6b8d1898e6 Author: Gilles Duboscq Date: 2014-05-17 14:57 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/ef6b8d1898e6 Add resolved receiver type to ResolvedJavaMethod.isInVirtualMethodTable in order to be able to do vtable-calls for miranda and default methods ! graal/com.oracle.graal.api.meta/src/com/oracle/graal/api/meta/ResolvedJavaMethod.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/HotSpotVMConfig.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/bridge/CompilerToVM.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/bridge/CompilerToVMImpl.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/DefaultHotSpotLoweringProvider.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotResolvedJavaMethod.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotResolvedObjectType.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/Invoke.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/extended/LoadMethodNode.java ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/inlining/info/MultiTypeGuardInlineInfo.java ! src/share/vm/graal/graalCompilerToVM.cpp Changeset: 668d158f780c Author: Gilles Duboscq Date: 2014-05-17 12:45 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/668d158f780c Rename HotSpotResolvedObjectType.metaspaceKlass to getMetaspaceKlass ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotResolvedJavaMethod.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotResolvedObjectType.java ! src/share/vm/graal/graalCompilerToVM.cpp ! src/share/vm/graal/vmStructs_graal.hpp Changeset: fa66540676ce Author: Gilles Duboscq Date: 2014-05-17 15:05 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/fa66540676ce Try to devirtualize using unique concrete method and subtype in MethodCallTargetNode.canonical ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/java/MethodCallTargetNode.java Changeset: 22f56c3eadb7 Author: Gilles Duboscq Date: 2014-05-17 14:56 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/22f56c3eadb7 CodeInstalled not need to assert_leaf_type when asserting abstract_with_unique_concrete_subtype ! src/share/vm/graal/graalCodeInstaller.cpp Changeset: 59a85df7a418 Author: Gilles Duboscq Date: 2014-05-17 14:58 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/59a85df7a418 Add some assertions and tests to TestResolvedJavaType.findUniqueConcreteSubtypeTest ! graal/com.oracle.graal.api.code/src/com/oracle/graal/api/code/Assumptions.java ! graal/com.oracle.graal.api.meta.test/src/com/oracle/graal/api/meta/test/TestResolvedJavaType.java Changeset: 920b7bb058a6 Author: Gilles Duboscq Date: 2014-05-17 16:29 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/920b7bb058a6 Simplify HotSpotUnresolvedJavaType, harmonize toString for HotSpotUnresolvedJavaType and HotSpotResolvedObjectType ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotConstantPool.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotResolvedObjectType.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotUnresolvedJavaType.java Changeset: 7260016882ef Author: Gilles Duboscq Date: 2014-05-17 17:04 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/7260016882ef fix assert in HotSpotResolvedJavaMethod.vtableEntryOffset ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotResolvedJavaMethod.java Changeset: 08f131535f9a Author: Gilles Duboscq Date: 2014-05-17 18:08 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/08f131535f9a Add slow-path for SLMulNode.mul(BigInteger) because BigInteger.multiply is recursive. ! graal/com.oracle.truffle.sl/src/com/oracle/truffle/sl/nodes/expression/SLMulNode.java Changeset: ca19a71c8566 Author: Gilles Duboscq Date: 2014-05-17 18:42 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/ca19a71c8566 In MethodCallTargetNode.canonicalize, uniqueConcreteType.resolveMethod can return null in some cases ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/java/MethodCallTargetNode.java From doug.simon at oracle.com Mon May 19 01:00:06 2014 From: doug.simon at oracle.com (doug.simon at oracle.com) Date: Mon, 19 May 2014 01:00:06 +0000 Subject: hg: graal/graal: 7 new changesets Message-ID: <201405190100.s4J10FD1029032@aojmv0008> Changeset: bc37e2efc0c2 Author: Miguel Garcia Date: 2014-05-18 14:05 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/bc37e2efc0c2 [inlining-2] fixing input as instance final rather than passing it over and over ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/inlining/InliningPhase.java ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/inlining/walker/InliningData.java Changeset: 6ea206e07d55 Author: Miguel Garcia Date: 2014-05-18 14:08 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/6ea206e07d55 [inlining-2] consumer becomes initializer of the probabilities map ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/inlining/InliningPhase.java ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/inlining/walker/InliningData.java Changeset: 3464575dbe2b Author: Miguel Garcia Date: 2014-05-18 14:15 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/3464575dbe2b [inlining-2] typos in source comment ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/inlining/InliningPhase.java Changeset: 291f0e9875c4 Author: Miguel Garcia Date: 2014-05-18 14:17 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/291f0e9875c4 [inlining-2] reduced verbosity in checkTargetConditions() ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/inlining/InliningUtil.java Changeset: c204f1ba66b9 Author: Miguel Garcia Date: 2014-05-18 14:34 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/c204f1ba66b9 [inlining-2] replaced method body with call to code duplicate ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/inlining/InliningUtil.java Changeset: 587fc571d043 Author: Miguel Garcia Date: 2014-05-18 14:37 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/587fc571d043 [inlining-2] one less logging method to worry about ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/inlining/InliningUtil.java Changeset: acfcb5ace52f Author: Miguel Garcia Date: 2014-05-18 14:39 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/acfcb5ace52f [inlining-2] pulling side-effects (logging) out of method that evals a condition ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/inlining/InliningUtil.java From tom.deneau at amd.com Mon May 19 12:33:58 2014 From: tom.deneau at amd.com (Deneau, Tom) Date: Mon, 19 May 2014 12:33:58 +0000 Subject: small webrev to enable some hsail virtual call inlining In-Reply-To: References: Message-ID: OK a second version of the webrev, the section in HSAILLIRGenerator.java mentioned below has been cleaned up as well as correcting some comments related to switches in HSAILControlFlow.java http://cr.openjdk.java.net/~tdeneau/graal-webrevs/webrev-hsail-virtual-inlining-v2/webrev/ -- Tom From: Christian Thalinger [mailto:christian.thalinger at oracle.com] Sent: Friday, May 16, 2014 11:54 AM To: Deneau, Tom Cc: graal-dev at openjdk.java.net Subject: Re: small webrev to enable some hsail virtual call inlining + if ((key.getKind() == Kind.Int) || (key.getKind() == Kind.Long) || (key.getKind() == Kind.Object)) { Maybe you should make this a switch now and the comment and exception message is not correct anymore: // Throw an exception if the keys aren't ints. throw GraalInternalError.unimplemented("Switch statements are only supported for keys of type int or long, not " + key.getKind()); On May 15, 2014, at 3:36 PM, Deneau, Tom > wrote: I submitted a small webrev that enables some hsail virtual call inlining in a few junit tests... http://cr.openjdk.java.net/~tdeneau/graal-webrevs/webrev-hsail-virtual-inlining/webrev/ Changes * tests that want to inline multiple target calls need to have enough profile information so the graal Hsail backend knows which targets to inline. Increased the kernel range to accomplish this. * The StrategySwitch implementation didn't handle switches of type Object. * The basic VirtualCallTest had two targets. I added variations that had 3 and 4 targets. These can only be run successfully with -XX:TypeProfileWidth being set to 3 or 4. However they check TypeProfileWidth and just don't run if is not enough, so they do not fail under the default hotspot configuration (TypeProfileWidth = 2). Note: I had hoped to enable passing of some other tests had virtual targets, for instance HashMapGetTest. However HSAIL still requires complete inlining and the complete inlining of HashMap.Get fails because of maximum recursive depth being exceeded. I believe this is on the TreeNode part of HashMap support, Treenode.find(). Maybe it is possible to do a substitution that does not use recursion. I've noticed recursion hitting us in a few other places as well, some of which I would not expect for instance Float.toString() which ends up trying to inline FDBigInteger.big5powRec -- Tom From christian.thalinger at oracle.com Mon May 19 14:35:45 2014 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Mon, 19 May 2014 07:35:45 -0700 Subject: small webrev to enable some hsail virtual call inlining In-Reply-To: References: Message-ID: Better. Thanks. On May 19, 2014, at 5:33 AM, Deneau, Tom wrote: > OK a second version of the webrev, the section in HSAILLIRGenerator.java mentioned below has been cleaned up as well as correcting some comments related to switches in HSAILControlFlow.java > > http://cr.openjdk.java.net/~tdeneau/graal-webrevs/webrev-hsail-virtual-inlining-v2/webrev/ > > -- Tom > > > > From: Christian Thalinger [mailto:christian.thalinger at oracle.com] > Sent: Friday, May 16, 2014 11:54 AM > To: Deneau, Tom > Cc: graal-dev at openjdk.java.net > Subject: Re: small webrev to enable some hsail virtual call inlining > > + if ((key.getKind() == Kind.Int) || (key.getKind() == Kind.Long) || (key.getKind() == Kind.Object)) { > Maybe you should make this a switch now and the comment and exception message is not correct anymore: > // Throw an exception if the keys aren't ints. > throw GraalInternalError.unimplemented("Switch statements are only supported for keys of type int or long, not " + key.getKind()); > > On May 15, 2014, at 3:36 PM, Deneau, Tom wrote: > > > I submitted a small webrev that enables some hsail virtual call inlining in a few junit tests... > > http://cr.openjdk.java.net/~tdeneau/graal-webrevs/webrev-hsail-virtual-inlining/webrev/ > > Changes > > * tests that want to inline multiple target calls need to have enough profile information so the graal Hsail backend knows which targets to inline. Increased the kernel range to accomplish this. > > * The StrategySwitch implementation didn't handle switches of type Object. > > * The basic VirtualCallTest had two targets. I added variations that had 3 and 4 targets. These can only be run successfully with -XX:TypeProfileWidth being set to 3 or 4. However they check TypeProfileWidth and just don't run if is not enough, so they do not fail under the default hotspot configuration (TypeProfileWidth = 2). > > Note: I had hoped to enable passing of some other tests had virtual targets, for instance HashMapGetTest. However HSAIL still requires complete inlining and the complete inlining of HashMap.Get fails because of maximum recursive depth being exceeded. I believe this is on the TreeNode part of HashMap support, Treenode.find(). Maybe it is possible to do a substitution that does not use recursion. > > I've noticed recursion hitting us in a few other places as well, some of which I would not expect for instance Float.toString() which ends up trying to inline FDBigInteger.big5powRec > > -- Tom > From christian.wimmer at oracle.com Mon May 19 18:11:02 2014 From: christian.wimmer at oracle.com (Christian Wimmer) Date: Mon, 19 May 2014 11:11:02 -0700 Subject: Build server out of disk space Message-ID: <537A4936.9010905@oracle.com> https://lafo.ssw.uni-linz.ac.at/buildbot/builders/gate-enterprise-truffle-pending/builds/1409/steps/mxgate/logs/stdio -Christian From christian.thalinger at oracle.com Mon May 19 18:39:37 2014 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Mon, 19 May 2014 11:39:37 -0700 Subject: small webrev to enable some hsail virtual call inlining In-Reply-To: References: Message-ID: Pushed. On May 19, 2014, at 7:35 AM, Christian Thalinger wrote: > Better. Thanks. > > On May 19, 2014, at 5:33 AM, Deneau, Tom wrote: > >> OK a second version of the webrev, the section in HSAILLIRGenerator.java mentioned below has been cleaned up as well as correcting some comments related to switches in HSAILControlFlow.java >> >> http://cr.openjdk.java.net/~tdeneau/graal-webrevs/webrev-hsail-virtual-inlining-v2/webrev/ >> >> -- Tom >> >> >> >> From: Christian Thalinger [mailto:christian.thalinger at oracle.com] >> Sent: Friday, May 16, 2014 11:54 AM >> To: Deneau, Tom >> Cc: graal-dev at openjdk.java.net >> Subject: Re: small webrev to enable some hsail virtual call inlining >> >> + if ((key.getKind() == Kind.Int) || (key.getKind() == Kind.Long) || (key.getKind() == Kind.Object)) { >> Maybe you should make this a switch now and the comment and exception message is not correct anymore: >> // Throw an exception if the keys aren't ints. >> throw GraalInternalError.unimplemented("Switch statements are only supported for keys of type int or long, not " + key.getKind()); >> >> On May 15, 2014, at 3:36 PM, Deneau, Tom wrote: >> >> >> I submitted a small webrev that enables some hsail virtual call inlining in a few junit tests... >> >> http://cr.openjdk.java.net/~tdeneau/graal-webrevs/webrev-hsail-virtual-inlining/webrev/ >> >> Changes >> >> * tests that want to inline multiple target calls need to have enough profile information so the graal Hsail backend knows which targets to inline. Increased the kernel range to accomplish this. >> >> * The StrategySwitch implementation didn't handle switches of type Object. >> >> * The basic VirtualCallTest had two targets. I added variations that had 3 and 4 targets. These can only be run successfully with -XX:TypeProfileWidth being set to 3 or 4. However they check TypeProfileWidth and just don't run if is not enough, so they do not fail under the default hotspot configuration (TypeProfileWidth = 2). >> >> Note: I had hoped to enable passing of some other tests had virtual targets, for instance HashMapGetTest. However HSAIL still requires complete inlining and the complete inlining of HashMap.Get fails because of maximum recursive depth being exceeded. I believe this is on the TreeNode part of HashMap support, Treenode.find(). Maybe it is possible to do a substitution that does not use recursion. >> >> I've noticed recursion hitting us in a few other places as well, some of which I would not expect for instance Float.toString() which ends up trying to inline FDBigInteger.big5powRec >> >> -- Tom >> > From doug.simon at oracle.com Mon May 19 20:28:25 2014 From: doug.simon at oracle.com (doug.simon at oracle.com) Date: Mon, 19 May 2014 20:28:25 +0000 Subject: hg: graal/graal: 37 new changesets Message-ID: <201405192029.s4JKTE2Q001347@aojmv0008> Changeset: c82a77d94067 Author: Lukas Stadler Date: 2014-05-19 10:23 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/c82a77d94067 do not assert for MergeNode in UseTrappingNullChecksPhase ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/UseTrappingNullChecksPhase.java Changeset: 928475f5c2f1 Author: Lukas Stadler Date: 2014-05-19 10:57 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/928475f5c2f1 small fix in GraphOrder.assertSchedulableGraph ! graal/com.oracle.graal.phases/src/com/oracle/graal/phases/util/GraphOrder.java Changeset: f7d839024344 Author: Miguel Garcia Date: 2014-05-18 16:08 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/f7d839024344 [inlining-2] renaming of an overloaded method ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/inlining/InliningUtil.java Changeset: 4f42ea8df6dd Author: Miguel Garcia Date: 2014-05-18 16:10 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/4f42ea8df6dd [inlining-2] make returned value explicit ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/inlining/InliningUtil.java Changeset: ff0d19700e31 Author: Miguel Garcia Date: 2014-05-18 16:14 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/ff0d19700e31 [inlining-2] renaming logNotInlinedMethodAndReturnNull -> logNotInlinedInvoke ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/inlining/InliningUtil.java Changeset: f07766efc58b Author: Miguel Garcia Date: 2014-05-18 16:20 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/f07766efc58b [inlining-2] make explicit the value returned by logNotInlinedInvoke() ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/inlining/InliningUtil.java Changeset: 2eee15fbe833 Author: Miguel Garcia Date: 2014-05-19 10:47 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/2eee15fbe833 [inlining-2] logNotInlinedMethod invoked only for side-effects not return value ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/inlining/InliningUtil.java Changeset: a09fdd69e735 Author: Miguel Garcia Date: 2014-05-19 10:52 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/a09fdd69e735 [inlining-2] logInliningDecision, for side-effects not return value (1/2) ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/inlining/InliningUtil.java Changeset: 721f7815493c Author: Miguel Garcia Date: 2014-05-19 10:54 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/721f7815493c [inlining-2] logInliningDecision, for side-effects not return value (2/2) ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/inlining/InliningUtil.java Changeset: 1e0ab8f0f2e3 Author: Miguel Garcia Date: 2014-05-19 11:24 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/1e0ab8f0f2e3 [inlining-2] no guesswork about return value of logInlinedMethod (1/2) ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/inlining/policy/GreedyInliningPolicy.java Changeset: f19a1a996a74 Author: Miguel Garcia Date: 2014-05-19 11:26 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/f19a1a996a74 [inlining-2] no guesswork about return value of logInlinedMethod (2/2) ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/inlining/InliningUtil.java Changeset: 131be7997721 Author: Miguel Garcia Date: 2014-05-19 11:29 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/131be7997721 [inlining-2] no guesswork at callsites about return value of logNotInlinedMethod ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/inlining/InliningUtil.java ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/inlining/policy/GreedyInliningPolicy.java Changeset: 4f32154c34ff Author: Miguel Garcia Date: 2014-05-19 11:59 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/4f32154c34ff Merge Changeset: 45285c8eccbd Author: Gilles Duboscq Date: 2014-05-19 11:19 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/45285c8eccbd Never use the current node's stamp in ValueNode.inferStamp overrides. Removed unused PhiNode.inferPhiStamp ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/GuardedValueNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/GuardingPiNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/PiNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/ValuePhiNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/java/CheckCastNode.java ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/cfs/State.java Changeset: 05826e450e3e Author: Lukas Stadler Date: 2014-05-19 13:58 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/05826e450e3e fix NPE in CallSiteHolder ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/inlining/walker/CallsiteHolder.java Changeset: 10830a8ab30d Author: Gilles Duboscq Date: 2014-05-19 15:30 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/10830a8ab30d ConditionalNode's boolean materialization canonicalization needs to insert a convert ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/calc/ConditionalNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/calc/IntegerConvertNode.java Changeset: ce5b2557396a Author: Miguel Garcia Date: 2014-05-19 14:51 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/ce5b2557396a [inlining-3] readability of checkInvokeConditions() part 1 of 2 ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/inlining/InliningUtil.java Changeset: c4f012d2b58b Author: Miguel Garcia Date: 2014-05-19 14:57 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/c4f012d2b58b [inlining-3] readability of checkInvokeConditions() part 2 of 2 ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/inlining/InliningUtil.java Changeset: fbeb421666cd Author: Miguel Garcia Date: 2014-05-19 15:28 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/fbeb421666cd [inlining-4] start of refactoring trail, by the end shorter parameter lists ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/inlining/InliningUtil.java ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/inlining/walker/InliningData.java Changeset: 559532aa3490 Author: Miguel Garcia Date: 2014-05-19 15:30 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/559532aa3490 [inlining-4] getAssumptionInlineInfo() becomes instance method of InliningData ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/inlining/InliningUtil.java ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/inlining/walker/InliningData.java Changeset: 00dd189ff7be Author: Miguel Garcia Date: 2014-05-19 15:39 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/00dd189ff7be [inlining-4] getTypeCheckedInlineInfo() becomes instance method of InliningData ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/inlining/InliningUtil.java ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/inlining/walker/InliningData.java Changeset: a63d94e780ca Author: Miguel Garcia Date: 2014-05-19 15:58 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/a63d94e780ca [inlining-4] getTypeInlineInfo() becomes instance method of InliningData ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/inlining/InliningUtil.java ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/inlining/walker/InliningData.java Changeset: 39ac86d1e2d2 Author: Miguel Garcia Date: 2014-05-19 16:05 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/39ac86d1e2d2 [inlining-4] the method param that aliased maxMethodPerInlining goes away ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/inlining/walker/InliningData.java Changeset: 1d12d358aa6d Author: Miguel Garcia Date: 2014-05-19 16:08 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/1d12d358aa6d [inlining-4] parameter aliasing context.getReplacements() goes away ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/inlining/walker/InliningData.java Changeset: 5456b4d73d99 Author: Miguel Garcia Date: 2014-05-19 16:10 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/5456b4d73d99 [inlining-4] parameter aliasing context.getOptimisticOptimizations() goes away ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/inlining/walker/InliningData.java Changeset: d4a78b357778 Author: Miguel Garcia Date: 2014-05-19 16:14 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/d4a78b357778 [inlining-4] no need to pass context.getReplacements() to getExactInlineInfo() ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/inlining/walker/InliningData.java Changeset: 7bce8202e5d0 Author: Miguel Garcia Date: 2014-05-19 16:17 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/7bce8202e5d0 [inlining-4] getAssumptionInlineInfo() can get context.getReplacements() itself ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/inlining/walker/InliningData.java Changeset: fb18f8eff376 Author: Miguel Garcia Date: 2014-05-19 16:24 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/fb18f8eff376 [inlining-4] getTypeCheckedInlineInfo() can get context.getReplacements() itself ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/inlining/walker/InliningData.java Changeset: b4478dcb2a04 Author: Miguel Garcia Date: 2014-05-19 16:27 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/b4478dcb2a04 [inlining-4] removed alias for InliningData.maxMethodPerInlining ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/inlining/walker/InliningData.java Changeset: f9780f141694 Author: Miguel Garcia Date: 2014-05-19 16:32 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/f9780f141694 [inlining-4] one less alias in getExactInlineInfo() ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/inlining/walker/InliningData.java Changeset: 2cbacdb145a8 Author: Miguel Garcia Date: 2014-05-19 16:34 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/2cbacdb145a8 [inlining-4] one less alias in getAssumptionInlineInfo() ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/inlining/walker/InliningData.java Changeset: 3813fb9e3e24 Author: Miguel Garcia Date: 2014-05-19 16:45 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/3813fb9e3e24 [inlining-4] one less alias in getTypeCheckedInlineInfo() ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/inlining/walker/InliningData.java Changeset: 56689688067a Author: Miguel Garcia Date: 2014-05-19 16:52 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/56689688067a [inlining-4] privatizing methods that can be made private ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/inlining/walker/InliningData.java Changeset: 402a74c6bc14 Author: Miguel Garcia Date: 2014-05-19 17:21 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/402a74c6bc14 Merge Changeset: 4293efaaab76 Author: Christian Wirth Date: 2014-05-19 18:52 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/4293efaaab76 Add description and language to the NodeInfo annotation ! graal/com.oracle.truffle.api/src/com/oracle/truffle/api/nodes/Node.java ! graal/com.oracle.truffle.api/src/com/oracle/truffle/api/nodes/NodeInfo.java ! graal/com.oracle.truffle.dsl.processor/src/com/oracle/truffle/dsl/processor/ast/CodeElement.java Changeset: 111bf82514ca Author: Christian Wirth Date: 2014-05-19 18:59 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/111bf82514ca SL: adding NodeInfo.descriptions to SL statements ! graal/com.oracle.truffle.sl/src/com/oracle/truffle/sl/nodes/SLExpressionNode.java ! graal/com.oracle.truffle.sl/src/com/oracle/truffle/sl/nodes/SLRootNode.java ! graal/com.oracle.truffle.sl/src/com/oracle/truffle/sl/nodes/SLStatementNode.java ! graal/com.oracle.truffle.sl/src/com/oracle/truffle/sl/nodes/controlflow/SLBlockNode.java ! graal/com.oracle.truffle.sl/src/com/oracle/truffle/sl/nodes/controlflow/SLBreakNode.java ! graal/com.oracle.truffle.sl/src/com/oracle/truffle/sl/nodes/controlflow/SLContinueNode.java ! graal/com.oracle.truffle.sl/src/com/oracle/truffle/sl/nodes/controlflow/SLIfNode.java ! graal/com.oracle.truffle.sl/src/com/oracle/truffle/sl/nodes/controlflow/SLReturnNode.java ! graal/com.oracle.truffle.sl/src/com/oracle/truffle/sl/nodes/controlflow/SLWhileNode.java Changeset: 1c7a75bf0456 Author: twisti Date: 2014-05-19 10:45 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/1c7a75bf0456 enable some HSAIL virtual call inlining Contributed-by: Tom Deneau ! graal/com.oracle.graal.compiler.hsail.test.infra/src/com/oracle/graal/compiler/hsail/test/infra/GraalKernelTester.java + graal/com.oracle.graal.compiler.hsail.test/src/com/oracle/graal/compiler/hsail/test/lambda/VirtualCall3Test.java + graal/com.oracle.graal.compiler.hsail.test/src/com/oracle/graal/compiler/hsail/test/lambda/VirtualCall4Test.java + graal/com.oracle.graal.compiler.hsail.test/src/com/oracle/graal/compiler/hsail/test/lambda/VirtualCallBase.java ! graal/com.oracle.graal.compiler.hsail.test/src/com/oracle/graal/compiler/hsail/test/lambda/VirtualCallTest.java ! graal/com.oracle.graal.compiler.hsail/src/com/oracle/graal/compiler/hsail/HSAILLIRGenerator.java ! graal/com.oracle.graal.lir.hsail/src/com/oracle/graal/lir/hsail/HSAILControlFlow.java From jules_gosnell at yahoo.com Mon May 19 23:12:24 2014 From: jules_gosnell at yahoo.com (Jules Gosnell) Date: Tue, 20 May 2014 00:12:24 +0100 Subject: clumatra: recent ?regression? Message-ID: <537A8FD8.5030800@yahoo.com> Guys, thought that I should let you know. my overnight builds 15/16th may for both hardware and simulated jdk-1.8/graal/okra sumatra stacks both suffered from crashed vms and have continued to do so, until I tracked down the test in question and disabled it. here are the full logs: http://ouroboros.dyndns-free.com/ci/view/clumatra/job/clumatra-hardware-acceleration/246/consoleText http://ouroboros.dyndns-free.com/ci/view/clumatra/job/clumatra-simulated-acceleration/199/consoleText if you scroll right to the bottom of each you will find that they end prematurely without a test summary - one silently, the other reports a segv: |7 |8 |9 |10 locals: |- |- |- |- |- |- |- |- |- |d9|j |- stack: |vobject:Ratio:1{numerator=Object[null],denominator=Object[null]} |vobject:Ratio:1{numerator=Object[null],denominator=Object[null]} | | | | | | | | | at clojure.lang.Numbers.divide(Numbers.java:157) [bci: 46] |0 |1 |2 locals: |- |- |- at clojure.lang.Numbers.divide(Numbers.java:3731) [bci: 8] |0 |1 |2 |3 locals: |- |- |- |- at clumatra.numbers_test$fn$reify__7461.invoke(numbers_test.clj:54) [bci: 35] |0 |1 |2 |3 |4 locals: |- |- |- |- |- stack: |d3|a |s0|i | | | > ld_kernarg_u64 $d16, [%_deoptInfo]; > ^ input(63,23): Symbol not found # # A fatal error has been detected by the Java Runtime Environment: # # SIGSEGV (0xb) at pc=0x00007fcbe29ab08d, pid=24144, tid=140515433301760 # # JRE version: OpenJDK Runtime Environment (8.0) (build 1.8.0-internal-jenkins_2014_05_16_09_06-b00) # Java VM: OpenJDK 64-Bit Server VM (25.0-b63-internal-graal-0.3 mixed mode linux-amd64 compressed oops) # Problematic frame: # C [libokra_x86_64.so+0x59508d] Java_com_amd_okra_OkraKernel_setLaunchAttributes+0x43 I can reproduce the problem with any required flags, and provide relevant src code (java) if someone is interested in looking at this. For now, I will just lose the problematic test. perhaps something has changed and I need to update my build ? thanks for all your hard work on graal, Jules From doug.simon at oracle.com Tue May 20 01:00:05 2014 From: doug.simon at oracle.com (doug.simon at oracle.com) Date: Tue, 20 May 2014 01:00:05 +0000 Subject: hg: graal/graal: convert asserts into if tests and check for phis at merge Message-ID: <201405200100.s4K107r6015098@aojmv0008> Changeset: 9ae1d2f3bda6 Author: Tom Rodriguez Date: 2014-05-19 14:14 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/9ae1d2f3bda6 convert asserts into if tests and check for phis at merge ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/UseTrappingNullChecksPhase.java From doug.simon at oracle.com Tue May 20 09:26:52 2014 From: doug.simon at oracle.com (doug.simon at oracle.com) Date: Tue, 20 May 2014 09:26:52 +0000 Subject: hg: graal/graal: 2 new changesets Message-ID: <201405200926.s4K9Qt7x029672@aojmv0008> Changeset: 8c34e2cc4add Author: Michael Van De Vanter Date: 2014-05-19 17:14 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/8c34e2cc4add Truffle/Instrumentation: significant reorganization of the instrumentation framework's implementation and connection to the runtime ExecutionContext, with some new features, including a Tag-based "trap" mechanisms. ! graal/com.oracle.truffle.api/src/com/oracle/truffle/api/ExecutionContext.java - graal/com.oracle.truffle.api/src/com/oracle/truffle/api/impl/AbstractExecutionContext.java ! graal/com.oracle.truffle.api/src/com/oracle/truffle/api/instrument/Instrument.java ! graal/com.oracle.truffle.api/src/com/oracle/truffle/api/instrument/Probe.java + graal/com.oracle.truffle.api/src/com/oracle/truffle/api/instrument/SourceCallback.java ! graal/com.oracle.truffle.api/src/com/oracle/truffle/api/instrument/impl/DefaultASTPrinter.java ! graal/com.oracle.truffle.api/src/com/oracle/truffle/api/instrument/impl/InstrumentationNode.java + graal/com.oracle.truffle.api/src/com/oracle/truffle/api/instrument/impl/ProbeManager.java - graal/com.oracle.truffle.api/src/com/oracle/truffle/api/instrument/impl/SourceCallback.java Changeset: bdf260d8e163 Author: Michael Van De Vanter Date: 2014-05-19 17:21 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/bdf260d8e163 Merge with 9ae1d2f3bda60f9d91243c883c5aa7812e2ab256 - graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/inlining/ComputeInliningRelevance.java - graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/inlining/DepthSearchUtil.java - graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/inlining/InliningIterator.java From tom.deneau at amd.com Tue May 20 13:22:16 2014 From: tom.deneau at amd.com (Deneau, Tom) Date: Tue, 20 May 2014 13:22:16 +0000 Subject: clumatra: recent ?regression? In-Reply-To: <537A8FD8.5030800@yahoo.com> References: <537A8FD8.5030800@yahoo.com> Message-ID: Jules -- I can't see the command lines you used but I believe you are using -XX:-UseHSAILDeoptimization. But it looks like HSAILSafepoints are still on which is causing the trouble (safepoints depend on deoptimization). Can you try also adding -XX:-UseHSAILSafepoints to your command line? We should correct this by automatically turning off HSAILSafepoints if HSAILDeoptimization is off. -- Tom > -----Original Message----- > From: graal-dev [mailto:graal-dev-bounces at openjdk.java.net] On Behalf Of > Jules Gosnell > Sent: Monday, May 19, 2014 6:12 PM > To: graal-dev at openjdk.java.net > Subject: clumatra: recent ?regression? > > Guys, > > thought that I should let you know. > > my overnight builds 15/16th may for both hardware and simulated jdk- > 1.8/graal/okra sumatra stacks both suffered from crashed vms and have > continued to do so, until I tracked down the test in question and > disabled it. > > here are the full logs: > > http://ouroboros.dyndns-free.com/ci/view/clumatra/job/clumatra-hardware- > acceleration/246/consoleText > http://ouroboros.dyndns-free.com/ci/view/clumatra/job/clumatra- > simulated-acceleration/199/consoleText > > if you scroll right to the bottom of each you will find that they end > prematurely without a test summary - one silently, the other reports a > segv: > > |7 |8 |9 |10 > locals: |- > |- > |- |- |- |- |- |- |- |d9|j |- > stack: > |vobject:Ratio:1{numerator=Object[null],denominator=Object[null]} > |vobject:Ratio:1{numerator=Object[null],denominator=Object[null]} | | > | | | | | | | > at clojure.lang.Numbers.divide(Numbers.java:157) [bci: 46] > |0 |1 |2 > locals: |- |- |- > at clojure.lang.Numbers.divide(Numbers.java:3731) [bci: 8] > |0 |1 |2 |3 > locals: |- |- |- |- > at clumatra.numbers_test$fn$reify__7461.invoke(numbers_test.clj:54) > [bci: 35] > |0 |1 |2 |3 |4 > locals: |- |- |- |- |- > stack: |d3|a |s0|i | | | > > > ld_kernarg_u64 $d16, [%_deoptInfo]; > > ^ > input(63,23): Symbol not found > # > # A fatal error has been detected by the Java Runtime Environment: > # > # SIGSEGV (0xb) at pc=0x00007fcbe29ab08d, pid=24144, > tid=140515433301760 # # JRE version: OpenJDK Runtime Environment (8.0) > (build > 1.8.0-internal-jenkins_2014_05_16_09_06-b00) > # Java VM: OpenJDK 64-Bit Server VM (25.0-b63-internal-graal-0.3 mixed > mode linux-amd64 compressed oops) # Problematic frame: > # C [libokra_x86_64.so+0x59508d] > Java_com_amd_okra_OkraKernel_setLaunchAttributes+0x43 > > I can reproduce the problem with any required flags, and provide > relevant src code (java) if someone is interested in looking at this. > For now, I will just lose the problematic test. > > perhaps something has changed and I need to update my build ? > > thanks for all your hard work on graal, > > > Jules > From doug.simon at oracle.com Wed May 21 01:00:07 2014 From: doug.simon at oracle.com (doug.simon at oracle.com) Date: Wed, 21 May 2014 01:00:07 +0000 Subject: hg: graal/graal: 25 new changesets Message-ID: <201405210100.s4L10w5i028577@aojmv0008> Changeset: 8b9e7f235d85 Author: Doug Simon Date: 2014-05-20 11:50 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/8b9e7f235d85 mx: fixed spurious "error while killing subprocess" messages (GRAAL-350) ! mxtool/mx.py Changeset: 6a6cb7f2db90 Author: Erik Eckstein Date: 2014-05-20 12:38 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/6a6cb7f2db90 fix wrong handling of memory anti-dependencies in scheduler ! graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/MemoryScheduleTest.java ! graal/com.oracle.graal.phases/src/com/oracle/graal/phases/schedule/SchedulePhase.java Changeset: 99662e393b52 Author: Erik Eckstein Date: 2014-05-20 12:40 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/99662e393b52 Merge Changeset: fb530b9fa474 Author: Gilles Duboscq Date: 2014-05-20 13:13 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/fb530b9fa474 ResolvedJavaType.resolveMethod: fix javadoc, add assert in native code. update changelog ! CHANGELOG.md ! graal/com.oracle.graal.api.meta/src/com/oracle/graal/api/meta/ResolvedJavaType.java ! src/share/vm/graal/graalCompilerToVM.cpp Changeset: 7a6f6a7ef886 Author: Josef Eisl Date: 2014-05-20 11:56 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/7a6f6a7ef886 Add JRE library support to mx projectgraph. ! mxtool/mx.py Changeset: d54cca247d0b Author: Doug Simon Date: 2014-05-20 15:35 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/d54cca247d0b mx: propagate failure from forked Java compilation task back up to parent (GRAAL-350) ! mxtool/mx.py Changeset: a5abeb0a3fb0 Author: Lukas Stadler Date: 2014-05-20 15:16 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/a5abeb0a3fb0 simplify getInterfaces jtt test ! graal/com.oracle.graal.jtt/src/com/oracle/graal/jtt/lang/Class_getInterfaces01.java Changeset: e84bdd23d22c Author: Lukas Stadler Date: 2014-05-20 15:16 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/e84bdd23d22c fix wrong assert in ObjectStampMeetTest ! graal/com.oracle.graal.nodes.test/src/com/oracle/graal/nodes/test/ObjectStampMeetTest.java Changeset: e44dd5a90947 Author: Lukas Stadler Date: 2014-05-20 15:17 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/e44dd5a90947 a bit of javadoc in TruffleRuntime ! graal/com.oracle.truffle.api/src/com/oracle/truffle/api/TruffleRuntime.java Changeset: c74c34976c47 Author: Lukas Stadler Date: 2014-05-20 15:28 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/c74c34976c47 @Ignore (and not expect GraalInternalError) long-running EscapingNewStringConcatTest ! graal/com.oracle.graal.compiler.hsail.test/src/com/oracle/graal/compiler/hsail/test/EscapingNewStringConcatTest.java Changeset: 308cedd2aaa2 Author: Lukas Stadler Date: 2014-05-20 16:17 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/308cedd2aaa2 better stamps for IntegerRemNode ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/calc/IntegerRemNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/type/StampTool.java Changeset: 401edc9ef521 Author: Gilles Duboscq Date: 2014-05-20 16:36 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/401edc9ef521 Update JaCoCo libs ! mx/projects Changeset: 11e11c6dba79 Author: Gilles Duboscq Date: 2014-05-20 20:32 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/11e11c6dba79 Ignore synthetic methods in TestResolvedJavaField ! graal/com.oracle.graal.api.meta.test/src/com/oracle/graal/api/meta/test/TestResolvedJavaField.java Changeset: e534a7a893aa Author: Miguel Garcia Date: 2014-05-19 21:23 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/e534a7a893aa [inlining-5] checkTargetConditions() about to lose some of its formal params ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/inlining/InliningUtil.java ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/inlining/walker/InliningData.java Changeset: 190b92ee969e Author: Miguel Garcia Date: 2014-05-19 21:26 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/190b92ee969e [inlining-5] "where does replacements come from?" answered ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/inlining/walker/InliningData.java Changeset: ab2858ab79e9 Author: Miguel Garcia Date: 2014-05-19 21:30 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/ab2858ab79e9 [inlining-5] "where does optimisticOpts come from?" answered ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/inlining/walker/InliningData.java Changeset: 8e4bedbbb6d8 Author: Miguel Garcia Date: 2014-05-19 21:39 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/8e4bedbbb6d8 [inlining-5] separate check code (fewer args, pure, concise) from logging code ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/inlining/walker/InliningData.java Changeset: 8c5bcddb4320 Author: Miguel Garcia Date: 2014-05-20 12:04 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/8c5bcddb4320 [inlining-6] moved Inlineable to dedicated package for inlineable elements ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/inlining/InliningUtil.java ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/inlining/info/AbstractInlineInfo.java ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/inlining/info/ExactInlineInfo.java ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/inlining/info/InlineInfo.java ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/inlining/info/MultiTypeGuardInlineInfo.java ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/inlining/info/TypeGuardInlineInfo.java + graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/inlining/info/elem/Inlineable.java ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/inlining/policy/AbstractInliningPolicy.java ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/inlining/walker/DepthSearchUtil.java ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/inlining/walker/InliningData.java Changeset: 99366262abb5 Author: Miguel Garcia Date: 2014-05-20 12:06 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/99366262abb5 [inlining-6] InlineableMacroNode now in package for inlineable elements ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/inlining/InliningUtil.java ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/inlining/info/AbstractInlineInfo.java + graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/inlining/info/elem/InlineableMacroNode.java ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/inlining/walker/DepthSearchUtil.java ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/inlining/walker/InliningData.java Changeset: 4850ba90e664 Author: Miguel Garcia Date: 2014-05-20 12:08 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/4850ba90e664 [inlining-6] InlineableGraph now in package for inlineable elements ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/inlining/InliningUtil.java ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/inlining/info/AbstractInlineInfo.java + graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/inlining/info/elem/InlineableGraph.java ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/inlining/walker/DepthSearchUtil.java ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/inlining/walker/InliningData.java Changeset: 4df5d01bd8b6 Author: Miguel Garcia Date: 2014-05-20 12:15 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/4df5d01bd8b6 [inlining-7] moved three utilities methods to where they belong ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/inlining/info/elem/InlineableGraph.java ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/inlining/walker/DepthSearchUtil.java Changeset: 5394a8f1d1de Author: Miguel Garcia Date: 2014-05-20 13:00 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/5394a8f1d1de [inlining-7] InlineableGraph takes care of setup chores during construction ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/inlining/info/elem/InlineableGraph.java ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/inlining/walker/DepthSearchUtil.java Changeset: f6942501f010 Author: Miguel Garcia Date: 2014-05-20 13:05 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/f6942501f010 [inlining-7] end of refactoring trail, helper methods now closer to users ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/inlining/info/elem/Inlineable.java - graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/inlining/walker/DepthSearchUtil.java ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/inlining/walker/InliningData.java Changeset: bde6fbdbbe38 Author: Miguel Garcia Date: 2014-05-20 21:38 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/bde6fbdbbe38 Merge Changeset: dffc37fa7157 Author: Tom Rodriguez Date: 2014-05-20 13:46 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/dffc37fa7157 initialize HotSpotVMConfig fields efficiently from C++ ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/HotSpotVMConfig.java - graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/HotSpotVMConstant.java - graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/HotSpotVMField.java - graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/HotSpotVMFlag.java - graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/HotSpotVMType.java + graal/com.oracle.graal.hotspotvmconfig/src/META-INF/services/javax.annotation.processing.Processor + graal/com.oracle.graal.hotspotvmconfig/src/com/oracle/graal/hotspotvmconfig/HotSpotVMConfigProcessor.java + graal/com.oracle.graal.hotspotvmconfig/src/com/oracle/graal/hotspotvmconfig/HotSpotVMConstant.java + graal/com.oracle.graal.hotspotvmconfig/src/com/oracle/graal/hotspotvmconfig/HotSpotVMField.java + graal/com.oracle.graal.hotspotvmconfig/src/com/oracle/graal/hotspotvmconfig/HotSpotVMFlag.java + graal/com.oracle.graal.hotspotvmconfig/src/com/oracle/graal/hotspotvmconfig/HotSpotVMType.java + graal/com.oracle.graal.hotspotvmconfig/src/com/oracle/graal/hotspotvmconfig/HotSpotVMValue.java ! make/bsd/makefiles/vm.make ! make/linux/makefiles/vm.make ! make/solaris/makefiles/vm.make ! make/windows/makefiles/projectcreator.make ! mx/mx_graal.py ! mx/projects ! src/share/vm/graal/graalCompilerToVM.cpp ! src/share/vm/runtime/globals.cpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/vmStructs.cpp ! src/share/vm/runtime/vmStructs.hpp From Eric.Caspole at amd.com Wed May 21 21:42:47 2014 From: Eric.Caspole at amd.com (Caspole, Eric) Date: Wed, 21 May 2014 21:42:47 +0000 Subject: Webrev fix for -UseHSAILDeoptimization Message-ID: Hi everybody, I put a new webrev here - http://cr.openjdk.java.net/~ecaspole/fix_deopt_off/webrev/ This fixes problems where recent changes hade made it so -XX:-UseHSAILDeoptimization was not having the intended effect. With this patch the codegen is correct with -XX:-UseHSAILDeoptimization and the tests have been updated so the hsail tests run clean with or without -XX:-UseHSAILDeoptimization. This passed "mx gate." Note +UseHSAILDeoptimization is still the default for regular Java compatibility. Let me know your comments, Thanks, Eric From doug.simon at oracle.com Thu May 22 01:00:06 2014 From: doug.simon at oracle.com (doug.simon at oracle.com) Date: Thu, 22 May 2014 01:00:06 +0000 Subject: hg: graal/graal: 36 new changesets Message-ID: <201405220100.s4M10weW009847@aojmv0008> Changeset: 240cc9a901fb Author: Tom Rodriguez Date: 2014-05-20 21:35 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/240cc9a901fb don't use JNI natives to interact with VM metadata ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/bridge/CompilerToVM.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/bridge/CompilerToVMImpl.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotResolvedJavaMethod.java ! graal/com.oracle.graal.hotspotvmconfig/src/com/oracle/graal/hotspotvmconfig/HotSpotVMConfigProcessor.java ! src/share/vm/graal/graalCompilerToVM.cpp ! src/share/vm/runtime/vmStructs.hpp Changeset: c9f913e5a93b Author: Tom Rodriguez Date: 2014-05-20 21:40 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/c9f913e5a93b handle expected phis when converting to trapping null checks ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/UseTrappingNullChecksPhase.java Changeset: 5656cfe34979 Author: Miguel Garcia Date: 2014-05-20 14:39 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/5656cfe34979 [inline-info] towards initializing InlineInfo in one place ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/inlining/walker/InliningData.java Changeset: d475c2841f09 Author: Miguel Garcia Date: 2014-05-20 14:48 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/d475c2841f09 [inline-info] step 1 of de-aliasing MethodInvocation assumptions ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/inlining/walker/InliningData.java Changeset: 64deb577ff5c Author: Miguel Garcia Date: 2014-05-20 14:53 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/64deb577ff5c [inline-info] step 2, simpler inter-procedural communication ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/inlining/walker/InliningData.java Changeset: f5934280f47c Author: Miguel Garcia Date: 2014-05-20 15:01 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/f5934280f47c [inline-info] step 3, InlineInfo leaves populateInlineInfo fully initialized ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/inlining/walker/InliningData.java Changeset: ad064659ae4a Author: Miguel Garcia Date: 2014-05-20 15:39 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/ad064659ae4a [inlining] renaming to convey underlying types (1 of 2) ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/inlining/walker/InliningData.java Changeset: f9591dd0b780 Author: Miguel Garcia Date: 2014-05-20 15:42 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/f9591dd0b780 [inlining] renaming to convey underlying types (2 of 2) ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/inlining/walker/InliningData.java Changeset: 066ed90d15a7 Author: Miguel Garcia Date: 2014-05-20 15:45 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/066ed90d15a7 [inlining] another renaming to avoid misleading type suggestion (1 of 2) ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/inlining/walker/InliningData.java Changeset: b5a993ed67ea Author: Miguel Garcia Date: 2014-05-20 15:46 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/b5a993ed67ea [inlining] another renaming to avoid misleading type suggestion (2 of 2) ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/inlining/walker/InliningData.java Changeset: e284afdafe7b Author: Roland Schatz Date: 2014-05-20 16:47 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/e284afdafe7b Allow using StampFactory.forConstant(Constant, MetaAccessProvider) for primitive constants. ! graal/com.oracle.graal.compiler.common/src/com/oracle/graal/compiler/common/type/StampFactory.java Changeset: 8b24f4684aa0 Author: Roland Schatz Date: 2014-05-20 17:26 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/8b24f4684aa0 Introduce AbstractObjectStamp, make ObjectStamp and NarrowOopStamp incompatible. + graal/com.oracle.graal.compiler.common/src/com/oracle/graal/compiler/common/type/AbstractObjectStamp.java ! graal/com.oracle.graal.compiler.common/src/com/oracle/graal/compiler/common/type/ObjectStamp.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/DefaultHotSpotLoweringProvider.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/nodes/CompressionNode.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/nodes/type/NarrowOopStamp.java Changeset: 718034423138 Author: Bernhard Urban Date: 2014-05-21 15:17 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/718034423138 mxtool: fix archive subcommand such that it will return a successful returncode ! mxtool/mx.py Changeset: 2460aed6c899 Author: Bernhard Urban Date: 2014-05-21 15:11 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/2460aed6c899 mx: add support for setting a main class in distributions ! mx/mx_graal.py ! mxtool/mx.py Changeset: f0127716b881 Author: Bernhard Urban Date: 2014-05-21 15:29 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/f0127716b881 mx: remove unused packagejar command ! mx/mx_graal.py Changeset: de8296c27680 Author: Bernhard Urban Date: 2014-05-21 15:34 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/de8296c27680 mx archive: avoid multiple directory entries too ! mxtool/mx.py Changeset: 4900010a15d2 Author: Bernhard Urban Date: 2014-05-21 16:41 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/4900010a15d2 mx archive: fix log message ! mxtool/mx.py Changeset: 9acad98567dc Author: Doug Simon Date: 2014-05-21 17:57 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/9acad98567dc mx: fixed more spurious "error while killing subprocess" messages (GRAAL-350) ! mxtool/mx.py Changeset: 8b4c360cd2fe Author: Christian Wimmer Date: 2014-05-20 18:51 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/8b4c360cd2fe Remove unused method ! graal/com.oracle.graal.api.code/src/com/oracle/graal/api/code/ReferenceMap.java Changeset: 4fd787b04c92 Author: Christian Wimmer Date: 2014-05-20 18:51 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/4fd787b04c92 Recompute probability only when number of types in profile changed ! graal/com.oracle.graal.api.meta/src/com/oracle/graal/api/meta/JavaTypeProfile.java Changeset: 1891bac562d8 Author: Christian Wimmer Date: 2014-05-20 18:52 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/1891bac562d8 Factor out rule creation in its own method ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/match/MatchRuleRegistry.java Changeset: 4e770fa50889 Author: Christian Wimmer Date: 2014-05-20 18:53 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/4e770fa50889 Make NodeClass more flexible ! graal/com.oracle.graal.graph/src/com/oracle/graal/graph/Node.java ! graal/com.oracle.graal.graph/src/com/oracle/graal/graph/NodeClass.java Changeset: 34c99f83795b Author: Christian Wimmer Date: 2014-05-20 18:54 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/34c99f83795b Cache result of toJava and toJavaConstructor, since it is an expensive operation ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotResolvedJavaMethod.java Changeset: af16872a18f1 Author: Christian Wimmer Date: 2014-05-20 18:54 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/af16872a18f1 Add accessor method ! graal/com.oracle.graal.java/src/com/oracle/graal/java/AbstractFrameStateBuilder.java Changeset: 90b324f2bd66 Author: Christian Wimmer Date: 2014-05-20 18:55 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/90b324f2bd66 Bugfix: as long as snippets are preprocessed, PiNode must not be canonicalized ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/PiNode.java Changeset: 1ddee372bf62 Author: Christian Wimmer Date: 2014-05-20 18:55 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/1ddee372bf62 Make classes extensible ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/java/CheckCastNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/java/InstanceOfNode.java Changeset: 120a8209389d Author: Christian Wimmer Date: 2014-05-20 18:56 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/120a8209389d Remove overly strict assertion; avoid NullPointerException when canonicalizing invokes without a state ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/java/MethodCallTargetNode.java Changeset: e28cb4a30e86 Author: Christian Wimmer Date: 2014-05-20 18:57 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/e28cb4a30e86 Avoid NullPointerException when only some assertions are enabled ! graal/com.oracle.graal.replacements/src/com/oracle/graal/replacements/SnippetTemplate.java Changeset: fc6f8d143c68 Author: Christian Wimmer Date: 2014-05-20 18:58 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/fc6f8d143c68 Introduce method to customize type size ! graal/com.oracle.truffle.api/src/com/oracle/truffle/api/nodes/NodeUtil.java Changeset: 187634c8099c Author: Christian Wimmer Date: 2014-05-20 18:58 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/187634c8099c Remove overly restrictive assertion ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/extended/LoadHubNode.java Changeset: faebb143dab2 Author: Christian Wimmer Date: 2014-05-20 18:59 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/faebb143dab2 Introduce class BarrieredAccess for low-level object access with read and write barriers + graal/com.oracle.graal.word/src/com/oracle/graal/word/BarrieredAccess.java ! graal/com.oracle.graal.word/src/com/oracle/graal/word/ObjectAccess.java ! graal/com.oracle.graal.word/src/com/oracle/graal/word/Pointer.java ! graal/com.oracle.graal.word/src/com/oracle/graal/word/Word.java ! graal/com.oracle.graal.word/src/com/oracle/graal/word/phases/WordTypeRewriterPhase.java Changeset: 6fe57ff3f02c Author: Christian Wimmer Date: 2014-05-20 19:01 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/6fe57ff3f02c Rename methods to have consistent names, allow subclasses of bytecode parsers ! graal/com.oracle.graal.baseline/src/com/oracle/graal/baseline/BaselineBytecodeParser.java ! graal/com.oracle.graal.java/src/com/oracle/graal/java/AbstractBytecodeParser.java ! graal/com.oracle.graal.java/src/com/oracle/graal/java/GraphBuilderPhase.java Changeset: 15771ff797b4 Author: Christian Wimmer Date: 2014-05-20 19:02 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/15771ff797b4 Pass the compiled method to LIR factory ! graal/com.oracle.graal.api.code/src/com/oracle/graal/api/code/CompilationResult.java ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/GraalCompiler.java ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/gen/NodeLIRBuilder.java ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/target/Backend.java ! graal/com.oracle.graal.hotspot.amd64/src/com/oracle/graal/hotspot/amd64/AMD64HotSpotBackend.java ! graal/com.oracle.graal.hotspot.amd64/src/com/oracle/graal/hotspot/amd64/AMD64HotSpotNodeLIRBuilder.java ! graal/com.oracle.graal.hotspot.hsail/src/com/oracle/graal/hotspot/hsail/HSAILHotSpotBackend.java ! graal/com.oracle.graal.hotspot.ptx/src/com/oracle/graal/hotspot/ptx/PTXHotSpotBackend.java ! graal/com.oracle.graal.hotspot.sparc/src/com/oracle/graal/hotspot/sparc/SPARCHotSpotBackend.java ! graal/com.oracle.graal.hotspot.sparc/src/com/oracle/graal/hotspot/sparc/SPARCHotSpotNodeLIRBuilder.java Changeset: 2838203d4231 Author: Christian Wimmer Date: 2014-05-20 19:06 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/2838203d4231 Add method ResolvedJavaType.getStaticFields ! graal/com.oracle.graal.api.meta/src/com/oracle/graal/api/meta/ResolvedJavaType.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotResolvedObjectType.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotResolvedPrimitiveType.java Changeset: e6f93283387a Author: Christian Wimmer Date: 2014-05-21 10:08 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/e6f93283387a Merge ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotResolvedJavaMethod.java Changeset: cb87019df5aa Author: Christian Wimmer Date: 2014-05-21 10:25 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/cb87019df5aa Add test for getStaticFields() ! graal/com.oracle.graal.api.meta.test/src/com/oracle/graal/api/meta/test/TestResolvedJavaType.java From thomas.wuerthinger at oracle.com Thu May 22 15:11:52 2014 From: thomas.wuerthinger at oracle.com (Thomas Wuerthinger) Date: Thu, 22 May 2014 17:11:52 +0200 Subject: Graal Release 0.3, Transition to JDK8, New Truffle Call API Message-ID: We are pleased to announce the release of Graal version 0.3. In addition to general stability and performance improvements, the main changes are the transition to JDK8 as well as a new API for Truffle calls. Additionally, we added support for obtaining stack traces on the Truffle level [1]. Source repository changeset: http://hg.openjdk.java.net/graal/graal/rev/graal-0.3 Binaries for Linux, MacOS, and Windows as well as detailed changelog: http://lafo.ssw.uni-linz.ac.at/builds. We would like to thank everyone who helped with this release. We very much appreciate both direct contributions as well as feedback! The Graal Team [1] http://lafo.ssw.uni-linz.ac.at/javadoc/graalvm/all/com/oracle/truffle/api/TruffleRuntime.html#getStackTrace-- From doug.simon at oracle.com Fri May 23 01:00:06 2014 From: doug.simon at oracle.com (doug.simon at oracle.com) Date: Fri, 23 May 2014 01:00:06 +0000 Subject: hg: graal/graal: 12 new changesets Message-ID: <201405230100.s4N10M62008737@aojmv0008> Changeset: eb947cc7bff9 Author: Michael Van De Vanter Date: 2014-05-21 21:07 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/eb947cc7bff9 Truffle: revise instrumentation support APIs in ExecutionContext ! graal/com.oracle.truffle.api/src/com/oracle/truffle/api/ExecutionContext.java Changeset: 747bc4099ad8 Author: Tom Rodriguez Date: 2014-05-21 22:22 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/747bc4099ad8 rename initializeBytecode to getBytecode and eliminate extra copy ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/bridge/CompilerToVM.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/bridge/CompilerToVMImpl.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotResolvedJavaMethod.java ! src/share/vm/graal/graalCompilerToVM.cpp Changeset: d1822a8fe26f Author: Tom Rodriguez Date: 2014-05-21 22:44 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/d1822a8fe26f minor cleanups ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/match/MatchProcessor.java ! graal/com.oracle.graal.hotspotvmconfig/src/com/oracle/graal/hotspotvmconfig/HotSpotVMConfigProcessor.java ! mx/mx_graal.py Changeset: babe4565c371 Author: twisti Date: 2014-05-22 12:41 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/babe4565c371 mx: fixed incorrect test for subprocess being alive ! mxtool/mx.py Changeset: 399aa56c6366 Author: twisti Date: 2014-05-22 13:19 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/399aa56c6366 HSAIL: fix for -UseHSAILDeoptimization Contributed-by: Eric Caspole ! graal/com.oracle.graal.compiler.hsail.test/src/com/oracle/graal/compiler/hsail/test/AtomicIntGetAndAddTest.java ! graal/com.oracle.graal.compiler.hsail.test/src/com/oracle/graal/compiler/hsail/test/AtomicIntGetAndSetTest.java ! graal/com.oracle.graal.compiler.hsail.test/src/com/oracle/graal/compiler/hsail/test/AtomicLongGetAndAddTest.java ! graal/com.oracle.graal.compiler.hsail.test/src/com/oracle/graal/compiler/hsail/test/AtomicLongGetAndSetTest.java ! graal/com.oracle.graal.compiler.hsail.test/src/com/oracle/graal/compiler/hsail/test/lambda/AtomicIntAddAndGetGidTest.java ! graal/com.oracle.graal.compiler.hsail.test/src/com/oracle/graal/compiler/hsail/test/lambda/AtomicIntAddAndGetTest.java ! graal/com.oracle.graal.compiler.hsail.test/src/com/oracle/graal/compiler/hsail/test/lambda/AtomicIntDecAndGetTest.java ! graal/com.oracle.graal.compiler.hsail.test/src/com/oracle/graal/compiler/hsail/test/lambda/AtomicIntGetAndAddTest.java ! graal/com.oracle.graal.compiler.hsail.test/src/com/oracle/graal/compiler/hsail/test/lambda/AtomicIntGetAndDecTest.java ! graal/com.oracle.graal.compiler.hsail.test/src/com/oracle/graal/compiler/hsail/test/lambda/AtomicIntGetAndIncTest.java ! graal/com.oracle.graal.compiler.hsail.test/src/com/oracle/graal/compiler/hsail/test/lambda/AtomicIntIncAndGetTest.java ! graal/com.oracle.graal.compiler.hsail.test/src/com/oracle/graal/compiler/hsail/test/lambda/AtomicLongAddAndGetTest.java ! graal/com.oracle.graal.compiler.hsail.test/src/com/oracle/graal/compiler/hsail/test/lambda/AtomicLongGetAndAddTest.java ! graal/com.oracle.graal.compiler.hsail.test/src/com/oracle/graal/compiler/hsail/test/lambda/AtomicLongGetAndIncTest.java ! graal/com.oracle.graal.compiler.hsail.test/src/com/oracle/graal/compiler/hsail/test/lambda/AtomicLongIncAndGetTest.java ! graal/com.oracle.graal.compiler.hsail.test/src/com/oracle/graal/compiler/hsail/test/lambda/ForEachToGraalTest.java ! graal/com.oracle.graal.compiler.hsail.test/src/com/oracle/graal/compiler/hsail/test/lambda/VecmathNBodyDeoptTest.java ! graal/com.oracle.graal.hotspot.hsail/src/com/oracle/graal/hotspot/hsail/HSAILHotSpotBackend.java ! graal/com.oracle.graal.hotspot.hsail/src/com/oracle/graal/hotspot/hsail/HSAILHotSpotLIRGenerator.java ! graal/com.oracle.graal.hotspot.hsail/src/com/oracle/graal/hotspot/hsail/HSAILHotSpotNodeLIRBuilder.java ! graal/com.oracle.graal.hotspot.hsail/src/com/oracle/graal/hotspot/hsail/HSAILHotSpotSafepointOp.java ! graal/com.oracle.graal.lir.hsail/src/com/oracle/graal/lir/hsail/HSAILControlFlow.java Changeset: 9e172511971d Author: Lukas Stadler Date: 2014-05-22 14:04 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/9e172511971d make FixedNodeProbabilityCache behave better in the presence of dead code ! graal/com.oracle.graal.phases/src/com/oracle/graal/phases/graph/FixedNodeProbabilityCache.java Changeset: 11328036d854 Author: Lukas Stadler Date: 2014-05-22 14:04 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/11328036d854 fix bug in ConditionalEliminationPhase that loses the connection from guard to checkcast PiNode ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/ConditionalEliminationPhase.java Changeset: e7277bf3b171 Author: Lukas Stadler Date: 2014-05-22 14:04 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/e7277bf3b171 skip PiNode in AMD64HotSpotNodeLIRBuilder.filterCompression ! graal/com.oracle.graal.hotspot.amd64/src/com/oracle/graal/hotspot/amd64/AMD64HotSpotNodeLIRBuilder.java Changeset: 9ce2ca72efef Author: Lukas Stadler Date: 2014-05-22 14:04 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/9ce2ca72efef small cleanup in LinearScan ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/alloc/LinearScan.java Changeset: 94a2df2f8e58 Author: Lukas Stadler Date: 2014-05-22 14:04 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/94a2df2f8e58 preserve context in Debug.forceLog ! graal/com.oracle.graal.debug/src/com/oracle/graal/debug/Debug.java Changeset: 8b8208aa2f44 Author: Lukas Stadler Date: 2014-05-22 16:51 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/8b8208aa2f44 put LoopSafepointEliminationPhase into an IncrementalCanonicalizerPhase ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/phases/MidTier.java Changeset: 241044995c87 Author: Lukas Stadler Date: 2014-05-22 16:51 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/241044995c87 only canonicalize CustomizedUnsafeLoadFinalNode if the condition is constant ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/nodes/typesystem/CustomizedUnsafeLoadFinalNode.java From doug.simon at oracle.com Fri May 23 11:59:37 2014 From: doug.simon at oracle.com (doug.simon at oracle.com) Date: Fri, 23 May 2014 11:59:37 +0000 Subject: hg: graal/graal: 8 new changesets Message-ID: <201405231159.s4NBxmX6016564@aojmv0008> Changeset: 3ce7f1c32353 Author: Miguel Garcia Date: 2014-05-21 19:49 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/3ce7f1c32353 [inlining] readability in CallsiteHolder constructor, part 1 ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/inlining/walker/CallsiteHolder.java Changeset: 1a8a29431872 Author: Miguel Garcia Date: 2014-05-21 20:04 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/1a8a29431872 [inlining] readability in CallsiteHolder constructor, part 2 ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/inlining/walker/CallsiteHolder.java Changeset: 3f735cec823e Author: Miguel Garcia Date: 2014-05-21 20:49 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/3f735cec823e [inlining] operation that pushes invocation goes ahead and pushes graphs too ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/inlining/walker/InliningData.java Changeset: bca82eabfe78 Author: Miguel Garcia Date: 2014-05-21 20:51 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/bca82eabfe78 [inlining] forgotten assertion, counterpart to the one in pushGraph() ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/inlining/walker/InliningData.java Changeset: 6eb913e7ec0d Author: Miguel Garcia Date: 2014-05-21 21:47 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/6eb913e7ec0d [inlining] isEmpty() favored over size() == 0 ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/inlining/walker/InliningData.java Changeset: ebe257551ffd Author: Miguel Garcia Date: 2014-05-22 11:18 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/ebe257551ffd [inlining] more precise type in createDispatchOnTypeBeforeInvoke() ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/inlining/info/MultiTypeGuardInlineInfo.java Changeset: 3e55e9614af7 Author: Miguel Garcia Date: 2014-05-22 14:15 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/3e55e9614af7 [inlining] check maxMethodPerInlining after discarding methods below threshold ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/inlining/walker/InliningData.java Changeset: dba1a510fe92 Author: Doug Simon Date: 2014-05-23 13:10 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/dba1a510fe92 mx: annotation processor paths must include libraries that are also Eclipse containers ! mxtool/mx.py From doug.simon at oracle.com Sat May 24 01:00:06 2014 From: doug.simon at oracle.com (doug.simon at oracle.com) Date: Sat, 24 May 2014 01:00:06 +0000 Subject: hg: graal/graal: 27 new changesets Message-ID: <201405240100.s4O10g6q005658@aojmv0008> Changeset: 283c8d31c560 Author: Bernhard Urban Date: 2014-05-23 11:25 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/283c8d31c560 mx: update vm choice helptext ! mx/mx_graal.py Changeset: f04a541af3c9 Author: Bernhard Urban Date: 2014-05-23 11:50 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/f04a541af3c9 mx: add pack200 to javaconfig ! mxtool/mx.py Changeset: cd755faecaec Author: Bernhard Urban Date: 2014-05-23 13:22 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/cd755faecaec midtier: remove ReadEliminationPhase (superseded by EarlyReadEliminationPhase) ! graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/ReadAfterCheckCastTest.java ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/phases/MidTier.java - graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/ReadEliminationPhase.java Changeset: 3a5ddfa22e77 Author: Gilles Duboscq Date: 2014-05-23 13:21 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/3a5ddfa22e77 Simplify removeOrMaterializeIf and make it handle merges with more predecessors. ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/IfNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/PhiNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/StructuredGraph.java Changeset: 0456d9b10322 Author: Gilles Duboscq Date: 2014-05-23 14:51 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/0456d9b10322 CanonicalizerPhase: canonicalize usages when stamp changes ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/CanonicalizerPhase.java Changeset: 23f45bae453a Author: Lukas Stadler Date: 2014-05-23 17:43 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/23f45bae453a read elimination without schedule ! graal/com.oracle.graal.virtual/src/com/oracle/graal/virtual/phases/ea/EarlyReadEliminationPhase.java ! graal/com.oracle.graal.virtual/src/com/oracle/graal/virtual/phases/ea/EffectsClosure.java ! graal/com.oracle.graal.virtual/src/com/oracle/graal/virtual/phases/ea/EffectsPhase.java ! graal/com.oracle.graal.virtual/src/com/oracle/graal/virtual/phases/ea/PartialEscapeClosure.java ! graal/com.oracle.graal.virtual/src/com/oracle/graal/virtual/phases/ea/PartialEscapePhase.java ! graal/com.oracle.graal.virtual/src/com/oracle/graal/virtual/phases/ea/ReadEliminationClosure.java Changeset: e626b112aa3d Author: Lukas Stadler Date: 2014-05-23 17:47 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/e626b112aa3d consume less memory in ReentrantBlockIterator and ReentrantNodeIterator ! graal/com.oracle.graal.phases/src/com/oracle/graal/phases/graph/ReentrantBlockIterator.java ! graal/com.oracle.graal.phases/src/com/oracle/graal/phases/graph/ReentrantNodeIterator.java Changeset: 387b15da0f68 Author: Lukas Stadler Date: 2014-05-23 17:47 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/387b15da0f68 small cleanup in ReadElimination ! graal/com.oracle.graal.virtual/src/com/oracle/graal/virtual/phases/ea/ReadEliminationBlockState.java ! graal/com.oracle.graal.virtual/src/com/oracle/graal/virtual/phases/ea/ReadEliminationClosure.java Changeset: fe608a56e3f7 Author: Doug Simon Date: 2014-05-23 19:36 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/fe608a56e3f7 made HotSpotOptions processing faster by removing use of service loader in VM startup and only doing work for options specified on the command line ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/HotSpotOptions.java + graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/HotSpotOptionsLoader.java ! mx/mx_graal.py ! src/share/vm/graal/graalRuntime.cpp ! src/share/vm/graal/graalRuntime.hpp ! src/share/vm/graal/graalVMToCompiler.cpp ! src/share/vm/graal/graalVMToCompiler.hpp ! src/share/vm/prims/nativeLookup.cpp Changeset: 11bf5b8973c9 Author: Doug Simon Date: 2014-05-24 00:23 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/11bf5b8973c9 mx: drain all subprocess output to callables before returning from mx.run ! mxtool/mx.py Changeset: b7fc7cdb9005 Author: Doug Simon Date: 2014-05-24 00:25 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/b7fc7cdb9005 HotSpotOptions error messages should go to System.err ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/HotSpotOptions.java Changeset: 6dcf8ab4ad86 Author: Doug Simon Date: 2014-05-24 00:46 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/6dcf8ab4ad86 HotSpotOptions.inline.hpp generator writes to System.out to make generator errors more visible (they will show up when compiling the generated source) ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/HotSpotOptionsLoader.java ! mx/mx_graal.py Changeset: 70bb12bdd178 Author: Doug Simon Date: 2014-05-24 00:54 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/70bb12bdd178 added clarifying comment ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/HotSpotOptionsLoader.java Changeset: 2d5f9c7379c1 Author: Thomas Wuerthinger Date: 2014-05-13 02:31 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/2d5f9c7379c1 Propagate 0.0 probabilities when simplifying IfNode. ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/IfNode.java Changeset: 8df3b6d4a035 Author: Thomas Wuerthinger Date: 2014-05-13 02:31 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/8df3b6d4a035 Merge. Changeset: f55153a2ca55 Author: Thomas Wuerthinger Date: 2014-05-13 03:57 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/f55153a2ca55 Stop propagating probability above loop header. ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/IfNode.java Changeset: c315c86e2130 Author: Thomas Wuerthinger Date: 2014-05-13 12:15 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/c315c86e2130 Fix exponential explosion when propagating zero probabilities. ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/IfNode.java Changeset: b963148055d6 Author: Thomas Wuerthinger Date: 2014-05-13 12:15 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/b963148055d6 Merge. - graal/com.oracle.truffle.api/src/com/oracle/truffle/api/instrument/InstrumentEventListener.java - graal/com.oracle.truffle.api/src/com/oracle/truffle/api/instrument/Instrumentation.java - graal/com.oracle.truffle.api/src/com/oracle/truffle/api/instrument/InstrumentationFactory.java - graal/com.oracle.truffle.api/src/com/oracle/truffle/api/instrument/impl/InstrumentationImpl.java - graal/com.oracle.truffle.api/src/com/oracle/truffle/api/instrument/impl/NullInstrumentEventListener.java Changeset: a43ff5d18350 Author: Thomas Wuerthinger Date: 2014-05-13 19:19 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/a43ff5d18350 Merge. Changeset: a6eeb3750238 Author: Thomas Wuerthinger Date: 2014-05-21 11:45 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/a6eeb3750238 Merge. - graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/HotSpotVMConstant.java - graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/HotSpotVMField.java - graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/HotSpotVMFlag.java - graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/HotSpotVMType.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/IfNode.java - graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/inlining/ComputeInliningRelevance.java - graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/inlining/InliningIterator.java - graal/com.oracle.truffle.api/src/com/oracle/truffle/api/impl/AbstractExecutionContext.java - graal/com.oracle.truffle.api/src/com/oracle/truffle/api/impl/DefaultSourceSection.java - graal/com.oracle.truffle.api/src/com/oracle/truffle/api/instrument/impl/SourceCallback.java Changeset: e751da27fd48 Author: Thomas Wuerthinger Date: 2014-05-22 18:10 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/e751da27fd48 Merge. Changeset: 9b6d45071187 Author: Thomas Wuerthinger Date: 2014-05-24 00:38 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/9b6d45071187 Merge. ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/IfNode.java - graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/ReadEliminationPhase.java Changeset: 0e6f83eeb0ab Author: Thomas Wuerthinger Date: 2014-05-24 01:05 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/0e6f83eeb0ab Clean up in LinearScan: Remove the need for a mapping of variable index to variable object. ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/alloc/LinearScan.java Changeset: 4d18c6bb6b3a Author: Thomas Wuerthinger Date: 2014-05-24 01:16 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/4d18c6bb6b3a LinearScan: Improve initialization and resizing of intervals array. ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/alloc/LinearScan.java Changeset: e5e7d9dfff1a Author: Thomas Wuerthinger Date: 2014-05-24 01:32 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/e5e7d9dfff1a LinearScan: Clean up interval comparator and replace with lambda form. ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/alloc/LinearScan.java Changeset: 839ea165f816 Author: Thomas Wuerthinger Date: 2014-05-24 01:38 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/839ea165f816 LinearScan: Small cleanup. ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/alloc/LinearScan.java Changeset: 1aaadf06db1b Author: Thomas Wuerthinger Date: 2014-05-24 01:41 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/1aaadf06db1b Merge. From jules_gosnell at yahoo.com Sat May 24 07:02:08 2014 From: jules_gosnell at yahoo.com (Jules Gosnell) Date: Sat, 24 May 2014 08:02:08 +0100 Subject: clumatra: recent ?regression? In-Reply-To: References: <537A8FD8.5030800@yahoo.com> Message-ID: <538043F0.40500@yahoo.com> Thanks, Tom, That nailed it :-) Jules On 20/05/14 14:22, Deneau, Tom wrote: > Jules -- > > I can't see the command lines you used but I believe you are using -XX:-UseHSAILDeoptimization. > But it looks like HSAILSafepoints are still on which is causing the trouble (safepoints depend on deoptimization). > Can you try also adding -XX:-UseHSAILSafepoints to your command line? > > We should correct this by automatically turning off HSAILSafepoints if HSAILDeoptimization is off. > > -- Tom > >> -----Original Message----- >> From: graal-dev [mailto:graal-dev-bounces at openjdk.java.net] On Behalf Of >> Jules Gosnell >> Sent: Monday, May 19, 2014 6:12 PM >> To: graal-dev at openjdk.java.net >> Subject: clumatra: recent ?regression? >> >> Guys, >> >> thought that I should let you know. >> >> my overnight builds 15/16th may for both hardware and simulated jdk- >> 1.8/graal/okra sumatra stacks both suffered from crashed vms and have >> continued to do so, until I tracked down the test in question and >> disabled it. >> >> here are the full logs: >> >> http://ouroboros.dyndns-free.com/ci/view/clumatra/job/clumatra-hardware- >> acceleration/246/consoleText >> http://ouroboros.dyndns-free.com/ci/view/clumatra/job/clumatra- >> simulated-acceleration/199/consoleText >> >> if you scroll right to the bottom of each you will find that they end >> prematurely without a test summary - one silently, the other reports a >> segv: >> >> |7 |8 |9 |10 >> locals: |- >> |- >> |- |- |- |- |- |- |- |d9|j |- >> stack: >> |vobject:Ratio:1{numerator=Object[null],denominator=Object[null]} >> |vobject:Ratio:1{numerator=Object[null],denominator=Object[null]} | | >> | | | | | | | >> at clojure.lang.Numbers.divide(Numbers.java:157) [bci: 46] >> |0 |1 |2 >> locals: |- |- |- >> at clojure.lang.Numbers.divide(Numbers.java:3731) [bci: 8] >> |0 |1 |2 |3 >> locals: |- |- |- |- >> at clumatra.numbers_test$fn$reify__7461.invoke(numbers_test.clj:54) >> [bci: 35] >> |0 |1 |2 |3 |4 >> locals: |- |- |- |- |- >> stack: |d3|a |s0|i | | | >> >> > ld_kernarg_u64 $d16, [%_deoptInfo]; >> > ^ >> input(63,23): Symbol not found >> # >> # A fatal error has been detected by the Java Runtime Environment: >> # >> # SIGSEGV (0xb) at pc=0x00007fcbe29ab08d, pid=24144, >> tid=140515433301760 # # JRE version: OpenJDK Runtime Environment (8.0) >> (build >> 1.8.0-internal-jenkins_2014_05_16_09_06-b00) >> # Java VM: OpenJDK 64-Bit Server VM (25.0-b63-internal-graal-0.3 mixed >> mode linux-amd64 compressed oops) # Problematic frame: >> # C [libokra_x86_64.so+0x59508d] >> Java_com_amd_okra_OkraKernel_setLaunchAttributes+0x43 >> >> I can reproduce the problem with any required flags, and provide >> relevant src code (java) if someone is interested in looking at this. >> For now, I will just lose the problematic test. >> >> perhaps something has changed and I need to update my build ? >> >> thanks for all your hard work on graal, >> >> >> Jules >> > > From java at stefan-marr.de Sat May 24 14:45:11 2014 From: java at stefan-marr.de (Stefan Marr) Date: Sat, 24 May 2014 16:45:11 +0200 Subject: Potential Graal Regression: The location argument could not be resolved to a constant. Message-ID: Hi: Adopting the latest version of Graal, I am having trouble with failing optimization passes because of ?The location argument could not be resolved to a constant.? For all case I investigated so far, I get a stack trace like the following: at com.oracle.graal.truffle.FrameWithoutBoxing.getObjectUnsafe(FrameWithoutBoxing.java:84) at com.oracle.graal.truffle.FrameWithoutBoxing.getObject(FrameWithoutBoxing.java:68) at com.oracle.truffle.api.frame.FrameUtil.getObjectSafe(FrameUtil.java:38) at som.interpreter.nodes.literals.BlockNode$BlockNodeWithContext.getOuterSelf(BlockNode.java:67) at som.vmobjects.SBlock.getOuterSelf(SBlock.java:103) at som.interpreter.nodes.ContextualNode.determineContext(ContextualNode.java:61) Now, the location in question, i.e., the frame slot, is used like this [1]: public Object getOuterSelf(final MaterializedFrame frame) { return FrameUtil.getObjectSafe(frame, outerSelfSlot); } And defined as `private final FrameSlot outerSelfSlot;` This reminds me of a change I did in March [2] based on Andreas? comment [3]. But, now this problem seems to be back, and since I didn?t change anything in my code, but just updated Graal, it looks like there might be either a regression or an old problem exposed. However, I don?t really see how I could get the frame slot ?even more constant? than what I have now. Perhaps, I am reading the stack trace wrong, or there is something else going on? To reproduce, the following should give an up-to-date TruffleSOM (note the recursive git submodule checkout, core-lib probably needs an update if you got an older copy): git clone --recursive https://github.com/SOM-st/TruffleSOM.git ant jar ant test ./graal.sh -cp Smalltalk Examples/Benchmarks/BenchmarkHarness.som TreeSort 100 0 100 Thanks Stefan [1] https://github.com/SOM-st/TruffleSOM/blob/master/src/som/interpreter/nodes/literals/BlockNode.java#L67 [2] https://github.com/SOM-st/TruffleSOM/commit/c002b9be8bbed2ecf0c7a3fce93f9c108563e73e [3] http://markmail.org/message/ad7jd2ewopheqo2l -- Stefan Marr INRIA Lille - Nord Europe http://stefan-marr.de/research/ From doug.simon at oracle.com Sun May 25 01:00:07 2014 From: doug.simon at oracle.com (doug.simon at oracle.com) Date: Sun, 25 May 2014 01:00:07 +0000 Subject: hg: graal/graal: 4 new changesets Message-ID: <201405250100.s4P10Ptw003923@aojmv0008> Changeset: 8184c00fefd2 Author: Christian Wimmer Date: 2014-05-23 17:33 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/8184c00fefd2 Factor out VM-independent part of DefaultHotSpotLoweringProvider into DefaultJavaLoweringProvider ! graal/com.oracle.graal.hotspot.amd64/src/com/oracle/graal/hotspot/amd64/AMD64HotSpotBackendFactory.java ! graal/com.oracle.graal.hotspot.amd64/src/com/oracle/graal/hotspot/amd64/AMD64HotSpotLoweringProvider.java ! graal/com.oracle.graal.hotspot.hsail/src/com/oracle/graal/hotspot/hsail/HSAILHotSpotBackendFactory.java ! graal/com.oracle.graal.hotspot.hsail/src/com/oracle/graal/hotspot/hsail/HSAILHotSpotLoweringProvider.java ! graal/com.oracle.graal.hotspot.hsail/src/com/oracle/graal/hotspot/hsail/replacements/HSAILNewObjectSnippets.java ! graal/com.oracle.graal.hotspot.sparc/src/com/oracle/graal/hotspot/sparc/SPARCHotSpotBackendFactory.java ! graal/com.oracle.graal.hotspot.sparc/src/com/oracle/graal/hotspot/sparc/SPARCHotSpotLoweringProvider.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/DefaultHotSpotLoweringProvider.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotLoweringProvider.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/NewObjectSnippets.java + graal/com.oracle.graal.replacements/src/com/oracle/graal/replacements/DefaultJavaLoweringProvider.java Changeset: f4510fd9e8b3 Author: Thomas Wuerthinger Date: 2014-05-24 13:37 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/f4510fd9e8b3 Removed unused grow functionality on NodeMap. ! graal/com.oracle.graal.graph/src/com/oracle/graal/graph/Graph.java ! graal/com.oracle.graal.graph/src/com/oracle/graal/graph/NodeMap.java ! graal/com.oracle.graal.graph/src/com/oracle/graal/graph/NodeNodeMap.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/cfg/ControlFlowGraph.java Changeset: 09ac9ac9c4fc Author: Michael Van De Vanter Date: 2014-05-24 10:34 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/09ac9ac9c4fc Truffle: SourceManager renamed to SourceFactory - All methods are static, no longer accessed via ExecutionContext - Sources are indexed with weak references - File content caching is now optional; off by default ! graal/com.oracle.truffle.api/src/com/oracle/truffle/api/ExecutionContext.java + graal/com.oracle.truffle.api/src/com/oracle/truffle/api/source/SourceFactory.java - graal/com.oracle.truffle.api/src/com/oracle/truffle/api/source/SourceManager.java ! graal/com.oracle.truffle.sl.test/src/com/oracle/truffle/sl/test/SLTestRunner.java ! graal/com.oracle.truffle.sl/src/com/oracle/truffle/sl/SLMain.java ! graal/com.oracle.truffle.sl/src/com/oracle/truffle/sl/builtins/SLDefineFunctionBuiltin.java ! graal/com.oracle.truffle.sl/src/com/oracle/truffle/sl/runtime/SLContext.java Changeset: 079229f002a3 Author: Michael Van De Vanter Date: 2014-05-24 10:48 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/079229f002a3 Merge with f4510fd9e8b3ad6965b3162b27edb476baa7140d - graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/ReadEliminationPhase.java From doug.simon at oracle.com Mon May 26 01:00:06 2014 From: doug.simon at oracle.com (doug.simon at oracle.com) Date: Mon, 26 May 2014 01:00:06 +0000 Subject: hg: graal/graal: added timers for Graal runtime initialization steps (enabled with -Dgraal.runtime.TimeInit=true) Message-ID: <201405260100.s4Q10CaQ002669@aojmv0008> Changeset: 839cb35354e8 Author: Doug Simon Date: 2014-05-25 15:55 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/839cb35354e8 added timers for Graal runtime initialization steps (enabled with -Dgraal.runtime.TimeInit=true) ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/HotSpotGraalRuntime.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/HotSpotHostBackend.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/bridge/VMToCompilerImpl.java From doug.simon at oracle.com Mon May 26 12:39:45 2014 From: doug.simon at oracle.com (doug.simon at oracle.com) Date: Mon, 26 May 2014 12:39:45 +0000 Subject: hg: graal/graal: 8 new changesets Message-ID: <201405261239.s4QCdufV023993@aojmv0008> Changeset: a9810ed7cad2 Author: Christian Wirth Date: 2014-05-26 09:46 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/a9810ed7cad2 explicit conversion to int, fixes windows build ! src/share/vm/graal/graalRuntime.cpp Changeset: a5c5b4aa79ca Author: Doug Simon Date: 2014-05-26 11:47 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/a5c5b4aa79ca mx: prevent CTRL-C from being blocked while subprocess is running ! mxtool/mx.py Changeset: db776f9bea7c Author: Doug Simon Date: 2014-05-26 11:48 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/db776f9bea7c mx: prevent spurious "Could not find or load main class com.oracle.graal.hotspot.HotSpotOptionsLoader" error message ! mx/mx_graal.py Changeset: c5f57314599d Author: Doug Simon Date: 2014-05-26 12:52 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/c5f57314599d Backed out changeset: a5c5b4aa79ca ! mxtool/mx.py Changeset: c102edf38127 Author: Doug Simon Date: 2014-05-26 12:55 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/c102edf38127 mx: prevent CTRL-C from being blocked while subprocess is running (re-applied without unrelated changes) ! mxtool/mx.py Changeset: e065b9746246 Author: Doug Simon Date: 2014-05-26 13:02 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/e065b9746246 mx: create Eclipse projects for distributions ! mx/projects ! mxtool/mx.py Changeset: 54151c986dbb Author: Lukas Stadler Date: 2014-05-26 13:37 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/54151c986dbb explicit getAndGrow and setAndGrow functionality on NodeMap ! graal/com.oracle.graal.graph/src/com/oracle/graal/graph/NodeMap.java Changeset: dd863084c7ad Author: Lukas Stadler Date: 2014-05-26 13:37 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/dd863084c7ad tests for NodeMap + graal/com.oracle.graal.graph.test/src/com/oracle/graal/graph/test/NodeMapTest.java From doug.simon at oracle.com Mon May 26 12:47:29 2014 From: doug.simon at oracle.com (Doug Simon) Date: Mon, 26 May 2014 14:47:29 +0200 Subject: Distributions are now distinct Eclipse projects Message-ID: As of http://hg.openjdk.java.net/graal/graal/rev/e065b9746246, the 'mx eclipseinit? and 'mx ideinit? commands generate an Eclipse project for each distribution declared in mx/projects. As a result, Eclipse only (re)builds the jar for a distribution after all update tasks for all modified constituent projects have completed, instead of doing it for each project. To ensure you get the same behavior from Eclipse as prior to this change, you need to import the distribution projects into Eclipse (the same way you would import normal projects). -Doug From java at stefan-marr.de Mon May 26 22:45:41 2014 From: java at stefan-marr.de (Stefan Marr) Date: Tue, 27 May 2014 00:45:41 +0200 Subject: Potential Graal Regression: The location argument could not be resolved to a constant. In-Reply-To: References: Message-ID: Hi Gilles: On 24 May 2014, at 16:45, Stefan Marr wrote: > Adopting the latest version of Graal, I am having trouble with failing optimization passes because of ?The location argument could not be resolved to a constant.? I think, my problem starts with one of your commits, most likely: http://hg.openjdk.java.net/graal/graal/rev/ef6b8d1898e6 Well, actually that one doesn?t yield a working VM for me. But the last good commit is: http://hg.openjdk.java.net/graal/graal/rev/a9f969e65b61 Afterwards, I get the ?The location argument could not be resolved to a constant? issues described below. And http://hg.openjdk.java.net/graal/graal/rev/fa66540676ce is definitely broken. Thanks Stefan > > For all case I investigated so far, I get a stack trace like the following: > > at com.oracle.graal.truffle.FrameWithoutBoxing.getObjectUnsafe(FrameWithoutBoxing.java:84) > at com.oracle.graal.truffle.FrameWithoutBoxing.getObject(FrameWithoutBoxing.java:68) > at com.oracle.truffle.api.frame.FrameUtil.getObjectSafe(FrameUtil.java:38) > at som.interpreter.nodes.literals.BlockNode$BlockNodeWithContext.getOuterSelf(BlockNode.java:67) > at som.vmobjects.SBlock.getOuterSelf(SBlock.java:103) > at som.interpreter.nodes.ContextualNode.determineContext(ContextualNode.java:61) > > Now, the location in question, i.e., the frame slot, is used like this [1]: > > public Object getOuterSelf(final MaterializedFrame frame) { > return FrameUtil.getObjectSafe(frame, outerSelfSlot); > } > > And defined as `private final FrameSlot outerSelfSlot;` > > This reminds me of a change I did in March [2] based on Andreas? comment [3]. > But, now this problem seems to be back, and since I didn?t change anything in my code, but just updated Graal, it looks like there might be either a regression or an old problem exposed. > However, I don?t really see how I could get the frame slot ?even more constant? than what I have now. > Perhaps, I am reading the stack trace wrong, or there is something else going on? > > > > To reproduce, the following should give an up-to-date TruffleSOM (note the recursive git submodule checkout, core-lib probably needs an update if you got an older copy): > > git clone --recursive https://github.com/SOM-st/TruffleSOM.git > ant jar > ant test > ./graal.sh -cp Smalltalk Examples/Benchmarks/BenchmarkHarness.som TreeSort 100 0 100 > > Thanks > Stefan > > [1] https://github.com/SOM-st/TruffleSOM/blob/master/src/som/interpreter/nodes/literals/BlockNode.java#L67 > [2] https://github.com/SOM-st/TruffleSOM/commit/c002b9be8bbed2ecf0c7a3fce93f9c108563e73e > [3] http://markmail.org/message/ad7jd2ewopheqo2l > > > -- > Stefan Marr > INRIA Lille - Nord Europe > http://stefan-marr.de/research/ > > > -- Stefan Marr INRIA Lille - Nord Europe http://stefan-marr.de/research/ From doug.simon at oracle.com Tue May 27 01:00:06 2014 From: doug.simon at oracle.com (doug.simon at oracle.com) Date: Tue, 27 May 2014 01:00:06 +0000 Subject: hg: graal/graal: 18 new changesets Message-ID: <201405270100.s4R10Ugp016298@aojmv0008> Changeset: a7fd7fee9d40 Author: Josef Eisl Date: 2014-05-22 23:02 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/a7fd7fee9d40 LSRA: restrict access to IntervalWalker members. ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/alloc/IntervalWalker.java ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/alloc/LinearScanWalker.java Changeset: 5d734275cc5f Author: Josef Eisl Date: 2014-05-22 19:42 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/5d734275cc5f LSRA: make IntervalWalker.currentInterval private. ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/alloc/IntervalWalker.java ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/alloc/LinearScanWalker.java Changeset: 09f3fe273640 Author: Josef Eisl Date: 2014-05-22 20:36 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/09f3fe273640 LSRA: remove IntervalWalker.currentInterval and change the behavior of nextInterval and walkTo(int). ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/alloc/IntervalWalker.java Changeset: a9781031ecf1 Author: Gilles Duboscq Date: 2014-05-26 12:01 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/a9781031ecf1 mx: use python downloader if stderr is not a tty to avoid spamming logs ! mxtool/mx.py Changeset: 5f692474fba3 Author: Gilles Duboscq Date: 2014-05-26 12:03 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/5f692474fba3 hotspot eclipse project: add generated folders for client and server builds ! hotspot/.project Changeset: 7d1690e145ae Author: Roland Schatz Date: 2014-05-23 11:44 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/7d1690e145ae mx: option to force a GC after each unit test + graal/com.oracle.graal.test/src/com/oracle/graal/test/GCAfterTestDecorator.java ! graal/com.oracle.graal.test/src/com/oracle/graal/test/GraalJUnitCore.java ! mx/mx_graal.py Changeset: 70bb8df01b6e Author: Roland Schatz Date: 2014-05-23 17:21 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/70bb8df01b6e Allow signed values in Buffer.emit(Byte|Short). ! graal/com.oracle.graal.asm/src/com/oracle/graal/asm/Buffer.java Changeset: e43591136d9f Author: Roland Schatz Date: 2014-05-26 16:09 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/e43591136d9f Support for compressed constants. ! graal/com.oracle.graal.api.meta/src/com/oracle/graal/api/meta/Constant.java ! graal/com.oracle.graal.compiler.amd64/src/com/oracle/graal/compiler/amd64/AMD64LIRGenerator.java ! graal/com.oracle.graal.compiler.common/src/com/oracle/graal/compiler/common/type/StampFactory.java ! graal/com.oracle.graal.hotspot.amd64/src/com/oracle/graal/hotspot/amd64/AMD64HotSpotLIRGenerator.java ! graal/com.oracle.graal.hotspot.amd64/src/com/oracle/graal/hotspot/amd64/AMD64HotSpotMove.java ! graal/com.oracle.graal.hotspot.hsail/src/com/oracle/graal/hotspot/hsail/HSAILHotSpotLIRGenerator.java + graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotCompressedNullConstant.java + graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotConstant.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotConstantReflectionProvider.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotMetaAccessProvider.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotMetaspaceConstant.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotObjectConstant.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotSuitesProvider.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/phases/LoadJavaMirrorWithKlassPhase.java Changeset: 79a0d9065849 Author: Roland Schatz Date: 2014-05-26 16:13 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/79a0d9065849 Support direct comparison of compressed pointers. ! graal/com.oracle.graal.compiler.amd64/src/com/oracle/graal/compiler/amd64/AMD64LIRGenerator.java + graal/com.oracle.graal.hotspot.amd64/src/com/oracle/graal/hotspot/amd64/AMD64HotSpotCompare.java ! graal/com.oracle.graal.hotspot.amd64/src/com/oracle/graal/hotspot/amd64/AMD64HotSpotLIRGenerator.java ! graal/com.oracle.graal.lir.amd64/src/com/oracle/graal/lir/amd64/AMD64Compare.java Changeset: 03e09ed7039d Author: Roland Schatz Date: 2014-05-26 16:16 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/03e09ed7039d Use correct stamp when creating ConstantNode. ! graal/com.oracle.graal.compiler.common/src/com/oracle/graal/compiler/common/type/AbstractObjectStamp.java ! graal/com.oracle.graal.compiler.common/src/com/oracle/graal/compiler/common/type/FloatStamp.java ! graal/com.oracle.graal.compiler.common/src/com/oracle/graal/compiler/common/type/IllegalStamp.java ! graal/com.oracle.graal.compiler.common/src/com/oracle/graal/compiler/common/type/IntegerStamp.java ! graal/com.oracle.graal.compiler.common/src/com/oracle/graal/compiler/common/type/Stamp.java ! graal/com.oracle.graal.compiler.common/src/com/oracle/graal/compiler/common/type/VoidStamp.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/ConstantNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/calc/NarrowNode.java Changeset: c44f617fb8d7 Author: Roland Schatz Date: 2014-05-26 17:43 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/c44f617fb8d7 Optimize compare compressed pattern. ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/nodes/CompressionNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/calc/CompareNode.java Changeset: 67e0015b21d6 Author: Gilles Duboscq Date: 2014-05-26 18:18 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/67e0015b21d6 Use new jacocoreport version ! mx/mx_graal.py ! mx/projects Changeset: 88a6017687c9 Author: Josef Eisl Date: 2014-05-21 18:40 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/88a6017687c9 LSRA: fix getMaterializedValue() (respect MustHaveRegister priorities). ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/alloc/LinearScan.java Changeset: d1e9a44b14cc Author: Doug Simon Date: 2014-05-26 17:44 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/d1e9a44b14cc added more runtime initialization timers ! graal/com.oracle.graal.hotspot.amd64/src/com/oracle/graal/hotspot/amd64/AMD64HotSpotBackendFactory.java ! graal/com.oracle.graal.hotspot.ptx/src/com/oracle/graal/hotspot/ptx/PTXHotSpotBackendFactory.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/HotSpotGraalRuntime.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/bridge/VMToCompilerImpl.java Changeset: 6aa352b260f4 Author: Doug Simon Date: 2014-05-26 18:55 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/6aa352b260f4 removed use of ServiceLoader in runtime initialization + graal/com.oracle.graal.api.runtime/src/com/oracle/graal/api/runtime/Service.java + graal/com.oracle.graal.api.runtime/src/com/oracle/graal/api/runtime/Services.java + graal/com.oracle.graal.hotspot.codegen/src/com/oracle/graal/hotspot/codegen/GenGraalRuntimeInlineHpp.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/HotSpotBackendFactory.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/HotSpotGraalRuntime.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/HotSpotHostBackend.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/HotSpotOptionsLoader.java ! graal/com.oracle.graal.phases/src/com/oracle/graal/phases/tiers/CompilerConfiguration.java ! graal/com.oracle.graal.phases/src/com/oracle/graal/phases/tiers/Suites.java ! mx/mx_graal.py ! mx/projects ! src/share/vm/graal/graalRuntime.cpp ! src/share/vm/graal/graalRuntime.hpp ! src/share/vm/prims/nativeLookup.cpp Changeset: 7c84f0ce7cae Author: Doug Simon Date: 2014-05-26 18:55 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/7c84f0ce7cae Merge. ! mx/mx_graal.py ! mx/projects Changeset: 2977687e6db0 Author: Doug Simon Date: 2014-05-26 19:54 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/2977687e6db0 fixed code generation error for debug builds ! graal/com.oracle.graal.hotspot.codegen/src/com/oracle/graal/hotspot/codegen/GenGraalRuntimeInlineHpp.java Changeset: 0bfce5328510 Author: Doug Simon Date: 2014-05-26 20:27 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/0bfce5328510 Merge. From duboscq at ssw.jku.at Tue May 27 13:48:48 2014 From: duboscq at ssw.jku.at (Gilles Duboscq) Date: Tue, 27 May 2014 15:48:48 +0200 Subject: Potential Graal Regression: The location argument could not be resolved to a constant. In-Reply-To: References: Message-ID: Hello Stefan, I had a look at your problem. >From what i can see the problem happens at this call stack: com.oracle.graal.truffle.FrameWithoutBoxing.getObjectUnsafe(FrameWithoutBoxing.java:84) com.oracle.graal.truffle.FrameWithoutBoxing.getObject(FrameWithoutBoxing.java:68) com.oracle.truffle.api.frame.FrameUtil.getObjectSafe(FrameUtil.java:38) som.interpreter.nodes.literals.BlockNode$BlockNodeWithContext.getOuterSelf(BlockNode.java:67) som.vmobjects.SBlock.getOuterSelf(SBlock.java:103) som.interpreter.nodes.ContextualNode.determineContext(ContextualNode.java:61) som.interpreter.nodes.NonLocalVariableNode$NonLocalVariableReadNode.doObject(NonLocalVariableNode.java:60) som.interpreter.nodes.NonLocalVariableNodeFactory$NonLocalVariableReadNodeFactory$NonLocalVariableReadObjectNode.executeGeneric(NonLocalVariableNodeFactory.java:513) som.interpreter.nodes.ExpressionNode.executeSObject(ExpressionNode.java:90) som.interpreter.nodes.FieldNode$FieldWriteNode.executeSelf(FieldNode.java:153) som.interpreter.nodes.FieldNode$FieldWriteNode.executeGeneric(FieldNode.java:145) som.interpreter.nodes.ArgumentInitializationNode.executeGeneric(ArgumentInitializationNode.java:24) som.interpreter.Invokable.execute(Invokable.java:33) com.oracle.graal.truffle.OptimizedCallTarget.callProxy(OptimizedCallTarget.java:186) com.oracle.graal.truffle.OptimizedCallTarget.callInlined(OptimizedCallTarget.java:234) com.oracle.graal.truffle.OptimizedDirectCallNode.callProxy(OptimizedDirectCallNode.java:63) com.oracle.graal.truffle.OptimizedDirectCallNode.call(OptimizedDirectCallNode.java:54) som.interpreter.nodes.specialized.AbstractIfMessageNode.doIfWithInlining(AbstractIfMessageNode.java:54) som.interpreter.nodes.specialized.IfTrueMessageNode.doIfTrueWithInlining(IfTrueMessageNode.java:21) som.interpreter.nodes.specialized.IfTrueMessageNodeFactory$IfTrueMessageBooleanSBlock0Node.executeGeneric(IfTrueMessageNodeFactory.java:275) som.interpreter.nodes.SequenceNode.executeGeneric(SequenceNode.java:37) som.interpreter.nodes.ArgumentInitializationNode.executeGeneric(ArgumentInitializationNode.java:24) som.interpreter.Invokable.execute(Invokable.java:33) com.oracle.graal.truffle.OptimizedCallTarget.callProxy(OptimizedCallTarget.java:186) com.oracle.graal.truffle.OptimizedCallTarget.callRoot(OptimizedCallTarget.java:272) ContextualNode.determineContext get a SBlock from the frame. Then the code gets a node (a BlockNodeWithContext) from this SBlock. Which in turn accesses the frame (in BlockNodeWithContext.getOuterSelf). But at this point the location can not be evaluated to a constant because all this access chain is rooted at the SBlock that was extracted from the frame and is not a constant. My changes make more devirtualization happen during partial evaluation and thus more inlining happens during partial evaluation. The problem is that before the frame.getObject call was not inlined in FrameUtil.getObjectSafe but now it is because of this additional devirtualization. Currently the partial evaluator enforces that accesses to FrameWithoutBoxing are done with a constant slot. I solved the problem by adding a @SlowPath to BlockNodeWithContext.getOuterSelf but i'm not sure how much it's a hack versus a proper solution. I think here the issue is around: - accesses to materialized frames (if i understand your code correctly, you're trying to access values in outer frames) - enforcing constant-foldable accesses to FrameWithoutBoxing - reaching non-constant Truffle Nodes in truffle compilations (the BlockNodeWithContext inside SBlock) This last point especially seems to be at odds with the Truffle philosophy about Nodes: they should always be constant-foldable when they reach the partial evaluator. However even without that last issue, your specific problem would still arise because of the first 2 points. Maybe someone who has better knowledge of these things in Truffle can give you a more detailed answer. -Gilles On Tue, May 27, 2014 at 12:45 AM, Stefan Marr wrote: > Hi Gilles: > > On 24 May 2014, at 16:45, Stefan Marr wrote: > >> Adopting the latest version of Graal, I am having trouble with failing optimization passes because of ?The location argument could not be resolved to a constant.? > > I think, my problem starts with one of your commits, most likely: http://hg.openjdk.java.net/graal/graal/rev/ef6b8d1898e6 > Well, actually that one doesn?t yield a working VM for me. > But the last good commit is: http://hg.openjdk.java.net/graal/graal/rev/a9f969e65b61 > Afterwards, I get the ?The location argument could not be resolved to a constant? issues described below. > And http://hg.openjdk.java.net/graal/graal/rev/fa66540676ce is definitely broken. > > Thanks > Stefan > >> >> For all case I investigated so far, I get a stack trace like the following: >> >> at com.oracle.graal.truffle.FrameWithoutBoxing.getObjectUnsafe(FrameWithoutBoxing.java:84) >> at com.oracle.graal.truffle.FrameWithoutBoxing.getObject(FrameWithoutBoxing.java:68) >> at com.oracle.truffle.api.frame.FrameUtil.getObjectSafe(FrameUtil.java:38) >> at som.interpreter.nodes.literals.BlockNode$BlockNodeWithContext.getOuterSelf(BlockNode.java:67) >> at som.vmobjects.SBlock.getOuterSelf(SBlock.java:103) >> at som.interpreter.nodes.ContextualNode.determineContext(ContextualNode.java:61) >> >> Now, the location in question, i.e., the frame slot, is used like this [1]: >> >> public Object getOuterSelf(final MaterializedFrame frame) { >> return FrameUtil.getObjectSafe(frame, outerSelfSlot); >> } >> >> And defined as `private final FrameSlot outerSelfSlot;` >> >> This reminds me of a change I did in March [2] based on Andreas? comment [3]. >> But, now this problem seems to be back, and since I didn?t change anything in my code, but just updated Graal, it looks like there might be either a regression or an old problem exposed. >> However, I don?t really see how I could get the frame slot ?even more constant? than what I have now. >> Perhaps, I am reading the stack trace wrong, or there is something else going on? >> >> >> >> To reproduce, the following should give an up-to-date TruffleSOM (note the recursive git submodule checkout, core-lib probably needs an update if you got an older copy): >> >> git clone --recursive https://github.com/SOM-st/TruffleSOM.git >> ant jar >> ant test >> ./graal.sh -cp Smalltalk Examples/Benchmarks/BenchmarkHarness.som TreeSort 100 0 100 >> >> Thanks >> Stefan >> >> [1] https://github.com/SOM-st/TruffleSOM/blob/master/src/som/interpreter/nodes/literals/BlockNode.java#L67 >> [2] https://github.com/SOM-st/TruffleSOM/commit/c002b9be8bbed2ecf0c7a3fce93f9c108563e73e >> [3] http://markmail.org/message/ad7jd2ewopheqo2l >> >> >> -- >> Stefan Marr >> INRIA Lille - Nord Europe >> http://stefan-marr.de/research/ >> >> >> > > -- > Stefan Marr > INRIA Lille - Nord Europe > http://stefan-marr.de/research/ > > > From duboscq at ssw.jku.at Tue May 27 14:05:23 2014 From: duboscq at ssw.jku.at (Gilles Duboscq) Date: Tue, 27 May 2014 16:05:23 +0200 Subject: Potential Graal Regression: The location argument could not be resolved to a constant. In-Reply-To: References: Message-ID: On Tue, May 27, 2014 at 3:48 PM, Gilles Duboscq wrote: > Hello Stefan, > > I had a look at your problem. > From what i can see the problem happens at this call stack: > > com.oracle.graal.truffle.FrameWithoutBoxing.getObjectUnsafe(FrameWithoutBoxing.java:84) > com.oracle.graal.truffle.FrameWithoutBoxing.getObject(FrameWithoutBoxing.java:68) > com.oracle.truffle.api.frame.FrameUtil.getObjectSafe(FrameUtil.java:38) > som.interpreter.nodes.literals.BlockNode$BlockNodeWithContext.getOuterSelf(BlockNode.java:67) > som.vmobjects.SBlock.getOuterSelf(SBlock.java:103) > som.interpreter.nodes.ContextualNode.determineContext(ContextualNode.java:61) > som.interpreter.nodes.NonLocalVariableNode$NonLocalVariableReadNode.doObject(NonLocalVariableNode.java:60) > som.interpreter.nodes.NonLocalVariableNodeFactory$NonLocalVariableReadNodeFactory$NonLocalVariableReadObjectNode.executeGeneric(NonLocalVariableNodeFactory.java:513) > som.interpreter.nodes.ExpressionNode.executeSObject(ExpressionNode.java:90) > som.interpreter.nodes.FieldNode$FieldWriteNode.executeSelf(FieldNode.java:153) > som.interpreter.nodes.FieldNode$FieldWriteNode.executeGeneric(FieldNode.java:145) > som.interpreter.nodes.ArgumentInitializationNode.executeGeneric(ArgumentInitializationNode.java:24) > som.interpreter.Invokable.execute(Invokable.java:33) > com.oracle.graal.truffle.OptimizedCallTarget.callProxy(OptimizedCallTarget.java:186) > com.oracle.graal.truffle.OptimizedCallTarget.callInlined(OptimizedCallTarget.java:234) > com.oracle.graal.truffle.OptimizedDirectCallNode.callProxy(OptimizedDirectCallNode.java:63) > com.oracle.graal.truffle.OptimizedDirectCallNode.call(OptimizedDirectCallNode.java:54) > som.interpreter.nodes.specialized.AbstractIfMessageNode.doIfWithInlining(AbstractIfMessageNode.java:54) > som.interpreter.nodes.specialized.IfTrueMessageNode.doIfTrueWithInlining(IfTrueMessageNode.java:21) > som.interpreter.nodes.specialized.IfTrueMessageNodeFactory$IfTrueMessageBooleanSBlock0Node.executeGeneric(IfTrueMessageNodeFactory.java:275) > som.interpreter.nodes.SequenceNode.executeGeneric(SequenceNode.java:37) > som.interpreter.nodes.ArgumentInitializationNode.executeGeneric(ArgumentInitializationNode.java:24) > som.interpreter.Invokable.execute(Invokable.java:33) > com.oracle.graal.truffle.OptimizedCallTarget.callProxy(OptimizedCallTarget.java:186) > com.oracle.graal.truffle.OptimizedCallTarget.callRoot(OptimizedCallTarget.java:272) > > ContextualNode.determineContext get a SBlock from the frame. > Then the code gets a node (a BlockNodeWithContext) from this SBlock. > Which in turn accesses the frame (in BlockNodeWithContext.getOuterSelf). > But at this point the location can not be evaluated to a constant > because all this access chain is rooted at the SBlock that was > extracted from the frame and is not a constant. > > My changes make more devirtualization happen during partial evaluation > and thus more inlining happens during partial evaluation. > The problem is that before the frame.getObject call was not inlined in > FrameUtil.getObjectSafe but now it is because of this additional > devirtualization. > > Currently the partial evaluator enforces that accesses to > FrameWithoutBoxing are done with a constant slot. > > I solved the problem by adding a @SlowPath to > BlockNodeWithContext.getOuterSelf but i'm not sure how much it's a > hack versus a proper solution. I think here the issue is around: > - accesses to materialized frames (if i understand your code > correctly, you're trying to access values in outer frames) > - enforcing constant-foldable accesses to FrameWithoutBoxing > - reaching non-constant Truffle Nodes in truffle compilations (the > BlockNodeWithContext inside SBlock) > > This last point especially seems to be at odds with the Truffle > philosophy about Nodes: they should always be constant-foldable when > they reach the partial evaluator. > However even without that last issue, your specific problem would > still arise because of the first 2 points. > > Maybe someone who has better knowledge of these things in Truffle can > give you a more detailed answer. I talked with Thomas and Andreas and the conclusion was that we should relax the assertions around FrameWithoutBoxing or even CompilerDirectives.unsafeGet/Put... in general, those should rather be performance warnings than assertions. The separate issue of the BlockNodeWithContext inside SBlock remains though. > > -Gilles > > On Tue, May 27, 2014 at 12:45 AM, Stefan Marr wrote: >> Hi Gilles: >> >> On 24 May 2014, at 16:45, Stefan Marr wrote: >> >>> Adopting the latest version of Graal, I am having trouble with failing optimization passes because of ?The location argument could not be resolved to a constant.? >> >> I think, my problem starts with one of your commits, most likely: http://hg.openjdk.java.net/graal/graal/rev/ef6b8d1898e6 >> Well, actually that one doesn?t yield a working VM for me. >> But the last good commit is: http://hg.openjdk.java.net/graal/graal/rev/a9f969e65b61 >> Afterwards, I get the ?The location argument could not be resolved to a constant? issues described below. >> And http://hg.openjdk.java.net/graal/graal/rev/fa66540676ce is definitely broken. >> >> Thanks >> Stefan >> >>> >>> For all case I investigated so far, I get a stack trace like the following: >>> >>> at com.oracle.graal.truffle.FrameWithoutBoxing.getObjectUnsafe(FrameWithoutBoxing.java:84) >>> at com.oracle.graal.truffle.FrameWithoutBoxing.getObject(FrameWithoutBoxing.java:68) >>> at com.oracle.truffle.api.frame.FrameUtil.getObjectSafe(FrameUtil.java:38) >>> at som.interpreter.nodes.literals.BlockNode$BlockNodeWithContext.getOuterSelf(BlockNode.java:67) >>> at som.vmobjects.SBlock.getOuterSelf(SBlock.java:103) >>> at som.interpreter.nodes.ContextualNode.determineContext(ContextualNode.java:61) >>> >>> Now, the location in question, i.e., the frame slot, is used like this [1]: >>> >>> public Object getOuterSelf(final MaterializedFrame frame) { >>> return FrameUtil.getObjectSafe(frame, outerSelfSlot); >>> } >>> >>> And defined as `private final FrameSlot outerSelfSlot;` >>> >>> This reminds me of a change I did in March [2] based on Andreas? comment [3]. >>> But, now this problem seems to be back, and since I didn?t change anything in my code, but just updated Graal, it looks like there might be either a regression or an old problem exposed. >>> However, I don?t really see how I could get the frame slot ?even more constant? than what I have now. >>> Perhaps, I am reading the stack trace wrong, or there is something else going on? >>> >>> >>> >>> To reproduce, the following should give an up-to-date TruffleSOM (note the recursive git submodule checkout, core-lib probably needs an update if you got an older copy): >>> >>> git clone --recursive https://github.com/SOM-st/TruffleSOM.git >>> ant jar >>> ant test >>> ./graal.sh -cp Smalltalk Examples/Benchmarks/BenchmarkHarness.som TreeSort 100 0 100 >>> >>> Thanks >>> Stefan >>> >>> [1] https://github.com/SOM-st/TruffleSOM/blob/master/src/som/interpreter/nodes/literals/BlockNode.java#L67 >>> [2] https://github.com/SOM-st/TruffleSOM/commit/c002b9be8bbed2ecf0c7a3fce93f9c108563e73e >>> [3] http://markmail.org/message/ad7jd2ewopheqo2l >>> >>> >>> -- >>> Stefan Marr >>> INRIA Lille - Nord Europe >>> http://stefan-marr.de/research/ >>> >>> >>> >> >> -- >> Stefan Marr >> INRIA Lille - Nord Europe >> http://stefan-marr.de/research/ >> >> >> From java at stefan-marr.de Tue May 27 20:27:20 2014 From: java at stefan-marr.de (Stefan Marr) Date: Tue, 27 May 2014 22:27:20 +0200 Subject: Potential Graal Regression: The location argument could not be resolved to a constant. In-Reply-To: References: Message-ID: <33E15C67-ED42-4C21-91F6-669AE09DCC4B@stefan-marr.de> Hi Gilles, Hi Chris: On 27 May 2014, at 16:05, Gilles Duboscq wrote: > The separate issue of the BlockNodeWithContext inside SBlock remains though. Gilles, thanks for having a look. That helps a lot. Now I have an idea in which direction to look. And that brings me to my next question, Chris: In BlockNodeWithContext, I access the outer ?self? slot, which I need to traverse the chain of lexical contexts. In TruffleSOM, all arguments of method calls are directly copied into the frame objects to enable specialization via FrameSlots (see ArgumentInitializationNode and its usage). After that, I never access the arguments array anymore. To get access to the self slot in that design, I keep a reference to the corresponding node in the block object. Previously, I had the reference directly to the frame slot object, but that gave already issues because then it was not constant. Guess, changing the reference to the node was just hiding the problem, without solving it. Chris, a brief look at the Ruby implementation makes me belief that you do not do that for accessing the lexical chain. You are using the arguments array directly via RubyArguments.getDeclarationFrame(). Is that to avoid exactly the issue I got here? At the moment, I guess that?s the only solution that avoids the need of having access to the frame slot object. Thanks Stefan -- Stefan Marr INRIA Lille - Nord Europe http://stefan-marr.de/research/ From andreas.woess at jku.at Tue May 27 21:35:02 2014 From: andreas.woess at jku.at (Andreas Woess) Date: Tue, 27 May 2014 23:35:02 +0200 Subject: Potential Graal Regression: The location argument could not be resolved to a constant. In-Reply-To: <33E15C67-ED42-4C21-91F6-669AE09DCC4B@stefan-marr.de> References: <33E15C67-ED42-4C21-91F6-669AE09DCC4B@stefan-marr.de> Message-ID: <53850506.40706@jku.at> On 2014-05-27 22:27, Stefan Marr wrote: > Hi Gilles, > Hi Chris: > > On 27 May 2014, at 16:05, Gilles Duboscq wrote: > >> The separate issue of the BlockNodeWithContext inside SBlock remains though. > Gilles, thanks for having a look. That helps a lot. Now I have an idea in which direction to look. > > And that brings me to my next question, Chris: > > In BlockNodeWithContext, I access the outer ?self? slot, which I need to traverse the chain of lexical contexts. > In TruffleSOM, all arguments of method calls are directly copied into the frame objects to enable specialization via FrameSlots (see ArgumentInitializationNode and its usage). After that, I never access the arguments array anymore. > > To get access to the self slot in that design, I keep a reference to the corresponding node in the block object. > Previously, I had the reference directly to the frame slot object, but that gave already issues because then it was not constant. > Guess, changing the reference to the node was just hiding the problem, without solving it. Exactly. > Chris, a brief look at the Ruby implementation makes me belief that you do not do that for accessing the lexical chain. > You are using the arguments array directly via RubyArguments.getDeclarationFrame(). Is that to avoid exactly the issue I got here? > > At the moment, I guess that?s the only solution that avoids the need of having access to the frame slot object. I take it that you always have a self slot (and it's always the first)? In that case you could share the same FrameSlot instance across all methods by shallowCopy()-ing a FrameDescriptor with only the self slot and then adding your other slots to the copy. Accessing the arguments directly also avoids the issue (iff 'self' cannot be changed). - andreas From java at stefan-marr.de Tue May 27 22:01:09 2014 From: java at stefan-marr.de (Stefan Marr) Date: Wed, 28 May 2014 00:01:09 +0200 Subject: Potential Graal Regression: The location argument could not be resolved to a constant. In-Reply-To: <53850506.40706@jku.at> References: <33E15C67-ED42-4C21-91F6-669AE09DCC4B@stefan-marr.de> <53850506.40706@jku.at> Message-ID: <3936C67D-3DDE-4758-A6EE-E2A1EFA0A535@stefan-marr.de> Hi: On 27 May 2014, at 23:35, Andreas Woess wrote: > Accessing the arguments directly also avoids the issue (iff 'self' > cannot be changed). Finally! I think this issue was the main problem that was still holding back TruffleSOM performance. Especially the numerical benchmarks should now be on the same level as JRuby+Truffle. After changing the blocks to use the arguments array to get access to self, I see much better performance for most benchmarks. Don?t know whether I would have found that one without the error. Thanks a lot to everyone Stefan -- Stefan Marr INRIA Lille - Nord Europe http://stefan-marr.de/research/ From tom.deneau at amd.com Tue May 27 22:33:15 2014 From: tom.deneau at amd.com (Deneau, Tom) Date: Tue, 27 May 2014 22:33:15 +0000 Subject: node for hsail workitemabsid Message-ID: I would like to make a Node and @NodeIntrinsic that would generate the HSAIL instruction workitemabsid (the workitemabsid is a linear index unique for each workitem). So this takes no inputs and produces one output (int). What would be the best existing node for this to inherit from? -- Tom From chris at chrisseaton.com Wed May 28 00:18:31 2014 From: chris at chrisseaton.com (Chris Seaton) Date: Wed, 28 May 2014 01:18:31 +0100 Subject: Potential Graal Regression: The location argument could not be resolved to a constant. In-Reply-To: <33E15C67-ED42-4C21-91F6-669AE09DCC4B@stefan-marr.de> References: <33E15C67-ED42-4C21-91F6-669AE09DCC4B@stefan-marr.de> Message-ID: Did Andreas' answer give you everything you needed? I'll just specifically answer your questions about Ruby: I don't copy self into a frame slot - not sure why, it's just never occurred to me to do that as it's not mutable. Also I can't think of a situation where I'm doing any numerical computation with self except for the core library methods which are implemented in Java. Perhaps I should take a look at doing that so it gets specialised as you say. Since self is never in a frame slot I get it directly from the arguments array each time, as you say. When a block is defined (when we execute a block literal) I store self in the block object - RubyProc. When the block is called I call the CallTarget with that stored self instead of whatever self currently is. In order words, I never need to access outer self - the correct self is always just self. In some circumstances I call a block with another value for self (for some metaprogramming stuff). I think your approach might make this hard. Chris On 27 May 2014 21:27, Stefan Marr wrote: > Hi Gilles, > Hi Chris: > > On 27 May 2014, at 16:05, Gilles Duboscq wrote: > > > The separate issue of the BlockNodeWithContext inside SBlock remains > though. > > Gilles, thanks for having a look. That helps a lot. Now I have an idea in > which direction to look. > > And that brings me to my next question, Chris: > > In BlockNodeWithContext, I access the outer ?self? slot, which I need to > traverse the chain of lexical contexts. > In TruffleSOM, all arguments of method calls are directly copied into the > frame objects to enable specialization via FrameSlots (see > ArgumentInitializationNode and its usage). After that, I never access the > arguments array anymore. > > To get access to the self slot in that design, I keep a reference to the > corresponding node in the block object. > Previously, I had the reference directly to the frame slot object, but > that gave already issues because then it was not constant. > Guess, changing the reference to the node was just hiding the problem, > without solving it. > > Chris, a brief look at the Ruby implementation makes me belief that you do > not do that for accessing the lexical chain. > You are using the arguments array directly via > RubyArguments.getDeclarationFrame(). Is that to avoid exactly the issue I > got here? > > At the moment, I guess that?s the only solution that avoids the need of > having access to the frame slot object. > > Thanks > Stefan > > > -- > Stefan Marr > INRIA Lille - Nord Europe > http://stefan-marr.de/research/ > > > > From doug.simon at oracle.com Wed May 28 01:00:06 2014 From: doug.simon at oracle.com (doug.simon at oracle.com) Date: Wed, 28 May 2014 01:00:06 +0000 Subject: hg: graal/graal: 23 new changesets Message-ID: <201405280100.s4S10bT9017024@aojmv0008> Changeset: 4b835260c746 Author: Josef Eisl Date: 2014-05-27 10:22 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/4b835260c746 backout 88a6017687c9 ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/alloc/LinearScan.java Changeset: 6d8c901814eb Author: Roland Schatz Date: 2014-05-27 12:08 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/6d8c901814eb Support for compressed constants in HSAIL backend. ! graal/com.oracle.graal.hotspot.hsail/src/com/oracle/graal/hotspot/hsail/HSAILHotSpotLIRGenerator.java Changeset: 2022366b513c Author: Bernhard Urban Date: 2014-05-27 12:14 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/2022366b513c mx: add verbose mode to download helper ! mxtool/URLConnectionDownload.java ! mxtool/mx.py Changeset: d0c7bd38e700 Author: Bernhard Urban Date: 2014-05-27 12:15 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/d0c7bd38e700 computeBlockOrder: no need to check if block is active, since it's anyway ! graal/com.oracle.graal.java/src/com/oracle/graal/java/BciBlockMapping.java Changeset: 48b85f37e03b Author: Bernhard Urban Date: 2014-05-27 13:04 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/48b85f37e03b BciBlockMapping: allocate smaller array if possible ! graal/com.oracle.graal.java/src/com/oracle/graal/java/BciBlockMapping.java Changeset: 674d4065e9fb Author: Bernhard Urban Date: 2014-05-27 13:16 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/674d4065e9fb mxtool: remove python downloader ! mxtool/mx.py Changeset: af0e42dad358 Author: Doug Simon Date: 2014-05-27 15:43 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/af0e42dad358 reduced time to initialize ForeignCallProviders by avoiding triggering class initialization of Node subclasses as well as making annotation parsing lazy in SnippetInfo ! graal/com.oracle.graal.hotspot.amd64/src/com/oracle/graal/hotspot/amd64/AMD64HotSpotForeignCallsProvider.java ! graal/com.oracle.graal.hotspot.amd64/src/com/oracle/graal/hotspot/amd64/AMD64HotSpotLIRGenerator.java ! graal/com.oracle.graal.hotspot.sparc/src/com/oracle/graal/hotspot/sparc/SPARCHotSpotLIRGenerator.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/HotSpotBackend.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotHostForeignCallsProvider.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/nodes/NewArrayStubCall.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/nodes/NewInstanceStubCall.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/nodes/NewMultiArrayStubCall.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/nodes/UncommonTrapCallNode.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/nodes/VMErrorNode.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/AESCryptSubstitutions.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/CipherBlockChainingSubstitutions.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/MonitorSnippets.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/stubs/DeoptimizationStub.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/stubs/ExceptionHandlerStub.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/stubs/NewArrayStub.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/stubs/NewInstanceStub.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/stubs/SnippetStub.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/stubs/StubUtil.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/stubs/UncommonTrapStub.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/stubs/UnwindExceptionToCallerStub.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/stubs/VerifyOopStub.java + graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/java/ForeignCallDescriptors.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/java/RegisterFinalizerNode.java ! graal/com.oracle.graal.replacements/src/com/oracle/graal/replacements/SnippetTemplate.java ! src/share/vm/graal/graalVMToCompiler.hpp ! src/share/vm/oops/instanceKlass.cpp Changeset: 96229f219351 Author: Josef Eisl Date: 2014-05-26 09:29 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/96229f219351 LSRA: add OptimizingLinearScanWalker. ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/alloc/LinearScan.java ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/alloc/LinearScanWalker.java + graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/alloc/OptimizingLinearScanWalker.java Changeset: 9c209d76d72d Author: Josef Eisl Date: 2014-05-26 09:32 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/9c209d76d72d LSRA Optimization: walk basic block boundaries. ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/alloc/OptimizingLinearScanWalker.java Changeset: 8da4ff90fb7f Author: Josef Eisl Date: 2014-05-26 11:47 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/8da4ff90fb7f LSRA Optimization: add support for stack intervals. ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/alloc/Interval.java ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/alloc/IntervalWalker.java Changeset: 1ec990b3e556 Author: Josef Eisl Date: 2014-05-26 12:06 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/1ec990b3e556 LSRA optimization: add LinearScanWalker.handleSpillSlot(). ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/alloc/LinearScanWalker.java Changeset: 5e22e6a76ac7 Author: Josef Eisl Date: 2014-05-26 15:11 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/5e22e6a76ac7 LSRA: move stack intervals to active list. ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/alloc/IntervalWalker.java Changeset: 01e6f7caa9b7 Author: Josef Eisl Date: 2014-05-26 15:12 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/01e6f7caa9b7 LSRA optimization: add spilled intervals to unhandled list. ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/alloc/OptimizingLinearScanWalker.java Changeset: 0fdfff835128 Author: Josef Eisl Date: 2014-05-26 15:44 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/0fdfff835128 LSRA: add Interval.getIntervalCoveringOpId(int). ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/alloc/Interval.java Changeset: c73fad48e90d Author: Josef Eisl Date: 2014-05-26 16:35 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/c73fad48e90d LSRA: skip handled intervals in IntervalWalker.updateUnhandledStackIntervals(int). ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/alloc/IntervalWalker.java Changeset: 705fe382e2da Author: Josef Eisl Date: 2014-05-26 16:57 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/705fe382e2da LSRA optimization: check if optimization is feasible. ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/alloc/OptimizingLinearScanWalker.java Changeset: 94ea3f60a65a Author: Josef Eisl Date: 2014-05-26 19:21 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/94ea3f60a65a LSRA optimization: split intervals at block boundaries. ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/alloc/OptimizingLinearScanWalker.java Changeset: e5b1e4babf59 Author: Josef Eisl Date: 2014-05-27 15:25 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/e5b1e4babf59 LSRA optimization: assign location to intervals. ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/alloc/LinearScanWalker.java ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/alloc/OptimizingLinearScanWalker.java Changeset: db7313f9add8 Author: Josef Eisl Date: 2014-05-27 16:27 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/db7313f9add8 LSRA optimization: activate by default. ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/alloc/OptimizingLinearScanWalker.java Changeset: efc5afa0f5b3 Author: Doug Simon Date: 2014-05-27 21:20 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/efc5afa0f5b3 added ${workspace}/com.oracle.graal.hotspot/src_gen/hotspot to include paths ! hotspot/.cproject Changeset: d676c4beeab8 Author: Doug Simon Date: 2014-05-27 22:00 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/d676c4beeab8 renamed project (and package) com.oracle.graal.hotspot.codegen to com.oracle.graal.hotspot.sourcegen - graal/com.oracle.graal.hotspot.codegen/src/com/oracle/graal/hotspot/codegen/GenGraalRuntimeInlineHpp.java + graal/com.oracle.graal.hotspot.sourcegen/src/com/oracle/graal/hotspot/sourcegen/GenGraalRuntimeInlineHpp.java ! mx/mx_graal.py ! mx/projects Changeset: b35b1dc75ec0 Author: Doug Simon Date: 2014-05-27 22:00 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/b35b1dc75ec0 added comments to explain the origin of generated sources ! src/share/vm/graal/graalRuntime.hpp ! src/share/vm/runtime/vmStructs.hpp Changeset: 5c73b162eec2 Author: Doug Simon Date: 2014-05-28 00:50 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/5c73b162eec2 reduced execution time of ReplacementsImple.registerSubstitutions() by deferring parsing of substitution classes until the first request for a substitute method is received ! graal/com.oracle.graal.compiler.hsail.test.infra/src/com/oracle/graal/compiler/hsail/test/infra/GraalKernelTester.java ! graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/GraalCompilerTest.java ! graal/com.oracle.graal.hotspot.hsail/src/com/oracle/graal/hotspot/hsail/HSAILHotSpotReplacementsImpl.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/HotSpotReplacementsImpl.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/CallSiteSubstitutions.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/HotSpotSubstitutions.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/spi/Replacements.java ! graal/com.oracle.graal.replacements.amd64/src/com/oracle/graal/replacements/amd64/AMD64Substitutions.java ! graal/com.oracle.graal.replacements/src/com/oracle/graal/replacements/BoxingSubstitutions.java ! graal/com.oracle.graal.replacements/src/com/oracle/graal/replacements/GraalMethodSubstitutions.java ! graal/com.oracle.graal.replacements/src/com/oracle/graal/replacements/ReplacementsImpl.java ! graal/com.oracle.graal.truffle.test/src/com/oracle/graal/truffle/test/ExactMathTest.java ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/TruffleReplacements.java From michael.haupt at oracle.com Wed May 28 07:25:36 2014 From: michael.haupt at oracle.com (Michael Haupt) Date: Wed, 28 May 2014 09:25:36 +0200 Subject: Truffle compilation problem Message-ID: Hi, in FastR, we're facing the problem shown below. The stack trace doesn't give away a particular location in the FastR sources - we're nevertheless looking at uses of HashMap. Still, it is somewhat odd that the trace ends with an R function (usually we were given traces that ended up somewhere in FastR node classes, which made it much easier to track the issue down). Best, Michael Exception occurred in scope: Truffle.CreateGraph.TruffleCache.TruffleCache.TruffleCache.TruffleCache.TruffleCache.TruffleCache.TruffleCache.TruffleCache.TruffleCache.TruffleCache.TruffleCache.TruffleCache.TruffleCache.TruffleCache.TruffleCache.TruffleCache.TruffleCache.TruffleCache.TruffleCache.TruffleCache.TruffleCache.TruffleCache.TruffleCache.InterceptException Context obj com.oracle.graal.nodes.util.GraphUtil$2: Found illegal recursive call to HotSpotMethod, must annotate such calls with @CompilerDirectives.SlowPath! Context obj com.oracle.graal.hotspot.meta.HotSpotMetaAccessProvider at 3a708380 Context obj HotSpotMethod Context obj com.oracle.graal.hotspot.meta.HotSpotMetaAccessProvider at 3a708380 Context obj HotSpotMethod Context obj com.oracle.graal.hotspot.meta.HotSpotMetaAccessProvider at 3a708380 Context obj HotSpotMethod Context obj com.oracle.graal.hotspot.meta.HotSpotMetaAccessProvider at 3a708380 Context obj HotSpotMethod Context obj com.oracle.graal.hotspot.meta.HotSpotMetaAccessProvider at 3a708380 Context obj HotSpotMethod Context obj com.oracle.graal.hotspot.meta.HotSpotMetaAccessProvider at 3a708380 Context obj HotSpotMethod Context obj com.oracle.graal.hotspot.meta.HotSpotMetaAccessProvider at 3a708380 Context obj HotSpotMethod Context obj com.oracle.graal.hotspot.meta.HotSpotMetaAccessProvider at 3a708380 Context obj HotSpotMethod Context obj com.oracle.graal.hotspot.meta.HotSpotMetaAccessProvider at 3a708380 Context obj HotSpotMethod Context obj com.oracle.graal.hotspot.meta.HotSpotMetaAccessProvider at 3a708380 Context obj HotSpotMethod Context obj com.oracle.graal.hotspot.meta.HotSpotMetaAccessProvider at 3a708380 Context obj HotSpotMethod Context obj com.oracle.graal.hotspot.meta.HotSpotMetaAccessProvider at 3a708380 Context obj HotSpotMethod Context obj com.oracle.graal.hotspot.meta.HotSpotMetaAccessProvider at 3a708380 Context obj HotSpotMethod(String, GenericsFactory)> Context obj com.oracle.graal.hotspot.meta.HotSpotMetaAccessProvider at 3a708380 Context obj HotSpotMethod(String, GenericsFactory)> Context obj com.oracle.graal.hotspot.meta.HotSpotMetaAccessProvider at 3a708380 Context obj HotSpotMethod(String, GenericsFactory)> Context obj com.oracle.graal.hotspot.meta.HotSpotMetaAccessProvider at 3a708380 Context obj HotSpotMethod Context obj com.oracle.graal.hotspot.meta.HotSpotMetaAccessProvider at 3a708380 Context obj HotSpotMethod Context obj com.oracle.graal.hotspot.meta.HotSpotMetaAccessProvider at 3a708380 Context obj HotSpotMethod Context obj com.oracle.graal.hotspot.meta.HotSpotMetaAccessProvider at 3a708380 Context obj HotSpotMethod Context obj com.oracle.graal.hotspot.meta.HotSpotMetaAccessProvider at 3a708380 Context obj HotSpotMethod Context obj com.oracle.graal.hotspot.meta.HotSpotMetaAccessProvider at 3a708380 Context obj HotSpotMethod Context obj com.oracle.graal.hotspot.meta.HotSpotMetaAccessProvider at 3a708380 Context obj HotSpotMethod Context obj com.oracle.graal.hotspot.meta.HotSpotMetaAccessProvider at 3a708380 Context obj HotSpotMethod Context obj StructuredGraph:43{function(g1, g2, op = euclidean) { ans <- matrix(0, HotSpotMethod} Use -G:+DumpOnError to enable dumping of graphs on this error Context obj Truffle [truffle] opt fail function(g1, g2, op = euclidean) { ans <- matrix(0 |Reason Found illegal recursive call to HotSpotMethod, must annotate such calls with @CompilerDirectives.SlowPath! -- Dr. Michael Haupt | Principal Member of Technical Staff Phone: +49 331 200 7277 | Fax: +49 331 200 7561 Oracle Labs Oracle Deutschland B.V. & Co. KG, Schiffbauergasse 14 | 14467 Potsdam, Germany Oracle is committed to developing practices and products that help protect the environment From chris at chrisseaton.com Wed May 28 07:59:20 2014 From: chris at chrisseaton.com (Chris Seaton) Date: Wed, 28 May 2014 08:59:20 +0100 Subject: Truffle compilation problem In-Reply-To: References: Message-ID: You're calling HashMap containsKey - can you try wrapping that call in SlowPath? I've had trouble in the past compiling some of the hash map methods. I put them all under SlowPath at the moment - also because they're generally very big to inline each time. Chris On Wednesday, 28 May 2014, Michael Haupt wrote: > Hi, > > in FastR, we're facing the problem shown below. The stack trace doesn't > give away a particular location in the FastR sources - we're nevertheless > looking at uses of HashMap. Still, it is somewhat odd that the trace ends > with an R function (usually we were given traces that ended up somewhere in > FastR node classes, which made it much easier to track the issue down). > > Best, > > Michael > > > > Exception occurred in scope: > Truffle.CreateGraph.TruffleCache.TruffleCache.TruffleCache.TruffleCache.TruffleCache.TruffleCache.TruffleCache.TruffleCache.TruffleCache.TruffleCache.TruffleCache.TruffleCache.TruffleCache.TruffleCache.TruffleCache.TruffleCache.TruffleCache.TruffleCache.TruffleCache.TruffleCache.TruffleCache.TruffleCache.TruffleCache.InterceptException > Context obj > com.oracle.graal.nodes.util.GraphUtil$2: Found illegal recursive call to > HotSpotMethod, must annotate > such calls with @CompilerDirectives.SlowPath! > Context obj > com.oracle.graal.hotspot.meta.HotSpotMetaAccessProvider at 3a708380 > Context obj > HotSpotMethod > Context obj > com.oracle.graal.hotspot.meta.HotSpotMetaAccessProvider at 3a708380 > Context obj > HotSpotMethod > Context obj > com.oracle.graal.hotspot.meta.HotSpotMetaAccessProvider at 3a708380 > Context obj > HotSpotMethod > Context obj > com.oracle.graal.hotspot.meta.HotSpotMetaAccessProvider at 3a708380 > Context obj > HotSpotMethod > Context obj > com.oracle.graal.hotspot.meta.HotSpotMetaAccessProvider at 3a708380 > Context obj > HotSpotMethod > Context obj > com.oracle.graal.hotspot.meta.HotSpotMetaAccessProvider at 3a708380 > Context obj > HotSpotMethod > Context obj > com.oracle.graal.hotspot.meta.HotSpotMetaAccessProvider at 3a708380 > Context obj > HotSpotMethod > Context obj > com.oracle.graal.hotspot.meta.HotSpotMetaAccessProvider at 3a708380 > Context obj > HotSpotMethod > Context obj > com.oracle.graal.hotspot.meta.HotSpotMetaAccessProvider at 3a708380 > Context obj > HotSpotMethod > Context obj > com.oracle.graal.hotspot.meta.HotSpotMetaAccessProvider at 3a708380 > Context obj > HotSpotMethod > Context obj > com.oracle.graal.hotspot.meta.HotSpotMetaAccessProvider at 3a708380 > Context obj > HotSpotMethod > Context obj > com.oracle.graal.hotspot.meta.HotSpotMetaAccessProvider at 3a708380 > Context obj > HotSpotMethod > Context obj > com.oracle.graal.hotspot.meta.HotSpotMetaAccessProvider at 3a708380 > Context obj > HotSpotMethod(String, GenericsFactory)> > Context obj > com.oracle.graal.hotspot.meta.HotSpotMetaAccessProvider at 3a708380 > Context obj > HotSpotMethod(String, GenericsFactory)> > Context obj > com.oracle.graal.hotspot.meta.HotSpotMetaAccessProvider at 3a708380 > Context obj > HotSpotMethod(String, GenericsFactory)> > Context obj > com.oracle.graal.hotspot.meta.HotSpotMetaAccessProvider at 3a708380 > Context obj > HotSpotMethod > Context obj > com.oracle.graal.hotspot.meta.HotSpotMetaAccessProvider at 3a708380 > Context obj > HotSpotMethod > Context obj > com.oracle.graal.hotspot.meta.HotSpotMetaAccessProvider at 3a708380 > Context obj > HotSpotMethod > Context obj > com.oracle.graal.hotspot.meta.HotSpotMetaAccessProvider at 3a708380 > Context obj > HotSpotMethod > Context obj > com.oracle.graal.hotspot.meta.HotSpotMetaAccessProvider at 3a708380 > Context obj > HotSpotMethod > Context obj > com.oracle.graal.hotspot.meta.HotSpotMetaAccessProvider at 3a708380 > Context obj > HotSpotMethod > Context obj > com.oracle.graal.hotspot.meta.HotSpotMetaAccessProvider at 3a708380 > Context obj > HotSpotMethod > Context obj > com.oracle.graal.hotspot.meta.HotSpotMetaAccessProvider at 3a708380 > Context obj > HotSpotMethod > Context obj > StructuredGraph:43{function(g1, g2, op = euclidean) > { > ans <- matrix(0, HotSpotMethod} > Use -G:+DumpOnError > to enable dumping of graphs on this error > Context obj > Truffle { > ans_<-_matrix(0()> > [truffle] opt fail function(g1, g2, op = euclidean) > { > ans <- matrix(0 |Reason Found illegal recursive call to > HotSpotMethod, must annotate > such calls with @CompilerDirectives.SlowPath! > > > > -- > > > Dr. Michael Haupt | Principal Member of Technical Staff > Phone: +49 331 200 7277 | Fax: +49 331 200 7561 > Oracle Labs > Oracle Deutschland B.V. & Co. KG, Schiffbauergasse 14 | 14467 Potsdam, > Germany > Oracle is committed to developing practices and products that help > protect the environment > > From michael.haupt at oracle.com Wed May 28 12:39:47 2014 From: michael.haupt at oracle.com (Michael Haupt) Date: Wed, 28 May 2014 14:39:47 +0200 Subject: Truffle compilation problem In-Reply-To: References: Message-ID: <13FFB42B-0BF2-4FA7-A4B7-563A3096DC40@oracle.com> Hi Chris, Am 28.05.2014 um 09:59 schrieb Chris Seaton : > You're calling HashMap containsKey - can you try wrapping that call in SlowPath? well, in all of our code there is only *one* such call, and that is made during library loading, i.e., before compilation should even bother kicking in. The compilation is also not one of any of the library functions, but one of an application function. This was part of my question: where in our code could this call originate? The stack trace ends with the containsKey() call, and I cannot trace that back to any of the FastR sources. > I've had trouble in the past compiling some of the hash map methods. I put them all under SlowPath at the moment - also because they're generally very big to inline each time. That may be a worthwhile strategy ... still, I wonder where the problem actually is. Best, Michael -- Dr. Michael Haupt | Principal Member of Technical Staff Phone: +49 331 200 7277 | Fax: +49 331 200 7561 Oracle Labs Oracle Deutschland B.V. & Co. KG, Schiffbauergasse 14 | 14467 Potsdam, Germany Oracle is committed to developing practices and products that help protect the environment From java at stefan-marr.de Wed May 28 13:21:36 2014 From: java at stefan-marr.de (Stefan Marr) Date: Wed, 28 May 2014 15:21:36 +0200 Subject: [Truffle] Loop count propagation Message-ID: Hi Chris: While skimming through your JRuby changes I saw something I haven?t noticed before: Pass loop counts up to the first call target for a method that is not a block. https://github.com/jruby/jruby/commit/74934f06299f896170e37cd538c594f6dd27fb35 What?s the idea behind that change? I don?t know enough about the corresponding compiler heuristics, so, it is not directly obvious to me why you propagate the loop count up to the enclosing methods. If a method has a high loop count, does it mean it gets more attention by the optimizer? Or is the idea to move the start point, for where and when to optimizer stars optimizing, up to the outer lexical scope to avoid optimizing only inner blocks? I guess, if that would happen, these inner blocks would access the outer lexical scope and thereby crossing the boundary between units of optimization? Also, you added branch probability to your while nodes and if nodes, what kind of impact do you see for that? (one of the relevant commits was: Using CompilerDirectives.injectBranchProbability in the DoWhile nodes https://github.com/jruby/jruby/commit/3845bbb106313bf7c4b0624a7fe8ac71940708b4) Thanks Stefan -- Stefan Marr INRIA Lille - Nord Europe http://stefan-marr.de/research/ From chris.seaton at oracle.com Wed May 28 13:41:59 2014 From: chris.seaton at oracle.com (Chris Seaton) Date: Wed, 28 May 2014 14:41:59 +0100 Subject: [Truffle] Loop count propagation In-Reply-To: References: Message-ID: On 28 May 2014, at 14:21, Stefan Marr wrote: > While skimming through your JRuby changes I saw something I haven?t noticed before: > > Pass loop counts up to the first call target for a method that is not a block. > https://github.com/jruby/jruby/commit/74934f06299f896170e37cd538c594f6dd27fb35 > > What?s the idea behind that change? I don?t know enough about the corresponding compiler heuristics, so, it is not directly obvious to me why you propagate the loop count up to the enclosing methods. This change greatly improved warmup time and generated fewer compiled methods. I?ll illustrate using JavaScript, to avoid any confusion about Ruby or SmallTalk syntax and to make it more accessible to other people reading this: The loop construct in Ruby is a method call that you pass a block to. It?s implemented like this: function loop(body) { while (true) { body(); } } And used like this: function foo() { loop(function() { ... }) } Normally Truffle would compile the function that I pass to loop after enough iterations, and then compile loop separately. It won?t compile foo unless that is called enough times. I?d prefer that it just compile foo straight away - if you had a JS-style while loop you wouldn?t just compile the body of the while loop, you?d compile the function that contained it, and this achieves the same thing, even though we have extra functions instead of statement blocks. To achieve that I pass the loop count to the first root node that isn?t a block (an anonymous function, in JS terms). I also pass it to all blocks in between, in case they can be compiled but the outer function can?t. > If a method has a high loop count, does it mean it gets more attention by the optimizer? > Or is the idea to move the start point, for where and when to optimizer stars optimizing, up to the outer lexical scope to avoid optimizing only inner blocks? I guess, if that would happen, these inner blocks would access the outer lexical scope and thereby crossing the boundary between units of optimisation? The idea is to move the starting point, as you say. There?s no tiered compilation in Graal (I believe) so it?s not about getting more attention, it?s just about what gets compiled. Also, creating the block object to pass to loop involves allocating an object and often materialising a frame. If I start compilation at a point earlier on the call stack I?m likely to inline both loop and the anonymous function, optimising away the allocation of the object and the materialisation of the frame. I don?t know how well this will apply to you, as you convert a call to while into a special while node, don?t you? So that means the loop count would already count for foo in your case I think? I don?t do that, so my call to loop and my call to the anonymous function are just normal calls for me and I need this special mechanism to pass the loop count up. > Also, you added branch probability to your while nodes and if nodes, what kind of impact do you see for that? > (one of the relevant commits was: Using CompilerDirectives.injectBranchProbability in the DoWhile nodes > https://github.com/jruby/jruby/commit/3845bbb106313bf7c4b0624a7fe8ac71940708b4) I can?t quantify any performance difference, but I just noticed they could be in there and put them in. At some point it might be a nice idea to turn off features and see what difference it makes. But I can tell you that when we wrote the DYLA paper we had to turn off BranchProfiles in IfNode because it was optimising away the breakpoint on our never-taken branch. You probably won?t find a benchmark that has dead code like that, so might be hard to illustrate. A more important use is in core library methods. Here in the Array#[]= method (assigning to an index in an array) I have branch profiles for the cases where the index is at the end, or beyond the end. This is almost always not needed, so we can usually remove it via a BranchProfile. https://github.com/jruby/jruby/blob/master/core/src/main/java/org/jruby/truffle/nodes/core/ArrayNodes.java#L616 Chris > Thanks > Stefan > > -- > Stefan Marr > INRIA Lille - Nord Europe > http://stefan-marr.de/research/ > > > From java at stefan-marr.de Wed May 28 13:58:13 2014 From: java at stefan-marr.de (Stefan Marr) Date: Wed, 28 May 2014 15:58:13 +0200 Subject: [Truffle] Loop count propagation In-Reply-To: References: Message-ID: Hi Chris: On 28 May 2014, at 15:41, Chris Seaton wrote: >> What?s the idea behind that change? I don?t know enough about the corresponding compiler heuristics, so, it is not directly obvious to me why you propagate the loop count up to the enclosing methods. > > This change greatly improved warmup time and generated fewer compiled methods. [...] > To achieve that I pass the loop count to the first root node that isn?t a block (an anonymous function, in JS terms). I also pass it to all blocks in between, in case they can be compiled but the outer function can?t. [...] > The idea is to move the starting point, as you say. There?s no tiered compilation in Graal (I believe) so it?s not about getting more attention, it?s just about what gets compiled. > > I don?t know how well this will apply to you, as you convert a call to while into a special while node, don?t you? So that means the loop count would already count for foo in your case I think? I don?t do that, so my call to loop and my call to the anonymous function are just normal calls for me and I need this special mechanism to pass the loop count up. Thanks. And yes, I think it still applies. One reason is that I do not copy loop bodies into the while nodes. They are still DirectCallNodes. Which is the same for all the control structures. I rely there entirely on the DirectCallNodes doing the right thing. So, propagating up the loop count seems to be a good idea to get warmup down. >> Also, you added branch probability to your while nodes and if nodes, what kind of impact do you see for that? >> (one of the relevant commits was: Using CompilerDirectives.injectBranchProbability in the DoWhile nodes >> https://github.com/jruby/jruby/commit/3845bbb106313bf7c4b0624a7fe8ac71940708b4) [...] > A more important use is in core library methods. Here in the Array#[]= method (assigning to an index in an array) I have branch profiles for the cases where the index is at the end, or beyond the end. This is almost always not needed, so we can usually remove it via a BranchProfile. Ok, well, those things are entirely in SOM. Only few operations are currently optimized/reimplemented. Not sure whether it is worthwhile to go further there, will see when I got the latest comparison numbers. Thanks for the explanation Stefan -- Stefan Marr INRIA Lille - Nord Europe http://stefan-marr.de/research/ From chris.seaton at oracle.com Wed May 28 14:05:16 2014 From: chris.seaton at oracle.com (Chris Seaton) Date: Wed, 28 May 2014 15:05:16 +0100 Subject: [Truffle] Loop count propagation In-Reply-To: References: Message-ID: On 28 May 2014, at 14:58, Stefan Marr wrote: > Ok, well, those things are entirely in SOM. Only few operations are currently optimized/reimplemented. > Not sure whether it is worthwhile to go further there, will see when I got the latest comparison numbers. You are probably better off keeping them in SOM if you can. I intend to move in that direction at some point. Some of my code is now Ruby code written as explicit ASTs. For example this is part of a method prelude, basically written as Ruby by manually creating nodes: https://github.com/jruby/jruby/blob/master/core/src/main/java/org/jruby/truffle/translator/MethodTranslator.java#L108-L115 Chris From tom.rodriguez at oracle.com Wed May 28 16:36:22 2014 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Wed, 28 May 2014 09:36:22 -0700 Subject: node for hsail workitemabsid In-Reply-To: References: Message-ID: It sounds like a trivial subclass of FloatingNode like CurrentJavaThreadNode. tom On May 27, 2014, at 3:33 PM, Deneau, Tom wrote: > I would like to make a Node and @NodeIntrinsic that would generate the HSAIL instruction workitemabsid > (the workitemabsid is a linear index unique for each workitem). > > So this takes no inputs and produces one output (int). > > What would be the best existing node for this to inherit from? > > -- Tom > > From tom.deneau at amd.com Wed May 28 20:47:52 2014 From: tom.deneau at amd.com (Deneau, Tom) Date: Wed, 28 May 2014 20:47:52 +0000 Subject: code optimized away before a deopt Message-ID: Dredging up this issue again, I still get burned by it occasionally in our snippets. The only workaround I have is to insert some test before the actual deopt and the test has to be something that the compiler can't optimize away. If I forget such a test, (or if the compiler optimizes it away), the fact that the side-effecting got discarded can cause situations that are difficult to debug. Just wondering if anything has happened since Novemeber to make this less error-prone. I agree with Doug a warning should be the minimum feedback. Or could we have some annotation or something that says in this snippet do not do the ConvertDeoptimizeToGuardPhase? -- Tom >> -----Original Message----- >> From: Doug Simon [mailto:doug.simon at oracle.com] >> Sent: Saturday, November 23, 2013 10:24 AM >> To: Lukas Stadler >> Cc: Deneau, Tom; graal-dev at openjdk.java.net >> Subject: Re: code optimized away before a deopt >> >> >> On Nov 23, 2013, at 5:18 PM, Lukas Stadler wrote: >> >>> But it _is_ ok to remove side effecting nodes, because we know they >> will be reelected. >> >> Yes, normally, but when you write this pattern in a snippet, then >> this won't be true right, since we don't resume execution in the >> bytecode of the snippet (yet!). That why I was thinking at least a >> warning would be a good idea. >> >> -Doug >> >>> Maybe the cleanup operations could be part of a special purpose >>> deopt >> node? >>> >>> - Lukas >>> >>> Von meinem iPhone gesendet >>> >>>> Am 23.11.2013 um 16:39 schrieb Doug Simon : >>>> >>>> This is done by the ConvertDeoptimizeToGuardPhase which replaces >> conditionals where one branch ends in a deopt with a GuardNode. This >> does indeed have the side effect of (silently) deleting all other >> nodes on that deopt-terminated branch. We should add some code to >> either make the deletion not silent or better, throw an error if >> these are any side- effecting nodes that will be deleted. >>>> >>>> -Doug >>>> >>>>> On Nov 23, 2013, at 1:58 AM, Deneau, Tom wrote: >>>>> >>>>> I've noticed that if I have a snippet that does a test and if the >> test fails, branches to a block that does some cleanup operations and >> then calls DeoptimizeNode.deopt(xxx, yyy), the cleanup code gets >> "optimized away". I guess this is related to what Gilles was talking >> about, maybe the cleanup operations were considered not state changing? >>>>> >>>>> In our current state of HSAIL backend, a deopt just returns early >> from the kernel. Is there something I can do to make the cleanup code >> get emitted before the deopt? >>>>> >>>>> -- Tom >>>> >> > > From doug.simon at oracle.com Thu May 29 01:00:06 2014 From: doug.simon at oracle.com (doug.simon at oracle.com) Date: Thu, 29 May 2014 01:00:06 +0000 Subject: hg: graal/graal: 29 new changesets Message-ID: <201405290100.s4T10i58029794@aojmv0008> Changeset: 14ac87c56a27 Author: Michael Van De Vanter Date: 2014-05-27 21:18 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/14ac87c56a27 Truffle: NPE guard in InstrumentationNode ! graal/com.oracle.truffle.api/src/com/oracle/truffle/api/instrument/impl/InstrumentationNode.java Changeset: eedf6c293639 Author: Michael Van De Vanter Date: 2014-05-27 21:18 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/eedf6c293639 Truffle: additional methods on ExecutionContext ! graal/com.oracle.truffle.api/src/com/oracle/truffle/api/ExecutionContext.java ! graal/com.oracle.truffle.api/src/com/oracle/truffle/api/instrument/impl/ProbeManager.java Changeset: 57303ce74a21 Author: Michael Van De Vanter Date: 2014-05-27 21:20 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/57303ce74a21 Merge with 5c73b162eec248fc2d06f59d8f25860871a21be5 Changeset: b2c18c498f13 Author: Roland Schatz Date: 2014-05-28 12:15 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/b2c18c498f13 Remove isCompressible flags from memory access nodes. ! graal/com.oracle.graal.hotspot.ptx/src/com/oracle/graal/hotspot/ptx/PTXWrapperBuilder.java ! graal/com.oracle.graal.hotspot.sparc/src/com/oracle/graal/hotspot/sparc/SPARCHotSpotLIRGenerator.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/debug/BenchmarkCounters.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/DefaultHotSpotLoweringProvider.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/HeapAccess.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/extended/AbstractWriteNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/extended/FixedAccessNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/extended/FloatableAccessNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/extended/FloatingAccessNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/extended/FloatingReadNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/extended/JavaReadNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/extended/JavaWriteNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/extended/ReadNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/extended/WriteNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/java/LoweredAtomicReadAndWriteNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/java/LoweredCompareAndSwapNode.java ! graal/com.oracle.graal.replacements/src/com/oracle/graal/replacements/DefaultJavaLoweringProvider.java Changeset: 3eedf7a653ea Author: Roland Schatz Date: 2014-05-28 12:16 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/3eedf7a653ea Remove unused oop compression code from backends. ! graal/com.oracle.graal.compiler.amd64/src/com/oracle/graal/compiler/amd64/AMD64LIRGenerator.java ! graal/com.oracle.graal.compiler.hsail/src/com/oracle/graal/compiler/hsail/HSAILLIRGenerator.java ! graal/com.oracle.graal.compiler.ptx/src/com/oracle/graal/compiler/ptx/PTXLIRGenerator.java ! graal/com.oracle.graal.compiler.sparc/src/com/oracle/graal/compiler/sparc/SPARCLIRGenerator.java ! graal/com.oracle.graal.hotspot.amd64/src/com/oracle/graal/hotspot/amd64/AMD64HotSpotLIRGenerator.java ! graal/com.oracle.graal.hotspot.amd64/src/com/oracle/graal/hotspot/amd64/AMD64HotSpotMove.java ! graal/com.oracle.graal.hotspot.hsail/src/com/oracle/graal/hotspot/hsail/HSAILHotSpotLIRGenerator.java ! graal/com.oracle.graal.hotspot.sparc/src/com/oracle/graal/hotspot/sparc/SPARCHotSpotLIRGenerator.java ! graal/com.oracle.graal.lir.hsail/src/com/oracle/graal/lir/hsail/HSAILMove.java ! graal/com.oracle.graal.lir.sparc/src/com/oracle/graal/lir/sparc/SPARCMove.java ! graal/com.oracle.graal.lir/src/com/oracle/graal/lir/gen/LIRGenerator.java ! graal/com.oracle.graal.lir/src/com/oracle/graal/lir/gen/LIRGeneratorTool.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/extended/WriteNode.java Changeset: 6abfac153606 Author: Roland Schatz Date: 2014-05-28 12:17 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/6abfac153606 Ensure values stay finite in block probability computation. ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/cfg/Block.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/cfg/ControlFlowGraph.java Changeset: 4243a6b8dd19 Author: Roland Schatz Date: 2014-05-28 12:17 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/4243a6b8dd19 Fix insertion of profile data in unit tests. ! graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/GraalCompilerTest.java Changeset: e4567f9acc42 Author: Roland Schatz Date: 2014-05-28 12:17 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/e4567f9acc42 Interface to do graph verification after High/Mid/LowTier in unittests. ! graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/GraalCompilerTest.java Changeset: aef229a61f96 Author: Lukas Stadler Date: 2014-05-28 17:14 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/aef229a61f96 grow NodeMaps exponentially ! graal/com.oracle.graal.graph.test/src/com/oracle/graal/graph/test/NodeMapTest.java ! graal/com.oracle.graal.graph/src/com/oracle/graal/graph/NodeMap.java Changeset: b7748fffea09 Author: Lukas Stadler Date: 2014-05-28 17:14 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/b7748fffea09 ignore transient fields in NodeClass ! graal/com.oracle.graal.compiler.common/src/com/oracle/graal/compiler/common/FieldIntrospection.java Changeset: a750e0d83535 Author: Lukas Stadler Date: 2014-05-28 17:14 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/a750e0d83535 cache last receiver stamp in MethodCallTargetNode ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/java/MethodCallTargetNode.java Changeset: cda2a7d1dcff Author: Lukas Stadler Date: 2014-05-28 17:19 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/cda2a7d1dcff long values and scale on DebugHistogram ! graal/com.oracle.graal.debug.test/src/com/oracle/graal/debug/test/DebugHistogramTest.java ! graal/com.oracle.graal.debug/src/com/oracle/graal/debug/DebugHistogram.java ! graal/com.oracle.graal.debug/src/com/oracle/graal/debug/internal/DebugHistogramAsciiPrinter.java ! graal/com.oracle.graal.debug/src/com/oracle/graal/debug/internal/DebugHistogramImpl.java Changeset: 3f48e9a1016c Author: Lukas Stadler Date: 2014-05-28 17:19 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/3f48e9a1016c NodeBitMap refactoring ! graal/com.oracle.graal.graph/src/com/oracle/graal/graph/Graph.java ! graal/com.oracle.graal.graph/src/com/oracle/graal/graph/NodeBitMap.java ! graal/com.oracle.graal.graph/src/com/oracle/graal/graph/NodeWorkList.java ! graal/com.oracle.graal.graph/src/com/oracle/graal/graph/iterators/DistinctPredicatedProxyNodeIterator.java ! graal/com.oracle.graal.loop/src/com/oracle/graal/loop/LoopFragment.java ! graal/com.oracle.graal.loop/src/com/oracle/graal/loop/LoopFragmentInside.java ! graal/com.oracle.graal.loop/src/com/oracle/graal/loop/LoopPolicies.java ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/LoweringPhase.java Changeset: edc33e8715d5 Author: Lukas Stadler Date: 2014-05-28 17:20 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/edc33e8715d5 NodeWorkList refactoring ! graal/com.oracle.graal.graph/src/com/oracle/graal/graph/Graph.java ! graal/com.oracle.graal.graph/src/com/oracle/graal/graph/NodeWorkList.java ! graal/com.oracle.graal.loop/src/com/oracle/graal/loop/LoopFragment.java ! graal/com.oracle.graal.loop/src/com/oracle/graal/loop/LoopFragmentInside.java ! graal/com.oracle.graal.loop/src/com/oracle/graal/loop/LoopFragmentInsideBefore.java ! graal/com.oracle.graal.loop/src/com/oracle/graal/loop/LoopFragmentInsideFrom.java ! graal/com.oracle.graal.loop/src/com/oracle/graal/loop/LoopFragmentWhole.java ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/CanonicalizerPhase.java Changeset: cf51d3ade2fb Author: Lukas Stadler Date: 2014-05-28 17:47 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/cf51d3ade2fb less canonicalization during InliningPhase ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/inlining/info/AbstractInlineInfo.java ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/inlining/info/AssumptionInlineInfo.java ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/inlining/info/ExactInlineInfo.java ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/inlining/info/InlineInfo.java ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/inlining/info/MultiTypeGuardInlineInfo.java ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/inlining/info/TypeGuardInlineInfo.java ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/inlining/info/elem/InlineableGraph.java ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/inlining/walker/InliningData.java Changeset: 8a39e009c142 Author: Lukas Stadler Date: 2014-05-28 17:47 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/8a39e009c142 IfNode refactorings ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/IfNode.java Changeset: 451a7e38ebce Author: Lukas Stadler Date: 2014-05-28 17:47 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/451a7e38ebce HotSpotResolvedJavaField refactorings ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotResolvedJavaField.java Changeset: da6941811da8 Author: Lukas Stadler Date: 2014-05-28 17:47 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/da6941811da8 fast path for IntegerStamp.meet ! graal/com.oracle.graal.compiler.common/src/com/oracle/graal/compiler/common/type/IntegerStamp.java Changeset: d5b824a41530 Author: Lukas Stadler Date: 2014-05-28 17:47 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/d5b824a41530 CompareNode refactorings ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/calc/CompareNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/calc/FloatEqualsNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/calc/FloatLessThanNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/calc/IntegerBelowThanNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/calc/IntegerEqualsNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/calc/IntegerLessThanNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/calc/ObjectEqualsNode.java Changeset: 7c7cfc44cc61 Author: Lukas Stadler Date: 2014-05-28 17:47 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/7c7cfc44cc61 fix WriteBarrierAdditionTest.test5 ! graal/com.oracle.graal.hotspot.test/src/com/oracle/graal/hotspot/test/WriteBarrierAdditionTest.java Changeset: a62590637801 Author: Lukas Stadler Date: 2014-05-28 18:44 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/a62590637801 track memory usage in TruffleCompilerImpl ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/TruffleCompilerImpl.java Changeset: 9d7b2134c4ce Author: Lukas Stadler Date: 2014-05-28 18:45 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/9d7b2134c4ce less canonicalization during Truffle partial evaluation ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/inlining/info/AbstractInlineInfo.java ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/PartialEvaluator.java Changeset: 272b64c1d65b Author: Doug Simon Date: 2014-05-28 14:07 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/272b64c1d65b do not count the memory allocated by ThreadMXBean.getThreadAllocatedBytes() ! graal/com.oracle.graal.debug/src/com/oracle/graal/debug/internal/MemUseTrackerImpl.java Changeset: 27ff0792b048 Author: Doug Simon Date: 2014-05-28 14:47 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/27ff0792b048 made more services implement com.oracle.graal.api.runtime.Service for faster loading ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/match/MatchProcessor.java ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/match/MatchRuleRegistry.java ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/match/MatchStatementSet.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/spi/ReplacementsProvider.java ! graal/com.oracle.graal.truffle.hotspot/src/com/oracle/graal/truffle/hotspot/HotSpotTruffleRuntime.java ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/OptimizedCallTargetInstrumentationFactory.java Changeset: 9a7803400ba7 Author: Doug Simon Date: 2014-05-28 15:51 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/9a7803400ba7 generate more efficient code for GraalRuntime::get_service_impls ! graal/com.oracle.graal.hotspot.sourcegen/src/com/oracle/graal/hotspot/sourcegen/GenGraalRuntimeInlineHpp.java Changeset: 42eaa579e134 Author: Doug Simon Date: 2014-05-28 17:41 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/42eaa579e134 more improvements to runtime initialization: - replaced HotSpotSymbol with native method for reading a symbol - moved more ForeignCallDescriptors to HotSpotBackend to reduce class initialization ! graal/com.oracle.graal.hotspot.amd64/src/com/oracle/graal/hotspot/amd64/AMD64HotSpotEnterUnpackFramesStackFrameOp.java ! graal/com.oracle.graal.hotspot.amd64/src/com/oracle/graal/hotspot/amd64/AMD64HotSpotLIRGenerator.java ! graal/com.oracle.graal.hotspot.amd64/src/com/oracle/graal/hotspot/amd64/AMD64HotSpotLeaveUnpackFramesStackFrameOp.java ! graal/com.oracle.graal.hotspot.sparc/src/com/oracle/graal/hotspot/sparc/SPARCHotSpotEnterUnpackFramesStackFrameOp.java ! graal/com.oracle.graal.hotspot.sparc/src/com/oracle/graal/hotspot/sparc/SPARCHotSpotLeaveUnpackFramesStackFrameOp.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/HotSpotBackend.java - graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/HotSpotSymbol.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/HotSpotVmSymbols.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/bridge/CompilerToVM.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/bridge/CompilerToVMImpl.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotConstantPool.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotHostForeignCallsProvider.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/nodes/DeoptimizationFetchUnrollInfoCallNode.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/nodes/EnterUnpackFramesStackFrameNode.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/nodes/LeaveUnpackFramesStackFrameNode.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/stubs/DeoptimizationStub.java ! graal/com.oracle.graal.replacements/src/com/oracle/graal/replacements/SnippetTemplate.java ! src/share/vm/graal/graalCompilerToVM.cpp Changeset: 5d0fbc245e55 Author: Doug Simon Date: 2014-05-28 21:17 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/5d0fbc245e55 Merge. Changeset: af95e5727fdc Author: Doug Simon Date: 2014-05-28 21:37 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/af95e5727fdc workaround for javac compiler error ! graal/com.oracle.graal.replacements/src/com/oracle/graal/replacements/SnippetTemplate.java Changeset: ef43e8c355ad Author: Doug Simon Date: 2014-05-28 22:27 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/ef43e8c355ad fixed declaration of fetchUnrollInfo foreign call descriptor ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/HotSpotBackend.java From juan.fumero at ed.ac.uk Thu May 29 09:52:40 2014 From: juan.fumero at ed.ac.uk (Juan Jose Fumero) Date: Thu, 29 May 2014 10:52:40 +0100 Subject: Substitutions in Graal Message-ID: <1401357160.28608.10.camel@gofio> Hi, after this merge [1] with my fork, I had to change the replacements from this registerSubstitutions(OCLMathSubstitutions.class); for this one: registerSubstitutions(Math.class, OCLMathSubstitutions.class); But, when I apply the replacements and inlining, the MatIntrinsics is still my graph. ... 114|MathIntrinsic 119|Const(0.31938154) 120|Const(-0.35656378) 121|Const(1.7814779) ... I want to substitute MathIntrinsic for OCLMathIntrinsic. With my previous version (merge with Graal 839cb35354e8 [2] ) it works. Any idea? Many thanks [1] http://hg.openjdk.java.net/graal/graal/rev/5c73b162eec2 [2] http://hg.openjdk.java.net/graal/graal/rev/839cb35354e8 -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: not available URL: From doug.simon at oracle.com Thu May 29 13:34:29 2014 From: doug.simon at oracle.com (Doug Simon) Date: Thu, 29 May 2014 15:34:29 +0200 Subject: Substitutions in Graal In-Reply-To: <1401357160.28608.10.camel@gofio> References: <1401357160.28608.10.camel@gofio> Message-ID: Hi Juan, What?s in OCLMathSubstitutions? Does it override substitutions provide by MathSubstitutionsX86? And where is your call to registerSubstitutions(Math.class, OCLMathSubstitutions.class)? In standard Graal, I don?t think we have a multiple substitutions for a single method so have never thought about which substitution takes precedence in the case of conflicts. -Doug On May 29, 2014, at 11:52 AM, Juan Jose Fumero wrote: > Hi, > > after this merge [1] with my fork, I had to change the replacements > from this > > registerSubstitutions(OCLMathSubstitutions.class); > > for this one: > > registerSubstitutions(Math.class, OCLMathSubstitutions.class); > > But, when I apply the replacements and inlining, the MatIntrinsics is > still my graph. > > ... > 114|MathIntrinsic > 119|Const(0.31938154) > 120|Const(-0.35656378) > 121|Const(1.7814779) > ... > > I want to substitute MathIntrinsic for OCLMathIntrinsic. > With my previous version (merge with Graal 839cb35354e8 [2] ) it works. > > Any idea? > > Many thanks > > > [1] http://hg.openjdk.java.net/graal/graal/rev/5c73b162eec2 > [2] http://hg.openjdk.java.net/graal/graal/rev/839cb35354e8 > > The University of Edinburgh is a charitable body, registered in > Scotland, with registration number SC005336. From java at stefan-marr.de Thu May 29 14:26:09 2014 From: java at stefan-marr.de (Stefan Marr) Date: Thu, 29 May 2014 16:26:09 +0200 Subject: [Truffle] Loop count propagation In-Reply-To: References: Message-ID: Hi Chris: On 28 May 2014, at 15:41, Chris Seaton wrote: > On 28 May 2014, at 14:21, Stefan Marr wrote: >> Pass loop counts up to the first call target for a method that is not a block. >> https://github.com/jruby/jruby/commit/74934f06299f896170e37cd538c594f6dd27fb35 > > This change greatly improved warmup time and generated fewer compiled methods. I?ll illustrate using JavaScript, to avoid any confusion about Ruby or SmallTalk syntax and to make it more accessible to other people reading this: This indeed has a good impact on warmup time for TruffleSOM as well. For DeltaBlue, warmup time was halved, I think. For the rest it might be even better. https://github.com/SOM-st/TruffleSOM/commit/e1a47e453f8d4e0db06d03f788d74fbe24763743 Just one more question, does the dynamic traversal of the stack in your solution in `reportLoopCountThroughBlocks()` give you additional benefits? I didn?t do it that way, but instead used only the static lexical context. Also, depending on how the block is used, if there is any kind of helper method in-between on your stack, the loop count won?t reach the outer method, I think. Best regards Stefan -- Stefan Marr INRIA Lille - Nord Europe http://stefan-marr.de/research/ From chris.seaton at oracle.com Thu May 29 14:42:32 2014 From: chris.seaton at oracle.com (Chris Seaton) Date: Thu, 29 May 2014 15:42:32 +0100 Subject: [Truffle] Loop count propagation In-Reply-To: References: Message-ID: > On 28 May 2014, at 15:41, Chris Seaton wrote: > >> On 28 May 2014, at 14:21, Stefan Marr wrote: >>> Pass loop counts up to the first call target for a method that is not a block. >>> https://github.com/jruby/jruby/commit/74934f06299f896170e37cd538c594f6dd27fb35 >> >> This change greatly improved warmup time and generated fewer compiled methods. I?ll illustrate using JavaScript, to avoid any confusion about Ruby or SmallTalk syntax and to make it more accessible to other people reading this: > > This indeed has a good impact on warmup time for TruffleSOM as well. For DeltaBlue, warmup time was halved, I think. For the rest it might be even better. > https://github.com/SOM-st/TruffleSOM/commit/e1a47e453f8d4e0db06d03f788d74fbe24763743 > > Just one more question, does the dynamic traversal of the stack in your solution in `reportLoopCountThroughBlocks()` give you additional benefits? I didn?t do it that way, but instead used only the static lexical context. Doing it lexically is a very interesting idea. Might you have some strange interactions if a block is defined in one method, then stored somewhere and called from somewhere else? Would it help the method it was lexically defined in be compiled, when it might be being used by some unrelated method? Using JS again: function foo() { return function() { ... } } x = foo() function bar() { loop(x) } bar() Will that cause foo to be compiled, when we?d rather bar was? Also, if your method is an invokable, which is a root node, what happens when a root node is cloned for splitting and inlining? Does that leave methods referring to the old copy of the method in their LexicalContext? I did it dynamically because what inspired me to do it was the new stack trace API, which suddenly have my access to the stack of call nodes. > Also, depending on how the block is used, if there is any kind of helper method in-between on your stack, the loop count won?t reach the outer method, I think. Yes, that?s true. Not sure what to do about that. Chris From java at stefan-marr.de Thu May 29 15:07:37 2014 From: java at stefan-marr.de (Stefan Marr) Date: Thu, 29 May 2014 17:07:37 +0200 Subject: [Truffle] Loop count propagation In-Reply-To: References: Message-ID: <2E5CE733-F154-4B89-8BB5-6B582896A964@stefan-marr.de> Hi Chris: On 29 May 2014, at 16:42, Chris Seaton wrote: > Might you have some strange interactions if a block is defined in one method, then stored somewhere and called from somewhere else? Good question. I think, none of the benchmarks I have do that. So, I probably won?t optimize for that. However, another interesting scenario is to pass a block/lambda to some method, which then uses it repeatedly. This seems to be pretty often the case in Smalltalk, with internal iteration etc. I guess, it could help to propagate the call count of blocks to their outer method in those cases, to increase the chances that the outer method gets compiled, and access to materialized frames gets compiled away. Or to make sure they get compiled as early as possible. > Would it help the method it was lexically defined in be compiled, when it might be being used by some unrelated method? Using JS again: > > function foo() { > return function() { > ... > } > } > > x = foo() > > function bar() { > loop(x) > } > > bar() > > Will that cause foo to be compiled, when we?d rather bar was? In your example, I am not sure why bar would need to be compiled. As long as x is properly compiled. In SOM, I would however worry that x, i.e. your lambda uses a materialize frame. And, since I always capture self, and I think I almost always need it, for error reporting, I am not sure I can be smart in the compiler here to avoid creating a materialized frame. > Also, if your method is an invokable, which is a root node, what happens when a root node is cloned for splitting and inlining? Does that leave methods referring to the old copy of the method in their LexicalContext? When a method is split for inlining, all lexical enclosed blocks are split as well. You need that to enable them to specialize their frame access in the new method. And, in the same way, they all get their proper lexical context. [That is done by Inliner [1], and replaceWithIndependentCopyForInlining(.)]. >> Also, depending on how the block is used, if there is any kind of helper method in-between on your stack, the loop count won?t reach the outer method, I think. > > Yes, that?s true. Not sure what to do about that. I guess, it might also depend on which kind of usages are most common for lambdas. So, don?t know which approach is preferable. It is probably also language-dependent. Best regards Stefan -- Stefan Marr INRIA Lille - Nord Europe http://stefan-marr.de/research/ From juan.fumero at ed.ac.uk Thu May 29 15:48:27 2014 From: juan.fumero at ed.ac.uk (Juan Jose Fumero) Date: Thu, 29 May 2014 16:48:27 +0100 Subject: Substitutions in Graal In-Reply-To: References: <1401357160.28608.10.camel@gofio> Message-ID: <1401378507.28608.25.camel@gofio> Hi Doug, In our OpenCL backend we created the OCLMath class with basically returns a float and double of Java maths operations. So, instead of using Math.log for example, the user writes OCLMath.log . But, in order to be this implementation legal from Java code, OCLMath is actually a wrapper that calls to Math.* methods. public class OCLMath { public static float fabs(float a) { return Math.abs(a); } .... } And then our OCLMathSubstitution @ClassSubstitution(com.edinburgh.opencl.math.OCLMath.class) public class OCLMathSubstitutions { @MethodSubstitution public static float fabs(float x) { return OCLMathIntrinsicNode.compute(x, Operation.FABS); } ... This approach is quite similar to HSAIL. My register substitution inherits from ReplacementImpl class. public class OCLHotSpotReplacementsImpl extends ReplacementsImpl { public OCLHotSpotReplacementsImpl(Providers providers, SnippetReflectionProvider snippetReflection, Assumptions assumptions, TargetDescription target) { super(providers, snippetReflection, assumptions, target); registerSubstitutions(Math.class, OCLMathSubstitutions.class); } Thanks Juanjo On Thu, 2014-05-29 at 15:34 +0200, Doug Simon wrote: > Hi Juan, > > What?s in OCLMathSubstitutions? Does it override substitutions provide by MathSubstitutionsX86? > > And where is your call to registerSubstitutions(Math.class, OCLMathSubstitutions.class)? > > In standard Graal, I don?t think we have a multiple substitutions for a single method so have never thought about which substitution takes precedence in the case of conflicts. > > -Doug > > On May 29, 2014, at 11:52 AM, Juan Jose Fumero wrote: > > > Hi, > > > > after this merge [1] with my fork, I had to change the replacements > > from this > > > > registerSubstitutions(OCLMathSubstitutions.class); > > > > for this one: > > > > registerSubstitutions(Math.class, OCLMathSubstitutions.class); > > > > But, when I apply the replacements and inlining, the MatIntrinsics is > > still my graph. > > > > ... > > 114|MathIntrinsic > > 119|Const(0.31938154) > > 120|Const(-0.35656378) > > 121|Const(1.7814779) > > ... > > > > I want to substitute MathIntrinsic for OCLMathIntrinsic. > > With my previous version (merge with Graal 839cb35354e8 [2] ) it works. > > > > Any idea? > > > > Many thanks > > > > > > [1] http://hg.openjdk.java.net/graal/graal/rev/5c73b162eec2 > > [2] http://hg.openjdk.java.net/graal/graal/rev/839cb35354e8 > > > > The University of Edinburgh is a charitable body, registered in > > Scotland, with registration number SC005336. > > -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: not available URL: From tom.deneau at amd.com Thu May 29 18:53:33 2014 From: tom.deneau at amd.com (Deneau, Tom) Date: Thu, 29 May 2014 18:53:33 +0000 Subject: loop peeling in snippets Message-ID: If we have a snippet we are compiling for the HSAIL backend which contains while loops and we don't want loop peeling, is there a way to turn that optimization off for snippets only? -- Tom From doug.simon at oracle.com Thu May 29 19:43:16 2014 From: doug.simon at oracle.com (Doug Simon) Date: Thu, 29 May 2014 21:43:16 +0200 Subject: loop peeling in snippets In-Reply-To: References: Message-ID: <8243EFB8-3F9D-4647-A692-D922A3070BF6@oracle.com> Apart from exploding loops based on explicit use of ExplodeLoopNode, we don?t do any loop peeling within snippets as far as I?m aware. What snippet are you writing and what problem are you trying to address? -Doug On May 29, 2014, at 8:53 PM, Deneau, Tom wrote: > If we have a snippet we are compiling for the HSAIL backend which contains while loops and we don't want loop peeling, is there a way to turn that optimization off for snippets only? > > -- Tom From doug.simon at oracle.com Thu May 29 19:50:13 2014 From: doug.simon at oracle.com (Doug Simon) Date: Thu, 29 May 2014 21:50:13 +0200 Subject: Substitutions in Graal In-Reply-To: <1401378507.28608.25.camel@gofio> References: <1401357160.28608.10.camel@gofio> <1401378507.28608.25.camel@gofio> Message-ID: <9448ADAE-58CF-411C-BBFB-88D677E627FB@oracle.com> On May 29, 2014, at 5:48 PM, Juan Jose Fumero wrote: > Hi Doug, > In our OpenCL backend we created the OCLMath class with basically returns a float and double of Java maths operations. So, instead of using > Math.log for example, the user writes OCLMath.log . > > But, in order to be this implementation legal from Java code, OCLMath is actually a wrapper that calls to Math.* methods. > > > public class OCLMath { > > public static float fabs(float a) { > return Math.abs(a); > } > .... > > } > > > And then our OCLMathSubstitution > > @ClassSubstitution(com.edinburgh.opencl.math.OCLMath.class) > public class OCLMathSubstitutions { > > @MethodSubstitution > public static float fabs(float x) { > return OCLMathIntrinsicNode.compute(x, Operation.FABS); > } > ... > > > This approach is quite similar to HSAIL. > > > My register substitution inherits from ReplacementImpl class. > > public class OCLHotSpotReplacementsImpl extends ReplacementsImpl { > > public OCLHotSpotReplacementsImpl(Providers providers, SnippetReflectionProvider snippetReflection, Assumptions assumptions, TargetDescription target) { > super(providers, snippetReflection, assumptions, target); > registerSubstitutions(Math.class, OCLMathSubstitutions.class); This above line should be: registerSubstitutions(OCLMath.class, OCLMathSubstitutions.class); You want to register substitutions for OCLMath, not Math. If you run with -esa enabled, this assert on ReplacementsImpl.java:322 should fire: assert getOriginalInternalName(substitutionClass).equals(internalName) : getOriginalInternalName(substitutionClass) + " != " + (internalName); -Doug > On Thu, 2014-05-29 at 15:34 +0200, Doug Simon wrote: >> Hi Juan, >> >> What?s in OCLMathSubstitutions? Does it override substitutions provide by MathSubstitutionsX86? >> >> And where is your call to registerSubstitutions(Math.class, OCLMathSubstitutions.class)? >> >> In standard Graal, I don?t think we have a multiple substitutions for a single method so have never thought about which substitution takes precedence in the case of conflicts. >> >> -Doug >> >> On May 29, 2014, at 11:52 AM, Juan Jose Fumero < >> juan.fumero at ed.ac.uk >> > wrote: >> >> >> > Hi, >> > >> > after this merge [1] with my fork, I had to change the replacements >> > from this >> > >> > registerSubstitutions(OCLMathSubstitutions.class); >> > >> > for this one: >> > >> > registerSubstitutions(Math.class, OCLMathSubstitutions.class); >> > >> > But, when I apply the replacements and inlining, the MatIntrinsics is >> > still my graph. >> > >> > ... >> > 114|MathIntrinsic >> > 119|Const(0.31938154) >> > 120|Const(-0.35656378) >> > 121|Const(1.7814779) >> > ... >> > >> > I want to substitute MathIntrinsic for OCLMathIntrinsic. >> > With my previous version (merge with Graal 839cb35354e8 [2] ) it works. >> > >> > Any idea? >> > >> > Many thanks >> > >> > >> > [1] http://hg.openjdk.java.net/graal/graal/rev/5c73b162eec2 >> > [2] http://hg.openjdk.java.net/graal/graal/rev/839cb35354e8 >> > >> > The University of Edinburgh is a charitable body, registered in >> > Scotland, with registration number SC005336. >> >> >> >> > > The University of Edinburgh is a charitable body, registered in > Scotland, with registration number SC005336. From tom.deneau at amd.com Thu May 29 20:20:12 2014 From: tom.deneau at amd.com (Deneau, Tom) Date: Thu, 29 May 2014 20:20:12 +0000 Subject: loop peeling in snippets In-Reply-To: <8243EFB8-3F9D-4647-A692-D922A3070BF6@oracle.com> References: <8243EFB8-3F9D-4647-A692-D922A3070BF6@oracle.com> Message-ID: OK I thought I saw peeling but let me look at it more closely. I'm working on an extension of the HSAIL allocation snippets to allow them to grab a new tlab when the current tlab is full. -- Tom > -----Original Message----- > From: Doug Simon [mailto:doug.simon at oracle.com] > Sent: Thursday, May 29, 2014 2:43 PM > To: Deneau, Tom > Cc: graal-dev at openjdk.java.net > Subject: Re: loop peeling in snippets > > Apart from exploding loops based on explicit use of ExplodeLoopNode, we > don't do any loop peeling within snippets as far as I'm aware. What > snippet are you writing and what problem are you trying to address? > > -Doug > > On May 29, 2014, at 8:53 PM, Deneau, Tom wrote: > > > If we have a snippet we are compiling for the HSAIL backend which > contains while loops and we don't want loop peeling, is there a way to > turn that optimization off for snippets only? > > > > -- Tom From doug.simon at oracle.com Fri May 30 01:00:06 2014 From: doug.simon at oracle.com (doug.simon at oracle.com) Date: Fri, 30 May 2014 01:00:06 +0000 Subject: hg: graal/graal: 8 new changesets Message-ID: <201405300100.s4U10Ht1023679@aojmv0008> Changeset: 6ee370b4d452 Author: Michael Van De Vanter Date: 2014-05-28 20:33 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/6ee370b4d452 Truffle/Instrumentation: Javadoc correction ! graal/com.oracle.truffle.api/src/com/oracle/truffle/api/source/SourceFactory.java Changeset: b048110014ff Author: Michael Van De Vanter Date: 2014-05-28 20:36 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/b048110014ff Merge with ef43e8c355ade5ed058a5496f6e51ff4af66f0c0 - graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/HotSpotSymbol.java Changeset: 3a537502f40f Author: Doug Simon Date: 2014-05-29 16:12 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/3a537502f40f HSAIL: prevent failure to loaded native Okra library from causing unit test failure Contributed-by: Eric Caspole ! graal/com.oracle.graal.compiler.hsail.test.infra/src/com/oracle/graal/compiler/hsail/test/infra/GraalKernelTester.java ! graal/com.oracle.graal.compiler.hsail.test.infra/src/com/oracle/graal/compiler/hsail/test/infra/KernelTester.java Changeset: 0ad889977080 Author: Gilles Duboscq Date: 2014-05-29 14:44 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/0ad889977080 CompareNode.canonicalizeSymmetricConstant can lead to float<->int changes so the right type of node needs to be created depending on the inputs ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/calc/FloatEqualsNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/calc/FloatLessThanNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/calc/IntegerBelowThanNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/calc/IntegerEqualsNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/calc/IntegerLessThanNode.java Changeset: 1dcc7ae72723 Author: Gilles Duboscq Date: 2014-05-26 13:43 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/1dcc7ae72723 InvokeNode: getAnnotation is dangerous ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/InvokeNode.java Changeset: eff84c561a95 Author: Gilles Duboscq Date: 2014-05-29 16:58 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/eff84c561a95 Fix AMD64Assembler.testl ! graal/com.oracle.graal.asm.amd64/src/com/oracle/graal/asm/amd64/AMD64Assembler.java ! graal/com.oracle.graal.lir.amd64/src/com/oracle/graal/lir/amd64/AMD64TestMemoryOp.java Changeset: 3a4bc0f70625 Author: Tom Rodriguez Date: 2014-05-29 11:19 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/3a4bc0f70625 construct proper LocationNode for LoweredCompareAndSwap ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/java/CompareAndSwapNode.java ! graal/com.oracle.graal.replacements/src/com/oracle/graal/replacements/DefaultJavaLoweringProvider.java ! graal/com.oracle.graal.replacements/src/com/oracle/graal/replacements/UnsafeSubstitutions.java Changeset: 73a0c8e14cd1 Author: Tom Rodriguez Date: 2014-05-29 11:20 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/73a0c8e14cd1 delete unused histogram ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/calc/CompareNode.java From juan.fumero at ed.ac.uk Fri May 30 09:19:32 2014 From: juan.fumero at ed.ac.uk (Juan Jose Fumero) Date: Fri, 30 May 2014 10:19:32 +0100 Subject: Substitutions in Graal In-Reply-To: <9448ADAE-58CF-411C-BBFB-88D677E627FB@oracle.com> References: <1401357160.28608.10.camel@gofio> <1401378507.28608.25.camel@gofio> <9448ADAE-58CF-411C-BBFB-88D677E627FB@oracle.com> Message-ID: <1401441572.28608.27.camel@gofio> Hi Doug, Ok you are right. It works now. Thanks Juanjo On Thu, 2014-05-29 at 21:50 +0200, Doug Simon wrote: > On May 29, 2014, at 5:48 PM, Juan Jose Fumero wrote: > > > Hi Doug, > > In our OpenCL backend we created the OCLMath class with basically returns a float and double of Java maths operations. So, instead of using > > Math.log for example, the user writes OCLMath.log . > > > > But, in order to be this implementation legal from Java code, OCLMath is actually a wrapper that calls to Math.* methods. > > > > > > public class OCLMath { > > > > public static float fabs(float a) { > > return Math.abs(a); > > } > > .... > > > > } > > > > > > And then our OCLMathSubstitution > > > > @ClassSubstitution(com.edinburgh.opencl.math.OCLMath.class) > > public class OCLMathSubstitutions { > > > > @MethodSubstitution > > public static float fabs(float x) { > > return OCLMathIntrinsicNode.compute(x, Operation.FABS); > > } > > ... > > > > > > This approach is quite similar to HSAIL. > > > > > > My register substitution inherits from ReplacementImpl class. > > > > public class OCLHotSpotReplacementsImpl extends ReplacementsImpl { > > > > public OCLHotSpotReplacementsImpl(Providers providers, SnippetReflectionProvider snippetReflection, Assumptions assumptions, TargetDescription target) { > > super(providers, snippetReflection, assumptions, target); > > registerSubstitutions(Math.class, OCLMathSubstitutions.class); > > This above line should be: > > registerSubstitutions(OCLMath.class, OCLMathSubstitutions.class); > > You want to register substitutions for OCLMath, not Math. If you run with -esa enabled, this assert on ReplacementsImpl.java:322 should fire: > > assert getOriginalInternalName(substitutionClass).equals(internalName) : getOriginalInternalName(substitutionClass) + " != " + (internalName); > > -Doug > > > On Thu, 2014-05-29 at 15:34 +0200, Doug Simon wrote: > >> Hi Juan, > >> > >> What?s in OCLMathSubstitutions? Does it override substitutions provide by MathSubstitutionsX86? > >> > >> And where is your call to registerSubstitutions(Math.class, OCLMathSubstitutions.class)? > >> > >> In standard Graal, I don?t think we have a multiple substitutions for a single method so have never thought about which substitution takes precedence in the case of conflicts. > >> > >> -Doug > >> > >> On May 29, 2014, at 11:52 AM, Juan Jose Fumero < > >> juan.fumero at ed.ac.uk > >> > wrote: > >> > >> > >> > Hi, > >> > > >> > after this merge [1] with my fork, I had to change the replacements > >> > from this > >> > > >> > registerSubstitutions(OCLMathSubstitutions.class); > >> > > >> > for this one: > >> > > >> > registerSubstitutions(Math.class, OCLMathSubstitutions.class); > >> > > >> > But, when I apply the replacements and inlining, the MatIntrinsics is > >> > still my graph. > >> > > >> > ... > >> > 114|MathIntrinsic > >> > 119|Const(0.31938154) > >> > 120|Const(-0.35656378) > >> > 121|Const(1.7814779) > >> > ... > >> > > >> > I want to substitute MathIntrinsic for OCLMathIntrinsic. > >> > With my previous version (merge with Graal 839cb35354e8 [2] ) it works. > >> > > >> > Any idea? > >> > > >> > Many thanks > >> > > >> > > >> > [1] http://hg.openjdk.java.net/graal/graal/rev/5c73b162eec2 > >> > [2] http://hg.openjdk.java.net/graal/graal/rev/839cb35354e8 > >> > > >> > The University of Edinburgh is a charitable body, registered in > >> > Scotland, with registration number SC005336. > >> > >> > >> > >> > > > > The University of Edinburgh is a charitable body, registered in > > Scotland, with registration number SC005336. > > -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: not available URL: From java at stefan-marr.de Fri May 30 19:51:03 2014 From: java at stefan-marr.de (Stefan Marr) Date: Fri, 30 May 2014 21:51:03 +0200 Subject: [TruffleDSL] Splitting and Cost of Generic Nodes Message-ID: <1AEB5093-457E-4D8A-9B2C-63F3ABF89267@stefan-marr.de> Hi: I am debugging splitting issues in TruffleSOM and found two things, I would like to ask for comments on. The first thing is one of the splitting conditions: OptimizedDirectCallNode.java:191 // max one child call and callCount > 2 and kind of small number of nodes if (isMaxSingleCall()) { return true; } In which cases would it be useful to split such methods? For TruffleSOM, this condition causes plenty of issues with microbenchmarks, because it leads to unconditional splitting and the resulting trees do not stabilize. I have the feeling this should be restricted to methods that contain at least polymorphic nodes and that seems to be covered by the condition afterwards. The second issue I have is the semantics of @Generic specializations. Now, it implies a megamorphic cost for nodes, which has an impact on splitting. For me, Generic can also be just a field access that reads or stores objects, because that is the most generic case, but, does not imply that the node ever saw something other than objects. So, I wonder whether it would be useful to be able to define a cost parameter for the @Generic annotation, in order to be able to influence the cost of the resulting nodes? Thanks Stefan -- Stefan Marr INRIA Lille - Nord Europe http://stefan-marr.de/research/ From tom.rodriguez at oracle.com Fri May 30 20:20:31 2014 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Fri, 30 May 2014 13:20:31 -0700 Subject: code optimized away before a deopt In-Reply-To: References: Message-ID: <363CC5AD-79F9-4DD1-9A97-E7EF64467CD9@oracle.com> On May 28, 2014, at 1:47 PM, Deneau, Tom wrote: > Dredging up this issue again, I still get burned by it occasionally in our snippets. > The only workaround I have is to insert some test before the actual deopt > and the test has to be something that the compiler can't optimize away. > If I forget such a test, (or if the compiler optimizes it away), the fact > that the side-effecting got discarded can cause situations that are difficult > to debug. > > Just wondering if anything has happened since Novemeber to make this less error-prone. > I agree with Doug a warning should be the minimum feedback. I have some changes that assert when a side effecting node is eliminated by ConvertDeoptimizeToGuardPhase during snippet preparation but I have to make some other changes because it?s unhappy about some assertion logic in one of the snippets. We can see if this assert makes sense in practice. I guess I was surprised that there weren?t more complaints from existing code but I haven?t run it through the gate yet so maybe there are more. I?ll push it once I get the assertion issue fixed. This doesn?t really solve your problem though since it will now complain when something gets eliminated but you still have no way to keep it from being eliminated. Maybe you could handle it by doing some late lowering to expand the problematic control flow during LOW_TIER lowering? tom > > Or could we have some annotation or something that says in this snippet do not > do the ConvertDeoptimizeToGuardPhase? > > -- Tom > > > >>> -----Original Message----- >>> From: Doug Simon [mailto:doug.simon at oracle.com] >>> Sent: Saturday, November 23, 2013 10:24 AM >>> To: Lukas Stadler >>> Cc: Deneau, Tom; graal-dev at openjdk.java.net >>> Subject: Re: code optimized away before a deopt >>> >>> >>> On Nov 23, 2013, at 5:18 PM, Lukas Stadler wrote: >>> >>>> But it _is_ ok to remove side effecting nodes, because we know they >>> will be reelected. >>> >>> Yes, normally, but when you write this pattern in a snippet, then >>> this won't be true right, since we don't resume execution in the >>> bytecode of the snippet (yet!). That why I was thinking at least a >>> warning would be a good idea. >>> >>> -Doug >>> >>>> Maybe the cleanup operations could be part of a special purpose >>>> deopt >>> node? >>>> >>>> - Lukas >>>> >>>> Von meinem iPhone gesendet >>>> >>>>> Am 23.11.2013 um 16:39 schrieb Doug Simon : >>>>> >>>>> This is done by the ConvertDeoptimizeToGuardPhase which replaces >>> conditionals where one branch ends in a deopt with a GuardNode. This >>> does indeed have the side effect of (silently) deleting all other >>> nodes on that deopt-terminated branch. We should add some code to >>> either make the deletion not silent or better, throw an error if >>> these are any side- effecting nodes that will be deleted. >>>>> >>>>> -Doug >>>>> >>>>>> On Nov 23, 2013, at 1:58 AM, Deneau, Tom wrote: >>>>>> >>>>>> I've noticed that if I have a snippet that does a test and if the >>> test fails, branches to a block that does some cleanup operations and >>> then calls DeoptimizeNode.deopt(xxx, yyy), the cleanup code gets >>> "optimized away". I guess this is related to what Gilles was talking >>> about, maybe the cleanup operations were considered not state changing? >>>>>> >>>>>> In our current state of HSAIL backend, a deopt just returns early >>> from the kernel. Is there something I can do to make the cleanup code >>> get emitted before the deopt? >>>>>> >>>>>> -- Tom >>>>> >>> >> >> > > From tom.deneau at amd.com Fri May 30 20:30:49 2014 From: tom.deneau at amd.com (Deneau, Tom) Date: Fri, 30 May 2014 20:30:49 +0000 Subject: regression for compressed oops that require shift and add Message-ID: All -- I have noticed a regression when I update to the latest default tip. This is in the area of compressed pointers. We typically run with different heap sizes which force different compression schemes. The failure is in the scheme where the 32-bit compressed pointer must be multiplied by 8 and then add a base, we get this for example with a max heap size of 31g. The problem is that the shift and add must only be applied if the original compressed oop is not 0. Previous codegen (good): ld_global_s32 $s1, [$d1 + 16]; cvt_u64_u32 $d1, $s1; cmp_eq_b1_u64 $c0, $d1, 0x0; mad_u64 $d1, $d1, 8, 0x7fb447fff000; // $d1 = $d1 * 8 + base cmov_b64 $d1, $c0, 0x0, $d1; // conditionally make $d1 0 if it was originally 0 Current codegen (bad); ld_global_s32 $s1, [$d1 + 16]; cvt_u64_u32 $d1, $s1; mad_u64 $d1, $d1, 8, 0x7f0137fff000; The other compression schemes seem to work ok. I confess I had not merged with default for a few weeks so my previous working version was based on default 8d0242a07f7e. But I'm not sure where the regression happened in between there. I guess you would not notice this in your gate unless you ran with a heap size big enough to cause this kind of compression. -- Tom From christian.humer at gmail.com Fri May 30 20:39:04 2014 From: christian.humer at gmail.com (Christian Humer) Date: Fri, 30 May 2014 22:39:04 +0200 Subject: [TruffleDSL] Splitting and Cost of Generic Nodes In-Reply-To: <1AEB5093-457E-4D8A-9B2C-63F3ABF89267@stefan-marr.de> References: <1AEB5093-457E-4D8A-9B2C-63F3ABF89267@stefan-marr.de> Message-ID: Hi Stefan, Unfortunately splitting has still some major issues (as you recognized). The current version splits way too much (independent of polymorphism) and can also have some exponential code duplication problems under bad conditions. However it should stabilize at some point (may be late). But this should only be a problem on bigger benchmarks not on micro-benchmarks. So maybe there is another issue here. Can you point me to such a micro? I am working on a fix for splitting for a longer time already, but was not able to finish it for the previous release. I hope that I am able to finish it for the next Truffle release. The only workaround at the moment that I can suggest is to disable the splitting heuristic (-G:-TruffleSplittingEnabled) and to do crucial splits manually for the moment using the call node API. @Generic is the wrong name for this annotation. In the next iteration of the DSL this annotation is going to be renamed to @Fallback. There are not much use-cases for @Generic besides erronous and unexpected cases because its representation is inherently slow. The reason for this is that it always uses the generic case to represent your operation. This means that not just the handler in the method annotated with @Generic but also all specializations are used to represent your operation. You can see the full behaviour in the generated executeGeneric0 method. This is also why this node is associated with megamorphic costs. The next iteration is going to make @Fallback handler faster, but still not fast enough to use it for important cases. So the solution I recommend is to use @Specialization instead of @Generic. Let me know if I can be of specific help with that. - Christian Humer On Fri, May 30, 2014 at 9:51 PM, Stefan Marr wrote: > Hi: > > I am debugging splitting issues in TruffleSOM and found two things, I > would like to ask for comments on. > > The first thing is one of the splitting conditions: > > OptimizedDirectCallNode.java:191 > // max one child call and callCount > 2 and kind of small number of nodes > if (isMaxSingleCall()) { return true; } > > In which cases would it be useful to split such methods? > For TruffleSOM, this condition causes plenty of issues with > microbenchmarks, because it leads to unconditional splitting and the > resulting trees do not stabilize. > I have the feeling this should be restricted to methods that contain at > least polymorphic nodes and that seems to be covered by the condition > afterwards. > > The second issue I have is the semantics of @Generic specializations. > Now, it implies a megamorphic cost for nodes, which has an impact on > splitting. > For me, Generic can also be just a field access that reads or stores > objects, because that is the most generic case, but, does not imply that > the node ever saw something other than objects. > So, I wonder whether it would be useful to be able to define a cost > parameter for the @Generic annotation, in order to be able to influence the > cost of the resulting nodes? > > Thanks > Stefan > > -- > Stefan Marr > INRIA Lille - Nord Europe > http://stefan-marr.de/research/ > > > > From java at stefan-marr.de Fri May 30 20:45:28 2014 From: java at stefan-marr.de (Stefan Marr) Date: Fri, 30 May 2014 22:45:28 +0200 Subject: [TruffleDSL] Splitting and Cost of Generic Nodes In-Reply-To: References: <1AEB5093-457E-4D8A-9B2C-63F3ABF89267@stefan-marr.de> Message-ID: Hi Christian: On 30 May 2014, at 22:39, Christian Humer wrote: > Unfortunately splitting has still some major issues (as you recognized). The current version splits way too much (independent of polymorphism) and can also have some exponential code duplication problems under bad conditions. However it should stabilize at some point (may be late). But this should only be a problem on bigger benchmarks not on micro-benchmarks. So maybe there is another issue here. Can you point me to such a micro? Well, removing the condition (isMaxSingleCall) [see 1] solves all the issues for me. After that, I do not have any benchmark (I am aware of) that gives trouble with splitting enabled. That?s why I am asking. To me, that condition just doesn?t seem very useful, and I would like to understand in which cases it might be useful. > @Generic is the wrong name for this annotation. In the next iteration of the DSL this annotation is going to be renamed to @Fallback. Ok, I see. Well, I did remove all uses of @Generic already, after I saw the consequence for splitting. Thanks Stefan [1] https://github.com/smarr/graal/commit/caa1fc084623f4e6ae3087dec9da81ce859aa906 -- Stefan Marr INRIA Lille - Nord Europe http://stefan-marr.de/research/ From christian.humer at gmail.com Sat May 31 00:10:54 2014 From: christian.humer at gmail.com (Christian Humer) Date: Sat, 31 May 2014 02:10:54 +0200 Subject: [TruffleDSL] Splitting and Cost of Generic Nodes In-Reply-To: References: <1AEB5093-457E-4D8A-9B2C-63F3ABF89267@stefan-marr.de> Message-ID: Hi, > > Unfortunately splitting has still some major issues (as you recognized). > The current version splits way too much (independent of polymorphism) and > can also have some exponential code duplication problems under bad > conditions. However it should stabilize at some point (may be late). But > this should only be a problem on bigger benchmarks not on micro-benchmarks. > So maybe there is another issue here. Can you point me to such a micro? > > Well, removing the condition (isMaxSingleCall) [see 1] solves all the > issues for me. > After that, I do not have any benchmark (I am aware of) that gives trouble > with splitting enabled. > That?s why I am asking. To me, that condition just doesn?t seem very > useful, and I would like to understand in which cases it might be useful. Well, splitting has some implications also on inlining. The more you split the more context sensitive (the better) your inlining decisions are. We have already improved on that by using a more leaf based inlining approach. Still they are not independent and most likely causing my current regressions. Also just counting the polymorphism of nodes may not be good enough. So what I want to say is that I do not really like to remove this branch at the moment. If you want, I can offer you to make it temporary configurable with a runtime flag. - Christian Humer On Fri, May 30, 2014 at 10:45 PM, Stefan Marr wrote: > Hi Christian: > > On 30 May 2014, at 22:39, Christian Humer > wrote: > > > Unfortunately splitting has still some major issues (as you recognized). > The current version splits way too much (independent of polymorphism) and > can also have some exponential code duplication problems under bad > conditions. However it should stabilize at some point (may be late). But > this should only be a problem on bigger benchmarks not on micro-benchmarks. > So maybe there is another issue here. Can you point me to such a micro? > > Well, removing the condition (isMaxSingleCall) [see 1] solves all the > issues for me. > After that, I do not have any benchmark (I am aware of) that gives trouble > with splitting enabled. > That?s why I am asking. To me, that condition just doesn?t seem very > useful, and I would like to understand in which cases it might be useful. > > > @Generic is the wrong name for this annotation. In the next iteration of > the DSL this annotation is going to be renamed to @Fallback. > > Ok, I see. Well, I did remove all uses of @Generic already, after I saw > the consequence for splitting. > > Thanks > Stefan > > > [1] > https://github.com/smarr/graal/commit/caa1fc084623f4e6ae3087dec9da81ce859aa906 > > > -- > Stefan Marr > INRIA Lille - Nord Europe > http://stefan-marr.de/research/ > > > > From doug.simon at oracle.com Sat May 31 01:00:06 2014 From: doug.simon at oracle.com (doug.simon at oracle.com) Date: Sat, 31 May 2014 01:00:06 +0000 Subject: hg: graal/graal: 2 new changesets Message-ID: <201405310100.s4V109TF004927@aojmv0008> Changeset: ce09739483c9 Author: Lukas Stadler Date: 2014-05-30 12:13 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/ce09739483c9 fix typo in InlineableGraph ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/inlining/info/elem/InlineableGraph.java Changeset: 5eadeec42668 Author: Lukas Stadler Date: 2014-05-30 12:14 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/5eadeec42668 make NodeBitMap.grow public ! graal/com.oracle.graal.graph/src/com/oracle/graal/graph/NodeBitMap.java From java at stefan-marr.de Sat May 31 08:33:52 2014 From: java at stefan-marr.de (Stefan Marr) Date: Sat, 31 May 2014 10:33:52 +0200 Subject: [TruffleDSL] Splitting and Cost of Generic Nodes In-Reply-To: References: <1AEB5093-457E-4D8A-9B2C-63F3ABF89267@stefan-marr.de> Message-ID: <49718503-6A50-456B-B642-136592783895@stefan-marr.de> Hi Christian: On 31 May 2014, at 02:10, Christian Humer wrote: > So what I want to say is that I do not really like to remove this branch at the moment. > If you want, I can offer you to make it temporary configurable with a runtime flag. Guess, it is best for me just to wait until the overall splitting issues you are seeing are sorted out. For the moment, I?ll just leave the change in my local copy of graal. Thanks Stefan -- Stefan Marr INRIA Lille - Nord Europe http://stefan-marr.de/research/