From doug.simon at oracle.com Sun Jun 1 01:00:06 2014 From: doug.simon at oracle.com (doug.simon at oracle.com) Date: Sun, 01 Jun 2014 01:00:06 +0000 Subject: hg: graal/graal: 6 new changesets Message-ID: <201406010100.s5110EP8020887@aojmv0008> Changeset: aa28d876651a Author: Miguel Garcia Date: 2014-05-28 17:24 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/aa28d876651a [probability-cache] documentation, assertions added; unreachable code removed ! graal/com.oracle.graal.phases/src/com/oracle/graal/phases/graph/FixedNodeProbabilityCache.java Changeset: 1fbefda059a6 Author: Miguel Garcia Date: 2014-05-29 16:35 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/1fbefda059a6 [inlining] documentation and assertions ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/inlining/walker/InliningData.java Changeset: 114ca0838327 Author: Miguel Garcia Date: 2014-05-30 17:01 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/114ca0838327 [inlining] made explicit an invariant of InliningData ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/inlining/InliningPhase.java ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/inlining/walker/InliningData.java Changeset: 85fa16055535 Author: Miguel Garcia Date: 2014-05-30 18:41 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/85fa16055535 [inlining] refactoring for readability in InlineableGraph ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/inlining/info/elem/InlineableGraph.java Changeset: 23e6edbe4c76 Author: Miguel Garcia Date: 2014-05-30 19:00 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/23e6edbe4c76 [inlining] more uniform treatment of method cloning in InlineableGraph ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/inlining/info/elem/InlineableGraph.java Changeset: 03b1d8f6b4ef Author: Miguel Garcia Date: 2014-05-30 19:41 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/03b1d8f6b4ef [inlining] preparations to avoid cloning whenever possible ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/inlining/info/elem/InlineableGraph.java From duboscq at ssw.jku.at Sun Jun 1 11:06:58 2014 From: duboscq at ssw.jku.at (Gilles Duboscq) Date: Sun, 1 Jun 2014 13:06:58 +0200 Subject: code optimized away before a deopt In-Reply-To: <363CC5AD-79F9-4DD1-9A97-E7EF64467CD9@oracle.com> References: <363CC5AD-79F9-4DD1-9A97-E7EF64467CD9@oracle.com> Message-ID: I think this assert is a good idea. In general I don't think you should use deopt in the same way for snippets used in lowering in the FLOATING_GUARDS stage and in lowering during later stages. At the early stages (FLOATING_GUARDS), the deoptimize node intrinsics should be used to express guards (which is what the assertion checks) and at later stages it's simply a deoptimize node and thus some extra logic can be applied before deoptimization. Maybe we could use two different intrinsics for these two different usages? - deoptimize(); - Guard g = guard(condition); -Gilles On Fri, May 30, 2014 at 10:20 PM, Tom Rodriguez wrote: > > On May 28, 2014, at 1:47 PM, Deneau, Tom wrote: > >> Dredging up this issue again, I still get burned by it occasionally in our snippets. >> The only workaround I have is to insert some test before the actual deopt >> and the test has to be something that the compiler can't optimize away. >> If I forget such a test, (or if the compiler optimizes it away), the fact >> that the side-effecting got discarded can cause situations that are difficult >> to debug. >> >> Just wondering if anything has happened since Novemeber to make this less error-prone. >> I agree with Doug a warning should be the minimum feedback. > > I have some changes that assert when a side effecting node is eliminated by ConvertDeoptimizeToGuardPhase during snippet preparation but I have to make some other changes because it?s unhappy about some assertion logic in one of the snippets. We can see if this assert makes sense in practice. I guess I was surprised that there weren?t more complaints from existing code but I haven?t run it through the gate yet so maybe there are more. I?ll push it once I get the assertion issue fixed. > > This doesn?t really solve your problem though since it will now complain when something gets eliminated but you still have no way to keep it from being eliminated. Maybe you could handle it by doing some late lowering to expand the problematic control flow during LOW_TIER lowering? > > tom > >> >> Or could we have some annotation or something that says in this snippet do not >> do the ConvertDeoptimizeToGuardPhase? >> >> -- Tom >> >> >> >>>> -----Original Message----- >>>> From: Doug Simon [mailto:doug.simon at oracle.com] >>>> Sent: Saturday, November 23, 2013 10:24 AM >>>> To: Lukas Stadler >>>> Cc: Deneau, Tom; graal-dev at openjdk.java.net >>>> Subject: Re: code optimized away before a deopt >>>> >>>> >>>> On Nov 23, 2013, at 5:18 PM, Lukas Stadler wrote: >>>> >>>>> But it _is_ ok to remove side effecting nodes, because we know they >>>> will be reelected. >>>> >>>> Yes, normally, but when you write this pattern in a snippet, then >>>> this won't be true right, since we don't resume execution in the >>>> bytecode of the snippet (yet!). That why I was thinking at least a >>>> warning would be a good idea. >>>> >>>> -Doug >>>> >>>>> Maybe the cleanup operations could be part of a special purpose >>>>> deopt >>>> node? >>>>> >>>>> - Lukas >>>>> >>>>> Von meinem iPhone gesendet >>>>> >>>>>> Am 23.11.2013 um 16:39 schrieb Doug Simon : >>>>>> >>>>>> This is done by the ConvertDeoptimizeToGuardPhase which replaces >>>> conditionals where one branch ends in a deopt with a GuardNode. This >>>> does indeed have the side effect of (silently) deleting all other >>>> nodes on that deopt-terminated branch. We should add some code to >>>> either make the deletion not silent or better, throw an error if >>>> these are any side- effecting nodes that will be deleted. >>>>>> >>>>>> -Doug >>>>>> >>>>>>> On Nov 23, 2013, at 1:58 AM, Deneau, Tom wrote: >>>>>>> >>>>>>> I've noticed that if I have a snippet that does a test and if the >>>> test fails, branches to a block that does some cleanup operations and >>>> then calls DeoptimizeNode.deopt(xxx, yyy), the cleanup code gets >>>> "optimized away". I guess this is related to what Gilles was talking >>>> about, maybe the cleanup operations were considered not state changing? >>>>>>> >>>>>>> In our current state of HSAIL backend, a deopt just returns early >>>> from the kernel. Is there something I can do to make the cleanup code >>>> get emitted before the deopt? >>>>>>> >>>>>>> -- Tom >>>>>> >>>> >>> >>> >> >> > From doug.simon at oracle.com Mon Jun 2 01:00:06 2014 From: doug.simon at oracle.com (doug.simon at oracle.com) Date: Mon, 02 Jun 2014 01:00:06 +0000 Subject: hg: graal/graal: [inliner] lazy allocation of param-usages container; documentation Message-ID: <201406020100.s52109Kl006070@aojmv0008> Changeset: 5aaef6a8985d Author: Miguel Garcia Date: 2014-06-01 16:06 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/5aaef6a8985d [inliner] lazy allocation of param-usages container; documentation ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/inlining/info/elem/InlineableGraph.java From doug.simon at oracle.com Mon Jun 2 08:30:20 2014 From: doug.simon at oracle.com (Doug Simon) Date: Mon, 2 Jun 2014 10:30:20 +0200 Subject: regression for compressed oops that require shift and add In-Reply-To: References: Message-ID: The code appears to be correct for the AMD64 backend (i.e. UncompressPointer.emitCode()). But the HSAIL backend code looks plausibly correct as well. Do you know where the wrong code path is taken in the HSAIL backend while emitting code? -Doug On May 30, 2014, at 10:30 PM, Deneau, Tom wrote: > All -- > > I have noticed a regression when I update to the latest default tip. > This is in the area of compressed pointers. We typically run with different heap sizes which > force different compression schemes. The failure is in the scheme where the 32-bit compressed pointer > must be multiplied by 8 and then add a base, we get this for example with a max heap size of 31g. > > The problem is that the shift and add must only be applied if the original compressed oop is not 0. > > Previous codegen (good): > ld_global_s32 $s1, [$d1 + 16]; > cvt_u64_u32 $d1, $s1; > cmp_eq_b1_u64 $c0, $d1, 0x0; > mad_u64 $d1, $d1, 8, 0x7fb447fff000; // $d1 = $d1 * 8 + base > cmov_b64 $d1, $c0, 0x0, $d1; // conditionally make $d1 0 if it was originally 0 > > Current codegen (bad); > ld_global_s32 $s1, [$d1 + 16]; > cvt_u64_u32 $d1, $s1; > mad_u64 $d1, $d1, 8, 0x7f0137fff000; > > The other compression schemes seem to work ok. > I confess I had not merged with default for a few weeks so my previous working version was based on default 8d0242a07f7e. But I'm not sure where the regression happened in between there. > > I guess you would not notice this in your gate unless you ran with a heap size big enough to cause this kind of compression. > > -- Tom > From tom.deneau at amd.com Mon Jun 2 11:54:11 2014 From: tom.deneau at amd.com (Deneau, Tom) Date: Mon, 2 Jun 2014 11:54:11 +0000 Subject: regression for compressed oops that require shift and add In-Reply-To: References: Message-ID: Doug -- I will try to get some more details on this. -- Tom > -----Original Message----- > From: Doug Simon [mailto:doug.simon at oracle.com] > Sent: Monday, June 02, 2014 3:30 AM > To: Deneau, Tom > Cc: graal-dev at openjdk.java.net > Subject: Re: regression for compressed oops that require shift and add > > The code appears to be correct for the AMD64 backend (i.e. > UncompressPointer.emitCode()). But the HSAIL backend code looks > plausibly correct as well. Do you know where the wrong code path is > taken in the HSAIL backend while emitting code? > > -Doug > > On May 30, 2014, at 10:30 PM, Deneau, Tom wrote: > > > All -- > > > > I have noticed a regression when I update to the latest default tip. > > This is in the area of compressed pointers. We typically run with > different heap sizes which > > force different compression schemes. The failure is in the scheme > where the 32-bit compressed pointer > > must be multiplied by 8 and then add a base, we get this for example > with a max heap size of 31g. > > > > The problem is that the shift and add must only be applied if the > original compressed oop is not 0. > > > > Previous codegen (good): > > ld_global_s32 $s1, [$d1 + 16]; > > cvt_u64_u32 $d1, $s1; > > cmp_eq_b1_u64 $c0, $d1, 0x0; > > mad_u64 $d1, $d1, 8, 0x7fb447fff000; // $d1 = $d1 * 8 + base > > cmov_b64 $d1, $c0, 0x0, $d1; // conditionally make > $d1 0 if it was originally 0 > > > > Current codegen (bad); > > ld_global_s32 $s1, [$d1 + 16]; > > cvt_u64_u32 $d1, $s1; > > mad_u64 $d1, $d1, 8, 0x7f0137fff000; > > > > The other compression schemes seem to work ok. > > I confess I had not merged with default for a few weeks so my previous > working version was based on default 8d0242a07f7e. But I'm not sure > where the regression happened in between there. > > > > I guess you would not notice this in your gate unless you ran with a > heap size big enough to cause this kind of compression. > > > > -- Tom > > From tom.deneau at amd.com Mon Jun 2 22:28:34 2014 From: tom.deneau at amd.com (Deneau, Tom) Date: Mon, 2 Jun 2014 22:28:34 +0000 Subject: regression for compressed oops that require shift and add In-Reply-To: References: Message-ID: Doug -- To reproduce the failure you can run this single junit test mx unittest -Xmx31g IntStreamNullCheckNonZeroBciTest This test purposely passes in a null object pointer in its input array. It looks like the problem is in CompressionNode.generate if (getInput().stamp() instanceof ObjectStamp) { nonNull = StampTool.isObjectNonNull(getInput().stamp()); } else { // metaspace pointers are never null nonNull = true; } The stamp is NarrowOopStamp which now extends AbstractObjectStamp, so nonNull is always true, and in the hsail LIR code we don't generate the code to test for null. I don't know the best way to fix this. Note that if we replace ObjectStamp above with AbstractObjectStamp, there is then another similar test in StampTool.isObjectNonNull. If I just ignore the nonNull parameter in HSAILMove.UncompressPointer, my test passes but of course the codegen is sub-optimal. -- Tom > -----Original Message----- > From: graal-dev [mailto:graal-dev-bounces at openjdk.java.net] On Behalf Of > Deneau, Tom > Sent: Monday, June 02, 2014 6:54 AM > To: Doug Simon > Cc: graal-dev at openjdk.java.net > Subject: RE: regression for compressed oops that require shift and add > > Doug -- > > I will try to get some more details on this. > > -- Tom > > > -----Original Message----- > > From: Doug Simon [mailto:doug.simon at oracle.com] > > Sent: Monday, June 02, 2014 3:30 AM > > To: Deneau, Tom > > Cc: graal-dev at openjdk.java.net > > Subject: Re: regression for compressed oops that require shift and add > > > > The code appears to be correct for the AMD64 backend (i.e. > > UncompressPointer.emitCode()). But the HSAIL backend code looks > > plausibly correct as well. Do you know where the wrong code path is > > taken in the HSAIL backend while emitting code? > > > > -Doug > > > > On May 30, 2014, at 10:30 PM, Deneau, Tom wrote: > > > > > All -- > > > > > > I have noticed a regression when I update to the latest default tip. > > > This is in the area of compressed pointers. We typically run with > > different heap sizes which > > > force different compression schemes. The failure is in the scheme > > where the 32-bit compressed pointer > > > must be multiplied by 8 and then add a base, we get this for > > > example > > with a max heap size of 31g. > > > > > > The problem is that the shift and add must only be applied if the > > original compressed oop is not 0. > > > > > > Previous codegen (good): > > > ld_global_s32 $s1, [$d1 + 16]; > > > cvt_u64_u32 $d1, $s1; > > > cmp_eq_b1_u64 $c0, $d1, 0x0; > > > mad_u64 $d1, $d1, 8, 0x7fb447fff000; // $d1 = $d1 * 8 + base > > > cmov_b64 $d1, $c0, 0x0, $d1; // conditionally make > > $d1 0 if it was originally 0 > > > > > > Current codegen (bad); > > > ld_global_s32 $s1, [$d1 + 16]; > > > cvt_u64_u32 $d1, $s1; > > > mad_u64 $d1, $d1, 8, 0x7f0137fff000; > > > > > > The other compression schemes seem to work ok. > > > I confess I had not merged with default for a few weeks so my > > > previous > > working version was based on default 8d0242a07f7e. But I'm not sure > > where the regression happened in between there. > > > > > > I guess you would not notice this in your gate unless you ran with a > > heap size big enough to cause this kind of compression. > > > > > > -- Tom > > > From doug.simon at oracle.com Tue Jun 3 01:00:07 2014 From: doug.simon at oracle.com (doug.simon at oracle.com) Date: Tue, 03 Jun 2014 01:00:07 +0000 Subject: hg: graal/graal: 12 new changesets Message-ID: <201406030100.s5310RN6002049@aojmv0008> Changeset: f62cc9f09c7b Author: Lukas Stadler Date: 2014-06-02 17:09 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/f62cc9f09c7b Backed out changeset: a750e0d83535 (cache last receiver stamp in MethodCallTargetNode) ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/java/MethodCallTargetNode.java Changeset: ba0e3c75bd49 Author: Lukas Stadler Date: 2014-06-02 17:10 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/ba0e3c75bd49 add ComputeLoopFrequenciesPhase after canonicalizer ! graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/GraalCompilerTest.java Changeset: df679a9e6de0 Author: Miguel Garcia Date: 2014-06-01 19:50 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/df679a9e6de0 [inliner] additional bits and pieces of documentation and assertions ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/inlining/info/elem/InlineableGraph.java Changeset: 794daffa3850 Author: Miguel Garcia Date: 2014-06-02 16:28 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/794daffa3850 [inliner] return result versus parameter mutation, former deemed more readable ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/inlining/info/elem/InlineableGraph.java Changeset: c13b6c4e2786 Author: Miguel Garcia Date: 2014-06-02 16:39 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/c13b6c4e2786 [inliner] documentation ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/inlining/info/elem/InlineableGraph.java Changeset: 1b07ca2f6c39 Author: Miguel Garcia Date: 2014-06-02 16:53 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/1b07ca2f6c39 [inliner] break method up, to enable delaying specializeGraphToArguments() ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/inlining/info/elem/InlineableGraph.java Changeset: 66fe80527060 Author: Miguel Garcia Date: 2014-06-02 17:00 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/66fe80527060 [inliner] both parts of what used to be a single method now invoked in sequence ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/inlining/info/elem/InlineableGraph.java Changeset: a27eceb10d33 Author: Miguel Garcia Date: 2014-06-02 17:05 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/a27eceb10d33 [inliner] readability ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/inlining/info/elem/InlineableGraph.java Changeset: 2b79ddf41d2f Author: Miguel Garcia Date: 2014-06-02 17:20 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/2b79ddf41d2f [inliner] trickle up, thus making more visible, graph copying ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/inlining/info/elem/InlineableGraph.java Changeset: 9b9d0017168c Author: Miguel Garcia Date: 2014-06-02 17:27 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/9b9d0017168c [inliner] removed a method, lost nothing (but code is more readable afterwards) ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/inlining/info/elem/InlineableGraph.java Changeset: 096848853662 Author: Miguel Garcia Date: 2014-06-02 17:58 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/096848853662 [inliner] no need to alias a final field ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/inlining/info/elem/InlineableGraph.java Changeset: 2e1957c8ccb8 Author: Miguel Garcia Date: 2014-06-02 18:14 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/2e1957c8ccb8 Merge From roland.schatz at oracle.com Tue Jun 3 09:04:23 2014 From: roland.schatz at oracle.com (Roland Schatz) Date: Tue, 03 Jun 2014 11:04:23 +0200 Subject: regression for compressed oops that require shift and add In-Reply-To: References: Message-ID: <538D8F97.2020204@oracle.com> Tom, You're right, this is a regression in Graal. The "instanceof ObjectStamp" tests in CompressionNode and StampTool should actually be "instanceof AbstractObjectStamp". I wonder why we're never hitting this bug in the AMD64 backend, at least on some of our benchmarks we have a heap base != 0. I'm currently pushing a fix. -- Roland On 06/03/2014 12:28 AM, Deneau, Tom wrote: > Doug -- > > To reproduce the failure you can run this single junit test > mx unittest -Xmx31g IntStreamNullCheckNonZeroBciTest > > This test purposely passes in a null object pointer in its input array. > > It looks like the problem is in CompressionNode.generate > if (getInput().stamp() instanceof ObjectStamp) { > nonNull = StampTool.isObjectNonNull(getInput().stamp()); > } else { > // metaspace pointers are never null > nonNull = true; > } > > The stamp is NarrowOopStamp which now extends AbstractObjectStamp, so nonNull is always true, > and in the hsail LIR code we don't generate the code to test for null. > > I don't know the best way to fix this. > Note that if we replace ObjectStamp above with AbstractObjectStamp, there is then another > similar test in StampTool.isObjectNonNull. > > If I just ignore the nonNull parameter in HSAILMove.UncompressPointer, my test passes but of course > the codegen is sub-optimal. > > -- Tom > > >> -----Original Message----- >> From: graal-dev [mailto:graal-dev-bounces at openjdk.java.net] On Behalf Of >> Deneau, Tom >> Sent: Monday, June 02, 2014 6:54 AM >> To: Doug Simon >> Cc: graal-dev at openjdk.java.net >> Subject: RE: regression for compressed oops that require shift and add >> >> Doug -- >> >> I will try to get some more details on this. >> >> -- Tom >> >>> -----Original Message----- >>> From: Doug Simon [mailto:doug.simon at oracle.com] >>> Sent: Monday, June 02, 2014 3:30 AM >>> To: Deneau, Tom >>> Cc: graal-dev at openjdk.java.net >>> Subject: Re: regression for compressed oops that require shift and add >>> >>> The code appears to be correct for the AMD64 backend (i.e. >>> UncompressPointer.emitCode()). But the HSAIL backend code looks >>> plausibly correct as well. Do you know where the wrong code path is >>> taken in the HSAIL backend while emitting code? >>> >>> -Doug >>> >>> On May 30, 2014, at 10:30 PM, Deneau, Tom wrote: >>> >>>> All -- >>>> >>>> I have noticed a regression when I update to the latest default tip. >>>> This is in the area of compressed pointers. We typically run with >>> different heap sizes which >>>> force different compression schemes. The failure is in the scheme >>> where the 32-bit compressed pointer >>>> must be multiplied by 8 and then add a base, we get this for >>>> example >>> with a max heap size of 31g. >>>> The problem is that the shift and add must only be applied if the >>> original compressed oop is not 0. >>>> Previous codegen (good): >>>> ld_global_s32 $s1, [$d1 + 16]; >>>> cvt_u64_u32 $d1, $s1; >>>> cmp_eq_b1_u64 $c0, $d1, 0x0; >>>> mad_u64 $d1, $d1, 8, 0x7fb447fff000; // $d1 = $d1 * 8 + base >>>> cmov_b64 $d1, $c0, 0x0, $d1; // conditionally make >>> $d1 0 if it was originally 0 >>>> Current codegen (bad); >>>> ld_global_s32 $s1, [$d1 + 16]; >>>> cvt_u64_u32 $d1, $s1; >>>> mad_u64 $d1, $d1, 8, 0x7f0137fff000; >>>> >>>> The other compression schemes seem to work ok. >>>> I confess I had not merged with default for a few weeks so my >>>> previous >>> working version was based on default 8d0242a07f7e. But I'm not sure >>> where the regression happened in between there. >>>> I guess you would not notice this in your gate unless you ran with a >>> heap size big enough to cause this kind of compression. >>>> -- Tom >>>> From tom.deneau at amd.com Tue Jun 3 13:26:05 2014 From: tom.deneau at amd.com (Deneau, Tom) Date: Tue, 3 Jun 2014 13:26:05 +0000 Subject: regression for compressed oops that require shift and add In-Reply-To: <538D8F97.2020204@oracle.com> References: <538D8F97.2020204@oracle.com> Message-ID: Do you have tests that explicitly pass null objects in? By the way, how do you control the heap size from your junits? -- Tom > -----Original Message----- > From: graal-dev [mailto:graal-dev-bounces at openjdk.java.net] On Behalf Of > Roland Schatz > Sent: Tuesday, June 03, 2014 4:04 AM > To: graal-dev at openjdk.java.net > Subject: Re: regression for compressed oops that require shift and add > > Tom, > > You're right, this is a regression in Graal. The "instanceof > ObjectStamp" tests in CompressionNode and StampTool should actually be > "instanceof AbstractObjectStamp". > I wonder why we're never hitting this bug in the AMD64 backend, at least > on some of our benchmarks we have a heap base != 0. > > I'm currently pushing a fix. > > -- Roland > > On 06/03/2014 12:28 AM, Deneau, Tom wrote: > > Doug -- > > > > To reproduce the failure you can run this single junit test > > mx unittest -Xmx31g IntStreamNullCheckNonZeroBciTest > > > > This test purposely passes in a null object pointer in its input > array. > > > > It looks like the problem is in CompressionNode.generate > > if (getInput().stamp() instanceof ObjectStamp) { > > nonNull = StampTool.isObjectNonNull(getInput().stamp()); > > } else { > > // metaspace pointers are never null > > nonNull = true; > > } > > > > The stamp is NarrowOopStamp which now extends AbstractObjectStamp, so > > nonNull is always true, and in the hsail LIR code we don't generate > the code to test for null. > > > > I don't know the best way to fix this. > > Note that if we replace ObjectStamp above with AbstractObjectStamp, > > there is then another similar test in StampTool.isObjectNonNull. > > > > If I just ignore the nonNull parameter in HSAILMove.UncompressPointer, > > my test passes but of course the codegen is sub-optimal. > > > > -- Tom > > > > > >> -----Original Message----- > >> From: graal-dev [mailto:graal-dev-bounces at openjdk.java.net] On Behalf > >> Of Deneau, Tom > >> Sent: Monday, June 02, 2014 6:54 AM > >> To: Doug Simon > >> Cc: graal-dev at openjdk.java.net > >> Subject: RE: regression for compressed oops that require shift and > >> add > >> > >> Doug -- > >> > >> I will try to get some more details on this. > >> > >> -- Tom > >> > >>> -----Original Message----- > >>> From: Doug Simon [mailto:doug.simon at oracle.com] > >>> Sent: Monday, June 02, 2014 3:30 AM > >>> To: Deneau, Tom > >>> Cc: graal-dev at openjdk.java.net > >>> Subject: Re: regression for compressed oops that require shift and > >>> add > >>> > >>> The code appears to be correct for the AMD64 backend (i.e. > >>> UncompressPointer.emitCode()). But the HSAIL backend code looks > >>> plausibly correct as well. Do you know where the wrong code path is > >>> taken in the HSAIL backend while emitting code? > >>> > >>> -Doug > >>> > >>> On May 30, 2014, at 10:30 PM, Deneau, Tom > wrote: > >>> > >>>> All -- > >>>> > >>>> I have noticed a regression when I update to the latest default > tip. > >>>> This is in the area of compressed pointers. We typically run with > >>> different heap sizes which > >>>> force different compression schemes. The failure is in the scheme > >>> where the 32-bit compressed pointer > >>>> must be multiplied by 8 and then add a base, we get this for > >>>> example > >>> with a max heap size of 31g. > >>>> The problem is that the shift and add must only be applied if the > >>> original compressed oop is not 0. > >>>> Previous codegen (good): > >>>> ld_global_s32 $s1, [$d1 + 16]; > >>>> cvt_u64_u32 $d1, $s1; > >>>> cmp_eq_b1_u64 $c0, $d1, 0x0; > >>>> mad_u64 $d1, $d1, 8, 0x7fb447fff000; // $d1 = $d1 * 8 + base > >>>> cmov_b64 $d1, $c0, 0x0, $d1; // conditionally make > >>> $d1 0 if it was originally 0 > >>>> Current codegen (bad); > >>>> ld_global_s32 $s1, [$d1 + 16]; > >>>> cvt_u64_u32 $d1, $s1; > >>>> mad_u64 $d1, $d1, 8, 0x7f0137fff000; > >>>> > >>>> The other compression schemes seem to work ok. > >>>> I confess I had not merged with default for a few weeks so my > >>>> previous > >>> working version was based on default 8d0242a07f7e. But I'm not sure > >>> where the regression happened in between there. > >>>> I guess you would not notice this in your gate unless you ran with > >>>> a > >>> heap size big enough to cause this kind of compression. > >>>> -- Tom > >>>> From tom.deneau at amd.com Tue Jun 3 13:31:48 2014 From: tom.deneau at amd.com (Deneau, Tom) Date: Tue, 3 Jun 2014 13:31:48 +0000 Subject: mx gate fail Message-ID: Running mx gate, I get the following failure. Strange because I do see the com.oracle.graal.hotspot.jfr directory. -- Tom ... modified /home/tom/graal/graal/com.oracle.graal.api.replacements/com.oracle.graal.api.replacements.iml modified /home/tom/graal/graal/com.oracle.graal.hotspot.jdk8.test/com.oracle.graal.hotspot.jdk8.test.iml modified /home/tom/graal/graal/com.oracle.graal.api.meta/com.oracle.graal.api.meta.iml modified /home/tom/graal/graal/com.oracle.graal.replacements.test/com.oracle.graal.replacements.test.iml gate: 03 Jun 2014 08:28:08: END: IDEConfigCheck [0:00:43.867074] gate: 03 Jun 2014 08:28:08: BEGIN: Canonicalization Check 03 Jun 2014 08:28:08 - Ensuring mx/projects files are canonicalized... Traceback (most recent call last): File "/home/tom/graal/mx/mx_graal.py", line 1308, in gate if mx.canonicalizeprojects([]) != 0: File "/home/tom/graal/mxtool/mx.py", line 2657, in canonicalizeprojects p = project(m.group(1)) File "/home/tom/graal/mxtool/mx.py", line 1178, in project abort('project named ' + name + ' not found') File "/home/tom/graal/mxtool/mx.py", line 1877, in abort raise SystemExit(codeOrMessage) SystemExit: project named com.oracle.graal.hotspot.jfr not found gate: 03 Jun 2014 08:28:08: ABORT: Gate [0:00:43.969592] project named com.oracle.graal.hotspot.jfr not found From duboscq at ssw.jku.at Tue Jun 3 13:51:34 2014 From: duboscq at ssw.jku.at (Gilles Duboscq) Date: Tue, 3 Jun 2014 15:51:34 +0200 Subject: mx gate fail In-Reply-To: References: Message-ID: On Tue, Jun 3, 2014 at 3:31 PM, Tom Deneau wrote: > Running mx gate, I get the following failure. > Strange because I do see the com.oracle.graal.hotspot.jfr directory. The project is probably "hidden" because you're not building from an Oracle JDK: this project depends on JDK libraries that are only found in Oracle JDKs. When these libraries are not present the project is "hidden" so that it doesn't get in the way but it seems it doesn't hide so well from the project canonicalizer. -Gilles > > -- Tom > > ... > modified /home/tom/graal/graal/com.oracle.graal.api.replacements/com.oracle.graal.api.replacements.iml > modified /home/tom/graal/graal/com.oracle.graal.hotspot.jdk8.test/com.oracle.graal.hotspot.jdk8.test.iml > modified /home/tom/graal/graal/com.oracle.graal.api.meta/com.oracle.graal.api.meta.iml > modified /home/tom/graal/graal/com.oracle.graal.replacements.test/com.oracle.graal.replacements.test.iml > gate: 03 Jun 2014 08:28:08: END: IDEConfigCheck [0:00:43.867074] > gate: 03 Jun 2014 08:28:08: BEGIN: Canonicalization Check > 03 Jun 2014 08:28:08 - Ensuring mx/projects files are canonicalized... > Traceback (most recent call last): > File "/home/tom/graal/mx/mx_graal.py", line 1308, in gate > if mx.canonicalizeprojects([]) != 0: > File "/home/tom/graal/mxtool/mx.py", line 2657, in canonicalizeprojects > p = project(m.group(1)) > File "/home/tom/graal/mxtool/mx.py", line 1178, in project > abort('project named ' + name + ' not found') > File "/home/tom/graal/mxtool/mx.py", line 1877, in abort > raise SystemExit(codeOrMessage) > SystemExit: project named com.oracle.graal.hotspot.jfr not found > gate: 03 Jun 2014 08:28:08: ABORT: Gate [0:00:43.969592] > project named com.oracle.graal.hotspot.jfr not found From tom.deneau at amd.com Tue Jun 3 13:55:17 2014 From: tom.deneau at amd.com (Deneau, Tom) Date: Tue, 3 Jun 2014 13:55:17 +0000 Subject: mx gate fail In-Reply-To: References: Message-ID: Gilles -- Hmm, I was building with a JDK built from the sumatra-dev project, which is only a slight modification of Java 8. Are you saying this depends on libraries that cannot be build from the openjdk? -- Tom > -----Original Message----- > From: gilwooden at gmail.com [mailto:gilwooden at gmail.com] On Behalf Of > Gilles Duboscq > Sent: Tuesday, June 03, 2014 8:52 AM > To: Deneau, Tom > Cc: graal-dev at openjdk.java.net > Subject: Re: mx gate fail > > On Tue, Jun 3, 2014 at 3:31 PM, Tom Deneau wrote: > > Running mx gate, I get the following failure. > > Strange because I do see the com.oracle.graal.hotspot.jfr directory. > > The project is probably "hidden" because you're not building from an > Oracle JDK: this project depends on JDK libraries that are only found in > Oracle JDKs. When these libraries are not present the project is > "hidden" so that it doesn't get in the way but it seems it doesn't hide > so well from the project canonicalizer. > > -Gilles > > > > > -- Tom > > > > ... > > modified > > /home/tom/graal/graal/com.oracle.graal.api.replacements/com.oracle.gra > > al.api.replacements.iml modified > > /home/tom/graal/graal/com.oracle.graal.hotspot.jdk8.test/com.oracle.gr > > aal.hotspot.jdk8.test.iml modified > > /home/tom/graal/graal/com.oracle.graal.api.meta/com.oracle.graal.api.m > > eta.iml modified > > > /home/tom/graal/graal/com.oracle.graal.replacements.test/com.oracle.graa > l.replacements.test.iml > > gate: 03 Jun 2014 08:28:08: END: IDEConfigCheck [0:00:43.867074] > > gate: 03 Jun 2014 08:28:08: BEGIN: Canonicalization Check > > 03 Jun 2014 08:28:08 - Ensuring mx/projects files are canonicalized... > > Traceback (most recent call last): > > File "/home/tom/graal/mx/mx_graal.py", line 1308, in gate > > if mx.canonicalizeprojects([]) != 0: > > File "/home/tom/graal/mxtool/mx.py", line 2657, in > canonicalizeprojects > > p = project(m.group(1)) > > File "/home/tom/graal/mxtool/mx.py", line 1178, in project > > abort('project named ' + name + ' not found') > > File "/home/tom/graal/mxtool/mx.py", line 1877, in abort > > raise SystemExit(codeOrMessage) > > SystemExit: project named com.oracle.graal.hotspot.jfr not found > > gate: 03 Jun 2014 08:28:08: ABORT: Gate [0:00:43.969592] project named > > com.oracle.graal.hotspot.jfr not found From doug.simon at oracle.com Tue Jun 3 14:02:26 2014 From: doug.simon at oracle.com (Doug Simon) Date: Tue, 3 Jun 2014 16:02:26 +0200 Subject: mx gate fail In-Reply-To: References: Message-ID: On Jun 3, 2014, at 3:55 PM, Deneau, Tom wrote: > Gilles -- > > Hmm, I was building with a JDK built from the sumatra-dev project, which is only a slight modification of Java 8. > Are you saying this depends on libraries that cannot be build from the openjdk? Yes. The Java Flight Recorder library is not part of OpenJDK, only Oracle JDK. I?ll make this work with the project canonicalizer. -Doug >> -----Original Message----- >> From: gilwooden at gmail.com [mailto:gilwooden at gmail.com] On Behalf Of >> Gilles Duboscq >> Sent: Tuesday, June 03, 2014 8:52 AM >> To: Deneau, Tom >> Cc: graal-dev at openjdk.java.net >> Subject: Re: mx gate fail >> >> On Tue, Jun 3, 2014 at 3:31 PM, Tom Deneau wrote: >>> Running mx gate, I get the following failure. >>> Strange because I do see the com.oracle.graal.hotspot.jfr directory. >> >> The project is probably "hidden" because you're not building from an >> Oracle JDK: this project depends on JDK libraries that are only found in >> Oracle JDKs. When these libraries are not present the project is >> "hidden" so that it doesn't get in the way but it seems it doesn't hide >> so well from the project canonicalizer. >> >> -Gilles >> >>> >>> -- Tom >>> >>> ... >>> modified >>> /home/tom/graal/graal/com.oracle.graal.api.replacements/com.oracle.gra >>> al.api.replacements.iml modified >>> /home/tom/graal/graal/com.oracle.graal.hotspot.jdk8.test/com.oracle.gr >>> aal.hotspot.jdk8.test.iml modified >>> /home/tom/graal/graal/com.oracle.graal.api.meta/com.oracle.graal.api.m >>> eta.iml modified >>> >> /home/tom/graal/graal/com.oracle.graal.replacements.test/com.oracle.graa >> l.replacements.test.iml >>> gate: 03 Jun 2014 08:28:08: END: IDEConfigCheck [0:00:43.867074] >>> gate: 03 Jun 2014 08:28:08: BEGIN: Canonicalization Check >>> 03 Jun 2014 08:28:08 - Ensuring mx/projects files are canonicalized... >>> Traceback (most recent call last): >>> File "/home/tom/graal/mx/mx_graal.py", line 1308, in gate >>> if mx.canonicalizeprojects([]) != 0: >>> File "/home/tom/graal/mxtool/mx.py", line 2657, in >> canonicalizeprojects >>> p = project(m.group(1)) >>> File "/home/tom/graal/mxtool/mx.py", line 1178, in project >>> abort('project named ' + name + ' not found') >>> File "/home/tom/graal/mxtool/mx.py", line 1877, in abort >>> raise SystemExit(codeOrMessage) >>> SystemExit: project named com.oracle.graal.hotspot.jfr not found >>> gate: 03 Jun 2014 08:28:08: ABORT: Gate [0:00:43.969592] project named >>> com.oracle.graal.hotspot.jfr not found From tom.deneau at amd.com Tue Jun 3 14:33:17 2014 From: tom.deneau at amd.com (Deneau, Tom) Date: Tue, 3 Jun 2014 14:33:17 +0000 Subject: mx gate fail In-Reply-To: References: Message-ID: OK using oracle jdk8 release now, I get this error gate: 03 Jun 2014 09:10:17: END: BuildHotSpotGraal: fastdebug,product [0:13:14.736611] gate: 03 Jun 2014 09:10:17: BEGIN: BootstrapWithSystemAssertions:fastdebug Bootstrapping Graal[thread:8] scope: [thread:8] scope: Compiling [thread:8] scope: Compiling.GraalCompiler [thread:8] scope: Compiling.GraalCompiler.BackEnd [thread:8] scope: Compiling.GraalCompiler.BackEnd.LIRGen [thread:8] scope: Compiling.GraalCompiler.BackEnd.LIRGen.InterceptException Exception occurred in scope: Compiling.GraalCompiler.BackEnd.LIRGen.InterceptException Context obj com.oracle.graal.graph.GraalGraphInternalError: java.lang.AssertionError at node: 26|ArrayEquals Context obj com.oracle.graal.hotspot.amd64.AMD64HotSpotLIRGenerator at 434fb9bb Context obj com.oracle.graal.lir.LIR at 464c71b3 Use -G:+DumpOnError to enable dumping of graphs on this error Context obj StructuredGraph:123{HotSpotMethod} Use -G:+DumpOnError to enable dumping of graphs on this error Context obj com.oracle.graal.hotspot.amd64.AMD64HotSpotCodeCacheProvider at bce7fd0 Context obj DebugDumpScope[53] com.oracle.graal.graph.GraalGraphInternalError: java.lang.AssertionError at node: 26|ArrayEquals at com.oracle.graal.compiler.gen.NodeLIRBuilder.doBlock(NodeLIRBuilder.java:268) at com.oracle.graal.compiler.GraalCompiler.emitBlock(GraalCompiler.java:216) at com.oracle.graal.compiler.GraalCompiler.emitLIR(GraalCompiler.java:250) at com.oracle.graal.compiler.GraalCompiler.emitBackEnd(GraalCompiler.java:198) at com.oracle.graal.compiler.GraalCompiler.compileGraph(GraalCompiler.java:141) at com.oracle.graal.hotspot.CompilationTask.runCompilation(CompilationTask.java:332) at com.oracle.graal.hotspot.CompilationTask.run(CompilationTask.java:176) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) at java.lang.Thread.run(Thread.java:744) at com.oracle.graal.compiler.CompilerThread.run(CompilerThread.java:48) Caused by: java.lang.AssertionError at com.oracle.graal.lir.LIRValueUtil.isVariable(LIRValueUtil.java:30) at com.oracle.graal.lir.LIRVerifier.allowed(LIRVerifier.java:237) at com.oracle.graal.lir.LIRVerifier.access$000(LIRVerifier.java:39) at com.oracle.graal.lir.LIRVerifier$1.doValue(LIRVerifier.java:70) at com.oracle.graal.lir.LIRIntrospection.forEach(LIRIntrospection.java:132) at com.oracle.graal.lir.LIRInstructionClass.forEachTemp(LIRInstructionClass.java:274) at com.oracle.graal.lir.LIRInstruction.forEachTemp(LIRInstruction.java:267) at com.oracle.graal.lir.LIRVerifier.verify(LIRVerifier.java:77) at com.oracle.graal.lir.gen.LIRGenerator.append(LIRGenerator.java:265) at com.oracle.graal.hotspot.amd64.AMD64HotSpotLIRGenerator.append(AMD64HotSpotLIRGenerator.java:127) at com.oracle.graal.compiler.amd64.AMD64LIRGenerator.emitArrayEquals(AMD64LIRGenerator.java:1065) at com.oracle.graal.compiler.gen.NodeLIRBuilder.emitArrayEquals(NodeLIRBuilder.java:651) at com.oracle.graal.replacements.nodes.ArrayEqualsNode.generate(ArrayEqualsNode.java:134) at com.oracle.graal.compiler.gen.NodeLIRBuilder.emitNode(NodeLIRBuilder.java:358) at com.oracle.graal.compiler.gen.NodeLIRBuilder.doRoot(NodeLIRBuilder.java:349) at com.oracle.graal.compiler.gen.NodeLIRBuilder.doBlock(NodeLIRBuilder.java:264) ... 10 more Traceback (most recent call last): File "/home/tom/graal/mx/mx_graal.py", line 1341, in gate gate_body(args, tasks) File "/home/tom/graal/mx/mx_graal.py", line 1179, in _basic_gate_body vm(['-esa', '-XX:-TieredCompilation', '-version']) File "/home/tom/graal/mx/mx_graal.py", line 890, in vm return mx.run(pfx_ + [exe_, '-' + vm_] + args_, nonZeroIsFatal=nonZeroIsFatal, out=out, err=err, cwd=cwd, timeout=timeout) File "/home/tom/graal/mxtool/mx.py", line 1555, in run abort(retcode) File "/home/tom/graal/mxtool/mx.py", line 1877, in abort raise SystemExit(codeOrMessage) SystemExit: 255 gate: 03 Jun 2014 09:10:36: ABORT: Gate [0:16:27.012194] > -----Original Message----- > From: Doug Simon [mailto:doug.simon at oracle.com] > Sent: Tuesday, June 03, 2014 9:02 AM > To: Deneau, Tom > Cc: Gilles Duboscq; graal-dev at openjdk.java.net > Subject: Re: mx gate fail > > > On Jun 3, 2014, at 3:55 PM, Deneau, Tom wrote: > > > Gilles -- > > > > Hmm, I was building with a JDK built from the sumatra-dev project, > which is only a slight modification of Java 8. > > Are you saying this depends on libraries that cannot be build from the > openjdk? > > Yes. The Java Flight Recorder library is not part of OpenJDK, only > Oracle JDK. > > I'll make this work with the project canonicalizer. > > -Doug > > >> -----Original Message----- > >> From: gilwooden at gmail.com [mailto:gilwooden at gmail.com] On Behalf Of > >> Gilles Duboscq > >> Sent: Tuesday, June 03, 2014 8:52 AM > >> To: Deneau, Tom > >> Cc: graal-dev at openjdk.java.net > >> Subject: Re: mx gate fail > >> > >> On Tue, Jun 3, 2014 at 3:31 PM, Tom Deneau > wrote: > >>> Running mx gate, I get the following failure. > >>> Strange because I do see the com.oracle.graal.hotspot.jfr directory. > >> > >> The project is probably "hidden" because you're not building from an > >> Oracle JDK: this project depends on JDK libraries that are only found > >> in Oracle JDKs. When these libraries are not present the project is > >> "hidden" so that it doesn't get in the way but it seems it doesn't > >> hide so well from the project canonicalizer. > >> > >> -Gilles > >> > >>> > >>> -- Tom > >>> > >>> ... > >>> modified > >>> /home/tom/graal/graal/com.oracle.graal.api.replacements/com.oracle.g > >>> ra > >>> al.api.replacements.iml modified > >>> /home/tom/graal/graal/com.oracle.graal.hotspot.jdk8.test/com.oracle. > >>> gr > >>> aal.hotspot.jdk8.test.iml modified > >>> /home/tom/graal/graal/com.oracle.graal.api.meta/com.oracle.graal.api > >>> .m > >>> eta.iml modified > >>> > >> /home/tom/graal/graal/com.oracle.graal.replacements.test/com.oracle.g > >> raa > >> l.replacements.test.iml > >>> gate: 03 Jun 2014 08:28:08: END: IDEConfigCheck [0:00:43.867074] > >>> gate: 03 Jun 2014 08:28:08: BEGIN: Canonicalization Check > >>> 03 Jun 2014 08:28:08 - Ensuring mx/projects files are > canonicalized... > >>> Traceback (most recent call last): > >>> File "/home/tom/graal/mx/mx_graal.py", line 1308, in gate > >>> if mx.canonicalizeprojects([]) != 0: > >>> File "/home/tom/graal/mxtool/mx.py", line 2657, in > >> canonicalizeprojects > >>> p = project(m.group(1)) > >>> File "/home/tom/graal/mxtool/mx.py", line 1178, in project > >>> abort('project named ' + name + ' not found') File > >>> "/home/tom/graal/mxtool/mx.py", line 1877, in abort > >>> raise SystemExit(codeOrMessage) > >>> SystemExit: project named com.oracle.graal.hotspot.jfr not found > >>> gate: 03 Jun 2014 08:28:08: ABORT: Gate [0:00:43.969592] project > >>> named com.oracle.graal.hotspot.jfr not found From doug.simon at oracle.com Tue Jun 3 15:52:54 2014 From: doug.simon at oracle.com (Doug Simon) Date: Tue, 3 Jun 2014 17:52:54 +0200 Subject: mx gate fail In-Reply-To: References: Message-ID: <8FCD86BF-9E0A-4B11-ABD4-5CCF7F130DED@oracle.com> Strange - that kind of thing should be caught in the gate. Can you reproduce it reliably? -Doug On Jun 3, 2014, at 4:33 PM, Deneau, Tom wrote: > OK using oracle jdk8 release now, > I get this error > > gate: 03 Jun 2014 09:10:17: END: BuildHotSpotGraal: fastdebug,product [0:13:14.736611] > gate: 03 Jun 2014 09:10:17: BEGIN: BootstrapWithSystemAssertions:fastdebug > Bootstrapping Graal[thread:8] scope: > [thread:8] scope: Compiling > [thread:8] scope: Compiling.GraalCompiler > [thread:8] scope: Compiling.GraalCompiler.BackEnd > [thread:8] scope: Compiling.GraalCompiler.BackEnd.LIRGen > [thread:8] scope: Compiling.GraalCompiler.BackEnd.LIRGen.InterceptException > Exception occurred in scope: Compiling.GraalCompiler.BackEnd.LIRGen.InterceptException > Context obj com.oracle.graal.graph.GraalGraphInternalError: java.lang.AssertionError > at node: 26|ArrayEquals > Context obj com.oracle.graal.hotspot.amd64.AMD64HotSpotLIRGenerator at 434fb9bb > Context obj com.oracle.graal.lir.LIR at 464c71b3 > Use -G:+DumpOnError to enable dumping of graphs on this error > Context obj StructuredGraph:123{HotSpotMethod} > Use -G:+DumpOnError to enable dumping of graphs on this error > Context obj com.oracle.graal.hotspot.amd64.AMD64HotSpotCodeCacheProvider at bce7fd0 > Context obj DebugDumpScope[53] > com.oracle.graal.graph.GraalGraphInternalError: java.lang.AssertionError > at node: 26|ArrayEquals > at com.oracle.graal.compiler.gen.NodeLIRBuilder.doBlock(NodeLIRBuilder.java:268) > at com.oracle.graal.compiler.GraalCompiler.emitBlock(GraalCompiler.java:216) > at com.oracle.graal.compiler.GraalCompiler.emitLIR(GraalCompiler.java:250) > at com.oracle.graal.compiler.GraalCompiler.emitBackEnd(GraalCompiler.java:198) > at com.oracle.graal.compiler.GraalCompiler.compileGraph(GraalCompiler.java:141) > at com.oracle.graal.hotspot.CompilationTask.runCompilation(CompilationTask.java:332) > at com.oracle.graal.hotspot.CompilationTask.run(CompilationTask.java:176) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) > at java.lang.Thread.run(Thread.java:744) > at com.oracle.graal.compiler.CompilerThread.run(CompilerThread.java:48) > Caused by: java.lang.AssertionError > at com.oracle.graal.lir.LIRValueUtil.isVariable(LIRValueUtil.java:30) > at com.oracle.graal.lir.LIRVerifier.allowed(LIRVerifier.java:237) > at com.oracle.graal.lir.LIRVerifier.access$000(LIRVerifier.java:39) > at com.oracle.graal.lir.LIRVerifier$1.doValue(LIRVerifier.java:70) > at com.oracle.graal.lir.LIRIntrospection.forEach(LIRIntrospection.java:132) > at com.oracle.graal.lir.LIRInstructionClass.forEachTemp(LIRInstructionClass.java:274) > at com.oracle.graal.lir.LIRInstruction.forEachTemp(LIRInstruction.java:267) > at com.oracle.graal.lir.LIRVerifier.verify(LIRVerifier.java:77) > at com.oracle.graal.lir.gen.LIRGenerator.append(LIRGenerator.java:265) > at com.oracle.graal.hotspot.amd64.AMD64HotSpotLIRGenerator.append(AMD64HotSpotLIRGenerator.java:127) > at com.oracle.graal.compiler.amd64.AMD64LIRGenerator.emitArrayEquals(AMD64LIRGenerator.java:1065) > at com.oracle.graal.compiler.gen.NodeLIRBuilder.emitArrayEquals(NodeLIRBuilder.java:651) > at com.oracle.graal.replacements.nodes.ArrayEqualsNode.generate(ArrayEqualsNode.java:134) > at com.oracle.graal.compiler.gen.NodeLIRBuilder.emitNode(NodeLIRBuilder.java:358) > at com.oracle.graal.compiler.gen.NodeLIRBuilder.doRoot(NodeLIRBuilder.java:349) > at com.oracle.graal.compiler.gen.NodeLIRBuilder.doBlock(NodeLIRBuilder.java:264) > ... 10 more > Traceback (most recent call last): > File "/home/tom/graal/mx/mx_graal.py", line 1341, in gate > gate_body(args, tasks) > File "/home/tom/graal/mx/mx_graal.py", line 1179, in _basic_gate_body > vm(['-esa', '-XX:-TieredCompilation', '-version']) > File "/home/tom/graal/mx/mx_graal.py", line 890, in vm > return mx.run(pfx_ + [exe_, '-' + vm_] + args_, nonZeroIsFatal=nonZeroIsFatal, out=out, err=err, cwd=cwd, timeout=timeout) > File "/home/tom/graal/mxtool/mx.py", line 1555, in run > abort(retcode) > File "/home/tom/graal/mxtool/mx.py", line 1877, in abort > raise SystemExit(codeOrMessage) > SystemExit: 255 > gate: 03 Jun 2014 09:10:36: ABORT: Gate [0:16:27.012194] > > >> -----Original Message----- >> From: Doug Simon [mailto:doug.simon at oracle.com] >> Sent: Tuesday, June 03, 2014 9:02 AM >> To: Deneau, Tom >> Cc: Gilles Duboscq; graal-dev at openjdk.java.net >> Subject: Re: mx gate fail >> >> >> On Jun 3, 2014, at 3:55 PM, Deneau, Tom wrote: >> >>> Gilles -- >>> >>> Hmm, I was building with a JDK built from the sumatra-dev project, >> which is only a slight modification of Java 8. >>> Are you saying this depends on libraries that cannot be build from the >> openjdk? >> >> Yes. The Java Flight Recorder library is not part of OpenJDK, only >> Oracle JDK. >> >> I'll make this work with the project canonicalizer. >> >> -Doug >> >>>> -----Original Message----- >>>> From: gilwooden at gmail.com [mailto:gilwooden at gmail.com] On Behalf Of >>>> Gilles Duboscq >>>> Sent: Tuesday, June 03, 2014 8:52 AM >>>> To: Deneau, Tom >>>> Cc: graal-dev at openjdk.java.net >>>> Subject: Re: mx gate fail >>>> >>>> On Tue, Jun 3, 2014 at 3:31 PM, Tom Deneau >> wrote: >>>>> Running mx gate, I get the following failure. >>>>> Strange because I do see the com.oracle.graal.hotspot.jfr directory. >>>> >>>> The project is probably "hidden" because you're not building from an >>>> Oracle JDK: this project depends on JDK libraries that are only found >>>> in Oracle JDKs. When these libraries are not present the project is >>>> "hidden" so that it doesn't get in the way but it seems it doesn't >>>> hide so well from the project canonicalizer. >>>> >>>> -Gilles >>>> >>>>> >>>>> -- Tom >>>>> >>>>> ... >>>>> modified >>>>> /home/tom/graal/graal/com.oracle.graal.api.replacements/com.oracle.g >>>>> ra >>>>> al.api.replacements.iml modified >>>>> /home/tom/graal/graal/com.oracle.graal.hotspot.jdk8.test/com.oracle. >>>>> gr >>>>> aal.hotspot.jdk8.test.iml modified >>>>> /home/tom/graal/graal/com.oracle.graal.api.meta/com.oracle.graal.api >>>>> .m >>>>> eta.iml modified >>>>> >>>> /home/tom/graal/graal/com.oracle.graal.replacements.test/com.oracle.g >>>> raa >>>> l.replacements.test.iml >>>>> gate: 03 Jun 2014 08:28:08: END: IDEConfigCheck [0:00:43.867074] >>>>> gate: 03 Jun 2014 08:28:08: BEGIN: Canonicalization Check >>>>> 03 Jun 2014 08:28:08 - Ensuring mx/projects files are >> canonicalized... >>>>> Traceback (most recent call last): >>>>> File "/home/tom/graal/mx/mx_graal.py", line 1308, in gate >>>>> if mx.canonicalizeprojects([]) != 0: >>>>> File "/home/tom/graal/mxtool/mx.py", line 2657, in >>>> canonicalizeprojects >>>>> p = project(m.group(1)) >>>>> File "/home/tom/graal/mxtool/mx.py", line 1178, in project >>>>> abort('project named ' + name + ' not found') File >>>>> "/home/tom/graal/mxtool/mx.py", line 1877, in abort >>>>> raise SystemExit(codeOrMessage) >>>>> SystemExit: project named com.oracle.graal.hotspot.jfr not found >>>>> gate: 03 Jun 2014 08:28:08: ABORT: Gate [0:00:43.969592] project >>>>> named com.oracle.graal.hotspot.jfr not found > From tom.deneau at amd.com Tue Jun 3 17:06:54 2014 From: tom.deneau at amd.com (Deneau, Tom) Date: Tue, 3 Jun 2014 17:06:54 +0000 Subject: mx gate fail In-Reply-To: <8FCD86BF-9E0A-4B11-ABD4-5CCF7F130DED@oracle.com> References: <8FCD86BF-9E0A-4B11-ABD4-5CCF7F130DED@oracle.com> Message-ID: Doug -- It reproduces on default tip. I am using jdk8-b132. -- Tom > -----Original Message----- > From: Doug Simon [mailto:doug.simon at oracle.com] > Sent: Tuesday, June 03, 2014 10:53 AM > To: Deneau, Tom > Cc: Gilles Duboscq; graal-dev at openjdk.java.net > Subject: Re: mx gate fail > > Strange - that kind of thing should be caught in the gate. Can you > reproduce it reliably? > > -Doug > > On Jun 3, 2014, at 4:33 PM, Deneau, Tom wrote: > > > OK using oracle jdk8 release now, > > I get this error > > > > gate: 03 Jun 2014 09:10:17: END: BuildHotSpotGraal: > fastdebug,product [0:13:14.736611] > > gate: 03 Jun 2014 09:10:17: BEGIN: > > BootstrapWithSystemAssertions:fastdebug > > Bootstrapping Graal[thread:8] scope: > > [thread:8] scope: Compiling > > [thread:8] scope: Compiling.GraalCompiler > > [thread:8] scope: Compiling.GraalCompiler.BackEnd > > [thread:8] scope: Compiling.GraalCompiler.BackEnd.LIRGen > > [thread:8] scope: > Compiling.GraalCompiler.BackEnd.LIRGen.InterceptException > > Exception occurred in scope: > Compiling.GraalCompiler.BackEnd.LIRGen.InterceptException > > Context obj com.oracle.graal.graph.GraalGraphInternalError: > java.lang.AssertionError > > at node: 26|ArrayEquals > > Context obj > com.oracle.graal.hotspot.amd64.AMD64HotSpotLIRGenerator at 434fb9bb > > Context obj com.oracle.graal.lir.LIR at 464c71b3 > > Use -G:+DumpOnError to enable dumping of graphs on this error > > Context obj > StructuredGraph:123{HotSpotMethod Object)>} > > Use -G:+DumpOnError to enable dumping of graphs on this error > > Context obj > com.oracle.graal.hotspot.amd64.AMD64HotSpotCodeCacheProvider at bce7fd0 > > Context obj DebugDumpScope[53] > > com.oracle.graal.graph.GraalGraphInternalError: > java.lang.AssertionError > > at node: 26|ArrayEquals > > at > com.oracle.graal.compiler.gen.NodeLIRBuilder.doBlock(NodeLIRBuilder.java > :268) > > at > com.oracle.graal.compiler.GraalCompiler.emitBlock(GraalCompiler.java:216 > ) > > at > com.oracle.graal.compiler.GraalCompiler.emitLIR(GraalCompiler.java:250) > > at > com.oracle.graal.compiler.GraalCompiler.emitBackEnd(GraalCompiler.java:1 > 98) > > at > com.oracle.graal.compiler.GraalCompiler.compileGraph(GraalCompiler.java: > 141) > > at > com.oracle.graal.hotspot.CompilationTask.runCompilation(CompilationTask. > java:332) > > at > com.oracle.graal.hotspot.CompilationTask.run(CompilationTask.java:176) > > at > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.jav > a:1142) > > at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.ja > va:617) > > at java.lang.Thread.run(Thread.java:744) > > at > > com.oracle.graal.compiler.CompilerThread.run(CompilerThread.java:48) > > Caused by: java.lang.AssertionError > > at > com.oracle.graal.lir.LIRValueUtil.isVariable(LIRValueUtil.java:30) > > at com.oracle.graal.lir.LIRVerifier.allowed(LIRVerifier.java:237) > > at > com.oracle.graal.lir.LIRVerifier.access$000(LIRVerifier.java:39) > > at > com.oracle.graal.lir.LIRVerifier$1.doValue(LIRVerifier.java:70) > > at > com.oracle.graal.lir.LIRIntrospection.forEach(LIRIntrospection.java:132) > > at > com.oracle.graal.lir.LIRInstructionClass.forEachTemp(LIRInstructionClass > .java:274) > > at > com.oracle.graal.lir.LIRInstruction.forEachTemp(LIRInstruction.java:267) > > at com.oracle.graal.lir.LIRVerifier.verify(LIRVerifier.java:77) > > at > com.oracle.graal.lir.gen.LIRGenerator.append(LIRGenerator.java:265) > > at > com.oracle.graal.hotspot.amd64.AMD64HotSpotLIRGenerator.append(AMD64HotS > potLIRGenerator.java:127) > > at > com.oracle.graal.compiler.amd64.AMD64LIRGenerator.emitArrayEquals(AMD64L > IRGenerator.java:1065) > > at > com.oracle.graal.compiler.gen.NodeLIRBuilder.emitArrayEquals(NodeLIRBuil > der.java:651) > > at > com.oracle.graal.replacements.nodes.ArrayEqualsNode.generate(ArrayEquals > Node.java:134) > > at > com.oracle.graal.compiler.gen.NodeLIRBuilder.emitNode(NodeLIRBuilder.jav > a:358) > > at > com.oracle.graal.compiler.gen.NodeLIRBuilder.doRoot(NodeLIRBuilder.java: > 349) > > at > com.oracle.graal.compiler.gen.NodeLIRBuilder.doBlock(NodeLIRBuilder.java > :264) > > ... 10 more > > Traceback (most recent call last): > > File "/home/tom/graal/mx/mx_graal.py", line 1341, in gate > > gate_body(args, tasks) > > File "/home/tom/graal/mx/mx_graal.py", line 1179, in _basic_gate_body > > vm(['-esa', '-XX:-TieredCompilation', '-version']) File > > "/home/tom/graal/mx/mx_graal.py", line 890, in vm > > return mx.run(pfx_ + [exe_, '-' + vm_] + args_, > > nonZeroIsFatal=nonZeroIsFatal, out=out, err=err, cwd=cwd, > timeout=timeout) File "/home/tom/graal/mxtool/mx.py", line 1555, in run > > abort(retcode) > > File "/home/tom/graal/mxtool/mx.py", line 1877, in abort > > raise SystemExit(codeOrMessage) > > SystemExit: 255 > > gate: 03 Jun 2014 09:10:36: ABORT: Gate [0:16:27.012194] > > > > > >> -----Original Message----- > >> From: Doug Simon [mailto:doug.simon at oracle.com] > >> Sent: Tuesday, June 03, 2014 9:02 AM > >> To: Deneau, Tom > >> Cc: Gilles Duboscq; graal-dev at openjdk.java.net > >> Subject: Re: mx gate fail > >> > >> > >> On Jun 3, 2014, at 3:55 PM, Deneau, Tom wrote: > >> > >>> Gilles -- > >>> > >>> Hmm, I was building with a JDK built from the sumatra-dev project, > >> which is only a slight modification of Java 8. > >>> Are you saying this depends on libraries that cannot be build from > >>> the > >> openjdk? > >> > >> Yes. The Java Flight Recorder library is not part of OpenJDK, only > >> Oracle JDK. > >> > >> I'll make this work with the project canonicalizer. > >> > >> -Doug > >> > >>>> -----Original Message----- > >>>> From: gilwooden at gmail.com [mailto:gilwooden at gmail.com] On Behalf Of > >>>> Gilles Duboscq > >>>> Sent: Tuesday, June 03, 2014 8:52 AM > >>>> To: Deneau, Tom > >>>> Cc: graal-dev at openjdk.java.net > >>>> Subject: Re: mx gate fail > >>>> > >>>> On Tue, Jun 3, 2014 at 3:31 PM, Tom Deneau > >> wrote: > >>>>> Running mx gate, I get the following failure. > >>>>> Strange because I do see the com.oracle.graal.hotspot.jfr > directory. > >>>> > >>>> The project is probably "hidden" because you're not building from > >>>> an Oracle JDK: this project depends on JDK libraries that are only > >>>> found in Oracle JDKs. When these libraries are not present the > >>>> project is "hidden" so that it doesn't get in the way but it seems > >>>> it doesn't hide so well from the project canonicalizer. > >>>> > >>>> -Gilles > >>>> > >>>>> > >>>>> -- Tom > >>>>> > >>>>> ... > >>>>> modified > >>>>> /home/tom/graal/graal/com.oracle.graal.api.replacements/com.oracle > >>>>> .g > >>>>> ra > >>>>> al.api.replacements.iml modified > >>>>> > /home/tom/graal/graal/com.oracle.graal.hotspot.jdk8.test/com.oracle. > >>>>> gr > >>>>> aal.hotspot.jdk8.test.iml modified > >>>>> /home/tom/graal/graal/com.oracle.graal.api.meta/com.oracle.graal.a > >>>>> pi > >>>>> .m > >>>>> eta.iml modified > >>>>> > >>>> /home/tom/graal/graal/com.oracle.graal.replacements.test/com.oracle > >>>> .g > >>>> raa > >>>> l.replacements.test.iml > >>>>> gate: 03 Jun 2014 08:28:08: END: IDEConfigCheck [0:00:43.867074] > >>>>> gate: 03 Jun 2014 08:28:08: BEGIN: Canonicalization Check > >>>>> 03 Jun 2014 08:28:08 - Ensuring mx/projects files are > >> canonicalized... > >>>>> Traceback (most recent call last): > >>>>> File "/home/tom/graal/mx/mx_graal.py", line 1308, in gate > >>>>> if mx.canonicalizeprojects([]) != 0: > >>>>> File "/home/tom/graal/mxtool/mx.py", line 2657, in > >>>> canonicalizeprojects > >>>>> p = project(m.group(1)) > >>>>> File "/home/tom/graal/mxtool/mx.py", line 1178, in project > >>>>> abort('project named ' + name + ' not found') File > >>>>> "/home/tom/graal/mxtool/mx.py", line 1877, in abort > >>>>> raise SystemExit(codeOrMessage) > >>>>> SystemExit: project named com.oracle.graal.hotspot.jfr not found > >>>>> gate: 03 Jun 2014 08:28:08: ABORT: Gate [0:00:43.969592] project > >>>>> named com.oracle.graal.hotspot.jfr not found > > From doug.simon at oracle.com Tue Jun 3 19:21:50 2014 From: doug.simon at oracle.com (Doug Simon) Date: Tue, 3 Jun 2014 21:21:50 +0200 Subject: mx gate fail In-Reply-To: References: <8FCD86BF-9E0A-4B11-ABD4-5CCF7F130DED@oracle.com> Message-ID: I think the problematic code is this: public AMD64ArrayEqualsOp(LIRGeneratorTool tool, Kind kind, Value result, Value array1, Value array2, Value length) { ... // We only need the vector temporaries if we generate SSE code. if (supportsSSE41(tool.target())) { this.vectorTemp1 = tool.newVariable(Kind.Double); this.vectorTemp2 = tool.newVariable(Kind.Double); } } I?m guessing you are on a machine that does not support SSE4.1. -Doug On Jun 3, 2014, at 7:06 PM, Deneau, Tom wrote: > Doug -- > > It reproduces on default tip. > I am using jdk8-b132. > > -- Tom > > >> -----Original Message----- >> From: Doug Simon [mailto:doug.simon at oracle.com] >> Sent: Tuesday, June 03, 2014 10:53 AM >> To: Deneau, Tom >> Cc: Gilles Duboscq; graal-dev at openjdk.java.net >> Subject: Re: mx gate fail >> >> Strange - that kind of thing should be caught in the gate. Can you >> reproduce it reliably? >> >> -Doug >> >> On Jun 3, 2014, at 4:33 PM, Deneau, Tom wrote: >> >>> OK using oracle jdk8 release now, >>> I get this error >>> >>> gate: 03 Jun 2014 09:10:17: END: BuildHotSpotGraal: >> fastdebug,product [0:13:14.736611] >>> gate: 03 Jun 2014 09:10:17: BEGIN: >>> BootstrapWithSystemAssertions:fastdebug >>> Bootstrapping Graal[thread:8] scope: >>> [thread:8] scope: Compiling >>> [thread:8] scope: Compiling.GraalCompiler >>> [thread:8] scope: Compiling.GraalCompiler.BackEnd >>> [thread:8] scope: Compiling.GraalCompiler.BackEnd.LIRGen >>> [thread:8] scope: >> Compiling.GraalCompiler.BackEnd.LIRGen.InterceptException >>> Exception occurred in scope: >> Compiling.GraalCompiler.BackEnd.LIRGen.InterceptException >>> Context obj com.oracle.graal.graph.GraalGraphInternalError: >> java.lang.AssertionError >>> at node: 26|ArrayEquals >>> Context obj >> com.oracle.graal.hotspot.amd64.AMD64HotSpotLIRGenerator at 434fb9bb >>> Context obj com.oracle.graal.lir.LIR at 464c71b3 >>> Use -G:+DumpOnError to enable dumping of graphs on this error >>> Context obj >> StructuredGraph:123{HotSpotMethod> Object)>} >>> Use -G:+DumpOnError to enable dumping of graphs on this error >>> Context obj >> com.oracle.graal.hotspot.amd64.AMD64HotSpotCodeCacheProvider at bce7fd0 >>> Context obj DebugDumpScope[53] >>> com.oracle.graal.graph.GraalGraphInternalError: >> java.lang.AssertionError >>> at node: 26|ArrayEquals >>> at >> com.oracle.graal.compiler.gen.NodeLIRBuilder.doBlock(NodeLIRBuilder.java >> :268) >>> at >> com.oracle.graal.compiler.GraalCompiler.emitBlock(GraalCompiler.java:216 >> ) >>> at >> com.oracle.graal.compiler.GraalCompiler.emitLIR(GraalCompiler.java:250) >>> at >> com.oracle.graal.compiler.GraalCompiler.emitBackEnd(GraalCompiler.java:1 >> 98) >>> at >> com.oracle.graal.compiler.GraalCompiler.compileGraph(GraalCompiler.java: >> 141) >>> at >> com.oracle.graal.hotspot.CompilationTask.runCompilation(CompilationTask. >> java:332) >>> at >> com.oracle.graal.hotspot.CompilationTask.run(CompilationTask.java:176) >>> at >> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.jav >> a:1142) >>> at >> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.ja >> va:617) >>> at java.lang.Thread.run(Thread.java:744) >>> at >>> com.oracle.graal.compiler.CompilerThread.run(CompilerThread.java:48) >>> Caused by: java.lang.AssertionError >>> at >> com.oracle.graal.lir.LIRValueUtil.isVariable(LIRValueUtil.java:30) >>> at com.oracle.graal.lir.LIRVerifier.allowed(LIRVerifier.java:237) >>> at >> com.oracle.graal.lir.LIRVerifier.access$000(LIRVerifier.java:39) >>> at >> com.oracle.graal.lir.LIRVerifier$1.doValue(LIRVerifier.java:70) >>> at >> com.oracle.graal.lir.LIRIntrospection.forEach(LIRIntrospection.java:132) >>> at >> com.oracle.graal.lir.LIRInstructionClass.forEachTemp(LIRInstructionClass >> .java:274) >>> at >> com.oracle.graal.lir.LIRInstruction.forEachTemp(LIRInstruction.java:267) >>> at com.oracle.graal.lir.LIRVerifier.verify(LIRVerifier.java:77) >>> at >> com.oracle.graal.lir.gen.LIRGenerator.append(LIRGenerator.java:265) >>> at >> com.oracle.graal.hotspot.amd64.AMD64HotSpotLIRGenerator.append(AMD64HotS >> potLIRGenerator.java:127) >>> at >> com.oracle.graal.compiler.amd64.AMD64LIRGenerator.emitArrayEquals(AMD64L >> IRGenerator.java:1065) >>> at >> com.oracle.graal.compiler.gen.NodeLIRBuilder.emitArrayEquals(NodeLIRBuil >> der.java:651) >>> at >> com.oracle.graal.replacements.nodes.ArrayEqualsNode.generate(ArrayEquals >> Node.java:134) >>> at >> com.oracle.graal.compiler.gen.NodeLIRBuilder.emitNode(NodeLIRBuilder.jav >> a:358) >>> at >> com.oracle.graal.compiler.gen.NodeLIRBuilder.doRoot(NodeLIRBuilder.java: >> 349) >>> at >> com.oracle.graal.compiler.gen.NodeLIRBuilder.doBlock(NodeLIRBuilder.java >> :264) >>> ... 10 more >>> Traceback (most recent call last): >>> File "/home/tom/graal/mx/mx_graal.py", line 1341, in gate >>> gate_body(args, tasks) >>> File "/home/tom/graal/mx/mx_graal.py", line 1179, in _basic_gate_body >>> vm(['-esa', '-XX:-TieredCompilation', '-version']) File >>> "/home/tom/graal/mx/mx_graal.py", line 890, in vm >>> return mx.run(pfx_ + [exe_, '-' + vm_] + args_, >>> nonZeroIsFatal=nonZeroIsFatal, out=out, err=err, cwd=cwd, >> timeout=timeout) File "/home/tom/graal/mxtool/mx.py", line 1555, in run >>> abort(retcode) >>> File "/home/tom/graal/mxtool/mx.py", line 1877, in abort >>> raise SystemExit(codeOrMessage) >>> SystemExit: 255 >>> gate: 03 Jun 2014 09:10:36: ABORT: Gate [0:16:27.012194] >>> >>> >>>> -----Original Message----- >>>> From: Doug Simon [mailto:doug.simon at oracle.com] >>>> Sent: Tuesday, June 03, 2014 9:02 AM >>>> To: Deneau, Tom >>>> Cc: Gilles Duboscq; graal-dev at openjdk.java.net >>>> Subject: Re: mx gate fail >>>> >>>> >>>> On Jun 3, 2014, at 3:55 PM, Deneau, Tom wrote: >>>> >>>>> Gilles -- >>>>> >>>>> Hmm, I was building with a JDK built from the sumatra-dev project, >>>> which is only a slight modification of Java 8. >>>>> Are you saying this depends on libraries that cannot be build from >>>>> the >>>> openjdk? >>>> >>>> Yes. The Java Flight Recorder library is not part of OpenJDK, only >>>> Oracle JDK. >>>> >>>> I'll make this work with the project canonicalizer. >>>> >>>> -Doug >>>> >>>>>> -----Original Message----- >>>>>> From: gilwooden at gmail.com [mailto:gilwooden at gmail.com] On Behalf Of >>>>>> Gilles Duboscq >>>>>> Sent: Tuesday, June 03, 2014 8:52 AM >>>>>> To: Deneau, Tom >>>>>> Cc: graal-dev at openjdk.java.net >>>>>> Subject: Re: mx gate fail >>>>>> >>>>>> On Tue, Jun 3, 2014 at 3:31 PM, Tom Deneau >>>> wrote: >>>>>>> Running mx gate, I get the following failure. >>>>>>> Strange because I do see the com.oracle.graal.hotspot.jfr >> directory. >>>>>> >>>>>> The project is probably "hidden" because you're not building from >>>>>> an Oracle JDK: this project depends on JDK libraries that are only >>>>>> found in Oracle JDKs. When these libraries are not present the >>>>>> project is "hidden" so that it doesn't get in the way but it seems >>>>>> it doesn't hide so well from the project canonicalizer. >>>>>> >>>>>> -Gilles >>>>>> >>>>>>> >>>>>>> -- Tom >>>>>>> >>>>>>> ... >>>>>>> modified >>>>>>> /home/tom/graal/graal/com.oracle.graal.api.replacements/com.oracle >>>>>>> .g >>>>>>> ra >>>>>>> al.api.replacements.iml modified >>>>>>> >> /home/tom/graal/graal/com.oracle.graal.hotspot.jdk8.test/com.oracle. >>>>>>> gr >>>>>>> aal.hotspot.jdk8.test.iml modified >>>>>>> /home/tom/graal/graal/com.oracle.graal.api.meta/com.oracle.graal.a >>>>>>> pi >>>>>>> .m >>>>>>> eta.iml modified >>>>>>> >>>>>> /home/tom/graal/graal/com.oracle.graal.replacements.test/com.oracle >>>>>> .g >>>>>> raa >>>>>> l.replacements.test.iml >>>>>>> gate: 03 Jun 2014 08:28:08: END: IDEConfigCheck [0:00:43.867074] >>>>>>> gate: 03 Jun 2014 08:28:08: BEGIN: Canonicalization Check >>>>>>> 03 Jun 2014 08:28:08 - Ensuring mx/projects files are >>>> canonicalized... >>>>>>> Traceback (most recent call last): >>>>>>> File "/home/tom/graal/mx/mx_graal.py", line 1308, in gate >>>>>>> if mx.canonicalizeprojects([]) != 0: >>>>>>> File "/home/tom/graal/mxtool/mx.py", line 2657, in >>>>>> canonicalizeprojects >>>>>>> p = project(m.group(1)) >>>>>>> File "/home/tom/graal/mxtool/mx.py", line 1178, in project >>>>>>> abort('project named ' + name + ' not found') File >>>>>>> "/home/tom/graal/mxtool/mx.py", line 1877, in abort >>>>>>> raise SystemExit(codeOrMessage) >>>>>>> SystemExit: project named com.oracle.graal.hotspot.jfr not found >>>>>>> gate: 03 Jun 2014 08:28:08: ABORT: Gate [0:00:43.969592] project >>>>>>> named com.oracle.graal.hotspot.jfr not found >>> > From doug.simon at oracle.com Tue Jun 3 20:13:59 2014 From: doug.simon at oracle.com (Doug Simon) Date: Tue, 3 Jun 2014 22:13:59 +0200 Subject: mx gate fail In-Reply-To: References: <8FCD86BF-9E0A-4B11-ABD4-5CCF7F130DED@oracle.com> Message-ID: <64C7E13C-9F4B-4F9C-80EB-EC346D4B8E81@oracle.com> I?ll push a fix for this. On Jun 3, 2014, at 9:21 PM, Doug Simon wrote: > I think the problematic code is this: > > public AMD64ArrayEqualsOp(LIRGeneratorTool tool, Kind kind, Value result, Value array1, Value array2, Value length) { > > ... > > // We only need the vector temporaries if we generate SSE code. > if (supportsSSE41(tool.target())) { > this.vectorTemp1 = tool.newVariable(Kind.Double); > this.vectorTemp2 = tool.newVariable(Kind.Double); > } > } > > I?m guessing you are on a machine that does not support SSE4.1. > > -Doug > > On Jun 3, 2014, at 7:06 PM, Deneau, Tom wrote: > >> Doug -- >> >> It reproduces on default tip. >> I am using jdk8-b132. >> >> -- Tom >> >> >>> -----Original Message----- >>> From: Doug Simon [mailto:doug.simon at oracle.com] >>> Sent: Tuesday, June 03, 2014 10:53 AM >>> To: Deneau, Tom >>> Cc: Gilles Duboscq; graal-dev at openjdk.java.net >>> Subject: Re: mx gate fail >>> >>> Strange - that kind of thing should be caught in the gate. Can you >>> reproduce it reliably? >>> >>> -Doug >>> >>> On Jun 3, 2014, at 4:33 PM, Deneau, Tom wrote: >>> >>>> OK using oracle jdk8 release now, >>>> I get this error >>>> >>>> gate: 03 Jun 2014 09:10:17: END: BuildHotSpotGraal: >>> fastdebug,product [0:13:14.736611] >>>> gate: 03 Jun 2014 09:10:17: BEGIN: >>>> BootstrapWithSystemAssertions:fastdebug >>>> Bootstrapping Graal[thread:8] scope: >>>> [thread:8] scope: Compiling >>>> [thread:8] scope: Compiling.GraalCompiler >>>> [thread:8] scope: Compiling.GraalCompiler.BackEnd >>>> [thread:8] scope: Compiling.GraalCompiler.BackEnd.LIRGen >>>> [thread:8] scope: >>> Compiling.GraalCompiler.BackEnd.LIRGen.InterceptException >>>> Exception occurred in scope: >>> Compiling.GraalCompiler.BackEnd.LIRGen.InterceptException >>>> Context obj com.oracle.graal.graph.GraalGraphInternalError: >>> java.lang.AssertionError >>>> at node: 26|ArrayEquals >>>> Context obj >>> com.oracle.graal.hotspot.amd64.AMD64HotSpotLIRGenerator at 434fb9bb >>>> Context obj com.oracle.graal.lir.LIR at 464c71b3 >>>> Use -G:+DumpOnError to enable dumping of graphs on this error >>>> Context obj >>> StructuredGraph:123{HotSpotMethod>> Object)>} >>>> Use -G:+DumpOnError to enable dumping of graphs on this error >>>> Context obj >>> com.oracle.graal.hotspot.amd64.AMD64HotSpotCodeCacheProvider at bce7fd0 >>>> Context obj DebugDumpScope[53] >>>> com.oracle.graal.graph.GraalGraphInternalError: >>> java.lang.AssertionError >>>> at node: 26|ArrayEquals >>>> at >>> com.oracle.graal.compiler.gen.NodeLIRBuilder.doBlock(NodeLIRBuilder.java >>> :268) >>>> at >>> com.oracle.graal.compiler.GraalCompiler.emitBlock(GraalCompiler.java:216 >>> ) >>>> at >>> com.oracle.graal.compiler.GraalCompiler.emitLIR(GraalCompiler.java:250) >>>> at >>> com.oracle.graal.compiler.GraalCompiler.emitBackEnd(GraalCompiler.java:1 >>> 98) >>>> at >>> com.oracle.graal.compiler.GraalCompiler.compileGraph(GraalCompiler.java: >>> 141) >>>> at >>> com.oracle.graal.hotspot.CompilationTask.runCompilation(CompilationTask. >>> java:332) >>>> at >>> com.oracle.graal.hotspot.CompilationTask.run(CompilationTask.java:176) >>>> at >>> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.jav >>> a:1142) >>>> at >>> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.ja >>> va:617) >>>> at java.lang.Thread.run(Thread.java:744) >>>> at >>>> com.oracle.graal.compiler.CompilerThread.run(CompilerThread.java:48) >>>> Caused by: java.lang.AssertionError >>>> at >>> com.oracle.graal.lir.LIRValueUtil.isVariable(LIRValueUtil.java:30) >>>> at com.oracle.graal.lir.LIRVerifier.allowed(LIRVerifier.java:237) >>>> at >>> com.oracle.graal.lir.LIRVerifier.access$000(LIRVerifier.java:39) >>>> at >>> com.oracle.graal.lir.LIRVerifier$1.doValue(LIRVerifier.java:70) >>>> at >>> com.oracle.graal.lir.LIRIntrospection.forEach(LIRIntrospection.java:132) >>>> at >>> com.oracle.graal.lir.LIRInstructionClass.forEachTemp(LIRInstructionClass >>> .java:274) >>>> at >>> com.oracle.graal.lir.LIRInstruction.forEachTemp(LIRInstruction.java:267) >>>> at com.oracle.graal.lir.LIRVerifier.verify(LIRVerifier.java:77) >>>> at >>> com.oracle.graal.lir.gen.LIRGenerator.append(LIRGenerator.java:265) >>>> at >>> com.oracle.graal.hotspot.amd64.AMD64HotSpotLIRGenerator.append(AMD64HotS >>> potLIRGenerator.java:127) >>>> at >>> com.oracle.graal.compiler.amd64.AMD64LIRGenerator.emitArrayEquals(AMD64L >>> IRGenerator.java:1065) >>>> at >>> com.oracle.graal.compiler.gen.NodeLIRBuilder.emitArrayEquals(NodeLIRBuil >>> der.java:651) >>>> at >>> com.oracle.graal.replacements.nodes.ArrayEqualsNode.generate(ArrayEquals >>> Node.java:134) >>>> at >>> com.oracle.graal.compiler.gen.NodeLIRBuilder.emitNode(NodeLIRBuilder.jav >>> a:358) >>>> at >>> com.oracle.graal.compiler.gen.NodeLIRBuilder.doRoot(NodeLIRBuilder.java: >>> 349) >>>> at >>> com.oracle.graal.compiler.gen.NodeLIRBuilder.doBlock(NodeLIRBuilder.java >>> :264) >>>> ... 10 more >>>> Traceback (most recent call last): >>>> File "/home/tom/graal/mx/mx_graal.py", line 1341, in gate >>>> gate_body(args, tasks) >>>> File "/home/tom/graal/mx/mx_graal.py", line 1179, in _basic_gate_body >>>> vm(['-esa', '-XX:-TieredCompilation', '-version']) File >>>> "/home/tom/graal/mx/mx_graal.py", line 890, in vm >>>> return mx.run(pfx_ + [exe_, '-' + vm_] + args_, >>>> nonZeroIsFatal=nonZeroIsFatal, out=out, err=err, cwd=cwd, >>> timeout=timeout) File "/home/tom/graal/mxtool/mx.py", line 1555, in run >>>> abort(retcode) >>>> File "/home/tom/graal/mxtool/mx.py", line 1877, in abort >>>> raise SystemExit(codeOrMessage) >>>> SystemExit: 255 >>>> gate: 03 Jun 2014 09:10:36: ABORT: Gate [0:16:27.012194] >>>> >>>> >>>>> -----Original Message----- >>>>> From: Doug Simon [mailto:doug.simon at oracle.com] >>>>> Sent: Tuesday, June 03, 2014 9:02 AM >>>>> To: Deneau, Tom >>>>> Cc: Gilles Duboscq; graal-dev at openjdk.java.net >>>>> Subject: Re: mx gate fail >>>>> >>>>> >>>>> On Jun 3, 2014, at 3:55 PM, Deneau, Tom wrote: >>>>> >>>>>> Gilles -- >>>>>> >>>>>> Hmm, I was building with a JDK built from the sumatra-dev project, >>>>> which is only a slight modification of Java 8. >>>>>> Are you saying this depends on libraries that cannot be build from >>>>>> the >>>>> openjdk? >>>>> >>>>> Yes. The Java Flight Recorder library is not part of OpenJDK, only >>>>> Oracle JDK. >>>>> >>>>> I'll make this work with the project canonicalizer. >>>>> >>>>> -Doug >>>>> >>>>>>> -----Original Message----- >>>>>>> From: gilwooden at gmail.com [mailto:gilwooden at gmail.com] On Behalf Of >>>>>>> Gilles Duboscq >>>>>>> Sent: Tuesday, June 03, 2014 8:52 AM >>>>>>> To: Deneau, Tom >>>>>>> Cc: graal-dev at openjdk.java.net >>>>>>> Subject: Re: mx gate fail >>>>>>> >>>>>>> On Tue, Jun 3, 2014 at 3:31 PM, Tom Deneau >>>>> wrote: >>>>>>>> Running mx gate, I get the following failure. >>>>>>>> Strange because I do see the com.oracle.graal.hotspot.jfr >>> directory. >>>>>>> >>>>>>> The project is probably "hidden" because you're not building from >>>>>>> an Oracle JDK: this project depends on JDK libraries that are only >>>>>>> found in Oracle JDKs. When these libraries are not present the >>>>>>> project is "hidden" so that it doesn't get in the way but it seems >>>>>>> it doesn't hide so well from the project canonicalizer. >>>>>>> >>>>>>> -Gilles >>>>>>> >>>>>>>> >>>>>>>> -- Tom >>>>>>>> >>>>>>>> ... >>>>>>>> modified >>>>>>>> /home/tom/graal/graal/com.oracle.graal.api.replacements/com.oracle >>>>>>>> .g >>>>>>>> ra >>>>>>>> al.api.replacements.iml modified >>>>>>>> >>> /home/tom/graal/graal/com.oracle.graal.hotspot.jdk8.test/com.oracle. >>>>>>>> gr >>>>>>>> aal.hotspot.jdk8.test.iml modified >>>>>>>> /home/tom/graal/graal/com.oracle.graal.api.meta/com.oracle.graal.a >>>>>>>> pi >>>>>>>> .m >>>>>>>> eta.iml modified >>>>>>>> >>>>>>> /home/tom/graal/graal/com.oracle.graal.replacements.test/com.oracle >>>>>>> .g >>>>>>> raa >>>>>>> l.replacements.test.iml >>>>>>>> gate: 03 Jun 2014 08:28:08: END: IDEConfigCheck [0:00:43.867074] >>>>>>>> gate: 03 Jun 2014 08:28:08: BEGIN: Canonicalization Check >>>>>>>> 03 Jun 2014 08:28:08 - Ensuring mx/projects files are >>>>> canonicalized... >>>>>>>> Traceback (most recent call last): >>>>>>>> File "/home/tom/graal/mx/mx_graal.py", line 1308, in gate >>>>>>>> if mx.canonicalizeprojects([]) != 0: >>>>>>>> File "/home/tom/graal/mxtool/mx.py", line 2657, in >>>>>>> canonicalizeprojects >>>>>>>> p = project(m.group(1)) >>>>>>>> File "/home/tom/graal/mxtool/mx.py", line 1178, in project >>>>>>>> abort('project named ' + name + ' not found') File >>>>>>>> "/home/tom/graal/mxtool/mx.py", line 1877, in abort >>>>>>>> raise SystemExit(codeOrMessage) >>>>>>>> SystemExit: project named com.oracle.graal.hotspot.jfr not found >>>>>>>> gate: 03 Jun 2014 08:28:08: ABORT: Gate [0:00:43.969592] project >>>>>>>> named com.oracle.graal.hotspot.jfr not found >>>> >> > From tom.deneau at amd.com Tue Jun 3 20:22:24 2014 From: tom.deneau at amd.com (Deneau, Tom) Date: Tue, 3 Jun 2014 20:22:24 +0000 Subject: mx gate fail In-Reply-To: References: <8FCD86BF-9E0A-4B11-ABD4-5CCF7F130DED@oracle.com> Message-ID: Yes, it does seem that the machine I am on does not support SSE4.1. -- Tom > -----Original Message----- > From: Doug Simon [mailto:doug.simon at oracle.com] > Sent: Tuesday, June 03, 2014 2:22 PM > To: Deneau, Tom > Cc: Christian Thalinger; graal-dev at openjdk.java.net > Subject: Re: mx gate fail > > I think the problematic code is this: > > public AMD64ArrayEqualsOp(LIRGeneratorTool tool, Kind kind, Value > result, Value array1, Value array2, Value length) { > > ... > > // We only need the vector temporaries if we generate SSE code. > if (supportsSSE41(tool.target())) { > this.vectorTemp1 = tool.newVariable(Kind.Double); > this.vectorTemp2 = tool.newVariable(Kind.Double); > } > } > > I'm guessing you are on a machine that does not support SSE4.1. > > -Doug > > On Jun 3, 2014, at 7:06 PM, Deneau, Tom wrote: > > > Doug -- > > > > It reproduces on default tip. > > I am using jdk8-b132. > > > > -- Tom > > > > > >> -----Original Message----- > >> From: Doug Simon [mailto:doug.simon at oracle.com] > >> Sent: Tuesday, June 03, 2014 10:53 AM > >> To: Deneau, Tom > >> Cc: Gilles Duboscq; graal-dev at openjdk.java.net > >> Subject: Re: mx gate fail > >> > >> Strange - that kind of thing should be caught in the gate. Can you > >> reproduce it reliably? > >> > >> -Doug > >> > >> On Jun 3, 2014, at 4:33 PM, Deneau, Tom wrote: > >> > >>> OK using oracle jdk8 release now, > >>> I get this error > >>> > >>> gate: 03 Jun 2014 09:10:17: END: BuildHotSpotGraal: > >> fastdebug,product [0:13:14.736611] > >>> gate: 03 Jun 2014 09:10:17: BEGIN: > >>> BootstrapWithSystemAssertions:fastdebug > >>> Bootstrapping Graal[thread:8] scope: > >>> [thread:8] scope: Compiling > >>> [thread:8] scope: Compiling.GraalCompiler > >>> [thread:8] scope: Compiling.GraalCompiler.BackEnd > >>> [thread:8] scope: Compiling.GraalCompiler.BackEnd.LIRGen > >>> [thread:8] scope: > >> Compiling.GraalCompiler.BackEnd.LIRGen.InterceptException > >>> Exception occurred in scope: > >> Compiling.GraalCompiler.BackEnd.LIRGen.InterceptException > >>> Context obj com.oracle.graal.graph.GraalGraphInternalError: > >> java.lang.AssertionError > >>> at node: 26|ArrayEquals > >>> Context obj > >> com.oracle.graal.hotspot.amd64.AMD64HotSpotLIRGenerator at 434fb9bb > >>> Context obj com.oracle.graal.lir.LIR at 464c71b3 > >>> Use -G:+DumpOnError to enable dumping of graphs on this > error > >>> Context obj > >> StructuredGraph:123{HotSpotMethod >> Object)>} > >>> Use -G:+DumpOnError to enable dumping of graphs on this > error > >>> Context obj > >> com.oracle.graal.hotspot.amd64.AMD64HotSpotCodeCacheProvider at bce7fd0 > >>> Context obj DebugDumpScope[53] > >>> com.oracle.graal.graph.GraalGraphInternalError: > >> java.lang.AssertionError > >>> at node: 26|ArrayEquals > >>> at > >> com.oracle.graal.compiler.gen.NodeLIRBuilder.doBlock(NodeLIRBuilder.j > >> ava > >> :268) > >>> at > >> com.oracle.graal.compiler.GraalCompiler.emitBlock(GraalCompiler.java: > >> 216 > >> ) > >>> at > >> com.oracle.graal.compiler.GraalCompiler.emitLIR(GraalCompiler.java:25 > >> 0) > >>> at > >> com.oracle.graal.compiler.GraalCompiler.emitBackEnd(GraalCompiler.jav > >> a:1 > >> 98) > >>> at > >> > com.oracle.graal.compiler.GraalCompiler.compileGraph(GraalCompiler.java: > >> 141) > >>> at > >> > com.oracle.graal.hotspot.CompilationTask.runCompilation(CompilationTask. > >> java:332) > >>> at > >> com.oracle.graal.hotspot.CompilationTask.run(CompilationTask.java:176 > >> ) > >>> at > >> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor. > >> jav > >> a:1142) > >>> at > >> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor > >> .ja > >> va:617) > >>> at java.lang.Thread.run(Thread.java:744) > >>> at > >>> com.oracle.graal.compiler.CompilerThread.run(CompilerThread.java:48) > >>> Caused by: java.lang.AssertionError > >>> at > >> com.oracle.graal.lir.LIRValueUtil.isVariable(LIRValueUtil.java:30) > >>> at com.oracle.graal.lir.LIRVerifier.allowed(LIRVerifier.java:237) > >>> at > >> com.oracle.graal.lir.LIRVerifier.access$000(LIRVerifier.java:39) > >>> at > >> com.oracle.graal.lir.LIRVerifier$1.doValue(LIRVerifier.java:70) > >>> at > >> com.oracle.graal.lir.LIRIntrospection.forEach(LIRIntrospection.java:1 > >> 32) > >>> at > >> com.oracle.graal.lir.LIRInstructionClass.forEachTemp(LIRInstructionCl > >> ass > >> .java:274) > >>> at > >> com.oracle.graal.lir.LIRInstruction.forEachTemp(LIRInstruction.java:2 > >> 67) > >>> at com.oracle.graal.lir.LIRVerifier.verify(LIRVerifier.java:77) > >>> at > >> com.oracle.graal.lir.gen.LIRGenerator.append(LIRGenerator.java:265) > >>> at > >> com.oracle.graal.hotspot.amd64.AMD64HotSpotLIRGenerator.append(AMD64H > >> otS > >> potLIRGenerator.java:127) > >>> at > >> com.oracle.graal.compiler.amd64.AMD64LIRGenerator.emitArrayEquals(AMD > >> 64L > >> IRGenerator.java:1065) > >>> at > >> com.oracle.graal.compiler.gen.NodeLIRBuilder.emitArrayEquals(NodeLIRB > >> uil > >> der.java:651) > >>> at > >> com.oracle.graal.replacements.nodes.ArrayEqualsNode.generate(ArrayEqu > >> als > >> Node.java:134) > >>> at > >> com.oracle.graal.compiler.gen.NodeLIRBuilder.emitNode(NodeLIRBuilder. > >> jav > >> a:358) > >>> at > >> > com.oracle.graal.compiler.gen.NodeLIRBuilder.doRoot(NodeLIRBuilder.java: > >> 349) > >>> at > >> com.oracle.graal.compiler.gen.NodeLIRBuilder.doBlock(NodeLIRBuilder.j > >> ava > >> :264) > >>> ... 10 more > >>> Traceback (most recent call last): > >>> File "/home/tom/graal/mx/mx_graal.py", line 1341, in gate > >>> gate_body(args, tasks) > >>> File "/home/tom/graal/mx/mx_graal.py", line 1179, in > _basic_gate_body > >>> vm(['-esa', '-XX:-TieredCompilation', '-version']) File > >>> "/home/tom/graal/mx/mx_graal.py", line 890, in vm > >>> return mx.run(pfx_ + [exe_, '-' + vm_] + args_, > >>> nonZeroIsFatal=nonZeroIsFatal, out=out, err=err, cwd=cwd, > >> timeout=timeout) File "/home/tom/graal/mxtool/mx.py", line 1555, in > >> run > >>> abort(retcode) > >>> File "/home/tom/graal/mxtool/mx.py", line 1877, in abort > >>> raise SystemExit(codeOrMessage) > >>> SystemExit: 255 > >>> gate: 03 Jun 2014 09:10:36: ABORT: Gate [0:16:27.012194] > >>> > >>> > >>>> -----Original Message----- > >>>> From: Doug Simon [mailto:doug.simon at oracle.com] > >>>> Sent: Tuesday, June 03, 2014 9:02 AM > >>>> To: Deneau, Tom > >>>> Cc: Gilles Duboscq; graal-dev at openjdk.java.net > >>>> Subject: Re: mx gate fail > >>>> > >>>> > >>>> On Jun 3, 2014, at 3:55 PM, Deneau, Tom wrote: > >>>> > >>>>> Gilles -- > >>>>> > >>>>> Hmm, I was building with a JDK built from the sumatra-dev project, > >>>> which is only a slight modification of Java 8. > >>>>> Are you saying this depends on libraries that cannot be build from > >>>>> the > >>>> openjdk? > >>>> > >>>> Yes. The Java Flight Recorder library is not part of OpenJDK, only > >>>> Oracle JDK. > >>>> > >>>> I'll make this work with the project canonicalizer. > >>>> > >>>> -Doug > >>>> > >>>>>> -----Original Message----- > >>>>>> From: gilwooden at gmail.com [mailto:gilwooden at gmail.com] On Behalf > >>>>>> Of Gilles Duboscq > >>>>>> Sent: Tuesday, June 03, 2014 8:52 AM > >>>>>> To: Deneau, Tom > >>>>>> Cc: graal-dev at openjdk.java.net > >>>>>> Subject: Re: mx gate fail > >>>>>> > >>>>>> On Tue, Jun 3, 2014 at 3:31 PM, Tom Deneau > >>>> wrote: > >>>>>>> Running mx gate, I get the following failure. > >>>>>>> Strange because I do see the com.oracle.graal.hotspot.jfr > >> directory. > >>>>>> > >>>>>> The project is probably "hidden" because you're not building from > >>>>>> an Oracle JDK: this project depends on JDK libraries that are > >>>>>> only found in Oracle JDKs. When these libraries are not present > >>>>>> the project is "hidden" so that it doesn't get in the way but it > >>>>>> seems it doesn't hide so well from the project canonicalizer. > >>>>>> > >>>>>> -Gilles > >>>>>> > >>>>>>> > >>>>>>> -- Tom > >>>>>>> > >>>>>>> ... > >>>>>>> modified > >>>>>>> /home/tom/graal/graal/com.oracle.graal.api.replacements/com.orac > >>>>>>> le > >>>>>>> .g > >>>>>>> ra > >>>>>>> al.api.replacements.iml modified > >>>>>>> > >> /home/tom/graal/graal/com.oracle.graal.hotspot.jdk8.test/com.oracle. > >>>>>>> gr > >>>>>>> aal.hotspot.jdk8.test.iml modified > >>>>>>> /home/tom/graal/graal/com.oracle.graal.api.meta/com.oracle.graal > >>>>>>> .a > >>>>>>> pi > >>>>>>> .m > >>>>>>> eta.iml modified > >>>>>>> > >>>>>> /home/tom/graal/graal/com.oracle.graal.replacements.test/com.orac > >>>>>> le > >>>>>> .g > >>>>>> raa > >>>>>> l.replacements.test.iml > >>>>>>> gate: 03 Jun 2014 08:28:08: END: IDEConfigCheck > [0:00:43.867074] > >>>>>>> gate: 03 Jun 2014 08:28:08: BEGIN: Canonicalization Check > >>>>>>> 03 Jun 2014 08:28:08 - Ensuring mx/projects files are > >>>> canonicalized... > >>>>>>> Traceback (most recent call last): > >>>>>>> File "/home/tom/graal/mx/mx_graal.py", line 1308, in gate if > >>>>>>> mx.canonicalizeprojects([]) != 0: > >>>>>>> File "/home/tom/graal/mxtool/mx.py", line 2657, in > >>>>>> canonicalizeprojects > >>>>>>> p = project(m.group(1)) > >>>>>>> File "/home/tom/graal/mxtool/mx.py", line 1178, in project > >>>>>>> abort('project named ' + name + ' not found') File > >>>>>>> "/home/tom/graal/mxtool/mx.py", line 1877, in abort raise > >>>>>>> SystemExit(codeOrMessage) > >>>>>>> SystemExit: project named com.oracle.graal.hotspot.jfr not found > >>>>>>> gate: 03 Jun 2014 08:28:08: ABORT: Gate [0:00:43.969592] project > >>>>>>> named com.oracle.graal.hotspot.jfr not found > >>> > > From tom.deneau at amd.com Tue Jun 3 21:27:22 2014 From: tom.deneau at amd.com (Deneau, Tom) Date: Tue, 3 Jun 2014 21:27:22 +0000 Subject: webrev to extend hsail allocation to allow gpu to refill tlab Message-ID: I have placed a webrev up at http://cr.openjdk.java.net/~tdeneau/graal-webrevs/webrev-hsail-refill-tlab-gpu which we would like to get checked into the graal trunk. This webrev extends the existing hsail heap allocation logic. In the existing logic, when a workitem cannot allocate from the current tlab, it just deoptimizes. In this webrev, we add logic to allocate a new tlab from the gpu. The algorithm must deal with the fact that multiple hsa workitems can share a single tlab, and so multiple workitems can "overflow". A workitem can tell if it is the "first overflower" and the first overflower is charged with getting a new tlab while the other workitems wait for the new tlab to be announced. Workitems access a tlab thru a fixed register (sort of like a thread register) which instead of pointing to a donor thread now points to a HSAILTlabInfo structure, which is sort of a subset of a full tlab struct, containing just the fields that we would actually use on the gpu. struct HSAILTlabInfo { HeapWord * _start; // normal vm tlab fields, start, top, end, etc. HeapWord * _top; HeapWord * _end; // additional data not in a normal tlab HeapWord * _lastGoodTop; // first overflower records this JavaThread * _donor_thread; // donor thread associated with this tlabInfo } The first overflower grabs a new tlabInfo structure and allocates a new tlab (using edenAllocate) and "publishes" the new tlabInfo for other workitems to start using. See the routine called allocateFromTlabSlowPath in HSAILNewObjectSnippets. Eventually when hsail function calls are supported, this slow path will not be inlined but will be called as a stub. Other changes: * the allocation-related logic was removed from gpu_hsail.cpp into gpu_hsail_tlab.hpp. The HSAILHotSpotNmethod now keeps track of whether a kernel uses allocation and avoids this logic if it does not. * Before the kernel runs, the donor thread tlabs are used to set up the initial tlabInfo records, and a tlab allocation is done here if the donor thread tlab is empty. * When kernel is finished running, the cpu side will see a list of one or more HSAILTlabInfos and basically postprocesses these, fixing up any overflows and making them parsable and copying them back to the appropriate donor thread as needed. * the inter-workitem communication required the use of the hsail instructions for load_acquire and store_release from the snippets. The HSAILDirectLoadAcquireNode and HSAILDirectStoreReleaseNode with associated NodeIntrinsics were created to handle this. A node for creating a workitemabsid instruction was also created, it is not used in the algorithm as such but was useful for adding debug traces. * In HSAILHotSpotBackend, the logic to decide whether a kernel uses allocation or not was made more precise. (This flag is also made available at execute time.) There were several atomic_add related tests were falsely being marked as requiring HSAILAllocation and thus HSAILDeoptimization support. This marking was removed. -- Tom Deneau From doug.simon at oracle.com Wed Jun 4 01:00:06 2014 From: doug.simon at oracle.com (doug.simon at oracle.com) Date: Wed, 04 Jun 2014 01:00:06 +0000 Subject: hg: graal/graal: 10 new changesets Message-ID: <201406040100.s5410NQJ008794@aojmv0008> Changeset: c55559b7824d Author: Lukas Stadler Date: 2014-06-03 10:04 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/c55559b7824d fix for NodeBitMap.grow ! graal/com.oracle.graal.graph/src/com/oracle/graal/graph/NodeBitMap.java Changeset: c60362c5150f Author: Roland Schatz Date: 2014-06-03 10:52 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/c60362c5150f mx: Use -XX:-DisableExplicitGC when running unit tests with --gc-after-test. ! mx/mx_graal.py Changeset: 83433cf49019 Author: Roland Schatz Date: 2014-06-03 11:01 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/83433cf49019 Fix incorrect null check in oop compression. ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/nodes/CompressionNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/type/StampTool.java Changeset: f5ae86b125fd Author: Josef Eisl Date: 2014-06-03 14:32 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/f5ae86b125fd LSRA optimization: skip walking to blocks with more than one predecessor. ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/alloc/OptimizingLinearScanWalker.java Changeset: dea42a47850e Author: Doug Simon Date: 2014-06-03 16:29 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/dea42a47850e made canonicalizeprojects handle projects depending on a missing jrelibrary ! mxtool/mx.py Changeset: 66a9286203a2 Author: Doug Simon Date: 2014-06-03 11:51 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/66a9286203a2 decoupled Graal runtime initialization and Graal compilation queue initialization ! graal/com.oracle.graal.hotspot.amd64/src/com/oracle/graal/hotspot/amd64/AMD64HotSpotBackendFactory.java ! graal/com.oracle.graal.hotspot.ptx/src/com/oracle/graal/hotspot/ptx/PTXHotSpotBackendFactory.java ! graal/com.oracle.graal.hotspot.sourcegen/src/com/oracle/graal/hotspot/sourcegen/GenGraalRuntimeInlineHpp.java + graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/CompilationQueue.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/CompilationTask.java + graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/DebugValuesPrinter.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/HotSpotGraalRuntime.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/HotSpotHostBackend.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/HotSpotOptions.java + graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/InitTimer.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/bridge/CompilerToVM.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/bridge/CompilerToVMImpl.java - graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/bridge/VMToCompiler.java - graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/bridge/VMToCompilerImpl.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/logging/Logger.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/calc/FloatEqualsNode.java ! src/gpu/hsail/vm/gpu_hsail.cpp ! src/share/vm/classfile/systemDictionary.hpp ! src/share/vm/classfile/vmSymbols.hpp ! src/share/vm/compiler/abstractCompiler.hpp ! src/share/vm/compiler/compileBroker.cpp ! src/share/vm/compiler/compileBroker.hpp ! src/share/vm/graal/graalCompiler.cpp ! src/share/vm/graal/graalCompiler.hpp ! src/share/vm/graal/graalCompilerToVM.cpp ! src/share/vm/graal/graalRuntime.cpp ! src/share/vm/graal/graalRuntime.hpp - src/share/vm/graal/graalVMToCompiler.cpp - src/share/vm/graal/graalVMToCompiler.hpp ! src/share/vm/oops/instanceKlass.cpp ! src/share/vm/prims/jni.cpp ! src/share/vm/prims/nativeLookup.cpp ! src/share/vm/runtime/java.cpp ! src/share/vm/runtime/thread.cpp ! src/share/vm/runtime/thread.hpp Changeset: 23ae0cbcb2ae Author: Doug Simon Date: 2014-06-03 17:11 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/23ae0cbcb2ae OptionProcessor needs to find the type parameter of an OptionValue field declaration ! graal/com.oracle.graal.options/src/com/oracle/graal/options/OptionProcessor.java Changeset: 76f40e11c820 Author: Doug Simon Date: 2014-06-03 17:13 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/76f40e11c820 refactored HotSpotGraalRuntime.LogFileOption to PrintStreamOption to workaround a javac bug as well as to clarify its design ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/CompilationQueue.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/HotSpotGraalRuntime.java + graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/PrintStreamOption.java Changeset: a831a16e52b4 Author: Doug Simon Date: 2014-06-03 17:14 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/a831a16e52b4 Merge. Changeset: effc7ef538f5 Author: Doug Simon Date: 2014-06-03 17:37 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/effc7ef538f5 fixed eclipseformat issue ! graal/com.oracle.graal.options/src/com/oracle/graal/options/OptionProcessor.java From tom.deneau at amd.com Wed Jun 4 12:28:38 2014 From: tom.deneau at amd.com (Deneau, Tom) Date: Wed, 4 Jun 2014 12:28:38 +0000 Subject: MethodSubstitution for JDK method Message-ID: Currently, the HSAIL backend codegen must inline everything and so can't handle recursive calls. Let's say we come upon some recursive method deep in the JDK. For example private static sun.misc.FDBigInteger.big5powRec(int p) And say we wanted to method-substitute a non-recursive implementation. But in our non-recursive implementation we would like to use some of the existing non-public methods or data structures in sun.misc.FDBigInteger. Is there a way to do that? -- Tom From doug.simon at oracle.com Wed Jun 4 13:38:36 2014 From: doug.simon at oracle.com (Doug Simon) Date: Wed, 4 Jun 2014 15:38:36 +0200 Subject: MethodSubstitution for JDK method In-Reply-To: References: Message-ID: On Jun 4, 2014, at 2:28 PM, Deneau, Tom wrote: > Currently, the HSAIL backend codegen must inline everything and so can't handle recursive calls. > Let's say we come upon some recursive method deep in the JDK. For example > private static sun.misc.FDBigInteger.big5powRec(int p) > > And say we wanted to method-substitute a non-recursive implementation. But in our non-recursive implementation we would like to use some of the existing non-public methods or data structures in sun.misc.FDBigInteger. > > Is there a way to do that? Not currently. In a previous eject (Maxine), we had support for aliasing hidden methods and fields and being able to access them via the aliases. Until we import such a mechanism into Graal, copy-and-paste is the only solution. -Doug From doug.simon at oracle.com Thu Jun 5 01:00:06 2014 From: doug.simon at oracle.com (doug.simon at oracle.com) Date: Thu, 05 Jun 2014 01:00:06 +0000 Subject: hg: graal/graal: 14 new changesets Message-ID: <201406050100.s5510RUc020582@aojmv0008> Changeset: dd11a7036c6e Author: Doug Simon Date: 2014-06-03 22:19 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/dd11a7036c6e LIR ops cannot have null @Temp fields ! graal/com.oracle.graal.lir.amd64/src/com/oracle/graal/lir/amd64/AMD64ArrayEqualsOp.java Changeset: 0497ead7ec50 Author: Roland Schatz Date: 2014-06-04 11:47 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/0497ead7ec50 Support null check directly on compressed oops. ! graal/com.oracle.graal.api.meta/src/com/oracle/graal/api/meta/Kind.java ! graal/com.oracle.graal.api.meta/src/com/oracle/graal/api/meta/PlatformKind.java ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/gen/NodeLIRBuilder.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/nodes/type/NarrowOopStamp.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/calc/IsNullNode.java Changeset: dd5c15b85f78 Author: Josef Eisl Date: 2014-06-04 12:02 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/dd5c15b85f78 Move dominates() and isDominatedBy() from Block to AbstractBlock and make them static methods. ! graal/com.oracle.graal.compiler.common/src/com/oracle/graal/compiler/common/cfg/AbstractBlock.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/cfg/Block.java ! graal/com.oracle.graal.phases/src/com/oracle/graal/phases/schedule/SchedulePhase.java Changeset: c1a47bf45b66 Author: Doug Simon Date: 2014-06-04 15:58 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/c1a47bf45b66 do not start/stop Graal compilation queue if -XX:-UseGraalCompilationQueue ! src/share/vm/graal/graalCompiler.cpp Changeset: 19a48d9834e1 Author: Doug Simon Date: 2014-06-04 15:58 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/19a48d9834e1 exclude CompilationTask from JaCoCo ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/CompilationTask.java Changeset: a1b9340534bf Author: Doug Simon Date: 2014-06-04 15:59 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/a1b9340534bf made UseGraalCompilationQueue false by default to see if perf. issue(s) still exist ! src/share/vm/graal/graalGlobals.hpp Changeset: 8d8c6a40d8e2 Author: Doug Simon Date: 2014-06-04 19:17 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/8d8c6a40d8e2 Backed out changeset: a1b9340534bf ! src/share/vm/graal/graalGlobals.hpp Changeset: 6a62ccbd1658 Author: Tom Rodriguez Date: 2014-06-04 13:20 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/6a62ccbd1658 add support for new G1 marking behavior ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/HotSpotVMConfig.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/HotSpotReplacementsUtil.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/WriteBarrierSnippets.java ! graal/com.oracle.graal.hotspotvmconfig/src/com/oracle/graal/hotspotvmconfig/HotSpotVMConfigProcessor.java Changeset: b15c20be0697 Author: Michael Van De Vanter Date: 2014-06-04 13:52 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/b15c20be0697 Truffle/API: new abstract TruffleScriptEngineFactory + graal/com.oracle.truffle.api/src/com/oracle/truffle/api/script/TruffleScriptEngineFactory.java Changeset: 9f25b70d6113 Author: Michael Van De Vanter Date: 2014-06-04 13:53 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/9f25b70d6113 Merge Changeset: 0926a952ba55 Author: Doug Simon Date: 2014-06-04 22:18 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/0926a952ba55 fixed crash when -XX:-TieredCompilation -XX:-UseGraalCompilationQueue is specified ! src/share/vm/runtime/compilationPolicy.cpp Changeset: 3f350b0d93c9 Author: Doug Simon Date: 2014-06-04 22:58 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/3f350b0d93c9 pass make variables on the command line instead of in environment variables to simplify running the make on the command line without mx ! mx/mx_graal.py Changeset: 774349ad0b03 Author: Doug Simon Date: 2014-06-04 23:07 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/774349ad0b03 fixed hang in non-COMPILERGRAAL builds when -Xcomp is specified ! src/share/vm/runtime/thread.hpp Changeset: 6b1bd708e254 Author: Doug Simon Date: 2014-06-04 23:43 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/6b1bd708e254 Merge. From tom.deneau at amd.com Thu Jun 5 20:29:24 2014 From: tom.deneau at amd.com (Deneau, Tom) Date: Thu, 5 Jun 2014 20:29:24 +0000 Subject: System.arraycopy Message-ID: Since we cannot handle "foreign calls" in the hsail backend, what is the preferred way to implement System.arraycopy? Right now, we are deferring to the host and so getting an ArrayCopyCallNode which gets lowered to a graph containing a ForeignCallNode. I confess to being a little confused with the ArrayCopyNode and Snippets, UnsafeArrayCopyNode and Snippets, ArrayCopyCallNode, etc. -- Tom From christian.thalinger at oracle.com Thu Jun 5 20:45:15 2014 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Thu, 5 Jun 2014 13:45:15 -0700 Subject: System.arraycopy In-Reply-To: References: Message-ID: <23396B2F-F391-449F-B0BD-28DA785F078B@oracle.com> Well, I guess the easiest but maybe not most performant way would be to have a substitution and implement it in plain Java. On the other hand you could rely on vectorization and the power of GPUs to produce good, parallel code :-) On Jun 5, 2014, at 1:29 PM, Deneau, Tom wrote: > Since we cannot handle "foreign calls" in the hsail backend, what is the preferred way to implement System.arraycopy? Right now, we are deferring to the host and so getting an ArrayCopyCallNode which gets lowered to a graph containing a ForeignCallNode. > > I confess to being a little confused with the ArrayCopyNode and Snippets, UnsafeArrayCopyNode and Snippets, ArrayCopyCallNode, etc. > > -- Tom > From tom.deneau at amd.com Thu Jun 5 21:39:47 2014 From: tom.deneau at amd.com (Deneau, Tom) Date: Thu, 5 Jun 2014 21:39:47 +0000 Subject: System.arraycopy In-Reply-To: <23396B2F-F391-449F-B0BD-28DA785F078B@oracle.com> References: <23396B2F-F391-449F-B0BD-28DA785F078B@oracle.com> Message-ID: Christian -- For now just going for functionally correct, will address performance issues in the future. But yes there are vector instructions that could help even in a single workitem. Is there already a pure java implementation of System.arrayCopy we could substitute? I guess we would want to use the logic to do different substitutions based on the type of the array (like in ArrayCopySnippets)? any other advice for implementing this? -- Tom > -----Original Message----- > From: Christian Thalinger [mailto:christian.thalinger at oracle.com] > Sent: Thursday, June 05, 2014 3:45 PM > To: Deneau, Tom > Cc: graal-dev at openjdk.java.net > Subject: Re: System.arraycopy > > Well, I guess the easiest but maybe not most performant way would be to > have a substitution and implement it in plain Java. > > On the other hand you could rely on vectorization and the power of GPUs > to produce good, parallel code :-) > > On Jun 5, 2014, at 1:29 PM, Deneau, Tom wrote: > > > Since we cannot handle "foreign calls" in the hsail backend, what is > the preferred way to implement System.arraycopy? Right now, we are > deferring to the host and so getting an ArrayCopyCallNode which gets > lowered to a graph containing a ForeignCallNode. > > > > I confess to being a little confused with the ArrayCopyNode and > Snippets, UnsafeArrayCopyNode and Snippets, ArrayCopyCallNode, etc. > > > > -- Tom > > From tom.rodriguez at oracle.com Thu Jun 5 21:43:52 2014 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Thu, 5 Jun 2014 14:43:52 -0700 Subject: System.arraycopy In-Reply-To: References: <23396B2F-F391-449F-B0BD-28DA785F078B@oracle.com> Message-ID: On Jun 5, 2014, at 2:39 PM, Deneau, Tom wrote: > Christian -- > > For now just going for functionally correct, will address performance issues in the future. But yes there are vector instructions that could help even in a single workitem. > > Is there already a pure java implementation of System.arrayCopy we could substitute? UnsafeArrayCopyNode is pretty much that. The flag CallArrayCopy controls whether it prefers the hotspot stubs for array copy or not but it should be able to fall back to UnsafeArrayCopyNode. tom > > I guess we would want to use the logic to do different substitutions based on the type of the array (like in ArrayCopySnippets)? > > any other advice for implementing this? > > -- Tom > > > >> -----Original Message----- >> From: Christian Thalinger [mailto:christian.thalinger at oracle.com] >> Sent: Thursday, June 05, 2014 3:45 PM >> To: Deneau, Tom >> Cc: graal-dev at openjdk.java.net >> Subject: Re: System.arraycopy >> >> Well, I guess the easiest but maybe not most performant way would be to >> have a substitution and implement it in plain Java. >> >> On the other hand you could rely on vectorization and the power of GPUs >> to produce good, parallel code :-) >> >> On Jun 5, 2014, at 1:29 PM, Deneau, Tom wrote: >> >>> Since we cannot handle "foreign calls" in the hsail backend, what is >> the preferred way to implement System.arraycopy? Right now, we are >> deferring to the host and so getting an ArrayCopyCallNode which gets >> lowered to a graph containing a ForeignCallNode. >>> >>> I confess to being a little confused with the ArrayCopyNode and >> Snippets, UnsafeArrayCopyNode and Snippets, ArrayCopyCallNode, etc. >>> >>> -- Tom >>> > From christian.thalinger at oracle.com Thu Jun 5 21:51:25 2014 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Thu, 5 Jun 2014 14:51:25 -0700 Subject: System.arraycopy In-Reply-To: References: <23396B2F-F391-449F-B0BD-28DA785F078B@oracle.com> Message-ID: <9E639B2E-E425-4690-9B98-A62BD38E9F93@oracle.com> On Jun 5, 2014, at 2:43 PM, Tom Rodriguez wrote: > > On Jun 5, 2014, at 2:39 PM, Deneau, Tom wrote: > >> Christian -- >> >> For now just going for functionally correct, will address performance issues in the future. But yes there are vector instructions that could help even in a single workitem. >> >> Is there already a pure java implementation of System.arrayCopy we could substitute? > > UnsafeArrayCopyNode is pretty much that. Oh yeah, I forgot about that. It?s using UnsafeLoadNode/UnsafeStoreNode and GPUs should be able to substitute these, right? > The flag CallArrayCopy controls whether it prefers the hotspot stubs for array copy or not but it should be able to fall back to UnsafeArrayCopyNode. > > tom > >> >> I guess we would want to use the logic to do different substitutions based on the type of the array (like in ArrayCopySnippets)? >> >> any other advice for implementing this? >> >> -- Tom >> >> >> >>> -----Original Message----- >>> From: Christian Thalinger [mailto:christian.thalinger at oracle.com] >>> Sent: Thursday, June 05, 2014 3:45 PM >>> To: Deneau, Tom >>> Cc: graal-dev at openjdk.java.net >>> Subject: Re: System.arraycopy >>> >>> Well, I guess the easiest but maybe not most performant way would be to >>> have a substitution and implement it in plain Java. >>> >>> On the other hand you could rely on vectorization and the power of GPUs >>> to produce good, parallel code :-) >>> >>> On Jun 5, 2014, at 1:29 PM, Deneau, Tom wrote: >>> >>>> Since we cannot handle "foreign calls" in the hsail backend, what is >>> the preferred way to implement System.arraycopy? Right now, we are >>> deferring to the host and so getting an ArrayCopyCallNode which gets >>> lowered to a graph containing a ForeignCallNode. >>>> >>>> I confess to being a little confused with the ArrayCopyNode and >>> Snippets, UnsafeArrayCopyNode and Snippets, ArrayCopyCallNode, etc. >>>> >>>> -- Tom >>>> >> > From tom.deneau at amd.com Thu Jun 5 23:28:37 2014 From: tom.deneau at amd.com (Deneau, Tom) Date: Thu, 5 Jun 2014 23:28:37 +0000 Subject: System.arraycopy In-Reply-To: References: <23396B2F-F391-449F-B0BD-28DA785F078B@oracle.com> Message-ID: Using -G:-CallArrayCopy seemed to work... > -----Original Message----- > From: Tom Rodriguez [mailto:tom.rodriguez at oracle.com] > Sent: Thursday, June 05, 2014 4:44 PM > To: Deneau, Tom > Cc: Chris Thalinger; graal-dev at openjdk.java.net > Subject: Re: System.arraycopy > > > On Jun 5, 2014, at 2:39 PM, Deneau, Tom wrote: > > > Christian -- > > > > For now just going for functionally correct, will address performance > issues in the future. But yes there are vector instructions that could > help even in a single workitem. > > > > Is there already a pure java implementation of System.arrayCopy we > could substitute? > > UnsafeArrayCopyNode is pretty much that. The flag CallArrayCopy > controls whether it prefers the hotspot stubs for array copy or not but > it should be able to fall back to UnsafeArrayCopyNode. > > tom > > > > > I guess we would want to use the logic to do different substitutions > based on the type of the array (like in ArrayCopySnippets)? > > > > any other advice for implementing this? > > > > -- Tom > > > > > > > >> -----Original Message----- > >> From: Christian Thalinger [mailto:christian.thalinger at oracle.com] > >> Sent: Thursday, June 05, 2014 3:45 PM > >> To: Deneau, Tom > >> Cc: graal-dev at openjdk.java.net > >> Subject: Re: System.arraycopy > >> > >> Well, I guess the easiest but maybe not most performant way would be > >> to have a substitution and implement it in plain Java. > >> > >> On the other hand you could rely on vectorization and the power of > >> GPUs to produce good, parallel code :-) > >> > >> On Jun 5, 2014, at 1:29 PM, Deneau, Tom wrote: > >> > >>> Since we cannot handle "foreign calls" in the hsail backend, what is > >> the preferred way to implement System.arraycopy? Right now, we are > >> deferring to the host and so getting an ArrayCopyCallNode which gets > >> lowered to a graph containing a ForeignCallNode. > >>> > >>> I confess to being a little confused with the ArrayCopyNode and > >> Snippets, UnsafeArrayCopyNode and Snippets, ArrayCopyCallNode, etc. > >>> > >>> -- Tom > >>> > > From doug.simon at oracle.com Fri Jun 6 01:00:07 2014 From: doug.simon at oracle.com (doug.simon at oracle.com) Date: Fri, 06 Jun 2014 01:00:07 +0000 Subject: hg: graal/graal: 25 new changesets Message-ID: <201406060100.s5610nka018511@aojmv0008> Changeset: 5c70a97bc5cc Author: Tom Rodriguez Date: 2014-06-03 17:32 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/5c70a97bc5cc make trap names compatible with xml ! src/share/vm/runtime/deoptimization.cpp Changeset: 5f3c8ebf4940 Author: Tom Rodriguez Date: 2014-06-03 17:48 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/5f3c8ebf4940 fix sorting of output in LogCompilation and add reporting of eliminated locks ! src/share/tools/LogCompilation/src/com/sun/hotspot/tools/compiler/Compilation.java + src/share/tools/LogCompilation/src/com/sun/hotspot/tools/compiler/JVMState.java ! src/share/tools/LogCompilation/src/com/sun/hotspot/tools/compiler/LogCompilation.java ! src/share/tools/LogCompilation/src/com/sun/hotspot/tools/compiler/LogParser.java ! src/share/tools/LogCompilation/src/com/sun/hotspot/tools/compiler/MakeNotEntrantEvent.java ! src/share/tools/LogCompilation/src/com/sun/hotspot/tools/compiler/NMethod.java ! src/share/tools/LogCompilation/src/com/sun/hotspot/tools/compiler/UncommonTrapEvent.java Changeset: 5da8c17a9767 Author: Tom Rodriguez Date: 2014-06-03 18:15 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/5da8c17a9767 improve error reporting for NodeIntrinsic signature mismatch ! graal/com.oracle.graal.replacements.verifier/src/com/oracle/graal/replacements/verifier/NodeIntrinsicVerifier.java Changeset: bca2ed3b97fd Author: Tom Rodriguez Date: 2014-06-04 17:21 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/bca2ed3b97fd skip initialization and use arraycopy for cloning arrays ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/HotSpotVMConfig.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotHostForeignCallsProvider.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/ArrayCopyCallNode.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/ObjectCloneSnippets.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/java/DynamicNewArrayNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/java/NewArrayNode.java Changeset: 8bbfddf8483f Author: Doug Simon Date: 2014-06-05 11:04 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/8bbfddf8483f exclude CompilationQueue and HotSpotOptions from JaCoCo ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/CompilationQueue.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/HotSpotOptions.java Changeset: bddb3eb57e90 Author: Doug Simon Date: 2014-06-05 11:05 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/bddb3eb57e90 moved verification of OptionValue declaring classes from run time to build time ! graal/com.oracle.graal.hotspot.sourcegen/src/com/oracle/graal/hotspot/sourcegen/GenGraalRuntimeInlineHpp.java + graal/com.oracle.graal.hotspot.sourcegen/src/com/oracle/graal/hotspot/sourcegen/OptionsVerifier.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/HotSpotGraalRuntime.java - graal/com.oracle.graal.java/src/com/oracle/graal/java/VerifyOptionsPhase.java Changeset: cd2209d3af46 Author: Doug Simon Date: 2014-06-05 11:08 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/cd2209d3af46 mx: show the environment variables defined and make command line issued when doing a HotSpot build ! mx/mx_graal.py Changeset: 8beba154719b Author: Miguel Garcia Date: 2014-06-03 11:27 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/8beba154719b [inliner] moved helper method to CallsiteHolder ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/inlining/walker/CallsiteHolder.java ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/inlining/walker/InliningData.java Changeset: 4408391d34a1 Author: Miguel Garcia Date: 2014-06-03 16:00 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/4408391d34a1 [inliner] assertion for result in a single place (producer) not at each consumer ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/inlining/walker/CallsiteHolder.java ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/inlining/walker/InliningIterator.java Changeset: 2aa285cf40db Author: Miguel Garcia Date: 2014-06-03 17:11 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/2aa285cf40db [inliner] the two personalities embodied by CallsiteHolder finally taken apart ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/inlining/walker/CallsiteHolder.java + graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/inlining/walker/CallsiteHolderDummy.java + graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/inlining/walker/CallsiteHolderExplorable.java ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/inlining/walker/InliningData.java Changeset: 15f1580a37e7 Author: Lukas Stadler Date: 2014-06-05 13:19 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/15f1580a37e7 metric for frame state count ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/FrameState.java Changeset: 4161a58e48cb Author: Lukas Stadler Date: 2014-06-05 13:19 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/4161a58e48cb refactor/simplify Constant ! graal/com.oracle.graal.api.meta/src/com/oracle/graal/api/meta/Constant.java ! graal/com.oracle.graal.java/src/com/oracle/graal/java/AbstractBytecodeParser.java Changeset: 3ad5e034ac1d Author: Lukas Stadler Date: 2014-06-05 13:19 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/3ad5e034ac1d add test for Constant + graal/com.oracle.graal.api.meta.test/src/com/oracle/graal/api/meta/test/ConstantTest.java Changeset: 23c4dd4f72a3 Author: Lukas Stadler Date: 2014-06-05 13:19 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/23c4dd4f72a3 avoid duplication of frame states during unrolling ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/phases/OnStackReplacementPhase.java ! graal/com.oracle.graal.loop/src/com/oracle/graal/loop/LoopFragment.java ! graal/com.oracle.graal.loop/src/com/oracle/graal/loop/LoopFragmentInside.java ! graal/com.oracle.graal.loop/src/com/oracle/graal/loop/LoopFragmentInsideBefore.java ! graal/com.oracle.graal.loop/src/com/oracle/graal/loop/LoopFragmentInsideFrom.java ! graal/com.oracle.graal.loop/src/com/oracle/graal/loop/LoopFragmentWhole.java ! graal/com.oracle.graal.loop/src/com/oracle/graal/loop/LoopTransformations.java ! graal/com.oracle.graal.loop/src/com/oracle/graal/loop/phases/LoopTransformHighPhase.java Changeset: 4c284376c374 Author: Lukas Stadler Date: 2014-05-26 17:12 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/4c284376c374 remove dead and redundant phis during LoopBeginNode simplification + graal/com.oracle.graal.nodes.test/src/com/oracle/graal/nodes/test/LoopPhiCanonicalizerTest.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/LoopBeginNode.java Changeset: 7046c4061cc8 Author: Lukas Stadler Date: 2014-06-05 14:30 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/7046c4061cc8 remove proxies when phis are removed ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/PhiNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/ValuePhiNode.java Changeset: f0efdd541094 Author: Lukas Stadler Date: 2014-06-05 18:14 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/f0efdd541094 less dependency between jtt tests and GraalCompilerTest constructors ! graal/com.oracle.graal.jtt/src/com/oracle/graal/jtt/JTTTest.java ! graal/com.oracle.graal.jtt/src/com/oracle/graal/jtt/bytecode/BC_checkcast01.java ! graal/com.oracle.graal.jtt/src/com/oracle/graal/jtt/bytecode/BC_checkcast02.java ! graal/com.oracle.graal.jtt/src/com/oracle/graal/jtt/bytecode/BC_instanceof.java ! graal/com.oracle.graal.jtt/src/com/oracle/graal/jtt/bytecode/BC_invokespecial.java ! graal/com.oracle.graal.jtt/src/com/oracle/graal/jtt/bytecode/BC_invokespecial2.java ! graal/com.oracle.graal.jtt/src/com/oracle/graal/jtt/bytecode/BC_invokevirtual.java ! graal/com.oracle.graal.jtt/src/com/oracle/graal/jtt/bytecode/BC_monitorenter.java ! graal/com.oracle.graal.jtt/src/com/oracle/graal/jtt/bytecode/BC_monitorenter02.java ! graal/com.oracle.graal.jtt/src/com/oracle/graal/jtt/bytecode/BC_multianewarray01.java ! graal/com.oracle.graal.jtt/src/com/oracle/graal/jtt/bytecode/BC_multianewarray02.java ! graal/com.oracle.graal.jtt/src/com/oracle/graal/jtt/bytecode/BC_new.java ! graal/com.oracle.graal.jtt/src/com/oracle/graal/jtt/bytecode/BC_putfield_01.java ! graal/com.oracle.graal.jtt/src/com/oracle/graal/jtt/bytecode/BC_putfield_02.java ! graal/com.oracle.graal.jtt/src/com/oracle/graal/jtt/bytecode/BC_putfield_03.java ! graal/com.oracle.graal.jtt/src/com/oracle/graal/jtt/bytecode/BC_putfield_04.java ! graal/com.oracle.graal.jtt/src/com/oracle/graal/jtt/except/BC_anewarray.java ! graal/com.oracle.graal.jtt/src/com/oracle/graal/jtt/except/BC_checkcast.java ! graal/com.oracle.graal.jtt/src/com/oracle/graal/jtt/except/BC_checkcast1.java ! graal/com.oracle.graal.jtt/src/com/oracle/graal/jtt/except/BC_checkcast2.java ! graal/com.oracle.graal.jtt/src/com/oracle/graal/jtt/except/BC_checkcast3.java ! graal/com.oracle.graal.jtt/src/com/oracle/graal/jtt/except/BC_checkcast4.java ! graal/com.oracle.graal.jtt/src/com/oracle/graal/jtt/except/BC_checkcast5.java ! graal/com.oracle.graal.jtt/src/com/oracle/graal/jtt/except/BC_checkcast6.java ! graal/com.oracle.graal.jtt/src/com/oracle/graal/jtt/except/BC_getfield.java ! graal/com.oracle.graal.jtt/src/com/oracle/graal/jtt/except/BC_getfield1.java ! graal/com.oracle.graal.jtt/src/com/oracle/graal/jtt/except/BC_invokespecial01.java ! graal/com.oracle.graal.jtt/src/com/oracle/graal/jtt/except/BC_invokevirtual01.java ! graal/com.oracle.graal.jtt/src/com/oracle/graal/jtt/except/BC_invokevirtual02.java ! graal/com.oracle.graal.jtt/src/com/oracle/graal/jtt/except/BC_monitorenter.java ! graal/com.oracle.graal.jtt/src/com/oracle/graal/jtt/except/BC_multianewarray.java ! graal/com.oracle.graal.jtt/src/com/oracle/graal/jtt/except/BC_putfield.java ! graal/com.oracle.graal.jtt/src/com/oracle/graal/jtt/except/Catch_NASE_2.java ! graal/com.oracle.graal.jtt/src/com/oracle/graal/jtt/except/Except_Synchronized01.java ! graal/com.oracle.graal.jtt/src/com/oracle/graal/jtt/except/Except_Synchronized02.java ! graal/com.oracle.graal.jtt/src/com/oracle/graal/jtt/except/Except_Synchronized03.java ! graal/com.oracle.graal.jtt/src/com/oracle/graal/jtt/except/Except_Synchronized04.java ! graal/com.oracle.graal.jtt/src/com/oracle/graal/jtt/except/StackTrace_CCE_00.java ! graal/com.oracle.graal.jtt/src/com/oracle/graal/jtt/except/Throw_Synchronized04.java ! graal/com.oracle.graal.jtt/src/com/oracle/graal/jtt/except/Throw_Synchronized05.java ! graal/com.oracle.graal.jtt/src/com/oracle/graal/jtt/hotpath/HP_field02.java ! graal/com.oracle.graal.jtt/src/com/oracle/graal/jtt/hotpath/HP_field04.java ! graal/com.oracle.graal.jtt/src/com/oracle/graal/jtt/jdk/UnsafeAccess01.java ! graal/com.oracle.graal.jtt/src/com/oracle/graal/jtt/lang/Class_cast01.java ! graal/com.oracle.graal.jtt/src/com/oracle/graal/jtt/lang/Class_cast02.java ! graal/com.oracle.graal.jtt/src/com/oracle/graal/jtt/lang/Class_isInstance01.java ! graal/com.oracle.graal.jtt/src/com/oracle/graal/jtt/lang/Class_isInstance02.java ! graal/com.oracle.graal.jtt/src/com/oracle/graal/jtt/lang/Class_isInstance03.java ! graal/com.oracle.graal.jtt/src/com/oracle/graal/jtt/lang/Class_isInstance06.java ! graal/com.oracle.graal.jtt/src/com/oracle/graal/jtt/lang/Class_isInstance07.java ! graal/com.oracle.graal.jtt/src/com/oracle/graal/jtt/lang/Object_clone01.java ! graal/com.oracle.graal.jtt/src/com/oracle/graal/jtt/lang/Object_clone02.java ! graal/com.oracle.graal.jtt/src/com/oracle/graal/jtt/lang/Object_equals01.java ! graal/com.oracle.graal.jtt/src/com/oracle/graal/jtt/lang/Object_getClass01.java ! graal/com.oracle.graal.jtt/src/com/oracle/graal/jtt/lang/Object_toString01.java ! graal/com.oracle.graal.jtt/src/com/oracle/graal/jtt/lang/Object_toString02.java ! graal/com.oracle.graal.jtt/src/com/oracle/graal/jtt/loop/Loop16.java ! graal/com.oracle.graal.jtt/src/com/oracle/graal/jtt/micro/StrangeFrames.java ! graal/com.oracle.graal.jtt/src/com/oracle/graal/jtt/optimize/Conditional01.java ! graal/com.oracle.graal.jtt/src/com/oracle/graal/jtt/optimize/Fold_Cast01.java ! graal/com.oracle.graal.jtt/src/com/oracle/graal/jtt/optimize/Fold_InstanceOf01.java ! graal/com.oracle.graal.jtt/src/com/oracle/graal/jtt/optimize/LLE_01.java ! graal/com.oracle.graal.jtt/src/com/oracle/graal/jtt/optimize/List_reorder_bug.java ! graal/com.oracle.graal.jtt/src/com/oracle/graal/jtt/optimize/NCE_01.java ! graal/com.oracle.graal.jtt/src/com/oracle/graal/jtt/optimize/NCE_02.java ! graal/com.oracle.graal.jtt/src/com/oracle/graal/jtt/optimize/NCE_03.java ! graal/com.oracle.graal.jtt/src/com/oracle/graal/jtt/optimize/NCE_04.java ! graal/com.oracle.graal.jtt/src/com/oracle/graal/jtt/optimize/VN_Cast01.java ! graal/com.oracle.graal.jtt/src/com/oracle/graal/jtt/optimize/VN_Cast02.java ! graal/com.oracle.graal.jtt/src/com/oracle/graal/jtt/optimize/VN_Field01.java ! graal/com.oracle.graal.jtt/src/com/oracle/graal/jtt/optimize/VN_Field02.java ! graal/com.oracle.graal.jtt/src/com/oracle/graal/jtt/optimize/VN_InstanceOf01.java ! graal/com.oracle.graal.jtt/src/com/oracle/graal/jtt/optimize/VN_InstanceOf02.java ! graal/com.oracle.graal.jtt/src/com/oracle/graal/jtt/optimize/VN_InstanceOf03.java ! graal/com.oracle.graal.jtt/src/com/oracle/graal/jtt/reflect/Field_get02.java ! graal/com.oracle.graal.jtt/src/com/oracle/graal/jtt/reflect/Field_get03.java ! graal/com.oracle.graal.jtt/src/com/oracle/graal/jtt/reflect/Field_get04.java ! graal/com.oracle.graal.jtt/src/com/oracle/graal/jtt/reflect/Field_set02.java ! graal/com.oracle.graal.jtt/src/com/oracle/graal/jtt/reflect/Field_set03.java ! graal/com.oracle.graal.jtt/src/com/oracle/graal/jtt/reflect/Invoke_except01.java ! graal/com.oracle.graal.jtt/src/com/oracle/graal/jtt/reflect/Invoke_main01.java ! graal/com.oracle.graal.jtt/src/com/oracle/graal/jtt/reflect/Invoke_main02.java ! graal/com.oracle.graal.jtt/src/com/oracle/graal/jtt/reflect/Invoke_main03.java ! graal/com.oracle.graal.jtt/src/com/oracle/graal/jtt/threads/Monitor_contended01.java ! graal/com.oracle.graal.jtt/src/com/oracle/graal/jtt/threads/Object_wait01.java ! graal/com.oracle.graal.jtt/src/com/oracle/graal/jtt/threads/Object_wait02.java ! graal/com.oracle.graal.jtt/src/com/oracle/graal/jtt/threads/Object_wait03.java ! graal/com.oracle.graal.jtt/src/com/oracle/graal/jtt/threads/Object_wait04.java ! graal/com.oracle.graal.jtt/src/com/oracle/graal/jtt/threads/Thread_join01.java ! graal/com.oracle.graal.jtt/src/com/oracle/graal/jtt/threads/Thread_join02.java ! graal/com.oracle.graal.jtt/src/com/oracle/graal/jtt/threads/Thread_join03.java ! graal/com.oracle.graal.jtt/src/com/oracle/graal/jtt/threads/Thread_new02.java Changeset: f546f40e1a6d Author: Lukas Stadler Date: 2014-06-05 18:15 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/f546f40e1a6d use thread pool for CheckGraalInvariants ! graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/CheckGraalInvariants.java Changeset: 369a3f9d1ceb Author: Roland Schatz Date: 2014-06-05 19:13 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/369a3f9d1ceb Fix bug in inferred stamp of IntegerRemNode. ! graal/com.oracle.graal.jtt/src/com/oracle/graal/jtt/hotpath/HP_idea.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/type/StampTool.java Changeset: 2662fb9c37e2 Author: Christian Humer Date: 2014-06-05 20:33 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/2662fb9c37e2 Truffle: invalidate inlining decisions on rewrites. ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/DefaultInliningPolicy.java ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/OptimizedCallTarget.java ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/OptimizedCallTargetLog.java ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/OptimizedDirectCallNode.java + graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/TruffleInliningDecision.java ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/TruffleInliningHandler.java ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/TruffleInliningPolicy.java ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/TruffleInliningProfile.java - graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/TruffleInliningResult.java Changeset: a8322288e838 Author: Tom Rodriguez Date: 2014-06-05 12:16 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/a8322288e838 improve error reporting in MatchProcessor ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/match/MatchProcessor.java ! graal/com.oracle.graal.hotspotvmconfig/src/com/oracle/graal/hotspotvmconfig/HotSpotVMConfigProcessor.java Changeset: 942e4b7712e1 Author: Tom Rodriguez Date: 2014-06-05 12:19 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/942e4b7712e1 graal build targets should automatically set INCLUDE_GRAAL ! make/Makefile Changeset: 692c25719837 Author: Christian Wimmer Date: 2014-06-05 15:37 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/692c25719837 Bugfix: Prefix byte missing for AMD64 byte instructions ! graal/com.oracle.graal.asm.amd64/src/com/oracle/graal/asm/amd64/AMD64Assembler.java ! src/cpu/x86/vm/assembler_x86.cpp Changeset: ebdeb414d64c Author: Michael Van De Vanter Date: 2014-06-05 16:17 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/ebdeb414d64c Truffle/Source: - clean up where IOException gets thrown for unreadable files - provide for sources from URLs - rename SourceFactory.asFakeFile() to asPseudoFile() - TruffleSourceFactory.asNull(String name) creates a named placeholder for a source that is unavailable ! graal/com.oracle.truffle.api/src/com/oracle/truffle/api/Source.java ! graal/com.oracle.truffle.api/src/com/oracle/truffle/api/source/SourceFactory.java Changeset: 0498791b33e8 Author: Michael Van De Vanter Date: 2014-06-05 16:24 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/0498791b33e8 Merge with 692c25719837cc1ce7c3f0165b0db765980a3012 From doug.simon at oracle.com Fri Jun 6 10:25:53 2014 From: doug.simon at oracle.com (Doug Simon) Date: Fri, 6 Jun 2014 12:25:53 +0200 Subject: [PATCH] SPARC Disassembler fixes In-Reply-To: References: Message-ID: <1B75FFC0-4B65-45D6-8CC1-165702D1B66F@oracle.com> Hi Stefan, I?ll integrate this patch. -Doug [1] http://www.oracle.com/technetwork/community/oca-486395.html On Jun 6, 2014, at 12:15 AM, Stefan Anzinger wrote: > Hi, > > Currently I am doing development in Graal on the SPARC backend. I encountered some issues with the dissassembler in the c1visualizer. > Here are the fixes, which i have made: > > HexCodeFile.java: Here is the Problem when addresses in SPARC like 0xFFFFFFFF5A239BF8, because it does not fit in a long value (Signed). > > The others are a few new instructions (VIS3) which I have used. > > Cheers > From java at stefan-marr.de Fri Jun 6 15:36:04 2014 From: java at stefan-marr.de (Stefan Marr) Date: Fri, 6 Jun 2014 17:36:04 +0200 Subject: Graal compilation error: no FrameState at DeoptimizingNode Message-ID: <9BD3F81D-4162-4019-A71A-89416B5596AD@stefan-marr.de> Dear all: After updating to the latest version of Graal, I am seeing errors of the following kind: Starting DeltaBlue benchmark ... [truffle] opt fail Method Variable>>#addConstraint::/home/smarr/.local/SOM/Examples/Benchmarks/DeltaBlue/Variable.som:32 at 66ebbd7b|Reason failed guarantee: no FrameState at DeoptimizingNode 3223|Deopt com.oracle.graal.compiler.common.GraalInternalError: failed guarantee: no FrameState at DeoptimizingNode 3223|Deopt at com.oracle.graal.compiler.common.GraalInternalError.guarantee(GraalInternalError.java:64) at com.oracle.graal.phases.common.FrameStateAssignmentPhase$FrameStateAssignmentClosure.processNode(FrameStateAssignmentPhase.java:57) at com.oracle.graal.phases.common.FrameStateAssignmentPhase$FrameStateAssignmentClosure.processNode(FrameStateAssignmentPhase.java:49) at com.oracle.graal.phases.graph.ReentrantNodeIterator.apply(ReentrantNodeIterator.java:110) at com.oracle.graal.phases.graph.ReentrantNodeIterator.apply(ReentrantNodeIterator.java:87) at com.oracle.graal.phases.common.FrameStateAssignmentPhase.run(FrameStateAssignmentPhase.java:110) at com.oracle.graal.phases.Phase.run(Phase.java:51) at com.oracle.graal.phases.BasePhase.apply(BasePhase.java:97) [...] Inspecting the corresponding graphs didn?t reveal much that helps me further, unfortunately. The only thing I saw was that the relevant node at least in one method was very early in the method on an untaken branch. To reproduce: ``` git clone --recursive https://github.com/SOM-st/TruffleSOM.git cd TruffleSOM ant GRAAL_HOME=../graal ./graal.sh -cp Smalltalk:Examples/Benchmarks/DeltaBlue Examples/Benchmarks/BenchmarkHarness.som DeltaBlue 100 0 10000 ``` Any hints on what the cause could be would be very welcome. Thanks Stefan -- Stefan Marr INRIA Lille - Nord Europe http://stefan-marr.de/research/ From lukas.stadler at oracle.com Fri Jun 6 15:39:51 2014 From: lukas.stadler at oracle.com (Lukas Stadler) Date: Fri, 6 Jun 2014 17:39:51 +0200 Subject: Graal compilation error: no FrameState at DeoptimizingNode In-Reply-To: <9BD3F81D-4162-4019-A71A-89416B5596AD@stefan-marr.de> References: <9BD3F81D-4162-4019-A71A-89416B5596AD@stefan-marr.de> Message-ID: <6B334D3A-1C72-4B96-AD84-9F18FF4E6E24@oracle.com> I suspect that this is caused by a change that I pushed yesterday - a fix is already on its way. - Lukas On 06 Jun 2014, at 17:36, Stefan Marr wrote: > Dear all: > > After updating to the latest version of Graal, I am seeing errors of the following kind: > > Starting DeltaBlue benchmark ... > [truffle] opt fail Method Variable>>#addConstraint::/home/smarr/.local/SOM/Examples/Benchmarks/DeltaBlue/Variable.som:32 at 66ebbd7b|Reason failed guarantee: no FrameState at DeoptimizingNode 3223|Deopt > com.oracle.graal.compiler.common.GraalInternalError: failed guarantee: no FrameState at DeoptimizingNode 3223|Deopt > at com.oracle.graal.compiler.common.GraalInternalError.guarantee(GraalInternalError.java:64) > at com.oracle.graal.phases.common.FrameStateAssignmentPhase$FrameStateAssignmentClosure.processNode(FrameStateAssignmentPhase.java:57) > at com.oracle.graal.phases.common.FrameStateAssignmentPhase$FrameStateAssignmentClosure.processNode(FrameStateAssignmentPhase.java:49) > at com.oracle.graal.phases.graph.ReentrantNodeIterator.apply(ReentrantNodeIterator.java:110) > at com.oracle.graal.phases.graph.ReentrantNodeIterator.apply(ReentrantNodeIterator.java:87) > at com.oracle.graal.phases.common.FrameStateAssignmentPhase.run(FrameStateAssignmentPhase.java:110) > at com.oracle.graal.phases.Phase.run(Phase.java:51) > at com.oracle.graal.phases.BasePhase.apply(BasePhase.java:97) > [...] > > Inspecting the corresponding graphs didn?t reveal much that helps me further, unfortunately. > The only thing I saw was that the relevant node at least in one method was very early in the method on an untaken branch. > > > To reproduce: > > ``` > git clone --recursive https://github.com/SOM-st/TruffleSOM.git > cd TruffleSOM > ant > GRAAL_HOME=../graal ./graal.sh -cp Smalltalk:Examples/Benchmarks/DeltaBlue Examples/Benchmarks/BenchmarkHarness.som DeltaBlue 100 0 10000 > ``` > > > Any hints on what the cause could be would be very welcome. > > Thanks > Stefan > > -- > Stefan Marr > INRIA Lille - Nord Europe > http://stefan-marr.de/research/ > > > From doug.simon at oracle.com Fri Jun 6 15:39:58 2014 From: doug.simon at oracle.com (doug.simon at oracle.com) Date: Fri, 06 Jun 2014 15:39:58 +0000 Subject: hg: graal/graal: 13 new changesets Message-ID: <201406061540.s56FeJtP021377@aojmv0008> Changeset: 7b37f1b6d188 Author: Bernhard Urban Date: 2014-06-05 17:44 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/7b37f1b6d188 MemoryScheduleTest: fix lowering (lower down to low tier) ! graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/MemoryScheduleTest.java Changeset: da9b9b625818 Author: Bernhard Urban Date: 2014-06-06 09:40 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/da9b9b625818 Truffle FrameDescriptor: add compiler asserts ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/substitutions/CompilerAssertsSubstitutions.java ! graal/com.oracle.truffle.api/src/com/oracle/truffle/api/CompilerAsserts.java ! graal/com.oracle.truffle.api/src/com/oracle/truffle/api/frame/FrameDescriptor.java Changeset: 80b0bd9e29c8 Author: Bernhard Urban Date: 2014-06-06 09:42 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/80b0bd9e29c8 FrameSlot: fix import ! graal/com.oracle.truffle.api/src/com/oracle/truffle/api/frame/FrameSlot.java Changeset: 87e11e4c031f Author: Bernhard Urban Date: 2014-06-06 11:17 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/87e11e4c031f pea: unittest to test escape analysis around nested loops + graal/com.oracle.graal.jtt/src/com/oracle/graal/jtt/optimize/NestedLoop_EA.java Changeset: 1f3174c89c6b Author: Miguel Garcia Date: 2014-06-03 19:57 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/1f3174c89c6b [inliner] readability ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/inlining/walker/InliningData.java Changeset: 1461d7627707 Author: Miguel Garcia Date: 2014-06-06 11:24 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/1461d7627707 [inliner] another mutator that finds its way to the class where it belongs ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/inlining/info/AbstractInlineInfo.java ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/inlining/info/InlineInfo.java ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/inlining/walker/InliningData.java Changeset: 61cf8b61ee4e Author: Miguel Garcia Date: 2014-06-06 11:41 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/61cf8b61ee4e [inliner] added a factory method in InlineInfo to make code uniform elsewhere ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/inlining/info/AbstractInlineInfo.java ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/inlining/info/InlineInfo.java ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/inlining/walker/InliningData.java Changeset: 83efd0e68a4a Author: Miguel Garcia Date: 2014-06-06 11:47 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/83efd0e68a4a [inliner] singleton pattern for DUMMY_CALLSITE_HOLDER ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/inlining/info/AbstractInlineInfo.java ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/inlining/walker/CallsiteHolderDummy.java ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/inlining/walker/InliningData.java Changeset: 45bd621d9bb9 Author: Miguel Garcia Date: 2014-06-06 12:16 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/45bd621d9bb9 Merge Changeset: bab1a955411e Author: Lukas Stadler Date: 2014-06-06 13:29 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/bab1a955411e Backed out changeset: 23c4dd4f72a3 (avoid duplication of frame states during unrolling) ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/phases/OnStackReplacementPhase.java ! graal/com.oracle.graal.loop/src/com/oracle/graal/loop/LoopFragment.java ! graal/com.oracle.graal.loop/src/com/oracle/graal/loop/LoopFragmentInside.java ! graal/com.oracle.graal.loop/src/com/oracle/graal/loop/LoopFragmentInsideBefore.java ! graal/com.oracle.graal.loop/src/com/oracle/graal/loop/LoopFragmentInsideFrom.java ! graal/com.oracle.graal.loop/src/com/oracle/graal/loop/LoopFragmentWhole.java ! graal/com.oracle.graal.loop/src/com/oracle/graal/loop/LoopTransformations.java ! graal/com.oracle.graal.loop/src/com/oracle/graal/loop/phases/LoopTransformHighPhase.java Changeset: 1629244c0df2 Author: Bernhard Urban Date: 2014-06-06 13:46 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/1629244c0df2 ArrayCopyCallNode: add exclude for JaCoCo ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/ArrayCopyCallNode.java Changeset: d8343c347dc0 Author: Doug Simon Date: 2014-06-06 16:01 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/d8343c347dc0 updated hcfdis library ! mx/mx_graal.py Changeset: a864a411fad3 Author: Doug Simon Date: 2014-06-06 16:03 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/a864a411fad3 mx: added -alt-javac option to build command to support an external javac executable (or javac wrapper) ! mxtool/mx.py From christian.humer at gmail.com Fri Jun 6 15:41:23 2014 From: christian.humer at gmail.com (Christian Humer) Date: Fri, 6 Jun 2014 17:41:23 +0200 Subject: Graal compilation error: no FrameState at DeoptimizingNode In-Reply-To: <6B334D3A-1C72-4B96-AD84-9F18FF4E6E24@oracle.com> References: <9BD3F81D-4162-4019-A71A-89416B5596AD@stefan-marr.de> <6B334D3A-1C72-4B96-AD84-9F18FF4E6E24@oracle.com> Message-ID: I just force-pushed the fix to openjdk. See http://hg.openjdk.java.net/graal/graal/rev/bab1a955411e. - Christian Humer On Fri, Jun 6, 2014 at 5:39 PM, Lukas Stadler wrote: > I suspect that this is caused by a change that I pushed yesterday - a fix > is already on its way. > > - Lukas > > On 06 Jun 2014, at 17:36, Stefan Marr wrote: > > > Dear all: > > > > After updating to the latest version of Graal, I am seeing errors of the > following kind: > > > > Starting DeltaBlue benchmark ... > > [truffle] opt fail Method > Variable>>#addConstraint::/home/smarr/.local/SOM/Examples/Benchmarks/DeltaBlue/Variable.som:32 at 66ebbd7b|Reason > failed guarantee: no FrameState at DeoptimizingNode 3223|Deopt > > com.oracle.graal.compiler.common.GraalInternalError: failed guarantee: > no FrameState at DeoptimizingNode 3223|Deopt > > at > com.oracle.graal.compiler.common.GraalInternalError.guarantee(GraalInternalError.java:64) > > at > com.oracle.graal.phases.common.FrameStateAssignmentPhase$FrameStateAssignmentClosure.processNode(FrameStateAssignmentPhase.java:57) > > at > com.oracle.graal.phases.common.FrameStateAssignmentPhase$FrameStateAssignmentClosure.processNode(FrameStateAssignmentPhase.java:49) > > at > com.oracle.graal.phases.graph.ReentrantNodeIterator.apply(ReentrantNodeIterator.java:110) > > at > com.oracle.graal.phases.graph.ReentrantNodeIterator.apply(ReentrantNodeIterator.java:87) > > at > com.oracle.graal.phases.common.FrameStateAssignmentPhase.run(FrameStateAssignmentPhase.java:110) > > at com.oracle.graal.phases.Phase.run(Phase.java:51) > > at com.oracle.graal.phases.BasePhase.apply(BasePhase.java:97) > > [...] > > > > Inspecting the corresponding graphs didn?t reveal much that helps me > further, unfortunately. > > The only thing I saw was that the relevant node at least in one method > was very early in the method on an untaken branch. > > > > > > To reproduce: > > > > ``` > > git clone --recursive https://github.com/SOM-st/TruffleSOM.git > > cd TruffleSOM > > ant > > GRAAL_HOME=../graal ./graal.sh -cp > Smalltalk:Examples/Benchmarks/DeltaBlue > Examples/Benchmarks/BenchmarkHarness.som DeltaBlue 100 0 10000 > > ``` > > > > > > Any hints on what the cause could be would be very welcome. > > > > Thanks > > Stefan > > > > -- > > Stefan Marr > > INRIA Lille - Nord Europe > > http://stefan-marr.de/research/ > > > > > > > > From java at stefan-marr.de Fri Jun 6 16:10:37 2014 From: java at stefan-marr.de (Stefan Marr) Date: Fri, 6 Jun 2014 18:10:37 +0200 Subject: Graal compilation error: no FrameState at DeoptimizingNode In-Reply-To: References: <9BD3F81D-4162-4019-A71A-89416B5596AD@stefan-marr.de> <6B334D3A-1C72-4B96-AD84-9F18FF4E6E24@oracle.com> Message-ID: Hi Lukas, Hi Christian: Thanks a lot, that does indeed fix it. And somewhere in there must have been also a fix for a performance regression I saw on the Richards benchmark. Best regards Stefan On 06 Jun 2014, at 17:41, Christian Humer wrote: > I just force-pushed the fix to openjdk. > See http://hg.openjdk.java.net/graal/graal/rev/bab1a955411e. > > > - Christian Humer > > > On Fri, Jun 6, 2014 at 5:39 PM, Lukas Stadler wrote: > I suspect that this is caused by a change that I pushed yesterday - a fix is already on its way. > > - Lukas > > On 06 Jun 2014, at 17:36, Stefan Marr wrote: > > > Dear all: > > > > After updating to the latest version of Graal, I am seeing errors of the following kind: > > > > Starting DeltaBlue benchmark ... > > [truffle] opt fail Method Variable>>#addConstraint::/home/smarr/.local/SOM/Examples/Benchmarks/DeltaBlue/Variable.som:32 at 66ebbd7b|Reason failed guarantee: no FrameState at DeoptimizingNode 3223|Deopt > > com.oracle.graal.compiler.common.GraalInternalError: failed guarantee: no FrameState at DeoptimizingNode 3223|Deopt > > at com.oracle.graal.compiler.common.GraalInternalError.guarantee(GraalInternalError.java:64) > > at com.oracle.graal.phases.common.FrameStateAssignmentPhase$FrameStateAssignmentClosure.processNode(FrameStateAssignmentPhase.java:57) > > at com.oracle.graal.phases.common.FrameStateAssignmentPhase$FrameStateAssignmentClosure.processNode(FrameStateAssignmentPhase.java:49) > > at com.oracle.graal.phases.graph.ReentrantNodeIterator.apply(ReentrantNodeIterator.java:110) > > at com.oracle.graal.phases.graph.ReentrantNodeIterator.apply(ReentrantNodeIterator.java:87) > > at com.oracle.graal.phases.common.FrameStateAssignmentPhase.run(FrameStateAssignmentPhase.java:110) > > at com.oracle.graal.phases.Phase.run(Phase.java:51) > > at com.oracle.graal.phases.BasePhase.apply(BasePhase.java:97) > > [...] > > > > Inspecting the corresponding graphs didn?t reveal much that helps me further, unfortunately. > > The only thing I saw was that the relevant node at least in one method was very early in the method on an untaken branch. > > > > > > To reproduce: > > > > ``` > > git clone --recursive https://github.com/SOM-st/TruffleSOM.git > > cd TruffleSOM > > ant > > GRAAL_HOME=../graal ./graal.sh -cp Smalltalk:Examples/Benchmarks/DeltaBlue Examples/Benchmarks/BenchmarkHarness.som DeltaBlue 100 0 10000 > > ``` > > > > > > Any hints on what the cause could be would be very welcome. > > > > 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 doug.simon at oracle.com Sat Jun 7 01:00:05 2014 From: doug.simon at oracle.com (doug.simon at oracle.com) Date: Sat, 07 Jun 2014 01:00:05 +0000 Subject: hg: graal/graal: 4 new changesets Message-ID: <201406070100.s5710DYb016537@aojmv0008> Changeset: 1d2c8c963d98 Author: Bernhard Urban Date: 2014-06-06 18:18 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/1d2c8c963d98 DynamicNewArrayNode: add exclude for JaCoCo ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/java/DynamicNewArrayNode.java Changeset: 03eda0a202e9 Author: Christian Wimmer Date: 2014-06-06 11:06 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/03eda0a202e9 Better fix for prefix byte for AMD64 byte instructions ! graal/com.oracle.graal.asm.amd64/src/com/oracle/graal/asm/amd64/AMD64Assembler.java ! src/cpu/x86/vm/assembler_x86.cpp ! src/cpu/x86/vm/assembler_x86.hpp Changeset: 87414e322d45 Author: Christian Wirth Date: 2014-06-06 15:13 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/87414e322d45 SlowPath a method in HotSpotTruffleRuntime ! graal/com.oracle.graal.truffle.hotspot/src/com/oracle/graal/truffle/hotspot/HotSpotTruffleRuntime.java Changeset: f59498d6e8b1 Author: Christian Wirth Date: 2014-06-06 21:36 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/f59498d6e8b1 Merged From doug.simon at oracle.com Sun Jun 8 01:00:07 2014 From: doug.simon at oracle.com (doug.simon at oracle.com) Date: Sun, 08 Jun 2014 01:00:07 +0000 Subject: hg: graal/graal: 4 new changesets Message-ID: <201406080100.s5810PaU003650@aojmv0008> Changeset: 915ebb306fcc Author: Michael Van De Vanter Date: 2014-06-06 17:51 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/915ebb306fcc Truffle/Source: major API revision - All source-related classes now in com.oracle.truffle.api.source - SourceFactory replaced with factory methods on Source - Revision, renaming, and documentation to methods on Source and SourceSection - NullSourceSection is now a utility class ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/TruffleCompilerImpl.java ! graal/com.oracle.truffle.api/src/com/oracle/truffle/api/ExecutionContext.java ! graal/com.oracle.truffle.api/src/com/oracle/truffle/api/instrument/Probe.java ! graal/com.oracle.truffle.api/src/com/oracle/truffle/api/instrument/ProbeListener.java ! graal/com.oracle.truffle.api/src/com/oracle/truffle/api/instrument/SourceCallback.java ! graal/com.oracle.truffle.api/src/com/oracle/truffle/api/instrument/SourceListener.java ! graal/com.oracle.truffle.api/src/com/oracle/truffle/api/instrument/impl/DefaultASTPrinter.java ! graal/com.oracle.truffle.api/src/com/oracle/truffle/api/instrument/impl/DefaultVisualizer.java ! graal/com.oracle.truffle.api/src/com/oracle/truffle/api/instrument/impl/InstrumentationNode.java ! graal/com.oracle.truffle.api/src/com/oracle/truffle/api/instrument/impl/ProbeManager.java ! graal/com.oracle.truffle.api/src/com/oracle/truffle/api/nodes/Node.java ! graal/com.oracle.truffle.api/src/com/oracle/truffle/api/nodes/NodeUtil.java ! graal/com.oracle.truffle.api/src/com/oracle/truffle/api/nodes/RootNode.java ! graal/com.oracle.truffle.api/src/com/oracle/truffle/api/nodes/serial/PostOrderDeserializer.java ! graal/com.oracle.truffle.api/src/com/oracle/truffle/api/nodes/serial/PostOrderSerializer.java ! graal/com.oracle.truffle.dsl.processor/src/com/oracle/truffle/dsl/processor/TruffleTypes.java ! graal/com.oracle.truffle.sl.test/src/com/oracle/truffle/sl/test/SLTestRunner.java ! graal/com.oracle.truffle.sl/src/com/oracle/truffle/sl/SLMain.java ! graal/com.oracle.truffle.sl/src/com/oracle/truffle/sl/builtins/SLDefineFunctionBuiltin.java ! graal/com.oracle.truffle.sl/src/com/oracle/truffle/sl/parser/Parser.frame ! graal/com.oracle.truffle.sl/src/com/oracle/truffle/sl/parser/Parser.java ! graal/com.oracle.truffle.sl/src/com/oracle/truffle/sl/parser/SLNodeFactory.java Changeset: 74e142bd2b12 Author: Michael Van De Vanter Date: 2014-06-06 22:13 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/74e142bd2b12 Truffle/Source: major API revision - All source-related classes now in com.oracle.truffle.api.source - SourceFactory replaced with factory methods on Source - Revision, renaming, and documentation to methods on Source and SourceSection - NullSourceSection is now a utility class - graal/com.oracle.truffle.api/src/com/oracle/truffle/api/NullSourceSection.java - graal/com.oracle.truffle.api/src/com/oracle/truffle/api/Source.java - graal/com.oracle.truffle.api/src/com/oracle/truffle/api/SourceSection.java + graal/com.oracle.truffle.api/src/com/oracle/truffle/api/source/LineLocation.java + graal/com.oracle.truffle.api/src/com/oracle/truffle/api/source/NullSourceSection.java + graal/com.oracle.truffle.api/src/com/oracle/truffle/api/source/Source.java - graal/com.oracle.truffle.api/src/com/oracle/truffle/api/source/SourceFactory.java - graal/com.oracle.truffle.api/src/com/oracle/truffle/api/source/SourceLineLocation.java + graal/com.oracle.truffle.api/src/com/oracle/truffle/api/source/SourceSection.java Changeset: 4291873b259b Author: Miguel Garcia Date: 2014-06-06 19:46 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/4291873b259b [inliner] extracted reusable query methods in InlineableGraph ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/inlining/info/elem/InlineableGraph.java Changeset: fa04403d1cb5 Author: Miguel Garcia Date: 2014-06-07 14:23 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/fa04403d1cb5 [inliner] documentation, more and better ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/inlining/InliningPhase.java ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/inlining/info/elem/InlineableGraph.java ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/inlining/walker/CallsiteHolderExplorable.java ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/inlining/walker/InliningData.java ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/inlining/walker/MethodInvocation.java From tom.deneau at amd.com Mon Jun 9 15:24:24 2014 From: tom.deneau at amd.com (Deneau, Tom) Date: Mon, 9 Jun 2014 15:24:24 +0000 Subject: System.arraycopy References: <23396B2F-F391-449F-B0BD-28DA785F078B@oracle.com> Message-ID: I did some tweaking to our HSAILHotSpotReplacementsImpl to basically make it always use the non-foreign-call version (UnsafeArrayCopy) rather than the foreign-call version, regardless of the sense of the global flag CallArrayCopy. This seems to cover most of the arraycopy cases. The one case that this not handle is a "non-exact" Object Array copy, for instance copying and array of Strings to an array of Objects. I see the snippet code for this "generic array copy" does as shown below and I believe we are taking the genericObjectCallCounter path. So we still fail with com.oracle.graal.graph.GraalGraphInternalError com.oracle.graal.compiler.common.GraalInternalError: unimplemented at node: 78|Invoke#Direct#System.arraycopy (I guess this doesn't get replaced by a snippet since it is already in a snippet? So my question is: Is there any java implementation of this path? Or any solution that would not involve a foreign call, etc. -- Tom ================= @Snippet public static void arraycopy(Object src, int srcPos, Object dest, int destPos, int length) { Object nonNullSrc = guardingNonNull(src); Object nonNullDest = guardingNonNull(dest); Word srcHub = loadHub(nonNullSrc); Word destHub = loadHub(nonNullDest); if (probability(FAST_PATH_PROBABILITY, srcHub.equal(destHub)) && probability(FAST_PATH_PROBABILITY, nonNullSrc != nonNullDest)) { int layoutHelper = checkArrayType(srcHub); final boolean isObjectArray = ((layoutHelper & layoutHelperElementTypePrimitiveInPlace()) == 0); checkLimits(nonNullSrc, srcPos, nonNullDest, destPos, length); if (probability(FAST_PATH_PROBABILITY, isObjectArray)) { genericObjectExactCallCounter.inc(); UnsafeArrayCopyNode.arraycopy(nonNullSrc, srcPos, nonNullDest, destPos, length, Kind.Object); } else { genericPrimitiveCallCounter.inc(); UnsafeArrayCopyNode.arraycopyPrimitive(nonNullSrc, srcPos, nonNullDest, destPos, length, layoutHelper); } } else { genericObjectCallCounter.inc(); System.arraycopy(nonNullSrc, srcPos, nonNullDest, destPos, length); } } > -----Original Message----- > From: Deneau, Tom > Sent: Thursday, June 05, 2014 6:29 PM > To: 'Tom Rodriguez' > Cc: Chris Thalinger; graal-dev at openjdk.java.net > Subject: RE: System.arraycopy > > Using -G:-CallArrayCopy seemed to work... > > > -----Original Message----- > > From: Tom Rodriguez [mailto:tom.rodriguez at oracle.com] > > Sent: Thursday, June 05, 2014 4:44 PM > > To: Deneau, Tom > > Cc: Chris Thalinger; graal-dev at openjdk.java.net > > Subject: Re: System.arraycopy > > > > > > On Jun 5, 2014, at 2:39 PM, Deneau, Tom wrote: > > > > > Christian -- > > > > > > For now just going for functionally correct, will address > > > performance > > issues in the future. But yes there are vector instructions that > > could help even in a single workitem. > > > > > > Is there already a pure java implementation of System.arrayCopy we > > could substitute? > > > > UnsafeArrayCopyNode is pretty much that. The flag CallArrayCopy > > controls whether it prefers the hotspot stubs for array copy or not > > but it should be able to fall back to UnsafeArrayCopyNode. > > > > tom > > > > > > > > I guess we would want to use the logic to do different substitutions > > based on the type of the array (like in ArrayCopySnippets)? > > > > > > any other advice for implementing this? > > > > > > -- Tom > > > > > > > > > > > >> -----Original Message----- > > >> From: Christian Thalinger [mailto:christian.thalinger at oracle.com] > > >> Sent: Thursday, June 05, 2014 3:45 PM > > >> To: Deneau, Tom > > >> Cc: graal-dev at openjdk.java.net > > >> Subject: Re: System.arraycopy > > >> > > >> Well, I guess the easiest but maybe not most performant way would > > >> be to have a substitution and implement it in plain Java. > > >> > > >> On the other hand you could rely on vectorization and the power of > > >> GPUs to produce good, parallel code :-) > > >> > > >> On Jun 5, 2014, at 1:29 PM, Deneau, Tom wrote: > > >> > > >>> Since we cannot handle "foreign calls" in the hsail backend, what > > >>> is > > >> the preferred way to implement System.arraycopy? Right now, we are > > >> deferring to the host and so getting an ArrayCopyCallNode which > > >> gets lowered to a graph containing a ForeignCallNode. > > >>> > > >>> I confess to being a little confused with the ArrayCopyNode and > > >> Snippets, UnsafeArrayCopyNode and Snippets, ArrayCopyCallNode, etc. > > >>> > > >>> -- Tom > > >>> > > > From tom.deneau at amd.com Mon Jun 9 15:25:44 2014 From: tom.deneau at amd.com (Deneau, Tom) Date: Mon, 9 Jun 2014 15:25:44 +0000 Subject: webrev to extend hsail allocation to allow gpu to refill tlab Message-ID: Hi all -- Has anyone had a chance to look at this webrev posted last Tuesday? -- Tom > -----Original Message----- > From: Deneau, Tom > Sent: Tuesday, June 03, 2014 4:27 PM > To: graal-dev at openjdk.java.net > Subject: webrev to extend hsail allocation to allow gpu to refill tlab > > I have placed a webrev up at > http://cr.openjdk.java.net/~tdeneau/graal-webrevs/webrev-hsail-refill- > tlab-gpu > which we would like to get checked into the graal trunk. > > This webrev extends the existing hsail heap allocation logic. In the > existing logic, when a workitem cannot allocate from the current tlab, > it just deoptimizes. In this webrev, we add logic to allocate a new > tlab from the gpu. > > The algorithm must deal with the fact that multiple hsa workitems can > share a single tlab, and so multiple workitems can "overflow". A > workitem can tell if it is the "first overflower" and the first > overflower is charged with getting a new tlab while the other workitems > wait for the new tlab to be announced. > > Workitems access a tlab thru a fixed register (sort of like a thread > register) which instead of pointing to a donor thread now points to a > HSAILTlabInfo structure, which is sort of a subset of a full tlab > struct, containing just the fields that we would actually use on the > gpu. > > struct HSAILTlabInfo { > HeapWord * _start; // normal vm tlab fields, > start, top, end, etc. > HeapWord * _top; > HeapWord * _end; > // additional data not in a normal tlab > HeapWord * _lastGoodTop; // first overflower records > this > JavaThread * _donor_thread; // donor thread associated > with this tlabInfo > } > > The first overflower grabs a new tlabInfo structure and allocates a new > tlab (using edenAllocate) and "publishes" the new tlabInfo for other > workitems to start using. See the routine called > allocateFromTlabSlowPath in HSAILNewObjectSnippets. > > Eventually when hsail function calls are supported, this slow path will > not be inlined but will be called as a stub. > > Other changes: > > * the allocation-related logic was removed from gpu_hsail.cpp into > gpu_hsail_tlab.hpp. The HSAILHotSpotNmethod now keeps track of > whether a kernel uses allocation and avoids this logic if it does > not. > > * Before the kernel runs, the donor thread tlabs are used to set > up the initial tlabInfo records, and a tlab allocation is done > here if the donor thread tlab is empty. > > * When kernel is finished running, the cpu side will see a list > of one or more HSAILTlabInfos and basically postprocesses > these, fixing up any overflows and making them parsable and > copying them back to the appropriate donor thread as needed. > > * the inter-workitem communication required the use of the hsail > instructions for load_acquire and store_release from the > snippets. The HSAILDirectLoadAcquireNode and > HSAILDirectStoreReleaseNode with associated NodeIntrinsics were > created to handle this. A node for creating a workitemabsid > instruction was also created, it is not used in the algorithm as > such but was useful for adding debug traces. > > * In HSAILHotSpotBackend, the logic to decide whether a kernel uses > allocation or not was made more precise. (This flag is also made > available at execute time.) There were several atomic_add > related tests were falsely being marked as requiring > HSAILAllocation and thus HSAILDeoptimization support. This > marking was removed. > > -- Tom Deneau From christian.thalinger at oracle.com Mon Jun 9 16:28:30 2014 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Mon, 9 Jun 2014 09:28:30 -0700 Subject: webrev to extend hsail allocation to allow gpu to refill tlab In-Reply-To: References: Message-ID: I have the webrev still open ;-) On Jun 9, 2014, at 8:25 AM, Deneau, Tom wrote: > Hi all -- > > Has anyone had a chance to look at this webrev posted last Tuesday? > > -- Tom > >> -----Original Message----- >> From: Deneau, Tom >> Sent: Tuesday, June 03, 2014 4:27 PM >> To: graal-dev at openjdk.java.net >> Subject: webrev to extend hsail allocation to allow gpu to refill tlab >> >> I have placed a webrev up at >> http://cr.openjdk.java.net/~tdeneau/graal-webrevs/webrev-hsail-refill- >> tlab-gpu >> which we would like to get checked into the graal trunk. >> >> This webrev extends the existing hsail heap allocation logic. In the >> existing logic, when a workitem cannot allocate from the current tlab, >> it just deoptimizes. In this webrev, we add logic to allocate a new >> tlab from the gpu. >> >> The algorithm must deal with the fact that multiple hsa workitems can >> share a single tlab, and so multiple workitems can "overflow". A >> workitem can tell if it is the "first overflower" and the first >> overflower is charged with getting a new tlab while the other workitems >> wait for the new tlab to be announced. >> >> Workitems access a tlab thru a fixed register (sort of like a thread >> register) which instead of pointing to a donor thread now points to a >> HSAILTlabInfo structure, which is sort of a subset of a full tlab >> struct, containing just the fields that we would actually use on the >> gpu. >> >> struct HSAILTlabInfo { >> HeapWord * _start; // normal vm tlab fields, >> start, top, end, etc. >> HeapWord * _top; >> HeapWord * _end; >> // additional data not in a normal tlab >> HeapWord * _lastGoodTop; // first overflower records >> this >> JavaThread * _donor_thread; // donor thread associated >> with this tlabInfo >> } >> >> The first overflower grabs a new tlabInfo structure and allocates a new >> tlab (using edenAllocate) and "publishes" the new tlabInfo for other >> workitems to start using. See the routine called >> allocateFromTlabSlowPath in HSAILNewObjectSnippets. >> >> Eventually when hsail function calls are supported, this slow path will >> not be inlined but will be called as a stub. >> >> Other changes: >> >> * the allocation-related logic was removed from gpu_hsail.cpp into >> gpu_hsail_tlab.hpp. The HSAILHotSpotNmethod now keeps track of >> whether a kernel uses allocation and avoids this logic if it does >> not. >> >> * Before the kernel runs, the donor thread tlabs are used to set >> up the initial tlabInfo records, and a tlab allocation is done >> here if the donor thread tlab is empty. >> >> * When kernel is finished running, the cpu side will see a list >> of one or more HSAILTlabInfos and basically postprocesses >> these, fixing up any overflows and making them parsable and >> copying them back to the appropriate donor thread as needed. >> >> * the inter-workitem communication required the use of the hsail >> instructions for load_acquire and store_release from the >> snippets. The HSAILDirectLoadAcquireNode and >> HSAILDirectStoreReleaseNode with associated NodeIntrinsics were >> created to handle this. A node for creating a workitemabsid >> instruction was also created, it is not used in the algorithm as >> such but was useful for adding debug traces. >> >> * In HSAILHotSpotBackend, the logic to decide whether a kernel uses >> allocation or not was made more precise. (This flag is also made >> available at execute time.) There were several atomic_add >> related tests were falsely being marked as requiring >> HSAILAllocation and thus HSAILDeoptimization support. This >> marking was removed. >> >> -- Tom Deneau > From Eric.Caspole at amd.com Mon Jun 9 16:40:26 2014 From: Eric.Caspole at amd.com (Caspole, Eric) Date: Mon, 9 Jun 2014 16:40:26 +0000 Subject: Webrev for first version of HSA offload integer reduce Message-ID: Hi everybody, I put up a new webrev that allows some IntStream.reduce() to be offloaded to HSA: http://cr.openjdk.java.net/~ecaspole/graal_int_reduce1/webrev/ This works with a Sumatra webrev I will eventually add into the Sumatra JDK repo: http://cr.openjdk.java.net/~ecaspole/sumatra_int_reduce_1/webrev/ This combo allows offloading IntStream.parallel().reduce() for Integer::sum, Integer::max, and Integer::min. It builds a kernel from a hand made HSAIL string of code that gets called from the new Stream API diversion code in the Sumatra part. Eventually we hope to have regular compilation of user reduce functions but this allows us to do experiments with workloads before we get all the details of reduce compilation in place such as barrier placement and group size nuances. In the current Kaveri hardware version of Okra, it uses group size 256 by default and this reduce code is designed to work only with 256. Also, because it is a handmade kernel, it only runs with -UseHSAILDeoptimization and -UseCompressedOops. In the included reduce tests, they will skip if the correct flags are not there for the tests to run correctly. This webrev also changes the way the kernel args are processed to look at the actual args type rather than by the type signature of the kernel method. Regards, Eric From christian.thalinger at oracle.com Mon Jun 9 16:41:04 2014 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Mon, 9 Jun 2014 09:41:04 -0700 Subject: webrev to extend hsail allocation to allow gpu to refill tlab In-Reply-To: References: Message-ID: <4172060C-E15B-4FA2-965C-CC19E62C445C@oracle.com> graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/HotSpotVMConfig.java Remove the space between the type and * for e.g. HSAILAllocationInfo *. Same in other files like src/gpu/hsail/vm/vmStructs_hsail.hpp. graal/com.oracle.graal.lir.hsail/src/com/oracle/graal/lir/hsail/HSAILMove.java + public LoadOp(Kind kind, AllocatableValue result, HSAILAddressValue address, LIRFrameState state, boolean useLoadAcquire) { + public StoreOp(Kind kind, HSAILAddressValue address, AllocatableValue input, LIRFrameState state, boolean useRelease) { I would prefer separate LoadAcquireOp/StoreReleaseOp classes. It makes the uses more readable. src/gpu/hsail/vm/gpu_hsail_Tlab.hpp 26 #define GPU_HSAIL_TLAB_HPP To be consistent with other header defines this should be: 26 #define GPU_HSAIL_VM_GPU_HSAIL_TLAB_HPP It seems this needs to be changed in existing files too. As a general comment, can we make multi-line comments C-style (/* ? */) comments instead of C++ style (// ?)? The C-style comments reformat themselves automatically if changed while the C++ ones don?t. On Jun 9, 2014, at 9:28 AM, Christian Thalinger wrote: > I have the webrev still open ;-) > > On Jun 9, 2014, at 8:25 AM, Deneau, Tom wrote: > >> Hi all -- >> >> Has anyone had a chance to look at this webrev posted last Tuesday? >> >> -- Tom >> >>> -----Original Message----- >>> From: Deneau, Tom >>> Sent: Tuesday, June 03, 2014 4:27 PM >>> To: graal-dev at openjdk.java.net >>> Subject: webrev to extend hsail allocation to allow gpu to refill tlab >>> >>> I have placed a webrev up at >>> http://cr.openjdk.java.net/~tdeneau/graal-webrevs/webrev-hsail-refill- >>> tlab-gpu >>> which we would like to get checked into the graal trunk. >>> >>> This webrev extends the existing hsail heap allocation logic. In the >>> existing logic, when a workitem cannot allocate from the current tlab, >>> it just deoptimizes. In this webrev, we add logic to allocate a new >>> tlab from the gpu. >>> >>> The algorithm must deal with the fact that multiple hsa workitems can >>> share a single tlab, and so multiple workitems can "overflow". A >>> workitem can tell if it is the "first overflower" and the first >>> overflower is charged with getting a new tlab while the other workitems >>> wait for the new tlab to be announced. >>> >>> Workitems access a tlab thru a fixed register (sort of like a thread >>> register) which instead of pointing to a donor thread now points to a >>> HSAILTlabInfo structure, which is sort of a subset of a full tlab >>> struct, containing just the fields that we would actually use on the >>> gpu. >>> >>> struct HSAILTlabInfo { >>> HeapWord * _start; // normal vm tlab fields, >>> start, top, end, etc. >>> HeapWord * _top; >>> HeapWord * _end; >>> // additional data not in a normal tlab >>> HeapWord * _lastGoodTop; // first overflower records >>> this >>> JavaThread * _donor_thread; // donor thread associated >>> with this tlabInfo >>> } >>> >>> The first overflower grabs a new tlabInfo structure and allocates a new >>> tlab (using edenAllocate) and "publishes" the new tlabInfo for other >>> workitems to start using. See the routine called >>> allocateFromTlabSlowPath in HSAILNewObjectSnippets. >>> >>> Eventually when hsail function calls are supported, this slow path will >>> not be inlined but will be called as a stub. >>> >>> Other changes: >>> >>> * the allocation-related logic was removed from gpu_hsail.cpp into >>> gpu_hsail_tlab.hpp. The HSAILHotSpotNmethod now keeps track of >>> whether a kernel uses allocation and avoids this logic if it does >>> not. >>> >>> * Before the kernel runs, the donor thread tlabs are used to set >>> up the initial tlabInfo records, and a tlab allocation is done >>> here if the donor thread tlab is empty. >>> >>> * When kernel is finished running, the cpu side will see a list >>> of one or more HSAILTlabInfos and basically postprocesses >>> these, fixing up any overflows and making them parsable and >>> copying them back to the appropriate donor thread as needed. >>> >>> * the inter-workitem communication required the use of the hsail >>> instructions for load_acquire and store_release from the >>> snippets. The HSAILDirectLoadAcquireNode and >>> HSAILDirectStoreReleaseNode with associated NodeIntrinsics were >>> created to handle this. A node for creating a workitemabsid >>> instruction was also created, it is not used in the algorithm as >>> such but was useful for adding debug traces. >>> >>> * In HSAILHotSpotBackend, the logic to decide whether a kernel uses >>> allocation or not was made more precise. (This flag is also made >>> available at execute time.) There were several atomic_add >>> related tests were falsely being marked as requiring >>> HSAILAllocation and thus HSAILDeoptimization support. This >>> marking was removed. >>> >>> -- Tom Deneau >> > From christian.thalinger at oracle.com Mon Jun 9 17:07:45 2014 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Mon, 9 Jun 2014 10:07:45 -0700 Subject: Webrev for first version of HSA offload integer reduce In-Reply-To: References: Message-ID: <1E9B0B70-CC27-44F5-A85A-C84B93EDCD96@oracle.com> On Jun 9, 2014, at 9:40 AM, Caspole, Eric wrote: > Hi everybody, > I put up a new webrev that allows some IntStream.reduce() to be offloaded to HSA: > > http://cr.openjdk.java.net/~ecaspole/graal_int_reduce1/webrev/ src/gpu/hsail/vm/hsailKernelArguments.hpp + virtual void collectArgs() { Does this really have to be in the .hpp file? I see that the base class has it in the .hpp file too. > > This works with a Sumatra webrev I will eventually add into the Sumatra JDK repo: > > http://cr.openjdk.java.net/~ecaspole/sumatra_int_reduce_1/webrev/ > > This combo allows offloading IntStream.parallel().reduce() for Integer::sum, Integer::max, and Integer::min. It builds a kernel from a hand made HSAIL string of code that gets called from the new Stream API diversion code in the Sumatra part. > > Eventually we hope to have regular compilation of user reduce functions but this allows us to do experiments with workloads before we get all the details of reduce compilation in place such as barrier placement and group size nuances. Presumably that will remove the hand-made code eventually? > > In the current Kaveri hardware version of Okra, it uses group size 256 by default and this reduce code is designed to work only with 256. Also, because it is a handmade kernel, it only runs with -UseHSAILDeoptimization and -UseCompressedOops. > In the included reduce tests, they will skip if the correct flags are not there for the tests to run correctly. > > This webrev also changes the way the kernel args are processed to look at the actual args type rather than by the type signature of the kernel method. > Regards, > Eric > From Eric.Caspole at amd.com Mon Jun 9 17:40:15 2014 From: Eric.Caspole at amd.com (Caspole, Eric) Date: Mon, 9 Jun 2014 17:40:15 +0000 Subject: mx gate dacapo problem? Message-ID: Has anyone else noticed, something seems wrong with the Dacapo part of "mx gate" since about last Friday or so. Unfortunately it seems to take more than 30 minutes of building and running to get the failure point. Thanks, Eric ===== DaCapo 9.12 fop starting warmup 5 ===== ===== DaCapo 9.12 fop completed warmup 5 in 1521 msec ===== ===== DaCapo 9.12 fop starting warmup 6 ===== ===== DaCapo 9.12 fop completed warmup 6 in 1142 msec ===== ===== DaCapo 9.12 fop starting warmup 7 ===== ===== DaCapo 9.12 fop completed warmup 7 in 833 msec ===== ===== DaCapo 9.12 fop starting ===== ===== DaCapo 9.12 fop PASSED in 717 msec ===== gate: 09 Jun 2014 10:41:44: END: DaCapo-fop:fastdebug [0:00:15.784107] gate: 09 Jun 2014 10:41:44: BEGIN: DaCapo-sunflow:fastdebug Using scaled threading model. 4 processors detected, 4 threads used to drive the workload, in a possible range of [1,256] ===== DaCapo 9.12 sunflow starting warmup 1 ===== ===== DaCapo 9.12 sunflow completed warmup 1 in 27979 msec ===== ===== DaCapo 9.12 sunflow starting ===== ===== DaCapo 9.12 sunflow PASSED in 6483 msec ===== gate: 09 Jun 2014 10:42:19: END: DaCapo-sunflow:fastdebug [0:00:35.180180] gate: 09 Jun 2014 10:42:19: BEGIN: Scala-DaCapo-kiama:fastdebug Error: Could not find or load main class Harness gate: 09 Jun 2014 10:42:19: ABORT: Scala-DaCapo-kiama:fastdebug [0:00:00.271493] Traceback (most recent call last): File "/home/ecaspole/views/graal-default/graal/mx/mx_graal.py", line 1363, in gate gate_body(args, tasks) File "/home/ecaspole/views/graal-default/graal/mx/mx_graal.py", line 1245, in _basic_gate_body t.abort(test.name + ' Failed') File "/home/ecaspole/views/graal-default/graal/mx/mx_graal.py", line 1191, in abort mx.abort(codeOrMessage) File "/home/ecaspole/views/graal-default/graal/mxtool/mx.py", line 1877, in abort raise SystemExit(codeOrMessage) SystemExit: Scala-DaCapo-kiama Failed gate: 09 Jun 2014 10:42:19: ABORT: Gate [0:56:26.247938] Scala-DaCapo-kiama Failed From tom.deneau at amd.com Mon Jun 9 17:42:19 2014 From: tom.deneau at amd.com (Deneau, Tom) Date: Mon, 9 Jun 2014 17:42:19 +0000 Subject: webrev to extend hsail allocation to allow gpu to refill tlab In-Reply-To: <4172060C-E15B-4FA2-965C-CC19E62C445C@oracle.com> References: <4172060C-E15B-4FA2-965C-CC19E62C445C@oracle.com> Message-ID: OK, I will address these suggestions. I was thinking in the future there could be other kinds of HSAIL loads we want to express thru load intrinsics, but I guess we could have separate Op classes for each one. -- Tom From: Christian Thalinger [mailto:christian.thalinger at oracle.com] Sent: Monday, June 09, 2014 11:41 AM To: Deneau, Tom Cc: graal-dev at openjdk.java.net Subject: Re: webrev to extend hsail allocation to allow gpu to refill tlab graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/HotSpotVMConfig.java Remove the space between the type and * for e.g. HSAILAllocationInfo *. Same in other files like src/gpu/hsail/vm/vmStructs_hsail.hpp. graal/com.oracle.graal.lir.hsail/src/com/oracle/graal/lir/hsail/HSAILMove.java + public LoadOp(Kind kind, AllocatableValue result, HSAILAddressValue address, LIRFrameState state, boolean useLoadAcquire) { + public StoreOp(Kind kind, HSAILAddressValue address, AllocatableValue input, LIRFrameState state, boolean useRelease) { I would prefer separate LoadAcquireOp/StoreReleaseOp classes. It makes the uses more readable. src/gpu/hsail/vm/gpu_hsail_Tlab.hpp 26 #define GPU_HSAIL_TLAB_HPP To be consistent with other header defines this should be: 26 #define GPU_HSAIL_VM_GPU_HSAIL_TLAB_HPP It seems this needs to be changed in existing files too. As a general comment, can we make multi-line comments C-style (/* ... */) comments instead of C++ style (// ...)? The C-style comments reformat themselves automatically if changed while the C++ ones don't. On Jun 9, 2014, at 9:28 AM, Christian Thalinger > wrote: I have the webrev still open ;-) On Jun 9, 2014, at 8:25 AM, Deneau, Tom > wrote: Hi all -- Has anyone had a chance to look at this webrev posted last Tuesday? -- Tom -----Original Message----- From: Deneau, Tom Sent: Tuesday, June 03, 2014 4:27 PM To: graal-dev at openjdk.java.net Subject: webrev to extend hsail allocation to allow gpu to refill tlab I have placed a webrev up at http://cr.openjdk.java.net/~tdeneau/graal-webrevs/webrev-hsail-refill- tlab-gpu which we would like to get checked into the graal trunk. This webrev extends the existing hsail heap allocation logic. In the existing logic, when a workitem cannot allocate from the current tlab, it just deoptimizes. In this webrev, we add logic to allocate a new tlab from the gpu. The algorithm must deal with the fact that multiple hsa workitems can share a single tlab, and so multiple workitems can "overflow". A workitem can tell if it is the "first overflower" and the first overflower is charged with getting a new tlab while the other workitems wait for the new tlab to be announced. Workitems access a tlab thru a fixed register (sort of like a thread register) which instead of pointing to a donor thread now points to a HSAILTlabInfo structure, which is sort of a subset of a full tlab struct, containing just the fields that we would actually use on the gpu. struct HSAILTlabInfo { HeapWord * _start; // normal vm tlab fields, start, top, end, etc. HeapWord * _top; HeapWord * _end; // additional data not in a normal tlab HeapWord * _lastGoodTop; // first overflower records this JavaThread * _donor_thread; // donor thread associated with this tlabInfo } The first overflower grabs a new tlabInfo structure and allocates a new tlab (using edenAllocate) and "publishes" the new tlabInfo for other workitems to start using. See the routine called allocateFromTlabSlowPath in HSAILNewObjectSnippets. Eventually when hsail function calls are supported, this slow path will not be inlined but will be called as a stub. Other changes: * the allocation-related logic was removed from gpu_hsail.cpp into gpu_hsail_tlab.hpp. The HSAILHotSpotNmethod now keeps track of whether a kernel uses allocation and avoids this logic if it does not. * Before the kernel runs, the donor thread tlabs are used to set up the initial tlabInfo records, and a tlab allocation is done here if the donor thread tlab is empty. * When kernel is finished running, the cpu side will see a list of one or more HSAILTlabInfos and basically postprocesses these, fixing up any overflows and making them parsable and copying them back to the appropriate donor thread as needed. * the inter-workitem communication required the use of the hsail instructions for load_acquire and store_release from the snippets. The HSAILDirectLoadAcquireNode and HSAILDirectStoreReleaseNode with associated NodeIntrinsics were created to handle this. A node for creating a workitemabsid instruction was also created, it is not used in the algorithm as such but was useful for adding debug traces. * In HSAILHotSpotBackend, the logic to decide whether a kernel uses allocation or not was made more precise. (This flag is also made available at execute time.) There were several atomic_add related tests were falsely being marked as requiring HSAILAllocation and thus HSAILDeoptimization support. This marking was removed. -- Tom Deneau From eric.caspole at amd.com Mon Jun 9 17:50:40 2014 From: eric.caspole at amd.com (Eric Caspole) Date: Mon, 9 Jun 2014 13:50:40 -0400 Subject: Webrev for first version of HSA offload integer reduce In-Reply-To: <1E9B0B70-CC27-44F5-A85A-C84B93EDCD96@oracle.com> References: <1E9B0B70-CC27-44F5-A85A-C84B93EDCD96@oracle.com> Message-ID: <5395F3F0.8060508@amd.com> On 06/09/2014 01:07 PM, Christian Thalinger wrote: > > On Jun 9, 2014, at 9:40 AM, Caspole, Eric > wrote: > >> Hi everybody, >> I put up a new webrev that allows some IntStream.reduce() to be >> offloaded to HSA: >> >> http://cr.openjdk.java.net/~ecaspole/graal_int_reduce1/webrev/ > > > src/gpu/hsail/vm/hsailKernelArguments.hpp > > + virtual void collectArgs() { > > Does this really have to be in the .hpp file? I see that the base class > has it in the .hpp file too. No it doesn't have to be there, it is just some historical thing I don't know why. I can change that. > >> >> This works with a Sumatra webrev I will eventually add into the >> Sumatra JDK repo: >> >> http://cr.openjdk.java.net/~ecaspole/sumatra_int_reduce_1/webrev/ >> >> This combo allows offloading IntStream.parallel().reduce() for >> Integer::sum, Integer::max, and Integer::min. It builds a kernel from >> a hand made HSAIL string of code that gets called from the new Stream >> API diversion code in the Sumatra part. >> >> Eventually we hope to have regular compilation of user reduce >> functions but this allows us to do experiments with workloads before >> we get all the details of reduce compilation in place such as barrier >> placement and group size nuances. > > Presumably that will remove the hand-made code eventually? Yes. I just want to be able to expose this interesting functionality in the mean time. > >> >> In the current Kaveri hardware version of Okra, it uses group size 256 >> by default and this reduce code is designed to work only with 256. >> Also, because it is a handmade kernel, it only runs with >> -UseHSAILDeoptimization and -UseCompressedOops. >> In the included reduce tests, they will skip if the correct flags are >> not there for the tests to run correctly. >> >> This webrev also changes the way the kernel args are processed to look >> at the actual args type rather than by the type signature of the >> kernel method. >> Regards, >> Eric >> > From christian.thalinger at oracle.com Mon Jun 9 18:15:25 2014 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Mon, 9 Jun 2014 11:15:25 -0700 Subject: Webrev for first version of HSA offload integer reduce In-Reply-To: <5395F3F0.8060508@amd.com> References: <1E9B0B70-CC27-44F5-A85A-C84B93EDCD96@oracle.com> <5395F3F0.8060508@amd.com> Message-ID: On Jun 9, 2014, at 10:50 AM, Eric Caspole wrote: > > > On 06/09/2014 01:07 PM, Christian Thalinger wrote: >> >> On Jun 9, 2014, at 9:40 AM, Caspole, Eric > > wrote: >> >>> Hi everybody, >>> I put up a new webrev that allows some IntStream.reduce() to be >>> offloaded to HSA: >>> >>> http://cr.openjdk.java.net/~ecaspole/graal_int_reduce1/webrev/ >> >> >> src/gpu/hsail/vm/hsailKernelArguments.hpp >> >> + virtual void collectArgs() { >> >> Does this really have to be in the .hpp file? I see that the base class >> has it in the .hpp file too. > > No it doesn't have to be there, it is just some historical thing I don't know why. I can change that. That would be good. Thanks. > >> >>> >>> This works with a Sumatra webrev I will eventually add into the >>> Sumatra JDK repo: >>> >>> http://cr.openjdk.java.net/~ecaspole/sumatra_int_reduce_1/webrev/ >>> >>> This combo allows offloading IntStream.parallel().reduce() for >>> Integer::sum, Integer::max, and Integer::min. It builds a kernel from >>> a hand made HSAIL string of code that gets called from the new Stream >>> API diversion code in the Sumatra part. >>> >>> Eventually we hope to have regular compilation of user reduce >>> functions but this allows us to do experiments with workloads before >>> we get all the details of reduce compilation in place such as barrier >>> placement and group size nuances. >> >> Presumably that will remove the hand-made code eventually? > > Yes. I just want to be able to expose this interesting functionality in the mean time. Makes sense. > >> >>> >>> In the current Kaveri hardware version of Okra, it uses group size 256 >>> by default and this reduce code is designed to work only with 256. >>> Also, because it is a handmade kernel, it only runs with >>> -UseHSAILDeoptimization and -UseCompressedOops. >>> In the included reduce tests, they will skip if the correct flags are >>> not there for the tests to run correctly. >>> >>> This webrev also changes the way the kernel args are processed to look >>> at the actual args type rather than by the type signature of the >>> kernel method. >>> Regards, >>> Eric From java at stefan-marr.de Mon Jun 9 20:06:49 2014 From: java at stefan-marr.de (Stefan Marr) Date: Mon, 9 Jun 2014 22:06:49 +0200 Subject: Optimization Thresholds? Message-ID: Hi: I am running into a strange issue when optimizing some reflective operations. Don?t think it is related to the operations themselves, but rather the way the optimizations/Graal works. If benchmarked separately, I see, as desired, the same performance results for direct and reflective operations. So, I assume that my specializations are sufficient to please the optimizer. Concretely, that is reflective method invocation via Smalltalk?s #perform: as well as intercepting undefined methods with #doesNotUnderstand:. However, if both reflective mechanisms are used in combination to implement something like dynamic proxies, runtime nearly doubles compared to what I would expect. I have been experimenting with the various thresholds in TruffleCompilerOptions, but without any luck. Since the benchmarks are still microbenchmarks, I don?t think I am really hitting any of those anyway. The fully inlined tree has something like 220 nodes. That?s the number I see in the error output after setting TruffleGraphMaxNodes to a very small number. And, that?s just about 20 more than what I get reported for the non-reflective, i.e., direct benchmark. What would be a good approach to figure out what?s going wrong here? Thanks Stefan To reporduce: git clone --recursive https://github.com/SOM-st/TruffleSOM.git ant jar ant test ./graal.sh -cp Smalltalk:Examples/Benchmarks/DoesNotUnderstand Examples/Benchmarks/BenchmarkHarness.som DirectAdd 20 0 1000 ./graal.sh -cp Smalltalk:Examples/Benchmarks/DoesNotUnderstand Examples/Benchmarks/BenchmarkHarness.som ProxyAdd 20 0 1000 -- Stefan Marr INRIA Lille - Nord Europe http://stefan-marr.de/research/ From tom.deneau at amd.com Mon Jun 9 21:11:29 2014 From: tom.deneau at amd.com (Deneau, Tom) Date: Mon, 9 Jun 2014 21:11:29 +0000 Subject: webrev to extend hsail allocation to allow gpu to refill tlab In-Reply-To: <4172060C-E15B-4FA2-965C-CC19E62C445C@oracle.com> References: <4172060C-E15B-4FA2-965C-CC19E62C445C@oracle.com> Message-ID: I have tried to address Christian's comments in http://cr.openjdk.java.net/~tdeneau/graal-webrevs/webrev-hsail-refill-tlab-gpu-v2 -- Tom From: Christian Thalinger [mailto:christian.thalinger at oracle.com] Sent: Monday, June 09, 2014 11:41 AM To: Deneau, Tom Cc: graal-dev at openjdk.java.net Subject: Re: webrev to extend hsail allocation to allow gpu to refill tlab graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/HotSpotVMConfig.java Remove the space between the type and * for e.g. HSAILAllocationInfo *. Same in other files like src/gpu/hsail/vm/vmStructs_hsail.hpp. graal/com.oracle.graal.lir.hsail/src/com/oracle/graal/lir/hsail/HSAILMove.java + public LoadOp(Kind kind, AllocatableValue result, HSAILAddressValue address, LIRFrameState state, boolean useLoadAcquire) { + public StoreOp(Kind kind, HSAILAddressValue address, AllocatableValue input, LIRFrameState state, boolean useRelease) { I would prefer separate LoadAcquireOp/StoreReleaseOp classes. It makes the uses more readable. src/gpu/hsail/vm/gpu_hsail_Tlab.hpp 26 #define GPU_HSAIL_TLAB_HPP To be consistent with other header defines this should be: 26 #define GPU_HSAIL_VM_GPU_HSAIL_TLAB_HPP It seems this needs to be changed in existing files too. As a general comment, can we make multi-line comments C-style (/* ... */) comments instead of C++ style (// ...)? The C-style comments reformat themselves automatically if changed while the C++ ones don't. On Jun 9, 2014, at 9:28 AM, Christian Thalinger > wrote: I have the webrev still open ;-) On Jun 9, 2014, at 8:25 AM, Deneau, Tom > wrote: Hi all -- Has anyone had a chance to look at this webrev posted last Tuesday? -- Tom -----Original Message----- From: Deneau, Tom Sent: Tuesday, June 03, 2014 4:27 PM To: graal-dev at openjdk.java.net Subject: webrev to extend hsail allocation to allow gpu to refill tlab I have placed a webrev up at http://cr.openjdk.java.net/~tdeneau/graal-webrevs/webrev-hsail-refill- tlab-gpu which we would like to get checked into the graal trunk. This webrev extends the existing hsail heap allocation logic. In the existing logic, when a workitem cannot allocate from the current tlab, it just deoptimizes. In this webrev, we add logic to allocate a new tlab from the gpu. The algorithm must deal with the fact that multiple hsa workitems can share a single tlab, and so multiple workitems can "overflow". A workitem can tell if it is the "first overflower" and the first overflower is charged with getting a new tlab while the other workitems wait for the new tlab to be announced. Workitems access a tlab thru a fixed register (sort of like a thread register) which instead of pointing to a donor thread now points to a HSAILTlabInfo structure, which is sort of a subset of a full tlab struct, containing just the fields that we would actually use on the gpu. struct HSAILTlabInfo { HeapWord * _start; // normal vm tlab fields, start, top, end, etc. HeapWord * _top; HeapWord * _end; // additional data not in a normal tlab HeapWord * _lastGoodTop; // first overflower records this JavaThread * _donor_thread; // donor thread associated with this tlabInfo } The first overflower grabs a new tlabInfo structure and allocates a new tlab (using edenAllocate) and "publishes" the new tlabInfo for other workitems to start using. See the routine called allocateFromTlabSlowPath in HSAILNewObjectSnippets. Eventually when hsail function calls are supported, this slow path will not be inlined but will be called as a stub. Other changes: * the allocation-related logic was removed from gpu_hsail.cpp into gpu_hsail_tlab.hpp. The HSAILHotSpotNmethod now keeps track of whether a kernel uses allocation and avoids this logic if it does not. * Before the kernel runs, the donor thread tlabs are used to set up the initial tlabInfo records, and a tlab allocation is done here if the donor thread tlab is empty. * When kernel is finished running, the cpu side will see a list of one or more HSAILTlabInfos and basically postprocesses these, fixing up any overflows and making them parsable and copying them back to the appropriate donor thread as needed. * the inter-workitem communication required the use of the hsail instructions for load_acquire and store_release from the snippets. The HSAILDirectLoadAcquireNode and HSAILDirectStoreReleaseNode with associated NodeIntrinsics were created to handle this. A node for creating a workitemabsid instruction was also created, it is not used in the algorithm as such but was useful for adding debug traces. * In HSAILHotSpotBackend, the logic to decide whether a kernel uses allocation or not was made more precise. (This flag is also made available at execute time.) There were several atomic_add related tests were falsely being marked as requiring HSAILAllocation and thus HSAILDeoptimization support. This marking was removed. -- Tom Deneau From tom.rodriguez at oracle.com Mon Jun 9 22:27:34 2014 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Mon, 9 Jun 2014 15:27:34 -0700 Subject: System.arraycopy In-Reply-To: References: <23396B2F-F391-449F-B0BD-28DA785F078B@oracle.com> Message-ID: <5AB0BCB5-7BFE-4173-B2DD-4E743E473F7C@oracle.com> On Jun 9, 2014, at 8:24 AM, Deneau, Tom wrote: > I did some tweaking to our HSAILHotSpotReplacementsImpl to basically make it always use the non-foreign-call version (UnsafeArrayCopy) rather than the foreign-call version, regardless of the sense of the global flag CallArrayCopy. This seems to cover most of the arraycopy cases. > > The one case that this not handle is a "non-exact" Object Array copy, for instance copying and array of Strings to an array of Objects. That case could be handled with the existing code by improving the store check. Currently it tests that the hubs are equal but for arrays the requirement is really that the element type of the destination is assignable from the source element type. So copying from String[] to Object[] doesn?t require any per element checks but the reverse operation does. UnsafeArrayCopyNode doesn?t do that great a job of decomposing the interesting cases for Object copies. Also the generic code doesn?t handle conjoint copies either which is fairly common. > > I see the snippet code for this "generic array copy" does as shown below and I believe we are taking the genericObjectCallCounter path. So we still fail with > > com.oracle.graal.graph.GraalGraphInternalError com.oracle.graal.compiler.common.GraalInternalError: unimplemented > at node: 78|Invoke#Direct#System.arraycopy > > (I guess this doesn't get replaced by a snippet since it is already in a snippet? > > So my question is: Is there any java implementation of this path? Or any solution that would not involve a foreign call, etc. A full implementation of array copy isn?t that hard in Java but it will entail a large amount of code. Would it be possible call HSAIL stubs for doing the copies or does everything have to be inline? tom > > -- Tom > > ================= > @Snippet > public static void arraycopy(Object src, int srcPos, Object dest, int destPos, int length) { > Object nonNullSrc = guardingNonNull(src); > Object nonNullDest = guardingNonNull(dest); > Word srcHub = loadHub(nonNullSrc); > Word destHub = loadHub(nonNullDest); > if (probability(FAST_PATH_PROBABILITY, srcHub.equal(destHub)) && probability(FAST_PATH_PROBABILITY, nonNullSrc != nonNullDest)) { > int layoutHelper = checkArrayType(srcHub); > final boolean isObjectArray = ((layoutHelper & layoutHelperElementTypePrimitiveInPlace()) == 0); > > checkLimits(nonNullSrc, srcPos, nonNullDest, destPos, length); > if (probability(FAST_PATH_PROBABILITY, isObjectArray)) { > genericObjectExactCallCounter.inc(); > UnsafeArrayCopyNode.arraycopy(nonNullSrc, srcPos, nonNullDest, destPos, length, Kind.Object); > } else { > genericPrimitiveCallCounter.inc(); > UnsafeArrayCopyNode.arraycopyPrimitive(nonNullSrc, srcPos, nonNullDest, destPos, length, layoutHelper); > } > } else { > genericObjectCallCounter.inc(); > System.arraycopy(nonNullSrc, srcPos, nonNullDest, destPos, length); > } > } > > >> -----Original Message----- >> From: Deneau, Tom >> Sent: Thursday, June 05, 2014 6:29 PM >> To: 'Tom Rodriguez' >> Cc: Chris Thalinger; graal-dev at openjdk.java.net >> Subject: RE: System.arraycopy >> >> Using -G:-CallArrayCopy seemed to work... >> >>> -----Original Message----- >>> From: Tom Rodriguez [mailto:tom.rodriguez at oracle.com] >>> Sent: Thursday, June 05, 2014 4:44 PM >>> To: Deneau, Tom >>> Cc: Chris Thalinger; graal-dev at openjdk.java.net >>> Subject: Re: System.arraycopy >>> >>> >>> On Jun 5, 2014, at 2:39 PM, Deneau, Tom wrote: >>> >>>> Christian -- >>>> >>>> For now just going for functionally correct, will address >>>> performance >>> issues in the future. But yes there are vector instructions that >>> could help even in a single workitem. >>>> >>>> Is there already a pure java implementation of System.arrayCopy we >>> could substitute? >>> >>> UnsafeArrayCopyNode is pretty much that. The flag CallArrayCopy >>> controls whether it prefers the hotspot stubs for array copy or not >>> but it should be able to fall back to UnsafeArrayCopyNode. >>> >>> tom >>> >>>> >>>> I guess we would want to use the logic to do different substitutions >>> based on the type of the array (like in ArrayCopySnippets)? >>>> >>>> any other advice for implementing this? >>>> >>>> -- Tom >>>> >>>> >>>> >>>>> -----Original Message----- >>>>> From: Christian Thalinger [mailto:christian.thalinger at oracle.com] >>>>> Sent: Thursday, June 05, 2014 3:45 PM >>>>> To: Deneau, Tom >>>>> Cc: graal-dev at openjdk.java.net >>>>> Subject: Re: System.arraycopy >>>>> >>>>> Well, I guess the easiest but maybe not most performant way would >>>>> be to have a substitution and implement it in plain Java. >>>>> >>>>> On the other hand you could rely on vectorization and the power of >>>>> GPUs to produce good, parallel code :-) >>>>> >>>>> On Jun 5, 2014, at 1:29 PM, Deneau, Tom wrote: >>>>> >>>>>> Since we cannot handle "foreign calls" in the hsail backend, what >>>>>> is >>>>> the preferred way to implement System.arraycopy? Right now, we are >>>>> deferring to the host and so getting an ArrayCopyCallNode which >>>>> gets lowered to a graph containing a ForeignCallNode. >>>>>> >>>>>> I confess to being a little confused with the ArrayCopyNode and >>>>> Snippets, UnsafeArrayCopyNode and Snippets, ArrayCopyCallNode, etc. >>>>>> >>>>>> -- Tom >>>>>> >>>> > From tom.deneau at amd.com Mon Jun 9 22:55:00 2014 From: tom.deneau at amd.com (Deneau, Tom) Date: Mon, 9 Jun 2014 22:55:00 +0000 Subject: System.arraycopy In-Reply-To: <5AB0BCB5-7BFE-4173-B2DD-4E743E473F7C@oracle.com> References: <23396B2F-F391-449F-B0BD-28DA785F078B@oracle.com> <5AB0BCB5-7BFE-4173-B2DD-4E743E473F7C@oracle.com> Message-ID: for now everything in hsail has to be inlined, but I guess we can postpone support for the "hard" generic cases until we can call stubs. -- Tom D. > -----Original Message----- > From: Tom Rodriguez [mailto:tom.rodriguez at oracle.com] > Sent: Monday, June 09, 2014 5:28 PM > To: Deneau, Tom > Cc: Chris Thalinger; graal-dev at openjdk.java.net > Subject: Re: System.arraycopy > > On Jun 9, 2014, at 8:24 AM, Deneau, Tom wrote: > > > I did some tweaking to our HSAILHotSpotReplacementsImpl to basically > make it always use the non-foreign-call version (UnsafeArrayCopy) rather > than the foreign-call version, regardless of the sense of the global > flag CallArrayCopy. This seems to cover most of the arraycopy cases. > > > > The one case that this not handle is a "non-exact" Object Array copy, > for instance copying and array of Strings to an array of Objects. > > That case could be handled with the existing code by improving the store > check. Currently it tests that the hubs are equal but for arrays the > requirement is really that the element type of the destination is > assignable from the source element type. So copying from String[] to > Object[] doesn't require any per element checks but the reverse > operation does. UnsafeArrayCopyNode doesn't do that great a job of > decomposing the interesting cases for Object copies. Also the generic > code doesn't handle conjoint copies either which is fairly common. > > > > > I see the snippet code for this "generic array copy" does as shown > > below and I believe we are taking the genericObjectCallCounter path. > > So we still fail with > > > > com.oracle.graal.graph.GraalGraphInternalError > com.oracle.graal.compiler.common.GraalInternalError: unimplemented > > at node: 78|Invoke#Direct#System.arraycopy > > > > (I guess this doesn't get replaced by a snippet since it is already in > a snippet? > > > > So my question is: Is there any java implementation of this path? Or > any solution that would not involve a foreign call, etc. > > A full implementation of array copy isn't that hard in Java but it will > entail a large amount of code. Would it be possible call HSAIL stubs > for doing the copies or does everything have to be inline? > > tom > > > > > -- Tom > > > > ================= > > @Snippet > > public static void arraycopy(Object src, int srcPos, Object dest, > int destPos, int length) { > > Object nonNullSrc = guardingNonNull(src); > > Object nonNullDest = guardingNonNull(dest); > > Word srcHub = loadHub(nonNullSrc); > > Word destHub = loadHub(nonNullDest); > > if (probability(FAST_PATH_PROBABILITY, srcHub.equal(destHub)) > && probability(FAST_PATH_PROBABILITY, nonNullSrc != nonNullDest)) { > > int layoutHelper = checkArrayType(srcHub); > > final boolean isObjectArray = ((layoutHelper & > > layoutHelperElementTypePrimitiveInPlace()) == 0); > > > > checkLimits(nonNullSrc, srcPos, nonNullDest, destPos, > length); > > if (probability(FAST_PATH_PROBABILITY, isObjectArray)) { > > genericObjectExactCallCounter.inc(); > > UnsafeArrayCopyNode.arraycopy(nonNullSrc, srcPos, > nonNullDest, destPos, length, Kind.Object); > > } else { > > genericPrimitiveCallCounter.inc(); > > UnsafeArrayCopyNode.arraycopyPrimitive(nonNullSrc, > srcPos, nonNullDest, destPos, length, layoutHelper); > > } > > } else { > > genericObjectCallCounter.inc(); > > System.arraycopy(nonNullSrc, srcPos, nonNullDest, destPos, > length); > > } > > } > > > > > >> -----Original Message----- > >> From: Deneau, Tom > >> Sent: Thursday, June 05, 2014 6:29 PM > >> To: 'Tom Rodriguez' > >> Cc: Chris Thalinger; graal-dev at openjdk.java.net > >> Subject: RE: System.arraycopy > >> > >> Using -G:-CallArrayCopy seemed to work... > >> > >>> -----Original Message----- > >>> From: Tom Rodriguez [mailto:tom.rodriguez at oracle.com] > >>> Sent: Thursday, June 05, 2014 4:44 PM > >>> To: Deneau, Tom > >>> Cc: Chris Thalinger; graal-dev at openjdk.java.net > >>> Subject: Re: System.arraycopy > >>> > >>> > >>> On Jun 5, 2014, at 2:39 PM, Deneau, Tom wrote: > >>> > >>>> Christian -- > >>>> > >>>> For now just going for functionally correct, will address > >>>> performance > >>> issues in the future. But yes there are vector instructions that > >>> could help even in a single workitem. > >>>> > >>>> Is there already a pure java implementation of System.arrayCopy we > >>> could substitute? > >>> > >>> UnsafeArrayCopyNode is pretty much that. The flag CallArrayCopy > >>> controls whether it prefers the hotspot stubs for array copy or not > >>> but it should be able to fall back to UnsafeArrayCopyNode. > >>> > >>> tom > >>> > >>>> > >>>> I guess we would want to use the logic to do different > >>>> substitutions > >>> based on the type of the array (like in ArrayCopySnippets)? > >>>> > >>>> any other advice for implementing this? > >>>> > >>>> -- Tom > >>>> > >>>> > >>>> > >>>>> -----Original Message----- > >>>>> From: Christian Thalinger [mailto:christian.thalinger at oracle.com] > >>>>> Sent: Thursday, June 05, 2014 3:45 PM > >>>>> To: Deneau, Tom > >>>>> Cc: graal-dev at openjdk.java.net > >>>>> Subject: Re: System.arraycopy > >>>>> > >>>>> Well, I guess the easiest but maybe not most performant way would > >>>>> be to have a substitution and implement it in plain Java. > >>>>> > >>>>> On the other hand you could rely on vectorization and the power of > >>>>> GPUs to produce good, parallel code :-) > >>>>> > >>>>> On Jun 5, 2014, at 1:29 PM, Deneau, Tom > wrote: > >>>>> > >>>>>> Since we cannot handle "foreign calls" in the hsail backend, what > >>>>>> is > >>>>> the preferred way to implement System.arraycopy? Right now, we > >>>>> are deferring to the host and so getting an ArrayCopyCallNode > >>>>> which gets lowered to a graph containing a ForeignCallNode. > >>>>>> > >>>>>> I confess to being a little confused with the ArrayCopyNode and > >>>>> Snippets, UnsafeArrayCopyNode and Snippets, ArrayCopyCallNode, > etc. > >>>>>> > >>>>>> -- Tom > >>>>>> > >>>> > > From tom.deneau at amd.com Tue Jun 10 14:47:03 2014 From: tom.deneau at amd.com (Deneau, Tom) Date: Tue, 10 Jun 2014 14:47:03 +0000 Subject: webrev to enable arraycopy support in hsail backend Message-ID: I placed a small webrev up at http://cr.openjdk.java.net/~tdeneau/graal-webrevs/webrev-hsail-arraycopy-support/webrev/ The purpose is to allow System.arraycopy (or at least most flavors of it) to be used in hsail kernels. Note that even if kernels do not use it directly, System.arrayCopy is used in many JDK routines, for example Stringbuilder.append(), ArrayList.get, etc. One flavor that is not supported yet is for example an Object array copy where the destination is a superclass of the source. The changes to HSAILHotSpotReplacementsImpl.java is just a way to take the non-foreign-call path (which hsail kernels cannot handle) regardless of the sense of the global flag CallArrayCopy (default true). The rest of the webrev is either new specific arraycopy tests, or enabling of some tests that were previously ignored because they needed arraycopy support. -- Tom From Eric.Caspole at amd.com Tue Jun 10 15:03:29 2014 From: Eric.Caspole at amd.com (Caspole, Eric) Date: Tue, 10 Jun 2014 15:03:29 +0000 Subject: Webrev for first version of HSA offload integer reduce In-Reply-To: References: <1E9B0B70-CC27-44F5-A85A-C84B93EDCD96@oracle.com> <5395F3F0.8060508@amd.com>, Message-ID: I moved collectArgs into the cpp files for both classes here: http://cr.openjdk.java.net/~ecaspole/graal_int_reduce1/02/webrev/ Thanks, Eric ________________________________ From: Christian Thalinger [christian.thalinger at oracle.com] Sent: Monday, June 09, 2014 2:15 PM To: Caspole, Eric Cc: graal-dev at openjdk.java.net; sumatra-dev at openjdk.java.net Subject: Re: Webrev for first version of HSA offload integer reduce On Jun 9, 2014, at 10:50 AM, Eric Caspole > wrote: On 06/09/2014 01:07 PM, Christian Thalinger wrote: On Jun 9, 2014, at 9:40 AM, Caspole, Eric > wrote: Hi everybody, I put up a new webrev that allows some IntStream.reduce() to be offloaded to HSA: http://cr.openjdk.java.net/~ecaspole/graal_int_reduce1/webrev/ src/gpu/hsail/vm/hsailKernelArguments.hpp + virtual void collectArgs() { Does this really have to be in the .hpp file? I see that the base class has it in the .hpp file too. No it doesn't have to be there, it is just some historical thing I don't know why. I can change that. That would be good. Thanks. This works with a Sumatra webrev I will eventually add into the Sumatra JDK repo: http://cr.openjdk.java.net/~ecaspole/sumatra_int_reduce_1/webrev/ This combo allows offloading IntStream.parallel().reduce() for Integer::sum, Integer::max, and Integer::min. It builds a kernel from a hand made HSAIL string of code that gets called from the new Stream API diversion code in the Sumatra part. Eventually we hope to have regular compilation of user reduce functions but this allows us to do experiments with workloads before we get all the details of reduce compilation in place such as barrier placement and group size nuances. Presumably that will remove the hand-made code eventually? Yes. I just want to be able to expose this interesting functionality in the mean time. Makes sense. In the current Kaveri hardware version of Okra, it uses group size 256 by default and this reduce code is designed to work only with 256. Also, because it is a handmade kernel, it only runs with -UseHSAILDeoptimization and -UseCompressedOops. In the included reduce tests, they will skip if the correct flags are not there for the tests to run correctly. This webrev also changes the way the kernel args are processed to look at the actual args type rather than by the type signature of the kernel method. Regards, Eric From java at stefan-marr.de Tue Jun 10 15:07:14 2014 From: java at stefan-marr.de (Stefan Marr) Date: Tue, 10 Jun 2014 17:07:14 +0200 Subject: NPE when showing truffle expansions Message-ID: <1FAB0E7B-A85A-4567-A103-75C642C12FDE@stefan-marr.de> Hi: There seems to be an issue with static methods, apparently, the current check in place is not sufficient to guard for non-existing receivers. The following patch seems to help: diff --git a/graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/TruffleExpansionLogger.java b/graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/TruffleExpansionLogger.java index e90fb56..5dec542 100644 --- a/graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/TruffleExpansionLogger.java +++ b/graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/TruffleExpansionLogger.java @@ -50,7 +50,9 @@ public class TruffleExpansionLogger { int sourceMethodBci = callTarget.invoke().bci(); ResolvedJavaMethod targetMethod = callTarget.targetMethod(); ResolvedJavaType targetReceiverType = null; - if (!sourceMethod.isStatic() && callTarget.receiver().isConstant()) { + + boolean isStatic = sourceMethod.isStatic() || callTarget.isStatic(); + if (!isStatic && callTarget.receiver().isConstant()) { targetReceiverType = providers.getMetaAccess().lookupJavaType(callTarget.arguments().first().asConstant()); } Best regards Stefan -- Stefan Marr INRIA Lille - Nord Europe http://stefan-marr.de/research/ From laurent.daynes at oracle.com Tue Jun 10 15:28:52 2014 From: laurent.daynes at oracle.com (Laurent Daynes) Date: Tue, 10 Jun 2014 17:28:52 +0200 Subject: NPE when showing truffle expansions In-Reply-To: <1FAB0E7B-A85A-4567-A103-75C642C12FDE@stefan-marr.de> References: <1FAB0E7B-A85A-4567-A103-75C642C12FDE@stefan-marr.de> Message-ID: <53972434.4000603@oracle.com> +1 I've hit the very same problem today and had fixed it on my copy with a null test on the receiver. Laurent On 6/10/2014 5:07 PM, Stefan Marr wrote: > Hi: > > There seems to be an issue with static methods, apparently, the current check in place is not sufficient to guard for non-existing receivers. > The following patch seems to help: > > diff --git a/graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/TruffleExpansionLogger.java b/graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/TruffleExpansionLogger.java > index e90fb56..5dec542 100644 > --- a/graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/TruffleExpansionLogger.java > +++ b/graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/TruffleExpansionLogger.java > @@ -50,7 +50,9 @@ public class TruffleExpansionLogger { > int sourceMethodBci = callTarget.invoke().bci(); > ResolvedJavaMethod targetMethod = callTarget.targetMethod(); > ResolvedJavaType targetReceiverType = null; > - if (!sourceMethod.isStatic() && callTarget.receiver().isConstant()) { > + > + boolean isStatic = sourceMethod.isStatic() || callTarget.isStatic(); > + if (!isStatic && callTarget.receiver().isConstant()) { > targetReceiverType = providers.getMetaAccess().lookupJavaType(callTarget.arguments().first().asConstant()); > } > > > Best regards > Stefan > -- Laurent Daynes Oracle Labs From miguel.m.garcia at oracle.com Tue Jun 10 15:46:05 2014 From: miguel.m.garcia at oracle.com (Miguel Garcia Gutierrez) Date: Tue, 10 Jun 2014 08:46:05 -0700 (PDT) Subject: a discussion on inlining heuristics, anyone? Message-ID: After a long, long trail of refactoring and documenting [1] the inliner, the time is ripe to actually improve the inlining heuristics. I've included below a few candidate ideas, please feel free to share your observations about what's working (or not) and what you'd do differently (and why) around inlining. Don't say later you weren't asked for input. The rules of the game are: (a) the inliner explores inlining candidates depth-first, propagating the additional information a caller has about arguments (in particular constants) thus specializing the callee(s) to such additional information. (b) provided the thus specialized inlining candidates meet certain criteria, inlining is performed: the current "stack top" during depth-first search has one of its callsites replaced with the body of callee(s), adding in general more callsites to the "stack top" (c) after some rounds of the above, the stack of inlining candidates eventually collapses back to the root method on which inlining was launched. Depth-first is good in that it minimizes the working set, the biggest trade-off being that the interplay between different inlining alternatives (for different callsites contained in the same caller) can't be taken into account. That would require "breadth-first" exploration. The main knobs that can be turned during depth-first search are just two: (1) from the callsites a caller contains, one is picked to become a candidate for inlining, in CallsiteHolderExplorable.popInvoke() (2) each feasible target method (as given by the type-profile for the receiver) is explored before inlining (ie its method body is peeked into). Implementation-wise, an InlineableGraph is built for that target. This is the one opportunity there is to evaluate the merits of inlining such target before actually doing so. The difference between (1) and (2) is the information available to make the decision. Picking a callsite in (1) must rely only on knowledge about the arguments as opposed to knowing (in the general case) anything about the feasible targets; precisely those feasible targets are determined *for that particular callsite* during (2). Even with an InlineableGraph at hand we can't "see" beyond that immediate target (ie we can't explore yet the callesites it contains, that's what item 1 is about). Still, the above offers quite some leeway. Candidates ideas: (1.a) a priority-queue to pick "promising" callsites first For example, a callsite receiving freshly instantiated objects (eg, anonymous closures) seems promising. Why? First, once inlined, escape analysis might notice they don't escape Second, accesses to final fields of freshly instantiated objects can avoid one indirection level (provided the constructors is also inlined, here's where "bread-first serch" would help) (2.a) an InlineableGraph may also prepare a summary of the usages of parameters. The idea is for such summary to record whether the target method uses one of its parameters as method-receiver or for field-accesses In terms of closures, or the Command pattern in Java, such callees should be inlined to convert the accesses in question from mega to monomorphic. With the summary, a more informed inlining decision can be made. Those are the ideas I've managed to come up with so far, one for each of (1) and (2). Comments? Miguel [1] http://hg.openjdk.java.net/graal/graal From doug.simon at oracle.com Tue Jun 10 16:43:17 2014 From: doug.simon at oracle.com (Doug Simon) Date: Tue, 10 Jun 2014 18:43:17 +0200 Subject: mx gate dacapo problem? In-Reply-To: References: Message-ID: <3587FC8E-DD95-42ED-B05C-859E4399F219@oracle.com> This is a known problem since I made initialization of the Graal runtime lazy: https://lafo.ssw.uni-linz.ac.at/hg/basic-graal/rev/66a9286203a2 It will be solved by removing the Graal compilation queue. However, there are still unresolved performance issues when using the native queues. Until they?re resolved, I?ll push a change that reverts to eager initialization of the Graal runtime. -Doug On Jun 9, 2014, at 7:40 PM, Caspole, Eric wrote: > Has anyone else noticed, something seems wrong with the Dacapo part of "mx gate" since about last Friday or so. > Unfortunately it seems to take more than 30 minutes of building and running to get the failure point. > Thanks, > Eric > > > ===== DaCapo 9.12 fop starting warmup 5 ===== > ===== DaCapo 9.12 fop completed warmup 5 in 1521 msec ===== > ===== DaCapo 9.12 fop starting warmup 6 ===== > ===== DaCapo 9.12 fop completed warmup 6 in 1142 msec ===== > ===== DaCapo 9.12 fop starting warmup 7 ===== > ===== DaCapo 9.12 fop completed warmup 7 in 833 msec ===== > ===== DaCapo 9.12 fop starting ===== > ===== DaCapo 9.12 fop PASSED in 717 msec ===== > gate: 09 Jun 2014 10:41:44: END: DaCapo-fop:fastdebug [0:00:15.784107] > gate: 09 Jun 2014 10:41:44: BEGIN: DaCapo-sunflow:fastdebug > Using scaled threading model. 4 processors detected, 4 threads used to drive the workload, in a possible range of [1,256] > ===== DaCapo 9.12 sunflow starting warmup 1 ===== > ===== DaCapo 9.12 sunflow completed warmup 1 in 27979 msec ===== > ===== DaCapo 9.12 sunflow starting ===== > ===== DaCapo 9.12 sunflow PASSED in 6483 msec ===== > gate: 09 Jun 2014 10:42:19: END: DaCapo-sunflow:fastdebug [0:00:35.180180] > gate: 09 Jun 2014 10:42:19: BEGIN: Scala-DaCapo-kiama:fastdebug > Error: Could not find or load main class Harness > gate: 09 Jun 2014 10:42:19: ABORT: Scala-DaCapo-kiama:fastdebug [0:00:00.271493] > Traceback (most recent call last): > File "/home/ecaspole/views/graal-default/graal/mx/mx_graal.py", line 1363, in gate > gate_body(args, tasks) > File "/home/ecaspole/views/graal-default/graal/mx/mx_graal.py", line 1245, in _basic_gate_body > t.abort(test.name + ' Failed') > File "/home/ecaspole/views/graal-default/graal/mx/mx_graal.py", line 1191, in abort > mx.abort(codeOrMessage) > File "/home/ecaspole/views/graal-default/graal/mxtool/mx.py", line 1877, in abort > raise SystemExit(codeOrMessage) > SystemExit: Scala-DaCapo-kiama Failed > gate: 09 Jun 2014 10:42:19: ABORT: Gate [0:56:26.247938] > Scala-DaCapo-kiama Failed > From christian.thalinger at oracle.com Tue Jun 10 17:17:51 2014 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Tue, 10 Jun 2014 10:17:51 -0700 Subject: webrev to extend hsail allocation to allow gpu to refill tlab In-Reply-To: References: <4172060C-E15B-4FA2-965C-CC19E62C445C@oracle.com> Message-ID: graal/com.oracle.graal.lir.hsail/src/com/oracle/graal/lir/hsail/HSAILMove.java + /** + * A LoadOp that uses the HSAIL ld_acq instruction + **/ + public static class LoadAcquireOp extends LoadOp { Please use the Java convention of: /** * */ in this file and all the others (if it applies). src/gpu/hsail/vm/gpu_hsail.cpp -void * Hsail::_device_context = NULL; +void* Hsail::_device_context = NULL; jint Hsail::_notice_safepoints = false; If you started to have names aligned you should keep it or get rid of it. + /** + * We avoid HSAILAllocationInfo logic if kernel does not allocate + * in which case the donor_thread array passed in will be null + */ + HSAILAllocationInfo* allocInfo = (donor_threads == NULL ? NULL : new HSAILAllocationInfo(donor_threads, dimX, allocBytesPerWorkitem)); Don?t use Doxygen-style method comments in code; just regular /* ? */. src/gpu/hsail/vm/gpu_hsail.hpp There are some space left, e.g.: + HSAILTlabInfo ** _cur_tlab_info; // copy of what was in the HSAILAllocationInfo, to avoid an extra indirection + HSAILAllocationInfo * _alloc_info; and a couple more. src/gpu/hsail/vm/hsailJavaCallArguments.hpp - JavaCallArguments *_javaArgs; + JavaCallArguments*_javaArgs; Here is a space missing. Thanks for the changes. It looks much better already. The thing I mentioned about multi-line comments was mainly for Java code and you still have them in e.g. graal/com.oracle.graal.hotspot.hsail/src/com/oracle/graal/hotspot/hsail/replacements/HSAILNewObjectSnippets.java On Jun 9, 2014, at 2:11 PM, Deneau, Tom wrote: > I have tried to address Christian's comments in > > http://cr.openjdk.java.net/~tdeneau/graal-webrevs/webrev-hsail-refill-tlab-gpu-v2 > > -- Tom > > > From: Christian Thalinger [mailto:christian.thalinger at oracle.com] > Sent: Monday, June 09, 2014 11:41 AM > To: Deneau, Tom > Cc: graal-dev at openjdk.java.net > Subject: Re: webrev to extend hsail allocation to allow gpu to refill tlab > > graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/HotSpotVMConfig.java > > Remove the space between the type and * for e.g. HSAILAllocationInfo *. Same in other files like src/gpu/hsail/vm/vmStructs_hsail.hpp. > graal/com.oracle.graal.lir.hsail/src/com/oracle/graal/lir/hsail/HSAILMove.java > > + public LoadOp(Kind kind, AllocatableValue result, HSAILAddressValue address, LIRFrameState state, boolean useLoadAcquire) { > + public StoreOp(Kind kind, HSAILAddressValue address, AllocatableValue input, LIRFrameState state, boolean useRelease) { > I would prefer separate LoadAcquireOp/StoreReleaseOp classes. It makes the uses more readable. > > src/gpu/hsail/vm/gpu_hsail_Tlab.hpp > 26 #define GPU_HSAIL_TLAB_HPP > To be consistent with other header defines this should be: > 26 #define GPU_HSAIL_VM_GPU_HSAIL_TLAB_HPP > It seems this needs to be changed in existing files too. > > As a general comment, can we make multi-line comments C-style (/* ? */) comments instead of C++ style (// ?)? The C-style comments reformat themselves automatically if changed while the C++ ones don?t. > > On Jun 9, 2014, at 9:28 AM, Christian Thalinger wrote: > > > I have the webrev still open ;-) > > On Jun 9, 2014, at 8:25 AM, Deneau, Tom wrote: > > > Hi all -- > > Has anyone had a chance to look at this webrev posted last Tuesday? > > -- Tom > > > -----Original Message----- > From: Deneau, Tom > Sent: Tuesday, June 03, 2014 4:27 PM > To: graal-dev at openjdk.java.net > Subject: webrev to extend hsail allocation to allow gpu to refill tlab > > I have placed a webrev up at > http://cr.openjdk.java.net/~tdeneau/graal-webrevs/webrev-hsail-refill- > tlab-gpu > which we would like to get checked into the graal trunk. > > This webrev extends the existing hsail heap allocation logic. In the > existing logic, when a workitem cannot allocate from the current tlab, > it just deoptimizes. In this webrev, we add logic to allocate a new > tlab from the gpu. > > The algorithm must deal with the fact that multiple hsa workitems can > share a single tlab, and so multiple workitems can "overflow". A > workitem can tell if it is the "first overflower" and the first > overflower is charged with getting a new tlab while the other workitems > wait for the new tlab to be announced. > > Workitems access a tlab thru a fixed register (sort of like a thread > register) which instead of pointing to a donor thread now points to a > HSAILTlabInfo structure, which is sort of a subset of a full tlab > struct, containing just the fields that we would actually use on the > gpu. > > struct HSAILTlabInfo { > HeapWord * _start; // normal vm tlab fields, > start, top, end, etc. > HeapWord * _top; > HeapWord * _end; > // additional data not in a normal tlab > HeapWord * _lastGoodTop; // first overflower records > this > JavaThread * _donor_thread; // donor thread associated > with this tlabInfo > } > > The first overflower grabs a new tlabInfo structure and allocates a new > tlab (using edenAllocate) and "publishes" the new tlabInfo for other > workitems to start using. See the routine called > allocateFromTlabSlowPath in HSAILNewObjectSnippets. > > Eventually when hsail function calls are supported, this slow path will > not be inlined but will be called as a stub. > > Other changes: > > * the allocation-related logic was removed from gpu_hsail.cpp into > gpu_hsail_tlab.hpp. The HSAILHotSpotNmethod now keeps track of > whether a kernel uses allocation and avoids this logic if it does > not. > > * Before the kernel runs, the donor thread tlabs are used to set > up the initial tlabInfo records, and a tlab allocation is done > here if the donor thread tlab is empty. > > * When kernel is finished running, the cpu side will see a list > of one or more HSAILTlabInfos and basically postprocesses > these, fixing up any overflows and making them parsable and > copying them back to the appropriate donor thread as needed. > > * the inter-workitem communication required the use of the hsail > instructions for load_acquire and store_release from the > snippets. The HSAILDirectLoadAcquireNode and > HSAILDirectStoreReleaseNode with associated NodeIntrinsics were > created to handle this. A node for creating a workitemabsid > instruction was also created, it is not used in the algorithm as > such but was useful for adding debug traces. > > * In HSAILHotSpotBackend, the logic to decide whether a kernel uses > allocation or not was made more precise. (This flag is also made > available at execute time.) There were several atomic_add > related tests were falsely being marked as requiring > HSAILAllocation and thus HSAILDeoptimization support. This > marking was removed. > > -- Tom Deneau From christian.thalinger at oracle.com Tue Jun 10 17:26:55 2014 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Tue, 10 Jun 2014 10:26:55 -0700 Subject: webrev to enable arraycopy support in hsail backend In-Reply-To: References: Message-ID: <85A5A357-4A6B-434D-8DCD-9E41ECAE11EF@oracle.com> graal/com.oracle.graal.hotspot.hsail/src/com/oracle/graal/hotspot/hsail/HSAILHotSpotReplacementsImpl.java + // Register the special arraycopy snippet handling + // This basically ignores the sense of the CallArrayCopy flag + // and always directs to the snippets from UnsafeArrayCopyNode Can you change this and other comments to multi-line comments? Otherwise it looks good. A general question: HSAIL has a lot of tests. Is there any way to make them common tests so that they are executed on CPUs and GPUs? On Jun 10, 2014, at 7:47 AM, Deneau, Tom wrote: > I placed a small webrev up at > http://cr.openjdk.java.net/~tdeneau/graal-webrevs/webrev-hsail-arraycopy-support/webrev/ > > The purpose is to allow System.arraycopy (or at least most flavors of it) to be used in hsail kernels. Note that even if kernels do not use it directly, System.arrayCopy is used in many JDK routines, for example Stringbuilder.append(), ArrayList.get, etc. One flavor that is not supported yet is for example an Object array copy where the destination is a superclass of the source. > > The changes to HSAILHotSpotReplacementsImpl.java is just a way to take the non-foreign-call path (which hsail kernels cannot handle) regardless of the sense of the global flag CallArrayCopy (default true). > > The rest of the webrev is either new specific arraycopy tests, or enabling of some tests that were previously ignored because they needed arraycopy support. > > -- Tom > From christian.thalinger at oracle.com Tue Jun 10 17:31:10 2014 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Tue, 10 Jun 2014 10:31:10 -0700 Subject: Webrev for first version of HSA offload integer reduce In-Reply-To: References: <1E9B0B70-CC27-44F5-A85A-C84B93EDCD96@oracle.com> <5395F3F0.8060508@amd.com>, Message-ID: <9B0C46EF-9D4E-44C5-9AA3-1CBBA15F82C4@oracle.com> Thanks; much better. One thing I missed during my last review is that all the tests have the wrong copyright year and an author comment: 34 /** 35 * 36 * @author user1 37 */ Can you remove these? On Jun 10, 2014, at 8:03 AM, Caspole, Eric wrote: > I moved collectArgs into the cpp files for both classes here: > http://cr.openjdk.java.net/~ecaspole/graal_int_reduce1/02/webrev/ > Thanks, > Eric > > > From: Christian Thalinger [christian.thalinger at oracle.com] > Sent: Monday, June 09, 2014 2:15 PM > To: Caspole, Eric > Cc: graal-dev at openjdk.java.net; sumatra-dev at openjdk.java.net > Subject: Re: Webrev for first version of HSA offload integer reduce > > > On Jun 9, 2014, at 10:50 AM, Eric Caspole wrote: > >> >> >> On 06/09/2014 01:07 PM, Christian Thalinger wrote: >>> >>> On Jun 9, 2014, at 9:40 AM, Caspole, Eric >> > wrote: >>> >>>> Hi everybody, >>>> I put up a new webrev that allows some IntStream.reduce() to be >>>> offloaded to HSA: >>>> >>>> http://cr.openjdk.java.net/~ecaspole/graal_int_reduce1/webrev/ >>> >>> >>> src/gpu/hsail/vm/hsailKernelArguments.hpp >>> >>> + virtual void collectArgs() { >>> >>> Does this really have to be in the .hpp file? I see that the base class >>> has it in the .hpp file too. >> >> No it doesn't have to be there, it is just some historical thing I don't know why. I can change that. > > That would be good. Thanks. > >> >>> >>>> >>>> This works with a Sumatra webrev I will eventually add into the >>>> Sumatra JDK repo: >>>> >>>> http://cr.openjdk.java.net/~ecaspole/sumatra_int_reduce_1/webrev/ >>>> >>>> This combo allows offloading IntStream.parallel().reduce() for >>>> Integer::sum, Integer::max, and Integer::min. It builds a kernel from >>>> a hand made HSAIL string of code that gets called from the new Stream >>>> API diversion code in the Sumatra part. >>>> >>>> Eventually we hope to have regular compilation of user reduce >>>> functions but this allows us to do experiments with workloads before >>>> we get all the details of reduce compilation in place such as barrier >>>> placement and group size nuances. >>> >>> Presumably that will remove the hand-made code eventually? >> >> Yes. I just want to be able to expose this interesting functionality in the mean time. > > Makes sense. > >> >>> >>>> >>>> In the current Kaveri hardware version of Okra, it uses group size 256 >>>> by default and this reduce code is designed to work only with 256. >>>> Also, because it is a handmade kernel, it only runs with >>>> -UseHSAILDeoptimization and -UseCompressedOops. >>>> In the included reduce tests, they will skip if the correct flags are >>>> not there for the tests to run correctly. >>>> >>>> This webrev also changes the way the kernel args are processed to look >>>> at the actual args type rather than by the type signature of the >>>> kernel method. >>>> Regards, >>>> Eric From tom.deneau at amd.com Tue Jun 10 19:11:45 2014 From: tom.deneau at amd.com (Deneau, Tom) Date: Tue, 10 Jun 2014 19:11:45 +0000 Subject: webrev to enable arraycopy support in hsail backend In-Reply-To: <85A5A357-4A6B-434D-8DCD-9E41ECAE11EF@oracle.com> References: <85A5A357-4A6B-434D-8DCD-9E41ECAE11EF@oracle.com> Message-ID: Christian -- Regarding the HSAIL tests being repurposed for CPU, I think with a little bit of work they could be used to compare say a server compile (C1 or C2) to a graal compile and make sure the results match. Or is there already a framework for that kind of comparison? I admit I haven't spent much time looking at the non-hsail tests. -- Tom From: Christian Thalinger [mailto:christian.thalinger at oracle.com] Sent: Tuesday, June 10, 2014 12:27 PM To: Deneau, Tom Cc: graal-dev at openjdk.java.net Subject: Re: webrev to enable arraycopy support in hsail backend graal/com.oracle.graal.hotspot.hsail/src/com/oracle/graal/hotspot/hsail/HSAILHotSpotReplacementsImpl.java + // Register the special arraycopy snippet handling + // This basically ignores the sense of the CallArrayCopy flag + // and always directs to the snippets from UnsafeArrayCopyNode Can you change this and other comments to multi-line comments? Otherwise it looks good. A general question: HSAIL has a lot of tests. Is there any way to make them common tests so that they are executed on CPUs and GPUs? On Jun 10, 2014, at 7:47 AM, Deneau, Tom > wrote: I placed a small webrev up at http://cr.openjdk.java.net/~tdeneau/graal-webrevs/webrev-hsail-arraycopy-support/webrev/ The purpose is to allow System.arraycopy (or at least most flavors of it) to be used in hsail kernels. Note that even if kernels do not use it directly, System.arrayCopy is used in many JDK routines, for example Stringbuilder.append(), ArrayList.get, etc. One flavor that is not supported yet is for example an Object array copy where the destination is a superclass of the source. The changes to HSAILHotSpotReplacementsImpl.java is just a way to take the non-foreign-call path (which hsail kernels cannot handle) regardless of the sense of the global flag CallArrayCopy (default true). The rest of the webrev is either new specific arraycopy tests, or enabling of some tests that were previously ignored because they needed arraycopy support. -- Tom From tom.deneau at amd.com Tue Jun 10 19:38:57 2014 From: tom.deneau at amd.com (Deneau, Tom) Date: Tue, 10 Jun 2014 19:38:57 +0000 Subject: webrev to extend hsail allocation to allow gpu to refill tlab In-Reply-To: References: <4172060C-E15B-4FA2-965C-CC19E62C445C@oracle.com> Message-ID: Christian -- OK a new version is available at http://cr.openjdk.java.net/~tdeneau/graal-webrevs/webrev-hsail-refill-tlab-gpu-v3 I reverted to c++ style multiline comments in the c++ files, since that's what was being used in other files. In the java code I did change some multi-line comments to be /* ... */ style. -- Tom From: Christian Thalinger [mailto:christian.thalinger at oracle.com] Sent: Tuesday, June 10, 2014 12:18 PM To: Deneau, Tom Cc: graal-dev at openjdk.java.net Subject: Re: webrev to extend hsail allocation to allow gpu to refill tlab graal/com.oracle.graal.lir.hsail/src/com/oracle/graal/lir/hsail/HSAILMove.java + /** + * A LoadOp that uses the HSAIL ld_acq instruction + **/ + public static class LoadAcquireOp extends LoadOp { Please use the Java convention of: /** * */ in this file and all the others (if it applies). src/gpu/hsail/vm/gpu_hsail.cpp -void * Hsail::_device_context = NULL; +void* Hsail::_device_context = NULL; jint Hsail::_notice_safepoints = false; If you started to have names aligned you should keep it or get rid of it. + /** + * We avoid HSAILAllocationInfo logic if kernel does not allocate + * in which case the donor_thread array passed in will be null + */ + HSAILAllocationInfo* allocInfo = (donor_threads == NULL ? NULL : new HSAILAllocationInfo(donor_threads, dimX, allocBytesPerWorkitem)); Don't use Doxygen-style method comments in code; just regular /* ... */. src/gpu/hsail/vm/gpu_hsail.hpp There are some space left, e.g.: + HSAILTlabInfo ** _cur_tlab_info; // copy of what was in the HSAILAllocationInfo, to avoid an extra indirection + HSAILAllocationInfo * _alloc_info; and a couple more. src/gpu/hsail/vm/hsailJavaCallArguments.hpp - JavaCallArguments *_javaArgs; + JavaCallArguments*_javaArgs; Here is a space missing. Thanks for the changes. It looks much better already. The thing I mentioned about multi-line comments was mainly for Java code and you still have them in e.g. graal/com.oracle.graal.hotspot.hsail/src/com/oracle/graal/hotspot/hsail/replacements/HSAILNewObjectSnippets.java On Jun 9, 2014, at 2:11 PM, Deneau, Tom > wrote: I have tried to address Christian's comments in http://cr.openjdk.java.net/~tdeneau/graal-webrevs/webrev-hsail-refill-tlab-gpu-v2 -- Tom From: Christian Thalinger [mailto:christian.thalinger at oracle.com] Sent: Monday, June 09, 2014 11:41 AM To: Deneau, Tom Cc: graal-dev at openjdk.java.net Subject: Re: webrev to extend hsail allocation to allow gpu to refill tlab graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/HotSpotVMConfig.java Remove the space between the type and * for e.g. HSAILAllocationInfo *. Same in other files like src/gpu/hsail/vm/vmStructs_hsail.hpp. graal/com.oracle.graal.lir.hsail/src/com/oracle/graal/lir/hsail/HSAILMove.java + public LoadOp(Kind kind, AllocatableValue result, HSAILAddressValue address, LIRFrameState state, boolean useLoadAcquire) { + public StoreOp(Kind kind, HSAILAddressValue address, AllocatableValue input, LIRFrameState state, boolean useRelease) { I would prefer separate LoadAcquireOp/StoreReleaseOp classes. It makes the uses more readable. src/gpu/hsail/vm/gpu_hsail_Tlab.hpp 26 #define GPU_HSAIL_TLAB_HPP To be consistent with other header defines this should be: 26 #define GPU_HSAIL_VM_GPU_HSAIL_TLAB_HPP It seems this needs to be changed in existing files too. As a general comment, can we make multi-line comments C-style (/* ... */) comments instead of C++ style (// ...)? The C-style comments reformat themselves automatically if changed while the C++ ones don't. On Jun 9, 2014, at 9:28 AM, Christian Thalinger > wrote: I have the webrev still open ;-) On Jun 9, 2014, at 8:25 AM, Deneau, Tom > wrote: Hi all -- Has anyone had a chance to look at this webrev posted last Tuesday? -- Tom -----Original Message----- From: Deneau, Tom Sent: Tuesday, June 03, 2014 4:27 PM To: graal-dev at openjdk.java.net Subject: webrev to extend hsail allocation to allow gpu to refill tlab I have placed a webrev up at http://cr.openjdk.java.net/~tdeneau/graal-webrevs/webrev-hsail-refill- tlab-gpu which we would like to get checked into the graal trunk. This webrev extends the existing hsail heap allocation logic. In the existing logic, when a workitem cannot allocate from the current tlab, it just deoptimizes. In this webrev, we add logic to allocate a new tlab from the gpu. The algorithm must deal with the fact that multiple hsa workitems can share a single tlab, and so multiple workitems can "overflow". A workitem can tell if it is the "first overflower" and the first overflower is charged with getting a new tlab while the other workitems wait for the new tlab to be announced. Workitems access a tlab thru a fixed register (sort of like a thread register) which instead of pointing to a donor thread now points to a HSAILTlabInfo structure, which is sort of a subset of a full tlab struct, containing just the fields that we would actually use on the gpu. struct HSAILTlabInfo { HeapWord * _start; // normal vm tlab fields, start, top, end, etc. HeapWord * _top; HeapWord * _end; // additional data not in a normal tlab HeapWord * _lastGoodTop; // first overflower records this JavaThread * _donor_thread; // donor thread associated with this tlabInfo } The first overflower grabs a new tlabInfo structure and allocates a new tlab (using edenAllocate) and "publishes" the new tlabInfo for other workitems to start using. See the routine called allocateFromTlabSlowPath in HSAILNewObjectSnippets. Eventually when hsail function calls are supported, this slow path will not be inlined but will be called as a stub. Other changes: * the allocation-related logic was removed from gpu_hsail.cpp into gpu_hsail_tlab.hpp. The HSAILHotSpotNmethod now keeps track of whether a kernel uses allocation and avoids this logic if it does not. * Before the kernel runs, the donor thread tlabs are used to set up the initial tlabInfo records, and a tlab allocation is done here if the donor thread tlab is empty. * When kernel is finished running, the cpu side will see a list of one or more HSAILTlabInfos and basically postprocesses these, fixing up any overflows and making them parsable and copying them back to the appropriate donor thread as needed. * the inter-workitem communication required the use of the hsail instructions for load_acquire and store_release from the snippets. The HSAILDirectLoadAcquireNode and HSAILDirectStoreReleaseNode with associated NodeIntrinsics were created to handle this. A node for creating a workitemabsid instruction was also created, it is not used in the algorithm as such but was useful for adding debug traces. * In HSAILHotSpotBackend, the logic to decide whether a kernel uses allocation or not was made more precise. (This flag is also made available at execute time.) There were several atomic_add related tests were falsely being marked as requiring HSAILAllocation and thus HSAILDeoptimization support. This marking was removed. -- Tom Deneau From tom.deneau at amd.com Tue Jun 10 19:49:38 2014 From: tom.deneau at amd.com (Deneau, Tom) Date: Tue, 10 Jun 2014 19:49:38 +0000 Subject: webrev to extend hsail allocation to allow gpu to refill tlab In-Reply-To: References: <4172060C-E15B-4FA2-965C-CC19E62C445C@oracle.com> Message-ID: Sorry formatting error, instead use http://cr.openjdk.java.net/~tdeneau/graal-webrevs/webrev-hsail-refill-tlab-gpu-v4 > -----Original Message----- > From: graal-dev [mailto:graal-dev-bounces at openjdk.java.net] On Behalf Of > Deneau, Tom > Sent: Tuesday, June 10, 2014 2:39 PM > To: Christian Thalinger > Cc: graal-dev at openjdk.java.net > Subject: RE: webrev to extend hsail allocation to allow gpu to refill > tlab > > Christian -- > > OK a new version is available at > > http://cr.openjdk.java.net/~tdeneau/graal-webrevs/webrev-hsail-refill- > tlab-gpu-v3 > > I reverted to c++ style multiline comments in the c++ files, since > that's what was being used in other files. In the java code I did > change some multi-line comments to be /* ... */ style. > > -- Tom > > From: Christian Thalinger [mailto:christian.thalinger at oracle.com] > Sent: Tuesday, June 10, 2014 12:18 PM > To: Deneau, Tom > Cc: graal-dev at openjdk.java.net > Subject: Re: webrev to extend hsail allocation to allow gpu to refill > tlab > > graal/com.oracle.graal.lir.hsail/src/com/oracle/graal/lir/hsail/HSAILMov > e.java > > > > + /** > > + * A LoadOp that uses the HSAIL ld_acq instruction > > + **/ > > + public static class LoadAcquireOp extends LoadOp { > > Please use the Java convention of: > > /** > * > */ > > in this file and all the others (if it applies). > > src/gpu/hsail/vm/gpu_hsail.cpp > > -void * Hsail::_device_context = NULL; > > +void* Hsail::_device_context = NULL; > > jint Hsail::_notice_safepoints = false; > If you started to have names aligned you should keep it or get rid of > it. > > > + /** > > + * We avoid HSAILAllocationInfo logic if kernel does not allocate > > + * in which case the donor_thread array passed in will be null > > + */ > > + HSAILAllocationInfo* allocInfo = (donor_threads == NULL ? NULL : new > HSAILAllocationInfo(donor_threads, dimX, allocBytesPerWorkitem)); > > Don't use Doxygen-style method comments in code; just regular /* ... */. > > src/gpu/hsail/vm/gpu_hsail.hpp > There are some space left, e.g.: > > > + HSAILTlabInfo ** _cur_tlab_info; // copy of what was in the > HSAILAllocationInfo, to avoid an extra indirection > > + HSAILAllocationInfo * _alloc_info; > > and a couple more. > > src/gpu/hsail/vm/hsailJavaCallArguments.hpp > > - JavaCallArguments *_javaArgs; > > + JavaCallArguments*_javaArgs; > > Here is a space missing. > > Thanks for the changes. It looks much better already. > > The thing I mentioned about multi-line comments was mainly for Java code > and you still have them in e.g. > graal/com.oracle.graal.hotspot.hsail/src/com/oracle/graal/hotspot/hsail/ > replacements/HSAILNewObjectSnippets.java > > > On Jun 9, 2014, at 2:11 PM, Deneau, Tom > > wrote: > > > I have tried to address Christian's comments in > > http://cr.openjdk.java.net/~tdeneau/graal-webrevs/webrev-hsail-refill- > tlab-gpu-v2 > > -- Tom > > > > From: Christian Thalinger [mailto:christian.thalinger at oracle.com] > Sent: Monday, June 09, 2014 11:41 AM > To: Deneau, Tom > Cc: graal-dev at openjdk.java.net > Subject: Re: webrev to extend hsail allocation to allow gpu to refill > tlab > > graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/HotSpotVMCon > fig.java > Remove the space between the type and * for e.g. HSAILAllocationInfo *. > Same in other files like src/gpu/hsail/vm/vmStructs_hsail.hpp. > graal/com.oracle.graal.lir.hsail/src/com/oracle/graal/lir/hsail/HSAILMov > e.java > > + public LoadOp(Kind kind, AllocatableValue result, > HSAILAddressValue address, LIRFrameState state, boolean useLoadAcquire) > { > > + public StoreOp(Kind kind, HSAILAddressValue address, > AllocatableValue input, LIRFrameState state, boolean useRelease) { > I would prefer separate LoadAcquireOp/StoreReleaseOp classes. It makes > the uses more readable. > > src/gpu/hsail/vm/gpu_hsail_Tlab.hpp > > 26 #define GPU_HSAIL_TLAB_HPP > To be consistent with other header defines this should be: > > 26 #define GPU_HSAIL_VM_GPU_HSAIL_TLAB_HPP > It seems this needs to be changed in existing files too. > > As a general comment, can we make multi-line comments C-style (/* ... > */) comments instead of C++ style (// ...)? The C-style comments > reformat themselves automatically if changed while the C++ ones don't. > > On Jun 9, 2014, at 9:28 AM, Christian Thalinger > > > wrote: > > > > I have the webrev still open ;-) > > On Jun 9, 2014, at 8:25 AM, Deneau, Tom > > wrote: > > > > Hi all -- > > Has anyone had a chance to look at this webrev posted last Tuesday? > > -- Tom > > > > -----Original Message----- > From: Deneau, Tom > Sent: Tuesday, June 03, 2014 4:27 PM > To: graal-dev at openjdk.java.net > Subject: webrev to extend hsail allocation to allow gpu to refill tlab > > I have placed a webrev up at > http://cr.openjdk.java.net/~tdeneau/graal-webrevs/webrev-hsail-refill- > tlab-gpu > which we would like to get checked into the graal trunk. > > This webrev extends the existing hsail heap allocation logic. In the > existing logic, when a workitem cannot allocate from the current tlab, > it just deoptimizes. In this webrev, we add logic to allocate a new > tlab from the gpu. > > The algorithm must deal with the fact that multiple hsa workitems can > share a single tlab, and so multiple workitems can "overflow". A > workitem can tell if it is the "first overflower" and the first > overflower is charged with getting a new tlab while the other workitems > wait for the new tlab to be announced. > > Workitems access a tlab thru a fixed register (sort of like a thread > register) which instead of pointing to a donor thread now points to a > HSAILTlabInfo structure, which is sort of a subset of a full tlab > struct, containing just the fields that we would actually use on the > gpu. > > struct HSAILTlabInfo { > HeapWord * _start; // normal vm tlab fields, > start, top, end, etc. > HeapWord * _top; > HeapWord * _end; > // additional data not in a normal tlab > HeapWord * _lastGoodTop; // first overflower records > this > JavaThread * _donor_thread; // donor thread associated > with this tlabInfo > } > > The first overflower grabs a new tlabInfo structure and allocates a new > tlab (using edenAllocate) and "publishes" the new tlabInfo for other > workitems to start using. See the routine called > allocateFromTlabSlowPath in HSAILNewObjectSnippets. > > Eventually when hsail function calls are supported, this slow path will > not be inlined but will be called as a stub. > > Other changes: > > * the allocation-related logic was removed from gpu_hsail.cpp into > gpu_hsail_tlab.hpp. The HSAILHotSpotNmethod now keeps track of > whether a kernel uses allocation and avoids this logic if it does > not. > > * Before the kernel runs, the donor thread tlabs are used to set > up the initial tlabInfo records, and a tlab allocation is done > here if the donor thread tlab is empty. > > * When kernel is finished running, the cpu side will see a list > of one or more HSAILTlabInfos and basically postprocesses > these, fixing up any overflows and making them parsable and > copying them back to the appropriate donor thread as needed. > > * the inter-workitem communication required the use of the hsail > instructions for load_acquire and store_release from the > snippets. The HSAILDirectLoadAcquireNode and > HSAILDirectStoreReleaseNode with associated NodeIntrinsics were > created to handle this. A node for creating a workitemabsid > instruction was also created, it is not used in the algorithm as > such but was useful for adding debug traces. > > * In HSAILHotSpotBackend, the logic to decide whether a kernel uses > allocation or not was made more precise. (This flag is also made > available at execute time.) There were several atomic_add > related tests were falsely being marked as requiring > HSAILAllocation and thus HSAILDeoptimization support. This > marking was removed. > > -- Tom Deneau From christian.thalinger at oracle.com Tue Jun 10 19:51:24 2014 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Tue, 10 Jun 2014 12:51:24 -0700 Subject: webrev to extend hsail allocation to allow gpu to refill tlab In-Reply-To: References: <4172060C-E15B-4FA2-965C-CC19E62C445C@oracle.com> Message-ID: <921B2DFC-496A-4C64-B5F5-C5B065F1B0C6@oracle.com> On Jun 10, 2014, at 12:38 PM, Deneau, Tom wrote: > Christian -- > > OK a new version is available at > > http://cr.openjdk.java.net/~tdeneau/graal-webrevs/webrev-hsail-refill-tlab-gpu-v3 > > I reverted to c++ style multiline comments in the c++ files, since that's what was being used in other files. In the java code I did change some multi-line comments to be /* ? */ style. Thanks. Some indent seems to be off but a mx eclipseformat should fix that. > > -- Tom > > From: Christian Thalinger [mailto:christian.thalinger at oracle.com] > Sent: Tuesday, June 10, 2014 12:18 PM > To: Deneau, Tom > Cc: graal-dev at openjdk.java.net > Subject: Re: webrev to extend hsail allocation to allow gpu to refill tlab > > graal/com.oracle.graal.lir.hsail/src/com/oracle/graal/lir/hsail/HSAILMove.java > > > + /** > + * A LoadOp that uses the HSAIL ld_acq instruction > + **/ > + public static class LoadAcquireOp extends LoadOp { > > Please use the Java convention of: > > /** > * > */ > > in this file and all the others (if it applies). > > src/gpu/hsail/vm/gpu_hsail.cpp > > -void * Hsail::_device_context = NULL; > +void* Hsail::_device_context = NULL; > jint Hsail::_notice_safepoints = false; > If you started to have names aligned you should keep it or get rid of it. > > + /** > + * We avoid HSAILAllocationInfo logic if kernel does not allocate > + * in which case the donor_thread array passed in will be null > + */ > + HSAILAllocationInfo* allocInfo = (donor_threads == NULL ? NULL : new HSAILAllocationInfo(donor_threads, dimX, allocBytesPerWorkitem)); > > Don?t use Doxygen-style method comments in code; just regular /* ? */. > > src/gpu/hsail/vm/gpu_hsail.hpp > > There are some space left, e.g.: > > + HSAILTlabInfo ** _cur_tlab_info; // copy of what was in the HSAILAllocationInfo, to avoid an extra indirection > + HSAILAllocationInfo * _alloc_info; > > and a couple more. > > src/gpu/hsail/vm/hsailJavaCallArguments.hpp > > - JavaCallArguments *_javaArgs; > + JavaCallArguments*_javaArgs; > > Here is a space missing. > > Thanks for the changes. It looks much better already. > > The thing I mentioned about multi-line comments was mainly for Java code and you still have them in e.g. graal/com.oracle.graal.hotspot.hsail/src/com/oracle/graal/hotspot/hsail/replacements/HSAILNewObjectSnippets.java > > > On Jun 9, 2014, at 2:11 PM, Deneau, Tom wrote: > > > I have tried to address Christian's comments in > > http://cr.openjdk.java.net/~tdeneau/graal-webrevs/webrev-hsail-refill-tlab-gpu-v2 > > -- Tom > > > > From: Christian Thalinger [mailto:christian.thalinger at oracle.com] > Sent: Monday, June 09, 2014 11:41 AM > To: Deneau, Tom > Cc: graal-dev at openjdk.java.net > Subject: Re: webrev to extend hsail allocation to allow gpu to refill tlab > > graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/HotSpotVMConfig.java > > Remove the space between the type and * for e.g. HSAILAllocationInfo *. Same in other files like src/gpu/hsail/vm/vmStructs_hsail.hpp. > graal/com.oracle.graal.lir.hsail/src/com/oracle/graal/lir/hsail/HSAILMove.java > > + public LoadOp(Kind kind, AllocatableValue result, HSAILAddressValue address, LIRFrameState state, boolean useLoadAcquire) { > + public StoreOp(Kind kind, HSAILAddressValue address, AllocatableValue input, LIRFrameState state, boolean useRelease) { > I would prefer separate LoadAcquireOp/StoreReleaseOp classes. It makes the uses more readable. > > src/gpu/hsail/vm/gpu_hsail_Tlab.hpp > 26 #define GPU_HSAIL_TLAB_HPP > To be consistent with other header defines this should be: > 26 #define GPU_HSAIL_VM_GPU_HSAIL_TLAB_HPP > It seems this needs to be changed in existing files too. > > As a general comment, can we make multi-line comments C-style (/* ? */) comments instead of C++ style (// ?)? The C-style comments reformat themselves automatically if changed while the C++ ones don?t. > > On Jun 9, 2014, at 9:28 AM, Christian Thalinger wrote: > > > > I have the webrev still open ;-) > > On Jun 9, 2014, at 8:25 AM, Deneau, Tom wrote: > > > > Hi all -- > > Has anyone had a chance to look at this webrev posted last Tuesday? > > -- Tom > > > > -----Original Message----- > From: Deneau, Tom > Sent: Tuesday, June 03, 2014 4:27 PM > To: graal-dev at openjdk.java.net > Subject: webrev to extend hsail allocation to allow gpu to refill tlab > > I have placed a webrev up at > http://cr.openjdk.java.net/~tdeneau/graal-webrevs/webrev-hsail-refill- > tlab-gpu > which we would like to get checked into the graal trunk. > > This webrev extends the existing hsail heap allocation logic. In the > existing logic, when a workitem cannot allocate from the current tlab, > it just deoptimizes. In this webrev, we add logic to allocate a new > tlab from the gpu. > > The algorithm must deal with the fact that multiple hsa workitems can > share a single tlab, and so multiple workitems can "overflow". A > workitem can tell if it is the "first overflower" and the first > overflower is charged with getting a new tlab while the other workitems > wait for the new tlab to be announced. > > Workitems access a tlab thru a fixed register (sort of like a thread > register) which instead of pointing to a donor thread now points to a > HSAILTlabInfo structure, which is sort of a subset of a full tlab > struct, containing just the fields that we would actually use on the > gpu. > > struct HSAILTlabInfo { > HeapWord * _start; // normal vm tlab fields, > start, top, end, etc. > HeapWord * _top; > HeapWord * _end; > // additional data not in a normal tlab > HeapWord * _lastGoodTop; // first overflower records > this > JavaThread * _donor_thread; // donor thread associated > with this tlabInfo > } > > The first overflower grabs a new tlabInfo structure and allocates a new > tlab (using edenAllocate) and "publishes" the new tlabInfo for other > workitems to start using. See the routine called > allocateFromTlabSlowPath in HSAILNewObjectSnippets. > > Eventually when hsail function calls are supported, this slow path will > not be inlined but will be called as a stub. > > Other changes: > > * the allocation-related logic was removed from gpu_hsail.cpp into > gpu_hsail_tlab.hpp. The HSAILHotSpotNmethod now keeps track of > whether a kernel uses allocation and avoids this logic if it does > not. > > * Before the kernel runs, the donor thread tlabs are used to set > up the initial tlabInfo records, and a tlab allocation is done > here if the donor thread tlab is empty. > > * When kernel is finished running, the cpu side will see a list > of one or more HSAILTlabInfos and basically postprocesses > these, fixing up any overflows and making them parsable and > copying them back to the appropriate donor thread as needed. > > * the inter-workitem communication required the use of the hsail > instructions for load_acquire and store_release from the > snippets. The HSAILDirectLoadAcquireNode and > HSAILDirectStoreReleaseNode with associated NodeIntrinsics were > created to handle this. A node for creating a workitemabsid > instruction was also created, it is not used in the algorithm as > such but was useful for adding debug traces. > > * In HSAILHotSpotBackend, the logic to decide whether a kernel uses > allocation or not was made more precise. (This flag is also made > available at execute time.) There were several atomic_add > related tests were falsely being marked as requiring > HSAILAllocation and thus HSAILDeoptimization support. This > marking was removed. > > -- Tom Deneau From christian.thalinger at oracle.com Tue Jun 10 19:54:13 2014 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Tue, 10 Jun 2014 12:54:13 -0700 Subject: webrev to extend hsail allocation to allow gpu to refill tlab In-Reply-To: References: <4172060C-E15B-4FA2-965C-CC19E62C445C@oracle.com> Message-ID: <68BC2519-09FA-482F-A80A-2B142397B022@oracle.com> On Jun 10, 2014, at 12:49 PM, Deneau, Tom wrote: > Sorry formatting error, instead use > > http://cr.openjdk.java.net/~tdeneau/graal-webrevs/webrev-hsail-refill-tlab-gpu-v4 Yes, that looks better. > > >> -----Original Message----- >> From: graal-dev [mailto:graal-dev-bounces at openjdk.java.net] On Behalf Of >> Deneau, Tom >> Sent: Tuesday, June 10, 2014 2:39 PM >> To: Christian Thalinger >> Cc: graal-dev at openjdk.java.net >> Subject: RE: webrev to extend hsail allocation to allow gpu to refill >> tlab >> >> Christian -- >> >> OK a new version is available at >> >> http://cr.openjdk.java.net/~tdeneau/graal-webrevs/webrev-hsail-refill- >> tlab-gpu-v3 >> >> I reverted to c++ style multiline comments in the c++ files, since >> that's what was being used in other files. In the java code I did >> change some multi-line comments to be /* ... */ style. >> >> -- Tom >> >> From: Christian Thalinger [mailto:christian.thalinger at oracle.com] >> Sent: Tuesday, June 10, 2014 12:18 PM >> To: Deneau, Tom >> Cc: graal-dev at openjdk.java.net >> Subject: Re: webrev to extend hsail allocation to allow gpu to refill >> tlab >> >> graal/com.oracle.graal.lir.hsail/src/com/oracle/graal/lir/hsail/HSAILMov >> e.java >> >> >> >> + /** >> >> + * A LoadOp that uses the HSAIL ld_acq instruction >> >> + **/ >> >> + public static class LoadAcquireOp extends LoadOp { >> >> Please use the Java convention of: >> >> /** >> * >> */ >> >> in this file and all the others (if it applies). >> >> src/gpu/hsail/vm/gpu_hsail.cpp >> >> -void * Hsail::_device_context = NULL; >> >> +void* Hsail::_device_context = NULL; >> >> jint Hsail::_notice_safepoints = false; >> If you started to have names aligned you should keep it or get rid of >> it. >> >> >> + /** >> >> + * We avoid HSAILAllocationInfo logic if kernel does not allocate >> >> + * in which case the donor_thread array passed in will be null >> >> + */ >> >> + HSAILAllocationInfo* allocInfo = (donor_threads == NULL ? NULL : new >> HSAILAllocationInfo(donor_threads, dimX, allocBytesPerWorkitem)); >> >> Don't use Doxygen-style method comments in code; just regular /* ... */. >> >> src/gpu/hsail/vm/gpu_hsail.hpp >> There are some space left, e.g.: >> >> >> + HSAILTlabInfo ** _cur_tlab_info; // copy of what was in the >> HSAILAllocationInfo, to avoid an extra indirection >> >> + HSAILAllocationInfo * _alloc_info; >> >> and a couple more. >> >> src/gpu/hsail/vm/hsailJavaCallArguments.hpp >> >> - JavaCallArguments *_javaArgs; >> >> + JavaCallArguments*_javaArgs; >> >> Here is a space missing. >> >> Thanks for the changes. It looks much better already. >> >> The thing I mentioned about multi-line comments was mainly for Java code >> and you still have them in e.g. >> graal/com.oracle.graal.hotspot.hsail/src/com/oracle/graal/hotspot/hsail/ >> replacements/HSAILNewObjectSnippets.java >> >> >> On Jun 9, 2014, at 2:11 PM, Deneau, Tom >> > wrote: >> >> >> I have tried to address Christian's comments in >> >> http://cr.openjdk.java.net/~tdeneau/graal-webrevs/webrev-hsail-refill- >> tlab-gpu-v2 >> >> -- Tom >> >> >> >> From: Christian Thalinger [mailto:christian.thalinger at oracle.com] >> Sent: Monday, June 09, 2014 11:41 AM >> To: Deneau, Tom >> Cc: graal-dev at openjdk.java.net >> Subject: Re: webrev to extend hsail allocation to allow gpu to refill >> tlab >> >> graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/HotSpotVMCon >> fig.java >> Remove the space between the type and * for e.g. HSAILAllocationInfo *. >> Same in other files like src/gpu/hsail/vm/vmStructs_hsail.hpp. >> graal/com.oracle.graal.lir.hsail/src/com/oracle/graal/lir/hsail/HSAILMov >> e.java >> >> + public LoadOp(Kind kind, AllocatableValue result, >> HSAILAddressValue address, LIRFrameState state, boolean useLoadAcquire) >> { >> >> + public StoreOp(Kind kind, HSAILAddressValue address, >> AllocatableValue input, LIRFrameState state, boolean useRelease) { >> I would prefer separate LoadAcquireOp/StoreReleaseOp classes. It makes >> the uses more readable. >> >> src/gpu/hsail/vm/gpu_hsail_Tlab.hpp >> >> 26 #define GPU_HSAIL_TLAB_HPP >> To be consistent with other header defines this should be: >> >> 26 #define GPU_HSAIL_VM_GPU_HSAIL_TLAB_HPP >> It seems this needs to be changed in existing files too. >> >> As a general comment, can we make multi-line comments C-style (/* ... >> */) comments instead of C++ style (// ...)? The C-style comments >> reformat themselves automatically if changed while the C++ ones don't. >> >> On Jun 9, 2014, at 9:28 AM, Christian Thalinger >> > >> wrote: >> >> >> >> I have the webrev still open ;-) >> >> On Jun 9, 2014, at 8:25 AM, Deneau, Tom >> > wrote: >> >> >> >> Hi all -- >> >> Has anyone had a chance to look at this webrev posted last Tuesday? >> >> -- Tom >> >> >> >> -----Original Message----- >> From: Deneau, Tom >> Sent: Tuesday, June 03, 2014 4:27 PM >> To: graal-dev at openjdk.java.net >> Subject: webrev to extend hsail allocation to allow gpu to refill tlab >> >> I have placed a webrev up at >> http://cr.openjdk.java.net/~tdeneau/graal-webrevs/webrev-hsail-refill- >> tlab-gpu >> which we would like to get checked into the graal trunk. >> >> This webrev extends the existing hsail heap allocation logic. In the >> existing logic, when a workitem cannot allocate from the current tlab, >> it just deoptimizes. In this webrev, we add logic to allocate a new >> tlab from the gpu. >> >> The algorithm must deal with the fact that multiple hsa workitems can >> share a single tlab, and so multiple workitems can "overflow". A >> workitem can tell if it is the "first overflower" and the first >> overflower is charged with getting a new tlab while the other workitems >> wait for the new tlab to be announced. >> >> Workitems access a tlab thru a fixed register (sort of like a thread >> register) which instead of pointing to a donor thread now points to a >> HSAILTlabInfo structure, which is sort of a subset of a full tlab >> struct, containing just the fields that we would actually use on the >> gpu. >> >> struct HSAILTlabInfo { >> HeapWord * _start; // normal vm tlab fields, >> start, top, end, etc. >> HeapWord * _top; >> HeapWord * _end; >> // additional data not in a normal tlab >> HeapWord * _lastGoodTop; // first overflower records >> this >> JavaThread * _donor_thread; // donor thread associated >> with this tlabInfo >> } >> >> The first overflower grabs a new tlabInfo structure and allocates a new >> tlab (using edenAllocate) and "publishes" the new tlabInfo for other >> workitems to start using. See the routine called >> allocateFromTlabSlowPath in HSAILNewObjectSnippets. >> >> Eventually when hsail function calls are supported, this slow path will >> not be inlined but will be called as a stub. >> >> Other changes: >> >> * the allocation-related logic was removed from gpu_hsail.cpp into >> gpu_hsail_tlab.hpp. The HSAILHotSpotNmethod now keeps track of >> whether a kernel uses allocation and avoids this logic if it does >> not. >> >> * Before the kernel runs, the donor thread tlabs are used to set >> up the initial tlabInfo records, and a tlab allocation is done >> here if the donor thread tlab is empty. >> >> * When kernel is finished running, the cpu side will see a list >> of one or more HSAILTlabInfos and basically postprocesses >> these, fixing up any overflows and making them parsable and >> copying them back to the appropriate donor thread as needed. >> >> * the inter-workitem communication required the use of the hsail >> instructions for load_acquire and store_release from the >> snippets. The HSAILDirectLoadAcquireNode and >> HSAILDirectStoreReleaseNode with associated NodeIntrinsics were >> created to handle this. A node for creating a workitemabsid >> instruction was also created, it is not used in the algorithm as >> such but was useful for adding debug traces. >> >> * In HSAILHotSpotBackend, the logic to decide whether a kernel uses >> allocation or not was made more precise. (This flag is also made >> available at execute time.) There were several atomic_add >> related tests were falsely being marked as requiring >> HSAILAllocation and thus HSAILDeoptimization support. This >> marking was removed. >> >> -- Tom Deneau From tom.deneau at amd.com Tue Jun 10 19:58:30 2014 From: tom.deneau at amd.com (Deneau, Tom) Date: Tue, 10 Jun 2014 19:58:30 +0000 Subject: webrev to enable arraycopy support in hsail backend In-Reply-To: <85A5A357-4A6B-434D-8DCD-9E41ECAE11EF@oracle.com> References: <85A5A357-4A6B-434D-8DCD-9E41ECAE11EF@oracle.com> Message-ID: Christian -- A new version addressing your comments is available in http://cr.openjdk.java.net/~tdeneau/graal-webrevs/webrev-hsail-arraycopy-support-v2 -- Tom From: Christian Thalinger [mailto:christian.thalinger at oracle.com] Sent: Tuesday, June 10, 2014 12:27 PM To: Deneau, Tom Cc: graal-dev at openjdk.java.net Subject: Re: webrev to enable arraycopy support in hsail backend graal/com.oracle.graal.hotspot.hsail/src/com/oracle/graal/hotspot/hsail/HSAILHotSpotReplacementsImpl.java + // Register the special arraycopy snippet handling + // This basically ignores the sense of the CallArrayCopy flag + // and always directs to the snippets from UnsafeArrayCopyNode Can you change this and other comments to multi-line comments? Otherwise it looks good. A general question: HSAIL has a lot of tests. Is there any way to make them common tests so that they are executed on CPUs and GPUs? On Jun 10, 2014, at 7:47 AM, Deneau, Tom > wrote: I placed a small webrev up at http://cr.openjdk.java.net/~tdeneau/graal-webrevs/webrev-hsail-arraycopy-support/webrev/ The purpose is to allow System.arraycopy (or at least most flavors of it) to be used in hsail kernels. Note that even if kernels do not use it directly, System.arrayCopy is used in many JDK routines, for example Stringbuilder.append(), ArrayList.get, etc. One flavor that is not supported yet is for example an Object array copy where the destination is a superclass of the source. The changes to HSAILHotSpotReplacementsImpl.java is just a way to take the non-foreign-call path (which hsail kernels cannot handle) regardless of the sense of the global flag CallArrayCopy (default true). The rest of the webrev is either new specific arraycopy tests, or enabling of some tests that were previously ignored because they needed arraycopy support. -- Tom From christian.thalinger at oracle.com Tue Jun 10 21:42:36 2014 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Tue, 10 Jun 2014 14:42:36 -0700 Subject: webrev to enable arraycopy support in hsail backend In-Reply-To: References: <85A5A357-4A6B-434D-8DCD-9E41ECAE11EF@oracle.com> Message-ID: <1413CA34-F8A2-437F-8549-EE49684899B7@oracle.com> That looks good. Can I suggest to use full sentences with punctuation in comments? Otherwise it might look odd on a reformat. On Jun 10, 2014, at 12:58 PM, Deneau, Tom wrote: > Christian -- > > A new version addressing your comments is available in > > http://cr.openjdk.java.net/~tdeneau/graal-webrevs/webrev-hsail-arraycopy-support-v2 > > -- Tom > > > > From: Christian Thalinger [mailto:christian.thalinger at oracle.com] > Sent: Tuesday, June 10, 2014 12:27 PM > To: Deneau, Tom > Cc: graal-dev at openjdk.java.net > Subject: Re: webrev to enable arraycopy support in hsail backend > > graal/com.oracle.graal.hotspot.hsail/src/com/oracle/graal/hotspot/hsail/HSAILHotSpotReplacementsImpl.java > > > + // Register the special arraycopy snippet handling > + // This basically ignores the sense of the CallArrayCopy flag > + // and always directs to the snippets from UnsafeArrayCopyNode > > Can you change this and other comments to multi-line comments? Otherwise it looks good. > > A general question: HSAIL has a lot of tests. Is there any way to make them common tests so that they are executed on CPUs and GPUs? > > On Jun 10, 2014, at 7:47 AM, Deneau, Tom wrote: > > > I placed a small webrev up at > http://cr.openjdk.java.net/~tdeneau/graal-webrevs/webrev-hsail-arraycopy-support/webrev/ > > The purpose is to allow System.arraycopy (or at least most flavors of it) to be used in hsail kernels. Note that even if kernels do not use it directly, System.arrayCopy is used in many JDK routines, for example Stringbuilder.append(), ArrayList.get, etc. One flavor that is not supported yet is for example an Object array copy where the destination is a superclass of the source. > > The changes to HSAILHotSpotReplacementsImpl.java is just a way to take the non-foreign-call path (which hsail kernels cannot handle) regardless of the sense of the global flag CallArrayCopy (default true). > > The rest of the webrev is either new specific arraycopy tests, or enabling of some tests that were previously ignored because they needed arraycopy support. > > -- Tom > From tom.rodriguez at oracle.com Tue Jun 10 21:44:42 2014 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Tue, 10 Jun 2014 14:44:42 -0700 Subject: webrev to enable arraycopy support in hsail backend In-Reply-To: References: <85A5A357-4A6B-434D-8DCD-9E41ECAE11EF@oracle.com> Message-ID: On Jun 10, 2014, at 12:11 PM, Deneau, Tom wrote: > Christian -- > > Regarding the HSAIL tests being repurposed for CPU, I think with a little bit of work they could be used to compare say a server compile (C1 or C2) to a graal compile and make sure the results match. Or is there already a framework for that kind of comparison? > I admit I haven't spent much time looking at the non-hsail tests. That?s a main point of running tests with a hosted version of graal vs a tiered graal. You can compare the results of a graal compilation with a regular hotspot execution using the GraalCompiler.test* methods. Testing array copy would be a little different since it modifies the arguments so you'd need separate copies of the arguments for the expected and actual calls and then compare them afterwards. You might have to override some methods to perform the required checking but GraalCompilerTest is factored a bit with many of the methods being protected for just this reason. tom > > -- Tom > > From: Christian Thalinger [mailto:christian.thalinger at oracle.com] > Sent: Tuesday, June 10, 2014 12:27 PM > To: Deneau, Tom > Cc: graal-dev at openjdk.java.net > Subject: Re: webrev to enable arraycopy support in hsail backend > > graal/com.oracle.graal.hotspot.hsail/src/com/oracle/graal/hotspot/hsail/HSAILHotSpotReplacementsImpl.java > > > + // Register the special arraycopy snippet handling > > + // This basically ignores the sense of the CallArrayCopy flag > > + // and always directs to the snippets from UnsafeArrayCopyNode > > Can you change this and other comments to multi-line comments? Otherwise it looks good. > > A general question: HSAIL has a lot of tests. Is there any way to make them common tests so that they are executed on CPUs and GPUs? > > > On Jun 10, 2014, at 7:47 AM, Deneau, Tom > wrote: > > > I placed a small webrev up at > http://cr.openjdk.java.net/~tdeneau/graal-webrevs/webrev-hsail-arraycopy-support/webrev/ > > The purpose is to allow System.arraycopy (or at least most flavors of it) to be used in hsail kernels. Note that even if kernels do not use it directly, System.arrayCopy is used in many JDK routines, for example Stringbuilder.append(), ArrayList.get, etc. One flavor that is not supported yet is for example an Object array copy where the destination is a superclass of the source. > > The changes to HSAILHotSpotReplacementsImpl.java is just a way to take the non-foreign-call path (which hsail kernels cannot handle) regardless of the sense of the global flag CallArrayCopy (default true). > > The rest of the webrev is either new specific arraycopy tests, or enabling of some tests that were previously ignored because they needed arraycopy support. > > -- Tom > From doug.simon at oracle.com Tue Jun 10 21:45:31 2014 From: doug.simon at oracle.com (Doug Simon) Date: Tue, 10 Jun 2014 23:45:31 +0200 Subject: webrev to enable arraycopy support in hsail backend In-Reply-To: <1413CA34-F8A2-437F-8549-EE49684899B7@oracle.com> References: <85A5A357-4A6B-434D-8DCD-9E41ECAE11EF@oracle.com> <1413CA34-F8A2-437F-8549-EE49684899B7@oracle.com> Message-ID: Good advice. As I integrated Tom?s changes I made changes to some of the comments following this suggestion. -Doug On Jun 10, 2014, at 11:42 PM, Christian Thalinger wrote: > That looks good. Can I suggest to use full sentences with punctuation in comments? Otherwise it might look odd on a reformat. > > On Jun 10, 2014, at 12:58 PM, Deneau, Tom wrote: > >> Christian -- >> >> A new version addressing your comments is available in >> >> http://cr.openjdk.java.net/~tdeneau/graal-webrevs/webrev-hsail-arraycopy-support-v2 >> >> -- Tom >> >> >> >> From: Christian Thalinger [mailto:christian.thalinger at oracle.com] >> Sent: Tuesday, June 10, 2014 12:27 PM >> To: Deneau, Tom >> Cc: graal-dev at openjdk.java.net >> Subject: Re: webrev to enable arraycopy support in hsail backend >> >> graal/com.oracle.graal.hotspot.hsail/src/com/oracle/graal/hotspot/hsail/HSAILHotSpotReplacementsImpl.java >> >> >> + // Register the special arraycopy snippet handling >> + // This basically ignores the sense of the CallArrayCopy flag >> + // and always directs to the snippets from UnsafeArrayCopyNode >> >> Can you change this and other comments to multi-line comments? Otherwise it looks good. >> >> A general question: HSAIL has a lot of tests. Is there any way to make them common tests so that they are executed on CPUs and GPUs? >> >> On Jun 10, 2014, at 7:47 AM, Deneau, Tom wrote: >> >> >> I placed a small webrev up at >> http://cr.openjdk.java.net/~tdeneau/graal-webrevs/webrev-hsail-arraycopy-support/webrev/ >> >> The purpose is to allow System.arraycopy (or at least most flavors of it) to be used in hsail kernels. Note that even if kernels do not use it directly, System.arrayCopy is used in many JDK routines, for example Stringbuilder.append(), ArrayList.get, etc. One flavor that is not supported yet is for example an Object array copy where the destination is a superclass of the source. >> >> The changes to HSAILHotSpotReplacementsImpl.java is just a way to take the non-foreign-call path (which hsail kernels cannot handle) regardless of the sense of the global flag CallArrayCopy (default true). >> >> The rest of the webrev is either new specific arraycopy tests, or enabling of some tests that were previously ignored because they needed arraycopy support. >> >> -- Tom From doug.simon at oracle.com Wed Jun 11 01:00:05 2014 From: doug.simon at oracle.com (doug.simon at oracle.com) Date: Wed, 11 Jun 2014 01:00:05 +0000 Subject: hg: graal/graal: 5 new changesets Message-ID: <201406110100.s5B10CnI009321@aojmv0008> Changeset: 8d0202b354fb Author: Miguel Garcia Date: 2014-06-10 15:35 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/8d0202b354fb [inliner] de-duplicate parameters for callsites with duplicate arguments ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/inlining/info/elem/InlineableGraph.java Changeset: 2023d6120416 Author: Doug Simon Date: 2014-06-10 18:50 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/2023d6120416 disable lazy initialization of Graal runtime until Graal compilation queue is removed (GRAAL-798) ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/CompilationQueue.java Changeset: b38191cd1665 Author: Doug Simon Date: 2014-06-10 18:52 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/b38191cd1665 removed code to make recording usages optional for ConstantNodes (GRAAL-508) ! graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/FlowSensitiveReductionTest.java ! graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/GraalCompilerTest.java ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/gen/NodeLIRBuilder.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/phases/AheadOfTimeVerificationPhase.java ! graal/com.oracle.graal.lir/src/com/oracle/graal/lir/gen/LIRGenerator.java ! graal/com.oracle.graal.lir/src/com/oracle/graal/lir/gen/LIRGeneratorTool.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/ConstantNode.java Changeset: b6ab7e7fa0a5 Author: Doug Simon Date: 2014-06-10 19:08 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/b6ab7e7fa0a5 Merge. Changeset: 77783d8a45ef Author: Tom Rodriguez Date: 2014-06-10 14:45 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/77783d8a45ef handle other primitive array types in clone ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/ObjectCloneNode.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/ObjectCloneSnippets.java From doug.simon at oracle.com Wed Jun 11 09:33:53 2014 From: doug.simon at oracle.com (doug.simon at oracle.com) Date: Wed, 11 Jun 2014 09:33:53 +0000 Subject: hg: graal/graal: 5 new changesets Message-ID: <201406110934.s5B9Y0Y3019932@aojmv0008> Changeset: 06eedda53e14 Author: Doug Simon Date: 2014-06-10 22:36 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/06eedda53e14 HSAIL: add support to allocate new TLAB from GPU Contributed-by: Tom Deneau ! graal/com.oracle.graal.compiler.hsail.test.infra/src/com/oracle/graal/compiler/hsail/test/infra/GraalKernelTester.java ! graal/com.oracle.graal.compiler.hsail.test/src/com/oracle/graal/compiler/hsail/test/AtomicIntGetAndAddTest.java ! graal/com.oracle.graal.compiler.hsail.test/src/com/oracle/graal/compiler/hsail/test/AtomicIntGetAndSetTest.java ! graal/com.oracle.graal.compiler.hsail.test/src/com/oracle/graal/compiler/hsail/test/AtomicLongGetAndAddTest.java ! graal/com.oracle.graal.compiler.hsail.test/src/com/oracle/graal/compiler/hsail/test/AtomicLongGetAndSetTest.java ! graal/com.oracle.graal.compiler.hsail.test/src/com/oracle/graal/compiler/hsail/test/lambda/AtomicIntAddAndGetGidTest.java ! graal/com.oracle.graal.compiler.hsail.test/src/com/oracle/graal/compiler/hsail/test/lambda/AtomicIntAddAndGetTest.java ! graal/com.oracle.graal.compiler.hsail.test/src/com/oracle/graal/compiler/hsail/test/lambda/AtomicIntDecAndGetTest.java ! graal/com.oracle.graal.compiler.hsail.test/src/com/oracle/graal/compiler/hsail/test/lambda/AtomicIntGetAndAddTest.java ! graal/com.oracle.graal.compiler.hsail.test/src/com/oracle/graal/compiler/hsail/test/lambda/AtomicIntGetAndDecTest.java ! graal/com.oracle.graal.compiler.hsail.test/src/com/oracle/graal/compiler/hsail/test/lambda/AtomicIntGetAndIncTest.java ! graal/com.oracle.graal.compiler.hsail.test/src/com/oracle/graal/compiler/hsail/test/lambda/AtomicIntIncAndGetTest.java ! graal/com.oracle.graal.compiler.hsail.test/src/com/oracle/graal/compiler/hsail/test/lambda/AtomicLongAddAndGetTest.java ! graal/com.oracle.graal.compiler.hsail.test/src/com/oracle/graal/compiler/hsail/test/lambda/AtomicLongGetAndAddTest.java ! graal/com.oracle.graal.compiler.hsail.test/src/com/oracle/graal/compiler/hsail/test/lambda/AtomicLongGetAndIncTest.java ! graal/com.oracle.graal.compiler.hsail.test/src/com/oracle/graal/compiler/hsail/test/lambda/AtomicLongIncAndGetTest.java ! graal/com.oracle.graal.gpu/src/com/oracle/graal/gpu/ExternalCompilationResult.java ! graal/com.oracle.graal.hotspot.hsail/src/com/oracle/graal/hotspot/hsail/HSAILHotSpotBackend.java ! graal/com.oracle.graal.hotspot.hsail/src/com/oracle/graal/hotspot/hsail/HSAILHotSpotLIRGenerator.java + graal/com.oracle.graal.hotspot.hsail/src/com/oracle/graal/hotspot/hsail/replacements/HSAILDirectLoadAcquireNode.java + graal/com.oracle.graal.hotspot.hsail/src/com/oracle/graal/hotspot/hsail/replacements/HSAILDirectStoreReleaseNode.java ! graal/com.oracle.graal.hotspot.hsail/src/com/oracle/graal/hotspot/hsail/replacements/HSAILHotSpotReplacementsUtil.java ! graal/com.oracle.graal.hotspot.hsail/src/com/oracle/graal/hotspot/hsail/replacements/HSAILNewObjectSnippets.java + graal/com.oracle.graal.hotspot.hsail/src/com/oracle/graal/hotspot/hsail/replacements/HSAILWorkItemAbsIdNode.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/HotSpotVMConfig.java ! graal/com.oracle.graal.lir.hsail/src/com/oracle/graal/lir/hsail/HSAILMove.java ! graal/com.oracle.graal.replacements/src/com/oracle/graal/replacements/nodes/DirectReadNode.java ! graal/com.oracle.graal.replacements/src/com/oracle/graal/replacements/nodes/DirectStoreNode.java ! src/gpu/hsail/vm/gpu_hsail.cpp ! src/gpu/hsail/vm/gpu_hsail.hpp ! src/gpu/hsail/vm/gpu_hsail_Frame.hpp + src/gpu/hsail/vm/gpu_hsail_Tlab.hpp ! src/gpu/hsail/vm/hsailArgumentsBase.hpp ! src/gpu/hsail/vm/hsailJavaCallArguments.hpp ! src/gpu/hsail/vm/hsailKernelArguments.hpp ! src/gpu/hsail/vm/vmStructs_hsail.hpp ! src/share/vm/gc_interface/collectedHeap.hpp Changeset: 2d296658a24e Author: Doug Simon Date: 2014-06-10 22:56 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/2d296658a24e HSAIL: enable arraycopy support in backend Contributed-by: Tom Deneau ! graal/com.oracle.graal.compiler.hsail.test/src/com/oracle/graal/compiler/hsail/test/EscapingNewStringConcatTest.java ! graal/com.oracle.graal.compiler.hsail.test/src/com/oracle/graal/compiler/hsail/test/lambda/ArrayListGetTest.java + graal/com.oracle.graal.compiler.hsail.test/src/com/oracle/graal/compiler/hsail/test/lambda/ArrayListSetTest.java + graal/com.oracle.graal.compiler.hsail.test/src/com/oracle/graal/compiler/hsail/test/lambda/ByteArrayCopyConjointTest.java + graal/com.oracle.graal.compiler.hsail.test/src/com/oracle/graal/compiler/hsail/test/lambda/ByteArrayCopyDisjointTest.java + graal/com.oracle.graal.compiler.hsail.test/src/com/oracle/graal/compiler/hsail/test/lambda/CharArrayCopyConjointTest.java + graal/com.oracle.graal.compiler.hsail.test/src/com/oracle/graal/compiler/hsail/test/lambda/CharArrayCopyDisjointTest.java + graal/com.oracle.graal.compiler.hsail.test/src/com/oracle/graal/compiler/hsail/test/lambda/IntArrayCopyConjointTest.java + graal/com.oracle.graal.compiler.hsail.test/src/com/oracle/graal/compiler/hsail/test/lambda/IntArrayCopyDisjointTest.java + graal/com.oracle.graal.compiler.hsail.test/src/com/oracle/graal/compiler/hsail/test/lambda/LongArrayCopyConjointTest.java + graal/com.oracle.graal.compiler.hsail.test/src/com/oracle/graal/compiler/hsail/test/lambda/LongArrayCopyDisjointTest.java ! graal/com.oracle.graal.compiler.hsail.test/src/com/oracle/graal/compiler/hsail/test/lambda/NewStringEqualsTest.java + graal/com.oracle.graal.compiler.hsail.test/src/com/oracle/graal/compiler/hsail/test/lambda/ObjArrayCopyConjointTest.java + graal/com.oracle.graal.compiler.hsail.test/src/com/oracle/graal/compiler/hsail/test/lambda/ObjArrayCopyDisjointNonExactTest.java + graal/com.oracle.graal.compiler.hsail.test/src/com/oracle/graal/compiler/hsail/test/lambda/ObjArrayCopyDisjointTest.java + graal/com.oracle.graal.compiler.hsail.test/src/com/oracle/graal/compiler/hsail/test/lambda/StringBuilderTest.java + graal/com.oracle.graal.compiler.hsail.test/src/com/oracle/graal/compiler/hsail/test/lambda/StringSubsequenceTest.java + graal/com.oracle.graal.compiler.hsail.test/src/com/oracle/graal/compiler/hsail/test/lambda/StringSubstringTest.java ! graal/com.oracle.graal.hotspot.hsail/src/com/oracle/graal/hotspot/hsail/HSAILHotSpotBackend.java ! graal/com.oracle.graal.hotspot.hsail/src/com/oracle/graal/hotspot/hsail/HSAILHotSpotReplacementsImpl.java Changeset: 0dd4bbe37f19 Author: Doug Simon Date: 2014-06-11 08:35 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/0dd4bbe37f19 replace use of == with .equals ! graal/com.oracle.graal.lir.hsail/src/com/oracle/graal/lir/hsail/HSAILMove.java Changeset: df8d39e2000b Author: Doug Simon Date: 2014-06-11 08:35 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/df8d39e2000b Merge. Changeset: 46cf1de19854 Author: Doug Simon Date: 2014-06-11 09:26 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/46cf1de19854 added @Ignore to failing tests and commented out uses of System.out.println in tests ! graal/com.oracle.graal.compiler.hsail.test/src/com/oracle/graal/compiler/hsail/test/EscapingNewStringConcatTest.java ! graal/com.oracle.graal.compiler.hsail.test/src/com/oracle/graal/compiler/hsail/test/lambda/ArrayListGetTest.java ! graal/com.oracle.graal.compiler.hsail.test/src/com/oracle/graal/compiler/hsail/test/lambda/ArrayListSetTest.java ! graal/com.oracle.graal.compiler.hsail.test/src/com/oracle/graal/compiler/hsail/test/lambda/StringSubsequenceTest.java ! graal/com.oracle.graal.compiler.hsail.test/src/com/oracle/graal/compiler/hsail/test/lambda/StringSubstringTest.java From doug.simon at oracle.com Wed Jun 11 09:35:43 2014 From: doug.simon at oracle.com (Doug Simon) Date: Wed, 11 Jun 2014 11:35:43 +0200 Subject: Webrev for first version of HSA offload integer reduce In-Reply-To: References: <1E9B0B70-CC27-44F5-A85A-C84B93EDCD96@oracle.com> <5395F3F0.8060508@amd.com>, Message-ID: Eric, Sorry for the inconvenience, but can you please update to the tip which now includes Tom Deneau?s changesets and generate one more webrev. Thanks. -Doug On Jun 10, 2014, at 5:03 PM, Caspole, Eric wrote: > I moved collectArgs into the cpp files for both classes here: > http://cr.openjdk.java.net/~ecaspole/graal_int_reduce1/02/webrev/ > Thanks, > Eric > > > ________________________________ > From: Christian Thalinger [christian.thalinger at oracle.com] > Sent: Monday, June 09, 2014 2:15 PM > To: Caspole, Eric > Cc: graal-dev at openjdk.java.net; sumatra-dev at openjdk.java.net > Subject: Re: Webrev for first version of HSA offload integer reduce > > > On Jun 9, 2014, at 10:50 AM, Eric Caspole > wrote: > > > > On 06/09/2014 01:07 PM, Christian Thalinger wrote: > > On Jun 9, 2014, at 9:40 AM, Caspole, Eric > > wrote: > > Hi everybody, > I put up a new webrev that allows some IntStream.reduce() to be > offloaded to HSA: > > http://cr.openjdk.java.net/~ecaspole/graal_int_reduce1/webrev/ > > > src/gpu/hsail/vm/hsailKernelArguments.hpp > > + virtual void collectArgs() { > > Does this really have to be in the .hpp file? I see that the base class > has it in the .hpp file too. > > No it doesn't have to be there, it is just some historical thing I don't know why. I can change that. > > That would be good. Thanks. > > > > > This works with a Sumatra webrev I will eventually add into the > Sumatra JDK repo: > > http://cr.openjdk.java.net/~ecaspole/sumatra_int_reduce_1/webrev/ > > This combo allows offloading IntStream.parallel().reduce() for > Integer::sum, Integer::max, and Integer::min. It builds a kernel from > a hand made HSAIL string of code that gets called from the new Stream > API diversion code in the Sumatra part. > > Eventually we hope to have regular compilation of user reduce > functions but this allows us to do experiments with workloads before > we get all the details of reduce compilation in place such as barrier > placement and group size nuances. > > Presumably that will remove the hand-made code eventually? > > Yes. I just want to be able to expose this interesting functionality in the mean time. > > Makes sense. > > > > > In the current Kaveri hardware version of Okra, it uses group size 256 > by default and this reduce code is designed to work only with 256. > Also, because it is a handmade kernel, it only runs with > -UseHSAILDeoptimization and -UseCompressedOops. > In the included reduce tests, they will skip if the correct flags are > not there for the tests to run correctly. > > This webrev also changes the way the kernel args are processed to look > at the actual args type rather than by the type signature of the > kernel method. > Regards, > Eric > From Eric.Caspole at amd.com Wed Jun 11 17:37:23 2014 From: Eric.Caspole at amd.com (Caspole, Eric) Date: Wed, 11 Jun 2014 17:37:23 +0000 Subject: Webrev for first version of HSA offload integer reduce In-Reply-To: References: <1E9B0B70-CC27-44F5-A85A-C84B93EDCD96@oracle.com> <5395F3F0.8060508@amd.com>, , Message-ID: Hi Doug, OK, I merged up and fixed the copyright etc, it is here: http://cr.openjdk.java.net/~ecaspole/graal_int_reduce1/03/webrev/ let me know what you think, Eric ________________________________________ From: Doug Simon [doug.simon at oracle.com] Sent: Wednesday, June 11, 2014 5:35 AM To: Caspole, Eric Cc: Christian Thalinger; sumatra-dev at openjdk.java.net; graal-dev at openjdk.java.net Subject: Re: Webrev for first version of HSA offload integer reduce Eric, Sorry for the inconvenience, but can you please update to the tip which now includes Tom Deneau?s changesets and generate one more webrev. Thanks. -Doug On Jun 10, 2014, at 5:03 PM, Caspole, Eric wrote: > I moved collectArgs into the cpp files for both classes here: > http://cr.openjdk.java.net/~ecaspole/graal_int_reduce1/02/webrev/ > Thanks, > Eric > > > ________________________________ > From: Christian Thalinger [christian.thalinger at oracle.com] > Sent: Monday, June 09, 2014 2:15 PM > To: Caspole, Eric > Cc: graal-dev at openjdk.java.net; sumatra-dev at openjdk.java.net > Subject: Re: Webrev for first version of HSA offload integer reduce > > > On Jun 9, 2014, at 10:50 AM, Eric Caspole > wrote: > > > > On 06/09/2014 01:07 PM, Christian Thalinger wrote: > > On Jun 9, 2014, at 9:40 AM, Caspole, Eric > > wrote: > > Hi everybody, > I put up a new webrev that allows some IntStream.reduce() to be > offloaded to HSA: > > http://cr.openjdk.java.net/~ecaspole/graal_int_reduce1/webrev/ > > > src/gpu/hsail/vm/hsailKernelArguments.hpp > > + virtual void collectArgs() { > > Does this really have to be in the .hpp file? I see that the base class > has it in the .hpp file too. > > No it doesn't have to be there, it is just some historical thing I don't know why. I can change that. > > That would be good. Thanks. > > > > > This works with a Sumatra webrev I will eventually add into the > Sumatra JDK repo: > > http://cr.openjdk.java.net/~ecaspole/sumatra_int_reduce_1/webrev/ > > This combo allows offloading IntStream.parallel().reduce() for > Integer::sum, Integer::max, and Integer::min. It builds a kernel from > a hand made HSAIL string of code that gets called from the new Stream > API diversion code in the Sumatra part. > > Eventually we hope to have regular compilation of user reduce > functions but this allows us to do experiments with workloads before > we get all the details of reduce compilation in place such as barrier > placement and group size nuances. > > Presumably that will remove the hand-made code eventually? > > Yes. I just want to be able to expose this interesting functionality in the mean time. > > Makes sense. > > > > > In the current Kaveri hardware version of Okra, it uses group size 256 > by default and this reduce code is designed to work only with 256. > Also, because it is a handmade kernel, it only runs with > -UseHSAILDeoptimization and -UseCompressedOops. > In the included reduce tests, they will skip if the correct flags are > not there for the tests to run correctly. > > This webrev also changes the way the kernel args are processed to look > at the actual args type rather than by the type signature of the > kernel method. > Regards, > Eric > From doug.simon at oracle.com Thu Jun 12 01:00:06 2014 From: doug.simon at oracle.com (doug.simon at oracle.com) Date: Thu, 12 Jun 2014 01:00:06 +0000 Subject: hg: graal/graal: 5 new changesets Message-ID: <201406120100.s5C10Is7005481@aojmv0008> Changeset: 77cb0f0e5e3f Author: Roland Schatz Date: 2014-06-11 10:53 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/77cb0f0e5e3f Revert unnecessary encoding change in assembler (part of 03eda0a202e9). ! src/cpu/x86/vm/assembler_x86.cpp Changeset: 048943ad39bf Author: Roland Schatz Date: 2014-06-11 11:14 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/048943ad39bf Reuse existing address simplification code in visitDirectCompareAndSwap. ! graal/com.oracle.graal.hotspot.amd64/src/com/oracle/graal/hotspot/amd64/AMD64HotSpotNodeLIRBuilder.java Changeset: 640a875667fe Author: Roland Schatz Date: 2014-06-11 11:17 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/640a875667fe Remove dead code. ! graal/com.oracle.graal.compiler.amd64/src/com/oracle/graal/compiler/amd64/AMD64NodeLIRBuilder.java ! graal/com.oracle.graal.hotspot.amd64/src/com/oracle/graal/hotspot/amd64/AMD64HotSpotLIRGenerator.java ! graal/com.oracle.graal.hotspot.amd64/src/com/oracle/graal/hotspot/amd64/AMD64HotSpotNodeLIRBuilder.java Changeset: b37dbfdfbbfb Author: Lukas Stadler Date: 2014-06-10 12:11 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/b37dbfdfbbfb assertion mechanism for snippets and stubs ! graal/com.oracle.graal.hotspot.hsail/src/com/oracle/graal/hotspot/hsail/replacements/HSAILNewObjectSnippets.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/DefaultHotSpotLoweringProvider.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotHostForeignCallsProvider.java + graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/AssertionSnippets.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/HotSpotReplacementsUtil.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/NewObjectSnippets.java + graal/com.oracle.graal.replacements/src/com/oracle/graal/replacements/ReplacementsUtil.java + graal/com.oracle.graal.replacements/src/com/oracle/graal/replacements/nodes/AssertionNode.java Changeset: 0cdce0e2d122 Author: Christian Humer Date: 2014-06-11 18:15 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/0cdce0e2d122 Truffle: Added -G:+TraceTruffleCompilationAST flag. ! CHANGELOG.md ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/TruffleCompilerImpl.java ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/TruffleCompilerOptions.java From doug.simon at oracle.com Thu Jun 12 07:31:09 2014 From: doug.simon at oracle.com (Doug Simon) Date: Thu, 12 Jun 2014 09:31:09 +0200 Subject: Webrev for first version of HSA offload integer reduce In-Reply-To: References: <1E9B0B70-CC27-44F5-A85A-C84B93EDCD96@oracle.com> <5395F3F0.8060508@amd.com>, , Message-ID: <31CEC65D-0448-47A2-84B5-08F8781F9012@oracle.com> Eric, graal/com.oracle.graal.hotspot.hsail/src/com/oracle/graal/hotspot/hsail/ForEachToGraal.java: + // Preallocate kernel args array to reduce allocation rate + static Object args[] = new Object[3]; + + static final int desiredGlobalSizeMultiple = Integer.getInteger("com.amd.sumatra.reduce.globalsize.multiple", 1); + // Running with a larger global size seems to increase the performance for sum, + // but it might be different for other reductions so it is a knob + static final int globalSize = 1024 * desiredGlobalSizeMultiple; // requiredGroupSize * 8 * + // desiredGlobalSizeMultiple; + static final int result[] = new int[1]; The use of static fields ?args? and ?result' in ForEachToGraal.offloadIntReduceImpl() seems both dangerous (I don?t see any synchronization on the class) and unnecessary (the overhead of the kernel dispatch will surely outweigh the cost of allocating the arrays of size 1 and 3 respectively). Why cannot they just be made into local variables? Also, please delete commented out code like that at the end of globalSize declaration or provide extra comments as to why it is being kept around. + String REDUCE_OP = "/* Invalid */ "; + String ATOMIC_RESULT_PRODUCTION = "/* Invalid */ "; + if (reducerName.equals("sum")) { + REDUCE_OP = "add_u32 "; + ATOMIC_RESULT_PRODUCTION = "atomicnoret_add_global_u32 "; + } else if (reducerName.equals("max")) { + REDUCE_OP = "max_s32 "; + ATOMIC_RESULT_PRODUCTION = "atomicnoret_max_global_s32 "; + } else if (reducerName.equals("min")) { + REDUCE_OP = "min_s32 "; + ATOMIC_RESULT_PRODUCTION = "atomicnoret_min_global_s32 "; + } else { + return "/* Invalid */ "; + } Local variables should not be all upper case (REDUCE_OP -> reduceOp). This will be flagged by Checkstyle once it support Java8. src/gpu/hsail/vm/hsailArgumentsBase.hpp: + void recordNullObjectParameter() { + if (_first_null_parameter_index == -1) _first_null_parameter_index = _parameter_index; Please use braces and indentation even for single state statement blocks. -Doug On Jun 11, 2014, at 7:37 PM, Caspole, Eric wrote: > Hi Doug, > OK, I merged up and fixed the copyright etc, it is here: > > http://cr.openjdk.java.net/~ecaspole/graal_int_reduce1/03/webrev/ > > let me know what you think, > Eric > > > ________________________________________ > From: Doug Simon [doug.simon at oracle.com] > Sent: Wednesday, June 11, 2014 5:35 AM > To: Caspole, Eric > Cc: Christian Thalinger; sumatra-dev at openjdk.java.net; graal-dev at openjdk.java.net > Subject: Re: Webrev for first version of HSA offload integer reduce > > Eric, > > Sorry for the inconvenience, but can you please update to the tip which now includes Tom Deneau?s changesets and generate one more webrev. > > Thanks. > > -Doug > > On Jun 10, 2014, at 5:03 PM, Caspole, Eric wrote: > >> I moved collectArgs into the cpp files for both classes here: >> http://cr.openjdk.java.net/~ecaspole/graal_int_reduce1/02/webrev/ >> Thanks, >> Eric >> >> >> ________________________________ >> From: Christian Thalinger [christian.thalinger at oracle.com] >> Sent: Monday, June 09, 2014 2:15 PM >> To: Caspole, Eric >> Cc: graal-dev at openjdk.java.net; sumatra-dev at openjdk.java.net >> Subject: Re: Webrev for first version of HSA offload integer reduce >> >> >> On Jun 9, 2014, at 10:50 AM, Eric Caspole > wrote: >> >> >> >> On 06/09/2014 01:07 PM, Christian Thalinger wrote: >> >> On Jun 9, 2014, at 9:40 AM, Caspole, Eric >> > wrote: >> >> Hi everybody, >> I put up a new webrev that allows some IntStream.reduce() to be >> offloaded to HSA: >> >> http://cr.openjdk.java.net/~ecaspole/graal_int_reduce1/webrev/ >> >> >> src/gpu/hsail/vm/hsailKernelArguments.hpp >> >> + virtual void collectArgs() { >> >> Does this really have to be in the .hpp file? I see that the base class >> has it in the .hpp file too. >> >> No it doesn't have to be there, it is just some historical thing I don't know why. I can change that. >> >> That would be good. Thanks. >> >> >> >> >> This works with a Sumatra webrev I will eventually add into the >> Sumatra JDK repo: >> >> http://cr.openjdk.java.net/~ecaspole/sumatra_int_reduce_1/webrev/ >> >> This combo allows offloading IntStream.parallel().reduce() for >> Integer::sum, Integer::max, and Integer::min. It builds a kernel from >> a hand made HSAIL string of code that gets called from the new Stream >> API diversion code in the Sumatra part. >> >> Eventually we hope to have regular compilation of user reduce >> functions but this allows us to do experiments with workloads before >> we get all the details of reduce compilation in place such as barrier >> placement and group size nuances. >> >> Presumably that will remove the hand-made code eventually? >> >> Yes. I just want to be able to expose this interesting functionality in the mean time. >> >> Makes sense. >> >> >> >> >> In the current Kaveri hardware version of Okra, it uses group size 256 >> by default and this reduce code is designed to work only with 256. >> Also, because it is a handmade kernel, it only runs with >> -UseHSAILDeoptimization and -UseCompressedOops. >> In the included reduce tests, they will skip if the correct flags are >> not there for the tests to run correctly. >> >> This webrev also changes the way the kernel args are processed to look >> at the actual args type rather than by the type signature of the >> kernel method. >> Regards, >> Eric >> > From doug.simon at oracle.com Fri Jun 13 01:00:06 2014 From: doug.simon at oracle.com (doug.simon at oracle.com) Date: Fri, 13 Jun 2014 01:00:06 +0000 Subject: hg: graal/graal: 2 new changesets Message-ID: <201406130100.s5D109No002300@aojmv0008> Changeset: 6eef506c173d Author: Bernhard Urban Date: 2014-06-12 11:39 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/6eef506c173d mx archive: only print overwrite warning on files ! mxtool/mx.py Changeset: 64e172733061 Author: Bernhard Urban Date: 2014-06-12 11:40 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/64e172733061 mx clean: delete distributions ! mx/mx_graal.py ! mxtool/mx.py From tom.deneau at amd.com Fri Jun 13 17:15:46 2014 From: tom.deneau at amd.com (Deneau, Tom) Date: Fri, 13 Jun 2014 17:15:46 +0000 Subject: oops_do GC question Message-ID: Hi all -- I have been modifying our hsail JVM side code to use the standard process of updating the oops in the saved HSAIL state by calling oops_do from a GC thread. The oops_do goes thru the saved hsail frames and applies the oops_do closure to each oop in each saved frame. In the trunk today we have a hackier (and higher overhead) process involving copying oops to and from a java Object array and letting them get fixed up there if necessary. Anyway, the oops_do implementation seems to be working but I had a question. I have a test app that does enough allocation that the HsailDeopt::oops_do gets invoked while we are processing the deopts. I ran it in a number of heap configurations. I first ran it with a small enough heap (-Xmx1g) such that the compressed oops had no shift or base offset. When I did this, I saw that each processed oop had been forwarded so the oops_do had the effect of changing the local oop in the hsail frame, for example deopt 12475, workitem 13320, pc 2401 slot 12475, bit=0, oop_ptr=0x7f00107f9238, old=fab203a0, new=ffa981d0 which all made sense. Then I ran the same app with a large enough heap (-Xmx6g) that the compressed oops used a shift but no base. In this configuration, the oops_do did not end up changing the oop in the hsailFrame, for example deopt 1051, workitem 1530, pc 2423 slot 1051, bit=0, oop_ptr=0x2b1e5c6d41b8, old=0x640135388, new=0x640135388 I stepped thru it the oops_do and when it calls should_scavenge, it does indeed come up false since the oop address (0x640135388 above) is not in the young generation. The oop being processed above for this kernel is I believe a "this" pointer for the class that wraps the kernel. Just wondering why in the 1g case this oop would still be in the young generation but in the 6g case it would not? -- Tom From doug.simon at oracle.com Sat Jun 14 01:00:06 2014 From: doug.simon at oracle.com (doug.simon at oracle.com) Date: Sat, 14 Jun 2014 01:00:06 +0000 Subject: hg: graal/graal: 16 new changesets Message-ID: <201406140100.s5E10VlM000987@aojmv0008> Changeset: 0bd92901891c Author: Laurent Daynes Date: 2014-06-11 10:38 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/0bd92901891c Fixed missing null check on target call's receiver (i.e., target is a static method) ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/TruffleExpansionLogger.java Changeset: 8d164bec9807 Author: Laurent Daynes Date: 2014-06-04 04:08 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/8d164bec9807 Changed (jlong) NULL to (jlong) (address) NULL to remove warning that cause build failures on old version of gcc (4.1.2 as used on Oracle Linux Server 5.8). ! src/share/vm/graal/graalCompilerToVM.cpp Changeset: 32ddc8096f4c Author: Laurent Daynes Date: 2014-06-13 09:06 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/32ddc8096f4c Merge Changeset: 69220322bc14 Author: Doug Simon Date: 2014-06-13 11:31 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/69220322bc14 show array lengths in allocation records produced by AllocSpy ! graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/AllocSpy.java Changeset: 51ba6c521922 Author: Roland Schatz Date: 2014-06-13 11:08 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/51ba6c521922 Refactor LIRGeneratorTool methods. ! graal/com.oracle.graal.compiler.amd64/src/com/oracle/graal/compiler/amd64/AMD64LIRGenerator.java ! graal/com.oracle.graal.compiler.hsail/src/com/oracle/graal/compiler/hsail/HSAILLIRGenerator.java ! graal/com.oracle.graal.compiler.ptx/src/com/oracle/graal/compiler/ptx/PTXLIRGenerator.java ! graal/com.oracle.graal.compiler.sparc/src/com/oracle/graal/compiler/sparc/SPARCLIRGenerator.java ! graal/com.oracle.graal.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.hsail/src/com/oracle/graal/hotspot/hsail/HSAILHotSpotNodeLIRBuilder.java ! graal/com.oracle.graal.hotspot.sparc/src/com/oracle/graal/hotspot/sparc/SPARCHotSpotNodeLIRBuilder.java ! graal/com.oracle.graal.lir/src/com/oracle/graal/lir/gen/LIRGenerator.java ! graal/com.oracle.graal.lir/src/com/oracle/graal/lir/gen/LIRGeneratorTool.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/spi/NodeLIRBuilderTool.java ! graal/com.oracle.graal.replacements/src/com/oracle/graal/replacements/nodes/ArrayEqualsNode.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: 39be5bc00046 Author: Roland Schatz Date: 2014-06-13 11:11 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/39be5bc00046 Support XMM registers in oop maps. ! graal/com.oracle.graal.amd64/src/com/oracle/graal/amd64/AMD64.java ! graal/com.oracle.graal.api.code/src/com/oracle/graal/api/code/Register.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/HotSpotReferenceMap.java ! graal/com.oracle.graal.lir/src/com/oracle/graal/lir/FrameMap.java ! graal/com.oracle.graal.sparc/src/com/oracle/graal/sparc/SPARC.java ! src/share/vm/graal/graalCodeInstaller.cpp Changeset: c0b8d395368b Author: Roland Schatz Date: 2014-06-13 11:47 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/c0b8d395368b Introduce LIRKind to accurately track oop references in backend. ! graal/com.oracle.graal.api.code/src/com/oracle/graal/api/code/ReferenceMap.java ! graal/com.oracle.graal.api.code/src/com/oracle/graal/api/code/Register.java ! graal/com.oracle.graal.api.code/src/com/oracle/graal/api/code/RegisterValue.java ! graal/com.oracle.graal.api.code/src/com/oracle/graal/api/code/StackSlot.java ! graal/com.oracle.graal.api.code/src/com/oracle/graal/api/code/TargetDescription.java ! graal/com.oracle.graal.api.code/src/com/oracle/graal/api/code/VirtualObject.java ! graal/com.oracle.graal.api.meta/src/com/oracle/graal/api/meta/AllocatableValue.java ! graal/com.oracle.graal.api.meta/src/com/oracle/graal/api/meta/Constant.java + graal/com.oracle.graal.api.meta/src/com/oracle/graal/api/meta/LIRKind.java ! graal/com.oracle.graal.api.meta/src/com/oracle/graal/api/meta/NullConstant.java ! graal/com.oracle.graal.api.meta/src/com/oracle/graal/api/meta/PlatformKind.java ! graal/com.oracle.graal.api.meta/src/com/oracle/graal/api/meta/PrimitiveConstant.java ! graal/com.oracle.graal.api.meta/src/com/oracle/graal/api/meta/Value.java ! graal/com.oracle.graal.baseline/src/com/oracle/graal/baseline/BaselineBytecodeParser.java ! graal/com.oracle.graal.compiler.amd64/src/com/oracle/graal/compiler/amd64/AMD64LIRGenerator.java ! graal/com.oracle.graal.compiler.amd64/src/com/oracle/graal/compiler/amd64/AMD64NodeLIRBuilder.java + graal/com.oracle.graal.compiler.common/src/com/oracle/graal/compiler/common/spi/LIRKindTool.java - graal/com.oracle.graal.compiler.common/src/com/oracle/graal/compiler/common/spi/PlatformKindTool.java ! graal/com.oracle.graal.compiler.common/src/com/oracle/graal/compiler/common/type/FloatStamp.java ! graal/com.oracle.graal.compiler.common/src/com/oracle/graal/compiler/common/type/IllegalStamp.java ! graal/com.oracle.graal.compiler.common/src/com/oracle/graal/compiler/common/type/IntegerStamp.java ! graal/com.oracle.graal.compiler.common/src/com/oracle/graal/compiler/common/type/ObjectStamp.java ! graal/com.oracle.graal.compiler.common/src/com/oracle/graal/compiler/common/type/Stamp.java ! graal/com.oracle.graal.compiler.common/src/com/oracle/graal/compiler/common/type/VoidStamp.java ! graal/com.oracle.graal.compiler.hsail/src/com/oracle/graal/compiler/hsail/HSAILLIRGenerator.java ! graal/com.oracle.graal.compiler.ptx/src/com/oracle/graal/compiler/ptx/PTXLIRGenerator.java ! graal/com.oracle.graal.compiler.sparc/src/com/oracle/graal/compiler/sparc/SPARCLIRGenerator.java ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/alloc/Interval.java ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/alloc/LinearScan.java ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/alloc/LinearScanWalker.java ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/alloc/MoveResolver.java ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/gen/NodeLIRBuilder.java ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/gen/PhiResolver.java ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/match/ComplexMatchValue.java ! graal/com.oracle.graal.hotspot.amd64/src/com/oracle/graal/hotspot/amd64/AMD64HotSpotBackendFactory.java ! graal/com.oracle.graal.hotspot.amd64/src/com/oracle/graal/hotspot/amd64/AMD64HotSpotBytecodeLIRBuilder.java ! graal/com.oracle.graal.hotspot.amd64/src/com/oracle/graal/hotspot/amd64/AMD64HotSpotCompare.java ! graal/com.oracle.graal.hotspot.amd64/src/com/oracle/graal/hotspot/amd64/AMD64HotSpotEpilogueOp.java ! graal/com.oracle.graal.hotspot.amd64/src/com/oracle/graal/hotspot/amd64/AMD64HotSpotForeignCallsProvider.java ! graal/com.oracle.graal.hotspot.amd64/src/com/oracle/graal/hotspot/amd64/AMD64HotSpotLIRGenerator.java ! graal/com.oracle.graal.hotspot.amd64/src/com/oracle/graal/hotspot/amd64/AMD64HotSpotNodeLIRBuilder.java ! graal/com.oracle.graal.hotspot.amd64/src/com/oracle/graal/hotspot/amd64/AMD64HotSpotRegisterConfig.java ! graal/com.oracle.graal.hotspot.amd64/src/com/oracle/graal/hotspot/amd64/AMD64HotSpotSafepointOp.java ! graal/com.oracle.graal.hotspot.hsail/src/com/oracle/graal/hotspot/hsail/HSAILHotSpotBackend.java ! graal/com.oracle.graal.hotspot.hsail/src/com/oracle/graal/hotspot/hsail/HSAILHotSpotBackendFactory.java ! graal/com.oracle.graal.hotspot.hsail/src/com/oracle/graal/hotspot/hsail/HSAILHotSpotLIRGenerator.java ! graal/com.oracle.graal.hotspot.hsail/src/com/oracle/graal/hotspot/hsail/HSAILHotSpotNodeLIRBuilder.java ! graal/com.oracle.graal.hotspot.hsail/src/com/oracle/graal/hotspot/hsail/HSAILHotSpotRegisterConfig.java ! graal/com.oracle.graal.hotspot.hsail/src/com/oracle/graal/hotspot/hsail/HSAILHotSpotSafepointOp.java ! graal/com.oracle.graal.hotspot.hsail/src/com/oracle/graal/hotspot/hsail/replacements/HSAILDirectLoadAcquireNode.java ! graal/com.oracle.graal.hotspot.hsail/src/com/oracle/graal/hotspot/hsail/replacements/HSAILDirectStoreReleaseNode.java ! graal/com.oracle.graal.hotspot.ptx/src/com/oracle/graal/hotspot/ptx/PTXHotSpotBackendFactory.java ! graal/com.oracle.graal.hotspot.ptx/src/com/oracle/graal/hotspot/ptx/PTXHotSpotRegisterConfig.java ! graal/com.oracle.graal.hotspot.sparc/src/com/oracle/graal/hotspot/sparc/SPARCHotSpotBackendFactory.java ! graal/com.oracle.graal.hotspot.sparc/src/com/oracle/graal/hotspot/sparc/SPARCHotSpotForeignCallsProvider.java ! graal/com.oracle.graal.hotspot.sparc/src/com/oracle/graal/hotspot/sparc/SPARCHotSpotLIRGenerator.java ! graal/com.oracle.graal.hotspot.sparc/src/com/oracle/graal/hotspot/sparc/SPARCHotSpotNodeLIRBuilder.java ! graal/com.oracle.graal.hotspot.sparc/src/com/oracle/graal/hotspot/sparc/SPARCHotSpotRegisterConfig.java ! graal/com.oracle.graal.hotspot.sparc/src/com/oracle/graal/hotspot/sparc/SPARCHotSpotSafepointOp.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/HotSpotLockStack.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/HotSpotReferenceMap.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/HotSpotTargetDescription.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotCompressedNullConstant.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotMonitorValue.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotObjectConstant.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/nodes/CStringNode.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/nodes/CurrentJavaThreadNode.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/nodes/GetObjectAddressNode.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/nodes/TailcallNode.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/nodes/type/NarrowOopStamp.java ! graal/com.oracle.graal.hsail/src/com/oracle/graal/hsail/HSAIL.java ! graal/com.oracle.graal.lir.amd64/src/com/oracle/graal/lir/amd64/AMD64AddressValue.java ! graal/com.oracle.graal.lir.amd64/src/com/oracle/graal/lir/amd64/AMD64Arithmetic.java ! graal/com.oracle.graal.lir.amd64/src/com/oracle/graal/lir/amd64/AMD64ArrayEqualsOp.java ! graal/com.oracle.graal.lir.amd64/src/com/oracle/graal/lir/amd64/AMD64Call.java ! graal/com.oracle.graal.lir.amd64/src/com/oracle/graal/lir/amd64/AMD64ControlFlow.java ! graal/com.oracle.graal.lir.amd64/src/com/oracle/graal/lir/amd64/AMD64FrameMap.java ! graal/com.oracle.graal.lir.amd64/src/com/oracle/graal/lir/amd64/AMD64RestoreRegistersOp.java ! graal/com.oracle.graal.lir.amd64/src/com/oracle/graal/lir/amd64/AMD64SaveRegistersOp.java ! graal/com.oracle.graal.lir.amd64/src/com/oracle/graal/lir/amd64/AMD64ZapRegistersOp.java ! graal/com.oracle.graal.lir.hsail/src/com/oracle/graal/lir/hsail/HSAILAddressValue.java ! graal/com.oracle.graal.lir.hsail/src/com/oracle/graal/lir/hsail/HSAILControlFlow.java ! graal/com.oracle.graal.lir.hsail/src/com/oracle/graal/lir/hsail/HSAILFrameMap.java ! graal/com.oracle.graal.lir.ptx/src/com/oracle/graal/lir/ptx/PTXAddressValue.java ! graal/com.oracle.graal.lir.ptx/src/com/oracle/graal/lir/ptx/PTXFrameMap.java ! graal/com.oracle.graal.lir.sparc/src/com/oracle/graal/lir/sparc/SPARCAddressValue.java ! graal/com.oracle.graal.lir.sparc/src/com/oracle/graal/lir/sparc/SPARCArithmetic.java ! graal/com.oracle.graal.lir.sparc/src/com/oracle/graal/lir/sparc/SPARCBitManipulationOp.java ! graal/com.oracle.graal.lir.sparc/src/com/oracle/graal/lir/sparc/SPARCControlFlow.java ! graal/com.oracle.graal.lir.sparc/src/com/oracle/graal/lir/sparc/SPARCFrameMap.java ! graal/com.oracle.graal.lir.sparc/src/com/oracle/graal/lir/sparc/SPARCSaveRegistersOp.java ! graal/com.oracle.graal.lir/src/com/oracle/graal/lir/CompositeValue.java ! graal/com.oracle.graal.lir/src/com/oracle/graal/lir/FrameMap.java ! graal/com.oracle.graal.lir/src/com/oracle/graal/lir/RedundantMoveElimination.java ! graal/com.oracle.graal.lir/src/com/oracle/graal/lir/Variable.java ! graal/com.oracle.graal.lir/src/com/oracle/graal/lir/gen/ArithmeticLIRGenerator.java ! graal/com.oracle.graal.lir/src/com/oracle/graal/lir/gen/LIRGenerator.java ! graal/com.oracle.graal.lir/src/com/oracle/graal/lir/gen/LIRGeneratorTool.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/calc/ReinterpretNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/extended/FloatingReadNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/extended/ReadNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/extended/WriteNode.java ! graal/com.oracle.graal.printer/src/com/oracle/graal/printer/CFGPrinter.java ! graal/com.oracle.graal.ptx/src/com/oracle/graal/ptx/PTX.java ! graal/com.oracle.graal.replacements/src/com/oracle/graal/replacements/nodes/DirectReadNode.java ! graal/com.oracle.graal.replacements/src/com/oracle/graal/replacements/nodes/DirectStoreNode.java ! graal/com.oracle.graal.replacements/src/com/oracle/graal/replacements/nodes/ReadRegisterNode.java ! graal/com.oracle.graal.replacements/src/com/oracle/graal/replacements/nodes/WriteRegisterNode.java ! graal/com.oracle.graal.sparc/src/com/oracle/graal/sparc/SPARC.java ! graal/com.oracle.graal.word/src/com/oracle/graal/word/nodes/WordCastNode.java Changeset: 137309c77bf9 Author: Doug Simon Date: 2014-06-13 14:25 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/137309c77bf9 updated Java Allocation Instrumenter library ! mx/projects Changeset: 5059c188c1e5 Author: Doug Simon Date: 2014-06-13 17:00 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/5059c188c1e5 memory use tracking should only be enabled if -G:TrackMemUse is specified ! graal/com.oracle.graal.debug/src/com/oracle/graal/debug/internal/MemUseTrackerImpl.java Changeset: 4af6f1fe425c Author: Lukas Stadler Date: 2014-06-13 18:17 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/4af6f1fe425c reduce unnecessary clearing of inputs ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/inlining/InliningUtil.java ! graal/com.oracle.graal.replacements/src/com/oracle/graal/replacements/InstanceOfSnippetsTemplates.java ! graal/com.oracle.graal.replacements/src/com/oracle/graal/replacements/SnippetTemplate.java Changeset: 1c042d5e7e69 Author: Lukas Stadler Date: 2014-06-13 18:18 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/1c042d5e7e69 make sure that anchoredReceiver isn't deleted when tail duplicating during inlining ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/inlining/info/MultiTypeGuardInlineInfo.java Changeset: 0d1f79e8add9 Author: Lukas Stadler Date: 2014-06-13 18:18 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/0d1f79e8add9 handle deleted proxies in GraphUtil.checkRedundantProxy ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/util/GraphUtil.java Changeset: 13e471b673f3 Author: Lukas Stadler Date: 2014-06-13 18:18 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/13e471b673f3 handle deleted nodes in IfNode.simplify ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/IfNode.java Changeset: 99e2e006ade2 Author: Lukas Stadler Date: 2014-06-13 18:19 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/99e2e006ade2 do not zap inputs and successors in Node.safeDelete ! graal/com.oracle.graal.graph/src/com/oracle/graal/graph/Node.java Changeset: 64d8c6c8a00c Author: Tom Rodriguez Date: 2014-06-13 10:37 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/64d8c6c8a00c derive native compiler thread name from Compiler::name ! graal/com.oracle.graal.lir/src/com/oracle/graal/lir/FrameMap.java ! src/share/vm/compiler/compileBroker.cpp Changeset: 26d95e1247d0 Author: Tom Rodriguez Date: 2014-06-13 15:19 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/26d95e1247d0 remove accidentally pushed changes ! graal/com.oracle.graal.lir/src/com/oracle/graal/lir/FrameMap.java From doug.simon at oracle.com Mon Jun 16 08:27:10 2014 From: doug.simon at oracle.com (Doug Simon) Date: Mon, 16 Jun 2014 10:27:10 +0200 Subject: oops_do GC question In-Reply-To: References: Message-ID: <9B0DBE7A-3310-4FAB-AF40-987E6FECA576@oracle.com> Which collector is being used? Is this with ?vm server (i.e., hosted mode)? If not, then it could just be that Graal compilation on another thread happened to trigger a GC at a different time during your 6g execution. If you are using ?vm server, then this goes against my expectation of generational GC as well. In the 6g case, does it always ?miss? the ?this? pointer? -Doug On Jun 13, 2014, at 7:15 PM, Deneau, Tom wrote: > Hi all -- > > > > I have been modifying our hsail JVM side code to use the standard process of updating the oops in the saved HSAIL state by calling oops_do from a GC thread. The oops_do goes thru the saved hsail frames and applies the oops_do closure to each oop in each saved frame. In the trunk today we have a hackier (and higher overhead) process involving copying oops to and from a java Object array and letting them get fixed up there if necessary. > > > > Anyway, the oops_do implementation seems to be working but I had a question. I have a test app that does enough allocation that the HsailDeopt::oops_do gets invoked while we are processing the deopts. > > I ran it in a number of heap configurations. I first ran it with a small enough heap (-Xmx1g) such that the compressed oops had no shift or base offset. When I did this, I saw that each processed oop had been forwarded so the oops_do had the effect of changing the local oop in the hsail frame, for example > > > > deopt 12475, workitem 13320, pc 2401 slot 12475, bit=0, > > oop_ptr=0x7f00107f9238, old=fab203a0, new=ffa981d0 > > > > which all made sense. > > > > Then I ran the same app with a large enough heap (-Xmx6g) that the compressed oops used a shift but no base. In this configuration, the oops_do did not end up changing the oop in the hsailFrame, for example > > deopt 1051, workitem 1530, pc 2423 slot 1051, bit=0, oop_ptr=0x2b1e5c6d41b8, old=0x640135388, new=0x640135388 > > > > > > I stepped thru it the oops_do and when it calls should_scavenge, it does indeed come up false since the oop address (0x640135388 above) is not in the young generation. > > > > The oop being processed above for this kernel is I believe a "this" pointer for the class that wraps the kernel. > > > > Just wondering why in the 1g case this oop would still be in the young generation but in the 6g case it would not? > > > > -- Tom > > > > From tom.deneau at amd.com Mon Jun 16 14:08:01 2014 From: tom.deneau at amd.com (Deneau, Tom) Date: Mon, 16 Jun 2014 14:08:01 +0000 Subject: oops_do GC question In-Reply-To: <9B0DBE7A-3310-4FAB-AF40-987E6FECA576@oracle.com> References: <9B0DBE7A-3310-4FAB-AF40-987E6FECA576@oracle.com> Message-ID: Doug -- This is the default collector, and is --vm server. Yes, it seems to always miss with -Xmx6g. -- Tom > -----Original Message----- > From: Doug Simon [mailto:doug.simon at oracle.com] > Sent: Monday, June 16, 2014 3:27 AM > To: Deneau, Tom > Cc: graal-dev at openjdk.java.net > Subject: Re: oops_do GC question > > Which collector is being used? > > Is this with -vm server (i.e., hosted mode)? If not, then it could just > be that Graal compilation on another thread happened to trigger a GC at > a different time during your 6g execution. > > If you are using -vm server, then this goes against my expectation of > generational GC as well. In the 6g case, does it always "miss" the > "this" pointer? > > -Doug > > On Jun 13, 2014, at 7:15 PM, Deneau, Tom wrote: > > > Hi all -- > > > > > > > > I have been modifying our hsail JVM side code to use the standard > process of updating the oops in the saved HSAIL state by calling oops_do > from a GC thread. The oops_do goes thru the saved hsail frames and > applies the oops_do closure to each oop in each saved frame. In the > trunk today we have a hackier (and higher overhead) process involving > copying oops to and from a java Object array and letting them get fixed > up there if necessary. > > > > > > > > Anyway, the oops_do implementation seems to be working but I had a > question. I have a test app that does enough allocation that the > HsailDeopt::oops_do gets invoked while we are processing the deopts. > > > > I ran it in a number of heap configurations. I first ran it with a > small enough heap (-Xmx1g) such that the compressed oops had no shift or > base offset. When I did this, I saw that each processed oop had been > forwarded so the oops_do had the effect of changing the local oop in the > hsail frame, for example > > > > > > > > deopt 12475, workitem 13320, pc 2401 slot 12475, bit=0, > > > > oop_ptr=0x7f00107f9238, old=fab203a0, new=ffa981d0 > > > > > > > > which all made sense. > > > > > > > > Then I ran the same app with a large enough heap (-Xmx6g) that the > compressed oops used a shift but no base. In this configuration, the > oops_do did not end up changing the oop in the hsailFrame, for example > > > > deopt 1051, workitem 1530, pc 2423 slot 1051, bit=0, > oop_ptr=0x2b1e5c6d41b8, old=0x640135388, new=0x640135388 > > > > > > > > > > > > I stepped thru it the oops_do and when it calls should_scavenge, it > does indeed come up false since the oop address (0x640135388 above) is > not in the young generation. > > > > > > > > The oop being processed above for this kernel is I believe a "this" > pointer for the class that wraps the kernel. > > > > > > > > Just wondering why in the 1g case this oop would still be in the young > generation but in the 6g case it would not? > > > > > > > > -- Tom > > > > > > > > From tom.deneau at amd.com Mon Jun 16 16:33:59 2014 From: tom.deneau at amd.com (Deneau, Tom) Date: Mon, 16 Jun 2014 16:33:59 +0000 Subject: Proposal to reuse existing equality testing in unit tests In-Reply-To: <53E30AB6-F1A8-4FC9-8859-4182EBE397BA@oracle.com> References: <52C71D6F-E8A2-4BDD-95CE-BC7B62964955@oracle.com> <39D8C101-5569-4315-A455-83C9FCF5AA01@oracle.com> <376CCB3D-0B6C-4B09-9372-55D24143D52F@oracle.com> <53E30AB6-F1A8-4FC9-8859-4182EBE397BA@oracle.com> Message-ID: A comment on GraalTest.API for asserting equality of floats and doubles. Rather than specifying an absolute delta parameter, it would be nice if there was a way to express a "relative delta" in terms of ULPs. (since this is how floating point accuracy is usually specified). Or is there a way to do that currently? -- Tom > -----Original Message----- > From: Doug Simon [mailto:doug.simon at oracle.com] > Sent: Tuesday, May 13, 2014 3:27 PM > To: Deneau, Tom > Cc: graal-dev at openjdk.java.net > Subject: Re: Proposal to reuse existing equality testing in unit tests > > > On May 13, 2014, at 7:25 PM, Deneau, Tom wrote: > > > Doug -- > > > > To make it work I had to extend GraalCompilerTest rather than > GraalTest (new patch attached). > > Otherwise it didn't do the deep equals for arrays. > > You must be not on tip as I moved the necessary methods from > GraalCompilerTest to GraalTest. > > > But with that, this new patch works for me. Thanks for noticing this > duplication. > > > > One question, I know we weren't really using it yet but we had made an > > overrideable method that would determine whether two floats or two > > doubles were equal so they wouldn't have to be exactly equal. > > > > > Is there any provision for that in your infrastructure? > > Yes. The junit mechanism for this is to supply a 'delta' parameter when > comparing floats or doubles. I've ensured this mechanism is also exposed > in the GraalTest API and you can see an example of it being used in > FloatDivPrecisionTest once you pull the latest changes: > > http://hg.openjdk.java.net/graal/graal/rev/3c1a88470123#l3.9 > > -Doug > > >> -----Original Message----- > >> From: Doug Simon [mailto:doug.simon at oracle.com] > >> Sent: Tuesday, May 13, 2014 10:34 AM > >> To: Deneau, Tom > >> Cc: graal-dev at openjdk.java.net > >> Subject: Proposal to reuse existing equality testing in unit tests > >> > >> Tom, > >> > >> I noticed the special logic in KernelTester for comparing results of > >> Okra based executions and sequential executions. As far as I can > >> tell, this duplicates code that already exists in Graal and Junit. > >> Could you please review this patch to remove the redundant logic: > >> > >> http://cr.openjdk.java.net/~dnsimon/use-existing-equality-testing/ > >> > >> -Doug > > From doug.simon at oracle.com Mon Jun 16 18:50:28 2014 From: doug.simon at oracle.com (Doug Simon) Date: Mon, 16 Jun 2014 20:50:28 +0200 Subject: Proposal to reuse existing equality testing in unit tests In-Reply-To: References: <52C71D6F-E8A2-4BDD-95CE-BC7B62964955@oracle.com> <39D8C101-5569-4315-A455-83C9FCF5AA01@oracle.com> <376CCB3D-0B6C-4B09-9372-55D24143D52F@oracle.com> <53E30AB6-F1A8-4FC9-8859-4182EBE397BA@oracle.com> Message-ID: <071A222D-A93E-4DFC-B492-C65AB47C8E18@oracle.com> On Jun 16, 2014, at 6:33 PM, Deneau, Tom wrote: > A comment on GraalTest.API for asserting equality of floats and doubles. Rather than specifying an absolute delta parameter, it would be nice if there was a way to express a "relative delta" in terms of ULPs. (since this is how floating point accuracy is usually specified). Or is there a way to do that currently? You should be able to achieve what you want by overriding GraalTest.assertDeepEquals(String, Object, Object, double). -Doug >> -----Original Message----- >> From: Doug Simon [mailto:doug.simon at oracle.com] >> Sent: Tuesday, May 13, 2014 3:27 PM >> To: Deneau, Tom >> Cc: graal-dev at openjdk.java.net >> Subject: Re: Proposal to reuse existing equality testing in unit tests >> >> >> On May 13, 2014, at 7:25 PM, Deneau, Tom wrote: >> >>> Doug -- >>> >>> To make it work I had to extend GraalCompilerTest rather than >> GraalTest (new patch attached). >>> Otherwise it didn't do the deep equals for arrays. >> >> You must be not on tip as I moved the necessary methods from >> GraalCompilerTest to GraalTest. >> >>> But with that, this new patch works for me. Thanks for noticing this >> duplication. >>> >>> One question, I know we weren't really using it yet but we had made an >>> overrideable method that would determine whether two floats or two >>> doubles were equal so they wouldn't have to be exactly equal. >> >>> >>> Is there any provision for that in your infrastructure? >> >> Yes. The junit mechanism for this is to supply a 'delta' parameter when >> comparing floats or doubles. I've ensured this mechanism is also exposed >> in the GraalTest API and you can see an example of it being used in >> FloatDivPrecisionTest once you pull the latest changes: >> >> http://hg.openjdk.java.net/graal/graal/rev/3c1a88470123#l3.9 >> >> -Doug >> >>>> -----Original Message----- >>>> From: Doug Simon [mailto:doug.simon at oracle.com] >>>> Sent: Tuesday, May 13, 2014 10:34 AM >>>> To: Deneau, Tom >>>> Cc: graal-dev at openjdk.java.net >>>> Subject: Proposal to reuse existing equality testing in unit tests >>>> >>>> Tom, >>>> >>>> I noticed the special logic in KernelTester for comparing results of >>>> Okra based executions and sequential executions. As far as I can >>>> tell, this duplicates code that already exists in Graal and Junit. >>>> Could you please review this patch to remove the redundant logic: >>>> >>>> http://cr.openjdk.java.net/~dnsimon/use-existing-equality-testing/ >>>> >>>> -Doug >>> > From Eric.Caspole at amd.com Mon Jun 16 23:19:59 2014 From: Eric.Caspole at amd.com (Caspole, Eric) Date: Mon, 16 Jun 2014 23:19:59 +0000 Subject: Webrev for first version of HSA offload integer reduce In-Reply-To: <31CEC65D-0448-47A2-84B5-08F8781F9012@oracle.com> References: <1E9B0B70-CC27-44F5-A85A-C84B93EDCD96@oracle.com> <5395F3F0.8060508@amd.com>, , , <31CEC65D-0448-47A2-84B5-08F8781F9012@oracle.com> Message-ID: Hi Doug, I think I got all your suggestions in this one: http://cr.openjdk.java.net/~ecaspole/graal_int_reduce1/04/webrev/ Regards, Eric ________________________________________ From: Doug Simon [doug.simon at oracle.com] Sent: Thursday, June 12, 2014 3:31 AM To: Caspole, Eric Cc: Christian Thalinger; sumatra-dev at openjdk.java.net; graal-dev at openjdk.java.net Subject: Re: Webrev for first version of HSA offload integer reduce Eric, graal/com.oracle.graal.hotspot.hsail/src/com/oracle/graal/hotspot/hsail/ForEachToGraal.java: + // Preallocate kernel args array to reduce allocation rate + static Object args[] = new Object[3]; + + static final int desiredGlobalSizeMultiple = Integer.getInteger("com.amd.sumatra.reduce.globalsize.multiple", 1); + // Running with a larger global size seems to increase the performance for sum, + // but it might be different for other reductions so it is a knob + static final int globalSize = 1024 * desiredGlobalSizeMultiple; // requiredGroupSize * 8 * + // desiredGlobalSizeMultiple; + static final int result[] = new int[1]; The use of static fields ?args? and ?result' in ForEachToGraal.offloadIntReduceImpl() seems both dangerous (I don?t see any synchronization on the class) and unnecessary (the overhead of the kernel dispatch will surely outweigh the cost of allocating the arrays of size 1 and 3 respectively). Why cannot they just be made into local variables? Also, please delete commented out code like that at the end of globalSize declaration or provide extra comments as to why it is being kept around. + String REDUCE_OP = "/* Invalid */ "; + String ATOMIC_RESULT_PRODUCTION = "/* Invalid */ "; + if (reducerName.equals("sum")) { + REDUCE_OP = "add_u32 "; + ATOMIC_RESULT_PRODUCTION = "atomicnoret_add_global_u32 "; + } else if (reducerName.equals("max")) { + REDUCE_OP = "max_s32 "; + ATOMIC_RESULT_PRODUCTION = "atomicnoret_max_global_s32 "; + } else if (reducerName.equals("min")) { + REDUCE_OP = "min_s32 "; + ATOMIC_RESULT_PRODUCTION = "atomicnoret_min_global_s32 "; + } else { + return "/* Invalid */ "; + } Local variables should not be all upper case (REDUCE_OP -> reduceOp). This will be flagged by Checkstyle once it support Java8. src/gpu/hsail/vm/hsailArgumentsBase.hpp: + void recordNullObjectParameter() { + if (_first_null_parameter_index == -1) _first_null_parameter_index = _parameter_index; Please use braces and indentation even for single state statement blocks. -Doug On Jun 11, 2014, at 7:37 PM, Caspole, Eric wrote: > Hi Doug, > OK, I merged up and fixed the copyright etc, it is here: > > http://cr.openjdk.java.net/~ecaspole/graal_int_reduce1/03/webrev/ > > let me know what you think, > Eric > > > ________________________________________ > From: Doug Simon [doug.simon at oracle.com] > Sent: Wednesday, June 11, 2014 5:35 AM > To: Caspole, Eric > Cc: Christian Thalinger; sumatra-dev at openjdk.java.net; graal-dev at openjdk.java.net > Subject: Re: Webrev for first version of HSA offload integer reduce > > Eric, > > Sorry for the inconvenience, but can you please update to the tip which now includes Tom Deneau?s changesets and generate one more webrev. > > Thanks. > > -Doug > > On Jun 10, 2014, at 5:03 PM, Caspole, Eric wrote: > >> I moved collectArgs into the cpp files for both classes here: >> http://cr.openjdk.java.net/~ecaspole/graal_int_reduce1/02/webrev/ >> Thanks, >> Eric >> >> >> ________________________________ >> From: Christian Thalinger [christian.thalinger at oracle.com] >> Sent: Monday, June 09, 2014 2:15 PM >> To: Caspole, Eric >> Cc: graal-dev at openjdk.java.net; sumatra-dev at openjdk.java.net >> Subject: Re: Webrev for first version of HSA offload integer reduce >> >> >> On Jun 9, 2014, at 10:50 AM, Eric Caspole > wrote: >> >> >> >> On 06/09/2014 01:07 PM, Christian Thalinger wrote: >> >> On Jun 9, 2014, at 9:40 AM, Caspole, Eric >> > wrote: >> >> Hi everybody, >> I put up a new webrev that allows some IntStream.reduce() to be >> offloaded to HSA: >> >> http://cr.openjdk.java.net/~ecaspole/graal_int_reduce1/webrev/ >> >> >> src/gpu/hsail/vm/hsailKernelArguments.hpp >> >> + virtual void collectArgs() { >> >> Does this really have to be in the .hpp file? I see that the base class >> has it in the .hpp file too. >> >> No it doesn't have to be there, it is just some historical thing I don't know why. I can change that. >> >> That would be good. Thanks. >> >> >> >> >> This works with a Sumatra webrev I will eventually add into the >> Sumatra JDK repo: >> >> http://cr.openjdk.java.net/~ecaspole/sumatra_int_reduce_1/webrev/ >> >> This combo allows offloading IntStream.parallel().reduce() for >> Integer::sum, Integer::max, and Integer::min. It builds a kernel from >> a hand made HSAIL string of code that gets called from the new Stream >> API diversion code in the Sumatra part. >> >> Eventually we hope to have regular compilation of user reduce >> functions but this allows us to do experiments with workloads before >> we get all the details of reduce compilation in place such as barrier >> placement and group size nuances. >> >> Presumably that will remove the hand-made code eventually? >> >> Yes. I just want to be able to expose this interesting functionality in the mean time. >> >> Makes sense. >> >> >> >> >> In the current Kaveri hardware version of Okra, it uses group size 256 >> by default and this reduce code is designed to work only with 256. >> Also, because it is a handmade kernel, it only runs with >> -UseHSAILDeoptimization and -UseCompressedOops. >> In the included reduce tests, they will skip if the correct flags are >> not there for the tests to run correctly. >> >> This webrev also changes the way the kernel args are processed to look >> at the actual args type rather than by the type signature of the >> kernel method. >> Regards, >> Eric >> > From doug.simon at oracle.com Tue Jun 17 01:00:06 2014 From: doug.simon at oracle.com (doug.simon at oracle.com) Date: Tue, 17 Jun 2014 01:00:06 +0000 Subject: hg: graal/graal: 10 new changesets Message-ID: <201406170100.s5H10KCJ022264@aojmv0008> Changeset: 4dd2cedc7f57 Author: Roland Schatz Date: 2014-06-16 17:18 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/4dd2cedc7f57 Revert using LIRKind.reference(Kind.Int) instead of hotspot specific NarrowOop kind (part of c0b8d395368b). ! graal/com.oracle.graal.compiler.amd64/src/com/oracle/graal/compiler/amd64/AMD64LIRGenerator.java ! graal/com.oracle.graal.hotspot.amd64/src/com/oracle/graal/hotspot/amd64/AMD64HotSpotBackendFactory.java ! graal/com.oracle.graal.hotspot.amd64/src/com/oracle/graal/hotspot/amd64/AMD64HotSpotCompare.java ! graal/com.oracle.graal.hotspot.amd64/src/com/oracle/graal/hotspot/amd64/AMD64HotSpotLIRGenerator.java ! graal/com.oracle.graal.hotspot.amd64/src/com/oracle/graal/hotspot/amd64/AMD64HotSpotRegisterConfig.java ! graal/com.oracle.graal.hotspot.hsail/src/com/oracle/graal/hotspot/hsail/HSAILHotSpotBackendFactory.java ! graal/com.oracle.graal.hotspot.hsail/src/com/oracle/graal/hotspot/hsail/HSAILHotSpotLIRGenerator.java ! graal/com.oracle.graal.hotspot.hsail/src/com/oracle/graal/hotspot/hsail/HSAILHotSpotRegisterConfig.java ! graal/com.oracle.graal.hotspot.ptx/src/com/oracle/graal/hotspot/ptx/PTXHotSpotBackendFactory.java ! graal/com.oracle.graal.hotspot.sparc/src/com/oracle/graal/hotspot/sparc/SPARCHotSpotBackendFactory.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/HotSpotTargetDescription.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotCompressedNullConstant.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotObjectConstant.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/nodes/type/NarrowOopStamp.java Changeset: e54507c88a93 Author: Doug Simon Date: 2014-06-13 17:41 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/e54507c88a93 placed HandleMark around Graal compilation performed on a native compiler thread ! src/share/vm/graal/graalCompiler.cpp Changeset: 5d84706642ce Author: Doug Simon Date: 2014-06-13 18:41 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/5d84706642ce ensure a DebugEnvironment is initialized for native compiler threads ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/CompilationTask.java ! graal/com.oracle.graal.printer/src/com/oracle/graal/printer/DebugEnvironment.java Changeset: c7db9dc73694 Author: Doug Simon Date: 2014-06-13 18:42 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/c7db9dc73694 disabled dialing C1 compilation back to partial profiling when Graal is the top tier compiler ! src/share/vm/runtime/advancedThresholdPolicy.cpp Changeset: 1a6746681b43 Author: Doug Simon Date: 2014-06-13 18:44 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/1a6746681b43 Merge. Changeset: ed7a88f43dc3 Author: Doug Simon Date: 2014-06-13 20:06 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/ed7a88f43dc3 Merge. Changeset: 0c0bc9ce40f2 Author: Doug Simon Date: 2014-06-16 10:44 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/0c0bc9ce40f2 Merge. Changeset: 9d0561fd3364 Author: Doug Simon Date: 2014-06-16 21:21 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/9d0561fd3364 Merge. Changeset: 2c65a5a280ed Author: Doug Simon Date: 2014-06-16 22:35 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/2c65a5a280ed HSAIL: better error message ! graal/com.oracle.graal.compiler.hsail/src/com/oracle/graal/compiler/hsail/HSAILNodeLIRBuilder.java Changeset: a3a9d703c078 Author: Doug Simon Date: 2014-06-16 23:07 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/a3a9d703c078 disabled UseGraalCompilationQueue by default ! src/share/vm/graal/graalGlobals.hpp From Eric.Caspole at amd.com Tue Jun 17 12:49:26 2014 From: Eric.Caspole at amd.com (Caspole, Eric) Date: Tue, 17 Jun 2014 12:49:26 +0000 Subject: update tests webrev for -XX:-UseHSAILDeoptimization Message-ID: Hi everybody, Here is a small change so the tests run clean with -XX:-UseHSAILDeoptimization http://cr.openjdk.java.net/~ecaspole/test_no_deopt_fix/webrev/ Thanks, Eric From doug.simon at oracle.com Tue Jun 17 15:03:21 2014 From: doug.simon at oracle.com (Doug Simon) Date: Tue, 17 Jun 2014 17:03:21 +0200 Subject: HSAIL (tests) and inlining issue In-Reply-To: References: Message-ID: Eric, Tom, We?ve had issues on our gate recently caused by intermittent failures of NewStringEqualsTest (stack trace below). If StringIndexOutOfBoundsException is resolved before this test is run, then inlining exhausts its budget before getting to inline String.equals which in turn leaves a direct call in the graph, something that HSAIL cannot currently handle. The primary problem is the use of InlineEverything and RemoveNeverExecutedCode in the HSAIL tests. As we?ve seen, these don?t actually guarantee everything will be inlined. For now, I?ve disabled NewStringEqualsTest and added a comment as to why. I?m not sure what the longer term solution is. I?d at least like to see RemoveNeverExecutedCode go away - do we really need it? Now that HSAIL supports deopt, maybe we can change InlineEverything to InlineEverythingOrDeopt - calls that cannot be inlined are replace with DopetimizeNodes. -Doug 2) testUsingLambdaMethod(com.oracle.graal.compiler.hsail.test.lambda.NewStringEqualsTest) com.oracle.graal.graph.GraalGraphInternalError: com.oracle.graal.compiler.common.GraalInternalError: unimplemented: direct call to java.lang.String.equals(Object) at node: 110|Invoke#Direct#String.equals at com.oracle.graal.graph.GraalGraphInternalError.transformAndAddContext(GraalGraphInternalError.java:136) at com.oracle.graal.compiler.gen.NodeLIRBuilder.doBlock(NodeLIRBuilder.java:220) at com.oracle.graal.compiler.GraalCompiler.emitBlock(GraalCompiler.java:216) at com.oracle.graal.compiler.GraalCompiler.emitLIR(GraalCompiler.java:250) at com.oracle.graal.compiler.GraalCompiler.emitBackEnd(GraalCompiler.java:198) at com.oracle.graal.compiler.GraalCompiler.compileGraph(GraalCompiler.java:141) at com.oracle.graal.hotspot.hsail.HSAILHotSpotBackend.compileKernel(HSAILHotSpotBackend.java:195) at com.oracle.graal.hotspot.hsail.HSAILHotSpotBackend.compileAndInstallKernel(HSAILHotSpotBackend.java:153) at com.oracle.graal.compiler.hsail.test.infra.GraalKernelTester.dispatchKernelOkra(GraalKernelTester.java:163) at com.oracle.graal.compiler.hsail.test.infra.KernelTester.dispatchLambdaMethodKernelOkra(KernelTester.java:598) at com.oracle.graal.compiler.hsail.test.infra.KernelTester.dispatchLambdaMethodKernel(KernelTester.java:279) at com.oracle.graal.compiler.hsail.test.infra.KernelTester.dispatchLambdaKernel(KernelTester.java:301) at com.oracle.graal.compiler.hsail.test.lambda.NewStringEqualsTest.runTest(NewStringEqualsTest.java:55) at com.oracle.graal.compiler.hsail.test.infra.KernelTester.runOkraInstance(KernelTester.java:666) at com.oracle.graal.compiler.hsail.test.infra.KernelTester.assertOkraEqualsSeq(KernelTester.java:656) at com.oracle.graal.compiler.hsail.test.infra.KernelTester.testGeneratedHsailUsingLambdaMethod(KernelTester.java:683) at com.oracle.graal.compiler.hsail.test.infra.GraalKernelTester.testGeneratedHsailUsingLambdaMethod(GraalKernelTester.java:206) at com.oracle.graal.compiler.hsail.test.lambda.NewStringEqualsTest.testUsingLambdaMethod(NewStringEqualsTest.java:76) 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.runn ers.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 org.junit.runner.JUnitCore.run(JUnitCore.java:117) at com.oracle.graal.test.GraalJUnitCore.main(GraalJUnitCore.java:102) at JUnitWrapper.main(JUnitWrapper.java:78) Caused by: com.oracle.graal.compiler.common.GraalInternalError: unimplemented: direct call to java.lang.String.equals(Object) at com.oracle.graal.compiler.common.GraalInternalError.unimplemented(GraalInternalError.java:40) at com.oracle.graal.compiler.hsail.HSAILNodeLIRBuilder.emitDirectCall(HSAILNodeLIRBuilder.java:50) at com.oracle.graal.compiler.gen.NodeLIRBuilder.emitInvoke(NodeLIRBuilder.java:472) at com.oracle.graal.nodes.InvokeNode.generate(InvokeNode.java:131) at com.oracle.graal.compiler.gen.NodeLIRBuilder.emitNode(NodeLIRBuilder.java:312) at com.oracle.graal.hotspot.hsail.HSAILHotSpotNodeLIRBuilder.emitNode(HSAILHotSpotNodeLIRBuilder.java:56) at com.oracle.graal.compiler.gen.NodeLIRBuilder.doRoot(NodeLIRBuilder.java:303) at com.oracle.graal.compiler.gen.NodeLIRBuilder.doBlock(NodeLIRBuilder.java:218) ... 46 more FAILURES!!! Tests run: 4527, Failures: 2 From tom.deneau at amd.com Tue Jun 17 15:21:09 2014 From: tom.deneau at amd.com (Deneau, Tom) Date: Tue, 17 Jun 2014 15:21:09 +0000 Subject: webrev to use oops_do to modify saved hsail state Message-ID: I placed a webrev up at http://cr.openjdk.java.net/~tdeneau/graal-webrevs/webrev-hsail-oops-do/webrev/ Please consider this for inclusion in graal. Background: Ever since we started support deoptimization from hsail kernels, we have had to deal with the fact that any oops saved in the hsail deoptimization save area could move around by GC during the windows that open during deoptimizations to the interpreter. Up until now, we had a hackier (and higher overhead) workaround involving copying oops to and from a java Object array and letting them get fixed up there if necessary. This webrev instead uses the standard process of updating the oops in the saved HSAIL state by calling oops_do from a GC thread. * A field was added to JavaThread so that we could tell that a thread was processing an hsail kernel. If so, we go thru the saved hsail frames and apply the oops_do closure to each oop in each saved frame. * Because the saved HSAILFrames are only used during deoptimization to the interpreter, we only need to process the frames for the deopt items that have not been handled yet. A field was added to HSAILDeoptimizationInfo to keep track of this. * Also, note that we don't need to do anything if we have finished the deopting workitems and are handling the never-ran workitems. (The never-rans have to resolve the argument oops, but they always did that). There used to be a class called OopSaver defined in gpu_hsail.cpp. That has been removed and we no longer pass the save array. Some of the logic from OopSaver is now in OopMapHelper. HSAILFrame was extended with a few new functions to help with oops_do. The disabling of ArrayListSetTest was because of an issue we saw unrelated to this webrev. This issue will be fixed in a later webrev. Note: Running with the hsail simulator, there will be a small number of de-opts so it's not the best test environment for this feature, but tests have passed on HSA hardware boxes which can have thousands of de-opts. -- Tom From tom.deneau at amd.com Tue Jun 17 15:32:16 2014 From: tom.deneau at amd.com (Deneau, Tom) Date: Tue, 17 Jun 2014 15:32:16 +0000 Subject: HSAIL (tests) and inlining issue In-Reply-To: References: Message-ID: Doug -- I didn't understand the relation between resolving StringIndexOutOfBoundsException and inlining String.equals(). I'm trying to remember why we disabled RemoveNeverExecutedCode. I think it was because our junits often don't run enough times in java mode to get valid profiling information so we might need code even if it was previously never executed. I need to think more about your suggestion of InlineOrDeopt. While this would allow a test to pass functionally, we wouldn't want to actually offload a kernel where there was a deoptimization on the main compilation path. -- Tom > -----Original Message----- > From: Doug Simon [mailto:doug.simon at oracle.com] > Sent: Tuesday, June 17, 2014 10:03 AM > To: Caspole, Eric; Deneau, Tom > Cc: graal-dev at openjdk.java.net > Subject: HSAIL (tests) and inlining issue > > Eric, Tom, > > We've had issues on our gate recently caused by intermittent failures of > NewStringEqualsTest (stack trace below). If > StringIndexOutOfBoundsException is resolved before this test is run, > then inlining exhausts its budget before getting to inline String.equals > which in turn leaves a direct call in the graph, something that HSAIL > cannot currently handle. The primary problem is the use of > InlineEverything and RemoveNeverExecutedCode in the HSAIL tests. As > we've seen, these don't actually guarantee everything will be inlined. > > For now, I've disabled NewStringEqualsTest and added a comment as to > why. I'm not sure what the longer term solution is. I'd at least like to > see RemoveNeverExecutedCode go away - do we really need it? > > Now that HSAIL supports deopt, maybe we can change InlineEverything to > InlineEverythingOrDeopt - calls that cannot be inlined are replace with > DopetimizeNodes. > > -Doug > > > 2) > testUsingLambdaMethod(com.oracle.graal.compiler.hsail.test.lambda.NewStr > ingEqualsTest) > com.oracle.graal.graph.GraalGraphInternalError: > com.oracle.graal.compiler.common.GraalInternalError: unimplemented: > direct call to java.lang.String.equals(Object) > at node: 110|Invoke#Direct#String.equals > at > com.oracle.graal.graph.GraalGraphInternalError.transformAndAddContext(Gr > aalGraphInternalError.java:136) > at > com.oracle.graal.compiler.gen.NodeLIRBuilder.doBlock(NodeLIRBuilder.java > :220) > at > com.oracle.graal.compiler.GraalCompiler.emitBlock(GraalCompiler.java:216 > ) > at > com.oracle.graal.compiler.GraalCompiler.emitLIR(GraalCompiler.java:250) > at > com.oracle.graal.compiler.GraalCompiler.emitBackEnd(GraalCompiler.java:1 > 98) > at > com.oracle.graal.compiler.GraalCompiler.compileGraph(GraalCompiler.java: > 141) > at > com.oracle.graal.hotspot.hsail.HSAILHotSpotBackend.compileKernel(HSAILHo > tSpotBackend.java:195) > at > com.oracle.graal.hotspot.hsail.HSAILHotSpotBackend.compileAndInstallKern > el(HSAILHotSpotBackend.java:153) > at > com.oracle.graal.compiler.hsail.test.infra.GraalKernelTester.dispatchKer > nelOkra(GraalKernelTester.java:163) > at > com.oracle.graal.compiler.hsail.test.infra.KernelTester.dispatchLambdaMe > thodKernelOkra(KernelTester.java:598) > at > com.oracle.graal.compiler.hsail.test.infra.KernelTester.dispatchLambdaMe > thodKernel(KernelTester.java:279) > at > com.oracle.graal.compiler.hsail.test.infra.KernelTester.dispatchLambdaKe > rnel(KernelTester.java:301) > at > com.oracle.graal.compiler.hsail.test.lambda.NewStringEqualsTest.runTest( > NewStringEqualsTest.java:55) > at > com.oracle.graal.compiler.hsail.test.infra.KernelTester.runOkraInstance( > KernelTester.java:666) > at > com.oracle.graal.compiler.hsail.test.infra.KernelTester.assertOkraEquals > Seq(KernelTester.java:656) > at > com.oracle.graal.compiler.hsail.test.infra.KernelTester.testGeneratedHsa > ilUsingLambdaMethod(KernelTester.java:683) > at > com.oracle.graal.compiler.hsail.test.infra.GraalKernelTester.testGenerat > edHsailUsingLambdaMethod(GraalKernelTester.java:206) > at > com.oracle.graal.compiler.hsail.test.lambda.NewStringEqualsTest.testUsin > gLambdaMethod(NewStringEqualsTest.java:76) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.jav > a:62) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessor > Impl.java:43) > at java.lang.reflect.Method.invoke(Method.java:483) > at > org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMet > hod.java:47) > at > org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallab > le.java:12) > at > org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMetho > d.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.runn > ers.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 org.junit.runner.JUnitCore.run(JUnitCore.java:117) > at > com.oracle.graal.test.GraalJUnitCore.main(GraalJUnitCore.java:102) > at JUnitWrapper.main(JUnitWrapper.java:78) > Caused by: com.oracle.graal.compiler.common.GraalInternalError: > unimplemented: direct call to java.lang.String.equals(Object) > at > com.oracle.graal.compiler.common.GraalInternalError.unimplemented(GraalI > nternalError.java:40) > at > com.oracle.graal.compiler.hsail.HSAILNodeLIRBuilder.emitDirectCall(HSAIL > NodeLIRBuilder.java:50) > at > com.oracle.graal.compiler.gen.NodeLIRBuilder.emitInvoke(NodeLIRBuilder.j > ava:472) > at > com.oracle.graal.nodes.InvokeNode.generate(InvokeNode.java:131) > at > com.oracle.graal.compiler.gen.NodeLIRBuilder.emitNode(NodeLIRBuilder.jav > a:312) > at > com.oracle.graal.hotspot.hsail.HSAILHotSpotNodeLIRBuilder.emitNode(HSAIL > HotSpotNodeLIRBuilder.java:56) > at > com.oracle.graal.compiler.gen.NodeLIRBuilder.doRoot(NodeLIRBuilder.java: > 303) > at > com.oracle.graal.compiler.gen.NodeLIRBuilder.doBlock(NodeLIRBuilder.java > :218) > ... 46 more > > FAILURES!!! > Tests run: 4527, Failures: 2 From doug.simon at oracle.com Tue Jun 17 15:45:15 2014 From: doug.simon at oracle.com (Doug Simon) Date: Tue, 17 Jun 2014 17:45:15 +0200 Subject: HSAIL (tests) and inlining issue In-Reply-To: References: Message-ID: On Jun 17, 2014, at 5:32 PM, Deneau, Tom wrote: > Doug -- > > I didn't understand the relation between resolving StringIndexOutOfBoundsException and inlining String.equals(). In com.oracle.graal.compiler.hsail.test.lambda.NewStringEqualsTest.runTest() we have the following: dispatchLambdaKernel(NUM, (gid) -> { outArray[gid] = new String(chars, 0, 10 + (gid % 3)).equals(base); }); The String(char[], int, int) constructor called above contains: if (count < 0) { throw new StringIndexOutOfBoundsException(count); } When RemoveNeverExecutedCode == false, then the ?then? branch will be compiled. If StringIndexOutOfBoundsException is unresolved, the allocation of StringIndexOutOfBoundsException is converted to a deopt. If it?s resolved, then InlineEverything==true ensure it is inlined. This constructor (indirectly) recursively calls String(char[], int, int). The inliner performs recursive inlining until it hits GraalOptions.MaximumDesiredSize which means it never gets to inline String.equals. > I'm trying to remember why we disabled RemoveNeverExecutedCode. I think it was because our junits often don't run enough times in java mode to get valid profiling information so we might need code even if it was previously never executed. You could make the unit tests run in Java mode in a loop long enough to get the desired profile. > I need to think more about your suggestion of InlineOrDeopt. While this would allow a test to pass functionally, we wouldn't want to actually offload a kernel where there was a deoptimization on the main compilation path. Won?t the profile gathered for the kernel prior to compilation be accurate in most cases? -Doug >> -----Original Message----- >> From: Doug Simon [mailto:doug.simon at oracle.com] >> Sent: Tuesday, June 17, 2014 10:03 AM >> To: Caspole, Eric; Deneau, Tom >> Cc: graal-dev at openjdk.java.net >> Subject: HSAIL (tests) and inlining issue >> >> Eric, Tom, >> >> We've had issues on our gate recently caused by intermittent failures of >> NewStringEqualsTest (stack trace below). If >> StringIndexOutOfBoundsException is resolved before this test is run, >> then inlining exhausts its budget before getting to inline String.equals >> which in turn leaves a direct call in the graph, something that HSAIL >> cannot currently handle. The primary problem is the use of >> InlineEverything and RemoveNeverExecutedCode in the HSAIL tests. As >> we've seen, these don't actually guarantee everything will be inlined. >> >> For now, I've disabled NewStringEqualsTest and added a comment as to >> why. I'm not sure what the longer term solution is. I'd at least like to >> see RemoveNeverExecutedCode go away - do we really need it? >> >> Now that HSAIL supports deopt, maybe we can change InlineEverything to >> InlineEverythingOrDeopt - calls that cannot be inlined are replace with >> DopetimizeNodes. >> >> -Doug >> >> >> 2) >> testUsingLambdaMethod(com.oracle.graal.compiler.hsail.test.lambda.NewStr >> ingEqualsTest) >> com.oracle.graal.graph.GraalGraphInternalError: >> com.oracle.graal.compiler.common.GraalInternalError: unimplemented: >> direct call to java.lang.String.equals(Object) >> at node: 110|Invoke#Direct#String.equals >> at >> com.oracle.graal.graph.GraalGraphInternalError.transformAndAddContext(Gr >> aalGraphInternalError.java:136) >> at >> com.oracle.graal.compiler.gen.NodeLIRBuilder.doBlock(NodeLIRBuilder.java >> :220) >> at >> com.oracle.graal.compiler.GraalCompiler.emitBlock(GraalCompiler.java:216 >> ) >> at >> com.oracle.graal.compiler.GraalCompiler.emitLIR(GraalCompiler.java:250) >> at >> com.oracle.graal.compiler.GraalCompiler.emitBackEnd(GraalCompiler.java:1 >> 98) >> at >> com.oracle.graal.compiler.GraalCompiler.compileGraph(GraalCompiler.java: >> 141) >> at >> com.oracle.graal.hotspot.hsail.HSAILHotSpotBackend.compileKernel(HSAILHo >> tSpotBackend.java:195) >> at >> com.oracle.graal.hotspot.hsail.HSAILHotSpotBackend.compileAndInstallKern >> el(HSAILHotSpotBackend.java:153) >> at >> com.oracle.graal.compiler.hsail.test.infra.GraalKernelTester.dispatchKer >> nelOkra(GraalKernelTester.java:163) >> at >> com.oracle.graal.compiler.hsail.test.infra.KernelTester.dispatchLambdaMe >> thodKernelOkra(KernelTester.java:598) >> at >> com.oracle.graal.compiler.hsail.test.infra.KernelTester.dispatchLambdaMe >> thodKernel(KernelTester.java:279) >> at >> com.oracle.graal.compiler.hsail.test.infra.KernelTester.dispatchLambdaKe >> rnel(KernelTester.java:301) >> at >> com.oracle.graal.compiler.hsail.test.lambda.NewStringEqualsTest.runTest( >> NewStringEqualsTest.java:55) >> at >> com.oracle.graal.compiler.hsail.test.infra.KernelTester.runOkraInstance( >> KernelTester.java:666) >> at >> com.oracle.graal.compiler.hsail.test.infra.KernelTester.assertOkraEquals >> Seq(KernelTester.java:656) >> at >> com.oracle.graal.compiler.hsail.test.infra.KernelTester.testGeneratedHsa >> ilUsingLambdaMethod(KernelTester.java:683) >> at >> com.oracle.graal.compiler.hsail.test.infra.GraalKernelTester.testGenerat >> edHsailUsingLambdaMethod(GraalKernelTester.java:206) >> at >> com.oracle.graal.compiler.hsail.test.lambda.NewStringEqualsTest.testUsin >> gLambdaMethod(NewStringEqualsTest.java:76) >> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) >> at >> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.jav >> a:62) >> at >> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessor >> Impl.java:43) >> at java.lang.reflect.Method.invoke(Method.java:483) >> at >> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMet >> hod.java:47) >> at >> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallab >> le.java:12) >> at >> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMetho >> d.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.runn >> ers.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 org.junit.runner.JUnitCore.run(JUnitCore.java:117) >> at >> com.oracle.graal.test.GraalJUnitCore.main(GraalJUnitCore.java:102) >> at JUnitWrapper.main(JUnitWrapper.java:78) >> Caused by: com.oracle.graal.compiler.common.GraalInternalError: >> unimplemented: direct call to java.lang.String.equals(Object) >> at >> com.oracle.graal.compiler.common.GraalInternalError.unimplemented(GraalI >> nternalError.java:40) >> at >> com.oracle.graal.compiler.hsail.HSAILNodeLIRBuilder.emitDirectCall(HSAIL >> NodeLIRBuilder.java:50) >> at >> com.oracle.graal.compiler.gen.NodeLIRBuilder.emitInvoke(NodeLIRBuilder.j >> ava:472) >> at >> com.oracle.graal.nodes.InvokeNode.generate(InvokeNode.java:131) >> at >> com.oracle.graal.compiler.gen.NodeLIRBuilder.emitNode(NodeLIRBuilder.jav >> a:312) >> at >> com.oracle.graal.hotspot.hsail.HSAILHotSpotNodeLIRBuilder.emitNode(HSAIL >> HotSpotNodeLIRBuilder.java:56) >> at >> com.oracle.graal.compiler.gen.NodeLIRBuilder.doRoot(NodeLIRBuilder.java: >> 303) >> at >> com.oracle.graal.compiler.gen.NodeLIRBuilder.doBlock(NodeLIRBuilder.java >> :218) >> ... 46 more >> >> FAILURES!!! >> Tests run: 4527, Failures: 2 From doug.simon at oracle.com Tue Jun 17 15:46:28 2014 From: doug.simon at oracle.com (doug.simon at oracle.com) Date: Tue, 17 Jun 2014 15:46:28 +0000 Subject: hg: graal/graal: 9 new changesets Message-ID: <201406171546.s5HFkeDs024786@aojmv0008> Changeset: a0d1dfc113b8 Author: Roland Schatz Date: 2014-06-16 19:38 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/a0d1dfc113b8 Better documentation for HotSpotReferenceMap. ! graal/com.oracle.graal.api.code/src/com/oracle/graal/api/code/Architecture.java ! graal/com.oracle.graal.api.code/src/com/oracle/graal/api/code/Register.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/HotSpotReferenceMap.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/HotSpotTargetDescription.java Changeset: 9a595d3f9a2f Author: Roland Schatz Date: 2014-06-17 09:43 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/9a595d3f9a2f Handle narrow oops in redundant move elimination. ! graal/com.oracle.graal.lir/src/com/oracle/graal/lir/RedundantMoveElimination.java Changeset: 9e5a323e0a1e Author: Roland Schatz Date: 2014-06-17 09:59 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/9e5a323e0a1e Remove hotspot specific NarrowOop kind, use LIRKind.reference(Kind.Int) instead. ! graal/com.oracle.graal.hotspot.amd64/src/com/oracle/graal/hotspot/amd64/AMD64HotSpotBackendFactory.java ! graal/com.oracle.graal.hotspot.amd64/src/com/oracle/graal/hotspot/amd64/AMD64HotSpotCompare.java ! graal/com.oracle.graal.hotspot.amd64/src/com/oracle/graal/hotspot/amd64/AMD64HotSpotLIRGenerator.java ! graal/com.oracle.graal.hotspot.amd64/src/com/oracle/graal/hotspot/amd64/AMD64HotSpotRegisterConfig.java ! graal/com.oracle.graal.hotspot.hsail/src/com/oracle/graal/hotspot/hsail/HSAILHotSpotBackendFactory.java ! graal/com.oracle.graal.hotspot.hsail/src/com/oracle/graal/hotspot/hsail/HSAILHotSpotLIRGenerator.java ! graal/com.oracle.graal.hotspot.hsail/src/com/oracle/graal/hotspot/hsail/HSAILHotSpotRegisterConfig.java ! graal/com.oracle.graal.hotspot.ptx/src/com/oracle/graal/hotspot/ptx/PTXHotSpotBackendFactory.java ! graal/com.oracle.graal.hotspot.sparc/src/com/oracle/graal/hotspot/sparc/SPARCHotSpotBackendFactory.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/HotSpotTargetDescription.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/data/OopData.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotCompressedNullConstant.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotObjectConstant.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/nodes/type/NarrowOopStamp.java Changeset: 3b4690ddd92e Author: Roland Schatz Date: 2014-06-17 10:09 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/3b4690ddd92e Enable UseGraalCompilationQueue in bootstrap gate tests. ! mx/mx_graal.py Changeset: 5cbaad0b7387 Author: Roland Schatz Date: 2014-06-17 11:53 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/5cbaad0b7387 Verify usage of equals method in LIRKind. ! graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/CheckGraalInvariants.java ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/alloc/Interval.java ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/alloc/LinearScan.java ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/alloc/MoveResolver.java ! graal/com.oracle.graal.hotspot.hsail/src/com/oracle/graal/hotspot/hsail/HSAILHotSpotLIRGenerator.java ! graal/com.oracle.graal.lir/src/com/oracle/graal/lir/FrameMap.java Changeset: 310994c667a7 Author: Doug Simon Date: 2014-06-17 12:05 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/310994c667a7 HSAIL: support offloading some IntStream.reduce() operations to HSA Contributed-by: Eric Caspole + graal/com.oracle.graal.compiler.hsail.test/src/com/oracle/graal/compiler/hsail/test/lambda/ReduceMaxTest.java + graal/com.oracle.graal.compiler.hsail.test/src/com/oracle/graal/compiler/hsail/test/lambda/ReduceMinTest.java + graal/com.oracle.graal.compiler.hsail.test/src/com/oracle/graal/compiler/hsail/test/lambda/ReduceSumTest.java ! graal/com.oracle.graal.compiler.hsail/src/com/oracle/graal/compiler/hsail/CompileAndDispatch.java ! graal/com.oracle.graal.hotspot.hsail/src/com/oracle/graal/hotspot/hsail/ForEachToGraal.java ! graal/com.oracle.graal.hotspot.hsail/src/com/oracle/graal/hotspot/hsail/HSAILHotSpotBackend.java ! src/gpu/hsail/vm/gpu_hsail.hpp ! src/gpu/hsail/vm/hsailArgumentsBase.cpp ! src/gpu/hsail/vm/hsailArgumentsBase.hpp + src/gpu/hsail/vm/hsailKernelArguments.cpp ! src/gpu/hsail/vm/hsailKernelArguments.hpp Changeset: af8b7d059e03 Author: Doug Simon Date: 2014-06-17 16:37 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/af8b7d059e03 HSAIL: disabled NewStringEqualsTest ! graal/com.oracle.graal.compiler.hsail.test/src/com/oracle/graal/compiler/hsail/test/lambda/NewStringEqualsTest.java Changeset: 4b1c42d33929 Author: Doug Simon Date: 2014-06-17 16:48 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/4b1c42d33929 HSAIL: make tests run clean with -XX:-UseHSAILDeoptimization Contributed-by: Eric Caspole ! graal/com.oracle.graal.compiler.hsail.test/src/com/oracle/graal/compiler/hsail/test/lambda/ArrayListSetTest.java ! graal/com.oracle.graal.compiler.hsail.test/src/com/oracle/graal/compiler/hsail/test/lambda/StringBuilderTest.java Changeset: 466211b0f8ae Author: Doug Simon Date: 2014-06-17 16:49 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/466211b0f8ae Merge. From tom.deneau at amd.com Tue Jun 17 16:49:15 2014 From: tom.deneau at amd.com (Deneau, Tom) Date: Tue, 17 Jun 2014 16:49:15 +0000 Subject: HSAIL (tests) and inlining issue In-Reply-To: References: Message-ID: > -----Original Message----- > From: Doug Simon [mailto:doug.simon at oracle.com] > Sent: Tuesday, June 17, 2014 10:45 AM > To: Deneau, Tom > Cc: Caspole, Eric; graal-dev at openjdk.java.net > Subject: Re: HSAIL (tests) and inlining issue > > > On Jun 17, 2014, at 5:32 PM, Deneau, Tom wrote: > > > Doug -- > > > > I didn't understand the relation between resolving > StringIndexOutOfBoundsException and inlining String.equals(). > > In > com.oracle.graal.compiler.hsail.test.lambda.NewStringEqualsTest.runTest( > ) we have the following: > > dispatchLambdaKernel(NUM, (gid) -> { > outArray[gid] = new String(chars, 0, 10 + (gid % > 3)).equals(base); > }); > > The String(char[], int, int) constructor called above contains: > > if (count < 0) { > throw new StringIndexOutOfBoundsException(count); > } > > When RemoveNeverExecutedCode == false, then the 'then' branch will be > compiled. If StringIndexOutOfBoundsException is unresolved, the > allocation of StringIndexOutOfBoundsException is converted to a deopt. > If it's resolved, then InlineEverything==true ensure it is inlined. This > constructor (indirectly) recursively calls String(char[], int, int). The > inliner performs recursive inlining until it hits > GraalOptions.MaximumDesiredSize which means it never gets to inline > String.equals. > > > I'm trying to remember why we disabled RemoveNeverExecutedCode. I > think it was because our junits often don't run enough times in java > mode to get valid profiling information so we might need code even if it > was previously never executed. > > You could make the unit tests run in Java mode in a loop long enough to > get the desired profile. > Agreed. If the profile runs long enough, we can trust it and deopt on the paths that weren't executed and get rid of -G:-RemoveNeverExecutedCode. And I guess if we do find something deopting we can always try to recompile. We'll try to plan out some way to deal with this. > > I need to think more about your suggestion of InlineOrDeopt. While > this would allow a test to pass functionally, we wouldn't want to > actually offload a kernel where there was a deoptimization on the main > compilation path. > > Won't the profile gathered for the kernel prior to compilation be > accurate in most cases? Yes as mentioned above, if it runs long enough we should be able to trust it for removing never-executed code, etc. But what about an actual recursive method in the main path? We can't inline that, so we would deopt but it would be a poor offload candidate if it de-opted on the main codepath. > > -Doug > > >> -----Original Message----- > >> From: Doug Simon [mailto:doug.simon at oracle.com] > >> Sent: Tuesday, June 17, 2014 10:03 AM > >> To: Caspole, Eric; Deneau, Tom > >> Cc: graal-dev at openjdk.java.net > >> Subject: HSAIL (tests) and inlining issue > >> > >> Eric, Tom, > >> > >> We've had issues on our gate recently caused by intermittent failures > >> of NewStringEqualsTest (stack trace below). If > >> StringIndexOutOfBoundsException is resolved before this test is run, > >> then inlining exhausts its budget before getting to inline > >> String.equals which in turn leaves a direct call in the graph, > >> something that HSAIL cannot currently handle. The primary problem is > >> the use of InlineEverything and RemoveNeverExecutedCode in the HSAIL > >> tests. As we've seen, these don't actually guarantee everything will > be inlined. > >> > >> For now, I've disabled NewStringEqualsTest and added a comment as to > >> why. I'm not sure what the longer term solution is. I'd at least like > >> to see RemoveNeverExecutedCode go away - do we really need it? > >> > >> Now that HSAIL supports deopt, maybe we can change InlineEverything > >> to InlineEverythingOrDeopt - calls that cannot be inlined are replace > >> with DopetimizeNodes. > >> > >> -Doug > >> > >> > >> 2) > >> testUsingLambdaMethod(com.oracle.graal.compiler.hsail.test.lambda.New > >> Str > >> ingEqualsTest) > >> com.oracle.graal.graph.GraalGraphInternalError: > >> com.oracle.graal.compiler.common.GraalInternalError: unimplemented: > >> direct call to java.lang.String.equals(Object) > >> at node: 110|Invoke#Direct#String.equals > >> at > >> com.oracle.graal.graph.GraalGraphInternalError.transformAndAddContext > >> (Gr > >> aalGraphInternalError.java:136) > >> at > >> com.oracle.graal.compiler.gen.NodeLIRBuilder.doBlock(NodeLIRBuilder.j > >> ava > >> :220) > >> at > >> com.oracle.graal.compiler.GraalCompiler.emitBlock(GraalCompiler.java: > >> 216 > >> ) > >> at > >> > com.oracle.graal.compiler.GraalCompiler.emitLIR(GraalCompiler.java:250) > >> at > >> com.oracle.graal.compiler.GraalCompiler.emitBackEnd(GraalCompiler.jav > >> a:1 > >> 98) > >> at > >> > com.oracle.graal.compiler.GraalCompiler.compileGraph(GraalCompiler.java: > >> 141) > >> at > >> com.oracle.graal.hotspot.hsail.HSAILHotSpotBackend.compileKernel(HSAI > >> LHo > >> tSpotBackend.java:195) > >> at > >> com.oracle.graal.hotspot.hsail.HSAILHotSpotBackend.compileAndInstallK > >> ern > >> el(HSAILHotSpotBackend.java:153) > >> at > >> com.oracle.graal.compiler.hsail.test.infra.GraalKernelTester.dispatch > >> Ker > >> nelOkra(GraalKernelTester.java:163) > >> at > >> com.oracle.graal.compiler.hsail.test.infra.KernelTester.dispatchLambd > >> aMe > >> thodKernelOkra(KernelTester.java:598) > >> at > >> com.oracle.graal.compiler.hsail.test.infra.KernelTester.dispatchLambd > >> aMe > >> thodKernel(KernelTester.java:279) > >> at > >> com.oracle.graal.compiler.hsail.test.infra.KernelTester.dispatchLambd > >> aKe > >> rnel(KernelTester.java:301) > >> at > >> com.oracle.graal.compiler.hsail.test.lambda.NewStringEqualsTest.runTe > >> st( > >> NewStringEqualsTest.java:55) > >> at > >> com.oracle.graal.compiler.hsail.test.infra.KernelTester.runOkraInstan > >> ce( > >> KernelTester.java:666) > >> at > >> com.oracle.graal.compiler.hsail.test.infra.KernelTester.assertOkraEqu > >> als > >> Seq(KernelTester.java:656) > >> at > >> com.oracle.graal.compiler.hsail.test.infra.KernelTester.testGenerated > >> Hsa > >> ilUsingLambdaMethod(KernelTester.java:683) > >> at > >> com.oracle.graal.compiler.hsail.test.infra.GraalKernelTester.testGene > >> rat > >> edHsailUsingLambdaMethod(GraalKernelTester.java:206) > >> at > >> com.oracle.graal.compiler.hsail.test.lambda.NewStringEqualsTest.testU > >> sin > >> gLambdaMethod(NewStringEqualsTest.java:76) > >> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > >> at > >> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl. > >> jav > >> a:62) > >> at > >> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces > >> sor > >> Impl.java:43) > >> at java.lang.reflect.Method.invoke(Method.java:483) > >> at > >> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(Framework > >> Met > >> hod.java:47) > >> at > >> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCal > >> lab > >> le.java:12) > >> at > >> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMe > >> tho > >> d.java:44) > >> at > >> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMet > >> hod > >> .java:17) > >> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:271) > >> at > >> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRun > >> ner > >> .java:70) > >> at > >> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRun > >> ner > >> .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.runn > >> ers.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 org.junit.runner.JUnitCore.run(JUnitCore.java:117) > >> at > >> com.oracle.graal.test.GraalJUnitCore.main(GraalJUnitCore.java:102) > >> at JUnitWrapper.main(JUnitWrapper.java:78) > >> Caused by: com.oracle.graal.compiler.common.GraalInternalError: > >> unimplemented: direct call to java.lang.String.equals(Object) > >> at > >> com.oracle.graal.compiler.common.GraalInternalError.unimplemented(Gra > >> alI > >> nternalError.java:40) > >> at > >> com.oracle.graal.compiler.hsail.HSAILNodeLIRBuilder.emitDirectCall(HS > >> AIL > >> NodeLIRBuilder.java:50) > >> at > >> com.oracle.graal.compiler.gen.NodeLIRBuilder.emitInvoke(NodeLIRBuilde > >> r.j > >> ava:472) > >> at > >> com.oracle.graal.nodes.InvokeNode.generate(InvokeNode.java:131) > >> at > >> com.oracle.graal.compiler.gen.NodeLIRBuilder.emitNode(NodeLIRBuilder. > >> jav > >> a:312) > >> at > >> com.oracle.graal.hotspot.hsail.HSAILHotSpotNodeLIRBuilder.emitNode(HS > >> AIL > >> HotSpotNodeLIRBuilder.java:56) > >> at > >> > com.oracle.graal.compiler.gen.NodeLIRBuilder.doRoot(NodeLIRBuilder.java: > >> 303) > >> at > >> com.oracle.graal.compiler.gen.NodeLIRBuilder.doBlock(NodeLIRBuilder.j > >> ava > >> :218) > >> ... 46 more > >> > >> FAILURES!!! > >> Tests run: 4527, Failures: 2 From doug.simon at oracle.com Tue Jun 17 19:00:57 2014 From: doug.simon at oracle.com (Doug Simon) Date: Tue, 17 Jun 2014 21:00:57 +0200 Subject: HSAIL (tests) and inlining issue In-Reply-To: References: Message-ID: <84CBD3B5-7849-4123-8DA7-825D7CC3D14B@oracle.com> On Jun 17, 2014, at 6:49 PM, Deneau, Tom wrote: > > >> -----Original Message----- >> From: Doug Simon [mailto:doug.simon at oracle.com] >> Sent: Tuesday, June 17, 2014 10:45 AM >> To: Deneau, Tom >> Cc: Caspole, Eric; graal-dev at openjdk.java.net >> Subject: Re: HSAIL (tests) and inlining issue >> >> >> On Jun 17, 2014, at 5:32 PM, Deneau, Tom wrote: >> >>> Doug -- >>> >>> I didn't understand the relation between resolving >> StringIndexOutOfBoundsException and inlining String.equals(). >> >> In >> com.oracle.graal.compiler.hsail.test.lambda.NewStringEqualsTest.runTest( >> ) we have the following: >> >> dispatchLambdaKernel(NUM, (gid) -> { >> outArray[gid] = new String(chars, 0, 10 + (gid % >> 3)).equals(base); >> }); >> >> The String(char[], int, int) constructor called above contains: >> >> if (count < 0) { >> throw new StringIndexOutOfBoundsException(count); >> } >> >> When RemoveNeverExecutedCode == false, then the 'then' branch will be >> compiled. If StringIndexOutOfBoundsException is unresolved, the >> allocation of StringIndexOutOfBoundsException is converted to a deopt. >> If it's resolved, then InlineEverything==true ensure it is inlined. This >> constructor (indirectly) recursively calls String(char[], int, int). The >> inliner performs recursive inlining until it hits >> GraalOptions.MaximumDesiredSize which means it never gets to inline >> String.equals. >> >>> I'm trying to remember why we disabled RemoveNeverExecutedCode. I >> think it was because our junits often don't run enough times in java >> mode to get valid profiling information so we might need code even if it >> was previously never executed. >> >> You could make the unit tests run in Java mode in a loop long enough to >> get the desired profile. >> > > Agreed. If the profile runs long enough, we can trust it and deopt on the paths that weren't executed and get rid of -G:-RemoveNeverExecutedCode. And I guess if we do find something deopting we can always try to recompile. > > We'll try to plan out some way to deal with this. > >>> I need to think more about your suggestion of InlineOrDeopt. While >> this would allow a test to pass functionally, we wouldn't want to >> actually offload a kernel where there was a deoptimization on the main >> compilation path. >> >> Won't the profile gathered for the kernel prior to compilation be >> accurate in most cases? > > Yes as mentioned above, if it runs long enough we should be able to trust it for removing never-executed code, etc. But what about an actual recursive method in the main path? We can't inline that, so we would deopt but it would be a poor offload candidate if it de-opted on the main code path. This concern applies to normal (i.e. non-offloaded) code as well so whatever strategy the inliner takes for hot recursive calls should work as well for HSAIL code. That said, giving that the cost of deopting is higher for offload code, we may want to be able to parameterize the inlining strategy with a multiplier for the relative cost of an uncommon trap. Thomas is currently working on the new inlining implementation and may be able to comment on other ways recursive calls will be handled. -Doug >>>> -----Original Message----- >>>> From: Doug Simon [mailto:doug.simon at oracle.com] >>>> Sent: Tuesday, June 17, 2014 10:03 AM >>>> To: Caspole, Eric; Deneau, Tom >>>> Cc: graal-dev at openjdk.java.net >>>> Subject: HSAIL (tests) and inlining issue >>>> >>>> Eric, Tom, >>>> >>>> We've had issues on our gate recently caused by intermittent failures >>>> of NewStringEqualsTest (stack trace below). If >>>> StringIndexOutOfBoundsException is resolved before this test is run, >>>> then inlining exhausts its budget before getting to inline >>>> String.equals which in turn leaves a direct call in the graph, >>>> something that HSAIL cannot currently handle. The primary problem is >>>> the use of InlineEverything and RemoveNeverExecutedCode in the HSAIL >>>> tests. As we've seen, these don't actually guarantee everything will >> be inlined. >>>> >>>> For now, I've disabled NewStringEqualsTest and added a comment as to >>>> why. I'm not sure what the longer term solution is. I'd at least like >>>> to see RemoveNeverExecutedCode go away - do we really need it? >>>> >>>> Now that HSAIL supports deopt, maybe we can change InlineEverything >>>> to InlineEverythingOrDeopt - calls that cannot be inlined are replace >>>> with DopetimizeNodes. >>>> >>>> -Doug >>>> >>>> >>>> 2) >>>> testUsingLambdaMethod(com.oracle.graal.compiler.hsail.test.lambda.New >>>> Str >>>> ingEqualsTest) >>>> com.oracle.graal.graph.GraalGraphInternalError: >>>> com.oracle.graal.compiler.common.GraalInternalError: unimplemented: >>>> direct call to java.lang.String.equals(Object) >>>> at node: 110|Invoke#Direct#String.equals >>>> at >>>> com.oracle.graal.graph.GraalGraphInternalError.transformAndAddContext >>>> (Gr >>>> aalGraphInternalError.java:136) >>>> at >>>> com.oracle.graal.compiler.gen.NodeLIRBuilder.doBlock(NodeLIRBuilder.j >>>> ava >>>> :220) >>>> at >>>> com.oracle.graal.compiler.GraalCompiler.emitBlock(GraalCompiler.java: >>>> 216 >>>> ) >>>> at >>>> >> com.oracle.graal.compiler.GraalCompiler.emitLIR(GraalCompiler.java:250) >>>> at >>>> com.oracle.graal.compiler.GraalCompiler.emitBackEnd(GraalCompiler.jav >>>> a:1 >>>> 98) >>>> at >>>> >> com.oracle.graal.compiler.GraalCompiler.compileGraph(GraalCompiler.java: >>>> 141) >>>> at >>>> com.oracle.graal.hotspot.hsail.HSAILHotSpotBackend.compileKernel(HSAI >>>> LHo >>>> tSpotBackend.java:195) >>>> at >>>> com.oracle.graal.hotspot.hsail.HSAILHotSpotBackend.compileAndInstallK >>>> ern >>>> el(HSAILHotSpotBackend.java:153) >>>> at >>>> com.oracle.graal.compiler.hsail.test.infra.GraalKernelTester.dispatch >>>> Ker >>>> nelOkra(GraalKernelTester.java:163) >>>> at >>>> com.oracle.graal.compiler.hsail.test.infra.KernelTester.dispatchLambd >>>> aMe >>>> thodKernelOkra(KernelTester.java:598) >>>> at >>>> com.oracle.graal.compiler.hsail.test.infra.KernelTester.dispatchLambd >>>> aMe >>>> thodKernel(KernelTester.java:279) >>>> at >>>> com.oracle.graal.compiler.hsail.test.infra.KernelTester.dispatchLambd >>>> aKe >>>> rnel(KernelTester.java:301) >>>> at >>>> com.oracle.graal.compiler.hsail.test.lambda.NewStringEqualsTest.runTe >>>> st( >>>> NewStringEqualsTest.java:55) >>>> at >>>> com.oracle.graal.compiler.hsail.test.infra.KernelTester.runOkraInstan >>>> ce( >>>> KernelTester.java:666) >>>> at >>>> com.oracle.graal.compiler.hsail.test.infra.KernelTester.assertOkraEqu >>>> als >>>> Seq(KernelTester.java:656) >>>> at >>>> com.oracle.graal.compiler.hsail.test.infra.KernelTester.testGenerated >>>> Hsa >>>> ilUsingLambdaMethod(KernelTester.java:683) >>>> at >>>> com.oracle.graal.compiler.hsail.test.infra.GraalKernelTester.testGene >>>> rat >>>> edHsailUsingLambdaMethod(GraalKernelTester.java:206) >>>> at >>>> com.oracle.graal.compiler.hsail.test.lambda.NewStringEqualsTest.testU >>>> sin >>>> gLambdaMethod(NewStringEqualsTest.java:76) >>>> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) >>>> at >>>> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl. >>>> jav >>>> a:62) >>>> at >>>> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces >>>> sor >>>> Impl.java:43) >>>> at java.lang.reflect.Method.invoke(Method.java:483) >>>> at >>>> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(Framework >>>> Met >>>> hod.java:47) >>>> at >>>> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCal >>>> lab >>>> le.java:12) >>>> at >>>> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMe >>>> tho >>>> d.java:44) >>>> at >>>> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMet >>>> hod >>>> .java:17) >>>> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:271) >>>> at >>>> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRun >>>> ner >>>> .java:70) >>>> at >>>> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRun >>>> ner >>>> .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.runn >>>> ers.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 org.junit.runner.JUnitCore.run(JUnitCore.java:117) >>>> at >>>> com.oracle.graal.test.GraalJUnitCore.main(GraalJUnitCore.java:102) >>>> at JUnitWrapper.main(JUnitWrapper.java:78) >>>> Caused by: com.oracle.graal.compiler.common.GraalInternalError: >>>> unimplemented: direct call to java.lang.String.equals(Object) >>>> at >>>> com.oracle.graal.compiler.common.GraalInternalError.unimplemented(Gra >>>> alI >>>> nternalError.java:40) >>>> at >>>> com.oracle.graal.compiler.hsail.HSAILNodeLIRBuilder.emitDirectCall(HS >>>> AIL >>>> NodeLIRBuilder.java:50) >>>> at >>>> com.oracle.graal.compiler.gen.NodeLIRBuilder.emitInvoke(NodeLIRBuilde >>>> r.j >>>> ava:472) >>>> at >>>> com.oracle.graal.nodes.InvokeNode.generate(InvokeNode.java:131) >>>> at >>>> com.oracle.graal.compiler.gen.NodeLIRBuilder.emitNode(NodeLIRBuilder. >>>> jav >>>> a:312) >>>> at >>>> com.oracle.graal.hotspot.hsail.HSAILHotSpotNodeLIRBuilder.emitNode(HS >>>> AIL >>>> HotSpotNodeLIRBuilder.java:56) >>>> at >>>> >> com.oracle.graal.compiler.gen.NodeLIRBuilder.doRoot(NodeLIRBuilder.java: >>>> 303) >>>> at >>>> com.oracle.graal.compiler.gen.NodeLIRBuilder.doBlock(NodeLIRBuilder.j >>>> ava >>>> :218) >>>> ... 46 more >>>> >>>> FAILURES!!! >>>> Tests run: 4527, Failures: 2 From jules_gosnell at yahoo.com Tue Jun 17 20:30:36 2014 From: jules_gosnell at yahoo.com (Jules Gosnell) Date: Tue, 17 Jun 2014 21:30:36 +0100 Subject: ? graal regression / okra simulator bug ? Message-ID: <53A0A56C.5030901@yahoo.com> Guys, Somewhere between the 14th (build# 268) and 15th (build# 273) June a SEGV crept into my nightly jdk8/graal/okra-simulator/clumatra build/test-suite: http://ouroboros.dyndns-free.com/ci/view/clumatra/job/clumatra-simulated-acceleration/ The issue is not present in my identical okra-hardware build which [builds and] tests exactly the same jdk/graal/okra/clumatra stack on an Ubuntu/KFD/Kaveri system: http://ouroboros.dyndns-free.com/ci/view/clumatra/job/clumatra-hardware-acceleration/ I build with the following flags: -Xms1g -Xmx8g -server -XX:-UseHSAILDeoptimization -XX:-UseHSAILSafepoints -G:+DumpOnError -G:Log=CodeGen -XX:+GPUOffload -XX:+TraceGPUInteraction You can see the segv and accompanying debugging at the end of all okra-simulated builds > #268 logs on the page above - e.g. http://ouroboros.dyndns-free.com/ci/view/clumatra/job/clumatra-simulated-acceleration/273/consoleFull Any help would be much appreciated - I can provide more detail on request. many thanks, Jules From jules_gosnell at yahoo.com Tue Jun 17 20:43:27 2014 From: jules_gosnell at yahoo.com (Jules Gosnell) Date: Tue, 17 Jun 2014 21:43:27 +0100 Subject: reduction / graal / kaveri / heterogeneous queueing ? Message-ID: <53A0A86F.2040309@yahoo.com> Guys, I have been playing with a system of gpu based reduction that is intended to work as follows: e.g. public void kernel(Object[] input, Object[] output, int i) { output[i] = foo(input[i*2], input[(i*2)+1]; } foo is the reducing function and is expected to return the reduction of two elements of the sequence being reduced. kernel would be called with e.g. input=Object[2n], output=Object[n], i=n. The idea is to go through a number of reduction steps, each one taking an input of size 2x and producing an output of size x, which can then be fed back into the same kernel as input for the following round. Odds and ends can be picked up by the cpu and folded in at a suitable juncture - repeat until output array is too small to reduce further on the gpu and so finish up the reduction on the cpu.... Questions: - does this sound sensible ? - I've read about Kaveri h/w supporting heterogeneous (including gpu->gpu) queueing. Is this available, or are there plans to surface it, in clumatra/graal/okra ? I need this to sequence the steps of my reduction efficiently. - anything else that anyone feels is relevant :-) looking forward to hearing from you, Jules From Eric.Caspole at amd.com Tue Jun 17 21:32:27 2014 From: Eric.Caspole at amd.com (Caspole, Eric) Date: Tue, 17 Jun 2014 21:32:27 +0000 Subject: reduction / graal / kaveri / heterogeneous queueing ? In-Reply-To: <53A0A86F.2040309@yahoo.com> References: <53A0A86F.2040309@yahoo.com> Message-ID: Hi Jules, I have been experimenting with IntStream reduces for a while now and mine works the same way, passing in the output array as you show here.The first version I have is based on this algorithm in the BOLT library - https://github.com/HSA-Libraries/Bolt/blob/master/include/bolt/cl/reduce_kernels.cl The HSA runtime spec is not finalized yet. When it is we will have a better idea on the possibility of using the dynamic job queuing in Sumatra. Regards, Eric ________________________________________ From: graal-dev [graal-dev-bounces at openjdk.java.net] on behalf of Jules Gosnell [jules_gosnell at yahoo.com] Sent: Tuesday, June 17, 2014 4:43 PM To: graal-dev at openjdk.java.net Subject: reduction / graal / kaveri / heterogeneous queueing ? Guys, I have been playing with a system of gpu based reduction that is intended to work as follows: e.g. public void kernel(Object[] input, Object[] output, int i) { output[i] = foo(input[i*2], input[(i*2)+1]; } foo is the reducing function and is expected to return the reduction of two elements of the sequence being reduced. kernel would be called with e.g. input=Object[2n], output=Object[n], i=n. The idea is to go through a number of reduction steps, each one taking an input of size 2x and producing an output of size x, which can then be fed back into the same kernel as input for the following round. Odds and ends can be picked up by the cpu and folded in at a suitable juncture - repeat until output array is too small to reduce further on the gpu and so finish up the reduction on the cpu.... Questions: - does this sound sensible ? - I've read about Kaveri h/w supporting heterogeneous (including gpu->gpu) queueing. Is this available, or are there plans to surface it, in clumatra/graal/okra ? I need this to sequence the steps of my reduction efficiently. - anything else that anyone feels is relevant :-) looking forward to hearing from you, Jules From doug.simon at oracle.com Wed Jun 18 01:00:05 2014 From: doug.simon at oracle.com (doug.simon at oracle.com) Date: Wed, 18 Jun 2014 01:00:05 +0000 Subject: hg: graal/graal: 7 new changesets Message-ID: <201406180100.s5I10G9D016795@aojmv0008> Changeset: 5fa2e2f73fa6 Author: Bernhard Urban Date: 2014-06-17 17:46 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/5fa2e2f73fa6 UnsafeLoad: insert uncompress operation also for null constant ! graal/com.oracle.graal.replacements/src/com/oracle/graal/replacements/DefaultJavaLoweringProvider.java Changeset: 4a9d5d60fa58 Author: Tom Rodriguez Date: 2014-06-17 12:47 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/4a9d5d60fa58 handle primitive classes with +ImmutableCode ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/phases/LoadJavaMirrorWithKlassPhase.java Changeset: cc76575f485c Author: Tom Rodriguez Date: 2014-06-17 12:47 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/cc76575f485c handle error case in Array.newInstance ! graal/com.oracle.graal.replacements/src/com/oracle/graal/replacements/ArraySubstitutions.java Changeset: dbd32c5942e8 Author: Tom Rodriguez Date: 2014-06-17 12:48 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/dbd32c5942e8 complain when deleting side effecting nodes from snippets ! graal/com.oracle.graal.replacements/src/com/oracle/graal/replacements/ReplacementsImpl.java Changeset: 7c9cf1697845 Author: Tom Rodriguez Date: 2014-06-17 12:50 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/7c9cf1697845 fold getClassLoader for constant classes + graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/nodes/ClassGetClassLoader0Node.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/ClassSubstitutions.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/ObjectGetClassNode.java Changeset: 66e3fc56e85f Author: Tom Rodriguez Date: 2014-06-17 13:24 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/66e3fc56e85f support adding pid to LogFile name ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/HotSpotGraalRuntime.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/PrintStreamOption.java Changeset: 9410f831fefa Author: Tom Rodriguez Date: 2014-06-17 13:24 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/9410f831fefa don't create profiles for exact types ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/TypeProfileProxyNode.java From tom.rodriguez at oracle.com Wed Jun 18 17:44:10 2014 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Wed, 18 Jun 2014 10:44:10 -0700 Subject: code optimized away before a deopt In-Reply-To: References: <363CC5AD-79F9-4DD1-9A97-E7EF64467CD9@oracle.com> Message-ID: <07E19964-E227-49C2-AAF5-2A6606185683@oracle.com> I just pushed a simple assert which should complain when a side effecting node is deleted from a snippet. http://hg.openjdk.java.net/graal/graal/rev/dbd32c5942e8 I?d be curious if this properly detects the cases that were happening with HSAIL. tom On Jun 1, 2014, at 4:06 AM, Gilles Duboscq wrote: > I think this assert is a good idea. > In general I don't think you should use deopt in the same way for > snippets used in lowering in the FLOATING_GUARDS stage and in lowering > during later stages. > At the early stages (FLOATING_GUARDS), the deoptimize node intrinsics > should be used to express guards (which is what the assertion checks) > and at later stages it's simply a deoptimize node and thus some extra > logic can be applied before deoptimization. > Maybe we could use two different intrinsics for these two different usages? > - deoptimize(); > - Guard g = guard(condition); > > > -Gilles > > On Fri, May 30, 2014 at 10:20 PM, Tom Rodriguez > wrote: >> >> On May 28, 2014, at 1:47 PM, Deneau, Tom wrote: >> >>> Dredging up this issue again, I still get burned by it occasionally in our snippets. >>> The only workaround I have is to insert some test before the actual deopt >>> and the test has to be something that the compiler can't optimize away. >>> If I forget such a test, (or if the compiler optimizes it away), the fact >>> that the side-effecting got discarded can cause situations that are difficult >>> to debug. >>> >>> Just wondering if anything has happened since Novemeber to make this less error-prone. >>> I agree with Doug a warning should be the minimum feedback. >> >> I have some changes that assert when a side effecting node is eliminated by ConvertDeoptimizeToGuardPhase during snippet preparation but I have to make some other changes because it?s unhappy about some assertion logic in one of the snippets. We can see if this assert makes sense in practice. I guess I was surprised that there weren?t more complaints from existing code but I haven?t run it through the gate yet so maybe there are more. I?ll push it once I get the assertion issue fixed. >> >> This doesn?t really solve your problem though since it will now complain when something gets eliminated but you still have no way to keep it from being eliminated. Maybe you could handle it by doing some late lowering to expand the problematic control flow during LOW_TIER lowering? >> >> tom >> >>> >>> Or could we have some annotation or something that says in this snippet do not >>> do the ConvertDeoptimizeToGuardPhase? >>> >>> -- Tom >>> >>> >>> >>>>> -----Original Message----- >>>>> From: Doug Simon [mailto:doug.simon at oracle.com] >>>>> Sent: Saturday, November 23, 2013 10:24 AM >>>>> To: Lukas Stadler >>>>> Cc: Deneau, Tom; graal-dev at openjdk.java.net >>>>> Subject: Re: code optimized away before a deopt >>>>> >>>>> >>>>> On Nov 23, 2013, at 5:18 PM, Lukas Stadler wrote: >>>>> >>>>>> But it _is_ ok to remove side effecting nodes, because we know they >>>>> will be reelected. >>>>> >>>>> Yes, normally, but when you write this pattern in a snippet, then >>>>> this won't be true right, since we don't resume execution in the >>>>> bytecode of the snippet (yet!). That why I was thinking at least a >>>>> warning would be a good idea. >>>>> >>>>> -Doug >>>>> >>>>>> Maybe the cleanup operations could be part of a special purpose >>>>>> deopt >>>>> node? >>>>>> >>>>>> - Lukas >>>>>> >>>>>> Von meinem iPhone gesendet >>>>>> >>>>>>> Am 23.11.2013 um 16:39 schrieb Doug Simon : >>>>>>> >>>>>>> This is done by the ConvertDeoptimizeToGuardPhase which replaces >>>>> conditionals where one branch ends in a deopt with a GuardNode. This >>>>> does indeed have the side effect of (silently) deleting all other >>>>> nodes on that deopt-terminated branch. We should add some code to >>>>> either make the deletion not silent or better, throw an error if >>>>> these are any side- effecting nodes that will be deleted. >>>>>>> >>>>>>> -Doug >>>>>>> >>>>>>>> On Nov 23, 2013, at 1:58 AM, Deneau, Tom wrote: >>>>>>>> >>>>>>>> I've noticed that if I have a snippet that does a test and if the >>>>> test fails, branches to a block that does some cleanup operations and >>>>> then calls DeoptimizeNode.deopt(xxx, yyy), the cleanup code gets >>>>> "optimized away". I guess this is related to what Gilles was talking >>>>> about, maybe the cleanup operations were considered not state changing? >>>>>>>> >>>>>>>> In our current state of HSAIL backend, a deopt just returns early >>>>> from the kernel. Is there something I can do to make the cleanup code >>>>> get emitted before the deopt? >>>>>>>> >>>>>>>> -- Tom >>>>>>> >>>>> >>>> >>>> >>> >>> >> From doug.simon at oracle.com Thu Jun 19 01:00:07 2014 From: doug.simon at oracle.com (doug.simon at oracle.com) Date: Thu, 19 Jun 2014 01:00:07 +0000 Subject: hg: graal/graal: 14 new changesets Message-ID: <201406190100.s5J10SVX021237@aojmv0008> Changeset: 6f7d3f3703d3 Author: Michael Van De Vanter Date: 2014-06-16 20:52 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/6f7d3f3703d3 Truffle/Source: - LineLocation and LineBreakpoint no longer implement Comparable - TextMap now internal to the Source factory + graal/com.oracle.truffle.api.test/src/com/oracle/truffle/api/test/utilities/SourceTextTest.java - graal/com.oracle.truffle.api.test/src/com/oracle/truffle/api/test/utilities/TextMapTest.java ! graal/com.oracle.truffle.api/src/com/oracle/truffle/api/source/LineLocation.java ! graal/com.oracle.truffle.api/src/com/oracle/truffle/api/source/Source.java - graal/com.oracle.truffle.api/src/com/oracle/truffle/api/source/TextMap.java Changeset: a4a2147a6aa6 Author: Michael Van De Vanter Date: 2014-06-17 17:42 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/a4a2147a6aa6 Merge with 9410f831fefa2a7af1865d65b32bf6019f197bd8 Changeset: 7143d614bb20 Author: Christian Wirth Date: 2014-06-18 10:39 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/7143d614bb20 Add missing include precompiled.hpp to fix windows build ! src/gpu/hsail/vm/hsailKernelArguments.cpp Changeset: d568574e6448 Author: Doug Simon Date: 2014-06-18 11:28 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/d568574e6448 reduce allocations of NodeIterables by Graph.getNewNodes() ! graal/com.oracle.graal.graph/src/com/oracle/graal/graph/Graph.java + graal/com.oracle.graal.graph/src/com/oracle/graal/graph/iterators/EmptyNodeIterable.java Changeset: 17af09bd9e75 Author: Lukas Stadler Date: 2014-06-18 11:57 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/17af09bd9e75 infer stamps for IntegerMulHighNode ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/nodes/arithmetic/IntegerMulHighNode.java Changeset: f3330ba9974c Author: Doug Simon Date: 2014-06-18 14:46 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/f3330ba9974c remove barrier to escape analysis introduced by d568574e6448 ! graal/com.oracle.graal.graph/src/com/oracle/graal/graph/Graph.java - graal/com.oracle.graal.graph/src/com/oracle/graal/graph/iterators/EmptyNodeIterable.java ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/CanonicalizerPhase.java Changeset: d32be0297274 Author: Doug Simon Date: 2014-06-18 16:48 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/d32be0297274 support -XX:+BootstrapGraal in conjunction with -XX:-UseGraalCompilationQueue ! src/share/vm/graal/graalCompiler.cpp ! src/share/vm/graal/graalCompiler.hpp ! src/share/vm/prims/jni.cpp Changeset: 0eb8270ae69d Author: Josef Eisl Date: 2014-06-04 14:52 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/0eb8270ae69d Add assertions to AbstractBlock.{dominated,isDominatedBy}(). ! graal/com.oracle.graal.compiler.common/src/com/oracle/graal/compiler/common/cfg/AbstractBlock.java Changeset: f315b1c0a590 Author: Josef Eisl Date: 2014-06-18 14:21 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/f315b1c0a590 Introduce InstructionValueProcedure. ! graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/backend/AllocatorTest.java ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/alloc/LinearScan.java ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/alloc/RegisterVerifier.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/HotSpotLIRFrameState.java ! graal/com.oracle.graal.lir/src/com/oracle/graal/lir/CompositeValue.java ! graal/com.oracle.graal.lir/src/com/oracle/graal/lir/CompositeValueClass.java ! graal/com.oracle.graal.lir/src/com/oracle/graal/lir/LIRFrameState.java ! graal/com.oracle.graal.lir/src/com/oracle/graal/lir/LIRInstruction.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/LIRVerifier.java Changeset: b7a1ece4f07b Author: Gilles Duboscq Date: 2014-06-18 19:32 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/b7a1ece4f07b Make sure that there is always a nmethod available for the method handle intrinsics. ! src/share/vm/classfile/systemDictionary.cpp Changeset: 7109baa7b9eb Author: Michael Van De Vanter Date: 2014-06-18 11:05 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/7109baa7b9eb Truffle/Source: SourceSection.toString() is now equivalent to getCode() ! graal/com.oracle.truffle.api/src/com/oracle/truffle/api/source/Source.java Changeset: da21746a64bf Author: Michael Van De Vanter Date: 2014-06-18 11:26 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/da21746a64bf Merge Changeset: a87f6927d73e Author: Doug Simon Date: 2014-06-18 21:58 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/a87f6927d73e added -XX:GraalThreads to mimic -G:Threads when using native compilation queue for Graal ! src/share/vm/compiler/compileBroker.cpp ! src/share/vm/graal/graalGlobals.hpp Changeset: 4f185700f4b7 Author: Doug Simon Date: 2014-06-19 00:45 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/4f185700f4b7 made BootstrapGraal have same semantics under -XX:-UseGraalCompilationQueue as -XX:+UseGraalCompilationQueue (i.e. only enabled if explicitly specified or -XX:-TieredCompilation) ! src/share/vm/prims/jni.cpp From tom.deneau at amd.com Thu Jun 19 22:41:17 2014 From: tom.deneau at amd.com (Deneau, Tom) Date: Thu, 19 Jun 2014 22:41:17 +0000 Subject: readonly arrays Message-ID: Does graal have any concept of marking an array as having constant primitive values? For instance on hsa such an array could be put in readonly memory and compiled into the kernel rather than accessed thru global memory. -- Tom From doug.simon at oracle.com Fri Jun 20 01:00:05 2014 From: doug.simon at oracle.com (doug.simon at oracle.com) Date: Fri, 20 Jun 2014 01:00:05 +0000 Subject: hg: graal/graal: 3 new changesets Message-ID: <201406200100.s5K10AJD018056@aojmv0008> Changeset: af9f3a5f091b Author: Doug Simon Date: 2014-06-19 11:24 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/af9f3a5f091b extended Debug API with DebugVerifyHandlers ! graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/FlowSenReduTest.java ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/GraalDebugConfig.java ! graal/com.oracle.graal.debug/src/com/oracle/graal/debug/Debug.java ! graal/com.oracle.graal.debug/src/com/oracle/graal/debug/DebugConfig.java + graal/com.oracle.graal.debug/src/com/oracle/graal/debug/DebugVerifyHandler.java ! graal/com.oracle.graal.debug/src/com/oracle/graal/debug/DelegatingDebugConfig.java ! graal/com.oracle.graal.debug/src/com/oracle/graal/debug/internal/DebugScope.java ! graal/com.oracle.graal.hotspot.test/src/com/oracle/graal/hotspot/test/WriteBarrierVerificationTest.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/HotSpotGraalRuntime.java ! graal/com.oracle.graal.printer/src/com/oracle/graal/printer/DebugEnvironment.java Changeset: 237508bd73b9 Author: Doug Simon Date: 2014-06-19 23:41 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/237508bd73b9 when Graal bootstrap is enabled (explicitly or implicitly), allocate same number of Graal compiler threads in -UseGraalCompilationQueue as in +UseGraalCompilationQueue ! src/share/vm/compiler/compileBroker.cpp Changeset: 9b27e69f7cec Author: Doug Simon Date: 2014-06-19 23:42 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/9b27e69f7cec added -XX:+PrintBootstrap option to mirror -G:+PrintBoostrap option ! src/share/vm/graal/graalCompiler.cpp ! src/share/vm/graal/graalGlobals.hpp From tom.deneau at amd.com Fri Jun 20 03:54:06 2014 From: tom.deneau at amd.com (Deneau, Tom) Date: Fri, 20 Jun 2014 03:54:06 +0000 Subject: -XX:AbortVMOnException=java.lang.NullPointerException Message-ID: I wanted to use the option -XX:AbortVMOnException=java.lang.NullPointerException to try to solve a different problem but I noticed when I use it, I always get this NullPointerException from LinearScanWalker showing up. Is this expected? (This was with the fastdebug build). -- Tom Stack: [0x00002b123e9d5000,0x00002b123ead6000], sp=0x00002b123ead1b80, free space=1010k Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) V [libjvm.so+0x1006d88] VMError::report_and_die()+0x168 V [libjvm.so+0x6ececf] report_fatal(char const*, int, char const*)+0x6f V [libjvm.so+0x7a6ed1] Exceptions::debug_check_abort(char const*, char const*)+0x91 V [libjvm.so+0xe8ef70] SharedRuntime::continuation_for_implicit_exception(JavaThread*, unsigned char*, SharedRuntime::ImplicitExceptionKind)+0x1a0 V [libjvm.so+0xd766a1] JVM_handle_linux_signal+0x5d1 V [libjvm.so+0xd64832] signalHandler(int, siginfo_t*, void*)+0x42 C [libc.so.6+0x36ff0] killpg+0x40 j com.oracle.graal.compiler.alloc.LinearScanWalker.activateCurrent(Lcom/oracle/graal/compiler/alloc/Interval;)Z+92 j com.oracle.graal.compiler.alloc.IntervalWalker.walkTo(I)V+88 j com.oracle.graal.compiler.alloc.OptimizingLinearScanWalker.walk()V+191 j com.oracle.graal.compiler.alloc.LinearScan.allocateRegisters()V+80 j com.oracle.graal.compiler.alloc.LinearScan.allocate()V+163 j com.oracle.graal.compiler.GraalCompiler.emitLIR(Lcom/oracle/graal/compiler/target/Backend;Lcom/oracle/graal/api/code/TargetDescription;Lcom/oracle/graal/phases/schedule/SchedulePhase;Lcom/oracle/graal/nodes/StructuredGraph;Ljava/lang/Object;Lcom/oracle/graal/api/code/CallingConvention;Lcom/oracle/graal/api/code/RegisterConfig;)Lcom/oracle/graal/lir/gen/LIRGenerationResult;+618 j com.oracle.graal.compiler.GraalCompiler.emitBackEnd(Lcom/oracle/graal/nodes/StructuredGraph;Ljava/lang/Object;Lcom/oracle/graal/api/code/CallingConvention;Lcom/oracle/graal/api/meta/ResolvedJavaMethod;Lcom/oracle/graal/compiler/target/Backend;Lcom/oracle/graal/api/code/TargetDescription;Lcom/oracle/graal/api/code/CompilationResult;Lcom/oracle/graal/lir/asm/CompilationResultBuilderFactory;Lcom/oracle/graal/api/code/Assumptions;Lcom/oracle/graal/phases/schedule/SchedulePhase;Lcom/oracle/graal/api/code/RegisterConfig;)V+27 j com.oracle.graal.compiler.GraalCompiler.compileGraph(Lcom/oracle/graal/nodes/StructuredGraph;Ljava/lang/Object;Lcom/oracle/graal/api/code/CallingConvention;Lcom/oracle/graal/api/meta/ResolvedJavaMethod;Lcom/oracle/graal/phases/util/Providers;Lcom/oracle/graal/compiler/target/Backend;Lcom/oracle/graal/api/code/TargetDescription;Ljava/util/Map;Lcom/oracle/graal/phases/PhaseSuite;Lcom/oracle/graal/phases/OptimisticOptimizations;Lcom/oracle/graal/api/meta/ProfilingInfo;Lcom/oracle/graal/api/code/SpeculationLog;Lcom/oracle/graal/phases/tiers/Suites;Lcom/oracle/graal/api/code/CompilationResult;Lcom/oracle/graal/lir/asm/CompilationResultBuilderFactory;)Lcom/oracle/graal/api/code/CompilationResult;+99 j com.oracle.graal.hotspot.hsail.HSAILHotSpotBackend.compileKernel(Lcom/oracle/graal/api/meta/ResolvedJavaMethod;Z)Lcom/oracle/graal/gpu/ExternalCompilationResult;+161 From duboscq at ssw.jku.at Fri Jun 20 08:03:32 2014 From: duboscq at ssw.jku.at (Gilles Duboscq) Date: Fri, 20 Jun 2014 10:03:32 +0200 Subject: -XX:AbortVMOnException=java.lang.NullPointerException In-Reply-To: References: Message-ID: I think in the Graal context, when we use implicit exceptions, we assume that the exception behaviour is fully handled in the interpreter. I'll disable the Exceptions::debug_check_abort check in the "deopt on implicit exception" case. That's interesting because it means that C2 never uses an implicit null check speculatively? -Gilles On Fri, Jun 20, 2014 at 5:54 AM, Tom Deneau wrote: > I wanted to use the option -XX:AbortVMOnException=java.lang.NullPointerException to try to solve a different problem but I noticed when I use it, I always get this NullPointerException from LinearScanWalker showing up. Is this expected? > > (This was with the fastdebug build). > > -- Tom > > Stack: [0x00002b123e9d5000,0x00002b123ead6000], sp=0x00002b123ead1b80, free space=1010k > Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) > V [libjvm.so+0x1006d88] VMError::report_and_die()+0x168 > V [libjvm.so+0x6ececf] report_fatal(char const*, int, char const*)+0x6f > V [libjvm.so+0x7a6ed1] Exceptions::debug_check_abort(char const*, char const*)+0x91 > V [libjvm.so+0xe8ef70] SharedRuntime::continuation_for_implicit_exception(JavaThread*, unsigned char*, SharedRuntime::ImplicitExceptionKind)+0x1a0 > V [libjvm.so+0xd766a1] JVM_handle_linux_signal+0x5d1 > V [libjvm.so+0xd64832] signalHandler(int, siginfo_t*, void*)+0x42 > C [libc.so.6+0x36ff0] killpg+0x40 > j com.oracle.graal.compiler.alloc.LinearScanWalker.activateCurrent(Lcom/oracle/graal/compiler/alloc/Interval;)Z+92 > j com.oracle.graal.compiler.alloc.IntervalWalker.walkTo(I)V+88 > j com.oracle.graal.compiler.alloc.OptimizingLinearScanWalker.walk()V+191 > j com.oracle.graal.compiler.alloc.LinearScan.allocateRegisters()V+80 > j com.oracle.graal.compiler.alloc.LinearScan.allocate()V+163 > j com.oracle.graal.compiler.GraalCompiler.emitLIR(Lcom/oracle/graal/compiler/target/Backend;Lcom/oracle/graal/api/code/TargetDescription;Lcom/oracle/graal/phases/schedule/SchedulePhase;Lcom/oracle/graal/nodes/StructuredGraph;Ljava/lang/Object;Lcom/oracle/graal/api/code/CallingConvention;Lcom/oracle/graal/api/code/RegisterConfig;)Lcom/oracle/graal/lir/gen/LIRGenerationResult;+618 > j com.oracle.graal.compiler.GraalCompiler.emitBackEnd(Lcom/oracle/graal/nodes/StructuredGraph;Ljava/lang/Object;Lcom/oracle/graal/api/code/CallingConvention;Lcom/oracle/graal/api/meta/ResolvedJavaMethod;Lcom/oracle/graal/compiler/target/Backend;Lcom/oracle/graal/api/code/TargetDescription;Lcom/oracle/graal/api/code/CompilationResult;Lcom/oracle/graal/lir/asm/CompilationResultBuilderFactory;Lcom/oracle/graal/api/code/Assumptions;Lcom/oracle/graal/phases/schedule/SchedulePhase;Lcom/oracle/graal/api/code/RegisterConfig;)V+27 > j com.oracle.graal.compiler.GraalCompiler.compileGraph(Lcom/oracle/graal/nodes/StructuredGraph;Ljava/lang/Object;Lcom/oracle/graal/api/code/CallingConvention;Lcom/oracle/graal/api/meta/ResolvedJavaMethod;Lcom/oracle/graal/phases/util/Providers;Lcom/oracle/graal/compiler/target/Backend;Lcom/oracle/graal/api/code/TargetDescription;Ljava/util/Map;Lcom/oracle/graal/phases/PhaseSuite;Lcom/oracle/graal/phases/OptimisticOptimizations;Lcom/oracle/graal/api/meta/ProfilingInfo;Lcom/oracle/graal/api/code/SpeculationLog;Lcom/oracle/graal/phases/tiers/Suites;Lcom/oracle/graal/api/code/CompilationResult;Lcom/oracle/graal/lir/asm/CompilationResultBuilderFactory;)Lcom/oracle/graal/api/code/CompilationResult;+99 > j com.oracle.graal.hotspot.hsail.HSAILHotSpotBackend.compileKernel(Lcom/oracle/graal/api/meta/ResolvedJavaMethod;Z)Lcom/oracle/graal/gpu/ExternalCompilationResult;+161 From duboscq at ssw.jku.at Fri Jun 20 08:16:37 2014 From: duboscq at ssw.jku.at (Gilles Duboscq) Date: Fri, 20 Jun 2014 10:16:37 +0200 Subject: readonly arrays In-Reply-To: References: Message-ID: tl;dr: not yet. The concept of "array with final content" is unfortunately impossible to express in vanilla Java. However both HotSpot and Graal have support for those to some degree. For example, HotSpot knows about the java.lang.invoke.Stable annotation. In Truffle the com.oracle.truffle.api.CompilerDirectives.CompilationFinal annotation has similar effects. In Graal we also have the com.oracle.graal.hotspot.Stable annotation. There's been a few prototypes for good support of this concepts in Graal but it's not so well supported currently. The problem is that all of the annotation based workaround mentioned above all work at the field level while this information should really be in the type. I think we will need it anyway at some point. First because it would probably allow us to unify the 3 different concepts from above. And secondly because it may become important to be able to run LambdaForms with good performances. -Gilles On Fri, Jun 20, 2014 at 12:41 AM, Tom Deneau wrote: > Does graal have any concept of marking an array as having constant primitive values? > For instance on hsa such an array could be put in readonly memory and compiled into the kernel rather than accessed thru global memory. > > -- Tom From tom.rodriguez at oracle.com Fri Jun 20 17:36:28 2014 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Fri, 20 Jun 2014 10:36:28 -0700 Subject: readonly arrays In-Reply-To: References: Message-ID: > > There's been a few prototypes for good support of this concepts in > Graal but it's not so well supported currently. > The problem is that all of the annotation based workaround mentioned > above all work at the field level while this information should really > be in the type. > > I think we will need it anyway at some point. First because it would > probably allow us to unify the 3 different concepts from above. And > secondly because it may become important to be able to run LambdaForms > with good performances. I was kicking around the idea of adding support for stable array contents to Constant so that loads from the char[] of constant Strings can be constant folded. I was just going to special case Strings but a more general tagging strategy wouldn?t be hard to add. tom > > -Gilles > > On Fri, Jun 20, 2014 at 12:41 AM, Tom Deneau wrote: >> Does graal have any concept of marking an array as having constant primitive values? >> For instance on hsa such an array could be put in readonly memory and compiled into the kernel rather than accessed thru global memory. >> >> -- Tom From tom.rodriguez at oracle.com Fri Jun 20 17:39:24 2014 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Fri, 20 Jun 2014 10:39:24 -0700 Subject: -XX:AbortVMOnException=java.lang.NullPointerException In-Reply-To: References: Message-ID: C2 has some gating logic for transforming explicit null tests into implicit null checks but it will certainly do this. If it happens too often it will recompile the method which should revert to explicit checks. I suspect if you ran the right program it would fail in the same way for C2. implicit_null_check(block, proj, val, allowed_reasons); // The implicit_null_check will only perform the transformation // if the null branch is truly uncommon, *and* it leads to an // uncommon trap. Combined with the too_many_traps guards // above, this prevents SEGV storms reported in 6366351, // by recompiling offending methods without this optimization. There was a bug where a user written null test was converted into an implicit test and never converted back to an explicit test. null became a common value so every test resulted into signal trapping and deopt which was horrifically slow. It doesn?t seem like the debug_check_abort code call should be there in the first place since it?s not the actual throw point. It may be there to deal with the fast throw machinery in C2 since it doesn?t actually create a new exception at the throw point. That may no longer be an issue though since there?s now some gating machinery on that. It used to be that it would immediately begin using preallocated exceptions. Anyway, for graal we could just return target_pc instead of setting it and falling through. Most of the other cases directly return anyway. tom On Jun 20, 2014, at 1:03 AM, Gilles Duboscq wrote: > I think in the Graal context, when we use implicit exceptions, we > assume that the exception behaviour is fully handled in the > interpreter. > I'll disable the Exceptions::debug_check_abort check in the "deopt on > implicit exception" case. > > That's interesting because it means that C2 never uses an implicit > null check speculatively? > > -Gilles > > On Fri, Jun 20, 2014 at 5:54 AM, Tom Deneau wrote: >> I wanted to use the option -XX:AbortVMOnException=java.lang.NullPointerException to try to solve a different problem but I noticed when I use it, I always get this NullPointerException from LinearScanWalker showing up. Is this expected? >> >> (This was with the fastdebug build). >> >> -- Tom >> >> Stack: [0x00002b123e9d5000,0x00002b123ead6000], sp=0x00002b123ead1b80, free space=1010k >> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) >> V [libjvm.so+0x1006d88] VMError::report_and_die()+0x168 >> V [libjvm.so+0x6ececf] report_fatal(char const*, int, char const*)+0x6f >> V [libjvm.so+0x7a6ed1] Exceptions::debug_check_abort(char const*, char const*)+0x91 >> V [libjvm.so+0xe8ef70] SharedRuntime::continuation_for_implicit_exception(JavaThread*, unsigned char*, SharedRuntime::ImplicitExceptionKind)+0x1a0 >> V [libjvm.so+0xd766a1] JVM_handle_linux_signal+0x5d1 >> V [libjvm.so+0xd64832] signalHandler(int, siginfo_t*, void*)+0x42 >> C [libc.so.6+0x36ff0] killpg+0x40 >> j com.oracle.graal.compiler.alloc.LinearScanWalker.activateCurrent(Lcom/oracle/graal/compiler/alloc/Interval;)Z+92 >> j com.oracle.graal.compiler.alloc.IntervalWalker.walkTo(I)V+88 >> j com.oracle.graal.compiler.alloc.OptimizingLinearScanWalker.walk()V+191 >> j com.oracle.graal.compiler.alloc.LinearScan.allocateRegisters()V+80 >> j com.oracle.graal.compiler.alloc.LinearScan.allocate()V+163 >> j com.oracle.graal.compiler.GraalCompiler.emitLIR(Lcom/oracle/graal/compiler/target/Backend;Lcom/oracle/graal/api/code/TargetDescription;Lcom/oracle/graal/phases/schedule/SchedulePhase;Lcom/oracle/graal/nodes/StructuredGraph;Ljava/lang/Object;Lcom/oracle/graal/api/code/CallingConvention;Lcom/oracle/graal/api/code/RegisterConfig;)Lcom/oracle/graal/lir/gen/LIRGenerationResult;+618 >> j com.oracle.graal.compiler.GraalCompiler.emitBackEnd(Lcom/oracle/graal/nodes/StructuredGraph;Ljava/lang/Object;Lcom/oracle/graal/api/code/CallingConvention;Lcom/oracle/graal/api/meta/ResolvedJavaMethod;Lcom/oracle/graal/compiler/target/Backend;Lcom/oracle/graal/api/code/TargetDescription;Lcom/oracle/graal/api/code/CompilationResult;Lcom/oracle/graal/lir/asm/CompilationResultBuilderFactory;Lcom/oracle/graal/api/code/Assumptions;Lcom/oracle/graal/phases/schedule/SchedulePhase;Lcom/oracle/graal/api/code/RegisterConfig;)V+27 >> j com.oracle.graal.compiler.GraalCompiler.compileGraph(Lcom/oracle/graal/nodes/StructuredGraph;Ljava/lang/Object;Lcom/oracle/graal/api/code/CallingConvention;Lcom/oracle/graal/api/meta/ResolvedJavaMethod;Lcom/oracle/graal/phases/util/Providers;Lcom/oracle/graal/compiler/target/Backend;Lcom/oracle/graal/api/code/TargetDescription;Ljava/util/Map;Lcom/oracle/graal/phases/PhaseSuite;Lcom/oracle/graal/phases/OptimisticOptimizations;Lcom/oracle/graal/api/meta/ProfilingInfo;Lcom/oracle/graal/api/code/SpeculationLog;Lcom/oracle/graal/phases/tiers/Suites;Lcom/oracle/graal/api/code/CompilationResult;Lcom/oracle/graal/lir/asm/CompilationResultBuilderFactory;)Lcom/oracle/graal/api/code/CompilationResult;+99 >> j com.oracle.graal.hotspot.hsail.HSAILHotSpotBackend.compileKernel(Lcom/oracle/graal/api/meta/ResolvedJavaMethod;Z)Lcom/oracle/graal/gpu/ExternalCompilationResult;+161 From christian.thalinger at oracle.com Fri Jun 20 20:50:59 2014 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Fri, 20 Jun 2014 13:50:59 -0700 Subject: update tests webrev for -XX:-UseHSAILDeoptimization In-Reply-To: References: Message-ID: <1504165E-991B-4F62-89B6-9C6605645D29@oracle.com> + return (canHandleObjectAllocation()); Remove the useless parentheses. On Jun 17, 2014, at 5:49 AM, Caspole, Eric wrote: > Hi everybody, > Here is a small change so the tests run clean with -XX:-UseHSAILDeoptimization > > http://cr.openjdk.java.net/~ecaspole/test_no_deopt_fix/webrev/ > > Thanks, > Eric > From doug.simon at oracle.com Sat Jun 21 01:00:06 2014 From: doug.simon at oracle.com (doug.simon at oracle.com) Date: Sat, 21 Jun 2014 01:00:06 +0000 Subject: hg: graal/graal: 7 new changesets Message-ID: <201406210100.s5L10GVg019595@aojmv0008> Changeset: f75c23a505e1 Author: Miguel Garcia Date: 2014-06-13 19:12 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/f75c23a505e1 [inliner] moved determineNodeCount() to InlineInfo ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/inlining/info/AbstractInlineInfo.java ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/inlining/info/InlineInfo.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 Changeset: 3bffcfbf23f5 Author: Miguel Garcia Date: 2014-06-13 19:24 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/3bffcfbf23f5 [inliner] moved buildCallsiteHolderForElement() to MethodInvocation ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/inlining/info/AbstractInlineInfo.java ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/inlining/info/InlineInfo.java ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/inlining/walker/InliningData.java ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/inlining/walker/MethodInvocation.java Changeset: c64c5f5913fd Author: Miguel Garcia Date: 2014-06-14 17:10 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/c64c5f5913fd [inliner] shorter argument list isWorthInlining() ! 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: f98b033b6050 Author: Miguel Garcia Date: 2014-06-18 14:12 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/f98b033b6050 [inliner] propagating fresh-instantiation info through call-hierarchy ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/inlining/info/elem/Inlineable.java ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/inlining/walker/CallsiteHolderExplorable.java ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/inlining/walker/InliningData.java ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/inlining/walker/MethodInvocation.java Changeset: 76895499bc88 Author: Christian Wirth Date: 2014-06-20 15:13 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/76895499bc88 Add facility to create JSON dump of AST creation/rewriting ! graal/com.oracle.truffle.api/src/com/oracle/truffle/api/TruffleOptions.java ! graal/com.oracle.truffle.api/src/com/oracle/truffle/api/nodes/Node.java + graal/com.oracle.truffle.api/src/com/oracle/truffle/api/utilities/JSONHelper.java Changeset: da0847068801 Author: Christian Wirth Date: 2014-06-20 15:21 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/da0847068801 fix line endings, add description and language to node info ! graal/com.oracle.truffle.api/src/com/oracle/truffle/api/utilities/JSONHelper.java Changeset: e8eeee2176ff Author: Christian Wirth Date: 2014-06-20 15:25 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/e8eeee2176ff fix JSON output format ! graal/com.oracle.truffle.api/src/com/oracle/truffle/api/utilities/JSONHelper.java From jules_gosnell at yahoo.com Sat Jun 21 07:56:27 2014 From: jules_gosnell at yahoo.com (Jules Gosnell) Date: Sat, 21 Jun 2014 08:56:27 +0100 Subject: okra-with-sim: Could not initialize class com.amd.okra.OkraContext Message-ID: <53A53AAB.7050306@yahoo.com> Guys, Between 17th/18th June, it looks like something changed which has broken the initialisation of the okra-with-sim build of my project Clumatra. I went to investigate and found that the okra-with-sim jar does not contain OkraContext - it is only in the okra jar. I am sure that my build only had the sim jar on its classpath... so I guess I must have been finding it in JDK/jre/lib/graal.jar I am using http://cr.openjdk.java.net/~tdeneau/okra-1.9-with-sim.jar I've tried rolling back to 1.8, but that seems to make any difference - besides it would no longer match with the okra version inside my jdk, I've had a look at the history of graal/mx/projects to see if e.g. the okra version changed on this date - but no dice. Nothing seems to have changed at https://github.com/HSAFoundation/Okra-Interface-to-HSAIL-Simulator or https://github.com/HSAFoundation/Okra-Interface-to-HSA-Device If I have time this evening I will sit down and try debugging it - I think something is going wrong in the loading/initialisation of the simulator's native lib. Maybe I could try rolling back the date on a jdk/graal src tree and see if that fixes it... Any hints as to what might have changed would be much appreciated. Jules From jules_gosnell at yahoo.com Sat Jun 21 09:11:19 2014 From: jules_gosnell at yahoo.com (Jules Gosnell) Date: Sat, 21 Jun 2014 10:11:19 +0100 Subject: reduction / graal / kaveri / heterogeneous queueing ? In-Reply-To: References: <53A0A86F.2040309@yahoo.com> Message-ID: <53A54C37.5080208@yahoo.com> Thanks for your reply, Eric :-) I've been thinking some more about this - any time requeueing work is still time, so I want do do as little queueing as possible... So, I am now thinking in terms of a stage 1 algorithm which will do whatever necessary to reduce its input of n elements to an array of e.g. 512 elements on the gpu. stage 2 would be to take these as input and reduce them to a single value on the cpu. The number of outputs from stage 1 is necessarily a little higher than I would like because it reflects the levels of parallelism that I am hoping for in my kaveri gpu ! I could insert another intermediate gpu stage to take the 512 down to e.g. 64 on a single compute unit... What do you think ? Jules On 17/06/14 22:32, Caspole, Eric wrote: > Hi Jules, > I have been experimenting with IntStream reduces for a while now and mine works the same way, passing in the output array as you show here.The first version I have is based on this algorithm in the BOLT library - https://github.com/HSA-Libraries/Bolt/blob/master/include/bolt/cl/reduce_kernels.cl > > The HSA runtime spec is not finalized yet. When it is we will have a better idea on the possibility of using the dynamic job queuing in Sumatra. > Regards, > Eric > > ________________________________________ > From: graal-dev [graal-dev-bounces at openjdk.java.net] on behalf of Jules Gosnell [jules_gosnell at yahoo.com] > Sent: Tuesday, June 17, 2014 4:43 PM > To: graal-dev at openjdk.java.net > Subject: reduction / graal / kaveri / heterogeneous queueing ? > > Guys, > > I have been playing with a system of gpu based reduction that is > intended to work as follows: > > e.g. > > public void kernel(Object[] input, Object[] output, int i) { > > output[i] = foo(input[i*2], input[(i*2)+1]; > > } > > foo is the reducing function and is expected to return the reduction of > two elements of the sequence being reduced. > > kernel would be called with e.g. > > input=Object[2n], output=Object[n], i=n. > > > The idea is to go through a number of reduction steps, each one taking > an input of size 2x and producing an output of size x, which can then be > fed back into the same kernel as input for the following round. Odds and > ends can be picked up by the cpu and folded in at a suitable juncture - > repeat until output array is too small to reduce further on the gpu and > so finish up the reduction on the cpu.... > > Questions: > > - does this sound sensible ? > > - I've read about Kaveri h/w supporting heterogeneous (including > gpu->gpu) queueing. Is this available, or are there plans to surface it, > in clumatra/graal/okra ? I need this to sequence the steps of my > reduction efficiently. > > - anything else that anyone feels is relevant :-) > > looking forward to hearing from you, > > > > Jules > > From tom.deneau at amd.com Sun Jun 22 03:18:17 2014 From: tom.deneau at amd.com (Deneau, Tom) Date: Sun, 22 Jun 2014 03:18:17 +0000 Subject: okra-with-sim: Could not initialize class com.amd.okra.OkraContext In-Reply-To: <53A53AAB.7050306@yahoo.com> References: <53A53AAB.7050306@yahoo.com> Message-ID: Jules -- Yes, OkraContext, OkraKernel, and OkraUtil are put into graal.jar so it is not necessary to have okra.jar on the classpath. okra-1.9 came out on Apr 23 and there have been no changes since then. What are the symptoms of your problem? -- Tom -----Original Message----- From: graal-dev [mailto:graal-dev-bounces at openjdk.java.net] On Behalf Of Jules Gosnell Sent: Saturday, June 21, 2014 2:56 AM To: graal-dev at openjdk.java.net Subject: okra-with-sim: Could not initialize class com.amd.okra.OkraContext Guys, Between 17th/18th June, it looks like something changed which has broken the initialisation of the okra-with-sim build of my project Clumatra. I went to investigate and found that the okra-with-sim jar does not contain OkraContext - it is only in the okra jar. I am sure that my build only had the sim jar on its classpath... so I guess I must have been finding it in JDK/jre/lib/graal.jar I am using http://cr.openjdk.java.net/~tdeneau/okra-1.9-with-sim.jar I've tried rolling back to 1.8, but that seems to make any difference - besides it would no longer match with the okra version inside my jdk, I've had a look at the history of graal/mx/projects to see if e.g. the okra version changed on this date - but no dice. Nothing seems to have changed at https://github.com/HSAFoundation/Okra-Interface-to-HSAIL-Simulator or https://github.com/HSAFoundation/Okra-Interface-to-HSA-Device If I have time this evening I will sit down and try debugging it - I think something is going wrong in the loading/initialisation of the simulator's native lib. Maybe I could try rolling back the date on a jdk/graal src tree and see if that fixes it... Any hints as to what might have changed would be much appreciated. Jules From tom.deneau at amd.com Mon Jun 23 18:35:58 2014 From: tom.deneau at amd.com (Deneau, Tom) Date: Mon, 23 Jun 2014 18:35:58 +0000 Subject: webrev to use oops_do to modify saved hsail state Message-ID: Has anyone had a chance to look a this webrev? -- Tom From: Deneau, Tom Sent: Tuesday, June 17, 2014 10:21 AM To: graal-dev at openjdk.java.net Subject: webrev to use oops_do to modify saved hsail state I placed a webrev up at http://cr.openjdk.java.net/~tdeneau/graal-webrevs/webrev-hsail-oops-do/webrev/ Please consider this for inclusion in graal. Background: Ever since we started support deoptimization from hsail kernels, we have had to deal with the fact that any oops saved in the hsail deoptimization save area could move around by GC during the windows that open during deoptimizations to the interpreter. Up until now, we had a hackier (and higher overhead) workaround involving copying oops to and from a java Object array and letting them get fixed up there if necessary. This webrev instead uses the standard process of updating the oops in the saved HSAIL state by calling oops_do from a GC thread. * A field was added to JavaThread so that we could tell that a thread was processing an hsail kernel. If so, we go thru the saved hsail frames and apply the oops_do closure to each oop in each saved frame. * Because the saved HSAILFrames are only used during deoptimization to the interpreter, we only need to process the frames for the deopt items that have not been handled yet. A field was added to HSAILDeoptimizationInfo to keep track of this. * Also, note that we don't need to do anything if we have finished the deopting workitems and are handling the never-ran workitems. (The never-rans have to resolve the argument oops, but they always did that). There used to be a class called OopSaver defined in gpu_hsail.cpp. That has been removed and we no longer pass the save array. Some of the logic from OopSaver is now in OopMapHelper. HSAILFrame was extended with a few new functions to help with oops_do. The disabling of ArrayListSetTest was because of an issue we saw unrelated to this webrev. This issue will be fixed in a later webrev. Note: Running with the hsail simulator, there will be a small number of de-opts so it's not the best test environment for this feature, but tests have passed on HSA hardware boxes which can have thousands of de-opts. -- Tom From jules_gosnell at yahoo.com Mon Jun 23 19:52:07 2014 From: jules_gosnell at yahoo.com (Jules Gosnell) Date: Mon, 23 Jun 2014 20:52:07 +0100 Subject: okra-with-sim: Could not initialize class com.amd.okra.OkraContext In-Reply-To: References: <53A53AAB.7050306@yahoo.com> Message-ID: <53A88567.8020401@yahoo.com> Tom, Thanks for your offer of help - I think the problem must have been environmental on my side somewhere - I rearranged my build process over the weekend and the problem has mysteriously disappeared :-) sorry to mess you about. Jules On 22/06/14 04:18, Deneau, Tom wrote: > Jules -- > > Yes, OkraContext, OkraKernel, and OkraUtil are put into graal.jar so it is not necessary to have okra.jar on the classpath. okra-1.9 came out on Apr 23 and there have been no changes since then. What are the symptoms of your problem? > > -- Tom > > -----Original Message----- > From: graal-dev [mailto:graal-dev-bounces at openjdk.java.net] On Behalf Of Jules Gosnell > Sent: Saturday, June 21, 2014 2:56 AM > To: graal-dev at openjdk.java.net > Subject: okra-with-sim: Could not initialize class com.amd.okra.OkraContext > > Guys, > > Between 17th/18th June, it looks like something changed which has broken the initialisation of the okra-with-sim build of my project Clumatra. > > I went to investigate and found that the okra-with-sim jar does not contain OkraContext - it is only in the okra jar. I am sure that my build only had the sim jar on its classpath... so I guess I must have been finding it in JDK/jre/lib/graal.jar > > I am using http://cr.openjdk.java.net/~tdeneau/okra-1.9-with-sim.jar > > I've tried rolling back to 1.8, but that seems to make any difference - besides it would no longer match with the okra version inside my jdk, > > I've had a look at the history of graal/mx/projects to see if e.g. the okra version changed on this date - but no dice. > > Nothing seems to have changed at > https://github.com/HSAFoundation/Okra-Interface-to-HSAIL-Simulator or https://github.com/HSAFoundation/Okra-Interface-to-HSA-Device > > If I have time this evening I will sit down and try debugging it - I think something is going wrong in the loading/initialisation of the simulator's native lib. > > Maybe I could try rolling back the date on a jdk/graal src tree and see if that fixes it... > > Any hints as to what might have changed would be much appreciated. > > > Jules > From tom.deneau at amd.com Mon Jun 23 20:33:46 2014 From: tom.deneau at amd.com (Deneau, Tom) Date: Mon, 23 Jun 2014 20:33:46 +0000 Subject: logic in Math.nextAfter for handling -0.0 input Message-ID: The JDK method Math.nextAfter contains the logic shown below to handle an input of -0.0 When the graal compiler compiles this for the hsail backend, it makes the reasonable assumption that "start + 0.0d" can be reduced to "start" which is a problem for this algorithm. >From what I could tell, c2 or graal for amd64 backend do not do this optimization and so get the right answer for -0.0 input. How do they know not to do this optimization? } else { // start > direction or start < direction // Add +0.0 to get rid of a -0.0 (+0.0 + -0.0 => +0.0) // then bitwise convert start to integer. long transducer = Double.doubleToRawLongBits(start + 0.0d); <============== if (direction > start) { // Calculate next greater value transducer = transducer + (transducer >= 0L ? 1L:-1L); } else { // Calculate next lesser value .... -- Tom From tom.deneau at amd.com Mon Jun 23 20:42:53 2014 From: tom.deneau at amd.com (Deneau, Tom) Date: Mon, 23 Jun 2014 20:42:53 +0000 Subject: logic in Math.nextAfter for handling -0.0 input Message-ID: Related to this... Should I be able to work around this with the following hsail MethodSubstitution? When I try this, I get a StackOverflowError... -- Tom @ClassSubstitution(java.lang.Math.class) public class HSAILMathSubstitutions { ... @MethodSubstitution public static double nextAfter(double x, double direction) { // work around special case of -0.0 double xx = (x == -0.0 ? 0.0 : x); return Math.nextAfter(xx, direction); } } -----Original Message----- From: Deneau, Tom Sent: Monday, June 23, 2014 3:34 PM To: 'graal-dev at openjdk.java.net' Subject: logic in Math.nextAfter for handling -0.0 input The JDK method Math.nextAfter contains the logic shown below to handle an input of -0.0 When the graal compiler compiles this for the hsail backend, it makes the reasonable assumption that "start + 0.0d" can be reduced to "start" which is a problem for this algorithm. >From what I could tell, c2 or graal for amd64 backend do not do this optimization and so get the right answer for -0.0 input. How do they know not to do this optimization? } else { // start > direction or start < direction // Add +0.0 to get rid of a -0.0 (+0.0 + -0.0 => +0.0) // then bitwise convert start to integer. long transducer = Double.doubleToRawLongBits(start + 0.0d); <============== if (direction > start) { // Calculate next greater value transducer = transducer + (transducer >= 0L ? 1L:-1L); } else { // Calculate next lesser value .... -- Tom From tom.rodriguez at oracle.com Mon Jun 23 21:04:26 2014 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Mon, 23 Jun 2014 14:04:26 -0700 Subject: logic in Math.nextAfter for handling -0.0 input In-Reply-To: References: Message-ID: <7F77F134-9439-40C2-B4A6-B58908B9C1E3@oracle.com> I think graal does this in general so it?s not an HSAIL specific problem. From AddFloatNode.java: @Override public Node canonical(CanonicalizerTool tool) { ? } else if (y().isConstant()) { Constant c = y().asConstant(); if ((c.getKind() == Kind.Float && c.asFloat() == 0.0f) || (c.getKind() == Kind.Double && c.asDouble() == 0.0)) { return x(); } } return this; } FloatSubNode has similar problems. I?ll delete the relevant code. tom On Jun 23, 2014, at 1:33 PM, Deneau, Tom wrote: > The JDK method Math.nextAfter contains the logic shown below to handle an input of -0.0 > > When the graal compiler compiles this for the hsail backend, it makes the reasonable > assumption that "start + 0.0d" can be reduced to "start" which is a problem for this algorithm. > > From what I could tell, c2 or graal for amd64 backend do not do this optimization > and so get the right answer for -0.0 input. How do they know not to do this optimization? > > > } else { // start > direction or start < direction > // Add +0.0 to get rid of a -0.0 (+0.0 + -0.0 => +0.0) > // then bitwise convert start to integer. > long transducer = Double.doubleToRawLongBits(start + 0.0d); <============== > > if (direction > start) { // Calculate next greater value > transducer = transducer + (transducer >= 0L ? 1L:-1L); > } else { // Calculate next lesser value > .... > > -- Tom From tom.deneau at amd.com Mon Jun 23 21:07:03 2014 From: tom.deneau at amd.com (Deneau, Tom) Date: Mon, 23 Jun 2014 21:07:03 +0000 Subject: logic in Math.nextAfter for handling -0.0 input In-Reply-To: <7F77F134-9439-40C2-B4A6-B58908B9C1E3@oracle.com> References: <7F77F134-9439-40C2-B4A6-B58908B9C1E3@oracle.com> Message-ID: Hmm, I tried running with -vm graal and running enough times so Math.nextAfter would get compiled and it was still getting the right answer but maybe I did something wrong. -- Tom From: Tom Rodriguez [mailto:tom.rodriguez at oracle.com] Sent: Monday, June 23, 2014 4:04 PM To: Deneau, Tom Cc: graal-dev at openjdk.java.net Subject: Re: logic in Math.nextAfter for handling -0.0 input I think graal does this in general so it's not an HSAIL specific problem. >From AddFloatNode.java: @Override public Node canonical(CanonicalizerTool tool) { ... } else if (y().isConstant()) { Constant c = y().asConstant(); if ((c.getKind() == Kind.Float && c.asFloat() == 0.0f) || (c.getKind() == Kind.Double && c.asDouble() == 0.0)) { return x(); } } return this; } FloatSubNode has similar problems. I'll delete the relevant code. tom On Jun 23, 2014, at 1:33 PM, Deneau, Tom > wrote: The JDK method Math.nextAfter contains the logic shown below to handle an input of -0.0 When the graal compiler compiles this for the hsail backend, it makes the reasonable assumption that "start + 0.0d" can be reduced to "start" which is a problem for this algorithm. >From what I could tell, c2 or graal for amd64 backend do not do this optimization and so get the right answer for -0.0 input. How do they know not to do this optimization? } else { // start > direction or start < direction // Add +0.0 to get rid of a -0.0 (+0.0 + -0.0 => +0.0) // then bitwise convert start to integer. long transducer = Double.doubleToRawLongBits(start + 0.0d); <============== if (direction > start) { // Calculate next greater value transducer = transducer + (transducer >= 0L ? 1L:-1L); } else { // Calculate next lesser value .... -- Tom From tom.deneau at amd.com Mon Jun 23 21:55:04 2014 From: tom.deneau at amd.com (Deneau, Tom) Date: Mon, 23 Jun 2014 21:55:04 +0000 Subject: logic in Math.nextAfter for handling -0.0 input In-Reply-To: <7F77F134-9439-40C2-B4A6-B58908B9C1E3@oracle.com> References: <7F77F134-9439-40C2-B4A6-B58908B9C1E3@oracle.com> Message-ID: In the same Math.nextAfter routine we have the following which among other things, handles the requirement that nextAfter(+infinity, +infinity) == +infinity and nextAfter(-infinity, -infinity) == -infinity However, in my test case, it looks like the "if (start == direction)" test is being optimized out and the above cases then don't work. Before Math.nextAfter is called the direction parameter is set up as double direction = (gid & 1) == 0 ? Double.POSITIVE_INFINITY : -Double.NEGATIVE_INFINITY; outArray[gid] = Math.nextAfter(inArray[gid], direction); so I don't understand why the (start == direction) test would be optimized out. -- Tom From: Tom Rodriguez [mailto:tom.rodriguez at oracle.com] Sent: Monday, June 23, 2014 4:04 PM To: Deneau, Tom Cc: graal-dev at openjdk.java.net Subject: Re: logic in Math.nextAfter for handling -0.0 input I think graal does this in general so it's not an HSAIL specific problem. >From AddFloatNode.java: @Override public Node canonical(CanonicalizerTool tool) { ... } else if (y().isConstant()) { Constant c = y().asConstant(); if ((c.getKind() == Kind.Float && c.asFloat() == 0.0f) || (c.getKind() == Kind.Double && c.asDouble() == 0.0)) { return x(); } } return this; } FloatSubNode has similar problems. I'll delete the relevant code. tom On Jun 23, 2014, at 1:33 PM, Deneau, Tom > wrote: The JDK method Math.nextAfter contains the logic shown below to handle an input of -0.0 When the graal compiler compiles this for the hsail backend, it makes the reasonable assumption that "start + 0.0d" can be reduced to "start" which is a problem for this algorithm. >From what I could tell, c2 or graal for amd64 backend do not do this optimization and so get the right answer for -0.0 input. How do they know not to do this optimization? } else { // start > direction or start < direction // Add +0.0 to get rid of a -0.0 (+0.0 + -0.0 => +0.0) // then bitwise convert start to integer. long transducer = Double.doubleToRawLongBits(start + 0.0d); <============== if (direction > start) { // Calculate next greater value transducer = transducer + (transducer >= 0L ? 1L:-1L); } else { // Calculate next lesser value .... -- Tom From tom.rodriguez at oracle.com Mon Jun 23 21:56:10 2014 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Mon, 23 Jun 2014 14:56:10 -0700 Subject: logic in Math.nextAfter for handling -0.0 input In-Reply-To: References: <7F77F134-9439-40C2-B4A6-B58908B9C1E3@oracle.com> Message-ID: <3072D23F-4EC0-4005-99B7-45F7FC803688@oracle.com> If it was tiered you?d need to make sure it was a graal compile, not just a C1 compile. I wrote at unit test which shows we are currently doing it wrong. I?ll push that along with the fix. tom On Jun 23, 2014, at 2:07 PM, Deneau, Tom wrote: > Hmm, I tried running with -vm graal and running enough times so Math.nextAfter would get compiled and it was still getting the right answer but maybe I did something wrong. > > -- Tom > > From: Tom Rodriguez [mailto:tom.rodriguez at oracle.com] > Sent: Monday, June 23, 2014 4:04 PM > To: Deneau, Tom > Cc: graal-dev at openjdk.java.net > Subject: Re: logic in Math.nextAfter for handling -0.0 input > > I think graal does this in general so it?s not an HSAIL specific problem. From AddFloatNode.java: > > @Override > public Node canonical(CanonicalizerTool tool) { > ? > } else if (y().isConstant()) { > Constant c = y().asConstant(); > if ((c.getKind() == Kind.Float && c.asFloat() == 0.0f) || (c.getKind() == Kind.Double && c.asDouble() == 0.0)) { > return x(); > } > } > return this; > } > > FloatSubNode has similar problems. I?ll delete the relevant code. > > tom > > > On Jun 23, 2014, at 1:33 PM, Deneau, Tom wrote: > > > The JDK method Math.nextAfter contains the logic shown below to handle an input of -0.0 > > When the graal compiler compiles this for the hsail backend, it makes the reasonable > assumption that "start + 0.0d" can be reduced to "start" which is a problem for this algorithm. > > From what I could tell, c2 or graal for amd64 backend do not do this optimization > and so get the right answer for -0.0 input. How do they know not to do this optimization? > > > } else { // start > direction or start < direction > // Add +0.0 to get rid of a -0.0 (+0.0 + -0.0 => +0.0) > // then bitwise convert start to integer. > long transducer = Double.doubleToRawLongBits(start + 0.0d); <============== > > if (direction > start) { // Calculate next greater value > transducer = transducer + (transducer >= 0L ? 1L:-1L); > } else { // Calculate next lesser value > .... > > -- Tom From tom.rodriguez at oracle.com Mon Jun 23 22:05:57 2014 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Mon, 23 Jun 2014 15:05:57 -0700 Subject: logic in Math.nextAfter for handling -0.0 input In-Reply-To: References: <7F77F134-9439-40C2-B4A6-B58908B9C1E3@oracle.com> Message-ID: Why are you negating NEGATIVE_INFINITY? tom On Jun 23, 2014, at 2:55 PM, Deneau, Tom wrote: > double direction = (gid & 1) == 0 ? Double.POSITIVE_INFINITY : -Double.NEGATIVE_INFINITY; > From tom.deneau at amd.com Mon Jun 23 22:10:02 2014 From: tom.deneau at amd.com (Deneau, Tom) Date: Mon, 23 Jun 2014 22:10:02 +0000 Subject: logic in Math.nextAfter for handling -0.0 input In-Reply-To: References: <7F77F134-9439-40C2-B4A6-B58908B9C1E3@oracle.com> Message-ID: Sorry, in the real test code it was not negated... -- Tom From: Tom Rodriguez [mailto:tom.rodriguez at oracle.com] Sent: Monday, June 23, 2014 5:06 PM To: Deneau, Tom Cc: graal-dev at openjdk.java.net Subject: Re: logic in Math.nextAfter for handling -0.0 input Why are you negating NEGATIVE_INFINITY? tom On Jun 23, 2014, at 2:55 PM, Deneau, Tom > wrote: double direction = (gid & 1) == 0 ? Double.POSITIVE_INFINITY : -Double.NEGATIVE_INFINITY; From tom.rodriguez at oracle.com Mon Jun 23 22:12:18 2014 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Mon, 23 Jun 2014 15:12:18 -0700 Subject: logic in Math.nextAfter for handling -0.0 input In-Reply-To: References: <7F77F134-9439-40C2-B4A6-B58908B9C1E3@oracle.com> Message-ID: <74EA0482-B50E-4F1C-B299-44A67B288062@oracle.com> Can you show me your actual test code which failing? tom On Jun 23, 2014, at 3:10 PM, Deneau, Tom wrote: > Sorry, in the real test code it was not negated? > > -- Tom > > > From: Tom Rodriguez [mailto:tom.rodriguez at oracle.com] > Sent: Monday, June 23, 2014 5:06 PM > To: Deneau, Tom > Cc: graal-dev at openjdk.java.net > Subject: Re: logic in Math.nextAfter for handling -0.0 input > > Why are you negating NEGATIVE_INFINITY? > > tom > > On Jun 23, 2014, at 2:55 PM, Deneau, Tom wrote: > > > double direction = (gid & 1) == 0 ? Double.POSITIVE_INFINITY : -Double.NEGATIVE_INFINITY; From tom.deneau at amd.com Mon Jun 23 22:31:43 2014 From: tom.deneau at amd.com (Deneau, Tom) Date: Mon, 23 Jun 2014 22:31:43 +0000 Subject: logic in Math.nextAfter for handling -0.0 input In-Reply-To: <74EA0482-B50E-4F1C-B299-44A67B288062@oracle.com> References: <7F77F134-9439-40C2-B4A6-B58908B9C1E3@oracle.com> <74EA0482-B50E-4F1C-B299-44A67B288062@oracle.com> Message-ID: On closer inspection, I think the nextAfter(Infinity, Infinity) case was failing because of the way I was checking that the actual was within 1 ULP of the expected. -- Tom From: Tom Rodriguez [mailto:tom.rodriguez at oracle.com] Sent: Monday, June 23, 2014 5:12 PM To: Deneau, Tom Cc: graal-dev at openjdk.java.net Subject: Re: logic in Math.nextAfter for handling -0.0 input Can you show me your actual test code which failing? tom On Jun 23, 2014, at 3:10 PM, Deneau, Tom > wrote: Sorry, in the real test code it was not negated... -- Tom From: Tom Rodriguez [mailto:tom.rodriguez at oracle.com] Sent: Monday, June 23, 2014 5:06 PM To: Deneau, Tom Cc: graal-dev at openjdk.java.net Subject: Re: logic in Math.nextAfter for handling -0.0 input Why are you negating NEGATIVE_INFINITY? tom On Jun 23, 2014, at 2:55 PM, Deneau, Tom > wrote: double direction = (gid & 1) == 0 ? Double.POSITIVE_INFINITY : -Double.NEGATIVE_INFINITY; From doug.simon at oracle.com Tue Jun 24 01:00:06 2014 From: doug.simon at oracle.com (doug.simon at oracle.com) Date: Tue, 24 Jun 2014 01:00:06 +0000 Subject: hg: graal/graal: 16 new changesets Message-ID: <201406240100.s5O10WRt002452@aojmv0008> Changeset: f9f7bd1a6b2c Author: Roland Schatz Date: 2014-06-23 13:13 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/f9f7bd1a6b2c IGV: Support for InputType. ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/match/MatchRuleRegistry.java ! graal/com.oracle.graal.graph/src/com/oracle/graal/graph/NodeClass.java ! graal/com.oracle.graal.printer/src/com/oracle/graal/printer/BinaryGraphPrinter.java ! src/share/tools/IdealGraphVisualizer/Data/src/com/sun/hotspot/igv/data/InputEdge.java ! src/share/tools/IdealGraphVisualizer/Data/src/com/sun/hotspot/igv/data/serialization/BinaryParser.java ! src/share/tools/IdealGraphVisualizer/Data/src/com/sun/hotspot/igv/data/serialization/Parser.java ! src/share/tools/IdealGraphVisualizer/Difference/src/com/sun/hotspot/igv/difference/Difference.java ! src/share/tools/IdealGraphVisualizer/Filter/src/com/sun/hotspot/igv/filter/CombineFilter.java ! src/share/tools/IdealGraphVisualizer/Graal/src/com/sun/hotspot/igv/graal/filters/GraalEdgeColorFilter.java ! src/share/tools/IdealGraphVisualizer/Graal/src/com/sun/hotspot/igv/graal/filters/edgeColor.filter ! src/share/tools/IdealGraphVisualizer/Graph/src/com/sun/hotspot/igv/graph/Connection.java ! src/share/tools/IdealGraphVisualizer/Graph/src/com/sun/hotspot/igv/graph/Diagram.java Changeset: c903c4e693bf Author: Lukas Stadler Date: 2014-06-20 12:09 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/c903c4e693bf run simplification if canonicalization is unsuccessful ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/CanonicalizerPhase.java Changeset: 0993768dfc8e Author: Lukas Stadler Date: 2014-06-23 14:11 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/0993768dfc8e new UnaryNode base class ! 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/HotSpotNodeLIRBuilder.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/nodes/CompressionNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/TypeProfileProxyNode.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/CompareNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/calc/ConvertNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/calc/FloatConvertNode.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/IntegerConvertNode.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/NarrowNode.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/ReinterpretNode.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/UnaryNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/calc/ZeroExtendNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/extended/BoxNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/extended/UnboxNode.java ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/CleanTypeProfileProxyPhase.java ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/cfs/EquationalReasoner.java ! graal/com.oracle.graal.replacements.amd64/src/com/oracle/graal/replacements/amd64/AMD64ConvertSnippets.java ! graal/com.oracle.graal.replacements.amd64/src/com/oracle/graal/replacements/amd64/AMD64FloatConvertNode.java ! graal/com.oracle.graal.replacements.test/src/com/oracle/graal/replacements/test/ObjectAccessTest.java ! graal/com.oracle.graal.replacements.test/src/com/oracle/graal/replacements/test/PointerTest.java ! graal/com.oracle.graal.replacements/src/com/oracle/graal/replacements/DefaultJavaLoweringProvider.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: bd1202138e21 Author: Lukas Stadler Date: 2014-06-23 14:11 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/bd1202138e21 add SimplifierTool.addToWorkList for Iterable ! graal/com.oracle.graal.graph/src/com/oracle/graal/graph/spi/SimplifierTool.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/LoopBeginNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/PhiNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/util/GraphUtil.java ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/CanonicalizerPhase.java Changeset: d8aa3ea65d39 Author: Lukas Stadler Date: 2014-06-23 14:11 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/d8aa3ea65d39 add stampForMask to public interface of StampTool ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/type/StampTool.java Changeset: d3f949fbdf30 Author: Lukas Stadler Date: 2014-06-23 14:11 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/d3f949fbdf30 infer stamps for BitCountNode ! graal/com.oracle.graal.replacements/src/com/oracle/graal/replacements/nodes/BitCountNode.java Changeset: 866438171d1d Author: Lukas Stadler Date: 2014-06-23 14:13 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/866438171d1d infer stamps for BitScanForwardNode and BitScanReverseNode ! 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 Changeset: 13b2e8c4c720 Author: Lukas Stadler Date: 2014-06-23 14:13 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/13b2e8c4c720 infer stamps for ReverseBytesNode ! graal/com.oracle.graal.replacements/src/com/oracle/graal/replacements/nodes/ReverseBytesNode.java Changeset: b3945bb0016f Author: Lukas Stadler Date: 2014-06-23 14:13 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/b3945bb0016f ConditionalNode is not a BinaryNode ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/IfNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/calc/CompareNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/calc/ConditionalNode.java Changeset: d5e66f2adf8f Author: Lukas Stadler Date: 2014-06-23 17:03 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/d5e66f2adf8f tests for bit operations + graal/com.oracle.graal.replacements.test/src/com/oracle/graal/replacements/test/BitOpNodesTest.java Changeset: 3d76b518b007 Author: Lukas Stadler Date: 2014-06-23 17:03 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/3d76b518b007 refactoring of BitCountNode.inferStamp ! graal/com.oracle.graal.replacements/src/com/oracle/graal/replacements/nodes/BitCountNode.java Changeset: 0244e5bdddc1 Author: Lukas Stadler Date: 2014-06-23 17:45 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/0244e5bdddc1 intrinsify unsigned operations in java.lang.Integer/Long ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/calc/UnsignedDivNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/calc/UnsignedRemNode.java ! graal/com.oracle.graal.replacements/src/com/oracle/graal/replacements/IntegerSubstitutions.java ! graal/com.oracle.graal.replacements/src/com/oracle/graal/replacements/LongSubstitutions.java Changeset: d69ede72299a Author: Roland Schatz Date: 2014-06-23 19:57 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/d69ede72299a Expose loadStamp method in HotSpotLoweringProvider interface. ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotLoweringProvider.java ! graal/com.oracle.graal.replacements/src/com/oracle/graal/replacements/DefaultJavaLoweringProvider.java Changeset: 1f4955abca9b Author: Andreas Woess Date: 2014-06-20 13:43 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/1f4955abca9b mx: add jol command for java object layout introspection ! mx/mx_graal.py ! mxtool/mx.py Changeset: b63f0428eb59 Author: Andreas Woess Date: 2014-06-23 18:30 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/b63f0428eb59 TruffleCompiler: use sourceSection.getShortDescription() ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/TruffleCompilerImpl.java Changeset: 91a5fc21f11b Author: Tom Rodriguez Date: 2014-06-23 14:38 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/91a5fc21f11b don't optimize away 0.0 and -0.0 + graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/FloatOptimizationTest.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/FloatSubNode.java From stefan.fehrenbach at gmail.com Tue Jun 24 08:20:16 2014 From: stefan.fehrenbach at gmail.com (Stefan Fehrenbach) Date: Tue, 24 Jun 2014 10:20:16 +0200 Subject: call vs execute Message-ID: Hello, I implemented a recursive descend grammar interpreter using Truffle. Nonterminal calls are replaced by either of three alternative implementations: 1. Unoptimized lookup of the nonterminal in a hash table 2. Look up nonterminal during replacement, cache result and call the cached node's execute method directly. 3. Look up nonterminal during replacement, cache result and use Truffle's function call support to call the execute method. Now it happens that the function call variant is a lot slower than the other two and even the cached variant is still slower than the naive implementation: Unoptimized: 3095 Cached execute: 3555 Cached call: 18521 (Time to parse a long string with a grammar consisting of a long chain of nonterminal calls a couple of times.) My question is: why is the function call variant so much slower? The actual computation is so simple, I expected Truffle/Graal to just inline the functions. And why is the cached variant still slower than the naive implementation. In every parse, we need 150*150 hash table look ups in the naive implementation vs only 150*150 Assumption checks in variant #2. Code is here: https://github.com/fehrenbach/parsers Uninitialized node: https://github.com/fehrenbach/parsers/blob/master/src/org/morphling/parsers/truffle/UninitializedNonterminalCall.java I use the graalvm-jdk1.8.0-0.3 release and the following JVM parameters to call this main method: org.morphling.parsers.truffle.Tests#main -server -Xss32m -Dtruffle.TraceRewrites=true -Dtruffle.DetailedRewriteReasons=true -G:+TraceTruffleCompilationDetails -G:+TraceTruffleCompilation -G:TruffleCompilationThreshold=1 -XX:+UnlockDiagnosticVMOptions -XX:-PrintCompilation Am I just using Truffle the wrong way? What could be the reason for the slow function calls and the underperforming cache, even in this contrived grammar with long nonterminal chains? Best regards, Stefan From duboscq at ssw.jku.at Tue Jun 24 13:17:50 2014 From: duboscq at ssw.jku.at (Gilles Duboscq) Date: Tue, 24 Jun 2014 15:17:50 +0200 Subject: webrev to use oops_do to modify saved hsail state In-Reply-To: References: Message-ID: Hello Tom, A few comments: The indentation in ArrayListSetTest.java and BoundsCatchMost20000StressGCTest.java is a bit strange. In gpu_hsail.cpp: in execute_kernel_void_1d_internal we could asser that THREAD is a JavaThread (is_Java_thread()). In gpu_hsail_Frame.hpp: there starts to be a lot of hard coded constants in there. In gpu_hsail_OopMapHelper.hpp: _saveAreaCounts seems unused (it was already unused in the OopSaver). It looks a bit strange that the oop maps are java object. They should probably be installed as native objects along the kernel but that's outside the scope of this change. As for this change, after the indentation changes in the java file and removal of _saveAreaCounts I think it's fine. -Gilles On Mon, Jun 23, 2014 at 8:35 PM, Tom Deneau wrote: > Has anyone had a chance to look a this webrev? > > -- Tom > > From: Deneau, Tom > Sent: Tuesday, June 17, 2014 10:21 AM > To: graal-dev at openjdk.java.net > Subject: webrev to use oops_do to modify saved hsail state > > I placed a webrev up at > http://cr.openjdk.java.net/~tdeneau/graal-webrevs/webrev-hsail-oops-do/webrev/ > Please consider this for inclusion in graal. > > Background: Ever since we started support deoptimization from hsail kernels, we have had to deal with the fact that any oops saved in the hsail deoptimization save area could move around by GC during the windows that open during deoptimizations to the interpreter. Up until now, we had a hackier (and higher overhead) workaround involving copying oops to and from a java Object array and letting them get fixed up there if necessary. > > This webrev instead uses the standard process of updating the oops in the saved HSAIL state by calling oops_do from a GC thread. > > * A field was added to JavaThread so that we could tell that a thread was processing an hsail kernel. If so, we go thru the saved hsail frames and apply the oops_do closure to each oop in each saved frame. > > * Because the saved HSAILFrames are only used during deoptimization to the interpreter, we only need to process the frames for the deopt items that have not been handled yet. A field was added to HSAILDeoptimizationInfo to keep track of this. > > * Also, note that we don't need to do anything if we have finished the deopting workitems and are handling the never-ran workitems. (The never-rans have to resolve the argument oops, but they always did that). > > There used to be a class called OopSaver defined in gpu_hsail.cpp. That has been removed and we no longer pass the save array. Some of the logic from OopSaver is now in OopMapHelper. HSAILFrame was extended with a few new functions to help with oops_do. > > The disabling of ArrayListSetTest was because of an issue we saw unrelated to this webrev. This issue will be fixed in a later webrev. > > Note: Running with the hsail simulator, there will be a small number of de-opts so it's not the best test environment for this feature, but tests have passed on HSA hardware boxes which can have thousands of de-opts. > > -- Tom > > From tom.deneau at amd.com Tue Jun 24 13:25:22 2014 From: tom.deneau at amd.com (Deneau, Tom) Date: Tue, 24 Jun 2014 13:25:22 +0000 Subject: webrev to use oops_do to modify saved hsail state In-Reply-To: References: Message-ID: Gilles -- I will get version 2 out later today. -- Tom -----Original Message----- From: gilwooden at gmail.com [mailto:gilwooden at gmail.com] On Behalf Of Gilles Duboscq Sent: Tuesday, June 24, 2014 8:18 AM To: Deneau, Tom Cc: graal-dev at openjdk.java.net Subject: Re: webrev to use oops_do to modify saved hsail state Hello Tom, A few comments: The indentation in ArrayListSetTest.java and BoundsCatchMost20000StressGCTest.java is a bit strange. In gpu_hsail.cpp: in execute_kernel_void_1d_internal we could asser that THREAD is a JavaThread (is_Java_thread()). In gpu_hsail_Frame.hpp: there starts to be a lot of hard coded constants in there. In gpu_hsail_OopMapHelper.hpp: _saveAreaCounts seems unused (it was already unused in the OopSaver). It looks a bit strange that the oop maps are java object. They should probably be installed as native objects along the kernel but that's outside the scope of this change. As for this change, after the indentation changes in the java file and removal of _saveAreaCounts I think it's fine. -Gilles On Mon, Jun 23, 2014 at 8:35 PM, Tom Deneau wrote: > Has anyone had a chance to look a this webrev? > > -- Tom > > From: Deneau, Tom > Sent: Tuesday, June 17, 2014 10:21 AM > To: graal-dev at openjdk.java.net > Subject: webrev to use oops_do to modify saved hsail state > > I placed a webrev up at > http://cr.openjdk.java.net/~tdeneau/graal-webrevs/webrev-hsail-oops-do > /webrev/ Please consider this for inclusion in graal. > > Background: Ever since we started support deoptimization from hsail kernels, we have had to deal with the fact that any oops saved in the hsail deoptimization save area could move around by GC during the windows that open during deoptimizations to the interpreter. Up until now, we had a hackier (and higher overhead) workaround involving copying oops to and from a java Object array and letting them get fixed up there if necessary. > > This webrev instead uses the standard process of updating the oops in the saved HSAIL state by calling oops_do from a GC thread. > > * A field was added to JavaThread so that we could tell that a thread was processing an hsail kernel. If so, we go thru the saved hsail frames and apply the oops_do closure to each oop in each saved frame. > > * Because the saved HSAILFrames are only used during deoptimization to the interpreter, we only need to process the frames for the deopt items that have not been handled yet. A field was added to HSAILDeoptimizationInfo to keep track of this. > > * Also, note that we don't need to do anything if we have finished the deopting workitems and are handling the never-ran workitems. (The never-rans have to resolve the argument oops, but they always did that). > > There used to be a class called OopSaver defined in gpu_hsail.cpp. That has been removed and we no longer pass the save array. Some of the logic from OopSaver is now in OopMapHelper. HSAILFrame was extended with a few new functions to help with oops_do. > > The disabling of ArrayListSetTest was because of an issue we saw unrelated to this webrev. This issue will be fixed in a later webrev. > > Note: Running with the hsail simulator, there will be a small number of de-opts so it's not the best test environment for this feature, but tests have passed on HSA hardware boxes which can have thousands of de-opts. > > -- Tom > > From Eric.Caspole at amd.com Tue Jun 24 14:09:44 2014 From: Eric.Caspole at amd.com (Caspole, Eric) Date: Tue, 24 Jun 2014 14:09:44 +0000 Subject: webrev: use assumeTrue to check for simulator Message-ID: Hi everybody, I put a new webrev here: http://cr.openjdk.java.net/~ecaspole/reduce_no_sim/webrev/ The reduce tests already checked in only work when built using the Sumatra JDK and -Dcom.amd.sumatra.offload.immediate=true is used. The HSAIL Simulator does not support HSA group/local memory at this time, so if you run the tests with the JDK and the flag under the simulator, they will fail. Here I added "assumeTrue" to skip the test if running on the simulator which makes it easier for me to work with and test the Sumatra JDK. This change will have no effect when you build Graal using plain JDK 8 since it will not offload the reduce operations. Regards, Eric From tom.deneau at amd.com Tue Jun 24 19:03:43 2014 From: tom.deneau at amd.com (Deneau, Tom) Date: Tue, 24 Jun 2014 19:03:43 +0000 Subject: webrev to use oops_do to modify saved hsail state In-Reply-To: References: Message-ID: Gilles -- I put a new webrev up at http://cr.openjdk.java.net/~tdeneau/graal-webrevs/webrev-hsail-oops-do-v2/webrev -- Tom -----Original Message----- From: gilwooden at gmail.com [mailto:gilwooden at gmail.com] On Behalf Of Gilles Duboscq Sent: Tuesday, June 24, 2014 8:18 AM To: Deneau, Tom Cc: graal-dev at openjdk.java.net Subject: Re: webrev to use oops_do to modify saved hsail state Hello Tom, A few comments: The indentation in ArrayListSetTest.java and BoundsCatchMost20000StressGCTest.java is a bit strange. In gpu_hsail.cpp: in execute_kernel_void_1d_internal we could asser that THREAD is a JavaThread (is_Java_thread()). In gpu_hsail_Frame.hpp: there starts to be a lot of hard coded constants in there. In gpu_hsail_OopMapHelper.hpp: _saveAreaCounts seems unused (it was already unused in the OopSaver). It looks a bit strange that the oop maps are java object. They should probably be installed as native objects along the kernel but that's outside the scope of this change. As for this change, after the indentation changes in the java file and removal of _saveAreaCounts I think it's fine. -Gilles On Mon, Jun 23, 2014 at 8:35 PM, Tom Deneau wrote: > Has anyone had a chance to look a this webrev? > > -- Tom > > From: Deneau, Tom > Sent: Tuesday, June 17, 2014 10:21 AM > To: graal-dev at openjdk.java.net > Subject: webrev to use oops_do to modify saved hsail state > > I placed a webrev up at > http://cr.openjdk.java.net/~tdeneau/graal-webrevs/webrev-hsail-oops-do/webrev/ > Please consider this for inclusion in graal. > > Background: Ever since we started support deoptimization from hsail kernels, we have had to deal with the fact that any oops saved in the hsail deoptimization save area could move around by GC during the windows that open during deoptimizations to the interpreter. Up until now, we had a hackier (and higher overhead) workaround involving copying oops to and from a java Object array and letting them get fixed up there if necessary. > > This webrev instead uses the standard process of updating the oops in the saved HSAIL state by calling oops_do from a GC thread. > > * A field was added to JavaThread so that we could tell that a thread was processing an hsail kernel. If so, we go thru the saved hsail frames and apply the oops_do closure to each oop in each saved frame. > > * Because the saved HSAILFrames are only used during deoptimization to the interpreter, we only need to process the frames for the deopt items that have not been handled yet. A field was added to HSAILDeoptimizationInfo to keep track of this. > > * Also, note that we don't need to do anything if we have finished the deopting workitems and are handling the never-ran workitems. (The never-rans have to resolve the argument oops, but they always did that). > > There used to be a class called OopSaver defined in gpu_hsail.cpp. That has been removed and we no longer pass the save array. Some of the logic from OopSaver is now in OopMapHelper. HSAILFrame was extended with a few new functions to help with oops_do. > > The disabling of ArrayListSetTest was because of an issue we saw unrelated to this webrev. This issue will be fixed in a later webrev. > > Note: Running with the hsail simulator, there will be a small number of de-opts so it's not the best test environment for this feature, but tests have passed on HSA hardware boxes which can have thousands of de-opts. > > -- Tom > > From doug.simon at oracle.com Wed Jun 25 01:00:06 2014 From: doug.simon at oracle.com (doug.simon at oracle.com) Date: Wed, 25 Jun 2014 01:00:06 +0000 Subject: hg: graal/graal: 16 new changesets Message-ID: <201406250100.s5P10V4T006405@aojmv0008> Changeset: 8322735c7540 Author: Tom Rodriguez Date: 2014-06-23 18:00 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/8322735c7540 add missing final to INTERIOR_MATCH ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/match/ComplexMatchValue.java Changeset: 3534a68bb8b9 Author: Tom Rodriguez Date: 2014-06-23 18:00 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/3534a68bb8b9 add contains to NodeWorkList ! graal/com.oracle.graal.graph/src/com/oracle/graal/graph/NodeWorkList.java Changeset: dc62f6e66459 Author: Tom Rodriguez Date: 2014-06-23 18:01 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/dc62f6e66459 remove useless override ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/ConstantNode.java Changeset: b92cad49bcc0 Author: Tom Rodriguez Date: 2014-06-23 18:01 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/b92cad49bcc0 fix help message ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/HotSpotGraalRuntime.java Changeset: 5605c5e37a1e Author: Tom Rodriguez Date: 2014-06-23 18:02 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/5605c5e37a1e use InvokeKind.Special for array methods ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/java/MethodCallTargetNode.java Changeset: 3ee8c2cb629c Author: Tom Rodriguez Date: 2014-06-23 18:02 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/3ee8c2cb629c notify changed when setting input to null ! graal/com.oracle.graal.graph/src/com/oracle/graal/graph/Node.java Changeset: 5785eca138b0 Author: Tom Rodriguez Date: 2014-06-23 18:04 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/5785eca138b0 improve tracking of nodes to canonicalize after inlining ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/MonitorSnippets.java ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/inlining/InliningUtil.java ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/inlining/info/AbstractInlineInfo.java ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/inlining/info/MultiTypeGuardInlineInfo.java ! graal/com.oracle.graal.replacements/src/com/oracle/graal/replacements/GraphKit.java ! graal/com.oracle.graal.replacements/src/com/oracle/graal/replacements/ReplacementsImpl.java ! graal/com.oracle.graal.replacements/src/com/oracle/graal/replacements/SnippetTemplate.java ! graal/com.oracle.graal.replacements/src/com/oracle/graal/replacements/nodes/MacroNode.java ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/PartialEvaluator.java ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/TruffleCacheImpl.java ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/phases/ReplaceIntrinsicsPhase.java Changeset: ef1834ac566c Author: Roland Schatz Date: 2014-06-24 11:43 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/ef1834ac566c Fold nodes with alwaysNull stamp into constant. ! graal/com.oracle.graal.compiler.common/src/com/oracle/graal/compiler/common/type/ObjectStamp.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/nodes/type/NarrowOopStamp.java Changeset: b96e17e6d6aa Author: Julian Lettner Date: 2014-06-24 14:52 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/b96e17e6d6aa Remove obsolete comments. ! graal/com.oracle.truffle.sl/src/com/oracle/truffle/sl/nodes/controlflow/SLBlockNode.java ! graal/com.oracle.truffle.sl/src/com/oracle/truffle/sl/nodes/controlflow/SLFunctionBodyNode.java ! graal/com.oracle.truffle.sl/src/com/oracle/truffle/sl/nodes/controlflow/SLIfNode.java ! graal/com.oracle.truffle.sl/src/com/oracle/truffle/sl/nodes/controlflow/SLWhileNode.java Changeset: 05397227b8d4 Author: Gilles Duboscq Date: 2014-06-24 12:19 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/05397227b8d4 Fix for debug check abort handling in implicit exception handler ! src/share/vm/runtime/sharedRuntime.cpp Changeset: 404d2e86488a Author: Gilles Duboscq Date: 2014-06-24 13:12 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/404d2e86488a CIPrintCompilerName: compiler name should be printed on supplied stream ! src/share/vm/compiler/compileBroker.cpp Changeset: da146f137cf7 Author: Michael Van De Vanter Date: 2014-06-24 09:35 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/da146f137cf7 Truffle/Instrumentation: add method boolean ExecutionContext.hasProbe(SourceSection) ! graal/com.oracle.truffle.api/src/com/oracle/truffle/api/ExecutionContext.java ! graal/com.oracle.truffle.api/src/com/oracle/truffle/api/instrument/impl/ProbeManager.java Changeset: 0a7e9347f8d0 Author: bharadwaj Date: 2014-06-24 13:23 -0400 URL: http://hg.openjdk.java.net/graal/graal/rev/0a7e9347f8d0 Add an ability to specify the signature of a C/C++ foreign function in HotSpotVMConfig and get the full symbol string; add a couple of convenience getters and setters for stubs with foreign call linkage. ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/HotSpotForeignCallLinkage.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/HotSpotVMConfig.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotHostForeignCallsProvider.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/stubs/Stub.java ! graal/com.oracle.graal.hotspotvmconfig/src/com/oracle/graal/hotspotvmconfig/HotSpotVMValue.java Changeset: b1be2a46cc5c Author: Tom Rodriguez Date: 2014-06-24 11:28 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/b1be2a46cc5c canonicalize LoadMethodNodes ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotConstantReflectionProvider.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/extended/LoadMethodNode.java Changeset: 8fde32ece68e Author: Tom Rodriguez Date: 2014-06-24 11:28 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/8fde32ece68e use receiver type in findUniqueConcreteMethod ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/bridge/CompilerToVM.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/bridge/CompilerToVMImpl.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotResolvedJavaMethod.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotResolvedObjectType.java ! src/share/vm/graal/graalCompilerToVM.cpp Changeset: 518a221dbbde Author: Tom Rodriguez Date: 2014-06-24 15:14 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/518a221dbbde don't allow blocking compile requests from the compiler thread ! src/share/vm/compiler/compileBroker.cpp From doug.simon at oracle.com Wed Jun 25 10:29:51 2014 From: doug.simon at oracle.com (doug.simon at oracle.com) Date: Wed, 25 Jun 2014 10:29:51 +0000 Subject: hg: graal/graal: 19 new changesets Message-ID: <201406251030.s5PAUIC6023253@aojmv0008> Changeset: 8366c0c9e5c3 Author: Doug Simon Date: 2014-06-19 12:02 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/8366c0c9e5c3 submit graphs to DebugVerifyHandlers after each phase ! graal/com.oracle.graal.phases/src/com/oracle/graal/phases/BasePhase.java Changeset: dd3d62dfa0bd Author: Doug Simon Date: 2014-06-19 12:03 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/dd3d62dfa0bd added DebugVerifyHandler implementation to verify all phases delete dead nodes ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/DeadCodeEliminationPhase.java + graal/com.oracle.graal.printer/src/com/oracle/graal/printer/NoDeadCodeVerifyHandler.java Changeset: 84b5d413e540 Author: Doug Simon Date: 2014-06-19 12:04 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/84b5d413e540 register NoDeadCodeVerifyHandler with GraalDebugConfig ! graal/com.oracle.graal.printer/src/com/oracle/graal/printer/DebugEnvironment.java Changeset: 7230e2f425f6 Author: Doug Simon Date: 2014-06-19 12:06 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/7230e2f425f6 make Invoke nodes delete unused floating inputs and frame state when intrinsified ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/InvokeNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/InvokeWithExceptionNode.java Changeset: 3e40052d3b91 Author: Doug Simon Date: 2014-06-19 12:07 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/3e40052d3b91 made CollapseFrameForSingleSideEffectPhase clean up dead nodes ! graal/com.oracle.graal.replacements/src/com/oracle/graal/replacements/CollapseFrameForSingleSideEffectPhase.java Changeset: 3e3578bc8f9b Author: Doug Simon Date: 2014-06-19 15:02 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/3e3578bc8f9b rename: lirLoop* -> loop* ! graal/com.oracle.graal.loop/src/com/oracle/graal/loop/LoopEx.java ! graal/com.oracle.graal.loop/src/com/oracle/graal/loop/LoopFragment.java ! graal/com.oracle.graal.loop/src/com/oracle/graal/loop/LoopFragmentWhole.java ! graal/com.oracle.graal.loop/src/com/oracle/graal/loop/LoopsData.java ! graal/com.oracle.graal.loop/src/com/oracle/graal/loop/phases/LoopSafepointEliminationPhase.java ! graal/com.oracle.graal.truffle.test/src/com/oracle/graal/truffle/test/PartialEvaluationTest.java ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/PartialEvaluator.java Changeset: 8588f460fa9b Author: Doug Simon Date: 2014-06-19 15:35 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/8588f460fa9b spelling fix: outterFirst -> outerFirst ! graal/com.oracle.graal.loop/src/com/oracle/graal/loop/LoopsData.java ! graal/com.oracle.graal.loop/src/com/oracle/graal/loop/phases/LoopTransformHighPhase.java Changeset: 48f86e56eb75 Author: Doug Simon Date: 2014-06-19 17:13 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/48f86e56eb75 simplified Debug verification API ! graal/com.oracle.graal.debug/src/com/oracle/graal/debug/Debug.java ! graal/com.oracle.graal.debug/src/com/oracle/graal/debug/DebugVerifyHandler.java ! graal/com.oracle.graal.debug/src/com/oracle/graal/debug/internal/DebugScope.java ! graal/com.oracle.graal.phases/src/com/oracle/graal/phases/BasePhase.java ! graal/com.oracle.graal.printer/src/com/oracle/graal/printer/NoDeadCodeVerifyHandler.java Changeset: 7fb828b4c32b Author: Doug Simon Date: 2014-06-19 17:33 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/7fb828b4c32b made LoopsData clients clean up dead nodes created during loop analysis ! graal/com.oracle.graal.loop/src/com/oracle/graal/loop/DerivedScaledInductionVariable.java ! graal/com.oracle.graal.loop/src/com/oracle/graal/loop/InductionVariable.java ! graal/com.oracle.graal.loop/src/com/oracle/graal/loop/InductionVariables.java ! graal/com.oracle.graal.loop/src/com/oracle/graal/loop/LoopEx.java ! graal/com.oracle.graal.loop/src/com/oracle/graal/loop/LoopsData.java ! graal/com.oracle.graal.loop/src/com/oracle/graal/loop/phases/LoopFullUnrollPhase.java ! graal/com.oracle.graal.loop/src/com/oracle/graal/loop/phases/LoopSafepointEliminationPhase.java ! graal/com.oracle.graal.loop/src/com/oracle/graal/loop/phases/LoopTransformHighPhase.java ! graal/com.oracle.graal.loop/src/com/oracle/graal/loop/phases/LoopTransformLowPhase.java ! graal/com.oracle.graal.replacements/src/com/oracle/graal/replacements/SnippetTemplate.java ! graal/com.oracle.graal.truffle.test/src/com/oracle/graal/truffle/test/PartialEvaluationTest.java ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/PartialEvaluator.java Changeset: e34d8c5fa927 Author: Doug Simon Date: 2014-06-19 17:51 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/e34d8c5fa927 do not create PiNode when lowering GuardingPiNode if the latter has no usages ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/GuardingPiNode.java Changeset: 8bf243c2c87b Author: Doug Simon Date: 2014-06-20 15:18 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/8bf243c2c87b removed explicit tracking of nodes removed by DeadCodeEliminationPhase; added option to enable NoDeadCodeVerifyHandle (disabled by default for now) ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/DeadCodeEliminationPhase.java ! graal/com.oracle.graal.printer/src/com/oracle/graal/printer/NoDeadCodeVerifyHandler.java Changeset: 97a10428ff2c Author: Doug Simon Date: 2014-06-20 15:23 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/97a10428ff2c mx: added support for SYMLINK_GRAAL_JAR env var which controls use of symlinks instead of copying when installing graal.jar into the local JDK(s) (disabled by default) ! mx/mx_graal.py Changeset: 006d99164743 Author: Doug Simon Date: 2014-06-24 23:22 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/006d99164743 handle graphs in JTT tests where one or more parameter nodes have been dead code eliminated ! graal/com.oracle.graal.jtt/src/com/oracle/graal/jtt/JTTTest.java Changeset: 506583999cf2 Author: Doug Simon Date: 2014-06-24 23:22 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/506583999cf2 handle dead-code eliminated nodes in GraalCOmpilerTest.getCanonicalGraphString ! graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/GraalCompilerTest.java Changeset: 38bb9b5b8544 Author: Doug Simon Date: 2014-06-24 23:24 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/38bb9b5b8544 made LoadSnippetVarargsParameterNode.parameters a NodeInputList to keep placeholder parameters alive ! graal/com.oracle.graal.replacements/src/com/oracle/graal/replacements/nodes/LoadSnippetVarargParameterNode.java Changeset: 6140fd60abe9 Author: Doug Simon Date: 2014-06-24 23:29 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/6140fd60abe9 Merge. ! graal/com.oracle.graal.replacements/src/com/oracle/graal/replacements/SnippetTemplate.java ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/PartialEvaluator.java ! mx/mx_graal.py Changeset: 04c0c507d123 Author: Doug Simon Date: 2014-06-25 11:28 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/04c0c507d123 prevent attempt to delete a node twice ! graal/com.oracle.graal.loop/src/com/oracle/graal/loop/DerivedScaledInductionVariable.java Changeset: bf0e3ff4b2c4 Author: Doug Simon Date: 2014-06-25 11:30 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/bf0e3ff4b2c4 removed -XX:+UseGraalCompilationQueue option from gate bootstrap executions since bootstrapping is now supported on the native compiler queue ! mx/mx_graal.py Changeset: c238f67f0745 Author: Doug Simon Date: 2014-06-25 11:30 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/c238f67f0745 Merge. From doug.simon at oracle.com Wed Jun 25 10:35:54 2014 From: doug.simon at oracle.com (Doug Simon) Date: Wed, 25 Jun 2014 12:35:54 +0200 Subject: Speeding up "empty" mx builds Message-ID: On one of my dev machines, I noticed that 'mx build? took longer and longer to complete when no actual building is done. The culprit turned out to be the copying of graal.jar into each JDK variant in the workspace. I don?t yet know why the shutil.move python function takes so long, especially since the underlying drive is an SSD drive. As a workaround, I?ve added support[1] for using symlinks instead of copying graal.jar. On my machine the difference is: [dsimon at coochie]~/linz/basic-graal$ time mx build real 0m7.979s user 0m1.832s sys 0m0.736s [dsimon at coochie]~/linz/basic-graal$ echo "SYMLINK_GRAAL_JAR=true" >> mx/env [dsimon at coochie]~/linz/basic-graal$ time mx build real 0m1.530s user 0m1.704s sys 0m0.376s -Doug [1] http://hg.openjdk.java.net/graal/graal/rev/97a10428ff2c From christian.humer at gmail.com Wed Jun 25 13:43:15 2014 From: christian.humer at gmail.com (Christian Humer) Date: Wed, 25 Jun 2014 15:43:15 +0200 Subject: call vs execute In-Reply-To: References: Message-ID: Hi Stefan, Nice to see some parser experiments with Truffle. I played a bit with your implementation and did some changes in order to fix some issues to enable compilation (see the attached patch). I have a few remarks on what was wrong with it. 1) Be aware of "opt fail" in the output. None of your CallTargets actually got optimized because Truffle compilation failed for several reasons (see below). If you see "opt fail" messages at the output its an indication that either you are we did something wrong. But there is definitely something wrong. The flag -G:+TruffleCompilationExceptionsAreFatal will ensure that such issues will be treated like normal exceptions. 2) Always use @Child annotation for nodes. You used final fields without @Child annotation in order to store nodes that are called using the frame. Always store child nodes in fields annotated with @Child or @Children. Otherwise the Truffle tree cannot be traversed properly by the framework. (that was the reason the inlining did not work). In order to verify that inlining works you can use the -G:+TraceTruffleInlining . 3) Truffle ASTs are trees not graphs. Never cache and reuse Truffle nodes like you did in ParserState. Truffle ASTs always need to be trees. Also do not share trees between created CallTarget instances. At the moment this property is not enforced, but it may be in the future. I changed your caching to caching using CallTargets instead of Alternative node instances. 4) Truffle expands everything on the fast path. Be aware if you call arbitrary Java methods on the fast path. Even common methods like HashMap.get may be too much code to expand. An indication for that is that the compiler fails with the message "too many nodes". In order to avoid such issues cut your calls to untrusted or arbitrary code with the @SlowPath annotation. In the parser case I just annotated ParserState#lookupInEnv with @SlowPath to resolve this issue. After fixing all those issues the performance for the "cached call" benchmark improved from 18 seconds to roughly 100ms. The "Cached execute" benchmark violated the Truffle Tree property so I did not repair it. I hope this helps. Feel free to ask more questions. - Christian Humer On Tue, Jun 24, 2014 at 10:20 AM, Stefan Fehrenbach < stefan.fehrenbach at gmail.com> wrote: > Hello, > > I implemented a recursive descend grammar interpreter using Truffle. > Nonterminal calls are replaced by either of three alternative > implementations: > 1. Unoptimized lookup of the nonterminal in a hash table > 2. Look up nonterminal during replacement, cache result and call the > cached node's execute method directly. > 3. Look up nonterminal during replacement, cache result and use > Truffle's function call support to call the execute method. > > Now it happens that the function call variant is a lot slower than the > other two and even the cached variant is still slower than the naive > implementation: > > Unoptimized: 3095 > Cached execute: 3555 > Cached call: 18521 > (Time to parse a long string with a grammar consisting of a long chain > of nonterminal calls a couple of times.) > > My question is: why is the function call variant so much slower? The > actual computation is so simple, I expected Truffle/Graal to just > inline the functions. > And why is the cached variant still slower than the naive > implementation. In every parse, we need 150*150 hash table look ups in > the naive implementation vs only 150*150 Assumption checks in variant > #2. > > Code is here: https://github.com/fehrenbach/parsers > Uninitialized node: > > https://github.com/fehrenbach/parsers/blob/master/src/org/morphling/parsers/truffle/UninitializedNonterminalCall.java > > I use the graalvm-jdk1.8.0-0.3 release and the following JVM > parameters to call this main method: > org.morphling.parsers.truffle.Tests#main > > -server > -Xss32m > -Dtruffle.TraceRewrites=true > -Dtruffle.DetailedRewriteReasons=true > -G:+TraceTruffleCompilationDetails > -G:+TraceTruffleCompilation > -G:TruffleCompilationThreshold=1 > -XX:+UnlockDiagnosticVMOptions > -XX:-PrintCompilation > > Am I just using Truffle the wrong way? What could be the reason for > the slow function calls and the underperforming cache, even in this > contrived grammar with long nonterminal chains? > > Best regards, > Stefan > From Eric.Caspole at amd.com Wed Jun 25 18:09:25 2014 From: Eric.Caspole at amd.com (Caspole, Eric) Date: Wed, 25 Jun 2014 18:09:25 +0000 Subject: Leak with per thread debug info? Message-ID: I think I found a leak with the DebugValueMaps. I wrote a test where it was creating HSA kernels on short lived threads continuously. It ends up adding a new public static synchronized void registerTopLevel(DebugValueMap map) { topLevelMaps.add(map); } from here: public static DebugScope getInstance() { DebugScope result = instanceTL.get(); if (result == null) { DebugScope topLevelDebugScope = new DebugScope(Thread.currentThread().getName(), "", null, false); instanceTL.set(topLevelDebugScope); DebugValueMap.registerTopLevel(topLevelDebugScope.getValueMap()); return topLevelDebugScope; but since my threads are short lived this ends up being a leak in the topLevelMaps. I see this in Eclipse MAT from a heap dump. Let me know what you think, Thanks, Eric From doug.simon at oracle.com Wed Jun 25 18:44:48 2014 From: doug.simon at oracle.com (Doug Simon) Date: Wed, 25 Jun 2014 20:44:48 +0200 Subject: Leak with per thread debug info? In-Reply-To: References: Message-ID: This is by design so that we get the debug info for all threads (of interest) during a VM execution, not just those alive when the VM is shutting down. Usually there is a bounded number of threads created DebugScopes (e.g. compiler threads) so this is ok. HSA deviates from this model whereby compilation is done in the same application thread triggering a HSA compilation. Is this causing out-of-memory errors in your case? I guess we could investigate the possibility for allowing a thread to remove its top level map when it is about to die... -Doug On Jun 25, 2014, at 8:09 PM, Caspole, Eric wrote: > I think I found a leak with the DebugValueMaps. I wrote a test where it was creating HSA kernels on short lived threads continuously. It ends up adding a new > > public static synchronized void registerTopLevel(DebugValueMap map) { > topLevelMaps.add(map); > } > > from here: > > public static DebugScope getInstance() { > DebugScope result = instanceTL.get(); > if (result == null) { > DebugScope topLevelDebugScope = new DebugScope(Thread.currentThread().getName(), "", null, false); > instanceTL.set(topLevelDebugScope); > DebugValueMap.registerTopLevel(topLevelDebugScope.getValueMap()); > return topLevelDebugScope; > > but since my threads are short lived this ends up being a leak in the topLevelMaps. I see this in Eclipse MAT from a heap dump. > Let me know what you think, > Thanks, > Eric > From Eric.Caspole at amd.com Thu Jun 26 00:06:11 2014 From: Eric.Caspole at amd.com (Caspole, Eric) Date: Thu, 26 Jun 2014 00:06:11 +0000 Subject: Leak with per thread debug info? In-Reply-To: References: , Message-ID: We are not blocked on this. We have been cosidering about whether to have a compile queue and compiler threads model for the offload because we have hit several of those "not enough profiling data" type problems in the last month or so. I knew we already had a leak in the Sumatra JDK part, and when I went to work on that I discovered this one. But it is not a problem for the time being. Eric ________________________________________ From: Doug Simon [doug.simon at oracle.com] Sent: Wednesday, June 25, 2014 2:44 PM To: Caspole, Eric Cc: graal-dev at openjdk.java.net Subject: Re: Leak with per thread debug info? This is by design so that we get the debug info for all threads (of interest) during a VM execution, not just those alive when the VM is shutting down. Usually there is a bounded number of threads created DebugScopes (e.g. compiler threads) so this is ok. HSA deviates from this model whereby compilation is done in the same application thread triggering a HSA compilation. Is this causing out-of-memory errors in your case? I guess we could investigate the possibility for allowing a thread to remove its top level map when it is about to die... -Doug On Jun 25, 2014, at 8:09 PM, Caspole, Eric wrote: > I think I found a leak with the DebugValueMaps. I wrote a test where it was creating HSA kernels on short lived threads continuously. It ends up adding a new > > public static synchronized void registerTopLevel(DebugValueMap map) { > topLevelMaps.add(map); > } > > from here: > > public static DebugScope getInstance() { > DebugScope result = instanceTL.get(); > if (result == null) { > DebugScope topLevelDebugScope = new DebugScope(Thread.currentThread().getName(), "", null, false); > instanceTL.set(topLevelDebugScope); > DebugValueMap.registerTopLevel(topLevelDebugScope.getValueMap()); > return topLevelDebugScope; > > but since my threads are short lived this ends up being a leak in the topLevelMaps. I see this in Eclipse MAT from a heap dump. > Let me know what you think, > Thanks, > Eric > From Eric.Caspole at amd.com Thu Jun 26 00:22:36 2014 From: Eric.Caspole at amd.com (Caspole, Eric) Date: Thu, 26 Jun 2014 00:22:36 +0000 Subject: JEP draft for Sumatra in OpenJDK JIRA Message-ID: Hi everybody, After side discussions with some Oracle folks I have prepared a JEP draft for Project Sumatra here: https://bugs.openjdk.java.net/browse/JDK-8047074 This draft is oriented for Stream API and HSA offload, because that is what we have working, without intending to prevent any other possible implementations or good ideas. We welcome feedback on this draft. Thanks, Eric From doug.simon at oracle.com Thu Jun 26 01:00:06 2014 From: doug.simon at oracle.com (doug.simon at oracle.com) Date: Thu, 26 Jun 2014 01:00:06 +0000 Subject: hg: graal/graal: 31 new changesets Message-ID: <201406260100.s5Q10rSQ006089@aojmv0008> Changeset: d078a3239653 Author: Lukas Stadler Date: 2014-06-25 10:58 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/d078a3239653 new Unary and Binary canonicalizable interfaces ! graal/com.oracle.graal.graph/src/com/oracle/graal/graph/spi/Canonicalizable.java Changeset: 2a1f3a8f76f1 Author: Lukas Stadler Date: 2014-06-25 11:20 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/2a1f3a8f76f1 handle Canonicalizable.Unary/Binary in CanonicalizerPhase and EquationalReasoner ! graal/com.oracle.graal.graph/src/com/oracle/graal/graph/Graph.java ! graal/com.oracle.graal.graph/src/com/oracle/graal/graph/NodeClass.java ! graal/com.oracle.graal.graph/src/com/oracle/graal/graph/NodeList.java ! graal/com.oracle.graal.graph/src/com/oracle/graal/graph/spi/Canonicalizable.java ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/CanonicalizerPhase.java ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/cfs/EquationalReasoner.java Changeset: df6f2365b153 Author: Lukas Stadler Date: 2014-06-25 11:20 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/df6f2365b153 rename of x() to getX(), y() to getY() and object() to getValue() ! graal/com.oracle.graal.compiler.amd64/src/com/oracle/graal/compiler/amd64/AMD64NodeLIRBuilder.java ! graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/CompareCanonicalizerTest.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/replacements/InstanceOfSnippets.java ! graal/com.oracle.graal.loop/src/com/oracle/graal/loop/DerivedOffsetInductionVariable.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/BinaryOpLogicNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/IfNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/LoopBeginNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/UnaryOpLogicNode.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/BinaryNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/calc/CompareNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/calc/ConditionalNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/calc/FloatAddNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/calc/FloatDivNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/calc/FloatMulNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/calc/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/IntegerBelowThanNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/calc/IntegerDivNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/calc/IntegerEqualsNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/calc/IntegerLessThanNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/calc/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/IntegerTestNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/calc/IsNullNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/calc/LeftShiftNode.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/NormalizeCompareNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/calc/ObjectEqualsNode.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/RightShiftNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/calc/UnsignedRightShiftNode.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/BranchProbabilityNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/java/InstanceOfNode.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/ConvertDeoptimizeToGuardPhase.java ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/GuardLoweringPhase.java ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/UseTrappingNullChecksPhase.java ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/cfs/CastCheckExtractor.java ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/cfs/EquationalReasoner.java ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/cfs/GuardingPiReduction.java ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/cfs/State.java ! graal/com.oracle.graal.phases/src/com/oracle/graal/phases/verify/VerifyUsageWithEquals.java ! graal/com.oracle.graal.replacements.test/src/com/oracle/graal/replacements/test/InstanceOfTest.java ! graal/com.oracle.graal.replacements/src/com/oracle/graal/replacements/DefaultJavaLoweringProvider.java ! graal/com.oracle.graal.replacements/src/com/oracle/graal/replacements/InstanceOfSnippetsTemplates.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/phases/WordTypeVerificationPhase.java Changeset: e73e293c8a65 Author: Lukas Stadler Date: 2014-06-25 11:20 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/e73e293c8a65 non-adding factory methods in ConstantNode ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/ConstantNode.java Changeset: dc1f9c606f36 Author: Lukas Stadler Date: 2014-06-25 11:20 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/dc1f9c606f36 non-adding factory methods in LogicConstantNode ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/LogicConstantNode.java Changeset: 6beb6da182fc Author: Lukas Stadler Date: 2014-06-25 11:20 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/6beb6da182fc non-adding factory methods in BitLogicNode ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/calc/BitLogicNode.java Changeset: a15b25626672 Author: Lukas Stadler Date: 2014-06-25 11:20 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/a15b25626672 implement Canonicalizable.Unary in the UnaryOpLogicNode hierarchy ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/UnaryOpLogicNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/calc/IsNullNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/java/InstanceOfNode.java Changeset: 51c7c676d41a Author: Lukas Stadler Date: 2014-06-25 11:21 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/51c7c676d41a implement Canonicalizable.Binary in the BinaryOpLogicNode hierarchy ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/BinaryOpLogicNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/calc/CompareNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/calc/FloatEqualsNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/calc/FloatLessThanNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/calc/IntegerBelowThanNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/calc/IntegerEqualsNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/calc/IntegerLessThanNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/calc/IntegerTestNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/calc/ObjectEqualsNode.java Changeset: de90d96f562c Author: Lukas Stadler Date: 2014-06-25 11:25 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/de90d96f562c make InstanceOfDynamicNode a BinaryOpLogicNode ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/java/InstanceOfDynamicNode.java Changeset: dcaf26339f7c Author: Josef Eisl Date: 2014-06-25 13:11 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/dcaf26339f7c Make ValueProcedure a subclass of InstructionValueProcedure and remove redundancies. ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/HotSpotLIRFrameState.java ! graal/com.oracle.graal.lir/src/com/oracle/graal/lir/CompositeValue.java ! graal/com.oracle.graal.lir/src/com/oracle/graal/lir/CompositeValueClass.java ! graal/com.oracle.graal.lir/src/com/oracle/graal/lir/LIRFrameState.java ! graal/com.oracle.graal.lir/src/com/oracle/graal/lir/LIRInstruction.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 Changeset: b558af6ff4bc Author: Lukas Stadler Date: 2014-06-25 16:35 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/b558af6ff4bc don't pass stamps to arithmetic node constructors ! graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/ea/EscapeAnalysisTest.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/CountedLoopInfo.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/BinaryNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/calc/BitLogicNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/calc/FloatAddNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/calc/FloatDivNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/calc/FloatMulNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/calc/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/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/IntegerRemNode.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/LeftShiftNode.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/RightShiftNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/calc/ShiftNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/calc/UnsignedDivNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/calc/UnsignedRemNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/calc/UnsignedRightShiftNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/calc/XorNode.java ! graal/com.oracle.graal.replacements/src/com/oracle/graal/replacements/IntegerSubstitutions.java ! graal/com.oracle.graal.replacements/src/com/oracle/graal/replacements/LongSubstitutions.java ! graal/com.oracle.graal.replacements/src/com/oracle/graal/replacements/UnsignedMathSubstitutions.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/IntegerSubExactNode.java ! graal/com.oracle.graal.word/src/com/oracle/graal/word/phases/WordTypeRewriterPhase.java Changeset: 388b787a5fe6 Author: Lukas Stadler Date: 2014-06-25 16:35 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/388b787a5fe6 implement Canonicalizable.Unary in the UnaryNode hierarchy ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/nodes/CompressionNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/TypeProfileProxyNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/calc/FloatConvertNode.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/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/ReinterpretNode.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/UnaryNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/calc/ZeroExtendNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/extended/BoxNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/extended/UnboxNode.java ! graal/com.oracle.graal.replacements.amd64/src/com/oracle/graal/replacements/amd64/AMD64FloatConvertNode.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: 561070049e73 Author: Lukas Stadler Date: 2014-06-25 16:54 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/561070049e73 implement Canonicalizable.Binary in the BinaryNode hierarchy ! graal/com.oracle.graal.loop/src/com/oracle/graal/loop/LoopEx.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/BinaryNode.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/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/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/IntegerRemNode.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/LeftShiftNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/calc/NormalizeCompareNode.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/RightShiftNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/calc/UnsignedRemNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/calc/UnsignedRightShiftNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/calc/XorNode.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 Changeset: c3260b05fd26 Author: Lukas Stadler Date: 2014-06-25 16:55 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/c3260b05fd26 rename x() to getX() and y() to getY() in FixedBinaryNode ! graal/com.oracle.graal.compiler.amd64/src/com/oracle/graal/compiler/amd64/AMD64NodeLIRBuilder.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/calc/FixedBinaryNode.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/calc/UnsignedDivNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/calc/UnsignedRemNode.java Changeset: 24c30ecf930f Author: Lukas Stadler Date: 2014-06-25 16:55 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/24c30ecf930f rename object() to getValue() in LoadHubNode ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/extended/LoadHubNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/extended/LoadMethodNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/java/TypeSwitchNode.java ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/ConditionalEliminationPhase.java ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/cfs/FlowSensitiveReduction.java ! graal/com.oracle.graal.replacements/src/com/oracle/graal/replacements/DefaultJavaLoweringProvider.java Changeset: 4182366b8eed Author: Lukas Stadler Date: 2014-06-25 16:55 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/4182366b8eed rename getInput() to getValue() in LogicNegationNode ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/AbstractFixedGuardNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/ConditionAnchorNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/GuardNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/IfNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/LogicNegationNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/ShortCircuitOrNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/calc/ConditionalNode.java ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/cfs/State.java Changeset: 8e82823712ba Author: Lukas Stadler Date: 2014-06-25 16:55 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/8e82823712ba let BranchProbabilityNode implement Simplifiable instead of Canonicalizable ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/extended/BranchProbabilityNode.java Changeset: 7a0035cbf808 Author: Lukas Stadler Date: 2014-06-25 16:55 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/7a0035cbf808 let ClassCastNode, CheckCastDynamicNode and LoadHubNode implement Canonicalizable.Unary/Binary ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/nodes/ClassCastNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/extended/LoadHubNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/java/CheckCastDynamicNode.java Changeset: 1434b835f0d3 Author: Lukas Stadler Date: 2014-06-25 16:55 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/1434b835f0d3 implement Canonicalizable.Binary in the FixedBinaryNode hierarchy ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/calc/FixedBinaryNode.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/calc/UnsignedDivNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/calc/UnsignedRemNode.java Changeset: 68f16c1057d4 Author: Lukas Stadler Date: 2014-06-25 16:55 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/68f16c1057d4 let LogicNegationNode and ShortCircuitNode implement Canonicalizable.Unary/Binary ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/LogicNegationNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/ShortCircuitOrNode.java Changeset: 69ab53db5080 Author: Lukas Stadler Date: 2014-06-25 16:55 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/69ab53db5080 add initializing ValuePhiNode constructor ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/ValuePhiNode.java Changeset: cc4b4fd5c484 Author: Lukas Stadler Date: 2014-06-25 16:55 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/cc4b4fd5c484 let LoadFieldNode implement Canonicalizable.Unary ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/java/LoadFieldNode.java ! graal/com.oracle.graal.word/src/com/oracle/graal/word/phases/WordTypeRewriterPhase.java Changeset: ec17c588abf9 Author: Doug Simon Date: 2014-06-25 12:38 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/ec17c588abf9 rename: MemoryMapNode -> MemoryMap + graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/MemoryMap.java - graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/MemoryMapNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/ReturnNode.java ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/FloatingReadPhase.java ! graal/com.oracle.graal.replacements/src/com/oracle/graal/replacements/InstanceOfSnippetsTemplates.java ! graal/com.oracle.graal.replacements/src/com/oracle/graal/replacements/SnippetTemplate.java Changeset: df5ac85a4813 Author: Doug Simon Date: 2014-06-25 16:52 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/df5ac85a4813 handle parameter nodes have been dead code eliminated in MonitorGraphTest ! graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/MonitorGraphTest.java Changeset: d837c02aba58 Author: Doug Simon Date: 2014-06-25 16:53 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/d837c02aba58 support constructing a NodeInputList from a collection of NodeInterface objects ! graal/com.oracle.graal.graph/src/com/oracle/graal/graph/NodeInputList.java ! graal/com.oracle.graal.graph/src/com/oracle/graal/graph/NodeList.java Changeset: 5f72421928e0 Author: Doug Simon Date: 2014-06-25 16:56 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/5f72421928e0 converted MemoryMap to an interface and provided new MemoryMapNode implementation that is also a Node allowing the map and it's node entries to survive DeadCodeElimination by normal graph reachability rules ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/MemoryMap.java + graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/MemoryMapNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/ReturnNode.java ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/FloatingReadPhase.java ! graal/com.oracle.graal.replacements/src/com/oracle/graal/replacements/SnippetTemplate.java Changeset: a47528fb2ea0 Author: Doug Simon Date: 2014-06-25 16:57 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/a47528fb2ea0 slight change to semantics of -G:NDCV option ! graal/com.oracle.graal.printer/src/com/oracle/graal/printer/NoDeadCodeVerifyHandler.java Changeset: e34bb128f227 Author: Doug Simon Date: 2014-06-25 17:34 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/e34bb128f227 Merge. ! graal/com.oracle.graal.graph/src/com/oracle/graal/graph/NodeList.java ! graal/com.oracle.graal.replacements/src/com/oracle/graal/replacements/InstanceOfSnippetsTemplates.java Changeset: 68fb8e4d8043 Author: Doug Simon Date: 2014-06-25 17:40 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/68fb8e4d8043 added missed copyright header ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/MemoryMapNode.java Changeset: 32b829303ff2 Author: Doug Simon Date: 2014-06-25 17:58 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/32b829303ff2 fixed issue discovered by findbugs ! graal/com.oracle.graal.printer/src/com/oracle/graal/printer/NoDeadCodeVerifyHandler.java Changeset: 0aac7ed51b12 Author: Lukas Stadler Date: 2014-06-25 18:47 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/0aac7ed51b12 Temporarily back out faulty changeset cc4b4fd5c484 ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/java/LoadFieldNode.java ! graal/com.oracle.graal.word/src/com/oracle/graal/word/phases/WordTypeRewriterPhase.java From duboscq at ssw.jku.at Thu Jun 26 10:22:24 2014 From: duboscq at ssw.jku.at (Gilles Duboscq) Date: Thu, 26 Jun 2014 12:22:24 +0200 Subject: webrev to use oops_do to modify saved hsail state In-Reply-To: References: Message-ID: Hello Tom, I tried to integrate it yesterday but i face the following problems: BoundsCatchMost20000StressGCTest.java does not pass the formatter. in HSAILHotSpotBackend.java, OopMapArrayBuilder.getSaveAreaCounts is unused. in gpu_hsail_Frame.hpp num_sregs and num_dregs are not defined. On line 56 i get "comparison between signed and unsigned integer expressions" -Gilles On Tue, Jun 24, 2014 at 9:03 PM, Tom Deneau wrote: > Gilles -- > > I put a new webrev up at > http://cr.openjdk.java.net/~tdeneau/graal-webrevs/webrev-hsail-oops-do-v2/webrev > > -- Tom > > -----Original Message----- > From: gilwooden at gmail.com [mailto:gilwooden at gmail.com] On Behalf Of Gilles Duboscq > Sent: Tuesday, June 24, 2014 8:18 AM > To: Deneau, Tom > Cc: graal-dev at openjdk.java.net > Subject: Re: webrev to use oops_do to modify saved hsail state > > Hello Tom, > > A few comments: > The indentation in ArrayListSetTest.java and > BoundsCatchMost20000StressGCTest.java is a bit strange. > In gpu_hsail.cpp: in execute_kernel_void_1d_internal we could asser > that THREAD is a JavaThread (is_Java_thread()). > In gpu_hsail_Frame.hpp: there starts to be a lot of hard coded > constants in there. > In gpu_hsail_OopMapHelper.hpp: _saveAreaCounts seems unused (it was > already unused in the OopSaver). > > It looks a bit strange that the oop maps are java object. They should > probably be installed as native objects along the kernel but that's > outside the scope of this change. > As for this change, after the indentation changes in the java file and > removal of _saveAreaCounts I think it's fine. > > -Gilles > > > > On Mon, Jun 23, 2014 at 8:35 PM, Tom Deneau wrote: >> Has anyone had a chance to look a this webrev? >> >> -- Tom >> >> From: Deneau, Tom >> Sent: Tuesday, June 17, 2014 10:21 AM >> To: graal-dev at openjdk.java.net >> Subject: webrev to use oops_do to modify saved hsail state >> >> I placed a webrev up at >> http://cr.openjdk.java.net/~tdeneau/graal-webrevs/webrev-hsail-oops-do/webrev/ >> Please consider this for inclusion in graal. >> >> Background: Ever since we started support deoptimization from hsail kernels, we have had to deal with the fact that any oops saved in the hsail deoptimization save area could move around by GC during the windows that open during deoptimizations to the interpreter. Up until now, we had a hackier (and higher overhead) workaround involving copying oops to and from a java Object array and letting them get fixed up there if necessary. >> >> This webrev instead uses the standard process of updating the oops in the saved HSAIL state by calling oops_do from a GC thread. >> >> * A field was added to JavaThread so that we could tell that a thread was processing an hsail kernel. If so, we go thru the saved hsail frames and apply the oops_do closure to each oop in each saved frame. >> >> * Because the saved HSAILFrames are only used during deoptimization to the interpreter, we only need to process the frames for the deopt items that have not been handled yet. A field was added to HSAILDeoptimizationInfo to keep track of this. >> >> * Also, note that we don't need to do anything if we have finished the deopting workitems and are handling the never-ran workitems. (The never-rans have to resolve the argument oops, but they always did that). >> >> There used to be a class called OopSaver defined in gpu_hsail.cpp. That has been removed and we no longer pass the save array. Some of the logic from OopSaver is now in OopMapHelper. HSAILFrame was extended with a few new functions to help with oops_do. >> >> The disabling of ArrayListSetTest was because of an issue we saw unrelated to this webrev. This issue will be fixed in a later webrev. >> >> Note: Running with the hsail simulator, there will be a small number of de-opts so it's not the best test environment for this feature, but tests have passed on HSA hardware boxes which can have thousands of de-opts. >> >> -- Tom >> >> From tom.deneau at amd.com Thu Jun 26 14:55:34 2014 From: tom.deneau at amd.com (Deneau, Tom) Date: Thu, 26 Jun 2014 14:55:34 +0000 Subject: webrev to use oops_do to modify saved hsail state In-Reply-To: References: Message-ID: Gilles -- Sorry about that. Forgot to do the debug and fastdebug builds. Hopefully version 3 will resolve these issues... http://cr.openjdk.java.net/~tdeneau/graal-webrevs/webrev-hsail-oops-do-v3/webrev -- Tom -----Original Message----- From: gilwooden at gmail.com [mailto:gilwooden at gmail.com] On Behalf Of Gilles Duboscq Sent: Thursday, June 26, 2014 5:22 AM To: Deneau, Tom Cc: graal-dev at openjdk.java.net Subject: Re: webrev to use oops_do to modify saved hsail state Hello Tom, I tried to integrate it yesterday but i face the following problems: BoundsCatchMost20000StressGCTest.java does not pass the formatter. in HSAILHotSpotBackend.java, OopMapArrayBuilder.getSaveAreaCounts is unused. in gpu_hsail_Frame.hpp num_sregs and num_dregs are not defined. On line 56 i get "comparison between signed and unsigned integer expressions" -Gilles On Tue, Jun 24, 2014 at 9:03 PM, Tom Deneau wrote: > Gilles -- > > I put a new webrev up at > http://cr.openjdk.java.net/~tdeneau/graal-webrevs/webrev-hsail-oops-do-v2/webrev > > -- Tom > > -----Original Message----- > From: gilwooden at gmail.com [mailto:gilwooden at gmail.com] On Behalf Of Gilles Duboscq > Sent: Tuesday, June 24, 2014 8:18 AM > To: Deneau, Tom > Cc: graal-dev at openjdk.java.net > Subject: Re: webrev to use oops_do to modify saved hsail state > > Hello Tom, > > A few comments: > The indentation in ArrayListSetTest.java and > BoundsCatchMost20000StressGCTest.java is a bit strange. > In gpu_hsail.cpp: in execute_kernel_void_1d_internal we could asser > that THREAD is a JavaThread (is_Java_thread()). > In gpu_hsail_Frame.hpp: there starts to be a lot of hard coded > constants in there. > In gpu_hsail_OopMapHelper.hpp: _saveAreaCounts seems unused (it was > already unused in the OopSaver). > > It looks a bit strange that the oop maps are java object. They should > probably be installed as native objects along the kernel but that's > outside the scope of this change. > As for this change, after the indentation changes in the java file and > removal of _saveAreaCounts I think it's fine. > > -Gilles > > > > On Mon, Jun 23, 2014 at 8:35 PM, Tom Deneau wrote: >> Has anyone had a chance to look a this webrev? >> >> -- Tom >> >> From: Deneau, Tom >> Sent: Tuesday, June 17, 2014 10:21 AM >> To: graal-dev at openjdk.java.net >> Subject: webrev to use oops_do to modify saved hsail state >> >> I placed a webrev up at >> http://cr.openjdk.java.net/~tdeneau/graal-webrevs/webrev-hsail-oops-do/webrev/ >> Please consider this for inclusion in graal. >> >> Background: Ever since we started support deoptimization from hsail kernels, we have had to deal with the fact that any oops saved in the hsail deoptimization save area could move around by GC during the windows that open during deoptimizations to the interpreter. Up until now, we had a hackier (and higher overhead) workaround involving copying oops to and from a java Object array and letting them get fixed up there if necessary. >> >> This webrev instead uses the standard process of updating the oops in the saved HSAIL state by calling oops_do from a GC thread. >> >> * A field was added to JavaThread so that we could tell that a thread was processing an hsail kernel. If so, we go thru the saved hsail frames and apply the oops_do closure to each oop in each saved frame. >> >> * Because the saved HSAILFrames are only used during deoptimization to the interpreter, we only need to process the frames for the deopt items that have not been handled yet. A field was added to HSAILDeoptimizationInfo to keep track of this. >> >> * Also, note that we don't need to do anything if we have finished the deopting workitems and are handling the never-ran workitems. (The never-rans have to resolve the argument oops, but they always did that). >> >> There used to be a class called OopSaver defined in gpu_hsail.cpp. That has been removed and we no longer pass the save array. Some of the logic from OopSaver is now in OopMapHelper. HSAILFrame was extended with a few new functions to help with oops_do. >> >> The disabling of ArrayListSetTest was because of an issue we saw unrelated to this webrev. This issue will be fixed in a later webrev. >> >> Note: Running with the hsail simulator, there will be a small number of de-opts so it's not the best test environment for this feature, but tests have passed on HSA hardware boxes which can have thousands of de-opts. >> >> -- Tom >> >> From jules_gosnell at yahoo.com Thu Jun 26 22:25:22 2014 From: jules_gosnell at yahoo.com (Jules Gosnell) Date: Thu, 26 Jun 2014 23:25:22 +0100 Subject: http://hg.openjdk.java.net/graal/graal build broken: findbugs jar missing / out of date ? Message-ID: <53AC9DD2.9040000@yahoo.com> ... Downloading jar:http://sourceforge.net/projects/findbugs/files/findbugs/3.0.0/findbugs-3.0.0-dev-20131204-e3cbbd5.zip/download!/findbugs-3.0.0-dev-20131204-e3cbbd5/lib/findbugs.jar to /usr/local/media/jenkins/workspace/graal/graal/lib/findbugs-3.0.0-dev-20131204-e3cbbd5.jar Error reading from jar:http://sourceforge.net/projects/findbugs/files/findbugs/3.0.0/findbugs-3.0.0-dev-20131204-e3cbbd5.zip/download!/findbugs-3.0.0-dev-20131204-e3cbbd5/lib/findbugs.jar: java.io.FileNotFoundException: http://sourceforge.net/projects/findbugs/files/findbugs/3.0.0/findbugs-3.0.0-dev-20131204-e3cbbd5.zip/download Exception in thread "main" java.lang.Error: Could not download content to /usr/local/media/jenkins/workspace/graal/graal/lib/findbugs-3.0.0-dev-20131204-e3cbbd5.jar from [jar:http://sourceforge.net/projects/findbugs/files/findbugs/3.0.0/findbugs-3.0.0-dev-20131204-e3cbbd5.zip/download!/findbugs-3.0.0-dev-20131204-e3cbbd5/lib/findbugs.jar] at URLConnectionDownload.main(URLConnectionDownload.java:114) Could not download to /usr/local/media/jenkins/workspace/graal/graal/lib/findbugs-3.0.0-dev-20131204-e3cbbd5.jar from any of the following URLs: jar:http://sourceforge.net/projects/findbugs/files/findbugs/3.0.0/findbugs-3.0.0-dev-20131204-e3cbbd5.zip/download!/findbugs-3.0.0-dev-20131204-e3cbbd5/lib/findbugs.jar Please use a web browser to do the download manually ... if you try to d/l the jar manually, you'll find that it is not there... I'm guessing that it has been replaced by 3.0.0 which appears to have been released on 2014-06-25 - i.e. yesterday - not sure why they would have removed the old release though ? cheers, Jules From mick.jordan at oracle.com Thu Jun 26 23:24:51 2014 From: mick.jordan at oracle.com (Mick Jordan) Date: Thu, 26 Jun 2014 16:24:51 -0700 Subject: http://hg.openjdk.java.net/graal/graal build broken: findbugs jar missing / out of date ? In-Reply-To: <53AC9DD2.9040000@yahoo.com> References: <53AC9DD2.9040000@yahoo.com> Message-ID: <53ACABC3.2060902@oracle.com> On 6/26/14, 3:25 PM, Jules Gosnell wrote: > ... > Downloading > jar:http://sourceforge.net/projects/findbugs/files/findbugs/3.0.0/findbugs-3.0.0-dev-20131204-e3cbbd5.zip/download!/findbugs-3.0.0-dev-20131204-e3cbbd5/lib/findbugs.jar > to > /usr/local/media/jenkins/workspace/graal/graal/lib/findbugs-3.0.0-dev-20131204-e3cbbd5.jar > Error reading from > jar:http://sourceforge.net/projects/findbugs/files/findbugs/3.0.0/findbugs-3.0.0-dev-20131204-e3cbbd5.zip/download!/findbugs-3.0.0-dev-20131204-e3cbbd5/lib/findbugs.jar: > java.io.FileNotFoundException: > http://sourceforge.net/projects/findbugs/files/findbugs/3.0.0/findbugs-3.0.0-dev-20131204-e3cbbd5.zip/download > Exception in thread "main" java.lang.Error: Could not download content > to > /usr/local/media/jenkins/workspace/graal/graal/lib/findbugs-3.0.0-dev-20131204-e3cbbd5.jar > from > [jar:http://sourceforge.net/projects/findbugs/files/findbugs/3.0.0/findbugs-3.0.0-dev-20131204-e3cbbd5.zip/download!/findbugs-3.0.0-dev-20131204-e3cbbd5/lib/findbugs.jar] > at URLConnectionDownload.main(URLConnectionDownload.java:114) > Could not download to > /usr/local/media/jenkins/workspace/graal/graal/lib/findbugs-3.0.0-dev-20131204-e3cbbd5.jar > from any of the following URLs: > > > jar:http://sourceforge.net/projects/findbugs/files/findbugs/3.0.0/findbugs-3.0.0-dev-20131204-e3cbbd5.zip/download!/findbugs-3.0.0-dev-20131204-e3cbbd5/lib/findbugs.jar > > > Please use a web browser to do the download manually > ... > > if you try to d/l the jar manually, you'll find that it is not there... > > I'm guessing that it has been replaced by 3.0.0 which appears to have > been released on 2014-06-25 - i.e. yesterday - not sure why they would > have removed the old release though ? > There is an update in the pipe. Mick From doug.simon at oracle.com Fri Jun 27 01:00:06 2014 From: doug.simon at oracle.com (doug.simon at oracle.com) Date: Fri, 27 Jun 2014 01:00:06 +0000 Subject: hg: graal/graal: 23 new changesets Message-ID: <201406270100.s5R10eSC016509@aojmv0008> Changeset: 197ae7ce6bf8 Author: Lukas Stadler Date: 2014-06-26 09:45 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/197ae7ce6bf8 (re-apply) let LoadFieldNode implement Canonicalizable.Unary ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/java/LoadFieldNode.java ! graal/com.oracle.graal.word/src/com/oracle/graal/word/phases/WordTypeRewriterPhase.java Changeset: 0e5e4628fca7 Author: Lukas Stadler Date: 2014-06-26 09:53 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/0e5e4628fca7 let AddLocationNode implement Canonicalizable.Binary ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/extended/AddLocationNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/extended/ConstantLocationNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/extended/IndexedLocationNode.java Changeset: db5b41891078 Author: Lukas Stadler Date: 2014-06-26 10:16 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/db5b41891078 let ArrayLengthNode implement Canonicalizable.Binary ! graal/com.oracle.graal.hotspot.hsail/src/com/oracle/graal/hotspot/hsail/replacements/HSAILNewObjectSnippets.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/NewObjectSnippets.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/java/ArrayLengthNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/java/DynamicNewArrayNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/virtual/VirtualArrayNode.java ! graal/com.oracle.graal.replacements/src/com/oracle/graal/replacements/DefaultJavaLoweringProvider.java ! graal/com.oracle.graal.replacements/src/com/oracle/graal/replacements/SnippetTemplate.java Changeset: de84713267fa Author: Lukas Stadler Date: 2014-06-26 10:48 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/de84713267fa use default methods to select Canonicalizable behavior ! 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/spi/Canonicalizable.java ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/CanonicalizerPhase.java ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/cfs/BaseReduction.java ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/cfs/EquationalReasoner.java Changeset: ff06fc69249e Author: Lukas Stadler Date: 2014-06-26 10:50 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/ff06fc69249e small cleanup in UnsignedMathSubstitutions ! graal/com.oracle.graal.replacements/src/com/oracle/graal/replacements/UnsignedMathSubstitutions.java Changeset: c6ebc1997a55 Author: Doug Simon Date: 2014-06-26 13:42 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/c6ebc1997a55 added listener for nodes being added to a graph; consolidated all node event listeners into new NodeEventListener interface and made registering such listeners work in a try-with-resources statement so that de-registration is automatic ! 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.phases.common/src/com/oracle/graal/phases/common/CanonicalizerPhase.java ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/IncrementalCanonicalizerPhase.java ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/IterativeConditionalEliminationPhase.java ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/cfs/IterativeFlowSensitiveReductionPhase.java - graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/util/HashSetNodeChangeListener.java + graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/util/HashSetNodeEventListener.java ! graal/com.oracle.graal.virtual/src/com/oracle/graal/virtual/phases/ea/EffectsPhase.java Changeset: e9998e2be7f5 Author: Gilles Duboscq Date: 2014-06-26 18:25 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/e9998e2be7f5 use oops_do to modify saved hsail state Contributed-by: Tom Deneau + graal/com.oracle.graal.compiler.hsail.test/src/com/oracle/graal/compiler/hsail/test/BoundsCatchMost20000StressGCTest.java ! graal/com.oracle.graal.compiler.hsail.test/src/com/oracle/graal/compiler/hsail/test/lambda/ArrayListSetTest.java ! graal/com.oracle.graal.hotspot.hsail/src/com/oracle/graal/hotspot/hsail/HSAILHotSpotBackend.java ! src/gpu/hsail/vm/gpu_hsail.cpp ! src/gpu/hsail/vm/gpu_hsail.hpp ! src/gpu/hsail/vm/gpu_hsail_Frame.hpp + src/gpu/hsail/vm/gpu_hsail_OopMapHelper.hpp ! src/share/vm/classfile/javaClasses.cpp ! src/share/vm/runtime/thread.cpp ! src/share/vm/runtime/thread.hpp Changeset: fb77eab05bd3 Author: Gilles Duboscq Date: 2014-06-26 11:56 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/fb77eab05bd3 Respect the VM's wish to record non-safepoint debug info ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/CompilationTask.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/bridge/CompilerToVM.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/bridge/CompilerToVMImpl.java ! graal/com.oracle.graal.java/src/com/oracle/graal/java/GraphBuilderConfiguration.java ! src/share/vm/graal/graalCompilerToVM.cpp Changeset: 5a3d6bb7a48f Author: Gilles Duboscq Date: 2014-06-26 11:39 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/5a3d6bb7a48f Add .recommenders (Eclipse recommanders) and test.[0-9]+.er (Solaris Studio analyzser) to .hgignore ! .hgignore Changeset: 38fab08a3d9d Author: Gilles Duboscq Date: 2014-06-26 17:40 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/38fab08a3d9d Update findbugs (old version is gone from sourceforge) ! mx/projects Changeset: 0815ca9d7747 Author: Lukas Stadler Date: 2014-06-26 16:27 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/0815ca9d7747 move removeIfUnused from CanonicalizerTool to SimplifierTool ! graal/com.oracle.graal.graph/src/com/oracle/graal/graph/spi/CanonicalizerTool.java ! graal/com.oracle.graal.graph/src/com/oracle/graal/graph/spi/SimplifierTool.java ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/cfs/BaseReduction.java Changeset: b35b25c68387 Author: Lukas Stadler Date: 2014-06-26 16:27 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/b35b25c68387 returning null Canonicalizer.canonical replaces usages with null ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/CanonicalizerPhase.java Changeset: c5b2a3c22318 Author: Lukas Stadler Date: 2014-06-26 16:27 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/c5b2a3c22318 refactor more Canonicalizable implementations to not add new nodes to the graph ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/nodes/ClassGetClassLoader0Node.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/nodes/ClassGetComponentTypeNode.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/nodes/ClassGetModifiersNode.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/nodes/ClassGetSuperclassNode.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/nodes/ClassIsArrayNode.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/nodes/ClassIsInstanceNode.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/nodes/ClassIsInterfaceNode.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/nodes/ClassIsPrimitiveNode.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/ArrayCopyCallNode.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/ObjectGetClassNode.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/ReflectionGetCallerClassNode.java ! graal/com.oracle.graal.loop/src/com/oracle/graal/loop/BasicInductionVariable.java ! graal/com.oracle.graal.loop/src/com/oracle/graal/loop/DerivedOffsetInductionVariable.java ! graal/com.oracle.graal.loop/src/com/oracle/graal/loop/DerivedScaledInductionVariable.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/ConditionAnchorNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/GuardedValueNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/GuardingPiNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/calc/ConditionalNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/calc/IntegerConvertNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/extended/FloatingReadNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/extended/IndexedLocationNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/extended/UnsafeLoadNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/java/CheckCastDynamicNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/java/DynamicNewInstanceNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/java/RegisterFinalizerNode.java ! graal/com.oracle.graal.replacements.hsail/src/com/oracle/graal/replacements/hsail/HSAILMathIntrinsicsNode.java ! graal/com.oracle.graal.replacements/src/com/oracle/graal/replacements/nodes/ArrayEqualsNode.java ! graal/com.oracle.graal.replacements/src/com/oracle/graal/replacements/nodes/PureFunctionMacroNode.java ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/PartialEvaluatorCanonicalizer.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/arithmetic/IntegerAddExactNode.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/typesystem/CustomizedUnsafeLoadFinalNode.java ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/nodes/typesystem/CustomizedUnsafeLoadMacroNode.java Changeset: 9c4043105f48 Author: Lukas Stadler Date: 2014-06-26 16:27 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/9c4043105f48 make MathIntrinsicNode a UnaryNode ! graal/com.oracle.graal.replacements/src/com/oracle/graal/replacements/nodes/MathIntrinsicNode.java Changeset: 56b1e71d93ca Author: Lukas Stadler Date: 2014-06-26 16:27 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/56b1e71d93ca small cleanup in ShortCircuitOrNode ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/ShortCircuitOrNode.java Changeset: aeaad00ddce0 Author: Lukas Stadler Date: 2014-06-26 16:27 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/aeaad00ddce0 new constructor (with stateBefore) for AbstractDeoptimizeNode ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/AbstractDeoptimizeNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/DeoptimizeNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/DynamicDeoptimizeNode.java ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/GuardLoweringPhase.java Changeset: a762ddb12b43 Author: Lukas Stadler Date: 2014-06-26 16:27 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/a762ddb12b43 change some node types from Canonicalizable to Simplifiable ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/MethodHandleNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/java/CheckCastNode.java ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/nodes/typesystem/UnsafeTypeCastMacroNode.java Changeset: 614d3b9ed188 Author: Lukas Stadler Date: 2014-06-26 16:27 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/614d3b9ed188 let CanonicalizerPhase handle replacement with null in GuardNode.canonical ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/GuardNode.java Changeset: a56aabb15e98 Author: Lukas Stadler Date: 2014-06-26 16:27 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/a56aabb15e98 new constructor (with stateAfter) for StoreFieldNode ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/extended/UnsafeStoreNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/java/StoreFieldNode.java Changeset: e6919996abe9 Author: Lukas Stadler Date: 2014-06-26 16:27 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/e6919996abe9 new constructor (with nullCheck and stateBefore) for ReadNode ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/DeoptimizingFixedWithNextNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/extended/FixedAccessNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/extended/FloatableAccessNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/extended/ReadNode.java Changeset: 6f02ff62c3ef Author: Lukas Stadler Date: 2014-06-26 16:27 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/6f02ff62c3ef new constructor (with stateAfter) for UnsafeStoreNode ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/extended/UnsafeStoreNode.java ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/nodes/typesystem/CustomizedUnsafeStoreMacroNode.java Changeset: 7e87ec3d156a Author: Lukas Stadler Date: 2014-06-26 16:27 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/7e87ec3d156a enable new-node assertion for all Canonicalizable node types ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/CanonicalizerPhase.java Changeset: 3a463b85b195 Author: Lukas Stadler Date: 2014-06-26 17:29 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/3a463b85b195 fix for LoadMethodNode ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/extended/LoadMethodNode.java From tom.deneau at amd.com Fri Jun 27 23:35:26 2014 From: tom.deneau at amd.com (Deneau, Tom) Date: Fri, 27 Jun 2014 23:35:26 +0000 Subject: logic in Math.nextAfter for handling -0.0 input Message-ID: Pinging, since I never saw an answer to this. I thought there was some way to substitute for a method and still call the original method without getting into a recursive call... (The original problem below is resolved but need this kind of solution for a different reason). -- Tom -----Original Message----- From: Deneau, Tom Sent: Monday, June 23, 2014 3:43 PM To: Deneau, Tom; 'graal-dev at openjdk.java.net' Subject: RE: logic in Math.nextAfter for handling -0.0 input Related to this... Should I be able to work around this with the following hsail MethodSubstitution? When I try this, I get a StackOverflowError... -- Tom @ClassSubstitution(java.lang.Math.class) public class HSAILMathSubstitutions { ... @MethodSubstitution public static double nextAfter(double x, double direction) { // work around special case of -0.0 double xx = (x == -0.0 ? 0.0 : x); return Math.nextAfter(xx, direction); } } -----Original Message----- From: Deneau, Tom Sent: Monday, June 23, 2014 3:34 PM To: 'graal-dev at openjdk.java.net' Subject: logic in Math.nextAfter for handling -0.0 input The JDK method Math.nextAfter contains the logic shown below to handle an input of -0.0 When the graal compiler compiles this for the hsail backend, it makes the reasonable assumption that "start + 0.0d" can be reduced to "start" which is a problem for this algorithm. >From what I could tell, c2 or graal for amd64 backend do not do this optimization and so get the right answer for -0.0 input. How do they know not to do this optimization? } else { // start > direction or start < direction // Add +0.0 to get rid of a -0.0 (+0.0 + -0.0 => +0.0) // then bitwise convert start to integer. long transducer = Double.doubleToRawLongBits(start + 0.0d); <============== if (direction > start) { // Calculate next greater value transducer = transducer + (transducer >= 0L ? 1L:-1L); } else { // Calculate next lesser value .... -- Tom From tom.rodriguez at oracle.com Fri Jun 27 23:38:50 2014 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Fri, 27 Jun 2014 16:38:50 -0700 Subject: logic in Math.nextAfter for handling -0.0 input In-Reply-To: References: Message-ID: <260B14EA-1404-4276-8E9D-556F284F1BEB@oracle.com> Just call it. A call to the original method stays a real call to that method and doesn?t get substituted. tom On Jun 27, 2014, at 4:35 PM, Deneau, Tom wrote: > Pinging, since I never saw an answer to this. > > I thought there was some way to substitute for a method and still call the original method > without getting into a recursive call... > > (The original problem below is resolved but need this kind of solution for a different reason). > > -- Tom > > > -----Original Message----- > From: Deneau, Tom > Sent: Monday, June 23, 2014 3:43 PM > To: Deneau, Tom; 'graal-dev at openjdk.java.net' > Subject: RE: logic in Math.nextAfter for handling -0.0 input > > Related to this... > Should I be able to work around this with the following hsail MethodSubstitution? > When I try this, I get a StackOverflowError... > > -- Tom > > @ClassSubstitution(java.lang.Math.class) > public class HSAILMathSubstitutions { > ... > @MethodSubstitution > public static double nextAfter(double x, double direction) { > // work around special case of -0.0 > double xx = (x == -0.0 ? 0.0 : x); > return Math.nextAfter(xx, direction); > } > } > > > > > -----Original Message----- > From: Deneau, Tom > Sent: Monday, June 23, 2014 3:34 PM > To: 'graal-dev at openjdk.java.net' > Subject: logic in Math.nextAfter for handling -0.0 input > > The JDK method Math.nextAfter contains the logic shown below to handle an input of -0.0 > > When the graal compiler compiles this for the hsail backend, it makes the reasonable assumption that "start + 0.0d" can be reduced to "start" which is a problem for this algorithm. > > From what I could tell, c2 or graal for amd64 backend do not do this optimization and so get the right answer for -0.0 input. How do they know not to do this optimization? > > > } else { // start > direction or start < direction > // Add +0.0 to get rid of a -0.0 (+0.0 + -0.0 => +0.0) > // then bitwise convert start to integer. > long transducer = Double.doubleToRawLongBits(start + 0.0d); <============== > > if (direction > start) { // Calculate next greater value > transducer = transducer + (transducer >= 0L ? 1L:-1L); > } else { // Calculate next lesser value > .... > > -- Tom From tom.deneau at amd.com Fri Jun 27 23:40:35 2014 From: tom.deneau at amd.com (Deneau, Tom) Date: Fri, 27 Jun 2014 23:40:35 +0000 Subject: logic in Math.nextAfter for handling -0.0 input In-Reply-To: <260B14EA-1404-4276-8E9D-556F284F1BEB@oracle.com> References: <260B14EA-1404-4276-8E9D-556F284F1BEB@oracle.com> Message-ID: That's what I was doing below. Is the problem that we are "inlining everything" on the hsail backend? -- Tom -----Original Message----- From: Tom Rodriguez [mailto:tom.rodriguez at oracle.com] Sent: Friday, June 27, 2014 6:39 PM To: Deneau, Tom Cc: graal-dev at openjdk.java.net Subject: Re: logic in Math.nextAfter for handling -0.0 input Just call it. A call to the original method stays a real call to that method and doesn't get substituted. tom On Jun 27, 2014, at 4:35 PM, Deneau, Tom wrote: > Pinging, since I never saw an answer to this. > > I thought there was some way to substitute for a method and still call > the original method without getting into a recursive call... > > (The original problem below is resolved but need this kind of solution for a different reason). > > -- Tom > > > -----Original Message----- > From: Deneau, Tom > Sent: Monday, June 23, 2014 3:43 PM > To: Deneau, Tom; 'graal-dev at openjdk.java.net' > Subject: RE: logic in Math.nextAfter for handling -0.0 input > > Related to this... > Should I be able to work around this with the following hsail MethodSubstitution? > When I try this, I get a StackOverflowError... > > -- Tom > > @ClassSubstitution(java.lang.Math.class) > public class HSAILMathSubstitutions { > ... > @MethodSubstitution > public static double nextAfter(double x, double direction) { > // work around special case of -0.0 > double xx = (x == -0.0 ? 0.0 : x); > return Math.nextAfter(xx, direction); > } > } > > > > > -----Original Message----- > From: Deneau, Tom > Sent: Monday, June 23, 2014 3:34 PM > To: 'graal-dev at openjdk.java.net' > Subject: logic in Math.nextAfter for handling -0.0 input > > The JDK method Math.nextAfter contains the logic shown below to handle > an input of -0.0 > > When the graal compiler compiles this for the hsail backend, it makes the reasonable assumption that "start + 0.0d" can be reduced to "start" which is a problem for this algorithm. > > From what I could tell, c2 or graal for amd64 backend do not do this optimization and so get the right answer for -0.0 input. How do they know not to do this optimization? > > > } else { // start > direction or start < direction > // Add +0.0 to get rid of a -0.0 (+0.0 + -0.0 => +0.0) > // then bitwise convert start to integer. > long transducer = Double.doubleToRawLongBits(start + 0.0d); <============== > > if (direction > start) { // Calculate next greater value > transducer = transducer + (transducer >= 0L ? 1L:-1L); > } else { // Calculate next lesser value > .... > > -- Tom From tom.rodriguez at oracle.com Sat Jun 28 00:13:26 2014 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Fri, 27 Jun 2014 17:13:26 -0700 Subject: logic in Math.nextAfter for handling -0.0 input In-Reply-To: References: <260B14EA-1404-4276-8E9D-556F284F1BEB@oracle.com> Message-ID: <77C6A85E-F2E5-4362-B3AD-DAC236594C41@oracle.com> That?s supposed to work correctly. I suppose it could be because of inline everything though I?m not sure how that would trigger the problem. Can try running your problematic test case against regular graal and see if it reproduces? I?ve seen cases like this with recursive deopts. Maybe that?s what?s happening here? tom On Jun 27, 2014, at 4:40 PM, Deneau, Tom wrote: > That's what I was doing below. Is the problem that we are "inlining everything" on the hsail backend? > > -- Tom > > -----Original Message----- > From: Tom Rodriguez [mailto:tom.rodriguez at oracle.com] > Sent: Friday, June 27, 2014 6:39 PM > To: Deneau, Tom > Cc: graal-dev at openjdk.java.net > Subject: Re: logic in Math.nextAfter for handling -0.0 input > > Just call it. A call to the original method stays a real call to that method and doesn't get substituted. > > tom > > On Jun 27, 2014, at 4:35 PM, Deneau, Tom wrote: > >> Pinging, since I never saw an answer to this. >> >> I thought there was some way to substitute for a method and still call >> the original method without getting into a recursive call... >> >> (The original problem below is resolved but need this kind of solution for a different reason). >> >> -- Tom >> >> >> -----Original Message----- >> From: Deneau, Tom >> Sent: Monday, June 23, 2014 3:43 PM >> To: Deneau, Tom; 'graal-dev at openjdk.java.net' >> Subject: RE: logic in Math.nextAfter for handling -0.0 input >> >> Related to this... >> Should I be able to work around this with the following hsail MethodSubstitution? >> When I try this, I get a StackOverflowError... >> >> -- Tom >> >> @ClassSubstitution(java.lang.Math.class) >> public class HSAILMathSubstitutions { >> ... >> @MethodSubstitution >> public static double nextAfter(double x, double direction) { >> // work around special case of -0.0 >> double xx = (x == -0.0 ? 0.0 : x); >> return Math.nextAfter(xx, direction); >> } >> } >> >> >> >> >> -----Original Message----- >> From: Deneau, Tom >> Sent: Monday, June 23, 2014 3:34 PM >> To: 'graal-dev at openjdk.java.net' >> Subject: logic in Math.nextAfter for handling -0.0 input >> >> The JDK method Math.nextAfter contains the logic shown below to handle >> an input of -0.0 >> >> When the graal compiler compiles this for the hsail backend, it makes the reasonable assumption that "start + 0.0d" can be reduced to "start" which is a problem for this algorithm. >> >> From what I could tell, c2 or graal for amd64 backend do not do this optimization and so get the right answer for -0.0 input. How do they know not to do this optimization? >> >> >> } else { // start > direction or start < direction >> // Add +0.0 to get rid of a -0.0 (+0.0 + -0.0 => +0.0) >> // then bitwise convert start to integer. >> long transducer = Double.doubleToRawLongBits(start + 0.0d); <============== >> >> if (direction > start) { // Calculate next greater value >> transducer = transducer + (transducer >= 0L ? 1L:-1L); >> } else { // Calculate next lesser value >> .... >> >> -- Tom > From doug.simon at oracle.com Sat Jun 28 01:00:07 2014 From: doug.simon at oracle.com (doug.simon at oracle.com) Date: Sat, 28 Jun 2014 01:00:07 +0000 Subject: hg: graal/graal: 18 new changesets Message-ID: <201406280100.s5S108Qf023038@aojmv0008> Changeset: 639e8085323a Author: Lukas Stadler Date: 2014-06-27 10:14 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/639e8085323a JavaDoc for Canonicalizable ! graal/com.oracle.graal.graph/src/com/oracle/graal/graph/spi/Canonicalizable.java Changeset: 96fbf0582b08 Author: Bernhard Urban Date: 2014-06-27 11:25 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/96fbf0582b08 mx projects: add mirror location of external dependencies ! mx/projects Changeset: a0f66e9174e7 Author: Miguel Garcia Date: 2014-06-27 13:13 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/a0f66e9174e7 [inliner] isFreshInstantiation() was forgetting about AllocatedObjectNode ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/inlining/walker/InliningData.java Changeset: 55f369530122 Author: Bernhard Urban Date: 2014-06-27 13:17 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/55f369530122 mx archive: print warning only in verbose mode ! mxtool/mx.py Changeset: dc26b91db5a8 Author: Lukas Stadler Date: 2014-06-27 14:04 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/dc26b91db5a8 create correct stamps in IntegerDivNode and IntegerRemNode constructors ! 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 Changeset: df2fd3857607 Author: Lukas Stadler Date: 2014-06-27 14:04 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/df2fd3857607 getter for canonicalizeReads in CanonicalizerPhase ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/CanonicalizerPhase.java Changeset: 11528f64d79d Author: Lukas Stadler Date: 2014-06-27 14:04 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/11528f64d79d default implementation of CanonicalizerTool + graal/com.oracle.graal.graph/src/com/oracle/graal/graph/spi/DefaultCanonicalizerTool.java Changeset: a501d56c8656 Author: Bernhard Urban Date: 2014-06-27 16:25 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/a501d56c8656 truffle compiler: cut off assertion errors too ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/TruffleCacheImpl.java Changeset: c04bdca850a9 Author: Bernhard Urban Date: 2014-06-27 16:25 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/c04bdca850a9 truffle compiler: small cleanup ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/TruffleCacheImpl.java Changeset: 0e092c1ecd64 Author: Andreas Woess Date: 2014-06-26 18:04 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/0e092c1ecd64 JSONHelper: add builders for JSON objects and arrays ! graal/com.oracle.truffle.api/src/com/oracle/truffle/api/utilities/JSONHelper.java Changeset: f5437f2db322 Author: Andreas Woess Date: 2014-06-27 17:24 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/f5437f2db322 mx fsckprojects: do not traverse lib subdirectory ! mxtool/mx.py Changeset: d56a09df1a1f Author: Doug Simon Date: 2014-06-27 19:55 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/d56a09df1a1f implemented eager checking of Graal options (GRAAL-807) ! graal/com.oracle.graal.hotspot.sourcegen/src/com/oracle/graal/hotspot/sourcegen/GenGraalRuntimeInlineHpp.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/HotSpotOptions.java ! src/share/vm/graal/graalRuntime.cpp ! src/share/vm/graal/graalRuntime.hpp ! src/share/vm/runtime/thread.cpp Changeset: e589c26c2eb8 Author: Doug Simon Date: 2014-06-27 22:10 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/e589c26c2eb8 enforce use of boxed types for OptionDescriptor ! graal/com.oracle.graal.options/src/com/oracle/graal/options/OptionDescriptor.java Changeset: 56cd93afdc15 Author: Doug Simon Date: 2014-06-27 22:11 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/56cd93afdc15 better error message when mistaking a boolean option for a non-boolean option or vice versa ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/HotSpotOptions.java Changeset: d6ffc6164830 Author: Doug Simon Date: 2014-06-27 22:21 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/d6ffc6164830 handle any exception raised during Graal option checking/parsing, not just those with a non-null message ! src/share/vm/graal/graalRuntime.cpp ! src/share/vm/graal/graalRuntime.hpp Changeset: 60c3f610183e Author: Doug Simon Date: 2014-06-27 22:58 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/60c3f610183e separate error messages for missing versus invalid non-String option values ! src/share/vm/graal/graalRuntime.cpp Changeset: 7af7db0bbfe9 Author: Doug Simon Date: 2014-06-27 23:00 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/7af7db0bbfe9 handle unwinding exception through recursive call properly ! src/share/vm/graal/graalRuntime.cpp Changeset: 5cdcb94a7cf7 Author: Doug Simon Date: 2014-06-27 23:04 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/5cdcb94a7cf7 clarify option checking code from option parsing code ! graal/com.oracle.graal.hotspot.sourcegen/src/com/oracle/graal/hotspot/sourcegen/GenGraalRuntimeInlineHpp.java From jules_gosnell at yahoo.com Sat Jun 28 06:55:09 2014 From: jules_gosnell at yahoo.com (Jules Gosnell) Date: Sat, 28 Jun 2014 07:55:09 +0100 Subject: http://hg.openjdk.java.net/graal/graal build broken: findbugs jar missing / out of date ? In-Reply-To: <53ACABC3.2060902@oracle.com> References: <53AC9DD2.9040000@yahoo.com> <53ACABC3.2060902@oracle.com> Message-ID: <53AE66CD.2020205@yahoo.com> Thanks - all green again this morning. Jules On 27/06/14 00:24, Mick Jordan wrote: > On 6/26/14, 3:25 PM, Jules Gosnell wrote: >> ... >> Downloading >> jar:http://sourceforge.net/projects/findbugs/files/findbugs/3.0.0/findbugs-3.0.0-dev-20131204-e3cbbd5.zip/download!/findbugs-3.0.0-dev-20131204-e3cbbd5/lib/findbugs.jar >> to >> /usr/local/media/jenkins/workspace/graal/graal/lib/findbugs-3.0.0-dev-20131204-e3cbbd5.jar >> >> Error reading from >> jar:http://sourceforge.net/projects/findbugs/files/findbugs/3.0.0/findbugs-3.0.0-dev-20131204-e3cbbd5.zip/download!/findbugs-3.0.0-dev-20131204-e3cbbd5/lib/findbugs.jar: >> java.io.FileNotFoundException: >> http://sourceforge.net/projects/findbugs/files/findbugs/3.0.0/findbugs-3.0.0-dev-20131204-e3cbbd5.zip/download >> >> Exception in thread "main" java.lang.Error: Could not download content >> to >> /usr/local/media/jenkins/workspace/graal/graal/lib/findbugs-3.0.0-dev-20131204-e3cbbd5.jar >> from >> [jar:http://sourceforge.net/projects/findbugs/files/findbugs/3.0.0/findbugs-3.0.0-dev-20131204-e3cbbd5.zip/download!/findbugs-3.0.0-dev-20131204-e3cbbd5/lib/findbugs.jar] >> >> at URLConnectionDownload.main(URLConnectionDownload.java:114) >> Could not download to >> /usr/local/media/jenkins/workspace/graal/graal/lib/findbugs-3.0.0-dev-20131204-e3cbbd5.jar >> from any of the following URLs: >> >> >> jar:http://sourceforge.net/projects/findbugs/files/findbugs/3.0.0/findbugs-3.0.0-dev-20131204-e3cbbd5.zip/download!/findbugs-3.0.0-dev-20131204-e3cbbd5/lib/findbugs.jar >> >> >> Please use a web browser to do the download manually >> ... >> >> if you try to d/l the jar manually, you'll find that it is not there... >> >> I'm guessing that it has been replaced by 3.0.0 which appears to have >> been released on 2014-06-25 - i.e. yesterday - not sure why they would >> have removed the old release though ? >> > There is an update in the pipe. > > Mick > > From eric.caspole at amd.com Mon Jun 30 15:10:15 2014 From: eric.caspole at amd.com (Eric Caspole) Date: Mon, 30 Jun 2014 11:10:15 -0400 Subject: webrev: use assumeTrue to check for simulator In-Reply-To: References: Message-ID: <53B17DD7.5000901@amd.com> Anyone have time to review this? This will help our internal Sumatra testing run through clean. Thanks, Eric On 06/24/2014 10:09 AM, Caspole, Eric wrote: > Hi everybody, > I put a new webrev here: > > http://cr.openjdk.java.net/~ecaspole/reduce_no_sim/webrev/ > > The reduce tests already checked in only work when built using the Sumatra JDK and -Dcom.amd.sumatra.offload.immediate=true is used. The HSAIL Simulator does not support HSA group/local memory at this time, so if you run the tests with the JDK and the flag under the simulator, they will fail. Here I added "assumeTrue" to skip the test if running on the simulator which makes it easier for me to work with and test the Sumatra JDK. > This change will have no effect when you build Graal using plain JDK 8 since it will not offload the reduce operations. > Regards, > Eric > From doug.simon at oracle.com Mon Jun 30 15:55:59 2014 From: doug.simon at oracle.com (Doug Simon) Date: Mon, 30 Jun 2014 17:55:59 +0200 Subject: webrev: use assumeTrue to check for simulator In-Reply-To: <53B17DD7.5000901@amd.com> References: <53B17DD7.5000901@amd.com> Message-ID: Looks ok to me - I?ll integrate it. On Jun 30, 2014, at 5:10 PM, Eric Caspole wrote: > Anyone have time to review this? This will help our internal Sumatra testing run through clean. > Thanks, > Eric > > > On 06/24/2014 10:09 AM, Caspole, Eric wrote: >> Hi everybody, >> I put a new webrev here: >> >> http://cr.openjdk.java.net/~ecaspole/reduce_no_sim/webrev/ >> >> The reduce tests already checked in only work when built using the Sumatra JDK and -Dcom.amd.sumatra.offload.immediate=true is used. The HSAIL Simulator does not support HSA group/local memory at this time, so if you run the tests with the JDK and the flag under the simulator, they will fail. Here I added "assumeTrue" to skip the test if running on the simulator which makes it easier for me to work with and test the Sumatra JDK. >> This change will have no effect when you build Graal using plain JDK 8 since it will not offload the reduce operations. >> Regards, >> Eric >> From tom.deneau at amd.com Mon Jun 30 16:28:26 2014 From: tom.deneau at amd.com (Deneau, Tom) Date: Mon, 30 Jun 2014 16:28:26 +0000 Subject: logic in Math.nextAfter for handling -0.0 input In-Reply-To: <77C6A85E-F2E5-4362-B3AD-DAC236594C41@oracle.com> References: <260B14EA-1404-4276-8E9D-556F284F1BEB@oracle.com> <77C6A85E-F2E5-4362-B3AD-DAC236594C41@oracle.com> Message-ID: OK, I took the LongSubstitutions.java which were already part of the AMD64 backend. I made the following (garbage) change just to see what code got generated... @MethodSubstitution public static int numberOfTrailingZeros(long i) { if (i == 0) { return 67; } return 13 + Long.numberOfTrailingZeros(i); // return BitScanForwardNode.scan(i); } Then I tried the junit test shown below to get it to compile... I ran this test using mx --vm server --vmbuild product unittest BasicTest3 and got similar output that I got with the HSAIL backend. (output shown below the source code...) -- Tom ========================================================== package com.oracle.graal.compiler.test; import org.junit.*; import com.oracle.graal.api.code.*; import com.oracle.graal.debug.*; import com.oracle.graal.nodes.*; import java.util.concurrent.atomic.AtomicInteger; import java.util.concurrent.atomic.AtomicReference; public class BasicTest3 extends GraalCompilerTest { @Test public void testitNTZ() { test("numTrailingZeros7"); } public int numTrailingZeros7(long x) { return Long.numberOfTrailingZeros(x) + 7; } private void test(String snippet) { StructuredGraph graph = parse(snippet); InstalledCode code = getCode(graph.method(), graph); Debug.dump(graph, "Graph"); // DisassemblerProvider dis = Graal.getRuntime().getCapability(DisassemblerProvider.class); DisassemblerProvider dis = getBackend().getDisassembler(); if (dis != null) { String disasm = dis.disassemble(code); TTY.println("code generated for " + snippet + "\n" + disasm); } else { System.out.println("disassembler is null"); } } } ========================================================== java.lang.RuntimeException: Exception while intercepting exception at com.oracle.graal.debug.internal.DebugScope.interceptException(DebugScope.java:314) at com.oracle.graal.debug.internal.DebugScope.handle(DebugScope.java:265) at com.oracle.graal.debug.Debug.handle(Debug.java:343) at com.oracle.graal.replacements.ReplacementsImpl$GraphMaker.makeGraph(ReplacementsImpl.java:475) at com.oracle.graal.replacements.ReplacementsImpl.makeGraph(ReplacementsImpl.java:410) at com.oracle.graal.replacements.ReplacementsImpl.getMethodSubstitution(ReplacementsImpl.java:281) at com.oracle.graal.phases.common.inlining.InliningUtil.getIntrinsicGraph(InliningUtil.java:500) at com.oracle.graal.replacements.ReplacementsImpl$GraphMaker.buildGraph(ReplacementsImpl.java:612) at com.oracle.graal.replacements.ReplacementsImpl$GraphMaker.parseGraph(ReplacementsImpl.java:514) at com.oracle.graal.replacements.ReplacementsImpl$GraphMaker.makeGraph(ReplacementsImpl.java:464) at com.oracle.graal.replacements.ReplacementsImpl.makeGraph(ReplacementsImpl.java:410) at com.oracle.graal.replacements.ReplacementsImpl.getMethodSubstitution(ReplacementsImpl.java:281) at com.oracle.graal.phases.common.inlining.InliningUtil.getIntrinsicGraph(InliningUtil.java:500) at com.oracle.graal.replacements.ReplacementsImpl$GraphMaker.buildGraph(ReplacementsImpl.java:612) at com.oracle.graal.replacements.ReplacementsImpl$GraphMaker.parseGraph(ReplacementsImpl.java:514) at com.oracle.graal.replacements.ReplacementsImpl$GraphMaker.makeGraph(ReplacementsImpl.java:464) at com.oracle.graal.replacements.ReplacementsImpl.makeGraph(ReplacementsImpl.java:410) at com.oracle.graal.replacements.ReplacementsImpl.getMethodSubstitution(ReplacementsImpl.java:281) [ ... repeating many times ...] -----Original Message----- From: Tom Rodriguez [mailto:tom.rodriguez at oracle.com] Sent: Friday, June 27, 2014 7:13 PM To: Deneau, Tom Cc: graal-dev at openjdk.java.net Subject: Re: logic in Math.nextAfter for handling -0.0 input That's supposed to work correctly. I suppose it could be because of inline everything though I'm not sure how that would trigger the problem. Can try running your problematic test case against regular graal and see if it reproduces? I've seen cases like this with recursive deopts. Maybe that's what's happening here? tom On Jun 27, 2014, at 4:40 PM, Deneau, Tom wrote: > That's what I was doing below. Is the problem that we are "inlining everything" on the hsail backend? > > -- Tom > > -----Original Message----- > From: Tom Rodriguez [mailto:tom.rodriguez at oracle.com] > Sent: Friday, June 27, 2014 6:39 PM > To: Deneau, Tom > Cc: graal-dev at openjdk.java.net > Subject: Re: logic in Math.nextAfter for handling -0.0 input > > Just call it. A call to the original method stays a real call to that method and doesn't get substituted. > > tom > > On Jun 27, 2014, at 4:35 PM, Deneau, Tom wrote: > >> Pinging, since I never saw an answer to this. >> >> I thought there was some way to substitute for a method and still call >> the original method without getting into a recursive call... >> >> (The original problem below is resolved but need this kind of solution for a different reason). >> >> -- Tom >> >> >> -----Original Message----- >> From: Deneau, Tom >> Sent: Monday, June 23, 2014 3:43 PM >> To: Deneau, Tom; 'graal-dev at openjdk.java.net' >> Subject: RE: logic in Math.nextAfter for handling -0.0 input >> >> Related to this... >> Should I be able to work around this with the following hsail MethodSubstitution? >> When I try this, I get a StackOverflowError... >> >> -- Tom >> >> @ClassSubstitution(java.lang.Math.class) >> public class HSAILMathSubstitutions { >> ... >> @MethodSubstitution >> public static double nextAfter(double x, double direction) { >> // work around special case of -0.0 >> double xx = (x == -0.0 ? 0.0 : x); >> return Math.nextAfter(xx, direction); >> } >> } >> >> >> >> >> -----Original Message----- >> From: Deneau, Tom >> Sent: Monday, June 23, 2014 3:34 PM >> To: 'graal-dev at openjdk.java.net' >> Subject: logic in Math.nextAfter for handling -0.0 input >> >> The JDK method Math.nextAfter contains the logic shown below to handle >> an input of -0.0 >> >> When the graal compiler compiles this for the hsail backend, it makes the reasonable assumption that "start + 0.0d" can be reduced to "start" which is a problem for this algorithm. >> >> From what I could tell, c2 or graal for amd64 backend do not do this optimization and so get the right answer for -0.0 input. How do they know not to do this optimization? >> >> >> } else { // start > direction or start < direction >> // Add +0.0 to get rid of a -0.0 (+0.0 + -0.0 => +0.0) >> // then bitwise convert start to integer. >> long transducer = Double.doubleToRawLongBits(start + 0.0d); <============== >> >> if (direction > start) { // Calculate next greater value >> transducer = transducer + (transducer >= 0L ? 1L:-1L); >> } else { // Calculate next lesser value >> .... >> >> -- Tom > From doug.simon at oracle.com Mon Jun 30 17:09:15 2014 From: doug.simon at oracle.com (doug.simon at oracle.com) Date: Mon, 30 Jun 2014 17:09:15 +0000 Subject: hg: graal/graal: 26 new changesets Message-ID: <201406301709.s5UH9HDF002922@aojmv0008> Changeset: 2bcba15fa725 Author: Josef Eisl Date: 2014-06-25 15:04 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/2bcba15fa725 Introduce LIRInstructionClass.Position. ! graal/com.oracle.graal.lir/src/com/oracle/graal/lir/LIRInstruction.java ! graal/com.oracle.graal.lir/src/com/oracle/graal/lir/LIRInstructionClass.java Changeset: 7a1dee389497 Author: Josef Eisl Date: 2014-06-25 15:11 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/7a1dee389497 Rename LIRInstructionClass.Position to ValuePosition to avoid confusion with NodeClass.Position. ! graal/com.oracle.graal.lir/src/com/oracle/graal/lir/LIRInstructionClass.java Changeset: 69b9980ff5c2 Author: Josef Eisl Date: 2014-06-25 15:30 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/69b9980ff5c2 Add ValuePositionProcedure and corresponding forEach methods. ! graal/com.oracle.graal.lir/src/com/oracle/graal/lir/LIRInstruction.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 Changeset: 266db8cf4dc6 Author: Josef Eisl Date: 2014-06-25 16:15 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/266db8cf4dc6 Add LIRInstruction.forEach*(ValuePositionProcedure proc). ! graal/com.oracle.graal.lir/src/com/oracle/graal/lir/LIRInstruction.java Changeset: 14e56cef5be8 Author: Josef Eisl Date: 2014-06-25 19:23 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/14e56cef5be8 Start to make ValuePosition aware of CompositeValues. ! graal/com.oracle.graal.lir/src/com/oracle/graal/lir/CompositeValue.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 Changeset: aabd00bc6028 Author: Josef Eisl Date: 2014-06-25 20:15 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/aabd00bc6028 Move ValuePosition into LIRIntrospection. ! graal/com.oracle.graal.lir/src/com/oracle/graal/lir/CompositeValue.java ! graal/com.oracle.graal.lir/src/com/oracle/graal/lir/CompositeValueClass.java ! graal/com.oracle.graal.lir/src/com/oracle/graal/lir/LIRInstruction.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 Changeset: d59e68286d60 Author: Josef Eisl Date: 2014-06-25 20:27 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/d59e68286d60 Move ValuePosition into a dedicated file. ! graal/com.oracle.graal.lir/src/com/oracle/graal/lir/CompositeValue.java ! graal/com.oracle.graal.lir/src/com/oracle/graal/lir/LIRInstruction.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 Changeset: 96a088675c48 Author: Josef Eisl Date: 2014-06-25 20:39 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/96a088675c48 Add ValuePosition.isCompositePosition(). ! graal/com.oracle.graal.lir/src/com/oracle/graal/lir/ValuePosition.java Changeset: ad197a92e25e Author: Josef Eisl Date: 2014-06-26 11:19 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/ad197a92e25e Fix ValuePosition.set() issues. ! graal/com.oracle.graal.lir/src/com/oracle/graal/lir/LIRIntrospection.java ! graal/com.oracle.graal.lir/src/com/oracle/graal/lir/ValuePosition.java Changeset: 95e147b30dd0 Author: Josef Eisl Date: 2014-06-26 12:01 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/95e147b30dd0 Add graal.test project and ValuePositionTest. + graal/com.oracle.graal.lir.test/src/com/oracle/graal/lir/test/ValuePositionTest.java ! mx/projects Changeset: 90046b8aae8a Author: Josef Eisl Date: 2014-06-26 12:03 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/90046b8aae8a Fix ValuePosition recursive lookup issue for CompositeValues. ! graal/com.oracle.graal.lir/src/com/oracle/graal/lir/ValuePosition.java Changeset: b58855f3990e Author: Josef Eisl Date: 2014-06-26 13:22 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/b58855f3990e Add and improve ValuePositionTest. - graal/com.oracle.graal.lir.test/src/com/oracle/graal/lir/test/ValuePositionTest.java + graal/com.oracle.graal.lir.test/src/com/oracle/graal/lir/test/ValuePositionTest1.java + graal/com.oracle.graal.lir.test/src/com/oracle/graal/lir/test/ValuePositionTest2.java Changeset: b2b362cc1a9f Author: Josef Eisl Date: 2014-06-26 13:26 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/b2b362cc1a9f Rename ValuePosition.superPosition to outerPosition. ! graal/com.oracle.graal.lir/src/com/oracle/graal/lir/CompositeValue.java ! graal/com.oracle.graal.lir/src/com/oracle/graal/lir/CompositeValueClass.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 Changeset: e6622e77e8c7 Author: Lukas Stadler Date: 2014-06-30 11:38 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/e6622e77e8c7 split MacroNode into MacroNode and MacroStateSplitNode ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/nodes/ClassCastNode.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/nodes/ClassGetClassLoader0Node.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/CallSiteTargetNode.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/MethodHandleNode.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/ObjectCloneNode.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/ReflectionGetCallerClassNode.java ! graal/com.oracle.graal.replacements/src/com/oracle/graal/replacements/nodes/MacroNode.java + graal/com.oracle.graal.replacements/src/com/oracle/graal/replacements/nodes/MacroStateSplitNode.java ! graal/com.oracle.graal.replacements/src/com/oracle/graal/replacements/nodes/PureFunctionMacroNode.java ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/nodes/AssumptionNode.java ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/nodes/BailoutNode.java ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/nodes/asserts/NeverInlineMacroNode.java ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/nodes/asserts/NeverPartOfCompilationNode.java ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/nodes/typesystem/CustomizedUnsafeStoreMacroNode.java Changeset: da8f16efaa4c Author: Christian Wirth Date: 2014-06-30 15:45 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/da8f16efaa4c explicit conversion to (int), fixes Windows build ! src/share/vm/graal/graalRuntime.cpp Changeset: 81e4af185dd6 Author: Lukas Stadler Date: 2014-06-30 16:14 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/81e4af185dd6 add predecessors to worklist during MergeNode splitting ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/MergeNode.java Changeset: 95c174d0c532 Author: Doug Simon Date: 2014-06-27 11:59 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/95c174d0c532 removed legacy GraphEvent[Log] code ! graal/com.oracle.graal.graph/src/com/oracle/graal/graph/Graph.java - graal/com.oracle.graal.graph/src/com/oracle/graal/graph/GraphEvent.java - graal/com.oracle.graal.graph/src/com/oracle/graal/graph/GraphEventLog.java Changeset: 443411840041 Author: Doug Simon Date: 2014-06-27 13:38 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/443411840041 include added nodes to those canonicalized by the EffectsPhase after effects have been applied ! graal/com.oracle.graal.virtual/src/com/oracle/graal/virtual/phases/ea/EffectsPhase.java Changeset: d9de8f5197e1 Author: Doug Simon Date: 2014-06-27 13:39 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/d9de8f5197e1 simplified NodeEventListener implementations by having all events routed to a single method by default ! graal/com.oracle.graal.graph/src/com/oracle/graal/graph/Graph.java ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/IterativeConditionalEliminationPhase.java ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/cfs/IterativeFlowSensitiveReductionPhase.java ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/util/HashSetNodeEventListener.java Changeset: f2d75b3b3963 Author: Doug Simon Date: 2014-06-30 15:43 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/f2d75b3b3963 fixed incorrect forwarding of ZERO_USAGEs event in ChainedNodeEventListener ! graal/com.oracle.graal.graph/src/com/oracle/graal/graph/Graph.java Changeset: b9236eaecf4c Author: Doug Simon Date: 2014-06-30 17:23 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/b9236eaecf4c simplified DebugVerifyHandler API to be closer to DebugDumpHandler ! graal/com.oracle.graal.debug/src/com/oracle/graal/debug/Debug.java ! graal/com.oracle.graal.debug/src/com/oracle/graal/debug/DebugVerifyHandler.java ! graal/com.oracle.graal.debug/src/com/oracle/graal/debug/internal/DebugScope.java ! graal/com.oracle.graal.phases/src/com/oracle/graal/phases/BasePhase.java ! graal/com.oracle.graal.printer/src/com/oracle/graal/printer/NoDeadCodeVerifyHandler.java Changeset: 3e4c83ac68d2 Author: Doug Simon Date: 2014-06-30 17:24 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/3e4c83ac68d2 improved javadoc ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/util/HashSetNodeEventListener.java Changeset: 732a9e80e8dc Author: Doug Simon Date: 2014-06-30 17:27 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/732a9e80e8dc ensure memory map (if any) for a snippet template is attached to the returnNode ! graal/com.oracle.graal.replacements/src/com/oracle/graal/replacements/SnippetTemplate.java Changeset: 8da760bd1575 Author: Doug Simon Date: 2014-06-30 17:28 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/8da760bd1575 Merge. Changeset: b741f44cb277 Author: Doug Simon Date: 2014-06-30 17:47 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/b741f44cb277 filter out subsequent reports for phases that don't clean up their own dead nodes ! graal/com.oracle.graal.printer/src/com/oracle/graal/printer/NoDeadCodeVerifyHandler.java Changeset: fb90ad461cdb Author: Doug Simon Date: 2014-06-30 18:03 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/fb90ad461cdb HSAIL: skip certain tests if running on the HSAIL simulator Contributed-by: Eric Caspole ! graal/com.oracle.graal.compiler.hsail.test/src/com/oracle/graal/compiler/hsail/test/lambda/ReduceMaxTest.java ! graal/com.oracle.graal.compiler.hsail.test/src/com/oracle/graal/compiler/hsail/test/lambda/ReduceMinTest.java ! graal/com.oracle.graal.compiler.hsail.test/src/com/oracle/graal/compiler/hsail/test/lambda/ReduceSumTest.java From tom.rodriguez at oracle.com Mon Jun 30 17:16:42 2014 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Mon, 30 Jun 2014 10:16:42 -0700 Subject: logic in Math.nextAfter for handling -0.0 input In-Reply-To: <77C6A85E-F2E5-4362-B3AD-DAC236594C41@oracle.com> References: <260B14EA-1404-4276-8E9D-556F284F1BEB@oracle.com> <77C6A85E-F2E5-4362-B3AD-DAC236594C41@oracle.com> Message-ID: <4B1AFC14-7F31-401B-BEE6-1A5AAA0045EF@oracle.com> The meaning of ?just call it? is the problem here. Currently the logic in ReplacementsImpl.java around line 595 is looking for a call to the substitution method and replacing that with an inline of the original method. It?s not looking for invokes of the original method. So if you write your replacement like this: @MethodSubstitution public static double nextAfter(double x, double direction) { // work around special case of -0.0 double xx = (x == -0.0 ? 0.0 : x); return Math.nextAfter(xx, direction); } it will stack overflow like you are seeing because it's recursively trying to do the method substitution. If you remove the ?Math.? part then it will look like a recursive call to the substitution method and be handled by replacing the call with the original Math.nextAfter code. I?ll fix the code to properly handle calling either the original method or the substitution method so this works as expected. tom On Jun 27, 2014, at 5:13 PM, Tom Rodriguez wrote: > That?s supposed to work correctly. I suppose it could be because of inline everything though I?m not sure how that would trigger the problem. Can try running your problematic test case against regular graal and see if it reproduces? > > I?ve seen cases like this with recursive deopts. Maybe that?s what?s happening here? > > tom > > On Jun 27, 2014, at 4:40 PM, Deneau, Tom wrote: > >> That's what I was doing below. Is the problem that we are "inlining everything" on the hsail backend? >> >> -- Tom >> >> -----Original Message----- >> From: Tom Rodriguez [mailto:tom.rodriguez at oracle.com] >> Sent: Friday, June 27, 2014 6:39 PM >> To: Deneau, Tom >> Cc: graal-dev at openjdk.java.net >> Subject: Re: logic in Math.nextAfter for handling -0.0 input >> >> Just call it. A call to the original method stays a real call to that method and doesn't get substituted. >> >> tom >> >> On Jun 27, 2014, at 4:35 PM, Deneau, Tom wrote: >> >>> Pinging, since I never saw an answer to this. >>> >>> I thought there was some way to substitute for a method and still call >>> the original method without getting into a recursive call... >>> >>> (The original problem below is resolved but need this kind of solution for a different reason). >>> >>> -- Tom >>> >>> >>> -----Original Message----- >>> From: Deneau, Tom >>> Sent: Monday, June 23, 2014 3:43 PM >>> To: Deneau, Tom; 'graal-dev at openjdk.java.net' >>> Subject: RE: logic in Math.nextAfter for handling -0.0 input >>> >>> Related to this... >>> Should I be able to work around this with the following hsail MethodSubstitution? >>> When I try this, I get a StackOverflowError... >>> >>> -- Tom >>> >>> @ClassSubstitution(java.lang.Math.class) >>> public class HSAILMathSubstitutions { >>> ... >>> @MethodSubstitution >>> public static double nextAfter(double x, double direction) { >>> // work around special case of -0.0 >>> double xx = (x == -0.0 ? 0.0 : x); >>> return Math.nextAfter(xx, direction); >>> } >>> } >>> >>> >>> >>> >>> -----Original Message----- >>> From: Deneau, Tom >>> Sent: Monday, June 23, 2014 3:34 PM >>> To: 'graal-dev at openjdk.java.net' >>> Subject: logic in Math.nextAfter for handling -0.0 input >>> >>> The JDK method Math.nextAfter contains the logic shown below to handle >>> an input of -0.0 >>> >>> When the graal compiler compiles this for the hsail backend, it makes the reasonable assumption that "start + 0.0d" can be reduced to "start" which is a problem for this algorithm. >>> >>> From what I could tell, c2 or graal for amd64 backend do not do this optimization and so get the right answer for -0.0 input. How do they know not to do this optimization? >>> >>> >>> } else { // start > direction or start < direction >>> // Add +0.0 to get rid of a -0.0 (+0.0 + -0.0 => +0.0) >>> // then bitwise convert start to integer. >>> long transducer = Double.doubleToRawLongBits(start + 0.0d); <============== >>> >>> if (direction > start) { // Calculate next greater value >>> transducer = transducer + (transducer >= 0L ? 1L:-1L); >>> } else { // Calculate next lesser value >>> .... >>> >>> -- Tom >> > From tom.deneau at amd.com Mon Jun 30 17:42:32 2014 From: tom.deneau at amd.com (Deneau, Tom) Date: Mon, 30 Jun 2014 17:42:32 +0000 Subject: logic in Math.nextAfter for handling -0.0 input In-Reply-To: <4B1AFC14-7F31-401B-BEE6-1A5AAA0045EF@oracle.com> References: <260B14EA-1404-4276-8E9D-556F284F1BEB@oracle.com> <77C6A85E-F2E5-4362-B3AD-DAC236594C41@oracle.com> <4B1AFC14-7F31-401B-BEE6-1A5AAA0045EF@oracle.com> Message-ID: Thanks, Tom, I will give this a try... From: Tom Rodriguez [mailto:tom.rodriguez at oracle.com] Sent: Monday, June 30, 2014 12:17 PM To: Deneau, Tom Cc: graal-dev at openjdk.java.net Subject: Re: logic in Math.nextAfter for handling -0.0 input The meaning of "just call it" is the problem here. Currently the logic in ReplacementsImpl.java around line 595 is looking for a call to the substitution method and replacing that with an inline of the original method. It's not looking for invokes of the original method. So if you write your replacement like this: @MethodSubstitution public static double nextAfter(double x, double direction) { // work around special case of -0.0 double xx = (x == -0.0 ? 0.0 : x); return Math.nextAfter(xx, direction); } it will stack overflow like you are seeing because it's recursively trying to do the method substitution. If you remove the "Math." part then it will look like a recursive call to the substitution method and be handled by replacing the call with the original Math.nextAfter code. I'll fix the code to properly handle calling either the original method or the substitution method so this works as expected. tom On Jun 27, 2014, at 5:13 PM, Tom Rodriguez > wrote: That's supposed to work correctly. I suppose it could be because of inline everything though I'm not sure how that would trigger the problem. Can try running your problematic test case against regular graal and see if it reproduces? I've seen cases like this with recursive deopts. Maybe that's what's happening here? tom On Jun 27, 2014, at 4:40 PM, Deneau, Tom > wrote: That's what I was doing below. Is the problem that we are "inlining everything" on the hsail backend? -- Tom -----Original Message----- From: Tom Rodriguez [mailto:tom.rodriguez at oracle.com] Sent: Friday, June 27, 2014 6:39 PM To: Deneau, Tom Cc: graal-dev at openjdk.java.net Subject: Re: logic in Math.nextAfter for handling -0.0 input Just call it. A call to the original method stays a real call to that method and doesn't get substituted. tom On Jun 27, 2014, at 4:35 PM, Deneau, Tom > wrote: Pinging, since I never saw an answer to this. I thought there was some way to substitute for a method and still call the original method without getting into a recursive call... (The original problem below is resolved but need this kind of solution for a different reason). -- Tom -----Original Message----- From: Deneau, Tom Sent: Monday, June 23, 2014 3:43 PM To: Deneau, Tom; 'graal-dev at openjdk.java.net' Subject: RE: logic in Math.nextAfter for handling -0.0 input Related to this... Should I be able to work around this with the following hsail MethodSubstitution? When I try this, I get a StackOverflowError... -- Tom @ClassSubstitution(java.lang.Math.class) public class HSAILMathSubstitutions { ... @MethodSubstitution public static double nextAfter(double x, double direction) { // work around special case of -0.0 double xx = (x == -0.0 ? 0.0 : x); return Math.nextAfter(xx, direction); } } -----Original Message----- From: Deneau, Tom Sent: Monday, June 23, 2014 3:34 PM To: 'graal-dev at openjdk.java.net' Subject: logic in Math.nextAfter for handling -0.0 input The JDK method Math.nextAfter contains the logic shown below to handle an input of -0.0 When the graal compiler compiles this for the hsail backend, it makes the reasonable assumption that "start + 0.0d" can be reduced to "start" which is a problem for this algorithm. >From what I could tell, c2 or graal for amd64 backend do not do this optimization and so get the right answer for -0.0 input. How do they know not to do this optimization? } else { // start > direction or start < direction // Add +0.0 to get rid of a -0.0 (+0.0 + -0.0 => +0.0) // then bitwise convert start to integer. long transducer = Double.doubleToRawLongBits(start + 0.0d); <============== if (direction > start) { // Calculate next greater value transducer = transducer + (transducer >= 0L ? 1L:-1L); } else { // Calculate next lesser value .... -- Tom From tom.deneau at amd.com Mon Jun 30 18:20:48 2014 From: tom.deneau at amd.com (Deneau, Tom) Date: Mon, 30 Jun 2014 18:20:48 +0000 Subject: logic in Math.nextAfter for handling -0.0 input In-Reply-To: References: <260B14EA-1404-4276-8E9D-556F284F1BEB@oracle.com> <77C6A85E-F2E5-4362-B3AD-DAC236594C41@oracle.com> <4B1AFC14-7F31-401B-BEE6-1A5AAA0045EF@oracle.com> Message-ID: This calling back to the original method as Tom Rodriguez suggested seemed to work fine for some substitutions, but then I hit this one which I don't really understand. @MethodSubstitution public static double nextAfter(double x, double direction) { double input = (x == -0.0 ? 0.0 : x); return nextAfter(input, direction); } java.lang.AssertionError: deleted side effecting node at com.oracle.graal.replacements.ReplacementsImpl$GraphMaker.finalizeGraph(ReplacementsImpl.java:489) at com.oracle.graal.replacements.ReplacementsImpl$GraphMaker.makeGraph(ReplacementsImpl.java:468) at com.oracle.graal.replacements.ReplacementsImpl.makeGraph(ReplacementsImpl.java:409) at com.oracle.graal.replacements.ReplacementsImpl.getMethodSubstitution(ReplacementsImpl.java:281) at com.oracle.graal.hotspot.hsail.HSAILHotSpotReplacementsImpl.getMethodSubstitution(HSAILHotSpotReplacementsImpl.java:132) at com.oracle.graal.phases.common.inlining.InliningUtil.getIntrinsicGraph(InliningUtil.java:500) at com.oracle.graal.phases.common.inlining.info.elem.InlineableGraph.getOriginalGraph(InlineableGraph.java:72) at com.oracle.graal.phases.common.inlining.info.elem.InlineableGraph.(InlineableGraph.java:60) at com.oracle.graal.phases.common.inlining.info.elem.Inlineable.getInlineableElement(Inlineable.java:41) -----Original Message----- From: graal-dev [mailto:graal-dev-bounces at openjdk.java.net] On Behalf Of Deneau, Tom Sent: Monday, June 30, 2014 12:43 PM To: Tom Rodriguez Cc: graal-dev at openjdk.java.net Subject: RE: logic in Math.nextAfter for handling -0.0 input Thanks, Tom, I will give this a try... From: Tom Rodriguez [mailto:tom.rodriguez at oracle.com] Sent: Monday, June 30, 2014 12:17 PM To: Deneau, Tom Cc: graal-dev at openjdk.java.net Subject: Re: logic in Math.nextAfter for handling -0.0 input The meaning of "just call it" is the problem here. Currently the logic in ReplacementsImpl.java around line 595 is looking for a call to the substitution method and replacing that with an inline of the original method. It's not looking for invokes of the original method. So if you write your replacement like this: @MethodSubstitution public static double nextAfter(double x, double direction) { // work around special case of -0.0 double xx = (x == -0.0 ? 0.0 : x); return Math.nextAfter(xx, direction); } it will stack overflow like you are seeing because it's recursively trying to do the method substitution. If you remove the "Math." part then it will look like a recursive call to the substitution method and be handled by replacing the call with the original Math.nextAfter code. I'll fix the code to properly handle calling either the original method or the substitution method so this works as expected. tom On Jun 27, 2014, at 5:13 PM, Tom Rodriguez > wrote: That's supposed to work correctly. I suppose it could be because of inline everything though I'm not sure how that would trigger the problem. Can try running your problematic test case against regular graal and see if it reproduces? I've seen cases like this with recursive deopts. Maybe that's what's happening here? tom On Jun 27, 2014, at 4:40 PM, Deneau, Tom > wrote: That's what I was doing below. Is the problem that we are "inlining everything" on the hsail backend? -- Tom -----Original Message----- From: Tom Rodriguez [mailto:tom.rodriguez at oracle.com] Sent: Friday, June 27, 2014 6:39 PM To: Deneau, Tom Cc: graal-dev at openjdk.java.net Subject: Re: logic in Math.nextAfter for handling -0.0 input Just call it. A call to the original method stays a real call to that method and doesn't get substituted. tom On Jun 27, 2014, at 4:35 PM, Deneau, Tom > wrote: Pinging, since I never saw an answer to this. I thought there was some way to substitute for a method and still call the original method without getting into a recursive call... (The original problem below is resolved but need this kind of solution for a different reason). -- Tom -----Original Message----- From: Deneau, Tom Sent: Monday, June 23, 2014 3:43 PM To: Deneau, Tom; 'graal-dev at openjdk.java.net' Subject: RE: logic in Math.nextAfter for handling -0.0 input Related to this... Should I be able to work around this with the following hsail MethodSubstitution? When I try this, I get a StackOverflowError... -- Tom @ClassSubstitution(java.lang.Math.class) public class HSAILMathSubstitutions { ... @MethodSubstitution public static double nextAfter(double x, double direction) { // work around special case of -0.0 double xx = (x == -0.0 ? 0.0 : x); return Math.nextAfter(xx, direction); } } -----Original Message----- From: Deneau, Tom Sent: Monday, June 23, 2014 3:34 PM To: 'graal-dev at openjdk.java.net' Subject: logic in Math.nextAfter for handling -0.0 input The JDK method Math.nextAfter contains the logic shown below to handle an input of -0.0 When the graal compiler compiles this for the hsail backend, it makes the reasonable assumption that "start + 0.0d" can be reduced to "start" which is a problem for this algorithm. >From what I could tell, c2 or graal for amd64 backend do not do this optimization and so get the right answer for -0.0 input. How do they know not to do this optimization? } else { // start > direction or start < direction // Add +0.0 to get rid of a -0.0 (+0.0 + -0.0 => +0.0) // then bitwise convert start to integer. long transducer = Double.doubleToRawLongBits(start + 0.0d); <============== if (direction > start) { // Calculate next greater value transducer = transducer + (transducer >= 0L ? 1L:-1L); } else { // Calculate next lesser value .... -- Tom From tom.rodriguez at oracle.com Mon Jun 30 18:23:07 2014 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Mon, 30 Jun 2014 11:23:07 -0700 Subject: logic in Math.nextAfter for handling -0.0 input In-Reply-To: References: <260B14EA-1404-4276-8E9D-556F284F1BEB@oracle.com> <77C6A85E-F2E5-4362-B3AD-DAC236594C41@oracle.com> <4B1AFC14-7F31-401B-BEE6-1A5AAA0045EF@oracle.com> Message-ID: <57C608D1-E073-4415-AFD2-500232888A55@oracle.com> Yes, this is something I?ll be fixing as well. We?re being very conservative about what we allow to be deleted from snippets but when preparing method substitutions we can end up inlining asserts which will get trimmed away and that?s ok. I?ll be fixing that. You can disable that assert until I push my fix. tom On Jun 30, 2014, at 11:20 AM, Deneau, Tom wrote: > This calling back to the original method as Tom Rodriguez suggested seemed to work fine for some substitutions, but then I hit this one which I don't really understand. > > @MethodSubstitution > public static double nextAfter(double x, double direction) { > double input = (x == -0.0 ? 0.0 : x); > return nextAfter(input, direction); > } > > > java.lang.AssertionError: deleted side effecting node > at com.oracle.graal.replacements.ReplacementsImpl$GraphMaker.finalizeGraph(ReplacementsImpl.java:489) > at com.oracle.graal.replacements.ReplacementsImpl$GraphMaker.makeGraph(ReplacementsImpl.java:468) > at com.oracle.graal.replacements.ReplacementsImpl.makeGraph(ReplacementsImpl.java:409) > at com.oracle.graal.replacements.ReplacementsImpl.getMethodSubstitution(ReplacementsImpl.java:281) > at com.oracle.graal.hotspot.hsail.HSAILHotSpotReplacementsImpl.getMethodSubstitution(HSAILHotSpotReplacementsImpl.java:132) > at com.oracle.graal.phases.common.inlining.InliningUtil.getIntrinsicGraph(InliningUtil.java:500) > at com.oracle.graal.phases.common.inlining.info.elem.InlineableGraph.getOriginalGraph(InlineableGraph.java:72) > at com.oracle.graal.phases.common.inlining.info.elem.InlineableGraph.(InlineableGraph.java:60) > at com.oracle.graal.phases.common.inlining.info.elem.Inlineable.getInlineableElement(Inlineable.java:41) > > -----Original Message----- > From: graal-dev [mailto:graal-dev-bounces at openjdk.java.net] On Behalf Of Deneau, Tom > Sent: Monday, June 30, 2014 12:43 PM > To: Tom Rodriguez > Cc: graal-dev at openjdk.java.net > Subject: RE: logic in Math.nextAfter for handling -0.0 input > > Thanks, Tom, I will give this a try... > > > > From: Tom Rodriguez [mailto:tom.rodriguez at oracle.com] > Sent: Monday, June 30, 2014 12:17 PM > To: Deneau, Tom > Cc: graal-dev at openjdk.java.net > Subject: Re: logic in Math.nextAfter for handling -0.0 input > > The meaning of "just call it" is the problem here. Currently the logic in ReplacementsImpl.java around line 595 is looking for a call to the substitution method and replacing that with an inline of the original method. It's not looking for invokes of the original method. So if you write your replacement like this: > > > @MethodSubstitution > public static double nextAfter(double x, double direction) { > // work around special case of -0.0 > double xx = (x == -0.0 ? 0.0 : x); > return Math.nextAfter(xx, direction); > } > > it will stack overflow like you are seeing because it's recursively trying to do the method substitution. If you remove the "Math." part then it will look like a recursive call to the substitution method and be handled by replacing the call with the original Math.nextAfter code. I'll fix the code to properly handle calling either the original method or the substitution method so this works as expected. > > tom > > On Jun 27, 2014, at 5:13 PM, Tom Rodriguez > wrote: > > > That's supposed to work correctly. I suppose it could be because of inline everything though I'm not sure how that would trigger the problem. Can try running your problematic test case against regular graal and see if it reproduces? > > I've seen cases like this with recursive deopts. Maybe that's what's happening here? > > tom > > On Jun 27, 2014, at 4:40 PM, Deneau, Tom > wrote: > > > That's what I was doing below. Is the problem that we are "inlining everything" on the hsail backend? > > -- Tom > > -----Original Message----- > From: Tom Rodriguez [mailto:tom.rodriguez at oracle.com] > Sent: Friday, June 27, 2014 6:39 PM > To: Deneau, Tom > Cc: graal-dev at openjdk.java.net > Subject: Re: logic in Math.nextAfter for handling -0.0 input > > Just call it. A call to the original method stays a real call to that method and doesn't get substituted. > > tom > > On Jun 27, 2014, at 4:35 PM, Deneau, Tom > wrote: > > > Pinging, since I never saw an answer to this. > > I thought there was some way to substitute for a method and still call > the original method without getting into a recursive call... > > (The original problem below is resolved but need this kind of solution for a different reason). > > -- Tom > > > -----Original Message----- > From: Deneau, Tom > Sent: Monday, June 23, 2014 3:43 PM > To: Deneau, Tom; 'graal-dev at openjdk.java.net' > Subject: RE: logic in Math.nextAfter for handling -0.0 input > > Related to this... > Should I be able to work around this with the following hsail MethodSubstitution? > When I try this, I get a StackOverflowError... > > -- Tom > > @ClassSubstitution(java.lang.Math.class) > public class HSAILMathSubstitutions { > ... > @MethodSubstitution > public static double nextAfter(double x, double direction) { > // work around special case of -0.0 > double xx = (x == -0.0 ? 0.0 : x); > return Math.nextAfter(xx, direction); > } > } > > > > > -----Original Message----- > From: Deneau, Tom > Sent: Monday, June 23, 2014 3:34 PM > To: 'graal-dev at openjdk.java.net' > Subject: logic in Math.nextAfter for handling -0.0 input > > The JDK method Math.nextAfter contains the logic shown below to handle > an input of -0.0 > > When the graal compiler compiles this for the hsail backend, it makes the reasonable assumption that "start + 0.0d" can be reduced to "start" which is a problem for this algorithm. > > From what I could tell, c2 or graal for amd64 backend do not do this optimization and so get the right answer for -0.0 input. How do they know not to do this optimization? > > > } else { // start > direction or start < direction > // Add +0.0 to get rid of a -0.0 (+0.0 + -0.0 => +0.0) > // then bitwise convert start to integer. > long transducer = Double.doubleToRawLongBits(start + 0.0d); <============== > > if (direction > start) { // Calculate next greater value > transducer = transducer + (transducer >= 0L ? 1L:-1L); > } else { // Calculate next lesser value > .... > > -- Tom From tom.deneau at amd.com Mon Jun 30 19:56:48 2014 From: tom.deneau at amd.com (Deneau, Tom) Date: Mon, 30 Jun 2014 19:56:48 +0000 Subject: webrev-hsail-transcendentals Message-ID: Please review the following webrev which adds support for several missing java.lang.Math routines to the HSAIL backend. http://cr.openjdk.java.net/~tdeneau/graal-webrevs/webrev-hsail-transcendentals/webrev/ Many of these routines were declared as native in the regular host backends, but HSAIL has no way to invoke host code from the kernels. But if we could find java implementations of these methods we could use those thru the graal MethodSubstitution framework. For the java implementations, we basically used a file StrictMath.java which Gustav Trede donated to OpenJDK back in 2009 as a java port of the C FDLIBM routines, thank you Gustav. http://mail.openjdk.java.net/pipermail/hotspot-dev/2009-August/001992.html We made only a few minor changes to that file. My understanding from Joe Darcy is that in Java 9 there will be an official port of FDLIBM to java in the JDK, so when that happens we should be able to use that instead. Notes: * JStrictMath.java is the java implementation of the Math routines noted above. HSAILMathSubstitutions redirects several methods to there. In addition test cases were added for many Math routines which were already implemented as java methods in java.lang.Math. * GraalTest -- o Since the java spec specifies the tolerance for most of these Math routines in terms of ULPs, I wanted to enable a way for AssertEquals to use ULPs rather than a constant maximum delta. This is done by overriding protected int ulpsDelta() to return something other than zero. * HSAILAssembler o fix the printing of some special Double and Float constants o cvt for float to integer uses zeroi_sat (saturate) * HSAILLIRGenerator & HSAILControlFlow o IntegerTestMove support was required by some of the java implementations * all the rest are just junit tests. All junit tests should pass on the simulator. These math routines have also been useful in solidifying the hsail hardware implementation. -- Tom From tom.deneau at amd.com Mon Jun 30 21:01:51 2014 From: tom.deneau at amd.com (Deneau, Tom) Date: Mon, 30 Jun 2014 21:01:51 +0000 Subject: HSAIL backend Deoptimization and Allocation wiki pages Message-ID: To reflect recent checkins on the graal trunk, I have updated a couple of pages on the Sumatra wiki dealing with HSAIL backend deoptimization and allocation. Suggestions for further experiments in this area are welcome. -- Tom Deneau https://wiki.openjdk.java.net/display/Sumatra/Experiments+With+Deoptimization+on+Sumatra https://wiki.openjdk.java.net/display/Sumatra/Experiments+with+Allocation+on+Sumatra