From doug.simon at oracle.com Fri Nov 1 03:46:23 2013 From: doug.simon at oracle.com (Doug Simon) Date: Fri, 1 Nov 2013 11:46:23 +0100 Subject: webrev for remaining bitwise operators and arithmetic negation In-Reply-To: <5DD1503F815BD14889DC81D28643E3A7553AB5BE@SATLEXDAG02.amd.com> References: <5DD1503F815BD14889DC81D28643E3A7553AB5BE@SATLEXDAG02.amd.com> Message-ID: <4A8010E7-5CE0-4221-A0D2-AD10456190D0@oracle.com> Somewhat related to Christian?s comment, please don?t use javadoc style comments where they are not applicable. graal/com.oracle.graal.asm.hsail/src/com/oracle/graal/asm/hsail/HSAILAssembler.java: + private void emitTextFormattedInstruction(String instr, Value dest, Value... sources) { + /** + * Destination can't be a constant and no instruction has > 3 source operands. + */ + assert (!isConstant(dest) && sources.length <= 3); Javadoc comments cannot be applied to statements. Otherwise, the patch looks fine. I?ll integrate it and fix up these comments along the way. -Doug On Oct 31, 2013, at 11:24 PM, Venkatachalam, Vasanth wrote: > Hi, > > I've uploaded a webrev that extends the HSAIL backend to generate code for bitwise right shift (>>), bitwise NOT (~), and arithmetic negation. > > http://cr.openjdk.java.net/~tdeneau/webrev-bitwiseopsupport-parttwo.01/webrev/ > > Please review and provide feedback. > > Summary of main changes. > > > * In HSAILLIRGenerator. Java I extended the implementation of the emitNegate, emitNot and emitShr routines to handle cases that weren't previously being covered. I then made supporting changes to HSAILArithmetic.java and HSAILAssembler.java. > > * I added unit test cases in compiler/hsail/test for left shift (<<), right shift (>>), unsigned right shift(>>>) and integer negation. > > * I refactored the emit routines in HSAILAssembler which were calling emitString. We previously had multiple of these routines taking different number of source operands. I was able to coalesce these into a single routine (renamed emitTextFormattedInstruction) taking variable number of source operands. This makes the code more readable but doesn't impact functionality. > > * A stylistic change. I rearranged the opcode values in the HSAILArithmetic enum to appear in alphabetical order for easier readability. > > * I've run this code through the eclipse 4.3 formatter and didn't see any changes in files that are part of this webrev. I've also tested the webrev against the latest OpenJDK version of the trunk. > > Vasanth From doug.simon at oracle.com Fri Nov 1 04:08:01 2013 From: doug.simon at oracle.com (Doug Simon) Date: Fri, 1 Nov 2013 12:08:01 +0100 Subject: webrev for remaining bitwise operators and arithmetic negation In-Reply-To: <4A8010E7-5CE0-4221-A0D2-AD10456190D0@oracle.com> References: <5DD1503F815BD14889DC81D28643E3A7553AB5BE@SATLEXDAG02.amd.com> <4A8010E7-5CE0-4221-A0D2-AD10456190D0@oracle.com> Message-ID: <4519D19C-4ED5-45E5-9B98-778C0736BE2F@oracle.com> Also, try to use ?descriptive? rather than ?prescriptive? form in javadoc comments. From the Javadoc style guide[1]: ? Use 3rd person (descriptive) not 2nd person (prescriptive). The description is in 3rd person declarative rather than 2nd person imperative. Gets the label. (preferred) Get the label. (avoid) -Doug [1] http://www.oracle.com/technetwork/java/javase/documentation/index-137868.html On Nov 1, 2013, at 11:46 AM, Doug Simon wrote: > Somewhat related to Christian?s comment, please don?t use javadoc style comments where they are not applicable. > > graal/com.oracle.graal.asm.hsail/src/com/oracle/graal/asm/hsail/HSAILAssembler.java: > > + private void emitTextFormattedInstruction(String instr, Value dest, Value... sources) { > + /** > + * Destination can't be a constant and no instruction has > 3 source operands. > + */ > + assert (!isConstant(dest) && sources.length <= 3); > > Javadoc comments cannot be applied to statements. > > Otherwise, the patch looks fine. I?ll integrate it and fix up these comments along the way. > > -Doug > > On Oct 31, 2013, at 11:24 PM, Venkatachalam, Vasanth wrote: > >> Hi, >> >> I've uploaded a webrev that extends the HSAIL backend to generate code for bitwise right shift (>>), bitwise NOT (~), and arithmetic negation. >> >> http://cr.openjdk.java.net/~tdeneau/webrev-bitwiseopsupport-parttwo.01/webrev/ >> >> Please review and provide feedback. >> >> Summary of main changes. >> >> >> * In HSAILLIRGenerator. Java I extended the implementation of the emitNegate, emitNot and emitShr routines to handle cases that weren't previously being covered. I then made supporting changes to HSAILArithmetic.java and HSAILAssembler.java. >> >> * I added unit test cases in compiler/hsail/test for left shift (<<), right shift (>>), unsigned right shift(>>>) and integer negation. >> >> * I refactored the emit routines in HSAILAssembler which were calling emitString. We previously had multiple of these routines taking different number of source operands. I was able to coalesce these into a single routine (renamed emitTextFormattedInstruction) taking variable number of source operands. This makes the code more readable but doesn't impact functionality. >> >> * A stylistic change. I rearranged the opcode values in the HSAILArithmetic enum to appear in alphabetical order for easier readability. >> >> * I've run this code through the eclipse 4.3 formatter and didn't see any changes in files that are part of this webrev. I've also tested the webrev against the latest OpenJDK version of the trunk. >> >> Vasanth > From doug.simon at oracle.com Fri Nov 1 08:21:49 2013 From: doug.simon at oracle.com (doug.simon at oracle.com) Date: Fri, 01 Nov 2013 15:21:49 +0000 Subject: hg: graal/graal: 41 new changesets Message-ID: <20131101152456.64AEC628E0@hg.openjdk.java.net> Changeset: 42a2c235652f Author: Doug Simon Date: 2013-10-27 19:51 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/42a2c235652f replace ".count() == 0" with ".isEmpty()" ! graal/com.oracle.graal.graph/src/com/oracle/graal/graph/NodeClass.java Changeset: 595f01abb887 Author: Doug Simon Date: 2013-10-27 19:59 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/595f01abb887 clearer API and documentation for the capability of a SaveRegistersOp to have its registers pruned ! graal/com.oracle.graal.hotspot.amd64/src/com/oracle/graal/hotspot/amd64/AMD64HotSpotLIRGenerator.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/HotSpotBackend.java ! graal/com.oracle.graal.lir.amd64/src/com/oracle/graal/lir/amd64/AMD64SaveRegistersOp.java ! graal/com.oracle.graal.lir.amd64/src/com/oracle/graal/lir/amd64/AMD64ZapRegistersOp.java ! graal/com.oracle.graal.lir/src/com/oracle/graal/lir/StandardOp.java Changeset: 47ac1df40fc2 Author: Doug Simon Date: 2013-10-28 11:27 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/47ac1df40fc2 refactored creation of Graal and Truffle compiler threads into a single facility + graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/CompilerThreadFactory.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/CompilationTask.java - graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/CompilerThread.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/bridge/VMToCompilerImpl.java ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/TruffleCompilerImpl.java - graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/TruffleCompilerThread.java Changeset: fe163112087a Author: Bernhard Urban Date: 2013-10-28 10:11 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/fe163112087a AESCryptSubstitutions: use more precise location for K array ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/AESCryptSubstitutions.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/CipherBlockChainingSubstitutions.java Changeset: b292dd6d02ac Author: Bernhard Urban Date: 2013-10-28 13:10 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/b292dd6d02ac CipherBlockChainingSubstitutions: use more precise location for embeddedCipher object and r array ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/CipherBlockChainingSubstitutions.java Changeset: bca33c3135de Author: Lukas Stadler Date: 2013-10-28 13:01 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/bca33c3135de PEA: support for unsafe stores of mismatching sizes, cleanup, documentation ! 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/Constant.java ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/gen/DebugInfoBuilder.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotHostLoweringProvider.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/ArrayCopyNode.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/WriteNode.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.nodes/src/com/oracle/graal/nodes/spi/VirtualizerTool.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/type/GenericStamp.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/type/StampFactory.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/virtual/VirtualArrayNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/virtual/VirtualInstanceNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/virtual/VirtualObjectNode.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/PartialEscapeClosure.java ! graal/com.oracle.graal.virtual/src/com/oracle/graal/virtual/phases/ea/VirtualizerToolImpl.java ! src/share/vm/runtime/deoptimization.cpp Changeset: 2925280e3f92 Author: Lukas Stadler Date: 2013-10-28 13:39 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/2925280e3f92 remove unused CommitAllocationNodes during simplification ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/virtual/CommitAllocationNode.java Changeset: 62b05f62a75c Author: Doug Simon Date: 2013-10-28 16:04 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/62b05f62a75c removed redundant assertion ! graal/com.oracle.graal.virtual/src/com/oracle/graal/virtual/phases/ea/PartialEscapeClosure.java Changeset: a9f750305a38 Author: Doug Simon Date: 2013-10-28 16:04 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/a9f750305a38 added --igv option to "mx projectgraph" command for sending output to IGV instead ! mxtool/mx.py Changeset: 7f55cdeec6af Author: Doug Simon Date: 2013-10-28 17:03 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/7f55cdeec6af improved documentation of HotSpotBackend.updateStub() ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/HotSpotBackend.java Changeset: f40b8d0d9dcb Author: Lukas Stadler Date: 2013-10-28 15:25 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/f40b8d0d9dcb PEA: more tests, common base class for tests + graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/ea/EAMergingTest.java + graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/ea/EATestBase.java ! graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/ea/EscapeAnalysisTest.java ! graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/ea/IterativeInliningTest.java ! graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/ea/PartialEscapeAnalysisTest.java + graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/ea/UnsafeEATest.java Changeset: 0d6ad1cd4191 Author: Lukas Stadler Date: 2013-10-28 15:27 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/0d6ad1cd4191 documentation and simplification in MonitorExitNode ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/java/MonitorExitNode.java Changeset: 37a4252fbcc7 Author: Lukas Stadler Date: 2013-10-29 16:56 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/37a4252fbcc7 exclude EATestBase from JaCoCo ! graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/ea/EATestBase.java Changeset: 1f7bca29d15c Author: Roland Schatz Date: 2013-10-29 17:26 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/1f7bca29d15c Simplify AMD64ConvertSnippets instantiation code. ! graal/com.oracle.graal.replacements.amd64/src/com/oracle/graal/replacements/amd64/AMD64ConvertSnippets.java Changeset: e09959e910f7 Author: Doug Simon Date: 2013-10-29 21:59 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/e09959e910f7 weakened or commented out assertions that are too strict given the way Truffle makes use of Unsafe ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotHostLoweringProvider.java ! graal/com.oracle.graal.virtual/src/com/oracle/graal/virtual/phases/ea/PartialEscapeClosure.java Changeset: 9cd8dbb8a37d Author: Doug Simon Date: 2013-10-29 22:01 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/9cd8dbb8a37d re-added a graph context to the debug scopes entered by Truffle partial evaluation and compilation so that -G:+DumpOnError works again ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/PartialEvaluator.java ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/TruffleCompilerImpl.java Changeset: c36bdee8ca29 Author: Doug Simon Date: 2013-10-29 22:03 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/c36bdee8ca29 added type check for object before reading a field value from it during compilation ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotResolvedJavaField.java Changeset: 8ba058ffbc2e Author: twisti Date: 2013-10-29 14:45 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/8ba058ffbc2e Clang 5.0 fixes ! make/bsd/makefiles/gcc.make Changeset: aadb188e4258 Author: Mick Jordan Date: 2013-10-29 21:05 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/aadb188e4258 mxtool: regenerate IDE files when suite imports file changes ! mxtool/mx.py Changeset: 2303d9e199e3 Author: Doug Simon Date: 2013-10-30 09:49 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/2303d9e199e3 rebuild projects if their annotation processor dependencies change; clean output directories before (re)compiling a Java project ! mxtool/mx.py Changeset: 8bb706d2b365 Author: Doug Simon Date: 2013-10-30 09:50 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/8bb706d2b365 added missing annotation processor dependency for com.oracle.graal.hotspot.sparc ! mx/projects Changeset: 5820660675a0 Author: Doug Simon Date: 2013-10-30 10:04 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/5820660675a0 added .currentAnnotationProcessors to .hgignore ! .hgignore Changeset: 321229a79f7a Author: Doug Simon Date: 2013-10-30 10:05 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/321229a79f7a format cleanup by 'mx eclipseformat' ! graal/com.oracle.graal.replacements/src/com/oracle/graal/replacements/SnippetCounter.java Changeset: ba6593e52d22 Author: Christian Humer Date: 2013-10-28 11:06 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/ba6593e52d22 Truffle-DSL: fixed additional wrong @SlowPath usage on generic. (GRAAL-490 #resolve) ! graal/com.oracle.truffle.api.dsl.test/src/com/oracle/truffle/api/dsl/test/SlowPathTest.java ! graal/com.oracle.truffle.dsl.processor/src/com/oracle/truffle/dsl/processor/node/NodeCodeGenerator.java ! graal/com.oracle.truffle.dsl.processor/src/com/oracle/truffle/dsl/processor/node/NodeData.java Changeset: 748b8381b171 Author: Christian Humer Date: 2013-10-29 16:23 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/748b8381b171 Merge. - graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/CompilerThread.java - graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/TruffleCompilerThread.java Changeset: 9b23caa3ad31 Author: Christian Humer Date: 2013-10-29 16:36 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/9b23caa3ad31 Truffle-DSL: fixed generated generic node adopted the polymorphic chain when transiting from polymorphic to generic. ! graal/com.oracle.truffle.dsl.processor/src/com/oracle/truffle/dsl/processor/node/NodeCodeGenerator.java Changeset: 02f844c76626 Author: Christian Humer Date: 2013-10-29 16:55 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/02f844c76626 Truffle-DSL: the default polymorphic depth should also include combinations of implicit casts. ! graal/com.oracle.truffle.dsl.processor/src/com/oracle/truffle/dsl/processor/node/NodeParser.java Changeset: 50aca0c0dff4 Author: Christian Humer Date: 2013-10-30 11:08 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/50aca0c0dff4 Merge. Changeset: 6860d5528902 Author: Doug Simon Date: 2013-10-30 13:14 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/6860d5528902 disabled pre-cleaning before Java compilation until annotation processor is resolved ! mxtool/mx.py Changeset: 851aa5341214 Author: Doug Simon Date: 2013-10-30 15:29 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/851aa5341214 moved persistent annotation processor dependency files into mx/currentAnnotationProcessors directory ! .hgignore ! mxtool/mx.py Changeset: e9f23b348da2 Author: Andreas Woess Date: 2013-10-30 17:31 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/e9f23b348da2 fix GraalTruffleRuntime.createMaterializedFrame(Arguments) overload. ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/GraalTruffleRuntime.java Changeset: 856a9864ed93 Author: Andreas Woess Date: 2013-10-30 20:01 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/856a9864ed93 Frame: add is methods. ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/FrameWithoutBoxing.java ! graal/com.oracle.truffle.api/src/com/oracle/truffle/api/frame/Frame.java ! graal/com.oracle.truffle.api/src/com/oracle/truffle/api/frame/NativeFrame.java ! graal/com.oracle.truffle.api/src/com/oracle/truffle/api/impl/DefaultMaterializedFrame.java ! graal/com.oracle.truffle.api/src/com/oracle/truffle/api/impl/DefaultVirtualFrame.java Changeset: e122dc0436be Author: Andreas Woess Date: 2013-10-30 19:05 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/e122dc0436be convert FrameSlot interface to a final class. ! graal/com.oracle.truffle.api/src/com/oracle/truffle/api/frame/FrameDescriptor.java ! graal/com.oracle.truffle.api/src/com/oracle/truffle/api/frame/FrameSlot.java - graal/com.oracle.truffle.api/src/com/oracle/truffle/api/frame/FrameSlotImpl.java Changeset: 60c32ab6eb39 Author: Andreas Woess Date: 2013-10-30 19:50 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/60c32ab6eb39 add FrameUtil.getSafe methods that do not throw checked exceptions. ! graal/com.oracle.truffle.api/src/com/oracle/truffle/api/frame/FrameUtil.java Changeset: 0046afcda972 Author: Andreas Woess Date: 2013-10-30 19:59 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/0046afcda972 remove obsolete FrameUtil.setSafe methods. ! graal/com.oracle.truffle.api/src/com/oracle/truffle/api/frame/FrameUtil.java Changeset: b038b643a3a4 Author: Doug Simon Date: 2013-10-30 21:49 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/b038b643a3a4 restricted BootstrapGraal option to GRAALVM builds only ! mx/commands.py ! mx/sanitycheck.py ! src/share/vm/graal/graalCompiler.cpp ! src/share/vm/graal/graalGlobals.hpp Changeset: 1fbe3ca3d30d Author: Doug Simon Date: 2013-10-31 12:08 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/1fbe3ca3d30d don't equate missing current annotation processor file with it being out of date ! mxtool/mx.py Changeset: f376a77c22fb Author: Lukas Stadler Date: 2013-10-31 18:44 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/f376a77c22fb don't create ProxyNodes for constants during PEA ! graal/com.oracle.graal.virtual/src/com/oracle/graal/virtual/phases/ea/PartialEscapeClosure.java Changeset: 04c74433529a Author: Lukas Stadler Date: 2013-10-31 18:45 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/04c74433529a PEA: create ProxyNodes when the LoopExitNode is encountered, not between blocks ! graal/com.oracle.graal.virtual/src/com/oracle/graal/virtual/phases/ea/EffectsClosure.java Changeset: c73b857b1be9 Author: Doug Simon Date: 2013-11-01 12:06 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/c73b857b1be9 Adds support to the HSAIL backend to generate code for bitwise right shift (>>), bitwise NOT (~), and arithmetic negation Contributed-by: Vasanth Venkatachalam ! 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/DoubleNegTest.java + graal/com.oracle.graal.compiler.hsail.test/src/com/oracle/graal/compiler/hsail/test/FloatNegTest.java + graal/com.oracle.graal.compiler.hsail.test/src/com/oracle/graal/compiler/hsail/test/IntBitwiseNotTest.java + graal/com.oracle.graal.compiler.hsail.test/src/com/oracle/graal/compiler/hsail/test/IntBitwiseShiftLeftTest.java + graal/com.oracle.graal.compiler.hsail.test/src/com/oracle/graal/compiler/hsail/test/IntBitwiseShiftRightTest.java + graal/com.oracle.graal.compiler.hsail.test/src/com/oracle/graal/compiler/hsail/test/IntBitwiseShiftRightUnsignedTest.java + graal/com.oracle.graal.compiler.hsail.test/src/com/oracle/graal/compiler/hsail/test/IntNegTest.java + graal/com.oracle.graal.compiler.hsail.test/src/com/oracle/graal/compiler/hsail/test/LongBitwiseNotTest.java + graal/com.oracle.graal.compiler.hsail.test/src/com/oracle/graal/compiler/hsail/test/LongBitwiseShiftLeftTest.java + graal/com.oracle.graal.compiler.hsail.test/src/com/oracle/graal/compiler/hsail/test/LongBitwiseShiftRightTest.java + graal/com.oracle.graal.compiler.hsail.test/src/com/oracle/graal/compiler/hsail/test/LongBitwiseShiftRightUnsignedTest.java + graal/com.oracle.graal.compiler.hsail.test/src/com/oracle/graal/compiler/hsail/test/LongNegTest.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/HSAILArithmetic.java ! graal/com.oracle.graal.lir.hsail/src/com/oracle/graal/lir/hsail/HSAILControlFlow.java Changeset: 0dd597c6c9c7 Author: Doug Simon Date: 2013-11-01 13:07 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/0dd597c6c9c7 fixed performance regression in hosted CompileTheWorld ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/bridge/VMToCompiler.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/bridge/VMToCompilerImpl.java ! src/share/vm/classfile/vmSymbols.hpp ! src/share/vm/graal/graalCompiler.cpp ! src/share/vm/graal/graalVMToCompiler.cpp ! src/share/vm/graal/graalVMToCompiler.hpp From Vasanth.Venkatachalam at amd.com Fri Nov 1 08:54:23 2013 From: Vasanth.Venkatachalam at amd.com (Venkatachalam, Vasanth) Date: Fri, 1 Nov 2013 15:54:23 +0000 Subject: webrev for remaining bitwise operators and arithmetic negation Message-ID: <5DD1503F815BD14889DC81D28643E3A7553AB67B@SATLEXDAG02.amd.com> Hi Doug, Thanks for the feedback. I gather from below that you will proceed to integrate the patch making these changes along the way. If I need to do anything on my end, please let me know. Please attribute the patch to Vasanth Venkatachalam. Commit message: Adds support to the HSAIL backend for arithmetic negation and two of the bitwise logical operators, bitwise shift right (>>), and bitwise NOT (~) Vasanth -----Original Message----- From: Doug Simon [mailto:doug.simon at oracle.com] Sent: Friday, November 01, 2013 5:46 AM To: Venkatachalam, Vasanth Cc: graal-dev at openjdk.java.net; dl.Runtimes Subject: Re: webrev for remaining bitwise operators and arithmetic negation Somewhat related to Christian's comment, please don't use javadoc style comments where they are not applicable. graal/com.oracle.graal.asm.hsail/src/com/oracle/graal/asm/hsail/HSAILAssembler.java: + private void emitTextFormattedInstruction(String instr, Value dest, Value... sources) { + /** + * Destination can't be a constant and no instruction has > 3 source operands. + */ + assert (!isConstant(dest) && sources.length <= 3); Javadoc comments cannot be applied to statements. Otherwise, the patch looks fine. I'll integrate it and fix up these comments along the way. -Doug On Oct 31, 2013, at 11:24 PM, Venkatachalam, Vasanth wrote: > Hi, > > I've uploaded a webrev that extends the HSAIL backend to generate code for bitwise right shift (>>), bitwise NOT (~), and arithmetic negation. > > http://cr.openjdk.java.net/~tdeneau/webrev-bitwiseopsupport-parttwo.01/webrev/ > > Please review and provide feedback. > > Summary of main changes. > > > * In HSAILLIRGenerator. Java I extended the implementation of the emitNegate, emitNot and emitShr routines to handle cases that weren't previously being covered. I then made supporting changes to HSAILArithmetic.java and HSAILAssembler.java. > > * I added unit test cases in compiler/hsail/test for left shift (<<), right shift (>>), unsigned right shift(>>>) and integer negation. > > * I refactored the emit routines in HSAILAssembler which were calling emitString. We previously had multiple of these routines taking different number of source operands. I was able to coalesce these into a single routine (renamed emitTextFormattedInstruction) taking variable number of source operands. This makes the code more readable but doesn't impact functionality. > > * A stylistic change. I rearranged the opcode values in the HSAILArithmetic enum to appear in alphabetical order for easier readability. > > * I've run this code through the eclipse 4.3 formatter and didn't see any changes in files that are part of this webrev. I've also tested the webrev against the latest OpenJDK version of the trunk. > > Vasanth From Eric.Caspole at amd.com Fri Nov 1 11:02:29 2013 From: Eric.Caspole at amd.com (Caspole, Eric) Date: Fri, 1 Nov 2013 18:02:29 +0000 Subject: NetBeans 7.4 mx ideinit problem Message-ID: Hi, I might be the only one, but I have been using the NetBeans 7.4 with Graal on Windows for months now using JDK 8. It has been working well to run the unit tests etc in our JDK 8 environment. Very recently the build stopped working correctly in NetBeans and the project group import seems flaky. It looks like the Java Platform is not set correctly for the projects, where I have set up the JDK as shown If using NetBeans: 1. Ensure that a platform named "JDK_1.8.0-internal-fastdebug" is defined (Tools -> Java Platforms) 2. Open/create a Project Group for the directory containing the projects (File -> Project Group -> New Group... -> Folder of Projects) But all the Graal projects have the default Java Platform selected as their JDK after I create the project group, not the newly created one. I get the message below when I right-click on a project and select "Build" I don't know if this is a NetBeans bug or a problem with the "mx ideinit" output. Anyone have any suggestions? Thanks, Eric ===== ant -f C:\\work\\graal-default\\graal\\graal\\com.oracle.graal.compiler -Dnb.internal.action.name=build jar C:\work\graal-default\graal\graal\com.oracle.graal.compiler\nbproject\build-impl.xml:86: The J2SE Platform is not correctly set up. Your active platform is: ${platform.active}, but the corresponding property "platforms.${platform.active}.home" is not found in the project's properties files. Either open the project in the IDE and setup the Platform with the same name or add it manually. For example like this: ant -Duser.properties.file= jar (where you put the property "platforms.${platform.active}.home" in a .properties file) or ant -Dplatforms.${platform.active}.home= jar (where no properties file is used) BUILD FAILED (total time: 0 seconds) From mick.jordan at oracle.com Fri Nov 1 11:11:16 2013 From: mick.jordan at oracle.com (Mick Jordan) Date: Fri, 01 Nov 2013 11:11:16 -0700 Subject: NetBeans 7.4 mx ideinit problem In-Reply-To: References: Message-ID: <5273EEC4.40205@oracle.com> On 11/1/13 11:02 AM, Caspole, Eric wrote: > > I don't know if this is a NetBeans bug or a problem with the "mx ideinit" output. > Anyone have any suggestions? > There have been changes in the ideinit area recently, so it could well be a bug in mx. I don't use Netbeans myself but what we want to see probably is the config files that get generated by mx. One thing you might be able to do is clone an older version of the repo, say a month ago, and run mx ideinit in there and compare the config files. Try the revision before the none that has the comment: "Allow mxtool suites to be in separate repositories (CR-1367)", which was Sep 11. From eric.caspole at amd.com Fri Nov 1 11:50:17 2013 From: eric.caspole at amd.com (Eric Caspole) Date: Fri, 1 Nov 2013 14:50:17 -0400 Subject: NetBeans 7.4 mx ideinit problem In-Reply-To: <5273EEC4.40205@oracle.com> References: <5273EEC4.40205@oracle.com> Message-ID: <5273F7E9.8020802@amd.com> I found that I can go into NetBeans and right click on each project and manually set the JDK correctly, and then it seems to work OK, although that is very time consuming with so many projects. I never see this problem on Linux, BTW. Is the "mx ideinit" different between Windows/Linux? Eric On 11/01/2013 02:11 PM, Mick Jordan wrote: > On 11/1/13 11:02 AM, Caspole, Eric wrote: >> >> I don't know if this is a NetBeans bug or a problem with the "mx >> ideinit" output. >> Anyone have any suggestions? >> > There have been changes in the ideinit area recently, so it could well > be a bug in mx. I don't use Netbeans myself but what we want to see > probably is the config files that get generated by mx. > > One thing you might be able to do is clone an older version of the repo, > say a month ago, and run mx ideinit in there and compare the config > files. Try the revision before the none that has the comment: > > "Allow mxtool suites to be in separate repositories (CR-1367)", which > was Sep 11. > > > > From doug.simon at oracle.com Fri Nov 1 13:50:35 2013 From: doug.simon at oracle.com (Doug Simon) Date: Fri, 1 Nov 2013 21:50:35 +0100 Subject: NetBeans 7.4 mx ideinit problem In-Reply-To: <5273F7E9.8020802@amd.com> References: <5273EEC4.40205@oracle.com> <5273F7E9.8020802@amd.com> Message-ID: <6D9FDA12-E124-4394-AB69-C8A513ACA2B5@oracle.com> Does this help: 1. In NetBeans: File -> Project Group -> Remove ?graal? 2. mx ideclean 3. mx fsck (answer yes to all) 4. mx netbeansinit 5. In NetBeans: File -> Project Group -> New Group... -> Folder Of Projects It seems that NetBeans does not react to well to having projects disappear from behind its back (which can happen when you pull changes that delete/rename/create projects). -Doug On Nov 1, 2013, at 7:50 PM, Eric Caspole wrote: > I found that I can go into NetBeans and right click on each project and manually set the JDK correctly, and then it seems to work OK, although that is very time consuming with so many projects. > > I never see this problem on Linux, BTW. Is the "mx ideinit" different between Windows/Linux? > Eric > > On 11/01/2013 02:11 PM, Mick Jordan wrote: >> On 11/1/13 11:02 AM, Caspole, Eric wrote: >>> >>> I don't know if this is a NetBeans bug or a problem with the "mx >>> ideinit" output. >>> Anyone have any suggestions? >>> >> There have been changes in the ideinit area recently, so it could well >> be a bug in mx. I don't use Netbeans myself but what we want to see >> probably is the config files that get generated by mx. >> >> One thing you might be able to do is clone an older version of the repo, >> say a month ago, and run mx ideinit in there and compare the config >> files. Try the revision before the none that has the comment: >> >> "Allow mxtool suites to be in separate repositories (CR-1367)", which >> was Sep 11. >> >> >> >> > From tom.deneau at amd.com Fri Nov 1 15:54:10 2013 From: tom.deneau at amd.com (Deneau, Tom) Date: Fri, 1 Nov 2013 22:54:10 +0000 Subject: webrev for hsail backend merging with new providers infrastructure Message-ID: All -- I have posted a small webrev to http://cr.openjdk.java.net/~tdeneau/graal-webrevs/webrev-infrastructure-merge/webrev/ This is the result of our merge with the recent providers infrastructure. Could you please look this over? Here is a brief summary: HSAILHotSpotForeignCallsProvider.java ------------------------------------- . As noted in the comments,?? we don't really support foreign calls yet, ?yet we do get asked to handle ForeignCall nodes, and we want to generate dummy code for them. We just support them all and lazily create dummy linkages here.? When we finally support foreign calls we will explicitly register the ones we want to support. HSAILHotSpotLIRGenerator.java, HSAILLIRGenerator.java, HSAILControlFlow.java ---------------------------------------------------------------------------- . This again is part of the dummy Foreign Call support. ??Some less extensive ForeignCall support used to be in HSAILLIRGenerator. HSAILHotSpotReplacementsImpl.java --------------------------------- . This is another one of the providers in the new runtime infrastructure.? For both macro substitutions and method substitutions, we just delegate to the host substitution list.? This is a quick solution which allows things like Math.sqrt, and some of the Unsafe methods to work for HSAIL, similar to the way these substitutions worked before the providers change.? Eventually, we will explicitly list which substitutions we will support. HSAIL.java ---------- . Not really part of the webrev infrastructure merge but since we're planning to limit the number of registers actually used by the graal compiler, it seemed appropriate to push this out. Tests ----- . With the ForeignCall support above, some test cases that were marked as failing are now passing. KernelTester.java ----------------- . Not really part of the webrev infrastructure merge but added a property to allow running the gpu code either first or second vs. the java code in our test cases. -- Tom Deneau From doug.simon at oracle.com Sat Nov 2 19:00:09 2013 From: doug.simon at oracle.com (doug.simon at oracle.com) Date: Sun, 03 Nov 2013 02:00:09 +0000 Subject: hg: graal/graal: 2 new changesets Message-ID: <20131103020030.328F66293D@hg.openjdk.java.net> Changeset: 1a7e7011a341 Author: S.Bharadwaj Yadavalli Date: 2013-11-01 18:34 -0400 URL: http://hg.openjdk.java.net/graal/graal/rev/1a7e7011a341 * PTX kernel argument buffer now has naturally aligned arguments as required by PTX JIT compiler. * Change dynamic loading of CUDA driver API functions to load 32-bit or 64-bit versions of depending on the the host architecture. * Add ability to generate PTX kernels to be launched both on 32-bit and 64-bit hosts. * Use Unified Virtual Memory APIs to perform array argument marshalling. * PTX array storage test runs on the device and returns correct results. * More integer test failures on GPU fixed. ! graal/com.oracle.graal.asm.ptx/src/com/oracle/graal/asm/ptx/PTXAssembler.java ! graal/com.oracle.graal.compiler.ptx.test/src/com/oracle/graal/compiler/ptx/test/ArrayPTXTest.java ! graal/com.oracle.graal.hotspot.ptx/src/com/oracle/graal/hotspot/ptx/PTXHotSpotBackend.java ! graal/com.oracle.graal.lir.ptx/src/com/oracle/graal/lir/ptx/PTXMemOp.java ! src/gpu/ptx/vm/gpu_ptx.cpp ! src/gpu/ptx/vm/gpu_ptx.hpp ! src/gpu/ptx/vm/ptxKernelArguments.cpp ! src/gpu/ptx/vm/ptxKernelArguments.hpp ! src/share/vm/graal/graalCompilerToGPU.cpp Changeset: 1c0261ebeeed Author: twisti Date: 2013-11-01 19:35 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/1c0261ebeeed use getAddress instead of getLong in HotSpotResolvedJavaMethod ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotResolvedJavaMethod.java From ndrzmansn at gmail.com Sun Nov 3 11:25:49 2013 From: ndrzmansn at gmail.com (Wei Zhang) Date: Sun, 3 Nov 2013 11:25:49 -0800 Subject: Truffle Node replacement problem caused by recursion In-Reply-To: References: <274BA668-5EC1-4108-B129-0A60918A313D@stefan-marr.de> Message-ID: Hi Andreas, The fix worked for me. Now I don't have to do anything special when rewriting. Thanks and take care! /Wei --------------------------------------------------------------------------- Message: 3 Date: Tue, 29 Oct 2013 18:32:42 +0100 From: Andreas Woess Subject: Re: Truffle Node replacement problem caused by recursion To: graal-dev at openjdk.java.net Message-ID: <526FF13A.90401 at jku.at> Content-Type: text/plain; charset=UTF-8 Hi Wei, Stefan, et al, I've pushed a fix about a week ago that solves this problem including an assertion that should trigger if you do anything wrong. Please update and let me know whether everything works as expected now. - andreas -------------------------- Wei Zhang Personal: NdrZmansN at Gmail.com On Mon, Oct 21, 2013 at 7:10 AM, Thomas Wuerthinger wrote: > Thanks both Wei and Stefan for describing the issue. We are currently experimenting with various possible of fixes (this is why you can see change sets being pushed and backed out again ;)). Andreas is going to post a description of the solution once we are confident that we have solved the problem. - thomas > > On Oct 19, 2013, at 6:53 PM, Stefan Marr wrote: > >> Hi Wei: >> >> On 19 Oct 2013, at 01:44, Wei Zhang wrote: >> >>> Hi guys, >>> >>> I came across a problem with Truffle node replacement when I was >>> trying to apply Python level inlining to binarytrees.py (one of the >>> shootout benchmarks). I thought it is worth sharing it with all of you >>> that are using Truffle. >>> >>> Basically, recursion might cause inconsistencies in a Truffle AST. >>> That is a node's parent's children don't include itself. >> >> I had similar issues. A simple fibonacci function is a good example. >> The plus operation got specialized in a recursive call, and the unspecialized plus node was still on the Java call stack and tried to specialize itself after completing execution of its arguments. >> >> My solution first was based on remembering in the node that it got specialized. >> See [1] and [2] for the code in my nodes. >> >> However, after I switched to using the Truffle DSL, that problem went away. Don't know exactly why. >> >> And even more mysterious is a commit that was done by Andreas recently and later reverted: [3] "Truffle: fix node rewrite issue that can occur when a currently executing node is replaced in a recursive call." >> Not sure why it got reverted later on, but since I am not experiencing the issue anymore, I hope it is solved somehow by the Truffle DSL implementation. >> >> Best regards >> Stefan >> >> [1] https://github.com/smarr/TruffleSOM/blob/bf97e05836c0c9c9647b41e6da305c007ac94236/src/som/interpreter/nodes/MessageNode.java#L141 >> [2] https://github.com/smarr/TruffleSOM/blob/bf97e05836c0c9c9647b41e6da305c007ac94236/src/som/interpreter/nodes/MessageNode.java#L257 >> >> [3] http://hg.openjdk.java.net/graal/graal/rev/be0a33a631fa >> >> -- >> Stefan Marr >> Software Languages Lab >> Vrije Universiteit Brussel >> Pleinlaan 2 / B-1050 Brussels / Belgium >> http://soft.vub.ac.be/~smarr >> Phone: +32 2 629 2974 >> Fax: +32 2 629 3525 >> > From thomas.wuerthinger at oracle.com Sun Nov 3 16:17:10 2013 From: thomas.wuerthinger at oracle.com (Thomas Wuerthinger) Date: Sun, 3 Nov 2013 16:17:10 -0800 Subject: Result: New graal Committer: Bharadwaj Yadavalli Message-ID: <8BA811D8-AC0C-4F8A-BC66-148E6F50E43B@oracle.com> Voting for Bharadwaj Yadavalli [1] is now closed. Yes: 7 Veto: 0 Abstain: 0 According to the Bylaws definition of Lazy Consensus, this is sufficient to approve the nomination. Thomas Wuerthinger [1] http://mail.openjdk.java.net/pipermail/graal-dev/2013-September/000886.html From java at stefan-marr.de Mon Nov 4 04:24:10 2013 From: java at stefan-marr.de (Stefan Marr) Date: Mon, 4 Nov 2013 13:24:10 +0100 Subject: Truffle: executeCached, get, and other abstract methods? And a little generator bug. Message-ID: Hi: I found another useful abstract method in truffle node classes: executeCachedGeneric, which allows me to execute the code of a specialized node after replacing a more general one. After inspecting the generator code, I also found that executeCached* is probably working also for other kind of specializations. And since there are also the accessors for node children (get$childName), I was wondering whether the TruffleDSL has other similar gems hidden in it, which might be useful? As a related note, I also saw a null pointer exception that can be reproduced with the code snippet below. Best regards Stefan package som.interpreter.nodes.specialized; import som.interpreter.Types; import som.interpreter.nodes.ExpressionNode; import som.vmobjects.SAbstractObject; import com.oracle.truffle.api.dsl.NodeChild; import com.oracle.truffle.api.dsl.Specialization; import com.oracle.truffle.api.dsl.TypeSystemReference; import com.oracle.truffle.api.frame.VirtualFrame; import com.oracle.truffle.api.nodes.Node; @TypeSystemReference(Types.class) @NodeChild(value = "receiver", type = ExpressionNode.class) public abstract class TestNode extends Node { public abstract SAbstractObject executeCachedGeneric(final VirtualFrame frame, final Object receiver); @Specialization public SAbstractObject doGeneric(final VirtualFrame frame, final SAbstractObject receiver) { return null; } } -- Stefan Marr Software Languages Lab Vrije Universiteit Brussel Pleinlaan 2 / B-1050 Brussels / Belgium http://soft.vub.ac.be/~smarr Phone: +32 2 629 2974 Fax: +32 2 629 3525 From doug.simon at oracle.com Mon Nov 4 07:23:09 2013 From: doug.simon at oracle.com (Doug Simon) Date: Mon, 4 Nov 2013 16:23:09 +0100 Subject: webrev for hsail backend merging with new providers infrastructure In-Reply-To: References: Message-ID: Looks good - I?ll integrate it and push it through. On Nov 1, 2013, at 11:54 PM, Deneau, Tom wrote: > All -- > > I have posted a small webrev to > http://cr.openjdk.java.net/~tdeneau/graal-webrevs/webrev-infrastructure-merge/webrev/ > > This is the result of our merge with the recent providers infrastructure. Could you please look this over? > > Here is a brief summary: > > > HSAILHotSpotForeignCallsProvider.java > ------------------------------------- > . As noted in the comments, we don't really support foreign calls yet, yet we do get asked to handle ForeignCall nodes, and we want to generate dummy code for them. We just support them all and lazily create dummy linkages here. When we finally support foreign calls we will explicitly register the ones we want to support. > > HSAILHotSpotLIRGenerator.java, HSAILLIRGenerator.java, HSAILControlFlow.java > ---------------------------------------------------------------------------- > . This again is part of the dummy Foreign Call support. Some less extensive ForeignCall support used to be in HSAILLIRGenerator. > > HSAILHotSpotReplacementsImpl.java > --------------------------------- > . This is another one of the providers in the new runtime infrastructure. For both macro substitutions and method substitutions, we just delegate to the host substitution list. This is a quick solution which allows things like Math.sqrt, and some of the Unsafe methods to work for HSAIL, similar to the way these substitutions worked before the providers change. Eventually, we will explicitly list which substitutions we will support. > > HSAIL.java > ---------- > . Not really part of the webrev infrastructure merge but since we're planning to limit the number of registers actually used by the graal compiler, it seemed appropriate to push this out. > > Tests > ----- > . With the ForeignCall support above, some test cases that were marked as failing are now passing. > > KernelTester.java > ----------------- > . Not really part of the webrev infrastructure merge but added a property to allow running the gpu code either first or second vs. the java code in our test cases. > > > -- Tom Deneau > > From doug.simon at oracle.com Mon Nov 4 07:30:21 2013 From: doug.simon at oracle.com (Doug Simon) Date: Mon, 4 Nov 2013 16:30:21 +0100 Subject: webrev for hsail backend merging with new providers infrastructure In-Reply-To: References: Message-ID: <0DB6F95F-9B2F-42BC-B29D-7CCA428C2CC0@oracle.com> Actually, one quick question: Do we really need the VECMATH and APACHELANG libraries declared in mx/projects[1]? None of the projects seem to use them. -Doug [1] http://cr.openjdk.java.net/~tdeneau/graal-webrevs/webrev-infrastructure-merge/webrev/mx/projects.udiff.html On Nov 1, 2013, at 11:54 PM, Deneau, Tom wrote: > All -- > > I have posted a small webrev to > http://cr.openjdk.java.net/~tdeneau/graal-webrevs/webrev-infrastructure-merge/webrev/ > > This is the result of our merge with the recent providers infrastructure. Could you please look this over? > > Here is a brief summary: > > > HSAILHotSpotForeignCallsProvider.java > ------------------------------------- > . As noted in the comments, we don't really support foreign calls yet, yet we do get asked to handle ForeignCall nodes, and we want to generate dummy code for them. We just support them all and lazily create dummy linkages here. When we finally support foreign calls we will explicitly register the ones we want to support. > > HSAILHotSpotLIRGenerator.java, HSAILLIRGenerator.java, HSAILControlFlow.java > ---------------------------------------------------------------------------- > . This again is part of the dummy Foreign Call support. Some less extensive ForeignCall support used to be in HSAILLIRGenerator. > > HSAILHotSpotReplacementsImpl.java > --------------------------------- > . This is another one of the providers in the new runtime infrastructure. For both macro substitutions and method substitutions, we just delegate to the host substitution list. This is a quick solution which allows things like Math.sqrt, and some of the Unsafe methods to work for HSAIL, similar to the way these substitutions worked before the providers change. Eventually, we will explicitly list which substitutions we will support. > > HSAIL.java > ---------- > . Not really part of the webrev infrastructure merge but since we're planning to limit the number of registers actually used by the graal compiler, it seemed appropriate to push this out. > > Tests > ----- > . With the ForeignCall support above, some test cases that were marked as failing are now passing. > > KernelTester.java > ----------------- > . Not really part of the webrev infrastructure merge but added a property to allow running the gpu code either first or second vs. the java code in our test cases. > > > -- Tom Deneau > > From christian.humer at gmail.com Mon Nov 4 07:50:00 2013 From: christian.humer at gmail.com (Christian Humer) Date: Mon, 4 Nov 2013 16:50:00 +0100 Subject: Truffle: executeCached, get, and other abstract methods? And a little generator bug. In-Reply-To: <60F35720-B657-476D-96E5-AA870765DF72@vub.ac.be> References: <60F35720-B657-476D-96E5-AA870765DF72@vub.ac.be> Message-ID: Hi Stefan, The generated methods named executeCached* are not intended to be used from your code and are entirely an implementation detail. So they are subject of change or removal any time. Actually its a bug that you are able to access it. I will try to give you some insight on these executeCached* methods and why they are generated, further below. I think, the feature you need is the generation of execute methods with evaluated children. This is also the feature you are already using, but the method should not be called executeCached* but instead executeEvaluated or something different. I will try to give you a brief introduction to this feature: An execute method is the contract to the parent node on how to be executed. The code generator for the DSL parses the execute methods that a node declares and tries to generate an implementation for them. So usually one would provide execute methods in a node or better in its base class like this: @NodeChild(value = "receiver", type = TestNode .class) public abstract class TestNode extends Node { public abstract Object execute(VirtualFrame frame); // ... specialiations omitted ... } The code generator would now see the execute methods and will generate implementation code for it in generated subclasses. In this case the generated code for the execute method would look like: @Override public Object execute(VirtualFrame frame) { Object receiverValue = receiver.execute(frame); // call to proper specialization(s) with receiverValue } But the code generator also supports additional execute methods with evaluated arguments like this: @NodeChild(value = "receiver", type = TestNode .class) public abstract class TestNode extends Node { public abstract Object execute(VirtualFrame frame); public abstract Object executeEvaluated(VirtualFrame frame, Object receiverValue); // ... specialiations omitted ... } In this case the generated implementation of executeEvaluated would look like this: @Override public Object executeEvaluated(VirtualFrame frame, Object receiverEvaluated) { Object receiverValue = receiverEvaluated; // call to proper specialization(s) with receiverValue } The code generator also supports other signatures for execute methods like: public abstract int executeInt(VirtualFrame frame) throws UnexpectedResultException; public abstract Object executeEvaluated(VirtualFrame frame, int receiverEvaluated); public abstract int executeIntEvaluated(VirtualFrame frame, Object receiverEvaluated) throws UnexpectedResultException; And it also works for any number of evaluated values. I hope this answers your question. There are just these two magic features (the rest is more explicit using annotations): Getters for fields/children and the automatic implementation of execute methods. While the first is a convenience feature the second is an essential part of the DSL. So now some insight on these generated executeCachedGeneric methods. These methods are used to implement the polymorphic chain of specializations. So imagine you have an operation node which defines a lot of different specializations. Some of them may be specializations for type int, double or String. When we create a node using the generated factory it starts off in the uninitialized state. When its first invoked the node replaces itself to a node just compatible to one specialization, lets assume an int specialization. We also call this state the monomorphic state. If the node is now executed again and a double value comes in from the child we do not want to go directly to a generic case because this would also contain the code for the String specialization. Instead we build up a polymorphic chain which just contains code for the int and double specialization. This is called the polymorphic state. After some depth of the polymorphic chain (which is optionally configurable by @PolymorphicDepth on the operation node) is reached, we rewrite to the generic case which we also call the megamorphic state. Lets illustrate how the node tree looks in each state for an operation node called MyNode with one arbitrary child operand: State Uninitialized: UninitializedMyNode operand = ... State Monomorphic: IntMyNode operand = ... State Polymorphic : PolymorphicMyNode operand = ... next0 =IntMyNode next0= DoubleMyNode next0 = UninitializedMyNode State Megamorphic: GenericMyNode operand = ... When the PolymorphicMyNode now gets called by its parent using an execute method it first executes its child operand. It then calls the first element of the polymorphic chain which is IntMyNode using executeChachedGeneric with the evaluated value of operand. The implementation of executeChachedGeneric in IntMyNode will then check if the value is compatible to this specialization and invoke the specialization if so. If not it will just call the next specialization in the chain stored in the next0 field. If an UninitializedMyNode is reached another entry to the polymorphic chain is added or if the maximum depth was reached the whole tree gets rewritten to GenericMyNode. Regarding the NPE: Null is not supported as a value by the DSL at them moment (but it is supported by Truffle in general). If you want to represent null using the DSL, use a singleton value like MyNull.INSTANCE. It should not make a difference performance wise. It is on my list of things I want to add support for at some point. Please tell me if you need it. In this case I can try to give it a higher priority. Cheers, - Christian Humer On Mon, Nov 4, 2013 at 12:49 PM, Stefan Marr wrote: > Hi: > > I found another useful abstract method in truffle node classes: > executeCachedGeneric, which allows me to execute the code of a specialized > node after replacing a more general one. > After inspecting the generator code, I also found that executeCached* is > probably working also for other kind of specializations. > > And since there are also the accessors for node children (get$childName), > I was wondering whether the TruffleDSL has other similar gems hidden in > it, which might be useful? > > As a related note, I also saw a null pointer exception that can be > reproduced with the code snippet below. > > Best regards > Stefan > > > package som.interpreter.nodes.specialized; > > import som.interpreter.Types; > import som.interpreter.nodes.ExpressionNode; > import som.vmobjects.SAbstractObject; > > import com.oracle.truffle.api.dsl.NodeChild; > import com.oracle.truffle.api.dsl.Specialization; > import com.oracle.truffle.api.dsl.TypeSystemReference; > import com.oracle.truffle.api.frame.VirtualFrame; > import com.oracle.truffle.api.nodes.Node; > > @TypeSystemReference(Types.class) > @NodeChild(value = "receiver", type = ExpressionNode.class) > public abstract class TestNode extends Node { > public abstract SAbstractObject executeCachedGeneric(final VirtualFrame > frame, final Object receiver); > > @Specialization > public SAbstractObject doGeneric(final VirtualFrame frame, > final SAbstractObject receiver) { > return null; > } > } > > > -- > Stefan Marr > Software Languages Lab > Vrije Universiteit Brussel > Pleinlaan 2 / B-1050 Brussels / Belgium > http://soft.vub.ac.be/~smarr > Phone: +32 2 629 2974 > Fax: +32 2 629 3525 > > From tom.deneau at amd.com Mon Nov 4 08:27:23 2013 From: tom.deneau at amd.com (Deneau, Tom) Date: Mon, 4 Nov 2013 16:27:23 +0000 Subject: webrev for hsail backend merging with new providers infrastructure In-Reply-To: <0DB6F95F-9B2F-42BC-B29D-7CCA428C2CC0@oracle.com> References: <0DB6F95F-9B2F-42BC-B29D-7CCA428C2CC0@oracle.com> Message-ID: Hi Doug -- Some of our java 8 based unit tests (which use lambdas) use these two libraries currently, but you're right we don't use them in the java 7 based tests yet. If you want to remove them from the public mx/projects, go ahead. This points to a hole in our testing strategy which we've always been aware of. We have written a number of java 8 style unit tests that we test locally here but that don't get exercised in the public repository. We could of course add similar java 7 based unit tests and push them to public but we haven't done that work, and if graal is going to support 8 soon, there wouldn't be a need for that conversion work. On a related note, I think Vasanth mentioned that we run our unit tests locally here with the flags -G:+InlineEverything -G:-RemoveNeverExecutedCode. We need InlineEverything because we don't support HSAIL function calls yet. Several test cases have a line like assumeTrue(aggressiveInliningEnabled()); and of course these just get skipped if -G:+InlineEverything is not set. Is it possible to get the hsail tests that get run at Oracle to use these two flags? -- Tom -----Original Message----- From: Doug Simon [mailto:doug.simon at oracle.com] Sent: Monday, November 04, 2013 9:30 AM To: Deneau, Tom Cc: graal-dev at openjdk.java.net Subject: Re: webrev for hsail backend merging with new providers infrastructure Actually, one quick question: Do we really need the VECMATH and APACHELANG libraries declared in mx/projects[1]? None of the projects seem to use them. -Doug [1] http://cr.openjdk.java.net/~tdeneau/graal-webrevs/webrev-infrastructure-merge/webrev/mx/projects.udiff.html On Nov 1, 2013, at 11:54 PM, Deneau, Tom wrote: > All -- > > I have posted a small webrev to > http://cr.openjdk.java.net/~tdeneau/graal-webrevs/webrev-infrastructure-merge/webrev/ > > This is the result of our merge with the recent providers infrastructure. Could you please look this over? > > Here is a brief summary: > > > HSAILHotSpotForeignCallsProvider.java > ------------------------------------- > . As noted in the comments, we don't really support foreign calls yet, yet we do get asked to handle ForeignCall nodes, and we want to generate dummy code for them. We just support them all and lazily create dummy linkages here. When we finally support foreign calls we will explicitly register the ones we want to support. > > HSAILHotSpotLIRGenerator.java, HSAILLIRGenerator.java, HSAILControlFlow.java > ---------------------------------------------------------------------------- > . This again is part of the dummy Foreign Call support. Some less extensive ForeignCall support used to be in HSAILLIRGenerator. > > HSAILHotSpotReplacementsImpl.java > --------------------------------- > . This is another one of the providers in the new runtime infrastructure. For both macro substitutions and method substitutions, we just delegate to the host substitution list. This is a quick solution which allows things like Math.sqrt, and some of the Unsafe methods to work for HSAIL, similar to the way these substitutions worked before the providers change. Eventually, we will explicitly list which substitutions we will support. > > HSAIL.java > ---------- > . Not really part of the webrev infrastructure merge but since we're planning to limit the number of registers actually used by the graal compiler, it seemed appropriate to push this out. > > Tests > ----- > . With the ForeignCall support above, some test cases that were marked as failing are now passing. > > KernelTester.java > ----------------- > . Not really part of the webrev infrastructure merge but added a property to allow running the gpu code either first or second vs. the java code in our test cases. > > > -- Tom Deneau > > From Vasanth.Venkatachalam at amd.com Mon Nov 4 08:36:45 2013 From: Vasanth.Venkatachalam at amd.com (Venkatachalam, Vasanth) Date: Mon, 4 Nov 2013 16:36:45 +0000 Subject: testing new Graal backends for Java conformance Message-ID: <5DD1503F815BD14889DC81D28643E3A7553ABBC9@SATLEXDAG02.amd.com> Doug or others- Do you have a way of testing new backends that are developed for Graal for Java compliance (against the TCK)? If so, can you explain how we can plug our HSAIL backend into this process so that it also gets tested for Java compliance? A related question has to do with unit testing. So far we've been writing separate unit tests (in compiler.hsail.test) for each new Java operator that we add support for (e.g., +, -, *) as well as program constructs (e.g., conditionals, loops) to ensure that we are generating the correct code. Is there already a common infrastructure in Graal that could be leveraged for this purpose? On a related note, can you explain at a high level how you are ensuring that you have complete testing coverage (for the x86 code gen) in compiler.test/ ? Vasanth From doug.simon at oracle.com Mon Nov 4 09:19:52 2013 From: doug.simon at oracle.com (Doug Simon) Date: Mon, 4 Nov 2013 18:19:52 +0100 Subject: webrev for hsail backend merging with new providers infrastructure In-Reply-To: References: <0DB6F95F-9B2F-42BC-B29D-7CCA428C2CC0@oracle.com> Message-ID: On Nov 4, 2013, at 5:27 PM, Deneau, Tom wrote: > Hi Doug -- > > Some of our java 8 based unit tests (which use lambdas) use these two libraries currently, but you're right we don't use them in the java 7 based tests yet. If you want to remove them from the public mx/projects, go ahead. > > This points to a hole in our testing strategy which we've always been aware of. We have written a number of java 8 style unit tests that we test locally here but that don't get exercised in the public repository. We could of course add similar java 7 based unit tests and push them to public but we haven't done that work, and if graal is going to support 8 soon, there wouldn't be a need for that conversion work. Yes, I suggest to keep just running these tests locally until Graal has transitioned to 8. > On a related note, I think Vasanth mentioned that we run our unit tests locally here with the flags -G:+InlineEverything -G:-RemoveNeverExecutedCode. We need InlineEverything because we don't support HSAIL function calls yet. Several test cases have a line like > assumeTrue(aggressiveInliningEnabled()); > > and of course these just get skipped if -G:+InlineEverything is not set. Is it possible to get the hsail tests that get run at Oracle to use these two flags? We don?t currently have infrastructure for running tests in a different VM instances based on required command line option settings. What we ideally want (in this case at least) is for options such as InlineEverything and RemoveNeverExecutedCode to be overridable in a scoped manner (e.g., for individual compilations). Until we have support for this however, we?ll have to rely on your testing setup to run these tests. -Doug > -----Original Message----- > From: Doug Simon [mailto:doug.simon at oracle.com] > Sent: Monday, November 04, 2013 9:30 AM > To: Deneau, Tom > Cc: graal-dev at openjdk.java.net > Subject: Re: webrev for hsail backend merging with new providers infrastructure > > Actually, one quick question: Do we really need the VECMATH and APACHELANG libraries declared in mx/projects[1]? None of the projects seem to use them. > > -Doug > > [1] http://cr.openjdk.java.net/~tdeneau/graal-webrevs/webrev-infrastructure-merge/webrev/mx/projects.udiff.html > > On Nov 1, 2013, at 11:54 PM, Deneau, Tom wrote: > >> All -- >> >> I have posted a small webrev to >> http://cr.openjdk.java.net/~tdeneau/graal-webrevs/webrev-infrastructure-merge/webrev/ >> >> This is the result of our merge with the recent providers infrastructure. Could you please look this over? >> >> Here is a brief summary: >> >> >> HSAILHotSpotForeignCallsProvider.java >> ------------------------------------- >> . As noted in the comments, we don't really support foreign calls yet, yet we do get asked to handle ForeignCall nodes, and we want to generate dummy code for them. We just support them all and lazily create dummy linkages here. When we finally support foreign calls we will explicitly register the ones we want to support. >> >> HSAILHotSpotLIRGenerator.java, HSAILLIRGenerator.java, HSAILControlFlow.java >> ---------------------------------------------------------------------------- >> . This again is part of the dummy Foreign Call support. Some less extensive ForeignCall support used to be in HSAILLIRGenerator. >> >> HSAILHotSpotReplacementsImpl.java >> --------------------------------- >> . This is another one of the providers in the new runtime infrastructure. For both macro substitutions and method substitutions, we just delegate to the host substitution list. This is a quick solution which allows things like Math.sqrt, and some of the Unsafe methods to work for HSAIL, similar to the way these substitutions worked before the providers change. Eventually, we will explicitly list which substitutions we will support. >> >> HSAIL.java >> ---------- >> . Not really part of the webrev infrastructure merge but since we're planning to limit the number of registers actually used by the graal compiler, it seemed appropriate to push this out. >> >> Tests >> ----- >> . With the ForeignCall support above, some test cases that were marked as failing are now passing. >> >> KernelTester.java >> ----------------- >> . Not really part of the webrev infrastructure merge but added a property to allow running the gpu code either first or second vs. the java code in our test cases. >> >> >> -- Tom Deneau >> >> > > > From doug.simon at oracle.com Mon Nov 4 11:34:38 2013 From: doug.simon at oracle.com (Doug Simon) Date: Mon, 4 Nov 2013 20:34:38 +0100 Subject: testing new Graal backends for Java conformance In-Reply-To: <5DD1503F815BD14889DC81D28643E3A7553ABBC9@SATLEXDAG02.amd.com> References: <5DD1503F815BD14889DC81D28643E3A7553ABBC9@SATLEXDAG02.amd.com> Message-ID: Currently we have the gate tests plus a bunch of benchmarks we run for every push. The latter are run post-gate. Since we only have a fully functioning AMD64 backend, we currently use only AMD64 machines in our gate/benchmarking infrastructure. We don?t yet do any rigorous TCK/JCK testing. This kind of testing will occur at the point Graal is adopted into the mainline HotSpot code base. On Nov 4, 2013, at 5:36 PM, Venkatachalam, Vasanth wrote: > Doug or others- > > Do you have a way of testing new backends that are developed for Graal for Java compliance (against the TCK)? > > If so, can you explain how we can plug our HSAIL backend into this process so that it also gets tested for Java compliance? > > A related question has to do with unit testing. So far we've been writing separate unit tests (in compiler.hsail.test) for each new Java operator that we add support for (e.g., +, -, *) as well as program constructs (e.g., conditionals, loops) to ensure that we are generating the correct code. Is there already a common infrastructure in Graal that could be leveraged for this purpose? The JTT tests (com.oracle.graal.jtt) provide fairly good coverage of basic Java functionality. Additions are always welcome ;-) > On a related note, can you explain at a high level how you are ensuring that you have complete testing coverage (for the x86 code gen) in compiler.test/ ? We don?t have much else apart from what is listed above. However, in combination with our automated benchmarking system, we think the coverage is fine for now (even though it can always be better of course). We also use JaCoCo for analyzing the code paths covered by the gate (see the '--jacocout? option of the ?mx gate? command). If you want to see the list of tests (apart from doing a text search for ?@Test?), use the MX_TESTFILE variable to capture the set of tests run by ?mx unittest? to a file: % mx help unittest ... % env MX_TESTFILE=test.list mx unittest % cat test.list -Doug From java at stefan-marr.de Mon Nov 4 16:42:33 2013 From: java at stefan-marr.de (Stefan Marr) Date: Tue, 5 Nov 2013 01:42:33 +0100 Subject: Truffle: executeCached, get, and other abstract methods? And a little generator bug. In-Reply-To: References: <60F35720-B657-476D-96E5-AA870765DF72@vub.ac.be> Message-ID: Hi Christian: Thanks for the thorough explanation! On 04 Nov 2013, at 16:50, Christian Humer wrote: > I think, the feature you need is the generation of execute methods with > evaluated children. This is also the feature you are already using, but the > method should not be called executeCached* but instead executeEvaluated or > something different. Ah, right, I already forgot about those. > I hope this answers your question. There are just these two magic features > (the rest is more explicit using annotations): Getters for fields/children > and the automatic implementation of execute methods. While the first is a > convenience feature the second is an essential part of the DSL. Ok, thanks. > When the PolymorphicMyNode now gets called by its parent using an execute > method it first executes its child operand. It then calls the first element > of the polymorphic chain which is IntMyNode using executeChachedGeneric > with the evaluated value of operand. The implementation of > executeChachedGeneric in IntMyNode will then check if the value is > compatible to this specialization and invoke the specialization if so. If > not it will just call the next specialization in the chain stored in the > next0 field. If an UninitializedMyNode is reached another entry to the > polymorphic chain is added or if the maximum depth was reached the whole > tree gets rewritten to GenericMyNode. Is this feature somehow [ab]usable to realize polymorphic inline caches? I.e., can I somehow define something like my MonomorphicMessageNode with it and get automatically a polymorphic behavior? (https://github.com/smarr/TruffleSOM/blob/master/src/som/interpreter/nodes/specialized/MonomorpicMessageNode.java#L35) I would assume that a failing guard on line 49 would be very similar to the situations you describe? > Regarding the NPE: Null is not supported as a value by the DSL at them > moment (but it is supported by Truffle in general). If you want to > represent null using the DSL, use a singleton value like MyNull.INSTANCE. > It should not make a difference performance wise. It is on my list of > things I want to add support for at some point. Please tell me if you need > it. In this case I can try to give it a higher priority. Hm, well, no. The error caused by the snipped below is a different one. The `return null` can be changed to a `throw new RuntimeException();` or something. To me it reads rather like a little edge case that?s not handled gracefully in the DSL processor causing the stack trace below. At the moment I am not hitting that one, just stumbled over it while experimenting. Thanks again Stefan Uncaught error in AnnotationProcessor while processing som.interpreter.nodes.TestNode: null java.lang.NullPointerException at com.oracle.truffle.dsl.processor.node.NodeParser.createGenericSpecialization(NodeParser.java:734) at com.oracle.truffle.dsl.processor.node.NodeParser.finalizeSpecializations(NodeParser.java:614) at com.oracle.truffle.dsl.processor.node.NodeParser.parseNode(NodeParser.java:206) at com.oracle.truffle.dsl.processor.node.NodeParser.resolveNode(NodeParser.java:119) at com.oracle.truffle.dsl.processor.node.NodeParser.parse(NodeParser.java:59) at com.oracle.truffle.dsl.processor.node.NodeParser.parse(NodeParser.java:1) at com.oracle.truffle.dsl.processor.AbstractParser.parse(AbstractParser.java:63) at com.oracle.truffle.dsl.processor.AnnotationProcessor.process(AnnotationProcessor.java:83) at com.oracle.truffle.dsl.processor.TruffleProcessor.processElement(TruffleProcessor.java:91) at com.oracle.truffle.dsl.processor.TruffleProcessor.processImpl(TruffleProcessor.java:79) at com.oracle.truffle.dsl.processor.TruffleProcessor.process(TruffleProcessor.java:53) at org.eclipse.jdt.internal.compiler.apt.dispatch.RoundDispatcher.handleProcessor(RoundDispatcher.java:139) at org.eclipse.jdt.internal.compiler.apt.dispatch.RoundDispatcher.round(RoundDispatcher.java:121) at org.eclipse.jdt.internal.compiler.apt.dispatch.BaseAnnotationProcessorManager.processAnnotations(BaseAnnotatio nProcessorManager.java:159) at org.eclipse.jdt.internal.apt.pluggable.core.dispatch.IdeAnnotationProcessorManager.processAnnotations(IdeAnnot ationProcessorManager.java:134) at org.eclipse.jdt.internal.compiler.Compiler.processAnnotations(Compiler.java: 820) at org.eclipse.jdt.internal.compiler.Compiler.compile(Compiler.java:434) at org.eclipse.jdt.internal.core.builder.AbstractImageBuilder.compile(AbstractImageBuilder.java:366) at org.eclipse.jdt.internal.core.builder.IncrementalImageBuilder.compile(IncrementalImageBuilder.java:329) at org.eclipse.jdt.internal.core.builder.AbstractImageBuilder.compile(AbstractImageBuilder.java:303) at org.eclipse.jdt.internal.core.builder.IncrementalImageBuilder.build(IncrementalImageBuilder.java:134) at org.eclipse.jdt.internal.core.builder.JavaBuilder.buildDeltas(JavaBuilder.java:265) at org.eclipse.jdt.internal.core.builder.JavaBuilder.build(JavaBuilder.java:193) at org.eclipse.core.internal.events.BuildManager$2.run(BuildManager.java:733) at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:42) at org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:206) at org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:246) at org.eclipse.core.internal.events.BuildManager$1.run(BuildManager.java:299) at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:42) at org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:302) at org.eclipse.core.internal.events.BuildManager.basicBuildLoop(BuildManager.java:358) at org.eclipse.core.internal.events.BuildManager.build(BuildManager.java:381) at org.eclipse.core.internal.events.AutoBuildJob.doBuild(AutoBuildJob.java:143) at org.eclipse.core.internal.events.AutoBuildJob.run(AutoBuildJob.java:241) at org.eclipse.core.internal.jobs.Worker.run(Worker.java:53) > > > Cheers, > > - Christian Humer > > > On Mon, Nov 4, 2013 at 12:49 PM, Stefan Marr wrote: > >> Hi: >> >> I found another useful abstract method in truffle node classes: >> executeCachedGeneric, which allows me to execute the code of a specialized >> node after replacing a more general one. >> After inspecting the generator code, I also found that executeCached* is >> probably working also for other kind of specializations. >> >> And since there are also the accessors for node children (get$childName), >> I was wondering whether the TruffleDSL has other similar gems hidden in >> it, which might be useful? >> >> As a related note, I also saw a null pointer exception that can be >> reproduced with the code snippet below. >> >> Best regards >> Stefan >> >> >> package som.interpreter.nodes.specialized; >> >> import som.interpreter.Types; >> import som.interpreter.nodes.ExpressionNode; >> import som.vmobjects.SAbstractObject; >> >> import com.oracle.truffle.api.dsl.NodeChild; >> import com.oracle.truffle.api.dsl.Specialization; >> import com.oracle.truffle.api.dsl.TypeSystemReference; >> import com.oracle.truffle.api.frame.VirtualFrame; >> import com.oracle.truffle.api.nodes.Node; >> >> @TypeSystemReference(Types.class) >> @NodeChild(value = "receiver", type = ExpressionNode.class) >> public abstract class TestNode extends Node { >> public abstract SAbstractObject executeCachedGeneric(final VirtualFrame >> frame, final Object receiver); >> >> @Specialization >> public SAbstractObject doGeneric(final VirtualFrame frame, >> final SAbstractObject receiver) { >> return null; >> } >> } -- Stefan Marr Software Languages Lab Vrije Universiteit Brussel Pleinlaan 2 / B-1050 Brussels / Belgium http://soft.vub.ac.be/~smarr Phone: +32 2 629 2974 Fax: +32 2 629 3525 From doug.simon at oracle.com Tue Nov 5 05:33:13 2013 From: doug.simon at oracle.com (doug.simon at oracle.com) Date: Tue, 05 Nov 2013 13:33:13 +0000 Subject: hg: graal/graal: 19 new changesets Message-ID: <20131105133417.7C24362A64@hg.openjdk.java.net> Changeset: 2c4aa758ee18 Author: Doug Simon Date: 2013-11-03 15:27 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/2c4aa758ee18 made ConstantNodes external to a Graph (GRAAL-508) ! graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/ConditionalEliminationTest.java ! graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/GraalCompilerTest.java ! graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/deopt/CompiledMethodTest.java ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/gen/DebugInfoBuilder.java ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/gen/LIRGenerator.java ! graal/com.oracle.graal.graph/src/com/oracle/graal/graph/Graph.java ! 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/NodeMap.java ! graal/com.oracle.graal.graph/src/com/oracle/graal/graph/NodeWorkList.java ! graal/com.oracle.graal.hotspot.test/src/com/oracle/graal/hotspot/test/AheadOfTimeCompilationTest.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotHostLoweringProvider.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/phases/AheadOfTimeVerificationPhase.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/phases/LoadJavaMirrorWithKlassPhase.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/InstanceOfSnippets.java ! graal/com.oracle.graal.loop/src/com/oracle/graal/loop/BasicInductionVariable.java ! graal/com.oracle.graal.loop/src/com/oracle/graal/loop/CountedLoopInfo.java ! graal/com.oracle.graal.loop/src/com/oracle/graal/loop/DerivedOffsetInductionVariable.java ! graal/com.oracle.graal.loop/src/com/oracle/graal/loop/DerivedScaledInductionVariable.java ! graal/com.oracle.graal.loop/src/com/oracle/graal/loop/InductionVariable.java ! graal/com.oracle.graal.loop/src/com/oracle/graal/loop/LoopEx.java ! graal/com.oracle.graal.loop/src/com/oracle/graal/loop/LoopFragment.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/ConstantNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/ValueNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/calc/BinaryNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/calc/BitLogicNode.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/ConditionalNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/calc/IntegerAddNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/calc/IntegerArithmeticNode.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/IntegerDivNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/calc/IntegerSubNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/calc/NegateNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/extended/AddLocationNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/java/ArrayLengthNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/type/StampFactory.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/util/GraphUtil.java ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/ConditionalEliminationPhase.java ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/DeadCodeEliminationPhase.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/LoweringPhase.java ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/TailDuplicationPhase.java ! graal/com.oracle.graal.phases/src/com/oracle/graal/phases/schedule/SchedulePhase.java ! graal/com.oracle.graal.phases/src/com/oracle/graal/phases/verify/VerifyUsageWithEquals.java ! graal/com.oracle.graal.printer/src/com/oracle/graal/printer/BinaryGraphPrinter.java ! graal/com.oracle.graal.replacements/src/com/oracle/graal/replacements/InstanceOfSnippetsTemplates.java ! graal/com.oracle.graal.replacements/src/com/oracle/graal/replacements/NodeIntrinsificationPhase.java ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/nodes/typesystem/CustomizedUnsafeLoadMacroNode.java ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/nodes/typesystem/UnsafeTypeCastMacroNode.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/PartialEscapeClosure.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/WordTypeRewriterPhase.java Changeset: 9334392ed279 Author: Roland Schatz Date: 2013-11-04 11:25 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/9334392ed279 Refactor ConvertNode. ! graal/com.oracle.graal.asm.hsail/src/com/oracle/graal/asm/hsail/HSAILAssembler.java ! graal/com.oracle.graal.asm.ptx/src/com/oracle/graal/asm/ptx/PTXAssembler.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.java/src/com/oracle/graal/java/GraphBuilderPhase.java ! graal/com.oracle.graal.lir.hsail/src/com/oracle/graal/lir/hsail/HSAILArithmetic.java ! graal/com.oracle.graal.lir.ptx/src/com/oracle/graal/lir/ptx/PTXArithmetic.java ! graal/com.oracle.graal.loop/src/com/oracle/graal/loop/BasicInductionVariable.java ! graal/com.oracle.graal.nodes.test/src/com/oracle/graal/nodes/test/IntegerStampTest.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/ConvertNode.java + graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/calc/ReinterpretNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/spi/ArithmeticLIRGenerator.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/type/StampTool.java ! graal/com.oracle.graal.replacements.amd64/src/com/oracle/graal/replacements/amd64/AMD64ConvertNode.java ! graal/com.oracle.graal.replacements.amd64/src/com/oracle/graal/replacements/amd64/AMD64ConvertSnippets.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/StandardMethodSubstitutionsTest.java ! graal/com.oracle.graal.replacements/src/com/oracle/graal/replacements/DoubleSubstitutions.java ! graal/com.oracle.graal.replacements/src/com/oracle/graal/replacements/FloatSubstitutions.java ! graal/com.oracle.graal.word/src/com/oracle/graal/word/phases/WordTypeRewriterPhase.java Changeset: a66169e30623 Author: Roland Schatz Date: 2013-11-04 11:32 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/a66169e30623 Move second RemoveValueProxyPhase. ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/phases/LowTier.java Changeset: ef6745a4597a Author: Roland Schatz Date: 2013-11-04 11:40 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/ef6745a4597a Use Arrays.deepEquals in global value numbering. ! graal/com.oracle.graal.graph/src/com/oracle/graal/graph/NodeClass.java Changeset: 55b23f75d3b0 Author: Roland Schatz Date: 2013-11-04 12:17 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/55b23f75d3b0 Add graph parameter to ConvertNode smart constructor. ! graal/com.oracle.graal.loop/src/com/oracle/graal/loop/DerivedOffsetInductionVariable.java ! graal/com.oracle.graal.loop/src/com/oracle/graal/loop/DerivedScaledInductionVariable.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/calc/ConvertNode.java Changeset: a2b1ee69ce46 Author: Christos Kotselidis Date: 2013-11-04 15:42 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/a2b1ee69ce46 Loose unnecessary input dependencies from write barriers ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/nodes/G1PostWriteBarrier.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/nodes/SerialWriteBarrier.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/phases/WriteBarrierAdditionPhase.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/WriteBarrierSnippets.java Changeset: 0497d6702cff Author: Christian Humer Date: 2013-11-04 12:18 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/0497d6702cff mxtool: fixed eclipse builder glitches and rebuild loops. ! mxtool/mx.py Changeset: c6cc96cc6a1f Author: Christian Humer Date: 2013-11-04 12:20 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/c6cc96cc6a1f Merge. - graal/com.oracle.truffle.api/src/com/oracle/truffle/api/frame/FrameSlotImpl.java ! mxtool/mx.py Changeset: 7f507f082daa Author: Christian Humer Date: 2013-11-04 16:12 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/7f507f082daa Merge. Changeset: 1fdecc36c8ac Author: Doug Simon Date: 2013-11-04 17:17 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/1fdecc36c8ac HSAIL updates to integrate recent changes to the providers infrastructure. Contributed-by: Tom Deneau ! 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/FloatSqrtTest.java ! graal/com.oracle.graal.compiler.hsail.test/src/com/oracle/graal/compiler/hsail/test/StaticNBodySpillTest.java ! graal/com.oracle.graal.compiler.hsail.test/src/com/oracle/graal/compiler/hsail/test/StaticNBodyTest.java ! graal/com.oracle.graal.compiler.hsail.test/src/com/oracle/graal/compiler/hsail/test/StringContainsTest.java ! graal/com.oracle.graal.compiler.hsail.test/src/com/oracle/graal/compiler/hsail/test/StringIndexOfTest.java ! graal/com.oracle.graal.compiler.hsail/src/com/oracle/graal/compiler/hsail/HSAILLIRGenerator.java ! graal/com.oracle.graal.hotspot.hsail/src/com/oracle/graal/hotspot/hsail/HSAILHotSpotBackend.java ! graal/com.oracle.graal.hotspot.hsail/src/com/oracle/graal/hotspot/hsail/HSAILHotSpotForeignCallsProvider.java ! graal/com.oracle.graal.hotspot.hsail/src/com/oracle/graal/hotspot/hsail/HSAILHotSpotLIRGenerator.java ! graal/com.oracle.graal.hotspot.hsail/src/com/oracle/graal/hotspot/hsail/HSAILHotSpotReplacementsImpl.java ! graal/com.oracle.graal.hsail/src/com/oracle/graal/hsail/HSAIL.java ! graal/com.oracle.graal.lir.hsail/src/com/oracle/graal/lir/hsail/HSAILControlFlow.java ! mx/projects Changeset: 9db9e37ee4b8 Author: Doug Simon Date: 2013-11-04 17:18 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/9db9e37ee4b8 fixes for regression in Jython performance ! graal/com.oracle.graal.graph/src/com/oracle/graal/graph/NodeWorkList.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/ConstantNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/util/GraphUtil.java Changeset: d9c34e8337f4 Author: Christian Humer Date: 2013-11-04 21:24 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/d9c34e8337f4 Truffle: cleanup of NodeUtil#findParent; added NodeUtil#findAllParents ! graal/com.oracle.truffle.api/src/com/oracle/truffle/api/nodes/NodeUtil.java Changeset: bee224687003 Author: Christian Humer Date: 2013-11-04 21:25 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/bee224687003 Merge. Changeset: e27f3169460e Author: Tom Rodriguez Date: 2013-11-04 21:45 -0800 URL: http://hg.openjdk.java.net/graal/graal/rev/e27f3169460e notify JVMTI about exception throws from runtime ! src/share/vm/graal/graalRuntime.cpp Changeset: 1152cf83f0b9 Author: Doug Simon Date: 2013-11-05 06:49 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/1152cf83f0b9 added support for reading float debug properties from a node ! graal/com.oracle.graal.graph/src/com/oracle/graal/graph/NodeClass.java Changeset: cf57663a2a36 Author: Doug Simon Date: 2013-11-05 06:50 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/cf57663a2a36 use getAddress instead of getLong in HotSpotGraalRuntime ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/HotSpotGraalRuntime.java Changeset: 582b3d24c6ad Author: Doug Simon Date: 2013-11-05 11:14 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/582b3d24c6ad record an OptionDescriptor in an OptionValue so that it can be queried for a name ! graal/com.oracle.graal.options/src/com/oracle/graal/options/OptionDescriptor.java ! graal/com.oracle.graal.options/src/com/oracle/graal/options/OptionValue.java Changeset: 38bf986ce231 Author: Doug Simon Date: 2013-11-05 12:48 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/38bf986ce231 added support for scoped overriding of OptionValues (GRAAL-27) + graal/com.oracle.graal.options.test/src/com/oracle/graal/options/test/TestOptionValue.java ! graal/com.oracle.graal.options/src/com/oracle/graal/options/OptionValue.java ! mx/projects Changeset: df42ff42279f Author: Doug Simon Date: 2013-11-05 12:48 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/df42ff42279f Merge. From doug.simon at oracle.com Tue Nov 5 06:05:41 2013 From: doug.simon at oracle.com (Doug Simon) Date: Tue, 5 Nov 2013 15:05:41 +0100 Subject: webrev for hsail backend merging with new providers infrastructure In-Reply-To: References: <0DB6F95F-9B2F-42BC-B29D-7CCA428C2CC0@oracle.com> Message-ID: On Nov 4, 2013, at 6:19 PM, Doug Simon wrote: > > On Nov 4, 2013, at 5:27 PM, Deneau, Tom wrote: > >> Hi Doug -- >> >> Some of our java 8 based unit tests (which use lambdas) use these two libraries currently, but you're right we don't use them in the java 7 based tests yet. If you want to remove them from the public mx/projects, go ahead. >> >> This points to a hole in our testing strategy which we've always been aware of. We have written a number of java 8 style unit tests that we test locally here but that don't get exercised in the public repository. We could of course add similar java 7 based unit tests and push them to public but we haven't done that work, and if graal is going to support 8 soon, there wouldn't be a need for that conversion work. > > Yes, I suggest to keep just running these tests locally until Graal has transitioned to 8. > >> On a related note, I think Vasanth mentioned that we run our unit tests locally here with the flags -G:+InlineEverything -G:-RemoveNeverExecutedCode. We need InlineEverything because we don't support HSAIL function calls yet. Several test cases have a line like >> assumeTrue(aggressiveInliningEnabled()); >> >> and of course these just get skipped if -G:+InlineEverything is not set. Is it possible to get the hsail tests that get run at Oracle to use these two flags? > > We don?t currently have infrastructure for running tests in a different VM instances based on required command line option settings. What we ideally want (in this case at least) is for options such as InlineEverything and RemoveNeverExecutedCode to be overridable in a scoped manner (e.g., for individual compilations). Until we have support for this however, we?ll have to rely on your testing setup to run these tests. There is now support for scoped overriding of options[1]. For example, in StaticNBodyCallTest: @Test @Override public void test() throws Exception { Field f = GraalOptions.class.getDeclaredField("RemoveNeverExecutedCode"); f.setAccessible(true); OptionValue removeNeverExecutedCode = (OptionValue) f.get(null); try (OverrideScope s = OptionValue.override(GraalOptions.InlineEverything, true, removeNeverExecutedCode, false)) { assumeTrue(aggressiveInliningEnabled() || canHandleHSAILMethodCalls()); testGeneratedHsail(); } } [1] http://hg.openjdk.java.net/graal/graal/rev/38bf986ce231 -Doug >> -----Original Message----- >> From: Doug Simon [mailto:doug.simon at oracle.com] >> Sent: Monday, November 04, 2013 9:30 AM >> To: Deneau, Tom >> Cc: graal-dev at openjdk.java.net >> Subject: Re: webrev for hsail backend merging with new providers infrastructure >> >> Actually, one quick question: Do we really need the VECMATH and APACHELANG libraries declared in mx/projects[1]? None of the projects seem to use them. >> >> -Doug >> >> [1] http://cr.openjdk.java.net/~tdeneau/graal-webrevs/webrev-infrastructure-merge/webrev/mx/projects.udiff.html >> >> On Nov 1, 2013, at 11:54 PM, Deneau, Tom wrote: >> >>> All -- >>> >>> I have posted a small webrev to >>> http://cr.openjdk.java.net/~tdeneau/graal-webrevs/webrev-infrastructure-merge/webrev/ >>> >>> This is the result of our merge with the recent providers infrastructure. Could you please look this over? >>> >>> Here is a brief summary: >>> >>> >>> HSAILHotSpotForeignCallsProvider.java >>> ------------------------------------- >>> . As noted in the comments, we don't really support foreign calls yet, yet we do get asked to handle ForeignCall nodes, and we want to generate dummy code for them. We just support them all and lazily create dummy linkages here. When we finally support foreign calls we will explicitly register the ones we want to support. >>> >>> HSAILHotSpotLIRGenerator.java, HSAILLIRGenerator.java, HSAILControlFlow.java >>> ---------------------------------------------------------------------------- >>> . This again is part of the dummy Foreign Call support. Some less extensive ForeignCall support used to be in HSAILLIRGenerator. >>> >>> HSAILHotSpotReplacementsImpl.java >>> --------------------------------- >>> . This is another one of the providers in the new runtime infrastructure. For both macro substitutions and method substitutions, we just delegate to the host substitution list. This is a quick solution which allows things like Math.sqrt, and some of the Unsafe methods to work for HSAIL, similar to the way these substitutions worked before the providers change. Eventually, we will explicitly list which substitutions we will support. >>> >>> HSAIL.java >>> ---------- >>> . Not really part of the webrev infrastructure merge but since we're planning to limit the number of registers actually used by the graal compiler, it seemed appropriate to push this out. >>> >>> Tests >>> ----- >>> . With the ForeignCall support above, some test cases that were marked as failing are now passing. >>> >>> KernelTester.java >>> ----------------- >>> . Not really part of the webrev infrastructure merge but added a property to allow running the gpu code either first or second vs. the java code in our test cases. >>> >>> >>> -- Tom Deneau >>> >>> >> >> >> > From Vasanth.Venkatachalam at amd.com Tue Nov 5 13:50:57 2013 From: Vasanth.Venkatachalam at amd.com (Venkatachalam, Vasanth) Date: Tue, 5 Nov 2013 21:50:57 +0000 Subject: heuristic used in LirGenerator.emitSwitch Message-ID: <5DD1503F815BD14889DC81D28643E3A7553AC0AF@SATLEXDAG02.amd.com> Can someone explain the reasons behind the heuristic that Graal uses (in LIRGenerator.emitSwitch() ) to decide which of the switch statement implementations (sequential switch, table switch) should be used for a given target platform? Is there a way to adapt this heuristic in cases where the target platform may favor one implementation over the other? Vasanth From tom.deneau at amd.com Tue Nov 5 13:54:30 2013 From: tom.deneau at amd.com (Deneau, Tom) Date: Tue, 5 Nov 2013 21:54:30 +0000 Subject: hsail support for different compression for klass ptrs vs. oops Message-ID: All -- I have posted a small webrev for hsail support for different compression for klass ptrs vs. oops to http://cr.openjdk.java.net/~tdeneau/graal-webrevs/webrev-compressed-klass-ptrs/webrev/ We had an java8 based instanceof based test that started failing when graal started supporting different compressions for klass ptrs vs. oops. I have added a java7 version of this test. Brief Summary: * HSAILHotSpotLIRGenerator passes possibly different base and shift for oops and klass ptrs to the lower layers. * Avoids the overhead of testing for null on klass ptrs. Could you please look this over? -- Tom From Vasanth.Venkatachalam at amd.com Tue Nov 5 18:22:08 2013 From: Vasanth.Venkatachalam at amd.com (Venkatachalam, Vasanth) Date: Wed, 6 Nov 2013 02:22:08 +0000 Subject: unreachable branch in codegen for switch statement Message-ID: <5DD1503F815BD14889DC81D28643E3A7553AC18D@SATLEXDAG02.amd.com> Doug or others- When I ran the test case below through the AMD64 backend, I noticed an unreachable branch in the code generated below. Namely, the jmp instruction at 0x00007facc8145a60. It appears this is coming from the call to emitJump( ) in LIRGenerator.doBlock( ), which appends a jump instruction to the end of each basic block, which may later get optimized away by the reg. allocator. Is there a reason why this jmp isn't being optimized away? Is there any way around this? I tried -G:+RemoveNeverExecutedCode but this isn't making a difference. I'm hitting the same issue when I generate HSAIL code for this switch statement, but I get an assembler error due to this unreachable branch. public int switchTest(int n) { switch (n) { case 0: return 0; case 1: return 1; case 2: return 2; default: return 3; } } 0x00007facc8145a40: cmp edx,0x0 0x00007facc8145a43: je 0x00007facc8145a6b 0x00007facc8145a49: cmp edx,0x1 0x00007facc8145a4c: je 0x00007facc8145a72 0x00007facc8145a52: cmp edx,0x2 0x00007facc8145a55: je 0x00007facc8145a79 0x00007facc8145a5b: jmp 0x00007facc8145a65 0x00007facc8145a60: jmp 0x00007facc8145a6b //unreachable code 0x00007facc8145a65: mov eax,0x3 0x00007facc8145a6a: ret 0x00007facc8145a6b: mov eax,0x0 //case 0 0x00007facc8145a70: jmp 0x00007facc8145a6a 0x00007facc8145a72: mov eax,0x1 //case 1 0x00007facc8145a77: jmp 0x00007facc8145a6a 0x00007facc8145a79: mov eax,0x2 //case 2 0x00007facc8145a7e: jmp 0x00007facc8145a6a From Vasanth.Venkatachalam at amd.com Tue Nov 5 18:40:10 2013 From: Vasanth.Venkatachalam at amd.com (Venkatachalam, Vasanth) Date: Wed, 6 Nov 2013 02:40:10 +0000 Subject: heuristic used in LirGenerator.emitSwitch Message-ID: <5DD1503F815BD14889DC81D28643E3A7553AC1A9@SATLEXDAG02.amd.com> Doug or others- To clarify the question below. For optimally performant HSAIL code generation of a switch statement, its currently preferable to use a series of compare and branch instructions, following the pattern of what would be implemented in the emitSequentialSwitch( ) routine instead of emitTableSwitch( ). Currently LIRGenerator is using a heuristic to decide whether to invoke emitSequentialSwitch( ) or emitTableSwitch( ). Is there a way I can force it to always call emitSequentialSwitch when I'm running an HSAIL test case? More generally, if it doesn't make sense for us to implement HSAILLIRGenerator.emitTableSwitch( ), do you have a preference for how we should handle this in Graal? As a start, I was thinking of implementing just emitSequentialSwitch and having only that routine called from LIRGenerator.emitSwitch() whenever I'm running an HSAIL test case. Vasanth From: Venkatachalam, Vasanth Sent: Tuesday, November 05, 2013 3:51 PM To: graal-dev at openjdk.java.net Cc: dl.Runtimes Subject: heuristic used in LirGenerator.emitSwitch Can someone explain the reasons behind the heuristic that Graal uses (in LIRGenerator.emitSwitch() ) to decide which of the switch statement implementations (sequential switch, table switch) should be used for a given target platform? Is there a way to adapt this heuristic in cases where the target platform may favor one implementation over the other? Vasanth From doug.simon at oracle.com Wed Nov 6 08:34:58 2013 From: doug.simon at oracle.com (doug.simon at oracle.com) Date: Wed, 06 Nov 2013 16:34:58 +0000 Subject: hg: graal/graal: 21 new changesets Message-ID: <20131106163631.15FD9623C5@hg.openjdk.java.net> Changeset: ecd519b39f10 Author: Doug Simon Date: 2013-11-05 13:56 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/ecd519b39f10 don't try and get override for StableOptionValues ! graal/com.oracle.graal.options/src/com/oracle/graal/options/OptionValue.java Changeset: 7fedc59e2cdc Author: Gilles Duboscq Date: 2013-11-05 12:19 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/7fedc59e2cdc Split code cache stats for the different compilers ! src/share/vm/code/nmethod.cpp Changeset: 524afdbe0612 Author: Gilles Duboscq Date: 2013-11-05 15:44 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/524afdbe0612 Clarify unsigned test in IntegerStamp(kind) ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/type/IntegerStamp.java Changeset: e53aa17b8fdf Author: Gilles Duboscq Date: 2013-11-05 15:46 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/e53aa17b8fdf Fix some more problems in StampTool.add and simplify the overflow condition Add more tests to IntegerStampTest and split them into independent methods ! 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: 3332295624ec Author: Bernhard Urban Date: 2013-11-05 17:57 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/3332295624ec AOTTest: use scoped option value ! graal/com.oracle.graal.hotspot.test/src/com/oracle/graal/hotspot/test/AheadOfTimeCompilationTest.java Changeset: 944e31d1b427 Author: Christos Kotselidis Date: 2013-11-05 18:59 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/944e31d1b427 Finalize fields ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/nodes/G1PostWriteBarrier.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/nodes/SerialWriteBarrier.java Changeset: 3affe68ddb50 Author: Christos Kotselidis Date: 2013-11-05 19:00 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/3affe68ddb50 Merge Changeset: 343477cb53ff Author: Christos Kotselidis Date: 2013-11-05 19:02 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/343477cb53ff Merge Changeset: 5dbfb4d5eaba Author: Doug Simon Date: 2013-11-05 19:02 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/5dbfb4d5eaba added a histogram to OptionValue (enabled by -Dgraal.showOptionValueReadsHistogram=true) to see which options are most frequently read ! graal/com.oracle.graal.options/src/com/oracle/graal/options/OptionValue.java Changeset: 5c5b02a165d4 Author: Doug Simon Date: 2013-11-05 19:03 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/5c5b02a165d4 moved a number of options to be declared closer to usage and cached some heavily accessed options in fields ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/alloc/IntervalWalker.java ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/alloc/LinearScan.java ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/alloc/LinearScanWalker.java ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/alloc/MoveResolver.java ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/alloc/RegisterVerifier.java ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/gen/LIRGenerator.java ! graal/com.oracle.graal.java/src/com/oracle/graal/java/GraphBuilderPhase.java ! graal/com.oracle.graal.phases/src/com/oracle/graal/phases/GraalOptions.java Changeset: ec224fef3012 Author: Doug Simon Date: 2013-11-05 19:42 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/ec224fef3012 integrated auto-formatting changes ! mxtool/mx.py Changeset: 478c82dde838 Author: Doug Simon Date: 2013-11-05 19:44 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/478c82dde838 commented choice of data structure in NodeClass.addGraphDuplicate() ! graal/com.oracle.graal.graph/src/com/oracle/graal/graph/NodeClass.java Changeset: ca8ab182026f Author: Doug Simon Date: 2013-11-05 19:54 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/ca8ab182026f abstracted a graph mark as a Mark object (hiding the node index) ! graal/com.oracle.graal.graph/src/com/oracle/graal/graph/Graph.java ! graal/com.oracle.graal.graph/src/com/oracle/graal/graph/Node.java ! graal/com.oracle.graal.loop/src/com/oracle/graal/loop/LoopTransformations.java ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/CanonicalizerPhase.java ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/IncrementalCanonicalizerPhase.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/LoweringPhase.java ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/TailDuplicationPhase.java ! graal/com.oracle.graal.replacements/src/com/oracle/graal/replacements/SnippetTemplate.java ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/PartialEvaluator.java ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/TruffleCache.java Changeset: 43301f080126 Author: Doug Simon Date: 2013-11-05 20:03 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/43301f080126 added graph compression (GRAAL-571) ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/GraalCompiler.java ! graal/com.oracle.graal.graph/src/com/oracle/graal/graph/Graph.java ! graal/com.oracle.graal.graph/src/com/oracle/graal/graph/NodeBitMap.java ! graal/com.oracle.graal.graph/src/com/oracle/graal/graph/NodeClass.java + graal/com.oracle.graal.graph/src/com/oracle/graal/graph/NodeIdAccessor.java ! graal/com.oracle.graal.graph/src/com/oracle/graal/graph/NodeMap.java ! graal/com.oracle.graal.printer/src/com/oracle/graal/printer/BinaryGraphPrinter.java Changeset: 76a6070f7164 Author: Lukas Stadler Date: 2013-11-06 11:04 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/76a6070f7164 LIRGenerator: don't create end-of-block JumpOps for blocks that end in a FallThroughOp with a target ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/gen/LIRGenerator.java ! graal/com.oracle.graal.lir/src/com/oracle/graal/lir/EdgeMoveOptimizer.java Changeset: 697ef4cf18c0 Author: Gilles Duboscq Date: 2013-11-05 19:10 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/697ef4cf18c0 mx.run should support streams for out/err even if there is no timeout ! mxtool/mx.py Changeset: c3bdd186e6cf Author: Andreas Woess Date: 2013-11-06 13:31 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/c3bdd186e6cf fix possible NPE in TruffleCompiler with TraceTruffleCompilation and background compilation enabled. With background compilation, the installed code can already be invalidated when compiledMethod.getCode() is called, in which case it returns null. ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/TruffleCompilerImpl.java Changeset: 426786412db6 Author: Andreas Woess Date: 2013-11-06 13:38 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/426786412db6 AssumptionValidAssumption: implement equals() and hashCode() to avoid duplicate registration. ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/nodes/AssumptionValidAssumption.java Changeset: ffd4b6b4ae68 Author: Andreas Woess Date: 2013-11-06 13:54 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/ffd4b6b4ae68 Truffle Node class refactoring. ! graal/com.oracle.truffle.api/src/com/oracle/truffle/api/nodes/Node.java Changeset: c6b833f7935e Author: Andreas Woess Date: 2013-11-06 14:14 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/c6b833f7935e mx sl: change vm args syntax ! mx/commands.py Changeset: 65513c398fd2 Author: Lukas Stadler Date: 2013-11-06 16:01 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/65513c398fd2 make LIRGenerator.emitSequentialSwitch protected ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/gen/LIRGenerator.java From lukas.stadler at jku.at Wed Nov 6 07:25:32 2013 From: lukas.stadler at jku.at (Lukas Stadler) Date: Wed, 6 Nov 2013 16:25:32 +0100 Subject: heuristic used in LirGenerator.emitSwitch In-Reply-To: <5DD1503F815BD14889DC81D28643E3A7553AC1A9@SATLEXDAG02.amd.com> References: <5DD1503F815BD14889DC81D28643E3A7553AC1A9@SATLEXDAG02.amd.com> Message-ID: Hi Vasanth, you?re right - the heuristic in LIRGenerator.emitSwitch is actually somewhat architecture/x86 - dependent. I?ve made the LIRGenerator.emitSequentialSwitch - method protected, so that it should be easy for you to create your own emitSwitch that always just generates a sequential switch - just like you proposed. - Lukas On 06 Nov 2013, at 3:40, Venkatachalam, Vasanth wrote: > Doug or others- > > To clarify the question below. > > For optimally performant HSAIL code generation of a switch statement, its currently preferable to use a series of compare and branch instructions, following the pattern of what would be implemented in the emitSequentialSwitch( ) routine instead of emitTableSwitch( ). > > Currently LIRGenerator is using a heuristic to decide whether to invoke emitSequentialSwitch( ) or emitTableSwitch( ). Is there a way I can force it to always call emitSequentialSwitch when I'm running an HSAIL test case? > > More generally, if it doesn't make sense for us to implement HSAILLIRGenerator.emitTableSwitch( ), do you have a preference for how we should handle this in Graal? > As a start, I was thinking of implementing just emitSequentialSwitch and having only that routine called from LIRGenerator.emitSwitch() whenever I'm running an HSAIL test case. > > Vasanth > > > From: Venkatachalam, Vasanth > Sent: Tuesday, November 05, 2013 3:51 PM > To: graal-dev at openjdk.java.net > Cc: dl.Runtimes > Subject: heuristic used in LirGenerator.emitSwitch > > Can someone explain the reasons behind the heuristic that Graal uses (in LIRGenerator.emitSwitch() ) to decide which of the switch statement implementations (sequential switch, table switch) should be used for a given target platform? > Is there a way to adapt this heuristic in cases where the target platform may favor one implementation over the other? > > Vasanth From lukas.stadler at jku.at Wed Nov 6 03:07:42 2013 From: lukas.stadler at jku.at (Lukas Stadler) Date: Wed, 6 Nov 2013 12:07:42 +0100 Subject: unreachable branch in codegen for switch statement In-Reply-To: <5DD1503F815BD14889DC81D28643E3A7553AC18D@SATLEXDAG02.amd.com> References: <5DD1503F815BD14889DC81D28643E3A7553AC18D@SATLEXDAG02.amd.com> Message-ID: <2E61E608-EBC5-4B96-922F-402D3768048B@jku.at> The problem in this particular case is that a switch with a default target is not recognized as a non-fall-through instruction in LIRGenerator.endsWithJump(). I?ve just pushed some changes that get rid of this unnecessary jump, by taking into account the (somewhat ill-named) FallThroughOps. There?s still a problem left - occasionally, the a SwitchOp emits useless jumps to the next instruction, because the control flow optimization logic doesn?t know how to optimize blocks ending in switches. Getting rid of this will require a bit more refactoring. - Lukas On 06 Nov 2013, at 3:22, Venkatachalam, Vasanth wrote: > Doug or others- > > When I ran the test case below through the AMD64 backend, I noticed an unreachable branch in the code generated below. Namely, the jmp instruction at 0x00007facc8145a60. It appears this is coming from the call to emitJump( ) in LIRGenerator.doBlock( ), which appends a jump instruction to the end of each basic block, which may later get optimized away by the reg. allocator. Is there a reason why this jmp isn't being optimized away? Is there any way around this? > I tried -G:+RemoveNeverExecutedCode but this isn't making a difference. > > I'm hitting the same issue when I generate HSAIL code for this switch statement, but I get an assembler error due to this unreachable branch. > > public int switchTest(int n) { > switch (n) { > case 0: > return 0; > case 1: > return 1; > case 2: > return 2; > default: > return 3; > } > } > > 0x00007facc8145a40: cmp edx,0x0 > 0x00007facc8145a43: je 0x00007facc8145a6b > 0x00007facc8145a49: cmp edx,0x1 > 0x00007facc8145a4c: je 0x00007facc8145a72 > 0x00007facc8145a52: cmp edx,0x2 > 0x00007facc8145a55: je 0x00007facc8145a79 > 0x00007facc8145a5b: jmp 0x00007facc8145a65 > 0x00007facc8145a60: jmp 0x00007facc8145a6b //unreachable code > 0x00007facc8145a65: mov eax,0x3 > 0x00007facc8145a6a: ret > 0x00007facc8145a6b: mov eax,0x0 //case 0 > 0x00007facc8145a70: jmp 0x00007facc8145a6a > 0x00007facc8145a72: mov eax,0x1 //case 1 > 0x00007facc8145a77: jmp 0x00007facc8145a6a > 0x00007facc8145a79: mov eax,0x2 //case 2 > 0x00007facc8145a7e: jmp 0x00007facc8145a6a From doug.simon at oracle.com Wed Nov 6 09:48:13 2013 From: doug.simon at oracle.com (Doug Simon) Date: Wed, 6 Nov 2013 18:48:13 +0100 Subject: hsail support for different compression for klass ptrs vs. oops In-Reply-To: References: Message-ID: <0CDD8E29-1DCC-48E7-B72B-59F08AC24946@oracle.com> Looks good to me - I?ll integrate it. On Nov 5, 2013, at 10:54 PM, Deneau, Tom wrote: > All -- > > I have posted a small webrev for hsail support for different compression for klass ptrs vs. oops to > http://cr.openjdk.java.net/~tdeneau/graal-webrevs/webrev-compressed-klass-ptrs/webrev/ > > We had an java8 based instanceof based test that started failing when graal started supporting different compressions for klass ptrs vs. oops. I have added a java7 version of this test. > > Brief Summary: > * HSAILHotSpotLIRGenerator passes possibly different base and shift for oops and klass ptrs to the lower layers. > * Avoids the overhead of testing for null on klass ptrs. > > Could you please look this over? > > -- Tom > > From Vasanth.Venkatachalam at amd.com Wed Nov 6 10:43:22 2013 From: Vasanth.Venkatachalam at amd.com (Venkatachalam, Vasanth) Date: Wed, 6 Nov 2013 18:43:22 +0000 Subject: switching on keys of type long Message-ID: <5DD1503F815BD14889DC81D28643E3A7553AC321@SATLEXDAG02.amd.com> Can someone explain why the emitCode( ) routine of AMD64ControlFlow.SequentialSwitchOp is handling the case: else if (key.getKind() = Kind.Long) ? >From my understanding of Java, it's not possible to switch on keys of type long. You get a compile time error. Vasanth From doug.simon at oracle.com Wed Nov 6 10:57:40 2013 From: doug.simon at oracle.com (Doug Simon) Date: Wed, 6 Nov 2013 19:57:40 +0100 Subject: switching on keys of type long In-Reply-To: <5DD1503F815BD14889DC81D28643E3A7553AC321@SATLEXDAG02.amd.com> References: <5DD1503F815BD14889DC81D28643E3A7553AC321@SATLEXDAG02.amd.com> Message-ID: <02CEFB71-5DA7-4A40-B971-42D23E127C45@oracle.com> This comes from TypeSwitchNode. On Nov 6, 2013, at 7:43 PM, Venkatachalam, Vasanth wrote: > Can someone explain why the emitCode( ) routine of AMD64ControlFlow.SequentialSwitchOp is handling the case: > > else if (key.getKind() = Kind.Long) ? > >> From my understanding of Java, it's not possible to switch on keys of type long. You get a compile time error. > > Vasanth From Eric.Caspole at amd.com Wed Nov 6 14:11:34 2013 From: Eric.Caspole at amd.com (Caspole, Eric) Date: Wed, 6 Nov 2013 22:11:34 +0000 Subject: webrev for running HSAIL same way as PTX from Hotspot Message-ID: Hi everyone, I put a new graal hotspot webrev at http://cr.openjdk.java.net/~ecaspole/jvm_kernel_launch.01/webrev/ Here I made changes to support running HSAIL kernels using the same code path as PTX in Hotspot. I tried to have the same code structure as PTX except that HSAIL arguments are processed differently because HSA has direct access to the java heap. I did not do anything with the gpu detection code. I added a -XX:+UseHSAILSimulator option for the time being to use this path rather than the PTX path. These changes will work with the HSA simulator Okra library at https://github.com/HSAFoundation/Okra-Interface-to-HSAIL-Simulator We are adding new support in that library to work with these hotspot changes. Then you can build the Okra library, put it in the LD_LIBRARY_PATH for the Graal JVM and run HSAIL kernels. I think there is a little work to do to more smoothly support the two different offload platforms but this is a start to integrate it. Thanks, Eric From christian.humer at gmail.com Thu Nov 7 05:27:26 2013 From: christian.humer at gmail.com (Christian Humer) Date: Thu, 7 Nov 2013 14:27:26 +0100 Subject: Truffle: executeCached, get, and other abstract methods? And a little generator bug. In-Reply-To: References: <60F35720-B657-476D-96E5-AA870765DF72@vub.ac.be> Message-ID: Hi Stefan, > Is this feature somehow [ab]usable to realize polymorphic inline caches? > I.e., can I somehow define something like my MonomorphicMessageNode with > it and get automatically a polymorphic behavior? > ( > https://github.com/smarr/TruffleSOM/blob/master/src/som/interpreter/nodes/specialized/MonomorpicMessageNode.java#L35 > ) > I would assume that a failing guard on line 49 would be very similar to > the situations you describe? Unfortunately it is not and I also failed myself to abuse it in that way. There are some features (eg. caching of values) missing to declare polymorphic inline caches using the DSL. At the moment all polymorphic inline caches are implemented manually using Truffle API only. We are still in phase of collecting required use-cases to compile a list of required DSL features to support it. There are some concepts like resorting of cache entries or generic cache entry promotion (not completely go to generic but keep some hot cache entries) which would also be quite difficult to support. But we would be happy if we could use your implementation as an additional use-case for DSL support. Hm, well, no. The error caused by the snipped below is a different one. > The `return null` can be changed to a `throw new RuntimeException();` or > something. > To me it reads rather like a little edge case that?s not handled > gracefully in the DSL processor causing the stack trace below. > At the moment I am not hitting that one, just stumbled over it while > experimenting. Sorry i missed that. That's a bug, of course. Thanks for the report. Will keep you posted. Cheers, Christian Humer On Tue, Nov 5, 2013 at 1:42 AM, Stefan Marr wrote: > Hi Christian: > > Thanks for the thorough explanation! > > On 04 Nov 2013, at 16:50, Christian Humer > wrote: > > > I think, the feature you need is the generation of execute methods with > > evaluated children. This is also the feature you are already using, but > the > > method should not be called executeCached* but instead executeEvaluated > or > > something different. > > Ah, right, I already forgot about those. > > > I hope this answers your question. There are just these two magic > features > > (the rest is more explicit using annotations): Getters for > fields/children > > and the automatic implementation of execute methods. While the first is a > > convenience feature the second is an essential part of the DSL. > > Ok, thanks. > > > When the PolymorphicMyNode now gets called by its parent using an execute > > method it first executes its child operand. It then calls the first > element > > of the polymorphic chain which is IntMyNode using executeChachedGeneric > > with the evaluated value of operand. The implementation of > > executeChachedGeneric in IntMyNode will then check if the value is > > compatible to this specialization and invoke the specialization if so. If > > not it will just call the next specialization in the chain stored in the > > next0 field. If an UninitializedMyNode is reached another entry to the > > polymorphic chain is added or if the maximum depth was reached the whole > > tree gets rewritten to GenericMyNode. > > Is this feature somehow [ab]usable to realize polymorphic inline caches? > I.e., can I somehow define something like my MonomorphicMessageNode with > it and get automatically a polymorphic behavior? > ( > https://github.com/smarr/TruffleSOM/blob/master/src/som/interpreter/nodes/specialized/MonomorpicMessageNode.java#L35 > ) > > I would assume that a failing guard on line 49 would be very similar to > the situations you describe? > > > Regarding the NPE: Null is not supported as a value by the DSL at them > > moment (but it is supported by Truffle in general). If you want to > > represent null using the DSL, use a singleton value like MyNull.INSTANCE. > > It should not make a difference performance wise. It is on my list of > > things I want to add support for at some point. Please tell me if you > need > > it. In this case I can try to give it a higher priority. > > Hm, well, no. The error caused by the snipped below is a different one. > The `return null` can be changed to a `throw new RuntimeException();` or > something. > To me it reads rather like a little edge case that?s not handled > gracefully in the DSL processor causing the stack trace below. > At the moment I am not hitting that one, just stumbled over it while > experimenting. > > Thanks again > Stefan > > Uncaught error in AnnotationProcessor while processing > som.interpreter.nodes.TestNode: null > java.lang.NullPointerException at > com.oracle.truffle.dsl.processor.node.NodeParser.createGenericSpecialization(NodeParser.java:734) > at > com.oracle.truffle.dsl.processor.node.NodeParser.finalizeSpecializations(NodeParser.java:614) > at > com.oracle.truffle.dsl.processor.node.NodeParser.parseNode(NodeParser.java:206) > at > com.oracle.truffle.dsl.processor.node.NodeParser.resolveNode(NodeParser.java:119) > at > com.oracle.truffle.dsl.processor.node.NodeParser.parse(NodeParser.java:59) > at > com.oracle.truffle.dsl.processor.node.NodeParser.parse(NodeParser.java:1) > at > com.oracle.truffle.dsl.processor.AbstractParser.parse(AbstractParser.java:63) > at > com.oracle.truffle.dsl.processor.AnnotationProcessor.process(AnnotationProcessor.java:83) > at > com.oracle.truffle.dsl.processor.TruffleProcessor.processElement(TruffleProcessor.java:91) > at > com.oracle.truffle.dsl.processor.TruffleProcessor.processImpl(TruffleProcessor.java:79) > at > com.oracle.truffle.dsl.processor.TruffleProcessor.process(TruffleProcessor.java:53) > at > org.eclipse.jdt.internal.compiler.apt.dispatch.RoundDispatcher.handleProcessor(RoundDispatcher.java:139) > at > org.eclipse.jdt.internal.compiler.apt.dispatch.RoundDispatcher.round(RoundDispatcher.java:121) > at > > org.eclipse.jdt.internal.compiler.apt.dispatch.BaseAnnotationProcessorManager.processAnnotations(BaseAnnotatio > nProcessorManager.java:159) at > > org.eclipse.jdt.internal.apt.pluggable.core.dispatch.IdeAnnotationProcessorManager.processAnnotations(IdeAnnot > ationProcessorManager.java:134) at > org.eclipse.jdt.internal.compiler.Compiler.processAnnotations(Compiler.java: > 820) at > org.eclipse.jdt.internal.compiler.Compiler.compile(Compiler.java:434) at > org.eclipse.jdt.internal.core.builder.AbstractImageBuilder.compile(AbstractImageBuilder.java:366) > at > org.eclipse.jdt.internal.core.builder.IncrementalImageBuilder.compile(IncrementalImageBuilder.java:329) > at > org.eclipse.jdt.internal.core.builder.AbstractImageBuilder.compile(AbstractImageBuilder.java:303) > at > org.eclipse.jdt.internal.core.builder.IncrementalImageBuilder.build(IncrementalImageBuilder.java:134) > at > org.eclipse.jdt.internal.core.builder.JavaBuilder.buildDeltas(JavaBuilder.java:265) > at > org.eclipse.jdt.internal.core.builder.JavaBuilder.build(JavaBuilder.java:193) > at > org.eclipse.core.internal.events.BuildManager$2.run(BuildManager.java:733) > at > org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:42) at > org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:206) > at > org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:246) > at > org.eclipse.core.internal.events.BuildManager$1.run(BuildManager.java:299) > at > org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:42) at > org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:302) > at > org.eclipse.core.internal.events.BuildManager.basicBuildLoop(BuildManager.java:358) > at > org.eclipse.core.internal.events.BuildManager.build(BuildManager.java:381) > at > org.eclipse.core.internal.events.AutoBuildJob.doBuild(AutoBuildJob.java:143) > at > org.eclipse.core.internal.events.AutoBuildJob.run(AutoBuildJob.java:241) at > org.eclipse.core.internal.jobs.Worker.run(Worker.java:53) > > > > > > > > Cheers, > > > > - Christian Humer > > > > > > On Mon, Nov 4, 2013 at 12:49 PM, Stefan Marr > wrote: > > > >> Hi: > >> > >> I found another useful abstract method in truffle node classes: > >> executeCachedGeneric, which allows me to execute the code of a > specialized > >> node after replacing a more general one. > >> After inspecting the generator code, I also found that executeCached* is > >> probably working also for other kind of specializations. > >> > >> And since there are also the accessors for node children > (get$childName), > >> I was wondering whether the TruffleDSL has other similar gems hidden in > >> it, which might be useful? > >> > >> As a related note, I also saw a null pointer exception that can be > >> reproduced with the code snippet below. > >> > >> Best regards > >> Stefan > >> > >> > >> package som.interpreter.nodes.specialized; > >> > >> import som.interpreter.Types; > >> import som.interpreter.nodes.ExpressionNode; > >> import som.vmobjects.SAbstractObject; > >> > >> import com.oracle.truffle.api.dsl.NodeChild; > >> import com.oracle.truffle.api.dsl.Specialization; > >> import com.oracle.truffle.api.dsl.TypeSystemReference; > >> import com.oracle.truffle.api.frame.VirtualFrame; > >> import com.oracle.truffle.api.nodes.Node; > >> > >> @TypeSystemReference(Types.class) > >> @NodeChild(value = "receiver", type = ExpressionNode.class) > >> public abstract class TestNode extends Node { > >> public abstract SAbstractObject executeCachedGeneric(final VirtualFrame > >> frame, final Object receiver); > >> > >> @Specialization > >> public SAbstractObject doGeneric(final VirtualFrame frame, > >> final SAbstractObject receiver) { > >> return null; > >> } > >> } > > -- > Stefan Marr > Software Languages Lab > Vrije Universiteit Brussel > Pleinlaan 2 / B-1050 Brussels / Belgium > http://soft.vub.ac.be/~smarr > Phone: +32 2 629 2974 > Fax: +32 2 629 3525 > > From java at stefan-marr.de Thu Nov 7 08:30:15 2013 From: java at stefan-marr.de (Stefan Marr) Date: Thu, 7 Nov 2013 17:30:15 +0100 Subject: Truffle DSL feature suggestions In-Reply-To: References: <60F35720-B657-476D-96E5-AA870765DF72@vub.ac.be> Message-ID: Hi Christian, Hi all: On 07 Nov 2013, at 14:27, Christian Humer wrote: > Unfortunately it is not and I also failed myself to abuse it in that way. There are some features (eg. caching of values) missing to declare polymorphic inline caches using the DSL. At the moment all polymorphic inline caches are implemented manually using Truffle API only. We are still in phase of collecting required use-cases to compile a list of required DSL features to support it. There are some concepts like resorting of cache entries or generic cache entry promotion (not completely go to generic but keep some hot cache entries) which would also be quite difficult to support. But we would be happy if we could use your implementation as an additional use-case for DSL support. I am just about to finish a rather large rewrite of TruffleSOM [1]. And for that it would be very useful if I could coerce the DSL into generating multiple cases out of a single specialization in order to handle polymorphic message sends. Overall, I think, I have three suggestions based on the TruffleSOM rewrite. I?ll try to detail them below to outline the use case and my understanding. Perhaps somethings are by design and should be done differently. The three things I would like to suggest are: - Allowing @Generic for simple non-specializing nodes, as a base case (uninitialized state) for custom specialization hierarchies - Support for inheriting @NodeChilds - Support for polymorphic inline caching, perhaps based on chaining multiple instances of the same specialization. Allowing @Generic for Simple Nodes ?????????????????????????????????- In my new node hierarchy, I use UnaryMessageNode (..Binary/Ternary/KeywordMsgNode) [2] to represent the initial state of message send as generated by the parser. So, the main idea is to avoid specialization before execution starts. The parser could do some simple specializations already purely based on the static name of a message. However, I decided against doing that, following what I understand to be one of the main suggestions for Truffle. As a result I have the UnaryMessageNode (Binary/Ternary/Keyword) class just implementing a doGeneric(.) method, which replace the node by a UnaryMonomorphicNode. For the doGeneric(.) method, I feel that @Generic would be the better annotation, and putting @Specialization there, because it otherwise wouldn?t have a specialization, feels a little unnatural. The @Generic annotation also has another benefit, because it enforces certain constraints on the method signature, which is useful to make the type system happy. Support for inheriting @NodeChild ????????????????????????????????- The next thing I noticed is that @NodeChild annotation are not inherited when the subclass defines additional @NodeChilds. While it is not a big issue, it feel counter intuitive when I noticed it for the first time. My expectation was that these annotations have an additive semantics. As an example, I have a AbstractMonomorphicMessageNode [3] with the @NodeChild(value = ?receiver?, ExpN.class) annotation, and in the subclass BinaryMonomorphicNode [4] I need to specify the receiver again, because I want to add an argument NodeChild. Polymorphic Inline Caching ?????????????????????????- I assume that you got already a number of specific use case form other Truffle languages, so I will try to outline how I would imagine potential support for PICs in the DSL based on what I see in TruffleSOM. One thing upfront: I decided that it want to try to conflate the notion of monomorphic message sends and primitive implementations. Thus, you will currently find the following hierarchy of nodes in TruffleSOM (still need to figure out whether that?s actually going to work): ExpressionNode +- AbstractMessageNode | +- AbstractMonomorphicMessageNode | +- BinaryMonomorphicNode | | +- AdditionPrimitive | | +- MultiplicationPrimitive | +- UnaryMonomorphicNode | +- PrintPrimitive | +- ... +- BinaryMessageNode +- UnaryMessageNode +- ... The reason why I thought that might be a good idea is to essential see every specialization for the primitive nodes as one variant of a potentially polymorphic message send. Let?s assume we have a #print primitive implemented for strings, and normal #print messages for other types of object, implementing something custom to first convert the value into a string and then printing it. So, a nice polymorphic example would be something like the following loop over an array: `{1. ?two?. #three. 4.0. FiveClass} do: [:elem | elem print]`. The print primitive could than be implemented like this: public abstract class PrintStringPrim extends UnaryMonomorphicNode { public PrintStringPrim(final SSymbol selector, final Universe universe, final SClass rcvrClass, final SMethod invokable) { super(selector, universe, rcvrClass, invokable); } public PrintStringPrim(final PrintStringPrim prim) { this(prim.selector, prim.universe, prim.rcvrClass, prim.invokable); } @Specialization public Object doSString(final SString receiver) { Universe.print(receiver.getEmbeddedString()); return receiver; } } And the UnaryMonomorphicNode implements a simple monomorphic method cache: public abstract class UnaryMonomorphicNode extends AbstractMonomorphicMessageNode { @Specialization(guards = "isCachedReceiverClass", order = PriorityMonomorphicCase) public SAbstractObject doMonomorphic(final VirtualFrame frame, final SAbstractObject receiver) { return invokable.invoke(frame.pack(), receiver, noArgs); } } So, my understanding is now that a normal node that has multiple specializations, perhaps based on types, can become ?node-polymorphic?. Thus, multiple specializations get instantiated and instead of replacing a previous specialization, they get chained one after another. And then, during execution, you walk the chain to find the one where the guards do not fail. I understand now that this chain can build up because there are multiple cases that can be easily identified based on different guards/tests. However, for the doMonomorphic(.) method, it is not multiple tests, it is not multiple specializations. Instead, the value on which a test is based differs. So, what I would find useful is if I could tell the DSL to multiply my specialization doMonomorphic(.) up to a given number of times, and then, I think for the instantiation, I would also need to give it a function that allows it to derive the necessary state for such ?value-based? specializations. Perhaps something like this: @Specialization(guards = ?isCachedReceiverClass?, order = PriorityMonomorphicCase, multiplicity = 8, specialization = {rcvrClass = ?classOfReceiver?, invokable = ?lookUp? } ) public SAbstractObject doMonomorphic(final VirtualFrame frame, final SAbstractObject receiver) { /* ... /* } public SClass classOfReceiver(final SAbstractObject receiver) { return classOfReceiver(receiver, getReceiver()); } public SMethod lookUp(final SAbstractObject receiver) { return classOfReceiver(receiver).lookupInvokable(selector); } I think, this might give me enough flexibility to express value-based specialization for polymorphic messages. When it comes to cleaning up or optimizing such polymorphic-node chains, well, I don?t know enough how it would behave yet. So, no ideas there so far. Would be interested to hear whether any of that sounds like it fits into how you see Truffle being used. Thanks Stefan [1] https://github.com/smarr/TruffleSOM/commit/482ccaa88306a1e7a989afdfd91e4121c5be163a [2] https://github.com/smarr/TruffleSOM/blob/482ccaa88306a1e7a989afdfd91e4121c5be163a/src/som/interpreter/nodes/UnaryMessageNode.java#L30 [3] https://github.com/smarr/TruffleSOM/blob/482ccaa88306a1e7a989afdfd91e4121c5be163a/src/som/interpreter/nodes/messages/AbstractMonomorphicMessageNode.java#L18 [4] https://github.com/smarr/TruffleSOM/blob/482ccaa88306a1e7a989afdfd91e4121c5be163a/src/som/interpreter/nodes/messages/BinaryMonomorphicNode.java#L21 -- Stefan Marr Software Languages Lab Vrije Universiteit Brussel Pleinlaan 2 / B-1050 Brussels / Belgium http://soft.vub.ac.be/~smarr Phone: +32 2 629 2974 Fax: +32 2 629 3525 From tom.deneau at amd.com Thu Nov 7 12:33:51 2013 From: tom.deneau at amd.com (Deneau, Tom) Date: Thu, 7 Nov 2013 20:33:51 +0000 Subject: webrev for hsail support for CompareAndSwap and Membar Message-ID: I have posted a webrev enabling HSAIL backend support for CompareAndSwapNode to http://cr.openjdk.java.net/~tdeneau/graal-webrevs/webrev-compareandswap/webrev/ This webrev also adds support for a volatile load and store with emitMembar. I added the CompareAndSwap support to HSAILHotSpotLIRGenerator (instead of HSAILLIRGenerator) because of the hotspot-specific special handling when the CAS location is a compressed oop. (This was definitely the more complicated case to implement). Three test cases were also added, using each of AtomicInteger, AtomicLong and AtomicReference. Could you please look this over? -- Tom From Vasanth.Venkatachalam at amd.com Thu Nov 7 12:49:51 2013 From: Vasanth.Venkatachalam at amd.com (Venkatachalam, Vasanth) Date: Thu, 7 Nov 2013 20:49:51 +0000 Subject: switching on keys of type long In-Reply-To: <02CEFB71-5DA7-4A40-B971-42D23E127C45@oracle.com> References: <5DD1503F815BD14889DC81D28643E3A7553AC321@SATLEXDAG02.amd.com> <02CEFB71-5DA7-4A40-B971-42D23E127C45@oracle.com> Message-ID: <5DD1503F815BD14889DC81D28643E3A7553AC723@SATLEXDAG02.amd.com> I assume that the case for handling Object keys also comes from TypeSwitchNOde? I also had a similar question about LIRGenerator.emitSwitch( ) The line that says: If(keyCount == 0) { ... Javac optimizes away switch statements that have no keys (e.g., cases) so that the switch doesn't appear in bytecode. Was this condition also added to handle the TypeSwitchNode? Vasanth -----Original Message----- From: Doug Simon [mailto:doug.simon at oracle.com] Sent: Wednesday, November 06, 2013 12:58 PM To: Venkatachalam, Vasanth Cc: graal-dev at openjdk.java.net Subject: Re: switching on keys of type long This comes from TypeSwitchNode. On Nov 6, 2013, at 7:43 PM, Venkatachalam, Vasanth wrote: > Can someone explain why the emitCode( ) routine of AMD64ControlFlow.SequentialSwitchOp is handling the case: > > else if (key.getKind() = Kind.Long) ? > >> From my understanding of Java, it's not possible to switch on keys of type long. You get a compile time error. > > Vasanth From tom.deneau at amd.com Thu Nov 7 13:22:41 2013 From: tom.deneau at amd.com (Deneau, Tom) Date: Thu, 7 Nov 2013 21:22:41 +0000 Subject: non-foreign-call tlab refill from hsail In-Reply-To: <33F60C70-33F8-40F6-AE82-DD817293856C@oracle.com> References: <33F60C70-33F8-40F6-AE82-DD817293856C@oracle.com> Message-ID: Doug -- Trying to see if I understand how these pieces fit together. NewObjectSnippets.allocateInstance makes a call to NewInstanceStubCall.call if the current tlab does not have enough room. NewInstanceStubCall.call looks up the ForeignCallLinkage and finds that it is not a simple foreign call to a specific foreign call address (its address is 0) but instead has a stub associated with it. I think this association came from the call to link(new NewInstanceStub(providers, target, registerStubCall(NEW_INSTANCE, REEXECUTABLE, NOT_LEAF, ANY_LOCATION))); in HotSpotHostForeingCallsProvider.java So when we try to finalizeAddress for the ForeignCallLinkage we end up compiling this stub. The stub is a SnippetStub implemented with the snippet called "newInstance" in NewInstanceStub.java and tries to get a new tlab using CAS operations. If this stub cannot get a new tlab it makes a "real" foreign call using newInstanceC(NEW_INSTANCE_C, thread(), hub); which ends up going to the graalRuntime::new_instance -----Original Message----- From: Doug Simon [mailto:doug.simon at oracle.com] Sent: Tuesday, October 22, 2013 4:42 AM To: Deneau, Tom Cc: graal-dev at openjdk.java.net; sumatra-dev at openjdk.java.net Subject: Re: non-foreign-call tlab refill from hsail On Oct 22, 2013, at 12:18 AM, "Deneau, Tom" wrote: > We are experimenting with object (and array) allocation from an HSA device (using graal for > > the HSAIL codegen). Where we are now: > > > > * the hsa workitems are using TLABs from "donor threads" who exist > > just to supply TLABs and don't do any allocation themselves. > > > > * To reduce the number of donor threads required, a TLAB can be > > used by more than one workitem, in which case the workitems use > > HSAIL atomic_add instructions to bump the tlab top pointer. > > > > * the HSAIL backend has its own fastpath allocation snippets > > which generate the HSAIL atomic_add instructions which > > override the snippets in NewObjectSnippets.java > > > > Some junit tests have been written and pass which allocate objects, or arrays of primitives, or arrays of objects. > > > > All the above only works for the fastpath case, i.e., if there is indeed enough space in the donor TLAB. We realize there are other cases: > > > > a) not enough space in current TLAB but ability to allocate a new TLAB. > > > > b) not able to allocate a new TLAB, GC required. > > > > For only case a) above, we would like to experiment with grabbing the new TLAB from HSAIL without making a "foreign call" to the VM. From the hotspot code, I assume the logic required is what one sees in > > mutableSpace::cas_allocate(size_t size) at least for the non-G1 case. When the NewInstanceStub fails to allocate a new TLAB, it calls out to GraalRuntime::new_instance (in graalRuntime.cpp). > Some of this non-foreign-call allocation logic appears to exist in the Snippet called NewInstanceStub.newInstance (as opposed to NewObjectSnippets.allocateInstance snippet which is what we are currently overriding). This comments for this snippet say > > "Re-attempts allocation after an initial TLAB allocation failed or > > was skipped (e.g., due to * -XX:-UseTLAB)." > > > > Is this NewInstanceStub.newInstance snippet actually used anywhere in the current graal framework. Yes, you can see a call to NewInstanceStubCall in NewObjectSnippets.allocateInstance. > Is this a starting point we could use to get a non-foreign-call TLAB refill working? Yes. Note that this call *is* a foreign call (see the javadoc for ForeignCallDescriptor). -Doug From tom.deneau at amd.com Thu Nov 7 13:54:06 2013 From: tom.deneau at amd.com (Deneau, Tom) Date: Thu, 7 Nov 2013 21:54:06 +0000 Subject: webrev for hsail backend merging with new providers infrastructure In-Reply-To: References: <0DB6F95F-9B2F-42BC-B29D-7CCA428C2CC0@oracle.com> Message-ID: Doug -- Sometimes we want to run a test with several different max heap sizes because it forces different types of Compressed Oops encoding, etc. Can that type of change be handled by this scoped overriding of options? (I assume not). -- Tom -----Original Message----- From: Doug Simon [mailto:doug.simon at oracle.com] Sent: Tuesday, November 05, 2013 8:06 AM To: Deneau, Tom Cc: graal-dev at openjdk.java.net Subject: Re: webrev for hsail backend merging with new providers infrastructure On Nov 4, 2013, at 6:19 PM, Doug Simon wrote: > > On Nov 4, 2013, at 5:27 PM, Deneau, Tom wrote: > >> Hi Doug -- >> >> Some of our java 8 based unit tests (which use lambdas) use these two libraries currently, but you're right we don't use them in the java 7 based tests yet. If you want to remove them from the public mx/projects, go ahead. >> >> This points to a hole in our testing strategy which we've always been aware of. We have written a number of java 8 style unit tests that we test locally here but that don't get exercised in the public repository. We could of course add similar java 7 based unit tests and push them to public but we haven't done that work, and if graal is going to support 8 soon, there wouldn't be a need for that conversion work. > > Yes, I suggest to keep just running these tests locally until Graal has transitioned to 8. > >> On a related note, I think Vasanth mentioned that we run our unit tests locally here with the flags -G:+InlineEverything -G:-RemoveNeverExecutedCode. We need InlineEverything because we don't support HSAIL function calls yet. Several test cases have a line like >> assumeTrue(aggressiveInliningEnabled()); >> >> and of course these just get skipped if -G:+InlineEverything is not set. Is it possible to get the hsail tests that get run at Oracle to use these two flags? > > We don't currently have infrastructure for running tests in a different VM instances based on required command line option settings. What we ideally want (in this case at least) is for options such as InlineEverything and RemoveNeverExecutedCode to be overridable in a scoped manner (e.g., for individual compilations). Until we have support for this however, we'll have to rely on your testing setup to run these tests. There is now support for scoped overriding of options[1]. For example, in StaticNBodyCallTest: @Test @Override public void test() throws Exception { Field f = GraalOptions.class.getDeclaredField("RemoveNeverExecutedCode"); f.setAccessible(true); OptionValue removeNeverExecutedCode = (OptionValue) f.get(null); try (OverrideScope s = OptionValue.override(GraalOptions.InlineEverything, true, removeNeverExecutedCode, false)) { assumeTrue(aggressiveInliningEnabled() || canHandleHSAILMethodCalls()); testGeneratedHsail(); } } [1] http://hg.openjdk.java.net/graal/graal/rev/38bf986ce231 -Doug >> -----Original Message----- >> From: Doug Simon [mailto:doug.simon at oracle.com] >> Sent: Monday, November 04, 2013 9:30 AM >> To: Deneau, Tom >> Cc: graal-dev at openjdk.java.net >> Subject: Re: webrev for hsail backend merging with new providers infrastructure >> >> Actually, one quick question: Do we really need the VECMATH and APACHELANG libraries declared in mx/projects[1]? None of the projects seem to use them. >> >> -Doug >> >> [1] http://cr.openjdk.java.net/~tdeneau/graal-webrevs/webrev-infrastructure-merge/webrev/mx/projects.udiff.html >> >> On Nov 1, 2013, at 11:54 PM, Deneau, Tom wrote: >> >>> All -- >>> >>> I have posted a small webrev to >>> http://cr.openjdk.java.net/~tdeneau/graal-webrevs/webrev-infrastructure-merge/webrev/ >>> >>> This is the result of our merge with the recent providers infrastructure. Could you please look this over? >>> >>> Here is a brief summary: >>> >>> >>> HSAILHotSpotForeignCallsProvider.java >>> ------------------------------------- >>> . As noted in the comments, we don't really support foreign calls yet, yet we do get asked to handle ForeignCall nodes, and we want to generate dummy code for them. We just support them all and lazily create dummy linkages here. When we finally support foreign calls we will explicitly register the ones we want to support. >>> >>> HSAILHotSpotLIRGenerator.java, HSAILLIRGenerator.java, HSAILControlFlow.java >>> ---------------------------------------------------------------------------- >>> . This again is part of the dummy Foreign Call support. Some less extensive ForeignCall support used to be in HSAILLIRGenerator. >>> >>> HSAILHotSpotReplacementsImpl.java >>> --------------------------------- >>> . This is another one of the providers in the new runtime infrastructure. For both macro substitutions and method substitutions, we just delegate to the host substitution list. This is a quick solution which allows things like Math.sqrt, and some of the Unsafe methods to work for HSAIL, similar to the way these substitutions worked before the providers change. Eventually, we will explicitly list which substitutions we will support. >>> >>> HSAIL.java >>> ---------- >>> . Not really part of the webrev infrastructure merge but since we're planning to limit the number of registers actually used by the graal compiler, it seemed appropriate to push this out. >>> >>> Tests >>> ----- >>> . With the ForeignCall support above, some test cases that were marked as failing are now passing. >>> >>> KernelTester.java >>> ----------------- >>> . Not really part of the webrev infrastructure merge but added a property to allow running the gpu code either first or second vs. the java code in our test cases. >>> >>> >>> -- Tom Deneau >>> >>> >> >> >> > From doug.simon at oracle.com Thu Nov 7 14:02:07 2013 From: doug.simon at oracle.com (Doug Simon) Date: Thu, 7 Nov 2013 23:02:07 +0100 Subject: switching on keys of type long In-Reply-To: <5DD1503F815BD14889DC81D28643E3A7553AC723@SATLEXDAG02.amd.com> References: <5DD1503F815BD14889DC81D28643E3A7553AC321@SATLEXDAG02.amd.com> <02CEFB71-5DA7-4A40-B971-42D23E127C45@oracle.com> <5DD1503F815BD14889DC81D28643E3A7553AC723@SATLEXDAG02.amd.com> Message-ID: On Nov 7, 2013, at 9:49 PM, Venkatachalam, Vasanth wrote: > I assume that the case for handling Object keys also comes from TypeSwitchNOde? > > I also had a similar question about LIRGenerator.emitSwitch( ) > > The line that says: > > If(keyCount == 0) { ... > > Javac optimizes away switch statements that have no keys (e.g., cases) so that the switch doesn't appear in bytecode. > Was this condition also added to handle the TypeSwitchNode? Not necessarily. It used to be that javac generated switch bytecodes for switch statements that have only a default case. If you want to find out, run Graal over a number of applications/benchmarks in a debugger and place a breakpoint on the code path of interest. That?s what I?d have to do to provide you with a more accurate answer ;-) -Doug > -----Original Message----- > From: Doug Simon [mailto:doug.simon at oracle.com] > Sent: Wednesday, November 06, 2013 12:58 PM > To: Venkatachalam, Vasanth > Cc: graal-dev at openjdk.java.net > Subject: Re: switching on keys of type long > > This comes from TypeSwitchNode. > > On Nov 6, 2013, at 7:43 PM, Venkatachalam, Vasanth wrote: > >> Can someone explain why the emitCode( ) routine of AMD64ControlFlow.SequentialSwitchOp is handling the case: >> >> else if (key.getKind() = Kind.Long) ? >> >>> From my understanding of Java, it's not possible to switch on keys of type long. You get a compile time error. >> >> Vasanth > > > From doug.simon at oracle.com Thu Nov 7 14:03:37 2013 From: doug.simon at oracle.com (Doug Simon) Date: Thu, 7 Nov 2013 23:03:37 +0100 Subject: non-foreign-call tlab refill from hsail In-Reply-To: References: <33F60C70-33F8-40F6-AE82-DD817293856C@oracle.com> Message-ID: That is a very correct summary of the way it works! On Nov 7, 2013, at 10:22 PM, Deneau, Tom wrote: > Doug -- > > Trying to see if I understand how these pieces fit together. > > NewObjectSnippets.allocateInstance makes a call to > NewInstanceStubCall.call if the current tlab does not have enough > room. > > NewInstanceStubCall.call looks up the ForeignCallLinkage and finds > that it is not a simple foreign call to a specific foreign call > address (its address is 0) but instead has a stub associated with it. > I think this association came from the call to > > link(new NewInstanceStub(providers, target, registerStubCall(NEW_INSTANCE, REEXECUTABLE, NOT_LEAF, ANY_LOCATION))); > > in HotSpotHostForeingCallsProvider.java > > So when we try to finalizeAddress for the ForeignCallLinkage we end up > compiling this stub. > > The stub is a SnippetStub implemented with the snippet called > "newInstance" in NewInstanceStub.java and tries to get a new tlab > using CAS operations. If this stub cannot get a new tlab it makes a > "real" foreign call using > newInstanceC(NEW_INSTANCE_C, thread(), hub); > > which ends up going to the graalRuntime::new_instance > > > -----Original Message----- > From: Doug Simon [mailto:doug.simon at oracle.com] > Sent: Tuesday, October 22, 2013 4:42 AM > To: Deneau, Tom > Cc: graal-dev at openjdk.java.net; sumatra-dev at openjdk.java.net > Subject: Re: non-foreign-call tlab refill from hsail > > > On Oct 22, 2013, at 12:18 AM, "Deneau, Tom" wrote: > >> We are experimenting with object (and array) allocation from an HSA device (using graal for >> >> the HSAIL codegen). Where we are now: >> >> >> >> * the hsa workitems are using TLABs from "donor threads" who exist >> >> just to supply TLABs and don't do any allocation themselves. >> >> >> >> * To reduce the number of donor threads required, a TLAB can be >> >> used by more than one workitem, in which case the workitems use >> >> HSAIL atomic_add instructions to bump the tlab top pointer. >> >> >> >> * the HSAIL backend has its own fastpath allocation snippets >> >> which generate the HSAIL atomic_add instructions which >> >> override the snippets in NewObjectSnippets.java >> >> >> >> Some junit tests have been written and pass which allocate objects, or arrays of primitives, or arrays of objects. >> >> >> >> All the above only works for the fastpath case, i.e., if there is indeed enough space in the donor TLAB. We realize there are other cases: >> >> >> >> a) not enough space in current TLAB but ability to allocate a new TLAB. >> >> >> >> b) not able to allocate a new TLAB, GC required. >> >> >> >> For only case a) above, we would like to experiment with grabbing the new TLAB from HSAIL without making a "foreign call" to the VM. From the hotspot code, I assume the logic required is what one sees in >> >> mutableSpace::cas_allocate(size_t size) at least for the non-G1 case. > > When the NewInstanceStub fails to allocate a new TLAB, it calls out to GraalRuntime::new_instance (in graalRuntime.cpp). > >> Some of this non-foreign-call allocation logic appears to exist in the Snippet called NewInstanceStub.newInstance (as opposed to NewObjectSnippets.allocateInstance snippet which is what we are currently overriding). This comments for this snippet say >> >> "Re-attempts allocation after an initial TLAB allocation failed or >> >> was skipped (e.g., due to * -XX:-UseTLAB)." >> >> >> >> Is this NewInstanceStub.newInstance snippet actually used anywhere in the current graal framework. > > Yes, you can see a call to NewInstanceStubCall in NewObjectSnippets.allocateInstance. > >> Is this a starting point we could use to get a non-foreign-call TLAB refill working? > > Yes. Note that this call *is* a foreign call (see the javadoc for ForeignCallDescriptor). > > -Doug > From doug.simon at oracle.com Thu Nov 7 14:05:02 2013 From: doug.simon at oracle.com (Doug Simon) Date: Thu, 7 Nov 2013 23:05:02 +0100 Subject: webrev for hsail backend merging with new providers infrastructure In-Reply-To: References: <0DB6F95F-9B2F-42BC-B29D-7CCA428C2CC0@oracle.com> Message-ID: <16BA4787-DA30-4D21-A7B7-B4149C498D40@oracle.com> On Nov 7, 2013, at 10:54 PM, Deneau, Tom wrote: > Doug -- > > Sometimes we want to run a test with several different max heap sizes because it forces different types of Compressed Oops encoding, etc. Can that type of change be handled by this scoped overriding of options? (I assume not). Unfortunately not. The scoped overriding mechanism is only supported for Graal options, not HotSpot options. -Doug > -----Original Message----- > From: Doug Simon [mailto:doug.simon at oracle.com] > Sent: Tuesday, November 05, 2013 8:06 AM > To: Deneau, Tom > Cc: graal-dev at openjdk.java.net > Subject: Re: webrev for hsail backend merging with new providers infrastructure > > > On Nov 4, 2013, at 6:19 PM, Doug Simon wrote: > >> >> On Nov 4, 2013, at 5:27 PM, Deneau, Tom wrote: >> >>> Hi Doug -- >>> >>> Some of our java 8 based unit tests (which use lambdas) use these two libraries currently, but you're right we don't use them in the java 7 based tests yet. If you want to remove them from the public mx/projects, go ahead. >>> >>> This points to a hole in our testing strategy which we've always been aware of. We have written a number of java 8 style unit tests that we test locally here but that don't get exercised in the public repository. We could of course add similar java 7 based unit tests and push them to public but we haven't done that work, and if graal is going to support 8 soon, there wouldn't be a need for that conversion work. >> >> Yes, I suggest to keep just running these tests locally until Graal has transitioned to 8. >> >>> On a related note, I think Vasanth mentioned that we run our unit tests locally here with the flags -G:+InlineEverything -G:-RemoveNeverExecutedCode. We need InlineEverything because we don't support HSAIL function calls yet. Several test cases have a line like >>> assumeTrue(aggressiveInliningEnabled()); >>> >>> and of course these just get skipped if -G:+InlineEverything is not set. Is it possible to get the hsail tests that get run at Oracle to use these two flags? >> >> We don't currently have infrastructure for running tests in a different VM instances based on required command line option settings. What we ideally want (in this case at least) is for options such as InlineEverything and RemoveNeverExecutedCode to be overridable in a scoped manner (e.g., for individual compilations). Until we have support for this however, we'll have to rely on your testing setup to run these tests. > > There is now support for scoped overriding of options[1]. For example, in StaticNBodyCallTest: > > @Test > @Override > public void test() throws Exception { > Field f = GraalOptions.class.getDeclaredField("RemoveNeverExecutedCode"); > f.setAccessible(true); > OptionValue removeNeverExecutedCode = (OptionValue) f.get(null); > try (OverrideScope s = OptionValue.override(GraalOptions.InlineEverything, true, removeNeverExecutedCode, false)) { > assumeTrue(aggressiveInliningEnabled() || canHandleHSAILMethodCalls()); > testGeneratedHsail(); > } > } > > > [1] http://hg.openjdk.java.net/graal/graal/rev/38bf986ce231 > > -Doug > >>> -----Original Message----- >>> From: Doug Simon [mailto:doug.simon at oracle.com] >>> Sent: Monday, November 04, 2013 9:30 AM >>> To: Deneau, Tom >>> Cc: graal-dev at openjdk.java.net >>> Subject: Re: webrev for hsail backend merging with new providers infrastructure >>> >>> Actually, one quick question: Do we really need the VECMATH and APACHELANG libraries declared in mx/projects[1]? None of the projects seem to use them. >>> >>> -Doug >>> >>> [1] http://cr.openjdk.java.net/~tdeneau/graal-webrevs/webrev-infrastructure-merge/webrev/mx/projects.udiff.html >>> >>> On Nov 1, 2013, at 11:54 PM, Deneau, Tom wrote: >>> >>>> All -- >>>> >>>> I have posted a small webrev to >>>> http://cr.openjdk.java.net/~tdeneau/graal-webrevs/webrev-infrastructure-merge/webrev/ >>>> >>>> This is the result of our merge with the recent providers infrastructure. Could you please look this over? >>>> >>>> Here is a brief summary: >>>> >>>> >>>> HSAILHotSpotForeignCallsProvider.java >>>> ------------------------------------- >>>> . As noted in the comments, we don't really support foreign calls yet, yet we do get asked to handle ForeignCall nodes, and we want to generate dummy code for them. We just support them all and lazily create dummy linkages here. When we finally support foreign calls we will explicitly register the ones we want to support. >>>> >>>> HSAILHotSpotLIRGenerator.java, HSAILLIRGenerator.java, HSAILControlFlow.java >>>> ---------------------------------------------------------------------------- >>>> . This again is part of the dummy Foreign Call support. Some less extensive ForeignCall support used to be in HSAILLIRGenerator. >>>> >>>> HSAILHotSpotReplacementsImpl.java >>>> --------------------------------- >>>> . This is another one of the providers in the new runtime infrastructure. For both macro substitutions and method substitutions, we just delegate to the host substitution list. This is a quick solution which allows things like Math.sqrt, and some of the Unsafe methods to work for HSAIL, similar to the way these substitutions worked before the providers change. Eventually, we will explicitly list which substitutions we will support. >>>> >>>> HSAIL.java >>>> ---------- >>>> . Not really part of the webrev infrastructure merge but since we're planning to limit the number of registers actually used by the graal compiler, it seemed appropriate to push this out. >>>> >>>> Tests >>>> ----- >>>> . With the ForeignCall support above, some test cases that were marked as failing are now passing. >>>> >>>> KernelTester.java >>>> ----------------- >>>> . Not really part of the webrev infrastructure merge but added a property to allow running the gpu code either first or second vs. the java code in our test cases. >>>> >>>> >>>> -- Tom Deneau >>>> >>>> >>> >>> >>> >> > > > From tom.deneau at amd.com Thu Nov 7 14:13:49 2013 From: tom.deneau at amd.com (Deneau, Tom) Date: Thu, 7 Nov 2013 22:13:49 +0000 Subject: non-foreign-call tlab refill from hsail In-Reply-To: References: <33F60C70-33F8-40F6-AE82-DD817293856C@oracle.com> Message-ID: So I was trying to understand why the NewInstanceStub.newInstance Stub code was not just included in the original NewObjectSnippet.allocateInstance snippet. -- Tom -----Original Message----- From: Doug Simon [mailto:doug.simon at oracle.com] Sent: Thursday, November 07, 2013 4:04 PM To: Deneau, Tom Cc: graal-dev at openjdk.java.net; sumatra-dev at openjdk.java.net Subject: Re: non-foreign-call tlab refill from hsail That is a very correct summary of the way it works! On Nov 7, 2013, at 10:22 PM, Deneau, Tom wrote: > Doug -- > > Trying to see if I understand how these pieces fit together. > > NewObjectSnippets.allocateInstance makes a call to > NewInstanceStubCall.call if the current tlab does not have enough > room. > > NewInstanceStubCall.call looks up the ForeignCallLinkage and finds > that it is not a simple foreign call to a specific foreign call > address (its address is 0) but instead has a stub associated with it. > I think this association came from the call to > > link(new NewInstanceStub(providers, target, > registerStubCall(NEW_INSTANCE, REEXECUTABLE, NOT_LEAF, > ANY_LOCATION))); > > in HotSpotHostForeingCallsProvider.java > > So when we try to finalizeAddress for the ForeignCallLinkage we end up > compiling this stub. > > The stub is a SnippetStub implemented with the snippet called > "newInstance" in NewInstanceStub.java and tries to get a new tlab > using CAS operations. If this stub cannot get a new tlab it makes a > "real" foreign call using > newInstanceC(NEW_INSTANCE_C, thread(), hub); > > which ends up going to the graalRuntime::new_instance > > > -----Original Message----- > From: Doug Simon [mailto:doug.simon at oracle.com] > Sent: Tuesday, October 22, 2013 4:42 AM > To: Deneau, Tom > Cc: graal-dev at openjdk.java.net; sumatra-dev at openjdk.java.net > Subject: Re: non-foreign-call tlab refill from hsail > > > On Oct 22, 2013, at 12:18 AM, "Deneau, Tom" wrote: > >> We are experimenting with object (and array) allocation from an HSA >> device (using graal for >> >> the HSAIL codegen). Where we are now: >> >> >> >> * the hsa workitems are using TLABs from "donor threads" who exist >> >> just to supply TLABs and don't do any allocation themselves. >> >> >> >> * To reduce the number of donor threads required, a TLAB can be >> >> used by more than one workitem, in which case the workitems use >> >> HSAIL atomic_add instructions to bump the tlab top pointer. >> >> >> >> * the HSAIL backend has its own fastpath allocation snippets >> >> which generate the HSAIL atomic_add instructions which >> >> override the snippets in NewObjectSnippets.java >> >> >> >> Some junit tests have been written and pass which allocate objects, or arrays of primitives, or arrays of objects. >> >> >> >> All the above only works for the fastpath case, i.e., if there is indeed enough space in the donor TLAB. We realize there are other cases: >> >> >> >> a) not enough space in current TLAB but ability to allocate a new TLAB. >> >> >> >> b) not able to allocate a new TLAB, GC required. >> >> >> >> For only case a) above, we would like to experiment with grabbing the >> new TLAB from HSAIL without making a "foreign call" to the VM. From >> the hotspot code, I assume the logic required is what one sees in >> >> mutableSpace::cas_allocate(size_t size) at least for the non-G1 case. > > When the NewInstanceStub fails to allocate a new TLAB, it calls out to GraalRuntime::new_instance (in graalRuntime.cpp). > >> Some of this non-foreign-call allocation logic appears to exist in >> the Snippet called NewInstanceStub.newInstance (as opposed to >> NewObjectSnippets.allocateInstance snippet which is what we are >> currently overriding). This comments for this snippet say >> >> "Re-attempts allocation after an initial TLAB allocation failed or >> >> was skipped (e.g., due to * -XX:-UseTLAB)." >> >> >> >> Is this NewInstanceStub.newInstance snippet actually used anywhere in the current graal framework. > > Yes, you can see a call to NewInstanceStubCall in NewObjectSnippets.allocateInstance. > >> Is this a starting point we could use to get a non-foreign-call TLAB refill working? > > Yes. Note that this call *is* a foreign call (see the javadoc for ForeignCallDescriptor). > > -Doug > From doug.simon at oracle.com Thu Nov 7 14:15:12 2013 From: doug.simon at oracle.com (Doug Simon) Date: Thu, 7 Nov 2013 23:15:12 +0100 Subject: non-foreign-call tlab refill from hsail In-Reply-To: References: <33F60C70-33F8-40F6-AE82-DD817293856C@oracle.com> Message-ID: <36423EAD-CDB9-4F3B-BDD4-E210C5EE3FB5@oracle.com> Because it is slow (well, medium) path code that we don?t want to inline at every allocation site. On Nov 7, 2013, at 11:13 PM, Deneau, Tom wrote: > So I was trying to understand why the NewInstanceStub.newInstance Stub code > was not just included in the original NewObjectSnippet.allocateInstance snippet. > > -- Tom > > > -----Original Message----- > From: Doug Simon [mailto:doug.simon at oracle.com] > Sent: Thursday, November 07, 2013 4:04 PM > To: Deneau, Tom > Cc: graal-dev at openjdk.java.net; sumatra-dev at openjdk.java.net > Subject: Re: non-foreign-call tlab refill from hsail > > That is a very correct summary of the way it works! > > On Nov 7, 2013, at 10:22 PM, Deneau, Tom wrote: > >> Doug -- >> >> Trying to see if I understand how these pieces fit together. >> >> NewObjectSnippets.allocateInstance makes a call to >> NewInstanceStubCall.call if the current tlab does not have enough >> room. >> >> NewInstanceStubCall.call looks up the ForeignCallLinkage and finds >> that it is not a simple foreign call to a specific foreign call >> address (its address is 0) but instead has a stub associated with it. >> I think this association came from the call to >> >> link(new NewInstanceStub(providers, target, >> registerStubCall(NEW_INSTANCE, REEXECUTABLE, NOT_LEAF, >> ANY_LOCATION))); >> >> in HotSpotHostForeingCallsProvider.java >> >> So when we try to finalizeAddress for the ForeignCallLinkage we end up >> compiling this stub. >> >> The stub is a SnippetStub implemented with the snippet called >> "newInstance" in NewInstanceStub.java and tries to get a new tlab >> using CAS operations. If this stub cannot get a new tlab it makes a >> "real" foreign call using >> newInstanceC(NEW_INSTANCE_C, thread(), hub); >> >> which ends up going to the graalRuntime::new_instance >> >> >> -----Original Message----- >> From: Doug Simon [mailto:doug.simon at oracle.com] >> Sent: Tuesday, October 22, 2013 4:42 AM >> To: Deneau, Tom >> Cc: graal-dev at openjdk.java.net; sumatra-dev at openjdk.java.net >> Subject: Re: non-foreign-call tlab refill from hsail >> >> >> On Oct 22, 2013, at 12:18 AM, "Deneau, Tom" wrote: >> >>> We are experimenting with object (and array) allocation from an HSA >>> device (using graal for >>> >>> the HSAIL codegen). Where we are now: >>> >>> >>> >>> * the hsa workitems are using TLABs from "donor threads" who exist >>> >>> just to supply TLABs and don't do any allocation themselves. >>> >>> >>> >>> * To reduce the number of donor threads required, a TLAB can be >>> >>> used by more than one workitem, in which case the workitems use >>> >>> HSAIL atomic_add instructions to bump the tlab top pointer. >>> >>> >>> >>> * the HSAIL backend has its own fastpath allocation snippets >>> >>> which generate the HSAIL atomic_add instructions which >>> >>> override the snippets in NewObjectSnippets.java >>> >>> >>> >>> Some junit tests have been written and pass which allocate objects, or arrays of primitives, or arrays of objects. >>> >>> >>> >>> All the above only works for the fastpath case, i.e., if there is indeed enough space in the donor TLAB. We realize there are other cases: >>> >>> >>> >>> a) not enough space in current TLAB but ability to allocate a new TLAB. >>> >>> >>> >>> b) not able to allocate a new TLAB, GC required. >>> >>> >>> >>> For only case a) above, we would like to experiment with grabbing the >>> new TLAB from HSAIL without making a "foreign call" to the VM. From >>> the hotspot code, I assume the logic required is what one sees in >>> >>> mutableSpace::cas_allocate(size_t size) at least for the non-G1 case. >> >> When the NewInstanceStub fails to allocate a new TLAB, it calls out to GraalRuntime::new_instance (in graalRuntime.cpp). >> >>> Some of this non-foreign-call allocation logic appears to exist in >>> the Snippet called NewInstanceStub.newInstance (as opposed to >>> NewObjectSnippets.allocateInstance snippet which is what we are >>> currently overriding). This comments for this snippet say >>> >>> "Re-attempts allocation after an initial TLAB allocation failed or >>> >>> was skipped (e.g., due to * -XX:-UseTLAB)." >>> >>> >>> >>> Is this NewInstanceStub.newInstance snippet actually used anywhere in the current graal framework. >> >> Yes, you can see a call to NewInstanceStubCall in NewObjectSnippets.allocateInstance. >> >>> Is this a starting point we could use to get a non-foreign-call TLAB refill working? >> >> Yes. Note that this call *is* a foreign call (see the javadoc for ForeignCallDescriptor). >> >> -Doug >> > > > From andreas.woess at jku.at Thu Nov 7 14:20:23 2013 From: andreas.woess at jku.at (Andreas Woess) Date: Thu, 07 Nov 2013 23:20:23 +0100 Subject: switching on keys of type long In-Reply-To: References: <5DD1503F815BD14889DC81D28643E3A7553AC321@SATLEXDAG02.amd.com> <02CEFB71-5DA7-4A40-B971-42D23E127C45@oracle.com> <5DD1503F815BD14889DC81D28643E3A7553AC723@SATLEXDAG02.amd.com> Message-ID: <527C1227.7080307@jku.at> In general, JVM bytecodes do not have to come from javac, and the JVM spec seems to allow for this case. Although Graal will probably optimize away such a switch. - andreas On 2013-11-07 23:02, Doug Simon wrote: > On Nov 7, 2013, at 9:49 PM, Venkatachalam, Vasanth wrote: > >> I assume that the case for handling Object keys also comes from TypeSwitchNOde? >> >> I also had a similar question about LIRGenerator.emitSwitch( ) >> >> The line that says: >> >> If(keyCount == 0) { ... >> >> Javac optimizes away switch statements that have no keys (e.g., cases) so that the switch doesn't appear in bytecode. >> Was this condition also added to handle the TypeSwitchNode? > Not necessarily. It used to be that javac generated switch bytecodes for switch statements that have only a default case. > If you want to find out, run Graal over a number of applications/benchmarks in a debugger and place a breakpoint on the code path of interest. > That?s what I?d have to do to provide you with a more accurate answer ;-) > > -Doug > >> -----Original Message----- >> From: Doug Simon [mailto:doug.simon at oracle.com] >> Sent: Wednesday, November 06, 2013 12:58 PM >> To: Venkatachalam, Vasanth >> Cc: graal-dev at openjdk.java.net >> Subject: Re: switching on keys of type long >> >> This comes from TypeSwitchNode. >> >> On Nov 6, 2013, at 7:43 PM, Venkatachalam, Vasanth wrote: >> >>> Can someone explain why the emitCode( ) routine of AMD64ControlFlow.SequentialSwitchOp is handling the case: >>> >>> else if (key.getKind() = Kind.Long) ? >>> >>>> From my understanding of Java, it's not possible to switch on keys of type long. You get a compile time error. >>> Vasanth >> >> From tom.deneau at amd.com Thu Nov 7 14:21:40 2013 From: tom.deneau at amd.com (Deneau, Tom) Date: Thu, 7 Nov 2013 22:21:40 +0000 Subject: non-foreign-call tlab refill from hsail In-Reply-To: <36423EAD-CDB9-4F3B-BDD4-E210C5EE3FB5@oracle.com> References: <33F60C70-33F8-40F6-AE82-DD817293856C@oracle.com> <36423EAD-CDB9-4F3B-BDD4-E210C5EE3FB5@oracle.com> Message-ID: Are snippets required to inline all their calls? Or alternatively is there no way to annotate that a method should not be inlined? -- Tom -----Original Message----- From: Doug Simon [mailto:doug.simon at oracle.com] Sent: Thursday, November 07, 2013 4:15 PM To: Deneau, Tom Cc: graal-dev at openjdk.java.net; sumatra-dev at openjdk.java.net Subject: Re: non-foreign-call tlab refill from hsail Because it is slow (well, medium) path code that we don't want to inline at every allocation site. On Nov 7, 2013, at 11:13 PM, Deneau, Tom wrote: > So I was trying to understand why the NewInstanceStub.newInstance Stub > code was not just included in the original NewObjectSnippet.allocateInstance snippet. > > -- Tom > > > -----Original Message----- > From: Doug Simon [mailto:doug.simon at oracle.com] > Sent: Thursday, November 07, 2013 4:04 PM > To: Deneau, Tom > Cc: graal-dev at openjdk.java.net; sumatra-dev at openjdk.java.net > Subject: Re: non-foreign-call tlab refill from hsail > > That is a very correct summary of the way it works! > > On Nov 7, 2013, at 10:22 PM, Deneau, Tom wrote: > >> Doug -- >> >> Trying to see if I understand how these pieces fit together. >> >> NewObjectSnippets.allocateInstance makes a call to >> NewInstanceStubCall.call if the current tlab does not have enough >> room. >> >> NewInstanceStubCall.call looks up the ForeignCallLinkage and finds >> that it is not a simple foreign call to a specific foreign call >> address (its address is 0) but instead has a stub associated with it. >> I think this association came from the call to >> >> link(new NewInstanceStub(providers, target, >> registerStubCall(NEW_INSTANCE, REEXECUTABLE, NOT_LEAF, >> ANY_LOCATION))); >> >> in HotSpotHostForeingCallsProvider.java >> >> So when we try to finalizeAddress for the ForeignCallLinkage we end >> up compiling this stub. >> >> The stub is a SnippetStub implemented with the snippet called >> "newInstance" in NewInstanceStub.java and tries to get a new tlab >> using CAS operations. If this stub cannot get a new tlab it makes a >> "real" foreign call using >> newInstanceC(NEW_INSTANCE_C, thread(), hub); >> >> which ends up going to the graalRuntime::new_instance >> >> >> -----Original Message----- >> From: Doug Simon [mailto:doug.simon at oracle.com] >> Sent: Tuesday, October 22, 2013 4:42 AM >> To: Deneau, Tom >> Cc: graal-dev at openjdk.java.net; sumatra-dev at openjdk.java.net >> Subject: Re: non-foreign-call tlab refill from hsail >> >> >> On Oct 22, 2013, at 12:18 AM, "Deneau, Tom" wrote: >> >>> We are experimenting with object (and array) allocation from an HSA >>> device (using graal for >>> >>> the HSAIL codegen). Where we are now: >>> >>> >>> >>> * the hsa workitems are using TLABs from "donor threads" who exist >>> >>> just to supply TLABs and don't do any allocation themselves. >>> >>> >>> >>> * To reduce the number of donor threads required, a TLAB can be >>> >>> used by more than one workitem, in which case the workitems use >>> >>> HSAIL atomic_add instructions to bump the tlab top pointer. >>> >>> >>> >>> * the HSAIL backend has its own fastpath allocation snippets >>> >>> which generate the HSAIL atomic_add instructions which >>> >>> override the snippets in NewObjectSnippets.java >>> >>> >>> >>> Some junit tests have been written and pass which allocate objects, or arrays of primitives, or arrays of objects. >>> >>> >>> >>> All the above only works for the fastpath case, i.e., if there is indeed enough space in the donor TLAB. We realize there are other cases: >>> >>> >>> >>> a) not enough space in current TLAB but ability to allocate a new TLAB. >>> >>> >>> >>> b) not able to allocate a new TLAB, GC required. >>> >>> >>> >>> For only case a) above, we would like to experiment with grabbing >>> the new TLAB from HSAIL without making a "foreign call" to the VM. >>> From the hotspot code, I assume the logic required is what one sees >>> in >>> >>> mutableSpace::cas_allocate(size_t size) at least for the non-G1 case. >> >> When the NewInstanceStub fails to allocate a new TLAB, it calls out to GraalRuntime::new_instance (in graalRuntime.cpp). >> >>> Some of this non-foreign-call allocation logic appears to exist in >>> the Snippet called NewInstanceStub.newInstance (as opposed to >>> NewObjectSnippets.allocateInstance snippet which is what we are >>> currently overriding). This comments for this snippet say >>> >>> "Re-attempts allocation after an initial TLAB allocation failed or >>> >>> was skipped (e.g., due to * -XX:-UseTLAB)." >>> >>> >>> >>> Is this NewInstanceStub.newInstance snippet actually used anywhere in the current graal framework. >> >> Yes, you can see a call to NewInstanceStubCall in NewObjectSnippets.allocateInstance. >> >>> Is this a starting point we could use to get a non-foreign-call TLAB refill working? >> >> Yes. Note that this call *is* a foreign call (see the javadoc for ForeignCallDescriptor). >> >> -Doug >> > > > From doug.simon at oracle.com Thu Nov 7 14:38:14 2013 From: doug.simon at oracle.com (Doug Simon) Date: Thu, 7 Nov 2013 23:38:14 +0100 Subject: non-foreign-call tlab refill from hsail In-Reply-To: References: <33F60C70-33F8-40F6-AE82-DD817293856C@oracle.com> <36423EAD-CDB9-4F3B-BDD4-E210C5EE3FB5@oracle.com> Message-ID: On Nov 7, 2013, at 11:21 PM, Deneau, Tom wrote: > Are snippets required to inline all their calls? Generally speaking, yes. > Or alternatively is there no way to annotate that a method should not be inlined? You can use the Snippet.SnippetInliningPolicy class to control inlining during snippet preparation. -Doug > -----Original Message----- > From: Doug Simon [mailto:doug.simon at oracle.com] > Sent: Thursday, November 07, 2013 4:15 PM > To: Deneau, Tom > Cc: graal-dev at openjdk.java.net; sumatra-dev at openjdk.java.net > Subject: Re: non-foreign-call tlab refill from hsail > > Because it is slow (well, medium) path code that we don't want to inline at every allocation site. > > On Nov 7, 2013, at 11:13 PM, Deneau, Tom wrote: > >> So I was trying to understand why the NewInstanceStub.newInstance Stub >> code was not just included in the original NewObjectSnippet.allocateInstance snippet. >> >> -- Tom >> >> >> -----Original Message----- >> From: Doug Simon [mailto:doug.simon at oracle.com] >> Sent: Thursday, November 07, 2013 4:04 PM >> To: Deneau, Tom >> Cc: graal-dev at openjdk.java.net; sumatra-dev at openjdk.java.net >> Subject: Re: non-foreign-call tlab refill from hsail >> >> That is a very correct summary of the way it works! >> >> On Nov 7, 2013, at 10:22 PM, Deneau, Tom wrote: >> >>> Doug -- >>> >>> Trying to see if I understand how these pieces fit together. >>> >>> NewObjectSnippets.allocateInstance makes a call to >>> NewInstanceStubCall.call if the current tlab does not have enough >>> room. >>> >>> NewInstanceStubCall.call looks up the ForeignCallLinkage and finds >>> that it is not a simple foreign call to a specific foreign call >>> address (its address is 0) but instead has a stub associated with it. >>> I think this association came from the call to >>> >>> link(new NewInstanceStub(providers, target, >>> registerStubCall(NEW_INSTANCE, REEXECUTABLE, NOT_LEAF, >>> ANY_LOCATION))); >>> >>> in HotSpotHostForeingCallsProvider.java >>> >>> So when we try to finalizeAddress for the ForeignCallLinkage we end >>> up compiling this stub. >>> >>> The stub is a SnippetStub implemented with the snippet called >>> "newInstance" in NewInstanceStub.java and tries to get a new tlab >>> using CAS operations. If this stub cannot get a new tlab it makes a >>> "real" foreign call using >>> newInstanceC(NEW_INSTANCE_C, thread(), hub); >>> >>> which ends up going to the graalRuntime::new_instance >>> >>> >>> -----Original Message----- >>> From: Doug Simon [mailto:doug.simon at oracle.com] >>> Sent: Tuesday, October 22, 2013 4:42 AM >>> To: Deneau, Tom >>> Cc: graal-dev at openjdk.java.net; sumatra-dev at openjdk.java.net >>> Subject: Re: non-foreign-call tlab refill from hsail >>> >>> >>> On Oct 22, 2013, at 12:18 AM, "Deneau, Tom" wrote: >>> >>>> We are experimenting with object (and array) allocation from an HSA >>>> device (using graal for >>>> >>>> the HSAIL codegen). Where we are now: >>>> >>>> >>>> >>>> * the hsa workitems are using TLABs from "donor threads" who exist >>>> >>>> just to supply TLABs and don't do any allocation themselves. >>>> >>>> >>>> >>>> * To reduce the number of donor threads required, a TLAB can be >>>> >>>> used by more than one workitem, in which case the workitems use >>>> >>>> HSAIL atomic_add instructions to bump the tlab top pointer. >>>> >>>> >>>> >>>> * the HSAIL backend has its own fastpath allocation snippets >>>> >>>> which generate the HSAIL atomic_add instructions which >>>> >>>> override the snippets in NewObjectSnippets.java >>>> >>>> >>>> >>>> Some junit tests have been written and pass which allocate objects, or arrays of primitives, or arrays of objects. >>>> >>>> >>>> >>>> All the above only works for the fastpath case, i.e., if there is indeed enough space in the donor TLAB. We realize there are other cases: >>>> >>>> >>>> >>>> a) not enough space in current TLAB but ability to allocate a new TLAB. >>>> >>>> >>>> >>>> b) not able to allocate a new TLAB, GC required. >>>> >>>> >>>> >>>> For only case a) above, we would like to experiment with grabbing >>>> the new TLAB from HSAIL without making a "foreign call" to the VM. >>>> From the hotspot code, I assume the logic required is what one sees >>>> in >>>> >>>> mutableSpace::cas_allocate(size_t size) at least for the non-G1 case. >>> >>> When the NewInstanceStub fails to allocate a new TLAB, it calls out to GraalRuntime::new_instance (in graalRuntime.cpp). >>> >>>> Some of this non-foreign-call allocation logic appears to exist in >>>> the Snippet called NewInstanceStub.newInstance (as opposed to >>>> NewObjectSnippets.allocateInstance snippet which is what we are >>>> currently overriding). This comments for this snippet say >>>> >>>> "Re-attempts allocation after an initial TLAB allocation failed or >>>> >>>> was skipped (e.g., due to * -XX:-UseTLAB)." >>>> >>>> >>>> >>>> Is this NewInstanceStub.newInstance snippet actually used anywhere in the current graal framework. >>> >>> Yes, you can see a call to NewInstanceStubCall in NewObjectSnippets.allocateInstance. >>> >>>> Is this a starting point we could use to get a non-foreign-call TLAB refill working? >>> >>> Yes. Note that this call *is* a foreign call (see the javadoc for ForeignCallDescriptor). >>> >>> -Doug >>> >> >> >> > > > From duboscq at ssw.jku.at Thu Nov 7 23:56:06 2013 From: duboscq at ssw.jku.at (Gilles Duboscq) Date: Fri, 8 Nov 2013 08:56:06 +0100 Subject: webrev for hsail backend merging with new providers infrastructure In-Reply-To: <16BA4787-DA30-4D21-A7B7-B4149C498D40@oracle.com> References: <0DB6F95F-9B2F-42BC-B29D-7CCA428C2CC0@oracle.com> <16BA4787-DA30-4D21-A7B7-B4149C498D40@oracle.com> Message-ID: For this kind of scenario in general you would need to fork the VM and change just that one option, I don't think there is support for this kind of things in JUnit and its usually not trivial to do. The jcstress and jmh tools (http://openjdk.java.net/projects/code-tools/) need to do something like that for example. -Gilles On 7 Nov 2013 23:06, "Doug Simon" wrote: > > On Nov 7, 2013, at 10:54 PM, Deneau, Tom wrote: > > > Doug -- > > > > Sometimes we want to run a test with several different max heap sizes > because it forces different types of Compressed Oops encoding, etc. Can > that type of change be handled by this scoped overriding of options? (I > assume not). > > Unfortunately not. The scoped overriding mechanism is only supported for > Graal options, not HotSpot options. > > -Doug > > > -----Original Message----- > > From: Doug Simon [mailto:doug.simon at oracle.com] > > Sent: Tuesday, November 05, 2013 8:06 AM > > To: Deneau, Tom > > Cc: graal-dev at openjdk.java.net > > Subject: Re: webrev for hsail backend merging with new providers > infrastructure > > > > > > On Nov 4, 2013, at 6:19 PM, Doug Simon wrote: > > > >> > >> On Nov 4, 2013, at 5:27 PM, Deneau, Tom wrote: > >> > >>> Hi Doug -- > >>> > >>> Some of our java 8 based unit tests (which use lambdas) use these two > libraries currently, but you're right we don't use them in the java 7 based > tests yet. If you want to remove them from the public mx/projects, go > ahead. > >>> > >>> This points to a hole in our testing strategy which we've always been > aware of. We have written a number of java 8 style unit tests that we test > locally here but that don't get exercised in the public repository. We > could of course add similar java 7 based unit tests and push them to public > but we haven't done that work, and if graal is going to support 8 soon, > there wouldn't be a need for that conversion work. > >> > >> Yes, I suggest to keep just running these tests locally until Graal has > transitioned to 8. > >> > >>> On a related note, I think Vasanth mentioned that we run our unit > tests locally here with the flags -G:+InlineEverything > -G:-RemoveNeverExecutedCode. We need InlineEverything because we don't > support HSAIL function calls yet. Several test cases have a line like > >>> assumeTrue(aggressiveInliningEnabled()); > >>> > >>> and of course these just get skipped if -G:+InlineEverything is not > set. Is it possible to get the hsail tests that get run at Oracle to use > these two flags? > >> > >> We don't currently have infrastructure for running tests in a different > VM instances based on required command line option settings. What we > ideally want (in this case at least) is for options such as > InlineEverything and RemoveNeverExecutedCode to be overridable in a scoped > manner (e.g., for individual compilations). Until we have support for this > however, we'll have to rely on your testing setup to run these tests. > > > > There is now support for scoped overriding of options[1]. For example, > in StaticNBodyCallTest: > > > > @Test > > @Override > > public void test() throws Exception { > > Field f = > GraalOptions.class.getDeclaredField("RemoveNeverExecutedCode"); > > f.setAccessible(true); > > OptionValue removeNeverExecutedCode = (OptionValue) > f.get(null); > > try (OverrideScope s = > OptionValue.override(GraalOptions.InlineEverything, true, > removeNeverExecutedCode, false)) { > > assumeTrue(aggressiveInliningEnabled() || > canHandleHSAILMethodCalls()); > > testGeneratedHsail(); > > } > > } > > > > > > [1] http://hg.openjdk.java.net/graal/graal/rev/38bf986ce231 > > > > -Doug > > > >>> -----Original Message----- > >>> From: Doug Simon [mailto:doug.simon at oracle.com] > >>> Sent: Monday, November 04, 2013 9:30 AM > >>> To: Deneau, Tom > >>> Cc: graal-dev at openjdk.java.net > >>> Subject: Re: webrev for hsail backend merging with new providers > infrastructure > >>> > >>> Actually, one quick question: Do we really need the VECMATH and > APACHELANG libraries declared in mx/projects[1]? None of the projects seem > to use them. > >>> > >>> -Doug > >>> > >>> [1] > http://cr.openjdk.java.net/~tdeneau/graal-webrevs/webrev-infrastructure-merge/webrev/mx/projects.udiff.html > >>> > >>> On Nov 1, 2013, at 11:54 PM, Deneau, Tom wrote: > >>> > >>>> All -- > >>>> > >>>> I have posted a small webrev to > >>>> > http://cr.openjdk.java.net/~tdeneau/graal-webrevs/webrev-infrastructure-merge/webrev/ > >>>> > >>>> This is the result of our merge with the recent providers > infrastructure. Could you please look this over? > >>>> > >>>> Here is a brief summary: > >>>> > >>>> > >>>> HSAILHotSpotForeignCallsProvider.java > >>>> ------------------------------------- > >>>> . As noted in the comments, we don't really support foreign calls > yet, yet we do get asked to handle ForeignCall nodes, and we want to > generate dummy code for them. We just support them all and lazily create > dummy linkages here. When we finally support foreign calls we will > explicitly register the ones we want to support. > >>>> > >>>> HSAILHotSpotLIRGenerator.java, HSAILLIRGenerator.java, > HSAILControlFlow.java > >>>> > ---------------------------------------------------------------------------- > >>>> . This again is part of the dummy Foreign Call support. Some less > extensive ForeignCall support used to be in HSAILLIRGenerator. > >>>> > >>>> HSAILHotSpotReplacementsImpl.java > >>>> --------------------------------- > >>>> . This is another one of the providers in the new runtime > infrastructure. For both macro substitutions and method substitutions, we > just delegate to the host substitution list. This is a quick solution > which allows things like Math.sqrt, and some of the Unsafe methods to work > for HSAIL, similar to the way these substitutions worked before the > providers change. Eventually, we will explicitly list which substitutions > we will support. > >>>> > >>>> HSAIL.java > >>>> ---------- > >>>> . Not really part of the webrev infrastructure merge but since we're > planning to limit the number of registers actually used by the graal > compiler, it seemed appropriate to push this out. > >>>> > >>>> Tests > >>>> ----- > >>>> . With the ForeignCall support above, some test cases that were > marked as failing are now passing. > >>>> > >>>> KernelTester.java > >>>> ----------------- > >>>> . Not really part of the webrev infrastructure merge but added a > property to allow running the gpu code either first or second vs. the java > code in our test cases. > >>>> > >>>> > >>>> -- Tom Deneau > >>>> > >>>> > >>> > >>> > >>> > >> > > > > > > > > From christian.humer at gmail.com Fri Nov 8 08:48:18 2013 From: christian.humer at gmail.com (Christian Humer) Date: Fri, 8 Nov 2013 17:48:18 +0100 Subject: Truffle DSL feature suggestions In-Reply-To: References: <60F35720-B657-476D-96E5-AA870765DF72@vub.ac.be> Message-ID: Hi Stefan, Seems that your making good progress! Support for inheriting @NodeChild > ????????????????????????????????- > The next thing I noticed is that @NodeChild annotation are not inherited > when the subclass defines additional @NodeChilds. While it is not a big > issue, it feel counter intuitive when I noticed it for the first time. My > expectation was that these annotations have an additive semantics. > As an example, I have a AbstractMonomorphicMessageNode [3] with the > @NodeChild(value = ?receiver?, ExpN.class) annotation, and in the subclass > BinaryMonomorphicNode [4] I need to specify the receiver again, because I > want to add an argument NodeChild. @NodeChild elements should be inherited already. Unfortunately there is a bug when inheriting more than one @NodeChild defined int he base class and there is another @NodeChild annotation defined in the inheriting class, the second @NodeChild of the base class is not inherited. Seems that nobody used this annotation in this way so far ;-). Will fix this and keep you posted. However, what already works is using a variable number of arguments @NodeChild in the base class like this: @NodeChildren({@NodeChild(value = "receiver", type = ValueNode.class), @NodeChild(value = "arguments", type = ValueNode[].class)}) abstract static class BaseNode extends ValueNode { public abstract ValueNode getReceiver(); public abstract ValueNode[] getArguments(); } abstract static class UnaryNode extends BaseNode { @Specialization public int doIt(Object receiver, int value0) { return value; } } abstract static class BinaryNode extends BaseNode { @Specialization public int doIt(Object receiver, int value0, int value1) { return value0 + value1; } } abstract static class TernaryNode extends BaseNode { @Specialization public int doIt(Object receiver, int value0, int value1, int value2) { return value0 + value1 + value2; } } Also take a look at the generated code. There you can see that instead of accessing a field per child the generated source now accesses the children in an array using fixed indexes. So for the third value it accesses arguments[1].execute() to execute the value. Please note that all specializations in one operation must have the same number of arguments. Using the NodeFactory#getExecutionSignature() method you can find out the actual number of arguments that were used dynamically. So you would be able to write one generic rewrite mechanism. Allowing @Generic for Simple Nodes ?????????????????????????????????- > In my new node hierarchy, I use UnaryMessageNode (..Binary/Ternary/KeywordMsgNode) > [2] to represent the initial state of message send as generated by the > parser. So, the main idea is to avoid specialization before execution > starts. The parser could do some simple specializations already purely > based on the static name of a message. However, I decided against doing > that, following what I understand to be one of the main suggestions for > Truffle. > As a result I have the UnaryMessageNode (Binary/Ternary/Keyword) class > just implementing a doGeneric(.) method, which replace the node by a > UnaryMonomorphicNode. For the doGeneric(.) method, I feel that @Generic > would be the better annotation, and putting @Specialization there, because > it otherwise wouldn?t have a specialization, feels a little unnatural. The > @Generic annotation also has another benefit, because it enforces certain > constraints on the method signature, which is useful to make the type > system happy. I see your point. Just @Generic should be possible. I've put it on my list. I do not recommend doing manual replaces inside of @Specialization or @Generic annotated methods at all. Think of the use-case of polymorphic chains where a call to replace would just replace one entry of the polymorphic chain. This would lead to a wrong tree. If you want do do that please turn off the polymorphic chaining by using @PolymorphicDepth(0). But I don't think you will need that if you do it the way I describe it below. Polymorphic Inline Caching > ?????????????????????????- First thanks for your input on the new DSL feature. I hope we will be able to implement it soon. Let me explain to you how polymorphic inline caches are currently implemented in most of the truffle languages by referencing what i think you want to achieve. final class Message { String name; ... CallTarget target; ... } Each available message is represented as such an instance. A CallTarget for the message can be created by a call to Truffle.getRuntime().createCallTarget(...). These Message instances are usually stored in a global map or a similar concept. For a call you start off with one uninitialized call/message node which has a child for receiving the function and one for the receiver. class UninitializedSendNode { message = ... // returns a Message (may do a lookup in a local variable or global map) receiver = ... // returns the receiver object uninitializedArguments[] = ... // the uninitialized arguments of the call as they are parsed } When the first call to the execute method in UninitializedMessageNode occurs the uninitialized node creates a cache like this: class CachedSendNode { final CallTarget cachedTarget; // the call target this node is specialized on receiver, message; uninitializedArguments[]; current = DispatchedSendNode // Implementation of the call (may get inlined later or immediatly) arguments // copied from uninitializedArguments next = UninitializedMessageNode or again CachedSendNode // how an implementation for that node could look like: Object execute(VirtualFrame frame) { Object receiver = receiver.execute(frame); // we need to ensure that the receiver is just evaluated once per call Message m = message.execute(frame); if (this.cachedTarget == m.getCallTargetTarget()) { return current.execute(frame, receiver); } return next.execute(frame, receiver); } } This CachedSendNode can be chained as a cache using the next field. After reaching some depth the chain should rewrite itself to a GenericSendNode which then does not store the callTarget as a final field but always dispatches the call to the callTarget (no inlining possible anymore). Each DispatchedSendNode knows about their callTarget as a final field and just calls the constant/final CallTarget in the default case. After some inlining policy (which could be immediately, later or not at all) the DispatchedSendNode gets replaced by a compatible node which represents the CallTarget. This can usually be achieved by casting the CallTarget to DefaultCallTarget and looking at its RootNode to copy it. I think the described pattern should work for you and it has been proven to work for our implementations. I will try to put together an example using the SimpleLanguage next week. Have a nice weekend! Christian Humer On Thu, Nov 7, 2013 at 5:30 PM, Stefan Marr wrote: > Hi Christian, > Hi all: > > On 07 Nov 2013, at 14:27, Christian Humer > wrote: > > > Unfortunately it is not and I also failed myself to abuse it in that > way. There are some features (eg. caching of values) missing to declare > polymorphic inline caches using the DSL. At the moment all polymorphic > inline caches are implemented manually using Truffle API only. We are still > in phase of collecting required use-cases to compile a list of required DSL > features to support it. There are some concepts like resorting of cache > entries or generic cache entry promotion (not completely go to generic but > keep some hot cache entries) which would also be quite difficult to > support. But we would be happy if we could use your implementation as an > additional use-case for DSL support. > > I am just about to finish a rather large rewrite of TruffleSOM [1]. > And for that it would be very useful if I could coerce the DSL into > generating multiple cases out of a single specialization in order to handle > polymorphic message sends. > > Overall, I think, I have three suggestions based on the TruffleSOM rewrite. > I?ll try to detail them below to outline the use case and my > understanding. Perhaps somethings are by design and should be done > differently. > > The three things I would like to suggest are: > > - Allowing @Generic for simple non-specializing nodes, as a base case > (uninitialized state) for custom specialization hierarchies > - Support for inheriting @NodeChilds > - Support for polymorphic inline caching, perhaps based on chaining > multiple instances of the same specialization. > > > Allowing @Generic for Simple Nodes > ?????????????????????????????????- > > In my new node hierarchy, I use UnaryMessageNode > (..Binary/Ternary/KeywordMsgNode) [2] to represent the initial state of > message send as generated by the parser. So, the main idea is to avoid > specialization before execution starts. The parser could do some simple > specializations already purely based on the static name of a message. > However, I decided against doing that, following what I understand to be > one of the main suggestions for Truffle. > > As a result I have the UnaryMessageNode (Binary/Ternary/Keyword) class > just implementing a doGeneric(.) method, which replace the node by a > UnaryMonomorphicNode. For the doGeneric(.) method, I feel that @Generic > would be the better annotation, and putting @Specialization there, because > it otherwise wouldn?t have a specialization, feels a little unnatural. The > @Generic annotation also has another benefit, because it enforces certain > constraints on the method signature, which is useful to make the type > system happy. > > > Support for inheriting @NodeChild > ????????????????????????????????- > > The next thing I noticed is that @NodeChild annotation are not inherited > when the subclass defines additional @NodeChilds. While it is not a big > issue, it feel counter intuitive when I noticed it for the first time. My > expectation was that these annotations have an additive semantics. > > As an example, I have a AbstractMonomorphicMessageNode [3] with the > @NodeChild(value = ?receiver?, ExpN.class) annotation, and in the subclass > BinaryMonomorphicNode [4] I need to specify the receiver again, because I > want to add an argument NodeChild. > > > Polymorphic Inline Caching > ?????????????????????????- > > I assume that you got already a number of specific use case form other > Truffle languages, so I will try to outline how I would imagine potential > support for PICs in the DSL based on what I see in TruffleSOM. > > One thing upfront: I decided that it want to try to conflate the notion of > monomorphic message sends and primitive implementations. > Thus, you will currently find the following hierarchy of nodes in > TruffleSOM (still need to figure out whether that?s actually going to work): > > ExpressionNode > +- AbstractMessageNode > | +- AbstractMonomorphicMessageNode > | +- BinaryMonomorphicNode > | | +- AdditionPrimitive > | | +- MultiplicationPrimitive > | +- UnaryMonomorphicNode > | +- PrintPrimitive > | +- ... > +- BinaryMessageNode > +- UnaryMessageNode > +- ... > > The reason why I thought that might be a good idea is to essential see > every specialization for the primitive nodes as one variant of a > potentially polymorphic message send. > > Let?s assume we have a #print primitive implemented for strings, and > normal #print messages for other types of object, implementing something > custom to first convert the value into a string and then printing it. > > So, a nice polymorphic example would be something like the following loop > over an array: `{1. ?two?. #three. 4.0. FiveClass} do: [:elem | elem > print]`. > > The print primitive could than be implemented like this: > > public abstract class PrintStringPrim extends UnaryMonomorphicNode { > public PrintStringPrim(final SSymbol selector, final Universe > universe, final SClass rcvrClass, final SMethod invokable) { > super(selector, universe, rcvrClass, > invokable); } > public PrintStringPrim(final PrintStringPrim prim) { > this(prim.selector, prim.universe, prim.rcvrClass, prim.invokable); } > > @Specialization > public Object doSString(final SString receiver) { > Universe.print(receiver.getEmbeddedString()); > return receiver; > } > } > > And the UnaryMonomorphicNode implements a simple monomorphic method cache: > > public abstract class UnaryMonomorphicNode extends > AbstractMonomorphicMessageNode { > > @Specialization(guards = "isCachedReceiverClass", order = > PriorityMonomorphicCase) > public SAbstractObject doMonomorphic(final VirtualFrame frame, final > SAbstractObject receiver) { > return invokable.invoke(frame.pack(), receiver, noArgs); > } > } > > So, my understanding is now that a normal node that has multiple > specializations, perhaps based on types, can become ?node-polymorphic?. > Thus, multiple specializations get instantiated and instead of replacing a > previous specialization, they get chained one after another. > And then, during execution, you walk the chain to find the one where the > guards do not fail. > I understand now that this chain can build up because there are multiple > cases that can be easily identified based on different guards/tests. > However, for the doMonomorphic(.) method, it is not multiple tests, it is > not multiple specializations. > Instead, the value on which a test is based differs. > > So, what I would find useful is if I could tell the DSL to multiply my > specialization doMonomorphic(.) up to a given number of times, and then, I > think for the instantiation, I would also need to give it a function that > allows it to derive the necessary state for such ?value-based? > specializations. > > Perhaps something like this: > > @Specialization(guards = ?isCachedReceiverClass?, order = > PriorityMonomorphicCase, > multiplicity = 8, specialization = {rcvrClass = > ?classOfReceiver?, invokable = ?lookUp? } ) > public SAbstractObject doMonomorphic(final VirtualFrame frame, final > SAbstractObject receiver) { /* ... /* } > > public SClass classOfReceiver(final SAbstractObject receiver) { > return classOfReceiver(receiver, getReceiver()); > } > > public SMethod lookUp(final SAbstractObject receiver) { > return classOfReceiver(receiver).lookupInvokable(selector); > } > > I think, this might give me enough flexibility to express value-based > specialization for polymorphic messages. > > When it comes to cleaning up or optimizing such polymorphic-node chains, > well, I don?t know enough how it would behave yet. So, no ideas there so > far. > > Would be interested to hear whether any of that sounds like it fits into > how you see Truffle being used. > > Thanks > Stefan > > > > [1] > https://github.com/smarr/TruffleSOM/commit/482ccaa88306a1e7a989afdfd91e4121c5be163a > [2] > https://github.com/smarr/TruffleSOM/blob/482ccaa88306a1e7a989afdfd91e4121c5be163a/src/som/interpreter/nodes/UnaryMessageNode.java#L30 > [3] > https://github.com/smarr/TruffleSOM/blob/482ccaa88306a1e7a989afdfd91e4121c5be163a/src/som/interpreter/nodes/messages/AbstractMonomorphicMessageNode.java#L18 > [4] > https://github.com/smarr/TruffleSOM/blob/482ccaa88306a1e7a989afdfd91e4121c5be163a/src/som/interpreter/nodes/messages/BinaryMonomorphicNode.java#L21 > -- > Stefan Marr > Software Languages Lab > Vrije Universiteit Brussel > Pleinlaan 2 / B-1050 Brussels / Belgium > http://soft.vub.ac.be/~smarr > Phone: +32 2 629 2974 > Fax: +32 2 629 3525 > > From Monir.Mozumder at amd.com Fri Nov 8 14:17:00 2013 From: Monir.Mozumder at amd.com (Mozumder, Monir) Date: Fri, 8 Nov 2013 22:17:00 +0000 Subject: Error compiling example code for HSAIL generation Message-ID: I am trying to compile an example code from this page: http://www.tuicool.com/articles/eEFRR3?jdfwkey=d741l1 ~/dev/sumatra/test$ cat IntSquaredTest.java package com.oracle.graal.compiler.hsail.test; import org.junit.Test; import java.util.logging.*; public class IntSquaredTest extends StaticMethodTwoIntArrays { public static void run(int[] out, int[] in, int gid) { out[gid] = in[gid] * in[gid]; } @Test public void test() { super.testGeneratedHsail(); } } I see errors when trying to do the compilation step: mx --vm server unittest hsail.test.IntSquaredTest. ~/dev/sumatra/test$ mx --vm server unittest hsail.test.IntSquaredTest # # A fatal error has been detected by the Java Runtime Environment: # # Internal Error (graalJavaAccess.cpp:42), pid=12108, tid=140148517222144 # fatal error: Invalid layout of registerRefMap at com.oracle.graal.api.code.DebugInfo # # JRE version: Java(TM) SE Runtime Environment (8.0-b112) (build 1.8.0-ea-b112) # Java VM: OpenJDK 64-Bit Server VM (25.0-b53-internal mixed mode linux-amd64 compressed oops) # Failed to write core dump. Core dumps have been disabled. To enable core dumping, try "ulimit -c unlimited" before starting Java again # # An error report file with more information is saved as: # /home/munir/dev/sumatra/test/hs_err_pid12108.log # # If you would like to submit a bug report, please visit: # http://bugreport.sun.com/bugreport/crash.jsp # The crash happened outside the Java Virtual Machine in native code. # See problematic frame for where to report the bug. # See below for my setup details. I am also providing some snippets from hs_err_pid12108.log . Any ideas? Bests, -Monir ~/dev/sumatra/test$ which javac /home/munir/dev/sumatra/simulator/build_linux/grail/profuct/bin/javac ~/dev/sumatra/test$ java -version java version "1.8.0-ea" Java(TM) SE Runtime Environment (build 1.8.0-ea-b112) Java HotSpot(TM) 64-Bit Server VM (build 25.0-b54, mixed mode) ============================== excerpts from hs_err_pid12108.log # # A fatal error has been detected by the Java Runtime Environment: # # Internal Error (graalJavaAccess.cpp:42), pid=12108, tid=140148517222144 # fatal error: Invalid layout of registerRefMap at com.oracle.graal.api.code.DebugInfo # # JRE version: Java(TM) SE Runtime Environment (8.0-b112) (build 1.8.0-ea-b112) # Java VM: OpenJDK 64-Bit Server VM (25.0-b53-internal mixed mode linux-amd64 compressed oops) # Failed to write core dump. Core dumps have been disabled. To enable core dumping, try "ulimit -c unlimited" before starting Java again # # If you would like to submit a bug report, please visit: # http://bugreport.sun.com/bugreport/crash.jsp # The crash happened outside the Java Virtual Machine in native code. # See problematic frame for where to report the bug. # --------------- T H R E A D --------------- Current thread (0x00007f76d800d800): JavaThread "main" [_thread_in_native, id=12109, stack(0x00007f76de85b000,0x00007f76de95c000)] Stack: [0x00007f76de85b000,0x00007f76de95c000], sp=0x00007f76de95a860, free space=1022k Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) V [libjvm.so+0x96f8b6] VMError::report_and_die()+0x166 V [libjvm.so+0x46c773] report_fatal(char const*, int, char const*)+0x53 V [libjvm.so+0x555439] compute_offset(int&, Klass*, char const*, char const*, bool)+0x2e9 V [libjvm.so+0x555f13] graal_compute_offsets()+0xa93 V [libjvm.so+0x5461b6] GraalCompiler::initialize()+0x436 V [libjvm.so+0x5f65ee] JNI_CreateJavaVM+0xde C [libjli.so+0x703e] JavaMain+0x9e --------------- P R O C E S S --------------- ~ ~ ~ From Monir.Mozumder at amd.com Fri Nov 8 14:26:21 2013 From: Monir.Mozumder at amd.com (Mozumder, Monir) Date: Fri, 8 Nov 2013 22:26:21 +0000 Subject: Error compiling example code for HSAIL generation Message-ID: More setup details: graal setup: done as per https://wiki.openjdk.java.net/display/Graal/Instructions (hg clone http://hg.openjdk.java.net/graal/graal) HSA simulator setup: https://wiki.openjdk.java.net/display/Sumatra/The+HSAIL+Simulator (installed all 3 components) Though the HAS simulator setup does not matter here, I am mentioning it for giving the environment. Upon setting up grail, I pointed JAVA_HOME to be from its product folder. All test cases from simulator and grail seem to work fine. Bests, -Monir From tom.deneau at amd.com Fri Nov 8 14:44:12 2013 From: tom.deneau at amd.com (Deneau, Tom) Date: Fri, 8 Nov 2013 22:44:12 +0000 Subject: scoped overriding of graal options In-Reply-To: <16BA4787-DA30-4D21-A7B7-B4149C498D40@oracle.com> References: <0DB6F95F-9B2F-42BC-B29D-7CCA428C2CC0@oracle.com> <16BA4787-DA30-4D21-A7B7-B4149C498D40@oracle.com> Message-ID: Doug -- OK, this still looks very useful. One small complaint, I did a println of the overridden option while debugging, and it just showed the original value from the command line. Maybe toString could show both the original value and the overridden value (if different) -- Tom -----Original Message----- From: Doug Simon [mailto:doug.simon at oracle.com] Sent: Thursday, November 07, 2013 4:05 PM To: Deneau, Tom Cc: graal-dev at openjdk.java.net Subject: Re: webrev for hsail backend merging with new providers infrastructure On Nov 7, 2013, at 10:54 PM, Deneau, Tom wrote: > Doug -- > > Sometimes we want to run a test with several different max heap sizes because it forces different types of Compressed Oops encoding, etc. Can that type of change be handled by this scoped overriding of options? (I assume not). Unfortunately not. The scoped overriding mechanism is only supported for Graal options, not HotSpot options. -Doug > -----Original Message----- > From: Doug Simon [mailto:doug.simon at oracle.com] > Sent: Tuesday, November 05, 2013 8:06 AM > To: Deneau, Tom > Cc: graal-dev at openjdk.java.net > Subject: Re: webrev for hsail backend merging with new providers infrastructure > > > On Nov 4, 2013, at 6:19 PM, Doug Simon wrote: > >> >> On Nov 4, 2013, at 5:27 PM, Deneau, Tom wrote: >> >>> Hi Doug -- >>> >>> Some of our java 8 based unit tests (which use lambdas) use these two libraries currently, but you're right we don't use them in the java 7 based tests yet. If you want to remove them from the public mx/projects, go ahead. >>> >>> This points to a hole in our testing strategy which we've always been aware of. We have written a number of java 8 style unit tests that we test locally here but that don't get exercised in the public repository. We could of course add similar java 7 based unit tests and push them to public but we haven't done that work, and if graal is going to support 8 soon, there wouldn't be a need for that conversion work. >> >> Yes, I suggest to keep just running these tests locally until Graal has transitioned to 8. >> >>> On a related note, I think Vasanth mentioned that we run our unit tests locally here with the flags -G:+InlineEverything -G:-RemoveNeverExecutedCode. We need InlineEverything because we don't support HSAIL function calls yet. Several test cases have a line like >>> assumeTrue(aggressiveInliningEnabled()); >>> >>> and of course these just get skipped if -G:+InlineEverything is not set. Is it possible to get the hsail tests that get run at Oracle to use these two flags? >> >> We don't currently have infrastructure for running tests in a different VM instances based on required command line option settings. What we ideally want (in this case at least) is for options such as InlineEverything and RemoveNeverExecutedCode to be overridable in a scoped manner (e.g., for individual compilations). Until we have support for this however, we'll have to rely on your testing setup to run these tests. > > There is now support for scoped overriding of options[1]. For example, in StaticNBodyCallTest: > > @Test > @Override > public void test() throws Exception { > Field f = GraalOptions.class.getDeclaredField("RemoveNeverExecutedCode"); > f.setAccessible(true); > OptionValue removeNeverExecutedCode = (OptionValue) f.get(null); > try (OverrideScope s = OptionValue.override(GraalOptions.InlineEverything, true, removeNeverExecutedCode, false)) { > assumeTrue(aggressiveInliningEnabled() || canHandleHSAILMethodCalls()); > testGeneratedHsail(); > } > } > > > [1] http://hg.openjdk.java.net/graal/graal/rev/38bf986ce231 > > -Doug > >>> -----Original Message----- >>> From: Doug Simon [mailto:doug.simon at oracle.com] >>> Sent: Monday, November 04, 2013 9:30 AM >>> To: Deneau, Tom >>> Cc: graal-dev at openjdk.java.net >>> Subject: Re: webrev for hsail backend merging with new providers infrastructure >>> >>> Actually, one quick question: Do we really need the VECMATH and APACHELANG libraries declared in mx/projects[1]? None of the projects seem to use them. >>> >>> -Doug >>> >>> [1] http://cr.openjdk.java.net/~tdeneau/graal-webrevs/webrev-infrastructure-merge/webrev/mx/projects.udiff.html >>> >>> On Nov 1, 2013, at 11:54 PM, Deneau, Tom wrote: >>> >>>> All -- >>>> >>>> I have posted a small webrev to >>>> http://cr.openjdk.java.net/~tdeneau/graal-webrevs/webrev-infrastructure-merge/webrev/ >>>> >>>> This is the result of our merge with the recent providers infrastructure. Could you please look this over? >>>> >>>> Here is a brief summary: >>>> >>>> >>>> HSAILHotSpotForeignCallsProvider.java >>>> ------------------------------------- >>>> . As noted in the comments, we don't really support foreign calls yet, yet we do get asked to handle ForeignCall nodes, and we want to generate dummy code for them. We just support them all and lazily create dummy linkages here. When we finally support foreign calls we will explicitly register the ones we want to support. >>>> >>>> HSAILHotSpotLIRGenerator.java, HSAILLIRGenerator.java, HSAILControlFlow.java >>>> ---------------------------------------------------------------------------- >>>> . This again is part of the dummy Foreign Call support. Some less extensive ForeignCall support used to be in HSAILLIRGenerator. >>>> >>>> HSAILHotSpotReplacementsImpl.java >>>> --------------------------------- >>>> . This is another one of the providers in the new runtime infrastructure. For both macro substitutions and method substitutions, we just delegate to the host substitution list. This is a quick solution which allows things like Math.sqrt, and some of the Unsafe methods to work for HSAIL, similar to the way these substitutions worked before the providers change. Eventually, we will explicitly list which substitutions we will support. >>>> >>>> HSAIL.java >>>> ---------- >>>> . Not really part of the webrev infrastructure merge but since we're planning to limit the number of registers actually used by the graal compiler, it seemed appropriate to push this out. >>>> >>>> Tests >>>> ----- >>>> . With the ForeignCall support above, some test cases that were marked as failing are now passing. >>>> >>>> KernelTester.java >>>> ----------------- >>>> . Not really part of the webrev infrastructure merge but added a property to allow running the gpu code either first or second vs. the java code in our test cases. >>>> >>>> >>>> -- Tom Deneau >>>> >>>> >>> >>> >>> >> > > > From tom.deneau at amd.com Fri Nov 8 15:51:49 2013 From: tom.deneau at amd.com (Deneau, Tom) Date: Fri, 8 Nov 2013 23:51:49 +0000 Subject: Error compiling example code for HSAIL generation In-Reply-To: References: Message-ID: Monir -- I just did a download of jdk8-b112 and built a clone of graal and the test below worked for me. I built graal with "mx --vm server --vmbuild product build". Is that what you used? -- Tom -----Original Message----- From: graal-dev-bounces at openjdk.java.net [mailto:graal-dev-bounces at openjdk.java.net] On Behalf Of Mozumder, Monir Sent: Friday, November 08, 2013 4:17 PM To: graal-dev at openjdk.java.net Subject: Error compiling example code for HSAIL generation I am trying to compile an example code from this page: http://www.tuicool.com/articles/eEFRR3?jdfwkey=d741l1 ~/dev/sumatra/test$ cat IntSquaredTest.java package com.oracle.graal.compiler.hsail.test; import org.junit.Test; import java.util.logging.*; public class IntSquaredTest extends StaticMethodTwoIntArrays { public static void run(int[] out, int[] in, int gid) { out[gid] = in[gid] * in[gid]; } @Test public void test() { super.testGeneratedHsail(); } } I see errors when trying to do the compilation step: mx --vm server unittest hsail.test.IntSquaredTest. ~/dev/sumatra/test$ mx --vm server unittest hsail.test.IntSquaredTest # # A fatal error has been detected by the Java Runtime Environment: # # Internal Error (graalJavaAccess.cpp:42), pid=12108, tid=140148517222144 # fatal error: Invalid layout of registerRefMap at com.oracle.graal.api.code.DebugInfo # # JRE version: Java(TM) SE Runtime Environment (8.0-b112) (build 1.8.0-ea-b112) # Java VM: OpenJDK 64-Bit Server VM (25.0-b53-internal mixed mode linux-amd64 compressed oops) # Failed to write core dump. Core dumps have been disabled. To enable core dumping, try "ulimit -c unlimited" before starting Java again # # An error report file with more information is saved as: # /home/munir/dev/sumatra/test/hs_err_pid12108.log # # If you would like to submit a bug report, please visit: # http://bugreport.sun.com/bugreport/crash.jsp # The crash happened outside the Java Virtual Machine in native code. # See problematic frame for where to report the bug. # See below for my setup details. I am also providing some snippets from hs_err_pid12108.log . Any ideas? Bests, -Monir ~/dev/sumatra/test$ which javac /home/munir/dev/sumatra/simulator/build_linux/grail/profuct/bin/javac ~/dev/sumatra/test$ java -version java version "1.8.0-ea" Java(TM) SE Runtime Environment (build 1.8.0-ea-b112) Java HotSpot(TM) 64-Bit Server VM (build 25.0-b54, mixed mode) ============================== excerpts from hs_err_pid12108.log # # A fatal error has been detected by the Java Runtime Environment: # # Internal Error (graalJavaAccess.cpp:42), pid=12108, tid=140148517222144 # fatal error: Invalid layout of registerRefMap at com.oracle.graal.api.code.DebugInfo # # JRE version: Java(TM) SE Runtime Environment (8.0-b112) (build 1.8.0-ea-b112) # Java VM: OpenJDK 64-Bit Server VM (25.0-b53-internal mixed mode linux-amd64 compressed oops) # Failed to write core dump. Core dumps have been disabled. To enable core dumping, try "ulimit -c unlimited" before starting Java again # # If you would like to submit a bug report, please visit: # http://bugreport.sun.com/bugreport/crash.jsp # The crash happened outside the Java Virtual Machine in native code. # See problematic frame for where to report the bug. # --------------- T H R E A D --------------- Current thread (0x00007f76d800d800): JavaThread "main" [_thread_in_native, id=12109, stack(0x00007f76de85b000,0x00007f76de95c000)] Stack: [0x00007f76de85b000,0x00007f76de95c000], sp=0x00007f76de95a860, free space=1022k Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) V [libjvm.so+0x96f8b6] VMError::report_and_die()+0x166 V [libjvm.so+0x46c773] report_fatal(char const*, int, char const*)+0x53 V [libjvm.so+0x555439] compute_offset(int&, Klass*, char const*, char const*, bool)+0x2e9 V [libjvm.so+0x555f13] graal_compute_offsets()+0xa93 V [libjvm.so+0x5461b6] GraalCompiler::initialize()+0x436 V [libjvm.so+0x5f65ee] JNI_CreateJavaVM+0xde C [libjli.so+0x703e] JavaMain+0x9e --------------- P R O C E S S --------------- ~ ~ ~ From Monir.Mozumder at amd.com Fri Nov 8 15:58:03 2013 From: Monir.Mozumder at amd.com (Mozumder, Monir) Date: Fri, 8 Nov 2013 23:58:03 +0000 Subject: graal-dev Digest, Vol 21, Issue 15 In-Reply-To: References: Message-ID: Thanks Tom, I will give it a shot. I believe I did the " mx build" as per the graal wiki page. Bests, -Monir -----Original Message----- From: graal-dev-bounces at openjdk.java.net [mailto:graal-dev-bounces at openjdk.java.net] On Behalf Of graal-dev-request at openjdk.java.net Sent: Friday, November 08, 2013 3:52 PM To: graal-dev at openjdk.java.net Subject: graal-dev Digest, Vol 21, Issue 15 Send graal-dev mailing list submissions to graal-dev at openjdk.java.net To subscribe or unsubscribe via the World Wide Web, visit http://mail.openjdk.java.net/mailman/listinfo/graal-dev or, via email, send a message with subject or body 'help' to graal-dev-request at openjdk.java.net You can reach the person managing the list at graal-dev-owner at openjdk.java.net When replying, please edit your Subject line so it is more specific than "Re: Contents of graal-dev digest..." Today's Topics: 1. Error compiling example code for HSAIL generation (Mozumder, Monir) 2. RE: Error compiling example code for HSAIL generation (Mozumder, Monir) 3. scoped overriding of graal options (Deneau, Tom) 4. RE: Error compiling example code for HSAIL generation (Deneau, Tom) ---------------------------------------------------------------------- Message: 1 Date: Fri, 8 Nov 2013 22:17:00 +0000 From: "Mozumder, Monir" Subject: Error compiling example code for HSAIL generation To: "graal-dev at openjdk.java.net" Message-ID: Content-Type: text/plain; charset="us-ascii" I am trying to compile an example code from this page: http://www.tuicool.com/articles/eEFRR3?jdfwkey=d741l1 ~/dev/sumatra/test$ cat IntSquaredTest.java package com.oracle.graal.compiler.hsail.test; import org.junit.Test; import java.util.logging.*; public class IntSquaredTest extends StaticMethodTwoIntArrays { public static void run(int[] out, int[] in, int gid) { out[gid] = in[gid] * in[gid]; } @Test public void test() { super.testGeneratedHsail(); } } I see errors when trying to do the compilation step: mx --vm server unittest hsail.test.IntSquaredTest. ~/dev/sumatra/test$ mx --vm server unittest hsail.test.IntSquaredTest # # A fatal error has been detected by the Java Runtime Environment: # # Internal Error (graalJavaAccess.cpp:42), pid=12108, tid=140148517222144 # fatal error: Invalid layout of registerRefMap at com.oracle.graal.api.code.DebugInfo # # JRE version: Java(TM) SE Runtime Environment (8.0-b112) (build 1.8.0-ea-b112) # Java VM: OpenJDK 64-Bit Server VM (25.0-b53-internal mixed mode linux-amd64 compressed oops) # Failed to write core dump. Core dumps have been disabled. To enable core dumping, try "ulimit -c unlimited" before starting Java again # # An error report file with more information is saved as: # /home/munir/dev/sumatra/test/hs_err_pid12108.log # # If you would like to submit a bug report, please visit: # http://bugreport.sun.com/bugreport/crash.jsp # The crash happened outside the Java Virtual Machine in native code. # See problematic frame for where to report the bug. # See below for my setup details. I am also providing some snippets from hs_err_pid12108.log . Any ideas? Bests, -Monir ~/dev/sumatra/test$ which javac /home/munir/dev/sumatra/simulator/build_linux/grail/profuct/bin/javac ~/dev/sumatra/test$ java -version java version "1.8.0-ea" Java(TM) SE Runtime Environment (build 1.8.0-ea-b112) Java HotSpot(TM) 64-Bit Server VM (build 25.0-b54, mixed mode) ============================== excerpts from hs_err_pid12108.log # # A fatal error has been detected by the Java Runtime Environment: # # Internal Error (graalJavaAccess.cpp:42), pid=12108, tid=140148517222144 # fatal error: Invalid layout of registerRefMap at com.oracle.graal.api.code.DebugInfo # # JRE version: Java(TM) SE Runtime Environment (8.0-b112) (build 1.8.0-ea-b112) # Java VM: OpenJDK 64-Bit Server VM (25.0-b53-internal mixed mode linux-amd64 compressed oops) # Failed to write core dump. Core dumps have been disabled. To enable core dumping, try "ulimit -c unlimited" before starting Java again # # If you would like to submit a bug report, please visit: # http://bugreport.sun.com/bugreport/crash.jsp # The crash happened outside the Java Virtual Machine in native code. # See problematic frame for where to report the bug. # --------------- T H R E A D --------------- Current thread (0x00007f76d800d800): JavaThread "main" [_thread_in_native, id=12109, stack(0x00007f76de85b000,0x00007f76de95c000)] Stack: [0x00007f76de85b000,0x00007f76de95c000], sp=0x00007f76de95a860, free space=1022k Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) V [libjvm.so+0x96f8b6] VMError::report_and_die()+0x166 V [libjvm.so+0x46c773] report_fatal(char const*, int, char const*)+0x53 V [libjvm.so+0x555439] compute_offset(int&, Klass*, char const*, char const*, bool)+0x2e9 V [libjvm.so+0x555f13] graal_compute_offsets()+0xa93 V [libjvm.so+0x5461b6] GraalCompiler::initialize()+0x436 V [libjvm.so+0x5f65ee] JNI_CreateJavaVM+0xde C [libjli.so+0x703e] JavaMain+0x9e --------------- P R O C E S S --------------- ~ ~ ~ ------------------------------ Message: 2 Date: Fri, 8 Nov 2013 22:26:21 +0000 From: "Mozumder, Monir" Subject: RE: Error compiling example code for HSAIL generation To: "graal-dev at openjdk.java.net" Message-ID: Content-Type: text/plain; charset="us-ascii" More setup details: graal setup: done as per https://wiki.openjdk.java.net/display/Graal/Instructions (hg clone http://hg.openjdk.java.net/graal/graal) HSA simulator setup: https://wiki.openjdk.java.net/display/Sumatra/The+HSAIL+Simulator (installed all 3 components) Though the HAS simulator setup does not matter here, I am mentioning it for giving the environment. Upon setting up grail, I pointed JAVA_HOME to be from its product folder. All test cases from simulator and grail seem to work fine. Bests, -Monir ------------------------------ Message: 3 Date: Fri, 8 Nov 2013 22:44:12 +0000 From: "Deneau, Tom" Subject: scoped overriding of graal options To: Doug Simon Cc: "graal-dev at openjdk.java.net" Message-ID: Content-Type: text/plain; charset="us-ascii" Doug -- OK, this still looks very useful. One small complaint, I did a println of the overridden option while debugging, and it just showed the original value from the command line. Maybe toString could show both the original value and the overridden value (if different) -- Tom -----Original Message----- From: Doug Simon [mailto:doug.simon at oracle.com] Sent: Thursday, November 07, 2013 4:05 PM To: Deneau, Tom Cc: graal-dev at openjdk.java.net Subject: Re: webrev for hsail backend merging with new providers infrastructure On Nov 7, 2013, at 10:54 PM, Deneau, Tom wrote: > Doug -- > > Sometimes we want to run a test with several different max heap sizes because it forces different types of Compressed Oops encoding, etc. Can that type of change be handled by this scoped overriding of options? (I assume not). Unfortunately not. The scoped overriding mechanism is only supported for Graal options, not HotSpot options. -Doug > -----Original Message----- > From: Doug Simon [mailto:doug.simon at oracle.com] > Sent: Tuesday, November 05, 2013 8:06 AM > To: Deneau, Tom > Cc: graal-dev at openjdk.java.net > Subject: Re: webrev for hsail backend merging with new providers infrastructure > > > On Nov 4, 2013, at 6:19 PM, Doug Simon wrote: > >> >> On Nov 4, 2013, at 5:27 PM, Deneau, Tom wrote: >> >>> Hi Doug -- >>> >>> Some of our java 8 based unit tests (which use lambdas) use these two libraries currently, but you're right we don't use them in the java 7 based tests yet. If you want to remove them from the public mx/projects, go ahead. >>> >>> This points to a hole in our testing strategy which we've always been aware of. We have written a number of java 8 style unit tests that we test locally here but that don't get exercised in the public repository. We could of course add similar java 7 based unit tests and push them to public but we haven't done that work, and if graal is going to support 8 soon, there wouldn't be a need for that conversion work. >> >> Yes, I suggest to keep just running these tests locally until Graal has transitioned to 8. >> >>> On a related note, I think Vasanth mentioned that we run our unit tests locally here with the flags -G:+InlineEverything -G:-RemoveNeverExecutedCode. We need InlineEverything because we don't support HSAIL function calls yet. Several test cases have a line like >>> assumeTrue(aggressiveInliningEnabled()); >>> >>> and of course these just get skipped if -G:+InlineEverything is not set. Is it possible to get the hsail tests that get run at Oracle to use these two flags? >> >> We don't currently have infrastructure for running tests in a different VM instances based on required command line option settings. What we ideally want (in this case at least) is for options such as InlineEverything and RemoveNeverExecutedCode to be overridable in a scoped manner (e.g., for individual compilations). Until we have support for this however, we'll have to rely on your testing setup to run these tests. > > There is now support for scoped overriding of options[1]. For example, in StaticNBodyCallTest: > > @Test > @Override > public void test() throws Exception { > Field f = GraalOptions.class.getDeclaredField("RemoveNeverExecutedCode"); > f.setAccessible(true); > OptionValue removeNeverExecutedCode = (OptionValue) f.get(null); > try (OverrideScope s = OptionValue.override(GraalOptions.InlineEverything, true, removeNeverExecutedCode, false)) { > assumeTrue(aggressiveInliningEnabled() || canHandleHSAILMethodCalls()); > testGeneratedHsail(); > } > } > > > [1] http://hg.openjdk.java.net/graal/graal/rev/38bf986ce231 > > -Doug > >>> -----Original Message----- >>> From: Doug Simon [mailto:doug.simon at oracle.com] >>> Sent: Monday, November 04, 2013 9:30 AM >>> To: Deneau, Tom >>> Cc: graal-dev at openjdk.java.net >>> Subject: Re: webrev for hsail backend merging with new providers infrastructure >>> >>> Actually, one quick question: Do we really need the VECMATH and APACHELANG libraries declared in mx/projects[1]? None of the projects seem to use them. >>> >>> -Doug >>> >>> [1] http://cr.openjdk.java.net/~tdeneau/graal-webrevs/webrev-infrastructure-merge/webrev/mx/projects.udiff.html >>> >>> On Nov 1, 2013, at 11:54 PM, Deneau, Tom wrote: >>> >>>> All -- >>>> >>>> I have posted a small webrev to >>>> http://cr.openjdk.java.net/~tdeneau/graal-webrevs/webrev-infrastructure-merge/webrev/ >>>> >>>> This is the result of our merge with the recent providers infrastructure. Could you please look this over? >>>> >>>> Here is a brief summary: >>>> >>>> >>>> HSAILHotSpotForeignCallsProvider.java >>>> ------------------------------------- >>>> . As noted in the comments, we don't really support foreign calls yet, yet we do get asked to handle ForeignCall nodes, and we want to generate dummy code for them. We just support them all and lazily create dummy linkages here. When we finally support foreign calls we will explicitly register the ones we want to support. >>>> >>>> HSAILHotSpotLIRGenerator.java, HSAILLIRGenerator.java, HSAILControlFlow.java >>>> ---------------------------------------------------------------------------- >>>> . This again is part of the dummy Foreign Call support. Some less extensive ForeignCall support used to be in HSAILLIRGenerator. >>>> >>>> HSAILHotSpotReplacementsImpl.java >>>> --------------------------------- >>>> . This is another one of the providers in the new runtime infrastructure. For both macro substitutions and method substitutions, we just delegate to the host substitution list. This is a quick solution which allows things like Math.sqrt, and some of the Unsafe methods to work for HSAIL, similar to the way these substitutions worked before the providers change. Eventually, we will explicitly list which substitutions we will support. >>>> >>>> HSAIL.java >>>> ---------- >>>> . Not really part of the webrev infrastructure merge but since we're planning to limit the number of registers actually used by the graal compiler, it seemed appropriate to push this out. >>>> >>>> Tests >>>> ----- >>>> . With the ForeignCall support above, some test cases that were marked as failing are now passing. >>>> >>>> KernelTester.java >>>> ----------------- >>>> . Not really part of the webrev infrastructure merge but added a property to allow running the gpu code either first or second vs. the java code in our test cases. >>>> >>>> >>>> -- Tom Deneau >>>> >>>> >>> >>> >>> >> > > > ------------------------------ Message: 4 Date: Fri, 8 Nov 2013 23:51:49 +0000 From: "Deneau, Tom" Subject: RE: Error compiling example code for HSAIL generation To: "Mozumder, Monir" , "graal-dev at openjdk.java.net" Message-ID: Content-Type: text/plain; charset="us-ascii" Monir -- I just did a download of jdk8-b112 and built a clone of graal and the test below worked for me. I built graal with "mx --vm server --vmbuild product build". Is that what you used? -- Tom -----Original Message----- From: graal-dev-bounces at openjdk.java.net [mailto:graal-dev-bounces at openjdk.java.net] On Behalf Of Mozumder, Monir Sent: Friday, November 08, 2013 4:17 PM To: graal-dev at openjdk.java.net Subject: Error compiling example code for HSAIL generation I am trying to compile an example code from this page: http://www.tuicool.com/articles/eEFRR3?jdfwkey=d741l1 ~/dev/sumatra/test$ cat IntSquaredTest.java package com.oracle.graal.compiler.hsail.test; import org.junit.Test; import java.util.logging.*; public class IntSquaredTest extends StaticMethodTwoIntArrays { public static void run(int[] out, int[] in, int gid) { out[gid] = in[gid] * in[gid]; } @Test public void test() { super.testGeneratedHsail(); } } I see errors when trying to do the compilation step: mx --vm server unittest hsail.test.IntSquaredTest. ~/dev/sumatra/test$ mx --vm server unittest hsail.test.IntSquaredTest # # A fatal error has been detected by the Java Runtime Environment: # # Internal Error (graalJavaAccess.cpp:42), pid=12108, tid=140148517222144 # fatal error: Invalid layout of registerRefMap at com.oracle.graal.api.code.DebugInfo # # JRE version: Java(TM) SE Runtime Environment (8.0-b112) (build 1.8.0-ea-b112) # Java VM: OpenJDK 64-Bit Server VM (25.0-b53-internal mixed mode linux-amd64 compressed oops) # Failed to write core dump. Core dumps have been disabled. To enable core dumping, try "ulimit -c unlimited" before starting Java again # # An error report file with more information is saved as: # /home/munir/dev/sumatra/test/hs_err_pid12108.log # # If you would like to submit a bug report, please visit: # http://bugreport.sun.com/bugreport/crash.jsp # The crash happened outside the Java Virtual Machine in native code. # See problematic frame for where to report the bug. # See below for my setup details. I am also providing some snippets from hs_err_pid12108.log . Any ideas? Bests, -Monir ~/dev/sumatra/test$ which javac /home/munir/dev/sumatra/simulator/build_linux/grail/profuct/bin/javac ~/dev/sumatra/test$ java -version java version "1.8.0-ea" Java(TM) SE Runtime Environment (build 1.8.0-ea-b112) Java HotSpot(TM) 64-Bit Server VM (build 25.0-b54, mixed mode) ============================== excerpts from hs_err_pid12108.log # # A fatal error has been detected by the Java Runtime Environment: # # Internal Error (graalJavaAccess.cpp:42), pid=12108, tid=140148517222144 # fatal error: Invalid layout of registerRefMap at com.oracle.graal.api.code.DebugInfo # # JRE version: Java(TM) SE Runtime Environment (8.0-b112) (build 1.8.0-ea-b112) # Java VM: OpenJDK 64-Bit Server VM (25.0-b53-internal mixed mode linux-amd64 compressed oops) # Failed to write core dump. Core dumps have been disabled. To enable core dumping, try "ulimit -c unlimited" before starting Java again # # If you would like to submit a bug report, please visit: # http://bugreport.sun.com/bugreport/crash.jsp # The crash happened outside the Java Virtual Machine in native code. # See problematic frame for where to report the bug. # --------------- T H R E A D --------------- Current thread (0x00007f76d800d800): JavaThread "main" [_thread_in_native, id=12109, stack(0x00007f76de85b000,0x00007f76de95c000)] Stack: [0x00007f76de85b000,0x00007f76de95c000], sp=0x00007f76de95a860, free space=1022k Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) V [libjvm.so+0x96f8b6] VMError::report_and_die()+0x166 V [libjvm.so+0x46c773] report_fatal(char const*, int, char const*)+0x53 V [libjvm.so+0x555439] compute_offset(int&, Klass*, char const*, char const*, bool)+0x2e9 V [libjvm.so+0x555f13] graal_compute_offsets()+0xa93 V [libjvm.so+0x5461b6] GraalCompiler::initialize()+0x436 V [libjvm.so+0x5f65ee] JNI_CreateJavaVM+0xde C [libjli.so+0x703e] JavaMain+0x9e --------------- P R O C E S S --------------- ~ ~ ~ End of graal-dev Digest, Vol 21, Issue 15 ***************************************** From Monir.Mozumder at amd.com Fri Nov 8 16:01:07 2013 From: Monir.Mozumder at amd.com (Mozumder, Monir) Date: Sat, 9 Nov 2013 00:01:07 +0000 Subject: Error compiling example code for HSAIL generation In-Reply-To: References: Message-ID: Thanks Tom! I think I did the basic "mx build" command and did not choose proper options during the prompts due to my inexperience with the toolset. I will give a shot to your suggestion. Bests, -Monir -----Original Message----- From: Deneau, Tom Sent: Friday, November 08, 2013 3:52 PM To: Mozumder, Monir; graal-dev at openjdk.java.net Subject: RE: Error compiling example code for HSAIL generation Monir -- I just did a download of jdk8-b112 and built a clone of graal and the test below worked for me. I built graal with "mx --vm server --vmbuild product build". Is that what you used? -- Tom -----Original Message----- From: graal-dev-bounces at openjdk.java.net [mailto:graal-dev-bounces at openjdk.java.net] On Behalf Of Mozumder, Monir Sent: Friday, November 08, 2013 4:17 PM To: graal-dev at openjdk.java.net Subject: Error compiling example code for HSAIL generation I am trying to compile an example code from this page: http://www.tuicool.com/articles/eEFRR3?jdfwkey=d741l1 ~/dev/sumatra/test$ cat IntSquaredTest.java package com.oracle.graal.compiler.hsail.test; import org.junit.Test; import java.util.logging.*; public class IntSquaredTest extends StaticMethodTwoIntArrays { public static void run(int[] out, int[] in, int gid) { out[gid] = in[gid] * in[gid]; } @Test public void test() { super.testGeneratedHsail(); } } I see errors when trying to do the compilation step: mx --vm server unittest hsail.test.IntSquaredTest. ~/dev/sumatra/test$ mx --vm server unittest hsail.test.IntSquaredTest # # A fatal error has been detected by the Java Runtime Environment: # # Internal Error (graalJavaAccess.cpp:42), pid=12108, tid=140148517222144 # fatal error: Invalid layout of registerRefMap at com.oracle.graal.api.code.DebugInfo # # JRE version: Java(TM) SE Runtime Environment (8.0-b112) (build 1.8.0-ea-b112) # Java VM: OpenJDK 64-Bit Server VM (25.0-b53-internal mixed mode linux-amd64 compressed oops) # Failed to write core dump. Core dumps have been disabled. To enable core dumping, try "ulimit -c unlimited" before starting Java again # # An error report file with more information is saved as: # /home/munir/dev/sumatra/test/hs_err_pid12108.log # # If you would like to submit a bug report, please visit: # http://bugreport.sun.com/bugreport/crash.jsp # The crash happened outside the Java Virtual Machine in native code. # See problematic frame for where to report the bug. # See below for my setup details. I am also providing some snippets from hs_err_pid12108.log . Any ideas? Bests, -Monir ~/dev/sumatra/test$ which javac /home/munir/dev/sumatra/simulator/build_linux/grail/profuct/bin/javac ~/dev/sumatra/test$ java -version java version "1.8.0-ea" Java(TM) SE Runtime Environment (build 1.8.0-ea-b112) Java HotSpot(TM) 64-Bit Server VM (build 25.0-b54, mixed mode) ============================== excerpts from hs_err_pid12108.log # # A fatal error has been detected by the Java Runtime Environment: # # Internal Error (graalJavaAccess.cpp:42), pid=12108, tid=140148517222144 # fatal error: Invalid layout of registerRefMap at com.oracle.graal.api.code.DebugInfo # # JRE version: Java(TM) SE Runtime Environment (8.0-b112) (build 1.8.0-ea-b112) # Java VM: OpenJDK 64-Bit Server VM (25.0-b53-internal mixed mode linux-amd64 compressed oops) # Failed to write core dump. Core dumps have been disabled. To enable core dumping, try "ulimit -c unlimited" before starting Java again # # If you would like to submit a bug report, please visit: # http://bugreport.sun.com/bugreport/crash.jsp # The crash happened outside the Java Virtual Machine in native code. # See problematic frame for where to report the bug. # --------------- T H R E A D --------------- Current thread (0x00007f76d800d800): JavaThread "main" [_thread_in_native, id=12109, stack(0x00007f76de85b000,0x00007f76de95c000)] Stack: [0x00007f76de85b000,0x00007f76de95c000], sp=0x00007f76de95a860, free space=1022k Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) V [libjvm.so+0x96f8b6] VMError::report_and_die()+0x166 V [libjvm.so+0x46c773] report_fatal(char const*, int, char const*)+0x53 V [libjvm.so+0x555439] compute_offset(int&, Klass*, char const*, char const*, bool)+0x2e9 V [libjvm.so+0x555f13] graal_compute_offsets()+0xa93 V [libjvm.so+0x5461b6] GraalCompiler::initialize()+0x436 V [libjvm.so+0x5f65ee] JNI_CreateJavaVM+0xde C [libjli.so+0x703e] JavaMain+0x9e --------------- P R O C E S S --------------- ~ ~ ~ From doug.simon at oracle.com Sat Nov 9 03:06:01 2013 From: doug.simon at oracle.com (Doug Simon) Date: Sat, 9 Nov 2013 12:06:01 +0100 Subject: scoped overriding of graal options In-Reply-To: References: <0DB6F95F-9B2F-42BC-B29D-7CCA428C2CC0@oracle.com> <16BA4787-DA30-4D21-A7B7-B4149C498D40@oracle.com> Message-ID: <77719E59-A8D2-4179-8632-AB94F3A0E8DB@oracle.com> On Nov 8, 2013, at 11:44 PM, Deneau, Tom wrote: > Doug -- > > OK, this still looks very useful. > One small complaint, I did a println of the overridden option while debugging, and it just showed the original value from the command line. > > Maybe toString could show both the original value and the overridden value (if different) I modified toString() to show the current value and added a getValues() method to be able to access the overriding chain. -Doug > -----Original Message----- > From: Doug Simon [mailto:doug.simon at oracle.com] > Sent: Thursday, November 07, 2013 4:05 PM > To: Deneau, Tom > Cc: graal-dev at openjdk.java.net > Subject: Re: webrev for hsail backend merging with new providers infrastructure > > > On Nov 7, 2013, at 10:54 PM, Deneau, Tom wrote: > >> Doug -- >> >> Sometimes we want to run a test with several different max heap sizes because it forces different types of Compressed Oops encoding, etc. Can that type of change be handled by this scoped overriding of options? (I assume not). > > Unfortunately not. The scoped overriding mechanism is only supported for Graal options, not HotSpot options. > > -Doug > >> -----Original Message----- >> From: Doug Simon [mailto:doug.simon at oracle.com] >> Sent: Tuesday, November 05, 2013 8:06 AM >> To: Deneau, Tom >> Cc: graal-dev at openjdk.java.net >> Subject: Re: webrev for hsail backend merging with new providers infrastructure >> >> >> On Nov 4, 2013, at 6:19 PM, Doug Simon wrote: >> >>> >>> On Nov 4, 2013, at 5:27 PM, Deneau, Tom wrote: >>> >>>> Hi Doug -- >>>> >>>> Some of our java 8 based unit tests (which use lambdas) use these two libraries currently, but you're right we don't use them in the java 7 based tests yet. If you want to remove them from the public mx/projects, go ahead. >>>> >>>> This points to a hole in our testing strategy which we've always been aware of. We have written a number of java 8 style unit tests that we test locally here but that don't get exercised in the public repository. We could of course add similar java 7 based unit tests and push them to public but we haven't done that work, and if graal is going to support 8 soon, there wouldn't be a need for that conversion work. >>> >>> Yes, I suggest to keep just running these tests locally until Graal has transitioned to 8. >>> >>>> On a related note, I think Vasanth mentioned that we run our unit tests locally here with the flags -G:+InlineEverything -G:-RemoveNeverExecutedCode. We need InlineEverything because we don't support HSAIL function calls yet. Several test cases have a line like >>>> assumeTrue(aggressiveInliningEnabled()); >>>> >>>> and of course these just get skipped if -G:+InlineEverything is not set. Is it possible to get the hsail tests that get run at Oracle to use these two flags? >>> >>> We don't currently have infrastructure for running tests in a different VM instances based on required command line option settings. What we ideally want (in this case at least) is for options such as InlineEverything and RemoveNeverExecutedCode to be overridable in a scoped manner (e.g., for individual compilations). Until we have support for this however, we'll have to rely on your testing setup to run these tests. >> >> There is now support for scoped overriding of options[1]. For example, in StaticNBodyCallTest: >> >> @Test >> @Override >> public void test() throws Exception { >> Field f = GraalOptions.class.getDeclaredField("RemoveNeverExecutedCode"); >> f.setAccessible(true); >> OptionValue removeNeverExecutedCode = (OptionValue) f.get(null); >> try (OverrideScope s = OptionValue.override(GraalOptions.InlineEverything, true, removeNeverExecutedCode, false)) { >> assumeTrue(aggressiveInliningEnabled() || canHandleHSAILMethodCalls()); >> testGeneratedHsail(); >> } >> } >> >> >> [1] http://hg.openjdk.java.net/graal/graal/rev/38bf986ce231 >> >> -Doug >> >>>> -----Original Message----- >>>> From: Doug Simon [mailto:doug.simon at oracle.com] >>>> Sent: Monday, November 04, 2013 9:30 AM >>>> To: Deneau, Tom >>>> Cc: graal-dev at openjdk.java.net >>>> Subject: Re: webrev for hsail backend merging with new providers infrastructure >>>> >>>> Actually, one quick question: Do we really need the VECMATH and APACHELANG libraries declared in mx/projects[1]? None of the projects seem to use them. >>>> >>>> -Doug >>>> >>>> [1] http://cr.openjdk.java.net/~tdeneau/graal-webrevs/webrev-infrastructure-merge/webrev/mx/projects.udiff.html >>>> >>>> On Nov 1, 2013, at 11:54 PM, Deneau, Tom wrote: >>>> >>>>> All -- >>>>> >>>>> I have posted a small webrev to >>>>> http://cr.openjdk.java.net/~tdeneau/graal-webrevs/webrev-infrastructure-merge/webrev/ >>>>> >>>>> This is the result of our merge with the recent providers infrastructure. Could you please look this over? >>>>> >>>>> Here is a brief summary: >>>>> >>>>> >>>>> HSAILHotSpotForeignCallsProvider.java >>>>> ------------------------------------- >>>>> . As noted in the comments, we don't really support foreign calls yet, yet we do get asked to handle ForeignCall nodes, and we want to generate dummy code for them. We just support them all and lazily create dummy linkages here. When we finally support foreign calls we will explicitly register the ones we want to support. >>>>> >>>>> HSAILHotSpotLIRGenerator.java, HSAILLIRGenerator.java, HSAILControlFlow.java >>>>> ---------------------------------------------------------------------------- >>>>> . This again is part of the dummy Foreign Call support. Some less extensive ForeignCall support used to be in HSAILLIRGenerator. >>>>> >>>>> HSAILHotSpotReplacementsImpl.java >>>>> --------------------------------- >>>>> . This is another one of the providers in the new runtime infrastructure. For both macro substitutions and method substitutions, we just delegate to the host substitution list. This is a quick solution which allows things like Math.sqrt, and some of the Unsafe methods to work for HSAIL, similar to the way these substitutions worked before the providers change. Eventually, we will explicitly list which substitutions we will support. >>>>> >>>>> HSAIL.java >>>>> ---------- >>>>> . Not really part of the webrev infrastructure merge but since we're planning to limit the number of registers actually used by the graal compiler, it seemed appropriate to push this out. >>>>> >>>>> Tests >>>>> ----- >>>>> . With the ForeignCall support above, some test cases that were marked as failing are now passing. >>>>> >>>>> KernelTester.java >>>>> ----------------- >>>>> . Not really part of the webrev infrastructure merge but added a property to allow running the gpu code either first or second vs. the java code in our test cases. >>>>> >>>>> >>>>> -- Tom Deneau >>>>> >>>>> >>>> >>>> >>>> >>> >> >> >> > > > From doug.simon at oracle.com Sat Nov 9 18:00:10 2013 From: doug.simon at oracle.com (doug.simon at oracle.com) Date: Sun, 10 Nov 2013 02:00:10 +0000 Subject: hg: graal/graal: 47 new changesets Message-ID: <20131110020302.0EB53624C1@hg.openjdk.java.net> Changeset: 4aec62c32a82 Author: Roland Schatz Date: 2013-11-06 16:29 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/4aec62c32a82 Helper functions for identifying numeric kinds. ! graal/com.oracle.graal.api.meta/src/com/oracle/graal/api/meta/Constant.java ! graal/com.oracle.graal.api.meta/src/com/oracle/graal/api/meta/Kind.java ! graal/com.oracle.graal.compiler.amd64/src/com/oracle/graal/compiler/amd64/AMD64LIRGenerator.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.java/src/com/oracle/graal/java/GraphBuilderPhase.java ! graal/com.oracle.graal.lir/src/com/oracle/graal/lir/asm/TargetMethodAssembler.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/Condition.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/calc/FloatArithmeticNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/calc/IntegerAddNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/calc/IntegerArithmeticNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/calc/IntegerBelowThanNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/calc/IntegerEqualsNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/calc/IntegerLessThanNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/extended/ReadNode.java ! graal/com.oracle.graal.replacements/src/com/oracle/graal/replacements/nodes/ReverseBytesNode.java Changeset: 22780dc399da Author: Roland Schatz Date: 2013-11-06 16:56 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/22780dc399da Support arbitrary array types in global value numbering. ! graal/com.oracle.graal.graph/src/com/oracle/graal/graph/NodeClass.java Changeset: 8577cb721f51 Author: Doug Simon Date: 2013-11-06 18:43 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/8577cb721f51 use scoped option overriding for some HSAIL tests ! graal/com.oracle.graal.compiler.hsail.test.infra/src/com/oracle/graal/compiler/hsail/test/infra/GraalKernelTester.java ! graal/com.oracle.graal.compiler.hsail.test/src/com/oracle/graal/compiler/hsail/test/StaticNBodyCallTest.java ! graal/com.oracle.graal.compiler.hsail.test/src/com/oracle/graal/compiler/hsail/test/StaticNBodyTest.java ! graal/com.oracle.graal.compiler.hsail.test/src/com/oracle/graal/compiler/hsail/test/StringContainsAcceptTest.java Changeset: d59a65c11feb Author: Doug Simon Date: 2013-11-06 18:49 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/d59a65c11feb HSAIL support for difference between compression of oops and class pointers Contributed-by: Tom Deneau ! graal/com.oracle.graal.asm.hsail/src/com/oracle/graal/asm/hsail/HSAILAssembler.java + graal/com.oracle.graal.compiler.hsail.test/src/com/oracle/graal/compiler/hsail/test/InstanceOfTest.java ! graal/com.oracle.graal.hotspot.hsail/src/com/oracle/graal/hotspot/hsail/HSAILHotSpotLIRGenerator.java ! graal/com.oracle.graal.lir.hsail/src/com/oracle/graal/lir/hsail/HSAILMove.java Changeset: 38b84d5a66fd Author: Gilles Duboscq Date: 2013-11-06 14:53 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/38b84d5a66fd Start passing down a 'speculation id' to deoptimizations. Use it to record GuardNode id during guard lowering as a debug feature for now ! graal/com.oracle.graal.api.meta/src/com/oracle/graal/api/meta/MetaAccessProvider.java ! graal/com.oracle.graal.hotspot.amd64/src/com/oracle/graal/hotspot/amd64/AMD64HotSpotLIRGenerator.java ! graal/com.oracle.graal.hotspot.sparc/src/com/oracle/graal/hotspot/sparc/SPARCHotSpotLIRGenerator.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotMetaAccessProvider.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/DeoptimizeNode.java ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/GuardLoweringPhase.java ! src/share/vm/runtime/deoptimization.cpp ! src/share/vm/runtime/deoptimization.hpp Changeset: 4b053442b9d1 Author: Gilles Duboscq Date: 2013-11-06 16:41 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/4b053442b9d1 Do not compress graph when debug is enabled ! graal/com.oracle.graal.graph/src/com/oracle/graal/graph/Graph.java Changeset: 42a60780c2c9 Author: Gilles Duboscq Date: 2013-11-06 16:47 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/42a60780c2c9 Add some missing cases for NodeClass.(getDebugProperties|valueEqual|valueNumber) ! graal/com.oracle.graal.graph/src/com/oracle/graal/graph/NodeClass.java Changeset: 44c0e08c4150 Author: Gilles Duboscq Date: 2013-11-07 10:42 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/44c0e08c4150 Lowering should handle the case where the current guard anchor gets lowered and does not exist anymore ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/LoweringPhase.java Changeset: b6f66fb9f106 Author: Gilles Duboscq Date: 2013-11-07 10:45 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/b6f66fb9f106 SnippetTemplate instantiation should replace snippet's start node with a valid anchor point not the caller's start node ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/spi/LoweringTool.java ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/LoweringPhase.java ! graal/com.oracle.graal.replacements/src/com/oracle/graal/replacements/SnippetTemplate.java Changeset: 0e998f0daddf Author: Gilles Duboscq Date: 2013-11-07 11:17 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/0e998f0daddf Code cache: make sure we collect statistics even if the compiler is not recognized ! src/share/vm/code/nmethod.cpp Changeset: 001b8429afc3 Author: Doug Simon Date: 2013-11-07 18:33 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/001b8429afc3 added ResetDebugValuesAfterBootstrap to separate out metrics gathered during bootstrap ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/GraalDebugConfig.java ! graal/com.oracle.graal.debug/src/com/oracle/graal/debug/internal/DebugValueMap.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/bridge/VMToCompilerImpl.java Changeset: bb5fa27daa20 Author: Doug Simon Date: 2013-11-07 18:34 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/bb5fa27daa20 added ability to disable snippet graph preparation cache (-Dgraal.useSnippetGraphCache=false) ! graal/com.oracle.graal.replacements/src/com/oracle/graal/replacements/ReplacementsImpl.java Changeset: 3b2b8a71d10d Author: Doug Simon Date: 2013-11-07 18:36 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/3b2b8a71d10d added ability to disable snippet template cache (-Dgraal.useSnippetTemplateCache=false) added metrics for size (i.e., node count) of prepared snippets graphs and snippet templates ! graal/com.oracle.graal.replacements/src/com/oracle/graal/replacements/SnippetTemplate.java Changeset: 85bab2227295 Author: Christian Humer Date: 2013-11-07 15:10 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/85bab2227295 Truffle: refactored inlining to a new class. ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/CompilationPolicy.java ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/OptimizedCallTarget.java + graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/TruffleInlining.java + graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/TruffleInliningImpl.java Changeset: d2d0c44662bb Author: Christian Humer Date: 2013-11-07 16:21 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/d2d0c44662bb Truffle: refactored CompilationProfile to separate the profile and the policy in separate classes. + graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/CompilationPolicy.java ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/CompilationProfile.java < graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/CompilationPolicy.java + graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/DefaultCompilationPolicy.java ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/OptimizedCallTarget.java + graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/TimedCompilationPolicy.java ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/TruffleInliningImpl.java Changeset: 60142b15ed42 Author: Christian Humer Date: 2013-11-07 19:07 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/60142b15ed42 Truffle: fixed bug where invocation counter was decremented twice after inlining; cleanup of optimized call target and profile. ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/CompilationProfile.java ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/OptimizedCallTarget.java Changeset: fb4658e16b5d Author: Christian Humer Date: 2013-11-07 20:47 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/fb4658e16b5d Truffle: some regression fixes to previous cleanup ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/OptimizedCallTarget.java Changeset: 882a0aadfed6 Author: Christian Humer Date: 2013-11-07 20:55 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/882a0aadfed6 Merge. Changeset: 8716b7ceef94 Author: Doug Simon Date: 2013-11-08 10:55 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/8716b7ceef94 removed debug value header & footer from non-debug value printing executions ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/bridge/VMToCompilerImpl.java Changeset: 655c87d8d3c2 Author: Doug Simon Date: 2013-11-08 10:56 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/655c87d8d3c2 added SnippetPreparationTime metric ! graal/com.oracle.graal.replacements/src/com/oracle/graal/replacements/ReplacementsImpl.java Changeset: b9f19a33dbb2 Author: Doug Simon Date: 2013-11-08 10:56 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/b9f19a33dbb2 fixed npe in DebugValueMap.reset() ! graal/com.oracle.graal.debug/src/com/oracle/graal/debug/internal/DebugValueMap.java Changeset: c6b7f982e949 Author: Doug Simon Date: 2013-11-08 11:12 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/c6b7f982e949 added per SnippetTemplate instantiation timer and counter ! graal/com.oracle.graal.replacements/src/com/oracle/graal/replacements/SnippetTemplate.java Changeset: dd856c84a75c Author: Gilles Duboscq Date: 2013-11-08 11:00 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/dd856c84a75c Mask the speculation id correctly in HotSpotMetaAccessProvider.encodeDeoptActionAndReason ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotMetaAccessProvider.java Changeset: 605c69ce3b35 Author: Gilles Duboscq Date: 2013-11-08 12:04 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/605c69ce3b35 Use option to enable guard-id-as-speculation-id rather than Debug.isEnabled() ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/GuardLoweringPhase.java Changeset: 895f31682b88 Author: Gilles Duboscq Date: 2013-11-08 12:10 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/895f31682b88 Make the speculation id an int and allow for more bits to be set in the HotSpot implementation (which currently silently discards unsupported high bit). ! graal/com.oracle.graal.api.meta/src/com/oracle/graal/api/meta/MetaAccessProvider.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotMetaAccessProvider.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/DeoptimizeNode.java ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/GuardLoweringPhase.java Changeset: 8898d449f95d Author: Roland Schatz Date: 2013-11-08 13:20 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/8898d449f95d Fix wrong conversion in extremum and exit values of induction variables. ! graal/com.oracle.graal.loop/src/com/oracle/graal/loop/BasicInductionVariable.java Changeset: dac9c1783aed Author: Roland Schatz Date: 2013-11-08 13:20 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/dac9c1783aed Use correct type for LocationIdentity in MemoryPhi. ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/PhiNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/ProxyNode.java ! graal/com.oracle.graal.phases/src/com/oracle/graal/phases/schedule/SchedulePhase.java Changeset: b87c2f34e0e0 Author: Roland Schatz Date: 2013-11-08 13:22 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/b87c2f34e0e0 Maintain lastLocationAccess in WriteNode. ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/extended/FloatingAccessNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/extended/FloatingReadNode.java + graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/extended/MemoryAccess.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/extended/WriteNode.java ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/FloatingReadPhase.java ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/ReadEliminationPhase.java ! graal/com.oracle.graal.phases/src/com/oracle/graal/phases/schedule/SchedulePhase.java ! graal/com.oracle.graal.replacements/src/com/oracle/graal/replacements/SnippetTemplate.java Changeset: bbf6407458ee Author: Bernhard Urban Date: 2013-11-08 13:45 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/bbf6407458ee Node: print node in assert ! graal/com.oracle.graal.graph/src/com/oracle/graal/graph/Node.java Changeset: b1e7e4ffead1 Author: Bernhard Urban Date: 2013-11-08 13:52 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/b1e7e4ffead1 UnsafeAccessNode: add assert to ensure a proper graph state ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/extended/UnsafeAccessNode.java Changeset: 7b457ecd18c3 Author: Bernhard Urban Date: 2013-11-08 13:52 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/7b457ecd18c3 AMD64Assembler: remove useless option "Atomic" and make other options final as reference: bacdc1d5c21c removal of Atomic option in the hotspot assembler ! graal/com.oracle.graal.asm.amd64/src/com/oracle/graal/asm/amd64/AMD64AsmOptions.java ! graal/com.oracle.graal.asm.amd64/src/com/oracle/graal/asm/amd64/AMD64Assembler.java Changeset: a95336e46474 Author: Doug Simon Date: 2013-11-08 16:12 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/a95336e46474 made LinearScan.checkIntervals non-static ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/alloc/LinearScan.java Changeset: c46e091cba57 Author: Doug Simon Date: 2013-11-08 16:13 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/c46e091cba57 intercept and report an error during debug value reporting but don't propagate it ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/bridge/VMToCompilerImpl.java Changeset: 3e88ee655612 Author: Doug Simon Date: 2013-11-08 16:14 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/3e88ee655612 per SnippetTemplate metrics now include the details of the specialization in their name ! graal/com.oracle.graal.replacements/src/com/oracle/graal/replacements/SnippetTemplate.java Changeset: 64d960e854e6 Author: Roland Schatz Date: 2013-11-08 16:59 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/64d960e854e6 Canonicalize comparison of type conversion with constants. ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/calc/CompareNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/calc/ConvertNode.java Changeset: 0646713243fb Author: Roland Schatz Date: 2013-11-08 17:07 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/0646713243fb Canonicalize convert of convert. ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/calc/ConvertNode.java Changeset: 8e862906e2e4 Author: Doug Simon Date: 2013-11-08 18:07 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/8e862906e2e4 removed hash code from name of SnippetTemplate metrics (blows up DebugValueMaps when template caching is disabled) ! graal/com.oracle.graal.replacements/src/com/oracle/graal/replacements/SnippetTemplate.java Changeset: 8212479436e0 Author: Doug Simon Date: 2013-11-08 18:26 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/8212479436e0 disabled type context specialization of allocation snippets unless allocation profiling is enabled ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/NewObjectSnippets.java Changeset: 8d8d9d0b04bb Author: Doug Simon Date: 2013-11-08 18:34 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/8d8d9d0b04bb added check (with warning on System.err) if number of templates for a snippet exceeds a threshold (default is 50) ! graal/com.oracle.graal.replacements/src/com/oracle/graal/replacements/SnippetTemplate.java Changeset: 2caa21ef52bb Author: Doug Simon Date: 2013-11-08 18:34 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/2caa21ef52bb Merge. Changeset: bb85b81258a0 Author: Doug Simon Date: 2013-11-09 12:04 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/bb85b81258a0 modified OptionValue.toString() to use the current, possibly overriding value; added OptionValue.getValues() ! graal/com.oracle.graal.options.test/src/com/oracle/graal/options/test/TestOptionValue.java ! graal/com.oracle.graal.options/src/com/oracle/graal/options/OptionValue.java Changeset: 49fe5a06ac6f Author: Christos Kotselidis Date: 2013-11-09 21:28 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/49fe5a06ac6f Add canonicalization phase before NodeIntrinsification ! graal/com.oracle.graal.replacements/src/com/oracle/graal/replacements/SnippetTemplate.java Changeset: 1619e69e4ea3 Author: Christos Kotselidis Date: 2013-11-09 21:29 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/1619e69e4ea3 Pass Long object to array copy snippets to canonicalize properly when BoxingSubstitutions are disabled ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/UnsafeArrayCopySnippets.java Changeset: 9a56121f285b Author: Christos Kotselidis Date: 2013-11-09 21:30 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/9a56121f285b Add missing cases for CheckCast usages in NodeIntrisification when BoxingSubstitutions are disabled ! graal/com.oracle.graal.replacements/src/com/oracle/graal/replacements/NodeIntrinsificationPhase.java Changeset: b699233403ad Author: Christos Kotselidis Date: 2013-11-09 21:32 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/b699233403ad Delegate hprof enabled information from hotspot to graal ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/HotSpotVMConfig.java ! src/share/vm/graal/graalGlobals.hpp ! src/share/vm/runtime/arguments.cpp Changeset: ad2434911b69 Author: Christos Kotselidis Date: 2013-11-09 21:33 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/ad2434911b69 Disable Boxing substitutions when hprof is enabled ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/HotSpotReplacementsImpl.java Changeset: a5b5e1ebab81 Author: Christos Kotselidis Date: 2013-11-09 21:34 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/a5b5e1ebab81 Merge ! graal/com.oracle.graal.replacements/src/com/oracle/graal/replacements/SnippetTemplate.java From doug.simon at oracle.com Sun Nov 10 02:27:18 2013 From: doug.simon at oracle.com (Doug Simon) Date: Sun, 10 Nov 2013 11:27:18 +0100 Subject: webrev for hsail support for CompareAndSwap and Membar In-Reply-To: References: Message-ID: <2D4BFAA4-A341-4ED3-AB6C-25AA0BB3B302@oracle.com> I?ll integrate these changes. On Nov 7, 2013, at 9:33 PM, Deneau, Tom wrote: > I have posted a webrev enabling HSAIL backend support for CompareAndSwapNode to http://cr.openjdk.java.net/~tdeneau/graal-webrevs/webrev-compareandswap/webrev/ > > This webrev also adds support for a volatile load and store with emitMembar. > > I added the CompareAndSwap support to HSAILHotSpotLIRGenerator (instead of HSAILLIRGenerator) because of the hotspot-specific special handling when the CAS location is a compressed oop. (This was definitely the more complicated case to implement). > > Three test cases were also added, using each of AtomicInteger, AtomicLong and AtomicReference. > > Could you please look this over? > > -- Tom > > > From doug.simon at oracle.com Sun Nov 10 06:40:07 2013 From: doug.simon at oracle.com (doug.simon at oracle.com) Date: Sun, 10 Nov 2013 14:40:07 +0000 Subject: hg: graal/graal: 3 new changesets Message-ID: <20131110144019.C4488624D4@hg.openjdk.java.net> Changeset: 40924dbc623b Author: Doug Simon Date: 2013-11-10 11:42 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/40924dbc623b HSAIL support for compare-and-swap and volatile load/store operations Contributed-by: Tom Deneau ! graal/com.oracle.graal.asm.hsail/src/com/oracle/graal/asm/hsail/HSAILAssembler.java + graal/com.oracle.graal.compiler.hsail.test/src/com/oracle/graal/compiler/hsail/test/AtomicIntGetAndAddTest.java + graal/com.oracle.graal.compiler.hsail.test/src/com/oracle/graal/compiler/hsail/test/AtomicLongGetAndAddTest.java + graal/com.oracle.graal.compiler.hsail.test/src/com/oracle/graal/compiler/hsail/test/AtomicReferenceGetAndSetTest.java ! graal/com.oracle.graal.compiler.hsail/src/com/oracle/graal/compiler/hsail/HSAILLIRGenerator.java ! graal/com.oracle.graal.hotspot.hsail/src/com/oracle/graal/hotspot/hsail/HSAILHotSpotLIRGenerator.java ! graal/com.oracle.graal.lir.hsail/src/com/oracle/graal/lir/hsail/HSAILMove.java Changeset: f1a55428a8d7 Author: Doug Simon Date: 2013-11-10 13:18 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/f1a55428a8d7 more HSAIL support in the C++ layer for executing HSAIL code on the simulator Contributed-by: Eric Caspole ! graal/com.oracle.graal.compiler.hsail.test.infra/src/com/oracle/graal/compiler/hsail/test/infra/GraalKernelTester.java ! graal/com.oracle.graal.compiler.hsail.test.infra/src/com/oracle/graal/compiler/hsail/test/infra/KernelTester.java ! graal/com.oracle.graal.hotspot.hsail/src/com/oracle/graal/hotspot/hsail/ForEachToGraal.java ! graal/com.oracle.graal.hotspot.hsail/src/com/oracle/graal/hotspot/hsail/HSAILCompilationResult.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotNmethod.java ! hotspot/.project ! make/linux/makefiles/buildtree.make ! make/linux/makefiles/vm.make ! make/windows/makefiles/projectcreator.make ! make/windows/makefiles/vm.make + src/gpu/hsail/vm/gpu_hsail.cpp + src/gpu/hsail/vm/gpu_hsail.hpp + src/gpu/hsail/vm/hsailKernelArguments.cpp + src/gpu/hsail/vm/hsailKernelArguments.hpp ! src/os_gpu/linux_ptx/vm/gpu_linux.cpp + src/os_gpu/windows_hsail/vm/gpu_windows.cpp + src/os_gpu/windows_hsail/vm/gpu_windows.hpp ! src/share/vm/graal/graalCompilerToGPU.cpp ! src/share/vm/graal/graalEnv.cpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/gpu.cpp ! src/share/vm/runtime/gpu.hpp Changeset: 41f0bd213b51 Author: Doug Simon Date: 2013-11-10 14:37 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/41f0bd213b51 make 'mx unittest' still pass even if HSAIL device is not available ! graal/com.oracle.graal.compiler.hsail.test.infra/src/com/oracle/graal/compiler/hsail/test/infra/GraalKernelTester.java From doug.simon at oracle.com Sun Nov 10 06:43:15 2013 From: doug.simon at oracle.com (Doug Simon) Date: Sun, 10 Nov 2013 15:43:15 +0100 Subject: webrev for running HSAIL same way as PTX from Hotspot In-Reply-To: References: Message-ID: <445CDAD6-6377-4720-84D4-885C027859FC@oracle.com> I have integrated this patch [1][2]. On Nov 6, 2013, at 11:11 PM, Caspole, Eric wrote: > Hi everyone, > I put a new graal hotspot webrev at > > http://cr.openjdk.java.net/~ecaspole/jvm_kernel_launch.01/webrev/ > > Here I made changes to support running HSAIL kernels using the same code path as PTX in Hotspot. I tried to have the same code structure as PTX except that HSAIL arguments are processed differently because HSA has direct access to the java heap. > > I did not do anything with the gpu detection code. I added a -XX:+UseHSAILSimulator option for the time being to use this path rather than the PTX path. These changes will work with the HSA simulator Okra library at > > https://github.com/HSAFoundation/Okra-Interface-to-HSAIL-Simulator > > We are adding new support in that library to work with these hotspot changes. Then you can build the Okra library, put it in the LD_LIBRARY_PATH for the Graal JVM and run HSAIL kernels. > > I think there is a little work to do to more smoothly support the two different offload platforms I agree. For example in both executeExternalMethodVarargs and executeParallelMethodVarargs, there should be a test on the incoming HotSpotInstalledCode argument to determine which GPU it is for. One solution might be to repurpose the HotSpotInstalledCode.external field to be an ISA identifier (0 meaning host ISA). -Doug [1] http://hg.openjdk.java.net/graal/graal/rev/f1a55428a8d7 [2] http://hg.openjdk.java.net/graal/graal/rev/41f0bd213b51 From doug.simon at oracle.com Mon Nov 11 13:37:18 2013 From: doug.simon at oracle.com (doug.simon at oracle.com) Date: Mon, 11 Nov 2013 21:37:18 +0000 Subject: hg: graal/graal: 10 new changesets Message-ID: <20131111213805.F30DA6250C@hg.openjdk.java.net> Changeset: 31ed7cd96914 Author: Doug Simon Date: 2013-11-10 17:55 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/31ed7cd96914 made SnippetGraphNodeCount count the right thing; re-enable prepared snippet graph caching by default ! 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: a7eee87c7897 Author: Doug Simon Date: 2013-11-10 21:31 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/a7eee87c7897 remove use of snippets for lowering nop write barriers ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/WriteBarrierSnippets.java Changeset: b5cf28c97430 Author: Doug Simon Date: 2013-11-10 21:34 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/b5cf28c97430 replaced global snippet and template node metrics with per-snippet and per-template metrics ! 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: e4f0cba4e843 Author: Mick Jordan Date: 2013-11-10 20:54 -0800 URL: http://hg.openjdk.java.net/graal/graal/rev/e4f0cba4e843 mx_graal.py symlink for commands.py for static import + mx/mx_graal.py Changeset: d36c39829943 Author: Roland Schatz Date: 2013-11-11 17:49 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/d36c39829943 Test case for loop unrolling. + graal/com.oracle.graal.jtt/src/com/oracle/graal/jtt/loop/LoopUnroll.java Changeset: c61d1f1bbee0 Author: Roland Schatz Date: 2013-11-11 17:54 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/c61d1f1bbee0 Invalidate cached nodes after canonicalization in full unrolling. ! graal/com.oracle.graal.loop/src/com/oracle/graal/loop/LoopEx.java ! graal/com.oracle.graal.loop/src/com/oracle/graal/loop/LoopFragment.java ! graal/com.oracle.graal.loop/src/com/oracle/graal/loop/LoopTransformations.java Changeset: d61e3ca7c89b Author: Roland Schatz Date: 2013-11-11 17:56 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/d61e3ca7c89b Canonicalize coversions that don't change the type. ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/calc/ConvertNode.java Changeset: 71991b7a0f14 Author: Christian Humer Date: 2013-11-11 21:34 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/71991b7a0f14 SL: Enhanced SimpleLanguage with support for if statements, function calls, function caching + inlining and builtins. + graal/com.oracle.truffle.api.dsl.test/src/com/oracle/truffle/api/dsl/test/NodeChildTest.java ! graal/com.oracle.truffle.sl.test/src/com/oracle/truffle/sl/test/AddTest.java + graal/com.oracle.truffle.sl.test/src/com/oracle/truffle/sl/test/BuiltinsTest.java + graal/com.oracle.truffle.sl.test/src/com/oracle/truffle/sl/test/CallTest.java ! graal/com.oracle.truffle.sl.test/src/com/oracle/truffle/sl/test/ComparisonTest.java ! graal/com.oracle.truffle.sl.test/src/com/oracle/truffle/sl/test/DivTest.java + graal/com.oracle.truffle.sl.test/src/com/oracle/truffle/sl/test/FibonacciTest.java ! graal/com.oracle.truffle.sl.test/src/com/oracle/truffle/sl/test/LoopPrintTest.java ! graal/com.oracle.truffle.sl.test/src/com/oracle/truffle/sl/test/MulTest.java ! graal/com.oracle.truffle.sl.test/src/com/oracle/truffle/sl/test/SubTest.java ! graal/com.oracle.truffle.sl.test/src/com/oracle/truffle/sl/test/TernaryTest.java - graal/com.oracle.truffle.sl/src/com/oracle/truffle/sl/NodeFactory.java - graal/com.oracle.truffle.sl/src/com/oracle/truffle/sl/SLArguments.java ! graal/com.oracle.truffle.sl/src/com/oracle/truffle/sl/SLNode.java + graal/com.oracle.truffle.sl/src/com/oracle/truffle/sl/SLNodeFactory.java + graal/com.oracle.truffle.sl/src/com/oracle/truffle/sl/SLScript.java ! graal/com.oracle.truffle.sl/src/com/oracle/truffle/sl/SLTypes.java ! graal/com.oracle.truffle.sl/src/com/oracle/truffle/sl/SimpleLanguage.java + graal/com.oracle.truffle.sl/src/com/oracle/truffle/sl/builtins/BuiltinNode.java + graal/com.oracle.truffle.sl/src/com/oracle/truffle/sl/builtins/DefaultBuiltins.java + graal/com.oracle.truffle.sl/src/com/oracle/truffle/sl/builtins/PrintBuiltin.java + graal/com.oracle.truffle.sl/src/com/oracle/truffle/sl/builtins/TimeBuiltin.java + graal/com.oracle.truffle.sl/src/com/oracle/truffle/sl/nodes/ArgumentsNode.java + graal/com.oracle.truffle.sl/src/com/oracle/truffle/sl/nodes/CallNode.java + graal/com.oracle.truffle.sl/src/com/oracle/truffle/sl/nodes/FunctionBodyNode.java - graal/com.oracle.truffle.sl/src/com/oracle/truffle/sl/nodes/FunctionDefinitionNode.java + graal/com.oracle.truffle.sl/src/com/oracle/truffle/sl/nodes/FunctionRootNode.java ! graal/com.oracle.truffle.sl/src/com/oracle/truffle/sl/nodes/IfNode.java + graal/com.oracle.truffle.sl/src/com/oracle/truffle/sl/nodes/NullLiteralNode.java - graal/com.oracle.truffle.sl/src/com/oracle/truffle/sl/nodes/PrintLineNode.java - graal/com.oracle.truffle.sl/src/com/oracle/truffle/sl/nodes/PrintNode.java + graal/com.oracle.truffle.sl/src/com/oracle/truffle/sl/nodes/ReadArgumentNode.java + graal/com.oracle.truffle.sl/src/com/oracle/truffle/sl/nodes/ReadFunctionNode.java ! graal/com.oracle.truffle.sl/src/com/oracle/truffle/sl/nodes/ReadLocalNode.java + graal/com.oracle.truffle.sl/src/com/oracle/truffle/sl/nodes/ReadUninitializedNode.java - graal/com.oracle.truffle.sl/src/com/oracle/truffle/sl/nodes/TimeNode.java ! graal/com.oracle.truffle.sl/src/com/oracle/truffle/sl/nodes/TypedNode.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/Parser.java.old + graal/com.oracle.truffle.sl/src/com/oracle/truffle/sl/parser/ParserUtils.java ! graal/com.oracle.truffle.sl/src/com/oracle/truffle/sl/parser/Scanner.frame ! graal/com.oracle.truffle.sl/src/com/oracle/truffle/sl/parser/Scanner.java + graal/com.oracle.truffle.sl/src/com/oracle/truffle/sl/parser/Scanner.java.old ! graal/com.oracle.truffle.sl/src/com/oracle/truffle/sl/parser/SimpleLanguage.atg + graal/com.oracle.truffle.sl/src/com/oracle/truffle/sl/runtime/SLArguments.java + graal/com.oracle.truffle.sl/src/com/oracle/truffle/sl/runtime/SLContext.java + graal/com.oracle.truffle.sl/src/com/oracle/truffle/sl/runtime/SLFunctionRegistry.java + graal/com.oracle.truffle.sl/src/com/oracle/truffle/sl/runtime/SLNull.java Changeset: 53f8adcbc474 Author: Christian Humer Date: 2013-11-11 21:40 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/53f8adcbc474 Merge. Changeset: 7311354f5bf8 Author: Christian Humer Date: 2013-11-11 21:43 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/7311354f5bf8 SL: fixed eclipse formatter problems. ! graal/com.oracle.truffle.sl/src/com/oracle/truffle/sl/parser/Parser.java ! graal/com.oracle.truffle.sl/src/com/oracle/truffle/sl/parser/Scanner.java From tom.deneau at amd.com Mon Nov 11 14:08:16 2013 From: tom.deneau at amd.com (Deneau, Tom) Date: Mon, 11 Nov 2013 22:08:16 +0000 Subject: scoped options usage in hsail Message-ID: I have posted a small webrev for how we use the scoped options feature in hsail http://cr.openjdk.java.net/~tdeneau/graal-webrevs/webrev-scoped-options/webrev/ The previous way of using scoped options only forced new options on a few tests. While this was enough to make the existing java 7 junit tests pass, in reality we want to force the options on all tests (this is how we were running things here). So I pushed the scoped options overrides down into GraalKernelTester.java which all tests go thru. The assumeTrue(aggressiveInliingEnabled) assertions then had to move one layer down, to the runTest routine. -- Tom From doug.simon at oracle.com Mon Nov 11 14:44:23 2013 From: doug.simon at oracle.com (Doug Simon) Date: Mon, 11 Nov 2013 23:44:23 +0100 Subject: scoped options usage in hsail In-Reply-To: References: Message-ID: I?ve integrated this patch. On Nov 11, 2013, at 11:08 PM, Deneau, Tom wrote: > I have posted a small webrev for how we use the scoped options feature in hsail > > > > http://cr.openjdk.java.net/~tdeneau/graal-webrevs/webrev-scoped-options/webrev/ > > > > The previous way of using scoped options only forced new options on a few tests. While this was enough to make the existing java 7 junit tests pass, in reality we want to force the options on all tests (this is how we were running things here). > > > > So I pushed the scoped options overrides down into GraalKernelTester.java which all tests go thru. > > > > The assumeTrue(aggressiveInliingEnabled) assertions then had to move one layer down, to the runTest routine. > > > > -- Tom > > > From christian.humer at gmail.com Mon Nov 11 15:04:14 2013 From: christian.humer at gmail.com (Christian Humer) Date: Tue, 12 Nov 2013 00:04:14 +0100 Subject: Truffle DSL feature suggestions In-Reply-To: References: <60F35720-B657-476D-96E5-AA870765DF72@vub.ac.be> Message-ID: Stefan, I've updated the SimpleLanguage [1]. It now contains a basic inline cache similar to the one described in my previous mail. [1] http://hg.openjdk.java.net/graal/graal/rev/71991b7a0f14 - Christian Humer On Fri, Nov 8, 2013 at 5:48 PM, Christian Humer wrote: > Hi Stefan, > > Seems that your making good progress! > > Support for inheriting @NodeChild >> ????????????????????????????????- >> The next thing I noticed is that @NodeChild annotation are not inherited >> when the subclass defines additional @NodeChilds. While it is not a big >> issue, it feel counter intuitive when I noticed it for the first time. My >> expectation was that these annotations have an additive semantics. >> As an example, I have a AbstractMonomorphicMessageNode [3] with the >> @NodeChild(value = ?receiver?, ExpN.class) annotation, and in the subclass >> BinaryMonomorphicNode [4] I need to specify the receiver again, because I >> want to add an argument NodeChild. > > > @NodeChild elements should be inherited already. Unfortunately there is a > bug when inheriting more than one @NodeChild defined int he base class and > there is another @NodeChild annotation defined in the inheriting class, the > second @NodeChild of the base class is not inherited. Seems that nobody > used this annotation in this way so far ;-). Will fix this and keep you > posted. > > However, what already works is using a variable number of arguments > @NodeChild in the base class like this: > > @NodeChildren({@NodeChild(value = "receiver", type = ValueNode.class), > @NodeChild(value = "arguments", type = ValueNode[].class)}) > abstract static class BaseNode extends ValueNode { > public abstract ValueNode getReceiver(); > public abstract ValueNode[] getArguments(); > } > > abstract static class UnaryNode extends BaseNode { > @Specialization > public int doIt(Object receiver, int value0) { > return value; > } > } > > abstract static class BinaryNode extends BaseNode { > @Specialization > public int doIt(Object receiver, int value0, int value1) { > return value0 + value1; > } > } > > abstract static class TernaryNode extends BaseNode { > @Specialization > public int doIt(Object receiver, int value0, int value1, int > value2) { > return value0 + value1 + value2; > } > } > > Also take a look at the generated code. There you can see that instead of > accessing a field per child the generated source now accesses the children > in an array using fixed indexes. So for the third value it accesses > arguments[1].execute() to execute the value. Please note that all > specializations in one operation must have the same number of arguments. > Using the NodeFactory#getExecutionSignature() method you can find out the > actual number of arguments that were used dynamically. So you would be able > to write one generic rewrite mechanism. > > > Allowing @Generic for Simple Nodes > > ?????????????????????????????????- >> In my new node hierarchy, I use UnaryMessageNode (..Binary/Ternary/KeywordMsgNode) >> [2] to represent the initial state of message send as generated by the >> parser. So, the main idea is to avoid specialization before execution >> starts. The parser could do some simple specializations already purely >> based on the static name of a message. However, I decided against doing >> that, following what I understand to be one of the main suggestions for >> Truffle. >> As a result I have the UnaryMessageNode (Binary/Ternary/Keyword) class >> just implementing a doGeneric(.) method, which replace the node by a >> UnaryMonomorphicNode. For the doGeneric(.) method, I feel that @Generic >> would be the better annotation, and putting @Specialization there, because >> it otherwise wouldn?t have a specialization, feels a little unnatural. The >> @Generic annotation also has another benefit, because it enforces certain >> constraints on the method signature, which is useful to make the type >> system happy. > > > I see your point. Just @Generic should be possible. I've put it on my list. > > I do not recommend doing manual replaces inside of @Specialization or > @Generic annotated methods at all. Think of the use-case of polymorphic > chains where a call to replace would just replace one entry of the > polymorphic chain. This would lead to a wrong tree. If you want do do that > please turn off the polymorphic chaining by using @PolymorphicDepth(0). But > I don't think you will need that if you do it the way I describe it below. > > Polymorphic Inline Caching >> ?????????????????????????- > > First thanks for your input on the new DSL feature. I hope we will be > able to implement it soon. > > Let me explain to you how polymorphic inline caches are currently > implemented in most of the truffle languages by referencing what i think > you want to achieve. > > final class Message { > String name; > ... > CallTarget target; > ... > } > > Each available message is represented as such an instance. A CallTarget > for the message can be created by a call to > Truffle.getRuntime().createCallTarget(...). These Message instances are > usually stored in a global map or a similar concept. > > For a call you start off with one uninitialized call/message node which > has a child for receiving the function and one for the receiver. > > class UninitializedSendNode { > message = ... // returns a Message (may do a lookup in a local variable > or global map) > receiver = ... // returns the receiver object > uninitializedArguments[] = ... // the uninitialized arguments of the > call as they are parsed > } > > When the first call to the execute method in UninitializedMessageNode > occurs the uninitialized node creates a cache like this: > > class CachedSendNode { > final CallTarget cachedTarget; // the call target this node is specialized > on > receiver, message; > uninitializedArguments[]; > current = DispatchedSendNode // Implementation of the call (may get > inlined later or immediatly) > arguments // copied from uninitializedArguments > next = UninitializedMessageNode or again CachedSendNode > // how an implementation for that node could look like: > Object execute(VirtualFrame frame) { > Object receiver = receiver.execute(frame); // we need to ensure that > the receiver is just evaluated once per call > Message m = message.execute(frame); > if (this.cachedTarget == m.getCallTargetTarget()) { > return current.execute(frame, receiver); > } > return next.execute(frame, receiver); > } > } > > This CachedSendNode can be chained as a cache using the next field. After > reaching some depth the chain should rewrite itself to a > GenericSendNode which then does not store the callTarget as a final field > but always dispatches the call to the callTarget (no inlining possible > anymore). > > Each DispatchedSendNode knows about their callTarget as a final field and > just calls the constant/final CallTarget in the default case. > After some inlining policy (which could be immediately, later or not at > all) the DispatchedSendNode gets replaced by a compatible node which > represents the CallTarget. This can usually be achieved by casting the > CallTarget to DefaultCallTarget and looking at its RootNode to copy it. > > I think the described pattern should work for you and it has been proven > to work for our implementations. > I will try to put together an example using the SimpleLanguage next week. > > Have a nice weekend! > > Christian Humer > > > On Thu, Nov 7, 2013 at 5:30 PM, Stefan Marr wrote: > >> Hi Christian, >> Hi all: >> >> On 07 Nov 2013, at 14:27, Christian Humer >> wrote: >> >> > Unfortunately it is not and I also failed myself to abuse it in that >> way. There are some features (eg. caching of values) missing to declare >> polymorphic inline caches using the DSL. At the moment all polymorphic >> inline caches are implemented manually using Truffle API only. We are still >> in phase of collecting required use-cases to compile a list of required DSL >> features to support it. There are some concepts like resorting of cache >> entries or generic cache entry promotion (not completely go to generic but >> keep some hot cache entries) which would also be quite difficult to >> support. But we would be happy if we could use your implementation as an >> additional use-case for DSL support. >> >> I am just about to finish a rather large rewrite of TruffleSOM [1]. >> And for that it would be very useful if I could coerce the DSL into >> generating multiple cases out of a single specialization in order to handle >> polymorphic message sends. >> >> Overall, I think, I have three suggestions based on the TruffleSOM >> rewrite. >> I?ll try to detail them below to outline the use case and my >> understanding. Perhaps somethings are by design and should be done >> differently. >> >> The three things I would like to suggest are: >> >> - Allowing @Generic for simple non-specializing nodes, as a base case >> (uninitialized state) for custom specialization hierarchies >> - Support for inheriting @NodeChilds >> - Support for polymorphic inline caching, perhaps based on chaining >> multiple instances of the same specialization. >> >> >> Allowing @Generic for Simple Nodes >> ?????????????????????????????????- >> >> In my new node hierarchy, I use UnaryMessageNode >> (..Binary/Ternary/KeywordMsgNode) [2] to represent the initial state of >> message send as generated by the parser. So, the main idea is to avoid >> specialization before execution starts. The parser could do some simple >> specializations already purely based on the static name of a message. >> However, I decided against doing that, following what I understand to be >> one of the main suggestions for Truffle. >> >> As a result I have the UnaryMessageNode (Binary/Ternary/Keyword) class >> just implementing a doGeneric(.) method, which replace the node by a >> UnaryMonomorphicNode. For the doGeneric(.) method, I feel that @Generic >> would be the better annotation, and putting @Specialization there, because >> it otherwise wouldn?t have a specialization, feels a little unnatural. The >> @Generic annotation also has another benefit, because it enforces certain >> constraints on the method signature, which is useful to make the type >> system happy. >> >> >> Support for inheriting @NodeChild >> ????????????????????????????????- >> >> The next thing I noticed is that @NodeChild annotation are not inherited >> when the subclass defines additional @NodeChilds. While it is not a big >> issue, it feel counter intuitive when I noticed it for the first time. My >> expectation was that these annotations have an additive semantics. >> >> As an example, I have a AbstractMonomorphicMessageNode [3] with the >> @NodeChild(value = ?receiver?, ExpN.class) annotation, and in the subclass >> BinaryMonomorphicNode [4] I need to specify the receiver again, because I >> want to add an argument NodeChild. >> >> >> Polymorphic Inline Caching >> ?????????????????????????- >> >> I assume that you got already a number of specific use case form other >> Truffle languages, so I will try to outline how I would imagine potential >> support for PICs in the DSL based on what I see in TruffleSOM. >> >> One thing upfront: I decided that it want to try to conflate the notion >> of monomorphic message sends and primitive implementations. >> Thus, you will currently find the following hierarchy of nodes in >> TruffleSOM (still need to figure out whether that?s actually going to work): >> >> ExpressionNode >> +- AbstractMessageNode >> | +- AbstractMonomorphicMessageNode >> | +- BinaryMonomorphicNode >> | | +- AdditionPrimitive >> | | +- MultiplicationPrimitive >> | +- UnaryMonomorphicNode >> | +- PrintPrimitive >> | +- ... >> +- BinaryMessageNode >> +- UnaryMessageNode >> +- ... >> >> The reason why I thought that might be a good idea is to essential see >> every specialization for the primitive nodes as one variant of a >> potentially polymorphic message send. >> >> Let?s assume we have a #print primitive implemented for strings, and >> normal #print messages for other types of object, implementing something >> custom to first convert the value into a string and then printing it. >> >> So, a nice polymorphic example would be something like the following loop >> over an array: `{1. ?two?. #three. 4.0. FiveClass} do: [:elem | elem >> print]`. >> >> The print primitive could than be implemented like this: >> >> public abstract class PrintStringPrim extends UnaryMonomorphicNode { >> public PrintStringPrim(final SSymbol selector, final Universe >> universe, final SClass rcvrClass, final SMethod invokable) { >> super(selector, universe, rcvrClass, >> invokable); } >> public PrintStringPrim(final PrintStringPrim prim) { >> this(prim.selector, prim.universe, prim.rcvrClass, prim.invokable); } >> >> @Specialization >> public Object doSString(final SString receiver) { >> Universe.print(receiver.getEmbeddedString()); >> return receiver; >> } >> } >> >> And the UnaryMonomorphicNode implements a simple monomorphic method cache: >> >> public abstract class UnaryMonomorphicNode extends >> AbstractMonomorphicMessageNode { >> >> @Specialization(guards = "isCachedReceiverClass", order = >> PriorityMonomorphicCase) >> public SAbstractObject doMonomorphic(final VirtualFrame frame, >> final SAbstractObject receiver) { >> return invokable.invoke(frame.pack(), receiver, noArgs); >> } >> } >> >> So, my understanding is now that a normal node that has multiple >> specializations, perhaps based on types, can become ?node-polymorphic?. >> Thus, multiple specializations get instantiated and instead of replacing >> a previous specialization, they get chained one after another. >> And then, during execution, you walk the chain to find the one where the >> guards do not fail. >> I understand now that this chain can build up because there are multiple >> cases that can be easily identified based on different guards/tests. >> However, for the doMonomorphic(.) method, it is not multiple tests, it is >> not multiple specializations. >> Instead, the value on which a test is based differs. >> >> So, what I would find useful is if I could tell the DSL to multiply my >> specialization doMonomorphic(.) up to a given number of times, and then, I >> think for the instantiation, I would also need to give it a function that >> allows it to derive the necessary state for such ?value-based? >> specializations. >> >> Perhaps something like this: >> >> @Specialization(guards = ?isCachedReceiverClass?, order = >> PriorityMonomorphicCase, >> multiplicity = 8, specialization = {rcvrClass = >> ?classOfReceiver?, invokable = ?lookUp? } ) >> public SAbstractObject doMonomorphic(final VirtualFrame frame, final >> SAbstractObject receiver) { /* ... /* } >> >> public SClass classOfReceiver(final SAbstractObject receiver) { >> return classOfReceiver(receiver, getReceiver()); >> } >> >> public SMethod lookUp(final SAbstractObject receiver) { >> return classOfReceiver(receiver).lookupInvokable(selector); >> } >> >> I think, this might give me enough flexibility to express value-based >> specialization for polymorphic messages. >> >> When it comes to cleaning up or optimizing such polymorphic-node chains, >> well, I don?t know enough how it would behave yet. So, no ideas there so >> far. >> >> Would be interested to hear whether any of that sounds like it fits into >> how you see Truffle being used. >> >> Thanks >> Stefan >> >> >> >> [1] >> https://github.com/smarr/TruffleSOM/commit/482ccaa88306a1e7a989afdfd91e4121c5be163a >> [2] >> https://github.com/smarr/TruffleSOM/blob/482ccaa88306a1e7a989afdfd91e4121c5be163a/src/som/interpreter/nodes/UnaryMessageNode.java#L30 >> [3] >> https://github.com/smarr/TruffleSOM/blob/482ccaa88306a1e7a989afdfd91e4121c5be163a/src/som/interpreter/nodes/messages/AbstractMonomorphicMessageNode.java#L18 >> [4] >> https://github.com/smarr/TruffleSOM/blob/482ccaa88306a1e7a989afdfd91e4121c5be163a/src/som/interpreter/nodes/messages/BinaryMonomorphicNode.java#L21 >> -- >> Stefan Marr >> Software Languages Lab >> Vrije Universiteit Brussel >> Pleinlaan 2 / B-1050 Brussels / Belgium >> http://soft.vub.ac.be/~smarr >> Phone: +32 2 629 2974 >> Fax: +32 2 629 3525 >> >> > From doug.simon at oracle.com Tue Nov 12 01:09:09 2013 From: doug.simon at oracle.com (doug.simon at oracle.com) Date: Tue, 12 Nov 2013 09:09:09 +0000 Subject: hg: graal/graal: 2 new changesets Message-ID: <20131112090925.AFF8D62531@hg.openjdk.java.net> Changeset: 6a9f50777e6d Author: Doug Simon Date: 2013-11-11 22:44 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/6a9f50777e6d fixes building on MacOS for recent HSAIL changes ! make/bsd/makefiles/buildtree.make ! make/bsd/makefiles/vm.make Changeset: 70b138d008ff Author: Doug Simon Date: 2013-11-11 23:43 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/70b138d008ff HSAIL: used scoped option overriding for all GraalKernelTester based tests Contributed-by: Tom Deneau ! graal/com.oracle.graal.compiler.hsail.test.infra/src/com/oracle/graal/compiler/hsail/test/infra/GraalKernelTester.java ! graal/com.oracle.graal.compiler.hsail.test/src/com/oracle/graal/compiler/hsail/test/StaticNBodyCallTest.java ! graal/com.oracle.graal.compiler.hsail.test/src/com/oracle/graal/compiler/hsail/test/StringContainsAcceptTest.java From tom.deneau at amd.com Tue Nov 12 14:49:38 2013 From: tom.deneau at amd.com (Deneau, Tom) Date: Tue, 12 Nov 2013 22:49:38 +0000 Subject: compiled leaf method vs. inlined method bounds check Message-ID: I've noticed that if the graph I am compiling is simply a leaf method which accesses an array, the target of a failing bounds check is a DeoptimizeNode with reason=BoundsCheckException, action=InvalidateReprofile But if the method that is accessing the array is being inlined into another method, the target of the failing bounds check is a ForeignCall to createOutOfBoundsException followed by a branch to a DeoptimizeNode with reason=NotCompiledExceptionHandler, action=InvalidateRecompile. Can someone explain this difference? -- Tom From duboscq at ssw.jku.at Tue Nov 12 15:56:12 2013 From: duboscq at ssw.jku.at (Gilles Duboscq) Date: Wed, 13 Nov 2013 00:56:12 +0100 Subject: compiled leaf method vs. inlined method bounds check In-Reply-To: References: Message-ID: Can you maybe show us the snippets you used and how you ran them? The second scenario you describe usually happen if an ArrayIndexOutOfBoundsException has already been thrown at the array access you're looking at. When compiling an array access, Graal will look at the profile and if it shows that exceptions are thrown there, it will compile in the exception branch (in your case the exception branch ends up into an other deopt for some reason). If profiling shows no exception has been thrown there, it will leave out the exception branch and will only place a which deoptimizes in case an exception needs to be thrown. This should have nothing to do with inlining. When doings tests about that, be carefull not to pollute the profile for the second test with the first one. You can change the bahviour of graal reagrding these things using the UseExceptionProbabilityForOperations flag. -Gilles On Tue, Nov 12, 2013 at 11:49 PM, Tom Deneau wrote: > I've noticed that if the graph I am compiling is simply a leaf method > which accesses an array, the target of a failing bounds check is a > DeoptimizeNode with reason=BoundsCheckException, action=InvalidateReprofile > > But if the method that is accessing the array is being inlined into > another method, the target of the failing bounds check is a ForeignCall to > createOutOfBoundsException followed by a branch to a DeoptimizeNode with > reason=NotCompiledExceptionHandler, action=InvalidateRecompile. > > Can someone explain this difference? > > -- Tom > > > From tom.deneau at amd.com Tue Nov 12 16:22:21 2013 From: tom.deneau at amd.com (Deneau, Tom) Date: Wed, 13 Nov 2013 00:22:21 +0000 Subject: compiled leaf method vs. inlined method bounds check In-Reply-To: References: Message-ID: Gilles -- OK, we have a simple existing test in com.oracle.graal.compiler.hsail.test.IntAddTest which adds ints from two arrays putting the result in a third output array public static void run(int[] out, int[] ina, int[] inb, int gid) { out[gid] = ina[gid] + inb[gid]; } Here is the hsail code:. (Note that we don't really handle the DeoptimizeNode but just print a comment based on the reason). version 0:95: $full : $large; // static method HotSpotMethod kernel &run ( kernarg_u64 %_arg0, kernarg_u64 %_arg1, kernarg_u64 %_arg2 ) { ld_kernarg_u64 $d0, [%_arg0]; ld_kernarg_u64 $d1, [%_arg1]; ld_kernarg_u64 $d2, [%_arg2]; workitemabsid_u32 $s0, 0; @L0: ld_global_s32 $s1, [$d0 + 12]; cmp_ge_b1_u32 $c0, $s0, $s1; cbr $c0, @L7; @L1: ld_global_s32 $s1, [$d2 + 12]; cmp_ge_b1_u32 $c0, $s0, $s1; cbr $c0, @L7; @L2: ld_global_s32 $s1, [$d1 + 12]; cmp_ge_b1_u32 $c0, $s0, $s1; cbr $c0, @L7; @L3: cvt_s64_s32 $d3, $s0; mul_s64 $d3, $d3, 4; add_u64 $d1, $d1, $d3; ld_global_s32 $s1, [$d1 + 16]; cvt_s64_s32 $d1, $s0; mul_s64 $d1, $d1, 4; add_u64 $d2, $d2, $d1; ld_global_s32 $s2, [$d2 + 16]; add_s32 $s2, $s2, $s1; cvt_s64_s32 $d1, $s0; mul_s64 $d1, $d1, 4; add_u64 $d0, $d0, $d1; st_global_s32 $s2, [$d0 + 16]; ret; @L7: // Deoptimization for BoundsCheckException would occur here ret; }; Then I made a new test where the run method just basically called the original IntAddTest.run public static void run(int[] out, int[] ina, int[] inb, int gid) { IntAddTest.run(out, ina, inb, gid); } We compile with InlineEverything set. We got this almost identical hsail code except for the deoptimization reason. (In this case, there is no call to createOutOfBoundsException but I have seen it in larger test cases). Note that in either case, no exceptions would have occurred when profiling. version 0:95: $full : $large; // static method HotSpotMethod kernel &run ( kernarg_u64 %_arg0, kernarg_u64 %_arg1, kernarg_u64 %_arg2 ) { ld_kernarg_u64 $d0, [%_arg0]; ld_kernarg_u64 $d1, [%_arg1]; ld_kernarg_u64 $d2, [%_arg2]; workitemabsid_u32 $s0, 0; @L0: ld_global_s32 $s1, [$d0 + 12]; cmp_ge_b1_u32 $c0, $s0, $s1; cbr $c0, @L7; @L1: ld_global_s32 $s1, [$d2 + 12]; cmp_ge_b1_u32 $c0, $s0, $s1; cbr $c0, @L7; @L2: ld_global_s32 $s1, [$d1 + 12]; cmp_ge_b1_u32 $c0, $s0, $s1; cbr $c0, @L7; @L3: cvt_s64_s32 $d3, $s0; mul_s64 $d3, $d3, 4; add_u64 $d1, $d1, $d3; ld_global_s32 $s1, [$d1 + 16]; cvt_s64_s32 $d1, $s0; mul_s64 $d1, $d1, 4; add_u64 $d2, $d2, $d1; ld_global_s32 $s2, [$d2 + 16]; add_s32 $s2, $s2, $s1; cvt_s64_s32 $d1, $s0; mul_s64 $d1, $d1, 4; add_u64 $d0, $d0, $d1; st_global_s32 $s2, [$d0 + 16]; ret; @L7: // Deoptimization for NotCompiledExceptionHandler would occur here ret; }; From: gilwooden at gmail.com [mailto:gilwooden at gmail.com] On Behalf Of Gilles Duboscq Sent: Tuesday, November 12, 2013 5:56 PM To: Deneau, Tom Cc: graal-dev at openjdk.java.net Subject: Re: compiled leaf method vs. inlined method bounds check Can you maybe show us the snippets you used and how you ran them? The second scenario you describe usually happen if an ArrayIndexOutOfBoundsException has already been thrown at the array access you're looking at. When compiling an array access, Graal will look at the profile and if it shows that exceptions are thrown there, it will compile in the exception branch (in your case the exception branch ends up into an other deopt for some reason). If profiling shows no exception has been thrown there, it will leave out the exception branch and will only place a which deoptimizes in case an exception needs to be thrown. This should have nothing to do with inlining. When doings tests about that, be carefull not to pollute the profile for the second test with the first one. You can change the bahviour of graal reagrding these things using the UseExceptionProbabilityForOperations flag. -Gilles On Tue, Nov 12, 2013 at 11:49 PM, Tom Deneau > wrote: I've noticed that if the graph I am compiling is simply a leaf method which accesses an array, the target of a failing bounds check is a DeoptimizeNode with reason=BoundsCheckException, action=InvalidateReprofile But if the method that is accessing the array is being inlined into another method, the target of the failing bounds check is a ForeignCall to createOutOfBoundsException followed by a branch to a DeoptimizeNode with reason=NotCompiledExceptionHandler, action=InvalidateRecompile. Can someone explain this difference? -- Tom From jjfumero at gmail.com Thu Nov 14 07:54:09 2013 From: jjfumero at gmail.com (=?ISO-8859-1?Q?Juan_Jos=E9_Fumero_Alfonso?=) Date: Thu, 14 Nov 2013 15:54:09 +0000 Subject: Inlining in Graal Message-ID: Hi, I am working on Inlining with Graal in my backend. Using the Log information: -XX:+BootstrapGraal -G:Log=InliningDecisions -XX:+PrintCompilation I get this: [thread:1] scope: [thread:1] scope: Inlining [thread:1] scope: Inlining.Inlining [thread:1] scope: Inlining.Inlining.InliningDecisions * inlining MapEngineOpenCL.kernelComputation at 11: exact com.edinburgh.parallel.map.MapEngineOpenCL.checkInline(int):int: trivial (relevance=1.000000, probability=1.000000, bonus=1.000000, nodes=6) * With this code: // Testing public void kernelComputation(int[] input, int[] output) { for (int i = 0; i < input.length; i++) { * output[i] = checkInline(input[i]);* } } private int checkInline(int a) { return 10 + a; } So in this case the inlining is working and also the result in my program is correct. But what I want to do is the following: public void kernelComputation(T[] input, T[] output) { for (int i = 0; i < input.length; i++) { *output[i] = mInterface.f(input[i]);* } } And the method f is defined dynamically by the user: Integer[] result = Map.apply(data, new MapInterface() { @Override * public Integer f(Integer data) { return data * data; }* }).executeOpenCL(); What I want to do is the inlining of the f method which is defined dynamically by the user. [thread:1] scope: [thread:1] scope: Inlining [thread:1] scope: Inlining.InliningDecisions * not inlining MapEngineOpenCL.kernelComputation at 14: com.edinburgh.parallel.map.MapInterface.f(Object):Object (0 bytes): no type profile exists* I do not understand why "no type profile exists". Any idea about this? I am doing the inlining as Graal shows in the tests (com.oracle.graal.compiler.test.inlining). Thank you very much Juanjo From Lukas.Stadler at jku.at Fri Nov 15 01:58:37 2013 From: Lukas.Stadler at jku.at (Lukas Stadler) Date: Fri, 15 Nov 2013 10:58:37 +0100 Subject: Inlining in Graal In-Reply-To: References: Message-ID: <5285FE5D0200000600105E13@gwia.im.jku.at> Hi Juan, in your working example, the checkInline call is a private method that can statically be bound to a specific target, without the help of profiling information. Thus, it can be inlined. The non-working example, however, contains an virtual/interface call, which means that the compiler needs a hint from somewhere as to which method could be the target of this call. The inlining heuristics in Graal assume that all important code has been running in the interpreter for a while (i.e. thousands of times). I guess that you are compiling code that has never been executed in the interpreter? One solution would be to warm up the method in the interpreter. However, the profiling information accumulates, so that the call site will become polymorphic and again stop inlining at some point. In your case, the closure that does the computation is known at the time of compilation (I guess). You could replace the parameter with a constant during your compilation process, which should allow the compiler to devirtualize the call. Is that a strategy that could work for you? - Lukas >>> Juan Jos? Fumero Alfonso 11/14/13 4:55 PM >>> Hi, I am working on Inlining with Graal in my backend. Using the Log information: -XX:+BootstrapGraal -G:Log=InliningDecisions -XX:+PrintCompilation I get this: [thread:1] scope: [thread:1] scope: Inlining [thread:1] scope: Inlining.Inlining [thread:1] scope: Inlining.Inlining.InliningDecisions * inlining MapEngineOpenCL.kernelComputation at 11: exact com.edinburgh.parallel.map.MapEngineOpenCL.checkInline(int):int: trivial (relevance=1.000000, probability=1.000000, bonus=1.000000, nodes=6) * With this code: // Testing public void kernelComputation(int[] input, int[] output) { for (int i = 0; i < input.length; i++) { * output[i] = checkInline(input[i]);* } } private int checkInline(int a) { return 10 + a; } So in this case the inlining is working and also the result in my program is correct. But what I want to do is the following: public void kernelComputation(T[] input, T[] output) { for (int i = 0; i < input.length; i++) { *output[i] = mInterface.f(input[i]);* } } And the method f is defined dynamically by the user: Integer[] result = Map.apply(data, new MapInterface() { @Override * public Integer f(Integer data) { return data * data; }* }).executeOpenCL(); What I want to do is the inlining of the f method which is defined dynamically by the user. [thread:1] scope: [thread:1] scope: Inlining [thread:1] scope: Inlining.InliningDecisions * not inlining MapEngineOpenCL.kernelComputation at 14: com.edinburgh.parallel.map.MapInterface.f(Object):Object (0 bytes): no type profile exists* I do not understand why "no type profile exists". Any idea about this? I am doing the inlining as Graal shows in the tests (com.oracle.graal.compiler.test.inlining). Thank you very much Juanjo From jjfumero at gmail.com Fri Nov 15 03:14:54 2013 From: jjfumero at gmail.com (=?ISO-8859-1?Q?Juan_Jos=E9_Fumero_Alfonso?=) Date: Fri, 15 Nov 2013 11:14:54 +0000 Subject: Inlining in Graal In-Reply-To: <5285FE5D0200000600105E13@gwia.im.jku.at> References: <5285FE5D0200000600105E13@gwia.im.jku.at> Message-ID: Hi Luka, I do not understand your second approach. In which moment the inlining is applied if I replace it with a constant? Is possible to force the inlining? I mean, a way to disable the heuristic for a while and create the inline. Thanks Juanjo 2013/11/15 Lukas Stadler > Hi Juan, > > > in your working example, the checkInline call is a private method that > can statically be bound to a specific target, without the help of > profiling information. Thus, it can be inlined. > The non-working example, however, contains an virtual/interface call, > which means that the compiler needs a hint from somewhere as to which > method could be the target of this call. > The inlining heuristics in Graal assume that all important code has been > running in the interpreter for a while (i.e. thousands of times). > I guess that you are compiling code that has never been executed in the > interpreter? > > > One solution would be to warm up the method in the interpreter. However, > the profiling information accumulates, so that the call site will become > polymorphic and again stop inlining at some point. > In your case, the closure that does the computation is known at the time > of compilation (I guess). You could replace the parameter with a > constant during your compilation process, which should allow the > compiler to devirtualize the call. > Is that a strategy that could work for you? > > > - Lukas > > >>> Juan Jos? Fumero Alfonso 11/14/13 4:55 PM >>> > Hi, > I am working on Inlining with Graal in my backend. Using the Log > information: > > -XX:+BootstrapGraal -G:Log=InliningDecisions -XX:+PrintCompilation > > I get this: > > [thread:1] scope: > [thread:1] scope: Inlining > [thread:1] scope: Inlining.Inlining > [thread:1] scope: Inlining.Inlining.InliningDecisions > > * inlining MapEngineOpenCL.kernelComputation at 11: exact > com.edinburgh.parallel.map.MapEngineOpenCL.checkInline(int):int: trivial > (relevance=1.000000, probability=1.000000, bonus=1.000000, nodes=6) * > > With this code: > > // Testing > public void kernelComputation(int[] input, int[] output) { > for (int i = 0; i < input.length; i++) { > * output[i] = checkInline(input[i]);* > } > } > > private int checkInline(int a) { > return 10 + a; > } > > So in this case the inlining is working and also the result in my > program > is correct. But what I want to do is the following: > > > public void kernelComputation(T[] input, T[] output) { > for (int i = 0; i < input.length; i++) { > *output[i] = mInterface.f(input[i]);* > } > } > > > And the method f is defined dynamically by the user: > > > Integer[] result = Map.apply(data, new MapInterface() { > @Override > > > * public Integer f(Integer data) { return data > * > data; }* > > }).executeOpenCL(); > > > What I want to do is the inlining of the f method which is defined > dynamically by the user. > > [thread:1] scope: > [thread:1] scope: Inlining > [thread:1] scope: Inlining.InliningDecisions > * not inlining MapEngineOpenCL.kernelComputation at 14: > com.edinburgh.parallel.map.MapInterface.f(Object):Object (0 bytes): no > type > profile exists* > > > I do not understand why "no type profile exists". Any idea about this? I > am > doing the inlining as Graal shows in the tests > (com.oracle.graal.compiler.test.inlining). > > Thank you very much > Juanjo > > > > > From tom.deneau at amd.com Fri Nov 15 13:28:06 2013 From: tom.deneau at amd.com (Deneau, Tom) Date: Fri, 15 Nov 2013 21:28:06 +0000 Subject: webrev to fix some assert logic in the hsail argument-gathering code Message-ID: I have posted a small webrev to fix some assert logic in the argument-gathering code that shows up when non-product hotspot builds are done with the new "run hsail kernels in hotspot" logic. http://cr.openjdk.java.net/~tdeneau/graal-webrevs/webrev-okrahotspot-assert-fixes/webrev/ Summary: * computes parameter_count based on signature and uses that and parameter_index (set by the SignatureIterator) to tell if we are on the last parameter, which requires special handling whether it is an int or an object. * if signature says last parameter is an Object, checks that the real passed in parameter is an Object Array, but for non last-parameters, lets objects go thru. * if signature says last parameter is an int, nothing is pushed (no change to this logic) -- Tom From meloli87 at gmail.com Fri Nov 15 21:17:55 2013 From: meloli87 at gmail.com (Chen Li) Date: Fri, 15 Nov 2013 21:17:55 -0800 Subject: graal build failed on Mac OS 10.9 Mavericks Message-ID: Does anyone encounter this build issue on Mac OS 10.9 Mavericks using clang? I got the following errors while building graal clang: error: argument unused during compilation: '-fcheck-new' clang: error: argument unused during compilation: '-fpch-deps' thanks, melo From doug.simon at oracle.com Sat Nov 16 00:27:46 2013 From: doug.simon at oracle.com (Doug Simon) Date: Sat, 16 Nov 2013 09:27:46 +0100 Subject: graal build failed on Mac OS 10.9 Mavericks In-Reply-To: References: Message-ID: <0E73E38E-EFA4-464F-921A-8D13DBF1D5D4@oracle.com> I think the solution (for now) is to disable use of precompiled headers: USE_CLANG=true USE_PRECOMPILED_HEADER=0 % mx clean % mx build -Doug On Nov 16, 2013, at 6:17 AM, Chen Li wrote: > Does anyone encounter this build issue on Mac OS 10.9 Mavericks using > clang? > > I got the following errors while building graal > > clang: error: argument unused during compilation: '-fcheck-new' > > clang: error: argument unused during compilation: '-fpch-deps' > > > thanks, > melo From doug.simon at oracle.com Sat Nov 16 18:00:15 2013 From: doug.simon at oracle.com (doug.simon at oracle.com) Date: Sun, 17 Nov 2013 02:00:15 +0000 Subject: hg: graal/graal: 13 new changesets Message-ID: <20131117020101.3007E62649@hg.openjdk.java.net> Changeset: a36839dafe50 Author: Gilles Duboscq Date: 2013-11-12 10:59 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/a36839dafe50 Remove some useless short casts, synchronize deoptimization.hpp with HotSpotMetaAccessProvider ! graal/com.oracle.graal.hotspot.amd64/src/com/oracle/graal/hotspot/amd64/AMD64HotSpotLIRGenerator.java ! graal/com.oracle.graal.hotspot.sparc/src/com/oracle/graal/hotspot/sparc/SPARCHotSpotLIRGenerator.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotMetaAccessProvider.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/DeoptimizeNode.java ! src/share/vm/runtime/deoptimization.hpp Changeset: ca33948fb804 Author: Gilles Duboscq Date: 2013-11-12 11:01 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/ca33948fb804 nmethod.cpp: s/unknwon/unknown/ ! src/share/vm/code/nmethod.cpp Changeset: cabef8844203 Author: Roland Schatz Date: 2013-11-12 12:07 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/cabef8844203 Delete accidentially commited files. - graal/com.oracle.truffle.sl/src/com/oracle/truffle/sl/parser/Parser.java.old - graal/com.oracle.truffle.sl/src/com/oracle/truffle/sl/parser/Scanner.java.old Changeset: aeb651f3c5d9 Author: Doug Simon Date: 2013-11-12 13:12 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/aeb651f3c5d9 made external node ids stable across graph dumps to the IGV ! graal/com.oracle.graal.printer/src/com/oracle/graal/printer/BinaryGraphPrinter.java Changeset: 8b82bdad798a Author: Roland Schatz Date: 2013-11-12 16:21 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/8b82bdad798a Make it possible to run counted loop detection on a single loop. ! graal/com.oracle.graal.loop/src/com/oracle/graal/loop/LoopEx.java ! graal/com.oracle.graal.loop/src/com/oracle/graal/loop/LoopsData.java Changeset: 884bee435276 Author: S.Bharadwaj Yadavalli Date: 2013-11-12 13:54 -0500 URL: http://hg.openjdk.java.net/graal/graal/rev/884bee435276 Implement support for passing byte arguments in Java methods to be compiled to PTX. Fix incorrect .reg and .param declarations in PTX kernels. Refactor and clean up PTXAssembler to PTXMacroAssembler. ! graal/com.oracle.graal.asm.ptx/src/com/oracle/graal/asm/ptx/PTXAssembler.java + graal/com.oracle.graal.asm.ptx/src/com/oracle/graal/asm/ptx/PTXMacroAssembler.java ! graal/com.oracle.graal.compiler.ptx.test/src/com/oracle/graal/compiler/ptx/test/ControlPTXTest.java ! graal/com.oracle.graal.compiler.ptx.test/src/com/oracle/graal/compiler/ptx/test/IntegerPTXTest.java ! graal/com.oracle.graal.compiler.ptx/src/com/oracle/graal/compiler/ptx/PTXLIRGenerator.java ! graal/com.oracle.graal.hotspot.ptx/src/com/oracle/graal/hotspot/ptx/PTXHotSpotBackend.java ! graal/com.oracle.graal.lir.ptx/src/com/oracle/graal/lir/ptx/PTXArithmetic.java ! graal/com.oracle.graal.lir.ptx/src/com/oracle/graal/lir/ptx/PTXBitManipulationOp.java ! graal/com.oracle.graal.lir.ptx/src/com/oracle/graal/lir/ptx/PTXCompare.java ! graal/com.oracle.graal.lir.ptx/src/com/oracle/graal/lir/ptx/PTXControlFlow.java ! graal/com.oracle.graal.lir.ptx/src/com/oracle/graal/lir/ptx/PTXLIRInstruction.java ! graal/com.oracle.graal.lir.ptx/src/com/oracle/graal/lir/ptx/PTXMemOp.java ! graal/com.oracle.graal.lir.ptx/src/com/oracle/graal/lir/ptx/PTXMove.java ! graal/com.oracle.graal.lir.ptx/src/com/oracle/graal/lir/ptx/PTXParameterOp.java ! graal/com.oracle.graal.lir.ptx/src/com/oracle/graal/lir/ptx/PTXTestOp.java Changeset: bff24aae4640 Author: Mick Jordan Date: 2013-11-12 16:22 -0800 URL: http://hg.openjdk.java.net/graal/graal/rev/bff24aae4640 unlink mx_graal.py - mx/mx_graal.py Changeset: 6cdf3b17316d Author: Mick Jordan Date: 2013-11-12 19:39 -0800 URL: http://hg.openjdk.java.net/graal/graal/rev/6cdf3b17316d mx: rename commands.py as mx_graal.py - mx/commands.py + mx/mx_graal.py Changeset: 49d38e959de1 Author: Roland Schatz Date: 2013-11-13 11:38 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/49d38e959de1 Move FixedValueAnchorNode out of hotspot dependent project. - graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/nodes/FixedValueAnchorNode.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/UnsafeLoadSnippets.java + graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/extended/FixedValueAnchorNode.java Changeset: 0b7172f093d0 Author: Tom Rodriguez Date: 2013-11-13 11:14 -0800 URL: http://hg.openjdk.java.net/graal/graal/rev/0b7172f093d0 don't sign extend integer laods ! graal/com.oracle.graal.lir.amd64/src/com/oracle/graal/lir/amd64/AMD64Move.java Changeset: 5a51864f3088 Author: Doug Simon Date: 2013-11-14 15:02 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/5a51864f3088 moved raw memory TLAB allocation routine into NewInstanceStub and unsnippetized it ! 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 Changeset: 2842b357c316 Author: Doug Simon Date: 2013-11-14 23:29 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/2842b357c316 moved options guiding when to use profile info in compiled type checks to InstanceOfSnippets ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/InstanceOfSnippets.java ! graal/com.oracle.graal.phases/src/com/oracle/graal/phases/GraalOptions.java Changeset: 99769479f9ce Author: Gilles Duboscq Date: 2013-11-15 11:20 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/99769479f9ce s/commands/mx_graal/ in mx/sanitycheck.py ! mx/sanitycheck.py From Lukas.Stadler at jku.at Mon Nov 18 11:28:30 2013 From: Lukas.Stadler at jku.at (Lukas Stadler) Date: Mon, 18 Nov 2013 20:28:30 +0100 Subject: Inlining in Graal In-Reply-To: References: <5285FE5D0200000600105E13@gwia.im.jku.at> Message-ID: <528A786E02000006001061F4@gwia.im.jku.at> Yes, sorry, that was missing some context. You can pass an inlining policy to the InliningPhase, InlineEverythingPolicy is a good place to start looking. But that will probably still not solve your problem, because in some cases it might be impossible for the compiler to determine what it should inline. Imagine a call to run on some Runnable that comes from a parameter: the compiler has no way of knowing which concrete method will be called in the end. If, by the time you do the compilation, you know the exact instance of Runnable which is called, you can create a ConstantNode for this object and replace the parameter (i.e., the LocalNode) with this constant. Then the compiler will have more luck figuring out the concrete method because it sees the actual type on which the run method will be called. - Lukas >>> Juan Jos? Fumero Alfonso 11/15/13 12:16 PM >>> Hi Luka, I do not understand your second approach. In which moment the inlining is applied if I replace it with a constant? Is possible to force the inlining? I mean, a way to disable the heuristic for a while and create the inline. Thanks Juanjo 2013/11/15 Lukas Stadler > Hi Juan, > > > in your working example, the checkInline call is a private method that > can statically be bound to a specific target, without the help of > profiling information. Thus, it can be inlined. > The non-working example, however, contains an virtual/interface call, > which means that the compiler needs a hint from somewhere as to which > method could be the target of this call. > The inlining heuristics in Graal assume that all important code has been > running in the interpreter for a while (i.e. thousands of times). > I guess that you are compiling code that has never been executed in the > interpreter? > > > One solution would be to warm up the method in the interpreter. However, > the profiling information accumulates, so that the call site will become > polymorphic and again stop inlining at some point. > In your case, the closure that does the computation is known at the time > of compilation (I guess). You could replace the parameter with a > constant during your compilation process, which should allow the > compiler to devirtualize the call. > Is that a strategy that could work for you? > > > - Lukas > > >>> Juan Jos? Fumero Alfonso 11/14/13 4:55 PM >>> > Hi, > I am working on Inlining with Graal in my backend. Using the Log > information: > > -XX:+BootstrapGraal -G:Log=InliningDecisions -XX:+PrintCompilation > > I get this: > > [thread:1] scope: > [thread:1] scope: Inlining > [thread:1] scope: Inlining.Inlining > [thread:1] scope: Inlining.Inlining.InliningDecisions > > * inlining MapEngineOpenCL.kernelComputation at 11: exact > com.edinburgh.parallel.map.MapEngineOpenCL.checkInline(int):int: trivial > (relevance=1.000000, probability=1.000000, bonus=1.000000, nodes=6) * > > With this code: > > // Testing > public void kernelComputation(int[] input, int[] output) { > for (int i = 0; i < input.length; i++) { > * output[i] = checkInline(input[i]);* > } > } > > private int checkInline(int a) { > return 10 + a; > } > > So in this case the inlining is working and also the result in my > program > is correct. But what I want to do is the following: > > > public void kernelComputation(T[] input, T[] output) { > for (int i = 0; i < input.length; i++) { > *output[i] = mInterface.f(input[i]);* > } > } > > > And the method f is defined dynamically by the user: > > > Integer[] result = Map.apply(data, new MapInterface() { > @Override > > > * public Integer f(Integer data) { return data > * > data; }* > > }).executeOpenCL(); > > > What I want to do is the inlining of the f method which is defined > dynamically by the user.> * not inlining MapEngineOpenCL.kernelComputation at 14: > com.edinburgh.parallel.map.MapInterface.f(Object):Object (0 bytes): no > type > profile exists* > > > I do not understand why "no type profile exists". Any idea about this? I > am > doing the inlining as Graal shows in the tests > (com.oracle.graal.compiler.test.inlining). > > Thank you very much > Juanjo > > > > > From falbert9 at vt.edu Tue Nov 19 09:51:09 2013 From: falbert9 at vt.edu (Curt Albert) Date: Tue, 19 Nov 2013 12:51:09 -0500 Subject: Graal Optimization Question Message-ID: I have a Java API that i would like to optimize grail for. I have a method that when called I would like graal to vectorize it. The solution is two different parts. 1. Is it possible to add an optimization to graal that would look for a certain method call and optimize it in a specific way? If so where would I add this code to graal? 2. Once graal has the method it needs to compile it using vector instructions. Where in graal does it compile byte code to assembly? Thanks, Curt Albert From Vasanth.Venkatachalam at amd.com Tue Nov 19 15:25:14 2013 From: Vasanth.Venkatachalam at amd.com (Venkatachalam, Vasanth) Date: Tue, 19 Nov 2013 23:25:14 +0000 Subject: webrev for switch statement support in HSAIL backend Message-ID: <5DD1503F815BD14889DC81D28643E3A75788AB08@SATLEXDAG02.amd.com> Hi, I've submitted a webrev for handling switch constructs generated by Java bytecode. Please review at http://cr.openjdk.java.net/~tdeneau/webrev-switchsupport.00/webrev/ Notes: This webrev adds support for the IntegerSwitchNode. (Support for TypeSwitchNode may be added later.) The approach currently recommended for generating performant HSAIL code for Java switch statements is to generate a series of cascading compare and branch instructions (instead of doing a table switch).This is the approach that I have implemented here. I've added an additional enhancement to HSAILAssembler which is unrelated to the switch support. The routine mov(Register reg, Object obj) previously had a restriction that the Object parameter had to be an instance of Class. This restriction has been lifted. I ran this through the Eclipse 4.3 formatter and there weren't any file changes. Vasanth From tom.deneau at amd.com Tue Nov 19 15:30:05 2013 From: tom.deneau at amd.com (Deneau, Tom) Date: Tue, 19 Nov 2013 23:30:05 +0000 Subject: replacements and getHostProviders Message-ID: Doug or others -- Currently the HSAIL backend lazily delegates all replacements to the host. And in HSAILHotSpotBackendFactory we also define our backend registers to be HotSpotRegisters registers = new HotSpotRegisters(Register.None, Register.None, Register.None); expecting that to hit an assert if anything tries to get the threadRegister, heapBaseRegister or stackPointerRegister. But if the method we are compiling in the HSAIL backend starts expanding a snippet that might use the threadRegister, I see that HotSpotReplacementsUtil defines threadRegister() as public static Register threadRegister() { return runtime().getHostProviders().getRegisters().getThreadRegister(); } which always goes to the host rather than the backend's registers. So we don't catch an error at compile time but instead at runtime. Is it a mistake that HotSpotReplacementsUtil goes thru the HostProviders? I realize that in a real solution we should not delegate all replacements to the host, just the ones we know we can implement, but just wondering about the above question. -- Tom From doug.simon at oracle.com Tue Nov 19 16:14:34 2013 From: doug.simon at oracle.com (Doug Simon) Date: Wed, 20 Nov 2013 01:14:34 +0100 Subject: replacements and getHostProviders In-Reply-To: References: Message-ID: <528BFEEA.9050000@oracle.com> On 11/20/2013 12:30 AM, Deneau, Tom wrote: > Doug or others -- > > Currently the HSAIL backend lazily delegates all replacements to the host. > And in HSAILHotSpotBackendFactory we also define our backend registers to be > HotSpotRegisters registers = new HotSpotRegisters(Register.None, Register.None, Register.None); > > expecting that to hit an assert if anything tries to get the threadRegister, heapBaseRegister or stackPointerRegister. > > But if the method we are compiling in the HSAIL backend starts expanding a snippet that might use the threadRegister, > I see that HotSpotReplacementsUtil defines threadRegister() as > > public static Register threadRegister() { > return runtime().getHostProviders().getRegisters().getThreadRegister(); > } > > which always goes to the host rather than the backend's registers. So we don't catch an error at compile time but > instead at runtime. > > Is it a mistake that HotSpotReplacementsUtil goes thru the HostProviders? No - these utils are for host-only snippets. This is why I explained previously that for HSAIL you cannot re-use the snippets that use these utils. -Doug From doug.simon at oracle.com Tue Nov 19 16:22:30 2013 From: doug.simon at oracle.com (Doug Simon) Date: Wed, 20 Nov 2013 01:22:30 +0100 Subject: webrev for switch statement support in HSAIL backend In-Reply-To: <5DD1503F815BD14889DC81D28643E3A75788AB08@SATLEXDAG02.amd.com> References: <5DD1503F815BD14889DC81D28643E3A75788AB08@SATLEXDAG02.amd.com> Message-ID: <528C00C6.3000202@oracle.com> graal/com.oracle.graal.asm.hsail/src/com/oracle/graal/asm/hsail/HSAILAssembler.java: + // Get a JNI reference handle to the object. + long refHandle = OkraUtil.getRefHandle(obj); How does OkraUtil manage these handles? I hope it at least never creates more than one global JNI ref for any given object or has some way to release them when no longer needed. graal/com.oracle.graal.lir.hsail/src/com/oracle/graal/lir/hsail/HSAILControlFlow.java: + // The array of key constants used for the cases of this switch statement. + @Use({CONST}) protected Constant[] keyConstants; + // The branch target labels that correspond to each case. + private final LabelRef[] keyTargets; + private LabelRef defaultTarget; + // The key of the switch. This will be compared with each of the keyConstants. + @Alive({REG}) protected Value key; + + // Constructor. Called from the HSAILLIRGenerator.emitSequentialSwitch routine. + public SwitchOp(Constant[] keyConstants, LabelRef[] keyTargets, LabelRef defaultTarget, Value key) { Java fields and methods should have javadoc comments instead of C++ style comments. -Doug On 11/20/2013 12:25 AM, Venkatachalam, Vasanth wrote: > Hi, > > I've submitted a webrev for handling switch constructs generated by Java bytecode. > > Please review at http://cr.openjdk.java.net/~tdeneau/webrev-switchsupport.00/webrev/ > > Notes: > > This webrev adds support for the IntegerSwitchNode. (Support for TypeSwitchNode may be added later.) > > The approach currently recommended for generating performant HSAIL code for Java switch statements is to generate a series of cascading compare and branch instructions (instead of doing a table switch).This is the approach that I have implemented here. > > I've added an additional enhancement to HSAILAssembler which is unrelated to the switch support. > The routine mov(Register reg, Object obj) previously had a restriction that the Object parameter had to be an instance of Class. This restriction has been lifted. > > I ran this through the Eclipse 4.3 formatter and there weren't any file changes. > > Vasanth > > From roland.schatz at oracle.com Wed Nov 20 01:47:44 2013 From: roland.schatz at oracle.com (Roland Schatz) Date: Wed, 20 Nov 2013 10:47:44 +0100 Subject: Graal Optimization Question In-Reply-To: References: Message-ID: <528C8540.9050709@oracle.com> Hi Curt, > I have a Java API that i would like to optimize grail for. I have a method > that when called I would like graal to vectorize it. The solution is two > different parts. > > 1. Is it possible to add an optimization to graal that would look for a > certain method call and optimize it in a specific way? If so where would I > add this code to graal? Have a look at e.g. the MathSubstitutionsX86 class. It defines method substitutions for the java.lang.Math class. Another possibility would be to directly replace the call with a single MacroNode. For an example of that, look at e.g. SystemSubstitutions.arraycopy or ClassSubstitutions.cast. These substitutions are registered in the GraalMethodSubstitutions class. You can register your own substitutions by creating a new class implementing the ReplacementsProvider interface and annotating it with the @ServiceProvider(ReplacementsProvider.class) annotation. > > 2. Once graal has the method it needs to compile it using vector > instructions. Where in graal does it compile byte code to assembly? If you look at the implementation of e.g. MathSubstitutionsX86.sqrt, it calls MathIntrinsicNode.compute. That is a @NodeIntrinsic method, so the compiler inserts a MathIntrinsicNode at this point in the graph. MathIntrinsicNode implements LIRLowerable and defines a method "generate", which generates platform dependent LIR code (see AMD64LIRGenerator.emitMathSqrt). After register allocation, the LIR code is turned into assembly (see Unary2Op.emitCode). I hope that helps get you started. - Roland > > Thanks, > Curt Albert From tom.deneau at amd.com Wed Nov 20 05:26:05 2013 From: tom.deneau at amd.com (Deneau, Tom) Date: Wed, 20 Nov 2013 13:26:05 +0000 Subject: replacements and getHostProviders In-Reply-To: <528BFEEA.9050000@oracle.com> References: <528BFEEA.9050000@oracle.com> Message-ID: Doug -- OK, to solve this particular problem, we will not delegate certain lowerings back to the host. But regarding the ReplacementUtils being only for host-only snippets, I remember the previous discussion but can't say I understood the reason. Back then you said: "The only way to do this is to pass all relevant configuration information into this snippets as @ConstantParameter arguments. This means every snippet that directly or indirectly uses a @Fold method (e.g., in HotSpotReplacementUtils) needs to be modified." However, in some of our allocation experiments, which we have not pushed back to trunk yet, we were able to reuse some of the utils without problem (we did have to override the threadRegister routine). Were we just lucky? How does the @Fold annotation figure into this? Also, is there a way to have an assert to catch if some backend does accidentally try to use one of the host-only snippets so we catch it at compile time? -- Tom -----Original Message----- From: graal-dev-bounces at openjdk.java.net [mailto:graal-dev-bounces at openjdk.java.net] On Behalf Of Doug Simon Sent: Tuesday, November 19, 2013 6:15 PM To: graal-dev at openjdk.java.net Subject: Re: replacements and getHostProviders On 11/20/2013 12:30 AM, Deneau, Tom wrote: > Doug or others -- > > Currently the HSAIL backend lazily delegates all replacements to the host. > And in HSAILHotSpotBackendFactory we also define our backend registers to be > HotSpotRegisters registers = new > HotSpotRegisters(Register.None, Register.None, Register.None); > > expecting that to hit an assert if anything tries to get the threadRegister, heapBaseRegister or stackPointerRegister. > > But if the method we are compiling in the HSAIL backend starts > expanding a snippet that might use the threadRegister, I see that > HotSpotReplacementsUtil defines threadRegister() as > > public static Register threadRegister() { > return runtime().getHostProviders().getRegisters().getThreadRegister(); > } > > which always goes to the host rather than the backend's registers. So > we don't catch an error at compile time but instead at runtime. > > Is it a mistake that HotSpotReplacementsUtil goes thru the HostProviders? No - these utils are for host-only snippets. This is why I explained previously that for HSAIL you cannot re-use the snippets that use these utils. -Doug From doug.simon at oracle.com Wed Nov 20 06:35:39 2013 From: doug.simon at oracle.com (Doug Simon) Date: Wed, 20 Nov 2013 15:35:39 +0100 Subject: replacements and getHostProviders In-Reply-To: References: <528BFEEA.9050000@oracle.com> Message-ID: <0B8A06A9-183B-44F1-85A6-69B148D277F3@oracle.com> On Nov 20, 2013, at 2:26 PM, Deneau, Tom wrote: > Doug -- > > OK, to solve this particular problem, we will not delegate certain lowerings back to the host. > > But regarding the ReplacementUtils being only for host-only snippets, I remember the previous discussion but can't say I understood the reason. > > Back then you said: > "The only way to do this is to pass all relevant configuration information into this snippets as @ConstantParameter arguments. This means every snippet that directly or indirectly uses a @Fold method (e.g., in HotSpotReplacementUtils) needs to be modified." > > However, in some of our allocation experiments, which we have not pushed back to trunk yet, we were able to reuse some of the utils without problem (we did have to override the threadRegister routine). Were we just lucky? How does the @Fold annotation figure into this? The @Fold annotation means that during snippet preparation, a call to such a method is executed (via reflection) and the resulting value replaces the invoke. So, if such a method retrieves host specific configuration information, that information is ?baked? into the snippet. For most of the snippets, this is configuration information. For example: @Fold private static int threadTlabEndOffset() { return config().threadTlabEndOffset(); } Configuration in this context means HotSpotVMConfig. I?m currently pushing changes that all registers used by snippets/stubs are now passed into the snippets/stub. In conjunction, I?ve made HSAIL reuse the HotSpot host snippets, just with a different HotSpotRegistersProvider object. In theory, this means the snippets should be closer to working on HSAIL although I?m sure there?s still unresolved issues. -Doug > -----Original Message----- > From: graal-dev-bounces at openjdk.java.net [mailto:graal-dev-bounces at openjdk.java.net] On Behalf Of Doug Simon > Sent: Tuesday, November 19, 2013 6:15 PM > To: graal-dev at openjdk.java.net > Subject: Re: replacements and getHostProviders > > > > On 11/20/2013 12:30 AM, Deneau, Tom wrote: >> Doug or others -- >> >> Currently the HSAIL backend lazily delegates all replacements to the host. >> And in HSAILHotSpotBackendFactory we also define our backend registers to be >> HotSpotRegisters registers = new >> HotSpotRegisters(Register.None, Register.None, Register.None); >> >> expecting that to hit an assert if anything tries to get the threadRegister, heapBaseRegister or stackPointerRegister. >> >> But if the method we are compiling in the HSAIL backend starts >> expanding a snippet that might use the threadRegister, I see that >> HotSpotReplacementsUtil defines threadRegister() as >> >> public static Register threadRegister() { >> return runtime().getHostProviders().getRegisters().getThreadRegister(); >> } >> >> which always goes to the host rather than the backend's registers. So >> we don't catch an error at compile time but instead at runtime. >> >> Is it a mistake that HotSpotReplacementsUtil goes thru the HostProviders? > > No - these utils are for host-only snippets. This is why I explained previously that for HSAIL you cannot re-use the snippets that use these utils. > > -Doug > > From doug.simon at oracle.com Wed Nov 20 10:29:18 2013 From: doug.simon at oracle.com (doug.simon at oracle.com) Date: Wed, 20 Nov 2013 18:29:18 +0000 Subject: hg: graal/graal: 28 new changesets Message-ID: <20131120183108.2439462715@hg.openjdk.java.net> Changeset: 3e013f4512de Author: Michael Haupt Date: 2013-11-18 09:11 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/3e013f4512de temporary addition of CompilerDirectives.transferToInterpreterAndInvalidate() ! 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 Changeset: d3f5a5b1d99c Author: Roland Schatz Date: 2013-11-18 17:02 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/d3f5a5b1d99c Use argument graph in BinaryNode smart constructors. ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/calc/BinaryNode.java Changeset: 6a7b6dcb7f67 Author: Bernhard Urban Date: 2013-11-18 17:22 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/6a7b6dcb7f67 NewMemoryAwareScheduling: fix out of loop for FloatingReadNodes ! graal/com.oracle.graal.phases/src/com/oracle/graal/phases/schedule/SchedulePhase.java Changeset: b6e04d6fe3a7 Author: Bernhard Urban Date: 2013-11-18 17:22 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/b6e04d6fe3a7 NewMemoryAwareScheduling: rewrite to set based approach ! graal/com.oracle.graal.phases/src/com/oracle/graal/phases/graph/ReentrantBlockIterator.java ! graal/com.oracle.graal.phases/src/com/oracle/graal/phases/schedule/SchedulePhase.java Changeset: 1729072a893a Author: Bernhard Urban Date: 2013-11-18 22:07 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/1729072a893a NewMemoryAwareScheduling: hide data structure behind wrapper class ! graal/com.oracle.graal.phases/src/com/oracle/graal/phases/schedule/SchedulePhase.java Changeset: d70077ca358a Author: Bernhard Urban Date: 2013-11-18 22:12 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/d70077ca358a enable -G:+NewMemoryAwareScheduling per default ! graal/com.oracle.graal.phases/src/com/oracle/graal/phases/GraalOptions.java Changeset: a7990d87c26e Author: Doug Simon Date: 2013-11-18 14:26 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/a7990d87c26e added support for unconditionally enabling a DebugTimer or DebugMetric, regardless of whether general Debug capabilities are enabled ! graal/com.oracle.graal.debug/src/com/oracle/graal/debug/Debug.java Changeset: 516ad7baa080 Author: Doug Simon Date: 2013-11-18 14:27 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/516ad7baa080 made the BytecodesParsed and InlinedBytecodes metrics and CompilationTime timer be unconditionally enabled if -XX:+CITime ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/HotSpotOptions.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/bridge/VMToCompilerImpl.java Changeset: c125485642e2 Author: Doug Simon Date: 2013-11-19 01:12 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/c125485642e2 added getCurrentValue() to both DebugTimer and DebugValue; added getTimeUnit() to DebugTimer ! graal/com.oracle.graal.debug/src/com/oracle/graal/debug/Debug.java ! graal/com.oracle.graal.debug/src/com/oracle/graal/debug/DebugMetric.java ! graal/com.oracle.graal.debug/src/com/oracle/graal/debug/DebugTimer.java ! graal/com.oracle.graal.debug/src/com/oracle/graal/debug/internal/DebugValue.java ! graal/com.oracle.graal.debug/src/com/oracle/graal/debug/internal/TimerImpl.java Changeset: f6c511451e4a Author: Doug Simon Date: 2013-11-19 01:31 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/f6c511451e4a made Graal report its compilation info under -XX:+CITime in the same format as c1 and c2 ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/CompilationTask.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/HotSpotVMConfig.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 ! src/share/vm/classfile/vmSymbols.hpp ! src/share/vm/compiler/abstractCompiler.hpp ! src/share/vm/compiler/compileBroker.cpp ! src/share/vm/graal/graalCompiler.cpp ! src/share/vm/graal/graalCompilerToVM.cpp ! src/share/vm/graal/graalVMToCompiler.cpp ! src/share/vm/graal/graalVMToCompiler.hpp ! src/share/vm/runtime/vmStructs.cpp Changeset: 430a95455271 Author: Doug Simon Date: 2013-11-19 01:38 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/430a95455271 removed deprecated mechanism for implementing -XX:+CITime in Graal - graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/bridge/MetricRateInPhase.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/bridge/VMToCompilerImpl.java Changeset: 6ae55c10796f Author: Doug Simon Date: 2013-11-19 01:39 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/6ae55c10796f Merge. Changeset: 92b7ec34ddfa Author: Gilles Duboscq Date: 2013-11-19 17:44 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/92b7ec34ddfa Add RandomAccess interface to NodeList ! graal/com.oracle.graal.graph/src/com/oracle/graal/graph/NodeList.java Changeset: 89fbf495e589 Author: Doug Simon Date: 2013-11-20 01:11 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/89fbf495e589 HSAIL: fix some assert logic in the argument-gathering code that shows up in non-product builds Contributed-by: Tom Deneau Summary: * computes parameter_count based on signature and uses that and parameter_index (set by the SignatureIterator) to tell if we are on the last parameter, which requires special handling whether it is an int or an object. * if signature says last parameter is an Object, checks that the real passed in parameter is an Object Array, but for non last-parameters, lets objects go thru. * if signature says last parameter is an int, nothing is pushed (no change to this logic) ! src/gpu/hsail/vm/hsailKernelArguments.cpp ! src/gpu/hsail/vm/hsailKernelArguments.hpp Changeset: 36bbe5bbe8fd Author: twisti Date: 2013-11-19 20:36 -0800 URL: http://hg.openjdk.java.net/graal/graal/rev/36bbe5bbe8fd use AccessController.doPrivileged to enqueue compilations and shutting down the compiler ! 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 Changeset: c13633a4d472 Author: Lukas Stadler Date: 2013-11-20 12:09 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/c13633a4d472 peephole optimization to remove null checks at the LIR level ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/alloc/LinearScan.java ! graal/com.oracle.graal.lir.amd64/src/com/oracle/graal/lir/amd64/AMD64Move.java ! graal/com.oracle.graal.lir.sparc/src/com/oracle/graal/lir/sparc/SPARCMove.java + graal/com.oracle.graal.lir/src/com/oracle/graal/lir/NullCheckOptimizer.java ! graal/com.oracle.graal.lir/src/com/oracle/graal/lir/StandardOp.java Changeset: 7e9c00c54866 Author: Doug Simon Date: 2013-11-20 12:52 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/7e9c00c54866 pass stack pointer register into monitorenter snippet instead of getting it from the host provider ! graal/com.oracle.graal.hotspot.amd64/src/com/oracle/graal/hotspot/amd64/AMD64HotSpotBackendFactory.java ! graal/com.oracle.graal.hotspot.amd64/src/com/oracle/graal/hotspot/amd64/AMD64HotSpotLoweringProvider.java ! graal/com.oracle.graal.hotspot.sparc/src/com/oracle/graal/hotspot/sparc/SPARCHotSpotBackendFactory.java ! graal/com.oracle.graal.hotspot.sparc/src/com/oracle/graal/hotspot/sparc/SPARCHotSpotLoweringProvider.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotHostLoweringProvider.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/MonitorSnippets.java Changeset: 9b62c748c9ae Author: Doug Simon Date: 2013-11-20 12:54 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/9b62c748c9ae get thread register from generator when lowering CurrentJavaThreadNode node instead of getting it from the host provider ! graal/com.oracle.graal.hotspot.amd64/src/com/oracle/graal/hotspot/amd64/AMD64HotSpotLIRGenerator.java ! graal/com.oracle.graal.hotspot.sparc/src/com/oracle/graal/hotspot/sparc/SPARCHotSpotLIRGenerator.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/HotSpotLIRGenerator.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/nodes/CurrentJavaThreadNode.java Changeset: 100d20e8d460 Author: Doug Simon Date: 2013-11-20 13:12 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/100d20e8d460 pass thread register into monitorenter snippet instead of getting it from the host provider ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotHostLoweringProvider.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/MonitorSnippets.java Changeset: e3d1e4f635e9 Author: Doug Simon Date: 2013-11-20 13:28 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/e3d1e4f635e9 pass thread register into allocation snippets instead of getting it from the host provider ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotHostLoweringProvider.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/NewObjectSnippets.java Changeset: 9b0ab9e2fd6b Author: Doug Simon Date: 2013-11-20 13:33 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/9b0ab9e2fd6b pass thread register into LoadExceptionObjectSnippet instead of getting it from the host provider ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotHostLoweringProvider.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/LoadExceptionObjectSnippets.java Changeset: 1cc0a907e1dd Author: Doug Simon Date: 2013-11-20 13:57 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/1cc0a907e1dd pass thread register into write barrier snippets instead of getting it from the host provider ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotHostLoweringProvider.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/WriteBarrierSnippets.java Changeset: be9c3426daad Author: Doug Simon Date: 2013-11-20 13:58 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/be9c3426daad pass thread register into allocation stubs instead of getting it from the host provider ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/HotSpotReplacementsUtil.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/stubs/NewArrayStub.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/stubs/NewInstanceStub.java Changeset: af7fb87fc62e Author: Doug Simon Date: 2013-11-20 14:45 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/af7fb87fc62e pass thread register into all stubs instead of getting it from the host provider ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/HotSpotReplacementsUtil.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/stubs/ExceptionHandlerStub.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/stubs/ForeignCallStub.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/stubs/NewArrayStub.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/stubs/NewInstanceStub.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/stubs/SnippetStub.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/stubs/StubUtil.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/stubs/UnwindExceptionToCallerStub.java ! graal/com.oracle.graal.replacements/src/com/oracle/graal/replacements/nodes/ReadRegisterNode.java Changeset: f8aef2693731 Author: Doug Simon Date: 2013-11-20 14:49 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/f8aef2693731 use local registers object instead of global one ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotHostLoweringProvider.java Changeset: d6b4f61ff643 Author: Doug Simon Date: 2013-11-20 14:49 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/d6b4f61ff643 Merge. Changeset: 68ff7abbfae5 Author: Doug Simon Date: 2013-11-20 15:31 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/68ff7abbfae5 renamed HotSpotHostLoweringProvider to HotSpotLoweringProvider ! graal/com.oracle.graal.hotspot.amd64/src/com/oracle/graal/hotspot/amd64/AMD64HotSpotBackendFactory.java ! graal/com.oracle.graal.hotspot.amd64/src/com/oracle/graal/hotspot/amd64/AMD64HotSpotLoweringProvider.java ! graal/com.oracle.graal.hotspot.sparc/src/com/oracle/graal/hotspot/sparc/SPARCHotSpotLoweringProvider.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/HotSpotHostBackend.java - graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotHostLoweringProvider.java + graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotLoweringProvider.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/NewObjectSnippets.java Changeset: 5341a7fca039 Author: Doug Simon Date: 2013-11-20 15:31 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/5341a7fca039 made HSAIL reuse HotSpotLoweringProvider, just with a different set of registers ! graal/com.oracle.graal.hotspot.hsail/src/com/oracle/graal/hotspot/hsail/HSAILHotSpotBackend.java ! graal/com.oracle.graal.hotspot.hsail/src/com/oracle/graal/hotspot/hsail/HSAILHotSpotBackendFactory.java ! graal/com.oracle.graal.hotspot.hsail/src/com/oracle/graal/hotspot/hsail/HSAILHotSpotLoweringProvider.java ! graal/com.oracle.graal.hotspot.hsail/src/com/oracle/graal/hotspot/hsail/HSAILHotSpotReplacementsImpl.java From Vasanth.Venkatachalam at amd.com Wed Nov 20 11:08:51 2013 From: Vasanth.Venkatachalam at amd.com (Venkatachalam, Vasanth) Date: Wed, 20 Nov 2013 19:08:51 +0000 Subject: webrev for switch statement support in HSAIL backend In-Reply-To: <528C00C6.3000202@oracle.com> References: <5DD1503F815BD14889DC81D28643E3A75788AB08@SATLEXDAG02.amd.com> <528C00C6.3000202@oracle.com> Message-ID: <5DD1503F815BD14889DC81D28643E3A75788BC85@SATLEXDAG02.amd.com> Doug, Answers inlined below. If there are no other changes required please commit the webrev, citing Vasanth Venkatachalam as the author, with the commit message: "Adds support to the HSAIL backend for handling Java switch constructs . Vasanth -----Original Message----- From: graal-dev-bounces at openjdk.java.net [mailto:graal-dev-bounces at openjdk.java.net] On Behalf Of Doug Simon Sent: Tuesday, November 19, 2013 6:23 PM To: graal-dev at openjdk.java.net Subject: Re: webrev for switch statement support in HSAIL backend graal/com.oracle.graal.asm.hsail/src/com/oracle/graal/asm/hsail/HSAILAssembler.java: + // Get a JNI reference handle to the object. + long refHandle = OkraUtil.getRefHandle(obj); How does OkraUtil manage these handles? I hope it at least never creates more than one global JNI ref for any given object or has some way to release them when no longer needed. >[Vasanth] OkraUtil never creates more than one JNI ref for any given object. This change isn't introducing anything new. This code has been in the assembler all along, we just extended it to remove the restriction that the Object passed as parameter to mov(Register reg, Object obj) must be an instance of Class. graal/com.oracle.graal.lir.hsail/src/com/oracle/graal/lir/hsail/HSAILControlFlow.java: + // The array of key constants used for the cases of this switch statement. + @Use({CONST}) protected Constant[] keyConstants; + // The branch target labels that correspond to each case. + private final LabelRef[] keyTargets; + private LabelRef defaultTarget; + // The key of the switch. This will be compared with each of the keyConstants. + @Alive({REG}) protected Value key; + + // Constructor. Called from the HSAILLIRGenerator.emitSequentialSwitch routine. + public SwitchOp(Constant[] keyConstants, LabelRef[] keyTargets, LabelRef defaultTarget, Value key) { Java fields and methods should have javadoc comments instead of C++ style comments. >>[Vasanth] This was my oversight. I've updated the latest version of the webrev to use Javadoc comments. -Doug On 11/20/2013 12:25 AM, Venkatachalam, Vasanth wrote: > Hi, > > I've submitted a webrev for handling switch constructs generated by Java bytecode. > > Please review at http://cr.openjdk.java.net/~tdeneau/webrev-switchsupport.00/webrev/ > > Notes: > > This webrev adds support for the IntegerSwitchNode. (Support for TypeSwitchNode may be added later.) > > The approach currently recommended for generating performant HSAIL code for Java switch statements is to generate a series of cascading compare and branch instructions (instead of doing a table switch).This is the approach that I have implemented here. > > I've added an additional enhancement to HSAILAssembler which is unrelated to the switch support. > The routine mov(Register reg, Object obj) previously had a restriction that the Object parameter had to be an instance of Class. This restriction has been lifted. > > I ran this through the Eclipse 4.3 formatter and there weren't any file changes. > > Vasanth > > From tom.deneau at amd.com Wed Nov 20 12:17:39 2013 From: tom.deneau at amd.com (Deneau, Tom) Date: Wed, 20 Nov 2013 20:17:39 +0000 Subject: question about bci in LIRFrameState for DeoptimizeOp Message-ID: I was looking at the AMD64DeoptimizeOp.emitCode routine which is AMD64Call.directCall(tasm, masm, tasm.foreignCalls.lookupForeignCall(UNCOMMON_TRAP), null, false, info); When I look at the LIRFrameState info which is passed to UNCOMMON_TRAP, the bci always seems to be 0. Why is that? For example, compiling this small snippet thru AMD64 backend public int intFromArray(int[] ary, int idx) { return ary[idx]; } with bytecodes public int intFromArray(int[], int); Code: 0: aload_1 1: iload_2 2: iaload 3: ireturn when I get to AMD64DeoptimizeOp.emitCode, I see info = "at com.oracle.graal.compiler.test.BasicTest2.intFromArray(BasicTest2.java:46) [bci: 0] |0 |1 |2 locals: |- |v0|a |v1|i " I would have expected the bci in this case to be 2, referring to the iaload instruction. -- Tom From thomas.wuerthinger at oracle.com Wed Nov 20 12:39:42 2013 From: thomas.wuerthinger at oracle.com (Thomas Wuerthinger) Date: Wed, 20 Nov 2013 21:39:42 +0100 Subject: question about bci in LIRFrameState for DeoptimizeOp In-Reply-To: References: Message-ID: <721F36C5-C300-46A6-B0D8-4153313F57C8@oracle.com> Graal understands that it can safely replay bytecodes without side effects. Therefore the target bci of a deoptimization will reflect the last side effecting instruction (or the beginning of the method if no such instruction exists). Gilles wrote a paper describing in more details how deoptimization works in Graal and we will publish it shortly as part of the Graal documentation. - thomas On 20 Nov 2013, at 21:17, Deneau, Tom wrote: > I was looking at the AMD64DeoptimizeOp.emitCode routine which is > AMD64Call.directCall(tasm, masm, tasm.foreignCalls.lookupForeignCall(UNCOMMON_TRAP), null, false, info); > > When I look at the LIRFrameState info which is passed to UNCOMMON_TRAP, the bci always seems to be 0. > Why is that? > > For example, compiling this small snippet thru AMD64 backend > public int intFromArray(int[] ary, int idx) { > return ary[idx]; > } > > with bytecodes > public int intFromArray(int[], int); > Code: > 0: aload_1 > 1: iload_2 > 2: iaload > 3: ireturn > > when I get to AMD64DeoptimizeOp.emitCode, I see > info = "at com.oracle.graal.compiler.test.BasicTest2.intFromArray(BasicTest2.java:46) [bci: 0] > |0 |1 |2 > locals: |- |v0|a |v1|i " > > I would have expected the bci in this case to be 2, referring to the iaload instruction. > > -- Tom > > From tom.deneau at amd.com Wed Nov 20 13:08:38 2013 From: tom.deneau at amd.com (Deneau, Tom) Date: Wed, 20 Nov 2013 21:08:38 +0000 Subject: question about bci in LIRFrameState for DeoptimizeOp In-Reply-To: <721F36C5-C300-46A6-B0D8-4153313F57C8@oracle.com> References: <721F36C5-C300-46A6-B0D8-4153313F57C8@oracle.com> Message-ID: Thomas -- I retried this experiment with a java snippet that I thought would have a side effect, incrementing a field public int intFromArrayLonger(int[] ary, int idx) { dummyField++; return ary[idx]; } But I still saw a info.bci of 0. -- Tom D -----Original Message----- From: Thomas Wuerthinger [mailto:thomas.wuerthinger at oracle.com] Sent: Wednesday, November 20, 2013 2:40 PM To: Deneau, Tom Cc: graal-dev at openjdk.java.net Subject: Re: question about bci in LIRFrameState for DeoptimizeOp Graal understands that it can safely replay bytecodes without side effects. Therefore the target bci of a deoptimization will reflect the last side effecting instruction (or the beginning of the method if no such instruction exists). Gilles wrote a paper describing in more details how deoptimization works in Graal and we will publish it shortly as part of the Graal documentation. - thomas On 20 Nov 2013, at 21:17, Deneau, Tom wrote: > I was looking at the AMD64DeoptimizeOp.emitCode routine which is > AMD64Call.directCall(tasm, masm, > tasm.foreignCalls.lookupForeignCall(UNCOMMON_TRAP), null, false, > info); > > When I look at the LIRFrameState info which is passed to UNCOMMON_TRAP, the bci always seems to be 0. > Why is that? > > For example, compiling this small snippet thru AMD64 backend > public int intFromArray(int[] ary, int idx) { > return ary[idx]; > } > > with bytecodes > public int intFromArray(int[], int); > Code: > 0: aload_1 > 1: iload_2 > 2: iaload > 3: ireturn > > when I get to AMD64DeoptimizeOp.emitCode, I see info = "at > com.oracle.graal.compiler.test.BasicTest2.intFromArray(BasicTest2.java:46) [bci: 0] > |0 |1 |2 > locals: |- |v0|a |v1|i " > > I would have expected the bci in this case to be 2, referring to the iaload instruction. > > -- Tom > > From tom.deneau at amd.com Wed Nov 20 13:13:00 2013 From: tom.deneau at amd.com (Deneau, Tom) Date: Wed, 20 Nov 2013 21:13:00 +0000 Subject: question about bci in LIRFrameState for DeoptimizeOp In-Reply-To: <721F36C5-C300-46A6-B0D8-4153313F57C8@oracle.com> References: <721F36C5-C300-46A6-B0D8-4153313F57C8@oracle.com> Message-ID: Also, if a draft of Gilles' paper is available for review, that would be great. -- Tom -----Original Message----- From: Thomas Wuerthinger [mailto:thomas.wuerthinger at oracle.com] Sent: Wednesday, November 20, 2013 2:40 PM To: Deneau, Tom Cc: graal-dev at openjdk.java.net Subject: Re: question about bci in LIRFrameState for DeoptimizeOp Graal understands that it can safely replay bytecodes without side effects. Therefore the target bci of a deoptimization will reflect the last side effecting instruction (or the beginning of the method if no such instruction exists). Gilles wrote a paper describing in more details how deoptimization works in Graal and we will publish it shortly as part of the Graal documentation. - thomas On 20 Nov 2013, at 21:17, Deneau, Tom wrote: > I was looking at the AMD64DeoptimizeOp.emitCode routine which is > AMD64Call.directCall(tasm, masm, > tasm.foreignCalls.lookupForeignCall(UNCOMMON_TRAP), null, false, > info); > > When I look at the LIRFrameState info which is passed to UNCOMMON_TRAP, the bci always seems to be 0. > Why is that? > > For example, compiling this small snippet thru AMD64 backend > public int intFromArray(int[] ary, int idx) { > return ary[idx]; > } > > with bytecodes > public int intFromArray(int[], int); > Code: > 0: aload_1 > 1: iload_2 > 2: iaload > 3: ireturn > > when I get to AMD64DeoptimizeOp.emitCode, I see info = "at > com.oracle.graal.compiler.test.BasicTest2.intFromArray(BasicTest2.java:46) [bci: 0] > |0 |1 |2 > locals: |- |v0|a |v1|i " > > I would have expected the bci in this case to be 2, referring to the iaload instruction. > > -- Tom > > From thomas.wuerthinger at oracle.com Wed Nov 20 13:15:38 2013 From: thomas.wuerthinger at oracle.com (Thomas Wuerthinger) Date: Wed, 20 Nov 2013 22:15:38 +0100 Subject: question about bci in LIRFrameState for DeoptimizeOp In-Reply-To: References: <721F36C5-C300-46A6-B0D8-4153313F57C8@oracle.com> Message-ID: I think the guards for the array access might have been moved before the field store. Can you check in the machine code whether the deoptimization is indeed *after* the field store? - thomas On 20 Nov 2013, at 22:08, Deneau, Tom wrote: > Thomas -- > > I retried this experiment with a java snippet that I thought would have a side effect, incrementing a field > public int intFromArrayLonger(int[] ary, int idx) { > dummyField++; > return ary[idx]; > } > > But I still saw a info.bci of 0. > > -- Tom D > > > > -----Original Message----- > From: Thomas Wuerthinger [mailto:thomas.wuerthinger at oracle.com] > Sent: Wednesday, November 20, 2013 2:40 PM > To: Deneau, Tom > Cc: graal-dev at openjdk.java.net > Subject: Re: question about bci in LIRFrameState for DeoptimizeOp > > Graal understands that it can safely replay bytecodes without side effects. Therefore the target bci of a deoptimization will reflect the last side effecting instruction (or the beginning of the method if no such instruction exists). Gilles wrote a paper describing in more details how deoptimization works in Graal and we will publish it shortly as part of the Graal documentation. - thomas > > On 20 Nov 2013, at 21:17, Deneau, Tom wrote: > >> I was looking at the AMD64DeoptimizeOp.emitCode routine which is >> AMD64Call.directCall(tasm, masm, >> tasm.foreignCalls.lookupForeignCall(UNCOMMON_TRAP), null, false, >> info); >> >> When I look at the LIRFrameState info which is passed to UNCOMMON_TRAP, the bci always seems to be 0. >> Why is that? >> >> For example, compiling this small snippet thru AMD64 backend >> public int intFromArray(int[] ary, int idx) { >> return ary[idx]; >> } >> >> with bytecodes >> public int intFromArray(int[], int); >> Code: >> 0: aload_1 >> 1: iload_2 >> 2: iaload >> 3: ireturn >> >> when I get to AMD64DeoptimizeOp.emitCode, I see info = "at >> com.oracle.graal.compiler.test.BasicTest2.intFromArray(BasicTest2.java:46) [bci: 0] >> |0 |1 |2 >> locals: |- |v0|a |v1|i " >> >> I would have expected the bci in this case to be 2, referring to the iaload instruction. >> >> -- Tom >> >> > > > From doug.simon at oracle.com Wed Nov 20 12:27:41 2013 From: doug.simon at oracle.com (doug.simon at oracle.com) Date: Wed, 20 Nov 2013 20:27:41 +0000 Subject: hg: graal/graal: 292 new changesets Message-ID: <20131120203744.EA2FA6271B@hg.openjdk.java.net> Changeset: 02d171a3b5d1 Author: cl Date: 2013-10-10 10:08 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/02d171a3b5d1 Added tag jdk8-b111 for changeset f6962730bbde ! .hgtags Changeset: deec468baebd Author: amurillo Date: 2013-10-04 14:19 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/deec468baebd 8025859: new hotspot build - hs25-b54 Reviewed-by: jcoomes ! make/hotspot_version Changeset: 5b3b75d9eb2f Author: coleenp Date: 2013-10-01 14:23 -0400 URL: http://hg.openjdk.java.net/graal/graal/rev/5b3b75d9eb2f 8025570: Naked oop in test/serviceability/ParserTest Summary: Fix for two naked objArrayOop(s) oops causing test failure Reviewed-by: coleenp, ctornqvi Contributed-by: lois.foltan at oracle.com ! src/share/vm/prims/wbtestmethods/parserTests.cpp Changeset: f21415c32ca1 Author: coleenp Date: 2013-10-01 15:41 -0400 URL: http://hg.openjdk.java.net/graal/graal/rev/f21415c32ca1 Merge Changeset: d574419c5372 Author: mseledtsov Date: 2013-10-02 15:17 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/d574419c5372 8025671: Test name changed, test list not updated. Test6878713.sh Summary: Removed the obsolete test from the test group file Reviewed-by: sla, ctornqvi, dholmes ! test/TEST.groups Changeset: 931f105563c5 Author: coleenp Date: 2013-10-02 13:02 -0400 URL: http://hg.openjdk.java.net/graal/graal/rev/931f105563c5 8025569: -XX:+CheckUnhandledOops crashes on Windows Summary: Disable CHECK_UNHANDLED_OOPS in fastdebug builds for JDK 8 on WIndows 32 & 64 bit machines Reviewed-by: coleenp, ctornqvi, zgu Contributed-by: lois.foltan at oracle.com ! make/windows/makefiles/fastdebug.make Changeset: 6f73bc5df986 Author: coleenp Date: 2013-10-02 15:06 -0400 URL: http://hg.openjdk.java.net/graal/graal/rev/6f73bc5df986 Merge Changeset: 2bd38d594b9a Author: dsamersoff Date: 2013-10-02 20:58 +0400 URL: http://hg.openjdk.java.net/graal/graal/rev/2bd38d594b9a 8025283: Nits in os_bsd file breaks compilation of open hotspot Summary: Couple of nits in os_bsd.cpp brake compilation of open hotspot on non-apple platforms Reviewed-by: sla, sspitsyn ! src/os/bsd/vm/os_bsd.cpp Changeset: 9855f17334d8 Author: dsamersoff Date: 2013-10-03 01:12 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/9855f17334d8 Merge Changeset: 5705c7ee6dd7 Author: dsamersoff Date: 2013-10-02 22:27 +0400 URL: http://hg.openjdk.java.net/graal/graal/rev/5705c7ee6dd7 8025250: SA: Sync linux and bsd versions of ps_core file Summary: linux/ps_core.c and bsd/ps_core.c share most of code, but it has different formatting, comments etc. Reviewed-by: sla, minqi ! agent/src/os/bsd/ps_core.c ! agent/src/os/linux/ps_core.c Changeset: 7ae82c3a781a Author: dsamersoff Date: 2013-10-03 04:42 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/7ae82c3a781a Merge Changeset: faff125a1ead Author: dsamersoff Date: 2013-10-03 12:39 +0400 URL: http://hg.openjdk.java.net/graal/graal/rev/faff125a1ead 8022616: u4 should not be used as a type for thread_id Summary: Usage of u4 as a type for thread_id cause a compilation error on platform, where thread_id is a pointer Reviewed-by: sla, sspitsyn, minqi ! src/os/bsd/vm/osThread_bsd.hpp ! src/os/bsd/vm/os_bsd.cpp ! src/os/bsd/vm/os_bsd.hpp Changeset: 07f8c2a453f8 Author: coleenp Date: 2013-10-03 18:53 -0400 URL: http://hg.openjdk.java.net/graal/graal/rev/07f8c2a453f8 8025238: nsk/jvmti/scenarios/bcinstr/BI04/bi04t002 crashed with SIGSEGV Summary: Redefined class in stack trace may not be found by method_idnum so handle null. Reviewed-by: sla, dcubed, sspitsyn ! src/share/vm/classfile/javaClasses.cpp ! src/share/vm/prims/jvmtiRedefineClasses.cpp Changeset: 3374b92de2d9 Author: coleenp Date: 2013-10-03 18:50 -0400 URL: http://hg.openjdk.java.net/graal/graal/rev/3374b92de2d9 8025004: -XX:+CheckUnhandledOops asserts for JDK 8 Solaris fastdebug binaries Summary: Remove unnecessary volatile keyword on stack locals within instanceKlass.cpp to work around Solaris Studio C++ compiler issue Reviewed-by: coleenp, dcubed Contributed-by: lois.foltan at oracle.com ! src/share/vm/oops/instanceKlass.cpp ! src/share/vm/oops/instanceKlass.hpp Changeset: 3bf767171ea4 Author: coleenp Date: 2013-10-05 00:53 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/3bf767171ea4 Merge Changeset: 675ffabf3798 Author: mikael Date: 2013-10-02 09:18 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/675ffabf3798 8024087: Remove dead JVM_{Get,Set}PrimitiveFieldValues functions Summary: The two functions were used to support JDK 1.3 but are no longer in use Reviewed-by: coleenp, ctornqvi, twisti, dsamersoff ! src/share/vm/prims/jvm.cpp ! src/share/vm/prims/jvm_misc.hpp ! src/share/vm/prims/nativeLookup.cpp Changeset: a1fd44b003c7 Author: coleenp Date: 2013-10-05 00:58 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/a1fd44b003c7 Merge Changeset: 4212bfb33d76 Author: coleenp Date: 2013-10-05 03:14 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/4212bfb33d76 Merge Changeset: 2720ab7a0d70 Author: ccheung Date: 2013-10-04 21:00 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/2720ab7a0d70 Merge ! src/share/vm/prims/jvm.cpp Changeset: febab3a8f203 Author: erikj Date: 2013-10-04 12:45 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/febab3a8f203 8007446: Add /MP to cl.exe speeds up windows builds of OpenJDK. Reviewed-by: sla, ctornqvi ! make/windows/makefiles/compile.make ! make/windows/makefiles/sa.make Changeset: 763705f0fec3 Author: sla Date: 2013-10-04 13:01 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/763705f0fec3 8016845: SA is unable to use hsdis on windows Summary: Added sadis.c to the build to provide missing symbols in sawindbg.dll. Added code to use the correct hsdisXXX.dll filename on different windows platforms. Reviewed-by: sla, mgerdin Contributed-by: fredrik.arvidsson at oracle.com ! agent/src/share/classes/sun/jvm/hotspot/asm/Disassembler.java ! make/windows/makefiles/sa.make Changeset: f9be370a7d54 Author: sla Date: 2013-10-05 15:18 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/f9be370a7d54 8025922: JNI access to Strings need to check if the value field is non-null Reviewed-by: dholmes, dcubed ! src/share/vm/prims/jni.cpp ! src/share/vm/prims/jniCheck.cpp Changeset: 8ef918538e22 Author: sla Date: 2013-10-04 13:44 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/8ef918538e22 6313383: SA: Update jmap to support HPROF binary format "JAVA PROFILE 1.0.2" Summary: Adds support for large(>4G) heap dumps in hprof format. Adds tests and updates testlibrary. Reviewed-by: sla, allwin Contributed-by: fredrik.arvidsson at oracle.com ! agent/src/share/classes/sun/jvm/hotspot/utilities/AbstractHeapGraphWriter.java ! agent/src/share/classes/sun/jvm/hotspot/utilities/HeapHprofBinWriter.java ! test/TEST.groups + test/serviceability/sa/jmap-hprof/JMapHProfLargeHeapProc.java + test/serviceability/sa/jmap-hprof/JMapHProfLargeHeapTest.java ! test/testlibrary/com/oracle/java/testlibrary/JDKToolLauncher.java Changeset: 9c63ad02c0a4 Author: sla Date: 2013-10-05 10:56 -0400 URL: http://hg.openjdk.java.net/graal/graal/rev/9c63ad02c0a4 Merge Changeset: cc4f5f8d885e Author: mseledtsov Date: 2013-10-06 16:13 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/cc4f5f8d885e 8023796: [TESTBUG] Add -XX:-TransmitErrorReport to runtime/6888954/vmerrors.sh Summary: added -XX:-TransmitErrorReport to the test Reviewed-by: stefank, ctornqvi ! test/runtime/6888954/vmerrors.sh ! test/runtime/memory/ReserveMemory.java Changeset: ac9cb1d5a202 Author: acorn Date: 2013-10-07 12:20 -0400 URL: http://hg.openjdk.java.net/graal/graal/rev/ac9cb1d5a202 8009130: Lambda: Fix access controls, loader constraints. Summary: New default methods list with inherited superinterface methods Reviewed-by: minqi, sspitsyn, coleenp ! src/share/vm/classfile/classFileParser.cpp ! src/share/vm/classfile/defaultMethods.cpp ! src/share/vm/code/dependencies.cpp ! src/share/vm/interpreter/linkResolver.cpp ! src/share/vm/interpreter/linkResolver.hpp ! src/share/vm/memory/heapInspection.hpp ! src/share/vm/oops/instanceKlass.cpp ! src/share/vm/oops/instanceKlass.hpp ! src/share/vm/oops/klassVtable.cpp ! src/share/vm/oops/klassVtable.hpp ! src/share/vm/oops/method.cpp ! src/share/vm/oops/method.hpp ! src/share/vm/prims/jni.cpp ! src/share/vm/prims/jvmtiRedefineClasses.cpp ! src/share/vm/prims/methodHandles.cpp ! src/share/vm/runtime/reflectionUtils.cpp ! src/share/vm/runtime/reflectionUtils.hpp ! src/share/vm/runtime/vmStructs.cpp Changeset: 615d83933195 Author: dholmes Date: 2013-10-08 02:56 -0400 URL: http://hg.openjdk.java.net/graal/graal/rev/615d83933195 8026025: JVM_GetCallerClass allows Reflection.getCallerClass(int depth) to use Reviewed-by: alanb, dholmes, twisti Contributed-by: mandy.chung at oracle.com ! src/share/vm/prims/jvm.cpp ! src/share/vm/prims/jvm.h Changeset: c90e76575b03 Author: kevinw Date: 2013-10-08 09:33 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/c90e76575b03 8019375: Internal symbol table size should be tunable. Reviewed-by: coleenp, kamg ! agent/src/share/classes/sun/jvm/hotspot/memory/SymbolTable.java ! src/share/vm/classfile/symbolTable.hpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/vmStructs.cpp ! src/share/vm/utilities/globalDefinitions.hpp Changeset: ced68a57cdbd Author: kevinw Date: 2013-10-08 11:37 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/ced68a57cdbd Merge Changeset: c72075c2883e Author: acorn Date: 2013-10-08 16:58 -0400 URL: http://hg.openjdk.java.net/graal/graal/rev/c72075c2883e 8026022: Verifier: allow anon classes to invokespecial host class/intf methods. Reviewed-by: coleenp, bharadwaj ! src/share/vm/classfile/verifier.cpp Changeset: d25557d03ec0 Author: acorn Date: 2013-10-09 17:57 -0400 URL: http://hg.openjdk.java.net/graal/graal/rev/d25557d03ec0 8026185: nsk/jvmit/GetMethodDeclaringClass/declcls001 failed Summary: Missed initialization. Thanks Coleen. Reviewed-by: coleenp, minqi ! src/share/vm/oops/instanceKlass.cpp Changeset: c01f4910f5f5 Author: ccheung Date: 2013-10-10 13:25 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/c01f4910f5f5 Merge Changeset: 9b4d0569f2f4 Author: jwilhelm Date: 2013-10-03 21:36 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/9b4d0569f2f4 8025852: Remove unnecessary setters in collector policy classes Summary: Use instance variables directly within the collector policy classes and remove unused setters. Reviewed-by: tschatzl, jcoomes ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.cpp ! src/share/vm/memory/collectorPolicy.cpp ! src/share/vm/memory/collectorPolicy.hpp Changeset: 087f02e22fc2 Author: jwilhelm Date: 2013-10-04 22:08 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/087f02e22fc2 8025854: Use "young gen" instead of "eden" Summary: Changed a few descriptions and variable names to young gen. Reviewed-by: tschatzl, jcoomes ! src/share/vm/memory/collectorPolicy.cpp ! src/share/vm/runtime/arguments.cpp Changeset: 263f2c796d6c Author: stefank Date: 2013-10-05 10:14 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/263f2c796d6c 8024838: Significant slowdown due to transparent huge pages Summary: Don't turn on transparent huge pages (-XX:+UseTransparentHugePages) unless explicitly specified on the command line. This has the effect that large pages are never turned on Linux unless the user has explicitly enabled any of the large pages flags: -XX:+UseLargePages, -XX:+UseTransparentHugePages, -XX:+UseHugeTLBFS, and -XX:+UseSHM. Reviewed-by: jwilhelm, tschatzl, brutisso ! src/os/linux/vm/globals_linux.hpp ! src/os/linux/vm/os_linux.cpp + test/runtime/memory/LargePages/TestLargePagesFlags.java Changeset: 8618e0d7735b Author: stefank Date: 2013-10-05 08:01 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/8618e0d7735b Merge Changeset: 04b18a42c2f3 Author: mgerdin Date: 2013-10-04 13:33 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/04b18a42c2f3 8025526: VirtualSpace should support per-instance disabling of large pages Summary: Add a new initialization function to VirtualSpace which allows the caller to override the max commit granularity. Reviewed-by: stefank, ehelin, tschatzl ! src/share/vm/runtime/virtualspace.cpp ! src/share/vm/runtime/virtualspace.hpp Changeset: 69944b868a32 Author: mgerdin Date: 2013-10-08 17:35 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/69944b868a32 8014555: G1: Memory ordering problem with Conc refinement and card marking Summary: Add a StoreLoad barrier in the G1 post-barrier to fix a race with concurrent refinement. Also-reviewed-by: martin.doerr at sap.com Reviewed-by: iveresov, tschatzl, brutisso, roland, kvn ! src/cpu/sparc/vm/c1_Runtime1_sparc.cpp ! src/cpu/sparc/vm/macroAssembler_sparc.cpp ! src/cpu/x86/vm/c1_Runtime1_x86.cpp ! src/cpu/x86/vm/macroAssembler_x86.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.inline.hpp ! src/share/vm/gc_implementation/g1/g1SATBCardTableModRefBS.cpp ! src/share/vm/gc_implementation/g1/g1SATBCardTableModRefBS.hpp ! src/share/vm/gc_implementation/g1/ptrQueue.hpp ! src/share/vm/opto/graphKit.cpp Changeset: b4d8a3d4db73 Author: tamao Date: 2013-10-09 11:18 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/b4d8a3d4db73 8010506: Typos and errors in descriptions of vm options in globals.hpp Summary: Fix typos and errors in descriptions of vm options in globals.hpp Reviewed-by: jmasa, jwilhelm ! src/share/vm/runtime/globals.hpp Changeset: 82af7d7a0128 Author: tschatzl Date: 2013-10-09 10:57 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/82af7d7a0128 8003420: NPG: make new GC root for pd_set Summary: Move protection domain oops from system dictionary entries into a seperate set; the system dictionary references entries in that set now. This allows fast iteration during non-classunloading garbage collection. Implementation based on initial prototype from Ioi Lam (iklam). Reviewed-by: coleenp, iklam + agent/src/share/classes/sun/jvm/hotspot/memory/ProtectionDomainCacheEntry.java ! agent/src/share/classes/sun/jvm/hotspot/memory/ProtectionDomainEntry.java ! src/share/vm/classfile/dictionary.cpp ! src/share/vm/classfile/dictionary.hpp ! src/share/vm/classfile/systemDictionary.cpp ! src/share/vm/runtime/vmStructs.cpp ! src/share/vm/utilities/globalDefinitions.hpp Changeset: 85c1ca43713f Author: stefank Date: 2013-10-07 15:51 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/85c1ca43713f 8024547: MaxMetaspaceSize should limit the committed memory used by the metaspaces Reviewed-by: brutisso, jmasa, coleenp ! src/share/vm/gc_implementation/shared/vmGCOperations.hpp ! src/share/vm/gc_interface/collectedHeap.cpp ! src/share/vm/gc_interface/collectedHeap.hpp ! src/share/vm/memory/collectorPolicy.cpp ! src/share/vm/memory/filemap.hpp ! src/share/vm/memory/metaspace.cpp ! src/share/vm/memory/metaspace.hpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/globals.hpp Changeset: a6414751d537 Author: stefank Date: 2013-10-07 15:51 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/a6414751d537 8025996: Track metaspace usage when metaspace is expanded Reviewed-by: coleenp, ehelin ! src/share/vm/memory/metaspace.cpp ! src/share/vm/services/memoryService.hpp Changeset: aa6f2ea19d8f Author: jcoomes Date: 2013-10-11 08:27 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/aa6f2ea19d8f Merge ! src/os/linux/vm/os_linux.cpp ! src/share/vm/classfile/dictionary.cpp ! src/share/vm/classfile/dictionary.hpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1SATBCardTableModRefBS.cpp ! src/share/vm/opto/graphKit.cpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/vmStructs.cpp ! src/share/vm/utilities/globalDefinitions.hpp Changeset: 4a845c7a4638 Author: amurillo Date: 2013-10-11 13:00 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/4a845c7a4638 Merge Changeset: 0ed9a90f45e1 Author: amurillo Date: 2013-10-11 13:00 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/0ed9a90f45e1 Added tag hs25-b54 for changeset 4a845c7a4638 ! .hgtags Changeset: aeae561a6d0b Author: cl Date: 2013-10-17 09:40 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/aeae561a6d0b Added tag jdk8-b112 for changeset 0ed9a90f45e1 ! .hgtags Changeset: 7c26dced065e Author: amurillo Date: 2013-10-11 13:14 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/7c26dced065e 8026265: new hotspot build - hs25-b55 Reviewed-by: jcoomes ! make/hotspot_version Changeset: b4a4fdc1f464 Author: coleenp Date: 2013-10-09 21:45 -0400 URL: http://hg.openjdk.java.net/graal/graal/rev/b4a4fdc1f464 8025185: MethodHandleInError and MethodTypeInError not handled in ConstantPool::compare_entry_to and copy_entry_to Summary: Add missing cases. Reviewed-by: sspitsyn, dcubed ! src/share/vm/oops/constantPool.cpp Changeset: e831448418ac Author: coleenp Date: 2013-10-09 22:01 -0400 URL: http://hg.openjdk.java.net/graal/graal/rev/e831448418ac Merge Changeset: cd7ea1d79dac Author: sla Date: 2013-10-11 13:48 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/cd7ea1d79dac 8026199: serviceability/sa/jmap-hprof/JMapHProfLargeHeapTest.java Compilation failed Summary: Fixed a compilation failure due to changed method name Reviewed-by: sla, jbachorik Contributed-by: fredrik.arvidsson at oracle.com ! test/serviceability/sa/jmap-hprof/JMapHProfLargeHeapTest.java ! test/testlibrary/com/oracle/java/testlibrary/JDKToolLauncher.java Changeset: 539144972c1e Author: sla Date: 2013-10-11 14:08 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/539144972c1e 8024425: VM_HeapDumper doesn't put anonymous classes in the heap dump Summary: Switched from using SystemDictionary to using ClassLoaderDataGraph to get the anonymous classes included. Reviewed-by: sla, sspitsyn Contributed-by: fredrik.arvidsson at oracle.com ! src/share/vm/services/heapDumper.cpp Changeset: 301ece1880ad Author: sla Date: 2013-10-11 14:57 +0000 URL: http://hg.openjdk.java.net/graal/graal/rev/301ece1880ad Merge Changeset: 28ca974cc21a Author: coleenp Date: 2013-10-11 11:23 -0400 URL: http://hg.openjdk.java.net/graal/graal/rev/28ca974cc21a 8022592: assert at constantTag.cpp:57: ShouldNotReachHere() Summary: more missing cases for JVM_CONSTANT_Method{Handle,Type}InError Reviewed-by: hseigel, dcubed ! src/share/vm/oops/constantPool.cpp ! src/share/vm/utilities/constantTag.cpp ! src/share/vm/utilities/constantTag.hpp Changeset: 26ae62bc26c4 Author: coleenp Date: 2013-10-11 15:04 -0400 URL: http://hg.openjdk.java.net/graal/graal/rev/26ae62bc26c4 Merge Changeset: 0db3ba3f6870 Author: hseigel Date: 2013-10-11 15:33 -0400 URL: http://hg.openjdk.java.net/graal/graal/rev/0db3ba3f6870 8026041: JVM crashes with assert "assert(is_updated()) failed: must not be clear" with -XX:+PrintGCApplicationConcurrentTime in -Xcomp mode Summary: Prior to printing the time interval in RuntimeService::record_safepoint_begin(), check first that VM initialization is complete. Reviewed-by: coleenp, dholmes, sla, ctornqvi Contributed-by: lois.foltan at oracle.com ! src/share/vm/services/runtimeService.cpp Changeset: df268195b0ea Author: hseigel Date: 2013-10-11 17:08 -0400 URL: http://hg.openjdk.java.net/graal/graal/rev/df268195b0ea Merge Changeset: 41459da469ae Author: ccheung Date: 2013-10-11 18:23 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/41459da469ae Merge Changeset: 83dbf427fedd Author: ccheung Date: 2013-10-11 22:22 -0400 URL: http://hg.openjdk.java.net/graal/graal/rev/83dbf427fedd Merge Changeset: 3e265ce4d2dd Author: hseigel Date: 2013-10-12 13:09 -0400 URL: http://hg.openjdk.java.net/graal/graal/rev/3e265ce4d2dd 8025942: os::Bsd::available_memory() needs implementation Summary: Implement using the host_statistics64() api. Reviewed-by: dsamersoff, morris, dholmes, coleenp, hseigel, dcubed Contributed-by: gerard.ziemski at oracle.com ! src/os/bsd/vm/os_bsd.cpp Changeset: d37a0525c0fe Author: hseigel Date: 2013-10-12 15:39 -0400 URL: http://hg.openjdk.java.net/graal/graal/rev/d37a0525c0fe 8024667: VM crashes with "assert(method() != NULL) failed: must have set method" Summary: Check if data is in shared spaces before deallocating it. Reviewed-by: coleenp, dcubed ! src/share/vm/memory/metadataFactory.hpp ! src/share/vm/oops/instanceKlass.cpp Changeset: 2f8728d92483 Author: acorn Date: 2013-10-14 21:52 -0400 URL: http://hg.openjdk.java.net/graal/graal/rev/2f8728d92483 8026299: invokespecial gets ICCE when it should get AME. Reviewed-by: ccheung, coleenp ! src/share/vm/interpreter/linkResolver.cpp ! src/share/vm/interpreter/linkResolver.hpp Changeset: f509b8f4699b Author: dcubed Date: 2013-10-15 08:25 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/f509b8f4699b 7165611: implement Full Debug Symbols on MacOS X hotspot Summary: Add MacOS X FDS support to hotspot; add minimal MacOS X FDS import support to jdk; add MacOS X FDS support to install; add MacOS X FDS support to root. Reviewed-by: erikj, sla, dholmes, rdurbin, tbell, ihse ! make/Makefile ! make/bsd/Makefile ! make/bsd/makefiles/buildtree.make ! make/bsd/makefiles/defs.make ! make/bsd/makefiles/dtrace.make ! make/bsd/makefiles/gcc.make ! make/bsd/makefiles/jsig.make ! make/bsd/makefiles/product.make ! make/bsd/makefiles/saproc.make ! make/bsd/makefiles/universal.gmk ! make/bsd/makefiles/vm.make ! make/defs.make Changeset: e8703d708e6e Author: ccheung Date: 2013-10-16 11:48 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/e8703d708e6e Merge Changeset: 1e814e391ee8 Author: anoll Date: 2013-10-04 09:19 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/1e814e391ee8 8025656: compiler/8013496/Test8013496.sh fails on assert Summary: Ensure the thread is in correct state; rewrote test in Java Reviewed-by: kvn, twisti ! src/share/vm/compiler/compileBroker.cpp - test/compiler/8013496/Test8013496.sh + test/compiler/codecache/CheckReservedInitialCodeCacheSizeArgOrder.java Changeset: 0c4c40f5c399 Author: twisti Date: 2013-10-04 10:11 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/0c4c40f5c399 8011138: C2: stack overflow in compiler thread because of recursive inlining of lambda form methods Reviewed-by: kvn, roland ! src/share/vm/opto/bytecodeInfo.cpp ! src/share/vm/opto/parse.hpp Changeset: 5f1241525a01 Author: twisti Date: 2013-10-04 19:05 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/5f1241525a01 Merge Changeset: bf8a21c3ab3b Author: vlivanov Date: 2013-10-07 14:10 +0400 URL: http://hg.openjdk.java.net/graal/graal/rev/bf8a21c3ab3b 8025849: Redundant "pid" in VM log file name (e.g. hotspot_pidpid12345.log) Reviewed-by: twisti, azeemj ! src/share/vm/utilities/ostream.cpp Changeset: 5cc2d82aa82a Author: vlivanov Date: 2013-10-07 14:11 +0400 URL: http://hg.openjdk.java.net/graal/graal/rev/5cc2d82aa82a 8024943: ciReplay: fails to dump replay data during safepointing Reviewed-by: kvn, twisti ! src/share/vm/ci/ciEnv.cpp ! src/share/vm/ci/ciEnv.hpp ! src/share/vm/ci/ciInstanceKlass.cpp ! src/share/vm/ci/ciMethod.cpp ! src/share/vm/ci/ciMethodData.cpp ! src/share/vm/utilities/vmError.cpp Changeset: f478c98e8114 Author: vlivanov Date: 2013-10-07 14:12 +0400 URL: http://hg.openjdk.java.net/graal/graal/rev/f478c98e8114 8024774: assert(_con < t->is_tuple()->cnt()) failed: ProjNode::_con must be in range Reviewed-by: iveresov, roland, kvn, twisti ! src/share/vm/opto/parse2.cpp Changeset: 5741fc86a2ee Author: vlivanov Date: 2013-10-07 14:13 +0400 URL: http://hg.openjdk.java.net/graal/graal/rev/5741fc86a2ee 8025845: Default methods are unnecessarily marked w/ force_inline directive in some situations Reviewed-by: acorn, kvn ! src/share/vm/classfile/defaultMethods.cpp Changeset: c775af091fe9 Author: twisti Date: 2013-10-07 10:41 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/c775af091fe9 8025566: EXCEPTION_ACCESS_VIOLATION in compiled by C1 String.valueOf method Reviewed-by: kvn ! src/share/vm/c1/c1_LIRGenerator.cpp ! src/share/vm/ci/ciMethod.cpp ! src/share/vm/ci/ciMethod.hpp ! src/share/vm/ci/ciMethodData.cpp ! src/share/vm/ci/ciMethodData.hpp ! src/share/vm/ci/ciReplay.cpp ! src/share/vm/oops/method.hpp ! src/share/vm/opto/parseHelper.cpp Changeset: d9043b88eeb3 Author: roland Date: 2013-10-03 10:55 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/d9043b88eeb3 8024067: Missing replace_in_map() calls following null checks Summary: add replace_in_map() calls following some null checks in type checks Reviewed-by: kvn ! src/share/vm/opto/graphKit.cpp ! src/share/vm/opto/graphKit.hpp Changeset: 17cda06bcb7d Author: iveresov Date: 2013-10-08 07:08 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/17cda06bcb7d Merge ! src/share/vm/classfile/defaultMethods.cpp - test/compiler/8013496/Test8013496.sh Changeset: 6171eb9da4fd Author: twisti Date: 2013-10-08 19:57 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/6171eb9da4fd 8007923: Tests on references fails Reviewed-by: kvn, iveresov ! src/share/vm/ci/ciKlass.cpp ! src/share/vm/opto/escape.cpp Changeset: 98692a2d36d7 Author: adlertz Date: 2013-10-09 13:00 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/98692a2d36d7 8013830: [parfait] Uninitialised pointer 'Reachblock' may be used as argument Summary: Replace uninitialised pointer with NULL at argument. Reviewed-by: kvn, roland, twisti ! src/share/vm/opto/reg_split.cpp Changeset: 4e7f99b70d9d Author: adlertz Date: 2013-10-09 05:03 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/4e7f99b70d9d Merge - test/testlibrary/AssertsTest.java - test/testlibrary/OutputAnalyzerReportingTest.java - test/testlibrary/OutputAnalyzerTest.java Changeset: 46ef27bcacb3 Author: twisti Date: 2013-10-09 11:05 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/46ef27bcacb3 8020750: Node::get_int: guarantee(t != NULL) failed: must be con Reviewed-by: kvn, roland ! src/share/vm/opto/ifnode.cpp Changeset: d13d7aba8c12 Author: roland Date: 2013-10-09 16:32 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/d13d7aba8c12 8023657: New type profiling points: arguments to call Summary: x86 interpreter and c1 type profiling for arguments at calls Reviewed-by: kvn, twisti ! src/cpu/sparc/vm/c1_LIRAssembler_sparc.cpp ! src/cpu/sparc/vm/globals_sparc.hpp ! src/cpu/x86/vm/c1_LIRAssembler_x86.cpp ! src/cpu/x86/vm/globals_x86.hpp ! src/cpu/x86/vm/interp_masm_x86_32.cpp ! src/cpu/x86/vm/interp_masm_x86_32.hpp ! src/cpu/x86/vm/interp_masm_x86_64.cpp ! src/cpu/x86/vm/interp_masm_x86_64.hpp ! src/cpu/x86/vm/macroAssembler_x86.hpp ! src/cpu/x86/vm/templateTable_x86_32.cpp ! src/cpu/x86/vm/templateTable_x86_64.cpp ! src/share/vm/c1/c1_Compilation.cpp ! src/share/vm/c1/c1_Compilation.hpp ! src/share/vm/c1/c1_GraphBuilder.cpp ! src/share/vm/c1/c1_GraphBuilder.hpp ! src/share/vm/c1/c1_Instruction.cpp ! src/share/vm/c1/c1_Instruction.hpp ! src/share/vm/c1/c1_InstructionPrinter.cpp ! src/share/vm/c1/c1_LIR.cpp ! src/share/vm/c1/c1_LIR.hpp ! src/share/vm/c1/c1_LIRAssembler.hpp ! src/share/vm/c1/c1_LIRGenerator.cpp ! src/share/vm/c1/c1_LIRGenerator.hpp ! src/share/vm/c1/c1_Optimizer.cpp ! src/share/vm/c1/c1_RangeCheckElimination.hpp ! src/share/vm/ci/ciClassList.hpp ! src/share/vm/ci/ciInstanceKlass.hpp ! src/share/vm/ci/ciKlass.hpp ! src/share/vm/ci/ciMethodData.cpp ! src/share/vm/ci/ciMethodData.hpp ! src/share/vm/ci/ciObjArrayKlass.cpp ! src/share/vm/ci/ciObjArrayKlass.hpp ! src/share/vm/ci/ciStreams.hpp ! src/share/vm/ci/ciTypeArrayKlass.hpp ! src/share/vm/oops/methodData.cpp ! src/share/vm/oops/methodData.hpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/java.cpp ! src/share/vm/runtime/signature.cpp ! src/share/vm/runtime/signature.hpp Changeset: 8b80b262e501 Author: twisti Date: 2013-10-11 10:14 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/8b80b262e501 8005173: assert(false) failed: DEBUG MESSAGE: exception oop must be empty (macroAssembler_x86.cpp:625) Reviewed-by: kvn, iveresov ! src/cpu/sparc/vm/c1_Runtime1_sparc.cpp ! src/share/vm/c1/c1_Runtime1.cpp ! src/share/vm/opto/runtime.cpp ! src/share/vm/runtime/thread.hpp Changeset: d8a449d2f5b2 Author: adlertz Date: 2013-10-11 13:10 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/d8a449d2f5b2 8011415: CTW on Sparc: assert(lrg.lo_degree()) failed: Summary: Increased the LRG AllStack mask size since the previous size was not big enough when compiling huge methods (60k+ nodes) Reviewed-by: kvn, roland, twisti ! src/share/vm/opto/chaitin.hpp ! src/share/vm/opto/ifg.cpp Changeset: 2348b2726e1d Author: adlertz Date: 2013-10-11 19:16 +0000 URL: http://hg.openjdk.java.net/graal/graal/rev/2348b2726e1d Merge Changeset: dd2cf1d1248b Author: adlertz Date: 2013-10-12 01:29 +0000 URL: http://hg.openjdk.java.net/graal/graal/rev/dd2cf1d1248b Merge Changeset: 469216acdb28 Author: anoll Date: 2013-10-10 15:44 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/469216acdb28 8023014: CodeSweeperSweepNoFlushTest.java fails with HS crash Summary: Ensure ensure correct initialization of compiler runtime Reviewed-by: kvn, twisti ! src/share/vm/c1/c1_Compiler.cpp ! src/share/vm/c1/c1_Compiler.hpp ! src/share/vm/code/codeBlob.cpp ! src/share/vm/code/codeBlob.hpp ! src/share/vm/compiler/abstractCompiler.cpp ! src/share/vm/compiler/abstractCompiler.hpp ! src/share/vm/compiler/compileBroker.cpp ! src/share/vm/compiler/compileBroker.hpp ! src/share/vm/opto/c2compiler.cpp ! src/share/vm/opto/c2compiler.hpp ! src/share/vm/opto/runtime.cpp ! src/share/vm/opto/runtime.hpp ! src/share/vm/runtime/thread.cpp ! src/share/vm/runtime/thread.hpp ! src/share/vm/runtime/vmStructs.cpp ! src/share/vm/shark/sharkCompiler.cpp ! src/share/vm/shark/sharkCompiler.hpp + test/compiler/startup/SmallCodeCacheStartup.java Changeset: ed2c74787eb5 Author: twisti Date: 2013-10-11 19:51 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/ed2c74787eb5 Merge Changeset: ce0cc25bc5e2 Author: roland Date: 2013-10-12 12:12 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/ce0cc25bc5e2 8026054: New type profiling points: type of return values at calls Summary: x86 interpreter and c1 type profiling for return values at calls Reviewed-by: kvn, twisti ! src/cpu/x86/vm/globals_x86.hpp ! src/cpu/x86/vm/interp_masm_x86_32.cpp ! src/cpu/x86/vm/interp_masm_x86_32.hpp ! src/cpu/x86/vm/interp_masm_x86_64.cpp ! src/cpu/x86/vm/interp_masm_x86_64.hpp ! src/cpu/x86/vm/templateInterpreter_x86_32.cpp ! src/cpu/x86/vm/templateInterpreter_x86_64.cpp ! src/share/vm/c1/c1_Canonicalizer.cpp ! src/share/vm/c1/c1_Canonicalizer.hpp ! src/share/vm/c1/c1_GraphBuilder.cpp ! src/share/vm/c1/c1_GraphBuilder.hpp ! src/share/vm/c1/c1_Instruction.hpp ! src/share/vm/c1/c1_InstructionPrinter.cpp ! src/share/vm/c1/c1_InstructionPrinter.hpp ! src/share/vm/c1/c1_LIRGenerator.cpp ! src/share/vm/c1/c1_LIRGenerator.hpp ! src/share/vm/c1/c1_Optimizer.cpp ! src/share/vm/c1/c1_RangeCheckElimination.hpp ! src/share/vm/c1/c1_ValueMap.hpp ! src/share/vm/ci/ciMethodData.cpp ! src/share/vm/ci/ciMethodData.hpp ! src/share/vm/oops/methodData.cpp ! src/share/vm/oops/methodData.hpp ! src/share/vm/runtime/globals.hpp Changeset: f50418dfb1b7 Author: iveresov Date: 2013-10-13 13:22 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/f50418dfb1b7 Merge ! src/cpu/sparc/vm/c1_Runtime1_sparc.cpp ! src/share/vm/classfile/defaultMethods.cpp ! src/share/vm/oops/method.hpp ! src/share/vm/opto/graphKit.cpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/vmStructs.cpp - test/compiler/8013496/Test8013496.sh Changeset: e504cd481ec0 Author: twisti Date: 2013-10-14 19:30 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/e504cd481ec0 8026376: assert(false) failed: DEBUG MESSAGE: exception pc already set Reviewed-by: kvn ! src/cpu/sparc/vm/sharedRuntime_sparc.cpp Changeset: 8df6f123d35e Author: drchase Date: 2013-10-12 17:26 -0400 URL: http://hg.openjdk.java.net/graal/graal/rev/8df6f123d35e 8026124: JSR-292 bug: java.nio.file.Path.toString cores dump Summary: catch problem case, assert it matches valid input, new test Reviewed-by: jrose, twisti, kvn ! src/share/vm/interpreter/linkResolver.cpp + test/compiler/jsr292/CreatesInterfaceDotEqualsCallInfo.java + test/compiler/jsr292/createsInterfaceDotEqualsCallInfo.js Changeset: f91a9a696e5e Author: kvn Date: 2013-10-15 12:14 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/f91a9a696e5e 8026293: Schedule part of G1 pre-barrier late Summary: move rare executed part of G1 write barrier from hot path. Reviewed-by: kvn, twisti, roland Contributed-by: staffan.friberg at oracle.com ! src/share/vm/opto/graphKit.cpp Changeset: 1263c7e17e1c Author: kvn Date: 2013-10-15 17:47 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/1263c7e17e1c Merge Changeset: 4a2acfb16e97 Author: rbackman Date: 2013-10-11 12:06 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/4a2acfb16e97 8025657: compiler/intrinsics/mathexact/ConstantTest.java fails on assert in lcm.cpp on solaris x64 Reviewed-by: kvn, twisti ! src/share/vm/opto/compile.cpp ! src/share/vm/opto/mathexactnode.cpp ! src/share/vm/opto/mathexactnode.hpp + test/compiler/intrinsics/mathexact/RepeatTest.java Changeset: 90abdd727e64 Author: iveresov Date: 2013-10-16 11:13 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/90abdd727e64 8009303: Tiered: incorrect results in VM tests stringconcat with -Xcomp -XX:+DeoptimizeALot on solaris-amd64 Summary: Do memory flow analysis in string concat optimizier to exclude cases when computation of arguments to StringBuffer::append has side effects Reviewed-by: kvn, twisti ! src/share/vm/opto/idealGraphPrinter.cpp ! src/share/vm/opto/stringopts.cpp Changeset: 8f4bb1773fd9 Author: iveresov Date: 2013-10-17 10:58 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/8f4bb1773fd9 Merge ! src/share/vm/interpreter/linkResolver.cpp - test/compiler/8013496/Test8013496.sh Changeset: 7114c4597ae3 Author: acorn Date: 2013-10-17 23:30 -0400 URL: http://hg.openjdk.java.net/graal/graal/rev/7114c4597ae3 8026365: NoClassDefinitionFound for anonymous class invokespecial. Reviewed-by: dcubed, kamg ! src/share/vm/classfile/verifier.cpp ! test/TEST.groups Changeset: 9c8289162268 Author: jwilhelm Date: 2013-10-11 16:18 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/9c8289162268 8024776: Max/MinHeapFreeRatio descriptions should be more precise Summary: Descriptions for Max/MinHeapFreeRatio updated Reviewed-by: ehelin, jmasa ! src/share/vm/runtime/globals.hpp Changeset: 2382ff14d889 Author: jwilhelm Date: 2013-10-12 05:08 +0000 URL: http://hg.openjdk.java.net/graal/graal/rev/2382ff14d889 Merge ! src/share/vm/runtime/globals.hpp Changeset: 24f32d09a0d7 Author: jwilhelm Date: 2013-10-12 00:49 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/24f32d09a0d7 8023643: G1 assert failed when NewSize was specified greater than MaxNewSize Summary: Exit with an error if incompatible NewSize and MaxNeSize are set Reviewed-by: brutisso, tschatzl ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.cpp Changeset: d6818f623792 Author: tschatzl Date: 2013-10-15 11:18 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/d6818f623792 8026186: gc/metaspace/CompressedClassSpaceSizeInJmapHeap.java Compilation failed Summary: After a method rename in JDK-8014905 the mentioned test did not compile any more. Fix the uses of the affected method. Reviewed-by: jwilhelm, mgerdin, jmasa ! test/serviceability/sa/jmap-hprof/JMapHProfLargeHeapTest.java ! test/testlibrary/com/oracle/java/testlibrary/JDKToolLauncher.java Changeset: 027006a47a6d Author: sjohanss Date: 2013-10-14 14:21 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/027006a47a6d 8025661: Ill-formed -Xminf and -Xmaxf options values interpreted as 0 Summary: Using strtod() instead of atof() when parsing -Xminf and -Xmaxf. Reviewed-by: brutisso, pliden ! src/share/vm/runtime/arguments.cpp + test/gc/arguments/TestHeapFreeRatio.java Changeset: 82fcc0567fef Author: mgerdin Date: 2013-10-15 04:29 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/82fcc0567fef Merge Changeset: 6f1919cfd18c Author: pliden Date: 2013-10-15 11:38 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/6f1919cfd18c 8023158: hotspot/test/gc/7168848/HumongousAlloc.java fails 14 full gcs, expect 0 full gcs Reviewed-by: brutisso, tschatzl ! test/TEST.groups - test/gc/7168848/HumongousAlloc.java + test/gc/g1/TestHumongousAllocInitialMark.java Changeset: bfd52054aeb8 Author: pliden Date: 2013-10-15 11:42 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/bfd52054aeb8 8024632: Description of InitialSurvivorRatio flag in globals.hpp is incorrect Reviewed-by: brutisso, tschatzl, kmo, tamao ! src/share/vm/runtime/globals.hpp Changeset: 041c5da41ac4 Author: pliden Date: 2013-10-15 11:44 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/041c5da41ac4 8024634: gc/startup_warnings tests can fail due to unrelated warnings Reviewed-by: brutisso, jwilhelm, tamao ! test/gc/startup_warnings/TestCMS.java ! test/gc/startup_warnings/TestCMSNoIncrementalMode.java ! test/gc/startup_warnings/TestG1.java ! test/gc/startup_warnings/TestParNewCMS.java ! test/gc/startup_warnings/TestParallelGC.java ! test/gc/startup_warnings/TestParallelScavengeSerialOld.java ! test/gc/startup_warnings/TestSerialGC.java Changeset: f16726924734 Author: stefank Date: 2013-10-15 07:10 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/f16726924734 Merge - test/gc/7168848/HumongousAlloc.java Changeset: bdfbb1fb19ca Author: stefank Date: 2013-10-15 14:28 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/bdfbb1fb19ca 8026391: The Metachunk header wastes memory Reviewed-by: coleenp, jmasa ! src/share/vm/memory/binaryTreeDictionary.cpp ! src/share/vm/memory/freeBlockDictionary.cpp ! src/share/vm/memory/freeList.cpp - src/share/vm/memory/metablock.cpp - src/share/vm/memory/metablock.hpp ! src/share/vm/memory/metachunk.cpp ! src/share/vm/memory/metachunk.hpp ! src/share/vm/memory/metaspace.cpp ! src/share/vm/memory/metaspace.hpp ! src/share/vm/prims/jni.cpp ! src/share/vm/runtime/vmStructs.cpp Changeset: ec2e26e26183 Author: stefank Date: 2013-10-15 14:32 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/ec2e26e26183 8026392: Metachunks and Metablocks are using a too large alignment Reviewed-by: coleenp, jmasa ! src/share/vm/memory/metachunk.cpp Changeset: 9e5fadad7fdf Author: tschatzl Date: 2013-10-16 11:46 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/9e5fadad7fdf 8025925: jmap fails with "field _length not found in type HeapRegionSeq" Summary: The change JDK-7163191 changed the data layout of a class that is referenced by the java code of the SA agent. This fix synchronizes the SA agent with that change. Reviewed-by: sla, mgerdin + agent/src/share/classes/sun/jvm/hotspot/gc_implementation/g1/G1HeapRegionTable.java ! agent/src/share/classes/sun/jvm/hotspot/gc_implementation/g1/HeapRegionSeq.java Changeset: 28df60a5badf Author: stefank Date: 2013-10-17 08:41 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/28df60a5badf 8026707: JDK-8026391 broke the optimized build target Reviewed-by: mgerdin, coleenp ! src/share/vm/memory/metachunk.hpp Changeset: 94c0343b1887 Author: stefank Date: 2013-10-17 08:42 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/94c0343b1887 8026715: Remove the MetaDataDeallocateALot develop flag Reviewed-by: coleenp, mgerdin ! src/share/vm/memory/metaspace.cpp ! src/share/vm/runtime/globals.hpp Changeset: bf9e50c573ad Author: jmasa Date: 2013-10-17 06:29 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/bf9e50c573ad 8025635: SoftReferences are not cleared before metaspace OOME are thrown Reviewed-by: jcoomes, tamao, tschatzl, stefank ! src/share/vm/gc_implementation/shared/vmGCOperations.cpp Changeset: c51cd6af7e61 Author: jcoomes Date: 2013-10-18 12:10 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/c51cd6af7e61 Merge ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/vmStructs.cpp ! test/TEST.groups - test/compiler/8013496/Test8013496.sh ! test/serviceability/sa/jmap-hprof/JMapHProfLargeHeapTest.java ! test/testlibrary/com/oracle/java/testlibrary/JDKToolLauncher.java Changeset: 23b8db5ea31d Author: amurillo Date: 2013-10-18 21:30 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/23b8db5ea31d Merge - src/share/vm/memory/metablock.cpp - src/share/vm/memory/metablock.hpp - test/compiler/8013496/Test8013496.sh - test/gc/7168848/HumongousAlloc.java Changeset: e8cbdc701bfb Author: amurillo Date: 2013-10-18 21:30 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/e8cbdc701bfb Added tag hs25-b55 for changeset 23b8db5ea31d ! .hgtags Changeset: 5c599c419c1d Author: hseigel Date: 2013-07-11 12:59 -0400 URL: http://hg.openjdk.java.net/graal/graal/rev/5c599c419c1d 8016256: Make finalization final Summary: Add private methods to final methods check Reviewed-by: coleenp, acorn, ahgross Contributed-by: harold.seigel at oracle.com ! src/share/vm/classfile/classFileParser.cpp Changeset: d840f02d03b4 Author: chegar Date: 2013-07-15 11:07 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/d840f02d03b4 Merge - src/os_cpu/linux_sparc/vm/assembler_linux_sparc.cpp - src/os_cpu/solaris_sparc/vm/assembler_solaris_sparc.cpp Changeset: 7ec210434b3c Author: chegar Date: 2013-07-22 14:01 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/7ec210434b3c Merge - src/share/vm/memory/klassInfoClosure.hpp - src/share/vm/runtime/aprofiler.cpp - src/share/vm/runtime/aprofiler.hpp Changeset: ca9029490fce Author: chegar Date: 2013-07-25 17:35 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/ca9029490fce Merge Changeset: 8f66130f7b5c Author: chegar Date: 2013-08-02 11:10 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/8f66130f7b5c Merge ! src/share/vm/classfile/classFileParser.cpp Changeset: 38f9393d1847 Author: sgabdura Date: 2013-08-09 11:03 +0400 URL: http://hg.openjdk.java.net/graal/graal/rev/38f9393d1847 8020789: Disable exporting of gc.heap_dump diagnostic command Reviewed-by: fparain, ahgross ! src/share/vm/services/diagnosticCommand.cpp Changeset: ee7a7aa7c6bb Author: chegar Date: 2013-08-09 14:30 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/ee7a7aa7c6bb Merge Changeset: 8f3c59225a5c Author: chegar Date: 2013-08-15 21:33 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/8f3c59225a5c Merge - test/runtime/7196045/Test7196045.java - test/runtime/8000968/Test8000968.sh Changeset: 7638e35cabc6 Author: erikj Date: 2013-08-19 17:47 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/7638e35cabc6 8015614: Update build settings Reviewed-by: tbell, dholmes, ahgross ! make/windows/makefiles/compile.make ! make/windows/makefiles/sa.make Changeset: d4fa23d6c35b Author: chegar Date: 2013-08-23 22:12 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/d4fa23d6c35b Merge - src/os_cpu/bsd_x86/vm/bsd_x86_32.ad - src/os_cpu/bsd_x86/vm/bsd_x86_64.ad - src/os_cpu/linux_x86/vm/linux_x86_32.ad - src/os_cpu/linux_x86/vm/linux_x86_64.ad - src/os_cpu/solaris_sparc/vm/solaris_sparc.ad - src/os_cpu/solaris_x86/vm/solaris_x86_32.ad - src/os_cpu/solaris_x86/vm/solaris_x86_64.ad - src/os_cpu/windows_x86/vm/windows_x86_32.ad - src/os_cpu/windows_x86/vm/windows_x86_64.ad Changeset: 07b5f47d7a18 Author: chegar Date: 2013-08-30 09:50 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/07b5f47d7a18 Merge ! src/share/vm/classfile/classFileParser.cpp Changeset: 98a2169ed7ac Author: iklam Date: 2013-08-24 00:14 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/98a2169ed7ac 8023683: Enhance class file parsing Summary: Use the value returned by REALLOC_RESOURCE_ARRAY() Reviewed-by: coleenp, ahgross ! src/share/vm/classfile/classFileParser.cpp Changeset: 8321dcc18438 Author: chegar Date: 2013-10-13 21:14 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/8321dcc18438 Merge ! src/share/vm/classfile/classFileParser.cpp Changeset: 1a93f2c5945a Author: lana Date: 2013-10-17 14:20 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/1a93f2c5945a Merge ! make/windows/makefiles/compile.make ! make/windows/makefiles/sa.make ! src/share/vm/classfile/classFileParser.cpp Changeset: 4589b398ab03 Author: amurillo Date: 2013-10-22 13:56 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/4589b398ab03 Merge - src/share/vm/memory/metablock.cpp - src/share/vm/memory/metablock.hpp - test/compiler/8013496/Test8013496.sh - test/gc/7168848/HumongousAlloc.java Changeset: 4a1128861221 Author: cl Date: 2013-10-24 09:10 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/4a1128861221 Added tag jdk8-b113 for changeset 4589b398ab03 ! .hgtags Changeset: d6d8aeb2c2d4 Author: amurillo Date: 2013-10-19 08:52 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/d6d8aeb2c2d4 8026928: new hotspot build - hs25-b56 Reviewed-by: jcoomes ! make/hotspot_version Changeset: 384c92148c68 Author: amurillo Date: 2013-10-21 14:38 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/384c92148c68 8023496: [jprt] build and test solaris 64-bits only Reviewed-by: tbell, jcoomes ! make/jprt.properties Changeset: f9d4ed6c88dd Author: dholmes Date: 2013-10-21 20:51 -0400 URL: http://hg.openjdk.java.net/graal/graal/rev/f9d4ed6c88dd 8026872: [TESTBUG] Classes OOMCrashClass4000_1.class and OOMCrashClass1960_2.class from runtime/ClassFile/ tests won't run on compact profiles Reviewed-by: sla, sspitsyn ! test/TEST.groups Changeset: 8cd1abf3ecab Author: dholmes Date: 2013-10-21 21:06 -0400 URL: http://hg.openjdk.java.net/graal/graal/rev/8cd1abf3ecab Merge - src/share/vm/memory/metablock.cpp - src/share/vm/memory/metablock.hpp ! test/TEST.groups - test/compiler/8013496/Test8013496.sh - test/gc/7168848/HumongousAlloc.java Changeset: 2036c97e3af0 Author: dholmes Date: 2013-10-21 22:36 -0400 URL: http://hg.openjdk.java.net/graal/graal/rev/2036c97e3af0 Merge Changeset: 7fe6ef09d242 Author: farvidsson Date: 2013-10-16 09:20 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/7fe6ef09d242 8025638: jmap returns 0 instead of 1 when it fails. Summary: Re-factored some code handling return values and fails/errors during tool execution. Reviewed-by: sla, kevinw Contributed-by: fredrik.arvidsson at oracle.com ! agent/src/share/classes/sun/jvm/hotspot/tools/ClassLoaderStats.java ! agent/src/share/classes/sun/jvm/hotspot/tools/FinalizerInfo.java ! agent/src/share/classes/sun/jvm/hotspot/tools/FlagDumper.java ! agent/src/share/classes/sun/jvm/hotspot/tools/HeapDumper.java ! agent/src/share/classes/sun/jvm/hotspot/tools/HeapSummary.java ! agent/src/share/classes/sun/jvm/hotspot/tools/JInfo.java ! agent/src/share/classes/sun/jvm/hotspot/tools/JMap.java ! agent/src/share/classes/sun/jvm/hotspot/tools/JSnap.java ! agent/src/share/classes/sun/jvm/hotspot/tools/JStack.java ! agent/src/share/classes/sun/jvm/hotspot/tools/ObjectHistogram.java ! agent/src/share/classes/sun/jvm/hotspot/tools/PMap.java ! agent/src/share/classes/sun/jvm/hotspot/tools/PStack.java ! agent/src/share/classes/sun/jvm/hotspot/tools/StackTrace.java ! agent/src/share/classes/sun/jvm/hotspot/tools/SysPropsDumper.java ! agent/src/share/classes/sun/jvm/hotspot/tools/Tool.java ! agent/src/share/classes/sun/jvm/hotspot/tools/jcore/ClassDump.java ! agent/src/share/classes/sun/jvm/hotspot/tools/soql/JSDB.java ! agent/src/share/classes/sun/jvm/hotspot/tools/soql/SOQL.java Changeset: 042cf42c72bd Author: simonis Date: 2013-10-16 15:06 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/042cf42c72bd 8026703: Wrongly placed element in Event-Based JVM Tracing .xsl files Reviewed-by: sla, kamg ! src/share/vm/trace/traceEventClasses.xsl ! src/share/vm/trace/traceEventIds.xsl ! src/share/vm/trace/traceTypes.xsl Changeset: d248425bcfe8 Author: hseigel Date: 2013-10-16 14:32 -0400 URL: http://hg.openjdk.java.net/graal/graal/rev/d248425bcfe8 8024804: Crash when InterfaceMethodref resolves to Object.registerNatives Summary: Added check for NULL prior to continuation of method look up to avoid runtime crash during look up of Object's superclass' methods. Reviewed-by: coleenp, hseigel Contributed-by: lois.foltan at oracle.com ! src/share/vm/interpreter/linkResolver.cpp + test/runtime/8024804/RegisterNatives.java Changeset: 9e0ef3f02648 Author: hseigel Date: 2013-10-16 15:26 -0400 URL: http://hg.openjdk.java.net/graal/graal/rev/9e0ef3f02648 Merge Changeset: 1bee3014cf2a Author: dsamersoff Date: 2013-10-17 16:08 +0400 URL: http://hg.openjdk.java.net/graal/graal/rev/1bee3014cf2a 8025812: tmtools/jmap/heap_config tests fail on Linux-ia32 because it Cant attach to the core file Summary: Coredump store memsz elf field rounded up to page Reviewed-by: dholmes, sla ! agent/src/os/linux/ps_core.c Changeset: ffb471203842 Author: erikj Date: 2013-10-17 16:11 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/ffb471203842 8026792: HOTSPOT: licensee reports a JDK8 build failure after 8005849/8005008 fixes integrated. Reviewed-by: dholmes, sla ! make/windows/makefiles/trace.make Changeset: ad8e901ca2e1 Author: sla Date: 2013-10-17 12:15 -0400 URL: http://hg.openjdk.java.net/graal/graal/rev/ad8e901ca2e1 Merge Changeset: d2db09f281ca Author: dsamersoff Date: 2013-10-17 16:45 +0400 URL: http://hg.openjdk.java.net/graal/graal/rev/d2db09f281ca 8005810: Update Hotspot Serviceability Agent for Method Parameter Reflection and Generic Type Signature Data Summary: Hotspot was updated to store method parameter reflection and generic type signature data at runtime. Serviceability agent support was updated for this data Reviewed-by: coleenp, minqi, sla Contributed-by: eric.mccorkle at oracle.com ! agent/src/share/classes/sun/jvm/hotspot/oops/ConstMethod.java ! src/share/vm/runtime/vmStructs.cpp Changeset: b942ac65ac86 Author: dsamersoff Date: 2013-10-17 17:01 +0000 URL: http://hg.openjdk.java.net/graal/graal/rev/b942ac65ac86 Merge Changeset: d0453d2fd045 Author: dsamersoff Date: 2013-10-18 10:37 +0000 URL: http://hg.openjdk.java.net/graal/graal/rev/d0453d2fd045 Merge Changeset: ee99e1a7c5fb Author: ccheung Date: 2013-10-18 19:44 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/ee99e1a7c5fb Merge ! src/share/vm/interpreter/linkResolver.cpp - src/share/vm/memory/metablock.cpp - src/share/vm/memory/metablock.hpp ! src/share/vm/runtime/vmStructs.cpp - test/compiler/8013496/Test8013496.sh - test/gc/7168848/HumongousAlloc.java Changeset: 996d1f2f056f Author: dsamersoff Date: 2013-10-19 21:29 +0400 URL: http://hg.openjdk.java.net/graal/graal/rev/996d1f2f056f 8026930: In ManagementAgent.start it should be possible to set the jdp.name parameter (hotspot part) Summary: Pass one more property from Agent to JdpController Reviewed-by: jbachorik, sla ! src/share/vm/services/diagnosticCommand.cpp ! src/share/vm/services/diagnosticCommand.hpp Changeset: 1327b7f85503 Author: ccheung Date: 2013-10-21 17:26 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/1327b7f85503 Merge Changeset: 662c154d2749 Author: hseigel Date: 2013-10-22 14:47 -0400 URL: http://hg.openjdk.java.net/graal/graal/rev/662c154d2749 8026394: Eclipse fails with JDK8 build 111 Summary: If the resolved interface does not itself contain "clone" or "finalize" methods, the method/interface method resolution looks to the interface's super class, java.lang.Object. With the JDK 8 interface method accessability check requirement, since these two methods are declared within Object as protected, they must be special cased in LinkResolver::check_method_accessability() in order to avoid an IAE. Reviewed-by: acorn, dholmes Contributed-by: lois.foltan at oracle.com ! src/share/vm/interpreter/linkResolver.cpp + test/runtime/8026394/InterfaceObjectTest.java Changeset: b8860472c377 Author: iklam Date: 2013-10-22 14:29 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/b8860472c377 8014910: deadlock between JVM/TI ClassPrepare event handler and CompilerThread Summary: Revert changes in JDK-8008962 Reviewed-by: coleenp, sspitsyn ! src/share/vm/ci/ciEnv.cpp ! src/share/vm/oops/constantPool.cpp ! src/share/vm/oops/constantPool.hpp ! src/share/vm/oops/cpCache.cpp ! src/share/vm/oops/instanceKlass.cpp ! src/share/vm/oops/instanceKlass.hpp ! src/share/vm/prims/jvmtiEnv.cpp Changeset: 28be4c586b70 Author: iklam Date: 2013-10-22 16:09 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/28be4c586b70 Merge Changeset: a997d762fa20 Author: hseigel Date: 2013-10-22 15:54 -0400 URL: http://hg.openjdk.java.net/graal/graal/rev/a997d762fa20 8026809: [TESTBUG] Create regression test for JDK-8026041 Summary: Created simple regression test for the bug Reviewed-by: hseigel, lfoltan, zgu Contributed-by: mikhailo.seledtsov at oracle.com + test/runtime/CommandLine/PrintGCApplicationConcurrentTime.java Changeset: c183576a2dd1 Author: hseigel Date: 2013-10-22 22:14 -0400 URL: http://hg.openjdk.java.net/graal/graal/rev/c183576a2dd1 Merge Changeset: b658cfe35857 Author: farvidsson Date: 2013-10-23 10:24 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/b658cfe35857 8026808: serviceability/sa/jmap-hprof/JMapHProfLargeHeapTest.java failed with unexpected exit value Summary: Fixes a bug with vmArgs when using JDKToolLauncher Reviewed-by: sla, dholmes ! test/testlibrary/com/oracle/java/testlibrary/JDKToolLauncher.java Changeset: b3a4d4279fa3 Author: ccheung Date: 2013-10-24 17:20 -0400 URL: http://hg.openjdk.java.net/graal/graal/rev/b3a4d4279fa3 Merge Changeset: 74e00b98d5dd Author: anoll Date: 2013-10-17 19:47 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/74e00b98d5dd 8026708: guarantee(codelet_size > 0 && (size_t)codelet_size > 2*K) failed: not enough space for interpreter generation Summary: Increase size for the template interpreter accordingly Reviewed-by: kvn, twisti ! src/cpu/x86/vm/templateInterpreter_x86.hpp Changeset: 1856ea98184a Author: adlertz Date: 2013-10-18 10:50 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/1856ea98184a 8022783: Nashorn test fails with: assert(!def_outside->member(r)) Summary: Enables private copies of inputs for recent spill copies as well Reviewed-by: kvn, twisti ! src/share/vm/adlc/formssel.cpp ! src/share/vm/opto/reg_split.cpp Changeset: e3b736cf4fa3 Author: adlertz Date: 2013-10-18 09:36 +0000 URL: http://hg.openjdk.java.net/graal/graal/rev/e3b736cf4fa3 Merge Changeset: 252d541466ea Author: morris Date: 2013-10-18 12:15 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/252d541466ea 8008242: VerifyOops is broken on SPARC Summary: Fixed displacement issues in SPARC macroassembler and ensure that getClass intrinsic temporary result is T_METADATA Reviewed-by: kvn, twisti ! src/cpu/sparc/vm/c1_LIRAssembler_sparc.cpp ! src/cpu/sparc/vm/c1_Runtime1_sparc.cpp ! src/cpu/sparc/vm/macroAssembler_sparc.cpp ! src/cpu/x86/vm/c1_LIRAssembler_x86.cpp ! src/share/vm/c1/c1_LIRGenerator.cpp Changeset: 3213ba4d3dff Author: roland Date: 2013-10-19 12:16 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/3213ba4d3dff 8024069: replace_in_map() should operate on parent maps Summary: type information gets lost because replace_in_map() doesn't update parent maps Reviewed-by: kvn, twisti ! src/share/vm/opto/c2_globals.hpp ! src/share/vm/opto/callGenerator.cpp ! src/share/vm/opto/callGenerator.hpp ! src/share/vm/opto/compile.cpp ! src/share/vm/opto/compile.hpp ! src/share/vm/opto/doCall.cpp ! src/share/vm/opto/graphKit.cpp ! src/share/vm/opto/ifnode.cpp ! src/share/vm/opto/library_call.cpp ! src/share/vm/opto/loopPredicate.cpp ! src/share/vm/opto/loopnode.cpp ! src/share/vm/opto/loopnode.hpp ! src/share/vm/opto/loopopts.cpp ! src/share/vm/opto/multnode.cpp ! src/share/vm/opto/multnode.hpp ! src/share/vm/opto/parse.hpp ! src/share/vm/opto/parse1.cpp Changeset: 19c5a042b0b3 Author: iignatyev Date: 2013-10-19 21:54 +0400 URL: http://hg.openjdk.java.net/graal/graal/rev/19c5a042b0b3 8026414: [TESTBUG] Tests for Tiered/NonTiered levels Reviewed-by: twisti, iveresov + test/compiler/tiered/CompLevelsTest.java + test/compiler/tiered/NonTieredLevelsTest.java + test/compiler/tiered/TieredLevelsTest.java Changeset: 600c83f8e6a5 Author: iignatyev Date: 2013-10-19 21:54 +0400 URL: http://hg.openjdk.java.net/graal/graal/rev/600c83f8e6a5 8023318: compiler/whitebox tests timeout with enabled TieredCompilation Reviewed-by: kvn, twisti ! test/compiler/whitebox/CompilerWhiteBoxTest.java Changeset: e842cc2d2dfb Author: iveresov Date: 2013-10-19 22:22 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/e842cc2d2dfb Merge Changeset: 52575a17a36c Author: iignatyev Date: 2013-10-21 09:21 +0400 URL: http://hg.openjdk.java.net/graal/graal/rev/52575a17a36c 8026865: [TESTBUG] 'compiler/print/PrintInlining.java' should specify -XX:+UnlockDiagnosticVMOptions Reviewed-by: twisti, iveresov ! test/compiler/print/PrintInlining.java Changeset: 4748b3308cda Author: iveresov Date: 2013-10-21 17:34 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/4748b3308cda Merge Changeset: 5ccbab1c69f3 Author: roland Date: 2013-10-22 09:51 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/5ccbab1c69f3 8026251: New type profiling points: parameters to methods Summary: x86 interpreter and c1 type profiling for parameters on method entries Reviewed-by: kvn, twisti ! src/cpu/x86/vm/bytecodeInterpreter_x86.cpp ! src/cpu/x86/vm/globals_x86.hpp + src/cpu/x86/vm/interp_masm_x86.cpp + src/cpu/x86/vm/interp_masm_x86.hpp ! src/cpu/x86/vm/interp_masm_x86_32.cpp ! src/cpu/x86/vm/interp_masm_x86_32.hpp ! src/cpu/x86/vm/interp_masm_x86_64.cpp ! src/cpu/x86/vm/interp_masm_x86_64.hpp ! src/cpu/x86/vm/register_definitions_x86.cpp ! src/cpu/x86/vm/templateInterpreter_x86_32.cpp ! src/cpu/x86/vm/templateInterpreter_x86_64.cpp ! src/cpu/x86/vm/vtableStubs_x86_32.cpp ! src/cpu/x86/vm/vtableStubs_x86_64.cpp ! src/share/vm/c1/c1_Compilation.hpp ! src/share/vm/c1/c1_GraphBuilder.cpp ! src/share/vm/c1/c1_GraphBuilder.hpp ! src/share/vm/c1/c1_LIRGenerator.cpp ! src/share/vm/c1/c1_LIRGenerator.hpp ! src/share/vm/ci/ciMethodData.cpp ! src/share/vm/ci/ciMethodData.hpp ! src/share/vm/interpreter/abstractInterpreter.hpp ! src/share/vm/interpreter/templateTable.hpp ! src/share/vm/oops/methodData.cpp ! src/share/vm/oops/methodData.hpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/java.cpp Changeset: 435c7b4577cd Author: rbackman Date: 2013-10-21 15:31 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/435c7b4577cd 8026959: assert(!n->pinned() || n->is_MachConstantBase()) failed: only pinned MachConstantBase node is expected here Reviewed-by: iveresov, roland ! src/share/vm/opto/compile.cpp Changeset: 36e17466dd39 Author: rbackman Date: 2013-10-22 14:02 +0000 URL: http://hg.openjdk.java.net/graal/graal/rev/36e17466dd39 Merge Changeset: 8b4bbba322d3 Author: anoll Date: 2013-10-23 10:00 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/8b4bbba322d3 8026407: VM crashes on linux-ppc and linux-i586 when there is not enough ReservedCodeCacheSize specified Summary: Ensure currently required generation of AdapterHandlerLibrary::create_native_wrapper() Reviewed-by: roland, iveresov ! src/share/vm/compiler/compileBroker.cpp Changeset: b2ee5dc63353 Author: roland Date: 2013-10-23 12:40 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/b2ee5dc63353 8024070: C2 needs some form of type speculation Summary: record unused type profile information with type system, propagate and use it. Reviewed-by: kvn, twisti ! src/share/vm/ci/ciMethod.cpp ! src/share/vm/ci/ciMethod.hpp ! src/share/vm/ci/ciMethodData.hpp ! src/share/vm/opto/c2_globals.hpp ! src/share/vm/opto/callGenerator.cpp ! src/share/vm/opto/callGenerator.hpp ! src/share/vm/opto/compile.cpp ! src/share/vm/opto/compile.hpp ! src/share/vm/opto/doCall.cpp ! src/share/vm/opto/graphKit.cpp ! src/share/vm/opto/graphKit.hpp ! src/share/vm/opto/library_call.cpp ! src/share/vm/opto/parse.hpp ! src/share/vm/opto/parse1.cpp ! src/share/vm/opto/parse2.cpp ! src/share/vm/opto/parseHelper.cpp ! src/share/vm/opto/phaseX.cpp ! src/share/vm/opto/phaseX.hpp ! src/share/vm/opto/type.cpp ! src/share/vm/opto/type.hpp ! src/share/vm/runtime/arguments.cpp + test/compiler/types/TypeSpeculation.java Changeset: 4c9115774c8e Author: adlertz Date: 2013-10-23 10:44 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/4c9115774c8e 8026939: assert(Reachblock != NULL) failed: Reachblock must be non-NULL Summary: We can reach this state from phi input rematerialization, so pass in the Reaches of the predecessor Reviewed-by: roland, twisti ! src/share/vm/opto/reg_split.cpp Changeset: 97d400662426 Author: adlertz Date: 2013-10-23 19:22 +0000 URL: http://hg.openjdk.java.net/graal/graal/rev/97d400662426 Merge Changeset: 9acbfe04b5c3 Author: iveresov Date: 2013-10-23 11:15 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/9acbfe04b5c3 8026495: JVM Crashes when started with -XX:+DTraceMethodProbes on Solaris x86_64 Summary: Fix wrong calling convention in LIR_Assembler::emit_unwind_handler(), T_METADATA support in calling convention generator, C1 register allocator Reviewed-by: twisti, jrose ! src/cpu/sparc/vm/c1_FrameMap_sparc.cpp ! src/cpu/x86/vm/c1_FrameMap_x86.cpp ! src/cpu/x86/vm/c1_LIRAssembler_x86.cpp ! src/share/vm/c1/c1_LIR.cpp ! src/share/vm/c1/c1_LIRGenerator.cpp ! src/share/vm/c1/c1_LinearScan.cpp Changeset: 1c90f0072f0d Author: twisti Date: 2013-10-23 15:44 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/1c90f0072f0d 8026502: java/lang/invoke/MethodHandleConstants.java fails on all platforms Reviewed-by: iveresov, jrose ! src/share/vm/classfile/systemDictionary.cpp Changeset: 3a04e444da6d Author: iveresov Date: 2013-10-23 16:25 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/3a04e444da6d Merge Changeset: 59e8ad757e19 Author: rbackman Date: 2013-10-18 10:41 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/59e8ad757e19 8026844: Various Math functions needs intrinsification Reviewed-by: kvn, twisti ! src/cpu/sparc/vm/sparc.ad ! src/cpu/x86/vm/assembler_x86.cpp ! src/cpu/x86/vm/assembler_x86.hpp ! src/cpu/x86/vm/x86_32.ad ! src/cpu/x86/vm/x86_64.ad ! src/share/vm/adlc/archDesc.cpp ! src/share/vm/classfile/vmSymbols.hpp ! src/share/vm/opto/classes.hpp ! src/share/vm/opto/library_call.cpp ! src/share/vm/opto/matcher.hpp ! src/share/vm/opto/mathexactnode.cpp ! src/share/vm/opto/mathexactnode.hpp ! src/share/vm/opto/node.hpp ! src/share/vm/opto/type.cpp ! src/share/vm/opto/type.hpp ! src/share/vm/runtime/vmStructs.cpp + test/compiler/intrinsics/mathexact/AddExactICondTest.java + test/compiler/intrinsics/mathexact/AddExactIConstantTest.java + test/compiler/intrinsics/mathexact/AddExactILoadTest.java + test/compiler/intrinsics/mathexact/AddExactILoopDependentTest.java + test/compiler/intrinsics/mathexact/AddExactINonConstantTest.java + test/compiler/intrinsics/mathexact/AddExactIRepeatTest.java + test/compiler/intrinsics/mathexact/AddExactLConstantTest.java + test/compiler/intrinsics/mathexact/AddExactLNonConstantTest.java - test/compiler/intrinsics/mathexact/CondTest.java - test/compiler/intrinsics/mathexact/ConstantTest.java + test/compiler/intrinsics/mathexact/DecExactITest.java + test/compiler/intrinsics/mathexact/DecExactLTest.java + test/compiler/intrinsics/mathexact/IncExactITest.java + test/compiler/intrinsics/mathexact/IncExactLTest.java - test/compiler/intrinsics/mathexact/LoadTest.java - test/compiler/intrinsics/mathexact/LoopDependentTest.java + test/compiler/intrinsics/mathexact/MulExactICondTest.java + test/compiler/intrinsics/mathexact/MulExactIConstantTest.java + test/compiler/intrinsics/mathexact/MulExactILoadTest.java + test/compiler/intrinsics/mathexact/MulExactILoopDependentTest.java + test/compiler/intrinsics/mathexact/MulExactINonConstantTest.java + test/compiler/intrinsics/mathexact/MulExactIRepeatTest.java + test/compiler/intrinsics/mathexact/MulExactLConstantTest.java + test/compiler/intrinsics/mathexact/MulExactLNonConstantTest.java + test/compiler/intrinsics/mathexact/NegExactIConstantTest.java + test/compiler/intrinsics/mathexact/NegExactILoadTest.java + test/compiler/intrinsics/mathexact/NegExactILoopDependentTest.java + test/compiler/intrinsics/mathexact/NegExactINonConstantTest.java + test/compiler/intrinsics/mathexact/NegExactLConstantTest.java + test/compiler/intrinsics/mathexact/NegExactLNonConstantTest.java - test/compiler/intrinsics/mathexact/NonConstantTest.java - test/compiler/intrinsics/mathexact/RepeatTest.java + test/compiler/intrinsics/mathexact/SubExactICondTest.java + test/compiler/intrinsics/mathexact/SubExactIConstantTest.java + test/compiler/intrinsics/mathexact/SubExactILoadTest.java + test/compiler/intrinsics/mathexact/SubExactILoopDependentTest.java + test/compiler/intrinsics/mathexact/SubExactINonConstantTest.java + test/compiler/intrinsics/mathexact/SubExactIRepeatTest.java + test/compiler/intrinsics/mathexact/SubExactLConstantTest.java + test/compiler/intrinsics/mathexact/SubExactLNonConstantTest.java ! test/compiler/intrinsics/mathexact/Verify.java Changeset: 68f07c29521b Author: anoll Date: 2013-10-15 08:38 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/68f07c29521b 8025740: Typo. Error line for wrong ReservedCodeCacheSize value is printed twice Summary: Remove duplicate print Reviewed-by: kvn, twisti ! src/share/vm/runtime/arguments.cpp Changeset: d95eca175eff Author: sspitsyn Date: 2013-10-23 20:15 +0400 URL: http://hg.openjdk.java.net/graal/graal/rev/d95eca175eff 8023004: JSR 292: java.lang.RuntimeException: Original target method was called. Reviewed-by: jrose ! src/share/vm/prims/methodHandles.cpp Changeset: 0d1661d63d70 Author: vlivanov Date: 2013-10-23 20:20 +0400 URL: http://hg.openjdk.java.net/graal/graal/rev/0d1661d63d70 8012941: JSR 292: too deep inlining might crash compiler because of stack overflow Reviewed-by: kvn, twisti ! src/share/vm/c1/c1_GraphBuilder.cpp ! src/share/vm/c1/c1_globals.hpp Changeset: f7d928a3181c Author: roland Date: 2013-10-24 19:32 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/f7d928a3181c 8026978: JSR292: fatal error: Type profiling not implemented on this platform Summary: force TypeProfileLevel to 0 on non x86 Reviewed-by: twisti ! src/share/vm/runtime/arguments.cpp Changeset: 395499125cb0 Author: iveresov Date: 2013-10-24 16:14 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/395499125cb0 Merge - test/compiler/intrinsics/mathexact/CondTest.java - test/compiler/intrinsics/mathexact/ConstantTest.java - test/compiler/intrinsics/mathexact/LoadTest.java - test/compiler/intrinsics/mathexact/LoopDependentTest.java - test/compiler/intrinsics/mathexact/NonConstantTest.java - test/compiler/intrinsics/mathexact/RepeatTest.java Changeset: 6b32b911d723 Author: iveresov Date: 2013-10-24 16:25 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/6b32b911d723 Merge ! src/share/vm/runtime/vmStructs.cpp - test/compiler/intrinsics/mathexact/CondTest.java - test/compiler/intrinsics/mathexact/ConstantTest.java - test/compiler/intrinsics/mathexact/LoadTest.java - test/compiler/intrinsics/mathexact/LoopDependentTest.java - test/compiler/intrinsics/mathexact/NonConstantTest.java - test/compiler/intrinsics/mathexact/RepeatTest.java Changeset: 1d1ea10fe09f Author: mgerdin Date: 2013-10-15 13:56 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/1d1ea10fe09f 8015255: NPG: Don't waste fragment at the end of a VirtualSpaceNode before retiring it. Summary: Chunk up the last piece of committed memory in a VSN when getting a new one. Reviewed-by: stefank, jmasa ! src/share/vm/memory/metaspace.cpp ! src/share/vm/prims/jni.cpp Changeset: 91a88c8450f4 Author: mgerdin Date: 2013-10-18 09:31 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/91a88c8450f4 8026698: Incorrect error handling in Metaspace::allocate Reviewed-by: stefank, jwilhelm ! src/share/vm/memory/metaspace.cpp Changeset: a1b05d4a6fd0 Author: stefank Date: 2013-10-21 09:34 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/a1b05d4a6fd0 8026781: Add missing test to exercise -XX:+UseLargePagesInMetaspace Reviewed-by: mgerdin, brutisso + test/gc/TestSystemGC.java Changeset: 3dd24766da44 Author: stefank Date: 2013-10-21 01:04 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/3dd24766da44 Merge Changeset: 2fab5b7e6140 Author: ehelin Date: 2013-10-21 14:20 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/2fab5b7e6140 8025834: NPE in Parallel Scavenge with -XX:+CheckUnhandledOops Reviewed-by: coleenp, mgerdin, sspitsyn ! src/share/vm/prims/jvmtiImpl.cpp Changeset: c7f403b05168 Author: sjohanss Date: 2013-10-22 11:50 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/c7f403b05168 8026848: -XX:+G1SummarizeRSetStats can result in wrong exit code and crash Summary: Changed the use of %d to SIZE_FORMAT macro in format string when printing size_t values. Reviewed-by: stefank, ehelin ! src/share/vm/gc_implementation/g1/g1RemSetSummary.cpp Changeset: 0823c8bac468 Author: jcoomes Date: 2013-10-22 12:03 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/0823c8bac468 Merge Changeset: 1b422ef5288a Author: tschatzl Date: 2013-10-23 10:23 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/1b422ef5288a 8025728: Missing volatile specifier for field G1AllocRegion::_alloc_region Summary: The field G1AllocRegion::_alloc_region needs to be declared volatile as it is used with that intention. Otherwise the compiler may generate the code that reloads the value which might have changed in the meantime, leading to spurious crashes. Reviewed-by: iveresov, simonis, tschatzl Contributed-by: Axel Siebenborn ! src/share/vm/gc_implementation/g1/g1AllocRegion.hpp Changeset: 0dcdec729cda Author: jcoomes Date: 2013-10-25 08:38 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/0dcdec729cda Merge Changeset: 82a9cdbf683e Author: amurillo Date: 2013-10-25 13:29 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/82a9cdbf683e Merge ! src/share/vm/services/diagnosticCommand.cpp - test/compiler/intrinsics/mathexact/CondTest.java - test/compiler/intrinsics/mathexact/ConstantTest.java - test/compiler/intrinsics/mathexact/LoadTest.java - test/compiler/intrinsics/mathexact/LoopDependentTest.java - test/compiler/intrinsics/mathexact/NonConstantTest.java - test/compiler/intrinsics/mathexact/RepeatTest.java Changeset: bde83ddf920c Author: amurillo Date: 2013-10-25 13:29 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/bde83ddf920c Added tag hs25-b56 for changeset 82a9cdbf683e ! .hgtags Changeset: e006d2e25bc7 Author: dholmes Date: 2013-10-24 20:47 -0400 URL: http://hg.openjdk.java.net/graal/graal/rev/e006d2e25bc7 8025673: [macosx] Disable X11 AWT toolkit Summary: Disable but not completely remove the XAWT and headless toolkits on Mac OS X Reviewed-by: dholmes Contributed-by: david.dehaven at oracle.com ! src/os/bsd/vm/os_bsd.cpp Changeset: 913a35723a0a Author: katleman Date: 2013-10-28 16:02 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/913a35723a0a Merge Changeset: 7fd913010dbb Author: katleman Date: 2013-10-29 14:56 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/7fd913010dbb Merge Changeset: ddc3758f68db Author: cl Date: 2013-10-31 12:36 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/ddc3758f68db Added tag jdk8-b114 for changeset 7fd913010dbb ! .hgtags Changeset: f94a9f0746d8 Author: amurillo Date: 2013-10-25 13:43 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/f94a9f0746d8 8027173: new hotspot build - hs25-b57 Reviewed-by: jcoomes ! make/hotspot_version Changeset: e64f1fe9756b Author: farvidsson Date: 2013-10-24 10:02 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/e64f1fe9756b 8024423: JVMTI: GetLoadedClasses doesn't enumerate anonymous classes Summary: Rewrite of the getLoadedClasses() method implementation to include anonymous classes. Reviewed-by: coleenp, sspitsyn ! src/share/vm/classfile/classLoaderData.cpp ! src/share/vm/classfile/classLoaderData.hpp ! src/share/vm/oops/instanceKlass.cpp ! src/share/vm/prims/jvmtiGetLoadedClasses.cpp Changeset: d70a665e25d7 Author: iklam Date: 2013-10-24 22:19 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/d70a665e25d7 8020753: JNI_CreateJavaVM on Mac OSX 10.9 Mavericks corrupts the callers stack size Summary: Use hard-coded DEFAULT_MAIN_THREAD_STACK_PAGES = 2048 for 10.9 Reviewed-by: dcubed, iveresov Contributed-by: gerard.ziemski at oracle.com ! src/os_cpu/bsd_x86/vm/os_bsd_x86.cpp Changeset: e4f478e7781b Author: jbachorik Date: 2013-10-25 09:07 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/e4f478e7781b 8027294: Prepare hotspot for non TOD based uptime counter Summary: Use HR timer when available for os::elapsed_counter() on linux/bsd. Add a new counter for the JVM uptime. Reviewed-by: dholmes, sla ! src/os/bsd/vm/os_bsd.cpp ! src/os/linux/vm/os_linux.cpp ! src/share/vm/services/jmm.h ! src/share/vm/services/management.cpp Changeset: a6177f601c64 Author: hseigel Date: 2013-10-25 11:05 -0400 URL: http://hg.openjdk.java.net/graal/graal/rev/a6177f601c64 8026822: metaspace/flags/maxMetaspaceSize throws OOM of unexpected type.java.lang.OutOfMemoryError: Compressed class space Summary: Incorporate chunk size when seeing if OutOfMemoryError was caused by Metaspace or Compressed class space. Reviewed-by: stefank, coleenp ! src/share/vm/memory/metaspace.cpp ! src/share/vm/memory/metaspace.hpp ! src/share/vm/memory/universe.cpp Changeset: 634715d59d9e Author: hseigel Date: 2013-10-25 11:13 -0400 URL: http://hg.openjdk.java.net/graal/graal/rev/634715d59d9e Merge Changeset: 209aa13ab8c0 Author: coleenp Date: 2013-10-25 15:19 -0400 URL: http://hg.openjdk.java.net/graal/graal/rev/209aa13ab8c0 8024927: Nashorn performance regression with CompressedOops Summary: Allocate compressed class space at end of Java heap. For small heap sizes, without CDS, save some space so compressed classes can have the same favorable compression as oops Reviewed-by: stefank, hseigel, goetz ! src/cpu/sparc/vm/macroAssembler_sparc.cpp ! src/cpu/sparc/vm/sparc.ad ! src/cpu/x86/vm/macroAssembler_x86.cpp ! src/share/vm/memory/metaspace.cpp ! src/share/vm/memory/metaspace.hpp ! src/share/vm/memory/universe.cpp ! src/share/vm/utilities/globalDefinitions.hpp + test/runtime/CompressedOops/CompressedClassPointers.java Changeset: b4aa8fc5d0d5 Author: ccheung Date: 2013-10-25 22:06 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/b4aa8fc5d0d5 Merge ! src/cpu/sparc/vm/macroAssembler_sparc.cpp ! src/cpu/sparc/vm/sparc.ad ! src/share/vm/memory/metaspace.cpp - test/compiler/intrinsics/mathexact/CondTest.java - test/compiler/intrinsics/mathexact/ConstantTest.java - test/compiler/intrinsics/mathexact/LoadTest.java - test/compiler/intrinsics/mathexact/LoopDependentTest.java - test/compiler/intrinsics/mathexact/NonConstantTest.java - test/compiler/intrinsics/mathexact/RepeatTest.java Changeset: 1a04de1aaedb Author: dsamersoff Date: 2013-10-28 21:41 +0400 URL: http://hg.openjdk.java.net/graal/graal/rev/1a04de1aaedb 8026950: Nits in agent ps_proc.c file breaks compilation of open hotspot Summary: Fixed two compilation-breaking nits Reviewed-by: sla, dholmes ! agent/src/os/bsd/ps_proc.c Changeset: 85730a185147 Author: ccheung Date: 2013-10-30 14:02 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/85730a185147 Merge Changeset: 292050e5d5ea Author: dholmes Date: 2013-10-24 00:33 -0400 URL: http://hg.openjdk.java.net/graal/graal/rev/292050e5d5ea 8026877: Error in opening JAR file when invalid jar specified with -Xbootclasspath/a on OpenJDK build Reviewed-by: coleenp, twisti ! src/share/vm/classfile/systemDictionary.hpp ! src/share/vm/runtime/thread.cpp Changeset: 066778844ed9 Author: jprovino Date: 2013-10-27 14:11 -0400 URL: http://hg.openjdk.java.net/graal/graal/rev/066778844ed9 Merge Changeset: f2f9139ccde9 Author: jprovino Date: 2013-10-30 16:06 -0400 URL: http://hg.openjdk.java.net/graal/graal/rev/f2f9139ccde9 Merge Changeset: a007575ea726 Author: vladidan Date: 2013-10-30 16:31 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/a007575ea726 Merge Changeset: 3b3133d93fb6 Author: brutisso Date: 2013-10-28 13:27 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/3b3133d93fb6 8027132: Print deprecation warning message for the flags controlling the CMS foreground collector Reviewed-by: stefank, ehelin, ysr, tschatzl ! src/share/vm/runtime/arguments.cpp + test/gc/startup_warnings/TestCMSForegroundFlags.java Changeset: 6d965678f21e Author: ehelin Date: 2013-10-31 21:20 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/6d965678f21e Merge Changeset: bd3237e0e18d Author: twisti Date: 2013-10-24 16:23 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/bd3237e0e18d 8026328: Setting a breakpoint on invokedynamic crashes the JVM Reviewed-by: jrose, roland ! src/cpu/sparc/vm/cppInterpreter_sparc.cpp ! src/cpu/sparc/vm/templateInterpreter_sparc.cpp ! src/cpu/sparc/vm/templateTable_sparc.cpp ! src/cpu/x86/vm/cppInterpreter_x86.cpp ! src/cpu/x86/vm/templateInterpreter_x86_32.cpp ! src/cpu/x86/vm/templateInterpreter_x86_64.cpp ! src/cpu/x86/vm/templateTable_x86_32.cpp ! src/cpu/x86/vm/templateTable_x86_64.cpp ! src/cpu/zero/vm/cppInterpreter_zero.cpp ! src/cpu/zero/vm/globals_zero.hpp ! src/share/vm/interpreter/abstractInterpreter.hpp ! src/share/vm/interpreter/cppInterpreter.hpp ! src/share/vm/interpreter/interpreter.cpp ! src/share/vm/interpreter/templateInterpreter.cpp ! src/share/vm/interpreter/templateInterpreter.hpp ! src/share/vm/interpreter/templateInterpreterGenerator.hpp ! src/share/vm/oops/method.cpp ! src/share/vm/runtime/handles.cpp Changeset: cbe8ba0fb8fc Author: twisti Date: 2013-10-24 16:26 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/cbe8ba0fb8fc Merge - test/compiler/intrinsics/mathexact/CondTest.java - test/compiler/intrinsics/mathexact/ConstantTest.java - test/compiler/intrinsics/mathexact/LoadTest.java - test/compiler/intrinsics/mathexact/LoopDependentTest.java - test/compiler/intrinsics/mathexact/NonConstantTest.java - test/compiler/intrinsics/mathexact/RepeatTest.java Changeset: f01788f13696 Author: adlertz Date: 2013-10-25 10:13 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/f01788f13696 8026940: assert(n->outcnt() != 0 || C->top() == n || n->is_Proj()) failed: No dead instructions after post-alloc Summary: Remove input to junk phi if they also become dead during post_allocate_copy_removal Reviewed-by: roland ! src/share/vm/opto/postaloc.cpp Changeset: 7ae254fd0b3c Author: adlertz Date: 2013-10-25 12:40 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/7ae254fd0b3c Merge Changeset: 6c2f07d1495f Author: roland Date: 2013-10-28 09:58 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/6c2f07d1495f 8027140: Assertion in compiler when running bigapps/Kitchensink/stability Summary: filter() code for TypeKlassPtr not moved when permgen removal was introduced Reviewed-by: twisti, iveresov ! src/share/vm/opto/type.cpp ! src/share/vm/opto/type.hpp Changeset: bfdb530cdffa Author: roland Date: 2013-10-28 12:21 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/bfdb530cdffa Merge Changeset: a196f1aaec86 Author: anoll Date: 2013-10-25 22:57 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/a196f1aaec86 8026949: -Xint flag prints wrong warning: Initialization of C1 thread failed (no space to run compilers) Summary: Exit compiler threads early during startup so that wrong error message is not printed Reviewed-by: iveresov, twisti ! src/share/vm/compiler/compileBroker.cpp + test/compiler/startup/StartupOutput.java Changeset: 8c16f426dbb2 Author: iveresov Date: 2013-10-28 15:16 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/8c16f426dbb2 Merge Changeset: fc1632f5021a Author: iveresov Date: 2013-10-28 17:32 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/fc1632f5021a Merge Changeset: a57a165b8296 Author: rbackman Date: 2013-10-28 08:34 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/a57a165b8296 8027353: Exact intrinsics: assert(n != NULL) failed: must not be null Reviewed-by: kvn, roland ! src/share/vm/opto/library_call.cpp ! test/compiler/intrinsics/mathexact/SubExactLConstantTest.java ! test/compiler/intrinsics/mathexact/SubExactLNonConstantTest.java Changeset: 60a32bb8ff99 Author: rbackman Date: 2013-10-30 13:14 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/60a32bb8ff99 8027444: mathExact: assert(i < _max) failed: oob: i=1, _max=1 Reviewed-by: duke ! src/share/vm/opto/loopTransform.cpp + test/compiler/intrinsics/mathexact/NestedMathExactTest.java Changeset: 4d3575d37a07 Author: iveresov Date: 2013-10-30 22:55 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/4d3575d37a07 8026735: Stream tests throw java.lang.IncompatibleClassChangeError Summary: Put a band-aid to disable CHA-based inlining for interfaces with default methods in C1 Reviewed-by: kvn, twisti ! src/share/vm/c1/c1_GraphBuilder.cpp ! src/share/vm/ci/ciInstanceKlass.cpp ! src/share/vm/ci/ciInstanceKlass.hpp + test/compiler/inlining/InlineDefaultMethod.java Changeset: 946a8294ab15 Author: iveresov Date: 2013-10-31 04:16 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/946a8294ab15 8024919: G1: SPECjbb2013 crashes due to a broken object reference Summary: Pass correct new value to post_barrer() in Unsafe.getAndSetObject() C1 intrinsic Reviewed-by: kvn, roland ! src/cpu/x86/vm/c1_LIRGenerator_x86.cpp Changeset: 2dcd0bd2920d Author: iveresov Date: 2013-10-31 14:54 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/2dcd0bd2920d Merge Changeset: 0836a3c28c6a Author: iveresov Date: 2013-10-31 15:04 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/0836a3c28c6a Merge Changeset: 3b32d287da89 Author: amurillo Date: 2013-11-01 08:26 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/3b32d287da89 Merge ! src/os/bsd/vm/os_bsd.cpp Changeset: afd012c940e4 Author: amurillo Date: 2013-11-01 08:26 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/afd012c940e4 Added tag hs25-b57 for changeset 3b32d287da89 ! .hgtags Changeset: e39b138b2518 Author: acorn Date: 2013-10-19 18:32 -0400 URL: http://hg.openjdk.java.net/graal/graal/rev/e39b138b2518 8026893: Push 8026365 to TL early and add test Reviewed-by: dcubed, kamg ! src/share/vm/classfile/verifier.cpp ! test/TEST.groups + test/runtime/8026365/InvokeSpecialAnonTest.java Changeset: 0e55a181cb08 Author: lana Date: 2013-10-28 12:25 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/0e55a181cb08 Merge - src/share/vm/memory/metablock.cpp - src/share/vm/memory/metablock.hpp - test/compiler/8013496/Test8013496.sh - test/gc/7168848/HumongousAlloc.java Changeset: ea1b8c643fc8 Author: lana Date: 2013-10-30 13:43 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/ea1b8c643fc8 Merge - test/compiler/intrinsics/mathexact/CondTest.java - test/compiler/intrinsics/mathexact/ConstantTest.java - test/compiler/intrinsics/mathexact/LoadTest.java - test/compiler/intrinsics/mathexact/LoopDependentTest.java - test/compiler/intrinsics/mathexact/NonConstantTest.java - test/compiler/intrinsics/mathexact/RepeatTest.java Changeset: 205834867346 Author: lana Date: 2013-10-31 16:31 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/205834867346 Merge Changeset: 9ebaac78a8a0 Author: amurillo Date: 2013-11-05 14:06 -0800 URL: http://hg.openjdk.java.net/graal/graal/rev/9ebaac78a8a0 Merge Changeset: 842b6ce4dfb4 Author: cl Date: 2013-11-07 08:16 -0800 URL: http://hg.openjdk.java.net/graal/graal/rev/842b6ce4dfb4 Added tag jdk8-b115 for changeset 9ebaac78a8a0 ! .hgtags Changeset: 5b84039ca739 Author: amurillo Date: 2013-11-01 08:35 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/5b84039ca739 8027580: new hotspot build - hs25-b58 Reviewed-by: jcoomes ! make/hotspot_version Changeset: ea79ab313e98 Author: mgerdin Date: 2013-10-30 15:35 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/ea79ab313e98 8027252: Crash in interpreter because get_unsigned_2_byte_index_at_bcp reads 4 bytes Summary: Use 2-byte loads to load indexes from the byte code stream to avoid out of bounds reads. Reviewed-by: coleenp, sspitsyn ! src/cpu/x86/vm/interp_masm_x86_32.cpp ! src/cpu/x86/vm/interp_masm_x86_64.cpp ! src/cpu/x86/vm/templateTable_x86_32.cpp ! src/cpu/x86/vm/templateTable_x86_64.cpp Changeset: fdd464c8d62e Author: acorn Date: 2013-10-30 09:11 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/fdd464c8d62e 8027304: Lambda: inheriting abstract + 1 default -> default, not ICCE Reviewed-by: hseigel, zgu ! src/share/vm/classfile/defaultMethods.cpp Changeset: 4fe7815b04f5 Author: acorn Date: 2013-10-30 09:26 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/4fe7815b04f5 Merge Changeset: c8fc12209830 Author: coleenp Date: 2013-10-31 14:11 -0400 URL: http://hg.openjdk.java.net/graal/graal/rev/c8fc12209830 8027616: Off by one error in putback for compressed oops nashorn performance improvement Summary: Should compare bounds greater than or equal 4G when deciding if shift is needed or CDS area + compressed class space are within 4G of each other. Reviewed-by: stefank, hseigel, zgu ! src/share/vm/memory/metaspace.cpp Changeset: 910026b800b8 Author: coleenp Date: 2013-11-01 10:32 -0400 URL: http://hg.openjdk.java.net/graal/graal/rev/910026b800b8 8026946: JvmtiEnv::SetBreakpoint and JvmtiEnv::ClearBreakpoint should use MethodHandle 8026948: JvmtiEnv::SetBreakpoint and JvmtiEnv::ClearBreakpoint might not work with anonymous classes Summary: Walk methods in breakpoints for marking on stack so they aren't deallocated by redefine classes. Use class_holder rather than class_loader to keep GC from reclaiming class owning the method. Reviewed-by: sspitsyn, ehelin, sla ! src/share/vm/classfile/metadataOnStackMark.cpp ! src/share/vm/prims/jvmtiImpl.cpp ! src/share/vm/prims/jvmtiImpl.hpp Changeset: 42790b7e4d48 Author: mgronlun Date: 2013-11-01 15:56 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/42790b7e4d48 Merge ! src/cpu/x86/vm/templateTable_x86_32.cpp ! src/cpu/x86/vm/templateTable_x86_64.cpp Changeset: f8b56489e455 Author: mgronlun Date: 2013-11-01 17:10 +0000 URL: http://hg.openjdk.java.net/graal/graal/rev/f8b56489e455 Merge Changeset: 04df110c8655 Author: mgronlun Date: 2013-11-02 20:56 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/04df110c8655 Merge Changeset: 208ebea980f8 Author: roland Date: 2013-11-04 21:59 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/208ebea980f8 8027445: SIGSEGV at TestFloatingDecimal.testAppendToDouble()I Summary: String.equals() intrinsic shouldn't use integer length input in pointer arithmetic without an i2l. Reviewed-by: kvn, twisti ! src/cpu/sparc/vm/sparc.ad + test/compiler/intrinsics/stringequals/TestStringEqualsBadLength.java Changeset: e428d5e768e3 Author: rbackman Date: 2013-11-04 10:44 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/e428d5e768e3 8027622: java.time.Instant.create failing since hs25-b56 Reviewed-by: kvn, iveresov ! src/share/vm/opto/compile.cpp + test/compiler/intrinsics/mathexact/CompareTest.java Changeset: a905d33ce13a Author: iveresov Date: 2013-11-05 00:59 -0800 URL: http://hg.openjdk.java.net/graal/graal/rev/a905d33ce13a 8027751: C1 crashes in Weblogic with G1 enabled Summary: Keep T_OBJECT operands in registers for logical operations on x64 Reviewed-by: kvn, roland ! src/share/vm/c1/c1_LinearScan.cpp + test/compiler/regalloc/C1ObjectSpillInLogicOp.java Changeset: 94a83e0f9ce1 Author: iveresov Date: 2013-11-05 01:57 -0800 URL: http://hg.openjdk.java.net/graal/graal/rev/94a83e0f9ce1 8017065: C2 allows safepoint checks to leak into G1 pre-barriers Summary: Make all raw loads strictly respect control dependencies, make sure RCE doesn't move raw loads, add verification of G1 pre-barriers. Reviewed-by: kvn, roland ! src/share/vm/opto/compile.cpp ! src/share/vm/opto/compile.hpp ! src/share/vm/opto/loopTransform.cpp ! src/share/vm/opto/memnode.hpp Changeset: 613e6a6fc328 Author: iveresov Date: 2013-11-05 02:29 -0800 URL: http://hg.openjdk.java.net/graal/graal/rev/613e6a6fc328 Merge ! src/share/vm/opto/compile.cpp Changeset: be525e91f65b Author: mikael Date: 2013-11-06 06:51 -0800 URL: http://hg.openjdk.java.net/graal/graal/rev/be525e91f65b 8026775: nsk/jvmti/RedefineClasses/StressRedefine crashes due to EXCEPTION_ACCESS_VIOLATION Summary: Uncommon trap blob did not bang all the stack shadow pages Reviewed-by: kvn, twisti, iveresov, jrose ! src/cpu/sparc/vm/macroAssembler_sparc.cpp ! src/cpu/x86/vm/macroAssembler_x86.cpp ! src/share/vm/asm/assembler.cpp + test/compiler/uncommontrap/UncommonTrapStackBang.java Changeset: 53662b2f1d68 Author: drchase Date: 2013-11-07 10:02 -0500 URL: http://hg.openjdk.java.net/graal/graal/rev/53662b2f1d68 Merge Changeset: e510dfdec6dd Author: amurillo Date: 2013-11-08 07:02 -0800 URL: http://hg.openjdk.java.net/graal/graal/rev/e510dfdec6dd Merge Changeset: 52b076e6ffae Author: amurillo Date: 2013-11-08 07:02 -0800 URL: http://hg.openjdk.java.net/graal/graal/rev/52b076e6ffae Added tag hs25-b58 for changeset e510dfdec6dd ! .hgtags Changeset: aec3226be72d Author: cl Date: 2013-11-14 09:04 -0800 URL: http://hg.openjdk.java.net/graal/graal/rev/aec3226be72d Added tag jdk8-b116 for changeset 52b076e6ffae ! .hgtags Changeset: 20c72bec2707 Author: amurillo Date: 2013-11-08 07:13 -0800 URL: http://hg.openjdk.java.net/graal/graal/rev/20c72bec2707 8028061: new hotspot build - hs25-b59 Reviewed-by: jcoomes ! make/hotspot_version Changeset: 9d8b29a0548c Author: mgerdin Date: 2013-11-08 16:48 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/9d8b29a0548c 8027237: New tests on ReservedSpace/VirtualSpace classes Summary: Three tests added: 1) test stressing VirtualSpace by resizing it constantly 2) test running unit tests in several threads 3) test checking protected area in ReservedHeapSpace class Reviewed-by: stefank, zgu Contributed-by: aleksey.timofeev at oracle.com ! src/share/vm/prims/whitebox.cpp + test/runtime/memory/ReadFromNoaccessArea.java + test/runtime/memory/RunUnitTestsConcurrently.java + test/runtime/memory/StressVirtualSpaceResize.java ! test/testlibrary/whitebox/sun/hotspot/WhiteBox.java Changeset: 19f8a5d7600b Author: mgerdin Date: 2013-11-08 23:49 +0000 URL: http://hg.openjdk.java.net/graal/graal/rev/19f8a5d7600b Merge Changeset: fce21ac5968d Author: acorn Date: 2013-11-13 07:31 -0800 URL: http://hg.openjdk.java.net/graal/graal/rev/fce21ac5968d 8027229: ICCE expected for >=2 maximally specific default methods. Summary: Need to process defaults for interfaces for invokespecial Reviewed-by: lfoltan, hseigel, coleenp, jrose ! src/share/vm/classfile/classFileParser.cpp ! src/share/vm/classfile/defaultMethods.cpp ! src/share/vm/interpreter/linkResolver.cpp ! src/share/vm/interpreter/linkResolver.hpp ! src/share/vm/oops/klassVtable.cpp Changeset: 41cb10cbfb3c Author: coleenp Date: 2013-11-13 16:42 -0500 URL: http://hg.openjdk.java.net/graal/graal/rev/41cb10cbfb3c 8025937: assert(existing_f1 == NULL || existing_f1 == f1) failed: illegal field change Summary: Create extra constant pool cache entries for invokespecial/InterfaceMethodref to hold the alternate resolution. Reviewed-by: jrose, lfoltan, hseigel ! src/share/vm/interpreter/rewriter.cpp ! src/share/vm/interpreter/rewriter.hpp ! src/share/vm/oops/cpCache.cpp ! src/share/vm/oops/cpCache.hpp Changeset: 4288e54fd145 Author: jwilhelm Date: 2013-10-21 18:51 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/4288e54fd145 8026851: Remove unnecessary code in GenRemSet Summary: Removed the GenRemSet::rem_set_name() since we only have one remset. Reviewed-by: stefank, mgerdin, tschatzl ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.cpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.hpp ! src/share/vm/memory/collectorPolicy.cpp ! src/share/vm/memory/collectorPolicy.hpp Changeset: 3aee6bc29547 Author: jwilhelm Date: 2013-10-21 18:52 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/3aee6bc29547 8026852: Use restricted_align_down in collector policy code Summary: Moved restricted_align_down to globalDefinitions and renamed it align_size_down_bounded Reviewed-by: stefank, mgerdin, tschatzl ! src/share/vm/memory/collectorPolicy.cpp ! src/share/vm/memory/metaspace.cpp ! src/share/vm/utilities/globalDefinitions.hpp Changeset: 46d7652b223c Author: jwilhelm Date: 2013-10-21 18:56 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/46d7652b223c 8026853: Prepare GC code for collector policy regression fix Summary: Cleanup related to the NewSize and MaxNewSize bugs Reviewed-by: tschatzl, jcoomes, ehelin ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.hpp ! src/share/vm/gc_implementation/g1/g1RemSet.cpp ! src/share/vm/gc_implementation/parallelScavenge/asPSOldGen.cpp ! src/share/vm/gc_implementation/parallelScavenge/asPSYoungGen.cpp ! src/share/vm/gc_implementation/parallelScavenge/parallelScavengeHeap.hpp ! src/share/vm/gc_implementation/parallelScavenge/psAdaptiveSizePolicy.cpp ! src/share/vm/memory/collectorPolicy.cpp ! src/share/vm/memory/collectorPolicy.hpp ! src/share/vm/memory/genCollectedHeap.cpp ! src/share/vm/memory/genCollectedHeap.hpp ! src/share/vm/memory/universe.cpp ! src/share/vm/runtime/arguments.cpp Changeset: 8f07aa079343 Author: jwilhelm Date: 2013-11-01 17:09 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/8f07aa079343 8016309: assert(eden_size > 0 && survivor_size > 0) failed: just checking 7057939: jmap shows MaxNewSize=4GB when Java is using parallel collector Summary: Major cleanup of the collectorpolicy classes Reviewed-by: tschatzl, jcoomes ! src/share/vm/gc_implementation/concurrentMarkSweep/cmsCollectorPolicy.cpp ! src/share/vm/gc_implementation/concurrentMarkSweep/cmsCollectorPolicy.hpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.cpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.hpp ! src/share/vm/gc_implementation/g1/heapRegion.cpp ! src/share/vm/gc_implementation/parallelScavenge/adjoiningGenerations.cpp ! src/share/vm/gc_implementation/parallelScavenge/adjoiningGenerations.hpp ! src/share/vm/gc_implementation/parallelScavenge/asPSOldGen.cpp ! src/share/vm/gc_implementation/parallelScavenge/asPSYoungGen.cpp + src/share/vm/gc_implementation/parallelScavenge/generationSizer.cpp ! src/share/vm/gc_implementation/parallelScavenge/generationSizer.hpp ! src/share/vm/gc_implementation/parallelScavenge/parallelScavengeHeap.cpp ! src/share/vm/gc_implementation/parallelScavenge/parallelScavengeHeap.hpp ! src/share/vm/gc_implementation/parallelScavenge/psAdaptiveSizePolicy.cpp ! src/share/vm/gc_implementation/parallelScavenge/psAdaptiveSizePolicy.hpp ! src/share/vm/gc_implementation/parallelScavenge/psYoungGen.cpp ! src/share/vm/gc_interface/collectedHeap.cpp ! src/share/vm/memory/collectorPolicy.cpp ! src/share/vm/memory/collectorPolicy.hpp ! src/share/vm/memory/defNewGeneration.cpp ! src/share/vm/memory/genCollectedHeap.cpp ! src/share/vm/memory/sharedHeap.cpp ! src/share/vm/memory/universe.cpp ! src/share/vm/prims/whitebox.cpp ! src/share/vm/runtime/arguments.cpp ! test/gc/arguments/TestMaxHeapSizeTools.java + test/gc/arguments/TestMaxNewSize.java Changeset: 610be0309a79 Author: amurillo Date: 2013-11-02 13:02 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/610be0309a79 Merge ! src/share/vm/memory/metaspace.cpp ! src/share/vm/memory/universe.cpp ! src/share/vm/utilities/globalDefinitions.hpp Changeset: 28674af341ac Author: tschatzl Date: 2013-11-07 15:17 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/28674af341ac 8027756: assert(!hr->isHumongous()) failed: code root in humongous region? Summary: Change checks for isHumongous() to continuesHumongous() as installing a code root for a humongous object is valid, but not for continuations of humongous objects. Cleaned up asserts. Reviewed-by: jmasa, tamao ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/heapRegion.cpp ! src/share/vm/gc_implementation/g1/heapRegionRemSet.cpp + test/gc/g1/TestHumongousCodeCacheRoots.java Changeset: 40b8c6bad703 Author: jmasa Date: 2013-10-16 15:14 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/40b8c6bad703 8024954: CMS: CMSClassUnloadingMaxInterval is not implemented correctly. This change is also part of the fix for 8024483. Reviewed-by: mgerdin, brutisso, tschatzl Contributed-by: jwha at google.com ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp Changeset: 592d8b01fedd Author: jmasa Date: 2013-11-08 06:14 -0800 URL: http://hg.openjdk.java.net/graal/graal/rev/592d8b01fedd 8024483: assertion failure: (!mirror_alive || loader_alive) failed: Reviewed-by: brutisso, tschatzl, mgerdin ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp Changeset: 3ad2b68d107e Author: jwilhelm Date: 2013-11-10 00:07 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/3ad2b68d107e 8027911: Assertion in the collector policy when running gc/arguments/TestMaxNewSize.java Summary: Update NewSize when _initial_gen0_size is changed Reviewed-by: tschatzl, brutisso ! src/share/vm/memory/collectorPolicy.cpp Changeset: 236cecd9ec97 Author: jwilhelm Date: 2013-11-11 13:50 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/236cecd9ec97 8028093: Initial young size is smaller than minimum young size Summary: Remove min_gen1_size argument from adjust_gen0_sizes() Reviewed-by: tschatzl, brutisso ! src/share/vm/memory/collectorPolicy.cpp ! src/share/vm/memory/collectorPolicy.hpp Changeset: bde526e3667e Author: jwilhelm Date: 2013-11-11 05:05 -0800 URL: http://hg.openjdk.java.net/graal/graal/rev/bde526e3667e Merge Changeset: 11b116661830 Author: mgerdin Date: 2013-11-11 16:20 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/11b116661830 Merge ! src/share/vm/memory/metaspace.cpp Changeset: ee527493b36d Author: sjohanss Date: 2013-11-08 17:46 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/ee527493b36d 8027960: Assertion assert(end >= start) failed during nightly testing on solaris Summary: Needed to update _space_alignment in generation sizer to ensure correct sizing of spaces. Reviewed-by: jmasa, tschatzl ! src/share/vm/gc_implementation/parallelScavenge/generationSizer.cpp Changeset: 755c423791ab Author: ehelin Date: 2013-11-14 21:05 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/755c423791ab Merge ! src/share/vm/prims/whitebox.cpp Changeset: e2509677809c Author: vlivanov Date: 2013-11-08 01:13 -0800 URL: http://hg.openjdk.java.net/graal/graal/rev/e2509677809c 8023037: Race between ciEnv::register_method and nmethod::make_not_entrant_or_zombie Reviewed-by: kvn, iveresov ! src/cpu/sparc/vm/sharedRuntime_sparc.cpp ! src/share/vm/ci/ciEnv.cpp ! src/share/vm/code/nmethod.cpp ! src/share/vm/runtime/globals.hpp Changeset: 83c8f6f4ab09 Author: drchase Date: 2013-11-08 14:19 -0800 URL: http://hg.openjdk.java.net/graal/graal/rev/83c8f6f4ab09 Merge Changeset: 1dcea64e9f00 Author: kvn Date: 2013-11-11 11:53 -0800 URL: http://hg.openjdk.java.net/graal/graal/rev/1dcea64e9f00 8024830: SEGV in org.apache.lucene.codecs.compressing.CompressingTermVectorsReader.get Summary: Exclude last input argument's stack slots from vector's spilling masks. Reviewed-by: iveresov ! src/share/vm/opto/matcher.cpp Changeset: 78da3894b86f Author: anoll Date: 2013-11-12 09:32 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/78da3894b86f 8027593: performance drop with constrained codecache starting with hs25 b111 Summary: Fixed proper sweeping of small code cache sizes Reviewed-by: kvn, iveresov ! src/share/vm/code/nmethod.cpp ! src/share/vm/compiler/compileBroker.cpp ! src/share/vm/compiler/compileBroker.hpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/sweeper.cpp ! src/share/vm/runtime/sweeper.hpp Changeset: 144b23411b51 Author: roland Date: 2013-11-12 13:58 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/144b23411b51 8027632: assert(xtype->klass_is_exact()) failed: Should be exact at graphKit.cpp Summary: receiver type collected by profiling for default method may be interface Reviewed-by: kvn, iveresov ! src/share/vm/c1/c1_GraphBuilder.cpp Changeset: f675976a61e7 Author: rbackman Date: 2013-11-12 13:47 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/f675976a61e7 8028198: SIGSEGV in PhaseIdealLoop::build_loop_late_post Reviewed-by: iveresov, kvn ! src/share/vm/opto/loopopts.cpp + test/compiler/intrinsics/mathexact/SplitThruPhiTest.java Changeset: b957c650babb Author: rbackman Date: 2013-11-12 14:52 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/b957c650babb 8028207: assert(_outcnt==1) failed: not unique in compile.cpp Reviewed-by: iveresov, kvn ! src/share/vm/opto/mathexactnode.hpp + test/compiler/intrinsics/mathexact/GVNTest.java Changeset: e6ba215af802 Author: roland Date: 2013-11-13 09:45 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/e6ba215af802 8027631: "unexpected profiling mismatch" error with new type profiling Summary: inlined method handle calls can call methods with different signatures Reviewed-by: kvn, iveresov ! src/share/vm/c1/c1_LIRGenerator.cpp ! src/share/vm/c1/c1_LIRGenerator.hpp + test/compiler/profiling/TestUnexpectedProfilingMismatch.java Changeset: 924c32982a12 Author: roland Date: 2013-11-13 01:50 -0800 URL: http://hg.openjdk.java.net/graal/graal/rev/924c32982a12 Merge Changeset: 6e1826d5c23e Author: roland Date: 2013-11-13 13:45 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/6e1826d5c23e 8027572: assert(r != 0) failed: invalid Summary: null classes should be expected in profiles with conflicts Reviewed-by: kvn, iveresov ! src/share/vm/ci/ciMethodData.hpp ! src/share/vm/oops/instanceKlass.cpp ! src/share/vm/oops/methodData.cpp ! src/share/vm/oops/methodData.hpp + test/compiler/profiling/unloadingconflict/B.java + test/compiler/profiling/unloadingconflict/TestProfileConflictClassUnloading.java Changeset: e74074c34312 Author: vlivanov Date: 2013-11-14 09:14 -0800 URL: http://hg.openjdk.java.net/graal/graal/rev/e74074c34312 8028159: C2: compiler stack overflow during inlining of @ForceInline methods Reviewed-by: roland, kvn ! src/share/vm/c1/c1_globals.hpp ! src/share/vm/opto/bytecodeInfo.cpp ! src/share/vm/opto/callGenerator.cpp ! src/share/vm/runtime/globals.hpp Changeset: df0df745224c Author: drchase Date: 2013-11-14 15:58 -0500 URL: http://hg.openjdk.java.net/graal/graal/rev/df0df745224c Merge Changeset: 6f206b5d258f Author: drchase Date: 2013-11-14 13:38 -0800 URL: http://hg.openjdk.java.net/graal/graal/rev/6f206b5d258f Merge ! src/share/vm/runtime/arguments.cpp Changeset: c78d517c7ea4 Author: amurillo Date: 2013-11-15 07:50 -0800 URL: http://hg.openjdk.java.net/graal/graal/rev/c78d517c7ea4 Merge Changeset: f573d00213b7 Author: amurillo Date: 2013-11-15 07:50 -0800 URL: http://hg.openjdk.java.net/graal/graal/rev/f573d00213b7 Added tag hs25-b59 for changeset c78d517c7ea4 ! .hgtags Changeset: 096c224171c4 Author: Doug Simon Date: 2013-11-20 00:10 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/096c224171c4 Merge with http://hg.openjdk.java.net/hsx/hsx25/hotspot/ ! .hgtags ! make/Makefile ! make/bsd/Makefile ! make/bsd/makefiles/buildtree.make ! make/bsd/makefiles/gcc.make ! make/bsd/makefiles/vm.make ! make/defs.make ! make/hotspot_version ! make/windows/makefiles/fastdebug.make ! src/cpu/sparc/vm/sharedRuntime_sparc.cpp ! src/cpu/sparc/vm/templateInterpreter_sparc.cpp ! src/cpu/sparc/vm/templateTable_sparc.cpp ! src/cpu/x86/vm/assembler_x86.cpp ! src/cpu/x86/vm/c1_Runtime1_x86.cpp ! src/cpu/x86/vm/globals_x86.hpp ! src/cpu/x86/vm/interp_masm_x86_64.cpp ! src/cpu/x86/vm/interp_masm_x86_64.hpp ! src/cpu/x86/vm/macroAssembler_x86.cpp ! src/cpu/x86/vm/templateInterpreter_x86.hpp ! src/cpu/x86/vm/templateInterpreter_x86_64.cpp ! src/cpu/x86/vm/templateTable_x86_64.cpp ! src/os/bsd/vm/os_bsd.cpp ! src/os/linux/vm/os_linux.cpp ! src/share/vm/c1/c1_Compiler.cpp ! src/share/vm/c1/c1_GraphBuilder.cpp ! src/share/vm/c1/c1_LIRGenerator.cpp ! src/share/vm/c1/c1_Runtime1.cpp ! src/share/vm/c1/c1_globals.hpp ! src/share/vm/ci/ciEnv.cpp ! src/share/vm/ci/ciEnv.hpp ! src/share/vm/ci/ciInstanceKlass.cpp ! src/share/vm/ci/ciInstanceKlass.hpp ! src/share/vm/ci/ciKlass.cpp ! src/share/vm/ci/ciMethod.cpp ! src/share/vm/classfile/classFileParser.cpp ! src/share/vm/classfile/defaultMethods.cpp ! src/share/vm/classfile/javaClasses.cpp ! src/share/vm/classfile/systemDictionary.cpp ! src/share/vm/classfile/systemDictionary.hpp ! src/share/vm/classfile/vmSymbols.hpp ! src/share/vm/code/codeBlob.cpp ! src/share/vm/code/codeBlob.hpp ! src/share/vm/code/dependencies.cpp ! src/share/vm/code/nmethod.cpp ! src/share/vm/compiler/abstractCompiler.hpp ! src/share/vm/compiler/compileBroker.cpp ! src/share/vm/compiler/compileBroker.hpp ! src/share/vm/gc_implementation/g1/g1AllocRegion.hpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.inline.hpp ! src/share/vm/gc_implementation/g1/heapRegion.cpp ! src/share/vm/gc_interface/collectedHeap.cpp ! src/share/vm/gc_interface/collectedHeap.hpp ! src/share/vm/graal/graalCompiler.cpp ! src/share/vm/graal/graalEnv.cpp ! src/share/vm/interpreter/abstractInterpreter.hpp ! src/share/vm/interpreter/interpreter.cpp ! src/share/vm/interpreter/linkResolver.cpp ! src/share/vm/interpreter/linkResolver.hpp ! src/share/vm/interpreter/rewriter.cpp ! src/share/vm/interpreter/templateInterpreter.cpp ! src/share/vm/interpreter/templateInterpreterGenerator.hpp - src/share/vm/memory/metablock.cpp - src/share/vm/memory/metablock.hpp ! src/share/vm/memory/universe.cpp ! src/share/vm/oops/constantPool.cpp ! src/share/vm/oops/constantPool.hpp ! src/share/vm/oops/instanceKlass.cpp ! src/share/vm/oops/instanceKlass.hpp ! src/share/vm/oops/method.cpp ! src/share/vm/oops/method.hpp ! src/share/vm/oops/methodData.cpp ! src/share/vm/oops/methodData.hpp ! src/share/vm/opto/bytecodeInfo.cpp ! src/share/vm/opto/c2compiler.hpp ! src/share/vm/opto/callGenerator.hpp ! src/share/vm/opto/graphKit.cpp ! src/share/vm/opto/runtime.cpp ! src/share/vm/prims/jni.cpp ! src/share/vm/prims/jvm.cpp ! src/share/vm/prims/jvm.h ! src/share/vm/prims/jvmtiEnv.cpp ! src/share/vm/prims/jvmtiImpl.cpp ! src/share/vm/prims/methodHandles.cpp ! src/share/vm/prims/nativeLookup.cpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/java.cpp ! src/share/vm/runtime/reflectionUtils.cpp ! src/share/vm/runtime/sweeper.cpp ! src/share/vm/runtime/thread.cpp ! src/share/vm/runtime/thread.hpp ! src/share/vm/runtime/vmStructs.cpp ! src/share/vm/shark/sharkCompiler.cpp ! src/share/vm/utilities/globalDefinitions.hpp ! src/share/vm/utilities/ostream.cpp ! src/share/vm/utilities/vmError.cpp - test/compiler/8013496/Test8013496.sh - test/compiler/intrinsics/mathexact/CondTest.java - test/compiler/intrinsics/mathexact/ConstantTest.java - test/compiler/intrinsics/mathexact/LoadTest.java - test/compiler/intrinsics/mathexact/LoopDependentTest.java - test/compiler/intrinsics/mathexact/NonConstantTest.java - test/gc/7168848/HumongousAlloc.java Changeset: ec3e4f35e466 Author: Doug Simon Date: 2013-11-20 15:58 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/ec3e4f35e466 disabled argument/parameter/return value profiling in GRAALVM until issue with MethodData related crashes in interpreter are resolved ! src/cpu/x86/vm/globals_x86.hpp ! src/share/vm/code/nmethod.hpp ! src/share/vm/oops/methodData.cpp Changeset: 514e809bd97d Author: Doug Simon Date: 2013-11-20 15:58 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/514e809bd97d Merge. - graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotHostLoweringProvider.java Changeset: 77fbf02f701c Author: Doug Simon Date: 2013-11-20 19:27 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/77fbf02f701c re-enabled protection against recursive Graal compilation requests with Graal specific _graal_compiling field in JavaThread ! src/share/vm/compiler/compileBroker.cpp ! src/share/vm/graal/graalCompiler.cpp ! src/share/vm/runtime/thread.cpp ! src/share/vm/runtime/thread.hpp From duboscq at ssw.jku.at Wed Nov 20 13:36:11 2013 From: duboscq at ssw.jku.at (Gilles Duboscq) Date: Wed, 20 Nov 2013 22:36:11 +0100 Subject: question about bci in LIRFrameState for DeoptimizeOp In-Reply-To: References: <721F36C5-C300-46A6-B0D8-4153313F57C8@oracle.com> Message-ID: Since guards are scheduled early, in your example i would guess they are indeed before the side effect. You can have a look at this paper: http://design.cs.iastate.edu/vmil/2013/papers/p04-Duboscq.pdf it contains information about how we handle deoptimization in Graal and about how we use it for exceptional control-flow (which is probably also of interest in the HSAIL runtime context). Why are you looking at the deoptimization exactly? Do you have an idea already about how you would handle them in HSAIL runtime? -Gilles On Wed, Nov 20, 2013 at 10:15 PM, Thomas Wuerthinger < thomas.wuerthinger at oracle.com> wrote: > I think the guards for the array access might have been moved before the > field store. Can you check in the machine code whether the deoptimization > is indeed *after* the field store? - thomas > > On 20 Nov 2013, at 22:08, Deneau, Tom wrote: > > > Thomas -- > > > > I retried this experiment with a java snippet that I thought would have > a side effect, incrementing a field > > public int intFromArrayLonger(int[] ary, int idx) { > > dummyField++; > > return ary[idx]; > > } > > > > But I still saw a info.bci of 0. > > > > -- Tom D > > > > > > > > -----Original Message----- > > From: Thomas Wuerthinger [mailto:thomas.wuerthinger at oracle.com] > > Sent: Wednesday, November 20, 2013 2:40 PM > > To: Deneau, Tom > > Cc: graal-dev at openjdk.java.net > > Subject: Re: question about bci in LIRFrameState for DeoptimizeOp > > > > Graal understands that it can safely replay bytecodes without side > effects. Therefore the target bci of a deoptimization will reflect the last > side effecting instruction (or the beginning of the method if no such > instruction exists). Gilles wrote a paper describing in more details how > deoptimization works in Graal and we will publish it shortly as part of the > Graal documentation. - thomas > > > > On 20 Nov 2013, at 21:17, Deneau, Tom wrote: > > > >> I was looking at the AMD64DeoptimizeOp.emitCode routine which is > >> AMD64Call.directCall(tasm, masm, > >> tasm.foreignCalls.lookupForeignCall(UNCOMMON_TRAP), null, false, > >> info); > >> > >> When I look at the LIRFrameState info which is passed to UNCOMMON_TRAP, > the bci always seems to be 0. > >> Why is that? > >> > >> For example, compiling this small snippet thru AMD64 backend > >> public int intFromArray(int[] ary, int idx) { > >> return ary[idx]; > >> } > >> > >> with bytecodes > >> public int intFromArray(int[], int); > >> Code: > >> 0: aload_1 > >> 1: iload_2 > >> 2: iaload > >> 3: ireturn > >> > >> when I get to AMD64DeoptimizeOp.emitCode, I see info = "at > >> > com.oracle.graal.compiler.test.BasicTest2.intFromArray(BasicTest2.java:46) > [bci: 0] > >> |0 |1 |2 > >> locals: |- |v0|a |v1|i " > >> > >> I would have expected the bci in this case to be 2, referring to the > iaload instruction. > >> > >> -- Tom > >> > >> > > > > > > > > From doug.simon at oracle.com Wed Nov 20 13:54:43 2013 From: doug.simon at oracle.com (Doug Simon) Date: Wed, 20 Nov 2013 22:54:43 +0100 Subject: webrev for switch statement support in HSAIL backend In-Reply-To: <5DD1503F815BD14889DC81D28643E3A75788BC85@SATLEXDAG02.amd.com> References: <5DD1503F815BD14889DC81D28643E3A75788AB08@SATLEXDAG02.amd.com> <528C00C6.3000202@oracle.com> <5DD1503F815BD14889DC81D28643E3A75788BC85@SATLEXDAG02.amd.com> Message-ID: <5F330428-EE75-4C7A-A701-27549364D368@oracle.com> I?ve integrated your change and am pushing it through now. -Doug On Nov 20, 2013, at 8:08 PM, Venkatachalam, Vasanth wrote: > Doug, > > Answers inlined below. > > If there are no other changes required please commit the webrev, citing Vasanth Venkatachalam as the author, with the commit message: "Adds support to the HSAIL backend for handling Java switch constructs . > > Vasanth > > -----Original Message----- > From: graal-dev-bounces at openjdk.java.net [mailto:graal-dev-bounces at openjdk.java.net] On Behalf Of Doug Simon > Sent: Tuesday, November 19, 2013 6:23 PM > To: graal-dev at openjdk.java.net > Subject: Re: webrev for switch statement support in HSAIL backend > > graal/com.oracle.graal.asm.hsail/src/com/oracle/graal/asm/hsail/HSAILAssembler.java: > > + // Get a JNI reference handle to the object. > + long refHandle = OkraUtil.getRefHandle(obj); > > How does OkraUtil manage these handles? I hope it at least never creates more than one global JNI ref for any given object or has some way to release them when no longer needed. > >> [Vasanth] OkraUtil never creates more than one JNI ref for any given object. > This change isn't introducing anything new. This code has been in the assembler all along, we just extended it to remove the restriction that the Object passed as parameter to mov(Register reg, Object obj) must be an instance of Class. > > graal/com.oracle.graal.lir.hsail/src/com/oracle/graal/lir/hsail/HSAILControlFlow.java: > > + // The array of key constants used for the cases of this switch statement. > + @Use({CONST}) protected Constant[] keyConstants; > + // The branch target labels that correspond to each case. > + private final LabelRef[] keyTargets; > + private LabelRef defaultTarget; > + // The key of the switch. This will be compared with each of the keyConstants. > + @Alive({REG}) protected Value key; > + > + // Constructor. Called from the HSAILLIRGenerator.emitSequentialSwitch routine. > + public SwitchOp(Constant[] keyConstants, LabelRef[] keyTargets, LabelRef defaultTarget, Value key) { > > Java fields and methods should have javadoc comments instead of C++ style comments. > >>> [Vasanth] This was my oversight. I've updated the latest version of the webrev to use Javadoc comments. > > -Doug > > On 11/20/2013 12:25 AM, Venkatachalam, Vasanth wrote: >> Hi, >> >> I've submitted a webrev for handling switch constructs generated by Java bytecode. >> >> Please review at http://cr.openjdk.java.net/~tdeneau/webrev-switchsupport.00/webrev/ >> >> Notes: >> >> This webrev adds support for the IntegerSwitchNode. (Support for TypeSwitchNode may be added later.) >> >> The approach currently recommended for generating performant HSAIL code for Java switch statements is to generate a series of cascading compare and branch instructions (instead of doing a table switch).This is the approach that I have implemented here. >> >> I've added an additional enhancement to HSAILAssembler which is unrelated to the switch support. >> The routine mov(Register reg, Object obj) previously had a restriction that the Object parameter had to be an instance of Class. This restriction has been lifted. >> >> I ran this through the Eclipse 4.3 formatter and there weren't any file changes. >> >> Vasanth >> >> > > From tom.deneau at amd.com Wed Nov 20 14:27:01 2013 From: tom.deneau at amd.com (Deneau, Tom) Date: Wed, 20 Nov 2013 22:27:01 +0000 Subject: question about bci in LIRFrameState for DeoptimizeOp In-Reply-To: References: <721F36C5-C300-46A6-B0D8-4153313F57C8@oracle.com> Message-ID: Gilles -- Yes, the guards were scheduled early in this case, before the side effect. Will take a look at the paper, thanks. We are still in an early mode of exploring what information gets passed to the VM, and in what ways HSAIL can make use of that if a kernel gets an exception in one or more workitems. Eric Caspole may have more to add on this. -- Tom From: gilwooden at gmail.com [mailto:gilwooden at gmail.com] On Behalf Of Gilles Duboscq Sent: Wednesday, November 20, 2013 3:36 PM To: Thomas Wuerthinger Cc: Deneau, Tom; graal-dev at openjdk.java.net Subject: Re: question about bci in LIRFrameState for DeoptimizeOp Since guards are scheduled early, in your example i would guess they are indeed before the side effect. You can have a look at this paper: http://design.cs.iastate.edu/vmil/2013/papers/p04-Duboscq.pdf it contains information about how we handle deoptimization in Graal and about how we use it for exceptional control-flow (which is probably also of interest in the HSAIL runtime context). Why are you looking at the deoptimization exactly? Do you have an idea already about how you would handle them in HSAIL runtime? -Gilles On Wed, Nov 20, 2013 at 10:15 PM, Thomas Wuerthinger > wrote: I think the guards for the array access might have been moved before the field store. Can you check in the machine code whether the deoptimization is indeed *after* the field store? - thomas On 20 Nov 2013, at 22:08, Deneau, Tom > wrote: > Thomas -- > > I retried this experiment with a java snippet that I thought would have a side effect, incrementing a field > public int intFromArrayLonger(int[] ary, int idx) { > dummyField++; > return ary[idx]; > } > > But I still saw a info.bci of 0. > > -- Tom D > > > > -----Original Message----- > From: Thomas Wuerthinger [mailto:thomas.wuerthinger at oracle.com] > Sent: Wednesday, November 20, 2013 2:40 PM > To: Deneau, Tom > Cc: graal-dev at openjdk.java.net > Subject: Re: question about bci in LIRFrameState for DeoptimizeOp > > Graal understands that it can safely replay bytecodes without side effects. Therefore the target bci of a deoptimization will reflect the last side effecting instruction (or the beginning of the method if no such instruction exists). Gilles wrote a paper describing in more details how deoptimization works in Graal and we will publish it shortly as part of the Graal documentation. - thomas > > On 20 Nov 2013, at 21:17, Deneau, Tom > wrote: > >> I was looking at the AMD64DeoptimizeOp.emitCode routine which is >> AMD64Call.directCall(tasm, masm, >> tasm.foreignCalls.lookupForeignCall(UNCOMMON_TRAP), null, false, >> info); >> >> When I look at the LIRFrameState info which is passed to UNCOMMON_TRAP, the bci always seems to be 0. >> Why is that? >> >> For example, compiling this small snippet thru AMD64 backend >> public int intFromArray(int[] ary, int idx) { >> return ary[idx]; >> } >> >> with bytecodes >> public int intFromArray(int[], int); >> Code: >> 0: aload_1 >> 1: iload_2 >> 2: iaload >> 3: ireturn >> >> when I get to AMD64DeoptimizeOp.emitCode, I see info = "at >> com.oracle.graal.compiler.test.BasicTest2.intFromArray(BasicTest2.java:46) [bci: 0] >> |0 |1 |2 >> locals: |- |v0|a |v1|i " >> >> I would have expected the bci in this case to be 2, referring to the iaload instruction. >> >> -- Tom >> >> > > > From doug.simon at oracle.com Wed Nov 20 15:01:13 2013 From: doug.simon at oracle.com (doug.simon at oracle.com) Date: Wed, 20 Nov 2013 23:01:13 +0000 Subject: hg: graal/graal: 6 new changesets Message-ID: <20131120230136.5D12162721@hg.openjdk.java.net> Changeset: 4fcc7d778e0f Author: Bernhard Urban Date: 2013-11-20 20:32 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/4fcc7d778e0f MethodFilter: add documentation about comma seperator ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/MethodFilter.java Changeset: d1c929751642 Author: Bernhard Urban Date: 2013-11-20 16:30 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/d1c929751642 MemoryScheduleTest: add testcase for read block scheduling. add support to disable out_of_loop schedule for tests ! graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/MemoryScheduleTest.java Changeset: b334ca53f077 Author: Bernhard Urban Date: 2013-11-20 20:33 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/b334ca53f077 NewMemoryAwareScheduling: don't consider lastAccessLocation of a read as a kill also: don't accumulate KillSet along the dominator path. we aren't interested in the information from previous blocks. ! graal/com.oracle.graal.phases/src/com/oracle/graal/phases/schedule/SchedulePhase.java Changeset: ec0f6ecc0b7a Author: Doug Simon Date: 2013-11-20 22:16 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/ec0f6ecc0b7a fixed HotSpot build on MacOS ! make/bsd/makefiles/jsig.make ! make/bsd/makefiles/vm.make Changeset: c0085eefbd42 Author: Doug Simon Date: 2013-11-20 22:40 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/c0085eefbd42 fixed serviceability agent build issue on MacOS ! make/bsd/makefiles/saproc.make Changeset: f705fc04faa5 Author: Doug Simon Date: 2013-11-20 22:50 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/f705fc04faa5 HSAIL: adds support for handling Java switch constructs . Contributed-by: Vasanth Venkatachalam ! 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/IntLookupSwitchTest.java + graal/com.oracle.graal.compiler.hsail.test/src/com/oracle/graal/compiler/hsail/test/IntTableSwitchTest.java + graal/com.oracle.graal.compiler.hsail.test/src/com/oracle/graal/compiler/hsail/test/StringSwitchTest.java ! graal/com.oracle.graal.compiler.hsail/src/com/oracle/graal/compiler/hsail/HSAILLIRGenerator.java ! graal/com.oracle.graal.lir.hsail/src/com/oracle/graal/lir/hsail/HSAILControlFlow.java From thomas.wuerthinger at oracle.com Wed Nov 20 16:07:10 2013 From: thomas.wuerthinger at oracle.com (Thomas Wuerthinger) Date: Thu, 21 Nov 2013 01:07:10 +0100 Subject: question about bci in LIRFrameState for DeoptimizeOp In-Reply-To: References: <721F36C5-C300-46A6-B0D8-4153313F57C8@oracle.com> Message-ID: <5FAE43E9-4E5A-431E-ADD0-2DE4D7631834@oracle.com> Can you always restart a kernel or do your kernels have intermediate side effects that cannot be undone? - thomas On 20 Nov 2013, at 23:27, Deneau, Tom wrote: > Gilles -- > > Yes, the guards were scheduled early in this case, before the side effect. > Will take a look at the paper, thanks. > > We are still in an early mode of exploring what information gets passed to the VM, and in what ways HSAIL can make use of that if a kernel gets an exception in one or more workitems. > > Eric Caspole may have more to add on this. > > -- Tom > > > From: gilwooden at gmail.com [mailto:gilwooden at gmail.com] On Behalf Of Gilles Duboscq > Sent: Wednesday, November 20, 2013 3:36 PM > To: Thomas Wuerthinger > Cc: Deneau, Tom; graal-dev at openjdk.java.net > Subject: Re: question about bci in LIRFrameState for DeoptimizeOp > > Since guards are scheduled early, in your example i would guess they are indeed before the side effect. > You can have a look at this paper: http://design.cs.iastate.edu/vmil/2013/papers/p04-Duboscq.pdf it contains information about how we handle deoptimization in Graal and about how we use it for exceptional control-flow (which is probably also of interest in the HSAIL runtime context). > > Why are you looking at the deoptimization exactly? Do you have an idea already about how you would handle them in HSAIL runtime? > > -Gilles > > > On Wed, Nov 20, 2013 at 10:15 PM, Thomas Wuerthinger wrote: > I think the guards for the array access might have been moved before the field store. Can you check in the machine code whether the deoptimization is indeed *after* the field store? - thomas > > On 20 Nov 2013, at 22:08, Deneau, Tom wrote: > > > Thomas -- > > > > I retried this experiment with a java snippet that I thought would have a side effect, incrementing a field > > public int intFromArrayLonger(int[] ary, int idx) { > > dummyField++; > > return ary[idx]; > > } > > > > But I still saw a info.bci of 0. > > > > -- Tom D > > > > > > > > -----Original Message----- > > From: Thomas Wuerthinger [mailto:thomas.wuerthinger at oracle.com] > > Sent: Wednesday, November 20, 2013 2:40 PM > > To: Deneau, Tom > > Cc: graal-dev at openjdk.java.net > > Subject: Re: question about bci in LIRFrameState for DeoptimizeOp > > > > Graal understands that it can safely replay bytecodes without side effects. Therefore the target bci of a deoptimization will reflect the last side effecting instruction (or the beginning of the method if no such instruction exists). Gilles wrote a paper describing in more details how deoptimization works in Graal and we will publish it shortly as part of the Graal documentation. - thomas > > > > On 20 Nov 2013, at 21:17, Deneau, Tom wrote: > > > >> I was looking at the AMD64DeoptimizeOp.emitCode routine which is > >> AMD64Call.directCall(tasm, masm, > >> tasm.foreignCalls.lookupForeignCall(UNCOMMON_TRAP), null, false, > >> info); > >> > >> When I look at the LIRFrameState info which is passed to UNCOMMON_TRAP, the bci always seems to be 0. > >> Why is that? > >> > >> For example, compiling this small snippet thru AMD64 backend > >> public int intFromArray(int[] ary, int idx) { > >> return ary[idx]; > >> } > >> > >> with bytecodes > >> public int intFromArray(int[], int); > >> Code: > >> 0: aload_1 > >> 1: iload_2 > >> 2: iaload > >> 3: ireturn > >> > >> when I get to AMD64DeoptimizeOp.emitCode, I see info = "at > >> com.oracle.graal.compiler.test.BasicTest2.intFromArray(BasicTest2.java:46) [bci: 0] > >> |0 |1 |2 > >> locals: |- |v0|a |v1|i " > >> > >> I would have expected the bci in this case to be 2, referring to the iaload instruction. > >> > >> -- Tom > >> > >> > > > > > > > From duboscq at ssw.jku.at Thu Nov 21 03:27:03 2013 From: duboscq at ssw.jku.at (Gilles Duboscq) Date: Thu, 21 Nov 2013 12:27:03 +0100 Subject: compiled leaf method vs. inlined method bounds check In-Reply-To: References: Message-ID: Hello Tom, sorry for the delayed answer. I did the tests and i can not reproduce the behaviour you are seeing if no exception is ever thrown. However i can easily reproduce it if the first method (the one containing the array accesses) has already thrown an exception while the second one (the one containing the call) has never seen an exception flow through the call. In this case the second method assumes no exception can never flow through the call but when it inline the call, it sees that it actually needs to handle exceptions, in this case you get that NotCompiledExceptionHandler reason. I used this to test: public class ArrayTest extends JTTTest { static int[] array = {1, 2, 3}; @Test public void test0() throws Throwable { run(new int[3], array, array, 0); runTest("callRun", new int[3], array, array, 0); } @Test public void test1() throws Throwable { run(new int[3], array, array, 3); runTest("callRun", new int[3], array, array, 0); } @Test public void test2() throws Throwable { callRun(new int[3], array, array, 3); runTest("callRun", new int[3], array, array, 0); } public static void run(int[] out, int[] ina, int[] inb, int gid) { out[gid] = ina[gid] + inb[gid]; } public static void callRun(int[] out, int[] ina, int[] inb, int gid) { run(out, ina, inb, gid); } } In the first case (test0) i get the inlined call an the BoundsCheckException reason. In the second case (test1) i get the inlined call and the NotCompiledExceptionHandler reason. In the thrid case (test2) i get the full exception handling. Note that you need to run these separately if you don't want profile pollution. -Gilles On Wed, Nov 13, 2013 at 1:22 AM, Tom Deneau wrote: > Gilles -- > > > > OK, we have a simple existing test in > com.oracle.graal.compiler.hsail.test.IntAddTest which adds ints from two > arrays putting the result in a third output array > > public static void run(int[] out, int[] ina, int[] inb, int gid) { > > out[gid] = ina[gid] + inb[gid]; > > } > > > > Here is the hsail code:. (Note that we don't really handle the > DeoptimizeNode but just print a comment based on the reason). > > > > version 0:95: $full : $large; > > // static method HotSpotMethod int)> > > kernel &run ( > > kernarg_u64 %_arg0, > > kernarg_u64 %_arg1, > > kernarg_u64 %_arg2 > > ) { > > ld_kernarg_u64 $d0, [%_arg0]; > > ld_kernarg_u64 $d1, [%_arg1]; > > ld_kernarg_u64 $d2, [%_arg2]; > > workitemabsid_u32 $s0, 0; > > > > @L0: > > ld_global_s32 $s1, [$d0 + 12]; > > cmp_ge_b1_u32 $c0, $s0, $s1; > > cbr $c0, @L7; > > @L1: > > ld_global_s32 $s1, [$d2 + 12]; > > cmp_ge_b1_u32 $c0, $s0, $s1; > > cbr $c0, @L7; > > @L2: > > ld_global_s32 $s1, [$d1 + 12]; > > cmp_ge_b1_u32 $c0, $s0, $s1; > > cbr $c0, @L7; > > @L3: > > cvt_s64_s32 $d3, $s0; > > mul_s64 $d3, $d3, 4; > > add_u64 $d1, $d1, $d3; > > ld_global_s32 $s1, [$d1 + 16]; > > cvt_s64_s32 $d1, $s0; > > mul_s64 $d1, $d1, 4; > > add_u64 $d2, $d2, $d1; > > ld_global_s32 $s2, [$d2 + 16]; > > add_s32 $s2, $s2, $s1; > > cvt_s64_s32 $d1, $s0; > > mul_s64 $d1, $d1, 4; > > add_u64 $d0, $d0, $d1; > > st_global_s32 $s2, [$d0 + 16]; > > ret; > > @L7: > > // Deoptimization for BoundsCheckException would occur here > > ret; > > }; > > > > > > Then I made a new test where the run method just basically called the > original IntAddTest.run > > public static void run(int[] out, int[] ina, int[] inb, int gid) { > > IntAddTest.run(out, ina, inb, gid); > > } > > > > We compile with InlineEverything set. We got this almost identical hsail > code except for the deoptimization reason. (In this case, there is no call > to createOutOfBoundsException but I have seen it in larger test cases). > Note that in either case, no exceptions would have occurred when profiling. > > > > version 0:95: $full : $large; > > // static method HotSpotMethod int)> > > kernel &run ( > > kernarg_u64 %_arg0, > > kernarg_u64 %_arg1, > > kernarg_u64 %_arg2 > > ) { > > ld_kernarg_u64 $d0, [%_arg0]; > > ld_kernarg_u64 $d1, [%_arg1]; > > ld_kernarg_u64 $d2, [%_arg2]; > > workitemabsid_u32 $s0, 0; > > > > @L0: > > ld_global_s32 $s1, [$d0 + 12]; > > cmp_ge_b1_u32 $c0, $s0, $s1; > > cbr $c0, @L7; > > @L1: > > ld_global_s32 $s1, [$d2 + 12]; > > cmp_ge_b1_u32 $c0, $s0, $s1; > > cbr $c0, @L7; > > @L2: > > ld_global_s32 $s1, [$d1 + 12]; > > cmp_ge_b1_u32 $c0, $s0, $s1; > > cbr $c0, @L7; > > @L3: > > cvt_s64_s32 $d3, $s0; > > mul_s64 $d3, $d3, 4; > > add_u64 $d1, $d1, $d3; > > ld_global_s32 $s1, [$d1 + 16]; > > cvt_s64_s32 $d1, $s0; > > mul_s64 $d1, $d1, 4; > > add_u64 $d2, $d2, $d1; > > ld_global_s32 $s2, [$d2 + 16]; > > add_s32 $s2, $s2, $s1; > > cvt_s64_s32 $d1, $s0; > > mul_s64 $d1, $d1, 4; > > add_u64 $d0, $d0, $d1; > > st_global_s32 $s2, [$d0 + 16]; > > ret; > > @L7: > > // Deoptimization for NotCompiledExceptionHandler would > occur here > > ret; > > }; > > > > > > *From:* gilwooden at gmail.com [mailto:gilwooden at gmail.com] *On Behalf Of *Gilles > Duboscq > *Sent:* Tuesday, November 12, 2013 5:56 PM > *To:* Deneau, Tom > *Cc:* graal-dev at openjdk.java.net > *Subject:* Re: compiled leaf method vs. inlined method bounds check > > > > Can you maybe show us the snippets you used and how you ran them? > > The second scenario you describe usually happen if an > ArrayIndexOutOfBoundsException has already been thrown at the array access > you're looking at. > > When compiling an array access, Graal will look at the profile and if it > shows that exceptions are thrown there, it will compile in the exception > branch (in your case the exception branch ends up into an other deopt for > some reason). If profiling shows no exception has been thrown there, it > will leave out the exception branch and will only place a which deoptimizes > in case an exception needs to be thrown. > > > > This should have nothing to do with inlining. When doings tests about > that, be carefull not to pollute the profile for the second test with the > first one. > > You can change the bahviour of graal reagrding these things using > the UseExceptionProbabilityForOperations flag. > > > > -Gilles > > > > On Tue, Nov 12, 2013 at 11:49 PM, Tom Deneau wrote: > > I've noticed that if the graph I am compiling is simply a leaf method > which accesses an array, the target of a failing bounds check is a > DeoptimizeNode with reason=BoundsCheckException, action=InvalidateReprofile > > But if the method that is accessing the array is being inlined into > another method, the target of the failing bounds check is a ForeignCall to > createOutOfBoundsException followed by a branch to a DeoptimizeNode with > reason=NotCompiledExceptionHandler, action=InvalidateRecompile. > > Can someone explain this difference? > > -- Tom > > > From tom.deneau at amd.com Thu Nov 21 08:04:36 2013 From: tom.deneau at amd.com (Deneau, Tom) Date: Thu, 21 Nov 2013 16:04:36 +0000 Subject: question about bci in LIRFrameState for DeoptimizeOp In-Reply-To: <5FAE43E9-4E5A-431E-ADD0-2DE4D7631834@oracle.com> References: <721F36C5-C300-46A6-B0D8-4153313F57C8@oracle.com> <5FAE43E9-4E5A-431E-ADD0-2DE4D7631834@oracle.com> Message-ID: In general, the kernels can have side effects. From: Thomas Wuerthinger [mailto:thomas.wuerthinger at oracle.com] Sent: Wednesday, November 20, 2013 6:07 PM To: Deneau, Tom Cc: Gilles Duboscq; graal-dev at openjdk.java.net Subject: Re: question about bci in LIRFrameState for DeoptimizeOp Can you always restart a kernel or do your kernels have intermediate side effects that cannot be undone? - thomas On 20 Nov 2013, at 23:27, Deneau, Tom > wrote: Gilles -- Yes, the guards were scheduled early in this case, before the side effect. Will take a look at the paper, thanks. We are still in an early mode of exploring what information gets passed to the VM, and in what ways HSAIL can make use of that if a kernel gets an exception in one or more workitems. Eric Caspole may have more to add on this. -- Tom From: gilwooden at gmail.com [mailto:gilwooden at gmail.com] On Behalf Of Gilles Duboscq Sent: Wednesday, November 20, 2013 3:36 PM To: Thomas Wuerthinger Cc: Deneau, Tom; graal-dev at openjdk.java.net Subject: Re: question about bci in LIRFrameState for DeoptimizeOp Since guards are scheduled early, in your example i would guess they are indeed before the side effect. You can have a look at this paper: http://design.cs.iastate.edu/vmil/2013/papers/p04-Duboscq.pdf it contains information about how we handle deoptimization in Graal and about how we use it for exceptional control-flow (which is probably also of interest in the HSAIL runtime context). Why are you looking at the deoptimization exactly? Do you have an idea already about how you would handle them in HSAIL runtime? -Gilles On Wed, Nov 20, 2013 at 10:15 PM, Thomas Wuerthinger > wrote: I think the guards for the array access might have been moved before the field store. Can you check in the machine code whether the deoptimization is indeed *after* the field store? - thomas On 20 Nov 2013, at 22:08, Deneau, Tom > wrote: > Thomas -- > > I retried this experiment with a java snippet that I thought would have a side effect, incrementing a field > public int intFromArrayLonger(int[] ary, int idx) { > dummyField++; > return ary[idx]; > } > > But I still saw a info.bci of 0. > > -- Tom D > > > > -----Original Message----- > From: Thomas Wuerthinger [mailto:thomas.wuerthinger at oracle.com] > Sent: Wednesday, November 20, 2013 2:40 PM > To: Deneau, Tom > Cc: graal-dev at openjdk.java.net > Subject: Re: question about bci in LIRFrameState for DeoptimizeOp > > Graal understands that it can safely replay bytecodes without side effects. Therefore the target bci of a deoptimization will reflect the last side effecting instruction (or the beginning of the method if no such instruction exists). Gilles wrote a paper describing in more details how deoptimization works in Graal and we will publish it shortly as part of the Graal documentation. - thomas > > On 20 Nov 2013, at 21:17, Deneau, Tom > wrote: > >> I was looking at the AMD64DeoptimizeOp.emitCode routine which is >> AMD64Call.directCall(tasm, masm, >> tasm.foreignCalls.lookupForeignCall(UNCOMMON_TRAP), null, false, >> info); >> >> When I look at the LIRFrameState info which is passed to UNCOMMON_TRAP, the bci always seems to be 0. >> Why is that? >> >> For example, compiling this small snippet thru AMD64 backend >> public int intFromArray(int[] ary, int idx) { >> return ary[idx]; >> } >> >> with bytecodes >> public int intFromArray(int[], int); >> Code: >> 0: aload_1 >> 1: iload_2 >> 2: iaload >> 3: ireturn >> >> when I get to AMD64DeoptimizeOp.emitCode, I see info = "at >> com.oracle.graal.compiler.test.BasicTest2.intFromArray(BasicTest2.java:46) [bci: 0] >> |0 |1 |2 >> locals: |- |v0|a |v1|i " >> >> I would have expected the bci in this case to be 2, referring to the iaload instruction. >> >> -- Tom >> >> > > > From doug.simon at oracle.com Thu Nov 21 08:25:31 2013 From: doug.simon at oracle.com (Doug Simon) Date: Thu, 21 Nov 2013 17:25:31 +0100 Subject: webrev for switch statement support in HSAIL backend In-Reply-To: <5DD1503F815BD14889DC81D28643E3A75788BC85@SATLEXDAG02.amd.com> References: <5DD1503F815BD14889DC81D28643E3A75788AB08@SATLEXDAG02.amd.com> <528C00C6.3000202@oracle.com> <5DD1503F815BD14889DC81D28643E3A75788BC85@SATLEXDAG02.amd.com> Message-ID: <95E0CFB9-CE8E-4546-BAEB-E400734F59C4@oracle.com> On Nov 20, 2013, at 8:08 PM, Venkatachalam, Vasanth wrote: > Doug, > > Answers inlined below. > > If there are no other changes required please commit the webrev, citing Vasanth Venkatachalam as the author, with the commit message: "Adds support to the HSAIL backend for handling Java switch constructs . > > Vasanth > > -----Original Message----- > From: graal-dev-bounces at openjdk.java.net [mailto:graal-dev-bounces at openjdk.java.net] On Behalf Of Doug Simon > Sent: Tuesday, November 19, 2013 6:23 PM > To: graal-dev at openjdk.java.net > Subject: Re: webrev for switch statement support in HSAIL backend > > graal/com.oracle.graal.asm.hsail/src/com/oracle/graal/asm/hsail/HSAILAssembler.java: > > + // Get a JNI reference handle to the object. > + long refHandle = OkraUtil.getRefHandle(obj); > > How does OkraUtil manage these handles? I hope it at least never creates more than one global JNI ref for any given object or has some way to release them when no longer needed. > >> [Vasanth] OkraUtil never creates more than one JNI ref for any given object. > This change isn't introducing anything new. This code has been in the assembler all along, we just extended it to remove the restriction that the Object passed as parameter to mov(Register reg, Object obj) must be an instance of Class. Even if it has been there all along, my question/concerns still remain. This is a memory leak if the global JNI refs are not managed to reflect the object lifetimes. Worse, if the objects are Class values, it will also probably prevent class unloading. -Doug From tom.deneau at amd.com Thu Nov 21 08:25:57 2013 From: tom.deneau at amd.com (Deneau, Tom) Date: Thu, 21 Nov 2013 16:25:57 +0000 Subject: Reviewing patches Message-ID: A process question... On other OpenJDK projects I have participated in (e.g., Hotspot Compiler), patches are sent out for review before being checked in, even if they are originated by folks with commit rights. Is this something we can start on the graal project? -- Tom Deneau From tom.deneau at amd.com Thu Nov 21 08:36:37 2013 From: tom.deneau at amd.com (Deneau, Tom) Date: Thu, 21 Nov 2013 16:36:37 +0000 Subject: webrev for switch statement support in HSAIL backend In-Reply-To: <95E0CFB9-CE8E-4546-BAEB-E400734F59C4@oracle.com> References: <5DD1503F815BD14889DC81D28643E3A75788AB08@SATLEXDAG02.amd.com> <528C00C6.3000202@oracle.com> <5DD1503F815BD14889DC81D28643E3A75788BC85@SATLEXDAG02.amd.com> <95E0CFB9-CE8E-4546-BAEB-E400734F59C4@oracle.com> Message-ID: Doug -- We were thinking about this as well after your questions. Stepping back, the problem that we were trying to solve was to be able to generate code which could contain "constant" references embedded in the code but which would not need to be updated if the underlying object moved. Using a level of indirection thru a JNI Global reference seemed like one solution. This does not seem like an HSAIL-specific problem so maybe the best solution would be to have some support in graal itself to support this. This support would include releasing handles if the code that uses them gets discarded. What do you think? -- Tom -----Original Message----- From: graal-dev-bounces at openjdk.java.net [mailto:graal-dev-bounces at openjdk.java.net] On Behalf Of Doug Simon Sent: Thursday, November 21, 2013 10:26 AM To: Venkatachalam, Vasanth Cc: graal-dev at openjdk.java.net Subject: Re: webrev for switch statement support in HSAIL backend On Nov 20, 2013, at 8:08 PM, Venkatachalam, Vasanth wrote: > Doug, > > Answers inlined below. > > If there are no other changes required please commit the webrev, citing Vasanth Venkatachalam as the author, with the commit message: "Adds support to the HSAIL backend for handling Java switch constructs . > > Vasanth > > -----Original Message----- > From: graal-dev-bounces at openjdk.java.net [mailto:graal-dev-bounces at openjdk.java.net] On Behalf Of Doug Simon > Sent: Tuesday, November 19, 2013 6:23 PM > To: graal-dev at openjdk.java.net > Subject: Re: webrev for switch statement support in HSAIL backend > > graal/com.oracle.graal.asm.hsail/src/com/oracle/graal/asm/hsail/HSAILAssembler.java: > > + // Get a JNI reference handle to the object. > + long refHandle = OkraUtil.getRefHandle(obj); > > How does OkraUtil manage these handles? I hope it at least never creates more than one global JNI ref for any given object or has some way to release them when no longer needed. > >> [Vasanth] OkraUtil never creates more than one JNI ref for any given object. > This change isn't introducing anything new. This code has been in the assembler all along, we just extended it to remove the restriction that the Object passed as parameter to mov(Register reg, Object obj) must be an instance of Class. Even if it has been there all along, my question/concerns still remain. This is a memory leak if the global JNI refs are not managed to reflect the object lifetimes. Worse, if the objects are Class values, it will also probably prevent class unloading. -Doug From doug.simon at oracle.com Thu Nov 21 08:52:52 2013 From: doug.simon at oracle.com (Doug Simon) Date: Thu, 21 Nov 2013 17:52:52 +0100 Subject: webrev for switch statement support in HSAIL backend In-Reply-To: References: <5DD1503F815BD14889DC81D28643E3A75788AB08@SATLEXDAG02.amd.com> <528C00C6.3000202@oracle.com> <5DD1503F815BD14889DC81D28643E3A75788BC85@SATLEXDAG02.amd.com> <95E0CFB9-CE8E-4546-BAEB-E400734F59C4@oracle.com> Message-ID: Object pointers in compiled code is a complex issue. HotSpot (especially the GCs) treat oops in nmethods very specially. Since HSAIL kernels are only ?fake? nmethods (as far as I can tell), we?ll need another mechanism for supporting oops in GPU kernels. However, for now, just stay with the current solution. -Doug On Nov 21, 2013, at 5:36 PM, Deneau, Tom wrote: > Doug -- > > We were thinking about this as well after your questions. > > Stepping back, the problem that we were trying to solve was to be able to generate code which could contain "constant" references embedded in the code but which would not need to be updated if the underlying object moved. Using a level of indirection thru a JNI Global reference seemed like one solution. > > This does not seem like an HSAIL-specific problem so maybe the best solution would be to have some support in graal itself to support this. This support would include releasing handles if the code that uses them gets discarded. > > What do you think? > > -- Tom > > > > -----Original Message----- > From: graal-dev-bounces at openjdk.java.net [mailto:graal-dev-bounces at openjdk.java.net] On Behalf Of Doug Simon > Sent: Thursday, November 21, 2013 10:26 AM > To: Venkatachalam, Vasanth > Cc: graal-dev at openjdk.java.net > Subject: Re: webrev for switch statement support in HSAIL backend > > > On Nov 20, 2013, at 8:08 PM, Venkatachalam, Vasanth wrote: > >> Doug, >> >> Answers inlined below. >> >> If there are no other changes required please commit the webrev, citing Vasanth Venkatachalam as the author, with the commit message: "Adds support to the HSAIL backend for handling Java switch constructs . >> >> Vasanth >> >> -----Original Message----- >> From: graal-dev-bounces at openjdk.java.net [mailto:graal-dev-bounces at openjdk.java.net] On Behalf Of Doug Simon >> Sent: Tuesday, November 19, 2013 6:23 PM >> To: graal-dev at openjdk.java.net >> Subject: Re: webrev for switch statement support in HSAIL backend >> >> graal/com.oracle.graal.asm.hsail/src/com/oracle/graal/asm/hsail/HSAILAssembler.java: >> >> + // Get a JNI reference handle to the object. >> + long refHandle = OkraUtil.getRefHandle(obj); >> >> How does OkraUtil manage these handles? I hope it at least never creates more than one global JNI ref for any given object or has some way to release them when no longer needed. >> >>> [Vasanth] OkraUtil never creates more than one JNI ref for any given object. >> This change isn't introducing anything new. This code has been in the assembler all along, we just extended it to remove the restriction that the Object passed as parameter to mov(Register reg, Object obj) must be an instance of Class. > > Even if it has been there all along, my question/concerns still remain. This is a memory leak if the global JNI refs are not managed to reflect the object lifetimes. Worse, if the objects are Class values, it will also probably prevent class unloading. > > -Doug > From tom.deneau at amd.com Thu Nov 21 09:04:12 2013 From: tom.deneau at amd.com (Deneau, Tom) Date: Thu, 21 Nov 2013 17:04:12 +0000 Subject: webrev to address some HSAIL junit testing issues Message-ID: I have posted a webrev to address some issues in our HSAIL junit testing. http://cr.openjdk.java.net/~tdeneau/graal-webrevs/webrev-junit-support/webrev/ Here is a summary: 1) a fix for a problem that was introduced in the latest okra-in-hotspot webrev in that we were still going thru the JNI path for some of the java8 lambda-based kerneltester APIs. It also simplifies the KernelTester overrides in GraalKernelTester. While this does not affect the current java7 based tests in trunk, I feel this is important to get into trunk. 2) All the current junit tests that can be run from trunk test over an integer stream range. In Sumatra, we also want to be able to iterate over an Object array, with an Object being the iteration parameter. There was some partially implemented support in KernelTester for Object array based junit tests, this was filled out and a number of java-7 style object array stream tests were added. 3) Some object array stream related bugs in HSAILHotSpotBackend were fixed, and support for Object arrays in the presence of CompressedOops was added. 4) removed some java.util.logger usages that were hanging around in HSAILCompilationResult. If you want to see the generated hsail code, you can use something like -G:Log=CodeGen -- Tom From doug.simon at oracle.com Thu Nov 21 09:12:24 2013 From: doug.simon at oracle.com (Doug Simon) Date: Thu, 21 Nov 2013 18:12:24 +0100 Subject: Reviewing patches In-Reply-To: References: Message-ID: <7F2D4B45-6AAC-4FFE-A40E-E91DBC3D505B@oracle.com> The Graal team has so far adopted a post-push review system using an internal Crucible instance. Rumor has it that OpenJDK hosted Crucible instances will be available at some point at which time external collaborators could participate at the same level. For now, feel free to review or comment on changesets once they are available in the OpenJDK Graal repository. -Doug On Nov 21, 2013, at 5:25 PM, Deneau, Tom wrote: > A process question... > > On other OpenJDK projects I have participated in (e.g., Hotspot Compiler), patches are sent out for review before being checked in, even if they are originated by folks with commit rights. Is this something we can start on the graal project? > > -- Tom Deneau From tom.deneau at amd.com Thu Nov 21 12:17:56 2013 From: tom.deneau at amd.com (Deneau, Tom) Date: Thu, 21 Nov 2013 20:17:56 +0000 Subject: disassembly for foreign call wrapper Message-ID: Is there a Log scoping that will show the disassembly for the code that is the wrapper for a foreign call to a non-stub. I am currently using -G:Log=CodeInstall which gives me normal methods plus CompilingStub.CodeInstall . -- Tom From doug.simon at oracle.com Thu Nov 21 12:59:29 2013 From: doug.simon at oracle.com (Doug Simon) Date: Thu, 21 Nov 2013 21:59:29 +0100 Subject: disassembly for foreign call wrapper In-Reply-To: References: Message-ID: This is no wrapper - just the foreign call plus maybe a prologue/epilogue around the call. For example, each of the calls in the output below is to foreign call described by SystemSubstitutions.JAVA_TIME_MILLIS: $ mx --vm server unittest -G:Log=CodeInstall -G:MethodFilter=test System_nanoTime01 JUnit version 4.8 .Loaded disassembler from /Users/dsimon/linz/basic-graal/jdk1.7.0_45/product/jre/lib/hsdis-amd64.dylib [thread:1] scope: [thread:1] scope: Compiling [thread:1] scope: Compiling.CodeInstall Code installed for HotSpotMethod ---------------------------------------------------------------------- com/oracle/graal/jtt/jdk/System_nanoTime01.test [0x000000010971dba0, 0x000000010971dc40] 1280 bytes [Disassembling for mach='i386:x86-64'] [Entry Point] [Verified Entry Point] [Constants] # {method} {0x0000000112bbfde8} 'test' '()I' in 'com/oracle/graal/jtt/jdk/System_nanoTime01' # [sp+0x20] (sp of caller) 0x000000010971dba0: mov %rax,-0x14000(%rsp) 0x000000010971dba8: sub $0x18,%rsp 0x000000010971dbac: mov %rbp,0x10(%rsp) 0x000000010971dbb1: callq 0x0000000108c22934 ; {runtime_call} 0x000000010971dbb6: nop 0x000000010971dbb7: mov %rax,0x8(%rsp) 0x000000010971dbbc: callq 0x0000000108c22934 ; {runtime_call} 0x000000010971dbc1: nop 0x000000010971dbc2: sub 0x8(%rsp),%rax 0x000000010971dbc7: cmp $0x0,%rax 0x000000010971dbcb: jg 0x000000010971dc0d 0x000000010971dbd1: mov $0x1,%eax 0x000000010971dbd6: jmpq 0x000000010971dbff 0x000000010971dbdb: nopl 0x0(%rax,%rax,1) 0x000000010971dbe0: mov %eax,0x4(%rsp) 0x000000010971dbe4: callq 0x0000000108c22934 ; {runtime_call} 0x000000010971dbe9: nop 0x000000010971dbea: sub 0x8(%rsp),%rax 0x000000010971dbef: cmp $0x0,%rax 0x000000010971dbf3: jg 0x000000010971dc2a 0x000000010971dbf9: mov 0x4(%rsp),%eax 0x000000010971dbfd: inc %eax 0x000000010971dbff: cmp $0x989680,%eax 0x000000010971dc05: jge 0x000000010971dc23 0x000000010971dc0b: jmp 0x000000010971dbe0 0x000000010971dc0d: mov $0x1,%eax 0x000000010971dc12: mov 0x10(%rsp),%rbp 0x000000010971dc17: add $0x18,%rsp 0x000000010971dc1b: mov -0x1784c1b(%rip),%rbx # 0x0000000107f99007 ; {poll_return} 0x000000010971dc22: retq 0x000000010971dc23: mov $0x0,%eax 0x000000010971dc28: jmp 0x000000010971dc12 0x000000010971dc2a: mov $0x1,%eax 0x000000010971dc2f: jmp 0x000000010971dc12 [Exception Handler] 0x000000010971dc31: callq 0x000000010971dd20 ; {runtime_call} 0x000000010971dc36: nop [Deopt Handler Code] 0x000000010971dc37: callq 0x00000001095deb00 ; {runtime_call} 0x000000010971dc3c: nop [Stub Code] 0x000000010971dc3d: hlt 0x000000010971dc3e: hlt 0x000000010971dc3f: hlt On Nov 21, 2013, at 9:17 PM, Deneau, Tom wrote: > Is there a Log scoping that will show the disassembly for the code that is the wrapper for a foreign call to a non-stub. > > I am currently using -G:Log=CodeInstall which gives me normal methods plus CompilingStub.CodeInstall . > > -- Tom From doug.simon at oracle.com Thu Nov 21 13:27:44 2013 From: doug.simon at oracle.com (Doug Simon) Date: Thu, 21 Nov 2013 22:27:44 +0100 Subject: webrev to address some HSAIL junit testing issues In-Reply-To: References: Message-ID: I?ve integrated this webrev and am pushing it through now. On Nov 21, 2013, at 6:04 PM, Deneau, Tom wrote: > I have posted a webrev to address some issues in our HSAIL junit testing. > > > > http://cr.openjdk.java.net/~tdeneau/graal-webrevs/webrev-junit-support/webrev/ > > > > Here is a summary: > > > > 1) a fix for a problem that was introduced in the latest okra-in-hotspot webrev in that we were still going thru the JNI path for some of the java8 lambda-based kerneltester APIs. It also simplifies the KernelTester overrides in GraalKernelTester. While this does not affect the current java7 based tests in trunk, I feel this is important to get into trunk. > > > > 2) All the current junit tests that can be run from trunk test over an integer stream range. In Sumatra, we also want to be able to iterate over an Object array, with an Object being the iteration parameter. There was some partially implemented support in KernelTester for Object array based junit tests, this was filled out and a number of java-7 style object array stream tests were added. > > > > 3) Some object array stream related bugs in HSAILHotSpotBackend were fixed, and support for Object arrays in the presence of CompressedOops was added. > > > > 4) removed some java.util.logger usages that were hanging around in HSAILCompilationResult. If you want to see the generated hsail code, you can use something like -G:Log=CodeGen > > > > -- Tom > > > > > From tom.deneau at amd.com Thu Nov 21 14:11:25 2013 From: tom.deneau at amd.com (Deneau, Tom) Date: Thu, 21 Nov 2013 22:11:25 +0000 Subject: disassembly for foreign call wrapper In-Reply-To: References: Message-ID: Doug -- In the particular case of a foreign call to UNCOMMON_TRAP (from AMD64DeoptimizeOp), I'm trying to understand the role that the LIRFrameState info parameter plays. It doesn't get passed to the foreign Deoptimization::uncommon_trap which takes a JavaThread* and an int (the actionAndReason int). Since the LIRFrameState info doesn't get passed, I was trying to understand how the JVM gets the deoptimization information it needs. Does it come from using a table in each nmethod to map a physical pc to a trap_scope? -- Tom -----Original Message----- From: Doug Simon [mailto:doug.simon at oracle.com] Sent: Thursday, November 21, 2013 2:59 PM To: Deneau, Tom Cc: graal-dev at openjdk.java.net Subject: Re: disassembly for foreign call wrapper This is no wrapper - just the foreign call plus maybe a prologue/epilogue around the call. For example, each of the calls in the output below is to foreign call described by SystemSubstitutions.JAVA_TIME_MILLIS: $ mx --vm server unittest -G:Log=CodeInstall -G:MethodFilter=test System_nanoTime01 JUnit version 4.8 .Loaded disassembler from /Users/dsimon/linz/basic-graal/jdk1.7.0_45/product/jre/lib/hsdis-amd64.dylib [thread:1] scope: [thread:1] scope: Compiling [thread:1] scope: Compiling.CodeInstall Code installed for HotSpotMethod ---------------------------------------------------------------------- com/oracle/graal/jtt/jdk/System_nanoTime01.test [0x000000010971dba0, 0x000000010971dc40] 1280 bytes [Disassembling for mach='i386:x86-64'] [Entry Point] [Verified Entry Point] [Constants] # {method} {0x0000000112bbfde8} 'test' '()I' in 'com/oracle/graal/jtt/jdk/System_nanoTime01' # [sp+0x20] (sp of caller) 0x000000010971dba0: mov %rax,-0x14000(%rsp) 0x000000010971dba8: sub $0x18,%rsp 0x000000010971dbac: mov %rbp,0x10(%rsp) 0x000000010971dbb1: callq 0x0000000108c22934 ; {runtime_call} 0x000000010971dbb6: nop 0x000000010971dbb7: mov %rax,0x8(%rsp) 0x000000010971dbbc: callq 0x0000000108c22934 ; {runtime_call} 0x000000010971dbc1: nop 0x000000010971dbc2: sub 0x8(%rsp),%rax 0x000000010971dbc7: cmp $0x0,%rax 0x000000010971dbcb: jg 0x000000010971dc0d 0x000000010971dbd1: mov $0x1,%eax 0x000000010971dbd6: jmpq 0x000000010971dbff 0x000000010971dbdb: nopl 0x0(%rax,%rax,1) 0x000000010971dbe0: mov %eax,0x4(%rsp) 0x000000010971dbe4: callq 0x0000000108c22934 ; {runtime_call} 0x000000010971dbe9: nop 0x000000010971dbea: sub 0x8(%rsp),%rax 0x000000010971dbef: cmp $0x0,%rax 0x000000010971dbf3: jg 0x000000010971dc2a 0x000000010971dbf9: mov 0x4(%rsp),%eax 0x000000010971dbfd: inc %eax 0x000000010971dbff: cmp $0x989680,%eax 0x000000010971dc05: jge 0x000000010971dc23 0x000000010971dc0b: jmp 0x000000010971dbe0 0x000000010971dc0d: mov $0x1,%eax 0x000000010971dc12: mov 0x10(%rsp),%rbp 0x000000010971dc17: add $0x18,%rsp 0x000000010971dc1b: mov -0x1784c1b(%rip),%rbx # 0x0000000107f99007 ; {poll_return} 0x000000010971dc22: retq 0x000000010971dc23: mov $0x0,%eax 0x000000010971dc28: jmp 0x000000010971dc12 0x000000010971dc2a: mov $0x1,%eax 0x000000010971dc2f: jmp 0x000000010971dc12 [Exception Handler] 0x000000010971dc31: callq 0x000000010971dd20 ; {runtime_call} 0x000000010971dc36: nop [Deopt Handler Code] 0x000000010971dc37: callq 0x00000001095deb00 ; {runtime_call} 0x000000010971dc3c: nop [Stub Code] 0x000000010971dc3d: hlt 0x000000010971dc3e: hlt 0x000000010971dc3f: hlt On Nov 21, 2013, at 9:17 PM, Deneau, Tom wrote: > Is there a Log scoping that will show the disassembly for the code that is the wrapper for a foreign call to a non-stub. > > I am currently using -G:Log=CodeInstall which gives me normal methods plus CompilingStub.CodeInstall . > > -- Tom From Vasanth.Venkatachalam at amd.com Thu Nov 21 14:32:14 2013 From: Vasanth.Venkatachalam at amd.com (Venkatachalam, Vasanth) Date: Thu, 21 Nov 2013 22:32:14 +0000 Subject: webrev to support remainder operation on longs Message-ID: <5DD1503F815BD14889DC81D28643E3A75788C103@SATLEXDAG02.amd.com> Hi, I've uploaded a webrev which adds support to the HSAIL backend for the Java remainder operator (%) on longs. Previously it was only supporting ints. http://cr.openjdk.java.net/~tdeneau/webrev-remoplong.00/webrev/ Please review and when ready for check-in please commit the code under my name. Notes; * This is a one line change to HSAILArithmetic. * I've added a test case (LongModTest) for this change * I've enhanced the test case for ints to use negative as well as positive values. * Floating point support for % will be added later. This needs to be scoped out. Vasanth From doug.simon at oracle.com Fri Nov 22 04:58:46 2013 From: doug.simon at oracle.com (doug.simon at oracle.com) Date: Fri, 22 Nov 2013 12:58:46 +0000 Subject: hg: graal/graal: 15 new changesets Message-ID: <20131122125944.62333627B0@hg.openjdk.java.net> Changeset: b65b34c524cb Author: Tom Rodriguez Date: 2013-11-20 15:47 -0800 URL: http://hg.openjdk.java.net/graal/graal/rev/b65b34c524cb Ensure _non_oop_bits is initialized before starting compile ! src/share/vm/graal/graalCompiler.cpp Changeset: 14db5ffd5ed9 Author: twisti Date: 2013-11-20 16:54 -0800 URL: http://hg.openjdk.java.net/graal/graal/rev/14db5ffd5ed9 make HSAIL silent ! src/gpu/hsail/vm/gpu_hsail.cpp Changeset: d61687130412 Author: twisti Date: 2013-11-20 16:55 -0800 URL: http://hg.openjdk.java.net/graal/graal/rev/d61687130412 move GRAAL_ONLY stuff from vmStructs.cpp to separate vmStructs_graal.hpp file + src/share/vm/graal/vmStructs_graal.hpp ! src/share/vm/runtime/vmStructs.cpp Changeset: eae26735df5a Author: twisti Date: 2013-11-20 16:56 -0800 URL: http://hg.openjdk.java.net/graal/graal/rev/eae26735df5a make Solaris build again ! make/solaris/makefiles/buildtree.make ! make/solaris/makefiles/vm.make Changeset: df7fa4734c44 Author: twisti Date: 2013-11-20 17:14 -0800 URL: http://hg.openjdk.java.net/graal/graal/rev/df7fa4734c44 make Deoptimization::UnrollBlock visible to vmStructs ! src/share/vm/runtime/deoptimization.hpp Changeset: 790ebab62d23 Author: Christos Kotselidis Date: 2013-11-21 15:04 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/790ebab62d23 Fix nmethod reloc scanning bug of zombie methods in G1 ! src/share/vm/code/nmethod.cpp Changeset: f9f4503a4ab5 Author: Christos Kotselidis Date: 2013-11-21 15:04 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/f9f4503a4ab5 Merge - graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/bridge/MetricRateInPhase.java - graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotHostLoweringProvider.java ! src/share/vm/code/nmethod.cpp - src/share/vm/memory/metablock.cpp - src/share/vm/memory/metablock.hpp - test/compiler/8013496/Test8013496.sh - test/compiler/intrinsics/mathexact/CondTest.java - test/compiler/intrinsics/mathexact/ConstantTest.java - test/compiler/intrinsics/mathexact/LoadTest.java - test/compiler/intrinsics/mathexact/LoopDependentTest.java - test/compiler/intrinsics/mathexact/NonConstantTest.java - test/gc/7168848/HumongousAlloc.java Changeset: c0b0974dd509 Author: Doug Simon Date: 2013-11-21 22:08 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/c0b0974dd509 moved notification of Graal compilation statistics from VMToCompiler to CompilerToVM ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/CompilationTask.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/HotSpotOptions.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/HotSpotVMConfig.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/bridge/CompilerToVM.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/bridge/CompilerToVMImpl.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/bridge/VMToCompiler.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/bridge/VMToCompilerImpl.java ! src/share/vm/classfile/vmSymbols.hpp ! src/share/vm/graal/graalCompiler.cpp ! src/share/vm/graal/graalCompilerToVM.cpp ! src/share/vm/graal/graalVMToCompiler.cpp ! src/share/vm/graal/graalVMToCompiler.hpp ! src/share/vm/graal/vmStructs_graal.hpp ! src/share/vm/runtime/timer.cpp ! src/share/vm/runtime/timer.hpp Changeset: dd941feb26cb Author: Doug Simon Date: 2013-11-21 22:10 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/dd941feb26cb check for pending exception after call to createHotSpotResolvedObjectType ! src/share/vm/graal/graalCompiler.cpp Changeset: d3fc35a43376 Author: Doug Simon Date: 2013-11-21 22:24 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/d3fc35a43376 HSAIL: addressed issues in JUnit tests Contributed-by: Tom Deneau ! graal/com.oracle.graal.compiler.hsail.test.infra/src/com/oracle/graal/compiler/hsail/test/infra/GraalKernelTester.java ! graal/com.oracle.graal.compiler.hsail.test.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/BasicHSAILTest.java + graal/com.oracle.graal.compiler.hsail.test/src/com/oracle/graal/compiler/hsail/test/Vec3.java + graal/com.oracle.graal.compiler.hsail.test/src/com/oracle/graal/compiler/hsail/test/Vec3ObjStreamFloatCaptureTest.java + graal/com.oracle.graal.compiler.hsail.test/src/com/oracle/graal/compiler/hsail/test/Vec3ObjStreamIntCaptureTest.java + graal/com.oracle.graal.compiler.hsail.test/src/com/oracle/graal/compiler/hsail/test/Vec3ObjStreamIntFloatCaptureTest.java + graal/com.oracle.graal.compiler.hsail.test/src/com/oracle/graal/compiler/hsail/test/Vec3ObjStreamObjCaptureTest.java + graal/com.oracle.graal.compiler.hsail.test/src/com/oracle/graal/compiler/hsail/test/Vec3ObjStreamObjFieldTest.java + graal/com.oracle.graal.compiler.hsail.test/src/com/oracle/graal/compiler/hsail/test/Vec3ObjStreamTest.java ! graal/com.oracle.graal.hotspot.hsail/src/com/oracle/graal/hotspot/hsail/HSAILCompilationResult.java ! graal/com.oracle.graal.hotspot.hsail/src/com/oracle/graal/hotspot/hsail/HSAILHotSpotBackend.java Changeset: bdc836ef885e Author: Doug Simon Date: 2013-11-21 22:45 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/bdc836ef885e made CITimeEach work for Graal even if CITime is not enabled ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/CompilationTask.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/HotSpotOptions.java ! src/share/vm/graal/graalCompiler.cpp Changeset: 91933915d1d0 Author: Doug Simon Date: 2013-11-22 01:22 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/91933915d1d0 minor fix to output format of CITime ! src/share/vm/compiler/compileBroker.cpp Changeset: d84fa69a9874 Author: Doug Simon Date: 2013-11-22 01:30 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/d84fa69a9874 added support for printing method profiles for virtual calls ! src/share/vm/oops/methodData.cpp ! src/share/vm/oops/methodData.hpp Changeset: 58dfd753ada8 Author: Doug Simon Date: 2013-11-22 01:40 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/58dfd753ada8 fixed regression from recent hsx merge that prevented TypeProfileLevel from being enabled ! src/cpu/x86/vm/globals_x86.hpp ! src/cpu/x86/vm/templateTable_x86_64.cpp Changeset: b96536453a74 Author: Doug Simon Date: 2013-11-22 01:50 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/b96536453a74 HSAIL: added support for LREM Contributed-by: Vasanth Venkatachalam + graal/com.oracle.graal.compiler.hsail.test/src/com/oracle/graal/compiler/hsail/test/LongModTest.java ! graal/com.oracle.graal.compiler.hsail.test/src/com/oracle/graal/compiler/hsail/test/StaticMethodThreeIntArrays.java ! graal/com.oracle.graal.lir.hsail/src/com/oracle/graal/lir/hsail/HSAILArithmetic.java From Eric.Caspole at amd.com Fri Nov 22 06:13:21 2013 From: Eric.Caspole at amd.com (Caspole, Eric) Date: Fri, 22 Nov 2013 14:13:21 +0000 Subject: webrev to remove AMD GPU check Message-ID: Hi everybody, After discussing it with Bharadwaj the other day, I made a webrev to remove AMD GPU detection since for the time being we are only running on the HSAIL simulator, which only depends on shared libraries. I found that since AMD CPUs and GPUs have the same vendor ID, this part was not working as intended if you have a system with an AMD CPU with Nvidia GPU so nothing would be offloaded. We will adjust this AMD APU detection when the real HSA system is generally available. http://cr.openjdk.java.net/~ecaspole/no_amd_hw_check/ In the course of this change, I moved the gpu::init during the JVM boot up after the arguments are processed so the +UseHSAILSimulator I added earlier will work correctly. Let me know what you think, Thanks, Eric From Eric.Caspole at amd.com Fri Nov 22 06:21:17 2013 From: Eric.Caspole at amd.com (Caspole, Eric) Date: Fri, 22 Nov 2013 14:21:17 +0000 Subject: webrev for loading HSAIL/Okra function pointers Message-ID: Hi everybody, Here is a webrev to do null checks on the Okra library we load to do the HSAIL offload. Earlier there were no checks on finding the function pointers, so if you happened to be running an older version of Okra from github, it would crash. http://cr.openjdk.java.net/~ecaspole/check_okra_funcs/ Here I made the function pointer loading very similar to the PTX version using macros with null checks. Thanks, Eric From bharadwaj.yadavalli at oracle.com Fri Nov 22 07:59:48 2013 From: bharadwaj.yadavalli at oracle.com (S. Bharadwaj Yadavalli) Date: Fri, 22 Nov 2013 10:59:48 -0500 Subject: webrev to remove AMD GPU check In-Reply-To: References: Message-ID: <528F7F74.1040207@oracle.com> This change looks good to me. I have successfully run a couple of PTX tests on a machine with Intel CPU + Nvidia GPU with this patch. Thanks, Bharadwaj On 11/22/2013 09:13 AM, Caspole, Eric wrote: > Hi everybody, > After discussing it with Bharadwaj the other day, I made a webrev to remove AMD GPU detection since for the time being we are only running on the HSAIL simulator, which only depends on shared libraries. I found that since AMD CPUs and GPUs have the same vendor ID, this part was not working as intended if you have a system with an AMD CPU with Nvidia GPU so nothing would be offloaded. We will adjust this AMD APU detection when the real HSA system is generally available. > > http://cr.openjdk.java.net/~ecaspole/no_amd_hw_check/ > > In the course of this change, I moved the gpu::init during the JVM boot up after the arguments are processed so the +UseHSAILSimulator I added earlier will work correctly. > Let me know what you think, > Thanks, > Eric > From doug.simon at oracle.com Fri Nov 22 08:40:11 2013 From: doug.simon at oracle.com (Doug Simon) Date: Fri, 22 Nov 2013 17:40:11 +0100 Subject: webrev for loading HSAIL/Okra function pointers In-Reply-To: References: Message-ID: <27DDBFAA-2CD0-4279-BE05-4FF389C120E8@oracle.com> Looks good to me - I?ll push it through. On Nov 22, 2013, at 3:21 PM, Caspole, Eric wrote: > Hi everybody, > Here is a webrev to do null checks on the Okra library we load to do the HSAIL offload. Earlier there were no checks on finding the function pointers, so if you happened to be running an older version of Okra from github, it would crash. > > http://cr.openjdk.java.net/~ecaspole/check_okra_funcs/ > > Here I made the function pointer loading very similar to the PTX version using macros with null checks. > Thanks, > Eric > From doug.simon at oracle.com Fri Nov 22 08:40:43 2013 From: doug.simon at oracle.com (Doug Simon) Date: Fri, 22 Nov 2013 17:40:43 +0100 Subject: webrev to remove AMD GPU check In-Reply-To: <528F7F74.1040207@oracle.com> References: <528F7F74.1040207@oracle.com> Message-ID: <26FD2787-4AF7-4E04-B541-CC81FB05C242@oracle.com> Looks good to me as well - I?ll push it through. On Nov 22, 2013, at 4:59 PM, S. Bharadwaj Yadavalli wrote: > This change looks good to me. I have successfully run a couple of PTX tests on a machine with Intel CPU + Nvidia GPU with this patch. > > Thanks, > > Bharadwaj > > On 11/22/2013 09:13 AM, Caspole, Eric wrote: >> Hi everybody, >> After discussing it with Bharadwaj the other day, I made a webrev to remove AMD GPU detection since for the time being we are only running on the HSAIL simulator, which only depends on shared libraries. I found that since AMD CPUs and GPUs have the same vendor ID, this part was not working as intended if you have a system with an AMD CPU with Nvidia GPU so nothing would be offloaded. We will adjust this AMD APU detection when the real HSA system is generally available. >> >> http://cr.openjdk.java.net/~ecaspole/no_amd_hw_check/ >> >> In the course of this change, I moved the gpu::init during the JVM boot up after the arguments are processed so the +UseHSAILSimulator I added earlier will work correctly. >> Let me know what you think, >> Thanks, >> Eric >> > From Vasanth.Venkatachalam at amd.com Fri Nov 22 12:10:05 2013 From: Vasanth.Venkatachalam at amd.com (Venkatachalam, Vasanth) Date: Fri, 22 Nov 2013 20:10:05 +0000 Subject: testing of Math intrinsics Message-ID: <5DD1503F815BD14889DC81D28643E3A75788C2C8@SATLEXDAG02.amd.com> Doug or others- For the case of Math intrinsics implemented for the x86 backend, and especially the transcendental functions (Math.sin, Math.cos...) can you explain what tests you are running to ensure that precision requirements are being met for all possible input values and corner cases? Are there specific test suites you are using for this purpose? Vasanth From doug.simon at oracle.com Fri Nov 22 12:18:28 2013 From: doug.simon at oracle.com (Doug Simon) Date: Fri, 22 Nov 2013 21:18:28 +0100 Subject: testing of Math intrinsics In-Reply-To: <5DD1503F815BD14889DC81D28643E3A75788C2C8@SATLEXDAG02.amd.com> References: <5DD1503F815BD14889DC81D28643E3A75788C2C8@SATLEXDAG02.amd.com> Message-ID: <395E9F9B-F4AB-4DAD-802F-1BB189F9BA51@oracle.com> In addition to the basic tests we have in graal/com.oracle.graal.jtt/src/com/oracle/graal/jtt/lang/Math_*.java, we?ll most likely rely on JCK[1] tests to get complete (or better) coverage. -Doug [1] http://openjdk.java.net/groups/conformance/JckAccess/ On Nov 22, 2013, at 9:10 PM, Venkatachalam, Vasanth wrote: > Doug or others- > > For the case of Math intrinsics implemented for the x86 backend, and especially the transcendental functions (Math.sin, Math.cos...) can you explain what tests you are running to ensure that precision requirements are being met for all possible input values and corner cases? Are there specific test suites you are using for this purpose? > > Vasanth From tom.deneau at amd.com Fri Nov 22 16:58:08 2013 From: tom.deneau at amd.com (Deneau, Tom) Date: Sat, 23 Nov 2013 00:58:08 +0000 Subject: code optimized away before a deopt Message-ID: I've noticed that if I have a snippet that does a test and if the test fails, branches to a block that does some cleanup operations and then calls DeoptimizeNode.deopt(xxx, yyy), the cleanup code gets "optimized away". I guess this is related to what Gilles was talking about, maybe the cleanup operations were considered not state changing? In our current state of HSAIL backend, a deopt just returns early from the kernel. Is there something I can do to make the cleanup code get emitted before the deopt? -- Tom From doug.simon at oracle.com Sat Nov 23 07:39:36 2013 From: doug.simon at oracle.com (Doug Simon) Date: Sat, 23 Nov 2013 16:39:36 +0100 Subject: code optimized away before a deopt In-Reply-To: References: Message-ID: <5C4A5B37-B6B6-4E25-9982-EA0BC543685C@oracle.com> This is done by the ConvertDeoptimizeToGuardPhase which replaces conditionals where one branch ends in a deopt with a GuardNode. This does indeed have the side effect of (silently) deleting all other nodes on that deopt-terminated branch. We should add some code to either make the deletion not silent or better, throw an error if these are any side-effecting nodes that will be deleted. -Doug On Nov 23, 2013, at 1:58 AM, Deneau, Tom wrote: > I've noticed that if I have a snippet that does a test and if the test fails, branches to a block that does some cleanup operations and then calls DeoptimizeNode.deopt(xxx, yyy), the cleanup code gets "optimized away". I guess this is related to what Gilles was talking about, maybe the cleanup operations were considered not state changing? > > In our current state of HSAIL backend, a deopt just returns early from the kernel. Is there something I can do to make the cleanup code get emitted before the deopt? > > -- Tom From lukas.stadler at jku.at Sat Nov 23 08:18:28 2013 From: lukas.stadler at jku.at (Lukas Stadler) Date: Sat, 23 Nov 2013 17:18:28 +0100 Subject: code optimized away before a deopt In-Reply-To: <5C4A5B37-B6B6-4E25-9982-EA0BC543685C@oracle.com> References: <5C4A5B37-B6B6-4E25-9982-EA0BC543685C@oracle.com> Message-ID: <56957525-604C-4321-9A3D-478913744E0C@jku.at> But it _is_ ok to remove side effecting nodes, because we know they will be reexecuted. Maybe the cleanup operations could be part of a special purpose deopt node? - Lukas Von meinem iPhone gesendet > Am 23.11.2013 um 16:39 schrieb Doug Simon : > > This is done by the ConvertDeoptimizeToGuardPhase which replaces conditionals where one branch ends in a deopt with a GuardNode. This does indeed have the side effect of (silently) deleting all other nodes on that deopt-terminated branch. We should add some code to either make the deletion not silent or better, throw an error if these are any side-effecting nodes that will be deleted. > > -Doug > >> On Nov 23, 2013, at 1:58 AM, Deneau, Tom wrote: >> >> I've noticed that if I have a snippet that does a test and if the test fails, branches to a block that does some cleanup operations and then calls DeoptimizeNode.deopt(xxx, yyy), the cleanup code gets "optimized away". I guess this is related to what Gilles was talking about, maybe the cleanup operations were considered not state changing? >> >> In our current state of HSAIL backend, a deopt just returns early from the kernel. Is there something I can do to make the cleanup code get emitted before the deopt? >> >> -- Tom > From doug.simon at oracle.com Sat Nov 23 08:23:58 2013 From: doug.simon at oracle.com (Doug Simon) Date: Sat, 23 Nov 2013 17:23:58 +0100 Subject: code optimized away before a deopt In-Reply-To: <56957525-604C-4321-9A3D-478913744E0C@jku.at> References: <5C4A5B37-B6B6-4E25-9982-EA0BC543685C@oracle.com> <56957525-604C-4321-9A3D-478913744E0C@jku.at> Message-ID: On Nov 23, 2013, at 5:18 PM, Lukas Stadler wrote: > But it _is_ ok to remove side effecting nodes, because we know they will be reelected. Yes, normally, but when you write this pattern in a snippet, then this won?t be true right, since we don?t resume execution in the bytecode of the snippet (yet!). That why I was thinking at least a warning would be a good idea. -Doug > Maybe the cleanup operations could be part of a special purpose deopt node? > > - Lukas > > Von meinem iPhone gesendet > >> Am 23.11.2013 um 16:39 schrieb Doug Simon : >> >> This is done by the ConvertDeoptimizeToGuardPhase which replaces conditionals where one branch ends in a deopt with a GuardNode. This does indeed have the side effect of (silently) deleting all other nodes on that deopt-terminated branch. We should add some code to either make the deletion not silent or better, throw an error if these are any side-effecting nodes that will be deleted. >> >> -Doug >> >>> On Nov 23, 2013, at 1:58 AM, Deneau, Tom wrote: >>> >>> I've noticed that if I have a snippet that does a test and if the test fails, branches to a block that does some cleanup operations and then calls DeoptimizeNode.deopt(xxx, yyy), the cleanup code gets "optimized away". I guess this is related to what Gilles was talking about, maybe the cleanup operations were considered not state changing? >>> >>> In our current state of HSAIL backend, a deopt just returns early from the kernel. Is there something I can do to make the cleanup code get emitted before the deopt? >>> >>> -- Tom >> From duboscq at ssw.jku.at Sat Nov 23 09:26:53 2013 From: duboscq at ssw.jku.at (Gilles Duboscq) Date: Sat, 23 Nov 2013 18:26:53 +0100 Subject: code optimized away before a deopt In-Reply-To: References: <5C4A5B37-B6B6-4E25-9982-EA0BC543685C@oracle.com> <56957525-604C-4321-9A3D-478913744E0C@jku.at> Message-ID: To really understand the problem we would probably need to know exactly what you (Tom) are trying to achieve and how the snippet is used (lowering? of which node? when?...). On Sat, Nov 23, 2013 at 5:23 PM, Doug Simon wrote: > > On Nov 23, 2013, at 5:18 PM, Lukas Stadler wrote: > > > But it _is_ ok to remove side effecting nodes, because we know they will > be reelected. > > Yes, normally, but when you write this pattern in a snippet, then this > won?t be true right, since we don?t resume execution in the bytecode of the > snippet (yet!). That why I was thinking at least a warning would be a good > idea. > > -Doug > > > Maybe the cleanup operations could be part of a special purpose deopt > node? > > > > - Lukas > > > > Von meinem iPhone gesendet > > > >> Am 23.11.2013 um 16:39 schrieb Doug Simon : > >> > >> This is done by the ConvertDeoptimizeToGuardPhase which replaces > conditionals where one branch ends in a deopt with a GuardNode. This does > indeed have the side effect of (silently) deleting all other nodes on that > deopt-terminated branch. We should add some code to either make the > deletion not silent or better, throw an error if these are any > side-effecting nodes that will be deleted. > >> > >> -Doug > >> > >>> On Nov 23, 2013, at 1:58 AM, Deneau, Tom wrote: > >>> > >>> I've noticed that if I have a snippet that does a test and if the test > fails, branches to a block that does some cleanup operations and then calls > DeoptimizeNode.deopt(xxx, yyy), the cleanup code gets "optimized away". I > guess this is related to what Gilles was talking about, maybe the cleanup > operations were considered not state changing? > >>> > >>> In our current state of HSAIL backend, a deopt just returns early from > the kernel. Is there something I can do to make the cleanup code get > emitted before the deopt? > >>> > >>> -- Tom > >> > > From doug.simon at oracle.com Sat Nov 23 18:00:17 2013 From: doug.simon at oracle.com (doug.simon at oracle.com) Date: Sun, 24 Nov 2013 02:00:17 +0000 Subject: hg: graal/graal: 27 new changesets Message-ID: <20131124020216.3CEB1627E9@hg.openjdk.java.net> Changeset: caeacd31800a Author: twisti Date: 2013-11-21 16:49 -0800 URL: http://hg.openjdk.java.net/graal/graal/rev/caeacd31800a replaced == with equals as pointed out by VerifyUsageWithEquals ! graal/com.oracle.graal.lir.amd64/src/com/oracle/graal/lir/amd64/AMD64Move.java Changeset: d737287f5b32 Author: twisti Date: 2013-11-21 16:51 -0800 URL: http://hg.openjdk.java.net/graal/graal/rev/d737287f5b32 ignore ClassNotFoundException when trying to register foreign calls to crypto methods ! graal/com.oracle.graal.hotspot.amd64/src/com/oracle/graal/hotspot/amd64/AMD64HotSpotForeignCallsProvider.java Changeset: e2933e3d4fb0 Author: twisti Date: 2013-11-21 16:52 -0800 URL: http://hg.openjdk.java.net/graal/graal/rev/e2933e3d4fb0 print stack traces when doing CompileTheWorld ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/CompileTheWorld.java Changeset: 5465ba051280 Author: Doug Simon Date: 2013-11-22 15:47 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/5465ba051280 HSAIL: removed AMD GPU detection until a) clashing AMD CPU and GPU vendor ID issue is resolved and b) HSA port is more complete Contributed-by: Eric Caspole ! src/os_gpu/linux_ptx/vm/gpu_linux.cpp ! src/share/vm/runtime/thread.cpp Changeset: 166ed1584f30 Author: Doug Simon Date: 2013-11-22 15:51 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/166ed1584f30 HSAIL: null checks when loading Okra library functions Contributed-by: Eric Caspole ! src/gpu/hsail/vm/gpu_hsail.cpp ! src/gpu/hsail/vm/gpu_hsail.hpp Changeset: 0267afb6816b Author: Doug Simon Date: 2013-11-22 20:14 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/0267afb6816b Merge. Changeset: 99dcb236aaad Author: Doug Simon Date: 2013-11-22 12:15 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/99dcb236aaad fixed faulty logic in makefiles when compressed FDS builds are disabled ! make/bsd/makefiles/jsig.make ! make/bsd/makefiles/saproc.make ! make/bsd/makefiles/vm.make ! make/linux/makefiles/jsig.make ! make/linux/makefiles/vm.make ! make/solaris/makefiles/jsig.make ! make/solaris/makefiles/vm.make Changeset: d511d688b782 Author: Doug Simon Date: 2013-11-22 21:08 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/d511d688b782 re-enabled TieredCompilation when GRAAL is defined by handling abstract types in profiles gathered by C1 ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/InliningUtil.java ! src/cpu/sparc/vm/c2_globals_sparc.hpp ! src/cpu/x86/vm/c2_globals_x86.hpp Changeset: 124860fac470 Author: Doug Simon Date: 2013-11-22 21:09 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/124860fac470 Merge. Changeset: 37b166b8f08e Author: Christian Wimmer Date: 2013-11-22 11:52 -0800 URL: http://hg.openjdk.java.net/graal/graal/rev/37b166b8f08e Reintroduce constructor used by node intrinsics ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/extended/ReadNode.java Changeset: a4eb86dc383e Author: Christian Wimmer Date: 2013-11-22 11:53 -0800 URL: http://hg.openjdk.java.net/graal/graal/rev/a4eb86dc383e Bugfix: WriteNode needs to return stateAfter so that it is processed by escape analysis ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/extended/WriteNode.java Changeset: c6ab6ae1b360 Author: Christian Wimmer Date: 2013-11-22 11:55 -0800 URL: http://hg.openjdk.java.net/graal/graal/rev/c6ab6ae1b360 Allow subclasses of NewInstanceNode and NewArrayNode to provide the default values used by escape analysis ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/java/NewArrayNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/java/NewInstanceNode.java Changeset: a4593e99f1ea Author: Christian Wimmer Date: 2013-11-22 11:55 -0800 URL: http://hg.openjdk.java.net/graal/graal/rev/a4593e99f1ea Lower LoadHubNode in all late stages ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/extended/LoadHubNode.java Changeset: aa9be8414779 Author: Christian Wimmer Date: 2013-11-22 11:56 -0800 URL: http://hg.openjdk.java.net/graal/graal/rev/aa9be8414779 Canonicalize GuardingPiNode to PiNode when guard is unnecessary ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/GuardingPiNode.java Changeset: c65150049959 Author: Christian Wimmer Date: 2013-11-22 11:57 -0800 URL: http://hg.openjdk.java.net/graal/graal/rev/c65150049959 Allow DeoptimizeNode and UnwindNode to be lowered ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotLoweringProvider.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/DeoptimizeNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/UnwindNode.java Changeset: c07055d2c66e Author: Christian Wimmer Date: 2013-11-22 11:58 -0800 URL: http://hg.openjdk.java.net/graal/graal/rev/c07055d2c66e Fix assertion error message ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/LoweringPhase.java Changeset: f42f1f5d5ce0 Author: Christian Wimmer Date: 2013-11-22 11:59 -0800 URL: http://hg.openjdk.java.net/graal/graal/rev/f42f1f5d5ce0 Allow custom field offset providers ! graal/com.oracle.graal.graph/src/com/oracle/graal/graph/NodeClass.java ! graal/com.oracle.graal.lir/src/com/oracle/graal/lir/CompositeValueClass.java ! graal/com.oracle.graal.lir/src/com/oracle/graal/lir/LIRInstructionClass.java Changeset: c9660efac5f6 Author: Christian Wimmer Date: 2013-11-22 12:02 -0800 URL: http://hg.openjdk.java.net/graal/graal/rev/c9660efac5f6 Factor out methods that use reflection so that they can be substituted ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/InliningUtil.java ! graal/com.oracle.graal.replacements/src/com/oracle/graal/replacements/ReplacementsImpl.java Changeset: 3a05ef752a40 Author: Christian Wimmer Date: 2013-11-22 12:12 -0800 URL: http://hg.openjdk.java.net/graal/graal/rev/3a05ef752a40 Introduce option to disable deoptimization grouping ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/phases/HighTier.java ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/phases/MidTier.java ! graal/com.oracle.graal.phases/src/com/oracle/graal/phases/GraalOptions.java Changeset: 103a0003db01 Author: Christian Wimmer Date: 2013-11-22 12:13 -0800 URL: http://hg.openjdk.java.net/graal/graal/rev/103a0003db01 Introduce ComparableWord and PointerBase into the Word type hierarchy + graal/com.oracle.graal.word/src/com/oracle/graal/word/ComparableWord.java ! graal/com.oracle.graal.word/src/com/oracle/graal/word/Pointer.java + graal/com.oracle.graal.word/src/com/oracle/graal/word/PointerBase.java ! graal/com.oracle.graal.word/src/com/oracle/graal/word/Signed.java ! graal/com.oracle.graal.word/src/com/oracle/graal/word/Unsigned.java ! graal/com.oracle.graal.word/src/com/oracle/graal/word/Word.java Changeset: 5d4b75c35f59 Author: Christian Wimmer Date: 2013-11-22 12:16 -0800 URL: http://hg.openjdk.java.net/graal/graal/rev/5d4b75c35f59 Support lowering of control sink nodes; annotate parameters to make node class invariant checker happy ! graal/com.oracle.graal.replacements/src/com/oracle/graal/replacements/SnippetTemplate.java Changeset: 922dd1415c0a Author: Christian Wimmer Date: 2013-11-22 12:17 -0800 URL: http://hg.openjdk.java.net/graal/graal/rev/922dd1415c0a Commit pass target as a parameter to ReplacementImpl, so that it does not require a CodeCacheProvider ! graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/GraalCompilerTest.java ! graal/com.oracle.graal.hotspot.amd64/src/com/oracle/graal/hotspot/amd64/AMD64HotSpotBackendFactory.java ! graal/com.oracle.graal.hotspot.hsail/src/com/oracle/graal/hotspot/hsail/HSAILHotSpotBackendFactory.java ! graal/com.oracle.graal.hotspot.hsail/src/com/oracle/graal/hotspot/hsail/HSAILHotSpotReplacementsImpl.java ! graal/com.oracle.graal.hotspot.sparc/src/com/oracle/graal/hotspot/sparc/SPARCHotSpotBackendFactory.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/HotSpotReplacementsImpl.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/stubs/ForeignCallStub.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/ReplacementsImpl.java ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/TruffleReplacements.java Changeset: dfb8de11d1bf Author: Christian Wimmer Date: 2013-11-22 12:18 -0800 URL: http://hg.openjdk.java.net/graal/graal/rev/dfb8de11d1bf Make graph builder more extensible by subclasses ! graal/com.oracle.graal.java/src/com/oracle/graal/java/GraphBuilderPhase.java Changeset: 6217f601e65d Author: Christian Wimmer Date: 2013-11-22 12:19 -0800 URL: http://hg.openjdk.java.net/graal/graal/rev/6217f601e65d Allow addresses with an arbitrary scale value; fix handling of unsigned int-to-long conversion ! graal/com.oracle.graal.asm.amd64/src/com/oracle/graal/asm/amd64/AMD64Address.java ! graal/com.oracle.graal.compiler.amd64/src/com/oracle/graal/compiler/amd64/AMD64LIRGenerator.java ! graal/com.oracle.graal.lir.amd64/src/com/oracle/graal/lir/amd64/AMD64AddressValue.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/FixedGuardNode.java Changeset: c7ce697ddb9a Author: Christian Wimmer Date: 2013-11-22 12:19 -0800 URL: http://hg.openjdk.java.net/graal/graal/rev/c7ce697ddb9a Improvements and bugfixes of word type rewriter ! 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.word/src/com/oracle/graal/word/phases/WordTypeRewriterPhase.java Changeset: 3adfe375b01b Author: Christian Wimmer Date: 2013-11-22 13:41 -0800 URL: http://hg.openjdk.java.net/graal/graal/rev/3adfe375b01b Merge ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/InliningUtil.java Changeset: 438ed35bed29 Author: Christian Wimmer Date: 2013-11-22 15:32 -0800 URL: http://hg.openjdk.java.net/graal/graal/rev/438ed35bed29 Change PhaseContext so that it does not subclass Providers, to avoid leaking low-level provider objects such as the CodeCacheProvdier to high-level optimization phases ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/ArrayCopyNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/spi/LoweringTool.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/LoweringPhase.java ! graal/com.oracle.graal.phases/src/com/oracle/graal/phases/tiers/HighTierContext.java ! graal/com.oracle.graal.phases/src/com/oracle/graal/phases/tiers/PhaseContext.java ! graal/com.oracle.graal.phases/src/com/oracle/graal/phases/util/Providers.java ! graal/com.oracle.graal.replacements/src/com/oracle/graal/replacements/nodes/MacroNode.java From tom.deneau at amd.com Sun Nov 24 11:26:47 2013 From: tom.deneau at amd.com (Deneau, Tom) Date: Sun, 24 Nov 2013 19:26:47 +0000 Subject: code optimized away before a deopt In-Reply-To: References: <5C4A5B37-B6B6-4E25-9982-EA0BC543685C@oracle.com> <56957525-604C-4321-9A3D-478913744E0C@jku.at> Message-ID: Gilles -- By adding another test before the call to DeoptimizeNode.deopt I was able to get the cleanup to happen. But I agree with Doug, a warning would be helpful in such a situation (for novice snippet writers). Our situation: We were experimenting with our own implementation of newInstance snippet. There are cases when we reach the end of a tlab where some of the tlab fields are in an inconsistent state and need to be cleaned up and we also need to end the kernel with an error condition (since we can't yet recover from this by getting a new tlab in this situation). But we want to leave the tlab in a consistent state before we exit. Currently we don't really handle deoptimization yet at all, but it does end up generating code to return early from the HSAIL kernel. So calling DeoptimizeNode.deopt from the snippet seemed like one way to exit early. However, as I think about it, using DeoptimizeNode.deopt is probably the wrong way to handle this early exit situation (especially in light of cleanup code possibly being optimized away). (although I'm not really sure what other means we could use to early exit). -- Tom -----Original Message----- From: graal-dev-bounces at openjdk.java.net [mailto:graal-dev-bounces at openjdk.java.net] On Behalf Of Gilles Duboscq Sent: Saturday, November 23, 2013 11:27 AM To: Doug Simon Cc: Lukas Stadler; graal-dev at openjdk.java.net Subject: Re: code optimized away before a deopt To really understand the problem we would probably need to know exactly what you (Tom) are trying to achieve and how the snippet is used (lowering? of which node? when?...). On Sat, Nov 23, 2013 at 5:23 PM, Doug Simon wrote: > > On Nov 23, 2013, at 5:18 PM, Lukas Stadler wrote: > > > But it _is_ ok to remove side effecting nodes, because we know they > > will > be reelected. > > Yes, normally, but when you write this pattern in a snippet, then this > won?t be true right, since we don?t resume execution in the bytecode > of the snippet (yet!). That why I was thinking at least a warning > would be a good idea. > > -Doug > > > Maybe the cleanup operations could be part of a special purpose > > deopt > node? > > > > - Lukas > > > > Von meinem iPhone gesendet > > > >> Am 23.11.2013 um 16:39 schrieb Doug Simon : > >> > >> This is done by the ConvertDeoptimizeToGuardPhase which replaces > conditionals where one branch ends in a deopt with a GuardNode. This > does indeed have the side effect of (silently) deleting all other > nodes on that deopt-terminated branch. We should add some code to > either make the deletion not silent or better, throw an error if these > are any side-effecting nodes that will be deleted. > >> > >> -Doug > >> > >>> On Nov 23, 2013, at 1:58 AM, Deneau, Tom wrote: > >>> > >>> I've noticed that if I have a snippet that does a test and if the > >>> test > fails, branches to a block that does some cleanup operations and then > calls DeoptimizeNode.deopt(xxx, yyy), the cleanup code gets > "optimized away". I guess this is related to what Gilles was talking > about, maybe the cleanup operations were considered not state changing? > >>> > >>> In our current state of HSAIL backend, a deopt just returns early > >>> from > the kernel. Is there something I can do to make the cleanup code get > emitted before the deopt? > >>> > >>> -- Tom > >> > > From doug.simon at oracle.com Thu Nov 28 05:34:37 2013 From: doug.simon at oracle.com (doug.simon at oracle.com) Date: Thu, 28 Nov 2013 13:34:37 +0000 Subject: hg: graal/graal: 50 new changesets Message-ID: <20131128133733.D3ACE628EA@hg.openjdk.java.net> Changeset: c6a8a3af11ac Author: Doug Simon Date: 2013-11-23 23:19 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/c6a8a3af11ac improved output of method name under -G:+PrintProfilingInformation ! graal/com.oracle.graal.java/src/com/oracle/graal/java/GraphBuilderPhase.java ! graal/com.oracle.graal.phases/src/com/oracle/graal/phases/GraalOptions.java Changeset: f9d908fb3492 Author: Doug Simon Date: 2013-11-23 23:20 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/f9d908fb3492 added toString() to HotSpotMethodData to assist with debugging low-level profile data reading ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotMethodData.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotMethodDataAccessor.java Changeset: 3f1c70baa3bd Author: Doug Simon Date: 2013-11-25 12:46 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/3f1c70baa3bd use separate data structure for canonicalizing ConstantNodes (GRAAL-508) ! graal/com.oracle.graal.api.meta/src/com/oracle/graal/api/meta/Constant.java ! graal/com.oracle.graal.graph/src/com/oracle/graal/graph/Graph.java ! 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.hotspot/src/com/oracle/graal/hotspot/replacements/TypeCheckSnippetUtils.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/ConstantNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/StructuredGraph.java ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/InliningUtil.java ! graal/com.oracle.graal.replacements.test/src/com/oracle/graal/replacements/test/NewMultiArrayTest.java ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/PartialEvaluatorCanonicalizer.java Changeset: 333ec6116aa7 Author: Erik Eckstein Date: 2013-11-25 13:37 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/333ec6116aa7 fixed wrong assert condition in JavaTypeProfile ! graal/com.oracle.graal.api.meta/src/com/oracle/graal/api/meta/JavaTypeProfile.java Changeset: 401830ff96f4 Author: Erik Eckstein Date: 2013-11-25 13:41 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/401830ff96f4 some improvements in Debug logging ! graal/com.oracle.graal.debug/src/com/oracle/graal/debug/Debug.java ! graal/com.oracle.graal.debug/src/com/oracle/graal/debug/Indent.java ! graal/com.oracle.graal.debug/src/com/oracle/graal/debug/internal/DebugScope.java Changeset: 4e599571ddb2 Author: Erik Eckstein Date: 2013-11-25 13:48 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/4e599571ddb2 make graph builder more visible for derived classes; add few indent levels for debug logging ! graal/com.oracle.graal.java/src/com/oracle/graal/java/FrameStateBuilder.java ! graal/com.oracle.graal.java/src/com/oracle/graal/java/GraphBuilderPhase.java Changeset: b6b930315135 Author: Erik Eckstein Date: 2013-11-25 13:49 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/b6b930315135 Use default charset instead of US-ASCII in BasicIdealGraphPrinter ! graal/com.oracle.graal.printer/src/com/oracle/graal/printer/BasicIdealGraphPrinter.java Changeset: 3e5555577ebc Author: Erik Eckstein Date: 2013-11-25 13:53 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/3e5555577ebc improve graph printer API for better suppport of derived classes ! graal/com.oracle.graal.printer/src/com/oracle/graal/printer/GraphPrinterDumpHandler.java ! graal/com.oracle.graal.printer/src/com/oracle/graal/printer/IdealGraphPrinter.java Changeset: ffbfc3e78746 Author: Erik Eckstein Date: 2013-11-25 13:54 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/ffbfc3e78746 extend replacements API to support svm specific snippet handling ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/spi/Replacements.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: 371db31081be Author: Erik Eckstein Date: 2013-11-25 13:56 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/371db31081be Merge Changeset: dcb1f442ca98 Author: Erik Eckstein Date: 2013-11-25 15:19 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/dcb1f442ca98 fix lost method format in graph builder debug logging ! graal/com.oracle.graal.java/src/com/oracle/graal/java/GraphBuilderPhase.java Changeset: 79f52f7e7a08 Author: Roland Schatz Date: 2013-11-25 17:04 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/79f52f7e7a08 Fix typo. ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/OptimizeGuardAnchors.java Changeset: ebb61e1a3a83 Author: Roland Schatz Date: 2013-11-25 17:04 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/ebb61e1a3a83 Use initializeWord in NewObjectSnippets. ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/NewObjectSnippets.java Changeset: 5801a5e3e7e4 Author: Roland Schatz Date: 2013-11-25 17:04 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/5801a5e3e7e4 Assert for checking the input type in NodeClass.updateInputSuccInPlace. ! graal/com.oracle.graal.graph/src/com/oracle/graal/graph/NodeClass.java Changeset: 640516a8ca6b Author: Roland Schatz Date: 2013-11-25 17:06 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/640516a8ca6b Separate class for MemoryProxy and MemoryPhi. ! graal/com.oracle.graal.loop/src/com/oracle/graal/loop/LoopFragment.java ! graal/com.oracle.graal.loop/src/com/oracle/graal/loop/LoopFragmentInside.java + graal/com.oracle.graal.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/PhiNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/ProxyNode.java + graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/spi/MemoryProxy.java ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/FloatingReadPhase.java ! graal/com.oracle.graal.phases/src/com/oracle/graal/phases/schedule/SchedulePhase.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/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: ae0001b445c0 Author: Roland Schatz Date: 2013-11-25 17:10 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/ae0001b445c0 Common base interface for nodes in the memory graph. ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/nodes/BeginLockScopeNode.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/EndLockScopeNode.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/nodes/StubForeignCallNode.java + graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/AbstractMemoryCheckpoint.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/KillingBeginNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/MemoryMapNode.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/ValueNodeUtil.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/extended/ArrayRangeWriteNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/extended/FloatableAccessNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/extended/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/MembarNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/extended/MemoryAccess.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/extended/MemoryCheckpoint.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/ReadNode.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/WriteNode.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/CompareAndSwapNode.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/LoweredCompareAndSwapNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/spi/MemoryProxy.java ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/FloatingReadPhase.java ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/ReadEliminationPhase.java ! graal/com.oracle.graal.phases/src/com/oracle/graal/phases/schedule/SchedulePhase.java ! graal/com.oracle.graal.replacements/src/com/oracle/graal/replacements/SnippetTemplate.java ! graal/com.oracle.graal.replacements/src/com/oracle/graal/replacements/nodes/MacroNode.java Changeset: 1e22792abdbc Author: Roland Schatz Date: 2013-11-25 17:19 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/1e22792abdbc Make GuardNode extensible. + graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/AbstractFixedGuardNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/FixedGuardNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/GuardNode.java ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/GuardLoweringPhase.java Changeset: 1dd9aa5a9ee5 Author: Roland Schatz Date: 2013-11-25 17:23 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/1dd9aa5a9ee5 Deoptimization reason for failed aliasing assumptions. ! 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 ! src/share/vm/runtime/deoptimization.hpp ! src/share/vm/runtime/vmStructs.cpp Changeset: 2e76d94f8383 Author: twisti Date: 2013-11-25 15:10 -0800 URL: http://hg.openjdk.java.net/graal/graal/rev/2e76d94f8383 propagate code-cache-full message up to Java to throw exception instead of crashing VM ! src/share/vm/graal/graalCodeInstaller.cpp ! src/share/vm/graal/graalCompiler.cpp ! src/share/vm/graal/graalCompiler.hpp Changeset: ca10e53c03ab Author: Doug Simon Date: 2013-11-25 17:25 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/ca10e53c03ab put warnings about missing GPU device behind TraceGPUInteraction option ! src/share/vm/graal/graalCompilerToGPU.cpp Changeset: 53b1edcf628f Author: Doug Simon Date: 2013-11-25 17:28 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/53b1edcf628f added support for scoping a change to the current DebugConfig using try-with-resource ! graal/com.oracle.graal.debug/src/com/oracle/graal/debug/Debug.java + graal/com.oracle.graal.debug/src/com/oracle/graal/debug/DebugConfigScope.java + graal/com.oracle.graal.debug/src/com/oracle/graal/debug/DelegatingDebugConfig.java Changeset: 447e912c345c Author: Doug Simon Date: 2013-11-25 17:29 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/447e912c345c suppress messages about expected exception in HSAIL test ! graal/com.oracle.graal.compiler.hsail.test/src/com/oracle/graal/compiler/hsail/test/StaticMethod16InArraysTest.java Changeset: f7504936fcea Author: Doug Simon Date: 2013-11-25 17:30 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/f7504936fcea use new mechanism for scoping a DebugConfig change ! graal/com.oracle.graal.hotspot.test/src/com/oracle/graal/hotspot/test/WriteBarrierVerificationTest.java Changeset: 3214b704060a Author: Doug Simon Date: 2013-11-25 17:31 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/3214b704060a changed default level for HSAIL KernelTester logger to OFF ! graal/com.oracle.graal.compiler.hsail.test.infra/src/com/oracle/graal/compiler/hsail/test/infra/KernelTester.java Changeset: f9723019584e Author: Doug Simon Date: 2013-11-25 17:32 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/f9723019584e put HSAIL test code dumping behind -G:Log ! graal/com.oracle.graal.compiler.hsail.test/src/com/oracle/graal/compiler/hsail/test/BasicHSAILTest.java Changeset: 1baa169508f5 Author: Doug Simon Date: 2013-11-25 18:42 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/1baa169508f5 made DebugScope be AutoCloseable so that try-with-resource can be used to more cleanly manage scopes ! 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 Changeset: 70e6bb85d802 Author: Doug Simon Date: 2013-11-25 23:49 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/70e6bb85d802 cleaned up HotSpotMethodData tracing a little and enabled it when -Dgraal.traceMethodDataFilter=true ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotMethodData.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotResolvedJavaMethod.java Changeset: 0097301f34fa Author: Doug Simon Date: 2013-11-26 00:08 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/0097301f34fa integrated patch from Roland that prevents abstract types showing up in C1 generated type profiles ! src/share/vm/c1/c1_GraphBuilder.cpp Changeset: 107fee7fa3bb Author: Doug Simon Date: 2013-11-26 00:09 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/107fee7fa3bb replace code handling abstract (non-array) types in type profiles with assertions now that it should never occur ! graal/com.oracle.graal.api.meta/src/com/oracle/graal/api/meta/JavaTypeProfile.java ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/InliningUtil.java Changeset: 787357a6de3e Author: Doug Simon Date: 2013-11-26 00:09 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/787357a6de3e Merge. Changeset: 533808334e7b Author: Doug Simon Date: 2013-11-26 00:21 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/533808334e7b renamed parameters of ProfiledMethod and ProfiledType ! graal/com.oracle.graal.api.meta/src/com/oracle/graal/api/meta/JavaMethodProfile.java ! graal/com.oracle.graal.api.meta/src/com/oracle/graal/api/meta/JavaTypeProfile.java Changeset: 680060a794a1 Author: Doug Simon Date: 2013-11-26 00:53 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/680060a794a1 Merge. Changeset: f294b4ee2d47 Author: twisti Date: 2013-11-25 18:39 -0800 URL: http://hg.openjdk.java.net/graal/graal/rev/f294b4ee2d47 make CodeInstallResult enum independent of the actual values in C++ code ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/HotSpotVMConfig.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/bridge/CompilerToVM.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/bridge/CompilerToVMImpl.java ! src/share/vm/graal/graalEnv.hpp ! src/share/vm/graal/vmStructs_graal.hpp ! src/share/vm/runtime/vmStructs.cpp Changeset: c302ab46defe Author: twisti Date: 2013-11-25 18:40 -0800 URL: http://hg.openjdk.java.net/graal/graal/rev/c302ab46defe don't overwrite the values of HotSpotPrintCompilation and HotSpotPrintInlining ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/HotSpotGraalRuntime.java Changeset: bc868f83bcec Author: Roland Schatz Date: 2013-11-26 13:35 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/bc868f83bcec Add aliasing trap reason name. ! src/share/vm/runtime/deoptimization.cpp Changeset: 5df9c590f401 Author: Tom Rodriguez Date: 2013-11-25 15:26 -0800 URL: http://hg.openjdk.java.net/graal/graal/rev/5df9c590f401 remove incorrect should_reexecute assert ! src/share/vm/runtime/vframeArray.cpp Changeset: b00553202ec2 Author: Tom Rodriguez Date: 2013-11-25 15:31 -0800 URL: http://hg.openjdk.java.net/graal/graal/rev/b00553202ec2 add NULL check so that -Xint option works again ! src/share/vm/prims/jni.cpp ! src/share/vm/runtime/java.cpp Changeset: 85b60abfd11f Author: Tom Rodriguez Date: 2013-11-25 15:31 -0800 URL: http://hg.openjdk.java.net/graal/graal/rev/85b60abfd11f Treat block comments as raw strings ! src/share/vm/asm/codeBuffer.cpp Changeset: 57ea5bfec214 Author: Tom Rodriguez Date: 2013-11-26 13:03 -0800 URL: http://hg.openjdk.java.net/graal/graal/rev/57ea5bfec214 Merge Changeset: 74cfcd0fbedf Author: Doug Simon Date: 2013-11-26 18:43 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/74cfcd0fbedf made method substitution take return types into account (GRAAL-612) ! graal/com.oracle.graal.replacements/src/com/oracle/graal/replacements/ReplacementsImpl.java Changeset: 5b58f4746286 Author: Doug Simon Date: 2013-11-26 20:54 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/5b58f4746286 fixed HotSpot compiler test 7184394 (GRAAL-612) ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/CipherBlockChainingSubstitutions.java Changeset: 5c7f67c7ccd4 Author: Doug Simon Date: 2013-11-26 22:15 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/5c7f67c7ccd4 made FrameWithoutBoxing.pack() substitution match the signature of the original ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/substitutions/FrameWithoutBoxingSubstitutions.java Changeset: feff37de4465 Author: Doug Simon Date: 2013-11-26 23:14 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/feff37de4465 Merge. Changeset: 389d40d7d99f Author: Doug Simon Date: 2013-11-27 02:31 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/389d40d7d99f fixed bug in MethodData and added assertion that precomputed size == initialized size reduced diff to upstream HotSpot ! src/share/vm/graal/graalCompilerToVM.cpp ! src/share/vm/oops/methodData.cpp ! src/share/vm/oops/methodData.hpp Changeset: 599eaf3bc4b2 Author: twisti Date: 2013-11-26 11:41 -0800 URL: http://hg.openjdk.java.net/graal/graal/rev/599eaf3bc4b2 get DataLayout tags from VM ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/HotSpotVMConfig.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotMethodData.java ! src/share/vm/runtime/vmStructs.cpp Changeset: 0266ac3b26c0 Author: Doug Simon Date: 2013-11-27 18:53 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/0266ac3b26c0 JDK8: added support for default methods as well as interfaces containing static and private methods + 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 ! graal/com.oracle.graal.api.meta.test/src/com/oracle/graal/api/meta/test/TypeUniverse.java ! graal/com.oracle.graal.api.meta/src/com/oracle/graal/api/meta/ResolvedJavaMethod.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotResolvedJavaMethod.java ! mx/projects Changeset: 6531170a229f Author: Doug Simon Date: 2013-11-27 20:13 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/6531170a229f removed unnecessary use of org.junit.Assume ! graal/com.oracle.graal.api.meta.jdk8.test/src/com/oracle/graal/api/meta/jdk8/test/TestResolvedJavaMethodJDK8.java Changeset: 06d9596a909e Author: Doug Simon Date: 2013-11-27 20:14 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/06d9596a909e refactored all PTX reporting to use PTXTestBase.printReport() ! graal/com.oracle.graal.compiler.ptx.test/src/com/oracle/graal/compiler/ptx/test/ArrayPTXTest.java ! graal/com.oracle.graal.compiler.ptx.test/src/com/oracle/graal/compiler/ptx/test/BasicPTXTest.java ! graal/com.oracle.graal.compiler.ptx.test/src/com/oracle/graal/compiler/ptx/test/ControlPTXTest.java ! graal/com.oracle.graal.compiler.ptx.test/src/com/oracle/graal/compiler/ptx/test/FloatPTXTest.java ! graal/com.oracle.graal.compiler.ptx.test/src/com/oracle/graal/compiler/ptx/test/IntegerPTXTest.java ! graal/com.oracle.graal.compiler.ptx.test/src/com/oracle/graal/compiler/ptx/test/LogicPTXTest.java ! graal/com.oracle.graal.compiler.ptx.test/src/com/oracle/graal/compiler/ptx/test/PTXTestBase.java Changeset: 32f606699ce5 Author: Doug Simon Date: 2013-11-27 20:16 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/32f606699ce5 made ConstantNode optionally be an external node (GRAAL-508) ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/ConstantNode.java Changeset: b199147f187e Author: Bernhard Urban Date: 2013-11-28 13:19 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/b199147f187e C2V: remove unused method ! 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 From doug.simon at oracle.com Sat Nov 30 18:00:56 2013 From: doug.simon at oracle.com (doug.simon at oracle.com) Date: Sun, 01 Dec 2013 02:00:56 +0000 Subject: hg: graal/graal: 16 new changesets Message-ID: <20131201020152.B61BE6294F@hg.openjdk.java.net> Changeset: 6b2d8d20ecbd Author: Bernhard Urban Date: 2013-11-28 14:12 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/6b2d8d20ecbd deoptimization: add helper to minimize hsx diff #resolve GRAAL-531 ! src/share/vm/c1/c1_Runtime1.cpp ! src/share/vm/opto/runtime.cpp ! src/share/vm/prims/jvmtiEnv.cpp ! src/share/vm/prims/jvmtiEnvBase.cpp ! src/share/vm/prims/jvmtiImpl.cpp ! src/share/vm/runtime/deoptimization.cpp ! src/share/vm/runtime/deoptimization.hpp ! src/share/vm/runtime/safepoint.cpp ! src/share/vm/runtime/thread.cpp ! src/share/vm/runtime/vm_operations.cpp Changeset: f444a67ecbae Author: Bernhard Urban Date: 2013-11-28 19:51 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/f444a67ecbae Debug: use silent debug config for sandbox ! graal/com.oracle.graal.debug/src/com/oracle/graal/debug/Debug.java Changeset: 1b9aaf25c609 Author: Bernhard Urban Date: 2013-11-28 19:52 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/1b9aaf25c609 virtualize(): check if stamp is null (GRAAL-609) ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/GuardingPiNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/PiNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/extended/UnsafeCastNode.java Changeset: c50290e743f9 Author: Bernhard Urban Date: 2013-11-28 19:54 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/c50290e743f9 Canonicalizer: when replacing a fixed node with a controlsink, set the next of the replacee *before* calling killCFG() (GRAAL-609) ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/CanonicalizerPhase.java Changeset: 824e40a3a4a1 Author: Bernhard Urban Date: 2013-11-29 10:09 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/824e40a3a4a1 annotate UnsafeCastNode as deprecated ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/extended/UnsafeCastNode.java Changeset: ada266d00876 Author: Christian Wirth Date: 2013-11-29 12:19 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/ada266d00876 fix problem detected by -G:-PartialEscapeAnalysis ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/ObjectCloneNode.java Changeset: 717de4f0b38f Author: Christian Wirth Date: 2013-11-29 12:20 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/717de4f0b38f Merged Changeset: bb992a44734e Author: Gilles Duboscq Date: 2013-11-29 17:40 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/bb992a44734e Fix Compare Canonicalization with 2 converts from different kinds as input Add test case + graal/com.oracle.graal.jtt/src/com/oracle/graal/jtt/optimize/ConvertCompare.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/calc/CompareNode.java Changeset: e343d4623e47 Author: Doug Simon Date: 2013-11-29 20:46 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/e343d4623e47 weakened assertion around type profiles to allow array types (GRAAL-618) ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/InliningUtil.java Changeset: 8569b9e047cd Author: Doug Simon Date: 2013-11-30 01:16 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/8569b9e047cd change debug scopes implementation to prevent extra frames related to mechanism being added to call stack ! graal/com.oracle.graal.compiler.hsail.test/src/com/oracle/graal/compiler/hsail/test/BasicHSAILTest.java ! graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/BoxingEliminationTest.java ! graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/DegeneratedLoopsTest.java ! graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/EliminateNestedCheckCastsTest.java ! graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/FinalizableSubclassTest.java ! graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/FloatingReadTest.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/LoopUnswitchTest.java ! graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/MemoryScheduleTest.java ! graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/PushNodesThroughPiTest.java ! graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/ReadAfterCheckCastTest.java ! graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/SimpleCFGTest.java ! graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/backend/AllocatorTest.java ! graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/ea/EATestBase.java ! graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/inlining/InliningTest.java ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/GraalCompiler.java ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/alloc/LinearScan.java ! 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.test/src/com/oracle/graal/hotspot/test/WriteBarrierAdditionTest.java ! graal/com.oracle.graal.hotspot.test/src/com/oracle/graal/hotspot/test/WriteBarrierVerificationTest.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/CompilationTask.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/HotSpotHostBackend.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/ArrayCopyNode.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/ObjectCloneNode.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/stubs/Stub.java ! graal/com.oracle.graal.java/src/com/oracle/graal/java/BciBlockMapping.java ! graal/com.oracle.graal.loop/src/com/oracle/graal/loop/LoopsData.java ! graal/com.oracle.graal.loop/src/com/oracle/graal/loop/phases/LoopTransformLowPhase.java ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/CanonicalizerPhase.java ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/InliningPhase.java ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/InliningUtil.java ! graal/com.oracle.graal.phases/src/com/oracle/graal/phases/BasePhase.java ! graal/com.oracle.graal.printer/src/com/oracle/graal/printer/DecompilerDebugDumpHandler.java ! graal/com.oracle.graal.printer/src/com/oracle/graal/printer/GraphPrinterDumpHandler.java ! graal/com.oracle.graal.replacements.test/src/com/oracle/graal/replacements/test/MethodSubstitutionTest.java ! graal/com.oracle.graal.replacements/src/com/oracle/graal/replacements/ReplacementsImpl.java ! graal/com.oracle.graal.replacements/src/com/oracle/graal/replacements/SnippetTemplate.java ! graal/com.oracle.graal.replacements/src/com/oracle/graal/replacements/nodes/MacroNode.java ! graal/com.oracle.graal.truffle.test/src/com/oracle/graal/truffle/test/PartialEvaluationTest.java ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/PartialEvaluator.java ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/TruffleCache.java ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/TruffleCompilerImpl.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/EffectsPhase.java ! graal/com.oracle.graal.virtual/src/com/oracle/graal/virtual/phases/ea/IterativeInliningPhase.java Changeset: 9a971210a55a Author: Doug Simon Date: 2013-11-30 01:33 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/9a971210a55a put PTX logging behind the -G:Log option ! graal/com.oracle.graal.compiler.ptx.test/src/com/oracle/graal/compiler/ptx/test/PTXTestBase.java Changeset: bae0869c829a Author: Doug Simon Date: 2013-11-30 01:48 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/bae0869c829a put CompileTheWorldTest logging behind the graal.compileTheWorldTest.log system property ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/CompileTheWorld.java Changeset: ebdc13d9845d Author: Doug Simon Date: 2013-11-30 11:07 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/ebdc13d9845d replaced use of graal.compileTheWorldTest.log system property with a field to control CTW verbosity which is true by default but is set to false by CTW unit test ! graal/com.oracle.graal.hotspot.test/src/com/oracle/graal/hotspot/test/CompileTheWorldTest.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/CompileTheWorld.java Changeset: 833f8e96d0a5 Author: Christian Humer Date: 2013-11-22 14:45 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/833f8e96d0a5 Truffle: improved error mesage for accessing unknonw frame slots. ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/FrameWithoutBoxing.java ! graal/com.oracle.truffle.api/src/com/oracle/truffle/api/impl/DefaultVirtualFrame.java Changeset: 8b14bab15757 Author: Christian Humer Date: 2013-11-30 19:05 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/8b14bab15757 Merge. Changeset: 401e1473c546 Author: Christian Humer Date: 2013-11-30 19:09 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/401e1473c546 Truffle: Implemented basic tracing of truffle compiler tree expansion (-G:+TraceTruffleExpansion, -G:+TraceTruffleExpansionSource) ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/PartialEvaluator.java ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/TruffleCompilerOptions.java + graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/TruffleExpansionLogger.java