From doug.simon at oracle.com Tue Sep 2 01:00:06 2014 From: doug.simon at oracle.com (doug.simon at oracle.com) Date: Tue, 02 Sep 2014 01:00:06 +0000 Subject: hg: graal/graal: improved error reporting by @NodeInfo annotation processor Message-ID: <201409020100.s82106vn021481@aojmv0008> Changeset: 9716891b7342 Author: Doug Simon Date: 2014-09-01 16:46 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/9716891b7342 improved error reporting by @NodeInfo annotation processor ! graal/com.oracle.graal.nodeinfo.processor/src/com/oracle/graal/nodeinfo/processor/GraphNodeGenerator.java ! graal/com.oracle.graal.nodeinfo.processor/src/com/oracle/graal/nodeinfo/processor/GraphNodeProcessor.java From doug.simon at oracle.com Wed Sep 3 01:00:06 2014 From: doug.simon at oracle.com (doug.simon at oracle.com) Date: Wed, 03 Sep 2014 01:00:06 +0000 Subject: hg: graal/graal: 15 new changesets Message-ID: <201409030100.s83107t2008828@aojmv0008> Changeset: 8fd42ea95f64 Author: Christian Humer Date: 2014-09-01 20:08 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/8fd42ea95f64 SL: added assertTrue and assertFalse builtins to SL. + graal/com.oracle.truffle.sl/src/com/oracle/truffle/sl/builtins/SLAssertFalseBuiltin.java + graal/com.oracle.truffle.sl/src/com/oracle/truffle/sl/builtins/SLAssertTrueBuiltin.java ! graal/com.oracle.truffle.sl/src/com/oracle/truffle/sl/runtime/SLContext.java Changeset: 158c9ba66e45 Author: Christian Humer Date: 2014-09-01 20:08 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/158c9ba66e45 SL: added support for guest language stack traces to SLException; added SLAssertionError. + graal/com.oracle.truffle.sl/src/com/oracle/truffle/sl/SLAssertionError.java ! graal/com.oracle.truffle.sl/src/com/oracle/truffle/sl/SLException.java ! graal/com.oracle.truffle.sl/src/com/oracle/truffle/sl/builtins/SLAssertFalseBuiltin.java ! graal/com.oracle.truffle.sl/src/com/oracle/truffle/sl/builtins/SLAssertTrueBuiltin.java ! graal/com.oracle.truffle.sl/src/com/oracle/truffle/sl/nodes/SLRootNode.java Changeset: 112ab4a3de3a Author: Christian Humer Date: 2014-09-01 20:08 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/112ab4a3de3a Truffle: added Graal runtime API to wait for the completion of a compilation. ! graal/com.oracle.graal.truffle.hotspot/src/com/oracle/graal/truffle/hotspot/HotSpotTruffleRuntime.java ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/GraalTruffleRuntime.java Changeset: e9c119927199 Author: Christian Humer Date: 2014-09-01 20:08 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/e9c119927199 SL: added internal APIs to SL for the Graal runtime tests. ! graal/com.oracle.truffle.sl.test/src/com/oracle/truffle/sl/test/SLTestRunner.java ! graal/com.oracle.truffle.sl/src/com/oracle/truffle/sl/nodes/SLRootNode.java Changeset: 004e3f0a0517 Author: Christian Humer Date: 2014-09-01 20:08 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/004e3f0a0517 Truffle: added new infrastructure for graal truffle runtime tests using SL. + graal/com.oracle.graal.truffle.test/sl/TestCompilationThreshold.sl + graal/com.oracle.graal.truffle.test/sl/TestInliningMaxCallerSize.sl + graal/com.oracle.graal.truffle.test/src/com/oracle/graal/truffle/test/SLTruffleGraalTestSuite.java + graal/com.oracle.graal.truffle.test/src/com/oracle/graal/truffle/test/builtins/SLCallUntilOptimizedBuiltin.java + graal/com.oracle.graal.truffle.test/src/com/oracle/graal/truffle/test/builtins/SLDisableSplittingBuiltin.java + graal/com.oracle.graal.truffle.test/src/com/oracle/graal/truffle/test/builtins/SLGenerateDummyNodesBuiltin.java + graal/com.oracle.graal.truffle.test/src/com/oracle/graal/truffle/test/builtins/SLGetOptionBuiltin.java + graal/com.oracle.graal.truffle.test/src/com/oracle/graal/truffle/test/builtins/SLGraalRuntimeBuiltin.java + graal/com.oracle.graal.truffle.test/src/com/oracle/graal/truffle/test/builtins/SLIsInlinedBuiltin.java + graal/com.oracle.graal.truffle.test/src/com/oracle/graal/truffle/test/builtins/SLIsOptimizedBuiltin.java + graal/com.oracle.graal.truffle.test/src/com/oracle/graal/truffle/test/builtins/SLSetOptionBuiltin.java + graal/com.oracle.graal.truffle.test/src/com/oracle/graal/truffle/test/builtins/SLWaitForOptimizationBuiltin.java ! graal/com.oracle.truffle.sl.test/src/com/oracle/truffle/sl/test/SLTestRunner.java ! mx/projects Changeset: 81c9a1fc9072 Author: Doug Simon Date: 2014-09-02 00:44 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/81c9a1fc9072 select generated input and successor iterators if Node.USE_GENERATED_NODES ! 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/NodeClassIterable.java + graal/com.oracle.graal.graph/src/com/oracle/graal/graph/NodePosIterator.java - graal/com.oracle.graal.graph/src/com/oracle/graal/graph/NodeRefIterable.java ! graal/com.oracle.graal.graph/src/com/oracle/graal/graph/NodeRefIterator.java ! graal/com.oracle.graal.graph/src/com/oracle/graal/graph/Position.java ! graal/com.oracle.graal.loop/src/com/oracle/graal/loop/LoopTransformations.java ! graal/com.oracle.graal.loop/src/com/oracle/graal/loop/phases/LoopTransformLowPhase.java ! graal/com.oracle.graal.nodeinfo.processor/src/com/oracle/graal/nodeinfo/processor/GraphNodeGenerator.java ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/OptimizeGuardAnchorsPhase.java ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/TailDuplicationPhase.java ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/cfs/FlowUtil.java ! graal/com.oracle.graal.phases/src/com/oracle/graal/phases/graph/ReentrantNodeIterator.java ! graal/com.oracle.graal.printer/src/com/oracle/graal/printer/CFGPrinter.java ! graal/com.oracle.graal.printer/src/com/oracle/graal/printer/IdealGraphPrinter.java ! graal/com.oracle.truffle.dsl.processor/src/com/oracle/truffle/dsl/processor/java/ElementUtils.java Changeset: 2c04d7665bf6 Author: Doug Simon Date: 2014-09-02 09:56 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/2c04d7665bf6 use the right class loader when loading generated PositionFieldOrder class ! graal/com.oracle.graal.graph/src/com/oracle/graal/graph/NodeClass.java Changeset: 0a036547149c Author: Doug Simon Date: 2014-09-02 10:30 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/0a036547149c use source field declaration order in generated Node classes ! graal/com.oracle.graal.nodeinfo.processor/src/com/oracle/graal/nodeinfo/processor/GraphNodeGenerator.java Changeset: ccd8c2ef112e Author: Doug Simon Date: 2014-09-02 10:30 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/ccd8c2ef112e Merge. Changeset: ad10671d1bbd Author: Bernhard Urban Date: 2014-09-02 14:45 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/ad10671d1bbd mx: move get_arch() to mxtool ! mx/mx_graal.py ! mxtool/mx.py Changeset: 0b2675391d01 Author: Bernhard Urban Date: 2014-09-02 14:46 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/0b2675391d01 mx library: support platform/architecture specific libraries ! mxtool/mx.py Changeset: 6a30738791f7 Author: Bernhard Urban Date: 2014-09-02 14:46 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/6a30738791f7 mx: add helper for determine jli location ! mx/mx_graal.py Changeset: ffddcdca8e74 Author: Bernhard Urban Date: 2014-09-02 14:47 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/ffddcdca8e74 mx: support different name for jvm.cfg ! mx/mx_graal.py Changeset: 3482684330ee Author: Bernhard Urban Date: 2014-09-02 22:19 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/3482684330ee cherry-pick: 8041980: (hotspot) sun/jvmstat/monitor/MonitoredVm/CR6672135.java failing on all platforms Reviewed-by: mgronlun, kamg Contributed-by: sla ! make/bsd/makefiles/mapfile-vers-debug ! make/bsd/makefiles/mapfile-vers-product ! make/linux/makefiles/mapfile-vers-debug ! make/linux/makefiles/mapfile-vers-product ! make/solaris/makefiles/mapfile-vers ! src/share/vm/prims/jvm.cpp ! src/share/vm/prims/jvm.h Changeset: 66bf28082a14 Author: Christian Wimmer Date: 2014-09-02 15:44 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/66bf28082a14 Bugfix: ReadEliminationClosure ignored subclasses of FixedAccessNode that are memory checkpoints ! graal/com.oracle.graal.virtual/src/com/oracle/graal/virtual/phases/ea/ReadEliminationClosure.java From eric.caspole at amd.com Wed Sep 3 14:02:41 2014 From: eric.caspole at amd.com (Eric Caspole) Date: Wed, 3 Sep 2014 10:02:41 -0400 Subject: Problem with HSAIL->interpreter deopt with many variables In-Reply-To: <3E16593D-04EE-4655-9F1C-5063A405BBE4@oracle.com> References: <2AB94C37-7571-43D1-875A-9009C31B5ABA@oracle.com> <53FDE22A.5020002@amd.com> <3E16593D-04EE-4655-9F1C-5063A405BBE4@oracle.com> Message-ID: <54071F81.8030906@amd.com> Yes, that is the exception that should happen there. Thanks Tom. Eric On 08/29/2014 07:08 PM, Tom Rodriguez wrote: > So if I fix this issue, it fails like below. Is the expected? > > tom > > > 1) testUsingLambdaMethod(com.oracle.graal.compiler.hsail.test.lambda.MoreThanEightArgsOOBTest) > java.lang.ArrayIndexOutOfBoundsException: 5000 > at com.oracle.graal.compiler.hsail.test.lambda.MoreThanEightArgsOOBTest.lambda$innerTest$0(MoreThanEightArgsOOBTest.java:62) > at com.oracle.graal.hotspot.hsail.HSAILHotSpotBackend.executeKernel0(Native Method) > at com.oracle.graal.hotspot.hsail.HSAILHotSpotBackend.executeKernel(HSAILHotSpotBackend.java:380) > at com.oracle.graal.compiler.hsail.test.infra.GraalKernelTester.dispatchKernelOkra(GraalKernelTester.java:172) > at com.oracle.graal.compiler.hsail.test.infra.KernelTester.dispatchLambdaMethodKernelOkra(KernelTester.java:591) > at com.oracle.graal.compiler.hsail.test.infra.KernelTester.dispatchLambdaMethodKernel(KernelTester.java:272) > at com.oracle.graal.compiler.hsail.test.infra.KernelTester.dispatchLambdaKernel(KernelTester.java:294) > at com.oracle.graal.compiler.hsail.test.lambda.MoreThanEightArgsOOBTest.innerTest(MoreThanEightArgsOOBTest.java:51) > at com.oracle.graal.compiler.hsail.test.lambda.MoreThanEightArgsOOBTest.runTest(MoreThanEightArgsOOBTest.java:82) > at com.oracle.graal.compiler.hsail.test.infra.KernelTester.runOkraInstance(KernelTester.java:659) > at com.oracle.graal.compiler.hsail.test.infra.KernelTester.assertOkraEqualsSeq(KernelTester.java:645) > at com.oracle.graal.compiler.hsail.test.infra.KernelTester.testGeneratedHsailUsingLambdaMethod(KernelTester.java:676) > at com.oracle.graal.compiler.hsail.test.infra.GraalKernelTester.testGeneratedHsailUsingLambdaMethod(GraalKernelTester.java:213) > at com.oracle.graal.compiler.hsail.test.lambda.MoreThanEightArgsOOBTest.testUsingLambdaMethod(MoreThanEightArgsOOBTest.java:93) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:483) > at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47) > at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12) > at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44) > at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17) > at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:271) > at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:70) > at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50) > at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238) > at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63) > at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236) > at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53) > at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229) > at org.junit.runners.ParentRunner.run(ParentRunner.java:309) > at org.junit.runners.Suite.runChild(Suite.java:127) > at org.junit.runners.Suite.runChild(Suite.java:26) > at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238) > at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63) > at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236) > at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53) > at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229) > at org.junit.runners.ParentRunner.run(ParentRunner.java:309) > at org.junit.runner.JUnitCore.run(JUnitCore.java:160) > at org.junit.runner.JUnitCore.run(JUnitCore.java:138) > at com.oracle.graal.test.GraalJUnitCore.main(GraalJUnitCore.java:132) > > FAILURES!!! > Tests run: 1, Failures: 1 > > > On Aug 27, 2014, at 6:50 AM, Eric Caspole wrote: > >> Thanks Tom. >> >> On 08/26/2014 05:20 PM, Tom Rodriguez wrote: >>> >>> On Aug 26, 2014, at 11:50 AM, Caspole, Eric wrote: >>> >>>> Hi everybody, >>>> Is it normal to have the deoptimization of a compiled frame sitting >>>> right on top of a call_stub frame called from the C++ code? I don't see any comments in >>>> deoptimization or in the stub generators that mention anything about this. >>> >>> I think the problem is the disagreement between the number of arguments passed through the JavaCall when invoking the trampoline and the number of arguments in the deopt frame state. The deopt code is expecting that the frame of the call_stub has already been adjusted to handle the number of initial arguments for the root of the compile but that hasn?t been done so it?s overwriting part of the call stub frame. This should probably be the responsibility of the call_stub but it would mean that we need to pass some extra info about how much space to pad the frame. Injecting some extra pushes before pushing the real arguments appears to let your test work, or at least not crash. Maybe Gilles has some ideas on other ways to fix this? >>> >>> -XX:+VerifyStack should have complained about this but it?s missing some logic to describe the entry frame so it didn?t detect the overlap. >>> >>> tom >>> >>>> >>>> Here is an example of the stack when this problem happens during a >>>> kernel deoptimization: >>>> >>>> >>>> - Hsail::execute_kernel_void_1d_internal sp=7ff0680 >>>> >>>> - [JavaCall frames] >>>> >>>> - StubRoutines::call_stub sp = 7ff0340 >>>> >>>> - hsail.test.lambda.MoreThanEightArgsOOBTest.lambda$innerTest$139 sp = >>>> 7ff0320 >>>> (This is the compiled "trampoline" for HSAIL deoptimization) >>>> >>>> - UncommonTrapStub.uncommonTrapHandler sp =7ff01a8 >>>> >>>> #2 0x00007ffff645d310 in Deoptimization::unpack_frames >>>> (thread=0x7ffff000d800, exec_mode=2) at >>>> /home/ecaspole/views/graal-default/graal/src/share/vm/runtime/deoptimization.cpp:611 >>>> >>>> #1 0x00007ffff6a99921 in vframeArray::unpack_to_stack >>>> (this=0x7ffff0954d58, unpack_frame=..., exec_mode=2, >>>> caller_actual_parameters=9) at >>>> /home/ecaspole/views/graal-default/graal/src/share/vm/runtime/vframeArray.cpp:598 >>>> >>>> #0 vframeArrayElement::unpack_on_stack (this=0x7ffff0955450, >>>> caller_actual_parameters=9, callee_parameters=0, callee_locals=0, >>>> caller=0x7ffff7fef780, is_top_frame=true, is_bottom_frame=true, >>>> exec_mode=2) at >>>> /home/ecaspole/views/graal-default/graal/src/share/vm/runtime/vframeArray.cpp:328 >>>> >>>> top frame $rsp=0x7ffff7fee7e0 >>>> >>>> _this->_frame size = 10, >>>> sender frame size = 283 (this is theStubRoutines::call_stub frame) >>>> >>>> >>>> (gdb) p this->_frame >>>> $5 = { >>>> _sp = 0x7ffff7ff02c8, >>>> _pc = 0x7fffdc00a7a0 "H\307", , >>>> _cb = 0x7fffdc005390, >>>> _deopt_state = frame::not_deoptimized, >>>> static _check_value = { >>>> = { >>>> = { >>>> = { >>>> = { >>>> _vptr.AllocatedObj = 0x7ffff72e57b0 >>>> }, }, >>>> members of Closure: >>>> _abort = false >>>> }, }, }, >>>> static _check_oop = { >>>> = { >>>> = { >>>> = { >>>> = { >>>> _vptr.AllocatedObj = 0x7ffff72e5770 >>>> }, }, >>>> members of Closure: >>>> _abort = false >>>> }, }, }, >>>> static _zap_dead = { >>>> = { >>>> = { >>>> = { >>>> = { >>>> _vptr.AllocatedObj = 0x7ffff72e5730 >>>> }, }, >>>> members of Closure: >>>> _abort = false >>>> }, }, }, >>>> _fp = 0x7ffff7ff0308, >>>> _unextended_sp = 0x7ffff7ff02c8 >>>> } >>>> (gdb) >>>> >>>> 365 for(i = 0; i < locals()->size(); i++) { >>>> (gdb) >>>> 366 StackValue *value = locals()->at(i); >>>> (gdb) >>>> 367 intptr_t* addr = iframe()->interpreter_frame_local_at(i); >>>> (gdb) >>>> 368 switch(value->type()) { >>>> (gdb) p addr >>>> $6 = (intptr_t *) 0x7ffff7ff0380 >>>> >>>> So here you can see that addr, where locals will be written, is well >>>> above the SP of StubRoutines::call_stub (7ff0340), and it overwrites the >>>> callee-saves saved in the call_stub frame. Depending on how many locals >>>> get restored here in the wrong place, this may or may not cause a crash >>>> after returning all the way back to execute_kernel_void_1d_internal. >>>> >>>> I put a better test than before at: http://cr.openjdk.java.net/~ecaspole/MoreThanEightArgsOOBTest.java >>>> >>>> I run it like: ./mx.sh -V --vmbuild debug --vm server unittest -Xms2g -Xmx2g -XX:+TraceGPUInteraction -XX:+PrintGCDetails -XX:-UseCompressedOops -Dkerneltester.runOkraFirst=true hsail.test.lambda.MoreThanEightArgsOOBTest >>>> >>>> Thanks for any advice on this, >>>> Eric >>>> >>>> >>>> >>>> >>>> >>>> -------- Original Message -------- >>>> Subject: Problem with HSAIL->interpreter deopt with many variables >>>> Date: Thu, 21 Aug 2014 22:50:11 +0000 >>>> From: Caspole, Eric >>>> To: graal-dev at openjdk.java.net >>>> >>>> I think I found a problem with the HSAIL deoptimization back to >>>> interpreter when there are a lot of locals in the offloaded lambda. From >>>> what I have seen so far it looks like if there are more than about 8 >>>> locals, and I am not sure what is the mix of ints and objects, when the >>>> locals get restored into the new interpreter frame in >>>> vframeArrayElement::unpack_on_stack(), it writes into the stack frame of >>>> call_stub() that is used when calling from the hsail C++ code to the x86 >>>> trampoline for the method. >>>> >>>> I put a test case that shows working/crashing just by switching 2 lines >>>> of code at >>>> http://cr.openjdk.java.net/~ecaspole/OtherArgsWithCompSafepointTest.java >>>> Just switch the lines around at line 47 to see it work or crash. >>>> In this test to see the crash you have to take a safepoint and >>>> deoptimize on the compiler safepoint in the loop in the kernel. >>>> Run it with : ./mx.sh --vmbuild debug --vm server unittest >>>> -XX:+TraceGPUInteraction hsail.test.lambda.OtherArgsWithCompSafepointTest >>>> >>>> When the problem happens, it over writes the callee saves in call_stub >>>> so it ends up crashing in the hsail C++ code or near there. >>>> I am not sure if this problem has always been there since we have very >>>> few test cases with this many variables. >>>> >>>> I am not familiar with how the frames are created on a deopt. Could >>>> someone give me some hints about this? How is the newly created frame >>>> placed relative to the caller frames? How is the size of that frame >>>> determined? >>>> >>>> Thanks, >>>> Eric >>>> >>>> >>>> >>>> >>>> Here is one example crash from this test case - >>>> # >>>> # A fatal error has been detected by the Java Runtime Environment: >>>> # >>>> # SIGSEGV (0xb) at pc=0x00007fd250000770, pid=835, tid=140541751068416 >>>> # >>>> # JRE version: OpenJDK Runtime Environment (8.0) (build >>>> 1.8.0-internal-ecaspole_2014_06_09_09_40-b00) >>>> # Java VM: OpenJDK 64-Bit Server VM >>>> (25.0-b63-internal-graal-0.5-dev-debug mixed mode linux-amd64 ) >>>> # Problematic frame: >>>> # v ~StubRoutines::call_stub >>>> # >>>> # Core dump written. Default location: >>>> /home/ecaspole/views/graal-deopt-size/graal/core or core.835 >>>> # >>>> # An error report file with more information is saved as: >>>> # /home/ecaspole/views/graal-deopt-size/graal/hs_err_pid835.log >>>> Loaded disassembler from >>>> /home/ecaspole/views/graal-deopt-size/graal/jdk1.8.0-internal/debug/jre/lib/amd64/hsdis-amd64.so >>>> # >>>> # If you would like to submit a bug report, please visit: >>>> # http://bugreport.sun.com/bugreport/crash.jsp >>>> # >>>> >>>> >>>> >>> > From tom.rodriguez at oracle.com Wed Sep 3 19:57:51 2014 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Wed, 3 Sep 2014 12:57:51 -0700 Subject: Problem with HSAIL->interpreter deopt with many variables In-Reply-To: <54071F81.8030906@amd.com> References: <2AB94C37-7571-43D1-875A-9009C31B5ABA@oracle.com> <53FDE22A.5020002@amd.com> <3E16593D-04EE-4655-9F1C-5063A405BBE4@oracle.com> <54071F81.8030906@amd.com> Message-ID: <1FC694CB-8BAF-48CF-AEC3-7FA2306C6BF5@oracle.com> I pushed a fix for this issue. The special deopt adapter now takes an extra argument which is the number arguments expected if the root method were invoked normally. The adapter then extends the caller frame by the difference between the number of arguments actually passed and that number. I also pushed a fix so that -XX:+VerifyStack would have complained about this issue. tom On Sep 3, 2014, at 7:02 AM, Eric Caspole wrote: > Yes, that is the exception that should happen there. > Thanks Tom. > Eric > > > On 08/29/2014 07:08 PM, Tom Rodriguez wrote: >> So if I fix this issue, it fails like below. Is the expected? >> >> tom >> >> >> 1) testUsingLambdaMethod(com.oracle.graal.compiler.hsail.test.lambda.MoreThanEightArgsOOBTest) >> java.lang.ArrayIndexOutOfBoundsException: 5000 >> at com.oracle.graal.compiler.hsail.test.lambda.MoreThanEightArgsOOBTest.lambda$innerTest$0(MoreThanEightArgsOOBTest.java:62) >> at com.oracle.graal.hotspot.hsail.HSAILHotSpotBackend.executeKernel0(Native Method) >> at com.oracle.graal.hotspot.hsail.HSAILHotSpotBackend.executeKernel(HSAILHotSpotBackend.java:380) >> at com.oracle.graal.compiler.hsail.test.infra.GraalKernelTester.dispatchKernelOkra(GraalKernelTester.java:172) >> at com.oracle.graal.compiler.hsail.test.infra.KernelTester.dispatchLambdaMethodKernelOkra(KernelTester.java:591) >> at com.oracle.graal.compiler.hsail.test.infra.KernelTester.dispatchLambdaMethodKernel(KernelTester.java:272) >> at com.oracle.graal.compiler.hsail.test.infra.KernelTester.dispatchLambdaKernel(KernelTester.java:294) >> at com.oracle.graal.compiler.hsail.test.lambda.MoreThanEightArgsOOBTest.innerTest(MoreThanEightArgsOOBTest.java:51) >> at com.oracle.graal.compiler.hsail.test.lambda.MoreThanEightArgsOOBTest.runTest(MoreThanEightArgsOOBTest.java:82) >> at com.oracle.graal.compiler.hsail.test.infra.KernelTester.runOkraInstance(KernelTester.java:659) >> at com.oracle.graal.compiler.hsail.test.infra.KernelTester.assertOkraEqualsSeq(KernelTester.java:645) >> at com.oracle.graal.compiler.hsail.test.infra.KernelTester.testGeneratedHsailUsingLambdaMethod(KernelTester.java:676) >> at com.oracle.graal.compiler.hsail.test.infra.GraalKernelTester.testGeneratedHsailUsingLambdaMethod(GraalKernelTester.java:213) >> at com.oracle.graal.compiler.hsail.test.lambda.MoreThanEightArgsOOBTest.testUsingLambdaMethod(MoreThanEightArgsOOBTest.java:93) >> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) >> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) >> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) >> at java.lang.reflect.Method.invoke(Method.java:483) >> at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47) >> at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12) >> at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44) >> at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17) >> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:271) >> at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:70) >> at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50) >> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238) >> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63) >> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236) >> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53) >> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229) >> at org.junit.runners.ParentRunner.run(ParentRunner.java:309) >> at org.junit.runners.Suite.runChild(Suite.java:127) >> at org.junit.runners.Suite.runChild(Suite.java:26) >> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238) >> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63) >> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236) >> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53) >> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229) >> at org.junit.runners.ParentRunner.run(ParentRunner.java:309) >> at org.junit.runner.JUnitCore.run(JUnitCore.java:160) >> at org.junit.runner.JUnitCore.run(JUnitCore.java:138) >> at com.oracle.graal.test.GraalJUnitCore.main(GraalJUnitCore.java:132) >> >> FAILURES!!! >> Tests run: 1, Failures: 1 >> >> >> On Aug 27, 2014, at 6:50 AM, Eric Caspole wrote: >> >>> Thanks Tom. >>> >>> On 08/26/2014 05:20 PM, Tom Rodriguez wrote: >>>> >>>> On Aug 26, 2014, at 11:50 AM, Caspole, Eric wrote: >>>> >>>>> Hi everybody, >>>>> Is it normal to have the deoptimization of a compiled frame sitting >>>>> right on top of a call_stub frame called from the C++ code? I don't see any comments in >>>>> deoptimization or in the stub generators that mention anything about this. >>>> >>>> I think the problem is the disagreement between the number of arguments passed through the JavaCall when invoking the trampoline and the number of arguments in the deopt frame state. The deopt code is expecting that the frame of the call_stub has already been adjusted to handle the number of initial arguments for the root of the compile but that hasn?t been done so it?s overwriting part of the call stub frame. This should probably be the responsibility of the call_stub but it would mean that we need to pass some extra info about how much space to pad the frame. Injecting some extra pushes before pushing the real arguments appears to let your test work, or at least not crash. Maybe Gilles has some ideas on other ways to fix this? >>>> >>>> -XX:+VerifyStack should have complained about this but it?s missing some logic to describe the entry frame so it didn?t detect the overlap. >>>> >>>> tom >>>> >>>>> >>>>> Here is an example of the stack when this problem happens during a >>>>> kernel deoptimization: >>>>> >>>>> >>>>> - Hsail::execute_kernel_void_1d_internal sp=7ff0680 >>>>> >>>>> - [JavaCall frames] >>>>> >>>>> - StubRoutines::call_stub sp = 7ff0340 >>>>> >>>>> - hsail.test.lambda.MoreThanEightArgsOOBTest.lambda$innerTest$139 sp = >>>>> 7ff0320 >>>>> (This is the compiled "trampoline" for HSAIL deoptimization) >>>>> >>>>> - UncommonTrapStub.uncommonTrapHandler sp =7ff01a8 >>>>> >>>>> #2 0x00007ffff645d310 in Deoptimization::unpack_frames >>>>> (thread=0x7ffff000d800, exec_mode=2) at >>>>> /home/ecaspole/views/graal-default/graal/src/share/vm/runtime/deoptimization.cpp:611 >>>>> >>>>> #1 0x00007ffff6a99921 in vframeArray::unpack_to_stack >>>>> (this=0x7ffff0954d58, unpack_frame=..., exec_mode=2, >>>>> caller_actual_parameters=9) at >>>>> /home/ecaspole/views/graal-default/graal/src/share/vm/runtime/vframeArray.cpp:598 >>>>> >>>>> #0 vframeArrayElement::unpack_on_stack (this=0x7ffff0955450, >>>>> caller_actual_parameters=9, callee_parameters=0, callee_locals=0, >>>>> caller=0x7ffff7fef780, is_top_frame=true, is_bottom_frame=true, >>>>> exec_mode=2) at >>>>> /home/ecaspole/views/graal-default/graal/src/share/vm/runtime/vframeArray.cpp:328 >>>>> >>>>> top frame $rsp=0x7ffff7fee7e0 >>>>> >>>>> _this->_frame size = 10, >>>>> sender frame size = 283 (this is theStubRoutines::call_stub frame) >>>>> >>>>> >>>>> (gdb) p this->_frame >>>>> $5 = { >>>>> _sp = 0x7ffff7ff02c8, >>>>> _pc = 0x7fffdc00a7a0 "H\307", , >>>>> _cb = 0x7fffdc005390, >>>>> _deopt_state = frame::not_deoptimized, >>>>> static _check_value = { >>>>> = { >>>>> = { >>>>> = { >>>>> = { >>>>> _vptr.AllocatedObj = 0x7ffff72e57b0 >>>>> }, }, >>>>> members of Closure: >>>>> _abort = false >>>>> }, }, }, >>>>> static _check_oop = { >>>>> = { >>>>> = { >>>>> = { >>>>> = { >>>>> _vptr.AllocatedObj = 0x7ffff72e5770 >>>>> }, }, >>>>> members of Closure: >>>>> _abort = false >>>>> }, }, }, >>>>> static _zap_dead = { >>>>> = { >>>>> = { >>>>> = { >>>>> = { >>>>> _vptr.AllocatedObj = 0x7ffff72e5730 >>>>> }, }, >>>>> members of Closure: >>>>> _abort = false >>>>> }, }, }, >>>>> _fp = 0x7ffff7ff0308, >>>>> _unextended_sp = 0x7ffff7ff02c8 >>>>> } >>>>> (gdb) >>>>> >>>>> 365 for(i = 0; i < locals()->size(); i++) { >>>>> (gdb) >>>>> 366 StackValue *value = locals()->at(i); >>>>> (gdb) >>>>> 367 intptr_t* addr = iframe()->interpreter_frame_local_at(i); >>>>> (gdb) >>>>> 368 switch(value->type()) { >>>>> (gdb) p addr >>>>> $6 = (intptr_t *) 0x7ffff7ff0380 >>>>> >>>>> So here you can see that addr, where locals will be written, is well >>>>> above the SP of StubRoutines::call_stub (7ff0340), and it overwrites the >>>>> callee-saves saved in the call_stub frame. Depending on how many locals >>>>> get restored here in the wrong place, this may or may not cause a crash >>>>> after returning all the way back to execute_kernel_void_1d_internal. >>>>> >>>>> I put a better test than before at: http://cr.openjdk.java.net/~ecaspole/MoreThanEightArgsOOBTest.java >>>>> >>>>> I run it like: ./mx.sh -V --vmbuild debug --vm server unittest -Xms2g -Xmx2g -XX:+TraceGPUInteraction -XX:+PrintGCDetails -XX:-UseCompressedOops -Dkerneltester.runOkraFirst=true hsail.test.lambda.MoreThanEightArgsOOBTest >>>>> >>>>> Thanks for any advice on this, >>>>> Eric >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> -------- Original Message -------- >>>>> Subject: Problem with HSAIL->interpreter deopt with many variables >>>>> Date: Thu, 21 Aug 2014 22:50:11 +0000 >>>>> From: Caspole, Eric >>>>> To: graal-dev at openjdk.java.net >>>>> >>>>> I think I found a problem with the HSAIL deoptimization back to >>>>> interpreter when there are a lot of locals in the offloaded lambda. From >>>>> what I have seen so far it looks like if there are more than about 8 >>>>> locals, and I am not sure what is the mix of ints and objects, when the >>>>> locals get restored into the new interpreter frame in >>>>> vframeArrayElement::unpack_on_stack(), it writes into the stack frame of >>>>> call_stub() that is used when calling from the hsail C++ code to the x86 >>>>> trampoline for the method. >>>>> >>>>> I put a test case that shows working/crashing just by switching 2 lines >>>>> of code at >>>>> http://cr.openjdk.java.net/~ecaspole/OtherArgsWithCompSafepointTest.java >>>>> Just switch the lines around at line 47 to see it work or crash. >>>>> In this test to see the crash you have to take a safepoint and >>>>> deoptimize on the compiler safepoint in the loop in the kernel. >>>>> Run it with : ./mx.sh --vmbuild debug --vm server unittest >>>>> -XX:+TraceGPUInteraction hsail.test.lambda.OtherArgsWithCompSafepointTest >>>>> >>>>> When the problem happens, it over writes the callee saves in call_stub >>>>> so it ends up crashing in the hsail C++ code or near there. >>>>> I am not sure if this problem has always been there since we have very >>>>> few test cases with this many variables. >>>>> >>>>> I am not familiar with how the frames are created on a deopt. Could >>>>> someone give me some hints about this? How is the newly created frame >>>>> placed relative to the caller frames? How is the size of that frame >>>>> determined? >>>>> >>>>> Thanks, >>>>> Eric >>>>> >>>>> >>>>> >>>>> >>>>> Here is one example crash from this test case - >>>>> # >>>>> # A fatal error has been detected by the Java Runtime Environment: >>>>> # >>>>> # SIGSEGV (0xb) at pc=0x00007fd250000770, pid=835, tid=140541751068416 >>>>> # >>>>> # JRE version: OpenJDK Runtime Environment (8.0) (build >>>>> 1.8.0-internal-ecaspole_2014_06_09_09_40-b00) >>>>> # Java VM: OpenJDK 64-Bit Server VM >>>>> (25.0-b63-internal-graal-0.5-dev-debug mixed mode linux-amd64 ) >>>>> # Problematic frame: >>>>> # v ~StubRoutines::call_stub >>>>> # >>>>> # Core dump written. Default location: >>>>> /home/ecaspole/views/graal-deopt-size/graal/core or core.835 >>>>> # >>>>> # An error report file with more information is saved as: >>>>> # /home/ecaspole/views/graal-deopt-size/graal/hs_err_pid835.log >>>>> Loaded disassembler from >>>>> /home/ecaspole/views/graal-deopt-size/graal/jdk1.8.0-internal/debug/jre/lib/amd64/hsdis-amd64.so >>>>> # >>>>> # If you would like to submit a bug report, please visit: >>>>> # http://bugreport.sun.com/bugreport/crash.jsp >>>>> # >>>>> >>>>> >>>>> >>>> >> From doug.simon at oracle.com Thu Sep 4 01:00:06 2014 From: doug.simon at oracle.com (doug.simon at oracle.com) Date: Thu, 04 Sep 2014 01:00:06 +0000 Subject: hg: graal/graal: 24 new changesets Message-ID: <201409040100.s841077S004780@aojmv0008> Changeset: e91533b86166 Author: Stefan Anzinger Date: 2014-08-28 19:24 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/e91533b86166 [SPARC] Fix dacapo sunflow test (Unordered branching is now implemented right) ! graal/com.oracle.graal.compiler.sparc/src/com/oracle/graal/compiler/sparc/SPARCLIRGenerator.java ! graal/com.oracle.graal.lir.sparc/src/com/oracle/graal/lir/sparc/SPARCControlFlow.java Changeset: 1013a8444746 Author: Stefan Anzinger Date: 2014-08-29 16:04 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/1013a8444746 [SPARC] Assembler fixes ! graal/com.oracle.graal.compiler.sparc/src/com/oracle/graal/compiler/sparc/SPARCLIRGenerator.java ! graal/com.oracle.graal.lir.sparc/src/com/oracle/graal/lir/sparc/SPARCArithmetic.java Changeset: 5c1bc769563e Author: Stefan Anzinger Date: 2014-08-29 16:05 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/5c1bc769563e Merge Changeset: c2437c80c253 Author: Stefan Anzinger Date: 2014-08-29 21:00 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/c2437c80c253 [SPARC] Make scratch register usage safe ! graal/com.oracle.graal.hotspot.sparc/src/com/oracle/graal/hotspot/sparc/SPARCHotSpotBackend.java ! graal/com.oracle.graal.hotspot.sparc/src/com/oracle/graal/hotspot/sparc/SPARCHotSpotDeoptimizeCallerOp.java ! graal/com.oracle.graal.hotspot.sparc/src/com/oracle/graal/hotspot/sparc/SPARCHotSpotNodeLIRBuilder.java ! graal/com.oracle.graal.lir.sparc/src/com/oracle/graal/lir/sparc/SPARCArithmetic.java ! graal/com.oracle.graal.lir.sparc/src/com/oracle/graal/lir/sparc/SPARCControlFlow.java ! graal/com.oracle.graal.lir.sparc/src/com/oracle/graal/lir/sparc/SPARCMove.java + graal/com.oracle.graal.sparc/src/com/oracle/graal/sparc/SPARCScratchRegister.java Changeset: 9364a47125ef Author: Stefan Anzinger Date: 2014-09-02 11:49 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/9364a47125ef Eliminating the lambda expression, as in the recursive call it creates unnecessary stack frames which causes StackOverflowErros sooner ! graal/com.oracle.graal.phases/src/com/oracle/graal/phases/graph/FixedNodeProbabilityCache.java Changeset: 586c1bdd73b8 Author: Stefan Anzinger Date: 2014-09-02 17:08 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/586c1bdd73b8 isDominatedBy made iterative as in huge graphs it may cause stackoverflow (dacapo tomcat tests max depth is about 2.5k recursions) ! graal/com.oracle.graal.compiler.common/src/com/oracle/graal/compiler/common/cfg/AbstractControlFlowGraph.java Changeset: 4e2d34d7715b Author: Stefan Anzinger Date: 2014-09-02 17:16 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/4e2d34d7715b [SPARC/AMD64] Splitting up oopmap generation for Intel XMM and SPARC Floatingpoint registers ! src/cpu/sparc/vm/graalCodeInstaller_sparc.cpp ! src/cpu/x86/vm/graalCodeInstaller_x86.cpp ! src/share/vm/graal/graalCodeInstaller.cpp ! src/share/vm/graal/graalCodeInstaller.hpp Changeset: b23172dcb8f7 Author: Stefan Anzinger Date: 2014-09-02 17:17 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/b23172dcb8f7 [SPARC] Giving now two scratch registers ! graal/com.oracle.graal.lir.sparc/src/com/oracle/graal/lir/sparc/SPARCMove.java ! graal/com.oracle.graal.sparc/src/com/oracle/graal/sparc/SPARCScratchRegister.java Changeset: 8adf60d5ce73 Author: Stefan Anzinger Date: 2014-09-02 17:18 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/8adf60d5ce73 [SPARC] Saving return value to a "real" double register. ! graal/com.oracle.graal.hotspot.sparc/src/com/oracle/graal/hotspot/sparc/SPARCHotSpotLeaveUnpackFramesStackFrameOp.java ! graal/com.oracle.graal.lir.sparc/src/com/oracle/graal/lir/sparc/SPARCSaveRegistersOp.java Changeset: b44535d38d64 Author: Stefan Anzinger Date: 2014-09-02 17:19 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/b44535d38d64 Eliminate the recursion over lambda expression as it generates a huge stack which may cause stack overflow earlier as it should be ! graal/com.oracle.graal.phases/src/com/oracle/graal/phases/graph/FixedNodeProbabilityCache.java Changeset: dc293c1d969c Author: Stefan Anzinger Date: 2014-09-02 17:22 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/dc293c1d969c [SPARC] Fixing conversions of l2d l2f i2d i2f ... Adding assertions for usage of float/double registers to get rid of using wrong encoding in registers ! graal/com.oracle.graal.asm.sparc/src/com/oracle/graal/asm/sparc/SPARCAssembler.java ! graal/com.oracle.graal.compiler.sparc/src/com/oracle/graal/compiler/sparc/SPARCLIRGenerator.java ! graal/com.oracle.graal.lir.sparc/src/com/oracle/graal/lir/sparc/SPARCArithmetic.java Changeset: 790e5e5072a2 Author: Stefan Anzinger Date: 2014-09-02 19:01 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/790e5e5072a2 [SPARC] Checkstyle, blacklist for unittests ! graal/com.oracle.graal.asm.sparc/src/com/oracle/graal/asm/sparc/SPARCAssembler.java ! graal/com.oracle.graal.compiler.sparc/src/com/oracle/graal/compiler/sparc/SPARCLIRGenerator.java ! test/blacklist_sparc.txt Changeset: 2110fe2b7284 Author: Stefan Anzinger Date: 2014-09-02 19:23 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/2110fe2b7284 Merge - graal/com.oracle.graal.graph/src/com/oracle/graal/graph/NodeRefIterable.java Changeset: 4f8c81b1d1cb Author: Stefan Anzinger Date: 2014-09-02 20:50 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/4f8c81b1d1cb Added header to file and jumptable for byte char short ! graal/com.oracle.graal.lir.sparc/src/com/oracle/graal/lir/sparc/SPARCControlFlow.java ! graal/com.oracle.graal.sparc/src/com/oracle/graal/sparc/SPARCScratchRegister.java Changeset: 8f3ece00da4f Author: Tom Rodriguez Date: 2014-09-02 21:42 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/8f3ece00da4f Claim entry_frame slots for VerifyStack ! src/cpu/x86/vm/frame_x86.cpp Changeset: 2d6dd2eebd51 Author: Tom Rodriguez Date: 2014-09-02 21:42 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/2d6dd2eebd51 Fixed HSAIL deopt ! src/cpu/sparc/vm/sharedRuntime_sparc.cpp ! src/cpu/x86/vm/sharedRuntime_x86_32.cpp ! src/cpu/x86/vm/sharedRuntime_x86_64.cpp ! src/gpu/hsail/vm/gpu_hsail.cpp ! src/share/vm/graal/graalRuntime.cpp ! src/share/vm/graal/graalRuntime.hpp ! src/share/vm/runtime/sharedRuntime.hpp Changeset: 86749331247a Author: Gilles Duboscq Date: 2014-09-03 12:00 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/86749331247a Truffle/API: TruffleScriptEngineFactory.engineCreated() is now final Contributed-By: Michael Van De Vanter ! graal/com.oracle.truffle.api/src/com/oracle/truffle/api/script/TruffleScriptEngineFactory.java Changeset: 7b2e6171f455 Author: Gilles Duboscq Date: 2014-09-03 12:01 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/7b2e6171f455 LineLocationToProbeCollectionMap: add forget method ! graal/com.oracle.truffle.api/src/com/oracle/truffle/api/instrument/impl/LineLocationToProbeCollectionMap.java Changeset: 7b45e33b7986 Author: Christian Humer Date: 2014-09-03 14:58 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/7b45e33b7986 Truffle: made TruffleRuntime#getCallTargets return a Collection and simplified its implementation. ! graal/com.oracle.graal.truffle.hotspot/src/com/oracle/graal/truffle/hotspot/HotSpotTruffleRuntime.java ! graal/com.oracle.truffle.api.test/src/com/oracle/truffle/api/test/TruffleRuntimeTest.java ! graal/com.oracle.truffle.api/src/com/oracle/truffle/api/TruffleRuntime.java ! graal/com.oracle.truffle.api/src/com/oracle/truffle/api/impl/DefaultTruffleRuntime.java Changeset: ff0ec169843b Author: Christian Humer Date: 2014-09-03 14:58 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/ff0ec169843b Fixed loop phis with itself as single back value did not canonicalize. (contributed by Lukas Stadler) ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/PhiNode.java Changeset: 3b3e768a2b92 Author: Christian Humer Date: 2014-09-03 14:58 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/3b3e768a2b92 Truffle: run expandTree iteratively to make frame propagations visible to expandTree. ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/PartialEvaluator.java Changeset: 1e542561783e Author: Christian Humer Date: 2014-09-03 14:58 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/1e542561783e Truffle: new value profiles prototype. + graal/com.oracle.truffle.api.test/src/com/oracle/truffle/api/test/utilities/ExactClassValueProfileTest.java + graal/com.oracle.truffle.api.test/src/com/oracle/truffle/api/test/utilities/IdentityValueProfileTest.java + graal/com.oracle.truffle.api/src/com/oracle/truffle/api/utilities/ExactClassValueProfile.java + graal/com.oracle.truffle.api/src/com/oracle/truffle/api/utilities/IdentityValueProfile.java + graal/com.oracle.truffle.api/src/com/oracle/truffle/api/utilities/ValueProfile.java Changeset: df448ee85279 Author: Doug Simon Date: 2014-09-03 16:25 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/df448ee85279 added new version of iteration for Node inputs and successors that allows the iterators to be escape analyzed at the cost of extra polymorphism when accessing Node and NodeList fields during iteration ! graal/com.oracle.graal.graph/src/com/oracle/graal/graph/Node.java + graal/com.oracle.graal.graph/src/com/oracle/graal/graph/NodeAllRefsIterator.java + graal/com.oracle.graal.graph/src/com/oracle/graal/graph/NodeRefIterable.java ! graal/com.oracle.graal.graph/src/com/oracle/graal/graph/NodeRefIterator.java + graal/com.oracle.graal.graph/src/com/oracle/graal/graph/NodeRefWithModCountIterator.java ! graal/com.oracle.graal.nodeinfo.processor/src/com/oracle/graal/nodeinfo/processor/GraphNodeGenerator.java Changeset: 0bf917d4d061 Author: Doug Simon Date: 2014-09-03 18:04 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/0bf917d4d061 temporarily disable use of generated Nodes ! graal/com.oracle.graal.graph/src/com/oracle/graal/graph/Node.java From thomas.wuerthinger at oracle.com Thu Sep 4 18:48:54 2014 From: thomas.wuerthinger at oracle.com (Thomas Wuerthinger) Date: Thu, 4 Sep 2014 20:48:54 +0200 Subject: 1st Virtual Machine Meetup at ETH Zurich Message-ID: We are inviting to the 1st Virtual Machine Meetup at ETH Zurich to exchange ideas with other computer scientists in this area. Presentations will discuss the current state of the art and future directions in virtual machine technology (detailed agenda with talk titles and presenters below). Date: 11th and 12th of September 2014 Time: 9:00 - 16:30 Location: IFW A 32.1 at ETH Zurich Attendance is open, but attendees should register by sending a note to "thomas.wuerthinger at oracle.com? (due to limited seating). Regards, Thomas Wuerthinger Senior Research Manager Oracle Labs ====================================================== Thursday, 11th of September 09:00 - 09:30 Oracle Labs VM Research Overview (Thomas Wuerthinger, Oracle Labs) 09:30 - 10:00 Three Research Threads with Potential Application in Data Analytics (Markus P?schel, Department of Computer Science, ETH Zurich) 10:00 - 10:30 The Oracle - Linz JVM Research Cooperation (Hanspeter M?ssenb?ck, Johannes Kepler University Linz) 10:30 - 11:00 *** Coffee Break *** 11:00 - 11:30 Optimizing Allocations with Partial Escape Analysis (Lukas Stadler, Oracle Labs) 11:30 - 12:00 Late Data Layout: Unifying Data Representation Transformations (Vlad Ureche, Programming Methods Laboratory, EPFL) 13:30 - 14:00 Garbage Collection for Distributed Systems (Tim Harris, Oracle Labs) 14:00 - 14:30 Reflecting on Advanced Distributed Programs (Elisa Gonzalez Boix, Vrije Universiteit Brussel) 14:30 - 15:00 Comprehensive Multi-Platform Dynamic Program Analysis for the Java and Dalvik VM (Walter Binder and Yudi Zheng, University of Lugano) 15:00 - 15:30 *** Coffee Break *** 15:30 - 16:00 Beyond Virtual Machines: Dynamic Control Flow Integrity (Thomas Gross, Laboratory for Software Technology, ETH Zurich) 16:00 - 16:30 EventRacer: Concurrency Analysis for Event-Driven Applications (Martin Vechev, Software Reliability Lab, ETH Zurich) Friday, 12th of September 09:00 - 09:30 Generating Interpreters from DynSem Specifications (Eelco Visser and Vlad Vergu, Delft University of Technology) 09:30 - 10:00 High-performance JavaScript on top of Truffle (Christian Wirth, Oracle Labs) 10:00 - 10:30 Tools for the Development of Correct Software (Peter M?ller, Chair of Programming Methodology, Department of Computer Science, ETH Zurich) 10:30 - 11:00 *** Coffee Break *** 11:00 - 11:30 Purity Analysis for JavaScript (Jens Nicolay, Software Languages Lab, Vrije Universiteit Brussel) 11:30 - 12:00 ScalaMeter (Aleksandar Prokopec, Programming Methods Laboratory, EPFL) 13:30 - 14:00 FastR (Michael Haupt, Oracle Labs) 14:00 - 14:30 Language Integration and Migration (Laurence Tratt, Software Development Team, Informatics, King's College London) 14:30 - 15:00 Language Support for Reactive Applications (Guido Salvaneschi, Technische Universit?t Darmstadt) 15:00 - 15:30 *** Coffee Break *** 15:30 - 16:00 Incremental Updates for Graph Queries (Sandro Stucki, EPFL LAMP & Oracle Labs) 16:00 - 16:30 Space-Time Views For Back-In-Time Debugging (Mohammad Azadmanesh, University of Lugano) From doug.simon at oracle.com Fri Sep 5 01:00:06 2014 From: doug.simon at oracle.com (doug.simon at oracle.com) Date: Fri, 05 Sep 2014 01:00:06 +0000 Subject: hg: graal/graal: 11 new changesets Message-ID: <201409050100.s85107tO007351@aojmv0008> Changeset: 9fe9d32e00b5 Author: Doug Simon Date: 2014-09-04 12:51 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/9fe9d32e00b5 fixed unit tests so that they pass when assertions are disabled ! graal/com.oracle.graal.graph.test/src/com/oracle/graal/graph/test/NodeMapTest.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/phases/WriteBarrierVerificationPhase.java Changeset: 46cefd15ba3f Author: Doug Simon Date: 2014-09-04 12:54 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/46cefd15ba3f NodeRefIterator advances lazily instead of eagerly, allowing the next element to be cached in the advance operation + graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/NodeRefIteratorTest.java ! graal/com.oracle.graal.graph/src/com/oracle/graal/graph/NodeAllRefsIterator.java ! graal/com.oracle.graal.graph/src/com/oracle/graal/graph/NodeRefIterable.java ! graal/com.oracle.graal.graph/src/com/oracle/graal/graph/NodeRefIterator.java ! graal/com.oracle.graal.graph/src/com/oracle/graal/graph/NodeRefWithModCountIterator.java ! graal/com.oracle.graal.nodeinfo.processor/src/com/oracle/graal/nodeinfo/processor/GraphNodeGenerator.java Changeset: d5289a18cf5d Author: Doug Simon Date: 2014-09-04 13:08 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/d5289a18cf5d NodeClassIterator advances lazily instead of eagerly, allowing the next element to be cached in the advance operation ! graal/com.oracle.graal.graph/src/com/oracle/graal/graph/NodeClass.java Changeset: 7c12f8aae0c9 Author: Doug Simon Date: 2014-09-04 13:33 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/7c12f8aae0c9 re-enabled use of generated Nodes ! graal/com.oracle.graal.graph/src/com/oracle/graal/graph/Node.java Changeset: c72182ae4476 Author: Roland Schatz Date: 2014-09-04 13:44 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/c72182ae4476 Remove redundant Begin nodes before LoopExit. ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/LoopExitNode.java ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/ConvertDeoptimizeToGuardPhase.java Changeset: e8c37988a819 Author: Roland Schatz Date: 2014-09-04 15:04 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/e8c37988a819 Split method in OptimizingLinearScanWalker. ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/alloc/OptimizingLinearScanWalker.java Changeset: ba5b07e2b2c2 Author: Roland Schatz Date: 2014-09-04 16:18 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/ba5b07e2b2c2 Disable use of generated Nodes. ! graal/com.oracle.graal.graph/src/com/oracle/graal/graph/Node.java Changeset: b4866d4484d1 Author: Christian Humer Date: 2014-09-04 21:46 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/b4866d4484d1 Truffle: fixed potential non determinism in the invalidation of inlining. ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/OptimizedCallTarget.java Changeset: 49b8c8932786 Author: Doug Simon Date: 2014-09-04 22:32 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/49b8c8932786 projects must be rebuilt when any of their dependencies are rebuilt ! mxtool/mx.py Changeset: c25fcf343b4f Author: Doug Simon Date: 2014-09-04 22:33 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/c25fcf343b4f improved javadoc for NodeClass.is() ! graal/com.oracle.graal.graph/src/com/oracle/graal/graph/NodeClass.java Changeset: 35fda668ed6e Author: Doug Simon Date: 2014-09-04 22:34 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/35fda668ed6e mx: added ctw command to simplify executing CompileTheWorld ! mx/mx_graal.py From doug.simon at oracle.com Sat Sep 6 01:00:09 2014 From: doug.simon at oracle.com (doug.simon at oracle.com) Date: Sat, 06 Sep 2014 01:00:09 +0000 Subject: hg: graal/graal: 3 new changesets Message-ID: <201409060100.s86109lW024662@aojmv0008> Changeset: 7404e1113697 Author: Doug Simon Date: 2014-09-05 11:50 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/7404e1113697 enable CompileTheWorld in non-hosted mode ! src/share/vm/graal/graalCompiler.cpp Changeset: fb8fe09c00a3 Author: Roland Schatz Date: 2014-09-05 12:27 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/fb8fe09c00a3 Don't remove LoopExitNodes in UseTrappingNullChecksPhase. ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/UseTrappingNullChecksPhase.java Changeset: 3e4d3be0b6bf Author: Gilles Duboscq Date: 2014-09-04 20:12 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/3e4d3be0b6bf mx: fix default handling of vm config and build type ! mx/mx_graal.py From doug.simon at oracle.com Sun Sep 7 01:00:06 2014 From: doug.simon at oracle.com (doug.simon at oracle.com) Date: Sun, 07 Sep 2014 01:00:06 +0000 Subject: hg: graal/graal: 3 new changesets Message-ID: <201409070100.s87106VH022380@aojmv0008> Changeset: 0e7894989f37 Author: Chris Seaton Date: 2014-09-06 17:14 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/0e7894989f37 Truffle: fix AssumedValue. ! graal/com.oracle.truffle.api/src/com/oracle/truffle/api/utilities/AssumedValue.java Changeset: d51c097cca37 Author: Chris Seaton Date: 2014-09-06 17:19 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/d51c097cca37 Truffle: Add NeverValidAssumption. + graal/com.oracle.truffle.api.test/src/com/oracle/truffle/api/test/utilities/NeverValidAssumptionTest.java + graal/com.oracle.truffle.api/src/com/oracle/truffle/api/utilities/NeverValidAssumption.java Changeset: 97d0508b7cf1 Author: Chris Seaton Date: 2014-09-06 17:20 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/97d0508b7cf1 Truffle: entries in change log. ! CHANGELOG.md From Eric.Caspole at amd.com Mon Sep 8 13:13:53 2014 From: Eric.Caspole at amd.com (Caspole, Eric) Date: Mon, 8 Sep 2014 13:13:53 +0000 Subject: Webrev of test case for HSAIL deopt Message-ID: Hi everybody, I put a new webrev for a test case here: http://cr.openjdk.java.net/~ecaspole/hsail_deopt_test/01/ This is the test case that goes with the hsail call stub deopt bug that Tom R fixed last week: http://hg.openjdk.java.net/graal/graal/rev/2d6dd2eebd51 The test does a throw that caused the failure before the fix was added. Thanks, Eric From email at pitr.ch Mon Sep 8 16:06:07 2014 From: email at pitr.ch (Petr Chalupa) Date: Mon, 8 Sep 2014 18:06:07 +0200 Subject: 1st Virtual Machine Meetup at ETH Zurich In-Reply-To: References: Message-ID: Hello, Will the presentations be recorded? I would like to attend but unfortunately I am on sickness leave. Thanks, Petr On Thu, Sep 4, 2014 at 8:48 PM, Thomas Wuerthinger < thomas.wuerthinger at oracle.com> wrote: > We are inviting to the 1st Virtual Machine Meetup at ETH Zurich to > exchange ideas with other computer scientists in this area. Presentations > will discuss the current state of the art and future directions in virtual > machine technology (detailed agenda with talk titles and presenters below). > > Date: 11th and 12th of September 2014 > Time: 9:00 - 16:30 > Location: IFW A 32.1 at ETH Zurich > > Attendance is open, but attendees should register by sending a note to " > thomas.wuerthinger at oracle.com? (due to limited seating). > > Regards, > Thomas Wuerthinger > Senior Research Manager > Oracle Labs > > ====================================================== > > Thursday, 11th of September > > 09:00 - 09:30 Oracle Labs VM Research Overview (Thomas Wuerthinger, > Oracle Labs) > 09:30 - 10:00 Three Research Threads with Potential Application in Data > Analytics (Markus P?schel, Department of Computer Science, ETH Zurich) > 10:00 - 10:30 The Oracle - Linz JVM Research Cooperation (Hanspeter > M?ssenb?ck, Johannes Kepler University Linz) > 10:30 - 11:00 *** Coffee Break *** > 11:00 - 11:30 Optimizing Allocations with Partial Escape Analysis (Lukas > Stadler, Oracle Labs) > 11:30 - 12:00 Late Data Layout: Unifying Data Representation > Transformations (Vlad Ureche, Programming Methods Laboratory, EPFL) > > 13:30 - 14:00 Garbage Collection for Distributed Systems (Tim Harris, > Oracle Labs) > 14:00 - 14:30 Reflecting on Advanced Distributed Programs (Elisa > Gonzalez Boix, Vrije Universiteit Brussel) > 14:30 - 15:00 Comprehensive Multi-Platform Dynamic Program Analysis for > the Java and Dalvik VM (Walter Binder and Yudi Zheng, University of Lugano) > 15:00 - 15:30 *** Coffee Break *** > 15:30 - 16:00 Beyond Virtual Machines: Dynamic Control Flow Integrity > (Thomas Gross, Laboratory for Software Technology, ETH Zurich) > 16:00 - 16:30 EventRacer: Concurrency Analysis for Event-Driven > Applications (Martin Vechev, Software Reliability Lab, ETH Zurich) > > Friday, 12th of September > > 09:00 - 09:30 Generating Interpreters from DynSem Specifications (Eelco > Visser and Vlad Vergu, Delft University of Technology) > 09:30 - 10:00 High-performance JavaScript on top of Truffle (Christian > Wirth, Oracle Labs) > 10:00 - 10:30 Tools for the Development of Correct Software (Peter > M?ller, Chair of Programming Methodology, Department of Computer Science, > ETH Zurich) > 10:30 - 11:00 *** Coffee Break *** > 11:00 - 11:30 Purity Analysis for JavaScript (Jens Nicolay, Software > Languages Lab, Vrije Universiteit Brussel) > 11:30 - 12:00 ScalaMeter (Aleksandar Prokopec, Programming Methods > Laboratory, EPFL) > > 13:30 - 14:00 FastR (Michael Haupt, Oracle Labs) > 14:00 - 14:30 Language Integration and Migration (Laurence Tratt, > Software Development Team, Informatics, King's College London) > 14:30 - 15:00 Language Support for Reactive Applications (Guido > Salvaneschi, Technische Universit?t Darmstadt) > 15:00 - 15:30 *** Coffee Break *** > 15:30 - 16:00 Incremental Updates for Graph Queries (Sandro Stucki, EPFL > LAMP & Oracle Labs) > 16:00 - 16:30 Space-Time Views For Back-In-Time Debugging (Mohammad > Azadmanesh, University of Lugano) From tom.enebo at gmail.com Mon Sep 8 16:28:56 2014 From: tom.enebo at gmail.com (Thomas E Enebo) Date: Mon, 8 Sep 2014 11:28:56 -0500 Subject: 1st Virtual Machine Meetup at ETH Zurich In-Reply-To: References: Message-ID: I also will be in travelling when this is and would love to see a recording... -Tom On Mon, Sep 8, 2014 at 11:06 AM, Petr Chalupa wrote: > Hello, > > Will the presentations be recorded? > I would like to attend but unfortunately I am on sickness leave. > > Thanks, > Petr > > > On Thu, Sep 4, 2014 at 8:48 PM, Thomas Wuerthinger < > thomas.wuerthinger at oracle.com> wrote: > > > We are inviting to the 1st Virtual Machine Meetup at ETH Zurich to > > exchange ideas with other computer scientists in this area. Presentations > > will discuss the current state of the art and future directions in > virtual > > machine technology (detailed agenda with talk titles and presenters > below). > > > > Date: 11th and 12th of September 2014 > > Time: 9:00 - 16:30 > > Location: IFW A 32.1 at ETH Zurich > > > > Attendance is open, but attendees should register by sending a note to " > > thomas.wuerthinger at oracle.com? (due to limited seating). > > > > Regards, > > Thomas Wuerthinger > > Senior Research Manager > > Oracle Labs > > > > ====================================================== > > > > Thursday, 11th of September > > > > 09:00 - 09:30 Oracle Labs VM Research Overview (Thomas Wuerthinger, > > Oracle Labs) > > 09:30 - 10:00 Three Research Threads with Potential Application in Data > > Analytics (Markus P?schel, Department of Computer Science, ETH Zurich) > > 10:00 - 10:30 The Oracle - Linz JVM Research Cooperation (Hanspeter > > M?ssenb?ck, Johannes Kepler University Linz) > > 10:30 - 11:00 *** Coffee Break *** > > 11:00 - 11:30 Optimizing Allocations with Partial Escape Analysis > (Lukas > > Stadler, Oracle Labs) > > 11:30 - 12:00 Late Data Layout: Unifying Data Representation > > Transformations (Vlad Ureche, Programming Methods Laboratory, EPFL) > > > > 13:30 - 14:00 Garbage Collection for Distributed Systems (Tim Harris, > > Oracle Labs) > > 14:00 - 14:30 Reflecting on Advanced Distributed Programs (Elisa > > Gonzalez Boix, Vrije Universiteit Brussel) > > 14:30 - 15:00 Comprehensive Multi-Platform Dynamic Program Analysis for > > the Java and Dalvik VM (Walter Binder and Yudi Zheng, University of > Lugano) > > 15:00 - 15:30 *** Coffee Break *** > > 15:30 - 16:00 Beyond Virtual Machines: Dynamic Control Flow Integrity > > (Thomas Gross, Laboratory for Software Technology, ETH Zurich) > > 16:00 - 16:30 EventRacer: Concurrency Analysis for Event-Driven > > Applications (Martin Vechev, Software Reliability Lab, ETH Zurich) > > > > Friday, 12th of September > > > > 09:00 - 09:30 Generating Interpreters from DynSem Specifications (Eelco > > Visser and Vlad Vergu, Delft University of Technology) > > 09:30 - 10:00 High-performance JavaScript on top of Truffle (Christian > > Wirth, Oracle Labs) > > 10:00 - 10:30 Tools for the Development of Correct Software (Peter > > M?ller, Chair of Programming Methodology, Department of Computer Science, > > ETH Zurich) > > 10:30 - 11:00 *** Coffee Break *** > > 11:00 - 11:30 Purity Analysis for JavaScript (Jens Nicolay, Software > > Languages Lab, Vrije Universiteit Brussel) > > 11:30 - 12:00 ScalaMeter (Aleksandar Prokopec, Programming Methods > > Laboratory, EPFL) > > > > 13:30 - 14:00 FastR (Michael Haupt, Oracle Labs) > > 14:00 - 14:30 Language Integration and Migration (Laurence Tratt, > > Software Development Team, Informatics, King's College London) > > 14:30 - 15:00 Language Support for Reactive Applications (Guido > > Salvaneschi, Technische Universit?t Darmstadt) > > 15:00 - 15:30 *** Coffee Break *** > > 15:30 - 16:00 Incremental Updates for Graph Queries (Sandro Stucki, > EPFL > > LAMP & Oracle Labs) > > 16:00 - 16:30 Space-Time Views For Back-In-Time Debugging (Mohammad > > Azadmanesh, University of Lugano) > -- blog: http://blog.enebo.com twitter: tom_enebo mail: tom.enebo at gmail.com From eric.caspole at amd.com Mon Sep 8 20:23:22 2014 From: eric.caspole at amd.com (Eric Caspole) Date: Mon, 8 Sep 2014 16:23:22 -0400 Subject: src_gen folder with netbeansinit Message-ID: <540E103A.7080700@amd.com> Hi everyone, I just discovered this new src file that is generated: graal/com.oracle.graal.graph/src_gen/com/oracle/graal/graph/Graph_PlaceHolderNodeGen.java:29:final class Graph_PlaceHolderNodeGen extends PlaceHolderNode { Would it be possible to fix the netbeansinit to create the com.oracle.graal.graph project to include the src_gen folder by default so you don't have to add it by hand? This seems to be a new problem for com.oracle.graal.nodes as well. Thanks, Eric From doug.simon at oracle.com Tue Sep 9 01:00:07 2014 From: doug.simon at oracle.com (doug.simon at oracle.com) Date: Tue, 09 Sep 2014 01:00:07 +0000 Subject: hg: graal/graal: 9 new changesets Message-ID: <201409090100.s89109MT028738@aojmv0008> Changeset: a5dc5513ce85 Author: Bernhard Urban Date: 2014-09-08 09:46 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/a5dc5513ce85 mx: add check for compliance level of a distribution ! mx/projects ! mxtool/mx.py Changeset: cc8bd79d8d57 Author: Doug Simon Date: 2014-09-08 13:24 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/cc8bd79d8d57 fixed race involving NodeRefIterator.Empty ! graal/com.oracle.graal.graph/src/com/oracle/graal/graph/NodeRefIterable.java ! graal/com.oracle.graal.graph/src/com/oracle/graal/graph/NodeRefIterator.java Changeset: 75dd27a1d79f Author: Doug Simon Date: 2014-09-08 13:26 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/75dd27a1d79f re-enable use of generated nodes by default ! graal/com.oracle.graal.graph/src/com/oracle/graal/graph/Node.java Changeset: a6277ae87f0e Author: Doug Simon Date: 2014-09-08 13:49 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/a6277ae87f0e ensure NodeRefIterator.Empty.hasNext() returns false ! graal/com.oracle.graal.graph/src/com/oracle/graal/graph/NodeRefIterator.java Changeset: 75a4acd33159 Author: Doug Simon Date: 2014-09-08 19:04 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/75a4acd33159 mx: do not clean distributions if the --no-java option is given to the clean command ! mxtool/mx.py Changeset: 3c54a098455f Author: Doug Simon Date: 2014-09-08 21:00 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/3c54a098455f removed Node.recordsUsages() ! 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/TypeSystemTest.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.hotspot/src/com/oracle/graal/hotspot/phases/AheadOfTimeVerificationPhase.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/MergeNode.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/cfs/FlowUtil.java ! graal/com.oracle.graal.phases/src/com/oracle/graal/phases/schedule/SchedulePhase.java ! graal/com.oracle.graal.printer/src/com/oracle/graal/printer/CFGPrinter.java ! graal/com.oracle.graal.replacements/src/com/oracle/graal/replacements/NodeIntrinsificationPhase.java ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/TruffleCacheImpl.java ! graal/com.oracle.graal.word/src/com/oracle/graal/word/phases/WordTypeVerificationPhase.java Changeset: 37d6d174bc40 Author: Doug Simon Date: 2014-09-08 21:23 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/37d6d174bc40 denote certain applications of DeadCodeEliminationPhase as optional and only run them if -G:-ReduceDCE ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/GraalCompiler.java ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/phases/HighTier.java ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/phases/LowTier.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/phases/OnStackReplacementPhase.java ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/ConvertDeoptimizeToGuardPhase.java ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/DeadCodeEliminationPhase.java ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/cfs/FlowSensitiveReduction.java ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/inlining/info/elem/InlineableGraph.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.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: 0bcefb0f8488 Author: Chris Seaton Date: 2014-09-08 22:21 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/0bcefb0f8488 Truffle: byte[] sources. + graal/com.oracle.truffle.api.test/src/com/oracle/truffle/api/test/source/BytesSourceSectionTest.java + graal/com.oracle.truffle.api/src/com/oracle/truffle/api/source/BytesDecoder.java ! graal/com.oracle.truffle.api/src/com/oracle/truffle/api/source/Source.java Changeset: 2bc092f3d574 Author: Chris Seaton Date: 2014-09-08 22:21 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/2bc092f3d574 Merge. From doug.simon at oracle.com Tue Sep 9 14:15:24 2014 From: doug.simon at oracle.com (doug.simon at oracle.com) Date: Tue, 09 Sep 2014 14:15:24 +0000 Subject: hg: graal/graal: 10 new changesets Message-ID: <201409091415.s89EFO8K012488@aojmv0008> Changeset: 8456194ca311 Author: Tom Rodriguez Date: 2014-09-09 11:35 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/8456194ca311 Unproxy constant usages in FrameState ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/gen/DebugInfoBuilder.java ! graal/com.oracle.graal.lir/src/com/oracle/graal/lir/constopt/ConstantLoadOptimization.java Changeset: 2740dad59eb7 Author: Tom Rodriguez Date: 2014-09-09 11:36 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/2740dad59eb7 Fix forceLog ! graal/com.oracle.graal.debug/src/com/oracle/graal/debug/Debug.java ! graal/com.oracle.graal.debug/src/com/oracle/graal/debug/DelegatingDebugConfig.java Changeset: 6e45ae59781c Author: Tom Rodriguez Date: 2014-09-09 11:37 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/6e45ae59781c Let linear scan DetailedAsserts deal with missing intervals ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/alloc/LinearScan.java Changeset: 1b7b4eb6e0ef Author: Tom Rodriguez Date: 2014-09-09 11:51 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/1b7b4eb6e0ef Enable scheduling when dumping for DumpOnError ! graal/com.oracle.graal.printer/src/com/oracle/graal/printer/BinaryGraphPrinter.java Changeset: e4923262b8c5 Author: Tom Rodriguez Date: 2014-09-09 11:53 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/e4923262b8c5 Move FixedNodeProbabilityCache into InlineableGraph so it doesn't get too big ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/inlining/info/elem/Inlineable.java ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/inlining/info/elem/InlineableGraph.java ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/inlining/info/elem/InlineableMacroNode.java ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/inlining/policy/AbstractInliningPolicy.java ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/inlining/policy/GreedyInliningPolicy.java ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/inlining/policy/InlineEverythingPolicy.java ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/inlining/policy/InliningPolicy.java ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/inlining/walker/InliningData.java Changeset: 1d69b5c58bfe Author: Tom Rodriguez Date: 2014-09-09 11:53 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/1d69b5c58bfe Insert proxies when peeking through proxy for array length ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/java/ArrayLengthNode.java Changeset: 899dd861f081 Author: Tom Rodriguez Date: 2014-09-09 12:14 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/899dd861f081 Update comment about usages of streams ! graal/com.oracle.graal.phases/src/com/oracle/graal/phases/graph/FixedNodeProbabilityCache.java Changeset: c24ea91c30ba Author: Doug Simon Date: 2014-09-09 13:32 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/c24ea91c30ba create generated source dirs as part of netbeansinit ! mxtool/mx.py Changeset: f0b55d0c5d2d Author: Doug Simon Date: 2014-09-09 13:58 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/f0b55d0c5d2d use absolute paths in generated NetBeans project configurations ! mxtool/mx.py Changeset: 0a210ccd3bd3 Author: Doug Simon Date: 2014-09-09 14:05 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/0a210ccd3bd3 HSAIL: test case for HSAIL deopt bug Contributed-by: Eric Caspole + graal/com.oracle.graal.compiler.hsail.test/src/com/oracle/graal/compiler/hsail/test/lambda/MoreThanEightArgsOOBTest.java From tom.deneau at amd.com Tue Sep 9 22:02:44 2014 From: tom.deneau at amd.com (Deneau, Tom) Date: Tue, 9 Sep 2014 22:02:44 +0000 Subject: determining when to offload to the gpu Message-ID: The following is an issue we need to resolve in Sumatra. We intend to file this in the openjdk bugs system once we get the Sumatra project set up as a project there. Meanwhile, comments are welcome. In the current prototype, a config flag enables offload and if a Stream API parallel().forEach call is encountered which meets the other criteria for being offloaded, then on its first invocation it is compiled for the HSA target and executed. The compilation happens once, the compiled kernel is saved and can be reused on subsequent invocations of the same lambda. (Note: if for any reason the lambda cannot be compiled for an HSA target, offload is disabled for this lambda and the usual CPU parallel path is used). The logic for deciding whether to offload or not is all in the special Sumatra-modified JDK classes in java/util/stream. The above logic could be improved: a) instead of being offloaded on the first invocation, the lambda should first be executed thru the interpreter so that profiling information is gathered which could then be useful in the eventual HSAIL compilation step. b) instead of being offloaded unconditionally, it would be good if the lambda would be offloaded only if the offload is determined profitable when compared to running parallel on the CPU. We assume that in general it is not possible to predict the profitability of GPU offload statically and that measurement will be necessary. So how to meet the above needs? Our current thoughts are that at the JDK level where we decide to offload a particular parallel lambda invocation would go thru a number of stages: * Interpreted (to gather profiling information) * Compiled and executed on Parallel CPU and timed * Compiled and executed on Parallel GPU and timed And then at that point make some decision about which way is faster and use that going forward. Do people think making these measurements back at the JDK API level is the right place? (It seems to fit there since that is where we decide whether or not to offload) Some concerns ------------- This comparison works well if the work per stream call is similar for all invocations. However, even the range may not be the same from invocation to invocation. We should try to compare parCPU and parGPU runs with the same range. If we can't find runs with the same range, we could derive a time per workitem measurement and compare those. However, time per workitem for a small range may be quite different for time per workitem for a large range so would be difficult to compare. Even then the work per run may be different (might take different paths thru the lambda). How to detect that we are in the "Compiled" stage for the Parallel CPU runs? I guess knowing the range of each forEach call we should be able to estimate this, or just see a reduction in the runtime. -- Tom Deneau From doug.simon at oracle.com Wed Sep 10 01:00:06 2014 From: doug.simon at oracle.com (doug.simon at oracle.com) Date: Wed, 10 Sep 2014 01:00:06 +0000 Subject: hg: graal/graal: 12 new changesets Message-ID: <201409100100.s8A1067i005075@aojmv0008> Changeset: c4b1cf38002b Author: Chris Seaton Date: 2014-09-09 20:19 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/c4b1cf38002b Truffle: TruffleCompilationExceptionsAreThrown option to get OptimizationFailedException on compiler error. ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/OptimizedCallTarget.java ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/TruffleCompilerOptions.java + graal/com.oracle.truffle.api/src/com/oracle/truffle/api/OptimizationFailedException.java Changeset: b06b4dee86d5 Author: Chris Seaton Date: 2014-09-09 20:21 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/b06b4dee86d5 Truffle: keep the RootNode in OptimizationFailedException, so you can figure out what it was that failed. ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/OptimizedCallTarget.java ! graal/com.oracle.truffle.api/src/com/oracle/truffle/api/OptimizationFailedException.java Changeset: 2476180699f6 Author: Chris Seaton Date: 2014-09-09 20:22 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/2476180699f6 Truffle: change log entry for TruffleCompilationExceptionsAreThrown. ! CHANGELOG.md Changeset: 62505bdc6960 Author: Stefan Anzinger Date: 2014-09-05 18:28 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/62505bdc6960 [SPARC] fixing irem ! graal/com.oracle.graal.compiler.sparc/src/com/oracle/graal/compiler/sparc/SPARCLIRGenerator.java ! graal/com.oracle.graal.jtt/src/com/oracle/graal/jtt/bytecode/BC_irem.java ! graal/com.oracle.graal.lir.sparc/src/com/oracle/graal/lir/sparc/SPARCArithmetic.java Changeset: f8586d059f9d Author: Stefan Anzinger Date: 2014-09-09 12:09 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/f8586d059f9d [SPARC] make compatible for CPU without VIS3 and do some cleanup ! graal/com.oracle.graal.asm.sparc/src/com/oracle/graal/asm/sparc/SPARCAssembler.java ! graal/com.oracle.graal.asm.sparc/src/com/oracle/graal/asm/sparc/SPARCMacroAssembler.java ! graal/com.oracle.graal.compiler.sparc/src/com/oracle/graal/compiler/sparc/SPARCLIRGenerator.java ! graal/com.oracle.graal.hotspot.sparc/src/com/oracle/graal/hotspot/sparc/SPARCHotSpotBackendFactory.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/HotSpotVMConfig.java ! graal/com.oracle.graal.lir.sparc/src/com/oracle/graal/lir/sparc/SPARCArithmetic.java ! graal/com.oracle.graal.lir.sparc/src/com/oracle/graal/lir/sparc/SPARCMove.java ! graal/com.oracle.graal.lir.sparc/src/com/oracle/graal/lir/sparc/SPARCSaveRegistersOp.java ! graal/com.oracle.graal.sparc/src/com/oracle/graal/sparc/SPARC.java Changeset: 2b7c005ae93a Author: Stefan Anzinger Date: 2014-09-09 12:11 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/2b7c005ae93a [SPARC] Introduce access of HotSpot flags for sparc cpu (VIS1,2,3) ! src/cpu/sparc/vm/vmStructs_sparc.hpp ! src/cpu/sparc/vm/vm_version_sparc.hpp Changeset: 26f5733fb645 Author: Stefan Anzinger Date: 2014-09-09 12:15 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/26f5733fb645 Fix the endianess issue, when using JSR/RET instruction and deoptimization happens in this subroutine ! graal/com.oracle.graal.java/src/com/oracle/graal/java/GraphBuilderPhase.java ! graal/com.oracle.graal.replacements.test/src/com/oracle/graal/replacements/test/DeoptimizeOnExceptionTest.java ! src/share/vm/classfile/systemDictionary.hpp ! src/share/vm/classfile/vmSymbols.hpp ! src/share/vm/graal/graalCodeInstaller.cpp ! src/share/vm/graal/graalJavaAccess.hpp Changeset: 841a9f98b97c Author: Stefan Anzinger Date: 2014-09-09 12:20 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/841a9f98b97c Using basename instead of BASH_SOURCE, does not on older versions of bash (Which comes with Solaris 11.0) ! mxtool/mx Changeset: 82b5a7250a0d Author: Stefan Anzinger Date: 2014-09-09 12:22 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/82b5a7250a0d Add RawConstant + graal/com.oracle.graal.api.meta/src/com/oracle/graal/api/meta/RawConstant.java Changeset: 4faf9bdb9973 Author: Stefan Anzinger Date: 2014-09-09 14:31 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/4faf9bdb9973 Merge ! src/cpu/sparc/vm/sharedRuntime_sparc.cpp Changeset: 6e27f9d92dc5 Author: Stefan Anzinger Date: 2014-09-09 15:41 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/6e27f9d92dc5 [SPARC] Findbugs/checkstyle ! graal/com.oracle.graal.api.meta/src/com/oracle/graal/api/meta/RawConstant.java ! graal/com.oracle.graal.compiler.sparc.test/src/com/oracle/graal/compiler/sparc/test/SPARCAllocatorTest.java ! graal/com.oracle.graal.compiler.sparc/src/com/oracle/graal/compiler/sparc/SPARCLIRGenerator.java ! graal/com.oracle.graal.lir.sparc/src/com/oracle/graal/lir/sparc/SPARCArithmetic.java ! graal/com.oracle.graal.lir.sparc/src/com/oracle/graal/lir/sparc/SPARCMove.java ! graal/com.oracle.graal.lir.sparc/src/com/oracle/graal/lir/sparc/SPARCSaveRegistersOp.java Changeset: 245c1ceb8221 Author: Stefan Anzinger Date: 2014-09-09 15:50 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/245c1ceb8221 Findbugs ! graal/com.oracle.graal.asm.sparc/src/com/oracle/graal/asm/sparc/SPARCMacroAssembler.java From Sandro at oversea-supply.com Thu Sep 4 14:10:22 2014 From: Sandro at oversea-supply.com (Sandro) Date: Thu, 4 Sep 2014 22:10:22 +0800 Subject: Attn: graal-dev---Export?printing?products and inquiry Message-ID: <20140904221035381465@cyans-tag.vicp.cc> Dear manager, This is Sandro from a printing company based in China. We are producing all kinds of print products with the perfect price. Our products range from books, magazines to sticky memo pad, T-shirt particularly in printing catalogue, picture albums, etc. Should you have interest of items mentioned above Contact me. Best regards, Sandro i-loveprint Co.,Ltd Email : Sandro(at)oversea-supply.com From Ryan.LaMothe at pnnl.gov Wed Sep 10 00:02:52 2014 From: Ryan.LaMothe at pnnl.gov (LaMothe, Ryan R) Date: Wed, 10 Sep 2014 00:02:52 +0000 Subject: determining when to offload to the gpu In-Reply-To: References: Message-ID: Hi Tom, I thought this may be a good point to jump in and make a quick comment on some thoughts. A question: At what level is it better to encapsulate this in the JVM and at what level is this better left to the user/utility functions? For example, in the Aparapi project there is an example project named correlation-matrix that gives a pretty good idea about what it takes to realistically decide in code whether to run a specific matrix computation on CPU or GPU and how to split up the work. This is a very basic example and is only a sample of the real code base from which it was derived, but should help highlight the issue. Instead of the JVM trying to figure out how to decompose the lambda functions optimally and offload to HSA automatically for all possible cases, might it be better to take the following approach: - Implement the base functionality in the JVM for HSA offload and then search the entire JDK for places where offloading may be obvious or easily achieved (i.e. Matrix Math, etc.)? Maybe this even means implementing new base classes for specific packages that are HSA-enabled. - For non-obvious cases, allow the developer to somehow indicate in the lambda that they want the execution to occur via HSA/offload, if possible, and provide some form of annotations or other functionality to give the JVM hints about how they would like it done? Maybe that seems like steps backwards, but thought it was worth mentioning. -Ryan On 9/9/14, 3:02 PM, "Deneau, Tom" wrote: >The following is an issue we need to resolve in Sumatra. We >intend to file this in the openjdk bugs system once we get the Sumatra >project set up as a project there. Meanwhile, comments are welcome. > > >In the current prototype, a config flag enables offload and if a >Stream API parallel().forEach call is encountered which meets the >other criteria for being offloaded, then on its first invocation it is >compiled for the HSA target and executed. The compilation happens >once, the compiled kernel is saved and can be reused on subsequent >invocations of the same lambda. (Note: if for any reason the lambda >cannot be compiled for an HSA target, offload is disabled for this >lambda and the usual CPU parallel path is used). The logic for >deciding whether to offload or not is all in the special >Sumatra-modified JDK classes in java/util/stream. > >The above logic could be improved: > > a) instead of being offloaded on the first invocation, the lambda > should first be executed thru the interpreter so that profiling > information is gathered which could then be useful in the > eventual HSAIL compilation step. > > b) instead of being offloaded unconditionally, it would be good if > the lambda would be offloaded only if the offload is determined > profitable when compared to running parallel on the CPU. We > assume that in general it is not possible to predict the > profitability of GPU offload statically and that measurement > will be necessary. > >So how to meet the above needs? Our current thoughts are that at the >JDK level where we decide to offload a particular parallel lambda >invocation would go thru a number of stages: > > * Interpreted (to gather profiling information) > * Compiled and executed on Parallel CPU and timed > * Compiled and executed on Parallel GPU and timed > >And then at that point make some decision about which way is faster >and use that going forward. > >Do people think making these measurements back at the JDK API level is >the right place? (It seems to fit there since that is where we decide >whether or not to offload) > >Some concerns >------------- >This comparison works well if the work per stream call is similar for >all invocations. However, even the range may not be the same from >invocation to invocation. We should try to compare parCPU and parGPU >runs with the same range. If we can't find runs with the same range, >we could derive a time per workitem measurement and compare those. >However, time per workitem for a small range may be quite different >for time per workitem for a large range so would be difficult to >compare. Even then the work per run may be different (might take >different paths thru the lambda). > >How to detect that we are in the "Compiled" stage for the Parallel CPU >runs? I guess knowing the range of each forEach call we should be >able to estimate this, or just see a reduction in the runtime. > >-- Tom Deneau > > From doug.simon at oracle.com Wed Sep 10 15:14:22 2014 From: doug.simon at oracle.com (doug.simon at oracle.com) Date: Wed, 10 Sep 2014 15:14:22 +0000 Subject: hg: graal/graal: 5 new changesets Message-ID: <201409101514.s8AFEM3i024607@aojmv0008> Changeset: 2e7b0bb73f2f Author: Stefan Anzinger Date: 2014-09-09 17:02 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/2e7b0bb73f2f [SPARC] get rid of VIS3 ! graal/com.oracle.graal.hotspot.sparc/src/com/oracle/graal/hotspot/sparc/SPARCHotSpotLeaveUnpackFramesStackFrameOp.java Changeset: bd26b71aa5fc Author: Stefan Anzinger Date: 2014-09-09 18:35 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/bd26b71aa5fc Add truffle com.oracle.graal.truffle.test.SLTruffleGraalTestSuite to ignore for now ! test/blacklist_sparc.txt Changeset: 2f64a6c771d5 Author: Doug Simon Date: 2014-09-10 11:04 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/2f64a6c771d5 Backed out changeset: f0b55d0c5d2d ! mxtool/mx.py Changeset: e82d22396109 Author: Doug Simon Date: 2014-09-10 11:36 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/e82d22396109 Backed out changeset: 841a9f98b97c ! mxtool/mx Changeset: 86888df288ec Author: Doug Simon Date: 2014-09-10 11:44 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/86888df288ec fixed case of Optionality constants ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/GraalCompiler.java ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/phases/HighTier.java ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/phases/LowTier.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/phases/OnStackReplacementPhase.java ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/ConvertDeoptimizeToGuardPhase.java ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/DeadCodeEliminationPhase.java ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/cfs/FlowSensitiveReduction.java ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/inlining/info/elem/InlineableGraph.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.virtual/src/com/oracle/graal/virtual/phases/ea/EffectsPhase.java ! graal/com.oracle.graal.virtual/src/com/oracle/graal/virtual/phases/ea/IterativeInliningPhase.java From christian.thalinger at oracle.com Wed Sep 10 19:46:25 2014 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Wed, 10 Sep 2014 12:46:25 -0700 Subject: determining when to offload to the gpu In-Reply-To: References: Message-ID: <601A2476-F617-4F74-BB23-8DF5695BB54D@oracle.com> On Sep 9, 2014, at 3:02 PM, Deneau, Tom wrote: > The following is an issue we need to resolve in Sumatra. We > intend to file this in the openjdk bugs system once we get the Sumatra > project set up as a project there. Meanwhile, comments are welcome. > > > In the current prototype, a config flag enables offload and if a > Stream API parallel().forEach call is encountered which meets the > other criteria for being offloaded, then on its first invocation it is > compiled for the HSA target and executed. The compilation happens > once, the compiled kernel is saved and can be reused on subsequent > invocations of the same lambda. (Note: if for any reason the lambda > cannot be compiled for an HSA target, offload is disabled for this > lambda and the usual CPU parallel path is used). The logic for > deciding whether to offload or not is all in the special > Sumatra-modified JDK classes in java/util/stream. > > The above logic could be improved: > > a) instead of being offloaded on the first invocation, the lambda > should first be executed thru the interpreter so that profiling > information is gathered which could then be useful in the > eventual HSAIL compilation step. > > b) instead of being offloaded unconditionally, it would be good if > the lambda would be offloaded only if the offload is determined > profitable when compared to running parallel on the CPU. We > assume that in general it is not possible to predict the > profitability of GPU offload statically and that measurement > will be necessary. > > So how to meet the above needs? Our current thoughts are that at the > JDK level where we decide to offload a particular parallel lambda > invocation would go thru a number of stages: > > * Interpreted (to gather profiling information) > * Compiled and executed on Parallel CPU and timed > * Compiled and executed on Parallel GPU and timed > > And then at that point make some decision about which way is faster > and use that going forward. > > Do people think making these measurements back at the JDK API level is > the right place? (It seems to fit there since that is where we decide > whether or not to offload) The API level doesn?t seem to be the right place; the JIT compiler should make these decisions. Eventually we want unmodified Java code to be offloaded, too. > > Some concerns > ------------- > This comparison works well if the work per stream call is similar for > all invocations. However, even the range may not be the same from > invocation to invocation. We should try to compare parCPU and parGPU > runs with the same range. If we can't find runs with the same range, > we could derive a time per workitem measurement and compare those. > However, time per workitem for a small range may be quite different > for time per workitem for a large range so would be difficult to > compare. Even then the work per run may be different (might take > different paths thru the lambda). > > How to detect that we are in the "Compiled" stage for the Parallel CPU > runs? I guess knowing the range of each forEach call we should be > able to estimate this, or just see a reduction in the runtime. > > -- Tom Deneau > > From doug.simon at oracle.com Thu Sep 11 01:00:06 2014 From: doug.simon at oracle.com (doug.simon at oracle.com) Date: Thu, 11 Sep 2014 01:00:06 +0000 Subject: hg: graal/graal: 3 new changesets Message-ID: <201409110100.s8B106Y5001256@aojmv0008> Changeset: 174f78c24747 Author: Chris Seaton Date: 2014-09-10 21:38 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/174f78c24747 Truffle: simplify byte section tests. ! graal/com.oracle.truffle.api.test/src/com/oracle/truffle/api/test/source/BytesSourceSectionTest.java Changeset: 23cdb7e5fa2d Author: Tom Rodriguez Date: 2014-09-10 23:14 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/23cdb7e5fa2d Fixed variable name ! src/cpu/sparc/vm/sharedRuntime_sparc.cpp Changeset: fc94fd8a28dc Author: Tom Rodriguez Date: 2014-09-10 23:14 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/fc94fd8a28dc Disable graph caching until assumptions problem is fixed ! graal/com.oracle.graal.compiler.common/src/com/oracle/graal/compiler/common/GraalOptions.java From doug.simon at oracle.com Sat Sep 13 01:00:06 2014 From: doug.simon at oracle.com (doug.simon at oracle.com) Date: Sat, 13 Sep 2014 01:00:06 +0000 Subject: hg: graal/graal: 10 new changesets Message-ID: <201409130100.s8D106Wd015046@aojmv0008> Changeset: 602fcd1b2cd4 Author: Stefan Anzinger Date: 2014-09-10 11:18 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/602fcd1b2cd4 [SPARC] fix issues with moving between float and general purpose registers (alignment) ! graal/com.oracle.graal.lir.sparc/src/com/oracle/graal/lir/sparc/SPARCMove.java Changeset: 6e3cb88e6990 Author: Stefan Anzinger Date: 2014-09-10 11:22 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/6e3cb88e6990 [SPARC] Temp slot must be 64 bit (long) ! graal/com.oracle.graal.compiler.sparc/src/com/oracle/graal/compiler/sparc/SPARCLIRGenerator.java Changeset: dbc4d605eb8f Author: Stefan Anzinger Date: 2014-09-10 12:55 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/dbc4d605eb8f [SPARC] rename guaranteeLoadable to generateSimm13OffsetLoad ! graal/com.oracle.graal.lir.sparc/src/com/oracle/graal/lir/sparc/SPARCArithmetic.java ! graal/com.oracle.graal.lir.sparc/src/com/oracle/graal/lir/sparc/SPARCMove.java Changeset: a3fa16378eaa Author: Stefan Anzinger Date: 2014-09-11 11:26 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/a3fa16378eaa Merge Changeset: 8c9ab783e814 Author: Stefan Anzinger Date: 2014-09-12 12:51 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/8c9ab783e814 DirectReadNode from unsafe does now sign/zero extend values which are shorter than int ! graal/com.oracle.graal.replacements/src/com/oracle/graal/replacements/nodes/DirectReadNode.java Changeset: 69d8f4e45ee2 Author: Stefan Anzinger Date: 2014-09-12 12:54 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/69d8f4e45ee2 [SPARC] Fix typo ! src/cpu/sparc/vm/sharedRuntime_sparc.cpp Changeset: b0146ab5b55f Author: Stefan Anzinger Date: 2014-09-12 12:55 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/b0146ab5b55f [SPARC] Can now configure different prefetch modes ! graal/com.oracle.graal.asm.sparc/src/com/oracle/graal/asm/sparc/SPARCAssembler.java ! graal/com.oracle.graal.hotspot.sparc/src/com/oracle/graal/hotspot/sparc/SPARCPrefetchOp.java Changeset: 0a21f24f9a65 Author: Stefan Anzinger Date: 2014-09-12 14:50 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/0a21f24f9a65 [SPARC] eliminating some redundant LIR types ! graal/com.oracle.graal.compiler.sparc/src/com/oracle/graal/compiler/sparc/SPARCLIRGenerator.java ! graal/com.oracle.graal.lir.sparc/src/com/oracle/graal/lir/sparc/SPARCArithmetic.java ! graal/com.oracle.graal.lir.sparc/src/com/oracle/graal/lir/sparc/SPARCMove.java Changeset: 3d6132d71975 Author: Stefan Anzinger Date: 2014-09-12 15:24 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/3d6132d71975 Compiler warning removed (unused import) ! graal/com.oracle.graal.replacements/src/com/oracle/graal/replacements/nodes/DirectReadNode.java Changeset: 33d2fea5d40e Author: Stefan Anzinger Date: 2014-09-12 15:39 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/33d2fea5d40e Removed another unused variable ! graal/com.oracle.graal.lir.sparc/src/com/oracle/graal/lir/sparc/SPARCMove.java From doug.simon at oracle.com Tue Sep 16 01:00:05 2014 From: doug.simon at oracle.com (doug.simon at oracle.com) Date: Tue, 16 Sep 2014 01:00:05 +0000 Subject: hg: graal/graal: Add optional graph dump before each compiler phase. Message-ID: <201409160100.s8G105tS012864@aojmv0008> Changeset: dbb08e742d87 Author: Roland Schatz Date: 2014-09-15 17:16 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/dbb08e742d87 Add optional graph dump before each compiler phase. ! graal/com.oracle.graal.phases/src/com/oracle/graal/phases/BasePhase.java From java at stefan-marr.de Tue Sep 16 21:57:05 2014 From: java at stefan-marr.de (Stefan Marr) Date: Tue, 16 Sep 2014 23:57:05 +0200 Subject: Recent Truffle DSL changes. In-Reply-To: References: Message-ID: <54D3BDC5-2312-4542-946B-AE0866F6D57E@stefan-marr.de> Hi Christian: On 11 Aug 2014, at 19:59, Christian Humer wrote: > I just pushed some new features to the DSL for the upcoming Truffle > release. Please note that some of the changes may break existing Truffle > interpreters. Guest languages that don't use Truffle DSL are not affected > by this push. I finally found the time to update Graal. Looks good. Didn?t had any major issues. Performance seems to remain more or less the same. Only got two nits. The first one is that the generated code does have one simple issue with the code style, which can be solved by initializing the method body unconditionally (see patch below). The second thing is a simple typo in one of the error messages. Best regards Stefan diff --git a/graal/com.oracle.truffle.dsl.processor/src/com/oracle/truffle/dsl/processor/generator/NodeCodeGenerator.java b/graal/com.oracle.truffle.dsl.processor/src/com/oracle/truffle/dsl/processor/generator/NodeCodeGenerator.java index 0a38640..c3bc5eb 100644 --- a/graal/com.oracle.truffle.dsl.processor/src/com/oracle/truffle/dsl/processor/generator/NodeCodeGenerator.java +++ b/graal/com.oracle.truffle.dsl.processor/src/com/oracle/truffle/dsl/processor/generator/NodeCodeGenerator.java @@ -906,9 +906,9 @@ public class NodeCodeGenerator extends AbstractCompilationUnitFactory CodeExecutableElement method = new CodeExecutableElement(modifiers(PUBLIC), context.getType(void.class), "updateTypes0"); method.getParameters().add(new CodeVariableElement(classArray, "types")); - if (getModel().isPolymorphic()) { - CodeTreeBuilder builder = method.createBuilder(); + CodeTreeBuilder builder = method.createBuilder(); + if (getModel().isPolymorphic()) { int index = 0; for (NodeExecutionData execution : getModel().getNode().getChildExecutions()) { String fieldName = polymorphicTypeName(execution); diff --git a/graal/com.oracle.truffle.dsl.processor/src/com/oracle/truffle/dsl/processor/parser/NodeParser.java b/graal/com.oracle.truffle.dsl.processor/src/com/oracle/truffle/dsl/processor/parser/NodeParser.java index 202815e..516dc18 100644 --- a/graal/com.oracle.truffle.dsl.processor/src/com/oracle/truffle/dsl/processor/parser/NodeParser.java +++ b/graal/com.oracle.truffle.dsl.processor/src/com/oracle/truffle/dsl/processor/parser/NodeParser.java @@ -650,7 +650,7 @@ public class NodeParser extends AbstractParser { SpecializationData next = i + 1 < specializations.size() ? specializations.get(i + 1) : null; if (!cur.isContainedBy(next)) { - next.addError("This specialiation is not a valid exceptional rewrite target for %s. To fix this make %s compatible to %s or remove the exceptional rewrite.", + next.addError("This specialization is not a valid exceptional rewrite target for %s. To fix this make %s compatible to %s or remove the exceptional rewrite.", cur.createReferenceName(), next != null ? next.createReferenceName() : "-", cur.createReferenceName()); continue; } -- 1.9.1 -- Stefan Marr INRIA Lille - Nord Europe http://stefan-marr.de/research/ From doug.simon at oracle.com Wed Sep 17 01:00:06 2014 From: doug.simon at oracle.com (doug.simon at oracle.com) Date: Wed, 17 Sep 2014 01:00:06 +0000 Subject: hg: graal/graal: 6 new changesets Message-ID: <201409170100.s8H1060Q000226@aojmv0008> Changeset: 1a92d77a851b Author: Stefan Anzinger Date: 2014-09-15 19:22 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/1a92d77a851b [SPARC] Implementing ArrayEqualsOp for sparc ! graal/com.oracle.graal.asm.sparc/src/com/oracle/graal/asm/sparc/SPARCAssembler.java ! graal/com.oracle.graal.compiler.sparc/src/com/oracle/graal/compiler/sparc/SPARCLIRGenerator.java + graal/com.oracle.graal.lir.sparc/src/com/oracle/graal/lir/sparc/SPARCArrayEqualsOp.java ! graal/com.oracle.graal.replacements/src/com/oracle/graal/replacements/ArraysSubstitutions.java ! graal/com.oracle.graal.replacements/src/com/oracle/graal/replacements/StringSubstitutions.java Changeset: fe935dbf9863 Author: Stefan Anzinger Date: 2014-09-15 20:06 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/fe935dbf9863 Remove unused imports ! graal/com.oracle.graal.lir.sparc/src/com/oracle/graal/lir/sparc/SPARCArrayEqualsOp.java Changeset: 881fa8b6ca9d Author: Stefan Anzinger Date: 2014-09-15 20:06 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/881fa8b6ca9d Merge Changeset: 4c9c347fa4da Author: Stefan Anzinger Date: 2014-09-15 20:20 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/4c9c347fa4da [SPARC] Renamed member tmp to avoid compiler warnings ! graal/com.oracle.graal.compiler.sparc/src/com/oracle/graal/compiler/sparc/SPARCLIRGenerator.java Changeset: 583bf03b3e1a Author: Doug Simon Date: 2014-09-16 22:00 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/583bf03b3e1a apply CompilerToVM.shouldDebugNonSafepoints() to HotSpot Truffle compilations as well ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/CompilationTask.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotSuitesProvider.java ! graal/com.oracle.graal.java/src/com/oracle/graal/java/GraphBuilderConfiguration.java ! graal/com.oracle.graal.truffle.hotspot/src/com/oracle/graal/truffle/hotspot/HotSpotTruffleRuntime.java Changeset: 8ca5e41dde86 Author: Doug Simon Date: 2014-09-16 22:00 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/8ca5e41dde86 DeadCodeElimination is not optional for OnStackReplacementPhase ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/phases/OnStackReplacementPhase.java From java at stefan-marr.de Wed Sep 17 14:04:19 2014 From: java at stefan-marr.de (Stefan Marr) Date: Wed, 17 Sep 2014 16:04:19 +0200 Subject: How to use ProfileCompiledMethods Message-ID: Hi: I was trying to investigate the performance of some benchmarks with the +ProfileCompiledMethods option but fail to get it to work. What exactly are the necessary steps to get profiling output? I compiled the GraalVM with: ./mx.sh --vm graal build -p And then run the benchmark of interest like this: ../graal/mxtool/mx --vm graal vm -XX:+BootstrapGraal -XX:GraalCounterSize=30000 "-G:BenchmarkDynamicCounters=out,warmup finished,finished" -G:+ProfileCompiledMethods -G:-TraceTruffleCompilation -Xbootclasspath/a:build/classes:libs/truffle.jar som.vm.Universe -cp Smalltalk:Examples/Benchmarks/DeltaBlue Examples/Benchmarks/BenchmarkHarness.som DeltaBlue 500 0 10 Unfortunately, that doesn?t seem to produce any output (except the benchmark?s output). Thanks Stefan -- Stefan Marr INRIA Lille - Nord Europe http://stefan-marr.de/research/ From lukas.stadler at oracle.com Wed Sep 17 14:09:04 2014 From: lukas.stadler at oracle.com (Lukas Stadler) Date: Wed, 17 Sep 2014 16:09:04 +0200 Subject: How to use ProfileCompiledMethods In-Reply-To: References: Message-ID: The "out,warmup finished,finished? clause means that it will listen on System.out, start measuring when it encounters ?warmup finished? and print results when it encounters ?finished?. Is it possible that that is does not occur in our benchmark setup? - Lukas On 17 Sep 2014, at 16:04, Stefan Marr wrote: > Hi: > > I was trying to investigate the performance of some benchmarks with the +ProfileCompiledMethods option but fail to get it to work. > > What exactly are the necessary steps to get profiling output? > > I compiled the GraalVM with: > ./mx.sh --vm graal build -p > > And then run the benchmark of interest like this: > > ../graal/mxtool/mx --vm graal vm -XX:+BootstrapGraal -XX:GraalCounterSize=30000 "-G:BenchmarkDynamicCounters=out,warmup finished,finished" -G:+ProfileCompiledMethods -G:-TraceTruffleCompilation -Xbootclasspath/a:build/classes:libs/truffle.jar som.vm.Universe -cp Smalltalk:Examples/Benchmarks/DeltaBlue Examples/Benchmarks/BenchmarkHarness.som DeltaBlue 500 0 10 > > Unfortunately, that doesn?t seem to produce any output (except the benchmark?s output). > > Thanks > Stefan > > -- > Stefan Marr > INRIA Lille - Nord Europe > http://stefan-marr.de/research/ > > > From java at stefan-marr.de Wed Sep 17 14:30:34 2014 From: java at stefan-marr.de (Stefan Marr) Date: Wed, 17 Sep 2014 16:30:34 +0200 Subject: How to use ProfileCompiledMethods In-Reply-To: References: Message-ID: <17DE6D5E-A39A-47BB-AC9A-1FCC475AA7B0@stefan-marr.de> Hi Lukas: On 17 Sep 2014, at 16:09, Lukas Stadler wrote: > The "out,warmup finished,finished? clause means that it will listen on System.out, start measuring when it encounters ?warmup finished? and print results when it encounters ?finished?. > Is it possible that that is does not occur in our benchmark setup? Thanks! I didn?t understand that part, and after adapting it I get the desired output. Bye the way, I noticed that my DeltaBlue runs quite a bit faster at peek performance with graal vs. server. Is this expected? Should I be using the graal build for benchmarking? And, for benchmarking, is the bootstrap necessary to get peek performance? Thanks Stefan -- Stefan Marr INRIA Lille - Nord Europe http://stefan-marr.de/research/ From lukas.stadler at oracle.com Wed Sep 17 16:26:56 2014 From: lukas.stadler at oracle.com (Lukas Stadler) Date: Wed, 17 Sep 2014 18:26:56 +0200 Subject: How to use ProfileCompiledMethods In-Reply-To: <17DE6D5E-A39A-47BB-AC9A-1FCC475AA7B0@stefan-marr.de> References: <17DE6D5E-A39A-47BB-AC9A-1FCC475AA7B0@stefan-marr.de> Message-ID: Hi! On 17 Sep 2014, at 16:30, Stefan Marr wrote: > On 17 Sep 2014, at 16:09, Lukas Stadler wrote: > >> The "out,warmup finished,finished? clause means that it will listen on System.out, start measuring when it encounters ?warmup finished? and print results when it encounters ?finished?. >> Is it possible that that is does not occur in our benchmark setup? > > Thanks! I didn?t understand that part, and after adapting it I get the desired output. > > Bye the way, I noticed that my DeltaBlue runs quite a bit faster at peek performance with graal vs. server. Is this expected? Should I be using the graal build for benchmarking? That is somewhat unexpected, since peak performance should be influenced only by the code generated by Truffle partial evaluated methods - and that should be the same in both server and graal configurations (it still uses Graal for this in server mode). I don?t think that any of the other languages benchmarks with ?-graal?, maybe Christian can comment on this? > And, for benchmarking, is the bootstrap necessary to get peek performance? A bootstrap should not be necessary. - Lukas From bernhard.urban at jku.at Wed Sep 17 16:53:54 2014 From: bernhard.urban at jku.at (Bernhard Urban) Date: Wed, 17 Sep 2014 18:53:54 +0200 Subject: How to use ProfileCompiledMethods In-Reply-To: References: <17DE6D5E-A39A-47BB-AC9A-1FCC475AA7B0@stefan-marr.de> Message-ID: On Wed, Sep 17, 2014 at 6:26 PM, Lukas Stadler wrote: > Hi! > > On 17 Sep 2014, at 16:30, Stefan Marr wrote: > > > On 17 Sep 2014, at 16:09, Lukas Stadler > wrote: > > > >> The "out,warmup finished,finished? clause means that it will listen on > System.out, start measuring when it encounters ?warmup finished? and print > results when it encounters ?finished?. > >> Is it possible that that is does not occur in our benchmark setup? > > > > Thanks! I didn?t understand that part, and after adapting it I get the > desired output. > > > > Bye the way, I noticed that my DeltaBlue runs quite a bit faster at peek > performance with graal vs. server. Is this expected? Should I be using the > graal build for benchmarking? > > That is somewhat unexpected, since peak performance should be influenced > only by the code generated by Truffle partial evaluated methods - and that > should be the same in both server and graal configurations (it still uses > Graal for this in server mode). I don?t think that any of the other > languages benchmarks with ?-graal?, maybe Christian can comment on this? > @SlowPath annotated methods can be compiled by the host compiler, therefore it can have different performance characteristics. -Bernhard From java at stefan-marr.de Wed Sep 17 18:57:13 2014 From: java at stefan-marr.de (Stefan Marr) Date: Wed, 17 Sep 2014 20:57:13 +0200 Subject: Recent Truffle DSL changes. In-Reply-To: <54D3BDC5-2312-4542-946B-AE0866F6D57E@stefan-marr.de> References: <54D3BDC5-2312-4542-946B-AE0866F6D57E@stefan-marr.de> Message-ID: Hi Christian: Now I am running into issues. I belief your new rewriting logic in the generated code for polymorphic nodes is not completely thread safe. Specifically, I am running into issues that a node is supposed to be rewritten, but not actually adopted yet. In case you might have a hunch, let me know. Will try to have a look later this week. To reproduce, you?ll need the thread-support branch and start a benchmark with at least 2 threads: git clone --recursive -b thread-support https://github.com/SOM-st/TruffleSOM.git cd TruffleSOM ant ./som.sh -cp Smalltalk Examples/Benchmarks/BenchmarkHarness.som Dispatch 10 0 10 2 Best regards Stefan On 16 Sep 2014, at 23:57, Stefan Marr wrote: > Hi Christian: > > On 11 Aug 2014, at 19:59, Christian Humer wrote: > >> I just pushed some new features to the DSL for the upcoming Truffle >> release. Please note that some of the changes may break existing Truffle >> interpreters. Guest languages that don't use Truffle DSL are not affected >> by this push. > > I finally found the time to update Graal. > Looks good. Didn?t had any major issues. Performance seems to remain more or less the same. > > Only got two nits. The first one is that the generated code does have one simple issue with the code style, which can be solved by initializing the method body unconditionally (see patch below). > The second thing is a simple typo in one of the error messages. > > Best regards > Stefan > > diff --git a/graal/com.oracle.truffle.dsl.processor/src/com/oracle/truffle/dsl/processor/generator/NodeCodeGenerator.java b/graal/com.oracle.truffle.dsl.processor/src/com/oracle/truffle/dsl/processor/generator/NodeCodeGenerator.java > index 0a38640..c3bc5eb 100644 > --- a/graal/com.oracle.truffle.dsl.processor/src/com/oracle/truffle/dsl/processor/generator/NodeCodeGenerator.java > +++ b/graal/com.oracle.truffle.dsl.processor/src/com/oracle/truffle/dsl/processor/generator/NodeCodeGenerator.java > @@ -906,9 +906,9 @@ public class NodeCodeGenerator extends AbstractCompilationUnitFactory > CodeExecutableElement method = new CodeExecutableElement(modifiers(PUBLIC), context.getType(void.class), "updateTypes0"); > method.getParameters().add(new CodeVariableElement(classArray, "types")); > > - if (getModel().isPolymorphic()) { > - CodeTreeBuilder builder = method.createBuilder(); > + CodeTreeBuilder builder = method.createBuilder(); > > + if (getModel().isPolymorphic()) { > int index = 0; > for (NodeExecutionData execution : getModel().getNode().getChildExecutions()) { > String fieldName = polymorphicTypeName(execution); > diff --git a/graal/com.oracle.truffle.dsl.processor/src/com/oracle/truffle/dsl/processor/parser/NodeParser.java b/graal/com.oracle.truffle.dsl.processor/src/com/oracle/truffle/dsl/processor/parser/NodeParser.java > index 202815e..516dc18 100644 > --- a/graal/com.oracle.truffle.dsl.processor/src/com/oracle/truffle/dsl/processor/parser/NodeParser.java > +++ b/graal/com.oracle.truffle.dsl.processor/src/com/oracle/truffle/dsl/processor/parser/NodeParser.java > @@ -650,7 +650,7 @@ public class NodeParser extends AbstractParser { > SpecializationData next = i + 1 < specializations.size() ? specializations.get(i + 1) : null; > > if (!cur.isContainedBy(next)) { > - next.addError("This specialiation is not a valid exceptional rewrite target for %s. To fix this make %s compatible to %s or remove the exceptional rewrite.", > + next.addError("This specialization is not a valid exceptional rewrite target for %s. To fix this make %s compatible to %s or remove the exceptional rewrite.", > cur.createReferenceName(), next != null ? next.createReferenceName() : "-", cur.createReferenceName()); > continue; > } > -- > 1.9.1 > > > > > -- > Stefan Marr > INRIA Lille - Nord Europe > http://stefan-marr.de/research/ > > > -- Stefan Marr INRIA Lille - Nord Europe http://stefan-marr.de/research/ From christian.humer at gmail.com Wed Sep 17 22:05:09 2014 From: christian.humer at gmail.com (Christian Humer) Date: Thu, 18 Sep 2014 00:05:09 +0200 Subject: Recent Truffle DSL changes. In-Reply-To: References: <54D3BDC5-2312-4542-946B-AE0866F6D57E@stefan-marr.de> Message-ID: Hi Stefan, Regarding the thread-safety issues. Yes polymorphic rewrites are not yet thread-safe. But they were also not thread-safe in the old version. So you might have been just lucky. However it is straight forward to make them thread-safe. You just have to wrap every replace in DSLShare into a closure and call atomic on the node that is currently in the AST. I've attached a patch. Let me know if that works for you. So I can push it tomorrow. (Had no time to verify it yet) Also be careful with the rewriting of function inline caches so that replaces are always atomic. Also important is that you are not moving one used AST node from one place to another. Instead copy it, remove the old and insert the copy. - Christian Humer On Wed, Sep 17, 2014 at 8:57 PM, Stefan Marr wrote: > Hi Christian: > > Now I am running into issues. > I belief your new rewriting logic in the generated code for polymorphic > nodes is not completely thread safe. > > Specifically, I am running into issues that a node is supposed to be > rewritten, but not actually adopted yet. > > In case you might have a hunch, let me know. Will try to have a look later > this week. > > > To reproduce, you?ll need the thread-support branch and start a benchmark > with at least 2 threads: > > git clone --recursive -b thread-support > https://github.com/SOM-st/TruffleSOM.git > cd TruffleSOM > ant > ./som.sh -cp Smalltalk Examples/Benchmarks/BenchmarkHarness.som Dispatch > 10 0 10 2 > > Best regards > Stefan > > > On 16 Sep 2014, at 23:57, Stefan Marr wrote: > > > Hi Christian: > > > > On 11 Aug 2014, at 19:59, Christian Humer > wrote: > > > >> I just pushed some new features to the DSL for the upcoming Truffle > >> release. Please note that some of the changes may break existing Truffle > >> interpreters. Guest languages that don't use Truffle DSL are not > affected > >> by this push. > > > > I finally found the time to update Graal. > > Looks good. Didn?t had any major issues. Performance seems to remain > more or less the same. > > > > Only got two nits. The first one is that the generated code does have > one simple issue with the code style, which can be solved by initializing > the method body unconditionally (see patch below). > > The second thing is a simple typo in one of the error messages. > > > > Best regards > > Stefan > > > > diff --git > a/graal/com.oracle.truffle.dsl.processor/src/com/oracle/truffle/dsl/processor/generator/NodeCodeGenerator.java > b/graal/com.oracle.truffle.dsl.processor/src/com/oracle/truffle/dsl/processor/generator/NodeCodeGenerator.java > > index 0a38640..c3bc5eb 100644 > > --- > a/graal/com.oracle.truffle.dsl.processor/src/com/oracle/truffle/dsl/processor/generator/NodeCodeGenerator.java > > +++ > b/graal/com.oracle.truffle.dsl.processor/src/com/oracle/truffle/dsl/processor/generator/NodeCodeGenerator.java > > @@ -906,9 +906,9 @@ public class NodeCodeGenerator extends > AbstractCompilationUnitFactory > > CodeExecutableElement method = new > CodeExecutableElement(modifiers(PUBLIC), context.getType(void.class), > "updateTypes0"); > > method.getParameters().add(new > CodeVariableElement(classArray, "types")); > > > > - if (getModel().isPolymorphic()) { > > - CodeTreeBuilder builder = method.createBuilder(); > > + CodeTreeBuilder builder = method.createBuilder(); > > > > + if (getModel().isPolymorphic()) { > > int index = 0; > > for (NodeExecutionData execution : > getModel().getNode().getChildExecutions()) { > > String fieldName = polymorphicTypeName(execution); > > diff --git > a/graal/com.oracle.truffle.dsl.processor/src/com/oracle/truffle/dsl/processor/parser/NodeParser.java > b/graal/com.oracle.truffle.dsl.processor/src/com/oracle/truffle/dsl/processor/parser/NodeParser.java > > index 202815e..516dc18 100644 > > --- > a/graal/com.oracle.truffle.dsl.processor/src/com/oracle/truffle/dsl/processor/parser/NodeParser.java > > +++ > b/graal/com.oracle.truffle.dsl.processor/src/com/oracle/truffle/dsl/processor/parser/NodeParser.java > > @@ -650,7 +650,7 @@ public class NodeParser extends > AbstractParser { > > SpecializationData next = i + 1 < specializations.size() ? > specializations.get(i + 1) : null; > > > > if (!cur.isContainedBy(next)) { > > - next.addError("This specialiation is not a valid > exceptional rewrite target for %s. To fix this make %s compatible to %s or > remove the exceptional rewrite.", > > + next.addError("This specialization is not a valid > exceptional rewrite target for %s. To fix this make %s compatible to %s or > remove the exceptional rewrite.", > > cur.createReferenceName(), next != null > ? next.createReferenceName() : "-", cur.createReferenceName()); > > continue; > > } > > -- > > 1.9.1 > > > > > > > > > > -- > > Stefan Marr > > INRIA Lille - Nord Europe > > http://stefan-marr.de/research/ > > > > > > > > -- > Stefan Marr > INRIA Lille - Nord Europe > http://stefan-marr.de/research/ > > > > -------------- next part -------------- # HG changeset patch # Parent b391c2f1901665081ee685a8416c27ff87cd4ddd Truffle-DSL: added thread-safety for DSL rewrites. diff -r b391c2f19016 -r 6817f289f27a graal/com.oracle.truffle.api.dsl/src/com/oracle/truffle/api/dsl/internal/DSLShare.java --- a/graal/com.oracle.truffle.api.dsl/src/com/oracle/truffle/api/dsl/internal/DSLShare.java Fri Sep 05 00:08:16 2014 +0200 +++ b/graal/com.oracle.truffle.api.dsl/src/com/oracle/truffle/api/dsl/internal/DSLShare.java Wed Sep 17 23:57:33 2014 +0200 @@ -25,6 +25,7 @@ package com.oracle.truffle.api.dsl.internal; import java.util.*; +import java.util.concurrent.*; import com.oracle.truffle.api.nodes.*; @@ -50,19 +51,23 @@ return containsClass(newNode.getMetadata0().getIncludes(), oldNode); } - public static T rewrite(Node thisNode, T newNode, String message) { - assert newNode != null; - if (getNext(thisNode) != null || getPrevious(thisNode) != null) { - // already polymorphic -> append - return appendPolymorphic(findUninitialized(thisNode), newNode); - } else if (includes(thisNode, newNode)) { - // included -> remains monomorphic - newNode.adoptChildren0(thisNode, null); - return thisNode.replace(newNode, message); - } else { - // goto polymorphic - return null; - } + public static T rewrite(final Node thisNode, final T newNode, final String message) { + return thisNode.atomic(new Callable() { + public T call() { + assert newNode != null; + if (getNext(thisNode) != null || getPrevious(thisNode) != null) { + // already polymorphic -> append + return appendPolymorphic(findUninitialized(thisNode), newNode); + } else if (includes(thisNode, newNode)) { + // included -> remains monomorphic + newNode.adoptChildren0(thisNode, null); + return thisNode.replace(newNode, message); + } else { + // goto polymorphic + return null; + } + } + }); } @SuppressWarnings("unchecked") @@ -86,37 +91,47 @@ return cur; } - public static T rewriteUninitialized(Node uninitialized, T newNode) { - Node prev = getPrevious(uninitialized); - if (prev == null) { - newNode.adoptChildren0(uninitialized, null); - return uninitialized.replace(newNode, "Uninitialized monomorphic"); - } else { - return appendPolymorphic(uninitialized, newNode); - } + public static T rewriteUninitialized(final Node uninitialized, final T newNode) { + return uninitialized.atomic(new Callable() { + public T call() { + Node prev = getPrevious(uninitialized); + if (prev == null) { + newNode.adoptChildren0(uninitialized, null); + return uninitialized.replace(newNode, "Uninitialized monomorphic"); + } else { + return appendPolymorphic(uninitialized, newNode); + } + } + }); + } - public static T rewriteToPolymorphic(Node oldNode, DSLNode uninitializedDSL, T polymorphic, DSLNode currentCopy, DSLNode newNodeDSL, String message) { - assert getNext(oldNode) == null; - assert getPrevious(oldNode) == null; - assert newNodeDSL != null; + public static T rewriteToPolymorphic(final Node oldNode, final DSLNode uninitializedDSL, final T polymorphic, final DSLNode currentCopy, final DSLNode newNodeDSL, + final String message) { + return oldNode.atomic(new Callable() { + public T call() { + assert getNext(oldNode) == null; + assert getPrevious(oldNode) == null; + assert newNodeDSL != null; - Node uninitialized = (Node) uninitializedDSL; - Node newNode = (Node) newNodeDSL; - polymorphic.adoptChildren0(oldNode, (Node) currentCopy); + Node uninitialized = (Node) uninitializedDSL; + Node newNode = (Node) newNodeDSL; + polymorphic.adoptChildren0(oldNode, (Node) currentCopy); - updateSourceSection(oldNode, uninitialized); - // new specialization - updateSourceSection(oldNode, newNode); - newNodeDSL.adoptChildren0(null, uninitialized); - currentCopy.adoptChildren0(null, newNode); + updateSourceSection(oldNode, uninitialized); + // new specialization + updateSourceSection(oldNode, newNode); + newNodeDSL.adoptChildren0(null, uninitialized); + currentCopy.adoptChildren0(null, newNode); - oldNode.replace(polymorphic, message); + oldNode.replace(polymorphic, message); - assert polymorphic.getNext0() == currentCopy; - assert newNode != null ? currentCopy.getNext0() == newNode : currentCopy.getNext0() == uninitialized; - assert uninitializedDSL.getNext0() == null; - return polymorphic; + assert polymorphic.getNext0() == currentCopy; + assert newNode != null ? currentCopy.getNext0() == newNode : currentCopy.getNext0() == uninitialized; + assert uninitializedDSL.getNext0() == null; + return polymorphic; + } + }); } private static void updateSourceSection(Node oldNode, Node newNode) { From doug.simon at oracle.com Thu Sep 18 01:00:07 2014 From: doug.simon at oracle.com (doug.simon at oracle.com) Date: Thu, 18 Sep 2014 01:00:07 +0000 Subject: hg: graal/graal: 28 new changesets Message-ID: <201409180100.s8I109tP012941@aojmv0008> Changeset: 9a0bf0c3b21e Author: Stefan Anzinger Date: 2014-09-16 11:49 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/9a0bf0c3b21e [SPARC] Use VIS3 moves between fp and gp registers when available ! graal/com.oracle.graal.compiler.sparc/src/com/oracle/graal/compiler/sparc/SPARCLIRGenerator.java ! graal/com.oracle.graal.hotspot.sparc/src/com/oracle/graal/hotspot/sparc/SPARCHotSpotBackendFactory.java ! graal/com.oracle.graal.lir.sparc/src/com/oracle/graal/lir/sparc/SPARCMove.java Changeset: dced35fd40f7 Author: Stefan Anzinger Date: 2014-09-16 15:36 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/dced35fd40f7 [SPARC] fix the floatingpoint loading of constant +0.0 and -0.0, changed ArraysCompare more to the C2 implementation. ! graal/com.oracle.graal.asm.sparc/src/com/oracle/graal/asm/sparc/SPARCAssembler.java ! graal/com.oracle.graal.lir.sparc/src/com/oracle/graal/lir/sparc/SPARCArrayEqualsOp.java ! graal/com.oracle.graal.lir.sparc/src/com/oracle/graal/lir/sparc/SPARCMove.java Changeset: d980377abc6f Author: Stefan Anzinger Date: 2014-09-16 17:49 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/d980377abc6f [SPARC] MathIntrinsic for sqrt and abs ! graal/com.oracle.graal.asm.sparc/src/com/oracle/graal/asm/sparc/SPARCAssembler.java ! graal/com.oracle.graal.compiler.sparc/src/com/oracle/graal/compiler/sparc/SPARCLIRGenerator.java ! graal/com.oracle.graal.lir.sparc/src/com/oracle/graal/lir/sparc/SPARCMathIntrinsicOp.java ! graal/com.oracle.graal.replacements/src/com/oracle/graal/replacements/MathSubstitutionsX86.java Changeset: be9c24f5fa2b Author: Stefan Anzinger Date: 2014-09-16 17:49 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/be9c24f5fa2b [SPARC] Remove unneccessary nops after calls ! graal/com.oracle.graal.lir.sparc/src/com/oracle/graal/lir/sparc/SPARCCall.java Changeset: 60844c15ab27 Author: Stefan Anzinger Date: 2014-09-17 08:21 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/60844c15ab27 [SPARC] Add nop again otherwise the information on pc is not unique ! graal/com.oracle.graal.lir.sparc/src/com/oracle/graal/lir/sparc/SPARCCall.java Changeset: 832c8c93c949 Author: Stefan Anzinger Date: 2014-09-17 08:22 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/832c8c93c949 [SPARC] Now doing alignment bytewise and not instruction-wise (nop in AMD64 has one byte, nop in SPARC four bytes) ! graal/com.oracle.graal.asm.sparc/src/com/oracle/graal/asm/sparc/SPARCMacroAssembler.java Changeset: 4a1ee9bebd33 Author: Stefan Anzinger Date: 2014-09-17 08:23 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/4a1ee9bebd33 Merge Changeset: 5a260e749bca Author: Christian Wimmer Date: 2014-09-16 18:35 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/5a260e749bca Fixes for SimpleLanguage when compiling ! graal/com.oracle.truffle.sl/src/com/oracle/truffle/sl/builtins/SLHelloEqualsWorldBuiltin.java ! graal/com.oracle.truffle.sl/src/com/oracle/truffle/sl/builtins/SLStackTraceBuiltin.java Changeset: deab46118819 Author: Christian Wimmer Date: 2014-09-16 18:35 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/deab46118819 Add methods to InstalledCode ! graal/com.oracle.graal.api.code/src/com/oracle/graal/api/code/InstalledCode.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotInstalledCode.java Changeset: 7b3ece800806 Author: Christian Wimmer Date: 2014-09-16 18:36 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/7b3ece800806 Using getKind().format is unnecessary ! graal/com.oracle.graal.api.meta/src/com/oracle/graal/api/meta/PrimitiveConstant.java Changeset: ce1b6453c544 Author: Christian Wimmer Date: 2014-09-16 18:36 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/ce1b6453c544 Add ResolvedJavaMethod.getAnnotations ! 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 Changeset: 7a0bff31df98 Author: Christian Wimmer Date: 2014-09-16 18:40 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/7a0bff31df98 Encapsulate creation of LinearScan object ! graal/com.oracle.graal.baseline/src/com/oracle/graal/baseline/BaselineBytecodeParser.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 Changeset: 3db919d1c8d5 Author: Christian Wimmer Date: 2014-09-16 18:41 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/3db919d1c8d5 Add option to disable Graal graph verification (which takes very long for big graphs) ! graal/com.oracle.graal.graph/src/com/oracle/graal/graph/Graph.java Changeset: 8ec6deb7d2eb Author: Christian Wimmer Date: 2014-09-16 18:41 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/8ec6deb7d2eb Fix when not using generated node classes ! graal/com.oracle.graal.graph/src/com/oracle/graal/graph/NodeClass.java Changeset: f2a87467d41a Author: Christian Wimmer Date: 2014-09-16 18:42 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/f2a87467d41a Allow lowering of DynamicDeoptimizeNode ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/DefaultHotSpotLoweringProvider.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/DynamicDeoptimizeNode.java Changeset: f396d15ddce2 Author: Christian Wimmer Date: 2014-09-16 18:43 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/f396d15ddce2 Factor out HotSpot-independent parts of ArrayCopy and ObjectClone nodes ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/ArrayCopyCallNode.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.replacements/src/com/oracle/graal/replacements/nodes/BasicArrayCopyNode.java + graal/com.oracle.graal.replacements/src/com/oracle/graal/replacements/nodes/BasicObjectCloneNode.java Changeset: 4e15850b67bb Author: Christian Wimmer Date: 2014-09-16 18:48 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/4e15850b67bb Make liveness analysis configurable by graph builder configuration ! graal/com.oracle.graal.baseline/src/com/oracle/graal/baseline/BaselineBytecodeParser.java ! graal/com.oracle.graal.java/src/com/oracle/graal/java/AbstractBytecodeParser.java ! graal/com.oracle.graal.java/src/com/oracle/graal/java/BciBlockMapping.java ! graal/com.oracle.graal.java/src/com/oracle/graal/java/GraphBuilderConfiguration.java ! graal/com.oracle.graal.java/src/com/oracle/graal/java/GraphBuilderPhase.java Changeset: 71e56d7bc888 Author: Christian Wimmer Date: 2014-09-16 18:49 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/71e56d7bc888 Make methods accessible ! graal/com.oracle.graal.lir/src/com/oracle/graal/lir/LIRInstructionClass.java Changeset: 1a02fc45776f Author: Christian Wimmer Date: 2014-09-16 18:52 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/1a02fc45776f Allow customization by subclasses ! 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: 63b359cf25ad Author: Christian Wimmer Date: 2014-09-16 18:52 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/63b359cf25ad Allow customization by subclasses ! graal/com.oracle.graal.replacements/src/com/oracle/graal/replacements/DefaultJavaLoweringProvider.java Changeset: ceb34d2d124e Author: Christian Wimmer Date: 2014-09-16 18:53 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/ceb34d2d124e Make fields and constructors protected to allow subclasses in different packages ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/calc/FixedBinaryNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/extended/ForeignCallNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/java/CheckCastNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/java/InstanceOfNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/java/MethodCallTargetNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/java/NewMultiArrayNode.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/VirtualBoxingNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/virtual/VirtualInstanceNode.java Changeset: 42ee7621a3fa Author: Christian Wimmer Date: 2014-09-16 18:53 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/42ee7621a3fa Do not hardcode the stamp of deoptimization reasonAndAcation and speculation ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/DeoptimizationGroupingPhase.java Changeset: ac687cfbed21 Author: Christian Wimmer Date: 2014-09-16 18:54 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/ac687cfbed21 Delete temporary node ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/LoweringPhase.java Changeset: de926488f244 Author: Christian Wimmer Date: 2014-09-16 18:54 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/de926488f244 Avoid NullPointerException ! graal/com.oracle.graal.printer/src/com/oracle/graal/printer/CompilationPrinter.java Changeset: 21fdd914bb8f Author: Christian Wimmer Date: 2014-09-16 18:55 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/21fdd914bb8f Create frame state with correct bci ! graal/com.oracle.graal.replacements/src/com/oracle/graal/replacements/GraphKit.java Changeset: f95ddcd3e08a Author: Christian Wimmer Date: 2014-09-16 18:56 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/f95ddcd3e08a Allow customization by subclasses ! graal/com.oracle.graal.replacements/src/com/oracle/graal/replacements/NodeIntrinsificationPhase.java ! graal/com.oracle.graal.replacements/src/com/oracle/graal/replacements/ReplacementsImpl.java ! graal/com.oracle.graal.replacements/src/com/oracle/graal/replacements/SnippetTemplate.java Changeset: 2d01369ee234 Author: Christian Wimmer Date: 2014-09-17 09:06 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/2d01369ee234 Add unit test ! graal/com.oracle.graal.api.meta.test/src/com/oracle/graal/api/meta/test/TestResolvedJavaMethod.java Changeset: 62d7d16b170b Author: Christian Wimmer Date: 2014-09-17 09:33 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/62d7d16b170b Merge From java at stefan-marr.de Thu Sep 18 09:12:58 2014 From: java at stefan-marr.de (Stefan Marr) Date: Thu, 18 Sep 2014 11:12:58 +0200 Subject: Recent Truffle DSL changes. In-Reply-To: References: <54D3BDC5-2312-4542-946B-AE0866F6D57E@stefan-marr.de> Message-ID: <64D4755B-6518-4732-B003-247660F9139A@stefan-marr.de> Hi Christian: On 18 Sep 2014, at 00:05, Christian Humer wrote: > Regarding the thread-safety issues. Yes polymorphic rewrites are not yet thread-safe. But they were also not thread-safe in the old version. So you might have been just lucky. > However it is straight forward to make them thread-safe. You just have to wrap every replace in DSLShare into a closure and call atomic on the node that is currently in the AST. > I've attached a patch. Let me know if that works for you. So I can push it tomorrow. (Had no time to verify it yet) Have only tested it briefly, but there is still an issue with a node that doesn?t have a parent yet. The Eclipse and the JVM are unfortunately rather uncooperative. Debugging this isn?t exactly easy, because for half of the objects Eclipse refuses to give me any information. Is this a known issue? I set the debugger to suspend the VM once an illegal state exception is hit. That doesn?t seem to be a good idea. Will try to look into it later today. Thanks Stefan -- Stefan Marr INRIA Lille - Nord Europe http://stefan-marr.de/research/ From doug.simon at oracle.com Thu Sep 18 10:10:41 2014 From: doug.simon at oracle.com (Doug Simon) Date: Thu, 18 Sep 2014 12:10:41 +0200 Subject: Recent Truffle DSL changes. In-Reply-To: <64D4755B-6518-4732-B003-247660F9139A@stefan-marr.de> References: <54D3BDC5-2312-4542-946B-AE0866F6D57E@stefan-marr.de> <64D4755B-6518-4732-B003-247660F9139A@stefan-marr.de> Message-ID: <6A3FE81D-09C0-4980-B3BC-1CB185798419@oracle.com> On Sep 18, 2014, at 11:12 AM, Stefan Marr wrote: > Hi Christian: > > On 18 Sep 2014, at 00:05, Christian Humer wrote: > >> Regarding the thread-safety issues. Yes polymorphic rewrites are not yet thread-safe. But they were also not thread-safe in the old version. So you might have been just lucky. >> However it is straight forward to make them thread-safe. You just have to wrap every replace in DSLShare into a closure and call atomic on the node that is currently in the AST. >> I've attached a patch. Let me know if that works for you. So I can push it tomorrow. (Had no time to verify it yet) > > Have only tested it briefly, but there is still an issue with a node that doesn?t have a parent yet. > The Eclipse and the JVM are unfortunately rather uncooperative. Debugging this isn?t exactly easy, because for half of the objects Eclipse refuses to give me any information. > Is this a known issue? I set the debugger to suspend the VM once an illegal state exception is hit. That doesn?t seem to be a good idea. Try setting the exception breakpoint to ?suspend thread? instead of ?suspend VM?. This resolved most of my issues where Eclipse does not respond. -Doug From java at stefan-marr.de Thu Sep 18 13:08:01 2014 From: java at stefan-marr.de (Stefan Marr) Date: Thu, 18 Sep 2014 15:08:01 +0200 Subject: Recent Truffle DSL changes. In-Reply-To: <64D4755B-6518-4732-B003-247660F9139A@stefan-marr.de> References: <54D3BDC5-2312-4542-946B-AE0866F6D57E@stefan-marr.de> <64D4755B-6518-4732-B003-247660F9139A@stefan-marr.de> Message-ID: Hi Christian: While trying to debug the problem I am seeing, I noticed something I haven?t noticed before, and would like to hear whether it is by design or whether I can do something about it. In my node to read local variables, I got specializations for the different slot types: https://github.com/SOM-st/TruffleSOM/blob/master/src/som/interpreter/nodes/LocalVariableNode.java#L56-L76 However, now it looks like the generated code goes through all specializations in a top to bottom approach, until the correct one is found. And this involves creating new nodes, and leads eventually to the ?concurrency? issue I was seeing. For me the question now is whether I can avoid all the ?unnecessary? trial and error somehow. I was experimenting with a guard on the slot kind that tests the slot type specifically to be boolean, long, or double. However, since I need the rewriteOn = slot-type-exception, the DSL now tells me that the different specializations are not compatible to each other. I was experimenting also with ?contains?, but that does not seem to make a difference. So, I was wondering whether the brute-force approaches is intended, or whether there is an easy way around by for instance telling the DSL that doObject is the next general thing after doBool, doLong, or doDouble respectively. Thanks Stefan On 18 Sep 2014, at 11:12, Stefan Marr wrote: > Hi Christian: > > On 18 Sep 2014, at 00:05, Christian Humer wrote: > >> Regarding the thread-safety issues. Yes polymorphic rewrites are not yet thread-safe. But they were also not thread-safe in the old version. So you might have been just lucky. >> However it is straight forward to make them thread-safe. You just have to wrap every replace in DSLShare into a closure and call atomic on the node that is currently in the AST. >> I've attached a patch. Let me know if that works for you. So I can push it tomorrow. (Had no time to verify it yet) > > Have only tested it briefly, but there is still an issue with a node that doesn?t have a parent yet. > The Eclipse and the JVM are unfortunately rather uncooperative. Debugging this isn?t exactly easy, because for half of the objects Eclipse refuses to give me any information. > Is this a known issue? I set the debugger to suspend the VM once an illegal state exception is hit. That doesn?t seem to be a good idea. > > Will try to look into it later today. > > Thanks > Stefan > > -- > Stefan Marr > INRIA Lille - Nord Europe > http://stefan-marr.de/research/ > > > -- Stefan Marr INRIA Lille - Nord Europe http://stefan-marr.de/research/ From java at stefan-marr.de Thu Sep 18 14:28:40 2014 From: java at stefan-marr.de (Stefan Marr) Date: Thu, 18 Sep 2014 16:28:40 +0200 Subject: Recent Truffle DSL changes. In-Reply-To: References: <54D3BDC5-2312-4542-946B-AE0866F6D57E@stefan-marr.de> Message-ID: <66A57E3F-2A78-497A-90F4-7456912E3520@stefan-marr.de> Hi Christian: Trying to figure out what the issue could be, I am wondering what the idea behind the replaceHelper logic and the difference between adoptHelper(.) and adoptUnadoptedHelper(.) is. Somehow, there seem to be situations in which the resulting tree contains nodes for which the parent link has not been set. I am also wondering, whether the approach of synchronizing on the level of the rewrite operations itself is reliable enough or whether the synchronization should happen one level up, i.e., the specialization logic might need to ensure that each node is only specialized exactly once. Otherwise, two threads could end up specializing the tree multiple times for the same node, racing for the replace. The thread that wins the race for the replace will continue executing a sub tree that is going to be removed from main tree once the second thread specialized the node. I assume, this could lead to all kind of strange and undesirable situations. Does any of that make sense, or am I missing something? Thanks Stefan On 18 Sep 2014, at 00:05, Christian Humer wrote: > Hi Stefan, > > Regarding the thread-safety issues. Yes polymorphic rewrites are not yet thread-safe. But they were also not thread-safe in the old version. So you might have been just lucky. > However it is straight forward to make them thread-safe. You just have to wrap every replace in DSLShare into a closure and call atomic on the node that is currently in the AST. > I've attached a patch. Let me know if that works for you. So I can push it tomorrow. (Had no time to verify it yet) > Also be careful with the rewriting of function inline caches so that replaces are always atomic. Also important is that you are not moving one used AST node from one place to another. Instead copy it, remove the old and insert the copy. > > > - Christian Humer > > On Wed, Sep 17, 2014 at 8:57 PM, Stefan Marr wrote: > Hi Christian: > > Now I am running into issues. > I belief your new rewriting logic in the generated code for polymorphic nodes is not completely thread safe. > > Specifically, I am running into issues that a node is supposed to be rewritten, but not actually adopted yet. > > In case you might have a hunch, let me know. Will try to have a look later this week. > > > To reproduce, you?ll need the thread-support branch and start a benchmark with at least 2 threads: > > git clone --recursive -b thread-support https://github.com/SOM-st/TruffleSOM.git > cd TruffleSOM > ant > ./som.sh -cp Smalltalk Examples/Benchmarks/BenchmarkHarness.som Dispatch 10 0 10 2 > > Best regards > Stefan > > > On 16 Sep 2014, at 23:57, Stefan Marr wrote: > > > Hi Christian: > > > > On 11 Aug 2014, at 19:59, Christian Humer wrote: > > > >> I just pushed some new features to the DSL for the upcoming Truffle > >> release. Please note that some of the changes may break existing Truffle > >> interpreters. Guest languages that don't use Truffle DSL are not affected > >> by this push. > > > > I finally found the time to update Graal. > > Looks good. Didn?t had any major issues. Performance seems to remain more or less the same. > > > > Only got two nits. The first one is that the generated code does have one simple issue with the code style, which can be solved by initializing the method body unconditionally (see patch below). > > The second thing is a simple typo in one of the error messages. > > > > Best regards > > Stefan > > > > diff --git a/graal/com.oracle.truffle.dsl.processor/src/com/oracle/truffle/dsl/processor/generator/NodeCodeGenerator.java b/graal/com.oracle.truffle.dsl.processor/src/com/oracle/truffle/dsl/processor/generator/NodeCodeGenerator.java > > index 0a38640..c3bc5eb 100644 > > --- a/graal/com.oracle.truffle.dsl.processor/src/com/oracle/truffle/dsl/processor/generator/NodeCodeGenerator.java > > +++ b/graal/com.oracle.truffle.dsl.processor/src/com/oracle/truffle/dsl/processor/generator/NodeCodeGenerator.java > > @@ -906,9 +906,9 @@ public class NodeCodeGenerator extends AbstractCompilationUnitFactory > > CodeExecutableElement method = new CodeExecutableElement(modifiers(PUBLIC), context.getType(void.class), "updateTypes0"); > > method.getParameters().add(new CodeVariableElement(classArray, "types")); > > > > - if (getModel().isPolymorphic()) { > > - CodeTreeBuilder builder = method.createBuilder(); > > + CodeTreeBuilder builder = method.createBuilder(); > > > > + if (getModel().isPolymorphic()) { > > int index = 0; > > for (NodeExecutionData execution : getModel().getNode().getChildExecutions()) { > > String fieldName = polymorphicTypeName(execution); > > diff --git a/graal/com.oracle.truffle.dsl.processor/src/com/oracle/truffle/dsl/processor/parser/NodeParser.java b/graal/com.oracle.truffle.dsl.processor/src/com/oracle/truffle/dsl/processor/parser/NodeParser.java > > index 202815e..516dc18 100644 > > --- a/graal/com.oracle.truffle.dsl.processor/src/com/oracle/truffle/dsl/processor/parser/NodeParser.java > > +++ b/graal/com.oracle.truffle.dsl.processor/src/com/oracle/truffle/dsl/processor/parser/NodeParser.java > > @@ -650,7 +650,7 @@ public class NodeParser extends AbstractParser { > > SpecializationData next = i + 1 < specializations.size() ? specializations.get(i + 1) : null; > > > > if (!cur.isContainedBy(next)) { > > - next.addError("This specialiation is not a valid exceptional rewrite target for %s. To fix this make %s compatible to %s or remove the exceptional rewrite.", > > + next.addError("This specialization is not a valid exceptional rewrite target for %s. To fix this make %s compatible to %s or remove the exceptional rewrite.", > > cur.createReferenceName(), next != null ? next.createReferenceName() : "-", cur.createReferenceName()); > > continue; > > } > > -- > > 1.9.1 > > > > > > > > > > -- > > Stefan Marr > > INRIA Lille - Nord Europe > > http://stefan-marr.de/research/ > > > > > > > > -- > Stefan Marr > INRIA Lille - Nord Europe > http://stefan-marr.de/research/ > > > > > -- Stefan Marr INRIA Lille - Nord Europe http://stefan-marr.de/research/ From tom.deneau at amd.com Thu Sep 18 15:04:55 2014 From: tom.deneau at amd.com (Deneau, Tom) Date: Thu, 18 Sep 2014 15:04:55 +0000 Subject: determining when to offload to the gpu In-Reply-To: References: Message-ID: Ryan -- So I believe you are saying: a) Given a lambda marked parallel to execute across a range, the decision of where to run it does not have to be an all-CPU or all-GPU decision. It may be possible to subdivide the problem and run part of it on the GPU and part on the CPU. This subdividing could be part of the framework. b) There should be an API that allows the expert user to break up the problem and control which parts run on the CPU and GPU. I think solving part a) in the JVM or JDK is an interesting (and difficult) problem for the future but may be beyond the scope of the current Sumatra. I will definitely open an issue on this once we get the Sumatra project in place on bugs.openjdk.java.net. Meanwhile, for now I think we will limit the automatic decision of where to run to all-GPU or all-CPU. I think there is a middle ground of problems that either may or may not gain thru offloading (for example depending on GPU or CPU hardware capabilities) and where the programmer wants to leave that decision up to the framework. I will also enter an issue for Part b). I agree this is something that an expert user might want. -- Tom ------------------------------------------------- -----Original Message----- From: LaMothe, Ryan R [mailto:Ryan.LaMothe at pnnl.gov] Sent: Tuesday, September 09, 2014 7:03 PM To: Deneau, Tom; sumatra-dev at openjdk.java.net; graal-dev at openjdk.java.net Subject: Re: determining when to offload to the gpu Hi Tom, I thought this may be a good point to jump in and make a quick comment on some thoughts. A question: At what level is it better to encapsulate this in the JVM and at what level is this better left to the user/utility functions? For example, in the Aparapi project there is an example project named correlation-matrix that gives a pretty good idea about what it takes to realistically decide in code whether to run a specific matrix computation on CPU or GPU and how to split up the work. This is a very basic example and is only a sample of the real code base from which it was derived, but should help highlight the issue. Instead of the JVM trying to figure out how to decompose the lambda functions optimally and offload to HSA automatically for all possible cases, might it be better to take the following approach: - Implement the base functionality in the JVM for HSA offload and then search the entire JDK for places where offloading may be obvious or easily achieved (i.e. Matrix Math, etc.)? Maybe this even means implementing new base classes for specific packages that are HSA-enabled. - For non-obvious cases, allow the developer to somehow indicate in the lambda that they want the execution to occur via HSA/offload, if possible, and provide some form of annotations or other functionality to give the JVM hints about how they would like it done? Maybe that seems like steps backwards, but thought it was worth mentioning. -Ryan On 9/9/14, 3:02 PM, "Deneau, Tom" wrote: >The following is an issue we need to resolve in Sumatra. We intend to >file this in the openjdk bugs system once we get the Sumatra project >set up as a project there. Meanwhile, comments are welcome. > > >In the current prototype, a config flag enables offload and if a Stream >API parallel().forEach call is encountered which meets the other >criteria for being offloaded, then on its first invocation it is >compiled for the HSA target and executed. The compilation happens >once, the compiled kernel is saved and can be reused on subsequent >invocations of the same lambda. (Note: if for any reason the lambda >cannot be compiled for an HSA target, offload is disabled for this >lambda and the usual CPU parallel path is used). The logic for >deciding whether to offload or not is all in the special >Sumatra-modified JDK classes in java/util/stream. > >The above logic could be improved: > > a) instead of being offloaded on the first invocation, the lambda > should first be executed thru the interpreter so that profiling > information is gathered which could then be useful in the > eventual HSAIL compilation step. > > b) instead of being offloaded unconditionally, it would be good if > the lambda would be offloaded only if the offload is determined > profitable when compared to running parallel on the CPU. We > assume that in general it is not possible to predict the > profitability of GPU offload statically and that measurement > will be necessary. > >So how to meet the above needs? Our current thoughts are that at the >JDK level where we decide to offload a particular parallel lambda >invocation would go thru a number of stages: > > * Interpreted (to gather profiling information) > * Compiled and executed on Parallel CPU and timed > * Compiled and executed on Parallel GPU and timed > >And then at that point make some decision about which way is faster and >use that going forward. > >Do people think making these measurements back at the JDK API level is >the right place? (It seems to fit there since that is where we decide >whether or not to offload) > >Some concerns >------------- >This comparison works well if the work per stream call is similar for >all invocations. However, even the range may not be the same from >invocation to invocation. We should try to compare parCPU and parGPU >runs with the same range. If we can't find runs with the same range, >we could derive a time per workitem measurement and compare those. >However, time per workitem for a small range may be quite different for >time per workitem for a large range so would be difficult to compare. >Even then the work per run may be different (might take different paths >thru the lambda). > >How to detect that we are in the "Compiled" stage for the Parallel CPU >runs? I guess knowing the range of each forEach call we should be able >to estimate this, or just see a reduction in the runtime. > >-- Tom Deneau > > From christian.humer at gmail.com Thu Sep 18 16:09:28 2014 From: christian.humer at gmail.com (Christian Humer) Date: Thu, 18 Sep 2014 18:09:28 +0200 Subject: Recent Truffle DSL changes. In-Reply-To: <66A57E3F-2A78-497A-90F4-7456912E3520@stefan-marr.de> References: <54D3BDC5-2312-4542-946B-AE0866F6D57E@stefan-marr.de> <66A57E3F-2A78-497A-90F4-7456912E3520@stefan-marr.de> Message-ID: Hi Stefan, So, I was wondering whether the brute-force approaches is intended, or > whether there is an easy way around by for instance telling the DSL that > doObject is the next general thing after doBool, doLong, or doDouble > respectively. Unfortunately there is no way to resolve this yet. But I am aware of that problem. We could do this if we declare a hint where to rewrite to next from all compatible specializations. Its on my TODO list.I already talked to Andreas a few weeks ago and we also should not use rewrite by exception for local variables. So we might invent a new pattern for that. Does any of that make sense, or am I missing something? Yes this needs to be done at specialization level. The DSL implementation does this on this level (with my patch). All the inline cache implementation need to do the same. This is why we currently expose the "atomic(Callable)" API. Also nodes should not be respecialized twice as you mentioned. Instead they should be copied. - Christian Humer On Thu, Sep 18, 2014 at 4:28 PM, Stefan Marr wrote: > Hi Christian: > > Trying to figure out what the issue could be, I am wondering what the idea > behind the replaceHelper logic and the difference between adoptHelper(.) > and adoptUnadoptedHelper(.) is. > > Somehow, there seem to be situations in which the resulting tree contains > nodes for which the parent link has not been set. > > I am also wondering, whether the approach of synchronizing on the level of > the rewrite operations itself is reliable enough or whether the > synchronization should happen one level up, i.e., the specialization logic > might need to ensure that each node is only specialized exactly once. > Otherwise, two threads could end up specializing the tree multiple times > for the same node, racing for the replace. The thread that wins the race > for the replace will continue executing a sub tree that is going to be > removed from main tree once the second thread specialized the node. I > assume, this could lead to all kind of strange and undesirable situations. > > Does any of that make sense, or am I missing something? > > Thanks > Stefan > > > On 18 Sep 2014, at 00:05, Christian Humer > wrote: > > > Hi Stefan, > > > > Regarding the thread-safety issues. Yes polymorphic rewrites are not yet > thread-safe. But they were also not thread-safe in the old version. So you > might have been just lucky. > > However it is straight forward to make them thread-safe. You just have > to wrap every replace in DSLShare into a closure and call atomic on the > node that is currently in the AST. > > I've attached a patch. Let me know if that works for you. So I can push > it tomorrow. (Had no time to verify it yet) > > Also be careful with the rewriting of function inline caches so that > replaces are always atomic. Also important is that you are not moving one > used AST node from one place to another. Instead copy it, remove the old > and insert the copy. > > > > > > - Christian Humer > > > > On Wed, Sep 17, 2014 at 8:57 PM, Stefan Marr > wrote: > > Hi Christian: > > > > Now I am running into issues. > > I belief your new rewriting logic in the generated code for polymorphic > nodes is not completely thread safe. > > > > Specifically, I am running into issues that a node is supposed to be > rewritten, but not actually adopted yet. > > > > In case you might have a hunch, let me know. Will try to have a look > later this week. > > > > > > To reproduce, you?ll need the thread-support branch and start a > benchmark with at least 2 threads: > > > > git clone --recursive -b thread-support > https://github.com/SOM-st/TruffleSOM.git > > cd TruffleSOM > > ant > > ./som.sh -cp Smalltalk Examples/Benchmarks/BenchmarkHarness.som Dispatch > 10 0 10 2 > > > > Best regards > > Stefan > > > > > > On 16 Sep 2014, at 23:57, Stefan Marr wrote: > > > > > Hi Christian: > > > > > > On 11 Aug 2014, at 19:59, Christian Humer > wrote: > > > > > >> I just pushed some new features to the DSL for the upcoming Truffle > > >> release. Please note that some of the changes may break existing > Truffle > > >> interpreters. Guest languages that don't use Truffle DSL are not > affected > > >> by this push. > > > > > > I finally found the time to update Graal. > > > Looks good. Didn?t had any major issues. Performance seems to remain > more or less the same. > > > > > > Only got two nits. The first one is that the generated code does have > one simple issue with the code style, which can be solved by initializing > the method body unconditionally (see patch below). > > > The second thing is a simple typo in one of the error messages. > > > > > > Best regards > > > Stefan > > > > > > diff --git > a/graal/com.oracle.truffle.dsl.processor/src/com/oracle/truffle/dsl/processor/generator/NodeCodeGenerator.java > b/graal/com.oracle.truffle.dsl.processor/src/com/oracle/truffle/dsl/processor/generator/NodeCodeGenerator.java > > > index 0a38640..c3bc5eb 100644 > > > --- > a/graal/com.oracle.truffle.dsl.processor/src/com/oracle/truffle/dsl/processor/generator/NodeCodeGenerator.java > > > +++ > b/graal/com.oracle.truffle.dsl.processor/src/com/oracle/truffle/dsl/processor/generator/NodeCodeGenerator.java > > > @@ -906,9 +906,9 @@ public class NodeCodeGenerator extends > AbstractCompilationUnitFactory > > > CodeExecutableElement method = new > CodeExecutableElement(modifiers(PUBLIC), context.getType(void.class), > "updateTypes0"); > > > method.getParameters().add(new > CodeVariableElement(classArray, "types")); > > > > > > - if (getModel().isPolymorphic()) { > > > - CodeTreeBuilder builder = method.createBuilder(); > > > + CodeTreeBuilder builder = method.createBuilder(); > > > > > > + if (getModel().isPolymorphic()) { > > > int index = 0; > > > for (NodeExecutionData execution : > getModel().getNode().getChildExecutions()) { > > > String fieldName = polymorphicTypeName(execution); > > > diff --git > a/graal/com.oracle.truffle.dsl.processor/src/com/oracle/truffle/dsl/processor/parser/NodeParser.java > b/graal/com.oracle.truffle.dsl.processor/src/com/oracle/truffle/dsl/processor/parser/NodeParser.java > > > index 202815e..516dc18 100644 > > > --- > a/graal/com.oracle.truffle.dsl.processor/src/com/oracle/truffle/dsl/processor/parser/NodeParser.java > > > +++ > b/graal/com.oracle.truffle.dsl.processor/src/com/oracle/truffle/dsl/processor/parser/NodeParser.java > > > @@ -650,7 +650,7 @@ public class NodeParser extends > AbstractParser { > > > SpecializationData next = i + 1 < specializations.size() ? > specializations.get(i + 1) : null; > > > > > > if (!cur.isContainedBy(next)) { > > > - next.addError("This specialiation is not a valid > exceptional rewrite target for %s. To fix this make %s compatible to %s or > remove the exceptional rewrite.", > > > + next.addError("This specialization is not a valid > exceptional rewrite target for %s. To fix this make %s compatible to %s or > remove the exceptional rewrite.", > > > cur.createReferenceName(), next != > null ? next.createReferenceName() : "-", cur.createReferenceName()); > > > continue; > > > } > > > -- > > > 1.9.1 > > > > > > > > > > > > > > > -- > > > Stefan Marr > > > INRIA Lille - Nord Europe > > > http://stefan-marr.de/research/ > > > > > > > > > > > > > -- > > Stefan Marr > > INRIA Lille - Nord Europe > > http://stefan-marr.de/research/ > > > > > > > > > > > > -- > Stefan Marr > INRIA Lille - Nord Europe > http://stefan-marr.de/research/ > > > > From java at stefan-marr.de Thu Sep 18 17:00:40 2014 From: java at stefan-marr.de (Stefan Marr) Date: Thu, 18 Sep 2014 19:00:40 +0200 Subject: Recent Truffle DSL changes. In-Reply-To: References: <54D3BDC5-2312-4542-946B-AE0866F6D57E@stefan-marr.de> <66A57E3F-2A78-497A-90F4-7456912E3520@stefan-marr.de> Message-ID: <847832FA-2522-4A37-B3FC-75F0FC742739@stefan-marr.de> Hi Christian: On 18 Sep 2014, at 18:09, Christian Humer wrote: > Unfortunately there is no way to resolve this yet. But I am aware of that problem. We could do this if we declare a hint where to rewrite to next from all compatible specializations. Its on my TODO list.I already talked to Andreas a few weeks ago and we also should not use rewrite by exception for local variables. So we might invent a new pattern for that. Ok, I?ll keep it on my todo list as well. > Yes this needs to be done at specialization level. The DSL implementation does this on this level (with my patch). All the inline cache implementation need to do the same. This is why we currently expose the "atomic(Callable)" API. Also nodes should not be respecialized twice as you mentioned. Instead they should be copied. Will probably not get to making TruffleSOM thread-safe this week. But, I was wondering how the API could help me to know that I am doing something in a way I shouldn?t do it. How about adding a ReentrantLock object to the root node, removing the implicit lock acquisition from replace(), and instead putting an assertion on isHeldByCurrentThread() in there? I realize that it might be slightly inconvenient. But, it would make it explicit to the language implementer that one has to look out for those things. As a compromise, a replaceLocked(.) could be introduced. Generally, I would also prefer if the method names would tell me something about the concurrency properties. Another thing I was wondering about is whether some of those concepts in DSLShare could be promoted for general use. It kind of represents good standard practices, right? And even if one needs to step outside the DSL, I presume the general structuring and concepts would still help to implement custom things. I was thinking about the notion of ?uninitialized? and the find and rewrite helper methods, for instance. Best regards Stefan -- Stefan Marr INRIA Lille - Nord Europe http://stefan-marr.de/research/ From doug.simon at oracle.com Fri Sep 19 01:00:07 2014 From: doug.simon at oracle.com (doug.simon at oracle.com) Date: Fri, 19 Sep 2014 01:00:07 +0000 Subject: hg: graal/graal: 11 new changesets Message-ID: <201409190100.s8J107c1024011@aojmv0008> Changeset: 41368fb9ec1f Author: Stefan Anzinger Date: 2014-09-17 17:01 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/41368fb9ec1f [SPARC] Remove Substitutiontests from blacklist ! test/blacklist_sparc.txt Changeset: 44a96c7413a7 Author: Stefan Anzinger Date: 2014-09-17 17:05 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/44a96c7413a7 [SPARC] Gearing up with CBcond instruction ! graal/com.oracle.graal.asm.sparc/src/com/oracle/graal/asm/sparc/SPARCAssembler.java ! graal/com.oracle.graal.asm.sparc/src/com/oracle/graal/asm/sparc/SPARCMacroAssembler.java ! graal/com.oracle.graal.hotspot.sparc/src/com/oracle/graal/hotspot/sparc/SPARCHotSpotBackendFactory.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/HotSpotVMConfig.java ! graal/com.oracle.graal.lir.sparc/src/com/oracle/graal/lir/sparc/SPARCArrayEqualsOp.java ! graal/com.oracle.graal.sparc/src/com/oracle/graal/sparc/SPARC.java ! src/cpu/sparc/vm/vmStructs_sparc.hpp Changeset: d75276c49399 Author: Stefan Anzinger Date: 2014-09-17 17:06 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/d75276c49399 [SPARC] Add a index register, when offset is too large ! graal/com.oracle.graal.compiler.sparc/src/com/oracle/graal/compiler/sparc/SPARCLIRGenerator.java Changeset: 2e4bd9de8682 Author: Stefan Anzinger Date: 2014-09-17 17:06 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/2e4bd9de8682 Merge Changeset: 7a3f6543d383 Author: Doug Simon Date: 2014-09-18 12:22 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/7a3f6543d383 added timer for NodeClass initializer (-Dgraal.debug.timer.NodeClassCreation=true) ! graal/com.oracle.graal.graph/src/com/oracle/graal/graph/NodeClass.java Changeset: 3837c6aa9fd0 Author: Doug Simon Date: 2014-09-18 12:28 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/3837c6aa9fd0 ensure NodeClass initialization follows class hierarchy order ! graal/com.oracle.graal.graph/src/com/oracle/graal/graph/NodeClass.java Changeset: 0a35e2789735 Author: Andreas Woess Date: 2014-09-17 20:57 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/0a35e2789735 Truffle: remove unnecessary DefaultTruffleRuntime fields ! graal/com.oracle.truffle.api/src/com/oracle/truffle/api/impl/DefaultCallTarget.java ! graal/com.oracle.truffle.api/src/com/oracle/truffle/api/impl/DefaultDirectCallNode.java ! graal/com.oracle.truffle.api/src/com/oracle/truffle/api/impl/DefaultTruffleRuntime.java Changeset: 80d021f12b22 Author: Andreas Woess Date: 2014-09-18 18:56 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/80d021f12b22 fix typo in graalRuntime.cpp ! src/share/vm/graal/graalRuntime.cpp Changeset: e165f4223650 Author: Andreas Woess Date: 2014-09-18 19:00 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/e165f4223650 bring MethodData::_trap_hist_limit back in sync with Deoptimization::Reason_LIMIT ! src/share/vm/oops/methodData.hpp Changeset: d48738c27e7d Author: Andreas Woess Date: 2014-09-18 19:02 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/d48738c27e7d Truffle: restore "opt fail" message on compilation failure ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/OptimizedCallTarget.java Changeset: 646ddd52d79a Author: Doug Simon Date: 2014-09-18 23:19 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/646ddd52d79a only generate extra debug info if on HotSpot *and* compiling for HotSpot execution ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/CompilationTask.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotSuitesProvider.java ! graal/com.oracle.graal.truffle.hotspot/src/com/oracle/graal/truffle/hotspot/HotSpotTruffleRuntime.java From jani.vainola at gmail.com Fri Sep 19 08:22:21 2014 From: jani.vainola at gmail.com (=?UTF-8?B?SmFuaSBWw6RpbsO2bMOk?=) Date: Fri, 19 Sep 2014 10:22:21 +0200 Subject: determining when to offload to the gpu In-Reply-To: References: Message-ID: Hi (I am new here so please bare with me. I just couldn't stay silent) About part b), as a java developer I would love if there was some kind of expert API that gives me control of this feature. I would like to able to control where my code is executed (if it is possible). For instance, say that I would write a custom collection class, I want to be able to write a member function that does a few operations on the data in a data-parallell manner and a therefore always (if possible) run those parts of it on the GPU. That is, I want to make the decisions inside my collection but hide it from the users. In my opinion, they should only call my collection and not have any clue on where or how the execution is done. I guess I could slice up the code into a few private functions that use the parallel functionality on the data and use those in the public function but it would be very neat to have a good API for this instead. Regards Jani 2014-09-18 17:04 GMT+02:00 Deneau, Tom : > Ryan -- > > So I believe you are saying: > > a) Given a lambda marked parallel to execute across a range, the > decision of where to run it does not have to be an all-CPU or > all-GPU decision. It may be possible to subdivide the problem > and run part of it on the GPU and part on the CPU. This > subdividing could be part of the framework. > > b) There should be an API that allows the expert user to break up > the problem and control which parts run on the CPU and GPU. > > > I think solving part a) in the JVM or JDK is an interesting (and > difficult) problem for the future but may be beyond the scope of the > current Sumatra. I will definitely open an issue on this once we get > the Sumatra project in place on bugs.openjdk.java.net. > > Meanwhile, for now I think we will limit the automatic decision of > where to run to all-GPU or all-CPU. I think there is a middle ground > of problems that either may or may not gain thru offloading (for > example depending on GPU or CPU hardware capabilities) and where the > programmer wants to leave that decision up to the framework. > > I will also enter an issue for Part b). I agree this is something > that an expert user might want. > > -- Tom > > ------------------------------------------------- > -----Original Message----- > From: LaMothe, Ryan R [mailto:Ryan.LaMothe at pnnl.gov] > Sent: Tuesday, September 09, 2014 7:03 PM > To: Deneau, Tom; sumatra-dev at openjdk.java.net; graal-dev at openjdk.java.net > Subject: Re: determining when to offload to the gpu > > Hi Tom, > > I thought this may be a good point to jump in and make a quick comment on > some thoughts. > > A question: At what level is it better to encapsulate this in the JVM and > at what level is this better left to the user/utility functions? > > > For example, in the Aparapi project there is an example project named > correlation-matrix that gives a pretty good idea about what it takes to > realistically decide in code whether to run a specific matrix computation > on CPU or GPU and how to split up the work. This is a very basic example > and is only a sample of the real code base from which it was derived, but > should help highlight the issue. > > Instead of the JVM trying to figure out how to decompose the lambda > functions optimally and offload to HSA automatically for all possible > cases, might it be better to take the following approach: > > - Implement the base functionality in the JVM for HSA offload and then > search the entire JDK for places where offloading may be obvious or easily > achieved (i.e. Matrix Math, etc.)? Maybe this even means implementing new > base classes for specific packages that are HSA-enabled. > > - For non-obvious cases, allow the developer to somehow indicate in the > lambda that they want the execution to occur via HSA/offload, if possible, > and provide some form of annotations or other functionality to give the JVM > hints about how they would like it done? > > > Maybe that seems like steps backwards, but thought it was worth mentioning. > > > -Ryan > > > On 9/9/14, 3:02 PM, "Deneau, Tom" wrote: > > >The following is an issue we need to resolve in Sumatra. We intend to > >file this in the openjdk bugs system once we get the Sumatra project > >set up as a project there. Meanwhile, comments are welcome. > > > > > >In the current prototype, a config flag enables offload and if a Stream > >API parallel().forEach call is encountered which meets the other > >criteria for being offloaded, then on its first invocation it is > >compiled for the HSA target and executed. The compilation happens > >once, the compiled kernel is saved and can be reused on subsequent > >invocations of the same lambda. (Note: if for any reason the lambda > >cannot be compiled for an HSA target, offload is disabled for this > >lambda and the usual CPU parallel path is used). The logic for > >deciding whether to offload or not is all in the special > >Sumatra-modified JDK classes in java/util/stream. > > > >The above logic could be improved: > > > > a) instead of being offloaded on the first invocation, the lambda > > should first be executed thru the interpreter so that profiling > > information is gathered which could then be useful in the > > eventual HSAIL compilation step. > > > > b) instead of being offloaded unconditionally, it would be good if > > the lambda would be offloaded only if the offload is determined > > profitable when compared to running parallel on the CPU. We > > assume that in general it is not possible to predict the > > profitability of GPU offload statically and that measurement > > will be necessary. > > > >So how to meet the above needs? Our current thoughts are that at the > >JDK level where we decide to offload a particular parallel lambda > >invocation would go thru a number of stages: > > > > * Interpreted (to gather profiling information) > > * Compiled and executed on Parallel CPU and timed > > * Compiled and executed on Parallel GPU and timed > > > >And then at that point make some decision about which way is faster and > >use that going forward. > > > >Do people think making these measurements back at the JDK API level is > >the right place? (It seems to fit there since that is where we decide > >whether or not to offload) > > > >Some concerns > >------------- > >This comparison works well if the work per stream call is similar for > >all invocations. However, even the range may not be the same from > >invocation to invocation. We should try to compare parCPU and parGPU > >runs with the same range. If we can't find runs with the same range, > >we could derive a time per workitem measurement and compare those. > >However, time per workitem for a small range may be quite different for > >time per workitem for a large range so would be difficult to compare. > >Even then the work per run may be different (might take different paths > >thru the lambda). > > > >How to detect that we are in the "Compiled" stage for the Parallel CPU > >runs? I guess knowing the range of each forEach call we should be able > >to estimate this, or just see a reduction in the runtime. > > > >-- Tom Deneau > > > > > > From doug.simon at oracle.com Sat Sep 20 01:00:06 2014 From: doug.simon at oracle.com (doug.simon at oracle.com) Date: Sat, 20 Sep 2014 01:00:06 +0000 Subject: hg: graal/graal: 16 new changesets Message-ID: <201409200100.s8K1075O007783@aojmv0008> Changeset: 7716c6993546 Author: Gilles Duboscq Date: 2014-09-18 17:41 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/7716c6993546 Stamp: interface types can not be trusted except after explicit runtime checks ! graal/com.oracle.graal.api.meta/src/com/oracle/graal/api/meta/ResolvedJavaType.java ! graal/com.oracle.graal.compiler.common/src/com/oracle/graal/compiler/common/type/StampFactory.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 ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/java/CheckCastNode.java ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/ConditionalEliminationPhase.java ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/cfs/CheckCastReduction.java ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/inlining/InliningUtil.java ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/nodes/LoadIndexedFinalNode.java ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/nodes/typesystem/UnsafeTypeCastMacroNode.java Changeset: a8eb7473d58a Author: Gilles Duboscq Date: 2014-09-19 09:59 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/a8eb7473d58a Add test for interface types + graal/com.oracle.graal.jtt/src/com/oracle/graal/jtt/except/UntrustedInterfaces.java ! mx/projects Changeset: ac6e25901d62 Author: Gilles Duboscq Date: 2014-09-18 17:42 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/ac6e25901d62 Add trusted interface concept and use it for WordBase, fix a NPE and some tests ! graal/com.oracle.graal.api.meta.test/src/com/oracle/graal/api/meta/test/TestResolvedJavaType.java ! graal/com.oracle.graal.api.meta/src/com/oracle/graal/api/meta/ResolvedJavaType.java + graal/com.oracle.graal.api.meta/src/com/oracle/graal/api/meta/TrustedInterface.java ! graal/com.oracle.graal.compiler.common/src/com/oracle/graal/compiler/common/type/StampFactory.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotResolvedObjectType.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotResolvedPrimitiveType.java + graal/com.oracle.graal.nodes.test/src/com/oracle/graal/nodes/test/AbstractObjectStampTest.java ! graal/com.oracle.graal.nodes.test/src/com/oracle/graal/nodes/test/ObjectStampJoinTest.java ! graal/com.oracle.graal.nodes.test/src/com/oracle/graal/nodes/test/ObjectStampMeetTest.java ! graal/com.oracle.graal.nodes.test/src/com/oracle/graal/nodes/test/ObjectStampTest.java ! graal/com.oracle.graal.word/src/com/oracle/graal/word/WordBase.java Changeset: 44a408dcd4a4 Author: Gilles Duboscq Date: 2014-09-18 17:43 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/44a408dcd4a4 Simplify consecutive SimpleInfopointNodes ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/SimpleInfopointNode.java Changeset: ae749a34de49 Author: Lukas Stadler Date: 2014-09-19 11:51 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/ae749a34de49 use "NEW_" instead of "OLD_" for new properties in IGV ! src/share/tools/IdealGraphVisualizer/Difference/src/com/sun/hotspot/igv/difference/Difference.java Changeset: ef5212ce8091 Author: Doug Simon Date: 2014-09-19 13:48 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/ef5212ce8091 support for new projects file format including support for automatically updating from old format ! mxtool/mx.py Changeset: adaecbc405cb Author: Doug Simon Date: 2014-09-19 13:49 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/adaecbc405cb projects file converted to new format + mx/projects.py Changeset: 499804c831fc Author: Lukas Stadler Date: 2014-09-19 14:24 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/499804c831fc use compilation thread even for synchronous Truffle compilations ! graal/com.oracle.graal.truffle.hotspot/src/com/oracle/graal/truffle/hotspot/HotSpotTruffleRuntime.java Changeset: 4a955509b98a Author: Bernhard Urban Date: 2014-09-19 14:29 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/4a955509b98a sparc: fix client vm build ! src/cpu/sparc/vm/c1_globals_sparc.hpp Changeset: 30dda118ef3d Author: Doug Simon Date: 2014-09-19 17:46 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/30dda118ef3d mx: added support for extending distributions; require list literals for list attributes in projects.py ! mx/projects.py ! mxtool/mx.py Changeset: 5ecd1f298c64 Author: Stefan Anzinger Date: 2014-09-18 16:57 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/5ecd1f298c64 [SPARC] Fix few issues (sign extension) on CBcond instructions, and one typo ! graal/com.oracle.graal.asm.sparc/src/com/oracle/graal/asm/sparc/SPARCAssembler.java Changeset: 5247c895a6ab Author: Stefan Anzinger Date: 2014-09-19 09:18 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/5247c895a6ab [SPARC] Use Fzero(d|s) for clearing a fp register ! graal/com.oracle.graal.asm.sparc/src/com/oracle/graal/asm/sparc/SPARCAssembler.java ! graal/com.oracle.graal.lir.sparc/src/com/oracle/graal/lir/sparc/SPARCMove.java ! src/share/vm/graal/graalRuntime.cpp Changeset: 9df38e5fbed6 Author: Stefan Anzinger Date: 2014-09-19 09:24 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/9df38e5fbed6 Limit the maximum Graal thread amount to 32 if nothing else is specified (On SPARC with 256 threads we exceed code cache size) ! src/share/vm/compiler/compileBroker.cpp Changeset: b8f54c5ec73a Author: Stefan Anzinger Date: 2014-09-19 09:27 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/b8f54c5ec73a Merge ! src/share/vm/graal/graalRuntime.cpp Changeset: 65c75f0bfc7b Author: Stefan Anzinger Date: 2014-09-19 09:53 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/65c75f0bfc7b Merge Changeset: a8c0553cb2e4 Author: Doug Simon Date: 2014-09-19 22:52 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/a8c0553cb2e4 restore support for expanding environment variables in suite declarations ! mxtool/mx.py From doug.simon at oracle.com Mon Sep 22 11:27:02 2014 From: doug.simon at oracle.com (doug.simon at oracle.com) Date: Mon, 22 Sep 2014 11:27:02 +0000 Subject: hg: graal/graal: use supplied canonicalizer in TruffleCacheImpl Message-ID: <201409221127.s8MBR2v4029523@aojmv0008> Changeset: fe5d4383b505 Author: Lukas Stadler Date: 2014-09-22 12:17 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/fe5d4383b505 use supplied canonicalizer in TruffleCacheImpl ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/TruffleCacheImpl.java ! graal/com.oracle.truffle.api/src/com/oracle/truffle/api/nodes/NodeCost.java From doug.simon at oracle.com Tue Sep 23 01:00:07 2014 From: doug.simon at oracle.com (doug.simon at oracle.com) Date: Tue, 23 Sep 2014 01:00:07 +0000 Subject: hg: graal/graal: 9 new changesets Message-ID: <201409230100.s8N10EOl024376@aojmv0008> Changeset: a5535a5e9197 Author: Doug Simon Date: 2014-09-22 09:21 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/a5535a5e9197 deprecated mx/projects file (by renaming to projects.deprecated) - mx/projects + mx/projects.deprecated Changeset: 099028aa4d8b Author: Doug Simon Date: 2014-09-22 09:22 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/099028aa4d8b fixed MatchPattern.toString() for USE_GENERATED_NODES ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/match/MatchPattern.java Changeset: 6c299422ba23 Author: Doug Simon Date: 2014-09-22 14:25 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/6c299422ba23 added support for substring matching when specifying unconditional timers and meters (e.g., -Dgraal.debug.timer.NodeClass*) ! graal/com.oracle.graal.debug/src/com/oracle/graal/debug/Debug.java Changeset: 2cb007e99ed0 Author: Doug Simon Date: 2014-09-22 14:26 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/2cb007e99ed0 added support for getting the flat time from a DebugTimer + graal/com.oracle.graal.debug.test/src/com/oracle/graal/debug/test/DebugTimerTest.java ! graal/com.oracle.graal.debug/src/com/oracle/graal/debug/DebugTimer.java ! graal/com.oracle.graal.debug/src/com/oracle/graal/debug/internal/TimerImpl.java Changeset: 63870b298b39 Author: Doug Simon Date: 2014-09-22 14:31 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/63870b298b39 added timers for NodeClass creation ! graal/com.oracle.graal.graph/src/com/oracle/graal/graph/NodeClass.java Changeset: 371cf2a6500a Author: Doug Simon Date: 2014-09-22 14:31 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/371cf2a6500a Merge. Changeset: 805a26002dc7 Author: Stefan Anzinger Date: 2014-09-22 09:21 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/805a26002dc7 [SPARC] Implement stuffing of delay slots in branches and calls. Optimized the cmove for integer and fp ops ! graal/com.oracle.graal.asm.sparc/src/com/oracle/graal/asm/sparc/SPARCAssembler.java ! graal/com.oracle.graal.asm.sparc/src/com/oracle/graal/asm/sparc/SPARCMacroAssembler.java ! graal/com.oracle.graal.compiler.sparc/src/com/oracle/graal/compiler/sparc/SPARCLIRGenerator.java ! graal/com.oracle.graal.compiler.sparc/src/com/oracle/graal/compiler/sparc/SPARCNodeLIRBuilder.java ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/gen/NodeLIRBuilder.java ! graal/com.oracle.graal.hotspot.sparc/src/com/oracle/graal/hotspot/sparc/SPARCHotSpotBackend.java ! graal/com.oracle.graal.hotspot.sparc/src/com/oracle/graal/hotspot/sparc/SPARCHotSpotCRuntimeCallEpilogueOp.java ! graal/com.oracle.graal.hotspot.sparc/src/com/oracle/graal/hotspot/sparc/SPARCHotSpotCRuntimeCallPrologueOp.java ! graal/com.oracle.graal.hotspot.sparc/src/com/oracle/graal/hotspot/sparc/SPARCHotspotDirectStaticCallOp.java ! graal/com.oracle.graal.hotspot.sparc/src/com/oracle/graal/hotspot/sparc/SPARCHotspotDirectVirtualCallOp.java + graal/com.oracle.graal.lir.sparc/src/com/oracle/graal/lir/sparc/DelaySlotHolder.java ! graal/com.oracle.graal.lir.sparc/src/com/oracle/graal/lir/sparc/SPARCArithmetic.java ! graal/com.oracle.graal.lir.sparc/src/com/oracle/graal/lir/sparc/SPARCByteSwapOp.java ! graal/com.oracle.graal.lir.sparc/src/com/oracle/graal/lir/sparc/SPARCCall.java ! graal/com.oracle.graal.lir.sparc/src/com/oracle/graal/lir/sparc/SPARCCompare.java ! graal/com.oracle.graal.lir.sparc/src/com/oracle/graal/lir/sparc/SPARCControlFlow.java + graal/com.oracle.graal.lir.sparc/src/com/oracle/graal/lir/sparc/SPARCJumpOp.java ! graal/com.oracle.graal.lir.sparc/src/com/oracle/graal/lir/sparc/SPARCMathIntrinsicOp.java ! graal/com.oracle.graal.lir.sparc/src/com/oracle/graal/lir/sparc/SPARCMove.java ! graal/com.oracle.graal.lir.sparc/src/com/oracle/graal/lir/sparc/SPARCSaveRegistersOp.java + graal/com.oracle.graal.lir.sparc/src/com/oracle/graal/lir/sparc/TailDelayedLIRInstruction.java Changeset: bef7eac46e1e Author: Stefan Anzinger Date: 2014-09-22 09:29 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/bef7eac46e1e Merge - mx/projects Changeset: 6d8ae4c6725f Author: Stefan Anzinger Date: 2014-09-22 11:20 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/6d8ae4c6725f [SPARC] UseCompressedOops defaulting to false on SPARC && GRAAL ! src/share/vm/runtime/arguments.cpp From doug.simon at oracle.com Tue Sep 23 12:10:13 2014 From: doug.simon at oracle.com (doug.simon at oracle.com) Date: Tue, 23 Sep 2014 12:10:13 +0000 Subject: hg: graal/graal: 2 new changesets Message-ID: <201409231210.s8NCADfP008312@aojmv0008> Changeset: ae5b66255083 Author: Bernhard Urban Date: 2014-09-23 10:55 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/ae5b66255083 changelog: graal-0.5 ! CHANGELOG.md Changeset: dddb5e4e51a4 Author: Bernhard Urban Date: 2014-09-23 10:55 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/dddb5e4e51a4 Added tag graal-0.5 for changeset ae5b66255083 ! .hgtags From doug.simon at oracle.com Wed Sep 24 01:00:07 2014 From: doug.simon at oracle.com (doug.simon at oracle.com) Date: Wed, 24 Sep 2014 01:00:07 +0000 Subject: hg: graal/graal: 7 new changesets Message-ID: <201409240100.s8O10CXT023893@aojmv0008> Changeset: d6c7c530ca84 Author: Doug Simon Date: 2014-09-23 12:52 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/d6c7c530ca84 mx: change name of suite specification file from projects.py to suite.py - mx/projects.py + mx/suite.py ! mxtool/mx.py Changeset: 4046e014f29f Author: Doug Simon Date: 2014-09-23 12:53 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/4046e014f29f mx: removed convertprojects ! mxtool/mx.py Changeset: 1cc8b62b4d37 Author: Doug Simon Date: 2014-09-23 13:09 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/1cc8b62b4d37 mx: added 'suites' command ! mxtool/mx.py Changeset: 7169e42f7e1b Author: Doug Simon Date: 2014-09-23 13:10 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/7169e42f7e1b updated CHANGELOG.md ! CHANGELOG.md ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/match/MatchableNode.java Changeset: ca13853abf0d Author: Doug Simon Date: 2014-09-23 13:18 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/ca13853abf0d mx: fix pylint issues ! mxtool/mx.py Changeset: bd760d193008 Author: Doug Simon Date: 2014-09-23 13:19 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/bd760d193008 updated CHANGELOG.md ! CHANGELOG.md ! 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.nodeinfo.processor/src/com/oracle/graal/nodeinfo/processor/GraphNodeGenerator.java Changeset: 55a924683e72 Author: Doug Simon Date: 2014-09-23 13:40 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/55a924683e72 removed generated inputs/successors iterators and Position related methods ! graal/com.oracle.graal.graph/src/com/oracle/graal/graph/Node.java - graal/com.oracle.graal.graph/src/com/oracle/graal/graph/NodeAllRefsIterator.java ! graal/com.oracle.graal.graph/src/com/oracle/graal/graph/NodeClass.java ! graal/com.oracle.graal.graph/src/com/oracle/graal/graph/NodeClassIterable.java - graal/com.oracle.graal.graph/src/com/oracle/graal/graph/NodeRefIterable.java - graal/com.oracle.graal.graph/src/com/oracle/graal/graph/NodeRefIterator.java - graal/com.oracle.graal.graph/src/com/oracle/graal/graph/NodeRefWithModCountIterator.java ! graal/com.oracle.graal.graph/src/com/oracle/graal/graph/Position.java ! graal/com.oracle.graal.nodeinfo.processor/src/com/oracle/graal/nodeinfo/processor/GraphNodeGenerator.java From doug.simon at oracle.com Thu Sep 25 01:00:09 2014 From: doug.simon at oracle.com (doug.simon at oracle.com) Date: Thu, 25 Sep 2014 01:00:09 +0000 Subject: hg: graal/graal: 21 new changesets Message-ID: <201409250100.s8P10AXA025012@aojmv0008> Changeset: a4b8c73ebb7d Author: Christian Wimmer Date: 2014-09-23 19:20 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/a4b8c73ebb7d Copy graph properties when copying a graph ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/StructuredGraph.java Changeset: 9ff6aee72c8b Author: Christian Wimmer Date: 2014-09-23 19:22 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/9ff6aee72c8b Change class hierarchy of ValueProxy that should only be transparent during graph building ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/ValueProxyNode.java + graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/spi/LimitedValueProxy.java - graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/spi/ValueAndStampProxy.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/spi/ValueProxy.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/util/GraphUtil.java ! graal/com.oracle.graal.phases/src/com/oracle/graal/phases/graph/InferStamps.java Changeset: be733832464d Author: Christian Wimmer Date: 2014-09-23 19:22 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/be733832464d Allow subclasses to intercept Truffle call boundaries ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/OptimizedCallTarget.java Changeset: d0d76deeacb9 Author: Christian Wimmer Date: 2014-09-23 19:23 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/d0d76deeacb9 Make more Truffle code HotSpot independent, and allow more customization by subclasses - graal/com.oracle.graal.truffle.hotspot/src/com/oracle/graal/truffle/hotspot/HotSpotFrameInstance.java ! graal/com.oracle.graal.truffle.hotspot/src/com/oracle/graal/truffle/hotspot/HotSpotTruffleRuntime.java - graal/com.oracle.graal.truffle.hotspot/src/com/oracle/graal/truffle/hotspot/ReadOnlyFrame.java + graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/GraalFrameInstance.java ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/GraalTruffleRuntime.java ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/OptimizedCallTargetLog.java ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/OptimizedCallUtils.java + graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/ReadOnlyFrame.java ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/TruffleCacheImpl.java Changeset: 9a980af18ec5 Author: Doug Simon Date: 2014-09-24 09:50 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/9a980af18ec5 cherry-pick: JDK-8033898: undefined symbol when build hotspot with Xcode5 ! make/bsd/makefiles/gcc.make Changeset: e92cf6db7a07 Author: Josef Eisl Date: 2014-09-24 11:34 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/e92cf6db7a07 Handle deleted instructions in CFGPrinter. ! graal/com.oracle.graal.printer/src/com/oracle/graal/printer/CFGPrinter.java Changeset: 41a75081678c Author: Josef Eisl Date: 2014-09-24 11:18 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/41a75081678c Print LIR after move elimination. ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/alloc/LinearScan.java Changeset: 189479d72dc8 Author: Roland Schatz Date: 2014-09-19 11:00 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/189479d72dc8 Move bit manipulation methods to CodeUtil class. ! graal/com.oracle.graal.api.code/src/com/oracle/graal/api/code/CodeUtil.java ! graal/com.oracle.graal.compiler.amd64/src/com/oracle/graal/compiler/amd64/AMD64LIRGenerator.java ! graal/com.oracle.graal.compiler.common/src/com/oracle/graal/compiler/common/type/IntegerStamp.java ! graal/com.oracle.graal.compiler.common/src/com/oracle/graal/compiler/common/type/StampFactory.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.loop/src/com/oracle/graal/loop/CountedLoopInfo.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/ConstantNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/calc/AndNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/calc/IntegerConvertNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/calc/NarrowNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/calc/OrNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/calc/SignExtendNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/calc/XorNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/calc/ZeroExtendNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/type/StampTool.java ! graal/com.oracle.graal.replacements/src/com/oracle/graal/replacements/nodes/BitCountNode.java ! graal/com.oracle.graal.replacements/src/com/oracle/graal/replacements/nodes/BitScanForwardNode.java ! graal/com.oracle.graal.replacements/src/com/oracle/graal/replacements/nodes/BitScanReverseNode.java ! graal/com.oracle.graal.replacements/src/com/oracle/graal/replacements/nodes/ReverseBytesNode.java Changeset: ec35bb4eccb8 Author: Roland Schatz Date: 2014-09-24 13:46 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/ec35bb4eccb8 Add support for other data types to integer arithmetic nodes. ! graal/com.oracle.graal.api.meta/src/com/oracle/graal/api/meta/Constant.java ! graal/com.oracle.graal.compiler.amd64/src/com/oracle/graal/compiler/amd64/AMD64NodeLIRBuilder.java + graal/com.oracle.graal.compiler.common/src/com/oracle/graal/compiler/common/type/ArithmeticOpTable.java + graal/com.oracle.graal.compiler.common/src/com/oracle/graal/compiler/common/type/ArithmeticStamp.java ! graal/com.oracle.graal.compiler.common/src/com/oracle/graal/compiler/common/type/FloatStamp.java ! graal/com.oracle.graal.compiler.common/src/com/oracle/graal/compiler/common/type/IntegerStamp.java ! graal/com.oracle.graal.compiler.common/src/com/oracle/graal/compiler/common/type/PrimitiveStamp.java ! graal/com.oracle.graal.compiler.common/src/com/oracle/graal/compiler/common/type/Stamp.java ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/gen/NodeLIRBuilder.java ! graal/com.oracle.graal.hotspot.amd64/src/com/oracle/graal/hotspot/amd64/AMD64HotSpotNodeLIRBuilder.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/debug/BenchmarkCounters.java ! graal/com.oracle.graal.java/src/com/oracle/graal/java/GraphBuilderPhase.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/InductionVariables.java ! graal/com.oracle.graal.loop/src/com/oracle/graal/loop/LoopEx.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/LoopBeginNode.java + graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/calc/AddNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/calc/AndNode.java + graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/calc/BinaryArithmeticNode.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/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/IntegerDivNode.java - graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/calc/IntegerMulNode.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/MulNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/calc/NegateNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/calc/OrNode.java + graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/calc/SubNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/calc/XorNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/extended/AddLocationNode.java ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/ProfileCompiledMethodsPhase.java ! graal/com.oracle.graal.replacements/src/com/oracle/graal/replacements/DefaultJavaLoweringProvider.java ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/nodes/arithmetic/IntegerAddExactNode.java ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/nodes/arithmetic/IntegerMulExactNode.java ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/nodes/arithmetic/IntegerMulHighNode.java ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/nodes/arithmetic/IntegerSubExactNode.java ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/nodes/arithmetic/UnsignedMulHighNode.java ! graal/com.oracle.graal.word/src/com/oracle/graal/word/Word.java Changeset: 75177b3cc5a8 Author: Roland Schatz Date: 2014-09-24 14:22 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/75177b3cc5a8 Remove unused methods from StampTool. ! 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/IntegerDivNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/calc/IntegerRemNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/extended/AddLocationNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/extended/IndexedLocationNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/type/StampTool.java ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/nodes/arithmetic/IntegerAddExactNode.java ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/nodes/arithmetic/IntegerSubExactNode.java Changeset: 88012c1750a0 Author: Roland Schatz Date: 2014-09-24 14:29 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/88012c1750a0 Move bit logic nodes into the arithmetic node hierarchies. ! graal/com.oracle.graal.compiler.common/src/com/oracle/graal/compiler/common/type/ArithmeticOpTable.java ! graal/com.oracle.graal.compiler.common/src/com/oracle/graal/compiler/common/type/IntegerStamp.java ! graal/com.oracle.graal.loop/src/com/oracle/graal/loop/LoopEx.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/AndNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/calc/BinaryArithmeticNode.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/NegateNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/calc/NotNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/calc/OrNode.java + graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/calc/UnaryArithmeticNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/calc/XorNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/type/StampTool.java ! graal/com.oracle.graal.replacements/src/com/oracle/graal/replacements/nodes/ReverseBytesNode.java Changeset: 56458afc02a3 Author: Roland Schatz Date: 2014-09-24 14:57 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/56458afc02a3 Use common nodes for integer and floating point arithmetic. ! graal/com.oracle.graal.compiler.amd64/src/com/oracle/graal/compiler/amd64/AMD64NodeLIRBuilder.java ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/gen/NodeLIRBuilder.java ! graal/com.oracle.graal.hotspot.amd64/src/com/oracle/graal/hotspot/amd64/AMD64HotSpotNodeLIRBuilder.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/DefaultHotSpotLoweringProvider.java ! graal/com.oracle.graal.java/src/com/oracle/graal/java/GraphBuilderPhase.java ! graal/com.oracle.graal.loop/src/com/oracle/graal/loop/InductionVariables.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/LoopBeginNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/calc/AddNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/calc/BinaryArithmeticNode.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/DivNode.java - graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/calc/FloatAddNode.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/FloatDivNode.java - graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/calc/FloatMulNode.java - graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/calc/FloatRemNode.java - graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/calc/FloatSubNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/calc/MulNode.java + graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/calc/RemNode.java ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/ProfileCompiledMethodsPhase.java Changeset: 3f176485d807 Author: Roland Schatz Date: 2014-09-24 15:28 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/3f176485d807 Test cornercase in floating point subtraction. ! graal/com.oracle.graal.jtt/src/com/oracle/graal/jtt/bytecode/BC_dsub2.java Changeset: dfe30d721f3f Author: Lukas Stadler Date: 2014-09-24 18:39 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/dfe30d721f3f simplify WriteNode.generate ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/extended/WriteNode.java Changeset: b15a7b70523f Author: Lukas Stadler Date: 2014-09-24 18:40 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/b15a7b70523f remove unused ignoreSlowPath parameter in TruffleCache ! 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/TruffleCacheImpl.java Changeset: fcf71ef8a0e5 Author: Lukas Stadler Date: 2014-09-24 18:42 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/fcf71ef8a0e5 visibility change in NewObjectSnippets ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/NewObjectSnippets.java Changeset: 873f082901c8 Author: Bernhard Urban Date: 2014-09-24 22:05 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/873f082901c8 unittest: fix NPE if inlining is disabled ! graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/GraalCompilerTest.java Changeset: 2d401b9ca70d Author: Stefan Anzinger Date: 2014-09-23 12:12 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/2d401b9ca70d [SPARC] Improve the lookup for delayable candidates, renaming interfaces/methods ! graal/com.oracle.graal.hotspot.sparc/src/com/oracle/graal/hotspot/sparc/SPARCHotSpotBackend.java ! graal/com.oracle.graal.hotspot.sparc/src/com/oracle/graal/hotspot/sparc/SPARCHotSpotCRuntimeCallEpilogueOp.java ! graal/com.oracle.graal.hotspot.sparc/src/com/oracle/graal/hotspot/sparc/SPARCHotSpotCRuntimeCallPrologueOp.java ! graal/com.oracle.graal.hotspot.sparc/src/com/oracle/graal/hotspot/sparc/SPARCHotSpotEnterUnpackFramesStackFrameOp.java ! graal/com.oracle.graal.hotspot.sparc/src/com/oracle/graal/hotspot/sparc/SPARCHotSpotLeaveCurrentStackFrameOp.java ! graal/com.oracle.graal.hotspot.sparc/src/com/oracle/graal/hotspot/sparc/SPARCHotSpotLeaveDeoptimizedStackFrameOp.java ! graal/com.oracle.graal.hotspot.sparc/src/com/oracle/graal/hotspot/sparc/SPARCHotSpotPushInterpreterFrameOp.java - graal/com.oracle.graal.lir.sparc/src/com/oracle/graal/lir/sparc/DelaySlotHolder.java ! graal/com.oracle.graal.lir.sparc/src/com/oracle/graal/lir/sparc/SPARCArithmetic.java ! graal/com.oracle.graal.lir.sparc/src/com/oracle/graal/lir/sparc/SPARCByteSwapOp.java ! graal/com.oracle.graal.lir.sparc/src/com/oracle/graal/lir/sparc/SPARCCall.java ! graal/com.oracle.graal.lir.sparc/src/com/oracle/graal/lir/sparc/SPARCControlFlow.java + graal/com.oracle.graal.lir.sparc/src/com/oracle/graal/lir/sparc/SPARCDelayedControlTransfer.java ! graal/com.oracle.graal.lir.sparc/src/com/oracle/graal/lir/sparc/SPARCJumpOp.java ! graal/com.oracle.graal.lir.sparc/src/com/oracle/graal/lir/sparc/SPARCLIRInstruction.java ! graal/com.oracle.graal.lir.sparc/src/com/oracle/graal/lir/sparc/SPARCMathIntrinsicOp.java ! graal/com.oracle.graal.lir.sparc/src/com/oracle/graal/lir/sparc/SPARCMove.java ! graal/com.oracle.graal.lir.sparc/src/com/oracle/graal/lir/sparc/SPARCSaveRegistersOp.java + graal/com.oracle.graal.lir.sparc/src/com/oracle/graal/lir/sparc/SPARCTailDelayedLIRInstruction.java - graal/com.oracle.graal.lir.sparc/src/com/oracle/graal/lir/sparc/TailDelayedLIRInstruction.java Changeset: 5a7b82c1514e Author: Stefan Anzinger Date: 2014-09-24 16:13 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/5a7b82c1514e [SPARC] Add functionality to be able to do assembly in two passes (knowing offsets of forward branches) ! graal/com.oracle.graal.api.code/src/com/oracle/graal/api/code/CompilationResult.java ! graal/com.oracle.graal.asm.sparc/src/com/oracle/graal/asm/sparc/SPARCAssembler.java ! graal/com.oracle.graal.asm/src/com/oracle/graal/asm/Assembler.java ! graal/com.oracle.graal.asm/src/com/oracle/graal/asm/Buffer.java ! graal/com.oracle.graal.asm/src/com/oracle/graal/asm/Label.java ! graal/com.oracle.graal.hotspot.sparc/src/com/oracle/graal/hotspot/sparc/SPARCHotSpotBackend.java ! graal/com.oracle.graal.lir.sparc/src/com/oracle/graal/lir/sparc/SPARCCall.java ! graal/com.oracle.graal.lir.sparc/src/com/oracle/graal/lir/sparc/SPARCControlFlow.java ! graal/com.oracle.graal.lir.sparc/src/com/oracle/graal/lir/sparc/SPARCDelayedControlTransfer.java ! graal/com.oracle.graal.lir.sparc/src/com/oracle/graal/lir/sparc/SPARCJumpOp.java ! graal/com.oracle.graal.lir/src/com/oracle/graal/lir/LIR.java ! graal/com.oracle.graal.lir/src/com/oracle/graal/lir/asm/CompilationResultBuilder.java Changeset: d8f4c1e6b538 Author: Stefan Anzinger Date: 2014-09-24 16:22 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/d8f4c1e6b538 Merge - graal/com.oracle.graal.graph/src/com/oracle/graal/graph/NodeAllRefsIterator.java - graal/com.oracle.graal.graph/src/com/oracle/graal/graph/NodeRefIterable.java - graal/com.oracle.graal.graph/src/com/oracle/graal/graph/NodeRefIterator.java - graal/com.oracle.graal.graph/src/com/oracle/graal/graph/NodeRefWithModCountIterator.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/FloatAddNode.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/FloatDivNode.java - graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/calc/FloatMulNode.java - graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/calc/FloatRemNode.java - graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/calc/FloatSubNode.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/IntegerMulNode.java - graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/calc/IntegerSubNode.java - graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/spi/ValueAndStampProxy.java - graal/com.oracle.graal.truffle.hotspot/src/com/oracle/graal/truffle/hotspot/HotSpotFrameInstance.java - graal/com.oracle.graal.truffle.hotspot/src/com/oracle/graal/truffle/hotspot/ReadOnlyFrame.java - mx/projects.py Changeset: 1b6172cb270e Author: Stefan Anzinger Date: 2014-09-24 17:17 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/1b6172cb270e [SPARC] eclipseformat ! graal/com.oracle.graal.lir.sparc/src/com/oracle/graal/lir/sparc/SPARCArithmetic.java From doug.simon at oracle.com Fri Sep 26 01:00:06 2014 From: doug.simon at oracle.com (doug.simon at oracle.com) Date: Fri, 26 Sep 2014 01:00:06 +0000 Subject: hg: graal/graal: 3 new changesets Message-ID: <201409260100.s8Q106cl004944@aojmv0008> Changeset: ef64e2682bb6 Author: Doug Simon Date: 2014-09-25 10:27 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/ef64e2682bb6 added Edges class to consolidate code operating on set of input or successor edges and to better isolate magic used to access edges + graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/NodePosIteratorTest.java - graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/NodeRefIteratorTest.java ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/match/MatchRuleRegistry.java + graal/com.oracle.graal.graph/src/com/oracle/graal/graph/Edges.java - graal/com.oracle.graal.graph/src/com/oracle/graal/graph/FirstLevelPositionCollection.java - graal/com.oracle.graal.graph/src/com/oracle/graal/graph/FirstLevelPositionIterator.java ! graal/com.oracle.graal.graph/src/com/oracle/graal/graph/Graph.java + graal/com.oracle.graal.graph/src/com/oracle/graal/graph/InputEdges.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/NodeClassIterable.java ! graal/com.oracle.graal.graph/src/com/oracle/graal/graph/NodeInputList.java ! graal/com.oracle.graal.graph/src/com/oracle/graal/graph/NodeList.java ! graal/com.oracle.graal.graph/src/com/oracle/graal/graph/NodeSuccessorList.java ! graal/com.oracle.graal.graph/src/com/oracle/graal/graph/Position.java + graal/com.oracle.graal.graph/src/com/oracle/graal/graph/SuccessorEdges.java ! graal/com.oracle.graal.loop/src/com/oracle/graal/loop/LoopTransformations.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/IfNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/calc/IntegerDivNode.java ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/TailDuplicationPhase.java ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/cfs/FlowUtil.java ! graal/com.oracle.graal.printer/src/com/oracle/graal/printer/BinaryGraphPrinter.java ! graal/com.oracle.graal.printer/src/com/oracle/graal/printer/CFGPrinter.java ! graal/com.oracle.graal.printer/src/com/oracle/graal/printer/IdealGraphPrinter.java + graal/com.oracle.graal.replacements/src/com/oracle/graal/replacements/EdgesSubstitutions.java - graal/com.oracle.graal.replacements/src/com/oracle/graal/replacements/NodeClassSubstitutions.java Changeset: 1ac6b4879443 Author: Josef Eisl Date: 2014-09-25 13:28 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/1ac6b4879443 Enforce catch-blocks for Debug.Scopes with context objects. ! graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/GraalCompilerTest.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.hotspot/src/com/oracle/graal/hotspot/nfi/HotSpotNativeFunctionInterface.java ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/inlining/walker/InliningData.java ! graal/com.oracle.graal.truffle.hotspot/src/com/oracle/graal/truffle/hotspot/HotSpotTruffleRuntime.java Changeset: 26d07b31c4a8 Author: Josef Eisl Date: 2014-09-25 14:43 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/26d07b31c4a8 ConstantLoadOptimization: make debug meters final. ! graal/com.oracle.graal.lir/src/com/oracle/graal/lir/constopt/ConstantLoadOptimization.java From java at stefan-marr.de Fri Sep 26 08:11:17 2014 From: java at stefan-marr.de (Stefan Marr) Date: Fri, 26 Sep 2014 10:11:17 +0200 Subject: How to assess impact of specializations on warmup Message-ID: <2CC2DB91-164A-4A96-B179-32292FD4548D@stefan-marr.de> Hi: I was wondering whether you guys have a way of assessing the impact of optimizations and/or specializations on warmup. I was thinking of a simple approach based on the observed peak performance. So, assuming that each benchmark iteration does a constant amount of work (minus optimizations), perhaps taking the index of the first iteration that is within an error margin of the peak performance would be a good proxy for the time it takes to warmup. However, I also see on a number of benchmarks that there are later compilations happening, that do not necessarily contribute to the peak performance. Some benchmarks even have one fast run very early after some compilation. Then however further compilation happens that degrades performance again and it takes a while to reach the peak performance again. So, well, I am not sure whether just taking the first iteration which is close to peak is a good idea. On the other hand, saying peak is reached when it was observed for 20 or so iterations seems also to be a little arbitrary. Is there perhaps literature on the topic? So far I have mostly seen people reporting startup time by measuring a first iteration. However, that isn?t really what I am interested in, since I want to know what the impact of certain specializations is on the warmup behavior. Thanks Stefan -- Stefan Marr INRIA Lille - Nord Europe http://stefan-marr.de/research/ From chris.seaton at oracle.com Fri Sep 26 10:03:51 2014 From: chris.seaton at oracle.com (Chris Seaton) Date: Fri, 26 Sep 2014 11:03:51 +0100 Subject: How to assess impact of specializations on warmup In-Reply-To: <2CC2DB91-164A-4A96-B179-32292FD4548D@stefan-marr.de> References: <2CC2DB91-164A-4A96-B179-32292FD4548D@stefan-marr.de> Message-ID: On 26 Sep 2014, at 09:11, Stefan Marr wrote: > Hi: > > I was wondering whether you guys have a way of assessing the impact of optimizations and/or specializations on warmup. > > I was thinking of a simple approach based on the observed peak performance. > So, assuming that each benchmark iteration does a constant amount of work (minus optimizations), perhaps taking the index of the first iteration that is within an error margin of the peak performance would be a good proxy for the time it takes to warmup. My warmup strategy at the moment is to look in a sliding window for the first n iterations where the relative range is less than some constant k. These first n iterations are where I start sampling, so if the relative range is low immediately we could have ?no warmup?. This seems to work well - in that it does seem to capture all the compilation (both in Graal and LLVM etc). > However, I also see on a number of benchmarks that there are later compilations happening, that do not necessarily contribute to the peak performance. I used to worry about this as well, but really Graal is a dynamic compiler and it can run anytime it wants to. I now don?t look at compilation to check for warmup - I just look at iteration times. As long as I?m not running a parallelism benchmark and my warmup test passes I don?t worry about extra compilation happening in the background on another core. > Some benchmarks even have one fast run very early after some compilation. Then however further compilation happens that degrades performance again and it takes a while to reach the peak performance again. > So, well, I am not sure whether just taking the first iteration which is close to peak is a good idea. > On the other hand, saying peak is reached when it was observed for 20 or so iterations seems also to be a little arbitrary. I have also seen this behaviour with Ruby. I don?t have a good explanation for it at the moment, beyond that as your program warms up you will have a different set of compiled and interpreted methods and the interaction between these as they call each other and use frames from each other will change with different runtime costs. > Is there perhaps literature on the topic? So far I have mostly seen people reporting startup time by measuring a first iteration. However, that isn?t really what I am interested in, since I want to know what the impact of certain specializations is on the warmup behavior. You?ve probably heard me say this before, but as far as I know the only sensible methodical approach to benchmarking is Kalibera and Jones, http://kar.kent.ac.uk/33611/. I won?t pretend to understand all their statistics work, but they recommend that to check warmup you really need to manually look for patterns in lag and autocorrelation plots. I use my sliding-window warmup technique on benchmark servers, but if I?m publishing a paper I draw these plots and check them manually for the runs I?m using in the publication. So basically - if you?re looking for a good simple solution, I don?t think there is one! > Thanks > Stefan > > > > -- > Stefan Marr > INRIA Lille - Nord Europe > http://stefan-marr.de/research/ > > > From christian.humer at gmail.com Fri Sep 26 14:11:16 2014 From: christian.humer at gmail.com (Christian Humer) Date: Fri, 26 Sep 2014 16:11:16 +0200 Subject: @SlowPath renaming discussion Message-ID: Hi Folks, I've heard from a few people (including myself) that the @SlowPath annotation naming might be misleading. That is why I want to raise a discussion on this list, which will hopefully lead to a good permanent decision for a new name. I would suggest these names: @Boundary @TruffleBoundary @PartialEvaluationBoundary (or @PEBoundary) Please add more suggestions and vote for whatever you think is best. --- Here are some additional thoughts regarding the old name: The @SlowPath annotation marks the border for the Truffle partial evaluator. So methods marked with @SlowPath are not partially evaluated and treated as if they would be normal Java methods. Here is an example: @SlowPath String stringConcat(String s1, String s2) { return new StringBuilder(s1).append(s2).toString(); } If there would be no @SlowPath annotation on this method then the partial evaluator would just inline through the constructor and the append method. This will produce too much code and is not desirable. Another issue is that the implementation of append is not under the control of the guest language implementation and might contain e.g. recursions which will make the partial evaluator fail. Virtual objects like VirtualFrame instances must not be passed to @SlowPath annotated methods because they leave the scope of the partial evaluator. Such cases are considered Truffle compilation errors. To summarize: * @SlowPath should be applied on every call to a method that is not under the control of the guest language implementation. * @SlowPath should be applied on guest language methods that are very big and might produce too much code. * Virtual objects must not be passed to @SlowPath annotated methods. These are arguments against using "SlowPath" as name: * Its name does not explain the semantics in any way * @SlowPath might also be used for "fast path" code. * The use of @SlowPath does not imply slow execution. - Christian Humer From michael.haupt at oracle.com Fri Sep 26 14:28:50 2014 From: michael.haupt at oracle.com (Michael Haupt) Date: Fri, 26 Sep 2014 16:28:50 +0200 Subject: @SlowPath renaming discussion In-Reply-To: References: Message-ID: <6A990121-0783-4EC4-8F43-5D0FC4194C66@oracle.com> Hi Christian, Am 26.09.2014 um 16:11 schrieb Christian Humer : I would suggest these names: @Boundary @TruffleBoundary @PartialEvaluationBoundary (or @PEBoundary) Please add more suggestions and vote for whatever you think is best. I'll try to first give my rationale for how I try to come up with a name. It should express the intent of the annotation with regard to the method it is attached to, at a level that is understandable by a Truffle user. Applying this, and note that this is purely my personal view, @Boundary is a bit too fuzzy; @TruffleBoundary is more apt, but regarding a method as a boundary is a bit odd; and @PEBoundary is rather technical (not focused on the user). Alternative suggestions (more may be coming): @TruffleInterpreted, @TruffleInterpretOnly. (Prepending "Truffle" should indicate that the method is not exempt from compilation.) If the technical stance of @PartialEvaluationBoundary is agreeable but the name is too long, how about @NoPE? ;-) Best, Michael -- Dr. Michael Haupt | Principal Member of Technical Staff Phone: +49 331 200 7277 | Fax: +49 331 200 7561 Oracle Labs Oracle Deutschland B.V. & Co. KG, Schiffbauergasse 14 | 14467 Potsdam, Germany Oracle is committed to developing practices and products that help protect the environment From chris.seaton at oracle.com Fri Sep 26 14:49:09 2014 From: chris.seaton at oracle.com (Chris Seaton) Date: Fri, 26 Sep 2014 15:49:09 +0100 Subject: @SlowPath renaming discussion In-Reply-To: <6A990121-0783-4EC4-8F43-5D0FC4194C66@oracle.com> References: <6A990121-0783-4EC4-8F43-5D0FC4194C66@oracle.com> Message-ID: <451C896D-6297-4432-9383-49C2EC803174@oracle.com> What about something less Truffle specific? What about @StopInlining, @NotInlined or @DontInline? On 26 Sep 2014, at 15:28, Michael Haupt wrote: > Hi Christian, > > Am 26.09.2014 um 16:11 schrieb Christian Humer : > I would suggest these names: > @Boundary > @TruffleBoundary > @PartialEvaluationBoundary (or @PEBoundary) > > Please add more suggestions and vote for whatever you think is best. > > I'll try to first give my rationale for how I try to come up with a name. It should express the intent of the annotation with regard to the method it is attached to, at a level that is understandable by a Truffle user. > > Applying this, and note that this is purely my personal view, @Boundary is a bit too fuzzy; @TruffleBoundary is more apt, but regarding a method as a boundary is a bit odd; and @PEBoundary is rather technical (not focused on the user). > > Alternative suggestions (more may be coming): @TruffleInterpreted, @TruffleInterpretOnly. (Prepending "Truffle" should indicate that the method is not exempt from compilation.) > > If the technical stance of @PartialEvaluationBoundary is agreeable but the name is too long, how about @NoPE? ;-) > > Best, > > Michael > > -- > > > Dr. Michael Haupt | Principal Member of Technical Staff > Phone: +49 331 200 7277 | Fax: +49 331 200 7561 > Oracle Labs > Oracle Deutschland B.V. & Co. KG, Schiffbauergasse 14 | 14467 Potsdam, Germany > Oracle is committed to developing practices and products that help protect the environment > From gero.leinemann at oracle.com Fri Sep 26 15:09:06 2014 From: gero.leinemann at oracle.com (Gero Leinemann) Date: Fri, 26 Sep 2014 17:09:06 +0200 Subject: @SlowPath renaming discussion In-Reply-To: <451C896D-6297-4432-9383-49C2EC803174@oracle.com> References: <6A990121-0783-4EC4-8F43-5D0FC4194C66@oracle.com> <451C896D-6297-4432-9383-49C2EC803174@oracle.com> Message-ID: <54258192.2070909@oracle.com> Though I find the simplicity of "@NotInlined" etc. appealing, I'd recommend not to use the word "inline", as this is highly overloaded in the Truffle/Graal context: 1. inlining by AST rewriting (language level) 2. inlining during/for PE (Truffle level) 3. inlining done by the compiler (Graal/compiler level) This confused - at least - me quite a bit when I started working at FastR. What about @StopPE? Best, Gero Am 26.09.2014 um 16:49 schrieb Chris Seaton: > What about something less Truffle specific? What about @StopInlining, @NotInlined or @DontInline? > > On 26 Sep 2014, at 15:28, Michael Haupt wrote: > >> Hi Christian, >> >> Am 26.09.2014 um 16:11 schrieb Christian Humer : >> I would suggest these names: >> @Boundary >> @TruffleBoundary >> @PartialEvaluationBoundary (or @PEBoundary) >> >> Please add more suggestions and vote for whatever you think is best. >> >> I'll try to first give my rationale for how I try to come up with a name. It should express the intent of the annotation with regard to the method it is attached to, at a level that is understandable by a Truffle user. >> >> Applying this, and note that this is purely my personal view, @Boundary is a bit too fuzzy; @TruffleBoundary is more apt, but regarding a method as a boundary is a bit odd; and @PEBoundary is rather technical (not focused on the user). >> >> Alternative suggestions (more may be coming): @TruffleInterpreted, @TruffleInterpretOnly. (Prepending "Truffle" should indicate that the method is not exempt from compilation.) >> >> If the technical stance of @PartialEvaluationBoundary is agreeable but the name is too long, how about @NoPE? ;-) >> >> Best, >> >> Michael >> >> -- >> >> >> Dr. Michael Haupt | Principal Member of Technical Staff >> Phone: +49 331 200 7277 | Fax: +49 331 200 7561 >> Oracle Labs >> Oracle Deutschland B.V. & Co. KG, Schiffbauergasse 14 | 14467 Potsdam, Germany >> Oracle is committed to developing practices and products that help protect the environment >> From laurent.daynes at oracle.com Fri Sep 26 15:10:57 2014 From: laurent.daynes at oracle.com (Laurent Daynes) Date: Fri, 26 Sep 2014 17:10:57 +0200 Subject: @SlowPath renaming discussion In-Reply-To: <451C896D-6297-4432-9383-49C2EC803174@oracle.com> References: <6A990121-0783-4EC4-8F43-5D0FC4194C66@oracle.com> <451C896D-6297-4432-9383-49C2EC803174@oracle.com> Message-ID: <54258201.9080308@oracle.com> @StopPartialEvaluation comes to mind. Laurent On 9/26/2014 4:49 PM, Chris Seaton wrote: > What about something less Truffle specific? What about @StopInlining, @NotInlined or @DontInline? > > On 26 Sep 2014, at 15:28, Michael Haupt wrote: > >> Hi Christian, >> >> Am 26.09.2014 um 16:11 schrieb Christian Humer : >> I would suggest these names: >> @Boundary >> @TruffleBoundary >> @PartialEvaluationBoundary (or @PEBoundary) >> >> Please add more suggestions and vote for whatever you think is best. >> >> I'll try to first give my rationale for how I try to come up with a name. It should express the intent of the annotation with regard to the method it is attached to, at a level that is understandable by a Truffle user. >> >> Applying this, and note that this is purely my personal view, @Boundary is a bit too fuzzy; @TruffleBoundary is more apt, but regarding a method as a boundary is a bit odd; and @PEBoundary is rather technical (not focused on the user). >> >> Alternative suggestions (more may be coming): @TruffleInterpreted, @TruffleInterpretOnly. (Prepending "Truffle" should indicate that the method is not exempt from compilation.) >> >> If the technical stance of @PartialEvaluationBoundary is agreeable but the name is too long, how about @NoPE? ;-) >> >> Best, >> >> Michael >> >> -- >> >> >> Dr. Michael Haupt | Principal Member of Technical Staff >> Phone: +49 331 200 7277 | Fax: +49 331 200 7561 >> Oracle Labs >> Oracle Deutschland B.V. & Co. KG, Schiffbauergasse 14 | 14467 Potsdam, Germany >> Oracle is committed to developing practices and products that help protect the environment >> -- Laurent Daynes Oracle Labs From manuel.rigger at chello.at Fri Sep 26 21:11:34 2014 From: manuel.rigger at chello.at (Manuel Rigger) Date: Fri, 26 Sep 2014 23:11:34 +0200 Subject: @SlowPath renaming discussion In-Reply-To: <451C896D-6297-4432-9383-49C2EC803174@oracle.com> References: <6A990121-0783-4EC4-8F43-5D0FC4194C66@oracle.com> <451C896D-6297-4432-9383-49C2EC803174@oracle.com> Message-ID: <5425D686.2010703@chello.at> Hi, having a method annotated as a "boundary" leaves open where the exact boundary for the PE is. Some user might think that the PE might still evaluate the method but does not continue from there. I think the name should include "Partial Evaluation". I guess that a user will already have some idea about partial evaluation if he/she uses the annotation. To try to come up with a simpler name will probably make the naming more fuzzy. Instead of talking about the abstract concept "Partial Evaluation" we would have to put somehow inside what Truffle _does not do_ but Graal still _could do_, i.e., inlining. I thus have these additional suggestions: @CutoffPartialEvaluator (or simply @CutPartialEvaluation as in the Prolog Cut operator) @PartialEvaluationInvisible - Manuel Am 26.09.2014 16:49, schrieb Chris Seaton: > What about something less Truffle specific? What about @StopInlining, @NotInlined or @DontInline? > > On 26 Sep 2014, at 15:28, Michael Haupt wrote: > >> Hi Christian, >> >> Am 26.09.2014 um 16:11 schrieb Christian Humer : >> I would suggest these names: >> @Boundary >> @TruffleBoundary >> @PartialEvaluationBoundary (or @PEBoundary) >> >> Please add more suggestions and vote for whatever you think is best. >> >> I'll try to first give my rationale for how I try to come up with a name. It should express the intent of the annotation with regard to the method it is attached to, at a level that is understandable by a Truffle user. >> >> Applying this, and note that this is purely my personal view, @Boundary is a bit too fuzzy; @TruffleBoundary is more apt, but regarding a method as a boundary is a bit odd; and @PEBoundary is rather technical (not focused on the user). >> >> Alternative suggestions (more may be coming): @TruffleInterpreted, @TruffleInterpretOnly. (Prepending "Truffle" should indicate that the method is not exempt from compilation.) >> >> If the technical stance of @PartialEvaluationBoundary is agreeable but the name is too long, how about @NoPE? ;-) >> >> Best, >> >> Michael >> >> -- >> >> >> Dr. Michael Haupt | Principal Member of Technical Staff >> Phone: +49 331 200 7277 | Fax: +49 331 200 7561 >> Oracle Labs >> Oracle Deutschland B.V. & Co. KG, Schiffbauergasse 14 | 14467 Potsdam, Germany >> Oracle is committed to developing practices and products that help protect the environment >> > > > ----- > E-Mail ist virenfrei. > Von AVG uberpruft - www.avg.de > Version: 2014.0.4765 / Virendatenbank: 4025/8276 - Ausgabedatum: 26.09.2014 > > > From laurent.daynes at oracle.com Fri Sep 26 15:12:57 2014 From: laurent.daynes at oracle.com (Laurent Daynes) Date: Fri, 26 Sep 2014 17:12:57 +0200 Subject: @SlowPath renaming discussion In-Reply-To: <54258192.2070909@oracle.com> References: <6A990121-0783-4EC4-8F43-5D0FC4194C66@oracle.com> <451C896D-6297-4432-9383-49C2EC803174@oracle.com> <54258192.2070909@oracle.com> Message-ID: <54258279.7070301@oracle.com> I agree with Gero. Don't use the word inlining -- it is way too overloaded. Laurent On 9/26/2014 5:09 PM, Gero Leinemann wrote: > > Though I find the simplicity of "@NotInlined" etc. appealing, I'd > recommend not to use the word "inline", as this is highly overloaded > in the Truffle/Graal context: > 1. inlining by AST rewriting (language level) > 2. inlining during/for PE (Truffle level) > 3. inlining done by the compiler (Graal/compiler level) > This confused - at least - me quite a bit when I started working at > FastR. > > What about @StopPE? > > Best, > Gero > > Am 26.09.2014 um 16:49 schrieb Chris Seaton: >> What about something less Truffle specific? What about @StopInlining, >> @NotInlined or @DontInline? >> >> On 26 Sep 2014, at 15:28, Michael Haupt >> wrote: >> >>> Hi Christian, >>> >>> Am 26.09.2014 um 16:11 schrieb Christian Humer >>> : >>> I would suggest these names: >>> @Boundary >>> @TruffleBoundary >>> @PartialEvaluationBoundary (or @PEBoundary) >>> >>> Please add more suggestions and vote for whatever you think is best. >>> >>> I'll try to first give my rationale for how I try to come up with a >>> name. It should express the intent of the annotation with regard to >>> the method it is attached to, at a level that is understandable by a >>> Truffle user. >>> >>> Applying this, and note that this is purely my personal view, >>> @Boundary is a bit too fuzzy; @TruffleBoundary is more apt, but >>> regarding a method as a boundary is a bit odd; and @PEBoundary is >>> rather technical (not focused on the user). >>> >>> Alternative suggestions (more may be coming): @TruffleInterpreted, >>> @TruffleInterpretOnly. (Prepending "Truffle" should indicate that >>> the method is not exempt from compilation.) >>> >>> If the technical stance of @PartialEvaluationBoundary is agreeable >>> but the name is too long, how about @NoPE? ;-) >>> >>> Best, >>> >>> Michael >>> >>> -- >>> >>> >>> Dr. Michael Haupt | Principal Member of Technical Staff >>> Phone: +49 331 200 7277 | Fax: +49 331 200 7561 >>> Oracle Labs >>> Oracle Deutschland B.V. & Co. KG, Schiffbauergasse 14 | 14467 >>> Potsdam, Germany >>> Oracle is committed to developing practices and products that >>> help protect the environment >>> > -- Laurent Daynes Oracle Labs From christian.humer at gmail.com Fri Sep 26 15:24:04 2014 From: christian.humer at gmail.com (Christian Humer) Date: Fri, 26 Sep 2014 17:24:04 +0200 Subject: @SlowPath renaming discussion In-Reply-To: <54258192.2070909@oracle.com> References: <6A990121-0783-4EC4-8F43-5D0FC4194C66@oracle.com> <451C896D-6297-4432-9383-49C2EC803174@oracle.com> <54258192.2070909@oracle.com> Message-ID: I also agree not to use inline. I usually use "guest language inlining" for 1), "expansion" for 2) and "host language inlining" for 3). Will keep the suggestions flowing and will wrap up a vote later on. - Christian Humer On Fri, Sep 26, 2014 at 5:09 PM, Gero Leinemann wrote: > > Though I find the simplicity of "@NotInlined" etc. appealing, I'd > recommend not to use the word "inline", as this is highly overloaded in the > Truffle/Graal context: > 1. inlining by AST rewriting (language level) > 2. inlining during/for PE (Truffle level) > 3. inlining done by the compiler (Graal/compiler level) > This confused - at least - me quite a bit when I started working at FastR. > > What about @StopPE? > > Best, > Gero > > Am 26.09.2014 um 16:49 schrieb Chris Seaton: > > What about something less Truffle specific? What about @StopInlining, >> @NotInlined or @DontInline? >> >> On 26 Sep 2014, at 15:28, Michael Haupt wrote: >> >> Hi Christian, >>> >>> Am 26.09.2014 um 16:11 schrieb Christian Humer < >>> christian.humer at gmail.com>: >>> I would suggest these names: >>> @Boundary >>> @TruffleBoundary >>> @PartialEvaluationBoundary (or @PEBoundary) >>> >>> Please add more suggestions and vote for whatever you think is best. >>> >>> I'll try to first give my rationale for how I try to come up with a >>> name. It should express the intent of the annotation with regard to the >>> method it is attached to, at a level that is understandable by a Truffle >>> user. >>> >>> Applying this, and note that this is purely my personal view, @Boundary >>> is a bit too fuzzy; @TruffleBoundary is more apt, but regarding a method as >>> a boundary is a bit odd; and @PEBoundary is rather technical (not focused >>> on the user). >>> >>> Alternative suggestions (more may be coming): @TruffleInterpreted, >>> @TruffleInterpretOnly. (Prepending "Truffle" should indicate that the >>> method is not exempt from compilation.) >>> >>> If the technical stance of @PartialEvaluationBoundary is agreeable but >>> the name is too long, how about @NoPE? ;-) >>> >>> Best, >>> >>> Michael >>> >>> -- >>> >>> >>> Dr. Michael Haupt | Principal Member of Technical Staff >>> Phone: +49 331 200 7277 | Fax: +49 331 200 7561 >>> Oracle Labs >>> Oracle Deutschland B.V. & Co. KG, Schiffbauergasse 14 | 14467 Potsdam, >>> Germany >>> Oracle is committed to developing practices and products that >>> help protect the environment >>> >>> > From chris.seaton at oracle.com Fri Sep 26 15:28:16 2014 From: chris.seaton at oracle.com (Chris Seaton) Date: Fri, 26 Sep 2014 16:28:16 +0100 Subject: @SlowPath renaming discussion In-Reply-To: References: <6A990121-0783-4EC4-8F43-5D0FC4194C66@oracle.com> <451C896D-6297-4432-9383-49C2EC803174@oracle.com> <54258192.2070909@oracle.com> Message-ID: Ah - well how about @NotExpanded then? On 26 Sep 2014, at 16:24, Christian Humer wrote: > I also agree not to use inline. I usually use "guest language inlining" for > 1), "expansion" for 2) and "host language inlining" for 3). > > Will keep the suggestions flowing and will wrap up a vote later on. > > > > - Christian Humer > > On Fri, Sep 26, 2014 at 5:09 PM, Gero Leinemann > wrote: > >> >> Though I find the simplicity of "@NotInlined" etc. appealing, I'd >> recommend not to use the word "inline", as this is highly overloaded in the >> Truffle/Graal context: >> 1. inlining by AST rewriting (language level) >> 2. inlining during/for PE (Truffle level) >> 3. inlining done by the compiler (Graal/compiler level) >> This confused - at least - me quite a bit when I started working at FastR. >> >> What about @StopPE? >> >> Best, >> Gero >> >> Am 26.09.2014 um 16:49 schrieb Chris Seaton: >> >> What about something less Truffle specific? What about @StopInlining, >>> @NotInlined or @DontInline? >>> >>> On 26 Sep 2014, at 15:28, Michael Haupt wrote: >>> >>> Hi Christian, >>>> >>>> Am 26.09.2014 um 16:11 schrieb Christian Humer < >>>> christian.humer at gmail.com>: >>>> I would suggest these names: >>>> @Boundary >>>> @TruffleBoundary >>>> @PartialEvaluationBoundary (or @PEBoundary) >>>> >>>> Please add more suggestions and vote for whatever you think is best. >>>> >>>> I'll try to first give my rationale for how I try to come up with a >>>> name. It should express the intent of the annotation with regard to the >>>> method it is attached to, at a level that is understandable by a Truffle >>>> user. >>>> >>>> Applying this, and note that this is purely my personal view, @Boundary >>>> is a bit too fuzzy; @TruffleBoundary is more apt, but regarding a method as >>>> a boundary is a bit odd; and @PEBoundary is rather technical (not focused >>>> on the user). >>>> >>>> Alternative suggestions (more may be coming): @TruffleInterpreted, >>>> @TruffleInterpretOnly. (Prepending "Truffle" should indicate that the >>>> method is not exempt from compilation.) >>>> >>>> If the technical stance of @PartialEvaluationBoundary is agreeable but >>>> the name is too long, how about @NoPE? ;-) >>>> >>>> Best, >>>> >>>> Michael >>>> >>>> -- >>>> >>>> >>>> Dr. Michael Haupt | Principal Member of Technical Staff >>>> Phone: +49 331 200 7277 | Fax: +49 331 200 7561 >>>> Oracle Labs >>>> Oracle Deutschland B.V. & Co. KG, Schiffbauergasse 14 | 14467 Potsdam, >>>> Germany >>>> Oracle is committed to developing practices and products that >>>> help protect the environment >>>> >>>> >> From bernhard.urban at jku.at Fri Sep 26 16:01:10 2014 From: bernhard.urban at jku.at (Bernhard Urban) Date: Fri, 26 Sep 2014 18:01:10 +0200 Subject: @SlowPath renaming discussion In-Reply-To: References: <6A990121-0783-4EC4-8F43-5D0FC4194C66@oracle.com> <451C896D-6297-4432-9383-49C2EC803174@oracle.com> <54258192.2070909@oracle.com> Message-ID: @ExitPartialEvaluator / @ExitPE fwiw, in pypy there's a @jit.dont_look_inside annotation. -Bernhard On Sep 26, 2014 5:30 PM, "Christian Humer" wrote: > I also agree not to use inline. I usually use "guest language inlining" for > 1), "expansion" for 2) and "host language inlining" for 3). > > Will keep the suggestions flowing and will wrap up a vote later on. > > > > - Christian Humer > > On Fri, Sep 26, 2014 at 5:09 PM, Gero Leinemann > > wrote: > > > > > Though I find the simplicity of "@NotInlined" etc. appealing, I'd > > recommend not to use the word "inline", as this is highly overloaded in > the > > Truffle/Graal context: > > 1. inlining by AST rewriting (language level) > > 2. inlining during/for PE (Truffle level) > > 3. inlining done by the compiler (Graal/compiler level) > > This confused - at least - me quite a bit when I started working at > FastR. > > > > What about @StopPE? > > > > Best, > > Gero > > > > Am 26.09.2014 um 16:49 schrieb Chris Seaton: > > > > What about something less Truffle specific? What about @StopInlining, > >> @NotInlined or @DontInline? > >> > >> On 26 Sep 2014, at 15:28, Michael Haupt > wrote: > >> > >> Hi Christian, > >>> > >>> Am 26.09.2014 um 16:11 schrieb Christian Humer < > >>> christian.humer at gmail.com>: > >>> I would suggest these names: > >>> @Boundary > >>> @TruffleBoundary > >>> @PartialEvaluationBoundary (or @PEBoundary) > >>> > >>> Please add more suggestions and vote for whatever you think is best. > >>> > >>> I'll try to first give my rationale for how I try to come up with a > >>> name. It should express the intent of the annotation with regard to the > >>> method it is attached to, at a level that is understandable by a > Truffle > >>> user. > >>> > >>> Applying this, and note that this is purely my personal view, @Boundary > >>> is a bit too fuzzy; @TruffleBoundary is more apt, but regarding a > method as > >>> a boundary is a bit odd; and @PEBoundary is rather technical (not > focused > >>> on the user). > >>> > >>> Alternative suggestions (more may be coming): @TruffleInterpreted, > >>> @TruffleInterpretOnly. (Prepending "Truffle" should indicate that the > >>> method is not exempt from compilation.) > >>> > >>> If the technical stance of @PartialEvaluationBoundary is agreeable but > >>> the name is too long, how about @NoPE? ;-) > >>> > >>> Best, > >>> > >>> Michael > >>> > >>> -- > >>> > >>> > >>> Dr. Michael Haupt | Principal Member of Technical Staff > >>> Phone: +49 331 200 7277 | Fax: +49 331 200 7561 > >>> Oracle Labs > >>> Oracle Deutschland B.V. & Co. KG, Schiffbauergasse 14 | 14467 Potsdam, > >>> Germany > >>> Oracle is committed to developing practices and products that > >>> help protect the environment > >>> > >>> > > > > From mario.wolczko at oracle.com Fri Sep 26 16:25:33 2014 From: mario.wolczko at oracle.com (Mario Wolczko) Date: Fri, 26 Sep 2014 09:25:33 -0700 Subject: @SlowPath renaming discussion In-Reply-To: References: <6A990121-0783-4EC4-8F43-5D0FC4194C66@oracle.com> <451C896D-6297-4432-9383-49C2EC803174@oracle.com> <54258192.2070909@oracle.com> Message-ID: <882426FF-A4CB-4A2D-AEF0-0CA375776FDD@oracle.com> Why not attempt to develop better inlining heuristics and do away with the annotation altogether? I find it hard to believe this is not possible (although in some cases a judicious annotation may save a lot of computation). > On Sep 26, 2014, at 8:28 AM, Chris Seaton wrote: > > Ah - well how about @NotExpanded then? > >> On 26 Sep 2014, at 16:24, Christian Humer wrote: >> >> I also agree not to use inline. I usually use "guest language inlining" for >> 1), "expansion" for 2) and "host language inlining" for 3). >> >> Will keep the suggestions flowing and will wrap up a vote later on. >> >> >> >> - Christian Humer >> >> On Fri, Sep 26, 2014 at 5:09 PM, Gero Leinemann >> wrote: >> >>> >>> Though I find the simplicity of "@NotInlined" etc. appealing, I'd >>> recommend not to use the word "inline", as this is highly overloaded in the >>> Truffle/Graal context: >>> 1. inlining by AST rewriting (language level) >>> 2. inlining during/for PE (Truffle level) >>> 3. inlining done by the compiler (Graal/compiler level) >>> This confused - at least - me quite a bit when I started working at FastR. >>> >>> What about @StopPE? >>> >>> Best, >>> Gero >>> >>> Am 26.09.2014 um 16:49 schrieb Chris Seaton: >>> >>> What about something less Truffle specific? What about @StopInlining, >>>> @NotInlined or @DontInline? >>>> >>>> On 26 Sep 2014, at 15:28, Michael Haupt wrote: >>>> >>>> Hi Christian, >>>>> >>>>> Am 26.09.2014 um 16:11 schrieb Christian Humer < >>>>> christian.humer at gmail.com>: >>>>> I would suggest these names: >>>>> @Boundary >>>>> @TruffleBoundary >>>>> @PartialEvaluationBoundary (or @PEBoundary) >>>>> >>>>> Please add more suggestions and vote for whatever you think is best. >>>>> >>>>> I'll try to first give my rationale for how I try to come up with a >>>>> name. It should express the intent of the annotation with regard to the >>>>> method it is attached to, at a level that is understandable by a Truffle >>>>> user. >>>>> >>>>> Applying this, and note that this is purely my personal view, @Boundary >>>>> is a bit too fuzzy; @TruffleBoundary is more apt, but regarding a method as >>>>> a boundary is a bit odd; and @PEBoundary is rather technical (not focused >>>>> on the user). >>>>> >>>>> Alternative suggestions (more may be coming): @TruffleInterpreted, >>>>> @TruffleInterpretOnly. (Prepending "Truffle" should indicate that the >>>>> method is not exempt from compilation.) >>>>> >>>>> If the technical stance of @PartialEvaluationBoundary is agreeable but >>>>> the name is too long, how about @NoPE? ;-) >>>>> >>>>> Best, >>>>> >>>>> Michael >>>>> >>>>> -- >>>>> >>>>> >>>>> Dr. Michael Haupt | Principal Member of Technical Staff >>>>> Phone: +49 331 200 7277 | Fax: +49 331 200 7561 >>>>> Oracle Labs >>>>> Oracle Deutschland B.V. & Co. KG, Schiffbauergasse 14 | 14467 Potsdam, >>>>> Germany >>>>> Oracle is committed to developing practices and products that >>>>> help protect the environment > From christian.humer at gmail.com Fri Sep 26 16:57:17 2014 From: christian.humer at gmail.com (Christian Humer) Date: Fri, 26 Sep 2014 18:57:17 +0200 Subject: @SlowPath renaming discussion In-Reply-To: <882426FF-A4CB-4A2D-AEF0-0CA375776FDD@oracle.com> References: <6A990121-0783-4EC4-8F43-5D0FC4194C66@oracle.com> <451C896D-6297-4432-9383-49C2EC803174@oracle.com> <54258192.2070909@oracle.com> <882426FF-A4CB-4A2D-AEF0-0CA375776FDD@oracle.com> Message-ID: On Fri, Sep 26, 2014 at 6:25 PM, Mario Wolczko wrote: > Why not attempt to develop better inlining heuristics and do away with the > annotation altogether? We tried this already. It turned out to be not working very well. Because it was difficult to understand for the guest language developer how the system behaves. With the "expand everything until Annotation" its simple to understand. - Christian Humer From mario.wolczko at oracle.com Fri Sep 26 16:58:48 2014 From: mario.wolczko at oracle.com (Mario Wolczko) Date: Fri, 26 Sep 2014 09:58:48 -0700 Subject: @SlowPath renaming discussion In-Reply-To: References: <6A990121-0783-4EC4-8F43-5D0FC4194C66@oracle.com> <451C896D-6297-4432-9383-49C2EC803174@oracle.com> <54258192.2070909@oracle.com> <882426FF-A4CB-4A2D-AEF0-0CA375776FDD@oracle.com> Message-ID: <3668D2A2-FDBC-43F1-87AB-952F61BBB9DD@oracle.com> Do you have anything written up about the heuristics you tried, and the results? On Sep 26, 2014, at 9:57 AM, Christian Humer wrote: > > On Fri, Sep 26, 2014 at 6:25 PM, Mario Wolczko wrote: > Why not attempt to develop better inlining heuristics and do away with the annotation altogether? > > We tried this already. It turned out to be not working very well. Because it was difficult to understand for the guest language developer how the system behaves. With the "expand everything until Annotation" its simple to understand. > > > - Christian Humer From christian.humer at gmail.com Fri Sep 26 17:01:42 2014 From: christian.humer at gmail.com (Christian Humer) Date: Fri, 26 Sep 2014 19:01:42 +0200 Subject: @SlowPath renaming discussion In-Reply-To: <3668D2A2-FDBC-43F1-87AB-952F61BBB9DD@oracle.com> References: <6A990121-0783-4EC4-8F43-5D0FC4194C66@oracle.com> <451C896D-6297-4432-9383-49C2EC803174@oracle.com> <54258192.2070909@oracle.com> <882426FF-A4CB-4A2D-AEF0-0CA375776FDD@oracle.com> <3668D2A2-FDBC-43F1-87AB-952F61BBB9DD@oracle.com> Message-ID: On Fri, Sep 26, 2014 at 6:58 PM, Mario Wolczko wrote: > Do you have anything written up about the heuristics you tried, and the > results? Not that I know of. Somebody may correct me. - Christian Humer From mario.wolczko at oracle.com Fri Sep 26 17:23:34 2014 From: mario.wolczko at oracle.com (Mario Wolczko) Date: Fri, 26 Sep 2014 10:23:34 -0700 Subject: @SlowPath renaming discussion In-Reply-To: References: <6A990121-0783-4EC4-8F43-5D0FC4194C66@oracle.com> <451C896D-6297-4432-9383-49C2EC803174@oracle.com> <54258192.2070909@oracle.com> <882426FF-A4CB-4A2D-AEF0-0CA375776FDD@oracle.com> <3668D2A2-FDBC-43F1-87AB-952F61BBB9DD@oracle.com> Message-ID: That's too bad. There's as much to be learned from failure as there is from success. On Sep 26, 2014, at 10:01 AM, Christian Humer wrote: > > On Fri, Sep 26, 2014 at 6:58 PM, Mario Wolczko wrote: > Do you have anything written up about the heuristics you tried, and the results? > > Not that I know of. Somebody may correct me. > > > - Christian Humer From thomas.wuerthinger at oracle.com Fri Sep 26 17:57:50 2014 From: thomas.wuerthinger at oracle.com (Thomas Wuerthinger) Date: Fri, 26 Sep 2014 19:57:50 +0200 Subject: @SlowPath renaming discussion In-Reply-To: References: <6A990121-0783-4EC4-8F43-5D0FC4194C66@oracle.com> <451C896D-6297-4432-9383-49C2EC803174@oracle.com> <54258192.2070909@oracle.com> <882426FF-A4CB-4A2D-AEF0-0CA375776FDD@oracle.com> <3668D2A2-FDBC-43F1-87AB-952F61BBB9DD@oracle.com> Message-ID: This prioritisation of core node partial evaluation and later (optional) Java level inlining makes the achieved performance for guest language operations more predictable. For small guest language methods, the inlining can still extend deeper beyond the @SlowPath, because it is only a ?need not inline? annotation as opposed to a ?must not inline? annotation. Our experiments to avoid @SlowPath were of short duration as at that point in time too many things in the runtime were moving simultaneously. I think it might be possible to develop an algorithm that finds out those points via a static analysis. However, even then the guest language implementor needs to fully understand the algorithm in any case to not get bad performance surprises. A middle ground would be to provide an automatic analysis that verifies obviously missing @SlowPath annotations. Current compiler optimizations such as inlining bring variability to the performance model of the guest language programmer. Without @SlowPath, we would bring additional variability to the performance model of the guest language implementor. - thomas On 26 Sep 2014, at 19:23, Mario Wolczko wrote: > That's too bad. There's as much to be learned from failure as there is from success. > > On Sep 26, 2014, at 10:01 AM, Christian Humer wrote: > >> >> On Fri, Sep 26, 2014 at 6:58 PM, Mario Wolczko wrote: >> Do you have anything written up about the heuristics you tried, and the results? >> >> Not that I know of. Somebody may correct me. >> >> >> - Christian Humer > From mario.wolczko at oracle.com Fri Sep 26 20:49:16 2014 From: mario.wolczko at oracle.com (Mario Wolczko) Date: Fri, 26 Sep 2014 13:49:16 -0700 Subject: @SlowPath renaming discussion In-Reply-To: References: <6A990121-0783-4EC4-8F43-5D0FC4194C66@oracle.com> <451C896D-6297-4432-9383-49C2EC803174@oracle.com> <54258192.2070909@oracle.com> <882426FF-A4CB-4A2D-AEF0-0CA375776FDD@oracle.com> <3668D2A2-FDBC-43F1-87AB-952F61BBB9DD@oracle.com> Message-ID: Makes sense. Let's talk when you're around. I have some ideas, but you may have already tried them, and their usefulness depends on some answers. When are you in the office? On Sep 26, 2014, at 10:57 AM, Thomas Wuerthinger wrote: > This prioritisation of core node partial evaluation and later (optional) Java level inlining makes the achieved performance for guest language operations more predictable. For small guest language methods, the inlining can still extend deeper beyond the @SlowPath, because it is only a ?need not inline? annotation as opposed to a ?must not inline? annotation. > > Our experiments to avoid @SlowPath were of short duration as at that point in time too many things in the runtime were moving simultaneously. I think it might be possible to develop an algorithm that finds out those points via a static analysis. However, even then the guest language implementor needs to fully understand the algorithm in any case to not get bad performance surprises. A middle ground would be to provide an automatic analysis that verifies obviously missing @SlowPath annotations. > > Current compiler optimizations such as inlining bring variability to the performance model of the guest language programmer. Without @SlowPath, we would bring additional variability to the performance model of the guest language implementor. > > - thomas > > > On 26 Sep 2014, at 19:23, Mario Wolczko wrote: > >> That's too bad. There's as much to be learned from failure as there is from success. >> >> On Sep 26, 2014, at 10:01 AM, Christian Humer wrote: >> >>> >>> On Fri, Sep 26, 2014 at 6:58 PM, Mario Wolczko wrote: >>> Do you have anything written up about the heuristics you tried, and the results? >>> >>> Not that I know of. Somebody may correct me. >>> >>> >>> - Christian Humer >> > From doug.simon at oracle.com Sat Sep 27 01:00:07 2014 From: doug.simon at oracle.com (doug.simon at oracle.com) Date: Sat, 27 Sep 2014 01:00:07 +0000 Subject: hg: graal/graal: 30 new changesets Message-ID: <201409270100.s8R107lM003318@aojmv0008> Changeset: 959d3e75534a Author: Stefan Anzinger Date: 2014-09-25 08:57 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/959d3e75534a LabelHints are now collected in ArrayLists instead of HashSet ! graal/com.oracle.graal.asm/src/com/oracle/graal/asm/Assembler.java Changeset: 2390886b4e27 Author: Stefan Anzinger Date: 2014-09-25 09:40 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/2390886b4e27 [SPARC] use sll and sra over sllx and srax when possible ! graal/com.oracle.graal.lir.sparc/src/com/oracle/graal/lir/sparc/SPARCArithmetic.java Changeset: 7a99826863d9 Author: Stefan Anzinger Date: 2014-09-25 09:41 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/7a99826863d9 Eliminate valid bit in LabelHint as the validity can be encoded into the capturedTarget ! graal/com.oracle.graal.asm/src/com/oracle/graal/asm/Assembler.java Changeset: 7d8bb35e67c8 Author: Stefan Anzinger Date: 2014-09-25 09:42 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/7d8bb35e67c8 Merge - graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/NodeRefIteratorTest.java - graal/com.oracle.graal.graph/src/com/oracle/graal/graph/FirstLevelPositionCollection.java - graal/com.oracle.graal.graph/src/com/oracle/graal/graph/FirstLevelPositionIterator.java - graal/com.oracle.graal.replacements/src/com/oracle/graal/replacements/NodeClassSubstitutions.java Changeset: 1738211d4cdb Author: Stefan Anzinger Date: 2014-09-25 18:54 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/1738211d4cdb Multiply use shift-add|subtract operations when easily possible. In DivNode use rightshift ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/calc/DivNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/calc/MulNode.java Changeset: 43a89fe3ff8b Author: Stefan Anzinger Date: 2014-09-25 18:59 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/43a89fe3ff8b [SPARC] Eliminate sign extension when signed load is used ! graal/com.oracle.graal.compiler.sparc/src/com/oracle/graal/compiler/sparc/SPARCNodeLIRBuilder.java Changeset: 44389818b25b Author: Stefan Anzinger Date: 2014-09-25 19:00 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/44389818b25b [SPARC] Enable hinting registers in arithmetics ! graal/com.oracle.graal.lir.sparc/src/com/oracle/graal/lir/sparc/SPARCArithmetic.java Changeset: 5eb5446a474d Author: Stefan Anzinger Date: 2014-09-25 19:29 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/5eb5446a474d [SPARC] add additional argument to pass gate ! graal/com.oracle.graal.compiler.sparc/src/com/oracle/graal/compiler/sparc/SPARCNodeLIRBuilder.java Changeset: 05884c6f6b15 Author: Stefan Anzinger Date: 2014-09-25 19:47 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/05884c6f6b15 Revert ! graal/com.oracle.graal.compiler.sparc/src/com/oracle/graal/compiler/sparc/SPARCNodeLIRBuilder.java Changeset: fa7dc2f64c25 Author: Stefan Anzinger Date: 2014-09-25 20:01 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/fa7dc2f64c25 Allow unused imports in MatchStatementSets (as imports just taken from the originating class) ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/match/MatchProcessor.java Changeset: 5b8f316bdb9e Author: Stefan Anzinger Date: 2014-09-25 20:57 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/5b8f316bdb9e Using suppress warning for SPARCNodeLIRBuilder ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/match/MatchProcessor.java Changeset: a02c295218aa Author: Bernhard Urban Date: 2014-09-26 04:53 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/a02c295218aa mx: add support for cygwin * use `cygpath' to translate paths * pay attention when passing paths from unix world to windows world (e.g., when calling out to `javac') * adapt _runInDebugShell to avoid quoting issues ! mx/mx_graal.py ! mxtool/mx.py Changeset: f4b939d433a4 Author: Doug Simon Date: 2014-09-25 12:02 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/f4b939d433a4 removed unused support for rescanning offsets in FieldIntrospection objects ! graal/com.oracle.graal.compiler.common/src/com/oracle/graal/compiler/common/FieldIntrospection.java ! 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: a552dd335bde Author: Doug Simon Date: 2014-09-26 00:18 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/a552dd335bde generalized support for unsafe access to a subset of the fields of an object + graal/com.oracle.graal.compiler.common/src/com/oracle/graal/compiler/common/Fields.java ! graal/com.oracle.graal.graph/src/com/oracle/graal/graph/Edges.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.nodes/src/com/oracle/graal/nodes/DeferredPiNode.java - graal/com.oracle.graal.replacements/src/com/oracle/graal/replacements/EdgesSubstitutions.java + graal/com.oracle.graal.replacements/src/com/oracle/graal/replacements/FieldsSubstitutions.java ! graal/com.oracle.graal.replacements/src/com/oracle/graal/replacements/GraalMethodSubstitutions.java Changeset: 5d03b4a472c6 Author: Doug Simon Date: 2014-09-26 00:18 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/5d03b4a472c6 Merge. Changeset: c1d10773331f Author: Doug Simon Date: 2014-09-26 09:22 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/c1d10773331f Merge. Changeset: 4cbf3ab4b7d2 Author: Doug Simon Date: 2014-09-26 14:43 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/4cbf3ab4b7d2 added graal-truffle.jar to the classes checked by CheckGraalInvariants ! graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/CheckGraalInvariants.java Changeset: 627b11398fdd Author: Doug Simon Date: 2014-09-26 14:45 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/627b11398fdd check that the value of the MethodSubstitution.isStatic is set properly ! graal/com.oracle.graal.replacements.verifier/src/com/oracle/graal/replacements/verifier/MethodSubstitutionVerifier.java Changeset: 58f1d1335ef4 Author: Doug Simon Date: 2014-09-26 14:53 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/58f1d1335ef4 force inline Fields.getObject(Object, int, Class) so that a constant value bound to its last parameter is connected with the DeferredPiNode used in Fields.getObject(Object, long, Class) ! graal/com.oracle.graal.compiler.common/src/com/oracle/graal/compiler/common/Fields.java ! graal/com.oracle.graal.graph/src/com/oracle/graal/graph/NodeClass.java - graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/DeferredPiNode.java + graal/com.oracle.graal.replacements.test/src/com/oracle/graal/replacements/test/EdgesTest.java ! graal/com.oracle.graal.replacements/src/com/oracle/graal/replacements/FieldsSubstitutions.java + graal/com.oracle.graal.replacements/src/com/oracle/graal/replacements/nodes/DeferredPiNode.java Changeset: be6f5fad74c6 Author: Doug Simon Date: 2014-09-26 14:53 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/be6f5fad74c6 check that all callers of Fields.getObject(Object, int, Class) pass a class literal for the last parameter ! graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/CheckGraalInvariants.java + graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/VerifyFieldsGetNode.java Changeset: 1278680407e7 Author: Doug Simon Date: 2014-09-26 18:10 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/1278680407e7 moved intrinsifications for Edges back into EdgesSubstitutions ! graal/com.oracle.graal.compiler.common/src/com/oracle/graal/compiler/common/Fields.java ! graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/CheckGraalInvariants.java - graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/VerifyFieldsGetNode.java ! graal/com.oracle.graal.graph/src/com/oracle/graal/graph/Edges.java ! graal/com.oracle.graal.replacements.test/src/com/oracle/graal/replacements/test/EdgesTest.java + graal/com.oracle.graal.replacements/src/com/oracle/graal/replacements/EdgesSubstitutions.java - graal/com.oracle.graal.replacements/src/com/oracle/graal/replacements/FieldsSubstitutions.java ! graal/com.oracle.graal.replacements/src/com/oracle/graal/replacements/GraalMethodSubstitutions.java Changeset: fd0f5f9abb79 Author: Doug Simon Date: 2014-09-26 18:11 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/fd0f5f9abb79 Merge. Changeset: fa8210d2ff06 Author: Bernhard Urban Date: 2014-09-26 18:53 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/fa8210d2ff06 fix jdt build on windows/cygwin ! mxtool/mx.py Changeset: 9d728eb7fdec Author: Doug Simon Date: 2014-09-26 23:21 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/9d728eb7fdec mx: fixed regression in checking whether the JDK contains an optional library ! mxtool/mx.py Changeset: c990248e816e Author: Stefan Anzinger Date: 2014-09-26 10:40 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/c990248e816e [SPARC] changed register counts due to hint ! graal/com.oracle.graal.compiler.sparc.test/src/com/oracle/graal/compiler/sparc/test/SPARCAllocatorTest.java Changeset: 45c8f71196ec Author: Stefan Anzinger Date: 2014-09-26 10:41 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/45c8f71196ec Merge ! graal/com.oracle.graal.replacements/src/com/oracle/graal/replacements/EdgesSubstitutions.java Changeset: d1cc47f5b1dd Author: Stefan Anzinger Date: 2014-09-26 15:14 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/d1cc47f5b1dd Merge Changeset: 136ba6d379f2 Author: Tom Rodriguez Date: 2014-09-26 15:59 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/136ba6d379f2 avoid different names for the same arraycopy routine ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotHostForeignCallsProvider.java Changeset: 6fcb6691fe5f Author: Tom Rodriguez Date: 2014-09-26 16:00 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/6fcb6691fe5f Add safepoint checks during code installation ! src/share/vm/graal/graalCodeInstaller.cpp ! src/share/vm/graal/graalCodeInstaller.hpp ! src/share/vm/graal/graalGlobals.hpp Changeset: 15c8e24f027a Author: Tom Rodriguez Date: 2014-09-26 16:01 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/15c8e24f027a Limit imports in generated matchers to only the used packages ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/match/MatchProcessor.java From doug.simon at oracle.com Sun Sep 28 01:00:07 2014 From: doug.simon at oracle.com (doug.simon at oracle.com) Date: Sun, 28 Sep 2014 01:00:07 +0000 Subject: hg: graal/graal: 2 new changesets Message-ID: <201409280100.s8S1081m011376@aojmv0008> Changeset: 5b00a1e62a5e Author: Stefan Anzinger Date: 2014-09-26 18:59 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/5b00a1e62a5e [SPARC] Update expected moves ! graal/com.oracle.graal.compiler.sparc.test/src/com/oracle/graal/compiler/sparc/test/SPARCAllocatorTest.java Changeset: aef31f60e970 Author: Doug Simon Date: 2014-09-27 18:16 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/aef31f60e970 converted all FieldIntrospection subclass to use Fields ! graal/com.oracle.graal.compiler.common/src/com/oracle/graal/compiler/common/FieldIntrospection.java ! graal/com.oracle.graal.compiler.common/src/com/oracle/graal/compiler/common/Fields.java ! graal/com.oracle.graal.graph/src/com/oracle/graal/graph/Edges.java ! graal/com.oracle.graal.graph/src/com/oracle/graal/graph/InputEdges.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/SuccessorEdges.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 ! graal/com.oracle.graal.lir/src/com/oracle/graal/lir/LIRIntrospection.java ! graal/com.oracle.graal.lir/src/com/oracle/graal/lir/ValuePosition.java From lukas.stadler at oracle.com Mon Sep 29 08:30:23 2014 From: lukas.stadler at oracle.com (Lukas Stadler) Date: Mon, 29 Sep 2014 10:30:23 +0200 Subject: @SlowPath renaming discussion In-Reply-To: References: <6A990121-0783-4EC4-8F43-5D0FC4194C66@oracle.com> <451C896D-6297-4432-9383-49C2EC803174@oracle.com> <54258192.2070909@oracle.com> Message-ID: <65392097-D035-45AA-8E97-22158EB4CB79@oracle.com> I?m a big fan of @PEBoundary - because: - it?s concise - it says exactly what it is (entry into this method is a boundary for partial evaluation) - it?s non-threatening (as opposed to stop, cut or exit) - ?inlining? and ?interpreted? are overloaded with too many different meanings, so I think we should avoid these terms - Lukas On 26 Sep 2014, at 18:01, Bernhard Urban wrote: > @ExitPartialEvaluator / @ExitPE > > fwiw, in pypy there's a @jit.dont_look_inside annotation. > > -Bernhard > On Sep 26, 2014 5:30 PM, "Christian Humer" > wrote: > >> I also agree not to use inline. I usually use "guest language inlining" for >> 1), "expansion" for 2) and "host language inlining" for 3). >> >> Will keep the suggestions flowing and will wrap up a vote later on. >> >> >> >> - Christian Humer >> >> On Fri, Sep 26, 2014 at 5:09 PM, Gero Leinemann >> >> wrote: >> >>> >>> Though I find the simplicity of "@NotInlined" etc. appealing, I'd >>> recommend not to use the word "inline", as this is highly overloaded in >> the >>> Truffle/Graal context: >>> 1. inlining by AST rewriting (language level) >>> 2. inlining during/for PE (Truffle level) >>> 3. inlining done by the compiler (Graal/compiler level) >>> This confused - at least - me quite a bit when I started working at >> FastR. >>> >>> What about @StopPE? >>> >>> Best, >>> Gero >>> >>> Am 26.09.2014 um 16:49 schrieb Chris Seaton: >>> >>> What about something less Truffle specific? What about @StopInlining, >>>> @NotInlined or @DontInline? >>>> >>>> On 26 Sep 2014, at 15:28, Michael Haupt >> wrote: >>>> >>>> Hi Christian, >>>>> >>>>> Am 26.09.2014 um 16:11 schrieb Christian Humer < >>>>> christian.humer at gmail.com>: >>>>> I would suggest these names: >>>>> @Boundary >>>>> @TruffleBoundary >>>>> @PartialEvaluationBoundary (or @PEBoundary) >>>>> >>>>> Please add more suggestions and vote for whatever you think is best. >>>>> >>>>> I'll try to first give my rationale for how I try to come up with a >>>>> name. It should express the intent of the annotation with regard to the >>>>> method it is attached to, at a level that is understandable by a >> Truffle >>>>> user. >>>>> >>>>> Applying this, and note that this is purely my personal view, @Boundary >>>>> is a bit too fuzzy; @TruffleBoundary is more apt, but regarding a >> method as >>>>> a boundary is a bit odd; and @PEBoundary is rather technical (not >> focused >>>>> on the user). >>>>> >>>>> Alternative suggestions (more may be coming): @TruffleInterpreted, >>>>> @TruffleInterpretOnly. (Prepending "Truffle" should indicate that the >>>>> method is not exempt from compilation.) >>>>> >>>>> If the technical stance of @PartialEvaluationBoundary is agreeable but >>>>> the name is too long, how about @NoPE? ;-) >>>>> >>>>> Best, >>>>> >>>>> Michael >>>>> >>>>> -- >>>>> >>>>> >>>>> Dr. Michael Haupt | Principal Member of Technical Staff >>>>> Phone: +49 331 200 7277 | Fax: +49 331 200 7561 >>>>> Oracle Labs >>>>> Oracle Deutschland B.V. & Co. KG, Schiffbauergasse 14 | 14467 Potsdam, >>>>> Germany >>>>> Oracle is committed to developing practices and products that >>>>> help protect the environment >>>>> >>>>> >>> >> >> From laurent.daynes at oracle.com Mon Sep 29 08:39:06 2014 From: laurent.daynes at oracle.com (Laurent Daynes) Date: Mon, 29 Sep 2014 10:39:06 +0200 Subject: @SlowPath renaming discussion In-Reply-To: <65392097-D035-45AA-8E97-22158EB4CB79@oracle.com> References: <6A990121-0783-4EC4-8F43-5D0FC4194C66@oracle.com> <451C896D-6297-4432-9383-49C2EC803174@oracle.com> <54258192.2070909@oracle.com> <65392097-D035-45AA-8E97-22158EB4CB79@oracle.com> Message-ID: <54291AAA.6050609@oracle.com> Alright, I'm sold. However, I strongly encourage a more developed comment in the source for the annotation that the current succinct one for SlowPath, which doesn't reflect the subtleties hidden behind it. Laurent On 9/29/2014 10:30 AM, Lukas Stadler wrote: > I?m a big fan of @PEBoundary - because: > - it?s concise > - it says exactly what it is (entry into this method is a boundary for partial evaluation) > - it?s non-threatening (as opposed to stop, cut or exit) > - ?inlining? and ?interpreted? are overloaded with too many different meanings, so I think we should avoid these terms > > - Lukas > > On 26 Sep 2014, at 18:01, Bernhard Urban wrote: > >> @ExitPartialEvaluator / @ExitPE >> >> fwiw, in pypy there's a @jit.dont_look_inside annotation. >> >> -Bernhard >> On Sep 26, 2014 5:30 PM, "Christian Humer" >> wrote: >> >>> I also agree not to use inline. I usually use "guest language inlining" for >>> 1), "expansion" for 2) and "host language inlining" for 3). >>> >>> Will keep the suggestions flowing and will wrap up a vote later on. >>> >>> >>> >>> - Christian Humer >>> >>> On Fri, Sep 26, 2014 at 5:09 PM, Gero Leinemann >> wrote: >>> >>>> Though I find the simplicity of "@NotInlined" etc. appealing, I'd >>>> recommend not to use the word "inline", as this is highly overloaded in >>> the >>>> Truffle/Graal context: >>>> 1. inlining by AST rewriting (language level) >>>> 2. inlining during/for PE (Truffle level) >>>> 3. inlining done by the compiler (Graal/compiler level) >>>> This confused - at least - me quite a bit when I started working at >>> FastR. >>>> What about @StopPE? >>>> >>>> Best, >>>> Gero >>>> >>>> Am 26.09.2014 um 16:49 schrieb Chris Seaton: >>>> >>>> What about something less Truffle specific? What about @StopInlining, >>>>> @NotInlined or @DontInline? >>>>> >>>>> On 26 Sep 2014, at 15:28, Michael Haupt >>> wrote: >>>>> Hi Christian, >>>>>> Am 26.09.2014 um 16:11 schrieb Christian Humer < >>>>>> christian.humer at gmail.com>: >>>>>> I would suggest these names: >>>>>> @Boundary >>>>>> @TruffleBoundary >>>>>> @PartialEvaluationBoundary (or @PEBoundary) >>>>>> >>>>>> Please add more suggestions and vote for whatever you think is best. >>>>>> >>>>>> I'll try to first give my rationale for how I try to come up with a >>>>>> name. It should express the intent of the annotation with regard to the >>>>>> method it is attached to, at a level that is understandable by a >>> Truffle >>>>>> user. >>>>>> >>>>>> Applying this, and note that this is purely my personal view, @Boundary >>>>>> is a bit too fuzzy; @TruffleBoundary is more apt, but regarding a >>> method as >>>>>> a boundary is a bit odd; and @PEBoundary is rather technical (not >>> focused >>>>>> on the user). >>>>>> >>>>>> Alternative suggestions (more may be coming): @TruffleInterpreted, >>>>>> @TruffleInterpretOnly. (Prepending "Truffle" should indicate that the >>>>>> method is not exempt from compilation.) >>>>>> >>>>>> If the technical stance of @PartialEvaluationBoundary is agreeable but >>>>>> the name is too long, how about @NoPE? ;-) >>>>>> >>>>>> Best, >>>>>> >>>>>> Michael >>>>>> >>>>>> -- >>>>>> >>>>>> >>>>>> Dr. Michael Haupt | Principal Member of Technical Staff >>>>>> Phone: +49 331 200 7277 | Fax: +49 331 200 7561 >>>>>> Oracle Labs >>>>>> Oracle Deutschland B.V. & Co. KG, Schiffbauergasse 14 | 14467 Potsdam, >>>>>> Germany >>>>>> Oracle is committed to developing practices and products that >>>>>> help protect the environment >>>>>> >>>>>> >>> -- Laurent Daynes Oracle Labs From michael.haupt at oracle.com Mon Sep 29 09:29:44 2014 From: michael.haupt at oracle.com (Michael Haupt) Date: Mon, 29 Sep 2014 11:29:44 +0200 Subject: @SlowPath renaming discussion In-Reply-To: <54291AAA.6050609@oracle.com> References: <6A990121-0783-4EC4-8F43-5D0FC4194C66@oracle.com> <451C896D-6297-4432-9383-49C2EC803174@oracle.com> <54258192.2070909@oracle.com> <65392097-D035-45AA-8E97-22158EB4CB79@oracle.com> <54291AAA.6050609@oracle.com> Message-ID: <962792BE-B242-4653-89B3-C75CC7135B86@oracle.com> Hi, @PEBoundary is non-threatening and apt, but heavy on jargon. The documentation will have to explain part of the underlying concepts clearly. Best, Michael Am 29.09.2014 um 10:39 schrieb Laurent Daynes : > Alright, I'm sold. > However, I strongly encourage a more developed comment in the source for the annotation that the current succinct one for SlowPath, which > doesn't reflect the subtleties hidden behind it. > > Laurent > On 9/29/2014 10:30 AM, Lukas Stadler wrote: >> I?m a big fan of @PEBoundary - because: >> - it?s concise >> - it says exactly what it is (entry into this method is a boundary for partial evaluation) >> - it?s non-threatening (as opposed to stop, cut or exit) >> - ?inlining? and ?interpreted? are overloaded with too many different meanings, so I think we should avoid these terms >> >> - Lukas >> >> On 26 Sep 2014, at 18:01, Bernhard Urban wrote: >> >>> @ExitPartialEvaluator / @ExitPE >>> >>> fwiw, in pypy there's a @jit.dont_look_inside annotation. >>> >>> -Bernhard >>> On Sep 26, 2014 5:30 PM, "Christian Humer" >>> wrote: >>> >>>> I also agree not to use inline. I usually use "guest language inlining" for >>>> 1), "expansion" for 2) and "host language inlining" for 3). >>>> >>>> Will keep the suggestions flowing and will wrap up a vote later on. >>>> >>>> >>>> >>>> - Christian Humer >>>> >>>> On Fri, Sep 26, 2014 at 5:09 PM, Gero Leinemann >>> wrote: >>>> >>>>> Though I find the simplicity of "@NotInlined" etc. appealing, I'd >>>>> recommend not to use the word "inline", as this is highly overloaded in >>>> the >>>>> Truffle/Graal context: >>>>> 1. inlining by AST rewriting (language level) >>>>> 2. inlining during/for PE (Truffle level) >>>>> 3. inlining done by the compiler (Graal/compiler level) >>>>> This confused - at least - me quite a bit when I started working at >>>> FastR. >>>>> What about @StopPE? >>>>> >>>>> Best, >>>>> Gero >>>>> >>>>> Am 26.09.2014 um 16:49 schrieb Chris Seaton: >>>>> >>>>> What about something less Truffle specific? What about @StopInlining, >>>>>> @NotInlined or @DontInline? >>>>>> >>>>>> On 26 Sep 2014, at 15:28, Michael Haupt >>>> wrote: >>>>>> Hi Christian, >>>>>>> Am 26.09.2014 um 16:11 schrieb Christian Humer < >>>>>>> christian.humer at gmail.com>: >>>>>>> I would suggest these names: >>>>>>> @Boundary >>>>>>> @TruffleBoundary >>>>>>> @PartialEvaluationBoundary (or @PEBoundary) >>>>>>> >>>>>>> Please add more suggestions and vote for whatever you think is best. >>>>>>> >>>>>>> I'll try to first give my rationale for how I try to come up with a >>>>>>> name. It should express the intent of the annotation with regard to the >>>>>>> method it is attached to, at a level that is understandable by a >>>> Truffle >>>>>>> user. >>>>>>> >>>>>>> Applying this, and note that this is purely my personal view, @Boundary >>>>>>> is a bit too fuzzy; @TruffleBoundary is more apt, but regarding a >>>> method as >>>>>>> a boundary is a bit odd; and @PEBoundary is rather technical (not >>>> focused >>>>>>> on the user). >>>>>>> >>>>>>> Alternative suggestions (more may be coming): @TruffleInterpreted, >>>>>>> @TruffleInterpretOnly. (Prepending "Truffle" should indicate that the >>>>>>> method is not exempt from compilation.) >>>>>>> >>>>>>> If the technical stance of @PartialEvaluationBoundary is agreeable but >>>>>>> the name is too long, how about @NoPE? ;-) >>>>>>> >>>>>>> Best, >>>>>>> >>>>>>> Michael -- Dr. Michael Haupt | Principal Member of Technical Staff Phone: +49 331 200 7277 | Fax: +49 331 200 7561 Oracle Labs Oracle Deutschland B.V. & Co. KG, Schiffbauergasse 14 | 14467 Potsdam, Germany Oracle is committed to developing practices and products that help protect the environment From roland.schatz at oracle.com Mon Sep 29 09:33:47 2014 From: roland.schatz at oracle.com (Roland Schatz) Date: Mon, 29 Sep 2014 11:33:47 +0200 Subject: @SlowPath renaming discussion In-Reply-To: References: Message-ID: <5429277B.70008@oracle.com> A completely different suggestion, if you want to avoid the technical term "partial evaluation": You could call it @JavaCode (or similar). The reasoning behind this is that, from now on, you're no longer executing "Truffle" code, but vanilla "Java" code. What the annotation does is, it marks the boundary between the code of the guest language interpreter, which is somehow special, and transitioning to library code which is written in plain Java. This would be along the lines of @TruffleBoundary, but formulated positively (i.e. what begins here, instead of what stops here). That way, the name describes what the annotation "means", as opposed to what it "does". Just my 2?. - Roland On 09/26/2014 04:11 PM, Christian Humer wrote: > Hi Folks, > > I've heard from a few people (including myself) that the @SlowPath > annotation naming might be misleading. That is why I want to raise a > discussion on this list, which will hopefully lead to a good permanent > decision for a new name. > > I would suggest these names: > @Boundary > @TruffleBoundary > @PartialEvaluationBoundary (or @PEBoundary) > > Please add more suggestions and vote for whatever you think is best. > > --- > > Here are some additional thoughts regarding the old name: > > The @SlowPath annotation marks the border for the Truffle partial > evaluator. So methods marked with @SlowPath are not partially evaluated and > treated as if they would be normal Java methods. > > Here is an example: > > @SlowPath > String stringConcat(String s1, String s2) { > return new StringBuilder(s1).append(s2).toString(); > } > > If there would be no @SlowPath annotation on this method then the partial > evaluator would just inline through the constructor and the append method. > This will produce too much code and is not desirable. Another issue is that > the implementation of append is not under the control of the guest language > implementation and might contain e.g. recursions which will make the > partial evaluator fail. > > Virtual objects like VirtualFrame instances must not be passed to @SlowPath > annotated methods because they leave the scope of the partial evaluator. > Such cases are considered Truffle compilation errors. > > To summarize: > * @SlowPath should be applied on every call to a method that is not under > the control of the guest language implementation. > * @SlowPath should be applied on guest language methods that are very big > and might produce too much code. > * Virtual objects must not be passed to @SlowPath annotated methods. > > These are arguments against using "SlowPath" as name: > * Its name does not explain the semantics in any way > * @SlowPath might also be used for "fast path" code. > * The use of @SlowPath does not imply slow execution. > > > > - Christian Humer From christian.wirth at oracle.com Mon Sep 29 09:46:27 2014 From: christian.wirth at oracle.com (Christian Wirth) Date: Mon, 29 Sep 2014 11:46:27 +0200 Subject: @SlowPath renaming discussion In-Reply-To: <962792BE-B242-4653-89B3-C75CC7135B86@oracle.com> References: <6A990121-0783-4EC4-8F43-5D0FC4194C66@oracle.com> <451C896D-6297-4432-9383-49C2EC803174@oracle.com> <54258192.2070909@oracle.com> <65392097-D035-45AA-8E97-22158EB4CB79@oracle.com> <54291AAA.6050609@oracle.com> <962792BE-B242-4653-89B3-C75CC7135B86@oracle.com> Message-ID: <54292A73.5030001@oracle.com> Hi, Michael, I agree. We will have to give a good description of e.g. partial evaluation. Truffle developers need to understand the basic concepts to achieve high performance. Every Truffle developer should know what "PE" means and understand that concept. I vote for @PEBoundary. -- Christian Wirth Am 29.09.2014 11:29, schrieb Michael Haupt: > Hi, > > @PEBoundary is non-threatening and apt, but heavy on jargon. The documentation will have to explain part of the underlying concepts clearly. > > Best, > > Michael > > Am 29.09.2014 um 10:39 schrieb Laurent Daynes : > >> Alright, I'm sold. >> However, I strongly encourage a more developed comment in the source for the annotation that the current succinct one for SlowPath, which >> doesn't reflect the subtleties hidden behind it. >> >> Laurent >> On 9/29/2014 10:30 AM, Lukas Stadler wrote: >>> I?m a big fan of @PEBoundary - because: >>> - it?s concise >>> - it says exactly what it is (entry into this method is a boundary for partial evaluation) >>> - it?s non-threatening (as opposed to stop, cut or exit) >>> - ?inlining? and ?interpreted? are overloaded with too many different meanings, so I think we should avoid these terms >>> >>> - Lukas >>> >>> On 26 Sep 2014, at 18:01, Bernhard Urban wrote: >>> >>>> @ExitPartialEvaluator / @ExitPE >>>> >>>> fwiw, in pypy there's a @jit.dont_look_inside annotation. >>>> >>>> -Bernhard >>>> On Sep 26, 2014 5:30 PM, "Christian Humer" >>>> wrote: >>>> >>>>> I also agree not to use inline. I usually use "guest language inlining" for >>>>> 1), "expansion" for 2) and "host language inlining" for 3). >>>>> >>>>> Will keep the suggestions flowing and will wrap up a vote later on. >>>>> >>>>> >>>>> >>>>> - Christian Humer >>>>> >>>>> On Fri, Sep 26, 2014 at 5:09 PM, Gero Leinemann >>>> wrote: >>>>> >>>>>> Though I find the simplicity of "@NotInlined" etc. appealing, I'd >>>>>> recommend not to use the word "inline", as this is highly overloaded in >>>>> the >>>>>> Truffle/Graal context: >>>>>> 1. inlining by AST rewriting (language level) >>>>>> 2. inlining during/for PE (Truffle level) >>>>>> 3. inlining done by the compiler (Graal/compiler level) >>>>>> This confused - at least - me quite a bit when I started working at >>>>> FastR. >>>>>> What about @StopPE? >>>>>> >>>>>> Best, >>>>>> Gero >>>>>> >>>>>> Am 26.09.2014 um 16:49 schrieb Chris Seaton: >>>>>> >>>>>> What about something less Truffle specific? What about @StopInlining, >>>>>>> @NotInlined or @DontInline? >>>>>>> >>>>>>> On 26 Sep 2014, at 15:28, Michael Haupt >>>>> wrote: >>>>>>> Hi Christian, >>>>>>>> Am 26.09.2014 um 16:11 schrieb Christian Humer < >>>>>>>> christian.humer at gmail.com>: >>>>>>>> I would suggest these names: >>>>>>>> @Boundary >>>>>>>> @TruffleBoundary >>>>>>>> @PartialEvaluationBoundary (or @PEBoundary) >>>>>>>> >>>>>>>> Please add more suggestions and vote for whatever you think is best. >>>>>>>> >>>>>>>> I'll try to first give my rationale for how I try to come up with a >>>>>>>> name. It should express the intent of the annotation with regard to the >>>>>>>> method it is attached to, at a level that is understandable by a >>>>> Truffle >>>>>>>> user. >>>>>>>> >>>>>>>> Applying this, and note that this is purely my personal view, @Boundary >>>>>>>> is a bit too fuzzy; @TruffleBoundary is more apt, but regarding a >>>>> method as >>>>>>>> a boundary is a bit odd; and @PEBoundary is rather technical (not >>>>> focused >>>>>>>> on the user). >>>>>>>> >>>>>>>> Alternative suggestions (more may be coming): @TruffleInterpreted, >>>>>>>> @TruffleInterpretOnly. (Prepending "Truffle" should indicate that the >>>>>>>> method is not exempt from compilation.) >>>>>>>> >>>>>>>> If the technical stance of @PartialEvaluationBoundary is agreeable but >>>>>>>> the name is too long, how about @NoPE? ;-) >>>>>>>> >>>>>>>> Best, >>>>>>>> >>>>>>>> Michael > From christian.wirth at oracle.com Mon Sep 29 09:48:06 2014 From: christian.wirth at oracle.com (Christian Wirth) Date: Mon, 29 Sep 2014 11:48:06 +0200 Subject: @SlowPath renaming discussion In-Reply-To: <5429277B.70008@oracle.com> References: <5429277B.70008@oracle.com> Message-ID: <54292AD6.1050408@oracle.com> Hi, Roland, I see your point. However, I think "@JavaCode" it is heavily confusing in the sense that all Truffle code is Java code as well. -- Christian Am 29.09.2014 11:33, schrieb Roland Schatz: > A completely different suggestion, if you want to avoid the technical > term "partial evaluation": > > You could call it @JavaCode (or similar). > > The reasoning behind this is that, from now on, you're no longer > executing "Truffle" code, but vanilla "Java" code. > What the annotation does is, it marks the boundary between the code of > the guest language interpreter, which is somehow special, and > transitioning to library code which is written in plain Java. > > This would be along the lines of @TruffleBoundary, but formulated > positively (i.e. what begins here, instead of what stops here). > That way, the name describes what the annotation "means", as opposed > to what it "does". > > Just my 2?. > > - Roland > > On 09/26/2014 04:11 PM, Christian Humer wrote: >> Hi Folks, >> >> I've heard from a few people (including myself) that the @SlowPath >> annotation naming might be misleading. That is why I want to raise a >> discussion on this list, which will hopefully lead to a good permanent >> decision for a new name. >> >> I would suggest these names: >> @Boundary >> @TruffleBoundary >> @PartialEvaluationBoundary (or @PEBoundary) >> >> Please add more suggestions and vote for whatever you think is best. >> >> --- >> >> Here are some additional thoughts regarding the old name: >> >> The @SlowPath annotation marks the border for the Truffle partial >> evaluator. So methods marked with @SlowPath are not partially >> evaluated and >> treated as if they would be normal Java methods. >> >> Here is an example: >> >> @SlowPath >> String stringConcat(String s1, String s2) { >> return new StringBuilder(s1).append(s2).toString(); >> } >> >> If there would be no @SlowPath annotation on this method then the >> partial >> evaluator would just inline through the constructor and the append >> method. >> This will produce too much code and is not desirable. Another issue >> is that >> the implementation of append is not under the control of the guest >> language >> implementation and might contain e.g. recursions which will make the >> partial evaluator fail. >> >> Virtual objects like VirtualFrame instances must not be passed to >> @SlowPath >> annotated methods because they leave the scope of the partial evaluator. >> Such cases are considered Truffle compilation errors. >> >> To summarize: >> * @SlowPath should be applied on every call to a method that is not >> under >> the control of the guest language implementation. >> * @SlowPath should be applied on guest language methods that are >> very big >> and might produce too much code. >> * Virtual objects must not be passed to @SlowPath annotated methods. >> >> These are arguments against using "SlowPath" as name: >> * Its name does not explain the semantics in any way >> * @SlowPath might also be used for "fast path" code. >> * The use of @SlowPath does not imply slow execution. >> >> >> >> - Christian Humer > From andreas.woess at jku.at Mon Sep 29 10:09:31 2014 From: andreas.woess at jku.at (Andreas Woess) Date: Mon, 29 Sep 2014 12:09:31 +0200 Subject: @SlowPath renaming discussion In-Reply-To: <962792BE-B242-4653-89B3-C75CC7135B86@oracle.com> References: <6A990121-0783-4EC4-8F43-5D0FC4194C66@oracle.com> <451C896D-6297-4432-9383-49C2EC803174@oracle.com> <54258192.2070909@oracle.com> <65392097-D035-45AA-8E97-22158EB4CB79@oracle.com> <54291AAA.6050609@oracle.com> <962792BE-B242-4653-89B3-C75CC7135B86@oracle.com> Message-ID: <54292FDB.1040707@jku.at> Isn't this more of a documentation issue than anything else? No matter the name, someone who hasn't used Truffle before most likely doesn't know the meaning of the annotation and when and where to put it. You have to be aware of Truffle's partial evaluation and its entry and exit points. That said, I'm happy with a new name if it is free of misleading connotations and concise. - andreas On 29/09/14 11:29, Michael Haupt wrote: > Hi, > > @PEBoundary is non-threatening and apt, but heavy on jargon. The documentation will have to explain part of the underlying concepts clearly. > > Best, > > Michael > > Am 29.09.2014 um 10:39 schrieb Laurent Daynes : > >> Alright, I'm sold. >> However, I strongly encourage a more developed comment in the source for the annotation that the current succinct one for SlowPath, which >> doesn't reflect the subtleties hidden behind it. >> >> Laurent >> On 9/29/2014 10:30 AM, Lukas Stadler wrote: >>> I?m a big fan of @PEBoundary - because: >>> - it?s concise >>> - it says exactly what it is (entry into this method is a boundary for partial evaluation) >>> - it?s non-threatening (as opposed to stop, cut or exit) >>> - ?inlining? and ?interpreted? are overloaded with too many different meanings, so I think we should avoid these terms >>> >>> - Lukas >>> >>> On 26 Sep 2014, at 18:01, Bernhard Urban wrote: >>> >>>> @ExitPartialEvaluator / @ExitPE >>>> >>>> fwiw, in pypy there's a @jit.dont_look_inside annotation. >>>> >>>> -Bernhard >>>> On Sep 26, 2014 5:30 PM, "Christian Humer" >>>> wrote: >>>> >>>>> I also agree not to use inline. I usually use "guest language inlining" for >>>>> 1), "expansion" for 2) and "host language inlining" for 3). >>>>> >>>>> Will keep the suggestions flowing and will wrap up a vote later on. >>>>> >>>>> >>>>> >>>>> - Christian Humer >>>>> >>>>> On Fri, Sep 26, 2014 at 5:09 PM, Gero Leinemann >>>> wrote: >>>>> >>>>>> Though I find the simplicity of "@NotInlined" etc. appealing, I'd >>>>>> recommend not to use the word "inline", as this is highly overloaded in >>>>> the >>>>>> Truffle/Graal context: >>>>>> 1. inlining by AST rewriting (language level) >>>>>> 2. inlining during/for PE (Truffle level) >>>>>> 3. inlining done by the compiler (Graal/compiler level) >>>>>> This confused - at least - me quite a bit when I started working at >>>>> FastR. >>>>>> What about @StopPE? >>>>>> >>>>>> Best, >>>>>> Gero >>>>>> >>>>>> Am 26.09.2014 um 16:49 schrieb Chris Seaton: >>>>>> >>>>>> What about something less Truffle specific? What about @StopInlining, >>>>>>> @NotInlined or @DontInline? >>>>>>> >>>>>>> On 26 Sep 2014, at 15:28, Michael Haupt >>>>> wrote: >>>>>>> Hi Christian, >>>>>>>> Am 26.09.2014 um 16:11 schrieb Christian Humer < >>>>>>>> christian.humer at gmail.com>: >>>>>>>> I would suggest these names: >>>>>>>> @Boundary >>>>>>>> @TruffleBoundary >>>>>>>> @PartialEvaluationBoundary (or @PEBoundary) >>>>>>>> >>>>>>>> Please add more suggestions and vote for whatever you think is best. >>>>>>>> >>>>>>>> I'll try to first give my rationale for how I try to come up with a >>>>>>>> name. It should express the intent of the annotation with regard to the >>>>>>>> method it is attached to, at a level that is understandable by a >>>>> Truffle >>>>>>>> user. >>>>>>>> >>>>>>>> Applying this, and note that this is purely my personal view, @Boundary >>>>>>>> is a bit too fuzzy; @TruffleBoundary is more apt, but regarding a >>>>> method as >>>>>>>> a boundary is a bit odd; and @PEBoundary is rather technical (not >>>>> focused >>>>>>>> on the user). >>>>>>>> >>>>>>>> Alternative suggestions (more may be coming): @TruffleInterpreted, >>>>>>>> @TruffleInterpretOnly. (Prepending "Truffle" should indicate that the >>>>>>>> method is not exempt from compilation.) >>>>>>>> >>>>>>>> If the technical stance of @PartialEvaluationBoundary is agreeable but >>>>>>>> the name is too long, how about @NoPE? ;-) >>>>>>>> >>>>>>>> Best, >>>>>>>> >>>>>>>> Michael > From java at stefan-marr.de Mon Sep 29 12:02:41 2014 From: java at stefan-marr.de (Stefan Marr) Date: Mon, 29 Sep 2014 14:02:41 +0200 Subject: @SlowPath renaming discussion In-Reply-To: <5429277B.70008@oracle.com> References: <5429277B.70008@oracle.com> Message-ID: <0DD5E47F-232A-4353-B53E-C2EAAEBB4398@stefan-marr.de> Hi: On 29 Sep 2014, at 11:33, Roland Schatz wrote: > You could call it @JavaCode (or similar). > > The reasoning behind this is that, from now on, you're no longer executing "Truffle" code, but vanilla "Java" code. > What the annotation does is, it marks the boundary between the code of the guest language interpreter, which is somehow special, and transitioning to library code which is written in plain Java. I like the general idea. How about @PlatformCode to avoid the potentially confusing ?Java?? ?Platform? or something similar to indicate that it is not the guest interpreter. Best regards Stefan -- Stefan Marr INRIA Lille - Nord Europe http://stefan-marr.de/research/ From gero.leinemann at oracle.com Mon Sep 29 13:30:19 2014 From: gero.leinemann at oracle.com (Gero Leinemann) Date: Mon, 29 Sep 2014 15:30:19 +0200 Subject: @SlowPath renaming discussion In-Reply-To: <962792BE-B242-4653-89B3-C75CC7135B86@oracle.com> References: <6A990121-0783-4EC4-8F43-5D0FC4194C66@oracle.com> <451C896D-6297-4432-9383-49C2EC803174@oracle.com> <54258192.2070909@oracle.com> <65392097-D035-45AA-8E97-22158EB4CB79@oracle.com> <54291AAA.6050609@oracle.com> <962792BE-B242-4653-89B3-C75CC7135B86@oracle.com> Message-ID: <54295EEB.8020501@oracle.com> +1 for @PEBoundary + JavaDoc Gero Am 29.09.2014 um 11:29 schrieb Michael Haupt: > Hi, > > @PEBoundary is non-threatening and apt, but heavy on jargon. The documentation will have to explain part of the underlying concepts clearly. > > Best, > > Michael > > Am 29.09.2014 um 10:39 schrieb Laurent Daynes : > >> Alright, I'm sold. >> However, I strongly encourage a more developed comment in the source for the annotation that the current succinct one for SlowPath, which >> doesn't reflect the subtleties hidden behind it. >> >> Laurent >> On 9/29/2014 10:30 AM, Lukas Stadler wrote: >>> I?m a big fan of @PEBoundary - because: >>> - it?s concise >>> - it says exactly what it is (entry into this method is a boundary for partial evaluation) >>> - it?s non-threatening (as opposed to stop, cut or exit) >>> - ?inlining? and ?interpreted? are overloaded with too many different meanings, so I think we should avoid these terms >>> >>> - Lukas >>> >>> On 26 Sep 2014, at 18:01, Bernhard Urban wrote: >>> >>>> @ExitPartialEvaluator / @ExitPE >>>> >>>> fwiw, in pypy there's a @jit.dont_look_inside annotation. >>>> >>>> -Bernhard >>>> On Sep 26, 2014 5:30 PM, "Christian Humer" >>>> wrote: >>>> >>>>> I also agree not to use inline. I usually use "guest language inlining" for >>>>> 1), "expansion" for 2) and "host language inlining" for 3). >>>>> >>>>> Will keep the suggestions flowing and will wrap up a vote later on. >>>>> >>>>> >>>>> >>>>> - Christian Humer >>>>> >>>>> On Fri, Sep 26, 2014 at 5:09 PM, Gero Leinemann >>>> wrote: >>>>> >>>>>> Though I find the simplicity of "@NotInlined" etc. appealing, I'd >>>>>> recommend not to use the word "inline", as this is highly overloaded in >>>>> the >>>>>> Truffle/Graal context: >>>>>> 1. inlining by AST rewriting (language level) >>>>>> 2. inlining during/for PE (Truffle level) >>>>>> 3. inlining done by the compiler (Graal/compiler level) >>>>>> This confused - at least - me quite a bit when I started working at >>>>> FastR. >>>>>> What about @StopPE? >>>>>> >>>>>> Best, >>>>>> Gero >>>>>> >>>>>> Am 26.09.2014 um 16:49 schrieb Chris Seaton: >>>>>> >>>>>> What about something less Truffle specific? What about @StopInlining, >>>>>>> @NotInlined or @DontInline? >>>>>>> >>>>>>> On 26 Sep 2014, at 15:28, Michael Haupt >>>>> wrote: >>>>>>> Hi Christian, >>>>>>>> Am 26.09.2014 um 16:11 schrieb Christian Humer < >>>>>>>> christian.humer at gmail.com>: >>>>>>>> I would suggest these names: >>>>>>>> @Boundary >>>>>>>> @TruffleBoundary >>>>>>>> @PartialEvaluationBoundary (or @PEBoundary) >>>>>>>> >>>>>>>> Please add more suggestions and vote for whatever you think is best. >>>>>>>> >>>>>>>> I'll try to first give my rationale for how I try to come up with a >>>>>>>> name. It should express the intent of the annotation with regard to the >>>>>>>> method it is attached to, at a level that is understandable by a >>>>> Truffle >>>>>>>> user. >>>>>>>> >>>>>>>> Applying this, and note that this is purely my personal view, @Boundary >>>>>>>> is a bit too fuzzy; @TruffleBoundary is more apt, but regarding a >>>>> method as >>>>>>>> a boundary is a bit odd; and @PEBoundary is rather technical (not >>>>> focused >>>>>>>> on the user). >>>>>>>> >>>>>>>> Alternative suggestions (more may be coming): @TruffleInterpreted, >>>>>>>> @TruffleInterpretOnly. (Prepending "Truffle" should indicate that the >>>>>>>> method is not exempt from compilation.) >>>>>>>> >>>>>>>> If the technical stance of @PartialEvaluationBoundary is agreeable but >>>>>>>> the name is too long, how about @NoPE? ;-) >>>>>>>> >>>>>>>> Best, >>>>>>>> >>>>>>>> Michael > From gero.leinemann at oracle.com Mon Sep 29 13:51:54 2014 From: gero.leinemann at oracle.com (Gero Leinemann) Date: Mon, 29 Sep 2014 15:51:54 +0200 Subject: +TraceTruffleCompilation: More detailed infos on optimization Message-ID: <542963FA.7020305@oracle.com> Hi all, when checking FastR programs with "+TraceTruffleCompilation" and looking at the output only it's currently impossible to 100% identify a) the function which got called and b) from where it got called, as "CallTarget.toString()" offers only limited information (and only about the callee). I locally added the parameter "SourceSection callSrc" from "OptimizedCallTarget.compile" all the way down to "OptimizedCallTargetLog.logOptimizingDone" which turned out to be tremendously helpful. This is of course very language specific, but I can imagine that others have the same problem, too. If yes, I'd suggest to find a generic solution for language implementors to add information to the output, even if it's only for debugging purposes. Would that make sense? Best, Gero From christian.humer at gmail.com Mon Sep 29 14:19:28 2014 From: christian.humer at gmail.com (Christian Humer) Date: Mon, 29 Sep 2014 16:19:28 +0200 Subject: +TraceTruffleCompilation: More detailed infos on optimization In-Reply-To: <542963FA.7020305@oracle.com> References: <542963FA.7020305@oracle.com> Message-ID: Hi Gero, a) the function which got called and CallTarget#toString() delegates to RootNode#toString() which is controlled by the guest language. So feel free to implement your own overwritten version of RootNode#toString() in R that fits your need to identify the guest language function. b) from where it got called, Do you mean the call site that made the CallTarget hot? We could just go up the guest language stack trace once to see where it got hot. How did you implement that, and can you give me an example output with your modifications? Additionally every node can override Node#getDebugProperties() to provide additional debug information. We could use the RootNode#getDebugProperties() method to provide additional information for the output. Can you elaborate which kind of information do you want to provide this way and also how would you like to see this information get integrated into the log output? On the long term, i think we should work towards a web based logging tool for Truffle. Console log outputs are very limited. Thanks. - Christian Humer On Mon, Sep 29, 2014 at 3:51 PM, Gero Leinemann wrote: > Hi all, > > when checking FastR programs with "+TraceTruffleCompilation" and looking > at the output only it's currently impossible to 100% identify > a) the function which got called and > b) from where it got called, > as "CallTarget.toString()" offers only limited information (and only about > the callee). > > I locally added the parameter "SourceSection callSrc" from > "OptimizedCallTarget.compile" all the way down to "OptimizedCallTargetLog.logOptimizingDone" > which turned out to be tremendously helpful. This is of course very > language specific, but I can imagine that others have the same problem, too. > > If yes, I'd suggest to find a generic solution for language implementors > to add information to the output, even if it's only for debugging purposes. > Would that make sense? > > Best, > Gero > From mick.jordan at oracle.com Mon Sep 29 15:51:18 2014 From: mick.jordan at oracle.com (Mick Jordan) Date: Mon, 29 Sep 2014 08:51:18 -0700 Subject: @SlowPath renaming discussion In-Reply-To: <54292FDB.1040707@jku.at> References: <6A990121-0783-4EC4-8F43-5D0FC4194C66@oracle.com> <451C896D-6297-4432-9383-49C2EC803174@oracle.com> <54258192.2070909@oracle.com> <65392097-D035-45AA-8E97-22158EB4CB79@oracle.com> <54291AAA.6050609@oracle.com> <962792BE-B242-4653-89B3-C75CC7135B86@oracle.com> <54292FDB.1040707@jku.at> Message-ID: <54297FF6.2090106@oracle.com> On 9/29/14, 3:09 AM, Andreas Woess wrote: > Isn't this more of a documentation issue than anything else? No matter > the name, someone who hasn't used Truffle before most likely doesn't > know the meaning of the annotation and when and where to put it. You > have to be aware of Truffle's partial evaluation and its entry and > exit points. I second that. All Truffle annotations should have extensive Javadoc describing their semantics, and then the exact form of the name is less important. It is generally impossible to come up with succint names that convey all the semantics. Mick From christian.humer at gmail.com Mon Sep 29 16:18:39 2014 From: christian.humer at gmail.com (Christian Humer) Date: Mon, 29 Sep 2014 18:18:39 +0200 Subject: @SlowPath renaming discussion In-Reply-To: <54297FF6.2090106@oracle.com> References: <6A990121-0783-4EC4-8F43-5D0FC4194C66@oracle.com> <451C896D-6297-4432-9383-49C2EC803174@oracle.com> <54258192.2070909@oracle.com> <65392097-D035-45AA-8E97-22158EB4CB79@oracle.com> <54291AAA.6050609@oracle.com> <962792BE-B242-4653-89B3-C75CC7135B86@oracle.com> <54292FDB.1040707@jku.at> <54297FF6.2090106@oracle.com> Message-ID: On Mon, Sep 29, 2014 at 5:51 PM, Mick Jordan wrote: > On 9/29/14, 3:09 AM, Andreas Woess wrote: > >> Isn't this more of a documentation issue than anything else? No matter >> the name, someone who hasn't used Truffle before most likely doesn't know >> the meaning of the annotation and when and where to put it. You have to be >> aware of Truffle's partial evaluation and its entry and exit points. >> > I second that. All Truffle annotations should have extensive Javadoc > describing their semantics, and then the exact form of the name is less > important. It is generally impossible to come up with succint names that > convey all the semantics. I agree. Part of the work will be to provide proper documentation. The naming discussion also has the purpose of getting an idea how the documentation should look like. For example if we decide that we name it @PlatformCode or something similar, its clear that we wanna hide the fact that partial evaluation is involved. If we decide to name it @PEBoundary we should at least link to something that explains partial evaluation. - Christian Humer From thomas.wuerthinger at oracle.com Mon Sep 29 17:03:57 2014 From: thomas.wuerthinger at oracle.com (Thomas Wuerthinger) Date: Mon, 29 Sep 2014 10:03:57 -0700 Subject: @SlowPath renaming discussion In-Reply-To: <54292A73.5030001@oracle.com> References: <6A990121-0783-4EC4-8F43-5D0FC4194C66@oracle.com> <451C896D-6297-4432-9383-49C2EC803174@oracle.com> <54258192.2070909@oracle.com> <65392097-D035-45AA-8E97-22158EB4CB79@oracle.com> <54291AAA.6050609@oracle.com> <962792BE-B242-4653-89B3-C75CC7135B86@oracle.com> <54292A73.5030001@oracle.com> Message-ID: <66A41254-CA77-43AE-ABA6-E545916493CC@oracle.com> I think we should avoid abbreviations if possible. While I agree that a Truffle language implementor needs to understand how the compilation actually works, I?m still unsure whether the term ?partial evaluation? is the right one. It is well understood in an academic context, but it is not very intuitive. I?d like to propose two additional options: @CompilationBoundary @RuntimeCall The latter based on similar reasonings to @SlowPath. When implementing a language without Truffle, the equivalent effect to this annotation is achieved by emitting a call to the language runtime (either via bytecodes or via machine code) as opposed to emitting the logic inline. It should also make clear to language implementors the trade-off between using a runtime call (small code size, faster startup, slower peak) as opposed to emitting the logic inline (larger code size, slower startup, faster peak). Maybe we should collect all suggestions and make a majority vote ;). - thomas On 29 Sep 2014, at 02:46, Christian Wirth wrote: > Hi, > > Michael, I agree. We will have to give a good description of e.g. partial evaluation. Truffle developers need to understand the basic concepts to achieve high performance. Every Truffle developer should know what "PE" means and understand that concept. > > I vote for @PEBoundary. > > -- Christian Wirth > > > > Am 29.09.2014 11:29, schrieb Michael Haupt: >> Hi, >> >> @PEBoundary is non-threatening and apt, but heavy on jargon. The documentation will have to explain part of the underlying concepts clearly. >> >> Best, >> >> Michael >> >> Am 29.09.2014 um 10:39 schrieb Laurent Daynes : >> >>> Alright, I'm sold. >>> However, I strongly encourage a more developed comment in the source for the annotation that the current succinct one for SlowPath, which >>> doesn't reflect the subtleties hidden behind it. >>> >>> Laurent >>> On 9/29/2014 10:30 AM, Lukas Stadler wrote: >>>> I?m a big fan of @PEBoundary - because: >>>> - it?s concise >>>> - it says exactly what it is (entry into this method is a boundary for partial evaluation) >>>> - it?s non-threatening (as opposed to stop, cut or exit) >>>> - ?inlining? and ?interpreted? are overloaded with too many different meanings, so I think we should avoid these terms >>>> >>>> - Lukas >>>> >>>> On 26 Sep 2014, at 18:01, Bernhard Urban wrote: >>>> >>>>> @ExitPartialEvaluator / @ExitPE >>>>> >>>>> fwiw, in pypy there's a @jit.dont_look_inside annotation. >>>>> >>>>> -Bernhard >>>>> On Sep 26, 2014 5:30 PM, "Christian Humer" >>>>> wrote: >>>>> >>>>>> I also agree not to use inline. I usually use "guest language inlining" for >>>>>> 1), "expansion" for 2) and "host language inlining" for 3). >>>>>> >>>>>> Will keep the suggestions flowing and will wrap up a vote later on. >>>>>> >>>>>> >>>>>> >>>>>> - Christian Humer >>>>>> >>>>>> On Fri, Sep 26, 2014 at 5:09 PM, Gero Leinemann >>>>> wrote: >>>>>> >>>>>>> Though I find the simplicity of "@NotInlined" etc. appealing, I'd >>>>>>> recommend not to use the word "inline", as this is highly overloaded in >>>>>> the >>>>>>> Truffle/Graal context: >>>>>>> 1. inlining by AST rewriting (language level) >>>>>>> 2. inlining during/for PE (Truffle level) >>>>>>> 3. inlining done by the compiler (Graal/compiler level) >>>>>>> This confused - at least - me quite a bit when I started working at >>>>>> FastR. >>>>>>> What about @StopPE? >>>>>>> >>>>>>> Best, >>>>>>> Gero >>>>>>> >>>>>>> Am 26.09.2014 um 16:49 schrieb Chris Seaton: >>>>>>> >>>>>>> What about something less Truffle specific? What about @StopInlining, >>>>>>>> @NotInlined or @DontInline? >>>>>>>> >>>>>>>> On 26 Sep 2014, at 15:28, Michael Haupt >>>>>> wrote: >>>>>>>> Hi Christian, >>>>>>>>> Am 26.09.2014 um 16:11 schrieb Christian Humer < >>>>>>>>> christian.humer at gmail.com>: >>>>>>>>> I would suggest these names: >>>>>>>>> @Boundary >>>>>>>>> @TruffleBoundary >>>>>>>>> @PartialEvaluationBoundary (or @PEBoundary) >>>>>>>>> >>>>>>>>> Please add more suggestions and vote for whatever you think is best. >>>>>>>>> >>>>>>>>> I'll try to first give my rationale for how I try to come up with a >>>>>>>>> name. It should express the intent of the annotation with regard to the >>>>>>>>> method it is attached to, at a level that is understandable by a >>>>>> Truffle >>>>>>>>> user. >>>>>>>>> >>>>>>>>> Applying this, and note that this is purely my personal view, @Boundary >>>>>>>>> is a bit too fuzzy; @TruffleBoundary is more apt, but regarding a >>>>>> method as >>>>>>>>> a boundary is a bit odd; and @PEBoundary is rather technical (not >>>>>> focused >>>>>>>>> on the user). >>>>>>>>> >>>>>>>>> Alternative suggestions (more may be coming): @TruffleInterpreted, >>>>>>>>> @TruffleInterpretOnly. (Prepending "Truffle" should indicate that the >>>>>>>>> method is not exempt from compilation.) >>>>>>>>> >>>>>>>>> If the technical stance of @PartialEvaluationBoundary is agreeable but >>>>>>>>> the name is too long, how about @NoPE? ;-) >>>>>>>>> >>>>>>>>> Best, >>>>>>>>> >>>>>>>>> Michael >> > From mario.wolczko at oracle.com Mon Sep 29 17:40:34 2014 From: mario.wolczko at oracle.com (Mario Wolczko) Date: Mon, 29 Sep 2014 10:40:34 -0700 Subject: @SlowPath renaming discussion In-Reply-To: <66A41254-CA77-43AE-ABA6-E545916493CC@oracle.com> References: <6A990121-0783-4EC4-8F43-5D0FC4194C66@oracle.com> <451C896D-6297-4432-9383-49C2EC803174@oracle.com> <54258192.2070909@oracle.com> <65392097-D035-45AA-8E97-22158EB4CB79@oracle.com> <54291AAA.6050609@oracle.com> <962792BE-B242-4653-89B3-C75CC7135B86@oracle.com> <54292A73.5030001@oracle.com> <66A41254-CA77-43AE-ABA6-E545916493CC@oracle.com> Message-ID: I agree that abbreviations should be avoided. Also, the "Code" suffix in some of the proposed names is superfluous - it's all code, before and after the annotation. Right now, I don't see any candidates overwhelmingly better than @SlowPath! On Sep 29, 2014, at 10:03 AM, Thomas Wuerthinger wrote: > I think we should avoid abbreviations if possible. While I agree that a Truffle language implementor needs to understand how the compilation actually works, I?m still unsure whether the term ?partial evaluation? is the right one. It is well understood in an academic context, but it is not very intuitive. > > I?d like to propose two additional options: > @CompilationBoundary > @RuntimeCall > > The latter based on similar reasonings to @SlowPath. When implementing a language without Truffle, the equivalent effect to this annotation is achieved by emitting a call to the language runtime (either via bytecodes or via machine code) as opposed to emitting the logic inline. It should also make clear to language implementors the trade-off between using a runtime call (small code size, faster startup, slower peak) as opposed to emitting the logic inline (larger code size, slower startup, faster peak). > > Maybe we should collect all suggestions and make a majority vote ;). > > - thomas > > > On 29 Sep 2014, at 02:46, Christian Wirth wrote: > >> Hi, >> >> Michael, I agree. We will have to give a good description of e.g. partial evaluation. Truffle developers need to understand the basic concepts to achieve high performance. Every Truffle developer should know what "PE" means and understand that concept. >> >> I vote for @PEBoundary. >> >> -- Christian Wirth >> >> >> >> Am 29.09.2014 11:29, schrieb Michael Haupt: >>> Hi, >>> >>> @PEBoundary is non-threatening and apt, but heavy on jargon. The documentation will have to explain part of the underlying concepts clearly. >>> >>> Best, >>> >>> Michael >>> >>> Am 29.09.2014 um 10:39 schrieb Laurent Daynes : >>> >>>> Alright, I'm sold. >>>> However, I strongly encourage a more developed comment in the source for the annotation that the current succinct one for SlowPath, which >>>> doesn't reflect the subtleties hidden behind it. >>>> >>>> Laurent >>>> On 9/29/2014 10:30 AM, Lukas Stadler wrote: >>>>> I?m a big fan of @PEBoundary - because: >>>>> - it?s concise >>>>> - it says exactly what it is (entry into this method is a boundary for partial evaluation) >>>>> - it?s non-threatening (as opposed to stop, cut or exit) >>>>> - ?inlining? and ?interpreted? are overloaded with too many different meanings, so I think we should avoid these terms >>>>> >>>>> - Lukas >>>>> >>>>> On 26 Sep 2014, at 18:01, Bernhard Urban wrote: >>>>> >>>>>> @ExitPartialEvaluator / @ExitPE >>>>>> >>>>>> fwiw, in pypy there's a @jit.dont_look_inside annotation. >>>>>> >>>>>> -Bernhard >>>>>> On Sep 26, 2014 5:30 PM, "Christian Humer" >>>>>> wrote: >>>>>> >>>>>>> I also agree not to use inline. I usually use "guest language inlining" for >>>>>>> 1), "expansion" for 2) and "host language inlining" for 3). >>>>>>> >>>>>>> Will keep the suggestions flowing and will wrap up a vote later on. >>>>>>> >>>>>>> >>>>>>> >>>>>>> - Christian Humer >>>>>>> >>>>>>> On Fri, Sep 26, 2014 at 5:09 PM, Gero Leinemann >>>>>> wrote: >>>>>>> >>>>>>>> Though I find the simplicity of "@NotInlined" etc. appealing, I'd >>>>>>>> recommend not to use the word "inline", as this is highly overloaded in >>>>>>> the >>>>>>>> Truffle/Graal context: >>>>>>>> 1. inlining by AST rewriting (language level) >>>>>>>> 2. inlining during/for PE (Truffle level) >>>>>>>> 3. inlining done by the compiler (Graal/compiler level) >>>>>>>> This confused - at least - me quite a bit when I started working at >>>>>>> FastR. >>>>>>>> What about @StopPE? >>>>>>>> >>>>>>>> Best, >>>>>>>> Gero >>>>>>>> >>>>>>>> Am 26.09.2014 um 16:49 schrieb Chris Seaton: >>>>>>>> >>>>>>>> What about something less Truffle specific? What about @StopInlining, >>>>>>>>> @NotInlined or @DontInline? >>>>>>>>> >>>>>>>>> On 26 Sep 2014, at 15:28, Michael Haupt >>>>>>> wrote: >>>>>>>>> Hi Christian, >>>>>>>>>> Am 26.09.2014 um 16:11 schrieb Christian Humer < >>>>>>>>>> christian.humer at gmail.com>: >>>>>>>>>> I would suggest these names: >>>>>>>>>> @Boundary >>>>>>>>>> @TruffleBoundary >>>>>>>>>> @PartialEvaluationBoundary (or @PEBoundary) >>>>>>>>>> >>>>>>>>>> Please add more suggestions and vote for whatever you think is best. >>>>>>>>>> >>>>>>>>>> I'll try to first give my rationale for how I try to come up with a >>>>>>>>>> name. It should express the intent of the annotation with regard to the >>>>>>>>>> method it is attached to, at a level that is understandable by a >>>>>>> Truffle >>>>>>>>>> user. >>>>>>>>>> >>>>>>>>>> Applying this, and note that this is purely my personal view, @Boundary >>>>>>>>>> is a bit too fuzzy; @TruffleBoundary is more apt, but regarding a >>>>>>> method as >>>>>>>>>> a boundary is a bit odd; and @PEBoundary is rather technical (not >>>>>>> focused >>>>>>>>>> on the user). >>>>>>>>>> >>>>>>>>>> Alternative suggestions (more may be coming): @TruffleInterpreted, >>>>>>>>>> @TruffleInterpretOnly. (Prepending "Truffle" should indicate that the >>>>>>>>>> method is not exempt from compilation.) >>>>>>>>>> >>>>>>>>>> If the technical stance of @PartialEvaluationBoundary is agreeable but >>>>>>>>>> the name is too long, how about @NoPE? ;-) >>>>>>>>>> >>>>>>>>>> Best, >>>>>>>>>> >>>>>>>>>> Michael >>> >> > From doug.simon at oracle.com Tue Sep 30 01:00:07 2014 From: doug.simon at oracle.com (doug.simon at oracle.com) Date: Tue, 30 Sep 2014 01:00:07 +0000 Subject: hg: graal/graal: 16 new changesets Message-ID: <201409300100.s8U109bF003401@aojmv0008> Changeset: 86d9e456ef98 Author: Doug Simon Date: 2014-09-29 13:57 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/86d9e456ef98 mx: added cyclic dependency checking ! mxtool/mx.py Changeset: 44c5817156a9 Author: Doug Simon Date: 2014-09-29 13:58 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/44c5817156a9 fixed bug in LIRIntrospection.appendValues ! graal/com.oracle.graal.lir/src/com/oracle/graal/lir/LIRIntrospection.java Changeset: eed077c367d3 Author: Doug Simon Date: 2014-09-29 13:59 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/eed077c367d3 improved performance of NodeClass initialization by improving the way information is derived from super NodeClasses ! graal/com.oracle.graal.compiler.common/src/com/oracle/graal/compiler/common/FieldIntrospection.java ! graal/com.oracle.graal.compiler.common/src/com/oracle/graal/compiler/common/Fields.java ! graal/com.oracle.graal.graph/src/com/oracle/graal/graph/Edges.java ! graal/com.oracle.graal.graph/src/com/oracle/graal/graph/InputEdges.java ! graal/com.oracle.graal.graph/src/com/oracle/graal/graph/NodeClass.java ! graal/com.oracle.graal.graph/src/com/oracle/graal/graph/SuccessorEdges.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: 03826360967b Author: Doug Simon Date: 2014-09-29 14:14 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/03826360967b fix pylint issues ! mxtool/mx.py Changeset: c13f423bd4ed Author: Lukas Stadler Date: 2014-09-29 16:22 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/c13f423bd4ed coalesce DataSection entries ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/data/DataSection.java Changeset: 9f001294893d Author: Christian Humer Date: 2014-09-29 18:37 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/9f001294893d Truffle: Added test case that compiler intrinsics are not intrinsified if hidden behind a @SlowPath. + graal/com.oracle.graal.truffle.test/sl/TestSlowPath01.sl ! graal/com.oracle.graal.truffle.test/src/com/oracle/graal/truffle/test/SLTruffleGraalTestSuite.java + graal/com.oracle.graal.truffle.test/src/com/oracle/graal/truffle/test/builtins/SLTestSlowPath01Builtin.java Changeset: 6ee7afea175a Author: Christian Humer Date: 2014-09-29 18:37 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/6ee7afea175a Truffle-DSL: Fixed @SlowPath was not applied to certain specialize0 implementations. This will reduce the pressure on the truffle cache. ! graal/com.oracle.truffle.dsl.processor/src/com/oracle/truffle/dsl/processor/generator/NodeCodeGenerator.java ! graal/com.oracle.truffle.dsl.processor/src/com/oracle/truffle/dsl/processor/model/NodeData.java ! graal/com.oracle.truffle.dsl.processor/src/com/oracle/truffle/dsl/processor/model/SpecializationData.java Changeset: 1680a4ddc2a7 Author: Christian Humer Date: 2014-09-29 18:39 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/1680a4ddc2a7 Truffle-DSL: added thread-safety for DSL rewrites. ! graal/com.oracle.truffle.api.dsl/src/com/oracle/truffle/api/dsl/internal/DSLShare.java Changeset: b8611b23c4f8 Author: Christian Humer Date: 2014-09-29 18:39 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/b8611b23c4f8 Truffle: Fixed forced inlining decisions could exceed the maximum total node count. ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/DefaultInliningPolicy.java Changeset: 11db1a51607c Author: Christian Humer Date: 2014-09-29 18:39 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/11db1a51607c Truffle: fixed if a lot compilations are queued some Truffle tests could time out ! graal/com.oracle.graal.truffle.test/src/com/oracle/graal/truffle/test/builtins/SLWaitForOptimizationBuiltin.java Changeset: c53ff2dc8284 Author: Christian Humer Date: 2014-09-29 18:39 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/c53ff2dc8284 Truffle: aligned expansion logger to changed Graal type name API. ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/TruffleExpansionLogger.java Changeset: 88d5fd9e1a6c Author: Christian Humer Date: 2014-09-29 18:46 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/88d5fd9e1a6c Truffle: implemented context sensitive inlining; implemented basic partial evaluation caching for call targets (disabled by default). ! graal/com.oracle.graal.truffle.test/src/com/oracle/graal/truffle/test/PartialEvaluationTest.java + graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/ContextSensitiveInlining.java ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/OptimizedCallTarget.java ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/OptimizedCallTargetLog.java ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/OptimizedCallUtils.java ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/OptimizedDirectCallNode.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/TruffleCacheImpl.java ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/TruffleCompilerImpl.java ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/TruffleCompilerOptions.java ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/TruffleInliningHandler.java ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/TruffleInliningProfile.java Changeset: f735aa886cf6 Author: Christian Humer Date: 2014-09-29 18:46 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/f735aa886cf6 Truffle: add new inlining tests; adapt tests for context sensitive inlining. + graal/com.oracle.graal.truffle.test/sl/TestInlining.sl ! graal/com.oracle.graal.truffle.test/sl/TestInliningMaxCallerSize.sl + graal/com.oracle.graal.truffle.test/sl/TestInliningRecursive1.sl + graal/com.oracle.graal.truffle.test/sl/TestInliningRecursive2.sl ! graal/com.oracle.graal.truffle.test/src/com/oracle/graal/truffle/test/builtins/SLIsInlinedBuiltin.java Changeset: f1f7b796874f Author: Doug Simon Date: 2014-09-29 20:48 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/f1f7b796874f moved Node naming logic to generated nodes ! 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.nodeinfo.processor/src/com/oracle/graal/nodeinfo/processor/GraphNodeGenerator.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/EndNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/StartNode.java ! graal/com.oracle.graal.printer/src/com/oracle/graal/printer/BinaryGraphPrinter.java ! graal/com.oracle.graal.printer/src/com/oracle/graal/printer/CFGPrinter.java Changeset: eff18e262a13 Author: Bernhard Urban Date: 2014-09-29 20:13 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/eff18e262a13 fix jdt build on windows/cygwin (2) ! mxtool/mx.py Changeset: 222b60e248ba Author: Christian Humer Date: 2014-09-30 00:48 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/222b60e248ba Truffle-DSL: fixed regression with @SlowPath on specialize0. ! graal/com.oracle.truffle.dsl.processor/src/com/oracle/truffle/dsl/processor/generator/NodeCodeGenerator.java From lukas.stadler at oracle.com Tue Sep 30 09:19:37 2014 From: lukas.stadler at oracle.com (Lukas Stadler) Date: Tue, 30 Sep 2014 11:19:37 +0200 Subject: @SlowPath renaming discussion In-Reply-To: <66A41254-CA77-43AE-ABA6-E545916493CC@oracle.com> References: <6A990121-0783-4EC4-8F43-5D0FC4194C66@oracle.com> <451C896D-6297-4432-9383-49C2EC803174@oracle.com> <54258192.2070909@oracle.com> <65392097-D035-45AA-8E97-22158EB4CB79@oracle.com> <54291AAA.6050609@oracle.com> <962792BE-B242-4653-89B3-C75CC7135B86@oracle.com> <54292A73.5030001@oracle.com> <66A41254-CA77-43AE-ABA6-E545916493CC@oracle.com> Message-ID: The term ?partial evaluation? is not widely used, which makes it a good fit - because all widely-used terms have lots of other meanings. Truffle is a one-of-a-kind technology, so it can afford to introduce its own terminology. The naming question is connected to the question of what this annotation is supposed to achieve and how it is supposed to be used. IMO, the ?skeleton? that is derived via partial evaluation needs to contain the parts that make certain things compile-time constant: node instances, (@Compilation)final node field values, profiles, loop counts (for @ExplodeLoop), call targets, types. It also needs to include all places that use Truffle-specific intrinsics (invalidating compiled code, assertions, ?). This hard hard to do automatically, since asking the reverse question (what needs to be inlined to make this value constant?) is difficult. So everything that can be @SlowPath should be - and Graal?s inlining should figure out the rest. But maybe I?m too optimistic :-) - Lukas On 29 Sep 2014, at 19:03, Thomas Wuerthinger wrote: > I think we should avoid abbreviations if possible. While I agree that a Truffle language implementor needs to understand how the compilation actually works, I?m still unsure whether the term ?partial evaluation? is the right one. It is well understood in an academic context, but it is not very intuitive. > > I?d like to propose two additional options: > @CompilationBoundary > @RuntimeCall > > The latter based on similar reasonings to @SlowPath. When implementing a language without Truffle, the equivalent effect to this annotation is achieved by emitting a call to the language runtime (either via bytecodes or via machine code) as opposed to emitting the logic inline. It should also make clear to language implementors the trade-off between using a runtime call (small code size, faster startup, slower peak) as opposed to emitting the logic inline (larger code size, slower startup, faster peak). > > Maybe we should collect all suggestions and make a majority vote ;). > > - thomas > > > On 29 Sep 2014, at 02:46, Christian Wirth wrote: > >> Hi, >> >> Michael, I agree. We will have to give a good description of e.g. partial evaluation. Truffle developers need to understand the basic concepts to achieve high performance. Every Truffle developer should know what "PE" means and understand that concept. >> >> I vote for @PEBoundary. >> >> -- Christian Wirth >> >> >> >> Am 29.09.2014 11:29, schrieb Michael Haupt: >>> Hi, >>> >>> @PEBoundary is non-threatening and apt, but heavy on jargon. The documentation will have to explain part of the underlying concepts clearly. >>> >>> Best, >>> >>> Michael >>> >>> Am 29.09.2014 um 10:39 schrieb Laurent Daynes : >>> >>>> Alright, I'm sold. >>>> However, I strongly encourage a more developed comment in the source for the annotation that the current succinct one for SlowPath, which >>>> doesn't reflect the subtleties hidden behind it. >>>> >>>> Laurent >>>> On 9/29/2014 10:30 AM, Lukas Stadler wrote: >>>>> I?m a big fan of @PEBoundary - because: >>>>> - it?s concise >>>>> - it says exactly what it is (entry into this method is a boundary for partial evaluation) >>>>> - it?s non-threatening (as opposed to stop, cut or exit) >>>>> - ?inlining? and ?interpreted? are overloaded with too many different meanings, so I think we should avoid these terms >>>>> >>>>> - Lukas >>>>> >>>>> On 26 Sep 2014, at 18:01, Bernhard Urban wrote: >>>>> >>>>>> @ExitPartialEvaluator / @ExitPE >>>>>> >>>>>> fwiw, in pypy there's a @jit.dont_look_inside annotation. >>>>>> >>>>>> -Bernhard >>>>>> On Sep 26, 2014 5:30 PM, "Christian Humer" >>>>>> wrote: >>>>>> >>>>>>> I also agree not to use inline. I usually use "guest language inlining" for >>>>>>> 1), "expansion" for 2) and "host language inlining" for 3). >>>>>>> >>>>>>> Will keep the suggestions flowing and will wrap up a vote later on. >>>>>>> >>>>>>> >>>>>>> >>>>>>> - Christian Humer >>>>>>> >>>>>>> On Fri, Sep 26, 2014 at 5:09 PM, Gero Leinemann >>>>>> wrote: >>>>>>> >>>>>>>> Though I find the simplicity of "@NotInlined" etc. appealing, I'd >>>>>>>> recommend not to use the word "inline", as this is highly overloaded in >>>>>>> the >>>>>>>> Truffle/Graal context: >>>>>>>> 1. inlining by AST rewriting (language level) >>>>>>>> 2. inlining during/for PE (Truffle level) >>>>>>>> 3. inlining done by the compiler (Graal/compiler level) >>>>>>>> This confused - at least - me quite a bit when I started working at >>>>>>> FastR. >>>>>>>> What about @StopPE? >>>>>>>> >>>>>>>> Best, >>>>>>>> Gero >>>>>>>> >>>>>>>> Am 26.09.2014 um 16:49 schrieb Chris Seaton: >>>>>>>> >>>>>>>> What about something less Truffle specific? What about @StopInlining, >>>>>>>>> @NotInlined or @DontInline? >>>>>>>>> >>>>>>>>> On 26 Sep 2014, at 15:28, Michael Haupt >>>>>>> wrote: >>>>>>>>> Hi Christian, >>>>>>>>>> Am 26.09.2014 um 16:11 schrieb Christian Humer < >>>>>>>>>> christian.humer at gmail.com>: >>>>>>>>>> I would suggest these names: >>>>>>>>>> @Boundary >>>>>>>>>> @TruffleBoundary >>>>>>>>>> @PartialEvaluationBoundary (or @PEBoundary) >>>>>>>>>> >>>>>>>>>> Please add more suggestions and vote for whatever you think is best. >>>>>>>>>> >>>>>>>>>> I'll try to first give my rationale for how I try to come up with a >>>>>>>>>> name. It should express the intent of the annotation with regard to the >>>>>>>>>> method it is attached to, at a level that is understandable by a >>>>>>> Truffle >>>>>>>>>> user. >>>>>>>>>> >>>>>>>>>> Applying this, and note that this is purely my personal view, @Boundary >>>>>>>>>> is a bit too fuzzy; @TruffleBoundary is more apt, but regarding a >>>>>>> method as >>>>>>>>>> a boundary is a bit odd; and @PEBoundary is rather technical (not >>>>>>> focused >>>>>>>>>> on the user). >>>>>>>>>> >>>>>>>>>> Alternative suggestions (more may be coming): @TruffleInterpreted, >>>>>>>>>> @TruffleInterpretOnly. (Prepending "Truffle" should indicate that the >>>>>>>>>> method is not exempt from compilation.) >>>>>>>>>> >>>>>>>>>> If the technical stance of @PartialEvaluationBoundary is agreeable but >>>>>>>>>> the name is too long, how about @NoPE? ;-) >>>>>>>>>> >>>>>>>>>> Best, >>>>>>>>>> >>>>>>>>>> Michael >>> >> > From gero.leinemann at oracle.com Tue Sep 30 11:06:36 2014 From: gero.leinemann at oracle.com (Gero Leinemann) Date: Tue, 30 Sep 2014 13:06:36 +0200 Subject: +TraceTruffleCompilation: More detailed infos on optimization In-Reply-To: References: <542963FA.7020305@oracle.com> Message-ID: <542A8EBC.2000909@oracle.com> Hi Christian, >> a) the function which got called and > CallTarget#toString() delegates to RootNode#toString() which is > controlled by the guest language. So feel free to implement your own > overwritten version of RootNode#toString() in R that fits your need to > identify the guest language function. yes. I wanted to stress the point that a function is most easily identified by the name of the variable it's assigned to, which is a property of the call site and not the function/CallTarget itself. Instead of modifying "RootNode.toString" or implement "getDebugProperties()", it'd be useful to be able to pass information from the call site, too. >> b) from where it got called, > Do you mean the call site that made the CallTarget hot? We could just > go up the guest language stack trace once to see where it got hot. How > did you implement that, and can you give me an example output with > your modifications? The call site that triggered the "compile()", yes. Because R needs to know how each function was called (at least for error messages, maybe even for introspection), we store the SourceSection of the call site (say, "f(x, y)") in the frame. I extract it in "OptimizedCallTarget.interpreterCall", pass it down to "OptimizedCallTargetLog.logOptimizingDone" and add it as output property so a line looks like this: > [truffle] opt done function(item, depth) {\n if (depth == > 0L)\n |ASTSize 324 (5/0) |Time 3212(2115+1097)ms > |*CallSrc tree(left_item, next_depth)* |CallNodes I 0/D 2 > |GraalNodes 4201/ 4193 |CodeSize 19749 |Source > /home/gero/oracle-dev/r/r_benchmarks/r.benchmarks/bin/r/benchmarks/shootout/shootout-binarytrees.r:8 Maybe it's possible to "simply" forward the SourceSection information present in the OptimizedDirectCallNode to the "OptimizedCallTarget.compile" (and so on), but I don't know how to do this without changing the "CallTarget.call(args)" signature, which is not desired I guess. Best, Gero From andreas.woess at jku.at Tue Sep 30 14:30:03 2014 From: andreas.woess at jku.at (Andreas Woess) Date: Tue, 30 Sep 2014 16:30:03 +0200 Subject: +TraceTruffleCompilation: More detailed infos on optimization In-Reply-To: <542A8EBC.2000909@oracle.com> References: <542963FA.7020305@oracle.com> <542A8EBC.2000909@oracle.com> Message-ID: <542ABE6B.8050208@jku.at> Hi Gero, On 2014-09-30 13:06, Gero Leinemann wrote: > Hi Christian, >>> a) the function which got called and >> CallTarget#toString() delegates to RootNode#toString() which is >> controlled by the guest language. So feel free to implement your own >> overwritten version of RootNode#toString() in R that fits your need >> to identify the guest language function. > yes. I wanted to stress the point that a function is most easily > identified by the name of the variable it's assigned to, which is a > property of the call site and not the function/CallTarget itself. > Instead of modifying "RootNode.toString" or implement > "getDebugProperties()", it'd be useful to be able to pass information > from the call site, too. I'd argue a function is best identified by its source location and it's useful to capture the name at function assignment as an identifier (at parse time), which is not a property of the call site. If I understand you correctly, then for this piece of code: name = function() { bla }; other = name; other(); you would identify "other" as the function name rather than "name"? >>> b) from where it got called, >> Do you mean the call site that made the CallTarget hot? We could just >> go up the guest language stack trace once to see where it got hot. >> How did you implement that, and can you give me an example output >> with your modifications? > The call site that triggered the "compile()", yes. Because R needs to > know how each function was called (at least for error messages, maybe > even for introspection), we store the SourceSection of the call site > (say, "f(x, y)") in the frame. > I extract it in "OptimizedCallTarget.interpreterCall", pass it down to > "OptimizedCallTargetLog.logOptimizingDone" and add it as output > property so a line looks like this: >> [truffle] opt done function(item, depth) {\n if (depth == >> 0L)\n |ASTSize 324 (5/0) |Time 3212(2115+1097)ms >> |*CallSrc tree(left_item, next_depth)* |CallNodes I 0/D 2 >> |GraalNodes 4201/ 4193 |CodeSize 19749 |Source >> /home/gero/oracle-dev/r/r_benchmarks/r.benchmarks/bin/r/benchmarks/shootout/shootout-binarytrees.r:8 > Maybe it's possible to "simply" forward the SourceSection information > present in the OptimizedDirectCallNode to the > "OptimizedCallTarget.compile" (and so on), but I don't know how to do > this without changing the "CallTarget.call(args)" signature, which is > not desired I guess. If you need access to caller frames or call nodes in R you could just use TruffleRuntime#iterateFrames (or getCallerFrame). For that, you don't need the SourceSection in the frame. But it sounds like you're mixing two problems here: getting the call node from within R (error messages) vs. for compilation logging. I'm not convinced it is useful to refer to the call site that triggered the compile(). There can be any number of call sites per call target and which one triggers may depend on compilation policy. What is it good for? - andreas From andreas.woess at jku.at Tue Sep 30 16:29:33 2014 From: andreas.woess at jku.at (Andreas Woess) Date: Tue, 30 Sep 2014 18:29:33 +0200 Subject: @SlowPath renaming discussion In-Reply-To: <66A41254-CA77-43AE-ABA6-E545916493CC@oracle.com> References: <6A990121-0783-4EC4-8F43-5D0FC4194C66@oracle.com> <451C896D-6297-4432-9383-49C2EC803174@oracle.com> <54258192.2070909@oracle.com> <65392097-D035-45AA-8E97-22158EB4CB79@oracle.com> <54291AAA.6050609@oracle.com> <962792BE-B242-4653-89B3-C75CC7135B86@oracle.com> <54292A73.5030001@oracle.com> <66A41254-CA77-43AE-ABA6-E545916493CC@oracle.com> Message-ID: <542ADA6D.5040002@jku.at> I like @CompilationBoundary since "Compilation" is what we call it in other places, too: @CompilationFinal, neverPartOfCompilation, compilationConstant. We should be consistent here. @RuntimeCall would be a good fit if it would mean always call, never inline -- which is not the case with @SlowPath. I think we should have both options anyway (maybe inline, don't inline), although that could simply be a boolean parameter to the annotation ("forced"). - andreas On 2014-09-29 19:03, Thomas Wuerthinger wrote: > I think we should avoid abbreviations if possible. While I agree that a Truffle language implementor needs to understand how the compilation actually works, I?m still unsure whether the term ?partial evaluation? is the right one. It is well understood in an academic context, but it is not very intuitive. > > I?d like to propose two additional options: > @CompilationBoundary > @RuntimeCall > > The latter based on similar reasonings to @SlowPath. When implementing a language without Truffle, the equivalent effect to this annotation is achieved by emitting a call to the language runtime (either via bytecodes or via machine code) as opposed to emitting the logic inline. It should also make clear to language implementors the trade-off between using a runtime call (small code size, faster startup, slower peak) as opposed to emitting the logic inline (larger code size, slower startup, faster peak). > > Maybe we should collect all suggestions and make a majority vote ;). > > - thomas > > > On 29 Sep 2014, at 02:46, Christian Wirth wrote: > >> Hi, >> >> Michael, I agree. We will have to give a good description of e.g. partial evaluation. Truffle developers need to understand the basic concepts to achieve high performance. Every Truffle developer should know what "PE" means and understand that concept. >> >> I vote for @PEBoundary. >> >> -- Christian Wirth >> >> >> >> Am 29.09.2014 11:29, schrieb Michael Haupt: >>> Hi, >>> >>> @PEBoundary is non-threatening and apt, but heavy on jargon. The documentation will have to explain part of the underlying concepts clearly. >>> >>> Best, >>> >>> Michael >>> >>> Am 29.09.2014 um 10:39 schrieb Laurent Daynes : >>> >>>> Alright, I'm sold. >>>> However, I strongly encourage a more developed comment in the source for the annotation that the current succinct one for SlowPath, which >>>> doesn't reflect the subtleties hidden behind it. >>>> >>>> Laurent >>>> On 9/29/2014 10:30 AM, Lukas Stadler wrote: >>>>> I?m a big fan of @PEBoundary - because: >>>>> - it?s concise >>>>> - it says exactly what it is (entry into this method is a boundary for partial evaluation) >>>>> - it?s non-threatening (as opposed to stop, cut or exit) >>>>> - ?inlining? and ?interpreted? are overloaded with too many different meanings, so I think we should avoid these terms >>>>> >>>>> - Lukas >>>>> >>>>> On 26 Sep 2014, at 18:01, Bernhard Urban wrote: >>>>> >>>>>> @ExitPartialEvaluator / @ExitPE >>>>>> >>>>>> fwiw, in pypy there's a @jit.dont_look_inside annotation. >>>>>> >>>>>> -Bernhard >>>>>> On Sep 26, 2014 5:30 PM, "Christian Humer" >>>>>> wrote: >>>>>> >>>>>>> I also agree not to use inline. I usually use "guest language inlining" for >>>>>>> 1), "expansion" for 2) and "host language inlining" for 3). >>>>>>> >>>>>>> Will keep the suggestions flowing and will wrap up a vote later on. >>>>>>>