From doug.simon at oracle.com Sat Jun 1 18:00:07 2013 From: doug.simon at oracle.com (doug.simon at oracle.com) Date: Sun, 02 Jun 2013 01:00:07 +0000 Subject: hg: graal/graal: 23 new changesets Message-ID: <20130602010128.779F448EBC@hg.openjdk.java.net> Changeset: 9e6b6d5d6465 Author: Doug Simon Date: 2013-05-26 13:09 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/9e6b6d5d6465 rename: getKilledLocationIdentities -> getKilledLocations ! graal/com.oracle.graal.api.meta/src/com/oracle/graal/api/meta/MetaAccessProvider.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotRuntime.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/extended/ForeignCallNode.java Changeset: 6fa4b4933892 Author: Doug Simon Date: 2013-05-26 13:15 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/6fa4b4933892 added check to gate that generated IDE configurations don't break the build ! mx/commands.py Changeset: 81d5d8089cda Author: Morris Meyer Date: 2013-05-26 13:44 -0400 URL: http://hg.openjdk.java.net/graal/graal/rev/81d5d8089cda SPARC float arithmetic + graal/com.oracle.graal.asm.sparc/src/com/oracle/graal/asm/sparc/SPARCAddress.java ! graal/com.oracle.graal.asm.sparc/src/com/oracle/graal/asm/sparc/SPARCAssembler.java + graal/com.oracle.graal.compiler.sparc.test/src/com/oracle/graal/compiler/sparc/test/FloatSPARCTest.java ! graal/com.oracle.graal.compiler.sparc/src/com/oracle/graal/compiler/sparc/SPARCLIRGenerator.java ! graal/com.oracle.graal.lir.sparc/src/com/oracle/graal/lir/sparc/SPARCArithmetic.java Changeset: cff647969dfa Author: Doug Simon Date: 2013-05-26 22:48 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/cff647969dfa fixed detection of Checkstyle errors in checkstyle command (GRAAL-293) ! mxtool/mx.py Changeset: 26a4433252a3 Author: Doug Simon Date: 2013-05-26 22:49 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/26a4433252a3 fixed Checkstyle errors ! graal/com.oracle.graal.lir.sparc/src/com/oracle/graal/lir/sparc/SPARCArithmetic.java Changeset: 5aedcaed6ccf Author: Morris Meyer Date: 2013-05-26 18:16 -0400 URL: http://hg.openjdk.java.net/graal/graal/rev/5aedcaed6ccf Initial SPARC control instructions ! graal/com.oracle.graal.asm.sparc/src/com/oracle/graal/asm/sparc/AbstractSPARCAssembler.java ! graal/com.oracle.graal.asm.sparc/src/com/oracle/graal/asm/sparc/SPARCAddress.java ! graal/com.oracle.graal.asm.sparc/src/com/oracle/graal/asm/sparc/SPARCAssembler.java + graal/com.oracle.graal.compiler.sparc.test/src/com/oracle/graal/compiler/sparc/test/ControlSPARCTest.java ! graal/com.oracle.graal.compiler.sparc/src/com/oracle/graal/compiler/sparc/SPARCLIRGenerator.java + graal/com.oracle.graal.lir.sparc/src/com/oracle/graal/lir/sparc/SPARCAddressValue.java ! graal/com.oracle.graal.lir.sparc/src/com/oracle/graal/lir/sparc/SPARCControlFlow.java ! graal/com.oracle.graal.lir.sparc/src/com/oracle/graal/lir/sparc/SPARCMove.java ! make/build-graal.xml ! mx/projects Changeset: 04911dff1c66 Author: Morris Meyer Date: 2013-05-27 10:26 -0400 URL: http://hg.openjdk.java.net/graal/graal/rev/04911dff1c66 SPARC logic and shift operations + graal/com.oracle.graal.compiler.sparc.test/src/com/oracle/graal/compiler/sparc/test/LogicSPARCTest.java ! graal/com.oracle.graal.compiler.sparc/src/com/oracle/graal/compiler/sparc/SPARCLIRGenerator.java ! graal/com.oracle.graal.lir.sparc/src/com/oracle/graal/lir/sparc/SPARCArithmetic.java Changeset: 98918f518640 Author: Doug Simon Date: 2013-05-28 10:59 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/98918f518640 fixed bash syntax error ! mxtool/mx Changeset: 705aca4ebf2f Author: Morris Meyer Date: 2013-05-28 09:04 -0400 URL: http://hg.openjdk.java.net/graal/graal/rev/705aca4ebf2f SPARC array, load / store and compare operations ! graal/com.oracle.graal.asm.sparc/src/com/oracle/graal/asm/sparc/SPARCAddress.java ! graal/com.oracle.graal.asm.sparc/src/com/oracle/graal/asm/sparc/SPARCAssembler.java + graal/com.oracle.graal.compiler.sparc.test/src/com/oracle/graal/compiler/sparc/test/ArraySPARCTest.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/LIRGenerator.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/SPARCCompare.java ! graal/com.oracle.graal.lir.sparc/src/com/oracle/graal/lir/sparc/SPARCControlFlow.java ! graal/com.oracle.graal.lir.sparc/src/com/oracle/graal/lir/sparc/SPARCMove.java ! make/build-graal.xml ! mx/projects Changeset: 1c4bef4568a8 Author: Lukas Stadler Date: 2013-05-28 17:17 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/1c4bef4568a8 create correct stamps for LocalNodes ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/stubs/ForeignCallStub.java ! graal/com.oracle.graal.java/src/com/oracle/graal/java/FrameStateBuilder.java Changeset: 716664350f87 Author: Christian Wimmer Date: 2013-05-28 16:12 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/716664350f87 Flag to disable VerifyUsageWithEquals phase ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/GraalCompiler.java ! graal/com.oracle.graal.phases/src/com/oracle/graal/phases/GraalOptions.java Changeset: df223ca2d6af Author: Christian Wimmer Date: 2013-05-28 16:13 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/df223ca2d6af Remove usage of identity hash code ! graal/com.oracle.truffle.sl/src/com/oracle/truffle/sl/nodes/FunctionDefinitionNode.java Changeset: fcfedd3dd2eb Author: Christian Wimmer Date: 2013-05-28 16:15 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/fcfedd3dd2eb ResolvedJavaType.isAssignableFrom must not be called with null argument. Check that with assertions in HotSpot implementation. ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotResolvedObjectType.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotResolvedPrimitiveType.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/java/StoreIndexedNode.java Changeset: eed6a2a93920 Author: Christian Wimmer Date: 2013-05-28 16:16 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/eed6a2a93920 Fix node intrinsic constructor ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/extended/ReadNode.java Changeset: 59d799c965c9 Author: Christian Wimmer Date: 2013-05-28 16:26 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/59d799c965c9 Allow ResolvedJavaType.resolveMethod to return null ! graal/com.oracle.graal.api.meta/src/com/oracle/graal/api/meta/ResolvedJavaType.java ! graal/com.oracle.graal.java/src/com/oracle/graal/java/GraphBuilderPhase.java ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/InliningUtil.java Changeset: d59af238b0e9 Author: Christian Wimmer Date: 2013-05-28 16:44 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/d59af238b0e9 ResolvedJavaType.isAssignableFrom must not be called with null argument ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/ObjectCloneNode.java Changeset: b360b05aa996 Author: Andreas Woess Date: 2013-05-16 14:33 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/b360b05aa996 Quick fix for BranchProbabilityNode. ! graal/com.oracle.graal.replacements/src/com/oracle/graal/replacements/nodes/BranchProbabilityNode.java Changeset: e6df511677da Author: Andreas Woess Date: 2013-05-17 18:05 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/e6df511677da BranchProbabilityNode: condition can also be a constant in the prepared graph for inlining. ! graal/com.oracle.graal.replacements/src/com/oracle/graal/replacements/nodes/BranchProbabilityNode.java Changeset: e9d8f135f203 Author: Bernhard Urban Date: 2013-05-29 15:28 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/e9d8f135f203 Assumptions: initialize list in constructor and add getter ! graal/com.oracle.graal.api.code/src/com/oracle/graal/api/code/Assumptions.java Changeset: 1cd5e2a6f038 Author: Bernhard Urban Date: 2013-05-29 15:33 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/1cd5e2a6f038 LIRGenerator: change visibility of `getLIRBlock' ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/gen/LIRGenerator.java Changeset: e05af215586b Author: Morris Meyer Date: 2013-05-30 22:56 -0400 URL: http://hg.openjdk.java.net/graal/graal/rev/e05af215586b SPARC compare ! graal/com.oracle.graal.asm.sparc/src/com/oracle/graal/asm/sparc/SPARCAssembler.java ! graal/com.oracle.graal.compiler.sparc/src/com/oracle/graal/compiler/sparc/SPARCLIRGenerator.java ! graal/com.oracle.graal.lir.sparc/src/com/oracle/graal/lir/sparc/SPARCCompare.java Changeset: 2d1687e63484 Author: Morris Meyer Date: 2013-05-31 21:55 -0400 URL: http://hg.openjdk.java.net/graal/graal/rev/2d1687e63484 SPARCMacroAssembler and synthetic instructions ! graal/com.oracle.graal.asm.sparc/src/com/oracle/graal/asm/sparc/SPARCAssembler.java + graal/com.oracle.graal.asm.sparc/src/com/oracle/graal/asm/sparc/SPARCMacroAssembler.java ! graal/com.oracle.graal.lir.sparc/src/com/oracle/graal/lir/sparc/SPARCCompare.java ! graal/com.oracle.graal.lir.sparc/src/com/oracle/graal/lir/sparc/SPARCMove.java ! graal/com.oracle.graal.sparc/src/com/oracle/graal/sparc/SPARC.java Changeset: 204e8f3209e9 Author: Morris Meyer Date: 2013-06-01 12:44 -0400 URL: http://hg.openjdk.java.net/graal/graal/rev/204e8f3209e9 SPARCMacroAssembler synthetic instructions and SPARCTestOp ! graal/com.oracle.graal.asm.sparc/src/com/oracle/graal/asm/sparc/SPARCAssembler.java ! graal/com.oracle.graal.asm.sparc/src/com/oracle/graal/asm/sparc/SPARCMacroAssembler.java ! graal/com.oracle.graal.compiler.sparc/src/com/oracle/graal/compiler/sparc/SPARCLIRGenerator.java ! graal/com.oracle.graal.lir.sparc/src/com/oracle/graal/lir/sparc/SPARCMove.java + graal/com.oracle.graal.lir.sparc/src/com/oracle/graal/lir/sparc/SPARCTestOp.java From thomas.wuerthinger at oracle.com Sun Jun 2 12:16:35 2013 From: thomas.wuerthinger at oracle.com (Thomas Wuerthinger) Date: Sun, 2 Jun 2013 21:16:35 +0200 Subject: graal inlining decisions In-Reply-To: References: <51A4D665.3020703@oracle.com> Message-ID: <03BC7756-57BA-454C-A4B0-CA47F3430B87@oracle.com> If you run with "--vm server", the host should be the server compiler and therefore not be affected by the "-G:Log" value. Additionally, you can choose to either limit the number of unit tests executed or apply a "-G:MethodFilter=" argument to reduce the output to certain patterns of methods. - thomas On May 29, 2013, at 1:22 AM, "Deneau, Tom" wrote: > Just to clarify, I would like to see the inlining decisions made when I compile for an HSAIL target, > (not interested in any decisions made for the x86 host). > > When I use the line below with mx unittest I see only x86 decisions... > > -- Tom > > -----Original Message----- > From: Mick Jordan [mailto:mick.jordan at oracle.com] > Sent: Tuesday, May 28, 2013 11:08 AM > To: Deneau, Tom > Cc: graal-dev at openjdk.java.net > Subject: Re: graal inlining decisions > > On 5/28/13 8:13 AM, Deneau, Tom wrote: >> What would be the best command line to use to see what kind of inlining decisions are being made in graal? >> >> -- Tom > This works for me: > > -G:Log=InliningDecisions > > Mick > > > From duboscq at ssw.jku.at Mon Jun 3 01:28:30 2013 From: duboscq at ssw.jku.at (Gilles Duboscq) Date: Mon, 3 Jun 2013 10:28:30 +0200 Subject: Initial SPARC compilation test In-Reply-To: <664A9D4F-3E50-4929-9C8E-85A409F7537E@oracle.com> References: <51A02F02.3020802@oracle.com> <8E446DA0-A873-4E57-9AD6-290BBF78394E@oracle.com> <03490880-C700-47B8-BBEA-47F0762C438D@oracle.com> <98CF2C01-4D13-4193-A5C8-07BFD551CA6F@oracle.com> <0A95D2A7-72DD-44EC-91F6-502AEF85745A@oracle.com> <440BBC4B-BD2E-48EA-9753-7E308ADFDF5B@oracle.com> <51A6172D.5020703@oracle.com> <664A9D4F-3E50-4929-9C8E-85A409F7537E@oracle.com> Message-ID: I'm also in favour of the .emit(masm) method, it allows you to keep the various benefits mentioned above and would remove the surprise element of side-effecting constructors. -Gilles On Wed, May 29, 2013 at 6:16 PM, Christian Thalinger < christian.thalinger at oracle.com> wrote: > > On May 29, 2013, at 7:56 AM, Morris Meyer wrote: > > > The object layout of instructions has sort of grown on me. I think the > possibility for post-assembly reordering of code - such as this from the > SPARC V9 spec below could have benefits. > > > > > I think there is room for improvement still in SPARCAssembler with the > class structure - saving the fields and separating encode from emit seems > to be one. > > > > For now though I'm working on getting Graal to compile on SPARC. > > > > --mm > > > > Branches cause most implementations? performance to degrade > significantly. Frrequently, the MOVcc and FMOVcc instructions can be used > to avoid branches. For example, the following C language segment: > > > > double A, B, X; > > if (A > B) then X = 1.03; else X = 0.0; > > > > can be coded as > > > > ! assume A is in %f0; B is in %f2; %xx points to constant area > > ldd [%xx+C_1.03],%f4 ! X = 1.03 > > fcmpd %fcc3,%f0,%f2 ! A > B > > > > fble,a %fcc3,label > > > > ! following only executed if the branch is taken > > > > fsubd %f4,%f4,%f4 ! X = 0.0 > > label:... > > > > This takes four instructions including a branch. Using FMOVcc, this > could be coded as > > > > ldd [%xx+C_1.03],%f4 ! X = 1.03 > > > > fsubd %f4,%f4,%f6! X? = 0.0 > > fcmpd %fcc3,%f0,%f2! A > B > > fmovdle %fcc3,%f6,%f4! X = 0.0 > > > > > > > > > > This also takes four instructions, but requires no branches and may > boost performance significantly. It is sug- gested that MOVcc and FMOVcc be > used instead of branches wherever they would improve performance. > > I wonder if this is still true with newer SPARC implementations. > > -- Chris > > > > > SPARCV9 > > > > On 5/28/13 6:27 PM, Christian Thalinger wrote: > >> On May 28, 2013, at 1:58 PM, Doug Simon wrote: > >> > >>> On May 28, 2013, at 10:52 PM, Thomas Wuerthinger < > thomas.wuerthinger at oracle.com> wrote: > >>> > >>>> The possible benefits of having instruction classes would include > abilities like writing simulation or verification code. > >>> True. It also makes the classes usable as output for a structured > disassembler. > >> That's a good point. Instruction patching could then be something like: > >> > >> Add.readAt(pc).setRd(reg).emit(masm); > >> > >> Since RISC architectures usually have a small number of instruction > classes I think we should go that way. > >> > >> -- Chris > >> > >>>> This would include the field definitions you outline below. In the > machine code, it would not make any performance difference as escape > analysis would still get rid of the allocation for the case where the > instruction instance is not stored in a side data structure. > >>> Yes, I have complete faith in escape analysis, especially in this case. > >>> > >>>> If we do not have the fields, then I see no benefit of using > constructors over static methods. > >>> Right. The use cases mentioned above are interesting however though. > >>> > >>> -Doug > >>> > >>>> On May 28, 2013, at 10:42 PM, Doug Simon > wrote: > >>>> > >>>>> On May 28, 2013, at 10:28 PM, Thomas Wuerthinger < > thomas.wuerthinger at oracle.com> wrote: > >>>>> > >>>>>> In general, I like the idea of representing the instructions using > a Java class hierarchy. What about using a pattern like new > InstructionXY(?).emit(?) to avoid the side-effecting constructor? > >>>>> This make the Fmt classes bigger as they would define fields for the > operands and they need to define an emit() method. For example, we > currently we have: > >>>>> > >>>>> public static class Fmt3b { > >>>>> public Fmt3b(SPARCAssembler masm, int op, int op3, int rs1, int > regOrImmediate, int rd) { > >>>>> assert op == 2 || op == 3; > >>>>> assert op3 >= 0 && op3 < 0x40; > >>>>> assert rs1 >= 0 && rs1 < 0x20; > >>>>> assert rd >= 0 && rd < 0x20; > >>>>> > >>>>> masm.emitInt(op << 30 | rd << 25 | op3 << 19 | rs1 << 14 | > (regOrImmediate & 0x1fff)); > >>>>> } > >>>>> } > >>>>> > >>>>> public static class Add extends Fmt3b { > >>>>> public Add(SPARCAssembler masm, Register src1, int simm13, > Register dst) { > >>>>> super(masm, Ops.ArithOp.getValue(), Op3s.Add.getValue(), > src1.encoding(), simm13, dst.encoding()); > >>>>> } > >>>>> public Add(SPARCAssembler masm, Register src1, Register src2, > Register dst) { > >>>>> super(masm, Ops.ArithOp.getValue(), Op3s.Add.getValue(), > src1.encoding(), src2.encoding(), dst.encoding()); > >>>>> } > >>>>> } > >>>>> > >>>>> and we would go to: > >>>>> > >>>>> public static class Fmt3b { > >>>>> final int op; > >>>>> final int op3; > >>>>> final int rs1; > >>>>> final int regOrImmediate; > >>>>> int rd; > >>>>> public Fmt3b(int op, int op3, int rs1, int regOrImmediate, int > rd) { > >>>>> assert op == 2 || op == 3; > >>>>> assert op3 >= 0 && op3 < 0x40; > >>>>> assert rs1 >= 0 && rs1 < 0x20; > >>>>> assert rd >= 0 && rd < 0x20; > >>>>> this.op = op; > >>>>> this.op3 = op3; > >>>>> this.rs1 = rs1; > >>>>> this.regOrImmediate = regOrImmediate; > >>>>> } > >>>>> public emit(SPARCAssembler masm) { > >>>>> masm.emitInt(op << 30 | rd << 25 | op3 << 19 | rs1 << 14 | > (regOrImmediate & 0x1fff)); > >>>>> } > >>>>> } > >>>>> > >>>>> public static class Add extends Fmt3b { > >>>>> public Add(SPARCAssembler masm, Register src1, int simm13, > Register dst) { > >>>>> super(Ops.ArithOp.getValue(), Op3s.Add.getValue(), > src1.encoding(), simm13, dst.encoding()); > >>>>> } > >>>>> public Add(SPARCAssembler masm, Register src1, Register src2, > Register dst) { > >>>>> super(Ops.ArithOp.getValue(), Op3s.Add.getValue(), > src1.encoding(), src2.encoding(), dst.encoding()); > >>>>> } > >>>>> } > >>>>> > >>>>> If we do without instruction classes, we'd have: > >>>>> > >>>>> void fmt3b(int op, int op3, int rs1, int regOrImmediate, int rd) { > >>>>> assert op == 2 || op == 3; > >>>>> assert op3 >= 0 && op3 < 0x40; > >>>>> assert rs1 >= 0 && rs1 < 0x20; > >>>>> assert rd >= 0 && rd < 0x20; > >>>>> > >>>>> emitInt(op << 30 | rd << 25 | op3 << 19 | rs1 << 14 | > (regOrImmediate & 0x1fff)); > >>>>> } > >>>>> > >>>>> void add(Register src1, int simm13, Register dst) { > >>>>> fmt3b(Ops.ArithOp.getValue(), Op3s.Add.getValue(), > src1.encoding(), simm13, dst.encoding()); > >>>>> } > >>>>> > >>>>> void add(Register src1, Register src2, Register dst) { > >>>>> super(Ops.ArithOp.getValue(), Op3s.Add.getValue(), > src1.encoding(), src2.encoding(), dst.encoding()); > >>>>> } > >>>>> > >>>>> As long as the above are non-static methods in SPARCAssembler, we > still have extensibility with less code. > >>>>> > >>>>> -Doug > >>>>> > >>>>>> - thomas > >>>>>> > >>>>>> On May 28, 2013, at 8:59 PM, Doug Simon > wrote: > >>>>>> > >>>>>>> On May 28, 2013, at 7:48 PM, Christian Thalinger < > christian.thalinger at oracle.com> wrote: > >>>>>>> > >>>>>>>> On May 25, 2013, at 2:07 PM, Doug Simon > wrote: > >>>>>>>> > >>>>>>>>> Hi Morris, > >>>>>>>>> > >>>>>>>>> On May 25, 2013, at 3:57 PM, Morris Meyer < > morris.meyer at oracle.com> wrote: > >>>>>>>>> > >>>>>>>>>> Christian suggested that we use Fmt superclasses to contain the > various SPARC instruction modes. I think his preference would be to > generate the assembler w annotations but this is as far as we pushed it. > >>>>>>>> Yes, this is my fault. Don't blame Morris :-) > >>>>>>> Blame? I had no intention of assigning blame ;-) Just trying to > understand the advantage(s) of doing it this way. > >>>>>>> > >>>>>>>>> As part of the Maxine project, we had a system for generating > assemblers[1] (with which we generated assemblers for SPARC and x64). This > system also allowed for easy construction of disassemblers. There might > something there worth leveraging if we want to pursue the generated > assembler idea further. I know Christian is already aware of this work - > I'm just bringing it up in case others aren't. > >>>>>>>> Right. Remind me, why was it not used in the end? > >>>>>>> Because the port of C1 into C1X was intended to be as disconnected > from existing Maxine technology as possible (to demonstrate the > runtime/compiled interface designed as part of the porting process). Had we > not moved onto Graal, there were thoughts of having the hand assembler in > C1X be generated by the framework. > >>>>>>> > >>>>>>>>>> I started w static methods like the PTX and AMD64 assemblers > but this pattern is sort of growing on me as makes asserting things easier. > >>>>>>>>> The assertions I see in SPARCAssembler could just as easily be > placed in helper methods as opposed to super class constructors right? > >>>>>>>> It could. It seems like a good idea to use the Java class > hierarchy to represent the instruction classes of an ISA but if it causes > too much trouble then we can drop it. > >>>>>>> I have no strong preference. I was just looking for the technical > advantage of modeling the instructions with classes that motivated the use > of side-effecting constructors. > >>>>>>> > >>>>>>> In any case, it's great to see a second backend being added to > Graal. > >>>>>>> > >>>>>>> -Doug > >>>>>>> > >>>>>>>> -- Chris > >>>>>>>> > >>>>>>>>>> The warning is handled in the lir.sparc package with a JDT > prefs change. > >>>>>>>>> Unfortunately this doesn't help anyone using mx to create the > Eclipse project configurations. The next time anyone runs 'mx eclipseinit' > (which most of us do after a pull when we new projects added), your changes > to graal/com.oracle.graal.lir.sparc/.settings/org.eclipse.jdt.core.prefs > will be overwritten. > >>>>>>>>> > >>>>>>>>> For now, could you please add @SuppressWarnings("unused") where > necessary and hg delete > graal/com.oracle.graal.lir.sparc/.settings/org.eclipse.jdt.core.prefs. At > the same time, we should consider whether to disable the > unusedObjectAllocation check globally. As of now, we use the same Eclipse > settings for all projects and I'm not sure this current case is a strong > enough reason to deviate from that policy. Especially since it's not yet > clear (to me at least) why the pattern of separate > >>>>>>>>> > >>>>>>>>> -Doug > >>>>>>>>> > >>>>>>>>> [1] https://wikis.oracle.com/display/MaxineVM/Assembler > >>>>>>>>> > >>>>>>>>>> --mm > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> On May 25, 2013, at 5:54 AM, Doug Simon > wrote: > >>>>>>>>>> > >>>>>>>>>>> Hi Morris, Christian, > >>>>>>>>>>> > >>>>>>>>>>> Why is the SPARC assembler constructed as a set of classes, > one for each instruction as opposed to a single assembler class with a > bunch of methods (like AMD64Assembler)? I trust that escape analysis does > the right thing so there's no overhead for the object construction but I > don't see any real advantages to doing it this way. It's strange to have a > constructor with a side effect. And of course, it means we need to suppress > the Eclipse warnings somehow. > >>>>>>>>>>> > >>>>>>>>>>> -Doug > >>>>>>>>>>> > >>>>>>>>>>> On May 25, 2013, at 5:24 AM, Morris Meyer < > morris.meyer at oracle.com> wrote: > >>>>>>>>>>> > >>>>>>>>>>>> I just pushed the initial SPARC compilation test for Graal. > >>>>>>>>>>>> > >>>>>>>>>>>> ./mx.sh --vm server unittest BasicSPARCTest > >>>>>>>>>>>> > >>>>>>>>>>>> will get you started. > >>>>>>>>>>>> > >>>>>>>>>>>> --mm > > > > From tom.deneau at amd.com Mon Jun 3 05:04:18 2013 From: tom.deneau at amd.com (Deneau, Tom) Date: Mon, 3 Jun 2013 12:04:18 +0000 Subject: graal inlining decisions In-Reply-To: <03BC7756-57BA-454C-A4B0-CA47F3430B87@oracle.com> References: <51A4D665.3020703@oracle.com> <03BC7756-57BA-454C-A4B0-CA47F3430B87@oracle.com> Message-ID: Thomas -- I tried this command line mx --vm server unittest @-G:Log=InliningDecisions ArrayListGetTest which only runs a single test, and I did not see any inlining decisions logged (one method is being compiled by the graal hsail compiler in the above case) If I instead use a --vm graal command line mx --vm server unittest @-G:Log=InliningDecisions ArrayListGetTest I see only the hosted x86 inlining decisions, not the hsail decisions. We are compiling the HSAIL with with code like the following: public static HSAILCompilationResult getHSAILCompilationResult(StructuredGraph graph) { Debug.dump(graph, "Graph"); TargetDescription target = new TargetDescription(new HSAIL(), true, 1, 0, true); HSAILBackend hsailBackend = new HSAILBackend(Graal.getRequiredCapability(GraalCodeCacheProvider.class), target); PhasePlan phasePlan = new PhasePlan(); GraphBuilderPhase graphBuilderPhase = new GraphBuilderPhase(runtime, GraphBuilderConfiguration.getDefault(), OptimisticOptimizations.NONE); phasePlan.addPhase(PhasePosition.AFTER_PARSING, graphBuilderPhase); phasePlan.addPhase(PhasePosition.AFTER_PARSING, new HSAILPhase()); new HSAILPhase().apply(graph); CallingConvention cc = getCallingConvention(runtime, Type.JavaCallee, graph.method(), false); CompilationResult compResult = GraalCompiler.compileGraph(graph, cc, graph.method(), runtime, replacements, // graalRuntime().getReplacements(), hsailBackend, target, null, phasePlan, OptimisticOptimizations.NONE, new SpeculationLog()); -- Tom Deneau -----Original Message----- From: Thomas Wuerthinger [mailto:thomas.wuerthinger at oracle.com] Sent: Sunday, June 02, 2013 2:17 PM To: Deneau, Tom Cc: graal-dev at openjdk.java.net Subject: Re: graal inlining decisions If you run with "--vm server", the host should be the server compiler and therefore not be affected by the "-G:Log" value. Additionally, you can choose to either limit the number of unit tests executed or apply a "-G:MethodFilter=" argument to reduce the output to certain patterns of methods. - thomas On May 29, 2013, at 1:22 AM, "Deneau, Tom" wrote: > Just to clarify, I would like to see the inlining decisions made when I compile for an HSAIL target, > (not interested in any decisions made for the x86 host). > > When I use the line below with mx unittest I see only x86 decisions... > > -- Tom > > -----Original Message----- > From: Mick Jordan [mailto:mick.jordan at oracle.com] > Sent: Tuesday, May 28, 2013 11:08 AM > To: Deneau, Tom > Cc: graal-dev at openjdk.java.net > Subject: Re: graal inlining decisions > > On 5/28/13 8:13 AM, Deneau, Tom wrote: >> What would be the best command line to use to see what kind of inlining decisions are being made in graal? >> >> -- Tom > This works for me: > > -G:Log=InliningDecisions > > Mick > > > From doug.simon at oracle.com Mon Jun 3 07:01:32 2013 From: doug.simon at oracle.com (Doug Simon) Date: Mon, 3 Jun 2013 16:01:32 +0200 Subject: possible bug in mx/projects handling In-Reply-To: <5DD1503F815BD14889DC81D28643E3A73D8CC90C@sausexdag06.amd.com> References: <5DD1503F815BD14889DC81D28643E3A73D8CC90C@sausexdag06.amd.com> Message-ID: <75209595-07E0-4D7F-9C70-D857FC9A9A3F@oracle.com> On May 31, 2013, at 11:02 PM, "Venkatachalam, Vasanth" wrote: > Hi, > > We have a project com.amd.sumatra which requires java 1.8 compliance to build. > > We've added lines in mx/project to specify that the project shouldn't be built when building with a 1.7 JDK: > > distribution at GRAAL@path=graal.jar > distribution at GRAAL@dependencies=com.oracle.graal.hotspot.amd64,com.oracle.graal.hotspot.sparc,com.oracle.graal.hotspot,com.amd.sumatra > > # com.amd.sumatra > project at com.amd.sumatra@subDir=graal > project at com.amd.sumatra@sourceDirs=src > project at com.amd.sumatra@dependencies=com.oracle.graal.hotspot,com.oracle.graal.hotspot.amd64,com.oracle.graal.hsail,com.oracle.graal.compiler.hsail,com.amd.okra > project at com.amd.sumatra@checkstyle=com.oracle.graal.graph > project at com.amd.sumatra@javaCompliance=1.8 > > When I do an mx build, I see the lines > > Excluding com.amd.sumatra fro build (Java compliance level 1.8 required) > > But then Graal goes ahead and tries to build the package. This appears to be a bug. Can someone look into this? I tried to reproduce this by creating a local com.amd.sumatra project and used some JDK 1.8 API in it. However, 'mx build' does the expected thing in may case (i.e. does not try to compiled anything in com.amd.sumatra). Could you please send me the output of 'mx clean --no-native; mx -v build' so I can investigate further. -Doug From tom.deneau at amd.com Mon Jun 3 08:31:42 2013 From: tom.deneau at amd.com (Deneau, Tom) Date: Mon, 3 Jun 2013 15:31:42 +0000 Subject: possible bug in mx/projects handling In-Reply-To: <75209595-07E0-4D7F-9C70-D857FC9A9A3F@oracle.com> References: <5DD1503F815BD14889DC81D28643E3A73D8CC90C@sausexdag06.amd.com> <75209595-07E0-4D7F-9C70-D857FC9A9A3F@oracle.com> Message-ID: Doug -- Did you also put your com.amd.sumatra as a dependency for graal.jar? That is where the problem seems to arise. distribution at GRAAL@path=graal.jar distribution at GRAAL@dependencies=com.oracle.graal.hotspot.amd64,com.oracle.graal.hotspot.sparc,com.oracle.graal.hotspot,com.amd.sumatra -- Tom -----Original Message----- From: graal-dev-bounces at openjdk.java.net [mailto:graal-dev-bounces at openjdk.java.net] On Behalf Of Doug Simon Sent: Monday, June 03, 2013 9:02 AM To: Venkatachalam, Vasanth Cc: graal-dev at openjdk.java.net Subject: Re: possible bug in mx/projects handling On May 31, 2013, at 11:02 PM, "Venkatachalam, Vasanth" wrote: > Hi, > > We have a project com.amd.sumatra which requires java 1.8 compliance to build. > > We've added lines in mx/project to specify that the project shouldn't be built when building with a 1.7 JDK: > > distribution at GRAAL@path=graal.jar > distribution at GRAAL@dependencies=com.oracle.graal.hotspot.amd64,com.oracle.graal.hotspot.sparc,com.oracle.graal.hotspot,com.amd.sumatra > > # com.amd.sumatra > project at com.amd.sumatra@subDir=graal > project at com.amd.sumatra@sourceDirs=src > project at com.amd.sumatra@dependencies=com.oracle.graal.hotspot,com.oracle.graal.hotspot.amd64,com.oracle.graal.hsail,com.oracle.graal.compiler.hsail,com.amd.okra > project at com.amd.sumatra@checkstyle=com.oracle.graal.graph > project at com.amd.sumatra@javaCompliance=1.8 > > When I do an mx build, I see the lines > > Excluding com.amd.sumatra fro build (Java compliance level 1.8 required) > > But then Graal goes ahead and tries to build the package. This appears to be a bug. Can someone look into this? I tried to reproduce this by creating a local com.amd.sumatra project and used some JDK 1.8 API in it. However, 'mx build' does the expected thing in may case (i.e. does not try to compiled anything in com.amd.sumatra). Could you please send me the output of 'mx clean --no-native; mx -v build' so I can investigate further. -Doug From doug.simon at oracle.com Mon Jun 3 09:29:01 2013 From: doug.simon at oracle.com (Doug Simon) Date: Mon, 3 Jun 2013 18:29:01 +0200 Subject: possible bug in mx/projects handling In-Reply-To: References: <5DD1503F815BD14889DC81D28643E3A73D8CC90C@sausexdag06.amd.com> <75209595-07E0-4D7F-9C70-D857FC9A9A3F@oracle.com> Message-ID: <8768AD30-240F-42FA-8D84-7179CD5681F9@oracle.com> Ok, I see the problem. Pushing through a fix now. Here's the patch: diff -r 91a1041ec905 mxtool/mx.py --- a/mxtool/mx.py Sat Jun 01 20:42:22 2013 -0400 +++ b/mxtool/mx.py Mon Jun 03 18:07:59 2013 +0200 @@ -1700,6 +1700,11 @@ try: zf = zipfile.ZipFile(tmp, 'w') for p in sorted_deps(d.deps): + # skip a Java project if its Java compliance level is "higher" than the configured JDK + if java().javaCompliance < p.javaCompliance: + log('Excluding {0} from {2} (Java compliance level {1} required)'.format(p.name, p.javaCompliance, d.path)) + continue + outputDir = p.output_dir() for root, _, files in os.walk(outputDir): relpath = root[len(outputDir) + 1:] On Jun 3, 2013, at 5:31 PM, "Deneau, Tom" wrote: > Doug -- > > Did you also put your com.amd.sumatra as a dependency for graal.jar? That is where the problem seems to arise. > > distribution at GRAAL@path=graal.jar > distribution at GRAAL@dependencies=com.oracle.graal.hotspot.amd64,com.oracle.graal.hotspot.sparc,com.oracle.graal.hotspot,com.amd.sumatra > > -- Tom > > -----Original Message----- > From: graal-dev-bounces at openjdk.java.net [mailto:graal-dev-bounces at openjdk.java.net] On Behalf Of Doug Simon > Sent: Monday, June 03, 2013 9:02 AM > To: Venkatachalam, Vasanth > Cc: graal-dev at openjdk.java.net > Subject: Re: possible bug in mx/projects handling > > > On May 31, 2013, at 11:02 PM, "Venkatachalam, Vasanth" wrote: > >> Hi, >> >> We have a project com.amd.sumatra which requires java 1.8 compliance to build. >> >> We've added lines in mx/project to specify that the project shouldn't be built when building with a 1.7 JDK: >> >> distribution at GRAAL@path=graal.jar >> distribution at GRAAL@dependencies=com.oracle.graal.hotspot.amd64,com.oracle.graal.hotspot.sparc,com.oracle.graal.hotspot,com.amd.sumatra >> >> # com.amd.sumatra >> project at com.amd.sumatra@subDir=graal >> project at com.amd.sumatra@sourceDirs=src >> project at com.amd.sumatra@dependencies=com.oracle.graal.hotspot,com.oracle.graal.hotspot.amd64,com.oracle.graal.hsail,com.oracle.graal.compiler.hsail,com.amd.okra >> project at com.amd.sumatra@checkstyle=com.oracle.graal.graph >> project at com.amd.sumatra@javaCompliance=1.8 >> >> When I do an mx build, I see the lines >> >> Excluding com.amd.sumatra fro build (Java compliance level 1.8 required) >> >> But then Graal goes ahead and tries to build the package. This appears to be a bug. Can someone look into this? > > I tried to reproduce this by creating a local com.amd.sumatra project and used some JDK 1.8 API in it. However, 'mx build' does the expected thing in may case (i.e. does not try to compiled anything in com.amd.sumatra). Could you please send me the output of 'mx clean --no-native; mx -v build' so I can investigate further. > > -Doug > From doug.simon at oracle.com Mon Jun 3 11:03:46 2013 From: doug.simon at oracle.com (doug.simon at oracle.com) Date: Mon, 03 Jun 2013 18:03:46 +0000 Subject: hg: graal/graal: 2 new changesets Message-ID: <20130603180357.8467E48EF2@hg.openjdk.java.net> Changeset: 91a1041ec905 Author: Morris Meyer Date: 2013-06-01 20:42 -0400 URL: http://hg.openjdk.java.net/graal/graal/rev/91a1041ec905 SPARCLIRGenerator, sqrt, condition move, breakpoint op, partial bit ops ! graal/com.oracle.graal.asm.sparc/src/com/oracle/graal/asm/sparc/SPARCAssembler.java ! graal/com.oracle.graal.asm.sparc/src/com/oracle/graal/asm/sparc/SPARCMacroAssembler.java ! graal/com.oracle.graal.compiler.sparc/src/com/oracle/graal/compiler/sparc/SPARCLIRGenerator.java ! graal/com.oracle.graal.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/SPARCBreakpointOp.java + graal/com.oracle.graal.lir.sparc/src/com/oracle/graal/lir/sparc/SPARCByteSwapOp.java ! graal/com.oracle.graal.lir.sparc/src/com/oracle/graal/lir/sparc/SPARCControlFlow.java + graal/com.oracle.graal.lir.sparc/src/com/oracle/graal/lir/sparc/SPARCMathIntrinsicOp.java Changeset: 931f9ced42ad Author: Doug Simon Date: 2013-06-03 18:27 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/931f9ced42ad omit projects from distributions where the project's Java compliance level is too high ! mxtool/mx.py From thomas.wuerthinger at oracle.com Thu Jun 6 05:22:21 2013 From: thomas.wuerthinger at oracle.com (Thomas Wuerthinger) Date: Thu, 6 Jun 2013 14:22:21 +0200 Subject: graal inlining decisions In-Reply-To: References: <51A4D665.3020703@oracle.com> <03BC7756-57BA-454C-A4B0-CA47F3430B87@oracle.com> Message-ID: Maybe you are missing a call to this method: "DebugEnvironment.initialize(System.out)" Does dumping the graph to the IdealGraphVisualizer work in the code below? - thomas On Jun 3, 2013, at 2:04 PM, "Deneau, Tom" wrote: > Thomas -- > > I tried this command line > mx --vm server unittest @-G:Log=InliningDecisions ArrayListGetTest > > which only runs a single test, and I did not see any inlining decisions logged (one method is being compiled by the graal hsail compiler in the above case) > > If I instead use a --vm graal command line > mx --vm server unittest @-G:Log=InliningDecisions ArrayListGetTest > > I see only the hosted x86 inlining decisions, not the hsail decisions. > > We are compiling the HSAIL with with code like the following: > > > public static HSAILCompilationResult getHSAILCompilationResult(StructuredGraph graph) { > Debug.dump(graph, "Graph"); > TargetDescription target = new TargetDescription(new HSAIL(), true, 1, 0, true); > HSAILBackend hsailBackend = new HSAILBackend(Graal.getRequiredCapability(GraalCodeCacheProvider.class), target); > PhasePlan phasePlan = new PhasePlan(); > GraphBuilderPhase graphBuilderPhase = new GraphBuilderPhase(runtime, GraphBuilderConfiguration.getDefault(), OptimisticOptimizations.NONE); > phasePlan.addPhase(PhasePosition.AFTER_PARSING, graphBuilderPhase); > phasePlan.addPhase(PhasePosition.AFTER_PARSING, new HSAILPhase()); > new HSAILPhase().apply(graph); > CallingConvention cc = getCallingConvention(runtime, Type.JavaCallee, graph.method(), false); > CompilationResult compResult = GraalCompiler.compileGraph(graph, cc, graph.method(), runtime, replacements, // graalRuntime().getReplacements(), hsailBackend, target, null, > phasePlan, OptimisticOptimizations.NONE, new SpeculationLog()); > > -- Tom Deneau > > > -----Original Message----- > From: Thomas Wuerthinger [mailto:thomas.wuerthinger at oracle.com] > Sent: Sunday, June 02, 2013 2:17 PM > To: Deneau, Tom > Cc: graal-dev at openjdk.java.net > Subject: Re: graal inlining decisions > > If you run with "--vm server", the host should be the server compiler and therefore not be affected by the "-G:Log" value. Additionally, you can choose to either limit the number of unit tests executed or apply a "-G:MethodFilter=" argument to reduce the output to certain patterns of methods. > > - thomas > > On May 29, 2013, at 1:22 AM, "Deneau, Tom" wrote: > >> Just to clarify, I would like to see the inlining decisions made when I compile for an HSAIL target, >> (not interested in any decisions made for the x86 host). >> >> When I use the line below with mx unittest I see only x86 decisions... >> >> -- Tom >> >> -----Original Message----- >> From: Mick Jordan [mailto:mick.jordan at oracle.com] >> Sent: Tuesday, May 28, 2013 11:08 AM >> To: Deneau, Tom >> Cc: graal-dev at openjdk.java.net >> Subject: Re: graal inlining decisions >> >> On 5/28/13 8:13 AM, Deneau, Tom wrote: >>> What would be the best command line to use to see what kind of inlining decisions are being made in graal? >>> >>> -- Tom >> This works for me: >> >> -G:Log=InliningDecisions >> >> Mick >> >> >> > > > From doug.simon at oracle.com Thu Jun 6 05:32:59 2013 From: doug.simon at oracle.com (Doug Simon) Date: Thu, 6 Jun 2013 14:32:59 +0200 Subject: graal inlining decisions In-Reply-To: References: <51A4D665.3020703@oracle.com> <03BC7756-57BA-454C-A4B0-CA47F3430B87@oracle.com> Message-ID: Pulling/applying this changeset may fix it: http://hg.openjdk.java.net/graal/graal/rev/6dfd53575553 On Jun 6, 2013, at 2:22 PM, Thomas Wuerthinger wrote: > Maybe you are missing a call to this method: "DebugEnvironment.initialize(System.out)" > Does dumping the graph to the IdealGraphVisualizer work in the code below? > > - thomas > > On Jun 3, 2013, at 2:04 PM, "Deneau, Tom" wrote: > >> Thomas -- >> >> I tried this command line >> mx --vm server unittest @-G:Log=InliningDecisions ArrayListGetTest >> >> which only runs a single test, and I did not see any inlining decisions logged (one method is being compiled by the graal hsail compiler in the above case) >> >> If I instead use a --vm graal command line >> mx --vm server unittest @-G:Log=InliningDecisions ArrayListGetTest >> >> I see only the hosted x86 inlining decisions, not the hsail decisions. >> >> We are compiling the HSAIL with with code like the following: >> >> >> public static HSAILCompilationResult getHSAILCompilationResult(StructuredGraph graph) { >> Debug.dump(graph, "Graph"); >> TargetDescription target = new TargetDescription(new HSAIL(), true, 1, 0, true); >> HSAILBackend hsailBackend = new HSAILBackend(Graal.getRequiredCapability(GraalCodeCacheProvider.class), target); >> PhasePlan phasePlan = new PhasePlan(); >> GraphBuilderPhase graphBuilderPhase = new GraphBuilderPhase(runtime, GraphBuilderConfiguration.getDefault(), OptimisticOptimizations.NONE); >> phasePlan.addPhase(PhasePosition.AFTER_PARSING, graphBuilderPhase); >> phasePlan.addPhase(PhasePosition.AFTER_PARSING, new HSAILPhase()); >> new HSAILPhase().apply(graph); >> CallingConvention cc = getCallingConvention(runtime, Type.JavaCallee, graph.method(), false); >> CompilationResult compResult = GraalCompiler.compileGraph(graph, cc, graph.method(), runtime, replacements, // graalRuntime().getReplacements(), hsailBackend, target, null, >> phasePlan, OptimisticOptimizations.NONE, new SpeculationLog()); >> >> -- Tom Deneau >> >> >> -----Original Message----- >> From: Thomas Wuerthinger [mailto:thomas.wuerthinger at oracle.com] >> Sent: Sunday, June 02, 2013 2:17 PM >> To: Deneau, Tom >> Cc: graal-dev at openjdk.java.net >> Subject: Re: graal inlining decisions >> >> If you run with "--vm server", the host should be the server compiler and therefore not be affected by the "-G:Log" value. Additionally, you can choose to either limit the number of unit tests executed or apply a "-G:MethodFilter=" argument to reduce the output to certain patterns of methods. >> >> - thomas >> >> On May 29, 2013, at 1:22 AM, "Deneau, Tom" wrote: >> >>> Just to clarify, I would like to see the inlining decisions made when I compile for an HSAIL target, >>> (not interested in any decisions made for the x86 host). >>> >>> When I use the line below with mx unittest I see only x86 decisions... >>> >>> -- Tom >>> >>> -----Original Message----- >>> From: Mick Jordan [mailto:mick.jordan at oracle.com] >>> Sent: Tuesday, May 28, 2013 11:08 AM >>> To: Deneau, Tom >>> Cc: graal-dev at openjdk.java.net >>> Subject: Re: graal inlining decisions >>> >>> On 5/28/13 8:13 AM, Deneau, Tom wrote: >>>> What would be the best command line to use to see what kind of inlining decisions are being made in graal? >>>> >>>> -- Tom >>> This works for me: >>> >>> -G:Log=InliningDecisions >>> >>> Mick >>> >>> >>> >> >> >> > From doug.simon at oracle.com Thu Jun 6 05:31:17 2013 From: doug.simon at oracle.com (doug.simon at oracle.com) Date: Thu, 06 Jun 2013 12:31:17 +0000 Subject: hg: graal/graal: 56 new changesets Message-ID: <20130606123808.0A11D48FF1@hg.openjdk.java.net> Changeset: a5d3e0973e83 Author: Christian Humer Date: 2013-06-03 20:28 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/a5d3e0973e83 Fixed @Specialization#executeWith order was ignored. ! graal/com.oracle.truffle.codegen.processor/src/com/oracle/truffle/codegen/processor/node/NodeCodeGenerator.java ! graal/com.oracle.truffle.codegen.processor/src/com/oracle/truffle/codegen/processor/template/TemplateMethod.java Changeset: e876c2a6954f Author: Doug Simon Date: 2013-06-03 21:59 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/e876c2a6954f extensible option system (GRAAL-27) partial conversion from GraalOptions to new system ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/DebugFilter.java ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/GraalCompiler.java ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/GraalDebugConfig.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/CompilationTask.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/CompilerThread.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/HotSpotOptions.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/bridge/VMToCompilerImpl.java + graal/com.oracle.graal.options/src/META-INF/services/javax.annotation.processing.Processor + graal/com.oracle.graal.options/src/com/oracle/graal/options/Option.java + graal/com.oracle.graal.options/src/com/oracle/graal/options/OptionProcessor.java + graal/com.oracle.graal.options/src/com/oracle/graal/options/OptionProvider.java + graal/com.oracle.graal.options/src/com/oracle/graal/options/OptionValue.java ! graal/com.oracle.graal.phases/src/com/oracle/graal/phases/GraalOptions.java ! graal/com.oracle.graal.printer/src/com/oracle/graal/printer/DebugEnvironment.java ! make/build-graal.xml ! mx/projects Changeset: 6e0c6526334b Author: Christos Kotselidis Date: 2013-06-04 10:55 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/6e0c6526334b Add HeapInfo interface for write barriers and compressed oops support ! graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/WriteBarrierAdditionTest.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotRuntime.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/phases/WriteBarrierAdditionPhase.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/phases/WriteBarrierVerificationPhase.java + graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/HeapAccess.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/extended/Access.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/extended/AccessNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/extended/FloatableAccessNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/extended/FloatingAccessNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/extended/FloatingReadNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/extended/ReadNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/extended/WriteNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/java/CompareAndSwapNode.java ! graal/com.oracle.graal.replacements/src/com/oracle/graal/replacements/nodes/DirectObjectStoreNode.java ! graal/com.oracle.graal.word/src/com/oracle/graal/word/phases/WordTypeRewriterPhase.java Changeset: 4249a3510413 Author: Christos Kotselidis Date: 2013-06-04 11:01 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/4249a3510413 Merge ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/extended/ReadNode.java Changeset: ed56953c514b Author: Christos Kotselidis Date: 2013-06-04 11:06 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/ed56953c514b Fix Checkstyle Error ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/HeapAccess.java Changeset: e45c7720b46b Author: Doug Simon Date: 2013-06-03 23:26 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/e45c7720b46b use package of generated OptionProvider to filter Graal options that are parsed from the HotSpot command line (GRAAL-27) ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/HotSpotOptions.java Changeset: 394f38496856 Author: Doug Simon Date: 2013-06-04 00:33 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/394f38496856 made projects inherit annotation processors from dependencies ! mxtool/mx.py Changeset: 6898d8995866 Author: Doug Simon Date: 2013-06-04 00:35 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/6898d8995866 converted more options from GraalOptions to new system (GRAAL-27) ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/GraalCompiler.java ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/GraalDebugConfig.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.hotspot/src/com/oracle/graal/hotspot/HotSpotGraalRuntime.java ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/InliningPhase.java ! graal/com.oracle.graal.phases/src/com/oracle/graal/phases/GraalOptions.java ! graal/com.oracle.graal.phases/src/com/oracle/graal/phases/tiers/Suites.java ! make/build-graal.xml ! mx/projects Changeset: fbeda9df497d Author: Doug Simon Date: 2013-06-04 12:21 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/fbeda9df497d implemented workaround for https://bugs.eclipse.org/bugs/show_bug.cgi?id=409824 ! graal/com.oracle.graal.hotspot.amd64/src/com/oracle/graal/hotspot/amd64/AMD64DeoptimizeOp.java ! graal/com.oracle.graal.hotspot.amd64/src/com/oracle/graal/hotspot/amd64/AMD64HotSpotCRuntimeCallEpilogueOp.java ! graal/com.oracle.graal.hotspot.amd64/src/com/oracle/graal/hotspot/amd64/AMD64HotSpotCRuntimeCallPrologueOp.java ! graal/com.oracle.graal.hotspot.amd64/src/com/oracle/graal/hotspot/amd64/AMD64HotSpotDeoptimizeCallerOp.java ! graal/com.oracle.graal.hotspot.amd64/src/com/oracle/graal/hotspot/amd64/AMD64HotSpotJumpToExceptionHandlerInCallerOp.java ! graal/com.oracle.graal.hotspot.amd64/src/com/oracle/graal/hotspot/amd64/AMD64HotSpotPatchReturnAddressOp.java ! graal/com.oracle.graal.hotspot.amd64/src/com/oracle/graal/hotspot/amd64/AMD64HotSpotReturnOp.java ! graal/com.oracle.graal.hotspot.amd64/src/com/oracle/graal/hotspot/amd64/AMD64HotSpotUnwindOp.java ! graal/com.oracle.graal.hotspot.amd64/src/com/oracle/graal/hotspot/amd64/AMD64HotspotDirectStaticCallOp.java ! graal/com.oracle.graal.hotspot.amd64/src/com/oracle/graal/hotspot/amd64/AMD64HotspotDirectVirtualCallOp.java ! graal/com.oracle.graal.hotspot.amd64/src/com/oracle/graal/hotspot/amd64/AMD64IndirectCallOp.java ! graal/com.oracle.graal.hotspot.amd64/src/com/oracle/graal/hotspot/amd64/AMD64SafepointOp.java ! graal/com.oracle.graal.hotspot.amd64/src/com/oracle/graal/hotspot/amd64/AMD64TailcallOp.java ! graal/com.oracle.graal.lir.amd64/src/com/oracle/graal/lir/amd64/AMD64BitManipulationOp.java ! graal/com.oracle.graal.lir.amd64/src/com/oracle/graal/lir/amd64/AMD64BreakpointOp.java ! graal/com.oracle.graal.lir.amd64/src/com/oracle/graal/lir/amd64/AMD64ByteSwapOp.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/AMD64Compare.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/AMD64MathIntrinsicOp.java ! graal/com.oracle.graal.lir.amd64/src/com/oracle/graal/lir/amd64/AMD64Move.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.ptx/src/com/oracle/graal/lir/ptx/PTXBitManipulationOp.java ! graal/com.oracle.graal.lir.ptx/src/com/oracle/graal/lir/ptx/PTXCompare.java ! graal/com.oracle.graal.lir.ptx/src/com/oracle/graal/lir/ptx/PTXMove.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/SPARCBreakpointOp.java ! graal/com.oracle.graal.lir.sparc/src/com/oracle/graal/lir/sparc/SPARCByteSwapOp.java ! graal/com.oracle.graal.lir.sparc/src/com/oracle/graal/lir/sparc/SPARCCompare.java ! 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/SPARCMathIntrinsicOp.java ! graal/com.oracle.graal.lir.sparc/src/com/oracle/graal/lir/sparc/SPARCMove.java ! graal/com.oracle.graal.lir/src/com/oracle/graal/lir/InfopointOp.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/Opcode.java Changeset: 719a290b8a23 Author: Doug Simon Date: 2013-06-04 15:22 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/719a290b8a23 added optional annotationProcessorForDependents attribute for a project to inject itself as an annotation processor for all dependents ! mx/projects ! mxtool/mx.py Changeset: 538ac2cf3383 Author: Doug Simon Date: 2013-06-04 15:22 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/538ac2cf3383 Merge. Changeset: 30cab249529e Author: Gilles Duboscq Date: 2013-06-04 16:53 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/30cab249529e When lowering a fixed guard, the usages should be forwarded to the floating guard instead of the value anchor. FixedGuardNode should have a dependency stamp ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotRuntime.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/FixedGuardNode.java Changeset: 6a0da51dfba4 Author: Gilles Duboscq Date: 2013-06-04 17:23 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/6a0da51dfba4 Handle Proxies and pi nodes better in the NodeIntrinsificationPhase ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/extended/ValueAnchorNode.java ! graal/com.oracle.graal.replacements/src/com/oracle/graal/replacements/NodeIntrinsificationPhase.java Changeset: 2d5c0f7ce7a1 Author: Gilles Duboscq Date: 2013-06-04 17:30 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/2d5c0f7ce7a1 Add a PiNode for the null-checked receiver during inlining ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/InliningUtil.java ! graal/com.oracle.graal.replacements/src/com/oracle/graal/replacements/NodeIntrinsificationPhase.java Changeset: 49fb2675c665 Author: Gilles Duboscq Date: 2013-06-04 19:21 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/49fb2675c665 UnsafeLoadNode should not assume that 'type' is non-null in an object stamp ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/extended/UnsafeLoadNode.java Changeset: b2141bc6e98e Author: Doug Simon Date: 2013-06-04 15:42 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/b2141bc6e98e option values are either initialized upon creation or they must provide a lazily initialized value ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/bridge/VMToCompilerImpl.java ! graal/com.oracle.graal.options/src/com/oracle/graal/options/OptionValue.java Changeset: 063a712fe8d8 Author: Doug Simon Date: 2013-06-04 17:33 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/063a712fe8d8 converted remaining options in GraalOptions to new system (GRAAL-27) ! graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/GraalCompilerTest.java ! graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/backend/AllocatorTest.java ! graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/ea/IterativeInliningTest.java ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/GraalCompiler.java ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/alloc/IntervalWalker.java ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/alloc/LinearScan.java ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/alloc/LinearScanWalker.java ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/alloc/MoveResolver.java ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/alloc/RegisterVerifier.java ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/gen/LIRGenerator.java ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/phases/HighTier.java ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/phases/MidTier.java ! graal/com.oracle.graal.hotspot.amd64/src/com/oracle/graal/hotspot/amd64/AMD64HotSpotBackend.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/AMD64SafepointOp.java ! graal/com.oracle.graal.hotspot.sparc/src/com/oracle/graal/hotspot/sparc/SPARCHotSpotBackend.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/CompilationTask.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/CompileTheWorld.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/HotSpotGraalRuntime.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/HotSpotOptions.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/bridge/VMToCompilerImpl.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotGraphCache.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotMethodData.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotResolvedJavaField.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/HotSpotRuntime.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/ArrayCopySnippets.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/CallSiteSubstitutions.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/CheckCastSnippets.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/HotSpotNmethodIntrinsics.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/InstanceOfSnippets.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/NewObjectSnippets.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/ObjectCloneSnippets.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/ReflectionGetCallerClassNode.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/TypeCheckSnippetUtils.java ! graal/com.oracle.graal.java/src/com/oracle/graal/java/BciBlockMapping.java ! graal/com.oracle.graal.java/src/com/oracle/graal/java/GraphBuilderPhase.java ! graal/com.oracle.graal.loop/src/com/oracle/graal/loop/LoopPolicies.java ! graal/com.oracle.graal.loop/src/com/oracle/graal/loop/LoopTransformations.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.phases.common/src/com/oracle/graal/phases/common/GuardLoweringPhase.java ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/InliningPhase.java ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/InliningUtil.java ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/LoweringPhase.java ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/SafepointInsertionPhase.java ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/TailDuplicationPhase.java ! graal/com.oracle.graal.phases/src/com/oracle/graal/phases/GraalOptions.java ! graal/com.oracle.graal.phases/src/com/oracle/graal/phases/OptimisticOptimizations.java ! graal/com.oracle.graal.phases/src/com/oracle/graal/phases/schedule/SchedulePhase.java ! graal/com.oracle.graal.printer/src/com/oracle/graal/printer/DebugEnvironment.java ! graal/com.oracle.graal.printer/src/com/oracle/graal/printer/GraphPrinterDumpHandler.java ! graal/com.oracle.graal.replacements/src/com/oracle/graal/replacements/BoxingSnippets.java ! graal/com.oracle.graal.replacements/src/com/oracle/graal/replacements/GraalMethodSubstitutions.java ! graal/com.oracle.graal.replacements/src/com/oracle/graal/replacements/ReplacementsImpl.java ! graal/com.oracle.graal.virtual/src/com/oracle/graal/virtual/phases/ea/IterativeInliningPhase.java ! graal/com.oracle.graal.virtual/src/com/oracle/graal/virtual/phases/ea/PartialEscapeAnalysisPhase.java ! graal/com.oracle.graal.virtual/src/com/oracle/graal/virtual/phases/ea/PartialEscapeClosure.java ! graal/com.oracle.graal.virtual/src/com/oracle/graal/virtual/phases/ea/VirtualUtil.java ! graal/com.oracle.graal.virtual/src/com/oracle/graal/virtual/phases/ea/VirtualizerToolImpl.java ! make/build-graal.xml Changeset: 9006bc30a951 Author: Doug Simon Date: 2013-06-04 18:11 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/9006bc30a951 add all enclosing elements of an annotated field as originating elements ! graal/com.oracle.graal.options/src/com/oracle/graal/options/OptionProcessor.java Changeset: 5ba11d51fe80 Author: Doug Simon Date: 2013-06-05 11:16 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/5ba11d51fe80 Merge. ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotRuntime.java ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/InliningUtil.java Changeset: 59181bf27144 Author: Bernhard Urban Date: 2013-05-27 17:14 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/59181bf27144 .hgignore: add files generated by coverage ! .hgignore Changeset: 9f764fbf3b0d Author: Bernhard Urban Date: 2013-05-31 11:38 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/9f764fbf3b0d VerifyUsageWithEquals: fix wording ! graal/com.oracle.graal.phases/src/com/oracle/graal/phases/verify/VerifyUsageWithEquals.java Changeset: 17e31cfaf037 Author: Bernhard Urban Date: 2013-06-05 11:48 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/17e31cfaf037 TestResolvedJavaMethod: relax check for max stack size ! graal/com.oracle.graal.api.meta.test/src/com/oracle/graal/api/meta/test/TestResolvedJavaMethod.java Changeset: c65bad5126b0 Author: Lukas Stadler Date: 2013-06-05 11:09 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/c65bad5126b0 pull HotSpotForeignCallLinkage.isLeaf into ForeignCallLinkage and rename to canDeoptimize ! graal/com.oracle.graal.api.code/src/com/oracle/graal/api/code/ForeignCallLinkage.java ! graal/com.oracle.graal.hotspot.amd64/src/com/oracle/graal/hotspot/amd64/AMD64HotSpotLIRGenerator.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/HotSpotForeignCallLinkage.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotRuntime.java Changeset: acba1a273f9b Author: Lukas Stadler Date: 2013-06-05 11:10 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/acba1a273f9b LIRGenerator.emitForeignCall uses linkage to determine if a state is needed ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/gen/LIRGenerator.java Changeset: 4391fd907278 Author: Lukas Stadler Date: 2013-06-05 11:34 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/4391fd907278 use StubForeignCallNode within stubs, instead of ForeignCallNode + graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/nodes/StubForeignCallNode.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/stubs/ExceptionHandlerStub.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/stubs/ForeignCallStub.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/stubs/NewArrayStub.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/stubs/NewInstanceStub.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/stubs/StubUtil.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/stubs/UnwindExceptionToCallerStub.java Changeset: d59b9078978c Author: Lukas Stadler Date: 2013-06-05 11:44 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/d59b9078978c use loadHub without null check in MonitorSnippets ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/HotSpotReplacementsUtil.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/MonitorSnippets.java Changeset: fb010fd0b384 Author: Lukas Stadler Date: 2013-06-05 11:44 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/fb010fd0b384 only create overflow guards for loops that have safepoints ! graal/com.oracle.graal.loop/src/com/oracle/graal/loop/phases/LoopSafepointEliminationPhase.java Changeset: 2c55e8c4a591 Author: Lukas Stadler Date: 2013-06-05 11:45 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/2c55e8c4a591 make ReadNode and WriteNode virtualizable ! 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 Changeset: 975cc822632a Author: Lukas Stadler Date: 2013-06-05 11:46 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/975cc822632a PEA phase only needs PhaseContext ! graal/com.oracle.graal.virtual/src/com/oracle/graal/virtual/phases/ea/PartialEscapeAnalysisPhase.java Changeset: fe02e8159afa Author: Lukas Stadler Date: 2013-06-05 11:47 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/fe02e8159afa PEA: changes to allow BlockState to be extended ! graal/com.oracle.graal.virtual/src/com/oracle/graal/virtual/phases/ea/BlockState.java ! graal/com.oracle.graal.virtual/src/com/oracle/graal/virtual/phases/ea/PartialEscapeClosure.java Changeset: d0a007fb65af Author: Lukas Stadler Date: 2013-06-05 11:50 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/d0a007fb65af simplify FrameStateAssignmentPhase, add guarantee that every DeoptimizingNode has a FrameState ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/FrameStateAssignmentPhase.java Changeset: bf6943c12840 Author: Lukas Stadler Date: 2013-06-05 12:05 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/bf6943c12840 allow for late lowering of MemoryCheckpoints (handle usages by FloatingReads in SnippetTemplate) ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/InsertStateAfterPlaceholderPhase.java ! graal/com.oracle.graal.replacements/src/com/oracle/graal/replacements/SnippetTemplate.java Changeset: f7ec3ec8a03c Author: Lukas Stadler Date: 2013-06-05 13:10 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/f7ec3ec8a03c HotSpotRuntime should decide when to lower which nodes, not the nodes themselves ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotRuntime.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/extended/OSRStartNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/java/NewArrayNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/java/NewInstanceNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/java/NewMultiArrayNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/spi/LoweringTool.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/virtual/CommitAllocationNode.java ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/LoweringPhase.java Changeset: 7779b1d5ba37 Author: Lukas Stadler Date: 2013-06-05 14:18 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/7779b1d5ba37 don't synthesize a deoptState in ForeignCallNode is canDeoptimize == false ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/extended/ForeignCallNode.java Changeset: cf071af51d94 Author: Christos Kotselidis Date: 2013-06-04 13:46 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/cf071af51d94 Crypto substitutions use unsafe loads to access fields ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/AESCryptSubstitutions.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/CipherBlockChainingSubstitutions.java Changeset: 477fb9a9a06d Author: Christos Kotselidis Date: 2013-06-04 13:54 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/477fb9a9a06d Delegate compressed oop arguments from HotSpot to Graal ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/HotSpotVMConfig.java ! make/build-graal.xml ! src/share/vm/graal/graalCompilerToVM.cpp Changeset: cecd40916b06 Author: Christos Kotselidis Date: 2013-06-04 17:14 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/cecd40916b06 Add scaling factor for arrays ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotRuntime.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/NewObjectSnippets.java ! make/build-graal.xml Changeset: ed86945795d5 Author: Christos Kotselidis Date: 2013-06-04 18:06 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/ed86945795d5 Add Compressed Oops support in LIR ! 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/AMD64HotSpotLIRGenerator.java ! graal/com.oracle.graal.lir.amd64/src/com/oracle/graal/lir/amd64/AMD64Move.java Changeset: d14b65dac937 Author: Christos Kotselidis Date: 2013-06-04 18:52 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/d14b65dac937 Reserve r12 for heap base address when compressed oops are enabled ! graal/com.oracle.graal.hotspot.amd64/src/com/oracle/graal/hotspot/amd64/AMD64HotSpotRegisterConfig.java Changeset: 4d5872186e76 Author: Christos Kotselidis Date: 2013-06-04 19:36 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/4d5872186e76 Add compressed oops support in Graal/Hotspot site ! src/share/vm/graal/graalCodeInstaller.cpp ! src/share/vm/graal/graalCompilerToVM.hpp ! src/share/vm/oops/klass.hpp ! src/share/vm/prims/unsafe.cpp Changeset: 3d658d3b56f5 Author: Christos Kotselidis Date: 2013-06-04 20:26 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/3d658d3b56f5 Attach compress info to Load/Store nodes ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotRuntime.java ! graal/com.oracle.graal.replacements/src/com/oracle/graal/replacements/nodes/DirectObjectStoreNode.java Changeset: eb3b9e05924b Author: Christos Kotselidis Date: 2013-06-04 21:07 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/eb3b9e05924b OSR Read nodes already have uncompressed references ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotRuntime.java Changeset: f902b6a71670 Author: Christos Kotselidis Date: 2013-06-05 11:26 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/f902b6a71670 Add CompressedOops unit tests + graal/com.oracle.graal.hotspot.test/src/com/oracle/graal/hotspot/test/CompressedOopTest.java Changeset: 558c73d8bdc0 Author: Christos Kotselidis Date: 2013-06-05 12:00 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/558c73d8bdc0 Add compressed oops support in comments' copying in CodeInstaller ! src/share/vm/graal/graalCodeInstaller.cpp Changeset: 3d965e61b5f6 Author: Christos Kotselidis Date: 2013-06-05 12:01 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/3d965e61b5f6 Unsuccessful attempt to save r12 when heap base is zero, verification uses it ! graal/com.oracle.graal.hotspot.amd64/src/com/oracle/graal/hotspot/amd64/AMD64HotSpotRegisterConfig.java Changeset: b132d7666ac8 Author: Christos Kotselidis Date: 2013-06-05 12:55 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/b132d7666ac8 Fix Check style error ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/NewObjectSnippets.java Changeset: 9d0031cf5df9 Author: Christos Kotselidis Date: 2013-06-05 12:55 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/9d0031cf5df9 Fix Assertion in LIR ! graal/com.oracle.graal.hotspot.amd64/src/com/oracle/graal/hotspot/amd64/AMD64HotSpotLIRGenerator.java Changeset: ab85c49630e2 Author: Christos Kotselidis Date: 2013-06-05 14:49 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/ab85c49630e2 Remove unused graal_mirror from klass ! src/share/vm/oops/klass.hpp Changeset: 5945a36ccba4 Author: Christos Kotselidis Date: 2013-06-05 15:11 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/5945a36ccba4 Merge ! 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/AMD64HotSpotLIRGenerator.java ! graal/com.oracle.graal.hotspot.amd64/src/com/oracle/graal/hotspot/amd64/AMD64HotSpotRegisterConfig.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotRuntime.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/NewObjectSnippets.java ! graal/com.oracle.graal.lir.amd64/src/com/oracle/graal/lir/amd64/AMD64Move.java ! make/build-graal.xml Changeset: 65e23a65de9d Author: Christos Kotselidis Date: 2013-06-05 18:35 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/65e23a65de9d Fix unit test ! graal/com.oracle.graal.hotspot.test/src/com/oracle/graal/hotspot/test/CompressedOopTest.java Changeset: 2f72106d54c7 Author: Christos Kotselidis Date: 2013-06-05 18:37 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/2f72106d54c7 Fix check style error ! graal/com.oracle.graal.hotspot.test/src/com/oracle/graal/hotspot/test/CompressedOopTest.java Changeset: 249e76a97031 Author: Christos Kotselidis Date: 2013-06-05 19:37 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/249e76a97031 Supress warning in Compressed Oopt Test ! graal/com.oracle.graal.hotspot.test/src/com/oracle/graal/hotspot/test/CompressedOopTest.java Changeset: f6a792c8e3ec Author: Doug Simon Date: 2013-06-06 08:51 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/f6a792c8e3ec added documentation for BytecodeFrame.rethrowException ! graal/com.oracle.graal.api.code/src/com/oracle/graal/api/code/BytecodeFrame.java ! graal/com.oracle.graal.java/src/com/oracle/graal/java/FrameStateBuilder.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/FrameState.java Changeset: 4fcd38b13eb1 Author: Doug Simon Date: 2013-06-06 10:09 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/4fcd38b13eb1 disabled emitting and checking of copyright header in files generated by OptionProcessor ! graal/com.oracle.graal.graph/.checkstyle_checks.xml ! graal/com.oracle.graal.options/src/com/oracle/graal/options/OptionProcessor.java Changeset: 6dfd53575553 Author: Doug Simon Date: 2013-06-06 10:10 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/6dfd53575553 re-enabled initialization of debug environment on main thread ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/bridge/VMToCompilerImpl.java Changeset: b621e2a690dd Author: Doug Simon Date: 2013-06-06 12:07 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/b621e2a690dd assert that -G: options are unique ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/HotSpotOptions.java From thomas.wuerthinger at oracle.com Thu Jun 6 06:31:40 2013 From: thomas.wuerthinger at oracle.com (Thomas Wuerthinger) Date: Thu, 6 Jun 2013 15:31:40 +0200 Subject: CFV: New Graal Committer: Christian Thalinger Message-ID: <2E1B2505-5545-48DE-8261-34D511843284@oracle.com> I hereby nominate Christian Thalinger to Graal committer. Christian has made the following significant contributions to the Graal OpenJDK source base: - Start of the experimental PTX backend [1]. - Support for JSR292 and invokedynamic [2]. - Support for CompileTheWorld functionality for footprint and compilation speed testing [3]. Votes are due June 20, 4:00 pm CET. Only current Graal committers are eligible to vote on this nomination [4]. For Lazy Consensus voting instructions, see [5]. - thomas [1] http://hg.openjdk.java.net/graal/graal/rev/bd5c6b3dedc5 [2] http://hg.openjdk.java.net/graal/graal/rev/447f9ba1962b [3] http://hg.openjdk.java.net/graal/graal/rev/b78686983a75 [4] http://openjdk.java.net/census#graal [5] http://openjdk.java.net/projects/#committer-vote From thomas.wuerthinger at oracle.com Thu Jun 6 06:31:45 2013 From: thomas.wuerthinger at oracle.com (Thomas Wuerthinger) Date: Thu, 6 Jun 2013 15:31:45 +0200 Subject: CFV: New Graal Committer: Morris Meyer Message-ID: I hereby nominate Morris Meyer to Graal committer. Morris has made the following significant contributions to the Graal OpenJDK source base: - Several enhancements to the PTX backend [1]. - Support for PTX code loading [2]. - Initial support for SPARC [3]. Votes are due June 20, 4:00 pm CET. Only current Graal committers are eligible to vote on this nomination [4]. For Lazy Consensus voting instructions, see [5]. - thomas [1] http://hg.openjdk.java.net/graal/graal/rev/585cc62fcdc5 [2] http://hg.openjdk.java.net/graal/graal/rev/147162b27799 [3] http://hg.openjdk.java.net/graal/graal/rev/4e9854086532 [4] http://openjdk.java.net/census#graal [5] http://openjdk.java.net/projects/#committer-vote From thomas.wuerthinger at oracle.com Thu Jun 6 06:31:52 2013 From: thomas.wuerthinger at oracle.com (Thomas Wuerthinger) Date: Thu, 6 Jun 2013 15:31:52 +0200 Subject: CFV: New Graal Committer: Roland Schatz Message-ID: I hereby nominate Roland Schatz to Graal committer. Roland has made more than 150 commits to the Graal OpenJDK source base, most notable areas of contribution: - Improvements to the linear-scan register allocator. - Improvements to the AMD64 backend. - Design of an extensible mechanism for declaring compiler phases. Votes are due June 20, 4:00 pm CET. Only current Graal committers are eligible to vote on this nomination [1]. For Lazy Consensus voting instructions, see [2]. - thomas [1] http://openjdk.java.net/census#graal [2] http://openjdk.java.net/projects/#committer-vote From thomas.wuerthinger at oracle.com Thu Jun 6 06:32:16 2013 From: thomas.wuerthinger at oracle.com (Thomas Wuerthinger) Date: Thu, 6 Jun 2013 15:32:16 +0200 Subject: CFV: New Graal Committer: Christian Humer Message-ID: <5B558376-F5B3-4243-955B-0E727C2DA229@oracle.com> I hereby nominate Christian Humer to Graal committer. Christian has made more than 150 commits to the Graal OpenJDK source base, most notable areas of contribution: - Support for annotation processors in the Graal build system. - Improvements to the Truffle API. - Design and implementation of the Truffle DSL for Truffle guest language implementors. Christian is a master student from the Johannes Kepler University Linz [1]. Votes are due June 20, 4:00 pm CET. Only current Graal committers are eligible to vote on this nomination [2]. For Lazy Consensus voting instructions, see [3]. - thomas [1] http://www.ssw.uni-linz.ac.at/General/Staff/Chumer/ [2] http://openjdk.java.net/census#graal [3] http://openjdk.java.net/projects/#committer-vote From doug.simon at oracle.com Thu Jun 6 06:46:55 2013 From: doug.simon at oracle.com (Doug Simon) Date: Thu, 6 Jun 2013 15:46:55 +0200 Subject: CFV: New Graal Committer: Morris Meyer In-Reply-To: References: Message-ID: Yes. On Jun 6, 2013, at 3:31 PM, Thomas Wuerthinger wrote: > I hereby nominate Morris Meyer to Graal committer. > > Morris has made the following significant contributions to the Graal OpenJDK source base: > - Several enhancements to the PTX backend [1]. > - Support for PTX code loading [2]. > - Initial support for SPARC [3]. > > Votes are due June 20, 4:00 pm CET. > > Only current Graal committers are eligible to vote on this nomination [4]. > For Lazy Consensus voting instructions, see [5]. > > - thomas > > [1] http://hg.openjdk.java.net/graal/graal/rev/585cc62fcdc5 > [2] http://hg.openjdk.java.net/graal/graal/rev/147162b27799 > [3] http://hg.openjdk.java.net/graal/graal/rev/4e9854086532 > [4] http://openjdk.java.net/census#graal > [5] http://openjdk.java.net/projects/#committer-vote From doug.simon at oracle.com Thu Jun 6 06:47:37 2013 From: doug.simon at oracle.com (Doug Simon) Date: Thu, 6 Jun 2013 15:47:37 +0200 Subject: CFV: New Graal Committer: Christian Thalinger In-Reply-To: <2E1B2505-5545-48DE-8261-34D511843284@oracle.com> References: <2E1B2505-5545-48DE-8261-34D511843284@oracle.com> Message-ID: Yes. On Jun 6, 2013, at 3:31 PM, Thomas Wuerthinger wrote: > I hereby nominate Christian Thalinger to Graal committer. > > Christian has made the following significant contributions to the Graal OpenJDK source base: > - Start of the experimental PTX backend [1]. > - Support for JSR292 and invokedynamic [2]. > - Support for CompileTheWorld functionality for footprint and compilation speed testing [3]. > > Votes are due June 20, 4:00 pm CET. > > Only current Graal committers are eligible to vote on this nomination [4]. > For Lazy Consensus voting instructions, see [5]. > > - thomas > > [1] http://hg.openjdk.java.net/graal/graal/rev/bd5c6b3dedc5 > [2] http://hg.openjdk.java.net/graal/graal/rev/447f9ba1962b > [3] http://hg.openjdk.java.net/graal/graal/rev/b78686983a75 > [4] http://openjdk.java.net/census#graal > [5] http://openjdk.java.net/projects/#committer-vote From doug.simon at oracle.com Thu Jun 6 06:48:05 2013 From: doug.simon at oracle.com (Doug Simon) Date: Thu, 6 Jun 2013 15:48:05 +0200 Subject: CFV: New Graal Committer: Roland Schatz In-Reply-To: References: Message-ID: Yes. On Jun 6, 2013, at 3:31 PM, Thomas Wuerthinger wrote: > I hereby nominate Roland Schatz to Graal committer. > > Roland has made more than 150 commits to the Graal OpenJDK source base, most notable areas of contribution: > - Improvements to the linear-scan register allocator. > - Improvements to the AMD64 backend. > - Design of an extensible mechanism for declaring compiler phases. > > Votes are due June 20, 4:00 pm CET. > > Only current Graal committers are eligible to vote on this nomination [1]. > For Lazy Consensus voting instructions, see [2]. > > - thomas > > [1] http://openjdk.java.net/census#graal > [2] http://openjdk.java.net/projects/#committer-vote From doug.simon at oracle.com Thu Jun 6 06:48:22 2013 From: doug.simon at oracle.com (Doug Simon) Date: Thu, 6 Jun 2013 15:48:22 +0200 Subject: CFV: New Graal Committer: Christian Humer In-Reply-To: <5B558376-F5B3-4243-955B-0E727C2DA229@oracle.com> References: <5B558376-F5B3-4243-955B-0E727C2DA229@oracle.com> Message-ID: Yes. On Jun 6, 2013, at 3:32 PM, Thomas Wuerthinger wrote: > I hereby nominate Christian Humer to Graal committer. > > Christian has made more than 150 commits to the Graal OpenJDK source base, most notable areas of contribution: > - Support for annotation processors in the Graal build system. > - Improvements to the Truffle API. > - Design and implementation of the Truffle DSL for Truffle guest language implementors. > > Christian is a master student from the Johannes Kepler University Linz [1]. > > Votes are due June 20, 4:00 pm CET. > > Only current Graal committers are eligible to vote on this nomination [2]. > For Lazy Consensus voting instructions, see [3]. > > - thomas > > [1] http://www.ssw.uni-linz.ac.at/General/Staff/Chumer/ > [2] http://openjdk.java.net/census#graal > [3] http://openjdk.java.net/projects/#committer-vote > From thomas.wuerthinger at oracle.com Thu Jun 6 06:51:12 2013 From: thomas.wuerthinger at oracle.com (Thomas Wuerthinger) Date: Thu, 6 Jun 2013 15:51:12 +0200 Subject: CFV: New Graal Committer: Christian Humer In-Reply-To: References: <5B558376-F5B3-4243-955B-0E727C2DA229@oracle.com> Message-ID: <27A66815-717C-4579-975D-4DA05C9045AD@oracle.com> Parse error. This is not a valid vote, Doug ;). See http://openjdk.java.net/projects/#committer-vote. - thomas On Jun 6, 2013, at 3:48 PM, Doug Simon wrote: > Yes. > > On Jun 6, 2013, at 3:32 PM, Thomas Wuerthinger wrote: > >> I hereby nominate Christian Humer to Graal committer. >> >> Christian has made more than 150 commits to the Graal OpenJDK source base, most notable areas of contribution: >> - Support for annotation processors in the Graal build system. >> - Improvements to the Truffle API. >> - Design and implementation of the Truffle DSL for Truffle guest language implementors. >> >> Christian is a master student from the Johannes Kepler University Linz [1]. >> >> Votes are due June 20, 4:00 pm CET. >> >> Only current Graal committers are eligible to vote on this nomination [2]. >> For Lazy Consensus voting instructions, see [3]. >> >> - thomas >> >> [1] http://www.ssw.uni-linz.ac.at/General/Staff/Chumer/ >> [2] http://openjdk.java.net/census#graal >> [3] http://openjdk.java.net/projects/#committer-vote >> > From doug.simon at oracle.com Thu Jun 6 06:55:24 2013 From: doug.simon at oracle.com (Doug Simon) Date: Thu, 6 Jun 2013 06:55:24 -0700 (PDT) Subject: CFV: New Graal Committer: Christian Humer In-Reply-To: <27A66815-717C-4579-975D-4DA05C9045AD@oracle.com> References: <5B558376-F5B3-4243-955B-0E727C2DA229@oracle.com> <27A66815-717C-4579-975D-4DA05C9045AD@oracle.com> Message-ID: Just wanted to make the candidates sweat through a spoilt vote ;-) On Jun 6, 2013, at 3:51 PM, Thomas Wuerthinger wrote: > Parse error. This is not a valid vote, Doug ;). See http://openjdk.java.net/projects/#committer-vote. > > - thomas > > On Jun 6, 2013, at 3:48 PM, Doug Simon wrote: > >> Yes. >> >> On Jun 6, 2013, at 3:32 PM, Thomas Wuerthinger wrote: >> >>> I hereby nominate Christian Humer to Graal committer. >>> >>> Christian has made more than 150 commits to the Graal OpenJDK source base, most notable areas of contribution: >>> - Support for annotation processors in the Graal build system. >>> - Improvements to the Truffle API. >>> - Design and implementation of the Truffle DSL for Truffle guest language implementors. >>> >>> Christian is a master student from the Johannes Kepler University Linz [1]. >>> >>> Votes are due June 20, 4:00 pm CET. >>> >>> Only current Graal committers are eligible to vote on this nomination [2]. >>> For Lazy Consensus voting instructions, see [3]. >>> >>> - thomas >>> >>> [1] http://www.ssw.uni-linz.ac.at/General/Staff/Chumer/ >>> [2] http://openjdk.java.net/census#graal >>> [3] http://openjdk.java.net/projects/#committer-vote >>> >> > From doug.simon at oracle.com Thu Jun 6 06:56:52 2013 From: doug.simon at oracle.com (Doug Simon) Date: Thu, 6 Jun 2013 06:56:52 -0700 (PDT) Subject: CFV: New Graal Committer: Christian Humer In-Reply-To: <5B558376-F5B3-4243-955B-0E727C2DA229@oracle.com> References: <5B558376-F5B3-4243-955B-0E727C2DA229@oracle.com> Message-ID: Vote: yes On Jun 6, 2013, at 3:32 PM, Thomas Wuerthinger wrote: > I hereby nominate Christian Humer to Graal committer. > > Christian has made more than 150 commits to the Graal OpenJDK source base, most notable areas of contribution: > - Support for annotation processors in the Graal build system. > - Improvements to the Truffle API. > - Design and implementation of the Truffle DSL for Truffle guest language implementors. > > Christian is a master student from the Johannes Kepler University Linz [1]. > > Votes are due June 20, 4:00 pm CET. > > Only current Graal committers are eligible to vote on this nomination [2]. > For Lazy Consensus voting instructions, see [3]. > > - thomas > > [1] http://www.ssw.uni-linz.ac.at/General/Staff/Chumer/ > [2] http://openjdk.java.net/census#graal > [3] http://openjdk.java.net/projects/#committer-vote > From doug.simon at oracle.com Thu Jun 6 06:56:21 2013 From: doug.simon at oracle.com (Doug Simon) Date: Thu, 6 Jun 2013 06:56:21 -0700 (PDT) Subject: CFV: New Graal Committer: Morris Meyer In-Reply-To: References: Message-ID: <5CBBE8B8-4DC5-4189-87A9-91E86AF9D45B@oracle.com> Vote: yes On Jun 6, 2013, at 3:31 PM, Thomas Wuerthinger wrote: > I hereby nominate Morris Meyer to Graal committer. > > Morris has made the following significant contributions to the Graal OpenJDK source base: > - Several enhancements to the PTX backend [1]. > - Support for PTX code loading [2]. > - Initial support for SPARC [3]. > > Votes are due June 20, 4:00 pm CET. > > Only current Graal committers are eligible to vote on this nomination [4]. > For Lazy Consensus voting instructions, see [5]. > > - thomas > > [1] http://hg.openjdk.java.net/graal/graal/rev/585cc62fcdc5 > [2] http://hg.openjdk.java.net/graal/graal/rev/147162b27799 > [3] http://hg.openjdk.java.net/graal/graal/rev/4e9854086532 > [4] http://openjdk.java.net/census#graal > [5] http://openjdk.java.net/projects/#committer-vote From doug.simon at oracle.com Thu Jun 6 06:56:08 2013 From: doug.simon at oracle.com (Doug Simon) Date: Thu, 6 Jun 2013 06:56:08 -0700 (PDT) Subject: CFV: New Graal Committer: Roland Schatz In-Reply-To: References: Message-ID: Vote: yes On Jun 6, 2013, at 3:31 PM, Thomas Wuerthinger wrote: > I hereby nominate Roland Schatz to Graal committer. > > Roland has made more than 150 commits to the Graal OpenJDK source base, most notable areas of contribution: > - Improvements to the linear-scan register allocator. > - Improvements to the AMD64 backend. > - Design of an extensible mechanism for declaring compiler phases. > > Votes are due June 20, 4:00 pm CET. > > Only current Graal committers are eligible to vote on this nomination [1]. > For Lazy Consensus voting instructions, see [2]. > > - thomas > > [1] http://openjdk.java.net/census#graal > [2] http://openjdk.java.net/projects/#committer-vote From doug.simon at oracle.com Thu Jun 6 06:55:48 2013 From: doug.simon at oracle.com (Doug Simon) Date: Thu, 6 Jun 2013 06:55:48 -0700 (PDT) Subject: CFV: New Graal Committer: Christian Thalinger In-Reply-To: <2E1B2505-5545-48DE-8261-34D511843284@oracle.com> References: <2E1B2505-5545-48DE-8261-34D511843284@oracle.com> Message-ID: <152BF09D-B6FC-45E7-87EC-66B22223C381@oracle.com> Vote: yes On Jun 6, 2013, at 3:31 PM, Thomas Wuerthinger wrote: > I hereby nominate Christian Thalinger to Graal committer. > > Christian has made the following significant contributions to the Graal OpenJDK source base: > - Start of the experimental PTX backend [1]. > - Support for JSR292 and invokedynamic [2]. > - Support for CompileTheWorld functionality for footprint and compilation speed testing [3]. > > Votes are due June 20, 4:00 pm CET. > > Only current Graal committers are eligible to vote on this nomination [4]. > For Lazy Consensus voting instructions, see [5]. > > - thomas > > [1] http://hg.openjdk.java.net/graal/graal/rev/bd5c6b3dedc5 > [2] http://hg.openjdk.java.net/graal/graal/rev/447f9ba1962b > [3] http://hg.openjdk.java.net/graal/graal/rev/b78686983a75 > [4] http://openjdk.java.net/census#graal > [5] http://openjdk.java.net/projects/#committer-vote From thomas.wuerthinger at oracle.com Thu Jun 6 06:58:56 2013 From: thomas.wuerthinger at oracle.com (Thomas Wuerthinger) Date: Thu, 6 Jun 2013 15:58:56 +0200 Subject: CFV: New Graal Committer: Christian Humer In-Reply-To: References: <5B558376-F5B3-4243-955B-0E727C2DA229@oracle.com> <27A66815-717C-4579-975D-4DA05C9045AD@oracle.com> Message-ID: <847B0B2A-76F5-4326-925F-2E947E502C2F@oracle.com> You are lucky. "Multiple votes are allowed but only the most recent vote will be counted." [1] - thomas [1] http://openjdk.java.net/projects/#project-committer On Jun 6, 2013, at 3:55 PM, Doug Simon wrote: > Just wanted to make the candidates sweat through a spoilt vote ;-) > > On Jun 6, 2013, at 3:51 PM, Thomas Wuerthinger wrote: > >> Parse error. This is not a valid vote, Doug ;). See http://openjdk.java.net/projects/#committer-vote. >> >> - thomas >> >> On Jun 6, 2013, at 3:48 PM, Doug Simon wrote: >> >>> Yes. >>> >>> On Jun 6, 2013, at 3:32 PM, Thomas Wuerthinger wrote: >>> >>>> I hereby nominate Christian Humer to Graal committer. >>>> >>>> Christian has made more than 150 commits to the Graal OpenJDK source base, most notable areas of contribution: >>>> - Support for annotation processors in the Graal build system. >>>> - Improvements to the Truffle API. >>>> - Design and implementation of the Truffle DSL for Truffle guest language implementors. >>>> >>>> Christian is a master student from the Johannes Kepler University Linz [1]. >>>> >>>> Votes are due June 20, 4:00 pm CET. >>>> >>>> Only current Graal committers are eligible to vote on this nomination [2]. >>>> For Lazy Consensus voting instructions, see [3]. >>>> >>>> - thomas >>>> >>>> [1] http://www.ssw.uni-linz.ac.at/General/Staff/Chumer/ >>>> [2] http://openjdk.java.net/census#graal >>>> [3] http://openjdk.java.net/projects/#committer-vote >>>> >>> >> > From doug.simon at oracle.com Thu Jun 6 07:06:42 2013 From: doug.simon at oracle.com (Doug Simon) Date: Thu, 6 Jun 2013 16:06:42 +0200 Subject: CFV: New Graal Committer: Christian Humer In-Reply-To: <847B0B2A-76F5-4326-925F-2E947E502C2F@oracle.com> References: <5B558376-F5B3-4243-955B-0E727C2DA229@oracle.com> <27A66815-717C-4579-975D-4DA05C9045AD@oracle.com> <847B0B2A-76F5-4326-925F-2E947E502C2F@oracle.com> Message-ID: But I only submitted one vote per candidate; the first emails were just "opinions" ;-) On Jun 6, 2013, at 3:58 PM, Thomas Wuerthinger wrote: > You are lucky. "Multiple votes are allowed but only the most recent vote will be counted." [1] > > - thomas > > [1] http://openjdk.java.net/projects/#project-committer > > On Jun 6, 2013, at 3:55 PM, Doug Simon wrote: > >> Just wanted to make the candidates sweat through a spoilt vote ;-) >> >> On Jun 6, 2013, at 3:51 PM, Thomas Wuerthinger wrote: >> >>> Parse error. This is not a valid vote, Doug ;). See http://openjdk.java.net/projects/#committer-vote. >>> >>> - thomas >>> >>> On Jun 6, 2013, at 3:48 PM, Doug Simon wrote: >>> >>>> Yes. >>>> >>>> On Jun 6, 2013, at 3:32 PM, Thomas Wuerthinger wrote: >>>> >>>>> I hereby nominate Christian Humer to Graal committer. >>>>> >>>>> Christian has made more than 150 commits to the Graal OpenJDK source base, most notable areas of contribution: >>>>> - Support for annotation processors in the Graal build system. >>>>> - Improvements to the Truffle API. >>>>> - Design and implementation of the Truffle DSL for Truffle guest language implementors. >>>>> >>>>> Christian is a master student from the Johannes Kepler University Linz [1]. >>>>> >>>>> Votes are due June 20, 4:00 pm CET. >>>>> >>>>> Only current Graal committers are eligible to vote on this nomination [2]. >>>>> For Lazy Consensus voting instructions, see [3]. >>>>> >>>>> - thomas >>>>> >>>>> [1] http://www.ssw.uni-linz.ac.at/General/Staff/Chumer/ >>>>> [2] http://openjdk.java.net/census#graal >>>>> [3] http://openjdk.java.net/projects/#committer-vote >>>>> >>>> >>> >> > From duboscq at ssw.jku.at Thu Jun 6 08:13:33 2013 From: duboscq at ssw.jku.at (Gilles Duboscq) Date: Thu, 6 Jun 2013 17:13:33 +0200 Subject: CFV: New Graal Committer: Roland Schatz In-Reply-To: References: Message-ID: Vote: yes On Thu, Jun 6, 2013 at 3:56 PM, Doug Simon wrote: > Vote: yes > > On Jun 6, 2013, at 3:31 PM, Thomas Wuerthinger < > thomas.wuerthinger at oracle.com> wrote: > > > I hereby nominate Roland Schatz to Graal committer. > > > > Roland has made more than 150 commits to the Graal OpenJDK source base, > most notable areas of contribution: > > - Improvements to the linear-scan register allocator. > > - Improvements to the AMD64 backend. > > - Design of an extensible mechanism for declaring compiler phases. > > > > Votes are due June 20, 4:00 pm CET. > > > > Only current Graal committers are eligible to vote on this nomination > [1]. > > For Lazy Consensus voting instructions, see [2]. > > > > - thomas > > > > [1] http://openjdk.java.net/census#graal > > [2] http://openjdk.java.net/projects/#committer-vote > > From duboscq at ssw.jku.at Thu Jun 6 08:14:25 2013 From: duboscq at ssw.jku.at (Gilles Duboscq) Date: Thu, 6 Jun 2013 17:14:25 +0200 Subject: CFV: New Graal Committer: Morris Meyer In-Reply-To: <5CBBE8B8-4DC5-4189-87A9-91E86AF9D45B@oracle.com> References: <5CBBE8B8-4DC5-4189-87A9-91E86AF9D45B@oracle.com> Message-ID: Vote: yes On Thu, Jun 6, 2013 at 3:56 PM, Doug Simon wrote: > Vote: yes > > On Jun 6, 2013, at 3:31 PM, Thomas Wuerthinger < > thomas.wuerthinger at oracle.com> wrote: > > > I hereby nominate Morris Meyer to Graal committer. > > > > Morris has made the following significant contributions to the Graal > OpenJDK source base: > > - Several enhancements to the PTX backend [1]. > > - Support for PTX code loading [2]. > > - Initial support for SPARC [3]. > > > > Votes are due June 20, 4:00 pm CET. > > > > Only current Graal committers are eligible to vote on this nomination > [4]. > > For Lazy Consensus voting instructions, see [5]. > > > > - thomas > > > > [1] http://hg.openjdk.java.net/graal/graal/rev/585cc62fcdc5 > > [2] http://hg.openjdk.java.net/graal/graal/rev/147162b27799 > > [3] http://hg.openjdk.java.net/graal/graal/rev/4e9854086532 > > [4] http://openjdk.java.net/census#graal > > [5] http://openjdk.java.net/projects/#committer-vote > > From duboscq at ssw.jku.at Thu Jun 6 08:14:45 2013 From: duboscq at ssw.jku.at (Gilles Duboscq) Date: Thu, 6 Jun 2013 17:14:45 +0200 Subject: CFV: New Graal Committer: Christian Thalinger In-Reply-To: <152BF09D-B6FC-45E7-87EC-66B22223C381@oracle.com> References: <2E1B2505-5545-48DE-8261-34D511843284@oracle.com> <152BF09D-B6FC-45E7-87EC-66B22223C381@oracle.com> Message-ID: Vote: yes On Thu, Jun 6, 2013 at 3:55 PM, Doug Simon wrote: > Vote: yes > > On Jun 6, 2013, at 3:31 PM, Thomas Wuerthinger < > thomas.wuerthinger at oracle.com> wrote: > > > I hereby nominate Christian Thalinger to Graal committer. > > > > Christian has made the following significant contributions to the Graal > OpenJDK source base: > > - Start of the experimental PTX backend [1]. > > - Support for JSR292 and invokedynamic [2]. > > - Support for CompileTheWorld functionality for footprint and > compilation speed testing [3]. > > > > Votes are due June 20, 4:00 pm CET. > > > > Only current Graal committers are eligible to vote on this nomination > [4]. > > For Lazy Consensus voting instructions, see [5]. > > > > - thomas > > > > [1] http://hg.openjdk.java.net/graal/graal/rev/bd5c6b3dedc5 > > [2] http://hg.openjdk.java.net/graal/graal/rev/447f9ba1962b > > [3] http://hg.openjdk.java.net/graal/graal/rev/b78686983a75 > > [4] http://openjdk.java.net/census#graal > > [5] http://openjdk.java.net/projects/#committer-vote > > From duboscq at ssw.jku.at Thu Jun 6 08:16:02 2013 From: duboscq at ssw.jku.at (Gilles Duboscq) Date: Thu, 6 Jun 2013 17:16:02 +0200 Subject: CFV: New Graal Committer: Christian Humer In-Reply-To: References: <5B558376-F5B3-4243-955B-0E727C2DA229@oracle.com> <27A66815-717C-4579-975D-4DA05C9045AD@oracle.com> <847B0B2A-76F5-4326-925F-2E947E502C2F@oracle.com> Message-ID: Vote: yes On Thu, Jun 6, 2013 at 4:06 PM, Doug Simon wrote: > But I only submitted one vote per candidate; the first emails were just > "opinions" ;-) > > On Jun 6, 2013, at 3:58 PM, Thomas Wuerthinger < > thomas.wuerthinger at oracle.com> wrote: > > > You are lucky. "Multiple votes are allowed but only the most recent vote > will be counted." [1] > > > > - thomas > > > > [1] http://openjdk.java.net/projects/#project-committer > > > > On Jun 6, 2013, at 3:55 PM, Doug Simon wrote: > > > >> Just wanted to make the candidates sweat through a spoilt vote ;-) > >> > >> On Jun 6, 2013, at 3:51 PM, Thomas Wuerthinger < > thomas.wuerthinger at oracle.com> wrote: > >> > >>> Parse error. This is not a valid vote, Doug ;). See > http://openjdk.java.net/projects/#committer-vote. > >>> > >>> - thomas > >>> > >>> On Jun 6, 2013, at 3:48 PM, Doug Simon wrote: > >>> > >>>> Yes. > >>>> > >>>> On Jun 6, 2013, at 3:32 PM, Thomas Wuerthinger < > thomas.wuerthinger at oracle.com> wrote: > >>>> > >>>>> I hereby nominate Christian Humer to Graal committer. > >>>>> > >>>>> Christian has made more than 150 commits to the Graal OpenJDK source > base, most notable areas of contribution: > >>>>> - Support for annotation processors in the Graal build system. > >>>>> - Improvements to the Truffle API. > >>>>> - Design and implementation of the Truffle DSL for Truffle guest > language implementors. > >>>>> > >>>>> Christian is a master student from the Johannes Kepler University > Linz [1]. > >>>>> > >>>>> Votes are due June 20, 4:00 pm CET. > >>>>> > >>>>> Only current Graal committers are eligible to vote on this > nomination [2]. > >>>>> For Lazy Consensus voting instructions, see [3]. > >>>>> > >>>>> - thomas > >>>>> > >>>>> [1] http://www.ssw.uni-linz.ac.at/General/Staff/Chumer/ > >>>>> [2] http://openjdk.java.net/census#graal > >>>>> [3] http://openjdk.java.net/projects/#committer-vote > >>>>> > >>>> > >>> > >> > > > > From lukas.stadler at jku.at Thu Jun 6 08:34:05 2013 From: lukas.stadler at jku.at (Lukas Stadler) Date: Thu, 6 Jun 2013 17:34:05 +0200 Subject: CFV: New Graal Committer: Roland Schatz In-Reply-To: References: Message-ID: Vote: yes On Jun 6, 2013, at 3:31 PM, Thomas Wuerthinger wrote: > I hereby nominate Roland Schatz to Graal committer. > > Roland has made more than 150 commits to the Graal OpenJDK source base, most notable areas of contribution: > - Improvements to the linear-scan register allocator. > - Improvements to the AMD64 backend. > - Design of an extensible mechanism for declaring compiler phases. > > Votes are due June 20, 4:00 pm CET. > > Only current Graal committers are eligible to vote on this nomination [1]. > For Lazy Consensus voting instructions, see [2]. > > - thomas > > [1] http://openjdk.java.net/census#graal > [2] http://openjdk.java.net/projects/#committer-vote From lukas.stadler at jku.at Thu Jun 6 08:34:24 2013 From: lukas.stadler at jku.at (Lukas Stadler) Date: Thu, 6 Jun 2013 17:34:24 +0200 Subject: CFV: New Graal Committer: Morris Meyer In-Reply-To: References: Message-ID: <3915EE02-983D-4C6B-AB85-5198707CB501@jku.at> Vote: yes On Jun 6, 2013, at 3:31 PM, Thomas Wuerthinger wrote: > I hereby nominate Morris Meyer to Graal committer. > > Morris has made the following significant contributions to the Graal OpenJDK source base: > - Several enhancements to the PTX backend [1]. > - Support for PTX code loading [2]. > - Initial support for SPARC [3]. > > Votes are due June 20, 4:00 pm CET. > > Only current Graal committers are eligible to vote on this nomination [4]. > For Lazy Consensus voting instructions, see [5]. > > - thomas > > [1] http://hg.openjdk.java.net/graal/graal/rev/585cc62fcdc5 > [2] http://hg.openjdk.java.net/graal/graal/rev/147162b27799 > [3] http://hg.openjdk.java.net/graal/graal/rev/4e9854086532 > [4] http://openjdk.java.net/census#graal > [5] http://openjdk.java.net/projects/#committer-vote From lukas.stadler at jku.at Thu Jun 6 08:34:50 2013 From: lukas.stadler at jku.at (Lukas Stadler) Date: Thu, 6 Jun 2013 17:34:50 +0200 Subject: CFV: New Graal Committer: Christian Thalinger In-Reply-To: <2E1B2505-5545-48DE-8261-34D511843284@oracle.com> References: <2E1B2505-5545-48DE-8261-34D511843284@oracle.com> Message-ID: Vote: yes On Jun 6, 2013, at 3:31 PM, Thomas Wuerthinger wrote: > I hereby nominate Christian Thalinger to Graal committer. > > Christian has made the following significant contributions to the Graal OpenJDK source base: > - Start of the experimental PTX backend [1]. > - Support for JSR292 and invokedynamic [2]. > - Support for CompileTheWorld functionality for footprint and compilation speed testing [3]. > > Votes are due June 20, 4:00 pm CET. > > Only current Graal committers are eligible to vote on this nomination [4]. > For Lazy Consensus voting instructions, see [5]. > > - thomas > > [1] http://hg.openjdk.java.net/graal/graal/rev/bd5c6b3dedc5 > [2] http://hg.openjdk.java.net/graal/graal/rev/447f9ba1962b > [3] http://hg.openjdk.java.net/graal/graal/rev/b78686983a75 > [4] http://openjdk.java.net/census#graal > [5] http://openjdk.java.net/projects/#committer-vote From lukas.stadler at jku.at Thu Jun 6 08:35:43 2013 From: lukas.stadler at jku.at (Lukas Stadler) Date: Thu, 6 Jun 2013 17:35:43 +0200 Subject: CFV: New Graal Committer: Christian Humer In-Reply-To: <5B558376-F5B3-4243-955B-0E727C2DA229@oracle.com> References: <5B558376-F5B3-4243-955B-0E727C2DA229@oracle.com> Message-ID: Vote: yes On Jun 6, 2013, at 3:32 PM, Thomas Wuerthinger wrote: > I hereby nominate Christian Humer to Graal committer. > > Christian has made more than 150 commits to the Graal OpenJDK source base, most notable areas of contribution: > - Support for annotation processors in the Graal build system. > - Improvements to the Truffle API. > - Design and implementation of the Truffle DSL for Truffle guest language implementors. > > Christian is a master student from the Johannes Kepler University Linz [1]. > > Votes are due June 20, 4:00 pm CET. > > Only current Graal committers are eligible to vote on this nomination [2]. > For Lazy Consensus voting instructions, see [3]. > > - thomas > > [1] http://www.ssw.uni-linz.ac.at/General/Staff/Chumer/ > [2] http://openjdk.java.net/census#graal > [3] http://openjdk.java.net/projects/#committer-vote > From christian.wimmer at oracle.com Thu Jun 6 08:55:27 2013 From: christian.wimmer at oracle.com (Christian Wimmer) Date: Thu, 06 Jun 2013 08:55:27 -0700 Subject: CFV: New Graal Committer: Christian Thalinger In-Reply-To: <2E1B2505-5545-48DE-8261-34D511843284@oracle.com> References: <2E1B2505-5545-48DE-8261-34D511843284@oracle.com> Message-ID: <51B0B0EF.8080105@oracle.com> Vote: yes On 06/06/2013 06:31 AM, Thomas Wuerthinger wrote: > I hereby nominate Christian Thalinger to Graal committer. > > Christian has made the following significant contributions to the Graal OpenJDK source base: > - Start of the experimental PTX backend [1]. > - Support for JSR292 and invokedynamic [2]. > - Support for CompileTheWorld functionality for footprint and compilation speed testing [3]. > > Votes are due June 20, 4:00 pm CET. > > Only current Graal committers are eligible to vote on this nomination [4]. > For Lazy Consensus voting instructions, see [5]. > > - thomas > > [1] http://hg.openjdk.java.net/graal/graal/rev/bd5c6b3dedc5 > [2] http://hg.openjdk.java.net/graal/graal/rev/447f9ba1962b > [3] http://hg.openjdk.java.net/graal/graal/rev/b78686983a75 > [4] http://openjdk.java.net/census#graal > [5] http://openjdk.java.net/projects/#committer-vote > From christian.wimmer at oracle.com Thu Jun 6 08:55:32 2013 From: christian.wimmer at oracle.com (Christian Wimmer) Date: Thu, 06 Jun 2013 08:55:32 -0700 Subject: CFV: New Graal Committer: Morris Meyer In-Reply-To: References: Message-ID: <51B0B0F4.6080500@oracle.com> Vote: yes On 06/06/2013 06:31 AM, Thomas Wuerthinger wrote: > I hereby nominate Morris Meyer to Graal committer. > > Morris has made the following significant contributions to the Graal OpenJDK source base: > - Several enhancements to the PTX backend [1]. > - Support for PTX code loading [2]. > - Initial support for SPARC [3]. > > Votes are due June 20, 4:00 pm CET. > > Only current Graal committers are eligible to vote on this nomination [4]. > For Lazy Consensus voting instructions, see [5]. > > - thomas > > [1] http://hg.openjdk.java.net/graal/graal/rev/585cc62fcdc5 > [2] http://hg.openjdk.java.net/graal/graal/rev/147162b27799 > [3] http://hg.openjdk.java.net/graal/graal/rev/4e9854086532 > [4] http://openjdk.java.net/census#graal > [5] http://openjdk.java.net/projects/#committer-vote > From christian.wimmer at oracle.com Thu Jun 6 08:55:37 2013 From: christian.wimmer at oracle.com (Christian Wimmer) Date: Thu, 6 Jun 2013 08:55:37 -0700 (PDT) Subject: CFV: New Graal Committer: Roland Schatz In-Reply-To: References: Message-ID: <51B0B0F9.7030405@oracle.com> Vote: yes On 06/06/2013 06:31 AM, Thomas Wuerthinger wrote: > I hereby nominate Roland Schatz to Graal committer. > > Roland has made more than 150 commits to the Graal OpenJDK source base, most notable areas of contribution: > - Improvements to the linear-scan register allocator. > - Improvements to the AMD64 backend. > - Design of an extensible mechanism for declaring compiler phases. > > Votes are due June 20, 4:00 pm CET. > > Only current Graal committers are eligible to vote on this nomination [1]. > For Lazy Consensus voting instructions, see [2]. > > - thomas > > [1] http://openjdk.java.net/census#graal > [2] http://openjdk.java.net/projects/#committer-vote > From christian.wimmer at oracle.com Thu Jun 6 08:55:43 2013 From: christian.wimmer at oracle.com (Christian Wimmer) Date: Thu, 06 Jun 2013 08:55:43 -0700 Subject: CFV: New Graal Committer: Christian Humer In-Reply-To: <5B558376-F5B3-4243-955B-0E727C2DA229@oracle.com> References: <5B558376-F5B3-4243-955B-0E727C2DA229@oracle.com> Message-ID: <51B0B0FF.6080605@oracle.com> Vote: yes On 06/06/2013 06:32 AM, Thomas Wuerthinger wrote: > I hereby nominate Christian Humer to Graal committer. > > Christian has made more than 150 commits to the Graal OpenJDK source base, most notable areas of contribution: > - Support for annotation processors in the Graal build system. > - Improvements to the Truffle API. > - Design and implementation of the Truffle DSL for Truffle guest language implementors. > > Christian is a master student from the Johannes Kepler University Linz [1]. > > Votes are due June 20, 4:00 pm CET. > > Only current Graal committers are eligible to vote on this nomination [2]. > For Lazy Consensus voting instructions, see [3]. > > - thomas > > [1] http://www.ssw.uni-linz.ac.at/General/Staff/Chumer/ > [2] http://openjdk.java.net/census#graal > [3] http://openjdk.java.net/projects/#committer-vote > From Vasanth.Venkatachalam at amd.com Thu Jun 6 11:19:14 2013 From: Vasanth.Venkatachalam at amd.com (Venkatachalam, Vasanth) Date: Thu, 6 Jun 2013 18:19:14 +0000 Subject: eclipse code format settings Message-ID: <5DD1503F815BD14889DC81D28643E3A73D8CD463@sausexdag06.amd.com> Thomas or Christian, Do either of you use Eclipse? If so, can you export your Eclipse code format settings for the Graal project and send them to me? That way, I can easily get my changes into the right formatting. Vasanth From christian.thalinger at oracle.com Thu Jun 6 11:23:30 2013 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Thu, 6 Jun 2013 11:23:30 -0700 Subject: eclipse code format settings In-Reply-To: <5DD1503F815BD14889DC81D28643E3A73D8CD463@sausexdag06.amd.com> References: <5DD1503F815BD14889DC81D28643E3A73D8CD463@sausexdag06.amd.com> Message-ID: On Jun 6, 2013, at 11:19 AM, "Venkatachalam, Vasanth" wrote: > Thomas or Christian, > > Do either of you use Eclipse? If so, can you export your Eclipse code format settings for the Graal project and send them to me? > That way, I can easily get my changes into the right formatting. I thought you folks use mx and ideinit? This should set up Eclipse with the right formatting settings among other things. -- Chris > > Vasanth From Vasanth.Venkatachalam at amd.com Thu Jun 6 11:34:22 2013 From: Vasanth.Venkatachalam at amd.com (Venkatachalam, Vasanth) Date: Thu, 6 Jun 2013 18:34:22 +0000 Subject: eclipse code format settings In-Reply-To: References: <5DD1503F815BD14889DC81D28643E3A73D8CD463@sausexdag06.amd.com> Message-ID: <5DD1503F815BD14889DC81D28643E3A73D8CD48E@sausexdag06.amd.com> Hi Christian, We did use mx ideinit when setting up the workspace. However, in Eclipse the formatters that show up are the built-in ones (Eclipse (built-in), Eclipse 2.1 (built-in), and Java Conventions (built-in)). Would it be okay to apply one of these to the whole code and if so which one? Vasanth From: Christian Thalinger [mailto:christian.thalinger at oracle.com] Sent: Thursday, June 06, 2013 1:24 PM To: Venkatachalam, Vasanth Cc: Thomas Wuerthinger (thomas.wuerthinger at oracle.com); graal-dev at openjdk.java.net Subject: Re: eclipse code format settings On Jun 6, 2013, at 11:19 AM, "Venkatachalam, Vasanth" > wrote: Thomas or Christian, Do either of you use Eclipse? If so, can you export your Eclipse code format settings for the Graal project and send them to me? That way, I can easily get my changes into the right formatting. I thought you folks use mx and ideinit? This should set up Eclipse with the right formatting settings among other things. -- Chris Vasanth From thomas.wuerthinger at oracle.com Thu Jun 6 11:38:06 2013 From: thomas.wuerthinger at oracle.com (Thomas Wuerthinger) Date: Thu, 06 Jun 2013 11:38:06 -0700 Subject: AW:Re: eclipse code format settings Message-ID: Yes. "./mx.sh ideinit" will create correctly set up eclipse project files. It uses project descriptions from the file at "mx/projects". You should also install the checkstyle eclipse plugin. - thomas Christian Thalinger hat geschrieben: On Jun 6, 2013, at 11:19 AM, "Venkatachalam, Vasanth" wrote: Thomas or Christian, ? Do either of you use Eclipse? If so, can you export your Eclipse code format settings for the Graal project and send them to me? That way, I can easily get my changes into the right formatting. I thought you folks use mx and ideinit? ?This should set up Eclipse with the right formatting settings among other things. -- Chris ? Vasanth From Vasanth.Venkatachalam at amd.com Thu Jun 6 11:55:55 2013 From: Vasanth.Venkatachalam at amd.com (Venkatachalam, Vasanth) Date: Thu, 6 Jun 2013 18:55:55 +0000 Subject: AW:Re: eclipse code format settings In-Reply-To: References: Message-ID: <5DD1503F815BD14889DC81D28643E3A73D8CD4EA@sausexdag06.amd.com> I have run mx ideinit and installed the checktyle plugin. Eclipse gives us a choice of formatters. When I go to project->properties->Java Code Style->Formatter, under the "Active Profile" drop down menu I see a choice of the following 4 formatters: Java Conventions [built-in] Eclipse [built-in] Eclipse 2.1 [built-in] Unmanaged profile 'Graal' Which one of these should I apply to the new projects I've created? Vasanth -----Original Message----- From: graal-dev-bounces at openjdk.java.net [mailto:graal-dev-bounces at openjdk.java.net] On Behalf Of Thomas Wuerthinger Sent: Thursday, June 06, 2013 1:38 PM To: christian.thalinger at oracle.com; Venkatachalam, Vasanth Cc: graal-dev at openjdk.java.net Subject: AW:Re: eclipse code format settings Yes. "./mx.sh ideinit" will create correctly set up eclipse project files. It uses project descriptions from the file at "mx/projects". You should also install the checkstyle eclipse plugin. - thomas Christian Thalinger hat geschrieben: On Jun 6, 2013, at 11:19 AM, "Venkatachalam, Vasanth" wrote: Thomas or Christian, ? Do either of you use Eclipse? If so, can you export your Eclipse code format settings for the Graal project and send them to me? That way, I can easily get my changes into the right formatting. I thought you folks use mx and ideinit? ?This should set up Eclipse with the right formatting settings among other things. -- Chris ? Vasanth From duboscq at ssw.jku.at Thu Jun 6 12:04:09 2013 From: duboscq at ssw.jku.at (Gilles Duboscq) Date: Thu, 6 Jun 2013 21:04:09 +0200 Subject: AW:Re: eclipse code format settings In-Reply-To: <5DD1503F815BD14889DC81D28643E3A73D8CD4EA@sausexdag06.amd.com> References: <5DD1503F815BD14889DC81D28643E3A73D8CD4EA@sausexdag06.amd.com> Message-ID: The 'Graal' one but this is strange because it should be automatically selected for all the graal projects, this is setup in the generated projects. Which version of eclipse are you using? -Gilles On Thu, Jun 6, 2013 at 8:55 PM, Vasanth Venkatachalam < Vasanth.Venkatachalam at amd.com> wrote: > I have run mx ideinit and installed the checktyle plugin. Eclipse gives us > a choice of formatters. > When I go to project->properties->Java Code Style->Formatter, under the > "Active Profile" drop down menu I see a choice of the following 4 > formatters: > > Java Conventions [built-in] > Eclipse [built-in] > Eclipse 2.1 [built-in] > Unmanaged profile 'Graal' > > Which one of these should I apply to the new projects I've created? > > Vasanth > > -----Original Message----- > From: graal-dev-bounces at openjdk.java.net [mailto: > graal-dev-bounces at openjdk.java.net] On Behalf Of Thomas Wuerthinger > Sent: Thursday, June 06, 2013 1:38 PM > To: christian.thalinger at oracle.com; Venkatachalam, Vasanth > Cc: graal-dev at openjdk.java.net > Subject: AW:Re: eclipse code format settings > > Yes. "./mx.sh ideinit" will create correctly set up eclipse project files. > It uses project descriptions from the file at "mx/projects". You should > also install the checkstyle eclipse plugin. > > - thomas > > Christian Thalinger hat geschrieben: > > > On Jun 6, 2013, at 11:19 AM, "Venkatachalam, Vasanth" < > Vasanth.Venkatachalam at amd.com> wrote: > > Thomas or Christian, > > Do either of you use Eclipse? If so, can you export your Eclipse code > format settings for the Graal project and send them to me? > That way, I can easily get my changes into the right formatting. > > I thought you folks use mx and ideinit? This should set up Eclipse with > the right formatting settings among other things. > > -- Chris > > > Vasanth > > From Christian.Haeubl at jku.at Thu Jun 6 13:36:41 2013 From: Christian.Haeubl at jku.at (Christian Haeubl) Date: Thu, 06 Jun 2013 22:36:41 +0200 Subject: CFV: New Graal Committer: Christian Humer In-Reply-To: <5B558376-F5B3-4243-955B-0E727C2DA229@oracle.com> References: <5B558376-F5B3-4243-955B-0E727C2DA229@oracle.com> Message-ID: <51B10EF9020000AC000A7998@gwia1.im.jku.at> Vote: yes >>> Thomas Wuerthinger 06.06.13 15.33 Uhr >>> I hereby nominate Christian Humer to Graal committer. Christian has made more than 150 commits to the Graal OpenJDK source base, most notable areas of contribution: - Support for annotation processors in the Graal build system. - Improvements to the Truffle API. - Design and implementation of the Truffle DSL for Truffle guest language implementors. Christian is a master student from the Johannes Kepler University Linz [1]. Votes are due June 20, 4:00 pm CET. Only current Graal committers are eligible to vote on this nomination [2]. For Lazy Consensus voting instructions, see [3]. - thomas [1] http://www.ssw.uni-linz.ac.at/General/Staff/Chumer/ [2] http://openjdk.java.net/census#graal [3] http://openjdk.java.net/projects/#committer-vote From Christian.Haeubl at jku.at Thu Jun 6 13:36:36 2013 From: Christian.Haeubl at jku.at (Christian Haeubl) Date: Thu, 06 Jun 2013 22:36:36 +0200 Subject: CFV: New Graal Committer: Christian Thalinger In-Reply-To: <2E1B2505-5545-48DE-8261-34D511843284@oracle.com> References: <2E1B2505-5545-48DE-8261-34D511843284@oracle.com> Message-ID: <51B10EF4020000AC000A7994@gwia1.im.jku.at> Vote: yes >>> Thomas Wuerthinger 06.06.13 15.32 Uhr >>> I hereby nominate Christian Thalinger to Graal committer. Christian has made the following significant contributions to the Graal OpenJDK source base: - Start of the experimental PTX backend [1]. - Support for JSR292 and invokedynamic [2]. - Support for CompileTheWorld functionality for footprint and compilation speed testing [3]. Votes are due June 20, 4:00 pm CET. Only current Graal committers are eligible to vote on this nomination [4]. For Lazy Consensus voting instructions, see [5]. - thomas [1] http://hg.openjdk.java.net/graal/graal/rev/bd5c6b3dedc5 [2] http://hg.openjdk.java.net/graal/graal/rev/447f9ba1962b [3] http://hg.openjdk.java.net/graal/graal/rev/b78686983a75 [4] http://openjdk.java.net/census#graal [5] http://openjdk.java.net/projects/#committer-vote From Christian.Haeubl at jku.at Thu Jun 6 13:36:50 2013 From: Christian.Haeubl at jku.at (Christian Haeubl) Date: Thu, 06 Jun 2013 22:36:50 +0200 Subject: CFV: New Graal Committer: Morris Meyer In-Reply-To: References: Message-ID: <51B10F02020000AC000A799C@gwia1.im.jku.at> Vote: yes >>> Thomas Wuerthinger 06.06.13 15.33 Uhr >>> I hereby nominate Morris Meyer to Graal committer. Morris has made the following significant contributions to the Graal OpenJDK source base: - Several enhancements to the PTX backend [1]. - Support for PTX code loading [2]. - Initial support for SPARC [3]. Votes are due June 20, 4:00 pm CET. Only current Graal committers are eligible to vote on this nomination [4]. For Lazy Consensus voting instructions, see [5]. - thomas [1] http://hg.openjdk.java.net/graal/graal/rev/585cc62fcdc5 [2] http://hg.openjdk.java.net/graal/graal/rev/147162b27799 [3] http://hg.openjdk.java.net/graal/graal/rev/4e9854086532 [4] http://openjdk.java.net/census#graal [5] http://openjdk.java.net/projects/#committer-vote From Christian.Haeubl at jku.at Thu Jun 6 13:36:57 2013 From: Christian.Haeubl at jku.at (Christian Haeubl) Date: Thu, 06 Jun 2013 22:36:57 +0200 Subject: CFV: New Graal Committer: Roland Schatz In-Reply-To: References: Message-ID: <51B10F09020000AC000A79A2@gwia1.im.jku.at> Vote: yes >>> Thomas Wuerthinger 06.06.13 15.34 Uhr >>> I hereby nominate Roland Schatz to Graal committer. Roland has made more than 150 commits to the Graal OpenJDK source base, most notable areas of contribution: - Improvements to the linear-scan register allocator. - Improvements to the AMD64 backend. - Design of an extensible mechanism for declaring compiler phases. Votes are due June 20, 4:00 pm CET. Only current Graal committers are eligible to vote on this nomination [1]. For Lazy Consensus voting instructions, see [2]. - thomas [1] http://openjdk.java.net/census#graal [2] http://openjdk.java.net/projects/#committer-vote From doug.simon at oracle.com Sat Jun 8 18:00:12 2013 From: doug.simon at oracle.com (doug.simon at oracle.com) Date: Sun, 09 Jun 2013 01:00:12 +0000 Subject: hg: graal/graal: 46 new changesets Message-ID: <20130609010250.C3F08480CE@hg.openjdk.java.net> Changeset: 77c4b6c9d6e2 Author: Bernhard Urban Date: 2013-06-05 21:17 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/77c4b6c9d6e2 CanonicalizerPhase: move comment ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/CanonicalizerPhase.java Changeset: 97cabe2c4642 Author: Bernhard Urban Date: 2013-06-05 21:17 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/97cabe2c4642 PartialEscapeAnalysisPhase: remove constructor for CustomCanonicalizer ! graal/com.oracle.graal.virtual/src/com/oracle/graal/virtual/phases/ea/PartialEscapeAnalysisPhase.java Changeset: fc93d919f896 Author: Bernhard Urban Date: 2013-06-05 21:17 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/fc93d919f896 PhaseContext: add an instance of CanonicalizerPhase to context ! graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/BoxingEliminationTest.java ! graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/FloatingReadTest.java ! graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/MemoryScheduleTest.java ! graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/PushNodesThroughPiTest.java ! graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/ReadAfterCheckCastTest.java ! graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/WriteBarrierAdditionTest.java ! graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/WriteBarrierVerificationTest.java ! graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/ea/EscapeAnalysisTest.java ! graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/ea/IterativeInliningTest.java ! graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/ea/PEAReadEliminationTest.java ! graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/ea/PartialEscapeAnalysisTest.java ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/GraalCompiler.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/ArrayCopyNode.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/InliningUtil.java ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/TailDuplicationPhase.java ! graal/com.oracle.graal.phases/src/com/oracle/graal/phases/tiers/HighTierContext.java ! graal/com.oracle.graal.phases/src/com/oracle/graal/phases/tiers/LowTierContext.java ! graal/com.oracle.graal.phases/src/com/oracle/graal/phases/tiers/MidTierContext.java ! graal/com.oracle.graal.phases/src/com/oracle/graal/phases/tiers/PhaseContext.java ! graal/com.oracle.graal.virtual/src/com/oracle/graal/virtual/phases/ea/IterativeInliningPhase.java ! graal/com.oracle.graal.virtual/src/com/oracle/graal/virtual/phases/ea/PartialEscapeAnalysisPhase.java Changeset: 7e0a3f8fbd70 Author: Bernhard Urban Date: 2013-06-06 09:26 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/7e0a3f8fbd70 CanonicalizerPhase: add phase that obtains the canonicalizer from the context ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/phases/HighTier.java ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/phases/MidTier.java ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/CanonicalizerPhase.java Changeset: 91295caf53b6 Author: Bernhard Urban Date: 2013-06-06 11:04 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/91295caf53b6 CanonicalizerPhase: add OptCanonicalizeReads option (GRAAL-290) ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/GraalCompiler.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/ArrayCopyNode.java ! graal/com.oracle.graal.loop/src/com/oracle/graal/loop/LoopTransformations.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/extended/ReadNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/java/LoadFieldNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/spi/CanonicalizerTool.java ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/CanonicalizerPhase.java ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/IncrementalCanonicalizerPhase.java ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/InliningPhase.java ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/InliningUtil.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/TailDuplicationPhase.java ! graal/com.oracle.graal.phases/src/com/oracle/graal/phases/GraalOptions.java ! graal/com.oracle.graal.replacements/src/com/oracle/graal/replacements/ReplacementsImpl.java ! graal/com.oracle.graal.replacements/src/com/oracle/graal/replacements/SnippetTemplate.java Changeset: 8fdee70e2e1f Author: Bernhard Urban Date: 2013-06-06 11:04 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/8fdee70e2e1f CanonicalizerPhase: add OptCanonicalizeReads option (adapt tests) ! graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/BoxingEliminationTest.java ! graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/CompareCanonicalizerTest.java ! graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/DegeneratedLoopsTest.java ! graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/EliminateNestedCheckCastsTest.java ! graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/FinalizableSubclassTest.java ! graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/FloatingReadTest.java ! graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/IfCanonicalizerTest.java ! graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/InvokeExceptionTest.java ! graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/InvokeHintsTest.java ! graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/LoopUnswitchTest.java ! graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/MemoryScheduleTest.java ! graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/MonitorGraphTest.java ! graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/PushNodesThroughPiTest.java ! graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/ReadAfterCheckCastTest.java ! graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/ReassociateAndCanonicalTest.java ! graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/ScalarTypeSystemTest.java ! graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/StampCanonicalizerTest.java ! graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/StraighteningTest.java ! graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/TypeSystemTest.java ! graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/WriteBarrierAdditionTest.java ! graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/WriteBarrierVerificationTest.java ! graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/deopt/CompiledMethodTest.java ! graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/ea/EscapeAnalysisTest.java ! graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/ea/IterativeInliningTest.java ! graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/ea/PEAReadEliminationTest.java ! graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/ea/PartialEscapeAnalysisTest.java ! graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/inlining/InliningTest.java ! graal/com.oracle.graal.replacements.test/src/com/oracle/graal/replacements/test/MethodSubstitutionTest.java ! make/build-graal.xml Changeset: 1dd50a788ab7 Author: Bernhard Urban Date: 2013-06-06 11:36 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/1dd50a788ab7 unittest: add test for OptCanonicalizeReads + graal/com.oracle.graal.hotspot.test/src/com/oracle/graal/hotspot/test/AheadOfTimeCompilationTest.java Changeset: 6ceff6124679 Author: Bernhard Urban Date: 2013-06-06 13:09 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/6ceff6124679 unittest/ctw: restore modified option after executing tests ! graal/com.oracle.graal.hotspot.test/src/com/oracle/graal/hotspot/test/CompileTheWorldTest.java Changeset: fbad7372eccd Author: Doug Simon Date: 2013-06-06 15:35 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/fbad7372eccd added support for stable options ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/GraalCompiler.java ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/GraalDebugConfig.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/CompilationTask.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/HotSpotGraalRuntime.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/HotSpotOptions.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/bridge/VMToCompilerImpl.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotResolvedJavaField.java ! graal/com.oracle.graal.options/src/com/oracle/graal/options/OptionValue.java ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/InliningPhase.java ! graal/com.oracle.graal.phases/src/com/oracle/graal/phases/GraalOptions.java ! graal/com.oracle.graal.phases/src/com/oracle/graal/phases/tiers/Suites.java Changeset: 35f93560b1f0 Author: Doug Simon Date: 2013-06-06 17:27 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/35f93560b1f0 ensure that for HotSpotOptions is called irrespective of whether and -G: options are specified ! src/share/vm/graal/graalCompiler.cpp ! src/share/vm/graal/graalVMToCompiler.cpp ! src/share/vm/graal/graalVMToCompiler.hpp Changeset: 84890660eefb Author: Doug Simon Date: 2013-06-06 17:29 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/84890660eefb cleaner implementation of stable options ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/GraalCompiler.java ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/GraalDebugConfig.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/CompilationTask.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/HotSpotGraalRuntime.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/bridge/VMToCompilerImpl.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotResolvedJavaField.java ! graal/com.oracle.graal.options/src/com/oracle/graal/options/OptionValue.java + graal/com.oracle.graal.options/src/com/oracle/graal/options/StableOptionValue.java ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/InliningPhase.java ! graal/com.oracle.graal.phases/src/com/oracle/graal/phases/GraalOptions.java ! graal/com.oracle.graal.phases/src/com/oracle/graal/phases/tiers/Suites.java Changeset: d8a8d794f631 Author: Gilles Duboscq Date: 2013-06-06 20:02 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/d8a8d794f631 More precise inlining decision messages. Use maximumNodes as an inclusive limit for relevence based inlining. ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/InliningPhase.java Changeset: 491cd7d69539 Author: Bernhard Urban Date: 2013-06-06 16:30 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/491cd7d69539 CanonicalizerPhase: remove it from context, add it to tiers instead and configure/pass it there (GRAAL-309) ! graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/BoxingEliminationTest.java ! graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/FloatingReadTest.java ! graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/MemoryScheduleTest.java ! graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/PushNodesThroughPiTest.java ! graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/ReadAfterCheckCastTest.java ! graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/WriteBarrierAdditionTest.java ! graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/WriteBarrierVerificationTest.java ! graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/ea/EscapeAnalysisTest.java ! graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/ea/IterativeInliningTest.java ! graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/ea/PEAReadEliminationTest.java ! graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/ea/PartialEscapeAnalysisTest.java ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/GraalCompiler.java ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/phases/HighTier.java ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/phases/MidTier.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/ArrayCopyNode.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/InliningUtil.java ! graal/com.oracle.graal.phases/src/com/oracle/graal/phases/tiers/HighTierContext.java ! graal/com.oracle.graal.phases/src/com/oracle/graal/phases/tiers/LowTierContext.java ! graal/com.oracle.graal.phases/src/com/oracle/graal/phases/tiers/MidTierContext.java ! graal/com.oracle.graal.phases/src/com/oracle/graal/phases/tiers/PhaseContext.java ! graal/com.oracle.graal.virtual/src/com/oracle/graal/virtual/phases/ea/IterativeInliningPhase.java ! graal/com.oracle.graal.virtual/src/com/oracle/graal/virtual/phases/ea/PartialEscapeAnalysisPhase.java Changeset: 2c82f780bff5 Author: Bernhard Urban Date: 2013-06-06 17:26 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/2c82f780bff5 CanonicalizerPhase: pass flag to fullUnroll ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/phases/HighTier.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/ArrayCopyNode.java ! graal/com.oracle.graal.loop/src/com/oracle/graal/loop/LoopTransformations.java ! graal/com.oracle.graal.loop/src/com/oracle/graal/loop/phases/LoopFullUnrollPhase.java ! graal/com.oracle.graal.replacements/src/com/oracle/graal/replacements/SnippetTemplate.java Changeset: ab90954e5fec Author: Bernhard Urban Date: 2013-06-06 21:22 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/ab90954e5fec unittest/aot: disable one part of the test setting the option to a different value after it was already used, is not a good idea. I've to come up with a different solution to test it. ! graal/com.oracle.graal.hotspot.test/src/com/oracle/graal/hotspot/test/AheadOfTimeCompilationTest.java Changeset: af909f4b80a9 Author: Doug Simon Date: 2013-06-06 23:16 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/af909f4b80a9 options are grouped per top level class/interface when accessed via the service mechanism ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/HotSpotOptions.java ! graal/com.oracle.graal.options/src/com/oracle/graal/options/Option.java + graal/com.oracle.graal.options/src/com/oracle/graal/options/OptionDescriptor.java ! graal/com.oracle.graal.options/src/com/oracle/graal/options/OptionProcessor.java - graal/com.oracle.graal.options/src/com/oracle/graal/options/OptionProvider.java ! graal/com.oracle.graal.options/src/com/oracle/graal/options/OptionValue.java + graal/com.oracle.graal.options/src/com/oracle/graal/options/Options.java ! graal/com.oracle.graal.options/src/com/oracle/graal/options/StableOptionValue.java ! make/build-graal.xml Changeset: 44fcf49b746f Author: Doug Simon Date: 2013-06-07 10:52 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/44fcf49b746f fixed class initialization ordering issue; HotSpotOptions. must not trigger initialization of other classes that depend on the effect of option setting in their ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/CompilationTask.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/bridge/VMToCompilerImpl.java ! make/build-graal.xml Changeset: 26785bb7006d Author: Christian Haeubl Date: 2013-05-21 10:34 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/26785bb7006d Refactorings for the InliningPhase. - graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/InlineableElement.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/StructuredGraph.java ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/InliningPhase.java ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/InliningUtil.java Changeset: 7bd4a69b4ce1 Author: Christian Haeubl Date: 2013-05-21 11:36 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/7bd4a69b4ce1 Added #ifdefs to nmethod statistics. ! src/share/vm/code/nmethod.cpp Changeset: 89cbd0119dc5 Author: Christian Haeubl Date: 2013-05-21 11:38 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/89cbd0119dc5 Added comment to explain the generics of AbstractJavaProfile. ! graal/com.oracle.graal.api.meta/src/com/oracle/graal/api/meta/AbstractJavaProfile.java Changeset: 6c7f40e6effd Author: Christian Haeubl Date: 2013-05-22 17:29 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/6c7f40e6effd Minor refactoring. ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/InliningUtil.java Changeset: 07e76b6fcc38 Author: Christian Haeubl Date: 2013-05-23 13:51 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/07e76b6fcc38 Backed out changeset: 7bd4a69b4ce1 ! src/share/vm/code/nmethod.cpp Changeset: fe9a97ee352b Author: Christian Haeubl Date: 2013-06-07 13:43 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/fe9a97ee352b Added more profiling information testcases. ! graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/ProfilingInfoTest.java Changeset: 81b298e0868b Author: Christian Haeubl Date: 2013-06-07 14:15 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/81b298e0868b Merge. - graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/extended/ForeignCallStateSplitNode.java ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/InliningPhase.java ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/InliningUtil.java - graal/com.oracle.graal.phases/src/com/oracle/graal/phases/verify/VerifyValueUsage.java Changeset: a9311ec68721 Author: Christian Haeubl Date: 2013-06-07 14:36 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/a9311ec68721 Avoid graph caching if immature or no profiling information was used for graph building. ! graal/com.oracle.graal.api.meta/src/com/oracle/graal/api/meta/DefaultProfilingInfo.java ! graal/com.oracle.graal.api.meta/src/com/oracle/graal/api/meta/ProfilingInfo.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/HotSpotVMConfig.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotGraphCache.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotMethodData.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotProfilingInfo.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotResolvedJavaMethod.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/spi/GraphCache.java ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/InliningPhase.java ! graal/com.oracle.graal.phases/src/com/oracle/graal/phases/GraalOptions.java ! src/share/vm/graal/graalCompilerToVM.cpp ! src/share/vm/interpreter/invocationCounter.hpp Changeset: dacc97879751 Author: Christian Haeubl Date: 2013-06-07 14:38 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/dacc97879751 Assume that null and bounds checks fail less likely. ! graal/com.oracle.graal.java/src/com/oracle/graal/java/GraphBuilderPhase.java Changeset: 5a4fbe932ab3 Author: Christian Haeubl Date: 2013-06-07 14:48 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/5a4fbe932ab3 Assume that those path which end in a DeoptimizeNode are taken less frequently. ! graal/com.oracle.graal.api.code/src/com/oracle/graal/api/code/DeoptimizationAction.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/extended/SwitchNode.java ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/InliningPhase.java ! graal/com.oracle.graal.phases/src/com/oracle/graal/phases/graph/ComputeProbabilityClosure.java Changeset: 8d62b9774d0c Author: Christian Haeubl Date: 2013-06-07 14:57 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/8d62b9774d0c Checkstyle fix. ! graal/com.oracle.graal.phases/src/com/oracle/graal/phases/graph/ComputeProbabilityClosure.java Changeset: 3d5fdf185a67 Author: Christian Haeubl Date: 2013-06-07 16:02 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/3d5fdf185a67 Bugfix concerning ComputeProbabilityClosure. ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/extended/SwitchNode.java ! graal/com.oracle.graal.phases/src/com/oracle/graal/phases/graph/ComputeProbabilityClosure.java Changeset: 78a1232be418 Author: Christian Haeubl Date: 2013-06-07 16:10 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/78a1232be418 Fixed a warning. ! graal/com.oracle.graal.phases/src/com/oracle/graal/phases/graph/ComputeProbabilityClosure.java Changeset: 0f7ca53be929 Author: Morris Meyer Date: 2013-06-07 15:43 -0400 URL: http://hg.openjdk.java.net/graal/graal/rev/0f7ca53be929 CR-806: Changes to build Graal for SPARC ! graal/com.oracle.graal.hotspot.sparc/src/com/oracle/graal/hotspot/sparc/SPARCHotSpotGraalRuntime.java ! make/solaris/makefiles/buildtree.make ! make/solaris/makefiles/vm.make ! mx/commands.py + src/cpu/sparc/vm/codeInstaller_sparc.hpp ! src/cpu/sparc/vm/graalGlobals_sparc.hpp ! src/cpu/sparc/vm/interpreterGenerator_sparc.hpp ! src/cpu/sparc/vm/nativeInst_sparc.cpp ! src/cpu/sparc/vm/sharedRuntime_sparc.cpp ! src/cpu/sparc/vm/templateInterpreter_sparc.cpp + src/cpu/x86/vm/codeInstaller_x86.hpp ! src/share/vm/classfile/vmSymbols.hpp ! src/share/vm/graal/graalCodeInstaller.cpp ! src/share/vm/graal/graalCodeInstaller.hpp ! src/share/vm/graal/graalCompiler.cpp ! src/share/vm/graal/graalCompilerToVM.cpp ! src/share/vm/graal/graalVMToCompiler.cpp ! src/share/vm/runtime/fieldDescriptor.cpp ! src/share/vm/runtime/fieldDescriptor.hpp Changeset: 2a091d2987bd Author: Doug Simon Date: 2013-06-07 15:59 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/2a091d2987bd added graal.options mechanism for being able to override default option values ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/HotSpotOptions.java ! make/Makefile ! make/build-graal.xml ! mx/commands.py Changeset: 0927013db134 Author: Doug Simon Date: 2013-06-07 15:59 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/0927013db134 fail fast if a non-default value for GraalRuntime was specified and the corresponding factory is not available ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/HotSpotGraalRuntime.java Changeset: 4f5e5bb03184 Author: Doug Simon Date: 2013-06-07 17:03 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/4f5e5bb03184 fixed emitting of platform-specific newline in files generated by OptionProcessor ! graal/com.oracle.graal.options/src/com/oracle/graal/options/OptionProcessor.java Changeset: 63bae87147df Author: Doug Simon Date: 2013-06-07 17:28 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/63bae87147df Merge. - graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/InlineableElement.java Changeset: e2068bbf4c0d Author: Doug Simon Date: 2013-06-08 00:25 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/e2068bbf4c0d Merge. ! mx/commands.py Changeset: 2194b25ff111 Author: Doug Simon Date: 2013-06-08 00:54 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/2194b25ff111 only copy graal.options if it exists ! make/build-graal.xml ! mx/commands.py Changeset: 8448a4e15f95 Author: Lukas Stadler Date: 2013-06-07 13:36 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/8448a4e15f95 remove unused method from Virtualizable.State ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/spi/Virtualizable.java ! graal/com.oracle.graal.virtual/src/com/oracle/graal/virtual/phases/ea/ObjectState.java Changeset: de3653e68738 Author: Lukas Stadler Date: 2013-06-07 13:44 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/de3653e68738 proper assertions in VirtualizerToolImpl.setVirtualEntry ! graal/com.oracle.graal.virtual/src/com/oracle/graal/virtual/phases/ea/VirtualizerToolImpl.java Changeset: 671bcaf13017 Author: Lukas Stadler Date: 2013-06-07 14:27 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/671bcaf13017 remove FrameState logic from LIRGenerator ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/gen/LIRGenerator.java Changeset: eef9281ec13b Author: Lukas Stadler Date: 2013-06-07 16:43 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/eef9281ec13b pull basic algorithm of PartialEscapeAnalysisPhase into new base class EffectsPhase ! graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/BoxingEliminationTest.java ! graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/ea/EscapeAnalysisTest.java ! graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/ea/IterativeInliningTest.java - graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/ea/PEAReadEliminationTest.java ! graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/ea/PartialEscapeAnalysisTest.java ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/GraalCompiler.java ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/phases/HighTier.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/java/LoadFieldNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/java/StoreFieldNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/spi/VirtualizerTool.java ! graal/com.oracle.graal.phases/src/com/oracle/graal/phases/GraalOptions.java ! graal/com.oracle.graal.replacements.test/src/com/oracle/graal/replacements/test/MonitorTest.java - graal/com.oracle.graal.virtual/src/com/oracle/graal/virtual/phases/ea/BlockState.java + graal/com.oracle.graal.virtual/src/com/oracle/graal/virtual/phases/ea/EffectsBlockState.java + graal/com.oracle.graal.virtual/src/com/oracle/graal/virtual/phases/ea/EffectsClosure.java + graal/com.oracle.graal.virtual/src/com/oracle/graal/virtual/phases/ea/EffectsPhase.java ! graal/com.oracle.graal.virtual/src/com/oracle/graal/virtual/phases/ea/IterativeInliningPhase.java ! graal/com.oracle.graal.virtual/src/com/oracle/graal/virtual/phases/ea/ObjectState.java - graal/com.oracle.graal.virtual/src/com/oracle/graal/virtual/phases/ea/PartialEscapeAnalysisPhase.java + graal/com.oracle.graal.virtual/src/com/oracle/graal/virtual/phases/ea/PartialEscapeBlockState.java ! graal/com.oracle.graal.virtual/src/com/oracle/graal/virtual/phases/ea/PartialEscapeClosure.java + graal/com.oracle.graal.virtual/src/com/oracle/graal/virtual/phases/ea/PartialEscapePhase.java ! graal/com.oracle.graal.virtual/src/com/oracle/graal/virtual/phases/ea/VirtualUtil.java ! graal/com.oracle.graal.virtual/src/com/oracle/graal/virtual/phases/ea/VirtualizerToolImpl.java Changeset: abf8c6cc5f50 Author: Lukas Stadler Date: 2013-06-07 16:34 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/abf8c6cc5f50 make MacroNode a memory checkpoint ! graal/com.oracle.graal.replacements/src/com/oracle/graal/replacements/nodes/MacroNode.java Changeset: 3d09efebcc8e Author: Lukas Stadler Date: 2013-06-07 16:36 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/3d09efebcc8e do not assign FrameStates to ForeignCallNodes that have no side effect and cannot deoptimize ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/extended/ForeignCallNode.java Changeset: f8a4c5011a10 Author: Lukas Stadler Date: 2013-06-08 15:43 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/f8a4c5011a10 fix merge problem in EffectsClosure ! graal/com.oracle.graal.virtual/src/com/oracle/graal/virtual/phases/ea/EffectsClosure.java Changeset: b4325bc087c4 Author: Lukas Stadler Date: 2013-06-08 15:44 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/b4325bc087c4 Merge - graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/InlineableElement.java ! graal/com.oracle.graal.phases/src/com/oracle/graal/phases/GraalOptions.java Changeset: 41511d78546a Author: Morris Meyer Date: 2013-06-08 16:54 -0400 URL: http://hg.openjdk.java.net/graal/graal/rev/41511d78546a SPARC UA 2011 assembler changes, bit manipulation synthetics ! graal/com.oracle.graal.asm.sparc/src/com/oracle/graal/asm/sparc/SPARCAssembler.java ! graal/com.oracle.graal.asm.sparc/src/com/oracle/graal/asm/sparc/SPARCMacroAssembler.java ! graal/com.oracle.graal.compiler.sparc/src/com/oracle/graal/compiler/sparc/SPARCLIRGenerator.java ! graal/com.oracle.graal.lir.ptx/src/com/oracle/graal/lir/ptx/PTXArithmetic.java ! graal/com.oracle.graal.lir.sparc/src/com/oracle/graal/lir/sparc/SPARCBitManipulationOp.java From Vasanth.Venkatachalam at amd.com Mon Jun 10 15:29:09 2013 From: Vasanth.Venkatachalam at amd.com (Venkatachalam, Vasanth) Date: Mon, 10 Jun 2013 22:29:09 +0000 Subject: access to cr.openjdk.java.net Message-ID: <5DD1503F815BD14889DC81D28643E3A73D8D6B1B@sausexdag06.amd.com> Hi, I need an account on http://cr.openjdk.java.net so that I can submit AMD's webrev for the Graal HSAIL support changes. Who would be the person to contact? Mark, Eric Caspole suggested I copy you? Vasanth From christian.thalinger at oracle.com Mon Jun 10 16:18:23 2013 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Mon, 10 Jun 2013 16:18:23 -0700 Subject: access to cr.openjdk.java.net In-Reply-To: <5DD1503F815BD14889DC81D28643E3A73D8D6B1B@sausexdag06.amd.com> References: <5DD1503F815BD14889DC81D28643E3A73D8D6B1B@sausexdag06.amd.com> Message-ID: <8F311469-8C28-4594-96B9-2E090B78A1C3@oracle.com> Yes, Mark is the right person. First of all you need an OpenJDK user. -- Chris On Jun 10, 2013, at 3:29 PM, "Venkatachalam, Vasanth" wrote: > Hi, > > I need an account on http://cr.openjdk.java.net so that I can submit AMD's webrev for the Graal HSAIL support changes. > > Who would be the person to contact? > > Mark, > > Eric Caspole suggested I copy you? > > Vasanth From mark.reinhold at oracle.com Mon Jun 10 16:42:42 2013 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Mon, 10 Jun 2013 16:42:42 -0700 Subject: access to cr.openjdk.java.net In-Reply-To: <5DD1503F815BD14889DC81D28643E3A73D8D6B1B@sausexdag06.amd.com> References: <5DD1503F815BD14889DC81D28643E3A73D8D6B1B@sausexdag06.amd.com> Message-ID: <20130610164242.329309@eggemoggin.niobe.net> 2013/6/10 8:29 -0700, vasanth.venkatachalam at amd.com: > I need an account on http://cr.openjdk.java.net so that I can submit > AMD's webrev for the Graal HSAIL support changes. > > Who would be the person to contact? > > Mark, > > Eric Caspole suggested I copy you? No, per our documented process [1] you should ask the Graal Project Lead, Thomas Wuerthinger, to appoint you an Author. He should then ask the Registrar to make it official [2]. - Mark [1] http://openjdk.java.net/projects/#project-author [2] http://openjdk.java.net/projects/#appointing-author From Vasanth.Venkatachalam at amd.com Tue Jun 11 15:16:02 2013 From: Vasanth.Venkatachalam at amd.com (Venkatachalam, Vasanth) Date: Tue, 11 Jun 2013 22:16:02 +0000 Subject: webrev for Graal HSAIL backend Message-ID: <5DD1503F815BD14889DC81D28643E3A73D8D6D8F@sausexdag06.amd.com> Hi, The AMD Sumatra team has submitted a webrev (http://cr.openjdk.java.net/~ecaspole/graal_hsail/) that adds HSAIL code generation support for Graal, allowing Java programs to be compiled and executed on HSAIL-enabled GPU/APU devices. While this work is a prototype, we have included several working unit test cases, including Mandelbrot and NBody. Features Arithmetic operations for integers, longs, doubles, and floats Loads, stores and move operations Min/max/rem/carry operations for integers and longs Conversion operations - (currently support conversions between integers and floats, integers and doubles, integers and longs, floats and doubles). Some math library operations (e.g., square root). Support for JDK8 lambda constructs. Known Issues -The logic to handle register spilling is work-in-progress, so not all test cases that induce spilling are guaranteed to work. -X86 register encodings are being passed to the HSAIL backend. The calling convention returned by getCallingConvention() currently returns an x86 calling convention -Function call support has yet to be implemented. For a detailed list of unsupported features, refer to the routines that are emitting "NYI" in HSAILLIRGenerator.java The test cases (except for BasicHSAILTest) require an HSAIL simulator or hardware to execute, but in lieu of a simulator or hardware they will output the HSAIL code generated, which is useful for debugging. Moreover, BasicHSAILTest provides a template for adding Java code snippets and viewing the HSAIL generated code without executing the code. We encourage the community to support this new backend and extend it with additional features. Vasanth From morris.meyer at oracle.com Tue Jun 11 17:16:47 2013 From: morris.meyer at oracle.com (Morris Meyer) Date: Tue, 11 Jun 2013 20:16:47 -0400 Subject: webrev for Graal HSAIL backend In-Reply-To: <5DD1503F815BD14889DC81D28643E3A73D8D6D8F@sausexdag06.amd.com> References: <5DD1503F815BD14889DC81D28643E3A73D8D6D8F@sausexdag06.amd.com> Message-ID: <51B7BDEF.8010308@oracle.com> Vasanth, After seeing Apple's WWDC and the 4,000 core dual-GPU system they built into the Mac Pro, I'm very happy to see the work your team has put together. Lots of good stuff here and I think we should take most of it. I like that the HSAIL backend is in the com.oracle.graal namespace - not so much as an Oracle engineer - but it will make working and refactoring these GPU and CPU backends much easier. Thanks. compilerBroker.cpp, library_call.cpp, runtime.cpp and arguments.cpp seem like the might be a little specialized for this point in time. Very interesting changes though. I would like to get the heterogeneous method support into HotSpot / Graal and sit down at the language summit and discuss how we take on constructs like the ForEach work. I think com.amd.sumatra.Sumatra is sort of in the right ballpark - it echos the change I made to CompilerToGPU in the earlier PTX work. I would like of like to reserve the sumatra package for lambda work along the lines you are thinking for a collections / lambda oriented java.lang.invoke set of code. We need to get the requirements for this sort of externalized kernel creating defined as soon as we can. Maybe ...bridge.gpu, ...bridge.gpu.hsail, ...bridge.gpu.ptx packages in the graal namespace? I think it might be a good next step to put in the HSAIL back end and tests and the emulator working at the gate so we can build and verify JDK9 / Sumatra / Graal changes in this environment going forward. I will be working as time permits on the heterogeneous methods and PTX invocation so we can get both platforms at the gate integrating changes. That's all for now. I'm looking forward to working my way through all these unit tests. Huge kudos AMD! --morris meyer On 6/11/13 6:16 PM, Venkatachalam, Vasanth wrote: > Hi, > > The AMD Sumatra team has submitted a webrev (http://cr.openjdk.java.net/~ecaspole/graal_hsail/) that adds HSAIL code generation support for Graal, allowing Java programs to be compiled and executed on HSAIL-enabled GPU/APU devices. While this work is a prototype, we have included several working unit test cases, including Mandelbrot and NBody. > > Features > > Arithmetic operations for integers, longs, doubles, and floats > Loads, stores and move operations > Min/max/rem/carry operations for integers and longs > Conversion operations - (currently support conversions between integers and floats, integers and doubles, integers and longs, floats and doubles). > Some math library operations (e.g., square root). > Support for JDK8 lambda constructs. > > Known Issues > > -The logic to handle register spilling is work-in-progress, so not all test cases that induce spilling are guaranteed to work. > -X86 register encodings are being passed to the HSAIL backend. The calling convention returned by getCallingConvention() currently returns an x86 calling convention > -Function call support has yet to be implemented. > > For a detailed list of unsupported features, refer to the routines that are emitting "NYI" in HSAILLIRGenerator.java > > The test cases (except for BasicHSAILTest) require an HSAIL simulator or hardware to execute, but in lieu of a simulator or hardware they will output the HSAIL code generated, which is useful for debugging. Moreover, BasicHSAILTest provides a template for adding Java code snippets and viewing the HSAIL generated code without executing the code. > > We encourage the community to support this new backend and extend it with additional features. > > Vasanth > > > > > > > > > From tom.deneau at amd.com Wed Jun 12 08:59:17 2013 From: tom.deneau at amd.com (Deneau, Tom) Date: Wed, 12 Jun 2013 15:59:17 +0000 Subject: webrev for Graal HSAIL backend In-Reply-To: <51B7BDEF.8010308@oracle.com> References: <5DD1503F815BD14889DC81D28643E3A73D8D6D8F@sausexdag06.amd.com> <51B7BDEF.8010308@oracle.com> Message-ID: Morris -- Regarding your comments on the hotspot changes in this webrev http://cr.openjdk.java.net/~ecaspole/graal_hsail/ I wanted to let you know that these hotspot changes really don't make sense on their own but co-operate with some JDK changes which we will be submitting in a separate webrev to the Sumatra-dev repository early next week (these JDK changes are much smaller than the graal changes). Here is a brief overview of how the pieces fit together... Basically we wanted the GPU offload programming model to be triggered by the programmer using Stream.parallel.forEach(). So the JDK changes are really just interceptions of the stream API for parallel forEach. The intercept code tests whether the stream meets a few criteria to be offloadable, and if so tell graal (thru the Sumatra interface) to compile the lambda method to HSAIL and dispatch it. If already compiled, it will just be dispatched. Currently we have a property, off by default, which tells the JDK intercept code to offload immediately. If the offload-immediate flag is set, no hotspot changes are really needed. The hotspot changes just provide an alternate way of enabling the offloading (without using the offload-immediate flag) by using the compilation of the underlying lambda method as a trigger for offloading. They are very experimental and we would welcome community input on other ways to do this. Hope this helps... -- Tom Deneau -----Original Message----- From: graal-dev-bounces at openjdk.java.net [mailto:graal-dev-bounces at openjdk.java.net] On Behalf Of Morris Meyer Sent: Tuesday, June 11, 2013 7:17 PM To: graal-dev at openjdk.java.net Subject: Re: webrev for Graal HSAIL backend Vasanth, After seeing Apple's WWDC and the 4,000 core dual-GPU system they built into the Mac Pro, I'm very happy to see the work your team has put together. Lots of good stuff here and I think we should take most of it. I like that the HSAIL backend is in the com.oracle.graal namespace - not so much as an Oracle engineer - but it will make working and refactoring these GPU and CPU backends much easier. Thanks. compilerBroker.cpp, library_call.cpp, runtime.cpp and arguments.cpp seem like the might be a little specialized for this point in time. Very interesting changes though. I would like to get the heterogeneous method support into HotSpot / Graal and sit down at the language summit and discuss how we take on constructs like the ForEach work. I think com.amd.sumatra.Sumatra is sort of in the right ballpark - it echos the change I made to CompilerToGPU in the earlier PTX work. I would like of like to reserve the sumatra package for lambda work along the lines you are thinking for a collections / lambda oriented java.lang.invoke set of code. We need to get the requirements for this sort of externalized kernel creating defined as soon as we can. Maybe ...bridge.gpu, ...bridge.gpu.hsail, ...bridge.gpu.ptx packages in the graal namespace? I think it might be a good next step to put in the HSAIL back end and tests and the emulator working at the gate so we can build and verify JDK9 / Sumatra / Graal changes in this environment going forward. I will be working as time permits on the heterogeneous methods and PTX invocation so we can get both platforms at the gate integrating changes. That's all for now. I'm looking forward to working my way through all these unit tests. Huge kudos AMD! --morris meyer On 6/11/13 6:16 PM, Venkatachalam, Vasanth wrote: > Hi, > > The AMD Sumatra team has submitted a webrev (http://cr.openjdk.java.net/~ecaspole/graal_hsail/) that adds HSAIL code generation support for Graal, allowing Java programs to be compiled and executed on HSAIL-enabled GPU/APU devices. While this work is a prototype, we have included several working unit test cases, including Mandelbrot and NBody. > > Features > > Arithmetic operations for integers, longs, doubles, and floats > Loads, stores and move operations > Min/max/rem/carry operations for integers and longs > Conversion operations - (currently support conversions between integers and floats, integers and doubles, integers and longs, floats and doubles). > Some math library operations (e.g., square root). > Support for JDK8 lambda constructs. > > Known Issues > > -The logic to handle register spilling is work-in-progress, so not all test cases that induce spilling are guaranteed to work. > -X86 register encodings are being passed to the HSAIL backend. The calling convention returned by getCallingConvention() currently returns an x86 calling convention > -Function call support has yet to be implemented. > > For a detailed list of unsupported features, refer to the routines that are emitting "NYI" in HSAILLIRGenerator.java > > The test cases (except for BasicHSAILTest) require an HSAIL simulator or hardware to execute, but in lieu of a simulator or hardware they will output the HSAIL code generated, which is useful for debugging. Moreover, BasicHSAILTest provides a template for adding Java code snippets and viewing the HSAIL generated code without executing the code. > > We encourage the community to support this new backend and extend it with additional features. > > Vasanth > > > > > > > > > From Eric.Caspole at amd.com Wed Jun 12 10:53:12 2013 From: Eric.Caspole at amd.com (Caspole, Eric) Date: Wed, 12 Jun 2013 17:53:12 +0000 Subject: graal tip does not build on Windows today Message-ID: Hi Graal folks, I am building on Windows today and getting an error I did not see before, previously it has worked to build on Windows. If it is a matter to add an extra "return 0;" to keep the compiler happy, I can make a webrev for it. Thanks, Eric graalCompilerToGPU.cpp graalCompilerToVM.cpp graalEnv.cpp c:\work\graal-openjdk\graal\src\cpu\x86\vm\codeinstaller_x86.hpp(56): error C2220: warning treated as error - no 'object' file gener ated [c:\work\graal-openjdk\graal\build\vs-amd64\jvm.vcxproj] c:\work\graal-openjdk\graal\src\cpu\x86\vm\codeinstaller_x86.hpp(56): warning C4715: 'CodeInstaller::pd_next_offset' : not all contr ol paths return a value [c:\work\graal-openjdk\graal\build\vs-amd64\jvm.vcxproj] graalGlobals.cpp graalJavaAccess.cpp the code here is doing a fatal where the error is: inline jint CodeInstaller::pd_next_offset(NativeInstruction* inst, jint pc_offset, oop method) { if (inst->is_call() || inst->is_jump()) { assert(NativeCall::instruction_size == (int)NativeJump::instruction_size, "unexpected size"); return (pc_offset + NativeCall::instruction_size); } else if (inst->is_mov_literal64()) { // mov+call instruction pair jint offset = pc_offset + NativeMovConstReg::instruction_size; u_char* call = (u_char*) (_instructions->start() + offset); assert((call[0] == 0x40 || call[0] == 0x41) && call[1] == 0xFF, "expected call with rex/rexb prefix byte"); offset += 3; /* prefix byte + opcode byte + modrm byte */ return (offset); } else if (inst->is_call_reg()) { // the inlined vtable stub contains a "call register" instruction assert(method != NULL, "only valid for virtual calls"); return (pc_offset + ((NativeCallReg *) inst)->next_instruction_offset()); } else { fatal("unsupported type of instruction for call site"); } } From duboscq at ssw.jku.at Wed Jun 12 11:01:01 2013 From: duboscq at ssw.jku.at (Gilles Duboscq) Date: Wed, 12 Jun 2013 20:01:01 +0200 Subject: graal tip does not build on Windows today In-Reply-To: References: Message-ID: I think someone (Andreas?) already fixed that and committed the change, we should probably push it. On Wed, Jun 12, 2013 at 7:53 PM, Eric Caspole wrote: > Hi Graal folks, > I am building on Windows today and getting an error I did not see before, > previously it has worked to build on Windows. > If it is a matter to add an extra "return 0;" to keep the compiler happy, > I can make a webrev for it. > Thanks, > Eric > > > graalCompilerToGPU.cpp > graalCompilerToVM.cpp > graalEnv.cpp > c:\work\graal-openjdk\graal\src\cpu\x86\vm\codeinstaller_x86.hpp(56): > error C2220: warning treated as error - no 'object' file gener > ated [c:\work\graal-openjdk\graal\build\vs-amd64\jvm.vcxproj] > c:\work\graal-openjdk\graal\src\cpu\x86\vm\codeinstaller_x86.hpp(56): > warning C4715: 'CodeInstaller::pd_next_offset' : not all contr > ol paths return a value > [c:\work\graal-openjdk\graal\build\vs-amd64\jvm.vcxproj] > graalGlobals.cpp > graalJavaAccess.cpp > > the code here is doing a fatal where the error is: > > inline jint CodeInstaller::pd_next_offset(NativeInstruction* inst, jint > pc_offset, oop method) { > if (inst->is_call() || inst->is_jump()) { > assert(NativeCall::instruction_size == > (int)NativeJump::instruction_size, "unexpected size"); > return (pc_offset + NativeCall::instruction_size); > } else if (inst->is_mov_literal64()) { > // mov+call instruction pair > jint offset = pc_offset + NativeMovConstReg::instruction_size; > u_char* call = (u_char*) (_instructions->start() + offset); > assert((call[0] == 0x40 || call[0] == 0x41) && call[1] == 0xFF, > "expected call with rex/rexb prefix byte"); > offset += 3; /* prefix byte + opcode byte + modrm byte */ > return (offset); > } else if (inst->is_call_reg()) { > // the inlined vtable stub contains a "call register" instruction > assert(method != NULL, "only valid for virtual calls"); > return (pc_offset + ((NativeCallReg *) > inst)->next_instruction_offset()); > } else { > fatal("unsupported type of instruction for call site"); > } > } > > From doug.simon at oracle.com Wed Jun 12 11:42:06 2013 From: doug.simon at oracle.com (doug.simon at oracle.com) Date: Wed, 12 Jun 2013 18:42:06 +0000 Subject: hg: graal/graal: 67 new changesets Message-ID: <20130612184548.6F2874819B@hg.openjdk.java.net> Changeset: b59331342d01 Author: Thomas Wuerthinger Date: 2013-06-10 01:07 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/b59331342d01 Make arithmetic nodes extensible. ! 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 Changeset: c73690957f9b Author: Thomas Wuerthinger Date: 2013-06-10 01:08 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/c73690957f9b Add custom constructor to VirtualInstanceNode. ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/virtual/VirtualInstanceNode.java Changeset: 5d91b0b67cba Author: Thomas Wuerthinger Date: 2013-06-10 01:16 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/5d91b0b67cba Introduce Frame.isInitialized in the Truffle API. ! graal/com.oracle.truffle.api/src/com/oracle/truffle/api/frame/Frame.java ! graal/com.oracle.truffle.api/src/com/oracle/truffle/api/frame/FrameDescriptor.java ! graal/com.oracle.truffle.api/src/com/oracle/truffle/api/frame/FrameSlotImpl.java ! graal/com.oracle.truffle.api/src/com/oracle/truffle/api/frame/NativeFrame.java ! graal/com.oracle.truffle.api/src/com/oracle/truffle/api/impl/DefaultMaterializedFrame.java ! graal/com.oracle.truffle.api/src/com/oracle/truffle/api/impl/DefaultVirtualFrame.java Changeset: 60648c97cdd0 Author: Andreas Woess Date: 2013-06-10 01:37 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/60648c97cdd0 Windows build fix: compiler warning "not all control paths return a value" in CodeInstaller::pd_next_offset. ! src/cpu/x86/vm/codeInstaller_x86.hpp Changeset: fd0e5587a07d Author: Christian Haeubl Date: 2013-06-07 17:53 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/fd0e5587a07d Avoid storing statistics about OSR compilations. ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/GraalCompiler.java Changeset: de73bbbde021 Author: Christian Haeubl Date: 2013-06-10 08:44 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/de73bbbde021 Removed the probability fix temporarily. ! graal/com.oracle.graal.phases/src/com/oracle/graal/phases/graph/ComputeProbabilityClosure.java Changeset: 8ad4e90fc5d7 Author: Christian Haeubl Date: 2013-06-10 08:44 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/8ad4e90fc5d7 Merge. - graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/ea/PEAReadEliminationTest.java ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/GraalCompiler.java - graal/com.oracle.graal.virtual/src/com/oracle/graal/virtual/phases/ea/BlockState.java - graal/com.oracle.graal.virtual/src/com/oracle/graal/virtual/phases/ea/PartialEscapeAnalysisPhase.java Changeset: 1b33ef6544b4 Author: Christian Haeubl Date: 2013-06-10 09:30 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/1b33ef6544b4 Fixed a warning. ! graal/com.oracle.graal.phases/src/com/oracle/graal/phases/graph/ComputeProbabilityClosure.java Changeset: 8efb5a58a799 Author: Lukas Stadler Date: 2013-06-10 10:49 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/8efb5a58a799 more checks for ArrayCopyNode virtualization ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/ArrayCopyNode.java Changeset: 38b1517cf458 Author: Lukas Stadler Date: 2013-06-10 10:52 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/38b1517cf458 Merge (60648c97cdd0 Windows build fix...) Changeset: b1b69cb27756 Author: Lukas Stadler Date: 2013-06-10 10:52 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/b1b69cb27756 Merge (1b33ef6544b4 Fixed a warning) Changeset: a91b0d42917f Author: Christian Haeubl Date: 2013-06-10 10:34 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/a91b0d42917f Slightly simplified inlining policy. ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/InliningPhase.java ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/InliningUtil.java Changeset: 8d055f03761a Author: Christian Haeubl Date: 2013-06-10 12:21 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/8d055f03761a Temporarily enabled printing of inlining decisions. ! graal/com.oracle.graal.phases/src/com/oracle/graal/phases/GraalOptions.java Changeset: a76b46d8b231 Author: Christian Haeubl Date: 2013-06-10 12:21 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/a76b46d8b231 Disabled printing of inlining decisions. ! graal/com.oracle.graal.phases/src/com/oracle/graal/phases/GraalOptions.java Changeset: e2ffbaa682b8 Author: Christian Haeubl Date: 2013-06-10 12:22 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/e2ffbaa682b8 Merge. Changeset: 6c13b749d3f9 Author: Bernhard Urban Date: 2013-06-10 15:41 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/6c13b749d3f9 Tool: make class non-static ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/CanonicalizerPhase.java Changeset: 4158612eca60 Author: Bernhard Urban Date: 2013-06-10 15:41 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/4158612eca60 GraalOptions: use static import ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/alloc/LinearScan.java ! graal/com.oracle.graal.hotspot.test/src/com/oracle/graal/hotspot/test/AheadOfTimeCompilationTest.java ! graal/com.oracle.graal.hotspot.test/src/com/oracle/graal/hotspot/test/CompileTheWorldTest.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotProfilingInfo.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/InliningUtil.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/TailDuplicationPhase.java Changeset: 6b6d34f83eb1 Author: Bernhard Urban Date: 2013-06-10 15:41 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/6b6d34f83eb1 IterativeInliningPhase: obtain replacements from context ! graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/ea/IterativeInliningTest.java ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/GraalCompiler.java ! graal/com.oracle.graal.virtual/src/com/oracle/graal/virtual/phases/ea/IterativeInliningPhase.java Changeset: 3df534c97af1 Author: Roland Schatz Date: 2013-06-10 16:06 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/3df534c97af1 Create Suites instance in runtime. ! graal/com.oracle.graal.compiler.ptx.test/src/com/oracle/graal/compiler/ptx/test/PTXTestBase.java ! graal/com.oracle.graal.compiler.sparc.test/src/com/oracle/graal/compiler/sparc/test/SPARCTestBase.java ! graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/GraalCompilerTest.java ! graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/InfopointReasonTest.java ! graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/backend/AllocatorTest.java ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/GraalCompiler.java ! graal/com.oracle.graal.hotspot.test/src/com/oracle/graal/hotspot/test/AheadOfTimeCompilationTest.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/CompilationTask.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/HotSpotGraalRuntime.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotRuntime.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/stubs/Stub.java ! graal/com.oracle.graal.phases/src/com/oracle/graal/phases/tiers/Suites.java + graal/com.oracle.graal.phases/src/com/oracle/graal/phases/tiers/SuitesProvider.java Changeset: b8b4d7f3e4aa Author: Roland Schatz Date: 2013-06-10 17:00 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/b8b4d7f3e4aa Use Suites mechanism for HotSpot specific compiler phases. ! graal/com.oracle.graal.compiler.ptx.test/src/com/oracle/graal/compiler/ptx/test/PTXTestBase.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/GraalCompiler.java ! graal/com.oracle.graal.hotspot.test/src/com/oracle/graal/hotspot/test/AheadOfTimeCompilationTest.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/bridge/VMToCompilerImpl.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotRuntime.java ! graal/com.oracle.graal.phases/src/com/oracle/graal/phases/PhasePlan.java Changeset: 5f2ab1ec1a87 Author: Christos Kotselidis Date: 2013-06-10 10:14 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/5f2ab1ec1a87 Remove blank line ! graal/com.oracle.graal.hotspot.test/src/com/oracle/graal/hotspot/test/CompressedOopTest.java Changeset: 390df0b3eefe Author: Christos Kotselidis Date: 2013-06-10 11:06 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/390df0b3eefe Refactor CompressedOopTest ! graal/com.oracle.graal.hotspot.test/src/com/oracle/graal/hotspot/test/CompressedOopTest.java Changeset: 91c16dff3fc1 Author: Christos Kotselidis Date: 2013-06-10 11:47 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/91c16dff3fc1 Refactor CodeInstaller and CompilerToVM ! src/share/vm/graal/graalCodeInstaller.cpp ! src/share/vm/graal/graalCompilerToVM.hpp Changeset: 80cff15f7721 Author: Christos Kotselidis Date: 2013-06-10 12:11 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/80cff15f7721 Remove check for classMirrorOffset in LoadField ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotRuntime.java Changeset: 01dd93600d02 Author: Christos Kotselidis Date: 2013-06-10 12:18 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/01dd93600d02 Add comments in unsafe access of uncompressed pointers ! src/share/vm/prims/unsafe.cpp Changeset: 3743ac6347dd Author: Christos Kotselidis Date: 2013-06-10 12:28 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/3743ac6347dd Small refactoring and comment addition ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotRuntime.java Changeset: f6ceb0a3482e Author: Christos Kotselidis Date: 2013-06-10 12:33 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/f6ceb0a3482e Class renaming ! graal/com.oracle.graal.hotspot.amd64/src/com/oracle/graal/hotspot/amd64/AMD64HotSpotLIRGenerator.java ! graal/com.oracle.graal.lir.amd64/src/com/oracle/graal/lir/amd64/AMD64Move.java Changeset: 940c2186f0fa Author: Christos Kotselidis Date: 2013-06-10 12:34 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/940c2186f0fa Remove dead code ! graal/com.oracle.graal.lir.amd64/src/com/oracle/graal/lir/amd64/AMD64Move.java Changeset: 0a7bae701ad6 Author: Christos Kotselidis Date: 2013-06-10 12:36 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/0a7bae701ad6 Factor out redundant method ! graal/com.oracle.graal.lir.amd64/src/com/oracle/graal/lir/amd64/AMD64Move.java Changeset: 70ffc60dbce7 Author: Christos Kotselidis Date: 2013-06-10 12:40 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/70ffc60dbce7 Refactoring ! graal/com.oracle.graal.hotspot.amd64/src/com/oracle/graal/hotspot/amd64/AMD64HotSpotLIRGenerator.java ! graal/com.oracle.graal.lir.amd64/src/com/oracle/graal/lir/amd64/AMD64Move.java Changeset: 8369c5780c77 Author: Christos Kotselidis Date: 2013-06-10 13:04 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/8369c5780c77 Refactoring ! graal/com.oracle.graal.hotspot.amd64/src/com/oracle/graal/hotspot/amd64/AMD64HotSpotLIRGenerator.java ! graal/com.oracle.graal.lir.amd64/src/com/oracle/graal/lir/amd64/AMD64Move.java Changeset: a5adff75cb93 Author: Christos Kotselidis Date: 2013-06-10 14:05 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/a5adff75cb93 Add comments and minor renaming ! graal/com.oracle.graal.lir.amd64/src/com/oracle/graal/lir/amd64/AMD64Move.java Changeset: 06e176eff527 Author: Christos Kotselidis Date: 2013-06-10 23:59 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/06e176eff527 Remove unused field ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/extended/WriteNode.java Changeset: 13384d19fec0 Author: Christos Kotselidis Date: 2013-06-11 00:00 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/13384d19fec0 Merge - graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/ea/PEAReadEliminationTest.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotRuntime.java - graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/InlineableElement.java - graal/com.oracle.graal.virtual/src/com/oracle/graal/virtual/phases/ea/BlockState.java - graal/com.oracle.graal.virtual/src/com/oracle/graal/virtual/phases/ea/PartialEscapeAnalysisPhase.java ! src/share/vm/graal/graalCodeInstaller.cpp Changeset: f3330a4487eb Author: Doug Simon Date: 2013-06-11 01:17 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/f3330a4487eb added ResolvedJava[Field|Method].isSynthetic() ! graal/com.oracle.graal.api.meta.test/src/com/oracle/graal/api/meta/test/TestResolvedJavaMethod.java ! graal/com.oracle.graal.api.meta/src/com/oracle/graal/api/meta/ResolvedJavaField.java ! graal/com.oracle.graal.api.meta/src/com/oracle/graal/api/meta/ResolvedJavaMethod.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotResolvedJavaField.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotResolvedJavaMethod.java Changeset: e6bd1004082a Author: Doug Simon Date: 2013-06-11 01:18 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/e6bd1004082a added HotSpotResolvedObjectType.getMethods() to get all methods of a class including those (such as ) not normally exposed by Java reflection ! 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/HotSpotResolvedObjectType.java ! src/share/vm/graal/graalCompilerToVM.cpp Changeset: 4f542ceb5fed Author: Doug Simon Date: 2013-06-11 01:31 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/4f542ceb5fed added VerifyHotSpotOptionsPhase to ensure that global state is not initialized from options prior to command line parsing ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/HotSpotOptions.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/bridge/VMToCompilerImpl.java + graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/phases/VerifyHotSpotOptionsPhase.java ! graal/com.oracle.graal.options/src/com/oracle/graal/options/OptionDescriptor.java ! graal/com.oracle.graal.options/src/com/oracle/graal/options/OptionProcessor.java Changeset: b270f0856a39 Author: Doug Simon Date: 2013-06-11 01:32 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/b270f0856a39 fixed issues detected by VerifyHotSpotOptionsPhase ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/InliningPhase.java ! graal/com.oracle.graal.phases/src/com/oracle/graal/phases/tiers/Suites.java Changeset: 0a59959177c9 Author: Doug Simon Date: 2013-06-11 01:56 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/0a59959177c9 allow calls to $jacocoInit() from in a class declaring an option ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/phases/VerifyHotSpotOptionsPhase.java Changeset: b9b8af46c2b7 Author: Michael Van De Vanter Date: 2013-06-10 16:46 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/b9b8af46c2b7 Upgrade the documentation for SourceSection, especially with respect to the specification of text locations. ! graal/com.oracle.truffle.api/src/com/oracle/truffle/api/SourceSection.java Changeset: fb2c8034e9b9 Author: Michael Van De Vanter Date: 2013-06-10 16:48 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/fb2c8034e9b9 Merge with 13384d19fec0af8e42d8d97a0dd231365831802a Changeset: 81f8a7461d63 Author: Gilles Duboscq Date: 2013-06-11 11:42 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/81f8a7461d63 Merge Changeset: b2aea23ee2b1 Author: Christian Haeubl Date: 2013-06-10 15:17 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/b2aea23ee2b1 Only avoid graph caching when the graph was built without profiling information. ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/HotSpotVMConfig.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotProfilingInfo.java ! graal/com.oracle.graal.phases/src/com/oracle/graal/phases/GraalOptions.java ! src/share/vm/graal/graalCompilerToVM.cpp ! src/share/vm/interpreter/invocationCounter.hpp Changeset: 053b837d0d7d Author: Christian Haeubl Date: 2013-06-11 13:10 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/053b837d0d7d Readded the pass that fixes DeoptimizeNode probabilities. ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotProfilingInfo.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/ControlSplitNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/IfNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/InvokeWithExceptionNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/extended/SwitchNode.java ! graal/com.oracle.graal.phases/src/com/oracle/graal/phases/graph/ComputeProbabilityClosure.java Changeset: f90fc8987779 Author: Christian Haeubl Date: 2013-06-11 13:12 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/f90fc8987779 Merge. ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotProfilingInfo.java ! src/share/vm/graal/graalCompilerToVM.cpp Changeset: 3754bb5aab2f Author: Christian Haeubl Date: 2013-06-11 13:14 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/3754bb5aab2f Minor fix after merge. ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotProfilingInfo.java Changeset: d9a331e2fd61 Author: Christos Kotselidis Date: 2013-06-11 17:32 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/d9a331e2fd61 Compressed Oop support for heab base > 32g ! graal/com.oracle.graal.lir.amd64/src/com/oracle/graal/lir/amd64/AMD64Move.java Changeset: 4abd6387a612 Author: Christos Kotselidis Date: 2013-06-11 17:45 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/4abd6387a612 Allow UseCompressedOops argument ! src/share/vm/runtime/arguments.cpp Changeset: e85afceb39e7 Author: Christos Kotselidis Date: 2013-06-11 18:13 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/e85afceb39e7 Merge Changeset: 828f342cb275 Author: Doug Simon Date: 2013-06-11 17:00 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/828f342cb275 improved toString() for JavaTypeProfile and ProfiledType ! graal/com.oracle.graal.api.meta/src/com/oracle/graal/api/meta/JavaTypeProfile.java Changeset: d9c14b1828fc Author: Doug Simon Date: 2013-06-11 17:03 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/d9c14b1828fc unified toString() for HotSpot implementations of JavaMethod ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotMethod.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotMethodUnresolved.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotResolvedJavaMethod.java Changeset: 38d7b55f87b0 Author: Doug Simon Date: 2013-06-11 22:02 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/38d7b55f87b0 added instanceof snippets that for a profile with 100% precise coverage of seen types. This snippet deoptimizes on any path that contradicts the profile. ! graal/com.oracle.graal.api.code/src/com/oracle/graal/api/code/TypeCheckHints.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/CheckCastSnippets.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/InstanceOfSnippets.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/TypeProfileProxyNode.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: 3bc930dd9313 Author: Doug Simon Date: 2013-06-11 22:02 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/3bc930dd9313 Merge. Changeset: e23b0486e750 Author: Bernhard Urban Date: 2013-06-12 10:12 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/e23b0486e750 unittest/aot: create suites on every compilation ! graal/com.oracle.graal.hotspot.test/src/com/oracle/graal/hotspot/test/AheadOfTimeCompilationTest.java Changeset: c4a0e878868f Author: Bernhard Urban Date: 2013-06-12 10:12 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/c4a0e878868f class constants: add hotspot specific phase to load java mirror via klass* (GRAAL-290) ! graal/com.oracle.graal.hotspot.test/src/com/oracle/graal/hotspot/test/AheadOfTimeCompilationTest.java + graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/phases/LoadJavaMirrorWithKlassPhase.java Changeset: 8cffc5183a27 Author: Doug Simon Date: 2013-06-12 13:55 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/8cffc5183a27 incorporated auto-format fix ! graal/com.oracle.graal.compiler.sparc.test/src/com/oracle/graal/compiler/sparc/test/BasicSPARCTest.java Changeset: 0478f70900de Author: Doug Simon Date: 2013-06-12 13:58 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/0478f70900de extra javadoc for intricacies involved in lowering ExceptionObjectNode ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/java/ExceptionObjectNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/java/LoadExceptionObjectNode.java Changeset: 10b8973ac372 Author: Doug Simon Date: 2013-06-12 14:00 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/10b8973ac372 fixed copy-and-paste errors ! graal/com.oracle.graal.replacements/src/com/oracle/graal/replacements/SnippetTemplate.java Changeset: 03b822ee729e Author: Bernhard Urban Date: 2013-06-12 16:04 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/03b822ee729e LoadJavaMirrorWithKlassPhase: replace constants with floating nodes (GRAAL-290) ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/phases/LoadJavaMirrorWithKlassPhase.java Changeset: b5c87b5c6e9c Author: Bernhard Urban Date: 2013-06-12 16:04 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/b5c87b5c6e9c add option to enable ahead of time compilation for hotspot (GRAAL-290) ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/GraalCompiler.java ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/phases/HighTier.java ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/phases/MidTier.java ! graal/com.oracle.graal.hotspot.test/src/com/oracle/graal/hotspot/test/AheadOfTimeCompilationTest.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotRuntime.java ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/IncrementalCanonicalizerPhase.java ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/InliningPhase.java ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/IterativeConditionalEliminationPhase.java ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/TailDuplicationPhase.java ! graal/com.oracle.graal.phases/src/com/oracle/graal/phases/GraalOptions.java Changeset: 893bc1dbb58c Author: Bernhard Urban Date: 2013-06-12 16:04 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/893bc1dbb58c gate: add bootstrap with aot configuration to gate check ! mx/commands.py Changeset: e65727799325 Author: Bernhard Urban Date: 2013-06-12 13:18 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/e65727799325 LoadJavaMirrorWithKlassPhase: replace if with an assertion ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/phases/LoadJavaMirrorWithKlassPhase.java Changeset: b2f1168ee37f Author: Bernhard Urban Date: 2013-06-12 16:04 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/b2f1168ee37f unittest/aot: add test for primitive types ! graal/com.oracle.graal.hotspot.test/src/com/oracle/graal/hotspot/test/AheadOfTimeCompilationTest.java Changeset: 767ef799b323 Author: Bernhard Urban Date: 2013-06-12 16:04 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/767ef799b323 unittest/aot: use assert methods instead of keyword ! graal/com.oracle.graal.hotspot.test/src/com/oracle/graal/hotspot/test/AheadOfTimeCompilationTest.java Changeset: 16dfdc920e77 Author: Bernhard Urban Date: 2013-06-12 16:04 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/16dfdc920e77 unittest/aot: add testcase for string objects ! graal/com.oracle.graal.hotspot.test/src/com/oracle/graal/hotspot/test/AheadOfTimeCompilationTest.java Changeset: deb5bd841422 Author: Bernhard Urban Date: 2013-06-12 17:24 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/deb5bd841422 aot: add verification phase ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotRuntime.java + graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/phases/AheadOfTimeVerifcationPhase.java Changeset: 7709bb831916 Author: Doug Simon Date: 2013-06-12 18:15 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/7709bb831916 adjusted threshold at which the deoptimizing instanceof snippet is used and change the deoptimization action to None to reflect that fact it is a rare event but does not warrant reprofiling ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/InstanceOfSnippets.java ! graal/com.oracle.graal.phases/src/com/oracle/graal/phases/GraalOptions.java From christian.thalinger at oracle.com Wed Jun 12 12:14:09 2013 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Wed, 12 Jun 2013 12:14:09 -0700 Subject: webrev for Graal HSAIL backend In-Reply-To: <5DD1503F815BD14889DC81D28643E3A73D8D6D8F@sausexdag06.amd.com> References: <5DD1503F815BD14889DC81D28643E3A73D8D6D8F@sausexdag06.amd.com> Message-ID: Before I'm going into review details, how are we going to handle this review? Like any other OpenJDK review which means we do review-change iterations until we all agree it's good? -- Chris On Jun 11, 2013, at 3:16 PM, "Venkatachalam, Vasanth" wrote: > > Hi, > > The AMD Sumatra team has submitted a webrev (http://cr.openjdk.java.net/~ecaspole/graal_hsail/) that adds HSAIL code generation support for Graal, allowing Java programs to be compiled and executed on HSAIL-enabled GPU/APU devices. While this work is a prototype, we have included several working unit test cases, including Mandelbrot and NBody. > > Features > > Arithmetic operations for integers, longs, doubles, and floats > Loads, stores and move operations > Min/max/rem/carry operations for integers and longs > Conversion operations - (currently support conversions between integers and floats, integers and doubles, integers and longs, floats and doubles). > Some math library operations (e.g., square root). > Support for JDK8 lambda constructs. > > Known Issues > > -The logic to handle register spilling is work-in-progress, so not all test cases that induce spilling are guaranteed to work. > -X86 register encodings are being passed to the HSAIL backend. The calling convention returned by getCallingConvention() currently returns an x86 calling convention > -Function call support has yet to be implemented. > > For a detailed list of unsupported features, refer to the routines that are emitting "NYI" in HSAILLIRGenerator.java > > The test cases (except for BasicHSAILTest) require an HSAIL simulator or hardware to execute, but in lieu of a simulator or hardware they will output the HSAIL code generated, which is useful for debugging. Moreover, BasicHSAILTest provides a template for adding Java code snippets and viewing the HSAIL generated code without executing the code. > > We encourage the community to support this new backend and extend it with additional features. > > Vasanth > > > > > > > > > From doug.simon at oracle.com Wed Jun 12 13:26:19 2013 From: doug.simon at oracle.com (Doug Simon) Date: Wed, 12 Jun 2013 22:26:19 +0200 Subject: webrev for Graal HSAIL backend In-Reply-To: References: <5DD1503F815BD14889DC81D28643E3A73D8D6D8F@sausexdag06.amd.com> Message-ID: <728B911F-FFB4-4B71-9C6B-6BA70238EFAF@oracle.com> For something this size, I'm really hoping we can find a Crucible instance everyone has access to. Doing a review this size is going to be painful via webrev I believe. On Jun 12, 2013, at 9:14 PM, Christian Thalinger wrote: > Before I'm going into review details, how are we going to handle this review? Like any other OpenJDK review which means we do review-change iterations until we all agree it's good? > > -- Chris > > On Jun 11, 2013, at 3:16 PM, "Venkatachalam, Vasanth" wrote: > >> >> Hi, >> >> The AMD Sumatra team has submitted a webrev (http://cr.openjdk.java.net/~ecaspole/graal_hsail/) that adds HSAIL code generation support for Graal, allowing Java programs to be compiled and executed on HSAIL-enabled GPU/APU devices. While this work is a prototype, we have included several working unit test cases, including Mandelbrot and NBody. >> >> Features >> >> Arithmetic operations for integers, longs, doubles, and floats >> Loads, stores and move operations >> Min/max/rem/carry operations for integers and longs >> Conversion operations - (currently support conversions between integers and floats, integers and doubles, integers and longs, floats and doubles). >> Some math library operations (e.g., square root). >> Support for JDK8 lambda constructs. >> >> Known Issues >> >> -The logic to handle register spilling is work-in-progress, so not all test cases that induce spilling are guaranteed to work. >> -X86 register encodings are being passed to the HSAIL backend. The calling convention returned by getCallingConvention() currently returns an x86 calling convention >> -Function call support has yet to be implemented. >> >> For a detailed list of unsupported features, refer to the routines that are emitting "NYI" in HSAILLIRGenerator.java >> >> The test cases (except for BasicHSAILTest) require an HSAIL simulator or hardware to execute, but in lieu of a simulator or hardware they will output the HSAIL code generated, which is useful for debugging. Moreover, BasicHSAILTest provides a template for adding Java code snippets and viewing the HSAIL generated code without executing the code. >> >> We encourage the community to support this new backend and extend it with additional features. >> >> Vasanth >> >> >> >> >> >> >> >> >> > From s1255495 at sms.ed.ac.uk Wed Jun 12 22:42:56 2013 From: s1255495 at sms.ed.ac.uk (SINGH Ranjeet) Date: Thu, 13 Jun 2013 05:42:56 +0000 Subject: modifying a method Message-ID: <3454624D1FF2C24B832E62EB80104C5E20D49A21@AMXPRD0510MB366.eurprd05.prod.outlook.com> Hi, I'm using Graal for my university project and one part of my project requires modifying methods which have a specific annotation at runtime. I was thinking of putting my code to do this in the CompilationTask.runCompilation() method before GraalCompiler.compileGraph get's called (this might not be the best place to put it), my code would check if the method coming in has the annotation I'm looking for if it has then modify the body of the method. Is what I'm trying to do possible in Graal? and if yes how? Thanks. -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: not available Url: http://mail.openjdk.java.net/pipermail/graal-dev/attachments/20130613/e3367c17/attachment.ksh From doug.simon at oracle.com Thu Jun 13 01:35:11 2013 From: doug.simon at oracle.com (Doug Simon) Date: Thu, 13 Jun 2013 10:35:11 +0200 Subject: modifying a method In-Reply-To: <3454624D1FF2C24B832E62EB80104C5E20D49A21@AMXPRD0510MB366.eurprd05.prod.outlook.com> References: <3454624D1FF2C24B832E62EB80104C5E20D49A21@AMXPRD0510MB366.eurprd05.prod.outlook.com> Message-ID: <04B9E958-69D7-457A-89EA-3F45EBB47AE0@oracle.com> What kind of modification are you planning on doing? Almost certainly it's going to be best to do it as a graph transformation right after the initial graph for your method has been constructed (i.e., after the GraphBuilderPhase has run). One way to do this would be to modify VMToCompilerImple.createPhasePlan() to inject a new phase for doing your transformation: phasePlan.addPhase(PhasePosition.AFTER_PARSING, new MyPhase()); -Doug On Jun 13, 2013, at 7:42 AM, SINGH Ranjeet wrote: > Hi, > > I'm using Graal for my university project and one part of my project requires modifying methods which have a specific annotation at runtime. I was thinking of putting my code to do this in the CompilationTask.runCompilation() method before GraalCompiler.compileGraph get's called (this might not be the best place to put it), my code would check if the method coming in has the annotation I'm looking for if it has then modify the body of the method. Is what I'm trying to do possible in Graal? and if yes how? > > Thanks. > The University of Edinburgh is a charitable body, registered in > Scotland, with registration number SC005336. From doug.simon at oracle.com Thu Jun 13 07:04:08 2013 From: doug.simon at oracle.com (Doug Simon) Date: Thu, 13 Jun 2013 16:04:08 +0200 Subject: webrev for Graal HSAIL backend In-Reply-To: References: <5DD1503F815BD14889DC81D28643E3A73D8D6D8F@sausexdag06.amd.com> <51B7BDEF.8010308@oracle.com> Message-ID: <06675A95-9FCC-4C0A-9025-A1105C1F9F4A@oracle.com> Tom, It would really help to have this patch broken up into components that can be separately considered for integration. In particular (as Morris stated), having the HSAIL backend (and tests) in Graal would be great so a separate patch for this code would be a good first step. One immediate observation is that a lot of the code does not yet import into Eclipse very well. This is the primary tool we use for development and code comprehension so getting the code into Eclipse compliant form would be very helpful in terms of being able to efficiently assess a contribution and offer further feedback. This means: o Only use Java 7 language features (Eclipse does not yet support Java 8 language features and it's not clear when it will). o Remove all Checkstyle warnings (use the eclipse-cs plugin or 'mx checkstyle'). o Remove all Java warnings (which show up in the Eclipse Problems view). o Format Java code with the Eclipse formatter (the Eclipse projects generated by 'mx eclipseinit' will ensure the Graal code formatting rules are used). It would be useful to have a high level description of the code, broken down by package or collection of packages. This can either be plain text or (preferably) package-info.java files. I notice there are files without licenses and some with University of Illinois licenses (the Okra framework). I'm no expert on licensing, but this may causes integration issues. The HotSpot changes are probably best to keep in the Sumatra repository for now given their experimental nature. I look forward to further progress in terms of getting Sumatra code into Graal - thanks for a good start! -Doug On Jun 12, 2013, at 5:59 PM, "Deneau, Tom" wrote: > Morris -- > > Regarding your comments on the hotspot changes in this webrev > http://cr.openjdk.java.net/~ecaspole/graal_hsail/ > I wanted to let you know that these hotspot changes really don't make > sense on their own but co-operate with some JDK changes which we will > be submitting in a separate webrev to the Sumatra-dev repository early > next week (these JDK changes are much smaller than the graal changes). > > Here is a brief overview of how the pieces fit together... > > Basically we wanted the GPU offload programming model to be triggered > by the programmer using Stream.parallel.forEach(). So the JDK changes > are really just interceptions of the stream API for parallel forEach. > The intercept code tests whether the stream meets a few criteria to be > offloadable, and if so tell graal (thru the Sumatra interface) to > compile the lambda method to HSAIL and dispatch it. If already > compiled, it will just be dispatched. Currently we have a property, > off by default, which tells the JDK intercept code to offload > immediately. If the offload-immediate flag is set, no hotspot changes > are really needed. > > The hotspot changes just provide an alternate way of enabling the > offloading (without using the offload-immediate flag) by using the > compilation of the underlying lambda method as a trigger for > offloading. They are very experimental and we would welcome community > input on other ways to do this. > > Hope this helps... > > -- Tom Deneau > > > > -----Original Message----- > From: graal-dev-bounces at openjdk.java.net [mailto:graal-dev-bounces at openjdk.java.net] On Behalf Of Morris Meyer > Sent: Tuesday, June 11, 2013 7:17 PM > To: graal-dev at openjdk.java.net > Subject: Re: webrev for Graal HSAIL backend > > Vasanth, > > After seeing Apple's WWDC and the 4,000 core dual-GPU system they built > into the Mac Pro, I'm very happy to see the work your team has put > together. Lots of good stuff here and I think we should take most of it. > > I like that the HSAIL backend is in the com.oracle.graal namespace - not > so much as an Oracle engineer - but it will make working and refactoring > these GPU and CPU backends much easier. Thanks. > > compilerBroker.cpp, library_call.cpp, runtime.cpp and arguments.cpp seem > like the might be a little specialized for this point in time. Very > interesting changes though. I would like to get the heterogeneous > method support into HotSpot / Graal and sit down at the language summit > and discuss how we take on constructs like the ForEach work. > > I think com.amd.sumatra.Sumatra is sort of in the right ballpark - it > echos the change I made to CompilerToGPU in the earlier PTX work. I > would like of like to reserve the sumatra package for lambda work along > the lines you are thinking for a collections / lambda oriented > java.lang.invoke set of code. We need to get the requirements for this > sort of externalized kernel creating defined as soon as we can. Maybe > ...bridge.gpu, ...bridge.gpu.hsail, ...bridge.gpu.ptx packages in the > graal namespace? > > I think it might be a good next step to put in the HSAIL back end and > tests and the emulator working at the gate so we can build and verify > JDK9 / Sumatra / Graal changes in this environment going forward. > > I will be working as time permits on the heterogeneous methods and PTX > invocation so we can get both platforms at the gate integrating changes. > > That's all for now. I'm looking forward to working my way through all > these unit tests. Huge kudos AMD! > > --morris meyer > > On 6/11/13 6:16 PM, Venkatachalam, Vasanth wrote: >> Hi, >> >> The AMD Sumatra team has submitted a webrev (http://cr.openjdk.java.net/~ecaspole/graal_hsail/) that adds HSAIL code generation support for Graal, allowing Java programs to be compiled and executed on HSAIL-enabled GPU/APU devices. While this work is a prototype, we have included several working unit test cases, including Mandelbrot and NBody. >> >> Features >> >> Arithmetic operations for integers, longs, doubles, and floats >> Loads, stores and move operations >> Min/max/rem/carry operations for integers and longs >> Conversion operations - (currently support conversions between integers and floats, integers and doubles, integers and longs, floats and doubles). >> Some math library operations (e.g., square root). >> Support for JDK8 lambda constructs. >> >> Known Issues >> >> -The logic to handle register spilling is work-in-progress, so not all test cases that induce spilling are guaranteed to work. >> -X86 register encodings are being passed to the HSAIL backend. The calling convention returned by getCallingConvention() currently returns an x86 calling convention >> -Function call support has yet to be implemented. >> >> For a detailed list of unsupported features, refer to the routines that are emitting "NYI" in HSAILLIRGenerator.java >> >> The test cases (except for BasicHSAILTest) require an HSAIL simulator or hardware to execute, but in lieu of a simulator or hardware they will output the HSAIL code generated, which is useful for debugging. Moreover, BasicHSAILTest provides a template for adding Java code snippets and viewing the HSAIL generated code without executing the code. >> >> We encourage the community to support this new backend and extend it with additional features. >> >> Vasanth >> >> >> >> >> >> >> >> >> > > > From Vasanth.Venkatachalam at amd.com Thu Jun 13 07:53:32 2013 From: Vasanth.Venkatachalam at amd.com (Venkatachalam, Vasanth) Date: Thu, 13 Jun 2013 14:53:32 +0000 Subject: graal wiki site Message-ID: <5DD1503F815BD14889DC81D28643E3A73D8D8233@sausexdag06.amd.com> Hi, Can someone explain how we can get authorship rights to the Graal wiki site? We were going to post some additional info about the HSAIL changes we have submitted. Vasanth From doug.simon at oracle.com Thu Jun 13 08:34:44 2013 From: doug.simon at oracle.com (Doug Simon) Date: Thu, 13 Jun 2013 17:34:44 +0200 Subject: graal wiki site In-Reply-To: <5DD1503F815BD14889DC81D28643E3A73D8D8233@sausexdag06.amd.com> References: <5DD1503F815BD14889DC81D28643E3A73D8D8233@sausexdag06.amd.com> Message-ID: <2F26F6E4-6D33-42D4-87CF-7F25352538CD@oracle.com> Hi Vasanth, According to the FAQ[1], only "project Authors, Committers, and Reviewers have write access to the Project's web content". I'm assuming a project's web content in this context includes the wiki. However, I see there is a Sumatra space[2] on this wiki. Maybe you could post the additional info there (I assume you have write access to that space) and I'll add a link to it from the Graal space. -Doug [1] https://wiki.openjdk.java.net/display/general/FAQ [2] https://wiki.openjdk.java.net/display/Sumatra/Main On Jun 13, 2013, at 4:53 PM, "Venkatachalam, Vasanth" wrote: > Hi, > > Can someone explain how we can get authorship rights to the Graal wiki site? We were going to post some additional info about the HSAIL changes we have submitted. > > Vasanth From Vasanth.Venkatachalam at amd.com Thu Jun 13 14:31:12 2013 From: Vasanth.Venkatachalam at amd.com (Venkatachalam, Vasanth) Date: Thu, 13 Jun 2013 21:31:12 +0000 Subject: disabling function inlining in Graal Message-ID: <5DD1503F815BD14889DC81D28643E3A73D8DA408@sausexdag06.amd.com> Is there a flag to disable method inlining in Graal? I noticed in GraalOptions. and there are three options for enabling inlining of monomorphic/polymorphic/megamorphic calls. Would setting these options values to false do the trick? I'm trying to implement function call support for my HSAIL backend and would like to see what nodes are emitted for a simple test case. Vasanth From christian.thalinger at oracle.com Thu Jun 13 16:33:45 2013 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Thu, 13 Jun 2013 16:33:45 -0700 Subject: disabling function inlining in Graal In-Reply-To: <5DD1503F815BD14889DC81D28643E3A73D8DA408@sausexdag06.amd.com> References: <5DD1503F815BD14889DC81D28643E3A73D8DA408@sausexdag06.amd.com> Message-ID: -G:-Inline On Jun 13, 2013, at 2:31 PM, "Venkatachalam, Vasanth" wrote: > Is there a flag to disable method inlining in Graal? > > I noticed in GraalOptions. and there are three options for enabling inlining of monomorphic/polymorphic/megamorphic calls. > Would setting these options values to false do the trick? > > I'm trying to implement function call support for my HSAIL backend and would like to see what nodes are emitted for a simple test case. > > Vasanth > > > From Vasanth.Venkatachalam at amd.com Fri Jun 14 13:34:14 2013 From: Vasanth.Venkatachalam at amd.com (Venkatachalam, Vasanth) Date: Fri, 14 Jun 2013 20:34:14 +0000 Subject: webrev for Graal HSAIL backend Message-ID: <5DD1503F815BD14889DC81D28643E3A73D8DB665@sausexdag06.amd.com> Hi Doug, Thanks for the feedback. We're addressing your comments and had a few questions. 1) I'm trying to understand the issue with the formatting. To apply the Eclipse formatter, I first ran mx ideinit, then started eclipse and under projects->properties->Java Code Style->Formatter, I made sure the profile (Unmanaged profile 'Graal') was selected. Is this the correct way to apply the formatter? Can you give an example of some code that wasn't formatted according to these rules? 2). The only projects that use JDK8 features are com.amd.sumatra, and com.oracle.graal.compiler.hsail.test.lambda, In mx/projects we have specified that these projects have Java compliance of 1.8, so they shouldn't be compiled if the JDK used is 1.7. It seems like there should be a way for Eclipse to pick up on these changes after running mx ideinit. Are you saying this isn't the case? Vasanth -----Original Message----- From: graal-dev-bounces at openjdk.java.net [mailto:graal-dev-bounces at openjdk.java.net] On Behalf Of Doug Simon Sent: Thursday, June 13, 2013 9:04 AM To: Deneau, Tom Cc: sumatra-dev at openjdk.java.net; graal-dev at openjdk.java.net Subject: Re: webrev for Graal HSAIL backend Tom, It would really help to have this patch broken up into components that can be separately considered for integration. In particular (as Morris stated), having the HSAIL backend (and tests) in Graal would be great so a separate patch for this code would be a good first step. One immediate observation is that a lot of the code does not yet import into Eclipse very well. This is the primary tool we use for development and code comprehension so getting the code into Eclipse compliant form would be very helpful in terms of being able to efficiently assess a contribution and offer further feedback. This means: o Only use Java 7 language features (Eclipse does not yet support Java 8 language features and it's not clear when it will). o Remove all Checkstyle warnings (use the eclipse-cs plugin or 'mx checkstyle'). o Remove all Java warnings (which show up in the Eclipse Problems view). o Format Java code with the Eclipse formatter (the Eclipse projects generated by 'mx eclipseinit' will ensure the Graal code formatting rules are used). It would be useful to have a high level description of the code, broken down by package or collection of packages. This can either be plain text or (preferably) package-info.java files. I notice there are files without licenses and some with University of Illinois licenses (the Okra framework). I'm no expert on licensing, but this may causes integration issues. The HotSpot changes are probably best to keep in the Sumatra repository for now given their experimental nature. I look forward to further progress in terms of getting Sumatra code into Graal - thanks for a good start! -Doug On Jun 12, 2013, at 5:59 PM, "Deneau, Tom" wrote: > Morris -- > > Regarding your comments on the hotspot changes in this webrev > http://cr.openjdk.java.net/~ecaspole/graal_hsail/ > I wanted to let you know that these hotspot changes really don't make > sense on their own but co-operate with some JDK changes which we will > be submitting in a separate webrev to the Sumatra-dev repository early > next week (these JDK changes are much smaller than the graal changes). > > Here is a brief overview of how the pieces fit together... > > Basically we wanted the GPU offload programming model to be triggered > by the programmer using Stream.parallel.forEach(). So the JDK changes > are really just interceptions of the stream API for parallel forEach. > The intercept code tests whether the stream meets a few criteria to be > offloadable, and if so tell graal (thru the Sumatra interface) to > compile the lambda method to HSAIL and dispatch it. If already > compiled, it will just be dispatched. Currently we have a property, > off by default, which tells the JDK intercept code to offload > immediately. If the offload-immediate flag is set, no hotspot changes > are really needed. > > The hotspot changes just provide an alternate way of enabling the > offloading (without using the offload-immediate flag) by using the > compilation of the underlying lambda method as a trigger for > offloading. They are very experimental and we would welcome community > input on other ways to do this. > > Hope this helps... > > -- Tom Deneau > > > > -----Original Message----- > From: graal-dev-bounces at openjdk.java.net > [mailto:graal-dev-bounces at openjdk.java.net] On Behalf Of Morris Meyer > Sent: Tuesday, June 11, 2013 7:17 PM > To: graal-dev at openjdk.java.net > Subject: Re: webrev for Graal HSAIL backend > > Vasanth, > > After seeing Apple's WWDC and the 4,000 core dual-GPU system they > built into the Mac Pro, I'm very happy to see the work your team has > put together. Lots of good stuff here and I think we should take most of it. > > I like that the HSAIL backend is in the com.oracle.graal namespace - > not so much as an Oracle engineer - but it will make working and > refactoring these GPU and CPU backends much easier. Thanks. > > compilerBroker.cpp, library_call.cpp, runtime.cpp and arguments.cpp seem > like the might be a little specialized for this point in time. Very > interesting changes though. I would like to get the heterogeneous > method support into HotSpot / Graal and sit down at the language > summit and discuss how we take on constructs like the ForEach work. > > I think com.amd.sumatra.Sumatra is sort of in the right ballpark - it > echos the change I made to CompilerToGPU in the earlier PTX work. I > would like of like to reserve the sumatra package for lambda work > along the lines you are thinking for a collections / lambda oriented > java.lang.invoke set of code. We need to get the requirements for this > sort of externalized kernel creating defined as soon as we can. Maybe > ...bridge.gpu, ...bridge.gpu.hsail, ...bridge.gpu.ptx packages in the > graal namespace? > > I think it might be a good next step to put in the HSAIL back end and > tests and the emulator working at the gate so we can build and verify > JDK9 / Sumatra / Graal changes in this environment going forward. > > I will be working as time permits on the heterogeneous methods and PTX > invocation so we can get both platforms at the gate integrating changes. > > That's all for now. I'm looking forward to working my way through all > these unit tests. Huge kudos AMD! > > --morris meyer > > On 6/11/13 6:16 PM, Venkatachalam, Vasanth wrote: >> Hi, >> >> The AMD Sumatra team has submitted a webrev (http://cr.openjdk.java.net/~ecaspole/graal_hsail/) that adds HSAIL code generation support for Graal, allowing Java programs to be compiled and executed on HSAIL-enabled GPU/APU devices. While this work is a prototype, we have included several working unit test cases, including Mandelbrot and NBody. >> >> Features >> >> Arithmetic operations for integers, longs, doubles, and floats Loads, >> stores and move operations Min/max/rem/carry operations for integers >> and longs Conversion operations - (currently support conversions >> between integers and floats, integers and doubles, integers and longs, floats and doubles). >> Some math library operations (e.g., square root). >> Support for JDK8 lambda constructs. >> >> Known Issues >> >> -The logic to handle register spilling is work-in-progress, so not all test cases that induce spilling are guaranteed to work. >> -X86 register encodings are being passed to the HSAIL backend. The >> calling convention returned by getCallingConvention() currently returns an x86 calling convention -Function call support has yet to be implemented. >> >> For a detailed list of unsupported features, refer to the routines >> that are emitting "NYI" in HSAILLIRGenerator.java >> >> The test cases (except for BasicHSAILTest) require an HSAIL simulator or hardware to execute, but in lieu of a simulator or hardware they will output the HSAIL code generated, which is useful for debugging. Moreover, BasicHSAILTest provides a template for adding Java code snippets and viewing the HSAIL generated code without executing the code. >> >> We encourage the community to support this new backend and extend it with additional features. >> >> Vasanth >> >> >> >> >> >> >> >> >> > > > From doug.simon at oracle.com Sat Jun 15 13:20:15 2013 From: doug.simon at oracle.com (Doug Simon) Date: Sat, 15 Jun 2013 22:20:15 +0200 Subject: webrev for Graal HSAIL backend In-Reply-To: <5DD1503F815BD14889DC81D28643E3A73D8DB665@sausexdag06.amd.com> References: <5DD1503F815BD14889DC81D28643E3A73D8DB665@sausexdag06.amd.com> Message-ID: Hi Vasanth, On Jun 14, 2013, at 10:34 PM, "Venkatachalam, Vasanth" wrote: > Hi Doug, > > Thanks for the feedback. We're addressing your comments and had a few questions. > > 1) I'm trying to understand the issue with the formatting. To apply the Eclipse formatter, I first ran mx ideinit, then started eclipse and under projects->properties->Java Code Style->Formatter, I made sure the profile (Unmanaged profile 'Graal') was selected. Is this the correct way to apply the formatter? Yes. The Eclipse project configurations created by eclipseinit should also apply the formatter to any Java file when it is saved. > Can you give an example of some code that wasn't formatted according to these rules? Now that I've looked at the patch in more detail, I can't see any problem in terms of formatting. > 2). The only projects that use JDK8 features are com.amd.sumatra, and com.oracle.graal.compiler.hsail.test.lambda, In mx/projects we have specified that these projects have Java compliance of 1.8, so they shouldn't be compiled if the JDK used is 1.7. It seems like there should be a way for Eclipse to pick up on these changes after running mx ideinit. Are you saying this isn't the case? One problem is that Eclipse doesn't (yet) support JDK8 *language* features such as lambdas. Projects that only use JDK8 library features should be fine. The ideinit command does not consider compliance level when generating Eclipse project configurations - it probably should. And it should probably ignore any projects whose compliance level is >= 8 altogether. Not only does Eclipse not yet support JDK8 anguage features, it cannot yet generate JDK8 class files (the maximum "Compiler compliance level" one can currently set in Eclipse is 1.7). I've just modified the checkstyle command to pay attention to compliance levels. With this change, you should now be able to test your changes for Graal compliance on the command line with these commands: mx clean mx build --jdt /path/to/ecj.jar --jdt-warning-as-error mx checkstyle Once all 3 pass without any warnings or errors, the code should be easier to review and integrate. Note that these commands are part of our gate so we need to get them passing anyway. If you are game, you could try and replicate our complete gate testing with: mx --jacoco on gate BTW, if you download an ecj.jar[1] to /mx/ecj.jar, it will be automatically detected and used by the 'mx build' command, removing the need for the --jdt argument. Let me know if you run into any problems or have any further questions. -Doug [1] http://www.eclipse.org/downloads/download.php?file=/eclipse/downloads/drops4/R-4.2.2-201302041200/ecj-4.2.2.jar > -----Original Message----- > From: graal-dev-bounces at openjdk.java.net [mailto:graal-dev-bounces at openjdk.java.net] On Behalf Of Doug Simon > Sent: Thursday, June 13, 2013 9:04 AM > To: Deneau, Tom > Cc: sumatra-dev at openjdk.java.net; graal-dev at openjdk.java.net > Subject: Re: webrev for Graal HSAIL backend > > Tom, > > It would really help to have this patch broken up into components that can be separately considered for integration. In particular (as Morris stated), having the HSAIL backend (and tests) in Graal would be great so a separate patch for this code would be a good first step. > > One immediate observation is that a lot of the code does not yet import into Eclipse very well. This is the primary tool we use for development and code comprehension so getting the code into Eclipse compliant form would be very helpful in terms of being able to efficiently assess a contribution and offer further feedback. This means: > > o Only use Java 7 language features (Eclipse does not yet support Java 8 language features and it's not clear when it will). > o Remove all Checkstyle warnings (use the eclipse-cs plugin or 'mx checkstyle'). > o Remove all Java warnings (which show up in the Eclipse Problems view). > o Format Java code with the Eclipse formatter (the Eclipse projects generated by 'mx eclipseinit' will ensure the Graal code formatting rules are used). > > It would be useful to have a high level description of the code, broken down by package or collection of packages. This can either be plain text or (preferably) package-info.java files. > > I notice there are files without licenses and some with University of Illinois licenses (the Okra framework). I'm no expert on licensing, but this may causes integration issues. > > The HotSpot changes are probably best to keep in the Sumatra repository for now given their experimental nature. > > I look forward to further progress in terms of getting Sumatra code into Graal - thanks for a good start! > > -Doug > > On Jun 12, 2013, at 5:59 PM, "Deneau, Tom" wrote: > >> Morris -- >> >> Regarding your comments on the hotspot changes in this webrev >> http://cr.openjdk.java.net/~ecaspole/graal_hsail/ >> I wanted to let you know that these hotspot changes really don't make >> sense on their own but co-operate with some JDK changes which we will >> be submitting in a separate webrev to the Sumatra-dev repository early >> next week (these JDK changes are much smaller than the graal changes). >> >> Here is a brief overview of how the pieces fit together... >> >> Basically we wanted the GPU offload programming model to be triggered >> by the programmer using Stream.parallel.forEach(). So the JDK changes >> are really just interceptions of the stream API for parallel forEach. >> The intercept code tests whether the stream meets a few criteria to be >> offloadable, and if so tell graal (thru the Sumatra interface) to >> compile the lambda method to HSAIL and dispatch it. If already >> compiled, it will just be dispatched. Currently we have a property, >> off by default, which tells the JDK intercept code to offload >> immediately. If the offload-immediate flag is set, no hotspot changes >> are really needed. >> >> The hotspot changes just provide an alternate way of enabling the >> offloading (without using the offload-immediate flag) by using the >> compilation of the underlying lambda method as a trigger for >> offloading. They are very experimental and we would welcome community >> input on other ways to do this. >> >> Hope this helps... >> >> -- Tom Deneau >> >> >> >> -----Original Message----- >> From: graal-dev-bounces at openjdk.java.net >> [mailto:graal-dev-bounces at openjdk.java.net] On Behalf Of Morris Meyer >> Sent: Tuesday, June 11, 2013 7:17 PM >> To: graal-dev at openjdk.java.net >> Subject: Re: webrev for Graal HSAIL backend >> >> Vasanth, >> >> After seeing Apple's WWDC and the 4,000 core dual-GPU system they >> built into the Mac Pro, I'm very happy to see the work your team has >> put together. Lots of good stuff here and I think we should take most of it. >> >> I like that the HSAIL backend is in the com.oracle.graal namespace - >> not so much as an Oracle engineer - but it will make working and >> refactoring these GPU and CPU backends much easier. Thanks. >> >> compilerBroker.cpp, library_call.cpp, runtime.cpp and arguments.cpp seem >> like the might be a little specialized for this point in time. Very >> interesting changes though. I would like to get the heterogeneous >> method support into HotSpot / Graal and sit down at the language >> summit and discuss how we take on constructs like the ForEach work. >> >> I think com.amd.sumatra.Sumatra is sort of in the right ballpark - it >> echos the change I made to CompilerToGPU in the earlier PTX work. I >> would like of like to reserve the sumatra package for lambda work >> along the lines you are thinking for a collections / lambda oriented >> java.lang.invoke set of code. We need to get the requirements for this >> sort of externalized kernel creating defined as soon as we can. Maybe >> ...bridge.gpu, ...bridge.gpu.hsail, ...bridge.gpu.ptx packages in the >> graal namespace? >> >> I think it might be a good next step to put in the HSAIL back end and >> tests and the emulator working at the gate so we can build and verify >> JDK9 / Sumatra / Graal changes in this environment going forward. >> >> I will be working as time permits on the heterogeneous methods and PTX >> invocation so we can get both platforms at the gate integrating changes. >> >> That's all for now. I'm looking forward to working my way through all >> these unit tests. Huge kudos AMD! >> >> --morris meyer >> >> On 6/11/13 6:16 PM, Venkatachalam, Vasanth wrote: >>> Hi, >>> >>> The AMD Sumatra team has submitted a webrev (http://cr.openjdk.java.net/~ecaspole/graal_hsail/) that adds HSAIL code generation support for Graal, allowing Java programs to be compiled and executed on HSAIL-enabled GPU/APU devices. While this work is a prototype, we have included several working unit test cases, including Mandelbrot and NBody. >>> >>> Features >>> >>> Arithmetic operations for integers, longs, doubles, and floats Loads, >>> stores and move operations Min/max/rem/carry operations for integers >>> and longs Conversion operations - (currently support conversions >>> between integers and floats, integers and doubles, integers and longs, floats and doubles). >>> Some math library operations (e.g., square root). >>> Support for JDK8 lambda constructs. >>> >>> Known Issues >>> >>> -The logic to handle register spilling is work-in-progress, so not all test cases that induce spilling are guaranteed to work. >>> -X86 register encodings are being passed to the HSAIL backend. The >>> calling convention returned by getCallingConvention() currently returns an x86 calling convention -Function call support has yet to be implemented. >>> >>> For a detailed list of unsupported features, refer to the routines >>> that are emitting "NYI" in HSAILLIRGenerator.java >>> >>> The test cases (except for BasicHSAILTest) require an HSAIL simulator or hardware to execute, but in lieu of a simulator or hardware they will output the HSAIL code generated, which is useful for debugging. Moreover, BasicHSAILTest provides a template for adding Java code snippets and viewing the HSAIL generated code without executing the code. >>> >>> We encourage the community to support this new backend and extend it with additional features. >>> >>> Vasanth >>> >>> >>> >>> >>> >>> >>> >>> >>> >> >> >> > > > From doug.simon at oracle.com Sat Jun 15 13:19:48 2013 From: doug.simon at oracle.com (doug.simon at oracle.com) Date: Sat, 15 Jun 2013 20:19:48 +0000 Subject: hg: graal/graal: 44 new changesets Message-ID: <20130615202226.89D0148241@hg.openjdk.java.net> Changeset: 4d9d0cb1520a Author: Christian Haeubl Date: 2013-06-13 09:40 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/4d9d0cb1520a Changed computation of inlining relevance to avoid that the inlining order affects the relevance. ! graal/com.oracle.graal.phases/src/com/oracle/graal/phases/graph/ComputeInliningRelevanceClosure.java Changeset: 53f090c5975a Author: Christian Haeubl Date: 2013-06-13 09:41 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/53f090c5975a Merge. Changeset: 6e4b72bcc97f Author: Christos Kotselidis Date: 2013-06-13 11:25 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/6e4b72bcc97f Remove graph from HotSpotNMethod ! graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/GraalCompilerTest.java ! graal/com.oracle.graal.hotspot.test/src/com/oracle/graal/hotspot/test/AheadOfTimeCompilationTest.java ! graal/com.oracle.graal.hotspot.test/src/com/oracle/graal/hotspot/test/HotSpotCryptoSubstitutionTest.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/CompilationTask.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotNmethod.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotRuntime.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/nodes/HotSpotNmethodExecuteNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/spi/GraalCodeCacheProvider.java Changeset: 4ebe31e19892 Author: Christos Kotselidis Date: 2013-06-13 11:25 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/4ebe31e19892 Merge ! graal/com.oracle.graal.hotspot.test/src/com/oracle/graal/hotspot/test/AheadOfTimeCompilationTest.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotRuntime.java Changeset: 7f2e23d309b3 Author: Christian Haeubl Date: 2013-06-13 10:54 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/7f2e23d309b3 Minor refactorings for ComputeInliningRelevanceClosure. ! graal/com.oracle.graal.phases/src/com/oracle/graal/phases/graph/ComputeInliningRelevanceClosure.java Changeset: 3ce140f4f2c9 Author: Christian Haeubl Date: 2013-06-13 14:44 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/3ce140f4f2c9 Bootstrap-specific fix for CompilationPolicy 0. ! src/share/vm/runtime/compilationPolicy.cpp Changeset: 3d4cdc2de2c1 Author: Christian Haeubl Date: 2013-06-13 14:45 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/3d4cdc2de2c1 Temporarily changed compilation policy to 0. ! src/share/vm/runtime/globals.hpp Changeset: b2934877ba61 Author: Christian Haeubl Date: 2013-06-13 14:47 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/b2934877ba61 Reverted default compilation policy to 4 if Graal is the only compiler. ! src/share/vm/runtime/globals.hpp Changeset: 0c717bcb2988 Author: Christian Haeubl Date: 2013-06-13 14:47 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/0c717bcb2988 Merge. Changeset: 2beeb916aa31 Author: Roland Schatz Date: 2013-06-12 16:28 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/2beeb916aa31 Add arrayKlassOffset field to HotSpotVMConfig. ! 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 ! src/share/vm/graal/graalCompilerToVM.cpp Changeset: e561e0a6f727 Author: Roland Schatz Date: 2013-06-12 16:29 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/e561e0a6f727 DynamicNewArrayNode ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotRuntime.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/DynamicNewArrayNode.java + graal/com.oracle.graal.replacements/src/com/oracle/graal/replacements/ArraySubstitutions.java ! graal/com.oracle.graal.replacements/src/com/oracle/graal/replacements/GraalMethodSubstitutions.java Changeset: 3a7a8666df94 Author: Roland Schatz Date: 2013-06-12 17:09 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/3a7a8666df94 Tests for DynamicNewArrayNode. + graal/com.oracle.graal.replacements.test/src/com/oracle/graal/replacements/test/DynamicNewArrayTest.java Changeset: 839791e70ff1 Author: Roland Schatz Date: 2013-06-13 13:19 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/839791e70ff1 Method for adding a new phase at the beginning of a suite. ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/phases/HighTier.java ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/phases/LowTier.java ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/phases/MidTier.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotRuntime.java ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/LoweringPhase.java ! graal/com.oracle.graal.phases/src/com/oracle/graal/phases/PhaseSuite.java Changeset: 85f926430ae6 Author: Roland Schatz Date: 2013-06-13 13:50 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/85f926430ae6 Test deoptimization in DynamicNewArrayNode. ! graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/GraalCompilerTest.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/NewObjectSnippets.java ! graal/com.oracle.graal.replacements.test/src/com/oracle/graal/replacements/test/DynamicNewArrayTest.java Changeset: ebb32c4589f3 Author: Christos Kotselidis Date: 2013-06-11 19:59 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/ebb32c4589f3 Force GC to process graal_installed_code references during marking (GRAAL-257) ! src/share/vm/code/codeCache.cpp ! src/share/vm/code/codeCache.hpp ! src/share/vm/code/nmethod.cpp ! src/share/vm/code/nmethod.hpp ! src/share/vm/memory/referenceProcessor.cpp ! src/share/vm/memory/referenceProcessor.hpp Changeset: 4a7dc38ae96b Author: Christos Kotselidis Date: 2013-06-12 11:36 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/4a7dc38ae96b Checkstyle fixes ! src/share/vm/code/codeCache.hpp ! src/share/vm/code/nmethod.cpp ! src/share/vm/memory/referenceProcessor.cpp Changeset: 9d6f0c55cda7 Author: Christos Kotselidis Date: 2013-06-12 11:37 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/9d6f0c55cda7 Merge Changeset: 6cbb7fb49de5 Author: Christos Kotselidis Date: 2013-06-13 12:52 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/6cbb7fb49de5 Merge Changeset: 055430b5abb9 Author: Christos Kotselidis Date: 2013-06-13 18:48 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/055430b5abb9 Merge Changeset: 5260095a574b Author: Christian Haeubl Date: 2013-06-14 09:28 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/5260095a574b Fixed probability computation for invokes with an exception edge. ! graal/com.oracle.graal.phases/src/com/oracle/graal/phases/graph/ComputeProbabilityClosure.java Changeset: 91b9c3f0100a Author: Christian Haeubl Date: 2013-06-14 09:29 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/91b9c3f0100a Merge. Changeset: 9645cfaffc62 Author: Gilles Duboscq Date: 2013-06-14 11:16 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/9645cfaffc62 CodeUtil.isPowerOf2 should not return true for Integer/Long.MIN_VALUE. CodeUtil.log2 should work even for numbers that are not powers of 2 ! graal/com.oracle.graal.api.code/src/com/oracle/graal/api/code/CodeUtil.java Changeset: 92cbc5e88484 Author: Gilles Duboscq Date: 2013-06-14 12:11 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/92cbc5e88484 Do not virtualize when locks do not match at merge ! graal/com.oracle.graal.virtual/src/com/oracle/graal/virtual/phases/ea/PartialEscapeClosure.java Changeset: 6b34d50d3d24 Author: Gilles Duboscq Date: 2013-06-14 11:16 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/6b34d50d3d24 Remove PiNode.anchor, use the guard field of FloatingGuardedNode instead ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/PiNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/extended/UnsafeArrayCastNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/extended/UnsafeCastNode.java ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/InliningUtil.java Changeset: 595f1f253ef4 Author: Gilles Duboscq Date: 2013-06-13 17:15 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/595f1f253ef4 Use createAnchoredReceiver to create the invokes's receiver check before inlining ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/InliningUtil.java Changeset: 0b30da13d86b Author: Doug Simon Date: 2013-06-14 15:01 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/0b30da13d86b fixed bug in InstanceOfSnippets - deoptimization action should be None for instanceofWithProfile snippet ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/InstanceOfSnippets.java Changeset: e063474076dd Author: Lukas Stadler Date: 2013-06-14 11:10 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/e063474076dd clean up .factorypath files on "mx ideclean" ! mxtool/mx.py Changeset: a5a89816a157 Author: Lukas Stadler Date: 2013-06-14 16:20 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/a5a89816a157 correct parameter type for NodeFlood.addAll ! graal/com.oracle.graal.graph/src/com/oracle/graal/graph/NodeFlood.java Changeset: a4e7a7dc74f3 Author: Lukas Stadler Date: 2013-06-14 16:23 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/a4e7a7dc74f3 better stamps for OrNodes ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/type/StampTool.java Changeset: 09baba95f1ae Author: Lukas Stadler Date: 2013-06-14 16:24 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/09baba95f1ae detect distinct values by looking at integer masks ! graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/StampCanonicalizerTest.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/type/IntegerStamp.java Changeset: 30499c84823d Author: Lukas Stadler Date: 2013-06-14 16:25 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/30499c84823d remove CullFrameStatesPhase ! graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/BoxingEliminationTest.java ! graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/ea/PartialEscapeAnalysisTest.java ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/phases/HighTier.java - graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/CullFrameStatesPhase.java ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/InliningPhase.java ! graal/com.oracle.graal.phases/src/com/oracle/graal/phases/GraalOptions.java Changeset: 33b3cd0222c8 Author: Lukas Stadler Date: 2013-06-14 16:26 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/33b3cd0222c8 PEA: allowed for defered effects on ends in MergeProcessor ! graal/com.oracle.graal.virtual/src/com/oracle/graal/virtual/phases/ea/EffectsClosure.java Changeset: ec8dd267d882 Author: Lukas Stadler Date: 2013-06-14 16:27 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/ec8dd267d882 public constructor for IndexedLocationNode ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/extended/IndexedLocationNode.java Changeset: 55bf0dc8e281 Author: Lukas Stadler Date: 2013-06-14 16:28 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/55bf0dc8e281 Merge Changeset: 215a4291e387 Author: Lukas Stadler Date: 2013-06-14 16:30 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/215a4291e387 add InliningPhase constructor with explicit InliningPolicy ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/InliningPhase.java Changeset: 5b21ddb3deaa Author: Andreas Woess Date: 2013-06-14 17:28 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/5b21ddb3deaa readd optional graph to HotSpotNmethod ! graal/com.oracle.graal.hotspot.test/src/com/oracle/graal/hotspot/test/HotSpotCryptoSubstitutionTest.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotNmethod.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotRuntime.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/nodes/HotSpotNmethodExecuteNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/spi/GraalCodeCacheProvider.java Changeset: 0531aa5ae1cd Author: Gilles Duboscq Date: 2013-06-14 17:07 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/0531aa5ae1cd Guards should not canonicalize to their own guard ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/GuardNode.java Changeset: 10fbede11db0 Author: Gilles Duboscq Date: 2013-06-14 17:09 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/10fbede11db0 Canonicalize useless PiNodes away ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/PiNode.java Changeset: 9469034773b2 Author: Christian Haeubl Date: 2013-06-14 15:52 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/9469034773b2 Fixed an issue concerning statistics for OSR compilations. ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/GraalCompiler.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/StructuredGraph.java Changeset: a323a9e20f9d Author: Christian Haeubl Date: 2013-06-14 19:12 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/a323a9e20f9d Fixed a few race conditions in the compilation queue. ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/CompilationTask.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/HotSpotVMConfig.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/bridge/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/meta/HotSpotResolvedJavaMethod.java ! src/share/vm/classfile/vmSymbols.hpp ! src/share/vm/compiler/compileBroker.cpp ! src/share/vm/graal/graalCompiler.cpp ! src/share/vm/graal/graalCompilerToVM.cpp ! src/share/vm/graal/graalVMToCompiler.cpp ! src/share/vm/graal/graalVMToCompiler.hpp Changeset: e90e48dae0ab Author: Christian Haeubl Date: 2013-06-14 19:13 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/e90e48dae0ab Merge. - graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/CullFrameStatesPhase.java Changeset: 440661cc7908 Author: Doug Simon Date: 2013-06-15 21:05 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/440661cc7908 a suite should be registered in the global _suites map at most once ! mxtool/mx.py Changeset: 4dada3ec9c58 Author: Doug Simon Date: 2013-06-15 21:27 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/4dada3ec9c58 mx checkstyle command no longer exits on first error ! mxtool/mx.py Changeset: 193d5163a94a Author: Doug Simon Date: 2013-06-15 21:28 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/193d5163a94a exclude projects from mx checkstyle if their Java compliance level is higher than the configured JDK ! mxtool/mx.py From s1255753 at sms.ed.ac.uk Sun Jun 16 15:35:47 2013 From: s1255753 at sms.ed.ac.uk (ATKIN-GRANVILLE Chris) Date: Sun, 16 Jun 2013 22:35:47 +0000 Subject: Instrumentation with snippets Message-ID: <9335A643-E176-4D18-9965-3C9FA7F4B1ED@sms.ed.ac.uk> An embedded and charset-unspecified text was scrubbed... Name: not available Url: http://mail.openjdk.java.net/pipermail/graal-dev/attachments/20130616/1ed8dbec/attachment.ksh From me at chrisatk.in Mon Jun 17 08:02:40 2013 From: me at chrisatk.in (Chris Atkin-Granville) Date: Mon, 17 Jun 2013 16:02:40 +0100 Subject: Instrumentation with snippets Message-ID: Hey guys, I'm trying to instrument memory operations using snippets, but something is going wrong. At the moment I'm focussing on StoreIndexedNode and LoadIndexedNode - array access operations. To be clear I don't want to replace the behaviour associated with these nodes - just augment existing functionality to basically log each operation (but I haven't got to actually writing the instrumentation yet). What I have at the moment is a new phase that I've added at PhasePosition.HIGH_LEVEL: public class ArrayAccessInstrumentationPhase extends Phase { private ArrayAccessSnippets.Templates snippets; public ArrayAccessInstrumentationPhase(CodeCacheProvider runtime, Replacements replacements, TargetDescription target) { snippets = new ArrayAccessSnippets.Templates(runtime, replacements, target); } @Override protected void run(StructuredGraph graph) { for (Node node: graph.getNodes()) { if (node instanceof StoreIndexedNode) snippets.lower((StoreIndexedNode) node); if (node instanceof LoadIndexedNode) snippets.lower((LoadIndexedNode) node); } } } And the snippets: public class ArrayAccessSnippets implements Snippets { @Snippet public static StoreIndexedNode arrayIndexStore(StoreIndexedNode n) { // TODO: add instrumentation here return n; } @Snippet public static LoadIndexedNode arrayIndexLoad(LoadIndexedNode n) { // TODO: add instrumentation here return n; } public static class Templates extends AbstractTemplates { private final SnippetInfo load = snippet(ArrayAccessSnippets.class, "arrayIndexLoad"); private final SnippetInfo store = snippet(ArrayAccessSnippets.class, "arrayIndexStore"); public Templates(CodeCacheProvider runtime, Replacements replacements, TargetDescription target) { super(runtime, replacements, target); } public void lower(final StoreIndexedNode node) { Arguments args = new Arguments(store) {{ add("n", node); }}; template(args).instantiate(runtime, node, DEFAULT_REPLACER, args); } public void lower(final LoadIndexedNode node) { Arguments args = new Arguments(load) {{ add("n", node); }}; template(args).instantiate(runtime, node, DEFAULT_REPLACER, args); } } } However this causes Java to run out of heap space (java.lang.OutOfMemoryError) - I think because the JVM gets into an "infinite replacement" spiral? At any rate, I see in HotSpotRuntime:lower() there's behaviour associated with StoreIndexedNode (line 582) and LoadIndexedNode (line 574) so I tried to move that over into my snippet - but that didn't work because I couldn't see any way to get access to a LoweringToolImpl from within my snippets. Anybody have any thoughts of how I can achieve this access instrumentation? Thanks, Chris (P.S. Not sure what went wrong with my last email!) From doug.simon at oracle.com Mon Jun 17 09:05:48 2013 From: doug.simon at oracle.com (Doug Simon) Date: Mon, 17 Jun 2013 18:05:48 +0200 Subject: Instrumentation with snippets In-Reply-To: References: Message-ID: <25380D5F-06EF-4221-AE86-1E14C94DF627@oracle.com> Hi Chris, Snippets (as opposed to method substitutions) are currently only used during lowering. So one thing you could do is replace the lowering in HotSpotRuntime.lower() for LoadIndexedNode and StoreIndexedNode to use your snippets instead. However, this means you need to replicate the correct semantics for these operations in your snippet in addition to the instrumentation code. I think a better alternative would be to insert an InvokeNode before/after the array access node that takes the same inputs of the array access and calls a well known (static) instrumentation method. It might be instructive to look at MonitorSnippets.checkBalancedMonitors() for an example of inserting an invoke node. -Doug On Jun 17, 2013, at 5:02 PM, Chris Atkin-Granville wrote: > Hey guys, > > I'm trying to instrument memory operations using snippets, but something is going wrong. At the moment I'm focussing on StoreIndexedNode and LoadIndexedNode - array access operations. To be clear I don't want to replace the behaviour associated with these nodes - just augment existing functionality to basically log each operation (but I haven't got to actually writing the instrumentation yet). > > What I have at the moment is a new phase that I've added at PhasePosition.HIGH_LEVEL: > > public class ArrayAccessInstrumentationPhase extends Phase { > > private ArrayAccessSnippets.Templates snippets; > > public ArrayAccessInstrumentationPhase(CodeCacheProvider runtime, Replacements replacements, TargetDescription target) { > snippets = new ArrayAccessSnippets.Templates(runtime, replacements, target); > } > > @Override > protected void run(StructuredGraph graph) { > for (Node node: graph.getNodes()) { > if (node instanceof StoreIndexedNode) > snippets.lower((StoreIndexedNode) node); > > if (node instanceof LoadIndexedNode) > snippets.lower((LoadIndexedNode) node); > } > } > > } > > And the snippets: > > public class ArrayAccessSnippets implements Snippets { > > @Snippet > public static StoreIndexedNode arrayIndexStore(StoreIndexedNode n) { > // TODO: add instrumentation here > return n; > } > > @Snippet > public static LoadIndexedNode arrayIndexLoad(LoadIndexedNode n) { > // TODO: add instrumentation here > return n; > } > > public static class Templates extends AbstractTemplates { > > private final SnippetInfo load = snippet(ArrayAccessSnippets.class, "arrayIndexLoad"); > private final SnippetInfo store = snippet(ArrayAccessSnippets.class, "arrayIndexStore"); > > public Templates(CodeCacheProvider runtime, Replacements replacements, TargetDescription target) { > super(runtime, replacements, target); > } > > public void lower(final StoreIndexedNode node) { > Arguments args = new Arguments(store) {{ > add("n", node); > }}; > > template(args).instantiate(runtime, node, DEFAULT_REPLACER, args); > } > > public void lower(final LoadIndexedNode node) { > Arguments args = new Arguments(load) {{ > add("n", node); > }}; > > template(args).instantiate(runtime, node, DEFAULT_REPLACER, args); > } > } > } > > However this causes Java to run out of heap space (java.lang.OutOfMemoryError) - I think because the JVM gets into an "infinite replacement" spiral? > > At any rate, I see in HotSpotRuntime:lower() there's behaviour associated with StoreIndexedNode (line 582) and LoadIndexedNode (line 574) so I tried to move that over into my snippet - but that didn't work because I couldn't see any way to get access to a LoweringToolImpl from within my snippets. > > Anybody have any thoughts of how I can achieve this access instrumentation? > > Thanks, Chris > > (P.S. Not sure what went wrong with my last email!) From me at chrisatk.in Mon Jun 17 12:10:23 2013 From: me at chrisatk.in (Chris Atkin-Granville) Date: Mon, 17 Jun 2013 20:10:23 +0100 Subject: Instrumentation with snippets In-Reply-To: <51BF4C0F.4010709@oracle.com> References: <25380D5F-06EF-4221-AE86-1E14C94DF627@oracle.com> <51BF4C0F.4010709@oracle.com> Message-ID: Hi Doug, Mick, On 17 Jun 2013, at 17:05, Doug Simon wrote: > Snippets (as opposed to method substitutions) are currently only used during lowering. So one thing you could do is replace the lowering in HotSpotRuntime.lower() for LoadIndexedNode and StoreIndexedNode to use your snippets instead. However, this means you need to replicate the correct semantics for these operations in your snippet in addition to the instrumentation code. I think a better alternative would be to insert an InvokeNode before/after the array access node that takes the same inputs of the array access and calls a well known (static) instrumentation method. After that information I agree that inserting an InvokeNode is probably the best idea too. I'd like to avoid modifying the Graal source if possible! > It might be instructive to look at MonitorSnippets.checkBalancedMonitors() for an example of inserting an invoke node. Thanks for the pointer. Is the best way to do this to add a phase (at HIGH_LEVEL I presume?) and then call a method that inserts InvokeNodes upon each instance of StoreIndexedNode/LoadIndexedNode? In other words, to use the same mechanism as in the code I posted below, replacing the contents of ArrayAccessSnippets.Templates:lower() with code that adds InvokeNodes? If so, I have already tried this but I'm getting SIGSEGVs from the JVM upon execution (LinkResolver::lookup_method_in_klasses) - I've attached the full report. At the moment the behaviour in my Templates class is: private final SnippetInfo methodOnStore = snippet(ArrayAccessSnippets.class, "arrayIndexStore"); // note - arrayIndexStore has been declared static, no args, void return public void invokeAfter(StoreIndexedNode node, StructuredGraph graph) { JavaType returnType = methodOnStore.getMethod().getSignature().getReturnType(methodOnStore.getMethod().getDeclaringClass()); MethodCallTargetNode callTarget = graph.add(new MethodCallTargetNode(InvokeKind.Static, methodOnStore.getMethod(), new ValueNode[] {}, returnType)); InvokeNode invoke = graph.add(new InvokeNode(callTarget, 0)); invoke.setStateAfter(node.stateAfter()); graph.addAfterFixed(node, invoke); } invokeAfter is called from my HIGH_LEVEL phase [i.e., for(Node node: graph.getNodes()) if (node instanceOf StoreIndexedNode) snippets.invokeAfter((StoreIndexedNode) node, graph); ] I'm confused as to why I'm getting the LinkResolver error - to me (through a debugger) it looks like everything is "wired up" correctly. On 17 Jun 2013, at 18:49, Mick Jordan wrote: > I am planning to implement the VMA instrumentation from Maxine in Graal fairly soon which, as Doug suggests, involves inserting Invoke nodes in general. However, depending on the nature of the instrumentation, the inlining may then remove them and inline the instrumentation. This should work with Hotspot also (eventually). Interesting. Could you perhaps elaborate on the "nature of the instrumentation"? Specifically, would you perform inlining based on the behaviour of the instrumentation or something else? From christian.thalinger at oracle.com Mon Jun 17 17:14:19 2013 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Mon, 17 Jun 2013 17:14:19 -0700 Subject: Instrumentation with snippets In-Reply-To: References: <25380D5F-06EF-4221-AE86-1E14C94DF627@oracle.com> <51BF4C0F.4010709@oracle.com> Message-ID: <9806FD7E-7B4D-4848-A580-DD6FE01C08D5@oracle.com> On Jun 17, 2013, at 12:10 PM, Chris Atkin-Granville wrote: > Hi Doug, Mick, > > On 17 Jun 2013, at 17:05, Doug Simon wrote: >> Snippets (as opposed to method substitutions) are currently only used during lowering. So one thing you could do is replace the lowering in HotSpotRuntime.lower() for LoadIndexedNode and StoreIndexedNode to use your snippets instead. However, this means you need to replicate the correct semantics for these operations in your snippet in addition to the instrumentation code. I think a better alternative would be to insert an InvokeNode before/after the array access node that takes the same inputs of the array access and calls a well known (static) instrumentation method. > > After that information I agree that inserting an InvokeNode is probably the best idea too. I'd like to avoid modifying the Graal source if possible! I don't know what you are working on but can't you do it with bytecode instrumentation? -- Chris > >> It might be instructive to look at MonitorSnippets.checkBalancedMonitors() for an example of inserting an invoke node. > > Thanks for the pointer. Is the best way to do this to add a phase (at HIGH_LEVEL I presume?) and then call a method that inserts InvokeNodes upon each instance of StoreIndexedNode/LoadIndexedNode? In other words, to use the same mechanism as in the code I posted below, replacing the contents of ArrayAccessSnippets.Templates:lower() with code that adds InvokeNodes? If so, I have already tried this but I'm getting SIGSEGVs from the JVM upon execution (LinkResolver::lookup_method_in_klasses) - I've attached the full report. > > At the moment the behaviour in my Templates class is: > > private final SnippetInfo methodOnStore = snippet(ArrayAccessSnippets.class, "arrayIndexStore"); // note - arrayIndexStore has been declared static, no args, void return > > public void invokeAfter(StoreIndexedNode node, StructuredGraph graph) { > JavaType returnType = methodOnStore.getMethod().getSignature().getReturnType(methodOnStore.getMethod().getDeclaringClass()); > MethodCallTargetNode callTarget = graph.add(new MethodCallTargetNode(InvokeKind.Static, methodOnStore.getMethod(), new ValueNode[] {}, returnType)); > InvokeNode invoke = graph.add(new InvokeNode(callTarget, 0)); > invoke.setStateAfter(node.stateAfter()); > graph.addAfterFixed(node, invoke); > } > > invokeAfter is called from my HIGH_LEVEL phase [i.e., for(Node node: graph.getNodes()) if (node instanceOf StoreIndexedNode) snippets.invokeAfter((StoreIndexedNode) node, graph); ] > > I'm confused as to why I'm getting the LinkResolver error - to me (through a debugger) it looks like everything is "wired up" correctly. > > On 17 Jun 2013, at 18:49, Mick Jordan wrote: >> I am planning to implement the VMA instrumentation from Maxine in Graal fairly soon which, as Doug suggests, involves inserting Invoke nodes in general. However, depending on the nature of the instrumentation, the inlining may then remove them and inline the instrumentation. This should work with Hotspot also (eventually). > > Interesting. Could you perhaps elaborate on the "nature of the instrumentation"? Specifically, would you perform inlining based on the behaviour of the instrumentation or something else? > From doug.simon at oracle.com Tue Jun 18 05:12:10 2013 From: doug.simon at oracle.com (Doug Simon) Date: Tue, 18 Jun 2013 14:12:10 +0200 Subject: Instrumentation with snippets In-Reply-To: References: <25380D5F-06EF-4221-AE86-1E14C94DF627@oracle.com> <51BF4C0F.4010709@oracle.com> Message-ID: <6E2D9743-A95D-4112-8ACD-458E8F930F83@oracle.com> Chris, After more thought and discussion with other Graal devs, the InvokeNode solution won't work as the HotSpot runtime cannot patch an unlinked call at a location that doesn't map back to the bytecode index (BCI) of an INVOKE* instruction. In this case, the BCI is for one of the *ASTORE *ALOAD instructions. The reason it works in the example I gave is that the call to MonitorSnippets.initCounter() is force inlined so there's no need for call patching. Instead, what you want is to place your own placeholder node before/after the array access instructions where that node implements Lowerable and lowers itself via a snippet. For this, you need to write a phase that does the insertion of your new nodes and also modify HotSpotRuntime to register your snippets and call them in the lower() method. -Doug On Jun 17, 2013, at 9:10 PM, Chris Atkin-Granville wrote: > Hi Doug, Mick, > > On 17 Jun 2013, at 17:05, Doug Simon wrote: >> Snippets (as opposed to method substitutions) are currently only used during lowering. So one thing you could do is replace the lowering in HotSpotRuntime.lower() for LoadIndexedNode and StoreIndexedNode to use your snippets instead. However, this means you need to replicate the correct semantics for these operations in your snippet in addition to the instrumentation code. I think a better alternative would be to insert an InvokeNode before/after the array access node that takes the same inputs of the array access and calls a well known (static) instrumentation method. > > After that information I agree that inserting an InvokeNode is probably the best idea too. I'd like to avoid modifying the Graal source if possible! > >> It might be instructive to look at MonitorSnippets.checkBalancedMonitors() for an example of inserting an invoke node. > > Thanks for the pointer. Is the best way to do this to add a phase (at HIGH_LEVEL I presume?) and then call a method that inserts InvokeNodes upon each instance of StoreIndexedNode/LoadIndexedNode? In other words, to use the same mechanism as in the code I posted below, replacing the contents of ArrayAccessSnippets.Templates:lower() with code that adds InvokeNodes? If so, I have already tried this but I'm getting SIGSEGVs from the JVM upon execution (LinkResolver::lookup_method_in_klasses) - I've attached the full report. > > At the moment the behaviour in my Templates class is: > > private final SnippetInfo methodOnStore = snippet(ArrayAccessSnippets.class, "arrayIndexStore"); // note - arrayIndexStore has been declared static, no args, void return > > public void invokeAfter(StoreIndexedNode node, StructuredGraph graph) { > JavaType returnType = methodOnStore.getMethod().getSignature().getReturnType(methodOnStore.getMethod().getDeclaringClass()); > MethodCallTargetNode callTarget = graph.add(new MethodCallTargetNode(InvokeKind.Static, methodOnStore.getMethod(), new ValueNode[] {}, returnType)); > InvokeNode invoke = graph.add(new InvokeNode(callTarget, 0)); > invoke.setStateAfter(node.stateAfter()); > graph.addAfterFixed(node, invoke); > } > > invokeAfter is called from my HIGH_LEVEL phase [i.e., for(Node node: graph.getNodes()) if (node instanceOf StoreIndexedNode) snippets.invokeAfter((StoreIndexedNode) node, graph); ] > > I'm confused as to why I'm getting the LinkResolver error - to me (through a debugger) it looks like everything is "wired up" correctly. > > On 17 Jun 2013, at 18:49, Mick Jordan wrote: >> I am planning to implement the VMA instrumentation from Maxine in Graal fairly soon which, as Doug suggests, involves inserting Invoke nodes in general. However, depending on the nature of the instrumentation, the inlining may then remove them and inline the instrumentation. This should work with Hotspot also (eventually). > > Interesting. Could you perhaps elaborate on the "nature of the instrumentation"? Specifically, would you perform inlining based on the behaviour of the instrumentation or something else? > From Vasanth.Venkatachalam at amd.com Tue Jun 18 08:50:19 2013 From: Vasanth.Venkatachalam at amd.com (Venkatachalam, Vasanth) Date: Tue, 18 Jun 2013 15:50:19 +0000 Subject: possible bug in mx/projects handling In-Reply-To: <8768AD30-240F-42FA-8D84-7179CD5681F9@oracle.com> References: <5DD1503F815BD14889DC81D28643E3A73D8CC90C@sausexdag06.amd.com> <75209595-07E0-4D7F-9C70-D857FC9A9A3F@oracle.com> <8768AD30-240F-42FA-8D84-7179CD5681F9@oracle.com> Message-ID: <5DD1503F815BD14889DC81D28643E3A73D8DDCDE@sausexdag06.amd.com> Hi Doug, We're still seeing this issue with the mx scripts attempting to build JDK8 packages when the configured JDK is JDK 7. Below is the verbose output from mx build. You can see it mentions it is excluding com.amd.sumatra from graal.jar, but then it tries to compile one of the classes in this package. Vasanth Excluding com.amd.sumatra from /home/tester/graalcloneinternal/graal/graal.jar (Java compliance level 1.8 required) Creating /home/tester/graalcloneinternal/graal/jdk1.7.0_13/product from /home/tester/Downloads/jdk1.7.0_13 Creating VM directory in JDK7: /home/tester/graalcloneinternal/graal/jdk1.7.0_13/product/jre/lib/amd64/graal cd /home/tester/graalcloneinternal/graal/make; \ make BUILD_FLAVOR=productgraal VM_TARGET=productgraal \ generic_buildgraal INFO: ENABLE_FULL_DEBUG_SYMBOLS=1 INFO: /usr/bin/objcopy cmd found so will create .debuginfo files. INFO: STRIP_POLICY=min_strip INFO: ZIP_DEBUGINFO_FILES=0 make[1]: Entering directory `/home/tester/graalcloneinternal/graal/make' ANT_OPTS=-Djava.io.tmpdir='/home/tester/graalcloneinternal/graal/build/linux/tmp' JAVA_HOME='/home/tester/Downloads/jdk1.7.0_13' ant -f /home/tester/graalcloneinternal/graal/make/build-graal.xml -Dgamma.dir=/home/tester/graalcloneinternal/graal -Dshared.dir=/home/tester/graalcloneinternal/graal/build/linux/shared Buildfile: /home/tester/graalcloneinternal/graal/make/build-graal.xml options: cleanclasses: compile: [mkdir] Created dir: /home/tester/graalcloneinternal/graal/build/linux/shared/graal [javac] Compiling 759 source files to /home/tester/graalcloneinternal/graal/build/linux/shared/graal [javac] /home/tester/graalcloneinternal/graal/graal/com.amd.sumatra/src/com/amd/sumatra/ForEachToGraal.java:94: error: illegal start of expression [javac] filter(p -> p.getName().equals("accept")).toArray(); [javac] ^ [javac] 1 error -----Original Message----- From: Doug Simon [mailto:doug.simon at oracle.com] Sent: Monday, June 03, 2013 11:29 AM To: Deneau, Tom Cc: Venkatachalam, Vasanth; graal-dev at openjdk.java.net Subject: Re: possible bug in mx/projects handling Ok, I see the problem. Pushing through a fix now. Here's the patch: diff -r 91a1041ec905 mxtool/mx.py --- a/mxtool/mx.py Sat Jun 01 20:42:22 2013 -0400 +++ b/mxtool/mx.py Mon Jun 03 18:07:59 2013 +0200 @@ -1700,6 +1700,11 @@ try: zf = zipfile.ZipFile(tmp, 'w') for p in sorted_deps(d.deps): + # skip a Java project if its Java compliance level is "higher" than the configured JDK + if java().javaCompliance < p.javaCompliance: + log('Excluding {0} from {2} (Java compliance level {1} required)'.format(p.name, p.javaCompliance, d.path)) + continue + outputDir = p.output_dir() for root, _, files in os.walk(outputDir): relpath = root[len(outputDir) + 1:] On Jun 3, 2013, at 5:31 PM, "Deneau, Tom" wrote: > Doug -- > > Did you also put your com.amd.sumatra as a dependency for graal.jar? That is where the problem seems to arise. > > distribution at GRAAL@path=graal.jar > distribution at GRAAL@dependencies=com.oracle.graal.hotspot.amd64,com.ora > cle.graal.hotspot.sparc,com.oracle.graal.hotspot,com.amd.sumatra > > -- Tom > > -----Original Message----- > From: graal-dev-bounces at openjdk.java.net > [mailto:graal-dev-bounces at openjdk.java.net] On Behalf Of Doug Simon > Sent: Monday, June 03, 2013 9:02 AM > To: Venkatachalam, Vasanth > Cc: graal-dev at openjdk.java.net > Subject: Re: possible bug in mx/projects handling > > > On May 31, 2013, at 11:02 PM, "Venkatachalam, Vasanth" wrote: > >> Hi, >> >> We have a project com.amd.sumatra which requires java 1.8 compliance to build. >> >> We've added lines in mx/project to specify that the project shouldn't be built when building with a 1.7 JDK: >> >> distribution at GRAAL@path=graal.jar >> distribution at GRAAL@dependencies=com.oracle.graal.hotspot.amd64,com.or >> acle.graal.hotspot.sparc,com.oracle.graal.hotspot,com.amd.sumatra >> >> # com.amd.sumatra >> project at com.amd.sumatra@subDir=graal >> project at com.amd.sumatra@sourceDirs=src >> project at com.amd.sumatra@dependencies=com.oracle.graal.hotspot,com.ora >> cle.graal.hotspot.amd64,com.oracle.graal.hsail,com.oracle.graal.compi >> ler.hsail,com.amd.okra >> project at com.amd.sumatra@checkstyle=com.oracle.graal.graph >> project at com.amd.sumatra@javaCompliance=1.8 >> >> When I do an mx build, I see the lines >> >> Excluding com.amd.sumatra fro build (Java compliance level 1.8 >> required) >> >> But then Graal goes ahead and tries to build the package. This appears to be a bug. Can someone look into this? > > I tried to reproduce this by creating a local com.amd.sumatra project and used some JDK 1.8 API in it. However, 'mx build' does the expected thing in may case (i.e. does not try to compiled anything in com.amd.sumatra). Could you please send me the output of 'mx clean --no-native; mx -v build' so I can investigate further. > > -Doug > From Vasanth.Venkatachalam at amd.com Tue Jun 18 09:27:49 2013 From: Vasanth.Venkatachalam at amd.com (Venkatachalam, Vasanth) Date: Tue, 18 Jun 2013 16:27:49 +0000 Subject: update on graal HSAIL backend webrev Message-ID: <5DD1503F815BD14889DC81D28643E3A73D8DDD0C@sausexdag06.amd.com> Hi, I wanted to give an update on our Graal webrev. We have fixed all of the Java warnings and most of the checkstyle errors. The only checkstyle errors that remain are coming from the license header used in two packages ( HSAIL simulator source) that currently require a University of Illinois license, as opposed to the Oracle license which checkstyle is expecting. We are internally discussing how to handle the licensing issue. I ran the three commands the Doug listed: mx clean mx build --jdt /path/to/ecj.jar --jdt-warning-as-error mx checkstyle Aside from the checkstyle warnings mentioned above, there were no issues. However, when using JDK7, mx still tries to build JDK 8 projects, even though their compliance level was specified as Java 8 in mx/projects. I reported this bug on the mailing list. I'd like to propose two possible ways we can submit the revised webrev, and get people's feedback on what's preferable. 1) The easiest approach would be to give you a single webrev encompassing all changes and provide you with adequate documentation that will allow you to be selective in what projects to review. 2) We can split this up into multiple webrevs. However, due to dependencies you will need to apply all the patches to be able to build. The four-way split I propose is as follows: A) Hotspot changes B) Graal changes B1) Infrastructure changes B2) Test cases Let me know what's preferable. If I don't hear from anyone I plan to produce 1) within the next couple of days. Vasanth /home/tester/graalcloneinternal/graal/graal/com.amd.okra/src/com/amd/okra/OkraKernel.java:2: Line does not match expected header line of ' \* Copyright \(c\) (20[0-9][0-9], )?20[0-9][0-9], Oracle and/or its affiliates. All rights reserved.'. /home/tester/graalcloneinternal/graal/graal/com.amd.okra/src/com/amd/okra/OkraContext.java:2: Line does not match expected header line of ' \* Copyright \(c\) (20[0-9][0-9], )?20[0-9][0-9], Oracle and/or its affiliates. All rights reserved.'. /home/tester/graalcloneinternal/graal/graal/com.amd.okra/src/com/amd/okra/OkraOpenCLtoHSAILCompiler.java:2: Line does not match expected header line of ' \* Copyright \(c\) (20[0-9][0-9], )?20[0-9][0-9], Oracle and/or its affiliates. All rights reserved.'. /home/tester/graalcloneinternal/graal/graal/com.amd.okra/src/com/amd/okra/OkraUtil.java:2: Line does not match expected header line of ' \* Copyright \(c\) (20[0-9][0-9], )?20[0-9][0-9], Oracle and/or its affiliates. All rights reserved.'. -----Original Message----- From: Doug Simon [mailto:doug.simon at oracle.com] Sent: Saturday, June 15, 2013 3:20 PM To: Venkatachalam, Vasanth Cc: graal-dev at openjdk.java.net Subject: Re: webrev for Graal HSAIL backend Hi Vasanth, On Jun 14, 2013, at 10:34 PM, "Venkatachalam, Vasanth" wrote: > Hi Doug, > > Thanks for the feedback. We're addressing your comments and had a few questions. > > 1) I'm trying to understand the issue with the formatting. To apply the Eclipse formatter, I first ran mx ideinit, then started eclipse and under projects->properties->Java Code Style->Formatter, I made sure the profile (Unmanaged profile 'Graal') was selected. Is this the correct way to apply the formatter? Yes. The Eclipse project configurations created by eclipseinit should also apply the formatter to any Java file when it is saved. > Can you give an example of some code that wasn't formatted according to these rules? Now that I've looked at the patch in more detail, I can't see any problem in terms of formatting. > 2). The only projects that use JDK8 features are com.amd.sumatra, and com.oracle.graal.compiler.hsail.test.lambda, In mx/projects we have specified that these projects have Java compliance of 1.8, so they shouldn't be compiled if the JDK used is 1.7. It seems like there should be a way for Eclipse to pick up on these changes after running mx ideinit. Are you saying this isn't the case? One problem is that Eclipse doesn't (yet) support JDK8 *language* features such as lambdas. Projects that only use JDK8 library features should be fine. The ideinit command does not consider compliance level when generating Eclipse project configurations - it probably should. And it should probably ignore any projects whose compliance level is >= 8 altogether. Not only does Eclipse not yet support JDK8 anguage features, it cannot yet generate JDK8 class files (the maximum "Compiler compliance level" one can currently set in Eclipse is 1.7). I've just modified the checkstyle command to pay attention to compliance levels. With this change, you should now be able to test your changes for Graal compliance on the command line with these commands: mx clean mx build --jdt /path/to/ecj.jar --jdt-warning-as-error mx checkstyle Once all 3 pass without any warnings or errors, the code should be easier to review and integrate. Note that these commands are part of our gate so we need to get them passing anyway. If you are game, you could try and replicate our complete gate testing with: mx --jacoco on gate BTW, if you download an ecj.jar[1] to /mx/ecj.jar, it will be automatically detected and used by the 'mx build' command, removing the need for the --jdt argument. Let me know if you run into any problems or have any further questions. -Doug [1] http://www.eclipse.org/downloads/download.php?file=/eclipse/downloads/drops4/R-4.2.2-201302041200/ecj-4.2.2.jar > -----Original Message----- > From: graal-dev-bounces at openjdk.java.net > [mailto:graal-dev-bounces at openjdk.java.net] On Behalf Of Doug Simon > Sent: Thursday, June 13, 2013 9:04 AM > To: Deneau, Tom > Cc: sumatra-dev at openjdk.java.net; graal-dev at openjdk.java.net > Subject: Re: webrev for Graal HSAIL backend > > Tom, > > It would really help to have this patch broken up into components that can be separately considered for integration. In particular (as Morris stated), having the HSAIL backend (and tests) in Graal would be great so a separate patch for this code would be a good first step. > > One immediate observation is that a lot of the code does not yet import into Eclipse very well. This is the primary tool we use for development and code comprehension so getting the code into Eclipse compliant form would be very helpful in terms of being able to efficiently assess a contribution and offer further feedback. This means: > > o Only use Java 7 language features (Eclipse does not yet support Java 8 language features and it's not clear when it will). > o Remove all Checkstyle warnings (use the eclipse-cs plugin or 'mx checkstyle'). > o Remove all Java warnings (which show up in the Eclipse Problems view). > o Format Java code with the Eclipse formatter (the Eclipse projects generated by 'mx eclipseinit' will ensure the Graal code formatting rules are used). > > It would be useful to have a high level description of the code, broken down by package or collection of packages. This can either be plain text or (preferably) package-info.java files. > > I notice there are files without licenses and some with University of Illinois licenses (the Okra framework). I'm no expert on licensing, but this may causes integration issues. > > The HotSpot changes are probably best to keep in the Sumatra repository for now given their experimental nature. > > I look forward to further progress in terms of getting Sumatra code into Graal - thanks for a good start! > > -Doug > > On Jun 12, 2013, at 5:59 PM, "Deneau, Tom" wrote: > >> Morris -- >> >> Regarding your comments on the hotspot changes in this webrev >> http://cr.openjdk.java.net/~ecaspole/graal_hsail/ >> I wanted to let you know that these hotspot changes really don't make >> sense on their own but co-operate with some JDK changes which we will >> be submitting in a separate webrev to the Sumatra-dev repository >> early next week (these JDK changes are much smaller than the graal changes). >> >> Here is a brief overview of how the pieces fit together... >> >> Basically we wanted the GPU offload programming model to be triggered >> by the programmer using Stream.parallel.forEach(). So the JDK changes >> are really just interceptions of the stream API for parallel forEach. >> The intercept code tests whether the stream meets a few criteria to >> be offloadable, and if so tell graal (thru the Sumatra interface) to >> compile the lambda method to HSAIL and dispatch it. If already >> compiled, it will just be dispatched. Currently we have a property, >> off by default, which tells the JDK intercept code to offload >> immediately. If the offload-immediate flag is set, no hotspot >> changes are really needed. >> >> The hotspot changes just provide an alternate way of enabling the >> offloading (without using the offload-immediate flag) by using the >> compilation of the underlying lambda method as a trigger for >> offloading. They are very experimental and we would welcome >> community input on other ways to do this. >> >> Hope this helps... >> >> -- Tom Deneau >> >> >> >> -----Original Message----- >> From: graal-dev-bounces at openjdk.java.net >> [mailto:graal-dev-bounces at openjdk.java.net] On Behalf Of Morris Meyer >> Sent: Tuesday, June 11, 2013 7:17 PM >> To: graal-dev at openjdk.java.net >> Subject: Re: webrev for Graal HSAIL backend >> >> Vasanth, >> >> After seeing Apple's WWDC and the 4,000 core dual-GPU system they >> built into the Mac Pro, I'm very happy to see the work your team has >> put together. Lots of good stuff here and I think we should take most of it. >> >> I like that the HSAIL backend is in the com.oracle.graal namespace - >> not so much as an Oracle engineer - but it will make working and >> refactoring these GPU and CPU backends much easier. Thanks. >> >> compilerBroker.cpp, library_call.cpp, runtime.cpp and arguments.cpp seem >> like the might be a little specialized for this point in time. Very >> interesting changes though. I would like to get the heterogeneous >> method support into HotSpot / Graal and sit down at the language >> summit and discuss how we take on constructs like the ForEach work. >> >> I think com.amd.sumatra.Sumatra is sort of in the right ballpark - it >> echos the change I made to CompilerToGPU in the earlier PTX work. I >> would like of like to reserve the sumatra package for lambda work >> along the lines you are thinking for a collections / lambda oriented >> java.lang.invoke set of code. We need to get the requirements for this >> sort of externalized kernel creating defined as soon as we can. >> Maybe ...bridge.gpu, ...bridge.gpu.hsail, ...bridge.gpu.ptx packages >> in the graal namespace? >> >> I think it might be a good next step to put in the HSAIL back end and >> tests and the emulator working at the gate so we can build and verify >> JDK9 / Sumatra / Graal changes in this environment going forward. >> >> I will be working as time permits on the heterogeneous methods and >> PTX invocation so we can get both platforms at the gate integrating changes. >> >> That's all for now. I'm looking forward to working my way through >> all these unit tests. Huge kudos AMD! >> >> --morris meyer >> >> On 6/11/13 6:16 PM, Venkatachalam, Vasanth wrote: >>> Hi, >>> >>> The AMD Sumatra team has submitted a webrev (http://cr.openjdk.java.net/~ecaspole/graal_hsail/) that adds HSAIL code generation support for Graal, allowing Java programs to be compiled and executed on HSAIL-enabled GPU/APU devices. While this work is a prototype, we have included several working unit test cases, including Mandelbrot and NBody. >>> >>> Features >>> >>> Arithmetic operations for integers, longs, doubles, and floats >>> Loads, stores and move operations Min/max/rem/carry operations for >>> integers and longs Conversion operations - (currently support >>> conversions between integers and floats, integers and doubles, integers and longs, floats and doubles). >>> Some math library operations (e.g., square root). >>> Support for JDK8 lambda constructs. >>> >>> Known Issues >>> >>> -The logic to handle register spilling is work-in-progress, so not all test cases that induce spilling are guaranteed to work. >>> -X86 register encodings are being passed to the HSAIL backend. The >>> calling convention returned by getCallingConvention() currently returns an x86 calling convention -Function call support has yet to be implemented. >>> >>> For a detailed list of unsupported features, refer to the routines >>> that are emitting "NYI" in HSAILLIRGenerator.java >>> >>> The test cases (except for BasicHSAILTest) require an HSAIL simulator or hardware to execute, but in lieu of a simulator or hardware they will output the HSAIL code generated, which is useful for debugging. Moreover, BasicHSAILTest provides a template for adding Java code snippets and viewing the HSAIL generated code without executing the code. >>> >>> We encourage the community to support this new backend and extend it with additional features. >>> >>> Vasanth >>> >>> >>> >>> >>> >>> >>> >>> >>> >> >> >> > > > From doug.simon at oracle.com Tue Jun 18 11:49:58 2013 From: doug.simon at oracle.com (Doug Simon) Date: Tue, 18 Jun 2013 20:49:58 +0200 Subject: possible bug in mx/projects handling In-Reply-To: <5DD1503F815BD14889DC81D28643E3A73D8DDCDE@sausexdag06.amd.com> References: <5DD1503F815BD14889DC81D28643E3A73D8CC90C@sausexdag06.amd.com> <75209595-07E0-4D7F-9C70-D857FC9A9A3F@oracle.com> <8768AD30-240F-42FA-8D84-7179CD5681F9@oracle.com> <5DD1503F815BD14889DC81D28643E3A73D8DDCDE@sausexdag06.amd.com> Message-ID: <0F5FB1C6-920B-44E4-B648-041CF81CA95C@oracle.com> Hi Vasanth, The problems you are seeing are due to the and process inside the makefiles that try to replicate the steps performed by 'mx build' to create graal.jar. The intention is to be able to build and deploy GraalVM without needing to use mx (and thus install Python). This requirement has been relaxed and now graal.jar is only built via mx. I'm pushing a change now that removes the ant call in the make files (it's replaced by a call to mx). Once you pull this change, you'll need to ensure a 'python2.7' executable is on your path. This should (touch wood) be the end of build issues around JDK8 code. -Doug On Jun 18, 2013, at 5:50 PM, "Venkatachalam, Vasanth" wrote: > Hi Doug, > > We're still seeing this issue with the mx scripts attempting to build JDK8 packages when the configured JDK is JDK 7. Below is the verbose output from mx build. > > You can see it mentions it is excluding com.amd.sumatra from graal.jar, but then it tries to compile one of the classes in this package. > > Vasanth > > Excluding com.amd.sumatra from /home/tester/graalcloneinternal/graal/graal.jar (Java compliance level 1.8 required) > Creating /home/tester/graalcloneinternal/graal/jdk1.7.0_13/product from /home/tester/Downloads/jdk1.7.0_13 > Creating VM directory in JDK7: /home/tester/graalcloneinternal/graal/jdk1.7.0_13/product/jre/lib/amd64/graal > cd /home/tester/graalcloneinternal/graal/make; \ > make BUILD_FLAVOR=productgraal VM_TARGET=productgraal \ > generic_buildgraal > INFO: ENABLE_FULL_DEBUG_SYMBOLS=1 > > INFO: /usr/bin/objcopy cmd found so will create .debuginfo files. > > INFO: STRIP_POLICY=min_strip > > INFO: ZIP_DEBUGINFO_FILES=0 > > make[1]: Entering directory `/home/tester/graalcloneinternal/graal/make' > ANT_OPTS=-Djava.io.tmpdir='/home/tester/graalcloneinternal/graal/build/linux/tmp' JAVA_HOME='/home/tester/Downloads/jdk1.7.0_13' ant -f /home/tester/graalcloneinternal/graal/make/build-graal.xml -Dgamma.dir=/home/tester/graalcloneinternal/graal -Dshared.dir=/home/tester/graalcloneinternal/graal/build/linux/shared > Buildfile: /home/tester/graalcloneinternal/graal/make/build-graal.xml > > options: > > cleanclasses: > > compile: > [mkdir] Created dir: /home/tester/graalcloneinternal/graal/build/linux/shared/graal > [javac] Compiling 759 source files to /home/tester/graalcloneinternal/graal/build/linux/shared/graal > [javac] /home/tester/graalcloneinternal/graal/graal/com.amd.sumatra/src/com/amd/sumatra/ForEachToGraal.java:94: error: illegal start of expression > [javac] filter(p -> p.getName().equals("accept")).toArray(); > [javac] ^ > [javac] 1 error > > > -----Original Message----- > From: Doug Simon [mailto:doug.simon at oracle.com] > Sent: Monday, June 03, 2013 11:29 AM > To: Deneau, Tom > Cc: Venkatachalam, Vasanth; graal-dev at openjdk.java.net > Subject: Re: possible bug in mx/projects handling > > Ok, I see the problem. Pushing through a fix now. Here's the patch: > > diff -r 91a1041ec905 mxtool/mx.py > --- a/mxtool/mx.py Sat Jun 01 20:42:22 2013 -0400 > +++ b/mxtool/mx.py Mon Jun 03 18:07:59 2013 +0200 > @@ -1700,6 +1700,11 @@ > try: > zf = zipfile.ZipFile(tmp, 'w') > for p in sorted_deps(d.deps): > + # skip a Java project if its Java compliance level is "higher" than the configured JDK > + if java().javaCompliance < p.javaCompliance: > + log('Excluding {0} from {2} (Java compliance level {1} required)'.format(p.name, p.javaCompliance, d.path)) > + continue > + > outputDir = p.output_dir() > for root, _, files in os.walk(outputDir): > relpath = root[len(outputDir) + 1:] > > On Jun 3, 2013, at 5:31 PM, "Deneau, Tom" wrote: > >> Doug -- >> >> Did you also put your com.amd.sumatra as a dependency for graal.jar? That is where the problem seems to arise. >> >> distribution at GRAAL@path=graal.jar >> distribution at GRAAL@dependencies=com.oracle.graal.hotspot.amd64,com.ora >> cle.graal.hotspot.sparc,com.oracle.graal.hotspot,com.amd.sumatra >> >> -- Tom >> >> -----Original Message----- >> From: graal-dev-bounces at openjdk.java.net >> [mailto:graal-dev-bounces at openjdk.java.net] On Behalf Of Doug Simon >> Sent: Monday, June 03, 2013 9:02 AM >> To: Venkatachalam, Vasanth >> Cc: graal-dev at openjdk.java.net >> Subject: Re: possible bug in mx/projects handling >> >> >> On May 31, 2013, at 11:02 PM, "Venkatachalam, Vasanth" wrote: >> >>> Hi, >>> >>> We have a project com.amd.sumatra which requires java 1.8 compliance to build. >>> >>> We've added lines in mx/project to specify that the project shouldn't be built when building with a 1.7 JDK: >>> >>> distribution at GRAAL@path=graal.jar >>> distribution at GRAAL@dependencies=com.oracle.graal.hotspot.amd64,com.or >>> acle.graal.hotspot.sparc,com.oracle.graal.hotspot,com.amd.sumatra >>> >>> # com.amd.sumatra >>> project at com.amd.sumatra@subDir=graal >>> project at com.amd.sumatra@sourceDirs=src >>> project at com.amd.sumatra@dependencies=com.oracle.graal.hotspot,com.ora >>> cle.graal.hotspot.amd64,com.oracle.graal.hsail,com.oracle.graal.compi >>> ler.hsail,com.amd.okra >>> project at com.amd.sumatra@checkstyle=com.oracle.graal.graph >>> project at com.amd.sumatra@javaCompliance=1.8 >>> >>> When I do an mx build, I see the lines >>> >>> Excluding com.amd.sumatra fro build (Java compliance level 1.8 >>> required) >>> >>> But then Graal goes ahead and tries to build the package. This appears to be a bug. Can someone look into this? >> >> I tried to reproduce this by creating a local com.amd.sumatra project and used some JDK 1.8 API in it. However, 'mx build' does the expected thing in may case (i.e. does not try to compiled anything in com.amd.sumatra). Could you please send me the output of 'mx clean --no-native; mx -v build' so I can investigate further. >> >> -Doug >> > > > From doug.simon at oracle.com Tue Jun 18 12:33:06 2013 From: doug.simon at oracle.com (Doug Simon) Date: Tue, 18 Jun 2013 21:33:06 +0200 Subject: update on graal HSAIL backend webrev In-Reply-To: <5DD1503F815BD14889DC81D28643E3A73D8DDD0C@sausexdag06.amd.com> References: <5DD1503F815BD14889DC81D28643E3A73D8DDD0C@sausexdag06.amd.com> Message-ID: Hi Vasanth, Here's a proposal that should allow us to integrate your HSAIL backend changes and tests and avoids all licensing issues. As I understand it, the HSAIL tests depend on the OKRA framework. If you can make this framework available as a jar located at a publicly available URL, then you can simply specify it as a library dependency for the projects that need it (just like we specify the JUNIT library) in mx/projects. This way, the library will be pulled down and cached locally on demand for running the tests. In terms of the remaining code, we would like to receive and maintain the Graal HSAIL backend (plus tests) in the Graal repository which only contains JDK7 code and is only tested in a JDK7 environment. For the JDK8 changes, we propose that they remain in a Sumatra downstream repository. This would include the HotSpot code to do the optional interception on the Streams API. If this proposal is not acceptable, we're open to further discussion. If it is acceptable, could you please create a JDK7 compliant patch that has the Graal HSAIL backend, the tests for those changes and a dependency on OKRA as an external jar library. -Doug On Jun 18, 2013, at 6:27 PM, "Venkatachalam, Vasanth" wrote: > Hi, > > I wanted to give an update on our Graal webrev. > > We have fixed all of the Java warnings and most of the checkstyle errors. The only checkstyle errors that remain are coming from the license header used in two packages ( HSAIL simulator source) that currently require a University of Illinois license, as opposed to the Oracle license which checkstyle is expecting. We are internally discussing how to handle the licensing issue. > > I ran the three commands the Doug listed: > > mx clean > mx build --jdt /path/to/ecj.jar --jdt-warning-as-error > mx checkstyle > > Aside from the checkstyle warnings mentioned above, there were no issues. However, when using JDK7, mx still tries to build JDK 8 projects, even though their compliance level was specified as Java 8 in mx/projects. I reported this bug on the mailing list. > > I'd like to propose two possible ways we can submit the revised webrev, and get people's feedback on what's preferable. > > 1) The easiest approach would be to give you a single webrev encompassing all changes and provide you with adequate documentation that will allow you to be selective in what projects to review. > > 2) We can split this up into multiple webrevs. However, due to dependencies you will need to apply all the patches to be able to build. The four-way split I propose is as follows: > > A) Hotspot changes > > B) Graal changes > B1) Infrastructure changes > B2) Test cases > > Let me know what's preferable. If I don't hear from anyone I plan to produce 1) within the next couple of days. > > Vasanth > > > > /home/tester/graalcloneinternal/graal/graal/com.amd.okra/src/com/amd/okra/OkraKernel.java:2: Line does not match expected header line of ' \* Copyright \(c\) (20[0-9][0-9], )?20[0-9][0-9], Oracle and/or its affiliates. All rights reserved.'. > /home/tester/graalcloneinternal/graal/graal/com.amd.okra/src/com/amd/okra/OkraContext.java:2: Line does not match expected header line of ' \* Copyright \(c\) (20[0-9][0-9], )?20[0-9][0-9], Oracle and/or its affiliates. All rights reserved.'. > /home/tester/graalcloneinternal/graal/graal/com.amd.okra/src/com/amd/okra/OkraOpenCLtoHSAILCompiler.java:2: Line does not match expected header line of ' \* Copyright \(c\) (20[0-9][0-9], )?20[0-9][0-9], Oracle and/or its affiliates. All rights reserved.'. > /home/tester/graalcloneinternal/graal/graal/com.amd.okra/src/com/amd/okra/OkraUtil.java:2: Line does not match expected header line of ' \* Copyright \(c\) (20[0-9][0-9], )?20[0-9][0-9], Oracle and/or its affiliates. All rights reserved.'. > > > -----Original Message----- > From: Doug Simon [mailto:doug.simon at oracle.com] > Sent: Saturday, June 15, 2013 3:20 PM > To: Venkatachalam, Vasanth > Cc: graal-dev at openjdk.java.net > Subject: Re: webrev for Graal HSAIL backend > > Hi Vasanth, > > On Jun 14, 2013, at 10:34 PM, "Venkatachalam, Vasanth" wrote: > >> Hi Doug, >> >> Thanks for the feedback. We're addressing your comments and had a few questions. >> >> 1) I'm trying to understand the issue with the formatting. To apply the Eclipse formatter, I first ran mx ideinit, then started eclipse and under projects->properties->Java Code Style->Formatter, I made sure the profile (Unmanaged profile 'Graal') was selected. Is this the correct way to apply the formatter? > > Yes. The Eclipse project configurations created by eclipseinit should also apply the formatter to any Java file when it is saved. > >> Can you give an example of some code that wasn't formatted according to these rules? > > Now that I've looked at the patch in more detail, I can't see any problem in terms of formatting. > >> 2). The only projects that use JDK8 features are com.amd.sumatra, and com.oracle.graal.compiler.hsail.test.lambda, In mx/projects we have specified that these projects have Java compliance of 1.8, so they shouldn't be compiled if the JDK used is 1.7. It seems like there should be a way for Eclipse to pick up on these changes after running mx ideinit. Are you saying this isn't the case? > > One problem is that Eclipse doesn't (yet) support JDK8 *language* features such as lambdas. Projects that only use JDK8 library features should be fine. > > The ideinit command does not consider compliance level when generating Eclipse project configurations - it probably should. And it should probably ignore any projects whose compliance level is >= 8 altogether. Not only does Eclipse not yet support JDK8 anguage features, it cannot yet generate JDK8 class files (the maximum "Compiler compliance level" one can currently set in Eclipse is 1.7). > > I've just modified the checkstyle command to pay attention to compliance levels. With this change, you should now be able to test your changes for Graal compliance on the command line with these commands: > > mx clean > mx build --jdt /path/to/ecj.jar --jdt-warning-as-error mx checkstyle > > Once all 3 pass without any warnings or errors, the code should be easier to review and integrate. Note that these commands are part of our gate so we need to get them passing anyway. If you are game, you could try and replicate our complete gate testing with: > > mx --jacoco on gate > > BTW, if you download an ecj.jar[1] to /mx/ecj.jar, it will be automatically detected and used by the 'mx build' command, removing the need for the --jdt argument. > > Let me know if you run into any problems or have any further questions. > > -Doug > > [1] http://www.eclipse.org/downloads/download.php?file=/eclipse/downloads/drops4/R-4.2.2-201302041200/ecj-4.2.2.jar > >> -----Original Message----- >> From: graal-dev-bounces at openjdk.java.net >> [mailto:graal-dev-bounces at openjdk.java.net] On Behalf Of Doug Simon >> Sent: Thursday, June 13, 2013 9:04 AM >> To: Deneau, Tom >> Cc: sumatra-dev at openjdk.java.net; graal-dev at openjdk.java.net >> Subject: Re: webrev for Graal HSAIL backend >> >> Tom, >> >> It would really help to have this patch broken up into components that can be separately considered for integration. In particular (as Morris stated), having the HSAIL backend (and tests) in Graal would be great so a separate patch for this code would be a good first step. >> >> One immediate observation is that a lot of the code does not yet import into Eclipse very well. This is the primary tool we use for development and code comprehension so getting the code into Eclipse compliant form would be very helpful in terms of being able to efficiently assess a contribution and offer further feedback. This means: >> >> o Only use Java 7 language features (Eclipse does not yet support Java 8 language features and it's not clear when it will). >> o Remove all Checkstyle warnings (use the eclipse-cs plugin or 'mx checkstyle'). >> o Remove all Java warnings (which show up in the Eclipse Problems view). >> o Format Java code with the Eclipse formatter (the Eclipse projects generated by 'mx eclipseinit' will ensure the Graal code formatting rules are used). >> >> It would be useful to have a high level description of the code, broken down by package or collection of packages. This can either be plain text or (preferably) package-info.java files. >> >> I notice there are files without licenses and some with University of Illinois licenses (the Okra framework). I'm no expert on licensing, but this may causes integration issues. >> >> The HotSpot changes are probably best to keep in the Sumatra repository for now given their experimental nature. >> >> I look forward to further progress in terms of getting Sumatra code into Graal - thanks for a good start! >> >> -Doug >> >> On Jun 12, 2013, at 5:59 PM, "Deneau, Tom" wrote: >> >>> Morris -- >>> >>> Regarding your comments on the hotspot changes in this webrev >>> http://cr.openjdk.java.net/~ecaspole/graal_hsail/ >>> I wanted to let you know that these hotspot changes really don't make >>> sense on their own but co-operate with some JDK changes which we will >>> be submitting in a separate webrev to the Sumatra-dev repository >>> early next week (these JDK changes are much smaller than the graal changes). >>> >>> Here is a brief overview of how the pieces fit together... >>> >>> Basically we wanted the GPU offload programming model to be triggered >>> by the programmer using Stream.parallel.forEach(). So the JDK changes >>> are really just interceptions of the stream API for parallel forEach. >>> The intercept code tests whether the stream meets a few criteria to >>> be offloadable, and if so tell graal (thru the Sumatra interface) to >>> compile the lambda method to HSAIL and dispatch it. If already >>> compiled, it will just be dispatched. Currently we have a property, >>> off by default, which tells the JDK intercept code to offload >>> immediately. If the offload-immediate flag is set, no hotspot >>> changes are really needed. >>> >>> The hotspot changes just provide an alternate way of enabling the >>> offloading (without using the offload-immediate flag) by using the >>> compilation of the underlying lambda method as a trigger for >>> offloading. They are very experimental and we would welcome >>> community input on other ways to do this. >>> >>> Hope this helps... >>> >>> -- Tom Deneau >>> >>> >>> >>> -----Original Message----- >>> From: graal-dev-bounces at openjdk.java.net >>> [mailto:graal-dev-bounces at openjdk.java.net] On Behalf Of Morris Meyer >>> Sent: Tuesday, June 11, 2013 7:17 PM >>> To: graal-dev at openjdk.java.net >>> Subject: Re: webrev for Graal HSAIL backend >>> >>> Vasanth, >>> >>> After seeing Apple's WWDC and the 4,000 core dual-GPU system they >>> built into the Mac Pro, I'm very happy to see the work your team has >>> put together. Lots of good stuff here and I think we should take most of it. >>> >>> I like that the HSAIL backend is in the com.oracle.graal namespace - >>> not so much as an Oracle engineer - but it will make working and >>> refactoring these GPU and CPU backends much easier. Thanks. >>> >>> compilerBroker.cpp, library_call.cpp, runtime.cpp and arguments.cpp seem >>> like the might be a little specialized for this point in time. Very >>> interesting changes though. I would like to get the heterogeneous >>> method support into HotSpot / Graal and sit down at the language >>> summit and discuss how we take on constructs like the ForEach work. >>> >>> I think com.amd.sumatra.Sumatra is sort of in the right ballpark - it >>> echos the change I made to CompilerToGPU in the earlier PTX work. I >>> would like of like to reserve the sumatra package for lambda work >>> along the lines you are thinking for a collections / lambda oriented >>> java.lang.invoke set of code. We need to get the requirements for this >>> sort of externalized kernel creating defined as soon as we can. >>> Maybe ...bridge.gpu, ...bridge.gpu.hsail, ...bridge.gpu.ptx packages >>> in the graal namespace? >>> >>> I think it might be a good next step to put in the HSAIL back end and >>> tests and the emulator working at the gate so we can build and verify >>> JDK9 / Sumatra / Graal changes in this environment going forward. >>> >>> I will be working as time permits on the heterogeneous methods and >>> PTX invocation so we can get both platforms at the gate integrating changes. >>> >>> That's all for now. I'm looking forward to working my way through >>> all these unit tests. Huge kudos AMD! >>> >>> --morris meyer >>> >>> On 6/11/13 6:16 PM, Venkatachalam, Vasanth wrote: >>>> Hi, >>>> >>>> The AMD Sumatra team has submitted a webrev (http://cr.openjdk.java.net/~ecaspole/graal_hsail/) that adds HSAIL code generation support for Graal, allowing Java programs to be compiled and executed on HSAIL-enabled GPU/APU devices. While this work is a prototype, we have included several working unit test cases, including Mandelbrot and NBody. >>>> >>>> Features >>>> >>>> Arithmetic operations for integers, longs, doubles, and floats >>>> Loads, stores and move operations Min/max/rem/carry operations for >>>> integers and longs Conversion operations - (currently support >>>> conversions between integers and floats, integers and doubles, integers and longs, floats and doubles). >>>> Some math library operations (e.g., square root). >>>> Support for JDK8 lambda constructs. >>>> >>>> Known Issues >>>> >>>> -The logic to handle register spilling is work-in-progress, so not all test cases that induce spilling are guaranteed to work. >>>> -X86 register encodings are being passed to the HSAIL backend. The >>>> calling convention returned by getCallingConvention() currently returns an x86 calling convention -Function call support has yet to be implemented. >>>> >>>> For a detailed list of unsupported features, refer to the routines >>>> that are emitting "NYI" in HSAILLIRGenerator.java >>>> >>>> The test cases (except for BasicHSAILTest) require an HSAIL simulator or hardware to execute, but in lieu of a simulator or hardware they will output the HSAIL code generated, which is useful for debugging. Moreover, BasicHSAILTest provides a template for adding Java code snippets and viewing the HSAIL generated code without executing the code. >>>> >>>> We encourage the community to support this new backend and extend it with additional features. >>>> >>>> Vasanth >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>> >>> >>> >> >> >> > > > From doug.simon at oracle.com Tue Jun 18 12:34:37 2013 From: doug.simon at oracle.com (doug.simon at oracle.com) Date: Tue, 18 Jun 2013 19:34:37 +0000 Subject: hg: graal/graal: 24 new changesets Message-ID: <20130618193607.4F889482CC@hg.openjdk.java.net> Changeset: b6dfe12478ff Author: Michael Haupt Date: 2013-06-17 08:30 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/b6dfe12478ff [GRAAL-308] pre-defined working sets for Eclipse ! mx/projects ! mxtool/mx.py Changeset: 56fc40ca4ae0 Author: Bernhard Urban Date: 2013-06-16 23:55 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/56fc40ca4ae0 HotSpotResolvedJavaField: don't embed caches of java.lang.{Integer,Long,Boolean} for replacements when compiled in AOT mode (GRAAL-290) ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotResolvedJavaField.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/phases/AheadOfTimeVerifcationPhase.java Changeset: 9e688291fc53 Author: Bernhard Urban Date: 2013-06-16 23:55 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/9e688291fc53 HotSpotResolvedJavaField: don't embed object for empty stack trace for replacements when compiled in AOT mode (GRAAL-290) ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotResolvedJavaField.java Changeset: 5749b583efe1 Author: Bernhard Urban Date: 2013-06-16 23:55 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/5749b583efe1 BoxingSnippets: don't embed constants if in AOT mode (GRAAL-290) ! graal/com.oracle.graal.replacements/src/com/oracle/graal/replacements/BoxingSnippets.java Changeset: 5ba3763d6986 Author: Bernhard Urban Date: 2013-06-16 23:55 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/5ba3763d6986 HotSpotResolvedJavaField: check if method is called from snippet/replacements (GRAAL-290) ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotResolvedJavaField.java Changeset: 295ef03139f4 Author: Bernhard Urban Date: 2013-06-16 23:55 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/295ef03139f4 HotSpotResolvedJavaField: be more precise about fields that are not embeddable (GRAAL-290) ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotResolvedJavaField.java Changeset: 0d378ea2b822 Author: Bernhard Urban Date: 2013-06-17 09:48 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/0d378ea2b822 gate: enable verification for aot ! mx/commands.py Changeset: 529570e20aff Author: Gilles Duboscq Date: 2013-06-17 14:53 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/529570e20aff Ignore workingsets.xml ! .hgignore Changeset: abb9d3a26025 Author: Doug Simon Date: 2013-06-17 17:55 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/abb9d3a26025 an instanceof instruction lowers to a deoptimize-on-hint-miss snippet only if its profile indicates a miss (of a hint type) occurs an order of magnitude less than the compilation threshold ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/HotSpotVMConfig.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/InstanceOfSnippets.java ! graal/com.oracle.graal.phases/src/com/oracle/graal/phases/GraalOptions.java ! src/share/vm/graal/graalCompilerToVM.cpp Changeset: a555af792411 Author: Christos Kotselidis Date: 2013-06-17 20:38 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/a555af792411 Remove old G1 Barrier nodes - graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/nodes/WriteBarrierPost.java - graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/nodes/WriteBarrierPre.java Changeset: 4071b48fc4ed Author: Christos Kotselidis Date: 2013-06-17 20:39 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/4071b48fc4ed Remove old G1 stub calls - graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/nodes/WriteBarrierPostStubCall.java - graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/nodes/WriteBarrierPreStubCall.java Changeset: 62ea8789b88a Author: Christos Kotselidis Date: 2013-06-17 20:39 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/62ea8789b88a Remove leaf calls for G1 calls ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotRuntime.java ! src/share/vm/graal/graalCompilerToVM.cpp ! src/share/vm/graal/graalRuntime.cpp ! src/share/vm/graal/graalRuntime.hpp Changeset: 1397c3e1f642 Author: Bernhard Urban Date: 2013-06-17 17:07 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/1397c3e1f642 HotSpotResolvedJavaField: add cache of java.lang.{Character,Byte,Short} to not embeddable list (GRAAL-290) running dacapo in AOT mode + verification revealed some more possible usages of cached boxed values (Character + Short). For completness I also added j.l.Byte. ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotResolvedJavaField.java Changeset: e8fbc5fd3440 Author: Bernhard Urban Date: 2013-06-17 17:50 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/e8fbc5fd3440 aot: add/fix some javadoc ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotResolvedJavaField.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/phases/AheadOfTimeVerifcationPhase.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/phases/LoadJavaMirrorWithKlassPhase.java ! graal/com.oracle.graal.replacements/src/com/oracle/graal/replacements/BoxingSnippets.java Changeset: c0e9ae41ed17 Author: Bernhard Urban Date: 2013-06-17 22:09 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/c0e9ae41ed17 unittest/aot: add testcase for BoxingSnippets ! graal/com.oracle.graal.hotspot.test/src/com/oracle/graal/hotspot/test/AheadOfTimeCompilationTest.java Changeset: 25de9c96a032 Author: Christian Haeubl Date: 2013-06-18 09:00 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/25de9c96a032 Minor CompilationTask refactoring. ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/CompilationTask.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/bridge/VMToCompilerImpl.java Changeset: 9c4e6767ab78 Author: Bernhard Urban Date: 2013-06-18 09:32 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/9c4e6767ab78 Value/Register: replace object identity check with equals() ! graal/com.oracle.graal.compiler.sparc/src/com/oracle/graal/compiler/sparc/SPARCLIRGenerator.java ! graal/com.oracle.graal.lir.amd64/src/com/oracle/graal/lir/amd64/AMD64Move.java Changeset: 7bcc4bf839fe Author: Christian Haeubl Date: 2013-06-18 10:43 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/7bcc4bf839fe Bugfix for compilation queue. ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/CompilationTask.java Changeset: 77772d794ffd Author: Christian Haeubl Date: 2013-06-18 11:01 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/77772d794ffd Merge. Changeset: e04f128d719c Author: Doug Simon Date: 2013-06-18 12:46 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/e04f128d719c cannot use DeoptimizationAction.None for deoptimizing instanceof snippet since it will miss application phase changes, causing repeated and expensive deoptimization ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/InstanceOfSnippets.java Changeset: 20fd8760cb34 Author: Lukas Stadler Date: 2013-06-18 16:38 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/20fd8760cb34 pull ScheduledNodeIterator into separate class ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/GuardLoweringPhase.java + graal/com.oracle.graal.phases/src/com/oracle/graal/phases/graph/ScheduledNodeIterator.java Changeset: 665e95c28965 Author: Lukas Stadler Date: 2013-06-18 16:39 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/665e95c28965 DynamicCounterNode: counter without lowering, output tweaks ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/debug/DynamicCounterNode.java ! graal/com.oracle.graal.virtual/src/com/oracle/graal/virtual/phases/ea/GraphEffectList.java Changeset: 8dc4cdde75fb Author: Doug Simon Date: 2013-06-18 18:17 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/8dc4cdde75fb remove build-graal.xml and have make directly call mx to generate graal.jar ! make/Makefile - make/build-graal.xml ! mx/commands.py Changeset: dcc1994e523e Author: Doug Simon Date: 2013-06-18 18:35 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/dcc1994e523e hard code use of python2.7 executable ! make/Makefile From Vasanth.Venkatachalam at amd.com Tue Jun 18 13:35:56 2013 From: Vasanth.Venkatachalam at amd.com (Venkatachalam, Vasanth) Date: Tue, 18 Jun 2013 20:35:56 +0000 Subject: update on graal HSAIL backend webrev Message-ID: <5DD1503F815BD14889DC81D28643E3A73D90648F@sausexdag06.amd.com> Hi Doug, We had discussions with Donald Smith regarding the licensing issue. Based on his feedback, the University of Illinois license which the Okra framework uses is OpenJDK friendly. One advantage of including the simulator sources is that it makes the code self-contained, whereas if the jar had to be downloaded separately, it could get updated in a way that breaks the build. We wanted to find the easiest way to keep the code self-contained and ensure that all the licenses are OpenJDK compatible. We've decided not to check-in any JDK8-dependent changes until Graal becomes JDK8 compatible. Till then we'll test these changes locally. We're working on reverting these changes now. Vasanth -----Original Message----- From: Doug Simon [mailto:doug.simon at oracle.com] Sent: Tuesday, June 18, 2013 2:33 PM To: Venkatachalam, Vasanth Cc: graal-dev at openjdk.java.net Subject: Re: update on graal HSAIL backend webrev Hi Vasanth, Here's a proposal that should allow us to integrate your HSAIL backend changes and tests and avoids all licensing issues. As I understand it, the HSAIL tests depend on the OKRA framework. If you can make this framework available as a jar located at a publicly available URL, then you can simply specify it as a library dependency for the projects that need it (just like we specify the JUNIT library) in mx/projects. This way, the library will be pulled down and cached locally on demand for running the tests. In terms of the remaining code, we would like to receive and maintain the Graal HSAIL backend (plus tests) in the Graal repository which only contains JDK7 code and is only tested in a JDK7 environment. For the JDK8 changes, we propose that they remain in a Sumatra downstream repository. This would include the HotSpot code to do the optional interception on the Streams API. If this proposal is not acceptable, we're open to further discussion. If it is acceptable, could you please create a JDK7 compliant patch that has the Graal HSAIL backend, the tests for those changes and a dependency on OKRA as an external jar library. -Doug On Jun 18, 2013, at 6:27 PM, "Venkatachalam, Vasanth" wrote: > Hi, > > I wanted to give an update on our Graal webrev. > > We have fixed all of the Java warnings and most of the checkstyle errors. The only checkstyle errors that remain are coming from the license header used in two packages ( HSAIL simulator source) that currently require a University of Illinois license, as opposed to the Oracle license which checkstyle is expecting. We are internally discussing how to handle the licensing issue. > > I ran the three commands the Doug listed: > > mx clean > mx build --jdt /path/to/ecj.jar --jdt-warning-as-error mx checkstyle > > Aside from the checkstyle warnings mentioned above, there were no issues. However, when using JDK7, mx still tries to build JDK 8 projects, even though their compliance level was specified as Java 8 in mx/projects. I reported this bug on the mailing list. > > I'd like to propose two possible ways we can submit the revised webrev, and get people's feedback on what's preferable. > > 1) The easiest approach would be to give you a single webrev encompassing all changes and provide you with adequate documentation that will allow you to be selective in what projects to review. > > 2) We can split this up into multiple webrevs. However, due to dependencies you will need to apply all the patches to be able to build. The four-way split I propose is as follows: > > A) Hotspot changes > > B) Graal changes > B1) Infrastructure changes > B2) Test cases > > Let me know what's preferable. If I don't hear from anyone I plan to produce 1) within the next couple of days. > > Vasanth > > > > /home/tester/graalcloneinternal/graal/graal/com.amd.okra/src/com/amd/okra/OkraKernel.java:2: Line does not match expected header line of ' \* Copyright \(c\) (20[0-9][0-9], )?20[0-9][0-9], Oracle and/or its affiliates. All rights reserved.'. > /home/tester/graalcloneinternal/graal/graal/com.amd.okra/src/com/amd/okra/OkraContext.java:2: Line does not match expected header line of ' \* Copyright \(c\) (20[0-9][0-9], )?20[0-9][0-9], Oracle and/or its affiliates. All rights reserved.'. > /home/tester/graalcloneinternal/graal/graal/com.amd.okra/src/com/amd/okra/OkraOpenCLtoHSAILCompiler.java:2: Line does not match expected header line of ' \* Copyright \(c\) (20[0-9][0-9], )?20[0-9][0-9], Oracle and/or its affiliates. All rights reserved.'. > /home/tester/graalcloneinternal/graal/graal/com.amd.okra/src/com/amd/okra/OkraUtil.java:2: Line does not match expected header line of ' \* Copyright \(c\) (20[0-9][0-9], )?20[0-9][0-9], Oracle and/or its affiliates. All rights reserved.'. > > > -----Original Message----- > From: Doug Simon [mailto:doug.simon at oracle.com] > Sent: Saturday, June 15, 2013 3:20 PM > To: Venkatachalam, Vasanth > Cc: graal-dev at openjdk.java.net > Subject: Re: webrev for Graal HSAIL backend > > Hi Vasanth, > > On Jun 14, 2013, at 10:34 PM, "Venkatachalam, Vasanth" wrote: > >> Hi Doug, >> >> Thanks for the feedback. We're addressing your comments and had a few questions. >> >> 1) I'm trying to understand the issue with the formatting. To apply the Eclipse formatter, I first ran mx ideinit, then started eclipse and under projects->properties->Java Code Style->Formatter, I made sure the profile (Unmanaged profile 'Graal') was selected. Is this the correct way to apply the formatter? > > Yes. The Eclipse project configurations created by eclipseinit should also apply the formatter to any Java file when it is saved. > >> Can you give an example of some code that wasn't formatted according to these rules? > > Now that I've looked at the patch in more detail, I can't see any problem in terms of formatting. > >> 2). The only projects that use JDK8 features are com.amd.sumatra, and com.oracle.graal.compiler.hsail.test.lambda, In mx/projects we have specified that these projects have Java compliance of 1.8, so they shouldn't be compiled if the JDK used is 1.7. It seems like there should be a way for Eclipse to pick up on these changes after running mx ideinit. Are you saying this isn't the case? > > One problem is that Eclipse doesn't (yet) support JDK8 *language* features such as lambdas. Projects that only use JDK8 library features should be fine. > > The ideinit command does not consider compliance level when generating Eclipse project configurations - it probably should. And it should probably ignore any projects whose compliance level is >= 8 altogether. Not only does Eclipse not yet support JDK8 anguage features, it cannot yet generate JDK8 class files (the maximum "Compiler compliance level" one can currently set in Eclipse is 1.7). > > I've just modified the checkstyle command to pay attention to compliance levels. With this change, you should now be able to test your changes for Graal compliance on the command line with these commands: > > mx clean > mx build --jdt /path/to/ecj.jar --jdt-warning-as-error mx checkstyle > > Once all 3 pass without any warnings or errors, the code should be easier to review and integrate. Note that these commands are part of our gate so we need to get them passing anyway. If you are game, you could try and replicate our complete gate testing with: > > mx --jacoco on gate > > BTW, if you download an ecj.jar[1] to /mx/ecj.jar, it will be automatically detected and used by the 'mx build' command, removing the need for the --jdt argument. > > Let me know if you run into any problems or have any further questions. > > -Doug > > [1] > http://www.eclipse.org/downloads/download.php?file=/eclipse/downloads/ > drops4/R-4.2.2-201302041200/ecj-4.2.2.jar > >> -----Original Message----- >> From: graal-dev-bounces at openjdk.java.net >> [mailto:graal-dev-bounces at openjdk.java.net] On Behalf Of Doug Simon >> Sent: Thursday, June 13, 2013 9:04 AM >> To: Deneau, Tom >> Cc: sumatra-dev at openjdk.java.net; graal-dev at openjdk.java.net >> Subject: Re: webrev for Graal HSAIL backend >> >> Tom, >> >> It would really help to have this patch broken up into components that can be separately considered for integration. In particular (as Morris stated), having the HSAIL backend (and tests) in Graal would be great so a separate patch for this code would be a good first step. >> >> One immediate observation is that a lot of the code does not yet import into Eclipse very well. This is the primary tool we use for development and code comprehension so getting the code into Eclipse compliant form would be very helpful in terms of being able to efficiently assess a contribution and offer further feedback. This means: >> >> o Only use Java 7 language features (Eclipse does not yet support Java 8 language features and it's not clear when it will). >> o Remove all Checkstyle warnings (use the eclipse-cs plugin or 'mx checkstyle'). >> o Remove all Java warnings (which show up in the Eclipse Problems view). >> o Format Java code with the Eclipse formatter (the Eclipse projects generated by 'mx eclipseinit' will ensure the Graal code formatting rules are used). >> >> It would be useful to have a high level description of the code, broken down by package or collection of packages. This can either be plain text or (preferably) package-info.java files. >> >> I notice there are files without licenses and some with University of Illinois licenses (the Okra framework). I'm no expert on licensing, but this may causes integration issues. >> >> The HotSpot changes are probably best to keep in the Sumatra repository for now given their experimental nature. >> >> I look forward to further progress in terms of getting Sumatra code into Graal - thanks for a good start! >> >> -Doug >> >> On Jun 12, 2013, at 5:59 PM, "Deneau, Tom" wrote: >> >>> Morris -- >>> >>> Regarding your comments on the hotspot changes in this webrev >>> http://cr.openjdk.java.net/~ecaspole/graal_hsail/ >>> I wanted to let you know that these hotspot changes really don't >>> make sense on their own but co-operate with some JDK changes which >>> we will be submitting in a separate webrev to the Sumatra-dev >>> repository early next week (these JDK changes are much smaller than the graal changes). >>> >>> Here is a brief overview of how the pieces fit together... >>> >>> Basically we wanted the GPU offload programming model to be >>> triggered by the programmer using Stream.parallel.forEach(). So the >>> JDK changes are really just interceptions of the stream API for parallel forEach. >>> The intercept code tests whether the stream meets a few criteria to >>> be offloadable, and if so tell graal (thru the Sumatra interface) to >>> compile the lambda method to HSAIL and dispatch it. If already >>> compiled, it will just be dispatched. Currently we have a property, >>> off by default, which tells the JDK intercept code to offload >>> immediately. If the offload-immediate flag is set, no hotspot >>> changes are really needed. >>> >>> The hotspot changes just provide an alternate way of enabling the >>> offloading (without using the offload-immediate flag) by using the >>> compilation of the underlying lambda method as a trigger for >>> offloading. They are very experimental and we would welcome >>> community input on other ways to do this. >>> >>> Hope this helps... >>> >>> -- Tom Deneau >>> >>> >>> >>> -----Original Message----- >>> From: graal-dev-bounces at openjdk.java.net >>> [mailto:graal-dev-bounces at openjdk.java.net] On Behalf Of Morris >>> Meyer >>> Sent: Tuesday, June 11, 2013 7:17 PM >>> To: graal-dev at openjdk.java.net >>> Subject: Re: webrev for Graal HSAIL backend >>> >>> Vasanth, >>> >>> After seeing Apple's WWDC and the 4,000 core dual-GPU system they >>> built into the Mac Pro, I'm very happy to see the work your team has >>> put together. Lots of good stuff here and I think we should take most of it. >>> >>> I like that the HSAIL backend is in the com.oracle.graal namespace - >>> not so much as an Oracle engineer - but it will make working and >>> refactoring these GPU and CPU backends much easier. Thanks. >>> >>> compilerBroker.cpp, library_call.cpp, runtime.cpp and arguments.cpp seem >>> like the might be a little specialized for this point in time. Very >>> interesting changes though. I would like to get the heterogeneous >>> method support into HotSpot / Graal and sit down at the language >>> summit and discuss how we take on constructs like the ForEach work. >>> >>> I think com.amd.sumatra.Sumatra is sort of in the right ballpark - >>> it echos the change I made to CompilerToGPU in the earlier PTX work. >>> I would like of like to reserve the sumatra package for lambda work >>> along the lines you are thinking for a collections / lambda oriented >>> java.lang.invoke set of code. We need to get the requirements for this >>> sort of externalized kernel creating defined as soon as we can. >>> Maybe ...bridge.gpu, ...bridge.gpu.hsail, ...bridge.gpu.ptx packages >>> in the graal namespace? >>> >>> I think it might be a good next step to put in the HSAIL back end >>> and tests and the emulator working at the gate so we can build and >>> verify >>> JDK9 / Sumatra / Graal changes in this environment going forward. >>> >>> I will be working as time permits on the heterogeneous methods and >>> PTX invocation so we can get both platforms at the gate integrating changes. >>> >>> That's all for now. I'm looking forward to working my way through >>> all these unit tests. Huge kudos AMD! >>> >>> --morris meyer >>> >>> On 6/11/13 6:16 PM, Venkatachalam, Vasanth wrote: >>>> Hi, >>>> >>>> The AMD Sumatra team has submitted a webrev (http://cr.openjdk.java.net/~ecaspole/graal_hsail/) that adds HSAIL code generation support for Graal, allowing Java programs to be compiled and executed on HSAIL-enabled GPU/APU devices. While this work is a prototype, we have included several working unit test cases, including Mandelbrot and NBody. >>>> >>>> Features >>>> >>>> Arithmetic operations for integers, longs, doubles, and floats >>>> Loads, stores and move operations Min/max/rem/carry operations for >>>> integers and longs Conversion operations - (currently support >>>> conversions between integers and floats, integers and doubles, integers and longs, floats and doubles). >>>> Some math library operations (e.g., square root). >>>> Support for JDK8 lambda constructs. >>>> >>>> Known Issues >>>> >>>> -The logic to handle register spilling is work-in-progress, so not all test cases that induce spilling are guaranteed to work. >>>> -X86 register encodings are being passed to the HSAIL backend. The >>>> calling convention returned by getCallingConvention() currently returns an x86 calling convention -Function call support has yet to be implemented. >>>> >>>> For a detailed list of unsupported features, refer to the routines >>>> that are emitting "NYI" in HSAILLIRGenerator.java >>>> >>>> The test cases (except for BasicHSAILTest) require an HSAIL simulator or hardware to execute, but in lieu of a simulator or hardware they will output the HSAIL code generated, which is useful for debugging. Moreover, BasicHSAILTest provides a template for adding Java code snippets and viewing the HSAIL generated code without executing the code. >>>> >>>> We encourage the community to support this new backend and extend it with additional features. >>>> >>>> Vasanth >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>> >>> >>> >> >> >> > > > From tom.deneau at amd.com Tue Jun 18 13:42:13 2013 From: tom.deneau at amd.com (Deneau, Tom) Date: Tue, 18 Jun 2013 20:42:13 +0000 Subject: update on graal HSAIL backend webrev In-Reply-To: References: <5DD1503F815BD14889DC81D28643E3A73D8DDD0C@sausexdag06.amd.com> Message-ID: Hi Doug -- We have some things we would like to log to stdout to help with debugging. What is the standard graal way to do this logging? -- Tom Deneau -----Original Message----- From: graal-dev-bounces at openjdk.java.net [mailto:graal-dev-bounces at openjdk.java.net] On Behalf Of Doug Simon Sent: Tuesday, June 18, 2013 2:33 PM To: Venkatachalam, Vasanth Cc: graal-dev at openjdk.java.net Subject: Re: update on graal HSAIL backend webrev Hi Vasanth, Here's a proposal that should allow us to integrate your HSAIL backend changes and tests and avoids all licensing issues. As I understand it, the HSAIL tests depend on the OKRA framework. If you can make this framework available as a jar located at a publicly available URL, then you can simply specify it as a library dependency for the projects that need it (just like we specify the JUNIT library) in mx/projects. This way, the library will be pulled down and cached locally on demand for running the tests. In terms of the remaining code, we would like to receive and maintain the Graal HSAIL backend (plus tests) in the Graal repository which only contains JDK7 code and is only tested in a JDK7 environment. For the JDK8 changes, we propose that they remain in a Sumatra downstream repository. This would include the HotSpot code to do the optional interception on the Streams API. If this proposal is not acceptable, we're open to further discussion. If it is acceptable, could you please create a JDK7 compliant patch that has the Graal HSAIL backend, the tests for those changes and a dependency on OKRA as an external jar library. -Doug On Jun 18, 2013, at 6:27 PM, "Venkatachalam, Vasanth" wrote: > Hi, > > I wanted to give an update on our Graal webrev. > > We have fixed all of the Java warnings and most of the checkstyle errors. The only checkstyle errors that remain are coming from the license header used in two packages ( HSAIL simulator source) that currently require a University of Illinois license, as opposed to the Oracle license which checkstyle is expecting. We are internally discussing how to handle the licensing issue. > > I ran the three commands the Doug listed: > > mx clean > mx build --jdt /path/to/ecj.jar --jdt-warning-as-error > mx checkstyle > > Aside from the checkstyle warnings mentioned above, there were no issues. However, when using JDK7, mx still tries to build JDK 8 projects, even though their compliance level was specified as Java 8 in mx/projects. I reported this bug on the mailing list. > > I'd like to propose two possible ways we can submit the revised webrev, and get people's feedback on what's preferable. > > 1) The easiest approach would be to give you a single webrev encompassing all changes and provide you with adequate documentation that will allow you to be selective in what projects to review. > > 2) We can split this up into multiple webrevs. However, due to dependencies you will need to apply all the patches to be able to build. The four-way split I propose is as follows: > > A) Hotspot changes > > B) Graal changes > B1) Infrastructure changes > B2) Test cases > > Let me know what's preferable. If I don't hear from anyone I plan to produce 1) within the next couple of days. > > Vasanth > > > > /home/tester/graalcloneinternal/graal/graal/com.amd.okra/src/com/amd/okra/OkraKernel.java:2: Line does not match expected header line of ' \* Copyright \(c\) (20[0-9][0-9], )?20[0-9][0-9], Oracle and/or its affiliates. All rights reserved.'. > /home/tester/graalcloneinternal/graal/graal/com.amd.okra/src/com/amd/okra/OkraContext.java:2: Line does not match expected header line of ' \* Copyright \(c\) (20[0-9][0-9], )?20[0-9][0-9], Oracle and/or its affiliates. All rights reserved.'. > /home/tester/graalcloneinternal/graal/graal/com.amd.okra/src/com/amd/okra/OkraOpenCLtoHSAILCompiler.java:2: Line does not match expected header line of ' \* Copyright \(c\) (20[0-9][0-9], )?20[0-9][0-9], Oracle and/or its affiliates. All rights reserved.'. > /home/tester/graalcloneinternal/graal/graal/com.amd.okra/src/com/amd/okra/OkraUtil.java:2: Line does not match expected header line of ' \* Copyright \(c\) (20[0-9][0-9], )?20[0-9][0-9], Oracle and/or its affiliates. All rights reserved.'. > > > -----Original Message----- > From: Doug Simon [mailto:doug.simon at oracle.com] > Sent: Saturday, June 15, 2013 3:20 PM > To: Venkatachalam, Vasanth > Cc: graal-dev at openjdk.java.net > Subject: Re: webrev for Graal HSAIL backend > > Hi Vasanth, > > On Jun 14, 2013, at 10:34 PM, "Venkatachalam, Vasanth" wrote: > >> Hi Doug, >> >> Thanks for the feedback. We're addressing your comments and had a few questions. >> >> 1) I'm trying to understand the issue with the formatting. To apply the Eclipse formatter, I first ran mx ideinit, then started eclipse and under projects->properties->Java Code Style->Formatter, I made sure the profile (Unmanaged profile 'Graal') was selected. Is this the correct way to apply the formatter? > > Yes. The Eclipse project configurations created by eclipseinit should also apply the formatter to any Java file when it is saved. > >> Can you give an example of some code that wasn't formatted according to these rules? > > Now that I've looked at the patch in more detail, I can't see any problem in terms of formatting. > >> 2). The only projects that use JDK8 features are com.amd.sumatra, and com.oracle.graal.compiler.hsail.test.lambda, In mx/projects we have specified that these projects have Java compliance of 1.8, so they shouldn't be compiled if the JDK used is 1.7. It seems like there should be a way for Eclipse to pick up on these changes after running mx ideinit. Are you saying this isn't the case? > > One problem is that Eclipse doesn't (yet) support JDK8 *language* features such as lambdas. Projects that only use JDK8 library features should be fine. > > The ideinit command does not consider compliance level when generating Eclipse project configurations - it probably should. And it should probably ignore any projects whose compliance level is >= 8 altogether. Not only does Eclipse not yet support JDK8 anguage features, it cannot yet generate JDK8 class files (the maximum "Compiler compliance level" one can currently set in Eclipse is 1.7). > > I've just modified the checkstyle command to pay attention to compliance levels. With this change, you should now be able to test your changes for Graal compliance on the command line with these commands: > > mx clean > mx build --jdt /path/to/ecj.jar --jdt-warning-as-error mx checkstyle > > Once all 3 pass without any warnings or errors, the code should be easier to review and integrate. Note that these commands are part of our gate so we need to get them passing anyway. If you are game, you could try and replicate our complete gate testing with: > > mx --jacoco on gate > > BTW, if you download an ecj.jar[1] to /mx/ecj.jar, it will be automatically detected and used by the 'mx build' command, removing the need for the --jdt argument. > > Let me know if you run into any problems or have any further questions. > > -Doug > > [1] http://www.eclipse.org/downloads/download.php?file=/eclipse/downloads/drops4/R-4.2.2-201302041200/ecj-4.2.2.jar > >> -----Original Message----- >> From: graal-dev-bounces at openjdk.java.net >> [mailto:graal-dev-bounces at openjdk.java.net] On Behalf Of Doug Simon >> Sent: Thursday, June 13, 2013 9:04 AM >> To: Deneau, Tom >> Cc: sumatra-dev at openjdk.java.net; graal-dev at openjdk.java.net >> Subject: Re: webrev for Graal HSAIL backend >> >> Tom, >> >> It would really help to have this patch broken up into components that can be separately considered for integration. In particular (as Morris stated), having the HSAIL backend (and tests) in Graal would be great so a separate patch for this code would be a good first step. >> >> One immediate observation is that a lot of the code does not yet import into Eclipse very well. This is the primary tool we use for development and code comprehension so getting the code into Eclipse compliant form would be very helpful in terms of being able to efficiently assess a contribution and offer further feedback. This means: >> >> o Only use Java 7 language features (Eclipse does not yet support Java 8 language features and it's not clear when it will). >> o Remove all Checkstyle warnings (use the eclipse-cs plugin or 'mx checkstyle'). >> o Remove all Java warnings (which show up in the Eclipse Problems view). >> o Format Java code with the Eclipse formatter (the Eclipse projects generated by 'mx eclipseinit' will ensure the Graal code formatting rules are used). >> >> It would be useful to have a high level description of the code, broken down by package or collection of packages. This can either be plain text or (preferably) package-info.java files. >> >> I notice there are files without licenses and some with University of Illinois licenses (the Okra framework). I'm no expert on licensing, but this may causes integration issues. >> >> The HotSpot changes are probably best to keep in the Sumatra repository for now given their experimental nature. >> >> I look forward to further progress in terms of getting Sumatra code into Graal - thanks for a good start! >> >> -Doug >> >> On Jun 12, 2013, at 5:59 PM, "Deneau, Tom" wrote: >> >>> Morris -- >>> >>> Regarding your comments on the hotspot changes in this webrev >>> http://cr.openjdk.java.net/~ecaspole/graal_hsail/ >>> I wanted to let you know that these hotspot changes really don't make >>> sense on their own but co-operate with some JDK changes which we will >>> be submitting in a separate webrev to the Sumatra-dev repository >>> early next week (these JDK changes are much smaller than the graal changes). >>> >>> Here is a brief overview of how the pieces fit together... >>> >>> Basically we wanted the GPU offload programming model to be triggered >>> by the programmer using Stream.parallel.forEach(). So the JDK changes >>> are really just interceptions of the stream API for parallel forEach. >>> The intercept code tests whether the stream meets a few criteria to >>> be offloadable, and if so tell graal (thru the Sumatra interface) to >>> compile the lambda method to HSAIL and dispatch it. If already >>> compiled, it will just be dispatched. Currently we have a property, >>> off by default, which tells the JDK intercept code to offload >>> immediately. If the offload-immediate flag is set, no hotspot >>> changes are really needed. >>> >>> The hotspot changes just provide an alternate way of enabling the >>> offloading (without using the offload-immediate flag) by using the >>> compilation of the underlying lambda method as a trigger for >>> offloading. They are very experimental and we would welcome >>> community input on other ways to do this. >>> >>> Hope this helps... >>> >>> -- Tom Deneau >>> >>> >>> >>> -----Original Message----- >>> From: graal-dev-bounces at openjdk.java.net >>> [mailto:graal-dev-bounces at openjdk.java.net] On Behalf Of Morris Meyer >>> Sent: Tuesday, June 11, 2013 7:17 PM >>> To: graal-dev at openjdk.java.net >>> Subject: Re: webrev for Graal HSAIL backend >>> >>> Vasanth, >>> >>> After seeing Apple's WWDC and the 4,000 core dual-GPU system they >>> built into the Mac Pro, I'm very happy to see the work your team has >>> put together. Lots of good stuff here and I think we should take most of it. >>> >>> I like that the HSAIL backend is in the com.oracle.graal namespace - >>> not so much as an Oracle engineer - but it will make working and >>> refactoring these GPU and CPU backends much easier. Thanks. >>> >>> compilerBroker.cpp, library_call.cpp, runtime.cpp and arguments.cpp seem >>> like the might be a little specialized for this point in time. Very >>> interesting changes though. I would like to get the heterogeneous >>> method support into HotSpot / Graal and sit down at the language >>> summit and discuss how we take on constructs like the ForEach work. >>> >>> I think com.amd.sumatra.Sumatra is sort of in the right ballpark - it >>> echos the change I made to CompilerToGPU in the earlier PTX work. I >>> would like of like to reserve the sumatra package for lambda work >>> along the lines you are thinking for a collections / lambda oriented >>> java.lang.invoke set of code. We need to get the requirements for this >>> sort of externalized kernel creating defined as soon as we can. >>> Maybe ...bridge.gpu, ...bridge.gpu.hsail, ...bridge.gpu.ptx packages >>> in the graal namespace? >>> >>> I think it might be a good next step to put in the HSAIL back end and >>> tests and the emulator working at the gate so we can build and verify >>> JDK9 / Sumatra / Graal changes in this environment going forward. >>> >>> I will be working as time permits on the heterogeneous methods and >>> PTX invocation so we can get both platforms at the gate integrating changes. >>> >>> That's all for now. I'm looking forward to working my way through >>> all these unit tests. Huge kudos AMD! >>> >>> --morris meyer >>> >>> On 6/11/13 6:16 PM, Venkatachalam, Vasanth wrote: >>>> Hi, >>>> >>>> The AMD Sumatra team has submitted a webrev (http://cr.openjdk.java.net/~ecaspole/graal_hsail/) that adds HSAIL code generation support for Graal, allowing Java programs to be compiled and executed on HSAIL-enabled GPU/APU devices. While this work is a prototype, we have included several working unit test cases, including Mandelbrot and NBody. >>>> >>>> Features >>>> >>>> Arithmetic operations for integers, longs, doubles, and floats >>>> Loads, stores and move operations Min/max/rem/carry operations for >>>> integers and longs Conversion operations - (currently support >>>> conversions between integers and floats, integers and doubles, integers and longs, floats and doubles). >>>> Some math library operations (e.g., square root). >>>> Support for JDK8 lambda constructs. >>>> >>>> Known Issues >>>> >>>> -The logic to handle register spilling is work-in-progress, so not all test cases that induce spilling are guaranteed to work. >>>> -X86 register encodings are being passed to the HSAIL backend. The >>>> calling convention returned by getCallingConvention() currently returns an x86 calling convention -Function call support has yet to be implemented. >>>> >>>> For a detailed list of unsupported features, refer to the routines >>>> that are emitting "NYI" in HSAILLIRGenerator.java >>>> >>>> The test cases (except for BasicHSAILTest) require an HSAIL simulator or hardware to execute, but in lieu of a simulator or hardware they will output the HSAIL code generated, which is useful for debugging. Moreover, BasicHSAILTest provides a template for adding Java code snippets and viewing the HSAIL generated code without executing the code. >>>> >>>> We encourage the community to support this new backend and extend it with additional features. >>>> >>>> Vasanth >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>> >>> >>> >> >> >> > > > From doug.simon at oracle.com Tue Jun 18 14:15:30 2013 From: doug.simon at oracle.com (Doug Simon) Date: Tue, 18 Jun 2013 23:15:30 +0200 Subject: update on graal HSAIL backend webrev In-Reply-To: References: <5DD1503F815BD14889DC81D28643E3A73D8DDD0C@sausexdag06.amd.com> Message-ID: <264216FC-2526-4491-B3F6-1358EE24AEFC@oracle.com> For simple printf-style debugging that you don't plan on checking in, you can keep using System.out and System.err. Even though Checkstyle complains, the code still runs as expected. And having the error is a clear reminder that the temporary printf's must be deleted before checking the code in. For longer term log output that you want to check in (and get through the Graal gate), you should use the Debug.log() mechanism. It helps to have the Debug.log() statements are in the (transitive) scope of a Debug.scope() method with a distinct name. E.g.: Debug.scope("HSA", new Runnable() { @Override public void run() { // some HSA code... Debug.log("hello %s", "world"); } } Then running with the option -G:Log=HSA. -Doug On Jun 18, 2013, at 10:42 PM, "Deneau, Tom" wrote: > Hi Doug -- > > We have some things we would like to log to stdout to help with debugging. > What is the standard graal way to do this logging? > > -- Tom Deneau > > > -----Original Message----- > From: graal-dev-bounces at openjdk.java.net [mailto:graal-dev-bounces at openjdk.java.net] On Behalf Of Doug Simon > Sent: Tuesday, June 18, 2013 2:33 PM > To: Venkatachalam, Vasanth > Cc: graal-dev at openjdk.java.net > Subject: Re: update on graal HSAIL backend webrev > > Hi Vasanth, > > Here's a proposal that should allow us to integrate your HSAIL backend changes and tests and avoids all licensing issues. > > As I understand it, the HSAIL tests depend on the OKRA framework. If you can make this framework available as a jar located at a publicly available URL, then you can simply specify it as a library dependency for the projects that need it (just like we specify the JUNIT library) in mx/projects. This way, the library will be pulled down and cached locally on demand for running the tests. > > In terms of the remaining code, we would like to receive and maintain the Graal HSAIL backend (plus tests) in the Graal repository which only contains JDK7 code and is only tested in a JDK7 environment. > > For the JDK8 changes, we propose that they remain in a Sumatra downstream repository. This would include the HotSpot code to do the optional interception on the Streams API. > > If this proposal is not acceptable, we're open to further discussion. If it is acceptable, could you please create a JDK7 compliant patch that has the Graal HSAIL backend, the tests for those changes and a dependency on OKRA as an external jar library. > > -Doug > > On Jun 18, 2013, at 6:27 PM, "Venkatachalam, Vasanth" wrote: > >> Hi, >> >> I wanted to give an update on our Graal webrev. >> >> We have fixed all of the Java warnings and most of the checkstyle errors. The only checkstyle errors that remain are coming from the license header used in two packages ( HSAIL simulator source) that currently require a University of Illinois license, as opposed to the Oracle license which checkstyle is expecting. We are internally discussing how to handle the licensing issue. >> >> I ran the three commands the Doug listed: >> >> mx clean >> mx build --jdt /path/to/ecj.jar --jdt-warning-as-error >> mx checkstyle >> >> Aside from the checkstyle warnings mentioned above, there were no issues. However, when using JDK7, mx still tries to build JDK 8 projects, even though their compliance level was specified as Java 8 in mx/projects. I reported this bug on the mailing list. >> >> I'd like to propose two possible ways we can submit the revised webrev, and get people's feedback on what's preferable. >> >> 1) The easiest approach would be to give you a single webrev encompassing all changes and provide you with adequate documentation that will allow you to be selective in what projects to review. >> >> 2) We can split this up into multiple webrevs. However, due to dependencies you will need to apply all the patches to be able to build. The four-way split I propose is as follows: >> >> A) Hotspot changes >> >> B) Graal changes >> B1) Infrastructure changes >> B2) Test cases >> >> Let me know what's preferable. If I don't hear from anyone I plan to produce 1) within the next couple of days. >> >> Vasanth >> >> >> >> /home/tester/graalcloneinternal/graal/graal/com.amd.okra/src/com/amd/okra/OkraKernel.java:2: Line does not match expected header line of ' \* Copyright \(c\) (20[0-9][0-9], )?20[0-9][0-9], Oracle and/or its affiliates. All rights reserved.'. >> /home/tester/graalcloneinternal/graal/graal/com.amd.okra/src/com/amd/okra/OkraContext.java:2: Line does not match expected header line of ' \* Copyright \(c\) (20[0-9][0-9], )?20[0-9][0-9], Oracle and/or its affiliates. All rights reserved.'. >> /home/tester/graalcloneinternal/graal/graal/com.amd.okra/src/com/amd/okra/OkraOpenCLtoHSAILCompiler.java:2: Line does not match expected header line of ' \* Copyright \(c\) (20[0-9][0-9], )?20[0-9][0-9], Oracle and/or its affiliates. All rights reserved.'. >> /home/tester/graalcloneinternal/graal/graal/com.amd.okra/src/com/amd/okra/OkraUtil.java:2: Line does not match expected header line of ' \* Copyright \(c\) (20[0-9][0-9], )?20[0-9][0-9], Oracle and/or its affiliates. All rights reserved.'. >> >> >> -----Original Message----- >> From: Doug Simon [mailto:doug.simon at oracle.com] >> Sent: Saturday, June 15, 2013 3:20 PM >> To: Venkatachalam, Vasanth >> Cc: graal-dev at openjdk.java.net >> Subject: Re: webrev for Graal HSAIL backend >> >> Hi Vasanth, >> >> On Jun 14, 2013, at 10:34 PM, "Venkatachalam, Vasanth" wrote: >> >>> Hi Doug, >>> >>> Thanks for the feedback. We're addressing your comments and had a few questions. >>> >>> 1) I'm trying to understand the issue with the formatting. To apply the Eclipse formatter, I first ran mx ideinit, then started eclipse and under projects->properties->Java Code Style->Formatter, I made sure the profile (Unmanaged profile 'Graal') was selected. Is this the correct way to apply the formatter? >> >> Yes. The Eclipse project configurations created by eclipseinit should also apply the formatter to any Java file when it is saved. >> >>> Can you give an example of some code that wasn't formatted according to these rules? >> >> Now that I've looked at the patch in more detail, I can't see any problem in terms of formatting. >> >>> 2). The only projects that use JDK8 features are com.amd.sumatra, and com.oracle.graal.compiler.hsail.test.lambda, In mx/projects we have specified that these projects have Java compliance of 1.8, so they shouldn't be compiled if the JDK used is 1.7. It seems like there should be a way for Eclipse to pick up on these changes after running mx ideinit. Are you saying this isn't the case? >> >> One problem is that Eclipse doesn't (yet) support JDK8 *language* features such as lambdas. Projects that only use JDK8 library features should be fine. >> >> The ideinit command does not consider compliance level when generating Eclipse project configurations - it probably should. And it should probably ignore any projects whose compliance level is >= 8 altogether. Not only does Eclipse not yet support JDK8 anguage features, it cannot yet generate JDK8 class files (the maximum "Compiler compliance level" one can currently set in Eclipse is 1.7). >> >> I've just modified the checkstyle command to pay attention to compliance levels. With this change, you should now be able to test your changes for Graal compliance on the command line with these commands: >> >> mx clean >> mx build --jdt /path/to/ecj.jar --jdt-warning-as-error mx checkstyle >> >> Once all 3 pass without any warnings or errors, the code should be easier to review and integrate. Note that these commands are part of our gate so we need to get them passing anyway. If you are game, you could try and replicate our complete gate testing with: >> >> mx --jacoco on gate >> >> BTW, if you download an ecj.jar[1] to /mx/ecj.jar, it will be automatically detected and used by the 'mx build' command, removing the need for the --jdt argument. >> >> Let me know if you run into any problems or have any further questions. >> >> -Doug >> >> [1] http://www.eclipse.org/downloads/download.php?file=/eclipse/downloads/drops4/R-4.2.2-201302041200/ecj-4.2.2.jar >> >>> -----Original Message----- >>> From: graal-dev-bounces at openjdk.java.net >>> [mailto:graal-dev-bounces at openjdk.java.net] On Behalf Of Doug Simon >>> Sent: Thursday, June 13, 2013 9:04 AM >>> To: Deneau, Tom >>> Cc: sumatra-dev at openjdk.java.net; graal-dev at openjdk.java.net >>> Subject: Re: webrev for Graal HSAIL backend >>> >>> Tom, >>> >>> It would really help to have this patch broken up into components that can be separately considered for integration. In particular (as Morris stated), having the HSAIL backend (and tests) in Graal would be great so a separate patch for this code would be a good first step. >>> >>> One immediate observation is that a lot of the code does not yet import into Eclipse very well. This is the primary tool we use for development and code comprehension so getting the code into Eclipse compliant form would be very helpful in terms of being able to efficiently assess a contribution and offer further feedback. This means: >>> >>> o Only use Java 7 language features (Eclipse does not yet support Java 8 language features and it's not clear when it will). >>> o Remove all Checkstyle warnings (use the eclipse-cs plugin or 'mx checkstyle'). >>> o Remove all Java warnings (which show up in the Eclipse Problems view). >>> o Format Java code with the Eclipse formatter (the Eclipse projects generated by 'mx eclipseinit' will ensure the Graal code formatting rules are used). >>> >>> It would be useful to have a high level description of the code, broken down by package or collection of packages. This can either be plain text or (preferably) package-info.java files. >>> >>> I notice there are files without licenses and some with University of Illinois licenses (the Okra framework). I'm no expert on licensing, but this may causes integration issues. >>> >>> The HotSpot changes are probably best to keep in the Sumatra repository for now given their experimental nature. >>> >>> I look forward to further progress in terms of getting Sumatra code into Graal - thanks for a good start! >>> >>> -Doug >>> >>> On Jun 12, 2013, at 5:59 PM, "Deneau, Tom" wrote: >>> >>>> Morris -- >>>> >>>> Regarding your comments on the hotspot changes in this webrev >>>> http://cr.openjdk.java.net/~ecaspole/graal_hsail/ >>>> I wanted to let you know that these hotspot changes really don't make >>>> sense on their own but co-operate with some JDK changes which we will >>>> be submitting in a separate webrev to the Sumatra-dev repository >>>> early next week (these JDK changes are much smaller than the graal changes). >>>> >>>> Here is a brief overview of how the pieces fit together... >>>> >>>> Basically we wanted the GPU offload programming model to be triggered >>>> by the programmer using Stream.parallel.forEach(). So the JDK changes >>>> are really just interceptions of the stream API for parallel forEach. >>>> The intercept code tests whether the stream meets a few criteria to >>>> be offloadable, and if so tell graal (thru the Sumatra interface) to >>>> compile the lambda method to HSAIL and dispatch it. If already >>>> compiled, it will just be dispatched. Currently we have a property, >>>> off by default, which tells the JDK intercept code to offload >>>> immediately. If the offload-immediate flag is set, no hotspot >>>> changes are really needed. >>>> >>>> The hotspot changes just provide an alternate way of enabling the >>>> offloading (without using the offload-immediate flag) by using the >>>> compilation of the underlying lambda method as a trigger for >>>> offloading. They are very experimental and we would welcome >>>> community input on other ways to do this. >>>> >>>> Hope this helps... >>>> >>>> -- Tom Deneau >>>> >>>> >>>> >>>> -----Original Message----- >>>> From: graal-dev-bounces at openjdk.java.net >>>> [mailto:graal-dev-bounces at openjdk.java.net] On Behalf Of Morris Meyer >>>> Sent: Tuesday, June 11, 2013 7:17 PM >>>> To: graal-dev at openjdk.java.net >>>> Subject: Re: webrev for Graal HSAIL backend >>>> >>>> Vasanth, >>>> >>>> After seeing Apple's WWDC and the 4,000 core dual-GPU system they >>>> built into the Mac Pro, I'm very happy to see the work your team has >>>> put together. Lots of good stuff here and I think we should take most of it. >>>> >>>> I like that the HSAIL backend is in the com.oracle.graal namespace - >>>> not so much as an Oracle engineer - but it will make working and >>>> refactoring these GPU and CPU backends much easier. Thanks. >>>> >>>> compilerBroker.cpp, library_call.cpp, runtime.cpp and arguments.cpp seem >>>> like the might be a little specialized for this point in time. Very >>>> interesting changes though. I would like to get the heterogeneous >>>> method support into HotSpot / Graal and sit down at the language >>>> summit and discuss how we take on constructs like the ForEach work. >>>> >>>> I think com.amd.sumatra.Sumatra is sort of in the right ballpark - it >>>> echos the change I made to CompilerToGPU in the earlier PTX work. I >>>> would like of like to reserve the sumatra package for lambda work >>>> along the lines you are thinking for a collections / lambda oriented >>>> java.lang.invoke set of code. We need to get the requirements for this >>>> sort of externalized kernel creating defined as soon as we can. >>>> Maybe ...bridge.gpu, ...bridge.gpu.hsail, ...bridge.gpu.ptx packages >>>> in the graal namespace? >>>> >>>> I think it might be a good next step to put in the HSAIL back end and >>>> tests and the emulator working at the gate so we can build and verify >>>> JDK9 / Sumatra / Graal changes in this environment going forward. >>>> >>>> I will be working as time permits on the heterogeneous methods and >>>> PTX invocation so we can get both platforms at the gate integrating changes. >>>> >>>> That's all for now. I'm looking forward to working my way through >>>> all these unit tests. Huge kudos AMD! >>>> >>>> --morris meyer >>>> >>>> On 6/11/13 6:16 PM, Venkatachalam, Vasanth wrote: >>>>> Hi, >>>>> >>>>> The AMD Sumatra team has submitted a webrev (http://cr.openjdk.java.net/~ecaspole/graal_hsail/) that adds HSAIL code generation support for Graal, allowing Java programs to be compiled and executed on HSAIL-enabled GPU/APU devices. While this work is a prototype, we have included several working unit test cases, including Mandelbrot and NBody. >>>>> >>>>> Features >>>>> >>>>> Arithmetic operations for integers, longs, doubles, and floats >>>>> Loads, stores and move operations Min/max/rem/carry operations for >>>>> integers and longs Conversion operations - (currently support >>>>> conversions between integers and floats, integers and doubles, integers and longs, floats and doubles). >>>>> Some math library operations (e.g., square root). >>>>> Support for JDK8 lambda constructs. >>>>> >>>>> Known Issues >>>>> >>>>> -The logic to handle register spilling is work-in-progress, so not all test cases that induce spilling are guaranteed to work. >>>>> -X86 register encodings are being passed to the HSAIL backend. The >>>>> calling convention returned by getCallingConvention() currently returns an x86 calling convention -Function call support has yet to be implemented. >>>>> >>>>> For a detailed list of unsupported features, refer to the routines >>>>> that are emitting "NYI" in HSAILLIRGenerator.java >>>>> >>>>> The test cases (except for BasicHSAILTest) require an HSAIL simulator or hardware to execute, but in lieu of a simulator or hardware they will output the HSAIL code generated, which is useful for debugging. Moreover, BasicHSAILTest provides a template for adding Java code snippets and viewing the HSAIL generated code without executing the code. >>>>> >>>>> We encourage the community to support this new backend and extend it with additional features. >>>>> >>>>> Vasanth >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>> >>>> >>>> >>> >>> >>> >> >> >> > > > From doug.simon at oracle.com Tue Jun 18 14:26:58 2013 From: doug.simon at oracle.com (Doug Simon) Date: Tue, 18 Jun 2013 23:26:58 +0200 Subject: update on graal HSAIL backend webrev In-Reply-To: <5DD1503F815BD14889DC81D28643E3A73D90648F@sausexdag06.amd.com> References: <5DD1503F815BD14889DC81D28643E3A73D90648F@sausexdag06.amd.com> Message-ID: <33B6ED41-5A19-4429-BAF2-C324036C20DE@oracle.com> On Jun 18, 2013, at 10:35 PM, "Venkatachalam, Vasanth" wrote: > Hi Doug, > > We had discussions with Donald Smith regarding the licensing issue. Based on his feedback, the University of Illinois license which the Okra framework uses is OpenJDK friendly. One advantage of including the simulator sources is that it makes the code self-contained, whereas if the jar had to be downloaded separately, it could get updated in a way that breaks the build. We wanted to find the easiest way to keep the code self-contained and ensure that all the licenses are OpenJDK compatible. The reference to the external jar is versioned so to preserve the versioned dependency, you add a version suffix to the jar. For example: library at OKRA@path=lib/okra-1.jar library at OKRA@urls=http://sumatra.amd.com/okra-1.jar Anytime you make a change to OKRA, upload a jar with a new suffix and change the dependency URL in mx/projects. How does that sound? -Doug > We've decided not to check-in any JDK8-dependent changes until Graal becomes JDK8 compatible. Till then we'll test these changes locally. > We're working on reverting these changes now. > > Vasanth > > > -----Original Message----- > From: Doug Simon [mailto:doug.simon at oracle.com] > Sent: Tuesday, June 18, 2013 2:33 PM > To: Venkatachalam, Vasanth > Cc: graal-dev at openjdk.java.net > Subject: Re: update on graal HSAIL backend webrev > > Hi Vasanth, > > Here's a proposal that should allow us to integrate your HSAIL backend changes and tests and avoids all licensing issues. > > As I understand it, the HSAIL tests depend on the OKRA framework. If you can make this framework available as a jar located at a publicly available URL, then you can simply specify it as a library dependency for the projects that need it (just like we specify the JUNIT library) in mx/projects. This way, the library will be pulled down and cached locally on demand for running the tests. > > In terms of the remaining code, we would like to receive and maintain the Graal HSAIL backend (plus tests) in the Graal repository which only contains JDK7 code and is only tested in a JDK7 environment. > > For the JDK8 changes, we propose that they remain in a Sumatra downstream repository. This would include the HotSpot code to do the optional interception on the Streams API. > > If this proposal is not acceptable, we're open to further discussion. If it is acceptable, could you please create a JDK7 compliant patch that has the Graal HSAIL backend, the tests for those changes and a dependency on OKRA as an external jar library. > > -Doug > > On Jun 18, 2013, at 6:27 PM, "Venkatachalam, Vasanth" wrote: > >> Hi, >> >> I wanted to give an update on our Graal webrev. >> >> We have fixed all of the Java warnings and most of the checkstyle errors. The only checkstyle errors that remain are coming from the license header used in two packages ( HSAIL simulator source) that currently require a University of Illinois license, as opposed to the Oracle license which checkstyle is expecting. We are internally discussing how to handle the licensing issue. >> >> I ran the three commands the Doug listed: >> >> mx clean >> mx build --jdt /path/to/ecj.jar --jdt-warning-as-error mx checkstyle >> >> Aside from the checkstyle warnings mentioned above, there were no issues. However, when using JDK7, mx still tries to build JDK 8 projects, even though their compliance level was specified as Java 8 in mx/projects. I reported this bug on the mailing list. >> >> I'd like to propose two possible ways we can submit the revised webrev, and get people's feedback on what's preferable. >> >> 1) The easiest approach would be to give you a single webrev encompassing all changes and provide you with adequate documentation that will allow you to be selective in what projects to review. >> >> 2) We can split this up into multiple webrevs. However, due to dependencies you will need to apply all the patches to be able to build. The four-way split I propose is as follows: >> >> A) Hotspot changes >> >> B) Graal changes >> B1) Infrastructure changes >> B2) Test cases >> >> Let me know what's preferable. If I don't hear from anyone I plan to produce 1) within the next couple of days. >> >> Vasanth >> >> >> >> /home/tester/graalcloneinternal/graal/graal/com.amd.okra/src/com/amd/okra/OkraKernel.java:2: Line does not match expected header line of ' \* Copyright \(c\) (20[0-9][0-9], )?20[0-9][0-9], Oracle and/or its affiliates. All rights reserved.'. >> /home/tester/graalcloneinternal/graal/graal/com.amd.okra/src/com/amd/okra/OkraContext.java:2: Line does not match expected header line of ' \* Copyright \(c\) (20[0-9][0-9], )?20[0-9][0-9], Oracle and/or its affiliates. All rights reserved.'. >> /home/tester/graalcloneinternal/graal/graal/com.amd.okra/src/com/amd/okra/OkraOpenCLtoHSAILCompiler.java:2: Line does not match expected header line of ' \* Copyright \(c\) (20[0-9][0-9], )?20[0-9][0-9], Oracle and/or its affiliates. All rights reserved.'. >> /home/tester/graalcloneinternal/graal/graal/com.amd.okra/src/com/amd/okra/OkraUtil.java:2: Line does not match expected header line of ' \* Copyright \(c\) (20[0-9][0-9], )?20[0-9][0-9], Oracle and/or its affiliates. All rights reserved.'. >> >> >> -----Original Message----- >> From: Doug Simon [mailto:doug.simon at oracle.com] >> Sent: Saturday, June 15, 2013 3:20 PM >> To: Venkatachalam, Vasanth >> Cc: graal-dev at openjdk.java.net >> Subject: Re: webrev for Graal HSAIL backend >> >> Hi Vasanth, >> >> On Jun 14, 2013, at 10:34 PM, "Venkatachalam, Vasanth" wrote: >> >>> Hi Doug, >>> >>> Thanks for the feedback. We're addressing your comments and had a few questions. >>> >>> 1) I'm trying to understand the issue with the formatting. To apply the Eclipse formatter, I first ran mx ideinit, then started eclipse and under projects->properties->Java Code Style->Formatter, I made sure the profile (Unmanaged profile 'Graal') was selected. Is this the correct way to apply the formatter? >> >> Yes. The Eclipse project configurations created by eclipseinit should also apply the formatter to any Java file when it is saved. >> >>> Can you give an example of some code that wasn't formatted according to these rules? >> >> Now that I've looked at the patch in more detail, I can't see any problem in terms of formatting. >> >>> 2). The only projects that use JDK8 features are com.amd.sumatra, and com.oracle.graal.compiler.hsail.test.lambda, In mx/projects we have specified that these projects have Java compliance of 1.8, so they shouldn't be compiled if the JDK used is 1.7. It seems like there should be a way for Eclipse to pick up on these changes after running mx ideinit. Are you saying this isn't the case? >> >> One problem is that Eclipse doesn't (yet) support JDK8 *language* features such as lambdas. Projects that only use JDK8 library features should be fine. >> >> The ideinit command does not consider compliance level when generating Eclipse project configurations - it probably should. And it should probably ignore any projects whose compliance level is >= 8 altogether. Not only does Eclipse not yet support JDK8 anguage features, it cannot yet generate JDK8 class files (the maximum "Compiler compliance level" one can currently set in Eclipse is 1.7). >> >> I've just modified the checkstyle command to pay attention to compliance levels. With this change, you should now be able to test your changes for Graal compliance on the command line with these commands: >> >> mx clean >> mx build --jdt /path/to/ecj.jar --jdt-warning-as-error mx checkstyle >> >> Once all 3 pass without any warnings or errors, the code should be easier to review and integrate. Note that these commands are part of our gate so we need to get them passing anyway. If you are game, you could try and replicate our complete gate testing with: >> >> mx --jacoco on gate >> >> BTW, if you download an ecj.jar[1] to /mx/ecj.jar, it will be automatically detected and used by the 'mx build' command, removing the need for the --jdt argument. >> >> Let me know if you run into any problems or have any further questions. >> >> -Doug >> >> [1] >> http://www.eclipse.org/downloads/download.php?file=/eclipse/downloads/ >> drops4/R-4.2.2-201302041200/ecj-4.2.2.jar >> >>> -----Original Message----- >>> From: graal-dev-bounces at openjdk.java.net >>> [mailto:graal-dev-bounces at openjdk.java.net] On Behalf Of Doug Simon >>> Sent: Thursday, June 13, 2013 9:04 AM >>> To: Deneau, Tom >>> Cc: sumatra-dev at openjdk.java.net; graal-dev at openjdk.java.net >>> Subject: Re: webrev for Graal HSAIL backend >>> >>> Tom, >>> >>> It would really help to have this patch broken up into components that can be separately considered for integration. In particular (as Morris stated), having the HSAIL backend (and tests) in Graal would be great so a separate patch for this code would be a good first step. >>> >>> One immediate observation is that a lot of the code does not yet import into Eclipse very well. This is the primary tool we use for development and code comprehension so getting the code into Eclipse compliant form would be very helpful in terms of being able to efficiently assess a contribution and offer further feedback. This means: >>> >>> o Only use Java 7 language features (Eclipse does not yet support Java 8 language features and it's not clear when it will). >>> o Remove all Checkstyle warnings (use the eclipse-cs plugin or 'mx checkstyle'). >>> o Remove all Java warnings (which show up in the Eclipse Problems view). >>> o Format Java code with the Eclipse formatter (the Eclipse projects generated by 'mx eclipseinit' will ensure the Graal code formatting rules are used). >>> >>> It would be useful to have a high level description of the code, broken down by package or collection of packages. This can either be plain text or (preferably) package-info.java files. >>> >>> I notice there are files without licenses and some with University of Illinois licenses (the Okra framework). I'm no expert on licensing, but this may causes integration issues. >>> >>> The HotSpot changes are probably best to keep in the Sumatra repository for now given their experimental nature. >>> >>> I look forward to further progress in terms of getting Sumatra code into Graal - thanks for a good start! >>> >>> -Doug >>> >>> On Jun 12, 2013, at 5:59 PM, "Deneau, Tom" wrote: >>> >>>> Morris -- >>>> >>>> Regarding your comments on the hotspot changes in this webrev >>>> http://cr.openjdk.java.net/~ecaspole/graal_hsail/ >>>> I wanted to let you know that these hotspot changes really don't >>>> make sense on their own but co-operate with some JDK changes which >>>> we will be submitting in a separate webrev to the Sumatra-dev >>>> repository early next week (these JDK changes are much smaller than the graal changes). >>>> >>>> Here is a brief overview of how the pieces fit together... >>>> >>>> Basically we wanted the GPU offload programming model to be >>>> triggered by the programmer using Stream.parallel.forEach(). So the >>>> JDK changes are really just interceptions of the stream API for parallel forEach. >>>> The intercept code tests whether the stream meets a few criteria to >>>> be offloadable, and if so tell graal (thru the Sumatra interface) to >>>> compile the lambda method to HSAIL and dispatch it. If already >>>> compiled, it will just be dispatched. Currently we have a property, >>>> off by default, which tells the JDK intercept code to offload >>>> immediately. If the offload-immediate flag is set, no hotspot >>>> changes are really needed. >>>> >>>> The hotspot changes just provide an alternate way of enabling the >>>> offloading (without using the offload-immediate flag) by using the >>>> compilation of the underlying lambda method as a trigger for >>>> offloading. They are very experimental and we would welcome >>>> community input on other ways to do this. >>>> >>>> Hope this helps... >>>> >>>> -- Tom Deneau >>>> >>>> >>>> >>>> -----Original Message----- >>>> From: graal-dev-bounces at openjdk.java.net >>>> [mailto:graal-dev-bounces at openjdk.java.net] On Behalf Of Morris >>>> Meyer >>>> Sent: Tuesday, June 11, 2013 7:17 PM >>>> To: graal-dev at openjdk.java.net >>>> Subject: Re: webrev for Graal HSAIL backend >>>> >>>> Vasanth, >>>> >>>> After seeing Apple's WWDC and the 4,000 core dual-GPU system they >>>> built into the Mac Pro, I'm very happy to see the work your team has >>>> put together. Lots of good stuff here and I think we should take most of it. >>>> >>>> I like that the HSAIL backend is in the com.oracle.graal namespace - >>>> not so much as an Oracle engineer - but it will make working and >>>> refactoring these GPU and CPU backends much easier. Thanks. >>>> >>>> compilerBroker.cpp, library_call.cpp, runtime.cpp and arguments.cpp seem >>>> like the might be a little specialized for this point in time. Very >>>> interesting changes though. I would like to get the heterogeneous >>>> method support into HotSpot / Graal and sit down at the language >>>> summit and discuss how we take on constructs like the ForEach work. >>>> >>>> I think com.amd.sumatra.Sumatra is sort of in the right ballpark - >>>> it echos the change I made to CompilerToGPU in the earlier PTX work. >>>> I would like of like to reserve the sumatra package for lambda work >>>> along the lines you are thinking for a collections / lambda oriented >>>> java.lang.invoke set of code. We need to get the requirements for this >>>> sort of externalized kernel creating defined as soon as we can. >>>> Maybe ...bridge.gpu, ...bridge.gpu.hsail, ...bridge.gpu.ptx packages >>>> in the graal namespace? >>>> >>>> I think it might be a good next step to put in the HSAIL back end >>>> and tests and the emulator working at the gate so we can build and >>>> verify >>>> JDK9 / Sumatra / Graal changes in this environment going forward. >>>> >>>> I will be working as time permits on the heterogeneous methods and >>>> PTX invocation so we can get both platforms at the gate integrating changes. >>>> >>>> That's all for now. I'm looking forward to working my way through >>>> all these unit tests. Huge kudos AMD! >>>> >>>> --morris meyer >>>> >>>> On 6/11/13 6:16 PM, Venkatachalam, Vasanth wrote: >>>>> Hi, >>>>> >>>>> The AMD Sumatra team has submitted a webrev (http://cr.openjdk.java.net/~ecaspole/graal_hsail/) that adds HSAIL code generation support for Graal, allowing Java programs to be compiled and executed on HSAIL-enabled GPU/APU devices. While this work is a prototype, we have included several working unit test cases, including Mandelbrot and NBody. >>>>> >>>>> Features >>>>> >>>>> Arithmetic operations for integers, longs, doubles, and floats >>>>> Loads, stores and move operations Min/max/rem/carry operations for >>>>> integers and longs Conversion operations - (currently support >>>>> conversions between integers and floats, integers and doubles, integers and longs, floats and doubles). >>>>> Some math library operations (e.g., square root). >>>>> Support for JDK8 lambda constructs. >>>>> >>>>> Known Issues >>>>> >>>>> -The logic to handle register spilling is work-in-progress, so not all test cases that induce spilling are guaranteed to work. >>>>> -X86 register encodings are being passed to the HSAIL backend. The >>>>> calling convention returned by getCallingConvention() currently returns an x86 calling convention -Function call support has yet to be implemented. >>>>> >>>>> For a detailed list of unsupported features, refer to the routines >>>>> that are emitting "NYI" in HSAILLIRGenerator.java >>>>> >>>>> The test cases (except for BasicHSAILTest) require an HSAIL simulator or hardware to execute, but in lieu of a simulator or hardware they will output the HSAIL code generated, which is useful for debugging. Moreover, BasicHSAILTest provides a template for adding Java code snippets and viewing the HSAIL generated code without executing the code. >>>>> >>>>> We encourage the community to support this new backend and extend it with additional features. >>>>> >>>>> Vasanth >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>> >>>> >>>> >>> >>> >>> >> >> >> > > > From Vasanth.Venkatachalam at amd.com Tue Jun 18 14:39:42 2013 From: Vasanth.Venkatachalam at amd.com (Venkatachalam, Vasanth) Date: Tue, 18 Jun 2013 21:39:42 +0000 Subject: update on graal HSAIL backend webrev In-Reply-To: <264216FC-2526-4491-B3F6-1358EE24AEFC@oracle.com> References: <5DD1503F815BD14889DC81D28643E3A73D8DDD0C@sausexdag06.amd.com> <264216FC-2526-4491-B3F6-1358EE24AEFC@oracle.com> Message-ID: <5DD1503F815BD14889DC81D28643E3A73D90950E@sausexdag06.amd.com> For the Debug.log statements that aren't within a Debug.scope( ) method, can you explain how to run with logging enabled? Vasanth -----Original Message----- From: Doug Simon [mailto:doug.simon at oracle.com] Sent: Tuesday, June 18, 2013 4:16 PM To: Deneau, Tom Cc: Venkatachalam, Vasanth; graal-dev at openjdk.java.net Subject: Re: update on graal HSAIL backend webrev For simple printf-style debugging that you don't plan on checking in, you can keep using System.out and System.err. Even though Checkstyle complains, the code still runs as expected. And having the error is a clear reminder that the temporary printf's must be deleted before checking the code in. For longer term log output that you want to check in (and get through the Graal gate), you should use the Debug.log() mechanism. It helps to have the Debug.log() statements are in the (transitive) scope of a Debug.scope() method with a distinct name. E.g.: Debug.scope("HSA", new Runnable() { @Override public void run() { // some HSA code... Debug.log("hello %s", "world"); } } Then running with the option -G:Log=HSA. -Doug On Jun 18, 2013, at 10:42 PM, "Deneau, Tom" wrote: > Hi Doug -- > > We have some things we would like to log to stdout to help with debugging. > What is the standard graal way to do this logging? > > -- Tom Deneau > > > -----Original Message----- > From: graal-dev-bounces at openjdk.java.net > [mailto:graal-dev-bounces at openjdk.java.net] On Behalf Of Doug Simon > Sent: Tuesday, June 18, 2013 2:33 PM > To: Venkatachalam, Vasanth > Cc: graal-dev at openjdk.java.net > Subject: Re: update on graal HSAIL backend webrev > > Hi Vasanth, > > Here's a proposal that should allow us to integrate your HSAIL backend changes and tests and avoids all licensing issues. > > As I understand it, the HSAIL tests depend on the OKRA framework. If you can make this framework available as a jar located at a publicly available URL, then you can simply specify it as a library dependency for the projects that need it (just like we specify the JUNIT library) in mx/projects. This way, the library will be pulled down and cached locally on demand for running the tests. > > In terms of the remaining code, we would like to receive and maintain the Graal HSAIL backend (plus tests) in the Graal repository which only contains JDK7 code and is only tested in a JDK7 environment. > > For the JDK8 changes, we propose that they remain in a Sumatra downstream repository. This would include the HotSpot code to do the optional interception on the Streams API. > > If this proposal is not acceptable, we're open to further discussion. If it is acceptable, could you please create a JDK7 compliant patch that has the Graal HSAIL backend, the tests for those changes and a dependency on OKRA as an external jar library. > > -Doug > > On Jun 18, 2013, at 6:27 PM, "Venkatachalam, Vasanth" wrote: > >> Hi, >> >> I wanted to give an update on our Graal webrev. >> >> We have fixed all of the Java warnings and most of the checkstyle errors. The only checkstyle errors that remain are coming from the license header used in two packages ( HSAIL simulator source) that currently require a University of Illinois license, as opposed to the Oracle license which checkstyle is expecting. We are internally discussing how to handle the licensing issue. >> >> I ran the three commands the Doug listed: >> >> mx clean >> mx build --jdt /path/to/ecj.jar --jdt-warning-as-error mx checkstyle >> >> Aside from the checkstyle warnings mentioned above, there were no issues. However, when using JDK7, mx still tries to build JDK 8 projects, even though their compliance level was specified as Java 8 in mx/projects. I reported this bug on the mailing list. >> >> I'd like to propose two possible ways we can submit the revised webrev, and get people's feedback on what's preferable. >> >> 1) The easiest approach would be to give you a single webrev encompassing all changes and provide you with adequate documentation that will allow you to be selective in what projects to review. >> >> 2) We can split this up into multiple webrevs. However, due to dependencies you will need to apply all the patches to be able to build. The four-way split I propose is as follows: >> >> A) Hotspot changes >> >> B) Graal changes >> B1) Infrastructure changes >> B2) Test cases >> >> Let me know what's preferable. If I don't hear from anyone I plan to produce 1) within the next couple of days. >> >> Vasanth >> >> >> >> /home/tester/graalcloneinternal/graal/graal/com.amd.okra/src/com/amd/okra/OkraKernel.java:2: Line does not match expected header line of ' \* Copyright \(c\) (20[0-9][0-9], )?20[0-9][0-9], Oracle and/or its affiliates. All rights reserved.'. >> /home/tester/graalcloneinternal/graal/graal/com.amd.okra/src/com/amd/okra/OkraContext.java:2: Line does not match expected header line of ' \* Copyright \(c\) (20[0-9][0-9], )?20[0-9][0-9], Oracle and/or its affiliates. All rights reserved.'. >> /home/tester/graalcloneinternal/graal/graal/com.amd.okra/src/com/amd/okra/OkraOpenCLtoHSAILCompiler.java:2: Line does not match expected header line of ' \* Copyright \(c\) (20[0-9][0-9], )?20[0-9][0-9], Oracle and/or its affiliates. All rights reserved.'. >> /home/tester/graalcloneinternal/graal/graal/com.amd.okra/src/com/amd/okra/OkraUtil.java:2: Line does not match expected header line of ' \* Copyright \(c\) (20[0-9][0-9], )?20[0-9][0-9], Oracle and/or its affiliates. All rights reserved.'. >> >> >> -----Original Message----- >> From: Doug Simon [mailto:doug.simon at oracle.com] >> Sent: Saturday, June 15, 2013 3:20 PM >> To: Venkatachalam, Vasanth >> Cc: graal-dev at openjdk.java.net >> Subject: Re: webrev for Graal HSAIL backend >> >> Hi Vasanth, >> >> On Jun 14, 2013, at 10:34 PM, "Venkatachalam, Vasanth" wrote: >> >>> Hi Doug, >>> >>> Thanks for the feedback. We're addressing your comments and had a few questions. >>> >>> 1) I'm trying to understand the issue with the formatting. To apply the Eclipse formatter, I first ran mx ideinit, then started eclipse and under projects->properties->Java Code Style->Formatter, I made sure the profile (Unmanaged profile 'Graal') was selected. Is this the correct way to apply the formatter? >> >> Yes. The Eclipse project configurations created by eclipseinit should also apply the formatter to any Java file when it is saved. >> >>> Can you give an example of some code that wasn't formatted according to these rules? >> >> Now that I've looked at the patch in more detail, I can't see any problem in terms of formatting. >> >>> 2). The only projects that use JDK8 features are com.amd.sumatra, and com.oracle.graal.compiler.hsail.test.lambda, In mx/projects we have specified that these projects have Java compliance of 1.8, so they shouldn't be compiled if the JDK used is 1.7. It seems like there should be a way for Eclipse to pick up on these changes after running mx ideinit. Are you saying this isn't the case? >> >> One problem is that Eclipse doesn't (yet) support JDK8 *language* features such as lambdas. Projects that only use JDK8 library features should be fine. >> >> The ideinit command does not consider compliance level when generating Eclipse project configurations - it probably should. And it should probably ignore any projects whose compliance level is >= 8 altogether. Not only does Eclipse not yet support JDK8 anguage features, it cannot yet generate JDK8 class files (the maximum "Compiler compliance level" one can currently set in Eclipse is 1.7). >> >> I've just modified the checkstyle command to pay attention to compliance levels. With this change, you should now be able to test your changes for Graal compliance on the command line with these commands: >> >> mx clean >> mx build --jdt /path/to/ecj.jar --jdt-warning-as-error mx checkstyle >> >> Once all 3 pass without any warnings or errors, the code should be easier to review and integrate. Note that these commands are part of our gate so we need to get them passing anyway. If you are game, you could try and replicate our complete gate testing with: >> >> mx --jacoco on gate >> >> BTW, if you download an ecj.jar[1] to /mx/ecj.jar, it will be automatically detected and used by the 'mx build' command, removing the need for the --jdt argument. >> >> Let me know if you run into any problems or have any further questions. >> >> -Doug >> >> [1] >> http://www.eclipse.org/downloads/download.php?file=/eclipse/downloads >> /drops4/R-4.2.2-201302041200/ecj-4.2.2.jar >> >>> -----Original Message----- >>> From: graal-dev-bounces at openjdk.java.net >>> [mailto:graal-dev-bounces at openjdk.java.net] On Behalf Of Doug Simon >>> Sent: Thursday, June 13, 2013 9:04 AM >>> To: Deneau, Tom >>> Cc: sumatra-dev at openjdk.java.net; graal-dev at openjdk.java.net >>> Subject: Re: webrev for Graal HSAIL backend >>> >>> Tom, >>> >>> It would really help to have this patch broken up into components that can be separately considered for integration. In particular (as Morris stated), having the HSAIL backend (and tests) in Graal would be great so a separate patch for this code would be a good first step. >>> >>> One immediate observation is that a lot of the code does not yet import into Eclipse very well. This is the primary tool we use for development and code comprehension so getting the code into Eclipse compliant form would be very helpful in terms of being able to efficiently assess a contribution and offer further feedback. This means: >>> >>> o Only use Java 7 language features (Eclipse does not yet support Java 8 language features and it's not clear when it will). >>> o Remove all Checkstyle warnings (use the eclipse-cs plugin or 'mx checkstyle'). >>> o Remove all Java warnings (which show up in the Eclipse Problems view). >>> o Format Java code with the Eclipse formatter (the Eclipse projects generated by 'mx eclipseinit' will ensure the Graal code formatting rules are used). >>> >>> It would be useful to have a high level description of the code, broken down by package or collection of packages. This can either be plain text or (preferably) package-info.java files. >>> >>> I notice there are files without licenses and some with University of Illinois licenses (the Okra framework). I'm no expert on licensing, but this may causes integration issues. >>> >>> The HotSpot changes are probably best to keep in the Sumatra repository for now given their experimental nature. >>> >>> I look forward to further progress in terms of getting Sumatra code into Graal - thanks for a good start! >>> >>> -Doug >>> >>> On Jun 12, 2013, at 5:59 PM, "Deneau, Tom" wrote: >>> >>>> Morris -- >>>> >>>> Regarding your comments on the hotspot changes in this webrev >>>> http://cr.openjdk.java.net/~ecaspole/graal_hsail/ >>>> I wanted to let you know that these hotspot changes really don't >>>> make sense on their own but co-operate with some JDK changes which >>>> we will be submitting in a separate webrev to the Sumatra-dev >>>> repository early next week (these JDK changes are much smaller than the graal changes). >>>> >>>> Here is a brief overview of how the pieces fit together... >>>> >>>> Basically we wanted the GPU offload programming model to be >>>> triggered by the programmer using Stream.parallel.forEach(). So the >>>> JDK changes are really just interceptions of the stream API for parallel forEach. >>>> The intercept code tests whether the stream meets a few criteria to >>>> be offloadable, and if so tell graal (thru the Sumatra interface) >>>> to compile the lambda method to HSAIL and dispatch it. If already >>>> compiled, it will just be dispatched. Currently we have a >>>> property, off by default, which tells the JDK intercept code to >>>> offload immediately. If the offload-immediate flag is set, no >>>> hotspot changes are really needed. >>>> >>>> The hotspot changes just provide an alternate way of enabling the >>>> offloading (without using the offload-immediate flag) by using the >>>> compilation of the underlying lambda method as a trigger for >>>> offloading. They are very experimental and we would welcome >>>> community input on other ways to do this. >>>> >>>> Hope this helps... >>>> >>>> -- Tom Deneau >>>> >>>> >>>> >>>> -----Original Message----- >>>> From: graal-dev-bounces at openjdk.java.net >>>> [mailto:graal-dev-bounces at openjdk.java.net] On Behalf Of Morris >>>> Meyer >>>> Sent: Tuesday, June 11, 2013 7:17 PM >>>> To: graal-dev at openjdk.java.net >>>> Subject: Re: webrev for Graal HSAIL backend >>>> >>>> Vasanth, >>>> >>>> After seeing Apple's WWDC and the 4,000 core dual-GPU system they >>>> built into the Mac Pro, I'm very happy to see the work your team >>>> has put together. Lots of good stuff here and I think we should take most of it. >>>> >>>> I like that the HSAIL backend is in the com.oracle.graal namespace >>>> - not so much as an Oracle engineer - but it will make working and >>>> refactoring these GPU and CPU backends much easier. Thanks. >>>> >>>> compilerBroker.cpp, library_call.cpp, runtime.cpp and arguments.cpp seem >>>> like the might be a little specialized for this point in time. Very >>>> interesting changes though. I would like to get the heterogeneous >>>> method support into HotSpot / Graal and sit down at the language >>>> summit and discuss how we take on constructs like the ForEach work. >>>> >>>> I think com.amd.sumatra.Sumatra is sort of in the right ballpark - >>>> it echos the change I made to CompilerToGPU in the earlier PTX >>>> work. I would like of like to reserve the sumatra package for >>>> lambda work along the lines you are thinking for a collections / lambda oriented >>>> java.lang.invoke set of code. We need to get the requirements for this >>>> sort of externalized kernel creating defined as soon as we can. >>>> Maybe ...bridge.gpu, ...bridge.gpu.hsail, ...bridge.gpu.ptx >>>> packages in the graal namespace? >>>> >>>> I think it might be a good next step to put in the HSAIL back end >>>> and tests and the emulator working at the gate so we can build and >>>> verify >>>> JDK9 / Sumatra / Graal changes in this environment going forward. >>>> >>>> I will be working as time permits on the heterogeneous methods and >>>> PTX invocation so we can get both platforms at the gate integrating changes. >>>> >>>> That's all for now. I'm looking forward to working my way through >>>> all these unit tests. Huge kudos AMD! >>>> >>>> --morris meyer >>>> >>>> On 6/11/13 6:16 PM, Venkatachalam, Vasanth wrote: >>>>> Hi, >>>>> >>>>> The AMD Sumatra team has submitted a webrev (http://cr.openjdk.java.net/~ecaspole/graal_hsail/) that adds HSAIL code generation support for Graal, allowing Java programs to be compiled and executed on HSAIL-enabled GPU/APU devices. While this work is a prototype, we have included several working unit test cases, including Mandelbrot and NBody. >>>>> >>>>> Features >>>>> >>>>> Arithmetic operations for integers, longs, doubles, and floats >>>>> Loads, stores and move operations Min/max/rem/carry operations for >>>>> integers and longs Conversion operations - (currently support >>>>> conversions between integers and floats, integers and doubles, integers and longs, floats and doubles). >>>>> Some math library operations (e.g., square root). >>>>> Support for JDK8 lambda constructs. >>>>> >>>>> Known Issues >>>>> >>>>> -The logic to handle register spilling is work-in-progress, so not all test cases that induce spilling are guaranteed to work. >>>>> -X86 register encodings are being passed to the HSAIL backend. The >>>>> calling convention returned by getCallingConvention() currently returns an x86 calling convention -Function call support has yet to be implemented. >>>>> >>>>> For a detailed list of unsupported features, refer to the routines >>>>> that are emitting "NYI" in HSAILLIRGenerator.java >>>>> >>>>> The test cases (except for BasicHSAILTest) require an HSAIL simulator or hardware to execute, but in lieu of a simulator or hardware they will output the HSAIL code generated, which is useful for debugging. Moreover, BasicHSAILTest provides a template for adding Java code snippets and viewing the HSAIL generated code without executing the code. >>>>> >>>>> We encourage the community to support this new backend and extend it with additional features. >>>>> >>>>> Vasanth >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>> >>>> >>>> >>> >>> >>> >> >> >> > > > From doug.simon at oracle.com Tue Jun 18 14:42:46 2013 From: doug.simon at oracle.com (Doug Simon) Date: Tue, 18 Jun 2013 23:42:46 +0200 Subject: update on graal HSAIL backend webrev In-Reply-To: <5DD1503F815BD14889DC81D28643E3A73D90950E@sausexdag06.amd.com> References: <5DD1503F815BD14889DC81D28643E3A73D8DDD0C@sausexdag06.amd.com> <264216FC-2526-4491-B3F6-1358EE24AEFC@oracle.com> <5DD1503F815BD14889DC81D28643E3A73D90950E@sausexdag06.amd.com> Message-ID: <35BBC32B-B2C2-42BE-9A23-EB4EA89AEB82@oracle.com> You can still see the output of such statements with a '-G:Log=' option. But then you'll also see the output of every other Debug.log() statement. On Jun 18, 2013, at 11:39 PM, "Venkatachalam, Vasanth" wrote: > For the Debug.log statements that aren't within a Debug.scope( ) method, can you explain how to run with logging enabled? > > Vasanth > > -----Original Message----- > From: Doug Simon [mailto:doug.simon at oracle.com] > Sent: Tuesday, June 18, 2013 4:16 PM > To: Deneau, Tom > Cc: Venkatachalam, Vasanth; graal-dev at openjdk.java.net > Subject: Re: update on graal HSAIL backend webrev > > For simple printf-style debugging that you don't plan on checking in, you can keep using System.out and System.err. Even though Checkstyle complains, the code still runs as expected. And having the error is a clear reminder that the temporary printf's must be deleted before checking the code in. > > For longer term log output that you want to check in (and get through the Graal gate), you should use the Debug.log() mechanism. It helps to have the Debug.log() statements are in the (transitive) scope of a Debug.scope() method with a distinct name. E.g.: > > Debug.scope("HSA", new Runnable() { > @Override > public void run() { > // some HSA code... > > Debug.log("hello %s", "world"); > } > } > > Then running with the option -G:Log=HSA. > > -Doug > > On Jun 18, 2013, at 10:42 PM, "Deneau, Tom" wrote: > >> Hi Doug -- >> >> We have some things we would like to log to stdout to help with debugging. >> What is the standard graal way to do this logging? >> >> -- Tom Deneau >> >> >> -----Original Message----- >> From: graal-dev-bounces at openjdk.java.net >> [mailto:graal-dev-bounces at openjdk.java.net] On Behalf Of Doug Simon >> Sent: Tuesday, June 18, 2013 2:33 PM >> To: Venkatachalam, Vasanth >> Cc: graal-dev at openjdk.java.net >> Subject: Re: update on graal HSAIL backend webrev >> >> Hi Vasanth, >> >> Here's a proposal that should allow us to integrate your HSAIL backend changes and tests and avoids all licensing issues. >> >> As I understand it, the HSAIL tests depend on the OKRA framework. If you can make this framework available as a jar located at a publicly available URL, then you can simply specify it as a library dependency for the projects that need it (just like we specify the JUNIT library) in mx/projects. This way, the library will be pulled down and cached locally on demand for running the tests. >> >> In terms of the remaining code, we would like to receive and maintain the Graal HSAIL backend (plus tests) in the Graal repository which only contains JDK7 code and is only tested in a JDK7 environment. >> >> For the JDK8 changes, we propose that they remain in a Sumatra downstream repository. This would include the HotSpot code to do the optional interception on the Streams API. >> >> If this proposal is not acceptable, we're open to further discussion. If it is acceptable, could you please create a JDK7 compliant patch that has the Graal HSAIL backend, the tests for those changes and a dependency on OKRA as an external jar library. >> >> -Doug >> >> On Jun 18, 2013, at 6:27 PM, "Venkatachalam, Vasanth" wrote: >> >>> Hi, >>> >>> I wanted to give an update on our Graal webrev. >>> >>> We have fixed all of the Java warnings and most of the checkstyle errors. The only checkstyle errors that remain are coming from the license header used in two packages ( HSAIL simulator source) that currently require a University of Illinois license, as opposed to the Oracle license which checkstyle is expecting. We are internally discussing how to handle the licensing issue. >>> >>> I ran the three commands the Doug listed: >>> >>> mx clean >>> mx build --jdt /path/to/ecj.jar --jdt-warning-as-error mx checkstyle >>> >>> Aside from the checkstyle warnings mentioned above, there were no issues. However, when using JDK7, mx still tries to build JDK 8 projects, even though their compliance level was specified as Java 8 in mx/projects. I reported this bug on the mailing list. >>> >>> I'd like to propose two possible ways we can submit the revised webrev, and get people's feedback on what's preferable. >>> >>> 1) The easiest approach would be to give you a single webrev encompassing all changes and provide you with adequate documentation that will allow you to be selective in what projects to review. >>> >>> 2) We can split this up into multiple webrevs. However, due to dependencies you will need to apply all the patches to be able to build. The four-way split I propose is as follows: >>> >>> A) Hotspot changes >>> >>> B) Graal changes >>> B1) Infrastructure changes >>> B2) Test cases >>> >>> Let me know what's preferable. If I don't hear from anyone I plan to produce 1) within the next couple of days. >>> >>> Vasanth >>> >>> >>> >>> /home/tester/graalcloneinternal/graal/graal/com.amd.okra/src/com/amd/okra/OkraKernel.java:2: Line does not match expected header line of ' \* Copyright \(c\) (20[0-9][0-9], )?20[0-9][0-9], Oracle and/or its affiliates. All rights reserved.'. >>> /home/tester/graalcloneinternal/graal/graal/com.amd.okra/src/com/amd/okra/OkraContext.java:2: Line does not match expected header line of ' \* Copyright \(c\) (20[0-9][0-9], )?20[0-9][0-9], Oracle and/or its affiliates. All rights reserved.'. >>> /home/tester/graalcloneinternal/graal/graal/com.amd.okra/src/com/amd/okra/OkraOpenCLtoHSAILCompiler.java:2: Line does not match expected header line of ' \* Copyright \(c\) (20[0-9][0-9], )?20[0-9][0-9], Oracle and/or its affiliates. All rights reserved.'. >>> /home/tester/graalcloneinternal/graal/graal/com.amd.okra/src/com/amd/okra/OkraUtil.java:2: Line does not match expected header line of ' \* Copyright \(c\) (20[0-9][0-9], )?20[0-9][0-9], Oracle and/or its affiliates. All rights reserved.'. >>> >>> >>> -----Original Message----- >>> From: Doug Simon [mailto:doug.simon at oracle.com] >>> Sent: Saturday, June 15, 2013 3:20 PM >>> To: Venkatachalam, Vasanth >>> Cc: graal-dev at openjdk.java.net >>> Subject: Re: webrev for Graal HSAIL backend >>> >>> Hi Vasanth, >>> >>> On Jun 14, 2013, at 10:34 PM, "Venkatachalam, Vasanth" wrote: >>> >>>> Hi Doug, >>>> >>>> Thanks for the feedback. We're addressing your comments and had a few questions. >>>> >>>> 1) I'm trying to understand the issue with the formatting. To apply the Eclipse formatter, I first ran mx ideinit, then started eclipse and under projects->properties->Java Code Style->Formatter, I made sure the profile (Unmanaged profile 'Graal') was selected. Is this the correct way to apply the formatter? >>> >>> Yes. The Eclipse project configurations created by eclipseinit should also apply the formatter to any Java file when it is saved. >>> >>>> Can you give an example of some code that wasn't formatted according to these rules? >>> >>> Now that I've looked at the patch in more detail, I can't see any problem in terms of formatting. >>> >>>> 2). The only projects that use JDK8 features are com.amd.sumatra, and com.oracle.graal.compiler.hsail.test.lambda, In mx/projects we have specified that these projects have Java compliance of 1.8, so they shouldn't be compiled if the JDK used is 1.7. It seems like there should be a way for Eclipse to pick up on these changes after running mx ideinit. Are you saying this isn't the case? >>> >>> One problem is that Eclipse doesn't (yet) support JDK8 *language* features such as lambdas. Projects that only use JDK8 library features should be fine. >>> >>> The ideinit command does not consider compliance level when generating Eclipse project configurations - it probably should. And it should probably ignore any projects whose compliance level is >= 8 altogether. Not only does Eclipse not yet support JDK8 anguage features, it cannot yet generate JDK8 class files (the maximum "Compiler compliance level" one can currently set in Eclipse is 1.7). >>> >>> I've just modified the checkstyle command to pay attention to compliance levels. With this change, you should now be able to test your changes for Graal compliance on the command line with these commands: >>> >>> mx clean >>> mx build --jdt /path/to/ecj.jar --jdt-warning-as-error mx checkstyle >>> >>> Once all 3 pass without any warnings or errors, the code should be easier to review and integrate. Note that these commands are part of our gate so we need to get them passing anyway. If you are game, you could try and replicate our complete gate testing with: >>> >>> mx --jacoco on gate >>> >>> BTW, if you download an ecj.jar[1] to /mx/ecj.jar, it will be automatically detected and used by the 'mx build' command, removing the need for the --jdt argument. >>> >>> Let me know if you run into any problems or have any further questions. >>> >>> -Doug >>> >>> [1] >>> http://www.eclipse.org/downloads/download.php?file=/eclipse/downloads >>> /drops4/R-4.2.2-201302041200/ecj-4.2.2.jar >>> >>>> -----Original Message----- >>>> From: graal-dev-bounces at openjdk.java.net >>>> [mailto:graal-dev-bounces at openjdk.java.net] On Behalf Of Doug Simon >>>> Sent: Thursday, June 13, 2013 9:04 AM >>>> To: Deneau, Tom >>>> Cc: sumatra-dev at openjdk.java.net; graal-dev at openjdk.java.net >>>> Subject: Re: webrev for Graal HSAIL backend >>>> >>>> Tom, >>>> >>>> It would really help to have this patch broken up into components that can be separately considered for integration. In particular (as Morris stated), having the HSAIL backend (and tests) in Graal would be great so a separate patch for this code would be a good first step. >>>> >>>> One immediate observation is that a lot of the code does not yet import into Eclipse very well. This is the primary tool we use for development and code comprehension so getting the code into Eclipse compliant form would be very helpful in terms of being able to efficiently assess a contribution and offer further feedback. This means: >>>> >>>> o Only use Java 7 language features (Eclipse does not yet support Java 8 language features and it's not clear when it will). >>>> o Remove all Checkstyle warnings (use the eclipse-cs plugin or 'mx checkstyle'). >>>> o Remove all Java warnings (which show up in the Eclipse Problems view). >>>> o Format Java code with the Eclipse formatter (the Eclipse projects generated by 'mx eclipseinit' will ensure the Graal code formatting rules are used). >>>> >>>> It would be useful to have a high level description of the code, broken down by package or collection of packages. This can either be plain text or (preferably) package-info.java files. >>>> >>>> I notice there are files without licenses and some with University of Illinois licenses (the Okra framework). I'm no expert on licensing, but this may causes integration issues. >>>> >>>> The HotSpot changes are probably best to keep in the Sumatra repository for now given their experimental nature. >>>> >>>> I look forward to further progress in terms of getting Sumatra code into Graal - thanks for a good start! >>>> >>>> -Doug >>>> >>>> On Jun 12, 2013, at 5:59 PM, "Deneau, Tom" wrote: >>>> >>>>> Morris -- >>>>> >>>>> Regarding your comments on the hotspot changes in this webrev >>>>> http://cr.openjdk.java.net/~ecaspole/graal_hsail/ >>>>> I wanted to let you know that these hotspot changes really don't >>>>> make sense on their own but co-operate with some JDK changes which >>>>> we will be submitting in a separate webrev to the Sumatra-dev >>>>> repository early next week (these JDK changes are much smaller than the graal changes). >>>>> >>>>> Here is a brief overview of how the pieces fit together... >>>>> >>>>> Basically we wanted the GPU offload programming model to be >>>>> triggered by the programmer using Stream.parallel.forEach(). So the >>>>> JDK changes are really just interceptions of the stream API for parallel forEach. >>>>> The intercept code tests whether the stream meets a few criteria to >>>>> be offloadable, and if so tell graal (thru the Sumatra interface) >>>>> to compile the lambda method to HSAIL and dispatch it. If already >>>>> compiled, it will just be dispatched. Currently we have a >>>>> property, off by default, which tells the JDK intercept code to >>>>> offload immediately. If the offload-immediate flag is set, no >>>>> hotspot changes are really needed. >>>>> >>>>> The hotspot changes just provide an alternate way of enabling the >>>>> offloading (without using the offload-immediate flag) by using the >>>>> compilation of the underlying lambda method as a trigger for >>>>> offloading. They are very experimental and we would welcome >>>>> community input on other ways to do this. >>>>> >>>>> Hope this helps... >>>>> >>>>> -- Tom Deneau >>>>> >>>>> >>>>> >>>>> -----Original Message----- >>>>> From: graal-dev-bounces at openjdk.java.net >>>>> [mailto:graal-dev-bounces at openjdk.java.net] On Behalf Of Morris >>>>> Meyer >>>>> Sent: Tuesday, June 11, 2013 7:17 PM >>>>> To: graal-dev at openjdk.java.net >>>>> Subject: Re: webrev for Graal HSAIL backend >>>>> >>>>> Vasanth, >>>>> >>>>> After seeing Apple's WWDC and the 4,000 core dual-GPU system they >>>>> built into the Mac Pro, I'm very happy to see the work your team >>>>> has put together. Lots of good stuff here and I think we should take most of it. >>>>> >>>>> I like that the HSAIL backend is in the com.oracle.graal namespace >>>>> - not so much as an Oracle engineer - but it will make working and >>>>> refactoring these GPU and CPU backends much easier. Thanks. >>>>> >>>>> compilerBroker.cpp, library_call.cpp, runtime.cpp and arguments.cpp seem >>>>> like the might be a little specialized for this point in time. Very >>>>> interesting changes though. I would like to get the heterogeneous >>>>> method support into HotSpot / Graal and sit down at the language >>>>> summit and discuss how we take on constructs like the ForEach work. >>>>> >>>>> I think com.amd.sumatra.Sumatra is sort of in the right ballpark - >>>>> it echos the change I made to CompilerToGPU in the earlier PTX >>>>> work. I would like of like to reserve the sumatra package for >>>>> lambda work along the lines you are thinking for a collections / lambda oriented >>>>> java.lang.invoke set of code. We need to get the requirements for this >>>>> sort of externalized kernel creating defined as soon as we can. >>>>> Maybe ...bridge.gpu, ...bridge.gpu.hsail, ...bridge.gpu.ptx >>>>> packages in the graal namespace? >>>>> >>>>> I think it might be a good next step to put in the HSAIL back end >>>>> and tests and the emulator working at the gate so we can build and >>>>> verify >>>>> JDK9 / Sumatra / Graal changes in this environment going forward. >>>>> >>>>> I will be working as time permits on the heterogeneous methods and >>>>> PTX invocation so we can get both platforms at the gate integrating changes. >>>>> >>>>> That's all for now. I'm looking forward to working my way through >>>>> all these unit tests. Huge kudos AMD! >>>>> >>>>> --morris meyer >>>>> >>>>> On 6/11/13 6:16 PM, Venkatachalam, Vasanth wrote: >>>>>> Hi, >>>>>> >>>>>> The AMD Sumatra team has submitted a webrev (http://cr.openjdk.java.net/~ecaspole/graal_hsail/) that adds HSAIL code generation support for Graal, allowing Java programs to be compiled and executed on HSAIL-enabled GPU/APU devices. While this work is a prototype, we have included several working unit test cases, including Mandelbrot and NBody. >>>>>> >>>>>> Features >>>>>> >>>>>> Arithmetic operations for integers, longs, doubles, and floats >>>>>> Loads, stores and move operations Min/max/rem/carry operations for >>>>>> integers and longs Conversion operations - (currently support >>>>>> conversions between integers and floats, integers and doubles, integers and longs, floats and doubles). >>>>>> Some math library operations (e.g., square root). >>>>>> Support for JDK8 lambda constructs. >>>>>> >>>>>> Known Issues >>>>>> >>>>>> -The logic to handle register spilling is work-in-progress, so not all test cases that induce spilling are guaranteed to work. >>>>>> -X86 register encodings are being passed to the HSAIL backend. The >>>>>> calling convention returned by getCallingConvention() currently returns an x86 calling convention -Function call support has yet to be implemented. >>>>>> >>>>>> For a detailed list of unsupported features, refer to the routines >>>>>> that are emitting "NYI" in HSAILLIRGenerator.java >>>>>> >>>>>> The test cases (except for BasicHSAILTest) require an HSAIL simulator or hardware to execute, but in lieu of a simulator or hardware they will output the HSAIL code generated, which is useful for debugging. Moreover, BasicHSAILTest provides a template for adding Java code snippets and viewing the HSAIL generated code without executing the code. >>>>>> >>>>>> We encourage the community to support this new backend and extend it with additional features. >>>>>> >>>>>> Vasanth >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>>> >>>> >>>> >>>> >>> >>> >>> >> >> >> > > > From christian.thalinger at oracle.com Tue Jun 18 15:02:49 2013 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Tue, 18 Jun 2013 15:02:49 -0700 Subject: update on graal HSAIL backend webrev In-Reply-To: <5DD1503F815BD14889DC81D28643E3A73D90648F@sausexdag06.amd.com> References: <5DD1503F815BD14889DC81D28643E3A73D90648F@sausexdag06.amd.com> Message-ID: <8910258D-F1D2-4E54-B579-FF3BB2B15256@oracle.com> On Jun 18, 2013, at 1:35 PM, "Venkatachalam, Vasanth" wrote: > Hi Doug, > > We had discussions with Donald Smith regarding the licensing issue. Based on his feedback, the University of Illinois license which the Okra framework uses is OpenJDK friendly. One advantage of including the simulator sources is that it makes the code self-contained, whereas if the jar had to be downloaded separately, it could get updated in a way that breaks the build. We wanted to find the easiest way to keep the code self-contained and ensure that all the licenses are OpenJDK compatible. > > We've decided not to check-in any JDK8-dependent changes until Graal becomes JDK8 compatible. Till then we'll test these changes locally. > We're working on reverting these changes now. That's good and what I wanted to see too. -- Chris > > Vasanth > > > -----Original Message----- > From: Doug Simon [mailto:doug.simon at oracle.com] > Sent: Tuesday, June 18, 2013 2:33 PM > To: Venkatachalam, Vasanth > Cc: graal-dev at openjdk.java.net > Subject: Re: update on graal HSAIL backend webrev > > Hi Vasanth, > > Here's a proposal that should allow us to integrate your HSAIL backend changes and tests and avoids all licensing issues. > > As I understand it, the HSAIL tests depend on the OKRA framework. If you can make this framework available as a jar located at a publicly available URL, then you can simply specify it as a library dependency for the projects that need it (just like we specify the JUNIT library) in mx/projects. This way, the library will be pulled down and cached locally on demand for running the tests. > > In terms of the remaining code, we would like to receive and maintain the Graal HSAIL backend (plus tests) in the Graal repository which only contains JDK7 code and is only tested in a JDK7 environment. > > For the JDK8 changes, we propose that they remain in a Sumatra downstream repository. This would include the HotSpot code to do the optional interception on the Streams API. > > If this proposal is not acceptable, we're open to further discussion. If it is acceptable, could you please create a JDK7 compliant patch that has the Graal HSAIL backend, the tests for those changes and a dependency on OKRA as an external jar library. > > -Doug > > On Jun 18, 2013, at 6:27 PM, "Venkatachalam, Vasanth" wrote: > >> Hi, >> >> I wanted to give an update on our Graal webrev. >> >> We have fixed all of the Java warnings and most of the checkstyle errors. The only checkstyle errors that remain are coming from the license header used in two packages ( HSAIL simulator source) that currently require a University of Illinois license, as opposed to the Oracle license which checkstyle is expecting. We are internally discussing how to handle the licensing issue. >> >> I ran the three commands the Doug listed: >> >> mx clean >> mx build --jdt /path/to/ecj.jar --jdt-warning-as-error mx checkstyle >> >> Aside from the checkstyle warnings mentioned above, there were no issues. However, when using JDK7, mx still tries to build JDK 8 projects, even though their compliance level was specified as Java 8 in mx/projects. I reported this bug on the mailing list. >> >> I'd like to propose two possible ways we can submit the revised webrev, and get people's feedback on what's preferable. >> >> 1) The easiest approach would be to give you a single webrev encompassing all changes and provide you with adequate documentation that will allow you to be selective in what projects to review. >> >> 2) We can split this up into multiple webrevs. However, due to dependencies you will need to apply all the patches to be able to build. The four-way split I propose is as follows: >> >> A) Hotspot changes >> >> B) Graal changes >> B1) Infrastructure changes >> B2) Test cases >> >> Let me know what's preferable. If I don't hear from anyone I plan to produce 1) within the next couple of days. >> >> Vasanth >> >> >> >> /home/tester/graalcloneinternal/graal/graal/com.amd.okra/src/com/amd/okra/OkraKernel.java:2: Line does not match expected header line of ' \* Copyright \(c\) (20[0-9][0-9], )?20[0-9][0-9], Oracle and/or its affiliates. All rights reserved.'. >> /home/tester/graalcloneinternal/graal/graal/com.amd.okra/src/com/amd/okra/OkraContext.java:2: Line does not match expected header line of ' \* Copyright \(c\) (20[0-9][0-9], )?20[0-9][0-9], Oracle and/or its affiliates. All rights reserved.'. >> /home/tester/graalcloneinternal/graal/graal/com.amd.okra/src/com/amd/okra/OkraOpenCLtoHSAILCompiler.java:2: Line does not match expected header line of ' \* Copyright \(c\) (20[0-9][0-9], )?20[0-9][0-9], Oracle and/or its affiliates. All rights reserved.'. >> /home/tester/graalcloneinternal/graal/graal/com.amd.okra/src/com/amd/okra/OkraUtil.java:2: Line does not match expected header line of ' \* Copyright \(c\) (20[0-9][0-9], )?20[0-9][0-9], Oracle and/or its affiliates. All rights reserved.'. >> >> >> -----Original Message----- >> From: Doug Simon [mailto:doug.simon at oracle.com] >> Sent: Saturday, June 15, 2013 3:20 PM >> To: Venkatachalam, Vasanth >> Cc: graal-dev at openjdk.java.net >> Subject: Re: webrev for Graal HSAIL backend >> >> Hi Vasanth, >> >> On Jun 14, 2013, at 10:34 PM, "Venkatachalam, Vasanth" wrote: >> >>> Hi Doug, >>> >>> Thanks for the feedback. We're addressing your comments and had a few questions. >>> >>> 1) I'm trying to understand the issue with the formatting. To apply the Eclipse formatter, I first ran mx ideinit, then started eclipse and under projects->properties->Java Code Style->Formatter, I made sure the profile (Unmanaged profile 'Graal') was selected. Is this the correct way to apply the formatter? >> >> Yes. The Eclipse project configurations created by eclipseinit should also apply the formatter to any Java file when it is saved. >> >>> Can you give an example of some code that wasn't formatted according to these rules? >> >> Now that I've looked at the patch in more detail, I can't see any problem in terms of formatting. >> >>> 2). The only projects that use JDK8 features are com.amd.sumatra, and com.oracle.graal.compiler.hsail.test.lambda, In mx/projects we have specified that these projects have Java compliance of 1.8, so they shouldn't be compiled if the JDK used is 1.7. It seems like there should be a way for Eclipse to pick up on these changes after running mx ideinit. Are you saying this isn't the case? >> >> One problem is that Eclipse doesn't (yet) support JDK8 *language* features such as lambdas. Projects that only use JDK8 library features should be fine. >> >> The ideinit command does not consider compliance level when generating Eclipse project configurations - it probably should. And it should probably ignore any projects whose compliance level is >= 8 altogether. Not only does Eclipse not yet support JDK8 anguage features, it cannot yet generate JDK8 class files (the maximum "Compiler compliance level" one can currently set in Eclipse is 1.7). >> >> I've just modified the checkstyle command to pay attention to compliance levels. With this change, you should now be able to test your changes for Graal compliance on the command line with these commands: >> >> mx clean >> mx build --jdt /path/to/ecj.jar --jdt-warning-as-error mx checkstyle >> >> Once all 3 pass without any warnings or errors, the code should be easier to review and integrate. Note that these commands are part of our gate so we need to get them passing anyway. If you are game, you could try and replicate our complete gate testing with: >> >> mx --jacoco on gate >> >> BTW, if you download an ecj.jar[1] to /mx/ecj.jar, it will be automatically detected and used by the 'mx build' command, removing the need for the --jdt argument. >> >> Let me know if you run into any problems or have any further questions. >> >> -Doug >> >> [1] >> http://www.eclipse.org/downloads/download.php?file=/eclipse/downloads/ >> drops4/R-4.2.2-201302041200/ecj-4.2.2.jar >> >>> -----Original Message----- >>> From: graal-dev-bounces at openjdk.java.net >>> [mailto:graal-dev-bounces at openjdk.java.net] On Behalf Of Doug Simon >>> Sent: Thursday, June 13, 2013 9:04 AM >>> To: Deneau, Tom >>> Cc: sumatra-dev at openjdk.java.net; graal-dev at openjdk.java.net >>> Subject: Re: webrev for Graal HSAIL backend >>> >>> Tom, >>> >>> It would really help to have this patch broken up into components that can be separately considered for integration. In particular (as Morris stated), having the HSAIL backend (and tests) in Graal would be great so a separate patch for this code would be a good first step. >>> >>> One immediate observation is that a lot of the code does not yet import into Eclipse very well. This is the primary tool we use for development and code comprehension so getting the code into Eclipse compliant form would be very helpful in terms of being able to efficiently assess a contribution and offer further feedback. This means: >>> >>> o Only use Java 7 language features (Eclipse does not yet support Java 8 language features and it's not clear when it will). >>> o Remove all Checkstyle warnings (use the eclipse-cs plugin or 'mx checkstyle'). >>> o Remove all Java warnings (which show up in the Eclipse Problems view). >>> o Format Java code with the Eclipse formatter (the Eclipse projects generated by 'mx eclipseinit' will ensure the Graal code formatting rules are used). >>> >>> It would be useful to have a high level description of the code, broken down by package or collection of packages. This can either be plain text or (preferably) package-info.java files. >>> >>> I notice there are files without licenses and some with University of Illinois licenses (the Okra framework). I'm no expert on licensing, but this may causes integration issues. >>> >>> The HotSpot changes are probably best to keep in the Sumatra repository for now given their experimental nature. >>> >>> I look forward to further progress in terms of getting Sumatra code into Graal - thanks for a good start! >>> >>> -Doug >>> >>> On Jun 12, 2013, at 5:59 PM, "Deneau, Tom" wrote: >>> >>>> Morris -- >>>> >>>> Regarding your comments on the hotspot changes in this webrev >>>> http://cr.openjdk.java.net/~ecaspole/graal_hsail/ >>>> I wanted to let you know that these hotspot changes really don't >>>> make sense on their own but co-operate with some JDK changes which >>>> we will be submitting in a separate webrev to the Sumatra-dev >>>> repository early next week (these JDK changes are much smaller than the graal changes). >>>> >>>> Here is a brief overview of how the pieces fit together... >>>> >>>> Basically we wanted the GPU offload programming model to be >>>> triggered by the programmer using Stream.parallel.forEach(). So the >>>> JDK changes are really just interceptions of the stream API for parallel forEach. >>>> The intercept code tests whether the stream meets a few criteria to >>>> be offloadable, and if so tell graal (thru the Sumatra interface) to >>>> compile the lambda method to HSAIL and dispatch it. If already >>>> compiled, it will just be dispatched. Currently we have a property, >>>> off by default, which tells the JDK intercept code to offload >>>> immediately. If the offload-immediate flag is set, no hotspot >>>> changes are really needed. >>>> >>>> The hotspot changes just provide an alternate way of enabling the >>>> offloading (without using the offload-immediate flag) by using the >>>> compilation of the underlying lambda method as a trigger for >>>> offloading. They are very experimental and we would welcome >>>> community input on other ways to do this. >>>> >>>> Hope this helps... >>>> >>>> -- Tom Deneau >>>> >>>> >>>> >>>> -----Original Message----- >>>> From: graal-dev-bounces at openjdk.java.net >>>> [mailto:graal-dev-bounces at openjdk.java.net] On Behalf Of Morris >>>> Meyer >>>> Sent: Tuesday, June 11, 2013 7:17 PM >>>> To: graal-dev at openjdk.java.net >>>> Subject: Re: webrev for Graal HSAIL backend >>>> >>>> Vasanth, >>>> >>>> After seeing Apple's WWDC and the 4,000 core dual-GPU system they >>>> built into the Mac Pro, I'm very happy to see the work your team has >>>> put together. Lots of good stuff here and I think we should take most of it. >>>> >>>> I like that the HSAIL backend is in the com.oracle.graal namespace - >>>> not so much as an Oracle engineer - but it will make working and >>>> refactoring these GPU and CPU backends much easier. Thanks. >>>> >>>> compilerBroker.cpp, library_call.cpp, runtime.cpp and arguments.cpp seem >>>> like the might be a little specialized for this point in time. Very >>>> interesting changes though. I would like to get the heterogeneous >>>> method support into HotSpot / Graal and sit down at the language >>>> summit and discuss how we take on constructs like the ForEach work. >>>> >>>> I think com.amd.sumatra.Sumatra is sort of in the right ballpark - >>>> it echos the change I made to CompilerToGPU in the earlier PTX work. >>>> I would like of like to reserve the sumatra package for lambda work >>>> along the lines you are thinking for a collections / lambda oriented >>>> java.lang.invoke set of code. We need to get the requirements for this >>>> sort of externalized kernel creating defined as soon as we can. >>>> Maybe ...bridge.gpu, ...bridge.gpu.hsail, ...bridge.gpu.ptx packages >>>> in the graal namespace? >>>> >>>> I think it might be a good next step to put in the HSAIL back end >>>> and tests and the emulator working at the gate so we can build and >>>> verify >>>> JDK9 / Sumatra / Graal changes in this environment going forward. >>>> >>>> I will be working as time permits on the heterogeneous methods and >>>> PTX invocation so we can get both platforms at the gate integrating changes. >>>> >>>> That's all for now. I'm looking forward to working my way through >>>> all these unit tests. Huge kudos AMD! >>>> >>>> --morris meyer >>>> >>>> On 6/11/13 6:16 PM, Venkatachalam, Vasanth wrote: >>>>> Hi, >>>>> >>>>> The AMD Sumatra team has submitted a webrev (http://cr.openjdk.java.net/~ecaspole/graal_hsail/) that adds HSAIL code generation support for Graal, allowing Java programs to be compiled and executed on HSAIL-enabled GPU/APU devices. While this work is a prototype, we have included several working unit test cases, including Mandelbrot and NBody. >>>>> >>>>> Features >>>>> >>>>> Arithmetic operations for integers, longs, doubles, and floats >>>>> Loads, stores and move operations Min/max/rem/carry operations for >>>>> integers and longs Conversion operations - (currently support >>>>> conversions between integers and floats, integers and doubles, integers and longs, floats and doubles). >>>>> Some math library operations (e.g., square root). >>>>> Support for JDK8 lambda constructs. >>>>> >>>>> Known Issues >>>>> >>>>> -The logic to handle register spilling is work-in-progress, so not all test cases that induce spilling are guaranteed to work. >>>>> -X86 register encodings are being passed to the HSAIL backend. The >>>>> calling convention returned by getCallingConvention() currently returns an x86 calling convention -Function call support has yet to be implemented. >>>>> >>>>> For a detailed list of unsupported features, refer to the routines >>>>> that are emitting "NYI" in HSAILLIRGenerator.java >>>>> >>>>> The test cases (except for BasicHSAILTest) require an HSAIL simulator or hardware to execute, but in lieu of a simulator or hardware they will output the HSAIL code generated, which is useful for debugging. Moreover, BasicHSAILTest provides a template for adding Java code snippets and viewing the HSAIL generated code without executing the code. >>>>> >>>>> We encourage the community to support this new backend and extend it with additional features. >>>>> >>>>> Vasanth >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>> >>>> >>>> >>> >>> >>> >> >> >> > > > From tom.deneau at amd.com Tue Jun 18 16:08:05 2013 From: tom.deneau at amd.com (Deneau, Tom) Date: Tue, 18 Jun 2013 23:08:05 +0000 Subject: update on graal HSAIL backend webrev In-Reply-To: <35BBC32B-B2C2-42BE-9A23-EB4EA89AEB82@oracle.com> References: <5DD1503F815BD14889DC81D28643E3A73D8DDD0C@sausexdag06.amd.com> <264216FC-2526-4491-B3F6-1358EE24AEFC@oracle.com> <5DD1503F815BD14889DC81D28643E3A73D90950E@sausexdag06.amd.com> <35BBC32B-B2C2-42BE-9A23-EB4EA89AEB82@oracle.com> Message-ID: Is there a Debug.log variant that does not do any formatting? We have generated code we want to log that has embedded % signs. -- Tom -----Original Message----- From: Doug Simon [mailto:doug.simon at oracle.com] Sent: Tuesday, June 18, 2013 4:43 PM To: Venkatachalam, Vasanth Cc: Deneau, Tom; graal-dev at openjdk.java.net Subject: Re: update on graal HSAIL backend webrev You can still see the output of such statements with a '-G:Log=' option. But then you'll also see the output of every other Debug.log() statement. On Jun 18, 2013, at 11:39 PM, "Venkatachalam, Vasanth" wrote: > For the Debug.log statements that aren't within a Debug.scope( ) method, can you explain how to run with logging enabled? > > Vasanth > > -----Original Message----- > From: Doug Simon [mailto:doug.simon at oracle.com] > Sent: Tuesday, June 18, 2013 4:16 PM > To: Deneau, Tom > Cc: Venkatachalam, Vasanth; graal-dev at openjdk.java.net > Subject: Re: update on graal HSAIL backend webrev > > For simple printf-style debugging that you don't plan on checking in, you can keep using System.out and System.err. Even though Checkstyle complains, the code still runs as expected. And having the error is a clear reminder that the temporary printf's must be deleted before checking the code in. > > For longer term log output that you want to check in (and get through the Graal gate), you should use the Debug.log() mechanism. It helps to have the Debug.log() statements are in the (transitive) scope of a Debug.scope() method with a distinct name. E.g.: > > Debug.scope("HSA", new Runnable() { > @Override > public void run() { > // some HSA code... > > Debug.log("hello %s", "world"); > } > } > > Then running with the option -G:Log=HSA. > > -Doug > > On Jun 18, 2013, at 10:42 PM, "Deneau, Tom" wrote: > >> Hi Doug -- >> >> We have some things we would like to log to stdout to help with debugging. >> What is the standard graal way to do this logging? >> >> -- Tom Deneau >> >> >> -----Original Message----- >> From: graal-dev-bounces at openjdk.java.net >> [mailto:graal-dev-bounces at openjdk.java.net] On Behalf Of Doug Simon >> Sent: Tuesday, June 18, 2013 2:33 PM >> To: Venkatachalam, Vasanth >> Cc: graal-dev at openjdk.java.net >> Subject: Re: update on graal HSAIL backend webrev >> >> Hi Vasanth, >> >> Here's a proposal that should allow us to integrate your HSAIL backend changes and tests and avoids all licensing issues. >> >> As I understand it, the HSAIL tests depend on the OKRA framework. If you can make this framework available as a jar located at a publicly available URL, then you can simply specify it as a library dependency for the projects that need it (just like we specify the JUNIT library) in mx/projects. This way, the library will be pulled down and cached locally on demand for running the tests. >> >> In terms of the remaining code, we would like to receive and maintain the Graal HSAIL backend (plus tests) in the Graal repository which only contains JDK7 code and is only tested in a JDK7 environment. >> >> For the JDK8 changes, we propose that they remain in a Sumatra downstream repository. This would include the HotSpot code to do the optional interception on the Streams API. >> >> If this proposal is not acceptable, we're open to further discussion. If it is acceptable, could you please create a JDK7 compliant patch that has the Graal HSAIL backend, the tests for those changes and a dependency on OKRA as an external jar library. >> >> -Doug >> >> On Jun 18, 2013, at 6:27 PM, "Venkatachalam, Vasanth" wrote: >> >>> Hi, >>> >>> I wanted to give an update on our Graal webrev. >>> >>> We have fixed all of the Java warnings and most of the checkstyle errors. The only checkstyle errors that remain are coming from the license header used in two packages ( HSAIL simulator source) that currently require a University of Illinois license, as opposed to the Oracle license which checkstyle is expecting. We are internally discussing how to handle the licensing issue. >>> >>> I ran the three commands the Doug listed: >>> >>> mx clean >>> mx build --jdt /path/to/ecj.jar --jdt-warning-as-error mx checkstyle >>> >>> Aside from the checkstyle warnings mentioned above, there were no issues. However, when using JDK7, mx still tries to build JDK 8 projects, even though their compliance level was specified as Java 8 in mx/projects. I reported this bug on the mailing list. >>> >>> I'd like to propose two possible ways we can submit the revised webrev, and get people's feedback on what's preferable. >>> >>> 1) The easiest approach would be to give you a single webrev encompassing all changes and provide you with adequate documentation that will allow you to be selective in what projects to review. >>> >>> 2) We can split this up into multiple webrevs. However, due to dependencies you will need to apply all the patches to be able to build. The four-way split I propose is as follows: >>> >>> A) Hotspot changes >>> >>> B) Graal changes >>> B1) Infrastructure changes >>> B2) Test cases >>> >>> Let me know what's preferable. If I don't hear from anyone I plan to produce 1) within the next couple of days. >>> >>> Vasanth >>> >>> >>> >>> /home/tester/graalcloneinternal/graal/graal/com.amd.okra/src/com/amd/okra/OkraKernel.java:2: Line does not match expected header line of ' \* Copyright \(c\) (20[0-9][0-9], )?20[0-9][0-9], Oracle and/or its affiliates. All rights reserved.'. >>> /home/tester/graalcloneinternal/graal/graal/com.amd.okra/src/com/amd/okra/OkraContext.java:2: Line does not match expected header line of ' \* Copyright \(c\) (20[0-9][0-9], )?20[0-9][0-9], Oracle and/or its affiliates. All rights reserved.'. >>> /home/tester/graalcloneinternal/graal/graal/com.amd.okra/src/com/amd/okra/OkraOpenCLtoHSAILCompiler.java:2: Line does not match expected header line of ' \* Copyright \(c\) (20[0-9][0-9], )?20[0-9][0-9], Oracle and/or its affiliates. All rights reserved.'. >>> /home/tester/graalcloneinternal/graal/graal/com.amd.okra/src/com/amd/okra/OkraUtil.java:2: Line does not match expected header line of ' \* Copyright \(c\) (20[0-9][0-9], )?20[0-9][0-9], Oracle and/or its affiliates. All rights reserved.'. >>> >>> >>> -----Original Message----- >>> From: Doug Simon [mailto:doug.simon at oracle.com] >>> Sent: Saturday, June 15, 2013 3:20 PM >>> To: Venkatachalam, Vasanth >>> Cc: graal-dev at openjdk.java.net >>> Subject: Re: webrev for Graal HSAIL backend >>> >>> Hi Vasanth, >>> >>> On Jun 14, 2013, at 10:34 PM, "Venkatachalam, Vasanth" wrote: >>> >>>> Hi Doug, >>>> >>>> Thanks for the feedback. We're addressing your comments and had a few questions. >>>> >>>> 1) I'm trying to understand the issue with the formatting. To apply the Eclipse formatter, I first ran mx ideinit, then started eclipse and under projects->properties->Java Code Style->Formatter, I made sure the profile (Unmanaged profile 'Graal') was selected. Is this the correct way to apply the formatter? >>> >>> Yes. The Eclipse project configurations created by eclipseinit should also apply the formatter to any Java file when it is saved. >>> >>>> Can you give an example of some code that wasn't formatted according to these rules? >>> >>> Now that I've looked at the patch in more detail, I can't see any problem in terms of formatting. >>> >>>> 2). The only projects that use JDK8 features are com.amd.sumatra, and com.oracle.graal.compiler.hsail.test.lambda, In mx/projects we have specified that these projects have Java compliance of 1.8, so they shouldn't be compiled if the JDK used is 1.7. It seems like there should be a way for Eclipse to pick up on these changes after running mx ideinit. Are you saying this isn't the case? >>> >>> One problem is that Eclipse doesn't (yet) support JDK8 *language* features such as lambdas. Projects that only use JDK8 library features should be fine. >>> >>> The ideinit command does not consider compliance level when generating Eclipse project configurations - it probably should. And it should probably ignore any projects whose compliance level is >= 8 altogether. Not only does Eclipse not yet support JDK8 anguage features, it cannot yet generate JDK8 class files (the maximum "Compiler compliance level" one can currently set in Eclipse is 1.7). >>> >>> I've just modified the checkstyle command to pay attention to compliance levels. With this change, you should now be able to test your changes for Graal compliance on the command line with these commands: >>> >>> mx clean >>> mx build --jdt /path/to/ecj.jar --jdt-warning-as-error mx checkstyle >>> >>> Once all 3 pass without any warnings or errors, the code should be easier to review and integrate. Note that these commands are part of our gate so we need to get them passing anyway. If you are game, you could try and replicate our complete gate testing with: >>> >>> mx --jacoco on gate >>> >>> BTW, if you download an ecj.jar[1] to /mx/ecj.jar, it will be automatically detected and used by the 'mx build' command, removing the need for the --jdt argument. >>> >>> Let me know if you run into any problems or have any further questions. >>> >>> -Doug >>> >>> [1] >>> http://www.eclipse.org/downloads/download.php?file=/eclipse/downloads >>> /drops4/R-4.2.2-201302041200/ecj-4.2.2.jar >>> >>>> -----Original Message----- >>>> From: graal-dev-bounces at openjdk.java.net >>>> [mailto:graal-dev-bounces at openjdk.java.net] On Behalf Of Doug Simon >>>> Sent: Thursday, June 13, 2013 9:04 AM >>>> To: Deneau, Tom >>>> Cc: sumatra-dev at openjdk.java.net; graal-dev at openjdk.java.net >>>> Subject: Re: webrev for Graal HSAIL backend >>>> >>>> Tom, >>>> >>>> It would really help to have this patch broken up into components that can be separately considered for integration. In particular (as Morris stated), having the HSAIL backend (and tests) in Graal would be great so a separate patch for this code would be a good first step. >>>> >>>> One immediate observation is that a lot of the code does not yet import into Eclipse very well. This is the primary tool we use for development and code comprehension so getting the code into Eclipse compliant form would be very helpful in terms of being able to efficiently assess a contribution and offer further feedback. This means: >>>> >>>> o Only use Java 7 language features (Eclipse does not yet support Java 8 language features and it's not clear when it will). >>>> o Remove all Checkstyle warnings (use the eclipse-cs plugin or 'mx checkstyle'). >>>> o Remove all Java warnings (which show up in the Eclipse Problems view). >>>> o Format Java code with the Eclipse formatter (the Eclipse projects generated by 'mx eclipseinit' will ensure the Graal code formatting rules are used). >>>> >>>> It would be useful to have a high level description of the code, broken down by package or collection of packages. This can either be plain text or (preferably) package-info.java files. >>>> >>>> I notice there are files without licenses and some with University of Illinois licenses (the Okra framework). I'm no expert on licensing, but this may causes integration issues. >>>> >>>> The HotSpot changes are probably best to keep in the Sumatra repository for now given their experimental nature. >>>> >>>> I look forward to further progress in terms of getting Sumatra code into Graal - thanks for a good start! >>>> >>>> -Doug >>>> >>>> On Jun 12, 2013, at 5:59 PM, "Deneau, Tom" wrote: >>>> >>>>> Morris -- >>>>> >>>>> Regarding your comments on the hotspot changes in this webrev >>>>> http://cr.openjdk.java.net/~ecaspole/graal_hsail/ >>>>> I wanted to let you know that these hotspot changes really don't >>>>> make sense on their own but co-operate with some JDK changes which >>>>> we will be submitting in a separate webrev to the Sumatra-dev >>>>> repository early next week (these JDK changes are much smaller than the graal changes). >>>>> >>>>> Here is a brief overview of how the pieces fit together... >>>>> >>>>> Basically we wanted the GPU offload programming model to be >>>>> triggered by the programmer using Stream.parallel.forEach(). So the >>>>> JDK changes are really just interceptions of the stream API for parallel forEach. >>>>> The intercept code tests whether the stream meets a few criteria to >>>>> be offloadable, and if so tell graal (thru the Sumatra interface) >>>>> to compile the lambda method to HSAIL and dispatch it. If already >>>>> compiled, it will just be dispatched. Currently we have a >>>>> property, off by default, which tells the JDK intercept code to >>>>> offload immediately. If the offload-immediate flag is set, no >>>>> hotspot changes are really needed. >>>>> >>>>> The hotspot changes just provide an alternate way of enabling the >>>>> offloading (without using the offload-immediate flag) by using the >>>>> compilation of the underlying lambda method as a trigger for >>>>> offloading. They are very experimental and we would welcome >>>>> community input on other ways to do this. >>>>> >>>>> Hope this helps... >>>>> >>>>> -- Tom Deneau >>>>> >>>>> >>>>> >>>>> -----Original Message----- >>>>> From: graal-dev-bounces at openjdk.java.net >>>>> [mailto:graal-dev-bounces at openjdk.java.net] On Behalf Of Morris >>>>> Meyer >>>>> Sent: Tuesday, June 11, 2013 7:17 PM >>>>> To: graal-dev at openjdk.java.net >>>>> Subject: Re: webrev for Graal HSAIL backend >>>>> >>>>> Vasanth, >>>>> >>>>> After seeing Apple's WWDC and the 4,000 core dual-GPU system they >>>>> built into the Mac Pro, I'm very happy to see the work your team >>>>> has put together. Lots of good stuff here and I think we should take most of it. >>>>> >>>>> I like that the HSAIL backend is in the com.oracle.graal namespace >>>>> - not so much as an Oracle engineer - but it will make working and >>>>> refactoring these GPU and CPU backends much easier. Thanks. >>>>> >>>>> compilerBroker.cpp, library_call.cpp, runtime.cpp and arguments.cpp seem >>>>> like the might be a little specialized for this point in time. Very >>>>> interesting changes though. I would like to get the heterogeneous >>>>> method support into HotSpot / Graal and sit down at the language >>>>> summit and discuss how we take on constructs like the ForEach work. >>>>> >>>>> I think com.amd.sumatra.Sumatra is sort of in the right ballpark - >>>>> it echos the change I made to CompilerToGPU in the earlier PTX >>>>> work. I would like of like to reserve the sumatra package for >>>>> lambda work along the lines you are thinking for a collections / lambda oriented >>>>> java.lang.invoke set of code. We need to get the requirements for this >>>>> sort of externalized kernel creating defined as soon as we can. >>>>> Maybe ...bridge.gpu, ...bridge.gpu.hsail, ...bridge.gpu.ptx >>>>> packages in the graal namespace? >>>>> >>>>> I think it might be a good next step to put in the HSAIL back end >>>>> and tests and the emulator working at the gate so we can build and >>>>> verify >>>>> JDK9 / Sumatra / Graal changes in this environment going forward. >>>>> >>>>> I will be working as time permits on the heterogeneous methods and >>>>> PTX invocation so we can get both platforms at the gate integrating changes. >>>>> >>>>> That's all for now. I'm looking forward to working my way through >>>>> all these unit tests. Huge kudos AMD! >>>>> >>>>> --morris meyer >>>>> >>>>> On 6/11/13 6:16 PM, Venkatachalam, Vasanth wrote: >>>>>> Hi, >>>>>> >>>>>> The AMD Sumatra team has submitted a webrev (http://cr.openjdk.java.net/~ecaspole/graal_hsail/) that adds HSAIL code generation support for Graal, allowing Java programs to be compiled and executed on HSAIL-enabled GPU/APU devices. While this work is a prototype, we have included several working unit test cases, including Mandelbrot and NBody. >>>>>> >>>>>> Features >>>>>> >>>>>> Arithmetic operations for integers, longs, doubles, and floats >>>>>> Loads, stores and move operations Min/max/rem/carry operations for >>>>>> integers and longs Conversion operations - (currently support >>>>>> conversions between integers and floats, integers and doubles, integers and longs, floats and doubles). >>>>>> Some math library operations (e.g., square root). >>>>>> Support for JDK8 lambda constructs. >>>>>> >>>>>> Known Issues >>>>>> >>>>>> -The logic to handle register spilling is work-in-progress, so not all test cases that induce spilling are guaranteed to work. >>>>>> -X86 register encodings are being passed to the HSAIL backend. The >>>>>> calling convention returned by getCallingConvention() currently returns an x86 calling convention -Function call support has yet to be implemented. >>>>>> >>>>>> For a detailed list of unsupported features, refer to the routines >>>>>> that are emitting "NYI" in HSAILLIRGenerator.java >>>>>> >>>>>> The test cases (except for BasicHSAILTest) require an HSAIL simulator or hardware to execute, but in lieu of a simulator or hardware they will output the HSAIL code generated, which is useful for debugging. Moreover, BasicHSAILTest provides a template for adding Java code snippets and viewing the HSAIL generated code without executing the code. >>>>>> >>>>>> We encourage the community to support this new backend and extend it with additional features. >>>>>> >>>>>> Vasanth >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>>> >>>> >>>> >>>> >>> >>> >>> >> >> >> > > > From tom.deneau at amd.com Tue Jun 18 16:13:41 2013 From: tom.deneau at amd.com (Deneau, Tom) Date: Tue, 18 Jun 2013 23:13:41 +0000 Subject: update on graal HSAIL backend webrev In-Reply-To: References: <5DD1503F815BD14889DC81D28643E3A73D8DDD0C@sausexdag06.amd.com> <264216FC-2526-4491-B3F6-1358EE24AEFC@oracle.com> <5DD1503F815BD14889DC81D28643E3A73D90950E@sausexdag06.amd.com> <35BBC32B-B2C2-42BE-9A23-EB4EA89AEB82@oracle.com> Message-ID: Never mind, I see how to use it now... -----Original Message----- From: graal-dev-bounces at openjdk.java.net [mailto:graal-dev-bounces at openjdk.java.net] On Behalf Of Deneau, Tom Sent: Tuesday, June 18, 2013 6:08 PM To: Doug Simon; Venkatachalam, Vasanth Cc: graal-dev at openjdk.java.net Subject: RE: update on graal HSAIL backend webrev Is there a Debug.log variant that does not do any formatting? We have generated code we want to log that has embedded % signs. -- Tom -----Original Message----- From: Doug Simon [mailto:doug.simon at oracle.com] Sent: Tuesday, June 18, 2013 4:43 PM To: Venkatachalam, Vasanth Cc: Deneau, Tom; graal-dev at openjdk.java.net Subject: Re: update on graal HSAIL backend webrev You can still see the output of such statements with a '-G:Log=' option. But then you'll also see the output of every other Debug.log() statement. On Jun 18, 2013, at 11:39 PM, "Venkatachalam, Vasanth" wrote: > For the Debug.log statements that aren't within a Debug.scope( ) method, can you explain how to run with logging enabled? > > Vasanth > > -----Original Message----- > From: Doug Simon [mailto:doug.simon at oracle.com] > Sent: Tuesday, June 18, 2013 4:16 PM > To: Deneau, Tom > Cc: Venkatachalam, Vasanth; graal-dev at openjdk.java.net > Subject: Re: update on graal HSAIL backend webrev > > For simple printf-style debugging that you don't plan on checking in, you can keep using System.out and System.err. Even though Checkstyle complains, the code still runs as expected. And having the error is a clear reminder that the temporary printf's must be deleted before checking the code in. > > For longer term log output that you want to check in (and get through the Graal gate), you should use the Debug.log() mechanism. It helps to have the Debug.log() statements are in the (transitive) scope of a Debug.scope() method with a distinct name. E.g.: > > Debug.scope("HSA", new Runnable() { > @Override > public void run() { > // some HSA code... > > Debug.log("hello %s", "world"); > } > } > > Then running with the option -G:Log=HSA. > > -Doug > > On Jun 18, 2013, at 10:42 PM, "Deneau, Tom" wrote: > >> Hi Doug -- >> >> We have some things we would like to log to stdout to help with debugging. >> What is the standard graal way to do this logging? >> >> -- Tom Deneau >> >> >> -----Original Message----- >> From: graal-dev-bounces at openjdk.java.net >> [mailto:graal-dev-bounces at openjdk.java.net] On Behalf Of Doug Simon >> Sent: Tuesday, June 18, 2013 2:33 PM >> To: Venkatachalam, Vasanth >> Cc: graal-dev at openjdk.java.net >> Subject: Re: update on graal HSAIL backend webrev >> >> Hi Vasanth, >> >> Here's a proposal that should allow us to integrate your HSAIL backend changes and tests and avoids all licensing issues. >> >> As I understand it, the HSAIL tests depend on the OKRA framework. If you can make this framework available as a jar located at a publicly available URL, then you can simply specify it as a library dependency for the projects that need it (just like we specify the JUNIT library) in mx/projects. This way, the library will be pulled down and cached locally on demand for running the tests. >> >> In terms of the remaining code, we would like to receive and maintain the Graal HSAIL backend (plus tests) in the Graal repository which only contains JDK7 code and is only tested in a JDK7 environment. >> >> For the JDK8 changes, we propose that they remain in a Sumatra downstream repository. This would include the HotSpot code to do the optional interception on the Streams API. >> >> If this proposal is not acceptable, we're open to further discussion. If it is acceptable, could you please create a JDK7 compliant patch that has the Graal HSAIL backend, the tests for those changes and a dependency on OKRA as an external jar library. >> >> -Doug >> >> On Jun 18, 2013, at 6:27 PM, "Venkatachalam, Vasanth" wrote: >> >>> Hi, >>> >>> I wanted to give an update on our Graal webrev. >>> >>> We have fixed all of the Java warnings and most of the checkstyle errors. The only checkstyle errors that remain are coming from the license header used in two packages ( HSAIL simulator source) that currently require a University of Illinois license, as opposed to the Oracle license which checkstyle is expecting. We are internally discussing how to handle the licensing issue. >>> >>> I ran the three commands the Doug listed: >>> >>> mx clean >>> mx build --jdt /path/to/ecj.jar --jdt-warning-as-error mx checkstyle >>> >>> Aside from the checkstyle warnings mentioned above, there were no issues. However, when using JDK7, mx still tries to build JDK 8 projects, even though their compliance level was specified as Java 8 in mx/projects. I reported this bug on the mailing list. >>> >>> I'd like to propose two possible ways we can submit the revised webrev, and get people's feedback on what's preferable. >>> >>> 1) The easiest approach would be to give you a single webrev encompassing all changes and provide you with adequate documentation that will allow you to be selective in what projects to review. >>> >>> 2) We can split this up into multiple webrevs. However, due to dependencies you will need to apply all the patches to be able to build. The four-way split I propose is as follows: >>> >>> A) Hotspot changes >>> >>> B) Graal changes >>> B1) Infrastructure changes >>> B2) Test cases >>> >>> Let me know what's preferable. If I don't hear from anyone I plan to produce 1) within the next couple of days. >>> >>> Vasanth >>> >>> >>> >>> /home/tester/graalcloneinternal/graal/graal/com.amd.okra/src/com/amd/okra/OkraKernel.java:2: Line does not match expected header line of ' \* Copyright \(c\) (20[0-9][0-9], )?20[0-9][0-9], Oracle and/or its affiliates. All rights reserved.'. >>> /home/tester/graalcloneinternal/graal/graal/com.amd.okra/src/com/amd/okra/OkraContext.java:2: Line does not match expected header line of ' \* Copyright \(c\) (20[0-9][0-9], )?20[0-9][0-9], Oracle and/or its affiliates. All rights reserved.'. >>> /home/tester/graalcloneinternal/graal/graal/com.amd.okra/src/com/amd/okra/OkraOpenCLtoHSAILCompiler.java:2: Line does not match expected header line of ' \* Copyright \(c\) (20[0-9][0-9], )?20[0-9][0-9], Oracle and/or its affiliates. All rights reserved.'. >>> /home/tester/graalcloneinternal/graal/graal/com.amd.okra/src/com/amd/okra/OkraUtil.java:2: Line does not match expected header line of ' \* Copyright \(c\) (20[0-9][0-9], )?20[0-9][0-9], Oracle and/or its affiliates. All rights reserved.'. >>> >>> >>> -----Original Message----- >>> From: Doug Simon [mailto:doug.simon at oracle.com] >>> Sent: Saturday, June 15, 2013 3:20 PM >>> To: Venkatachalam, Vasanth >>> Cc: graal-dev at openjdk.java.net >>> Subject: Re: webrev for Graal HSAIL backend >>> >>> Hi Vasanth, >>> >>> On Jun 14, 2013, at 10:34 PM, "Venkatachalam, Vasanth" wrote: >>> >>>> Hi Doug, >>>> >>>> Thanks for the feedback. We're addressing your comments and had a few questions. >>>> >>>> 1) I'm trying to understand the issue with the formatting. To apply the Eclipse formatter, I first ran mx ideinit, then started eclipse and under projects->properties->Java Code Style->Formatter, I made sure the profile (Unmanaged profile 'Graal') was selected. Is this the correct way to apply the formatter? >>> >>> Yes. The Eclipse project configurations created by eclipseinit should also apply the formatter to any Java file when it is saved. >>> >>>> Can you give an example of some code that wasn't formatted according to these rules? >>> >>> Now that I've looked at the patch in more detail, I can't see any problem in terms of formatting. >>> >>>> 2). The only projects that use JDK8 features are com.amd.sumatra, and com.oracle.graal.compiler.hsail.test.lambda, In mx/projects we have specified that these projects have Java compliance of 1.8, so they shouldn't be compiled if the JDK used is 1.7. It seems like there should be a way for Eclipse to pick up on these changes after running mx ideinit. Are you saying this isn't the case? >>> >>> One problem is that Eclipse doesn't (yet) support JDK8 *language* features such as lambdas. Projects that only use JDK8 library features should be fine. >>> >>> The ideinit command does not consider compliance level when generating Eclipse project configurations - it probably should. And it should probably ignore any projects whose compliance level is >= 8 altogether. Not only does Eclipse not yet support JDK8 anguage features, it cannot yet generate JDK8 class files (the maximum "Compiler compliance level" one can currently set in Eclipse is 1.7). >>> >>> I've just modified the checkstyle command to pay attention to compliance levels. With this change, you should now be able to test your changes for Graal compliance on the command line with these commands: >>> >>> mx clean >>> mx build --jdt /path/to/ecj.jar --jdt-warning-as-error mx checkstyle >>> >>> Once all 3 pass without any warnings or errors, the code should be easier to review and integrate. Note that these commands are part of our gate so we need to get them passing anyway. If you are game, you could try and replicate our complete gate testing with: >>> >>> mx --jacoco on gate >>> >>> BTW, if you download an ecj.jar[1] to /mx/ecj.jar, it will be automatically detected and used by the 'mx build' command, removing the need for the --jdt argument. >>> >>> Let me know if you run into any problems or have any further questions. >>> >>> -Doug >>> >>> [1] >>> http://www.eclipse.org/downloads/download.php?file=/eclipse/downloads >>> /drops4/R-4.2.2-201302041200/ecj-4.2.2.jar >>> >>>> -----Original Message----- >>>> From: graal-dev-bounces at openjdk.java.net >>>> [mailto:graal-dev-bounces at openjdk.java.net] On Behalf Of Doug Simon >>>> Sent: Thursday, June 13, 2013 9:04 AM >>>> To: Deneau, Tom >>>> Cc: sumatra-dev at openjdk.java.net; graal-dev at openjdk.java.net >>>> Subject: Re: webrev for Graal HSAIL backend >>>> >>>> Tom, >>>> >>>> It would really help to have this patch broken up into components that can be separately considered for integration. In particular (as Morris stated), having the HSAIL backend (and tests) in Graal would be great so a separate patch for this code would be a good first step. >>>> >>>> One immediate observation is that a lot of the code does not yet import into Eclipse very well. This is the primary tool we use for development and code comprehension so getting the code into Eclipse compliant form would be very helpful in terms of being able to efficiently assess a contribution and offer further feedback. This means: >>>> >>>> o Only use Java 7 language features (Eclipse does not yet support Java 8 language features and it's not clear when it will). >>>> o Remove all Checkstyle warnings (use the eclipse-cs plugin or 'mx checkstyle'). >>>> o Remove all Java warnings (which show up in the Eclipse Problems view). >>>> o Format Java code with the Eclipse formatter (the Eclipse projects generated by 'mx eclipseinit' will ensure the Graal code formatting rules are used). >>>> >>>> It would be useful to have a high level description of the code, broken down by package or collection of packages. This can either be plain text or (preferably) package-info.java files. >>>> >>>> I notice there are files without licenses and some with University of Illinois licenses (the Okra framework). I'm no expert on licensing, but this may causes integration issues. >>>> >>>> The HotSpot changes are probably best to keep in the Sumatra repository for now given their experimental nature. >>>> >>>> I look forward to further progress in terms of getting Sumatra code into Graal - thanks for a good start! >>>> >>>> -Doug >>>> >>>> On Jun 12, 2013, at 5:59 PM, "Deneau, Tom" wrote: >>>> >>>>> Morris -- >>>>> >>>>> Regarding your comments on the hotspot changes in this webrev >>>>> http://cr.openjdk.java.net/~ecaspole/graal_hsail/ >>>>> I wanted to let you know that these hotspot changes really don't >>>>> make sense on their own but co-operate with some JDK changes which >>>>> we will be submitting in a separate webrev to the Sumatra-dev >>>>> repository early next week (these JDK changes are much smaller than the graal changes). >>>>> >>>>> Here is a brief overview of how the pieces fit together... >>>>> >>>>> Basically we wanted the GPU offload programming model to be >>>>> triggered by the programmer using Stream.parallel.forEach(). So the >>>>> JDK changes are really just interceptions of the stream API for parallel forEach. >>>>> The intercept code tests whether the stream meets a few criteria to >>>>> be offloadable, and if so tell graal (thru the Sumatra interface) >>>>> to compile the lambda method to HSAIL and dispatch it. If already >>>>> compiled, it will just be dispatched. Currently we have a >>>>> property, off by default, which tells the JDK intercept code to >>>>> offload immediately. If the offload-immediate flag is set, no >>>>> hotspot changes are really needed. >>>>> >>>>> The hotspot changes just provide an alternate way of enabling the >>>>> offloading (without using the offload-immediate flag) by using the >>>>> compilation of the underlying lambda method as a trigger for >>>>> offloading. They are very experimental and we would welcome >>>>> community input on other ways to do this. >>>>> >>>>> Hope this helps... >>>>> >>>>> -- Tom Deneau >>>>> >>>>> >>>>> >>>>> -----Original Message----- >>>>> From: graal-dev-bounces at openjdk.java.net >>>>> [mailto:graal-dev-bounces at openjdk.java.net] On Behalf Of Morris >>>>> Meyer >>>>> Sent: Tuesday, June 11, 2013 7:17 PM >>>>> To: graal-dev at openjdk.java.net >>>>> Subject: Re: webrev for Graal HSAIL backend >>>>> >>>>> Vasanth, >>>>> >>>>> After seeing Apple's WWDC and the 4,000 core dual-GPU system they >>>>> built into the Mac Pro, I'm very happy to see the work your team >>>>> has put together. Lots of good stuff here and I think we should take most of it. >>>>> >>>>> I like that the HSAIL backend is in the com.oracle.graal namespace >>>>> - not so much as an Oracle engineer - but it will make working and >>>>> refactoring these GPU and CPU backends much easier. Thanks. >>>>> >>>>> compilerBroker.cpp, library_call.cpp, runtime.cpp and arguments.cpp seem >>>>> like the might be a little specialized for this point in time. Very >>>>> interesting changes though. I would like to get the heterogeneous >>>>> method support into HotSpot / Graal and sit down at the language >>>>> summit and discuss how we take on constructs like the ForEach work. >>>>> >>>>> I think com.amd.sumatra.Sumatra is sort of in the right ballpark - >>>>> it echos the change I made to CompilerToGPU in the earlier PTX >>>>> work. I would like of like to reserve the sumatra package for >>>>> lambda work along the lines you are thinking for a collections / lambda oriented >>>>> java.lang.invoke set of code. We need to get the requirements for this >>>>> sort of externalized kernel creating defined as soon as we can. >>>>> Maybe ...bridge.gpu, ...bridge.gpu.hsail, ...bridge.gpu.ptx >>>>> packages in the graal namespace? >>>>> >>>>> I think it might be a good next step to put in the HSAIL back end >>>>> and tests and the emulator working at the gate so we can build and >>>>> verify >>>>> JDK9 / Sumatra / Graal changes in this environment going forward. >>>>> >>>>> I will be working as time permits on the heterogeneous methods and >>>>> PTX invocation so we can get both platforms at the gate integrating changes. >>>>> >>>>> That's all for now. I'm looking forward to working my way through >>>>> all these unit tests. Huge kudos AMD! >>>>> >>>>> --morris meyer >>>>> >>>>> On 6/11/13 6:16 PM, Venkatachalam, Vasanth wrote: >>>>>> Hi, >>>>>> >>>>>> The AMD Sumatra team has submitted a webrev (http://cr.openjdk.java.net/~ecaspole/graal_hsail/) that adds HSAIL code generation support for Graal, allowing Java programs to be compiled and executed on HSAIL-enabled GPU/APU devices. While this work is a prototype, we have included several working unit test cases, including Mandelbrot and NBody. >>>>>> >>>>>> Features >>>>>> >>>>>> Arithmetic operations for integers, longs, doubles, and floats >>>>>> Loads, stores and move operations Min/max/rem/carry operations for >>>>>> integers and longs Conversion operations - (currently support >>>>>> conversions between integers and floats, integers and doubles, integers and longs, floats and doubles). >>>>>> Some math library operations (e.g., square root). >>>>>> Support for JDK8 lambda constructs. >>>>>> >>>>>> Known Issues >>>>>> >>>>>> -The logic to handle register spilling is work-in-progress, so not all test cases that induce spilling are guaranteed to work. >>>>>> -X86 register encodings are being passed to the HSAIL backend. The >>>>>> calling convention returned by getCallingConvention() currently returns an x86 calling convention -Function call support has yet to be implemented. >>>>>> >>>>>> For a detailed list of unsupported features, refer to the routines >>>>>> that are emitting "NYI" in HSAILLIRGenerator.java >>>>>> >>>>>> The test cases (except for BasicHSAILTest) require an HSAIL simulator or hardware to execute, but in lieu of a simulator or hardware they will output the HSAIL code generated, which is useful for debugging. Moreover, BasicHSAILTest provides a template for adding Java code snippets and viewing the HSAIL generated code without executing the code. >>>>>> >>>>>> We encourage the community to support this new backend and extend it with additional features. >>>>>> >>>>>> Vasanth >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>>> >>>> >>>> >>>> >>> >>> >>> >> >> >> > > > From christian.thalinger at oracle.com Tue Jun 18 16:28:10 2013 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Tue, 18 Jun 2013 16:28:10 -0700 Subject: update on graal HSAIL backend webrev In-Reply-To: References: <5DD1503F815BD14889DC81D28643E3A73D8DDD0C@sausexdag06.amd.com> <264216FC-2526-4491-B3F6-1358EE24AEFC@oracle.com> <5DD1503F815BD14889DC81D28643E3A73D90950E@sausexdag06.amd.com> <35BBC32B-B2C2-42BE-9A23-EB4EA89AEB82@oracle.com> Message-ID: <3ADE8546-5FDB-4657-B402-24D00B06214B@oracle.com> On Jun 18, 2013, at 4:08 PM, "Deneau, Tom" wrote: > Is there a Debug.log variant that does not do any formatting? > We have generated code we want to log that has embedded % signs. Debug.log uses String.format so a "%%" should do it. -- Chris > > -- Tom > > > -----Original Message----- > From: Doug Simon [mailto:doug.simon at oracle.com] > Sent: Tuesday, June 18, 2013 4:43 PM > To: Venkatachalam, Vasanth > Cc: Deneau, Tom; graal-dev at openjdk.java.net > Subject: Re: update on graal HSAIL backend webrev > > You can still see the output of such statements with a '-G:Log=' option. But then you'll also see the output of every other Debug.log() statement. > > On Jun 18, 2013, at 11:39 PM, "Venkatachalam, Vasanth" wrote: > >> For the Debug.log statements that aren't within a Debug.scope( ) method, can you explain how to run with logging enabled? >> >> Vasanth >> >> -----Original Message----- >> From: Doug Simon [mailto:doug.simon at oracle.com] >> Sent: Tuesday, June 18, 2013 4:16 PM >> To: Deneau, Tom >> Cc: Venkatachalam, Vasanth; graal-dev at openjdk.java.net >> Subject: Re: update on graal HSAIL backend webrev >> >> For simple printf-style debugging that you don't plan on checking in, you can keep using System.out and System.err. Even though Checkstyle complains, the code still runs as expected. And having the error is a clear reminder that the temporary printf's must be deleted before checking the code in. >> >> For longer term log output that you want to check in (and get through the Graal gate), you should use the Debug.log() mechanism. It helps to have the Debug.log() statements are in the (transitive) scope of a Debug.scope() method with a distinct name. E.g.: >> >> Debug.scope("HSA", new Runnable() { >> @Override >> public void run() { >> // some HSA code... >> >> Debug.log("hello %s", "world"); >> } >> } >> >> Then running with the option -G:Log=HSA. >> >> -Doug >> >> On Jun 18, 2013, at 10:42 PM, "Deneau, Tom" wrote: >> >>> Hi Doug -- >>> >>> We have some things we would like to log to stdout to help with debugging. >>> What is the standard graal way to do this logging? >>> >>> -- Tom Deneau >>> >>> >>> -----Original Message----- >>> From: graal-dev-bounces at openjdk.java.net >>> [mailto:graal-dev-bounces at openjdk.java.net] On Behalf Of Doug Simon >>> Sent: Tuesday, June 18, 2013 2:33 PM >>> To: Venkatachalam, Vasanth >>> Cc: graal-dev at openjdk.java.net >>> Subject: Re: update on graal HSAIL backend webrev >>> >>> Hi Vasanth, >>> >>> Here's a proposal that should allow us to integrate your HSAIL backend changes and tests and avoids all licensing issues. >>> >>> As I understand it, the HSAIL tests depend on the OKRA framework. If you can make this framework available as a jar located at a publicly available URL, then you can simply specify it as a library dependency for the projects that need it (just like we specify the JUNIT library) in mx/projects. This way, the library will be pulled down and cached locally on demand for running the tests. >>> >>> In terms of the remaining code, we would like to receive and maintain the Graal HSAIL backend (plus tests) in the Graal repository which only contains JDK7 code and is only tested in a JDK7 environment. >>> >>> For the JDK8 changes, we propose that they remain in a Sumatra downstream repository. This would include the HotSpot code to do the optional interception on the Streams API. >>> >>> If this proposal is not acceptable, we're open to further discussion. If it is acceptable, could you please create a JDK7 compliant patch that has the Graal HSAIL backend, the tests for those changes and a dependency on OKRA as an external jar library. >>> >>> -Doug >>> >>> On Jun 18, 2013, at 6:27 PM, "Venkatachalam, Vasanth" wrote: >>> >>>> Hi, >>>> >>>> I wanted to give an update on our Graal webrev. >>>> >>>> We have fixed all of the Java warnings and most of the checkstyle errors. The only checkstyle errors that remain are coming from the license header used in two packages ( HSAIL simulator source) that currently require a University of Illinois license, as opposed to the Oracle license which checkstyle is expecting. We are internally discussing how to handle the licensing issue. >>>> >>>> I ran the three commands the Doug listed: >>>> >>>> mx clean >>>> mx build --jdt /path/to/ecj.jar --jdt-warning-as-error mx checkstyle >>>> >>>> Aside from the checkstyle warnings mentioned above, there were no issues. However, when using JDK7, mx still tries to build JDK 8 projects, even though their compliance level was specified as Java 8 in mx/projects. I reported this bug on the mailing list. >>>> >>>> I'd like to propose two possible ways we can submit the revised webrev, and get people's feedback on what's preferable. >>>> >>>> 1) The easiest approach would be to give you a single webrev encompassing all changes and provide you with adequate documentation that will allow you to be selective in what projects to review. >>>> >>>> 2) We can split this up into multiple webrevs. However, due to dependencies you will need to apply all the patches to be able to build. The four-way split I propose is as follows: >>>> >>>> A) Hotspot changes >>>> >>>> B) Graal changes >>>> B1) Infrastructure changes >>>> B2) Test cases >>>> >>>> Let me know what's preferable. If I don't hear from anyone I plan to produce 1) within the next couple of days. >>>> >>>> Vasanth >>>> >>>> >>>> >>>> /home/tester/graalcloneinternal/graal/graal/com.amd.okra/src/com/amd/okra/OkraKernel.java:2: Line does not match expected header line of ' \* Copyright \(c\) (20[0-9][0-9], )?20[0-9][0-9], Oracle and/or its affiliates. All rights reserved.'. >>>> /home/tester/graalcloneinternal/graal/graal/com.amd.okra/src/com/amd/okra/OkraContext.java:2: Line does not match expected header line of ' \* Copyright \(c\) (20[0-9][0-9], )?20[0-9][0-9], Oracle and/or its affiliates. All rights reserved.'. >>>> /home/tester/graalcloneinternal/graal/graal/com.amd.okra/src/com/amd/okra/OkraOpenCLtoHSAILCompiler.java:2: Line does not match expected header line of ' \* Copyright \(c\) (20[0-9][0-9], )?20[0-9][0-9], Oracle and/or its affiliates. All rights reserved.'. >>>> /home/tester/graalcloneinternal/graal/graal/com.amd.okra/src/com/amd/okra/OkraUtil.java:2: Line does not match expected header line of ' \* Copyright \(c\) (20[0-9][0-9], )?20[0-9][0-9], Oracle and/or its affiliates. All rights reserved.'. >>>> >>>> >>>> -----Original Message----- >>>> From: Doug Simon [mailto:doug.simon at oracle.com] >>>> Sent: Saturday, June 15, 2013 3:20 PM >>>> To: Venkatachalam, Vasanth >>>> Cc: graal-dev at openjdk.java.net >>>> Subject: Re: webrev for Graal HSAIL backend >>>> >>>> Hi Vasanth, >>>> >>>> On Jun 14, 2013, at 10:34 PM, "Venkatachalam, Vasanth" wrote: >>>> >>>>> Hi Doug, >>>>> >>>>> Thanks for the feedback. We're addressing your comments and had a few questions. >>>>> >>>>> 1) I'm trying to understand the issue with the formatting. To apply the Eclipse formatter, I first ran mx ideinit, then started eclipse and under projects->properties->Java Code Style->Formatter, I made sure the profile (Unmanaged profile 'Graal') was selected. Is this the correct way to apply the formatter? >>>> >>>> Yes. The Eclipse project configurations created by eclipseinit should also apply the formatter to any Java file when it is saved. >>>> >>>>> Can you give an example of some code that wasn't formatted according to these rules? >>>> >>>> Now that I've looked at the patch in more detail, I can't see any problem in terms of formatting. >>>> >>>>> 2). The only projects that use JDK8 features are com.amd.sumatra, and com.oracle.graal.compiler.hsail.test.lambda, In mx/projects we have specified that these projects have Java compliance of 1.8, so they shouldn't be compiled if the JDK used is 1.7. It seems like there should be a way for Eclipse to pick up on these changes after running mx ideinit. Are you saying this isn't the case? >>>> >>>> One problem is that Eclipse doesn't (yet) support JDK8 *language* features such as lambdas. Projects that only use JDK8 library features should be fine. >>>> >>>> The ideinit command does not consider compliance level when generating Eclipse project configurations - it probably should. And it should probably ignore any projects whose compliance level is >= 8 altogether. Not only does Eclipse not yet support JDK8 anguage features, it cannot yet generate JDK8 class files (the maximum "Compiler compliance level" one can currently set in Eclipse is 1.7). >>>> >>>> I've just modified the checkstyle command to pay attention to compliance levels. With this change, you should now be able to test your changes for Graal compliance on the command line with these commands: >>>> >>>> mx clean >>>> mx build --jdt /path/to/ecj.jar --jdt-warning-as-error mx checkstyle >>>> >>>> Once all 3 pass without any warnings or errors, the code should be easier to review and integrate. Note that these commands are part of our gate so we need to get them passing anyway. If you are game, you could try and replicate our complete gate testing with: >>>> >>>> mx --jacoco on gate >>>> >>>> BTW, if you download an ecj.jar[1] to /mx/ecj.jar, it will be automatically detected and used by the 'mx build' command, removing the need for the --jdt argument. >>>> >>>> Let me know if you run into any problems or have any further questions. >>>> >>>> -Doug >>>> >>>> [1] >>>> http://www.eclipse.org/downloads/download.php?file=/eclipse/downloads >>>> /drops4/R-4.2.2-201302041200/ecj-4.2.2.jar >>>> >>>>> -----Original Message----- >>>>> From: graal-dev-bounces at openjdk.java.net >>>>> [mailto:graal-dev-bounces at openjdk.java.net] On Behalf Of Doug Simon >>>>> Sent: Thursday, June 13, 2013 9:04 AM >>>>> To: Deneau, Tom >>>>> Cc: sumatra-dev at openjdk.java.net; graal-dev at openjdk.java.net >>>>> Subject: Re: webrev for Graal HSAIL backend >>>>> >>>>> Tom, >>>>> >>>>> It would really help to have this patch broken up into components that can be separately considered for integration. In particular (as Morris stated), having the HSAIL backend (and tests) in Graal would be great so a separate patch for this code would be a good first step. >>>>> >>>>> One immediate observation is that a lot of the code does not yet import into Eclipse very well. This is the primary tool we use for development and code comprehension so getting the code into Eclipse compliant form would be very helpful in terms of being able to efficiently assess a contribution and offer further feedback. This means: >>>>> >>>>> o Only use Java 7 language features (Eclipse does not yet support Java 8 language features and it's not clear when it will). >>>>> o Remove all Checkstyle warnings (use the eclipse-cs plugin or 'mx checkstyle'). >>>>> o Remove all Java warnings (which show up in the Eclipse Problems view). >>>>> o Format Java code with the Eclipse formatter (the Eclipse projects generated by 'mx eclipseinit' will ensure the Graal code formatting rules are used). >>>>> >>>>> It would be useful to have a high level description of the code, broken down by package or collection of packages. This can either be plain text or (preferably) package-info.java files. >>>>> >>>>> I notice there are files without licenses and some with University of Illinois licenses (the Okra framework). I'm no expert on licensing, but this may causes integration issues. >>>>> >>>>> The HotSpot changes are probably best to keep in the Sumatra repository for now given their experimental nature. >>>>> >>>>> I look forward to further progress in terms of getting Sumatra code into Graal - thanks for a good start! >>>>> >>>>> -Doug >>>>> >>>>> On Jun 12, 2013, at 5:59 PM, "Deneau, Tom" wrote: >>>>> >>>>>> Morris -- >>>>>> >>>>>> Regarding your comments on the hotspot changes in this webrev >>>>>> http://cr.openjdk.java.net/~ecaspole/graal_hsail/ >>>>>> I wanted to let you know that these hotspot changes really don't >>>>>> make sense on their own but co-operate with some JDK changes which >>>>>> we will be submitting in a separate webrev to the Sumatra-dev >>>>>> repository early next week (these JDK changes are much smaller than the graal changes). >>>>>> >>>>>> Here is a brief overview of how the pieces fit together... >>>>>> >>>>>> Basically we wanted the GPU offload programming model to be >>>>>> triggered by the programmer using Stream.parallel.forEach(). So the >>>>>> JDK changes are really just interceptions of the stream API for parallel forEach. >>>>>> The intercept code tests whether the stream meets a few criteria to >>>>>> be offloadable, and if so tell graal (thru the Sumatra interface) >>>>>> to compile the lambda method to HSAIL and dispatch it. If already >>>>>> compiled, it will just be dispatched. Currently we have a >>>>>> property, off by default, which tells the JDK intercept code to >>>>>> offload immediately. If the offload-immediate flag is set, no >>>>>> hotspot changes are really needed. >>>>>> >>>>>> The hotspot changes just provide an alternate way of enabling the >>>>>> offloading (without using the offload-immediate flag) by using the >>>>>> compilation of the underlying lambda method as a trigger for >>>>>> offloading. They are very experimental and we would welcome >>>>>> community input on other ways to do this. >>>>>> >>>>>> Hope this helps... >>>>>> >>>>>> -- Tom Deneau >>>>>> >>>>>> >>>>>> >>>>>> -----Original Message----- >>>>>> From: graal-dev-bounces at openjdk.java.net >>>>>> [mailto:graal-dev-bounces at openjdk.java.net] On Behalf Of Morris >>>>>> Meyer >>>>>> Sent: Tuesday, June 11, 2013 7:17 PM >>>>>> To: graal-dev at openjdk.java.net >>>>>> Subject: Re: webrev for Graal HSAIL backend >>>>>> >>>>>> Vasanth, >>>>>> >>>>>> After seeing Apple's WWDC and the 4,000 core dual-GPU system they >>>>>> built into the Mac Pro, I'm very happy to see the work your team >>>>>> has put together. Lots of good stuff here and I think we should take most of it. >>>>>> >>>>>> I like that the HSAIL backend is in the com.oracle.graal namespace >>>>>> - not so much as an Oracle engineer - but it will make working and >>>>>> refactoring these GPU and CPU backends much easier. Thanks. >>>>>> >>>>>> compilerBroker.cpp, library_call.cpp, runtime.cpp and arguments.cpp seem >>>>>> like the might be a little specialized for this point in time. Very >>>>>> interesting changes though. I would like to get the heterogeneous >>>>>> method support into HotSpot / Graal and sit down at the language >>>>>> summit and discuss how we take on constructs like the ForEach work. >>>>>> >>>>>> I think com.amd.sumatra.Sumatra is sort of in the right ballpark - >>>>>> it echos the change I made to CompilerToGPU in the earlier PTX >>>>>> work. I would like of like to reserve the sumatra package for >>>>>> lambda work along the lines you are thinking for a collections / lambda oriented >>>>>> java.lang.invoke set of code. We need to get the requirements for this >>>>>> sort of externalized kernel creating defined as soon as we can. >>>>>> Maybe ...bridge.gpu, ...bridge.gpu.hsail, ...bridge.gpu.ptx >>>>>> packages in the graal namespace? >>>>>> >>>>>> I think it might be a good next step to put in the HSAIL back end >>>>>> and tests and the emulator working at the gate so we can build and >>>>>> verify >>>>>> JDK9 / Sumatra / Graal changes in this environment going forward. >>>>>> >>>>>> I will be working as time permits on the heterogeneous methods and >>>>>> PTX invocation so we can get both platforms at the gate integrating changes. >>>>>> >>>>>> That's all for now. I'm looking forward to working my way through >>>>>> all these unit tests. Huge kudos AMD! >>>>>> >>>>>> --morris meyer >>>>>> >>>>>> On 6/11/13 6:16 PM, Venkatachalam, Vasanth wrote: >>>>>>> Hi, >>>>>>> >>>>>>> The AMD Sumatra team has submitted a webrev (http://cr.openjdk.java.net/~ecaspole/graal_hsail/) that adds HSAIL code generation support for Graal, allowing Java programs to be compiled and executed on HSAIL-enabled GPU/APU devices. While this work is a prototype, we have included several working unit test cases, including Mandelbrot and NBody. >>>>>>> >>>>>>> Features >>>>>>> >>>>>>> Arithmetic operations for integers, longs, doubles, and floats >>>>>>> Loads, stores and move operations Min/max/rem/carry operations for >>>>>>> integers and longs Conversion operations - (currently support >>>>>>> conversions between integers and floats, integers and doubles, integers and longs, floats and doubles). >>>>>>> Some math library operations (e.g., square root). >>>>>>> Support for JDK8 lambda constructs. >>>>>>> >>>>>>> Known Issues >>>>>>> >>>>>>> -The logic to handle register spilling is work-in-progress, so not all test cases that induce spilling are guaranteed to work. >>>>>>> -X86 register encodings are being passed to the HSAIL backend. The >>>>>>> calling convention returned by getCallingConvention() currently returns an x86 calling convention -Function call support has yet to be implemented. >>>>>>> >>>>>>> For a detailed list of unsupported features, refer to the routines >>>>>>> that are emitting "NYI" in HSAILLIRGenerator.java >>>>>>> >>>>>>> The test cases (except for BasicHSAILTest) require an HSAIL simulator or hardware to execute, but in lieu of a simulator or hardware they will output the HSAIL code generated, which is useful for debugging. Moreover, BasicHSAILTest provides a template for adding Java code snippets and viewing the HSAIL generated code without executing the code. >>>>>>> >>>>>>> We encourage the community to support this new backend and extend it with additional features. >>>>>>> >>>>>>> Vasanth >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>>> >>>> >>>> >>>> >>> >>> >>> >> >> >> > > > From tom.deneau at amd.com Wed Jun 19 06:07:07 2013 From: tom.deneau at amd.com (Deneau, Tom) Date: Wed, 19 Jun 2013 13:07:07 +0000 Subject: conditional move References: <94EEBC17-CD7A-4881-9C33-A05E6C65487C@jku.at> <7D18ADF6-5118-448F-ADEB-E0061337E07A@oracle.com> Message-ID: Wondering whether anyone knows the reason for the problem below? For the HSAIL backend, we would like both to emit conditional moves. Is there a backend property that enables this? -- Tom -----Original Message----- From: Deneau, Tom Sent: Friday, May 24, 2013 6:42 PM To: 'Doug Simon'; Frost, Gary Cc: Lukas Stadler; graal-dev at openjdk.java.net Subject: RE: conditional move I noticed that this code emits a Conditional Move node public int test(int a, int b) { return (a < b ? 1 : 2); } but this one does not public float test(int a, int b) { return (a < b ? 1.0f : 2.0f); } -- Tom -----Original Message----- From: Doug Simon [mailto:doug.simon at oracle.com] Sent: Friday, May 24, 2013 10:28 AM To: Frost, Gary Cc: Lukas Stadler; Deneau, Tom; graal-dev at openjdk.java.net Subject: Re: conditional move Yes, because ternaries are compiled by javac as if-statements. On May 24, 2013, at 5:17 PM, "Frost, Gary" wrote: > Presumably, ternaries are good candidates for this. > > boolean isOdd(int i){ > boolean odd=((i%2)!=0)?0:1; > return odd; > } > > -----Original Message----- > From: graal-dev-bounces at openjdk.java.net [mailto:graal-dev-bounces at openjdk.java.net] On Behalf Of Lukas Stadler > Sent: Friday, May 24, 2013 3:51 AM > To: Deneau, Tom > Cc: graal-dev at openjdk.java.net > Subject: Re: conditional move > > The ConditionalNode is most of the time not created by the GraphBuilder directly, but it will appear later when a simple if/then/else is canonicalized. > So a simple snippet that boils down to a conditional move could look like this: > > public static int testSnippet(int i) { > if (i == 0) { > return 1; > } else { > return 2; > } > } > > - Lukas > > > On May 24, 2013, at 1:04 AM, "Deneau, Tom" wrote: > >> While compiling a larger chunk of code we were handed a >> ConditionalMove node (which we have not implemented yet). I would >> like to make a smaller test case for this but java patterns that I >> thought would be mapping to conditional move aren't doing so. What >> would be a typical small test case for generating the ConditionalMove node? >> >> -- Tom Deneau >> > > > From lukas.stadler at jku.at Wed Jun 19 06:19:46 2013 From: lukas.stadler at jku.at (Lukas Stadler) Date: Wed, 19 Jun 2013 15:19:46 +0200 Subject: conditional move In-Reply-To: References: <94EEBC17-CD7A-4881-9C33-A05E6C65487C@jku.at> <7D18ADF6-5118-448F-ADEB-E0061337E07A@oracle.com> Message-ID: There's a heuristic in the canonicalization of IfNodes that says that it is only beneficial to create a ConditionalNode if the two values are constant integers or constant longs. You can see it in IfNode.removeOrMaterializeIf. This restriction on types is AMD64 - specific, and I think we should remove it anyway. (because the only downside could be that we have to create the if again at a lower level). The restriction on constants, however, makes sense - because if we need to do work to calculate the values then this work should happen only if we need it. - Lukas On Jun 19, 2013, at 3:07 PM, "Deneau, Tom" wrote: > Wondering whether anyone knows the reason for the problem below? > For the HSAIL backend, we would like both to emit conditional moves. > Is there a backend property that enables this? > > -- Tom > > > -----Original Message----- > From: Deneau, Tom > Sent: Friday, May 24, 2013 6:42 PM > To: 'Doug Simon'; Frost, Gary > Cc: Lukas Stadler; graal-dev at openjdk.java.net > Subject: RE: conditional move > > I noticed that this code emits a Conditional Move node > > public int test(int a, int b) { > return (a < b ? 1 : 2); > } > > but this one does not > public float test(int a, int b) { > return (a < b ? 1.0f : 2.0f); > } > > -- Tom > > -----Original Message----- > From: Doug Simon [mailto:doug.simon at oracle.com] > Sent: Friday, May 24, 2013 10:28 AM > To: Frost, Gary > Cc: Lukas Stadler; Deneau, Tom; graal-dev at openjdk.java.net > Subject: Re: conditional move > > Yes, because ternaries are compiled by javac as if-statements. > > On May 24, 2013, at 5:17 PM, "Frost, Gary" wrote: > >> Presumably, ternaries are good candidates for this. >> >> boolean isOdd(int i){ >> boolean odd=((i%2)!=0)?0:1; >> return odd; >> } >> >> -----Original Message----- >> From: graal-dev-bounces at openjdk.java.net [mailto:graal-dev-bounces at openjdk.java.net] On Behalf Of Lukas Stadler >> Sent: Friday, May 24, 2013 3:51 AM >> To: Deneau, Tom >> Cc: graal-dev at openjdk.java.net >> Subject: Re: conditional move >> >> The ConditionalNode is most of the time not created by the GraphBuilder directly, but it will appear later when a simple if/then/else is canonicalized. >> So a simple snippet that boils down to a conditional move could look like this: >> >> public static int testSnippet(int i) { >> if (i == 0) { >> return 1; >> } else { >> return 2; >> } >> } >> >> - Lukas >> >> >> On May 24, 2013, at 1:04 AM, "Deneau, Tom" wrote: >> >>> While compiling a larger chunk of code we were handed a >>> ConditionalMove node (which we have not implemented yet). I would >>> like to make a smaller test case for this but java patterns that I >>> thought would be mapping to conditional move aren't doing so. What >>> would be a typical small test case for generating the ConditionalMove node? >>> >>> -- Tom Deneau >>> >> >> >> > > > From duboscq at ssw.jku.at Wed Jun 19 06:25:16 2013 From: duboscq at ssw.jku.at (Gilles Duboscq) Date: Wed, 19 Jun 2013 15:25:16 +0200 Subject: conditional move In-Reply-To: References: <94EEBC17-CD7A-4881-9C33-A05E6C65487C@jku.at> <7D18ADF6-5118-448F-ADEB-E0061337E07A@oracle.com> Message-ID: I think that we should rather always go for ConditionalNodes, it should then be a backend specific decision about how to optimally compute them. But in this case we would need a backend specific phase near that does the correct transformation. On Wed, Jun 19, 2013 at 3:19 PM, Lukas Stadler wrote: > There's a heuristic in the canonicalization of IfNodes that says that it > is only beneficial to create a ConditionalNode if the two values are > constant integers or constant longs. > You can see it in IfNode.removeOrMaterializeIf. This restriction on types > is AMD64 - specific, and I think we should remove it anyway. > (because the only downside could be that we have to create the if again at > a lower level). > > The restriction on constants, however, makes sense - because if we need to > do work to calculate the values then this work should happen only if we > need it. > > - Lukas > > On Jun 19, 2013, at 3:07 PM, "Deneau, Tom" wrote: > > > Wondering whether anyone knows the reason for the problem below? > > For the HSAIL backend, we would like both to emit conditional moves. > > Is there a backend property that enables this? > > > > -- Tom > > > > > > -----Original Message----- > > From: Deneau, Tom > > Sent: Friday, May 24, 2013 6:42 PM > > To: 'Doug Simon'; Frost, Gary > > Cc: Lukas Stadler; graal-dev at openjdk.java.net > > Subject: RE: conditional move > > > > I noticed that this code emits a Conditional Move node > > > > public int test(int a, int b) { > > return (a < b ? 1 : 2); > > } > > > > but this one does not > > public float test(int a, int b) { > > return (a < b ? 1.0f : 2.0f); > > } > > > > -- Tom > > > > -----Original Message----- > > From: Doug Simon [mailto:doug.simon at oracle.com] > > Sent: Friday, May 24, 2013 10:28 AM > > To: Frost, Gary > > Cc: Lukas Stadler; Deneau, Tom; graal-dev at openjdk.java.net > > Subject: Re: conditional move > > > > Yes, because ternaries are compiled by javac as if-statements. > > > > On May 24, 2013, at 5:17 PM, "Frost, Gary" wrote: > > > >> Presumably, ternaries are good candidates for this. > >> > >> boolean isOdd(int i){ > >> boolean odd=((i%2)!=0)?0:1; > >> return odd; > >> } > >> > >> -----Original Message----- > >> From: graal-dev-bounces at openjdk.java.net [mailto: > graal-dev-bounces at openjdk.java.net] On Behalf Of Lukas Stadler > >> Sent: Friday, May 24, 2013 3:51 AM > >> To: Deneau, Tom > >> Cc: graal-dev at openjdk.java.net > >> Subject: Re: conditional move > >> > >> The ConditionalNode is most of the time not created by the GraphBuilder > directly, but it will appear later when a simple if/then/else is > canonicalized. > >> So a simple snippet that boils down to a conditional move could look > like this: > >> > >> public static int testSnippet(int i) { > >> if (i == 0) { > >> return 1; > >> } else { > >> return 2; > >> } > >> } > >> > >> - Lukas > >> > >> > >> On May 24, 2013, at 1:04 AM, "Deneau, Tom" wrote: > >> > >>> While compiling a larger chunk of code we were handed a > >>> ConditionalMove node (which we have not implemented yet). I would > >>> like to make a smaller test case for this but java patterns that I > >>> thought would be mapping to conditional move aren't doing so. What > >>> would be a typical small test case for generating the ConditionalMove > node? > >>> > >>> -- Tom Deneau > >>> > >> > >> > >> > > > > > > > > From tom.deneau at amd.com Wed Jun 19 08:05:24 2013 From: tom.deneau at amd.com (Deneau, Tom) Date: Wed, 19 Jun 2013 15:05:24 +0000 Subject: conditional move In-Reply-To: References: <94EEBC17-CD7A-4881-9C33-A05E6C65487C@jku.at> <7D18ADF6-5118-448F-ADEB-E0061337E07A@oracle.com> Message-ID: I have confirmed that if this restriction in IfNode is commented out, we do in the HSAIL backend generate conditional moves for the float code using constants below. Restricting to constants might be too strict, I can imagine cases where the alternatives are not constants but have already been calculated so no additional work is needed. Or as Gilles said perhaps in all cases the backend should decide whether any additional work outweighs the benefit of the conditional move (or more pessimistically the penalty of the branch). -- Tom -----Original Message----- From: Lukas Stadler [mailto:lukas.stadler at jku.at] Sent: Wednesday, June 19, 2013 8:20 AM To: Deneau, Tom Cc: graal-dev at openjdk.java.net Subject: Re: conditional move There's a heuristic in the canonicalization of IfNodes that says that it is only beneficial to create a ConditionalNode if the two values are constant integers or constant longs. You can see it in IfNode.removeOrMaterializeIf. This restriction on types is AMD64 - specific, and I think we should remove it anyway. (because the only downside could be that we have to create the if again at a lower level). The restriction on constants, however, makes sense - because if we need to do work to calculate the values then this work should happen only if we need it. - Lukas On Jun 19, 2013, at 3:07 PM, "Deneau, Tom" wrote: > Wondering whether anyone knows the reason for the problem below? > For the HSAIL backend, we would like both to emit conditional moves. > Is there a backend property that enables this? > > -- Tom > > > -----Original Message----- > From: Deneau, Tom > Sent: Friday, May 24, 2013 6:42 PM > To: 'Doug Simon'; Frost, Gary > Cc: Lukas Stadler; graal-dev at openjdk.java.net > Subject: RE: conditional move > > I noticed that this code emits a Conditional Move node > > public int test(int a, int b) { > return (a < b ? 1 : 2); > } > > but this one does not > public float test(int a, int b) { > return (a < b ? 1.0f : 2.0f); > } > > -- Tom > > -----Original Message----- > From: Doug Simon [mailto:doug.simon at oracle.com] > Sent: Friday, May 24, 2013 10:28 AM > To: Frost, Gary > Cc: Lukas Stadler; Deneau, Tom; graal-dev at openjdk.java.net > Subject: Re: conditional move > > Yes, because ternaries are compiled by javac as if-statements. > > On May 24, 2013, at 5:17 PM, "Frost, Gary" wrote: > >> Presumably, ternaries are good candidates for this. >> >> boolean isOdd(int i){ >> boolean odd=((i%2)!=0)?0:1; >> return odd; >> } >> >> -----Original Message----- >> From: graal-dev-bounces at openjdk.java.net [mailto:graal-dev-bounces at openjdk.java.net] On Behalf Of Lukas Stadler >> Sent: Friday, May 24, 2013 3:51 AM >> To: Deneau, Tom >> Cc: graal-dev at openjdk.java.net >> Subject: Re: conditional move >> >> The ConditionalNode is most of the time not created by the GraphBuilder directly, but it will appear later when a simple if/then/else is canonicalized. >> So a simple snippet that boils down to a conditional move could look like this: >> >> public static int testSnippet(int i) { >> if (i == 0) { >> return 1; >> } else { >> return 2; >> } >> } >> >> - Lukas >> >> >> On May 24, 2013, at 1:04 AM, "Deneau, Tom" wrote: >> >>> While compiling a larger chunk of code we were handed a >>> ConditionalMove node (which we have not implemented yet). I would >>> like to make a smaller test case for this but java patterns that I >>> thought would be mapping to conditional move aren't doing so. What >>> would be a typical small test case for generating the ConditionalMove node? >>> >>> -- Tom Deneau >>> >> >> >> > > > From Vasanth.Venkatachalam at amd.com Wed Jun 19 09:28:39 2013 From: Vasanth.Venkatachalam at amd.com (Venkatachalam, Vasanth) Date: Wed, 19 Jun 2013 16:28:39 +0000 Subject: revised webrev for graal hsail backend Message-ID: <5DD1503F815BD14889DC81D28643E3A73D90971E@sausexdag06.amd.com> Hi Christian, Attached is a patch which addresses the first round of review comments from Doug Simon. We're having a call with Donald Smith about the license issue surrounding Okra. Please ignore the license question for now. The rest of the patch is ready to be reviewed. Can you create the webrev and required commit with line "Contributed-by"? Vasanth -----Original Message----- From: Christian Thalinger [mailto:christian.thalinger at oracle.com] Sent: Tuesday, June 11, 2013 7:48 PM To: Thomas Wuerthinger Cc: Venkatachalam, Vasanth Subject: Re: access to cr.openjdk.java.net On Jun 11, 2013, at 2:20 PM, Thomas Wuerthinger wrote: > If Mark is very picky, he might insist that you have "2 contributions" before you can be appointed author. Chris, you know what is the best procedure here? Could Vasanth send you the patch and you create the webrev and the required commit with line "Contributed-by:"? Yes, I can do this. Just send me the patch. -- Chris > > - thomas > > On Jun 11, 2013, at 8:35 PM, "Venkatachalam, Vasanth" wrote: >> Thomas, >> >> I need an account on http://cr.openjdk.java.net so that I can submit AMD's webrev for the Graal HSAIL support changes. Can you appoint me as an Author? >> >> Vasanth >> >> >> 2013/6/10 8:29 -0700, vasanth.venkatachalam at amd.com: >>> I need an account on http://cr.openjdk.java.net so that I can submit >>> AMD's webrev for the Graal HSAIL support changes. >>> >>> Who would be the person to contact? >>> >>> Mark, >>> >>> Eric Caspole suggested I copy you? >> >> No, per our documented process [1] you should ask the Graal Project Lead, Thomas Wuerthinger, to appoint you an Author. >> >> He should then ask the Registrar to make it official [2]. >> >> - Mark >> >> >> [1] http://openjdk.java.net/projects/#project-author >> [2] http://openjdk.java.net/projects/#appointing-author >> >> > From Vasanth.Venkatachalam at amd.com Wed Jun 19 15:27:30 2013 From: Vasanth.Venkatachalam at amd.com (Venkatachalam, Vasanth) Date: Wed, 19 Jun 2013 22:27:30 +0000 Subject: final graal HSAIL support patch Message-ID: <5DD1503F815BD14889DC81D28643E3A73D909869@sausexdag06.amd.com> Hi Christian, Here's the final version of our graal HSAIL support patch. This addresses all of Doug Simon's comments. In particular, 1) Checkstyle errors have been fixed and all licenses in the Okra packages are attributed to Oracle. 2) What was previously the com.amd.sumatra package has been removed and its source files (which don't have anything Sumatra specific) have been moved into the com.oracle.graal.compiler.hsail package. 3) Hotspot c++ source changes have been reverted and are no longer part of the webrev. Vasanth From Vasanth.Venkatachalam at amd.com Thu Jun 20 08:14:36 2013 From: Vasanth.Venkatachalam at amd.com (Venkatachalam, Vasanth) Date: Thu, 20 Jun 2013 15:14:36 +0000 Subject: final graal HSAIL support patch Message-ID: <5DD1503F815BD14889DC81D28643E3A73D90A91C@sausexdag06.amd.com> I had attached my patch with the below email with, but it looks like the mail client may have stripped it away. In case anyone didn't get the attachment, here it is zipped up. From: Venkatachalam, Vasanth Sent: Wednesday, June 19, 2013 5:28 PM To: christian.thalinger at oracle.com Cc: Doug Simon @ Oracle (doug.simon at oracle.com); donald.smith at oracle.com; graal-dev at openjdk.java.net; sw.runtimes Subject: final graal HSAIL support patch Hi Christian, Here's the final version of our graal HSAIL support patch. This addresses all of Doug Simon's comments. In particular, 1) Checkstyle errors have been fixed and all licenses in the Okra packages are attributed to Oracle. 2) What was previously the com.amd.sumatra package has been removed and its source files (which don't have anything Sumatra specific) have been moved into the com.oracle.graal.compiler.hsail package. 3) Hotspot c++ source changes have been reverted and are no longer part of the webrev. Vasanth From Vasanth.Venkatachalam at amd.com Fri Jun 21 08:44:26 2013 From: Vasanth.Venkatachalam at amd.com (Venkatachalam, Vasanth) Date: Fri, 21 Jun 2013 15:44:26 +0000 Subject: AMD's blog article on Graal HSAIL support Message-ID: <5DD1503F815BD14889DC81D28643E3A73D90CBAA@sausexdag06.amd.com> Hi all, Please check out AMD's first blog article on HSAIL code generation support for Graal. This article shows describes the HSAIL code generated for a simple test case of squaring two arrays. This will be useful for understanding the webrev we recently submitted to extend Graal with an HSAIL backend. http://developer.amd.com/community/blog/amd-enabled-gpu-code-generation-for-java-a-case-study/ We plan to submit more articles like this where we give examples of what HSAIL would be generated for java programs of varying complexities. Vasanth From me at chrisatk.in Fri Jun 21 10:12:01 2013 From: me at chrisatk.in (Chris Atkin-Granville) Date: Fri, 21 Jun 2013 18:12:01 +0100 Subject: Instrumentation with snippets In-Reply-To: <6E2D9743-A95D-4112-8ACD-458E8F930F83@oracle.com> References: <25380D5F-06EF-4221-AE86-1E14C94DF627@oracle.com> <51BF4C0F.4010709@oracle.com> <6E2D9743-A95D-4112-8ACD-458E8F930F83@oracle.com> Message-ID: Excellent! Thanks for your help - I really appreciate it. I'm working on getting this implemented now. On 18 Jun 2013, at 13:12, Doug Simon wrote: > Chris, > > After more thought and discussion with other Graal devs, the InvokeNode solution won't work as the HotSpot runtime cannot patch an unlinked call at a location that doesn't map back to the bytecode index (BCI) of an INVOKE* instruction. In this case, the BCI is for one of the *ASTORE *ALOAD instructions. The reason it works in the example I gave is that the call to MonitorSnippets.initCounter() is force inlined so there's no need for call patching. > > Instead, what you want is to place your own placeholder node before/after the array access instructions where that node implements Lowerable and lowers itself via a snippet. For this, you need to write a phase that does the insertion of your new nodes and also modify HotSpotRuntime to register your snippets and call them in the lower() method. > > -Doug > > On Jun 17, 2013, at 9:10 PM, Chris Atkin-Granville wrote: > >> Hi Doug, Mick, >> >> On 17 Jun 2013, at 17:05, Doug Simon wrote: >>> Snippets (as opposed to method substitutions) are currently only used during lowering. So one thing you could do is replace the lowering in HotSpotRuntime.lower() for LoadIndexedNode and StoreIndexedNode to use your snippets instead. However, this means you need to replicate the correct semantics for these operations in your snippet in addition to the instrumentation code. I think a better alternative would be to insert an InvokeNode before/after the array access node that takes the same inputs of the array access and calls a well known (static) instrumentation method. >> >> After that information I agree that inserting an InvokeNode is probably the best idea too. I'd like to avoid modifying the Graal source if possible! >> >>> It might be instructive to look at MonitorSnippets.checkBalancedMonitors() for an example of inserting an invoke node. >> >> Thanks for the pointer. Is the best way to do this to add a phase (at HIGH_LEVEL I presume?) and then call a method that inserts InvokeNodes upon each instance of StoreIndexedNode/LoadIndexedNode? In other words, to use the same mechanism as in the code I posted below, replacing the contents of ArrayAccessSnippets.Templates:lower() with code that adds InvokeNodes? If so, I have already tried this but I'm getting SIGSEGVs from the JVM upon execution (LinkResolver::lookup_method_in_klasses) - I've attached the full report. >> >> At the moment the behaviour in my Templates class is: >> >> private final SnippetInfo methodOnStore = snippet(ArrayAccessSnippets.class, "arrayIndexStore"); // note - arrayIndexStore has been declared static, no args, void return >> >> public void invokeAfter(StoreIndexedNode node, StructuredGraph graph) { >> JavaType returnType = methodOnStore.getMethod().getSignature().getReturnType(methodOnStore.getMethod().getDeclaringClass()); >> MethodCallTargetNode callTarget = graph.add(new MethodCallTargetNode(InvokeKind.Static, methodOnStore.getMethod(), new ValueNode[] {}, returnType)); >> InvokeNode invoke = graph.add(new InvokeNode(callTarget, 0)); >> invoke.setStateAfter(node.stateAfter()); >> graph.addAfterFixed(node, invoke); >> } >> >> invokeAfter is called from my HIGH_LEVEL phase [i.e., for(Node node: graph.getNodes()) if (node instanceOf StoreIndexedNode) snippets.invokeAfter((StoreIndexedNode) node, graph); ] >> >> I'm confused as to why I'm getting the LinkResolver error - to me (through a debugger) it looks like everything is "wired up" correctly. >> >> On 17 Jun 2013, at 18:49, Mick Jordan wrote: >>> I am planning to implement the VMA instrumentation from Maxine in Graal fairly soon which, as Doug suggests, involves inserting Invoke nodes in general. However, depending on the nature of the instrumentation, the inlining may then remove them and inline the instrumentation. This should work with Hotspot also (eventually). >> >> Interesting. Could you perhaps elaborate on the "nature of the instrumentation"? Specifically, would you perform inlining based on the behaviour of the instrumentation or something else? >> > > From s1255753 at sms.ed.ac.uk Fri Jun 21 11:21:21 2013 From: s1255753 at sms.ed.ac.uk (ATKIN-GRANVILLE Chris) Date: Fri, 21 Jun 2013 18:21:21 +0000 Subject: Instrumentation with snippets In-Reply-To: References: <25380D5F-06EF-4221-AE86-1E14C94DF627@oracle.com> <51BF4C0F.4010709@oracle.com> <6E2D9743-A95D-4112-8ACD-458E8F930F83@oracle.com> Message-ID: <83211E04-C8A9-4F2F-B4E6-13AD928373BE@sms.ed.ac.uk> Just wondering?is there a way to do this without modifying HotSpotRuntime? Perhaps I could call the lowering of my custom nodes in a phase? On 21 Jun 2013, at 18:12, Chris Atkin-Granville wrote: > Excellent! Thanks for your help - I really appreciate it. I'm working on getting this implemented now. > > On 18 Jun 2013, at 13:12, Doug Simon wrote: > >> Chris, >> >> After more thought and discussion with other Graal devs, the InvokeNode solution won't work as the HotSpot runtime cannot patch an unlinked call at a location that doesn't map back to the bytecode index (BCI) of an INVOKE* instruction. In this case, the BCI is for one of the *ASTORE *ALOAD instructions. The reason it works in the example I gave is that the call to MonitorSnippets.initCounter() is force inlined so there's no need for call patching. >> >> Instead, what you want is to place your own placeholder node before/after the array access instructions where that node implements Lowerable and lowers itself via a snippet. For this, you need to write a phase that does the insertion of your new nodes and also modify HotSpotRuntime to register your snippets and call them in the lower() method. >> >> -Doug >> >> On Jun 17, 2013, at 9:10 PM, Chris Atkin-Granville wrote: >> >>> Hi Doug, Mick, >>> >>> On 17 Jun 2013, at 17:05, Doug Simon wrote: >>>> Snippets (as opposed to method substitutions) are currently only used during lowering. So one thing you could do is replace the lowering in HotSpotRuntime.lower() for LoadIndexedNode and StoreIndexedNode to use your snippets instead. However, this means you need to replicate the correct semantics for these operations in your snippet in addition to the instrumentation code. I think a better alternative would be to insert an InvokeNode before/after the array access node that takes the same inputs of the array access and calls a well known (static) instrumentation method. >>> >>> After that information I agree that inserting an InvokeNode is probably the best idea too. I'd like to avoid modifying the Graal source if possible! >>> >>>> It might be instructive to look at MonitorSnippets.checkBalancedMonitors() for an example of inserting an invoke node. >>> >>> Thanks for the pointer. Is the best way to do this to add a phase (at HIGH_LEVEL I presume?) and then call a method that inserts InvokeNodes upon each instance of StoreIndexedNode/LoadIndexedNode? In other words, to use the same mechanism as in the code I posted below, replacing the contents of ArrayAccessSnippets.Templates:lower() with code that adds InvokeNodes? If so, I have already tried this but I'm getting SIGSEGVs from the JVM upon execution (LinkResolver::lookup_method_in_klasses) - I've attached the full report. >>> >>> At the moment the behaviour in my Templates class is: >>> >>> private final SnippetInfo methodOnStore = snippet(ArrayAccessSnippets.class, "arrayIndexStore"); // note - arrayIndexStore has been declared static, no args, void return >>> >>> public void invokeAfter(StoreIndexedNode node, StructuredGraph graph) { >>> JavaType returnType = methodOnStore.getMethod().getSignature().getReturnType(methodOnStore.getMethod().getDeclaringClass()); >>> MethodCallTargetNode callTarget = graph.add(new MethodCallTargetNode(InvokeKind.Static, methodOnStore.getMethod(), new ValueNode[] {}, returnType)); >>> InvokeNode invoke = graph.add(new InvokeNode(callTarget, 0)); >>> invoke.setStateAfter(node.stateAfter()); >>> graph.addAfterFixed(node, invoke); >>> } >>> >>> invokeAfter is called from my HIGH_LEVEL phase [i.e., for(Node node: graph.getNodes()) if (node instanceOf StoreIndexedNode) snippets.invokeAfter((StoreIndexedNode) node, graph); ] >>> >>> I'm confused as to why I'm getting the LinkResolver error - to me (through a debugger) it looks like everything is "wired up" correctly. >>> >>> On 17 Jun 2013, at 18:49, Mick Jordan wrote: >>>> I am planning to implement the VMA instrumentation from Maxine in Graal fairly soon which, as Doug suggests, involves inserting Invoke nodes in general. However, depending on the nature of the instrumentation, the inlining may then remove them and inline the instrumentation. This should work with Hotspot also (eventually). >>> >>> Interesting. Could you perhaps elaborate on the "nature of the instrumentation"? Specifically, would you perform inlining based on the behaviour of the instrumentation or something else? >>> >> >> > > -- The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336. From thomas.wuerthinger at oracle.com Fri Jun 21 11:52:22 2013 From: thomas.wuerthinger at oracle.com (Thomas Wuerthinger) Date: Fri, 21 Jun 2013 20:52:22 +0200 Subject: Instrumentation with snippets In-Reply-To: <83211E04-C8A9-4F2F-B4E6-13AD928373BE@sms.ed.ac.uk> References: <25380D5F-06EF-4221-AE86-1E14C94DF627@oracle.com> <51BF4C0F.4010709@oracle.com> <6E2D9743-A95D-4112-8ACD-458E8F930F83@oracle.com> <83211E04-C8A9-4F2F-B4E6-13AD928373BE@sms.ed.ac.uk> Message-ID: Yes. You can also implement the lowering directly in the "lower" method of your custom nodes instead of delegating to the runtime. - thomas On Jun 21, 2013, at 8:21 PM, ATKIN-GRANVILLE Chris wrote: > Just wondering?is there a way to do this without modifying HotSpotRuntime? Perhaps I could call the lowering of my custom nodes in a phase? > > On 21 Jun 2013, at 18:12, Chris Atkin-Granville wrote: > >> Excellent! Thanks for your help - I really appreciate it. I'm working on getting this implemented now. >> >> On 18 Jun 2013, at 13:12, Doug Simon wrote: >> >>> Chris, >>> >>> After more thought and discussion with other Graal devs, the InvokeNode solution won't work as the HotSpot runtime cannot patch an unlinked call at a location that doesn't map back to the bytecode index (BCI) of an INVOKE* instruction. In this case, the BCI is for one of the *ASTORE *ALOAD instructions. The reason it works in the example I gave is that the call to MonitorSnippets.initCounter() is force inlined so there's no need for call patching. >>> >>> Instead, what you want is to place your own placeholder node before/after the array access instructions where that node implements Lowerable and lowers itself via a snippet. For this, you need to write a phase that does the insertion of your new nodes and also modify HotSpotRuntime to register your snippets and call them in the lower() method. >>> >>> -Doug >>> >>> On Jun 17, 2013, at 9:10 PM, Chris Atkin-Granville wrote: >>> >>>> Hi Doug, Mick, >>>> >>>> On 17 Jun 2013, at 17:05, Doug Simon wrote: >>>>> Snippets (as opposed to method substitutions) are currently only used during lowering. So one thing you could do is replace the lowering in HotSpotRuntime.lower() for LoadIndexedNode and StoreIndexedNode to use your snippets instead. However, this means you need to replicate the correct semantics for these operations in your snippet in addition to the instrumentation code. I think a better alternative would be to insert an InvokeNode before/after the array access node that takes the same inputs of the array access and calls a well known (static) instrumentation method. >>>> >>>> After that information I agree that inserting an InvokeNode is probably the best idea too. I'd like to avoid modifying the Graal source if possible! >>>> >>>>> It might be instructive to look at MonitorSnippets.checkBalancedMonitors() for an example of inserting an invoke node. >>>> >>>> Thanks for the pointer. Is the best way to do this to add a phase (at HIGH_LEVEL I presume?) and then call a method that inserts InvokeNodes upon each instance of StoreIndexedNode/LoadIndexedNode? In other words, to use the same mechanism as in the code I posted below, replacing the contents of ArrayAccessSnippets.Templates:lower() with code that adds InvokeNodes? If so, I have already tried this but I'm getting SIGSEGVs from the JVM upon execution (LinkResolver::lookup_method_in_klasses) - I've attached the full report. >>>> >>>> At the moment the behaviour in my Templates class is: >>>> >>>> private final SnippetInfo methodOnStore = snippet(ArrayAccessSnippets.class, "arrayIndexStore"); // note - arrayIndexStore has been declared static, no args, void return >>>> >>>> public void invokeAfter(StoreIndexedNode node, StructuredGraph graph) { >>>> JavaType returnType = methodOnStore.getMethod().getSignature().getReturnType(methodOnStore.getMethod().getDeclaringClass()); >>>> MethodCallTargetNode callTarget = graph.add(new MethodCallTargetNode(InvokeKind.Static, methodOnStore.getMethod(), new ValueNode[] {}, returnType)); >>>> InvokeNode invoke = graph.add(new InvokeNode(callTarget, 0)); >>>> invoke.setStateAfter(node.stateAfter()); >>>> graph.addAfterFixed(node, invoke); >>>> } >>>> >>>> invokeAfter is called from my HIGH_LEVEL phase [i.e., for(Node node: graph.getNodes()) if (node instanceOf StoreIndexedNode) snippets.invokeAfter((StoreIndexedNode) node, graph); ] >>>> >>>> I'm confused as to why I'm getting the LinkResolver error - to me (through a debugger) it looks like everything is "wired up" correctly. >>>> >>>> On 17 Jun 2013, at 18:49, Mick Jordan wrote: >>>>> I am planning to implement the VMA instrumentation from Maxine in Graal fairly soon which, as Doug suggests, involves inserting Invoke nodes in general. However, depending on the nature of the instrumentation, the inlining may then remove them and inline the instrumentation. This should work with Hotspot also (eventually). >>>> >>>> Interesting. Could you perhaps elaborate on the "nature of the instrumentation"? Specifically, would you perform inlining based on the behaviour of the instrumentation or something else? >>>> >>> >>> >> >> > > > > -- > The University of Edinburgh is a charitable body, registered in > Scotland, with registration number SC005336. > From sunbiz at gmail.com Fri Jun 21 12:09:15 2013 From: sunbiz at gmail.com (Saptarshi Purkayastha) Date: Fri, 21 Jun 2013 21:09:15 +0200 Subject: AMD's blog article on Graal HSAIL support In-Reply-To: <5DD1503F815BD14889DC81D28643E3A73D90CBAA@sausexdag06.amd.com> References: <5DD1503F815BD14889DC81D28643E3A73D90CBAA@sausexdag06.amd.com> Message-ID: This might be the correct link I think - http://developer.amd.com/community/blog/hsail-based-gpu-offload-the-quest-for-java-performance-begins/ --- Regards, Saptarshi PURKAYASTHA My Tech Blog: http://sunnytalkstech.blogspot.com You Live by CHOICE, Not by CHANCE On 21 June 2013 17:44, Venkatachalam, Vasanth wrote: > Hi all, > > Please check out AMD's first blog article on HSAIL code generation support > for Graal. > This article shows describes the HSAIL code generated for a simple test > case of squaring two arrays. This will be useful for understanding the > webrev we recently submitted to extend Graal with an HSAIL backend. > > > http://developer.amd.com/community/blog/amd-enabled-gpu-code-generation-for-java-a-case-study/ > > We plan to submit more articles like this where we give examples of what > HSAIL would be generated for java programs of varying complexities. > > Vasanth > From Vasanth.Venkatachalam at amd.com Fri Jun 21 13:16:41 2013 From: Vasanth.Venkatachalam at amd.com (Venkatachalam, Vasanth) Date: Fri, 21 Jun 2013 20:16:41 +0000 Subject: AMD's blog article on Graal HSAIL support In-Reply-To: References: <5DD1503F815BD14889DC81D28643E3A73D90CBAA@sausexdag06.amd.com> Message-ID: <5DD1503F815BD14889DC81D28643E3A73D90DCD2@sausexdag06.amd.com> Hi, We had to take the site down to fix some formatting issues. Its back up again. The link has been changed to: http://developer.amd.com/community/blog/hsail-based-gpu-offload-the-quest-for-java-performance-begins/ Vasanth From: Saptarshi Purkayastha [mailto:sunbiz at gmail.com] Sent: Friday, June 21, 2013 2:09 PM To: Venkatachalam, Vasanth Cc: graal-dev at openjdk.java.net; sumatra-dev at openjdk.java.net Subject: Re: AMD's blog article on Graal HSAIL support This might be the correct link I think - http://developer.amd.com/community/blog/hsail-based-gpu-offload-the-quest-for-java-performance-begins/ --- Regards, Saptarshi PURKAYASTHA My Tech Blog: http://sunnytalkstech.blogspot.com You Live by CHOICE, Not by CHANCE On 21 June 2013 17:44, Venkatachalam, Vasanth > wrote: Hi all, Please check out AMD's first blog article on HSAIL code generation support for Graal. This article shows describes the HSAIL code generated for a simple test case of squaring two arrays. This will be useful for understanding the webrev we recently submitted to extend Graal with an HSAIL backend. http://developer.amd.com/community/blog/amd-enabled-gpu-code-generation-for-java-a-case-study/ We plan to submit more articles like this where we give examples of what HSAIL would be generated for java programs of varying complexities. Vasanth From doug.simon at oracle.com Sat Jun 22 18:00:24 2013 From: doug.simon at oracle.com (doug.simon at oracle.com) Date: Sun, 23 Jun 2013 01:00:24 +0000 Subject: hg: graal/graal: 386 new changesets Message-ID: <20130623011415.5DC5A4842E@hg.openjdk.java.net> Changeset: 9d15ca2f38d1 Author: Mick Jordan Date: 2013-06-18 14:17 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/9d15ca2f38d1 fix == on Register value ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/alloc/LinearScanWalker.java Changeset: e0fb8a213650 Author: Mick Jordan Date: 2013-06-18 14:23 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/e0fb8a213650 fix == on Value ! graal/com.oracle.graal.compiler.amd64/src/com/oracle/graal/compiler/amd64/AMD64LIRGenerator.java Changeset: baec10fbe959 Author: Christian Haeubl Date: 2013-06-19 12:21 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/baec10fbe959 Added a more inlining test cases. ! graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/inlining/InliningTest.java Changeset: 9d0c16df0bc7 Author: Andreas Woess Date: 2013-06-19 15:07 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/9d0c16df0bc7 junit.framework package is deprecated ! graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/EliminateNestedCheckCastsTest.java ! graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/PushNodesThroughPiTest.java ! graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/TypeSystemTest.java ! graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/ea/EscapeAnalysisTest.java ! graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/ea/PartialEscapeAnalysisTest.java Changeset: 97e8cabe9064 Author: Andreas Woess Date: 2013-06-19 15:29 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/97e8cabe9064 fix canonicalization of UnsafeStoreNode: preserve stateAfter ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/extended/UnsafeStoreNode.java Changeset: ae6f0c381087 Author: Lukas Stadler Date: 2013-06-19 16:42 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/ae6f0c381087 split MemoryCheckpoint interface into Single and Multi ! graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/WriteBarrierVerificationTest.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/nodes/BeginLockScopeNode.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/nodes/DirectCompareAndSwapNode.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/nodes/EndLockScopeNode.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/nodes/HotSpotNmethodExecuteNode.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/nodes/StubForeignCallNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/InvokeNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/InvokeWithExceptionNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/StartNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/extended/AbstractCallNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/extended/ForeignCallNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/extended/MembarNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/extended/MemoryCheckpoint.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/extended/MonitorEnter.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/extended/UnsafeStoreNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/extended/WriteMemoryCheckpointNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/extended/WriteNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/java/CompareAndSwapNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/java/ExceptionObjectNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/java/MonitorEnterNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/java/MonitorExitNode.java ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/FloatingReadPhase.java ! graal/com.oracle.graal.phases/src/com/oracle/graal/phases/schedule/SchedulePhase.java ! graal/com.oracle.graal.replacements/src/com/oracle/graal/replacements/nodes/MacroNode.java Changeset: 51b8585a1d70 Author: Lukas Stadler Date: 2013-06-19 16:46 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/51b8585a1d70 more restrictive condition in ForeignCallNode.setStateAfter ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/extended/ForeignCallNode.java Changeset: b0301c02f38e Author: katleman Date: 2013-04-12 15:22 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/b0301c02f38e 8012048: JDK8 b85 source with GPL header errors Reviewed-by: iris, mduigou, jjg ! make/bsd/makefiles/fastdebug.make ! src/share/vm/services/diagnosticArgument.cpp ! test/sanity/WBApi.java ! test/serviceability/ParserTest.java ! test/testlibrary/whitebox/sun/hotspot/WhiteBox.java ! test/testlibrary/whitebox/sun/hotspot/parser/DiagnosticCommand.java Changeset: c9eb0ec1c792 Author: katleman Date: 2013-04-15 14:19 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/c9eb0ec1c792 Merge ! test/testlibrary/whitebox/sun/hotspot/WhiteBox.java Changeset: 86db4847f195 Author: katleman Date: 2013-04-17 12:38 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/86db4847f195 Merge ! test/testlibrary/whitebox/sun/hotspot/WhiteBox.java Changeset: 2e657354f6bc Author: katleman Date: 2013-04-18 10:30 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/2e657354f6bc Added tag jdk8-b86 for changeset 86db4847f195 ! .hgtags Changeset: 35f8765422b9 Author: zgu Date: 2013-04-10 08:55 -0400 URL: http://hg.openjdk.java.net/graal/graal/rev/35f8765422b9 8010151: nsk/regression/b6653214 fails "assert(snapshot != NULL) failed: Worker should not be started" Summary: Fixed a racing condition when shutting down NMT while worker thread is being started, also fixed a few mis-declared volatile pointers. Reviewed-by: dholmes, dlong ! src/share/vm/runtime/thread.hpp ! src/share/vm/services/memTrackWorker.cpp ! src/share/vm/services/memTrackWorker.hpp ! src/share/vm/services/memTracker.cpp ! src/share/vm/services/memTracker.hpp Changeset: f2c0ccccc6b6 Author: rdurbin Date: 2013-04-16 08:59 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/f2c0ccccc6b6 Merge Changeset: 71013d764f6e Author: johnc Date: 2013-04-10 10:57 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/71013d764f6e 8010780: G1: Eden occupancy/capacity output wrong after a full GC Summary: Move the calculation and recording of eden capacity to the start of a GC and print a detailed heap transition for full GCs. Reviewed-by: tschatzl, jmasa ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.cpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.hpp Changeset: c0000f77bc6d Author: johnc Date: 2013-04-11 10:20 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/c0000f77bc6d Merge ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp Changeset: 9aa8d8037ee3 Author: mgerdin Date: 2013-04-16 12:46 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/9aa8d8037ee3 Merge ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.cpp Changeset: df254344edf1 Author: jmasa Date: 2013-04-01 10:50 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/df254344edf1 8011173: NPG: Replace the ChunkList implementation with class FreeList Reviewed-by: mgerdin, tschatzl, johnc, coleenp ! src/share/vm/memory/metaspace.cpp Changeset: f2e682ef3156 Author: johnc Date: 2013-04-17 10:57 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/f2e682ef3156 8012335: G1: Fix bug with compressed oops in template interpreter on x86 and sparc. Summary: In do_oop_store the uncompressed value of the oop being stored needs to be preserved and passed to g1_write_barrier_post. This is necessary for the heap region cross check to work correctly. Reviewed-by: coleenp, johnc Contributed-by: Martin Doerr ! src/cpu/sparc/vm/templateTable_sparc.cpp ! src/cpu/x86/vm/templateTable_x86_64.cpp Changeset: 07a4efc5ed14 Author: brutisso Date: 2013-04-18 06:50 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/07a4efc5ed14 8012455: Missing time and date stamps for PrintGCApplicationConcurrentTime and PrintGCApplicationStoppedTime Summary: also reviewed by: kirk at kodewerk.com, brandon at twitter.com Reviewed-by: tschatzl, stefank, johnc ! src/share/vm/services/runtimeService.cpp Changeset: cbf8c8c25bbe Author: mgerdin Date: 2013-04-18 14:38 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/cbf8c8c25bbe Merge Changeset: aeaca88565e6 Author: jiangli Date: 2013-04-09 17:17 -0400 URL: http://hg.openjdk.java.net/graal/graal/rev/aeaca88565e6 8010862: The Method counter fields used for profiling can be allocated lazily. Summary: Allocate the method's profiling related metadata until they are needed. Reviewed-by: coleenp, roland ! agent/src/share/classes/sun/jvm/hotspot/oops/Method.java + agent/src/share/classes/sun/jvm/hotspot/oops/MethodCounters.java ! src/cpu/sparc/vm/cppInterpreter_sparc.cpp ! src/cpu/sparc/vm/interp_masm_sparc.cpp ! src/cpu/sparc/vm/interp_masm_sparc.hpp ! src/cpu/sparc/vm/templateInterpreter_sparc.cpp ! src/cpu/sparc/vm/templateTable_sparc.cpp ! src/cpu/x86/vm/cppInterpreter_x86.cpp ! src/cpu/x86/vm/interp_masm_x86_32.cpp ! src/cpu/x86/vm/interp_masm_x86_32.hpp ! src/cpu/x86/vm/interp_masm_x86_64.cpp ! src/cpu/x86/vm/interp_masm_x86_64.hpp ! src/cpu/x86/vm/templateInterpreter_x86_32.cpp ! src/cpu/x86/vm/templateInterpreter_x86_64.cpp ! src/cpu/x86/vm/templateTable_x86_32.cpp ! src/cpu/x86/vm/templateTable_x86_64.cpp ! src/share/vm/c1/c1_LIRGenerator.cpp ! src/share/vm/ci/ciMethod.cpp ! src/share/vm/ci/ciMethod.hpp ! src/share/vm/ci/ciReplay.cpp ! src/share/vm/interpreter/interpreterRuntime.cpp ! src/share/vm/interpreter/interpreterRuntime.hpp ! src/share/vm/interpreter/invocationCounter.cpp ! src/share/vm/oops/method.cpp ! src/share/vm/oops/method.hpp + src/share/vm/oops/methodCounters.cpp + src/share/vm/oops/methodCounters.hpp ! src/share/vm/oops/methodData.cpp ! src/share/vm/opto/parseHelper.cpp ! src/share/vm/runtime/advancedThresholdPolicy.cpp ! src/share/vm/runtime/compilationPolicy.cpp ! src/share/vm/runtime/fprofiler.cpp ! src/share/vm/runtime/simpleThresholdPolicy.cpp ! src/share/vm/runtime/vmStructs.cpp Changeset: 42a42da29fd7 Author: jiangli Date: 2013-04-11 23:06 -0400 URL: http://hg.openjdk.java.net/graal/graal/rev/42a42da29fd7 8012052: java/lang/invoke/6987555/Test6987555.java crashes with assert(mcs != NULL) failed: MethodCounters cannot be NULL. Summary: Skip counter decay if the MethodCounters is NULL in NonTieredCompPolicy::delay_compilation(). Reviewed-by: kvn, dholmes ! src/share/vm/runtime/compilationPolicy.cpp Changeset: 8df6ddda8090 Author: jiangli Date: 2013-04-15 21:25 -0400 URL: http://hg.openjdk.java.net/graal/graal/rev/8df6ddda8090 Merge ! src/share/vm/c1/c1_LIRGenerator.cpp ! src/share/vm/interpreter/interpreterRuntime.cpp ! src/share/vm/oops/method.hpp ! src/share/vm/oops/methodData.cpp ! src/share/vm/prims/whitebox.cpp ! src/share/vm/runtime/compilationPolicy.cpp ! src/share/vm/runtime/vmStructs.cpp Changeset: 9500809ceead Author: jiangli Date: 2013-04-18 17:00 -0400 URL: http://hg.openjdk.java.net/graal/graal/rev/9500809ceead Merge ! src/cpu/sparc/vm/templateTable_sparc.cpp ! src/cpu/x86/vm/templateTable_x86_64.cpp Changeset: 1c6887c9afaa Author: twisti Date: 2013-04-15 16:20 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/1c6887c9afaa 7172922: export_ makefile targets do not work unless all supported variants are built Reviewed-by: dholmes, kvn ! make/Makefile Changeset: b105029fdbfd Author: roland Date: 2013-04-15 18:42 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/b105029fdbfd Merge Changeset: 8373c19be854 Author: neliasso Date: 2013-04-16 10:08 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/8373c19be854 8011621: live_ranges_in_separate_class.patch Reviewed-by: kvn, roland Contributed-by: niclas.adlertz at oracle.com ! make/bsd/makefiles/vm.make ! make/linux/makefiles/vm.make ! make/solaris/makefiles/vm.make ! make/windows/create_obj_files.sh - src/os/bsd/vm/chaitin_bsd.cpp - src/os/linux/vm/chaitin_linux.cpp - src/os/solaris/vm/chaitin_solaris.cpp - src/os/windows/vm/chaitin_windows.cpp ! src/share/vm/opto/chaitin.cpp ! src/share/vm/opto/chaitin.hpp ! src/share/vm/opto/coalesce.cpp ! src/share/vm/opto/coalesce.hpp ! src/share/vm/opto/compile.cpp ! src/share/vm/opto/idealGraphPrinter.cpp ! src/share/vm/opto/ifg.cpp ! src/share/vm/opto/live.cpp ! src/share/vm/opto/live.hpp ! src/share/vm/opto/postaloc.cpp ! src/share/vm/opto/reg_split.cpp ! src/share/vm/opto/regalloc.hpp ! src/share/vm/runtime/vmStructs.cpp Changeset: c89eab0b6b30 Author: neliasso Date: 2013-04-16 10:37 -0400 URL: http://hg.openjdk.java.net/graal/graal/rev/c89eab0b6b30 Merge - src/os/bsd/vm/chaitin_bsd.cpp - src/os/linux/vm/chaitin_linux.cpp - src/os/solaris/vm/chaitin_solaris.cpp - src/os/windows/vm/chaitin_windows.cpp Changeset: 4b2eebe03f93 Author: iignatyev Date: 2013-04-16 10:04 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/4b2eebe03f93 8011971: WB API doesn't accept j.l.reflect.Constructor Reviewed-by: kvn, vlivanov ! src/share/vm/prims/whitebox.cpp ! test/compiler/whitebox/ClearMethodStateTest.java ! test/compiler/whitebox/CompilerWhiteBoxTest.java ! test/compiler/whitebox/DeoptimizeAllTest.java ! test/compiler/whitebox/DeoptimizeMethodTest.java ! test/compiler/whitebox/EnqueueMethodForCompilationTest.java ! test/compiler/whitebox/IsMethodCompilableTest.java ! test/compiler/whitebox/MakeMethodNotCompilableTest.java ! test/compiler/whitebox/SetDontInlineMethodTest.java ! test/compiler/whitebox/SetForceInlineMethodTest.java ! test/testlibrary/whitebox/sun/hotspot/WhiteBox.java Changeset: a7fb14888912 Author: neliasso Date: 2013-04-11 13:57 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/a7fb14888912 8006952: Slow VM due to excessive code cache freelist iteration Summary: Remove continous free block requirement Reviewed-by: kvn ! src/share/vm/code/codeBlob.cpp ! src/share/vm/code/codeCache.cpp ! src/share/vm/code/codeCache.hpp ! src/share/vm/code/nmethod.cpp ! src/share/vm/compiler/compileBroker.cpp ! src/share/vm/memory/heap.cpp ! src/share/vm/memory/heap.hpp ! src/share/vm/opto/output.cpp Changeset: dedc8563e33d Author: bharadwaj Date: 2013-04-18 16:04 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/dedc8563e33d Merge - make/bsd/makefiles/jvmg.make - make/bsd/makefiles/profiled.make - make/linux/makefiles/jvmg.make - make/linux/makefiles/profiled.make - make/solaris/makefiles/jvmg.make - make/solaris/makefiles/profiled.make - src/os/bsd/vm/chaitin_bsd.cpp - src/os/linux/vm/chaitin_linux.cpp - src/os/solaris/vm/chaitin_solaris.cpp - src/os/windows/vm/chaitin_windows.cpp Changeset: 2a9d97b57920 Author: bharadwaj Date: 2013-04-19 03:13 -0400 URL: http://hg.openjdk.java.net/graal/graal/rev/2a9d97b57920 Merge - make/bsd/makefiles/jvmg.make - make/bsd/makefiles/profiled.make - make/linux/makefiles/jvmg.make - make/linux/makefiles/profiled.make - make/solaris/makefiles/jvmg.make - make/solaris/makefiles/profiled.make - src/os/bsd/vm/chaitin_bsd.cpp - src/os/linux/vm/chaitin_linux.cpp - src/os/solaris/vm/chaitin_solaris.cpp - src/os/windows/vm/chaitin_windows.cpp ! src/share/vm/c1/c1_LIRGenerator.cpp ! src/share/vm/prims/whitebox.cpp ! src/share/vm/runtime/vmStructs.cpp Changeset: 01d5f04e64dc Author: amurillo Date: 2013-04-19 09:58 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/01d5f04e64dc Merge ! make/bsd/makefiles/fastdebug.make - make/bsd/makefiles/jvmg.make - make/bsd/makefiles/profiled.make - make/linux/makefiles/jvmg.make - make/linux/makefiles/profiled.make - make/solaris/makefiles/jvmg.make - make/solaris/makefiles/profiled.make - src/os/bsd/vm/chaitin_bsd.cpp - src/os/linux/vm/chaitin_linux.cpp - src/os/solaris/vm/chaitin_solaris.cpp - src/os/windows/vm/chaitin_windows.cpp ! test/testlibrary/whitebox/sun/hotspot/WhiteBox.java Changeset: 0491c26b1f1d Author: amurillo Date: 2013-04-19 09:58 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/0491c26b1f1d Added tag hs25-b29 for changeset 01d5f04e64dc ! .hgtags Changeset: 3d641132f83b Author: twisti Date: 2013-02-26 16:16 -0800 URL: http://hg.openjdk.java.net/graal/graal/rev/3d641132f83b 8004336: Better handling of method handle intrinsic frames Reviewed-by: kvn, jrose, ahgross ! src/share/vm/opto/library_call.cpp Changeset: 124ca22437b1 Author: chegar Date: 2013-04-12 10:14 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/124ca22437b1 Merge ! src/share/vm/opto/library_call.cpp Changeset: 6c560f9ebb3e Author: lana Date: 2013-04-17 10:12 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/6c560f9ebb3e Merge - test/gc/6941923/test6941923.sh - test/gc/TestVerifyBeforeGCDuringStartup.java Changeset: db9c527a1fd8 Author: lana Date: 2013-04-17 21:33 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/db9c527a1fd8 Merge Changeset: d4c266784660 Author: lana Date: 2013-04-23 09:27 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/d4c266784660 Merge Changeset: d080f5168deb Author: katleman Date: 2013-04-25 09:24 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/d080f5168deb Added tag jdk8-b87 for changeset d4c266784660 ! .hgtags Changeset: f78763f49817 Author: amurillo Date: 2013-04-19 10:09 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/f78763f49817 8012559: new hotspot build - hs25-b30 Reviewed-by: jcoomes ! make/hotspot_version Changeset: 63e31ce40bdb Author: hseigel Date: 2013-04-17 08:20 -0400 URL: http://hg.openjdk.java.net/graal/graal/rev/63e31ce40bdb 8009928: PSR:PERF Increase default string table size Summary: Increase default string table size to 60013 for 64-bit platforms. Reviewed-by: coleenp, dholmes ! src/share/vm/runtime/arguments.cpp ! src/share/vm/utilities/globalDefinitions.hpp Changeset: b80cc96882f7 Author: zgu Date: 2013-04-18 10:04 -0400 URL: http://hg.openjdk.java.net/graal/graal/rev/b80cc96882f7 8012464: NMT: classes should not derive from _ValueObj, use VALUE_OBJ_CLASS_SPEC instead Summary: NMT value objects should use VALUE_OBJ_CLASS_SPEC instead of deriving from _ValueObj Reviewed-by: coleenp, hseigel, dholmes ! src/share/vm/services/memBaseline.hpp ! src/share/vm/services/memPtr.hpp ! src/share/vm/services/memSnapshot.hpp ! src/share/vm/services/memTrackWorker.hpp Changeset: 41ed397cc0cd Author: bharadwaj Date: 2013-04-18 08:05 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/41ed397cc0cd 8006267: InterfaceMethod_ref should allow invokestatic and invokespecial Summary: Lambda changes; spec 0.6.2 - Allow static invokestatic and invokespecial calls to InterfaceMethod_ref Reviewed-by: dholmes, acorn ! src/share/vm/classfile/classFileParser.cpp ! src/share/vm/classfile/genericSignatures.cpp ! src/share/vm/interpreter/linkResolver.cpp ! src/share/vm/prims/methodHandles.cpp Changeset: 7815eaceaa8c Author: bharadwaj Date: 2013-04-18 14:03 -0400 URL: http://hg.openjdk.java.net/graal/graal/rev/7815eaceaa8c Merge Changeset: 6f817ce50129 Author: minqi Date: 2013-04-19 11:08 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/6f817ce50129 8010992: Remove calls to global ::operator new[] and new Summary: disable use of global operator new and new[] which could cause unexpected exception and escape from NMT tracking. Reviewed-by: coleenp, dholmes, zgu Contributed-by: yumin.qi at oracle.com ! src/os/windows/vm/os_windows.cpp ! src/share/vm/classfile/altHashing.cpp ! src/share/vm/gc_implementation/concurrentMarkSweep/cmsCollectorPolicy.cpp ! src/share/vm/gc_implementation/g1/heapRegionRemSet.cpp ! src/share/vm/memory/allocation.cpp ! src/share/vm/memory/allocation.hpp ! src/share/vm/memory/allocation.inline.hpp ! src/share/vm/memory/cardTableModRefBS.cpp ! src/share/vm/memory/cardTableModRefBS.hpp ! src/share/vm/memory/cardTableRS.cpp ! src/share/vm/memory/cardTableRS.hpp ! src/share/vm/memory/collectorPolicy.cpp ! src/share/vm/opto/idealGraphPrinter.hpp ! src/share/vm/runtime/handles.hpp ! src/share/vm/runtime/reflectionUtils.hpp ! src/share/vm/runtime/synchronizer.cpp ! src/share/vm/runtime/thread.cpp ! src/share/vm/runtime/vmStructs.cpp ! src/share/vm/utilities/events.hpp ! src/share/vm/utilities/quickSort.cpp ! src/share/vm/utilities/workgroup.cpp ! src/share/vm/utilities/workgroup.hpp Changeset: 17c51f84773a Author: dcubed Date: 2013-04-19 13:48 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/17c51f84773a Merge Changeset: 5b6512efcdc4 Author: dcubed Date: 2013-04-19 16:51 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/5b6512efcdc4 Merge - make/bsd/makefiles/jvmg.make - make/bsd/makefiles/profiled.make - make/linux/makefiles/jvmg.make - make/linux/makefiles/profiled.make - make/solaris/makefiles/jvmg.make - make/solaris/makefiles/profiled.make - src/os/bsd/vm/chaitin_bsd.cpp - src/os/linux/vm/chaitin_linux.cpp - src/os/solaris/vm/chaitin_solaris.cpp - src/os/windows/vm/chaitin_windows.cpp ! src/os/windows/vm/os_windows.cpp ! src/share/vm/memory/allocation.hpp ! src/share/vm/runtime/vmStructs.cpp Changeset: 6337ca4dcad8 Author: sspitsyn Date: 2013-04-20 04:07 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/6337ca4dcad8 8008511: JSR 292: MemberName vmtarget refs to methods must be updated at class redefinition Summary: Lazily create and maintain the MemberNameTable to be able to update MemberName's Reviewed-by: coleenp, jrose, dholmes Contributed-by: serguei.spitsyn at oracle.com ! src/share/vm/classfile/javaClasses.cpp ! src/share/vm/classfile/javaClasses.hpp ! src/share/vm/oops/instanceKlass.cpp ! src/share/vm/oops/instanceKlass.hpp ! src/share/vm/prims/jvmtiRedefineClasses.cpp ! src/share/vm/prims/methodHandles.cpp ! src/share/vm/prims/methodHandles.hpp ! src/share/vm/runtime/mutexLocker.cpp ! src/share/vm/runtime/mutexLocker.hpp Changeset: a527ddd44e07 Author: mgronlun Date: 2013-04-20 19:02 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/a527ddd44e07 6729929: I18N - Taking Heap Dump failed if project path contains multibyte characters Reviewed-by: dholmes, rbackman Contributed-by: peter.allwin at oracle.com ! src/share/vm/services/management.cpp Changeset: 5a9fa2ba85f0 Author: dcubed Date: 2013-04-21 20:41 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/5a9fa2ba85f0 8012907: anti-delta fix for 8010992 Summary: anti-delta fix for 8010992 until 8012902 can be fixed Reviewed-by: acorn, minqi, rdurbin ! src/os/windows/vm/os_windows.cpp ! src/share/vm/classfile/altHashing.cpp ! src/share/vm/gc_implementation/concurrentMarkSweep/cmsCollectorPolicy.cpp ! src/share/vm/gc_implementation/g1/heapRegionRemSet.cpp ! src/share/vm/memory/allocation.cpp ! src/share/vm/memory/allocation.hpp ! src/share/vm/memory/allocation.inline.hpp ! src/share/vm/memory/cardTableModRefBS.cpp ! src/share/vm/memory/cardTableModRefBS.hpp ! src/share/vm/memory/cardTableRS.cpp ! src/share/vm/memory/cardTableRS.hpp ! src/share/vm/memory/collectorPolicy.cpp ! src/share/vm/opto/idealGraphPrinter.hpp ! src/share/vm/runtime/handles.hpp ! src/share/vm/runtime/reflectionUtils.hpp ! src/share/vm/runtime/synchronizer.cpp ! src/share/vm/runtime/thread.cpp ! src/share/vm/runtime/vmStructs.cpp ! src/share/vm/utilities/events.hpp ! src/share/vm/utilities/quickSort.cpp ! src/share/vm/utilities/workgroup.cpp ! src/share/vm/utilities/workgroup.hpp Changeset: cc12becb22e7 Author: dcubed Date: 2013-04-21 21:05 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/cc12becb22e7 Merge ! src/os/windows/vm/os_windows.cpp ! src/share/vm/memory/allocation.hpp ! src/share/vm/runtime/vmStructs.cpp Changeset: ce6d7e43501c Author: bharadwaj Date: 2013-04-23 08:12 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/ce6d7e43501c 8012961: Do not restrict static interface methods to be private Summary: Lambda changes; spec 0.6.2 - remove the restriction that was added as part of recent changes made to support upcoming changes to compilation of lambda methods. Reviewed-by: dholmes, acorn ! src/share/vm/prims/methodHandles.cpp Changeset: 1ea6a35dcbe5 Author: jiangli Date: 2013-04-23 12:32 -0400 URL: http://hg.openjdk.java.net/graal/graal/rev/1ea6a35dcbe5 8012927: 'assert(nbits == 32 || (-(1 << nbits-1) <= x && x < ( 1 << nbits-1))) failed: value out of range' in interpreter initialization. Summary: Change br_null_short() to br_null(). Reviewed-by: coleenp, hseigel ! src/cpu/sparc/vm/interp_masm_sparc.cpp Changeset: 35c15dad89ea Author: roland Date: 2013-04-16 17:06 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/35c15dad89ea 8011901: Unsafe.getAndAddLong(obj, off, delta) does not work properly with long deltas Summary: instruct xaddL_no_res shouldn't allow 64 bit constants. Reviewed-by: kvn ! src/cpu/x86/vm/x86_64.ad + test/compiler/8011901/Test8011901.java Changeset: 6a3629cf7075 Author: roland Date: 2013-04-24 09:42 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/6a3629cf7075 8011771: runThese crashed with EAV Summary: Array bound check elimination's in block motion doesn't always reset its data structures from one step to the other. Reviewed-by: kvn, twisti ! src/share/vm/c1/c1_RangeCheckElimination.cpp Changeset: 47766e2d2527 Author: jiangli Date: 2013-04-24 18:20 -0400 URL: http://hg.openjdk.java.net/graal/graal/rev/47766e2d2527 8013041: guarantee(this->is8bit(imm8)) failed: Short forward jump exceeds 8-bit offset. Summary: Change jmpb() to jmp(). Reviewed-by: coleenp, rdurbin, dcubed ! src/cpu/x86/vm/templateInterpreter_x86_32.cpp ! src/cpu/x86/vm/templateInterpreter_x86_64.cpp Changeset: e8a7a5995e65 Author: bharadwaj Date: 2013-04-25 13:10 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/e8a7a5995e65 Merge Changeset: c4af77d20454 Author: amurillo Date: 2013-04-26 00:29 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/c4af77d20454 Merge ! .hgtags - make/bsd/makefiles/jvmg.make - make/bsd/makefiles/profiled.make - make/linux/makefiles/jvmg.make - make/linux/makefiles/profiled.make - make/solaris/makefiles/jvmg.make - make/solaris/makefiles/profiled.make - src/os/bsd/vm/chaitin_bsd.cpp - src/os/linux/vm/chaitin_linux.cpp - src/os/solaris/vm/chaitin_solaris.cpp - src/os/windows/vm/chaitin_windows.cpp Changeset: 8482058e74bc Author: amurillo Date: 2013-04-26 00:29 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/8482058e74bc Added tag hs25-b30 for changeset c4af77d20454 ! .hgtags Changeset: d0081bfc425c Author: katleman Date: 2013-05-02 13:35 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/d0081bfc425c Added tag jdk8-b88 for changeset 8482058e74bc ! .hgtags Changeset: 57ac6a688ae6 Author: amurillo Date: 2013-04-26 00:40 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/57ac6a688ae6 8013227: new hotspot build - hs25-b31 Reviewed-by: jcoomes ! make/hotspot_version Changeset: cc70cbbd422e Author: hseigel Date: 2013-04-24 09:00 -0400 URL: http://hg.openjdk.java.net/graal/graal/rev/cc70cbbd422e 8012695: Assertion message displays %u and %s text instead of actual values Summary: USe err_msg() to create a proper assertion message. Reviewed-by: twisti, coleenp, iklam ! src/share/vm/classfile/classFileParser.hpp Changeset: fbca7eaeac2e Author: zgu Date: 2013-04-24 14:55 -0400 URL: http://hg.openjdk.java.net/graal/graal/rev/fbca7eaeac2e 8011218: Kitchensink hanged, likely NMT is to blame Summary: Made NMT query safepoint aware. Reviewed-by: dholmes, coleenp ! src/share/vm/services/memBaseline.cpp ! src/share/vm/services/memBaseline.hpp ! src/share/vm/services/memTracker.cpp Changeset: d587a5c30bd8 Author: coleenp Date: 2013-04-24 16:19 -0400 URL: http://hg.openjdk.java.net/graal/graal/rev/d587a5c30bd8 8011803: release_C_heap_structures is never called for anonymous classes. Summary: Call this function from the ClassLoaderData destructor instead of the system dictionary walk. Reviewed-by: stefank, mgerdin ! src/share/vm/classfile/classLoaderData.cpp ! src/share/vm/classfile/dictionary.cpp ! src/share/vm/oops/instanceKlass.cpp ! src/share/vm/oops/instanceKlass.hpp Changeset: d66a24adbe3f Author: coleenp Date: 2013-04-24 15:57 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/d66a24adbe3f Merge Changeset: 15a99ca4ee34 Author: sspitsyn Date: 2013-04-25 03:58 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/15a99ca4ee34 8007037: JSR 292: the VM_RedefineClasses::append_entry() should do cross-checks with indy operands Summary: References from operands to CP entries and back must be correct after CP merge Reviewed-by: coleenp, twisti Contributed-by: serguei.spitsyn at oracle.com ! src/share/vm/oops/constantPool.cpp ! src/share/vm/oops/constantPool.hpp ! src/share/vm/prims/jvmtiRedefineClasses.cpp ! src/share/vm/prims/jvmtiRedefineClasses.hpp Changeset: c115fac239eb Author: iklam Date: 2013-04-25 12:55 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/c115fac239eb 8008962: NPG: Memory regression: One extra Monitor per ConstantPool Summary: Re-use InstanceKlass::_init_lock locking ConstantPool as well. Reviewed-by: dholmes, coleenp, acorn ! src/share/vm/ci/ciEnv.cpp ! src/share/vm/oops/constantPool.cpp ! src/share/vm/oops/constantPool.hpp ! src/share/vm/oops/cpCache.cpp ! src/share/vm/oops/instanceKlass.cpp ! src/share/vm/oops/instanceKlass.hpp ! src/share/vm/prims/jvmtiEnv.cpp Changeset: 3c9b7ef92c61 Author: dcubed Date: 2013-04-26 08:40 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/3c9b7ef92c61 Merge Changeset: d1644a010f52 Author: emc Date: 2013-04-26 07:34 -0400 URL: http://hg.openjdk.java.net/graal/graal/rev/d1644a010f52 8007154: Remove support for u4 MethodParameter flags fields Summary: Remove support for parsing class files with four-byte flags fields in MethodParameters attributes Reviewed-by: jrose, coleenp ! src/share/vm/classfile/classFileParser.cpp Changeset: f258c5828eb8 Author: hseigel Date: 2013-04-29 16:13 -0400 URL: http://hg.openjdk.java.net/graal/graal/rev/f258c5828eb8 8011773: Some tests on Interned String crashed JVM with OOM Summary: Instead of terminating the VM, throw OutOfMemoryError exceptions. Reviewed-by: coleenp, dholmes ! src/share/vm/classfile/javaClasses.cpp ! src/share/vm/classfile/javaClasses.hpp ! src/share/vm/classfile/symbolTable.cpp ! src/share/vm/memory/allocation.hpp ! src/share/vm/oops/oop.cpp ! src/share/vm/prims/whitebox.cpp Changeset: c53e49efe6a8 Author: hseigel Date: 2013-04-29 16:36 -0400 URL: http://hg.openjdk.java.net/graal/graal/rev/c53e49efe6a8 Merge Changeset: f32b6c267d2e Author: mikael Date: 2013-04-29 11:03 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/f32b6c267d2e 8012015: Use PROT_NONE when reserving memory Summary: Reserved memory had PROT_READ+PROT_WRITE access on Linux/bsd, now changed to PROT_NONE. Reviewed-by: dholmes, ctornqvi ! src/os/bsd/vm/os_bsd.cpp ! src/os/linux/vm/os_linux.cpp ! src/share/vm/prims/whitebox.cpp + test/runtime/memory/ReserveMemory.java ! test/testlibrary/whitebox/sun/hotspot/WhiteBox.java Changeset: 9f96b7a853bc Author: sla Date: 2013-04-30 10:53 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/9f96b7a853bc 8013466: SA crashes when attaching to a process on OS X Reviewed-by: coleenp, rbackman, minqi ! agent/src/os/bsd/MacosxDebuggerLocal.m Changeset: 409d4b59e095 Author: sla Date: 2013-04-30 02:28 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/409d4b59e095 Merge Changeset: ed5a590835a4 Author: zgu Date: 2013-04-30 09:17 -0400 URL: http://hg.openjdk.java.net/graal/graal/rev/ed5a590835a4 8013214: BigApps fails due to 'fatal error: Illegal threadstate encountered: 6' Summary: Grab and drop SR_lock to get the thread to honor the safepoint protocol Reviewed-by: dcubed, coleenp ! src/share/vm/services/memBaseline.cpp Changeset: 746b070f5022 Author: ccheung Date: 2013-04-30 11:56 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/746b070f5022 8011661: Insufficient memory message says "malloc" when sometimes it should say "mmap" Reviewed-by: coleenp, zgu, hseigel ! src/os/solaris/vm/os_solaris.cpp ! src/os_cpu/linux_sparc/vm/os_linux_sparc.cpp ! src/os_cpu/linux_x86/vm/os_linux_x86.cpp ! src/os_cpu/linux_zero/vm/os_linux_zero.cpp ! src/os_cpu/solaris_sparc/vm/os_solaris_sparc.cpp ! src/os_cpu/solaris_x86/vm/os_solaris_x86.cpp ! src/share/vm/asm/assembler.cpp ! src/share/vm/code/stubs.cpp ! src/share/vm/code/vtableStubs.cpp ! src/share/vm/gc_implementation/g1/g1BlockOffsetTable.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/heapRegionRemSet.cpp ! src/share/vm/gc_implementation/parallelScavenge/cardTableExtension.cpp ! src/share/vm/gc_implementation/parallelScavenge/gcTaskThread.cpp ! src/share/vm/gc_implementation/parallelScavenge/objectStartArray.cpp ! src/share/vm/interpreter/interpreterRuntime.cpp ! src/share/vm/memory/allocation.cpp ! src/share/vm/memory/allocation.inline.hpp ! src/share/vm/memory/blockOffsetTable.cpp ! src/share/vm/memory/cardTableModRefBS.cpp ! src/share/vm/oops/oop.cpp ! src/share/vm/prims/jvmtiTagMap.cpp ! src/share/vm/prims/methodHandles.cpp ! src/share/vm/runtime/objectMonitor.cpp ! src/share/vm/runtime/stubRoutines.cpp ! src/share/vm/runtime/synchronizer.cpp ! src/share/vm/utilities/debug.cpp ! src/share/vm/utilities/debug.hpp ! src/share/vm/utilities/vmError.cpp ! src/share/vm/utilities/vmError.hpp ! src/share/vm/utilities/workgroup.cpp Changeset: e4614b063fe1 Author: sla Date: 2013-04-30 21:47 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/e4614b063fe1 8013364: SA-JDI exceptions caused by lack of permissions on OSX should be more verbose about issue cause Reviewed-by: coleenp, rbackman ! agent/src/os/bsd/MacosxDebuggerLocal.m Changeset: 376ff861f611 Author: sla Date: 2013-05-01 01:07 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/376ff861f611 Merge Changeset: b4081e9714ec Author: vladidan Date: 2013-04-30 17:36 -0400 URL: http://hg.openjdk.java.net/graal/graal/rev/b4081e9714ec 8013398: Adjust number of stack guard pages on systems with large memory page size Summary: Auto adjust number of stack guard pages on systems with large memory page size Reviewed-by: bobv, coleenp ! src/os/linux/vm/os_linux.cpp ! src/os/linux/vm/os_linux.hpp Changeset: 1847df492437 Author: vladidan Date: 2013-05-01 10:10 -0400 URL: http://hg.openjdk.java.net/graal/graal/rev/1847df492437 Merge Changeset: 08236d966eea Author: bharadwaj Date: 2013-05-01 08:07 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/08236d966eea 8013418: assert(i == total_args_passed) in AdapterHandlerLibrary::get_adapter since 8-b87 Summary: Do not treat static methods as miranda methods. Reviewed-by: dholmes, acorn ! src/share/vm/oops/klassVtable.cpp + test/runtime/lambda-features/PublicStaticInterfaceMethodHandling.java Changeset: 8fe2542bdc8d Author: bharadwaj Date: 2013-05-01 09:00 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/8fe2542bdc8d Merge Changeset: a6e09d6dd8e5 Author: dlong Date: 2013-04-24 20:55 -0400 URL: http://hg.openjdk.java.net/graal/graal/rev/a6e09d6dd8e5 8003853: specify offset of IC load in java_to_interp stub Summary: refactored code to allow platform-specific differences Reviewed-by: dlong, twisti Contributed-by: Goetz Lindenmaier + src/cpu/sparc/vm/compiledIC_sparc.cpp ! src/cpu/sparc/vm/sparc.ad + src/cpu/x86/vm/compiledIC_x86.cpp ! src/cpu/x86/vm/x86_32.ad ! src/cpu/x86/vm/x86_64.ad + src/cpu/zero/vm/compiledIC_zero.cpp ! src/share/vm/adlc/main.cpp ! src/share/vm/code/compiledIC.cpp ! src/share/vm/code/compiledIC.hpp ! src/share/vm/opto/output.cpp Changeset: e10e43e58e92 Author: dlong Date: 2013-04-24 21:11 -0400 URL: http://hg.openjdk.java.net/graal/graal/rev/e10e43e58e92 Merge - make/bsd/makefiles/jvmg.make - make/bsd/makefiles/profiled.make - make/linux/makefiles/jvmg.make - make/linux/makefiles/profiled.make - make/solaris/makefiles/jvmg.make - make/solaris/makefiles/profiled.make ! src/cpu/sparc/vm/sparc.ad ! src/cpu/x86/vm/x86_32.ad ! src/cpu/x86/vm/x86_64.ad - src/os/bsd/vm/chaitin_bsd.cpp - src/os/linux/vm/chaitin_linux.cpp - src/os/solaris/vm/chaitin_solaris.cpp - src/os/windows/vm/chaitin_windows.cpp ! src/share/vm/opto/output.cpp - test/gc/6941923/test6941923.sh - test/gc/TestVerifyBeforeGCDuringStartup.java - test/runtime/NMT/AllocTestType.java Changeset: 3c0584fec1e6 Author: dholmes Date: 2013-04-28 18:24 -0400 URL: http://hg.openjdk.java.net/graal/graal/rev/3c0584fec1e6 8010428: Special -agentpath checks needed with minimal VM to produce proper error message Reviewed-by: dholmes, alanb, cjplummer, olagneau Contributed-by: Carlos Lucasius ! src/share/vm/runtime/arguments.cpp Changeset: 78603aa58b1e Author: jiangli Date: 2013-04-26 16:58 -0400 URL: http://hg.openjdk.java.net/graal/graal/rev/78603aa58b1e Merge ! src/cpu/x86/vm/x86_64.ad Changeset: e01e02a9fcb6 Author: jiangli Date: 2013-04-29 01:58 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/e01e02a9fcb6 Merge ! src/share/vm/runtime/arguments.cpp Changeset: 052caeaeb771 Author: jiangli Date: 2013-05-02 12:16 -0400 URL: http://hg.openjdk.java.net/graal/graal/rev/052caeaeb771 Merge Changeset: 8f9fae155577 Author: jiangli Date: 2013-05-02 13:12 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/8f9fae155577 Merge Changeset: c23dbf0e8ab7 Author: jmasa Date: 2013-03-01 10:19 -0800 URL: http://hg.openjdk.java.net/graal/graal/rev/c23dbf0e8ab7 8011268: NPG: Free unused VirtualSpaceNodes Reviewed-by: mgerdin, coleenp, johnc ! src/share/vm/classfile/classLoaderData.cpp ! src/share/vm/memory/metachunk.cpp ! src/share/vm/memory/metachunk.hpp ! src/share/vm/memory/metaspace.cpp ! src/share/vm/memory/metaspace.hpp Changeset: bfe3be9ebd6c Author: kevinw Date: 2013-04-18 17:02 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/bfe3be9ebd6c 7109087: gc/7072527/TestFullGCCount.java fails when GC is set in command-line Reviewed-by: mgerdin ! test/gc/7072527/TestFullGCCount.java Changeset: 12927badda81 Author: kevinw Date: 2013-04-19 05:14 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/12927badda81 Merge Changeset: d391427ddc29 Author: mgerdin Date: 2013-04-22 10:10 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/d391427ddc29 Merge Changeset: a08c80e9e1e5 Author: stefank Date: 2013-04-22 20:27 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/a08c80e9e1e5 8012687: Remove unused is_root checks and closures Reviewed-by: tschatzl, jmasa ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp ! src/share/vm/gc_implementation/g1/g1MarkSweep.cpp ! src/share/vm/gc_implementation/parallelScavenge/psMarkSweep.cpp ! src/share/vm/gc_implementation/parallelScavenge/psMarkSweep.hpp ! src/share/vm/gc_implementation/parallelScavenge/psParallelCompact.cpp ! src/share/vm/gc_implementation/parallelScavenge/psParallelCompact.hpp ! src/share/vm/gc_implementation/shared/markSweep.cpp ! src/share/vm/gc_implementation/shared/markSweep.hpp ! src/share/vm/gc_implementation/shared/markSweep.inline.hpp ! src/share/vm/memory/genCollectedHeap.cpp ! src/share/vm/memory/genCollectedHeap.hpp ! src/share/vm/memory/genMarkSweep.cpp ! src/share/vm/memory/sharedHeap.cpp ! src/share/vm/memory/sharedHeap.hpp Changeset: ebded0261dfc Author: jmasa Date: 2013-04-22 22:00 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/ebded0261dfc 8012111: Remove warning about CMS generation shrinking. Reviewed-by: johnc, brutisso, stefank ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp + test/gc/concurrentMarkSweep/GuardShrinkWarning.java Changeset: 1cb4795305b9 Author: mgerdin Date: 2013-04-23 08:39 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/1cb4795305b9 8011802: NPG: init_dependencies in class loader data graph can cause invalid CLD Summary: Restructure initialization of ClassLoaderData to not add a new instance if init_dependencies fail Reviewed-by: stefank, coleenp ! src/share/vm/classfile/classLoaderData.cpp ! src/share/vm/classfile/classLoaderData.hpp ! src/share/vm/classfile/classLoaderData.inline.hpp Changeset: 5c93c1f61226 Author: johnc Date: 2013-04-18 10:09 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/5c93c1f61226 8011724: G1: Stack allocate instances of HeapRegionRemSetIterator Summary: Stack allocate instances of HeapRegionRemSetIterator during RSet scanning. Reviewed-by: brutisso, jwilhelm ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp ! src/share/vm/gc_implementation/g1/g1RemSet.cpp ! src/share/vm/gc_implementation/g1/g1RemSet.hpp ! src/share/vm/gc_implementation/g1/heapRegionRemSet.cpp ! src/share/vm/gc_implementation/g1/heapRegionRemSet.hpp ! src/share/vm/gc_implementation/g1/sparsePRT.cpp ! src/share/vm/gc_implementation/g1/sparsePRT.hpp Changeset: 868d87ed63c8 Author: jmasa Date: 2013-02-12 14:15 -0800 URL: http://hg.openjdk.java.net/graal/graal/rev/868d87ed63c8 8008966: NPG: Inefficient Metaspace counter functions cause large young GC regressions Reviewed-by: mgerdin, coleenp ! src/share/vm/classfile/classLoaderData.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/parallelScavenge/psMarkSweep.cpp ! src/share/vm/gc_implementation/parallelScavenge/psParallelCompact.cpp ! src/share/vm/gc_implementation/shared/vmGCOperations.cpp ! src/share/vm/memory/filemap.cpp ! src/share/vm/memory/genCollectedHeap.cpp ! src/share/vm/memory/metaspace.cpp ! src/share/vm/memory/metaspace.hpp ! src/share/vm/memory/metaspaceCounters.cpp ! src/share/vm/memory/metaspaceCounters.hpp ! src/share/vm/memory/metaspaceShared.cpp Changeset: 9d75bcd7c890 Author: mgerdin Date: 2013-04-24 19:55 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/9d75bcd7c890 8013136: NPG: Parallel class loading tests fail after fix for JDK-8011802 Summary: Move initialization of dependencies to before allocation of CLD Reviewed-by: stefank, coleenp ! src/share/vm/classfile/classLoaderData.cpp ! src/share/vm/classfile/classLoaderData.hpp Changeset: d50cc62e94ff Author: johnc Date: 2013-04-24 14:48 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/d50cc62e94ff 8012715: G1: GraphKit accesses PtrQueue::_index as int but is size_t Summary: In graphKit INT operations were generated to access PtrQueue::_index which has type size_t. This is 64 bit on 64-bit machines. No problems occur on little endian machines as long as the index fits into 32 bit, but on big endian machines the upper part is read, which is zero. This leads to unnecessary branches to the slow path in the runtime. Reviewed-by: twisti, johnc Contributed-by: Martin Doerr ! src/share/vm/opto/graphKit.cpp Changeset: b06ac540229e Author: stefank Date: 2013-04-24 20:13 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/b06ac540229e 8013132: Add a flag to turn off the output of the verbose verification code Reviewed-by: johnc, brutisso ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.hpp ! src/share/vm/gc_implementation/g1/concurrentMark.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1MarkSweep.cpp ! src/share/vm/gc_implementation/parallelScavenge/psMarkSweep.cpp ! src/share/vm/gc_implementation/parallelScavenge/psParallelCompact.cpp ! src/share/vm/gc_implementation/parallelScavenge/psScavenge.cpp ! src/share/vm/memory/genCollectedHeap.cpp ! src/share/vm/memory/universe.cpp ! src/share/vm/memory/universe.hpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/thread.cpp ! src/share/vm/runtime/vmThread.cpp ! src/share/vm/runtime/vm_operations.hpp Changeset: b294421fa3c5 Author: brutisso Date: 2013-04-26 09:53 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/b294421fa3c5 8012915: ReservedSpace::align_reserved_region() broken on Windows Summary: remove unused constructors and helper methods for ReservedHeapSpace and ReservedSpace Reviewed-by: mgerdin, jmasa, johnc, tschatzl ! src/share/vm/runtime/virtualspace.cpp ! src/share/vm/runtime/virtualspace.hpp Changeset: 2f50bc369470 Author: stefank Date: 2013-04-26 10:40 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/2f50bc369470 8013160: NPG: Remove unnecessary mark stack draining after CodeCache::do_unloading Reviewed-by: coleenp, mgerdin ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp ! src/share/vm/gc_implementation/g1/g1MarkSweep.cpp ! src/share/vm/gc_implementation/parallelScavenge/psMarkSweep.cpp ! src/share/vm/gc_implementation/parallelScavenge/psParallelCompact.cpp ! src/share/vm/memory/genMarkSweep.cpp Changeset: 3edf23423bb2 Author: johnc Date: 2013-04-26 10:57 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/3edf23423bb2 8011898: gc/TestVerifyBeforeGCDuringStartup.java: java.lang.RuntimeException: '[Verifying' missing from stdout/stderr: [Error: Could not find or load main class] Summary: System.getProperty("test.java.opts") can return NULL, which gets converted to to the empty string, and the child java command then interprets that as the name of the main class. Reviewed-by: jmasa, brutisso ! test/gc/TestVerifyDuringStartup.java Changeset: caac22686b17 Author: mgerdin Date: 2013-04-29 09:31 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/caac22686b17 Merge ! src/share/vm/gc_implementation/g1/heapRegionRemSet.cpp ! src/share/vm/runtime/thread.cpp Changeset: 601183f604b2 Author: mgerdin Date: 2013-04-29 13:07 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/601183f604b2 8013129: Possible deadlock with Metaspace locks due to mixed usage of safepoint aware and non-safepoint aware locking Summary: Change Metaspace::deallocate to take lock with _no_safepoint_check_flag Reviewed-by: coleenp, jmasa, dholmes ! src/share/vm/memory/metaspace.cpp Changeset: 9075044ed66b Author: ehelin Date: 2013-04-30 16:36 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/9075044ed66b 8008541: Remove old code in HotSpot that supported the jmap -permstat functionality Reviewed-by: sla, brutisso ! agent/src/share/classes/sun/jvm/hotspot/tools/JMap.java Changeset: d58c62b7447d Author: mgerdin Date: 2013-05-02 19:28 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/d58c62b7447d Merge ! src/share/vm/classfile/classLoaderData.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/heapRegionRemSet.cpp Changeset: cbd4ce58f1f3 Author: mgerdin Date: 2013-05-02 16:41 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/cbd4ce58f1f3 Merge Changeset: e12c9b3740db Author: vlivanov Date: 2013-04-25 11:02 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/e12c9b3740db 8012260: ciReplay: Include PID into the name of replay data file Reviewed-by: kvn, twisti ! src/os/bsd/vm/os_bsd.cpp ! src/os/linux/vm/os_linux.cpp ! src/os/posix/vm/os_posix.cpp ! src/os/solaris/vm/os_solaris.cpp ! src/os/windows/vm/os_windows.cpp ! src/share/vm/ci/ciEnv.cpp ! src/share/vm/ci/ciEnv.hpp ! src/share/vm/ci/ciReplay.cpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/os.hpp ! src/share/vm/utilities/ostream.hpp ! src/share/vm/utilities/vmError.cpp Changeset: dc7db03f5aa2 Author: iignatyev Date: 2013-04-25 11:04 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/dc7db03f5aa2 8012337: Change Whitebox implementation to make absence of method in Whitebox.class not fatal Reviewed-by: kvn, vlivanov ! src/share/vm/prims/whitebox.cpp + test/sanity/WhiteBox.java Changeset: 7b23cb975cf2 Author: iignatyev Date: 2013-04-25 11:09 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/7b23cb975cf2 8011675: adding compilation level to replay data Reviewed-by: kvn, vlivanov - agent/doc/c2replay.html + agent/doc/cireplay.html ! agent/doc/clhsdb.html ! agent/src/share/classes/sun/jvm/hotspot/ci/ciEnv.java ! agent/src/share/classes/sun/jvm/hotspot/code/NMethod.java ! agent/src/share/classes/sun/jvm/hotspot/compiler/CompileTask.java ! src/share/vm/ci/ciEnv.cpp ! src/share/vm/ci/ciReplay.cpp ! src/share/vm/compiler/compileBroker.cpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/vmStructs.cpp + test/compiler/ciReplay/TestSA.sh + test/compiler/ciReplay/TestVM.sh + test/compiler/ciReplay/TestVM_no_comp_level.sh + test/compiler/ciReplay/common.sh Changeset: 247342108a11 Author: neliasso Date: 2013-04-23 13:48 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/247342108a11 8010332: removed unused method: ciMethod::uses_monitors Reviewed-by: twisti, roland Contributed-by: albert.noll at oracle.com ! src/share/vm/ci/ciMethod.hpp Changeset: a5c95fcf7cb7 Author: neliasso Date: 2013-04-23 18:06 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/a5c95fcf7cb7 8012157: removed unused code in SharedRuntime::handle_wrong_method Reviewed-by: kvn, roland, rbackman Contributed-by: albert.noll at oracle.com ! src/share/vm/runtime/sharedRuntime.cpp Changeset: d1c9384eecb4 Author: iignatyev Date: 2013-04-26 07:21 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/d1c9384eecb4 8012322: Tiered: CompilationPolicy::can_be_compiled(CompLevel_all) mistakenly return false Reviewed-by: kvn, vlivanov ! src/share/vm/classfile/classLoader.cpp ! src/share/vm/runtime/compilationPolicy.cpp ! test/compiler/whitebox/CompilerWhiteBoxTest.java ! test/compiler/whitebox/MakeMethodNotCompilableTest.java Changeset: 93b8272814cf Author: vlivanov Date: 2013-04-26 08:33 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/93b8272814cf Merge Changeset: 0b55a78c6be5 Author: bharadwaj Date: 2013-04-26 10:52 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/0b55a78c6be5 Merge - agent/doc/c2replay.html ! src/os/windows/vm/os_windows.cpp ! src/share/vm/runtime/vmStructs.cpp Changeset: fd49109d0d88 Author: bharadwaj Date: 2013-04-26 14:50 -0400 URL: http://hg.openjdk.java.net/graal/graal/rev/fd49109d0d88 Merge Changeset: 487d442ef257 Author: jiangli Date: 2013-04-26 16:21 -0400 URL: http://hg.openjdk.java.net/graal/graal/rev/487d442ef257 8013036: vm/runtime/simpleThresholdPolicy.cpp: assert(mcs != NULL). Summary: Change the assert to if check as MethodCounters could be NULL under TieredCompilation. Reviewed-by: kvn, twisti ! src/share/vm/runtime/simpleThresholdPolicy.cpp Changeset: 62b683108582 Author: jiangli Date: 2013-04-26 14:41 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/62b683108582 Merge Changeset: 0cfa93c2fcc4 Author: neliasso Date: 2013-04-29 13:20 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/0cfa93c2fcc4 8012547: Code cache flushing can get stuck reclaming of memory Summary: Keep sweeping regardless of if we are flushing Reviewed-by: kvn, twisti ! src/share/vm/code/codeCache.cpp ! src/share/vm/code/codeCache.hpp ! src/share/vm/compiler/compileBroker.cpp ! src/share/vm/oops/method.cpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/sweeper.cpp ! src/share/vm/runtime/sweeper.hpp Changeset: e4e131b15d5c Author: roland Date: 2013-05-02 10:27 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/e4e131b15d5c 8013532: Remove unused parameter "compiler" from DTRACE_METHOD_COMPILE* macros Summary: remove unused parameter in dtrace macros Reviewed-by: kvn, roland Contributed-by: albert.noll at oracle.com ! src/share/vm/compiler/compileBroker.cpp Changeset: 9ce110b1d14a Author: kvn Date: 2013-05-02 18:50 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/9ce110b1d14a Merge - agent/doc/c2replay.html ! src/os/bsd/vm/os_bsd.cpp ! src/os/linux/vm/os_linux.cpp ! src/os/solaris/vm/os_solaris.cpp ! src/share/vm/ci/ciEnv.cpp ! src/share/vm/prims/whitebox.cpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/utilities/vmError.cpp Changeset: 4ec913499722 Author: amurillo Date: 2013-05-03 08:10 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/4ec913499722 Merge - agent/doc/c2replay.html Changeset: 9c1fe0b419b4 Author: amurillo Date: 2013-05-03 08:10 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/9c1fe0b419b4 Added tag hs25-b31 for changeset 4ec913499722 ! .hgtags Changeset: 7d56b68a9672 Author: katleman Date: 2013-05-09 10:03 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/7d56b68a9672 Added tag jdk8-b89 for changeset 9c1fe0b419b4 ! .hgtags Changeset: 625ddb0052e1 Author: amurillo Date: 2013-05-03 08:19 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/625ddb0052e1 8013800: new hotspot build - hs25-b32 Reviewed-by: jcoomes ! make/hotspot_version Changeset: c456f4510385 Author: sla Date: 2013-05-03 12:24 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/c456f4510385 8008453: JvmtiClassFileReconstituter does not recognize default methods Reviewed-by: acorn, sspitsyn ! src/share/vm/prims/jvmtiClassFileReconstituter.cpp Changeset: 0380df7c3cd0 Author: sla Date: 2013-05-03 12:26 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/0380df7c3cd0 8013785: Respect EXTRA_CFLAGS on windows Reviewed-by: mgronlun, rbackman, kvn ! make/windows/makefiles/compile.make ! make/windows/makefiles/defs.make Changeset: 31a4e55f8c9d Author: fparain Date: 2013-05-03 05:05 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/31a4e55f8c9d 8004095: Add support for JMX interface to Diagnostic Framework and Commands Reviewed-by: acorn, sla ! src/share/vm/classfile/vmSymbols.hpp ! src/share/vm/runtime/serviceThread.cpp ! src/share/vm/services/attachListener.cpp ! src/share/vm/services/diagnosticCommand.cpp ! src/share/vm/services/diagnosticCommand.hpp ! src/share/vm/services/diagnosticFramework.cpp ! src/share/vm/services/diagnosticFramework.hpp ! src/share/vm/services/jmm.h ! src/share/vm/services/management.cpp ! src/share/vm/services/management.hpp ! src/share/vm/services/nmtDCmd.cpp ! src/share/vm/services/nmtDCmd.hpp Changeset: 39fba0d6d9ad Author: fparain Date: 2013-05-03 05:17 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/39fba0d6d9ad Merge Changeset: bf089b838c9e Author: ccheung Date: 2013-05-02 16:55 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/bf089b838c9e 8012641: Perf_CreateLong creates perf counter of incorrect type Reviewed-by: mchung, hseigel, coleenp ! src/share/vm/prims/perf.cpp Changeset: a55b7b8c34af Author: zgu Date: 2013-05-03 13:00 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/a55b7b8c34af Merge Changeset: 9c8e2f44228d Author: dcubed Date: 2013-05-03 15:51 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/9c8e2f44228d Merge Changeset: 800078be49d2 Author: hseigel Date: 2013-05-06 09:10 -0400 URL: http://hg.openjdk.java.net/graal/graal/rev/800078be49d2 8013648: Guarantee(VerifyBeforeGC || VerifyDuringGC || VerifyBeforeExit || VerifyAfterGC) failed: too expensive Summary: Fix code to call correct version of function find_class(). Reviewed-by: coleenp, rdurbin, dcubed ! src/share/vm/classfile/systemDictionary.cpp Changeset: c18152e0554e Author: zgu Date: 2013-05-06 11:15 -0400 URL: http://hg.openjdk.java.net/graal/graal/rev/c18152e0554e 8013120: NMT: Kitchensink crashes with assert(next_region == NULL || !next_region->is_committed_region()) failed: Sanity check Summary: Fixed NMT to deal with releasing virtual memory region when there are still committed regions within it Reviewed-by: acorn, coleenp ! src/share/vm/memory/allocation.inline.hpp ! src/share/vm/runtime/os.cpp ! src/share/vm/runtime/os.hpp ! src/share/vm/services/memSnapshot.cpp + test/runtime/NMT/ReleaseCommittedMemory.java Changeset: da4d87770781 Author: zgu Date: 2013-05-06 08:49 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/da4d87770781 Merge Changeset: d9b08d62b95e Author: acorn Date: 2013-05-02 10:58 -0400 URL: http://hg.openjdk.java.net/graal/graal/rev/d9b08d62b95e 8010783: assert(s->refcount() != 0) failed: for create_overpasses Reviewed-by: kvn, dcubed ! src/share/vm/classfile/bytecodeAssembler.cpp Changeset: b7f3bf2ba33b Author: acorn Date: 2013-05-06 10:20 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/b7f3bf2ba33b Merge - agent/doc/c2replay.html Changeset: f916d5986c86 Author: acorn Date: 2013-05-06 12:36 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/f916d5986c86 Merge Changeset: 187154b7a226 Author: sla Date: 2013-05-06 19:49 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/187154b7a226 8009615: JvmtiClassFileReconstituter does not create BootstrapMethod attributes Reviewed-by: coleenp, sspitsyn ! src/share/vm/prims/jvmtiClassFileReconstituter.cpp ! src/share/vm/prims/jvmtiClassFileReconstituter.hpp Changeset: 3ecc6b9940de Author: sla Date: 2013-05-07 01:25 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/3ecc6b9940de Merge Changeset: b5fef8013a95 Author: sla Date: 2013-05-07 14:04 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/b5fef8013a95 8014044: Spelling error in JDK-8009615: boostrapmethod Reviewed-by: sspitsyn, coleenp ! src/share/vm/prims/jvmtiClassFileReconstituter.cpp ! src/share/vm/prims/jvmtiClassFileReconstituter.hpp Changeset: f6a055fcf47d Author: sla Date: 2013-05-07 14:33 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/f6a055fcf47d 8005038: remove crufty '_g' support from SA Reviewed-by: coleenp, mgronlun, rbackman ! agent/src/os/bsd/ps_core.c ! agent/src/os/linux/ps_core.c ! agent/src/os/solaris/proc/saproc.cpp ! agent/src/share/classes/sun/jvm/hotspot/HotSpotAgent.java ! agent/src/share/classes/sun/jvm/hotspot/LinuxVtblAccess.java ! agent/src/share/classes/sun/jvm/hotspot/debugger/bsd/BsdDebuggerLocal.java ! agent/src/share/classes/sun/jvm/hotspot/debugger/linux/LinuxDebuggerLocal.java Changeset: 33bcd9ead1d5 Author: ctornqvi Date: 2013-05-07 21:36 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/33bcd9ead1d5 8009577: Test test/closed/runtime/classunload broken Summary: Fixed tests to use new way of utilizing the WB API, fixed issue with where custom classloader got the classes from Reviewed-by: collins, mgerdin, zgu + test/runtime/ClassUnload/KeepAliveClass.java + test/runtime/ClassUnload/KeepAliveClassLoader.java + test/runtime/ClassUnload/KeepAliveObject.java + test/runtime/ClassUnload/KeepAliveSoftReference.java + test/runtime/ClassUnload/UnloadTest.java + test/runtime/ClassUnload/classes/test/Empty.java + test/runtime/testlibrary/ClassUnloadCommon.java Changeset: 58bb870a0cbd Author: emc Date: 2013-05-07 13:45 -0400 URL: http://hg.openjdk.java.net/graal/graal/rev/58bb870a0cbd 8009729: Refix hotspot jni_.h JNIEXPORT and JNIIMPORT definitions to match jdk version Summary: Update JNIEXPORT and JNIIMPORT to work with other compilers that don't necessarily have the __attribute__ type qualifier Reviewed-by: dholmes, dcubed, coleenp ! src/cpu/sparc/vm/jni_sparc.h ! src/cpu/x86/vm/jni_x86.h ! src/cpu/zero/vm/jni_zero.h Changeset: 7243490a6847 Author: coleenp Date: 2013-05-07 14:30 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/7243490a6847 Merge Changeset: e60b3fce2b02 Author: jiangli Date: 2013-05-06 19:57 -0400 URL: http://hg.openjdk.java.net/graal/graal/rev/e60b3fce2b02 8013067: Zero builds are broken after 8010862. Summary: Fixed broken Zero build. Reviewed-by: twisti, coleenp, kvn ! src/cpu/zero/vm/cppInterpreter_zero.cpp ! src/share/vm/interpreter/bytecodeInterpreter.cpp ! src/share/vm/oops/method.hpp Changeset: 27d2d456cd96 Author: jiangli Date: 2013-05-06 20:11 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/27d2d456cd96 Merge Changeset: 6b388e7d4905 Author: bpittore Date: 2013-05-07 10:19 -0400 URL: http://hg.openjdk.java.net/graal/graal/rev/6b388e7d4905 8013633: Cleanup platform ifdefs in unsafe.cpp Summary: Replace ifdefs with SUPPORTS_NATIVE_CX8 set in platform include file Reviewed-by: dholmes, dlong ! src/cpu/sparc/vm/globalDefinitions_sparc.hpp ! src/cpu/x86/vm/globalDefinitions_x86.hpp ! src/share/vm/prims/unsafe.cpp Changeset: a258a8351528 Author: vladidan Date: 2013-05-07 10:36 -0400 URL: http://hg.openjdk.java.net/graal/graal/rev/a258a8351528 Merge - agent/doc/c2replay.html Changeset: d3c98423c146 Author: jiangli Date: 2013-05-09 16:27 -0400 URL: http://hg.openjdk.java.net/graal/graal/rev/d3c98423c146 Merge Changeset: 1d0fba8a2a6d Author: brutisso Date: 2013-05-02 22:35 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/1d0fba8a2a6d 8013574: PrintMalloc conflicts with the command line parsing Summary: Make sure that _num_jvm_args is not updated until the new entry to _jvm_args_array has been added Reviewed-by: johnc, tamao, tschatzl ! src/share/vm/runtime/arguments.cpp Changeset: f14063dcd52a Author: brutisso Date: 2013-05-06 09:16 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/f14063dcd52a 8013791: G1: G1CollectorPolicy::initialize_flags() may set min_alignment > max_alignment Summary: Make sure max alignemnt is at least as large as min alignment Reviewed-by: johnc, jmasa, tschatzl ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.cpp ! src/share/vm/memory/collectorPolicy.cpp + test/gc/g1/TestRegionAlignment.java Changeset: 30860066ae8f Author: jwilhelm Date: 2013-05-06 13:03 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/30860066ae8f Merge ! src/share/vm/runtime/arguments.cpp Changeset: d17700c82d7d Author: tschatzl Date: 2013-05-06 17:19 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/d17700c82d7d 8006088: Incompatible heap size flags accepted by VM Summary: Make processing of minimum, initial and maximum heap size more intiutive by removing previous limitations on allowed values, and make error reporting consistent. Further, fix errors in ergonomic heap sizing. Reviewed-by: johnc, jwilhelm, tamao ! src/share/vm/memory/collectorPolicy.cpp ! src/share/vm/prims/whitebox.cpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/globals.hpp ! test/testlibrary/whitebox/sun/hotspot/WhiteBox.java Changeset: b0d20fa374b4 Author: brutisso Date: 2013-05-06 21:30 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/b0d20fa374b4 8013872: G1: HeapRegionSeq::shrink_by() has invalid assert Summary: Refactored shrink_by() to only use region counts and not byte sizes Reviewed-by: johnc, tschatzl ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/heapRegionSeq.cpp ! src/share/vm/gc_implementation/g1/heapRegionSeq.hpp + test/gc/g1/TestShrinkToOneRegion.java Changeset: a9d568b7df60 Author: jmasa Date: 2013-05-08 16:28 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/a9d568b7df60 8013032: CMS: assert(used() == used_after_gc && used_after_gc <= capacity()) failed: used: 0 used_after_gc: 292080 capacity: 1431699456 Reviewed-by: tschatzl, mgerdin, johnc ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp + test/gc/concurrentMarkSweep/CheckAllocateAndSystemGC.java Changeset: 06ab37f08701 Author: jmasa Date: 2013-05-08 17:12 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/06ab37f08701 8013184: CMS: Call reset_after_compaction() only if a compaction has been done Reviewed-by: mgerdin, johnc, tschatzl ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.hpp + test/gc/concurrentMarkSweep/SystemGCOnForegroundCollector.java Changeset: 923ac8d1df95 Author: jwilhelm Date: 2013-05-09 12:23 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/923ac8d1df95 Merge Changeset: 194f52aa2f23 Author: johnc Date: 2013-05-09 11:16 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/194f52aa2f23 7176479: G1: JVM crashes on T5-8 system with 1.5 TB heap Summary: Refactor G1's hot card cache and card counts table into their own files. Simplify the card counts table, including removing the encoding of the card index in each entry. The card counts table now has a 1:1 correspondence with the cards spanned by heap. Space for the card counts table is reserved from virtual memory (rather than C heap) during JVM startup and is committed/expanded when the heap is expanded. Changes were also reviewed-by Vitaly Davidovich. Reviewed-by: tschatzl, jmasa ! make/excludeSrc.make ! src/share/vm/gc_implementation/g1/concurrentG1Refine.cpp ! src/share/vm/gc_implementation/g1/concurrentG1Refine.hpp + src/share/vm/gc_implementation/g1/g1CardCounts.cpp + src/share/vm/gc_implementation/g1/g1CardCounts.hpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1GCPhaseTimes.cpp ! src/share/vm/gc_implementation/g1/g1GCPhaseTimes.hpp + src/share/vm/gc_implementation/g1/g1HotCardCache.cpp + src/share/vm/gc_implementation/g1/g1HotCardCache.hpp ! src/share/vm/gc_implementation/g1/g1RemSet.cpp ! src/share/vm/gc_implementation/g1/g1RemSet.hpp ! src/share/vm/gc_implementation/g1/g1_globals.hpp ! src/share/vm/runtime/arguments.cpp Changeset: 73652d89e7c4 Author: stefank Date: 2013-05-10 09:24 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/73652d89e7c4 Merge Changeset: 69494caf5790 Author: amurillo Date: 2013-05-10 11:14 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/69494caf5790 Merge Changeset: 1ae0472ff3a0 Author: amurillo Date: 2013-05-10 11:14 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/1ae0472ff3a0 Added tag hs25-b32 for changeset 69494caf5790 ! .hgtags Changeset: 1cdbd42c3e49 Author: katleman Date: 2013-05-16 12:14 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/1cdbd42c3e49 Added tag jdk8-b90 for changeset 1ae0472ff3a0 ! .hgtags Changeset: 6114c49b31b5 Author: amurillo Date: 2013-05-10 11:27 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/6114c49b31b5 8014279: new hotspot build - hs25-b33 Reviewed-by: jcoomes ! make/hotspot_version Changeset: 712a1e9c91f3 Author: coleenp Date: 2013-05-07 09:46 -0400 URL: http://hg.openjdk.java.net/graal/graal/rev/712a1e9c91f3 8013063: nsk/jvmti/RetransformClasses/retransform001 failed debug version on os::free Summary: Clear out class_file_bytes so they aren't deallocated twice Reviewed-by: dcubed, sspitsyn ! src/share/vm/prims/jvmtiRedefineClasses.cpp Changeset: 4674e409a9e6 Author: coleenp Date: 2013-05-07 18:51 -0400 URL: http://hg.openjdk.java.net/graal/graal/rev/4674e409a9e6 8014024: NPG: keep compiled ic methods from being deallocated in redefine classes Summary: Walk the compiledIC relocation records to keep Method* from being deallocated. Reviewed-by: dlong, kvn ! src/share/vm/code/nmethod.cpp Changeset: a1cc1d1e7ce5 Author: coleenp Date: 2013-05-07 16:17 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/a1cc1d1e7ce5 Merge Changeset: 28ae1d38d296 Author: coleenp Date: 2013-05-07 18:46 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/28ae1d38d296 Merge Changeset: 64340da5b68c Author: hseigel Date: 2013-05-08 08:20 -0400 URL: http://hg.openjdk.java.net/graal/graal/rev/64340da5b68c 8007018: RFE: -XX:+UseLargePages does not work with CDS Summary: Remove command line restriction. It should just work. Reviewed-by: ctornqvi, coleenp, dholmes ! src/share/vm/runtime/arguments.cpp Changeset: cbfe859bd244 Author: sla Date: 2013-05-08 15:37 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/cbfe859bd244 8013591: compiler/ciReplay/TestSA.sh fails in nightly Reviewed-by: coleenp, rbackman, dholmes ! agent/src/share/classes/sun/jvm/hotspot/ci/ciMethod.java ! agent/src/share/classes/sun/jvm/hotspot/oops/Method.java ! agent/src/share/classes/sun/jvm/hotspot/oops/MethodData.java Changeset: 0dc028fd5101 Author: sla Date: 2013-05-08 10:14 -0400 URL: http://hg.openjdk.java.net/graal/graal/rev/0dc028fd5101 Merge Changeset: 39ead0411f07 Author: bharadwaj Date: 2013-05-08 14:18 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/39ead0411f07 8013875: Incorrect vtable index being set during methodHandle creation for static Summary: Set vtable index as appropriate for static interface methods and for interface methods invoked via invokespecial. To be improved in a later enhancement to CallInfo. Reviewed-by: jrose, twisti ! src/share/vm/prims/methodHandles.cpp Changeset: 711016f146fd Author: dholmes Date: 2013-05-08 19:28 -0400 URL: http://hg.openjdk.java.net/graal/graal/rev/711016f146fd 8006997: ContendedPaddingWidth should be range-checked Summary: Constrain between zero and 8K Reviewed-by: dholmes, rbackman Contributed-by: Aleksey Shipilev ! src/share/vm/runtime/arguments.cpp Changeset: 9b77ca4ce35e Author: dholmes Date: 2013-05-08 19:38 -0400 URL: http://hg.openjdk.java.net/graal/graal/rev/9b77ca4ce35e Merge ! src/share/vm/runtime/arguments.cpp Changeset: c272092594bd Author: dholmes Date: 2013-05-08 21:06 -0400 URL: http://hg.openjdk.java.net/graal/graal/rev/c272092594bd Merge Changeset: 0b7f78069732 Author: rbackman Date: 2013-05-08 11:21 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/0b7f78069732 8008255: jvmtiExport.cpp::post_to_env() does not check malloc() return Reviewed-by: coleenp, dholmes, sla ! src/share/vm/prims/jvmtiExport.cpp Changeset: 735c995bf1a1 Author: rbackman Date: 2013-05-13 07:53 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/735c995bf1a1 Merge ! src/share/vm/runtime/arguments.cpp Changeset: 92ef81e2f571 Author: minqi Date: 2013-05-10 08:27 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/92ef81e2f571 8003557: NPG: Klass* const k should be const Klass* k. Summary: With NPG, const KlassOop klass which is in fact a definition converted to Klass* const, which is not the original intention. The right usage is converting them to const Klass*. Reviewed-by: coleenp, kvn Contributed-by: yumin.qi at oracle.com ! src/share/vm/c1/c1_Runtime1.cpp ! src/share/vm/classfile/verifier.cpp ! src/share/vm/classfile/verifier.hpp ! src/share/vm/gc_implementation/parallelScavenge/pcTasks.cpp ! src/share/vm/gc_implementation/parallelScavenge/psCompactionManager.cpp ! src/share/vm/gc_implementation/shared/markSweep.cpp ! src/share/vm/memory/heapInspection.cpp ! src/share/vm/memory/heapInspection.hpp ! src/share/vm/memory/universe.cpp ! src/share/vm/memory/universe.hpp ! src/share/vm/oops/constantPool.hpp ! src/share/vm/oops/instanceKlass.cpp ! src/share/vm/oops/instanceKlass.hpp ! src/share/vm/oops/klass.cpp ! src/share/vm/oops/klass.hpp ! src/share/vm/oops/method.cpp ! src/share/vm/oops/method.hpp ! src/share/vm/oops/methodData.hpp ! src/share/vm/prims/jvm.cpp ! src/share/vm/prims/jvmtiTagMap.cpp Changeset: 1fcfc045b229 Author: minqi Date: 2013-05-10 19:30 +0000 URL: http://hg.openjdk.java.net/graal/graal/rev/1fcfc045b229 Merge Changeset: 8b40495b9381 Author: minqi Date: 2013-05-13 18:08 +0000 URL: http://hg.openjdk.java.net/graal/graal/rev/8b40495b9381 Merge ! src/share/vm/oops/method.hpp Changeset: 43083e670adf Author: coleenp Date: 2013-05-13 15:37 -0400 URL: http://hg.openjdk.java.net/graal/graal/rev/43083e670adf 8005056: NPG: Crash after redefining java.lang.Object Summary: Need to walk array class vtables replacing old methods too if j.l.o redefined Reviewed-by: sspitsyn, dcubed, ctornqvi ! src/share/vm/classfile/dictionary.cpp ! src/share/vm/classfile/dictionary.hpp ! src/share/vm/classfile/systemDictionary.cpp ! src/share/vm/classfile/systemDictionary.hpp ! src/share/vm/oops/klass.hpp ! src/share/vm/prims/jvmtiRedefineClasses.cpp ! src/share/vm/prims/jvmtiRedefineClasses.hpp + test/runtime/RedefineObject/Agent.java + test/runtime/RedefineObject/TestRedefineObject.java ! test/testlibrary/ClassFileInstaller.java Changeset: a9270d9ecb13 Author: shade Date: 2013-05-14 11:34 +0400 URL: http://hg.openjdk.java.net/graal/graal/rev/a9270d9ecb13 8014448: Purge PrintCompactFieldsSavings Summary: Remove obsolete debugging code. Reviewed-by: dholmes, kvn Contributed-by: Aleksey Shipilev ! src/share/vm/classfile/classFileParser.cpp ! src/share/vm/runtime/globals.hpp Changeset: f944ba972151 Author: hseigel Date: 2013-05-14 09:17 -0400 URL: http://hg.openjdk.java.net/graal/graal/rev/f944ba972151 8014138: Add VM option to facilitate the writing of CDS tests Summary: Added the -XX:SharedArchiveFile option. Reviewed-by: coleenp, ccheung, acorn, dcubed, zgu ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/globals.hpp + test/runtime/SharedArchiveFile/SharedArchiveFile.java Changeset: f9be75d21404 Author: minqi Date: 2013-05-14 09:41 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/f9be75d21404 8012902: remove use of global operator new - take 2 Summary: The fix of 8010992, disable use of global operator new and new[] which caused failure on some tests. This takes two of the bugs also add ALLOW_OPERATOR_NEW_USAGE to prevent crash for third party code calling operator new of jvm on certain platforms. Reviewed-by: coleenp, dholmes, zgu Contributed-by: yumin.qi at oracle.com ! make/bsd/makefiles/fastdebug.make ! make/bsd/makefiles/vm.make ! src/os/windows/vm/os_windows.cpp ! src/share/vm/ci/ciReplay.cpp ! src/share/vm/classfile/altHashing.cpp ! src/share/vm/gc_implementation/concurrentMarkSweep/cmsCollectorPolicy.cpp ! src/share/vm/gc_implementation/g1/heapRegionRemSet.cpp ! src/share/vm/memory/allocation.cpp ! src/share/vm/memory/allocation.hpp ! src/share/vm/memory/allocation.inline.hpp ! src/share/vm/memory/cardTableModRefBS.cpp ! src/share/vm/memory/cardTableModRefBS.hpp ! src/share/vm/memory/cardTableRS.cpp ! src/share/vm/memory/cardTableRS.hpp ! src/share/vm/memory/collectorPolicy.cpp ! src/share/vm/memory/memRegion.cpp ! src/share/vm/memory/memRegion.hpp ! src/share/vm/opto/idealGraphPrinter.hpp ! src/share/vm/runtime/handles.cpp ! src/share/vm/runtime/handles.hpp ! src/share/vm/runtime/objectMonitor.hpp ! src/share/vm/runtime/reflectionUtils.hpp ! src/share/vm/runtime/unhandledOops.hpp ! src/share/vm/runtime/vmStructs.cpp ! src/share/vm/utilities/events.hpp ! src/share/vm/utilities/quickSort.cpp ! src/share/vm/utilities/workgroup.cpp ! src/share/vm/utilities/workgroup.hpp Changeset: 513a5298c1dd Author: minqi Date: 2013-05-14 17:33 +0000 URL: http://hg.openjdk.java.net/graal/graal/rev/513a5298c1dd Merge Changeset: d15464bfd4d0 Author: roland Date: 2013-05-03 09:32 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/d15464bfd4d0 8012037: Test8009761.java "Failed: init recursive calls: 7224. After deopt 58824" Summary: test shouldn't be run with a modified CompileThreshold Reviewed-by: kvn ! test/compiler/8009761/Test8009761.java Changeset: e76dd894b984 Author: roland Date: 2013-04-24 14:26 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/e76dd894b984 8012292: optimized build with GCC broken Summary: Some #ifndef PRODUCT should be #ifdef ASSERT Reviewed-by: kvn, twisti Contributed-by: gdub ! make/jprt.properties ! src/share/vm/classfile/classFileParser.cpp ! src/share/vm/classfile/vmSymbols.cpp ! src/share/vm/opto/runtime.cpp ! src/share/vm/utilities/quickSort.cpp Changeset: d73c88e524ff Author: kvn Date: 2013-05-03 15:35 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/d73c88e524ff Merge ! src/share/vm/classfile/classFileParser.cpp Changeset: f0bc60565ba8 Author: twisti Date: 2013-05-06 13:53 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/f0bc60565ba8 7196277: JSR 292: Two jck/runtime tests crash on java.lang.invoke.MethodHandle.invokeExact Reviewed-by: jrose, kvn ! src/share/vm/oops/method.cpp ! src/share/vm/prims/methodHandles.cpp ! src/share/vm/prims/nativeLookup.cpp ! src/share/vm/runtime/sharedRuntime.cpp Changeset: aabf54ccedb1 Author: twisti Date: 2013-05-06 19:49 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/aabf54ccedb1 8008772: remove gamma launcher Reviewed-by: kvn, neliasso, ctornqvi ! make/Makefile ! make/bsd/makefiles/buildtree.make - make/bsd/makefiles/launcher.make ! make/bsd/makefiles/vm.make + make/hotspot.script ! make/linux/makefiles/buildtree.make - make/linux/makefiles/launcher.make ! make/linux/makefiles/vm.make ! make/solaris/makefiles/buildtree.make - make/solaris/makefiles/launcher.make ! make/solaris/makefiles/vm.make ! make/windows/makefiles/debug.make ! make/windows/makefiles/fastdebug.make - make/windows/makefiles/launcher.make ! make/windows/makefiles/product.make ! make/windows/makefiles/projectcreator.make ! make/windows/projectfiles/common/Makefile - src/os/posix/launcher/java_md.c - src/os/posix/launcher/java_md.h - src/os/posix/launcher/launcher.script - src/os/windows/launcher/java_md.c - src/os/windows/launcher/java_md.h ! src/share/tools/ProjectCreator/BuildConfig.java ! src/share/tools/ProjectCreator/WinGammaPlatformVC10.java - src/share/tools/launcher/java.c - src/share/tools/launcher/java.h - src/share/tools/launcher/jli_util.c - src/share/tools/launcher/jli_util.h - src/share/tools/launcher/wildcard.c - src/share/tools/launcher/wildcard.h Changeset: 6f3fd5150b67 Author: kvn Date: 2013-05-08 15:08 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/6f3fd5150b67 6934604: enable parts of EliminateAutoBox by default Summary: Resurrected autobox elimination code and enabled part of it by default. Reviewed-by: roland, twisti ! src/share/vm/ci/ciInstanceKlass.cpp ! src/share/vm/ci/ciInstanceKlass.hpp ! src/share/vm/ci/ciMethod.cpp ! src/share/vm/ci/ciMethod.hpp ! src/share/vm/classfile/vmSymbols.hpp ! src/share/vm/compiler/compileBroker.cpp ! src/share/vm/opto/bytecodeInfo.cpp ! src/share/vm/opto/c2_globals.hpp ! src/share/vm/opto/c2compiler.cpp ! src/share/vm/opto/callGenerator.cpp ! src/share/vm/opto/callGenerator.hpp ! src/share/vm/opto/callnode.cpp ! src/share/vm/opto/callnode.hpp ! src/share/vm/opto/cfgnode.cpp ! src/share/vm/opto/compile.cpp ! src/share/vm/opto/compile.hpp ! src/share/vm/opto/doCall.cpp ! src/share/vm/opto/escape.cpp ! src/share/vm/opto/graphKit.cpp ! src/share/vm/opto/ifnode.cpp ! src/share/vm/opto/library_call.cpp ! src/share/vm/opto/loopPredicate.cpp ! src/share/vm/opto/macro.cpp ! src/share/vm/opto/macro.hpp ! src/share/vm/opto/memnode.cpp ! src/share/vm/opto/memnode.hpp ! src/share/vm/opto/multnode.cpp ! src/share/vm/opto/multnode.hpp ! src/share/vm/opto/node.cpp ! src/share/vm/opto/node.hpp ! src/share/vm/opto/parse.hpp ! src/share/vm/opto/parse1.cpp ! src/share/vm/opto/parse2.cpp ! src/share/vm/opto/parse3.cpp ! src/share/vm/opto/parseHelper.cpp ! src/share/vm/opto/phase.cpp ! src/share/vm/opto/phase.hpp ! src/share/vm/opto/phaseX.cpp ! src/share/vm/opto/type.cpp ! src/share/vm/opto/type.hpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/vmStructs.cpp + test/compiler/6934604/TestByteBoxing.java + test/compiler/6934604/TestDoubleBoxing.java + test/compiler/6934604/TestFloatBoxing.java + test/compiler/6934604/TestIntBoxing.java + test/compiler/6934604/TestLongBoxing.java + test/compiler/6934604/TestShortBoxing.java Changeset: 70120f47d403 Author: kvn Date: 2013-05-09 17:28 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/70120f47d403 8014189: JVM crash with SEGV in ConnectionGraph::record_for_escape_analysis() Summary: Add NULL checks and asserts for Type::make_ptr() returned value. Reviewed-by: twisti ! src/share/vm/opto/escape.cpp ! src/share/vm/opto/lcm.cpp ! src/share/vm/opto/library_call.cpp ! src/share/vm/opto/machnode.cpp ! src/share/vm/opto/macro.cpp ! src/share/vm/opto/node.cpp ! src/share/vm/opto/node.hpp ! src/share/vm/opto/output.cpp ! src/share/vm/opto/subnode.cpp Changeset: 8bcfd9ce2c6b Author: twisti Date: 2013-05-13 12:43 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/8bcfd9ce2c6b Merge - make/bsd/makefiles/launcher.make - make/linux/makefiles/launcher.make - make/solaris/makefiles/launcher.make - make/windows/makefiles/launcher.make - src/os/posix/launcher/java_md.c - src/os/posix/launcher/java_md.h - src/os/posix/launcher/launcher.script - src/os/windows/launcher/java_md.c - src/os/windows/launcher/java_md.h - src/share/tools/launcher/java.c - src/share/tools/launcher/java.h - src/share/tools/launcher/jli_util.c - src/share/tools/launcher/jli_util.h - src/share/tools/launcher/wildcard.c - src/share/tools/launcher/wildcard.h ! src/share/vm/classfile/vmSymbols.hpp ! src/share/vm/runtime/arguments.cpp Changeset: 1da5d70655e9 Author: kvn Date: 2013-05-13 14:36 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/1da5d70655e9 8014286: failed java/lang/Math/DivModTests.java after 6934604 changes Summary: Corrected escape state for the result of boxing method. Added force inlining executed boxing methods. Reviewed-by: twisti ! src/share/vm/opto/bytecodeInfo.cpp ! src/share/vm/opto/escape.cpp Changeset: cd6f6fccd287 Author: iignatyev Date: 2013-05-15 22:44 +0400 URL: http://hg.openjdk.java.net/graal/graal/rev/cd6f6fccd287 8014068: TEST_BUG: compiler/ciReplay/TestSA.sh fails on Windows: core wasn't generated Reviewed-by: kvn ! test/compiler/ciReplay/TestSA.sh ! test/compiler/ciReplay/common.sh Changeset: e484fe2abebd Author: twisti Date: 2013-05-16 13:47 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/e484fe2abebd Merge - make/bsd/makefiles/launcher.make ! make/bsd/makefiles/vm.make - make/linux/makefiles/launcher.make - make/solaris/makefiles/launcher.make - make/windows/makefiles/launcher.make - src/os/posix/launcher/java_md.c - src/os/posix/launcher/java_md.h - src/os/posix/launcher/launcher.script - src/os/windows/launcher/java_md.c - src/os/windows/launcher/java_md.h - src/share/tools/launcher/java.c - src/share/tools/launcher/java.h - src/share/tools/launcher/jli_util.c - src/share/tools/launcher/jli_util.h - src/share/tools/launcher/wildcard.c - src/share/tools/launcher/wildcard.h ! src/share/vm/classfile/classFileParser.cpp ! src/share/vm/oops/method.cpp ! src/share/vm/prims/methodHandles.cpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/vmStructs.cpp ! src/share/vm/utilities/quickSort.cpp Changeset: 7a95933197d0 Author: tschatzl Date: 2013-05-13 09:45 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/7a95933197d0 8014058: Regression tests for 8006088 Summary: The patch for 8006088 misses regression tests after a merge error, this CR provides them. Reviewed-by: jwilhelm, tamao, jmasa ! src/share/vm/memory/collectorPolicy.cpp + test/gc/arguments/TestCMSHeapSizeFlags.java + test/gc/arguments/TestG1HeapSizeFlags.java + test/gc/arguments/TestMaxHeapSizeTools.java + test/gc/arguments/TestMinInitialErgonomics.java + test/gc/arguments/TestParallelHeapSizeFlags.java + test/gc/arguments/TestSerialHeapSizeFlags.java Changeset: 4868caa99ecf Author: brutisso Date: 2013-05-13 14:09 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/4868caa99ecf 8014339: Improve assert and remove some dead code from parMarkBitMap.hpp/cpp Reviewed-by: stefank, tschatzl ! src/share/vm/gc_implementation/parallelScavenge/parMarkBitMap.cpp ! src/share/vm/gc_implementation/parallelScavenge/parMarkBitMap.hpp - src/share/vm/gc_implementation/parallelScavenge/parMarkBitMap.inline.hpp ! src/share/vm/gc_implementation/parallelScavenge/psParallelCompact.cpp Changeset: 0a2986f36965 Author: tschatzl Date: 2013-05-14 17:08 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/0a2986f36965 8014489: tests/gc/arguments/Test(Serial|CMS|Parallel|G1)HeapSizeFlags jtreg tests invoke wrong class Summary: Some jtreg tests reference unknown classes in the @run and @build lines. This change fixes them. Reviewed-by: stefank, ehelin ! test/gc/arguments/TestCMSHeapSizeFlags.java ! test/gc/arguments/TestG1HeapSizeFlags.java ! test/gc/arguments/TestParallelHeapSizeFlags.java ! test/gc/arguments/TestSerialHeapSizeFlags.java Changeset: 12f651e29f6b Author: tschatzl Date: 2013-05-15 11:05 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/12f651e29f6b 6843347: Boundary values in some public GC options cause crashes Summary: Setting some public integer options to specific values causes crashes or undefined GC behavior. This patchset adds the necessary argument checking for these options. Reviewed-by: jmasa, brutisso ! src/cpu/sparc/vm/globals_sparc.hpp ! src/cpu/x86/vm/globals_x86.hpp ! src/cpu/zero/vm/globals_zero.hpp ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp ! src/share/vm/gc_implementation/parallelScavenge/psMarkSweep.cpp ! src/share/vm/gc_implementation/parallelScavenge/psMarkSweepDecorator.cpp ! src/share/vm/gc_implementation/shared/markSweep.cpp ! src/share/vm/gc_implementation/shared/markSweep.hpp ! src/share/vm/memory/collectorPolicy.cpp ! src/share/vm/memory/space.hpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/globals.hpp Changeset: eba99d16dc6f Author: tamao Date: 2013-05-15 10:41 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/eba99d16dc6f 8007763: Refactoring: split up compute_generation_free_space() into two functions for class PSAdaptiveSizePolicy Summary: split up compute_generation_free_space() into two functions: compute_eden_space_size() + compute_old_gen_free_space(), each of which (if needed) can be reused without executing an overhead of the other. Reviewed-by: jmasa, tschatzl Contributed-by: tamao ! src/share/vm/gc_implementation/parallelScavenge/psAdaptiveSizePolicy.cpp ! src/share/vm/gc_implementation/parallelScavenge/psAdaptiveSizePolicy.hpp ! src/share/vm/gc_implementation/parallelScavenge/psMarkSweep.cpp ! src/share/vm/gc_implementation/parallelScavenge/psParallelCompact.cpp ! src/share/vm/gc_implementation/parallelScavenge/psScavenge.cpp Changeset: bed55d125e37 Author: johnc Date: 2013-05-15 22:35 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/bed55d125e37 8014408: G1: crashes with assert assert(prev_committed_card_num == _committed_max_card_num) failed Summary: Mismatch in the card number calculation between next and previous committed sizes of the card counts table. Reviewed-by: jmasa, tschatzl ! src/share/vm/gc_implementation/g1/g1CardCounts.cpp ! src/share/vm/gc_implementation/g1/g1CardCounts.hpp Changeset: 05a17f270c7e Author: tschatzl Date: 2013-05-16 13:02 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/05a17f270c7e 8014240: G1: Add remembered set size information to output of G1PrintRegionLivenessInfo Summary: Improve the output of G1PrintRegionLivenessInfo by adding a per-region remembered set size information column Reviewed-by: jwilhelm, johnc ! src/share/vm/gc_implementation/g1/concurrentMark.cpp ! src/share/vm/gc_implementation/g1/concurrentMark.hpp ! src/share/vm/gc_implementation/g1/heapRegionRemSet.cpp + test/gc/g1/TestPrintRegionRememberedSetInfo.java Changeset: 48391ab0687e Author: johnc Date: 2013-05-16 09:24 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/48391ab0687e 8010738: G1: Output for full GCs with +PrintGCDetails should contain perm gen size/meta data change info Summary: Include metaspace information (used, allocated, reserved) in the PrintGCDetails output for full GCs. Reviewed-by: poonam, jmasa, brutisso ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.cpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.hpp + test/gc/g1/TestPrintGCDetails.java Changeset: acac2b03a07f Author: tschatzl Date: 2013-05-16 23:51 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/acac2b03a07f 8014765: VM exits if MaxTenuringThreshold is set below the default InitialTenuringThreshold, and InitialTenuringThreshold is not set Summary: The VM exits when the condition in the subject line applies. The fix sets InitialTenuringThreshold to MaxTenuringThreshold if it is larger than MaxTenuringThreshold and InitialTenuringThreshold has not been set (is default). Reviewed-by: jwilhelm, jmasa, brutisso, johnc ! src/share/vm/runtime/arguments.cpp + test/gc/arguments/TestInitialTenuringThreshold.java Changeset: 2958af1d8c5a Author: jwilhelm Date: 2013-05-17 06:01 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/2958af1d8c5a Merge ! src/share/vm/gc_implementation/g1/heapRegionRemSet.cpp - src/share/vm/gc_implementation/parallelScavenge/parMarkBitMap.inline.hpp ! src/share/vm/gc_implementation/shared/markSweep.cpp ! src/share/vm/memory/collectorPolicy.cpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/globals.hpp Changeset: 2f9ac66165e6 Author: jwilhelm Date: 2013-05-17 08:00 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/2f9ac66165e6 Merge - src/share/vm/gc_implementation/parallelScavenge/parMarkBitMap.inline.hpp ! src/share/vm/runtime/arguments.cpp Changeset: b19517cecc2e Author: amurillo Date: 2013-05-17 08:59 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/b19517cecc2e Merge - make/bsd/makefiles/launcher.make - make/linux/makefiles/launcher.make - make/solaris/makefiles/launcher.make - make/windows/makefiles/launcher.make - src/os/posix/launcher/java_md.c - src/os/posix/launcher/java_md.h - src/os/posix/launcher/launcher.script - src/os/windows/launcher/java_md.c - src/os/windows/launcher/java_md.h - src/share/tools/launcher/java.c - src/share/tools/launcher/java.h - src/share/tools/launcher/jli_util.c - src/share/tools/launcher/jli_util.h - src/share/tools/launcher/wildcard.c - src/share/tools/launcher/wildcard.h - src/share/vm/gc_implementation/parallelScavenge/parMarkBitMap.inline.hpp Changeset: 7cbdf0e3725c Author: amurillo Date: 2013-05-17 08:59 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/7cbdf0e3725c Added tag hs25-b33 for changeset b19517cecc2e ! .hgtags Changeset: ad47de214f0c Author: katleman Date: 2013-05-23 10:47 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/ad47de214f0c Added tag jdk8-b91 for changeset 7cbdf0e3725c ! .hgtags Changeset: 7ec426e29e4c Author: amurillo Date: 2013-05-17 09:10 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/7ec426e29e4c 8014760: new hotspot build - hs25-b34 Reviewed-by: jcoomes ! make/hotspot_version Changeset: f49e0508a38a Author: rbackman Date: 2013-05-15 11:30 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/f49e0508a38a 4965252: JvmtiExport::post_raw_field_modification jni ref handling is odd Reviewed-by: coleenp, sspitsyn ! src/share/vm/prims/jvmtiExport.cpp Changeset: 243469d929e6 Author: ctornqvi Date: 2013-05-16 15:31 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/243469d929e6 8008169: test/runtime/7158804/Test7158804.sh has bad copyright header Summary: Re-wrote test in Java in addition to fixing the Copyright notice. Also reviewed by leonid.mesnik at oracle.com Reviewed-by: coleenp, ctornqvi Contributed-by: Mikhailo Seledtsov - test/runtime/7158804/Test7158804.sh + test/runtime/CommandLine/ConfigFileParsing.java Changeset: 17db82f22f1e Author: ctornqvi Date: 2013-05-16 17:54 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/17db82f22f1e 8014511: runtime/RedefineObject/TestRedefineObject.java has incorrect classname in @run tag Summary: Corrected the class name Reviewed-by: coleenp, ctornqvi, hseigel Contributed-by: Mikhailo Seledtsov ! test/runtime/RedefineObject/TestRedefineObject.java Changeset: 78332b46e604 Author: kevinw Date: 2013-05-16 12:40 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/78332b46e604 6313816: SA: jstack -m fails on Win32 : UnalignedAddressException Reviewed-by: sla, poonam - agent/src/share/classes/sun/jvm/hotspot/debugger/cdbg/basic/amd64/AMD64CFrame.java - agent/src/share/classes/sun/jvm/hotspot/debugger/cdbg/basic/x86/X86CFrame.java ! agent/src/share/classes/sun/jvm/hotspot/debugger/windbg/WindbgCDebugger.java + agent/src/share/classes/sun/jvm/hotspot/debugger/windows/amd64/WindowsAMD64CFrame.java + agent/src/share/classes/sun/jvm/hotspot/debugger/windows/x86/WindowsX86CFrame.java ! make/sa.files Changeset: 205dd30230e1 Author: shade Date: 2013-05-17 01:43 +0400 URL: http://hg.openjdk.java.net/graal/graal/rev/205dd30230e1 8012939: @Contended doesn't work correctly with inheritance Summary: Fix instance_size miscalculation. Reviewed-by: jrose, kvn ! src/share/vm/classfile/classFileParser.cpp + test/runtime/contended/Inheritance1.java Changeset: b334821dad92 Author: dholmes Date: 2013-05-16 21:19 -0400 URL: http://hg.openjdk.java.net/graal/graal/rev/b334821dad92 Merge Changeset: 50e9396d5257 Author: shade Date: 2013-05-17 01:58 +0400 URL: http://hg.openjdk.java.net/graal/graal/rev/50e9396d5257 8014509: @Contended: explicit default value behaves differently from the implicit value Summary: Treat the empty string as the default value tag Reviewed-by: kvn, twisti ! src/share/vm/classfile/classFileParser.cpp + test/runtime/contended/DefaultValue.java Changeset: 074ba6269cf4 Author: dholmes Date: 2013-05-16 22:11 -0400 URL: http://hg.openjdk.java.net/graal/graal/rev/074ba6269cf4 Merge - agent/src/share/classes/sun/jvm/hotspot/debugger/cdbg/basic/amd64/AMD64CFrame.java - agent/src/share/classes/sun/jvm/hotspot/debugger/cdbg/basic/x86/X86CFrame.java Changeset: 1ba508fcd3e2 Author: dholmes Date: 2013-05-16 23:40 -0400 URL: http://hg.openjdk.java.net/graal/graal/rev/1ba508fcd3e2 Merge Changeset: 6ce351ac7339 Author: rdurbin Date: 2013-05-17 08:51 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/6ce351ac7339 7145527: sscanf must use a length in the format string Summary: Remove dead code containing last call to scanf with no string length specifier Reviewed-by: dcubed, coleenp ! src/share/vm/utilities/debug.cpp Changeset: a250c89cf9e3 Author: dcubed Date: 2013-05-17 08:56 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/a250c89cf9e3 Merge Changeset: b5be63340698 Author: dcubed Date: 2013-05-17 11:36 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/b5be63340698 Merge - agent/src/share/classes/sun/jvm/hotspot/debugger/cdbg/basic/amd64/AMD64CFrame.java - agent/src/share/classes/sun/jvm/hotspot/debugger/cdbg/basic/x86/X86CFrame.java ! src/share/vm/classfile/classFileParser.cpp - test/runtime/7158804/Test7158804.sh Changeset: 386b77bf6427 Author: dcubed Date: 2013-05-17 17:52 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/386b77bf6427 Merge - make/bsd/makefiles/launcher.make - make/linux/makefiles/launcher.make - make/solaris/makefiles/launcher.make - make/windows/makefiles/launcher.make - src/os/posix/launcher/java_md.c - src/os/posix/launcher/java_md.h - src/os/posix/launcher/launcher.script - src/os/windows/launcher/java_md.c - src/os/windows/launcher/java_md.h - src/share/tools/launcher/java.c - src/share/tools/launcher/java.h - src/share/tools/launcher/jli_util.c - src/share/tools/launcher/jli_util.h - src/share/tools/launcher/wildcard.c - src/share/tools/launcher/wildcard.h - src/share/vm/gc_implementation/parallelScavenge/parMarkBitMap.inline.hpp Changeset: a5d6f0c3585f Author: iklam Date: 2013-05-18 20:41 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/a5d6f0c3585f 8014262: PrintStringTableStatistics should include more footprint info Summary: Added info for the string/symbol objects and the hash entries Reviewed-by: coleenp, rbackman ! src/share/vm/classfile/symbolTable.cpp ! src/share/vm/utilities/hashtable.cpp ! src/share/vm/utilities/hashtable.hpp Changeset: 5e3573e08a83 Author: shade Date: 2013-05-20 15:43 +0400 URL: http://hg.openjdk.java.net/graal/graal/rev/5e3573e08a83 8014871: Move @Contended regression tests to the same place Summary: Move the missing test to appropriate location. Reviewed-by: dholmes, sla - test/runtime/8003985/Test8003985.java + test/runtime/contended/Basic.java Changeset: bbddfb08190f Author: shade Date: 2013-05-20 23:41 +0400 URL: http://hg.openjdk.java.net/graal/graal/rev/bbddfb08190f 8014878: Clean up class field layout code Summary: rename/remove local variables, re-arrange instance_size calculation, more comments. Reviewed-by: kvn, coleenp ! src/share/vm/classfile/classFileParser.cpp Changeset: 293b99787401 Author: dholmes Date: 2013-05-14 07:24 -0400 URL: http://hg.openjdk.java.net/graal/graal/rev/293b99787401 8014460: Need to check for non-empty EXT_LIBS_PATH before using it Reviewed-by: tbell, collins, sla, coleenp ! make/bsd/makefiles/arm.make ! make/linux/makefiles/arm.make Changeset: 26579ac80ce9 Author: bpittore Date: 2013-05-15 23:06 -0400 URL: http://hg.openjdk.java.net/graal/graal/rev/26579ac80ce9 8014669: arch specific flags not passed to some link commands Summary: EXTRA_CFLAGS does not propagate to saproc and jsig makefiles Reviewed-by: dholmes, tbell, collins ! make/linux/makefiles/jsig.make ! make/linux/makefiles/saproc.make Changeset: f8c833eb2a5f Author: jiangli Date: 2013-05-20 13:13 -0400 URL: http://hg.openjdk.java.net/graal/graal/rev/f8c833eb2a5f Merge Changeset: c838b672691c Author: jiangli Date: 2013-05-23 13:40 -0400 URL: http://hg.openjdk.java.net/graal/graal/rev/c838b672691c Merge Changeset: 91eba9f82325 Author: anoll Date: 2013-05-16 15:46 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/91eba9f82325 8012371: Adjust Tiered compile threshold according to available space in code cache Summary: Added command line parameter to define a threshold at which C1 compilation threshold for is increased. Reviewed-by: kvn, iveresov ! src/share/vm/code/codeCache.cpp ! src/share/vm/code/codeCache.hpp ! src/share/vm/runtime/advancedThresholdPolicy.cpp ! src/share/vm/runtime/advancedThresholdPolicy.hpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/globals.hpp Changeset: ec922e5c545a Author: anoll Date: 2013-05-22 10:28 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/ec922e5c545a 8012312: hsdis fails to compile with binutils-2.23.2 Summary: added to header file to make hsdis compile with binutils 2.23.* Reviewed-by: kvn, twisti ! src/share/tools/hsdis/hsdis.c Changeset: b4907b24ed48 Author: twisti Date: 2013-05-22 11:44 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/b4907b24ed48 Merge Changeset: 1682bec79205 Author: kvn Date: 2013-05-22 09:02 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/1682bec79205 8014811: loopTransform.cpp assert(cmp_end->in(2) == limit) failed Summary: Stop current iteration of loop opts if partial_peel() failed and it created node clones outside processed loop. Reviewed-by: roland ! src/share/vm/opto/loopnode.hpp ! src/share/vm/opto/loopopts.cpp Changeset: 71a2d06b9c2b Author: kvn Date: 2013-05-22 17:39 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/71a2d06b9c2b Merge Changeset: 3f281b313240 Author: kvn Date: 2013-05-22 18:25 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/3f281b313240 8010927: Kitchensink crashed with SIGSEGV, Problematic frame: v ~StubRoutines::checkcast_arraycopy Summary: Changed gen_write_ref_array_post_barrier() code on x64 to pass start address and number of copied oop elements. In generate_checkcast_copy() skip post barrier code if no elements are copied. Reviewed-by: roland ! src/cpu/x86/vm/stubGenerator_x86_32.cpp ! src/cpu/x86/vm/stubGenerator_x86_64.cpp + test/compiler/8010927/Test8010927.java Changeset: 01e51113b4f5 Author: anoll Date: 2013-05-23 14:11 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/01e51113b4f5 8014430: JRE crashes instead of stop compilation on full Code Cache. Internal Error (c1_Compiler.cpp:87) Summary: Disable client compiler and switch to interpreter if there is not enough free space in the code cache. Reviewed-by: kvn, twisti ! src/share/vm/c1/c1_Compiler.cpp ! src/share/vm/c1/c1_Compiler.hpp Changeset: 59e18b573605 Author: twisti Date: 2013-05-23 15:30 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/59e18b573605 Merge Changeset: 001ec9515f84 Author: ehelin Date: 2013-05-17 11:57 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/001ec9515f84 8014277: Remove ObjectClosure as base class for BoolObjectClosure Reviewed-by: brutisso, tschatzl ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.hpp ! src/share/vm/gc_implementation/g1/concurrentMark.hpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp ! src/share/vm/gc_implementation/parallelScavenge/psMarkSweep.cpp ! src/share/vm/gc_implementation/parallelScavenge/psParallelCompact.cpp ! src/share/vm/gc_implementation/parallelScavenge/psParallelCompact.hpp ! src/share/vm/gc_implementation/parallelScavenge/psScavenge.cpp ! src/share/vm/gc_implementation/shared/markSweep.cpp ! src/share/vm/gc_implementation/shared/markSweep.hpp ! src/share/vm/memory/defNewGeneration.cpp ! src/share/vm/memory/defNewGeneration.hpp ! src/share/vm/memory/iterator.hpp ! src/share/vm/memory/referenceProcessor.cpp ! src/share/vm/memory/sharedHeap.cpp ! src/share/vm/runtime/jniHandles.cpp Changeset: 2138a2c14831 Author: jwilhelm Date: 2013-05-19 20:31 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/2138a2c14831 Merge ! src/share/vm/gc_implementation/shared/markSweep.cpp Changeset: 10f759898d40 Author: tamao Date: 2013-05-20 10:44 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/10f759898d40 7186737: Unable to allocate bit maps or card tables for parallel gc for the requested heap Summary: Print helpful error message when VM aborts due to inability of allocating bit maps or card tables Reviewed-by: jmasa, stefank Contributed-by: tamao ! src/share/vm/gc_implementation/parallelScavenge/parMarkBitMap.cpp ! src/share/vm/gc_implementation/parallelScavenge/parMarkBitMap.hpp ! src/share/vm/gc_implementation/parallelScavenge/psParallelCompact.cpp ! src/share/vm/gc_implementation/parallelScavenge/psParallelCompact.hpp Changeset: 2b1a9d972fc2 Author: jmasa Date: 2013-05-20 22:34 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/2b1a9d972fc2 8014862: Add fast Metasapce capacity and used per MetadataType Reviewed-by: ehelin, stefank ! src/share/vm/memory/metaspace.cpp ! src/share/vm/memory/metaspace.hpp Changeset: 28e53b8db94f Author: brutisso Date: 2013-05-21 08:50 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/28e53b8db94f 7066063: CMS: "Conservation Principle" assert failed Summary: Add call to coalBirth() in CompactibleFreeListSpace::reset() Reviewed-by: ysr, jmasa ! src/share/vm/gc_implementation/concurrentMarkSweep/compactibleFreeListSpace.cpp Changeset: 5ed122fbd0ef Author: brutisso Date: 2013-05-21 10:39 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/5ed122fbd0ef Merge Changeset: 6702da6b6082 Author: tschatzl Date: 2013-05-21 11:30 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/6702da6b6082 8014405: G1: PerRegionTable::fl_mem_size() calculates size of the free list using wrong element sizes Summary: Instead of using a simple sizeof(), ask the PerRegionTable class about its size when iterating over the free list. Reviewed-by: jwilhelm, brutisso ! src/share/vm/gc_implementation/g1/heapRegionRemSet.cpp ! src/share/vm/gc_implementation/g1/heapRegionRemSet.hpp ! src/share/vm/prims/jni.cpp Changeset: 7c5a1b62f53d Author: brutisso Date: 2013-05-22 08:04 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/7c5a1b62f53d 8014971: Minor code cleanup of the freelist management Reviewed-by: jwilhelm, jmasa, tschatzl ! src/share/vm/gc_implementation/concurrentMarkSweep/adaptiveFreeList.cpp ! src/share/vm/gc_implementation/concurrentMarkSweep/adaptiveFreeList.hpp ! src/share/vm/gc_implementation/concurrentMarkSweep/compactibleFreeListSpace.cpp ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp ! src/share/vm/memory/freeList.cpp ! src/share/vm/memory/freeList.hpp Changeset: 62890ed7e2a8 Author: jwilhelm Date: 2013-05-24 09:29 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/62890ed7e2a8 Merge - agent/src/share/classes/sun/jvm/hotspot/debugger/cdbg/basic/amd64/AMD64CFrame.java - agent/src/share/classes/sun/jvm/hotspot/debugger/cdbg/basic/x86/X86CFrame.java - test/runtime/7158804/Test7158804.sh - test/runtime/8003985/Test8003985.java Changeset: 38da9f4f6709 Author: amurillo Date: 2013-05-24 09:25 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/38da9f4f6709 Merge - agent/src/share/classes/sun/jvm/hotspot/debugger/cdbg/basic/amd64/AMD64CFrame.java - agent/src/share/classes/sun/jvm/hotspot/debugger/cdbg/basic/x86/X86CFrame.java - test/runtime/7158804/Test7158804.sh - test/runtime/8003985/Test8003985.java Changeset: 092018493d3b Author: amurillo Date: 2013-05-24 09:25 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/092018493d3b Added tag hs25-b34 for changeset 38da9f4f6709 ! .hgtags Changeset: 573d86d412cd Author: katleman Date: 2013-05-30 10:57 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/573d86d412cd Added tag jdk8-b92 for changeset 092018493d3b ! .hgtags Changeset: 194b27b865bc Author: amurillo Date: 2013-05-24 09:35 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/194b27b865bc 8015305: new hotspot build - hs25-b35 Reviewed-by: jcoomes ! make/hotspot_version Changeset: ccdecfece956 Author: bharadwaj Date: 2013-05-21 16:17 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/ccdecfece956 8014059: JSR292: Failed to reject invalid class cplmhl00201m28n Summary: Restrict reference of interface methods by invokestatic and invokespecial to classfile version 52 or later. Reviewed-by: kvn, hseigel ! src/share/vm/classfile/classFileParser.cpp Changeset: f54c85acc043 Author: mikael Date: 2013-05-21 09:43 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/f54c85acc043 8013726: runtime/memory/ReserveMemory.java fails due to 'assert(bytes % os::vm_allocation_granularity() == 0) failed: reserve block size' Summary: Fix regression test to work on all platforms Reviewed-by: ctornqvi, dholmes ! src/share/vm/prims/whitebox.cpp ! test/runtime/memory/ReserveMemory.java ! test/testlibrary/whitebox/sun/hotspot/WhiteBox.java Changeset: 1a07e086ff28 Author: dholmes Date: 2013-05-21 19:52 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/1a07e086ff28 Merge Changeset: 6bd680e9ea35 Author: coleenp Date: 2013-05-22 14:37 -0400 URL: http://hg.openjdk.java.net/graal/graal/rev/6bd680e9ea35 8003421: NPG: Move oops out of InstanceKlass into mirror Summary: Inject protection_domain, signers, init_lock into java_lang_Class Reviewed-by: stefank, dholmes, sla ! agent/src/share/classes/sun/jvm/hotspot/memory/DictionaryEntry.java ! agent/src/share/classes/sun/jvm/hotspot/oops/InstanceKlass.java ! agent/src/share/classes/sun/jvm/hotspot/utilities/HeapGXLWriter.java ! agent/src/share/classes/sun/jvm/hotspot/utilities/HeapHprofBinWriter.java ! agent/src/share/classes/sun/jvm/hotspot/utilities/soql/JSJavaInstanceKlass.java ! src/share/vm/classfile/classFileParser.cpp ! src/share/vm/classfile/javaClasses.cpp ! src/share/vm/classfile/javaClasses.hpp ! src/share/vm/classfile/vmSymbols.hpp ! src/share/vm/oops/arrayKlass.cpp ! src/share/vm/oops/instanceKlass.cpp ! src/share/vm/oops/instanceKlass.hpp ! src/share/vm/oops/klass.cpp ! src/share/vm/oops/klass.hpp ! src/share/vm/oops/objArrayKlass.hpp ! src/share/vm/oops/typeArrayKlass.hpp ! src/share/vm/prims/jvm.cpp ! src/share/vm/runtime/vmStructs.cpp Changeset: 699d9df07e59 Author: ctornqvi Date: 2013-05-23 17:39 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/699d9df07e59 8009576: Test returns ClassNotFoundException Summary: Small classpath fix and move tests into open Reviewed-by: mgerdin, zgu + test/runtime/Metaspace/FragmentMetaspace.java + test/runtime/Metaspace/FragmentMetaspaceSimple.java + test/runtime/Metaspace/classes/test/Empty.java + test/runtime/testlibrary/GeneratedClassLoader.java Changeset: b7fa10a3a69a Author: sspitsyn Date: 2013-05-23 23:04 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/b7fa10a3a69a 8014288: perf regression in nashorn JDK-8008448.js test after 8008511 changes Summary: The fix of perf regression is to use method_idnum() for direct indexing into NMT Reviewed-by: twisti, kvn, coleenp, dholmes Contributed-by: serguei.spitsyn at oracle.com ! src/share/vm/oops/instanceKlass.cpp ! src/share/vm/oops/instanceKlass.hpp ! src/share/vm/prims/methodHandles.cpp ! src/share/vm/prims/methodHandles.hpp Changeset: cd83e1d98347 Author: dcubed Date: 2013-05-24 10:21 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/cd83e1d98347 Merge Changeset: 6c138b9851fb Author: sspitsyn Date: 2013-05-24 17:36 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/6c138b9851fb 8013945: CMS fatal error: must own lock MemberNameTable_lock Summary: The "delete mnt" needs to grab MemberNameTable_lock if !SafepointSynchronize::is_at_safepoint() Reviewed-by: sla, mgerdin, dholmes, jmasa Contributed-by: serguei.spitsyn at oracle.com ! src/share/vm/oops/instanceKlass.cpp Changeset: 3970971c91e0 Author: shade Date: 2013-05-27 12:49 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/3970971c91e0 8015270: @Contended: fix multiple issues in the layout code Summary: field count handling fixed, has_nonstatic_fields invariant fixed, oop map overrun fixed; new asserts Reviewed-by: kvn, dcubed, coleenp ! src/share/vm/classfile/classFileParser.cpp + test/runtime/contended/HasNonStatic.java + test/runtime/contended/OopMaps.java Changeset: a213d425d87a Author: ctornqvi Date: 2013-05-28 15:08 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/a213d425d87a 8015329: Print reason for failed MiniDumpWriteDump() call Summary: Printing both result from GetLastError and text representation of error. Also changed so that we produce dumps by default on client versions of Windows when running with a debug build. Also reviewed by peter.allwin at oracle.com Reviewed-by: sla, dholmes ! src/os/windows/vm/os_windows.cpp Changeset: 51af5fae397d Author: ccheung Date: 2013-05-24 17:19 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/51af5fae397d 8015265: revise the fix for 8007037 Reviewed-by: sspitsyn, dholmes, dcubed ! src/share/vm/oops/constantPool.cpp Changeset: 4cc7d4d5dc92 Author: zgu Date: 2013-05-28 08:54 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/4cc7d4d5dc92 Merge Changeset: 01c2bdd24bb5 Author: shade Date: 2013-05-28 19:54 +0400 URL: http://hg.openjdk.java.net/graal/graal/rev/01c2bdd24bb5 8015493: runtime/contended/OopMaps.java fails with OutOfMemory Summary: limit the memory footprint to dodge OutOfMemory errors. Reviewed-by: dcubed, ctornqvi, iignatyev ! test/runtime/contended/OopMaps.java Changeset: 9ea643afcaaf Author: dcubed Date: 2013-05-28 11:35 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/9ea643afcaaf Merge Changeset: dcb062bea05b Author: jprovino Date: 2013-05-28 11:17 -0400 URL: http://hg.openjdk.java.net/graal/graal/rev/dcb062bea05b 8013461: There is a symbol AsyncGetCallTrace in libjvm.symbols that does not exist in minimal/libjvm.a when DEBUG_LEVEL == release Summary: AsyncGetCallTrace is needed in libjvm.symbols so that programs which reference it can build correctly. Reviewed-by: dholmes, bobv ! make/excludeSrc.make ! src/share/vm/prims/forte.cpp Changeset: fb14e9ed1594 Author: jprovino Date: 2013-05-28 11:32 -0400 URL: http://hg.openjdk.java.net/graal/graal/rev/fb14e9ed1594 8011064: Some tests have failed with SIGSEGV on arm-hflt on build b82 Summary: NMT_detail is only supported when frame pointers are not omitted (-fno-omit-frame-pointer). Reviewed-by: dholmes, cjplummer ! src/share/vm/services/memTracker.cpp ! src/share/vm/utilities/globalDefinitions.hpp Changeset: 9e954e8d9139 Author: jprovino Date: 2013-05-28 15:24 -0400 URL: http://hg.openjdk.java.net/graal/graal/rev/9e954e8d9139 Merge Changeset: 9e86c5544295 Author: jiangli Date: 2013-05-30 13:19 -0400 URL: http://hg.openjdk.java.net/graal/graal/rev/9e86c5544295 Merge Changeset: 0def34ab1c98 Author: tamao Date: 2013-05-21 16:43 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/0def34ab1c98 8015007: Incorrect print format in error message for VM cannot allocate the requested heap Summary: Correct the wrong print format in error message for VM cannot allocate the requested heap; and clean up the error message call in check_alignment() Reviewed-by: brutisso, tschatzl Contributed-by: tamao ! src/share/vm/memory/universe.cpp Changeset: 14d3f71f831d Author: tamao Date: 2013-05-22 11:11 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/14d3f71f831d 8007762: Rename a bunch of methods in size policy across collectors Summary: Rename: compute_generations_free_space() = compute_eden_space_size() + compute_old_gen_free_space(); update related logging messages Reviewed-by: jmasa, johnc, tschatzl, brutisso Contributed-by: tamao ! src/share/vm/gc_implementation/concurrentMarkSweep/cmsAdaptiveSizePolicy.cpp ! src/share/vm/gc_implementation/concurrentMarkSweep/cmsAdaptiveSizePolicy.hpp ! src/share/vm/gc_implementation/parNew/asParNewGeneration.cpp ! src/share/vm/gc_implementation/parallelScavenge/psAdaptiveSizePolicy.cpp ! src/share/vm/gc_implementation/parallelScavenge/psAdaptiveSizePolicy.hpp ! src/share/vm/gc_implementation/parallelScavenge/psGCAdaptivePolicyCounters.hpp ! src/share/vm/gc_implementation/parallelScavenge/psMarkSweep.cpp ! src/share/vm/gc_implementation/parallelScavenge/psParallelCompact.cpp ! src/share/vm/gc_implementation/shared/adaptiveSizePolicy.cpp Changeset: 0886b99a4d1b Author: jwilhelm Date: 2013-05-24 14:16 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/0886b99a4d1b Merge Changeset: eda078b01c65 Author: stefank Date: 2013-05-27 15:22 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/eda078b01c65 8015268: NPG: 2.5% regression in young GC times on CRM Sales Opty Summary: Split SystemDictionary and ClassLoaderDataGraph root processing to help load balancing. Reviewed-by: tschatzl, johnc ! src/share/vm/gc_implementation/parallelScavenge/pcTasks.cpp ! src/share/vm/gc_implementation/parallelScavenge/pcTasks.hpp ! src/share/vm/gc_implementation/parallelScavenge/psParallelCompact.cpp ! src/share/vm/gc_implementation/parallelScavenge/psScavenge.cpp ! src/share/vm/gc_implementation/parallelScavenge/psTasks.cpp ! src/share/vm/gc_implementation/parallelScavenge/psTasks.hpp ! src/share/vm/memory/sharedHeap.cpp Changeset: 95c00927be11 Author: stefank Date: 2013-05-27 12:56 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/95c00927be11 8015428: Remove unused CDS support from StringTable Summary: The string in StringTable is not used by CDS anymore. Remove the unnecessary code in preparation for 8015422: Large performance hit when the StringTable is walked twice in Parallel Scavenge Reviewed-by: pliden, tschatzl, coleenp ! src/share/vm/classfile/symbolTable.cpp Changeset: 8dbc025ff709 Author: stefank Date: 2013-05-27 12:58 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/8dbc025ff709 8015422: Large performance hit when the StringTable is walked twice in Parallel Scavenge Summary: Combine the calls to StringTable::unlink and StringTable::oops_do in Parallel Scavenge. Reviewed-by: pliden, coleenp ! src/share/vm/classfile/symbolTable.cpp ! src/share/vm/classfile/symbolTable.hpp ! src/share/vm/gc_implementation/parallelScavenge/psScavenge.cpp Changeset: f41a577cffb0 Author: jwilhelm Date: 2013-05-31 09:55 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/f41a577cffb0 Merge Changeset: b786c04b7be1 Author: amurillo Date: 2013-05-31 09:37 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/b786c04b7be1 Merge Changeset: 5a028ee56116 Author: amurillo Date: 2013-05-31 09:37 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/5a028ee56116 Added tag hs25-b35 for changeset b786c04b7be1 ! .hgtags Changeset: 61dcf187a198 Author: katleman Date: 2013-06-06 09:54 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/61dcf187a198 Added tag jdk8-b93 for changeset 573d86d412cd ! .hgtags Changeset: b7569f617285 Author: amurillo Date: 2013-05-31 10:04 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/b7569f617285 8015690: new hotspot build - hs25-b36 Reviewed-by: jcoomes ! make/hotspot_version Changeset: 5534bd30c151 Author: jcoomes Date: 2013-05-30 13:04 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/5534bd30c151 6725714: par compact - add a table to speed up bitmap searches Reviewed-by: jmasa, tschatzl ! src/share/vm/gc_implementation/parallelScavenge/parallelScavengeHeap.hpp ! src/share/vm/gc_implementation/parallelScavenge/psParallelCompact.cpp ! src/share/vm/gc_implementation/parallelScavenge/psParallelCompact.hpp Changeset: 47bdfb3d010f Author: stefank Date: 2013-05-30 10:58 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/47bdfb3d010f 8015486: PSScavenge::is_obj_in_young is unnecessarily slow with UseCompressedOops Summary: Compare compressed oops to a compressed young gen boundary instead of uncompressing the oops before doing the young gen boundary check. Reviewed-by: brutisso, jmasa ! src/share/vm/gc_implementation/parallelScavenge/psPromotionManager.inline.hpp ! src/share/vm/gc_implementation/parallelScavenge/psScavenge.cpp ! src/share/vm/gc_implementation/parallelScavenge/psScavenge.hpp ! src/share/vm/gc_implementation/parallelScavenge/psScavenge.inline.hpp Changeset: c20186fa611b Author: jwilhelm Date: 2013-06-01 10:00 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/c20186fa611b Merge Changeset: e72f7eecc96d Author: tschatzl Date: 2013-05-28 09:32 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/e72f7eecc96d 8013895: G1: G1SummarizeRSetStats output on Linux needs improvemen Summary: Fixed the output of G1SummarizeRSetStats: too small datatype for the number of concurrently processed cards, added concurrent remembered set thread time retrieval for Linux and Windows (BSD uses os::elapsedTime() now), and other cleanup. The information presented during VM operation is now relative to the previous output, not always cumulative if G1SummarizeRSetStatsPeriod > 0. At VM exit, the code prints a cumulative summary. Reviewed-by: johnc, jwilhelm ! make/excludeSrc.make ! src/os/bsd/vm/os_bsd.cpp ! src/os/linux/vm/os_linux.cpp ! src/os/windows/vm/os_windows.cpp ! src/share/vm/gc_implementation/g1/concurrentG1Refine.cpp ! src/share/vm/gc_implementation/g1/concurrentG1Refine.hpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1RemSet.cpp ! src/share/vm/gc_implementation/g1/g1RemSet.hpp + src/share/vm/gc_implementation/g1/g1RemSetSummary.cpp + src/share/vm/gc_implementation/g1/g1RemSetSummary.hpp + test/gc/g1/TestSummarizeRSetStats.java Changeset: 3a4805ad0005 Author: johnc Date: 2013-06-04 10:04 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/3a4805ad0005 8015244: G1: Verification after a full GC is incorrectly placed. Summary: In a full GC, move the verification after the GC to after RSet rebuilding. Verify RSet entries during a full GC under control of a flag. Reviewed-by: tschatzl, brutisso ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1RemSet.cpp ! src/share/vm/gc_implementation/g1/g1_globals.hpp ! src/share/vm/gc_implementation/g1/heapRegion.cpp Changeset: 87c64c0438fb Author: tamao Date: 2013-06-03 14:37 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/87c64c0438fb 6976350: G1: deal with fragmentation while copying objects during GC Summary: Create G1ParGCAllocBufferContainer to contain two buffers instead of previously using one buffer, in order to hold the first priority buffer longer. Thus, when some large objects hits the value of free space left in the first priority buffer it has an alternative to fit in the second priority buffer while the first priority buffer is given more chances to try allocating smaller objects. Overall, it will improve heap space efficiency. Reviewed-by: johnc, jmasa, brutisso Contributed-by: tamao ! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp ! src/share/vm/gc_implementation/shared/parGCAllocBuffer.hpp Changeset: 2f7a31318b84 Author: johnc Date: 2013-06-04 14:00 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/2f7a31318b84 Merge Changeset: a1ebd310d5c1 Author: iklam Date: 2013-05-28 16:36 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/a1ebd310d5c1 8014912: Restore PrintSharedSpaces functionality after NPG Summary: Added dumping of object sizes in CDS archive, sorted by MetaspaceObj::Type Reviewed-by: coleenp, acorn ! src/share/vm/memory/allocation.cpp ! src/share/vm/memory/allocation.hpp ! src/share/vm/memory/metaspace.cpp ! src/share/vm/memory/metaspace.hpp ! src/share/vm/memory/metaspaceShared.cpp ! src/share/vm/oops/annotations.cpp ! src/share/vm/oops/constMethod.cpp ! src/share/vm/oops/constantPool.cpp ! src/share/vm/oops/cpCache.cpp ! src/share/vm/oops/klass.cpp ! src/share/vm/oops/method.cpp ! src/share/vm/oops/methodCounters.cpp ! src/share/vm/oops/methodData.cpp ! src/share/vm/oops/symbol.cpp ! src/share/vm/utilities/array.hpp Changeset: fe00365c8f31 Author: sspitsyn Date: 2013-05-30 11:46 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/fe00365c8f31 8015436: compiler/ciReplay/TestSA.sh fails with assert() index is out of bounds Summary: The InstanceKlass _initial_method_idnum value must be adjusted if overpass methods are added. Reviewed-by: twisti, kvn Contributed-by: serguei.spitsyn at oracle.com ! src/share/vm/classfile/defaultMethods.cpp + test/compiler/8015436/Test8015436.java Changeset: a589c78a8811 Author: rbackman Date: 2013-05-31 13:02 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/a589c78a8811 8014709: Constructor.getAnnotatedReturnType() returns empty AnnotatedType Reviewed-by: stefank, rbackman Contributed-by: Joel Borggren-Franck ! src/share/vm/runtime/reflection.cpp ! test/runtime/8007320/ConstMethodTest.java Changeset: efe8b7d64424 Author: ctornqvi Date: 2013-05-31 20:24 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/efe8b7d64424 6726963: multi_allocate() call does not CHECK_NULL and causes crash in fastdebug bits Summary: Using CHECK_NULL when calling multi_allocate() from the corresponding reflection code; added test for this condition Reviewed-by: dholmes, minqi Contributed-by: Mikhailo Seledtsov ! src/share/vm/runtime/reflection.cpp + test/runtime/memory/MultiAllocateNullCheck.java Changeset: 532c55335fb6 Author: dcubed Date: 2013-06-01 09:28 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/532c55335fb6 Merge Changeset: 4552a7633a07 Author: hseigel Date: 2013-06-03 10:00 -0400 URL: http://hg.openjdk.java.net/graal/graal/rev/4552a7633a07 8015385: Remove RelaxAccessControlCheck for JDK 8 bytecodes Summary: Check bytecode versions along with RelaxAccessControlCheck version Reviewed-by: dholmes, acorn ! src/share/vm/classfile/verifier.hpp ! src/share/vm/runtime/reflection.cpp Changeset: e7d29a019a3c Author: sspitsyn Date: 2013-06-03 14:28 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/e7d29a019a3c 8014052: JSR292: assert(end_offset == next_offset) failed: matched ending Summary: A call to the finalize_operands_merge() must be unconditional Reviewed-by: kvn, twisti Contributed-by: serguei.spitsyn at oracle.com ! src/share/vm/prims/jvmtiRedefineClasses.cpp Changeset: 2f004f9dc9e1 Author: sspitsyn Date: 2013-06-04 01:06 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/2f004f9dc9e1 8015803: Test8015436.java fails 'can not access a member of class Test8015436 with modifiers "public static"' Summary: Newly added test has an issue: the main class must be public Reviewed-by: kvn, jbachorik, coleenp Contributed-by: serguei.spitsyn at oracle.com ! test/compiler/8015436/Test8015436.java Changeset: 04551f4dbdb9 Author: nloodin Date: 2013-06-05 09:47 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/04551f4dbdb9 Merge Changeset: 62e7bac9524f Author: dcubed Date: 2013-06-04 19:39 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/62e7bac9524f 8010257: remove unused thread-local variables _ScratchA and _ScratchB Summary: Remove dead code. Reviewed-by: twisti, coleenp ! src/share/vm/runtime/thread.hpp Changeset: 6bf8b8bb7c19 Author: hseigel Date: 2013-06-05 14:12 -0400 URL: http://hg.openjdk.java.net/graal/graal/rev/6bf8b8bb7c19 8009302: Mac OS X: JVM crash on infinite recursion on Appkit Thread Summary: Use SA_ONSTACK flag to ensure signal gets delivered properly. Reviewed-by: dholmes, coleenp Contributed-by: gerard.ziemski at oracle.com ! src/os/bsd/vm/os_bsd.cpp Changeset: f8c8cace25ad Author: dcubed Date: 2013-06-06 05:56 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/f8c8cace25ad Merge ! src/os/bsd/vm/os_bsd.cpp Changeset: 320b4e0f0892 Author: roland Date: 2013-05-30 11:21 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/320b4e0f0892 8015585: Missing regression test for 8011771 Summary: missing regression test Reviewed-by: kvn + test/compiler/8011771/Test8011771.java Changeset: f15fe46d8c00 Author: twisti Date: 2013-05-30 08:37 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/f15fe46d8c00 8015266: fix some -Wsign-compare warnings in adlc Reviewed-by: kvn ! src/share/vm/adlc/archDesc.cpp ! src/share/vm/adlc/dict2.cpp ! src/share/vm/adlc/formssel.cpp ! src/share/vm/adlc/formssel.hpp ! src/share/vm/adlc/output_c.cpp Changeset: 28e5aed7f3a6 Author: roland Date: 2013-05-31 14:40 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/28e5aed7f3a6 8009981: nashorn tests fail with -XX:+VerifyStack Summary: nmethod::preserve_callee_argument_oops() must take appendix into account. Reviewed-by: kvn, twisti ! src/share/vm/code/nmethod.cpp ! src/share/vm/runtime/deoptimization.cpp ! src/share/vm/runtime/frame.cpp ! src/share/vm/runtime/frame.hpp ! src/share/vm/runtime/sharedRuntime.cpp ! src/share/vm/runtime/sharedRuntime.hpp Changeset: 83dcb116fdb1 Author: kvn Date: 2013-05-31 13:54 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/83dcb116fdb1 8015441: runThese crashed with assert(opcode == Op_ConP || opcode == Op_ThreadLocal || opcode == Op_CastX2P ..) failed: sanity Summary: Relax the assert to accept any raw ptr types. Reviewed-by: roland ! src/share/vm/opto/escape.cpp Changeset: c07dd9be16e8 Author: anoll Date: 2013-05-31 06:41 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/c07dd9be16e8 8013496: Code cache management command line options work only in special order. Another order of arguments does not deliver the second parameter to the jvm. Summary: Moved check that ReservedCodeCacheSize >= InitialCodeCacheSize to Arguments::check_vm_args_consistency(). As a result, the ordering in which the two parameters are given to the VM is not relevant. Added a regression test. Reviewed-by: kvn, twisti ! src/share/vm/runtime/arguments.cpp + test/compiler/8013496/Test8013496.sh Changeset: 603ca7e51354 Author: roland Date: 2013-04-24 11:49 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/603ca7e51354 8010460: Interpreter on some platforms loads ConstMethod::_max_stack and misses extra stack slots for JSR 292 Summary: ConstMethod::max_stack() doesn't account for JSR 292 appendix. Reviewed-by: kvn ! src/cpu/sparc/vm/cppInterpreter_sparc.cpp ! src/cpu/sparc/vm/interp_masm_sparc.cpp ! src/cpu/sparc/vm/templateInterpreter_sparc.cpp ! src/cpu/x86/vm/cppInterpreter_x86.cpp ! src/cpu/x86/vm/templateInterpreter_x86_32.cpp ! src/cpu/x86/vm/templateInterpreter_x86_64.cpp ! src/share/vm/interpreter/bytecodeInterpreter.cpp ! src/share/vm/oops/method.hpp ! src/share/vm/opto/matcher.cpp Changeset: 813f26e34135 Author: anoll Date: 2013-06-03 08:52 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/813f26e34135 8013329: File leak in hotspot/src/share/vm/compiler/compileBroker.cpp Summary: Added calling of the destructor of CompileLog so that files are closed. Added/moved memory allocation/deallocation of the string that contains the name of the log file to class CompileLog. Reviewed-by: kvn, roland ! src/share/vm/compiler/compileBroker.cpp ! src/share/vm/compiler/compileLog.cpp ! src/share/vm/compiler/compileLog.hpp Changeset: b274ac1dbe11 Author: adlertz Date: 2013-06-03 12:39 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/b274ac1dbe11 8005956: C2: assert(!def_outside->member(r)) failed: Use of external LRG overlaps the same LRG defined in this block Summary: Disable re-materialization of reaching definitions (which have live inputs) for phi nodes when spilling. Reviewed-by: twisti, kvn ! src/share/vm/opto/reg_split.cpp Changeset: 770e91e578a6 Author: kvn Date: 2013-06-03 14:02 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/770e91e578a6 Merge Changeset: 075ea888b039 Author: morris Date: 2013-06-04 12:06 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/075ea888b039 8010724: [parfait] Null pointer dereference in hotspot/src/share/vm/c1/c1_LIRGenerator.cpp Summary: added guarantee() Reviewed-by: kvn ! src/share/vm/c1/c1_LIRGenerator.cpp Changeset: 2cb5d5f6d5e5 Author: simonis Date: 2013-06-04 22:16 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/2cb5d5f6d5e5 8015252: Enable HotSpot build with Clang Reviewed-by: twisti, dholmes, kvn ! make/bsd/makefiles/adlc.make ! make/bsd/makefiles/gcc.make ! make/bsd/makefiles/vm.make ! make/linux/makefiles/adlc.make ! make/linux/makefiles/gcc.make ! src/os/bsd/vm/os_bsd.cpp ! src/os_cpu/linux_x86/vm/linux_x86_32.s ! src/os_cpu/linux_x86/vm/os_linux_x86.cpp Changeset: 609aad72004a Author: anoll Date: 2013-06-06 09:29 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/609aad72004a 8014246: remove assert to catch access to object headers in index_oop_from_field_offset_long Reviewed-by: twisti, jrose ! src/share/vm/prims/unsafe.cpp Changeset: ef1818846c22 Author: kvn Date: 2013-06-06 11:02 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/ef1818846c22 Merge ! src/os/bsd/vm/os_bsd.cpp Changeset: 3c78a14da19d Author: amurillo Date: 2013-06-07 09:25 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/3c78a14da19d Merge ! .hgtags Changeset: 1beed1f6f9ed Author: amurillo Date: 2013-06-07 09:25 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/1beed1f6f9ed Added tag hs25-b36 for changeset 3c78a14da19d ! .hgtags Changeset: 3a353050e85a Author: katleman Date: 2013-06-13 09:48 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/3a353050e85a Added tag jdk8-b94 for changeset 1beed1f6f9ed ! .hgtags Changeset: d0add7016434 Author: amurillo Date: 2013-06-07 09:33 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/d0add7016434 8016078: new hotspot build - hs25-b37 Reviewed-by: jcoomes ! make/hotspot_version Changeset: f2110083203d Author: sla Date: 2013-06-10 11:30 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/f2110083203d 8005849: JEP 167: Event-Based JVM Tracing Reviewed-by: acorn, coleenp, sla Contributed-by: Karen Kinnear , Bengt Rutisson , Calvin Cheung , Erik Gahlin , Erik Helin , Jesper Wilhelmsson , Keith McGuigan , Mattias Tobiasson , Markus Gronlund , Mikael Auno , Nils Eliasson , Nils Loodin , Rickard Backman , Staffan Larsen , Stefan Karlsson , Yekaterina Kantserova ! make/Makefile ! make/bsd/makefiles/buildtree.make ! make/bsd/makefiles/minimal1.make ! make/bsd/makefiles/top.make + make/bsd/makefiles/trace.make ! make/bsd/makefiles/vm.make ! make/defs.make ! make/excludeSrc.make ! make/linux/makefiles/buildtree.make ! make/linux/makefiles/minimal1.make ! make/linux/makefiles/top.make + make/linux/makefiles/trace.make ! make/linux/makefiles/vm.make ! make/solaris/makefiles/buildtree.make ! make/solaris/makefiles/top.make + make/solaris/makefiles/trace.make ! make/solaris/makefiles/vm.make ! make/windows/build.make ! make/windows/create_obj_files.sh ! make/windows/makefiles/generated.make ! make/windows/makefiles/projectcreator.make + make/windows/makefiles/trace.make ! make/windows/makefiles/vm.make ! make/windows/projectfiles/common/Makefile ! src/cpu/sparc/vm/frame_sparc.cpp ! src/cpu/x86/vm/frame_x86.cpp ! src/os/bsd/vm/osThread_bsd.hpp ! src/os/bsd/vm/os_bsd.cpp ! src/os/bsd/vm/os_bsd.hpp ! src/os/bsd/vm/os_bsd.inline.hpp ! src/os/linux/vm/osThread_linux.hpp ! src/os/linux/vm/os_linux.cpp ! src/os/linux/vm/os_linux.hpp ! src/os/linux/vm/os_linux.inline.hpp ! src/os/solaris/vm/osThread_solaris.cpp ! src/os/solaris/vm/osThread_solaris.hpp ! src/os/solaris/vm/os_share_solaris.hpp ! src/os/solaris/vm/os_solaris.cpp ! src/os/solaris/vm/os_solaris.hpp ! src/os/windows/vm/os_windows.cpp ! src/os_cpu/bsd_x86/vm/thread_bsd_x86.cpp ! src/os_cpu/bsd_x86/vm/thread_bsd_x86.hpp ! src/os_cpu/linux_x86/vm/thread_linux_x86.cpp ! src/os_cpu/linux_x86/vm/thread_linux_x86.hpp ! src/os_cpu/solaris_sparc/vm/os_solaris_sparc.cpp ! src/os_cpu/solaris_sparc/vm/thread_solaris_sparc.cpp ! src/os_cpu/solaris_sparc/vm/thread_solaris_sparc.hpp ! src/os_cpu/solaris_x86/vm/os_solaris_x86.cpp ! src/os_cpu/solaris_x86/vm/thread_solaris_x86.cpp ! src/os_cpu/solaris_x86/vm/thread_solaris_x86.hpp ! src/os_cpu/windows_x86/vm/thread_windows_x86.cpp ! src/os_cpu/windows_x86/vm/thread_windows_x86.hpp ! src/share/tools/ProjectCreator/BuildConfig.java ! src/share/vm/classfile/classFileParser.cpp ! src/share/vm/classfile/classLoaderData.cpp ! src/share/vm/classfile/classLoaderData.hpp ! src/share/vm/classfile/javaClasses.cpp ! src/share/vm/classfile/systemDictionary.cpp ! src/share/vm/classfile/systemDictionary.hpp ! src/share/vm/code/codeCache.cpp ! src/share/vm/code/codeCache.hpp ! src/share/vm/compiler/compileBroker.cpp ! src/share/vm/compiler/compileBroker.hpp ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.hpp ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepThread.cpp ! src/share/vm/gc_implementation/concurrentMarkSweep/vmCMSOperations.cpp ! src/share/vm/gc_implementation/g1/concurrentMark.cpp ! src/share/vm/gc_implementation/g1/concurrentMark.hpp ! src/share/vm/gc_implementation/g1/concurrentMarkThread.cpp + src/share/vm/gc_implementation/g1/evacuationInfo.hpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.cpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.hpp ! src/share/vm/gc_implementation/g1/g1GCPhaseTimes.hpp ! src/share/vm/gc_implementation/g1/g1MarkSweep.cpp ! src/share/vm/gc_implementation/g1/g1MarkSweep.hpp ! src/share/vm/gc_implementation/g1/g1MonitoringSupport.hpp + src/share/vm/gc_implementation/g1/g1YCTypes.hpp ! src/share/vm/gc_implementation/g1/vm_operations_g1.cpp ! src/share/vm/gc_implementation/parNew/parNewGeneration.cpp ! src/share/vm/gc_implementation/parNew/parNewGeneration.hpp ! src/share/vm/gc_implementation/parallelScavenge/parallelScavengeHeap.cpp ! src/share/vm/gc_implementation/parallelScavenge/parallelScavengeHeap.hpp ! src/share/vm/gc_implementation/parallelScavenge/pcTasks.cpp ! src/share/vm/gc_implementation/parallelScavenge/psMarkSweep.cpp ! src/share/vm/gc_implementation/parallelScavenge/psParallelCompact.cpp ! src/share/vm/gc_implementation/parallelScavenge/psParallelCompact.hpp ! src/share/vm/gc_implementation/parallelScavenge/psPromotionManager.cpp ! src/share/vm/gc_implementation/parallelScavenge/psPromotionManager.hpp ! src/share/vm/gc_implementation/parallelScavenge/psPromotionManager.inline.hpp ! src/share/vm/gc_implementation/parallelScavenge/psScavenge.cpp ! src/share/vm/gc_implementation/parallelScavenge/psScavenge.hpp + src/share/vm/gc_implementation/shared/copyFailedInfo.hpp + src/share/vm/gc_implementation/shared/gcHeapSummary.hpp + src/share/vm/gc_implementation/shared/gcTimer.cpp + src/share/vm/gc_implementation/shared/gcTimer.hpp + src/share/vm/gc_implementation/shared/gcTrace.cpp + src/share/vm/gc_implementation/shared/gcTrace.hpp + src/share/vm/gc_implementation/shared/gcTraceSend.cpp + src/share/vm/gc_implementation/shared/gcTraceTime.cpp + src/share/vm/gc_implementation/shared/gcTraceTime.hpp + src/share/vm/gc_implementation/shared/gcWhen.hpp ! src/share/vm/gc_implementation/shared/markSweep.cpp ! src/share/vm/gc_implementation/shared/markSweep.hpp ! src/share/vm/gc_implementation/shared/vmGCOperations.cpp ! src/share/vm/gc_implementation/shared/vmGCOperations.hpp + src/share/vm/gc_interface/allocTracer.cpp + src/share/vm/gc_interface/allocTracer.hpp ! src/share/vm/gc_interface/collectedHeap.cpp ! src/share/vm/gc_interface/collectedHeap.hpp ! src/share/vm/gc_interface/collectedHeap.inline.hpp ! src/share/vm/gc_interface/gcCause.cpp ! src/share/vm/gc_interface/gcCause.hpp + src/share/vm/gc_interface/gcName.hpp ! src/share/vm/memory/allocation.hpp ! src/share/vm/memory/defNewGeneration.cpp ! src/share/vm/memory/defNewGeneration.hpp ! src/share/vm/memory/genCollectedHeap.cpp ! src/share/vm/memory/genMarkSweep.cpp ! src/share/vm/memory/generation.cpp ! src/share/vm/memory/heapInspection.cpp ! src/share/vm/memory/heapInspection.hpp + src/share/vm/memory/klassInfoClosure.hpp ! src/share/vm/memory/metaspace.hpp ! src/share/vm/memory/oopFactory.hpp ! src/share/vm/memory/referenceProcessor.cpp ! src/share/vm/memory/referenceProcessor.hpp + src/share/vm/memory/referenceProcessorStats.hpp + src/share/vm/memory/referenceType.hpp ! src/share/vm/memory/universe.cpp ! src/share/vm/memory/universe.hpp ! src/share/vm/oops/instanceKlass.hpp ! src/share/vm/oops/klass.cpp ! src/share/vm/opto/compile.cpp ! src/share/vm/opto/compile.hpp ! src/share/vm/opto/escape.cpp ! src/share/vm/opto/library_call.cpp ! src/share/vm/opto/loopnode.cpp ! src/share/vm/opto/matcher.cpp + src/share/vm/opto/phasetype.hpp ! src/share/vm/precompiled/precompiled.hpp ! src/share/vm/prims/jni.cpp ! src/share/vm/prims/jvm.cpp ! src/share/vm/prims/jvmtiGen.java ! src/share/vm/prims/jvmtiImpl.cpp ! src/share/vm/prims/jvmtiImpl.hpp ! src/share/vm/prims/unsafe.cpp ! src/share/vm/runtime/frame.hpp ! src/share/vm/runtime/frame.inline.hpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/java.cpp ! src/share/vm/runtime/mutexLocker.cpp ! src/share/vm/runtime/objectMonitor.cpp ! src/share/vm/runtime/objectMonitor.hpp ! src/share/vm/runtime/os.cpp ! src/share/vm/runtime/os.hpp ! src/share/vm/runtime/perfData.cpp ! src/share/vm/runtime/perfData.hpp ! src/share/vm/runtime/stubRoutines.hpp ! src/share/vm/runtime/sweeper.cpp ! src/share/vm/runtime/sweeper.hpp ! src/share/vm/runtime/synchronizer.cpp ! src/share/vm/runtime/task.cpp ! src/share/vm/runtime/thread.cpp ! src/share/vm/runtime/thread.hpp ! src/share/vm/runtime/timer.cpp ! src/share/vm/runtime/timer.hpp ! src/share/vm/runtime/vmStructs.cpp ! src/share/vm/runtime/vmThread.cpp ! src/share/vm/runtime/vm_operations.cpp ! src/share/vm/runtime/vm_operations.hpp ! src/share/vm/services/attachListener.cpp ! src/share/vm/services/diagnosticArgument.cpp ! src/share/vm/services/diagnosticCommand.cpp ! src/share/vm/services/memBaseline.cpp + src/share/vm/trace/noTraceBackend.hpp + src/share/vm/trace/trace.dtd + src/share/vm/trace/trace.xml + src/share/vm/trace/traceBackend.hpp + src/share/vm/trace/traceDataTypes.hpp + src/share/vm/trace/traceEvent.hpp + src/share/vm/trace/traceEventClasses.xsl + src/share/vm/trace/traceEventIds.xsl - src/share/vm/trace/traceEventTypes.hpp ! src/share/vm/trace/traceMacros.hpp + src/share/vm/trace/traceStream.hpp + src/share/vm/trace/traceTime.hpp + src/share/vm/trace/traceTypes.xsl + src/share/vm/trace/tracetypes.xml ! src/share/vm/trace/tracing.hpp + src/share/vm/trace/xinclude.mod + src/share/vm/trace/xsl_util.xsl ! src/share/vm/utilities/globalDefinitions.hpp ! src/share/vm/utilities/macros.hpp Changeset: 69689078dff8 Author: amurillo Date: 2013-06-13 23:28 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/69689078dff8 Merge - src/share/vm/trace/traceEventTypes.hpp Changeset: 5d65c078cd0a Author: amurillo Date: 2013-06-13 23:28 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/5d65c078cd0a Added tag hs25-b37 for changeset 69689078dff8 ! .hgtags Changeset: 836a62f43af9 Author: Doug Simon Date: 2013-06-19 10:45 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/836a62f43af9 Merge with http://hg.openjdk.java.net/hsx/hsx25/hotspot/ ! .hgtags - agent/doc/c2replay.html - agent/src/share/classes/sun/jvm/hotspot/debugger/cdbg/basic/amd64/AMD64CFrame.java - agent/src/share/classes/sun/jvm/hotspot/debugger/cdbg/basic/x86/X86CFrame.java ! make/Makefile ! make/bsd/makefiles/buildtree.make - make/bsd/makefiles/launcher.make ! make/bsd/makefiles/vm.make ! make/defs.make ! make/hotspot_version ! make/linux/makefiles/adlc.make ! make/linux/makefiles/buildtree.make ! make/linux/makefiles/jsig.make - make/linux/makefiles/launcher.make ! make/linux/makefiles/top.make ! make/linux/makefiles/vm.make ! make/solaris/makefiles/buildtree.make - make/solaris/makefiles/launcher.make ! make/solaris/makefiles/vm.make ! make/windows/build.make - make/windows/makefiles/launcher.make ! make/windows/makefiles/projectcreator.make ! make/windows/makefiles/vm.make ! src/cpu/sparc/vm/templateInterpreter_sparc.cpp ! src/cpu/x86/vm/frame_x86.cpp ! src/cpu/x86/vm/interp_masm_x86_64.cpp ! src/cpu/x86/vm/interp_masm_x86_64.hpp ! src/cpu/x86/vm/stubGenerator_x86_32.cpp ! src/cpu/x86/vm/stubGenerator_x86_64.cpp ! src/cpu/x86/vm/templateInterpreter_x86_64.cpp ! src/cpu/x86/vm/templateTable_x86_64.cpp - src/os/bsd/vm/chaitin_bsd.cpp ! src/os/bsd/vm/os_bsd.cpp - src/os/linux/vm/chaitin_linux.cpp ! src/os/linux/vm/os_linux.cpp - src/os/posix/launcher/java_md.c - src/os/posix/launcher/java_md.h - src/os/posix/launcher/launcher.script - src/os/solaris/vm/chaitin_solaris.cpp ! src/os/solaris/vm/os_solaris.cpp - src/os/windows/launcher/java_md.c - src/os/windows/launcher/java_md.h - src/os/windows/vm/chaitin_windows.cpp ! src/os/windows/vm/os_windows.cpp ! src/os_cpu/linux_x86/vm/os_linux_x86.cpp ! src/share/tools/ProjectCreator/BuildConfig.java ! src/share/tools/ProjectCreator/WinGammaPlatformVC10.java - src/share/tools/launcher/java.c - src/share/tools/launcher/java.h - src/share/tools/launcher/jli_util.c - src/share/tools/launcher/jli_util.h - src/share/tools/launcher/wildcard.c - src/share/tools/launcher/wildcard.h ! src/share/vm/c1/c1_Compiler.cpp ! src/share/vm/c1/c1_LIRGenerator.cpp ! src/share/vm/c1/c1_Runtime1.cpp ! src/share/vm/ci/ciEnv.cpp ! src/share/vm/ci/ciEnv.hpp ! src/share/vm/ci/ciInstanceKlass.cpp ! src/share/vm/ci/ciInstanceKlass.hpp ! src/share/vm/ci/ciMethod.cpp ! src/share/vm/classfile/classFileParser.cpp ! src/share/vm/classfile/classLoader.cpp ! src/share/vm/classfile/javaClasses.cpp ! src/share/vm/classfile/javaClasses.hpp ! src/share/vm/classfile/systemDictionary.cpp ! src/share/vm/classfile/systemDictionary.hpp ! src/share/vm/classfile/vmSymbols.hpp ! src/share/vm/code/codeBlob.cpp ! src/share/vm/code/codeCache.cpp ! src/share/vm/code/codeCache.hpp ! src/share/vm/code/compiledIC.cpp ! src/share/vm/code/nmethod.cpp ! src/share/vm/code/stubs.cpp ! src/share/vm/compiler/compileBroker.cpp ! src/share/vm/compiler/compileBroker.hpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp ! src/share/vm/gc_implementation/g1/g1_globals.hpp ! src/share/vm/gc_implementation/g1/heapRegion.cpp - src/share/vm/gc_implementation/parallelScavenge/parMarkBitMap.inline.hpp ! src/share/vm/gc_interface/collectedHeap.hpp ! src/share/vm/graal/graalCompilerToVM.cpp ! src/share/vm/interpreter/interpreterRuntime.cpp ! src/share/vm/interpreter/invocationCounter.cpp ! src/share/vm/memory/allocation.hpp ! src/share/vm/memory/cardTableModRefBS.hpp ! src/share/vm/memory/heap.cpp ! src/share/vm/memory/referenceProcessor.cpp ! src/share/vm/memory/referenceProcessor.hpp ! src/share/vm/memory/universe.cpp ! src/share/vm/oops/constantPool.cpp ! src/share/vm/oops/constantPool.hpp ! src/share/vm/oops/instanceKlass.cpp ! src/share/vm/oops/instanceKlass.hpp ! src/share/vm/oops/klass.cpp ! src/share/vm/oops/klass.hpp ! src/share/vm/oops/method.cpp ! src/share/vm/oops/method.hpp + src/share/vm/oops/methodCounters.hpp ! src/share/vm/oops/methodData.cpp ! src/share/vm/oops/methodData.hpp ! src/share/vm/opto/bytecodeInfo.cpp ! src/share/vm/opto/callGenerator.hpp ! src/share/vm/opto/graphKit.cpp ! src/share/vm/opto/output.cpp ! src/share/vm/opto/runtime.cpp ! src/share/vm/precompiled/precompiled.hpp ! src/share/vm/prims/jni.cpp ! src/share/vm/prims/jvm.cpp ! src/share/vm/prims/jvmtiEnv.cpp ! src/share/vm/prims/jvmtiImpl.cpp ! src/share/vm/prims/nativeLookup.cpp ! src/share/vm/prims/unsafe.cpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/compilationPolicy.cpp ! src/share/vm/runtime/deoptimization.cpp ! src/share/vm/runtime/frame.cpp ! src/share/vm/runtime/frame.hpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/java.cpp ! src/share/vm/runtime/mutexLocker.cpp ! src/share/vm/runtime/mutexLocker.hpp ! src/share/vm/runtime/os.cpp ! src/share/vm/runtime/os.hpp ! src/share/vm/runtime/sharedRuntime.cpp ! src/share/vm/runtime/sharedRuntime.hpp ! src/share/vm/runtime/sweeper.cpp ! src/share/vm/runtime/synchronizer.cpp ! src/share/vm/runtime/thread.cpp ! src/share/vm/runtime/thread.hpp ! src/share/vm/runtime/vmStructs.cpp ! src/share/vm/runtime/vm_operations.cpp ! src/share/vm/runtime/vm_operations.hpp - src/share/vm/trace/traceEventTypes.hpp ! src/share/vm/utilities/debug.cpp ! src/share/vm/utilities/debug.hpp ! src/share/vm/utilities/globalDefinitions.hpp ! src/share/vm/utilities/macros.hpp ! src/share/vm/utilities/quickSort.cpp ! src/share/vm/utilities/vmError.cpp - test/runtime/7158804/Test7158804.sh - test/runtime/8003985/Test8003985.java Changeset: 36bcc10e01c0 Author: Doug Simon Date: 2013-06-19 15:37 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/36bcc10e01c0 merge fixes ! hotspot/.project ! src/cpu/sparc/vm/compiledIC_sparc.cpp ! src/cpu/x86/vm/compiledIC_x86.cpp ! src/cpu/x86/vm/sharedRuntime_x86_64.cpp ! src/share/vm/graal/graalCompiler.cpp ! src/share/vm/graal/graalEnv.cpp ! src/share/vm/oops/method.cpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/compilationPolicy.cpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/sharedRuntime.cpp ! src/share/vm/runtime/thread.hpp Changeset: 9062da84cd75 Author: Doug Simon Date: 2013-06-19 15:43 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/9062da84cd75 removed redundant import of platform specific codeInstaller_*.hpp files ! src/share/vm/graal/graalCodeInstaller.cpp Changeset: 67fa9b3e10ed Author: Doug Simon Date: 2013-06-19 15:46 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/67fa9b3e10ed renamed codeInstaller_.hpp to graalCodeInstaller_.hpp - src/cpu/sparc/vm/codeInstaller_sparc.hpp + src/cpu/sparc/vm/graalCodeInstaller_sparc.hpp - src/cpu/x86/vm/codeInstaller_x86.hpp + src/cpu/x86/vm/graalCodeInstaller_x86.hpp ! src/share/vm/graal/graalCodeInstaller.hpp Changeset: cd63140aaad7 Author: Doug Simon Date: 2013-06-19 16:14 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/cd63140aaad7 Merge. Changeset: 72034f38f953 Author: Doug Simon Date: 2013-06-19 18:20 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/72034f38f953 Merge. Changeset: 72eafe3a1c34 Author: Christos Kotselidis Date: 2013-06-18 19:30 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/72eafe3a1c34 Add comments in Compressed Oops ! graal/com.oracle.graal.lir.amd64/src/com/oracle/graal/lir/amd64/AMD64Move.java Changeset: 1c77d0732233 Author: Christos Kotselidis Date: 2013-06-18 19:30 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/1c77d0732233 Remove completely UseCompressedOops args ! src/share/vm/runtime/arguments.cpp Changeset: d61ad4aff3a8 Author: Christos Kotselidis Date: 2013-06-18 21:52 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/d61ad4aff3a8 Merge - make/build-graal.xml Changeset: acc1c61ba408 Author: Christos Kotselidis Date: 2013-06-19 12:24 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/acc1c61ba408 Add one more register in Register pressure configuration for Compressed Oops ! mx/commands.py Changeset: ff3c23a329ed Author: Christos Kotselidis Date: 2013-06-19 20:24 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/ff3c23a329ed Merge - agent/doc/c2replay.html - agent/src/share/classes/sun/jvm/hotspot/debugger/cdbg/basic/amd64/AMD64CFrame.java - agent/src/share/classes/sun/jvm/hotspot/debugger/cdbg/basic/x86/X86CFrame.java - make/bsd/makefiles/launcher.make - make/linux/makefiles/launcher.make - make/solaris/makefiles/launcher.make - make/windows/makefiles/launcher.make - src/cpu/sparc/vm/codeInstaller_sparc.hpp - src/cpu/x86/vm/codeInstaller_x86.hpp - src/os/bsd/vm/chaitin_bsd.cpp - src/os/linux/vm/chaitin_linux.cpp - src/os/posix/launcher/java_md.c - src/os/posix/launcher/java_md.h - src/os/posix/launcher/launcher.script - src/os/solaris/vm/chaitin_solaris.cpp - src/os/windows/launcher/java_md.c - src/os/windows/launcher/java_md.h - src/os/windows/vm/chaitin_windows.cpp - src/share/tools/launcher/java.c - src/share/tools/launcher/java.h - src/share/tools/launcher/jli_util.c - src/share/tools/launcher/jli_util.h - src/share/tools/launcher/wildcard.c - src/share/tools/launcher/wildcard.h - src/share/vm/gc_implementation/parallelScavenge/parMarkBitMap.inline.hpp ! src/share/vm/runtime/arguments.cpp - src/share/vm/trace/traceEventTypes.hpp - test/runtime/7158804/Test7158804.sh - test/runtime/8003985/Test8003985.java Changeset: ac79c138e734 Author: Gilles Duboscq Date: 2013-06-19 23:46 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/ac79c138e734 GraphBuilderPhase: handle locks properly during framestate merge ! graal/com.oracle.graal.java/src/com/oracle/graal/java/FrameStateBuilder.java + graal/com.oracle.graal.jtt/src/com/oracle/graal/jtt/threads/SynchronizedLoopExit01.java Changeset: 672e126cf996 Author: Bernhard Urban Date: 2013-06-19 23:46 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/672e126cf996 aot verify: s/AheadOfTimeVerifcationPhase/AheadOfTimeVerificationPhase/g ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotRuntime.java - graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/phases/AheadOfTimeVerifcationPhase.java + graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/phases/AheadOfTimeVerificationPhase.java Changeset: 1669d8b5863a Author: Bernhard Urban Date: 2013-06-19 23:47 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/1669d8b5863a aot verify: check if string constant is really a interned string; javadoc updates ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/phases/AheadOfTimeVerificationPhase.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/phases/LoadJavaMirrorWithKlassPhase.java ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/CanonicalizerPhase.java Changeset: a47dd157277e Author: Thomas Wuerthinger Date: 2013-06-19 21:49 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/a47dd157277e Simplified lowering phase. Removed "deferred" lowering. Removed custom setLastFixedNode method. ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/java/ExceptionObjectNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/spi/LoweringTool.java ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/LoweringPhase.java ! graal/com.oracle.graal.replacements/src/com/oracle/graal/replacements/SnippetTemplate.java Changeset: a6697eaddebd Author: Thomas Wuerthinger Date: 2013-06-19 21:54 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/a6697eaddebd Merge. - agent/doc/c2replay.html - agent/src/share/classes/sun/jvm/hotspot/debugger/cdbg/basic/amd64/AMD64CFrame.java - agent/src/share/classes/sun/jvm/hotspot/debugger/cdbg/basic/x86/X86CFrame.java - make/bsd/makefiles/launcher.make - make/linux/makefiles/launcher.make - make/solaris/makefiles/launcher.make - make/windows/makefiles/launcher.make - src/cpu/sparc/vm/codeInstaller_sparc.hpp - src/cpu/x86/vm/codeInstaller_x86.hpp - src/os/bsd/vm/chaitin_bsd.cpp - src/os/linux/vm/chaitin_linux.cpp - src/os/posix/launcher/java_md.c - src/os/posix/launcher/java_md.h - src/os/posix/launcher/launcher.script - src/os/solaris/vm/chaitin_solaris.cpp - src/os/windows/launcher/java_md.c - src/os/windows/launcher/java_md.h - src/os/windows/vm/chaitin_windows.cpp - src/share/tools/launcher/java.c - src/share/tools/launcher/java.h - src/share/tools/launcher/jli_util.c - src/share/tools/launcher/jli_util.h - src/share/tools/launcher/wildcard.c - src/share/tools/launcher/wildcard.h - src/share/vm/gc_implementation/parallelScavenge/parMarkBitMap.inline.hpp - src/share/vm/trace/traceEventTypes.hpp - test/runtime/7158804/Test7158804.sh - test/runtime/8003985/Test8003985.java Changeset: e6cf435419b2 Author: Thomas Wuerthinger Date: 2013-06-19 23:50 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/e6cf435419b2 Fix after lowering phase refactoring. ! graal/com.oracle.graal.graph/src/com/oracle/graal/graph/NodeClass.java ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/LoweringPhase.java Changeset: b61e946bf0ef Author: Thomas Wuerthinger Date: 2013-06-20 01:10 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/b61e946bf0ef Merge. - graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/phases/AheadOfTimeVerifcationPhase.java Changeset: 2fe8c94089b8 Author: Roland Schatz Date: 2013-06-20 10:17 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/2fe8c94089b8 Test DynamicNewArrayNode with void.class. ! graal/com.oracle.graal.replacements.test/src/com/oracle/graal/replacements/test/DynamicNewArrayTest.java Changeset: 58777dad7f90 Author: Roland Schatz Date: 2013-06-20 10:18 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/58777dad7f90 Cite source of comment in NewObjectSnippets. ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/NewObjectSnippets.java Changeset: 6188764e66af Author: Roland Schatz Date: 2013-06-20 11:17 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/6188764e66af Use stack kind to determine instruction in AMD64LIRGenerator. ! graal/com.oracle.graal.compiler.amd64/src/com/oracle/graal/compiler/amd64/AMD64LIRGenerator.java Changeset: 113c00c4def2 Author: Lukas Stadler Date: 2013-06-20 13:47 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/113c00c4def2 fix recent merge with hsx (Mac build problems) ! make/Makefile ! make/bsd/makefiles/buildtree.make Changeset: 77220af593d5 Author: Christos Kotselidis Date: 2013-06-20 15:10 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/77220af593d5 Add Write Barrier superclass ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/SerialWriteBarrier.java + graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/WriteBarrier.java Changeset: 7a2c49a5ffd4 Author: Christos Kotselidis Date: 2013-06-20 15:25 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/7a2c49a5ffd4 Add G1 Barrier nodes + graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/G1PostWriteBarrier.java + graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/G1PreWriteBarrier.java Changeset: dd3904c9487f Author: Christos Kotselidis Date: 2013-06-20 15:36 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/dd3904c9487f Fix CheckStyle errors ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/G1PostWriteBarrier.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/G1PreWriteBarrier.java Changeset: d7f4cc510a88 Author: Christos Kotselidis Date: 2013-06-20 15:36 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/d7f4cc510a88 Add G1 Barrier stub call nodes + graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/nodes/G1PostWriteBarrierStubCall.java + graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/nodes/G1PreWriteBarrierStubCall.java Changeset: 8b22524df53b Author: Christos Kotselidis Date: 2013-06-20 16:10 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/8b22524df53b Add G1 Barriers' foreign calls ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotRuntime.java ! src/share/vm/graal/graalCompilerToVM.cpp ! src/share/vm/graal/graalRuntime.cpp ! src/share/vm/graal/graalRuntime.hpp Changeset: 89c15a40ef35 Author: Christos Kotselidis Date: 2013-06-20 17:30 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/89c15a40ef35 Align foreign call descriptors ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/nodes/G1PostWriteBarrierStubCall.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/nodes/G1PreWriteBarrierStubCall.java Changeset: 8c8285e345cc Author: Roland Schatz Date: 2013-06-20 16:59 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/8c8285e345cc Later lowering of arraycopy. ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/phases/LowTier.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotRuntime.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/ArrayCopySnippets.java + graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/UnsafeArrayCopyNode.java + graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/UnsafeArrayCopySnippets.java Changeset: 1fb21605c0e1 Author: Roland Schatz Date: 2013-06-20 16:59 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/1fb21605c0e1 Common base class for nodes that need array range barriers. ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/phases/WriteBarrierAdditionPhase.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/GenericArrayRangeWriteBarrier.java + graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/extended/ArrayRangeWriteNode.java Changeset: 6a847d44d4ef Author: Roland Schatz Date: 2013-06-20 16:59 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/6a847d44d4ef Delay write barrier addition for arraycopy. ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/ArrayCopySnippets.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/UnsafeArrayCopyNode.java Changeset: b724895db5c0 Author: Roland Schatz Date: 2013-06-20 16:59 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/b724895db5c0 Remove unused class GenericArrayRangeWriteBarrier. ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/phases/WriteBarrierAdditionPhase.java - graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/GenericArrayRangeWriteBarrier.java Changeset: 7a0d4d95f84c Author: Doug Simon Date: 2013-06-20 17:38 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/7a0d4d95f84c moved write barrier tests to graal.hotspot.test and removed the graal.compiler.test -> graal.hotspot dependency - graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/WriteBarrierAdditionTest.java - graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/WriteBarrierVerificationTest.java + graal/com.oracle.graal.hotspot.test/src/com/oracle/graal/hotspot/test/WriteBarrierAdditionTest.java + graal/com.oracle.graal.hotspot.test/src/com/oracle/graal/hotspot/test/WriteBarrierVerificationTest.java ! mx/projects Changeset: 6447890af1bf Author: Doug Simon Date: 2013-06-20 21:11 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/6447890af1bf Merge. - graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/GenericArrayRangeWriteBarrier.java Changeset: 7381d7427f0f Author: Roland Schatz Date: 2013-06-21 11:12 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/7381d7427f0f Fix deoptimization problem in DynamicNewArrayNode. ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/NewObjectSnippets.java Changeset: 8b2573c8d47f Author: Christian Humer Date: 2013-06-18 10:10 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/8b2573c8d47f dsl cleanup. ! graal/com.oracle.graal.hotspot.amd64/src/com/oracle/graal/hotspot/amd64/AMD64DeoptimizeOp.java ! graal/com.oracle.graal.hotspot.amd64/src/com/oracle/graal/hotspot/amd64/AMD64TailcallOp.java ! graal/com.oracle.graal.service.processor/src/com/oracle/graal/service/processor/ServiceProviderProcessor.java - graal/com.oracle.truffle.api.codegen/src/com/oracle/truffle/api/codegen/ExecuteChildren.java - graal/com.oracle.truffle.api.codegen/src/com/oracle/truffle/api/codegen/ExtensionAnnotation.java ! graal/com.oracle.truffle.api.codegen/src/com/oracle/truffle/api/codegen/NodeChild.java ! graal/com.oracle.truffle.api.codegen/src/com/oracle/truffle/api/codegen/TypeSystem.java ! graal/com.oracle.truffle.api.codegen/src/com/oracle/truffle/api/codegen/TypeSystemReference.java - graal/com.oracle.truffle.codegen.processor/src/com/oracle/truffle/codegen/processor/ext/ExtensionCodeElementFactory.java - graal/com.oracle.truffle.codegen.processor/src/com/oracle/truffle/codegen/processor/ext/ExtensionContextImpl.java - graal/com.oracle.truffle.codegen.processor/src/com/oracle/truffle/codegen/processor/ext/ExtensionParser.java ! graal/com.oracle.truffle.codegen.processor/src/com/oracle/truffle/codegen/processor/template/TemplateParser.java ! graal/com.oracle.truffle.codegen.processor/src/com/oracle/truffle/codegen/processor/typesystem/TypeSystemCodeGenerator.java ! graal/com.oracle.truffle.codegen.processor/src/com/oracle/truffle/codegen/processor/typesystem/TypeSystemParser.java ! graal/com.oracle.truffle.sl/src/com/oracle/truffle/sl/nodes/PrintNode.java Changeset: ad48251630cd Author: Christian Humer Date: 2013-06-18 10:11 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/ad48251630cd Fixed GRAAL-321. ! graal/com.oracle.truffle.codegen.processor/src/com/oracle/truffle/codegen/processor/node/NodeParser.java Changeset: f158703c308c Author: Christian Humer Date: 2013-06-18 10:12 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/f158703c308c Merge. - graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/ea/PEAReadEliminationTest.java ! graal/com.oracle.graal.hotspot.amd64/src/com/oracle/graal/hotspot/amd64/AMD64DeoptimizeOp.java ! graal/com.oracle.graal.hotspot.amd64/src/com/oracle/graal/hotspot/amd64/AMD64TailcallOp.java - graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/nodes/WriteBarrierPost.java - graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/nodes/WriteBarrierPostStubCall.java - graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/nodes/WriteBarrierPre.java - graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/nodes/WriteBarrierPreStubCall.java - graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/InlineableElement.java - graal/com.oracle.graal.options/src/com/oracle/graal/options/OptionProvider.java - graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/CullFrameStatesPhase.java - graal/com.oracle.graal.virtual/src/com/oracle/graal/virtual/phases/ea/BlockState.java - graal/com.oracle.graal.virtual/src/com/oracle/graal/virtual/phases/ea/PartialEscapeAnalysisPhase.java Changeset: 746fa60be266 Author: Christian Humer Date: 2013-06-20 19:10 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/746fa60be266 Implemented CreateCast annotation for easier insertion of casts. + graal/com.oracle.truffle.api.codegen/src/com/oracle/truffle/api/codegen/CreateCast.java ! graal/com.oracle.truffle.codegen.processor/src/com/oracle/truffle/codegen/processor/Utils.java ! graal/com.oracle.truffle.codegen.processor/src/com/oracle/truffle/codegen/processor/ast/CodeTreeBuilder.java + graal/com.oracle.truffle.codegen.processor/src/com/oracle/truffle/codegen/processor/node/CreateCastData.java + graal/com.oracle.truffle.codegen.processor/src/com/oracle/truffle/codegen/processor/node/CreateCastParser.java ! graal/com.oracle.truffle.codegen.processor/src/com/oracle/truffle/codegen/processor/node/NodeChildData.java ! graal/com.oracle.truffle.codegen.processor/src/com/oracle/truffle/codegen/processor/node/NodeCodeGenerator.java ! graal/com.oracle.truffle.codegen.processor/src/com/oracle/truffle/codegen/processor/node/NodeData.java ! graal/com.oracle.truffle.codegen.processor/src/com/oracle/truffle/codegen/processor/node/NodeMethodParser.java ! graal/com.oracle.truffle.codegen.processor/src/com/oracle/truffle/codegen/processor/node/NodeParser.java ! graal/com.oracle.truffle.codegen.processor/src/com/oracle/truffle/codegen/processor/node/SpecializationData.java Changeset: 638387729ddf Author: Christian Humer Date: 2013-06-20 19:10 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/638387729ddf Merge. - agent/doc/c2replay.html - agent/src/share/classes/sun/jvm/hotspot/debugger/cdbg/basic/amd64/AMD64CFrame.java - agent/src/share/classes/sun/jvm/hotspot/debugger/cdbg/basic/x86/X86CFrame.java - graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/phases/AheadOfTimeVerifcationPhase.java - make/bsd/makefiles/launcher.make - make/build-graal.xml - make/linux/makefiles/launcher.make - make/solaris/makefiles/launcher.make - make/windows/makefiles/launcher.make - src/cpu/sparc/vm/codeInstaller_sparc.hpp - src/cpu/x86/vm/codeInstaller_x86.hpp - src/os/bsd/vm/chaitin_bsd.cpp - src/os/linux/vm/chaitin_linux.cpp - src/os/posix/launcher/java_md.c - src/os/posix/launcher/java_md.h - src/os/posix/launcher/launcher.script - src/os/solaris/vm/chaitin_solaris.cpp - src/os/windows/launcher/java_md.c - src/os/windows/launcher/java_md.h - src/os/windows/vm/chaitin_windows.cpp - src/share/tools/launcher/java.c - src/share/tools/launcher/java.h - src/share/tools/launcher/jli_util.c - src/share/tools/launcher/jli_util.h - src/share/tools/launcher/wildcard.c - src/share/tools/launcher/wildcard.h - src/share/vm/gc_implementation/parallelScavenge/parMarkBitMap.inline.hpp - src/share/vm/trace/traceEventTypes.hpp - test/runtime/7158804/Test7158804.sh - test/runtime/8003985/Test8003985.java Changeset: 8bb13e6ada94 Author: Christian Humer Date: 2013-06-20 19:40 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/8bb13e6ada94 Merge. Changeset: b3b87d500137 Author: Christian Humer Date: 2013-06-20 19:43 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/b3b87d500137 Fixed import. ! graal/com.oracle.graal.hotspot.amd64/src/com/oracle/graal/hotspot/amd64/AMD64DeoptimizeOp.java Changeset: 648165ffcf26 Author: Christian Humer Date: 2013-06-20 21:33 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/648165ffcf26 Merge. - graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/GenericArrayRangeWriteBarrier.java Changeset: 3754634b49a7 Author: Christian Humer Date: 2013-06-20 23:13 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/3754634b49a7 Merge. - graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/WriteBarrierAdditionTest.java - graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/WriteBarrierVerificationTest.java Changeset: 819251246143 Author: Christian Humer Date: 2013-06-21 12:05 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/819251246143 Readd accidentally commented code. ! graal/com.oracle.graal.service.processor/src/com/oracle/graal/service/processor/ServiceProviderProcessor.java Changeset: f748b42a1389 Author: Christian Humer Date: 2013-06-21 12:20 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/f748b42a1389 Merge. Changeset: 590b0c26877f Author: Bernhard Urban Date: 2013-06-21 14:16 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/590b0c26877f mx: add --workdir argument ! mx/commands.py Changeset: 467d9ae9912e Author: Bernhard Urban Date: 2013-06-21 14:17 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/467d9ae9912e mx: remove useless assignment ! mx/commands.py Changeset: e4dd840a39de Author: Roland Schatz Date: 2013-06-21 13:34 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/e4dd840a39de Use values from HotSpotVMConfig instead of hardcoding shifts and bitmasks. ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/NewObjectSnippets.java Changeset: fb95519008d6 Author: twisti Date: 2013-06-20 10:55 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/fb95519008d6 added back Graal export rules ! make/Makefile Changeset: 63e44cdabb91 Author: twisti Date: 2013-06-20 10:56 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/63e44cdabb91 fixed SPARC interpreter ! src/cpu/sparc/vm/interp_masm_sparc.cpp ! src/cpu/sparc/vm/interp_masm_sparc.hpp ! src/cpu/sparc/vm/templateTable_sparc.cpp ! src/cpu/x86/vm/interp_masm_x86_64.cpp Changeset: f78079947084 Author: twisti Date: 2013-06-20 20:40 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/f78079947084 some basic SPARC arithmetic works - graal/com.oracle.graal.asm.sparc/src/com/oracle/graal/asm/sparc/AbstractSPARCAssembler.java ! graal/com.oracle.graal.asm.sparc/src/com/oracle/graal/asm/sparc/SPARCAssembler.java ! graal/com.oracle.graal.asm.sparc/src/com/oracle/graal/asm/sparc/SPARCMacroAssembler.java - graal/com.oracle.graal.compiler.sparc/src/com/oracle/graal/compiler/sparc/SPARCBackend.java ! graal/com.oracle.graal.compiler.sparc/src/com/oracle/graal/compiler/sparc/SPARCLIRGenerator.java ! graal/com.oracle.graal.hotspot.sparc/src/com/oracle/graal/hotspot/sparc/SPARCHotSpotBackend.java + graal/com.oracle.graal.hotspot.sparc/src/com/oracle/graal/hotspot/sparc/SPARCHotSpotRegisterConfig.java ! graal/com.oracle.graal.hotspot.sparc/src/com/oracle/graal/hotspot/sparc/SPARCHotSpotRuntime.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/CompileTheWorld.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/SPARCCompare.java ! graal/com.oracle.graal.lir.sparc/src/com/oracle/graal/lir/sparc/SPARCControlFlow.java ! graal/com.oracle.graal.lir.sparc/src/com/oracle/graal/lir/sparc/SPARCMove.java ! graal/com.oracle.graal.lir.sparc/src/com/oracle/graal/lir/sparc/SPARCTestOp.java ! graal/com.oracle.graal.sparc/src/com/oracle/graal/sparc/SPARC.java Changeset: e799aba89b5d Author: twisti Date: 2013-06-20 20:41 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/e799aba89b5d Merge - graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/WriteBarrierAdditionTest.java - graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/WriteBarrierVerificationTest.java - graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/GenericArrayRangeWriteBarrier.java Changeset: 6b64601aa8c8 Author: twisti Date: 2013-06-20 20:50 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/6b64601aa8c8 backout CTW memory usage code ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/CompileTheWorld.java Changeset: c88019cc87f6 Author: twisti Date: 2013-06-20 22:07 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/c88019cc87f6 removed SPARC compiler test since SPARCBackend got moved to SPARCHotSpotBackend - graal/com.oracle.graal.compiler.sparc.test/src/com/oracle/graal/compiler/sparc/test/ArraySPARCTest.java - graal/com.oracle.graal.compiler.sparc.test/src/com/oracle/graal/compiler/sparc/test/BasicSPARCTest.java - graal/com.oracle.graal.compiler.sparc.test/src/com/oracle/graal/compiler/sparc/test/ControlSPARCTest.java - graal/com.oracle.graal.compiler.sparc.test/src/com/oracle/graal/compiler/sparc/test/FloatSPARCTest.java - graal/com.oracle.graal.compiler.sparc.test/src/com/oracle/graal/compiler/sparc/test/IntegerSPARCTest.java - graal/com.oracle.graal.compiler.sparc.test/src/com/oracle/graal/compiler/sparc/test/LogicSPARCTest.java - graal/com.oracle.graal.compiler.sparc.test/src/com/oracle/graal/compiler/sparc/test/SPARCTestBase.java Changeset: 1d79ddd777d9 Author: twisti Date: 2013-06-20 22:23 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/1d79ddd777d9 added SPARCAllocatorTest + graal/com.oracle.graal.compiler.sparc.test/src/com/oracle/graal/compiler/sparc/test/SPARCAllocatorTest.java Changeset: 83d789390d2e Author: twisti Date: 2013-06-20 22:26 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/83d789390d2e removed com.oracle.graal.compiler.sparc from com.oracle.graal.compiler.sparc.test ! mx/projects Changeset: 699ee4e4f9dc Author: twisti Date: 2013-06-20 22:26 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/699ee4e4f9dc fixed gate warnings ! graal/com.oracle.graal.asm.sparc/src/com/oracle/graal/asm/sparc/SPARCAssembler.java ! graal/com.oracle.graal.asm.sparc/src/com/oracle/graal/asm/sparc/SPARCMacroAssembler.java ! graal/com.oracle.graal.hotspot.sparc/src/com/oracle/graal/hotspot/sparc/SPARCHotSpotBackend.java Changeset: d95eaee1f6c0 Author: twisti Date: 2013-06-20 22:28 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/d95eaee1f6c0 fixed another gate warning ! graal/com.oracle.graal.asm.sparc/src/com/oracle/graal/asm/sparc/SPARCMacroAssembler.java Changeset: f0ec43f816a0 Author: twisti Date: 2013-06-20 22:40 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/f0ec43f816a0 fixed more warnings ! 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/SPARCCompare.java ! graal/com.oracle.graal.lir.sparc/src/com/oracle/graal/lir/sparc/SPARCControlFlow.java ! graal/com.oracle.graal.lir.sparc/src/com/oracle/graal/lir/sparc/SPARCMove.java ! graal/com.oracle.graal.lir.sparc/src/com/oracle/graal/lir/sparc/SPARCTestOp.java Changeset: cfbe4f978116 Author: twisti Date: 2013-06-21 11:38 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/cfbe4f978116 SPARC assembler enhancements and more fixes ! graal/com.oracle.graal.asm.sparc/src/com/oracle/graal/asm/sparc/SPARCAssembler.java ! graal/com.oracle.graal.asm.sparc/src/com/oracle/graal/asm/sparc/SPARCMacroAssembler.java ! graal/com.oracle.graal.lir.sparc/src/com/oracle/graal/lir/sparc/SPARCArithmetic.java ! graal/com.oracle.graal.lir.sparc/src/com/oracle/graal/lir/sparc/SPARCControlFlow.java Changeset: c43c4938e353 Author: twisti Date: 2013-06-21 11:38 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/c43c4938e353 Merge - graal/com.oracle.truffle.api.codegen/src/com/oracle/truffle/api/codegen/ExecuteChildren.java - graal/com.oracle.truffle.api.codegen/src/com/oracle/truffle/api/codegen/ExtensionAnnotation.java - graal/com.oracle.truffle.codegen.processor/src/com/oracle/truffle/codegen/processor/ext/ExtensionCodeElementFactory.java - graal/com.oracle.truffle.codegen.processor/src/com/oracle/truffle/codegen/processor/ext/ExtensionContextImpl.java - graal/com.oracle.truffle.codegen.processor/src/com/oracle/truffle/codegen/processor/ext/ExtensionParser.java Changeset: 53ba9df05fa2 Author: twisti Date: 2013-06-21 11:58 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/53ba9df05fa2 fixed remaining SPARC warnings using ecj ! graal/com.oracle.graal.compiler.sparc/src/com/oracle/graal/compiler/sparc/SPARCLIRGenerator.java ! graal/com.oracle.graal.hotspot.sparc/src/com/oracle/graal/hotspot/sparc/SPARCHotSpotBackend.java ! graal/com.oracle.graal.hotspot.sparc/src/com/oracle/graal/hotspot/sparc/SPARCHotSpotRuntime.java From s1255753 at sms.ed.ac.uk Mon Jun 24 10:47:27 2013 From: s1255753 at sms.ed.ac.uk (ATKIN-GRANVILLE Chris) Date: Mon, 24 Jun 2013 17:47:27 +0000 Subject: Low level PhasePosition Message-ID: Hi guys. Why was PhasePosition.LOW_LEVEL removed? I can't find any hints in the commit logs, nor any references to it in a current checkout of the repo. Is there a replacement for it? Chris -- The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336. From mick.jordan at oracle.com Mon Jun 24 10:54:26 2013 From: mick.jordan at oracle.com (Mick Jordan) Date: Mon, 24 Jun 2013 10:54:26 -0700 Subject: Low level PhasePosition In-Reply-To: References: Message-ID: <51C887D2.70904@oracle.com> On 6/24/13 10:47 AM, ATKIN-GRANVILLE Chris wrote: > Hi guys. Why was PhasePosition.LOW_LEVEL removed? I can't find any hints in the commit logs, nor any references to it in a current checkout of the repo. Is there a replacement for it? > > I don't know exactly why LOW_LEVEL was removed, but I do know that PhasePlan is in the process of being phased out (sic) to be replaced (eventually) by custom Suites. I used to use LOW_LEVEL and the way I worked around its demise was to use the appendPhase method on the PhaseSuite class, to add the phase to the end of the MidTier suite, e.g. bootSuites = Suites.createDefaultSuites(); PhaseSuite midTier = bootSuites.getMidTier(); midTier.appendPhase(new MyLowLevelPhase()); Mick From christian.thalinger at oracle.com Mon Jun 24 11:13:09 2013 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Mon, 24 Jun 2013 11:13:09 -0700 Subject: final graal HSAIL support patch In-Reply-To: <5DD1503F815BD14889DC81D28643E3A73D909869@sausexdag06.amd.com> References: <5DD1503F815BD14889DC81D28643E3A73D909869@sausexdag06.amd.com> Message-ID: <6BCB9963-2904-43B6-8C78-4E8A144B2BA1@oracle.com> I've created a Graal tracking bug so it's easier for me to handle it (the bug is not visible outside of Oracle): GRAAL-342: add HSAIL backend Here is the new webrev: http://cr.openjdk.java.net/~twisti/GRAAL-342/webrev/ -- Chris On Jun 19, 2013, at 3:27 PM, "Venkatachalam, Vasanth" wrote: > Hi Christian, > > Here?s the final version of our graal HSAIL support patch. This addresses all of Doug Simon?s comments. > > In particular, > > 1) Checkstyle errors have been fixed and all licenses in the Okra packages are attributed to Oracle. > 2) What was previously the com.amd.sumatra package has been removed and its source files (which don?t have anything Sumatra specific) have been moved into the com.oracle.graal.compiler.hsail package. > 3) Hotspot c++ source changes have been reverted and are no longer part of the webrev. > > Vasanth > From christian.thalinger at oracle.com Mon Jun 24 11:18:03 2013 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Mon, 24 Jun 2013 11:18:03 -0700 Subject: final graal HSAIL support patch In-Reply-To: <6BCB9963-2904-43B6-8C78-4E8A144B2BA1@oracle.com> References: <5DD1503F815BD14889DC81D28643E3A73D909869@sausexdag06.amd.com> <6BCB9963-2904-43B6-8C78-4E8A144B2BA1@oracle.com> Message-ID: <4A3B7F7E-E03B-4B31-9A48-FF50B159FC7D@oracle.com> On Jun 24, 2013, at 11:13 AM, Christian Thalinger wrote: > I've created a Graal tracking bug so it's easier for me to handle it (the bug is not visible outside of Oracle): > > GRAAL-342: add HSAIL backend > > Here is the new webrev: > > http://cr.openjdk.java.net/~twisti/GRAAL-342/webrev/ Two quick comments: 1) I understand that the way you're handling the assembler right now was much less work but I wonder if you ever want to go to support your binary format too. Then a full-fledged assembler as for the other platforms might be better. 2) The Labels. I remember talking to Gilles about this when I did the PTX work and I think there is a better way of doing this (although I can't recall). -- Chris > > -- Chris > > On Jun 19, 2013, at 3:27 PM, "Venkatachalam, Vasanth" wrote: > >> Hi Christian, >> >> Here?s the final version of our graal HSAIL support patch. This addresses all of Doug Simon?s comments. >> >> In particular, >> >> 1) Checkstyle errors have been fixed and all licenses in the Okra packages are attributed to Oracle. >> 2) What was previously the com.amd.sumatra package has been removed and its source files (which don?t have anything Sumatra specific) have been moved into the com.oracle.graal.compiler.hsail package. >> 3) Hotspot c++ source changes have been reverted and are no longer part of the webrev. >> >> Vasanth >> > From tom.deneau at amd.com Mon Jun 24 11:26:58 2013 From: tom.deneau at amd.com (Deneau, Tom) Date: Mon, 24 Jun 2013 18:26:58 +0000 Subject: [Sw.runtimes] final graal HSAIL support patch In-Reply-To: <6BCB9963-2904-43B6-8C78-4E8A144B2BA1@oracle.com> References: <5DD1503F815BD14889DC81D28643E3A73D909869@sausexdag06.amd.com> <6BCB9963-2904-43B6-8C78-4E8A144B2BA1@oracle.com> Message-ID: When are the graal tracking bugs going to become visible to everyone? Or are there plans for some other public bug tracking system? -- Tom Deneau From: sw.runtimes-bounces at mpdtxmail.amd.com [mailto:sw.runtimes-bounces at mpdtxmail.amd.com] On Behalf Of Christian Thalinger Sent: Monday, June 24, 2013 1:13 PM To: Venkatachalam, Vasanth Cc: sw.runtimes; Doug Simon @ Oracle (doug.simon at oracle.com); donald.smith at oracle.com; graal-dev at openjdk.java.net Subject: Re: [Sw.runtimes] final graal HSAIL support patch I've created a Graal tracking bug so it's easier for me to handle it (the bug is not visible outside of Oracle): GRAAL-342: add HSAIL backend Here is the new webrev: http://cr.openjdk.java.net/~twisti/GRAAL-342/webrev/ -- Chris On Jun 19, 2013, at 3:27 PM, "Venkatachalam, Vasanth" > wrote: Hi Christian, Here's the final version of our graal HSAIL support patch. This addresses all of Doug Simon's comments. In particular, 1) Checkstyle errors have been fixed and all licenses in the Okra packages are attributed to Oracle. 2) What was previously the com.amd.sumatra package has been removed and its source files (which don't have anything Sumatra specific) have been moved into the com.oracle.graal.compiler.hsail package. 3) Hotspot c++ source changes have been reverted and are no longer part of the webrev. Vasanth From christian.thalinger at oracle.com Mon Jun 24 11:34:32 2013 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Mon, 24 Jun 2013 11:34:32 -0700 Subject: [Sw.runtimes] final graal HSAIL support patch In-Reply-To: References: <5DD1503F815BD14889DC81D28643E3A73D909869@sausexdag06.amd.com> <6BCB9963-2904-43B6-8C78-4E8A144B2BA1@oracle.com> Message-ID: <5D8175AB-AD80-4D11-8E10-0F8D23D2D1D8@oracle.com> On Jun 24, 2013, at 11:26 AM, "Deneau, Tom" wrote: > When are the graal tracking bugs going to become visible to everyone? Presumably never. As I said earlier, there is no information in this bug it's just easier for me to create a webrev and other things. > Or are there plans for some other public bug tracking system? Yes. Oracle is working on this (JBS). -- Chris > > -- Tom Deneau > > > From: sw.runtimes-bounces at mpdtxmail.amd.com [mailto:sw.runtimes-bounces at mpdtxmail.amd.com] On Behalf Of Christian Thalinger > Sent: Monday, June 24, 2013 1:13 PM > To: Venkatachalam, Vasanth > Cc: sw.runtimes; Doug Simon @ Oracle (doug.simon at oracle.com); donald.smith at oracle.com; graal-dev at openjdk.java.net > Subject: Re: [Sw.runtimes] final graal HSAIL support patch > > I've created a Graal tracking bug so it's easier for me to handle it (the bug is not visible outside of Oracle): > > GRAAL-342: add HSAIL backend > > Here is the new webrev: > > http://cr.openjdk.java.net/~twisti/GRAAL-342/webrev/ > > -- Chris > > On Jun 19, 2013, at 3:27 PM, "Venkatachalam, Vasanth" wrote: > > > Hi Christian, > > Here?s the final version of our graal HSAIL support patch. This addresses all of Doug Simon?s comments. > > In particular, > > 1) Checkstyle errors have been fixed and all licenses in the Okra packages are attributed to Oracle. > 2) What was previously the com.amd.sumatra package has been removed and its source files (which don?t have anything Sumatra specific) have been moved into the com.oracle.graal.compiler.hsail package. > 3) Hotspot c++ source changes have been reverted and are no longer part of the webrev. > > Vasanth > From thomas.wuerthinger at oracle.com Mon Jun 24 11:38:26 2013 From: thomas.wuerthinger at oracle.com (Thomas Wuerthinger) Date: Mon, 24 Jun 2013 20:38:26 +0200 Subject: [Sw.runtimes] final graal HSAIL support patch In-Reply-To: References: <5DD1503F815BD14889DC81D28643E3A73D909869@sausexdag06.amd.com> <6BCB9963-2904-43B6-8C78-4E8A144B2BA1@oracle.com> Message-ID: There are plans to have a public JIRA bug tracking system for OpenJDK [1]. Unfortunately, I have no information on the timeline for that. - thomas [1] https://blogs.oracle.com/darcy/entry/milestone_jira_system_of_record On Jun 24, 2013, at 8:26 PM, "Deneau, Tom" wrote: > When are the graal tracking bugs going to become visible to everyone? > Or are there plans for some other public bug tracking system? > > -- Tom Deneau > > > From: sw.runtimes-bounces at mpdtxmail.amd.com [mailto:sw.runtimes-bounces at mpdtxmail.amd.com] On Behalf Of Christian Thalinger > Sent: Monday, June 24, 2013 1:13 PM > To: Venkatachalam, Vasanth > Cc: sw.runtimes; Doug Simon @ Oracle (doug.simon at oracle.com); donald.smith at oracle.com; graal-dev at openjdk.java.net > Subject: Re: [Sw.runtimes] final graal HSAIL support patch > > I've created a Graal tracking bug so it's easier for me to handle it (the bug is not visible outside of Oracle): > > GRAAL-342: add HSAIL backend > > Here is the new webrev: > > http://cr.openjdk.java.net/~twisti/GRAAL-342/webrev/ > > -- Chris > > On Jun 19, 2013, at 3:27 PM, "Venkatachalam, Vasanth" > wrote: > > > Hi Christian, > > Here's the final version of our graal HSAIL support patch. This addresses all of Doug Simon's comments. > > In particular, > > 1) Checkstyle errors have been fixed and all licenses in the Okra packages are attributed to Oracle. > 2) What was previously the com.amd.sumatra package has been removed and its source files (which don't have anything Sumatra specific) have been moved into the com.oracle.graal.compiler.hsail package. > 3) Hotspot c++ source changes have been reverted and are no longer part of the webrev. > > Vasanth > > From tom.deneau at amd.com Mon Jun 24 12:07:59 2013 From: tom.deneau at amd.com (Deneau, Tom) Date: Mon, 24 Jun 2013 19:07:59 +0000 Subject: stackslot question Message-ID: In HSAIL there is not stack register as such but we can declare an array that is private to each workitem and reference at positive offsets into it. I see there is a bug in our current HSAIL implementation of stack slots which needs to be fixed and we are exploring different ways to fix it. My question is, assuming a load from a certain stackslot always reads back what was stored to that stackslot, (when the load and store both using the same data width) is there any requirement on the relative positions of different stackslots in memory, for example does it matter whether stackslot -8 is at a higher or lower memory address compared to stackslot -16? -- Tom Deneau From thomas.wuerthinger at oracle.com Mon Jun 24 13:13:58 2013 From: thomas.wuerthinger at oracle.com (Thomas Wuerthinger) Date: Mon, 24 Jun 2013 22:13:58 +0200 Subject: final graal HSAIL support patch In-Reply-To: <4A3B7F7E-E03B-4B31-9A48-FF50B159FC7D@oracle.com> References: <5DD1503F815BD14889DC81D28643E3A73D909869@sausexdag06.amd.com> <6BCB9963-2904-43B6-8C78-4E8A144B2BA1@oracle.com> <4A3B7F7E-E03B-4B31-9A48-FF50B159FC7D@oracle.com> Message-ID: <9C584B81-E266-4D93-AA4F-98717CD703C4@oracle.com> Vasanth, Thanks for the patch. I have a first round of coding style comments. We would like the code to adhere to the style guide used for all other Graal modules (although of course we might have already quite some violations in the code base?). For explaining some of those style guide lines, I'm using the HSAILAssembler.java file as an example [1]: - Line 36: Comment should end with ".". - Line 37: Instance field should be declared private. - Line 37: "= 0" should be removed given that 0 is the default value for variables of type "int". - Line 37: The name of the variable must be written in camel case "maxdatatypesize" => "maxDataTypeSize". - Line 38: Comment should start with an upper case letter. - Line 56: Remove "// TODO Auto-generated method stub". If the method is not used, replace with throwing an error/exception (GraalInternalError.shouldNotReachHere). - Line 60: Method name "at" seems too short/ambiguous. - Line 72-76: Multi-line "//" comment should be replaced with javadoc "/** */" comment. - Line 88: Remove unnecessary blank line. - Line 91: Use camel case for method names "emit_mov" => "emitMov" (we have violated this rule for the PTX assembler, but are going to fix that; at least we want to use "_" only in rare instances). - Line 97: Remove unnecessary blank line (please also fix for subsequent lines of the file). - Line 135: No commented-out code - please remove line. - Line 190: Use camel case for method names "emit_convert" => "emitConvert" (please also fix for subsequent method names of the file). - Line 196: Either remove comment or put javadoc comment including additional information. - Line 236: Comment on method should be javadoc comment. - Line 247-248: Comment seems on the wrong place. If this is a comment on the parameter "controlRegString", then please put the comment in the javadoc. Looking over the other files, there are similar style guide line violations, so please make a short sweep over the patch with those items in mind. Additionally, we would like to see a short javadoc description for each newly added class. This seems important given that we will need to maintain this code moving forward. Thanks, thomas [1] http://cr.openjdk.java.net/~twisti/GRAAL-342/webrev/graal/com.oracle.graal.asm.hsail/src/com/oracle/graal/asm/hsail/HSAILAssembler.java.html On Jun 24, 2013, at 8:18 PM, Christian Thalinger wrote: > > On Jun 24, 2013, at 11:13 AM, Christian Thalinger wrote: > >> I've created a Graal tracking bug so it's easier for me to handle it (the bug is not visible outside of Oracle): >> >> GRAAL-342: add HSAIL backend >> >> Here is the new webrev: >> >> http://cr.openjdk.java.net/~twisti/GRAAL-342/webrev/ > > Two quick comments: > > 1) I understand that the way you're handling the assembler right now was much less work but I wonder if you ever want to go to support your binary format too. Then a full-fledged assembler as for the other platforms might be better. > > 2) The Labels. I remember talking to Gilles about this when I did the PTX work and I think there is a better way of doing this (although I can't recall). > > -- Chris > >> >> -- Chris >> >> On Jun 19, 2013, at 3:27 PM, "Venkatachalam, Vasanth" wrote: >> >>> Hi Christian, >>> >>> Here?s the final version of our graal HSAIL support patch. This addresses all of Doug Simon?s comments. >>> >>> In particular, >>> >>> 1) Checkstyle errors have been fixed and all licenses in the Okra packages are attributed to Oracle. >>> 2) What was previously the com.amd.sumatra package has been removed and its source files (which don?t have anything Sumatra specific) have been moved into the com.oracle.graal.compiler.hsail package. >>> 3) Hotspot c++ source changes have been reverted and are no longer part of the webrev. >>> >>> Vasanth >>> >> > From doug.simon at oracle.com Mon Jun 24 13:29:48 2013 From: doug.simon at oracle.com (Doug Simon) Date: Mon, 24 Jun 2013 22:29:48 +0200 Subject: final graal HSAIL support patch In-Reply-To: <9C584B81-E266-4D93-AA4F-98717CD703C4@oracle.com> References: <5DD1503F815BD14889DC81D28643E3A73D909869@sausexdag06.amd.com> <6BCB9963-2904-43B6-8C78-4E8A144B2BA1@oracle.com> <4A3B7F7E-E03B-4B31-9A48-FF50B159FC7D@oracle.com> <9C584B81-E266-4D93-AA4F-98717CD703C4@oracle.com> Message-ID: <68BA4718-61A3-43F8-9777-ACAB2E969D59@oracle.com> Vasanth, Just one more request on top of Thomas' feedback. We'd like to keep all the Graal code in a com.oracle.graal package namespace. As such, could you please rename the com.amd.okra package to something like com.oracle.graal.amd.okra or simply com.oracle.graal.okra. Thanks. -Doug On Jun 24, 2013, at 10:13 PM, Thomas Wuerthinger wrote: > Vasanth, > > Thanks for the patch. I have a first round of coding style comments. We would like the code to adhere to the style guide used for all other Graal modules (although of course we might have already quite some violations in the code base?). For explaining some of those style guide lines, I'm using the HSAILAssembler.java file as an example [1]: > > - Line 36: Comment should end with ".". > - Line 37: Instance field should be declared private. > - Line 37: "= 0" should be removed given that 0 is the default value for variables of type "int". > - Line 37: The name of the variable must be written in camel case "maxdatatypesize" => "maxDataTypeSize". > - Line 38: Comment should start with an upper case letter. > - Line 56: Remove "// TODO Auto-generated method stub". If the method is not used, replace with throwing an error/exception (GraalInternalError.shouldNotReachHere). > - Line 60: Method name "at" seems too short/ambiguous. > - Line 72-76: Multi-line "//" comment should be replaced with javadoc "/** */" comment. > - Line 88: Remove unnecessary blank line. > - Line 91: Use camel case for method names "emit_mov" => "emitMov" (we have violated this rule for the PTX assembler, but are going to fix that; at least we want to use "_" only in rare instances). > - Line 97: Remove unnecessary blank line (please also fix for subsequent lines of the file). > - Line 135: No commented-out code - please remove line. > - Line 190: Use camel case for method names "emit_convert" => "emitConvert" (please also fix for subsequent method names of the file). > - Line 196: Either remove comment or put javadoc comment including additional information. > - Line 236: Comment on method should be javadoc comment. > - Line 247-248: Comment seems on the wrong place. If this is a comment on the parameter "controlRegString", then please put the comment in the javadoc. > > Looking over the other files, there are similar style guide line violations, so please make a short sweep over the patch with those items in mind. > > Additionally, we would like to see a short javadoc description for each newly added class. This seems important given that we will need to maintain this code moving forward. > > Thanks, thomas > > [1] http://cr.openjdk.java.net/~twisti/GRAAL-342/webrev/graal/com.oracle.graal.asm.hsail/src/com/oracle/graal/asm/hsail/HSAILAssembler.java.html > > On Jun 24, 2013, at 8:18 PM, Christian Thalinger wrote: > >> >> On Jun 24, 2013, at 11:13 AM, Christian Thalinger wrote: >> >>> I've created a Graal tracking bug so it's easier for me to handle it (the bug is not visible outside of Oracle): >>> >>> GRAAL-342: add HSAIL backend >>> >>> Here is the new webrev: >>> >>> http://cr.openjdk.java.net/~twisti/GRAAL-342/webrev/ >> >> Two quick comments: >> >> 1) I understand that the way you're handling the assembler right now was much less work but I wonder if you ever want to go to support your binary format too. Then a full-fledged assembler as for the other platforms might be better. >> >> 2) The Labels. I remember talking to Gilles about this when I did the PTX work and I think there is a better way of doing this (although I can't recall). >> >> -- Chris >> >>> >>> -- Chris >>> >>> On Jun 19, 2013, at 3:27 PM, "Venkatachalam, Vasanth" wrote: >>> >>>> Hi Christian, >>>> >>>> Here?s the final version of our graal HSAIL support patch. This addresses all of Doug Simon?s comments. >>>> >>>> In particular, >>>> >>>> 1) Checkstyle errors have been fixed and all licenses in the Okra packages are attributed to Oracle. >>>> 2) What was previously the com.amd.sumatra package has been removed and its source files (which don?t have anything Sumatra specific) have been moved into the com.oracle.graal.compiler.hsail package. >>>> 3) Hotspot c++ source changes have been reverted and are no longer part of the webrev. >>>> >>>> Vasanth >>>> >>> >> > From tom.deneau at amd.com Mon Jun 24 14:08:13 2013 From: tom.deneau at amd.com (Deneau, Tom) Date: Mon, 24 Jun 2013 21:08:13 +0000 Subject: [Sw.runtimes] final graal HSAIL support patch In-Reply-To: <68BA4718-61A3-43F8-9777-ACAB2E969D59@oracle.com> References: <5DD1503F815BD14889DC81D28643E3A73D909869@sausexdag06.amd.com> <6BCB9963-2904-43B6-8C78-4E8A144B2BA1@oracle.com> <4A3B7F7E-E03B-4B31-9A48-FF50B159FC7D@oracle.com> <9C584B81-E266-4D93-AA4F-98717CD703C4@oracle.com> <68BA4718-61A3-43F8-9777-ACAB2E969D59@oracle.com> Message-ID: Doug -- As you may have noticed, many of the methods in com.amd.okra are native so there is a corresponding native library with com_amd_okra_xxx names which is needed if you want to actually dispatch anything. This is an open source project of its own and will be used by other projects such as Aparapi. Since there is nothing graal-specific in the native library, it doesn't seem right to have a graal namespace on it. So leaving com.amd.okra as the package name would be our first choice. A second choice would be to have the com.oracle.graal.okra which you propose be a stub which could be built against but would use reflection to get to the real com.amd.okra which could be shipped as a jar with the okra native libraries. A third choice is going back to your earlier proposal of graal building against an okra.jar which would be downloaded from somewhere (would cr.openjdk.java.net do for this?) Our earlier concern was that the third choice would more easily get out of sync with the actual native libraries but as I think about it all three choices have this possibility of getting out of sync with the native libraries. -- Tom -----Original Message----- From: sw.runtimes-bounces at mpdtxmail.amd.com [mailto:sw.runtimes-bounces at mpdtxmail.amd.com] On Behalf Of Doug Simon Sent: Monday, June 24, 2013 3:30 PM To: Thomas Wuerthinger Cc: graal-dev at openjdk.java.net; sw.runtimes; donald.smith at oracle.com Smith Subject: Re: [Sw.runtimes] final graal HSAIL support patch Vasanth, Just one more request on top of Thomas' feedback. We'd like to keep all the Graal code in a com.oracle.graal package namespace. As such, could you please rename the com.amd.okra package to something like com.oracle.graal.amd.okra or simply com.oracle.graal.okra. Thanks. -Doug On Jun 24, 2013, at 10:13 PM, Thomas Wuerthinger wrote: > Vasanth, > > Thanks for the patch. I have a first round of coding style comments. We would like the code to adhere to the style guide used for all other Graal modules (although of course we might have already quite some violations in the code base...). For explaining some of those style guide lines, I'm using the HSAILAssembler.java file as an example [1]: > > - Line 36: Comment should end with ".". > - Line 37: Instance field should be declared private. > - Line 37: "= 0" should be removed given that 0 is the default value for variables of type "int". > - Line 37: The name of the variable must be written in camel case "maxdatatypesize" => "maxDataTypeSize". > - Line 38: Comment should start with an upper case letter. > - Line 56: Remove "// TODO Auto-generated method stub". If the method is not used, replace with throwing an error/exception (GraalInternalError.shouldNotReachHere). > - Line 60: Method name "at" seems too short/ambiguous. > - Line 72-76: Multi-line "//" comment should be replaced with javadoc "/** */" comment. > - Line 88: Remove unnecessary blank line. > - Line 91: Use camel case for method names "emit_mov" => "emitMov" (we have violated this rule for the PTX assembler, but are going to fix that; at least we want to use "_" only in rare instances). > - Line 97: Remove unnecessary blank line (please also fix for subsequent lines of the file). > - Line 135: No commented-out code - please remove line. > - Line 190: Use camel case for method names "emit_convert" => "emitConvert" (please also fix for subsequent method names of the file). > - Line 196: Either remove comment or put javadoc comment including additional information. > - Line 236: Comment on method should be javadoc comment. > - Line 247-248: Comment seems on the wrong place. If this is a comment on the parameter "controlRegString", then please put the comment in the javadoc. > > Looking over the other files, there are similar style guide line violations, so please make a short sweep over the patch with those items in mind. > > Additionally, we would like to see a short javadoc description for each newly added class. This seems important given that we will need to maintain this code moving forward. > > Thanks, thomas > > [1] http://cr.openjdk.java.net/~twisti/GRAAL-342/webrev/graal/com.oracle.graal.asm.hsail/src/com/oracle/graal/asm/hsail/HSAILAssembler.java.html > > On Jun 24, 2013, at 8:18 PM, Christian Thalinger wrote: > >> >> On Jun 24, 2013, at 11:13 AM, Christian Thalinger wrote: >> >>> I've created a Graal tracking bug so it's easier for me to handle it (the bug is not visible outside of Oracle): >>> >>> GRAAL-342: add HSAIL backend >>> >>> Here is the new webrev: >>> >>> http://cr.openjdk.java.net/~twisti/GRAAL-342/webrev/ >> >> Two quick comments: >> >> 1) I understand that the way you're handling the assembler right now was much less work but I wonder if you ever want to go to support your binary format too. Then a full-fledged assembler as for the other platforms might be better. >> >> 2) The Labels. I remember talking to Gilles about this when I did the PTX work and I think there is a better way of doing this (although I can't recall). >> >> -- Chris >> >>> >>> -- Chris >>> >>> On Jun 19, 2013, at 3:27 PM, "Venkatachalam, Vasanth" wrote: >>> >>>> Hi Christian, >>>> >>>> Here's the final version of our graal HSAIL support patch. This addresses all of Doug Simon's comments. >>>> >>>> In particular, >>>> >>>> 1) Checkstyle errors have been fixed and all licenses in the Okra packages are attributed to Oracle. >>>> 2) What was previously the com.amd.sumatra package has been removed and its source files (which don't have anything Sumatra specific) have been moved into the com.oracle.graal.compiler.hsail package. >>>> 3) Hotspot c++ source changes have been reverted and are no longer part of the webrev. >>>> >>>> Vasanth >>>> >>> >> > From Vasanth.Venkatachalam at amd.com Mon Jun 24 14:29:26 2013 From: Vasanth.Venkatachalam at amd.com (Venkatachalam, Vasanth) Date: Mon, 24 Jun 2013 21:29:26 +0000 Subject: final graal HSAIL support patch In-Reply-To: <9C584B81-E266-4D93-AA4F-98717CD703C4@oracle.com> References: <5DD1503F815BD14889DC81D28643E3A73D909869@sausexdag06.amd.com> <6BCB9963-2904-43B6-8C78-4E8A144B2BA1@oracle.com> <4A3B7F7E-E03B-4B31-9A48-FF50B159FC7D@oracle.com> <9C584B81-E266-4D93-AA4F-98717CD703C4@oracle.com> Message-ID: <5DD1503F815BD14889DC81D28643E3A73D90E068@sausexdag06.amd.com> Hi Thomas, We're addressing your comments. It would be nice if checkstyle and/or the Graal formatter in Eclipse would have picked up on these errors, so that we could have caught them the first time around. Vasanth From: Thomas Wuerthinger [mailto:thomas.wuerthinger at oracle.com] Sent: Monday, June 24, 2013 3:14 PM To: Venkatachalam, Vasanth Cc: sw.runtimes; donald.smith at oracle.com Smith; graal-dev at openjdk.java.net; Christian Thalinger Subject: Re: final graal HSAIL support patch Vasanth, Thanks for the patch. I have a first round of coding style comments. We would like the code to adhere to the style guide used for all other Graal modules (although of course we might have already quite some violations in the code base...). For explaining some of those style guide lines, I'm using the HSAILAssembler.java file as an example [1]: - Line 36: Comment should end with ".". - Line 37: Instance field should be declared private. - Line 37: "= 0" should be removed given that 0 is the default value for variables of type "int". - Line 37: The name of the variable must be written in camel case "maxdatatypesize" => "maxDataTypeSize". - Line 38: Comment should start with an upper case letter. - Line 56: Remove "// TODO Auto-generated method stub". If the method is not used, replace with throwing an error/exception (GraalInternalError.shouldNotReachHere). - Line 60: Method name "at" seems too short/ambiguous. - Line 72-76: Multi-line "//" comment should be replaced with javadoc "/** */" comment. - Line 88: Remove unnecessary blank line. - Line 91: Use camel case for method names "emit_mov" => "emitMov" (we have violated this rule for the PTX assembler, but are going to fix that; at least we want to use "_" only in rare instances). - Line 97: Remove unnecessary blank line (please also fix for subsequent lines of the file). - Line 135: No commented-out code - please remove line. - Line 190: Use camel case for method names "emit_convert" => "emitConvert" (please also fix for subsequent method names of the file). - Line 196: Either remove comment or put javadoc comment including additional information. - Line 236: Comment on method should be javadoc comment. - Line 247-248: Comment seems on the wrong place. If this is a comment on the parameter "controlRegString", then please put the comment in the javadoc. Looking over the other files, there are similar style guide line violations, so please make a short sweep over the patch with those items in mind. Additionally, we would like to see a short javadoc description for each newly added class. This seems important given that we will need to maintain this code moving forward. Thanks, thomas [1] http://cr.openjdk.java.net/~twisti/GRAAL-342/webrev/graal/com.oracle.graal.asm.hsail/src/com/oracle/graal/asm/hsail/HSAILAssembler.java.html On Jun 24, 2013, at 8:18 PM, Christian Thalinger > wrote: On Jun 24, 2013, at 11:13 AM, Christian Thalinger > wrote: I've created a Graal tracking bug so it's easier for me to handle it (the bug is not visible outside of Oracle): GRAAL-342: add HSAIL backend Here is the new webrev: http://cr.openjdk.java.net/~twisti/GRAAL-342/webrev/ Two quick comments: 1) I understand that the way you're handling the assembler right now was much less work but I wonder if you ever want to go to support your binary format too. Then a full-fledged assembler as for the other platforms might be better. 2) The Labels. I remember talking to Gilles about this when I did the PTX work and I think there is a better way of doing this (although I can't recall). -- Chris -- Chris On Jun 19, 2013, at 3:27 PM, "Venkatachalam, Vasanth" > wrote: Hi Christian, Here's the final version of our graal HSAIL support patch. This addresses all of Doug Simon's comments. In particular, 1) Checkstyle errors have been fixed and all licenses in the Okra packages are attributed to Oracle. 2) What was previously the com.amd.sumatra package has been removed and its source files (which don't have anything Sumatra specific) have been moved into the com.oracle.graal.compiler.hsail package. 3) Hotspot c++ source changes have been reverted and are no longer part of the webrev. Vasanth From doug.simon at oracle.com Mon Jun 24 14:33:09 2013 From: doug.simon at oracle.com (Doug Simon) Date: Mon, 24 Jun 2013 23:33:09 +0200 Subject: [Sw.runtimes] final graal HSAIL support patch In-Reply-To: References: <5DD1503F815BD14889DC81D28643E3A73D909869@sausexdag06.amd.com> <6BCB9963-2904-43B6-8C78-4E8A144B2BA1@oracle.com> <4A3B7F7E-E03B-4B31-9A48-FF50B159FC7D@oracle.com> <9C584B81-E266-4D93-AA4F-98717CD703C4@oracle.com> <68BA4718-61A3-43F8-9777-ACAB2E969D59@oracle.com> Message-ID: Hi Tom, Ok, based on the need to link with the native code and the fact that there is nothing particularly Graal specific in this code, I think the okra-.jar solution is the best one moving forward. The suffix on the jar should be sufficient to manage any version dependencies from the other HSAIL code and the Okra library. I'm guessing that this library interface will not change very often anyway. As you state, the issue of staying in sync with the native code will have to be resolved some other way anyway. One request I have is that the okra-.jar file also contain the Java sources so that debugging through this code should be straightforward. -Doug On Jun 24, 2013, at 11:08 PM, "Deneau, Tom" wrote: > Doug -- > > As you may have noticed, many of the methods in com.amd.okra are native so there is a corresponding native library with com_amd_okra_xxx names which is needed if you want to actually dispatch anything. This is an open source project of its own and will be used by other projects such as Aparapi. Since there is nothing graal-specific in the native library, it doesn't seem right to have a graal namespace on it. So leaving com.amd.okra as the package name would be our first choice. > > A second choice would be to have the com.oracle.graal.okra which you propose be a stub which could be built against but would use reflection to get to the real com.amd.okra which could be shipped as a jar with the okra native libraries. > > A third choice is going back to your earlier proposal of graal building against an okra.jar which would be downloaded from somewhere (would cr.openjdk.java.net do for this?) > > Our earlier concern was that the third choice would more easily get out of sync with the actual native libraries but as I think about it all three choices have this possibility of getting out of sync with the native libraries. > > -- Tom > > > -----Original Message----- > From: sw.runtimes-bounces at mpdtxmail.amd.com [mailto:sw.runtimes-bounces at mpdtxmail.amd.com] On Behalf Of Doug Simon > Sent: Monday, June 24, 2013 3:30 PM > To: Thomas Wuerthinger > Cc: graal-dev at openjdk.java.net; sw.runtimes; donald.smith at oracle.com Smith > Subject: Re: [Sw.runtimes] final graal HSAIL support patch > > Vasanth, > > Just one more request on top of Thomas' feedback. > > We'd like to keep all the Graal code in a com.oracle.graal package namespace. As such, could you please rename the com.amd.okra package to something like com.oracle.graal.amd.okra or simply com.oracle.graal.okra. > > Thanks. > > -Doug > > On Jun 24, 2013, at 10:13 PM, Thomas Wuerthinger wrote: > >> Vasanth, >> >> Thanks for the patch. I have a first round of coding style comments. We would like the code to adhere to the style guide used for all other Graal modules (although of course we might have already quite some violations in the code base...). For explaining some of those style guide lines, I'm using the HSAILAssembler.java file as an example [1]: >> >> - Line 36: Comment should end with ".". >> - Line 37: Instance field should be declared private. >> - Line 37: "= 0" should be removed given that 0 is the default value for variables of type "int". >> - Line 37: The name of the variable must be written in camel case "maxdatatypesize" => "maxDataTypeSize". >> - Line 38: Comment should start with an upper case letter. >> - Line 56: Remove "// TODO Auto-generated method stub". If the method is not used, replace with throwing an error/exception (GraalInternalError.shouldNotReachHere). >> - Line 60: Method name "at" seems too short/ambiguous. >> - Line 72-76: Multi-line "//" comment should be replaced with javadoc "/** */" comment. >> - Line 88: Remove unnecessary blank line. >> - Line 91: Use camel case for method names "emit_mov" => "emitMov" (we have violated this rule for the PTX assembler, but are going to fix that; at least we want to use "_" only in rare instances). >> - Line 97: Remove unnecessary blank line (please also fix for subsequent lines of the file). >> - Line 135: No commented-out code - please remove line. >> - Line 190: Use camel case for method names "emit_convert" => "emitConvert" (please also fix for subsequent method names of the file). >> - Line 196: Either remove comment or put javadoc comment including additional information. >> - Line 236: Comment on method should be javadoc comment. >> - Line 247-248: Comment seems on the wrong place. If this is a comment on the parameter "controlRegString", then please put the comment in the javadoc. >> >> Looking over the other files, there are similar style guide line violations, so please make a short sweep over the patch with those items in mind. >> >> Additionally, we would like to see a short javadoc description for each newly added class. This seems important given that we will need to maintain this code moving forward. >> >> Thanks, thomas >> >> [1] http://cr.openjdk.java.net/~twisti/GRAAL-342/webrev/graal/com.oracle.graal.asm.hsail/src/com/oracle/graal/asm/hsail/HSAILAssembler.java.html >> >> On Jun 24, 2013, at 8:18 PM, Christian Thalinger wrote: >> >>> >>> On Jun 24, 2013, at 11:13 AM, Christian Thalinger wrote: >>> >>>> I've created a Graal tracking bug so it's easier for me to handle it (the bug is not visible outside of Oracle): >>>> >>>> GRAAL-342: add HSAIL backend >>>> >>>> Here is the new webrev: >>>> >>>> http://cr.openjdk.java.net/~twisti/GRAAL-342/webrev/ >>> >>> Two quick comments: >>> >>> 1) I understand that the way you're handling the assembler right now was much less work but I wonder if you ever want to go to support your binary format too. Then a full-fledged assembler as for the other platforms might be better. >>> >>> 2) The Labels. I remember talking to Gilles about this when I did the PTX work and I think there is a better way of doing this (although I can't recall). >>> >>> -- Chris >>> >>>> >>>> -- Chris >>>> >>>> On Jun 19, 2013, at 3:27 PM, "Venkatachalam, Vasanth" wrote: >>>> >>>>> Hi Christian, >>>>> >>>>> Here's the final version of our graal HSAIL support patch. This addresses all of Doug Simon's comments. >>>>> >>>>> In particular, >>>>> >>>>> 1) Checkstyle errors have been fixed and all licenses in the Okra packages are attributed to Oracle. >>>>> 2) What was previously the com.amd.sumatra package has been removed and its source files (which don't have anything Sumatra specific) have been moved into the com.oracle.graal.compiler.hsail package. >>>>> 3) Hotspot c++ source changes have been reverted and are no longer part of the webrev. >>>>> >>>>> Vasanth >>>>> >>>> >>> >> > > > > From thomas.wuerthinger at oracle.com Mon Jun 24 14:38:53 2013 From: thomas.wuerthinger at oracle.com (Thomas Wuerthinger) Date: Mon, 24 Jun 2013 23:38:53 +0200 Subject: final graal HSAIL support patch In-Reply-To: <5DD1503F815BD14889DC81D28643E3A73D90E068@sausexdag06.amd.com> References: <5DD1503F815BD14889DC81D28643E3A73D909869@sausexdag06.amd.com> <6BCB9963-2904-43B6-8C78-4E8A144B2BA1@oracle.com> <4A3B7F7E-E03B-4B31-9A48-FF50B159FC7D@oracle.com> <9C584B81-E266-4D93-AA4F-98717CD703C4@oracle.com> <5DD1503F815BD14889DC81D28643E3A73D90E068@sausexdag06.amd.com> Message-ID: Yes, I agree. We are working on expanding our automatic checks. Additionally, we are working on a style guide document. Given that you are the first major outside contributor, this involves a certain learning experience for us. - thomas On Jun 24, 2013, at 11:29 PM, "Venkatachalam, Vasanth" wrote: > Hi Thomas, > > We?re addressing your comments. It would be nice if checkstyle and/or the Graal formatter in Eclipse would have picked up on these errors, so that we could have caught them the first time around. > > Vasanth > > From: Thomas Wuerthinger [mailto:thomas.wuerthinger at oracle.com] > Sent: Monday, June 24, 2013 3:14 PM > To: Venkatachalam, Vasanth > Cc: sw.runtimes; donald.smith at oracle.com Smith; graal-dev at openjdk.java.net; Christian Thalinger > Subject: Re: final graal HSAIL support patch > > Vasanth, > > Thanks for the patch. I have a first round of coding style comments. We would like the code to adhere to the style guide used for all other Graal modules (although of course we might have already quite some violations in the code base?). For explaining some of those style guide lines, I'm using the HSAILAssembler.java file as an example [1]: > > - Line 36: Comment should end with ".". > - Line 37: Instance field should be declared private. > - Line 37: "= 0" should be removed given that 0 is the default value for variables of type "int". > - Line 37: The name of the variable must be written in camel case "maxdatatypesize" => "maxDataTypeSize". > - Line 38: Comment should start with an upper case letter. > - Line 56: Remove "// TODO Auto-generated method stub". If the method is not used, replace with throwing an error/exception (GraalInternalError.shouldNotReachHere). > - Line 60: Method name "at" seems too short/ambiguous. > - Line 72-76: Multi-line "//" comment should be replaced with javadoc "/** */" comment. > - Line 88: Remove unnecessary blank line. > - Line 91: Use camel case for method names "emit_mov" => "emitMov" (we have violated this rule for the PTX assembler, but are going to fix that; at least we want to use "_" only in rare instances). > - Line 97: Remove unnecessary blank line (please also fix for subsequent lines of the file). > - Line 135: No commented-out code - please remove line. > - Line 190: Use camel case for method names "emit_convert" => "emitConvert" (please also fix for subsequent method names of the file). > - Line 196: Either remove comment or put javadoc comment including additional information. > - Line 236: Comment on method should be javadoc comment. > - Line 247-248: Comment seems on the wrong place. If this is a comment on the parameter "controlRegString", then please put the comment in the javadoc. > > Looking over the other files, there are similar style guide line violations, so please make a short sweep over the patch with those items in mind. > > Additionally, we would like to see a short javadoc description for each newly added class. This seems important given that we will need to maintain this code moving forward. > > Thanks, thomas > > [1] http://cr.openjdk.java.net/~twisti/GRAAL-342/webrev/graal/com.oracle.graal.asm.hsail/src/com/oracle/graal/asm/hsail/HSAILAssembler.java.html > > On Jun 24, 2013, at 8:18 PM, Christian Thalinger wrote: > > > > On Jun 24, 2013, at 11:13 AM, Christian Thalinger wrote: > > > I've created a Graal tracking bug so it's easier for me to handle it (the bug is not visible outside of Oracle): > > GRAAL-342: add HSAIL backend > > Here is the new webrev: > > http://cr.openjdk.java.net/~twisti/GRAAL-342/webrev/ > > Two quick comments: > > 1) I understand that the way you're handling the assembler right now was much less work but I wonder if you ever want to go to support your binary format too. Then a full-fledged assembler as for the other platforms might be better. > > 2) The Labels. I remember talking to Gilles about this when I did the PTX work and I think there is a better way of doing this (although I can't recall). > > -- Chris > > > > -- Chris > > On Jun 19, 2013, at 3:27 PM, "Venkatachalam, Vasanth" wrote: > > > Hi Christian, > > Here?s the final version of our graal HSAIL support patch. This addresses all of Doug Simon?s comments. > > In particular, > > 1) Checkstyle errors have been fixed and all licenses in the Okra packages are attributed to Oracle. > 2) What was previously the com.amd.sumatra package has been removed and its source files (which don?t have anything Sumatra specific) have been moved into the com.oracle.graal.compiler.hsail package. > 3) Hotspot c++ source changes have been reverted and are no longer part of the webrev. > > Vasanth > > > From tom.deneau at amd.com Mon Jun 24 15:12:21 2013 From: tom.deneau at amd.com (Deneau, Tom) Date: Mon, 24 Jun 2013 22:12:21 +0000 Subject: [Sw.runtimes] final graal HSAIL support patch In-Reply-To: References: <5DD1503F815BD14889DC81D28643E3A73D909869@sausexdag06.amd.com> <6BCB9963-2904-43B6-8C78-4E8A144B2BA1@oracle.com> <4A3B7F7E-E03B-4B31-9A48-FF50B159FC7D@oracle.com> <9C584B81-E266-4D93-AA4F-98717CD703C4@oracle.com> <68BA4718-61A3-43F8-9777-ACAB2E969D59@oracle.com> Message-ID: Doug -- Where should the jar file be downloaded from? Is there some place in one of the openjdk directories that would work? -- Tom -----Original Message----- From: Doug Simon [mailto:doug.simon at oracle.com] Sent: Monday, June 24, 2013 4:33 PM To: Deneau, Tom Cc: Thomas Wuerthinger; graal-dev at openjdk.java.net; sw.runtimes; donald.smith at oracle.com Smith Subject: Re: [Sw.runtimes] final graal HSAIL support patch Hi Tom, Ok, based on the need to link with the native code and the fact that there is nothing particularly Graal specific in this code, I think the okra-.jar solution is the best one moving forward. The suffix on the jar should be sufficient to manage any version dependencies from the other HSAIL code and the Okra library. I'm guessing that this library interface will not change very often anyway. As you state, the issue of staying in sync with the native code will have to be resolved some other way anyway. One request I have is that the okra-.jar file also contain the Java sources so that debugging through this code should be straightforward. -Doug On Jun 24, 2013, at 11:08 PM, "Deneau, Tom" wrote: > Doug -- > > As you may have noticed, many of the methods in com.amd.okra are native so there is a corresponding native library with com_amd_okra_xxx names which is needed if you want to actually dispatch anything. This is an open source project of its own and will be used by other projects such as Aparapi. Since there is nothing graal-specific in the native library, it doesn't seem right to have a graal namespace on it. So leaving com.amd.okra as the package name would be our first choice. > > A second choice would be to have the com.oracle.graal.okra which you propose be a stub which could be built against but would use reflection to get to the real com.amd.okra which could be shipped as a jar with the okra native libraries. > > A third choice is going back to your earlier proposal of graal building against an okra.jar which would be downloaded from somewhere (would cr.openjdk.java.net do for this?) > > Our earlier concern was that the third choice would more easily get out of sync with the actual native libraries but as I think about it all three choices have this possibility of getting out of sync with the native libraries. > > -- Tom > > > -----Original Message----- > From: sw.runtimes-bounces at mpdtxmail.amd.com [mailto:sw.runtimes-bounces at mpdtxmail.amd.com] On Behalf Of Doug Simon > Sent: Monday, June 24, 2013 3:30 PM > To: Thomas Wuerthinger > Cc: graal-dev at openjdk.java.net; sw.runtimes; donald.smith at oracle.com Smith > Subject: Re: [Sw.runtimes] final graal HSAIL support patch > > Vasanth, > > Just one more request on top of Thomas' feedback. > > We'd like to keep all the Graal code in a com.oracle.graal package namespace. As such, could you please rename the com.amd.okra package to something like com.oracle.graal.amd.okra or simply com.oracle.graal.okra. > > Thanks. > > -Doug > > On Jun 24, 2013, at 10:13 PM, Thomas Wuerthinger wrote: > >> Vasanth, >> >> Thanks for the patch. I have a first round of coding style comments. We would like the code to adhere to the style guide used for all other Graal modules (although of course we might have already quite some violations in the code base...). For explaining some of those style guide lines, I'm using the HSAILAssembler.java file as an example [1]: >> >> - Line 36: Comment should end with ".". >> - Line 37: Instance field should be declared private. >> - Line 37: "= 0" should be removed given that 0 is the default value for variables of type "int". >> - Line 37: The name of the variable must be written in camel case "maxdatatypesize" => "maxDataTypeSize". >> - Line 38: Comment should start with an upper case letter. >> - Line 56: Remove "// TODO Auto-generated method stub". If the method is not used, replace with throwing an error/exception (GraalInternalError.shouldNotReachHere). >> - Line 60: Method name "at" seems too short/ambiguous. >> - Line 72-76: Multi-line "//" comment should be replaced with javadoc "/** */" comment. >> - Line 88: Remove unnecessary blank line. >> - Line 91: Use camel case for method names "emit_mov" => "emitMov" (we have violated this rule for the PTX assembler, but are going to fix that; at least we want to use "_" only in rare instances). >> - Line 97: Remove unnecessary blank line (please also fix for subsequent lines of the file). >> - Line 135: No commented-out code - please remove line. >> - Line 190: Use camel case for method names "emit_convert" => "emitConvert" (please also fix for subsequent method names of the file). >> - Line 196: Either remove comment or put javadoc comment including additional information. >> - Line 236: Comment on method should be javadoc comment. >> - Line 247-248: Comment seems on the wrong place. If this is a comment on the parameter "controlRegString", then please put the comment in the javadoc. >> >> Looking over the other files, there are similar style guide line violations, so please make a short sweep over the patch with those items in mind. >> >> Additionally, we would like to see a short javadoc description for each newly added class. This seems important given that we will need to maintain this code moving forward. >> >> Thanks, thomas >> >> [1] http://cr.openjdk.java.net/~twisti/GRAAL-342/webrev/graal/com.oracle.graal.asm.hsail/src/com/oracle/graal/asm/hsail/HSAILAssembler.java.html >> >> On Jun 24, 2013, at 8:18 PM, Christian Thalinger wrote: >> >>> >>> On Jun 24, 2013, at 11:13 AM, Christian Thalinger wrote: >>> >>>> I've created a Graal tracking bug so it's easier for me to handle it (the bug is not visible outside of Oracle): >>>> >>>> GRAAL-342: add HSAIL backend >>>> >>>> Here is the new webrev: >>>> >>>> http://cr.openjdk.java.net/~twisti/GRAAL-342/webrev/ >>> >>> Two quick comments: >>> >>> 1) I understand that the way you're handling the assembler right now was much less work but I wonder if you ever want to go to support your binary format too. Then a full-fledged assembler as for the other platforms might be better. >>> >>> 2) The Labels. I remember talking to Gilles about this when I did the PTX work and I think there is a better way of doing this (although I can't recall). >>> >>> -- Chris >>> >>>> >>>> -- Chris >>>> >>>> On Jun 19, 2013, at 3:27 PM, "Venkatachalam, Vasanth" wrote: >>>> >>>>> Hi Christian, >>>>> >>>>> Here's the final version of our graal HSAIL support patch. This addresses all of Doug Simon's comments. >>>>> >>>>> In particular, >>>>> >>>>> 1) Checkstyle errors have been fixed and all licenses in the Okra packages are attributed to Oracle. >>>>> 2) What was previously the com.amd.sumatra package has been removed and its source files (which don't have anything Sumatra specific) have been moved into the com.oracle.graal.compiler.hsail package. >>>>> 3) Hotspot c++ source changes have been reverted and are no longer part of the webrev. >>>>> >>>>> Vasanth >>>>> >>>> >>> >> > > > > From doug.simon at oracle.com Mon Jun 24 22:58:26 2013 From: doug.simon at oracle.com (Doug Simon) Date: Tue, 25 Jun 2013 07:58:26 +0200 Subject: [Sw.runtimes] final graal HSAIL support patch In-Reply-To: References: <5DD1503F815BD14889DC81D28643E3A73D909869@sausexdag06.amd.com> <6BCB9963-2904-43B6-8C78-4E8A144B2BA1@oracle.com> <4A3B7F7E-E03B-4B31-9A48-FF50B159FC7D@oracle.com> <9C584B81-E266-4D93-AA4F-98717CD703C4@oracle.com> <68BA4718-61A3-43F8-9777-ACAB2E969D59@oracle.com> Message-ID: On Jun 25, 2013, at 12:12 AM, "Deneau, Tom" wrote: > Doug -- > > Where should the jar file be downloaded from? Is there some place in one of the openjdk directories that would work? Somewhere under http://cr.openjdk.java.net/~tdeneau/ would probably be best since you have write access to it. -Doug > -----Original Message----- > From: Doug Simon [mailto:doug.simon at oracle.com] > Sent: Monday, June 24, 2013 4:33 PM > To: Deneau, Tom > Cc: Thomas Wuerthinger; graal-dev at openjdk.java.net; sw.runtimes; donald.smith at oracle.com Smith > Subject: Re: [Sw.runtimes] final graal HSAIL support patch > > Hi Tom, > > Ok, based on the need to link with the native code and the fact that there is nothing particularly Graal specific in this code, I think the okra-.jar solution is the best one moving forward. The suffix on the jar should be sufficient to manage any version dependencies from the other HSAIL code and the Okra library. I'm guessing that this library interface will not change very often anyway. As you state, the issue of staying in sync with the native code will have to be resolved some other way anyway. > > One request I have is that the okra-.jar file also contain the Java sources so that debugging through this code should be straightforward. > > -Doug > > On Jun 24, 2013, at 11:08 PM, "Deneau, Tom" wrote: > >> Doug -- >> >> As you may have noticed, many of the methods in com.amd.okra are native so there is a corresponding native library with com_amd_okra_xxx names which is needed if you want to actually dispatch anything. This is an open source project of its own and will be used by other projects such as Aparapi. Since there is nothing graal-specific in the native library, it doesn't seem right to have a graal namespace on it. So leaving com.amd.okra as the package name would be our first choice. >> >> A second choice would be to have the com.oracle.graal.okra which you propose be a stub which could be built against but would use reflection to get to the real com.amd.okra which could be shipped as a jar with the okra native libraries. >> >> A third choice is going back to your earlier proposal of graal building against an okra.jar which would be downloaded from somewhere (would cr.openjdk.java.net do for this?) >> >> Our earlier concern was that the third choice would more easily get out of sync with the actual native libraries but as I think about it all three choices have this possibility of getting out of sync with the native libraries. >> >> -- Tom >> >> >> -----Original Message----- >> From: sw.runtimes-bounces at mpdtxmail.amd.com [mailto:sw.runtimes-bounces at mpdtxmail.amd.com] On Behalf Of Doug Simon >> Sent: Monday, June 24, 2013 3:30 PM >> To: Thomas Wuerthinger >> Cc: graal-dev at openjdk.java.net; sw.runtimes; donald.smith at oracle.com Smith >> Subject: Re: [Sw.runtimes] final graal HSAIL support patch >> >> Vasanth, >> >> Just one more request on top of Thomas' feedback. >> >> We'd like to keep all the Graal code in a com.oracle.graal package namespace. As such, could you please rename the com.amd.okra package to something like com.oracle.graal.amd.okra or simply com.oracle.graal.okra. >> >> Thanks. >> >> -Doug >> >> On Jun 24, 2013, at 10:13 PM, Thomas Wuerthinger wrote: >> >>> Vasanth, >>> >>> Thanks for the patch. I have a first round of coding style comments. We would like the code to adhere to the style guide used for all other Graal modules (although of course we might have already quite some violations in the code base...). For explaining some of those style guide lines, I'm using the HSAILAssembler.java file as an example [1]: >>> >>> - Line 36: Comment should end with ".". >>> - Line 37: Instance field should be declared private. >>> - Line 37: "= 0" should be removed given that 0 is the default value for variables of type "int". >>> - Line 37: The name of the variable must be written in camel case "maxdatatypesize" => "maxDataTypeSize". >>> - Line 38: Comment should start with an upper case letter. >>> - Line 56: Remove "// TODO Auto-generated method stub". If the method is not used, replace with throwing an error/exception (GraalInternalError.shouldNotReachHere). >>> - Line 60: Method name "at" seems too short/ambiguous. >>> - Line 72-76: Multi-line "//" comment should be replaced with javadoc "/** */" comment. >>> - Line 88: Remove unnecessary blank line. >>> - Line 91: Use camel case for method names "emit_mov" => "emitMov" (we have violated this rule for the PTX assembler, but are going to fix that; at least we want to use "_" only in rare instances). >>> - Line 97: Remove unnecessary blank line (please also fix for subsequent lines of the file). >>> - Line 135: No commented-out code - please remove line. >>> - Line 190: Use camel case for method names "emit_convert" => "emitConvert" (please also fix for subsequent method names of the file). >>> - Line 196: Either remove comment or put javadoc comment including additional information. >>> - Line 236: Comment on method should be javadoc comment. >>> - Line 247-248: Comment seems on the wrong place. If this is a comment on the parameter "controlRegString", then please put the comment in the javadoc. >>> >>> Looking over the other files, there are similar style guide line violations, so please make a short sweep over the patch with those items in mind. >>> >>> Additionally, we would like to see a short javadoc description for each newly added class. This seems important given that we will need to maintain this code moving forward. >>> >>> Thanks, thomas >>> >>> [1] http://cr.openjdk.java.net/~twisti/GRAAL-342/webrev/graal/com.oracle.graal.asm.hsail/src/com/oracle/graal/asm/hsail/HSAILAssembler.java.html >>> >>> On Jun 24, 2013, at 8:18 PM, Christian Thalinger wrote: >>> >>>> >>>> On Jun 24, 2013, at 11:13 AM, Christian Thalinger wrote: >>>> >>>>> I've created a Graal tracking bug so it's easier for me to handle it (the bug is not visible outside of Oracle): >>>>> >>>>> GRAAL-342: add HSAIL backend >>>>> >>>>> Here is the new webrev: >>>>> >>>>> http://cr.openjdk.java.net/~twisti/GRAAL-342/webrev/ >>>> >>>> Two quick comments: >>>> >>>> 1) I understand that the way you're handling the assembler right now was much less work but I wonder if you ever want to go to support your binary format too. Then a full-fledged assembler as for the other platforms might be better. >>>> >>>> 2) The Labels. I remember talking to Gilles about this when I did the PTX work and I think there is a better way of doing this (although I can't recall). >>>> >>>> -- Chris >>>> >>>>> >>>>> -- Chris >>>>> >>>>> On Jun 19, 2013, at 3:27 PM, "Venkatachalam, Vasanth" wrote: >>>>> >>>>>> Hi Christian, >>>>>> >>>>>> Here's the final version of our graal HSAIL support patch. This addresses all of Doug Simon's comments. >>>>>> >>>>>> In particular, >>>>>> >>>>>> 1) Checkstyle errors have been fixed and all licenses in the Okra packages are attributed to Oracle. >>>>>> 2) What was previously the com.amd.sumatra package has been removed and its source files (which don't have anything Sumatra specific) have been moved into the com.oracle.graal.compiler.hsail package. >>>>>> 3) Hotspot c++ source changes have been reverted and are no longer part of the webrev. >>>>>> >>>>>> Vasanth >>>>>> >>>>> >>>> >>> >> >> >> >> > > > From doug.simon at oracle.com Mon Jun 24 23:43:10 2013 From: doug.simon at oracle.com (Doug Simon) Date: Tue, 25 Jun 2013 08:43:10 +0200 Subject: stackslot question In-Reply-To: References: Message-ID: <8FB79FA2-2A19-4DFA-9DA0-591A60B0EC28@oracle.com> On Jun 24, 2013, at 9:07 PM, "Deneau, Tom" wrote: > In HSAIL there is not stack register as such but we can declare an array that is private to each workitem > and reference at positive offsets into it. > > I see there is a bug in our current HSAIL implementation of stack slots which needs to be fixed > and we are exploring different ways to fix it. > > My question is, assuming a load from a certain stackslot always reads back what was stored to that stackslot, > (when the load and store both using the same data width) > is there any requirement on the relative positions of different stackslots in memory, > for example does it matter whether stackslot -8 is at a higher or lower memory address compared to stackslot -16? The only time I think stack slot ordering matters is when arguments are passed via the stack. The ordering in that case is defined by the underlying CallingConvention in use. Otherwise, the relative position of stack slots in memory should not matter. -Doug From doug.simon at oracle.com Tue Jun 25 00:20:48 2013 From: doug.simon at oracle.com (doug.simon at oracle.com) Date: Tue, 25 Jun 2013 07:20:48 +0000 Subject: hg: graal/graal: 55 new changesets Message-ID: <20130625072527.588D5484D4@hg.openjdk.java.net> Changeset: edf612527d74 Author: Lukas Stadler Date: 2013-06-23 14:11 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/edf612527d74 small fix to code structured in IntegerStamp ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/type/IntegerStamp.java Changeset: 195eb23d9909 Author: Lukas Stadler Date: 2013-06-23 14:12 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/195eb23d9909 add memory verification to the gate ! mx/commands.py Changeset: 0d40e1cf70db Author: Thomas Wuerthinger Date: 2013-06-21 17:52 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/0d40e1cf70db Temporarily remove SPARC version of calling HotSpotInstalledCode targets. ! src/cpu/sparc/vm/sharedRuntime_sparc.cpp Changeset: 55827d611da7 Author: Thomas Wuerthinger Date: 2013-06-21 17:52 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/55827d611da7 Merge. - graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/WriteBarrierAdditionTest.java - graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/WriteBarrierVerificationTest.java - graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/GenericArrayRangeWriteBarrier.java - graal/com.oracle.truffle.api.codegen/src/com/oracle/truffle/api/codegen/ExecuteChildren.java - graal/com.oracle.truffle.api.codegen/src/com/oracle/truffle/api/codegen/ExtensionAnnotation.java - graal/com.oracle.truffle.codegen.processor/src/com/oracle/truffle/codegen/processor/ext/ExtensionCodeElementFactory.java - graal/com.oracle.truffle.codegen.processor/src/com/oracle/truffle/codegen/processor/ext/ExtensionContextImpl.java - graal/com.oracle.truffle.codegen.processor/src/com/oracle/truffle/codegen/processor/ext/ExtensionParser.java Changeset: 3489047ffea2 Author: Thomas Wuerthinger Date: 2013-06-21 18:26 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/3489047ffea2 Restructure the handling of HotSpotInstalledCode and their link to nmethods. ! 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/HotSpotNmethod.java ! src/cpu/x86/vm/c2_globals_x86.hpp ! src/cpu/x86/vm/sharedRuntime_x86_64.cpp ! src/cpu/x86/vm/templateInterpreter_x86_64.cpp ! src/share/vm/classfile/vmSymbols.hpp ! src/share/vm/code/nmethod.cpp ! src/share/vm/graal/graalCompilerToVM.cpp ! src/share/vm/graal/graalJavaAccess.cpp ! src/share/vm/graal/graalRuntime.cpp ! src/share/vm/graal/graalVMToCompiler.cpp ! src/share/vm/graal/graalVMToCompiler.hpp ! src/share/vm/prims/nativeLookup.cpp Changeset: cd68d6902328 Author: Thomas Wuerthinger Date: 2013-06-21 22:04 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/cd68d6902328 Fix invalidateInstalledCode and delete isInstalledCodeValid. ! 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/HotSpotNmethod.java ! src/share/vm/graal/graalCompilerToVM.cpp Changeset: 7943479d36f3 Author: Thomas Wuerthinger Date: 2013-06-21 22:09 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/7943479d36f3 Fix for invalidateInstalledCode. ! src/share/vm/graal/graalCompilerToVM.cpp Changeset: dd3333e4f182 Author: Thomas Wuerthinger Date: 2013-06-23 15:27 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/dd3333e4f182 Improve HotSpotNMethodTest. ! graal/com.oracle.graal.hotspot.test/src/com/oracle/graal/hotspot/test/HotSpotNmethodTest.java Changeset: 40b8c383bc31 Author: Thomas Wuerthinger Date: 2013-06-23 15:49 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/40b8c383bc31 Throw InvalidInstalledCodeException directly in the stubs. ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotNmethod.java ! src/cpu/sparc/vm/stubGenerator_sparc.cpp ! src/cpu/x86/vm/sharedRuntime_x86_64.cpp ! src/cpu/x86/vm/stubGenerator_x86_32.cpp ! src/cpu/x86/vm/stubGenerator_x86_64.cpp ! src/cpu/x86/vm/templateInterpreter_x86_64.cpp ! src/share/vm/interpreter/interpreterRuntime.cpp ! src/share/vm/interpreter/interpreterRuntime.hpp ! src/share/vm/runtime/sharedRuntime.cpp ! src/share/vm/runtime/sharedRuntime.hpp ! src/share/vm/runtime/stubRoutines.cpp ! src/share/vm/runtime/stubRoutines.hpp Changeset: aa685bff0926 Author: Thomas Wuerthinger Date: 2013-06-23 15:49 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/aa685bff0926 Merge. - graal/com.oracle.graal.asm.sparc/src/com/oracle/graal/asm/sparc/AbstractSPARCAssembler.java - graal/com.oracle.graal.compiler.sparc.test/src/com/oracle/graal/compiler/sparc/test/ArraySPARCTest.java - graal/com.oracle.graal.compiler.sparc.test/src/com/oracle/graal/compiler/sparc/test/BasicSPARCTest.java - graal/com.oracle.graal.compiler.sparc.test/src/com/oracle/graal/compiler/sparc/test/ControlSPARCTest.java - graal/com.oracle.graal.compiler.sparc.test/src/com/oracle/graal/compiler/sparc/test/FloatSPARCTest.java - graal/com.oracle.graal.compiler.sparc.test/src/com/oracle/graal/compiler/sparc/test/IntegerSPARCTest.java - graal/com.oracle.graal.compiler.sparc.test/src/com/oracle/graal/compiler/sparc/test/LogicSPARCTest.java - graal/com.oracle.graal.compiler.sparc.test/src/com/oracle/graal/compiler/sparc/test/SPARCTestBase.java - graal/com.oracle.graal.compiler.sparc/src/com/oracle/graal/compiler/sparc/SPARCBackend.java Changeset: 29e9a5d18c70 Author: Thomas Wuerthinger Date: 2013-06-23 20:50 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/29e9a5d18c70 Clean up. ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/WriteBarrierSnippets.java ! graal/com.oracle.graal.lir.sparc/src/com/oracle/graal/lir/sparc/SPARCAddressValue.java ! graal/com.oracle.truffle.api/src/com/oracle/truffle/api/nodes/GraphPrintVisitor.java ! graal/com.oracle.truffle.api/src/com/oracle/truffle/api/nodes/Node.java Changeset: 3e34b0318de6 Author: Thomas Wuerthinger Date: 2013-06-23 21:04 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/3e34b0318de6 Experimental decompiler that outputs Java source code from Graal IR for debug purposes. Contributed-by: Matthias Grimmer (mgrimmer) + graal/com.oracle.graal.java.decompiler.test/src/com/oracle/graal/java/decompiler/test/BootstrapTest.java + graal/com.oracle.graal.java.decompiler.test/src/com/oracle/graal/java/decompiler/test/Test.java + graal/com.oracle.graal.java.decompiler.test/src/com/oracle/graal/java/decompiler/test/TestUtil.java + graal/com.oracle.graal.java.decompiler.test/src/com/oracle/graal/java/decompiler/test/example/Example.java + graal/com.oracle.graal.java.decompiler/src/com/oracle/graal/java/decompiler/Decompiler.java + graal/com.oracle.graal.java.decompiler/src/com/oracle/graal/java/decompiler/DecompilerIfSimplify.java + graal/com.oracle.graal.java.decompiler/src/com/oracle/graal/java/decompiler/DecompilerLoopSimplify.java + graal/com.oracle.graal.java.decompiler/src/com/oracle/graal/java/decompiler/DecompilerPhiRemover.java + graal/com.oracle.graal.java.decompiler/src/com/oracle/graal/java/decompiler/block/DecompilerBasicBlock.java + graal/com.oracle.graal.java.decompiler/src/com/oracle/graal/java/decompiler/block/DecompilerBlock.java + graal/com.oracle.graal.java.decompiler/src/com/oracle/graal/java/decompiler/block/DecompilerIfBlock.java + graal/com.oracle.graal.java.decompiler/src/com/oracle/graal/java/decompiler/block/DecompilerLoopBlock.java + graal/com.oracle.graal.java.decompiler/src/com/oracle/graal/java/decompiler/lines/DecompilerAssignmentLine.java + graal/com.oracle.graal.java.decompiler/src/com/oracle/graal/java/decompiler/lines/DecompilerControlSplitLine.java + graal/com.oracle.graal.java.decompiler/src/com/oracle/graal/java/decompiler/lines/DecompilerIfLine.java + graal/com.oracle.graal.java.decompiler/src/com/oracle/graal/java/decompiler/lines/DecompilerPhiLine.java + graal/com.oracle.graal.java.decompiler/src/com/oracle/graal/java/decompiler/lines/DecompilerPhiResolveLine.java + graal/com.oracle.graal.java.decompiler/src/com/oracle/graal/java/decompiler/lines/DecompilerProxyLine.java + graal/com.oracle.graal.java.decompiler/src/com/oracle/graal/java/decompiler/lines/DecompilerReturnLine.java + graal/com.oracle.graal.java.decompiler/src/com/oracle/graal/java/decompiler/lines/DecompilerSyntaxLine.java ! graal/com.oracle.graal.phases/src/com/oracle/graal/phases/GraalOptions.java ! graal/com.oracle.graal.printer/src/com/oracle/graal/printer/DebugEnvironment.java ! mx/projects Changeset: 3e6f538829ce Author: Thomas Wuerthinger Date: 2013-06-23 21:36 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/3e6f538829ce Add decompiler debug handler. + graal/com.oracle.graal.printer/src/com/oracle/graal/printer/DecompilerDebugDumpHandler.java Changeset: 0097fb11c16f Author: Thomas Wuerthinger Date: 2013-06-23 21:44 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/0097fb11c16f Add basic version of Graal's Truffle runtime. + graal/com.oracle.graal.truffle.printer/src/com/oracle/graal/truffle/printer/InlinePrinterProcessor.java + graal/com.oracle.graal.truffle.printer/src/com/oracle/graal/truffle/printer/method/CallStackElement.java + graal/com.oracle.graal.truffle.printer/src/com/oracle/graal/truffle/printer/method/MethodHolder.java + graal/com.oracle.graal.truffle.printer/src/com/oracle/graal/truffle/printer/method/TruffleMethodNode.java + graal/com.oracle.graal.truffle.test/src/com/oracle/graal/truffle/test/AssumptionPartialEvaluationTest.java + graal/com.oracle.graal.truffle.test/src/com/oracle/graal/truffle/test/ExactMathTest.java + graal/com.oracle.graal.truffle.test/src/com/oracle/graal/truffle/test/PartialEvaluationTest.java + graal/com.oracle.graal.truffle.test/src/com/oracle/graal/truffle/test/SimplePartialEvaluationTest.java + graal/com.oracle.graal.truffle.test/src/com/oracle/graal/truffle/test/TruffleRuntimeTest.java + graal/com.oracle.graal.truffle.test/src/com/oracle/graal/truffle/test/nodes/AbstractTestNode.java + graal/com.oracle.graal.truffle.test/src/com/oracle/graal/truffle/test/nodes/AddTestNode.java + graal/com.oracle.graal.truffle.test/src/com/oracle/graal/truffle/test/nodes/BlockTestNode.java + graal/com.oracle.graal.truffle.test/src/com/oracle/graal/truffle/test/nodes/ConstantTestNode.java + graal/com.oracle.graal.truffle.test/src/com/oracle/graal/truffle/test/nodes/ConstantWithAssumptionTestNode.java + graal/com.oracle.graal.truffle.test/src/com/oracle/graal/truffle/test/nodes/LoadLocalTestNode.java + graal/com.oracle.graal.truffle.test/src/com/oracle/graal/truffle/test/nodes/LoopTestNode.java + graal/com.oracle.graal.truffle.test/src/com/oracle/graal/truffle/test/nodes/RootTestNode.java + graal/com.oracle.graal.truffle.test/src/com/oracle/graal/truffle/test/nodes/StoreLocalTestNode.java + graal/com.oracle.graal.truffle.test/src/com/oracle/graal/truffle/test/nodes/TestNodeFactory.java + graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/FrameWithoutBoxing.java + graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/GraalTruffleRuntime.java + graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/OptimizedAssumption.java + graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/OptimizedCallTarget.java + graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/PackedFrameImpl.java + graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/PartialEvaluator.java + graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/PartialEvaluatorCanonicalizer.java + graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/TruffleCompiler.java + graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/TruffleCompilerImpl.java + graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/TruffleCompilerOptions.java + graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/nodes/AssumptionNode.java + graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/nodes/AssumptionValidAssumption.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/CompilationConstantNode.java + graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/nodes/FrameAccessNode.java + graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/nodes/FrameGetNode.java + graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/nodes/FrameSetNode.java + graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/nodes/IntegerAddExactNode.java + graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/nodes/IntegerAddExactSplitNode.java + graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/nodes/IntegerExactArithmeticNode.java + graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/nodes/IntegerExactArithmeticSplitNode.java + graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/nodes/IntegerMulExactNode.java + graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/nodes/IntegerMulExactSplitNode.java + graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/nodes/IntegerSubExactNode.java + graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/nodes/IntegerSubExactSplitNode.java + graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/nodes/MaterializeFrameNode.java + graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/nodes/NeverInlineMacroNode.java + graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/nodes/NeverPartOfCompilationNode.java + graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/nodes/NewFrameNode.java + graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/nodes/UnsafeCastMacroNode.java + graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/phases/InlineTrivialGettersPhase.java + graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/phases/ReplaceIntrinsicsPhase.java + graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/phases/VerifyFrameDoesNotEscapePhase.java + graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/phases/VerifyNoIntrinsicsLeftPhase.java + graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/substitutions/CompilerAssertsSubstitutions.java + graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/substitutions/CompilerDirectivesSubstitutions.java + graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/substitutions/DefaultCallTargetSubstitutions.java + graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/substitutions/ExactMathSubstitutions.java + graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/substitutions/FrameWithoutBoxingSubstitutions.java + graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/substitutions/OptimizedAssumptionSubstitutions.java + graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/substitutions/OptimizedCallTargetSubstitutions.java + graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/substitutions/SlowPathExceptionSubstitutions.java + graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/substitutions/UnexpectedResultExceptionSubstitutions.java + graal/com.oracle.truffle.api/src/com/oracle/truffle/api/nodes/FrameFactory.java + graal/com.oracle.truffle.api/src/com/oracle/truffle/api/nodes/InlinableCallSite.java ! mx/projects Changeset: 181b729e5b77 Author: Thomas Wuerthinger Date: 2013-06-23 21:44 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/181b729e5b77 Merge. Changeset: b42db1748ff2 Author: Thomas Wuerthinger Date: 2013-06-23 23:42 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/b42db1748ff2 Ignore two test classes that show failures when used with code coverage tools. ! graal/com.oracle.graal.truffle.test/src/com/oracle/graal/truffle/test/AssumptionPartialEvaluationTest.java ! graal/com.oracle.graal.truffle.test/src/com/oracle/graal/truffle/test/SimplePartialEvaluationTest.java Changeset: e5dae076b467 Author: Andreas Woess Date: 2013-06-23 14:42 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/e5dae076b467 PartialEvaluator: report node count difference (+/-) instead of new node count ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/PartialEvaluator.java Changeset: 77016aeda39a Author: Andreas Woess Date: 2013-06-23 16:35 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/77016aeda39a TraceTruffleCompilation: output truffle and graal node counts ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/OptimizedCallTarget.java ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/TruffleCompilerImpl.java Changeset: 175a4900c230 Author: Andreas Woess Date: 2013-06-24 02:19 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/175a4900c230 OptimizedCallTarget: always disable compilation on exception; cleanup ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/OptimizedCallTarget.java Changeset: dcbdf71c4507 Author: Lukas Stadler Date: 2013-06-24 08:01 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/dcbdf71c4507 remove scheduledNext from ScheduledNode ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/FixedWithNextNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/ScheduledNode.java ! graal/com.oracle.graal.phases/src/com/oracle/graal/phases/schedule/SchedulePhase.java ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/nodes/IntegerExactArithmeticSplitNode.java Changeset: e98e021d1e7e Author: Christos Kotselidis Date: 2013-06-21 11:08 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/e98e021d1e7e Forbid direct eden allocation when G1 is enabled ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/stubs/NewInstanceStub.java Changeset: 34444b095a51 Author: Christos Kotselidis Date: 2013-06-21 11:34 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/34444b095a51 Read nodes with attached barrier (G1) can not float ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/extended/FloatableAccessNode.java ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/FloatingReadPhase.java Changeset: a46c3180faed Author: Christos Kotselidis Date: 2013-06-21 11:41 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/a46c3180faed Merge - graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/WriteBarrierAdditionTest.java - graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/WriteBarrierVerificationTest.java - graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/GenericArrayRangeWriteBarrier.java Changeset: 6f331db530f6 Author: Christos Kotselidis Date: 2013-06-21 11:59 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/6f331db530f6 Add G1 Barrier Snippets ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/WriteBarrierSnippets.java Changeset: 0fe1b0886dbf Author: Christos Kotselidis Date: 2013-06-21 15:03 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/0fe1b0886dbf Augment WriteBarrierAddition phase to insert G1 Barriers ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/phases/WriteBarrierAdditionPhase.java Changeset: d18fbe96ba76 Author: Christos Kotselidis Date: 2013-06-21 15:11 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/d18fbe96ba76 Attach G1 Pre barrier to load field of referent field ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotRuntime.java Changeset: 3d4c9765382d Author: Christos Kotselidis Date: 2013-06-21 15:46 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/3d4c9765382d Add logging helper function for write barrier debugging ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/WriteBarrierSnippets.java Changeset: 75fb91c2ba1f Author: Christos Kotselidis Date: 2013-06-21 15:46 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/75fb91c2ba1f Augment Write Barrier Addition Tests for G1 barriers ! graal/com.oracle.graal.hotspot.test/src/com/oracle/graal/hotspot/test/WriteBarrierAdditionTest.java Changeset: cbeafa74236c Author: Christos Kotselidis Date: 2013-06-21 16:26 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/cbeafa74236c Add G1 Barriers during lowering ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotRuntime.java Changeset: f9f949cc2333 Author: Christos Kotselidis Date: 2013-06-21 16:42 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/f9f949cc2333 Probability inversion in unsafe load lowering ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotRuntime.java Changeset: 4d84627b891b Author: Christos Kotselidis Date: 2013-06-21 16:49 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/4d84627b891b Merge - graal/com.oracle.truffle.api.codegen/src/com/oracle/truffle/api/codegen/ExecuteChildren.java - graal/com.oracle.truffle.api.codegen/src/com/oracle/truffle/api/codegen/ExtensionAnnotation.java - graal/com.oracle.truffle.codegen.processor/src/com/oracle/truffle/codegen/processor/ext/ExtensionCodeElementFactory.java - graal/com.oracle.truffle.codegen.processor/src/com/oracle/truffle/codegen/processor/ext/ExtensionContextImpl.java - graal/com.oracle.truffle.codegen.processor/src/com/oracle/truffle/codegen/processor/ext/ExtensionParser.java Changeset: 0ef79b98d842 Author: Christos Kotselidis Date: 2013-06-21 16:52 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/0ef79b98d842 Fix checkstyle errors ! graal/com.oracle.graal.hotspot.test/src/com/oracle/graal/hotspot/test/WriteBarrierAdditionTest.java Changeset: 2393c37d1997 Author: Christos Kotselidis Date: 2013-06-21 23:12 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/2393c37d1997 Merge - graal/com.oracle.graal.asm.sparc/src/com/oracle/graal/asm/sparc/AbstractSPARCAssembler.java - graal/com.oracle.graal.compiler.sparc.test/src/com/oracle/graal/compiler/sparc/test/ArraySPARCTest.java - graal/com.oracle.graal.compiler.sparc.test/src/com/oracle/graal/compiler/sparc/test/BasicSPARCTest.java - graal/com.oracle.graal.compiler.sparc.test/src/com/oracle/graal/compiler/sparc/test/ControlSPARCTest.java - graal/com.oracle.graal.compiler.sparc.test/src/com/oracle/graal/compiler/sparc/test/FloatSPARCTest.java - graal/com.oracle.graal.compiler.sparc.test/src/com/oracle/graal/compiler/sparc/test/IntegerSPARCTest.java - graal/com.oracle.graal.compiler.sparc.test/src/com/oracle/graal/compiler/sparc/test/LogicSPARCTest.java - graal/com.oracle.graal.compiler.sparc.test/src/com/oracle/graal/compiler/sparc/test/SPARCTestBase.java - graal/com.oracle.graal.compiler.sparc/src/com/oracle/graal/compiler/sparc/SPARCBackend.java Changeset: 0eeb9f8dab9b Author: Christos Kotselidis Date: 2013-06-24 10:22 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/0eeb9f8dab9b Ignore testBoxedBooleanAOT test ! graal/com.oracle.graal.hotspot.test/src/com/oracle/graal/hotspot/test/AheadOfTimeCompilationTest.java Changeset: 5db21405c6a4 Author: Christos Kotselidis Date: 2013-06-24 10:25 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/5db21405c6a4 Merge ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/WriteBarrierSnippets.java Changeset: 7344fa3e8833 Author: Christian Haeubl Date: 2013-06-24 11:43 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/7344fa3e8833 Fixed an interpreter issue concerning a trashed register. ! src/cpu/x86/vm/templateInterpreter_x86_64.cpp Changeset: 329c22feda1f Author: Christian Haeubl Date: 2013-06-24 11:56 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/329c22feda1f Merge Changeset: 3e9820de1c1c Author: Roland Schatz Date: 2013-06-24 13:17 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/3e9820de1c1c New strategy for selecting the default compiler configuration. ! graal/com.oracle.graal.phases/src/com/oracle/graal/phases/tiers/Suites.java Changeset: fcc5fb4e2b9e Author: Roland Schatz Date: 2013-06-24 13:40 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/fcc5fb4e2b9e New strategy for selecting the default runtime. + graal/com.oracle.graal.hotspot.amd64/src/com/oracle/graal/hotspot/amd64/AMD64HotSpotGraalRuntimeFactory.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/HotSpotGraalRuntime.java ! mx/projects Changeset: f40010b67b6e Author: Andreas Woess Date: 2013-06-24 12:57 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/f40010b67b6e fix windows build directory ! make/windows/makefiles/projectcreator.make ! src/share/tools/ProjectCreator/BuildConfig.java Changeset: 9d995ba8b82c Author: Andreas Woess Date: 2013-06-24 16:40 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/9d995ba8b82c Merge Changeset: 42017075d2b0 Author: Andreas Woess Date: 2013-06-24 16:40 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/42017075d2b0 Increase MaximumDesiredSize ! graal/com.oracle.graal.phases/src/com/oracle/graal/phases/GraalOptions.java Changeset: 00b70a864d3b Author: Doug Simon Date: 2013-06-24 22:56 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/00b70a864d3b updated Checkstyle rules to prohibit underscores in method names and fixed current violations ! graal/com.oracle.graal.asm.amd64/src/com/oracle/graal/asm/amd64/AMD64Assembler.java ! graal/com.oracle.graal.asm.amd64/src/com/oracle/graal/asm/amd64/AMD64MacroAssembler.java ! graal/com.oracle.graal.asm.ptx/src/com/oracle/graal/asm/ptx/PTXAssembler.java ! graal/com.oracle.graal.graph/.checkstyle_checks.xml ! graal/com.oracle.graal.hotspot.test/src/com/oracle/graal/hotspot/test/HotSpotMethodSubstitutionTest.java ! graal/com.oracle.graal.jtt/src/com/oracle/graal/jtt/bytecode/BC_multianewarray04.java ! graal/com.oracle.graal.lir.amd64/src/com/oracle/graal/lir/amd64/AMD64Arithmetic.java ! graal/com.oracle.graal.replacements.test/src/com/oracle/graal/replacements/test/CheckCastTest.java ! graal/com.oracle.graal.replacements.test/src/com/oracle/graal/replacements/test/InstanceOfTest.java ! graal/com.oracle.graal.replacements.test/src/com/oracle/graal/replacements/test/MonitorTest.java ! graal/com.oracle.graal.replacements.test/src/com/oracle/graal/replacements/test/PointerTest.java ! graal/com.oracle.graal.replacements.test/src/com/oracle/graal/replacements/test/WordTest.java ! graal/com.oracle.truffle.codegen.processor/src/com/oracle/truffle/codegen/processor/ast/CodeTreeBuilder.java ! graal/com.oracle.truffle.codegen.processor/src/com/oracle/truffle/codegen/processor/node/NodeCodeGenerator.java Changeset: 0c144cdc1acb Author: Christos Kotselidis Date: 2013-06-24 12:05 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/0c144cdc1acb Remove old Write Barrier node - graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/nodes/WriteBarrier.java Changeset: ba607afddc8b Author: Christos Kotselidis Date: 2013-06-24 12:06 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/ba607afddc8b Make Write Barrier abstract class ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/WriteBarrier.java Changeset: a1b3863e3fc5 Author: Christos Kotselidis Date: 2013-06-24 13:44 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/a1b3863e3fc5 Move barrier check inside addReadNodeBarriers method, better assertions ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/phases/WriteBarrierAdditionPhase.java Changeset: c2c9afee00b5 Author: Christos Kotselidis Date: 2013-06-24 14:48 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/c2c9afee00b5 Replace G1 stub call nodes with intrinsics ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotRuntime.java - graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/nodes/G1PostWriteBarrierStubCall.java - graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/nodes/G1PreWriteBarrierStubCall.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/WriteBarrierSnippets.java Changeset: 0e849dd16591 Author: Christos Kotselidis Date: 2013-06-24 14:49 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/0e849dd16591 Fix spelling error ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/phases/WriteBarrierAdditionPhase.java Changeset: 3891371b2a3b Author: Christos Kotselidis Date: 2013-06-24 14:52 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/3891371b2a3b Method renaming ! 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 Changeset: 590f8f159309 Author: Christos Kotselidis Date: 2013-06-24 14:57 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/590f8f159309 Static imports in write barrier snippets ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/WriteBarrierSnippets.java Changeset: 97aa9042965f Author: Christos Kotselidis Date: 2013-06-24 15:26 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/97aa9042965f Merge Changeset: 499f21a3bb81 Author: Christos Kotselidis Date: 2013-06-24 16:55 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/499f21a3bb81 Replace readObject with unsafe load for G1 Barriers + Compressed Oops correctness ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/WriteBarrierSnippets.java Changeset: 45788e918443 Author: Christos Kotselidis Date: 2013-06-24 23:10 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/45788e918443 Code cleanup ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/stubs/NewInstanceStub.java Changeset: ea43748a69cb Author: Christos Kotselidis Date: 2013-06-24 23:10 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/ea43748a69cb Merge Changeset: a11e3d681eb1 Author: Christos Kotselidis Date: 2013-06-25 00:11 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/a11e3d681eb1 Merge From tom.deneau at amd.com Tue Jun 25 08:00:59 2013 From: tom.deneau at amd.com (Deneau, Tom) Date: Tue, 25 Jun 2013 15:00:59 +0000 Subject: stackslot question In-Reply-To: <8FB79FA2-2A19-4DFA-9DA0-591A60B0EC28@oracle.com> References: <8FB79FA2-2A19-4DFA-9DA0-591A60B0EC28@oracle.com> Message-ID: OK, thanks. In HSAIL (when we finally define our own callingConvention and stop using the x64 convention) arguments cannot be passed on the stack anyway. -- Tom -----Original Message----- From: Doug Simon [mailto:doug.simon at oracle.com] Sent: Tuesday, June 25, 2013 1:43 AM To: Deneau, Tom Cc: graal-dev at openjdk.java.net Subject: Re: stackslot question On Jun 24, 2013, at 9:07 PM, "Deneau, Tom" wrote: > In HSAIL there is not stack register as such but we can declare an array that is private to each workitem > and reference at positive offsets into it. > > I see there is a bug in our current HSAIL implementation of stack slots which needs to be fixed > and we are exploring different ways to fix it. > > My question is, assuming a load from a certain stackslot always reads back what was stored to that stackslot, > (when the load and store both using the same data width) > is there any requirement on the relative positions of different stackslots in memory, > for example does it matter whether stackslot -8 is at a higher or lower memory address compared to stackslot -16? The only time I think stack slot ordering matters is when arguments are passed via the stack. The ordering in that case is defined by the underlying CallingConvention in use. Otherwise, the relative position of stack slots in memory should not matter. -Doug From doug.simon at oracle.com Wed Jun 26 08:30:10 2013 From: doug.simon at oracle.com (doug.simon at oracle.com) Date: Wed, 26 Jun 2013 15:30:10 +0000 Subject: hg: graal/graal: 16 new changesets Message-ID: <20130626153106.B901948553@hg.openjdk.java.net> Changeset: 815c675b07b0 Author: Lukas Stadler Date: 2013-06-25 10:05 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/815c675b07b0 split PiNode into PiNode and GuardedValueNode + graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/GuardedValueNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/PiNode.java Changeset: 2b95d5b1958b Author: Lukas Stadler Date: 2013-06-25 10:22 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/2b95d5b1958b change to GC verification during gate: run in product, add after-GC verification ! mx/commands.py Changeset: 5fb4a450b7a7 Author: Andreas Woess Date: 2013-06-24 17:16 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/5fb4a450b7a7 PartialEvaluator: iterative version of expandTree ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/PartialEvaluator.java Changeset: 254fab64b343 Author: Andreas Woess Date: 2013-06-25 13:53 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/254fab64b343 Separate replacements for Truffle compilation ! graal/com.oracle.graal.truffle.test/src/com/oracle/graal/truffle/test/PartialEvaluationTest.java ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/GraalTruffleRuntime.java ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/PartialEvaluator.java ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/PartialEvaluatorCanonicalizer.java ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/TruffleCompilerImpl.java + graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/TruffleReplacements.java Changeset: 36b75ddac55e Author: Doug Simon Date: 2013-06-25 21:14 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/36b75ddac55e made the primary suite detection logic a little more robust ! mxtool/mx.py Changeset: 74cbc5d6e38f Author: Doug Simon Date: 2013-06-25 23:05 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/74cbc5d6e38f GraalCompilerTest throws an error if code installation fails ! graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/GraalCompilerTest.java Changeset: 1194e94f9c16 Author: Doug Simon Date: 2013-06-25 23:05 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/1194e94f9c16 fixed bug in ConditionalEliminationPhase (GRAAL-346) + graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/ConditionalEliminationTest.java ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/ConditionalEliminationPhase.java Changeset: 2faa1e7ef4f3 Author: Lukas Stadler Date: 2013-06-26 12:16 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/2faa1e7ef4f3 enable TailDuplication for MergeNodes without stateAfter ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/TailDuplicationPhase.java Changeset: ce09ad599709 Author: Thomas Wuerthinger Date: 2013-06-25 14:56 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/ce09ad599709 Fix bug in executeCompiledMethod interpreter stub. ! src/cpu/x86/vm/templateInterpreter_x86_64.cpp Changeset: ddc756cd065d Author: Thomas Wuerthinger Date: 2013-06-25 14:59 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/ddc756cd065d Disable type check hints and type checked inlining for Truffle compiler. ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/TruffleCompilerImpl.java Changeset: 26c69598db3e Author: Thomas Wuerthinger Date: 2013-06-25 19:48 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/26c69598db3e Fix bug in canonicalization of non-compressed object pointers. ! graal/com.oracle.graal.api.meta/src/com/oracle/graal/api/meta/MetaAccessProvider.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/bridge/CompilerToVM.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/bridge/CompilerToVMImpl.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotResolvedJavaField.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotRuntime.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 ! src/share/vm/graal/graalCompilerToVM.cpp Changeset: 8b2065558490 Author: Thomas Wuerthinger Date: 2013-06-25 19:49 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/8b2065558490 Merge. ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/TruffleCompilerImpl.java Changeset: 347d444a6fb7 Author: Thomas Wuerthinger Date: 2013-06-25 23:52 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/347d444a6fb7 Delete unused stub. ! src/share/vm/runtime/sharedRuntime.cpp ! src/share/vm/runtime/sharedRuntime.hpp Changeset: 5d460d3465fd Author: Thomas Wuerthinger Date: 2013-06-26 15:17 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/5d460d3465fd Slightly increase GraalNMethodSizeLimit and make it a product flag. ! src/share/vm/graal/graalGlobals.hpp Changeset: 0ba44a5a8420 Author: Thomas Wuerthinger Date: 2013-06-26 15:22 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/0ba44a5a8420 Add sanity check to avoid overwriting the reserved code buffer for very large methods. ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/bridge/CompilerToVM.java ! src/share/vm/graal/graalCodeInstaller.cpp ! src/share/vm/graal/graalCodeInstaller.hpp ! src/share/vm/graal/graalEnv.hpp Changeset: 9599e1a01812 Author: Thomas Wuerthinger Date: 2013-06-26 15:22 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/9599e1a01812 Merge. From christian.thalinger at oracle.com Wed Jun 26 09:43:40 2013 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Wed, 26 Jun 2013 09:43:40 -0700 Subject: final graal HSAIL support patch In-Reply-To: <4A3B7F7E-E03B-4B31-9A48-FF50B159FC7D@oracle.com> References: <5DD1503F815BD14889DC81D28643E3A73D909869@sausexdag06.amd.com> <6BCB9963-2904-43B6-8C78-4E8A144B2BA1@oracle.com> <4A3B7F7E-E03B-4B31-9A48-FF50B159FC7D@oracle.com> Message-ID: <4B536FE0-526A-4985-BB6F-9AD3A1C8E9A9@oracle.com> On Jun 24, 2013, at 11:18 AM, Christian Thalinger wrote: > > On Jun 24, 2013, at 11:13 AM, Christian Thalinger wrote: > >> I've created a Graal tracking bug so it's easier for me to handle it (the bug is not visible outside of Oracle): >> >> GRAAL-342: add HSAIL backend >> >> Here is the new webrev: >> >> http://cr.openjdk.java.net/~twisti/GRAAL-342/webrev/ > > Two quick comments: > > 1) I understand that the way you're handling the assembler right now was much less work but I wonder if you ever want to go to support your binary format too. Then a full-fledged assembler as for the other platforms might be better. Any thoughts on this? -- Chris > > 2) The Labels. I remember talking to Gilles about this when I did the PTX work and I think there is a better way of doing this (although I can't recall). > > -- Chris > >> >> -- Chris >> >> On Jun 19, 2013, at 3:27 PM, "Venkatachalam, Vasanth" wrote: >> >>> Hi Christian, >>> >>> Here?s the final version of our graal HSAIL support patch. This addresses all of Doug Simon?s comments. >>> >>> In particular, >>> >>> 1) Checkstyle errors have been fixed and all licenses in the Okra packages are attributed to Oracle. >>> 2) What was previously the com.amd.sumatra package has been removed and its source files (which don?t have anything Sumatra specific) have been moved into the com.oracle.graal.compiler.hsail package. >>> 3) Hotspot c++ source changes have been reverted and are no longer part of the webrev. >>> >>> Vasanth >>> >> > From Vasanth.Venkatachalam at amd.com Wed Jun 26 11:37:56 2013 From: Vasanth.Venkatachalam at amd.com (Venkatachalam, Vasanth) Date: Wed, 26 Jun 2013 18:37:56 +0000 Subject: BinaryNodeTestFactory Message-ID: <5DD1503F815BD14889DC81D28643E3A73D90E57E@sausexdag06.amd.com> After merging with the latest default trunk, I'm getting some build errors in eclipse. For example, the file BinaryNodeTest.java is importing com.oracle.truffle.api.codegen.test.BinaryNodeTestFactory.AddNodeFactory, Eclipse complains that this import cannot be resolved. I checked the disk and didn't find any source file for the BinaryNodeTestFactory package. Has this file been checked in? Vasanth From doug.simon at oracle.com Wed Jun 26 12:02:37 2013 From: doug.simon at oracle.com (Doug Simon) Date: Wed, 26 Jun 2013 21:02:37 +0200 Subject: BinaryNodeTestFactory In-Reply-To: <5DD1503F815BD14889DC81D28643E3A73D90E57E@sausexdag06.amd.com> References: <5DD1503F815BD14889DC81D28643E3A73D90E57E@sausexdag06.amd.com> Message-ID: That's a generated source file. This is an issue we've seen getting Eclipse to run the annotation processors properly. Selecting the impacted projects (i.e. those with build errors) in the Package Explorer and force rebuilding them (Project -> Clean...) should fix the problem. On Jun 26, 2013, at 8:37 PM, "Venkatachalam, Vasanth" wrote: > After merging with the latest default trunk, I'm getting some build errors in eclipse. > For example, the file BinaryNodeTest.java is importing com.oracle.truffle.api.codegen.test.BinaryNodeTestFactory.AddNodeFactory, > > Eclipse complains that this import cannot be resolved. I checked the disk and didn't find any source file for the BinaryNodeTestFactory package. > Has this file been checked in? > > Vasanth From Vasanth.Venkatachalam at amd.com Wed Jun 26 15:00:40 2013 From: Vasanth.Venkatachalam at amd.com (Venkatachalam, Vasanth) Date: Wed, 26 Jun 2013 22:00:40 +0000 Subject: final graal HSAIL support patch In-Reply-To: References: <5DD1503F815BD14889DC81D28643E3A73D909869@sausexdag06.amd.com> <6BCB9963-2904-43B6-8C78-4E8A144B2BA1@oracle.com> <4A3B7F7E-E03B-4B31-9A48-FF50B159FC7D@oracle.com> <9C584B81-E266-4D93-AA4F-98717CD703C4@oracle.com> <5DD1503F815BD14889DC81D28643E3A73D90E068@sausexdag06.amd.com> Message-ID: <5DD1503F815BD14889DC81D28643E3A73D90E619@sausexdag06.amd.com> Hi Christian, Attached is our revised patch which makes the changes requested below and removes the okra packages. For the Javadoc, we inserted brief Javadoc comments for every new package introduced. We assumed this would be sufficient since you can generate the Javadoc html files from the sources. Let us know if anything else is needed here. Please send us a link to the revised webrev once you've posted it. Vasanth From: Thomas Wuerthinger [mailto:thomas.wuerthinger at oracle.com] Sent: Monday, June 24, 2013 4:39 PM To: Venkatachalam, Vasanth Cc: sw.runtimes; donald.smith at oracle.com Smith; graal-dev at openjdk.java.net; Christian Thalinger Subject: Re: final graal HSAIL support patch Yes, I agree. We are working on expanding our automatic checks. Additionally, we are working on a style guide document. Given that you are the first major outside contributor, this involves a certain learning experience for us. - thomas On Jun 24, 2013, at 11:29 PM, "Venkatachalam, Vasanth" > wrote: Hi Thomas, We're addressing your comments. It would be nice if checkstyle and/or the Graal formatter in Eclipse would have picked up on these errors, so that we could have caught them the first time around. Vasanth From: Thomas Wuerthinger [mailto:thomas.wuerthinger at oracle.com] Sent: Monday, June 24, 2013 3:14 PM To: Venkatachalam, Vasanth Cc: sw.runtimes; donald.smith at oracle.com Smith; graal-dev at openjdk.java.net; Christian Thalinger Subject: Re: final graal HSAIL support patch Vasanth, Thanks for the patch. I have a first round of coding style comments. We would like the code to adhere to the style guide used for all other Graal modules (although of course we might have already quite some violations in the code base...). For explaining some of those style guide lines, I'm using the HSAILAssembler.java file as an example [1]: - Line 36: Comment should end with ".". - Line 37: Instance field should be declared private. - Line 37: "= 0" should be removed given that 0 is the default value for variables of type "int". - Line 37: The name of the variable must be written in camel case "maxdatatypesize" => "maxDataTypeSize". - Line 38: Comment should start with an upper case letter. - Line 56: Remove "// TODO Auto-generated method stub". If the method is not used, replace with throwing an error/exception (GraalInternalError.shouldNotReachHere). - Line 60: Method name "at" seems too short/ambiguous. - Line 72-76: Multi-line "//" comment should be replaced with javadoc "/** */" comment. - Line 88: Remove unnecessary blank line. - Line 91: Use camel case for method names "emit_mov" => "emitMov" (we have violated this rule for the PTX assembler, but are going to fix that; at least we want to use "_" only in rare instances). - Line 97: Remove unnecessary blank line (please also fix for subsequent lines of the file). - Line 135: No commented-out code - please remove line. - Line 190: Use camel case for method names "emit_convert" => "emitConvert" (please also fix for subsequent method names of the file). - Line 196: Either remove comment or put javadoc comment including additional information. - Line 236: Comment on method should be javadoc comment. - Line 247-248: Comment seems on the wrong place. If this is a comment on the parameter "controlRegString", then please put the comment in the javadoc. Looking over the other files, there are similar style guide line violations, so please make a short sweep over the patch with those items in mind. Additionally, we would like to see a short javadoc description for each newly added class. This seems important given that we will need to maintain this code moving forward. Thanks, thomas [1] http://cr.openjdk.java.net/~twisti/GRAAL-342/webrev/graal/com.oracle.graal.asm.hsail/src/com/oracle/graal/asm/hsail/HSAILAssembler.java.html On Jun 24, 2013, at 8:18 PM, Christian Thalinger > wrote: On Jun 24, 2013, at 11:13 AM, Christian Thalinger > wrote: I've created a Graal tracking bug so it's easier for me to handle it (the bug is not visible outside of Oracle): GRAAL-342: add HSAIL backend Here is the new webrev: http://cr.openjdk.java.net/~twisti/GRAAL-342/webrev/ Two quick comments: 1) I understand that the way you're handling the assembler right now was much less work but I wonder if you ever want to go to support your binary format too. Then a full-fledged assembler as for the other platforms might be better. 2) The Labels. I remember talking to Gilles about this when I did the PTX work and I think there is a better way of doing this (although I can't recall). -- Chris -- Chris On Jun 19, 2013, at 3:27 PM, "Venkatachalam, Vasanth" > wrote: Hi Christian, Here's the final version of our graal HSAIL support patch. This addresses all of Doug Simon's comments. In particular, 1) Checkstyle errors have been fixed and all licenses in the Okra packages are attributed to Oracle. 2) What was previously the com.amd.sumatra package has been removed and its source files (which don't have anything Sumatra specific) have been moved into the com.oracle.graal.compiler.hsail package. 3) Hotspot c++ source changes have been reverted and are no longer part of the webrev. Vasanth From Vasanth.Venkatachalam at amd.com Wed Jun 26 15:10:51 2013 From: Vasanth.Venkatachalam at amd.com (Venkatachalam, Vasanth) Date: Wed, 26 Jun 2013 22:10:51 +0000 Subject: final graal HSAIL support patch In-Reply-To: <4B536FE0-526A-4985-BB6F-9AD3A1C8E9A9@oracle.com> References: <5DD1503F815BD14889DC81D28643E3A73D909869@sausexdag06.amd.com> <6BCB9963-2904-43B6-8C78-4E8A144B2BA1@oracle.com> <4A3B7F7E-E03B-4B31-9A48-FF50B159FC7D@oracle.com> <4B536FE0-526A-4985-BB6F-9AD3A1C8E9A9@oracle.com> Message-ID: <5DD1503F815BD14889DC81D28643E3A73D90E63E@sausexdag06.amd.com> Hi Christian, We don't have specific feedback yet, as we'll need to have some internal discussions about this. Vasanth -----Original Message----- From: Christian Thalinger [mailto:christian.thalinger at oracle.com] Sent: Wednesday, June 26, 2013 11:44 AM To: Venkatachalam, Vasanth Cc: sw.runtimes; donald.smith at oracle.com; graal-dev at openjdk.java.net Subject: Re: final graal HSAIL support patch On Jun 24, 2013, at 11:18 AM, Christian Thalinger wrote: > Two quick comments: > > 1) I understand that the way you're handling the assembler right now was much less work but I wonder if you ever want to go to support your binary format too. Then a full-fledged assembler as for the other platforms might be better. Any thoughts on this? -- Chris From java at stefan-marr.de Fri Jun 28 06:23:31 2013 From: java at stefan-marr.de (Stefan Marr) Date: Fri, 28 Jun 2013 15:23:31 +0200 Subject: TruffleSOM: A Smalltalk implemented with Truffle Message-ID: Hi: In order to get to know the Truffle framework better, I ported SOM, a little Smalltalk bytecode interpreter written in Java, to Truffle. The result is a first basic version that does not yet use any of the advanced features of Truffle, but is fully functional and executes tests and benchmarks: https://github.com/smarr/som-java/tree/TruffleSOM/master When I was implementing it, I was wondering whether you might be interested in TruffleSOM as a show case for how to use Truffle. Digging through the implementation of SimpleLanguage and the test cases did give me only minimal guidance. The set of language features covered is just too minimal. Relevant features such as calling methods, proper calling conventions, supporting lexical scopes, proper usage of control-flow exceptions and so on are either not covered or only in the simplest variation. So, to get a better idea of how to use Truffle, I actually looked at FastR, but I had the feeling that using Truffle was only an afterthought and thus, I am not sure whether it is used 'idiomatically'. Furthermore, the R semantics make it rather hard to see the key elements. However, if that would be interesting, I could use some feedback on the way Truffle is used. One example that should probably be changed is the way I implement lexical scopes for variable access and non-local returns. I suppose I should use materialized frames for that because a block/closure is holding on to its frame. And there are other things that could be done better, for instance, I am not yet supporting blocks/closures escaping from their activation scope, i.e., blocks that get returned as values from the method where they are defined. I would also like to use the chance to report a little problem, I had with the way the type system works. I haven't really used it yet, but I had trouble with the som.vmobjects.Object class clashing with java.lang.Object. That lead me to add a hack to the codegen to use fully qualified names for all classes with the simple name Object. I am sure there are more general solutions to the problem, but I wanted to avoid having to rename the Object class. The current patch I use is available here: https://github.com/smarr/graal/commit/12cf68632189703cb6cdcf683dc296452cded875 Another little nit is this patch: https://github.com/smarr/graal/commit/47437eba9b955108a1ed2cba0806d7f192fab238 I messed up the mx/env file when getting started, and found the resulting Python stack trace rather unpleasant. However, while I encountered a few stumbling blocks being not familiar with Truffle, overall I had the feeling that it is rather pleasant to use. For specific questions, the javadocs and test cases typically already provide hints how to solve problems or how to use the API correctly. So, thanks for the nice framework :) Best regards Stefan -- Stefan Marr Software Languages Lab Vrije Universiteit Brussel Pleinlaan 2 / B-1050 Brussels / Belgium http://soft.vub.ac.be/~smarr Phone: +32 2 629 2974 Fax: +32 2 629 3525 From s1255753 at sms.ed.ac.uk Fri Jun 28 07:08:17 2013 From: s1255753 at sms.ed.ac.uk (ATKIN-GRANVILLE Chris) Date: Fri, 28 Jun 2013 14:08:17 +0000 Subject: Low level PhasePosition In-Reply-To: <51C887D2.70904@oracle.com> References: <51C887D2.70904@oracle.com> Message-ID: <479AF2D1-FC8B-4EBC-BDB2-5755F5800143@sms.ed.ac.uk> I see. I tried replacing my phases with suites, but I wasn't able to get the same results out. Specifically, when I use suites instead of a phasePlan, it appears to me as if each "suite" receives a lower-level graph IR than the equivalent "phase". To illustrate, if I use a phasePlan, I get nodes like LoopBeginNode etc - with the equivalent suite, I don't. Perhaps I'm missing something though - I will investigate further. --chris On 24 Jun 2013, at 18:54, Mick Jordan wrote: > On 6/24/13 10:47 AM, ATKIN-GRANVILLE Chris wrote: >> Hi guys. Why was PhasePosition.LOW_LEVEL removed? I can't find any hints in the commit logs, nor any references to it in a current checkout of the repo. Is there a replacement for it? >> >> > I don't know exactly why LOW_LEVEL was removed, but I do know that PhasePlan is in the process of being phased out (sic) to be replaced (eventually) by custom Suites. > > I used to use LOW_LEVEL and the way I worked around its demise was to use the appendPhase method on the PhaseSuite class, to add the phase to the end of the MidTier suite, e.g. > > bootSuites = Suites.createDefaultSuites(); > PhaseSuite midTier = bootSuites.getMidTier(); > midTier.appendPhase(new MyLowLevelPhase()); > > > Mick > > -- The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336. From christian.thalinger at oracle.com Fri Jun 28 13:28:31 2013 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Fri, 28 Jun 2013 13:28:31 -0700 Subject: final graal HSAIL support patch In-Reply-To: <5DD1503F815BD14889DC81D28643E3A73D90E619@sausexdag06.amd.com> References: <5DD1503F815BD14889DC81D28643E3A73D909869@sausexdag06.amd.com> <6BCB9963-2904-43B6-8C78-4E8A144B2BA1@oracle.com> <4A3B7F7E-E03B-4B31-9A48-FF50B159FC7D@oracle.com> <9C584B81-E266-4D93-AA4F-98717CD703C4@oracle.com> <5DD1503F815BD14889DC81D28643E3A73D90E068@sausexdag06.amd.com> <5DD1503F815BD14889DC81D28643E3A73D90E619@sausexdag06.amd.com> Message-ID: <4D9C9697-3403-450E-AEF6-190FA35E145F@oracle.com> On Jun 26, 2013, at 3:00 PM, "Venkatachalam, Vasanth" wrote: > Hi Christian, > > Attached is our revised patch which makes the changes requested below and removes the okra packages. > > For the Javadoc, we inserted brief Javadoc comments for every new package introduced. We assumed this would be sufficient since you can generate the Javadoc html files from the sources. > Let us know if anything else is needed here. > > Please send us a link to the revised webrev once you?ve posted it. Sorry for the delay: http://cr.openjdk.java.net/~twisti/GRAAL-342/webrev/ -- Chris > > Vasanth > > From: Thomas Wuerthinger [mailto:thomas.wuerthinger at oracle.com] > Sent: Monday, June 24, 2013 4:39 PM > To: Venkatachalam, Vasanth > Cc: sw.runtimes; donald.smith at oracle.com Smith; graal-dev at openjdk.java.net; Christian Thalinger > Subject: Re: final graal HSAIL support patch > > Yes, I agree. We are working on expanding our automatic checks. Additionally, we are working on a style guide document. Given that you are the first major outside contributor, this involves a certain learning experience for us. - thomas > > On Jun 24, 2013, at 11:29 PM, "Venkatachalam, Vasanth" wrote: > > > Hi Thomas, > > We?re addressing your comments. It would be nice if checkstyle and/or the Graal formatter in Eclipse would have picked up on these errors, so that we could have caught them the first time around. > > Vasanth > > From: Thomas Wuerthinger [mailto:thomas.wuerthinger at oracle.com] > Sent: Monday, June 24, 2013 3:14 PM > To: Venkatachalam, Vasanth > Cc: sw.runtimes; donald.smith at oracle.com Smith; graal-dev at openjdk.java.net; Christian Thalinger > Subject: Re: final graal HSAIL support patch > > Vasanth, > > Thanks for the patch. I have a first round of coding style comments. We would like the code to adhere to the style guide used for all other Graal modules (although of course we might have already quite some violations in the code base?). For explaining some of those style guide lines, I'm using the HSAILAssembler.java file as an example [1]: > > - Line 36: Comment should end with ".". > - Line 37: Instance field should be declared private. > - Line 37: "= 0" should be removed given that 0 is the default value for variables of type "int". > - Line 37: The name of the variable must be written in camel case "maxdatatypesize" => "maxDataTypeSize". > - Line 38: Comment should start with an upper case letter. > - Line 56: Remove "// TODO Auto-generated method stub". If the method is not used, replace with throwing an error/exception (GraalInternalError.shouldNotReachHere). > - Line 60: Method name "at" seems too short/ambiguous. > - Line 72-76: Multi-line "//" comment should be replaced with javadoc "/** */" comment. > - Line 88: Remove unnecessary blank line. > - Line 91: Use camel case for method names "emit_mov" => "emitMov" (we have violated this rule for the PTX assembler, but are going to fix that; at least we want to use "_" only in rare instances). > - Line 97: Remove unnecessary blank line (please also fix for subsequent lines of the file). > - Line 135: No commented-out code - please remove line. > - Line 190: Use camel case for method names "emit_convert" => "emitConvert" (please also fix for subsequent method names of the file). > - Line 196: Either remove comment or put javadoc comment including additional information. > - Line 236: Comment on method should be javadoc comment. > - Line 247-248: Comment seems on the wrong place. If this is a comment on the parameter "controlRegString", then please put the comment in the javadoc. > > Looking over the other files, there are similar style guide line violations, so please make a short sweep over the patch with those items in mind. > > Additionally, we would like to see a short javadoc description for each newly added class. This seems important given that we will need to maintain this code moving forward. > > Thanks, thomas > > [1] http://cr.openjdk.java.net/~twisti/GRAAL-342/webrev/graal/com.oracle.graal.asm.hsail/src/com/oracle/graal/asm/hsail/HSAILAssembler.java.html > > On Jun 24, 2013, at 8:18 PM, Christian Thalinger wrote: > > > > > On Jun 24, 2013, at 11:13 AM, Christian Thalinger wrote: > > > > I've created a Graal tracking bug so it's easier for me to handle it (the bug is not visible outside of Oracle): > > GRAAL-342: add HSAIL backend > > Here is the new webrev: > > http://cr.openjdk.java.net/~twisti/GRAAL-342/webrev/ > > Two quick comments: > > 1) I understand that the way you're handling the assembler right now was much less work but I wonder if you ever want to go to support your binary format too. Then a full-fledged assembler as for the other platforms might be better. > > 2) The Labels. I remember talking to Gilles about this when I did the PTX work and I think there is a better way of doing this (although I can't recall). > > -- Chris > > > > > -- Chris > > On Jun 19, 2013, at 3:27 PM, "Venkatachalam, Vasanth" wrote: > > > > Hi Christian, > > Here?s the final version of our graal HSAIL support patch. This addresses all of Doug Simon?s comments. > > In particular, > > 1) Checkstyle errors have been fixed and all licenses in the Okra packages are attributed to Oracle. > 2) What was previously the com.amd.sumatra package has been removed and its source files (which don?t have anything Sumatra specific) have been moved into the com.oracle.graal.compiler.hsail package. > 3) Hotspot c++ source changes have been reverted and are no longer part of the webrev. > > Vasanth > > > > > From tom.deneau at amd.com Fri Jun 28 14:32:57 2013 From: tom.deneau at amd.com (Deneau, Tom) Date: Fri, 28 Jun 2013 21:32:57 +0000 Subject: [Sw.runtimes] final graal HSAIL support patch In-Reply-To: References: <5DD1503F815BD14889DC81D28643E3A73D909869@sausexdag06.amd.com> <6BCB9963-2904-43B6-8C78-4E8A144B2BA1@oracle.com> <4A3B7F7E-E03B-4B31-9A48-FF50B159FC7D@oracle.com> <9C584B81-E266-4D93-AA4F-98717CD703C4@oracle.com> <68BA4718-61A3-43F8-9777-ACAB2E969D59@oracle.com> Message-ID: Doug -- While preparing the change to make okra.jar a downloadable jar file, we hit the following issue. Some of the classes in graal.jar reference classes in okra.jar, in other words okra.jar is not used only by the junit tests. When the classes in graal.jar try to reference okra.jar they fail because it is not on the bootclasspath. We can work around this by explicitly specifying -Xbootclasspath/a:okra.jar but this doesn't seem a good long term solution. So since we have library at OKRA@path=lib/okra-1.jar, I tried listing OKRA as a dependency under graal.jar distribution, but the mx build did not like that. error: project named OKRA not found How should we resolve this? Is there a way under mx to add the class files from okra.jar into graal.jar? Or some way to include okra.jar in the lib directory so we don't need to use bootclasspath? -- Tom -----Original Message----- From: Doug Simon [mailto:doug.simon at oracle.com] Sent: Tuesday, June 25, 2013 12:58 AM To: Deneau, Tom Cc: Thomas Wuerthinger; graal-dev at openjdk.java.net; sw.runtimes; donald.smith at oracle.com Smith Subject: Re: [Sw.runtimes] final graal HSAIL support patch On Jun 25, 2013, at 12:12 AM, "Deneau, Tom" wrote: > Doug -- > > Where should the jar file be downloaded from? Is there some place in one of the openjdk directories that would work? Somewhere under http://cr.openjdk.java.net/~tdeneau/ would probably be best since you have write access to it. -Doug > -----Original Message----- > From: Doug Simon [mailto:doug.simon at oracle.com] > Sent: Monday, June 24, 2013 4:33 PM > To: Deneau, Tom > Cc: Thomas Wuerthinger; graal-dev at openjdk.java.net; sw.runtimes; donald.smith at oracle.com Smith > Subject: Re: [Sw.runtimes] final graal HSAIL support patch > > Hi Tom, > > Ok, based on the need to link with the native code and the fact that there is nothing particularly Graal specific in this code, I think the okra-.jar solution is the best one moving forward. The suffix on the jar should be sufficient to manage any version dependencies from the other HSAIL code and the Okra library. I'm guessing that this library interface will not change very often anyway. As you state, the issue of staying in sync with the native code will have to be resolved some other way anyway. > > One request I have is that the okra-.jar file also contain the Java sources so that debugging through this code should be straightforward. > > -Doug > > On Jun 24, 2013, at 11:08 PM, "Deneau, Tom" wrote: > >> Doug -- >> >> As you may have noticed, many of the methods in com.amd.okra are native so there is a corresponding native library with com_amd_okra_xxx names which is needed if you want to actually dispatch anything. This is an open source project of its own and will be used by other projects such as Aparapi. Since there is nothing graal-specific in the native library, it doesn't seem right to have a graal namespace on it. So leaving com.amd.okra as the package name would be our first choice. >> >> A second choice would be to have the com.oracle.graal.okra which you propose be a stub which could be built against but would use reflection to get to the real com.amd.okra which could be shipped as a jar with the okra native libraries. >> >> A third choice is going back to your earlier proposal of graal building against an okra.jar which would be downloaded from somewhere (would cr.openjdk.java.net do for this?) >> >> Our earlier concern was that the third choice would more easily get out of sync with the actual native libraries but as I think about it all three choices have this possibility of getting out of sync with the native libraries. >> >> -- Tom >> >> >> -----Original Message----- >> From: sw.runtimes-bounces at mpdtxmail.amd.com [mailto:sw.runtimes-bounces at mpdtxmail.amd.com] On Behalf Of Doug Simon >> Sent: Monday, June 24, 2013 3:30 PM >> To: Thomas Wuerthinger >> Cc: graal-dev at openjdk.java.net; sw.runtimes; donald.smith at oracle.com Smith >> Subject: Re: [Sw.runtimes] final graal HSAIL support patch >> >> Vasanth, >> >> Just one more request on top of Thomas' feedback. >> >> We'd like to keep all the Graal code in a com.oracle.graal package namespace. As such, could you please rename the com.amd.okra package to something like com.oracle.graal.amd.okra or simply com.oracle.graal.okra. >> >> Thanks. >> >> -Doug >> >> On Jun 24, 2013, at 10:13 PM, Thomas Wuerthinger wrote: >> >>> Vasanth, >>> >>> Thanks for the patch. I have a first round of coding style comments. We would like the code to adhere to the style guide used for all other Graal modules (although of course we might have already quite some violations in the code base...). For explaining some of those style guide lines, I'm using the HSAILAssembler.java file as an example [1]: >>> >>> - Line 36: Comment should end with ".". >>> - Line 37: Instance field should be declared private. >>> - Line 37: "= 0" should be removed given that 0 is the default value for variables of type "int". >>> - Line 37: The name of the variable must be written in camel case "maxdatatypesize" => "maxDataTypeSize". >>> - Line 38: Comment should start with an upper case letter. >>> - Line 56: Remove "// TODO Auto-generated method stub". If the method is not used, replace with throwing an error/exception (GraalInternalError.shouldNotReachHere). >>> - Line 60: Method name "at" seems too short/ambiguous. >>> - Line 72-76: Multi-line "//" comment should be replaced with javadoc "/** */" comment. >>> - Line 88: Remove unnecessary blank line. >>> - Line 91: Use camel case for method names "emit_mov" => "emitMov" (we have violated this rule for the PTX assembler, but are going to fix that; at least we want to use "_" only in rare instances). >>> - Line 97: Remove unnecessary blank line (please also fix for subsequent lines of the file). >>> - Line 135: No commented-out code - please remove line. >>> - Line 190: Use camel case for method names "emit_convert" => "emitConvert" (please also fix for subsequent method names of the file). >>> - Line 196: Either remove comment or put javadoc comment including additional information. >>> - Line 236: Comment on method should be javadoc comment. >>> - Line 247-248: Comment seems on the wrong place. If this is a comment on the parameter "controlRegString", then please put the comment in the javadoc. >>> >>> Looking over the other files, there are similar style guide line violations, so please make a short sweep over the patch with those items in mind. >>> >>> Additionally, we would like to see a short javadoc description for each newly added class. This seems important given that we will need to maintain this code moving forward. >>> >>> Thanks, thomas >>> >>> [1] http://cr.openjdk.java.net/~twisti/GRAAL-342/webrev/graal/com.oracle.graal.asm.hsail/src/com/oracle/graal/asm/hsail/HSAILAssembler.java.html >>> >>> On Jun 24, 2013, at 8:18 PM, Christian Thalinger wrote: >>> >>>> >>>> On Jun 24, 2013, at 11:13 AM, Christian Thalinger wrote: >>>> >>>>> I've created a Graal tracking bug so it's easier for me to handle it (the bug is not visible outside of Oracle): >>>>> >>>>> GRAAL-342: add HSAIL backend >>>>> >>>>> Here is the new webrev: >>>>> >>>>> http://cr.openjdk.java.net/~twisti/GRAAL-342/webrev/ >>>> >>>> Two quick comments: >>>> >>>> 1) I understand that the way you're handling the assembler right now was much less work but I wonder if you ever want to go to support your binary format too. Then a full-fledged assembler as for the other platforms might be better. >>>> >>>> 2) The Labels. I remember talking to Gilles about this when I did the PTX work and I think there is a better way of doing this (although I can't recall). >>>> >>>> -- Chris >>>> >>>>> >>>>> -- Chris >>>>> >>>>> On Jun 19, 2013, at 3:27 PM, "Venkatachalam, Vasanth" wrote: >>>>> >>>>>> Hi Christian, >>>>>> >>>>>> Here's the final version of our graal HSAIL support patch. This addresses all of Doug Simon's comments. >>>>>> >>>>>> In particular, >>>>>> >>>>>> 1) Checkstyle errors have been fixed and all licenses in the Okra packages are attributed to Oracle. >>>>>> 2) What was previously the com.amd.sumatra package has been removed and its source files (which don't have anything Sumatra specific) have been moved into the com.oracle.graal.compiler.hsail package. >>>>>> 3) Hotspot c++ source changes have been reverted and are no longer part of the webrev. >>>>>> >>>>>> Vasanth >>>>>> >>>>> >>>> >>> >> >> >> >> > > > From christian.thalinger at oracle.com Fri Jun 28 19:50:05 2013 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Fri, 28 Jun 2013 19:50:05 -0700 Subject: final graal HSAIL support patch In-Reply-To: <4D9C9697-3403-450E-AEF6-190FA35E145F@oracle.com> References: <5DD1503F815BD14889DC81D28643E3A73D909869@sausexdag06.amd.com> <6BCB9963-2904-43B6-8C78-4E8A144B2BA1@oracle.com> <4A3B7F7E-E03B-4B31-9A48-FF50B159FC7D@oracle.com> <9C584B81-E266-4D93-AA4F-98717CD703C4@oracle.com> <5DD1503F815BD14889DC81D28643E3A73D90E068@sausexdag06.amd.com> <5DD1503F815BD14889DC81D28643E3A73D90E619@sausexdag06.amd.com> <4D9C9697-3403-450E-AEF6-190FA35E145F@oracle.com> Message-ID: On Jun 28, 2013, at 1:28 PM, Christian Thalinger wrote: > > On Jun 26, 2013, at 3:00 PM, "Venkatachalam, Vasanth" wrote: > >> Hi Christian, >> >> Attached is our revised patch which makes the changes requested below and removes the okra packages. >> >> For the Javadoc, we inserted brief Javadoc comments for every new package introduced. We assumed this would be sufficient since you can generate the Javadoc html files from the sources. >> Let us know if anything else is needed here. >> >> Please send us a link to the revised webrev once you?ve posted it. > > Sorry for the delay: > > http://cr.openjdk.java.net/~twisti/GRAAL-342/webrev/ About the Label again, I think we should integrate this change but slightly different. Since every Label gets an ID assigned sooner or later we should do it in the constructor. Also: + public String toSequentialString() { + return isBound() || hasPreAssignedId ? ("@L" + localId) : "@L?"; + } is too HSAIL specific. Suggest that we add a name() method instead which returns the Label's name, e.g. L123. Maybe toString should return "unbound-"+id in the unbound case for debugging purposes. I'd like to push this change separately before we integrate the HSAIL work. -- Chris > > -- Chris > >> >> Vasanth >> >> From: Thomas Wuerthinger [mailto:thomas.wuerthinger at oracle.com] >> Sent: Monday, June 24, 2013 4:39 PM >> To: Venkatachalam, Vasanth >> Cc: sw.runtimes; donald.smith at oracle.com Smith; graal-dev at openjdk.java.net; Christian Thalinger >> Subject: Re: final graal HSAIL support patch >> >> Yes, I agree. We are working on expanding our automatic checks. Additionally, we are working on a style guide document. Given that you are the first major outside contributor, this involves a certain learning experience for us. - thomas >> >> On Jun 24, 2013, at 11:29 PM, "Venkatachalam, Vasanth" wrote: >> >> >> Hi Thomas, >> >> We?re addressing your comments. It would be nice if checkstyle and/or the Graal formatter in Eclipse would have picked up on these errors, so that we could have caught them the first time around. >> >> Vasanth >> >> From: Thomas Wuerthinger [mailto:thomas.wuerthinger at oracle.com] >> Sent: Monday, June 24, 2013 3:14 PM >> To: Venkatachalam, Vasanth >> Cc: sw.runtimes; donald.smith at oracle.com Smith; graal-dev at openjdk.java.net; Christian Thalinger >> Subject: Re: final graal HSAIL support patch >> >> Vasanth, >> >> Thanks for the patch. I have a first round of coding style comments. We would like the code to adhere to the style guide used for all other Graal modules (although of course we might have already quite some violations in the code base?). For explaining some of those style guide lines, I'm using the HSAILAssembler.java file as an example [1]: >> >> - Line 36: Comment should end with ".". >> - Line 37: Instance field should be declared private. >> - Line 37: "= 0" should be removed given that 0 is the default value for variables of type "int". >> - Line 37: The name of the variable must be written in camel case "maxdatatypesize" => "maxDataTypeSize". >> - Line 38: Comment should start with an upper case letter. >> - Line 56: Remove "// TODO Auto-generated method stub". If the method is not used, replace with throwing an error/exception (GraalInternalError.shouldNotReachHere). >> - Line 60: Method name "at" seems too short/ambiguous. >> - Line 72-76: Multi-line "//" comment should be replaced with javadoc "/** */" comment. >> - Line 88: Remove unnecessary blank line. >> - Line 91: Use camel case for method names "emit_mov" => "emitMov" (we have violated this rule for the PTX assembler, but are going to fix that; at least we want to use "_" only in rare instances). >> - Line 97: Remove unnecessary blank line (please also fix for subsequent lines of the file). >> - Line 135: No commented-out code - please remove line. >> - Line 190: Use camel case for method names "emit_convert" => "emitConvert" (please also fix for subsequent method names of the file). >> - Line 196: Either remove comment or put javadoc comment including additional information. >> - Line 236: Comment on method should be javadoc comment. >> - Line 247-248: Comment seems on the wrong place. If this is a comment on the parameter "controlRegString", then please put the comment in the javadoc. >> >> Looking over the other files, there are similar style guide line violations, so please make a short sweep over the patch with those items in mind. >> >> Additionally, we would like to see a short javadoc description for each newly added class. This seems important given that we will need to maintain this code moving forward. >> >> Thanks, thomas >> >> [1] http://cr.openjdk.java.net/~twisti/GRAAL-342/webrev/graal/com.oracle.graal.asm.hsail/src/com/oracle/graal/asm/hsail/HSAILAssembler.java.html >> >> On Jun 24, 2013, at 8:18 PM, Christian Thalinger wrote: >> >> >> >> >> On Jun 24, 2013, at 11:13 AM, Christian Thalinger wrote: >> >> >> >> I've created a Graal tracking bug so it's easier for me to handle it (the bug is not visible outside of Oracle): >> >> GRAAL-342: add HSAIL backend >> >> Here is the new webrev: >> >> http://cr.openjdk.java.net/~twisti/GRAAL-342/webrev/ >> >> Two quick comments: >> >> 1) I understand that the way you're handling the assembler right now was much less work but I wonder if you ever want to go to support your binary format too. Then a full-fledged assembler as for the other platforms might be better. >> >> 2) The Labels. I remember talking to Gilles about this when I did the PTX work and I think there is a better way of doing this (although I can't recall). >> >> -- Chris >> >> >> >> >> -- Chris >> >> On Jun 19, 2013, at 3:27 PM, "Venkatachalam, Vasanth" wrote: >> >> >> >> Hi Christian, >> >> Here?s the final version of our graal HSAIL support patch. This addresses all of Doug Simon?s comments. >> >> In particular, >> >> 1) Checkstyle errors have been fixed and all licenses in the Okra packages are attributed to Oracle. >> 2) What was previously the com.amd.sumatra package has been removed and its source files (which don?t have anything Sumatra specific) have been moved into the com.oracle.graal.compiler.hsail package. >> 3) Hotspot c++ source changes have been reverted and are no longer part of the webrev. >> >> Vasanth >> >> >> >> >> > From doug.simon at oracle.com Sat Jun 29 03:19:45 2013 From: doug.simon at oracle.com (Doug Simon) Date: Sat, 29 Jun 2013 12:19:45 +0200 Subject: [Sw.runtimes] final graal HSAIL support patch In-Reply-To: References: <5DD1503F815BD14889DC81D28643E3A73D909869@sausexdag06.amd.com> <6BCB9963-2904-43B6-8C78-4E8A144B2BA1@oracle.com> <4A3B7F7E-E03B-4B31-9A48-FF50B159FC7D@oracle.com> <9C584B81-E266-4D93-AA4F-98717CD703C4@oracle.com> <68BA4718-61A3-43F8-9777-ACAB2E969D59@oracle.com> Message-ID: Hi Tom, I've modified 'mx build'[1] so that graal.jar now includes the libraries that the projects in the distribution depend upon. As such, you should not have to list OKRA as a dependency of the GRAAL distribution as it must already be specified as a dependency of one of the projects in the GRAAL distribution. -Doug [1] http://hg.openjdk.java.net/graal/graal/rev/aee899c96b0b On Jun 28, 2013, at 11:32 PM, "Deneau, Tom" wrote: > Doug -- > > While preparing the change to make okra.jar a downloadable jar file, we hit the following issue. > > Some of the classes in graal.jar reference classes in okra.jar, in other words okra.jar is > not used only by the junit tests. When the classes in graal.jar try to reference okra.jar they fail > because it is not on the bootclasspath. We can work around this by explicitly specifying > -Xbootclasspath/a:okra.jar but this doesn't seem a good long term solution. > > So since we have library at OKRA@path=lib/okra-1.jar, > I tried listing OKRA as a dependency under graal.jar distribution, but the mx build did not like that. > error: project named OKRA not found > > How should we resolve this? > Is there a way under mx to add the class files from okra.jar into graal.jar? > Or some way to include okra.jar in the lib directory so we don't need to use bootclasspath? > > -- Tom > > > -----Original Message----- > From: Doug Simon [mailto:doug.simon at oracle.com] > Sent: Tuesday, June 25, 2013 12:58 AM > To: Deneau, Tom > Cc: Thomas Wuerthinger; graal-dev at openjdk.java.net; sw.runtimes; donald.smith at oracle.com Smith > Subject: Re: [Sw.runtimes] final graal HSAIL support patch > > > On Jun 25, 2013, at 12:12 AM, "Deneau, Tom" wrote: > >> Doug -- >> >> Where should the jar file be downloaded from? Is there some place in one of the openjdk directories that would work? > > Somewhere under http://cr.openjdk.java.net/~tdeneau/ would probably be best since you have write access to it. > > -Doug > >> -----Original Message----- >> From: Doug Simon [mailto:doug.simon at oracle.com] >> Sent: Monday, June 24, 2013 4:33 PM >> To: Deneau, Tom >> Cc: Thomas Wuerthinger; graal-dev at openjdk.java.net; sw.runtimes; donald.smith at oracle.com Smith >> Subject: Re: [Sw.runtimes] final graal HSAIL support patch >> >> Hi Tom, >> >> Ok, based on the need to link with the native code and the fact that there is nothing particularly Graal specific in this code, I think the okra-.jar solution is the best one moving forward. The suffix on the jar should be sufficient to manage any version dependencies from the other HSAIL code and the Okra library. I'm guessing that this library interface will not change very often anyway. As you state, the issue of staying in sync with the native code will have to be resolved some other way anyway. >> >> One request I have is that the okra-.jar file also contain the Java sources so that debugging through this code should be straightforward. >> >> -Doug >> >> On Jun 24, 2013, at 11:08 PM, "Deneau, Tom" wrote: >> >>> Doug -- >>> >>> As you may have noticed, many of the methods in com.amd.okra are native so there is a corresponding native library with com_amd_okra_xxx names which is needed if you want to actually dispatch anything. This is an open source project of its own and will be used by other projects such as Aparapi. Since there is nothing graal-specific in the native library, it doesn't seem right to have a graal namespace on it. So leaving com.amd.okra as the package name would be our first choice. >>> >>> A second choice would be to have the com.oracle.graal.okra which you propose be a stub which could be built against but would use reflection to get to the real com.amd.okra which could be shipped as a jar with the okra native libraries. >>> >>> A third choice is going back to your earlier proposal of graal building against an okra.jar which would be downloaded from somewhere (would cr.openjdk.java.net do for this?) >>> >>> Our earlier concern was that the third choice would more easily get out of sync with the actual native libraries but as I think about it all three choices have this possibility of getting out of sync with the native libraries. >>> >>> -- Tom >>> >>> >>> -----Original Message----- >>> From: sw.runtimes-bounces at mpdtxmail.amd.com [mailto:sw.runtimes-bounces at mpdtxmail.amd.com] On Behalf Of Doug Simon >>> Sent: Monday, June 24, 2013 3:30 PM >>> To: Thomas Wuerthinger >>> Cc: graal-dev at openjdk.java.net; sw.runtimes; donald.smith at oracle.com Smith >>> Subject: Re: [Sw.runtimes] final graal HSAIL support patch >>> >>> Vasanth, >>> >>> Just one more request on top of Thomas' feedback. >>> >>> We'd like to keep all the Graal code in a com.oracle.graal package namespace. As such, could you please rename the com.amd.okra package to something like com.oracle.graal.amd.okra or simply com.oracle.graal.okra. >>> >>> Thanks. >>> >>> -Doug >>> >>> On Jun 24, 2013, at 10:13 PM, Thomas Wuerthinger wrote: >>> >>>> Vasanth, >>>> >>>> Thanks for the patch. I have a first round of coding style comments. We would like the code to adhere to the style guide used for all other Graal modules (although of course we might have already quite some violations in the code base...). For explaining some of those style guide lines, I'm using the HSAILAssembler.java file as an example [1]: >>>> >>>> - Line 36: Comment should end with ".". >>>> - Line 37: Instance field should be declared private. >>>> - Line 37: "= 0" should be removed given that 0 is the default value for variables of type "int". >>>> - Line 37: The name of the variable must be written in camel case "maxdatatypesize" => "maxDataTypeSize". >>>> - Line 38: Comment should start with an upper case letter. >>>> - Line 56: Remove "// TODO Auto-generated method stub". If the method is not used, replace with throwing an error/exception (GraalInternalError.shouldNotReachHere). >>>> - Line 60: Method name "at" seems too short/ambiguous. >>>> - Line 72-76: Multi-line "//" comment should be replaced with javadoc "/** */" comment. >>>> - Line 88: Remove unnecessary blank line. >>>> - Line 91: Use camel case for method names "emit_mov" => "emitMov" (we have violated this rule for the PTX assembler, but are going to fix that; at least we want to use "_" only in rare instances). >>>> - Line 97: Remove unnecessary blank line (please also fix for subsequent lines of the file). >>>> - Line 135: No commented-out code - please remove line. >>>> - Line 190: Use camel case for method names "emit_convert" => "emitConvert" (please also fix for subsequent method names of the file). >>>> - Line 196: Either remove comment or put javadoc comment including additional information. >>>> - Line 236: Comment on method should be javadoc comment. >>>> - Line 247-248: Comment seems on the wrong place. If this is a comment on the parameter "controlRegString", then please put the comment in the javadoc. >>>> >>>> Looking over the other files, there are similar style guide line violations, so please make a short sweep over the patch with those items in mind. >>>> >>>> Additionally, we would like to see a short javadoc description for each newly added class. This seems important given that we will need to maintain this code moving forward. >>>> >>>> Thanks, thomas >>>> >>>> [1] http://cr.openjdk.java.net/~twisti/GRAAL-342/webrev/graal/com.oracle.graal.asm.hsail/src/com/oracle/graal/asm/hsail/HSAILAssembler.java.html >>>> >>>> On Jun 24, 2013, at 8:18 PM, Christian Thalinger wrote: >>>> >>>>> >>>>> On Jun 24, 2013, at 11:13 AM, Christian Thalinger wrote: >>>>> >>>>>> I've created a Graal tracking bug so it's easier for me to handle it (the bug is not visible outside of Oracle): >>>>>> >>>>>> GRAAL-342: add HSAIL backend >>>>>> >>>>>> Here is the new webrev: >>>>>> >>>>>> http://cr.openjdk.java.net/~twisti/GRAAL-342/webrev/ >>>>> >>>>> Two quick comments: >>>>> >>>>> 1) I understand that the way you're handling the assembler right now was much less work but I wonder if you ever want to go to support your binary format too. Then a full-fledged assembler as for the other platforms might be better. >>>>> >>>>> 2) The Labels. I remember talking to Gilles about this when I did the PTX work and I think there is a better way of doing this (although I can't recall). >>>>> >>>>> -- Chris >>>>> >>>>>> >>>>>> -- Chris >>>>>> >>>>>> On Jun 19, 2013, at 3:27 PM, "Venkatachalam, Vasanth" wrote: >>>>>> >>>>>>> Hi Christian, >>>>>>> >>>>>>> Here's the final version of our graal HSAIL support patch. This addresses all of Doug Simon's comments. >>>>>>> >>>>>>> In particular, >>>>>>> >>>>>>> 1) Checkstyle errors have been fixed and all licenses in the Okra packages are attributed to Oracle. >>>>>>> 2) What was previously the com.amd.sumatra package has been removed and its source files (which don't have anything Sumatra specific) have been moved into the com.oracle.graal.compiler.hsail package. >>>>>>> 3) Hotspot c++ source changes have been reverted and are no longer part of the webrev. >>>>>>> >>>>>>> Vasanth >>>>>>> >>>>>> >>>>> >>>> >>> >>> >>> >>> >> >> >> > > > From doug.simon at oracle.com Sat Jun 29 03:18:38 2013 From: doug.simon at oracle.com (doug.simon at oracle.com) Date: Sat, 29 Jun 2013 10:18:38 +0000 Subject: hg: graal/graal: 35 new changesets Message-ID: <20130629102123.055E24868E@hg.openjdk.java.net> Changeset: 554f67e4ff3f Author: Roland Schatz Date: 2013-06-26 15:35 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/554f67e4ff3f Use slow-path stub call instead of deopt in lowering of DynamicNewArrayNode. ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/HotSpotVMConfig.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotRuntime.java + graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/nodes/DynamicNewArrayStubCall.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/DynamicNewArrayNode.java ! graal/com.oracle.graal.replacements.test/src/com/oracle/graal/replacements/test/DynamicNewArrayTest.java ! graal/com.oracle.graal.replacements/src/com/oracle/graal/replacements/ArraySubstitutions.java ! src/share/vm/graal/graalCompilerToVM.cpp ! src/share/vm/graal/graalRuntime.cpp ! src/share/vm/graal/graalRuntime.hpp Changeset: 97caf20971ed Author: Bernhard Urban Date: 2013-06-27 18:21 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/97caf20971ed CTW: adapt output messages, so that they match with the output of hotspot ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/CompileTheWorld.java Changeset: 7b4afef906ca Author: Christos Kotselidis Date: 2013-06-27 11:14 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/7b4afef906ca Fix stamp in unsafe load lowering ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotRuntime.java Changeset: dc5b2b5089bd Author: Christos Kotselidis Date: 2013-06-27 11:16 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/dc5b2b5089bd Assume that all unsafe loads generated after guard lowering derive from ArrayCopy Intrinsics ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotRuntime.java Changeset: a6d6e6afd897 Author: Christos Kotselidis Date: 2013-06-27 11:22 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/a6d6e6afd897 Introduce ReadCompressed opcode in WordTypeRewriter ! graal/com.oracle.graal.word/src/com/oracle/graal/word/Pointer.java ! graal/com.oracle.graal.word/src/com/oracle/graal/word/Word.java ! graal/com.oracle.graal.word/src/com/oracle/graal/word/phases/WordTypeRewriterPhase.java Changeset: 01c902c59e38 Author: Christos Kotselidis Date: 2013-06-27 11:23 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/01c902c59e38 Replace unsafe load with readCompressed while reading the previous value in G1 pre barriers (Avoids guard insertion after guard lowering) ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/WriteBarrierSnippets.java Changeset: 74c33d164767 Author: Christos Kotselidis Date: 2013-06-27 11:26 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/74c33d164767 Introduce ArrayRangeWriteBarrier super class + graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/ArrayRangeWriteBarrier.java Changeset: 55d6875fc4e8 Author: Christos Kotselidis Date: 2013-06-27 11:28 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/55d6875fc4e8 SerialArrayRangeWriteBarrier inherits from ArrayRangeWriteBarrier class ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/SerialArrayRangeWriteBarrier.java Changeset: 8e5cda9d9c24 Author: Christos Kotselidis Date: 2013-06-27 11:32 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/8e5cda9d9c24 Introduce G1 Array Range Barrier Nodes + graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/G1ArrayRangePostWriteBarrier.java + graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/G1ArrayRangePreWriteBarrier.java Changeset: 1b3cba00f3dd Author: Christos Kotselidis Date: 2013-06-27 11:37 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/1b3cba00f3dd Fix Checkstyle errors ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/ArrayRangeWriteBarrier.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/G1ArrayRangePostWriteBarrier.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/G1ArrayRangePreWriteBarrier.java Changeset: ca8efaf18f27 Author: Christos Kotselidis Date: 2013-06-27 11:37 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/ca8efaf18f27 Add ArrayRange Snippets for G1 ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/WriteBarrierSnippets.java Changeset: a75e7e25aedf Author: Christos Kotselidis Date: 2013-06-27 11:39 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/a75e7e25aedf Small refactoring ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/phases/WriteBarrierAdditionPhase.java Changeset: 883a1327f984 Author: Christos Kotselidis Date: 2013-06-27 11:41 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/883a1327f984 Write Barrier Addition Phase adds Array Range Barriers for G1 ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/phases/WriteBarrierAdditionPhase.java Changeset: 9210083b253f Author: Christos Kotselidis Date: 2013-06-27 11:42 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/9210083b253f Lower G1 Array Range Barriers ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotRuntime.java Changeset: 35783fbfcf28 Author: Christos Kotselidis Date: 2013-06-27 11:44 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/35783fbfcf28 Augment comments ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotRuntime.java Changeset: c636b4399ffa Author: Christos Kotselidis Date: 2013-06-27 21:03 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/c636b4399ffa Merge Changeset: 9d3265486aad Author: Thomas Wuerthinger Date: 2013-06-27 14:15 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/9d3265486aad Fix for new warnings showing up when using Kepler eclipse. ! graal/com.oracle.graal.jtt/src/com/oracle/graal/jtt/bytecode/BC_newarray.java ! graal/com.oracle.graal.jtt/src/com/oracle/graal/jtt/except/BC_newarray.java Changeset: ea02ae30c97c Author: Thomas Wuerthinger Date: 2013-06-27 15:14 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/ea02ae30c97c Use correct parameters for readUnsafeConstant. ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotResolvedJavaField.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotRuntime.java Changeset: 0b1b5356b566 Author: Thomas Wuerthinger Date: 2013-06-27 21:20 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/0b1b5356b566 Fixed issues around execute compiled code stub. Made TraceDeoptimization a product flag. ! src/cpu/x86/vm/sharedRuntime_x86_64.cpp ! src/share/vm/code/nmethod.cpp ! src/share/vm/runtime/globals.hpp Changeset: 60ce5bd6e104 Author: Thomas Wuerthinger Date: 2013-06-27 21:47 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/60ce5bd6e104 Merge. ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotRuntime.java Changeset: 12d134c0aa8d Author: Thomas Wuerthinger Date: 2013-06-27 22:00 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/12d134c0aa8d Remove suppress warnings. ! graal/com.oracle.graal.jtt/src/com/oracle/graal/jtt/bytecode/BC_newarray.java ! graal/com.oracle.graal.jtt/src/com/oracle/graal/jtt/except/BC_newarray.java Changeset: 7a3499bf5e2c Author: Morris Meyer Date: 2013-06-27 19:22 -0400 URL: http://hg.openjdk.java.net/graal/graal/rev/7a3499bf5e2c PTX kernel get_function return ! src/gpu/ptx/gpu_ptx.cpp ! src/gpu/ptx/gpu_ptx.hpp ! src/share/vm/graal/graalCompilerToGPU.cpp Changeset: 1b864a1552e0 Author: Morris Meyer Date: 2013-06-27 19:24 -0400 URL: http://hg.openjdk.java.net/graal/graal/rev/1b864a1552e0 SPARCAssembler Fmt3p upgrade ! graal/com.oracle.graal.asm.sparc/src/com/oracle/graal/asm/sparc/SPARCAssembler.java ! graal/com.oracle.graal.lir.sparc/src/com/oracle/graal/lir/sparc/SPARCArithmetic.java ! graal/com.oracle.graal.lir.sparc/src/com/oracle/graal/lir/sparc/SPARCMathIntrinsicOp.java Changeset: 52d5ade44b59 Author: Morris Meyer Date: 2013-06-27 19:30 -0400 URL: http://hg.openjdk.java.net/graal/graal/rev/52d5ade44b59 Fix SPARC unused annotations ! 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/SPARCMathIntrinsicOp.java Changeset: a6632ef9c84d Author: Morris Meyer Date: 2013-06-27 19:57 -0400 URL: http://hg.openjdk.java.net/graal/graal/rev/a6632ef9c84d GPU generate_kernel return for Cuda function ! src/gpu/ptx/gpu_ptx.cpp ! src/share/vm/runtime/gpu.hpp Changeset: 7cd21876c116 Author: twisti Date: 2013-06-27 22:18 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/7cd21876c116 Revert bytecode indexes back to Java endianess. ! src/share/vm/graal/graalCompiler.hpp ! src/share/vm/graal/graalCompilerToVM.cpp Changeset: 070b4a3c56f3 Author: Doug Simon Date: 2013-06-28 11:02 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/070b4a3c56f3 disabled "noisy" log statements unless -v option (i.e. verbose) is specified to mx ! mx/commands.py ! mxtool/mx.py Changeset: 6b9ebfcf5fc5 Author: Lukas Stadler Date: 2013-06-28 15:32 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/6b9ebfcf5fc5 make BoxNode and UnboxNode floating ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotRuntime.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/src/com/oracle/graal/replacements/BoxingSnippets.java ! graal/com.oracle.graal.replacements/src/com/oracle/graal/replacements/NodeIntrinsificationPhase.java Changeset: 2f80624df8a2 Author: Gilles Duboscq Date: 2013-06-28 16:36 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/2f80624df8a2 Add a --vmdir argument to mx ! mx/commands.py Changeset: e376b764fdc7 Author: Doug Simon Date: 2013-06-28 17:00 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/e376b764fdc7 fixed non-product builds of the VM for jdk7_25 ! src/share/vm/prims/jvm.cpp Changeset: ef7490090dbf Author: Doug Simon Date: 2013-06-28 17:00 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/ef7490090dbf added annotation to suppress warnings for Eclipse kepler and juno ! graal/com.oracle.graal.jtt/src/com/oracle/graal/jtt/bytecode/BC_newarray.java ! graal/com.oracle.graal.jtt/src/com/oracle/graal/jtt/except/BC_newarray.java Changeset: ee1b82e8c1f4 Author: Doug Simon Date: 2013-06-28 17:33 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/ee1b82e8c1f4 Merge. Changeset: 0cad5096735e Author: Gilles Duboscq Date: 2013-06-28 19:11 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/0cad5096735e commands.py: Make sure _jdk returns an absolute path. Use _jdk and _jdksDir where necessary ! mx/commands.py Changeset: 97d280a879ff Author: Bernhard Urban Date: 2013-06-20 14:25 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/97d280a879ff ShiftNode: add constant with correct stamp in canonical() + graal/com.oracle.graal.jtt/src/com/oracle/graal/jtt/optimize/InferStamp01.java + graal/com.oracle.graal.jtt/src/com/oracle/graal/jtt/optimize/LongToSomethingArray01.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/RightShiftNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/calc/UnsignedRightShiftNode.java Changeset: aee899c96b0b Author: Doug Simon Date: 2013-06-29 11:40 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/aee899c96b0b distribution jars (e.g., graal.jar) now contain library dependencies ! mxtool/mx.py