From doug.simon at oracle.com Tue Jul 1 01:00:08 2014 From: doug.simon at oracle.com (doug.simon at oracle.com) Date: Tue, 01 Jul 2014 01:00:08 +0000 Subject: hg: graal/graal: 32 new changesets Message-ID: <201407010100.s6110A3N015695@aojmv0008> Changeset: 66c7e50a9a32 Author: Stefan Anzinger Date: 2014-04-19 15:29 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/66c7e50a9a32 SPARCMove.java: Adding constant float and double loads SPARCConstDataOp.java, SPARCLIRGenerator.java: Introducing CSTrings as constant value (Used for debugging) SPARCHotSpotLIRGenerationResult.java, SPARCHotSpotBackend.java: Adapting to new LIR interface SPARCAssembler.java: Introducing comments for some instructions ! graal/com.oracle.graal.asm.sparc/src/com/oracle/graal/asm/sparc/SPARCAssembler.java ! graal/com.oracle.graal.compiler.sparc/src/com/oracle/graal/compiler/sparc/SPARCLIRGenerator.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/SPARCHotSpotLIRGenerationResult.java + graal/com.oracle.graal.lir.sparc/src/com/oracle/graal/lir/sparc/SPARCConstDataOp.java ! graal/com.oracle.graal.lir.sparc/src/com/oracle/graal/lir/sparc/SPARCMove.java Changeset: 12f2b3baa163 Author: Stefan Anzinger Date: 2014-04-19 15:32 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/12f2b3baa163 JUnit Reporting ! mx/JUnitWrapper.java ! mx/mx_graal.py ! mx/projects Changeset: 18c8ef7df8b5 Author: Stefan Anzinger Date: 2014-04-24 07:21 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/18c8ef7df8b5 Implementing LNEG and check for the right condition code register. ! graal/com.oracle.graal.compiler.sparc/src/com/oracle/graal/compiler/sparc/SPARCLIRGenerator.java ! graal/com.oracle.graal.lir.sparc/src/com/oracle/graal/lir/sparc/SPARCArithmetic.java ! graal/com.oracle.graal.lir.sparc/src/com/oracle/graal/lir/sparc/SPARCControlFlow.java Changeset: 21c3c233e81a Author: Stefan Anzinger Date: 2014-04-24 07:25 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/21c3c233e81a mx_graal.py unittest make testname match with wildcards * ! mx/mx_graal.py Changeset: 2395c0fc5a19 Author: Stefan Anzinger Date: 2014-04-24 07:41 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/2395c0fc5a19 Added lookup for Gaals JavaThread::graal_alternate_call_target_offset() in the i2c. ! src/cpu/sparc/vm/sharedRuntime_sparc.cpp Changeset: e5a8608f7d63 Author: Stefan Anzinger Date: 2014-04-24 14:02 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/e5a8608f7d63 Narrowing down the return value (short, char and bool) of called method on Big Endian architectures. ! src/share/vm/graal/graalCompilerToVM.cpp Changeset: 9a40006b53c1 Author: Stefan Anzinger Date: 2014-04-24 14:09 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/9a40006b53c1 Make proper code for c const strings required for fixup in hotspot ! graal/com.oracle.graal.lir.sparc/src/com/oracle/graal/lir/sparc/SPARCConstDataOp.java Changeset: 2fc9d69be77e Author: Stefan Anzinger Date: 2014-05-30 10:42 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/2fc9d69be77e Fixing stub call to unwindExceptionToCaller and jumpToExceptionHandler Fix in generating code for the CString LIR instruction ! graal/com.oracle.graal.hotspot.sparc/src/com/oracle/graal/hotspot/sparc/SPARCHotSpotJumpToExceptionHandlerInCallerOp.java ! graal/com.oracle.graal.hotspot.sparc/src/com/oracle/graal/hotspot/sparc/SPARCHotSpotUnwindOp.java ! graal/com.oracle.graal.lir.sparc/src/com/oracle/graal/lir/sparc/SPARCConstDataOp.java ! graal/com.oracle.graal.lir.sparc/src/com/oracle/graal/lir/sparc/SPARCControlFlow.java Changeset: 08b2bfcb9075 Author: Stefan Anzinger Date: 2014-05-30 10:45 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/08b2bfcb9075 New tests for BC_lcmp ! graal/com.oracle.graal.jtt/src/com/oracle/graal/jtt/bytecode/BC_lcmp.java Changeset: b5f89908b9ba Author: Stefan Anzinger Date: 2014-05-30 13:23 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/b5f89908b9ba Merge ! graal/com.oracle.graal.hotspot.sparc/src/com/oracle/graal/hotspot/sparc/SPARCHotSpotBackend.java Changeset: 151fe6b1e511 Author: Stefan Anzinger Date: 2014-05-30 15:09 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/151fe6b1e511 Merge ! graal/com.oracle.graal.asm.sparc/src/com/oracle/graal/asm/sparc/SPARCAssembler.java - 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/GraalOptions.java + graal/com.oracle.graal.compiler.common/src/com/oracle/graal/compiler/common/UnsafeAccess.java - graal/com.oracle.graal.compiler.common/src/com/oracle/graal/compiler/common/spi/LIRTypeTool.java + 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/ObjectStamp.java + graal/com.oracle.graal.compiler.common/src/com/oracle/graal/compiler/common/type/PrimitiveStamp.java + graal/com.oracle.graal.compiler.common/src/com/oracle/graal/compiler/common/type/StampFactory.java + graal/com.oracle.graal.compiler.common/src/com/oracle/graal/compiler/common/type/StampProvider.java + graal/com.oracle.graal.compiler.common/src/com/oracle/graal/compiler/common/type/VoidStamp.java ! graal/com.oracle.graal.compiler.sparc/src/com/oracle/graal/compiler/sparc/SPARCLIRGenerator.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.hotspot.hsail/src/com/oracle/graal/hotspot/hsail/nodes/AtomicGetAndAddNode.java - graal/com.oracle.graal.hotspot.hsail/src/com/oracle/graal/hotspot/hsail/nodes/LoweredAtomicGetAndAddNode.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/SPARCHotSpotLIRGenerationResult.java - graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/HotSpotSymbol.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.hotspot/src/com/oracle/graal/hotspot/meta/DefaultHotSpotLoweringProvider.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 + 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.lir.sparc/src/com/oracle/graal/lir/sparc/SPARCArithmetic.java ! graal/com.oracle.graal.lir.sparc/src/com/oracle/graal/lir/sparc/SPARCControlFlow.java ! graal/com.oracle.graal.lir.sparc/src/com/oracle/graal/lir/sparc/SPARCMove.java - graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/BinaryLogicNode.java + graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/BinaryOpLogicNode.java - graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/cfg/BlocksToDoubles.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.nodes/src/com/oracle/graal/nodes/type/FloatStamp.java - graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/type/IllegalStamp.java - graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/type/IntegerStamp.java - graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/type/ObjectStamp.java - graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/type/PrimitiveStamp.java - graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/type/StampFactory.java - graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/type/StampProvider.java - graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/type/VoidStamp.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/ReadEliminationPhase.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/GraalOptions.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.test/src/com/oracle/graal/test/GraalLongUnitTest.java - graal/com.oracle.graal.test/src/com/oracle/graal/test/LongTest.java - graal/com.oracle.truffle.api/src/com/oracle/truffle/api/debug/ASTPrinter.java - graal/com.oracle.truffle.api/src/com/oracle/truffle/api/debug/DebugContext.java - graal/com.oracle.truffle.api/src/com/oracle/truffle/api/debug/DebugManager.java - graal/com.oracle.truffle.api/src/com/oracle/truffle/api/debug/DefaultDebugManager.java - graal/com.oracle.truffle.api/src/com/oracle/truffle/api/debug/KillException.java - graal/com.oracle.truffle.api/src/com/oracle/truffle/api/debug/QuitException.java - graal/com.oracle.truffle.api/src/com/oracle/truffle/api/impl/DefaultSourceSection.java - graal/com.oracle.truffle.api/src/com/oracle/truffle/api/nodes/instrument/DefaultNodeInstrumenter.java - graal/com.oracle.truffle.api/src/com/oracle/truffle/api/nodes/instrument/InstrumentationNode.java - graal/com.oracle.truffle.api/src/com/oracle/truffle/api/nodes/instrument/InstrumentationProbeEvents.java - graal/com.oracle.truffle.api/src/com/oracle/truffle/api/nodes/instrument/InstrumentationProbeNode.java - graal/com.oracle.truffle.api/src/com/oracle/truffle/api/nodes/instrument/InstrumentationProxyNode.java - graal/com.oracle.truffle.api/src/com/oracle/truffle/api/nodes/instrument/NodeInstrumenter.java - graal/com.oracle.truffle.api/src/com/oracle/truffle/api/nodes/instrument/NodePhylum.java - graal/com.oracle.truffle.api/src/com/oracle/truffle/api/nodes/instrument/PhylumMarked.java - graal/com.oracle.truffle.api/src/com/oracle/truffle/api/source/SourceManager.java ! mx/JUnitWrapper.java ! mx/mx_graal.py ! mx/projects ! src/share/vm/graal/graalCompilerToVM.cpp - test/baseline_whitelist.txt + test/whitelist_baseline.txt Changeset: f57cf459f5d3 Author: Stefan Anzinger Date: 2014-05-31 00:30 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/f57cf459f5d3 [SPARC] Adding deoptimization handler foreign call LoadDataAddressOp emitting now absolute addresses. (May be improved in future) Removing epilogue baseclass/block end marking interface from LeaveCurrentStackFrameOp and LeaveDeoptimizedStackFrameOp to conform with the assertion in com.oracle.graal.lir.LIR.verifyBlock Implement LIRGenerator.emitDeoptimizationFetchUnrollInfoCall for SPARC Removing my changes for JUnit reporting from testrunner. ! graal/com.oracle.graal.compiler.common/src/com/oracle/graal/compiler/common/GraalOptions.java ! graal/com.oracle.graal.compiler.common/src/com/oracle/graal/compiler/common/UnsafeAccess.java ! 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/ObjectStamp.java ! graal/com.oracle.graal.compiler.common/src/com/oracle/graal/compiler/common/type/PrimitiveStamp.java ! graal/com.oracle.graal.compiler.common/src/com/oracle/graal/compiler/common/type/StampFactory.java ! graal/com.oracle.graal.compiler.common/src/com/oracle/graal/compiler/common/type/StampProvider.java ! graal/com.oracle.graal.compiler.common/src/com/oracle/graal/compiler/common/type/VoidStamp.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.sparc/src/com/oracle/graal/hotspot/sparc/SPARCHotSpotLeaveCurrentStackFrameOp.java ! graal/com.oracle.graal.hotspot.sparc/src/com/oracle/graal/hotspot/sparc/SPARCHotSpotLeaveDeoptimizedStackFrameOp.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/DefaultHotSpotLoweringProvider.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/MethodHandleNode.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.lir.sparc/src/com/oracle/graal/lir/sparc/SPARCMove.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/BinaryOpLogicNode.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 ! mx/JUnitWrapper.java ! mx/mx_graal.py ! mx/projects ! test/whitelist_baseline.txt Changeset: b955d649fca8 Author: Stefan Anzinger Date: 2014-06-02 20:40 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/b955d649fca8 Fixing BC_i2f, BC_i2c, BC_fadd Implementing instructions in assembler Movwtos and Fitos ! graal/com.oracle.graal.asm.sparc/src/com/oracle/graal/asm/sparc/SPARCAssembler.java ! graal/com.oracle.graal.compiler.sparc/src/com/oracle/graal/compiler/sparc/SPARCLIRGenerator.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotForeignCallsProviderImpl.java ! graal/com.oracle.graal.jtt/src/com/oracle/graal/jtt/bytecode/BC_fadd.java ! graal/com.oracle.graal.lir.sparc/src/com/oracle/graal/lir/sparc/SPARCArithmetic.java - graal/com.oracle.graal.lir.sparc/src/com/oracle/graal/lir/sparc/SPARCConstDataOp.java ! graal/com.oracle.graal.lir.sparc/src/com/oracle/graal/lir/sparc/SPARCMove.java Changeset: 989ab80382c1 Author: Stefan Anzinger Date: 2014-06-02 20:41 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/989ab80382c1 Using absolute addressing instead of pc relative in fixup. ! src/cpu/sparc/vm/graalCodeInstaller_sparc.cpp Changeset: 4b24d2019286 Author: Stefan Anzinger Date: 2014-06-02 21:00 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/4b24d2019286 Fixing issues with fdiv ! graal/com.oracle.graal.asm.sparc/src/com/oracle/graal/asm/sparc/SPARCAssembler.java Changeset: 31db7b7374f0 Author: Stefan Anzinger Date: 2014-06-02 21:08 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/31db7b7374f0 Merge ! graal/com.oracle.graal.compiler.common/src/com/oracle/graal/compiler/common/GraalOptions.java ! graal/com.oracle.graal.compiler.common/src/com/oracle/graal/compiler/common/UnsafeAccess.java ! 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/ObjectStamp.java ! graal/com.oracle.graal.compiler.common/src/com/oracle/graal/compiler/common/type/PrimitiveStamp.java ! graal/com.oracle.graal.compiler.common/src/com/oracle/graal/compiler/common/type/StampFactory.java ! graal/com.oracle.graal.compiler.common/src/com/oracle/graal/compiler/common/type/StampProvider.java ! graal/com.oracle.graal.compiler.common/src/com/oracle/graal/compiler/common/type/VoidStamp.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/DefaultHotSpotLoweringProvider.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/MethodHandleNode.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.nodes/src/com/oracle/graal/nodes/BinaryOpLogicNode.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 ! test/whitelist_baseline.txt Changeset: a4bd33d52985 Author: Stefan Anzinger Date: 2014-06-03 14:29 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/a4bd33d52985 Fixing tests with number conversions, float and double handling. Introducing new VIS3 instructions. Adding testcases. ! graal/com.oracle.graal.api.code/src/com/oracle/graal/api/code/ValueUtil.java ! graal/com.oracle.graal.asm.sparc/src/com/oracle/graal/asm/sparc/SPARCAssembler.java ! graal/com.oracle.graal.compiler.common/src/com/oracle/graal/compiler/common/GraalOptions.java ! graal/com.oracle.graal.compiler.common/src/com/oracle/graal/compiler/common/UnsafeAccess.java ! 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/ObjectStamp.java ! graal/com.oracle.graal.compiler.common/src/com/oracle/graal/compiler/common/type/PrimitiveStamp.java ! graal/com.oracle.graal.compiler.common/src/com/oracle/graal/compiler/common/type/StampFactory.java ! graal/com.oracle.graal.compiler.common/src/com/oracle/graal/compiler/common/type/StampProvider.java ! graal/com.oracle.graal.compiler.common/src/com/oracle/graal/compiler/common/type/VoidStamp.java ! graal/com.oracle.graal.compiler.sparc/src/com/oracle/graal/compiler/sparc/SPARCLIRGenerator.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/DefaultHotSpotLoweringProvider.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/MethodHandleNode.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.jtt/src/com/oracle/graal/jtt/bytecode/BC_i2d.java ! graal/com.oracle.graal.lir.sparc/src/com/oracle/graal/lir/sparc/SPARCArithmetic.java ! graal/com.oracle.graal.lir.sparc/src/com/oracle/graal/lir/sparc/SPARCMove.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/BinaryOpLogicNode.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 ! test/whitelist_baseline.txt Changeset: fcac781d3592 Author: Stefan Anzinger Date: 2014-06-03 14:31 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/fcac781d3592 Merge ! graal/com.oracle.graal.compiler.common/src/com/oracle/graal/compiler/common/GraalOptions.java ! graal/com.oracle.graal.compiler.common/src/com/oracle/graal/compiler/common/UnsafeAccess.java ! 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/ObjectStamp.java ! graal/com.oracle.graal.compiler.common/src/com/oracle/graal/compiler/common/type/PrimitiveStamp.java ! graal/com.oracle.graal.compiler.common/src/com/oracle/graal/compiler/common/type/StampFactory.java ! graal/com.oracle.graal.compiler.common/src/com/oracle/graal/compiler/common/type/StampProvider.java ! graal/com.oracle.graal.compiler.common/src/com/oracle/graal/compiler/common/type/VoidStamp.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/DefaultHotSpotLoweringProvider.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/MethodHandleNode.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.nodes/src/com/oracle/graal/nodes/BinaryOpLogicNode.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 ! test/whitelist_baseline.txt Changeset: fac4af29aeb8 Author: Stefan Anzinger Date: 2014-06-05 11:28 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/fac4af29aeb8 [SPARC] Fixing lots of float and double issues. ! graal/com.oracle.graal.asm.sparc/src/com/oracle/graal/asm/sparc/SPARCAssembler.java ! graal/com.oracle.graal.compiler.common/src/com/oracle/graal/compiler/common/GraalOptions.java ! graal/com.oracle.graal.compiler.common/src/com/oracle/graal/compiler/common/UnsafeAccess.java ! 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/ObjectStamp.java ! graal/com.oracle.graal.compiler.common/src/com/oracle/graal/compiler/common/type/PrimitiveStamp.java ! graal/com.oracle.graal.compiler.common/src/com/oracle/graal/compiler/common/type/StampFactory.java ! graal/com.oracle.graal.compiler.common/src/com/oracle/graal/compiler/common/type/StampProvider.java ! graal/com.oracle.graal.compiler.common/src/com/oracle/graal/compiler/common/type/VoidStamp.java ! graal/com.oracle.graal.compiler.sparc/src/com/oracle/graal/compiler/sparc/SPARCLIRGenerator.java ! graal/com.oracle.graal.hotspot.sparc/src/com/oracle/graal/hotspot/sparc/SPARCHotSpotRegisterConfig.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/DefaultHotSpotLoweringProvider.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/MethodHandleNode.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.lir.sparc/src/com/oracle/graal/lir/sparc/SPARCArithmetic.java ! graal/com.oracle.graal.lir.sparc/src/com/oracle/graal/lir/sparc/SPARCMove.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/BinaryOpLogicNode.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 ! test/whitelist_baseline.txt Changeset: f96d9c455da5 Author: Stefan Anzinger Date: 2014-06-05 15:28 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/f96d9c455da5 Fixing dcmp ! graal/com.oracle.graal.lir.sparc/src/com/oracle/graal/lir/sparc/SPARCCompare.java ! graal/com.oracle.graal.lir.sparc/src/com/oracle/graal/lir/sparc/SPARCControlFlow.java ! graal/com.oracle.graal.lir.sparc/src/com/oracle/graal/lir/sparc/SPARCMove.java Changeset: f22e4fd06a7e Author: Stefan Anzinger Date: 2014-06-05 16:28 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/f22e4fd06a7e [SPARC] Fixing BC_new, BC_fcmpxx ! graal/com.oracle.graal.lir.sparc/src/com/oracle/graal/lir/sparc/SPARCCompare.java ! graal/com.oracle.graal.lir.sparc/src/com/oracle/graal/lir/sparc/SPARCControlFlow.java ! graal/com.oracle.graal.printer/src/com/oracle/graal/printer/HexCodeFile.java Changeset: cb196ea71d77 Author: Stefan Anzinger Date: 2014-06-06 00:18 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/cb196ea71d77 [SPARC] Fixing last issues on jtt.bytecode, reverting changes to HexCodeFile, fixed parsing method in Disassembler and submitted the patch ! graal/com.oracle.graal.lir.sparc/src/com/oracle/graal/lir/sparc/SPARCArithmetic.java ! graal/com.oracle.graal.printer/src/com/oracle/graal/printer/HexCodeFile.java Changeset: e497100e1fbf Author: Stefan Anzinger Date: 2014-06-06 01:19 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/e497100e1fbf Merge ! graal/com.oracle.graal.compiler.common/src/com/oracle/graal/compiler/common/GraalOptions.java ! graal/com.oracle.graal.compiler.common/src/com/oracle/graal/compiler/common/UnsafeAccess.java ! 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/ObjectStamp.java ! graal/com.oracle.graal.compiler.common/src/com/oracle/graal/compiler/common/type/PrimitiveStamp.java ! graal/com.oracle.graal.compiler.common/src/com/oracle/graal/compiler/common/type/StampFactory.java ! graal/com.oracle.graal.compiler.common/src/com/oracle/graal/compiler/common/type/StampProvider.java ! graal/com.oracle.graal.compiler.common/src/com/oracle/graal/compiler/common/type/VoidStamp.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/DefaultHotSpotLoweringProvider.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/MethodHandleNode.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.nodes/src/com/oracle/graal/nodes/BinaryOpLogicNode.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 ! mx/mx_graal.py ! src/share/vm/graal/graalCompilerToVM.cpp - src/share/vm/graal/graalVMToCompiler.cpp - src/share/vm/graal/graalVMToCompiler.hpp ! test/whitelist_baseline.txt Changeset: 51f392557124 Author: Stefan Anzinger Date: 2014-06-30 08:50 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/51f392557124 [SPARC] Improving implicit exception handling on sparc ! graal/com.oracle.graal.compiler.common/src/com/oracle/graal/compiler/common/GraalOptions.java ! graal/com.oracle.graal.compiler.common/src/com/oracle/graal/compiler/common/UnsafeAccess.java ! 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/ObjectStamp.java ! graal/com.oracle.graal.compiler.common/src/com/oracle/graal/compiler/common/type/PrimitiveStamp.java ! graal/com.oracle.graal.compiler.common/src/com/oracle/graal/compiler/common/type/StampFactory.java ! graal/com.oracle.graal.compiler.common/src/com/oracle/graal/compiler/common/type/StampProvider.java ! graal/com.oracle.graal.compiler.common/src/com/oracle/graal/compiler/common/type/VoidStamp.java ! graal/com.oracle.graal.compiler.sparc/src/com/oracle/graal/compiler/sparc/SPARCLIRGenerator.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/SPARCHotSpotPatchReturnAddressOp.java + graal/com.oracle.graal.hotspot.sparc/src/com/oracle/graal/hotspot/sparc/SPARCUncommonTrapStub.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/DefaultHotSpotLoweringProvider.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/MethodHandleNode.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.jtt/src/com/oracle/graal/jtt/except/BC_ldiv2.java ! graal/com.oracle.graal.lir.sparc/src/com/oracle/graal/lir/sparc/SPARCArithmetic.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/BinaryOpLogicNode.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 ! src/cpu/sparc/vm/sharedRuntime_sparc.cpp ! test/whitelist_baseline.txt Changeset: 5f01f7c48d40 Author: Stefan Anzinger Date: 2014-06-30 12:02 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/5f01f7c48d40 Merge with 5cdcb94a7cf7d9782107cc582f3e4b50000d5d1f ! graal/com.oracle.graal.compiler.common/src/com/oracle/graal/compiler/common/GraalOptions.java ! graal/com.oracle.graal.compiler.common/src/com/oracle/graal/compiler/common/UnsafeAccess.java - graal/com.oracle.graal.compiler.common/src/com/oracle/graal/compiler/common/spi/PlatformKindTool.java ! 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/ObjectStamp.java ! graal/com.oracle.graal.compiler.common/src/com/oracle/graal/compiler/common/type/PrimitiveStamp.java ! graal/com.oracle.graal.compiler.common/src/com/oracle/graal/compiler/common/type/StampFactory.java ! graal/com.oracle.graal.compiler.common/src/com/oracle/graal/compiler/common/type/StampProvider.java ! graal/com.oracle.graal.compiler.common/src/com/oracle/graal/compiler/common/type/VoidStamp.java ! graal/com.oracle.graal.compiler.sparc/src/com/oracle/graal/compiler/sparc/SPARCLIRGenerator.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.sparc/src/com/oracle/graal/hotspot/sparc/SPARCHotSpotRegisterConfig.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/DefaultHotSpotLoweringProvider.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/MethodHandleNode.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.java/src/com/oracle/graal/java/VerifyOptionsPhase.java ! graal/com.oracle.graal.lir.sparc/src/com/oracle/graal/lir/sparc/SPARCArithmetic.java ! graal/com.oracle.graal.lir.sparc/src/com/oracle/graal/lir/sparc/SPARCControlFlow.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/BinaryOpLogicNode.java + graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/MemoryMap.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/MemoryMapNode.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/util/HashSetNodeChangeListener.java + graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/util/HashSetNodeEventListener.java - graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/TruffleInliningResult.java - graal/com.oracle.truffle.api.test/src/com/oracle/truffle/api/test/utilities/TextMapTest.java - graal/com.oracle.truffle.api/src/com/oracle/truffle/api/NullSourceSection.java - 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/source/SourceFactory.java - graal/com.oracle.truffle.api/src/com/oracle/truffle/api/source/SourceLineLocation.java - graal/com.oracle.truffle.api/src/com/oracle/truffle/api/source/TextMap.java ! mx/mx_graal.py ! mx/projects ! src/share/vm/graal/graalCompilerToVM.cpp ! test/whitelist_baseline.txt Changeset: 34ac3ddfd5ac Author: Stefan Anzinger Date: 2014-06-30 17:27 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/34ac3ddfd5ac [SPARC] fixing findbug warnings ! graal/com.oracle.graal.compiler.common/src/com/oracle/graal/compiler/common/GraalOptions.java ! graal/com.oracle.graal.compiler.common/src/com/oracle/graal/compiler/common/UnsafeAccess.java ! 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/ObjectStamp.java ! graal/com.oracle.graal.compiler.common/src/com/oracle/graal/compiler/common/type/PrimitiveStamp.java ! graal/com.oracle.graal.compiler.common/src/com/oracle/graal/compiler/common/type/StampFactory.java ! graal/com.oracle.graal.compiler.common/src/com/oracle/graal/compiler/common/type/StampProvider.java ! graal/com.oracle.graal.compiler.common/src/com/oracle/graal/compiler/common/type/VoidStamp.java ! graal/com.oracle.graal.hotspot.sparc/src/com/oracle/graal/hotspot/sparc/SPARCHotSpotPatchReturnAddressOp.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/DefaultHotSpotLoweringProvider.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/MethodHandleNode.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.lir.sparc/src/com/oracle/graal/lir/sparc/SPARCControlFlow.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/BinaryOpLogicNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/MemoryMap.java < graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/MemoryMapNode.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/util/HashSetNodeEventListener.java ! test/whitelist_baseline.txt Changeset: 281c30cf1952 Author: Stefan Anzinger Date: 2014-06-30 18:17 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/281c30cf1952 Merge - graal/com.oracle.graal.graph/src/com/oracle/graal/graph/GraphEvent.java - graal/com.oracle.graal.graph/src/com/oracle/graal/graph/GraphEventLog.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/MethodHandleNode.java ! mx/projects Changeset: 41d479400da8 Author: Lukas Stadler Date: 2014-06-30 18:46 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/41d479400da8 Merge ! graal/com.oracle.graal.compiler.common/src/com/oracle/graal/compiler/common/GraalOptions.java ! 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/ObjectStamp.java ! graal/com.oracle.graal.compiler.common/src/com/oracle/graal/compiler/common/type/PrimitiveStamp.java ! graal/com.oracle.graal.compiler.common/src/com/oracle/graal/compiler/common/type/StampFactory.java ! graal/com.oracle.graal.compiler.common/src/com/oracle/graal/compiler/common/type/VoidStamp.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/DefaultHotSpotLoweringProvider.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.nodes/src/com/oracle/graal/nodes/BinaryOpLogicNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/MemoryMap.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 ! test/whitelist_baseline.txt Changeset: c8b0f10e3220 Author: Lukas Stadler Date: 2014-06-30 18:46 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/c8b0f10e3220 VirtualObjectNode is a floating node ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/util/GraphUtil.java Changeset: ddd68e267e34 Author: Lukas Stadler Date: 2014-06-30 18:46 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/ddd68e267e34 explicitly define optional inputs in @Input ! graal/com.oracle.graal.graph/src/com/oracle/graal/graph/Node.java ! graal/com.oracle.graal.graph/src/com/oracle/graal/graph/NodeClass.java ! graal/com.oracle.graal.graph/src/com/oracle/graal/graph/NodeClassIterable.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/nodes/G1PreWriteBarrier.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/nodes/WriteBarrier.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/UnsafeArrayCopyNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/AbstractDeoptimizeNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/AbstractStateSplit.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/BeginStateSplitNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/DeoptimizingFixedWithNextNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/FloatingGuardedNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/FrameState.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/GuardPhiNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/InvokeNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/InvokeWithExceptionNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/LoopBeginNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/ReturnNode.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/BytecodeExceptionNode.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/FloatingReadNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/extended/ForeignCallNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/extended/UnsafeLoadNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/extended/UnsafeStoreNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/extended/ValueAnchorNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/java/AccessFieldNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/java/AccessMonitorNode.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.nodes/src/com/oracle/graal/nodes/java/MonitorExitNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/java/RegisterFinalizerNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/java/StoreFieldNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/java/StoreIndexedNode.java ! graal/com.oracle.graal.replacements/src/com/oracle/graal/replacements/nodes/MacroStateSplitNode.java Changeset: 75ea3123657f Author: Lukas Stadler Date: 2014-06-30 19:01 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/75ea3123657f small formatting fixes for SPARC changes ! graal/com.oracle.graal.hotspot.sparc/src/com/oracle/graal/hotspot/sparc/SPARCHotSpotPatchReturnAddressOp.java ! graal/com.oracle.graal.lir.sparc/src/com/oracle/graal/lir/sparc/SPARCMove.java Changeset: 0e36e8377c99 Author: Doug Simon Date: 2014-06-30 21:22 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/0e36e8377c99 HSAIL: cannot reference OkraContext if it cannot be loaded ! 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/lambda/ReduceMaxTest.java ! graal/com.oracle.graal.compiler.hsail.test/src/com/oracle/graal/compiler/hsail/test/lambda/ReduceMinTest.java ! graal/com.oracle.graal.compiler.hsail.test/src/com/oracle/graal/compiler/hsail/test/lambda/ReduceSumTest.java From doug.simon at oracle.com Tue Jul 1 06:34:32 2014 From: doug.simon at oracle.com (Doug Simon) Date: Tue, 1 Jul 2014 08:34:32 +0200 Subject: webrev-hsail-transcendentals In-Reply-To: References: Message-ID: <2F413CD7-D39C-4984-8F45-30983C1925F4@oracle.com> I will integrate this patch. However, to do so, I need to change the header for JStrictMath so that it passes ?mx checkheaders'. The header is currently: /* * Copyright 1999-2006 Sun Microsystems, Inc. All rights reserved. * SUN PROPRIETARY/CONFIDENTIAL. Use is subject to license terms. */ Can we simply change this to the expected Oracle copyright header? -Doug On Jun 30, 2014, at 9:56 PM, Deneau, Tom wrote: > Please review the following webrev which adds support for several missing java.lang.Math routines to the HSAIL backend. > http://cr.openjdk.java.net/~tdeneau/graal-webrevs/webrev-hsail-transcendentals/webrev/ > > Many of these routines were declared as native in the regular host backends, but HSAIL has no way to invoke host code from the kernels. But if we could find java implementations of these methods we could use those thru the graal MethodSubstitution framework. For the java implementations, we basically used a file StrictMath.java which Gustav Trede donated to OpenJDK back in 2009 as a java port of the C FDLIBM routines, thank you Gustav. > http://mail.openjdk.java.net/pipermail/hotspot-dev/2009-August/001992.html > > We made only a few minor changes to that file. My understanding from Joe Darcy is that in Java 9 there will be an official port of FDLIBM to java in the JDK, so when that happens we should be able to use that instead. > > > Notes: > > * JStrictMath.java is the java implementation of the Math routines noted above. HSAILMathSubstitutions redirects several methods to there. In addition test cases were added for many Math routines which were already implemented as java methods in java.lang.Math. > > * GraalTest -- > > o Since the java spec specifies the tolerance for most of these Math routines in terms of ULPs, I wanted to enable a way for AssertEquals to use ULPs rather than a constant maximum delta. This is done by overriding protected int ulpsDelta() to return something other than zero. > > * HSAILAssembler > > o fix the printing of some special Double and Float constants > > o cvt for float to integer uses zeroi_sat (saturate) > > * HSAILLIRGenerator & HSAILControlFlow > > o IntegerTestMove support was required by some of the java implementations > > * all the rest are just junit tests. > > All junit tests should pass on the simulator. These math routines have also been useful in solidifying the hsail hardware implementation. > > -- Tom > From lukas.stadler at oracle.com Tue Jul 1 10:04:52 2014 From: lukas.stadler at oracle.com (Lukas Stadler) Date: Tue, 1 Jul 2014 12:04:52 +0200 Subject: Canonicalizable and @Input changes Message-ID: <28A86EE5-831D-40E4-A0D7-49833C5689F1@oracle.com> Hi! I just wanted to announce a two recent changes, to give you a hint in case you see assertions popping up in your code: - The Canonicalizable interface now expects implementors to not change the graph in any way: No changes to inputs, successors or properties of any node are allowed, and no nodes can be added to the graph. Returning pre-existing or newly allocated (but not yet added) nodes or null is the only way to request changes. This allows the compiler to ask a node how it would canonicalize itself without actually committing the changes. If you need to do more, use the Simplifiable interface. The assertion you might see is ?new node created while canonicalizing SomeNode: NewNode?. - Node inputs can now be defined to allow null values by declaring them as @OptionalInput instead of @Input. @Input fields will be checked for null values by assertions during graph verification. The assertion you might see is ?non-optional input fieldName cannot be null in SomeNode (fix nullness or use @OptionalInput)"?. cheers, Lukas From thomas.wuerthinger at oracle.com Tue Jul 1 14:11:22 2014 From: thomas.wuerthinger at oracle.com (Thomas Wuerthinger) Date: Tue, 1 Jul 2014 16:11:22 +0200 Subject: webrev-hsail-transcendentals In-Reply-To: <2F413CD7-D39C-4984-8F45-30983C1925F4@oracle.com> References: <2F413CD7-D39C-4984-8F45-30983C1925F4@oracle.com> Message-ID: <54571A28-2BFE-4B17-9209-AA0364584F1D@oracle.com> Tom, We cannot ourselves change the copyright header. Either Gustav contributes the code under the current OCA or he shares copyright with AMD such that you can yourself contribute. Thanks, thomas On 01 Jul 2014, at 08:34, Doug Simon wrote: > I will integrate this patch. However, to do so, I need to change the header for JStrictMath so that it passes ?mx checkheaders'. The header is currently: > > /* > * Copyright 1999-2006 Sun Microsystems, Inc. All rights reserved. > * SUN PROPRIETARY/CONFIDENTIAL. Use is subject to license terms. > */ > > Can we simply change this to the expected Oracle copyright header? > > -Doug > > On Jun 30, 2014, at 9:56 PM, Deneau, Tom wrote: > >> Please review the following webrev which adds support for several missing java.lang.Math routines to the HSAIL backend. >> http://cr.openjdk.java.net/~tdeneau/graal-webrevs/webrev-hsail-transcendentals/webrev/ >> >> Many of these routines were declared as native in the regular host backends, but HSAIL has no way to invoke host code from the kernels. But if we could find java implementations of these methods we could use those thru the graal MethodSubstitution framework. For the java implementations, we basically used a file StrictMath.java which Gustav Trede donated to OpenJDK back in 2009 as a java port of the C FDLIBM routines, thank you Gustav. >> http://mail.openjdk.java.net/pipermail/hotspot-dev/2009-August/001992.html >> >> We made only a few minor changes to that file. My understanding from Joe Darcy is that in Java 9 there will be an official port of FDLIBM to java in the JDK, so when that happens we should be able to use that instead. >> >> >> Notes: >> >> * JStrictMath.java is the java implementation of the Math routines noted above. HSAILMathSubstitutions redirects several methods to there. In addition test cases were added for many Math routines which were already implemented as java methods in java.lang.Math. >> >> * GraalTest -- >> >> o Since the java spec specifies the tolerance for most of these Math routines in terms of ULPs, I wanted to enable a way for AssertEquals to use ULPs rather than a constant maximum delta. This is done by overriding protected int ulpsDelta() to return something other than zero. >> >> * HSAILAssembler >> >> o fix the printing of some special Double and Float constants >> >> o cvt for float to integer uses zeroi_sat (saturate) >> >> * HSAILLIRGenerator & HSAILControlFlow >> >> o IntegerTestMove support was required by some of the java implementations >> >> * all the rest are just junit tests. >> >> All junit tests should pass on the simulator. These math routines have also been useful in solidifying the hsail hardware implementation. >> >> -- Tom >> > From tom.deneau at amd.com Tue Jul 1 14:44:51 2014 From: tom.deneau at amd.com (Deneau, Tom) Date: Tue, 1 Jul 2014 14:44:51 +0000 Subject: webrev-hsail-transcendentals In-Reply-To: <54571A28-2BFE-4B17-9209-AA0364584F1D@oracle.com> References: <2F413CD7-D39C-4984-8F45-30983C1925F4@oracle.com> <54571A28-2BFE-4B17-9209-AA0364584F1D@oracle.com> Message-ID: OK, I hadn't contacted Gustav because when I originally asked if this was OK to use the reply was 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'll see if I can contact him now. -- Tom Deneau -----Original Message----- From: Thomas Wuerthinger [mailto:thomas.wuerthinger at oracle.com] Sent: Tuesday, July 01, 2014 9:11 AM To: Deneau, Tom Cc: graal-dev at openjdk.java.net; Doug Simon Subject: Re: webrev-hsail-transcendentals Tom, We cannot ourselves change the copyright header. Either Gustav contributes the code under the current OCA or he shares copyright with AMD such that you can yourself contribute. Thanks, thomas On 01 Jul 2014, at 08:34, Doug Simon wrote: > I will integrate this patch. However, to do so, I need to change the header for JStrictMath so that it passes 'mx checkheaders'. The header is currently: > > /* > * Copyright 1999-2006 Sun Microsystems, Inc. All rights reserved. > * SUN PROPRIETARY/CONFIDENTIAL. Use is subject to license terms. > */ > > Can we simply change this to the expected Oracle copyright header? > > -Doug > > On Jun 30, 2014, at 9:56 PM, Deneau, Tom wrote: > >> Please review the following webrev which adds support for several missing java.lang.Math routines to the HSAIL backend. >> http://cr.openjdk.java.net/~tdeneau/graal-webrevs/webrev-hsail-transcendentals/webrev/ >> >> Many of these routines were declared as native in the regular host backends, but HSAIL has no way to invoke host code from the kernels. But if we could find java implementations of these methods we could use those thru the graal MethodSubstitution framework. For the java implementations, we basically used a file StrictMath.java which Gustav Trede donated to OpenJDK back in 2009 as a java port of the C FDLIBM routines, thank you Gustav. >> http://mail.openjdk.java.net/pipermail/hotspot-dev/2009-August/001992.html >> >> We made only a few minor changes to that file. My understanding from Joe Darcy is that in Java 9 there will be an official port of FDLIBM to java in the JDK, so when that happens we should be able to use that instead. >> >> >> Notes: >> >> * JStrictMath.java is the java implementation of the Math routines noted above. HSAILMathSubstitutions redirects several methods to there. In addition test cases were added for many Math routines which were already implemented as java methods in java.lang.Math. >> >> * GraalTest -- >> >> o Since the java spec specifies the tolerance for most of these Math routines in terms of ULPs, I wanted to enable a way for AssertEquals to use ULPs rather than a constant maximum delta. This is done by overriding protected int ulpsDelta() to return something other than zero. >> >> * HSAILAssembler >> >> o fix the printing of some special Double and Float constants >> >> o cvt for float to integer uses zeroi_sat (saturate) >> >> * HSAILLIRGenerator & HSAILControlFlow >> >> o IntegerTestMove support was required by some of the java implementations >> >> * all the rest are just junit tests. >> >> All junit tests should pass on the simulator. These math routines have also been useful in solidifying the hsail hardware implementation. >> >> -- Tom >> > From tom.deneau at amd.com Tue Jul 1 15:21:11 2014 From: tom.deneau at amd.com (Deneau, Tom) Date: Tue, 1 Jul 2014 15:21:11 +0000 Subject: copyright on your FDLIBM java port Message-ID: adding graal-dev to the copy list... Hi Gustav -- My name is Tom Deneau and myself and some colleagues here at AMD have been working adding an HSA backend to the OpenJDK graal project. http://openjdk.java.net/projects/graal/ (HSA is an architecture for offloading computation to GPUs). One of the things we wanted to enable was the java.lang.Math functions with the necessary accuracy. We cannot use the native host implementations of these math functions from the GPU but Graal provided a way (called MethodSubstitution) to override the java.lang.Math native routines with java routines. We saw your port of FDLIBM back posted back in Aug 2009 and thought that would be good to use for this purpose. http://mail.openjdk.java.net/pipermail/hotspot-dev/2009-August/001992.html. It is nicely written code and is working well for us in our testing but when we wanted to contribute the code to the graal project, there seems to be an issue with the copyright header which you can read below. The graal webrev we are contributing along with a very slightly modified version of your original contribution can be seen here. http://cr.openjdk.java.net/~tdeneau/graal-webrevs/webrev-hsail-transcendentals/webrev/ Is it OK to change the copyright header to the current Oracle OpenJDK copyright header shown here... -- Tom Deneau 1 /* 2 * Copyright (c) 2009, 2014, Oracle and/or its affiliates. All rights reserved. 3 * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. 4 * 5 * This code is free software; you can redistribute it and/or modify it 6 * under the terms of the GNU General Public License version 2 only, as 7 * published by the Free Software Foundation. 8 * 9 * This code is distributed in the hope that it will be useful, but WITHOUT 10 * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or 11 * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License 12 * version 2 for more details (a copy is included in the LICENSE file that 13 * accompanied this code). 14 * 15 * You should have received a copy of the GNU General Public License version 16 * 2 along with this work; if not, write to the Free Software Foundation, 17 * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA. 18 * 19 * Please contact Oracle, 500 Oracle Parkway, Redwood Shores, CA 94065 USA 20 * or visit www.oracle.com if you need additional information or have any 21 * questions. 22 */ 23 -----Original Message----- From: Thomas Wuerthinger [mailto:thomas.wuerthinger at oracle.com] Sent: Tuesday, July 01, 2014 9:11 AM To: Deneau, Tom Cc: graal-dev at openjdk.java.net; Doug Simon Subject: Re: webrev-hsail-transcendentals Tom, We cannot ourselves change the copyright header. Either Gustav contributes the code under the current OCA or he shares copyright with AMD such that you can yourself contribute. Thanks, thomas On 01 Jul 2014, at 08:34, Doug Simon > wrote: > I will integrate this patch. However, to do so, I need to change the header for JStrictMath so that it passes 'mx checkheaders'. The header is currently: > > /* > * Copyright 1999-2006 Sun Microsystems, Inc. All rights reserved. > * SUN PROPRIETARY/CONFIDENTIAL. Use is subject to license terms. > */ > > Can we simply change this to the expected Oracle copyright header? > > -Doug > > On Jun 30, 2014, at 9:56 PM, Deneau, Tom > wrote: > >> Please review the following webrev which adds support for several missing java.lang.Math routines to the HSAIL backend. >> http://cr.openjdk.java.net/~tdeneau/graal-webrevs/webrev-hsail-transcendentals/webrev/ >> >> Many of these routines were declared as native in the regular host backends, but HSAIL has no way to invoke host code from the kernels. But if we could find java implementations of these methods we could use those thru the graal MethodSubstitution framework. For the java implementations, we basically used a file StrictMath.java which Gustav Trede donated to OpenJDK back in 2009 as a java port of the C FDLIBM routines, thank you Gustav. >> http://mail.openjdk.java.net/pipermail/hotspot-dev/2009-August/001992.html >> >> We made only a few minor changes to that file. My understanding from Joe Darcy is that in Java 9 there will be an official port of FDLIBM to java in the JDK, so when that happens we should be able to use that instead. >> >> >> Notes: >> >> * JStrictMath.java is the java implementation of the Math routines noted above. HSAILMathSubstitutions redirects several methods to there. In addition test cases were added for many Math routines which were already implemented as java methods in java.lang.Math. >> >> * GraalTest -- >> >> o Since the java spec specifies the tolerance for most of these Math routines in terms of ULPs, I wanted to enable a way for AssertEquals to use ULPs rather than a constant maximum delta. This is done by overriding protected int ulpsDelta() to return something other than zero. >> >> * HSAILAssembler >> >> o fix the printing of some special Double and Float constants >> >> o cvt for float to integer uses zeroi_sat (saturate) >> >> * HSAILLIRGenerator & HSAILControlFlow >> >> o IntegerTestMove support was required by some of the java implementations >> >> * all the rest are just junit tests. >> >> All junit tests should pass on the simulator. These math routines have also been useful in solidifying the hsail hardware implementation. >> >> -- Tom >> > From tom.deneau at amd.com Tue Jul 1 20:51:52 2014 From: tom.deneau at amd.com (Deneau, Tom) Date: Tue, 1 Jul 2014 20:51:52 +0000 Subject: copyright on your FDLIBM java port In-Reply-To: References: Message-ID: Thank you Gustav. Doug S. or Thomas W. -- Can someone send Gustav for his review the proposed new header with the "contributed by" tag he is asking for. Myself I am not sure what the official format is for such a tag. -- Tom From: gustav [mailto:gustav.trede at gmail.com] Sent: Tuesday, July 01, 2014 3:27 PM To: Deneau, Tom Cc: graal-dev at openjdk.java.net; dl.Runtimes Subject: Re: copyright on your FDLIBM java port hello , Im happy my code found some usage :) I gladly do whatever is most convenient and flexible for you regarding license as long as there is a written or contributed tag in the header with my name. best regards Gustav Trede On 1 July 2014 17:21, Deneau, Tom > wrote: adding graal-dev to the copy list? Hi Gustav -- My name is Tom Deneau and myself and some colleagues here at AMD have been working adding an HSA backend to the OpenJDK graal project. http://openjdk.java.net/projects/graal/ (HSA is an architecture for offloading computation to GPUs). One of the things we wanted to enable was the java.lang.Math functions with the necessary accuracy. We cannot use the native host implementations of these math functions from the GPU but Graal provided a way (called MethodSubstitution) to override the java.lang.Math native routines with java routines. We saw your port of FDLIBM back posted back in Aug 2009 and thought that would be good to use for this purpose. http://mail.openjdk.java.net/pipermail/hotspot-dev/2009-August/001992.html. It is nicely written code and is working well for us in our testing but when we wanted to contribute the code to the graal project, there seems to be an issue with the copyright header which you can read below. The graal webrev we are contributing along with a very slightly modified version of your original contribution can be seen here. http://cr.openjdk.java.net/~tdeneau/graal-webrevs/webrev-hsail-transcendentals/webrev/ Is it OK to change the copyright header to the current Oracle OpenJDK copyright header shown here... -- Tom Deneau 1 /* 2 * Copyright (c) 2009, 2014, Oracle and/or its affiliates. All rights reserved. 3 * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. 4 * 5 * This code is free software; you can redistribute it and/or modify it 6 * under the terms of the GNU General Public License version 2 only, as 7 * published by the Free Software Foundation. 8 * 9 * This code is distributed in the hope that it will be useful, but WITHOUT 10 * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or 11 * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License 12 * version 2 for more details (a copy is included in the LICENSE file that 13 * accompanied this code). 14 * 15 * You should have received a copy of the GNU General Public License version 16 * 2 along with this work; if not, write to the Free Software Foundation, 17 * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA. 18 * 19 * Please contact Oracle, 500 Oracle Parkway, Redwood Shores, CA 94065 USA 20 * or visit www.oracle.com if you need additional information or have any 21 * questions. 22 */ 23 -----Original Message----- From: Thomas Wuerthinger [mailto:thomas.wuerthinger at oracle.com] Sent: Tuesday, July 01, 2014 9:11 AM To: Deneau, Tom Cc: graal-dev at openjdk.java.net; Doug Simon Subject: Re: webrev-hsail-transcendentals Tom, We cannot ourselves change the copyright header. Either Gustav contributes the code under the current OCA or he shares copyright with AMD such that you can yourself contribute. Thanks, thomas On 01 Jul 2014, at 08:34, Doug Simon > wrote: > I will integrate this patch. However, to do so, I need to change the header for JStrictMath so that it passes ?mx checkheaders'. The header is currently: > > /* > * Copyright 1999-2006 Sun Microsystems, Inc. All rights reserved. > * SUN PROPRIETARY/CONFIDENTIAL. Use is subject to license terms. > */ > > Can we simply change this to the expected Oracle copyright header? > > -Doug > > On Jun 30, 2014, at 9:56 PM, Deneau, Tom > wrote: > >> Please review the following webrev which adds support for several missing java.lang.Math routines to the HSAIL backend. >> http://cr.openjdk.java.net/~tdeneau/graal-webrevs/webrev-hsail-transcendentals/webrev/ >> >> Many of these routines were declared as native in the regular host backends, but HSAIL has no way to invoke host code from the kernels. But if we could find java implementations of these methods we could use those thru the graal MethodSubstitution framework. For the java implementations, we basically used a file StrictMath.java which Gustav Trede donated to OpenJDK back in 2009 as a java port of the C FDLIBM routines, thank you Gustav. >> http://mail.openjdk.java.net/pipermail/hotspot-dev/2009-August/001992.html >> >> We made only a few minor changes to that file. My understanding from Joe Darcy is that in Java 9 there will be an official port of FDLIBM to java in the JDK, so when that happens we should be able to use that instead. >> >> >> Notes: >> >> * JStrictMath.java is the java implementation of the Math routines noted above. HSAILMathSubstitutions redirects several methods to there. In addition test cases were added for many Math routines which were already implemented as java methods in java.lang.Math. >> >> * GraalTest -- >> >> o Since the java spec specifies the tolerance for most of these Math routines in terms of ULPs, I wanted to enable a way for AssertEquals to use ULPs rather than a constant maximum delta. This is done by overriding protected int ulpsDelta() to return something other than zero. >> >> * HSAILAssembler >> >> o fix the printing of some special Double and Float constants >> >> o cvt for float to integer uses zeroi_sat (saturate) >> >> * HSAILLIRGenerator & HSAILControlFlow >> >> o IntegerTestMove support was required by some of the java implementations >> >> * all the rest are just junit tests. >> >> All junit tests should pass on the simulator. These math routines have also been useful in solidifying the hsail hardware implementation. >> >> -- Tom >> > From thomas.wuerthinger at oracle.com Tue Jul 1 21:28:47 2014 From: thomas.wuerthinger at oracle.com (Thomas Wuerthinger) Date: Tue, 1 Jul 2014 23:28:47 +0200 Subject: copyright on your FDLIBM java port In-Reply-To: References: Message-ID: <5C6DFF2D-A1AB-4D80-8F39-AD03975D2B43@oracle.com> Gustav, Thank you very much for the possible contribution. We can acknowledge the authorship of the contribution both with a ?Contributed-By:? commit message as well as with a mention of the author in the initial version of the contributed code. We can however not provide a special header and/or a commitment that such attribution will continue to exist in all future derivatives of the code. Such conditions are incompatible with the Oracle Contributor Agreement (OCA) [1], which is the only way we are allowed to receive contributions to our OpenJDK project. Please let us know whether this is OK for you and that you can contribute the code under the terms of the OCA. Thanks, thomas [1] http://www.oracle.com/technetwork/community/oca-486395.html On 01 Jul 2014, at 22:51, Deneau, Tom wrote: > Thank you Gustav. > > Doug S. or Thomas W. -- > > Can someone send Gustav for his review the proposed new header with the "contributed by" tag he is asking for. Myself I am not sure what the official format is for such a tag. > > -- Tom > > > > From: gustav [mailto:gustav.trede at gmail.com] > Sent: Tuesday, July 01, 2014 3:27 PM > To: Deneau, Tom > Cc: graal-dev at openjdk.java.net; dl.Runtimes > Subject: Re: copyright on your FDLIBM java port > > hello , > > Im happy my code found some usage :) > I gladly do whatever is most convenient and flexible for you regarding license as long as there is a written or contributed tag in the header with my name. > > best regards > Gustav Trede > > On 1 July 2014 17:21, Deneau, Tom > wrote: > > adding graal-dev to the copy list? > > > > Hi Gustav -- > > > > My name is Tom Deneau and myself and some colleagues here at AMD have been working adding an HSA backend to the OpenJDK graal project. http://openjdk.java.net/projects/graal/ (HSA is an architecture for offloading computation to GPUs). > > > > One of the things we wanted to enable was the java.lang.Math functions with the necessary accuracy. We cannot use the native host implementations of these math functions from the GPU but Graal provided a way (called MethodSubstitution) to override the java.lang.Math native routines with java routines. > > > > We saw your port of FDLIBM back posted back in Aug 2009 and thought that would be good to use for this purpose. > > http://mail.openjdk.java.net/pipermail/hotspot-dev/2009-August/001992.html. It is nicely written code and is working well for us in our testing but when we wanted to contribute the code to the graal project, there seems to be an issue with the copyright header which you can read below. > > > > The graal webrev we are contributing along with a very slightly modified version of your original contribution can be seen here. http://cr.openjdk.java.net/~tdeneau/graal-webrevs/webrev-hsail-transcendentals/webrev/ > > > > Is it OK to change the copyright header to the current Oracle OpenJDK copyright header shown here... > > > > -- Tom Deneau > > > > > > 1 /* > > 2 * Copyright (c) 2009, 2014, Oracle and/or its affiliates. All rights reserved. > > 3 * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. > > 4 * > > 5 * This code is free software; you can redistribute it and/or modify it > > 6 * under the terms of the GNU General Public License version 2 only, as > > 7 * published by the Free Software Foundation. > > 8 * > > 9 * This code is distributed in the hope that it will be useful, but WITHOUT > > 10 * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or > > 11 * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License > > 12 * version 2 for more details (a copy is included in the LICENSE file that > > 13 * accompanied this code). > > 14 * > > 15 * You should have received a copy of the GNU General Public License version > > 16 * 2 along with this work; if not, write to the Free Software Foundation, > > 17 * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA. > > 18 * > > 19 * Please contact Oracle, 500 Oracle Parkway, Redwood Shores, CA 94065 USA > > 20 * or visit www.oracle.com if you need additional information or have any > > 21 * questions. > > 22 */ > > 23 > > > > -----Original Message----- > > From: Thomas Wuerthinger [mailto:thomas.wuerthinger at oracle.com] > > Sent: Tuesday, July 01, 2014 9:11 AM > > To: Deneau, Tom > > Cc: graal-dev at openjdk.java.net; Doug Simon > > Subject: Re: webrev-hsail-transcendentals > > > > Tom, > > > > We cannot ourselves change the copyright header. Either Gustav contributes the code under the current OCA or he shares copyright with AMD such that you can yourself contribute. > > > > Thanks, thomas > > > > On 01 Jul 2014, at 08:34, Doug Simon > wrote: > > > >> I will integrate this patch. However, to do so, I need to change the header for JStrictMath so that it passes ?mx checkheaders'. The header is currently: > >> > >> /* > >> * Copyright 1999-2006 Sun Microsystems, Inc. All rights reserved. > >> * SUN PROPRIETARY/CONFIDENTIAL. Use is subject to license terms. > >> */ > >> > >> Can we simply change this to the expected Oracle copyright header? > >> > >> -Doug > >> > >> On Jun 30, 2014, at 9:56 PM, Deneau, Tom > wrote: > >> > >>> Please review the following webrev which adds support for several missing java.lang.Math routines to the HSAIL backend. > >>> http://cr.openjdk.java.net/~tdeneau/graal-webrevs/webrev-hsail-transcendentals/webrev/ > > > >>> > >>> Many of these routines were declared as native in the regular host backends, but HSAIL has no way to invoke host code from the kernels. But if we could find java implementations of these methods we could use those thru the graal MethodSubstitution framework. For the java implementations, we basically used a file StrictMath.java which Gustav Trede donated to OpenJDK back in 2009 as a java port of the C FDLIBM routines, thank you Gustav. > >>> http://mail.openjdk.java.net/pipermail/hotspot-dev/2009-August/001992.html > >>> > >>> We made only a few minor changes to that file. My understanding from Joe Darcy is that in Java 9 there will be an official port of FDLIBM to java in the JDK, so when that happens we should be able to use that instead. > >>> > >>> > >>> Notes: > >>> > >>> * JStrictMath.java is the java implementation of the Math routines noted above. HSAILMathSubstitutions redirects several methods to there. In addition test cases were added for many Math routines which were already implemented as java methods in java.lang.Math. > >>> > >>> * GraalTest -- > >>> > >>> o Since the java spec specifies the tolerance for most of these Math routines in terms of ULPs, I wanted to enable a way for AssertEquals to use ULPs rather than a constant maximum delta. This is done by overriding protected int ulpsDelta() to return something other than zero. > >>> > >>> * HSAILAssembler > >>> > >>> o fix the printing of some special Double and Float constants > >>> > >>> o cvt for float to integer uses zeroi_sat (saturate) > >>> > >>> * HSAILLIRGenerator & HSAILControlFlow > >>> > >>> o IntegerTestMove support was required by some of the java implementations > >>> > >>> * all the rest are just junit tests. > >>> > >>> All junit tests should pass on the simulator. These math routines have also been useful in solidifying the hsail hardware implementation. > >>> > >>> -- Tom > >>> > >> > > > > From doug.simon at oracle.com Wed Jul 2 01:00:06 2014 From: doug.simon at oracle.com (doug.simon at oracle.com) Date: Wed, 02 Jul 2014 01:00:06 +0000 Subject: hg: graal/graal: 18 new changesets Message-ID: <201407020100.s62107ov026137@aojmv0008> Changeset: 524f5cf6cb95 Author: Michael Van De Vanter Date: 2014-06-30 19:34 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/524f5cf6cb95 Truffle/Source: add a singleton null instance of SourceCallback ! graal/com.oracle.truffle.api/src/com/oracle/truffle/api/instrument/SourceCallback.java Changeset: c88a9e432faf Author: Lukas Stadler Date: 2014-07-01 11:37 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/c88a9e432faf small fix and doc for @OptionalInput ! graal/com.oracle.graal.graph/src/com/oracle/graal/graph/Node.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/FrameState.java Changeset: 67f3267a8846 Author: Lukas Stadler Date: 2014-07-01 12:14 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/67f3267a8846 code and javadoc cleanups in Canonicalizable and NodeClassIterable ! graal/com.oracle.graal.graph/src/com/oracle/graal/graph/NodeClass.java ! graal/com.oracle.graal.graph/src/com/oracle/graal/graph/NodeClassIterable.java ! graal/com.oracle.graal.graph/src/com/oracle/graal/graph/spi/Canonicalizable.java ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/CanonicalizerPhase.java Changeset: 2cc0fea0cff6 Author: Lukas Stadler Date: 2014-07-01 14:57 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/2cc0fea0cff6 fix ReadNode canonicalization for guard-type usages of null-checking reads ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/extended/ReadNode.java ! graal/com.oracle.graal.word/src/com/oracle/graal/word/nodes/WordCastNode.java Changeset: 0ffff2c5e44e Author: Doug Simon Date: 2014-07-01 09:48 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/0ffff2c5e44e removed debug code ! graal/com.oracle.graal.printer/src/com/oracle/graal/printer/NoDeadCodeVerifyHandler.java Changeset: e7af30d6ae5b Author: Doug Simon Date: 2014-07-01 11:48 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/e7af30d6ae5b remove frame state manipulation after a DeoptimizeNode is appended as the state will never be used; remove unused ParameterNodes from a graph ! graal/com.oracle.graal.java/src/com/oracle/graal/java/GraphBuilderPhase.java Changeset: 627f255ee298 Author: Doug Simon Date: 2014-07-01 12:05 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/627f255ee298 made InductionVariable.deleteUnusedNodes() abstract ! graal/com.oracle.graal.loop/src/com/oracle/graal/loop/BasicInductionVariable.java ! graal/com.oracle.graal.loop/src/com/oracle/graal/loop/DerivedOffsetInductionVariable.java ! graal/com.oracle.graal.loop/src/com/oracle/graal/loop/InductionVariable.java Changeset: e17a0f85e0af Author: Doug Simon Date: 2014-07-01 12:10 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/e17a0f85e0af made IfCanonicalizerTest clean up dead nodes it creates ! graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/IfCanonicalizerTest.java Changeset: a415b3990811 Author: Doug Simon Date: 2014-07-01 15:42 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/a415b3990811 made FloatingReadNode clean up dead nodes it creates ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/FloatingReadPhase.java Changeset: 6f70e0b85e91 Author: Doug Simon Date: 2014-07-01 15:45 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/6f70e0b85e91 Merge. Changeset: d0c5f9bc7d98 Author: Roland Schatz Date: 2014-07-01 15:37 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/d0c5f9bc7d98 Fix c1visualizer dump. ! graal/com.oracle.graal.printer/src/com/oracle/graal/printer/CFGPrinter.java Changeset: bbf051d717f5 Author: Roland Schatz Date: 2014-07-01 16:06 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/bbf051d717f5 Propagate reference information through arithmetics. ! graal/com.oracle.graal.api.meta/src/com/oracle/graal/api/meta/LIRKind.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.sparc/src/com/oracle/graal/lir/sparc/SPARCArithmetic.java ! graal/com.oracle.graal.lir.sparc/src/com/oracle/graal/lir/sparc/SPARCBitManipulationOp.java ! graal/com.oracle.graal.word/src/com/oracle/graal/word/nodes/WordCastNode.java Changeset: c6a1215d025b Author: Roland Schatz Date: 2014-07-01 17:04 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/c6a1215d025b Improve documentation of LIRKind. ! graal/com.oracle.graal.api.meta/src/com/oracle/graal/api/meta/LIRKind.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 Changeset: fefb82b01d6f Author: Gilles Duboscq Date: 2014-06-27 11:50 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/fefb82b01d6f Make find_method_handle_intrinsic work in Xint mode ! src/share/vm/classfile/systemDictionary.cpp Changeset: 5a3351bb88a8 Author: Gilles Duboscq Date: 2014-07-01 18:08 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/5a3351bb88a8 Minor refactoring in LoopFragment.mergeEarlyExits to improve readability ! graal/com.oracle.graal.loop/src/com/oracle/graal/loop/LoopFragment.java Changeset: 6055f84e41d7 Author: Gilles Duboscq Date: 2014-07-01 18:10 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/6055f84e41d7 LoopFragmentInside: make sure no dead phi are left after phis have been rewritten ! graal/com.oracle.graal.loop/src/com/oracle/graal/loop/LoopFragmentInside.java Changeset: 3e341c30e5c0 Author: Gilles Duboscq Date: 2014-07-01 18:26 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/3e341c30e5c0 No need to duplicate the loop begin's state for LoopFragmentInside ! graal/com.oracle.graal.loop/src/com/oracle/graal/loop/LoopFragmentInside.java Changeset: 00460aab5c96 Author: Gilles Duboscq Date: 2014-07-01 19:06 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/00460aab5c96 Make sure LoopEx.reassociateInvariants doesn't leave dead nodes behind ! graal/com.oracle.graal.loop/src/com/oracle/graal/loop/LoopEx.java From tom.deneau at amd.com Wed Jul 2 20:45:37 2014 From: tom.deneau at amd.com (Deneau, Tom) Date: Wed, 2 Jul 2014 20:45:37 +0000 Subject: copyright on your FDLIBM java port In-Reply-To: <8892E551-BDF3-48EB-9858-F27D46F32146@oracle.com> References: <5C6DFF2D-A1AB-4D80-8F39-AD03975D2B43@oracle.com> <373F3241-9BE7-44EB-8329-1DAC18210D15@oracle.com> <8892E551-BDF3-48EB-9858-F27D46F32146@oracle.com> Message-ID: I have placed a new webrev with the javadoc modifications up at http://cr.openjdk.java.net/~tdeneau/graal-webrevs/webrev-hsail-transcendentals-v2/webrev/ (also merged with the later default tip). -- Tom From: Thomas Wuerthinger [mailto:thomas.wuerthinger at oracle.com] Sent: Tuesday, July 01, 2014 7:19 PM To: Deneau, Tom Cc: Doug Simon; gustav; dl.Runtimes Subject: Re: copyright on your FDLIBM java port I think this is fine. But we should somehow document that the class derives from (or tries to reimplement in Java the native methods defined in) java.lang.StrictMath. - thomas On 02 Jul 2014, at 00:14, Deneau, Tom > wrote: Thomas, Doug -- Would this be correct for the javadoc? Previously there were two @author lines, * @author unascribed * @author Joseph D. Darcy or should I leave Joseph's name there? -- Tom /** * The class {@code JStrictMath} contains methods for performing basic numeric operations such as * the elementary exponential, logarithm, square root, and trigonometric functions. * *

* To help ensure portability of Java programs, the definitions of some of the numeric functions in * this package require that they produce the same results as certain published algorithms. These * algorithms are available from the well-known network library {@code netlib} as the package * "Freely Distributable Math Library," {@code fdlibm} * . These algorithms, which are written in the C programming language, are then to be * understood as executed with all floating-point operations following the rules of Java * floating-point arithmetic. * *

* The Java math library is defined with respect to {@code fdlibm} version 5.3. Where {@code fdlibm} * provides more than one definition for a function (such as {@code acos}), use the * "IEEE 754 core function" version (residing in a file whose name begins with the letter {@code e} * ). The methods which require {@code fdlibm} semantics are {@code sin}, {@code cos}, {@code tan}, * {@code asin}, {@code acos}, {@code atan}, {@code exp}, {@code log}, {@code log10}, {@code cbrt}, * {@code atan2}, {@code pow}, {@code sinh}, {@code cosh}, {@code tanh}, {@code hypot}, * {@code expm1}, and {@code log1p}. * * @author Gustav Trede * @since 1.3 */ From: Thomas Wuerthinger [mailto:thomas.wuerthinger at oracle.com] Sent: Tuesday, July 01, 2014 4:43 PM To: Deneau, Tom Cc: Doug Simon Subject: Re: copyright on your FDLIBM java port Tom, you can go ahead preparing the webref with the standard header and a comment in the classes' javadoc that the code was contributed by gustav. - thomas On 01 Jul 2014, at 23:37, gustav > wrote: thats ok for me. i have already signed the sun contributor agreement a long time ago. i tried to contribute my code to the openjdk. but there was a lack of QA resources ... On 1 July 2014 23:28, Thomas Wuerthinger > wrote: Gustav, Thank you very much for the possible contribution. We can acknowledge the authorship of the contribution both with a "Contributed-By:" commit message as well as with a mention of the author in the initial version of the contributed code. We can however not provide a special header and/or a commitment that such attribution will continue to exist in all future derivatives of the code. Such conditions are incompatible with the Oracle Contributor Agreement (OCA) [1], which is the only way we are allowed to receive contributions to our OpenJDK project. Please let us know whether this is OK for you and that you can contribute the code under the terms of the OCA. Thanks, thomas [1] http://www.oracle.com/technetwork/community/oca-486395.html On 01 Jul 2014, at 22:51, Deneau, Tom > wrote: Thank you Gustav. Doug S. or Thomas W. -- Can someone send Gustav for his review the proposed new header with the "contributed by" tag he is asking for. Myself I am not sure what the official format is for such a tag. -- Tom From: gustav [mailto:gustav.trede at gmail.com] Sent: Tuesday, July 01, 2014 3:27 PM To: Deneau, Tom Cc: graal-dev at openjdk.java.net; dl.Runtimes Subject: Re: copyright on your FDLIBM java port hello , Im happy my code found some usage :) I gladly do whatever is most convenient and flexible for you regarding license as long as there is a written or contributed tag in the header with my name. best regards Gustav Trede On 1 July 2014 17:21, Deneau, Tom > wrote: adding graal-dev to the copy list... Hi Gustav -- My name is Tom Deneau and myself and some colleagues here at AMD have been working adding an HSA backend to the OpenJDK graal project. http://openjdk.java.net/projects/graal/ (HSA is an architecture for offloading computation to GPUs). One of the things we wanted to enable was the java.lang.Math functions with the necessary accuracy. We cannot use the native host implementations of these math functions from the GPU but Graal provided a way (called MethodSubstitution) to override the java.lang.Math native routines with java routines. We saw your port of FDLIBM back posted back in Aug 2009 and thought that would be good to use for this purpose. http://mail.openjdk.java.net/pipermail/hotspot-dev/2009-August/001992.html. It is nicely written code and is working well for us in our testing but when we wanted to contribute the code to the graal project, there seems to be an issue with the copyright header which you can read below. The graal webrev we are contributing along with a very slightly modified version of your original contribution can be seen here. http://cr.openjdk.java.net/~tdeneau/graal-webrevs/webrev-hsail-transcendentals/webrev/ Is it OK to change the copyright header to the current Oracle OpenJDK copyright header shown here... -- Tom Deneau 1 /* 2 * Copyright (c) 2009, 2014, Oracle and/or its affiliates. All rights reserved. 3 * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. 4 * 5 * This code is free software; you can redistribute it and/or modify it 6 * under the terms of the GNU General Public License version 2 only, as 7 * published by the Free Software Foundation. 8 * 9 * This code is distributed in the hope that it will be useful, but WITHOUT 10 * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or 11 * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License 12 * version 2 for more details (a copy is included in the LICENSE file that 13 * accompanied this code). 14 * 15 * You should have received a copy of the GNU General Public License version 16 * 2 along with this work; if not, write to the Free Software Foundation, 17 * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA. 18 * 19 * Please contact Oracle, 500 Oracle Parkway, Redwood Shores, CA 94065 USA 20 * or visit www.oracle.com> if you need additional information or have any 21 * questions. 22 */ 23 -----Original Message----- From: Thomas Wuerthinger [mailto:thomas.wuerthinger at oracle.com] Sent: Tuesday, July 01, 2014 9:11 AM To: Deneau, Tom Cc: graal-dev at openjdk.java.net; Doug Simon Subject: Re: webrev-hsail-transcendentals Tom, We cannot ourselves change the copyright header. Either Gustav contributes the code under the current OCA or he shares copyright with AMD such that you can yourself contribute. Thanks, thomas On 01 Jul 2014, at 08:34, Doug Simon > wrote: I will integrate this patch. However, to do so, I need to change the header for JStrictMath so that it passes 'mx checkheaders'. The header is currently: /* * Copyright 1999-2006 Sun Microsystems, Inc. All rights reserved. * SUN PROPRIETARY/CONFIDENTIAL. Use is subject to license terms. */ Can we simply change this to the expected Oracle copyright header? -Doug On Jun 30, 2014, at 9:56 PM, Deneau, Tom > wrote: Please review the following webrev which adds support for several missing java.lang.Math routines to the HSAIL backend. http://cr.openjdk.java.net/~tdeneau/graal-webrevs/webrev-hsail-transcendentals/webrev/ Many of these routines were declared as native in the regular host backends, but HSAIL has no way to invoke host code from the kernels. But if we could find java implementations of these methods we could use those thru the graal MethodSubstitution framework. For the java implementations, we basically used a file StrictMath.java which Gustav Trede donated to OpenJDK back in 2009 as a java port of the C FDLIBM routines, thank you Gustav. http://mail.openjdk.java.net/pipermail/hotspot-dev/2009-August/001992.html We made only a few minor changes to that file. My understanding from Joe Darcy is that in Java 9 there will be an official port of FDLIBM to java in the JDK, so when that happens we should be able to use that instead. Notes: * JStrictMath.java is the java implementation of the Math routines noted above. HSAILMathSubstitutions redirects several methods to there. In addition test cases were added for many Math routines which were already implemented as java methods in java.lang.Math. * GraalTest -- o Since the java spec specifies the tolerance for most of these Math routines in terms of ULPs, I wanted to enable a way for AssertEquals to use ULPs rather than a constant maximum delta. This is done by overriding protected int ulpsDelta() to return something other than zero. * HSAILAssembler o fix the printing of some special Double and Float constants o cvt for float to integer uses zeroi_sat (saturate) * HSAILLIRGenerator & HSAILControlFlow o IntegerTestMove support was required by some of the java implementations * all the rest are just junit tests. All junit tests should pass on the simulator. These math routines have also been useful in solidifying the hsail hardware implementation. -- Tom From tom.deneau at amd.com Wed Jul 2 21:21:21 2014 From: tom.deneau at amd.com (Deneau, Tom) Date: Wed, 2 Jul 2014 21:21:21 +0000 Subject: the src (hotspot) tree in graal Message-ID: I noticed when I run hg tags on graal, the most recent hs tag in there is hs25-b63 So if I wanted to find all the hotspot tree diffs introduced in graal , would it be correct to diff vs. jdk8/jdk8/hotspot, tag hs25-63? How does the graal team manage the src (hotspot) tree when there is a new hotspot build? Is there a mercurial repository somewhere which contains the graal hotspot on a branch from the regular hotspot to help with merges? -- Tom From doug.simon at oracle.com Thu Jul 3 01:00:07 2014 From: doug.simon at oracle.com (doug.simon at oracle.com) Date: Thu, 03 Jul 2014 01:00:07 +0000 Subject: hg: graal/graal: 39 new changesets Message-ID: <201407030100.s63108Xx009873@aojmv0008> Changeset: 7c47610015a9 Author: Roland Schatz Date: 2014-07-02 14:56 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/7c47610015a9 Support direct memory compare of uncompressed metadata references if they fit in 32 bit. ! graal/com.oracle.graal.hotspot.amd64/src/com/oracle/graal/hotspot/amd64/AMD64HotSpotCompare.java Changeset: b6e70c59b32d Author: Josef Eisl Date: 2014-07-02 15:26 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/b6e70c59b32d Introduce InstructionStateProcedure. ! graal/com.oracle.graal.lir/src/com/oracle/graal/lir/LIRInstruction.java ! graal/com.oracle.graal.lir/src/com/oracle/graal/lir/LIRInstructionClass.java Changeset: eeb911056079 Author: Josef Eisl Date: 2014-07-02 15:29 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/eeb911056079 LinearScan: use InstructionStateProcedure. ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/alloc/LinearScan.java Changeset: 830fd9cd1099 Author: Josef Eisl Date: 2014-06-04 12:19 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/830fd9cd1099 And Interval.getSplitChildren(). ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/alloc/Interval.java Changeset: a07492ccaf52 Author: Josef Eisl Date: 2014-06-04 14:53 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/a07492ccaf52 LSRA spill optimization: calculate optimized spill position. ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/alloc/LinearScan.java Changeset: 9371b9c246ca Author: Josef Eisl Date: 2014-06-04 15:40 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/9371b9c246ca LSRA spill optimization: spill at earliest dominator. ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/alloc/Interval.java ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/alloc/LinearScan.java Changeset: f686fae77383 Author: Josef Eisl Date: 2014-06-04 16:05 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/f686fae77383 LSRA spill optimization: rename SpillInDominator.MultipleSpills to SpillState.SpillInDominator. ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/alloc/Interval.java ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/alloc/LinearScan.java Changeset: ec54fc47ba5d Author: Josef Eisl Date: 2014-06-04 16:54 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/ec54fc47ba5d LSRA spill optimization: move spill out of loops. ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/alloc/LinearScan.java Changeset: faff09aa5999 Author: Josef Eisl Date: 2014-06-04 19:43 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/faff09aa5999 LSRA spill optimization: only use predecessor block if it has lower probability than the definition. ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/alloc/LinearScan.java Changeset: b100bd079fff Author: Josef Eisl Date: 2014-06-05 10:36 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/b100bd079fff LSRA spill optimization: add -G:+LSRAOptimizeSpillPosition option (default: enabled). ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/alloc/LinearScan.java Changeset: a7d11e1c7387 Author: Josef Eisl Date: 2014-06-05 13:25 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/a7d11e1c7387 LSRA spill optimization: relax probability assertion. ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/alloc/LinearScan.java Changeset: a54a64af1e82 Author: Josef Eisl Date: 2014-06-05 16:38 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/a54a64af1e82 LSRA spill optimization: take all blocks (with usepos) of a spill interval into account. ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/alloc/LinearScan.java Changeset: d2fc1c153655 Author: Josef Eisl Date: 2014-06-10 13:29 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/d2fc1c153655 LSRA spill optimization: start at the begin of the spill interval. ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/alloc/LinearScan.java Changeset: 0abb7a42ef75 Author: Josef Eisl Date: 2014-06-10 16:43 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/0abb7a42ef75 LSRA spill optimization: insert the spill moves at the right position. ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/alloc/Interval.java ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/alloc/LinearScan.java Changeset: f0ac7457252a Author: Josef Eisl Date: 2014-06-11 14:49 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/f0ac7457252a LSRA spill optimization: use the correct from location for the spill move. ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/alloc/LinearScan.java Changeset: ef641ba1fb69 Author: Josef Eisl Date: 2014-06-11 14:51 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/ef641ba1fb69 LSRA spill optimization: mark the correct frame locations. ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/alloc/LinearScan.java Changeset: f8ba57019a5d Author: Josef Eisl Date: 2014-06-11 17:02 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/f8ba57019a5d LSRA spill optimization: move spill position to the dominator if at spill interval. ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/alloc/LinearScan.java Changeset: 3324ab9fe71a Author: Josef Eisl Date: 2014-06-11 17:03 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/3324ab9fe71a LSRA spill optimization: iterate all ranges of spill interval. ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/alloc/LinearScan.java Changeset: 3a997f63ddac Author: Josef Eisl Date: 2014-06-11 19:21 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/3a997f63ddac LSRA spill optimization: remove spill block probability assertion (temporarily). ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/alloc/LinearScan.java Changeset: 73d7935be896 Author: Josef Eisl Date: 2014-06-11 19:22 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/73d7935be896 LSRA: add debug scope for eliminateSpillMoves() and assignLocations(). ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/alloc/LinearScan.java Changeset: 74e93f5ba4f3 Author: Josef Eisl Date: 2014-06-11 20:24 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/74e93f5ba4f3 LSRA spill optimization: consider all spill blocks not only use positions. ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/alloc/LinearScan.java Changeset: d908e75a0990 Author: Josef Eisl Date: 2014-06-16 20:04 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/d908e75a0990 LSRA spill optimization: insert dominator spill move after data flow resolution moves. ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/alloc/LinearScan.java Changeset: ff14306337f2 Author: Josef Eisl Date: 2014-06-17 14:41 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/ff14306337f2 LSRA spill optimization: fix UseBlockIterator. ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/alloc/LinearScan.java Changeset: ef21879c0c8f Author: Josef Eisl Date: 2014-06-17 14:42 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/ef21879c0c8f LSRA spill optimization: rename UseBlockIterator to IntervalBlockIterator. ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/alloc/LinearScan.java Changeset: 62dd783630c4 Author: Josef Eisl Date: 2014-07-01 20:35 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/62dd783630c4 LSRA spill optimization: fix another spill move placement bug. ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/alloc/LinearScan.java Changeset: d075b97fbd31 Author: Josef Eisl Date: 2014-07-02 13:47 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/d075b97fbd31 LSRA spill optimization: insert spill moves eagerly. ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/alloc/LinearScan.java ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/alloc/RegisterVerifier.java Changeset: c5257d58b71a Author: Josef Eisl Date: 2014-07-02 13:52 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/c5257d58b71a LSRA spill optimization: backout changesets obsoleted by eager spill move placement. Backed out changeset: eab691cbd756 Backed out changeset: 014e70df5940 Backed out changeset: 2db7a64ba9dc Backed out changeset: 46be5e0a8a6e (partly) ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/alloc/LinearScan.java Changeset: 8057279ec60e Author: Josef Eisl Date: 2014-07-02 15:04 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/8057279ec60e LSRA spill optimization: use DOMINATOR_SPILL_MOVE_ID to mark moves. ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/alloc/LinearScan.java ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/alloc/RegisterVerifier.java Changeset: d91fecb90fc0 Author: Tom Rodriguez Date: 2014-07-01 12:36 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/d91fecb90fc0 Check -Xbatch still works in the gate ! mx/mx_graal.py Changeset: 67500ef4d102 Author: Tom Rodriguez Date: 2014-07-01 12:37 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/67500ef4d102 Check for negative array size in Array.newInstance ! graal/com.oracle.graal.replacements/src/com/oracle/graal/replacements/ArraySubstitutions.java Changeset: 657ff04a7b73 Author: Tom Rodriguez Date: 2014-07-01 12:37 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/657ff04a7b73 look for original method and substitution when processing snippet graph ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotResolvedJavaField.java ! graal/com.oracle.graal.replacements.test/src/com/oracle/graal/replacements/test/ObjectAccessTest.java ! graal/com.oracle.graal.replacements.test/src/com/oracle/graal/replacements/test/PointerTest.java + graal/com.oracle.graal.replacements.test/src/com/oracle/graal/replacements/test/ReplacementsParseTest.java ! graal/com.oracle.graal.replacements.test/src/com/oracle/graal/replacements/test/WordTest.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 Changeset: 5d7b90ab9787 Author: Tom Rodriguez Date: 2014-07-01 19:35 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/5d7b90ab9787 Ensure that uniqueConcreteMethod is called with a resolved concrete method ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotResolvedObjectType.java Changeset: e0f77d30ad07 Author: Tom Rodriguez Date: 2014-07-01 19:36 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/e0f77d30ad07 ensure the declared method holder is at least linked before emitting an invoke ! graal/com.oracle.graal.java/src/com/oracle/graal/java/GraphBuilderPhase.java Changeset: 9ce3b1efc4e7 Author: Tom Rodriguez Date: 2014-07-01 19:37 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/9ce3b1efc4e7 InstanceKlass::_init_state only exists for InstanceKlasses ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/HotSpotVMConfig.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotResolvedObjectType.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/HotSpotNodeSubstitutions.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/HotSpotReplacementsUtil.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/NewObjectSnippets.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/stubs/NewInstanceStub.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/java/DynamicNewInstanceNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/java/NewInstanceNode.java Changeset: 2bd6dbbd7842 Author: Tom Rodriguez Date: 2014-07-01 19:39 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/2bd6dbbd7842 treat empty LineNumberTable as non-existent ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotResolvedJavaMethod.java Changeset: 31e242cad4d1 Author: Tom Rodriguez Date: 2014-07-02 13:05 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/31e242cad4d1 Allow mx unittest to run single test method from a class ! graal/com.oracle.graal.test/src/com/oracle/graal/test/GraalJUnitCore.java ! mx/mx_graal.py Changeset: c68c5fafef92 Author: Tom Rodriguez Date: 2014-07-02 13:40 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/c68c5fafef92 Merge Changeset: ae8f4016792a Author: Doug Simon Date: 2014-07-02 23:40 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/ae8f4016792a HSAIL: added support for several missing java.lang.Math routines Contributed-by: Tom Deneau Contributed-by: Gustav Trede ! graal/com.oracle.graal.asm.hsail/src/com/oracle/graal/asm/hsail/HSAILAssembler.java + graal/com.oracle.graal.compiler.hsail.test/src/com/oracle/graal/compiler/hsail/test/lambda/DoubleAcosTest.java + graal/com.oracle.graal.compiler.hsail.test/src/com/oracle/graal/compiler/hsail/test/lambda/DoubleAsinTest.java + graal/com.oracle.graal.compiler.hsail.test/src/com/oracle/graal/compiler/hsail/test/lambda/DoubleAtan2Test.java + graal/com.oracle.graal.compiler.hsail.test/src/com/oracle/graal/compiler/hsail/test/lambda/DoubleAtanTest.java + graal/com.oracle.graal.compiler.hsail.test/src/com/oracle/graal/compiler/hsail/test/lambda/DoubleCbrtTest.java + graal/com.oracle.graal.compiler.hsail.test/src/com/oracle/graal/compiler/hsail/test/lambda/DoubleCosTest.java + graal/com.oracle.graal.compiler.hsail.test/src/com/oracle/graal/compiler/hsail/test/lambda/DoubleCoshTest.java + graal/com.oracle.graal.compiler.hsail.test/src/com/oracle/graal/compiler/hsail/test/lambda/DoubleExpTest.java + graal/com.oracle.graal.compiler.hsail.test/src/com/oracle/graal/compiler/hsail/test/lambda/DoubleExpm1Test.java + graal/com.oracle.graal.compiler.hsail.test/src/com/oracle/graal/compiler/hsail/test/lambda/DoubleGetExponentTest.java + graal/com.oracle.graal.compiler.hsail.test/src/com/oracle/graal/compiler/hsail/test/lambda/DoubleHypotTest.java + graal/com.oracle.graal.compiler.hsail.test/src/com/oracle/graal/compiler/hsail/test/lambda/DoubleIeeeRemainderTest.java + graal/com.oracle.graal.compiler.hsail.test/src/com/oracle/graal/compiler/hsail/test/lambda/DoubleLog10Test.java + graal/com.oracle.graal.compiler.hsail.test/src/com/oracle/graal/compiler/hsail/test/lambda/DoubleLogTest.java + graal/com.oracle.graal.compiler.hsail.test/src/com/oracle/graal/compiler/hsail/test/lambda/DoubleMathBase.java + graal/com.oracle.graal.compiler.hsail.test/src/com/oracle/graal/compiler/hsail/test/lambda/DoubleMathLargeBase.java + graal/com.oracle.graal.compiler.hsail.test/src/com/oracle/graal/compiler/hsail/test/lambda/DoubleNextAfterTest.java + graal/com.oracle.graal.compiler.hsail.test/src/com/oracle/graal/compiler/hsail/test/lambda/DoubleNextUpTest.java + graal/com.oracle.graal.compiler.hsail.test/src/com/oracle/graal/compiler/hsail/test/lambda/DoublePowTest.java + graal/com.oracle.graal.compiler.hsail.test/src/com/oracle/graal/compiler/hsail/test/lambda/DoubleRoundTest.java + graal/com.oracle.graal.compiler.hsail.test/src/com/oracle/graal/compiler/hsail/test/lambda/DoubleScalbTest.java + graal/com.oracle.graal.compiler.hsail.test/src/com/oracle/graal/compiler/hsail/test/lambda/DoubleSignumTest.java + graal/com.oracle.graal.compiler.hsail.test/src/com/oracle/graal/compiler/hsail/test/lambda/DoubleSinTest.java + graal/com.oracle.graal.compiler.hsail.test/src/com/oracle/graal/compiler/hsail/test/lambda/DoubleSinhTest.java + graal/com.oracle.graal.compiler.hsail.test/src/com/oracle/graal/compiler/hsail/test/lambda/DoubleTanTest.java + graal/com.oracle.graal.compiler.hsail.test/src/com/oracle/graal/compiler/hsail/test/lambda/DoubleTanhTest.java + graal/com.oracle.graal.compiler.hsail.test/src/com/oracle/graal/compiler/hsail/test/lambda/DoubleToLongTest.java + graal/com.oracle.graal.compiler.hsail.test/src/com/oracle/graal/compiler/hsail/test/lambda/DoubleTwoInputMathBase.java + graal/com.oracle.graal.compiler.hsail.test/src/com/oracle/graal/compiler/hsail/test/lambda/DoubleUlpTest.java + graal/com.oracle.graal.compiler.hsail.test/src/com/oracle/graal/compiler/hsail/test/lambda/DremTest.java + graal/com.oracle.graal.compiler.hsail.test/src/com/oracle/graal/compiler/hsail/test/lambda/FloatAcosTest.java + graal/com.oracle.graal.compiler.hsail.test/src/com/oracle/graal/compiler/hsail/test/lambda/FloatAsinTest.java + graal/com.oracle.graal.compiler.hsail.test/src/com/oracle/graal/compiler/hsail/test/lambda/FloatAtan2Test.java + graal/com.oracle.graal.compiler.hsail.test/src/com/oracle/graal/compiler/hsail/test/lambda/FloatAtanTest.java + graal/com.oracle.graal.compiler.hsail.test/src/com/oracle/graal/compiler/hsail/test/lambda/FloatCbrtTest.java + graal/com.oracle.graal.compiler.hsail.test/src/com/oracle/graal/compiler/hsail/test/lambda/FloatCosTest.java + graal/com.oracle.graal.compiler.hsail.test/src/com/oracle/graal/compiler/hsail/test/lambda/FloatCoshTest.java + graal/com.oracle.graal.compiler.hsail.test/src/com/oracle/graal/compiler/hsail/test/lambda/FloatExpTest.java + graal/com.oracle.graal.compiler.hsail.test/src/com/oracle/graal/compiler/hsail/test/lambda/FloatExpm1Test.java + graal/com.oracle.graal.compiler.hsail.test/src/com/oracle/graal/compiler/hsail/test/lambda/FloatGetExponentTest.java + graal/com.oracle.graal.compiler.hsail.test/src/com/oracle/graal/compiler/hsail/test/lambda/FloatIeeeRemainderTest.java + graal/com.oracle.graal.compiler.hsail.test/src/com/oracle/graal/compiler/hsail/test/lambda/FloatLog10Test.java + graal/com.oracle.graal.compiler.hsail.test/src/com/oracle/graal/compiler/hsail/test/lambda/FloatLogTest.java + graal/com.oracle.graal.compiler.hsail.test/src/com/oracle/graal/compiler/hsail/test/lambda/FloatMathBase.java + graal/com.oracle.graal.compiler.hsail.test/src/com/oracle/graal/compiler/hsail/test/lambda/FloatMathLargeBase.java + graal/com.oracle.graal.compiler.hsail.test/src/com/oracle/graal/compiler/hsail/test/lambda/FloatNextAfterTest.java + graal/com.oracle.graal.compiler.hsail.test/src/com/oracle/graal/compiler/hsail/test/lambda/FloatNextUpTest.java + graal/com.oracle.graal.compiler.hsail.test/src/com/oracle/graal/compiler/hsail/test/lambda/FloatPowTest.java + graal/com.oracle.graal.compiler.hsail.test/src/com/oracle/graal/compiler/hsail/test/lambda/FloatRoundTest.java + graal/com.oracle.graal.compiler.hsail.test/src/com/oracle/graal/compiler/hsail/test/lambda/FloatScalbTest.java + graal/com.oracle.graal.compiler.hsail.test/src/com/oracle/graal/compiler/hsail/test/lambda/FloatSignumTest.java + graal/com.oracle.graal.compiler.hsail.test/src/com/oracle/graal/compiler/hsail/test/lambda/FloatSinTest.java + graal/com.oracle.graal.compiler.hsail.test/src/com/oracle/graal/compiler/hsail/test/lambda/FloatSinhTest.java + graal/com.oracle.graal.compiler.hsail.test/src/com/oracle/graal/compiler/hsail/test/lambda/FloatTanTest.java + graal/com.oracle.graal.compiler.hsail.test/src/com/oracle/graal/compiler/hsail/test/lambda/FloatTanhTest.java + graal/com.oracle.graal.compiler.hsail.test/src/com/oracle/graal/compiler/hsail/test/lambda/FloatTwoInputMathBase.java + graal/com.oracle.graal.compiler.hsail.test/src/com/oracle/graal/compiler/hsail/test/lambda/FloatUlpTest.java + graal/com.oracle.graal.compiler.hsail.test/src/com/oracle/graal/compiler/hsail/test/lambda/MathTestBase.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 ! graal/com.oracle.graal.replacements.hsail/src/com/oracle/graal/replacements/hsail/HSAILMathSubstitutions.java + graal/com.oracle.graal.replacements.hsail/src/com/oracle/graal/replacements/hsail/JStrictMath.java ! graal/com.oracle.graal.test/src/com/oracle/graal/test/GraalTest.java Changeset: 50d79ad439f1 Author: Michael Van De Vanter Date: 2014-07-02 16:06 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/50d79ad439f1 Truffle/Instrumentation: rename PhylumTag to SyntaxTag (along with related classes/methods) ! graal/com.oracle.truffle.api/src/com/oracle/truffle/api/ExecutionContext.java ! graal/com.oracle.truffle.api/src/com/oracle/truffle/api/instrument/ASTNodeProber.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/ProbeListener.java + graal/com.oracle.truffle.api/src/com/oracle/truffle/api/instrument/StandardSyntaxTag.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/SyntaxTag.java + graal/com.oracle.truffle.api/src/com/oracle/truffle/api/instrument/SyntaxTagTrap.java + graal/com.oracle.truffle.api/src/com/oracle/truffle/api/instrument/SyntaxTagged.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/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 From duboscq at ssw.jku.at Thu Jul 3 09:08:29 2014 From: duboscq at ssw.jku.at (Gilles Duboscq) Date: Thu, 3 Jul 2014 11:08:29 +0200 Subject: the src (hotspot) tree in graal In-Reply-To: References: Message-ID: Our current upstream repo is hsx/hsx25. The revision we're based on is 5f07ec8bb982 which is indeed hs25-b63. This revision also exists in jdk8/jdk8/hotspot. Up until last December we just merged the upstream repository regularly without any special difficulty. At times we also try to minimize the diff to make this task easier. We are not merging any more for now. Be careful when looking at the history through mercurial: there are two merges that were done later (with jdk9) that were "reverted". Since you can't really revert a merge as far as mercurial is concerned, it may get a little confused. -Gilles On Wed, Jul 2, 2014 at 11:21 PM, Tom Deneau wrote: > I noticed when I run hg tags on graal, the most recent hs tag in there is hs25-b63 > > So if I wanted to find all the hotspot tree diffs introduced in graal , would it be correct to diff vs. jdk8/jdk8/hotspot, tag hs25-63? > > How does the graal team manage the src (hotspot) tree when there is a new hotspot build? > Is there a mercurial repository somewhere which contains the graal hotspot on a branch from the regular hotspot to help with merges? > > -- Tom > > From tom.deneau at amd.com Thu Jul 3 12:00:11 2014 From: tom.deneau at amd.com (Deneau, Tom) Date: Thu, 3 Jul 2014 12:00:11 +0000 Subject: the src (hotspot) tree in graal In-Reply-To: References: Message-ID: Gilles -- When you say "we are not merging any more for now", does that mean graal will be staying at hs25-b63 for a while? -- Tom -----Original Message----- From: gilwooden at gmail.com [mailto:gilwooden at gmail.com] On Behalf Of Gilles Duboscq Sent: Thursday, July 03, 2014 4:08 AM To: Deneau, Tom Cc: graal-dev at openjdk.java.net Subject: Re: the src (hotspot) tree in graal Our current upstream repo is hsx/hsx25. The revision we're based on is 5f07ec8bb982 which is indeed hs25-b63. This revision also exists in jdk8/jdk8/hotspot. Up until last December we just merged the upstream repository regularly without any special difficulty. At times we also try to minimize the diff to make this task easier. We are not merging any more for now. Be careful when looking at the history through mercurial: there are two merges that were done later (with jdk9) that were "reverted". Since you can't really revert a merge as far as mercurial is concerned, it may get a little confused. -Gilles On Wed, Jul 2, 2014 at 11:21 PM, Tom Deneau wrote: > I noticed when I run hg tags on graal, the most recent hs tag in there > is hs25-b63 > > So if I wanted to find all the hotspot tree diffs introduced in graal , would it be correct to diff vs. jdk8/jdk8/hotspot, tag hs25-63? > > How does the graal team manage the src (hotspot) tree when there is a new hotspot build? > Is there a mercurial repository somewhere which contains the graal hotspot on a branch from the regular hotspot to help with merges? > > -- Tom > > From doug.simon at oracle.com Thu Jul 3 22:06:50 2014 From: doug.simon at oracle.com (doug.simon at oracle.com) Date: Thu, 03 Jul 2014 22:06:50 +0000 Subject: hg: graal/graal: 6 new changesets Message-ID: <201407032206.s63M6otD024601@aojmv0008> Changeset: 5af4dd229520 Author: Doug Simon Date: 2014-07-03 14:21 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/5af4dd229520 HSAIL: removed debug output ! graal/com.oracle.graal.compiler.hsail.test/src/com/oracle/graal/compiler/hsail/test/lambda/DoubleIeeeRemainderTest.java Changeset: 380290b81eb0 Author: Doug Simon Date: 2014-07-03 14:29 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/380290b81eb0 mx: converted class path variables to camel case for better readability ! mx/mx_graal.py Changeset: 0dd27c6472d7 Author: Doug Simon Date: 2014-07-03 14:31 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/0dd27c6472d7 mx: remove entries from unittest class path that are in graal.jar when running with a Graal enabled VM ! mx/mx_graal.py Changeset: ad431bf0de07 Author: Doug Simon Date: 2014-07-03 16:30 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/ad431bf0de07 added support to load classes from graal.jar with a separate class loader ! .hgignore ! graal/com.oracle.graal.hotspot.amd64/src/com/oracle/graal/hotspot/amd64/AMD64HotSpotBackend.java + graal/com.oracle.graal.hotspot.loader/src/com/oracle/graal/hotspot/loader/Factory.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/HotSpotReplacementsUtil.java ! mx/mx_graal.py ! mx/projects ! src/share/vm/classfile/systemDictionary.cpp ! src/share/vm/classfile/systemDictionary.hpp ! src/share/vm/classfile/verifier.cpp ! src/share/vm/classfile/vmSymbols.hpp ! src/share/vm/graal/graalGlobals.hpp ! src/share/vm/graal/graalRuntime.cpp ! src/share/vm/graal/graalRuntime.hpp ! src/share/vm/oops/instanceKlass.cpp ! src/share/vm/prims/nativeLookup.cpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/javaCalls.cpp ! src/share/vm/runtime/os.cpp ! src/share/vm/runtime/os.hpp ! src/share/vm/runtime/thread.cpp Changeset: 5c0f2b338874 Author: Doug Simon Date: 2014-07-03 18:57 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/5c0f2b338874 made -esa apply to Graal classes even if they are not loaded by the boot class loader ! src/share/vm/prims/jvm.cpp Changeset: 9ca36e4e3137 Author: Doug Simon Date: 2014-07-03 19:07 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/9ca36e4e3137 removed use of SecurityManager and hiding fields from reflection (made redundant by -XX:+UseGraalClassLoader option) ! graal/com.oracle.graal.api.runtime/src/com/oracle/graal/api/runtime/Graal.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/HotSpotGraalRuntime.java From doug.simon at oracle.com Fri Jul 4 01:00:05 2014 From: doug.simon at oracle.com (doug.simon at oracle.com) Date: Fri, 04 Jul 2014 01:00:05 +0000 Subject: hg: graal/graal: 2 new changesets Message-ID: <201407040100.s64105QC021583@aojmv0008> Changeset: c5ab3fbec257 Author: Doug Simon Date: 2014-07-03 21:47 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/c5ab3fbec257 made Graal symbol declarations conditional upon GRAAL macro ! src/share/vm/classfile/vmSymbols.hpp Changeset: 4481cf549cfc Author: Doug Simon Date: 2014-07-03 23:28 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/4481cf549cfc removed (Java based) CompilationQueue ! CHANGELOG.md ! graal/com.oracle.graal.compiler.common/src/com/oracle/graal/compiler/common/GraalOptions.java - graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/CompilationQueue.java ! 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/HotSpotGraalRuntime.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/HotSpotOptions.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/HotSpotVMConfig.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/InitTimer.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotResolvedJavaMethod.java ! src/share/vm/classfile/vmSymbols.hpp ! src/share/vm/compiler/compileBroker.cpp ! src/share/vm/graal/graalCompiler.cpp ! src/share/vm/graal/graalCompiler.hpp ! src/share/vm/graal/graalGlobals.hpp ! src/share/vm/graal/graalRuntime.cpp ! src/share/vm/prims/jni.cpp ! src/share/vm/prims/nativeLookup.cpp ! src/share/vm/runtime/java.cpp ! src/share/vm/runtime/thread.cpp ! src/share/vm/runtime/thread.hpp From java at stefan-marr.de Fri Jul 4 07:16:35 2014 From: java at stefan-marr.de (Stefan Marr) Date: Fri, 4 Jul 2014 09:16:35 +0200 Subject: Truffle compilation problem In-Reply-To: References: Message-ID: Hi: I got a somewhat similar issue to what Michael reported, but when looking at the debugger I see an array out of bounds exception in the SignatureParser, which seems to lead to the stack trace below. I haven?t updated Graal in a while. Will try that next, but in case anyone else encountered this issue and has an idea what it could be, please let me know. Thanks a lot Stefan [truffle] opt fail Primitive PerformEnforcedWithArgumentsInSuperclassPrimObjectObjectArrayNode at 1d21f9e7|Reason Found illegal recursive call to HotSpotMethod, must annotate such calls with @CompilerDirectives.SlowPath! com.oracle.graal.nodes.util.GraphUtil$2: Found illegal recursive call to HotSpotMethod, must annotate such calls with @CompilerDirectives.SlowPath! at sun.reflect.generics.parser.SignatureParser.parseFieldTypeSignature(SignatureParser.java) at sun.reflect.generics.parser.SignatureParser.parseTypeSignature(SignatureParser.java:485) Caused by: java.lang.IllegalStateException: Found illegal recursive call to HotSpotMethod, must annotate such calls with @CompilerDirectives.SlowPath! at com.oracle.graal.truffle.TruffleCacheImpl.expandInvoke(TruffleCacheImpl.java:246) at com.oracle.graal.truffle.TruffleCacheImpl.lookup(TruffleCacheImpl.java:203) at com.oracle.graal.truffle.TruffleCacheImpl.expandInvoke(TruffleCacheImpl.java:242) at com.oracle.graal.truffle.TruffleCacheImpl.lookup(TruffleCacheImpl.java:203) at com.oracle.graal.truffle.TruffleCacheImpl.expandInvoke(TruffleCacheImpl.java:242) at com.oracle.graal.truffle.TruffleCacheImpl.lookup(TruffleCacheImpl.java:203) at com.oracle.graal.truffle.TruffleCacheImpl.expandInvoke(TruffleCacheImpl.java:242) at com.oracle.graal.truffle.TruffleCacheImpl.lookup(TruffleCacheImpl.java:203) at com.oracle.graal.truffle.TruffleCacheImpl.expandInvoke(TruffleCacheImpl.java:242) at com.oracle.graal.truffle.TruffleCacheImpl.lookup(TruffleCacheImpl.java:203) at com.oracle.graal.truffle.TruffleCacheImpl.expandInvoke(TruffleCacheImpl.java:242) at com.oracle.graal.truffle.TruffleCacheImpl.lookup(TruffleCacheImpl.java:203) at com.oracle.graal.truffle.TruffleCacheImpl.expandInvoke(TruffleCacheImpl.java:242) at com.oracle.graal.truffle.TruffleCacheImpl.lookup(TruffleCacheImpl.java:203) at com.oracle.graal.truffle.TruffleCacheImpl.expandInvoke(TruffleCacheImpl.java:242) at com.oracle.graal.truffle.TruffleCacheImpl.lookup(TruffleCacheImpl.java:203) at com.oracle.graal.truffle.TruffleCacheImpl.expandInvoke(TruffleCacheImpl.java:242) at com.oracle.graal.truffle.TruffleCacheImpl.lookup(TruffleCacheImpl.java:203) at com.oracle.graal.truffle.TruffleCacheImpl.expandInvoke(TruffleCacheImpl.java:242) at com.oracle.graal.truffle.TruffleCacheImpl.lookup(TruffleCacheImpl.java:203) at com.oracle.graal.truffle.TruffleCacheImpl.expandInvoke(TruffleCacheImpl.java:242) at com.oracle.graal.truffle.TruffleCacheImpl.lookup(TruffleCacheImpl.java:203) at com.oracle.graal.truffle.TruffleCacheImpl.expandInvoke(TruffleCacheImpl.java:242) at com.oracle.graal.truffle.TruffleCacheImpl.lookup(TruffleCacheImpl.java:203) at com.oracle.graal.truffle.TruffleCacheImpl.expandInvoke(TruffleCacheImpl.java:242) at com.oracle.graal.truffle.TruffleCacheImpl.lookup(TruffleCacheImpl.java:203) at com.oracle.graal.truffle.TruffleCacheImpl.expandInvoke(TruffleCacheImpl.java:242) at com.oracle.graal.truffle.TruffleCacheImpl.lookup(TruffleCacheImpl.java:203) at com.oracle.graal.truffle.TruffleCacheImpl.expandInvoke(TruffleCacheImpl.java:242) at com.oracle.graal.truffle.TruffleCacheImpl.lookup(TruffleCacheImpl.java:203) at com.oracle.graal.truffle.TruffleCacheImpl.expandInvoke(TruffleCacheImpl.java:242) at com.oracle.graal.truffle.TruffleCacheImpl.lookup(TruffleCacheImpl.java:203) at com.oracle.graal.truffle.TruffleCacheImpl.expandInvoke(TruffleCacheImpl.java:242) at com.oracle.graal.truffle.TruffleCacheImpl.lookup(TruffleCacheImpl.java:203) at com.oracle.graal.truffle.TruffleCacheImpl.expandInvoke(TruffleCacheImpl.java:242) at com.oracle.graal.truffle.TruffleCacheImpl.lookup(TruffleCacheImpl.java:203) at com.oracle.graal.truffle.TruffleCacheImpl.expandInvoke(TruffleCacheImpl.java:242) at com.oracle.graal.truffle.TruffleCacheImpl.lookup(TruffleCacheImpl.java:203) at com.oracle.graal.truffle.TruffleCacheImpl.expandInvoke(TruffleCacheImpl.java:242) at com.oracle.graal.truffle.TruffleCacheImpl.lookup(TruffleCacheImpl.java:203) at com.oracle.graal.truffle.TruffleCacheImpl.expandInvoke(TruffleCacheImpl.java:242) at com.oracle.graal.truffle.TruffleCacheImpl.lookup(TruffleCacheImpl.java:203) at com.oracle.graal.truffle.TruffleCacheImpl.expandInvoke(TruffleCacheImpl.java:242) at com.oracle.graal.truffle.TruffleCacheImpl.lookup(TruffleCacheImpl.java:203) at com.oracle.graal.truffle.TruffleCacheImpl.expandInvoke(TruffleCacheImpl.java:242) at com.oracle.graal.truffle.TruffleCacheImpl.lookup(TruffleCacheImpl.java:203) at com.oracle.graal.truffle.TruffleCacheImpl.expandInvoke(TruffleCacheImpl.java:242) at com.oracle.graal.truffle.TruffleCacheImpl.lookup(TruffleCacheImpl.java:203) at com.oracle.graal.truffle.PartialEvaluator.parseGraph(PartialEvaluator.java:248) at com.oracle.graal.truffle.PartialEvaluator.expandTree(PartialEvaluator.java:206) at com.oracle.graal.truffle.PartialEvaluator.createGraph(PartialEvaluator.java:116) at com.oracle.graal.truffle.TruffleCompilerImpl.compileMethodImpl(TruffleCompilerImpl.java:120) at com.oracle.graal.truffle.hotspot.HotSpotTruffleRuntime$3.run(HotSpotTruffleRuntime.java:299) at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) at java.util.concurrent.FutureTask.run(FutureTask.java:266) 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:744) at com.oracle.graal.compiler.CompilerThread.run(CompilerThread.java:48) -- Stefan Marr INRIA Lille - Nord Europe http://stefan-marr.de/research/ From java at stefan-marr.de Fri Jul 4 09:03:09 2014 From: java at stefan-marr.de (Stefan Marr) Date: Fri, 4 Jul 2014 11:03:09 +0200 Subject: Truffle compilation problem In-Reply-To: References: Message-ID: Hi: Turned out to be another case of HashMap.put() on a fast path. Best regards Stefan On 04 Jul 2014, at 09:16, Stefan Marr wrote: > Hi: > > I got a somewhat similar issue to what Michael reported, but when looking at the debugger I see an array out of bounds exception in the SignatureParser, which seems to lead to the stack trace below. > > I haven?t updated Graal in a while. Will try that next, but in case anyone else encountered this issue and has an idea what it could be, please let me know. > > Thanks a lot > Stefan > > [truffle] opt fail Primitive PerformEnforcedWithArgumentsInSuperclassPrimObjectObjectArrayNode at 1d21f9e7|Reason Found illegal recursive call to HotSpotMethod, must annotate such calls with @CompilerDirectives.SlowPath! > com.oracle.graal.nodes.util.GraphUtil$2: Found illegal recursive call to HotSpotMethod, must annotate such calls with @CompilerDirectives.SlowPath! > at sun.reflect.generics.parser.SignatureParser.parseFieldTypeSignature(SignatureParser.java) > at sun.reflect.generics.parser.SignatureParser.parseTypeSignature(SignatureParser.java:485) > Caused by: java.lang.IllegalStateException: Found illegal recursive call to HotSpotMethod, must annotate such calls with @CompilerDirectives.SlowPath! > at com.oracle.graal.truffle.TruffleCacheImpl.expandInvoke(TruffleCacheImpl.java:246) > at com.oracle.graal.truffle.TruffleCacheImpl.lookup(TruffleCacheImpl.java:203) > at com.oracle.graal.truffle.TruffleCacheImpl.expandInvoke(TruffleCacheImpl.java:242) > at com.oracle.graal.truffle.TruffleCacheImpl.lookup(TruffleCacheImpl.java:203) > at com.oracle.graal.truffle.TruffleCacheImpl.expandInvoke(TruffleCacheImpl.java:242) > at com.oracle.graal.truffle.TruffleCacheImpl.lookup(TruffleCacheImpl.java:203) > at com.oracle.graal.truffle.TruffleCacheImpl.expandInvoke(TruffleCacheImpl.java:242) > at com.oracle.graal.truffle.TruffleCacheImpl.lookup(TruffleCacheImpl.java:203) > at com.oracle.graal.truffle.TruffleCacheImpl.expandInvoke(TruffleCacheImpl.java:242) > at com.oracle.graal.truffle.TruffleCacheImpl.lookup(TruffleCacheImpl.java:203) > at com.oracle.graal.truffle.TruffleCacheImpl.expandInvoke(TruffleCacheImpl.java:242) > at com.oracle.graal.truffle.TruffleCacheImpl.lookup(TruffleCacheImpl.java:203) > at com.oracle.graal.truffle.TruffleCacheImpl.expandInvoke(TruffleCacheImpl.java:242) > at com.oracle.graal.truffle.TruffleCacheImpl.lookup(TruffleCacheImpl.java:203) > at com.oracle.graal.truffle.TruffleCacheImpl.expandInvoke(TruffleCacheImpl.java:242) > at com.oracle.graal.truffle.TruffleCacheImpl.lookup(TruffleCacheImpl.java:203) > at com.oracle.graal.truffle.TruffleCacheImpl.expandInvoke(TruffleCacheImpl.java:242) > at com.oracle.graal.truffle.TruffleCacheImpl.lookup(TruffleCacheImpl.java:203) > at com.oracle.graal.truffle.TruffleCacheImpl.expandInvoke(TruffleCacheImpl.java:242) > at com.oracle.graal.truffle.TruffleCacheImpl.lookup(TruffleCacheImpl.java:203) > at com.oracle.graal.truffle.TruffleCacheImpl.expandInvoke(TruffleCacheImpl.java:242) > at com.oracle.graal.truffle.TruffleCacheImpl.lookup(TruffleCacheImpl.java:203) > at com.oracle.graal.truffle.TruffleCacheImpl.expandInvoke(TruffleCacheImpl.java:242) > at com.oracle.graal.truffle.TruffleCacheImpl.lookup(TruffleCacheImpl.java:203) > at com.oracle.graal.truffle.TruffleCacheImpl.expandInvoke(TruffleCacheImpl.java:242) > at com.oracle.graal.truffle.TruffleCacheImpl.lookup(TruffleCacheImpl.java:203) > at com.oracle.graal.truffle.TruffleCacheImpl.expandInvoke(TruffleCacheImpl.java:242) > at com.oracle.graal.truffle.TruffleCacheImpl.lookup(TruffleCacheImpl.java:203) > at com.oracle.graal.truffle.TruffleCacheImpl.expandInvoke(TruffleCacheImpl.java:242) > at com.oracle.graal.truffle.TruffleCacheImpl.lookup(TruffleCacheImpl.java:203) > at com.oracle.graal.truffle.TruffleCacheImpl.expandInvoke(TruffleCacheImpl.java:242) > at com.oracle.graal.truffle.TruffleCacheImpl.lookup(TruffleCacheImpl.java:203) > at com.oracle.graal.truffle.TruffleCacheImpl.expandInvoke(TruffleCacheImpl.java:242) > at com.oracle.graal.truffle.TruffleCacheImpl.lookup(TruffleCacheImpl.java:203) > at com.oracle.graal.truffle.TruffleCacheImpl.expandInvoke(TruffleCacheImpl.java:242) > at com.oracle.graal.truffle.TruffleCacheImpl.lookup(TruffleCacheImpl.java:203) > at com.oracle.graal.truffle.TruffleCacheImpl.expandInvoke(TruffleCacheImpl.java:242) > at com.oracle.graal.truffle.TruffleCacheImpl.lookup(TruffleCacheImpl.java:203) > at com.oracle.graal.truffle.TruffleCacheImpl.expandInvoke(TruffleCacheImpl.java:242) > at com.oracle.graal.truffle.TruffleCacheImpl.lookup(TruffleCacheImpl.java:203) > at com.oracle.graal.truffle.TruffleCacheImpl.expandInvoke(TruffleCacheImpl.java:242) > at com.oracle.graal.truffle.TruffleCacheImpl.lookup(TruffleCacheImpl.java:203) > at com.oracle.graal.truffle.TruffleCacheImpl.expandInvoke(TruffleCacheImpl.java:242) > at com.oracle.graal.truffle.TruffleCacheImpl.lookup(TruffleCacheImpl.java:203) > at com.oracle.graal.truffle.TruffleCacheImpl.expandInvoke(TruffleCacheImpl.java:242) > at com.oracle.graal.truffle.TruffleCacheImpl.lookup(TruffleCacheImpl.java:203) > at com.oracle.graal.truffle.TruffleCacheImpl.expandInvoke(TruffleCacheImpl.java:242) > at com.oracle.graal.truffle.TruffleCacheImpl.lookup(TruffleCacheImpl.java:203) > at com.oracle.graal.truffle.PartialEvaluator.parseGraph(PartialEvaluator.java:248) > at com.oracle.graal.truffle.PartialEvaluator.expandTree(PartialEvaluator.java:206) > at com.oracle.graal.truffle.PartialEvaluator.createGraph(PartialEvaluator.java:116) > at com.oracle.graal.truffle.TruffleCompilerImpl.compileMethodImpl(TruffleCompilerImpl.java:120) > at com.oracle.graal.truffle.hotspot.HotSpotTruffleRuntime$3.run(HotSpotTruffleRuntime.java:299) > at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) > at java.util.concurrent.FutureTask.run(FutureTask.java:266) > 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:744) > at com.oracle.graal.compiler.CompilerThread.run(CompilerThread.java:48) > > -- > 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 Fri Jul 4 11:20:26 2014 From: java at stefan-marr.de (Stefan Marr) Date: Fri, 4 Jul 2014 13:20:26 +0200 Subject: Truffle Feature Request: Print argument to neverPartOfCompilation Message-ID: Hi: Would it be possible to include something along the lines of the patch below? That would be very helpful to debug compilation. diff --git a/graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/nodes/asserts/NeverPartOfCompilationNode.java b/graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/nodes/asserts/NeverPartOfCompilationNode.java index 3e2fc61..9286007 100644 --- a/graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/nodes/asserts/NeverPartOfCompilationNode.java +++ b/graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/nodes/asserts/NeverPartOfCompilationNode.java @@ -40,6 +40,6 @@ public class NeverPartOfCompilationNode extends MacroNode implements IterableNod } public final String getMessage() { - return message; + return message + " " + arguments.toString(); } } Thanks Stefan -- Stefan Marr INRIA Lille - Nord Europe http://stefan-marr.de/research/ From java at stefan-marr.de Fri Jul 4 20:37:55 2014 From: java at stefan-marr.de (Stefan Marr) Date: Fri, 4 Jul 2014 22:37:55 +0200 Subject: NeverPartOfCompilation node slipping through the cracks Message-ID: Hi: I encountered an issue where a NeverPartOfCompilation node actually made it to a lowering phase (see output below). I would guess there are constellations were inlining or so can lead to NeverPartOfCompilation becoming part of the graph after the check that verifies there are none. In my case, I first saw hard crashes, and after investigating with assertions enabled, I was seeing ?AssertionError: cannot lower to invoke without state?. Best regards Stefan [thread:1] scope: [thread:1] scope: Truffle [thread:1] scope: Truffle.TruffleGraal.GraalCompiler [thread:1] scope: Truffle.TruffleGraal.GraalCompiler.GraalCompiler [thread:1] scope: Truffle.TruffleGraal.GraalCompiler.GraalCompiler.FrontEnd [thread:1] scope: Truffle.TruffleGraal.GraalCompiler.GraalCompiler.FrontEnd.HighTier [thread:1] scope: Truffle.TruffleGraal.GraalCompiler.GraalCompiler.FrontEnd.HighTier.LoweringPhase [thread:1] scope: Truffle.TruffleGraal.GraalCompiler.GraalCompiler.FrontEnd.HighTier.LoweringPhase.IncrementalCanonicalizerPhase [thread:1] scope: Truffle.TruffleGraal.GraalCompiler.GraalCompiler.FrontEnd.HighTier.LoweringPhase.IncrementalCanonicalizerPhase.LoweringPhase_Round [thread:1] scope: Truffle.TruffleGraal.GraalCompiler.GraalCompiler.FrontEnd.HighTier.LoweringPhase.IncrementalCanonicalizerPhase.LoweringPhase_Round.InterceptException Exception occurred in scope: Truffle.TruffleGraal.GraalCompiler.GraalCompiler.FrontEnd.HighTier.LoweringPhase.IncrementalCanonicalizerPhase.LoweringPhase_Round.InterceptException Context obj java.lang.AssertionError: cannot lower to invoke without state: -1000013198|NeverPartOfCompilation Context obj com.oracle.graal.phases.common.LoweringPhase$Round at 7598d675 Context obj com.oracle.graal.phases.common.IncrementalCanonicalizerPhase at 4946485c Context obj com.oracle.graal.phases.common.LoweringPhase at 4ae958b0 Context obj com.oracle.graal.compiler.phases.HighTier at 7c682e26 Context obj StructuredGraph:23{Primitive PerformEnforcedWithArgumentsInSuperclassPrimObjectObjectArrayNode at 4f18837a, HotSpotMethod} Use -G:+DumpOnError to enable dumping of graphs on this error Context obj com.oracle.graal.hotspot.amd64.AMD64HotSpotCodeCacheProvider at 4ff074a0 Context obj StructuredGraph:23{Primitive PerformEnforcedWithArgumentsInSuperclassPrimObjectObjectArrayNode at 4f18837a, HotSpotMethod} Use -G:+DumpOnError to enable dumping of graphs on this error Context obj com.oracle.graal.hotspot.amd64.AMD64HotSpotCodeCacheProvider at 4ff074a0 Context obj Truffle [truffle] opt fail Primitive PerformEnforcedWithArgumentsInSuperclassPrimObjectObjectArrayNode at 4f18837a|Reason cannot lower to invoke without state: -1000013198|NeverPartOfCompilation java.lang.AssertionError: cannot lower to invoke without state: -1000013198|NeverPartOfCompilation -- Stefan Marr INRIA Lille - Nord Europe http://stefan-marr.de/research/ From doug.simon at oracle.com Sat Jul 5 01:00:06 2014 From: doug.simon at oracle.com (doug.simon at oracle.com) Date: Sat, 05 Jul 2014 01:00:06 +0000 Subject: hg: graal/graal: 15 new changesets Message-ID: <201407050100.s65107FO023762@aojmv0008> Changeset: fca7699bacd8 Author: Gilles Duboscq Date: 2014-07-02 16:54 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/fca7699bacd8 RemoveValueProxyPhase should remove dead framestates recursively ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/RemoveValueProxyPhase.java Changeset: 347915b8cea8 Author: Gilles Duboscq Date: 2014-07-02 18:23 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/347915b8cea8 Move name from HotSpotNmethod to InstalledCode to have a name again for truffle nmethods. ! graal/com.oracle.graal.api.code/src/com/oracle/graal/api/code/InstalledCode.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotInstalledCode.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotNmethod.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotRuntimeStub.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/stubs/Stub.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/OptimizedCallTarget.java ! src/share/vm/graal/graalJavaAccess.hpp ! src/share/vm/runtime/deoptimization.cpp Changeset: 639716622dc8 Author: Gilles Duboscq Date: 2014-07-03 18:27 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/639716622dc8 GuardLoweringPhase should not leave dead nodes behind ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/GuardLoweringPhase.java Changeset: 39f9f052e5a8 Author: Gilles Duboscq Date: 2014-07-04 13:40 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/39f9f052e5a8 Move DefaultCanonicalizerTool to GraphUtil and make it a DefaultSimplifierTool - graal/com.oracle.graal.graph/src/com/oracle/graal/graph/spi/DefaultCanonicalizerTool.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/util/GraphUtil.java Changeset: fe985eebfcd9 Author: Gilles Duboscq Date: 2014-07-04 13:47 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/fe985eebfcd9 ConvertDeoptimizeToGuardPhase: remove useless BeginNodes ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/ConvertDeoptimizeToGuardPhase.java Changeset: 9bfc4247262f Author: Lukas Stadler Date: 2014-07-04 16:06 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/9bfc4247262f send log output to native tty ! graal/com.oracle.graal.debug/src/com/oracle/graal/debug/Debug.java ! graal/com.oracle.graal.debug/src/com/oracle/graal/debug/internal/DebugScope.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/PrintStreamOption.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 ! src/share/vm/graal/graalCompilerToVM.cpp Changeset: ed91068c8af5 Author: Lukas Stadler Date: 2014-07-04 16:06 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/ed91068c8af5 cleanup in AssertionNode ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotHostForeignCallsProvider.java ! graal/com.oracle.graal.replacements/src/com/oracle/graal/replacements/nodes/AssertionNode.java Changeset: 9575add7149c Author: Christian Humer Date: 2014-07-04 18:56 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/9575add7149c Truffle: new option TraceTruffleCompilationCallTree which prints the inlined call tree just before compilation. ! CHANGELOG.md ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/OptimizedCallTargetLog.java ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/OptimizedCallUtils.java ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/TruffleCompilerImpl.java ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/TruffleCompilerOptions.java Changeset: 3f9ec3220077 Author: Christian Humer Date: 2014-07-04 18:56 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/3f9ec3220077 Truffle: added API for typed objects. ! CHANGELOG.md + graal/com.oracle.truffle.api/src/com/oracle/truffle/api/TypedObject.java Changeset: 51b74b041bb7 Author: Christian Humer Date: 2014-07-04 18:56 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/51b74b041bb7 Truffle: added Truffle stamps for argument profiling. + graal/com.oracle.graal.truffle.test/src/com/oracle/graal/truffle/test/TruffleStampTest.java + graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/DefaultTruffleStamp.java + graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/TruffleStamp.java Changeset: 7f862f0ab1bc Author: Christian Humer Date: 2014-07-04 18:56 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/7f862f0ab1bc Truffle: added new experimental splitting heuristic. ! CHANGELOG.md + graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/DefaultTruffleSplittingStrategy.java + graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/DefaultTruffleSplittingStrategyNew.java ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/OptimizedCallTarget.java ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/OptimizedCallTargetLog.java ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/OptimizedDirectCallNode.java ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/TruffleCompilerOptions.java + graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/TruffleSplittingStrategy.java Changeset: e863be932518 Author: Christian Humer Date: 2014-07-04 19:48 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/e863be932518 Fixed line delimiters. ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/DefaultTruffleSplittingStrategy.java ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/DefaultTruffleSplittingStrategyNew.java ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/DefaultTruffleStamp.java ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/TruffleSplittingStrategy.java ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/TruffleStamp.java ! graal/com.oracle.truffle.api/src/com/oracle/truffle/api/TypedObject.java Changeset: 150b12ff9b36 Author: Christian Humer Date: 2014-07-04 21:02 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/150b12ff9b36 Fixed line delimiters. ! graal/com.oracle.graal.truffle.test/src/com/oracle/graal/truffle/test/TruffleStampTest.java Changeset: 3e7d0f67363c Author: Christian Humer Date: 2014-07-04 21:19 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/3e7d0f67363c Fixed headers. ! graal/com.oracle.graal.truffle.test/src/com/oracle/graal/truffle/test/TruffleStampTest.java ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/DefaultTruffleSplittingStrategy.java ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/DefaultTruffleSplittingStrategyNew.java ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/DefaultTruffleStamp.java ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/TruffleSplittingStrategy.java ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/TruffleStamp.java ! graal/com.oracle.truffle.api/src/com/oracle/truffle/api/TypedObject.java Changeset: 3d424f8a2bea Author: Christian Humer Date: 2014-07-04 21:29 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/3d424f8a2bea Fixed headers. ! graal/com.oracle.truffle.api/src/com/oracle/truffle/api/TypedObject.java From java at stefan-marr.de Sat Jul 5 16:34:09 2014 From: java at stefan-marr.de (Stefan Marr) Date: Sat, 5 Jul 2014 18:34:09 +0200 Subject: [Truffle] IndirectCallNode vs. another inline cache? Message-ID: Hi: I was wondering how exactly IndirectCallNode is optimized and what the characteristics are compared to using another inline cache. Are the performance characteristics supposed to be similar? Also, how are the interactions with tree inlining and splitting, etc? The JavaDoc isn?t very explicit on that point. And I didn?t really see how OptimizedIndirectCallNode is used in the code. Thanks Stefan -- Stefan Marr INRIA Lille - Nord Europe http://stefan-marr.de/research/ From christian.humer at gmail.com Mon Jul 7 12:22:58 2014 From: christian.humer at gmail.com (Christian Humer) Date: Mon, 7 Jul 2014 14:22:58 +0200 Subject: Fwd: call vs execute In-Reply-To: References: Message-ID: Hallo Stefan, > And the interpretation would be that Truffle inlines 18 nonterminal > calls into one compilation unit/method/$something? > This does not happen for the noncaching variant, because that uses an > IndirectCallNode, correct? > Yes exactly. The logic when and how to cache calls to CallTargets is guest language specific. Use DirectCallNode for cached calls and IndirectCallNode for not-cached calls. This is quite amazing. I didn't expect it to be so close to the > perfect Java code that does the same thing. Have fun experimenting! - Christian Humer > > > > > > - Christian Humer > > > > > > On Tue, Jun 24, 2014 at 10:20 AM, Stefan Fehrenbach > > wrote: > >> > >> Hello, > >> > >> I implemented a recursive descend grammar interpreter using Truffle. > >> Nonterminal calls are replaced by either of three alternative > >> implementations: > >> 1. Unoptimized lookup of the nonterminal in a hash table > >> 2. Look up nonterminal during replacement, cache result and call the > >> cached node's execute method directly. > >> 3. Look up nonterminal during replacement, cache result and use > >> Truffle's function call support to call the execute method. > >> > >> Now it happens that the function call variant is a lot slower than the > >> other two and even the cached variant is still slower than the naive > >> implementation: > >> > >> Unoptimized: 3095 > >> Cached execute: 3555 > >> Cached call: 18521 > >> (Time to parse a long string with a grammar consisting of a long chain > >> of nonterminal calls a couple of times.) > >> > >> My question is: why is the function call variant so much slower? The > >> actual computation is so simple, I expected Truffle/Graal to just > >> inline the functions. > >> And why is the cached variant still slower than the naive > >> implementation. In every parse, we need 150*150 hash table look ups in > >> the naive implementation vs only 150*150 Assumption checks in variant > >> #2. > >> > >> Code is here: https://github.com/fehrenbach/parsers > >> Uninitialized node: > >> > >> > https://github.com/fehrenbach/parsers/blob/master/src/org/morphling/parsers/truffle/UninitializedNonterminalCall.java > >> > >> I use the graalvm-jdk1.8.0-0.3 release and the following JVM > >> parameters to call this main method: > >> org.morphling.parsers.truffle.Tests#main > >> > >> -server > >> -Xss32m > >> -Dtruffle.TraceRewrites=true > >> -Dtruffle.DetailedRewriteReasons=true > >> -G:+TraceTruffleCompilationDetails > >> -G:+TraceTruffleCompilation > >> -G:TruffleCompilationThreshold=1 > >> -XX:+UnlockDiagnosticVMOptions > >> -XX:-PrintCompilation > >> > >> Am I just using Truffle the wrong way? What could be the reason for > >> the slow function calls and the underperforming cache, even in this > >> contrived grammar with long nonterminal chains? > >> > >> Best regards, > >> Stefan > > > > > From christian.humer at gmail.com Mon Jul 7 12:51:11 2014 From: christian.humer at gmail.com (Christian Humer) Date: Mon, 7 Jul 2014 14:51:11 +0200 Subject: [Truffle] IndirectCallNode vs. another inline cache? In-Reply-To: References: Message-ID: Hi Stefan, I was wondering how exactly IndirectCallNode is optimized and what the > characteristics are compared to using another inline cache. > Are the performance characteristics supposed to be similar? No. IndirectCallNode does not implement an inline cache. The inline cache for calls is guest language specific at the moment. You can see how such a cache is implemented in the SLInvokeNode in the simple language. For DirectCallNodes inlining and splitting may be performed. For IndirectCallNodes inlining and splitting is not performed. The only reason why there is an IndirectCallNode at the moment is to support guest language stack traces. However we plan to add an implementation of a call inline cache to the Truffle API. Also, how are the interactions with tree inlining and splitting, etc? There are quite a few interactions between them. *) The inlining heuristic cost function is based on the frequency and node count of a call. The frequency is more accurate if a split was performed. Also the node count may change depending on the call-site. (if branches not taken) *) The heuristic is also based on the number of callers of a call. If a CallTarget gets split it is going to get its own counter. (which affects the inlining decision) *) The inlining decision is decided per DirectCallNode. This means if a CallTarget gets split per call-site the split CallTarget gets its own maybe different inlining decision. *) If for some reason (like a phase change) the splitting is performed after the inlining decision was performed. Then the inlining decision gets invalidated. Please report to me if you see suspicious behavior. The JavaDoc isn?t very explicit on that point. And I didn?t really see how > OptimizedIndirectCallNode is used in the code. As I already mentioned it is only used to provide guest language stack traces. For an example how to use the indirect call node see SLGenericDispatchNode. Hope this helps. - Christian Humer On Sat, Jul 5, 2014 at 6:34 PM, Stefan Marr wrote: > Hi: > > I was wondering how exactly IndirectCallNode is optimized and what the > characteristics are compared to using another inline cache. > > Are the performance characteristics supposed to be similar? > Also, how are the interactions with tree inlining and splitting, etc? > > The JavaDoc isn?t very explicit on that point. And I didn?t really see how > OptimizedIndirectCallNode is used in the code. > > Thanks > Stefan > > -- > Stefan Marr > INRIA Lille - Nord Europe > http://stefan-marr.de/research/ > > > > From java at stefan-marr.de Mon Jul 7 14:29:53 2014 From: java at stefan-marr.de (Stefan Marr) Date: Mon, 7 Jul 2014 16:29:53 +0200 Subject: [Truffle] IndirectCallNode vs. another inline cache? In-Reply-To: References: Message-ID: <958C2553-5E52-4A6D-B782-3A4ACBC0E16A@stefan-marr.de> Hi Christian: On 07 Jul 2014, at 14:51, Christian Humer wrote: >> I was wondering how exactly IndirectCallNode is optimized and what the characteristics are compared to using another inline cache. >> Are the performance characteristics supposed to be similar? >> > No. IndirectCallNode does not implement an inline cache. The inline cache for calls is guest language specific at the moment. > For DirectCallNodes inlining and splitting may be performed. > For IndirectCallNodes inlining and splitting is not performed. Ok, that?s what I wanted to know. And I already switched to another custom inline cache. > However we plan to add an implementation of a call inline cache to the Truffle API. What exactly do you plan? Do you plan support for inline caches in the TruffleDSL? Looking at the different caches I got, they look extremely similar. I actually tried to keep them as similar as possible, because I think that much of the boilerplate could be generate. It is always the same structure. Only the cache key, the test, the initialization/specialization logic, and the passed parameters, and the implementation for the general case differ. Around that, I got a very repetitive structure. > Also, how are the interactions with tree inlining and splitting, etc? > >> There are quite a few interactions between them. Sorry for the unclear question, it was in the context of IndirectCallNodes, but that seems to be answered, thanks. Best regards Stefan -- Stefan Marr INRIA Lille - Nord Europe http://stefan-marr.de/research/ From christian.humer at gmail.com Mon Jul 7 17:05:58 2014 From: christian.humer at gmail.com (Christian Humer) Date: Mon, 7 Jul 2014 19:05:58 +0200 Subject: [Truffle] IndirectCallNode vs. another inline cache? In-Reply-To: <958C2553-5E52-4A6D-B782-3A4ACBC0E16A@stefan-marr.de> References: <958C2553-5E52-4A6D-B782-3A4ACBC0E16A@stefan-marr.de> Message-ID: Hi, On Mon, Jul 7, 2014 at 4:29 PM, Stefan Marr wrote: > What exactly do you plan? Do you plan support for inline caches in the > TruffleDSL? > Looking at the different caches I got, they look extremely similar. I > actually tried to keep them as similar as possible, because I think that > much of the boilerplate could be generate. It is always the same structure. > Only the cache key, the test, the initialization/specialization logic, and > the passed parameters, and the implementation for the general case differ. > Around that, I got a very repetitive structure. > Yes. I do want to support inline caches using the DSL. I've already done some prototyping, but it turned out that a few other issues with the DSL have to be resolved first. I am going to fix them and the next thing on my TODO list is going to be inline caches (a more abstract DSL feature name would be: specialization specific state). But maybe we are also going to push a reusable call inline cache implementation just based on the Truffle API. Not sure yet. - Christian Humer From doug.simon at oracle.com Tue Jul 8 01:00:07 2014 From: doug.simon at oracle.com (doug.simon at oracle.com) Date: Tue, 08 Jul 2014 01:00:07 +0000 Subject: hg: graal/graal: 5 new changesets Message-ID: <201407080100.s68107kJ013672@aojmv0008> Changeset: 24af0805e135 Author: Lukas Stadler Date: 2014-07-07 12:15 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/24af0805e135 hasValueProxies on StructuredGraph ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/StructuredGraph.java ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/RemoveValueProxyPhase.java ! graal/com.oracle.graal.phases/src/com/oracle/graal/phases/util/GraphOrder.java Changeset: 4fe215bc2da5 Author: Lukas Stadler Date: 2014-07-07 12:16 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/4fe215bc2da5 return null if phase is not found in PhaseSuite.findPhase ! graal/com.oracle.graal.phases/src/com/oracle/graal/phases/PhaseSuite.java Changeset: 9fe3cb463079 Author: Doug Simon Date: 2014-07-07 14:51 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/9fe3cb463079 mx: classpath function now accepts distributions as well (which are prepend to the class path) ! mx/mx_graal.py ! mxtool/mx.py Changeset: 434888b63a15 Author: Tom Rodriguez Date: 2014-07-07 11:53 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/434888b63a15 adjust comment ! graal/com.oracle.graal.replacements/src/com/oracle/graal/replacements/ReplacementsImpl.java Changeset: 7520833c6e7f Author: Tom Rodriguez Date: 2014-07-07 11:54 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/7520833c6e7f eliminate JUnitWrapper ! graal/com.oracle.graal.test/src/com/oracle/graal/test/GraalJUnitCore.java - mx/JUnitWrapper.java ! mx/mx_graal.py From java at stefan-marr.de Tue Jul 8 14:06:47 2014 From: java at stefan-marr.de (Stefan Marr) Date: Tue, 8 Jul 2014 16:06:47 +0200 Subject: How to change Truffle Inlining Policies to accommodate a Metaobject Protocol Message-ID: <8D6238E0-B71C-43E0-BA25-44E65B9D27BE@stefan-marr.de> Hi: Over the past weeks, I extended TruffleSOM with the implementation of a metaobject protocol. [This concrete one is an ownership-based one, so it is not using metaclasses but metaobjects that relate to base objects.] Encouraged by the great result I got with RTruffleSOM and meta tracing, I was expecting similarly good results on top of Truffle and Graal. However, so far no luck. Most likely candidate is the inlining on the tree level. When looking in IGV at the tree, I see OptimizedDirectCall nodes as leafs. And, I see some of the meta operations being not split as they would need to be. In order to address these things, I was experimenting with forcing inlining and splitting of operations related to the metaobject protocol. One of the concrete stumbling blocks is that the tree explodes. Actually much more than what I would naively expect. Consequently, the recursive tree depth counting leads to stack overflows (-Xss100m as parameter to mx did not help). Another issue, which I thought I can work around is the logic for recognizing recursion, which does not work in the presence of meta methods. Just imagine a meta handler that is called for every method invocation, it is recognized as recursive while it isn?t really recursive. So, I checked whether it is a meta method in the DefaultInliningPolicy. Similarly, I check in OptimizedDirectCallNode.shouldSplit() whether it is a method that should always be inlined and indicate it to be split. Unfortunately, this does not yield the desired results. Now I was wondering whether you already got experience in that direction. My naive expectation would be that inlining all operations related to the metaobject protocol should be feasible and allow the partial evaluator to reduce _all_ of it to a guard and lower the operations performed on the meta level to normal direct operations. Any hints how to get there would be highly appreciate. By the way, a month ago I was already stumbling over an issue, I wasn?t able to sort out yet, where the combination of two meta-programming features did not yield the expected performance [1]. Thanks Stefan [1] http://markmail.org/thread/63myxnjfncqe6kri -- Stefan Marr INRIA Lille - Nord Europe http://stefan-marr.de/research/ From doug.simon at oracle.com Wed Jul 9 01:00:05 2014 From: doug.simon at oracle.com (doug.simon at oracle.com) Date: Wed, 09 Jul 2014 01:00:05 +0000 Subject: hg: graal/graal: 9 new changesets Message-ID: <201407090100.s69105Fl020542@aojmv0008> Changeset: e4ac25d4e13d Author: Tom Rodriguez Date: 2014-07-07 17:43 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/e4ac25d4e13d use findUniqueConcreteSubtype in InstanceOfNode ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/java/InstanceOfNode.java Changeset: c158f653275e Author: Tom Rodriguez Date: 2014-07-07 20:26 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/c158f653275e don't forget to record assumptions ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/java/InstanceOfNode.java Changeset: 7f20dee1be60 Author: Tom Rodriguez Date: 2014-07-07 20:27 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/7f20dee1be60 ensure instanceof and null check stay dependent ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/java/CheckCastNode.java Changeset: a9b85fe36dbc Author: Roland Schatz Date: 2014-07-08 14:25 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/a9b85fe36dbc Don't rewrite to trapping null checks if the FrameState has an input that's anchored to the deopting branch. ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/UseTrappingNullChecksPhase.java Changeset: 1bed6de938cd Author: Danilo Ansaloni Date: 2014-07-08 15:59 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/1bed6de938cd Truffle: if value is null use instance stamps, not class or type stamps. ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/DefaultTruffleStamp.java Changeset: 8eec87d7bfc4 Author: Doug Simon Date: 2014-07-08 21:23 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/8eec87d7bfc4 made Factory.newClassLoader() private ! graal/com.oracle.graal.hotspot.loader/src/com/oracle/graal/hotspot/loader/Factory.java Changeset: 775660e1acbc Author: Doug Simon Date: 2014-07-08 21:29 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/775660e1acbc changed return type of Local.getType() to JavaType ! graal/com.oracle.graal.api.meta/src/com/oracle/graal/api/meta/Local.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/debug/LocalImpl.java Changeset: 84a14e69fa8b Author: Doug Simon Date: 2014-07-08 21:35 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/84a14e69fa8b added missing check for pending exception ! src/share/vm/runtime/thread.cpp Changeset: 78ddecd6255f Author: Doug Simon Date: 2014-07-08 21:38 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/78ddecd6255f added CHECK macros in uses of SymbolTable::new_symbol; added CHECK_ABORT macros for TRAPS functions that must abort the VM if they throw an exception ! graal/com.oracle.graal.hotspot.sourcegen/src/com/oracle/graal/hotspot/sourcegen/GenGraalRuntimeInlineHpp.java ! src/share/vm/graal/graalCompiler.cpp ! src/share/vm/graal/graalRuntime.cpp ! src/share/vm/graal/graalRuntime.hpp From bernhard.urban at jku.at Wed Jul 9 08:41:11 2014 From: bernhard.urban at jku.at (Bernhard Urban) Date: Wed, 9 Jul 2014 10:41:11 +0200 Subject: NeverPartOfCompilation node slipping through the cracks In-Reply-To: References: Message-ID: Hi Stefan, I believe the following happened: You have annotated some method with @SlowPath, which then was not inlined by the partial evaluator, but is still using some compiler directives that would be turned into a NeverPartOfCompilationNode. The verification that such nodes do not exist is done after partial evaluation. After that, the graph is passed to the normal Graal compiler. Its inliner can then still decide to inline your method annotated with @SlowPath. If this happens, it's quite unlikely that such NeverPartOfCompilationNodes will constant fold away. Do you think this could have happen in your Truffle interpreter? Anyway, I'll push a change that will turn this into a more friendly failure. Thanks for the report, Bernhard On Fri, Jul 4, 2014 at 10:37 PM, Stefan Marr wrote: > Hi: > > I encountered an issue where a NeverPartOfCompilation node actually made > it to a lowering phase (see output below). > > I would guess there are constellations were inlining or so can lead to > NeverPartOfCompilation becoming part of the graph after the check that > verifies there are none. > In my case, I first saw hard crashes, and after investigating with > assertions enabled, I was seeing ?AssertionError: cannot lower to invoke > without state?. > > Best regards > Stefan > > [thread:1] scope: > [thread:1] scope: Truffle > [thread:1] scope: Truffle.TruffleGraal.GraalCompiler > [thread:1] scope: Truffle.TruffleGraal.GraalCompiler.GraalCompiler > [thread:1] scope: > Truffle.TruffleGraal.GraalCompiler.GraalCompiler.FrontEnd > [thread:1] scope: > Truffle.TruffleGraal.GraalCompiler.GraalCompiler.FrontEnd.HighTier > [thread:1] scope: > Truffle.TruffleGraal.GraalCompiler.GraalCompiler.FrontEnd.HighTier.LoweringPhase > [thread:1] scope: > Truffle.TruffleGraal.GraalCompiler.GraalCompiler.FrontEnd.HighTier.LoweringPhase.IncrementalCanonicalizerPhase > [thread:1] scope: > Truffle.TruffleGraal.GraalCompiler.GraalCompiler.FrontEnd.HighTier.LoweringPhase.IncrementalCanonicalizerPhase.LoweringPhase_Round > [thread:1] scope: > Truffle.TruffleGraal.GraalCompiler.GraalCompiler.FrontEnd.HighTier.LoweringPhase.IncrementalCanonicalizerPhase.LoweringPhase_Round.InterceptException > Exception occurred in scope: > Truffle.TruffleGraal.GraalCompiler.GraalCompiler.FrontEnd.HighTier.LoweringPhase.IncrementalCanonicalizerPhase.LoweringPhase_Round.InterceptException > Context obj java.lang.AssertionError: cannot lower to > invoke without state: -1000013198|NeverPartOfCompilation > Context obj > com.oracle.graal.phases.common.LoweringPhase$Round at 7598d675 > Context obj > com.oracle.graal.phases.common.IncrementalCanonicalizerPhase at 4946485c > Context obj > com.oracle.graal.phases.common.LoweringPhase at 4ae958b0 > Context obj > com.oracle.graal.compiler.phases.HighTier at 7c682e26 > Context obj StructuredGraph:23{Primitive > PerformEnforcedWithArgumentsInSuperclassPrimObjectObjectArrayNode at 4f18837a, > HotSpotMethod} > Use -G:+DumpOnError to enable dumping of graphs on this > error > Context obj > com.oracle.graal.hotspot.amd64.AMD64HotSpotCodeCacheProvider at 4ff074a0 > Context obj StructuredGraph:23{Primitive > PerformEnforcedWithArgumentsInSuperclassPrimObjectObjectArrayNode at 4f18837a, > HotSpotMethod} > Use -G:+DumpOnError to enable dumping of graphs on this > error > Context obj > com.oracle.graal.hotspot.amd64.AMD64HotSpotCodeCacheProvider at 4ff074a0 > Context obj > Truffle ()> > [truffle] opt fail Primitive > PerformEnforcedWithArgumentsInSuperclassPrimObjectObjectArrayNode at 4f18837a|Reason > cannot lower to invoke without state: -1000013198|NeverPartOfCompilation > java.lang.AssertionError: cannot lower to invoke without state: > -1000013198|NeverPartOfCompilation > > -- > Stefan Marr > INRIA Lille - Nord Europe > http://stefan-marr.de/research/ > > > > From miguelalfredo.garcia at epfl.ch Wed Jul 9 08:43:36 2014 From: miguelalfredo.garcia at epfl.ch (Garcia Gutierrez Miguel Alfredo) Date: Wed, 9 Jul 2014 08:43:36 +0000 Subject: slides about the inliner, control-flow sensitive rewritings Message-ID: <7E4228B446372948BBB2916FC53FA49E3EC9B44B@REXMD.intranet.epfl.ch> Hi, I've made a bunch of improvements to the inliner (in the form of behavior-preserving refactorings plus documentation) which might pave the way towards more substantial improvements (eg, closure-aware inlining, one of the original goals). The following slides go into details about those improvements, and include pointers to what remains to be done: http://ssw.jku.at/General/Staff/Garcia/2014-07-07-Garcia.pdf As a bonus, the slides cover a new experimental phase I've added to Graal, to perform control-flow-sensitive rewritings (early in the compilation pipeline). That phase is self-contained and thus within reach of newcomers, for example as next stop after GraphBuilder. cheers, Miguel -- Miguel Garcia https://www.linkedin.com/pub/miguel-garcia/19/35/351 From bernhard.urban at jku.at Wed Jul 9 08:44:26 2014 From: bernhard.urban at jku.at (Bernhard Urban) Date: Wed, 9 Jul 2014 10:44:26 +0200 Subject: Truffle Feature Request: Print argument to neverPartOfCompilation In-Reply-To: References: Message-ID: Hi Stefan, I'll push it. Thanks for the suggestion! -Bernhard On Fri, Jul 4, 2014 at 1:20 PM, Stefan Marr wrote: > Hi: > > Would it be possible to include something along the lines of the patch > below? > That would be very helpful to debug compilation. > > diff --git > a/graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/nodes/asserts/NeverPartOfCompilationNode.java > b/graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/nodes/asserts/NeverPartOfCompilationNode.java > index 3e2fc61..9286007 100644 > --- > a/graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/nodes/asserts/NeverPartOfCompilationNode.java > +++ > b/graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/nodes/asserts/NeverPartOfCompilationNode.java > @@ -40,6 +40,6 @@ public class NeverPartOfCompilationNode extends > MacroNode implements IterableNod > } > > public final String getMessage() { > - return message; > + return message + " " + arguments.toString(); > } > } > > > Thanks > Stefan > > -- > Stefan Marr > INRIA Lille - Nord Europe > http://stefan-marr.de/research/ > > > > From java at stefan-marr.de Wed Jul 9 08:47:50 2014 From: java at stefan-marr.de (Stefan Marr) Date: Wed, 9 Jul 2014 10:47:50 +0200 Subject: NeverPartOfCompilation node slipping through the cracks In-Reply-To: References: Message-ID: Hi Bernhard: On 09 Jul 2014, at 10:41, Bernhard Urban wrote: > I believe the following happened: You have annotated some method with @SlowPath, which then was not inlined by the partial evaluator, but is still using some compiler directives that would be turned into a NeverPartOfCompilationNode. The verification that such nodes do not exist is done after partial evaluation. After that, the graph is passed to the normal Graal compiler. Its inliner can then still decide to inline your method annotated with @SlowPath. If this happens, it's quite unlikely that such NeverPartOfCompilationNodes will constant fold away. > Do you think this could have happen in your Truffle interpreter? Yes, that?s definitely possible. > Anyway, I?ll push a change that will turn this into a more friendly failure. Indeed, a good error message would be much nicer than a segfault. Thanks Stefan -- Stefan Marr INRIA Lille - Nord Europe http://stefan-marr.de/research/ From tom.deneau at amd.com Wed Jul 9 22:43:42 2014 From: tom.deneau at amd.com (Deneau, Tom) Date: Wed, 9 Jul 2014 22:43:42 +0000 Subject: building a JDK that includes the hsail graal backend without building graal Message-ID: At the request of some of the Hotspot team, I am trying an experiment to do the following: As you are all probably aware, currently our build process to build a Sumatra JDK image is two steps: 1) Build the Sumatra-modified JDK a. there are a small number of classes (less than 10) from java.util.stream that get modified to enable the gpu offload. If offload is detected it then calls into graal. 2) With JAVA_HOME set to the Sumatra-modified JDK, build graal "server" compiler. This uses its own special "mx build" command. This produces a new JDK image with the following changes: 2.1) from the graal java sources, a graal.jar in the jre/lib directory 2.2) from the graal hotspot sources, a new hotspot libjvm.so in the jre/lib/amd64/server directory We wanted to add enough classes to sumatra-dev/jdk and sumatra-dev/hotspot so that we could skip step 2 above but still build a functional sumatra able to offload to hsail. So the equivalent of graal.jar would be built into rt.jar ideally includes only that part of graal java and graal hotspot that would be necessary for an HSAIL backend. A webrev from before vs. after then would let use see what the hsail/graal additional footprint would be. But for a first cut, we wouldn't spend too much time getting down to the minimum footprint. So far we have some success. I modified mx/projects so that what I thought were the unnecessary project sets would not be included in graal.jar (so truffle, sparc, ptx. Note that we do need the graal amd64 backend because of the way hsail deoptimization is done). I did our normal 2-part sumatra build and everything seemed to work, and if you look at graal.jar you can see it does not have the classes that were removed via mx projects. Then I took the graal java sources for the classes that were still in graal.jar and added them to the sumatra-dev/jdk. I also took the hotspot src tree from graal (which is a modification of hs25-b63) and used that instead of the vanilla hs25-b63 tag in sumatra-dev/hotspot. After a few hiccups like having to manually add the graal-generated files graalRuntime.inline.hpp and HotspotVMConfig.inline.hpp to the sumatra-dev/hotspot, things built. And I am able to run sumatra offloads to HSAIL as long as I turn off HSAILDeoptimization. But with HSAILDeoptimization on (the default), I see a NPE coming from com.oracle.graal.graph.GraalGraphInternalError: com.oracle.graal.compiler.common.GraalInternalError: java.lang.NullPointerException at lir instruction: B2 at 38 DEOPT_CALLER stack:16|j [B0, B2, B1] at lir instruction: B2 at 38 DEOPT_CALLER stack:16|j [B0, B2, B1] at node: 12|VMError at com.oracle.graal.graph.GraalGraphInternalError.transformAndAddContext(GraalGraphInternalError.java:136) at com.oracle.graal.compiler.gen.NodeLIRBuilder.doBlock(NodeLIRBuilder.java:220) at com.oracle.graal.compiler.GraalCompiler.emitBlock(GraalCompiler.java:216) at com.oracle.graal.compiler.GraalCompiler.emitLIR(GraalCompiler.java:250) at com.oracle.graal.compiler.GraalCompiler.emitBackEnd(GraalCompiler.java:198) at com.oracle.graal.compiler.GraalCompiler.compileGraph(GraalCompiler.java:141) at com.oracle.graal.hotspot.hsail.HSAILHotSpotBackend.installKernel(HSAILHotSpotBackend.java:286) at com.oracle.graal.hotspot.hsail.ForEachToGraal.getCompiledLambda(ForEachToGraal.java:143) at com.oracle.graal.hotspot.hsail.ForEachToGraal.createKernel(ForEachToGraal.java:149) at java.util.stream.PipelineInfo.offloadForEachPipeline(PipelineInfo.java:391) Caused by: java.lang.NullPointerException at com.oracle.graal.replacements.SnippetTemplate$SnippetInfo$Lazy.initNames(SnippetTemplate.java:118) at com.oracle.graal.replacements.SnippetTemplate$SnippetInfo$Lazy.(SnippetTemplate.java:102) at com.oracle.graal.replacements.SnippetTemplate$SnippetInfo.lazy(SnippetTemplate.java:146) at com.oracle.graal.replacements.SnippetTemplate$SnippetInfo.getParameterCount(SnippetTemplate.java:174) at com.oracle.graal.replacements.SnippetTemplate$CacheKey.(SnippetTemplate.java:384) at com.oracle.graal.replacements.SnippetTemplate$Arguments.(SnippetTemplate.java:221) at com.oracle.graal.hotspot.stubs.SnippetStub.makeArguments(SnippetStub.java:99) at com.oracle.graal.hotspot.stubs.SnippetStub.getGraph(SnippetStub.java:92) at com.oracle.graal.hotspot.stubs.Stub.getCode(Stub.java:148) so we are in the code that builds the trampoline host code (which explains why this only shows up in the hsail deoptimization codepath). When I step into SnippetInfo$Lazy.initNames, I can see that the NPE is coming because method.getLocalVariableTable() is returning null because in HotSpotResolvedMethod.getLocalVariableTable() we see that (getConstMethodFlags() & runtime().getConfig().constMethodHasLocalVariableTable) == 0); private boolean initNames(ResolvedJavaMethod method, int parameterCount) { names = new String[parameterCount]; int slotIdx = 0; for (int i = 0; i < names.length; i++) { names[i] = method.getLocalVariableTable().getLocal(slotIdx, 0).getName(); Kind kind = method.getSignature().getParameterKind(i); slotIdx += kind == Kind.Long || kind == Kind.Double ? 2 : 1; } return true; } any suggestions? I had assumed that the HotSpotVMConfig.inline.hpp that was produced in the graal build could just be used as is in sumatra-dev/hotspot but I don't really understand whether that is a valid assumption. -- Tom From tom.rodriguez at oracle.com Wed Jul 9 23:05:38 2014 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Wed, 9 Jul 2014 16:05:38 -0700 Subject: building a JDK that includes the hsail graal backend without building graal In-Reply-To: References: Message-ID: That code is assuming it?s always compiled -g or at least -g:vars, which is true when built with mx. Only initializing the name when it?s non-null should make it work, assuming no one else it relying on that being non-null. tom On Jul 9, 2014, at 3:43 PM, Deneau, Tom wrote: > At the request of some of the Hotspot team, I am trying an experiment to do the following: > > As you are all probably aware, currently our build process to build a Sumatra JDK image is two steps: > > > 1) Build the Sumatra-modified JDK > > a. there are a small number of classes (less than 10) from java.util.stream that get modified to enable the gpu offload. If offload is detected it then calls into graal. > > > > 2) With JAVA_HOME set to the Sumatra-modified JDK, build graal "server" compiler. > > This uses its own special "mx build" command. > > This produces a new JDK image with the following changes: > > 2.1) from the graal java sources, a graal.jar in the jre/lib directory > > 2.2) from the graal hotspot sources, a new hotspot libjvm.so in the jre/lib/amd64/server directory > > > > > We wanted to add enough classes to sumatra-dev/jdk and sumatra-dev/hotspot so that we could skip step 2 above but still build a functional sumatra able to offload to hsail. So the equivalent of graal.jar would be built into rt.jar ideally includes only that part of graal java and graal hotspot that would be necessary for an HSAIL backend. A webrev from before vs. after then would let use see what the hsail/graal additional footprint would be. But for a first cut, we wouldn't spend too much time getting down to the minimum footprint. > > So far we have some success. > > I modified mx/projects so that what I thought were the unnecessary project sets would not be included in graal.jar (so truffle, sparc, ptx. Note that we do need the graal amd64 backend because of the way hsail deoptimization is done). > > I did our normal 2-part sumatra build and everything seemed to work, and if you look at graal.jar you can see it does not have the classes that were removed via mx projects. > > Then I took the graal java sources for the classes that were still in graal.jar and added them to the sumatra-dev/jdk. I also took the hotspot src tree from graal (which is a modification of hs25-b63) and used that instead of the vanilla hs25-b63 tag in sumatra-dev/hotspot. > > After a few hiccups like having to manually add the graal-generated files graalRuntime.inline.hpp and HotspotVMConfig.inline.hpp to the sumatra-dev/hotspot, things built. > > And I am able to run sumatra offloads to HSAIL as long as I turn off HSAILDeoptimization. > > But with HSAILDeoptimization on (the default), I see a NPE coming from > > > com.oracle.graal.graph.GraalGraphInternalError: com.oracle.graal.compiler.common.GraalInternalError: java.lang.NullPointerException > > at lir instruction: B2 at 38 DEOPT_CALLER stack:16|j > > [B0, B2, B1] > > at lir instruction: B2 at 38 DEOPT_CALLER stack:16|j > > [B0, B2, B1] > > at node: 12|VMError > > at com.oracle.graal.graph.GraalGraphInternalError.transformAndAddContext(GraalGraphInternalError.java:136) > > at com.oracle.graal.compiler.gen.NodeLIRBuilder.doBlock(NodeLIRBuilder.java:220) > > at com.oracle.graal.compiler.GraalCompiler.emitBlock(GraalCompiler.java:216) > > at com.oracle.graal.compiler.GraalCompiler.emitLIR(GraalCompiler.java:250) > > at com.oracle.graal.compiler.GraalCompiler.emitBackEnd(GraalCompiler.java:198) > > at com.oracle.graal.compiler.GraalCompiler.compileGraph(GraalCompiler.java:141) > > at com.oracle.graal.hotspot.hsail.HSAILHotSpotBackend.installKernel(HSAILHotSpotBackend.java:286) > > at com.oracle.graal.hotspot.hsail.ForEachToGraal.getCompiledLambda(ForEachToGraal.java:143) > > at com.oracle.graal.hotspot.hsail.ForEachToGraal.createKernel(ForEachToGraal.java:149) > > at java.util.stream.PipelineInfo.offloadForEachPipeline(PipelineInfo.java:391) > > > > Caused by: java.lang.NullPointerException > > at com.oracle.graal.replacements.SnippetTemplate$SnippetInfo$Lazy.initNames(SnippetTemplate.java:118) > > at com.oracle.graal.replacements.SnippetTemplate$SnippetInfo$Lazy.(SnippetTemplate.java:102) > > at com.oracle.graal.replacements.SnippetTemplate$SnippetInfo.lazy(SnippetTemplate.java:146) > > at com.oracle.graal.replacements.SnippetTemplate$SnippetInfo.getParameterCount(SnippetTemplate.java:174) > > at com.oracle.graal.replacements.SnippetTemplate$CacheKey.(SnippetTemplate.java:384) > > at com.oracle.graal.replacements.SnippetTemplate$Arguments.(SnippetTemplate.java:221) > > at com.oracle.graal.hotspot.stubs.SnippetStub.makeArguments(SnippetStub.java:99) > > at com.oracle.graal.hotspot.stubs.SnippetStub.getGraph(SnippetStub.java:92) > > at com.oracle.graal.hotspot.stubs.Stub.getCode(Stub.java:148) > > > > so we are in the code that builds the trampoline host code (which explains why this only shows up in the hsail deoptimization codepath). > > > > When I step into SnippetInfo$Lazy.initNames, I can see that the NPE is coming because method.getLocalVariableTable() is returning null because in HotSpotResolvedMethod.getLocalVariableTable() we see that (getConstMethodFlags() & runtime().getConfig().constMethodHasLocalVariableTable) == 0); > > > > private boolean initNames(ResolvedJavaMethod method, int parameterCount) { > > names = new String[parameterCount]; > > int slotIdx = 0; > > for (int i = 0; i < names.length; i++) { > > names[i] = method.getLocalVariableTable().getLocal(slotIdx, 0).getName(); > > > > Kind kind = method.getSignature().getParameterKind(i); > > slotIdx += kind == Kind.Long || kind == Kind.Double ? 2 : 1; > > } > > return true; > > } > > any suggestions? > > I had assumed that the HotSpotVMConfig.inline.hpp that was produced in the graal build could just be used as is in sumatra-dev/hotspot but I don't really understand whether that is a valid assumption. > > -- Tom From christian.wimmer at oracle.com Wed Jul 9 23:14:52 2014 From: christian.wimmer at oracle.com (Christian Wimmer) Date: Wed, 09 Jul 2014 16:14:52 -0700 Subject: building a JDK that includes the hsail graal backend without building graal In-Reply-To: References: Message-ID: <53BDCCEC.90700@oracle.com> The variable names are just used for assertion checking, so no one must rely on that they are non-null. When you disable assertions in Graal, your NullPointerException should go away too because SnippetInfo$Lazy.initNames is only called from within an assert statement. -Christian On 07/09/2014 04:05 PM, Tom Rodriguez wrote: > That code is assuming it?s always compiled -g or at least -g:vars, which is true when built with mx. Only initializing the name when it?s non-null should make it work, assuming no one else it relying on that being non-null. > > tom > > On Jul 9, 2014, at 3:43 PM, Deneau, Tom wrote: > >> At the request of some of the Hotspot team, I am trying an experiment to do the following: >> >> As you are all probably aware, currently our build process to build a Sumatra JDK image is two steps: >> >> >> 1) Build the Sumatra-modified JDK >> >> a. there are a small number of classes (less than 10) from java.util.stream that get modified to enable the gpu offload. If offload is detected it then calls into graal. >> >> >> >> 2) With JAVA_HOME set to the Sumatra-modified JDK, build graal "server" compiler. >> >> This uses its own special "mx build" command. >> >> This produces a new JDK image with the following changes: >> >> 2.1) from the graal java sources, a graal.jar in the jre/lib directory >> >> 2.2) from the graal hotspot sources, a new hotspot libjvm.so in the jre/lib/amd64/server directory >> >> >> >> >> We wanted to add enough classes to sumatra-dev/jdk and sumatra-dev/hotspot so that we could skip step 2 above but still build a functional sumatra able to offload to hsail. So the equivalent of graal.jar would be built into rt.jar ideally includes only that part of graal java and graal hotspot that would be necessary for an HSAIL backend. A webrev from before vs. after then would let use see what the hsail/graal additional footprint would be. But for a first cut, we wouldn't spend too much time getting down to the minimum footprint. >> >> So far we have some success. >> >> I modified mx/projects so that what I thought were the unnecessary project sets would not be included in graal.jar (so truffle, sparc, ptx. Note that we do need the graal amd64 backend because of the way hsail deoptimization is done). >> >> I did our normal 2-part sumatra build and everything seemed to work, and if you look at graal.jar you can see it does not have the classes that were removed via mx projects. >> >> Then I took the graal java sources for the classes that were still in graal.jar and added them to the sumatra-dev/jdk. I also took the hotspot src tree from graal (which is a modification of hs25-b63) and used that instead of the vanilla hs25-b63 tag in sumatra-dev/hotspot. >> >> After a few hiccups like having to manually add the graal-generated files graalRuntime.inline.hpp and HotspotVMConfig.inline.hpp to the sumatra-dev/hotspot, things built. >> >> And I am able to run sumatra offloads to HSAIL as long as I turn off HSAILDeoptimization. >> >> But with HSAILDeoptimization on (the default), I see a NPE coming from >> >> >> com.oracle.graal.graph.GraalGraphInternalError: com.oracle.graal.compiler.common.GraalInternalError: java.lang.NullPointerException >> >> at lir instruction: B2 at 38 DEOPT_CALLER stack:16|j >> >> [B0, B2, B1] >> >> at lir instruction: B2 at 38 DEOPT_CALLER stack:16|j >> >> [B0, B2, B1] >> >> at node: 12|VMError >> >> at com.oracle.graal.graph.GraalGraphInternalError.transformAndAddContext(GraalGraphInternalError.java:136) >> >> at com.oracle.graal.compiler.gen.NodeLIRBuilder.doBlock(NodeLIRBuilder.java:220) >> >> at com.oracle.graal.compiler.GraalCompiler.emitBlock(GraalCompiler.java:216) >> >> at com.oracle.graal.compiler.GraalCompiler.emitLIR(GraalCompiler.java:250) >> >> at com.oracle.graal.compiler.GraalCompiler.emitBackEnd(GraalCompiler.java:198) >> >> at com.oracle.graal.compiler.GraalCompiler.compileGraph(GraalCompiler.java:141) >> >> at com.oracle.graal.hotspot.hsail.HSAILHotSpotBackend.installKernel(HSAILHotSpotBackend.java:286) >> >> at com.oracle.graal.hotspot.hsail.ForEachToGraal.getCompiledLambda(ForEachToGraal.java:143) >> >> at com.oracle.graal.hotspot.hsail.ForEachToGraal.createKernel(ForEachToGraal.java:149) >> >> at java.util.stream.PipelineInfo.offloadForEachPipeline(PipelineInfo.java:391) >> >> >> >> Caused by: java.lang.NullPointerException >> >> at com.oracle.graal.replacements.SnippetTemplate$SnippetInfo$Lazy.initNames(SnippetTemplate.java:118) >> >> at com.oracle.graal.replacements.SnippetTemplate$SnippetInfo$Lazy.(SnippetTemplate.java:102) >> >> at com.oracle.graal.replacements.SnippetTemplate$SnippetInfo.lazy(SnippetTemplate.java:146) >> >> at com.oracle.graal.replacements.SnippetTemplate$SnippetInfo.getParameterCount(SnippetTemplate.java:174) >> >> at com.oracle.graal.replacements.SnippetTemplate$CacheKey.(SnippetTemplate.java:384) >> >> at com.oracle.graal.replacements.SnippetTemplate$Arguments.(SnippetTemplate.java:221) >> >> at com.oracle.graal.hotspot.stubs.SnippetStub.makeArguments(SnippetStub.java:99) >> >> at com.oracle.graal.hotspot.stubs.SnippetStub.getGraph(SnippetStub.java:92) >> >> at com.oracle.graal.hotspot.stubs.Stub.getCode(Stub.java:148) >> >> >> >> so we are in the code that builds the trampoline host code (which explains why this only shows up in the hsail deoptimization codepath). >> >> >> >> When I step into SnippetInfo$Lazy.initNames, I can see that the NPE is coming because method.getLocalVariableTable() is returning null because in HotSpotResolvedMethod.getLocalVariableTable() we see that (getConstMethodFlags() & runtime().getConfig().constMethodHasLocalVariableTable) == 0); >> >> >> >> private boolean initNames(ResolvedJavaMethod method, int parameterCount) { >> >> names = new String[parameterCount]; >> >> int slotIdx = 0; >> >> for (int i = 0; i < names.length; i++) { >> >> names[i] = method.getLocalVariableTable().getLocal(slotIdx, 0).getName(); >> >> >> >> Kind kind = method.getSignature().getParameterKind(i); >> >> slotIdx += kind == Kind.Long || kind == Kind.Double ? 2 : 1; >> >> } >> >> return true; >> >> } >> >> any suggestions? >> >> I had assumed that the HotSpotVMConfig.inline.hpp that was produced in the graal build could just be used as is in sumatra-dev/hotspot but I don't really understand whether that is a valid assumption. >> >> -- Tom > From doug.simon at oracle.com Thu Jul 10 01:00:06 2014 From: doug.simon at oracle.com (doug.simon at oracle.com) Date: Thu, 10 Jul 2014 01:00:06 +0000 Subject: hg: graal/graal: 9 new changesets Message-ID: <201407100100.s6A106BV027994@aojmv0008> Changeset: 3943a1a46a53 Author: Stefan Anzinger Date: 2014-07-08 17:57 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/3943a1a46a53 [SPARC] Fixing i2d and l2f and handling of implicit exceptions ! graal/com.oracle.graal.compiler.sparc/src/com/oracle/graal/compiler/sparc/SPARCLIRGenerator.java ! graal/com.oracle.graal.hotspot.sparc/src/com/oracle/graal/hotspot/sparc/SPARCHotSpotRegisterConfig.java ! graal/com.oracle.graal.jtt/src/com/oracle/graal/jtt/bytecode/BC_l2f.java Changeset: dfd4530c3cd2 Author: Stefan Anzinger Date: 2014-07-08 18:15 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/dfd4530c3cd2 [SPARC] Fix Double register allocation ! graal/com.oracle.graal.hotspot.sparc/src/com/oracle/graal/hotspot/sparc/SPARCHotSpotRegisterConfig.java Changeset: 99fa6bd5d27b Author: Bernhard Urban Date: 2014-07-09 09:28 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/99fa6bd5d27b truffle compiler: rename ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/TruffleCacheImpl.java Changeset: 78cbe3d93bc1 Author: Bernhard Urban Date: 2014-07-09 09:31 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/78cbe3d93bc1 truffle compiler: be a bit more aggressive on cutting exceptions/errors ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/TruffleCacheImpl.java Changeset: 3691fe88967e Author: Bernhard Urban Date: 2014-07-09 09:36 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/3691fe88967e truffle compiler: make lowering of NeverPartOfCompilationNode fail ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/nodes/asserts/NeverPartOfCompilationNode.java Changeset: 2d01fb8f8acb Author: Bernhard Urban Date: 2014-07-09 10:42 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/2d01fb8f8acb truffle compiler: put arguments in message of NPCNode ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/nodes/asserts/NeverPartOfCompilationNode.java Changeset: b20d00b2ac2e Author: Doug Simon Date: 2014-07-09 19:02 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/b20d00b2ac2e fixed deadlock in GraalVM under -Xcomp (JBS:GRAAL-48) ! src/share/vm/runtime/thread.cpp Changeset: 801017cdfd6a Author: Doug Simon Date: 2014-07-09 19:03 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/801017cdfd6a fixed field name in LocalImpl.toString() ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/debug/LocalImpl.java Changeset: 680f52926754 Author: Doug Simon Date: 2014-07-09 20:24 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/680f52926754 added test for -Xcomp to the gate ! mx/mx_graal.py From tom.deneau at amd.com Thu Jul 10 14:28:59 2014 From: tom.deneau at amd.com (Deneau, Tom) Date: Thu, 10 Jul 2014 14:28:59 +0000 Subject: building a JDK that includes the hsail graal backend without building graal In-Reply-To: <53BDCCEC.90700@oracle.com> References: <53BDCCEC.90700@oracle.com> Message-ID: Yes, things worked when I disabled assertions. Thanks. -- Tom -----Original Message----- From: graal-dev [mailto:graal-dev-bounces at openjdk.java.net] On Behalf Of Christian Wimmer Sent: Wednesday, July 09, 2014 6:15 PM To: graal-dev at openjdk.java.net Subject: Re: building a JDK that includes the hsail graal backend without building graal The variable names are just used for assertion checking, so no one must rely on that they are non-null. When you disable assertions in Graal, your NullPointerException should go away too because SnippetInfo$Lazy.initNames is only called from within an assert statement. -Christian On 07/09/2014 04:05 PM, Tom Rodriguez wrote: > That code is assuming it's always compiled -g or at least -g:vars, which is true when built with mx. Only initializing the name when it's non-null should make it work, assuming no one else it relying on that being non-null. > > tom > > On Jul 9, 2014, at 3:43 PM, Deneau, Tom wrote: > >> At the request of some of the Hotspot team, I am trying an experiment to do the following: >> >> As you are all probably aware, currently our build process to build a Sumatra JDK image is two steps: >> >> >> 1) Build the Sumatra-modified JDK >> >> a. there are a small number of classes (less than 10) from java.util.stream that get modified to enable the gpu offload. If offload is detected it then calls into graal. >> >> >> >> 2) With JAVA_HOME set to the Sumatra-modified JDK, build graal "server" compiler. >> >> This uses its own special "mx build" command. >> >> This produces a new JDK image with the following changes: >> >> 2.1) from the graal java sources, a graal.jar in the jre/lib directory >> >> 2.2) from the graal hotspot sources, a new hotspot libjvm.so in the jre/lib/amd64/server directory >> >> >> >> >> We wanted to add enough classes to sumatra-dev/jdk and sumatra-dev/hotspot so that we could skip step 2 above but still build a functional sumatra able to offload to hsail. So the equivalent of graal.jar would be built into rt.jar ideally includes only that part of graal java and graal hotspot that would be necessary for an HSAIL backend. A webrev from before vs. after then would let use see what the hsail/graal additional footprint would be. But for a first cut, we wouldn't spend too much time getting down to the minimum footprint. >> >> So far we have some success. >> >> I modified mx/projects so that what I thought were the unnecessary project sets would not be included in graal.jar (so truffle, sparc, ptx. Note that we do need the graal amd64 backend because of the way hsail deoptimization is done). >> >> I did our normal 2-part sumatra build and everything seemed to work, and if you look at graal.jar you can see it does not have the classes that were removed via mx projects. >> >> Then I took the graal java sources for the classes that were still in graal.jar and added them to the sumatra-dev/jdk. I also took the hotspot src tree from graal (which is a modification of hs25-b63) and used that instead of the vanilla hs25-b63 tag in sumatra-dev/hotspot. >> >> After a few hiccups like having to manually add the graal-generated files graalRuntime.inline.hpp and HotspotVMConfig.inline.hpp to the sumatra-dev/hotspot, things built. >> >> And I am able to run sumatra offloads to HSAIL as long as I turn off HSAILDeoptimization. >> >> But with HSAILDeoptimization on (the default), I see a NPE coming from >> >> >> com.oracle.graal.graph.GraalGraphInternalError: com.oracle.graal.compiler.common.GraalInternalError: java.lang.NullPointerException >> >> at lir instruction: B2 at 38 DEOPT_CALLER stack:16|j >> >> [B0, B2, B1] >> >> at lir instruction: B2 at 38 DEOPT_CALLER stack:16|j >> >> [B0, B2, B1] >> >> at node: 12|VMError >> >> at com.oracle.graal.graph.GraalGraphInternalError.transformAndAddContext(GraalGraphInternalError.java:136) >> >> at com.oracle.graal.compiler.gen.NodeLIRBuilder.doBlock(NodeLIRBuilder.java:220) >> >> at com.oracle.graal.compiler.GraalCompiler.emitBlock(GraalCompiler.java:216) >> >> at com.oracle.graal.compiler.GraalCompiler.emitLIR(GraalCompiler.java:250) >> >> at com.oracle.graal.compiler.GraalCompiler.emitBackEnd(GraalCompiler.java:198) >> >> at com.oracle.graal.compiler.GraalCompiler.compileGraph(GraalCompiler.java:141) >> >> at com.oracle.graal.hotspot.hsail.HSAILHotSpotBackend.installKernel(HSAILHotSpotBackend.java:286) >> >> at com.oracle.graal.hotspot.hsail.ForEachToGraal.getCompiledLambda(ForEachToGraal.java:143) >> >> at com.oracle.graal.hotspot.hsail.ForEachToGraal.createKernel(ForEachToGraal.java:149) >> >> at java.util.stream.PipelineInfo.offloadForEachPipeline(PipelineInfo.java:391) >> >> >> >> Caused by: java.lang.NullPointerException >> >> at com.oracle.graal.replacements.SnippetTemplate$SnippetInfo$Lazy.initNames(SnippetTemplate.java:118) >> >> at com.oracle.graal.replacements.SnippetTemplate$SnippetInfo$Lazy.(SnippetTemplate.java:102) >> >> at com.oracle.graal.replacements.SnippetTemplate$SnippetInfo.lazy(SnippetTemplate.java:146) >> >> at com.oracle.graal.replacements.SnippetTemplate$SnippetInfo.getParameterCount(SnippetTemplate.java:174) >> >> at com.oracle.graal.replacements.SnippetTemplate$CacheKey.(SnippetTemplate.java:384) >> >> at com.oracle.graal.replacements.SnippetTemplate$Arguments.(SnippetTemplate.java:221) >> >> at com.oracle.graal.hotspot.stubs.SnippetStub.makeArguments(SnippetStub.java:99) >> >> at com.oracle.graal.hotspot.stubs.SnippetStub.getGraph(SnippetStub.java:92) >> >> at com.oracle.graal.hotspot.stubs.Stub.getCode(Stub.java:148) >> >> >> >> so we are in the code that builds the trampoline host code (which explains why this only shows up in the hsail deoptimization codepath). >> >> >> >> When I step into SnippetInfo$Lazy.initNames, I can see that the NPE is coming because method.getLocalVariableTable() is returning null because in HotSpotResolvedMethod.getLocalVariableTable() we see that (getConstMethodFlags() & runtime().getConfig().constMethodHasLocalVariableTable) == 0); >> >> >> >> private boolean initNames(ResolvedJavaMethod method, int parameterCount) { >> >> names = new String[parameterCount]; >> >> int slotIdx = 0; >> >> for (int i = 0; i < names.length; i++) { >> >> names[i] = method.getLocalVariableTable().getLocal(slotIdx, 0).getName(); >> >> >> >> Kind kind = method.getSignature().getParameterKind(i); >> >> slotIdx += kind == Kind.Long || kind == Kind.Double ? 2 : 1; >> >> } >> >> return true; >> >> } >> >> any suggestions? >> >> I had assumed that the HotSpotVMConfig.inline.hpp that was produced in the graal build could just be used as is in sumatra-dev/hotspot but I don't really understand whether that is a valid assumption. >> >> -- Tom > From doug.simon at oracle.com Fri Jul 11 01:00:06 2014 From: doug.simon at oracle.com (doug.simon at oracle.com) Date: Fri, 11 Jul 2014 01:00:06 +0000 Subject: hg: graal/graal: 36 new changesets Message-ID: <201407110100.s6B107YB006289@aojmv0008> Changeset: 36ae19c8fb4e Author: Lukas Stadler Date: 2014-07-08 16:12 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/36ae19c8fb4e clean up MemoryNode interface (remove asMemory... methods) ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/nodes/DeoptimizationFetchUnrollInfoCallNode.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/nodes/DirectCompareAndSwapNode.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/nodes/StubForeignCallNode.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/nodes/UncommonTrapCallNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/AbstractMemoryCheckpoint.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/InvokeWithExceptionNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/KillingBeginNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/MemoryPhiNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/MemoryProxyNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/StartNode.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/FloatingReadNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/extended/MembarNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/extended/MemoryNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/extended/UnsafeStoreNode.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/LoweredAtomicReadAndWriteNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/java/LoweredCompareAndSwapNode.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/nodes/MacroStateSplitNode.java ! graal/com.oracle.graal.replacements/src/com/oracle/graal/replacements/nodes/MemoryAnchorNode.java Changeset: 409e9e09324b Author: Lukas Stadler Date: 2014-07-08 16:13 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/409e9e09324b code cleanup in WriteBarrierAdditionPhase ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/phases/WriteBarrierAdditionPhase.java Changeset: f1e4ed5ac7d2 Author: Lukas Stadler Date: 2014-07-08 16:13 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/f1e4ed5ac7d2 cleanup in AssertionSnippets (remove unused native method) ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/AssertionSnippets.java Changeset: 0de9f76a4b3d Author: Lukas Stadler Date: 2014-07-08 16:14 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/0de9f76a4b3d use a location for stack banging ! 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 Changeset: a6c3ea7ac369 Author: Lukas Stadler Date: 2014-07-08 16:17 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/a6c3ea7ac369 let ForeignStubCallNode kill PENDING_EXCEPTION_LOCATION ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/nodes/StubForeignCallNode.java Changeset: e941121f096f Author: Lukas Stadler Date: 2014-07-08 16:17 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/e941121f096f skip assertion in SchedulePhase for MemoryCheckpoint.Multi nodes ! graal/com.oracle.graal.phases/src/com/oracle/graal/phases/schedule/SchedulePhase.java Changeset: 843e8efacd13 Author: Lukas Stadler Date: 2014-07-08 16:24 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/843e8efacd13 getDisplacementStamp on LocationNodes ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/extended/AddLocationNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/extended/ConstantLocationNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/extended/IndexedLocationNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/extended/LocationNode.java ! graal/com.oracle.graal.word/src/com/oracle/graal/word/nodes/SnippetLocationNode.java Changeset: eff9559f4515 Author: Lukas Stadler Date: 2014-07-08 16:25 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/eff9559f4515 don't let reads float across SaveAllRegistersNode ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/nodes/SaveAllRegistersNode.java Changeset: 4584f29431be Author: Lukas Stadler Date: 2014-07-10 10:20 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/4584f29431be check phi types in during PEA state merging ! graal/com.oracle.graal.virtual/src/com/oracle/graal/virtual/phases/ea/PartialEscapeClosure.java Changeset: ce6696559683 Author: Doug Simon Date: 2014-07-10 12:33 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/ce6696559683 better fix for deadlock in GraalVM under -Xcomp (JBS:GRAAL-48) ! src/share/vm/compiler/compileBroker.cpp ! src/share/vm/runtime/thread.cpp Changeset: a51dab45c6b3 Author: Lukas Stadler Date: 2014-07-10 13:42 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/a51dab45c6b3 fix for IfNode.pushNodesThroughIf (push more than one node) ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/IfNode.java Changeset: d8d4120c62ae Author: Lukas Stadler Date: 2014-07-10 13:42 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/d8d4120c62ae throw error when lowering MacroNode without stateAfter to an InvokeNode ! graal/com.oracle.graal.replacements/src/com/oracle/graal/replacements/nodes/MacroNode.java Changeset: b650d0a98146 Author: Lukas Stadler Date: 2014-07-10 14:04 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/b650d0a98146 new GraphUtil.unlinkFixedNode utility method ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/IfNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/StructuredGraph.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/util/GraphUtil.java ! graal/com.oracle.graal.replacements/src/com/oracle/graal/replacements/NodeIntrinsificationPhase.java ! graal/com.oracle.graal.virtual/src/com/oracle/graal/virtual/phases/ea/GraphEffectList.java Changeset: 394b949fec5a Author: Lukas Stadler Date: 2014-07-10 14:04 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/394b949fec5a setter for MonitorExitNode.escapedReturnValue ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/java/MonitorExitNode.java Changeset: 41906973537e Author: Lukas Stadler Date: 2014-07-10 14:04 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/41906973537e better stamps for left shifts with fixed shift amount ! graal/com.oracle.graal.nodes.test/src/com/oracle/graal/nodes/test/IntegerStampTest.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/type/StampTool.java Changeset: 2824f2d25339 Author: Lukas Stadler Date: 2014-07-10 14:23 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/2824f2d25339 fix for getDisplacementStamp ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/extended/IndexedLocationNode.java Changeset: 973b5704b95d Author: Lukas Stadler Date: 2014-07-10 14:30 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/973b5704b95d GraphEffectList rework (with lambdas) ! graal/com.oracle.graal.virtual/src/com/oracle/graal/virtual/phases/ea/EffectList.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/GraphEffectList.java ! graal/com.oracle.graal.virtual/src/com/oracle/graal/virtual/phases/ea/PartialEscapeBlockState.java Changeset: 59fdea1f9e36 Author: Doug Simon Date: 2014-07-10 15:03 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/59fdea1f9e36 factored out _eclipseinit_project to all per-project Eclipse configuration ! mxtool/mx.py Changeset: 9f43efeabb4c Author: Lukas Stadler Date: 2014-07-10 16:45 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/9f43efeabb4c make some fields accessible in EffectsClosure ! graal/com.oracle.graal.virtual/src/com/oracle/graal/virtual/phases/ea/EffectsClosure.java Changeset: c51516ebe71c Author: Lukas Stadler Date: 2014-07-10 16:44 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/c51516ebe71c remove value proxies during MacroNode lowering ! graal/com.oracle.graal.replacements/src/com/oracle/graal/replacements/nodes/MacroNode.java Changeset: 162c6fba1168 Author: Lukas Stadler Date: 2014-07-10 16:45 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/162c6fba1168 start Stub compilation at mid tier ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/stubs/Stub.java ! graal/com.oracle.graal.phases/src/com/oracle/graal/phases/tiers/Suites.java Changeset: a039ae7e0e50 Author: Lukas Stadler Date: 2014-07-10 16:46 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/a039ae7e0e50 remove MemoryProxyNode (memory graph is built after proxies are removed) ! graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/MemoryScheduleTest.java ! graal/com.oracle.graal.loop/src/com/oracle/graal/loop/LoopFragment.java - graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/MemoryProxyNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/ProxyNode.java ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/FloatingReadPhase.java Changeset: 1da834bdfda2 Author: Lukas Stadler Date: 2014-07-10 17:07 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/1da834bdfda2 let FloatingReadPhase deal with existing MemoryPhiNodes ! 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: be0ad9b9aefe Author: Lukas Stadler Date: 2014-07-10 17:11 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/be0ad9b9aefe do not create proxy nodes if the graph doesn't need them ! graal/com.oracle.graal.virtual/src/com/oracle/graal/virtual/phases/ea/PEReadEliminationClosure.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/ReadEliminationClosure.java Changeset: 1a6989c482f6 Author: Lukas Stadler Date: 2014-07-10 17:17 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/1a6989c482f6 assertion in ConvertDeoptimizeToGuardPhase ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/ConvertDeoptimizeToGuardPhase.java Changeset: f1d839174e71 Author: Roland Schatz Date: 2014-07-10 18:29 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/f1d839174e71 Support for specifying log and dump levels. ! graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/FlowSenReduTest.java ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/DebugFilter.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/DelegatingDebugConfig.java ! graal/com.oracle.graal.debug/src/com/oracle/graal/debug/internal/DebugScope.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 Changeset: 76081918079d Author: Andreas Woess Date: 2014-07-10 18:08 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/76081918079d Truffle: move TraceRewrites code to NodeUtil ! graal/com.oracle.truffle.api/src/com/oracle/truffle/api/nodes/Node.java ! graal/com.oracle.truffle.api/src/com/oracle/truffle/api/nodes/NodeUtil.java Changeset: 456abab80eb5 Author: Andreas Woess Date: 2014-07-10 18:08 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/456abab80eb5 Truffle: remove obsolete NodeUtil.findNodeInstancesInFunction (functionally equivalent to findAllNodeInstances) ! graal/com.oracle.truffle.api/src/com/oracle/truffle/api/nodes/NodeUtil.java Changeset: d41922beb512 Author: Andreas Woess Date: 2014-07-10 18:08 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/d41922beb512 Truffle: use ClassValue for NodeClass ! graal/com.oracle.truffle.api/src/com/oracle/truffle/api/nodes/NodeUtil.java Changeset: 17f7331dcc4f Author: Andreas Woess Date: 2014-07-10 18:08 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/17f7331dcc4f Truffle: move iterator to NodeClass ! graal/com.oracle.truffle.api/src/com/oracle/truffle/api/nodes/Node.java ! graal/com.oracle.truffle.api/src/com/oracle/truffle/api/nodes/NodeUtil.java Changeset: 9fa5872291c1 Author: Andreas Woess Date: 2014-07-10 18:15 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/9fa5872291c1 Truffle: improve NodeIterator ! graal/com.oracle.truffle.api/src/com/oracle/truffle/api/nodes/NodeUtil.java Changeset: cec5a97ba1e4 Author: Andreas Woess Date: 2014-07-10 19:34 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/cec5a97ba1e4 PartialEvaluator: do not rely on ResolvedJavaMethod#canBeInlined() ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/PartialEvaluator.java Changeset: efbf9195dfcb Author: Andreas Woess Date: 2014-07-08 20:19 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/efbf9195dfcb Truffle: add argument type speculation ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/OptimizedCallTarget.java ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/TruffleCompilerOptions.java Changeset: 352de9bd8fd5 Author: Andreas Woess Date: 2014-07-10 19:36 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/352de9bd8fd5 Merge Changeset: 83dce5b6cb41 Author: Andreas Woess Date: 2014-07-10 20:36 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/83dce5b6cb41 Truffle: remove needless null check ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/OptimizedCallTarget.java Changeset: f681a647246c Author: Andreas Woess Date: 2014-07-10 20:43 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/f681a647246c uppercase JSON for consistency ! graal/com.oracle.truffle.api/src/com/oracle/truffle/api/utilities/JSONHelper.java From doug.simon at oracle.com Fri Jul 11 13:09:56 2014 From: doug.simon at oracle.com (doug.simon at oracle.com) Date: Fri, 11 Jul 2014 13:09:56 +0000 Subject: hg: graal/graal: 22 new changesets Message-ID: <201407111309.s6BD9ufK021309@aojmv0008> Changeset: 000a1a014bd4 Author: Andreas Woess Date: 2014-07-11 02:57 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/000a1a014bd4 Backed out changeset: cec5a97ba1e4 ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/PartialEvaluator.java Changeset: 6ce37ad3ea47 Author: Lukas Stadler Date: 2014-07-11 13:40 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/6ce37ad3ea47 simplify MemoryPhiNodes and GuardPhiNodes with single values ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/GuardPhiNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/MemoryPhiNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/PhiNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/ValuePhiNode.java Changeset: 92f75d104b4b Author: Doug Simon Date: 2014-07-10 21:20 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/92f75d104b4b moved getElementalType() from MetaUtil to be a default method in JavaType ! graal/com.oracle.graal.api.code/src/com/oracle/graal/api/code/Assumptions.java ! graal/com.oracle.graal.api.code/src/com/oracle/graal/api/code/TypeCheckHints.java ! graal/com.oracle.graal.api.meta/src/com/oracle/graal/api/meta/JavaType.java ! graal/com.oracle.graal.api.meta/src/com/oracle/graal/api/meta/MetaUtil.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/meta/HotSpotResolvedObjectType.java Changeset: 46397dc87086 Author: Doug Simon Date: 2014-07-10 21:46 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/46397dc87086 moved getParameterAnnotation() from MetaUtil to be a default method in ResolvedJavaMethod ! graal/com.oracle.graal.api.meta/src/com/oracle/graal/api/meta/MetaUtil.java ! graal/com.oracle.graal.api.meta/src/com/oracle/graal/api/meta/ResolvedJavaMethod.java ! graal/com.oracle.graal.compiler.ptx/src/com/oracle/graal/compiler/ptx/PTXNodeLIRBuilder.java ! graal/com.oracle.graal.hotspot.ptx/src/com/oracle/graal/hotspot/ptx/PTXWrapperBuilder.java ! graal/com.oracle.graal.replacements/src/com/oracle/graal/replacements/NodeIntrinsificationPhase.java ! graal/com.oracle.graal.replacements/src/com/oracle/graal/replacements/SnippetTemplate.java Changeset: 1f1ac8857d92 Author: Doug Simon Date: 2014-07-10 22:25 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/1f1ac8857d92 moved toJavaName(JavaType type, boolean qualified) from MetaUtil to be a default method in JavaType ! graal/com.oracle.graal.api.code/src/com/oracle/graal/api/code/VirtualObject.java ! graal/com.oracle.graal.api.meta/src/com/oracle/graal/api/meta/JavaType.java ! graal/com.oracle.graal.api.meta/src/com/oracle/graal/api/meta/MetaUtil.java ! graal/com.oracle.graal.hotspot.hsail/src/com/oracle/graal/hotspot/hsail/replacements/HSAILNewObjectSnippets.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/NewObjectSnippets.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/virtual/CommitAllocationNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/virtual/VirtualInstanceNode.java ! graal/com.oracle.graal.replacements/src/com/oracle/graal/replacements/NodeIntrinsificationPhase.java ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/PartialEvaluator.java Changeset: 558cf39c646b Author: Doug Simon Date: 2014-07-10 22:33 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/558cf39c646b moved toJavaName(JavaType type) from MetaUtil to be a default method in JavaType ! 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/TestMetaAccessProvider.java ! graal/com.oracle.graal.api.meta/src/com/oracle/graal/api/meta/JavaType.java ! graal/com.oracle.graal.api.meta/src/com/oracle/graal/api/meta/Kind.java ! graal/com.oracle.graal.api.meta/src/com/oracle/graal/api/meta/MetaUtil.java ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/MethodFilter.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotMethodData.java ! graal/com.oracle.graal.java/src/com/oracle/graal/java/BytecodeDisassembler.java ! graal/com.oracle.graal.printer/src/com/oracle/graal/printer/BinaryGraphPrinter.java ! graal/com.oracle.graal.replacements/src/com/oracle/graal/replacements/NodeIntrinsificationPhase.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 Changeset: 10c12d09a8d2 Author: Doug Simon Date: 2014-07-10 22:44 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/10c12d09a8d2 moved format(String format, JavaMethod method) from MetaUtil to be a default method in JavaMethod ! graal/com.oracle.graal.api.code/src/com/oracle/graal/api/code/Assumptions.java ! graal/com.oracle.graal.api.meta/src/com/oracle/graal/api/meta/JavaMethod.java ! graal/com.oracle.graal.api.meta/src/com/oracle/graal/api/meta/MetaUtil.java ! graal/com.oracle.graal.baseline/src/com/oracle/graal/baseline/BaselineBytecodeParser.java ! graal/com.oracle.graal.compiler.hsail/src/com/oracle/graal/compiler/hsail/HSAILNodeLIRBuilder.java ! graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/GraalCompilerTest.java ! 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/debug/BenchmarkCounters.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotMethod.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotMethodData.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotNmethod.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotResolvedJavaMethod.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/MonitorSnippets.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/stubs/ForeignCallStub.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/stubs/SnippetStub.java ! graal/com.oracle.graal.java/src/com/oracle/graal/java/BciBlockMapping.java ! graal/com.oracle.graal.java/src/com/oracle/graal/java/BytecodeDisassembler.java ! graal/com.oracle.graal.java/src/com/oracle/graal/java/GraphBuilderPhase.java ! graal/com.oracle.graal.loop/src/com/oracle/graal/loop/LoopEx.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/DirectCallTargetNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/IndirectCallTargetNode.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/cfs/FlowSensitiveReductionPhase.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/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/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/walker/CallsiteHolderExplorable.java ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/inlining/walker/MethodInvocation.java ! graal/com.oracle.graal.phases/src/com/oracle/graal/phases/verify/VerifyDebugUsage.java ! graal/com.oracle.graal.printer/src/com/oracle/graal/printer/CompilationPrinter.java ! graal/com.oracle.graal.printer/src/com/oracle/graal/printer/GraphPrinterDumpHandler.java ! graal/com.oracle.graal.replacements/src/com/oracle/graal/replacements/NodeIntrinsificationPhase.java ! graal/com.oracle.graal.replacements/src/com/oracle/graal/replacements/NodeIntrinsificationVerificationPhase.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.truffle/src/com/oracle/graal/truffle/TruffleDebugJavaMethod.java ! graal/com.oracle.graal.virtual/src/com/oracle/graal/virtual/phases/ea/VirtualUtil.java ! graal/com.oracle.graal.word/src/com/oracle/graal/word/phases/WordTypeVerificationPhase.java Changeset: e7fc65330742 Author: Doug Simon Date: 2014-07-10 22:48 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/e7fc65330742 moved format(String format, JavaField field) from MetaUtil to be a default method in JavaField ! graal/com.oracle.graal.api.meta/src/com/oracle/graal/api/meta/JavaField.java ! graal/com.oracle.graal.api.meta/src/com/oracle/graal/api/meta/MetaUtil.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotResolvedJavaField.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotUnresolvedField.java ! graal/com.oracle.graal.java/src/com/oracle/graal/java/BytecodeDisassembler.java Changeset: 162f3f682613 Author: Doug Simon Date: 2014-07-10 22:51 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/162f3f682613 moved lookupJavaTypes(MetaAccessProvider metaAccess, Class[] classes) from MetaUtil to be a default method in MetaAccessProvider ! graal/com.oracle.graal.api.meta/src/com/oracle/graal/api/meta/MetaAccessProvider.java ! graal/com.oracle.graal.api.meta/src/com/oracle/graal/api/meta/MetaUtil.java Changeset: 3c3cd36a3836 Author: Doug Simon Date: 2014-07-10 23:02 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/3c3cd36a3836 moved signatureToMethodDescriptor(Signature sig) from MetaUtil to be a default method in Signature ! graal/com.oracle.graal.api.meta/src/com/oracle/graal/api/meta/MetaUtil.java ! graal/com.oracle.graal.api.meta/src/com/oracle/graal/api/meta/Signature.java ! graal/com.oracle.graal.api.replacements/src/com/oracle/graal/api/replacements/MethodSubstitution.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/CompilationStatistics.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/CompilationTask.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotSignature.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/spi/MacroSubstitution.java Changeset: 27f2ee618883 Author: Doug Simon Date: 2014-07-10 23:07 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/27f2ee618883 moved signatureToTypes(Signature signature, JavaType receiverType) from MetaUtil to be a default method in Signature ! graal/com.oracle.graal.api.meta/src/com/oracle/graal/api/meta/MetaUtil.java ! graal/com.oracle.graal.api.meta/src/com/oracle/graal/api/meta/Signature.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/TailcallNode.java ! graal/com.oracle.graal.replacements/src/com/oracle/graal/replacements/NodeIntrinsificationPhase.java Changeset: d6604020da93 Author: Doug Simon Date: 2014-07-10 23:15 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/d6604020da93 removed com.oracle.graal.api.meta.jdk8.test project - graal/com.oracle.graal.api.meta.jdk8.test/src/com/oracle/graal/api/meta/jdk8/test/TestResolvedJavaMethodJDK8.java ! graal/com.oracle.graal.api.meta.test/src/com/oracle/graal/api/meta/test/TestResolvedJavaMethod.java ! graal/com.oracle.graal.api.meta.test/src/com/oracle/graal/api/meta/test/TestResolvedJavaType.java ! mx/projects Changeset: d3fc4779fc60 Author: Doug Simon Date: 2014-07-10 23:22 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/d3fc4779fc60 moved signatureToTypes(ResolvedJavaMethod method) from MetaUtil to be a default method in ResolvedJavaMethod ! graal/com.oracle.graal.api.meta/src/com/oracle/graal/api/meta/MetaUtil.java ! graal/com.oracle.graal.api.meta/src/com/oracle/graal/api/meta/ResolvedJavaMethod.java ! graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/GraalCompilerTest.java ! graal/com.oracle.graal.hotspot.test/src/com/oracle/graal/hotspot/test/InstalledCodeExecuteHelperTest.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotNmethod.java ! graal/com.oracle.graal.jtt/src/com/oracle/graal/jtt/JTTTest.java ! graal/com.oracle.graal.replacements/src/com/oracle/graal/replacements/NodeIntrinsificationPhase.java Changeset: 1ffe4349f945 Author: Doug Simon Date: 2014-07-10 23:45 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/1ffe4349f945 moved toClassName(JavaType) from MetaUtil to be a default method in JavaType ! graal/com.oracle.graal.api.meta/src/com/oracle/graal/api/meta/JavaType.java ! graal/com.oracle.graal.api.meta/src/com/oracle/graal/api/meta/MetaUtil.java Changeset: 890d25ac05c3 Author: Doug Simon Date: 2014-07-10 23:49 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/890d25ac05c3 moved getParameterAnnotations(Class annotationClass, ResolvedJavaMethod method) from MetaUtil to be a default method in ResolvedJavaMethod ! graal/com.oracle.graal.api.meta/src/com/oracle/graal/api/meta/MetaUtil.java ! graal/com.oracle.graal.api.meta/src/com/oracle/graal/api/meta/ResolvedJavaMethod.java ! graal/com.oracle.graal.replacements/src/com/oracle/graal/replacements/SnippetTemplate.java Changeset: db92d4a1564a Author: Doug Simon Date: 2014-07-10 23:50 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/db92d4a1564a fixed minor regression ! graal/com.oracle.graal.api.meta.test/src/com/oracle/graal/api/meta/test/TestResolvedJavaMethod.java Changeset: cac0a7d1c325 Author: Doug Simon Date: 2014-07-10 23:56 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/cac0a7d1c325 moved profileToString(ProfilingInfo info, ResolvedJavaMethod method, String sep) from MetaUtil to be a default method in ProfilingInfo ! graal/com.oracle.graal.api.meta/src/com/oracle/graal/api/meta/DefaultProfilingInfo.java ! graal/com.oracle.graal.api.meta/src/com/oracle/graal/api/meta/MetaUtil.java ! graal/com.oracle.graal.api.meta/src/com/oracle/graal/api/meta/ProfilingInfo.java ! graal/com.oracle.graal.baseline/src/com/oracle/graal/baseline/BaselineBytecodeParser.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotProfilingInfo.java ! graal/com.oracle.graal.java/src/com/oracle/graal/java/GraphBuilderPhase.java Changeset: 4d7a9829315e Author: Doug Simon Date: 2014-07-11 00:27 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/4d7a9829315e moved isJavaLangObject(ResolvedJavaType type) from MetaUtil to be a default method in ResolvedJavaType ! 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/MetaUtil.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/meta/HotSpotResolvedObjectType.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotResolvedPrimitiveType.java ! graal/com.oracle.graal.replacements/src/com/oracle/graal/replacements/DefaultJavaLoweringProvider.java Changeset: 8853b9304083 Author: Doug Simon Date: 2014-07-11 13:47 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/8853b9304083 made type resolution require an accessing class context ! graal/com.oracle.graal.api.meta/src/com/oracle/graal/api/meta/JavaType.java ! graal/com.oracle.graal.api.meta/src/com/oracle/graal/api/meta/ProfilingInfo.java ! graal/com.oracle.graal.api.meta/src/com/oracle/graal/api/meta/ResolvedJavaType.java ! graal/com.oracle.graal.api.meta/src/com/oracle/graal/api/meta/Signature.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/HotSpotGraalRuntime.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/bridge/CompilerToVM.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.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotSignature.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotUnresolvedJavaType.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/stubs/ForeignCallStub.java ! src/share/vm/graal/graalCompilerToVM.cpp Changeset: b45bb90c0192 Author: Doug Simon Date: 2014-07-11 14:19 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/b45bb90c0192 added forwarding methods to MetaUtil and marked them with @Deprecated to simplify adapting new API ! graal/com.oracle.graal.api.meta/src/com/oracle/graal/api/meta/JavaType.java ! graal/com.oracle.graal.api.meta/src/com/oracle/graal/api/meta/MetaUtil.java Changeset: d8d90184ec66 Author: Doug Simon Date: 2014-07-11 14:21 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/d8d90184ec66 Merge. ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/PartialEvaluator.java Changeset: 569b90d12edb Author: Doug Simon Date: 2014-07-11 14:27 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/569b90d12edb fixed eclipseformat issue ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/HotSpotGraalRuntime.java From doug.simon at oracle.com Sat Jul 12 01:00:27 2014 From: doug.simon at oracle.com (doug.simon at oracle.com) Date: Sat, 12 Jul 2014 01:00:27 +0000 Subject: hg: graal/graal: 5 new changesets Message-ID: <201407120100.s6C10ROm012268@aojmv0008> Changeset: b40984b06157 Author: Lukas Stadler Date: 2014-07-11 16:41 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/b40984b06157 make PhiNode.singleValue behave correctly for null values (in guard phis) ! graal/com.oracle.graal.loop/src/com/oracle/graal/loop/InductionVariables.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/PhiNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/ValuePhiNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/util/GraphUtil.java Changeset: c087cb67ba6d Author: Bernhard Urban Date: 2014-07-11 16:28 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/c087cb67ba6d findbugs: bump version ! mx/projects Changeset: b11f1c7cf6a5 Author: Bernhard Urban Date: 2014-07-11 16:30 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/b11f1c7cf6a5 findbugs: add lafo mirror ! mx/projects Changeset: a0f3688ce052 Author: Bernhard Urban Date: 2014-07-11 16:48 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/a0f3688ce052 findbugs: fix URLs in mx helper ! mx/mx_graal.py Changeset: 48d26e6289c7 Author: Doug Simon Date: 2014-07-11 17:54 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/48d26e6289c7 added tests for type resolution ! 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/TestJavaType.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/HotSpotGraalRuntime.java From java at stefan-marr.de Mon Jul 14 12:35:02 2014 From: java at stefan-marr.de (Stefan Marr) Date: Mon, 14 Jul 2014 14:35:02 +0200 Subject: Loop Peeling in Guest Language | Was: Optimization Thresholds? In-Reply-To: References: Message-ID: Hi: Turns out, my issue from a month ago wasn?t actually related to the reflective aspects at all and the specializations I put in place to optimize them worked perfectly. Instead, the problem turned out to be one that can be solved with loop peeling. It seems, for some reason that is not entirely clear to me, the first iteration of the loop is different and that seems to be somehow related to reading an object field. Either way, the micro benchmark benefits from an explicitly peeled first loop iteration implemented in the specialization node. That means, I use two DirectCallNodes for the loop body, one for the first iteration, and the second one for the other iterations [1]. Unfortunately, this form of loop peeling is not generally a win. Kalibera et al report that it is useful in R for loops [2]. However, on my benchmark collection, I see that it reduces performance on average. So, I was wondering what your experience with loop peeling on the level of the guest language is. Are there perhaps some heuristics that would help to decide whether to use it or not? Thanks Stefan [1] https://github.com/SOM-st/TruffleSOM/blob/master/src/som/interpreter/nodes/specialized/IntToDoMessageNode.java#L58 [2] http://dl.acm.org/citation.cfm?doid=2576195.2576205 On 09 Jun 2014, at 22:06, Stefan Marr wrote: > Hi: > > I am running into a strange issue when optimizing some reflective operations. > Don?t think it is related to the operations themselves, but rather the way the optimizations/Graal works. > > If benchmarked separately, I see, as desired, the same performance results for direct and reflective operations. > So, I assume that my specializations are sufficient to please the optimizer. > Concretely, that is reflective method invocation via Smalltalk?s #perform: as well as intercepting undefined methods with #doesNotUnderstand:. > > However, if both reflective mechanisms are used in combination to implement something like dynamic proxies, runtime nearly doubles compared to what I would expect. > > I have been experimenting with the various thresholds in TruffleCompilerOptions, but without any luck. > Since the benchmarks are still microbenchmarks, I don?t think I am really hitting any of those anyway. > The fully inlined tree has something like 220 nodes. That?s the number I see in the error output after setting TruffleGraphMaxNodes to a very small number. And, that?s just about 20 more than what I get reported for the non-reflective, i.e., direct benchmark. > > What would be a good approach to figure out what?s going wrong here? > > Thanks > Stefan > > To reporduce: > > git clone --recursive https://github.com/SOM-st/TruffleSOM.git > ant jar > ant test > ./graal.sh -cp Smalltalk:Examples/Benchmarks/DoesNotUnderstand Examples/Benchmarks/BenchmarkHarness.som DirectAdd 20 0 1000 > ./graal.sh -cp Smalltalk:Examples/Benchmarks/DoesNotUnderstand Examples/Benchmarks/BenchmarkHarness.som ProxyAdd 20 0 1000 > > -- > Stefan Marr > INRIA Lille - Nord Europe > http://stefan-marr.de/research/ > > > -- Stefan Marr INRIA Lille - Nord Europe http://stefan-marr.de/research/ From eric.caspole at amd.com Mon Jul 14 20:26:10 2014 From: eric.caspole at amd.com (Eric Caspole) Date: Mon, 14 Jul 2014 16:26:10 -0400 Subject: mx does not like .hotspot_compiler Message-ID: <53C43CE2.5090305@amd.com> We are usually running Graal with -server so only the HSAIL part is built with Graal. We were hitting an assert in C2 code and eventually I tried using a .hotspot_compiler file, but it makes mx fail, for example: $ cat .hotspot_compiler exclude java/lang/String indexOf $ ./mx.sh --vm server --vmbuild fastdebug unittest -server -ea -esa -XX:-TraceGPUInteraction -Dcom.amd.sumatra.offload.immediate=true hsail.test.lambda Traceback (most recent call last): File "/home/ecaspole/views/graal-default/graal/mxtool/mx.py", line 4912, in main() File "/home/ecaspole/views/graal-default/graal/mxtool/mx.py", line 4849, in main defaultJdk = JavaConfig(opts.java_home, opts.java_dbg_port) File "/home/ecaspole/views/graal-default/graal/mxtool/mx.py", line 1740, in __init__ assert output[1] == 'version' AssertionError Even a completely empty .hotspot_compiler file causes it to fail. Eventually I found -XX:CompileCommand= worked OK. From tom.rodriguez at oracle.com Mon Jul 14 21:08:26 2014 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Mon, 14 Jul 2014 14:08:26 -0700 Subject: mx does not like .hotspot_compiler In-Reply-To: <53C43CE2.5090305@amd.com> References: <53C43CE2.5090305@amd.com> Message-ID: hotspot_compiler as an automatically read file is deprecated in the product since it?s a potential security hole. If .hotspot_compiler exists it will emit a warning about the new behavior which screws up tools that parse VM output like mx. You can use -XX:CompileCommandFile= instead, just don?t use the .hotspot_compiler name. tom On Jul 14, 2014, at 1:26 PM, Eric Caspole wrote: > We are usually running Graal with -server so only the HSAIL part is built with Graal. We were hitting an assert in C2 code and eventually I tried using a .hotspot_compiler file, but it makes mx fail, for example: > > > $ cat .hotspot_compiler > exclude java/lang/String indexOf > > > $ ./mx.sh --vm server --vmbuild fastdebug unittest -server -ea -esa -XX:-TraceGPUInteraction -Dcom.amd.sumatra.offload.immediate=true hsail.test.lambda > Traceback (most recent call last): > File "/home/ecaspole/views/graal-default/graal/mxtool/mx.py", line 4912, in > main() > File "/home/ecaspole/views/graal-default/graal/mxtool/mx.py", line 4849, in main > defaultJdk = JavaConfig(opts.java_home, opts.java_dbg_port) > File "/home/ecaspole/views/graal-default/graal/mxtool/mx.py", line 1740, in __init__ > assert output[1] == 'version' > AssertionError > > > Even a completely empty .hotspot_compiler file causes it to fail. > Eventually I found -XX:CompileCommand= worked OK. From eric.caspole at amd.com Mon Jul 14 22:21:14 2014 From: eric.caspole at amd.com (Eric Caspole) Date: Mon, 14 Jul 2014 18:21:14 -0400 Subject: mx does not like .hotspot_compiler In-Reply-To: References: <53C43CE2.5090305@amd.com> Message-ID: <53C457DA.5090709@amd.com> Thanks Tom, using the command line versions is OK for us. Here is the actual assert we hit while compiling Graal parts in -server mode with debug builds. This doesn't happen every time but I can usually get it to happen at least once in about 10 minutes of running our tests in a loop. Looks like: https://bugs.openjdk.java.net/browse/JDK-8030654 I vote for fixing this in debug builds. Thanks, Eric # # A fatal error has been detected by the Java Runtime Environment: # # Internal Error (/home/ecaspole/views/graal-openjdk/graal/src/share/vm/opto/chaitin.cpp:282), pid=16931, tid=140031381886720 # assert(_cfg.get_block_for_node(proj) == borig) failed: incorrect block for kill projections # # JRE version: OpenJDK Runtime Environment (8.0) (build 1.8.0-internal-ecaspole_2014_07_10_12_42-b00) # Java VM: OpenJDK 64-Bit Server VM (25.0-b63-internal-graal-0.3-debug mixed mode linux-amd64 compressed oops) # Core dump written. Default location: /home/ecaspole/views/graal-openjdk/graal/core or core.16931 # # If you would like to submit a bug report, please visit: # http://bugreport.sun.com/bugreport/crash.jsp # --------------- T H R E A D --------------- Current thread (0x00007f5bb01a2000): JavaThread "C2 CompilerThread0" daemon [_thread_in_native, id=16941, stack(0x00007f5b98b65000,0x00007f5b98c66000)] Stack: [0x00007f5b98b65000,0x00007f5b98c66000], sp=0x00007f5b98c60440, free space=1005k Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) V [libjvm.so+0xc7a096] VMError::report(outputStream*)+0x1112 V [libjvm.so+0xc7b583] VMError::report_and_die()+0x427 V [libjvm.so+0x611781] report_vm_error(char const*, int, char const*, char const*)+0xa5 V [libjvm.so+0x4fb4af] PhaseChaitin::clone_projs(Block*, unsigned int, Node*, Node*, unsigned int&)+0x145 V [libjvm.so+0xb53c2e] PhaseChaitin::split_Rematerialize(Node*, Block*, unsigned int, unsigned int&, GrowableArray, int, unsigned int*, Node**, bool)+0 x4f6 V [libjvm.so+0xb57873] PhaseChaitin::Split(unsigned int, ResourceArea*)+0x398f V [libjvm.so+0x4fbc07] PhaseChaitin::Register_Allocate()+0x557 V [libjvm.so+0x5a0b4e] Compile::Code_Gen()+0x284 V [libjvm.so+0x59aaa8] Compile::Compile(ciEnv*, C2Compiler*, ciMethod*, int, bool, bool, bool)+0x1348 V [libjvm.so+0x4d651b] C2Compiler::compile_method(ciEnv*, ciMethod*, int)+0x109 V [libjvm.so+0x5b103d] CompileBroker::invoke_compiler_on_method(CompileTask*)+0x4d1 V [libjvm.so+0x5b042b] CompileBroker::compiler_thread_loop()+0x3b3 V [libjvm.so+0xc24316] compiler_thread_entry(JavaThread*, Thread*)+0x57 V [libjvm.so+0xc1f68e] JavaThread::thread_main_inner()+0x124 V [libjvm.so+0xc1f55b] JavaThread::run()+0x163 V [libjvm.so+0xabda91] java_start(Thread*)+0x1bb Current CompileTask: C2: 296437 23955 4 com.oracle.graal.phases.common.CanonicalizerPhase$Instance::performReplacement (552 bytes) On 07/14/2014 05:08 PM, Tom Rodriguez wrote: > hotspot_compiler as an automatically read file is deprecated in the product since it?s a potential security hole. If .hotspot_compiler exists it will emit a warning about the new behavior which screws up tools that parse VM output like mx. You can use -XX:CompileCommandFile= instead, just don?t use the .hotspot_compiler name. > > tom > > On Jul 14, 2014, at 1:26 PM, Eric Caspole wrote: > >> We are usually running Graal with -server so only the HSAIL part is built with Graal. We were hitting an assert in C2 code and eventually I tried using a .hotspot_compiler file, but it makes mx fail, for example: >> >> >> $ cat .hotspot_compiler >> exclude java/lang/String indexOf >> >> >> $ ./mx.sh --vm server --vmbuild fastdebug unittest -server -ea -esa -XX:-TraceGPUInteraction -Dcom.amd.sumatra.offload.immediate=true hsail.test.lambda >> Traceback (most recent call last): >> File "/home/ecaspole/views/graal-default/graal/mxtool/mx.py", line 4912, in >> main() >> File "/home/ecaspole/views/graal-default/graal/mxtool/mx.py", line 4849, in main >> defaultJdk = JavaConfig(opts.java_home, opts.java_dbg_port) >> File "/home/ecaspole/views/graal-default/graal/mxtool/mx.py", line 1740, in __init__ >> assert output[1] == 'version' >> AssertionError >> >> >> Even a completely empty .hotspot_compiler file causes it to fail. >> Eventually I found -XX:CompileCommand= worked OK. > From doug.simon at oracle.com Tue Jul 15 01:00:06 2014 From: doug.simon at oracle.com (doug.simon at oracle.com) Date: Tue, 15 Jul 2014 01:00:06 +0000 Subject: hg: graal/graal: Canonicalize multiplication with 1.0 and addition with -0.0. Message-ID: <201407150100.s6F106Wt000249@aojmv0008> Changeset: f0f4402a4f65 Author: Roland Schatz Date: 2014-07-14 11:06 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/f0f4402a4f65 Canonicalize multiplication with 1.0 and addition with -0.0. ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/calc/FloatAddNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/calc/FloatDivNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/calc/FloatMulNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/calc/FloatSubNode.java From duboscq at ssw.jku.at Tue Jul 15 08:03:41 2014 From: duboscq at ssw.jku.at (Gilles Duboscq) Date: Tue, 15 Jul 2014 10:03:41 +0200 Subject: mx does not like .hotspot_compiler In-Reply-To: References: <53C43CE2.5090305@amd.com> Message-ID: I've already hit that one and went the CompileCommandFile= way. We could detect the .hotspot_compiler file in mx and pass in some fake CompileCommandFile when doing version detection. -Gilles On Mon, Jul 14, 2014 at 11:08 PM, Tom Rodriguez wrote: > hotspot_compiler as an automatically read file is deprecated in the product since it?s a potential security hole. If .hotspot_compiler exists it will emit a warning about the new behavior which screws up tools that parse VM output like mx. You can use -XX:CompileCommandFile= instead, just don?t use the .hotspot_compiler name. > > tom > > On Jul 14, 2014, at 1:26 PM, Eric Caspole wrote: > >> We are usually running Graal with -server so only the HSAIL part is built with Graal. We were hitting an assert in C2 code and eventually I tried using a .hotspot_compiler file, but it makes mx fail, for example: >> >> >> $ cat .hotspot_compiler >> exclude java/lang/String indexOf >> >> >> $ ./mx.sh --vm server --vmbuild fastdebug unittest -server -ea -esa -XX:-TraceGPUInteraction -Dcom.amd.sumatra.offload.immediate=true hsail.test.lambda >> Traceback (most recent call last): >> File "/home/ecaspole/views/graal-default/graal/mxtool/mx.py", line 4912, in >> main() >> File "/home/ecaspole/views/graal-default/graal/mxtool/mx.py", line 4849, in main >> defaultJdk = JavaConfig(opts.java_home, opts.java_dbg_port) >> File "/home/ecaspole/views/graal-default/graal/mxtool/mx.py", line 1740, in __init__ >> assert output[1] == 'version' >> AssertionError >> >> >> Even a completely empty .hotspot_compiler file causes it to fail. >> Eventually I found -XX:CompileCommand= worked OK. > From gero.leinemann at oracle.com Tue Jul 15 12:12:53 2014 From: gero.leinemann at oracle.com (Gero Leinemann) Date: Tue, 15 Jul 2014 14:12:53 +0200 Subject: Node child/children relation change during Runtime Message-ID: <53C51AC5.1010508@oracle.com> Hello everyone, I'm new to Graal/Truffle and currently working for Michael Haupt on FastR. While trying to understand the FastR code base I've got some questions regarding the creation and mutation of child/children of a Truffle-Node. As far as I understand it, the aim in language implementations using Truffle is to keep the AST stable to get it compiled some time by Graal. Therefore one should avoid adding new children during the lifetime of a Node, as this alters the AST. Now there is a piece of code where a Node is once added to the tree whose children's order is permuted frequently (every 'execute'). My questions are: 1) Does this count as alteration? 2) If no: Is the change of order of children during execution really irrelevant for Truffle/Graal? 3) If no: Is the only thing Truffle/Graal depends on for compilation the proper bidirectional parent <-> child relation which is established by 'Node.insert'/'replace'? Thank you in advance! Best Regards, Gero From christian.wirth at oracle.com Tue Jul 15 12:39:09 2014 From: christian.wirth at oracle.com (Christian Wirth) Date: Tue, 15 Jul 2014 14:39:09 +0200 Subject: Node child/children relation change during Runtime In-Reply-To: <53C51AC5.1010508@oracle.com> References: <53C51AC5.1010508@oracle.com> Message-ID: <53C520ED.2030109@oracle.com> Hi Gero, why do you want to change the order of nodes dynamically; what is the reasoning for doing so? We have not yet seen any use-case for that. Ad 1) It SHOULD count as alteration of the AST. Are you working with @Child or with @Children? In any case, you need to invalidate the compiled code when you do that (the API does that for you, if it has a chance to). E.g. just exchanging two pointers in an @Children array is not enough, you manually need to call CompilerDirectives.transferToInterpreterAndInvalidate(). Ad 2) and 3) it is very relevant. Again, there is a difference whether you use @Child (where you have more controll over what is executed in what order) or @Children. Truffle assumes the @Child and the @Children array to be constant. If you change it, you have to invalidate your code. You can, however, express the execute method(s) in a way that they dynamically adopt to your ordering (or control flow). A very simple example example is an "IF" node: depending on the result of conditionNode, either thenNode or elseNode is executed. Regards, Christian Wirth Am 15.07.2014 14:12, schrieb Gero Leinemann: > Hello everyone, > > I'm new to Graal/Truffle and currently working for Michael Haupt on > FastR. While trying to understand the FastR code base I've got some > questions regarding the creation and mutation of child/children of a > Truffle-Node. > > As far as I understand it, the aim in language implementations using > Truffle is to keep the AST stable to get it compiled some time by Graal. > Therefore one should avoid adding new children during the lifetime of a > Node, as this alters the AST. > > Now there is a piece of code where a Node is once added to the tree > whose children's order is permuted frequently (every 'execute'). My > questions are: > 1) Does this count as alteration? > 2) If no: Is the change of order of children during execution really > irrelevant for Truffle/Graal? > 3) If no: Is the only thing Truffle/Graal depends on for compilation the > proper bidirectional parent <-> child relation which is established by > 'Node.insert'/'replace'? > > Thank you in advance! > > Best Regards, > Gero From gero.leinemann at oracle.com Tue Jul 15 13:09:52 2014 From: gero.leinemann at oracle.com (Gero Leinemann) Date: Tue, 15 Jul 2014 15:09:52 +0200 Subject: Node child/children relation change during Runtime In-Reply-To: <53C520ED.2030109@oracle.com> References: <53C51AC5.1010508@oracle.com> <53C520ED.2030109@oracle.com> Message-ID: <53C52820.9060804@oracle.com> Hi Christian, thank you for your fast and extensive response. This is done for certain CallNodes for which the passed arguments (@Children) may change on every call. But I after reading your answer and reviewing the code I think I can avoid this. Thanks for the pointer to IfNode! Best, Gero Am 15.07.2014 14:39, schrieb Christian Wirth: > Hi Gero, > > why do you want to change the order of nodes dynamically; what is the > reasoning for doing so? We have not yet seen any use-case for that. > > Ad 1) It SHOULD count as alteration of the AST. Are you working with > @Child or with @Children? In any case, you need to invalidate the > compiled code when you do that (the API does that for you, if it has a > chance to). E.g. just exchanging two pointers in an @Children array is > not enough, you manually need to call > CompilerDirectives.transferToInterpreterAndInvalidate(). > > Ad 2) and 3) it is very relevant. Again, there is a difference whether > you use @Child (where you have more controll over what is executed in > what order) or @Children. Truffle assumes the @Child and the @Children > array to be constant. If you change it, you have to invalidate your > code. You can, however, express the execute method(s) in a way that > they dynamically adopt to your ordering (or control flow). A very > simple example example is an "IF" node: depending on the result of > conditionNode, either thenNode or elseNode is executed. > > Regards, > Christian Wirth > > > > Am 15.07.2014 14:12, schrieb Gero Leinemann: >> Hello everyone, >> >> I'm new to Graal/Truffle and currently working for Michael Haupt on >> FastR. While trying to understand the FastR code base I've got some >> questions regarding the creation and mutation of child/children of a >> Truffle-Node. >> >> As far as I understand it, the aim in language implementations using >> Truffle is to keep the AST stable to get it compiled some time by Graal. >> Therefore one should avoid adding new children during the lifetime of a >> Node, as this alters the AST. >> >> Now there is a piece of code where a Node is once added to the tree >> whose children's order is permuted frequently (every 'execute'). My >> questions are: >> 1) Does this count as alteration? >> 2) If no: Is the change of order of children during execution really >> irrelevant for Truffle/Graal? >> 3) If no: Is the only thing Truffle/Graal depends on for compilation the >> proper bidirectional parent <-> child relation which is established by >> 'Node.insert'/'replace'? >> >> Thank you in advance! >> >> Best Regards, >> Gero > From eric.caspole at amd.com Tue Jul 15 16:35:18 2014 From: eric.caspole at amd.com (Eric Caspole) Date: Tue, 15 Jul 2014 12:35:18 -0400 Subject: Webrev for edits to Okra API Message-ID: <53C55846.60109@amd.com> Hi everybody, In order to let some other projects work with our Okra HSA layer, we changed the API a bit. The new compatible Okra with simulator is already posted in the http://cr.openjdk.java.net/~tdeneau/ like the previous ones were. We bumped the version of that to 1.10. Here is the webrev to use this new API: http://cr.openjdk.java.net/~ecaspole/new_okra_july8/webrev/ Thanks, Eric From doug.simon at oracle.com Wed Jul 16 01:00:28 2014 From: doug.simon at oracle.com (doug.simon at oracle.com) Date: Wed, 16 Jul 2014 01:00:28 +0000 Subject: hg: graal/graal: 14 new changesets Message-ID: <201407160100.s6G10SqX006625@aojmv0008> Changeset: 5f458fcc4f5a Author: Josef Eisl Date: 2014-07-14 20:23 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/5f458fcc4f5a Move CFGVerifier to graal.compiler.common and make it abstract. ! graal/com.oracle.graal.compiler.common/src/com/oracle/graal/compiler/common/cfg/AbstractBlock.java + graal/com.oracle.graal.compiler.common/src/com/oracle/graal/compiler/common/cfg/CFGVerifier.java ! graal/com.oracle.graal.java/src/com/oracle/graal/java/BciBlockMapping.java - graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/cfg/CFGVerifier.java Changeset: b3800429f543 Author: Josef Eisl Date: 2014-07-14 19:55 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/b3800429f543 Move commonDominator to AbstractControlFlowGraph. ! graal/com.oracle.graal.compiler.common/src/com/oracle/graal/compiler/common/cfg/AbstractControlFlowGraph.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/cfg/ControlFlowGraph.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 Changeset: b07f96c783ad Author: Josef Eisl Date: 2014-07-14 19:27 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/b07f96c783ad Document invariants of AbstractControlFlowGraph.getBlocks(). ! graal/com.oracle.graal.compiler.common/src/com/oracle/graal/compiler/common/cfg/AbstractControlFlowGraph.java Changeset: 45f92700119f Author: Josef Eisl Date: 2014-07-14 19:32 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/45f92700119f Move AbstractBlock.{dominates, isDominatedBy} to AbstractControlFlowGraph. ! graal/com.oracle.graal.compiler.common/src/com/oracle/graal/compiler/common/cfg/AbstractBlock.java ! graal/com.oracle.graal.compiler.common/src/com/oracle/graal/compiler/common/cfg/AbstractControlFlowGraph.java ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/alloc/LinearScan.java ! graal/com.oracle.graal.phases/src/com/oracle/graal/phases/schedule/SchedulePhase.java Changeset: 505c17ed39da Author: Josef Eisl Date: 2014-07-14 19:56 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/505c17ed39da LSRA spill optimization: use AbstractControlFlowGraph.commonDominator. ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/alloc/LinearScan.java Changeset: 32f326c239a5 Author: Josef Eisl Date: 2014-07-15 10:17 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/32f326c239a5 Move setDominator() and setDominated() to AbstractBlock. ! graal/com.oracle.graal.compiler.common/src/com/oracle/graal/compiler/common/cfg/AbstractBlock.java ! graal/com.oracle.graal.compiler.common/src/com/oracle/graal/compiler/common/cfg/AbstractBlockBase.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: 79bbd0e9f1c9 Author: Josef Eisl Date: 2014-07-15 10:25 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/79bbd0e9f1c9 Move computeDominators to AbstractControlFlowGraph. ! graal/com.oracle.graal.compiler.common/src/com/oracle/graal/compiler/common/cfg/AbstractControlFlowGraph.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/cfg/ControlFlowGraph.java Changeset: 1c96b77dcc80 Author: Josef Eisl Date: 2014-07-15 11:35 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/1c96b77dcc80 BaselineControlFlowGraph compute dominators and verify. ! graal/com.oracle.graal.baseline/src/com/oracle/graal/baseline/BaselineControlFlowGraph.java Changeset: b0ea5c266655 Author: Roland Schatz Date: 2014-07-15 15:49 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/b0ea5c266655 Fix typo in comment. ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/calc/FloatAddNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/calc/FloatSubNode.java Changeset: aee02665e505 Author: Michael Van De Vanter Date: 2014-07-14 16:04 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/aee02665e505 Truffle: NodeUtil fix for displaying null SourceSections. ! graal/com.oracle.truffle.api/src/com/oracle/truffle/api/nodes/NodeUtil.java Changeset: abe7128ca473 Author: Michael Van De Vanter Date: 2014-07-14 16:51 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/abe7128ca473 SL: upgrade source attribution ! graal/com.oracle.truffle.sl/src/com/oracle/truffle/sl/SLMain.java ! graal/com.oracle.truffle.sl/src/com/oracle/truffle/sl/builtins/SLBuiltinNode.java ! graal/com.oracle.truffle.sl/src/com/oracle/truffle/sl/builtins/SLDefineFunctionBuiltin.java ! graal/com.oracle.truffle.sl/src/com/oracle/truffle/sl/builtins/SLHelloEqualsWorldBuiltin.java ! graal/com.oracle.truffle.sl/src/com/oracle/truffle/sl/builtins/SLNanoTimeBuiltin.java ! graal/com.oracle.truffle.sl/src/com/oracle/truffle/sl/builtins/SLPrintlnBuiltin.java ! graal/com.oracle.truffle.sl/src/com/oracle/truffle/sl/builtins/SLReadlnBuiltin.java ! graal/com.oracle.truffle.sl/src/com/oracle/truffle/sl/builtins/SLStackTraceBuiltin.java ! graal/com.oracle.truffle.sl/src/com/oracle/truffle/sl/nodes/SLBinaryNode.java ! graal/com.oracle.truffle.sl/src/com/oracle/truffle/sl/nodes/SLExpressionNode.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/call/SLInvokeNode.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/SLFunctionBodyNode.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 ! graal/com.oracle.truffle.sl/src/com/oracle/truffle/sl/nodes/expression/SLAddNode.java ! graal/com.oracle.truffle.sl/src/com/oracle/truffle/sl/nodes/expression/SLBigIntegerLiteralNode.java ! graal/com.oracle.truffle.sl/src/com/oracle/truffle/sl/nodes/expression/SLDivNode.java ! graal/com.oracle.truffle.sl/src/com/oracle/truffle/sl/nodes/expression/SLEqualNode.java ! graal/com.oracle.truffle.sl/src/com/oracle/truffle/sl/nodes/expression/SLFunctionLiteralNode.java ! graal/com.oracle.truffle.sl/src/com/oracle/truffle/sl/nodes/expression/SLLessOrEqualNode.java ! graal/com.oracle.truffle.sl/src/com/oracle/truffle/sl/nodes/expression/SLLessThanNode.java ! graal/com.oracle.truffle.sl/src/com/oracle/truffle/sl/nodes/expression/SLLogicalAndNode.java ! graal/com.oracle.truffle.sl/src/com/oracle/truffle/sl/nodes/expression/SLLogicalNotNode.java ! graal/com.oracle.truffle.sl/src/com/oracle/truffle/sl/nodes/expression/SLLogicalOrNode.java ! graal/com.oracle.truffle.sl/src/com/oracle/truffle/sl/nodes/expression/SLLongLiteralNode.java ! graal/com.oracle.truffle.sl/src/com/oracle/truffle/sl/nodes/expression/SLMulNode.java ! graal/com.oracle.truffle.sl/src/com/oracle/truffle/sl/nodes/expression/SLStringLiteralNode.java ! graal/com.oracle.truffle.sl/src/com/oracle/truffle/sl/nodes/expression/SLSubNode.java ! graal/com.oracle.truffle.sl/src/com/oracle/truffle/sl/nodes/expression/demo/SLAddWithoutSpecializationNode.java ! graal/com.oracle.truffle.sl/src/com/oracle/truffle/sl/nodes/local/SLReadArgumentNode.java ! graal/com.oracle.truffle.sl/src/com/oracle/truffle/sl/nodes/local/SLReadLocalVariableNode.java ! graal/com.oracle.truffle.sl/src/com/oracle/truffle/sl/nodes/local/SLWriteLocalVariableNode.java ! graal/com.oracle.truffle.sl/src/com/oracle/truffle/sl/parser/Parser.java ! graal/com.oracle.truffle.sl/src/com/oracle/truffle/sl/parser/SLNodeFactory.java ! graal/com.oracle.truffle.sl/src/com/oracle/truffle/sl/parser/Scanner.java ! graal/com.oracle.truffle.sl/src/com/oracle/truffle/sl/parser/SimpleLanguage.atg ! graal/com.oracle.truffle.sl/src/com/oracle/truffle/sl/runtime/SLContext.java Changeset: d86f948268da Author: Michael Van De Vanter Date: 2014-07-14 17:06 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/d86f948268da Merge with f0f4402a4f65bc5456feeb4d78e6b4843ec23d8c - graal/com.oracle.graal.api.meta.jdk8.test/src/com/oracle/graal/api/meta/jdk8/test/TestResolvedJavaMethodJDK8.java ! graal/com.oracle.truffle.api/src/com/oracle/truffle/api/nodes/NodeUtil.java Changeset: 247a6c2fc382 Author: Michael Van De Vanter Date: 2014-07-15 14:22 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/247a6c2fc382 SL: update tests; error locations reported differently with source attribution change. ! graal/com.oracle.truffle.sl.test/tests/String.output ! graal/com.oracle.truffle.sl.test/tests/error/TypeError01.output ! graal/com.oracle.truffle.sl.test/tests/error/TypeError03.output ! graal/com.oracle.truffle.sl.test/tests/error/TypeError04.output ! graal/com.oracle.truffle.sl/src/com/oracle/truffle/sl/SLMain.java Changeset: d6ac7470603e Author: Michael Van De Vanter Date: 2014-07-15 14:23 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/d6ac7470603e Merge with b0ea5c266655253934e403f00d69aedc1f68e052 - graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/cfg/CFGVerifier.java From bernhard.urban at jku.at Wed Jul 16 11:58:15 2014 From: bernhard.urban at jku.at (Bernhard Urban) Date: Wed, 16 Jul 2014 13:58:15 +0200 Subject: Webrev for edits to Okra API In-Reply-To: <53C55846.60109@amd.com> References: <53C55846.60109@amd.com> Message-ID: Hi Eric, thanks for your patch. There was a minor whitespace problem in the C++ part (fixed) and I also put copies of the simulator files on our mirror. Pushing now. -Bernhard On Tue, Jul 15, 2014 at 6:35 PM, Eric Caspole wrote: > Hi everybody, > In order to let some other projects work with our Okra HSA layer, we > changed the API a bit. The new compatible Okra with simulator is already > posted in the http://cr.openjdk.java.net/~tdeneau/ like the previous ones > were. We bumped the version of that to 1.10. > > Here is the webrev to use this new API: > > http://cr.openjdk.java.net/~ecaspole/new_okra_july8/webrev/ > > Thanks, > Eric > > From doug.simon at oracle.com Wed Jul 16 12:51:33 2014 From: doug.simon at oracle.com (doug.simon at oracle.com) Date: Wed, 16 Jul 2014 12:51:33 +0000 Subject: hg: graal/graal: 19 new changesets Message-ID: <201407161251.s6GCpXAn020712@aojmv0008> Changeset: 587ff693e666 Author: Stefan Anzinger Date: 2014-07-09 08:48 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/587ff693e666 [SPARC] Fixing SPARCAllocatorTest ! graal/com.oracle.graal.compiler.sparc.test/src/com/oracle/graal/compiler/sparc/test/SPARCAllocatorTest.java Changeset: cb70055faeeb Author: Stefan Anzinger Date: 2014-07-09 09:36 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/cb70055faeeb [SPARC/AMD64] Ignore AllocatorTest when the platform does not match. ! graal/com.oracle.graal.compiler.amd64.test/src/com/oracle/graal/compiler/amd64/test/AMD64AllocatorTest.java ! graal/com.oracle.graal.compiler.sparc.test/src/com/oracle/graal/compiler/sparc/test/SPARCAllocatorTest.java ! graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/GraalCompilerTest.java Changeset: 3eb13b910134 Author: Stefan Anzinger Date: 2014-07-11 18:22 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/3eb13b910134 [SPARC] Fixing LongBits tests and some implicit exceptions ! graal/com.oracle.graal.asm.sparc/src/com/oracle/graal/asm/sparc/SPARCAssembler.java ! graal/com.oracle.graal.compiler.sparc/src/com/oracle/graal/compiler/sparc/SPARCLIRGenerator.java ! graal/com.oracle.graal.lir.sparc/src/com/oracle/graal/lir/sparc/SPARCArithmetic.java ! graal/com.oracle.graal.lir.sparc/src/com/oracle/graal/lir/sparc/SPARCBitManipulationOp.java ! graal/com.oracle.graal.lir.sparc/src/com/oracle/graal/lir/sparc/SPARCByteSwapOp.java ! graal/com.oracle.graal.lir.sparc/src/com/oracle/graal/lir/sparc/SPARCCompare.java Changeset: 2b91702c4e69 Author: Stefan Anzinger Date: 2014-07-11 18:43 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/2b91702c4e69 [SPARC] Fixing IntegerBits ! graal/com.oracle.graal.compiler.sparc/src/com/oracle/graal/compiler/sparc/SPARCLIRGenerator.java ! graal/com.oracle.graal.lir.sparc/src/com/oracle/graal/lir/sparc/SPARCArithmetic.java ! graal/com.oracle.graal.lir.sparc/src/com/oracle/graal/lir/sparc/SPARCBitManipulationOp.java ! graal/com.oracle.graal.lir.sparc/src/com/oracle/graal/lir/sparc/SPARCByteSwapOp.java Changeset: 9a07bf8467a6 Author: Stefan Anzinger Date: 2014-07-13 17:46 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/9a07bf8467a6 [SPARC] Implement floatingpoint branch instructions, removing math substitutions for SPARC; fixing problems with constants in debug info (Big/Little Endian problems) ! graal/com.oracle.graal.asm.sparc/src/com/oracle/graal/asm/sparc/SPARCAssembler.java ! graal/com.oracle.graal.asm.sparc/src/com/oracle/graal/asm/sparc/SPARCMacroAssembler.java ! graal/com.oracle.graal.compiler.sparc/src/com/oracle/graal/compiler/sparc/SPARCLIRGenerator.java ! graal/com.oracle.graal.lir.sparc/src/com/oracle/graal/lir/sparc/SPARCArithmetic.java ! graal/com.oracle.graal.lir.sparc/src/com/oracle/graal/lir/sparc/SPARCControlFlow.java ! graal/com.oracle.graal.lir.sparc/src/com/oracle/graal/lir/sparc/SPARCMove.java ! graal/com.oracle.graal.replacements/src/com/oracle/graal/replacements/MathSubstitutionsX86.java ! src/share/vm/graal/graalCodeInstaller.cpp Changeset: d1b16fe368a0 Author: Stefan Anzinger Date: 2014-07-14 04:42 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/d1b16fe368a0 [SPARC] Fixing dcmp instructions (cmove jump offset) ! graal/com.oracle.graal.asm.sparc/src/com/oracle/graal/asm/sparc/SPARCAssembler.java ! graal/com.oracle.graal.lir.sparc/src/com/oracle/graal/lir/sparc/SPARCControlFlow.java Changeset: 8bba3477c88c Author: Stefan Anzinger Date: 2014-07-14 05:04 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/8bba3477c88c [SPARC] Implementing visitInfopointNode ! graal/com.oracle.graal.compiler.sparc/src/com/oracle/graal/compiler/sparc/SPARCNodeLIRBuilder.java ! graal/com.oracle.graal.hotspot.sparc/src/com/oracle/graal/hotspot/sparc/SPARCHotSpotNodeLIRBuilder.java Changeset: 2100f2ef49e6 Author: Stefan Anzinger Date: 2014-07-14 05:15 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/2100f2ef49e6 [SPARC] fix SPARCLIRGenerator.emitNot ! graal/com.oracle.graal.asm.sparc/src/com/oracle/graal/asm/sparc/SPARCMacroAssembler.java ! graal/com.oracle.graal.hotspot.sparc/src/com/oracle/graal/hotspot/sparc/SPARCHotSpotLIRGenerator.java Changeset: a08a58d0736b Author: Stefan Anzinger Date: 2014-07-15 19:07 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/a08a58d0736b [SPARC] Emit compareAndSwap for AtomicInteger and AtomicLong, Removing o7 register from usable ones, as this register is always overwritten, when using Call or JumpAndLink instructions in SPARC, even callee does not overwrite explicitly, implicit exception is defined when doing integer division, parameter constraint narrowed to only register on Unary2Op, Fix SPARCTestOp, as it did a compare instead of an and with condition codes ! graal/com.oracle.graal.compiler.sparc/src/com/oracle/graal/compiler/sparc/SPARCLIRGenerator.java ! graal/com.oracle.graal.hotspot.sparc/src/com/oracle/graal/hotspot/sparc/SPARCHotSpotLIRGenerator.java ! graal/com.oracle.graal.hotspot.sparc/src/com/oracle/graal/hotspot/sparc/SPARCHotSpotRegisterConfig.java ! graal/com.oracle.graal.lir.sparc/src/com/oracle/graal/lir/sparc/SPARCArithmetic.java ! graal/com.oracle.graal.lir.sparc/src/com/oracle/graal/lir/sparc/SPARCTestOp.java Changeset: 072b9501f5f9 Author: Stefan Anzinger Date: 2014-07-15 19:15 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/072b9501f5f9 [SPARC] Avoiding ArraysSubstitutions and StringSubstitutions for SPARC for now, will be introduced later. ! graal/com.oracle.graal.replacements/src/com/oracle/graal/replacements/ArraysSubstitutions.java ! graal/com.oracle.graal.replacements/src/com/oracle/graal/replacements/StringSubstitutions.java Changeset: 446750355e5f Author: Stefan Anzinger Date: 2014-07-15 19:21 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/446750355e5f Merge - graal/com.oracle.graal.api.meta.jdk8.test/src/com/oracle/graal/api/meta/jdk8/test/TestResolvedJavaMethodJDK8.java ! graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/GraalCompilerTest.java - graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/MemoryProxyNode.java - graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/cfg/CFGVerifier.java Changeset: 22ae26714321 Author: Stefan Anzinger Date: 2014-07-15 19:42 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/22ae26714321 [SPARC] Fix warnings thrown by compiler ! graal/com.oracle.graal.hotspot.sparc/src/com/oracle/graal/hotspot/sparc/SPARCHotSpotLIRGenerator.java ! graal/com.oracle.graal.lir.sparc/src/com/oracle/graal/lir/sparc/SPARCMove.java ! graal/com.oracle.graal.lir.sparc/src/com/oracle/graal/lir/sparc/SPARCTestOp.java Changeset: 98686250ed46 Author: Stefan Anzinger Date: 2014-07-15 20:11 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/98686250ed46 [SPARC] Fixing structure of fpops to avoid javac/findbugs complaints ! graal/com.oracle.graal.asm.sparc/src/com/oracle/graal/asm/sparc/SPARCAssembler.java ! graal/com.oracle.graal.lir.sparc/src/com/oracle/graal/lir/sparc/SPARCArithmetic.java ! graal/com.oracle.graal.lir.sparc/src/com/oracle/graal/lir/sparc/SPARCMove.java Changeset: f6ac86d3334e Author: Christian Wimmer Date: 2014-07-15 16:34 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/f6ac86d3334e Change API for stack walking to a visitor: TruffleRuntime#iterateFrames replaces TruffleRuntime#getStackTrace ! CHANGELOG.md ! graal/com.oracle.graal.api.code/src/com/oracle/graal/api/code/stack/InspectedFrame.java + graal/com.oracle.graal.api.code/src/com/oracle/graal/api/code/stack/InspectedFrameVisitor.java ! graal/com.oracle.graal.api.code/src/com/oracle/graal/api/code/stack/StackIntrospection.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/HotSpotGraalRuntime.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/HotSpotStackFrameReference.java ! graal/com.oracle.graal.truffle.hotspot/src/com/oracle/graal/truffle/hotspot/HotSpotTruffleRuntime.java ! graal/com.oracle.truffle.api/src/com/oracle/truffle/api/TruffleRuntime.java + graal/com.oracle.truffle.api/src/com/oracle/truffle/api/frame/FrameInstanceVisitor.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/SLHelloEqualsWorldBuiltin.java ! graal/com.oracle.truffle.sl/src/com/oracle/truffle/sl/builtins/SLStackTraceBuiltin.java ! mx/projects Changeset: 6694631668a6 Author: Christian Wimmer Date: 2014-07-15 16:44 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/6694631668a6 Avoid infinite recursion of deep equals checks, but also satisfy the automatic checking that does not allow == on values ! graal/com.oracle.graal.api.code/src/com/oracle/graal/api/code/VirtualObject.java Changeset: fb1c21844758 Author: Christian Wimmer Date: 2014-07-15 16:45 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/fb1c21844758 Merge ! graal/com.oracle.truffle.sl/src/com/oracle/truffle/sl/builtins/SLHelloEqualsWorldBuiltin.java ! graal/com.oracle.truffle.sl/src/com/oracle/truffle/sl/builtins/SLStackTraceBuiltin.java Changeset: 2dd966b157e8 Author: Christian Wimmer Date: 2014-07-15 21:26 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/2dd966b157e8 Merge Changeset: d5c4bb0039d8 Author: Bernhard Urban Date: 2014-07-16 11:32 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/d5c4bb0039d8 HSAIL: update simulator Contributed-by: Eric Caspole ! mx/projects ! src/gpu/hsail/vm/gpu_hsail.cpp ! src/gpu/hsail/vm/gpu_hsail.hpp ! src/gpu/hsail/vm/hsailKernelArguments.hpp Changeset: 4aaa97f42b92 Author: Bernhard Urban Date: 2014-07-15 11:52 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/4aaa97f42b92 mx: be less strict while parsing the jvm version ! mxtool/mx.py From java at stefan-marr.de Wed Jul 16 17:23:48 2014 From: java at stefan-marr.de (Stefan Marr) Date: Wed, 16 Jul 2014 19:23:48 +0200 Subject: Loop Peeling in Guest Language | Was: Optimization Thresholds? In-Reply-To: References: Message-ID: Dear all: Trying to make sense of why the loop peeling worked, I didn?t find much. On the contrary, it got even more confusing. The benchmarks in question, did not even split the call targets for the two DirectCallNodes. Because the loop has so many iterations, that compilation triggered before the first iteration was split of. Taking that into account, I experiment with peeling the loop only on Java level, and it turns out that helps my benchmark as much as the full Truffle splitting helped. What I mean by that is that I changed from the following implementation of a simple Smalltalk for loop: ``` try { for (long i = receiver; i <= limit; i++) { valueSend.call(frame, new Object[] {block, i}); } } finally { if (CompilerDirectives.inInterpreter() && (limit - receiver) > 0) { reportLoopCount(limit - receiver); } } return receiver; ``` To this version first, doing Truffle level peeling: ``` try { if (receiver <= limit) { firstValueSend.call(frame, new Object[] {block, receiver}); // extra DirectCallNode for (long i = receiver; i <= limit; i++) { valueSend.call(frame, new Object[] {block, i}); } } } // ... ``` But since the call target was usually not split, I also tried this: ``` if (receiver <= limit) { valueSend.call(frame, new Object[] {block, receiver}); // same DCN for (long i = receiver; i <= limit; i++) { valueSend.call(frame, new Object[] {block, i}); } } ``` This still fixes my benchmark. However, it also has the side effect of increasing the warmup time of benchmarks. Any ideas of what that could be? I presume its something in Graal?s optimizer. Thanks Stefan On 14 Jul 2014, at 14:35, Stefan Marr wrote: > Hi: > > Turns out, my issue from a month ago wasn?t actually related to the reflective aspects at all and the specializations I put in place to optimize them worked perfectly. > > Instead, the problem turned out to be one that can be solved with loop peeling. > > It seems, for some reason that is not entirely clear to me, the first iteration of the loop is different and that seems to be somehow related to reading an object field. > Either way, the micro benchmark benefits from an explicitly peeled first loop iteration implemented in the specialization node. That means, I use two DirectCallNodes for the loop body, one for the first iteration, and the second one for the other iterations [1]. > > Unfortunately, this form of loop peeling is not generally a win. > Kalibera et al report that it is useful in R for loops [2]. > However, on my benchmark collection, I see that it reduces performance on average. > > So, I was wondering what your experience with loop peeling on the level of the guest language is. > Are there perhaps some heuristics that would help to decide whether to use it or not? > > Thanks > Stefan > > > [1] https://github.com/SOM-st/TruffleSOM/blob/master/src/som/interpreter/nodes/specialized/IntToDoMessageNode.java#L58 > [2] http://dl.acm.org/citation.cfm?doid=2576195.2576205 > > > On 09 Jun 2014, at 22:06, Stefan Marr wrote: > >> Hi: >> >> I am running into a strange issue when optimizing some reflective operations. >> Don?t think it is related to the operations themselves, but rather the way the optimizations/Graal works. >> >> If benchmarked separately, I see, as desired, the same performance results for direct and reflective operations. >> So, I assume that my specializations are sufficient to please the optimizer. >> Concretely, that is reflective method invocation via Smalltalk?s #perform: as well as intercepting undefined methods with #doesNotUnderstand:. >> >> However, if both reflective mechanisms are used in combination to implement something like dynamic proxies, runtime nearly doubles compared to what I would expect. >> >> I have been experimenting with the various thresholds in TruffleCompilerOptions, but without any luck. >> Since the benchmarks are still microbenchmarks, I don?t think I am really hitting any of those anyway. >> The fully inlined tree has something like 220 nodes. That?s the number I see in the error output after setting TruffleGraphMaxNodes to a very small number. And, that?s just about 20 more than what I get reported for the non-reflective, i.e., direct benchmark. >> >> What would be a good approach to figure out what?s going wrong here? >> >> Thanks >> Stefan >> >> To reporduce: >> >> git clone --recursive https://github.com/SOM-st/TruffleSOM.git >> ant jar >> ant test >> ./graal.sh -cp Smalltalk:Examples/Benchmarks/DoesNotUnderstand Examples/Benchmarks/BenchmarkHarness.som DirectAdd 20 0 1000 >> ./graal.sh -cp Smalltalk:Examples/Benchmarks/DoesNotUnderstand Examples/Benchmarks/BenchmarkHarness.som ProxyAdd 20 0 1000 >> >> -- >> Stefan Marr >> INRIA Lille - Nord Europe >> http://stefan-marr.de/research/ >> >> >> > > -- > Stefan Marr > INRIA Lille - Nord Europe > http://stefan-marr.de/research/ > > > -- Stefan Marr INRIA Lille - Nord Europe http://stefan-marr.de/research/ From tom.rodriguez at oracle.com Wed Jul 16 18:18:23 2014 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Wed, 16 Jul 2014 11:18:23 -0700 Subject: mx does not like .hotspot_compiler In-Reply-To: <53C457DA.5090709@amd.com> References: <53C43CE2.5090305@amd.com> <53C457DA.5090709@amd.com> Message-ID: <88C8B8CC-F563-40C6-AF23-1D022019718D@oracle.com> I think https://bugs.openjdk.java.net/browse/JDK-8029446 is the bug id it was fixed under. Oddly I just hit it this morning while looking at something else. I?ll see about getting it back ported. tom On Jul 14, 2014, at 3:21 PM, Eric Caspole wrote: > Thanks Tom, using the command line versions is OK for us. > > Here is the actual assert we hit while compiling Graal parts in -server mode with debug builds. This doesn't happen every time but I can usually get it to happen at least once in about 10 minutes of running our tests in a loop. > > Looks like: https://bugs.openjdk.java.net/browse/JDK-8030654 > I vote for fixing this in debug builds. > Thanks, > Eric > > > > # > # A fatal error has been detected by the Java Runtime Environment: > # > # Internal Error (/home/ecaspole/views/graal-openjdk/graal/src/share/vm/opto/chaitin.cpp:282), pid=16931, tid=140031381886720 > # assert(_cfg.get_block_for_node(proj) == borig) failed: incorrect block for kill projections > # > # JRE version: OpenJDK Runtime Environment (8.0) (build 1.8.0-internal-ecaspole_2014_07_10_12_42-b00) > # Java VM: OpenJDK 64-Bit Server VM (25.0-b63-internal-graal-0.3-debug mixed mode linux-amd64 compressed oops) > # Core dump written. Default location: /home/ecaspole/views/graal-openjdk/graal/core or core.16931 > # > # If you would like to submit a bug report, please visit: > # http://bugreport.sun.com/bugreport/crash.jsp > # > > --------------- T H R E A D --------------- > > Current thread (0x00007f5bb01a2000): JavaThread "C2 CompilerThread0" daemon [_thread_in_native, id=16941, stack(0x00007f5b98b65000,0x00007f5b98c66000)] > > Stack: [0x00007f5b98b65000,0x00007f5b98c66000], sp=0x00007f5b98c60440, free space=1005k > Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) > V [libjvm.so+0xc7a096] VMError::report(outputStream*)+0x1112 > V [libjvm.so+0xc7b583] VMError::report_and_die()+0x427 > V [libjvm.so+0x611781] report_vm_error(char const*, int, char const*, char const*)+0xa5 > V [libjvm.so+0x4fb4af] PhaseChaitin::clone_projs(Block*, unsigned int, Node*, Node*, unsigned int&)+0x145 > V [libjvm.so+0xb53c2e] PhaseChaitin::split_Rematerialize(Node*, Block*, unsigned int, unsigned int&, GrowableArray, int, unsigned int*, Node**, bool)+0 > x4f6 > V [libjvm.so+0xb57873] PhaseChaitin::Split(unsigned int, ResourceArea*)+0x398f > V [libjvm.so+0x4fbc07] PhaseChaitin::Register_Allocate()+0x557 > V [libjvm.so+0x5a0b4e] Compile::Code_Gen()+0x284 > V [libjvm.so+0x59aaa8] Compile::Compile(ciEnv*, C2Compiler*, ciMethod*, int, bool, bool, bool)+0x1348 > V [libjvm.so+0x4d651b] C2Compiler::compile_method(ciEnv*, ciMethod*, int)+0x109 > V [libjvm.so+0x5b103d] CompileBroker::invoke_compiler_on_method(CompileTask*)+0x4d1 > V [libjvm.so+0x5b042b] CompileBroker::compiler_thread_loop()+0x3b3 > V [libjvm.so+0xc24316] compiler_thread_entry(JavaThread*, Thread*)+0x57 > V [libjvm.so+0xc1f68e] JavaThread::thread_main_inner()+0x124 > V [libjvm.so+0xc1f55b] JavaThread::run()+0x163 > V [libjvm.so+0xabda91] java_start(Thread*)+0x1bb > > > Current CompileTask: > C2: 296437 23955 4 com.oracle.graal.phases.common.CanonicalizerPhase$Instance::performReplacement (552 bytes) > > > > On 07/14/2014 05:08 PM, Tom Rodriguez wrote: >> hotspot_compiler as an automatically read file is deprecated in the product since it?s a potential security hole. If .hotspot_compiler exists it will emit a warning about the new behavior which screws up tools that parse VM output like mx. You can use -XX:CompileCommandFile= instead, just don?t use the .hotspot_compiler name. >> >> tom >> >> On Jul 14, 2014, at 1:26 PM, Eric Caspole wrote: >> >>> We are usually running Graal with -server so only the HSAIL part is built with Graal. We were hitting an assert in C2 code and eventually I tried using a .hotspot_compiler file, but it makes mx fail, for example: >>> >>> >>> $ cat .hotspot_compiler >>> exclude java/lang/String indexOf >>> >>> >>> $ ./mx.sh --vm server --vmbuild fastdebug unittest -server -ea -esa -XX:-TraceGPUInteraction -Dcom.amd.sumatra.offload.immediate=true hsail.test.lambda >>> Traceback (most recent call last): >>> File "/home/ecaspole/views/graal-default/graal/mxtool/mx.py", line 4912, in >>> main() >>> File "/home/ecaspole/views/graal-default/graal/mxtool/mx.py", line 4849, in main >>> defaultJdk = JavaConfig(opts.java_home, opts.java_dbg_port) >>> File "/home/ecaspole/views/graal-default/graal/mxtool/mx.py", line 1740, in __init__ >>> assert output[1] == 'version' >>> AssertionError >>> >>> >>> Even a completely empty .hotspot_compiler file causes it to fail. >>> Eventually I found -XX:CompileCommand= worked OK. >> From tom.rodriguez at oracle.com Wed Jul 16 18:18:33 2014 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Wed, 16 Jul 2014 11:18:33 -0700 Subject: Loop Peeling in Guest Language | Was: Optimization Thresholds? In-Reply-To: References: Message-ID: Basically I?d guess some test is becoming loop invariant that we aren?t otherwise able to make invariant. Or maybe some type information becomes more precise. Peeling can have several benefits when dealing with loops. It can take a test inside the loop and create a copy outside the loop that may eliminates the test in the loop. It can also have effects similar to loop inversion in that you now have a block which is entered if and only if you are entering the loop itself which is handy for several reasons. Loop inversion is something we will be adding in the next month of so. tom On Jul 16, 2014, at 10:23 AM, Stefan Marr wrote: > Dear all: > > Trying to make sense of why the loop peeling worked, I didn?t find much. > On the contrary, it got even more confusing. > The benchmarks in question, did not even split the call targets for the two DirectCallNodes. Because the loop has so many iterations, that compilation triggered before the first iteration was split of. > > Taking that into account, I experiment with peeling the loop only on Java level, and it turns out that helps my benchmark as much as the full Truffle splitting helped. > What I mean by that is that I changed from the following implementation of a simple Smalltalk for loop: > > ``` > try { > for (long i = receiver; i <= limit; i++) { > valueSend.call(frame, new Object[] {block, i}); > } > } finally { > if (CompilerDirectives.inInterpreter() && (limit - receiver) > 0) { > reportLoopCount(limit - receiver); > } > } > return receiver; > ``` > > To this version first, doing Truffle level peeling: > > ``` > try { > if (receiver <= limit) { > firstValueSend.call(frame, new Object[] {block, receiver}); // extra DirectCallNode > > for (long i = receiver; i <= limit; i++) { > valueSend.call(frame, new Object[] {block, i}); > } > } > } // ... > ``` > > But since the call target was usually not split, I also tried this: > > ``` > if (receiver <= limit) { > valueSend.call(frame, new Object[] {block, receiver}); // same DCN > > for (long i = receiver; i <= limit; i++) { > valueSend.call(frame, new Object[] {block, i}); > } > } > ``` > > This still fixes my benchmark. However, it also has the side effect of increasing the warmup time of benchmarks. > > Any ideas of what that could be? I presume its something in Graal?s optimizer. > > Thanks > Stefan > > > On 14 Jul 2014, at 14:35, Stefan Marr wrote: > >> Hi: >> >> Turns out, my issue from a month ago wasn?t actually related to the reflective aspects at all and the specializations I put in place to optimize them worked perfectly. >> >> Instead, the problem turned out to be one that can be solved with loop peeling. >> >> It seems, for some reason that is not entirely clear to me, the first iteration of the loop is different and that seems to be somehow related to reading an object field. >> Either way, the micro benchmark benefits from an explicitly peeled first loop iteration implemented in the specialization node. That means, I use two DirectCallNodes for the loop body, one for the first iteration, and the second one for the other iterations [1]. >> >> Unfortunately, this form of loop peeling is not generally a win. >> Kalibera et al report that it is useful in R for loops [2]. >> However, on my benchmark collection, I see that it reduces performance on average. >> >> So, I was wondering what your experience with loop peeling on the level of the guest language is. >> Are there perhaps some heuristics that would help to decide whether to use it or not? >> >> Thanks >> Stefan >> >> >> [1] https://github.com/SOM-st/TruffleSOM/blob/master/src/som/interpreter/nodes/specialized/IntToDoMessageNode.java#L58 >> [2] http://dl.acm.org/citation.cfm?doid=2576195.2576205 >> >> >> On 09 Jun 2014, at 22:06, Stefan Marr wrote: >> >>> Hi: >>> >>> I am running into a strange issue when optimizing some reflective operations. >>> Don?t think it is related to the operations themselves, but rather the way the optimizations/Graal works. >>> >>> If benchmarked separately, I see, as desired, the same performance results for direct and reflective operations. >>> So, I assume that my specializations are sufficient to please the optimizer. >>> Concretely, that is reflective method invocation via Smalltalk?s #perform: as well as intercepting undefined methods with #doesNotUnderstand:. >>> >>> However, if both reflective mechanisms are used in combination to implement something like dynamic proxies, runtime nearly doubles compared to what I would expect. >>> >>> I have been experimenting with the various thresholds in TruffleCompilerOptions, but without any luck. >>> Since the benchmarks are still microbenchmarks, I don?t think I am really hitting any of those anyway. >>> The fully inlined tree has something like 220 nodes. That?s the number I see in the error output after setting TruffleGraphMaxNodes to a very small number. And, that?s just about 20 more than what I get reported for the non-reflective, i.e., direct benchmark. >>> >>> What would be a good approach to figure out what?s going wrong here? >>> >>> Thanks >>> Stefan >>> >>> To reporduce: >>> >>> git clone --recursive https://github.com/SOM-st/TruffleSOM.git >>> ant jar >>> ant test >>> ./graal.sh -cp Smalltalk:Examples/Benchmarks/DoesNotUnderstand Examples/Benchmarks/BenchmarkHarness.som DirectAdd 20 0 1000 >>> ./graal.sh -cp Smalltalk:Examples/Benchmarks/DoesNotUnderstand Examples/Benchmarks/BenchmarkHarness.som ProxyAdd 20 0 1000 >>> >>> -- >>> Stefan Marr >>> INRIA Lille - Nord Europe >>> http://stefan-marr.de/research/ >>> >>> >>> >> >> -- >> 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 Wed Jul 16 19:26:16 2014 From: duboscq at ssw.jku.at (Gilles Duboscq) Date: Wed, 16 Jul 2014 21:26:16 +0200 Subject: mx does not like .hotspot_compiler In-Reply-To: <88C8B8CC-F563-40C6-AF23-1D022019718D@oracle.com> References: <53C43CE2.5090305@amd.com> <53C457DA.5090709@amd.com> <88C8B8CC-F563-40C6-AF23-1D022019718D@oracle.com> Message-ID: I think Bernhard pushed a fix for mx anyway. -Gilles On 16 Jul 2014 20:19, "Tom Rodriguez" wrote: > I think https://bugs.openjdk.java.net/browse/JDK-8029446 is the bug id it > was fixed under. Oddly I just hit it this morning while looking at > something else. I?ll see about getting it back ported. > > tom > > On Jul 14, 2014, at 3:21 PM, Eric Caspole wrote: > > > Thanks Tom, using the command line versions is OK for us. > > > > Here is the actual assert we hit while compiling Graal parts in -server > mode with debug builds. This doesn't happen every time but I can usually > get it to happen at least once in about 10 minutes of running our tests in > a loop. > > > > Looks like: https://bugs.openjdk.java.net/browse/JDK-8030654 > > I vote for fixing this in debug builds. > > Thanks, > > Eric > > > > > > > > # > > # A fatal error has been detected by the Java Runtime Environment: > > # > > # Internal Error > (/home/ecaspole/views/graal-openjdk/graal/src/share/vm/opto/chaitin.cpp:282), > pid=16931, tid=140031381886720 > > # assert(_cfg.get_block_for_node(proj) == borig) failed: incorrect > block for kill projections > > # > > # JRE version: OpenJDK Runtime Environment (8.0) (build > 1.8.0-internal-ecaspole_2014_07_10_12_42-b00) > > # Java VM: OpenJDK 64-Bit Server VM (25.0-b63-internal-graal-0.3-debug > mixed mode linux-amd64 compressed oops) > > # Core dump written. Default location: > /home/ecaspole/views/graal-openjdk/graal/core or core.16931 > > # > > # If you would like to submit a bug report, please visit: > > # http://bugreport.sun.com/bugreport/crash.jsp > > # > > > > --------------- T H R E A D --------------- > > > > Current thread (0x00007f5bb01a2000): JavaThread "C2 CompilerThread0" > daemon [_thread_in_native, id=16941, > stack(0x00007f5b98b65000,0x00007f5b98c66000)] > > > > Stack: [0x00007f5b98b65000,0x00007f5b98c66000], sp=0x00007f5b98c60440, > free space=1005k > > Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, > C=native code) > > V [libjvm.so+0xc7a096] VMError::report(outputStream*)+0x1112 > > V [libjvm.so+0xc7b583] VMError::report_and_die()+0x427 > > V [libjvm.so+0x611781] report_vm_error(char const*, int, char const*, > char const*)+0xa5 > > V [libjvm.so+0x4fb4af] PhaseChaitin::clone_projs(Block*, unsigned int, > Node*, Node*, unsigned int&)+0x145 > > V [libjvm.so+0xb53c2e] PhaseChaitin::split_Rematerialize(Node*, > Block*, unsigned int, unsigned int&, GrowableArray, int, > unsigned int*, Node**, bool)+0 > > x4f6 > > V [libjvm.so+0xb57873] PhaseChaitin::Split(unsigned int, > ResourceArea*)+0x398f > > V [libjvm.so+0x4fbc07] PhaseChaitin::Register_Allocate()+0x557 > > V [libjvm.so+0x5a0b4e] Compile::Code_Gen()+0x284 > > V [libjvm.so+0x59aaa8] Compile::Compile(ciEnv*, C2Compiler*, > ciMethod*, int, bool, bool, bool)+0x1348 > > V [libjvm.so+0x4d651b] C2Compiler::compile_method(ciEnv*, ciMethod*, > int)+0x109 > > V [libjvm.so+0x5b103d] > CompileBroker::invoke_compiler_on_method(CompileTask*)+0x4d1 > > V [libjvm.so+0x5b042b] CompileBroker::compiler_thread_loop()+0x3b3 > > V [libjvm.so+0xc24316] compiler_thread_entry(JavaThread*, Thread*)+0x57 > > V [libjvm.so+0xc1f68e] JavaThread::thread_main_inner()+0x124 > > V [libjvm.so+0xc1f55b] JavaThread::run()+0x163 > > V [libjvm.so+0xabda91] java_start(Thread*)+0x1bb > > > > > > Current CompileTask: > > C2: 296437 23955 4 > com.oracle.graal.phases.common.CanonicalizerPhase$Instance::performReplacement > (552 bytes) > > > > > > > > On 07/14/2014 05:08 PM, Tom Rodriguez wrote: > >> hotspot_compiler as an automatically read file is deprecated in the > product since it?s a potential security hole. If .hotspot_compiler exists > it will emit a warning about the new behavior which screws up tools that > parse VM output like mx. You can use -XX:CompileCommandFile= instead, just > don?t use the .hotspot_compiler name. > >> > >> tom > >> > >> On Jul 14, 2014, at 1:26 PM, Eric Caspole wrote: > >> > >>> We are usually running Graal with -server so only the HSAIL part is > built with Graal. We were hitting an assert in C2 code and eventually I > tried using a .hotspot_compiler file, but it makes mx fail, for example: > >>> > >>> > >>> $ cat .hotspot_compiler > >>> exclude java/lang/String indexOf > >>> > >>> > >>> $ ./mx.sh --vm server --vmbuild fastdebug unittest -server -ea -esa > -XX:-TraceGPUInteraction -Dcom.amd.sumatra.offload.immediate=true > hsail.test.lambda > >>> Traceback (most recent call last): > >>> File "/home/ecaspole/views/graal-default/graal/mxtool/mx.py", line > 4912, in > >>> main() > >>> File "/home/ecaspole/views/graal-default/graal/mxtool/mx.py", line > 4849, in main > >>> defaultJdk = JavaConfig(opts.java_home, opts.java_dbg_port) > >>> File "/home/ecaspole/views/graal-default/graal/mxtool/mx.py", line > 1740, in __init__ > >>> assert output[1] == 'version' > >>> AssertionError > >>> > >>> > >>> Even a completely empty .hotspot_compiler file causes it to fail. > >>> Eventually I found -XX:CompileCommand= worked OK. > >> > > From eric.caspole at amd.com Wed Jul 16 21:14:59 2014 From: eric.caspole at amd.com (Eric Caspole) Date: Wed, 16 Jul 2014 17:14:59 -0400 Subject: mx version check question with openjdk build JDK Message-ID: <53C6EB53.6090008@amd.com> After meging up, "mx clean" does not work with my Sumatra JDK. It works OK if JAVA_HOME is JAVA_HOME=/opt/jdk1.8.0_05 In my mx/env it is: JAVA_HOME=/home/ecaspole/views/sumatra-dev/build/linux-x86_64-normal-server-fastdebug/images/j2sdk-image/ $ ./mx.sh clean Traceback (most recent call last): File "/home/ecaspole/views/graal-default/graal/mxtool/mx.py", line 4921, in main() File "/home/ecaspole/views/graal-default/graal/mxtool/mx.py", line 4858, in main defaultJdk = JavaConfig(opts.java_home, opts.java_dbg_port) File "/home/ecaspole/views/graal-default/graal/mxtool/mx.py", line 1750, in __init__ self.version = VersionSpec(version.split()[2].strip('"')) AttributeError: 'NoneType' object has no attribute 'split' So -version is different in my build compared to a release: $ /home/ecaspole/views/sumatra-dev/build/linux-x86_64-normal-server-fastdebug/images/j2sdk-image/bin/java -version openjdk version "1.8.0-internal-fastdebug" OpenJDK Runtime Environment (build 1.8.0-internal-fastdebug-ecaspole_2014_06_04_10_32-b00) OpenJDK 64-Bit Server VM (build 25.0-b70-fastdebug, mixed mode) $ /opt/jdk1.8.0_05/bin/java -version java version "1.8.0_05" Java(TM) SE Runtime Environment (build 1.8.0_05-b13) Java HotSpot(TM) 64-Bit Server VM (build 25.5-b02, mixed mode) I am not sure that is the exact problem here. Is it "java version" vs "openjdk version" ? Thanks, Eric From bernhard.urban at jku.at Wed Jul 16 21:44:30 2014 From: bernhard.urban at jku.at (Bernhard Urban) Date: Wed, 16 Jul 2014 23:44:30 +0200 Subject: mx version check question with openjdk build JDK In-Reply-To: <53C6EB53.6090008@amd.com> References: <53C6EB53.6090008@amd.com> Message-ID: Sorry, I introduced this regression while I fixed the problem around the .hotspot_compiler file. Pushing a fix now, you can find the patch here in the meanwhile: http://lafo.ssw.uni-linz.ac.at/lewurm/mx-java-version-fix.patch Thanks, -Bernhard On Wed, Jul 16, 2014 at 11:14 PM, Eric Caspole wrote: > After meging up, "mx clean" does not work with my Sumatra JDK. It works OK > if JAVA_HOME is JAVA_HOME=/opt/jdk1.8.0_05 > > In my mx/env it is: > JAVA_HOME=/home/ecaspole/views/sumatra-dev/build/linux- > x86_64-normal-server-fastdebug/images/j2sdk-image/ > > > $ ./mx.sh clean > Traceback (most recent call last): > File "/home/ecaspole/views/graal-default/graal/mxtool/mx.py", line > 4921, in > main() > File "/home/ecaspole/views/graal-default/graal/mxtool/mx.py", line > 4858, in main > defaultJdk = JavaConfig(opts.java_home, opts.java_dbg_port) > File "/home/ecaspole/views/graal-default/graal/mxtool/mx.py", line > 1750, in __init__ > self.version = VersionSpec(version.split()[2].strip('"')) > AttributeError: 'NoneType' object has no attribute 'split' > > > So -version is different in my build compared to a release: > > $ /home/ecaspole/views/sumatra-dev/build/linux-x86_64-normal- > server-fastdebug/images/j2sdk-image/bin/java -version > openjdk version "1.8.0-internal-fastdebug" > OpenJDK Runtime Environment (build 1.8.0-internal-fastdebug- > ecaspole_2014_06_04_10_32-b00) > OpenJDK 64-Bit Server VM (build 25.0-b70-fastdebug, mixed mode) > > $ /opt/jdk1.8.0_05/bin/java -version > java version "1.8.0_05" > Java(TM) SE Runtime Environment (build 1.8.0_05-b13) > Java HotSpot(TM) 64-Bit Server VM (build 25.5-b02, mixed mode) > > > I am not sure that is the exact problem here. Is it "java version" vs > "openjdk version" ? > Thanks, > Eric > > From tom.deneau at amd.com Wed Jul 16 22:55:28 2014 From: tom.deneau at amd.com (Deneau, Tom) Date: Wed, 16 Jul 2014 22:55:28 +0000 Subject: small webrev for hsail allocation stability Message-ID: I have submitted a small webrev to solve the following problem. The hsail allocation routines borrow TLABs from donor threads. The design depended on the donor threads not doing any allocation from those TLABs. The donor threads should be blocked on a CyclicBarrier. But we have seen in fairly rare cases things which looked like the donor threads were doing some allocations and interfering with the HSAIL kernel allocations. Maybe this is related to the "spurious wakeup" described in Object.wait javadocs? Anyway, this webrev zeroes out the donor thread tlabs as it copies the fields out into the TlabInfo structure used by the GPU. (this copy to TlabInfo has always been there, we just didn't zero out the donor thread tlab fields). Now if the donor thread does spuriously wakeup and needs to allocate anything it will get a new tlab or wait. If it gets a new tlab, then in the post-kernel cleanup code, we retire that tlab as we copy fields back in to the donor thread. Things were definitely more stable with this change. http://cr.openjdk.java.net/~tdeneau/graal-webrevs/webrev-hsail-donor-tlab-zero/webrev/ -- Tom From doug.simon at oracle.com Thu Jul 17 01:00:26 2014 From: doug.simon at oracle.com (doug.simon at oracle.com) Date: Thu, 17 Jul 2014 01:00:26 +0000 Subject: hg: graal/graal: 4 new changesets Message-ID: <201407170100.s6H10QSA014514@aojmv0008> Changeset: ada0a7729b6f Author: Andreas Woess Date: 2014-07-16 15:18 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/ada0a7729b6f Truffle: introduce debug option to print the stack trace when transferring to the interpreter ! graal/com.oracle.graal.api.meta/src/com/oracle/graal/api/meta/DeoptimizationReason.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/HotSpotVMConfig.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotMetaAccessProvider.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/TruffleCompilerOptions.java ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/substitutions/CompilerDirectivesSubstitutions.java ! graal/com.oracle.truffle.api/src/com/oracle/truffle/api/CompilerDirectives.java ! graal/com.oracle.truffle.api/src/com/oracle/truffle/api/TruffleRuntime.java ! graal/com.oracle.truffle.api/src/com/oracle/truffle/api/impl/DefaultTruffleRuntime.java ! src/share/vm/graal/vmStructs_graal.hpp ! src/share/vm/runtime/deoptimization.cpp ! src/share/vm/runtime/deoptimization.hpp ! src/share/vm/utilities/exceptions.hpp Changeset: 82ec79372221 Author: Roland Schatz Date: 2014-07-15 19:42 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/82ec79372221 Fix operator precedence bug. ! graal/com.oracle.graal.amd64/src/com/oracle/graal/amd64/AMD64.java Changeset: 5936fa0edb6f Author: Roland Schatz Date: 2014-07-16 15:29 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/5936fa0edb6f Fix wrong NaN handling in FloatStamp.meet. ! graal/com.oracle.graal.compiler.common/src/com/oracle/graal/compiler/common/type/FloatStamp.java Changeset: 5bf37ff211bd Author: Tom Rodriguez Date: 2014-07-16 09:41 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/5bf37ff211bd consider equivalent phi inputs when simplfiying empty ifs ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/IfNode.java From doug.simon at oracle.com Thu Jul 17 08:18:03 2014 From: doug.simon at oracle.com (doug.simon at oracle.com) Date: Thu, 17 Jul 2014 08:18:03 +0000 Subject: hg: graal/graal: mx: fix in java version parsing Message-ID: <201407170818.s6H8I4dx018123@aojmv0008> Changeset: cc30bd72a19b Author: Bernhard Urban Date: 2014-07-16 23:37 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/cc30bd72a19b mx: fix in java version parsing ! mxtool/mx.py From doug.simon at oracle.com Fri Jul 18 01:00:07 2014 From: doug.simon at oracle.com (doug.simon at oracle.com) Date: Fri, 18 Jul 2014 01:00:07 +0000 Subject: hg: graal/graal: 19 new changesets Message-ID: <201407180100.s6I107Dh024194@aojmv0008> Changeset: a18c229b9a0b Author: Christian Wirth Date: 2014-07-17 11:00 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/a18c229b9a0b HSAIL: fix performance warning (treated as error on windows!) due to jint=>bool conversion (in line 197) ! src/gpu/hsail/vm/gpu_hsail.cpp Changeset: 62773598c55d Author: Christian Wirth Date: 2014-07-17 11:05 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/62773598c55d extract method in PartialEvaluatorCanonicalizer ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/PartialEvaluatorCanonicalizer.java Changeset: 45fff0246a43 Author: Christian Wirth Date: 2014-07-17 11:13 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/45fff0246a43 extract methods in (de)serializer ! graal/com.oracle.truffle.api/src/com/oracle/truffle/api/nodes/serial/PostOrderDeserializer.java ! graal/com.oracle.truffle.api/src/com/oracle/truffle/api/nodes/serial/PostOrderSerializer.java Changeset: eb3209d37c50 Author: Christian Wirth Date: 2014-07-17 11:21 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/eb3209d37c50 extract methods in exact arithmetic nodes ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/nodes/arithmetic/IntegerAddExactNode.java ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/nodes/arithmetic/IntegerMulExactNode.java ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/nodes/arithmetic/IntegerSubExactNode.java Changeset: 1e8b758800fb Author: Christian Wirth Date: 2014-07-17 11:25 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/1e8b758800fb extract methods in TruffleCacheImpl ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/TruffleCacheImpl.java Changeset: c667378e4699 Author: Christian Wirth Date: 2014-07-17 11:40 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/c667378e4699 extract methods in PartialEvaluator ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/PartialEvaluator.java Changeset: d5e6c3793309 Author: Christian Wirth Date: 2014-07-17 11:46 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/d5e6c3793309 extract method in TruffleCompilerImpl ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/TruffleCompilerImpl.java Changeset: 36bc37806c61 Author: Christian Wirth Date: 2014-07-17 11:49 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/36bc37806c61 extract methods in DefaultASTPrinter ! graal/com.oracle.truffle.api/src/com/oracle/truffle/api/instrument/impl/DefaultASTPrinter.java Changeset: a3b0a2d61e62 Author: Christian Wirth Date: 2014-07-17 11:51 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/a3b0a2d61e62 extract method in NodeUtil ! graal/com.oracle.truffle.api/src/com/oracle/truffle/api/nodes/NodeUtil.java Changeset: 0f28c558d850 Author: Lukas Stadler Date: 2014-07-17 14:25 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/0f28c558d850 rename fieldValues to values in VirtualObjectState ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/gen/DebugInfoBuilder.java ! graal/com.oracle.graal.virtual/src/com/oracle/graal/virtual/nodes/VirtualObjectState.java Changeset: af52fd81a7a3 Author: Lukas Stadler Date: 2014-07-17 14:26 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/af52fd81a7a3 initializing constructors for GuardPhiNode and MemoryPhiNode ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/GuardPhiNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/MemoryPhiNode.java Changeset: 5cdca60d0f9f Author: Lukas Stadler Date: 2014-07-17 14:27 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/5cdca60d0f9f small refactoring of FrameState ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/nfi/NativeCallStubGraphBuilder.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/FrameState.java Changeset: f4c7b92a592f Author: Lukas Stadler Date: 2014-07-17 14:27 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/f4c7b92a592f remove ControlSplitNode.setProbability ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/ControlSplitNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/IfNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/InvokeWithExceptionNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/extended/SwitchNode.java ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/nodes/arithmetic/IntegerExactArithmeticSplitNode.java Changeset: c9d3d0964adb Author: Lukas Stadler Date: 2014-07-17 14:28 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/c9d3d0964adb proper generic types for CanonicalizerPhase.applyIncremental ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/CanonicalizerPhase.java Changeset: f3c1b2d999da Author: Lukas Stadler Date: 2014-07-17 14:29 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/f3c1b2d999da clone nodes without adding to a graph ! 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: 29c5fd119afa Author: Lukas Stadler Date: 2014-07-17 14:29 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/29c5fd119afa additional constructor (with guarding node) for WriteNode ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/extended/AbstractWriteNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/extended/WriteNode.java Changeset: a657c513e128 Author: Lukas Stadler Date: 2014-07-17 14:30 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/a657c513e128 small fix in GraphEffectList ! graal/com.oracle.graal.virtual/src/com/oracle/graal/virtual/phases/ea/GraphEffectList.java Changeset: 9d03461887a7 Author: Lukas Stadler Date: 2014-07-17 17:57 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/9d03461887a7 use Double.compare in FloatStamp ! graal/com.oracle.graal.compiler.common/src/com/oracle/graal/compiler/common/type/FloatStamp.java Changeset: f2a4042d9787 Author: Andreas Woess Date: 2014-07-18 01:26 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/f2a4042d9787 Truffle: remove useless transferToInterpreter() ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/OptimizedCallTarget.java From doug.simon at oracle.com Sat Jul 19 01:00:06 2014 From: doug.simon at oracle.com (doug.simon at oracle.com) Date: Sat, 19 Jul 2014 01:00:06 +0000 Subject: hg: graal/graal: 16 new changesets Message-ID: <201407190100.s6J106AP024759@aojmv0008> Changeset: 7d9c2a7f6ec9 Author: Lukas Stadler Date: 2014-07-18 13:08 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/7d9c2a7f6ec9 use getKind() only for primitive constants in Condition.foldCondition ! graal/com.oracle.graal.compiler.common/src/com/oracle/graal/compiler/common/calc/Condition.java Changeset: 6acf45a1e7e2 Author: Lukas Stadler Date: 2014-07-18 13:37 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/6acf45a1e7e2 disable ThreadSafetyTest ! graal/com.oracle.truffle.api.test/src/com/oracle/truffle/api/test/ThreadSafetyTest.java Changeset: ca2b422e8f50 Author: Gilles Duboscq Date: 2014-07-15 13:13 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/ca2b422e8f50 Remove unnecessary final ! graal/com.oracle.graal.loop/src/com/oracle/graal/loop/LoopFragment.java Changeset: 7792116a4c3b Author: Gilles Duboscq Date: 2014-07-15 13:12 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/7792116a4c3b Make sure loop unswitching handles guards properly ! graal/com.oracle.graal.loop/src/com/oracle/graal/loop/LoopTransformations.java Changeset: 1e63cb55f61d Author: Gilles Duboscq Date: 2014-07-14 13:55 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/1e63cb55f61d Move InvokeKind from MethodCallTargetNode to CallTargetNode ! 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.hotspot.amd64/src/com/oracle/graal/hotspot/amd64/AMD64HotSpotNodeLIRBuilder.java ! graal/com.oracle.graal.hotspot.amd64/src/com/oracle/graal/hotspot/amd64/AMD64HotspotDirectStaticCallOp.java ! graal/com.oracle.graal.hotspot.amd64/src/com/oracle/graal/hotspot/amd64/AMD64HotspotDirectVirtualCallOp.java ! graal/com.oracle.graal.hotspot.sparc/src/com/oracle/graal/hotspot/sparc/SPARCHotSpotNodeLIRBuilder.java ! graal/com.oracle.graal.hotspot.sparc/src/com/oracle/graal/hotspot/sparc/SPARCHotspotDirectStaticCallOp.java ! graal/com.oracle.graal.hotspot.sparc/src/com/oracle/graal/hotspot/sparc/SPARCHotspotDirectVirtualCallOp.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/HotSpotDirectCallTargetNode.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/MethodHandleNode.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/MonitorSnippets.java ! graal/com.oracle.graal.java/src/com/oracle/graal/java/GraphBuilderPhase.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/CallTargetNode.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/AssumptionInlineInfo.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/walker/InliningData.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/nodes/MacroNode.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 Changeset: 688f84e397a3 Author: Gilles Duboscq Date: 2014-07-14 14:00 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/688f84e397a3 Move the target method from MethodCallTargetNode and LoweredCallTargetNode to their superclass CallTargetNode ! 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.hotspot.amd64/src/com/oracle/graal/hotspot/amd64/AMD64HotSpotNodeLIRBuilder.java ! graal/com.oracle.graal.hotspot.sparc/src/com/oracle/graal/hotspot/sparc/SPARCHotSpotNodeLIRBuilder.java ! graal/com.oracle.graal.hotspot.test/src/com/oracle/graal/hotspot/test/ArrayCopyIntrinsificationTest.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/CallTargetNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/DirectCallTargetNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/IndirectCallTargetNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/LoweredCallTargetNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/java/MethodCallTargetNode.java Changeset: 2b63e51e7789 Author: Gilles Duboscq Date: 2014-07-14 14:17 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/2b63e51e7789 Move invokeKind into CallTragetNode from its subclasses ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/DefaultHotSpotLoweringProvider.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/nodes/HotSpotDirectCallTargetNode.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/nodes/HotSpotIndirectCallTargetNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/CallTargetNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/DirectCallTargetNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/IndirectCallTargetNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/LoweredCallTargetNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/java/MethodCallTargetNode.java Changeset: c82000597867 Author: Gilles Duboscq Date: 2014-07-14 14:49 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/c82000597867 Add getInvokeKind on Invoke, add hasReceiver on InvokeKind ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/CallTargetNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/Invoke.java Changeset: 164b644daa83 Author: Gilles Duboscq Date: 2014-07-14 14:49 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/164b644daa83 Minor simplification in WordTypeVerificationPhase ! 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 Changeset: 4d3008ddb5a0 Author: Gilles Duboscq Date: 2014-07-15 13:12 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/4d3008ddb5a0 Minor changes to StampFactory and ObjectStamp ! graal/com.oracle.graal.compiler.common/src/com/oracle/graal/compiler/common/type/ObjectStamp.java ! graal/com.oracle.graal.compiler.common/src/com/oracle/graal/compiler/common/type/StampFactory.java Changeset: d780f8b87d89 Author: Gilles Duboscq Date: 2014-07-15 16:50 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/d780f8b87d89 NonNullParametersPhase (and its HSAIL cousin) should join non-null rather than attempt to re-create the paramater stamp. ! graal/com.oracle.graal.hotspot.hsail/src/com/oracle/graal/hotspot/hsail/HSAILHotSpotBackend.java ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/NonNullParametersPhase.java Changeset: c54912403cb3 Author: Gilles Duboscq Date: 2014-07-15 16:54 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/c54912403cb3 Simplify ExceptionObjectNode.lower: use the node's stamp rather than re-compute it ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/java/ExceptionObjectNode.java Changeset: b9e7ce429c79 Author: Gilles Duboscq Date: 2014-07-16 14:22 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/b9e7ce429c79 BasePhase.createName: use full class name and strip package name so that the outer class is visible. ! graal/com.oracle.graal.phases/src/com/oracle/graal/phases/BasePhase.java Changeset: 7531cdfed73c Author: Gilles Duboscq Date: 2014-07-16 14:27 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/7531cdfed73c ConvertDeoptimizeToGuardPhase: the SimplifierTool can be an instance field ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/ConvertDeoptimizeToGuardPhase.java Changeset: a2ec1ac769e4 Author: Gilles Duboscq Date: 2014-07-18 11:14 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/a2ec1ac769e4 Add simple infopoint nodes which do not contain debugging informations for values. Use them when shouldDebugNonSafepoints is true. ! graal/com.oracle.graal.api.code/src/com/oracle/graal/api/code/BytecodePosition.java ! graal/com.oracle.graal.api.code/src/com/oracle/graal/api/code/CompilationResult.java ! graal/com.oracle.graal.api.code/src/com/oracle/graal/api/code/InfopointReason.java ! 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/PTXNodeLIRBuilder.java ! graal/com.oracle.graal.compiler.sparc/src/com/oracle/graal/compiler/sparc/SPARCNodeLIRBuilder.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/inlining/InliningTest.java ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/gen/NodeLIRBuilder.java ! graal/com.oracle.graal.hotspot.amd64/src/com/oracle/graal/hotspot/amd64/AMD64HotSpotNodeLIRBuilder.java ! graal/com.oracle.graal.hotspot.sparc/src/com/oracle/graal/hotspot/sparc/SPARCHotSpotNodeLIRBuilder.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/CompilationTask.java ! graal/com.oracle.graal.java/src/com/oracle/graal/java/GraphBuilderConfiguration.java ! graal/com.oracle.graal.java/src/com/oracle/graal/java/GraphBuilderPhase.java + graal/com.oracle.graal.lir/src/com/oracle/graal/lir/FullInfopointOp.java - graal/com.oracle.graal.lir/src/com/oracle/graal/lir/InfopointOp.java + graal/com.oracle.graal.lir/src/com/oracle/graal/lir/SimpleInfopointOp.java ! graal/com.oracle.graal.lir/src/com/oracle/graal/lir/asm/CompilationResultBuilder.java + graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/FullInfopointNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/InfopointNode.java + graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/SimpleInfopointNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/spi/NodeLIRBuilderTool.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/util/GraphOrder.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/TruffleCompilerImpl.java ! src/share/vm/graal/graalCodeInstaller.cpp ! src/share/vm/graal/graalCodeInstaller.hpp Changeset: 042b5e9aeb76 Author: Gilles Duboscq Date: 2014-07-18 14:28 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/042b5e9aeb76 Cherry-picking "8029446: assert(_cfg.get_block_for_node(proj) == borig) failed: incorrect block for kill projections" by adlertz ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/FullInfopointNode.java < graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/InfopointNode.java ! src/share/vm/opto/chaitin.cpp From michael.haupt at oracle.com Sun Jul 20 13:45:50 2014 From: michael.haupt at oracle.com (Michael Haupt) Date: Sun, 20 Jul 2014 15:45:50 +0200 Subject: igv startup error Message-ID: Hi, behold: ----- nancarrow:basic-graal haupt$ ./mx.sh igv Traceback (most recent call last): File "/Users/haupt/maxws/basic-graal/mxtool/mx.py", line 4921, in main() File "/Users/haupt/maxws/basic-graal/mxtool/mx.py", line 4902, in main retcode = c(command_args) File "/Users/haupt/maxws/basic-graal/mx/mx_graal.py", line 1463, in igv dom = xml.dom.minidom.parse(join(nbplatform, 'platform', 'update_tracking', 'org-netbeans-core.xml')) File "/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/xml/dom/minidom.py", line 1920, in parse return expatbuilder.parse(file) File "/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/xml/dom/expatbuilder.py", line 922, in parse fp = open(file, 'rb') IOError: [Errno 2] No such file or directory: '/Users/haupt/maxws/basic-graal/src/share/tools/IdealGraphVisualizer/nbplatform/platform/update_tracking/org-netbeans-core.xml' ----- What is this, and how can I address it? 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 michael.haupt at oracle.com Sun Jul 20 13:51:00 2014 From: michael.haupt at oracle.com (Michael Haupt) Date: Sun, 20 Jul 2014 15:51:00 +0200 Subject: igv startup error In-Reply-To: References: Message-ID: <9BA010EE-6AAD-4485-A601-39DDED5A97FC@oracle.com> Hi again, Am 20.07.2014 um 15:45 schrieb Michael Haupt : > IOError: [Errno 2] No such file or directory: '/Users/haupt/maxws/basic-graal/src/share/tools/IdealGraphVisualizer/nbplatform/platform/update_tracking/org-netbeans-core.xml' > ----- > > What is this, and how can I address it? it seems the IGV build directory was in some undefined state, so boldly deleting the nbplatform directory did the trick. 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 chris.seaton at oracle.com Sun Jul 20 14:12:50 2014 From: chris.seaton at oracle.com (Chris Seaton) Date: Sun, 20 Jul 2014 15:12:50 +0100 Subject: igv startup error In-Reply-To: References: Message-ID: <0397DF2C-1E20-4CC6-947C-E123E0A6ED67@oracle.com> I?ve seen this before. I can?t explain it as I don?t know these scripts, but I think I just did a full clean of the entire repo clean and it went away. Chris On 20 Jul 2014, at 14:45, Michael Haupt wrote: > Hi, > > behold: > > ----- > nancarrow:basic-graal haupt$ ./mx.sh igv > Traceback (most recent call last): > File "/Users/haupt/maxws/basic-graal/mxtool/mx.py", line 4921, in > main() > File "/Users/haupt/maxws/basic-graal/mxtool/mx.py", line 4902, in main > retcode = c(command_args) > File "/Users/haupt/maxws/basic-graal/mx/mx_graal.py", line 1463, in igv > dom = xml.dom.minidom.parse(join(nbplatform, 'platform', 'update_tracking', 'org-netbeans-core.xml')) > File "/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/xml/dom/minidom.py", line 1920, in parse > return expatbuilder.parse(file) > File "/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/xml/dom/expatbuilder.py", line 922, in parse > fp = open(file, 'rb') > IOError: [Errno 2] No such file or directory: '/Users/haupt/maxws/basic-graal/src/share/tools/IdealGraphVisualizer/nbplatform/platform/update_tracking/org-netbeans-core.xml' > ----- > > What is this, and how can I address it? > > 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 christian.wimmer at oracle.com Sun Jul 20 23:00:10 2014 From: christian.wimmer at oracle.com (Christian Wimmer) Date: Sun, 20 Jul 2014 16:00:10 -0700 Subject: igv startup error In-Reply-To: <9BA010EE-6AAD-4485-A601-39DDED5A97FC@oracle.com> References: <9BA010EE-6AAD-4485-A601-39DDED5A97FC@oracle.com> Message-ID: <53CC49FA.5070700@oracle.com> On 7/20/2014 6:51 AM, Michael Haupt wrote: > Hi again, > > Am 20.07.2014 um 15:45 schrieb Michael Haupt : >> IOError: [Errno 2] No such file or directory: '/Users/haupt/maxws/basic-graal/src/share/tools/IdealGraphVisualizer/nbplatform/platform/update_tracking/org-netbeans-core.xml' >> ----- >> >> What is this, and how can I address it? > > it seems the IGV build directory was in some undefined state, so boldly deleting the nbplatform directory did the trick. Yes, that's the official solution for this. When the nnplatform download does not succeed completely, the mx script can crash like that. -Christian From doug.simon at oracle.com Mon Jul 21 01:00:05 2014 From: doug.simon at oracle.com (doug.simon at oracle.com) Date: Mon, 21 Jul 2014 01:00:05 +0000 Subject: hg: graal/graal: improved name and documentation for method implementing fast-path check for type resolution Message-ID: <201407210100.s6L1052L005794@aojmv0008> Changeset: adafceb4da4a Author: Doug Simon Date: 2014-07-20 17:10 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/adafceb4da4a improved name and documentation for method implementing fast-path check for type resolution ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotResolvedObjectType.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotSignature.java From stefan.fehrenbach at gmail.com Mon Jul 21 11:19:28 2014 From: stefan.fehrenbach at gmail.com (Stefan Fehrenbach) Date: Mon, 21 Jul 2014 13:19:28 +0200 Subject: Frame escapes and inline failed, reason recursion Message-ID: Hello again, thanks to Christian Humer, I got my previous parser experiment to work. :-) I tried to apply my newly gained knowledge to "truffleize" a different parser. I have one problem, however, and one question: The problem is an escaping frame, see the error message below. If I read this correctly, it starts at gll.grammar.SymbolSlot.parse [1], which calls the push method of the gll.parser.State interface [2]. The only implementation is in gll.parser.ParsingState [3]. There, the VirtualFrame is passed on to gll.gss.Link.schedule [4], which does not use it currently, but probably should in the future. What is going wrong there, and what can I do to fix it? The FAQ says something about private/final methods, @Child fields and parent classes, but I don't really get that. [1] https://github.com/fehrenbach/gll/blob/20dbecaa111a481f59a54ed09e1e0c64e7aa435e/src/main/java/gll/grammar/SymbolSlot.java#L102 [2] https://github.com/fehrenbach/gll/blob/20dbecaa111a481f59a54ed09e1e0c64e7aa435e/src/main/java/gll/parser/State.java#L144 [3] https://github.com/fehrenbach/gll/blob/20dbecaa111a481f59a54ed09e1e0c64e7aa435e/src/main/java/gll/parser/ParsingState.java#L298 [4] https://github.com/fehrenbach/gll/blob/20dbecaa111a481f59a54ed09e1e0c64e7aa435e/src/main/java/gll/gss/Link.java#L94 My question is about this message "inline failed", where it says "reason recursion". Is that a problem? My best guess is that I have created a recursive function and truffle won't inline it into itself. In this code base, nonterminals are functions / CallTargets. In the grammar below, the left hand side S is a function, and the right hand side S is a call of that function. S ::= ? | 'a' S I think I avoided my mistakes from last time. I broke cycles in the grammar by using function calls to form a proper AST. I tried to not refer to AST nodes directly, but make the trampoline (Parser and ParsingState) use CallTargets. I have non-final @Child annotated fields. It just occurs to me, that my last frame escapes problem went away with an @ExplodeLoop annotation. Is the problem the loop in ParsingState.push [3]? How do I fix it? You use @ExplodeLoop to loop over children, right? The "results" are not part of the AST and they might not even be compilation final... I hope someone can enlighten me :) Best regards, Stefan /home/stefan/opt/graalvm-jdk1.8.0-0.3/bin/java -server -Xss64m -G:+TruffleCompilationExceptionsAreFatal -G:+TraceTruffleInlining -Dtruffle.TraceRewrites=true -Dtruffle.DetailedRewriteReasons=true -G:+TraceTruffleCompilationDetails -G:+TraceTruffleCompilation -G:TruffleCompilationThreshold=1 -XX:+UnlockDiagnosticVMOptions -XX:CompileCommand=print,*::executeHelper -Didea.launcher.port=7532 -Didea.launcher.bin.path=/usr/share/intellijidea-ce/bin -Dfile.encoding=UTF-8 -classpath /home/stefan/opt/graalvm-jdk1.8.0-0.3/lib/dt.jar:/home/stefan/opt/graalvm-jdk1.8.0-0.3/lib/tools.jar:/home/stefan/opt/graalvm-jdk1.8.0-0.3/lib/sa-jdi.jar:/home/stefan/opt/graalvm-jdk1.8.0-0.3/lib/jconsole.jar:/home/stefan/src/gll/target/scala-2.11/test-classes:/home/stefan/src/gll/target/scala-2.11/classes:/home/stefan/.ivy2/cache/asm/asm/jars/asm-3.3.1.jar:/home/stefan/.ivy2/cache/asm/asm-analysis/jars/asm-analysis-3.3.1.jar:/home/stefan/.ivy2/cache/asm/asm-commons/jars/asm-commons-3.3.1.jar:/home/stefan/.ivy2/cache/asm/asm-tree/jars/asm-tree-3.3.1.jar:/home/stefan/.ivy2/cache/asm/asm-util/jars/asm-util-3.3.1.jar:/home/stefan/.ivy2/cache/asm/asm-xml/jars/asm-xml-3.3.1.jar:/home/stefan/.ivy2/cache/com.google.caliper/caliper/jars/caliper-0.5-rc1.jar:/home/stefan/.ivy2/cache/com.google.code.findbugs/jsr305/jars/jsr305-1.3.9.jar:/home/stefan/.ivy2/cache/com.google.code.gson/gson/jars/gson-1.7.1.jar:/home/stefan/.ivy2/cache/com.google.code.java-allocation-instrumenter/java-allocation-instrumenter/jars/java-allocation-instrumenter-2.0.jar:/home/stefan/.ivy2/cache/com.google.guava/guava/jars/guava-11.0.1.jar:/home/stefan/.ivy2/cache/com.novocode/junit-interface/jars/junit-interface-0.10-M2.jar:/home/stefan/.ivy2/cache/com.oracle/truffle/jars/truffle-0.3.jar:/home/stefan/.ivy2/cache/junit/junit/jars/junit-4.8.2.jar:/home/stefan/.ivy2/cache/junit/junit-dep/jars/junit-dep-4.10.jar:/home/stefan/.ivy2/cache/org.hamcrest/hamcrest-core/jars/hamcrest-core-1.1.jar:/home/stefan/.ivy2/cache/com.github.wookietreiber/scala-chart_2.11/jars/scala-chart_2.11-0.4.2.jar:/home/stefan/.ivy2/cache/com.storm-enroute/scalameter-core_2.11/jars/scalameter-core_2.11-0.6.jar:/home/stefan/.ivy2/cache/com.storm-enroute/scalameter_2.11/jars/scalameter_2.11-0.6.jar:/home/stefan/.ivy2/cache/org.apache.commons/commons-math3/jars/commons-math3-3.2.jar:/home/stefan/.ivy2/cache/org.jfree/jcommon/jars/jcommon-1.0.21.jar:/home/stefan/.ivy2/cache/org.jfree/jfreechart/jars/jfreechart-1.0.17.jar:/home/stefan/.ivy2/cache/org.scala-lang/scala-library/jars/scala-library-2.11.1.jar:/home/stefan/.ivy2/cache/org.scala-lang/scala-reflect/jars/scala-reflect-2.11.0.jar:/home/stefan/.ivy2/cache/org.scala-lang.modules/scala-parser-combinators_2.11/jars/scala-parser-combinators_2.11-1.0.1.jar:/home/stefan/.ivy2/cache/org.scala-lang.modules/scala-swing_2.11/jars/scala-swing_2.11-1.0.1.jar:/home/stefan/.ivy2/cache/org.scala-lang.modules/scala-xml_2.11/jars/scala-xml_2.11-1.0.1.jar:/home/stefan/.ivy2/cache/org.scala-tools.testing/test-interface/jars/test-interface-0.5.jar:/home/stefan/.ivy2/cache/xml-apis/xml-apis/jars/xml-apis-1.3.04.jar:/usr/share/intellijidea-ce/lib/idea_rt.jar com.intellij.rt.execution.application.AppMain gll.parser.TestParserWithAs CompilerOracle: print *.executeHelper OpenJDK 64-Bit Server VM warning: printing of assembly code is enabled; turning on DebugNonSafepoints to gain additional output before first [truffle] rewrite S |From M SortCall |To M SortCallCached |Reason Called S for the first time at this call site [truffle] rewrite S |From M SortCall |To M SortCallCached |Reason Called S for the first time at this call site [truffle] inline start SortCallRootNode at 1e965684 |ASTSize 13 (0/0) |C/T 11/ 3 |L/T 11/ 11 |Inval#/Replace# 0/ 1 [truffle] inline failed SortCallRootNode at 1e965684 |ASTSize 13 (0/0) |nodeCount 2147483647/ 13 |frequency 0.91 |score 0.0000 |index= 0, force=N, callSites= 2 |reason recursion [truffle] inline done SortCallRootNode at 1e965684 |ASTSize 13 (0/0) |C/T 11/ 3 |L/T 11/ 11 |Inval#/Replace# 0/ 1 [truffle] opt queued SortCallRootNode at 1e965684 |ASTSize 13 (0/0) |C/T 11/ 3 |L/T 11/ 11 |Inval#/Replace# 0/ 1 [truffle] opt start SortCallRootNode at 1e965684 |ASTSize 13 (0/0) |C/T 20/ 3 |L/T 20/ 11 |Inval#/Replace# 0/ 1 after first [truffle] opt fail SortCallRootNode at 1e965684 |Reason Frame escapes at: 490|MethodCallTarget#HotSpotMethod properties:{invokeKind=Interface, targetMethod=HotSpotMethod, stamp=void, returnType=HotSpotType} arguments: [337|CheckCast, 257|NewFrame, 513|Const(SymbolSlot at 327177752), 298|CheckCast, 487|Invoke#State.getPosition, 416|Invoke#State.createEmpty, 313|Unbox] com.oracle.graal.nodes.util.GraphUtil$2: Frame escapes at: 490|MethodCallTarget#HotSpotMethod properties:{invokeKind=Interface, targetMethod=HotSpotMethod, stamp=void, returnType=HotSpotType} arguments: [337|CheckCast, 257|NewFrame, 513|Const(SymbolSlot at 327177752), 298|CheckCast, 487|Invoke#State.getPosition, 416|Invoke#State.createEmpty, 313|Unbox] at gll.parser.State.push(State.java) at gll.grammar.SymbolSlot.parse(SymbolSlot.java:103) at gll.grammar.Production.schedule(Production.java:79) at gll.grammar.SortCallRootNode.execute(SortCallRootNode.java:45) at com.oracle.graal.truffle.OptimizedCallTarget.callProxy(OptimizedCallTarget.java:186) at com.oracle.graal.truffle.OptimizedCallTarget.callRoot(OptimizedCallTarget.java:272) Caused by: com.oracle.graal.graph.VerificationError: Frame escapes at: 490|MethodCallTarget#HotSpotMethod properties:{invokeKind=Interface, targetMethod=HotSpotMethod, stamp=void, returnType=HotSpotType} arguments: [337|CheckCast, 257|NewFrame, 513|Const(SymbolSlot at 327177752), 298|CheckCast, 487|Invoke#State.getPosition, 416|Invoke#State.createEmpty, 313|Unbox] at com.oracle.graal.truffle.phases.VerifyFrameDoesNotEscapePhase.run(VerifyFrameDoesNotEscapePhase.java:45) at com.oracle.graal.phases.Phase.run(Phase.java:51) at com.oracle.graal.phases.BasePhase.apply(BasePhase.java:73) at com.oracle.graal.phases.Phase.apply(Phase.java:44) at com.oracle.graal.truffle.PartialEvaluator.createGraph(PartialEvaluator.java:122) at com.oracle.graal.truffle.TruffleCompilerImpl.compileMethodImpl(TruffleCompilerImpl.java:115) at com.oracle.graal.truffle.hotspot.HotSpotTruffleRuntime$3.run(HotSpotTruffleRuntime.java:300) at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) at java.util.concurrent.FutureTask.run(FutureTask.java:266) 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:744) at com.oracle.graal.compiler.CompilerThread.run(CompilerThread.java:48) From java at stefan-marr.de Mon Jul 21 11:36:30 2014 From: java at stefan-marr.de (Stefan Marr) Date: Mon, 21 Jul 2014 13:36:30 +0200 Subject: Frame escapes and inline failed, reason recursion In-Reply-To: References: Message-ID: <15EF1A27-998A-449F-B43A-F6F12E3A0AE2@stefan-marr.de> Hi Stefan: On 21 Jul 2014, at 13:19, Stefan Fehrenbach wrote: > My question is about this message "inline failed", where it says > "reason recursion". Is that a problem? In my experience, that becomes only relevant after you fixed the escaping frames. > I think I avoided my mistakes from last time. I broke cycles in the > grammar by using function calls to form a proper AST. I tried to not > refer to AST nodes directly, but make the trampoline (Parser and > ParsingState) use CallTargets. I have non-final @Child annotated > fields. This sounds strange to me. Are you using Truffle to implement a fast parser? Or are you implementing the interpretation of the parser?s result. The usual thing is the later. Another thing is that I haven?t seen a trampoline-based interpreter based on Truffle yet. Instead, as far as I know, they are all fully recursive and rely on Graal to make that work efficiently. > It just occurs to me, that my last frame escapes problem went away > with an @ExplodeLoop annotation. Is the problem the loop in > ParsingState.push [3]? > How do I fix it? You use @ExplodeLoop to loop over children, right? > The "results" are not part of the AST and they might not even be > compilation final? Every time I saw a new escaping frame issue it was because I introduced a loop that was not unrolled. So, my guess would be that you got your root cause right there. It is important that the loop bounds are going to be fixed at run time, so, I don?t know whether that is going to be the case here with your `results` set. It also looks like you are not strictly implementing your interpretation as part of the AST. Such loops should be in execute*() methods of Truffle nodes, and depend (in terms of number of iterations) solely on child nodes and known constant values, so that the loop unrolling triggered by @ExplodeLoop can do its magic. Hope that helps a little Stefan -- Stefan Marr INRIA Lille - Nord Europe http://stefan-marr.de/research/ From Eric.Caspole at amd.com Mon Jul 21 20:52:29 2014 From: Eric.Caspole at amd.com (Caspole, Eric) Date: Mon, 21 Jul 2014 20:52:29 +0000 Subject: Webrev for unloading kernels after class unloading Message-ID: Hi everybody, I put up a new webrev that allows GPU kernels to be unloaded when their class loader context gets unloaded, when used with the latest Sumatra JDK. http://cr.openjdk.java.net/~ecaspole/unload_kernels/01/ There was already a notion of "external nmethod" in the Graal side and in the nmethod, but they had not been connected before. Here, the kernel nmethods get the external flag set, and if the class loader context of the kernel is getting unloaded it will call to the GPU::Hsail class to unload the kernel from the HSA runtime, using the API in the latest version of Okra we added last week. There is a new test case in the webrev to create an offloadable kernel in a custom class loader and see that it gets Gc-ed and collected using jmx APIs. One shortcoming in this version I want to get comments on is how to distinguish HSAIL vs PTX nmethods so the unload code calls the correct GPU runtime to do the dispose. We don't use "make not entrant" style flagging of kernel nmethods but this change is the first step in making the kernels more proper members in the code cache. I also added the call to dispose the HSA GPU context similar to what the PTX version had for a long while now. Let me know your comments, Thanks, Eric From igor.veresov at oracle.com Mon Jul 21 22:03:34 2014 From: igor.veresov at oracle.com (Igor Veresov) Date: Mon, 21 Jul 2014 15:03:34 -0700 Subject: Webrev for unloading kernels after class unloading In-Reply-To: References: Message-ID: Hi Eric, Seems ok. Embedding the class file as a binary in the test is odd though. Shouldn?t it be possible to compile it from within the test with the javac api? igor On Jul 21, 2014, at 1:52 PM, Caspole, Eric wrote: > Hi everybody, > I put up a new webrev that allows GPU kernels to be unloaded when their class loader context gets unloaded, when used with the latest Sumatra JDK. > > http://cr.openjdk.java.net/~ecaspole/unload_kernels/01/ > > There was already a notion of "external nmethod" in the Graal side and in the nmethod, but they had not been connected before. Here, the kernel nmethods get the external flag set, and if the class loader context of the kernel is getting unloaded it will call to the GPU::Hsail class to unload the kernel from the HSA runtime, using the API in the latest version of Okra we added last week. There is a new test case in the webrev to create an offloadable kernel in a custom class loader and see that it gets Gc-ed and collected using jmx APIs. > > One shortcoming in this version I want to get comments on is how to distinguish HSAIL vs PTX nmethods so the unload code calls the correct GPU runtime to do the dispose. We don't use "make not entrant" style flagging of kernel nmethods but this change is the first step in making the kernels more proper members in the code cache. > > I also added the call to dispose the HSA GPU context similar to what the PTX version had for a long while now. > Let me know your comments, > Thanks, > Eric > From stefan.fehrenbach at gmail.com Tue Jul 22 09:13:08 2014 From: stefan.fehrenbach at gmail.com (Stefan Fehrenbach) Date: Tue, 22 Jul 2014 11:13:08 +0200 Subject: Frame escapes and inline failed, reason recursion In-Reply-To: <15EF1A27-998A-449F-B43A-F6F12E3A0AE2@stefan-marr.de> References: <15EF1A27-998A-449F-B43A-F6F12E3A0AE2@stefan-marr.de> Message-ID: Hi! On 21 July 2014 13:36, Stefan Marr wrote: > Hi Stefan: > > On 21 Jul 2014, at 13:19, Stefan Fehrenbach wrote: > >> My question is about this message "inline failed", where it says >> "reason recursion". Is that a problem? > > In my experience, that becomes only relevant after you fixed the escaping frames. > Okay. > This sounds strange to me. Are you using Truffle to implement a fast parser? Yes, indeed. A parser is basically an ahead-of-time compiled grammar. My code implements a grammar interpreter using Truffle for JIT compilation :) Preliminary results of my experiments with a very primitive recursive descent recognizer are promising. > Or are you implementing the interpretation of the parser?s result. > The usual thing is the later. > Another thing is that I haven?t seen a trampoline-based interpreter based on Truffle yet. > Instead, as far as I know, they are all fully recursive and rely on Graal to make that work efficiently. > Well, the parsing algorithm (GLL) dictates the need for a trampoline. It seems to work out so far. I guess I do a lot of indirect calls instead of partial evaluated Truffle magic, which will be slow, but I hope it will not be much slower than the existing non-Truffle code. > >> It just occurs to me, that my last frame escapes problem went away >> with an @ExplodeLoop annotation. Is the problem the loop in >> ParsingState.push [3]? >> How do I fix it? You use @ExplodeLoop to loop over children, right? >> The "results" are not part of the AST and they might not even be >> compilation final? > > Every time I saw a new escaping frame issue it was because I introduced a loop that was not unrolled. > So, my guess would be that you got your root cause right there. > > It is important that the loop bounds are going to be fixed at run time, so, I don?t know whether that is going to be the case here with your `results` set. > It also looks like you are not strictly implementing your interpretation as part of the AST. > > Such loops should be in execute*() methods of Truffle nodes, and depend (in terms of number of iterations) solely on child nodes and known constant values, so that the loop unrolling triggered by @ExplodeLoop can do its magic. > So, I "fixed" the problem by removing the VirtualFrame parameter from a couple of methods. I guess you can only have execute* methods on AST nodes, but some of my receivers were not. I suspect if I want to have Truffle magic along these paths, I'll need to do some clever grammar analysis and rewrite to specialized nodes based on the results. Might be possible, I don't know yet. Anyways, thanks for the help :) Stefan From duboscq at ssw.jku.at Tue Jul 22 11:26:02 2014 From: duboscq at ssw.jku.at (Gilles Duboscq) Date: Tue, 22 Jul 2014 13:26:02 +0200 Subject: Webrev for unloading kernels after class unloading In-Reply-To: References: Message-ID: I agree, it would be better to generate the class. If you do it with Javac, please tell me because it may require a small mx modification (providing libraries from the JDK: we already have JRE libraries but JDK is slightly diffrerent). If you prefer ASM you can declare it like this: library at ASM@path=lib/asm-5.0.3.jar library at ASM@urls=http://lafo.ssw.uni-linz.ac.at/graal-external-deps/asm-5.0.3.jar,http://central.maven.org/maven2/org/ow2/asm/asm/5.0.3/asm-5.0.3.jar library at ASM@sha1=dcc2193db20e19e1feca8b1240dbbc4e190824fa library at ASM@sourcePath=lib/asm-5.0.3-sources.jar library at ASM@sourceSha1=f0f24f6666c1a15c7e202e91610476bd4ce59368 library at ASM@sourceUrls=http://lafo.ssw.uni-linz.ac.at/graal-external-deps/asm-5.0.3-sources.jar,http://central.maven.org/maven2/org/ow2/asm/asm/5.0.3/asm-5.0.3-sources.jar Overall the change looks good but i'm not so happy with the fact that that we use the "external" flag in this way. Maybe it's just a naming problem and we should just rename it to "gpu" such that we rather have a concept of "gpu nmethods" (this renaming would anyway be for a different changeset). -Gilles On Tue, Jul 22, 2014 at 12:03 AM, Igor Veresov wrote: > Hi Eric, > > Seems ok. Embedding the class file as a binary in the test is odd though. Shouldn?t it be possible to compile it from within the test with the javac api? > > igor > > On Jul 21, 2014, at 1:52 PM, Caspole, Eric wrote: > >> Hi everybody, >> I put up a new webrev that allows GPU kernels to be unloaded when their class loader context gets unloaded, when used with the latest Sumatra JDK. >> >> http://cr.openjdk.java.net/~ecaspole/unload_kernels/01/ >> >> There was already a notion of "external nmethod" in the Graal side and in the nmethod, but they had not been connected before. Here, the kernel nmethods get the external flag set, and if the class loader context of the kernel is getting unloaded it will call to the GPU::Hsail class to unload the kernel from the HSA runtime, using the API in the latest version of Okra we added last week. There is a new test case in the webrev to create an offloadable kernel in a custom class loader and see that it gets Gc-ed and collected using jmx APIs. >> >> One shortcoming in this version I want to get comments on is how to distinguish HSAIL vs PTX nmethods so the unload code calls the correct GPU runtime to do the dispose. We don't use "make not entrant" style flagging of kernel nmethods but this change is the first step in making the kernels more proper members in the code cache. >> >> I also added the call to dispose the HSA GPU context similar to what the PTX version had for a long while now. >> Let me know your comments, >> Thanks, >> Eric >> > From chris.seaton at oracle.com Tue Jul 22 14:04:35 2014 From: chris.seaton at oracle.com (Chris Seaton) Date: Tue, 22 Jul 2014 15:04:35 +0100 Subject: Frame escapes and inline failed, reason recursion In-Reply-To: References: <15EF1A27-998A-449F-B43A-F6F12E3A0AE2@stefan-marr.de> Message-ID: Hi Stefan, I too tried to implement a parser for and using Truffle at the end of last year. I did a packrat parser of a PEG, using the Katahdin algorithm (http://chrisseaton.com/katahdin) for composability of different language grammars. I also had the vague idea that you could annotate parsing rules in your Truffle nodes. So nodes would have both an execute method, and a parse annotation. Some node would be marked as the global root and the parser would match from there. I didn?t get far enough to measure any performance, and the Katahdin algorithm is really far too slow anyway. You might get a better result using your more conventional parsing algorithm. Good luck! Chris On 22 Jul 2014, at 10:13, Stefan Fehrenbach wrote: > Hi! > > On 21 July 2014 13:36, Stefan Marr wrote: >> Hi Stefan: >> >> On 21 Jul 2014, at 13:19, Stefan Fehrenbach wrote: >> >>> My question is about this message "inline failed", where it says >>> "reason recursion". Is that a problem? >> >> In my experience, that becomes only relevant after you fixed the escaping frames. >> > Okay. > >> This sounds strange to me. Are you using Truffle to implement a fast parser? > Yes, indeed. A parser is basically an ahead-of-time compiled grammar. > My code implements a grammar interpreter using Truffle for JIT > compilation :) > Preliminary results of my experiments with a very primitive recursive > descent recognizer are promising. > >> Or are you implementing the interpretation of the parser?s result. >> The usual thing is the later. >> Another thing is that I haven?t seen a trampoline-based interpreter based on Truffle yet. >> Instead, as far as I know, they are all fully recursive and rely on Graal to make that work efficiently. >> > Well, the parsing algorithm (GLL) dictates the need for a trampoline. > It seems to work out so far. I guess I do a lot of indirect calls > instead of partial evaluated Truffle magic, which will be slow, but I > hope it will not be much slower than the existing non-Truffle code. > >> >>> It just occurs to me, that my last frame escapes problem went away >>> with an @ExplodeLoop annotation. Is the problem the loop in >>> ParsingState.push [3]? >>> How do I fix it? You use @ExplodeLoop to loop over children, right? >>> The "results" are not part of the AST and they might not even be >>> compilation final? >> >> Every time I saw a new escaping frame issue it was because I introduced a loop that was not unrolled. >> So, my guess would be that you got your root cause right there. >> >> It is important that the loop bounds are going to be fixed at run time, so, I don?t know whether that is going to be the case here with your `results` set. >> It also looks like you are not strictly implementing your interpretation as part of the AST. >> >> Such loops should be in execute*() methods of Truffle nodes, and depend (in terms of number of iterations) solely on child nodes and known constant values, so that the loop unrolling triggered by @ExplodeLoop can do its magic. >> > > So, I "fixed" the problem by removing the VirtualFrame parameter from > a couple of methods. > I guess you can only have execute* methods on AST nodes, but some of > my receivers were not. > I suspect if I want to have Truffle magic along these paths, I'll need > to do some clever grammar analysis and rewrite to specialized nodes > based on the results. Might be possible, I don't know yet. > > Anyways, thanks for the help :) > > Stefan From eric.caspole at amd.com Tue Jul 22 14:11:05 2014 From: eric.caspole at amd.com (Eric Caspole) Date: Tue, 22 Jul 2014 10:11:05 -0400 Subject: Webrev for unloading kernels after class unloading In-Reply-To: References: Message-ID: <53CE70F9.3060305@amd.com> OK, I will see how to use javac API or ASM to compile the embedded class. On 07/22/2014 07:26 AM, Gilles Duboscq wrote: > I agree, it would be better to generate the class. > If you do it with Javac, please tell me because it may require a small > mx modification (providing libraries from the JDK: we already have JRE > libraries but JDK is slightly diffrerent). If you prefer ASM you can > declare it like this: > > library at ASM@path=lib/asm-5.0.3.jar > library at ASM@urls=http://lafo.ssw.uni-linz.ac.at/graal-external-deps/asm-5.0.3.jar,http://central.maven.org/maven2/org/ow2/asm/asm/5.0.3/asm-5.0.3.jar > library at ASM@sha1=dcc2193db20e19e1feca8b1240dbbc4e190824fa > library at ASM@sourcePath=lib/asm-5.0.3-sources.jar > library at ASM@sourceSha1=f0f24f6666c1a15c7e202e91610476bd4ce59368 > library at ASM@sourceUrls=http://lafo.ssw.uni-linz.ac.at/graal-external-deps/asm-5.0.3-sources.jar,http://central.maven.org/maven2/org/ow2/asm/asm/5.0.3/asm-5.0.3-sources.jar > > Overall the change looks good but i'm not so happy with the fact that > that we use the "external" flag in this way. Maybe it's just a naming > problem and we should just rename it to "gpu" such that we rather have > a concept of "gpu nmethods" (this renaming would anyway be for a > different changeset). > > -Gilles > > On Tue, Jul 22, 2014 at 12:03 AM, Igor Veresov wrote: >> Hi Eric, >> >> Seems ok. Embedding the class file as a binary in the test is odd though. Shouldn?t it be possible to compile it from within the test with the javac api? >> >> igor >> >> On Jul 21, 2014, at 1:52 PM, Caspole, Eric wrote: >> >>> Hi everybody, >>> I put up a new webrev that allows GPU kernels to be unloaded when their class loader context gets unloaded, when used with the latest Sumatra JDK. >>> >>> http://cr.openjdk.java.net/~ecaspole/unload_kernels/01/ >>> >>> There was already a notion of "external nmethod" in the Graal side and in the nmethod, but they had not been connected before. Here, the kernel nmethods get the external flag set, and if the class loader context of the kernel is getting unloaded it will call to the GPU::Hsail class to unload the kernel from the HSA runtime, using the API in the latest version of Okra we added last week. There is a new test case in the webrev to create an offloadable kernel in a custom class loader and see that it gets Gc-ed and collected using jmx APIs. >>> >>> One shortcoming in this version I want to get comments on is how to distinguish HSAIL vs PTX nmethods so the unload code calls the correct GPU runtime to do the dispose. We don't use "make not entrant" style flagging of kernel nmethods but this change is the first step in making the kernels more proper members in the code cache. >>> >>> I also added the call to dispose the HSA GPU context similar to what the PTX version had for a long while now. >>> Let me know your comments, >>> Thanks, >>> Eric >>> >> From tom.deneau at amd.com Tue Jul 22 16:32:46 2014 From: tom.deneau at amd.com (Deneau, Tom) Date: Tue, 22 Jul 2014 16:32:46 +0000 Subject: double free or corruption Message-ID: What is the best technique to debug an error like the following (after having made some hotspot changes)... -- Tom *** Error in `/home/user1/SumatraDemos/graal/jdk1.8.0-internal/product/bin/java': double free or corruption (!prev): 0x00002b80e8517a30 *** From tom.deneau at amd.com Tue Jul 22 18:03:40 2014 From: tom.deneau at amd.com (Deneau, Tom) Date: Tue, 22 Jul 2014 18:03:40 +0000 Subject: double free or corruption In-Reply-To: References: Message-ID: I tried valgrind on a fairly simple mx unittest run for which the list of unittests was basically 32 copies of com.oracle.graal.jtt.bytecode.BC_aload_1 com.oracle.graal.jtt.bytecode.BC_aload_0 com.oracle.graal.jtt.bytecode.BC_aload_3 com.oracle.graal.jtt.bytecode.BC_aload_2 I get some valgrind errors of the following form. Is this expected? I seem to only see this on the product build, not fastdebug or debug. ==11432== Address 0x206c0ed8 is 8 bytes inside a block of size 24 free'd ==11432== at 0x4C2B60C: free (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) ==11432== by 0x61E5810: InlineCacheBuffer::update_inline_caches() (allocation.inline.hpp:83) ==11432== by 0x64EFF9F: SafepointSynchronize::do_cleanup_tasks() (safepoint.cpp:527) ==11432== by 0x64F0914: SafepointSynchronize::begin() (safepoint.cpp:403) ==11432== by 0x65FCFB9: VMThread::loop() (vmThread.cpp:496) ==11432== by 0x65FD411: VMThread::run() (vmThread.cpp:274) ==11432== by 0x6459EC1: java_start(Thread*) (os_linux.cpp:860) -- Tom -----Original Message----- From: graal-dev [mailto:graal-dev-bounces at openjdk.java.net] On Behalf Of Deneau, Tom Sent: Tuesday, July 22, 2014 11:33 AM To: graal-dev at openjdk.java.net Subject: double free or corruption What is the best technique to debug an error like the following (after having made some hotspot changes)... -- Tom *** Error in `/home/user1/SumatraDemos/graal/jdk1.8.0-internal/product/bin/java': double free or corruption (!prev): 0x00002b80e8517a30 *** From tom.rodriguez at oracle.com Tue Jul 22 18:15:16 2014 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Tue, 22 Jul 2014 11:15:16 -0700 Subject: double free or corruption In-Reply-To: References: Message-ID: In the past valgrind hasn?t worked well with hotspot because of various tricks it plays with storage management but the error below doesn?t look unreasonable. At a guess I?d say this code is pointing at line 217 in icBuffer.cpp where the CompiledICHolder is being freed. while (holder != NULL) { CompiledICHolder* next = holder->next(); delete holder; I don?t think any particularly clever tricks are being played here so I don?t know why it would be reporting a problem. It could just be valgrind getting confused. Have you tried running with the debug options of GNU malloc? Setting MALLOC_CHECK_=1 in your environment will enable some debug code which reports the errors it detects. The value 2 causes it to abort immediately instead It can?t detect everything valgrind does but double frees and other basic errors are caught. tom On Jul 22, 2014, at 11:03 AM, Deneau, Tom wrote: > I tried valgrind on a fairly simple mx unittest run for which the list of unittests was basically 32 copies of com.oracle.graal.jtt.bytecode.BC_aload_1 > com.oracle.graal.jtt.bytecode.BC_aload_0 > com.oracle.graal.jtt.bytecode.BC_aload_3 > com.oracle.graal.jtt.bytecode.BC_aload_2 > > I get some valgrind errors of the following form. Is this expected? > I seem to only see this on the product build, not fastdebug or debug. > > ==11432== Address 0x206c0ed8 is 8 bytes inside a block of size 24 free'd > ==11432== at 0x4C2B60C: free (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) > ==11432== by 0x61E5810: InlineCacheBuffer::update_inline_caches() (allocation.inline.hpp:83) > ==11432== by 0x64EFF9F: SafepointSynchronize::do_cleanup_tasks() (safepoint.cpp:527) > ==11432== by 0x64F0914: SafepointSynchronize::begin() (safepoint.cpp:403) > ==11432== by 0x65FCFB9: VMThread::loop() (vmThread.cpp:496) > ==11432== by 0x65FD411: VMThread::run() (vmThread.cpp:274) > ==11432== by 0x6459EC1: java_start(Thread*) (os_linux.cpp:860) > > > -- Tom > > > -----Original Message----- > From: graal-dev [mailto:graal-dev-bounces at openjdk.java.net] On Behalf Of Deneau, Tom > Sent: Tuesday, July 22, 2014 11:33 AM > To: graal-dev at openjdk.java.net > Subject: double free or corruption > > What is the best technique to debug an error like the following (after having made some hotspot changes)... > > -- Tom > > *** Error in `/home/user1/SumatraDemos/graal/jdk1.8.0-internal/product/bin/java': double free or corruption (!prev): 0x00002b80e8517a30 *** > From doug.simon at oracle.com Wed Jul 23 01:00:06 2014 From: doug.simon at oracle.com (doug.simon at oracle.com) Date: Wed, 23 Jul 2014 01:00:06 +0000 Subject: hg: graal/graal: 7 new changesets Message-ID: <201407230100.s6N106wB012719@aojmv0008> Changeset: a01fe4b301a8 Author: Chris Seaton Date: 2014-07-22 12:44 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/a01fe4b301a8 Truffle/Instrument: new syntax tags for periodically appearing locations. ! graal/com.oracle.truffle.api/src/com/oracle/truffle/api/instrument/StandardSyntaxTag.java Changeset: cc81bbd2e859 Author: Lukas Stadler Date: 2014-07-22 15:04 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/cc81bbd2e859 small comment in SwitchNode ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/extended/SwitchNode.java Changeset: 9793d86c21c5 Author: Lukas Stadler Date: 2014-07-22 15:05 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/9793d86c21c5 use TTY in BenchmarkCounters ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/debug/BenchmarkCounters.java Changeset: 8a23eeeb7b06 Author: Lukas Stadler Date: 2014-07-22 15:05 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/8a23eeeb7b06 use log level in EffectsClosure ! graal/com.oracle.graal.virtual/src/com/oracle/graal/virtual/phases/ea/EffectsClosure.java Changeset: a7d9b88ecd68 Author: Lukas Stadler Date: 2014-07-22 15:06 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/a7d9b88ecd68 use LIRKind in graalCodeInstaller, support compressed oops in frame states ! src/share/vm/classfile/systemDictionary.hpp ! src/share/vm/classfile/vmSymbols.hpp ! src/share/vm/graal/graalCodeInstaller.cpp ! src/share/vm/graal/graalJavaAccess.hpp ! src/share/vm/graal/graalRuntime.cpp Changeset: 8be5c68a779d Author: Andreas Woess Date: 2014-07-22 16:32 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/8be5c68a779d Truffle: revert to previous iterator implementation, add test case ! graal/com.oracle.truffle.api.test/src/com/oracle/truffle/api/test/ChildrenNodesTest.java ! graal/com.oracle.truffle.api/src/com/oracle/truffle/api/nodes/NodeUtil.java Changeset: 0eb70f622d01 Author: Andreas Woess Date: 2014-07-18 00:33 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/0eb70f622d01 Truffle: make NeverPartOfCompilationNode a MacroStateSplitNode for better debuggability ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/nodes/asserts/NeverPartOfCompilationNode.java ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/nodes/typesystem/CustomizedUnsafeStoreMacroNode.java From doug.simon at oracle.com Thu Jul 24 01:00:06 2014 From: doug.simon at oracle.com (doug.simon at oracle.com) Date: Thu, 24 Jul 2014 01:00:06 +0000 Subject: hg: graal/graal: 7 new changesets Message-ID: <201407240100.s6O106cU016287@aojmv0008> Changeset: 342fe74e3b90 Author: Lukas Stadler Date: 2014-07-23 11:53 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/342fe74e3b90 prefer predecessor frame states at merges ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/FrameStateAssignmentPhase.java Changeset: ab84673bedc2 Author: Lukas Stadler Date: 2014-07-23 13:56 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/ab84673bedc2 change assertions in VirtualObject to look at the LIRKind ! graal/com.oracle.graal.api.code/src/com/oracle/graal/api/code/VirtualObject.java Changeset: 0d3a4532a28c Author: Lukas Stadler Date: 2014-07-23 14:16 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/0d3a4532a28c better stamps for RightShiftNode ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/calc/RightShiftNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/type/StampTool.java Changeset: 4a8f255c8c8d Author: Lukas Stadler Date: 2014-07-23 14:19 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/4a8f255c8c8d LoadHubNode is not Canonicalizable.Unary (beause of the guard) ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/extended/LoadHubNode.java Changeset: 173da8c3095d Author: Lukas Stadler Date: 2014-07-23 14:20 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/173da8c3095d support simplification in CustomCanonicalizer and turn it into an abstract class ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/CanonicalizerPhase.java ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/PartialEvaluatorCanonicalizer.java Changeset: 4209ec855c1c Author: Lukas Stadler Date: 2014-07-23 14:24 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/4209ec855c1c cleanups and doc for PhiNode.singleValue ! graal/com.oracle.graal.loop/src/com/oracle/graal/loop/InductionVariables.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/PhiNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/util/GraphUtil.java Changeset: 6bdd2ec553eb Author: Lukas Stadler Date: 2014-07-23 15:01 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/6bdd2ec553eb handle HotSpotCompressedNullConstant in graalCodeInstaller ! src/share/vm/classfile/systemDictionary.hpp ! src/share/vm/classfile/vmSymbols.hpp ! src/share/vm/graal/graalCodeInstaller.cpp ! src/share/vm/graal/graalJavaAccess.hpp From tom.deneau at amd.com Thu Jul 24 20:24:09 2014 From: tom.deneau at amd.com (Deneau, Tom) Date: Thu, 24 Jul 2014 20:24:09 +0000 Subject: double free or corruption In-Reply-To: References: Message-ID: Using MALLOC_CHECK_ = 1 or 2 resulted in the heap being at a low address and uncovered a bug in the HSAILAssembler in the way we output HSAIL for constant addresses, but unfortunately with that bug fixed and MALLOC_CHECK_ on, I don't see any of the original failures. I tried calling mcheck(0) in the debugger at startup time but that resulted in immediate errors (hopefully not significant) reading " memory clobbered before allocated block" in places like os::current_stack_size. Maybe this is similar to the complaints of valgrind? #3 0x00007ffff786e5de in __GI___libc_fatal (message=0x7ffff79831d0 "memory clobbered before allocated block\n") at ../sysdeps/unix/sysv/linux/libc_fatal.c:210 #4 0x00007ffff78802d5 in mabort (status=) at mcheck.c:364 #5 0x00007ffff788079e in checkhdr (hdr=0x7fffcc000890) at mcheck.c:115 #6 checkhdr (hdr=0x7fffcc000890) at mcheck.c:181 #7 freehook (ptr=0x7fffcc0008c0, caller=0x7ffff73e28ad <__pthread_attr_destroy+13>) at mcheck.c:188 #8 0x00007ffff73e28ad in __pthread_attr_destroy (attr=) at pthread_attr_destroy.c:41 #9 0x00007ffff6918b47 in current_stack_region (bottom=0x7fffdbefdaf0, size=0x7fffdbefdaf8) at /home/user1/SumatraDemos/graal/src/os_cpu/linux_x86/vm/os_linux_x86.cpp:731 #10 0x00007ffff6918c09 in os::current_stack_size () at /home/user1/SumatraDemos/graal/src/os_cpu/linux_x86/vm/os_linux_x86.cpp:749 #11 0x00007ffff6a68ba9 in Thread::record_stack_base_and_size (this=0x7ffff003b000) at /home/user1/SumatraDemos/graal/src/share/vm/runtime/thread.cpp:322 -- Tom -----Original Message----- From: Tom Rodriguez [mailto:tom.rodriguez at oracle.com] Sent: Tuesday, July 22, 2014 1:15 PM To: Deneau, Tom Cc: graal-dev at openjdk.java.net Subject: Re: double free or corruption In the past valgrind hasn't worked well with hotspot because of various tricks it plays with storage management but the error below doesn't look unreasonable. At a guess I'd say this code is pointing at line 217 in icBuffer.cpp where the CompiledICHolder is being freed. while (holder != NULL) { CompiledICHolder* next = holder->next(); delete holder; I don't think any particularly clever tricks are being played here so I don't know why it would be reporting a problem. It could just be valgrind getting confused. Have you tried running with the debug options of GNU malloc? Setting MALLOC_CHECK_=1 in your environment will enable some debug code which reports the errors it detects. The value 2 causes it to abort immediately instead It can't detect everything valgrind does but double frees and other basic errors are caught. tom On Jul 22, 2014, at 11:03 AM, Deneau, Tom wrote: > I tried valgrind on a fairly simple mx unittest run for which the list of unittests was basically 32 copies of com.oracle.graal.jtt.bytecode.BC_aload_1 > com.oracle.graal.jtt.bytecode.BC_aload_0 > com.oracle.graal.jtt.bytecode.BC_aload_3 > com.oracle.graal.jtt.bytecode.BC_aload_2 > > I get some valgrind errors of the following form. Is this expected? > I seem to only see this on the product build, not fastdebug or debug. > > ==11432== Address 0x206c0ed8 is 8 bytes inside a block of size 24 free'd > ==11432== at 0x4C2B60C: free (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) > ==11432== by 0x61E5810: InlineCacheBuffer::update_inline_caches() (allocation.inline.hpp:83) > ==11432== by 0x64EFF9F: SafepointSynchronize::do_cleanup_tasks() (safepoint.cpp:527) > ==11432== by 0x64F0914: SafepointSynchronize::begin() (safepoint.cpp:403) > ==11432== by 0x65FCFB9: VMThread::loop() (vmThread.cpp:496) > ==11432== by 0x65FD411: VMThread::run() (vmThread.cpp:274) > ==11432== by 0x6459EC1: java_start(Thread*) (os_linux.cpp:860) > > > -- Tom > > > -----Original Message----- > From: graal-dev [mailto:graal-dev-bounces at openjdk.java.net] On Behalf Of Deneau, Tom > Sent: Tuesday, July 22, 2014 11:33 AM > To: graal-dev at openjdk.java.net > Subject: double free or corruption > > What is the best technique to debug an error like the following (after having made some hotspot changes)... > > -- Tom > > *** Error in `/home/user1/SumatraDemos/graal/jdk1.8.0-internal/product/bin/java': double free or corruption (!prev): 0x00002b80e8517a30 *** > From java at stefan-marr.de Thu Jul 24 20:48:25 2014 From: java at stefan-marr.de (Stefan Marr) Date: Thu, 24 Jul 2014 22:48:25 +0200 Subject: New Splitting strategy: running into assertion failure in newSplitting method Message-ID: <55E698A4-FD48-4422-A508-D24A3E0F7443@stefan-marr.de> Hi Christian: I updated to the latest version of Graal and tried the new splitting heuristic. Overall it seems to be a win for TruffleSOM. Warmup up time seems to increase significantly, and two benchmarks suffer, but overall results seem to be positive. However, on all benchmarks I tested manually, I was running into an assertion error. (at com.oracle.graal.truffle.DefaultTruffleSplittingStrategyNew.newSplitting(DefaultTruffleSplittingStrategyNew.java:102)) It doesn?t seem to cause any visible issues, but the assumption of the assertion does not hold. Best regards Stefan -- Stefan Marr INRIA Lille - Nord Europe http://stefan-marr.de/research/ From doug.simon at oracle.com Fri Jul 25 01:00:06 2014 From: doug.simon at oracle.com (doug.simon at oracle.com) Date: Fri, 25 Jul 2014 01:00:06 +0000 Subject: hg: graal/graal: 3 new changesets Message-ID: <201407250100.s6P106Ph024703@aojmv0008> Changeset: c62c1e0060cc Author: Tom Rodriguez Date: 2014-07-23 17:36 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/c62c1e0060cc Don't allow infinite loops to explode loop frequencies ! graal/com.oracle.graal.java/src/com/oracle/graal/java/ComputeLoopFrequenciesClosure.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/cfg/ControlFlowGraph.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 Changeset: 86eee6794713 Author: Tom Rodriguez Date: 2014-07-23 17:39 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/86eee6794713 BitScanReverseNode stamp tests should only be used with BitScanReverseNode ! graal/com.oracle.graal.replacements.test/src/com/oracle/graal/replacements/test/BitOpNodesTest.java Changeset: 8084d44c78d3 Author: Tom Rodriguez Date: 2014-07-24 12:22 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/8084d44c78d3 don't allow bsr to be used outside of intrinsics ! graal/com.oracle.graal.replacements/src/com/oracle/graal/replacements/IntegerSubstitutions.java ! graal/com.oracle.graal.replacements/src/com/oracle/graal/replacements/LongSubstitutions.java ! graal/com.oracle.graal.replacements/src/com/oracle/graal/replacements/nodes/BitScanForwardNode.java ! graal/com.oracle.graal.replacements/src/com/oracle/graal/replacements/nodes/BitScanReverseNode.java From doug.simon at oracle.com Sat Jul 26 01:00:06 2014 From: doug.simon at oracle.com (doug.simon at oracle.com) Date: Sat, 26 Jul 2014 01:00:06 +0000 Subject: hg: graal/graal: 4 new changesets Message-ID: <201407260100.s6Q106On029937@aojmv0008> Changeset: ba48a694e4c1 Author: Lukas Stadler Date: 2014-07-25 13:21 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/ba48a694e4c1 inferStamp for CompressionNode ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/nodes/CompressionNode.java Changeset: c4104e5ef7ab Author: Lukas Stadler Date: 2014-07-25 14:31 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/c4104e5ef7ab correctly handle inlining of method with multiple returns ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/inlining/InliningUtil.java Changeset: 618d92152d3c Author: David Piorkowski Date: 2014-07-24 16:14 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/618d92152d3c SL: Added support for instrumentation. ! 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/factory/SLContextFactory.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/instrument/SLASTPrinter.java + graal/com.oracle.truffle.sl/src/com/oracle/truffle/sl/nodes/instrument/SLASTProber.java + graal/com.oracle.truffle.sl/src/com/oracle/truffle/sl/nodes/instrument/SLDefaultVisualizer.java + graal/com.oracle.truffle.sl/src/com/oracle/truffle/sl/nodes/instrument/SLExpressionWrapper.java + graal/com.oracle.truffle.sl/src/com/oracle/truffle/sl/nodes/instrument/SLNodeProber.java + graal/com.oracle.truffle.sl/src/com/oracle/truffle/sl/nodes/instrument/SLStatementWrapper.java ! graal/com.oracle.truffle.sl/src/com/oracle/truffle/sl/parser/Parser.frame ! graal/com.oracle.truffle.sl/src/com/oracle/truffle/sl/parser/Parser.java ! graal/com.oracle.truffle.sl/src/com/oracle/truffle/sl/parser/SLNodeFactory.java ! graal/com.oracle.truffle.sl/src/com/oracle/truffle/sl/runtime/SLContext.java Changeset: 9e2317b1092b Author: David Piorkowski Date: 2014-07-25 08:35 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/9e2317b1092b SL: Merging changes to root From doug.simon at oracle.com Sun Jul 27 01:00:06 2014 From: doug.simon at oracle.com (doug.simon at oracle.com) Date: Sun, 27 Jul 2014 01:00:06 +0000 Subject: hg: graal/graal: loading of anonymous classes must update SystemDictionary::_number_of_modifications Message-ID: <201407270100.s6R108jQ025391@aojmv0008> Changeset: fcb186b03c8b Author: Tom Rodriguez Date: 2014-07-25 17:38 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/fcb186b03c8b loading of anonymous classes must update SystemDictionary::_number_of_modifications ! src/share/vm/classfile/systemDictionary.cpp From doug.simon at oracle.com Tue Jul 29 01:00:06 2014 From: doug.simon at oracle.com (doug.simon at oracle.com) Date: Tue, 29 Jul 2014 01:00:06 +0000 Subject: hg: graal/graal: 12 new changesets Message-ID: <201407290100.s6T106g1000751@aojmv0008> Changeset: edf653f51521 Author: Doug Simon Date: 2014-07-28 11:35 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/edf653f51521 added per-user cache for mx downloads ! mxtool/mx.py Changeset: 89be7c4db12c Author: Doug Simon Date: 2014-07-28 13:55 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/89be7c4db12c made sha1 signatures mandatory for libraries; made libraries for all downloading performed by commands in mx_graal ! mx/mx_graal.py ! mx/projects ! mxtool/mx.py Changeset: 6e7311d571ff Author: Doug Simon Date: 2014-07-28 14:48 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/6e7311d571ff modify the 'mx vm' command to check that the VM is up-to-date with respect to graalRuntime.inline.hpp ! mx/mx_graal.py Changeset: cd25e42d9b22 Author: Lukas Stadler Date: 2014-07-28 15:53 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/cd25e42d9b22 rename IntegerBelowThanNode to IntegerBelowNode ! graal/com.oracle.graal.compiler.amd64/src/com/oracle/graal/compiler/amd64/AMD64NodeLIRBuilder.java ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/gen/NodeLIRBuilder.java ! graal/com.oracle.graal.hotspot.amd64/src/com/oracle/graal/hotspot/amd64/AMD64HotSpotNodeLIRBuilder.java ! graal/com.oracle.graal.java/src/com/oracle/graal/java/GraphBuilderPhase.java ! graal/com.oracle.graal.loop/src/com/oracle/graal/loop/LoopEx.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/IfNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/calc/CompareNode.java + graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/calc/IntegerBelowNode.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/IntegerLessThanNode.java ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/ConditionalEliminationPhase.java ! graal/com.oracle.graal.replacements/src/com/oracle/graal/replacements/DefaultJavaLoweringProvider.java ! graal/com.oracle.graal.word/src/com/oracle/graal/word/phases/WordTypeRewriterPhase.java Changeset: a4490086af4d Author: Lukas Stadler Date: 2014-07-28 15:53 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/a4490086af4d remove unused setters from BinaryOpLogicNode ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/BinaryOpLogicNode.java Changeset: 5fcb220206e2 Author: Lukas Stadler Date: 2014-07-28 15:53 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/5fcb220206e2 small fix in FloatingReadPhase (when handling existing phis) ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/FloatingReadPhase.java Changeset: b519954b9daf Author: Lukas Stadler Date: 2014-07-28 15:53 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/b519954b9daf cached MatchPattern.Result failure constants ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/match/MatchPattern.java Changeset: c55478e640e1 Author: Doug Simon Date: 2014-07-28 16:51 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/c55478e640e1 generalized check that VM is up-to-date with all generated sources ! mx/mx_graal.py Changeset: 7036c4594919 Author: Tom Rodriguez Date: 2014-07-28 13:51 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/7036c4594919 correct name of zero usages method ! graal/com.oracle.graal.graph/src/com/oracle/graal/graph/Node.java Changeset: 07de1d5d53ef Author: Tom Rodriguez Date: 2014-07-28 13:52 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/07de1d5d53ef make scheduling before dumping optional to speed up dumping ! graal/com.oracle.graal.compiler.common/src/com/oracle/graal/compiler/common/GraalOptions.java ! graal/com.oracle.graal.printer/src/com/oracle/graal/printer/BinaryGraphPrinter.java ! graal/com.oracle.graal.printer/src/com/oracle/graal/printer/IdealGraphPrinter.java Changeset: 19410ce05a68 Author: Tom Rodriguez Date: 2014-07-28 14:43 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/19410ce05a68 Don't create useless ValueAnchorNode ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/ConditionalEliminationPhase.java Changeset: add3510d087b Author: Tom Rodriguez Date: 2014-07-28 14:43 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/add3510d087b Do final round of incremental conditional elimination ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/phases/LowTier.java From christian.humer at gmail.com Tue Jul 29 11:36:19 2014 From: christian.humer at gmail.com (Christian Humer) Date: Tue, 29 Jul 2014 13:36:19 +0200 Subject: New Splitting strategy: running into assertion failure in newSplitting method In-Reply-To: <55E698A4-FD48-4422-A508-D24A3E0F7443@stefan-marr.de> References: <55E698A4-FD48-4422-A508-D24A3E0F7443@stefan-marr.de> Message-ID: Hi Stefan, The assumption does in fact not hold yet. This needs a fix. Will remove it for now. Regarding the warmup time -G:-TruffleSplittingClassInstanceStamps should bring it again to a reasonable level. I think I will push this as a default because I've seen class instance stamps to have no visible influence on peak performance but horrible influence on startup time. Can you confim that? Thanks. - Christian Humer On Thu, Jul 24, 2014 at 10:48 PM, Stefan Marr wrote: > Hi Christian: > > I updated to the latest version of Graal and tried the new splitting > heuristic. > Overall it seems to be a win for TruffleSOM. Warmup up time seems to > increase significantly, and two benchmarks suffer, but overall results seem > to be positive. > > However, on all benchmarks I tested manually, I was running into an > assertion error. > (at > com.oracle.graal.truffle.DefaultTruffleSplittingStrategyNew.newSplitting(DefaultTruffleSplittingStrategyNew.java:102)) > > It doesn?t seem to cause any visible issues, but the assumption of the > assertion does not hold. > > Best regards > Stefan > > > -- > Stefan Marr > INRIA Lille - Nord Europe > http://stefan-marr.de/research/ > > > > From doug.simon at oracle.com Tue Jul 29 15:38:48 2014 From: doug.simon at oracle.com (doug.simon at oracle.com) Date: Tue, 29 Jul 2014 15:38:48 +0000 Subject: hg: graal/graal: 3 new changesets Message-ID: <201407291538.s6TFcnwI007609@aojmv0008> Changeset: 8cdb9ef96c01 Author: Doug Simon Date: 2014-07-29 16:53 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/8cdb9ef96c01 make up-to-date check for generated sources work with --installed-jdks ! mx/mx_graal.py Changeset: c6b16d7d139e Author: Doug Simon Date: 2014-07-29 16:54 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/c6b16d7d139e added test to show only verified bytecode can be accessed with Graal API + graal/com.oracle.graal.hotspot.test/src/com/oracle/graal/hotspot/test/BytecodeVerificationTest.java Changeset: ae876dca8a75 Author: Doug Simon Date: 2014-07-29 16:58 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/ae876dca8a75 added test showing that the Graal API is inaccessible when -XX:+UseGraalClassLoader is specified + graal/com.oracle.graal.hotspot.test/src/com/oracle/graal/hotspot/test/GraalClassLoaderTest.java From doug.simon at oracle.com Wed Jul 30 01:00:05 2014 From: doug.simon at oracle.com (doug.simon at oracle.com) Date: Wed, 30 Jul 2014 01:00:05 +0000 Subject: hg: graal/graal: fix FloatRemNode canonicalization Message-ID: <201407300100.s6U10Ai1005783@aojmv0008> Changeset: 0d582cb054c7 Author: Lukas Stadler Date: 2014-07-29 17:35 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/0d582cb054c7 fix FloatRemNode canonicalization ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/calc/FloatRemNode.java From doug.simon at oracle.com Thu Jul 31 01:00:05 2014 From: doug.simon at oracle.com (doug.simon at oracle.com) Date: Thu, 31 Jul 2014 01:00:05 +0000 Subject: hg: graal/graal: 9 new changesets Message-ID: <201407310100.s6V106YF008963@aojmv0008> Changeset: 0f2a9150d6f8 Author: Tom Rodriguez Date: 2014-07-29 17:39 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/0f2a9150d6f8 CleanTypeProfileProxyPhase should cleanup after itself ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/phases/HighTier.java ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/CleanTypeProfileProxyPhase.java Changeset: 3812931f9350 Author: Tom Rodriguez Date: 2014-07-29 17:40 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/3812931f9350 Don't read beyond end of known vtable ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/HotSpotVMConfig.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 Changeset: 29404eec7ced Author: Tom Rodriguez Date: 2014-07-29 17:40 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/29404eec7ced eliminate duplicate entries from profile data ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotMethodData.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/java/TypeSwitchNode.java ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/inlining/info/MultiTypeGuardInlineInfo.java Changeset: c164a505fc23 Author: Tom Rodriguez Date: 2014-07-29 17:40 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/c164a505fc23 Properly handle multiple copies of the same test when unswitching ! graal/com.oracle.graal.loop/src/com/oracle/graal/loop/LoopPolicies.java ! graal/com.oracle.graal.loop/src/com/oracle/graal/loop/LoopTransformations.java ! graal/com.oracle.graal.loop/src/com/oracle/graal/loop/phases/LoopTransformLowPhase.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/extended/IntegerSwitchNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/extended/SwitchNode.java Changeset: 0b0726730fbd Author: Tom Rodriguez Date: 2014-07-29 17:57 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/0b0726730fbd add some comments to BitOpNodesTest.java ! graal/com.oracle.graal.replacements.test/src/com/oracle/graal/replacements/test/BitOpNodesTest.java Changeset: 2acc00d0322a Author: Tom Rodriguez Date: 2014-07-29 17:58 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/2acc00d0322a Extra sanity checking in initHotSpotVMConfig ! graal/com.oracle.graal.hotspotvmconfig/src/com/oracle/graal/hotspotvmconfig/HotSpotVMConfigProcessor.java Changeset: a4b7356f4a2b Author: Chris Seaton Date: 2014-07-30 11:34 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/a4b7356f4a2b Unless the current revision is tagged as a release, make the Graal version 0.(n+1)-dev, in order to differentiate between release and development versions. ! mx/mx_graal.py Changeset: 202d86545bba Author: Chris Seaton Date: 2014-07-30 11:39 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/202d86545bba Fix Python style. ! mx/mx_graal.py Changeset: faaea970b951 Author: Chris Seaton Date: 2014-07-30 13:42 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/faaea970b951 Add an mx install command to install the Truffle jars to the local Maven repository. ! mx/mx_graal.py From doug.simon at oracle.com Thu Jul 31 08:37:24 2014 From: doug.simon at oracle.com (doug.simon at oracle.com) Date: Thu, 31 Jul 2014 08:37:24 +0000 Subject: hg: graal/graal: 4 new changesets Message-ID: <201407310837.s6V8bOxT013478@aojmv0008> Changeset: addc0564e5b5 Author: Doug Simon Date: 2014-07-30 18:27 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/addc0564e5b5 split com.oracle.graal.truffle.* projects into a separate graal-truffle.jar and added truffle.jar to the boot class path ! graal/com.oracle.graal.hotspot.loader/src/com/oracle/graal/hotspot/loader/Factory.java ! graal/com.oracle.graal.hotspot.sourcegen/src/com/oracle/graal/hotspot/sourcegen/GenGraalRuntimeInlineHpp.java ! graal/com.oracle.graal.hotspot.sourcegen/src/com/oracle/graal/hotspot/sourcegen/OptionsVerifier.java ! mx/mx_graal.py ! mx/projects ! mxtool/mx.py ! src/share/vm/graal/graalRuntime.hpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/os.cpp Changeset: c9284d733aa1 Author: Doug Simon Date: 2014-07-30 18:27 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/c9284d733aa1 made -XX:+UseGraalClassLoader the default (now that truffle.jar is on the boot class path) ! src/share/vm/graal/graalGlobals.hpp Changeset: d2aa48d54db5 Author: Doug Simon Date: 2014-07-30 21:48 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/d2aa48d54db5 don't allow blocking compilation requests to Graal if Graal itself is not yet initialized ! src/share/vm/compiler/compileBroker.cpp Changeset: 7ce626e1952c Author: Doug Simon Date: 2014-07-31 00:19 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/7ce626e1952c removed direct use of Unsafe.getUnsafe() since graal.jar is no longer on boot class path and so reflection method of accessed Unsafe must be used ! graal/com.oracle.graal.compiler.common/src/com/oracle/graal/compiler/common/UnsafeAccess.java From doug.simon at oracle.com Thu Jul 31 14:26:08 2014 From: doug.simon at oracle.com (Doug Simon) Date: Thu, 31 Jul 2014 16:26:08 +0200 Subject: small webrev for hsail allocation stability In-Reply-To: References: Message-ID: <50584505-0188-4596-B6E7-8E2CC8F4AEDA@oracle.com> I?ve integrated this change. I inlined the logic for resetting the donor thread to minimize the diff to upstream hotspot. On Jul 17, 2014, at 12:55 AM, Deneau, Tom wrote: > I have submitted a small webrev to solve the following problem. > > The hsail allocation routines borrow TLABs from donor threads. The design depended on the donor threads not doing any allocation from those TLABs. The donor threads should be blocked on a CyclicBarrier. But we have seen in fairly rare cases things which looked like the donor threads were doing some allocations and interfering with the HSAIL kernel allocations. Maybe this is related to the "spurious wakeup" described in Object.wait javadocs? > > Anyway, this webrev zeroes out the donor thread tlabs as it copies the fields out into the TlabInfo structure used by the GPU. (this copy to TlabInfo has always been there, we just didn't zero out the donor thread tlab fields). Now if the donor thread does spuriously wakeup and needs to allocate anything it will get a new tlab or wait. If it gets a new tlab, then in the post-kernel cleanup code, we retire that tlab as we copy fields back in to the donor thread. > > Things were definitely more stable with this change. > http://cr.openjdk.java.net/~tdeneau/graal-webrevs/webrev-hsail-donor-tlab-zero/webrev/ > > -- Tom >