From doug.simon at oracle.com  Mon Jul  1 02:11:53 2013
From: doug.simon at oracle.com (Doug Simon)
Date: Mon, 1 Jul 2013 11:11:53 +0200
Subject: TruffleSOM: A Smalltalk implemented with Truffle
In-Reply-To: <F689F796-B077-4555-BCDB-871D1EE409F3@stefan-marr.de>
References: <F689F796-B077-4555-BCDB-871D1EE409F3@stefan-marr.de>
Message-ID: <C34E5C78-AF8B-4F57-B77E-D6A548603384@oracle.com>

Hi Stefan,

What is the git command line I need to use to clone the TruffleSOM repository? When I run:

git clone https://github.com/smarr/som-java.git

I don't get the TruffleSOM sources browsable at https://github.com/smarr/som-java/tree

-Doug

On Jun 28, 2013, at 3:23 PM, Stefan Marr <java at stefan-marr.de> wrote:

> 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 java at stefan-marr.de  Mon Jul  1 02:27:48 2013
From: java at stefan-marr.de (Stefan Marr)
Date: Mon, 1 Jul 2013 11:27:48 +0200
Subject: TruffleSOM: A Smalltalk implemented with Truffle
In-Reply-To: <C34E5C78-AF8B-4F57-B77E-D6A548603384@oracle.com>
References: <F689F796-B077-4555-BCDB-871D1EE409F3@stefan-marr.de>
	<C34E5C78-AF8B-4F57-B77E-D6A548603384@oracle.com>
Message-ID: <08DD7C4B-F9B1-47C4-9733-1752175D704E@stefan-marr.de>

Hi Doug:

On 01 Jul 2013, at 11:11, Doug Simon <doug.simon at oracle.com> wrote:

> What is the git command line I need to use to clone the TruffleSOM repository?

Yes, sorry, not very user friendly. Apparently it is:

  git clone https://github.com/smarr/som-java.git --branch TruffleSOM/master TruffleSOM

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 tom.deneau at amd.com  Mon Jul  1 09:49:01 2013
From: tom.deneau at amd.com (Deneau, Tom)
Date: Mon, 1 Jul 2013 16:49:01 +0000
Subject: [Sw.runtimes] final graal HSAIL support patch
In-Reply-To: <B53F5649-CC90-432C-8527-C3416F9EA1C9@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>
	<BC97738F8E7C8742BABED7F06FB9DF9145030C3C@sausexdag01.amd.com>
	<DD023186-CD16-47CA-B153-B4BC7F78CFB3@oracle.com>
	<BC97738F8E7C8742BABED7F06FB9DF9145030C9C@sausexdag01.amd.com>
	<A66BBEFB-ADA6-44A5-BA53-E61E8BC6B839@oracle.com>
	<BC97738F8E7C8742BABED7F06FB9DF914503535A@sausexdag01.amd.com>
	<B53F5649-CC90-432C-8527-C3416F9EA1C9@oracle.com>
Message-ID: <BC97738F8E7C8742BABED7F06FB9DF91450364E0@sausexdag01.amd.com>

Thanks, Doug.
I have confirmed that this works fine and removes the need to use -Xbootclasspath

-- Tom


-----Original Message-----
From: Doug Simon [mailto:doug.simon at oracle.com] 
Sent: Saturday, June 29, 2013 5:20 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

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" <tom.deneau at amd.com> 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" <tom.deneau at amd.com> 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-<version>.jar solution is the best one moving forward. The <version> 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-<version>.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" <tom.deneau at amd.com> 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 <thomas.wuerthinger at oracle.com> 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 <christian.thalinger at oracle.com> wrote:
>>>> 
>>>>> 
>>>>> On Jun 24, 2013, at 11:13 AM, Christian Thalinger <christian.thalinger at oracle.com> 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" <Vasanth.Venkatachalam at amd.com> 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
>>>>>>> <graal.patch>
>>>>>> 
>>>>> 
>>>> 
>>> 
>>> 
>>> 
>>> 
>> 
>> 
>> 
> 
> 
> 




From tom.deneau at amd.com  Mon Jul  1 11:11:52 2013
From: tom.deneau at amd.com (Deneau, Tom)
Date: Mon, 1 Jul 2013 18:11:52 +0000
Subject: compressed oops and stack slots
Message-ID: <BC97738F8E7C8742BABED7F06FB9DF9145036554@sausexdag01.amd.com>

Now that graal supports compressed oops, 
I have been implementing the support for compressed oops in the HSAIL backend.
The basic mechanisms seem to be working and almost all of our test cases pass
with compressedOops off or on (including with a heap that is large enough such
that the compression requires a shift).

However, we have one test case that is failing, it does use spills to stack slots
and I think it is the only one of our tests that has a mixture of 32-bit spills
and 64-bit spills.  (This test works fine with compressedOops off).

With  compressedOops on, we are  hitting the assert in FrameMap.indexForStackSlot
(called from FrameMap.setReference)

    public int indexForStackSlot(StackSlot slot) {
        assert offsetForStackSlot(slot) % target.wordSize == 0;
        return offsetForStackSlot(slot) / target.wordSize;
    }

In our case
   * with +UseCompressedOops , the slot has offset -32, totalFrameSize is 44 so offsetForStackSlot(slot) is 12.
     which fails the assertion since target.wordSize is 8

   * with -UseCompressedOops , the slot has offset -32, totalFrameSize is 40 so offsetForStackSlot(slot) is 8.
     which passes the assertion (target.wordSize is 8)


>From the above information, can you folks tell what I should be doing so that this test works correctly with CompressedOops on?

-- Tom Deneau
   AMD



From tom.deneau at amd.com  Mon Jul  1 12:45:53 2013
From: tom.deneau at amd.com (Deneau, Tom)
Date: Mon, 1 Jul 2013 19:45:53 +0000
Subject: compressed oops and stack slots
In-Reply-To: <BC97738F8E7C8742BABED7F06FB9DF9145036554@sausexdag01.amd.com>
References: <BC97738F8E7C8742BABED7F06FB9DF9145036554@sausexdag01.amd.com>
Message-ID: <BC97738F8E7C8742BABED7F06FB9DF91450365E9@sausexdag01.amd.com>

I noticed our stackAlignment in our targetDescription was 1, setting that to 8 (same as wordsize) solved the problem.
Not sure why this didn't affect us somewhere else.

-- Tom


-----Original Message-----
From: graal-dev-bounces at openjdk.java.net [mailto:graal-dev-bounces at openjdk.java.net] On Behalf Of Deneau, Tom
Sent: Monday, July 01, 2013 1:12 PM
To: graal-dev at openjdk.java.net
Subject: compressed oops and stack slots

Now that graal supports compressed oops, 
I have been implementing the support for compressed oops in the HSAIL backend.
The basic mechanisms seem to be working and almost all of our test cases pass
with compressedOops off or on (including with a heap that is large enough such
that the compression requires a shift).

However, we have one test case that is failing, it does use spills to stack slots
and I think it is the only one of our tests that has a mixture of 32-bit spills
and 64-bit spills.  (This test works fine with compressedOops off).

With  compressedOops on, we are  hitting the assert in FrameMap.indexForStackSlot
(called from FrameMap.setReference)

    public int indexForStackSlot(StackSlot slot) {
        assert offsetForStackSlot(slot) % target.wordSize == 0;
        return offsetForStackSlot(slot) / target.wordSize;
    }

In our case
   * with +UseCompressedOops , the slot has offset -32, totalFrameSize is 44 so offsetForStackSlot(slot) is 12.
     which fails the assertion since target.wordSize is 8

   * with -UseCompressedOops , the slot has offset -32, totalFrameSize is 40 so offsetForStackSlot(slot) is 8.
     which passes the assertion (target.wordSize is 8)


>From the above information, can you folks tell what I should be doing so that this test works correctly with CompressedOops on?

-- Tom Deneau
   AMD





From tom.deneau at amd.com  Mon Jul  1 15:52:04 2013
From: tom.deneau at amd.com (Deneau, Tom)
Date: Mon, 1 Jul 2013 22:52:04 +0000
Subject: HSAIL Simulator open sourced
Message-ID: <BC97738F8E7C8742BABED7F06FB9DF91450366AD@sausexdag01.amd.com>

I am pleased to announce that the HSA Foundation has open sourced the
following projects:

    * libHSAIL (tools for parsing, assembling and disassembling HSAIL)
    * an HSAIL Instruction Set Simulator
    * OKRA interface to the HSAIL Simulator

The following wiki page goes into detail of how to build the simulator
and describes some tests that can be run against it, including tests that
use the graal HSAIL backend patch which is currently under review.

https://wiki.openjdk.java.net/display/Sumatra/The+HSAIL+Simulator

-- Tom Deneau, AMD




From tom.deneau at amd.com  Tue Jul  2 09:52:51 2013
From: tom.deneau at amd.com (Deneau, Tom)
Date: Tue, 2 Jul 2013 16:52:51 +0000
Subject: mx igv  or mx gv commands
Message-ID: <BC97738F8E7C8742BABED7F06FB9DF9145036996@sausexdag01.amd.com>

When I try to use
   mx igv &

as described on the wiki page, I get the splash screen for the visualize but then it dies.
Similarly with mx gv &

Is there some other command that must be run first before using these?

-- Tom


From tom.deneau at amd.com  Tue Jul  2 11:01:42 2013
From: tom.deneau at amd.com (Deneau, Tom)
Date: Tue, 2 Jul 2013 18:01:42 +0000
Subject: EmitDeoptimize, EmitForignCall "createOutOfBoundsException"
In-Reply-To: <BC97738F8E7C8742BABED7F06FB9DF9145036996@sausexdag01.amd.com>
References: <BC97738F8E7C8742BABED7F06FB9DF9145036996@sausexdag01.amd.com>
Message-ID: <BC97738F8E7C8742BABED7F06FB9DF91450369E3@sausexdag01.amd.com>

Here is the background for my visualizer question:

We have a junit test (part of the webrev) called StaticNBodyTest and the HSAIL backend is able
to compile the fairly large run method without problem.

Now to test inlining decisions, I moved the logic to a separate updateBody method, and had the
run method (the target of the compile) call the updateBody method.  By default, updateBody has too
many nodes to be inlined, but I raised the MaximumInliningSize and now graal does indeed inline it.

With the inlining completed, the HSAILLirGenerator is now passed several emitForeignCall requests
with the target being "createOutOfBoundsException".  Yet in the original StaticNBodyTest (same code,
just not behind a second layer of method call), there were no emitForeignCall requests.
Instead there were emitDeoptimize requests for the path taken when an array index was out of bounds.

Question 1: Why would there be emitDeoptimize in one case, and emitForeignCall after inlining?

As a followup question...

We have not decided how to handle exceptions yet in the HSAIL backend, so the emitDeoptimize request
is turned into a request to return early from the HSAIL kernel.   With this strategy, code generation
completes.

However, if I use similar logic with the emitForeignCall request, i.e. just generate a return,
or even just ignore the ForeignCall request completely, I hit the following error later in the codegen:

java.lang.AssertionError: using fixed register that is not defined in this block
	at com.oracle.graal.compiler.alloc.LinearScan.verifyInput(LinearScan.java:791)

Question 2: Why would this register assertion occur when emitForeignCall is replaced by a return, but not when emitDeoptimize
is similarly replaced by a return?

-- Tom Deneau




-----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, July 02, 2013 11:53 AM
To: graal-dev at openjdk.java.net
Subject: mx igv or mx gv commands

When I try to use
   mx igv &

as described on the wiki page, I get the splash screen for the visualize but then it dies.
Similarly with mx gv &

Is there some other command that must be run first before using these?

-- Tom




From s1255753 at sms.ed.ac.uk  Tue Jul  2 12:36:15 2013
From: s1255753 at sms.ed.ac.uk (ATKIN-GRANVILLE Chris)
Date: Tue, 2 Jul 2013 19:36:15 +0000
Subject: NullPointerException in HotSpotRuntime:lower when using Snippets
Message-ID: <72C1FE55-E500-47DA-B5DE-831AB7119F3F@sms.ed.ac.uk>

Hi there,

I'm trying add arbitrary behaviour to array accesses - the end goal being to create traces of all memory operations within a program. What I've done so far was suggested to me in a previous thread on this list, but in short, I've got phases that add my own custom nodes to each LoadIndexedNode/StoreIndexedNode. These are then lowered to the desired behaviour via snippets:

public class InstrumentationSnippets implements Snippets {
	@Snippet
	public static void store(final ArrayStoreBehaviourNode<?> node) {
		Instrument.arrayStores.add(node.getInfo());
	}
	
	@Snippet
	public static void load(final ArrayLoadBehaviourNode<?> node) {
		Instrument.arrayLoads.add(node.getInfo());
	}
	
	public static class Templates extends AbstractTemplates {
		private final SnippetInfo store = snippet(InstrumentationSnippets.class, "store");
		private final SnippetInfo load = snippet(InstrumentationSnippets.class, "load");

		public Templates(MetaAccessProvider runtime, Replacements replacements, TargetDescription target) {
			super(runtime, replacements, target);
		}
		
		public void lower(final ArrayStoreBehaviourNode<?> node) {
			Arguments args = new Arguments(store);
			args.add("node", node);
			
			template(args).instantiate(runtime, node, DEFAULT_REPLACER, args);
		}
		
		public void lower(final ArrayLoadBehaviourNode<?> node) {
			Arguments args = new Arguments(load);
			args.add("node", node);
			
			template(args).instantiate(runtime, node, DEFAULT_REPLACER, args);
		}
	}
}

However, doing this causes NullPointerExceptions to be thrown in HotSpotRuntime:lower:

java.lang.NullPointerException
	at com.oracle.graal.hotspot.meta.HotSpotRuntime.lower(HotSpotRuntime.java:527)
	at com.oracle.graal.hotspot.amd64.AMD64HotSpotRuntime.lower(AMD64HotSpotRuntime.java:218)
	at com.oracle.graal.nodes.InvokeNode.lower(InvokeNode.java:97)
	at com.oracle.graal.phases.common.LoweringPhase$Round.process(LoweringPhase.java:232)
	at com.oracle.graal.phases.common.LoweringPhase$Round.processBlock(LoweringPhase.java:182)
	at com.oracle.graal.phases.common.LoweringPhase$Round.run(LoweringPhase.java:173)
	at com.oracle.graal.phases.Phase.run(Phase.java:51)
	at com.oracle.graal.phases.BasePhase$1.run(BasePhase.java:62)
	at com.oracle.graal.debug.internal.DebugScope.executeScope(DebugScope.java:179)
	at com.oracle.graal.debug.internal.DebugScope.scope(DebugScope.java:167)
	at com.oracle.graal.debug.Debug.scope(Debug.java:118)
	at com.oracle.graal.debug.Debug.scope(Debug.java:113)
	at com.oracle.graal.phases.BasePhase.apply(BasePhase.java:59)
	at com.oracle.graal.phases.BasePhase.apply(BasePhase.java:55)
	at com.oracle.graal.phases.PhaseSuite.run(PhaseSuite.java:59)
	at com.oracle.graal.phases.common.IncrementalCanonicalizerPhase.run(IncrementalCanonicalizerPhase.java:45)
	at com.oracle.graal.phases.common.IncrementalCanonicalizerPhase.run(IncrementalCanonicalizerPhase.java:1)
	at com.oracle.graal.phases.BasePhase$1.run(BasePhase.java:62)
	at com.oracle.graal.debug.internal.DebugScope.executeScope(DebugScope.java:179)
	at com.oracle.graal.debug.internal.DebugScope.scope(DebugScope.java:167)
	at com.oracle.graal.debug.Debug.scope(Debug.java:118)
	at com.oracle.graal.debug.Debug.scope(Debug.java:113)
	at com.oracle.graal.phases.BasePhase.apply(BasePhase.java:59)
	at com.oracle.graal.phases.BasePhase.apply(BasePhase.java:55)
	at com.oracle.graal.phases.common.LoweringPhase.run(LoweringPhase.java:145)
	at com.oracle.graal.phases.common.LoweringPhase.run(LoweringPhase.java:1)
	at com.oracle.graal.phases.BasePhase$1.run(BasePhase.java:62)
	at com.oracle.graal.debug.internal.DebugScope.executeScope(DebugScope.java:179)
	at com.oracle.graal.debug.internal.DebugScope.scope(DebugScope.java:167)
	at com.oracle.graal.debug.Debug.scope(Debug.java:118)
	at com.oracle.graal.debug.Debug.scope(Debug.java:113)
	at com.oracle.graal.phases.BasePhase.apply(BasePhase.java:59)
	at com.oracle.graal.phases.BasePhase.apply(BasePhase.java:55)
	at com.oracle.graal.compiler.GraalCompiler.emitHIR(GraalCompiler.java:143)
	at com.oracle.graal.compiler.GraalCompiler$1$1.call(GraalCompiler.java:66)
	at com.oracle.graal.compiler.GraalCompiler$1$1.call(GraalCompiler.java:1)
	at com.oracle.graal.debug.internal.DebugScope.call(DebugScope.java:301)
	at com.oracle.graal.debug.internal.DebugScope.executeScope(DebugScope.java:182)
	at com.oracle.graal.debug.internal.DebugScope.scope(DebugScope.java:167)
	at com.oracle.graal.debug.Debug.scope(Debug.java:138)
	at com.oracle.graal.debug.Debug.scope(Debug.java:109)
	at com.oracle.graal.compiler.GraalCompiler$1.run(GraalCompiler.java:63)
	at com.oracle.graal.debug.internal.DebugScope.executeScope(DebugScope.java:179)
	at com.oracle.graal.debug.internal.DebugScope.scope(DebugScope.java:167)
	at com.oracle.graal.debug.Debug.scope(Debug.java:118)
	at com.oracle.graal.compiler.GraalCompiler.compileMethod(GraalCompiler.java:59)
	at uk.ac.ed.inf.icsa.locomotion.Locomotion.compile(Locomotion.java:79)
	at uk.ac.ed.inf.icsa.locomotion.Application.run(Application.java:34)
	at uk.ac.ed.inf.icsa.locomotion.Application.main(Application.java:58)

Following the stack trace leads to this line being the problem:

!callTarget.isStatic() && receiver.kind() == Kind.Object && !receiver.objectStamp().nonNull()

Specifically, receiver == null causes the exception.

Does anyone have any ideas of how I can get around this problem? Ideally without modifying HotSpotRuntime, but if that's whats required then so be it.

chris

-- 
The University of Edinburgh is a charitable body, registered in
Scotland, with registration number SC005336.


From christian.thalinger at oracle.com  Tue Jul  2 13:49:24 2013
From: christian.thalinger at oracle.com (Christian Thalinger)
Date: Tue, 2 Jul 2013 13:49:24 -0700
Subject: mx igv  or mx gv commands
In-Reply-To: <BC97738F8E7C8742BABED7F06FB9DF9145036996@sausexdag01.amd.com>
References: <BC97738F8E7C8742BABED7F06FB9DF9145036996@sausexdag01.amd.com>
Message-ID: <28C69BE9-B26E-4F31-9854-EDDE40F69B6C@oracle.com>

Which Java version are you using?  8 makes it crash, 7 should work.

-- Chris

On Jul 2, 2013, at 9:52 AM, "Deneau, Tom" <tom.deneau at amd.com> wrote:

> When I try to use
>   mx igv &
> 
> as described on the wiki page, I get the splash screen for the visualize but then it dies.
> Similarly with mx gv &
> 
> Is there some other command that must be run first before using these?
> 
> -- Tom
> 


From tom.deneau at amd.com  Tue Jul  2 13:50:30 2013
From: tom.deneau at amd.com (Deneau, Tom)
Date: Tue, 2 Jul 2013 20:50:30 +0000
Subject: mx igv  or mx gv commands
In-Reply-To: <28C69BE9-B26E-4F31-9854-EDDE40F69B6C@oracle.com>
References: <BC97738F8E7C8742BABED7F06FB9DF9145036996@sausexdag01.amd.com>
	<28C69BE9-B26E-4F31-9854-EDDE40F69B6C@oracle.com>
Message-ID: <BC97738F8E7C8742BABED7F06FB9DF9145036AFB@sausexdag01.amd.com>

ah,  it was 8.  I will back up to 7.

-----Original Message-----
From: Christian Thalinger [mailto:christian.thalinger at oracle.com] 
Sent: Tuesday, July 02, 2013 3:49 PM
To: Deneau, Tom
Cc: graal-dev at openjdk.java.net
Subject: Re: mx igv or mx gv commands

Which Java version are you using?  8 makes it crash, 7 should work.

-- Chris

On Jul 2, 2013, at 9:52 AM, "Deneau, Tom" <tom.deneau at amd.com> wrote:

> When I try to use
>   mx igv &
> 
> as described on the wiki page, I get the splash screen for the visualize but then it dies.
> Similarly with mx gv &
> 
> Is there some other command that must be run first before using these?
> 
> -- Tom
> 




From tom.deneau at amd.com  Tue Jul  2 14:56:30 2013
From: tom.deneau at amd.com (Deneau, Tom)
Date: Tue, 2 Jul 2013 21:56:30 +0000
Subject: mx igv  or mx gv commands
In-Reply-To: <28C69BE9-B26E-4F31-9854-EDDE40F69B6C@oracle.com>
References: <BC97738F8E7C8742BABED7F06FB9DF9145036996@sausexdag01.amd.com>
	<28C69BE9-B26E-4F31-9854-EDDE40F69B6C@oracle.com>
Message-ID: <BC97738F8E7C8742BABED7F06FB9DF9145036B50@sausexdag01.amd.com>

Christian --

What actual command lines should be used to view the graphs for an HSAIL compilation?
Note that we typically run using --vm server.
I would ask Vasanth but he is off this week.

-- Tom


-----Original Message-----
From: Christian Thalinger [mailto:christian.thalinger at oracle.com] 
Sent: Tuesday, July 02, 2013 3:49 PM
To: Deneau, Tom
Cc: graal-dev at openjdk.java.net
Subject: Re: mx igv or mx gv commands

Which Java version are you using?  8 makes it crash, 7 should work.

-- Chris

On Jul 2, 2013, at 9:52 AM, "Deneau, Tom" <tom.deneau at amd.com> wrote:

> When I try to use
>   mx igv &
> 
> as described on the wiki page, I get the splash screen for the visualize but then it dies.
> Similarly with mx gv &
> 
> Is there some other command that must be run first before using these?
> 
> -- Tom
> 




From christian.thalinger at oracle.com  Tue Jul  2 15:42:02 2013
From: christian.thalinger at oracle.com (Christian Thalinger)
Date: Tue, 2 Jul 2013 15:42:02 -0700
Subject: mx igv  or mx gv commands
In-Reply-To: <BC97738F8E7C8742BABED7F06FB9DF9145036B50@sausexdag01.amd.com>
References: <BC97738F8E7C8742BABED7F06FB9DF9145036996@sausexdag01.amd.com>
	<28C69BE9-B26E-4F31-9854-EDDE40F69B6C@oracle.com>
	<BC97738F8E7C8742BABED7F06FB9DF9145036B50@sausexdag01.amd.com>
Message-ID: <CE16E6D1-F406-4A4C-BFA4-9D69FA73D614@oracle.com>


On Jul 2, 2013, at 2:56 PM, "Deneau, Tom" <tom.deneau at amd.com> wrote:

> Christian --
> 
> What actual command lines should be used to view the graphs for an HSAIL compilation?

-G:Dump=

You can also use a method filter to only show what you want:

-G:MethodFilter=HashMap.put

It works when running a test inside Eclipse.

-- Chris

> Note that we typically run using --vm server.
> I would ask Vasanth but he is off this week.
> 
> -- Tom
> 
> 
> -----Original Message-----
> From: Christian Thalinger [mailto:christian.thalinger at oracle.com] 
> Sent: Tuesday, July 02, 2013 3:49 PM
> To: Deneau, Tom
> Cc: graal-dev at openjdk.java.net
> Subject: Re: mx igv or mx gv commands
> 
> Which Java version are you using?  8 makes it crash, 7 should work.
> 
> -- Chris
> 
> On Jul 2, 2013, at 9:52 AM, "Deneau, Tom" <tom.deneau at amd.com> wrote:
> 
>> When I try to use
>>  mx igv &
>> 
>> as described on the wiki page, I get the splash screen for the visualize but then it dies.
>> Similarly with mx gv &
>> 
>> Is there some other command that must be run first before using these?
>> 
>> -- Tom
>> 
> 
> 
> 


From duboscq at ssw.jku.at  Tue Jul  2 16:01:20 2013
From: duboscq at ssw.jku.at (Gilles Duboscq)
Date: Wed, 3 Jul 2013 01:01:20 +0200
Subject: mx igv or mx gv commands
In-Reply-To: <CE16E6D1-F406-4A4C-BFA4-9D69FA73D614@oracle.com>
References: <BC97738F8E7C8742BABED7F06FB9DF9145036996@sausexdag01.amd.com>
	<28C69BE9-B26E-4F31-9854-EDDE40F69B6C@oracle.com>
	<BC97738F8E7C8742BABED7F06FB9DF9145036B50@sausexdag01.amd.com>
	<CE16E6D1-F406-4A4C-BFA4-9D69FA73D614@oracle.com>
Message-ID: <CAGjk+z9zTozciBbfiaMwKMEg4yNvXQuv1mN9hWdNfFaVL04aQw@mail.gmail.com>

Which window manager do you use? I know that igv (netbeans) refuses to
start with some window managers


On Wed, Jul 3, 2013 at 12:42 AM, Christian Thalinger <
christian.thalinger at oracle.com> wrote:

>
> On Jul 2, 2013, at 2:56 PM, "Deneau, Tom" <tom.deneau at amd.com> wrote:
>
> > Christian --
> >
> > What actual command lines should be used to view the graphs for an HSAIL
> compilation?
>
> -G:Dump=
>
> You can also use a method filter to only show what you want:
>
> -G:MethodFilter=HashMap.put
>
> It works when running a test inside Eclipse.
>
> -- Chris
>
> > Note that we typically run using --vm server.
> > I would ask Vasanth but he is off this week.
> >
> > -- Tom
> >
> >
> > -----Original Message-----
> > From: Christian Thalinger [mailto:christian.thalinger at oracle.com]
> > Sent: Tuesday, July 02, 2013 3:49 PM
> > To: Deneau, Tom
> > Cc: graal-dev at openjdk.java.net
> > Subject: Re: mx igv or mx gv commands
> >
> > Which Java version are you using?  8 makes it crash, 7 should work.
> >
> > -- Chris
> >
> > On Jul 2, 2013, at 9:52 AM, "Deneau, Tom" <tom.deneau at amd.com> wrote:
> >
> >> When I try to use
> >>  mx igv &
> >>
> >> as described on the wiki page, I get the splash screen for the
> visualize but then it dies.
> >> Similarly with mx gv &
> >>
> >> Is there some other command that must be run first before using these?
> >>
> >> -- Tom
> >>
> >
> >
> >
>
>

From tom.deneau at amd.com  Tue Jul  2 16:16:40 2013
From: tom.deneau at amd.com (Deneau, Tom)
Date: Tue, 2 Jul 2013 23:16:40 +0000
Subject: mx igv or mx gv commands
In-Reply-To: <CAGjk+z9zTozciBbfiaMwKMEg4yNvXQuv1mN9hWdNfFaVL04aQw@mail.gmail.com>
References: <BC97738F8E7C8742BABED7F06FB9DF9145036996@sausexdag01.amd.com>
	<28C69BE9-B26E-4F31-9854-EDDE40F69B6C@oracle.com>
	<BC97738F8E7C8742BABED7F06FB9DF9145036B50@sausexdag01.amd.com>
	<CE16E6D1-F406-4A4C-BFA4-9D69FA73D614@oracle.com>
	<CAGjk+z9zTozciBbfiaMwKMEg4yNvXQuv1mN9hWdNfFaVL04aQw@mail.gmail.com>
Message-ID: <BC97738F8E7C8742BABED7F06FB9DF9145036C18@sausexdag01.amd.com>

I do see igv starting and waiting but it's not capturing anything.
My command line (after starting igv) is 

./mx.sh --vm server unittest @-G:-RemoveNeverExecutedCode @-G:Log=InliningDecisions  @-G:+HotSpotPrintInlining -G:Dump= -G:MethodFilter=com.oracle.graal.compiler.hsail.test.StaticNBodyCallTest.run --J @-Xmx1g @-Xms1g --J @-Dsun.boot.library.path=$LD_LIBRARY_PATH   hsail.test.StaticNBodyCallTest 

-- Tom


From: gilwooden at gmail.com [mailto:gilwooden at gmail.com] On Behalf Of Gilles Duboscq
Sent: Tuesday, July 02, 2013 6:01 PM
To: Christian Thalinger
Cc: Deneau, Tom; graal-dev at openjdk.java.net
Subject: Re: mx igv or mx gv commands

Which window manager do you use? I know that igv (netbeans) refuses to start with some window managers

On Wed, Jul 3, 2013 at 12:42 AM, Christian Thalinger <christian.thalinger at oracle.com> wrote:

On Jul 2, 2013, at 2:56 PM, "Deneau, Tom" <tom.deneau at amd.com> wrote:

> Christian --
>
> What actual command lines should be used to view the graphs for an HSAIL compilation?
-G:Dump=

You can also use a method filter to only show what you want:

-G:MethodFilter=HashMap.put

It works when running a test inside Eclipse.

-- Chris

> Note that we typically run using --vm server.
> I would ask Vasanth but he is off this week.
>
> -- Tom
>
>
> -----Original Message-----
> From: Christian Thalinger [mailto:christian.thalinger at oracle.com]
> Sent: Tuesday, July 02, 2013 3:49 PM
> To: Deneau, Tom
> Cc: graal-dev at openjdk.java.net
> Subject: Re: mx igv or mx gv commands
>
> Which Java version are you using? ?8 makes it crash, 7 should work.
>
> -- Chris
>
> On Jul 2, 2013, at 9:52 AM, "Deneau, Tom" <tom.deneau at amd.com> wrote:
>
>> When I try to use
>> ?mx igv &
>>
>> as described on the wiki page, I get the splash screen for the visualize but then it dies.
>> Similarly with mx gv &
>>
>> Is there some other command that must be run first before using these?
>>
>> -- Tom
>>
>
>
>


From christian.thalinger at oracle.com  Tue Jul  2 16:25:11 2013
From: christian.thalinger at oracle.com (Christian Thalinger)
Date: Tue, 2 Jul 2013 16:25:11 -0700
Subject: mx igv or mx gv commands
In-Reply-To: <BC97738F8E7C8742BABED7F06FB9DF9145036C18@sausexdag01.amd.com>
References: <BC97738F8E7C8742BABED7F06FB9DF9145036996@sausexdag01.amd.com>
	<28C69BE9-B26E-4F31-9854-EDDE40F69B6C@oracle.com>
	<BC97738F8E7C8742BABED7F06FB9DF9145036B50@sausexdag01.amd.com>
	<CE16E6D1-F406-4A4C-BFA4-9D69FA73D614@oracle.com>
	<CAGjk+z9zTozciBbfiaMwKMEg4yNvXQuv1mN9hWdNfFaVL04aQw@mail.gmail.com>
	<BC97738F8E7C8742BABED7F06FB9DF9145036C18@sausexdag01.amd.com>
Message-ID: <40F34CA5-F8B2-4DD3-A92E-4E6778747CC0@oracle.com>


On Jul 2, 2013, at 4:16 PM, "Deneau, Tom" <tom.deneau at amd.com> wrote:

> I do see igv starting and waiting but it's not capturing anything.
> My command line (after starting igv) is 
> 
> ./mx.sh --vm server unittest @-G:-RemoveNeverExecutedCode @-G:Log=InliningDecisions  @-G:+HotSpotPrintInlining -G:Dump= -G:MethodFilter=com.oracle.graal.compiler.hsail.test.StaticNBodyCallTest.run --J @-Xmx1g @-Xms1g --J @-Dsun.boot.library.path=$LD_LIBRARY_PATH   hsail.test.StaticNBodyCallTest 

@-G:Dump= ?

-- Chris

> 
> -- Tom
> 
> 
> From: gilwooden at gmail.com [mailto:gilwooden at gmail.com] On Behalf Of Gilles Duboscq
> Sent: Tuesday, July 02, 2013 6:01 PM
> To: Christian Thalinger
> Cc: Deneau, Tom; graal-dev at openjdk.java.net
> Subject: Re: mx igv or mx gv commands
> 
> Which window manager do you use? I know that igv (netbeans) refuses to start with some window managers
> 
> On Wed, Jul 3, 2013 at 12:42 AM, Christian Thalinger <christian.thalinger at oracle.com> wrote:
> 
> On Jul 2, 2013, at 2:56 PM, "Deneau, Tom" <tom.deneau at amd.com> wrote:
> 
>> Christian --
>> 
>> What actual command lines should be used to view the graphs for an HSAIL compilation?
> -G:Dump=
> 
> You can also use a method filter to only show what you want:
> 
> -G:MethodFilter=HashMap.put
> 
> It works when running a test inside Eclipse.
> 
> -- Chris
> 
>> Note that we typically run using --vm server.
>> I would ask Vasanth but he is off this week.
>> 
>> -- Tom
>> 
>> 
>> -----Original Message-----
>> From: Christian Thalinger [mailto:christian.thalinger at oracle.com]
>> Sent: Tuesday, July 02, 2013 3:49 PM
>> To: Deneau, Tom
>> Cc: graal-dev at openjdk.java.net
>> Subject: Re: mx igv or mx gv commands
>> 
>> Which Java version are you using?  8 makes it crash, 7 should work.
>> 
>> -- Chris
>> 
>> On Jul 2, 2013, at 9:52 AM, "Deneau, Tom" <tom.deneau at amd.com> wrote:
>> 
>>> When I try to use
>>>  mx igv &
>>> 
>>> as described on the wiki page, I get the splash screen for the visualize but then it dies.
>>> Similarly with mx gv &
>>> 
>>> Is there some other command that must be run first before using these?
>>> 
>>> -- Tom
>>> 
>> 
>> 
>> 
> 


From doug.simon at oracle.com  Tue Jul  2 23:37:25 2013
From: doug.simon at oracle.com (Doug Simon)
Date: Wed, 3 Jul 2013 08:37:25 +0200
Subject: mx igv or mx gv commands
In-Reply-To: <40F34CA5-F8B2-4DD3-A92E-4E6778747CC0@oracle.com>
References: <BC97738F8E7C8742BABED7F06FB9DF9145036996@sausexdag01.amd.com>
	<28C69BE9-B26E-4F31-9854-EDDE40F69B6C@oracle.com>
	<BC97738F8E7C8742BABED7F06FB9DF9145036B50@sausexdag01.amd.com>
	<CE16E6D1-F406-4A4C-BFA4-9D69FA73D614@oracle.com>
	<CAGjk+z9zTozciBbfiaMwKMEg4yNvXQuv1mN9hWdNfFaVL04aQw@mail.gmail.com>
	<BC97738F8E7C8742BABED7F06FB9DF9145036C18@sausexdag01.amd.com>
	<40F34CA5-F8B2-4DD3-A92E-4E6778747CC0@oracle.com>
Message-ID: <0B27773D-C633-416A-A9E4-BBC11860EED5@oracle.com>


On Jul 3, 2013, at 1:25 AM, Christian Thalinger <christian.thalinger at oracle.com> wrote:

> 
> On Jul 2, 2013, at 4:16 PM, "Deneau, Tom" <tom.deneau at amd.com> wrote:
> 
>> I do see igv starting and waiting but it's not capturing anything.
>> My command line (after starting igv) is 
>> 
>> ./mx.sh --vm server unittest @-G:-RemoveNeverExecutedCode @-G:Log=InliningDecisions  @-G:+HotSpotPrintInlining -G:Dump= -G:MethodFilter=com.oracle.graal.compiler.hsail.test.StaticNBodyCallTest.run --J @-Xmx1g @-Xms1g --J @-Dsun.boot.library.path=$LD_LIBRARY_PATH   hsail.test.StaticNBodyCallTest 
> 
> @-G:Dump= ?

Yes, that means "dump everything" since the empty string matches the name of any dump scope.

The problem is that you are missing the '@' prefix in front of some of the options. Also you don't need the '--J' option as all '@' prefixed option are passed to the VM already. Your fixed up command line is:

./mx.sh --vm server unittest @-G:-RemoveNeverExecutedCode @-G:Log=InliningDecisions  @-G:+HotSpotPrintInlining @-G:Dump= @-G:MethodFilter=com.oracle.graal.compiler.hsail.test.StaticNBodyCallTest.run @-Xmx1g @-Xms1g @-Dsun.boot.library.path=$LD_LIBRARY_PATH hsail.test.StaticNBodyCallTest

-Doug

>> From: gilwooden at gmail.com [mailto:gilwooden at gmail.com] On Behalf Of Gilles Duboscq
>> Sent: Tuesday, July 02, 2013 6:01 PM
>> To: Christian Thalinger
>> Cc: Deneau, Tom; graal-dev at openjdk.java.net
>> Subject: Re: mx igv or mx gv commands
>> 
>> Which window manager do you use? I know that igv (netbeans) refuses to start with some window managers
>> 
>> On Wed, Jul 3, 2013 at 12:42 AM, Christian Thalinger <christian.thalinger at oracle.com> wrote:
>> 
>> On Jul 2, 2013, at 2:56 PM, "Deneau, Tom" <tom.deneau at amd.com> wrote:
>> 
>>> Christian --
>>> 
>>> What actual command lines should be used to view the graphs for an HSAIL compilation?
>> -G:Dump=
>> 
>> You can also use a method filter to only show what you want:
>> 
>> -G:MethodFilter=HashMap.put
>> 
>> It works when running a test inside Eclipse.
>> 
>> -- Chris
>> 
>>> Note that we typically run using --vm server.
>>> I would ask Vasanth but he is off this week.
>>> 
>>> -- Tom
>>> 
>>> 
>>> -----Original Message-----
>>> From: Christian Thalinger [mailto:christian.thalinger at oracle.com]
>>> Sent: Tuesday, July 02, 2013 3:49 PM
>>> To: Deneau, Tom
>>> Cc: graal-dev at openjdk.java.net
>>> Subject: Re: mx igv or mx gv commands
>>> 
>>> Which Java version are you using?  8 makes it crash, 7 should work.
>>> 
>>> -- Chris
>>> 
>>> On Jul 2, 2013, at 9:52 AM, "Deneau, Tom" <tom.deneau at amd.com> wrote:
>>> 
>>>> When I try to use
>>>> mx igv &
>>>> 
>>>> as described on the wiki page, I get the splash screen for the visualize but then it dies.
>>>> Similarly with mx gv &
>>>> 
>>>> Is there some other command that must be run first before using these?
>>>> 
>>>> -- Tom
>>>> 
>>> 
>>> 
>>> 
>> 
> 


From duboscq at ssw.jku.at  Wed Jul  3 01:51:18 2013
From: duboscq at ssw.jku.at (Gilles Duboscq)
Date: Wed, 3 Jul 2013 10:51:18 +0200
Subject: EmitDeoptimize, EmitForignCall "createOutOfBoundsException"
In-Reply-To: <BC97738F8E7C8742BABED7F06FB9DF91450369E3@sausexdag01.amd.com>
References: <BC97738F8E7C8742BABED7F06FB9DF9145036996@sausexdag01.amd.com>
	<BC97738F8E7C8742BABED7F06FB9DF91450369E3@sausexdag01.amd.com>
Message-ID: <CAGjk+z8EHkRFQrod8O7zbq5tJDniBxgaYED3+2+WjEuoB6=-iA@mail.gmail.com>

For your first question, the profile seems to be the key: this path through
the "create..." foreign call should only appear if profiling shows that
array out of bounds exceptions are actually thrown at this position.
In this case the exception handling is done in the compiled code: it will
create the exception object with that foreign call and the execution will
be diverted to any  catch handler that the compiler could find.

Otherwise, if profile shows that no exception is thrown, the compiler
assumes it can leave the exception handling out. A deoptimization will be
used to go back to the interpreter if that assumption proved to be
incorrect.

A deoptimization is ? like a return ? a control flow sink, it ends the
execution of the current compilation unit. The foreign call on the other
end is not a control flow sink.
If you replace a foreign call with a return during LIR generation I can see
how later stages such as register allocation can get confused.
In general, it is not a good idea to modify the control flow graph during
LIR generation, many of invariants of the algorithms working on the LIR
will fail.

When compiling for such a target I suppose that you want to stick to
deoptimization to handle cases that are not supported by this execution
environment.
On 2 Jul 2013 20:03, "Tom Deneau" <tom.deneau at amd.com> wrote:

> Here is the background for my visualizer question:
>
> We have a junit test (part of the webrev) called StaticNBodyTest and the
> HSAIL backend is able
> to compile the fairly large run method without problem.
>
> Now to test inlining decisions, I moved the logic to a separate updateBody
> method, and had the
> run method (the target of the compile) call the updateBody method.  By
> default, updateBody has too
> many nodes to be inlined, but I raised the MaximumInliningSize and now
> graal does indeed inline it.
>
> With the inlining completed, the HSAILLirGenerator is now passed several
> emitForeignCall requests
> with the target being "createOutOfBoundsException".  Yet in the original
> StaticNBodyTest (same code,
> just not behind a second layer of method call), there were no
> emitForeignCall requests.
> Instead there were emitDeoptimize requests for the path taken when an
> array index was out of bounds.
>
> Question 1: Why would there be emitDeoptimize in one case, and
> emitForeignCall after inlining?
>
> As a followup question...
>
> We have not decided how to handle exceptions yet in the HSAIL backend, so
> the emitDeoptimize request
> is turned into a request to return early from the HSAIL kernel.   With
> this strategy, code generation
> completes.
>
> However, if I use similar logic with the emitForeignCall request, i.e.
> just generate a return,
> or even just ignore the ForeignCall request completely, I hit the
> following error later in the codegen:
>
> java.lang.AssertionError: using fixed register that is not defined in this
> block
>         at
> com.oracle.graal.compiler.alloc.LinearScan.verifyInput(LinearScan.java:791)
>
> Question 2: Why would this register assertion occur when emitForeignCall
> is replaced by a return, but not when emitDeoptimize
> is similarly replaced by a return?
>
> -- Tom Deneau
>
>
>
>
> -----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, July 02, 2013 11:53 AM
> To: graal-dev at openjdk.java.net
> Subject: mx igv or mx gv commands
>
> When I try to use
>    mx igv &
>
> as described on the wiki page, I get the splash screen for the visualize
> but then it dies.
> Similarly with mx gv &
>
> Is there some other command that must be run first before using these?
>
> -- Tom
>
>
>
>

From s1255753 at sms.ed.ac.uk  Wed Jul  3 05:20:56 2013
From: s1255753 at sms.ed.ac.uk (ATKIN-GRANVILLE Chris)
Date: Wed, 3 Jul 2013 12:20:56 +0000
Subject: NullPointerException in HotSpotRuntime:lower when using Snippets
In-Reply-To: <72C1FE55-E500-47DA-B5DE-831AB7119F3F@sms.ed.ac.uk>
References: <72C1FE55-E500-47DA-B5DE-831AB7119F3F@sms.ed.ac.uk>
Message-ID: <03D2C9DC-4154-477F-8F00-3E8221A3143F@sms.ed.ac.uk>

Perhaps I have to install any methods I call in my snippet into Graal before I can execute them?

On 2 Jul 2013, at 20:36, ATKIN-GRANVILLE Chris <s1255753 at sms.ed.ac.uk> wrote:

> Hi there,
> 
> I'm trying add arbitrary behaviour to array accesses - the end goal being to create traces of all memory operations within a program. What I've done so far was suggested to me in a previous thread on this list, but in short, I've got phases that add my own custom nodes to each LoadIndexedNode/StoreIndexedNode. These are then lowered to the desired behaviour via snippets:
> 
> public class InstrumentationSnippets implements Snippets {
> 	@Snippet
> 	public static void store(final ArrayStoreBehaviourNode<?> node) {
> 		Instrument.arrayStores.add(node.getInfo());
> 	}
> 	
> 	@Snippet
> 	public static void load(final ArrayLoadBehaviourNode<?> node) {
> 		Instrument.arrayLoads.add(node.getInfo());
> 	}
> 	
> 	public static class Templates extends AbstractTemplates {
> 		private final SnippetInfo store = snippet(InstrumentationSnippets.class, "store");
> 		private final SnippetInfo load = snippet(InstrumentationSnippets.class, "load");
> 
> 		public Templates(MetaAccessProvider runtime, Replacements replacements, TargetDescription target) {
> 			super(runtime, replacements, target);
> 		}
> 		
> 		public void lower(final ArrayStoreBehaviourNode<?> node) {
> 			Arguments args = new Arguments(store);
> 			args.add("node", node);
> 			
> 			template(args).instantiate(runtime, node, DEFAULT_REPLACER, args);
> 		}
> 		
> 		public void lower(final ArrayLoadBehaviourNode<?> node) {
> 			Arguments args = new Arguments(load);
> 			args.add("node", node);
> 			
> 			template(args).instantiate(runtime, node, DEFAULT_REPLACER, args);
> 		}
> 	}
> }
> 
> However, doing this causes NullPointerExceptions to be thrown in HotSpotRuntime:lower:
> 
> java.lang.NullPointerException
> 	at com.oracle.graal.hotspot.meta.HotSpotRuntime.lower(HotSpotRuntime.java:527)
> 	at com.oracle.graal.hotspot.amd64.AMD64HotSpotRuntime.lower(AMD64HotSpotRuntime.java:218)
> 	at com.oracle.graal.nodes.InvokeNode.lower(InvokeNode.java:97)
> 	at com.oracle.graal.phases.common.LoweringPhase$Round.process(LoweringPhase.java:232)
> 	at com.oracle.graal.phases.common.LoweringPhase$Round.processBlock(LoweringPhase.java:182)
> 	at com.oracle.graal.phases.common.LoweringPhase$Round.run(LoweringPhase.java:173)
> 	at com.oracle.graal.phases.Phase.run(Phase.java:51)
> 	at com.oracle.graal.phases.BasePhase$1.run(BasePhase.java:62)
> 	at com.oracle.graal.debug.internal.DebugScope.executeScope(DebugScope.java:179)
> 	at com.oracle.graal.debug.internal.DebugScope.scope(DebugScope.java:167)
> 	at com.oracle.graal.debug.Debug.scope(Debug.java:118)
> 	at com.oracle.graal.debug.Debug.scope(Debug.java:113)
> 	at com.oracle.graal.phases.BasePhase.apply(BasePhase.java:59)
> 	at com.oracle.graal.phases.BasePhase.apply(BasePhase.java:55)
> 	at com.oracle.graal.phases.PhaseSuite.run(PhaseSuite.java:59)
> 	at com.oracle.graal.phases.common.IncrementalCanonicalizerPhase.run(IncrementalCanonicalizerPhase.java:45)
> 	at com.oracle.graal.phases.common.IncrementalCanonicalizerPhase.run(IncrementalCanonicalizerPhase.java:1)
> 	at com.oracle.graal.phases.BasePhase$1.run(BasePhase.java:62)
> 	at com.oracle.graal.debug.internal.DebugScope.executeScope(DebugScope.java:179)
> 	at com.oracle.graal.debug.internal.DebugScope.scope(DebugScope.java:167)
> 	at com.oracle.graal.debug.Debug.scope(Debug.java:118)
> 	at com.oracle.graal.debug.Debug.scope(Debug.java:113)
> 	at com.oracle.graal.phases.BasePhase.apply(BasePhase.java:59)
> 	at com.oracle.graal.phases.BasePhase.apply(BasePhase.java:55)
> 	at com.oracle.graal.phases.common.LoweringPhase.run(LoweringPhase.java:145)
> 	at com.oracle.graal.phases.common.LoweringPhase.run(LoweringPhase.java:1)
> 	at com.oracle.graal.phases.BasePhase$1.run(BasePhase.java:62)
> 	at com.oracle.graal.debug.internal.DebugScope.executeScope(DebugScope.java:179)
> 	at com.oracle.graal.debug.internal.DebugScope.scope(DebugScope.java:167)
> 	at com.oracle.graal.debug.Debug.scope(Debug.java:118)
> 	at com.oracle.graal.debug.Debug.scope(Debug.java:113)
> 	at com.oracle.graal.phases.BasePhase.apply(BasePhase.java:59)
> 	at com.oracle.graal.phases.BasePhase.apply(BasePhase.java:55)
> 	at com.oracle.graal.compiler.GraalCompiler.emitHIR(GraalCompiler.java:143)
> 	at com.oracle.graal.compiler.GraalCompiler$1$1.call(GraalCompiler.java:66)
> 	at com.oracle.graal.compiler.GraalCompiler$1$1.call(GraalCompiler.java:1)
> 	at com.oracle.graal.debug.internal.DebugScope.call(DebugScope.java:301)
> 	at com.oracle.graal.debug.internal.DebugScope.executeScope(DebugScope.java:182)
> 	at com.oracle.graal.debug.internal.DebugScope.scope(DebugScope.java:167)
> 	at com.oracle.graal.debug.Debug.scope(Debug.java:138)
> 	at com.oracle.graal.debug.Debug.scope(Debug.java:109)
> 	at com.oracle.graal.compiler.GraalCompiler$1.run(GraalCompiler.java:63)
> 	at com.oracle.graal.debug.internal.DebugScope.executeScope(DebugScope.java:179)
> 	at com.oracle.graal.debug.internal.DebugScope.scope(DebugScope.java:167)
> 	at com.oracle.graal.debug.Debug.scope(Debug.java:118)
> 	at com.oracle.graal.compiler.GraalCompiler.compileMethod(GraalCompiler.java:59)
> 	at uk.ac.ed.inf.icsa.locomotion.Locomotion.compile(Locomotion.java:79)
> 	at uk.ac.ed.inf.icsa.locomotion.Application.run(Application.java:34)
> 	at uk.ac.ed.inf.icsa.locomotion.Application.main(Application.java:58)
> 
> Following the stack trace leads to this line being the problem:
> 
> !callTarget.isStatic() && receiver.kind() == Kind.Object && !receiver.objectStamp().nonNull()
> 
> Specifically, receiver == null causes the exception.
> 
> Does anyone have any ideas of how I can get around this problem? Ideally without modifying HotSpotRuntime, but if that's whats required then so be it.
> 
> chris
> 
> -- 
> The University of Edinburgh is a charitable body, registered in
> Scotland, with registration number SC005336.
> 
> 



-- 
The University of Edinburgh is a charitable body, registered in
Scotland, with registration number SC005336.


From doug.simon at oracle.com  Wed Jul  3 06:53:47 2013
From: doug.simon at oracle.com (Doug Simon)
Date: Wed, 3 Jul 2013 15:53:47 +0200
Subject: NullPointerException in HotSpotRuntime:lower when using Snippets
In-Reply-To: <72C1FE55-E500-47DA-B5DE-831AB7119F3F@sms.ed.ac.uk>
References: <72C1FE55-E500-47DA-B5DE-831AB7119F3F@sms.ed.ac.uk>
Message-ID: <1B56654D-BB65-423B-9558-96254F71132F@oracle.com>


On Jul 2, 2013, at 9:36 PM, ATKIN-GRANVILLE Chris <s1255753 at sms.ed.ac.uk> wrote:

> Hi there,
> 
> I'm trying add arbitrary behaviour to array accesses - the end goal being to create traces of all memory operations within a program. What I've done so far was suggested to me in a previous thread on this list, but in short, I've got phases that add my own custom nodes to each LoadIndexedNode/StoreIndexedNode. These are then lowered to the desired behaviour via snippets:
> 
> public class InstrumentationSnippets implements Snippets {
> 	@Snippet
> 	public static void store(final ArrayStoreBehaviourNode<?> node) {
> 		Instrument.arrayStores.add(node.getInfo());
> 	}
> 	
> 	@Snippet
> 	public static void load(final ArrayLoadBehaviourNode<?> node) {
> 		Instrument.arrayLoads.add(node.getInfo());
> 	}

This doesn't look right, having compiler nodes as parameter types of snippets. The value of a snippet parameter may come from a compiler node when the snippet is instantiated (during lowering) but the snippet sees the "raw" Java type of the value. Assuming ArrayLoadInfo is the type returned by node.getInfo(), you probably want something like this:

@Snippet
public static void load(ArrayLoadInfo info) {
    Instrument.arrayLoads.add(info);
}


> 	public static class Templates extends AbstractTemplates {
> 		private final SnippetInfo store = snippet(InstrumentationSnippets.class, "store");
> 		private final SnippetInfo load = snippet(InstrumentationSnippets.class, "load");
> 
> 		public Templates(MetaAccessProvider runtime, Replacements replacements, TargetDescription target) {
> 			super(runtime, replacements, target);
> 		}
> 		
> 		public void lower(final ArrayStoreBehaviourNode<?> node) {
> 			Arguments args = new Arguments(store);
> 			args.add("node", node);

and replace the above with:

args.add("info", node.getInfo());

-Doug

From tom.deneau at amd.com  Wed Jul  3 07:25:07 2013
From: tom.deneau at amd.com (Deneau, Tom)
Date: Wed, 3 Jul 2013 14:25:07 +0000
Subject: EmitDeoptimize, EmitForignCall "createOutOfBoundsException"
In-Reply-To: <CAGjk+z8EHkRFQrod8O7zbq5tJDniBxgaYED3+2+WjEuoB6=-iA@mail.gmail.com>
References: <BC97738F8E7C8742BABED7F06FB9DF9145036996@sausexdag01.amd.com>
	<BC97738F8E7C8742BABED7F06FB9DF91450369E3@sausexdag01.amd.com>
	<CAGjk+z8EHkRFQrod8O7zbq5tJDniBxgaYED3+2+WjEuoB6=-iA@mail.gmail.com>
Message-ID: <BC97738F8E7C8742BABED7F06FB9DF9145036E2E@sausexdag01.amd.com>

Gilles --

It is strange that profiling would show that out of bounds exceptions were thrown on that path, I am quite sure that such exceptions are not being thrown when this code is run from the java side.  I also don't understand how profiling would show such exceptions in case #2 but not in case #1

case #1, compile this "run" method

    public static void run(float[] inxyz, float[] outxyz, float[] invxyz, float[] outvxyz, int gid) {
         .. fairly large leaf routine, over 300 nodes
     }

case #2, compile this "run" method

    public static void run(float[] inxyz, float[] outxyz, float[] invxyz, float[] outvxyz, int gid) {
          updateBody(inxyz, outxyz, invxyz, outvxyz, gid);
     }

    public static void updateBody(float[] inxyz, float[] outxyz, float[] invxyz, float[] outvxyz, int gid) {
           .. same contents as "run" method in case #1
     }

Your answer about the register allocation invariants with foreign call makes since.  So since we cannot yet handle the foreign call for this target, is there a flag that will force the LIR to emit a Deoptimization node (which we are able to effectively ignore) rather than a foreign call node when the purpose of the foreign call node is to create an OutOfBounds exception?

-- Tom


From: gilwooden at gmail.com [mailto:gilwooden at gmail.com] On Behalf Of Gilles Duboscq
Sent: Wednesday, July 03, 2013 3:51 AM
To: Deneau, Tom
Cc: graal-dev at openjdk.java.net
Subject: Re: EmitDeoptimize, EmitForignCall "createOutOfBoundsException"


For your first question, the profile seems to be the key: this path through the "create..." foreign call should only appear if profiling shows that array out of bounds exceptions are actually thrown at this position.
In this case the exception handling is done in the compiled code: it will create the exception object with that foreign call and the execution will be diverted to any  catch handler that the compiler could find.

Otherwise, if profile shows that no exception is thrown, the compiler assumes it can leave the exception handling out. A deoptimization will be used to go back to the interpreter if that assumption proved to be incorrect.

A deoptimization is ? like a return ? a control flow sink, it ends the execution of the current compilation unit. The foreign call on the other end is not a control flow sink.
If you replace a foreign call with a return during LIR generation I can see how later stages such as register allocation can get confused.
In general, it is not a good idea to modify the control flow graph during LIR generation, many of invariants of the algorithms working on the LIR will fail.

When compiling for such a target I suppose that you want to stick to deoptimization to handle cases that are not supported by this execution environment.
On 2 Jul 2013 20:03, "Tom Deneau" <tom.deneau at amd.com<mailto:tom.deneau at amd.com>> wrote:
Here is the background for my visualizer question:

We have a junit test (part of the webrev) called StaticNBodyTest and the HSAIL backend is able
to compile the fairly large run method without problem.

Now to test inlining decisions, I moved the logic to a separate updateBody method, and had the
run method (the target of the compile) call the updateBody method.  By default, updateBody has too
many nodes to be inlined, but I raised the MaximumInliningSize and now graal does indeed inline it.

With the inlining completed, the HSAILLirGenerator is now passed several emitForeignCall requests
with the target being "createOutOfBoundsException".  Yet in the original StaticNBodyTest (same code,
just not behind a second layer of method call), there were no emitForeignCall requests.
Instead there were emitDeoptimize requests for the path taken when an array index was out of bounds.

Question 1: Why would there be emitDeoptimize in one case, and emitForeignCall after inlining?

As a followup question...

We have not decided how to handle exceptions yet in the HSAIL backend, so the emitDeoptimize request
is turned into a request to return early from the HSAIL kernel.   With this strategy, code generation
completes.

However, if I use similar logic with the emitForeignCall request, i.e. just generate a return,
or even just ignore the ForeignCall request completely, I hit the following error later in the codegen:

java.lang.AssertionError: using fixed register that is not defined in this block
        at com.oracle.graal.compiler.alloc.LinearScan.verifyInput(LinearScan.java:791)

Question 2: Why would this register assertion occur when emitForeignCall is replaced by a return, but not when emitDeoptimize
is similarly replaced by a return?

-- Tom Deneau




-----Original Message-----
From: graal-dev-bounces at openjdk.java.net<mailto:graal-dev-bounces at openjdk.java.net> [mailto:graal-dev-bounces at openjdk.java.net<mailto:graal-dev-bounces at openjdk.java.net>] On Behalf Of Deneau, Tom
Sent: Tuesday, July 02, 2013 11:53 AM
To: graal-dev at openjdk.java.net<mailto:graal-dev at openjdk.java.net>
Subject: mx igv or mx gv commands

When I try to use
   mx igv &

as described on the wiki page, I get the splash screen for the visualize but then it dies.
Similarly with mx gv &

Is there some other command that must be run first before using these?

-- Tom



From tom.deneau at amd.com  Wed Jul  3 07:56:53 2013
From: tom.deneau at amd.com (Deneau, Tom)
Date: Wed, 3 Jul 2013 14:56:53 +0000
Subject: mx igv or mx gv commands
In-Reply-To: <0B27773D-C633-416A-A9E4-BBC11860EED5@oracle.com>
References: <BC97738F8E7C8742BABED7F06FB9DF9145036996@sausexdag01.amd.com>
	<28C69BE9-B26E-4F31-9854-EDDE40F69B6C@oracle.com>
	<BC97738F8E7C8742BABED7F06FB9DF9145036B50@sausexdag01.amd.com>
	<CE16E6D1-F406-4A4C-BFA4-9D69FA73D614@oracle.com>
	<CAGjk+z9zTozciBbfiaMwKMEg4yNvXQuv1mN9hWdNfFaVL04aQw@mail.gmail.com>
	<BC97738F8E7C8742BABED7F06FB9DF9145036C18@sausexdag01.amd.com>
	<40F34CA5-F8B2-4DD3-A92E-4E6778747CC0@oracle.com>
	<0B27773D-C633-416A-A9E4-BBC11860EED5@oracle.com>
Message-ID: <BC97738F8E7C8742BABED7F06FB9DF9145036E6E@sausexdag01.amd.com>

Thanks, Doug and others, the igv capture is working now (with --vm server).

-- Tom


-----Original Message-----
From: Doug Simon [mailto:doug.simon at oracle.com] 
Sent: Wednesday, July 03, 2013 1:37 AM
To: Deneau, Tom
Cc: graal-dev at openjdk.java.net
Subject: Re: mx igv or mx gv commands


On Jul 3, 2013, at 1:25 AM, Christian Thalinger <christian.thalinger at oracle.com> wrote:

> 
> On Jul 2, 2013, at 4:16 PM, "Deneau, Tom" <tom.deneau at amd.com> wrote:
> 
>> I do see igv starting and waiting but it's not capturing anything.
>> My command line (after starting igv) is 
>> 
>> ./mx.sh --vm server unittest @-G:-RemoveNeverExecutedCode @-G:Log=InliningDecisions  @-G:+HotSpotPrintInlining -G:Dump= -G:MethodFilter=com.oracle.graal.compiler.hsail.test.StaticNBodyCallTest.run --J @-Xmx1g @-Xms1g --J @-Dsun.boot.library.path=$LD_LIBRARY_PATH   hsail.test.StaticNBodyCallTest 
> 
> @-G:Dump= ?

Yes, that means "dump everything" since the empty string matches the name of any dump scope.

The problem is that you are missing the '@' prefix in front of some of the options. Also you don't need the '--J' option as all '@' prefixed option are passed to the VM already. Your fixed up command line is:

./mx.sh --vm server unittest @-G:-RemoveNeverExecutedCode @-G:Log=InliningDecisions  @-G:+HotSpotPrintInlining @-G:Dump= @-G:MethodFilter=com.oracle.graal.compiler.hsail.test.StaticNBodyCallTest.run @-Xmx1g @-Xms1g @-Dsun.boot.library.path=$LD_LIBRARY_PATH hsail.test.StaticNBodyCallTest

-Doug

>> From: gilwooden at gmail.com [mailto:gilwooden at gmail.com] On Behalf Of Gilles Duboscq
>> Sent: Tuesday, July 02, 2013 6:01 PM
>> To: Christian Thalinger
>> Cc: Deneau, Tom; graal-dev at openjdk.java.net
>> Subject: Re: mx igv or mx gv commands
>> 
>> Which window manager do you use? I know that igv (netbeans) refuses to start with some window managers
>> 
>> On Wed, Jul 3, 2013 at 12:42 AM, Christian Thalinger <christian.thalinger at oracle.com> wrote:
>> 
>> On Jul 2, 2013, at 2:56 PM, "Deneau, Tom" <tom.deneau at amd.com> wrote:
>> 
>>> Christian --
>>> 
>>> What actual command lines should be used to view the graphs for an HSAIL compilation?
>> -G:Dump=
>> 
>> You can also use a method filter to only show what you want:
>> 
>> -G:MethodFilter=HashMap.put
>> 
>> It works when running a test inside Eclipse.
>> 
>> -- Chris
>> 
>>> Note that we typically run using --vm server.
>>> I would ask Vasanth but he is off this week.
>>> 
>>> -- Tom
>>> 
>>> 
>>> -----Original Message-----
>>> From: Christian Thalinger [mailto:christian.thalinger at oracle.com]
>>> Sent: Tuesday, July 02, 2013 3:49 PM
>>> To: Deneau, Tom
>>> Cc: graal-dev at openjdk.java.net
>>> Subject: Re: mx igv or mx gv commands
>>> 
>>> Which Java version are you using?  8 makes it crash, 7 should work.
>>> 
>>> -- Chris
>>> 
>>> On Jul 2, 2013, at 9:52 AM, "Deneau, Tom" <tom.deneau at amd.com> wrote:
>>> 
>>>> When I try to use
>>>> mx igv &
>>>> 
>>>> as described on the wiki page, I get the splash screen for the visualize but then it dies.
>>>> Similarly with mx gv &
>>>> 
>>>> Is there some other command that must be run first before using these?
>>>> 
>>>> -- Tom
>>>> 
>>> 
>>> 
>>> 
>> 
> 




From tom.deneau at amd.com  Wed Jul  3 08:42:03 2013
From: tom.deneau at amd.com (Deneau, Tom)
Date: Wed, 3 Jul 2013 15:42:03 +0000
Subject: EmitDeoptimize, EmitForignCall "createOutOfBoundsException"
References: <BC97738F8E7C8742BABED7F06FB9DF9145036996@sausexdag01.amd.com>
	<BC97738F8E7C8742BABED7F06FB9DF91450369E3@sausexdag01.amd.com>
	<CAGjk+z8EHkRFQrod8O7zbq5tJDniBxgaYED3+2+WjEuoB6=-iA@mail.gmail.com> 
Message-ID: <BC97738F8E7C8742BABED7F06FB9DF9145036F4C@sausexdag01.amd.com>

Gilles --

Asking my question from another angle, if we do have to consume the foreignCall to createOutOfBoundsException and effectively ignore it, is there something we can do from our side that will not upset the control flow graph and  register allocation invariants of the original LIR?

-- Tom


From: Deneau, Tom
Sent: Wednesday, July 03, 2013 9:25 AM
To: 'Gilles Duboscq'
Cc: graal-dev at openjdk.java.net
Subject: RE: EmitDeoptimize, EmitForignCall "createOutOfBoundsException"

Gilles --

It is strange that profiling would show that out of bounds exceptions were thrown on that path, I am quite sure that such exceptions are not being thrown when this code is run from the java side.  I also don't understand how profiling would show such exceptions in case #2 but not in case #1

case #1, compile this "run" method

    public static void run(float[] inxyz, float[] outxyz, float[] invxyz, float[] outvxyz, int gid) {
         .. fairly large leaf routine, over 300 nodes
     }

case #2, compile this "run" method

    public static void run(float[] inxyz, float[] outxyz, float[] invxyz, float[] outvxyz, int gid) {
          updateBody(inxyz, outxyz, invxyz, outvxyz, gid);
     }

    public static void updateBody(float[] inxyz, float[] outxyz, float[] invxyz, float[] outvxyz, int gid) {
           .. same contents as "run" method in case #1
     }

Your answer about the register allocation invariants with foreign call makes since.  So since we cannot yet handle the foreign call for this target, is there a flag that will force the LIR to emit a Deoptimization node (which we are able to effectively ignore) rather than a foreign call node when the purpose of the foreign call node is to create an OutOfBounds exception?

-- Tom


From: gilwooden at gmail.com [mailto:gilwooden at gmail.com] On Behalf Of Gilles Duboscq
Sent: Wednesday, July 03, 2013 3:51 AM
To: Deneau, Tom
Cc: graal-dev at openjdk.java.net
Subject: Re: EmitDeoptimize, EmitForignCall "createOutOfBoundsException"


For your first question, the profile seems to be the key: this path through the "create..." foreign call should only appear if profiling shows that array out of bounds exceptions are actually thrown at this position.
In this case the exception handling is done in the compiled code: it will create the exception object with that foreign call and the execution will be diverted to any  catch handler that the compiler could find.

Otherwise, if profile shows that no exception is thrown, the compiler assumes it can leave the exception handling out. A deoptimization will be used to go back to the interpreter if that assumption proved to be incorrect.

A deoptimization is ? like a return ? a control flow sink, it ends the execution of the current compilation unit. The foreign call on the other end is not a control flow sink.
If you replace a foreign call with a return during LIR generation I can see how later stages such as register allocation can get confused.
In general, it is not a good idea to modify the control flow graph during LIR generation, many of invariants of the algorithms working on the LIR will fail.

When compiling for such a target I suppose that you want to stick to deoptimization to handle cases that are not supported by this execution environment.
On 2 Jul 2013 20:03, "Tom Deneau" <tom.deneau at amd.com<mailto:tom.deneau at amd.com>> wrote:
Here is the background for my visualizer question:

We have a junit test (part of the webrev) called StaticNBodyTest and the HSAIL backend is able
to compile the fairly large run method without problem.

Now to test inlining decisions, I moved the logic to a separate updateBody method, and had the
run method (the target of the compile) call the updateBody method.  By default, updateBody has too
many nodes to be inlined, but I raised the MaximumInliningSize and now graal does indeed inline it.

With the inlining completed, the HSAILLirGenerator is now passed several emitForeignCall requests
with the target being "createOutOfBoundsException".  Yet in the original StaticNBodyTest (same code,
just not behind a second layer of method call), there were no emitForeignCall requests.
Instead there were emitDeoptimize requests for the path taken when an array index was out of bounds.

Question 1: Why would there be emitDeoptimize in one case, and emitForeignCall after inlining?

As a followup question...

We have not decided how to handle exceptions yet in the HSAIL backend, so the emitDeoptimize request
is turned into a request to return early from the HSAIL kernel.   With this strategy, code generation
completes.

However, if I use similar logic with the emitForeignCall request, i.e. just generate a return,
or even just ignore the ForeignCall request completely, I hit the following error later in the codegen:

java.lang.AssertionError: using fixed register that is not defined in this block
        at com.oracle.graal.compiler.alloc.LinearScan.verifyInput(LinearScan.java:791)

Question 2: Why would this register assertion occur when emitForeignCall is replaced by a return, but not when emitDeoptimize
is similarly replaced by a return?

-- Tom Deneau




-----Original Message-----
From: graal-dev-bounces at openjdk.java.net<mailto:graal-dev-bounces at openjdk.java.net> [mailto:graal-dev-bounces at openjdk.java.net<mailto:graal-dev-bounces at openjdk.java.net>] On Behalf Of Deneau, Tom
Sent: Tuesday, July 02, 2013 11:53 AM
To: graal-dev at openjdk.java.net<mailto:graal-dev at openjdk.java.net>
Subject: mx igv or mx gv commands

When I try to use
   mx igv &

as described on the wiki page, I get the splash screen for the visualize but then it dies.
Similarly with mx gv &

Is there some other command that must be run first before using these?

-- Tom


From tom.deneau at amd.com  Wed Jul  3 10:15:15 2013
From: tom.deneau at amd.com (Deneau, Tom)
Date: Wed, 3 Jul 2013 17:15:15 +0000
Subject: EmitDeoptimize, EmitForignCall "createOutOfBoundsException"
In-Reply-To: <BC97738F8E7C8742BABED7F06FB9DF9145036F4C@sausexdag01.amd.com>
References: <BC97738F8E7C8742BABED7F06FB9DF9145036996@sausexdag01.amd.com>
	<BC97738F8E7C8742BABED7F06FB9DF91450369E3@sausexdag01.amd.com>
	<CAGjk+z8EHkRFQrod8O7zbq5tJDniBxgaYED3+2+WjEuoB6=-iA@mail.gmail.com>
	<BC97738F8E7C8742BABED7F06FB9DF9145036F4C@sausexdag01.amd.com>
Message-ID: <BC97738F8E7C8742BABED7F06FB9DF9145036FCD@sausexdag01.amd.com>

I noticed that if I have the same structure where the compiled method
inlines a leaf method but the leaf method is small enough (I used
the IntSquaredTest), then the resulting LIR that is handed to the backend
has only deopt nodes, no ForeignCall nodes.

Looking at the igv graphs for the "smaller" leaf node inline,
I can see that right after inlining the ForeignCall
nodes (to CreateOutOfBoundsException) are still there, 
but they become FixedGuard nodes after the  DeadCodeElimination phase.
And then later, after Guard Lowering phase, they become deopt nodes.

Whereas for the "larger" leaf node inline case, the ForeignCall nodes
never become FixedGuard nodes.  Not sure why they are treated differently
in this case.

-- Tom



-----Original Message-----
From: graal-dev-bounces at openjdk.java.net [mailto:graal-dev-bounces at openjdk.java.net] On Behalf Of Deneau, Tom
Sent: Wednesday, July 03, 2013 10:42 AM
To: Gilles Duboscq
Cc: graal-dev at openjdk.java.net
Subject: RE: EmitDeoptimize, EmitForignCall "createOutOfBoundsException"

Gilles --

Asking my question from another angle, if we do have to consume the foreignCall to createOutOfBoundsException and effectively ignore it, is there something we can do from our side that will not upset the control flow graph and  register allocation invariants of the original LIR?

-- Tom


From: Deneau, Tom
Sent: Wednesday, July 03, 2013 9:25 AM
To: 'Gilles Duboscq'
Cc: graal-dev at openjdk.java.net
Subject: RE: EmitDeoptimize, EmitForignCall "createOutOfBoundsException"

Gilles --

It is strange that profiling would show that out of bounds exceptions were thrown on that path, I am quite sure that such exceptions are not being thrown when this code is run from the java side.  I also don't understand how profiling would show such exceptions in case #2 but not in case #1

case #1, compile this "run" method

    public static void run(float[] inxyz, float[] outxyz, float[] invxyz, float[] outvxyz, int gid) {
         .. fairly large leaf routine, over 300 nodes
     }

case #2, compile this "run" method

    public static void run(float[] inxyz, float[] outxyz, float[] invxyz, float[] outvxyz, int gid) {
          updateBody(inxyz, outxyz, invxyz, outvxyz, gid);
     }

    public static void updateBody(float[] inxyz, float[] outxyz, float[] invxyz, float[] outvxyz, int gid) {
           .. same contents as "run" method in case #1
     }

Your answer about the register allocation invariants with foreign call makes since.  So since we cannot yet handle the foreign call for this target, is there a flag that will force the LIR to emit a Deoptimization node (which we are able to effectively ignore) rather than a foreign call node when the purpose of the foreign call node is to create an OutOfBounds exception?

-- Tom


From: gilwooden at gmail.com [mailto:gilwooden at gmail.com] On Behalf Of Gilles Duboscq
Sent: Wednesday, July 03, 2013 3:51 AM
To: Deneau, Tom
Cc: graal-dev at openjdk.java.net
Subject: Re: EmitDeoptimize, EmitForignCall "createOutOfBoundsException"


For your first question, the profile seems to be the key: this path through the "create..." foreign call should only appear if profiling shows that array out of bounds exceptions are actually thrown at this position.
In this case the exception handling is done in the compiled code: it will create the exception object with that foreign call and the execution will be diverted to any  catch handler that the compiler could find.

Otherwise, if profile shows that no exception is thrown, the compiler assumes it can leave the exception handling out. A deoptimization will be used to go back to the interpreter if that assumption proved to be incorrect.

A deoptimization is ? like a return ? a control flow sink, it ends the execution of the current compilation unit. The foreign call on the other end is not a control flow sink.
If you replace a foreign call with a return during LIR generation I can see how later stages such as register allocation can get confused.
In general, it is not a good idea to modify the control flow graph during LIR generation, many of invariants of the algorithms working on the LIR will fail.

When compiling for such a target I suppose that you want to stick to deoptimization to handle cases that are not supported by this execution environment.
On 2 Jul 2013 20:03, "Tom Deneau" <tom.deneau at amd.com<mailto:tom.deneau at amd.com>> wrote:
Here is the background for my visualizer question:

We have a junit test (part of the webrev) called StaticNBodyTest and the HSAIL backend is able
to compile the fairly large run method without problem.

Now to test inlining decisions, I moved the logic to a separate updateBody method, and had the
run method (the target of the compile) call the updateBody method.  By default, updateBody has too
many nodes to be inlined, but I raised the MaximumInliningSize and now graal does indeed inline it.

With the inlining completed, the HSAILLirGenerator is now passed several emitForeignCall requests
with the target being "createOutOfBoundsException".  Yet in the original StaticNBodyTest (same code,
just not behind a second layer of method call), there were no emitForeignCall requests.
Instead there were emitDeoptimize requests for the path taken when an array index was out of bounds.

Question 1: Why would there be emitDeoptimize in one case, and emitForeignCall after inlining?

As a followup question...

We have not decided how to handle exceptions yet in the HSAIL backend, so the emitDeoptimize request
is turned into a request to return early from the HSAIL kernel.   With this strategy, code generation
completes.

However, if I use similar logic with the emitForeignCall request, i.e. just generate a return,
or even just ignore the ForeignCall request completely, I hit the following error later in the codegen:

java.lang.AssertionError: using fixed register that is not defined in this block
        at com.oracle.graal.compiler.alloc.LinearScan.verifyInput(LinearScan.java:791)

Question 2: Why would this register assertion occur when emitForeignCall is replaced by a return, but not when emitDeoptimize
is similarly replaced by a return?

-- Tom Deneau




-----Original Message-----
From: graal-dev-bounces at openjdk.java.net<mailto:graal-dev-bounces at openjdk.java.net> [mailto:graal-dev-bounces at openjdk.java.net<mailto:graal-dev-bounces at openjdk.java.net>] On Behalf Of Deneau, Tom
Sent: Tuesday, July 02, 2013 11:53 AM
To: graal-dev at openjdk.java.net<mailto:graal-dev at openjdk.java.net>
Subject: mx igv or mx gv commands

When I try to use
   mx igv &

as described on the wiki page, I get the splash screen for the visualize but then it dies.
Similarly with mx gv &

Is there some other command that must be run first before using these?

-- Tom


From thomas.wuerthinger at oracle.com  Fri Jul  5 05:36:25 2013
From: thomas.wuerthinger at oracle.com (Thomas Wuerthinger)
Date: Fri, 5 Jul 2013 14:36:25 +0200
Subject: EmitDeoptimize, EmitForignCall "createOutOfBoundsException"
In-Reply-To: <BC97738F8E7C8742BABED7F06FB9DF9145036FCD@sausexdag01.amd.com>
References: <BC97738F8E7C8742BABED7F06FB9DF9145036996@sausexdag01.amd.com>
	<BC97738F8E7C8742BABED7F06FB9DF91450369E3@sausexdag01.amd.com>
	<CAGjk+z8EHkRFQrod8O7zbq5tJDniBxgaYED3+2+WjEuoB6=-iA@mail.gmail.com>
	<BC97738F8E7C8742BABED7F06FB9DF9145036F4C@sausexdag01.amd.com>
	<BC97738F8E7C8742BABED7F06FB9DF9145036FCD@sausexdag01.amd.com>
Message-ID: <ACE51B7A-9D9B-4CEE-B6A5-756790FBE058@oracle.com>

Can you send a link to the IGV graphs? You can use File=>Export to create an XML file for the currently loaded graphs.

Thanks, thomas

On Jul 3, 2013, at 7:15 PM, "Deneau, Tom" <tom.deneau at amd.com> wrote:

> I noticed that if I have the same structure where the compiled method
> inlines a leaf method but the leaf method is small enough (I used
> the IntSquaredTest), then the resulting LIR that is handed to the backend
> has only deopt nodes, no ForeignCall nodes.
> 
> Looking at the igv graphs for the "smaller" leaf node inline,
> I can see that right after inlining the ForeignCall
> nodes (to CreateOutOfBoundsException) are still there, 
> but they become FixedGuard nodes after the  DeadCodeElimination phase.
> And then later, after Guard Lowering phase, they become deopt nodes.
> 
> Whereas for the "larger" leaf node inline case, the ForeignCall nodes
> never become FixedGuard nodes.  Not sure why they are treated differently
> in this case.
> 
> -- Tom
> 
> 
> 
> -----Original Message-----
> From: graal-dev-bounces at openjdk.java.net [mailto:graal-dev-bounces at openjdk.java.net] On Behalf Of Deneau, Tom
> Sent: Wednesday, July 03, 2013 10:42 AM
> To: Gilles Duboscq
> Cc: graal-dev at openjdk.java.net
> Subject: RE: EmitDeoptimize, EmitForignCall "createOutOfBoundsException"
> 
> Gilles --
> 
> Asking my question from another angle, if we do have to consume the foreignCall to createOutOfBoundsException and effectively ignore it, is there something we can do from our side that will not upset the control flow graph and  register allocation invariants of the original LIR?
> 
> -- Tom
> 
> 
> From: Deneau, Tom
> Sent: Wednesday, July 03, 2013 9:25 AM
> To: 'Gilles Duboscq'
> Cc: graal-dev at openjdk.java.net
> Subject: RE: EmitDeoptimize, EmitForignCall "createOutOfBoundsException"
> 
> Gilles --
> 
> It is strange that profiling would show that out of bounds exceptions were thrown on that path, I am quite sure that such exceptions are not being thrown when this code is run from the java side.  I also don't understand how profiling would show such exceptions in case #2 but not in case #1
> 
> case #1, compile this "run" method
> 
>    public static void run(float[] inxyz, float[] outxyz, float[] invxyz, float[] outvxyz, int gid) {
>         .. fairly large leaf routine, over 300 nodes
>     }
> 
> case #2, compile this "run" method
> 
>    public static void run(float[] inxyz, float[] outxyz, float[] invxyz, float[] outvxyz, int gid) {
>          updateBody(inxyz, outxyz, invxyz, outvxyz, gid);
>     }
> 
>    public static void updateBody(float[] inxyz, float[] outxyz, float[] invxyz, float[] outvxyz, int gid) {
>           .. same contents as "run" method in case #1
>     }
> 
> Your answer about the register allocation invariants with foreign call makes since.  So since we cannot yet handle the foreign call for this target, is there a flag that will force the LIR to emit a Deoptimization node (which we are able to effectively ignore) rather than a foreign call node when the purpose of the foreign call node is to create an OutOfBounds exception?
> 
> -- Tom
> 
> 
> From: gilwooden at gmail.com [mailto:gilwooden at gmail.com] On Behalf Of Gilles Duboscq
> Sent: Wednesday, July 03, 2013 3:51 AM
> To: Deneau, Tom
> Cc: graal-dev at openjdk.java.net
> Subject: Re: EmitDeoptimize, EmitForignCall "createOutOfBoundsException"
> 
> 
> For your first question, the profile seems to be the key: this path through the "create..." foreign call should only appear if profiling shows that array out of bounds exceptions are actually thrown at this position.
> In this case the exception handling is done in the compiled code: it will create the exception object with that foreign call and the execution will be diverted to any  catch handler that the compiler could find.
> 
> Otherwise, if profile shows that no exception is thrown, the compiler assumes it can leave the exception handling out. A deoptimization will be used to go back to the interpreter if that assumption proved to be incorrect.
> 
> A deoptimization is ? like a return ? a control flow sink, it ends the execution of the current compilation unit. The foreign call on the other end is not a control flow sink.
> If you replace a foreign call with a return during LIR generation I can see how later stages such as register allocation can get confused.
> In general, it is not a good idea to modify the control flow graph during LIR generation, many of invariants of the algorithms working on the LIR will fail.
> 
> When compiling for such a target I suppose that you want to stick to deoptimization to handle cases that are not supported by this execution environment.
> On 2 Jul 2013 20:03, "Tom Deneau" <tom.deneau at amd.com<mailto:tom.deneau at amd.com>> wrote:
> Here is the background for my visualizer question:
> 
> We have a junit test (part of the webrev) called StaticNBodyTest and the HSAIL backend is able
> to compile the fairly large run method without problem.
> 
> Now to test inlining decisions, I moved the logic to a separate updateBody method, and had the
> run method (the target of the compile) call the updateBody method.  By default, updateBody has too
> many nodes to be inlined, but I raised the MaximumInliningSize and now graal does indeed inline it.
> 
> With the inlining completed, the HSAILLirGenerator is now passed several emitForeignCall requests
> with the target being "createOutOfBoundsException".  Yet in the original StaticNBodyTest (same code,
> just not behind a second layer of method call), there were no emitForeignCall requests.
> Instead there were emitDeoptimize requests for the path taken when an array index was out of bounds.
> 
> Question 1: Why would there be emitDeoptimize in one case, and emitForeignCall after inlining?
> 
> As a followup question...
> 
> We have not decided how to handle exceptions yet in the HSAIL backend, so the emitDeoptimize request
> is turned into a request to return early from the HSAIL kernel.   With this strategy, code generation
> completes.
> 
> However, if I use similar logic with the emitForeignCall request, i.e. just generate a return,
> or even just ignore the ForeignCall request completely, I hit the following error later in the codegen:
> 
> java.lang.AssertionError: using fixed register that is not defined in this block
>        at com.oracle.graal.compiler.alloc.LinearScan.verifyInput(LinearScan.java:791)
> 
> Question 2: Why would this register assertion occur when emitForeignCall is replaced by a return, but not when emitDeoptimize
> is similarly replaced by a return?
> 
> -- Tom Deneau
> 
> 
> 
> 
> -----Original Message-----
> From: graal-dev-bounces at openjdk.java.net<mailto:graal-dev-bounces at openjdk.java.net> [mailto:graal-dev-bounces at openjdk.java.net<mailto:graal-dev-bounces at openjdk.java.net>] On Behalf Of Deneau, Tom
> Sent: Tuesday, July 02, 2013 11:53 AM
> To: graal-dev at openjdk.java.net<mailto:graal-dev at openjdk.java.net>
> Subject: mx igv or mx gv commands
> 
> When I try to use
>   mx igv &
> 
> as described on the wiki page, I get the splash screen for the visualize but then it dies.
> Similarly with mx gv &
> 
> Is there some other command that must be run first before using these?
> 
> -- Tom
> 


From tom.deneau at amd.com  Fri Jul  5 13:53:14 2013
From: tom.deneau at amd.com (Deneau, Tom)
Date: Fri, 5 Jul 2013 20:53:14 +0000
Subject: EmitDeoptimize, EmitForignCall "createOutOfBoundsException"
In-Reply-To: <ACE51B7A-9D9B-4CEE-B6A5-756790FBE058@oracle.com>
References: <BC97738F8E7C8742BABED7F06FB9DF9145036996@sausexdag01.amd.com>
	<BC97738F8E7C8742BABED7F06FB9DF91450369E3@sausexdag01.amd.com>
	<CAGjk+z8EHkRFQrod8O7zbq5tJDniBxgaYED3+2+WjEuoB6=-iA@mail.gmail.com>
	<BC97738F8E7C8742BABED7F06FB9DF9145036F4C@sausexdag01.amd.com>
	<BC97738F8E7C8742BABED7F06FB9DF9145036FCD@sausexdag01.amd.com>
	<ACE51B7A-9D9B-4CEE-B6A5-756790FBE058@oracle.com>
Message-ID: <BC97738F8E7C8742BABED7F06FB9DF9145037775@sausexdag01.amd.com>

Thomas --

I have put the graphs (collected with the igv tool) up at
http://cr.openjdk.java.net/~tdeneau/igv-graphs/ 

smallerinline.xml is the smaller leaf node case mentioned below,
largerinline.xml is the larger leaf node case.

Current status:
Instead of either just generating a return like we did for the no-op sink,
or doing nothing with the EmitForeignCall node, I appended a node
which had what I think are the appropriate @Use and @Def variable
annotations in it, and didn't emit any real code, just a comment such as

	//ForeignCall to createOutOfBoundsException would have gone here

This seemed to be enough to keep the register allocation invariants checker happy.
We never actually takes this exception path in our junit tests of course.

Still I would be interested in your analysis of the graphs and why
the ForeignCall nodes become FixedGuard nodes in the smaller inline case
and not in the larger.

-- Tom Deneau



-----Original Message-----
From: Thomas Wuerthinger [mailto:thomas.wuerthinger at oracle.com] 
Sent: Friday, July 05, 2013 7:36 AM
To: Deneau, Tom
Cc: Gilles Duboscq; graal-dev at openjdk.java.net
Subject: Re: EmitDeoptimize, EmitForignCall "createOutOfBoundsException"

Can you send a link to the IGV graphs? You can use File=>Export to create an XML file for the currently loaded graphs.

Thanks, thomas

On Jul 3, 2013, at 7:15 PM, "Deneau, Tom" <tom.deneau at amd.com> wrote:

> I noticed that if I have the same structure where the compiled method
> inlines a leaf method but the leaf method is small enough (I used
> the IntSquaredTest), then the resulting LIR that is handed to the backend
> has only deopt nodes, no ForeignCall nodes.
> 
> Looking at the igv graphs for the "smaller" leaf node inline,
> I can see that right after inlining the ForeignCall
> nodes (to CreateOutOfBoundsException) are still there, 
> but they become FixedGuard nodes after the  DeadCodeElimination phase.
> And then later, after Guard Lowering phase, they become deopt nodes.
> 
> Whereas for the "larger" leaf node inline case, the ForeignCall nodes
> never become FixedGuard nodes.  Not sure why they are treated differently
> in this case.
> 
> -- Tom
> 
> 
> 
> -----Original Message-----
> From: graal-dev-bounces at openjdk.java.net [mailto:graal-dev-bounces at openjdk.java.net] On Behalf Of Deneau, Tom
> Sent: Wednesday, July 03, 2013 10:42 AM
> To: Gilles Duboscq
> Cc: graal-dev at openjdk.java.net
> Subject: RE: EmitDeoptimize, EmitForignCall "createOutOfBoundsException"
> 
> Gilles --
> 
> Asking my question from another angle, if we do have to consume the foreignCall to createOutOfBoundsException and effectively ignore it, is there something we can do from our side that will not upset the control flow graph and  register allocation invariants of the original LIR?
> 
> -- Tom
> 
> 
> From: Deneau, Tom
> Sent: Wednesday, July 03, 2013 9:25 AM
> To: 'Gilles Duboscq'
> Cc: graal-dev at openjdk.java.net
> Subject: RE: EmitDeoptimize, EmitForignCall "createOutOfBoundsException"
> 
> Gilles --
> 
> It is strange that profiling would show that out of bounds exceptions were thrown on that path, I am quite sure that such exceptions are not being thrown when this code is run from the java side.  I also don't understand how profiling would show such exceptions in case #2 but not in case #1
> 
> case #1, compile this "run" method
> 
>    public static void run(float[] inxyz, float[] outxyz, float[] invxyz, float[] outvxyz, int gid) {
>         .. fairly large leaf routine, over 300 nodes
>     }
> 
> case #2, compile this "run" method
> 
>    public static void run(float[] inxyz, float[] outxyz, float[] invxyz, float[] outvxyz, int gid) {
>          updateBody(inxyz, outxyz, invxyz, outvxyz, gid);
>     }
> 
>    public static void updateBody(float[] inxyz, float[] outxyz, float[] invxyz, float[] outvxyz, int gid) {
>           .. same contents as "run" method in case #1
>     }
> 
> Your answer about the register allocation invariants with foreign call makes since.  So since we cannot yet handle the foreign call for this target, is there a flag that will force the LIR to emit a Deoptimization node (which we are able to effectively ignore) rather than a foreign call node when the purpose of the foreign call node is to create an OutOfBounds exception?
> 
> -- Tom
> 
> 
> From: gilwooden at gmail.com [mailto:gilwooden at gmail.com] On Behalf Of Gilles Duboscq
> Sent: Wednesday, July 03, 2013 3:51 AM
> To: Deneau, Tom
> Cc: graal-dev at openjdk.java.net
> Subject: Re: EmitDeoptimize, EmitForignCall "createOutOfBoundsException"
> 
> 
> For your first question, the profile seems to be the key: this path through the "create..." foreign call should only appear if profiling shows that array out of bounds exceptions are actually thrown at this position.
> In this case the exception handling is done in the compiled code: it will create the exception object with that foreign call and the execution will be diverted to any  catch handler that the compiler could find.
> 
> Otherwise, if profile shows that no exception is thrown, the compiler assumes it can leave the exception handling out. A deoptimization will be used to go back to the interpreter if that assumption proved to be incorrect.
> 
> A deoptimization is - like a return - a control flow sink, it ends the execution of the current compilation unit. The foreign call on the other end is not a control flow sink.
> If you replace a foreign call with a return during LIR generation I can see how later stages such as register allocation can get confused.
> In general, it is not a good idea to modify the control flow graph during LIR generation, many of invariants of the algorithms working on the LIR will fail.
> 
> When compiling for such a target I suppose that you want to stick to deoptimization to handle cases that are not supported by this execution environment.
> On 2 Jul 2013 20:03, "Tom Deneau" <tom.deneau at amd.com<mailto:tom.deneau at amd.com>> wrote:
> Here is the background for my visualizer question:
> 
> We have a junit test (part of the webrev) called StaticNBodyTest and the HSAIL backend is able
> to compile the fairly large run method without problem.
> 
> Now to test inlining decisions, I moved the logic to a separate updateBody method, and had the
> run method (the target of the compile) call the updateBody method.  By default, updateBody has too
> many nodes to be inlined, but I raised the MaximumInliningSize and now graal does indeed inline it.
> 
> With the inlining completed, the HSAILLirGenerator is now passed several emitForeignCall requests
> with the target being "createOutOfBoundsException".  Yet in the original StaticNBodyTest (same code,
> just not behind a second layer of method call), there were no emitForeignCall requests.
> Instead there were emitDeoptimize requests for the path taken when an array index was out of bounds.
> 
> Question 1: Why would there be emitDeoptimize in one case, and emitForeignCall after inlining?
> 
> As a followup question...
> 
> We have not decided how to handle exceptions yet in the HSAIL backend, so the emitDeoptimize request
> is turned into a request to return early from the HSAIL kernel.   With this strategy, code generation
> completes.
> 
> However, if I use similar logic with the emitForeignCall request, i.e. just generate a return,
> or even just ignore the ForeignCall request completely, I hit the following error later in the codegen:
> 
> java.lang.AssertionError: using fixed register that is not defined in this block
>        at com.oracle.graal.compiler.alloc.LinearScan.verifyInput(LinearScan.java:791)
> 
> Question 2: Why would this register assertion occur when emitForeignCall is replaced by a return, but not when emitDeoptimize
> is similarly replaced by a return?
> 
> -- Tom Deneau
> 
> 
> 
> 
> -----Original Message-----
> From: graal-dev-bounces at openjdk.java.net<mailto:graal-dev-bounces at openjdk.java.net> [mailto:graal-dev-bounces at openjdk.java.net<mailto:graal-dev-bounces at openjdk.java.net>] On Behalf Of Deneau, Tom
> Sent: Tuesday, July 02, 2013 11:53 AM
> To: graal-dev at openjdk.java.net<mailto:graal-dev at openjdk.java.net>
> Subject: mx igv or mx gv commands
> 
> When I try to use
>   mx igv &
> 
> as described on the wiki page, I get the splash screen for the visualize but then it dies.
> Similarly with mx gv &
> 
> Is there some other command that must be run first before using these?
> 
> -- Tom
> 




From s1255753 at sms.ed.ac.uk  Fri Jul  5 15:14:32 2013
From: s1255753 at sms.ed.ac.uk (ATKIN-GRANVILLE Chris)
Date: Fri, 5 Jul 2013 22:14:32 +0000
Subject: NullPointerException in HotSpotRuntime:lower when using Snippets
In-Reply-To: <1B56654D-BB65-423B-9558-96254F71132F@oracle.com>
References: <72C1FE55-E500-47DA-B5DE-831AB7119F3F@sms.ed.ac.uk>
	<1B56654D-BB65-423B-9558-96254F71132F@oracle.com>
Message-ID: <4AD5DAB8-9F0B-44AD-9FD3-B007DADE45A8@sms.ed.ac.uk>

Thanks for the advice. I tried your suggestions and I can now access fields in the snippet (so far I'm just incrementing a static field). However, if I try to do something a little more fancy like calling a method, I get another exception. I'll investigate further next week, but if you have any suggestions they'd be appreciated. FWIW I tried outputting to stdout whenever a node (i.e., my custom node) is being lowered and this error doesn't occur for *all* nodes - it appears to correctly lower some nodes first. I think I do some pattern matching and only replace nodes within loops (which are the only ones I'm interested in) and hope that the problem will go away that way but I haven't had time to try that (yet).

scope: GraalCompiler.FrontEnd.LowTier.Lowering.IncrementalCanonicalizer.Lowering iteration 0.InterceptException
Exception occurred in scope: GraalCompiler.FrontEnd.LowTier.Lowering.IncrementalCanonicalizer.Lowering iteration 0.InterceptException
Context obj com.oracle.graal.graph.GraalInternalError: Cannot create guards in after-guard lowering
Context obj com.oracle.graal.phases.common.LoweringPhase$Round at 76505305
Context obj com.oracle.graal.phases.common.IncrementalCanonicalizerPhase at 14cd1699
Context obj com.oracle.graal.phases.common.LoweringPhase at 77888435
Context obj com.oracle.graal.compiler.phases.LowTier at 73a1e9a9
Context obj StructuredGraph:3{HotSpotMethod<CodeSamples.loopDependency(int[], int[])>}
Connected to the IGV on 127.0.0.1:4445
Context obj com.oracle.graal.hotspot.amd64.AMD64HotSpotRuntime at 5ad851c9
Exception in thread "main" com.oracle.graal.graph.GraalInternalError: Cannot create guards in after-guard lowering
        at com.oracle.graal.phases.common.LoweringPhase$LoweringToolImpl.createGuard(LoweringPhase.java:103)
        at com.oracle.graal.phases.common.LoweringPhase$LoweringToolImpl.createNullCheckGuard(LoweringPhase.java:84)
        at com.oracle.graal.hotspot.meta.HotSpotRuntime.lower(HotSpotRuntime.java:497)
        at com.oracle.graal.hotspot.amd64.AMD64HotSpotRuntime.lower(AMD64HotSpotRuntime.java:82)
        at com.oracle.graal.nodes.InvokeNode.lower(InvokeNode.java:112)
        at com.oracle.graal.phases.common.LoweringPhase$Round.process(LoweringPhase.java:258)
        at com.oracle.graal.phases.common.LoweringPhase$Round.processBlock(LoweringPhase.java:192)
        at com.oracle.graal.phases.common.LoweringPhase$Round.processBlock(LoweringPhase.java:204)
        at com.oracle.graal.phases.common.LoweringPhase$Round.processBlock(LoweringPhase.java:204)
        at com.oracle.graal.phases.common.LoweringPhase$Round.processBlock(LoweringPhase.java:204)
        at com.oracle.graal.phases.common.LoweringPhase$Round.processBlock(LoweringPhase.java:204)
        at com.oracle.graal.phases.common.LoweringPhase$Round.processBlock(LoweringPhase.java:204)
        at com.oracle.graal.phases.common.LoweringPhase$Round.run(LoweringPhase.java:183)
        at com.oracle.graal.phases.Phase.run(Phase.java:51)
        at com.oracle.graal.phases.BasePhase$1.run(BasePhase.java:62)
        at com.oracle.graal.debug.internal.DebugScope.executeScope(DebugScope.java:179)
        at com.oracle.graal.debug.internal.DebugScope.scope(DebugScope.java:167)
        at com.oracle.graal.debug.Debug.scope(Debug.java:118)
        at com.oracle.graal.debug.Debug.scope(Debug.java:113)
        at com.oracle.graal.phases.BasePhase.apply(BasePhase.java:59)
        at com.oracle.graal.phases.BasePhase.apply(BasePhase.java:55)
        at com.oracle.graal.phases.PhaseSuite.run(PhaseSuite.java:69)
        at com.oracle.graal.phases.common.IncrementalCanonicalizerPhase.run(IncrementalCanonicalizerPhase.java:47)
        at com.oracle.graal.phases.common.IncrementalCanonicalizerPhase.run(IncrementalCanonicalizerPhase.java:1)
        at com.oracle.graal.phases.BasePhase$1.run(BasePhase.java:62)
        at com.oracle.graal.debug.internal.DebugScope.executeScope(DebugScope.java:179)
        at com.oracle.graal.debug.internal.DebugScope.scope(DebugScope.java:167)
        at com.oracle.graal.debug.Debug.scope(Debug.java:118)
        at com.oracle.graal.debug.Debug.scope(Debug.java:113)
        at com.oracle.graal.phases.BasePhase.apply(BasePhase.java:59)
        at com.oracle.graal.phases.BasePhase.apply(BasePhase.java:55)
        at com.oracle.graal.phases.common.LoweringPhase.run(LoweringPhase.java:159)
        at com.oracle.graal.phases.common.LoweringPhase.run(LoweringPhase.java:1)
        at com.oracle.graal.phases.BasePhase$1.run(BasePhase.java:62)
        at com.oracle.graal.debug.internal.DebugScope.executeScope(DebugScope.java:179)
        at com.oracle.graal.debug.internal.DebugScope.scope(DebugScope.java:167)
        at com.oracle.graal.debug.Debug.scope(Debug.java:118)
        at com.oracle.graal.debug.Debug.scope(Debug.java:113)
        at com.oracle.graal.phases.BasePhase.apply(BasePhase.java:59)
        at com.oracle.graal.phases.BasePhase.apply(BasePhase.java:55)
        at com.oracle.graal.phases.PhaseSuite.run(PhaseSuite.java:69)
        at com.oracle.graal.phases.BasePhase$1.run(BasePhase.java:62)
        at com.oracle.graal.debug.internal.DebugScope.executeScope(DebugScope.java:179)
        at com.oracle.graal.debug.internal.DebugScope.scope(DebugScope.java:167)
        at com.oracle.graal.debug.Debug.scope(Debug.java:118)
        at com.oracle.graal.debug.Debug.scope(Debug.java:113)
        at com.oracle.graal.phases.BasePhase.apply(BasePhase.java:59)
        at com.oracle.graal.phases.BasePhase.apply(BasePhase.java:55)
        at com.oracle.graal.compiler.GraalCompiler.emitHIR(GraalCompiler.java:172)
        at com.oracle.graal.compiler.GraalCompiler$1$1.call(GraalCompiler.java:86)
        at com.oracle.graal.compiler.GraalCompiler$1$1.call(GraalCompiler.java:1)
        at com.oracle.graal.debug.internal.DebugScope.call(DebugScope.java:301)
        at com.oracle.graal.debug.internal.DebugScope.executeScope(DebugScope.java:182)
        at com.oracle.graal.debug.internal.DebugScope.scope(DebugScope.java:167)
        at com.oracle.graal.debug.Debug.scope(Debug.java:138)
        at com.oracle.graal.debug.Debug.scope(Debug.java:109)
        at com.oracle.graal.compiler.GraalCompiler$1.run(GraalCompiler.java:83)
        at com.oracle.graal.debug.internal.DebugScope.executeScope(DebugScope.java:179)
        at com.oracle.graal.debug.internal.DebugScope.scope(DebugScope.java:167)
        at com.oracle.graal.debug.Debug.scope(Debug.java:118)
        at com.oracle.graal.compiler.GraalCompiler.compileGraph(GraalCompiler.java:79)
        at uk.ac.ed.inf.icsa.locomotion.core.Locomotion.compile(Locomotion.java:57)
        at uk.ac.ed.inf.icsa.locomotion.Application.run(Application.java:46)
        at uk.ac.ed.inf.icsa.locomotion.Application.main(Application.java:65)



On 3 Jul 2013, at 14:53, Doug Simon <doug.simon at oracle.com> wrote:

>
> On Jul 2, 2013, at 9:36 PM, ATKIN-GRANVILLE Chris <s1255753 at sms.ed.ac.uk> wrote:
>
>> Hi there,
>>
>> I'm trying add arbitrary behaviour to array accesses - the end goal being to create traces of all memory operations within a program. What I've done so far was suggested to me in a previous thread on this list, but in short, I've got phases that add my own custom nodes to each LoadIndexedNode/StoreIndexedNode. These are then lowered to the desired behaviour via snippets:
>>
>> public class InstrumentationSnippets implements Snippets {
>>       @Snippet
>>       public static void store(final ArrayStoreBehaviourNode<?> node) {
>>               Instrument.arrayStores.add(node.getInfo());
>>       }
>>
>>       @Snippet
>>       public static void load(final ArrayLoadBehaviourNode<?> node) {
>>               Instrument.arrayLoads.add(node.getInfo());
>>       }
>
> This doesn't look right, having compiler nodes as parameter types of snippets. The value of a snippet parameter may come from a compiler node when the snippet is instantiated (during lowering) but the snippet sees the "raw" Java type of the value. Assuming ArrayLoadInfo is the type returned by node.getInfo(), you probably want something like this:
>
> @Snippet
> public static void load(ArrayLoadInfo info) {
>    Instrument.arrayLoads.add(info);
> }
>
>
>>       public static class Templates extends AbstractTemplates {
>>               private final SnippetInfo store = snippet(InstrumentationSnippets.class, "store");
>>               private final SnippetInfo load = snippet(InstrumentationSnippets.class, "load");
>>
>>               public Templates(MetaAccessProvider runtime, Replacements replacements, TargetDescription target) {
>>                       super(runtime, replacements, target);
>>               }
>>
>>               public void lower(final ArrayStoreBehaviourNode<?> node) {
>>                       Arguments args = new Arguments(store);
>>                       args.add("node", node);
>
> and replace the above with:
>
> args.add("info", node.getInfo());
>
> -Doug

-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: not available
Url: http://mail.openjdk.java.net/pipermail/graal-dev/attachments/20130705/77019004/attachment.ksh 

From doug.simon at oracle.com  Sat Jul  6 18:00:30 2013
From: doug.simon at oracle.com (doug.simon at oracle.com)
Date: Sun, 07 Jul 2013 01:00:30 +0000
Subject: hg: graal/graal: 36 new changesets
Message-ID: <20130707010233.594854887A@hg.openjdk.java.net>

Changeset: 9c7d9e2c8326
Author:    Morris Meyer <morris.meyer at oracle.com>
Date:      2013-06-29 21:29 -0400
URL:       http://hg.openjdk.java.net/graal/graal/rev/9c7d9e2c8326

PTX kernel execution - no args or return value

+ graal/com.oracle.graal.api.code/src/com/oracle/graal/api/code/ExternalCompilationResult.java
! graal/com.oracle.graal.compiler.ptx.test/src/com/oracle/graal/compiler/ptx/test/BasicPTXTest.java
! graal/com.oracle.graal.compiler.ptx.test/src/com/oracle/graal/compiler/ptx/test/PTXTestBase.java
! graal/com.oracle.graal.compiler.ptx/src/com/oracle/graal/compiler/ptx/PTXTargetMethodAssembler.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/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/bridge/CompilerToGPU.java
! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/bridge/CompilerToGPUImpl.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/stubs/Stub.java
! graal/com.oracle.graal.java.decompiler.test/src/com/oracle/graal/java/decompiler/test/TestUtil.java
! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/TruffleCompilerImpl.java
! src/gpu/ptx/gpu_ptx.cpp
! src/gpu/ptx/gpu_ptx.hpp
! src/share/vm/classfile/systemDictionary.hpp
! src/share/vm/classfile/vmSymbols.hpp
! src/share/vm/code/nmethod.hpp
! src/share/vm/graal/graalCompilerToGPU.cpp
! src/share/vm/graal/graalCompilerToVM.cpp
! src/share/vm/graal/graalEnv.cpp
! src/share/vm/graal/graalJavaAccess.hpp
! src/share/vm/runtime/gpu.hpp

Changeset: de164e8e7c4d
Author:    Morris Meyer <morris.meyer at oracle.com>
Date:      2013-06-29 21:52 -0400
URL:       http://hg.openjdk.java.net/graal/graal/rev/de164e8e7c4d

ExternalCompilationResult serialization

! graal/com.oracle.graal.api.code/src/com/oracle/graal/api/code/ExternalCompilationResult.java

Changeset: c98fe0c0f4e1
Author:    Morris Meyer <morris.meyer at oracle.com>
Date:      2013-06-29 21:53 -0400
URL:       http://hg.openjdk.java.net/graal/graal/rev/c98fe0c0f4e1

ExternalCompilationResult gate fix

! graal/com.oracle.graal.api.code/src/com/oracle/graal/api/code/ExternalCompilationResult.java

Changeset: d1452dc23579
Author:    Morris Meyer <morris.meyer at oracle.com>
Date:      2013-06-29 21:57 -0400
URL:       http://hg.openjdk.java.net/graal/graal/rev/d1452dc23579

PTX invcation test fixes

! graal/com.oracle.graal.compiler.ptx.test/src/com/oracle/graal/compiler/ptx/test/BasicPTXTest.java
! graal/com.oracle.graal.compiler.ptx.test/src/com/oracle/graal/compiler/ptx/test/PTXTestBase.java

Changeset: 63d0eaa9b25d
Author:    Morris Meyer <morris.meyer at oracle.com>
Date:      2013-06-29 22:06 -0400
URL:       http://hg.openjdk.java.net/graal/graal/rev/63d0eaa9b25d

PTX checkstyle nits

! graal/com.oracle.graal.api.code/src/com/oracle/graal/api/code/ExternalCompilationResult.java
! graal/com.oracle.graal.compiler.ptx.test/src/com/oracle/graal/compiler/ptx/test/PTXTestBase.java
! graal/com.oracle.graal.compiler.ptx/src/com/oracle/graal/compiler/ptx/PTXTargetMethodAssembler.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

Changeset: 6cb9516d7036
Author:    Morris Meyer <morris.meyer at oracle.com>
Date:      2013-06-30 11:19 -0400
URL:       http://hg.openjdk.java.net/graal/graal/rev/6cb9516d7036

Ensure compilation in System_currentTimeMillis02

! graal/com.oracle.graal.jtt/src/com/oracle/graal/jtt/jdk/System_currentTimeMillis02.java

Changeset: 9af370c1fdf0
Author:    Morris Meyer <morris.meyer at oracle.com>
Date:      2013-06-30 11:19 -0400
URL:       http://hg.openjdk.java.net/graal/graal/rev/9af370c1fdf0

Disable PTX invocation

! graal/com.oracle.graal.compiler.ptx.test/src/com/oracle/graal/compiler/ptx/test/BasicPTXTest.java

Changeset: ace9e84cc773
Author:    Morris Meyer <morris.meyer at oracle.com>
Date:      2013-06-30 11:24 -0400
URL:       http://hg.openjdk.java.net/graal/graal/rev/ace9e84cc773

System_currentTimeMillis02 checkstyle nit

! graal/com.oracle.graal.jtt/src/com/oracle/graal/jtt/jdk/System_currentTimeMillis02.java

Changeset: be8b942f448f
Author:    Doug Simon <doug.simon at oracle.com>
Date:      2013-07-01 10:52 +0200
URL:       http://hg.openjdk.java.net/graal/graal/rev/be8b942f448f

made parsing of mx/env more robust

! mxtool/mx.py

Changeset: 110434bc2913
Author:    Roland Schatz <roland.schatz at oracle.com>
Date:      2013-07-01 11:46 +0200
URL:       http://hg.openjdk.java.net/graal/graal/rev/110434bc2913

Remove unnecessary class.

! 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

Changeset: e43bb3295475
Author:    Roland Schatz <roland.schatz at oracle.com>
Date:      2013-07-01 11:47 +0200
URL:       http://hg.openjdk.java.net/graal/graal/rev/e43bb3295475

Make newArray stubs reexecutable.

! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotRuntime.java

Changeset: b0b368d38b40
Author:    Morris Meyer <morris.meyer at oracle.com>
Date:      2013-07-01 15:46 -0400
URL:       http://hg.openjdk.java.net/graal/graal/rev/b0b368d38b40

CR-1032 - change ExternalCompilationResult kernel -> entryPoint

! graal/com.oracle.graal.api.code/src/com/oracle/graal/api/code/ExternalCompilationResult.java
! graal/com.oracle.graal.compiler.ptx/src/com/oracle/graal/compiler/ptx/PTXTargetMethodAssembler.java
! src/gpu/ptx/gpu_ptx.cpp
! src/share/vm/graal/graalCompilerToVM.cpp
! src/share/vm/graal/graalJavaAccess.hpp

Changeset: 17c5cc84560b
Author:    Roland Schatz <roland.schatz at oracle.com>
Date:      2013-07-02 10:17 +0200
URL:       http://hg.openjdk.java.net/graal/graal/rev/17c5cc84560b

Factor out common code of NewArrayNode and DynamicNewArrayNode.

+ graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/java/AbstractNewArrayNode.java
! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/java/DynamicNewArrayNode.java
! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/java/NewArrayNode.java

Changeset: 6eb8d63cea34
Author:    Christian Humer <christian.humer at gmail.com>
Date:      2013-06-26 17:21 +0200
URL:       http://hg.openjdk.java.net/graal/graal/rev/6eb8d63cea34

Added a feature to trace rewrites of truffle nodes.

+ graal/com.oracle.truffle.api/src/com/oracle/truffle/api/TruffleOptions.java
! graal/com.oracle.truffle.api/src/com/oracle/truffle/api/nodes/Node.java

Changeset: 3cc5fb59916e
Author:    Christian Humer <christian.humer at gmail.com>
Date:      2013-06-28 12:19 +0200
URL:       http://hg.openjdk.java.net/graal/graal/rev/3cc5fb59916e

Truffle-DSL: Renamed @NodeClass to @NodeContainer. splitByMethodName is not an option anymore and is always enabled if a @NodeContainer is used.

- graal/com.oracle.truffle.api.codegen.test/src/com/oracle/truffle/api/codegen/test/BuiltinTest.java
+ graal/com.oracle.truffle.api.codegen.test/src/com/oracle/truffle/api/codegen/test/NodeContainerTest.java
! graal/com.oracle.truffle.api.codegen.test/src/com/oracle/truffle/api/codegen/test/TestHelper.java
! graal/com.oracle.truffle.api.codegen.test/src/com/oracle/truffle/api/codegen/test/package-info.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/NodeClass.java
+ graal/com.oracle.truffle.api.codegen/src/com/oracle/truffle/api/codegen/NodeContainer.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/NodeParser.java

Changeset: 99b58803d6d9
Author:    Christian Humer <christian.humer at gmail.com>
Date:      2013-07-01 20:24 +0200
URL:       http://hg.openjdk.java.net/graal/graal/rev/99b58803d6d9

Truffle-DSL: API changes for new polymorphic caching feature.

+ graal/com.oracle.truffle.api.codegen.test/src/com/oracle/truffle/api/codegen/test/PolymorphicTest.java
+ graal/com.oracle.truffle.api.codegen/src/com/oracle/truffle/api/codegen/PolymorphicLimit.java
! graal/com.oracle.truffle.api/src/com/oracle/truffle/api/nodes/Node.java
! graal/com.oracle.truffle.api/src/com/oracle/truffle/api/nodes/NodeInfo.java

Changeset: 447465567e6f
Author:    Christian Humer <christian.humer at gmail.com>
Date:      2013-07-01 20:28 +0200
URL:       http://hg.openjdk.java.net/graal/graal/rev/447465567e6f

Truffle-DSL: API change: removed useSpecializations in @Generic. The way of specifying this behaviour now is to create a @Specialization which won't rewrite. This way there is no generic case anymore which could use the specializations for its implementation.

! graal/com.oracle.truffle.api.codegen/src/com/oracle/truffle/api/codegen/Generic.java
! graal/com.oracle.truffle.sl/src/com/oracle/truffle/sl/nodes/FrameSlotNode.java
! graal/com.oracle.truffle.sl/src/com/oracle/truffle/sl/nodes/LessThanNode.java
! graal/com.oracle.truffle.sl/src/com/oracle/truffle/sl/nodes/PrintNode.java
! graal/com.oracle.truffle.sl/src/com/oracle/truffle/sl/nodes/ReadLocalNode.java
! graal/com.oracle.truffle.sl/src/com/oracle/truffle/sl/nodes/TernaryNode.java
! graal/com.oracle.truffle.sl/src/com/oracle/truffle/sl/nodes/WriteLocalNode.java

Changeset: 72e6b178de16
Author:    Christian Humer <christian.humer at gmail.com>
Date:      2013-07-01 20:29 +0200
URL:       http://hg.openjdk.java.net/graal/graal/rev/72e6b178de16

Truffle-DSL: added a few missing types to the dsl tests.

! graal/com.oracle.truffle.api.codegen.test/src/com/oracle/truffle/api/codegen/test/TypeSystemTest.java

Changeset: 47233c73ca58
Author:    Christian Humer <christian.humer at gmail.com>
Date:      2013-07-01 20:31 +0200
URL:       http://hg.openjdk.java.net/graal/graal/rev/47233c73ca58

Truffle-DSL: API change: Renamed createNodeSpecialized to createNodeGeneric. There was not a known use-case for createNodeSpecialized so we decided to replace it with a simpler version.

! graal/com.oracle.truffle.api.codegen/src/com/oracle/truffle/api/codegen/NodeFactory.java

Changeset: f43eb2f1bbbc
Author:    Christian Humer <christian.humer at gmail.com>
Date:      2013-07-01 20:32 +0200
URL:       http://hg.openjdk.java.net/graal/graal/rev/f43eb2f1bbbc

Truffle-DSL: code-generation of polymorphic caching

! 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/ExecutableTypeData.java
! graal/com.oracle.truffle.codegen.processor/src/com/oracle/truffle/codegen/processor/node/ExecutableTypeMethodParser.java
! graal/com.oracle.truffle.codegen.processor/src/com/oracle/truffle/codegen/processor/node/GenericParser.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/NodeParser.java
! graal/com.oracle.truffle.codegen.processor/src/com/oracle/truffle/codegen/processor/node/SpecializationData.java
! graal/com.oracle.truffle.codegen.processor/src/com/oracle/truffle/codegen/processor/template/ActualParameter.java
! graal/com.oracle.truffle.codegen.processor/src/com/oracle/truffle/codegen/processor/template/TemplateMethod.java

Changeset: 79041ab43660
Author:    Christian Humer <christian.humer at gmail.com>
Date:      2013-07-01 20:58 +0200
URL:       http://hg.openjdk.java.net/graal/graal/rev/79041ab43660

Truffle-DSL: API-change: Renamed truffle.api.codegen to truffle.api.dsl for all projects and packages.

- graal/com.oracle.truffle.api.codegen.test/src/com/oracle/truffle/api/codegen/test/AssumptionsTest.java
- graal/com.oracle.truffle.api.codegen.test/src/com/oracle/truffle/api/codegen/test/BinaryNodeTest.java
- graal/com.oracle.truffle.api.codegen.test/src/com/oracle/truffle/api/codegen/test/ExecuteEvaluatedTest.java
- graal/com.oracle.truffle.api.codegen.test/src/com/oracle/truffle/api/codegen/test/GuardsTest.java
- graal/com.oracle.truffle.api.codegen.test/src/com/oracle/truffle/api/codegen/test/NodeContainerTest.java
- graal/com.oracle.truffle.api.codegen.test/src/com/oracle/truffle/api/codegen/test/PolymorphicTest.java
- graal/com.oracle.truffle.api.codegen.test/src/com/oracle/truffle/api/codegen/test/TestHelper.java
- graal/com.oracle.truffle.api.codegen.test/src/com/oracle/truffle/api/codegen/test/TypeSystemTest.java
- graal/com.oracle.truffle.api.codegen.test/src/com/oracle/truffle/api/codegen/test/package-info.java
- graal/com.oracle.truffle.api.codegen/src/com/oracle/truffle/api/codegen/CreateCast.java
- graal/com.oracle.truffle.api.codegen/src/com/oracle/truffle/api/codegen/GeneratedBy.java
- graal/com.oracle.truffle.api.codegen/src/com/oracle/truffle/api/codegen/Generic.java
- graal/com.oracle.truffle.api.codegen/src/com/oracle/truffle/api/codegen/NodeAssumptions.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/NodeChildren.java
- graal/com.oracle.truffle.api.codegen/src/com/oracle/truffle/api/codegen/NodeContainer.java
- graal/com.oracle.truffle.api.codegen/src/com/oracle/truffle/api/codegen/NodeFactory.java
- graal/com.oracle.truffle.api.codegen/src/com/oracle/truffle/api/codegen/NodeId.java
- graal/com.oracle.truffle.api.codegen/src/com/oracle/truffle/api/codegen/PolymorphicLimit.java
- graal/com.oracle.truffle.api.codegen/src/com/oracle/truffle/api/codegen/ShortCircuit.java
- graal/com.oracle.truffle.api.codegen/src/com/oracle/truffle/api/codegen/Specialization.java
- graal/com.oracle.truffle.api.codegen/src/com/oracle/truffle/api/codegen/SpecializationListener.java
- graal/com.oracle.truffle.api.codegen/src/com/oracle/truffle/api/codegen/TypeCast.java
- graal/com.oracle.truffle.api.codegen/src/com/oracle/truffle/api/codegen/TypeCheck.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.api.dsl.test/src/com/oracle/truffle/api/dsl/test/AssumptionsTest.java
+ graal/com.oracle.truffle.api.dsl.test/src/com/oracle/truffle/api/dsl/test/BinaryNodeTest.java
+ graal/com.oracle.truffle.api.dsl.test/src/com/oracle/truffle/api/dsl/test/ExecuteEvaluatedTest.java
+ graal/com.oracle.truffle.api.dsl.test/src/com/oracle/truffle/api/dsl/test/GuardsTest.java
+ graal/com.oracle.truffle.api.dsl.test/src/com/oracle/truffle/api/dsl/test/NodeContainerTest.java
+ graal/com.oracle.truffle.api.dsl.test/src/com/oracle/truffle/api/dsl/test/PolymorphicTest.java
+ graal/com.oracle.truffle.api.dsl.test/src/com/oracle/truffle/api/dsl/test/TestHelper.java
+ graal/com.oracle.truffle.api.dsl.test/src/com/oracle/truffle/api/dsl/test/TypeSystemTest.java
+ graal/com.oracle.truffle.api.dsl.test/src/com/oracle/truffle/api/dsl/test/package-info.java
+ graal/com.oracle.truffle.api.dsl/src/com/oracle/truffle/api/dsl/CreateCast.java
+ graal/com.oracle.truffle.api.dsl/src/com/oracle/truffle/api/dsl/GeneratedBy.java
+ graal/com.oracle.truffle.api.dsl/src/com/oracle/truffle/api/dsl/Generic.java
+ graal/com.oracle.truffle.api.dsl/src/com/oracle/truffle/api/dsl/NodeAssumptions.java
+ graal/com.oracle.truffle.api.dsl/src/com/oracle/truffle/api/dsl/NodeChild.java
+ graal/com.oracle.truffle.api.dsl/src/com/oracle/truffle/api/dsl/NodeChildren.java
+ graal/com.oracle.truffle.api.dsl/src/com/oracle/truffle/api/dsl/NodeContainer.java
+ graal/com.oracle.truffle.api.dsl/src/com/oracle/truffle/api/dsl/NodeFactory.java
+ graal/com.oracle.truffle.api.dsl/src/com/oracle/truffle/api/dsl/NodeId.java
+ graal/com.oracle.truffle.api.dsl/src/com/oracle/truffle/api/dsl/PolymorphicLimit.java
+ graal/com.oracle.truffle.api.dsl/src/com/oracle/truffle/api/dsl/ShortCircuit.java
+ graal/com.oracle.truffle.api.dsl/src/com/oracle/truffle/api/dsl/Specialization.java
+ graal/com.oracle.truffle.api.dsl/src/com/oracle/truffle/api/dsl/SpecializationListener.java
+ graal/com.oracle.truffle.api.dsl/src/com/oracle/truffle/api/dsl/TypeCast.java
+ graal/com.oracle.truffle.api.dsl/src/com/oracle/truffle/api/dsl/TypeCheck.java
+ graal/com.oracle.truffle.api.dsl/src/com/oracle/truffle/api/dsl/TypeSystem.java
+ graal/com.oracle.truffle.api.dsl/src/com/oracle/truffle/api/dsl/TypeSystemReference.java
- graal/com.oracle.truffle.codegen.processor/src/META-INF/services/javax.annotation.processing.Processor
- graal/com.oracle.truffle.codegen.processor/src/com/oracle/truffle/codegen/processor/AbstractParser.java
- graal/com.oracle.truffle.codegen.processor/src/com/oracle/truffle/codegen/processor/AnnotationProcessor.java
- graal/com.oracle.truffle.codegen.processor/src/com/oracle/truffle/codegen/processor/CompileErrorException.java
- graal/com.oracle.truffle.codegen.processor/src/com/oracle/truffle/codegen/processor/Log.java
- graal/com.oracle.truffle.codegen.processor/src/com/oracle/truffle/codegen/processor/ProcessorContext.java
- graal/com.oracle.truffle.codegen.processor/src/com/oracle/truffle/codegen/processor/TruffleProcessor.java
- graal/com.oracle.truffle.codegen.processor/src/com/oracle/truffle/codegen/processor/TruffleTypes.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/api/ExtensionContext.java
- graal/com.oracle.truffle.codegen.processor/src/com/oracle/truffle/codegen/processor/api/ExtensionProcessor.java
- graal/com.oracle.truffle.codegen.processor/src/com/oracle/truffle/codegen/processor/api/element/WritableAnnotationMirror.java
- graal/com.oracle.truffle.codegen.processor/src/com/oracle/truffle/codegen/processor/api/element/WritableElement.java
- graal/com.oracle.truffle.codegen.processor/src/com/oracle/truffle/codegen/processor/api/element/WritableElementFactory.java
- graal/com.oracle.truffle.codegen.processor/src/com/oracle/truffle/codegen/processor/api/element/WritableExecutableElement.java
- graal/com.oracle.truffle.codegen.processor/src/com/oracle/truffle/codegen/processor/api/element/WritableVariableElement.java
- graal/com.oracle.truffle.codegen.processor/src/com/oracle/truffle/codegen/processor/ast/CodeAnnotationMirror.java
- graal/com.oracle.truffle.codegen.processor/src/com/oracle/truffle/codegen/processor/ast/CodeAnnotationValue.java
- graal/com.oracle.truffle.codegen.processor/src/com/oracle/truffle/codegen/processor/ast/CodeCompilationUnit.java
- graal/com.oracle.truffle.codegen.processor/src/com/oracle/truffle/codegen/processor/ast/CodeElement.java
- graal/com.oracle.truffle.codegen.processor/src/com/oracle/truffle/codegen/processor/ast/CodeElementScanner.java
- graal/com.oracle.truffle.codegen.processor/src/com/oracle/truffle/codegen/processor/ast/CodeExecutableElement.java
- graal/com.oracle.truffle.codegen.processor/src/com/oracle/truffle/codegen/processor/ast/CodeImport.java
- graal/com.oracle.truffle.codegen.processor/src/com/oracle/truffle/codegen/processor/ast/CodeNames.java
- graal/com.oracle.truffle.codegen.processor/src/com/oracle/truffle/codegen/processor/ast/CodeTree.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/ast/CodeTreeKind.java
- graal/com.oracle.truffle.codegen.processor/src/com/oracle/truffle/codegen/processor/ast/CodeTreeVariable.java
- graal/com.oracle.truffle.codegen.processor/src/com/oracle/truffle/codegen/processor/ast/CodeTypeElement.java
- graal/com.oracle.truffle.codegen.processor/src/com/oracle/truffle/codegen/processor/ast/CodeTypeMirror.java
- graal/com.oracle.truffle.codegen.processor/src/com/oracle/truffle/codegen/processor/ast/CodeVariableElement.java
- graal/com.oracle.truffle.codegen.processor/src/com/oracle/truffle/codegen/processor/ast/GeneratedElement.java
- graal/com.oracle.truffle.codegen.processor/src/com/oracle/truffle/codegen/processor/codewriter/AbstractCodeWriter.java
- graal/com.oracle.truffle.codegen.processor/src/com/oracle/truffle/codegen/processor/codewriter/FixWarningsVisitor.java
- graal/com.oracle.truffle.codegen.processor/src/com/oracle/truffle/codegen/processor/codewriter/GenerateOverrideVisitor.java
- graal/com.oracle.truffle.codegen.processor/src/com/oracle/truffle/codegen/processor/codewriter/OrganizedImports.java
- graal/com.oracle.truffle.codegen.processor/src/com/oracle/truffle/codegen/processor/compiler/AbstractCompiler.java
- graal/com.oracle.truffle.codegen.processor/src/com/oracle/truffle/codegen/processor/compiler/Compiler.java
- graal/com.oracle.truffle.codegen.processor/src/com/oracle/truffle/codegen/processor/compiler/CompilerFactory.java
- graal/com.oracle.truffle.codegen.processor/src/com/oracle/truffle/codegen/processor/compiler/JDTCompiler.java
- graal/com.oracle.truffle.codegen.processor/src/com/oracle/truffle/codegen/processor/compiler/JavaCCompiler.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/ExecutableTypeData.java
- graal/com.oracle.truffle.codegen.processor/src/com/oracle/truffle/codegen/processor/node/ExecutableTypeMethodParser.java
- graal/com.oracle.truffle.codegen.processor/src/com/oracle/truffle/codegen/processor/node/GenericParser.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/NodeFieldData.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/ShortCircuitData.java
- graal/com.oracle.truffle.codegen.processor/src/com/oracle/truffle/codegen/processor/node/ShortCircuitParser.java
- graal/com.oracle.truffle.codegen.processor/src/com/oracle/truffle/codegen/processor/node/SpecializationData.java
- graal/com.oracle.truffle.codegen.processor/src/com/oracle/truffle/codegen/processor/node/SpecializationGuardData.java
- graal/com.oracle.truffle.codegen.processor/src/com/oracle/truffle/codegen/processor/node/SpecializationListenerData.java
- graal/com.oracle.truffle.codegen.processor/src/com/oracle/truffle/codegen/processor/node/SpecializationListenerParser.java
- graal/com.oracle.truffle.codegen.processor/src/com/oracle/truffle/codegen/processor/node/SpecializationMethodParser.java
- graal/com.oracle.truffle.codegen.processor/src/com/oracle/truffle/codegen/processor/node/SpecializationThrowsData.java
- graal/com.oracle.truffle.codegen.processor/src/com/oracle/truffle/codegen/processor/template/ActualParameter.java
- graal/com.oracle.truffle.codegen.processor/src/com/oracle/truffle/codegen/processor/template/ClassElementFactory.java
- graal/com.oracle.truffle.codegen.processor/src/com/oracle/truffle/codegen/processor/template/CodeElementFactory.java
- graal/com.oracle.truffle.codegen.processor/src/com/oracle/truffle/codegen/processor/template/CompilationUnitFactory.java
- graal/com.oracle.truffle.codegen.processor/src/com/oracle/truffle/codegen/processor/template/JavaName.java
- graal/com.oracle.truffle.codegen.processor/src/com/oracle/truffle/codegen/processor/template/MessageContainer.java
- graal/com.oracle.truffle.codegen.processor/src/com/oracle/truffle/codegen/processor/template/MethodSpec.java
- graal/com.oracle.truffle.codegen.processor/src/com/oracle/truffle/codegen/processor/template/ParameterSpec.java
- graal/com.oracle.truffle.codegen.processor/src/com/oracle/truffle/codegen/processor/template/Template.java
- graal/com.oracle.truffle.codegen.processor/src/com/oracle/truffle/codegen/processor/template/TemplateMethod.java
- graal/com.oracle.truffle.codegen.processor/src/com/oracle/truffle/codegen/processor/template/TemplateMethodParser.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/GuardData.java
- graal/com.oracle.truffle.codegen.processor/src/com/oracle/truffle/codegen/processor/typesystem/GuardParser.java
- graal/com.oracle.truffle.codegen.processor/src/com/oracle/truffle/codegen/processor/typesystem/TypeCastData.java
- graal/com.oracle.truffle.codegen.processor/src/com/oracle/truffle/codegen/processor/typesystem/TypeCastParser.java
- graal/com.oracle.truffle.codegen.processor/src/com/oracle/truffle/codegen/processor/typesystem/TypeCheckData.java
- graal/com.oracle.truffle.codegen.processor/src/com/oracle/truffle/codegen/processor/typesystem/TypeCheckParser.java
- graal/com.oracle.truffle.codegen.processor/src/com/oracle/truffle/codegen/processor/typesystem/TypeData.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/TypeSystemData.java
- graal/com.oracle.truffle.codegen.processor/src/com/oracle/truffle/codegen/processor/typesystem/TypeSystemMethodParser.java
- graal/com.oracle.truffle.codegen.processor/src/com/oracle/truffle/codegen/processor/typesystem/TypeSystemParser.java
+ graal/com.oracle.truffle.dsl.processor/src/META-INF/services/javax.annotation.processing.Processor
+ graal/com.oracle.truffle.dsl.processor/src/com/oracle/truffle/dsl/processor/AbstractParser.java
+ graal/com.oracle.truffle.dsl.processor/src/com/oracle/truffle/dsl/processor/AnnotationProcessor.java
+ graal/com.oracle.truffle.dsl.processor/src/com/oracle/truffle/dsl/processor/CompileErrorException.java
+ graal/com.oracle.truffle.dsl.processor/src/com/oracle/truffle/dsl/processor/Log.java
+ graal/com.oracle.truffle.dsl.processor/src/com/oracle/truffle/dsl/processor/ProcessorContext.java
+ graal/com.oracle.truffle.dsl.processor/src/com/oracle/truffle/dsl/processor/TruffleProcessor.java
+ graal/com.oracle.truffle.dsl.processor/src/com/oracle/truffle/dsl/processor/TruffleTypes.java
+ graal/com.oracle.truffle.dsl.processor/src/com/oracle/truffle/dsl/processor/Utils.java
+ graal/com.oracle.truffle.dsl.processor/src/com/oracle/truffle/dsl/processor/api/ExtensionContext.java
+ graal/com.oracle.truffle.dsl.processor/src/com/oracle/truffle/dsl/processor/api/ExtensionProcessor.java
+ graal/com.oracle.truffle.dsl.processor/src/com/oracle/truffle/dsl/processor/api/element/WritableAnnotationMirror.java
+ graal/com.oracle.truffle.dsl.processor/src/com/oracle/truffle/dsl/processor/api/element/WritableElement.java
+ graal/com.oracle.truffle.dsl.processor/src/com/oracle/truffle/dsl/processor/api/element/WritableElementFactory.java
+ graal/com.oracle.truffle.dsl.processor/src/com/oracle/truffle/dsl/processor/api/element/WritableExecutableElement.java
+ graal/com.oracle.truffle.dsl.processor/src/com/oracle/truffle/dsl/processor/api/element/WritableVariableElement.java
+ graal/com.oracle.truffle.dsl.processor/src/com/oracle/truffle/dsl/processor/ast/CodeAnnotationMirror.java
+ graal/com.oracle.truffle.dsl.processor/src/com/oracle/truffle/dsl/processor/ast/CodeAnnotationValue.java
+ graal/com.oracle.truffle.dsl.processor/src/com/oracle/truffle/dsl/processor/ast/CodeCompilationUnit.java
+ graal/com.oracle.truffle.dsl.processor/src/com/oracle/truffle/dsl/processor/ast/CodeElement.java
+ graal/com.oracle.truffle.dsl.processor/src/com/oracle/truffle/dsl/processor/ast/CodeElementScanner.java
+ graal/com.oracle.truffle.dsl.processor/src/com/oracle/truffle/dsl/processor/ast/CodeExecutableElement.java
+ graal/com.oracle.truffle.dsl.processor/src/com/oracle/truffle/dsl/processor/ast/CodeImport.java
+ graal/com.oracle.truffle.dsl.processor/src/com/oracle/truffle/dsl/processor/ast/CodeNames.java
+ graal/com.oracle.truffle.dsl.processor/src/com/oracle/truffle/dsl/processor/ast/CodeTree.java
+ graal/com.oracle.truffle.dsl.processor/src/com/oracle/truffle/dsl/processor/ast/CodeTreeBuilder.java
+ graal/com.oracle.truffle.dsl.processor/src/com/oracle/truffle/dsl/processor/ast/CodeTreeKind.java
+ graal/com.oracle.truffle.dsl.processor/src/com/oracle/truffle/dsl/processor/ast/CodeTreeVariable.java
+ graal/com.oracle.truffle.dsl.processor/src/com/oracle/truffle/dsl/processor/ast/CodeTypeElement.java
+ graal/com.oracle.truffle.dsl.processor/src/com/oracle/truffle/dsl/processor/ast/CodeTypeMirror.java
+ graal/com.oracle.truffle.dsl.processor/src/com/oracle/truffle/dsl/processor/ast/CodeVariableElement.java
+ graal/com.oracle.truffle.dsl.processor/src/com/oracle/truffle/dsl/processor/ast/GeneratedElement.java
+ graal/com.oracle.truffle.dsl.processor/src/com/oracle/truffle/dsl/processor/codewriter/AbstractCodeWriter.java
+ graal/com.oracle.truffle.dsl.processor/src/com/oracle/truffle/dsl/processor/codewriter/FixWarningsVisitor.java
+ graal/com.oracle.truffle.dsl.processor/src/com/oracle/truffle/dsl/processor/codewriter/GenerateOverrideVisitor.java
+ graal/com.oracle.truffle.dsl.processor/src/com/oracle/truffle/dsl/processor/codewriter/OrganizedImports.java
+ graal/com.oracle.truffle.dsl.processor/src/com/oracle/truffle/dsl/processor/compiler/AbstractCompiler.java
+ graal/com.oracle.truffle.dsl.processor/src/com/oracle/truffle/dsl/processor/compiler/Compiler.java
+ graal/com.oracle.truffle.dsl.processor/src/com/oracle/truffle/dsl/processor/compiler/CompilerFactory.java
+ graal/com.oracle.truffle.dsl.processor/src/com/oracle/truffle/dsl/processor/compiler/JDTCompiler.java
+ graal/com.oracle.truffle.dsl.processor/src/com/oracle/truffle/dsl/processor/compiler/JavaCCompiler.java
+ graal/com.oracle.truffle.dsl.processor/src/com/oracle/truffle/dsl/processor/node/CreateCastData.java
+ graal/com.oracle.truffle.dsl.processor/src/com/oracle/truffle/dsl/processor/node/CreateCastParser.java
+ graal/com.oracle.truffle.dsl.processor/src/com/oracle/truffle/dsl/processor/node/ExecutableTypeData.java
+ graal/com.oracle.truffle.dsl.processor/src/com/oracle/truffle/dsl/processor/node/ExecutableTypeMethodParser.java
+ graal/com.oracle.truffle.dsl.processor/src/com/oracle/truffle/dsl/processor/node/GenericParser.java
+ graal/com.oracle.truffle.dsl.processor/src/com/oracle/truffle/dsl/processor/node/NodeChildData.java
+ graal/com.oracle.truffle.dsl.processor/src/com/oracle/truffle/dsl/processor/node/NodeCodeGenerator.java
+ graal/com.oracle.truffle.dsl.processor/src/com/oracle/truffle/dsl/processor/node/NodeData.java
+ graal/com.oracle.truffle.dsl.processor/src/com/oracle/truffle/dsl/processor/node/NodeFieldData.java
+ graal/com.oracle.truffle.dsl.processor/src/com/oracle/truffle/dsl/processor/node/NodeMethodParser.java
+ graal/com.oracle.truffle.dsl.processor/src/com/oracle/truffle/dsl/processor/node/NodeParser.java
+ graal/com.oracle.truffle.dsl.processor/src/com/oracle/truffle/dsl/processor/node/ShortCircuitData.java
+ graal/com.oracle.truffle.dsl.processor/src/com/oracle/truffle/dsl/processor/node/ShortCircuitParser.java
+ graal/com.oracle.truffle.dsl.processor/src/com/oracle/truffle/dsl/processor/node/SpecializationData.java
+ graal/com.oracle.truffle.dsl.processor/src/com/oracle/truffle/dsl/processor/node/SpecializationGuardData.java
+ graal/com.oracle.truffle.dsl.processor/src/com/oracle/truffle/dsl/processor/node/SpecializationListenerData.java
+ graal/com.oracle.truffle.dsl.processor/src/com/oracle/truffle/dsl/processor/node/SpecializationListenerParser.java
+ graal/com.oracle.truffle.dsl.processor/src/com/oracle/truffle/dsl/processor/node/SpecializationMethodParser.java
+ graal/com.oracle.truffle.dsl.processor/src/com/oracle/truffle/dsl/processor/node/SpecializationThrowsData.java
+ graal/com.oracle.truffle.dsl.processor/src/com/oracle/truffle/dsl/processor/template/ActualParameter.java
+ graal/com.oracle.truffle.dsl.processor/src/com/oracle/truffle/dsl/processor/template/ClassElementFactory.java
+ graal/com.oracle.truffle.dsl.processor/src/com/oracle/truffle/dsl/processor/template/CodeElementFactory.java
+ graal/com.oracle.truffle.dsl.processor/src/com/oracle/truffle/dsl/processor/template/CompilationUnitFactory.java
+ graal/com.oracle.truffle.dsl.processor/src/com/oracle/truffle/dsl/processor/template/JavaName.java
+ graal/com.oracle.truffle.dsl.processor/src/com/oracle/truffle/dsl/processor/template/MessageContainer.java
+ graal/com.oracle.truffle.dsl.processor/src/com/oracle/truffle/dsl/processor/template/MethodSpec.java
+ graal/com.oracle.truffle.dsl.processor/src/com/oracle/truffle/dsl/processor/template/ParameterSpec.java
+ graal/com.oracle.truffle.dsl.processor/src/com/oracle/truffle/dsl/processor/template/Template.java
+ graal/com.oracle.truffle.dsl.processor/src/com/oracle/truffle/dsl/processor/template/TemplateMethod.java
+ graal/com.oracle.truffle.dsl.processor/src/com/oracle/truffle/dsl/processor/template/TemplateMethodParser.java
+ graal/com.oracle.truffle.dsl.processor/src/com/oracle/truffle/dsl/processor/template/TemplateParser.java
+ graal/com.oracle.truffle.dsl.processor/src/com/oracle/truffle/dsl/processor/typesystem/GuardData.java
+ graal/com.oracle.truffle.dsl.processor/src/com/oracle/truffle/dsl/processor/typesystem/GuardParser.java
+ graal/com.oracle.truffle.dsl.processor/src/com/oracle/truffle/dsl/processor/typesystem/TypeCastData.java
+ graal/com.oracle.truffle.dsl.processor/src/com/oracle/truffle/dsl/processor/typesystem/TypeCastParser.java
+ graal/com.oracle.truffle.dsl.processor/src/com/oracle/truffle/dsl/processor/typesystem/TypeCheckData.java
+ graal/com.oracle.truffle.dsl.processor/src/com/oracle/truffle/dsl/processor/typesystem/TypeCheckParser.java
+ graal/com.oracle.truffle.dsl.processor/src/com/oracle/truffle/dsl/processor/typesystem/TypeData.java
+ graal/com.oracle.truffle.dsl.processor/src/com/oracle/truffle/dsl/processor/typesystem/TypeSystemCodeGenerator.java
+ graal/com.oracle.truffle.dsl.processor/src/com/oracle/truffle/dsl/processor/typesystem/TypeSystemData.java
+ graal/com.oracle.truffle.dsl.processor/src/com/oracle/truffle/dsl/processor/typesystem/TypeSystemMethodParser.java
+ graal/com.oracle.truffle.dsl.processor/src/com/oracle/truffle/dsl/processor/typesystem/TypeSystemParser.java
! graal/com.oracle.truffle.sl/src/com/oracle/truffle/sl/SLNode.java
! graal/com.oracle.truffle.sl/src/com/oracle/truffle/sl/SLTypes.java
! graal/com.oracle.truffle.sl/src/com/oracle/truffle/sl/nodes/ArithmeticNode.java
! graal/com.oracle.truffle.sl/src/com/oracle/truffle/sl/nodes/BigIntegerLiteralNode.java
! graal/com.oracle.truffle.sl/src/com/oracle/truffle/sl/nodes/BinaryNode.java
! graal/com.oracle.truffle.sl/src/com/oracle/truffle/sl/nodes/IfNode.java
! graal/com.oracle.truffle.sl/src/com/oracle/truffle/sl/nodes/IntegerLiteralNode.java
! graal/com.oracle.truffle.sl/src/com/oracle/truffle/sl/nodes/LessThanNode.java
! graal/com.oracle.truffle.sl/src/com/oracle/truffle/sl/nodes/LogicalAndNode.java
! graal/com.oracle.truffle.sl/src/com/oracle/truffle/sl/nodes/PrintNode.java
! graal/com.oracle.truffle.sl/src/com/oracle/truffle/sl/nodes/ReadLocalNode.java
! graal/com.oracle.truffle.sl/src/com/oracle/truffle/sl/nodes/StringLiteralNode.java
! graal/com.oracle.truffle.sl/src/com/oracle/truffle/sl/nodes/TernaryNode.java
! graal/com.oracle.truffle.sl/src/com/oracle/truffle/sl/nodes/TimeNode.java
! graal/com.oracle.truffle.sl/src/com/oracle/truffle/sl/nodes/WriteLocalNode.java
! mx/projects

Changeset: 5b9abb0cc9d8
Author:    Christian Humer <christian.humer at gmail.com>
Date:      2013-07-01 21:07 +0200
URL:       http://hg.openjdk.java.net/graal/graal/rev/5b9abb0cc9d8

Merge.


Changeset: ebf5c5c23564
Author:    Christian Humer <christian.humer at gmail.com>
Date:      2013-07-01 21:08 +0200
URL:       http://hg.openjdk.java.net/graal/graal/rev/ebf5c5c23564

Disabled truffle rewrite trace by default.

! graal/com.oracle.truffle.api/src/com/oracle/truffle/api/TruffleOptions.java

Changeset: e93efe3ba5f4
Author:    Christian Humer <christian.humer at gmail.com>
Date:      2013-07-02 14:51 +0200
URL:       http://hg.openjdk.java.net/graal/graal/rev/e93efe3ba5f4

Truffle-DSL: rewritten polymorphic optimization for simpler generated code.

! graal/com.oracle.truffle.dsl.processor/src/com/oracle/truffle/dsl/processor/node/NodeCodeGenerator.java
! graal/com.oracle.truffle.dsl.processor/src/com/oracle/truffle/dsl/processor/node/NodeData.java
! graal/com.oracle.truffle.dsl.processor/src/com/oracle/truffle/dsl/processor/node/NodeParser.java
! graal/com.oracle.truffle.dsl.processor/src/com/oracle/truffle/dsl/processor/template/TemplateMethod.java
! graal/com.oracle.truffle.dsl.processor/src/com/oracle/truffle/dsl/processor/typesystem/TypeData.java
! graal/com.oracle.truffle.dsl.processor/src/com/oracle/truffle/dsl/processor/typesystem/TypeSystemParser.java

Changeset: 5acc3f3016b7
Author:    Christian Humer <christian.humer at gmail.com>
Date:      2013-07-02 14:51 +0200
URL:       http://hg.openjdk.java.net/graal/graal/rev/5acc3f3016b7

Merge.


Changeset: b8fe1fe004ec
Author:    Christian Humer <christian.humer at gmail.com>
Date:      2013-07-02 19:21 +0200
URL:       http://hg.openjdk.java.net/graal/graal/rev/b8fe1fe004ec

Truffle-DSL: fixed bugs in the generated polymorphic code generation.

! graal/com.oracle.truffle.dsl.processor/src/com/oracle/truffle/dsl/processor/node/NodeCodeGenerator.java
! graal/com.oracle.truffle.dsl.processor/src/com/oracle/truffle/dsl/processor/node/NodeData.java
! graal/com.oracle.truffle.dsl.processor/src/com/oracle/truffle/dsl/processor/node/NodeParser.java
! graal/com.oracle.truffle.dsl.processor/src/com/oracle/truffle/dsl/processor/node/SpecializationData.java
! graal/com.oracle.truffle.dsl.processor/src/com/oracle/truffle/dsl/processor/template/TemplateMethod.java

Changeset: 2e7e7a22940f
Author:    Bernhard Urban <bernhard.urban at jku.at>
Date:      2013-07-01 23:50 +0200
URL:       http://hg.openjdk.java.net/graal/graal/rev/2e7e7a22940f

RightShiftNode: fix canonicalization for negative input

+ graal/com.oracle.graal.jtt/src/com/oracle/graal/jtt/bytecode/BC_lshr02.java
! graal/com.oracle.graal.jtt/src/com/oracle/graal/jtt/optimize/InferStamp01.java
! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/calc/RightShiftNode.java

Changeset: 953a0d51a11f
Author:    Andreas Woess <andreas.woess at jku.at>
Date:      2013-07-03 16:19 +0200
URL:       http://hg.openjdk.java.net/graal/graal/rev/953a0d51a11f

ObjectEqualsNode: fix comparison of virtual boolean against constant object

! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/calc/ObjectEqualsNode.java

Changeset: f0551e15a416
Author:    Bernhard Urban <bernhard.urban at jku.at>
Date:      2013-07-04 13:39 +0200
URL:       http://hg.openjdk.java.net/graal/graal/rev/f0551e15a416

ptx: fix include for non-precompiled header build

! src/share/vm/graal/graalCompilerToGPU.cpp

Changeset: a6c0ae38e05e
Author:    Doug Simon <doug.simon at oracle.com>
Date:      2013-07-04 14:53 +0200
URL:       http://hg.openjdk.java.net/graal/graal/rev/a6c0ae38e05e

more robust command line checking for unittest (at cost of removing support for negative filters)

! mx/commands.py

Changeset: dd5a042811f6
Author:    Doug Simon <doug.simon at oracle.com>
Date:      2013-07-04 15:03 +0200
URL:       http://hg.openjdk.java.net/graal/graal/rev/dd5a042811f6

enhanced debug context for inlining so that inlining hierarchy is correctly shown in IGV
added documentation and toString() implementation for inlining utility classes

! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/InliningPhase.java

Changeset: eeb80dcd60d8
Author:    Doug Simon <doug.simon at oracle.com>
Date:      2013-07-04 15:30 +0200
URL:       http://hg.openjdk.java.net/graal/graal/rev/eeb80dcd60d8

fixed regression in unittest command when no tests are specified

! mx/commands.py

Changeset: 5f016460f95b
Author:    Bernhard Urban <bernhard.urban at jku.at>
Date:      2013-07-05 13:28 +0200
URL:       http://hg.openjdk.java.net/graal/graal/rev/5f016460f95b

scheduling: remove duplicated code

check is already done in CFG.commonDominator()

! graal/com.oracle.graal.phases/src/com/oracle/graal/phases/schedule/SchedulePhase.java

Changeset: 1db97e3de11c
Author:    Roland Schatz <roland.schatz at oracle.com>
Date:      2013-07-05 15:18 +0200
URL:       http://hg.openjdk.java.net/graal/graal/rev/1db97e3de11c

Do not re-compress oops that are already compressed.

! graal/com.oracle.graal.hotspot.amd64/src/com/oracle/graal/hotspot/amd64/AMD64HotSpotLIRGenerator.java

Changeset: 1546866ebb8d
Author:    Thomas Wuerthinger <thomas.wuerthinger at oracle.com>
Date:      2013-07-06 00:29 +0200
URL:       http://hg.openjdk.java.net/graal/graal/rev/1546866ebb8d

First draft of Truffle graph caching.

! graal/com.oracle.graal.api.code/src/com/oracle/graal/api/code/Assumptions.java
! graal/com.oracle.graal.debug/src/com/oracle/graal/debug/Debug.java
! graal/com.oracle.graal.truffle.test/src/com/oracle/graal/truffle/test/PartialEvaluationTest.java
! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/PartialEvaluator.java
+ graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/TruffleCache.java
! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/TruffleCompilerImpl.java
! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/phases/VerifyFrameDoesNotEscapePhase.java

Changeset: 549a7568ce14
Author:    Thomas Wuerthinger <thomas.wuerthinger at oracle.com>
Date:      2013-07-06 11:56 +0200
URL:       http://hg.openjdk.java.net/graal/graal/rev/549a7568ce14

Introduce new Truffle compiler options: TruffleOperationCacheMaxNodes and TraceTruffleCompilationExceptions
Perform inlining for cached Truffle graphs.

! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/FrameWithoutBoxing.java
! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/PartialEvaluator.java
! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/TruffleCache.java
! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/TruffleCompilerOptions.java


From doug.simon at oracle.com  Sun Jul  7 13:58:46 2013
From: doug.simon at oracle.com (Doug Simon)
Date: Sun, 7 Jul 2013 22:58:46 +0200
Subject: NullPointerException in HotSpotRuntime:lower when using Snippets
In-Reply-To: <4AD5DAB8-9F0B-44AD-9FD3-B007DADE45A8@sms.ed.ac.uk>
References: <72C1FE55-E500-47DA-B5DE-831AB7119F3F@sms.ed.ac.uk>
	<1B56654D-BB65-423B-9558-96254F71132F@oracle.com>
	<4AD5DAB8-9F0B-44AD-9FD3-B007DADE45A8@sms.ed.ac.uk>
Message-ID: <BB081FA8-D9FE-45CE-9D14-E6D648C46AB7@oracle.com>

In general, snippets inline any calls they make except for foreign calls. Wha call is not being inlined and do you know why not? You can figure this out by debugging the call to ReplacementsImpl.buildGraph() when your snippet is be processed.

On Jul 6, 2013, at 12:14 AM, ATKIN-GRANVILLE Chris <s1255753 at sms.ed.ac.uk> wrote:

> Thanks for the advice. I tried your suggestions and I can now access fields in the snippet (so far I'm just incrementing a static field). However, if I try to do something a little more fancy like calling a method, I get another exception. I'll investigate further next week, but if you have any suggestions they'd be appreciated. FWIW I tried outputting to stdout whenever a node (i.e., my custom node) is being lowered and this error doesn't occur for *all* nodes - it appears to correctly lower some nodes first. I think I do some pattern matching and only replace nodes within loops (which are the only ones I'm interested in) and hope that the problem will go away that way but I haven't had time to try that (yet).
> 
> scope: GraalCompiler.FrontEnd.LowTier.Lowering.IncrementalCanonicalizer.Lowering iteration 0.InterceptException
> Exception occurred in scope: GraalCompiler.FrontEnd.LowTier.Lowering.IncrementalCanonicalizer.Lowering iteration 0.InterceptException
> Context obj com.oracle.graal.graph.GraalInternalError: Cannot create guards in after-guard lowering
> Context obj com.oracle.graal.phases.common.LoweringPhase$Round at 76505305
> Context obj com.oracle.graal.phases.common.IncrementalCanonicalizerPhase at 14cd1699
> Context obj com.oracle.graal.phases.common.LoweringPhase at 77888435
> Context obj com.oracle.graal.compiler.phases.LowTier at 73a1e9a9
> Context obj StructuredGraph:3{HotSpotMethod<CodeSamples.loopDependency(int[], int[])>}
> Connected to the IGV on 127.0.0.1:4445
> Context obj com.oracle.graal.hotspot.amd64.AMD64HotSpotRuntime at 5ad851c9
> Exception in thread "main" com.oracle.graal.graph.GraalInternalError: Cannot create guards in after-guard lowering
>         at com.oracle.graal.phases.common.LoweringPhase$LoweringToolImpl.createGuard(LoweringPhase.java:103)
>         at com.oracle.graal.phases.common.LoweringPhase$LoweringToolImpl.createNullCheckGuard(LoweringPhase.java:84)
>         at com.oracle.graal.hotspot.meta.HotSpotRuntime.lower(HotSpotRuntime.java:497)
>         at com.oracle.graal.hotspot.amd64.AMD64HotSpotRuntime.lower(AMD64HotSpotRuntime.java:82)
>         at com.oracle.graal.nodes.InvokeNode.lower(InvokeNode.java:112)
>         at com.oracle.graal.phases.common.LoweringPhase$Round.process(LoweringPhase.java:258)
>         at com.oracle.graal.phases.common.LoweringPhase$Round.processBlock(LoweringPhase.java:192)
>         at com.oracle.graal.phases.common.LoweringPhase$Round.processBlock(LoweringPhase.java:204)
>         at com.oracle.graal.phases.common.LoweringPhase$Round.processBlock(LoweringPhase.java:204)
>         at com.oracle.graal.phases.common.LoweringPhase$Round.processBlock(LoweringPhase.java:204)
>         at com.oracle.graal.phases.common.LoweringPhase$Round.processBlock(LoweringPhase.java:204)
>         at com.oracle.graal.phases.common.LoweringPhase$Round.processBlock(LoweringPhase.java:204)
>         at com.oracle.graal.phases.common.LoweringPhase$Round.run(LoweringPhase.java:183)
>         at com.oracle.graal.phases.Phase.run(Phase.java:51)
>         at com.oracle.graal.phases.BasePhase$1.run(BasePhase.java:62)
>         at com.oracle.graal.debug.internal.DebugScope.executeScope(DebugScope.java:179)
>         at com.oracle.graal.debug.internal.DebugScope.scope(DebugScope.java:167)
>         at com.oracle.graal.debug.Debug.scope(Debug.java:118)
>         at com.oracle.graal.debug.Debug.scope(Debug.java:113)
>         at com.oracle.graal.phases.BasePhase.apply(BasePhase.java:59)
>         at com.oracle.graal.phases.BasePhase.apply(BasePhase.java:55)
>         at com.oracle.graal.phases.PhaseSuite.run(PhaseSuite.java:69)
>         at com.oracle.graal.phases.common.IncrementalCanonicalizerPhase.run(IncrementalCanonicalizerPhase.java:47)
>         at com.oracle.graal.phases.common.IncrementalCanonicalizerPhase.run(IncrementalCanonicalizerPhase.java:1)
>         at com.oracle.graal.phases.BasePhase$1.run(BasePhase.java:62)
>         at com.oracle.graal.debug.internal.DebugScope.executeScope(DebugScope.java:179)
>         at com.oracle.graal.debug.internal.DebugScope.scope(DebugScope.java:167)
>         at com.oracle.graal.debug.Debug.scope(Debug.java:118)
>         at com.oracle.graal.debug.Debug.scope(Debug.java:113)
>         at com.oracle.graal.phases.BasePhase.apply(BasePhase.java:59)
>         at com.oracle.graal.phases.BasePhase.apply(BasePhase.java:55)
>         at com.oracle.graal.phases.common.LoweringPhase.run(LoweringPhase.java:159)
>         at com.oracle.graal.phases.common.LoweringPhase.run(LoweringPhase.java:1)
>         at com.oracle.graal.phases.BasePhase$1.run(BasePhase.java:62)
>         at com.oracle.graal.debug.internal.DebugScope.executeScope(DebugScope.java:179)
>         at com.oracle.graal.debug.internal.DebugScope.scope(DebugScope.java:167)
>         at com.oracle.graal.debug.Debug.scope(Debug.java:118)
>         at com.oracle.graal.debug.Debug.scope(Debug.java:113)
>         at com.oracle.graal.phases.BasePhase.apply(BasePhase.java:59)
>         at com.oracle.graal.phases.BasePhase.apply(BasePhase.java:55)
>         at com.oracle.graal.phases.PhaseSuite.run(PhaseSuite.java:69)
>         at com.oracle.graal.phases.BasePhase$1.run(BasePhase.java:62)
>         at com.oracle.graal.debug.internal.DebugScope.executeScope(DebugScope.java:179)
>         at com.oracle.graal.debug.internal.DebugScope.scope(DebugScope.java:167)
>         at com.oracle.graal.debug.Debug.scope(Debug.java:118)
>         at com.oracle.graal.debug.Debug.scope(Debug.java:113)
>         at com.oracle.graal.phases.BasePhase.apply(BasePhase.java:59)
>         at com.oracle.graal.phases.BasePhase.apply(BasePhase.java:55)
>         at com.oracle.graal.compiler.GraalCompiler.emitHIR(GraalCompiler.java:172)
>         at com.oracle.graal.compiler.GraalCompiler$1$1.call(GraalCompiler.java:86)
>         at com.oracle.graal.compiler.GraalCompiler$1$1.call(GraalCompiler.java:1)
>         at com.oracle.graal.debug.internal.DebugScope.call(DebugScope.java:301)
>         at com.oracle.graal.debug.internal.DebugScope.executeScope(DebugScope.java:182)
>         at com.oracle.graal.debug.internal.DebugScope.scope(DebugScope.java:167)
>         at com.oracle.graal.debug.Debug.scope(Debug.java:138)
>         at com.oracle.graal.debug.Debug.scope(Debug.java:109)
>         at com.oracle.graal.compiler.GraalCompiler$1.run(GraalCompiler.java:83)
>         at com.oracle.graal.debug.internal.DebugScope.executeScope(DebugScope.java:179)
>         at com.oracle.graal.debug.internal.DebugScope.scope(DebugScope.java:167)
>         at com.oracle.graal.debug.Debug.scope(Debug.java:118)
>         at com.oracle.graal.compiler.GraalCompiler.compileGraph(GraalCompiler.java:79)
>         at uk.ac.ed.inf.icsa.locomotion.core.Locomotion.compile(Locomotion.java:57)
>         at uk.ac.ed.inf.icsa.locomotion.Application.run(Application.java:46)
>         at uk.ac.ed.inf.icsa.locomotion.Application.main(Application.java:65)
> 
> 
> 
> On 3 Jul 2013, at 14:53, Doug Simon <doug.simon at oracle.com> wrote:
> 
> > 
> > On Jul 2, 2013, at 9:36 PM, ATKIN-GRANVILLE Chris <s1255753 at sms.ed.ac.uk> wrote:
> > 
> >> Hi there,
> >> 
> >> I'm trying add arbitrary behaviour to array accesses - the end goal being to create traces of all memory operations within a program. What I've done so far was suggested to me in a previous thread on this list, but in short, I've got phases that add my own custom nodes to each LoadIndexedNode/StoreIndexedNode. These are then lowered to the desired behaviour via snippets:
> >> 
> >> public class InstrumentationSnippets implements Snippets {
> >>       @Snippet
> >>       public static void store(final ArrayStoreBehaviourNode<?> node) {
> >>               Instrument.arrayStores.add(node.getInfo());
> >>       }
> >>       
> >>       @Snippet
> >>       public static void load(final ArrayLoadBehaviourNode<?> node) {
> >>               Instrument.arrayLoads.add(node.getInfo());
> >>       }
> > 
> > This doesn't look right, having compiler nodes as parameter types of snippets. The value of a snippet parameter may come from a compiler node when the snippet is instantiated (during lowering) but the snippet sees the "raw" Java type of the value. Assuming ArrayLoadInfo is the type returned by node.getInfo(), you probably want something like this:
> > 
> > @Snippet
> > public static void load(ArrayLoadInfo info) {
> >    Instrument.arrayLoads.add(info);
> > }
> > 
> > 
> >>       public static class Templates extends AbstractTemplates {
> >>               private final SnippetInfo store = snippet(InstrumentationSnippets.class, "store");
> >>               private final SnippetInfo load = snippet(InstrumentationSnippets.class, "load");
> >> 
> >>               public Templates(MetaAccessProvider runtime, Replacements replacements, TargetDescription target) {
> >>                       super(runtime, replacements, target);
> >>               }
> >>               
> >>               public void lower(final ArrayStoreBehaviourNode<?> node) {
> >>                       Arguments args = new Arguments(store);
> >>                       args.add("node", node);
> > 
> > and replace the above with:
> > 
> > args.add("info", node.getInfo());
> > 
> > -Doug
> 
> <except.xml>The University of Edinburgh is a charitable body, registered in
> Scotland, with registration number SC005336.


From s1255753 at sms.ed.ac.uk  Mon Jul  8 08:04:35 2013
From: s1255753 at sms.ed.ac.uk (ATKIN-GRANVILLE Chris)
Date: Mon, 8 Jul 2013 15:04:35 +0000
Subject: NullPointerException in HotSpotRuntime:lower when using Snippets
In-Reply-To: <BB081FA8-D9FE-45CE-9D14-E6D648C46AB7@oracle.com>
References: <72C1FE55-E500-47DA-B5DE-831AB7119F3F@sms.ed.ac.uk>
	<1B56654D-BB65-423B-9558-96254F71132F@oracle.com>
	<4AD5DAB8-9F0B-44AD-9FD3-B007DADE45A8@sms.ed.ac.uk>
	<BB081FA8-D9FE-45CE-9D14-E6D648C46AB7@oracle.com>
Message-ID: <D590922B-A5FB-459E-B58A-74C8D51C0369@sms.ed.ac.uk>

I couldn't find a ReplacementsImpl.buildGraph() so I used ReplacementsImpl.GraphMaker.buildGraph() instead, specifically ReplacementsImpl.java:303.

My snippet at the moment consists of a call to HashSet.add().

@Snippet
public static void load(String s) {
	// call to add(s) on a public static Set (HashSet)
}

private final SnippetInfo load = snippet(InstrumentationSnippets.class, "load");

My lowering code looks like (in an inner class Templates extending AbstractTemplates):

public void lower(final ArrayLoadBehaviourNode node) {
	Arguments args = new Arguments(load);
	args.add("s", node.getInfoAsString());

	template(args).instantiate(runtime, node, DEFAULT_REPLACER, args);
}

My lowering code is called though a HIGH_LEVEL phase (via Suites) that scans through the graph:

for(Node n: graph.getNodes())
	if (n instanceof ArrayLoadBehaviourNode)
		new InstrumentationSnippets.Templates(runtime, replacements, target).lower((ArrayLoadBehaviourNode) n);

I added a breakpoint to ReplacementsImpl.GraphMaker.pharseGraph() line 303 (return buildGraph(?)). I inspected every call at this point, checking this.this$1.method. There were no calls with dontInline = true or forceInline = true - i.e., they were all false. Is that what you meant?

On 7 Jul 2013, at 21:58, Doug Simon <doug.simon at oracle.com>
 wrote:

> In general, snippets inline any calls they make except for foreign calls. Wha call is not being inlined and do you know why not? You can figure this out by debugging the call to ReplacementsImpl.buildGraph() when your snippet is be processed.
> 
> On Jul 6, 2013, at 12:14 AM, ATKIN-GRANVILLE Chris <s1255753 at sms.ed.ac.uk> wrote:
> 
>> Thanks for the advice. I tried your suggestions and I can now access fields in the snippet (so far I'm just incrementing a static field). However, if I try to do something a little more fancy like calling a method, I get another exception. I'll investigate further next week, but if you have any suggestions they'd be appreciated. FWIW I tried outputting to stdout whenever a node (i.e., my custom node) is being lowered and this error doesn't occur for *all* nodes - it appears to correctly lower some nodes first. I think I do some pattern matching and only replace nodes within loops (which are the only ones I'm interested in) and hope that the problem will go away that way but I haven't had time to try that (yet).
>> 
>> scope: GraalCompiler.FrontEnd.LowTier.Lowering.IncrementalCanonicalizer.Lowering iteration 0.InterceptException
>> Exception occurred in scope: GraalCompiler.FrontEnd.LowTier.Lowering.IncrementalCanonicalizer.Lowering iteration 0.InterceptException
>> Context obj com.oracle.graal.graph.GraalInternalError: Cannot create guards in after-guard lowering
>> Context obj com.oracle.graal.phases.common.LoweringPhase$Round at 76505305
>> Context obj com.oracle.graal.phases.common.IncrementalCanonicalizerPhase at 14cd1699
>> Context obj com.oracle.graal.phases.common.LoweringPhase at 77888435
>> Context obj com.oracle.graal.compiler.phases.LowTier at 73a1e9a9
>> Context obj StructuredGraph:3{HotSpotMethod<CodeSamples.loopDependency(int[], int[])>}
>> Connected to the IGV on 127.0.0.1:4445
>> Context obj com.oracle.graal.hotspot.amd64.AMD64HotSpotRuntime at 5ad851c9
>> Exception in thread "main" com.oracle.graal.graph.GraalInternalError: Cannot create guards in after-guard lowering
>>        at com.oracle.graal.phases.common.LoweringPhase$LoweringToolImpl.createGuard(LoweringPhase.java:103)
>>        at com.oracle.graal.phases.common.LoweringPhase$LoweringToolImpl.createNullCheckGuard(LoweringPhase.java:84)
>>        at com.oracle.graal.hotspot.meta.HotSpotRuntime.lower(HotSpotRuntime.java:497)
>>        at com.oracle.graal.hotspot.amd64.AMD64HotSpotRuntime.lower(AMD64HotSpotRuntime.java:82)
>>        at com.oracle.graal.nodes.InvokeNode.lower(InvokeNode.java:112)
>>        at com.oracle.graal.phases.common.LoweringPhase$Round.process(LoweringPhase.java:258)
>>        at com.oracle.graal.phases.common.LoweringPhase$Round.processBlock(LoweringPhase.java:192)
>>        at com.oracle.graal.phases.common.LoweringPhase$Round.processBlock(LoweringPhase.java:204)
>>        at com.oracle.graal.phases.common.LoweringPhase$Round.processBlock(LoweringPhase.java:204)
>>        at com.oracle.graal.phases.common.LoweringPhase$Round.processBlock(LoweringPhase.java:204)
>>        at com.oracle.graal.phases.common.LoweringPhase$Round.processBlock(LoweringPhase.java:204)
>>        at com.oracle.graal.phases.common.LoweringPhase$Round.processBlock(LoweringPhase.java:204)
>>        at com.oracle.graal.phases.common.LoweringPhase$Round.run(LoweringPhase.java:183)
>>        at com.oracle.graal.phases.Phase.run(Phase.java:51)
>>        at com.oracle.graal.phases.BasePhase$1.run(BasePhase.java:62)
>>        at com.oracle.graal.debug.internal.DebugScope.executeScope(DebugScope.java:179)
>>        at com.oracle.graal.debug.internal.DebugScope.scope(DebugScope.java:167)
>>        at com.oracle.graal.debug.Debug.scope(Debug.java:118)
>>        at com.oracle.graal.debug.Debug.scope(Debug.java:113)
>>        at com.oracle.graal.phases.BasePhase.apply(BasePhase.java:59)
>>        at com.oracle.graal.phases.BasePhase.apply(BasePhase.java:55)
>>        at com.oracle.graal.phases.PhaseSuite.run(PhaseSuite.java:69)
>>        at com.oracle.graal.phases.common.IncrementalCanonicalizerPhase.run(IncrementalCanonicalizerPhase.java:47)
>>        at com.oracle.graal.phases.common.IncrementalCanonicalizerPhase.run(IncrementalCanonicalizerPhase.java:1)
>>        at com.oracle.graal.phases.BasePhase$1.run(BasePhase.java:62)
>>        at com.oracle.graal.debug.internal.DebugScope.executeScope(DebugScope.java:179)
>>        at com.oracle.graal.debug.internal.DebugScope.scope(DebugScope.java:167)
>>        at com.oracle.graal.debug.Debug.scope(Debug.java:118)
>>        at com.oracle.graal.debug.Debug.scope(Debug.java:113)
>>        at com.oracle.graal.phases.BasePhase.apply(BasePhase.java:59)
>>        at com.oracle.graal.phases.BasePhase.apply(BasePhase.java:55)
>>        at com.oracle.graal.phases.common.LoweringPhase.run(LoweringPhase.java:159)
>>        at com.oracle.graal.phases.common.LoweringPhase.run(LoweringPhase.java:1)
>>        at com.oracle.graal.phases.BasePhase$1.run(BasePhase.java:62)
>>        at com.oracle.graal.debug.internal.DebugScope.executeScope(DebugScope.java:179)
>>        at com.oracle.graal.debug.internal.DebugScope.scope(DebugScope.java:167)
>>        at com.oracle.graal.debug.Debug.scope(Debug.java:118)
>>        at com.oracle.graal.debug.Debug.scope(Debug.java:113)
>>        at com.oracle.graal.phases.BasePhase.apply(BasePhase.java:59)
>>        at com.oracle.graal.phases.BasePhase.apply(BasePhase.java:55)
>>        at com.oracle.graal.phases.PhaseSuite.run(PhaseSuite.java:69)
>>        at com.oracle.graal.phases.BasePhase$1.run(BasePhase.java:62)
>>        at com.oracle.graal.debug.internal.DebugScope.executeScope(DebugScope.java:179)
>>        at com.oracle.graal.debug.internal.DebugScope.scope(DebugScope.java:167)
>>        at com.oracle.graal.debug.Debug.scope(Debug.java:118)
>>        at com.oracle.graal.debug.Debug.scope(Debug.java:113)
>>        at com.oracle.graal.phases.BasePhase.apply(BasePhase.java:59)
>>        at com.oracle.graal.phases.BasePhase.apply(BasePhase.java:55)
>>        at com.oracle.graal.compiler.GraalCompiler.emitHIR(GraalCompiler.java:172)
>>        at com.oracle.graal.compiler.GraalCompiler$1$1.call(GraalCompiler.java:86)
>>        at com.oracle.graal.compiler.GraalCompiler$1$1.call(GraalCompiler.java:1)
>>        at com.oracle.graal.debug.internal.DebugScope.call(DebugScope.java:301)
>>        at com.oracle.graal.debug.internal.DebugScope.executeScope(DebugScope.java:182)
>>        at com.oracle.graal.debug.internal.DebugScope.scope(DebugScope.java:167)
>>        at com.oracle.graal.debug.Debug.scope(Debug.java:138)
>>        at com.oracle.graal.debug.Debug.scope(Debug.java:109)
>>        at com.oracle.graal.compiler.GraalCompiler$1.run(GraalCompiler.java:83)
>>        at com.oracle.graal.debug.internal.DebugScope.executeScope(DebugScope.java:179)
>>        at com.oracle.graal.debug.internal.DebugScope.scope(DebugScope.java:167)
>>        at com.oracle.graal.debug.Debug.scope(Debug.java:118)
>>        at com.oracle.graal.compiler.GraalCompiler.compileGraph(GraalCompiler.java:79)
>>        at uk.ac.ed.inf.icsa.locomotion.core.Locomotion.compile(Locomotion.java:57)
>>        at uk.ac.ed.inf.icsa.locomotion.Application.run(Application.java:46)
>>        at uk.ac.ed.inf.icsa.locomotion.Application.main(Application.java:65)
>> 
>> 
>> 
>> On 3 Jul 2013, at 14:53, Doug Simon <doug.simon at oracle.com> wrote:
>> 
>>> 
>>> On Jul 2, 2013, at 9:36 PM, ATKIN-GRANVILLE Chris <s1255753 at sms.ed.ac.uk> wrote:
>>> 
>>>> Hi there,
>>>> 
>>>> I'm trying add arbitrary behaviour to array accesses - the end goal being to create traces of all memory operations within a program. What I've done so far was suggested to me in a previous thread on this list, but in short, I've got phases that add my own custom nodes to each LoadIndexedNode/StoreIndexedNode. These are then lowered to the desired behaviour via snippets:
>>>> 
>>>> public class InstrumentationSnippets implements Snippets {
>>>>      @Snippet
>>>>      public static void store(final ArrayStoreBehaviourNode<?> node) {
>>>>              Instrument.arrayStores.add(node.getInfo());
>>>>      }
>>>> 
>>>>      @Snippet
>>>>      public static void load(final ArrayLoadBehaviourNode<?> node) {
>>>>              Instrument.arrayLoads.add(node.getInfo());
>>>>      }
>>> 
>>> This doesn't look right, having compiler nodes as parameter types of snippets. The value of a snippet parameter may come from a compiler node when the snippet is instantiated (during lowering) but the snippet sees the "raw" Java type of the value. Assuming ArrayLoadInfo is the type returned by node.getInfo(), you probably want something like this:
>>> 
>>> @Snippet
>>> public static void load(ArrayLoadInfo info) {
>>>   Instrument.arrayLoads.add(info);
>>> }
>>> 
>>> 
>>>>      public static class Templates extends AbstractTemplates {
>>>>              private final SnippetInfo store = snippet(InstrumentationSnippets.class, "store");
>>>>              private final SnippetInfo load = snippet(InstrumentationSnippets.class, "load");
>>>> 
>>>>              public Templates(MetaAccessProvider runtime, Replacements replacements, TargetDescription target) {
>>>>                      super(runtime, replacements, target);
>>>>              }
>>>> 
>>>>              public void lower(final ArrayStoreBehaviourNode<?> node) {
>>>>                      Arguments args = new Arguments(store);
>>>>                      args.add("node", node);
>>> 
>>> and replace the above with:
>>> 
>>> args.add("info", node.getInfo());
>>> 
>>> -Doug
>> 
>> <except.xml>The University of Edinburgh is a charitable body, registered in
>> Scotland, with registration number SC005336.
> 
> 



-- 
The University of Edinburgh is a charitable body, registered in
Scotland, with registration number SC005336.


From s1255753 at sms.ed.ac.uk  Mon Jul  8 09:37:00 2013
From: s1255753 at sms.ed.ac.uk (ATKIN-GRANVILLE Chris)
Date: Mon, 8 Jul 2013 16:37:00 +0000
Subject: NullPointerException in HotSpotRuntime:lower when using Snippets
In-Reply-To: <D590922B-A5FB-459E-B58A-74C8D51C0369@sms.ed.ac.uk>
References: <72C1FE55-E500-47DA-B5DE-831AB7119F3F@sms.ed.ac.uk>
	<1B56654D-BB65-423B-9558-96254F71132F@oracle.com>
	<4AD5DAB8-9F0B-44AD-9FD3-B007DADE45A8@sms.ed.ac.uk>
	<BB081FA8-D9FE-45CE-9D14-E6D648C46AB7@oracle.com>
	<D590922B-A5FB-459E-B58A-74C8D51C0369@sms.ed.ac.uk>
Message-ID: <DE9CCC81-DE7B-4C6F-A719-FE5B1C1D2B63@sms.ed.ac.uk>

Just to add some more information--

There appears to be several nodes for which lowering is successful. I added System.out.println() to display output the WriteNode associated with the Array(Store/Load)BehaviourNode. When these nodes are created, they are instantiated with the toString() of the node their are instrumenting (currently, a WriteNode. In the future hopefully they will contain a reference to the node, but that's on the todo list). It looks like this:

public void lower(final ArrayStoreBehaviourNode node) {
	System.out.println(node.getString());

	Arguments args= ? // rest of the lowering stage as below
}

This results in several nodes being lowered, appearingly successfully:

561|Write
586|Write
614|Write
615|Write
scope: GraalCompiler.FrontEnd.LowTier.Lowering.IncrementalCanonicalizer.Lowering iteration 0.InterceptException
Exception occurred in scope: GraalCompiler.FrontEnd.LowTier.Lowering.IncrementalCanonicalizer.Lowering iteration 0.InterceptException
Context obj com.oracle.graal.graph.GraalInternalError: Cannot create guards in after-guard lowering
(snip)

I stepped through the times buildGraph() are called /after/ 615|Write is printed. At no point where methodToParse.forceInline or methodToParse.dontInline true (they were always false). Interestingly it appears as if there are two errors:

scope: GraalCompiler.FrontEnd.LowTier.Lowering.IncrementalCanonicalizer.Lowering iteration 0.InterceptException
Exception occurred in scope: GraalCompiler.FrontEnd.LowTier.Lowering.IncrementalCanonicalizer.Lowering iteration 0.InterceptException
Context obj com.oracle.graal.graph.GraalInternalError: Cannot create guards in after-guard lowering
Context obj com.oracle.graal.phases.common.LoweringPhase$Round at 37313c65
Context obj com.oracle.graal.phases.common.IncrementalCanonicalizerPhase at 465232e9
Context obj com.oracle.graal.phases.common.LoweringPhase at 798162bc
Context obj com.oracle.graal.compiler.phases.LowTier at 1df8da7a
Context obj StructuredGraph:3{HotSpotMethod<CodeSamples.loopDependency(int[], int[])>}
Connected to the IGV on 127.0.0.1:4445
Context obj com.oracle.graal.hotspot.amd64.AMD64HotSpotRuntime at 478db956

occurs at a different time than the GraalInternalError is thrown.

On 8 Jul 2013, at 16:04, ATKIN-GRANVILLE Chris <s1255753 at sms.ed.ac.uk> wrote:

> I couldn't find a ReplacementsImpl.buildGraph() so I used ReplacementsImpl.GraphMaker.buildGraph() instead, specifically ReplacementsImpl.java:303.
> 
> My snippet at the moment consists of a call to HashSet.add().
> 
> @Snippet
> public static void load(String s) {
> 	// call to add(s) on a public static Set (HashSet)
> }
> 
> private final SnippetInfo load = snippet(InstrumentationSnippets.class, "load");
> 
> My lowering code looks like (in an inner class Templates extending AbstractTemplates):
> 
> public void lower(final ArrayLoadBehaviourNode node) {
> 	Arguments args = new Arguments(load);
> 	args.add("s", node.getInfoAsString());
> 
> 	template(args).instantiate(runtime, node, DEFAULT_REPLACER, args);
> }
> 
> My lowering code is called though a HIGH_LEVEL phase (via Suites) that scans through the graph:
> 
> for(Node n: graph.getNodes())
> 	if (n instanceof ArrayLoadBehaviourNode)
> 		new InstrumentationSnippets.Templates(runtime, replacements, target).lower((ArrayLoadBehaviourNode) n);
> 
> I added a breakpoint to ReplacementsImpl.GraphMaker.pharseGraph() line 303 (return buildGraph(?)). I inspected every call at this point, checking this.this$1.method. There were no calls with dontInline = true or forceInline = true - i.e., they were all false. Is that what you meant?
> 
> On 7 Jul 2013, at 21:58, Doug Simon <doug.simon at oracle.com>
> wrote:
> 
>> In general, snippets inline any calls they make except for foreign calls. Wha call is not being inlined and do you know why not? You can figure this out by debugging the call to ReplacementsImpl.buildGraph() when your snippet is be processed.
>> 
>> On Jul 6, 2013, at 12:14 AM, ATKIN-GRANVILLE Chris <s1255753 at sms.ed.ac.uk> wrote:
>> 
>>> Thanks for the advice. I tried your suggestions and I can now access fields in the snippet (so far I'm just incrementing a static field). However, if I try to do something a little more fancy like calling a method, I get another exception. I'll investigate further next week, but if you have any suggestions they'd be appreciated. FWIW I tried outputting to stdout whenever a node (i.e., my custom node) is being lowered and this error doesn't occur for *all* nodes - it appears to correctly lower some nodes first. I think I do some pattern matching and only replace nodes within loops (which are the only ones I'm interested in) and hope that the problem will go away that way but I haven't had time to try that (yet).
>>> 
>>> scope: GraalCompiler.FrontEnd.LowTier.Lowering.IncrementalCanonicalizer.Lowering iteration 0.InterceptException
>>> Exception occurred in scope: GraalCompiler.FrontEnd.LowTier.Lowering.IncrementalCanonicalizer.Lowering iteration 0.InterceptException
>>> Context obj com.oracle.graal.graph.GraalInternalError: Cannot create guards in after-guard lowering
>>> Context obj com.oracle.graal.phases.common.LoweringPhase$Round at 76505305
>>> Context obj com.oracle.graal.phases.common.IncrementalCanonicalizerPhase at 14cd1699
>>> Context obj com.oracle.graal.phases.common.LoweringPhase at 77888435
>>> Context obj com.oracle.graal.compiler.phases.LowTier at 73a1e9a9
>>> Context obj StructuredGraph:3{HotSpotMethod<CodeSamples.loopDependency(int[], int[])>}
>>> Connected to the IGV on 127.0.0.1:4445
>>> Context obj com.oracle.graal.hotspot.amd64.AMD64HotSpotRuntime at 5ad851c9
>>> Exception in thread "main" com.oracle.graal.graph.GraalInternalError: Cannot create guards in after-guard lowering
>>>       at com.oracle.graal.phases.common.LoweringPhase$LoweringToolImpl.createGuard(LoweringPhase.java:103)
>>>       at com.oracle.graal.phases.common.LoweringPhase$LoweringToolImpl.createNullCheckGuard(LoweringPhase.java:84)
>>>       at com.oracle.graal.hotspot.meta.HotSpotRuntime.lower(HotSpotRuntime.java:497)
>>>       at com.oracle.graal.hotspot.amd64.AMD64HotSpotRuntime.lower(AMD64HotSpotRuntime.java:82)
>>>       at com.oracle.graal.nodes.InvokeNode.lower(InvokeNode.java:112)
>>>       at com.oracle.graal.phases.common.LoweringPhase$Round.process(LoweringPhase.java:258)
>>>       at com.oracle.graal.phases.common.LoweringPhase$Round.processBlock(LoweringPhase.java:192)
>>>       at com.oracle.graal.phases.common.LoweringPhase$Round.processBlock(LoweringPhase.java:204)
>>>       at com.oracle.graal.phases.common.LoweringPhase$Round.processBlock(LoweringPhase.java:204)
>>>       at com.oracle.graal.phases.common.LoweringPhase$Round.processBlock(LoweringPhase.java:204)
>>>       at com.oracle.graal.phases.common.LoweringPhase$Round.processBlock(LoweringPhase.java:204)
>>>       at com.oracle.graal.phases.common.LoweringPhase$Round.processBlock(LoweringPhase.java:204)
>>>       at com.oracle.graal.phases.common.LoweringPhase$Round.run(LoweringPhase.java:183)
>>>       at com.oracle.graal.phases.Phase.run(Phase.java:51)
>>>       at com.oracle.graal.phases.BasePhase$1.run(BasePhase.java:62)
>>>       at com.oracle.graal.debug.internal.DebugScope.executeScope(DebugScope.java:179)
>>>       at com.oracle.graal.debug.internal.DebugScope.scope(DebugScope.java:167)
>>>       at com.oracle.graal.debug.Debug.scope(Debug.java:118)
>>>       at com.oracle.graal.debug.Debug.scope(Debug.java:113)
>>>       at com.oracle.graal.phases.BasePhase.apply(BasePhase.java:59)
>>>       at com.oracle.graal.phases.BasePhase.apply(BasePhase.java:55)
>>>       at com.oracle.graal.phases.PhaseSuite.run(PhaseSuite.java:69)
>>>       at com.oracle.graal.phases.common.IncrementalCanonicalizerPhase.run(IncrementalCanonicalizerPhase.java:47)
>>>       at com.oracle.graal.phases.common.IncrementalCanonicalizerPhase.run(IncrementalCanonicalizerPhase.java:1)
>>>       at com.oracle.graal.phases.BasePhase$1.run(BasePhase.java:62)
>>>       at com.oracle.graal.debug.internal.DebugScope.executeScope(DebugScope.java:179)
>>>       at com.oracle.graal.debug.internal.DebugScope.scope(DebugScope.java:167)
>>>       at com.oracle.graal.debug.Debug.scope(Debug.java:118)
>>>       at com.oracle.graal.debug.Debug.scope(Debug.java:113)
>>>       at com.oracle.graal.phases.BasePhase.apply(BasePhase.java:59)
>>>       at com.oracle.graal.phases.BasePhase.apply(BasePhase.java:55)
>>>       at com.oracle.graal.phases.common.LoweringPhase.run(LoweringPhase.java:159)
>>>       at com.oracle.graal.phases.common.LoweringPhase.run(LoweringPhase.java:1)
>>>       at com.oracle.graal.phases.BasePhase$1.run(BasePhase.java:62)
>>>       at com.oracle.graal.debug.internal.DebugScope.executeScope(DebugScope.java:179)
>>>       at com.oracle.graal.debug.internal.DebugScope.scope(DebugScope.java:167)
>>>       at com.oracle.graal.debug.Debug.scope(Debug.java:118)
>>>       at com.oracle.graal.debug.Debug.scope(Debug.java:113)
>>>       at com.oracle.graal.phases.BasePhase.apply(BasePhase.java:59)
>>>       at com.oracle.graal.phases.BasePhase.apply(BasePhase.java:55)
>>>       at com.oracle.graal.phases.PhaseSuite.run(PhaseSuite.java:69)
>>>       at com.oracle.graal.phases.BasePhase$1.run(BasePhase.java:62)
>>>       at com.oracle.graal.debug.internal.DebugScope.executeScope(DebugScope.java:179)
>>>       at com.oracle.graal.debug.internal.DebugScope.scope(DebugScope.java:167)
>>>       at com.oracle.graal.debug.Debug.scope(Debug.java:118)
>>>       at com.oracle.graal.debug.Debug.scope(Debug.java:113)
>>>       at com.oracle.graal.phases.BasePhase.apply(BasePhase.java:59)
>>>       at com.oracle.graal.phases.BasePhase.apply(BasePhase.java:55)
>>>       at com.oracle.graal.compiler.GraalCompiler.emitHIR(GraalCompiler.java:172)
>>>       at com.oracle.graal.compiler.GraalCompiler$1$1.call(GraalCompiler.java:86)
>>>       at com.oracle.graal.compiler.GraalCompiler$1$1.call(GraalCompiler.java:1)
>>>       at com.oracle.graal.debug.internal.DebugScope.call(DebugScope.java:301)
>>>       at com.oracle.graal.debug.internal.DebugScope.executeScope(DebugScope.java:182)
>>>       at com.oracle.graal.debug.internal.DebugScope.scope(DebugScope.java:167)
>>>       at com.oracle.graal.debug.Debug.scope(Debug.java:138)
>>>       at com.oracle.graal.debug.Debug.scope(Debug.java:109)
>>>       at com.oracle.graal.compiler.GraalCompiler$1.run(GraalCompiler.java:83)
>>>       at com.oracle.graal.debug.internal.DebugScope.executeScope(DebugScope.java:179)
>>>       at com.oracle.graal.debug.internal.DebugScope.scope(DebugScope.java:167)
>>>       at com.oracle.graal.debug.Debug.scope(Debug.java:118)
>>>       at com.oracle.graal.compiler.GraalCompiler.compileGraph(GraalCompiler.java:79)
>>>       at uk.ac.ed.inf.icsa.locomotion.core.Locomotion.compile(Locomotion.java:57)
>>>       at uk.ac.ed.inf.icsa.locomotion.Application.run(Application.java:46)
>>>       at uk.ac.ed.inf.icsa.locomotion.Application.main(Application.java:65)
>>> 
>>> 
>>> 
>>> On 3 Jul 2013, at 14:53, Doug Simon <doug.simon at oracle.com> wrote:
>>> 
>>>> 
>>>> On Jul 2, 2013, at 9:36 PM, ATKIN-GRANVILLE Chris <s1255753 at sms.ed.ac.uk> wrote:
>>>> 
>>>>> Hi there,
>>>>> 
>>>>> I'm trying add arbitrary behaviour to array accesses - the end goal being to create traces of all memory operations within a program. What I've done so far was suggested to me in a previous thread on this list, but in short, I've got phases that add my own custom nodes to each LoadIndexedNode/StoreIndexedNode. These are then lowered to the desired behaviour via snippets:
>>>>> 
>>>>> public class InstrumentationSnippets implements Snippets {
>>>>>     @Snippet
>>>>>     public static void store(final ArrayStoreBehaviourNode<?> node) {
>>>>>             Instrument.arrayStores.add(node.getInfo());
>>>>>     }
>>>>> 
>>>>>     @Snippet
>>>>>     public static void load(final ArrayLoadBehaviourNode<?> node) {
>>>>>             Instrument.arrayLoads.add(node.getInfo());
>>>>>     }
>>>> 
>>>> This doesn't look right, having compiler nodes as parameter types of snippets. The value of a snippet parameter may come from a compiler node when the snippet is instantiated (during lowering) but the snippet sees the "raw" Java type of the value. Assuming ArrayLoadInfo is the type returned by node.getInfo(), you probably want something like this:
>>>> 
>>>> @Snippet
>>>> public static void load(ArrayLoadInfo info) {
>>>>  Instrument.arrayLoads.add(info);
>>>> }
>>>> 
>>>> 
>>>>>     public static class Templates extends AbstractTemplates {
>>>>>             private final SnippetInfo store = snippet(InstrumentationSnippets.class, "store");
>>>>>             private final SnippetInfo load = snippet(InstrumentationSnippets.class, "load");
>>>>> 
>>>>>             public Templates(MetaAccessProvider runtime, Replacements replacements, TargetDescription target) {
>>>>>                     super(runtime, replacements, target);
>>>>>             }
>>>>> 
>>>>>             public void lower(final ArrayStoreBehaviourNode<?> node) {
>>>>>                     Arguments args = new Arguments(store);
>>>>>                     args.add("node", node);
>>>> 
>>>> and replace the above with:
>>>> 
>>>> args.add("info", node.getInfo());
>>>> 
>>>> -Doug
>>> 
>>> <except.xml>The University of Edinburgh is a charitable body, registered in
>>> Scotland, with registration number SC005336.
>> 
>> 
> 
> 
> 
> -- 
> The University of Edinburgh is a charitable body, registered in
> Scotland, with registration number SC005336.
> 
> 



-- 
The University of Edinburgh is a charitable body, registered in
Scotland, with registration number SC005336.


From christian.thalinger at oracle.com  Mon Jul  8 14:41:26 2013
From: christian.thalinger at oracle.com (Christian Thalinger)
Date: Mon, 8 Jul 2013 14:41:26 -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>
	<F52F166A-DACB-4724-81D7-EA8D97B252E0@oracle.com>
	<5DD1503F815BD14889DC81D28643E3A73D90E619@sausexdag06.amd.com>
	<4D9C9697-3403-450E-AEF6-190FA35E145F@oracle.com>
Message-ID: <3ACAB77C-2869-4D59-B224-AEE840F2E70B@oracle.com>


On Jun 28, 2013, at 1:28 PM, Christian Thalinger <christian.thalinger at oracle.com> wrote:

> 
> On Jun 26, 2013, at 3:00 PM, "Venkatachalam, Vasanth" <Vasanth.Venkatachalam at amd.com> 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/

Any comments on this patch?  If not, I'm going to push this today.

-- 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" <Vasanth.Venkatachalam at amd.com> 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 <christian.thalinger at oracle.com> wrote:
>> 
>> 
>> 
>> 
>> On Jun 24, 2013, at 11:13 AM, Christian Thalinger <christian.thalinger at oracle.com> 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" <Vasanth.Venkatachalam at amd.com> 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
>> <graal.patch>
>> 
>> 
>> 
>> <graal.zip>
> 


From christian.thalinger at oracle.com  Mon Jul  8 14:43:14 2013
From: christian.thalinger at oracle.com (Christian Thalinger)
Date: Mon, 8 Jul 2013 14:43:14 -0700
Subject: final graal HSAIL support patch
In-Reply-To: <3ACAB77C-2869-4D59-B224-AEE840F2E70B@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>
	<F52F166A-DACB-4724-81D7-EA8D97B252E0@oracle.com>
	<5DD1503F815BD14889DC81D28643E3A73D90E619@sausexdag06.amd.com>
	<4D9C9697-3403-450E-AEF6-190FA35E145F@oracle.com>
	<3ACAB77C-2869-4D59-B224-AEE840F2E70B@oracle.com>
Message-ID: <79BF6EED-6F10-4C1D-AA29-0D870F68B323@oracle.com>


On Jul 8, 2013, at 2:41 PM, Christian Thalinger <christian.thalinger at oracle.com> wrote:

> 
> On Jun 28, 2013, at 1:28 PM, Christian Thalinger <christian.thalinger at oracle.com> wrote:
> 
>> 
>> On Jun 26, 2013, at 3:00 PM, "Venkatachalam, Vasanth" <Vasanth.Venkatachalam at amd.com> 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/
> 
> Any comments on this patch?  If not, I'm going to push this today.

Oh, wait!  Actually I have a question:  why do you need this to be public?

--- old/graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/HotSpotGraalRuntime.java	2013-06-28 13:26:17.000000000 -0700
+++ new/graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/HotSpotGraalRuntime.java	2013-06-28 13:26:17.000000000 -0700
@@ -49,7 +49,7 @@
  */
 public abstract class HotSpotGraalRuntime implements GraalRuntime {
 
-    private static HotSpotGraalRuntime instance;
+    public static HotSpotGraalRuntime instance;
 
     /**
      * Gets the singleton {@link HotSpotGraalRuntime} object.

-- Chris

> 
> -- 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" <Vasanth.Venkatachalam at amd.com> 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 <christian.thalinger at oracle.com> wrote:
>>> 
>>> 
>>> 
>>> 
>>> On Jun 24, 2013, at 11:13 AM, Christian Thalinger <christian.thalinger at oracle.com> 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" <Vasanth.Venkatachalam at amd.com> 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
>>> <graal.patch>
>>> 
>>> 
>>> 
>>> <graal.zip>
>> 
> 


From christian.thalinger at oracle.com  Mon Jul  8 15:12:53 2013
From: christian.thalinger at oracle.com (Christian Thalinger)
Date: Mon, 8 Jul 2013 15:12:53 -0700
Subject: final graal HSAIL support patch
In-Reply-To: <79BF6EED-6F10-4C1D-AA29-0D870F68B323@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>
	<F52F166A-DACB-4724-81D7-EA8D97B252E0@oracle.com>
	<5DD1503F815BD14889DC81D28643E3A73D90E619@sausexdag06.amd.com>
	<4D9C9697-3403-450E-AEF6-190FA35E145F@oracle.com>
	<3ACAB77C-2869-4D59-B224-AEE840F2E70B@oracle.com>
	<79BF6EED-6F10-4C1D-AA29-0D870F68B323@oracle.com>
Message-ID: <52B69ED9-0FEC-4ADE-836F-4AAF5ABB6256@oracle.com>


On Jul 8, 2013, at 2:43 PM, Christian Thalinger <christian.thalinger at oracle.com> wrote:

> 
> On Jul 8, 2013, at 2:41 PM, Christian Thalinger <christian.thalinger at oracle.com> wrote:
> 
>> 
>> On Jun 28, 2013, at 1:28 PM, Christian Thalinger <christian.thalinger at oracle.com> wrote:
>> 
>>> 
>>> On Jun 26, 2013, at 3:00 PM, "Venkatachalam, Vasanth" <Vasanth.Venkatachalam at amd.com> 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/
>> 
>> Any comments on this patch?  If not, I'm going to push this today.
> 
> Oh, wait!  Actually I have a question:  why do you need this to be public?
> 
> --- old/graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/HotSpotGraalRuntime.java	2013-06-28 13:26:17.000000000 -0700
> +++ new/graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/HotSpotGraalRuntime.java	2013-06-28 13:26:17.000000000 -0700
> @@ -49,7 +49,7 @@
>  */
> public abstract class HotSpotGraalRuntime implements GraalRuntime {
> 
> -    private static HotSpotGraalRuntime instance;
> +    public static HotSpotGraalRuntime instance;
> 
>     /**
>      * Gets the singleton {@link HotSpotGraalRuntime} object.

Apparently Doug was reworking the patch and fixing various things.  He just sent me the latest version of the patch and I created a webrev for it:

http://cr.openjdk.java.net/~twisti/GRAAL-342/webrev/

-- Chris

> 
> -- Chris
> 
>> 
>> -- 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" <Vasanth.Venkatachalam at amd.com> 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 <christian.thalinger at oracle.com> wrote:
>>>> 
>>>> 
>>>> 
>>>> 
>>>> On Jun 24, 2013, at 11:13 AM, Christian Thalinger <christian.thalinger at oracle.com> 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" <Vasanth.Venkatachalam at amd.com> 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
>>>> <graal.patch>
>>>> 
>>>> 
>>>> 
>>>> <graal.zip>
>>> 
>> 
> 


From Vasanth.Venkatachalam at amd.com  Mon Jul  8 15:35:10 2013
From: Vasanth.Venkatachalam at amd.com (Venkatachalam, Vasanth)
Date: Mon, 8 Jul 2013 22:35:10 +0000
Subject: final graal HSAIL support patch
In-Reply-To: <79BF6EED-6F10-4C1D-AA29-0D870F68B323@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>
	<F52F166A-DACB-4724-81D7-EA8D97B252E0@oracle.com>
	<5DD1503F815BD14889DC81D28643E3A73D90E619@sausexdag06.amd.com>
	<4D9C9697-3403-450E-AEF6-190FA35E145F@oracle.com>
	<3ACAB77C-2869-4D59-B224-AEE840F2E70B@oracle.com>
	<79BF6EED-6F10-4C1D-AA29-0D870F68B323@oracle.com>
Message-ID: <5DD1503F815BD14889DC81D28643E3A73D9117CB@sausexdag06.amd.com>

That HotspotGraalRuntime instance does not have to be public. We had made it public a while ago during some internal testing of the AMD64 backend, but I thought we had reverted it back in the patch I submitted. You can go ahead and make it private.

Vasanth

-----Original Message-----
From: Christian Thalinger [mailto:christian.thalinger at oracle.com] 
Sent: Monday, July 08, 2013 4:43 PM
To: Venkatachalam, Vasanth
Cc: sw.runtimes; graal-dev at openjdk.java.net
Subject: Re: final graal HSAIL support patch


On Jul 8, 2013, at 2:41 PM, Christian Thalinger <christian.thalinger at oracle.com> wrote:

> 
> On Jun 28, 2013, at 1:28 PM, Christian Thalinger <christian.thalinger at oracle.com> wrote:
> 
>> 
>> On Jun 26, 2013, at 3:00 PM, "Venkatachalam, Vasanth" <Vasanth.Venkatachalam at amd.com> 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/
> 
> Any comments on this patch?  If not, I'm going to push this today.

Oh, wait!  Actually I have a question:  why do you need this to be public?

--- old/graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/HotSpotGraalRuntime.java	2013-06-28 13:26:17.000000000 -0700
+++ new/graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/HotSpotGraalRuntime.java	2013-06-28 13:26:17.000000000 -0700
@@ -49,7 +49,7 @@
  */
 public abstract class HotSpotGraalRuntime implements GraalRuntime {
 
-    private static HotSpotGraalRuntime instance;
+    public static HotSpotGraalRuntime instance;
 
     /**
      * Gets the singleton {@link HotSpotGraalRuntime} object.

-- Chris

> 
> -- 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" <Vasanth.Venkatachalam at amd.com> 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 <christian.thalinger at oracle.com> wrote:
>>> 
>>> 
>>> 
>>> 
>>> On Jun 24, 2013, at 11:13 AM, Christian Thalinger <christian.thalinger at oracle.com> 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" <Vasanth.Venkatachalam at amd.com> 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
>>> <graal.patch>
>>> 
>>> 
>>> 
>>> <graal.zip>
>> 
> 




From doug.simon at oracle.com  Tue Jul  9 02:18:41 2013
From: doug.simon at oracle.com (Doug Simon)
Date: Tue, 9 Jul 2013 11:18:41 +0200
Subject: HSAIL Simulator open sourced
In-Reply-To: <BC97738F8E7C8742BABED7F06FB9DF91450366AD@sausexdag01.amd.com>
References: <BC97738F8E7C8742BABED7F06FB9DF91450366AD@sausexdag01.amd.com>
Message-ID: <942CA0B2-E6A6-480E-9DFE-6A8EC96E8CEE@oracle.com>

I've managed to build the simulator and use it to run all the Graal HSAIL tests. It was relatively straight-forward - nice work!

I have one minor request. Is it possible to have the simulator be configurable to be less verbose? Most of the existing Graal unit tests don't (or shouldn't) produce output on the console (apart from that generated by Junit itself). It would be great if the simulator could be made to do the same somehow.

And I have one major request. Can you port the simulator to Java? ;-) This would greatly simplify integrating it into the gate tests.

-Doug

On Jul 2, 2013, at 12:52 AM, "Deneau, Tom" <tom.deneau at amd.com> wrote:

> I am pleased to announce that the HSA Foundation has open sourced the
> following projects:
> 
>    * libHSAIL (tools for parsing, assembling and disassembling HSAIL)
>    * an HSAIL Instruction Set Simulator
>    * OKRA interface to the HSAIL Simulator
> 
> The following wiki page goes into detail of how to build the simulator
> and describes some tests that can be run against it, including tests that
> use the graal HSAIL backend patch which is currently under review.
> 
> https://wiki.openjdk.java.net/display/Sumatra/The+HSAIL+Simulator
> 
> -- Tom Deneau, AMD
> 
> 
> 


From doug.simon at oracle.com  Tue Jul  9 02:22:48 2013
From: doug.simon at oracle.com (Doug Simon)
Date: Tue, 9 Jul 2013 11:22:48 +0200
Subject: final graal HSAIL support patch
In-Reply-To: <5DD1503F815BD14889DC81D28643E3A73D9117CB@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>
	<F52F166A-DACB-4724-81D7-EA8D97B252E0@oracle.com>
	<5DD1503F815BD14889DC81D28643E3A73D90E619@sausexdag06.amd.com>
	<4D9C9697-3403-450E-AEF6-190FA35E145F@oracle.com>
	<3ACAB77C-2869-4D59-B224-AEE840F2E70B@oracle.com>
	<79BF6EED-6F10-4C1D-AA29-0D870F68B323@oracle.com>
	<5DD1503F815BD14889DC81D28643E3A73D9117CB@sausexdag06.amd.com>
Message-ID: <1231D68C-1019-43A5-8D08-8CFCF48E4ED5@oracle.com>

The integrated patch is now in the OpenJDK repo: http://hg.openjdk.java.net/graal/graal/rev/4ef92b67aeae

The HSAIL simulator page[1] should now be updated as a result. In particular, the command line for running the test is now:

mx --vm server unittest @-G:-RemoveNeverExecutedCode @-Dsun.boot.library.path=$LD_LIBRARY_PATH @-Xms1g @-Xmx1g @XX:-UseCompressedOops hsail.test.IntSquaredTest

-Doug

[1] https://wiki.openjdk.java.net/display/Sumatra/The+HSAIL+Simulator

On Jul 9, 2013, at 12:35 AM, "Venkatachalam, Vasanth" <Vasanth.Venkatachalam at amd.com> wrote:

> That HotspotGraalRuntime instance does not have to be public. We had made it public a while ago during some internal testing of the AMD64 backend, but I thought we had reverted it back in the patch I submitted. You can go ahead and make it private.
> 
> Vasanth
> 
> -----Original Message-----
> From: Christian Thalinger [mailto:christian.thalinger at oracle.com] 
> Sent: Monday, July 08, 2013 4:43 PM
> To: Venkatachalam, Vasanth
> Cc: sw.runtimes; graal-dev at openjdk.java.net
> Subject: Re: final graal HSAIL support patch
> 
> 
> On Jul 8, 2013, at 2:41 PM, Christian Thalinger <christian.thalinger at oracle.com> wrote:
> 
>> 
>> On Jun 28, 2013, at 1:28 PM, Christian Thalinger <christian.thalinger at oracle.com> wrote:
>> 
>>> 
>>> On Jun 26, 2013, at 3:00 PM, "Venkatachalam, Vasanth" <Vasanth.Venkatachalam at amd.com> 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/
>> 
>> Any comments on this patch?  If not, I'm going to push this today.
> 
> Oh, wait!  Actually I have a question:  why do you need this to be public?
> 
> --- old/graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/HotSpotGraalRuntime.java	2013-06-28 13:26:17.000000000 -0700
> +++ new/graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/HotSpotGraalRuntime.java	2013-06-28 13:26:17.000000000 -0700
> @@ -49,7 +49,7 @@
>  */
> public abstract class HotSpotGraalRuntime implements GraalRuntime {
> 
> -    private static HotSpotGraalRuntime instance;
> +    public static HotSpotGraalRuntime instance;
> 
>     /**
>      * Gets the singleton {@link HotSpotGraalRuntime} object.
> 
> -- Chris
> 
>> 
>> -- 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" <Vasanth.Venkatachalam at amd.com> 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 <christian.thalinger at oracle.com> wrote:
>>>> 
>>>> 
>>>> 
>>>> 
>>>> On Jun 24, 2013, at 11:13 AM, Christian Thalinger <christian.thalinger at oracle.com> 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" <Vasanth.Venkatachalam at amd.com> 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
>>>> <graal.patch>
>>>> 
>>>> 
>>>> 
>>>> <graal.zip>
>>> 
>> 
> 
> 
> 


From doug.simon at oracle.com  Tue Jul  9 02:16:00 2013
From: doug.simon at oracle.com (doug.simon at oracle.com)
Date: Tue, 09 Jul 2013 09:16:00 +0000
Subject: hg: graal/graal: 50 new changesets
Message-ID: <20130709091953.C516D488E6@hg.openjdk.java.net>

Changeset: 7220a8568e8c
Author:    Thomas Wuerthinger <thomas.wuerthinger at oracle.com>
Date:      2013-07-06 12:20 +0200
URL:       http://hg.openjdk.java.net/graal/graal/rev/7220a8568e8c

Introduce TraceTrufflePerformanceWarnings flag.

! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/TruffleCache.java
! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/TruffleCompilerOptions.java

Changeset: f84ea5453961
Author:    Thomas Wuerthinger <thomas.wuerthinger at oracle.com>
Date:      2013-07-07 17:20 +0200
URL:       http://hg.openjdk.java.net/graal/graal/rev/f84ea5453961

Fixes for Truffle cache.

! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/TruffleCache.java

Changeset: e9241e9cfcd5
Author:    Christos Kotselidis <christos.kotselidis at oracle.com>
Date:      2013-07-07 15:24 +0200
URL:       http://hg.openjdk.java.net/graal/graal/rev/e9241e9cfcd5

Augment WriteBarrier Verification Phase for G1 (only post barriers)

! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotRuntime.java
! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/phases/WriteBarrierVerificationPhase.java

Changeset: 1d245cc635e3
Author:    Christos Kotselidis <christos.kotselidis at oracle.com>
Date:      2013-07-07 15:24 +0200
URL:       http://hg.openjdk.java.net/graal/graal/rev/1d245cc635e3

Augment Write Barrier Verification Test for G1

! graal/com.oracle.graal.hotspot.test/src/com/oracle/graal/hotspot/test/WriteBarrierVerificationTest.java

Changeset: 88fa00e79d4a
Author:    Christos Kotselidis <christos.kotselidis at oracle.com>
Date:      2013-07-07 17:02 +0200
URL:       http://hg.openjdk.java.net/graal/graal/rev/88fa00e79d4a

Add GC counter for starting tracing of barriers

! graal/com.oracle.graal.phases/src/com/oracle/graal/phases/GraalOptions.java

Changeset: 72d0ea03635b
Author:    Christos Kotselidis <christos.kotselidis at oracle.com>
Date:      2013-07-07 17:09 +0200
URL:       http://hg.openjdk.java.net/graal/graal/rev/72d0ea03635b

Delegate GC counter from HotSpot to Graal for tracing purposes

! 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/gc_interface/collectedHeap.hpp
! src/share/vm/graal/graalCompilerToVM.cpp

Changeset: 2fdd0e263160
Author:    Christos Kotselidis <christos.kotselidis at oracle.com>
Date:      2013-07-07 17:09 +0200
URL:       http://hg.openjdk.java.net/graal/graal/rev/2fdd0e263160

Fix checkstyle errors

! graal/com.oracle.graal.phases/src/com/oracle/graal/phases/GraalOptions.java

Changeset: 260e75dc4b6e
Author:    Christos Kotselidis <christos.kotselidis at oracle.com>
Date:      2013-07-07 17:10 +0200
URL:       http://hg.openjdk.java.net/graal/graal/rev/260e75dc4b6e

Add tracing info to G1 Write Barriers

! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/WriteBarrierSnippets.java

Changeset: 7f1dbbfb9adf
Author:    Christos Kotselidis <christos.kotselidis at oracle.com>
Date:      2013-07-07 18:13 +0200
URL:       http://hg.openjdk.java.net/graal/graal/rev/7f1dbbfb9adf

Always fill contents when G1 is enabled

! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/NewObjectSnippets.java
! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/ObjectCloneSnippets.java

Changeset: 844be189150c
Author:    Christos Kotselidis <christos.kotselidis at oracle.com>
Date:      2013-07-07 19:09 +0200
URL:       http://hg.openjdk.java.net/graal/graal/rev/844be189150c

Add probabilities in WB snippets

! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/WriteBarrierSnippets.java

Changeset: 13c6440ac750
Author:    Christos Kotselidis <christos.kotselidis at oracle.com>
Date:      2013-07-07 19:44 +0200
URL:       http://hg.openjdk.java.net/graal/graal/rev/13c6440ac750

Add nullcheck at G1 Pre Barrier

! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/WriteBarrierSnippets.java

Changeset: cb2d97f002d4
Author:    Christos Kotselidis <christos.kotselidis at oracle.com>
Date:      2013-07-07 21:30 +0200
URL:       http://hg.openjdk.java.net/graal/graal/rev/cb2d97f002d4

Merge


Changeset: 57b9a8c7cea8
Author:    Christian Haeubl <haeubl at ssw.jku.at>
Date:      2013-07-04 15:56 +0200
URL:       http://hg.openjdk.java.net/graal/graal/rev/57b9a8c7cea8

Attempt to increase accuracy of profiling information in the context of deep inlining.

! src/share/vm/runtime/globals.hpp

Changeset: b02b3c6a59b6
Author:    Christian Haeubl <haeubl at ssw.jku.at>
Date:      2013-07-05 14:00 +0200
URL:       http://hg.openjdk.java.net/graal/graal/rev/b02b3c6a59b6

Added an inlining policy that tries to inline all calls.

! graal/com.oracle.graal.hotspot.test/src/com/oracle/graal/hotspot/test/WriteBarrierAdditionTest.java
! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/InliningPhase.java

Changeset: 4acf032748b9
Author:    Christian Haeubl <haeubl at ssw.jku.at>
Date:      2013-07-05 14:05 +0200
URL:       http://hg.openjdk.java.net/graal/graal/rev/4acf032748b9

Reenabled nmethod statistics in product mode.

! src/share/vm/code/nmethod.cpp

Changeset: 703d00fe2703
Author:    Christian Haeubl <haeubl at ssw.jku.at>
Date:      2013-07-08 09:57 +0200
URL:       http://hg.openjdk.java.net/graal/graal/rev/703d00fe2703

Reverted attempt to increase accuracy of profiling information (57b9a8c7cea8).

! src/share/vm/runtime/globals.hpp

Changeset: 3c2a77f01e89
Author:    Christian Haeubl <haeubl at ssw.jku.at>
Date:      2013-07-08 09:58 +0200
URL:       http://hg.openjdk.java.net/graal/graal/rev/3c2a77f01e89

Merge.

! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/InliningPhase.java

Changeset: ca3865947682
Author:    Christos Kotselidis <christos.kotselidis at oracle.com>
Date:      2013-07-08 09:08 +0200
URL:       http://hg.openjdk.java.net/graal/graal/rev/ca3865947682

Debug log cleanup

! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/WriteBarrierSnippets.java

Changeset: 2e82291febf4
Author:    Christos Kotselidis <christos.kotselidis at oracle.com>
Date:      2013-07-08 09:08 +0200
URL:       http://hg.openjdk.java.net/graal/graal/rev/2e82291febf4

Oop verification after printing oop

! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/WriteBarrierSnippets.java

Changeset: add96a4e79f7
Author:    Christos Kotselidis <christos.kotselidis at oracle.com>
Date:      2013-07-08 10:56 +0200
URL:       http://hg.openjdk.java.net/graal/graal/rev/add96a4e79f7

Merge


Changeset: b288e775e56b
Author:    Doug Simon <doug.simon at oracle.com>
Date:      2013-07-05 15:40 +0200
URL:       http://hg.openjdk.java.net/graal/graal/rev/b288e775e56b

added extra test for guarded inlining

! graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/inlining/InliningTest.java

Changeset: ae12060a0f7d
Author:    Doug Simon <doug.simon at oracle.com>
Date:      2013-07-05 15:43 +0200
URL:       http://hg.openjdk.java.net/graal/graal/rev/ae12060a0f7d

made TypeCheckTest test more common pattern of type test profile showing null never seen

! graal/com.oracle.graal.replacements.test/src/com/oracle/graal/replacements/test/TypeCheckTest.java

Changeset: 1fdcc58bff2a
Author:    Doug Simon <doug.simon at oracle.com>
Date:      2013-07-05 15:44 +0200
URL:       http://hg.openjdk.java.net/graal/graal/rev/1fdcc58bff2a

added GuardingPiNode

+ graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/GuardingPiNode.java
! graal/com.oracle.graal.replacements/src/com/oracle/graal/replacements/NodeIntrinsificationPhase.java

Changeset: bef82f0cf71d
Author:    Doug Simon <doug.simon at oracle.com>
Date:      2013-07-05 15:47 +0200
URL:       http://hg.openjdk.java.net/graal/graal/rev/bef82f0cf71d

added javadoc for GuardedNode and Stamp.nonNull()

! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/extended/GuardedNode.java
! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/type/Stamp.java

Changeset: ba1fbbfac0cd
Author:    Doug Simon <doug.simon at oracle.com>
Date:      2013-07-05 15:48 +0200
URL:       http://hg.openjdk.java.net/graal/graal/rev/ba1fbbfac0cd

remove null check semantics from LoadHubNode (GRAAL-248)

! 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/HotSpotReplacementsUtil.java
! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/MonitorSnippets.java
! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/calc/IsNullNode.java
! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/extended/LoadHubNode.java
! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/InliningUtil.java

Changeset: 87c441b324e9
Author:    Doug Simon <doug.simon at oracle.com>
Date:      2013-07-08 14:34 +0200
URL:       http://hg.openjdk.java.net/graal/graal/rev/87c441b324e9

Merge.

! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotRuntime.java
! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/HotSpotReplacementsUtil.java

Changeset: 08e06d4a9e73
Author:    Christian Haeubl <haeubl at ssw.jku.at>
Date:      2013-07-08 12:01 +0200
URL:       http://hg.openjdk.java.net/graal/graal/rev/08e06d4a9e73

Removed API to access method invocation count from Graal.

! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/CompilationStatistics.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/HotSpotResolvedJavaMethod.java
! src/share/vm/graal/graalCompilerToVM.cpp

Changeset: 88672775a26c
Author:    Christian Haeubl <haeubl at ssw.jku.at>
Date:      2013-07-08 16:55 +0200
URL:       http://hg.openjdk.java.net/graal/graal/rev/88672775a26c

Compilation policy fixes and changed default compilation policy.

! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/CompilationTask.java
! src/cpu/x86/vm/templateInterpreter_x86_64.cpp
! src/share/vm/interpreter/invocationCounter.cpp
! src/share/vm/oops/methodCounters.cpp
! src/share/vm/oops/methodCounters.hpp
! src/share/vm/runtime/compilationPolicy.cpp
! src/share/vm/runtime/globals.hpp

Changeset: 4b88e5c93f04
Author:    Christian Haeubl <haeubl at ssw.jku.at>
Date:      2013-07-08 17:14 +0200
URL:       http://hg.openjdk.java.net/graal/graal/rev/4b88e5c93f04

Minor C++ compilation fixes.

! src/cpu/x86/vm/templateInterpreter_x86_64.cpp
! src/share/vm/graal/graalCompiler.cpp

Changeset: 678cdd287d60
Author:    Christian Haeubl <haeubl at ssw.jku.at>
Date:      2013-07-08 17:32 +0200
URL:       http://hg.openjdk.java.net/graal/graal/rev/678cdd287d60

Merge.


Changeset: 8060a20be76b
Author:    Thomas Wuerthinger <thomas.wuerthinger at oracle.com>
Date:      2013-07-07 21:00 +0200
URL:       http://hg.openjdk.java.net/graal/graal/rev/8060a20be76b

Fix visitor in OptimizedCallTarget class.

! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/OptimizedCallTarget.java

Changeset: 90a7a58bf54f
Author:    Thomas Wuerthinger <thomas.wuerthinger at oracle.com>
Date:      2013-07-07 21:01 +0200
URL:       http://hg.openjdk.java.net/graal/graal/rev/90a7a58bf54f

Create utility method in InliningUtil for inlining macro nodes.

! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/InliningUtil.java

Changeset: a71fa3b8553b
Author:    Thomas Wuerthinger <thomas.wuerthinger at oracle.com>
Date:      2013-07-07 21:01 +0200
URL:       http://hg.openjdk.java.net/graal/graal/rev/a71fa3b8553b

Fix Truffle cache to handle macro nodes correctly.

! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/TruffleCache.java

Changeset: e7c2a0aa1fff
Author:    Thomas Wuerthinger <thomas.wuerthinger at oracle.com>
Date:      2013-07-07 21:30 +0200
URL:       http://hg.openjdk.java.net/graal/graal/rev/e7c2a0aa1fff

Fix unsafe load/store canonicalization to fields to also check accessKind.
Simplify partial evaluator canonicalizer.

! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/extended/UnsafeLoadNode.java
! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/extended/UnsafeStoreNode.java
! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/PartialEvaluatorCanonicalizer.java

Changeset: 2ea604c4c6ec
Author:    Thomas Wuerthinger <thomas.wuerthinger at oracle.com>
Date:      2013-07-07 22:28 +0200
URL:       http://hg.openjdk.java.net/graal/graal/rev/2ea604c4c6ec

Factor and improve unsafe load/store canonicalization.

! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/extended/UnsafeAccessNode.java
! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/extended/UnsafeLoadNode.java
! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/extended/UnsafeStoreNode.java
! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/PartialEvaluatorCanonicalizer.java

Changeset: 8660a090c3e2
Author:    Thomas Wuerthinger <thomas.wuerthinger at oracle.com>
Date:      2013-07-07 23:32 +0200
URL:       http://hg.openjdk.java.net/graal/graal/rev/8660a090c3e2

Merge.


Changeset: ac8b195fd3aa
Author:    Thomas Wuerthinger <thomas.wuerthinger at oracle.com>
Date:      2013-07-07 23:51 +0200
URL:       http://hg.openjdk.java.net/graal/graal/rev/ac8b195fd3aa

New unsafe cast CompilerDirectives method in Truffle API.

! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/nodes/UnsafeCastMacroNode.java
! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/substitutions/CompilerDirectivesSubstitutions.java
! graal/com.oracle.truffle.api/src/com/oracle/truffle/api/CompilerDirectives.java

Changeset: b6e46324233f
Author:    Thomas Wuerthinger <thomas.wuerthinger at oracle.com>
Date:      2013-07-08 00:05 +0200
URL:       http://hg.openjdk.java.net/graal/graal/rev/b6e46324233f

Make CompilerDirectives.unsafeCast a generic method.

! graal/com.oracle.truffle.api/src/com/oracle/truffle/api/CompilerDirectives.java

Changeset: 192a3b3c7292
Author:    Thomas Wuerthinger <thomas.wuerthinger at oracle.com>
Date:      2013-07-08 15:54 +0200
URL:       http://hg.openjdk.java.net/graal/graal/rev/192a3b3c7292

Merge.

! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/InliningUtil.java

Changeset: aca7481e71d1
Author:    Thomas Wuerthinger <thomas.wuerthinger at oracle.com>
Date:      2013-07-08 16:27 +0200
URL:       http://hg.openjdk.java.net/graal/graal/rev/aca7481e71d1

Create new intrinsic for GuardingPiNode for null check guarding. Fix ArraySubstitutions.

! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/GuardingPiNode.java
! graal/com.oracle.graal.replacements/src/com/oracle/graal/replacements/ArraySubstitutions.java

Changeset: ab689f0086bb
Author:    Thomas Wuerthinger <thomas.wuerthinger at oracle.com>
Date:      2013-07-08 21:08 +0200
URL:       http://hg.openjdk.java.net/graal/graal/rev/ab689f0086bb

Fix unsafe access node.

! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/extended/UnsafeAccessNode.java

Changeset: d71c56c67921
Author:    Thomas Wuerthinger <thomas.wuerthinger at oracle.com>
Date:      2013-07-08 21:12 +0200
URL:       http://hg.openjdk.java.net/graal/graal/rev/d71c56c67921

Improve performance of calling Truffle call targets.

! 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/src/com/oracle/graal/hotspot/bridge/CompilerToVMImpl.java
! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotNmethod.java
! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/nodes/HotSpotNmethodExecuteNode.java
! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/HotSpotNmethodSubstitutions.java
! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/extended/ReadNode.java
! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/OptimizedCallTarget.java
! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/substitutions/OptimizedCallTargetSubstitutions.java
! src/cpu/x86/vm/graalCodeInstaller_x86.hpp

Changeset: 2abf1c8b062a
Author:    Thomas Wuerthinger <thomas.wuerthinger at oracle.com>
Date:      2013-07-08 21:12 +0200
URL:       http://hg.openjdk.java.net/graal/graal/rev/2abf1c8b062a

Merge.

! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/bridge/CompilerToVMImpl.java

Changeset: a7d50a27982c
Author:    Thomas Wuerthinger <thomas.wuerthinger at oracle.com>
Date:      2013-07-08 21:14 +0200
URL:       http://hg.openjdk.java.net/graal/graal/rev/a7d50a27982c

Remove unused import.

! graal/com.oracle.graal.hotspot.amd64/src/com/oracle/graal/hotspot/amd64/AMD64HotSpotLIRGenerator.java

Changeset: dad6e7ff1f93
Author:    twisti
Date:      2013-07-08 14:49 -0700
URL:       http://hg.openjdk.java.net/graal/graal/rev/dad6e7ff1f93

Added unique Label identifier.

! graal/com.oracle.graal.asm.ptx/src/com/oracle/graal/asm/ptx/AbstractPTXAssembler.java
! graal/com.oracle.graal.asm/src/com/oracle/graal/asm/Label.java
! graal/com.oracle.graal.lir.ptx/src/com/oracle/graal/lir/ptx/PTXControlFlow.java

Changeset: c79cf526508e
Author:    Thomas Wuerthinger <thomas.wuerthinger at oracle.com>
Date:      2013-07-08 22:12 +0200
URL:       http://hg.openjdk.java.net/graal/graal/rev/c79cf526508e

Remove HotSpotNmethodSubstitutions.

- graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/nodes/HotSpotNmethodExecuteNode.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/HotSpotNmethodSubstitutions.java

Changeset: 63083745d390
Author:    Thomas Wuerthinger <thomas.wuerthinger at oracle.com>
Date:      2013-07-08 22:14 +0200
URL:       http://hg.openjdk.java.net/graal/graal/rev/63083745d390

Clean up OptimizedCallTarget and HotSpotNmethod.execute.

! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotNmethod.java
! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/OptimizedCallTarget.java

Changeset: 89efc9dd9f86
Author:    Thomas Wuerthinger <thomas.wuerthinger at oracle.com>
Date:      2013-07-09 01:27 +0200
URL:       http://hg.openjdk.java.net/graal/graal/rev/89efc9dd9f86

Small fixes for lowering phase.

! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/LoweringPhase.java

Changeset: b25a07ad3678
Author:    Thomas Wuerthinger <thomas.wuerthinger at oracle.com>
Date:      2013-07-09 01:27 +0200
URL:       http://hg.openjdk.java.net/graal/graal/rev/b25a07ad3678

Merge.


Changeset: 4ef92b67aeae
Author:    Doug Simon <doug.simon at oracle.com>
Date:      2013-07-09 10:40 +0200
URL:       http://hg.openjdk.java.net/graal/graal/rev/4ef92b67aeae

added HSAIL backend and tests
Contributed-by: Vasanth Venkatachalam <vasanth.venkatachalam at amd.com>
Contributed-by: Tom.Deneau <tom.deneau at amd.com>
Contributed-by: Eric Caspole <eric.caspole at amd.com>

+ graal/com.oracle.graal.asm.hsail/src/com/oracle/graal/asm/hsail/AbstractHSAILAssembler.java
+ graal/com.oracle.graal.asm.hsail/src/com/oracle/graal/asm/hsail/HSAILAddress.java
+ graal/com.oracle.graal.asm.hsail/src/com/oracle/graal/asm/hsail/HSAILAssembler.java
! graal/com.oracle.graal.asm.ptx/src/com/oracle/graal/asm/ptx/AbstractPTXAssembler.java
! graal/com.oracle.graal.asm/src/com/oracle/graal/asm/AbstractAssembler.java
! graal/com.oracle.graal.asm/src/com/oracle/graal/asm/Label.java
+ graal/com.oracle.graal.compiler.hsail.test.infra/src/com/oracle/graal/compiler/hsail/test/infra/GraalKernelTester.java
+ graal/com.oracle.graal.compiler.hsail.test.infra/src/com/oracle/graal/compiler/hsail/test/infra/KernelTester.java
+ graal/com.oracle.graal.compiler.hsail.test/src/com/oracle/graal/compiler/hsail/test/BasicHSAILTest.java
+ graal/com.oracle.graal.compiler.hsail.test/src/com/oracle/graal/compiler/hsail/test/CallTest.java
+ graal/com.oracle.graal.compiler.hsail.test/src/com/oracle/graal/compiler/hsail/test/FcompUnorderedTest.java
+ graal/com.oracle.graal.compiler.hsail.test/src/com/oracle/graal/compiler/hsail/test/FloatConvertTest.java
+ graal/com.oracle.graal.compiler.hsail.test/src/com/oracle/graal/compiler/hsail/test/FloatDivPrecisionTest.java
+ graal/com.oracle.graal.compiler.hsail.test/src/com/oracle/graal/compiler/hsail/test/FloatSqrtTest.java
+ graal/com.oracle.graal.compiler.hsail.test/src/com/oracle/graal/compiler/hsail/test/IntAddIndexTest.java
+ graal/com.oracle.graal.compiler.hsail.test/src/com/oracle/graal/compiler/hsail/test/IntAddTest.java
+ graal/com.oracle.graal.compiler.hsail.test/src/com/oracle/graal/compiler/hsail/test/IntDivTest.java
+ graal/com.oracle.graal.compiler.hsail.test/src/com/oracle/graal/compiler/hsail/test/IntDoubledTest.java
+ graal/com.oracle.graal.compiler.hsail.test/src/com/oracle/graal/compiler/hsail/test/IntFloatConvertTest.java
+ graal/com.oracle.graal.compiler.hsail.test/src/com/oracle/graal/compiler/hsail/test/IntLongConvertTest.java
+ graal/com.oracle.graal.compiler.hsail.test/src/com/oracle/graal/compiler/hsail/test/IntModTest.java
+ graal/com.oracle.graal.compiler.hsail.test/src/com/oracle/graal/compiler/hsail/test/IntMulTest.java
+ graal/com.oracle.graal.compiler.hsail.test/src/com/oracle/graal/compiler/hsail/test/IntSqrAddTest.java
+ graal/com.oracle.graal.compiler.hsail.test/src/com/oracle/graal/compiler/hsail/test/IntSquaredGidCmpTest.java
+ graal/com.oracle.graal.compiler.hsail.test/src/com/oracle/graal/compiler/hsail/test/IntSquaredTernaryTest.java
+ graal/com.oracle.graal.compiler.hsail.test/src/com/oracle/graal/compiler/hsail/test/IntSquaredTest.java
+ graal/com.oracle.graal.compiler.hsail.test/src/com/oracle/graal/compiler/hsail/test/IntSubTest.java
+ graal/com.oracle.graal.compiler.hsail.test/src/com/oracle/graal/compiler/hsail/test/IntSumArrayTest.java
+ graal/com.oracle.graal.compiler.hsail.test/src/com/oracle/graal/compiler/hsail/test/StaticDoubleSpillTest.java
+ graal/com.oracle.graal.compiler.hsail.test/src/com/oracle/graal/compiler/hsail/test/StaticIntSpillTest.java
+ graal/com.oracle.graal.compiler.hsail.test/src/com/oracle/graal/compiler/hsail/test/StaticMandelTest.java
+ graal/com.oracle.graal.compiler.hsail.test/src/com/oracle/graal/compiler/hsail/test/StaticMethod16InArraysTest.java
+ graal/com.oracle.graal.compiler.hsail.test/src/com/oracle/graal/compiler/hsail/test/StaticMethodThreeIntArrays.java
+ graal/com.oracle.graal.compiler.hsail.test/src/com/oracle/graal/compiler/hsail/test/StaticMethodTwoIntArrays.java
+ graal/com.oracle.graal.compiler.hsail.test/src/com/oracle/graal/compiler/hsail/test/StaticNBodySpillTest.java
+ graal/com.oracle.graal.compiler.hsail.test/src/com/oracle/graal/compiler/hsail/test/StaticNBodyTest.java
+ graal/com.oracle.graal.compiler.hsail/src/com/oracle/graal/compiler/hsail/CompileAndDispatch.java
+ graal/com.oracle.graal.compiler.hsail/src/com/oracle/graal/compiler/hsail/ForEachToGraal.java
+ graal/com.oracle.graal.compiler.hsail/src/com/oracle/graal/compiler/hsail/HSAILBackend.java
+ graal/com.oracle.graal.compiler.hsail/src/com/oracle/graal/compiler/hsail/HSAILCompilationResult.java
+ graal/com.oracle.graal.compiler.hsail/src/com/oracle/graal/compiler/hsail/HSAILLIRGenerator.java
! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotRuntime.java
+ graal/com.oracle.graal.hsail/src/com/oracle/graal/hsail/HSAIL.java
+ graal/com.oracle.graal.lir.hsail/src/com/oracle/graal/lir/hsail/HSAILAddressValue.java
+ graal/com.oracle.graal.lir.hsail/src/com/oracle/graal/lir/hsail/HSAILArithmetic.java
+ graal/com.oracle.graal.lir.hsail/src/com/oracle/graal/lir/hsail/HSAILBitManipulationOp.java
+ graal/com.oracle.graal.lir.hsail/src/com/oracle/graal/lir/hsail/HSAILCompare.java
+ graal/com.oracle.graal.lir.hsail/src/com/oracle/graal/lir/hsail/HSAILControlFlow.java
+ graal/com.oracle.graal.lir.hsail/src/com/oracle/graal/lir/hsail/HSAILLIRInstruction.java
+ graal/com.oracle.graal.lir.hsail/src/com/oracle/graal/lir/hsail/HSAILMove.java
! graal/com.oracle.graal.lir.ptx/src/com/oracle/graal/lir/ptx/PTXControlFlow.java
! mx/projects


From christian.thalinger at oracle.com  Tue Jul  9 11:12:28 2013
From: christian.thalinger at oracle.com (Christian Thalinger)
Date: Tue, 9 Jul 2013 11:12:28 -0700
Subject: final graal HSAIL support patch
In-Reply-To: <1231D68C-1019-43A5-8D08-8CFCF48E4ED5@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>
	<F52F166A-DACB-4724-81D7-EA8D97B252E0@oracle.com>
	<5DD1503F815BD14889DC81D28643E3A73D90E619@sausexdag06.amd.com>
	<4D9C9697-3403-450E-AEF6-190FA35E145F@oracle.com>
	<3ACAB77C-2869-4D59-B224-AEE840F2E70B@oracle.com>
	<79BF6EED-6F10-4C1D-AA29-0D870F68B323@oracle.com>
	<5DD1503F815BD14889DC81D28643E3A73D9117CB@sausexdag06.amd.com>
	<1231D68C-1019-43A5-8D08-8CFCF48E4ED5@oracle.com>
Message-ID: <EF14A5BA-DC45-4CA6-B533-8AB87A784109@oracle.com>

Thanks, Doug!  -- Chris

On Jul 9, 2013, at 2:22 AM, Doug Simon <doug.simon at oracle.com> wrote:

> The integrated patch is now in the OpenJDK repo: http://hg.openjdk.java.net/graal/graal/rev/4ef92b67aeae
> 
> The HSAIL simulator page[1] should now be updated as a result. In particular, the command line for running the test is now:
> 
> mx --vm server unittest @-G:-RemoveNeverExecutedCode @-Dsun.boot.library.path=$LD_LIBRARY_PATH @-Xms1g @-Xmx1g @XX:-UseCompressedOops hsail.test.IntSquaredTest
> 
> -Doug
> 
> [1] https://wiki.openjdk.java.net/display/Sumatra/The+HSAIL+Simulator
> 
> On Jul 9, 2013, at 12:35 AM, "Venkatachalam, Vasanth" <Vasanth.Venkatachalam at amd.com> wrote:
> 
>> That HotspotGraalRuntime instance does not have to be public. We had made it public a while ago during some internal testing of the AMD64 backend, but I thought we had reverted it back in the patch I submitted. You can go ahead and make it private.
>> 
>> Vasanth
>> 
>> -----Original Message-----
>> From: Christian Thalinger [mailto:christian.thalinger at oracle.com] 
>> Sent: Monday, July 08, 2013 4:43 PM
>> To: Venkatachalam, Vasanth
>> Cc: sw.runtimes; graal-dev at openjdk.java.net
>> Subject: Re: final graal HSAIL support patch
>> 
>> 
>> On Jul 8, 2013, at 2:41 PM, Christian Thalinger <christian.thalinger at oracle.com> wrote:
>> 
>>> 
>>> On Jun 28, 2013, at 1:28 PM, Christian Thalinger <christian.thalinger at oracle.com> wrote:
>>> 
>>>> 
>>>> On Jun 26, 2013, at 3:00 PM, "Venkatachalam, Vasanth" <Vasanth.Venkatachalam at amd.com> 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/
>>> 
>>> Any comments on this patch?  If not, I'm going to push this today.
>> 
>> Oh, wait!  Actually I have a question:  why do you need this to be public?
>> 
>> --- old/graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/HotSpotGraalRuntime.java	2013-06-28 13:26:17.000000000 -0700
>> +++ new/graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/HotSpotGraalRuntime.java	2013-06-28 13:26:17.000000000 -0700
>> @@ -49,7 +49,7 @@
>> */
>> public abstract class HotSpotGraalRuntime implements GraalRuntime {
>> 
>> -    private static HotSpotGraalRuntime instance;
>> +    public static HotSpotGraalRuntime instance;
>> 
>>    /**
>>     * Gets the singleton {@link HotSpotGraalRuntime} object.
>> 
>> -- Chris
>> 
>>> 
>>> -- 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" <Vasanth.Venkatachalam at amd.com> 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 <christian.thalinger at oracle.com> wrote:
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> On Jun 24, 2013, at 11:13 AM, Christian Thalinger <christian.thalinger at oracle.com> 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" <Vasanth.Venkatachalam at amd.com> 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
>>>>> <graal.patch>
>>>>> 
>>>>> 
>>>>> 
>>>>> <graal.zip>
>>>> 
>>> 
>> 
>> 
>> 
> 


From christian.thalinger at oracle.com  Tue Jul  9 11:15:53 2013
From: christian.thalinger at oracle.com (Christian Thalinger)
Date: Tue, 9 Jul 2013 11:15:53 -0700
Subject: HSAIL Simulator open sourced
In-Reply-To: <942CA0B2-E6A6-480E-9DFE-6A8EC96E8CEE@oracle.com>
References: <BC97738F8E7C8742BABED7F06FB9DF91450366AD@sausexdag01.amd.com>
	<942CA0B2-E6A6-480E-9DFE-6A8EC96E8CEE@oracle.com>
Message-ID: <22E83966-6D54-42B3-9245-A0B6F0D377CA@oracle.com>


On Jul 9, 2013, at 2:18 AM, Doug Simon <doug.simon at oracle.com> wrote:

> I've managed to build the simulator and use it to run all the Graal HSAIL tests. It was relatively straight-forward - nice work!
> 
> I have one minor request. Is it possible to have the simulator be configurable to be less verbose? Most of the existing Graal unit tests don't (or shouldn't) produce output on the console (apart from that generated by Junit itself). It would be great if the simulator could be made to do the same somehow.
> 
> And I have one major request. Can you port the simulator to Java? ;-) This would greatly simplify integrating it into the gate tests.

That is a very good point.  Having a simulator written in Java for all GPU architectures we support would be a major help to keep the compilers up and running and not break anything.  We've seen how bit-rot can easily happen with things like the Zero or Shark ports.

-- Chris

> 
> -Doug
> 
> On Jul 2, 2013, at 12:52 AM, "Deneau, Tom" <tom.deneau at amd.com> wrote:
> 
>> I am pleased to announce that the HSA Foundation has open sourced the
>> following projects:
>> 
>>   * libHSAIL (tools for parsing, assembling and disassembling HSAIL)
>>   * an HSAIL Instruction Set Simulator
>>   * OKRA interface to the HSAIL Simulator
>> 
>> The following wiki page goes into detail of how to build the simulator
>> and describes some tests that can be run against it, including tests that
>> use the graal HSAIL backend patch which is currently under review.
>> 
>> https://wiki.openjdk.java.net/display/Sumatra/The+HSAIL+Simulator
>> 
>> -- Tom Deneau, AMD
>> 
>> 
>> 
> 


From tom.deneau at amd.com  Tue Jul  9 13:32:14 2013
From: tom.deneau at amd.com (Deneau, Tom)
Date: Tue, 9 Jul 2013 20:32:14 +0000
Subject: dependencies in mx/projects
Message-ID: <BC97738F8E7C8742BABED7F06FB9DF91450390AE@sausexdag01.amd.com>

In mx/projects, I had to add a dependency such that project A was dependent on project B.
But B was already dependent on A, which seemed to get the mx dependency processor into a loop.

Is this a bug in mx, or should I rearrange things so there is not such a loop in the dependency graph?

-- Tom



From thomas.wuerthinger at oracle.com  Tue Jul  9 13:44:59 2013
From: thomas.wuerthinger at oracle.com (Thomas Wuerthinger)
Date: Tue, 9 Jul 2013 22:44:59 +0200
Subject: dependencies in mx/projects
In-Reply-To: <BC97738F8E7C8742BABED7F06FB9DF91450390AE@sausexdag01.amd.com>
References: <BC97738F8E7C8742BABED7F06FB9DF91450390AE@sausexdag01.amd.com>
Message-ID: <216E3649-B17E-4A41-82F6-06EE3DCA8EF7@oracle.com>

This is a feature ;). We don't allow cyclic dependencies. - thomas

On Jul 9, 2013, at 10:32 PM, "Deneau, Tom" <tom.deneau at amd.com> wrote:

> In mx/projects, I had to add a dependency such that project A was dependent on project B.
> But B was already dependent on A, which seemed to get the mx dependency processor into a loop.
> 
> Is this a bug in mx, or should I rearrange things so there is not such a loop in the dependency graph?
> 
> -- Tom
> 
> 


From doug.simon at oracle.com  Tue Jul  9 13:50:31 2013
From: doug.simon at oracle.com (Doug Simon)
Date: Tue, 9 Jul 2013 22:50:31 +0200
Subject: dependencies in mx/projects
In-Reply-To: <BC97738F8E7C8742BABED7F06FB9DF91450390AE@sausexdag01.amd.com>
References: <BC97738F8E7C8742BABED7F06FB9DF91450390AE@sausexdag01.amd.com>
Message-ID: <95C46456-BF87-4092-A664-3D47A698985E@oracle.com>

Dependency loops are definitely not supported by mx. And they are a questionable in reality ;-)

You can use 'mx canonicalizeprojects' to ensure mx/projects is canonical. In fact, you should do this as the gate checks it.

-Doug

On Jul 9, 2013, at 10:32 PM, "Deneau, Tom" <tom.deneau at amd.com> wrote:

> In mx/projects, I had to add a dependency such that project A was dependent on project B.
> But B was already dependent on A, which seemed to get the mx dependency processor into a loop.
> 
> Is this a bug in mx, or should I rearrange things so there is not such a loop in the dependency graph?
> 
> -- Tom
> 
> 


From java at stefan-marr.de  Wed Jul 10 07:17:31 2013
From: java at stefan-marr.de (Stefan Marr)
Date: Wed, 10 Jul 2013 16:17:31 +0200
Subject: TruffleSOM: A Smalltalk implemented with Truffle
In-Reply-To: <F689F796-B077-4555-BCDB-871D1EE409F3@stefan-marr.de>
References: <F689F796-B077-4555-BCDB-871D1EE409F3@stefan-marr.de>
Message-ID: <AE4C0C04-5123-4757-B162-0F94AA695C0B@stefan-marr.de>

Hi:

On 28 Jun 2013, at 15:23, Stefan Marr <java at stefan-marr.de> wrote:

> In order to get to know the Truffle framework better, I ported SOM, a little
> Smalltalk bytecode interpreter written in Java, to Truffle.
>   https://github.com/smarr/TruffleSOM

As a brief followup, with the help of Thomas and Michael, I corrected the implementation to use packed and materialized frames where appropriate.
With these changes it is possible to run TruffleSOM on the Graal VM.
The tests run, the benchmarks however, don't complete yet. Looks to me like the optimization phase trips over something that is not quite right yet and sees a null where a proper object should be. Will look into that later.

Currently more interesting to me is the general question whether Truffle is supposed to support non-local returns or similar language features.
When moving from purely using VirtualFrames to the different Frame types Truffle is expecting, I had to find an ad hoc solution, and I am not sure whether that is the best way of doing things.

Implementing non-local returns with when just using VirtualFrames is straight forward, because I can check the frames for their identity and know when I found the correct frame.
When using the proper frame classes however, I am using an extra frame slot, which contains a marker object that I can check when unwinding the stack with a control flow exception.

Not sure whether that is the ideal solution, especially with respect to performance.
For SOM/Smalltalk, the functionally that would be necessary includes the ability to determine the target frame for a non-local return, as well as to be able to check whether the frame is actually still on the stack in order to forbid non-local returns from blocks/lambdas that have escaped their activation context.


Thanks and 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 Vasanth.Venkatachalam at amd.com  Wed Jul 10 08:55:11 2013
From: Vasanth.Venkatachalam at amd.com (Venkatachalam, Vasanth)
Date: Wed, 10 Jul 2013 15:55:11 +0000
Subject: handling method calls in HSAIL
Message-ID: <5DD1503F815BD14889DC81D28643E3A73D911D23@sausexdag06.amd.com>

Hi,

While implementing support for function calls in the HSAIL backend, we identified some ways of tackling common problems that both HSAIL and PTX backends may face. We wanted to describe our ideas and see what people think.


1)      In the same HSAIL kernel, A calls B multiple times from different places in its code, and we want to avoid compiling B more than once.

2)      In the same HSAIL kernel, A calls B, A calls C, and C calls B. Here again, we want to avoid compiling B more than once.

3)      Multiple HSAIL kernels call the same method.

To tackle 1) and 2), we're thinking of defining a HashMap<ResolvedJavaMethod, Boolean> in HSAILCompilationResult which keeps track of all methods called by a single HSAIL kernel (and any methods it calls) and whether they have been compiled. Whenever the LIR triggers the creation of a direct call node (via call to HSAILLIRGenerator.emitDirectCall), we check whether a reference to the called method already exists in this Hashmap (which is global to a single HSAIL kernel), and if not, we add it and set a flag that indicates that the method needs to be compiled.

We then modify getHSAILCompilationResult so that after compiling the body of the current method, we process the above Hashmap to see which methods have not been compiled yet and compile those methods thru recursive calls to getCompilationResult().

It sounds like this should get around 1) and 2, but for 3) we would need a data structure that's global to all kernels. We're still scoping out what that should be.

We've implemented this approach in our local branch (not yet checked in) and are testing it, but wanted to see what people think.
Do folks have other ideas for tackling 1) and 2) that would be more efficient?

Vasanth







From tom.deneau at amd.com  Wed Jul 10 14:53:38 2013
From: tom.deneau at amd.com (Deneau, Tom)
Date: Wed, 10 Jul 2013 21:53:38 +0000
Subject: HSAIL Simulator open sourced
Message-ID: <BC97738F8E7C8742BABED7F06FB9DF9145039779@sausexdag01.amd.com>

Now that the HSAIL backend has been checked into the Graal trunk,
I have updated the wiki page below since the procedure for building and running
graal against the simulator is simpler now.

-- Tom

-----Original Message-----
From: Deneau, Tom 
Sent: Monday, July 01, 2013 5:52 PM
To: sumatra-dev at openjdk.java.net; graal-dev at openjdk.java.net
Subject: HSAIL Simulator open sourced

I am pleased to announce that the HSA Foundation has open sourced the
following projects:

    * libHSAIL (tools for parsing, assembling and disassembling HSAIL)
    * an HSAIL Instruction Set Simulator
    * OKRA interface to the HSAIL Simulator

The following wiki page goes into detail of how to build the simulator
and describes some tests that can be run against it, including tests that
use the graal HSAIL backend patch which is currently under review.

https://wiki.openjdk.java.net/display/Sumatra/The+HSAIL+Simulator 

-- Tom Deneau, AMD




From morris.meyer at oracle.com  Thu Jul 11 10:33:23 2013
From: morris.meyer at oracle.com (Morris Meyer)
Date: Thu, 11 Jul 2013 13:33:23 -0400
Subject: handling method calls in HSAIL
In-Reply-To: <5DD1503F815BD14889DC81D28643E3A73D911D23@sausexdag06.amd.com>
References: <5DD1503F815BD14889DC81D28643E3A73D911D23@sausexdag06.amd.com>
Message-ID: <51DEEC63.306@oracle.com>

Vasanth,

I added a class ExternalCompilationResult recently that could be a good 
place for this sort of functionality.  Could you make use of it for HSAIL?

This was part of changes recently that enabled PTX compiled kernels to 
execute on live Nvida hardware.

         --mm

On 7/10/13, 11:55 AM, Venkatachalam, Vasanth wrote:
> Hi,
>
> While implementing support for function calls in the HSAIL backend, we identified some ways of tackling common problems that both HSAIL and PTX backends may face. We wanted to describe our ideas and see what people think.
>
>
> 1)      In the same HSAIL kernel, A calls B multiple times from different places in its code, and we want to avoid compiling B more than once.
>
> 2)      In the same HSAIL kernel, A calls B, A calls C, and C calls B. Here again, we want to avoid compiling B more than once.
>
> 3)      Multiple HSAIL kernels call the same method.
>
> To tackle 1) and 2), we're thinking of defining a HashMap<ResolvedJavaMethod, Boolean> in HSAILCompilationResult which keeps track of all methods called by a single HSAIL kernel (and any methods it calls) and whether they have been compiled. Whenever the LIR triggers the creation of a direct call node (via call to HSAILLIRGenerator.emitDirectCall), we check whether a reference to the called method already exists in this Hashmap (which is global to a single HSAIL kernel), and if not, we add it and set a flag that indicates that the method needs to be compiled.
>
> We then modify getHSAILCompilationResult so that after compiling the body of the current method, we process the above Hashmap to see which methods have not been compiled yet and compile those methods thru recursive calls to getCompilationResult().
>
> It sounds like this should get around 1) and 2, but for 3) we would need a data structure that's global to all kernels. We're still scoping out what that should be.
>
> We've implemented this approach in our local branch (not yet checked in) and are testing it, but wanted to see what people think.
> Do folks have other ideas for tackling 1) and 2) that would be more efficient?
>
> Vasanth
>
>
>
>
>
>


From tom.deneau at amd.com  Thu Jul 11 12:35:11 2013
From: tom.deneau at amd.com (Deneau, Tom)
Date: Thu, 11 Jul 2013 19:35:11 +0000
Subject: [Sw.runtimes] final graal HSAIL support patch
In-Reply-To: <1231D68C-1019-43A5-8D08-8CFCF48E4ED5@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>
	<F52F166A-DACB-4724-81D7-EA8D97B252E0@oracle.com>
	<5DD1503F815BD14889DC81D28643E3A73D90E619@sausexdag06.amd.com>
	<4D9C9697-3403-450E-AEF6-190FA35E145F@oracle.com>
	<3ACAB77C-2869-4D59-B224-AEE840F2E70B@oracle.com>
	<79BF6EED-6F10-4C1D-AA29-0D870F68B323@oracle.com>
	<5DD1503F815BD14889DC81D28643E3A73D9117CB@sausexdag06.amd.com>
	<1231D68C-1019-43A5-8D08-8CFCF48E4ED5@oracle.com>
Message-ID: <BC97738F8E7C8742BABED7F06FB9DF9145039D0C@sausexdag01.amd.com>

Doug and others ---

We have a fairly small amount of bugfixes or new functionality which we added to the HSAIL backend while the review was going on.
And we would like that to get into the trunk.  Should we just supply a webrev with some explanatory text as to what
the changes are accomplishing?

On a separate topic, as you are probably aware from the review, we have some junit tests
that require jdk8 (they use lambdas) and were thus not submitted as part of the webrev.  We actually have
considerably more tests that use lambdas than the ones that don't only because the lambda tests were a
little easier to write.

We can of course run these jdk8-based tests privately here but it would be nice if they could be used
to catch problems sooner.

What is your estimate as to when graal will support projects that require jdk8?

-- 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: Tuesday, July 09, 2013 4:23 AM
To: sw.runtimes
Cc: graal-dev at openjdk.java.net
Subject: Re: [Sw.runtimes] final graal HSAIL support patch

The integrated patch is now in the OpenJDK repo: http://hg.openjdk.java.net/graal/graal/rev/4ef92b67aeae

The HSAIL simulator page[1] should now be updated as a result. In particular, the command line for running the test is now:

mx --vm server unittest @-G:-RemoveNeverExecutedCode @-Dsun.boot.library.path=$LD_LIBRARY_PATH @-Xms1g @-Xmx1g @XX:-UseCompressedOops hsail.test.IntSquaredTest

-Doug

[1] https://wiki.openjdk.java.net/display/Sumatra/The+HSAIL+Simulator

On Jul 9, 2013, at 12:35 AM, "Venkatachalam, Vasanth" <Vasanth.Venkatachalam at amd.com> wrote:

> That HotspotGraalRuntime instance does not have to be public. We had made it public a while ago during some internal testing of the AMD64 backend, but I thought we had reverted it back in the patch I submitted. You can go ahead and make it private.
> 
> Vasanth
> 
> -----Original Message-----
> From: Christian Thalinger [mailto:christian.thalinger at oracle.com] 
> Sent: Monday, July 08, 2013 4:43 PM
> To: Venkatachalam, Vasanth
> Cc: sw.runtimes; graal-dev at openjdk.java.net
> Subject: Re: final graal HSAIL support patch
> 
> 
> On Jul 8, 2013, at 2:41 PM, Christian Thalinger <christian.thalinger at oracle.com> wrote:
> 
>> 
>> On Jun 28, 2013, at 1:28 PM, Christian Thalinger <christian.thalinger at oracle.com> wrote:
>> 
>>> 
>>> On Jun 26, 2013, at 3:00 PM, "Venkatachalam, Vasanth" <Vasanth.Venkatachalam at amd.com> 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/
>> 
>> Any comments on this patch?  If not, I'm going to push this today.
> 
> Oh, wait!  Actually I have a question:  why do you need this to be public?
> 
> --- old/graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/HotSpotGraalRuntime.java	2013-06-28 13:26:17.000000000 -0700
> +++ new/graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/HotSpotGraalRuntime.java	2013-06-28 13:26:17.000000000 -0700
> @@ -49,7 +49,7 @@
>  */
> public abstract class HotSpotGraalRuntime implements GraalRuntime {
> 
> -    private static HotSpotGraalRuntime instance;
> +    public static HotSpotGraalRuntime instance;
> 
>     /**
>      * Gets the singleton {@link HotSpotGraalRuntime} object.
> 
> -- Chris
> 
>> 
>> -- 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" <Vasanth.Venkatachalam at amd.com> 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 <christian.thalinger at oracle.com> wrote:
>>>> 
>>>> 
>>>> 
>>>> 
>>>> On Jun 24, 2013, at 11:13 AM, Christian Thalinger <christian.thalinger at oracle.com> 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" <Vasanth.Venkatachalam at amd.com> 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
>>>> <graal.patch>
>>>> 
>>>> 
>>>> 
>>>> <graal.zip>
>>> 
>> 
> 
> 
> 





From doug.simon at oracle.com  Thu Jul 11 13:00:51 2013
From: doug.simon at oracle.com (Doug Simon)
Date: Thu, 11 Jul 2013 22:00:51 +0200
Subject: [Sw.runtimes] final graal HSAIL support patch
In-Reply-To: <BC97738F8E7C8742BABED7F06FB9DF9145039D0C@sausexdag01.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>
	<F52F166A-DACB-4724-81D7-EA8D97B252E0@oracle.com>
	<5DD1503F815BD14889DC81D28643E3A73D90E619@sausexdag06.amd.com>
	<4D9C9697-3403-450E-AEF6-190FA35E145F@oracle.com>
	<3ACAB77C-2869-4D59-B224-AEE840F2E70B@oracle.com>
	<79BF6EED-6F10-4C1D-AA29-0D870F68B323@oracle.com>
	<5DD1503F815BD14889DC81D28643E3A73D9117CB@sausexdag06.amd.com>
	<1231D68C-1019-43A5-8D08-8CFCF48E4ED5@oracle.com>
	<BC97738F8E7C8742BABED7F06FB9DF9145039D0C@sausexdag01.amd.com>
Message-ID: <67EC7C6A-3A6D-4A08-BED4-3779C5E26F04@oracle.com>

On Jul 11, 2013, at 9:35 PM, "Deneau, Tom" <tom.deneau at amd.com> wrote:

> Doug and others ---
> 
> We have a fairly small amount of bugfixes or new functionality which we added to the HSAIL backend while the review was going on.
> And we would like that to get into the trunk.  Should we just supply a webrev with some explanatory text as to what
> the changes are accomplishing?

Unfortunately, we don't have many other options in terms of reviewing external submissions (I greatly anticipate the availability of Crucible for OpenJDK projects!). So yes, please submit a webrev.

> On a separate topic, as you are probably aware from the review, we have some junit tests
> that require jdk8 (they use lambdas) and were thus not submitted as part of the webrev.  We actually have
> considerably more tests that use lambdas than the ones that don't only because the lambda tests were a
> little easier to write.

Unfortunately, we cannot move to Java 8 language features until the tools we use (namely Eclipse) supports these features. If there was a tool for translating Java 8 source code into Java 7 source code, you could at least keep writing the tests with lambdas and check in the generated sources. However, I'm not aware of such a tool. Keep your eyes on http://wiki.eclipse.org/JDT_Core/Java8 because we'll migrate as soon as Eclipse support for Java 8 is reasonably stable.

> We can of course run these jdk8-based tests privately here but it would be nice if they could be used
> to catch problems sooner.
> 
> What is your estimate as to when graal will support projects that require jdk8?

That depends entirely on the Eclipse effort mentioned above.

-Doug

> -----Original Message-----
> From: sw.runtimes-bounces at mpdtxmail.amd.com [mailto:sw.runtimes-bounces at mpdtxmail.amd.com] On Behalf Of Doug Simon
> Sent: Tuesday, July 09, 2013 4:23 AM
> To: sw.runtimes
> Cc: graal-dev at openjdk.java.net
> Subject: Re: [Sw.runtimes] final graal HSAIL support patch
> 
> The integrated patch is now in the OpenJDK repo: http://hg.openjdk.java.net/graal/graal/rev/4ef92b67aeae
> 
> The HSAIL simulator page[1] should now be updated as a result. In particular, the command line for running the test is now:
> 
> mx --vm server unittest @-G:-RemoveNeverExecutedCode @-Dsun.boot.library.path=$LD_LIBRARY_PATH @-Xms1g @-Xmx1g @XX:-UseCompressedOops hsail.test.IntSquaredTest
> 
> -Doug
> 
> [1] https://wiki.openjdk.java.net/display/Sumatra/The+HSAIL+Simulator
> 
> On Jul 9, 2013, at 12:35 AM, "Venkatachalam, Vasanth" <Vasanth.Venkatachalam at amd.com> wrote:
> 
>> That HotspotGraalRuntime instance does not have to be public. We had made it public a while ago during some internal testing of the AMD64 backend, but I thought we had reverted it back in the patch I submitted. You can go ahead and make it private.
>> 
>> Vasanth
>> 
>> -----Original Message-----
>> From: Christian Thalinger [mailto:christian.thalinger at oracle.com] 
>> Sent: Monday, July 08, 2013 4:43 PM
>> To: Venkatachalam, Vasanth
>> Cc: sw.runtimes; graal-dev at openjdk.java.net
>> Subject: Re: final graal HSAIL support patch
>> 
>> 
>> On Jul 8, 2013, at 2:41 PM, Christian Thalinger <christian.thalinger at oracle.com> wrote:
>> 
>>> 
>>> On Jun 28, 2013, at 1:28 PM, Christian Thalinger <christian.thalinger at oracle.com> wrote:
>>> 
>>>> 
>>>> On Jun 26, 2013, at 3:00 PM, "Venkatachalam, Vasanth" <Vasanth.Venkatachalam at amd.com> 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/
>>> 
>>> Any comments on this patch?  If not, I'm going to push this today.
>> 
>> Oh, wait!  Actually I have a question:  why do you need this to be public?
>> 
>> --- old/graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/HotSpotGraalRuntime.java	2013-06-28 13:26:17.000000000 -0700
>> +++ new/graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/HotSpotGraalRuntime.java	2013-06-28 13:26:17.000000000 -0700
>> @@ -49,7 +49,7 @@
>> */
>> public abstract class HotSpotGraalRuntime implements GraalRuntime {
>> 
>> -    private static HotSpotGraalRuntime instance;
>> +    public static HotSpotGraalRuntime instance;
>> 
>>    /**
>>     * Gets the singleton {@link HotSpotGraalRuntime} object.
>> 
>> -- Chris
>> 
>>> 
>>> -- 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" <Vasanth.Venkatachalam at amd.com> 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 <christian.thalinger at oracle.com> wrote:
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> On Jun 24, 2013, at 11:13 AM, Christian Thalinger <christian.thalinger at oracle.com> 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" <Vasanth.Venkatachalam at amd.com> 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
>>>>> <graal.patch>
>>>>> 
>>>>> 
>>>>> 
>>>>> <graal.zip>
>>>> 
>>> 
>> 
>> 
>> 
> 
> 
> 
> 


From tom.deneau at amd.com  Thu Jul 11 13:11:48 2013
From: tom.deneau at amd.com (Deneau, Tom)
Date: Thu, 11 Jul 2013 20:11:48 +0000
Subject: [Sw.runtimes] final graal HSAIL support patch
In-Reply-To: <67EC7C6A-3A6D-4A08-BED4-3779C5E26F04@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>
	<F52F166A-DACB-4724-81D7-EA8D97B252E0@oracle.com>
	<5DD1503F815BD14889DC81D28643E3A73D90E619@sausexdag06.amd.com>
	<4D9C9697-3403-450E-AEF6-190FA35E145F@oracle.com>
	<3ACAB77C-2869-4D59-B224-AEE840F2E70B@oracle.com>
	<79BF6EED-6F10-4C1D-AA29-0D870F68B323@oracle.com>
	<5DD1503F815BD14889DC81D28643E3A73D9117CB@sausexdag06.amd.com>
	<1231D68C-1019-43A5-8D08-8CFCF48E4ED5@oracle.com>
	<BC97738F8E7C8742BABED7F06FB9DF9145039D0C@sausexdag01.amd.com>
	<67EC7C6A-3A6D-4A08-BED4-3779C5E26F04@oracle.com>
Message-ID: <BC97738F8E7C8742BABED7F06FB9DF9145039D78@sausexdag01.amd.com>

I have a cr.openjdk.java.net/~tdeneau account.  Should I just place the webrev there or do you want to go thru the procedures you used before of me emailing the patch to someone who will put it in some other location for review.

-- Tom

-----Original Message-----
From: Doug Simon [mailto:doug.simon at oracle.com] 
Sent: Thursday, July 11, 2013 3:01 PM
To: Deneau, Tom
Cc: sw.runtimes; graal-dev at openjdk.java.net
Subject: Re: [Sw.runtimes] final graal HSAIL support patch

On Jul 11, 2013, at 9:35 PM, "Deneau, Tom" <tom.deneau at amd.com> wrote:

> Doug and others ---
> 
> We have a fairly small amount of bugfixes or new functionality which we added to the HSAIL backend while the review was going on.
> And we would like that to get into the trunk.  Should we just supply a webrev with some explanatory text as to what
> the changes are accomplishing?

Unfortunately, we don't have many other options in terms of reviewing external submissions (I greatly anticipate the availability of Crucible for OpenJDK projects!). So yes, please submit a webrev.

> On a separate topic, as you are probably aware from the review, we have some junit tests
> that require jdk8 (they use lambdas) and were thus not submitted as part of the webrev.  We actually have
> considerably more tests that use lambdas than the ones that don't only because the lambda tests were a
> little easier to write.

Unfortunately, we cannot move to Java 8 language features until the tools we use (namely Eclipse) supports these features. If there was a tool for translating Java 8 source code into Java 7 source code, you could at least keep writing the tests with lambdas and check in the generated sources. However, I'm not aware of such a tool. Keep your eyes on http://wiki.eclipse.org/JDT_Core/Java8 because we'll migrate as soon as Eclipse support for Java 8 is reasonably stable.

> We can of course run these jdk8-based tests privately here but it would be nice if they could be used
> to catch problems sooner.
> 
> What is your estimate as to when graal will support projects that require jdk8?

That depends entirely on the Eclipse effort mentioned above.

-Doug

> -----Original Message-----
> From: sw.runtimes-bounces at mpdtxmail.amd.com [mailto:sw.runtimes-bounces at mpdtxmail.amd.com] On Behalf Of Doug Simon
> Sent: Tuesday, July 09, 2013 4:23 AM
> To: sw.runtimes
> Cc: graal-dev at openjdk.java.net
> Subject: Re: [Sw.runtimes] final graal HSAIL support patch
> 
> The integrated patch is now in the OpenJDK repo: http://hg.openjdk.java.net/graal/graal/rev/4ef92b67aeae
> 
> The HSAIL simulator page[1] should now be updated as a result. In particular, the command line for running the test is now:
> 
> mx --vm server unittest @-G:-RemoveNeverExecutedCode @-Dsun.boot.library.path=$LD_LIBRARY_PATH @-Xms1g @-Xmx1g @XX:-UseCompressedOops hsail.test.IntSquaredTest
> 
> -Doug
> 
> [1] https://wiki.openjdk.java.net/display/Sumatra/The+HSAIL+Simulator
> 
> On Jul 9, 2013, at 12:35 AM, "Venkatachalam, Vasanth" <Vasanth.Venkatachalam at amd.com> wrote:
> 
>> That HotspotGraalRuntime instance does not have to be public. We had made it public a while ago during some internal testing of the AMD64 backend, but I thought we had reverted it back in the patch I submitted. You can go ahead and make it private.
>> 
>> Vasanth
>> 
>> -----Original Message-----
>> From: Christian Thalinger [mailto:christian.thalinger at oracle.com] 
>> Sent: Monday, July 08, 2013 4:43 PM
>> To: Venkatachalam, Vasanth
>> Cc: sw.runtimes; graal-dev at openjdk.java.net
>> Subject: Re: final graal HSAIL support patch
>> 
>> 
>> On Jul 8, 2013, at 2:41 PM, Christian Thalinger <christian.thalinger at oracle.com> wrote:
>> 
>>> 
>>> On Jun 28, 2013, at 1:28 PM, Christian Thalinger <christian.thalinger at oracle.com> wrote:
>>> 
>>>> 
>>>> On Jun 26, 2013, at 3:00 PM, "Venkatachalam, Vasanth" <Vasanth.Venkatachalam at amd.com> 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/
>>> 
>>> Any comments on this patch?  If not, I'm going to push this today.
>> 
>> Oh, wait!  Actually I have a question:  why do you need this to be public?
>> 
>> --- old/graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/HotSpotGraalRuntime.java	2013-06-28 13:26:17.000000000 -0700
>> +++ new/graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/HotSpotGraalRuntime.java	2013-06-28 13:26:17.000000000 -0700
>> @@ -49,7 +49,7 @@
>> */
>> public abstract class HotSpotGraalRuntime implements GraalRuntime {
>> 
>> -    private static HotSpotGraalRuntime instance;
>> +    public static HotSpotGraalRuntime instance;
>> 
>>    /**
>>     * Gets the singleton {@link HotSpotGraalRuntime} object.
>> 
>> -- Chris
>> 
>>> 
>>> -- 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" <Vasanth.Venkatachalam at amd.com> 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 <christian.thalinger at oracle.com> wrote:
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> On Jun 24, 2013, at 11:13 AM, Christian Thalinger <christian.thalinger at oracle.com> 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" <Vasanth.Venkatachalam at amd.com> 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
>>>>> <graal.patch>
>>>>> 
>>>>> 
>>>>> 
>>>>> <graal.zip>
>>>> 
>>> 
>> 
>> 
>> 
> 
> 
> 
> 




From thomas.wuerthinger at oracle.com  Thu Jul 11 20:12:50 2013
From: thomas.wuerthinger at oracle.com (Thomas Wuerthinger)
Date: Thu, 11 Jul 2013 20:12:50 -0700
Subject: TruffleSOM: A Smalltalk implemented with Truffle
In-Reply-To: <AE4C0C04-5123-4757-B162-0F94AA695C0B@stefan-marr.de>
References: <F689F796-B077-4555-BCDB-871D1EE409F3@stefan-marr.de>
	<AE4C0C04-5123-4757-B162-0F94AA695C0B@stefan-marr.de>
Message-ID: <3AB12D15-D2B1-470D-A031-C89F5DD4D5AD@oracle.com>

Stefan,

The proposed solution looks good and should not affect performance too much. Michael Haupt will be able to assist you further in making TruffleSOM run with the Truffle compiler enabled.

- thomas

On Jul 10, 2013, at 7:17 AM, Stefan Marr <java at stefan-marr.de> wrote:

> Hi:
> 
> On 28 Jun 2013, at 15:23, Stefan Marr <java at stefan-marr.de> wrote:
> 
>> In order to get to know the Truffle framework better, I ported SOM, a little
>> Smalltalk bytecode interpreter written in Java, to Truffle.
>>  https://github.com/smarr/TruffleSOM
> 
> As a brief followup, with the help of Thomas and Michael, I corrected the implementation to use packed and materialized frames where appropriate.
> With these changes it is possible to run TruffleSOM on the Graal VM.
> The tests run, the benchmarks however, don't complete yet. Looks to me like the optimization phase trips over something that is not quite right yet and sees a null where a proper object should be. Will look into that later.
> 
> Currently more interesting to me is the general question whether Truffle is supposed to support non-local returns or similar language features.
> When moving from purely using VirtualFrames to the different Frame types Truffle is expecting, I had to find an ad hoc solution, and I am not sure whether that is the best way of doing things.
> 
> Implementing non-local returns with when just using VirtualFrames is straight forward, because I can check the frames for their identity and know when I found the correct frame.
> When using the proper frame classes however, I am using an extra frame slot, which contains a marker object that I can check when unwinding the stack with a control flow exception.
> 
> Not sure whether that is the ideal solution, especially with respect to performance.
> For SOM/Smalltalk, the functionally that would be necessary includes the ability to determine the target frame for a non-local return, as well as to be able to check whether the frame is actually still on the stack in order to forbid non-local returns from blocks/lambdas that have escaped their activation context.
> 
> 
> Thanks and 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 christian.thalinger at oracle.com  Fri Jul 12 09:07:04 2013
From: christian.thalinger at oracle.com (Christian Thalinger)
Date: Fri, 12 Jul 2013 09:07:04 -0700
Subject: [Sw.runtimes] final graal HSAIL support patch
In-Reply-To: <BC97738F8E7C8742BABED7F06FB9DF9145039D78@sausexdag01.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>
	<F52F166A-DACB-4724-81D7-EA8D97B252E0@oracle.com>
	<5DD1503F815BD14889DC81D28643E3A73D90E619@sausexdag06.amd.com>
	<4D9C9697-3403-450E-AEF6-190FA35E145F@oracle.com>
	<3ACAB77C-2869-4D59-B224-AEE840F2E70B@oracle.com>
	<79BF6EED-6F10-4C1D-AA29-0D870F68B323@oracle.com>
	<5DD1503F815BD14889DC81D28643E3A73D9117CB@sausexdag06.amd.com>
	<1231D68C-1019-43A5-8D08-8CFCF48E4ED5@oracle.com>
	<BC97738F8E7C8742BABED7F06FB9DF9145039D0C@sausexdag01.amd.com>
	<67EC7C6A-3A6D-4A08-BED4-3779C5E26F04@oracle.com>
	<BC97738F8E7C8742BABED7F06FB9DF9145039D78@sausexdag01.amd.com>
Message-ID: <8FDE25C4-F1FD-4B9D-8F39-FF7357B5385B@oracle.com>


On Jul 11, 2013, at 1:11 PM, "Deneau, Tom" <tom.deneau at amd.com> wrote:

> I have a cr.openjdk.java.net/~tdeneau account.  Should I just place the webrev there or do you want to go thru the procedures you used before of me emailing the patch to someone who will put it in some other location for review.

If you have an account just upload your webrev and send the link to this list.

-- Chris

> 
> -- Tom
> 
> -----Original Message-----
> From: Doug Simon [mailto:doug.simon at oracle.com] 
> Sent: Thursday, July 11, 2013 3:01 PM
> To: Deneau, Tom
> Cc: sw.runtimes; graal-dev at openjdk.java.net
> Subject: Re: [Sw.runtimes] final graal HSAIL support patch
> 
> On Jul 11, 2013, at 9:35 PM, "Deneau, Tom" <tom.deneau at amd.com> wrote:
> 
>> Doug and others ---
>> 
>> We have a fairly small amount of bugfixes or new functionality which we added to the HSAIL backend while the review was going on.
>> And we would like that to get into the trunk.  Should we just supply a webrev with some explanatory text as to what
>> the changes are accomplishing?
> 
> Unfortunately, we don't have many other options in terms of reviewing external submissions (I greatly anticipate the availability of Crucible for OpenJDK projects!). So yes, please submit a webrev.
> 
>> On a separate topic, as you are probably aware from the review, we have some junit tests
>> that require jdk8 (they use lambdas) and were thus not submitted as part of the webrev.  We actually have
>> considerably more tests that use lambdas than the ones that don't only because the lambda tests were a
>> little easier to write.
> 
> Unfortunately, we cannot move to Java 8 language features until the tools we use (namely Eclipse) supports these features. If there was a tool for translating Java 8 source code into Java 7 source code, you could at least keep writing the tests with lambdas and check in the generated sources. However, I'm not aware of such a tool. Keep your eyes on http://wiki.eclipse.org/JDT_Core/Java8 because we'll migrate as soon as Eclipse support for Java 8 is reasonably stable.
> 
>> We can of course run these jdk8-based tests privately here but it would be nice if they could be used
>> to catch problems sooner.
>> 
>> What is your estimate as to when graal will support projects that require jdk8?
> 
> That depends entirely on the Eclipse effort mentioned above.
> 
> -Doug
> 
>> -----Original Message-----
>> From: sw.runtimes-bounces at mpdtxmail.amd.com [mailto:sw.runtimes-bounces at mpdtxmail.amd.com] On Behalf Of Doug Simon
>> Sent: Tuesday, July 09, 2013 4:23 AM
>> To: sw.runtimes
>> Cc: graal-dev at openjdk.java.net
>> Subject: Re: [Sw.runtimes] final graal HSAIL support patch
>> 
>> The integrated patch is now in the OpenJDK repo: http://hg.openjdk.java.net/graal/graal/rev/4ef92b67aeae
>> 
>> The HSAIL simulator page[1] should now be updated as a result. In particular, the command line for running the test is now:
>> 
>> mx --vm server unittest @-G:-RemoveNeverExecutedCode @-Dsun.boot.library.path=$LD_LIBRARY_PATH @-Xms1g @-Xmx1g @XX:-UseCompressedOops hsail.test.IntSquaredTest
>> 
>> -Doug
>> 
>> [1] https://wiki.openjdk.java.net/display/Sumatra/The+HSAIL+Simulator
>> 
>> On Jul 9, 2013, at 12:35 AM, "Venkatachalam, Vasanth" <Vasanth.Venkatachalam at amd.com> wrote:
>> 
>>> That HotspotGraalRuntime instance does not have to be public. We had made it public a while ago during some internal testing of the AMD64 backend, but I thought we had reverted it back in the patch I submitted. You can go ahead and make it private.
>>> 
>>> Vasanth
>>> 
>>> -----Original Message-----
>>> From: Christian Thalinger [mailto:christian.thalinger at oracle.com] 
>>> Sent: Monday, July 08, 2013 4:43 PM
>>> To: Venkatachalam, Vasanth
>>> Cc: sw.runtimes; graal-dev at openjdk.java.net
>>> Subject: Re: final graal HSAIL support patch
>>> 
>>> 
>>> On Jul 8, 2013, at 2:41 PM, Christian Thalinger <christian.thalinger at oracle.com> wrote:
>>> 
>>>> 
>>>> On Jun 28, 2013, at 1:28 PM, Christian Thalinger <christian.thalinger at oracle.com> wrote:
>>>> 
>>>>> 
>>>>> On Jun 26, 2013, at 3:00 PM, "Venkatachalam, Vasanth" <Vasanth.Venkatachalam at amd.com> 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/
>>>> 
>>>> Any comments on this patch?  If not, I'm going to push this today.
>>> 
>>> Oh, wait!  Actually I have a question:  why do you need this to be public?
>>> 
>>> --- old/graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/HotSpotGraalRuntime.java	2013-06-28 13:26:17.000000000 -0700
>>> +++ new/graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/HotSpotGraalRuntime.java	2013-06-28 13:26:17.000000000 -0700
>>> @@ -49,7 +49,7 @@
>>> */
>>> public abstract class HotSpotGraalRuntime implements GraalRuntime {
>>> 
>>> -    private static HotSpotGraalRuntime instance;
>>> +    public static HotSpotGraalRuntime instance;
>>> 
>>>   /**
>>>    * Gets the singleton {@link HotSpotGraalRuntime} object.
>>> 
>>> -- Chris
>>> 
>>>> 
>>>> -- 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" <Vasanth.Venkatachalam at amd.com> 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 <christian.thalinger at oracle.com> wrote:
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> On Jun 24, 2013, at 11:13 AM, Christian Thalinger <christian.thalinger at oracle.com> 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" <Vasanth.Venkatachalam at amd.com> 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
>>>>>> <graal.patch>
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> <graal.zip>
>>>>> 
>>>> 
>>> 
>>> 
>>> 
>> 
>> 
>> 
>> 
> 
> 
> 


From tom.deneau at amd.com  Fri Jul 12 16:26:57 2013
From: tom.deneau at amd.com (Deneau, Tom)
Date: Fri, 12 Jul 2013 23:26:57 +0000
Subject: patch for additional graal HSAIL backend functionality
In-Reply-To: <8B7AC96E-DA54-41FA-A371-4E63A4478B18@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>
	<F52F166A-DACB-4724-81D7-EA8D97B252E0@oracle.com>
	<5DD1503F815BD14889DC81D28643E3A73D90E619@sausexdag06.amd.com>
	<4D9C9697-3403-450E-AEF6-190FA35E145F@oracle.com>
	<3ACAB77C-2869-4D59-B224-AEE840F2E70B@oracle.com>
	<79BF6EED-6F10-4C1D-AA29-0D870F68B323@oracle.com>
	<5DD1503F815BD14889DC81D28643E3A73D9117CB@sausexdag06.amd.com>
	<1231D68C-1019-43A5-8D08-8CFCF48E4ED5@oracle.com>
	<BC97738F8E7C8742BABED7F06FB9DF9145039D0C@sausexdag01.amd.com>
	<67EC7C6A-3A6D-4A08-BED4-3779C5E26F04@oracle.com>
	<BC97738F8E7C8742BABED7F06FB9DF9145039D78@sausexdag01.amd.com>
	<8B7AC96E-DA54-41FA-A371-4E63A4478B18@oracle.com>
Message-ID: <BC97738F8E7C8742BABED7F06FB9DF914503A521@sausexdag01.amd.com>

Please review the following webrev.  This webrev adds some new
features to the HSAIL backend, which are listed below:

-- Tom

http://cr.openjdk.java.net/~tdeneau/graal-webrevs/graal-webrev-3.0/


* stackslot mapping was incorrect when combinations of 32-bit and
  64-bit stores were generated.  StackSlot alignment in
  HSAILTargetDescription set to 8.

* compressedOops support in various heap size configurations (with or
  without either of shift or heap base).  So we don't need
  XX:-UseCompressedOops anymore.

* some support for unsigned shifts, long shifts, logical ops for long
  datatype.

* a new GraalOption, InlineEverything.  Some HSAIL targets are not
  able to handle HSAIL function calls yet, plus we are still working
  on emitting HSAIL function calls in the compiler.

* hack for emitForeignCall special cases of createOutOfBoundsException
  or createNullPointerException.  (We just emit a comment.  Real
  exception handling still pending).  These nodes came about when we
  more aggressively inlined, although this has not been explained yet.

* support HSAILAddressValues as operands for arithmetic ops.  Use
  HSAIL lda instruction to get address into a register.  Used in
  particular for USHR for card-marking.

* Added some new junit tests. (some ported from their lambda versions)

   * StaticNBodyCallTest which would fail with default inlining (since
     we don't yet generate HSAIL calls).  It uses junit.assumeTrue and
     tests whether InlineEverything is set.  It (and also some
     lambda-based junit tests not part of this webrev) do pass nicely
     when InlineEverything is set true.

   * tests for storing an object, which test being able to handle the
     card-marking logic, as well as the encoding and decoding of a
     compressed oop.

   * some 2D matrix tests that showed a problem before the stackslot
     change above.  (have a mixture of 32-bit and 64-bit stackslot
     spills)



From miguelalfredo.garcia at epfl.ch  Sun Jul 14 13:59:33 2013
From: miguelalfredo.garcia at epfl.ch (Garcia Gutierrez Miguel Alfredo)
Date: Sun, 14 Jul 2013 20:59:33 +0000
Subject: two questions about ConditionalEliminationPhase
Message-ID: <7E4228B446372948BBB2916FC53FA49E26DDB815@rexma.intranet.epfl.ch>


After staring for what seemed like an eternity to ConditionalEliminationPhase, it slowly began to make sense. But not quite, as the questions below show.


/--------------------------\
|Question 1: Is this a bug?|
\--------------------------/

One of the cases that

  private void registerCondition(boolean isTrue, LogicNode condition, ValueNode anchor) {

handles is

  } else if (condition instanceof ObjectEqualsNode) {

where the consequences of the object-equality check are propagated.

In case of inequality, and one of the comparands known to be null, the code below gains information about the other comparand (ie, must be non-null). That's the idea, right?

                    if (state.isNull(x) && !state.isNonNull(y)) {
                        metricObjectEqualsRegistered.increment();
-------------->         state.addNullness(true, y);
                    } else if (!state.isNonNull(x) && state.isNull(y)) {
                        metricObjectEqualsRegistered.increment();
-------------->         state.addNullness(true, x);
                    }

However instead of recording non-nullness, the lines with an arrow above mark nullness. Looks to me it should read: `state.addNullness(false, ` etc. Comments are welcome to understand what's going on.



/----------------------------\
|Question 2: Could this work?|
\----------------------------/

I haven't looked into all phases, thus the suggestion below could be covered already. Let's see.

In:

  private void registerCondition(boolean isTrue, LogicNode condition, ValueNode anchor) {

three shapes of the condition are of interest (InstanceOfNode, IsNullNode, ObjectEqualsNode) because they allow trickling information from the whole condition down to its components.

Question: could LogicBinaryNode also be handled? For example,

  (a) a LogicConjunctionNode known to be true  allows establishing all its components to be true;
  (b) a LogicDisjunctionNode known to be false allows establishing all its components to be false;

(Not sure whether the extra precision pays off, my question is rather about whether that could be done in principle).



And now the kudos: Cool stuff!


Miguel


-- 
Miguel Garcia
Swiss Federal Institute of Technology
EPFL - IC - LAMP1 - INR 328 - Station 14
CH-1015 Lausanne - Switzerland
http://lamp.epfl.ch/~magarcia/


From s1255753 at sms.ed.ac.uk  Sun Jul 14 10:13:49 2013
From: s1255753 at sms.ed.ac.uk (ATKIN-GRANVILLE Chris)
Date: Sun, 14 Jul 2013 17:13:49 +0000
Subject: NullPointerException in HotSpotRuntime:lower when using Snippets
In-Reply-To: <C0C4D292-7403-474B-8602-A2CCC647AFB0@oracle.com>
References: <72C1FE55-E500-47DA-B5DE-831AB7119F3F@sms.ed.ac.uk>
	<1B56654D-BB65-423B-9558-96254F71132F@oracle.com>
	<4AD5DAB8-9F0B-44AD-9FD3-B007DADE45A8@sms.ed.ac.uk>
	<BB081FA8-D9FE-45CE-9D14-E6D648C46AB7@oracle.com>
	<D590922B-A5FB-459E-B58A-74C8D51C0369@sms.ed.ac.uk>
	<46BE599D-BAE6-47D6-A660-BBD8811FF6C3@oracle.com>
	<A89C1C43-8199-4DF8-A96E-9D79ADA898DD@sms.ed.ac.uk>
	<04453C30-7691-4C7C-8FE5-6FF636CE2711@oracle.com>
	<66066558-C469-4FF9-8C76-AFA6AC815238@oracle.com>
	<B1DF675D-1B38-4C48-9150-2D8BD34AE47A@sms.ed.ac.uk>
	<D3C3A49F-7A59-4604-8271-502EF7EA8739@oracle.com>
	<D6E7A5D4-4C33-4E5F-817B-121BC3F892B9@sms.ed.ac.uk>
	<D580B04A-5382-42AC-83FE-0D4590A35138@oracle.com>
	<F17781C1-D00A-4348-B817-6C259ECCE23F@sms.ed.ac.uk>
	<FB17EF9D-5C90-4CB3-B439-3F3E1F29EA16@oracle.com>
	<A3A6884D-4D69-4B57-B020-52942B89B0AF@sms.ed.ac.uk>
	<C2FD89C3-3353-4AD4-8C5D-6A4144F2BD2F@oracle.com>
	<A2419C2C-59CA-405C-BF2E-C21E0D3B19A2@sms.ed.ac.uk>
	<C0C4D292-7403-474B-8602-A2CCC647AFB0@oracle.com>
Message-ID: <06FF4162-C221-4742-8CD0-B56D86D1E723@sms.ed.ac.uk>


On 14 Jul 2013, at 17:10, Doug Simon <doug.simon at oracle.com> wrote:

> How important is it that your instrumentation achieves complete coverage? Do you need to see every single array access in the program? This will not be possible in the current GraalVM because it's hard to guarantee that execution always happens in compiled code. For this, you really need to do bytecode instrumentation.

We are only interested in array accesses that occur within loops (eventually we'll also extend to field accesses and so on, but for now we're sticking with arrays). Accesses that are not executed are unimportant as they pose no dependence risk.

Perhaps it would be possible use ASM or another bytecode manipulation library to add in transformations from InstalledCode.getCode(). Would it be possible to somehow load modified bytecode into Graal or something like that?

> Assuming the answer to the above is no, then you run into the issue of doing arbitrary instrumentation (as I've mentioned) with snippets. The underlying issue is that snippets need to essentially be atomic with respect to the runtime. Writing deopt free snippets is generally a trick task (as you've seen). We might be able improve this over time by techniques such as making the inlining for snippets for more aggressive, support annotations stating that certain field updates are not real side effects etc. However, none of this exists right now. 
> I'm cc'ing graal-dev in case there's some other way to achieve your goals within the current Graal system.
> 
> -Doug
> 
> On Jul 14, 2013, at 2:01 PM, ATKIN-GRANVILLE Chris <s1255753 at sms.ed.ac.uk> wrote:
> 
>> 
>> On 14 Jul 2013, at 10:52, Doug Simon <doug.simon at oracle.com>
>> wrote:
>> 
>>> 
>>> On Jul 14, 2013, at 3:59 AM, ATKIN-GRANVILLE Chris <s1255753 at sms.ed.ac.uk> wrote:
>>> 
>>>> I'm trying to work out what the code actually does, but the documentation (or rather, lack of) makes it difficult. To try and understand the code, I'm trying to modify it to include each dynamic access as a 'separate' item, rather than incrementing a counter.
>>> 
>>> That probably won't be possible in the current system. We can cheat in terms of pretending a counter update has no side effect but it's impossible to do the same for a dynamic resizable data structure (such as a list of accesses). I'm curious as to why a counter update doesn't give you all the information you need since your original prototype was not capturing anything specific about each dynamic access.
>> 
>> The problem is that we're trying to perform dependency analysis at run-time, not compile-time (i.e., dynamic analysis instead of static analysis). I'm not interested in getting a list of accesses per-se, but rather the ability to create arbitrary structures. The data that we're interested in is /both/ the information available at compile-time, and the specific run-time address (or equivalent) being written to.
>> 
>> Take for example a loop, the one I'm using to test:
>> 
>> public static int[] loopDependency(int[] a, int[] b) {
>> 	int[] c = new int[a.length];
>> 		
>> 	for (int i = 0; i < a.length; i++)
>> 		c[i] = a[b[i]];
>> 		
>> 	return c;
>> }
>> 
>> Assume a.length == b.length == 5 and the maximum value in each array is 4 but each value is unique.
>> 
>> The code at the moment produces this for the store associated with the c[i] = a[b[i]]:
>> 
>> 597|Write 596|IndexedLocation { stamp=Extension, valueKind=int, indexScaling=4, displacement=24, locationIdentity=Array: int,  } 4
>> 
>> (I switched it from working with StoreIndexedNode/LoadIndexedNode to WriteNode/ReadNode, but it's an easy change to turn it back)
>> 
>> The problem is that each time the write is 'triggered', I think there should be a different IndexedLocations associated with it (the indexScaling/displacement should change, right? It can't stay the same for all 4 writes).
>> 
>> If I switch back to StoreIndexedNode/LoadIndexedNode, I see that the location associated with the node (i.e., the index) is actually a PhiNode. I'd like to be able to "dereference" the value of the PhiNode - which can only be done at run-time. That's basically what we're trying to do - as well as build runtime data structures to compute dependency. Does that make sense?
>> 
>>> 
>>>> A couple of thoughts/questions:
>>>> 
>>>> 	- DirectObjectStoreNode, by not being a StateSplit is captured at all stack frames, kind-of like a global variable (or a static field, whatever). However, why do you not need to add it to the graph before using it (i.e., why are the methods static)?
>>> 
>>> You'll notice that those methods are annotated with @NodeIntrinsic. During snippet preparation, calls to such methods get turned into node instantiations. Look for all applications of the NodeIntrinsificationPhase. It's instructive to step through a node intrinsification with the debugger. Basically, each such method will (must!) match a constructor of the argument to the @NodeIntrinsic annotation.
>>> 
>>>> 	- The arguments to DirectObjectStoreNode.storeLong() are not documented. I understand that it stores arbitrary values at a "location specified as on offset relative to an object" (as per UnsafeStoreNode docs). But what is the difference between the offset and the displacement?
>>> 
>>> The displacement is byte sized and must be a compile-time constant (indicated by the @NodeConstantParameter annotation) where as an offset is a scaled runtime value. Look at the usage of DirectObjectStoreNode.storeObject() at UnsafeArrayCopySnippets.java:155.
>>> 
>>>> 	- An ArrayAccess is instantiated (and added to the appropriate group) once per static store instruction. @Snippet store()/@Snippet load() are however triggered/fired every time the location is accessed. How would I go about storing each access individually?
>>> 
>>> Like I said above, that is currently not possible.
>>> 
>>>> 	- Can I use this technique to build arbitrary data structures? At some point in the future, we may need to build some graphs at runtime (perhaps for dependency). Can I do that using a similar technique?
>>> 
>>> Once again, not from within a snippet itself.
>>> 
>>>> 	- My testing has shown me that although there should be e.g. 5 stores, only 4 will be recorded. For example, if I do a vector addition:
>>>> 
>>>> 		public static int[] vectorAddition(int[] a, int[] b) {
>>>> 			assert a.length == b.length;
>>>> 			int[] c = new int[a.length];
>>>> 
>>>> 			for (int i = 0; i > a.length; i++)
>>>> 				c[i] = a[i] + b[i];
>>>> 
>>>> 			return c;
>>>> 		}
>>>> 	
>>>> 	And then called this with two length n vectors, only n - 1 accesses will be recorded.
>>> 
>>> Maybe the first access happens in the interpreter? Remember, snippets are only used in compiled code. Also, partial escape analysis may convert array updates to nodes other than the one you've instrumented. The only way to know for sure is to look at the graphs in the IGV as well as at the generated code.
>>> 
>>> -Doug
>>> 
>>>> On 12 Jul 2013, at 09:08, Doug Simon <doug.simon at oracle.com> wrote:
>>>> 
>>>>> 
>>>>> On Jul 12, 2013, at 1:37 AM, ATKIN-GRANVILLE Chris <s1255753 at sms.ed.ac.uk> wrote:
>>>>> 
>>>>>> Sorry for the lateness of this email, I was moving today and away from a computer.
>>>>> 
>>>>> No worries.
>>>>> 
>>>>>> Thanks for sending me this code. I've done a quick splice of it into my codebase, and it looks like it does what I need it to. I am a little confused as to why there's fewer stores in the list than there are in the count (i.e., look below and there are 5 stores, yet 11 are counted) - I'll investigate that over the next few days.
>>>>> 
>>>>> There is one store in the list for each static store instruction along with a dynamic count for the executions of that instruction (the number after the ':'). If you add up those dynamic counts (which is all that I made the code do), you get the total shown.
>>>>> 
>>>>>> Either way, I'll be sure to give you appropriate credit in the final report and any papers that we write as a result of our work. I appreciate your help!
>>>>> 
>>>>> You're welcome. It's always interesting to see an outsider use the system and learn what we can improve for this kind of usage. It's particularly encouraging to see you did not have to modify an Graal code to make this work (even if some awkward hoops had to be jumped through).
>>>>> 
>>>>> -Doug
>>>>> 
>>>>>> 
>>>>>> On 10 Jul 2013, at 21:31, Doug Simon <doug.simon at oracle.com> wrote:
>>>>>> 
>>>>>>> I hacked up (and attached) something that should give you what you want.
>>>>>>> 
>>>>>>> $ mx vm -XX:-BootstrapGraal -cp locomotion/bin uk.ac.ed.inf.icsa.locomotion.Application
>>>>>>> [locomotion] using runtime=com.oracle.graal.hotspot.amd64.AMD64HotSpotRuntime
>>>>>>> [locomotion] parsing arrayAccess
>>>>>>> Array snippets
>>>>>>> [locomotion] compilation
>>>>>>> 55|StoreIndexed
>>>>>>> [locomotion] executing
>>>>>>> Loads: []
>>>>>>> Stores: [90|ArrayStoreBehaviour:1]
>>>>>>> 
>>>>>>> 
>>>>>>> Instrumentation Report
>>>>>>> -------------------------
>>>>>>> stores 1
>>>>>>> loads 1
>>>>>>> [locomotion] parsing loopDependency
>>>>>>> Array snippets
>>>>>>> [locomotion] compilation
>>>>>>> 247|StoreIndexed
>>>>>>> 247|StoreIndexed
>>>>>>> 441|StoreIndexed
>>>>>>> 441|StoreIndexed
>>>>>>> [locomotion] executing
>>>>>>> Loads: []
>>>>>>> Stores: [90|ArrayStoreBehaviour:1, 500|ArrayStoreBehaviour:1, 498|ArrayStoreBehaviour:1, 501|ArrayStoreBehaviour:4, 499|ArrayStoreBehaviour:4]
>>>>>>> 
>>>>>>> 
>>>>>>> Instrumentation Report
>>>>>>> -------------------------
>>>>>>> stores 11
>>>>>>> loads 11
>>>>>>> 
>>>>>>> 
>>>>>>> On Jul 10, 2013, at 9:19 PM, ATKIN-GRANVILLE Chris <s1255753 at sms.ed.ac.uk> wrote:
>>>>>>> 
>>>>>>>> Thanks for the code. I see I was pretty close but alas, no cigar.
>>>>>>>> 
>>>>>>>>> It helps to keep in mind that snippets are for lowering complex bytecodes, not (yet) for doing arbitrary instrumentation. Sorry for not making this clearer earlier.
>>>>>>>> 
>>>>>>>> This is a bit of a problem as what I'm trying to do is arbitrary instrumentation. What me + my supervisor are (trying to) do is create run-time traces of programs, and then perform dependency analysis in order to dynamically predict parallel loops. Is there  an appropriate mechanism for doing this in Graal currently? If this approach doesn't work, our next port-of-call was going to be to basically create our own WriteNode, copying the behaviour (we'd like to subclass but it's declared final!) except with the addition of calling our own instrumentation as well.
>>>>>>>> 
>>>>>>>> On 10 Jul 2013, at 19:33, Doug Simon <doug.simon at oracle.com>
>>>>>>>> wrote:
>>>>>>>> 
>>>>>>>>> Snippets must be deoptimization free. This is because there is no sensible place for the interpreter to continue should deoptimization occur. So, calling a method inside a snippet that won't be removed via inlining is not possible. In your case, the call to HashMap.put() resulting from inlining Instrument.addAddrLoad(s) cannot be inlined since the HashSet.map field is not final.
>>>>>>>>> 
>>>>>>>>> It helps to keep in mind that snippets are for lowering complex bytecodes, not (yet) for doing arbitrary instrumentation. Sorry for not making this clearer earlier.
>>>>>>>>> 
>>>>>>>>> In any case, I'm attaching a modified copy of your sources so you can at least see how to get the lowering done at the right time. One problem you had was that the ArrayInstrumentationPhase was being run after the LoweringPhase.
>>>>>>>>> 
>>>>>>>>> -Doug
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> On Jul 10, 2013, at 5:41 PM, ATKIN-GRANVILLE Chris <s1255753 at sms.ed.ac.uk> wrote:
>>>>>>>>> 
>>>>>>>>>> Do you mean instantiating the snippets in Lowerable.lower()? If so, I tried making ArrayBehaviourNode implement Lowerable, and then in ArrayStoreBehaviourNode.lower() doing new InstrumentationSnippets.Templates(runtime, replacements, target).lower(this); (runtime, replacements and target are accessed from public static fields of Application, initialized in Application.run()) and I get the same error as before.
>>>>>>>>>> 
>>>>>>>>>> On 10 Jul 2013, at 13:33, Doug Simon <doug.simon at oracle.com> wrote:
>>>>>>>>>> 
>>>>>>>>>>> The problem is that you are doing lowering externally from the LoweringPhase. Lowering is iterative as one lowering may introduce other Lowerable nodes. You need to make ArrayBehaviourNode implement Lowerable.
>>>>>>>>>>> 
>>>>>>>>>>> On Jul 10, 2013, at 8:25 AM, Doug Simon <doug.simon at oracle.com> wrote:
>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> On Jul 9, 2013, at 11:56 PM, ATKIN-GRANVILLE Chris <s1255753 at sms.ed.ac.uk> wrote:
>>>>>>>>>>>> 
>>>>>>>>>>>>> 
>>>>>>>>>>>>> On 8 Jul 2013, at 19:57, Doug Simon <doug.simon at oracle.com> wrote:
>>>>>>>>>>>>> 
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> On Jul 8, 2013, at 5:04 PM, ATKIN-GRANVILLE Chris <s1255753 at sms.ed.ac.uk> wrote:
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> I couldn't find a ReplacementsImpl.buildGraph() so I used ReplacementsImpl.GraphMaker.buildGraph() instead, specifically ReplacementsImpl.java:303.
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> Yes, sorry, that's the one I meant.
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> My snippet at the moment consists of a call to HashSet.add().
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> @Snippet
>>>>>>>>>>>>>>> public static void load(String s) {
>>>>>>>>>>>>>>> // call to add(s) on a public static Set (HashSet)
>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> Is the static field final? I think it will need to be. Also, this access to the HashSet sounds thread unsafe.
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> private final SnippetInfo load = snippet(InstrumentationSnippets.class, "load");
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> My lowering code looks like (in an inner class Templates extending AbstractTemplates):
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> public void lower(final ArrayLoadBehaviourNode node) {
>>>>>>>>>>>>>>> Arguments args = new Arguments(load);
>>>>>>>>>>>>>>> args.add("s", node.getInfoAsString());
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> template(args).instantiate(runtime, node, DEFAULT_REPLACER, args);
>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> My lowering code is called though a HIGH_LEVEL phase (via Suites) that scans through the graph:
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> for(Node n: graph.getNodes())
>>>>>>>>>>>>>>> if (n instanceof ArrayLoadBehaviourNode)
>>>>>>>>>>>>>>>     new InstrumentationSnippets.Templates(runtime, replacements, target).lower((ArrayLoadBehaviourNode) n);
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> Lowering should only be done from the LoweringPhase. That is, your ArrayLoadBehaviourNode needs to implement Lowerable.
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> I added a breakpoint to ReplacementsImpl.GraphMaker.pharseGraph() line 303 (return buildGraph(?)). I inspected every call at this point, checking this.this$1.method. There were no calls with dontInline = true or forceInline = true - i.e., they were all false. Is that what you meant?
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> Something like that. I was just trying to work out why the inlining is not happening.
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> It would really help if you send me a Mercurial bundle and a command line to reproduce your issue.
>>>>>>>>>>>>> 
>>>>>>>>>>>>> Sure thing. I'm using git for scm instead of hg though, so I've included a git bundle instead (if it's an issue, I can repackage with hg).
>>>>>>>>>>>> 
>>>>>>>>>>>> Yes, please repackage as a hg bundle as I don't know how to apply a git bundle to a hg repo.
>>>>>>>>>>>> 
>>>>>>>>>>>> -Doug
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> -- 
>>>>>>>>>> The University of Edinburgh is a charitable body, registered in
>>>>>>>>>> Scotland, with registration number SC005336.
>>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> <locomotion.tar.gz>
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>>> -- 
>>>>>>>> The University of Edinburgh is a charitable body, registered in
>>>>>>>> Scotland, with registration number SC005336.
>>>>>>>> 
>>>>>>> 
>>>>>>> <locomotion.tar.gz>
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> -- 
>>>>>> The University of Edinburgh is a charitable body, registered in
>>>>>> Scotland, with registration number SC005336.
>>>>>> 
>>>>> 
>>>>> 
>>>> 
>>>> 
>>>> 
>>>> -- 
>>>> The University of Edinburgh is a charitable body, registered in
>>>> Scotland, with registration number SC005336.
>>>> 
>>> 
>>> 
>> 
>> 
>> 
>> -- 
>> The University of Edinburgh is a charitable body, registered in
>> Scotland, with registration number SC005336.
>> 
> 
> 



-- 
The University of Edinburgh is a charitable body, registered in
Scotland, with registration number SC005336.


From doug.simon at oracle.com  Sun Jul 14 09:10:05 2013
From: doug.simon at oracle.com (Doug Simon)
Date: Sun, 14 Jul 2013 18:10:05 +0200
Subject: NullPointerException in HotSpotRuntime:lower when using Snippets
In-Reply-To: <A2419C2C-59CA-405C-BF2E-C21E0D3B19A2@sms.ed.ac.uk>
References: <72C1FE55-E500-47DA-B5DE-831AB7119F3F@sms.ed.ac.uk>
	<1B56654D-BB65-423B-9558-96254F71132F@oracle.com>
	<4AD5DAB8-9F0B-44AD-9FD3-B007DADE45A8@sms.ed.ac.uk>
	<BB081FA8-D9FE-45CE-9D14-E6D648C46AB7@oracle.com>
	<D590922B-A5FB-459E-B58A-74C8D51C0369@sms.ed.ac.uk>
	<46BE599D-BAE6-47D6-A660-BBD8811FF6C3@oracle.com>
	<A89C1C43-8199-4DF8-A96E-9D79ADA898DD@sms.ed.ac.uk>
	<04453C30-7691-4C7C-8FE5-6FF636CE2711@oracle.com>
	<66066558-C469-4FF9-8C76-AFA6AC815238@oracle.com>
	<B1DF675D-1B38-4C48-9150-2D8BD34AE47A@sms.ed.ac.uk>
	<D3C3A49F-7A59-4604-8271-502EF7EA8739@oracle.com>
	<D6E7A5D4-4C33-4E5F-817B-121BC3F892B9@sms.ed.ac.uk>
	<D580B04A-5382-42AC-83FE-0D4590A35138@oracle.com>
	<F17781C1-D00A-4348-B817-6C259ECCE23F@sms.ed.ac.uk>
	<FB17EF9D-5C90-4CB3-B439-3F3E1F29EA16@oracle.com>
	<A3A6884D-4D69-4B57-B020-52942B89B0AF@sms.ed.ac.uk>
	<C2FD89C3-3353-4AD4-8C5D-6A4144F2BD2F@oracle.com>
	<A2419C2C-59CA-405C-BF2E-C21E0D3B19A2@sms.ed.ac.uk>
Message-ID: <C0C4D292-7403-474B-8602-A2CCC647AFB0@oracle.com>

Ok, now that you stated what you are trying to achieve, it's easy to give better feedback ;-)

How important is it that your instrumentation achieves complete coverage? Do you need to see every single array access in the program? This will not be possible in the current GraalVM because it's hard to guarantee that execution always happens in compiled code. For this, you really need to do bytecode instrumentation.

Assuming the answer to the above is no, then you run into the issue of doing arbitrary instrumentation (as I've mentioned) with snippets. The underlying issue is that snippets need to essentially be atomic with respect to the runtime. Writing deopt free snippets is generally a trick task (as you've seen). We might be able improve this over time by techniques such as making the inlining for snippets for more aggressive, support annotations stating that certain field updates are not real side effects etc. However, none of this exists right now. 

I'm cc'ing graal-dev in case there's some other way to achieve your goals within the current Graal system.

-Doug

On Jul 14, 2013, at 2:01 PM, ATKIN-GRANVILLE Chris <s1255753 at sms.ed.ac.uk> wrote:

> 
> On 14 Jul 2013, at 10:52, Doug Simon <doug.simon at oracle.com>
> wrote:
> 
>> 
>> On Jul 14, 2013, at 3:59 AM, ATKIN-GRANVILLE Chris <s1255753 at sms.ed.ac.uk> wrote:
>> 
>>> I'm trying to work out what the code actually does, but the documentation (or rather, lack of) makes it difficult. To try and understand the code, I'm trying to modify it to include each dynamic access as a 'separate' item, rather than incrementing a counter.
>> 
>> That probably won't be possible in the current system. We can cheat in terms of pretending a counter update has no side effect but it's impossible to do the same for a dynamic resizable data structure (such as a list of accesses). I'm curious as to why a counter update doesn't give you all the information you need since your original prototype was not capturing anything specific about each dynamic access.
> 
> The problem is that we're trying to perform dependency analysis at run-time, not compile-time (i.e., dynamic analysis instead of static analysis). I'm not interested in getting a list of accesses per-se, but rather the ability to create arbitrary structures. The data that we're interested in is /both/ the information available at compile-time, and the specific run-time address (or equivalent) being written to.
> 
> Take for example a loop, the one I'm using to test:
> 
> public static int[] loopDependency(int[] a, int[] b) {
> 	int[] c = new int[a.length];
> 		
> 	for (int i = 0; i < a.length; i++)
> 		c[i] = a[b[i]];
> 		
> 	return c;
> }
> 
> Assume a.length == b.length == 5 and the maximum value in each array is 4 but each value is unique.
> 
> The code at the moment produces this for the store associated with the c[i] = a[b[i]]:
> 
> 597|Write 596|IndexedLocation { stamp=Extension, valueKind=int, indexScaling=4, displacement=24, locationIdentity=Array: int,  } 4
> 
> (I switched it from working with StoreIndexedNode/LoadIndexedNode to WriteNode/ReadNode, but it's an easy change to turn it back)
> 
> The problem is that each time the write is 'triggered', I think there should be a different IndexedLocations associated with it (the indexScaling/displacement should change, right? It can't stay the same for all 4 writes).
> 
> If I switch back to StoreIndexedNode/LoadIndexedNode, I see that the location associated with the node (i.e., the index) is actually a PhiNode. I'd like to be able to "dereference" the value of the PhiNode - which can only be done at run-time. That's basically what we're trying to do - as well as build runtime data structures to compute dependency. Does that make sense?
> 
>> 
>>> A couple of thoughts/questions:
>>> 
>>> 	- DirectObjectStoreNode, by not being a StateSplit is captured at all stack frames, kind-of like a global variable (or a static field, whatever). However, why do you not need to add it to the graph before using it (i.e., why are the methods static)?
>> 
>> You'll notice that those methods are annotated with @NodeIntrinsic. During snippet preparation, calls to such methods get turned into node instantiations. Look for all applications of the NodeIntrinsificationPhase. It's instructive to step through a node intrinsification with the debugger. Basically, each such method will (must!) match a constructor of the argument to the @NodeIntrinsic annotation.
>> 
>>> 	- The arguments to DirectObjectStoreNode.storeLong() are not documented. I understand that it stores arbitrary values at a "location specified as on offset relative to an object" (as per UnsafeStoreNode docs). But what is the difference between the offset and the displacement?
>> 
>> The displacement is byte sized and must be a compile-time constant (indicated by the @NodeConstantParameter annotation) where as an offset is a scaled runtime value. Look at the usage of DirectObjectStoreNode.storeObject() at UnsafeArrayCopySnippets.java:155.
>> 
>>> 	- An ArrayAccess is instantiated (and added to the appropriate group) once per static store instruction. @Snippet store()/@Snippet load() are however triggered/fired every time the location is accessed. How would I go about storing each access individually?
>> 
>> Like I said above, that is currently not possible.
>> 
>>> 	- Can I use this technique to build arbitrary data structures? At some point in the future, we may need to build some graphs at runtime (perhaps for dependency). Can I do that using a similar technique?
>> 
>> Once again, not from within a snippet itself.
>> 
>>> 	- My testing has shown me that although there should be e.g. 5 stores, only 4 will be recorded. For example, if I do a vector addition:
>>> 
>>> 		public static int[] vectorAddition(int[] a, int[] b) {
>>> 			assert a.length == b.length;
>>> 			int[] c = new int[a.length];
>>> 
>>> 			for (int i = 0; i > a.length; i++)
>>> 				c[i] = a[i] + b[i];
>>> 
>>> 			return c;
>>> 		}
>>> 	
>>> 	And then called this with two length n vectors, only n - 1 accesses will be recorded.
>> 
>> Maybe the first access happens in the interpreter? Remember, snippets are only used in compiled code. Also, partial escape analysis may convert array updates to nodes other than the one you've instrumented. The only way to know for sure is to look at the graphs in the IGV as well as at the generated code.
>> 
>> -Doug
>> 
>>> On 12 Jul 2013, at 09:08, Doug Simon <doug.simon at oracle.com> wrote:
>>> 
>>>> 
>>>> On Jul 12, 2013, at 1:37 AM, ATKIN-GRANVILLE Chris <s1255753 at sms.ed.ac.uk> wrote:
>>>> 
>>>>> Sorry for the lateness of this email, I was moving today and away from a computer.
>>>> 
>>>> No worries.
>>>> 
>>>>> Thanks for sending me this code. I've done a quick splice of it into my codebase, and it looks like it does what I need it to. I am a little confused as to why there's fewer stores in the list than there are in the count (i.e., look below and there are 5 stores, yet 11 are counted) - I'll investigate that over the next few days.
>>>> 
>>>> There is one store in the list for each static store instruction along with a dynamic count for the executions of that instruction (the number after the ':'). If you add up those dynamic counts (which is all that I made the code do), you get the total shown.
>>>> 
>>>>> Either way, I'll be sure to give you appropriate credit in the final report and any papers that we write as a result of our work. I appreciate your help!
>>>> 
>>>> You're welcome. It's always interesting to see an outsider use the system and learn what we can improve for this kind of usage. It's particularly encouraging to see you did not have to modify an Graal code to make this work (even if some awkward hoops had to be jumped through).
>>>> 
>>>> -Doug
>>>> 
>>>>> 
>>>>> On 10 Jul 2013, at 21:31, Doug Simon <doug.simon at oracle.com> wrote:
>>>>> 
>>>>>> I hacked up (and attached) something that should give you what you want.
>>>>>> 
>>>>>> $ mx vm -XX:-BootstrapGraal -cp locomotion/bin uk.ac.ed.inf.icsa.locomotion.Application
>>>>>> [locomotion] using runtime=com.oracle.graal.hotspot.amd64.AMD64HotSpotRuntime
>>>>>> [locomotion] parsing arrayAccess
>>>>>> Array snippets
>>>>>> [locomotion] compilation
>>>>>> 55|StoreIndexed
>>>>>> [locomotion] executing
>>>>>> Loads: []
>>>>>> Stores: [90|ArrayStoreBehaviour:1]
>>>>>> 
>>>>>> 
>>>>>> Instrumentation Report
>>>>>> -------------------------
>>>>>> stores 1
>>>>>> loads 1
>>>>>> [locomotion] parsing loopDependency
>>>>>> Array snippets
>>>>>> [locomotion] compilation
>>>>>> 247|StoreIndexed
>>>>>> 247|StoreIndexed
>>>>>> 441|StoreIndexed
>>>>>> 441|StoreIndexed
>>>>>> [locomotion] executing
>>>>>> Loads: []
>>>>>> Stores: [90|ArrayStoreBehaviour:1, 500|ArrayStoreBehaviour:1, 498|ArrayStoreBehaviour:1, 501|ArrayStoreBehaviour:4, 499|ArrayStoreBehaviour:4]
>>>>>> 
>>>>>> 
>>>>>> Instrumentation Report
>>>>>> -------------------------
>>>>>> stores 11
>>>>>> loads 11
>>>>>> 
>>>>>> 
>>>>>> On Jul 10, 2013, at 9:19 PM, ATKIN-GRANVILLE Chris <s1255753 at sms.ed.ac.uk> wrote:
>>>>>> 
>>>>>>> Thanks for the code. I see I was pretty close but alas, no cigar.
>>>>>>> 
>>>>>>>> It helps to keep in mind that snippets are for lowering complex bytecodes, not (yet) for doing arbitrary instrumentation. Sorry for not making this clearer earlier.
>>>>>>> 
>>>>>>> This is a bit of a problem as what I'm trying to do is arbitrary instrumentation. What me + my supervisor are (trying to) do is create run-time traces of programs, and then perform dependency analysis in order to dynamically predict parallel loops. Is there  an appropriate mechanism for doing this in Graal currently? If this approach doesn't work, our next port-of-call was going to be to basically create our own WriteNode, copying the behaviour (we'd like to subclass but it's declared final!) except with the addition of calling our own instrumentation as well.
>>>>>>> 
>>>>>>> On 10 Jul 2013, at 19:33, Doug Simon <doug.simon at oracle.com>
>>>>>>> wrote:
>>>>>>> 
>>>>>>>> Snippets must be deoptimization free. This is because there is no sensible place for the interpreter to continue should deoptimization occur. So, calling a method inside a snippet that won't be removed via inlining is not possible. In your case, the call to HashMap.put() resulting from inlining Instrument.addAddrLoad(s) cannot be inlined since the HashSet.map field is not final.
>>>>>>>> 
>>>>>>>> It helps to keep in mind that snippets are for lowering complex bytecodes, not (yet) for doing arbitrary instrumentation. Sorry for not making this clearer earlier.
>>>>>>>> 
>>>>>>>> In any case, I'm attaching a modified copy of your sources so you can at least see how to get the lowering done at the right time. One problem you had was that the ArrayInstrumentationPhase was being run after the LoweringPhase.
>>>>>>>> 
>>>>>>>> -Doug
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>>> On Jul 10, 2013, at 5:41 PM, ATKIN-GRANVILLE Chris <s1255753 at sms.ed.ac.uk> wrote:
>>>>>>>> 
>>>>>>>>> Do you mean instantiating the snippets in Lowerable.lower()? If so, I tried making ArrayBehaviourNode implement Lowerable, and then in ArrayStoreBehaviourNode.lower() doing new InstrumentationSnippets.Templates(runtime, replacements, target).lower(this); (runtime, replacements and target are accessed from public static fields of Application, initialized in Application.run()) and I get the same error as before.
>>>>>>>>> 
>>>>>>>>> On 10 Jul 2013, at 13:33, Doug Simon <doug.simon at oracle.com> wrote:
>>>>>>>>> 
>>>>>>>>>> The problem is that you are doing lowering externally from the LoweringPhase. Lowering is iterative as one lowering may introduce other Lowerable nodes. You need to make ArrayBehaviourNode implement Lowerable.
>>>>>>>>>> 
>>>>>>>>>> On Jul 10, 2013, at 8:25 AM, Doug Simon <doug.simon at oracle.com> wrote:
>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> On Jul 9, 2013, at 11:56 PM, ATKIN-GRANVILLE Chris <s1255753 at sms.ed.ac.uk> wrote:
>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> On 8 Jul 2013, at 19:57, Doug Simon <doug.simon at oracle.com> wrote:
>>>>>>>>>>>> 
>>>>>>>>>>>>> 
>>>>>>>>>>>>> On Jul 8, 2013, at 5:04 PM, ATKIN-GRANVILLE Chris <s1255753 at sms.ed.ac.uk> wrote:
>>>>>>>>>>>>> 
>>>>>>>>>>>>>> I couldn't find a ReplacementsImpl.buildGraph() so I used ReplacementsImpl.GraphMaker.buildGraph() instead, specifically ReplacementsImpl.java:303.
>>>>>>>>>>>>> 
>>>>>>>>>>>>> Yes, sorry, that's the one I meant.
>>>>>>>>>>>>> 
>>>>>>>>>>>>>> My snippet at the moment consists of a call to HashSet.add().
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> @Snippet
>>>>>>>>>>>>>> public static void load(String s) {
>>>>>>>>>>>>>> // call to add(s) on a public static Set (HashSet)
>>>>>>>>>>>>>> }
>>>>>>>>>>>>> 
>>>>>>>>>>>>> Is the static field final? I think it will need to be. Also, this access to the HashSet sounds thread unsafe.
>>>>>>>>>>>>> 
>>>>>>>>>>>>>> private final SnippetInfo load = snippet(InstrumentationSnippets.class, "load");
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> My lowering code looks like (in an inner class Templates extending AbstractTemplates):
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> public void lower(final ArrayLoadBehaviourNode node) {
>>>>>>>>>>>>>> Arguments args = new Arguments(load);
>>>>>>>>>>>>>> args.add("s", node.getInfoAsString());
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> template(args).instantiate(runtime, node, DEFAULT_REPLACER, args);
>>>>>>>>>>>>>> }
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> My lowering code is called though a HIGH_LEVEL phase (via Suites) that scans through the graph:
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> for(Node n: graph.getNodes())
>>>>>>>>>>>>>> if (n instanceof ArrayLoadBehaviourNode)
>>>>>>>>>>>>>>      new InstrumentationSnippets.Templates(runtime, replacements, target).lower((ArrayLoadBehaviourNode) n);
>>>>>>>>>>>>> 
>>>>>>>>>>>>> Lowering should only be done from the LoweringPhase. That is, your ArrayLoadBehaviourNode needs to implement Lowerable.
>>>>>>>>>>>>> 
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> I added a breakpoint to ReplacementsImpl.GraphMaker.pharseGraph() line 303 (return buildGraph(?)). I inspected every call at this point, checking this.this$1.method. There were no calls with dontInline = true or forceInline = true - i.e., they were all false. Is that what you meant?
>>>>>>>>>>>>> 
>>>>>>>>>>>>> Something like that. I was just trying to work out why the inlining is not happening.
>>>>>>>>>>>>> 
>>>>>>>>>>>>> It would really help if you send me a Mercurial bundle and a command line to reproduce your issue.
>>>>>>>>>>>> 
>>>>>>>>>>>> Sure thing. I'm using git for scm instead of hg though, so I've included a git bundle instead (if it's an issue, I can repackage with hg).
>>>>>>>>>>> 
>>>>>>>>>>> Yes, please repackage as a hg bundle as I don't know how to apply a git bundle to a hg repo.
>>>>>>>>>>> 
>>>>>>>>>>> -Doug
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> -- 
>>>>>>>>> The University of Edinburgh is a charitable body, registered in
>>>>>>>>> Scotland, with registration number SC005336.
>>>>>>>>> 
>>>>>>>> 
>>>>>>>> <locomotion.tar.gz>
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> -- 
>>>>>>> The University of Edinburgh is a charitable body, registered in
>>>>>>> Scotland, with registration number SC005336.
>>>>>>> 
>>>>>> 
>>>>>> <locomotion.tar.gz>
>>>>> 
>>>>> 
>>>>> 
>>>>> -- 
>>>>> The University of Edinburgh is a charitable body, registered in
>>>>> Scotland, with registration number SC005336.
>>>>> 
>>>> 
>>>> 
>>> 
>>> 
>>> 
>>> -- 
>>> The University of Edinburgh is a charitable body, registered in
>>> Scotland, with registration number SC005336.
>>> 
>> 
>> 
> 
> 
> 
> -- 
> The University of Edinburgh is a charitable body, registered in
> Scotland, with registration number SC005336.
> 


From doug.simon at oracle.com  Sun Jul 14 11:29:40 2013
From: doug.simon at oracle.com (Doug Simon)
Date: Sun, 14 Jul 2013 20:29:40 +0200
Subject: NullPointerException in HotSpotRuntime:lower when using Snippets
In-Reply-To: <06FF4162-C221-4742-8CD0-B56D86D1E723@sms.ed.ac.uk>
References: <72C1FE55-E500-47DA-B5DE-831AB7119F3F@sms.ed.ac.uk>
	<1B56654D-BB65-423B-9558-96254F71132F@oracle.com>
	<4AD5DAB8-9F0B-44AD-9FD3-B007DADE45A8@sms.ed.ac.uk>
	<BB081FA8-D9FE-45CE-9D14-E6D648C46AB7@oracle.com>
	<D590922B-A5FB-459E-B58A-74C8D51C0369@sms.ed.ac.uk>
	<46BE599D-BAE6-47D6-A660-BBD8811FF6C3@oracle.com>
	<A89C1C43-8199-4DF8-A96E-9D79ADA898DD@sms.ed.ac.uk>
	<04453C30-7691-4C7C-8FE5-6FF636CE2711@oracle.com>
	<66066558-C469-4FF9-8C76-AFA6AC815238@oracle.com>
	<B1DF675D-1B38-4C48-9150-2D8BD34AE47A@sms.ed.ac.uk>
	<D3C3A49F-7A59-4604-8271-502EF7EA8739@oracle.com>
	<D6E7A5D4-4C33-4E5F-817B-121BC3F892B9@sms.ed.ac.uk>
	<D580B04A-5382-42AC-83FE-0D4590A35138@oracle.com>
	<F17781C1-D00A-4348-B817-6C259ECCE23F@sms.ed.ac.uk>
	<FB17EF9D-5C90-4CB3-B439-3F3E1F29EA16@oracle.com>
	<A3A6884D-4D69-4B57-B020-52942B89B0AF@sms.ed.ac.uk>
	<C2FD89C3-3353-4AD4-8C5D-6A4144F2BD2F@oracle.com>
	<A2419C2C-59CA-405C-BF2E-C21E0D3B19A2@sms.ed.ac.uk>
	<C0C4D292-7403-474B-8602-A2CCC647AFB0@oracle.com> <06FF4162!
	-C221-4742-8CD0-B56D86D1E723@sms.ed.ac.uk>
Message-ID: <696D4214-ED8F-4255-BBEF-ADB0D7908C86@oracle.com>


On Jul 14, 2013, at 7:13 PM, ATKIN-GRANVILLE Chris <s1255753 at sms.ed.ac.uk> wrote:

> 
> On 14 Jul 2013, at 17:10, Doug Simon <doug.simon at oracle.com> wrote:
> 
>> How important is it that your instrumentation achieves complete coverage? Do you need to see every single array access in the program? This will not be possible in the current GraalVM because it's hard to guarantee that execution always happens in compiled code. For this, you really need to do bytecode instrumentation.
> 
> We are only interested in array accesses that occur within loops (eventually we'll also extend to field accesses and so on, but for now we're sticking with arrays). Accesses that are not executed are unimportant as they pose no dependence risk.

Array accesses can happen in the interpreter which will not be subject to any Graal-based instrumentation.

> Perhaps it would be possible use ASM or another bytecode manipulation library to add in transformations from InstalledCode.getCode(). Would it be possible to somehow load modified bytecode into Graal or something like that?

If you are going to use bytecode instrumentation, then you should by-pass Graal altogether. Just use the existing instrumentation API[1]. This will also ensure you catch all dynamic accesses you are interested in whether they are executed in the interpreter or by compiled code.

-Doug

[1] http://docs.oracle.com/javase/6/docs/api/java/lang/instrument/package-summary.html

> 
>> Assuming the answer to the above is no, then you run into the issue of doing arbitrary instrumentation (as I've mentioned) with snippets. The underlying issue is that snippets need to essentially be atomic with respect to the runtime. Writing deopt free snippets is generally a trick task (as you've seen). We might be able improve this over time by techniques such as making the inlining for snippets for more aggressive, support annotations stating that certain field updates are not real side effects etc. However, none of this exists right now. 
>> I'm cc'ing graal-dev in case there's some other way to achieve your goals within the current Graal system.
>> 
>> -Doug
>> 
>> On Jul 14, 2013, at 2:01 PM, ATKIN-GRANVILLE Chris <s1255753 at sms.ed.ac.uk> wrote:
>> 
>>> 
>>> On 14 Jul 2013, at 10:52, Doug Simon <doug.simon at oracle.com>
>>> wrote:
>>> 
>>>> 
>>>> On Jul 14, 2013, at 3:59 AM, ATKIN-GRANVILLE Chris <s1255753 at sms.ed.ac.uk> wrote:
>>>> 
>>>>> I'm trying to work out what the code actually does, but the documentation (or rather, lack of) makes it difficult. To try and understand the code, I'm trying to modify it to include each dynamic access as a 'separate' item, rather than incrementing a counter.
>>>> 
>>>> That probably won't be possible in the current system. We can cheat in terms of pretending a counter update has no side effect but it's impossible to do the same for a dynamic resizable data structure (such as a list of accesses). I'm curious as to why a counter update doesn't give you all the information you need since your original prototype was not capturing anything specific about each dynamic access.
>>> 
>>> The problem is that we're trying to perform dependency analysis at run-time, not compile-time (i.e., dynamic analysis instead of static analysis). I'm not interested in getting a list of accesses per-se, but rather the ability to create arbitrary structures. The data that we're interested in is /both/ the information available at compile-time, and the specific run-time address (or equivalent) being written to.
>>> 
>>> Take for example a loop, the one I'm using to test:
>>> 
>>> public static int[] loopDependency(int[] a, int[] b) {
>>> 	int[] c = new int[a.length];
>>> 		
>>> 	for (int i = 0; i < a.length; i++)
>>> 		c[i] = a[b[i]];
>>> 		
>>> 	return c;
>>> }
>>> 
>>> Assume a.length == b.length == 5 and the maximum value in each array is 4 but each value is unique.
>>> 
>>> The code at the moment produces this for the store associated with the c[i] = a[b[i]]:
>>> 
>>> 597|Write 596|IndexedLocation { stamp=Extension, valueKind=int, indexScaling=4, displacement=24, locationIdentity=Array: int,  } 4
>>> 
>>> (I switched it from working with StoreIndexedNode/LoadIndexedNode to WriteNode/ReadNode, but it's an easy change to turn it back)
>>> 
>>> The problem is that each time the write is 'triggered', I think there should be a different IndexedLocations associated with it (the indexScaling/displacement should change, right? It can't stay the same for all 4 writes).
>>> 
>>> If I switch back to StoreIndexedNode/LoadIndexedNode, I see that the location associated with the node (i.e., the index) is actually a PhiNode. I'd like to be able to "dereference" the value of the PhiNode - which can only be done at run-time. That's basically what we're trying to do - as well as build runtime data structures to compute dependency. Does that make sense?
>>> 
>>>> 
>>>>> A couple of thoughts/questions:
>>>>> 
>>>>> 	- DirectObjectStoreNode, by not being a StateSplit is captured at all stack frames, kind-of like a global variable (or a static field, whatever). However, why do you not need to add it to the graph before using it (i.e., why are the methods static)?
>>>> 
>>>> You'll notice that those methods are annotated with @NodeIntrinsic. During snippet preparation, calls to such methods get turned into node instantiations. Look for all applications of the NodeIntrinsificationPhase. It's instructive to step through a node intrinsification with the debugger. Basically, each such method will (must!) match a constructor of the argument to the @NodeIntrinsic annotation.
>>>> 
>>>>> 	- The arguments to DirectObjectStoreNode.storeLong() are not documented. I understand that it stores arbitrary values at a "location specified as on offset relative to an object" (as per UnsafeStoreNode docs). But what is the difference between the offset and the displacement?
>>>> 
>>>> The displacement is byte sized and must be a compile-time constant (indicated by the @NodeConstantParameter annotation) where as an offset is a scaled runtime value. Look at the usage of DirectObjectStoreNode.storeObject() at UnsafeArrayCopySnippets.java:155.
>>>> 
>>>>> 	- An ArrayAccess is instantiated (and added to the appropriate group) once per static store instruction. @Snippet store()/@Snippet load() are however triggered/fired every time the location is accessed. How would I go about storing each access individually?
>>>> 
>>>> Like I said above, that is currently not possible.
>>>> 
>>>>> 	- Can I use this technique to build arbitrary data structures? At some point in the future, we may need to build some graphs at runtime (perhaps for dependency). Can I do that using a similar technique?
>>>> 
>>>> Once again, not from within a snippet itself.
>>>> 
>>>>> 	- My testing has shown me that although there should be e.g. 5 stores, only 4 will be recorded. For example, if I do a vector addition:
>>>>> 
>>>>> 		public static int[] vectorAddition(int[] a, int[] b) {
>>>>> 			assert a.length == b.length;
>>>>> 			int[] c = new int[a.length];
>>>>> 
>>>>> 			for (int i = 0; i > a.length; i++)
>>>>> 				c[i] = a[i] + b[i];
>>>>> 
>>>>> 			return c;
>>>>> 		}
>>>>> 	
>>>>> 	And then called this with two length n vectors, only n - 1 accesses will be recorded.
>>>> 
>>>> Maybe the first access happens in the interpreter? Remember, snippets are only used in compiled code. Also, partial escape analysis may convert array updates to nodes other than the one you've instrumented. The only way to know for sure is to look at the graphs in the IGV as well as at the generated code.
>>>> 
>>>> -Doug
>>>> 
>>>>> On 12 Jul 2013, at 09:08, Doug Simon <doug.simon at oracle.com> wrote:
>>>>> 
>>>>>> 
>>>>>> On Jul 12, 2013, at 1:37 AM, ATKIN-GRANVILLE Chris <s1255753 at sms.ed.ac.uk> wrote:
>>>>>> 
>>>>>>> Sorry for the lateness of this email, I was moving today and away from a computer.
>>>>>> 
>>>>>> No worries.
>>>>>> 
>>>>>>> Thanks for sending me this code. I've done a quick splice of it into my codebase, and it looks like it does what I need it to. I am a little confused as to why there's fewer stores in the list than there are in the count (i.e., look below and there are 5 stores, yet 11 are counted) - I'll investigate that over the next few days.
>>>>>> 
>>>>>> There is one store in the list for each static store instruction along with a dynamic count for the executions of that instruction (the number after the ':'). If you add up those dynamic counts (which is all that I made the code do), you get the total shown.
>>>>>> 
>>>>>>> Either way, I'll be sure to give you appropriate credit in the final report and any papers that we write as a result of our work. I appreciate your help!
>>>>>> 
>>>>>> You're welcome. It's always interesting to see an outsider use the system and learn what we can improve for this kind of usage. It's particularly encouraging to see you did not have to modify an Graal code to make this work (even if some awkward hoops had to be jumped through).
>>>>>> 
>>>>>> -Doug
>>>>>> 
>>>>>>> 
>>>>>>> On 10 Jul 2013, at 21:31, Doug Simon <doug.simon at oracle.com> wrote:
>>>>>>> 
>>>>>>>> I hacked up (and attached) something that should give you what you want.
>>>>>>>> 
>>>>>>>> $ mx vm -XX:-BootstrapGraal -cp locomotion/bin uk.ac.ed.inf.icsa.locomotion.Application
>>>>>>>> [locomotion] using runtime=com.oracle.graal.hotspot.amd64.AMD64HotSpotRuntime
>>>>>>>> [locomotion] parsing arrayAccess
>>>>>>>> Array snippets
>>>>>>>> [locomotion] compilation
>>>>>>>> 55|StoreIndexed
>>>>>>>> [locomotion] executing
>>>>>>>> Loads: []
>>>>>>>> Stores: [90|ArrayStoreBehaviour:1]
>>>>>>>> 
>>>>>>>> 
>>>>>>>> Instrumentation Report
>>>>>>>> -------------------------
>>>>>>>> stores 1
>>>>>>>> loads 1
>>>>>>>> [locomotion] parsing loopDependency
>>>>>>>> Array snippets
>>>>>>>> [locomotion] compilation
>>>>>>>> 247|StoreIndexed
>>>>>>>> 247|StoreIndexed
>>>>>>>> 441|StoreIndexed
>>>>>>>> 441|StoreIndexed
>>>>>>>> [locomotion] executing
>>>>>>>> Loads: []
>>>>>>>> Stores: [90|ArrayStoreBehaviour:1, 500|ArrayStoreBehaviour:1, 498|ArrayStoreBehaviour:1, 501|ArrayStoreBehaviour:4, 499|ArrayStoreBehaviour:4]
>>>>>>>> 
>>>>>>>> 
>>>>>>>> Instrumentation Report
>>>>>>>> -------------------------
>>>>>>>> stores 11
>>>>>>>> loads 11
>>>>>>>> 
>>>>>>>> 
>>>>>>>> On Jul 10, 2013, at 9:19 PM, ATKIN-GRANVILLE Chris <s1255753 at sms.ed.ac.uk> wrote:
>>>>>>>> 
>>>>>>>>> Thanks for the code. I see I was pretty close but alas, no cigar.
>>>>>>>>> 
>>>>>>>>>> It helps to keep in mind that snippets are for lowering complex bytecodes, not (yet) for doing arbitrary instrumentation. Sorry for not making this clearer earlier.
>>>>>>>>> 
>>>>>>>>> This is a bit of a problem as what I'm trying to do is arbitrary instrumentation. What me + my supervisor are (trying to) do is create run-time traces of programs, and then perform dependency analysis in order to dynamically predict parallel loops. Is there  an appropriate mechanism for doing this in Graal currently? If this approach doesn't work, our next port-of-call was going to be to basically create our own WriteNode, copying the behaviour (we'd like to subclass but it's declared final!) except with the addition of calling our own instrumentation as well.
>>>>>>>>> 
>>>>>>>>> On 10 Jul 2013, at 19:33, Doug Simon <doug.simon at oracle.com>
>>>>>>>>> wrote:
>>>>>>>>> 
>>>>>>>>>> Snippets must be deoptimization free. This is because there is no sensible place for the interpreter to continue should deoptimization occur. So, calling a method inside a snippet that won't be removed via inlining is not possible. In your case, the call to HashMap.put() resulting from inlining Instrument.addAddrLoad(s) cannot be inlined since the HashSet.map field is not final.
>>>>>>>>>> 
>>>>>>>>>> It helps to keep in mind that snippets are for lowering complex bytecodes, not (yet) for doing arbitrary instrumentation. Sorry for not making this clearer earlier.
>>>>>>>>>> 
>>>>>>>>>> In any case, I'm attaching a modified copy of your sources so you can at least see how to get the lowering done at the right time. One problem you had was that the ArrayInstrumentationPhase was being run after the LoweringPhase.
>>>>>>>>>> 
>>>>>>>>>> -Doug
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> On Jul 10, 2013, at 5:41 PM, ATKIN-GRANVILLE Chris <s1255753 at sms.ed.ac.uk> wrote:
>>>>>>>>>> 
>>>>>>>>>>> Do you mean instantiating the snippets in Lowerable.lower()? If so, I tried making ArrayBehaviourNode implement Lowerable, and then in ArrayStoreBehaviourNode.lower() doing new InstrumentationSnippets.Templates(runtime, replacements, target).lower(this); (runtime, replacements and target are accessed from public static fields of Application, initialized in Application.run()) and I get the same error as before.
>>>>>>>>>>> 
>>>>>>>>>>> On 10 Jul 2013, at 13:33, Doug Simon <doug.simon at oracle.com> wrote:
>>>>>>>>>>> 
>>>>>>>>>>>> The problem is that you are doing lowering externally from the LoweringPhase. Lowering is iterative as one lowering may introduce other Lowerable nodes. You need to make ArrayBehaviourNode implement Lowerable.
>>>>>>>>>>>> 
>>>>>>>>>>>> On Jul 10, 2013, at 8:25 AM, Doug Simon <doug.simon at oracle.com> wrote:
>>>>>>>>>>>> 
>>>>>>>>>>>>> 
>>>>>>>>>>>>> On Jul 9, 2013, at 11:56 PM, ATKIN-GRANVILLE Chris <s1255753 at sms.ed.ac.uk> wrote:
>>>>>>>>>>>>> 
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> On 8 Jul 2013, at 19:57, Doug Simon <doug.simon at oracle.com> wrote:
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> On Jul 8, 2013, at 5:04 PM, ATKIN-GRANVILLE Chris <s1255753 at sms.ed.ac.uk> wrote:
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> I couldn't find a ReplacementsImpl.buildGraph() so I used ReplacementsImpl.GraphMaker.buildGraph() instead, specifically ReplacementsImpl.java:303.
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> Yes, sorry, that's the one I meant.
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> My snippet at the moment consists of a call to HashSet.add().
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> @Snippet
>>>>>>>>>>>>>>>> public static void load(String s) {
>>>>>>>>>>>>>>>> // call to add(s) on a public static Set (HashSet)
>>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> Is the static field final? I think it will need to be. Also, this access to the HashSet sounds thread unsafe.
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> private final SnippetInfo load = snippet(InstrumentationSnippets.class, "load");
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> My lowering code looks like (in an inner class Templates extending AbstractTemplates):
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> public void lower(final ArrayLoadBehaviourNode node) {
>>>>>>>>>>>>>>>> Arguments args = new Arguments(load);
>>>>>>>>>>>>>>>> args.add("s", node.getInfoAsString());
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> template(args).instantiate(runtime, node, DEFAULT_REPLACER, args);
>>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> My lowering code is called though a HIGH_LEVEL phase (via Suites) that scans through the graph:
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> for(Node n: graph.getNodes())
>>>>>>>>>>>>>>>> if (n instanceof ArrayLoadBehaviourNode)
>>>>>>>>>>>>>>>>    new InstrumentationSnippets.Templates(runtime, replacements, target).lower((ArrayLoadBehaviourNode) n);
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> Lowering should only be done from the LoweringPhase. That is, your ArrayLoadBehaviourNode needs to implement Lowerable.
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> I added a breakpoint to ReplacementsImpl.GraphMaker.pharseGraph() line 303 (return buildGraph(?)). I inspected every call at this point, checking this.this$1.method. There were no calls with dontInline = true or forceInline = true - i.e., they were all false. Is that what you meant?
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> Something like that. I was just trying to work out why the inlining is not happening.
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> It would really help if you send me a Mercurial bundle and a command line to reproduce your issue.
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> Sure thing. I'm using git for scm instead of hg though, so I've included a git bundle instead (if it's an issue, I can repackage with hg).
>>>>>>>>>>>>> 
>>>>>>>>>>>>> Yes, please repackage as a hg bundle as I don't know how to apply a git bundle to a hg repo.
>>>>>>>>>>>>> 
>>>>>>>>>>>>> -Doug
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> -- 
>>>>>>>>>>> The University of Edinburgh is a charitable body, registered in
>>>>>>>>>>> Scotland, with registration number SC005336.
>>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> <locomotion.tar.gz>
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> -- 
>>>>>>>>> The University of Edinburgh is a charitable body, registered in
>>>>>>>>> Scotland, with registration number SC005336.
>>>>>>>>> 
>>>>>>>> 
>>>>>>>> <locomotion.tar.gz>
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> -- 
>>>>>>> The University of Edinburgh is a charitable body, registered in
>>>>>>> Scotland, with registration number SC005336.
>>>>>>> 
>>>>>> 
>>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> -- 
>>>>> The University of Edinburgh is a charitable body, registered in
>>>>> Scotland, with registration number SC005336.
>>>>> 
>>>> 
>>>> 
>>> 
>>> 
>>> 
>>> -- 
>>> The University of Edinburgh is a charitable body, registered in
>>> Scotland, with registration number SC005336.
>>> 
>> 
>> 
> 
> 
> 
> -- 
> The University of Edinburgh is a charitable body, registered in
> Scotland, with registration number SC005336.
> 


From doug.simon at oracle.com  Mon Jul 15 02:17:08 2013
From: doug.simon at oracle.com (Doug Simon)
Date: Mon, 15 Jul 2013 11:17:08 +0200
Subject: patch for additional graal HSAIL backend functionality
In-Reply-To: <BC97738F8E7C8742BABED7F06FB9DF914503A521@sausexdag01.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>
	<F52F166A-DACB-4724-81D7-EA8D97B252E0@oracle.com>
	<5DD1503F815BD14889DC81D28643E3A73D90E619@sausexdag06.amd.com>
	<4D9C9697-3403-450E-AEF6-190FA35E145F@oracle.com>
	<3ACAB77C-2869-4D59-B224-AEE840F2E70B@oracle.com>
	<79BF6EED-6F10-4C1D-AA29-0D870F68B323@oracle.com>
	<5DD1503F815BD14889DC81D28643E3A73D9117CB@sausexdag06.amd.com>
	<1231D68C-1019-43A5-8D08-8CFCF48E4ED5@oracle.com>
	<BC97738F8E7C8742BABED7F06FB9DF9145039D0C@sausexdag01.amd.com>
	<67EC7C6A-3A6D-4A08-BED4-3779C5E26F04@oracle.com>
	<BC97738F8E7C8742BABED7F06FB9DF9145039D78@sausexdag01.amd.com>
	<8B7AC96E-DA54-41FA-A371-4E63A4478B18@oracle.com>
	<BC97738F8E7C8742BABED7F06FB9DF914503A521@sausexdag01.amd.com>
Message-ID: <8671FB33-4084-44C6-BB9A-C6B42C2FFBC1@oracle.com>

- this patch contains Eclipse errors (2) and warnings (13)
- ForeignCallNoOp0 -> ForeignCallNoArgOp
- ForeignCallNoOp1 -> ForeignCall1ArgOp

To save turn around time, I can simply make these fixes as part of my integration.

I also noticed for the first time that the c.o.graal.compiler.hsail project depends on c.o.graal.hotspot.amd64. The dependencies and structure for the HSAIL backend should more closely follow that for the AMD64 backend. The HSAILLIRGenerator class should be in the c.o.graal.lir.hsail project and there should be a HSAILHotSpotLIRGenerator subclass in a c.o.graal.hotspot.hsail project. Only the latter should introduce any HotSpot dependencies. I'm happy to make these refactoring if want.

-Doug

On Jul 13, 2013, at 1:26 AM, "Deneau, Tom" <tom.deneau at amd.com> wrote:

> Please review the following webrev.  This webrev adds some new
> features to the HSAIL backend, which are listed below:
> 
> -- Tom
> 
> http://cr.openjdk.java.net/~tdeneau/graal-webrevs/graal-webrev-3.0/
> 
> 
> * stackslot mapping was incorrect when combinations of 32-bit and
>  64-bit stores were generated.  StackSlot alignment in
>  HSAILTargetDescription set to 8.
> 
> * compressedOops support in various heap size configurations (with or
>  without either of shift or heap base).  So we don't need
>  XX:-UseCompressedOops anymore.
> 
> * some support for unsigned shifts, long shifts, logical ops for long
>  datatype.
> 
> * a new GraalOption, InlineEverything.  Some HSAIL targets are not
>  able to handle HSAIL function calls yet, plus we are still working
>  on emitting HSAIL function calls in the compiler.
> 
> * hack for emitForeignCall special cases of createOutOfBoundsException
>  or createNullPointerException.  (We just emit a comment.  Real
>  exception handling still pending).  These nodes came about when we
>  more aggressively inlined, although this has not been explained yet.
> 
> * support HSAILAddressValues as operands for arithmetic ops.  Use
>  HSAIL lda instruction to get address into a register.  Used in
>  particular for USHR for card-marking.
> 
> * Added some new junit tests. (some ported from their lambda versions)
> 
>   * StaticNBodyCallTest which would fail with default inlining (since
>     we don't yet generate HSAIL calls).  It uses junit.assumeTrue and
>     tests whether InlineEverything is set.  It (and also some
>     lambda-based junit tests not part of this webrev) do pass nicely
>     when InlineEverything is set true.
> 
>   * tests for storing an object, which test being able to handle the
>     card-marking logic, as well as the encoding and decoding of a
>     compressed oop.
> 
>   * some 2D matrix tests that showed a problem before the stackslot
>     change above.  (have a mixture of 32-bit and 64-bit stackslot
>     spills)
> 
> 


From lukas.stadler at jku.at  Mon Jul 15 04:26:25 2013
From: lukas.stadler at jku.at (Lukas Stadler)
Date: Mon, 15 Jul 2013 13:26:25 +0200
Subject: two questions about ConditionalEliminationPhase
In-Reply-To: <7E4228B446372948BBB2916FC53FA49E26DDB815@rexma.intranet.epfl.ch>
References: <7E4228B446372948BBB2916FC53FA49E26DDB815@rexma.intranet.epfl.ch>
Message-ID: <76B194B6-952B-4429-BF87-702AF9D248EF@jku.at>

Hey Miguel,

you're absolutely right, this is a bug. The information added to the state needs to specify that the value is non-null (false).

Your suggestion about the LogicCon/DisjunctionNodes makes sense - and it's not something that is handled by the current system.
(The conditions are picked up by conditional elimination only in later stages, when the node is lowered into control flow - which is too late)

However, we recently had lots of discussions about this phase, and it is scheduled for a major refactoring.
The problem is that this nullness state does not, at the moment, tell you where the information is coming from.
Without this it is hard/impossible to handle all cases around guards correctly (which is why the nullness is not used for guards any more?).

Thanks for the suggestion! I'll add it to the list of things to do while refactoring.

cheers,
 Lukas

On Jul 14, 2013, at 10:59 PM, Garcia Gutierrez Miguel Alfredo <miguelalfredo.garcia at epfl.ch> wrote:

> 
> After staring for what seemed like an eternity to ConditionalEliminationPhase, it slowly began to make sense. But not quite, as the questions below show.
> 
> 
> /--------------------------\
> |Question 1: Is this a bug?|
> \--------------------------/
> 
> One of the cases that
> 
>  private void registerCondition(boolean isTrue, LogicNode condition, ValueNode anchor) {
> 
> handles is
> 
>  } else if (condition instanceof ObjectEqualsNode) {
> 
> where the consequences of the object-equality check are propagated.
> 
> In case of inequality, and one of the comparands known to be null, the code below gains information about the other comparand (ie, must be non-null). That's the idea, right?
> 
>                    if (state.isNull(x) && !state.isNonNull(y)) {
>                        metricObjectEqualsRegistered.increment();
> -------------->         state.addNullness(true, y);
>                    } else if (!state.isNonNull(x) && state.isNull(y)) {
>                        metricObjectEqualsRegistered.increment();
> -------------->         state.addNullness(true, x);
>                    }
> 
> However instead of recording non-nullness, the lines with an arrow above mark nullness. Looks to me it should read: `state.addNullness(false, ` etc. Comments are welcome to understand what's going on.
> 
> 
> 
> /----------------------------\
> |Question 2: Could this work?|
> \----------------------------/
> 
> I haven't looked into all phases, thus the suggestion below could be covered already. Let's see.
> 
> In:
> 
>  private void registerCondition(boolean isTrue, LogicNode condition, ValueNode anchor) {
> 
> three shapes of the condition are of interest (InstanceOfNode, IsNullNode, ObjectEqualsNode) because they allow trickling information from the whole condition down to its components.
> 
> Question: could LogicBinaryNode also be handled? For example,
> 
>  (a) a LogicConjunctionNode known to be true  allows establishing all its components to be true;
>  (b) a LogicDisjunctionNode known to be false allows establishing all its components to be false;
> 
> (Not sure whether the extra precision pays off, my question is rather about whether that could be done in principle).
> 
> 
> 
> And now the kudos: Cool stuff!
> 
> 
> Miguel
> 
> 
> -- 
> Miguel Garcia
> Swiss Federal Institute of Technology
> EPFL - IC - LAMP1 - INR 328 - Station 14
> CH-1015 Lausanne - Switzerland
> http://lamp.epfl.ch/~magarcia/
> 


From tom.deneau at amd.com  Mon Jul 15 05:38:43 2013
From: tom.deneau at amd.com (Deneau, Tom)
Date: Mon, 15 Jul 2013 12:38:43 +0000
Subject: patch for additional graal HSAIL backend functionality
In-Reply-To: <8671FB33-4084-44C6-BB9A-C6B42C2FFBC1@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>
	<F52F166A-DACB-4724-81D7-EA8D97B252E0@oracle.com>
	<5DD1503F815BD14889DC81D28643E3A73D90E619@sausexdag06.amd.com>
	<4D9C9697-3403-450E-AEF6-190FA35E145F@oracle.com>
	<3ACAB77C-2869-4D59-B224-AEE840F2E70B@oracle.com>
	<79BF6EED-6F10-4C1D-AA29-0D870F68B323@oracle.com>
	<5DD1503F815BD14889DC81D28643E3A73D9117CB@sausexdag06.amd.com>
	<1231D68C-1019-43A5-8D08-8CFCF48E4ED5@oracle.com>
	<BC97738F8E7C8742BABED7F06FB9DF9145039D0C@sausexdag01.amd.com>
	<67EC7C6A-3A6D-4A08-BED4-3779C5E26F04@oracle.com>
	<BC97738F8E7C8742BABED7F06FB9DF9145039D78@sausexdag01.amd.com>
	<8B7AC96E-DA54-41FA-A371-4E63A4478B18@oracle.com>
	<BC97738F8E7C8742BABED7F06FB9DF914503A521@sausexdag01.amd.com>
	<8671FB33-4084-44C6-BB9A-C6B42C2FFBC1@oracle.com>
Message-ID: <BC97738F8E7C8742BABED7F06FB9DF914504304E@sausexdag01.amd.com>

Doug --

Yes, go ahead and make those fixes as part of your integration.
With regards to the HSAILLIRGenerator, did you mean to say that the HSAILLIRGenerator should be in co.graal.compiler.hsail
(like it is now) and there should be a new HSAILHotSpotLIRGenerator class in c.o.graal.hotspot.hsail?
For the original layout, I think Vasanth followed the way PTX was laid out

Sorry for the eclipse errors I realize now I forgot to specify the JDT compiler on the mx command line.

-- Tom

$ find graal -print | grep LIRGenerator.java
graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/gen/LIRGenerator.java
graal/com.oracle.graal.hotspot.sparc/src/com/oracle/graal/hotspot/sparc/SPARCHotSpotLIRGenerator.java
graal/com.oracle.graal.hotspot.amd64/src/com/oracle/graal/hotspot/amd64/AMD64HotSpotLIRGenerator.java
graal/com.oracle.graal.compiler.ptx/src/com/oracle/graal/compiler/ptx/PTXLIRGenerator.java
graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/HotSpotLIRGenerator.java
graal/com.oracle.graal.compiler.amd64/src/com/oracle/graal/compiler/amd64/AMD64LIRGenerator.java
graal/com.oracle.graal.compiler.sparc/src/com/oracle/graal/compiler/sparc/SPARCLIRGenerator.java
graal/com.oracle.graal.compiler.hsail/src/com/oracle/graal/compiler/hsail/HSAILLIRGenerator.java

-----Original Message-----
From: Doug Simon [mailto:doug.simon at oracle.com] 
Sent: Monday, July 15, 2013 4:17 AM
To: Deneau, Tom
Cc: graal-dev at openjdk.java.net
Subject: Re: patch for additional graal HSAIL backend functionality

- this patch contains Eclipse errors (2) and warnings (13)
- ForeignCallNoOp0 -> ForeignCallNoArgOp
- ForeignCallNoOp1 -> ForeignCall1ArgOp

To save turn around time, I can simply make these fixes as part of my integration.

I also noticed for the first time that the c.o.graal.compiler.hsail project depends on c.o.graal.hotspot.amd64. The dependencies and structure for the HSAIL backend should more closely follow that for the AMD64 backend. The HSAILLIRGenerator class should be in the c.o.graal.lir.hsail project and there should be a HSAILHotSpotLIRGenerator subclass in a c.o.graal.hotspot.hsail project. Only the latter should introduce any HotSpot dependencies. I'm happy to make these refactoring if want.

-Doug

On Jul 13, 2013, at 1:26 AM, "Deneau, Tom" <tom.deneau at amd.com> wrote:

> Please review the following webrev.  This webrev adds some new
> features to the HSAIL backend, which are listed below:
> 
> -- Tom
> 
> http://cr.openjdk.java.net/~tdeneau/graal-webrevs/graal-webrev-3.0/
> 
> 
> * stackslot mapping was incorrect when combinations of 32-bit and
>  64-bit stores were generated.  StackSlot alignment in
>  HSAILTargetDescription set to 8.
> 
> * compressedOops support in various heap size configurations (with or
>  without either of shift or heap base).  So we don't need
>  XX:-UseCompressedOops anymore.
> 
> * some support for unsigned shifts, long shifts, logical ops for long
>  datatype.
> 
> * a new GraalOption, InlineEverything.  Some HSAIL targets are not
>  able to handle HSAIL function calls yet, plus we are still working
>  on emitting HSAIL function calls in the compiler.
> 
> * hack for emitForeignCall special cases of createOutOfBoundsException
>  or createNullPointerException.  (We just emit a comment.  Real
>  exception handling still pending).  These nodes came about when we
>  more aggressively inlined, although this has not been explained yet.
> 
> * support HSAILAddressValues as operands for arithmetic ops.  Use
>  HSAIL lda instruction to get address into a register.  Used in
>  particular for USHR for card-marking.
> 
> * Added some new junit tests. (some ported from their lambda versions)
> 
>   * StaticNBodyCallTest which would fail with default inlining (since
>     we don't yet generate HSAIL calls).  It uses junit.assumeTrue and
>     tests whether InlineEverything is set.  It (and also some
>     lambda-based junit tests not part of this webrev) do pass nicely
>     when InlineEverything is set true.
> 
>   * tests for storing an object, which test being able to handle the
>     card-marking logic, as well as the encoding and decoding of a
>     compressed oop.
> 
>   * some 2D matrix tests that showed a problem before the stackslot
>     change above.  (have a mixture of 32-bit and 64-bit stackslot
>     spills)
> 
> 




From doug.simon at oracle.com  Mon Jul 15 09:10:21 2013
From: doug.simon at oracle.com (Doug Simon)
Date: Mon, 15 Jul 2013 18:10:21 +0200
Subject: patch for additional graal HSAIL backend functionality
In-Reply-To: <BC97738F8E7C8742BABED7F06FB9DF914504304E@sausexdag01.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>
	<F52F166A-DACB-4724-81D7-EA8D97B252E0@oracle.com>
	<5DD1503F815BD14889DC81D28643E3A73D90E619@sausexdag06.amd.com>
	<4D9C9697-3403-450E-AEF6-190FA35E145F@oracle.com>
	<3ACAB77C-2869-4D59-B224-AEE840F2E70B@oracle.com>
	<79BF6EED-6F10-4C1D-AA29-0D870F68B323@oracle.com>
	<5DD1503F815BD14889DC81D28643E3A73D9117CB@sausexdag06.amd.com>
	<1231D68C-1019-43A5-8D08-8CFCF48E4ED5@oracle.com>
	<BC97738F8E7C8742BABED7F06FB9DF9145039D0C@sausexdag01.amd.com>
	<67EC7C6A-3A6D-4A08-BED4-3779C5E26F04@oracle.com>
	<BC97738F8E7C8742BABED7F06FB9DF9145039D78@sausexdag01.amd.com>
	<8B7AC96E-DA54-41FA-A371-4E63A4478B18@oracle.com>
	<BC97738F8E7C8742BABED7F06FB9DF914503A521@sausexdag01.amd.com>
	<8671FB33-4084-44C6-BB9A-C6B42C2FFBC! 1@oracle.com>
	<BC97738F8E7C8742BABED7F06FB9DF914504304E@sausexdag01.amd.com>
Message-ID: <18FCE83C-7E6E-465F-962F-819CEAA07F8E@oracle.com>


On Jul 15, 2013, at 2:38 PM, "Deneau, Tom" <tom.deneau at amd.com> wrote:

> Doug --
> 
> Yes, go ahead and make those fixes as part of your integration.
> With regards to the HSAILLIRGenerator, did you mean to say that the HSAILLIRGenerator should be in co.graal.compiler.hsail
> (like it is now) and there should be a new HSAILHotSpotLIRGenerator class in c.o.graal.hotspot.hsail?

Yes. However, I've realized that doing the proposed refactoring right now is a little premature given that Graal doesn't yet have proper support for multiple, configurable backends.

> For the original layout, I think Vasanth followed the way PTX was laid out

Ok, makes sense.

> Sorry for the eclipse errors I realize now I forgot to specify the JDT compiler on the mx command line.

You're not using Eclipse?! ;-)

-Doug

> $ find graal -print | grep LIRGenerator.java
> graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/gen/LIRGenerator.java
> graal/com.oracle.graal.hotspot.sparc/src/com/oracle/graal/hotspot/sparc/SPARCHotSpotLIRGenerator.java
> graal/com.oracle.graal.hotspot.amd64/src/com/oracle/graal/hotspot/amd64/AMD64HotSpotLIRGenerator.java
> graal/com.oracle.graal.compiler.ptx/src/com/oracle/graal/compiler/ptx/PTXLIRGenerator.java
> graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/HotSpotLIRGenerator.java
> graal/com.oracle.graal.compiler.amd64/src/com/oracle/graal/compiler/amd64/AMD64LIRGenerator.java
> graal/com.oracle.graal.compiler.sparc/src/com/oracle/graal/compiler/sparc/SPARCLIRGenerator.java
> graal/com.oracle.graal.compiler.hsail/src/com/oracle/graal/compiler/hsail/HSAILLIRGenerator.java
> 
> -----Original Message-----
> From: Doug Simon [mailto:doug.simon at oracle.com] 
> Sent: Monday, July 15, 2013 4:17 AM
> To: Deneau, Tom
> Cc: graal-dev at openjdk.java.net
> Subject: Re: patch for additional graal HSAIL backend functionality
> 
> - this patch contains Eclipse errors (2) and warnings (13)
> - ForeignCallNoOp0 -> ForeignCallNoArgOp
> - ForeignCallNoOp1 -> ForeignCall1ArgOp
> 
> To save turn around time, I can simply make these fixes as part of my integration.
> 
> I also noticed for the first time that the c.o.graal.compiler.hsail project depends on c.o.graal.hotspot.amd64. The dependencies and structure for the HSAIL backend should more closely follow that for the AMD64 backend. The HSAILLIRGenerator class should be in the c.o.graal.lir.hsail project and there should be a HSAILHotSpotLIRGenerator subclass in a c.o.graal.hotspot.hsail project. Only the latter should introduce any HotSpot dependencies. I'm happy to make these refactoring if want.
> 
> -Doug
> 
> On Jul 13, 2013, at 1:26 AM, "Deneau, Tom" <tom.deneau at amd.com> wrote:
> 
>> Please review the following webrev.  This webrev adds some new
>> features to the HSAIL backend, which are listed below:
>> 
>> -- Tom
>> 
>> http://cr.openjdk.java.net/~tdeneau/graal-webrevs/graal-webrev-3.0/
>> 
>> 
>> * stackslot mapping was incorrect when combinations of 32-bit and
>> 64-bit stores were generated.  StackSlot alignment in
>> HSAILTargetDescription set to 8.
>> 
>> * compressedOops support in various heap size configurations (with or
>> without either of shift or heap base).  So we don't need
>> XX:-UseCompressedOops anymore.
>> 
>> * some support for unsigned shifts, long shifts, logical ops for long
>> datatype.
>> 
>> * a new GraalOption, InlineEverything.  Some HSAIL targets are not
>> able to handle HSAIL function calls yet, plus we are still working
>> on emitting HSAIL function calls in the compiler.
>> 
>> * hack for emitForeignCall special cases of createOutOfBoundsException
>> or createNullPointerException.  (We just emit a comment.  Real
>> exception handling still pending).  These nodes came about when we
>> more aggressively inlined, although this has not been explained yet.
>> 
>> * support HSAILAddressValues as operands for arithmetic ops.  Use
>> HSAIL lda instruction to get address into a register.  Used in
>> particular for USHR for card-marking.
>> 
>> * Added some new junit tests. (some ported from their lambda versions)
>> 
>>  * StaticNBodyCallTest which would fail with default inlining (since
>>    we don't yet generate HSAIL calls).  It uses junit.assumeTrue and
>>    tests whether InlineEverything is set.  It (and also some
>>    lambda-based junit tests not part of this webrev) do pass nicely
>>    when InlineEverything is set true.
>> 
>>  * tests for storing an object, which test being able to handle the
>>    card-marking logic, as well as the encoding and decoding of a
>>    compressed oop.
>> 
>>  * some 2D matrix tests that showed a problem before the stackslot
>>    change above.  (have a mixture of 32-bit and 64-bit stackslot
>>    spills)
>> 
>> 
> 
> 
> 


From doug.simon at oracle.com  Mon Jul 15 09:55:40 2013
From: doug.simon at oracle.com (doug.simon at oracle.com)
Date: Mon, 15 Jul 2013 16:55:40 +0000
Subject: hg: graal/graal: 107 new changesets
Message-ID: <20130715170157.A77A4480BF@hg.openjdk.java.net>

Changeset: 204d8d4f91a4
Author:    Christian Haeubl <haeubl at ssw.jku.at>
Date:      2013-07-09 11:18 +0200
URL:       http://hg.openjdk.java.net/graal/graal/rev/204d8d4f91a4

Minor Java fix.

! graal/com.oracle.graal.api.code/src/com/oracle/graal/api/code/Assumptions.java

Changeset: a9b76e1e5ab3
Author:    Christian Haeubl <haeubl at ssw.jku.at>
Date:      2013-07-09 11:19 +0200
URL:       http://hg.openjdk.java.net/graal/graal/rev/a9b76e1e5ab3

Fix for OSR regression introduced with 88672775a26c.

! src/share/vm/runtime/compilationPolicy.cpp

Changeset: dcee58529a1c
Author:    Christian Haeubl <haeubl at ssw.jku.at>
Date:      2013-07-09 11:21 +0200
URL:       http://hg.openjdk.java.net/graal/graal/rev/dcee58529a1c

Merge.

- graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/nodes/HotSpotNmethodExecuteNode.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/HotSpotNmethodSubstitutions.java

Changeset: 9808158cfeab
Author:    Roland Schatz <roland.schatz at oracle.com>
Date:      2013-07-09 11:14 +0200
URL:       http://hg.openjdk.java.net/graal/graal/rev/9808158cfeab

Allow foreign call stubs to be declared as leaf methods.

! graal/com.oracle.graal.hotspot.amd64/src/com/oracle/graal/hotspot/amd64/AMD64HotSpotBackend.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/ForeignCallStub.java
! graal/com.oracle.graal.lir.amd64/src/com/oracle/graal/lir/amd64/AMD64SaveRegistersOp.java

Changeset: 5348b49b2a76
Author:    Roland Schatz <roland.schatz at oracle.com>
Date:      2013-07-09 11:57 +0200
URL:       http://hg.openjdk.java.net/graal/graal/rev/5348b49b2a76

Assign framestates in snippet lowering after framestate assignment.

! graal/com.oracle.graal.replacements/src/com/oracle/graal/replacements/SnippetTemplate.java

Changeset: 110444cbf1eb
Author:    Roland Schatz <roland.schatz at oracle.com>
Date:      2013-07-09 11:58 +0200
URL:       http://hg.openjdk.java.net/graal/graal/rev/110444cbf1eb

Make FixedGuardNode a DeoptimizingNode.

! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/FixedGuardNode.java

Changeset: f11cd00d4115
Author:    Roland Schatz <roland.schatz at oracle.com>
Date:      2013-07-09 11:58 +0200
URL:       http://hg.openjdk.java.net/graal/graal/rev/f11cd00d4115

Make G1PreWriteBarrier a DeoptimizingNode.

! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/phases/WriteBarrierAdditionPhase.java
! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/WriteBarrierSnippets.java
! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/G1PreWriteBarrier.java

Changeset: 5bab3272bb82
Author:    Roland Schatz <roland.schatz at oracle.com>
Date:      2013-07-09 11:58 +0200
URL:       http://hg.openjdk.java.net/graal/graal/rev/5bab3272bb82

Make array allocations deoptimizing nodes.

! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/java/AbstractNewArrayNode.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

Changeset: 69089865435a
Author:    Roland Schatz <roland.schatz at oracle.com>
Date:      2013-07-09 11:58 +0200
URL:       http://hg.openjdk.java.net/graal/graal/rev/69089865435a

New lowering phase after framestate assignment.

! 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.nodes/src/com/oracle/graal/nodes/WriteBarrier.java
! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/spi/Lowerable.java

Changeset: e7d07c9bb779
Author:    Christian Haeubl <haeubl at ssw.jku.at>
Date:      2013-07-09 17:53 +0200
URL:       http://hg.openjdk.java.net/graal/graal/rev/e7d07c9bb779

Removed priority compilation queue.
Fixed another race condition in the compilation queue.
Removed Graal-specific compilation policy.

! 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/CompilerThread.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.phases/src/com/oracle/graal/phases/GraalOptions.java
! src/cpu/x86/vm/templateInterpreter_x86_64.cpp
! src/share/vm/classfile/vmSymbols.hpp
! src/share/vm/graal/graalCompiler.cpp
! src/share/vm/graal/graalVMToCompiler.cpp
! src/share/vm/graal/graalVMToCompiler.hpp
! src/share/vm/oops/methodCounters.cpp
! src/share/vm/oops/methodCounters.hpp
! src/share/vm/runtime/compilationPolicy.cpp

Changeset: d59e7f94f28d
Author:    Christian Haeubl <haeubl at ssw.jku.at>
Date:      2013-07-09 17:54 +0200
URL:       http://hg.openjdk.java.net/graal/graal/rev/d59e7f94f28d

Increased priority for compiler threads.

! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/CompilerThread.java

Changeset: 853a894e0d97
Author:    Christian Haeubl <haeubl at ssw.jku.at>
Date:      2013-07-09 17:55 +0200
URL:       http://hg.openjdk.java.net/graal/graal/rev/853a894e0d97

Merge.


Changeset: 41362ec88331
Author:    Thomas Wuerthinger <thomas.wuerthinger at oracle.com>
Date:      2013-07-09 14:33 +0200
URL:       http://hg.openjdk.java.net/graal/graal/rev/41362ec88331

Improve Truffle graph cache.

! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/PartialEvaluator.java
! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/TruffleCache.java

Changeset: 9db1377b0580
Author:    Thomas Wuerthinger <thomas.wuerthinger at oracle.com>
Date:      2013-07-09 17:38 +0200
URL:       http://hg.openjdk.java.net/graal/graal/rev/9db1377b0580

Fix for TruffleCache.

! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/PartialEvaluator.java
! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/TruffleCache.java
! graal/com.oracle.truffle.api/src/com/oracle/truffle/api/TruffleOptions.java
! graal/com.oracle.truffle.api/src/com/oracle/truffle/api/nodes/SlowPathException.java

Changeset: 3bbe14e492fb
Author:    Thomas Wuerthinger <thomas.wuerthinger at oracle.com>
Date:      2013-07-09 20:06 +0200
URL:       http://hg.openjdk.java.net/graal/graal/rev/3bbe14e492fb

Introduce TruffleGraphMaxNodes option with default value 10000.

! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/PartialEvaluator.java
! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/TruffleCompilerOptions.java

Changeset: 759415ed915a
Author:    Thomas Wuerthinger <thomas.wuerthinger at oracle.com>
Date:      2013-07-09 20:09 +0200
URL:       http://hg.openjdk.java.net/graal/graal/rev/759415ed915a

Merge.


Changeset: fa86a653bc0d
Author:    Andreas Woess <andreas.woess at jku.at>
Date:      2013-07-09 19:45 +0200
URL:       http://hg.openjdk.java.net/graal/graal/rev/fa86a653bc0d

Truffle: ensure frame assumption is recorded for materialized frames

! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/nodes/FrameAccessNode.java

Changeset: 0c570e82cc1d
Author:    Andreas Woess <andreas.woess at jku.at>
Date:      2013-07-09 21:03 +0200
URL:       http://hg.openjdk.java.net/graal/graal/rev/0c570e82cc1d

Truffle: minor cleanup

! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/FrameWithoutBoxing.java
! graal/com.oracle.truffle.api/src/com/oracle/truffle/api/impl/DefaultVirtualFrame.java

Changeset: 311abd52ffeb
Author:    Andreas Woess <andreas.woess at jku.at>
Date:      2013-07-09 21:20 +0200
URL:       http://hg.openjdk.java.net/graal/graal/rev/311abd52ffeb

Merge


Changeset: 725922588833
Author:    Thomas Wuerthinger <thomas.wuerthinger at oracle.com>
Date:      2013-07-09 21:53 +0200
URL:       http://hg.openjdk.java.net/graal/graal/rev/725922588833

Fix Truffle cache inlining strategy to skip exception edges.

! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/TruffleCache.java
! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/TruffleCompilerOptions.java

Changeset: ae4c79ee71d1
Author:    Thomas Wuerthinger <thomas.wuerthinger at oracle.com>
Date:      2013-07-09 22:05 +0200
URL:       http://hg.openjdk.java.net/graal/graal/rev/ae4c79ee71d1

Merge.


Changeset: 6ff467cdb105
Author:    twisti
Date:      2013-07-09 14:39 -0700
URL:       http://hg.openjdk.java.net/graal/graal/rev/6ff467cdb105

Code installer changes for SPARC.

! src/cpu/sparc/vm/graalCodeInstaller_sparc.hpp
! src/cpu/sparc/vm/sharedRuntime_sparc.cpp
! src/cpu/x86/vm/graalCodeInstaller_x86.hpp
! src/share/vm/graal/graalCodeInstaller.cpp
! src/share/vm/graal/graalCodeInstaller.hpp
! src/share/vm/prims/methodHandles.cpp

Changeset: 431eca622358
Author:    twisti
Date:      2013-07-09 15:37 -0700
URL:       http://hg.openjdk.java.net/graal/graal/rev/431eca622358

SPARC: Fixed build errors.

! src/share/vm/graal/graalCompilerToGPU.cpp
! src/share/vm/graal/graalCompilerToVM.hpp

Changeset: 73122b5edf6a
Author:    twisti
Date:      2013-07-09 15:37 -0700
URL:       http://hg.openjdk.java.net/graal/graal/rev/73122b5edf6a

SPARC: Can compile simple methods and do static calls.

! 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.asm.sparc/src/com/oracle/graal/asm/sparc/SPARCMacroAssembler.java
! graal/com.oracle.graal.compiler.sparc/src/com/oracle/graal/compiler/sparc/SPARCLIRGenerator.java
! graal/com.oracle.graal.hotspot.sparc/src/com/oracle/graal/hotspot/sparc/SPARCHotSpotBackend.java
! graal/com.oracle.graal.hotspot.sparc/src/com/oracle/graal/hotspot/sparc/SPARCHotSpotLIRGenerator.java
! graal/com.oracle.graal.hotspot.sparc/src/com/oracle/graal/hotspot/sparc/SPARCHotSpotRegisterConfig.java
+ graal/com.oracle.graal.hotspot.sparc/src/com/oracle/graal/hotspot/sparc/SPARCHotspotDirectStaticCallOp.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/SPARCCall.java
! graal/com.oracle.graal.lir.sparc/src/com/oracle/graal/lir/sparc/SPARCCompare.java
! graal/com.oracle.graal.lir.sparc/src/com/oracle/graal/lir/sparc/SPARCControlFlow.java
! graal/com.oracle.graal.lir.sparc/src/com/oracle/graal/lir/sparc/SPARCLIRInstruction.java
! graal/com.oracle.graal.lir.sparc/src/com/oracle/graal/lir/sparc/SPARCMathIntrinsicOp.java
! graal/com.oracle.graal.lir.sparc/src/com/oracle/graal/lir/sparc/SPARCMove.java
! graal/com.oracle.graal.lir.sparc/src/com/oracle/graal/lir/sparc/SPARCTestOp.java
! graal/com.oracle.graal.sparc/src/com/oracle/graal/sparc/SPARC.java

Changeset: d2055a110396
Author:    Thomas Wuerthinger <thomas.wuerthinger at oracle.com>
Date:      2013-07-10 05:26 +0200
URL:       http://hg.openjdk.java.net/graal/graal/rev/d2055a110396

Introduce CompilerDirectives.SlowPath annotation.

! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/TruffleCache.java
! graal/com.oracle.truffle.api/src/com/oracle/truffle/api/CompilerDirectives.java

Changeset: 87d2df0a7624
Author:    Thomas Wuerthinger <thomas.wuerthinger at oracle.com>
Date:      2013-07-10 05:27 +0200
URL:       http://hg.openjdk.java.net/graal/graal/rev/87d2df0a7624

Merge.


Changeset: 3ae117e62905
Author:    Christian Humer <christian.humer at gmail.com>
Date:      2013-07-10 09:23 +0200
URL:       http://hg.openjdk.java.net/graal/graal/rev/3ae117e62905

Removed frame argument for generic cases if not needed.
Added @SlowPath annotation to generated generic cases.

! graal/com.oracle.truffle.dsl.processor/src/com/oracle/truffle/dsl/processor/TruffleTypes.java
! graal/com.oracle.truffle.dsl.processor/src/com/oracle/truffle/dsl/processor/node/NodeCodeGenerator.java
! graal/com.oracle.truffle.dsl.processor/src/com/oracle/truffle/dsl/processor/node/NodeParser.java

Changeset: a0309f88306c
Author:    Christian Humer <christian.humer at gmail.com>
Date:      2013-07-10 09:42 +0200
URL:       http://hg.openjdk.java.net/graal/graal/rev/a0309f88306c

Added truffle option to enable detailed rewrite messages. Disabled by default.

! graal/com.oracle.truffle.api/src/com/oracle/truffle/api/TruffleOptions.java
! graal/com.oracle.truffle.dsl.processor/src/com/oracle/truffle/dsl/processor/TruffleTypes.java
! graal/com.oracle.truffle.dsl.processor/src/com/oracle/truffle/dsl/processor/node/NodeCodeGenerator.java

Changeset: 77b83e903703
Author:    Doug Simon <doug.simon at oracle.com>
Date:      2013-07-10 17:44 +0200
URL:       http://hg.openjdk.java.net/graal/graal/rev/77b83e903703

make use of guardingNonNull node intrinsic

! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/ArrayCopySnippets.java

Changeset: bebc9672f45e
Author:    Doug Simon <doug.simon at oracle.com>
Date:      2013-07-10 17:46 +0200
URL:       http://hg.openjdk.java.net/graal/graal/rev/bebc9672f45e

stamp for GuardingPiNode is determined by caller of constructor, not within constructor

! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/GuardingPiNode.java
! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/InliningUtil.java

Changeset: f8adf47cc05e
Author:    Doug Simon <doug.simon at oracle.com>
Date:      2013-07-10 17:46 +0200
URL:       http://hg.openjdk.java.net/graal/graal/rev/f8adf47cc05e

checkcast is lowered to instanceof (GRAAL-248)

! graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/PushNodesThroughPiTest.java
! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/java/CheckCastNode.java
! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/java/InstanceOfNode.java
! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/LoweringPhase.java
! graal/com.oracle.graal.replacements/src/com/oracle/graal/replacements/InstanceOfSnippetsTemplates.java

Changeset: 31266ceb86ef
Author:    twisti
Date:      2013-07-10 12:50 -0700
URL:       http://hg.openjdk.java.net/graal/graal/rev/31266ceb86ef

SPARC: Can compile and run two or three methods of a bootstrap.

! 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.asm.sparc/src/com/oracle/graal/asm/sparc/SPARCMacroAssembler.java
! graal/com.oracle.graal.compiler.sparc/src/com/oracle/graal/compiler/sparc/SPARCLIRGenerator.java
! graal/com.oracle.graal.hotspot.sparc/src/com/oracle/graal/hotspot/sparc/SPARCHotSpotBackend.java
! graal/com.oracle.graal.hotspot.sparc/src/com/oracle/graal/hotspot/sparc/SPARCHotSpotLIRGenerator.java
! graal/com.oracle.graal.hotspot.sparc/src/com/oracle/graal/hotspot/sparc/SPARCHotSpotRuntime.java
+ graal/com.oracle.graal.hotspot.sparc/src/com/oracle/graal/hotspot/sparc/SPARCSafepointOp.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

Changeset: 8c8e47cc101d
Author:    Christian Humer <christian.humer at gmail.com>
Date:      2013-07-11 01:55 +0200
URL:       http://hg.openjdk.java.net/graal/graal/rev/8c8e47cc101d

Truffle-DSL: fixed a bug in removal of the frame from the generated generic execute method.

! graal/com.oracle.truffle.dsl.processor/src/com/oracle/truffle/dsl/processor/node/NodeCodeGenerator.java
! graal/com.oracle.truffle.dsl.processor/src/com/oracle/truffle/dsl/processor/node/NodeData.java
! graal/com.oracle.truffle.dsl.processor/src/com/oracle/truffle/dsl/processor/node/NodeParser.java

Changeset: 062304c74353
Author:    Christian Humer <christian.humer at gmail.com>
Date:      2013-07-11 01:56 +0200
URL:       http://hg.openjdk.java.net/graal/graal/rev/062304c74353

merge.


Changeset: 5c1afcee72ec
Author:    Thomas Wuerthinger <thomas.wuerthinger at oracle.com>
Date:      2013-07-10 19:48 -0700
URL:       http://hg.openjdk.java.net/graal/graal/rev/5c1afcee72ec

Relax TruffleCache assertion.

! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/TruffleCache.java

Changeset: 4109190a0da5
Author:    Roland Schatz <roland.schatz at oracle.com>
Date:      2013-07-11 11:09 +0200
URL:       http://hg.openjdk.java.net/graal/graal/rev/4109190a0da5

Move lowering of arraycopy to the correct lowering phase.

! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/UnsafeArrayCopyNode.java

Changeset: 58cb83bfd882
Author:    Christos Kotselidis <christos.kotselidis at oracle.com>
Date:      2013-07-11 11:55 +0200
URL:       http://hg.openjdk.java.net/graal/graal/rev/58cb83bfd882

Simplify code

! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/NewObjectSnippets.java

Changeset: 2a87417379ce
Author:    Christos Kotselidis <christos.kotselidis at oracle.com>
Date:      2013-07-11 11:56 +0200
URL:       http://hg.openjdk.java.net/graal/graal/rev/2a87417379ce

Remove ternary

! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/ObjectCloneSnippets.java

Changeset: f1cd428fca9f
Author:    Christos Kotselidis <christos.kotselidis at oracle.com>
Date:      2013-07-11 11:58 +0200
URL:       http://hg.openjdk.java.net/graal/graal/rev/f1cd428fca9f

Remove caching of gcStartCycles

! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/WriteBarrierSnippets.java

Changeset: b95d42fdddca
Author:    Christos Kotselidis <christos.kotselidis at oracle.com>
Date:      2013-07-11 12:09 +0200
URL:       http://hg.openjdk.java.net/graal/graal/rev/b95d42fdddca

Minor refactoring

! src/share/vm/gc_interface/collectedHeap.hpp

Changeset: 7cdd4708b1aa
Author:    Christos Kotselidis <christos.kotselidis at oracle.com>
Date:      2013-07-11 12:10 +0200
URL:       http://hg.openjdk.java.net/graal/graal/rev/7cdd4708b1aa

Merge


Changeset: 84b944726df2
Author:    Andreas Woess <andreas.woess at jku.at>
Date:      2013-07-11 12:22 +0200
URL:       http://hg.openjdk.java.net/graal/graal/rev/84b944726df2

Truffle: introduce NodeUtil.countNodes

! graal/com.oracle.truffle.api/src/com/oracle/truffle/api/nodes/NodeUtil.java

Changeset: fd53f9f7007b
Author:    Andreas Woess <andreas.woess at jku.at>
Date:      2013-07-11 13:09 +0200
URL:       http://hg.openjdk.java.net/graal/graal/rev/fd53f9f7007b

Truffle: refactor inlining

! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/OptimizedCallTarget.java
! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/TruffleCompilerOptions.java

Changeset: 8d961f93725c
Author:    Gilles Duboscq <duboscq at ssw.jku.at>
Date:      2013-07-09 18:17 +0200
URL:       http://hg.openjdk.java.net/graal/graal/rev/8d961f93725c

Use GuardedValueNode in the inlining

! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/GuardedValueNode.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

Changeset: a643c88d164f
Author:    Gilles Duboscq <duboscq at ssw.jku.at>
Date:      2013-07-11 14:45 +0200
URL:       http://hg.openjdk.java.net/graal/graal/rev/a643c88d164f

Add scopes to capture the graphs in ReplacementsImpl

! graal/com.oracle.graal.replacements/src/com/oracle/graal/replacements/ReplacementsImpl.java

Changeset: 41e9c8845826
Author:    Gilles Duboscq <duboscq at ssw.jku.at>
Date:      2013-07-11 14:47 +0200
URL:       http://hg.openjdk.java.net/graal/graal/rev/41e9c8845826

Improve instanceof canonicalization

! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/java/InstanceOfNode.java

Changeset: 5888e1772ba1
Author:    Roland Schatz <roland.schatz at oracle.com>
Date:      2013-07-11 16:21 +0200
URL:       http://hg.openjdk.java.net/graal/graal/rev/5888e1772ba1

Check that guards are only created in BEFORE_GUARDS lowering.

! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/LoweringPhase.java

Changeset: cd28ead65a53
Author:    Roland Schatz <roland.schatz at oracle.com>
Date:      2013-07-11 16:21 +0200
URL:       http://hg.openjdk.java.net/graal/graal/rev/cd28ead65a53

Output lowering type in graph dumps.

! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/LoweringPhase.java

Changeset: 68d4d5457546
Author:    Doug Simon <doug.simon at oracle.com>
Date:      2013-07-11 20:56 +0200
URL:       http://hg.openjdk.java.net/graal/graal/rev/68d4d5457546

add sequential id prefixes to IGV graphs

! graal/com.oracle.graal.printer/src/com/oracle/graal/printer/GraphPrinterDumpHandler.java

Changeset: 7f50d79c46f2
Author:    Doug Simon <doug.simon at oracle.com>
Date:      2013-07-11 20:57 +0200
URL:       http://hg.openjdk.java.net/graal/graal/rev/7f50d79c46f2

fixed a stamp join to be done the "right" way (stamp joining is not currently commutative)

! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/java/CheckCastNode.java

Changeset: 057154505878
Author:    Doug Simon <doug.simon at oracle.com>
Date:      2013-07-11 20:58 +0200
URL:       http://hg.openjdk.java.net/graal/graal/rev/057154505878

fixed canonicalization bug (detected by Gilles) in binary logic nodes

! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/LogicConjunctionNode.java
! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/LogicConstantNode.java
! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/LogicDisjunctionNode.java

Changeset: 28dc33dc4565
Author:    Christos Kotselidis <christos.kotselidis at oracle.com>
Date:      2013-07-12 12:24 +0200
URL:       http://hg.openjdk.java.net/graal/graal/rev/28dc33dc4565

Delegate compressed klass pointers info from HotSpot to Graal

! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/HotSpotVMConfig.java
! src/share/vm/graal/graalCompilerToVM.cpp

Changeset: c3760150dc29
Author:    Christos Kotselidis <christos.kotselidis at oracle.com>
Date:      2013-07-12 12:40 +0200
URL:       http://hg.openjdk.java.net/graal/graal/rev/c3760150dc29

Add function to read compressed klass pointers of constant objects natively

! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/HotSpotGraalRuntime.java
! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/bridge/CompilerToVM.java
! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/bridge/CompilerToVMImpl.java
! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotRuntime.java
! src/share/vm/graal/graalCompilerToVM.cpp

Changeset: b975cad32411
Author:    Christos Kotselidis <christos.kotselidis at oracle.com>
Date:      2013-07-12 12:42 +0200
URL:       http://hg.openjdk.java.net/graal/graal/rev/b975cad32411

Add StoreHubNode

+ graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/extended/StoreHubNode.java

Changeset: 0517026315a0
Author:    Christos Kotselidis <christos.kotselidis at oracle.com>
Date:      2013-07-12 12:46 +0200
URL:       http://hg.openjdk.java.net/graal/graal/rev/0517026315a0

Adjust header size to compressed klass pointers

! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/HotSpotReplacementsUtil.java
! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/NewObjectSnippets.java
! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/ObjectCloneSnippets.java
! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/stubs/NewInstanceStub.java

Changeset: 0d3d300064a8
Author:    Christos Kotselidis <christos.kotselidis at oracle.com>
Date:      2013-07-12 12:47 +0200
URL:       http://hg.openjdk.java.net/graal/graal/rev/0d3d300064a8

Remove scratch register from compressed load LIR instruction (used only for testing)

! 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: 867588b3ecb4
Author:    Christos Kotselidis <christos.kotselidis at oracle.com>
Date:      2013-07-12 12:48 +0200
URL:       http://hg.openjdk.java.net/graal/graal/rev/867588b3ecb4

Variables' renaming

! graal/com.oracle.graal.lir.amd64/src/com/oracle/graal/lir/amd64/AMD64Move.java

Changeset: 7cc08d83111d
Author:    Lukas Stadler <lukas.stadler at jku.at>
Date:      2013-07-12 15:29 +0200
URL:       http://hg.openjdk.java.net/graal/graal/rev/7cc08d83111d

correctly anchor eliminated guards during ConditionalElimination

! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/ConditionalEliminationPhase.java

Changeset: 5fc4aedf7910
Author:    Lukas Stadler <lukas.stadler at jku.at>
Date:      2013-07-12 15:30 +0200
URL:       http://hg.openjdk.java.net/graal/graal/rev/5fc4aedf7910

add relative pc to uncommon trap event entry (helps debugging SEGFAULTs in copmiled code)

! src/share/vm/runtime/deoptimization.cpp

Changeset: c84048228b4a
Author:    Lukas Stadler <lukas.stadler at jku.at>
Date:      2013-07-12 17:01 +0200
URL:       http://hg.openjdk.java.net/graal/graal/rev/c84048228b4a

prevent repeated simplification of FixedGuardNode

! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/FixedGuardNode.java

Changeset: 097a634b57b1
Author:    Lukas Stadler <lukas.stadler at jku.at>
Date:      2013-07-12 11:19 +0200
URL:       http://hg.openjdk.java.net/graal/graal/rev/097a634b57b1

fix stamps for constants of boolean, byte, char and short type, add tests

+ graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/IntegerStampTest.java
! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/type/StampFactory.java

Changeset: 0e671d5268d1
Author:    Lukas Stadler <lukas.stadler at jku.at>
Date:      2013-07-11 14:57 +0200
URL:       http://hg.openjdk.java.net/graal/graal/rev/0e671d5268d1

re-introduce early read elimination as part of escape analysis

! 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/PartialEscapePhase.java
+ graal/com.oracle.graal.virtual/src/com/oracle/graal/virtual/phases/ea/ReadEliminationPEBlockState.java
+ graal/com.oracle.graal.virtual/src/com/oracle/graal/virtual/phases/ea/ReadEliminationPEClosure.java

Changeset: e35a72e32aae
Author:    Lukas Stadler <lukas.stadler at jku.at>
Date:      2013-07-11 15:13 +0200
URL:       http://hg.openjdk.java.net/graal/graal/rev/e35a72e32aae

add test for early read elimination

+ graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/ea/PEAReadEliminationTest.java

Changeset: c78097171701
Author:    Doug Simon <doug.simon at oracle.com>
Date:      2013-07-12 14:48 +0200
URL:       http://hg.openjdk.java.net/graal/graal/rev/c78097171701

made the "Remove selected graphs and groups" action work in IGV for binary graphs

! src/share/tools/IdealGraphVisualizer/Coordinator/src/com/sun/hotspot/igv/coordinator/OutlineTopComponent.java
! src/share/tools/IdealGraphVisualizer/Coordinator/src/com/sun/hotspot/igv/coordinator/actions/ImportAction.java
! src/share/tools/IdealGraphVisualizer/Data/src/com/sun/hotspot/igv/data/serialization/BinaryParser.java
! src/share/tools/IdealGraphVisualizer/NetworkConnection/src/com/sun/hotspot/igv/connection/Client.java
! src/share/tools/IdealGraphVisualizer/NetworkConnection/src/com/sun/hotspot/igv/connection/Server.java

Changeset: 9d079661cbcd
Author:    Doug Simon <doug.simon at oracle.com>
Date:      2013-07-12 18:08 +0200
URL:       http://hg.openjdk.java.net/graal/graal/rev/9d079661cbcd

fixed generation of sequential id prefixes for IGV graphs

! graal/com.oracle.graal.printer/src/com/oracle/graal/printer/GraphPrinterDumpHandler.java

Changeset: 70cb17338a70
Author:    Doug Simon <doug.simon at oracle.com>
Date:      2013-07-12 18:09 +0200
URL:       http://hg.openjdk.java.net/graal/graal/rev/70cb17338a70

Merge.


Changeset: 2a4ad6ab345e
Author:    Doug Simon <doug.simon at oracle.com>
Date:      2013-07-12 19:09 +0200
URL:       http://hg.openjdk.java.net/graal/graal/rev/2a4ad6ab345e

disabled new lowering of checkcast until performance regression is fixed

! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/java/CheckCastNode.java

Changeset: f1904749e4fe
Author:    Doug Simon <doug.simon at oracle.com>
Date:      2013-07-12 22:52 +0200
URL:       http://hg.openjdk.java.net/graal/graal/rev/f1904749e4fe

re-enabled new lowering of checkcast with addition of a null-check guard where the profile has nullSeen=FALSE

! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/java/CheckCastNode.java

Changeset: 40f6bda3f91d
Author:    Christos Kotselidis <christos.kotselidis at oracle.com>
Date:      2013-07-12 14:16 +0200
URL:       http://hg.openjdk.java.net/graal/graal/rev/40f6bda3f91d

Add compressed klass pointers support in LIR

! 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: 0bd794eb8222
Author:    Christos Kotselidis <christos.kotselidis at oracle.com>
Date:      2013-07-12 14:17 +0200
URL:       http://hg.openjdk.java.net/graal/graal/rev/0bd794eb8222

Add compressed oop support in HotSpot Backend

! graal/com.oracle.graal.hotspot.amd64/src/com/oracle/graal/hotspot/amd64/AMD64HotSpotBackend.java

Changeset: 6621bc66bfa4
Author:    Christos Kotselidis <christos.kotselidis at oracle.com>
Date:      2013-07-12 14:20 +0200
URL:       http://hg.openjdk.java.net/graal/graal/rev/6621bc66bfa4

Add WriteHubNode lowering

! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotRuntime.java

Changeset: 8b8587c32812
Author:    Christos Kotselidis <christos.kotselidis at oracle.com>
Date:      2013-07-12 14:38 +0200
URL:       http://hg.openjdk.java.net/graal/graal/rev/8b8587c32812

Adjust load/store hub intrinsics to account for Compressed Klass pointers

! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/HotSpotReplacementsUtil.java

Changeset: 49a0bd6b0605
Author:    Christos Kotselidis <christos.kotselidis at oracle.com>
Date:      2013-07-12 14:40 +0200
URL:       http://hg.openjdk.java.net/graal/graal/rev/49a0bd6b0605

Delegate compressed klass pointers info to ReadNode of LoadHubNode

! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotRuntime.java

Changeset: 90b3cf36dc17
Author:    Christos Kotselidis <christos.kotselidis at oracle.com>
Date:      2013-07-12 14:43 +0200
URL:       http://hg.openjdk.java.net/graal/graal/rev/90b3cf36dc17

Replace direct read word with loadHub intrinsic in VerifyOop stub

! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/stubs/StubUtil.java

Changeset: 060f9ed42e2f
Author:    Christos Kotselidis <christos.kotselidis at oracle.com>
Date:      2013-07-12 14:58 +0200
URL:       http://hg.openjdk.java.net/graal/graal/rev/060f9ed42e2f

Augment compressed oop tests

! graal/com.oracle.graal.hotspot.test/src/com/oracle/graal/hotspot/test/CompressedOopTest.java

Changeset: 88992c295d47
Author:    Christos Kotselidis <christos.kotselidis at oracle.com>
Date:      2013-07-12 20:19 +0200
URL:       http://hg.openjdk.java.net/graal/graal/rev/88992c295d47

Merge


Changeset: cdbfff4547be
Author:    Christos Kotselidis <christos.kotselidis at oracle.com>
Date:      2013-07-12 21:48 +0200
URL:       http://hg.openjdk.java.net/graal/graal/rev/cdbfff4547be

Allow compressed klass pointers

! src/share/vm/runtime/arguments.cpp

Changeset: bdd7c8e2293e
Author:    Christos Kotselidis <christos.kotselidis at oracle.com>
Date:      2013-07-12 23:26 +0200
URL:       http://hg.openjdk.java.net/graal/graal/rev/bdd7c8e2293e

Merge


Changeset: 00a9dbcbe431
Author:    Christian Humer <christian.humer at gmail.com>
Date:      2013-07-13 17:13 +0200
URL:       http://hg.openjdk.java.net/graal/graal/rev/00a9dbcbe431

Truffle-DSL: Fixed a bug in polymorphic code generation.

! graal/com.oracle.truffle.dsl.processor/src/com/oracle/truffle/dsl/processor/node/NodeCodeGenerator.java

Changeset: 99789440ce28
Author:    Christian Humer <christian.humer at gmail.com>
Date:      2013-07-13 17:14 +0200
URL:       http://hg.openjdk.java.net/graal/graal/rev/99789440ce28

Truffle: Added assertions to replaceChild.

! graal/com.oracle.truffle.api/src/com/oracle/truffle/api/nodes/NodeUtil.java

Changeset: ff6eb563a2e2
Author:    Christian Humer <christian.humer at gmail.com>
Date:      2013-07-13 17:21 +0200
URL:       http://hg.openjdk.java.net/graal/graal/rev/ff6eb563a2e2

Truffle-DSL: Added additional test case for polymporphic generation.

+ graal/com.oracle.truffle.api.dsl.test/src/com/oracle/truffle/api/dsl/test/PolymorphicTest2.java

Changeset: 45dc193567c2
Author:    Christos Kotselidis <christos.kotselidis at oracle.com>
Date:      2013-07-15 10:48 +0200
URL:       http://hg.openjdk.java.net/graal/graal/rev/45dc193567c2

Add assertions

! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotRuntime.java

Changeset: cbaf26740df8
Author:    Christos Kotselidis <christos.kotselidis at oracle.com>
Date:      2013-07-15 10:50 +0200
URL:       http://hg.openjdk.java.net/graal/graal/rev/cbaf26740df8

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/NewObjectSnippets.java
! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/ObjectCloneSnippets.java
! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/stubs/NewInstanceStub.java

Changeset: 257e2455270e
Author:    Christos Kotselidis <christos.kotselidis at oracle.com>
Date:      2013-07-15 10:59 +0200
URL:       http://hg.openjdk.java.net/graal/graal/rev/257e2455270e

Merge


Changeset: 3811d04d933e
Author:    Roland Schatz <roland.schatz at oracle.com>
Date:      2013-07-15 12:02 +0200
URL:       http://hg.openjdk.java.net/graal/graal/rev/3811d04d933e

Do not re-compress oops that are already compressed.

! graal/com.oracle.graal.hotspot.amd64/src/com/oracle/graal/hotspot/amd64/AMD64HotSpotLIRGenerator.java

Changeset: a5c9bc1f28fb
Author:    Lukas Stadler <lukas.stadler at jku.at>
Date:      2013-07-15 13:11 +0200
URL:       http://hg.openjdk.java.net/graal/graal/rev/a5c9bc1f28fb

fix nullness for not-equals in ConditionalEliminationPhase
bug reported by Miguel Garcia <miguelalfredo.garcia at epfl.ch>

! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/ConditionalEliminationPhase.java

Changeset: e7c0658c2f25
Author:    Lukas Stadler <lukas.stadler at jku.at>
Date:      2013-07-15 13:36 +0200
URL:       http://hg.openjdk.java.net/graal/graal/rev/e7c0658c2f25

record disjunctive conditions in ConditionalEliminationPhase
change suggested by Miguel Garcia <miguelalfredo.garcia at epfl.ch>

! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/ConditionalEliminationPhase.java

Changeset: 9f5a4074e36b
Author:    Lukas Stadler <lukas.stadler at jku.at>
Date:      2013-07-15 13:36 +0200
URL:       http://hg.openjdk.java.net/graal/graal/rev/9f5a4074e36b

test for nullness and disjunctive conditions in ConditionalEliminationPhase

! graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/ConditionalEliminationTest.java

Changeset: 7b5d7c42598b
Author:    Andreas Woess <andreas.woess at jku.at>
Date:      2013-07-11 19:34 +0200
URL:       http://hg.openjdk.java.net/graal/graal/rev/7b5d7c42598b

Truffle: change sorting of inlinable call sites

! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/OptimizedCallTarget.java

Changeset: e2f5ae9afdc5
Author:    Andreas Woess <andreas.woess at jku.at>
Date:      2013-07-11 22:14 +0200
URL:       http://hg.openjdk.java.net/graal/graal/rev/e2f5ae9afdc5

Truffle: introduce profiling option

! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/GraalTruffleRuntime.java
! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/OptimizedCallTarget.java
! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/TruffleCompilerOptions.java

Changeset: 64740220db85
Author:    Andreas Woess <andreas.woess at jku.at>
Date:      2013-07-15 14:09 +0200
URL:       http://hg.openjdk.java.net/graal/graal/rev/64740220db85

Merge


Changeset: 4c12d3756015
Author:    Andreas Woess <andreas.woess at jku.at>
Date:      2013-07-15 14:12 +0200
URL:       http://hg.openjdk.java.net/graal/graal/rev/4c12d3756015

Truffle: Never compile InvalidInstalledCodeException catch handler.

! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/TruffleCompilerImpl.java

Changeset: b221e31d7b0b
Author:    Andreas Woess <andreas.woess at jku.at>
Date:      2013-07-15 15:26 +0200
URL:       http://hg.openjdk.java.net/graal/graal/rev/b221e31d7b0b

Truffle: revise NodeUtil.replaceChild assertion

! graal/com.oracle.truffle.api/src/com/oracle/truffle/api/nodes/NodeUtil.java

Changeset: 7f6580db1e88
Author:    Andreas Woess <andreas.woess at jku.at>
Date:      2013-07-15 14:49 +0200
URL:       http://hg.openjdk.java.net/graal/graal/rev/7f6580db1e88

Truffle: add assertions to verify the finalness of child fields.

! graal/com.oracle.truffle.api.test/src/com/oracle/truffle/api/test/ReplaceTest.java
! graal/com.oracle.truffle.api/src/com/oracle/truffle/api/nodes/NodeUtil.java

Changeset: f4f46b734a4c
Author:    Andreas Woess <andreas.woess at jku.at>
Date:      2013-07-15 15:29 +0200
URL:       http://hg.openjdk.java.net/graal/graal/rev/f4f46b734a4c

Merge


Changeset: e82c28e94f08
Author:    Roland Schatz <roland.schatz at oracle.com>
Date:      2013-07-15 16:24 +0200
URL:       http://hg.openjdk.java.net/graal/graal/rev/e82c28e94f08

Don't add G1 prebarrier if the written location is uninitialized.

! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/phases/WriteBarrierAdditionPhase.java
! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/UnsafeArrayCopyNode.java
! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/extended/ArrayRangeWriteNode.java
! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/extended/WriteNode.java

Changeset: 7f186f1486f7
Author:    Roland Schatz <roland.schatz at oracle.com>
Date:      2013-07-15 16:24 +0200
URL:       http://hg.openjdk.java.net/graal/graal/rev/7f186f1486f7

Use initializing write node in object clone snippets.

! 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: 59d2d6a30d29
Author:    Roland Schatz <roland.schatz at oracle.com>
Date:      2013-07-15 16:24 +0200
URL:       http://hg.openjdk.java.net/graal/graal/rev/59d2d6a30d29

Re-enable omission of array initialization for G1.

! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/NewObjectSnippets.java
! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/ObjectCloneSnippets.java

Changeset: dd7a8807378b
Author:    Doug Simon <doug.simon at oracle.com>
Date:      2013-07-15 16:53 +0200
URL:       http://hg.openjdk.java.net/graal/graal/rev/dd7a8807378b

cannot omit frame for compiled methods that make a foreign call (GRAAL-362)

! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/gen/LIRGenerator.java
! graal/com.oracle.graal.hotspot.amd64/src/com/oracle/graal/hotspot/amd64/AMD64HotSpotBackend.java

Changeset: c483912aaf70
Author:    Lukas Stadler <lukas.stadler at jku.at>
Date:      2013-07-15 16:39 +0200
URL:       http://hg.openjdk.java.net/graal/graal/rev/c483912aaf70

add ValueProxy interface and infrastructure

! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/GuardedValueNode.java
! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/GuardingPiNode.java
! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/PiNode.java
! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/ProxyNode.java
! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/TypeProfileProxyNode.java
! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/java/CheckCastNode.java
+ graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/spi/ValueProxy.java
! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/util/GraphUtil.java

Changeset: 5e338844c64c
Author:    Lukas Stadler <lukas.stadler at jku.at>
Date:      2013-07-15 15:58 +0200
URL:       http://hg.openjdk.java.net/graal/graal/rev/5e338844c64c

make early read elimination see through ValueProxies

! graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/ea/PEAReadEliminationTest.java
! graal/com.oracle.graal.virtual/src/com/oracle/graal/virtual/phases/ea/ReadEliminationPEClosure.java

Changeset: d2f8addaf504
Author:    Lukas Stadler <lukas.stadler at jku.at>
Date:      2013-07-15 15:58 +0200
URL:       http://hg.openjdk.java.net/graal/graal/rev/d2f8addaf504

assertion in GraalCompiler (don't parse @Test methods)

! graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/GraalCompilerTest.java

Changeset: ae3d070ab223
Author:    Lukas Stadler <lukas.stadler at jku.at>
Date:      2013-07-15 16:36 +0200
URL:       http://hg.openjdk.java.net/graal/graal/rev/ae3d070ab223

make ValueNode.stamp() final, fix WordTypeRewriterPhase

! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/ProxyNode.java
! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/TypeProfileProxyNode.java
! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/ValueNode.java
! graal/com.oracle.graal.word/src/com/oracle/graal/word/phases/WordTypeRewriterPhase.java

Changeset: 3a044e575466
Author:    Lukas Stadler <lukas.stadler at jku.at>
Date:      2013-07-15 17:32 +0200
URL:       http://hg.openjdk.java.net/graal/graal/rev/3a044e575466

add ValueProxy interface to FixedValueAnchorNode

! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/nodes/FixedValueAnchorNode.java

Changeset: 88d0dc388450
Author:    Lukas Stadler <lukas.stadler at jku.at>
Date:      2013-07-15 17:52 +0200
URL:       http://hg.openjdk.java.net/graal/graal/rev/88d0dc388450

let ConditionalEliminationPhase change invokes to InvokeKind.Special based on type information

! 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: 058abc2b59a5
Author:    Lukas Stadler <lukas.stadler at jku.at>
Date:      2013-07-15 17:54 +0200
URL:       http://hg.openjdk.java.net/graal/graal/rev/058abc2b59a5

Merge

! graal/com.oracle.graal.word/src/com/oracle/graal/word/phases/WordTypeRewriterPhase.java

Changeset: 395d34c10e26
Author:    Doug Simon <doug.simon at oracle.com>
Date:      2013-07-15 18:22 +0200
URL:       http://hg.openjdk.java.net/graal/graal/rev/395d34c10e26

HSAIL backend changes
Contributed-by: Tom Deneau <tom.deneau at amd.com>

* stackslot mapping was incorrect when combinations of 32-bit and
 64-bit stores were generated.  StackSlot alignment in
 HSAILTargetDescription set to 8.

* compressedOops support in various heap size configurations (with or
 without either of shift or heap base).  So we don't need
 XX:-UseCompressedOops anymore.

* some support for unsigned shifts, long shifts, logical ops for long
 datatype.

* a new GraalOption, InlineEverything.  Some HSAIL targets are not
 able to handle HSAIL function calls yet, plus we are still working
 on emitting HSAIL function calls in the compiler.

* hack for emitForeignCall special cases of createOutOfBoundsException
 or createNullPointerException.  (We just emit a comment.  Real
 exception handling still pending).  These nodes came about when we
 more aggressively inlined, although this has not been explained yet.

* support HSAILAddressValues as operands for arithmetic ops.  Use
 HSAIL lda instruction to get address into a register.  Used in
 particular for USHR for card-marking.

* Added some new junit tests. (some ported from their lambda versions)

  * StaticNBodyCallTest which would fail with default inlining (since
    we don't yet generate HSAIL calls).  It uses junit.assumeTrue and
    tests whether InlineEverything is set.  It (and also some
    lambda-based junit tests not part of this webrev) do pass nicely
    when InlineEverything is set true.

  * tests for storing an object, which test being able to handle the
    card-marking logic, as well as the encoding and decoding of a
    compressed oop.

  * some 2D matrix tests that showed a problem before the stackslot
    change above.  (have a mixture of 32-bit and 64-bit stackslot
    spills)

! graal/com.oracle.graal.asm.hsail/src/com/oracle/graal/asm/hsail/HSAILAssembler.java
! graal/com.oracle.graal.compiler.hsail.test.infra/src/com/oracle/graal/compiler/hsail/test/infra/GraalKernelTester.java
! graal/com.oracle.graal.compiler.hsail.test.infra/src/com/oracle/graal/compiler/hsail/test/infra/KernelTester.java
+ graal/com.oracle.graal.compiler.hsail.test/src/com/oracle/graal/compiler/hsail/test/Float2DMatrixBase.java
+ graal/com.oracle.graal.compiler.hsail.test/src/com/oracle/graal/compiler/hsail/test/Float2DMatrixMultiplyRangeFinalTest.java
+ graal/com.oracle.graal.compiler.hsail.test/src/com/oracle/graal/compiler/hsail/test/Float2DMatrixMultiplyTest.java
+ graal/com.oracle.graal.compiler.hsail.test/src/com/oracle/graal/compiler/hsail/test/ObjectStoreNullTest.java
+ graal/com.oracle.graal.compiler.hsail.test/src/com/oracle/graal/compiler/hsail/test/ObjectStoreTest.java
! graal/com.oracle.graal.compiler.hsail.test/src/com/oracle/graal/compiler/hsail/test/StaticMandelTest.java
+ graal/com.oracle.graal.compiler.hsail.test/src/com/oracle/graal/compiler/hsail/test/StaticNBodyCallTest.java
! graal/com.oracle.graal.compiler.hsail/src/com/oracle/graal/compiler/hsail/HSAILCompilationResult.java
! graal/com.oracle.graal.compiler.hsail/src/com/oracle/graal/compiler/hsail/HSAILLIRGenerator.java
! graal/com.oracle.graal.lir.hsail/src/com/oracle/graal/lir/hsail/HSAILArithmetic.java
! graal/com.oracle.graal.lir.hsail/src/com/oracle/graal/lir/hsail/HSAILControlFlow.java
! graal/com.oracle.graal.lir.hsail/src/com/oracle/graal/lir/hsail/HSAILMove.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


From mick.jordan at oracle.com  Mon Jul 15 10:08:23 2013
From: mick.jordan at oracle.com (Mick Jordan)
Date: Mon, 15 Jul 2013 10:08:23 -0700
Subject: NullPointerException in HotSpotRuntime:lower when using Snippets
In-Reply-To: <06FF4162-C221-4742-8CD0-B56D86D1E723@sms.ed.ac.uk>
References: <72C1FE55-E500-47DA-B5DE-831AB7119F3F@sms.ed.ac.uk>
	<4AD5DAB8-9F0B-44AD-9FD3-B007DADE45A8@sms.ed.ac.uk>
	<BB081FA8-D9FE-45CE-9D14-E6D648C46AB7@oracle.com>
	<D590922B-A5FB-459E-B58A-74C8D51C0369@sms.ed.ac.uk>
	<46BE599D-BAE6-47D6-A660-BBD8811FF6C3@oracle.com>
	<A89C1C43-8199-4DF8-A96E-9D79ADA898DD@sms.ed.ac.uk>
	<04453C30-7691-4C7C-8FE5-6FF636CE2711@oracle.com>
	<66066558-C469-4FF9-8C76-AFA6AC815238@oracle.com>
	<B1DF675D-1B38-4C48-9150-2D8BD34AE47A@sms.ed.ac.uk>
	<D3C3A49F-7A59-4604-8271-502EF7EA8739@oracle.com>
	<D6E7A5D4-4C33-4E5F-817B-121BC3F892B9@sms.ed.ac.uk>
	<D580B04A-5382-42AC-83FE-0D4590A35138@oracle.com>
	<F17781C1-D00A-4348-B817-6C259ECCE23F@sms.ed.ac.uk>
	<FB17EF9D-5C90-4CB3-B439-3F3E1F29EA16@oracle.com>
	<A3A6884D-4D69-4B57-B020-52942B89B0AF@sms.ed.ac.uk>
	<C2FD89C3-3353-4AD4-8C5D-6A4144F2BD2F@oracle.com>
	<A2419C2C-59CA-405C-BF2E-C21E0D3B19A2@sms.ed.ac.uk>
	<C0C4D292-7403-474B-8602-A2CCC647AFB0@oracle.com>
	<06FF4162-C221-4742-8CD0-B56D86D1E723@sms.ed.ac.uk>
Message-ID: <51E42C87.1080704@oracle.com>

On 7/14/13 10:13 AM, ATKIN-GRANVILLE Chris wrote:
> On 14 Jul 2013, at 17:10, Doug Simon <doug.simon at oracle.com> wrote:
>
>> How important is it that your instrumentation achieves complete coverage? Do you need to see every single array access in the program? This will not be possible in the current GraalVM because it's hard to guarantee that execution always happens in compiled code. For this, you really need to do bytecode instrumentation.
> We are only interested in array accesses that occur within loops (eventually we'll also extend to field accesses and so on, but for now we're sticking with arrays). Accesses that are not executed are unimportant as they pose no dependence risk.
>
> Perhaps it would be possible use ASM or another bytecode manipulation library to add in transformations from InstalledCode.getCode(). Would it be possible to somehow load modified bytecode into Graal or something like that?
>
>
Given your goals, as I understand them, have you looked at the Maxine VM 
<https://wikis.oracle.com/display/MaxineVM/Home> and the VMA 
<https://wikis.oracle.com/display/MaxineVM/Virtual+Machine+Level+Analysis> 
extension? [I.e., how important is it that you run with Hotspot?]

I ran your example loopDependency example just now (with full bytecode 
advising enabled). The output from the tool that analyses the trace 
output (you can do the analysis online if you prefer), is attached. In 
some sense VMA is equivalent to the bytecode transformation in systems 
like Aspect/J but it is much more efficient and does not suffer the 
problems of operating strictly "above" the VM. Maxine also implements 
the JVMTI instrumentation framework and it is possible to write JVMTI 
handlers in Java.

I have a version of VMA for Graal, which is based on inserting 
AdviceNodes in the graph and then lowering those nodes via snippets to 
hook into the Maxine runtime support for VMA. I'll be shipping all of 
this by the end of the month. In principle Graal/VMA would work for 
Hotspot but, as Doug notes, there are issues related to the overall 
Hotspot environment. Not least is that VMA leverages Maxine's ability to 
(safely) change the object layout to add support for efficient object 
ids and extra bits for marking (which may not matter for your goals).

Mick



-------------- next part --------------
$ mx vm -cp $vmacp -XX:+VMAXJDK test.Glanville
bash-3.2$ qa
%% e AdviceRecords
39835000   main B ThreadStarting 
48203000   main A 0 Unseen (com.sun.max.vm.type.VMClassLoader) -3:0
48216000   main A 0 Unseen (com.sun.max.vm.type.BootClassLoader) -2:0
48217000   main A 0 Unseen (sun.misc.Launcher$AppClassLoader) -1:0
48219000   main A 0 MethodEntry test.Glanville.main
48224000   main B 0 ConstLoadLong  5
48226000   main A 1 NewArray (int[]) 1:05
48229000   main B 3 StackAdjust DUP
48230000   main B 4 ConstLoadLong  1
48231000   main B 5 ConstLoadLong  1
48231000   main B 6 ArrayStoreLong (int[]) 1:0[1]  1
48233000   main B 7 StackAdjust DUP
48233000   main B 8 ConstLoadLong  2
48234000   main B 9 ConstLoadLong  2
48234000   main B 10 ArrayStoreLong (int[]) 1:0[2]  2
48234000   main B 11 StackAdjust DUP
48235000   main B 12 ConstLoadLong  3
48235000   main B 13 ConstLoadLong  3
48235000   main B 14 ArrayStoreLong (int[]) 1:0[3]  3
48236000   main B 15 StackAdjust DUP
48236000   main B 16 ConstLoadLong  4
48236000   main B 17 ConstLoadLong  4
48236000   main B 18 ArrayStoreLong (int[]) 1:0[4]  4
48237000   main B 19 StoreObject 1 (int[]) 1:0
48239000   main B 20 ConstLoadLong  5
48239000   main A 21 NewArray (int[]) 2:05
48240000   main B 23 StackAdjust DUP
48240000   main B 24 ConstLoadLong  0
48240000   main B 25 ConstLoadLong  4
48240000   main B 26 ArrayStoreLong (int[]) 2:0[0]  4
48241000   main B 27 StackAdjust DUP
48241000   main B 28 ConstLoadLong  1
48241000   main B 29 ConstLoadLong  3
48242000   main B 30 ArrayStoreLong (int[]) 2:0[1]  3
48242000   main B 31 StackAdjust DUP
48242000   main B 32 ConstLoadLong  2
48243000   main B 33 ConstLoadLong  2
48243000   main B 34 ArrayStoreLong (int[]) 2:0[2]  2
48243000   main B 35 StackAdjust DUP
48243000   main B 36 ConstLoadLong  3
48244000   main B 37 ConstLoadLong  1
48244000   main B 38 ArrayStoreLong (int[]) 2:0[3]  1
48244000   main B 39 StoreObject 2 (int[]) 2:0
48245000   main B 40 Load 1
48246000   main B 40 LoadObject 
48248000   main B 41 Load 2
48248000   main B 41 LoadObject 
48249000   main B 42 InvokeStatic test.Glanville.loopDependency
48346000   main A 0 MethodEntry test.Glanville.loopDependency
48349000   main B 0 Load 0
48350000   main B 0 LoadObject 
48351000   main B 1 ArrayLength 5
48352000   main A 2 NewArray (int[]) 3:05
48353000   main B 4 StoreObject 2 (int[]) 3:0
48353000   main B 5 ConstLoadLong  0
48354000   main B 6 StoreLong 3 0
48355000   main B 7 Goto -> 21
48357000   main B 21 Load 3
48357000   main B 22 Load 0
48357000   main B 22 LoadObject 
48358000   main B 23 ArrayLength 5
48358000   main B 24 IfInt IF_ICMPLT 0 5 -> 10
48359000   main B 10 Load 2
48360000   main B 10 LoadObject 
48360000   main B 11 Load 3
48360000   main B 12 Load 0
48360000   main B 12 LoadObject 
48361000   main B 13 Load 1
48361000   main B 13 LoadObject 
48361000   main B 14 Load 3
48362000   main B 15 ArrayLoad (int[]) 2:0[0]
48363000   main B 16 ArrayLoad (int[]) 1:0[4]
48363000   main B 17 ArrayStoreLong (int[]) 3:0[0]  4
48364000   main B 18 OperationLong  3 IINC 1
48366000   main B 21 Load 3
48366000   main B 22 Load 0
48366000   main B 22 LoadObject 
48367000   main B 23 ArrayLength 5
48367000   main B 24 IfInt IF_ICMPLT 1 5 -> 10
48367000   main B 10 Load 2
48368000   main B 10 LoadObject 
48368000   main B 11 Load 3
48368000   main B 12 Load 0
48369000   main B 12 LoadObject 
48369000   main B 13 Load 1
48369000   main B 13 LoadObject 
48369000   main B 14 Load 3
48370000   main B 15 ArrayLoad (int[]) 2:0[1]
48370000   main B 16 ArrayLoad (int[]) 1:0[3]
48370000   main B 17 ArrayStoreLong (int[]) 3:0[1]  3
48371000   main B 18 OperationLong  3 IINC 1
48371000   main B 21 Load 3
48371000   main B 22 Load 0
48372000   main B 22 LoadObject 
48372000   main B 23 ArrayLength 5
48372000   main B 24 IfInt IF_ICMPLT 2 5 -> 10
48373000   main B 10 Load 2
48373000   main B 10 LoadObject 
48373000   main B 11 Load 3
48374000   main B 12 Load 0
48374000   main B 12 LoadObject 
48374000   main B 13 Load 1
48374000   main B 13 LoadObject 
48375000   main B 14 Load 3
48375000   main B 15 ArrayLoad (int[]) 2:0[2]
48375000   main B 16 ArrayLoad (int[]) 1:0[2]
48376000   main B 17 ArrayStoreLong (int[]) 3:0[2]  2
48376000   main B 18 OperationLong  3 IINC 1
48376000   main B 21 Load 3
48377000   main B 22 Load 0
48377000   main B 22 LoadObject 
48377000   main B 23 ArrayLength 5
48377000   main B 24 IfInt IF_ICMPLT 3 5 -> 10
48378000   main B 10 Load 2
48378000   main B 10 LoadObject 
48378000   main B 11 Load 3
48379000   main B 12 Load 0
48379000   main B 12 LoadObject 
48379000   main B 13 Load 1
48379000   main B 13 LoadObject 
48380000   main B 14 Load 3
48380000   main B 15 ArrayLoad (int[]) 2:0[3]
48380000   main B 16 ArrayLoad (int[]) 1:0[1]
48381000   main B 17 ArrayStoreLong (int[]) 3:0[3]  1
48381000   main B 18 OperationLong  3 IINC 1
48381000   main B 21 Load 3
48382000   main B 22 Load 0
48382000   main B 22 LoadObject 
48382000   main B 23 ArrayLength 5
48382000   main B 24 IfInt IF_ICMPLT 4 5 -> 10
48383000   main B 10 Load 2
48383000   main B 10 LoadObject 
48383000   main B 11 Load 3
48384000   main B 12 Load 0
48384000   main B 12 LoadObject 
48384000   main B 13 Load 1
48384000   main B 13 LoadObject 
48385000   main B 14 Load 3
48385000   main B 15 ArrayLoad (int[]) 2:0[4]
48385000   main B 16 ArrayLoad (int[]) 1:0[0]
48386000   main B 17 ArrayStoreLong (int[]) 3:0[4]  0
48386000   main B 18 OperationLong  3 IINC 1
48386000   main B 21 Load 3
48387000   main B 22 Load 0
48387000   main B 22 LoadObject 
48387000   main B 23 ArrayLength 5
48388000   main B 24 IfInt IF_ICMPLT 5 5 -> 10
48388000   main B 27 Load 2
48388000   main B 27 LoadObject 
48389000   main B 28 ReturnObject  (int[]) 3:0
48390000   main B 45 StackAdjust POP
48391000   main B 46 Return 
48394000   main B ThreadTerminating 
%% 

From s1255753 at sms.ed.ac.uk  Mon Jul 15 11:38:52 2013
From: s1255753 at sms.ed.ac.uk (ATKIN-GRANVILLE Chris)
Date: Mon, 15 Jul 2013 18:38:52 +0000
Subject: NullPointerException in HotSpotRuntime:lower when using Snippets
In-Reply-To: <51E42C87.1080704@oracle.com>
References: <72C1FE55-E500-47DA-B5DE-831AB7119F3F@sms.ed.ac.uk>
	<4AD5DAB8-9F0B-44AD-9FD3-B007DADE45A8@sms.ed.ac.uk>
	<BB081FA8-D9FE-45CE-9D14-E6D648C46AB7@oracle.com>
	<D590922B-A5FB-459E-B58A-74C8D51C0369@sms.ed.ac.uk>
	<46BE599D-BAE6-47D6-A660-BBD8811FF6C3@oracle.com>
	<A89C1C43-8199-4DF8-A96E-9D79ADA898DD@sms.ed.ac.uk>
	<04453C30-7691-4C7C-8FE5-6FF636CE2711@oracle.com>
	<66066558-C469-4FF9-8C76-AFA6AC815238@oracle.com>
	<B1DF675D-1B38-4C48-9150-2D8BD34AE47A@sms.ed.ac.uk>
	<D3C3A49F-7A59-4604-8271-502EF7EA8739@oracle.com>
	<D6E7A5D4-4C33-4E5F-817B-121BC3F892B9@sms.ed.ac.uk>
	<D580B04A-5382-42AC-83FE-0D4590A35138@oracle.com>
	<F17781C1-D00A-4348-B817-6C259ECCE23F@sms.ed.ac.uk>
	<FB17EF9D-5C90-4CB3-B439-3F3E1F29EA16@oracle.com>
	<A3A6884D-4D69-4B57-B020-52942B89B0AF@sms.ed.ac.uk>
	<C2FD89C3-3353-4AD4-8C5D-6A4144F2BD2F@oracle.com>
	<A2419C2C-59CA-405C-BF2E-C21E0D3B19A2@sms.ed.ac.uk>
	<C0C4D292-7403-474B-8602-A2CCC647AFB0@oracle.com>
	<06FF4162-C221-4742-8CD0-B56D86D1E723@sms.ed.ac.uk>
	<51E42C87.1080704@oracle.com>
Message-ID: <5BAB2A3B-508A-40B2-8900-EF6BF983DF52@sms.ed.ac.uk>

Hi Mick

On 15 Jul 2013, at 18:08, Mick Jordan <mick.jordan at oracle.com>
 wrote:

> On 7/14/13 10:13 AM, ATKIN-GRANVILLE Chris wrote:
>> On 14 Jul 2013, at 17:10, Doug Simon <doug.simon at oracle.com>
>>  wrote:
>> 
>> 
>>> How important is it that your instrumentation achieves complete coverage? Do you need to see every single array access in the program? This will not be possible in the current GraalVM because it's hard to guarantee that execution always happens in compiled code. For this, you really need to do bytecode instrumentation.
>>> 
>> We are only interested in array accesses that occur within loops (eventually we'll also extend to field accesses and so on, but for now we're sticking with arrays). Accesses that are not executed are unimportant as they pose no dependence risk.
>> 
>> Perhaps it would be possible use ASM or another bytecode manipulation library to add in transformations from InstalledCode.getCode(). Would it be possible to somehow load modified bytecode into Graal or something like that?
>> 
>> 
>> 
> Given your goals, as I understand them, have you looked at the Maxine VM and the VMA     extension? [I.e., how important is it that you run with Hotspot?]

I can't say I've given much thought to it yet, but I will now. I've been looking at modifying bytecode using javassist/ASM to call instrumentation, but there's other issues with that (mainly being able to detect loops would be manual). If I used Maxine + VMA, would it be relatively easy to implement dynamic tracing /in a loop/ - and /only/ in a loop? This is the disadvantage of using tools as low-level as VMA - I've lost a lot of the semantic information that is available at compile time (in Graal I had does-the-operation-exist-inside-a-loop working in <5 mins).

> I ran your example loopDependency example just now (with full bytecode advising enabled). The output from the tool that analyses the trace output (you can do the analysis online if you prefer), is attached. In some sense VMA is equivalent to the bytecode transformation in systems like Aspect/J but it is much more efficient and does not suffer the problems of operating strictly "above" the VM. Maxine also implements the JVMTI instrumentation framework and it is possible to write JVMTI handlers in Java.

> I have a version of VMA for Graal, which is based on inserting AdviceNodes in the graph and then lowering those nodes via snippets to hook into the Maxine runtime support for VMA. I'll be shipping all of this by the end of the month. In principle Graal/VMA would work for Hotspot but, as Doug notes, there are issues related to the     overall Hotspot environment. Not least is that VMA leverages Maxine's ability to (safely) change the object layout to add support for efficient object ids and extra bits for marking (which may not matter for your goals).
> 
> Mick
> 
> 
> 
> <glanville.trace>



-- 
The University of Edinburgh is a charitable body, registered in
Scotland, with registration number SC005336.


From mick.jordan at oracle.com  Mon Jul 15 11:57:57 2013
From: mick.jordan at oracle.com (Mick Jordan)
Date: Mon, 15 Jul 2013 11:57:57 -0700
Subject: NullPointerException in HotSpotRuntime:lower when using Snippets
In-Reply-To: <5BAB2A3B-508A-40B2-8900-EF6BF983DF52@sms.ed.ac.uk>
References: <72C1FE55-E500-47DA-B5DE-831AB7119F3F@sms.ed.ac.uk>
	<D590922B-A5FB-459E-B58A-74C8D51C0369@sms.ed.ac.uk>
	<46BE599D-BAE6-47D6-A660-BBD8811FF6C3@oracle.com>
	<A89C1C43-8199-4DF8-A96E-9D79ADA898DD@sms.ed.ac.uk>
	<04453C30-7691-4C7C-8FE5-6FF636CE2711@oracle.com>
	<66066558-C469-4FF9-8C76-AFA6AC815238@oracle.com>
	<B1DF675D-1B38-4C48-9150-2D8BD34AE47A@sms.ed.ac.uk>
	<D3C3A49F-7A59-4604-8271-502EF7EA8739@oracle.com>
	<D6E7A5D4-4C33-4E5F-817B-121BC3F892B9@sms.ed.ac.uk>
	<D580B04A-5382-42AC-83FE-0D4590A35138@oracle.com>
	<F17781C1-D00A-4348-B817-6C259ECCE23F@sms.ed.ac.uk>
	<FB17EF9D-5C90-4CB3-B439-3F3E1F29EA16@oracle.com>
	<A3A6884D-4D69-4B57-B020-52942B89B0AF@sms.ed.ac.uk>
	<C2FD89C3-3353-4AD4-8C5D-6A4144F2BD2F@oracle.com>
	<A2419C2C-59CA-405C-BF2E-C21E0D3B19A2@sms.ed.ac.uk>
	<C0C4D292-7403-474B-8602-A2CCC647AFB0@oracle.com>
	<06FF4162-C221-4742-8CD0-B56D86D1E723@sms.ed.ac.uk>
	<51E42C87.1080704@oracle.com>
	<5BAB2A3B-508A-40B2-8900-EF6BF983DF52@sms.ed.ac.uk>
Message-ID: <51E44635.1020103@oracle.com>

On 7/15/13 11:38 AM, ATKIN-GRANVILLE Chris wrote:
> I can't say I've given much thought to it yet, but I will now. I've been looking at modifying bytecode using javassist/ASM to call instrumentation, but there's other issues with that (mainly being able to detect loops would be manual). If I used Maxine + VMA, would it be relatively easy to implement dynamic tracing /in a loop/ - and /only/ in a loop? This is the disadvantage of using tools as low-level as VMA - I've lost a lot of the semantic information that is available at compile time (in Graal I had does-the-operation-exist-inside-a-loop working in <5 mins).
>
>
That's an interesting requirement. There are other frameworks, e.g., 
DiSL <http://d3s.mff.cuni.cz/publications/download/Marek-aplas12.pdf>, 
that allow regions of bytecode to identified for analysis. You are 
correct that Maxine/VMA based on the T1X baseline compiler has no more 
information than the original bytecode stream, so recovering loops 
requires some work. In the simple callback model, the advice itself 
cannot be limited to the loop, you have to detect the loop bytecodes and 
only analyse the array accesses when you know you are in the loop.

Graal/VMA evidently makes this easier as more of the original source is 
available explicitly the graph. However, it is a fact that Graal was not 
designed as an analysis framework, and is somewhat lossy - for example 
the kind of loop is not kept and some transformations,e.g. 
canonicalization of the various IF forms happen before you can get 
control. Nevertheless, it is a much more robust framework and graphs are 
much preferable to bytecode streams. DiSL could be implemented on Graal, 
no doubt, perhaps with some small extensions. E.g., the bytecode index 
is not routinely available for an arbitrary node.

Mick




From mick.jordan at oracle.com  Mon Jul 15 12:12:27 2013
From: mick.jordan at oracle.com (Mick Jordan)
Date: Mon, 15 Jul 2013 12:12:27 -0700
Subject: NullPointerException in HotSpotRuntime:lower when using Snippets
In-Reply-To: <51E44635.1020103@oracle.com>
References: <72C1FE55-E500-47DA-B5DE-831AB7119F3F@sms.ed.ac.uk>
	<D590922B-A5FB-459E-B58A-74C8D51C0369@sms.ed.ac.uk>
	<46BE599D-BAE6-47D6-A660-BBD8811FF6C3@oracle.com>
	<A89C1C43-8199-4DF8-A96E-9D79ADA898DD@sms.ed.ac.uk>
	<04453C30-7691-4C7C-8FE5-6FF636CE2711@oracle.com>
	<66066558-C469-4FF9-8C76-AFA6AC815238@oracle.com>
	<B1DF675D-1B38-4C48-9150-2D8BD34AE47A@sms.ed.ac.uk>
	<D3C3A49F-7A59-4604-8271-502EF7EA8739@oracle.com>
	<D6E7A5D4-4C33-4E5F-817B-121BC3F892B9@sms.ed.ac.uk>
	<D580B04A-5382-42AC-83FE-0D4590A35138@oracle.com>
	<F17781C1-D00A-4348-B817-6C259ECCE23F@sms.ed.ac.uk>
	<FB17EF9D-5C90-4CB3-B439-3F3E1F29EA16@oracle.com>
	<A3A6884D-4D69-4B57-B020-52942B89B0AF@sms.ed.ac.uk>
	<C2FD89C3-3353-4AD4-8C5D-6A4144F2BD2F@oracle.com>
	<A2419C2C-59CA-405C-BF2E-C21E0D3B19A2@sms.ed.ac.uk>
	<C0C4D292-7403-474B-8602-A2CCC647AFB0@oracle.com>
	<06FF4162-C221-4742-8CD0-B56D86D1E723@sms.ed.ac.uk>
	<51E42C87.1080704@oracle.com>
	<5BAB2A3B-508A-40B2-8900-EF6BF983DF52@sms.ed.ac.uk>
	<51E44635.1020103@oracle.co! m>
Message-ID: <51E4499B.5050605@oracle.com>

On 7/15/13 11:57 AM, Mick Jordan wrote:
>
> Graal/VMA evidently makes this easier as more of the original source 
> is available explicitly the graph. However, it is a fact that Graal 
> was not designed as an analysis framework, and is somewhat lossy - for 
> example the kind of loop is not kept and some transformations,e.g. 
> canonicalization of the various IF forms happen before you can get 
> control. Nevertheless, it is a much more robust framework and graphs 
> are much preferable to bytecode streams. DiSL could be implemented on 
> Graal, no doubt, perhaps with some small extensions. E.g., the 
> bytecode index is not routinely available for an arbitrary node.
I should clarify that some of the lossiness is due entirely to the 
source -> bytecode translation by the (javac) compiler (e.g. loops), and 
some is due to Graal's graph building itself (e.g. the IF bytecode 
forms). Graal recreates the loops by virtue of the LoopBegin/End nodes 
and if you look at GraphBuilderPhase, you can see this requires some work.

Mick


From tom.deneau at amd.com  Mon Jul 15 14:05:13 2013
From: tom.deneau at amd.com (Deneau, Tom)
Date: Mon, 15 Jul 2013 21:05:13 +0000
Subject: graal/graal: 107 new changesets
In-Reply-To: <20130715170157.A77A4480BF@hg.openjdk.java.net>
References: <20130715170157.A77A4480BF@hg.openjdk.java.net>
Message-ID: <BC97738F8E7C8742BABED7F06FB9DF91450454E9@sausexdag01.amd.com>

Doug or others --

I was about to ask for help on a codegen problem we were seeing but after updating to the latest default,
I see that it is gone (so I'm assuming it was not in our backend :) ).  Of course it is possible that the bug
is just being hidden by some unrelated change.   Anyway, here is a brief description,
maybe you can tell which of the many changesets below would have fixed this, if any.

We were using String.contains as our test case, which was being nicely inlined, and we generated the following 
HSAIL code which led to the problem

	ld_global_u16 $s8, [$d3 + 24];         // read a u16 char from the test String
	ld_global_u16 $s9, [$d1 + 24];         // read a u16 char from the pattern  
	st_spill_s32 $s9, [%spillseg][24];     // register spill
	mov_b32 $s8, 0;                        // <<<<--- This code was causing the problem 
	cmp_ne_b1_s32 $c0, $s8, $s9;           // compare the two chars but s8 has been clobbered


When I did a -G:TraceLIRGeneratorLevel=2, I could see that the problematic instruction
 "mov_b32 $s8, 0"
was generated as part of something called
       MOVE TO PHI from 276|EndNode to 277|LoopBegin

as part of PhiResolver.dispose, the part that is commented with
  // generate move for move from non variable to arbitrary destination

Does the above sound like something that was purposely fixed?

-- 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 at oracle.com
Sent: Monday, July 15, 2013 11:56 AM
To: graal-dev at openjdk.java.net
Subject: hg: graal/graal: 107 new changesets

Changeset: 204d8d4f91a4
Author:    Christian Haeubl <haeubl at ssw.jku.at>
Date:      2013-07-09 11:18 +0200
URL:       http://hg.openjdk.java.net/graal/graal/rev/204d8d4f91a4

Minor Java fix.

! graal/com.oracle.graal.api.code/src/com/oracle/graal/api/code/Assumptions.java

Changeset: a9b76e1e5ab3
Author:    Christian Haeubl <haeubl at ssw.jku.at>
Date:      2013-07-09 11:19 +0200
URL:       http://hg.openjdk.java.net/graal/graal/rev/a9b76e1e5ab3

Fix for OSR regression introduced with 88672775a26c.

! src/share/vm/runtime/compilationPolicy.cpp

Changeset: dcee58529a1c
Author:    Christian Haeubl <haeubl at ssw.jku.at>
Date:      2013-07-09 11:21 +0200
URL:       http://hg.openjdk.java.net/graal/graal/rev/dcee58529a1c

Merge.

- graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/nodes/HotSpotNmethodExecuteNode.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/HotSpotNmethodSubstitutions.java

Changeset: 9808158cfeab
Author:    Roland Schatz <roland.schatz at oracle.com>
Date:      2013-07-09 11:14 +0200
URL:       http://hg.openjdk.java.net/graal/graal/rev/9808158cfeab

Allow foreign call stubs to be declared as leaf methods.

! graal/com.oracle.graal.hotspot.amd64/src/com/oracle/graal/hotspot/amd64/AMD64HotSpotBackend.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/ForeignCallStub.java
! graal/com.oracle.graal.lir.amd64/src/com/oracle/graal/lir/amd64/AMD64SaveRegistersOp.java

Changeset: 5348b49b2a76
Author:    Roland Schatz <roland.schatz at oracle.com>
Date:      2013-07-09 11:57 +0200
URL:       http://hg.openjdk.java.net/graal/graal/rev/5348b49b2a76

Assign framestates in snippet lowering after framestate assignment.

! graal/com.oracle.graal.replacements/src/com/oracle/graal/replacements/SnippetTemplate.java

Changeset: 110444cbf1eb
Author:    Roland Schatz <roland.schatz at oracle.com>
Date:      2013-07-09 11:58 +0200
URL:       http://hg.openjdk.java.net/graal/graal/rev/110444cbf1eb

Make FixedGuardNode a DeoptimizingNode.

! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/FixedGuardNode.java

Changeset: f11cd00d4115
Author:    Roland Schatz <roland.schatz at oracle.com>
Date:      2013-07-09 11:58 +0200
URL:       http://hg.openjdk.java.net/graal/graal/rev/f11cd00d4115

Make G1PreWriteBarrier a DeoptimizingNode.

! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/phases/WriteBarrierAdditionPhase.java
! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/WriteBarrierSnippets.java
! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/G1PreWriteBarrier.java

Changeset: 5bab3272bb82
Author:    Roland Schatz <roland.schatz at oracle.com>
Date:      2013-07-09 11:58 +0200
URL:       http://hg.openjdk.java.net/graal/graal/rev/5bab3272bb82

Make array allocations deoptimizing nodes.

! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/java/AbstractNewArrayNode.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

Changeset: 69089865435a
Author:    Roland Schatz <roland.schatz at oracle.com>
Date:      2013-07-09 11:58 +0200
URL:       http://hg.openjdk.java.net/graal/graal/rev/69089865435a

New lowering phase after framestate assignment.

! 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.nodes/src/com/oracle/graal/nodes/WriteBarrier.java
! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/spi/Lowerable.java

Changeset: e7d07c9bb779
Author:    Christian Haeubl <haeubl at ssw.jku.at>
Date:      2013-07-09 17:53 +0200
URL:       http://hg.openjdk.java.net/graal/graal/rev/e7d07c9bb779

Removed priority compilation queue.
Fixed another race condition in the compilation queue.
Removed Graal-specific compilation policy.

! 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/CompilerThread.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.phases/src/com/oracle/graal/phases/GraalOptions.java
! src/cpu/x86/vm/templateInterpreter_x86_64.cpp
! src/share/vm/classfile/vmSymbols.hpp
! src/share/vm/graal/graalCompiler.cpp
! src/share/vm/graal/graalVMToCompiler.cpp
! src/share/vm/graal/graalVMToCompiler.hpp
! src/share/vm/oops/methodCounters.cpp
! src/share/vm/oops/methodCounters.hpp
! src/share/vm/runtime/compilationPolicy.cpp

Changeset: d59e7f94f28d
Author:    Christian Haeubl <haeubl at ssw.jku.at>
Date:      2013-07-09 17:54 +0200
URL:       http://hg.openjdk.java.net/graal/graal/rev/d59e7f94f28d

Increased priority for compiler threads.

! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/CompilerThread.java

Changeset: 853a894e0d97
Author:    Christian Haeubl <haeubl at ssw.jku.at>
Date:      2013-07-09 17:55 +0200
URL:       http://hg.openjdk.java.net/graal/graal/rev/853a894e0d97

Merge.


Changeset: 41362ec88331
Author:    Thomas Wuerthinger <thomas.wuerthinger at oracle.com>
Date:      2013-07-09 14:33 +0200
URL:       http://hg.openjdk.java.net/graal/graal/rev/41362ec88331

Improve Truffle graph cache.

! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/PartialEvaluator.java
! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/TruffleCache.java

Changeset: 9db1377b0580
Author:    Thomas Wuerthinger <thomas.wuerthinger at oracle.com>
Date:      2013-07-09 17:38 +0200
URL:       http://hg.openjdk.java.net/graal/graal/rev/9db1377b0580

Fix for TruffleCache.

! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/PartialEvaluator.java
! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/TruffleCache.java
! graal/com.oracle.truffle.api/src/com/oracle/truffle/api/TruffleOptions.java
! graal/com.oracle.truffle.api/src/com/oracle/truffle/api/nodes/SlowPathException.java

Changeset: 3bbe14e492fb
Author:    Thomas Wuerthinger <thomas.wuerthinger at oracle.com>
Date:      2013-07-09 20:06 +0200
URL:       http://hg.openjdk.java.net/graal/graal/rev/3bbe14e492fb

Introduce TruffleGraphMaxNodes option with default value 10000.

! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/PartialEvaluator.java
! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/TruffleCompilerOptions.java

Changeset: 759415ed915a
Author:    Thomas Wuerthinger <thomas.wuerthinger at oracle.com>
Date:      2013-07-09 20:09 +0200
URL:       http://hg.openjdk.java.net/graal/graal/rev/759415ed915a

Merge.


Changeset: fa86a653bc0d
Author:    Andreas Woess <andreas.woess at jku.at>
Date:      2013-07-09 19:45 +0200
URL:       http://hg.openjdk.java.net/graal/graal/rev/fa86a653bc0d

Truffle: ensure frame assumption is recorded for materialized frames

! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/nodes/FrameAccessNode.java

Changeset: 0c570e82cc1d
Author:    Andreas Woess <andreas.woess at jku.at>
Date:      2013-07-09 21:03 +0200
URL:       http://hg.openjdk.java.net/graal/graal/rev/0c570e82cc1d

Truffle: minor cleanup

! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/FrameWithoutBoxing.java
! graal/com.oracle.truffle.api/src/com/oracle/truffle/api/impl/DefaultVirtualFrame.java

Changeset: 311abd52ffeb
Author:    Andreas Woess <andreas.woess at jku.at>
Date:      2013-07-09 21:20 +0200
URL:       http://hg.openjdk.java.net/graal/graal/rev/311abd52ffeb

Merge


Changeset: 725922588833
Author:    Thomas Wuerthinger <thomas.wuerthinger at oracle.com>
Date:      2013-07-09 21:53 +0200
URL:       http://hg.openjdk.java.net/graal/graal/rev/725922588833

Fix Truffle cache inlining strategy to skip exception edges.

! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/TruffleCache.java
! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/TruffleCompilerOptions.java

Changeset: ae4c79ee71d1
Author:    Thomas Wuerthinger <thomas.wuerthinger at oracle.com>
Date:      2013-07-09 22:05 +0200
URL:       http://hg.openjdk.java.net/graal/graal/rev/ae4c79ee71d1

Merge.


Changeset: 6ff467cdb105
Author:    twisti
Date:      2013-07-09 14:39 -0700
URL:       http://hg.openjdk.java.net/graal/graal/rev/6ff467cdb105

Code installer changes for SPARC.

! src/cpu/sparc/vm/graalCodeInstaller_sparc.hpp
! src/cpu/sparc/vm/sharedRuntime_sparc.cpp
! src/cpu/x86/vm/graalCodeInstaller_x86.hpp
! src/share/vm/graal/graalCodeInstaller.cpp
! src/share/vm/graal/graalCodeInstaller.hpp
! src/share/vm/prims/methodHandles.cpp

Changeset: 431eca622358
Author:    twisti
Date:      2013-07-09 15:37 -0700
URL:       http://hg.openjdk.java.net/graal/graal/rev/431eca622358

SPARC: Fixed build errors.

! src/share/vm/graal/graalCompilerToGPU.cpp
! src/share/vm/graal/graalCompilerToVM.hpp

Changeset: 73122b5edf6a
Author:    twisti
Date:      2013-07-09 15:37 -0700
URL:       http://hg.openjdk.java.net/graal/graal/rev/73122b5edf6a

SPARC: Can compile simple methods and do static calls.

! 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.asm.sparc/src/com/oracle/graal/asm/sparc/SPARCMacroAssembler.java
! graal/com.oracle.graal.compiler.sparc/src/com/oracle/graal/compiler/sparc/SPARCLIRGenerator.java
! graal/com.oracle.graal.hotspot.sparc/src/com/oracle/graal/hotspot/sparc/SPARCHotSpotBackend.java
! graal/com.oracle.graal.hotspot.sparc/src/com/oracle/graal/hotspot/sparc/SPARCHotSpotLIRGenerator.java
! graal/com.oracle.graal.hotspot.sparc/src/com/oracle/graal/hotspot/sparc/SPARCHotSpotRegisterConfig.java
+ graal/com.oracle.graal.hotspot.sparc/src/com/oracle/graal/hotspot/sparc/SPARCHotspotDirectStaticCallOp.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/SPARCCall.java
! graal/com.oracle.graal.lir.sparc/src/com/oracle/graal/lir/sparc/SPARCCompare.java
! graal/com.oracle.graal.lir.sparc/src/com/oracle/graal/lir/sparc/SPARCControlFlow.java
! graal/com.oracle.graal.lir.sparc/src/com/oracle/graal/lir/sparc/SPARCLIRInstruction.java
! graal/com.oracle.graal.lir.sparc/src/com/oracle/graal/lir/sparc/SPARCMathIntrinsicOp.java
! graal/com.oracle.graal.lir.sparc/src/com/oracle/graal/lir/sparc/SPARCMove.java
! graal/com.oracle.graal.lir.sparc/src/com/oracle/graal/lir/sparc/SPARCTestOp.java
! graal/com.oracle.graal.sparc/src/com/oracle/graal/sparc/SPARC.java

Changeset: d2055a110396
Author:    Thomas Wuerthinger <thomas.wuerthinger at oracle.com>
Date:      2013-07-10 05:26 +0200
URL:       http://hg.openjdk.java.net/graal/graal/rev/d2055a110396

Introduce CompilerDirectives.SlowPath annotation.

! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/TruffleCache.java
! graal/com.oracle.truffle.api/src/com/oracle/truffle/api/CompilerDirectives.java

Changeset: 87d2df0a7624
Author:    Thomas Wuerthinger <thomas.wuerthinger at oracle.com>
Date:      2013-07-10 05:27 +0200
URL:       http://hg.openjdk.java.net/graal/graal/rev/87d2df0a7624

Merge.


Changeset: 3ae117e62905
Author:    Christian Humer <christian.humer at gmail.com>
Date:      2013-07-10 09:23 +0200
URL:       http://hg.openjdk.java.net/graal/graal/rev/3ae117e62905

Removed frame argument for generic cases if not needed.
Added @SlowPath annotation to generated generic cases.

! graal/com.oracle.truffle.dsl.processor/src/com/oracle/truffle/dsl/processor/TruffleTypes.java
! graal/com.oracle.truffle.dsl.processor/src/com/oracle/truffle/dsl/processor/node/NodeCodeGenerator.java
! graal/com.oracle.truffle.dsl.processor/src/com/oracle/truffle/dsl/processor/node/NodeParser.java

Changeset: a0309f88306c
Author:    Christian Humer <christian.humer at gmail.com>
Date:      2013-07-10 09:42 +0200
URL:       http://hg.openjdk.java.net/graal/graal/rev/a0309f88306c

Added truffle option to enable detailed rewrite messages. Disabled by default.

! graal/com.oracle.truffle.api/src/com/oracle/truffle/api/TruffleOptions.java
! graal/com.oracle.truffle.dsl.processor/src/com/oracle/truffle/dsl/processor/TruffleTypes.java
! graal/com.oracle.truffle.dsl.processor/src/com/oracle/truffle/dsl/processor/node/NodeCodeGenerator.java

Changeset: 77b83e903703
Author:    Doug Simon <doug.simon at oracle.com>
Date:      2013-07-10 17:44 +0200
URL:       http://hg.openjdk.java.net/graal/graal/rev/77b83e903703

make use of guardingNonNull node intrinsic

! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/ArrayCopySnippets.java

Changeset: bebc9672f45e
Author:    Doug Simon <doug.simon at oracle.com>
Date:      2013-07-10 17:46 +0200
URL:       http://hg.openjdk.java.net/graal/graal/rev/bebc9672f45e

stamp for GuardingPiNode is determined by caller of constructor, not within constructor

! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/GuardingPiNode.java
! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/InliningUtil.java

Changeset: f8adf47cc05e
Author:    Doug Simon <doug.simon at oracle.com>
Date:      2013-07-10 17:46 +0200
URL:       http://hg.openjdk.java.net/graal/graal/rev/f8adf47cc05e

checkcast is lowered to instanceof (GRAAL-248)

! graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/PushNodesThroughPiTest.java
! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/java/CheckCastNode.java
! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/java/InstanceOfNode.java
! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/LoweringPhase.java
! graal/com.oracle.graal.replacements/src/com/oracle/graal/replacements/InstanceOfSnippetsTemplates.java

Changeset: 31266ceb86ef
Author:    twisti
Date:      2013-07-10 12:50 -0700
URL:       http://hg.openjdk.java.net/graal/graal/rev/31266ceb86ef

SPARC: Can compile and run two or three methods of a bootstrap.

! 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.asm.sparc/src/com/oracle/graal/asm/sparc/SPARCMacroAssembler.java
! graal/com.oracle.graal.compiler.sparc/src/com/oracle/graal/compiler/sparc/SPARCLIRGenerator.java
! graal/com.oracle.graal.hotspot.sparc/src/com/oracle/graal/hotspot/sparc/SPARCHotSpotBackend.java
! graal/com.oracle.graal.hotspot.sparc/src/com/oracle/graal/hotspot/sparc/SPARCHotSpotLIRGenerator.java
! graal/com.oracle.graal.hotspot.sparc/src/com/oracle/graal/hotspot/sparc/SPARCHotSpotRuntime.java
+ graal/com.oracle.graal.hotspot.sparc/src/com/oracle/graal/hotspot/sparc/SPARCSafepointOp.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

Changeset: 8c8e47cc101d
Author:    Christian Humer <christian.humer at gmail.com>
Date:      2013-07-11 01:55 +0200
URL:       http://hg.openjdk.java.net/graal/graal/rev/8c8e47cc101d

Truffle-DSL: fixed a bug in removal of the frame from the generated generic execute method.

! graal/com.oracle.truffle.dsl.processor/src/com/oracle/truffle/dsl/processor/node/NodeCodeGenerator.java
! graal/com.oracle.truffle.dsl.processor/src/com/oracle/truffle/dsl/processor/node/NodeData.java
! graal/com.oracle.truffle.dsl.processor/src/com/oracle/truffle/dsl/processor/node/NodeParser.java

Changeset: 062304c74353
Author:    Christian Humer <christian.humer at gmail.com>
Date:      2013-07-11 01:56 +0200
URL:       http://hg.openjdk.java.net/graal/graal/rev/062304c74353

merge.


Changeset: 5c1afcee72ec
Author:    Thomas Wuerthinger <thomas.wuerthinger at oracle.com>
Date:      2013-07-10 19:48 -0700
URL:       http://hg.openjdk.java.net/graal/graal/rev/5c1afcee72ec

Relax TruffleCache assertion.

! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/TruffleCache.java

Changeset: 4109190a0da5
Author:    Roland Schatz <roland.schatz at oracle.com>
Date:      2013-07-11 11:09 +0200
URL:       http://hg.openjdk.java.net/graal/graal/rev/4109190a0da5

Move lowering of arraycopy to the correct lowering phase.

! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/UnsafeArrayCopyNode.java

Changeset: 58cb83bfd882
Author:    Christos Kotselidis <christos.kotselidis at oracle.com>
Date:      2013-07-11 11:55 +0200
URL:       http://hg.openjdk.java.net/graal/graal/rev/58cb83bfd882

Simplify code

! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/NewObjectSnippets.java

Changeset: 2a87417379ce
Author:    Christos Kotselidis <christos.kotselidis at oracle.com>
Date:      2013-07-11 11:56 +0200
URL:       http://hg.openjdk.java.net/graal/graal/rev/2a87417379ce

Remove ternary

! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/ObjectCloneSnippets.java

Changeset: f1cd428fca9f
Author:    Christos Kotselidis <christos.kotselidis at oracle.com>
Date:      2013-07-11 11:58 +0200
URL:       http://hg.openjdk.java.net/graal/graal/rev/f1cd428fca9f

Remove caching of gcStartCycles

! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/WriteBarrierSnippets.java

Changeset: b95d42fdddca
Author:    Christos Kotselidis <christos.kotselidis at oracle.com>
Date:      2013-07-11 12:09 +0200
URL:       http://hg.openjdk.java.net/graal/graal/rev/b95d42fdddca

Minor refactoring

! src/share/vm/gc_interface/collectedHeap.hpp

Changeset: 7cdd4708b1aa
Author:    Christos Kotselidis <christos.kotselidis at oracle.com>
Date:      2013-07-11 12:10 +0200
URL:       http://hg.openjdk.java.net/graal/graal/rev/7cdd4708b1aa

Merge


Changeset: 84b944726df2
Author:    Andreas Woess <andreas.woess at jku.at>
Date:      2013-07-11 12:22 +0200
URL:       http://hg.openjdk.java.net/graal/graal/rev/84b944726df2

Truffle: introduce NodeUtil.countNodes

! graal/com.oracle.truffle.api/src/com/oracle/truffle/api/nodes/NodeUtil.java

Changeset: fd53f9f7007b
Author:    Andreas Woess <andreas.woess at jku.at>
Date:      2013-07-11 13:09 +0200
URL:       http://hg.openjdk.java.net/graal/graal/rev/fd53f9f7007b

Truffle: refactor inlining

! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/OptimizedCallTarget.java
! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/TruffleCompilerOptions.java

Changeset: 8d961f93725c
Author:    Gilles Duboscq <duboscq at ssw.jku.at>
Date:      2013-07-09 18:17 +0200
URL:       http://hg.openjdk.java.net/graal/graal/rev/8d961f93725c

Use GuardedValueNode in the inlining

! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/GuardedValueNode.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

Changeset: a643c88d164f
Author:    Gilles Duboscq <duboscq at ssw.jku.at>
Date:      2013-07-11 14:45 +0200
URL:       http://hg.openjdk.java.net/graal/graal/rev/a643c88d164f

Add scopes to capture the graphs in ReplacementsImpl

! graal/com.oracle.graal.replacements/src/com/oracle/graal/replacements/ReplacementsImpl.java

Changeset: 41e9c8845826
Author:    Gilles Duboscq <duboscq at ssw.jku.at>
Date:      2013-07-11 14:47 +0200
URL:       http://hg.openjdk.java.net/graal/graal/rev/41e9c8845826

Improve instanceof canonicalization

! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/java/InstanceOfNode.java

Changeset: 5888e1772ba1
Author:    Roland Schatz <roland.schatz at oracle.com>
Date:      2013-07-11 16:21 +0200
URL:       http://hg.openjdk.java.net/graal/graal/rev/5888e1772ba1

Check that guards are only created in BEFORE_GUARDS lowering.

! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/LoweringPhase.java

Changeset: cd28ead65a53
Author:    Roland Schatz <roland.schatz at oracle.com>
Date:      2013-07-11 16:21 +0200
URL:       http://hg.openjdk.java.net/graal/graal/rev/cd28ead65a53

Output lowering type in graph dumps.

! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/LoweringPhase.java

Changeset: 68d4d5457546
Author:    Doug Simon <doug.simon at oracle.com>
Date:      2013-07-11 20:56 +0200
URL:       http://hg.openjdk.java.net/graal/graal/rev/68d4d5457546

add sequential id prefixes to IGV graphs

! graal/com.oracle.graal.printer/src/com/oracle/graal/printer/GraphPrinterDumpHandler.java

Changeset: 7f50d79c46f2
Author:    Doug Simon <doug.simon at oracle.com>
Date:      2013-07-11 20:57 +0200
URL:       http://hg.openjdk.java.net/graal/graal/rev/7f50d79c46f2

fixed a stamp join to be done the "right" way (stamp joining is not currently commutative)

! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/java/CheckCastNode.java

Changeset: 057154505878
Author:    Doug Simon <doug.simon at oracle.com>
Date:      2013-07-11 20:58 +0200
URL:       http://hg.openjdk.java.net/graal/graal/rev/057154505878

fixed canonicalization bug (detected by Gilles) in binary logic nodes

! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/LogicConjunctionNode.java
! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/LogicConstantNode.java
! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/LogicDisjunctionNode.java

Changeset: 28dc33dc4565
Author:    Christos Kotselidis <christos.kotselidis at oracle.com>
Date:      2013-07-12 12:24 +0200
URL:       http://hg.openjdk.java.net/graal/graal/rev/28dc33dc4565

Delegate compressed klass pointers info from HotSpot to Graal

! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/HotSpotVMConfig.java
! src/share/vm/graal/graalCompilerToVM.cpp

Changeset: c3760150dc29
Author:    Christos Kotselidis <christos.kotselidis at oracle.com>
Date:      2013-07-12 12:40 +0200
URL:       http://hg.openjdk.java.net/graal/graal/rev/c3760150dc29

Add function to read compressed klass pointers of constant objects natively

! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/HotSpotGraalRuntime.java
! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/bridge/CompilerToVM.java
! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/bridge/CompilerToVMImpl.java
! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotRuntime.java
! src/share/vm/graal/graalCompilerToVM.cpp

Changeset: b975cad32411
Author:    Christos Kotselidis <christos.kotselidis at oracle.com>
Date:      2013-07-12 12:42 +0200
URL:       http://hg.openjdk.java.net/graal/graal/rev/b975cad32411

Add StoreHubNode

+ graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/extended/StoreHubNode.java

Changeset: 0517026315a0
Author:    Christos Kotselidis <christos.kotselidis at oracle.com>
Date:      2013-07-12 12:46 +0200
URL:       http://hg.openjdk.java.net/graal/graal/rev/0517026315a0

Adjust header size to compressed klass pointers

! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/HotSpotReplacementsUtil.java
! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/NewObjectSnippets.java
! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/ObjectCloneSnippets.java
! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/stubs/NewInstanceStub.java

Changeset: 0d3d300064a8
Author:    Christos Kotselidis <christos.kotselidis at oracle.com>
Date:      2013-07-12 12:47 +0200
URL:       http://hg.openjdk.java.net/graal/graal/rev/0d3d300064a8

Remove scratch register from compressed load LIR instruction (used only for testing)

! 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: 867588b3ecb4
Author:    Christos Kotselidis <christos.kotselidis at oracle.com>
Date:      2013-07-12 12:48 +0200
URL:       http://hg.openjdk.java.net/graal/graal/rev/867588b3ecb4

Variables' renaming

! graal/com.oracle.graal.lir.amd64/src/com/oracle/graal/lir/amd64/AMD64Move.java

Changeset: 7cc08d83111d
Author:    Lukas Stadler <lukas.stadler at jku.at>
Date:      2013-07-12 15:29 +0200
URL:       http://hg.openjdk.java.net/graal/graal/rev/7cc08d83111d

correctly anchor eliminated guards during ConditionalElimination

! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/ConditionalEliminationPhase.java

Changeset: 5fc4aedf7910
Author:    Lukas Stadler <lukas.stadler at jku.at>
Date:      2013-07-12 15:30 +0200
URL:       http://hg.openjdk.java.net/graal/graal/rev/5fc4aedf7910

add relative pc to uncommon trap event entry (helps debugging SEGFAULTs in copmiled code)

! src/share/vm/runtime/deoptimization.cpp

Changeset: c84048228b4a
Author:    Lukas Stadler <lukas.stadler at jku.at>
Date:      2013-07-12 17:01 +0200
URL:       http://hg.openjdk.java.net/graal/graal/rev/c84048228b4a

prevent repeated simplification of FixedGuardNode

! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/FixedGuardNode.java

Changeset: 097a634b57b1
Author:    Lukas Stadler <lukas.stadler at jku.at>
Date:      2013-07-12 11:19 +0200
URL:       http://hg.openjdk.java.net/graal/graal/rev/097a634b57b1

fix stamps for constants of boolean, byte, char and short type, add tests

+ graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/IntegerStampTest.java
! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/type/StampFactory.java

Changeset: 0e671d5268d1
Author:    Lukas Stadler <lukas.stadler at jku.at>
Date:      2013-07-11 14:57 +0200
URL:       http://hg.openjdk.java.net/graal/graal/rev/0e671d5268d1

re-introduce early read elimination as part of escape analysis

! 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/PartialEscapePhase.java
+ graal/com.oracle.graal.virtual/src/com/oracle/graal/virtual/phases/ea/ReadEliminationPEBlockState.java
+ graal/com.oracle.graal.virtual/src/com/oracle/graal/virtual/phases/ea/ReadEliminationPEClosure.java

Changeset: e35a72e32aae
Author:    Lukas Stadler <lukas.stadler at jku.at>
Date:      2013-07-11 15:13 +0200
URL:       http://hg.openjdk.java.net/graal/graal/rev/e35a72e32aae

add test for early read elimination

+ graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/ea/PEAReadEliminationTest.java

Changeset: c78097171701
Author:    Doug Simon <doug.simon at oracle.com>
Date:      2013-07-12 14:48 +0200
URL:       http://hg.openjdk.java.net/graal/graal/rev/c78097171701

made the "Remove selected graphs and groups" action work in IGV for binary graphs

! src/share/tools/IdealGraphVisualizer/Coordinator/src/com/sun/hotspot/igv/coordinator/OutlineTopComponent.java
! src/share/tools/IdealGraphVisualizer/Coordinator/src/com/sun/hotspot/igv/coordinator/actions/ImportAction.java
! src/share/tools/IdealGraphVisualizer/Data/src/com/sun/hotspot/igv/data/serialization/BinaryParser.java
! src/share/tools/IdealGraphVisualizer/NetworkConnection/src/com/sun/hotspot/igv/connection/Client.java
! src/share/tools/IdealGraphVisualizer/NetworkConnection/src/com/sun/hotspot/igv/connection/Server.java

Changeset: 9d079661cbcd
Author:    Doug Simon <doug.simon at oracle.com>
Date:      2013-07-12 18:08 +0200
URL:       http://hg.openjdk.java.net/graal/graal/rev/9d079661cbcd

fixed generation of sequential id prefixes for IGV graphs

! graal/com.oracle.graal.printer/src/com/oracle/graal/printer/GraphPrinterDumpHandler.java

Changeset: 70cb17338a70
Author:    Doug Simon <doug.simon at oracle.com>
Date:      2013-07-12 18:09 +0200
URL:       http://hg.openjdk.java.net/graal/graal/rev/70cb17338a70

Merge.


Changeset: 2a4ad6ab345e
Author:    Doug Simon <doug.simon at oracle.com>
Date:      2013-07-12 19:09 +0200
URL:       http://hg.openjdk.java.net/graal/graal/rev/2a4ad6ab345e

disabled new lowering of checkcast until performance regression is fixed

! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/java/CheckCastNode.java

Changeset: f1904749e4fe
Author:    Doug Simon <doug.simon at oracle.com>
Date:      2013-07-12 22:52 +0200
URL:       http://hg.openjdk.java.net/graal/graal/rev/f1904749e4fe

re-enabled new lowering of checkcast with addition of a null-check guard where the profile has nullSeen=FALSE

! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/java/CheckCastNode.java

Changeset: 40f6bda3f91d
Author:    Christos Kotselidis <christos.kotselidis at oracle.com>
Date:      2013-07-12 14:16 +0200
URL:       http://hg.openjdk.java.net/graal/graal/rev/40f6bda3f91d

Add compressed klass pointers support in LIR

! 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: 0bd794eb8222
Author:    Christos Kotselidis <christos.kotselidis at oracle.com>
Date:      2013-07-12 14:17 +0200
URL:       http://hg.openjdk.java.net/graal/graal/rev/0bd794eb8222

Add compressed oop support in HotSpot Backend

! graal/com.oracle.graal.hotspot.amd64/src/com/oracle/graal/hotspot/amd64/AMD64HotSpotBackend.java

Changeset: 6621bc66bfa4
Author:    Christos Kotselidis <christos.kotselidis at oracle.com>
Date:      2013-07-12 14:20 +0200
URL:       http://hg.openjdk.java.net/graal/graal/rev/6621bc66bfa4

Add WriteHubNode lowering

! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotRuntime.java

Changeset: 8b8587c32812
Author:    Christos Kotselidis <christos.kotselidis at oracle.com>
Date:      2013-07-12 14:38 +0200
URL:       http://hg.openjdk.java.net/graal/graal/rev/8b8587c32812

Adjust load/store hub intrinsics to account for Compressed Klass pointers

! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/HotSpotReplacementsUtil.java

Changeset: 49a0bd6b0605
Author:    Christos Kotselidis <christos.kotselidis at oracle.com>
Date:      2013-07-12 14:40 +0200
URL:       http://hg.openjdk.java.net/graal/graal/rev/49a0bd6b0605

Delegate compressed klass pointers info to ReadNode of LoadHubNode

! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotRuntime.java

Changeset: 90b3cf36dc17
Author:    Christos Kotselidis <christos.kotselidis at oracle.com>
Date:      2013-07-12 14:43 +0200
URL:       http://hg.openjdk.java.net/graal/graal/rev/90b3cf36dc17

Replace direct read word with loadHub intrinsic in VerifyOop stub

! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/stubs/StubUtil.java

Changeset: 060f9ed42e2f
Author:    Christos Kotselidis <christos.kotselidis at oracle.com>
Date:      2013-07-12 14:58 +0200
URL:       http://hg.openjdk.java.net/graal/graal/rev/060f9ed42e2f

Augment compressed oop tests

! graal/com.oracle.graal.hotspot.test/src/com/oracle/graal/hotspot/test/CompressedOopTest.java

Changeset: 88992c295d47
Author:    Christos Kotselidis <christos.kotselidis at oracle.com>
Date:      2013-07-12 20:19 +0200
URL:       http://hg.openjdk.java.net/graal/graal/rev/88992c295d47

Merge


Changeset: cdbfff4547be
Author:    Christos Kotselidis <christos.kotselidis at oracle.com>
Date:      2013-07-12 21:48 +0200
URL:       http://hg.openjdk.java.net/graal/graal/rev/cdbfff4547be

Allow compressed klass pointers

! src/share/vm/runtime/arguments.cpp

Changeset: bdd7c8e2293e
Author:    Christos Kotselidis <christos.kotselidis at oracle.com>
Date:      2013-07-12 23:26 +0200
URL:       http://hg.openjdk.java.net/graal/graal/rev/bdd7c8e2293e

Merge


Changeset: 00a9dbcbe431
Author:    Christian Humer <christian.humer at gmail.com>
Date:      2013-07-13 17:13 +0200
URL:       http://hg.openjdk.java.net/graal/graal/rev/00a9dbcbe431

Truffle-DSL: Fixed a bug in polymorphic code generation.

! graal/com.oracle.truffle.dsl.processor/src/com/oracle/truffle/dsl/processor/node/NodeCodeGenerator.java

Changeset: 99789440ce28
Author:    Christian Humer <christian.humer at gmail.com>
Date:      2013-07-13 17:14 +0200
URL:       http://hg.openjdk.java.net/graal/graal/rev/99789440ce28

Truffle: Added assertions to replaceChild.

! graal/com.oracle.truffle.api/src/com/oracle/truffle/api/nodes/NodeUtil.java

Changeset: ff6eb563a2e2
Author:    Christian Humer <christian.humer at gmail.com>
Date:      2013-07-13 17:21 +0200
URL:       http://hg.openjdk.java.net/graal/graal/rev/ff6eb563a2e2

Truffle-DSL: Added additional test case for polymporphic generation.

+ graal/com.oracle.truffle.api.dsl.test/src/com/oracle/truffle/api/dsl/test/PolymorphicTest2.java

Changeset: 45dc193567c2
Author:    Christos Kotselidis <christos.kotselidis at oracle.com>
Date:      2013-07-15 10:48 +0200
URL:       http://hg.openjdk.java.net/graal/graal/rev/45dc193567c2

Add assertions

! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotRuntime.java

Changeset: cbaf26740df8
Author:    Christos Kotselidis <christos.kotselidis at oracle.com>
Date:      2013-07-15 10:50 +0200
URL:       http://hg.openjdk.java.net/graal/graal/rev/cbaf26740df8

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/NewObjectSnippets.java
! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/ObjectCloneSnippets.java
! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/stubs/NewInstanceStub.java

Changeset: 257e2455270e
Author:    Christos Kotselidis <christos.kotselidis at oracle.com>
Date:      2013-07-15 10:59 +0200
URL:       http://hg.openjdk.java.net/graal/graal/rev/257e2455270e

Merge


Changeset: 3811d04d933e
Author:    Roland Schatz <roland.schatz at oracle.com>
Date:      2013-07-15 12:02 +0200
URL:       http://hg.openjdk.java.net/graal/graal/rev/3811d04d933e

Do not re-compress oops that are already compressed.

! graal/com.oracle.graal.hotspot.amd64/src/com/oracle/graal/hotspot/amd64/AMD64HotSpotLIRGenerator.java

Changeset: a5c9bc1f28fb
Author:    Lukas Stadler <lukas.stadler at jku.at>
Date:      2013-07-15 13:11 +0200
URL:       http://hg.openjdk.java.net/graal/graal/rev/a5c9bc1f28fb

fix nullness for not-equals in ConditionalEliminationPhase
bug reported by Miguel Garcia <miguelalfredo.garcia at epfl.ch>

! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/ConditionalEliminationPhase.java

Changeset: e7c0658c2f25
Author:    Lukas Stadler <lukas.stadler at jku.at>
Date:      2013-07-15 13:36 +0200
URL:       http://hg.openjdk.java.net/graal/graal/rev/e7c0658c2f25

record disjunctive conditions in ConditionalEliminationPhase
change suggested by Miguel Garcia <miguelalfredo.garcia at epfl.ch>

! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/ConditionalEliminationPhase.java

Changeset: 9f5a4074e36b
Author:    Lukas Stadler <lukas.stadler at jku.at>
Date:      2013-07-15 13:36 +0200
URL:       http://hg.openjdk.java.net/graal/graal/rev/9f5a4074e36b

test for nullness and disjunctive conditions in ConditionalEliminationPhase

! graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/ConditionalEliminationTest.java

Changeset: 7b5d7c42598b
Author:    Andreas Woess <andreas.woess at jku.at>
Date:      2013-07-11 19:34 +0200
URL:       http://hg.openjdk.java.net/graal/graal/rev/7b5d7c42598b

Truffle: change sorting of inlinable call sites

! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/OptimizedCallTarget.java

Changeset: e2f5ae9afdc5
Author:    Andreas Woess <andreas.woess at jku.at>
Date:      2013-07-11 22:14 +0200
URL:       http://hg.openjdk.java.net/graal/graal/rev/e2f5ae9afdc5

Truffle: introduce profiling option

! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/GraalTruffleRuntime.java
! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/OptimizedCallTarget.java
! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/TruffleCompilerOptions.java

Changeset: 64740220db85
Author:    Andreas Woess <andreas.woess at jku.at>
Date:      2013-07-15 14:09 +0200
URL:       http://hg.openjdk.java.net/graal/graal/rev/64740220db85

Merge


Changeset: 4c12d3756015
Author:    Andreas Woess <andreas.woess at jku.at>
Date:      2013-07-15 14:12 +0200
URL:       http://hg.openjdk.java.net/graal/graal/rev/4c12d3756015

Truffle: Never compile InvalidInstalledCodeException catch handler.

! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/TruffleCompilerImpl.java

Changeset: b221e31d7b0b
Author:    Andreas Woess <andreas.woess at jku.at>
Date:      2013-07-15 15:26 +0200
URL:       http://hg.openjdk.java.net/graal/graal/rev/b221e31d7b0b

Truffle: revise NodeUtil.replaceChild assertion

! graal/com.oracle.truffle.api/src/com/oracle/truffle/api/nodes/NodeUtil.java

Changeset: 7f6580db1e88
Author:    Andreas Woess <andreas.woess at jku.at>
Date:      2013-07-15 14:49 +0200
URL:       http://hg.openjdk.java.net/graal/graal/rev/7f6580db1e88

Truffle: add assertions to verify the finalness of child fields.

! graal/com.oracle.truffle.api.test/src/com/oracle/truffle/api/test/ReplaceTest.java
! graal/com.oracle.truffle.api/src/com/oracle/truffle/api/nodes/NodeUtil.java

Changeset: f4f46b734a4c
Author:    Andreas Woess <andreas.woess at jku.at>
Date:      2013-07-15 15:29 +0200
URL:       http://hg.openjdk.java.net/graal/graal/rev/f4f46b734a4c

Merge


Changeset: e82c28e94f08
Author:    Roland Schatz <roland.schatz at oracle.com>
Date:      2013-07-15 16:24 +0200
URL:       http://hg.openjdk.java.net/graal/graal/rev/e82c28e94f08

Don't add G1 prebarrier if the written location is uninitialized.

! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/phases/WriteBarrierAdditionPhase.java
! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/UnsafeArrayCopyNode.java
! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/extended/ArrayRangeWriteNode.java
! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/extended/WriteNode.java

Changeset: 7f186f1486f7
Author:    Roland Schatz <roland.schatz at oracle.com>
Date:      2013-07-15 16:24 +0200
URL:       http://hg.openjdk.java.net/graal/graal/rev/7f186f1486f7

Use initializing write node in object clone snippets.

! 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: 59d2d6a30d29
Author:    Roland Schatz <roland.schatz at oracle.com>
Date:      2013-07-15 16:24 +0200
URL:       http://hg.openjdk.java.net/graal/graal/rev/59d2d6a30d29

Re-enable omission of array initialization for G1.

! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/NewObjectSnippets.java
! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/ObjectCloneSnippets.java

Changeset: dd7a8807378b
Author:    Doug Simon <doug.simon at oracle.com>
Date:      2013-07-15 16:53 +0200
URL:       http://hg.openjdk.java.net/graal/graal/rev/dd7a8807378b

cannot omit frame for compiled methods that make a foreign call (GRAAL-362)

! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/gen/LIRGenerator.java
! graal/com.oracle.graal.hotspot.amd64/src/com/oracle/graal/hotspot/amd64/AMD64HotSpotBackend.java

Changeset: c483912aaf70
Author:    Lukas Stadler <lukas.stadler at jku.at>
Date:      2013-07-15 16:39 +0200
URL:       http://hg.openjdk.java.net/graal/graal/rev/c483912aaf70

add ValueProxy interface and infrastructure

! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/GuardedValueNode.java
! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/GuardingPiNode.java
! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/PiNode.java
! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/ProxyNode.java
! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/TypeProfileProxyNode.java
! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/java/CheckCastNode.java
+ graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/spi/ValueProxy.java
! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/util/GraphUtil.java

Changeset: 5e338844c64c
Author:    Lukas Stadler <lukas.stadler at jku.at>
Date:      2013-07-15 15:58 +0200
URL:       http://hg.openjdk.java.net/graal/graal/rev/5e338844c64c

make early read elimination see through ValueProxies

! graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/ea/PEAReadEliminationTest.java
! graal/com.oracle.graal.virtual/src/com/oracle/graal/virtual/phases/ea/ReadEliminationPEClosure.java

Changeset: d2f8addaf504
Author:    Lukas Stadler <lukas.stadler at jku.at>
Date:      2013-07-15 15:58 +0200
URL:       http://hg.openjdk.java.net/graal/graal/rev/d2f8addaf504

assertion in GraalCompiler (don't parse @Test methods)

! graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/GraalCompilerTest.java

Changeset: ae3d070ab223
Author:    Lukas Stadler <lukas.stadler at jku.at>
Date:      2013-07-15 16:36 +0200
URL:       http://hg.openjdk.java.net/graal/graal/rev/ae3d070ab223

make ValueNode.stamp() final, fix WordTypeRewriterPhase

! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/ProxyNode.java
! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/TypeProfileProxyNode.java
! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/ValueNode.java
! graal/com.oracle.graal.word/src/com/oracle/graal/word/phases/WordTypeRewriterPhase.java

Changeset: 3a044e575466
Author:    Lukas Stadler <lukas.stadler at jku.at>
Date:      2013-07-15 17:32 +0200
URL:       http://hg.openjdk.java.net/graal/graal/rev/3a044e575466

add ValueProxy interface to FixedValueAnchorNode

! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/nodes/FixedValueAnchorNode.java

Changeset: 88d0dc388450
Author:    Lukas Stadler <lukas.stadler at jku.at>
Date:      2013-07-15 17:52 +0200
URL:       http://hg.openjdk.java.net/graal/graal/rev/88d0dc388450

let ConditionalEliminationPhase change invokes to InvokeKind.Special based on type information

! 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: 058abc2b59a5
Author:    Lukas Stadler <lukas.stadler at jku.at>
Date:      2013-07-15 17:54 +0200
URL:       http://hg.openjdk.java.net/graal/graal/rev/058abc2b59a5

Merge

! graal/com.oracle.graal.word/src/com/oracle/graal/word/phases/WordTypeRewriterPhase.java

Changeset: 395d34c10e26
Author:    Doug Simon <doug.simon at oracle.com>
Date:      2013-07-15 18:22 +0200
URL:       http://hg.openjdk.java.net/graal/graal/rev/395d34c10e26

HSAIL backend changes
Contributed-by: Tom Deneau <tom.deneau at amd.com>

* stackslot mapping was incorrect when combinations of 32-bit and
 64-bit stores were generated.  StackSlot alignment in
 HSAILTargetDescription set to 8.

* compressedOops support in various heap size configurations (with or
 without either of shift or heap base).  So we don't need
 XX:-UseCompressedOops anymore.

* some support for unsigned shifts, long shifts, logical ops for long
 datatype.

* a new GraalOption, InlineEverything.  Some HSAIL targets are not
 able to handle HSAIL function calls yet, plus we are still working
 on emitting HSAIL function calls in the compiler.

* hack for emitForeignCall special cases of createOutOfBoundsException
 or createNullPointerException.  (We just emit a comment.  Real
 exception handling still pending).  These nodes came about when we
 more aggressively inlined, although this has not been explained yet.

* support HSAILAddressValues as operands for arithmetic ops.  Use
 HSAIL lda instruction to get address into a register.  Used in
 particular for USHR for card-marking.

* Added some new junit tests. (some ported from their lambda versions)

  * StaticNBodyCallTest which would fail with default inlining (since
    we don't yet generate HSAIL calls).  It uses junit.assumeTrue and
    tests whether InlineEverything is set.  It (and also some
    lambda-based junit tests not part of this webrev) do pass nicely
    when InlineEverything is set true.

  * tests for storing an object, which test being able to handle the
    card-marking logic, as well as the encoding and decoding of a
    compressed oop.

  * some 2D matrix tests that showed a problem before the stackslot
    change above.  (have a mixture of 32-bit and 64-bit stackslot
    spills)

! graal/com.oracle.graal.asm.hsail/src/com/oracle/graal/asm/hsail/HSAILAssembler.java
! graal/com.oracle.graal.compiler.hsail.test.infra/src/com/oracle/graal/compiler/hsail/test/infra/GraalKernelTester.java
! graal/com.oracle.graal.compiler.hsail.test.infra/src/com/oracle/graal/compiler/hsail/test/infra/KernelTester.java
+ graal/com.oracle.graal.compiler.hsail.test/src/com/oracle/graal/compiler/hsail/test/Float2DMatrixBase.java
+ graal/com.oracle.graal.compiler.hsail.test/src/com/oracle/graal/compiler/hsail/test/Float2DMatrixMultiplyRangeFinalTest.java
+ graal/com.oracle.graal.compiler.hsail.test/src/com/oracle/graal/compiler/hsail/test/Float2DMatrixMultiplyTest.java
+ graal/com.oracle.graal.compiler.hsail.test/src/com/oracle/graal/compiler/hsail/test/ObjectStoreNullTest.java
+ graal/com.oracle.graal.compiler.hsail.test/src/com/oracle/graal/compiler/hsail/test/ObjectStoreTest.java
! graal/com.oracle.graal.compiler.hsail.test/src/com/oracle/graal/compiler/hsail/test/StaticMandelTest.java
+ graal/com.oracle.graal.compiler.hsail.test/src/com/oracle/graal/compiler/hsail/test/StaticNBodyCallTest.java
! graal/com.oracle.graal.compiler.hsail/src/com/oracle/graal/compiler/hsail/HSAILCompilationResult.java
! graal/com.oracle.graal.compiler.hsail/src/com/oracle/graal/compiler/hsail/HSAILLIRGenerator.java
! graal/com.oracle.graal.lir.hsail/src/com/oracle/graal/lir/hsail/HSAILArithmetic.java
! graal/com.oracle.graal.lir.hsail/src/com/oracle/graal/lir/hsail/HSAILControlFlow.java
! graal/com.oracle.graal.lir.hsail/src/com/oracle/graal/lir/hsail/HSAILMove.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




From s1255753 at sms.ed.ac.uk  Tue Jul 16 05:22:15 2013
From: s1255753 at sms.ed.ac.uk (ATKIN-GRANVILLE Chris)
Date: Tue, 16 Jul 2013 12:22:15 +0000
Subject: Modifying graph to include InvokeNode
Message-ID: <917C3B2B-52B0-4B9F-A3A4-FAB598A2EA29@sms.ed.ac.uk>

Hi there,

I'm trying to modify the graph to include an invoke node to a static function after certain node types. I'm modifying the graph at a high level before LoweringPhase.class (not a requirement, can change if required). However, I'm running into issues with JVM fatal errors. The code I have at the moment looks like this:

public class MyPhase extends Phase {
	public void run(StructuredGraph graph) {
		for (Node node: graph.getNode()) {

			if ( node instanceof RandomFixedNode) {
				RandomFixedNode rfm = (RandomFixedNode) node;
				
				try {
					ResolvedJavaMethod method = getMethod(?);
					MethodCallTargetMode callTarget = graph.add(new MethodCallTargetNode(MethodCallTargetNode.InvokeKind.Static,
						method, new ValueNode[] {}, new HotSpotResolvedPrimitiveType(Kind.Void)));

					InvokeNode invoke = graph.add(new InvokeNode(callTarget, FrameState.UNKNOWN_BCI));
					invoke.setStateAfter(graph.add(new FrameState(FrameState.UNKNOWN_BCI)));
					graph.addAfterFixed(rfm, invoke);
				
				} catch (Exception e) {
					e.printStackTrace();
				} 
			}

		}
	}
}

I'm pretty sure the problem is do with the BCIs and/or the FrameStates, but I don't know how to fix it. The error that I get is:

Internal Error (/Volumes/Acme/Development/graal/src/share/vm/graal/graalCompilerToVM.cpp:44), pid=8466, tid=5379
assert(hotspot_method != NULL && hotspot_method->is_a(HotSpotResolvedJavaMethod::klass())) failed: sanity

Does anyone have any ideas?

Thanks, Chris

-- 
The University of Edinburgh is a charitable body, registered in
Scotland, with registration number SC005336.


From s1255753 at sms.ed.ac.uk  Tue Jul 16 05:31:29 2013
From: s1255753 at sms.ed.ac.uk (ATKIN-GRANVILLE Chris)
Date: Tue, 16 Jul 2013 12:31:29 +0000
Subject: Modifying graph to include InvokeNode
In-Reply-To: <917C3B2B-52B0-4B9F-A3A4-FAB598A2EA29@sms.ed.ac.uk>
References: <917C3B2B-52B0-4B9F-A3A4-FAB598A2EA29@sms.ed.ac.uk>
Message-ID: <2C535DCE-1EE9-4A83-987B-14BA2A5E4A1C@sms.ed.ac.uk>

I forgot to mention that I have disabled inlining, via PhasePlan.disablePhase(InliningPhase.class);. 

On 16 Jul 2013, at 13:22, ATKIN-GRANVILLE Chris <s1255753 at sms.ed.ac.uk>
 wrote:

> Hi there,
> 
> I'm trying to modify the graph to include an invoke node to a static function after certain node types. I'm modifying the graph at a high level before LoweringPhase.class (not a requirement, can change if required). However, I'm running into issues with JVM fatal errors. The code I have at the moment looks like this:
> 
> public class MyPhase extends Phase {
> 	public void run(StructuredGraph graph) {
> 		for (Node node: graph.getNode()) {
> 
> 			if ( node instanceof RandomFixedNode) {
> 				RandomFixedNode rfm = (RandomFixedNode) node;
> 				
> 				try {
> 					ResolvedJavaMethod method = getMethod(?);
> 					MethodCallTargetMode callTarget = graph.add(new MethodCallTargetNode(MethodCallTargetNode.InvokeKind.Static,
> 						method, new ValueNode[] {}, new HotSpotResolvedPrimitiveType(Kind.Void)));
> 
> 					InvokeNode invoke = graph.add(new InvokeNode(callTarget, FrameState.UNKNOWN_BCI));
> 					invoke.setStateAfter(graph.add(new FrameState(FrameState.UNKNOWN_BCI)));
> 					graph.addAfterFixed(rfm, invoke);
> 				
> 				} catch (Exception e) {
> 					e.printStackTrace();
> 				} 
> 			}
> 
> 		}
> 	}
> }
> 
> I'm pretty sure the problem is do with the BCIs and/or the FrameStates, but I don't know how to fix it. The error that I get is:
> 
> Internal Error (/Volumes/Acme/Development/graal/src/share/vm/graal/graalCompilerToVM.cpp:44), pid=8466, tid=5379
> assert(hotspot_method != NULL && hotspot_method->is_a(HotSpotResolvedJavaMethod::klass())) failed: sanity
> 
> Does anyone have any ideas?
> 
> Thanks, Chris
> 
> -- 
> The University of Edinburgh is a charitable body, registered in
> Scotland, with registration number SC005336.
> 
> 



-- 
The University of Edinburgh is a charitable body, registered in
Scotland, with registration number SC005336.


From doug.simon at oracle.com  Tue Jul 16 06:14:07 2013
From: doug.simon at oracle.com (Doug Simon)
Date: Tue, 16 Jul 2013 15:14:07 +0200
Subject: Modifying graph to include InvokeNode
In-Reply-To: <917C3B2B-52B0-4B9F-A3A4-FAB598A2EA29@sms.ed.ac.uk>
References: <917C3B2B-52B0-4B9F-A3A4-FAB598A2EA29@sms.ed.ac.uk>
Message-ID: <920EF6F2-121B-4723-A760-9CA7FACC33D0@oracle.com>

This is almost certainly due to the fact that an invoke node must be associated with the BCI of a real invoke bytecode instruction. Otherwise, where would the interpreter resume if there is a deoptimization  during the invocation?

On Jul 16, 2013, at 2:22 PM, ATKIN-GRANVILLE Chris <s1255753 at sms.ed.ac.uk> wrote:

> Hi there,
> 
> I'm trying to modify the graph to include an invoke node to a static function after certain node types. I'm modifying the graph at a high level before LoweringPhase.class (not a requirement, can change if required). However, I'm running into issues with JVM fatal errors. The code I have at the moment looks like this:
> 
> public class MyPhase extends Phase {
> 	public void run(StructuredGraph graph) {
> 		for (Node node: graph.getNode()) {
> 
> 			if ( node instanceof RandomFixedNode) {
> 				RandomFixedNode rfm = (RandomFixedNode) node;
> 				
> 				try {
> 					ResolvedJavaMethod method = getMethod(?);
> 					MethodCallTargetMode callTarget = graph.add(new MethodCallTargetNode(MethodCallTargetNode.InvokeKind.Static,
> 						method, new ValueNode[] {}, new HotSpotResolvedPrimitiveType(Kind.Void)));
> 
> 					InvokeNode invoke = graph.add(new InvokeNode(callTarget, FrameState.UNKNOWN_BCI));
> 					invoke.setStateAfter(graph.add(new FrameState(FrameState.UNKNOWN_BCI)));
> 					graph.addAfterFixed(rfm, invoke);
> 				
> 				} catch (Exception e) {
> 					e.printStackTrace();
> 				} 
> 			}
> 
> 		}
> 	}
> }
> 
> I'm pretty sure the problem is do with the BCIs and/or the FrameStates, but I don't know how to fix it. The error that I get is:
> 
> Internal Error (/Volumes/Acme/Development/graal/src/share/vm/graal/graalCompilerToVM.cpp:44), pid=8466, tid=5379
> assert(hotspot_method != NULL && hotspot_method->is_a(HotSpotResolvedJavaMethod::klass())) failed: sanity
> 
> Does anyone have any ideas?
> 
> Thanks, Chris
> 
> -- 
> The University of Edinburgh is a charitable body, registered in
> Scotland, with registration number SC005336.
> 


From s1255753 at sms.ed.ac.uk  Tue Jul 16 06:19:48 2013
From: s1255753 at sms.ed.ac.uk (ATKIN-GRANVILLE Chris)
Date: Tue, 16 Jul 2013 13:19:48 +0000
Subject: Modifying graph to include InvokeNode
In-Reply-To: <920EF6F2-121B-4723-A760-9CA7FACC33D0@oracle.com>
References: <917C3B2B-52B0-4B9F-A3A4-FAB598A2EA29@sms.ed.ac.uk>
	<920EF6F2-121B-4723-A760-9CA7FACC33D0@oracle.com>
Message-ID: <C0E75C84-C04F-42CB-892E-C66E8D649EE8@sms.ed.ac.uk>

Is it not possible to somehow "get" that BCI? It doesn't seem like adding static method calls should be impossible when graph transformations are possible...

On 16 Jul 2013, at 14:14, Doug Simon <doug.simon at oracle.com>
 wrote:

> This is almost certainly due to the fact that an invoke node must be associated with the BCI of a real invoke bytecode instruction. Otherwise, where would the interpreter resume if there is a deoptimization  during the invocation?
> 
> On Jul 16, 2013, at 2:22 PM, ATKIN-GRANVILLE Chris <s1255753 at sms.ed.ac.uk> wrote:
> 
>> Hi there,
>> 
>> I'm trying to modify the graph to include an invoke node to a static function after certain node types. I'm modifying the graph at a high level before LoweringPhase.class (not a requirement, can change if required). However, I'm running into issues with JVM fatal errors. The code I have at the moment looks like this:
>> 
>> public class MyPhase extends Phase {
>> 	public void run(StructuredGraph graph) {
>> 		for (Node node: graph.getNode()) {
>> 
>> 			if ( node instanceof RandomFixedNode) {
>> 				RandomFixedNode rfm = (RandomFixedNode) node;
>> 				
>> 				try {
>> 					ResolvedJavaMethod method = getMethod(?);
>> 					MethodCallTargetMode callTarget = graph.add(new MethodCallTargetNode(MethodCallTargetNode.InvokeKind.Static,
>> 						method, new ValueNode[] {}, new HotSpotResolvedPrimitiveType(Kind.Void)));
>> 
>> 					InvokeNode invoke = graph.add(new InvokeNode(callTarget, FrameState.UNKNOWN_BCI));
>> 					invoke.setStateAfter(graph.add(new FrameState(FrameState.UNKNOWN_BCI)));
>> 					graph.addAfterFixed(rfm, invoke);
>> 				
>> 				} catch (Exception e) {
>> 					e.printStackTrace();
>> 				} 
>> 			}
>> 
>> 		}
>> 	}
>> }
>> 
>> I'm pretty sure the problem is do with the BCIs and/or the FrameStates, but I don't know how to fix it. The error that I get is:
>> 
>> Internal Error (/Volumes/Acme/Development/graal/src/share/vm/graal/graalCompilerToVM.cpp:44), pid=8466, tid=5379
>> assert(hotspot_method != NULL && hotspot_method->is_a(HotSpotResolvedJavaMethod::klass())) failed: sanity
>> 
>> Does anyone have any ideas?
>> 
>> Thanks, Chris
>> 
>> -- 
>> The University of Edinburgh is a charitable body, registered in
>> Scotland, with registration number SC005336.
>> 
> 
> 



-- 
The University of Edinburgh is a charitable body, registered in
Scotland, with registration number SC005336.


From s1255753 at sms.ed.ac.uk  Tue Jul 16 06:27:06 2013
From: s1255753 at sms.ed.ac.uk (ATKIN-GRANVILLE Chris)
Date: Tue, 16 Jul 2013 13:27:06 +0000
Subject: Modifying graph to include InvokeNode
In-Reply-To: <C0E75C84-C04F-42CB-892E-C66E8D649EE8@sms.ed.ac.uk>
References: <917C3B2B-52B0-4B9F-A3A4-FAB598A2EA29@sms.ed.ac.uk>
	<920EF6F2-121B-4723-A760-9CA7FACC33D0@oracle.com>
	<C0E75C84-C04F-42CB-892E-C66E8D649EE8@sms.ed.ac.uk>
Message-ID: <E2C4ACBD-0501-4E9A-A919-888C6BC04BE6@sms.ed.ac.uk>

Oh, that may have been a silly thing to say, I know you can't "get" the BCI of a method call that doesn't exist in the bytecode. Even still, it seems like quite a large omission from graal to not be able to add static method calls into a graph...

On 16 Jul 2013, at 14:19, ATKIN-GRANVILLE Chris <s1255753 at sms.ed.ac.uk>
 wrote:

> Is it not possible to somehow "get" that BCI? It doesn't seem like adding static method calls should be impossible when graph transformations are possible...
> 
> On 16 Jul 2013, at 14:14, Doug Simon <doug.simon at oracle.com>
> wrote:
> 
>> This is almost certainly due to the fact that an invoke node must be associated with the BCI of a real invoke bytecode instruction. Otherwise, where would the interpreter resume if there is a deoptimization  during the invocation?
>> 
>> On Jul 16, 2013, at 2:22 PM, ATKIN-GRANVILLE Chris <s1255753 at sms.ed.ac.uk> wrote:
>> 
>>> Hi there,
>>> 
>>> I'm trying to modify the graph to include an invoke node to a static function after certain node types. I'm modifying the graph at a high level before LoweringPhase.class (not a requirement, can change if required). However, I'm running into issues with JVM fatal errors. The code I have at the moment looks like this:
>>> 
>>> public class MyPhase extends Phase {
>>> 	public void run(StructuredGraph graph) {
>>> 		for (Node node: graph.getNode()) {
>>> 
>>> 			if ( node instanceof RandomFixedNode) {
>>> 				RandomFixedNode rfm = (RandomFixedNode) node;
>>> 				
>>> 				try {
>>> 					ResolvedJavaMethod method = getMethod(?);
>>> 					MethodCallTargetMode callTarget = graph.add(new MethodCallTargetNode(MethodCallTargetNode.InvokeKind.Static,
>>> 						method, new ValueNode[] {}, new HotSpotResolvedPrimitiveType(Kind.Void)));
>>> 
>>> 					InvokeNode invoke = graph.add(new InvokeNode(callTarget, FrameState.UNKNOWN_BCI));
>>> 					invoke.setStateAfter(graph.add(new FrameState(FrameState.UNKNOWN_BCI)));
>>> 					graph.addAfterFixed(rfm, invoke);
>>> 				
>>> 				} catch (Exception e) {
>>> 					e.printStackTrace();
>>> 				} 
>>> 			}
>>> 
>>> 		}
>>> 	}
>>> }
>>> 
>>> I'm pretty sure the problem is do with the BCIs and/or the FrameStates, but I don't know how to fix it. The error that I get is:
>>> 
>>> Internal Error (/Volumes/Acme/Development/graal/src/share/vm/graal/graalCompilerToVM.cpp:44), pid=8466, tid=5379
>>> assert(hotspot_method != NULL && hotspot_method->is_a(HotSpotResolvedJavaMethod::klass())) failed: sanity
>>> 
>>> Does anyone have any ideas?
>>> 
>>> Thanks, Chris
>>> 
>>> -- 
>>> The University of Edinburgh is a charitable body, registered in
>>> Scotland, with registration number SC005336.
>>> 
>> 
>> 
> 
> 
> 
> -- 
> The University of Edinburgh is a charitable body, registered in
> Scotland, with registration number SC005336.
> 
> 



-- 
The University of Edinburgh is a charitable body, registered in
Scotland, with registration number SC005336.


From doug.simon at oracle.com  Tue Jul 16 06:43:03 2013
From: doug.simon at oracle.com (Doug Simon)
Date: Tue, 16 Jul 2013 15:43:03 +0200
Subject: Modifying graph to include InvokeNode
In-Reply-To: <E2C4ACBD-0501-4E9A-A919-888C6BC04BE6@sms.ed.ac.uk>
References: <917C3B2B-52B0-4B9F-A3A4-FAB598A2EA29@sms.ed.ac.uk>
	<920EF6F2-121B-4723-A760-9CA7FACC33D0@oracle.com>
	<C0E75C84-C04F-42CB-892E-C66E8D649EE8@sms.ed.ac.uk>
	<E2C4ACBD-0501-4E9A-A919-888C6BC04BE6@sms.ed.ac.uk>
Message-ID: <50EF85C2-FF3F-4341-9169-46BAB0BC94A3@oracle.com>


On Jul 16, 2013, at 3:27 PM, ATKIN-GRANVILLE Chris <s1255753 at sms.ed.ac.uk> wrote:

> Oh, that may have been a silly thing to say, I know you can't "get" the BCI of a method call that doesn't exist in the bytecode. Even still, it seems like quite a large omission from graal to not be able to add static method calls into a graph?

We can only add static calls that are guaranteed to never be deoptimized since there is no valid interpreter state to continue in for such invocations. I doubt that any bytecode compiler that relies on deoptimization could do any different?

For your use case, bytecode instrumentation is what you want. Especially since you (seem to) need complete dynamic coverage of the code patterns you are interested in instrumenting.

-Doug

> On 16 Jul 2013, at 14:19, ATKIN-GRANVILLE Chris <s1255753 at sms.ed.ac.uk>
> wrote:
> 
>> Is it not possible to somehow "get" that BCI? It doesn't seem like adding static method calls should be impossible when graph transformations are possible...
>> 
>> On 16 Jul 2013, at 14:14, Doug Simon <doug.simon at oracle.com>
>> wrote:
>> 
>>> This is almost certainly due to the fact that an invoke node must be associated with the BCI of a real invoke bytecode instruction. Otherwise, where would the interpreter resume if there is a deoptimization  during the invocation?
>>> 
>>> On Jul 16, 2013, at 2:22 PM, ATKIN-GRANVILLE Chris <s1255753 at sms.ed.ac.uk> wrote:
>>> 
>>>> Hi there,
>>>> 
>>>> I'm trying to modify the graph to include an invoke node to a static function after certain node types. I'm modifying the graph at a high level before LoweringPhase.class (not a requirement, can change if required). However, I'm running into issues with JVM fatal errors. The code I have at the moment looks like this:
>>>> 
>>>> public class MyPhase extends Phase {
>>>> 	public void run(StructuredGraph graph) {
>>>> 		for (Node node: graph.getNode()) {
>>>> 
>>>> 			if ( node instanceof RandomFixedNode) {
>>>> 				RandomFixedNode rfm = (RandomFixedNode) node;
>>>> 				
>>>> 				try {
>>>> 					ResolvedJavaMethod method = getMethod(?);
>>>> 					MethodCallTargetMode callTarget = graph.add(new MethodCallTargetNode(MethodCallTargetNode.InvokeKind.Static,
>>>> 						method, new ValueNode[] {}, new HotSpotResolvedPrimitiveType(Kind.Void)));
>>>> 
>>>> 					InvokeNode invoke = graph.add(new InvokeNode(callTarget, FrameState.UNKNOWN_BCI));
>>>> 					invoke.setStateAfter(graph.add(new FrameState(FrameState.UNKNOWN_BCI)));
>>>> 					graph.addAfterFixed(rfm, invoke);
>>>> 				
>>>> 				} catch (Exception e) {
>>>> 					e.printStackTrace();
>>>> 				} 
>>>> 			}
>>>> 
>>>> 		}
>>>> 	}
>>>> }
>>>> 
>>>> I'm pretty sure the problem is do with the BCIs and/or the FrameStates, but I don't know how to fix it. The error that I get is:
>>>> 
>>>> Internal Error (/Volumes/Acme/Development/graal/src/share/vm/graal/graalCompilerToVM.cpp:44), pid=8466, tid=5379
>>>> assert(hotspot_method != NULL && hotspot_method->is_a(HotSpotResolvedJavaMethod::klass())) failed: sanity
>>>> 
>>>> Does anyone have any ideas?
>>>> 
>>>> Thanks, Chris
>>>> 
>>>> -- 
>>>> The University of Edinburgh is a charitable body, registered in
>>>> Scotland, with registration number SC005336.
>>>> 
>>> 
>>> 
>> 
>> 
>> 
>> -- 
>> The University of Edinburgh is a charitable body, registered in
>> Scotland, with registration number SC005336.
>> 
>> 
> 
> 
> 
> -- 
> The University of Edinburgh is a charitable body, registered in
> Scotland, with registration number SC005336.
> 


From christophe.dubach at ed.ac.uk  Tue Jul 16 07:41:20 2013
From: christophe.dubach at ed.ac.uk (Christophe Dubach)
Date: Tue, 16 Jul 2013 15:41:20 +0100
Subject: Modifying graph to include InvokeNode
In-Reply-To: <50EF85C2-FF3F-4341-9169-46BAB0BC94A3@oracle.com>
References: <917C3B2B-52B0-4B9F-A3A4-FAB598A2EA29@sms.ed.ac.uk>
	<920EF6F2-121B-4723-A760-9CA7FACC33D0@oracle.com>
	<C0E75C84-C04F-42CB-892E-C66E8D649EE8@sms.ed.ac.uk>
	<E2C4ACBD-0501-4E9A-A919-888C6BC04BE6@sms.ed.ac.uk>
	<50EF85C2-FF3F-4341-9169-46BAB0BC94A3@oracle.com>
Message-ID: <51E55B90.3060205@ed.ac.uk>

Dear Doug,

I'm currently supervising Chris with his work and have been following 
the discussion.

I am quite surprised that it is not possible to add an InvokeNode in a 
the graph of a method at runtime. When you say "We can only add static 
calls that are guaranteed to never be deoptimized" do you mean the 
callee or the caller? I am probably ignorant but I don't see what would 
be the difference between inserting an invokeNode to static method (not 
created dynamically) and an IntergerAdd node in the graph at runtime.

Anyway, thanks for the suggestion of doing bytecode instrumentation. Is 
it possible to do this directly with Graal or where you talking about 
patching the method at class load time? In our scenario, we want to 
limit our instrumentation to hot methods in order to further optimise 
them, therefore, we were aiming to do all this in the jit compiler.

Thanks,
Christophe.


  On 16/07/13 14:43, Doug Simon wrote:
> On Jul 16, 2013, at 3:27 PM, ATKIN-GRANVILLE Chris <s1255753 at sms.ed.ac.uk> wrote:
>
>> Oh, that may have been a silly thing to say, I know you can't "get" the BCI of a method call that doesn't exist in the bytecode. Even still, it seems like quite a large omission from graal to not be able to add static method calls into a graph?
> We can only add static calls that are guaranteed to never be deoptimized since there is no valid interpreter state to continue in for such invocations. I doubt that any bytecode compiler that relies on deoptimization could do any different?
>
> For your use case, bytecode instrumentation is what you want. Especially since you (seem to) need complete dynamic coverage of the code patterns you are interested in instrumenting.
>
> -Doug
>
>> On 16 Jul 2013, at 14:19, ATKIN-GRANVILLE Chris <s1255753 at sms.ed.ac.uk>
>> wrote:
>>
>>> Is it not possible to somehow "get" that BCI? It doesn't seem like adding static method calls should be impossible when graph transformations are possible...
>>>
>>> On 16 Jul 2013, at 14:14, Doug Simon <doug.simon at oracle.com>
>>> wrote:
>>>
>>>> This is almost certainly due to the fact that an invoke node must be associated with the BCI of a real invoke bytecode instruction. Otherwise, where would the interpreter resume if there is a deoptimization  during the invocation?
>>>>
>>>> On Jul 16, 2013, at 2:22 PM, ATKIN-GRANVILLE Chris <s1255753 at sms.ed.ac.uk> wrote:
>>>>
>>>>> Hi there,
>>>>>
>>>>> I'm trying to modify the graph to include an invoke node to a static function after certain node types. I'm modifying the graph at a high level before LoweringPhase.class (not a requirement, can change if required). However, I'm running into issues with JVM fatal errors. The code I have at the moment looks like this:
>>>>>
>>>>> public class MyPhase extends Phase {
>>>>> 	public void run(StructuredGraph graph) {
>>>>> 		for (Node node: graph.getNode()) {
>>>>>
>>>>> 			if ( node instanceof RandomFixedNode) {
>>>>> 				RandomFixedNode rfm = (RandomFixedNode) node;
>>>>> 				
>>>>> 				try {
>>>>> 					ResolvedJavaMethod method = getMethod(?);
>>>>> 					MethodCallTargetMode callTarget = graph.add(new MethodCallTargetNode(MethodCallTargetNode.InvokeKind.Static,
>>>>> 						method, new ValueNode[] {}, new HotSpotResolvedPrimitiveType(Kind.Void)));
>>>>>
>>>>> 					InvokeNode invoke = graph.add(new InvokeNode(callTarget, FrameState.UNKNOWN_BCI));
>>>>> 					invoke.setStateAfter(graph.add(new FrameState(FrameState.UNKNOWN_BCI)));
>>>>> 					graph.addAfterFixed(rfm, invoke);
>>>>> 				
>>>>> 				} catch (Exception e) {
>>>>> 					e.printStackTrace();
>>>>> 				}
>>>>> 			}
>>>>>
>>>>> 		}
>>>>> 	}
>>>>> }
>>>>>
>>>>> I'm pretty sure the problem is do with the BCIs and/or the FrameStates, but I don't know how to fix it. The error that I get is:
>>>>>
>>>>> Internal Error (/Volumes/Acme/Development/graal/src/share/vm/graal/graalCompilerToVM.cpp:44), pid=8466, tid=5379
>>>>> assert(hotspot_method != NULL && hotspot_method->is_a(HotSpotResolvedJavaMethod::klass())) failed: sanity
>>>>>
>>>>> Does anyone have any ideas?
>>>>>
>>>>> Thanks, Chris
>>>>>
>>>>> -- 
>>>>> The University of Edinburgh is a charitable body, registered in
>>>>> Scotland, with registration number SC005336.
>>>>>
>>>>
>>>
>>>
>>> -- 
>>> The University of Edinburgh is a charitable body, registered in
>>> Scotland, with registration number SC005336.
>>>
>>>
>>
>>
>> -- 
>> The University of Edinburgh is a charitable body, registered in
>> Scotland, with registration number SC005336.
>>
>


-- 
The University of Edinburgh is a charitable body, registered in
Scotland, with registration number SC005336.


From doug.simon at oracle.com  Tue Jul 16 08:27:43 2013
From: doug.simon at oracle.com (Doug Simon)
Date: Tue, 16 Jul 2013 17:27:43 +0200
Subject: Modifying graph to include InvokeNode
In-Reply-To: <51E55B90.3060205@ed.ac.uk>
References: <917C3B2B-52B0-4B9F-A3A4-FAB598A2EA29@sms.ed.ac.uk>
	<920EF6F2-121B-4723-A760-9CA7FACC33D0@oracle.com>
	<C0E75C84-C04F-42CB-892E-C66E8D649EE8@sms.ed.ac.uk>
	<E2C4ACBD-0501-4E9A-A919-888C6BC04BE6@sms.ed.ac.uk>
	<50EF85C2-FF3F-4341-9169-46BAB0BC94A3@oracle.com>
	<51E55B90.3060205@ed.ac.uk>
Message-ID: <DF5F8528-72B4-4F59-8042-F06232539537@oracle.com>


On Jul 16, 2013, at 4:41 PM, Christophe Dubach <christophe.dubach at ed.ac.uk> wrote:

> Dear Doug,
> 
> I'm currently supervising Chris with his work and have been following the discussion.
> 
> I am quite surprised that it is not possible to add an InvokeNode in a the graph of a method at runtime. When you say "We can only add static calls that are guaranteed to never be deoptimized" do you mean the callee or the caller? I am probably ignorant but I don't see what would be the difference between inserting an invokeNode to static method (not created dynamically) and an IntergerAdd node in the graph at runtime.

An invoke node (that doesn't get inlined) in method A that calls method B will result in a call in the generated code. During execution of B, something may happen to invalidate an assumption made when compiling A (e.g., class loading invalidating a class hierarchy speculation). This means A is now invalid and needs to be deoptimized upon return from B. In the current system, we rely on HotSpot's deoptimization infrastructure to continue execution at the return site of A in the interpreter. HotSpot only (currently) supports deoptimize-on-return for call sites that have the BCI of an invoke bytecode.

One could modify HotSpot to have more general deoptimization support or we could modify Graal to handle invokes inserted for instrumentation. However, both of these tasks are non-trivial. Since our current focus is not on making Graal an all purpose instrumentation framework, we probably won't invest much effort in them in the near future.

> Anyway, thanks for the suggestion of doing bytecode instrumentation. Is it possible to do this directly with Graal or where you talking about patching the method at class load time?

The latter. Although you could use Graal in conjunction with a bytecode instrumentation library such as ASM for building a graph from the bytecode and finding the loops.

> In our scenario, we want to limit our instrumentation to hot methods in order to further optimise them, therefore, we were aiming to do all this in the jit compiler.

What you really want is a Java interpreter based on Truffle[1][2]. We have gone someway down this path ourselves but don't yet have anything publicly available.

-Doug

[1] http://www.christianwimmer.at/Publications/Wimmer12b/
[2] http://www.cs.purdue.edu/homes/jv/events/ESS13/

> 
> Thanks,
> Christophe.
> 
> 
> On 16/07/13 14:43, Doug Simon wrote:
>> On Jul 16, 2013, at 3:27 PM, ATKIN-GRANVILLE Chris <s1255753 at sms.ed.ac.uk> wrote:
>> 
>>> Oh, that may have been a silly thing to say, I know you can't "get" the BCI of a method call that doesn't exist in the bytecode. Even still, it seems like quite a large omission from graal to not be able to add static method calls into a graph?
>> We can only add static calls that are guaranteed to never be deoptimized since there is no valid interpreter state to continue in for such invocations. I doubt that any bytecode compiler that relies on deoptimization could do any different?
>> 
>> For your use case, bytecode instrumentation is what you want. Especially since you (seem to) need complete dynamic coverage of the code patterns you are interested in instrumenting.
>> 
>> -Doug
>> 
>>> On 16 Jul 2013, at 14:19, ATKIN-GRANVILLE Chris <s1255753 at sms.ed.ac.uk>
>>> wrote:
>>> 
>>>> Is it not possible to somehow "get" that BCI? It doesn't seem like adding static method calls should be impossible when graph transformations are possible...
>>>> 
>>>> On 16 Jul 2013, at 14:14, Doug Simon <doug.simon at oracle.com>
>>>> wrote:
>>>> 
>>>>> This is almost certainly due to the fact that an invoke node must be associated with the BCI of a real invoke bytecode instruction. Otherwise, where would the interpreter resume if there is a deoptimization  during the invocation?
>>>>> 
>>>>> On Jul 16, 2013, at 2:22 PM, ATKIN-GRANVILLE Chris <s1255753 at sms.ed.ac.uk> wrote:
>>>>> 
>>>>>> Hi there,
>>>>>> 
>>>>>> I'm trying to modify the graph to include an invoke node to a static function after certain node types. I'm modifying the graph at a high level before LoweringPhase.class (not a requirement, can change if required). However, I'm running into issues with JVM fatal errors. The code I have at the moment looks like this:
>>>>>> 
>>>>>> public class MyPhase extends Phase {
>>>>>> 	public void run(StructuredGraph graph) {
>>>>>> 		for (Node node: graph.getNode()) {
>>>>>> 
>>>>>> 			if ( node instanceof RandomFixedNode) {
>>>>>> 				RandomFixedNode rfm = (RandomFixedNode) node;
>>>>>> 				
>>>>>> 				try {
>>>>>> 					ResolvedJavaMethod method = getMethod(?);
>>>>>> 					MethodCallTargetMode callTarget = graph.add(new MethodCallTargetNode(MethodCallTargetNode.InvokeKind.Static,
>>>>>> 						method, new ValueNode[] {}, new HotSpotResolvedPrimitiveType(Kind.Void)));
>>>>>> 
>>>>>> 					InvokeNode invoke = graph.add(new InvokeNode(callTarget, FrameState.UNKNOWN_BCI));
>>>>>> 					invoke.setStateAfter(graph.add(new FrameState(FrameState.UNKNOWN_BCI)));
>>>>>> 					graph.addAfterFixed(rfm, invoke);
>>>>>> 				
>>>>>> 				} catch (Exception e) {
>>>>>> 					e.printStackTrace();
>>>>>> 				}
>>>>>> 			}
>>>>>> 
>>>>>> 		}
>>>>>> 	}
>>>>>> }
>>>>>> 
>>>>>> I'm pretty sure the problem is do with the BCIs and/or the FrameStates, but I don't know how to fix it. The error that I get is:
>>>>>> 
>>>>>> Internal Error (/Volumes/Acme/Development/graal/src/share/vm/graal/graalCompilerToVM.cpp:44), pid=8466, tid=5379
>>>>>> assert(hotspot_method != NULL && hotspot_method->is_a(HotSpotResolvedJavaMethod::klass())) failed: sanity
>>>>>> 
>>>>>> Does anyone have any ideas?
>>>>>> 
>>>>>> Thanks, Chris
>>>>>> 
>>>>>> -- 
>>>>>> The University of Edinburgh is a charitable body, registered in
>>>>>> Scotland, with registration number SC005336.
>>>>>> 
>>>>> 
>>>> 
>>>> 
>>>> -- 
>>>> The University of Edinburgh is a charitable body, registered in
>>>> Scotland, with registration number SC005336.
>>>> 
>>>> 
>>> 
>>> 
>>> -- 
>>> The University of Edinburgh is a charitable body, registered in
>>> Scotland, with registration number SC005336.
>>> 
>> 
> 
> 
> -- 
> The University of Edinburgh is a charitable body, registered in
> Scotland, with registration number SC005336.
> 


From forax at univ-mlv.fr  Tue Jul 16 08:33:21 2013
From: forax at univ-mlv.fr (Remi Forax)
Date: Tue, 16 Jul 2013 17:33:21 +0200
Subject: Modifying graph to include InvokeNode
In-Reply-To: <DF5F8528-72B4-4F59-8042-F06232539537@oracle.com>
References: <917C3B2B-52B0-4B9F-A3A4-FAB598A2EA29@sms.ed.ac.uk>
	<920EF6F2-121B-4723-A760-9CA7FACC33D0@oracle.com>
	<C0E75C84-C04F-42CB-892E-C66E8D649EE8@sms.ed.ac.uk>
	<E2C4ACBD-0501-4E9A-A919-888C6BC04BE6@sms.ed.ac.uk>
	<50EF85C2-FF3F-4341-9169-46BAB0BC94A3@oracle.com>
	<51E55B90.3060205@ed.ac.uk>
	<DF5F8528-72B4-4F59-8042-F06232539537@oracle.com>
Message-ID: <51E567C1.50302@univ-mlv.fr>

On 07/16/2013 05:27 PM, Doug Simon wrote:
> On Jul 16, 2013, at 4:41 PM, Christophe Dubach <christophe.dubach at ed.ac.uk> wrote:
>
>> Dear Doug,
>>
>> I'm currently supervising Chris with his work and have been following the discussion.
>>
>> I am quite surprised that it is not possible to add an InvokeNode in a the graph of a method at runtime. When you say "We can only add static calls that are guaranteed to never be deoptimized" do you mean the callee or the caller? I am probably ignorant but I don't see what would be the difference between inserting an invokeNode to static method (not created dynamically) and an IntergerAdd node in the graph at runtime.
> An invoke node (that doesn't get inlined) in method A that calls method B will result in a call in the generated code. During execution of B, something may happen to invalidate an assumption made when compiling A (e.g., class loading invalidating a class hierarchy speculation). This means A is now invalid and needs to be deoptimized upon return from B. In the current system, we rely on HotSpot's deoptimization infrastructure to continue execution at the return site of A in the interpreter. HotSpot only (currently) supports deoptimize-on-return for call sites that have the BCI of an invoke bytecode.
>
> One could modify HotSpot to have more general deoptimization support or we could modify Graal to handle invokes inserted for instrumentation. However, both of these tasks are non-trivial. Since our current focus is not on making Graal an all purpose instrumentation framework, we probably won't invest much effort in them in the near future.
>
>> Anyway, thanks for the suggestion of doing bytecode instrumentation. Is it possible to do this directly with Graal or where you talking about patching the method at class load time?
> The latter. Although you could use Graal in conjunction with a bytecode instrumentation library such as ASM for building a graph from the bytecode and finding the loops.
>
>> In our scenario, we want to limit our instrumentation to hot methods in order to further optimise them, therefore, we were aiming to do all this in the jit compiler.
> What you really want is a Java interpreter based on Truffle[1][2]. We have gone someway down this path ourselves but don't yet have anything publicly available.

The other solution is to use invokedynamic, if Graal support it ?

>
> -Doug
>
> [1] http://www.christianwimmer.at/Publications/Wimmer12b/
> [2] http://www.cs.purdue.edu/homes/jv/events/ESS13/

R?mi

>> Thanks,
>> Christophe.
>>
>>
>> On 16/07/13 14:43, Doug Simon wrote:
>>> On Jul 16, 2013, at 3:27 PM, ATKIN-GRANVILLE Chris <s1255753 at sms.ed.ac.uk> wrote:
>>>
>>>> Oh, that may have been a silly thing to say, I know you can't "get" the BCI of a method call that doesn't exist in the bytecode. Even still, it seems like quite a large omission from graal to not be able to add static method calls into a graph?
>>> We can only add static calls that are guaranteed to never be deoptimized since there is no valid interpreter state to continue in for such invocations. I doubt that any bytecode compiler that relies on deoptimization could do any different?
>>>
>>> For your use case, bytecode instrumentation is what you want. Especially since you (seem to) need complete dynamic coverage of the code patterns you are interested in instrumenting.
>>>
>>> -Doug
>>>
>>>> On 16 Jul 2013, at 14:19, ATKIN-GRANVILLE Chris <s1255753 at sms.ed.ac.uk>
>>>> wrote:
>>>>
>>>>> Is it not possible to somehow "get" that BCI? It doesn't seem like adding static method calls should be impossible when graph transformations are possible...
>>>>>
>>>>> On 16 Jul 2013, at 14:14, Doug Simon <doug.simon at oracle.com>
>>>>> wrote:
>>>>>
>>>>>> This is almost certainly due to the fact that an invoke node must be associated with the BCI of a real invoke bytecode instruction. Otherwise, where would the interpreter resume if there is a deoptimization  during the invocation?
>>>>>>
>>>>>> On Jul 16, 2013, at 2:22 PM, ATKIN-GRANVILLE Chris <s1255753 at sms.ed.ac.uk> wrote:
>>>>>>
>>>>>>> Hi there,
>>>>>>>
>>>>>>> I'm trying to modify the graph to include an invoke node to a static function after certain node types. I'm modifying the graph at a high level before LoweringPhase.class (not a requirement, can change if required). However, I'm running into issues with JVM fatal errors. The code I have at the moment looks like this:
>>>>>>>
>>>>>>> public class MyPhase extends Phase {
>>>>>>> 	public void run(StructuredGraph graph) {
>>>>>>> 		for (Node node: graph.getNode()) {
>>>>>>>
>>>>>>> 			if ( node instanceof RandomFixedNode) {
>>>>>>> 				RandomFixedNode rfm = (RandomFixedNode) node;
>>>>>>> 				
>>>>>>> 				try {
>>>>>>> 					ResolvedJavaMethod method = getMethod(?);
>>>>>>> 					MethodCallTargetMode callTarget = graph.add(new MethodCallTargetNode(MethodCallTargetNode.InvokeKind.Static,
>>>>>>> 						method, new ValueNode[] {}, new HotSpotResolvedPrimitiveType(Kind.Void)));
>>>>>>>
>>>>>>> 					InvokeNode invoke = graph.add(new InvokeNode(callTarget, FrameState.UNKNOWN_BCI));
>>>>>>> 					invoke.setStateAfter(graph.add(new FrameState(FrameState.UNKNOWN_BCI)));
>>>>>>> 					graph.addAfterFixed(rfm, invoke);
>>>>>>> 				
>>>>>>> 				} catch (Exception e) {
>>>>>>> 					e.printStackTrace();
>>>>>>> 				}
>>>>>>> 			}
>>>>>>>
>>>>>>> 		}
>>>>>>> 	}
>>>>>>> }
>>>>>>>
>>>>>>> I'm pretty sure the problem is do with the BCIs and/or the FrameStates, but I don't know how to fix it. The error that I get is:
>>>>>>>
>>>>>>> Internal Error (/Volumes/Acme/Development/graal/src/share/vm/graal/graalCompilerToVM.cpp:44), pid=8466, tid=5379
>>>>>>> assert(hotspot_method != NULL && hotspot_method->is_a(HotSpotResolvedJavaMethod::klass())) failed: sanity
>>>>>>>
>>>>>>> Does anyone have any ideas?
>>>>>>>
>>>>>>> Thanks, Chris
>>>>>>>
>>>>>>> -- 
>>>>>>> The University of Edinburgh is a charitable body, registered in
>>>>>>> Scotland, with registration number SC005336.
>>>>>>>
>>>>>
>>>>> -- 
>>>>> The University of Edinburgh is a charitable body, registered in
>>>>> Scotland, with registration number SC005336.
>>>>>
>>>>>
>>>>
>>>> -- 
>>>> The University of Edinburgh is a charitable body, registered in
>>>> Scotland, with registration number SC005336.
>>>>
>>
>> -- 
>> The University of Edinburgh is a charitable body, registered in
>> Scotland, with registration number SC005336.
>>


From christophe.dubach at ed.ac.uk  Tue Jul 16 08:58:55 2013
From: christophe.dubach at ed.ac.uk (Christophe Dubach)
Date: Tue, 16 Jul 2013 16:58:55 +0100
Subject: Modifying graph to include InvokeNode
In-Reply-To: <DF5F8528-72B4-4F59-8042-F06232539537@oracle.com>
References: <917C3B2B-52B0-4B9F-A3A4-FAB598A2EA29@sms.ed.ac.uk>
	<920EF6F2-121B-4723-A760-9CA7FACC33D0@oracle.com>
	<C0E75C84-C04F-42CB-892E-C66E8D649EE8@sms.ed.ac.uk>
	<E2C4ACBD-0501-4E9A-A919-888C6BC04BE6@sms.ed.ac.uk>
	<50EF85C2-FF3F-4341-9169-46BAB0BC94A3@oracle.com>
	<51E55B90.3060205@ed.ac.uk>
	<DF5F8528-72B4-4F59-8042-F06232539537@oracle.com>
Message-ID: <51E56DBF.4000307@ed.ac.uk>

> An invoke node (that doesn't get inlined) in method A that calls method B will result in a call in the generated code. During execution of B, something may happen to invalidate an assumption made when compiling A (e.g., class loading invalidating a class hierarchy speculation). This means A is now invalid and needs to be deoptimized upon return from B. In the current system, we rely on HotSpot's deoptimization infrastructure to continue execution at the return site of A in the interpreter. HotSpot only (currently) supports deoptimize-on-return for call sites that have the BCI of an invoke bytecode.
Thank you for the clarification, I think I see the problem.

Is there a way we could add a new invokeNode in the graph and then force 
it to get inlined straight-away?

-- 
The University of Edinburgh is a charitable body, registered in
Scotland, with registration number SC005336.


From doug.simon at oracle.com  Tue Jul 16 09:03:25 2013
From: doug.simon at oracle.com (Doug Simon)
Date: Tue, 16 Jul 2013 18:03:25 +0200
Subject: Modifying graph to include InvokeNode
In-Reply-To: <51E567C1.50302@univ-mlv.fr>
References: <917C3B2B-52B0-4B9F-A3A4-FAB598A2EA29@sms.ed.ac.uk>
	<920EF6F2-121B-4723-A760-9CA7FACC33D0@oracle.com>
	<C0E75C84-C04F-42CB-892E-C66E8D649EE8@sms.ed.ac.uk>
	<E2C4ACBD-0501-4E9A-A919-888C6BC04BE6@sms.ed.ac.uk>
	<50EF85C2-FF3F-4341-9169-46BAB0BC94A3@oracle.com>
	<51E55B90.3060205@ed.ac.uk>
	<DF5F8528-72B4-4F59-8042-F06232539537@oracle.com>
	<51E567C1.50302@univ-mlv.fr>
Message-ID: <680474C2-27D9-4FD8-9AF9-E3690F29A923@oracle.com>


On Jul 16, 2013, at 5:33 PM, Remi Forax <forax at univ-mlv.fr> wrote:

> On 07/16/2013 05:27 PM, Doug Simon wrote:
>> On Jul 16, 2013, at 4:41 PM, Christophe Dubach <christophe.dubach at ed.ac.uk> wrote:
>> 
>>> Dear Doug,
>>> 
>>> I'm currently supervising Chris with his work and have been following the discussion.
>>> 
>>> I am quite surprised that it is not possible to add an InvokeNode in a the graph of a method at runtime. When you say "We can only add static calls that are guaranteed to never be deoptimized" do you mean the callee or the caller? I am probably ignorant but I don't see what would be the difference between inserting an invokeNode to static method (not created dynamically) and an IntergerAdd node in the graph at runtime.
>> An invoke node (that doesn't get inlined) in method A that calls method B will result in a call in the generated code. During execution of B, something may happen to invalidate an assumption made when compiling A (e.g., class loading invalidating a class hierarchy speculation). This means A is now invalid and needs to be deoptimized upon return from B. In the current system, we rely on HotSpot's deoptimization infrastructure to continue execution at the return site of A in the interpreter. HotSpot only (currently) supports deoptimize-on-return for call sites that have the BCI of an invoke bytecode.
>> 
>> One could modify HotSpot to have more general deoptimization support or we could modify Graal to handle invokes inserted for instrumentation. However, both of these tasks are non-trivial. Since our current focus is not on making Graal an all purpose instrumentation framework, we probably won't invest much effort in them in the near future.
>> 
>>> Anyway, thanks for the suggestion of doing bytecode instrumentation. Is it possible to do this directly with Graal or where you talking about patching the method at class load time?
>> The latter. Although you could use Graal in conjunction with a bytecode instrumentation library such as ASM for building a graph from the bytecode and finding the loops.
>> 
>>> In our scenario, we want to limit our instrumentation to hot methods in order to further optimise them, therefore, we were aiming to do all this in the jit compiler.
>> What you really want is a Java interpreter based on Truffle[1][2]. We have gone someway down this path ourselves but don't yet have anything publicly available.
> 
> The other solution is to use invokedynamic, if Graal support it ?

It supports it but does not (yet) optimize it.

-Doug

> 
>>> Thanks,
>>> Christophe.
>>> 
>>> 
>>> On 16/07/13 14:43, Doug Simon wrote:
>>>> On Jul 16, 2013, at 3:27 PM, ATKIN-GRANVILLE Chris <s1255753 at sms.ed.ac.uk> wrote:
>>>> 
>>>>> Oh, that may have been a silly thing to say, I know you can't "get" the BCI of a method call that doesn't exist in the bytecode. Even still, it seems like quite a large omission from graal to not be able to add static method calls into a graph?
>>>> We can only add static calls that are guaranteed to never be deoptimized since there is no valid interpreter state to continue in for such invocations. I doubt that any bytecode compiler that relies on deoptimization could do any different?
>>>> 
>>>> For your use case, bytecode instrumentation is what you want. Especially since you (seem to) need complete dynamic coverage of the code patterns you are interested in instrumenting.
>>>> 
>>>> -Doug
>>>> 
>>>>> On 16 Jul 2013, at 14:19, ATKIN-GRANVILLE Chris <s1255753 at sms.ed.ac.uk>
>>>>> wrote:
>>>>> 
>>>>>> Is it not possible to somehow "get" that BCI? It doesn't seem like adding static method calls should be impossible when graph transformations are possible...
>>>>>> 
>>>>>> On 16 Jul 2013, at 14:14, Doug Simon <doug.simon at oracle.com>
>>>>>> wrote:
>>>>>> 
>>>>>>> This is almost certainly due to the fact that an invoke node must be associated with the BCI of a real invoke bytecode instruction. Otherwise, where would the interpreter resume if there is a deoptimization  during the invocation?
>>>>>>> 
>>>>>>> On Jul 16, 2013, at 2:22 PM, ATKIN-GRANVILLE Chris <s1255753 at sms.ed.ac.uk> wrote:
>>>>>>> 
>>>>>>>> Hi there,
>>>>>>>> 
>>>>>>>> I'm trying to modify the graph to include an invoke node to a static function after certain node types. I'm modifying the graph at a high level before LoweringPhase.class (not a requirement, can change if required). However, I'm running into issues with JVM fatal errors. The code I have at the moment looks like this:
>>>>>>>> 
>>>>>>>> public class MyPhase extends Phase {
>>>>>>>> 	public void run(StructuredGraph graph) {
>>>>>>>> 		for (Node node: graph.getNode()) {
>>>>>>>> 
>>>>>>>> 			if ( node instanceof RandomFixedNode) {
>>>>>>>> 				RandomFixedNode rfm = (RandomFixedNode) node;
>>>>>>>> 				
>>>>>>>> 				try {
>>>>>>>> 					ResolvedJavaMethod method = getMethod(?);
>>>>>>>> 					MethodCallTargetMode callTarget = graph.add(new MethodCallTargetNode(MethodCallTargetNode.InvokeKind.Static,
>>>>>>>> 						method, new ValueNode[] {}, new HotSpotResolvedPrimitiveType(Kind.Void)));
>>>>>>>> 
>>>>>>>> 					InvokeNode invoke = graph.add(new InvokeNode(callTarget, FrameState.UNKNOWN_BCI));
>>>>>>>> 					invoke.setStateAfter(graph.add(new FrameState(FrameState.UNKNOWN_BCI)));
>>>>>>>> 					graph.addAfterFixed(rfm, invoke);
>>>>>>>> 				
>>>>>>>> 				} catch (Exception e) {
>>>>>>>> 					e.printStackTrace();
>>>>>>>> 				}
>>>>>>>> 			}
>>>>>>>> 
>>>>>>>> 		}
>>>>>>>> 	}
>>>>>>>> }
>>>>>>>> 
>>>>>>>> I'm pretty sure the problem is do with the BCIs and/or the FrameStates, but I don't know how to fix it. The error that I get is:
>>>>>>>> 
>>>>>>>> Internal Error (/Volumes/Acme/Development/graal/src/share/vm/graal/graalCompilerToVM.cpp:44), pid=8466, tid=5379
>>>>>>>> assert(hotspot_method != NULL && hotspot_method->is_a(HotSpotResolvedJavaMethod::klass())) failed: sanity
>>>>>>>> 
>>>>>>>> Does anyone have any ideas?
>>>>>>>> 
>>>>>>>> Thanks, Chris
>>>>>>>> 
>>>>>>>> -- 
>>>>>>>> The University of Edinburgh is a charitable body, registered in
>>>>>>>> Scotland, with registration number SC005336.
>>>>>>>> 
>>>>>> 
>>>>>> -- 
>>>>>> The University of Edinburgh is a charitable body, registered in
>>>>>> Scotland, with registration number SC005336.
>>>>>> 
>>>>>> 
>>>>> 
>>>>> -- 
>>>>> The University of Edinburgh is a charitable body, registered in
>>>>> Scotland, with registration number SC005336.
>>>>> 
>>> 
>>> -- 
>>> The University of Edinburgh is a charitable body, registered in
>>> Scotland, with registration number SC005336.
>>> 
> 


From doug.simon at oracle.com  Tue Jul 16 09:38:11 2013
From: doug.simon at oracle.com (Doug Simon)
Date: Tue, 16 Jul 2013 18:38:11 +0200
Subject: Modifying graph to include InvokeNode
In-Reply-To: <51E56DBF.4000307@ed.ac.uk>
References: <917C3B2B-52B0-4B9F-A3A4-FAB598A2EA29@sms.ed.ac.uk>
	<920EF6F2-121B-4723-A760-9CA7FACC33D0@oracle.com>
	<C0E75C84-C04F-42CB-892E-C66E8D649EE8@sms.ed.ac.uk>
	<E2C4ACBD-0501-4E9A-A919-888C6BC04BE6@sms.ed.ac.uk>
	<50EF85C2-FF3F-4341-9169-46BAB0BC94A3@oracle.com>
	<51E55B90.3060205@ed.ac.uk>
	<DF5F8528-72B4-4F59-8042-F06232539537@oracle.com>
	<51E56DBF.4000307@ed.ac.uk>
Message-ID: <EB2C2A5A-556E-4F01-8586-A2B268EDCC61@oracle.com>


On Jul 16, 2013, at 5:58 PM, Christophe Dubach <christophe.dubach at ed.ac.uk> wrote:

>> An invoke node (that doesn't get inlined) in method A that calls method B will result in a call in the generated code. During execution of B, something may happen to invalidate an assumption made when compiling A (e.g., class loading invalidating a class hierarchy speculation). This means A is now invalid and needs to be deoptimized upon return from B. In the current system, we rely on HotSpot's deoptimization infrastructure to continue execution at the return site of A in the interpreter. HotSpot only (currently) supports deoptimize-on-return for call sites that have the BCI of an invoke bytecode.
> Thank you for the clarification, I think I see the problem.
> 
> Is there a way we could add a new invokeNode in the graph and then force it to get inlined straight-away?

This is essentially what we do with snippets which is the direction Chris was initially heading. The problem you can still not do anything (like allocating/expanding a data structure) that causes deoptimization in the transitively inlined methods calls.

-Doug

From doug.simon at oracle.com  Tue Jul 16 09:47:51 2013
From: doug.simon at oracle.com (Doug Simon)
Date: Tue, 16 Jul 2013 18:47:51 +0200
Subject: graal/graal: 107 new changesets
In-Reply-To: <BC97738F8E7C8742BABED7F06FB9DF91450454E9@sausexdag01.amd.com>
References: <20130715170157.A77A4480BF@hg.openjdk.java.net>
	<BC97738F8E7C8742BABED7F06FB9DF91450454E9@sausexdag01.amd.com>
Message-ID: <A6D3A38A-FD4A-4179-AF70-B5A4E766677A@oracle.com>

Sorry, I can't think of what the problem is/was.

On Jul 15, 2013, at 11:05 PM, "Deneau, Tom" <tom.deneau at amd.com> wrote:

> Doug or others --
> 
> I was about to ask for help on a codegen problem we were seeing but after updating to the latest default,
> I see that it is gone (so I'm assuming it was not in our backend :) ).  Of course it is possible that the bug
> is just being hidden by some unrelated change.   Anyway, here is a brief description,
> maybe you can tell which of the many changesets below would have fixed this, if any.
> 
> We were using String.contains as our test case, which was being nicely inlined, and we generated the following 
> HSAIL code which led to the problem
> 
> 	ld_global_u16 $s8, [$d3 + 24];         // read a u16 char from the test String
> 	ld_global_u16 $s9, [$d1 + 24];         // read a u16 char from the pattern  
> 	st_spill_s32 $s9, [%spillseg][24];     // register spill
> 	mov_b32 $s8, 0;                        // <<<<--- This code was causing the problem 
> 	cmp_ne_b1_s32 $c0, $s8, $s9;           // compare the two chars but s8 has been clobbered
> 
> 
> When I did a -G:TraceLIRGeneratorLevel=2, I could see that the problematic instruction
> "mov_b32 $s8, 0"
> was generated as part of something called
>       MOVE TO PHI from 276|EndNode to 277|LoopBegin
> 
> as part of PhiResolver.dispose, the part that is commented with
>  // generate move for move from non variable to arbitrary destination
> 
> Does the above sound like something that was purposely fixed?
> 
> -- 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 at oracle.com
> Sent: Monday, July 15, 2013 11:56 AM
> To: graal-dev at openjdk.java.net
> Subject: hg: graal/graal: 107 new changesets
> 
> Changeset: 204d8d4f91a4
> Author:    Christian Haeubl <haeubl at ssw.jku.at>
> Date:      2013-07-09 11:18 +0200
> URL:       http://hg.openjdk.java.net/graal/graal/rev/204d8d4f91a4
> 
> Minor Java fix.
> 
> ! graal/com.oracle.graal.api.code/src/com/oracle/graal/api/code/Assumptions.java
> 
> Changeset: a9b76e1e5ab3
> Author:    Christian Haeubl <haeubl at ssw.jku.at>
> Date:      2013-07-09 11:19 +0200
> URL:       http://hg.openjdk.java.net/graal/graal/rev/a9b76e1e5ab3
> 
> Fix for OSR regression introduced with 88672775a26c.
> 
> ! src/share/vm/runtime/compilationPolicy.cpp
> 
> Changeset: dcee58529a1c
> Author:    Christian Haeubl <haeubl at ssw.jku.at>
> Date:      2013-07-09 11:21 +0200
> URL:       http://hg.openjdk.java.net/graal/graal/rev/dcee58529a1c
> 
> Merge.
> 
> - graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/nodes/HotSpotNmethodExecuteNode.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/HotSpotNmethodSubstitutions.java
> 
> Changeset: 9808158cfeab
> Author:    Roland Schatz <roland.schatz at oracle.com>
> Date:      2013-07-09 11:14 +0200
> URL:       http://hg.openjdk.java.net/graal/graal/rev/9808158cfeab
> 
> Allow foreign call stubs to be declared as leaf methods.
> 
> ! graal/com.oracle.graal.hotspot.amd64/src/com/oracle/graal/hotspot/amd64/AMD64HotSpotBackend.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/ForeignCallStub.java
> ! graal/com.oracle.graal.lir.amd64/src/com/oracle/graal/lir/amd64/AMD64SaveRegistersOp.java
> 
> Changeset: 5348b49b2a76
> Author:    Roland Schatz <roland.schatz at oracle.com>
> Date:      2013-07-09 11:57 +0200
> URL:       http://hg.openjdk.java.net/graal/graal/rev/5348b49b2a76
> 
> Assign framestates in snippet lowering after framestate assignment.
> 
> ! graal/com.oracle.graal.replacements/src/com/oracle/graal/replacements/SnippetTemplate.java
> 
> Changeset: 110444cbf1eb
> Author:    Roland Schatz <roland.schatz at oracle.com>
> Date:      2013-07-09 11:58 +0200
> URL:       http://hg.openjdk.java.net/graal/graal/rev/110444cbf1eb
> 
> Make FixedGuardNode a DeoptimizingNode.
> 
> ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/FixedGuardNode.java
> 
> Changeset: f11cd00d4115
> Author:    Roland Schatz <roland.schatz at oracle.com>
> Date:      2013-07-09 11:58 +0200
> URL:       http://hg.openjdk.java.net/graal/graal/rev/f11cd00d4115
> 
> Make G1PreWriteBarrier a DeoptimizingNode.
> 
> ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/phases/WriteBarrierAdditionPhase.java
> ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/WriteBarrierSnippets.java
> ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/G1PreWriteBarrier.java
> 
> Changeset: 5bab3272bb82
> Author:    Roland Schatz <roland.schatz at oracle.com>
> Date:      2013-07-09 11:58 +0200
> URL:       http://hg.openjdk.java.net/graal/graal/rev/5bab3272bb82
> 
> Make array allocations deoptimizing nodes.
> 
> ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/java/AbstractNewArrayNode.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
> 
> Changeset: 69089865435a
> Author:    Roland Schatz <roland.schatz at oracle.com>
> Date:      2013-07-09 11:58 +0200
> URL:       http://hg.openjdk.java.net/graal/graal/rev/69089865435a
> 
> New lowering phase after framestate assignment.
> 
> ! 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.nodes/src/com/oracle/graal/nodes/WriteBarrier.java
> ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/spi/Lowerable.java
> 
> Changeset: e7d07c9bb779
> Author:    Christian Haeubl <haeubl at ssw.jku.at>
> Date:      2013-07-09 17:53 +0200
> URL:       http://hg.openjdk.java.net/graal/graal/rev/e7d07c9bb779
> 
> Removed priority compilation queue.
> Fixed another race condition in the compilation queue.
> Removed Graal-specific compilation policy.
> 
> ! 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/CompilerThread.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.phases/src/com/oracle/graal/phases/GraalOptions.java
> ! src/cpu/x86/vm/templateInterpreter_x86_64.cpp
> ! src/share/vm/classfile/vmSymbols.hpp
> ! src/share/vm/graal/graalCompiler.cpp
> ! src/share/vm/graal/graalVMToCompiler.cpp
> ! src/share/vm/graal/graalVMToCompiler.hpp
> ! src/share/vm/oops/methodCounters.cpp
> ! src/share/vm/oops/methodCounters.hpp
> ! src/share/vm/runtime/compilationPolicy.cpp
> 
> Changeset: d59e7f94f28d
> Author:    Christian Haeubl <haeubl at ssw.jku.at>
> Date:      2013-07-09 17:54 +0200
> URL:       http://hg.openjdk.java.net/graal/graal/rev/d59e7f94f28d
> 
> Increased priority for compiler threads.
> 
> ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/CompilerThread.java
> 
> Changeset: 853a894e0d97
> Author:    Christian Haeubl <haeubl at ssw.jku.at>
> Date:      2013-07-09 17:55 +0200
> URL:       http://hg.openjdk.java.net/graal/graal/rev/853a894e0d97
> 
> Merge.
> 
> 
> Changeset: 41362ec88331
> Author:    Thomas Wuerthinger <thomas.wuerthinger at oracle.com>
> Date:      2013-07-09 14:33 +0200
> URL:       http://hg.openjdk.java.net/graal/graal/rev/41362ec88331
> 
> Improve Truffle graph cache.
> 
> ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/PartialEvaluator.java
> ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/TruffleCache.java
> 
> Changeset: 9db1377b0580
> Author:    Thomas Wuerthinger <thomas.wuerthinger at oracle.com>
> Date:      2013-07-09 17:38 +0200
> URL:       http://hg.openjdk.java.net/graal/graal/rev/9db1377b0580
> 
> Fix for TruffleCache.
> 
> ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/PartialEvaluator.java
> ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/TruffleCache.java
> ! graal/com.oracle.truffle.api/src/com/oracle/truffle/api/TruffleOptions.java
> ! graal/com.oracle.truffle.api/src/com/oracle/truffle/api/nodes/SlowPathException.java
> 
> Changeset: 3bbe14e492fb
> Author:    Thomas Wuerthinger <thomas.wuerthinger at oracle.com>
> Date:      2013-07-09 20:06 +0200
> URL:       http://hg.openjdk.java.net/graal/graal/rev/3bbe14e492fb
> 
> Introduce TruffleGraphMaxNodes option with default value 10000.
> 
> ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/PartialEvaluator.java
> ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/TruffleCompilerOptions.java
> 
> Changeset: 759415ed915a
> Author:    Thomas Wuerthinger <thomas.wuerthinger at oracle.com>
> Date:      2013-07-09 20:09 +0200
> URL:       http://hg.openjdk.java.net/graal/graal/rev/759415ed915a
> 
> Merge.
> 
> 
> Changeset: fa86a653bc0d
> Author:    Andreas Woess <andreas.woess at jku.at>
> Date:      2013-07-09 19:45 +0200
> URL:       http://hg.openjdk.java.net/graal/graal/rev/fa86a653bc0d
> 
> Truffle: ensure frame assumption is recorded for materialized frames
> 
> ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/nodes/FrameAccessNode.java
> 
> Changeset: 0c570e82cc1d
> Author:    Andreas Woess <andreas.woess at jku.at>
> Date:      2013-07-09 21:03 +0200
> URL:       http://hg.openjdk.java.net/graal/graal/rev/0c570e82cc1d
> 
> Truffle: minor cleanup
> 
> ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/FrameWithoutBoxing.java
> ! graal/com.oracle.truffle.api/src/com/oracle/truffle/api/impl/DefaultVirtualFrame.java
> 
> Changeset: 311abd52ffeb
> Author:    Andreas Woess <andreas.woess at jku.at>
> Date:      2013-07-09 21:20 +0200
> URL:       http://hg.openjdk.java.net/graal/graal/rev/311abd52ffeb
> 
> Merge
> 
> 
> Changeset: 725922588833
> Author:    Thomas Wuerthinger <thomas.wuerthinger at oracle.com>
> Date:      2013-07-09 21:53 +0200
> URL:       http://hg.openjdk.java.net/graal/graal/rev/725922588833
> 
> Fix Truffle cache inlining strategy to skip exception edges.
> 
> ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/TruffleCache.java
> ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/TruffleCompilerOptions.java
> 
> Changeset: ae4c79ee71d1
> Author:    Thomas Wuerthinger <thomas.wuerthinger at oracle.com>
> Date:      2013-07-09 22:05 +0200
> URL:       http://hg.openjdk.java.net/graal/graal/rev/ae4c79ee71d1
> 
> Merge.
> 
> 
> Changeset: 6ff467cdb105
> Author:    twisti
> Date:      2013-07-09 14:39 -0700
> URL:       http://hg.openjdk.java.net/graal/graal/rev/6ff467cdb105
> 
> Code installer changes for SPARC.
> 
> ! src/cpu/sparc/vm/graalCodeInstaller_sparc.hpp
> ! src/cpu/sparc/vm/sharedRuntime_sparc.cpp
> ! src/cpu/x86/vm/graalCodeInstaller_x86.hpp
> ! src/share/vm/graal/graalCodeInstaller.cpp
> ! src/share/vm/graal/graalCodeInstaller.hpp
> ! src/share/vm/prims/methodHandles.cpp
> 
> Changeset: 431eca622358
> Author:    twisti
> Date:      2013-07-09 15:37 -0700
> URL:       http://hg.openjdk.java.net/graal/graal/rev/431eca622358
> 
> SPARC: Fixed build errors.
> 
> ! src/share/vm/graal/graalCompilerToGPU.cpp
> ! src/share/vm/graal/graalCompilerToVM.hpp
> 
> Changeset: 73122b5edf6a
> Author:    twisti
> Date:      2013-07-09 15:37 -0700
> URL:       http://hg.openjdk.java.net/graal/graal/rev/73122b5edf6a
> 
> SPARC: Can compile simple methods and do static calls.
> 
> ! 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.asm.sparc/src/com/oracle/graal/asm/sparc/SPARCMacroAssembler.java
> ! graal/com.oracle.graal.compiler.sparc/src/com/oracle/graal/compiler/sparc/SPARCLIRGenerator.java
> ! graal/com.oracle.graal.hotspot.sparc/src/com/oracle/graal/hotspot/sparc/SPARCHotSpotBackend.java
> ! graal/com.oracle.graal.hotspot.sparc/src/com/oracle/graal/hotspot/sparc/SPARCHotSpotLIRGenerator.java
> ! graal/com.oracle.graal.hotspot.sparc/src/com/oracle/graal/hotspot/sparc/SPARCHotSpotRegisterConfig.java
> + graal/com.oracle.graal.hotspot.sparc/src/com/oracle/graal/hotspot/sparc/SPARCHotspotDirectStaticCallOp.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/SPARCCall.java
> ! graal/com.oracle.graal.lir.sparc/src/com/oracle/graal/lir/sparc/SPARCCompare.java
> ! graal/com.oracle.graal.lir.sparc/src/com/oracle/graal/lir/sparc/SPARCControlFlow.java
> ! graal/com.oracle.graal.lir.sparc/src/com/oracle/graal/lir/sparc/SPARCLIRInstruction.java
> ! graal/com.oracle.graal.lir.sparc/src/com/oracle/graal/lir/sparc/SPARCMathIntrinsicOp.java
> ! graal/com.oracle.graal.lir.sparc/src/com/oracle/graal/lir/sparc/SPARCMove.java
> ! graal/com.oracle.graal.lir.sparc/src/com/oracle/graal/lir/sparc/SPARCTestOp.java
> ! graal/com.oracle.graal.sparc/src/com/oracle/graal/sparc/SPARC.java
> 
> Changeset: d2055a110396
> Author:    Thomas Wuerthinger <thomas.wuerthinger at oracle.com>
> Date:      2013-07-10 05:26 +0200
> URL:       http://hg.openjdk.java.net/graal/graal/rev/d2055a110396
> 
> Introduce CompilerDirectives.SlowPath annotation.
> 
> ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/TruffleCache.java
> ! graal/com.oracle.truffle.api/src/com/oracle/truffle/api/CompilerDirectives.java
> 
> Changeset: 87d2df0a7624
> Author:    Thomas Wuerthinger <thomas.wuerthinger at oracle.com>
> Date:      2013-07-10 05:27 +0200
> URL:       http://hg.openjdk.java.net/graal/graal/rev/87d2df0a7624
> 
> Merge.
> 
> 
> Changeset: 3ae117e62905
> Author:    Christian Humer <christian.humer at gmail.com>
> Date:      2013-07-10 09:23 +0200
> URL:       http://hg.openjdk.java.net/graal/graal/rev/3ae117e62905
> 
> Removed frame argument for generic cases if not needed.
> Added @SlowPath annotation to generated generic cases.
> 
> ! graal/com.oracle.truffle.dsl.processor/src/com/oracle/truffle/dsl/processor/TruffleTypes.java
> ! graal/com.oracle.truffle.dsl.processor/src/com/oracle/truffle/dsl/processor/node/NodeCodeGenerator.java
> ! graal/com.oracle.truffle.dsl.processor/src/com/oracle/truffle/dsl/processor/node/NodeParser.java
> 
> Changeset: a0309f88306c
> Author:    Christian Humer <christian.humer at gmail.com>
> Date:      2013-07-10 09:42 +0200
> URL:       http://hg.openjdk.java.net/graal/graal/rev/a0309f88306c
> 
> Added truffle option to enable detailed rewrite messages. Disabled by default.
> 
> ! graal/com.oracle.truffle.api/src/com/oracle/truffle/api/TruffleOptions.java
> ! graal/com.oracle.truffle.dsl.processor/src/com/oracle/truffle/dsl/processor/TruffleTypes.java
> ! graal/com.oracle.truffle.dsl.processor/src/com/oracle/truffle/dsl/processor/node/NodeCodeGenerator.java
> 
> Changeset: 77b83e903703
> Author:    Doug Simon <doug.simon at oracle.com>
> Date:      2013-07-10 17:44 +0200
> URL:       http://hg.openjdk.java.net/graal/graal/rev/77b83e903703
> 
> make use of guardingNonNull node intrinsic
> 
> ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/ArrayCopySnippets.java
> 
> Changeset: bebc9672f45e
> Author:    Doug Simon <doug.simon at oracle.com>
> Date:      2013-07-10 17:46 +0200
> URL:       http://hg.openjdk.java.net/graal/graal/rev/bebc9672f45e
> 
> stamp for GuardingPiNode is determined by caller of constructor, not within constructor
> 
> ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/GuardingPiNode.java
> ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/InliningUtil.java
> 
> Changeset: f8adf47cc05e
> Author:    Doug Simon <doug.simon at oracle.com>
> Date:      2013-07-10 17:46 +0200
> URL:       http://hg.openjdk.java.net/graal/graal/rev/f8adf47cc05e
> 
> checkcast is lowered to instanceof (GRAAL-248)
> 
> ! graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/PushNodesThroughPiTest.java
> ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/java/CheckCastNode.java
> ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/java/InstanceOfNode.java
> ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/LoweringPhase.java
> ! graal/com.oracle.graal.replacements/src/com/oracle/graal/replacements/InstanceOfSnippetsTemplates.java
> 
> Changeset: 31266ceb86ef
> Author:    twisti
> Date:      2013-07-10 12:50 -0700
> URL:       http://hg.openjdk.java.net/graal/graal/rev/31266ceb86ef
> 
> SPARC: Can compile and run two or three methods of a bootstrap.
> 
> ! 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.asm.sparc/src/com/oracle/graal/asm/sparc/SPARCMacroAssembler.java
> ! graal/com.oracle.graal.compiler.sparc/src/com/oracle/graal/compiler/sparc/SPARCLIRGenerator.java
> ! graal/com.oracle.graal.hotspot.sparc/src/com/oracle/graal/hotspot/sparc/SPARCHotSpotBackend.java
> ! graal/com.oracle.graal.hotspot.sparc/src/com/oracle/graal/hotspot/sparc/SPARCHotSpotLIRGenerator.java
> ! graal/com.oracle.graal.hotspot.sparc/src/com/oracle/graal/hotspot/sparc/SPARCHotSpotRuntime.java
> + graal/com.oracle.graal.hotspot.sparc/src/com/oracle/graal/hotspot/sparc/SPARCSafepointOp.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
> 
> Changeset: 8c8e47cc101d
> Author:    Christian Humer <christian.humer at gmail.com>
> Date:      2013-07-11 01:55 +0200
> URL:       http://hg.openjdk.java.net/graal/graal/rev/8c8e47cc101d
> 
> Truffle-DSL: fixed a bug in removal of the frame from the generated generic execute method.
> 
> ! graal/com.oracle.truffle.dsl.processor/src/com/oracle/truffle/dsl/processor/node/NodeCodeGenerator.java
> ! graal/com.oracle.truffle.dsl.processor/src/com/oracle/truffle/dsl/processor/node/NodeData.java
> ! graal/com.oracle.truffle.dsl.processor/src/com/oracle/truffle/dsl/processor/node/NodeParser.java
> 
> Changeset: 062304c74353
> Author:    Christian Humer <christian.humer at gmail.com>
> Date:      2013-07-11 01:56 +0200
> URL:       http://hg.openjdk.java.net/graal/graal/rev/062304c74353
> 
> merge.
> 
> 
> Changeset: 5c1afcee72ec
> Author:    Thomas Wuerthinger <thomas.wuerthinger at oracle.com>
> Date:      2013-07-10 19:48 -0700
> URL:       http://hg.openjdk.java.net/graal/graal/rev/5c1afcee72ec
> 
> Relax TruffleCache assertion.
> 
> ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/TruffleCache.java
> 
> Changeset: 4109190a0da5
> Author:    Roland Schatz <roland.schatz at oracle.com>
> Date:      2013-07-11 11:09 +0200
> URL:       http://hg.openjdk.java.net/graal/graal/rev/4109190a0da5
> 
> Move lowering of arraycopy to the correct lowering phase.
> 
> ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/UnsafeArrayCopyNode.java
> 
> Changeset: 58cb83bfd882
> Author:    Christos Kotselidis <christos.kotselidis at oracle.com>
> Date:      2013-07-11 11:55 +0200
> URL:       http://hg.openjdk.java.net/graal/graal/rev/58cb83bfd882
> 
> Simplify code
> 
> ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/NewObjectSnippets.java
> 
> Changeset: 2a87417379ce
> Author:    Christos Kotselidis <christos.kotselidis at oracle.com>
> Date:      2013-07-11 11:56 +0200
> URL:       http://hg.openjdk.java.net/graal/graal/rev/2a87417379ce
> 
> Remove ternary
> 
> ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/ObjectCloneSnippets.java
> 
> Changeset: f1cd428fca9f
> Author:    Christos Kotselidis <christos.kotselidis at oracle.com>
> Date:      2013-07-11 11:58 +0200
> URL:       http://hg.openjdk.java.net/graal/graal/rev/f1cd428fca9f
> 
> Remove caching of gcStartCycles
> 
> ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/WriteBarrierSnippets.java
> 
> Changeset: b95d42fdddca
> Author:    Christos Kotselidis <christos.kotselidis at oracle.com>
> Date:      2013-07-11 12:09 +0200
> URL:       http://hg.openjdk.java.net/graal/graal/rev/b95d42fdddca
> 
> Minor refactoring
> 
> ! src/share/vm/gc_interface/collectedHeap.hpp
> 
> Changeset: 7cdd4708b1aa
> Author:    Christos Kotselidis <christos.kotselidis at oracle.com>
> Date:      2013-07-11 12:10 +0200
> URL:       http://hg.openjdk.java.net/graal/graal/rev/7cdd4708b1aa
> 
> Merge
> 
> 
> Changeset: 84b944726df2
> Author:    Andreas Woess <andreas.woess at jku.at>
> Date:      2013-07-11 12:22 +0200
> URL:       http://hg.openjdk.java.net/graal/graal/rev/84b944726df2
> 
> Truffle: introduce NodeUtil.countNodes
> 
> ! graal/com.oracle.truffle.api/src/com/oracle/truffle/api/nodes/NodeUtil.java
> 
> Changeset: fd53f9f7007b
> Author:    Andreas Woess <andreas.woess at jku.at>
> Date:      2013-07-11 13:09 +0200
> URL:       http://hg.openjdk.java.net/graal/graal/rev/fd53f9f7007b
> 
> Truffle: refactor inlining
> 
> ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/OptimizedCallTarget.java
> ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/TruffleCompilerOptions.java
> 
> Changeset: 8d961f93725c
> Author:    Gilles Duboscq <duboscq at ssw.jku.at>
> Date:      2013-07-09 18:17 +0200
> URL:       http://hg.openjdk.java.net/graal/graal/rev/8d961f93725c
> 
> Use GuardedValueNode in the inlining
> 
> ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/GuardedValueNode.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
> 
> Changeset: a643c88d164f
> Author:    Gilles Duboscq <duboscq at ssw.jku.at>
> Date:      2013-07-11 14:45 +0200
> URL:       http://hg.openjdk.java.net/graal/graal/rev/a643c88d164f
> 
> Add scopes to capture the graphs in ReplacementsImpl
> 
> ! graal/com.oracle.graal.replacements/src/com/oracle/graal/replacements/ReplacementsImpl.java
> 
> Changeset: 41e9c8845826
> Author:    Gilles Duboscq <duboscq at ssw.jku.at>
> Date:      2013-07-11 14:47 +0200
> URL:       http://hg.openjdk.java.net/graal/graal/rev/41e9c8845826
> 
> Improve instanceof canonicalization
> 
> ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/java/InstanceOfNode.java
> 
> Changeset: 5888e1772ba1
> Author:    Roland Schatz <roland.schatz at oracle.com>
> Date:      2013-07-11 16:21 +0200
> URL:       http://hg.openjdk.java.net/graal/graal/rev/5888e1772ba1
> 
> Check that guards are only created in BEFORE_GUARDS lowering.
> 
> ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/LoweringPhase.java
> 
> Changeset: cd28ead65a53
> Author:    Roland Schatz <roland.schatz at oracle.com>
> Date:      2013-07-11 16:21 +0200
> URL:       http://hg.openjdk.java.net/graal/graal/rev/cd28ead65a53
> 
> Output lowering type in graph dumps.
> 
> ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/LoweringPhase.java
> 
> Changeset: 68d4d5457546
> Author:    Doug Simon <doug.simon at oracle.com>
> Date:      2013-07-11 20:56 +0200
> URL:       http://hg.openjdk.java.net/graal/graal/rev/68d4d5457546
> 
> add sequential id prefixes to IGV graphs
> 
> ! graal/com.oracle.graal.printer/src/com/oracle/graal/printer/GraphPrinterDumpHandler.java
> 
> Changeset: 7f50d79c46f2
> Author:    Doug Simon <doug.simon at oracle.com>
> Date:      2013-07-11 20:57 +0200
> URL:       http://hg.openjdk.java.net/graal/graal/rev/7f50d79c46f2
> 
> fixed a stamp join to be done the "right" way (stamp joining is not currently commutative)
> 
> ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/java/CheckCastNode.java
> 
> Changeset: 057154505878
> Author:    Doug Simon <doug.simon at oracle.com>
> Date:      2013-07-11 20:58 +0200
> URL:       http://hg.openjdk.java.net/graal/graal/rev/057154505878
> 
> fixed canonicalization bug (detected by Gilles) in binary logic nodes
> 
> ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/LogicConjunctionNode.java
> ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/LogicConstantNode.java
> ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/LogicDisjunctionNode.java
> 
> Changeset: 28dc33dc4565
> Author:    Christos Kotselidis <christos.kotselidis at oracle.com>
> Date:      2013-07-12 12:24 +0200
> URL:       http://hg.openjdk.java.net/graal/graal/rev/28dc33dc4565
> 
> Delegate compressed klass pointers info from HotSpot to Graal
> 
> ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/HotSpotVMConfig.java
> ! src/share/vm/graal/graalCompilerToVM.cpp
> 
> Changeset: c3760150dc29
> Author:    Christos Kotselidis <christos.kotselidis at oracle.com>
> Date:      2013-07-12 12:40 +0200
> URL:       http://hg.openjdk.java.net/graal/graal/rev/c3760150dc29
> 
> Add function to read compressed klass pointers of constant objects natively
> 
> ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/HotSpotGraalRuntime.java
> ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/bridge/CompilerToVM.java
> ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/bridge/CompilerToVMImpl.java
> ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotRuntime.java
> ! src/share/vm/graal/graalCompilerToVM.cpp
> 
> Changeset: b975cad32411
> Author:    Christos Kotselidis <christos.kotselidis at oracle.com>
> Date:      2013-07-12 12:42 +0200
> URL:       http://hg.openjdk.java.net/graal/graal/rev/b975cad32411
> 
> Add StoreHubNode
> 
> + graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/extended/StoreHubNode.java
> 
> Changeset: 0517026315a0
> Author:    Christos Kotselidis <christos.kotselidis at oracle.com>
> Date:      2013-07-12 12:46 +0200
> URL:       http://hg.openjdk.java.net/graal/graal/rev/0517026315a0
> 
> Adjust header size to compressed klass pointers
> 
> ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/HotSpotReplacementsUtil.java
> ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/NewObjectSnippets.java
> ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/ObjectCloneSnippets.java
> ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/stubs/NewInstanceStub.java
> 
> Changeset: 0d3d300064a8
> Author:    Christos Kotselidis <christos.kotselidis at oracle.com>
> Date:      2013-07-12 12:47 +0200
> URL:       http://hg.openjdk.java.net/graal/graal/rev/0d3d300064a8
> 
> Remove scratch register from compressed load LIR instruction (used only for testing)
> 
> ! 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: 867588b3ecb4
> Author:    Christos Kotselidis <christos.kotselidis at oracle.com>
> Date:      2013-07-12 12:48 +0200
> URL:       http://hg.openjdk.java.net/graal/graal/rev/867588b3ecb4
> 
> Variables' renaming
> 
> ! graal/com.oracle.graal.lir.amd64/src/com/oracle/graal/lir/amd64/AMD64Move.java
> 
> Changeset: 7cc08d83111d
> Author:    Lukas Stadler <lukas.stadler at jku.at>
> Date:      2013-07-12 15:29 +0200
> URL:       http://hg.openjdk.java.net/graal/graal/rev/7cc08d83111d
> 
> correctly anchor eliminated guards during ConditionalElimination
> 
> ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/ConditionalEliminationPhase.java
> 
> Changeset: 5fc4aedf7910
> Author:    Lukas Stadler <lukas.stadler at jku.at>
> Date:      2013-07-12 15:30 +0200
> URL:       http://hg.openjdk.java.net/graal/graal/rev/5fc4aedf7910
> 
> add relative pc to uncommon trap event entry (helps debugging SEGFAULTs in copmiled code)
> 
> ! src/share/vm/runtime/deoptimization.cpp
> 
> Changeset: c84048228b4a
> Author:    Lukas Stadler <lukas.stadler at jku.at>
> Date:      2013-07-12 17:01 +0200
> URL:       http://hg.openjdk.java.net/graal/graal/rev/c84048228b4a
> 
> prevent repeated simplification of FixedGuardNode
> 
> ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/FixedGuardNode.java
> 
> Changeset: 097a634b57b1
> Author:    Lukas Stadler <lukas.stadler at jku.at>
> Date:      2013-07-12 11:19 +0200
> URL:       http://hg.openjdk.java.net/graal/graal/rev/097a634b57b1
> 
> fix stamps for constants of boolean, byte, char and short type, add tests
> 
> + graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/IntegerStampTest.java
> ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/type/StampFactory.java
> 
> Changeset: 0e671d5268d1
> Author:    Lukas Stadler <lukas.stadler at jku.at>
> Date:      2013-07-11 14:57 +0200
> URL:       http://hg.openjdk.java.net/graal/graal/rev/0e671d5268d1
> 
> re-introduce early read elimination as part of escape analysis
> 
> ! 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/PartialEscapePhase.java
> + graal/com.oracle.graal.virtual/src/com/oracle/graal/virtual/phases/ea/ReadEliminationPEBlockState.java
> + graal/com.oracle.graal.virtual/src/com/oracle/graal/virtual/phases/ea/ReadEliminationPEClosure.java
> 
> Changeset: e35a72e32aae
> Author:    Lukas Stadler <lukas.stadler at jku.at>
> Date:      2013-07-11 15:13 +0200
> URL:       http://hg.openjdk.java.net/graal/graal/rev/e35a72e32aae
> 
> add test for early read elimination
> 
> + graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/ea/PEAReadEliminationTest.java
> 
> Changeset: c78097171701
> Author:    Doug Simon <doug.simon at oracle.com>
> Date:      2013-07-12 14:48 +0200
> URL:       http://hg.openjdk.java.net/graal/graal/rev/c78097171701
> 
> made the "Remove selected graphs and groups" action work in IGV for binary graphs
> 
> ! src/share/tools/IdealGraphVisualizer/Coordinator/src/com/sun/hotspot/igv/coordinator/OutlineTopComponent.java
> ! src/share/tools/IdealGraphVisualizer/Coordinator/src/com/sun/hotspot/igv/coordinator/actions/ImportAction.java
> ! src/share/tools/IdealGraphVisualizer/Data/src/com/sun/hotspot/igv/data/serialization/BinaryParser.java
> ! src/share/tools/IdealGraphVisualizer/NetworkConnection/src/com/sun/hotspot/igv/connection/Client.java
> ! src/share/tools/IdealGraphVisualizer/NetworkConnection/src/com/sun/hotspot/igv/connection/Server.java
> 
> Changeset: 9d079661cbcd
> Author:    Doug Simon <doug.simon at oracle.com>
> Date:      2013-07-12 18:08 +0200
> URL:       http://hg.openjdk.java.net/graal/graal/rev/9d079661cbcd
> 
> fixed generation of sequential id prefixes for IGV graphs
> 
> ! graal/com.oracle.graal.printer/src/com/oracle/graal/printer/GraphPrinterDumpHandler.java
> 
> Changeset: 70cb17338a70
> Author:    Doug Simon <doug.simon at oracle.com>
> Date:      2013-07-12 18:09 +0200
> URL:       http://hg.openjdk.java.net/graal/graal/rev/70cb17338a70
> 
> Merge.
> 
> 
> Changeset: 2a4ad6ab345e
> Author:    Doug Simon <doug.simon at oracle.com>
> Date:      2013-07-12 19:09 +0200
> URL:       http://hg.openjdk.java.net/graal/graal/rev/2a4ad6ab345e
> 
> disabled new lowering of checkcast until performance regression is fixed
> 
> ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/java/CheckCastNode.java
> 
> Changeset: f1904749e4fe
> Author:    Doug Simon <doug.simon at oracle.com>
> Date:      2013-07-12 22:52 +0200
> URL:       http://hg.openjdk.java.net/graal/graal/rev/f1904749e4fe
> 
> re-enabled new lowering of checkcast with addition of a null-check guard where the profile has nullSeen=FALSE
> 
> ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/java/CheckCastNode.java
> 
> Changeset: 40f6bda3f91d
> Author:    Christos Kotselidis <christos.kotselidis at oracle.com>
> Date:      2013-07-12 14:16 +0200
> URL:       http://hg.openjdk.java.net/graal/graal/rev/40f6bda3f91d
> 
> Add compressed klass pointers support in LIR
> 
> ! 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: 0bd794eb8222
> Author:    Christos Kotselidis <christos.kotselidis at oracle.com>
> Date:      2013-07-12 14:17 +0200
> URL:       http://hg.openjdk.java.net/graal/graal/rev/0bd794eb8222
> 
> Add compressed oop support in HotSpot Backend
> 
> ! graal/com.oracle.graal.hotspot.amd64/src/com/oracle/graal/hotspot/amd64/AMD64HotSpotBackend.java
> 
> Changeset: 6621bc66bfa4
> Author:    Christos Kotselidis <christos.kotselidis at oracle.com>
> Date:      2013-07-12 14:20 +0200
> URL:       http://hg.openjdk.java.net/graal/graal/rev/6621bc66bfa4
> 
> Add WriteHubNode lowering
> 
> ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotRuntime.java
> 
> Changeset: 8b8587c32812
> Author:    Christos Kotselidis <christos.kotselidis at oracle.com>
> Date:      2013-07-12 14:38 +0200
> URL:       http://hg.openjdk.java.net/graal/graal/rev/8b8587c32812
> 
> Adjust load/store hub intrinsics to account for Compressed Klass pointers
> 
> ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/HotSpotReplacementsUtil.java
> 
> Changeset: 49a0bd6b0605
> Author:    Christos Kotselidis <christos.kotselidis at oracle.com>
> Date:      2013-07-12 14:40 +0200
> URL:       http://hg.openjdk.java.net/graal/graal/rev/49a0bd6b0605
> 
> Delegate compressed klass pointers info to ReadNode of LoadHubNode
> 
> ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotRuntime.java
> 
> Changeset: 90b3cf36dc17
> Author:    Christos Kotselidis <christos.kotselidis at oracle.com>
> Date:      2013-07-12 14:43 +0200
> URL:       http://hg.openjdk.java.net/graal/graal/rev/90b3cf36dc17
> 
> Replace direct read word with loadHub intrinsic in VerifyOop stub
> 
> ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/stubs/StubUtil.java
> 
> Changeset: 060f9ed42e2f
> Author:    Christos Kotselidis <christos.kotselidis at oracle.com>
> Date:      2013-07-12 14:58 +0200
> URL:       http://hg.openjdk.java.net/graal/graal/rev/060f9ed42e2f
> 
> Augment compressed oop tests
> 
> ! graal/com.oracle.graal.hotspot.test/src/com/oracle/graal/hotspot/test/CompressedOopTest.java
> 
> Changeset: 88992c295d47
> Author:    Christos Kotselidis <christos.kotselidis at oracle.com>
> Date:      2013-07-12 20:19 +0200
> URL:       http://hg.openjdk.java.net/graal/graal/rev/88992c295d47
> 
> Merge
> 
> 
> Changeset: cdbfff4547be
> Author:    Christos Kotselidis <christos.kotselidis at oracle.com>
> Date:      2013-07-12 21:48 +0200
> URL:       http://hg.openjdk.java.net/graal/graal/rev/cdbfff4547be
> 
> Allow compressed klass pointers
> 
> ! src/share/vm/runtime/arguments.cpp
> 
> Changeset: bdd7c8e2293e
> Author:    Christos Kotselidis <christos.kotselidis at oracle.com>
> Date:      2013-07-12 23:26 +0200
> URL:       http://hg.openjdk.java.net/graal/graal/rev/bdd7c8e2293e
> 
> Merge
> 
> 
> Changeset: 00a9dbcbe431
> Author:    Christian Humer <christian.humer at gmail.com>
> Date:      2013-07-13 17:13 +0200
> URL:       http://hg.openjdk.java.net/graal/graal/rev/00a9dbcbe431
> 
> Truffle-DSL: Fixed a bug in polymorphic code generation.
> 
> ! graal/com.oracle.truffle.dsl.processor/src/com/oracle/truffle/dsl/processor/node/NodeCodeGenerator.java
> 
> Changeset: 99789440ce28
> Author:    Christian Humer <christian.humer at gmail.com>
> Date:      2013-07-13 17:14 +0200
> URL:       http://hg.openjdk.java.net/graal/graal/rev/99789440ce28
> 
> Truffle: Added assertions to replaceChild.
> 
> ! graal/com.oracle.truffle.api/src/com/oracle/truffle/api/nodes/NodeUtil.java
> 
> Changeset: ff6eb563a2e2
> Author:    Christian Humer <christian.humer at gmail.com>
> Date:      2013-07-13 17:21 +0200
> URL:       http://hg.openjdk.java.net/graal/graal/rev/ff6eb563a2e2
> 
> Truffle-DSL: Added additional test case for polymporphic generation.
> 
> + graal/com.oracle.truffle.api.dsl.test/src/com/oracle/truffle/api/dsl/test/PolymorphicTest2.java
> 
> Changeset: 45dc193567c2
> Author:    Christos Kotselidis <christos.kotselidis at oracle.com>
> Date:      2013-07-15 10:48 +0200
> URL:       http://hg.openjdk.java.net/graal/graal/rev/45dc193567c2
> 
> Add assertions
> 
> ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotRuntime.java
> 
> Changeset: cbaf26740df8
> Author:    Christos Kotselidis <christos.kotselidis at oracle.com>
> Date:      2013-07-15 10:50 +0200
> URL:       http://hg.openjdk.java.net/graal/graal/rev/cbaf26740df8
> 
> 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/NewObjectSnippets.java
> ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/ObjectCloneSnippets.java
> ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/stubs/NewInstanceStub.java
> 
> Changeset: 257e2455270e
> Author:    Christos Kotselidis <christos.kotselidis at oracle.com>
> Date:      2013-07-15 10:59 +0200
> URL:       http://hg.openjdk.java.net/graal/graal/rev/257e2455270e
> 
> Merge
> 
> 
> Changeset: 3811d04d933e
> Author:    Roland Schatz <roland.schatz at oracle.com>
> Date:      2013-07-15 12:02 +0200
> URL:       http://hg.openjdk.java.net/graal/graal/rev/3811d04d933e
> 
> Do not re-compress oops that are already compressed.
> 
> ! graal/com.oracle.graal.hotspot.amd64/src/com/oracle/graal/hotspot/amd64/AMD64HotSpotLIRGenerator.java
> 
> Changeset: a5c9bc1f28fb
> Author:    Lukas Stadler <lukas.stadler at jku.at>
> Date:      2013-07-15 13:11 +0200
> URL:       http://hg.openjdk.java.net/graal/graal/rev/a5c9bc1f28fb
> 
> fix nullness for not-equals in ConditionalEliminationPhase
> bug reported by Miguel Garcia <miguelalfredo.garcia at epfl.ch>
> 
> ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/ConditionalEliminationPhase.java
> 
> Changeset: e7c0658c2f25
> Author:    Lukas Stadler <lukas.stadler at jku.at>
> Date:      2013-07-15 13:36 +0200
> URL:       http://hg.openjdk.java.net/graal/graal/rev/e7c0658c2f25
> 
> record disjunctive conditions in ConditionalEliminationPhase
> change suggested by Miguel Garcia <miguelalfredo.garcia at epfl.ch>
> 
> ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/ConditionalEliminationPhase.java
> 
> Changeset: 9f5a4074e36b
> Author:    Lukas Stadler <lukas.stadler at jku.at>
> Date:      2013-07-15 13:36 +0200
> URL:       http://hg.openjdk.java.net/graal/graal/rev/9f5a4074e36b
> 
> test for nullness and disjunctive conditions in ConditionalEliminationPhase
> 
> ! graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/ConditionalEliminationTest.java
> 
> Changeset: 7b5d7c42598b
> Author:    Andreas Woess <andreas.woess at jku.at>
> Date:      2013-07-11 19:34 +0200
> URL:       http://hg.openjdk.java.net/graal/graal/rev/7b5d7c42598b
> 
> Truffle: change sorting of inlinable call sites
> 
> ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/OptimizedCallTarget.java
> 
> Changeset: e2f5ae9afdc5
> Author:    Andreas Woess <andreas.woess at jku.at>
> Date:      2013-07-11 22:14 +0200
> URL:       http://hg.openjdk.java.net/graal/graal/rev/e2f5ae9afdc5
> 
> Truffle: introduce profiling option
> 
> ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/GraalTruffleRuntime.java
> ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/OptimizedCallTarget.java
> ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/TruffleCompilerOptions.java
> 
> Changeset: 64740220db85
> Author:    Andreas Woess <andreas.woess at jku.at>
> Date:      2013-07-15 14:09 +0200
> URL:       http://hg.openjdk.java.net/graal/graal/rev/64740220db85
> 
> Merge
> 
> 
> Changeset: 4c12d3756015
> Author:    Andreas Woess <andreas.woess at jku.at>
> Date:      2013-07-15 14:12 +0200
> URL:       http://hg.openjdk.java.net/graal/graal/rev/4c12d3756015
> 
> Truffle: Never compile InvalidInstalledCodeException catch handler.
> 
> ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/TruffleCompilerImpl.java
> 
> Changeset: b221e31d7b0b
> Author:    Andreas Woess <andreas.woess at jku.at>
> Date:      2013-07-15 15:26 +0200
> URL:       http://hg.openjdk.java.net/graal/graal/rev/b221e31d7b0b
> 
> Truffle: revise NodeUtil.replaceChild assertion
> 
> ! graal/com.oracle.truffle.api/src/com/oracle/truffle/api/nodes/NodeUtil.java
> 
> Changeset: 7f6580db1e88
> Author:    Andreas Woess <andreas.woess at jku.at>
> Date:      2013-07-15 14:49 +0200
> URL:       http://hg.openjdk.java.net/graal/graal/rev/7f6580db1e88
> 
> Truffle: add assertions to verify the finalness of child fields.
> 
> ! graal/com.oracle.truffle.api.test/src/com/oracle/truffle/api/test/ReplaceTest.java
> ! graal/com.oracle.truffle.api/src/com/oracle/truffle/api/nodes/NodeUtil.java
> 
> Changeset: f4f46b734a4c
> Author:    Andreas Woess <andreas.woess at jku.at>
> Date:      2013-07-15 15:29 +0200
> URL:       http://hg.openjdk.java.net/graal/graal/rev/f4f46b734a4c
> 
> Merge
> 
> 
> Changeset: e82c28e94f08
> Author:    Roland Schatz <roland.schatz at oracle.com>
> Date:      2013-07-15 16:24 +0200
> URL:       http://hg.openjdk.java.net/graal/graal/rev/e82c28e94f08
> 
> Don't add G1 prebarrier if the written location is uninitialized.
> 
> ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/phases/WriteBarrierAdditionPhase.java
> ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/UnsafeArrayCopyNode.java
> ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/extended/ArrayRangeWriteNode.java
> ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/extended/WriteNode.java
> 
> Changeset: 7f186f1486f7
> Author:    Roland Schatz <roland.schatz at oracle.com>
> Date:      2013-07-15 16:24 +0200
> URL:       http://hg.openjdk.java.net/graal/graal/rev/7f186f1486f7
> 
> Use initializing write node in object clone snippets.
> 
> ! 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: 59d2d6a30d29
> Author:    Roland Schatz <roland.schatz at oracle.com>
> Date:      2013-07-15 16:24 +0200
> URL:       http://hg.openjdk.java.net/graal/graal/rev/59d2d6a30d29
> 
> Re-enable omission of array initialization for G1.
> 
> ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/NewObjectSnippets.java
> ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/ObjectCloneSnippets.java
> 
> Changeset: dd7a8807378b
> Author:    Doug Simon <doug.simon at oracle.com>
> Date:      2013-07-15 16:53 +0200
> URL:       http://hg.openjdk.java.net/graal/graal/rev/dd7a8807378b
> 
> cannot omit frame for compiled methods that make a foreign call (GRAAL-362)
> 
> ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/gen/LIRGenerator.java
> ! graal/com.oracle.graal.hotspot.amd64/src/com/oracle/graal/hotspot/amd64/AMD64HotSpotBackend.java
> 
> Changeset: c483912aaf70
> Author:    Lukas Stadler <lukas.stadler at jku.at>
> Date:      2013-07-15 16:39 +0200
> URL:       http://hg.openjdk.java.net/graal/graal/rev/c483912aaf70
> 
> add ValueProxy interface and infrastructure
> 
> ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/GuardedValueNode.java
> ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/GuardingPiNode.java
> ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/PiNode.java
> ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/ProxyNode.java
> ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/TypeProfileProxyNode.java
> ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/java/CheckCastNode.java
> + graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/spi/ValueProxy.java
> ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/util/GraphUtil.java
> 
> Changeset: 5e338844c64c
> Author:    Lukas Stadler <lukas.stadler at jku.at>
> Date:      2013-07-15 15:58 +0200
> URL:       http://hg.openjdk.java.net/graal/graal/rev/5e338844c64c
> 
> make early read elimination see through ValueProxies
> 
> ! graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/ea/PEAReadEliminationTest.java
> ! graal/com.oracle.graal.virtual/src/com/oracle/graal/virtual/phases/ea/ReadEliminationPEClosure.java
> 
> Changeset: d2f8addaf504
> Author:    Lukas Stadler <lukas.stadler at jku.at>
> Date:      2013-07-15 15:58 +0200
> URL:       http://hg.openjdk.java.net/graal/graal/rev/d2f8addaf504
> 
> assertion in GraalCompiler (don't parse @Test methods)
> 
> ! graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/GraalCompilerTest.java
> 
> Changeset: ae3d070ab223
> Author:    Lukas Stadler <lukas.stadler at jku.at>
> Date:      2013-07-15 16:36 +0200
> URL:       http://hg.openjdk.java.net/graal/graal/rev/ae3d070ab223
> 
> make ValueNode.stamp() final, fix WordTypeRewriterPhase
> 
> ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/ProxyNode.java
> ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/TypeProfileProxyNode.java
> ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/ValueNode.java
> ! graal/com.oracle.graal.word/src/com/oracle/graal/word/phases/WordTypeRewriterPhase.java
> 
> Changeset: 3a044e575466
> Author:    Lukas Stadler <lukas.stadler at jku.at>
> Date:      2013-07-15 17:32 +0200
> URL:       http://hg.openjdk.java.net/graal/graal/rev/3a044e575466
> 
> add ValueProxy interface to FixedValueAnchorNode
> 
> ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/nodes/FixedValueAnchorNode.java
> 
> Changeset: 88d0dc388450
> Author:    Lukas Stadler <lukas.stadler at jku.at>
> Date:      2013-07-15 17:52 +0200
> URL:       http://hg.openjdk.java.net/graal/graal/rev/88d0dc388450
> 
> let ConditionalEliminationPhase change invokes to InvokeKind.Special based on type information
> 
> ! 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: 058abc2b59a5
> Author:    Lukas Stadler <lukas.stadler at jku.at>
> Date:      2013-07-15 17:54 +0200
> URL:       http://hg.openjdk.java.net/graal/graal/rev/058abc2b59a5
> 
> Merge
> 
> ! graal/com.oracle.graal.word/src/com/oracle/graal/word/phases/WordTypeRewriterPhase.java
> 
> Changeset: 395d34c10e26
> Author:    Doug Simon <doug.simon at oracle.com>
> Date:      2013-07-15 18:22 +0200
> URL:       http://hg.openjdk.java.net/graal/graal/rev/395d34c10e26
> 
> HSAIL backend changes
> Contributed-by: Tom Deneau <tom.deneau at amd.com>
> 
> * stackslot mapping was incorrect when combinations of 32-bit and
> 64-bit stores were generated.  StackSlot alignment in
> HSAILTargetDescription set to 8.
> 
> * compressedOops support in various heap size configurations (with or
> without either of shift or heap base).  So we don't need
> XX:-UseCompressedOops anymore.
> 
> * some support for unsigned shifts, long shifts, logical ops for long
> datatype.
> 
> * a new GraalOption, InlineEverything.  Some HSAIL targets are not
> able to handle HSAIL function calls yet, plus we are still working
> on emitting HSAIL function calls in the compiler.
> 
> * hack for emitForeignCall special cases of createOutOfBoundsException
> or createNullPointerException.  (We just emit a comment.  Real
> exception handling still pending).  These nodes came about when we
> more aggressively inlined, although this has not been explained yet.
> 
> * support HSAILAddressValues as operands for arithmetic ops.  Use
> HSAIL lda instruction to get address into a register.  Used in
> particular for USHR for card-marking.
> 
> * Added some new junit tests. (some ported from their lambda versions)
> 
>  * StaticNBodyCallTest which would fail with default inlining (since
>    we don't yet generate HSAIL calls).  It uses junit.assumeTrue and
>    tests whether InlineEverything is set.  It (and also some
>    lambda-based junit tests not part of this webrev) do pass nicely
>    when InlineEverything is set true.
> 
>  * tests for storing an object, which test being able to handle the
>    card-marking logic, as well as the encoding and decoding of a
>    compressed oop.
> 
>  * some 2D matrix tests that showed a problem before the stackslot
>    change above.  (have a mixture of 32-bit and 64-bit stackslot
>    spills)
> 
> ! graal/com.oracle.graal.asm.hsail/src/com/oracle/graal/asm/hsail/HSAILAssembler.java
> ! graal/com.oracle.graal.compiler.hsail.test.infra/src/com/oracle/graal/compiler/hsail/test/infra/GraalKernelTester.java
> ! graal/com.oracle.graal.compiler.hsail.test.infra/src/com/oracle/graal/compiler/hsail/test/infra/KernelTester.java
> + graal/com.oracle.graal.compiler.hsail.test/src/com/oracle/graal/compiler/hsail/test/Float2DMatrixBase.java
> + graal/com.oracle.graal.compiler.hsail.test/src/com/oracle/graal/compiler/hsail/test/Float2DMatrixMultiplyRangeFinalTest.java
> + graal/com.oracle.graal.compiler.hsail.test/src/com/oracle/graal/compiler/hsail/test/Float2DMatrixMultiplyTest.java
> + graal/com.oracle.graal.compiler.hsail.test/src/com/oracle/graal/compiler/hsail/test/ObjectStoreNullTest.java
> + graal/com.oracle.graal.compiler.hsail.test/src/com/oracle/graal/compiler/hsail/test/ObjectStoreTest.java
> ! graal/com.oracle.graal.compiler.hsail.test/src/com/oracle/graal/compiler/hsail/test/StaticMandelTest.java
> + graal/com.oracle.graal.compiler.hsail.test/src/com/oracle/graal/compiler/hsail/test/StaticNBodyCallTest.java
> ! graal/com.oracle.graal.compiler.hsail/src/com/oracle/graal/compiler/hsail/HSAILCompilationResult.java
> ! graal/com.oracle.graal.compiler.hsail/src/com/oracle/graal/compiler/hsail/HSAILLIRGenerator.java
> ! graal/com.oracle.graal.lir.hsail/src/com/oracle/graal/lir/hsail/HSAILArithmetic.java
> ! graal/com.oracle.graal.lir.hsail/src/com/oracle/graal/lir/hsail/HSAILControlFlow.java
> ! graal/com.oracle.graal.lir.hsail/src/com/oracle/graal/lir/hsail/HSAILMove.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
> 
> 
> 


From tom.deneau at amd.com  Tue Jul 16 10:10:44 2013
From: tom.deneau at amd.com (Deneau, Tom)
Date: Tue, 16 Jul 2013 17:10:44 +0000
Subject: graal/graal: 107 new changesets
In-Reply-To: <A6D3A38A-FD4A-4179-AF70-B5A4E766677A@oracle.com>
References: <20130715170157.A77A4480BF@hg.openjdk.java.net>
	<BC97738F8E7C8742BABED7F06FB9DF91450454E9@sausexdag01.amd.com>
	<A6D3A38A-FD4A-4179-AF70-B5A4E766677A@oracle.com>
Message-ID: <BC97738F8E7C8742BABED7F06FB9DF91450459B9@sausexdag01.amd.com>

Doug --

So do you recommend we just consider it fixed until it shows up again?
(rather than trying to debug the earlier drop of the trunk which showed the problem)

-- Tom

-----Original Message-----
From: Doug Simon [mailto:doug.simon at oracle.com] 
Sent: Tuesday, July 16, 2013 11:48 AM
To: Deneau, Tom
Cc: graal-dev at openjdk.java.net
Subject: Re: graal/graal: 107 new changesets

Sorry, I can't think of what the problem is/was.

On Jul 15, 2013, at 11:05 PM, "Deneau, Tom" <tom.deneau at amd.com> wrote:

> Doug or others --
> 
> I was about to ask for help on a codegen problem we were seeing but after updating to the latest default,
> I see that it is gone (so I'm assuming it was not in our backend :) ).  Of course it is possible that the bug
> is just being hidden by some unrelated change.   Anyway, here is a brief description,
> maybe you can tell which of the many changesets below would have fixed this, if any.
> 
> We were using String.contains as our test case, which was being nicely inlined, and we generated the following 
> HSAIL code which led to the problem
> 
> 	ld_global_u16 $s8, [$d3 + 24];         // read a u16 char from the test String
> 	ld_global_u16 $s9, [$d1 + 24];         // read a u16 char from the pattern  
> 	st_spill_s32 $s9, [%spillseg][24];     // register spill
> 	mov_b32 $s8, 0;                        // <<<<--- This code was causing the problem 
> 	cmp_ne_b1_s32 $c0, $s8, $s9;           // compare the two chars but s8 has been clobbered
> 
> 
> When I did a -G:TraceLIRGeneratorLevel=2, I could see that the problematic instruction
> "mov_b32 $s8, 0"
> was generated as part of something called
>       MOVE TO PHI from 276|EndNode to 277|LoopBegin
> 
> as part of PhiResolver.dispose, the part that is commented with
>  // generate move for move from non variable to arbitrary destination
> 
> Does the above sound like something that was purposely fixed?
> 
> -- 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 at oracle.com
> Sent: Monday, July 15, 2013 11:56 AM
> To: graal-dev at openjdk.java.net
> Subject: hg: graal/graal: 107 new changesets
> 
> Changeset: 204d8d4f91a4
> Author:    Christian Haeubl <haeubl at ssw.jku.at>
> Date:      2013-07-09 11:18 +0200
> URL:       http://hg.openjdk.java.net/graal/graal/rev/204d8d4f91a4
> 
> Minor Java fix.
> 
> ! graal/com.oracle.graal.api.code/src/com/oracle/graal/api/code/Assumptions.java
> 
> Changeset: a9b76e1e5ab3
> Author:    Christian Haeubl <haeubl at ssw.jku.at>
> Date:      2013-07-09 11:19 +0200
> URL:       http://hg.openjdk.java.net/graal/graal/rev/a9b76e1e5ab3
> 
> Fix for OSR regression introduced with 88672775a26c.
> 
> ! src/share/vm/runtime/compilationPolicy.cpp
> 
> Changeset: dcee58529a1c
> Author:    Christian Haeubl <haeubl at ssw.jku.at>
> Date:      2013-07-09 11:21 +0200
> URL:       http://hg.openjdk.java.net/graal/graal/rev/dcee58529a1c
> 
> Merge.
> 
> - graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/nodes/HotSpotNmethodExecuteNode.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/HotSpotNmethodSubstitutions.java
> 
> Changeset: 9808158cfeab
> Author:    Roland Schatz <roland.schatz at oracle.com>
> Date:      2013-07-09 11:14 +0200
> URL:       http://hg.openjdk.java.net/graal/graal/rev/9808158cfeab
> 
> Allow foreign call stubs to be declared as leaf methods.
> 
> ! graal/com.oracle.graal.hotspot.amd64/src/com/oracle/graal/hotspot/amd64/AMD64HotSpotBackend.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/ForeignCallStub.java
> ! graal/com.oracle.graal.lir.amd64/src/com/oracle/graal/lir/amd64/AMD64SaveRegistersOp.java
> 
> Changeset: 5348b49b2a76
> Author:    Roland Schatz <roland.schatz at oracle.com>
> Date:      2013-07-09 11:57 +0200
> URL:       http://hg.openjdk.java.net/graal/graal/rev/5348b49b2a76
> 
> Assign framestates in snippet lowering after framestate assignment.
> 
> ! graal/com.oracle.graal.replacements/src/com/oracle/graal/replacements/SnippetTemplate.java
> 
> Changeset: 110444cbf1eb
> Author:    Roland Schatz <roland.schatz at oracle.com>
> Date:      2013-07-09 11:58 +0200
> URL:       http://hg.openjdk.java.net/graal/graal/rev/110444cbf1eb
> 
> Make FixedGuardNode a DeoptimizingNode.
> 
> ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/FixedGuardNode.java
> 
> Changeset: f11cd00d4115
> Author:    Roland Schatz <roland.schatz at oracle.com>
> Date:      2013-07-09 11:58 +0200
> URL:       http://hg.openjdk.java.net/graal/graal/rev/f11cd00d4115
> 
> Make G1PreWriteBarrier a DeoptimizingNode.
> 
> ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/phases/WriteBarrierAdditionPhase.java
> ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/WriteBarrierSnippets.java
> ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/G1PreWriteBarrier.java
> 
> Changeset: 5bab3272bb82
> Author:    Roland Schatz <roland.schatz at oracle.com>
> Date:      2013-07-09 11:58 +0200
> URL:       http://hg.openjdk.java.net/graal/graal/rev/5bab3272bb82
> 
> Make array allocations deoptimizing nodes.
> 
> ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/java/AbstractNewArrayNode.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
> 
> Changeset: 69089865435a
> Author:    Roland Schatz <roland.schatz at oracle.com>
> Date:      2013-07-09 11:58 +0200
> URL:       http://hg.openjdk.java.net/graal/graal/rev/69089865435a
> 
> New lowering phase after framestate assignment.
> 
> ! 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.nodes/src/com/oracle/graal/nodes/WriteBarrier.java
> ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/spi/Lowerable.java
> 
> Changeset: e7d07c9bb779
> Author:    Christian Haeubl <haeubl at ssw.jku.at>
> Date:      2013-07-09 17:53 +0200
> URL:       http://hg.openjdk.java.net/graal/graal/rev/e7d07c9bb779
> 
> Removed priority compilation queue.
> Fixed another race condition in the compilation queue.
> Removed Graal-specific compilation policy.
> 
> ! 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/CompilerThread.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.phases/src/com/oracle/graal/phases/GraalOptions.java
> ! src/cpu/x86/vm/templateInterpreter_x86_64.cpp
> ! src/share/vm/classfile/vmSymbols.hpp
> ! src/share/vm/graal/graalCompiler.cpp
> ! src/share/vm/graal/graalVMToCompiler.cpp
> ! src/share/vm/graal/graalVMToCompiler.hpp
> ! src/share/vm/oops/methodCounters.cpp
> ! src/share/vm/oops/methodCounters.hpp
> ! src/share/vm/runtime/compilationPolicy.cpp
> 
> Changeset: d59e7f94f28d
> Author:    Christian Haeubl <haeubl at ssw.jku.at>
> Date:      2013-07-09 17:54 +0200
> URL:       http://hg.openjdk.java.net/graal/graal/rev/d59e7f94f28d
> 
> Increased priority for compiler threads.
> 
> ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/CompilerThread.java
> 
> Changeset: 853a894e0d97
> Author:    Christian Haeubl <haeubl at ssw.jku.at>
> Date:      2013-07-09 17:55 +0200
> URL:       http://hg.openjdk.java.net/graal/graal/rev/853a894e0d97
> 
> Merge.
> 
> 
> Changeset: 41362ec88331
> Author:    Thomas Wuerthinger <thomas.wuerthinger at oracle.com>
> Date:      2013-07-09 14:33 +0200
> URL:       http://hg.openjdk.java.net/graal/graal/rev/41362ec88331
> 
> Improve Truffle graph cache.
> 
> ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/PartialEvaluator.java
> ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/TruffleCache.java
> 
> Changeset: 9db1377b0580
> Author:    Thomas Wuerthinger <thomas.wuerthinger at oracle.com>
> Date:      2013-07-09 17:38 +0200
> URL:       http://hg.openjdk.java.net/graal/graal/rev/9db1377b0580
> 
> Fix for TruffleCache.
> 
> ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/PartialEvaluator.java
> ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/TruffleCache.java
> ! graal/com.oracle.truffle.api/src/com/oracle/truffle/api/TruffleOptions.java
> ! graal/com.oracle.truffle.api/src/com/oracle/truffle/api/nodes/SlowPathException.java
> 
> Changeset: 3bbe14e492fb
> Author:    Thomas Wuerthinger <thomas.wuerthinger at oracle.com>
> Date:      2013-07-09 20:06 +0200
> URL:       http://hg.openjdk.java.net/graal/graal/rev/3bbe14e492fb
> 
> Introduce TruffleGraphMaxNodes option with default value 10000.
> 
> ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/PartialEvaluator.java
> ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/TruffleCompilerOptions.java
> 
> Changeset: 759415ed915a
> Author:    Thomas Wuerthinger <thomas.wuerthinger at oracle.com>
> Date:      2013-07-09 20:09 +0200
> URL:       http://hg.openjdk.java.net/graal/graal/rev/759415ed915a
> 
> Merge.
> 
> 
> Changeset: fa86a653bc0d
> Author:    Andreas Woess <andreas.woess at jku.at>
> Date:      2013-07-09 19:45 +0200
> URL:       http://hg.openjdk.java.net/graal/graal/rev/fa86a653bc0d
> 
> Truffle: ensure frame assumption is recorded for materialized frames
> 
> ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/nodes/FrameAccessNode.java
> 
> Changeset: 0c570e82cc1d
> Author:    Andreas Woess <andreas.woess at jku.at>
> Date:      2013-07-09 21:03 +0200
> URL:       http://hg.openjdk.java.net/graal/graal/rev/0c570e82cc1d
> 
> Truffle: minor cleanup
> 
> ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/FrameWithoutBoxing.java
> ! graal/com.oracle.truffle.api/src/com/oracle/truffle/api/impl/DefaultVirtualFrame.java
> 
> Changeset: 311abd52ffeb
> Author:    Andreas Woess <andreas.woess at jku.at>
> Date:      2013-07-09 21:20 +0200
> URL:       http://hg.openjdk.java.net/graal/graal/rev/311abd52ffeb
> 
> Merge
> 
> 
> Changeset: 725922588833
> Author:    Thomas Wuerthinger <thomas.wuerthinger at oracle.com>
> Date:      2013-07-09 21:53 +0200
> URL:       http://hg.openjdk.java.net/graal/graal/rev/725922588833
> 
> Fix Truffle cache inlining strategy to skip exception edges.
> 
> ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/TruffleCache.java
> ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/TruffleCompilerOptions.java
> 
> Changeset: ae4c79ee71d1
> Author:    Thomas Wuerthinger <thomas.wuerthinger at oracle.com>
> Date:      2013-07-09 22:05 +0200
> URL:       http://hg.openjdk.java.net/graal/graal/rev/ae4c79ee71d1
> 
> Merge.
> 
> 
> Changeset: 6ff467cdb105
> Author:    twisti
> Date:      2013-07-09 14:39 -0700
> URL:       http://hg.openjdk.java.net/graal/graal/rev/6ff467cdb105
> 
> Code installer changes for SPARC.
> 
> ! src/cpu/sparc/vm/graalCodeInstaller_sparc.hpp
> ! src/cpu/sparc/vm/sharedRuntime_sparc.cpp
> ! src/cpu/x86/vm/graalCodeInstaller_x86.hpp
> ! src/share/vm/graal/graalCodeInstaller.cpp
> ! src/share/vm/graal/graalCodeInstaller.hpp
> ! src/share/vm/prims/methodHandles.cpp
> 
> Changeset: 431eca622358
> Author:    twisti
> Date:      2013-07-09 15:37 -0700
> URL:       http://hg.openjdk.java.net/graal/graal/rev/431eca622358
> 
> SPARC: Fixed build errors.
> 
> ! src/share/vm/graal/graalCompilerToGPU.cpp
> ! src/share/vm/graal/graalCompilerToVM.hpp
> 
> Changeset: 73122b5edf6a
> Author:    twisti
> Date:      2013-07-09 15:37 -0700
> URL:       http://hg.openjdk.java.net/graal/graal/rev/73122b5edf6a
> 
> SPARC: Can compile simple methods and do static calls.
> 
> ! 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.asm.sparc/src/com/oracle/graal/asm/sparc/SPARCMacroAssembler.java
> ! graal/com.oracle.graal.compiler.sparc/src/com/oracle/graal/compiler/sparc/SPARCLIRGenerator.java
> ! graal/com.oracle.graal.hotspot.sparc/src/com/oracle/graal/hotspot/sparc/SPARCHotSpotBackend.java
> ! graal/com.oracle.graal.hotspot.sparc/src/com/oracle/graal/hotspot/sparc/SPARCHotSpotLIRGenerator.java
> ! graal/com.oracle.graal.hotspot.sparc/src/com/oracle/graal/hotspot/sparc/SPARCHotSpotRegisterConfig.java
> + graal/com.oracle.graal.hotspot.sparc/src/com/oracle/graal/hotspot/sparc/SPARCHotspotDirectStaticCallOp.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/SPARCCall.java
> ! graal/com.oracle.graal.lir.sparc/src/com/oracle/graal/lir/sparc/SPARCCompare.java
> ! graal/com.oracle.graal.lir.sparc/src/com/oracle/graal/lir/sparc/SPARCControlFlow.java
> ! graal/com.oracle.graal.lir.sparc/src/com/oracle/graal/lir/sparc/SPARCLIRInstruction.java
> ! graal/com.oracle.graal.lir.sparc/src/com/oracle/graal/lir/sparc/SPARCMathIntrinsicOp.java
> ! graal/com.oracle.graal.lir.sparc/src/com/oracle/graal/lir/sparc/SPARCMove.java
> ! graal/com.oracle.graal.lir.sparc/src/com/oracle/graal/lir/sparc/SPARCTestOp.java
> ! graal/com.oracle.graal.sparc/src/com/oracle/graal/sparc/SPARC.java
> 
> Changeset: d2055a110396
> Author:    Thomas Wuerthinger <thomas.wuerthinger at oracle.com>
> Date:      2013-07-10 05:26 +0200
> URL:       http://hg.openjdk.java.net/graal/graal/rev/d2055a110396
> 
> Introduce CompilerDirectives.SlowPath annotation.
> 
> ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/TruffleCache.java
> ! graal/com.oracle.truffle.api/src/com/oracle/truffle/api/CompilerDirectives.java
> 
> Changeset: 87d2df0a7624
> Author:    Thomas Wuerthinger <thomas.wuerthinger at oracle.com>
> Date:      2013-07-10 05:27 +0200
> URL:       http://hg.openjdk.java.net/graal/graal/rev/87d2df0a7624
> 
> Merge.
> 
> 
> Changeset: 3ae117e62905
> Author:    Christian Humer <christian.humer at gmail.com>
> Date:      2013-07-10 09:23 +0200
> URL:       http://hg.openjdk.java.net/graal/graal/rev/3ae117e62905
> 
> Removed frame argument for generic cases if not needed.
> Added @SlowPath annotation to generated generic cases.
> 
> ! graal/com.oracle.truffle.dsl.processor/src/com/oracle/truffle/dsl/processor/TruffleTypes.java
> ! graal/com.oracle.truffle.dsl.processor/src/com/oracle/truffle/dsl/processor/node/NodeCodeGenerator.java
> ! graal/com.oracle.truffle.dsl.processor/src/com/oracle/truffle/dsl/processor/node/NodeParser.java
> 
> Changeset: a0309f88306c
> Author:    Christian Humer <christian.humer at gmail.com>
> Date:      2013-07-10 09:42 +0200
> URL:       http://hg.openjdk.java.net/graal/graal/rev/a0309f88306c
> 
> Added truffle option to enable detailed rewrite messages. Disabled by default.
> 
> ! graal/com.oracle.truffle.api/src/com/oracle/truffle/api/TruffleOptions.java
> ! graal/com.oracle.truffle.dsl.processor/src/com/oracle/truffle/dsl/processor/TruffleTypes.java
> ! graal/com.oracle.truffle.dsl.processor/src/com/oracle/truffle/dsl/processor/node/NodeCodeGenerator.java
> 
> Changeset: 77b83e903703
> Author:    Doug Simon <doug.simon at oracle.com>
> Date:      2013-07-10 17:44 +0200
> URL:       http://hg.openjdk.java.net/graal/graal/rev/77b83e903703
> 
> make use of guardingNonNull node intrinsic
> 
> ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/ArrayCopySnippets.java
> 
> Changeset: bebc9672f45e
> Author:    Doug Simon <doug.simon at oracle.com>
> Date:      2013-07-10 17:46 +0200
> URL:       http://hg.openjdk.java.net/graal/graal/rev/bebc9672f45e
> 
> stamp for GuardingPiNode is determined by caller of constructor, not within constructor
> 
> ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/GuardingPiNode.java
> ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/InliningUtil.java
> 
> Changeset: f8adf47cc05e
> Author:    Doug Simon <doug.simon at oracle.com>
> Date:      2013-07-10 17:46 +0200
> URL:       http://hg.openjdk.java.net/graal/graal/rev/f8adf47cc05e
> 
> checkcast is lowered to instanceof (GRAAL-248)
> 
> ! graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/PushNodesThroughPiTest.java
> ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/java/CheckCastNode.java
> ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/java/InstanceOfNode.java
> ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/LoweringPhase.java
> ! graal/com.oracle.graal.replacements/src/com/oracle/graal/replacements/InstanceOfSnippetsTemplates.java
> 
> Changeset: 31266ceb86ef
> Author:    twisti
> Date:      2013-07-10 12:50 -0700
> URL:       http://hg.openjdk.java.net/graal/graal/rev/31266ceb86ef
> 
> SPARC: Can compile and run two or three methods of a bootstrap.
> 
> ! 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.asm.sparc/src/com/oracle/graal/asm/sparc/SPARCMacroAssembler.java
> ! graal/com.oracle.graal.compiler.sparc/src/com/oracle/graal/compiler/sparc/SPARCLIRGenerator.java
> ! graal/com.oracle.graal.hotspot.sparc/src/com/oracle/graal/hotspot/sparc/SPARCHotSpotBackend.java
> ! graal/com.oracle.graal.hotspot.sparc/src/com/oracle/graal/hotspot/sparc/SPARCHotSpotLIRGenerator.java
> ! graal/com.oracle.graal.hotspot.sparc/src/com/oracle/graal/hotspot/sparc/SPARCHotSpotRuntime.java
> + graal/com.oracle.graal.hotspot.sparc/src/com/oracle/graal/hotspot/sparc/SPARCSafepointOp.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
> 
> Changeset: 8c8e47cc101d
> Author:    Christian Humer <christian.humer at gmail.com>
> Date:      2013-07-11 01:55 +0200
> URL:       http://hg.openjdk.java.net/graal/graal/rev/8c8e47cc101d
> 
> Truffle-DSL: fixed a bug in removal of the frame from the generated generic execute method.
> 
> ! graal/com.oracle.truffle.dsl.processor/src/com/oracle/truffle/dsl/processor/node/NodeCodeGenerator.java
> ! graal/com.oracle.truffle.dsl.processor/src/com/oracle/truffle/dsl/processor/node/NodeData.java
> ! graal/com.oracle.truffle.dsl.processor/src/com/oracle/truffle/dsl/processor/node/NodeParser.java
> 
> Changeset: 062304c74353
> Author:    Christian Humer <christian.humer at gmail.com>
> Date:      2013-07-11 01:56 +0200
> URL:       http://hg.openjdk.java.net/graal/graal/rev/062304c74353
> 
> merge.
> 
> 
> Changeset: 5c1afcee72ec
> Author:    Thomas Wuerthinger <thomas.wuerthinger at oracle.com>
> Date:      2013-07-10 19:48 -0700
> URL:       http://hg.openjdk.java.net/graal/graal/rev/5c1afcee72ec
> 
> Relax TruffleCache assertion.
> 
> ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/TruffleCache.java
> 
> Changeset: 4109190a0da5
> Author:    Roland Schatz <roland.schatz at oracle.com>
> Date:      2013-07-11 11:09 +0200
> URL:       http://hg.openjdk.java.net/graal/graal/rev/4109190a0da5
> 
> Move lowering of arraycopy to the correct lowering phase.
> 
> ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/UnsafeArrayCopyNode.java
> 
> Changeset: 58cb83bfd882
> Author:    Christos Kotselidis <christos.kotselidis at oracle.com>
> Date:      2013-07-11 11:55 +0200
> URL:       http://hg.openjdk.java.net/graal/graal/rev/58cb83bfd882
> 
> Simplify code
> 
> ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/NewObjectSnippets.java
> 
> Changeset: 2a87417379ce
> Author:    Christos Kotselidis <christos.kotselidis at oracle.com>
> Date:      2013-07-11 11:56 +0200
> URL:       http://hg.openjdk.java.net/graal/graal/rev/2a87417379ce
> 
> Remove ternary
> 
> ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/ObjectCloneSnippets.java
> 
> Changeset: f1cd428fca9f
> Author:    Christos Kotselidis <christos.kotselidis at oracle.com>
> Date:      2013-07-11 11:58 +0200
> URL:       http://hg.openjdk.java.net/graal/graal/rev/f1cd428fca9f
> 
> Remove caching of gcStartCycles
> 
> ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/WriteBarrierSnippets.java
> 
> Changeset: b95d42fdddca
> Author:    Christos Kotselidis <christos.kotselidis at oracle.com>
> Date:      2013-07-11 12:09 +0200
> URL:       http://hg.openjdk.java.net/graal/graal/rev/b95d42fdddca
> 
> Minor refactoring
> 
> ! src/share/vm/gc_interface/collectedHeap.hpp
> 
> Changeset: 7cdd4708b1aa
> Author:    Christos Kotselidis <christos.kotselidis at oracle.com>
> Date:      2013-07-11 12:10 +0200
> URL:       http://hg.openjdk.java.net/graal/graal/rev/7cdd4708b1aa
> 
> Merge
> 
> 
> Changeset: 84b944726df2
> Author:    Andreas Woess <andreas.woess at jku.at>
> Date:      2013-07-11 12:22 +0200
> URL:       http://hg.openjdk.java.net/graal/graal/rev/84b944726df2
> 
> Truffle: introduce NodeUtil.countNodes
> 
> ! graal/com.oracle.truffle.api/src/com/oracle/truffle/api/nodes/NodeUtil.java
> 
> Changeset: fd53f9f7007b
> Author:    Andreas Woess <andreas.woess at jku.at>
> Date:      2013-07-11 13:09 +0200
> URL:       http://hg.openjdk.java.net/graal/graal/rev/fd53f9f7007b
> 
> Truffle: refactor inlining
> 
> ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/OptimizedCallTarget.java
> ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/TruffleCompilerOptions.java
> 
> Changeset: 8d961f93725c
> Author:    Gilles Duboscq <duboscq at ssw.jku.at>
> Date:      2013-07-09 18:17 +0200
> URL:       http://hg.openjdk.java.net/graal/graal/rev/8d961f93725c
> 
> Use GuardedValueNode in the inlining
> 
> ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/GuardedValueNode.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
> 
> Changeset: a643c88d164f
> Author:    Gilles Duboscq <duboscq at ssw.jku.at>
> Date:      2013-07-11 14:45 +0200
> URL:       http://hg.openjdk.java.net/graal/graal/rev/a643c88d164f
> 
> Add scopes to capture the graphs in ReplacementsImpl
> 
> ! graal/com.oracle.graal.replacements/src/com/oracle/graal/replacements/ReplacementsImpl.java
> 
> Changeset: 41e9c8845826
> Author:    Gilles Duboscq <duboscq at ssw.jku.at>
> Date:      2013-07-11 14:47 +0200
> URL:       http://hg.openjdk.java.net/graal/graal/rev/41e9c8845826
> 
> Improve instanceof canonicalization
> 
> ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/java/InstanceOfNode.java
> 
> Changeset: 5888e1772ba1
> Author:    Roland Schatz <roland.schatz at oracle.com>
> Date:      2013-07-11 16:21 +0200
> URL:       http://hg.openjdk.java.net/graal/graal/rev/5888e1772ba1
> 
> Check that guards are only created in BEFORE_GUARDS lowering.
> 
> ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/LoweringPhase.java
> 
> Changeset: cd28ead65a53
> Author:    Roland Schatz <roland.schatz at oracle.com>
> Date:      2013-07-11 16:21 +0200
> URL:       http://hg.openjdk.java.net/graal/graal/rev/cd28ead65a53
> 
> Output lowering type in graph dumps.
> 
> ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/LoweringPhase.java
> 
> Changeset: 68d4d5457546
> Author:    Doug Simon <doug.simon at oracle.com>
> Date:      2013-07-11 20:56 +0200
> URL:       http://hg.openjdk.java.net/graal/graal/rev/68d4d5457546
> 
> add sequential id prefixes to IGV graphs
> 
> ! graal/com.oracle.graal.printer/src/com/oracle/graal/printer/GraphPrinterDumpHandler.java
> 
> Changeset: 7f50d79c46f2
> Author:    Doug Simon <doug.simon at oracle.com>
> Date:      2013-07-11 20:57 +0200
> URL:       http://hg.openjdk.java.net/graal/graal/rev/7f50d79c46f2
> 
> fixed a stamp join to be done the "right" way (stamp joining is not currently commutative)
> 
> ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/java/CheckCastNode.java
> 
> Changeset: 057154505878
> Author:    Doug Simon <doug.simon at oracle.com>
> Date:      2013-07-11 20:58 +0200
> URL:       http://hg.openjdk.java.net/graal/graal/rev/057154505878
> 
> fixed canonicalization bug (detected by Gilles) in binary logic nodes
> 
> ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/LogicConjunctionNode.java
> ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/LogicConstantNode.java
> ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/LogicDisjunctionNode.java
> 
> Changeset: 28dc33dc4565
> Author:    Christos Kotselidis <christos.kotselidis at oracle.com>
> Date:      2013-07-12 12:24 +0200
> URL:       http://hg.openjdk.java.net/graal/graal/rev/28dc33dc4565
> 
> Delegate compressed klass pointers info from HotSpot to Graal
> 
> ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/HotSpotVMConfig.java
> ! src/share/vm/graal/graalCompilerToVM.cpp
> 
> Changeset: c3760150dc29
> Author:    Christos Kotselidis <christos.kotselidis at oracle.com>
> Date:      2013-07-12 12:40 +0200
> URL:       http://hg.openjdk.java.net/graal/graal/rev/c3760150dc29
> 
> Add function to read compressed klass pointers of constant objects natively
> 
> ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/HotSpotGraalRuntime.java
> ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/bridge/CompilerToVM.java
> ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/bridge/CompilerToVMImpl.java
> ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotRuntime.java
> ! src/share/vm/graal/graalCompilerToVM.cpp
> 
> Changeset: b975cad32411
> Author:    Christos Kotselidis <christos.kotselidis at oracle.com>
> Date:      2013-07-12 12:42 +0200
> URL:       http://hg.openjdk.java.net/graal/graal/rev/b975cad32411
> 
> Add StoreHubNode
> 
> + graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/extended/StoreHubNode.java
> 
> Changeset: 0517026315a0
> Author:    Christos Kotselidis <christos.kotselidis at oracle.com>
> Date:      2013-07-12 12:46 +0200
> URL:       http://hg.openjdk.java.net/graal/graal/rev/0517026315a0
> 
> Adjust header size to compressed klass pointers
> 
> ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/HotSpotReplacementsUtil.java
> ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/NewObjectSnippets.java
> ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/ObjectCloneSnippets.java
> ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/stubs/NewInstanceStub.java
> 
> Changeset: 0d3d300064a8
> Author:    Christos Kotselidis <christos.kotselidis at oracle.com>
> Date:      2013-07-12 12:47 +0200
> URL:       http://hg.openjdk.java.net/graal/graal/rev/0d3d300064a8
> 
> Remove scratch register from compressed load LIR instruction (used only for testing)
> 
> ! 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: 867588b3ecb4
> Author:    Christos Kotselidis <christos.kotselidis at oracle.com>
> Date:      2013-07-12 12:48 +0200
> URL:       http://hg.openjdk.java.net/graal/graal/rev/867588b3ecb4
> 
> Variables' renaming
> 
> ! graal/com.oracle.graal.lir.amd64/src/com/oracle/graal/lir/amd64/AMD64Move.java
> 
> Changeset: 7cc08d83111d
> Author:    Lukas Stadler <lukas.stadler at jku.at>
> Date:      2013-07-12 15:29 +0200
> URL:       http://hg.openjdk.java.net/graal/graal/rev/7cc08d83111d
> 
> correctly anchor eliminated guards during ConditionalElimination
> 
> ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/ConditionalEliminationPhase.java
> 
> Changeset: 5fc4aedf7910
> Author:    Lukas Stadler <lukas.stadler at jku.at>
> Date:      2013-07-12 15:30 +0200
> URL:       http://hg.openjdk.java.net/graal/graal/rev/5fc4aedf7910
> 
> add relative pc to uncommon trap event entry (helps debugging SEGFAULTs in copmiled code)
> 
> ! src/share/vm/runtime/deoptimization.cpp
> 
> Changeset: c84048228b4a
> Author:    Lukas Stadler <lukas.stadler at jku.at>
> Date:      2013-07-12 17:01 +0200
> URL:       http://hg.openjdk.java.net/graal/graal/rev/c84048228b4a
> 
> prevent repeated simplification of FixedGuardNode
> 
> ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/FixedGuardNode.java
> 
> Changeset: 097a634b57b1
> Author:    Lukas Stadler <lukas.stadler at jku.at>
> Date:      2013-07-12 11:19 +0200
> URL:       http://hg.openjdk.java.net/graal/graal/rev/097a634b57b1
> 
> fix stamps for constants of boolean, byte, char and short type, add tests
> 
> + graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/IntegerStampTest.java
> ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/type/StampFactory.java
> 
> Changeset: 0e671d5268d1
> Author:    Lukas Stadler <lukas.stadler at jku.at>
> Date:      2013-07-11 14:57 +0200
> URL:       http://hg.openjdk.java.net/graal/graal/rev/0e671d5268d1
> 
> re-introduce early read elimination as part of escape analysis
> 
> ! 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/PartialEscapePhase.java
> + graal/com.oracle.graal.virtual/src/com/oracle/graal/virtual/phases/ea/ReadEliminationPEBlockState.java
> + graal/com.oracle.graal.virtual/src/com/oracle/graal/virtual/phases/ea/ReadEliminationPEClosure.java
> 
> Changeset: e35a72e32aae
> Author:    Lukas Stadler <lukas.stadler at jku.at>
> Date:      2013-07-11 15:13 +0200
> URL:       http://hg.openjdk.java.net/graal/graal/rev/e35a72e32aae
> 
> add test for early read elimination
> 
> + graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/ea/PEAReadEliminationTest.java
> 
> Changeset: c78097171701
> Author:    Doug Simon <doug.simon at oracle.com>
> Date:      2013-07-12 14:48 +0200
> URL:       http://hg.openjdk.java.net/graal/graal/rev/c78097171701
> 
> made the "Remove selected graphs and groups" action work in IGV for binary graphs
> 
> ! src/share/tools/IdealGraphVisualizer/Coordinator/src/com/sun/hotspot/igv/coordinator/OutlineTopComponent.java
> ! src/share/tools/IdealGraphVisualizer/Coordinator/src/com/sun/hotspot/igv/coordinator/actions/ImportAction.java
> ! src/share/tools/IdealGraphVisualizer/Data/src/com/sun/hotspot/igv/data/serialization/BinaryParser.java
> ! src/share/tools/IdealGraphVisualizer/NetworkConnection/src/com/sun/hotspot/igv/connection/Client.java
> ! src/share/tools/IdealGraphVisualizer/NetworkConnection/src/com/sun/hotspot/igv/connection/Server.java
> 
> Changeset: 9d079661cbcd
> Author:    Doug Simon <doug.simon at oracle.com>
> Date:      2013-07-12 18:08 +0200
> URL:       http://hg.openjdk.java.net/graal/graal/rev/9d079661cbcd
> 
> fixed generation of sequential id prefixes for IGV graphs
> 
> ! graal/com.oracle.graal.printer/src/com/oracle/graal/printer/GraphPrinterDumpHandler.java
> 
> Changeset: 70cb17338a70
> Author:    Doug Simon <doug.simon at oracle.com>
> Date:      2013-07-12 18:09 +0200
> URL:       http://hg.openjdk.java.net/graal/graal/rev/70cb17338a70
> 
> Merge.
> 
> 
> Changeset: 2a4ad6ab345e
> Author:    Doug Simon <doug.simon at oracle.com>
> Date:      2013-07-12 19:09 +0200
> URL:       http://hg.openjdk.java.net/graal/graal/rev/2a4ad6ab345e
> 
> disabled new lowering of checkcast until performance regression is fixed
> 
> ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/java/CheckCastNode.java
> 
> Changeset: f1904749e4fe
> Author:    Doug Simon <doug.simon at oracle.com>
> Date:      2013-07-12 22:52 +0200
> URL:       http://hg.openjdk.java.net/graal/graal/rev/f1904749e4fe
> 
> re-enabled new lowering of checkcast with addition of a null-check guard where the profile has nullSeen=FALSE
> 
> ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/java/CheckCastNode.java
> 
> Changeset: 40f6bda3f91d
> Author:    Christos Kotselidis <christos.kotselidis at oracle.com>
> Date:      2013-07-12 14:16 +0200
> URL:       http://hg.openjdk.java.net/graal/graal/rev/40f6bda3f91d
> 
> Add compressed klass pointers support in LIR
> 
> ! 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: 0bd794eb8222
> Author:    Christos Kotselidis <christos.kotselidis at oracle.com>
> Date:      2013-07-12 14:17 +0200
> URL:       http://hg.openjdk.java.net/graal/graal/rev/0bd794eb8222
> 
> Add compressed oop support in HotSpot Backend
> 
> ! graal/com.oracle.graal.hotspot.amd64/src/com/oracle/graal/hotspot/amd64/AMD64HotSpotBackend.java
> 
> Changeset: 6621bc66bfa4
> Author:    Christos Kotselidis <christos.kotselidis at oracle.com>
> Date:      2013-07-12 14:20 +0200
> URL:       http://hg.openjdk.java.net/graal/graal/rev/6621bc66bfa4
> 
> Add WriteHubNode lowering
> 
> ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotRuntime.java
> 
> Changeset: 8b8587c32812
> Author:    Christos Kotselidis <christos.kotselidis at oracle.com>
> Date:      2013-07-12 14:38 +0200
> URL:       http://hg.openjdk.java.net/graal/graal/rev/8b8587c32812
> 
> Adjust load/store hub intrinsics to account for Compressed Klass pointers
> 
> ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/HotSpotReplacementsUtil.java
> 
> Changeset: 49a0bd6b0605
> Author:    Christos Kotselidis <christos.kotselidis at oracle.com>
> Date:      2013-07-12 14:40 +0200
> URL:       http://hg.openjdk.java.net/graal/graal/rev/49a0bd6b0605
> 
> Delegate compressed klass pointers info to ReadNode of LoadHubNode
> 
> ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotRuntime.java
> 
> Changeset: 90b3cf36dc17
> Author:    Christos Kotselidis <christos.kotselidis at oracle.com>
> Date:      2013-07-12 14:43 +0200
> URL:       http://hg.openjdk.java.net/graal/graal/rev/90b3cf36dc17
> 
> Replace direct read word with loadHub intrinsic in VerifyOop stub
> 
> ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/stubs/StubUtil.java
> 
> Changeset: 060f9ed42e2f
> Author:    Christos Kotselidis <christos.kotselidis at oracle.com>
> Date:      2013-07-12 14:58 +0200
> URL:       http://hg.openjdk.java.net/graal/graal/rev/060f9ed42e2f
> 
> Augment compressed oop tests
> 
> ! graal/com.oracle.graal.hotspot.test/src/com/oracle/graal/hotspot/test/CompressedOopTest.java
> 
> Changeset: 88992c295d47
> Author:    Christos Kotselidis <christos.kotselidis at oracle.com>
> Date:      2013-07-12 20:19 +0200
> URL:       http://hg.openjdk.java.net/graal/graal/rev/88992c295d47
> 
> Merge
> 
> 
> Changeset: cdbfff4547be
> Author:    Christos Kotselidis <christos.kotselidis at oracle.com>
> Date:      2013-07-12 21:48 +0200
> URL:       http://hg.openjdk.java.net/graal/graal/rev/cdbfff4547be
> 
> Allow compressed klass pointers
> 
> ! src/share/vm/runtime/arguments.cpp
> 
> Changeset: bdd7c8e2293e
> Author:    Christos Kotselidis <christos.kotselidis at oracle.com>
> Date:      2013-07-12 23:26 +0200
> URL:       http://hg.openjdk.java.net/graal/graal/rev/bdd7c8e2293e
> 
> Merge
> 
> 
> Changeset: 00a9dbcbe431
> Author:    Christian Humer <christian.humer at gmail.com>
> Date:      2013-07-13 17:13 +0200
> URL:       http://hg.openjdk.java.net/graal/graal/rev/00a9dbcbe431
> 
> Truffle-DSL: Fixed a bug in polymorphic code generation.
> 
> ! graal/com.oracle.truffle.dsl.processor/src/com/oracle/truffle/dsl/processor/node/NodeCodeGenerator.java
> 
> Changeset: 99789440ce28
> Author:    Christian Humer <christian.humer at gmail.com>
> Date:      2013-07-13 17:14 +0200
> URL:       http://hg.openjdk.java.net/graal/graal/rev/99789440ce28
> 
> Truffle: Added assertions to replaceChild.
> 
> ! graal/com.oracle.truffle.api/src/com/oracle/truffle/api/nodes/NodeUtil.java
> 
> Changeset: ff6eb563a2e2
> Author:    Christian Humer <christian.humer at gmail.com>
> Date:      2013-07-13 17:21 +0200
> URL:       http://hg.openjdk.java.net/graal/graal/rev/ff6eb563a2e2
> 
> Truffle-DSL: Added additional test case for polymporphic generation.
> 
> + graal/com.oracle.truffle.api.dsl.test/src/com/oracle/truffle/api/dsl/test/PolymorphicTest2.java
> 
> Changeset: 45dc193567c2
> Author:    Christos Kotselidis <christos.kotselidis at oracle.com>
> Date:      2013-07-15 10:48 +0200
> URL:       http://hg.openjdk.java.net/graal/graal/rev/45dc193567c2
> 
> Add assertions
> 
> ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotRuntime.java
> 
> Changeset: cbaf26740df8
> Author:    Christos Kotselidis <christos.kotselidis at oracle.com>
> Date:      2013-07-15 10:50 +0200
> URL:       http://hg.openjdk.java.net/graal/graal/rev/cbaf26740df8
> 
> 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/NewObjectSnippets.java
> ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/ObjectCloneSnippets.java
> ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/stubs/NewInstanceStub.java
> 
> Changeset: 257e2455270e
> Author:    Christos Kotselidis <christos.kotselidis at oracle.com>
> Date:      2013-07-15 10:59 +0200
> URL:       http://hg.openjdk.java.net/graal/graal/rev/257e2455270e
> 
> Merge
> 
> 
> Changeset: 3811d04d933e
> Author:    Roland Schatz <roland.schatz at oracle.com>
> Date:      2013-07-15 12:02 +0200
> URL:       http://hg.openjdk.java.net/graal/graal/rev/3811d04d933e
> 
> Do not re-compress oops that are already compressed.
> 
> ! graal/com.oracle.graal.hotspot.amd64/src/com/oracle/graal/hotspot/amd64/AMD64HotSpotLIRGenerator.java
> 
> Changeset: a5c9bc1f28fb
> Author:    Lukas Stadler <lukas.stadler at jku.at>
> Date:      2013-07-15 13:11 +0200
> URL:       http://hg.openjdk.java.net/graal/graal/rev/a5c9bc1f28fb
> 
> fix nullness for not-equals in ConditionalEliminationPhase
> bug reported by Miguel Garcia <miguelalfredo.garcia at epfl.ch>
> 
> ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/ConditionalEliminationPhase.java
> 
> Changeset: e7c0658c2f25
> Author:    Lukas Stadler <lukas.stadler at jku.at>
> Date:      2013-07-15 13:36 +0200
> URL:       http://hg.openjdk.java.net/graal/graal/rev/e7c0658c2f25
> 
> record disjunctive conditions in ConditionalEliminationPhase
> change suggested by Miguel Garcia <miguelalfredo.garcia at epfl.ch>
> 
> ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/ConditionalEliminationPhase.java
> 
> Changeset: 9f5a4074e36b
> Author:    Lukas Stadler <lukas.stadler at jku.at>
> Date:      2013-07-15 13:36 +0200
> URL:       http://hg.openjdk.java.net/graal/graal/rev/9f5a4074e36b
> 
> test for nullness and disjunctive conditions in ConditionalEliminationPhase
> 
> ! graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/ConditionalEliminationTest.java
> 
> Changeset: 7b5d7c42598b
> Author:    Andreas Woess <andreas.woess at jku.at>
> Date:      2013-07-11 19:34 +0200
> URL:       http://hg.openjdk.java.net/graal/graal/rev/7b5d7c42598b
> 
> Truffle: change sorting of inlinable call sites
> 
> ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/OptimizedCallTarget.java
> 
> Changeset: e2f5ae9afdc5
> Author:    Andreas Woess <andreas.woess at jku.at>
> Date:      2013-07-11 22:14 +0200
> URL:       http://hg.openjdk.java.net/graal/graal/rev/e2f5ae9afdc5
> 
> Truffle: introduce profiling option
> 
> ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/GraalTruffleRuntime.java
> ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/OptimizedCallTarget.java
> ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/TruffleCompilerOptions.java
> 
> Changeset: 64740220db85
> Author:    Andreas Woess <andreas.woess at jku.at>
> Date:      2013-07-15 14:09 +0200
> URL:       http://hg.openjdk.java.net/graal/graal/rev/64740220db85
> 
> Merge
> 
> 
> Changeset: 4c12d3756015
> Author:    Andreas Woess <andreas.woess at jku.at>
> Date:      2013-07-15 14:12 +0200
> URL:       http://hg.openjdk.java.net/graal/graal/rev/4c12d3756015
> 
> Truffle: Never compile InvalidInstalledCodeException catch handler.
> 
> ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/TruffleCompilerImpl.java
> 
> Changeset: b221e31d7b0b
> Author:    Andreas Woess <andreas.woess at jku.at>
> Date:      2013-07-15 15:26 +0200
> URL:       http://hg.openjdk.java.net/graal/graal/rev/b221e31d7b0b
> 
> Truffle: revise NodeUtil.replaceChild assertion
> 
> ! graal/com.oracle.truffle.api/src/com/oracle/truffle/api/nodes/NodeUtil.java
> 
> Changeset: 7f6580db1e88
> Author:    Andreas Woess <andreas.woess at jku.at>
> Date:      2013-07-15 14:49 +0200
> URL:       http://hg.openjdk.java.net/graal/graal/rev/7f6580db1e88
> 
> Truffle: add assertions to verify the finalness of child fields.
> 
> ! graal/com.oracle.truffle.api.test/src/com/oracle/truffle/api/test/ReplaceTest.java
> ! graal/com.oracle.truffle.api/src/com/oracle/truffle/api/nodes/NodeUtil.java
> 
> Changeset: f4f46b734a4c
> Author:    Andreas Woess <andreas.woess at jku.at>
> Date:      2013-07-15 15:29 +0200
> URL:       http://hg.openjdk.java.net/graal/graal/rev/f4f46b734a4c
> 
> Merge
> 
> 
> Changeset: e82c28e94f08
> Author:    Roland Schatz <roland.schatz at oracle.com>
> Date:      2013-07-15 16:24 +0200
> URL:       http://hg.openjdk.java.net/graal/graal/rev/e82c28e94f08
> 
> Don't add G1 prebarrier if the written location is uninitialized.
> 
> ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/phases/WriteBarrierAdditionPhase.java
> ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/UnsafeArrayCopyNode.java
> ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/extended/ArrayRangeWriteNode.java
> ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/extended/WriteNode.java
> 
> Changeset: 7f186f1486f7
> Author:    Roland Schatz <roland.schatz at oracle.com>
> Date:      2013-07-15 16:24 +0200
> URL:       http://hg.openjdk.java.net/graal/graal/rev/7f186f1486f7
> 
> Use initializing write node in object clone snippets.
> 
> ! 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: 59d2d6a30d29
> Author:    Roland Schatz <roland.schatz at oracle.com>
> Date:      2013-07-15 16:24 +0200
> URL:       http://hg.openjdk.java.net/graal/graal/rev/59d2d6a30d29
> 
> Re-enable omission of array initialization for G1.
> 
> ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/NewObjectSnippets.java
> ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/ObjectCloneSnippets.java
> 
> Changeset: dd7a8807378b
> Author:    Doug Simon <doug.simon at oracle.com>
> Date:      2013-07-15 16:53 +0200
> URL:       http://hg.openjdk.java.net/graal/graal/rev/dd7a8807378b
> 
> cannot omit frame for compiled methods that make a foreign call (GRAAL-362)
> 
> ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/gen/LIRGenerator.java
> ! graal/com.oracle.graal.hotspot.amd64/src/com/oracle/graal/hotspot/amd64/AMD64HotSpotBackend.java
> 
> Changeset: c483912aaf70
> Author:    Lukas Stadler <lukas.stadler at jku.at>
> Date:      2013-07-15 16:39 +0200
> URL:       http://hg.openjdk.java.net/graal/graal/rev/c483912aaf70
> 
> add ValueProxy interface and infrastructure
> 
> ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/GuardedValueNode.java
> ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/GuardingPiNode.java
> ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/PiNode.java
> ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/ProxyNode.java
> ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/TypeProfileProxyNode.java
> ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/java/CheckCastNode.java
> + graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/spi/ValueProxy.java
> ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/util/GraphUtil.java
> 
> Changeset: 5e338844c64c
> Author:    Lukas Stadler <lukas.stadler at jku.at>
> Date:      2013-07-15 15:58 +0200
> URL:       http://hg.openjdk.java.net/graal/graal/rev/5e338844c64c
> 
> make early read elimination see through ValueProxies
> 
> ! graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/ea/PEAReadEliminationTest.java
> ! graal/com.oracle.graal.virtual/src/com/oracle/graal/virtual/phases/ea/ReadEliminationPEClosure.java
> 
> Changeset: d2f8addaf504
> Author:    Lukas Stadler <lukas.stadler at jku.at>
> Date:      2013-07-15 15:58 +0200
> URL:       http://hg.openjdk.java.net/graal/graal/rev/d2f8addaf504
> 
> assertion in GraalCompiler (don't parse @Test methods)
> 
> ! graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/GraalCompilerTest.java
> 
> Changeset: ae3d070ab223
> Author:    Lukas Stadler <lukas.stadler at jku.at>
> Date:      2013-07-15 16:36 +0200
> URL:       http://hg.openjdk.java.net/graal/graal/rev/ae3d070ab223
> 
> make ValueNode.stamp() final, fix WordTypeRewriterPhase
> 
> ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/ProxyNode.java
> ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/TypeProfileProxyNode.java
> ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/ValueNode.java
> ! graal/com.oracle.graal.word/src/com/oracle/graal/word/phases/WordTypeRewriterPhase.java
> 
> Changeset: 3a044e575466
> Author:    Lukas Stadler <lukas.stadler at jku.at>
> Date:      2013-07-15 17:32 +0200
> URL:       http://hg.openjdk.java.net/graal/graal/rev/3a044e575466
> 
> add ValueProxy interface to FixedValueAnchorNode
> 
> ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/nodes/FixedValueAnchorNode.java
> 
> Changeset: 88d0dc388450
> Author:    Lukas Stadler <lukas.stadler at jku.at>
> Date:      2013-07-15 17:52 +0200
> URL:       http://hg.openjdk.java.net/graal/graal/rev/88d0dc388450
> 
> let ConditionalEliminationPhase change invokes to InvokeKind.Special based on type information
> 
> ! 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: 058abc2b59a5
> Author:    Lukas Stadler <lukas.stadler at jku.at>
> Date:      2013-07-15 17:54 +0200
> URL:       http://hg.openjdk.java.net/graal/graal/rev/058abc2b59a5
> 
> Merge
> 
> ! graal/com.oracle.graal.word/src/com/oracle/graal/word/phases/WordTypeRewriterPhase.java
> 
> Changeset: 395d34c10e26
> Author:    Doug Simon <doug.simon at oracle.com>
> Date:      2013-07-15 18:22 +0200
> URL:       http://hg.openjdk.java.net/graal/graal/rev/395d34c10e26
> 
> HSAIL backend changes
> Contributed-by: Tom Deneau <tom.deneau at amd.com>
> 
> * stackslot mapping was incorrect when combinations of 32-bit and
> 64-bit stores were generated.  StackSlot alignment in
> HSAILTargetDescription set to 8.
> 
> * compressedOops support in various heap size configurations (with or
> without either of shift or heap base).  So we don't need
> XX:-UseCompressedOops anymore.
> 
> * some support for unsigned shifts, long shifts, logical ops for long
> datatype.
> 
> * a new GraalOption, InlineEverything.  Some HSAIL targets are not
> able to handle HSAIL function calls yet, plus we are still working
> on emitting HSAIL function calls in the compiler.
> 
> * hack for emitForeignCall special cases of createOutOfBoundsException
> or createNullPointerException.  (We just emit a comment.  Real
> exception handling still pending).  These nodes came about when we
> more aggressively inlined, although this has not been explained yet.
> 
> * support HSAILAddressValues as operands for arithmetic ops.  Use
> HSAIL lda instruction to get address into a register.  Used in
> particular for USHR for card-marking.
> 
> * Added some new junit tests. (some ported from their lambda versions)
> 
>  * StaticNBodyCallTest which would fail with default inlining (since
>    we don't yet generate HSAIL calls).  It uses junit.assumeTrue and
>    tests whether InlineEverything is set.  It (and also some
>    lambda-based junit tests not part of this webrev) do pass nicely
>    when InlineEverything is set true.
> 
>  * tests for storing an object, which test being able to handle the
>    card-marking logic, as well as the encoding and decoding of a
>    compressed oop.
> 
>  * some 2D matrix tests that showed a problem before the stackslot
>    change above.  (have a mixture of 32-bit and 64-bit stackslot
>    spills)
> 
> ! graal/com.oracle.graal.asm.hsail/src/com/oracle/graal/asm/hsail/HSAILAssembler.java
> ! graal/com.oracle.graal.compiler.hsail.test.infra/src/com/oracle/graal/compiler/hsail/test/infra/GraalKernelTester.java
> ! graal/com.oracle.graal.compiler.hsail.test.infra/src/com/oracle/graal/compiler/hsail/test/infra/KernelTester.java
> + graal/com.oracle.graal.compiler.hsail.test/src/com/oracle/graal/compiler/hsail/test/Float2DMatrixBase.java
> + graal/com.oracle.graal.compiler.hsail.test/src/com/oracle/graal/compiler/hsail/test/Float2DMatrixMultiplyRangeFinalTest.java
> + graal/com.oracle.graal.compiler.hsail.test/src/com/oracle/graal/compiler/hsail/test/Float2DMatrixMultiplyTest.java
> + graal/com.oracle.graal.compiler.hsail.test/src/com/oracle/graal/compiler/hsail/test/ObjectStoreNullTest.java
> + graal/com.oracle.graal.compiler.hsail.test/src/com/oracle/graal/compiler/hsail/test/ObjectStoreTest.java
> ! graal/com.oracle.graal.compiler.hsail.test/src/com/oracle/graal/compiler/hsail/test/StaticMandelTest.java
> + graal/com.oracle.graal.compiler.hsail.test/src/com/oracle/graal/compiler/hsail/test/StaticNBodyCallTest.java
> ! graal/com.oracle.graal.compiler.hsail/src/com/oracle/graal/compiler/hsail/HSAILCompilationResult.java
> ! graal/com.oracle.graal.compiler.hsail/src/com/oracle/graal/compiler/hsail/HSAILLIRGenerator.java
> ! graal/com.oracle.graal.lir.hsail/src/com/oracle/graal/lir/hsail/HSAILArithmetic.java
> ! graal/com.oracle.graal.lir.hsail/src/com/oracle/graal/lir/hsail/HSAILControlFlow.java
> ! graal/com.oracle.graal.lir.hsail/src/com/oracle/graal/lir/hsail/HSAILMove.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
> 
> 
> 




From doug.simon at oracle.com  Tue Jul 16 10:12:10 2013
From: doug.simon at oracle.com (Doug Simon)
Date: Tue, 16 Jul 2013 19:12:10 +0200
Subject: graal/graal: 107 new changesets
In-Reply-To: <BC97738F8E7C8742BABED7F06FB9DF91450459B9@sausexdag01.amd.com>
References: <20130715170157.A77A4480BF@hg.openjdk.java.net>
	<BC97738F8E7C8742BABED7F06FB9DF91450454E9@sausexdag01.amd.com>
	<A6D3A38A-FD4A-4179-AF70-B5A4E766677A@oracle.com>
	<BC97738F8E7C8742BABED7F06FB9DF91450459B9@sausexdag01.amd.com>
Message-ID: <1E0C65D0-C382-4719-9438-8327A2DA9139@oracle.com>

That's what I would do.

On Jul 16, 2013, at 7:10 PM, "Deneau, Tom" <tom.deneau at amd.com> wrote:

> Doug --
> 
> So do you recommend we just consider it fixed until it shows up again?
> (rather than trying to debug the earlier drop of the trunk which showed the problem)
> 
> -- Tom
> 
> -----Original Message-----
> From: Doug Simon [mailto:doug.simon at oracle.com] 
> Sent: Tuesday, July 16, 2013 11:48 AM
> To: Deneau, Tom
> Cc: graal-dev at openjdk.java.net
> Subject: Re: graal/graal: 107 new changesets
> 
> Sorry, I can't think of what the problem is/was.
> 
> On Jul 15, 2013, at 11:05 PM, "Deneau, Tom" <tom.deneau at amd.com> wrote:
> 
>> Doug or others --
>> 
>> I was about to ask for help on a codegen problem we were seeing but after updating to the latest default,
>> I see that it is gone (so I'm assuming it was not in our backend :) ).  Of course it is possible that the bug
>> is just being hidden by some unrelated change.   Anyway, here is a brief description,
>> maybe you can tell which of the many changesets below would have fixed this, if any.
>> 
>> We were using String.contains as our test case, which was being nicely inlined, and we generated the following 
>> HSAIL code which led to the problem
>> 
>> 	ld_global_u16 $s8, [$d3 + 24];         // read a u16 char from the test String
>> 	ld_global_u16 $s9, [$d1 + 24];         // read a u16 char from the pattern  
>> 	st_spill_s32 $s9, [%spillseg][24];     // register spill
>> 	mov_b32 $s8, 0;                        // <<<<--- This code was causing the problem 
>> 	cmp_ne_b1_s32 $c0, $s8, $s9;           // compare the two chars but s8 has been clobbered
>> 
>> 
>> When I did a -G:TraceLIRGeneratorLevel=2, I could see that the problematic instruction
>> "mov_b32 $s8, 0"
>> was generated as part of something called
>>      MOVE TO PHI from 276|EndNode to 277|LoopBegin
>> 
>> as part of PhiResolver.dispose, the part that is commented with
>> // generate move for move from non variable to arbitrary destination
>> 
>> Does the above sound like something that was purposely fixed?
>> 
>> -- 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 at oracle.com
>> Sent: Monday, July 15, 2013 11:56 AM
>> To: graal-dev at openjdk.java.net
>> Subject: hg: graal/graal: 107 new changesets
>> 
>> Changeset: 204d8d4f91a4
>> Author:    Christian Haeubl <haeubl at ssw.jku.at>
>> Date:      2013-07-09 11:18 +0200
>> URL:       http://hg.openjdk.java.net/graal/graal/rev/204d8d4f91a4
>> 
>> Minor Java fix.
>> 
>> ! graal/com.oracle.graal.api.code/src/com/oracle/graal/api/code/Assumptions.java
>> 
>> Changeset: a9b76e1e5ab3
>> Author:    Christian Haeubl <haeubl at ssw.jku.at>
>> Date:      2013-07-09 11:19 +0200
>> URL:       http://hg.openjdk.java.net/graal/graal/rev/a9b76e1e5ab3
>> 
>> Fix for OSR regression introduced with 88672775a26c.
>> 
>> ! src/share/vm/runtime/compilationPolicy.cpp
>> 
>> Changeset: dcee58529a1c
>> Author:    Christian Haeubl <haeubl at ssw.jku.at>
>> Date:      2013-07-09 11:21 +0200
>> URL:       http://hg.openjdk.java.net/graal/graal/rev/dcee58529a1c
>> 
>> Merge.
>> 
>> - graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/nodes/HotSpotNmethodExecuteNode.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/HotSpotNmethodSubstitutions.java
>> 
>> Changeset: 9808158cfeab
>> Author:    Roland Schatz <roland.schatz at oracle.com>
>> Date:      2013-07-09 11:14 +0200
>> URL:       http://hg.openjdk.java.net/graal/graal/rev/9808158cfeab
>> 
>> Allow foreign call stubs to be declared as leaf methods.
>> 
>> ! graal/com.oracle.graal.hotspot.amd64/src/com/oracle/graal/hotspot/amd64/AMD64HotSpotBackend.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/ForeignCallStub.java
>> ! graal/com.oracle.graal.lir.amd64/src/com/oracle/graal/lir/amd64/AMD64SaveRegistersOp.java
>> 
>> Changeset: 5348b49b2a76
>> Author:    Roland Schatz <roland.schatz at oracle.com>
>> Date:      2013-07-09 11:57 +0200
>> URL:       http://hg.openjdk.java.net/graal/graal/rev/5348b49b2a76
>> 
>> Assign framestates in snippet lowering after framestate assignment.
>> 
>> ! graal/com.oracle.graal.replacements/src/com/oracle/graal/replacements/SnippetTemplate.java
>> 
>> Changeset: 110444cbf1eb
>> Author:    Roland Schatz <roland.schatz at oracle.com>
>> Date:      2013-07-09 11:58 +0200
>> URL:       http://hg.openjdk.java.net/graal/graal/rev/110444cbf1eb
>> 
>> Make FixedGuardNode a DeoptimizingNode.
>> 
>> ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/FixedGuardNode.java
>> 
>> Changeset: f11cd00d4115
>> Author:    Roland Schatz <roland.schatz at oracle.com>
>> Date:      2013-07-09 11:58 +0200
>> URL:       http://hg.openjdk.java.net/graal/graal/rev/f11cd00d4115
>> 
>> Make G1PreWriteBarrier a DeoptimizingNode.
>> 
>> ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/phases/WriteBarrierAdditionPhase.java
>> ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/WriteBarrierSnippets.java
>> ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/G1PreWriteBarrier.java
>> 
>> Changeset: 5bab3272bb82
>> Author:    Roland Schatz <roland.schatz at oracle.com>
>> Date:      2013-07-09 11:58 +0200
>> URL:       http://hg.openjdk.java.net/graal/graal/rev/5bab3272bb82
>> 
>> Make array allocations deoptimizing nodes.
>> 
>> ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/java/AbstractNewArrayNode.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
>> 
>> Changeset: 69089865435a
>> Author:    Roland Schatz <roland.schatz at oracle.com>
>> Date:      2013-07-09 11:58 +0200
>> URL:       http://hg.openjdk.java.net/graal/graal/rev/69089865435a
>> 
>> New lowering phase after framestate assignment.
>> 
>> ! 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.nodes/src/com/oracle/graal/nodes/WriteBarrier.java
>> ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/spi/Lowerable.java
>> 
>> Changeset: e7d07c9bb779
>> Author:    Christian Haeubl <haeubl at ssw.jku.at>
>> Date:      2013-07-09 17:53 +0200
>> URL:       http://hg.openjdk.java.net/graal/graal/rev/e7d07c9bb779
>> 
>> Removed priority compilation queue.
>> Fixed another race condition in the compilation queue.
>> Removed Graal-specific compilation policy.
>> 
>> ! 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/CompilerThread.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.phases/src/com/oracle/graal/phases/GraalOptions.java
>> ! src/cpu/x86/vm/templateInterpreter_x86_64.cpp
>> ! src/share/vm/classfile/vmSymbols.hpp
>> ! src/share/vm/graal/graalCompiler.cpp
>> ! src/share/vm/graal/graalVMToCompiler.cpp
>> ! src/share/vm/graal/graalVMToCompiler.hpp
>> ! src/share/vm/oops/methodCounters.cpp
>> ! src/share/vm/oops/methodCounters.hpp
>> ! src/share/vm/runtime/compilationPolicy.cpp
>> 
>> Changeset: d59e7f94f28d
>> Author:    Christian Haeubl <haeubl at ssw.jku.at>
>> Date:      2013-07-09 17:54 +0200
>> URL:       http://hg.openjdk.java.net/graal/graal/rev/d59e7f94f28d
>> 
>> Increased priority for compiler threads.
>> 
>> ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/CompilerThread.java
>> 
>> Changeset: 853a894e0d97
>> Author:    Christian Haeubl <haeubl at ssw.jku.at>
>> Date:      2013-07-09 17:55 +0200
>> URL:       http://hg.openjdk.java.net/graal/graal/rev/853a894e0d97
>> 
>> Merge.
>> 
>> 
>> Changeset: 41362ec88331
>> Author:    Thomas Wuerthinger <thomas.wuerthinger at oracle.com>
>> Date:      2013-07-09 14:33 +0200
>> URL:       http://hg.openjdk.java.net/graal/graal/rev/41362ec88331
>> 
>> Improve Truffle graph cache.
>> 
>> ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/PartialEvaluator.java
>> ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/TruffleCache.java
>> 
>> Changeset: 9db1377b0580
>> Author:    Thomas Wuerthinger <thomas.wuerthinger at oracle.com>
>> Date:      2013-07-09 17:38 +0200
>> URL:       http://hg.openjdk.java.net/graal/graal/rev/9db1377b0580
>> 
>> Fix for TruffleCache.
>> 
>> ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/PartialEvaluator.java
>> ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/TruffleCache.java
>> ! graal/com.oracle.truffle.api/src/com/oracle/truffle/api/TruffleOptions.java
>> ! graal/com.oracle.truffle.api/src/com/oracle/truffle/api/nodes/SlowPathException.java
>> 
>> Changeset: 3bbe14e492fb
>> Author:    Thomas Wuerthinger <thomas.wuerthinger at oracle.com>
>> Date:      2013-07-09 20:06 +0200
>> URL:       http://hg.openjdk.java.net/graal/graal/rev/3bbe14e492fb
>> 
>> Introduce TruffleGraphMaxNodes option with default value 10000.
>> 
>> ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/PartialEvaluator.java
>> ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/TruffleCompilerOptions.java
>> 
>> Changeset: 759415ed915a
>> Author:    Thomas Wuerthinger <thomas.wuerthinger at oracle.com>
>> Date:      2013-07-09 20:09 +0200
>> URL:       http://hg.openjdk.java.net/graal/graal/rev/759415ed915a
>> 
>> Merge.
>> 
>> 
>> Changeset: fa86a653bc0d
>> Author:    Andreas Woess <andreas.woess at jku.at>
>> Date:      2013-07-09 19:45 +0200
>> URL:       http://hg.openjdk.java.net/graal/graal/rev/fa86a653bc0d
>> 
>> Truffle: ensure frame assumption is recorded for materialized frames
>> 
>> ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/nodes/FrameAccessNode.java
>> 
>> Changeset: 0c570e82cc1d
>> Author:    Andreas Woess <andreas.woess at jku.at>
>> Date:      2013-07-09 21:03 +0200
>> URL:       http://hg.openjdk.java.net/graal/graal/rev/0c570e82cc1d
>> 
>> Truffle: minor cleanup
>> 
>> ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/FrameWithoutBoxing.java
>> ! graal/com.oracle.truffle.api/src/com/oracle/truffle/api/impl/DefaultVirtualFrame.java
>> 
>> Changeset: 311abd52ffeb
>> Author:    Andreas Woess <andreas.woess at jku.at>
>> Date:      2013-07-09 21:20 +0200
>> URL:       http://hg.openjdk.java.net/graal/graal/rev/311abd52ffeb
>> 
>> Merge
>> 
>> 
>> Changeset: 725922588833
>> Author:    Thomas Wuerthinger <thomas.wuerthinger at oracle.com>
>> Date:      2013-07-09 21:53 +0200
>> URL:       http://hg.openjdk.java.net/graal/graal/rev/725922588833
>> 
>> Fix Truffle cache inlining strategy to skip exception edges.
>> 
>> ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/TruffleCache.java
>> ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/TruffleCompilerOptions.java
>> 
>> Changeset: ae4c79ee71d1
>> Author:    Thomas Wuerthinger <thomas.wuerthinger at oracle.com>
>> Date:      2013-07-09 22:05 +0200
>> URL:       http://hg.openjdk.java.net/graal/graal/rev/ae4c79ee71d1
>> 
>> Merge.
>> 
>> 
>> Changeset: 6ff467cdb105
>> Author:    twisti
>> Date:      2013-07-09 14:39 -0700
>> URL:       http://hg.openjdk.java.net/graal/graal/rev/6ff467cdb105
>> 
>> Code installer changes for SPARC.
>> 
>> ! src/cpu/sparc/vm/graalCodeInstaller_sparc.hpp
>> ! src/cpu/sparc/vm/sharedRuntime_sparc.cpp
>> ! src/cpu/x86/vm/graalCodeInstaller_x86.hpp
>> ! src/share/vm/graal/graalCodeInstaller.cpp
>> ! src/share/vm/graal/graalCodeInstaller.hpp
>> ! src/share/vm/prims/methodHandles.cpp
>> 
>> Changeset: 431eca622358
>> Author:    twisti
>> Date:      2013-07-09 15:37 -0700
>> URL:       http://hg.openjdk.java.net/graal/graal/rev/431eca622358
>> 
>> SPARC: Fixed build errors.
>> 
>> ! src/share/vm/graal/graalCompilerToGPU.cpp
>> ! src/share/vm/graal/graalCompilerToVM.hpp
>> 
>> Changeset: 73122b5edf6a
>> Author:    twisti
>> Date:      2013-07-09 15:37 -0700
>> URL:       http://hg.openjdk.java.net/graal/graal/rev/73122b5edf6a
>> 
>> SPARC: Can compile simple methods and do static calls.
>> 
>> ! 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.asm.sparc/src/com/oracle/graal/asm/sparc/SPARCMacroAssembler.java
>> ! graal/com.oracle.graal.compiler.sparc/src/com/oracle/graal/compiler/sparc/SPARCLIRGenerator.java
>> ! graal/com.oracle.graal.hotspot.sparc/src/com/oracle/graal/hotspot/sparc/SPARCHotSpotBackend.java
>> ! graal/com.oracle.graal.hotspot.sparc/src/com/oracle/graal/hotspot/sparc/SPARCHotSpotLIRGenerator.java
>> ! graal/com.oracle.graal.hotspot.sparc/src/com/oracle/graal/hotspot/sparc/SPARCHotSpotRegisterConfig.java
>> + graal/com.oracle.graal.hotspot.sparc/src/com/oracle/graal/hotspot/sparc/SPARCHotspotDirectStaticCallOp.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/SPARCCall.java
>> ! graal/com.oracle.graal.lir.sparc/src/com/oracle/graal/lir/sparc/SPARCCompare.java
>> ! graal/com.oracle.graal.lir.sparc/src/com/oracle/graal/lir/sparc/SPARCControlFlow.java
>> ! graal/com.oracle.graal.lir.sparc/src/com/oracle/graal/lir/sparc/SPARCLIRInstruction.java
>> ! graal/com.oracle.graal.lir.sparc/src/com/oracle/graal/lir/sparc/SPARCMathIntrinsicOp.java
>> ! graal/com.oracle.graal.lir.sparc/src/com/oracle/graal/lir/sparc/SPARCMove.java
>> ! graal/com.oracle.graal.lir.sparc/src/com/oracle/graal/lir/sparc/SPARCTestOp.java
>> ! graal/com.oracle.graal.sparc/src/com/oracle/graal/sparc/SPARC.java
>> 
>> Changeset: d2055a110396
>> Author:    Thomas Wuerthinger <thomas.wuerthinger at oracle.com>
>> Date:      2013-07-10 05:26 +0200
>> URL:       http://hg.openjdk.java.net/graal/graal/rev/d2055a110396
>> 
>> Introduce CompilerDirectives.SlowPath annotation.
>> 
>> ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/TruffleCache.java
>> ! graal/com.oracle.truffle.api/src/com/oracle/truffle/api/CompilerDirectives.java
>> 
>> Changeset: 87d2df0a7624
>> Author:    Thomas Wuerthinger <thomas.wuerthinger at oracle.com>
>> Date:      2013-07-10 05:27 +0200
>> URL:       http://hg.openjdk.java.net/graal/graal/rev/87d2df0a7624
>> 
>> Merge.
>> 
>> 
>> Changeset: 3ae117e62905
>> Author:    Christian Humer <christian.humer at gmail.com>
>> Date:      2013-07-10 09:23 +0200
>> URL:       http://hg.openjdk.java.net/graal/graal/rev/3ae117e62905
>> 
>> Removed frame argument for generic cases if not needed.
>> Added @SlowPath annotation to generated generic cases.
>> 
>> ! graal/com.oracle.truffle.dsl.processor/src/com/oracle/truffle/dsl/processor/TruffleTypes.java
>> ! graal/com.oracle.truffle.dsl.processor/src/com/oracle/truffle/dsl/processor/node/NodeCodeGenerator.java
>> ! graal/com.oracle.truffle.dsl.processor/src/com/oracle/truffle/dsl/processor/node/NodeParser.java
>> 
>> Changeset: a0309f88306c
>> Author:    Christian Humer <christian.humer at gmail.com>
>> Date:      2013-07-10 09:42 +0200
>> URL:       http://hg.openjdk.java.net/graal/graal/rev/a0309f88306c
>> 
>> Added truffle option to enable detailed rewrite messages. Disabled by default.
>> 
>> ! graal/com.oracle.truffle.api/src/com/oracle/truffle/api/TruffleOptions.java
>> ! graal/com.oracle.truffle.dsl.processor/src/com/oracle/truffle/dsl/processor/TruffleTypes.java
>> ! graal/com.oracle.truffle.dsl.processor/src/com/oracle/truffle/dsl/processor/node/NodeCodeGenerator.java
>> 
>> Changeset: 77b83e903703
>> Author:    Doug Simon <doug.simon at oracle.com>
>> Date:      2013-07-10 17:44 +0200
>> URL:       http://hg.openjdk.java.net/graal/graal/rev/77b83e903703
>> 
>> make use of guardingNonNull node intrinsic
>> 
>> ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/ArrayCopySnippets.java
>> 
>> Changeset: bebc9672f45e
>> Author:    Doug Simon <doug.simon at oracle.com>
>> Date:      2013-07-10 17:46 +0200
>> URL:       http://hg.openjdk.java.net/graal/graal/rev/bebc9672f45e
>> 
>> stamp for GuardingPiNode is determined by caller of constructor, not within constructor
>> 
>> ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/GuardingPiNode.java
>> ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/InliningUtil.java
>> 
>> Changeset: f8adf47cc05e
>> Author:    Doug Simon <doug.simon at oracle.com>
>> Date:      2013-07-10 17:46 +0200
>> URL:       http://hg.openjdk.java.net/graal/graal/rev/f8adf47cc05e
>> 
>> checkcast is lowered to instanceof (GRAAL-248)
>> 
>> ! graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/PushNodesThroughPiTest.java
>> ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/java/CheckCastNode.java
>> ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/java/InstanceOfNode.java
>> ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/LoweringPhase.java
>> ! graal/com.oracle.graal.replacements/src/com/oracle/graal/replacements/InstanceOfSnippetsTemplates.java
>> 
>> Changeset: 31266ceb86ef
>> Author:    twisti
>> Date:      2013-07-10 12:50 -0700
>> URL:       http://hg.openjdk.java.net/graal/graal/rev/31266ceb86ef
>> 
>> SPARC: Can compile and run two or three methods of a bootstrap.
>> 
>> ! 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.asm.sparc/src/com/oracle/graal/asm/sparc/SPARCMacroAssembler.java
>> ! graal/com.oracle.graal.compiler.sparc/src/com/oracle/graal/compiler/sparc/SPARCLIRGenerator.java
>> ! graal/com.oracle.graal.hotspot.sparc/src/com/oracle/graal/hotspot/sparc/SPARCHotSpotBackend.java
>> ! graal/com.oracle.graal.hotspot.sparc/src/com/oracle/graal/hotspot/sparc/SPARCHotSpotLIRGenerator.java
>> ! graal/com.oracle.graal.hotspot.sparc/src/com/oracle/graal/hotspot/sparc/SPARCHotSpotRuntime.java
>> + graal/com.oracle.graal.hotspot.sparc/src/com/oracle/graal/hotspot/sparc/SPARCSafepointOp.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
>> 
>> Changeset: 8c8e47cc101d
>> Author:    Christian Humer <christian.humer at gmail.com>
>> Date:      2013-07-11 01:55 +0200
>> URL:       http://hg.openjdk.java.net/graal/graal/rev/8c8e47cc101d
>> 
>> Truffle-DSL: fixed a bug in removal of the frame from the generated generic execute method.
>> 
>> ! graal/com.oracle.truffle.dsl.processor/src/com/oracle/truffle/dsl/processor/node/NodeCodeGenerator.java
>> ! graal/com.oracle.truffle.dsl.processor/src/com/oracle/truffle/dsl/processor/node/NodeData.java
>> ! graal/com.oracle.truffle.dsl.processor/src/com/oracle/truffle/dsl/processor/node/NodeParser.java
>> 
>> Changeset: 062304c74353
>> Author:    Christian Humer <christian.humer at gmail.com>
>> Date:      2013-07-11 01:56 +0200
>> URL:       http://hg.openjdk.java.net/graal/graal/rev/062304c74353
>> 
>> merge.
>> 
>> 
>> Changeset: 5c1afcee72ec
>> Author:    Thomas Wuerthinger <thomas.wuerthinger at oracle.com>
>> Date:      2013-07-10 19:48 -0700
>> URL:       http://hg.openjdk.java.net/graal/graal/rev/5c1afcee72ec
>> 
>> Relax TruffleCache assertion.
>> 
>> ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/TruffleCache.java
>> 
>> Changeset: 4109190a0da5
>> Author:    Roland Schatz <roland.schatz at oracle.com>
>> Date:      2013-07-11 11:09 +0200
>> URL:       http://hg.openjdk.java.net/graal/graal/rev/4109190a0da5
>> 
>> Move lowering of arraycopy to the correct lowering phase.
>> 
>> ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/UnsafeArrayCopyNode.java
>> 
>> Changeset: 58cb83bfd882
>> Author:    Christos Kotselidis <christos.kotselidis at oracle.com>
>> Date:      2013-07-11 11:55 +0200
>> URL:       http://hg.openjdk.java.net/graal/graal/rev/58cb83bfd882
>> 
>> Simplify code
>> 
>> ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/NewObjectSnippets.java
>> 
>> Changeset: 2a87417379ce
>> Author:    Christos Kotselidis <christos.kotselidis at oracle.com>
>> Date:      2013-07-11 11:56 +0200
>> URL:       http://hg.openjdk.java.net/graal/graal/rev/2a87417379ce
>> 
>> Remove ternary
>> 
>> ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/ObjectCloneSnippets.java
>> 
>> Changeset: f1cd428fca9f
>> Author:    Christos Kotselidis <christos.kotselidis at oracle.com>
>> Date:      2013-07-11 11:58 +0200
>> URL:       http://hg.openjdk.java.net/graal/graal/rev/f1cd428fca9f
>> 
>> Remove caching of gcStartCycles
>> 
>> ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/WriteBarrierSnippets.java
>> 
>> Changeset: b95d42fdddca
>> Author:    Christos Kotselidis <christos.kotselidis at oracle.com>
>> Date:      2013-07-11 12:09 +0200
>> URL:       http://hg.openjdk.java.net/graal/graal/rev/b95d42fdddca
>> 
>> Minor refactoring
>> 
>> ! src/share/vm/gc_interface/collectedHeap.hpp
>> 
>> Changeset: 7cdd4708b1aa
>> Author:    Christos Kotselidis <christos.kotselidis at oracle.com>
>> Date:      2013-07-11 12:10 +0200
>> URL:       http://hg.openjdk.java.net/graal/graal/rev/7cdd4708b1aa
>> 
>> Merge
>> 
>> 
>> Changeset: 84b944726df2
>> Author:    Andreas Woess <andreas.woess at jku.at>
>> Date:      2013-07-11 12:22 +0200
>> URL:       http://hg.openjdk.java.net/graal/graal/rev/84b944726df2
>> 
>> Truffle: introduce NodeUtil.countNodes
>> 
>> ! graal/com.oracle.truffle.api/src/com/oracle/truffle/api/nodes/NodeUtil.java
>> 
>> Changeset: fd53f9f7007b
>> Author:    Andreas Woess <andreas.woess at jku.at>
>> Date:      2013-07-11 13:09 +0200
>> URL:       http://hg.openjdk.java.net/graal/graal/rev/fd53f9f7007b
>> 
>> Truffle: refactor inlining
>> 
>> ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/OptimizedCallTarget.java
>> ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/TruffleCompilerOptions.java
>> 
>> Changeset: 8d961f93725c
>> Author:    Gilles Duboscq <duboscq at ssw.jku.at>
>> Date:      2013-07-09 18:17 +0200
>> URL:       http://hg.openjdk.java.net/graal/graal/rev/8d961f93725c
>> 
>> Use GuardedValueNode in the inlining
>> 
>> ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/GuardedValueNode.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
>> 
>> Changeset: a643c88d164f
>> Author:    Gilles Duboscq <duboscq at ssw.jku.at>
>> Date:      2013-07-11 14:45 +0200
>> URL:       http://hg.openjdk.java.net/graal/graal/rev/a643c88d164f
>> 
>> Add scopes to capture the graphs in ReplacementsImpl
>> 
>> ! graal/com.oracle.graal.replacements/src/com/oracle/graal/replacements/ReplacementsImpl.java
>> 
>> Changeset: 41e9c8845826
>> Author:    Gilles Duboscq <duboscq at ssw.jku.at>
>> Date:      2013-07-11 14:47 +0200
>> URL:       http://hg.openjdk.java.net/graal/graal/rev/41e9c8845826
>> 
>> Improve instanceof canonicalization
>> 
>> ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/java/InstanceOfNode.java
>> 
>> Changeset: 5888e1772ba1
>> Author:    Roland Schatz <roland.schatz at oracle.com>
>> Date:      2013-07-11 16:21 +0200
>> URL:       http://hg.openjdk.java.net/graal/graal/rev/5888e1772ba1
>> 
>> Check that guards are only created in BEFORE_GUARDS lowering.
>> 
>> ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/LoweringPhase.java
>> 
>> Changeset: cd28ead65a53
>> Author:    Roland Schatz <roland.schatz at oracle.com>
>> Date:      2013-07-11 16:21 +0200
>> URL:       http://hg.openjdk.java.net/graal/graal/rev/cd28ead65a53
>> 
>> Output lowering type in graph dumps.
>> 
>> ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/LoweringPhase.java
>> 
>> Changeset: 68d4d5457546
>> Author:    Doug Simon <doug.simon at oracle.com>
>> Date:      2013-07-11 20:56 +0200
>> URL:       http://hg.openjdk.java.net/graal/graal/rev/68d4d5457546
>> 
>> add sequential id prefixes to IGV graphs
>> 
>> ! graal/com.oracle.graal.printer/src/com/oracle/graal/printer/GraphPrinterDumpHandler.java
>> 
>> Changeset: 7f50d79c46f2
>> Author:    Doug Simon <doug.simon at oracle.com>
>> Date:      2013-07-11 20:57 +0200
>> URL:       http://hg.openjdk.java.net/graal/graal/rev/7f50d79c46f2
>> 
>> fixed a stamp join to be done the "right" way (stamp joining is not currently commutative)
>> 
>> ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/java/CheckCastNode.java
>> 
>> Changeset: 057154505878
>> Author:    Doug Simon <doug.simon at oracle.com>
>> Date:      2013-07-11 20:58 +0200
>> URL:       http://hg.openjdk.java.net/graal/graal/rev/057154505878
>> 
>> fixed canonicalization bug (detected by Gilles) in binary logic nodes
>> 
>> ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/LogicConjunctionNode.java
>> ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/LogicConstantNode.java
>> ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/LogicDisjunctionNode.java
>> 
>> Changeset: 28dc33dc4565
>> Author:    Christos Kotselidis <christos.kotselidis at oracle.com>
>> Date:      2013-07-12 12:24 +0200
>> URL:       http://hg.openjdk.java.net/graal/graal/rev/28dc33dc4565
>> 
>> Delegate compressed klass pointers info from HotSpot to Graal
>> 
>> ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/HotSpotVMConfig.java
>> ! src/share/vm/graal/graalCompilerToVM.cpp
>> 
>> Changeset: c3760150dc29
>> Author:    Christos Kotselidis <christos.kotselidis at oracle.com>
>> Date:      2013-07-12 12:40 +0200
>> URL:       http://hg.openjdk.java.net/graal/graal/rev/c3760150dc29
>> 
>> Add function to read compressed klass pointers of constant objects natively
>> 
>> ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/HotSpotGraalRuntime.java
>> ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/bridge/CompilerToVM.java
>> ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/bridge/CompilerToVMImpl.java
>> ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotRuntime.java
>> ! src/share/vm/graal/graalCompilerToVM.cpp
>> 
>> Changeset: b975cad32411
>> Author:    Christos Kotselidis <christos.kotselidis at oracle.com>
>> Date:      2013-07-12 12:42 +0200
>> URL:       http://hg.openjdk.java.net/graal/graal/rev/b975cad32411
>> 
>> Add StoreHubNode
>> 
>> + graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/extended/StoreHubNode.java
>> 
>> Changeset: 0517026315a0
>> Author:    Christos Kotselidis <christos.kotselidis at oracle.com>
>> Date:      2013-07-12 12:46 +0200
>> URL:       http://hg.openjdk.java.net/graal/graal/rev/0517026315a0
>> 
>> Adjust header size to compressed klass pointers
>> 
>> ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/HotSpotReplacementsUtil.java
>> ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/NewObjectSnippets.java
>> ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/ObjectCloneSnippets.java
>> ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/stubs/NewInstanceStub.java
>> 
>> Changeset: 0d3d300064a8
>> Author:    Christos Kotselidis <christos.kotselidis at oracle.com>
>> Date:      2013-07-12 12:47 +0200
>> URL:       http://hg.openjdk.java.net/graal/graal/rev/0d3d300064a8
>> 
>> Remove scratch register from compressed load LIR instruction (used only for testing)
>> 
>> ! 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: 867588b3ecb4
>> Author:    Christos Kotselidis <christos.kotselidis at oracle.com>
>> Date:      2013-07-12 12:48 +0200
>> URL:       http://hg.openjdk.java.net/graal/graal/rev/867588b3ecb4
>> 
>> Variables' renaming
>> 
>> ! graal/com.oracle.graal.lir.amd64/src/com/oracle/graal/lir/amd64/AMD64Move.java
>> 
>> Changeset: 7cc08d83111d
>> Author:    Lukas Stadler <lukas.stadler at jku.at>
>> Date:      2013-07-12 15:29 +0200
>> URL:       http://hg.openjdk.java.net/graal/graal/rev/7cc08d83111d
>> 
>> correctly anchor eliminated guards during ConditionalElimination
>> 
>> ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/ConditionalEliminationPhase.java
>> 
>> Changeset: 5fc4aedf7910
>> Author:    Lukas Stadler <lukas.stadler at jku.at>
>> Date:      2013-07-12 15:30 +0200
>> URL:       http://hg.openjdk.java.net/graal/graal/rev/5fc4aedf7910
>> 
>> add relative pc to uncommon trap event entry (helps debugging SEGFAULTs in copmiled code)
>> 
>> ! src/share/vm/runtime/deoptimization.cpp
>> 
>> Changeset: c84048228b4a
>> Author:    Lukas Stadler <lukas.stadler at jku.at>
>> Date:      2013-07-12 17:01 +0200
>> URL:       http://hg.openjdk.java.net/graal/graal/rev/c84048228b4a
>> 
>> prevent repeated simplification of FixedGuardNode
>> 
>> ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/FixedGuardNode.java
>> 
>> Changeset: 097a634b57b1
>> Author:    Lukas Stadler <lukas.stadler at jku.at>
>> Date:      2013-07-12 11:19 +0200
>> URL:       http://hg.openjdk.java.net/graal/graal/rev/097a634b57b1
>> 
>> fix stamps for constants of boolean, byte, char and short type, add tests
>> 
>> + graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/IntegerStampTest.java
>> ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/type/StampFactory.java
>> 
>> Changeset: 0e671d5268d1
>> Author:    Lukas Stadler <lukas.stadler at jku.at>
>> Date:      2013-07-11 14:57 +0200
>> URL:       http://hg.openjdk.java.net/graal/graal/rev/0e671d5268d1
>> 
>> re-introduce early read elimination as part of escape analysis
>> 
>> ! 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/PartialEscapePhase.java
>> + graal/com.oracle.graal.virtual/src/com/oracle/graal/virtual/phases/ea/ReadEliminationPEBlockState.java
>> + graal/com.oracle.graal.virtual/src/com/oracle/graal/virtual/phases/ea/ReadEliminationPEClosure.java
>> 
>> Changeset: e35a72e32aae
>> Author:    Lukas Stadler <lukas.stadler at jku.at>
>> Date:      2013-07-11 15:13 +0200
>> URL:       http://hg.openjdk.java.net/graal/graal/rev/e35a72e32aae
>> 
>> add test for early read elimination
>> 
>> + graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/ea/PEAReadEliminationTest.java
>> 
>> Changeset: c78097171701
>> Author:    Doug Simon <doug.simon at oracle.com>
>> Date:      2013-07-12 14:48 +0200
>> URL:       http://hg.openjdk.java.net/graal/graal/rev/c78097171701
>> 
>> made the "Remove selected graphs and groups" action work in IGV for binary graphs
>> 
>> ! src/share/tools/IdealGraphVisualizer/Coordinator/src/com/sun/hotspot/igv/coordinator/OutlineTopComponent.java
>> ! src/share/tools/IdealGraphVisualizer/Coordinator/src/com/sun/hotspot/igv/coordinator/actions/ImportAction.java
>> ! src/share/tools/IdealGraphVisualizer/Data/src/com/sun/hotspot/igv/data/serialization/BinaryParser.java
>> ! src/share/tools/IdealGraphVisualizer/NetworkConnection/src/com/sun/hotspot/igv/connection/Client.java
>> ! src/share/tools/IdealGraphVisualizer/NetworkConnection/src/com/sun/hotspot/igv/connection/Server.java
>> 
>> Changeset: 9d079661cbcd
>> Author:    Doug Simon <doug.simon at oracle.com>
>> Date:      2013-07-12 18:08 +0200
>> URL:       http://hg.openjdk.java.net/graal/graal/rev/9d079661cbcd
>> 
>> fixed generation of sequential id prefixes for IGV graphs
>> 
>> ! graal/com.oracle.graal.printer/src/com/oracle/graal/printer/GraphPrinterDumpHandler.java
>> 
>> Changeset: 70cb17338a70
>> Author:    Doug Simon <doug.simon at oracle.com>
>> Date:      2013-07-12 18:09 +0200
>> URL:       http://hg.openjdk.java.net/graal/graal/rev/70cb17338a70
>> 
>> Merge.
>> 
>> 
>> Changeset: 2a4ad6ab345e
>> Author:    Doug Simon <doug.simon at oracle.com>
>> Date:      2013-07-12 19:09 +0200
>> URL:       http://hg.openjdk.java.net/graal/graal/rev/2a4ad6ab345e
>> 
>> disabled new lowering of checkcast until performance regression is fixed
>> 
>> ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/java/CheckCastNode.java
>> 
>> Changeset: f1904749e4fe
>> Author:    Doug Simon <doug.simon at oracle.com>
>> Date:      2013-07-12 22:52 +0200
>> URL:       http://hg.openjdk.java.net/graal/graal/rev/f1904749e4fe
>> 
>> re-enabled new lowering of checkcast with addition of a null-check guard where the profile has nullSeen=FALSE
>> 
>> ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/java/CheckCastNode.java
>> 
>> Changeset: 40f6bda3f91d
>> Author:    Christos Kotselidis <christos.kotselidis at oracle.com>
>> Date:      2013-07-12 14:16 +0200
>> URL:       http://hg.openjdk.java.net/graal/graal/rev/40f6bda3f91d
>> 
>> Add compressed klass pointers support in LIR
>> 
>> ! 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: 0bd794eb8222
>> Author:    Christos Kotselidis <christos.kotselidis at oracle.com>
>> Date:      2013-07-12 14:17 +0200
>> URL:       http://hg.openjdk.java.net/graal/graal/rev/0bd794eb8222
>> 
>> Add compressed oop support in HotSpot Backend
>> 
>> ! graal/com.oracle.graal.hotspot.amd64/src/com/oracle/graal/hotspot/amd64/AMD64HotSpotBackend.java
>> 
>> Changeset: 6621bc66bfa4
>> Author:    Christos Kotselidis <christos.kotselidis at oracle.com>
>> Date:      2013-07-12 14:20 +0200
>> URL:       http://hg.openjdk.java.net/graal/graal/rev/6621bc66bfa4
>> 
>> Add WriteHubNode lowering
>> 
>> ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotRuntime.java
>> 
>> Changeset: 8b8587c32812
>> Author:    Christos Kotselidis <christos.kotselidis at oracle.com>
>> Date:      2013-07-12 14:38 +0200
>> URL:       http://hg.openjdk.java.net/graal/graal/rev/8b8587c32812
>> 
>> Adjust load/store hub intrinsics to account for Compressed Klass pointers
>> 
>> ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/HotSpotReplacementsUtil.java
>> 
>> Changeset: 49a0bd6b0605
>> Author:    Christos Kotselidis <christos.kotselidis at oracle.com>
>> Date:      2013-07-12 14:40 +0200
>> URL:       http://hg.openjdk.java.net/graal/graal/rev/49a0bd6b0605
>> 
>> Delegate compressed klass pointers info to ReadNode of LoadHubNode
>> 
>> ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotRuntime.java
>> 
>> Changeset: 90b3cf36dc17
>> Author:    Christos Kotselidis <christos.kotselidis at oracle.com>
>> Date:      2013-07-12 14:43 +0200
>> URL:       http://hg.openjdk.java.net/graal/graal/rev/90b3cf36dc17
>> 
>> Replace direct read word with loadHub intrinsic in VerifyOop stub
>> 
>> ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/stubs/StubUtil.java
>> 
>> Changeset: 060f9ed42e2f
>> Author:    Christos Kotselidis <christos.kotselidis at oracle.com>
>> Date:      2013-07-12 14:58 +0200
>> URL:       http://hg.openjdk.java.net/graal/graal/rev/060f9ed42e2f
>> 
>> Augment compressed oop tests
>> 
>> ! graal/com.oracle.graal.hotspot.test/src/com/oracle/graal/hotspot/test/CompressedOopTest.java
>> 
>> Changeset: 88992c295d47
>> Author:    Christos Kotselidis <christos.kotselidis at oracle.com>
>> Date:      2013-07-12 20:19 +0200
>> URL:       http://hg.openjdk.java.net/graal/graal/rev/88992c295d47
>> 
>> Merge
>> 
>> 
>> Changeset: cdbfff4547be
>> Author:    Christos Kotselidis <christos.kotselidis at oracle.com>
>> Date:      2013-07-12 21:48 +0200
>> URL:       http://hg.openjdk.java.net/graal/graal/rev/cdbfff4547be
>> 
>> Allow compressed klass pointers
>> 
>> ! src/share/vm/runtime/arguments.cpp
>> 
>> Changeset: bdd7c8e2293e
>> Author:    Christos Kotselidis <christos.kotselidis at oracle.com>
>> Date:      2013-07-12 23:26 +0200
>> URL:       http://hg.openjdk.java.net/graal/graal/rev/bdd7c8e2293e
>> 
>> Merge
>> 
>> 
>> Changeset: 00a9dbcbe431
>> Author:    Christian Humer <christian.humer at gmail.com>
>> Date:      2013-07-13 17:13 +0200
>> URL:       http://hg.openjdk.java.net/graal/graal/rev/00a9dbcbe431
>> 
>> Truffle-DSL: Fixed a bug in polymorphic code generation.
>> 
>> ! graal/com.oracle.truffle.dsl.processor/src/com/oracle/truffle/dsl/processor/node/NodeCodeGenerator.java
>> 
>> Changeset: 99789440ce28
>> Author:    Christian Humer <christian.humer at gmail.com>
>> Date:      2013-07-13 17:14 +0200
>> URL:       http://hg.openjdk.java.net/graal/graal/rev/99789440ce28
>> 
>> Truffle: Added assertions to replaceChild.
>> 
>> ! graal/com.oracle.truffle.api/src/com/oracle/truffle/api/nodes/NodeUtil.java
>> 
>> Changeset: ff6eb563a2e2
>> Author:    Christian Humer <christian.humer at gmail.com>
>> Date:      2013-07-13 17:21 +0200
>> URL:       http://hg.openjdk.java.net/graal/graal/rev/ff6eb563a2e2
>> 
>> Truffle-DSL: Added additional test case for polymporphic generation.
>> 
>> + graal/com.oracle.truffle.api.dsl.test/src/com/oracle/truffle/api/dsl/test/PolymorphicTest2.java
>> 
>> Changeset: 45dc193567c2
>> Author:    Christos Kotselidis <christos.kotselidis at oracle.com>
>> Date:      2013-07-15 10:48 +0200
>> URL:       http://hg.openjdk.java.net/graal/graal/rev/45dc193567c2
>> 
>> Add assertions
>> 
>> ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotRuntime.java
>> 
>> Changeset: cbaf26740df8
>> Author:    Christos Kotselidis <christos.kotselidis at oracle.com>
>> Date:      2013-07-15 10:50 +0200
>> URL:       http://hg.openjdk.java.net/graal/graal/rev/cbaf26740df8
>> 
>> 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/NewObjectSnippets.java
>> ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/ObjectCloneSnippets.java
>> ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/stubs/NewInstanceStub.java
>> 
>> Changeset: 257e2455270e
>> Author:    Christos Kotselidis <christos.kotselidis at oracle.com>
>> Date:      2013-07-15 10:59 +0200
>> URL:       http://hg.openjdk.java.net/graal/graal/rev/257e2455270e
>> 
>> Merge
>> 
>> 
>> Changeset: 3811d04d933e
>> Author:    Roland Schatz <roland.schatz at oracle.com>
>> Date:      2013-07-15 12:02 +0200
>> URL:       http://hg.openjdk.java.net/graal/graal/rev/3811d04d933e
>> 
>> Do not re-compress oops that are already compressed.
>> 
>> ! graal/com.oracle.graal.hotspot.amd64/src/com/oracle/graal/hotspot/amd64/AMD64HotSpotLIRGenerator.java
>> 
>> Changeset: a5c9bc1f28fb
>> Author:    Lukas Stadler <lukas.stadler at jku.at>
>> Date:      2013-07-15 13:11 +0200
>> URL:       http://hg.openjdk.java.net/graal/graal/rev/a5c9bc1f28fb
>> 
>> fix nullness for not-equals in ConditionalEliminationPhase
>> bug reported by Miguel Garcia <miguelalfredo.garcia at epfl.ch>
>> 
>> ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/ConditionalEliminationPhase.java
>> 
>> Changeset: e7c0658c2f25
>> Author:    Lukas Stadler <lukas.stadler at jku.at>
>> Date:      2013-07-15 13:36 +0200
>> URL:       http://hg.openjdk.java.net/graal/graal/rev/e7c0658c2f25
>> 
>> record disjunctive conditions in ConditionalEliminationPhase
>> change suggested by Miguel Garcia <miguelalfredo.garcia at epfl.ch>
>> 
>> ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/ConditionalEliminationPhase.java
>> 
>> Changeset: 9f5a4074e36b
>> Author:    Lukas Stadler <lukas.stadler at jku.at>
>> Date:      2013-07-15 13:36 +0200
>> URL:       http://hg.openjdk.java.net/graal/graal/rev/9f5a4074e36b
>> 
>> test for nullness and disjunctive conditions in ConditionalEliminationPhase
>> 
>> ! graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/ConditionalEliminationTest.java
>> 
>> Changeset: 7b5d7c42598b
>> Author:    Andreas Woess <andreas.woess at jku.at>
>> Date:      2013-07-11 19:34 +0200
>> URL:       http://hg.openjdk.java.net/graal/graal/rev/7b5d7c42598b
>> 
>> Truffle: change sorting of inlinable call sites
>> 
>> ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/OptimizedCallTarget.java
>> 
>> Changeset: e2f5ae9afdc5
>> Author:    Andreas Woess <andreas.woess at jku.at>
>> Date:      2013-07-11 22:14 +0200
>> URL:       http://hg.openjdk.java.net/graal/graal/rev/e2f5ae9afdc5
>> 
>> Truffle: introduce profiling option
>> 
>> ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/GraalTruffleRuntime.java
>> ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/OptimizedCallTarget.java
>> ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/TruffleCompilerOptions.java
>> 
>> Changeset: 64740220db85
>> Author:    Andreas Woess <andreas.woess at jku.at>
>> Date:      2013-07-15 14:09 +0200
>> URL:       http://hg.openjdk.java.net/graal/graal/rev/64740220db85
>> 
>> Merge
>> 
>> 
>> Changeset: 4c12d3756015
>> Author:    Andreas Woess <andreas.woess at jku.at>
>> Date:      2013-07-15 14:12 +0200
>> URL:       http://hg.openjdk.java.net/graal/graal/rev/4c12d3756015
>> 
>> Truffle: Never compile InvalidInstalledCodeException catch handler.
>> 
>> ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/TruffleCompilerImpl.java
>> 
>> Changeset: b221e31d7b0b
>> Author:    Andreas Woess <andreas.woess at jku.at>
>> Date:      2013-07-15 15:26 +0200
>> URL:       http://hg.openjdk.java.net/graal/graal/rev/b221e31d7b0b
>> 
>> Truffle: revise NodeUtil.replaceChild assertion
>> 
>> ! graal/com.oracle.truffle.api/src/com/oracle/truffle/api/nodes/NodeUtil.java
>> 
>> Changeset: 7f6580db1e88
>> Author:    Andreas Woess <andreas.woess at jku.at>
>> Date:      2013-07-15 14:49 +0200
>> URL:       http://hg.openjdk.java.net/graal/graal/rev/7f6580db1e88
>> 
>> Truffle: add assertions to verify the finalness of child fields.
>> 
>> ! graal/com.oracle.truffle.api.test/src/com/oracle/truffle/api/test/ReplaceTest.java
>> ! graal/com.oracle.truffle.api/src/com/oracle/truffle/api/nodes/NodeUtil.java
>> 
>> Changeset: f4f46b734a4c
>> Author:    Andreas Woess <andreas.woess at jku.at>
>> Date:      2013-07-15 15:29 +0200
>> URL:       http://hg.openjdk.java.net/graal/graal/rev/f4f46b734a4c
>> 
>> Merge
>> 
>> 
>> Changeset: e82c28e94f08
>> Author:    Roland Schatz <roland.schatz at oracle.com>
>> Date:      2013-07-15 16:24 +0200
>> URL:       http://hg.openjdk.java.net/graal/graal/rev/e82c28e94f08
>> 
>> Don't add G1 prebarrier if the written location is uninitialized.
>> 
>> ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/phases/WriteBarrierAdditionPhase.java
>> ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/UnsafeArrayCopyNode.java
>> ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/extended/ArrayRangeWriteNode.java
>> ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/extended/WriteNode.java
>> 
>> Changeset: 7f186f1486f7
>> Author:    Roland Schatz <roland.schatz at oracle.com>
>> Date:      2013-07-15 16:24 +0200
>> URL:       http://hg.openjdk.java.net/graal/graal/rev/7f186f1486f7
>> 
>> Use initializing write node in object clone snippets.
>> 
>> ! 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: 59d2d6a30d29
>> Author:    Roland Schatz <roland.schatz at oracle.com>
>> Date:      2013-07-15 16:24 +0200
>> URL:       http://hg.openjdk.java.net/graal/graal/rev/59d2d6a30d29
>> 
>> Re-enable omission of array initialization for G1.
>> 
>> ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/NewObjectSnippets.java
>> ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/ObjectCloneSnippets.java
>> 
>> Changeset: dd7a8807378b
>> Author:    Doug Simon <doug.simon at oracle.com>
>> Date:      2013-07-15 16:53 +0200
>> URL:       http://hg.openjdk.java.net/graal/graal/rev/dd7a8807378b
>> 
>> cannot omit frame for compiled methods that make a foreign call (GRAAL-362)
>> 
>> ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/gen/LIRGenerator.java
>> ! graal/com.oracle.graal.hotspot.amd64/src/com/oracle/graal/hotspot/amd64/AMD64HotSpotBackend.java
>> 
>> Changeset: c483912aaf70
>> Author:    Lukas Stadler <lukas.stadler at jku.at>
>> Date:      2013-07-15 16:39 +0200
>> URL:       http://hg.openjdk.java.net/graal/graal/rev/c483912aaf70
>> 
>> add ValueProxy interface and infrastructure
>> 
>> ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/GuardedValueNode.java
>> ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/GuardingPiNode.java
>> ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/PiNode.java
>> ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/ProxyNode.java
>> ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/TypeProfileProxyNode.java
>> ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/java/CheckCastNode.java
>> + graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/spi/ValueProxy.java
>> ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/util/GraphUtil.java
>> 
>> Changeset: 5e338844c64c
>> Author:    Lukas Stadler <lukas.stadler at jku.at>
>> Date:      2013-07-15 15:58 +0200
>> URL:       http://hg.openjdk.java.net/graal/graal/rev/5e338844c64c
>> 
>> make early read elimination see through ValueProxies
>> 
>> ! graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/ea/PEAReadEliminationTest.java
>> ! graal/com.oracle.graal.virtual/src/com/oracle/graal/virtual/phases/ea/ReadEliminationPEClosure.java
>> 
>> Changeset: d2f8addaf504
>> Author:    Lukas Stadler <lukas.stadler at jku.at>
>> Date:      2013-07-15 15:58 +0200
>> URL:       http://hg.openjdk.java.net/graal/graal/rev/d2f8addaf504
>> 
>> assertion in GraalCompiler (don't parse @Test methods)
>> 
>> ! graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/GraalCompilerTest.java
>> 
>> Changeset: ae3d070ab223
>> Author:    Lukas Stadler <lukas.stadler at jku.at>
>> Date:      2013-07-15 16:36 +0200
>> URL:       http://hg.openjdk.java.net/graal/graal/rev/ae3d070ab223
>> 
>> make ValueNode.stamp() final, fix WordTypeRewriterPhase
>> 
>> ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/ProxyNode.java
>> ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/TypeProfileProxyNode.java
>> ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/ValueNode.java
>> ! graal/com.oracle.graal.word/src/com/oracle/graal/word/phases/WordTypeRewriterPhase.java
>> 
>> Changeset: 3a044e575466
>> Author:    Lukas Stadler <lukas.stadler at jku.at>
>> Date:      2013-07-15 17:32 +0200
>> URL:       http://hg.openjdk.java.net/graal/graal/rev/3a044e575466
>> 
>> add ValueProxy interface to FixedValueAnchorNode
>> 
>> ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/nodes/FixedValueAnchorNode.java
>> 
>> Changeset: 88d0dc388450
>> Author:    Lukas Stadler <lukas.stadler at jku.at>
>> Date:      2013-07-15 17:52 +0200
>> URL:       http://hg.openjdk.java.net/graal/graal/rev/88d0dc388450
>> 
>> let ConditionalEliminationPhase change invokes to InvokeKind.Special based on type information
>> 
>> ! 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: 058abc2b59a5
>> Author:    Lukas Stadler <lukas.stadler at jku.at>
>> Date:      2013-07-15 17:54 +0200
>> URL:       http://hg.openjdk.java.net/graal/graal/rev/058abc2b59a5
>> 
>> Merge
>> 
>> ! graal/com.oracle.graal.word/src/com/oracle/graal/word/phases/WordTypeRewriterPhase.java
>> 
>> Changeset: 395d34c10e26
>> Author:    Doug Simon <doug.simon at oracle.com>
>> Date:      2013-07-15 18:22 +0200
>> URL:       http://hg.openjdk.java.net/graal/graal/rev/395d34c10e26
>> 
>> HSAIL backend changes
>> Contributed-by: Tom Deneau <tom.deneau at amd.com>
>> 
>> * stackslot mapping was incorrect when combinations of 32-bit and
>> 64-bit stores were generated.  StackSlot alignment in
>> HSAILTargetDescription set to 8.
>> 
>> * compressedOops support in various heap size configurations (with or
>> without either of shift or heap base).  So we don't need
>> XX:-UseCompressedOops anymore.
>> 
>> * some support for unsigned shifts, long shifts, logical ops for long
>> datatype.
>> 
>> * a new GraalOption, InlineEverything.  Some HSAIL targets are not
>> able to handle HSAIL function calls yet, plus we are still working
>> on emitting HSAIL function calls in the compiler.
>> 
>> * hack for emitForeignCall special cases of createOutOfBoundsException
>> or createNullPointerException.  (We just emit a comment.  Real
>> exception handling still pending).  These nodes came about when we
>> more aggressively inlined, although this has not been explained yet.
>> 
>> * support HSAILAddressValues as operands for arithmetic ops.  Use
>> HSAIL lda instruction to get address into a register.  Used in
>> particular for USHR for card-marking.
>> 
>> * Added some new junit tests. (some ported from their lambda versions)
>> 
>> * StaticNBodyCallTest which would fail with default inlining (since
>>   we don't yet generate HSAIL calls).  It uses junit.assumeTrue and
>>   tests whether InlineEverything is set.  It (and also some
>>   lambda-based junit tests not part of this webrev) do pass nicely
>>   when InlineEverything is set true.
>> 
>> * tests for storing an object, which test being able to handle the
>>   card-marking logic, as well as the encoding and decoding of a
>>   compressed oop.
>> 
>> * some 2D matrix tests that showed a problem before the stackslot
>>   change above.  (have a mixture of 32-bit and 64-bit stackslot
>>   spills)
>> 
>> ! graal/com.oracle.graal.asm.hsail/src/com/oracle/graal/asm/hsail/HSAILAssembler.java
>> ! graal/com.oracle.graal.compiler.hsail.test.infra/src/com/oracle/graal/compiler/hsail/test/infra/GraalKernelTester.java
>> ! graal/com.oracle.graal.compiler.hsail.test.infra/src/com/oracle/graal/compiler/hsail/test/infra/KernelTester.java
>> + graal/com.oracle.graal.compiler.hsail.test/src/com/oracle/graal/compiler/hsail/test/Float2DMatrixBase.java
>> + graal/com.oracle.graal.compiler.hsail.test/src/com/oracle/graal/compiler/hsail/test/Float2DMatrixMultiplyRangeFinalTest.java
>> + graal/com.oracle.graal.compiler.hsail.test/src/com/oracle/graal/compiler/hsail/test/Float2DMatrixMultiplyTest.java
>> + graal/com.oracle.graal.compiler.hsail.test/src/com/oracle/graal/compiler/hsail/test/ObjectStoreNullTest.java
>> + graal/com.oracle.graal.compiler.hsail.test/src/com/oracle/graal/compiler/hsail/test/ObjectStoreTest.java
>> ! graal/com.oracle.graal.compiler.hsail.test/src/com/oracle/graal/compiler/hsail/test/StaticMandelTest.java
>> + graal/com.oracle.graal.compiler.hsail.test/src/com/oracle/graal/compiler/hsail/test/StaticNBodyCallTest.java
>> ! graal/com.oracle.graal.compiler.hsail/src/com/oracle/graal/compiler/hsail/HSAILCompilationResult.java
>> ! graal/com.oracle.graal.compiler.hsail/src/com/oracle/graal/compiler/hsail/HSAILLIRGenerator.java
>> ! graal/com.oracle.graal.lir.hsail/src/com/oracle/graal/lir/hsail/HSAILArithmetic.java
>> ! graal/com.oracle.graal.lir.hsail/src/com/oracle/graal/lir/hsail/HSAILControlFlow.java
>> ! graal/com.oracle.graal.lir.hsail/src/com/oracle/graal/lir/hsail/HSAILMove.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
>> 
>> 
>> 
> 
> 
> 


From forax at univ-mlv.fr  Tue Jul 16 10:19:31 2013
From: forax at univ-mlv.fr (Remi Forax)
Date: Tue, 16 Jul 2013 19:19:31 +0200
Subject: Modifying graph to include InvokeNode
In-Reply-To: <680474C2-27D9-4FD8-9AF9-E3690F29A923@oracle.com>
References: <917C3B2B-52B0-4B9F-A3A4-FAB598A2EA29@sms.ed.ac.uk>
	<920EF6F2-121B-4723-A760-9CA7FACC33D0@oracle.com>
	<C0E75C84-C04F-42CB-892E-C66E8D649EE8@sms.ed.ac.uk>
	<E2C4ACBD-0501-4E9A-A919-888C6BC04BE6@sms.ed.ac.uk>
	<50EF85C2-FF3F-4341-9169-46BAB0BC94A3@oracle.com>
	<51E55B90.3060205@ed.ac.uk>
	<DF5F8528-72B4-4F59-8042-F06232539537@oracle.com>
	<51E567C1.50302@univ-mlv.fr>
	<680474C2-27D9-4FD8-9AF9-E3690F29A923@oracle.com>
Message-ID: <51E580A3.2040704@univ-mlv.fr>

On 07/16/2013 06:03 PM, Doug Simon wrote:
> On Jul 16, 2013, at 5:33 PM, Remi Forax <forax at univ-mlv.fr> wrote:
>
>> On 07/16/2013 05:27 PM, Doug Simon wrote:
>>> On Jul 16, 2013, at 4:41 PM, Christophe Dubach <christophe.dubach at ed.ac.uk> wrote:
>>>
>>>> Dear Doug,
>>>>
>>>> I'm currently supervising Chris with his work and have been following the discussion.
>>>>
>>>> I am quite surprised that it is not possible to add an InvokeNode in a the graph of a method at runtime. When you say "We can only add static calls that are guaranteed to never be deoptimized" do you mean the callee or the caller? I am probably ignorant but I don't see what would be the difference between inserting an invokeNode to static method (not created dynamically) and an IntergerAdd node in the graph at runtime.
>>> An invoke node (that doesn't get inlined) in method A that calls method B will result in a call in the generated code. During execution of B, something may happen to invalidate an assumption made when compiling A (e.g., class loading invalidating a class hierarchy speculation). This means A is now invalid and needs to be deoptimized upon return from B. In the current system, we rely on HotSpot's deoptimization infrastructure to continue execution at the return site of A in the interpreter. HotSpot only (currently) supports deoptimize-on-return for call sites that have the BCI of an invoke bytecode.
>>>
>>> One could modify HotSpot to have more general deoptimization support or we could modify Graal to handle invokes inserted for instrumentation. However, both of these tasks are non-trivial. Since our current focus is not on making Graal an all purpose instrumentation framework, we probably won't invest much effort in them in the near future.
>>>
>>>> Anyway, thanks for the suggestion of doing bytecode instrumentation. Is it possible to do this directly with Graal or where you talking about patching the method at class load time?
>>> The latter. Although you could use Graal in conjunction with a bytecode instrumentation library such as ASM for building a graph from the bytecode and finding the loops.
>>>
>>>> In our scenario, we want to limit our instrumentation to hot methods in order to further optimise them, therefore, we were aiming to do all this in the jit compiler.
>>> What you really want is a Java interpreter based on Truffle[1][2]. We have gone someway down this path ourselves but don't yet have anything publicly available.
>> The other solution is to use invokedynamic, if Graal support it ?
> It supports it but does not (yet) optimize it.
>
> -Doug

So I suppose that instrumentation is the best answer for now.

cheers,
R?mi

>
>>>> Thanks,
>>>> Christophe.
>>>>
>>>>
>>>> On 16/07/13 14:43, Doug Simon wrote:
>>>>> On Jul 16, 2013, at 3:27 PM, ATKIN-GRANVILLE Chris <s1255753 at sms.ed.ac.uk> wrote:
>>>>>
>>>>>> Oh, that may have been a silly thing to say, I know you can't "get" the BCI of a method call that doesn't exist in the bytecode. Even still, it seems like quite a large omission from graal to not be able to add static method calls into a graph?
>>>>> We can only add static calls that are guaranteed to never be deoptimized since there is no valid interpreter state to continue in for such invocations. I doubt that any bytecode compiler that relies on deoptimization could do any different?
>>>>>
>>>>> For your use case, bytecode instrumentation is what you want. Especially since you (seem to) need complete dynamic coverage of the code patterns you are interested in instrumenting.
>>>>>
>>>>> -Doug
>>>>>
>>>>>> On 16 Jul 2013, at 14:19, ATKIN-GRANVILLE Chris <s1255753 at sms.ed.ac.uk>
>>>>>> wrote:
>>>>>>
>>>>>>> Is it not possible to somehow "get" that BCI? It doesn't seem like adding static method calls should be impossible when graph transformations are possible...
>>>>>>>
>>>>>>> On 16 Jul 2013, at 14:14, Doug Simon <doug.simon at oracle.com>
>>>>>>> wrote:
>>>>>>>
>>>>>>>> This is almost certainly due to the fact that an invoke node must be associated with the BCI of a real invoke bytecode instruction. Otherwise, where would the interpreter resume if there is a deoptimization  during the invocation?
>>>>>>>>
>>>>>>>> On Jul 16, 2013, at 2:22 PM, ATKIN-GRANVILLE Chris <s1255753 at sms.ed.ac.uk> wrote:
>>>>>>>>
>>>>>>>>> Hi there,
>>>>>>>>>
>>>>>>>>> I'm trying to modify the graph to include an invoke node to a static function after certain node types. I'm modifying the graph at a high level before LoweringPhase.class (not a requirement, can change if required). However, I'm running into issues with JVM fatal errors. The code I have at the moment looks like this:
>>>>>>>>>
>>>>>>>>> public class MyPhase extends Phase {
>>>>>>>>> 	public void run(StructuredGraph graph) {
>>>>>>>>> 		for (Node node: graph.getNode()) {
>>>>>>>>>
>>>>>>>>> 			if ( node instanceof RandomFixedNode) {
>>>>>>>>> 				RandomFixedNode rfm = (RandomFixedNode) node;
>>>>>>>>> 				
>>>>>>>>> 				try {
>>>>>>>>> 					ResolvedJavaMethod method = getMethod(?);
>>>>>>>>> 					MethodCallTargetMode callTarget = graph.add(new MethodCallTargetNode(MethodCallTargetNode.InvokeKind.Static,
>>>>>>>>> 						method, new ValueNode[] {}, new HotSpotResolvedPrimitiveType(Kind.Void)));
>>>>>>>>>
>>>>>>>>> 					InvokeNode invoke = graph.add(new InvokeNode(callTarget, FrameState.UNKNOWN_BCI));
>>>>>>>>> 					invoke.setStateAfter(graph.add(new FrameState(FrameState.UNKNOWN_BCI)));
>>>>>>>>> 					graph.addAfterFixed(rfm, invoke);
>>>>>>>>> 				
>>>>>>>>> 				} catch (Exception e) {
>>>>>>>>> 					e.printStackTrace();
>>>>>>>>> 				}
>>>>>>>>> 			}
>>>>>>>>>
>>>>>>>>> 		}
>>>>>>>>> 	}
>>>>>>>>> }
>>>>>>>>>
>>>>>>>>> I'm pretty sure the problem is do with the BCIs and/or the FrameStates, but I don't know how to fix it. The error that I get is:
>>>>>>>>>
>>>>>>>>> Internal Error (/Volumes/Acme/Development/graal/src/share/vm/graal/graalCompilerToVM.cpp:44), pid=8466, tid=5379
>>>>>>>>> assert(hotspot_method != NULL && hotspot_method->is_a(HotSpotResolvedJavaMethod::klass())) failed: sanity
>>>>>>>>>
>>>>>>>>> Does anyone have any ideas?
>>>>>>>>>
>>>>>>>>> Thanks, Chris
>>>>>>>>>
>>>>>>>>> -- 
>>>>>>>>> The University of Edinburgh is a charitable body, registered in
>>>>>>>>> Scotland, with registration number SC005336.
>>>>>>>>>
>>>>>>> -- 
>>>>>>> The University of Edinburgh is a charitable body, registered in
>>>>>>> Scotland, with registration number SC005336.
>>>>>>>
>>>>>>>
>>>>>> -- 
>>>>>> The University of Edinburgh is a charitable body, registered in
>>>>>> Scotland, with registration number SC005336.
>>>>>>
>>>> -- 
>>>> The University of Edinburgh is a charitable body, registered in
>>>> Scotland, with registration number SC005336.
>>>>


From thomas.wuerthinger at oracle.com  Tue Jul 16 10:31:23 2013
From: thomas.wuerthinger at oracle.com (Thomas Wuerthinger)
Date: Tue, 16 Jul 2013 10:31:23 -0700
Subject: Modifying graph to include InvokeNode
In-Reply-To: <680474C2-27D9-4FD8-9AF9-E3690F29A923@oracle.com>
References: <917C3B2B-52B0-4B9F-A3A4-FAB598A2EA29@sms.ed.ac.uk>
	<920EF6F2-121B-4723-A760-9CA7FACC33D0@oracle.com>
	<C0E75C84-C04F-42CB-892E-C66E8D649EE8@sms.ed.ac.uk>
	<E2C4ACBD-0501-4E9A-A919-888C6BC04BE6@sms.ed.ac.uk>
	<50EF85C2-FF3F-4341-9169-46BAB0BC94A3@oracle.com>
	<51E55B90.3060205@ed.ac.uk>
	<DF5F8528-72B4-4F59-8042-F06232539537@oracle.com>
	<51E567C1.50302@univ-mlv.fr>
	<680474C2-27D9-4FD8-9AF9-E3690F29A923@oracle.com>
Message-ID: <3CDA627C-3530-4A97-9A53-88652E0CB7CC@oracle.com>

Actually Graal fully supports and optimizes invokedynamic and JSR292 code.

- thomas

On Jul 16, 2013, at 9:03 AM, Doug Simon <doug.simon at oracle.com> wrote:

> 
> On Jul 16, 2013, at 5:33 PM, Remi Forax <forax at univ-mlv.fr> wrote:
> 
>> On 07/16/2013 05:27 PM, Doug Simon wrote:
>>> On Jul 16, 2013, at 4:41 PM, Christophe Dubach <christophe.dubach at ed.ac.uk> wrote:
>>> 
>>>> Dear Doug,
>>>> 
>>>> I'm currently supervising Chris with his work and have been following the discussion.
>>>> 
>>>> I am quite surprised that it is not possible to add an InvokeNode in a the graph of a method at runtime. When you say "We can only add static calls that are guaranteed to never be deoptimized" do you mean the callee or the caller? I am probably ignorant but I don't see what would be the difference between inserting an invokeNode to static method (not created dynamically) and an IntergerAdd node in the graph at runtime.
>>> An invoke node (that doesn't get inlined) in method A that calls method B will result in a call in the generated code. During execution of B, something may happen to invalidate an assumption made when compiling A (e.g., class loading invalidating a class hierarchy speculation). This means A is now invalid and needs to be deoptimized upon return from B. In the current system, we rely on HotSpot's deoptimization infrastructure to continue execution at the return site of A in the interpreter. HotSpot only (currently) supports deoptimize-on-return for call sites that have the BCI of an invoke bytecode.
>>> 
>>> One could modify HotSpot to have more general deoptimization support or we could modify Graal to handle invokes inserted for instrumentation. However, both of these tasks are non-trivial. Since our current focus is not on making Graal an all purpose instrumentation framework, we probably won't invest much effort in them in the near future.
>>> 
>>>> Anyway, thanks for the suggestion of doing bytecode instrumentation. Is it possible to do this directly with Graal or where you talking about patching the method at class load time?
>>> The latter. Although you could use Graal in conjunction with a bytecode instrumentation library such as ASM for building a graph from the bytecode and finding the loops.
>>> 
>>>> In our scenario, we want to limit our instrumentation to hot methods in order to further optimise them, therefore, we were aiming to do all this in the jit compiler.
>>> What you really want is a Java interpreter based on Truffle[1][2]. We have gone someway down this path ourselves but don't yet have anything publicly available.
>> 
>> The other solution is to use invokedynamic, if Graal support it ?
> 
> It supports it but does not (yet) optimize it.
> 
> -Doug
> 
>> 
>>>> Thanks,
>>>> Christophe.
>>>> 
>>>> 
>>>> On 16/07/13 14:43, Doug Simon wrote:
>>>>> On Jul 16, 2013, at 3:27 PM, ATKIN-GRANVILLE Chris <s1255753 at sms.ed.ac.uk> wrote:
>>>>> 
>>>>>> Oh, that may have been a silly thing to say, I know you can't "get" the BCI of a method call that doesn't exist in the bytecode. Even still, it seems like quite a large omission from graal to not be able to add static method calls into a graph?
>>>>> We can only add static calls that are guaranteed to never be deoptimized since there is no valid interpreter state to continue in for such invocations. I doubt that any bytecode compiler that relies on deoptimization could do any different?
>>>>> 
>>>>> For your use case, bytecode instrumentation is what you want. Especially since you (seem to) need complete dynamic coverage of the code patterns you are interested in instrumenting.
>>>>> 
>>>>> -Doug
>>>>> 
>>>>>> On 16 Jul 2013, at 14:19, ATKIN-GRANVILLE Chris <s1255753 at sms.ed.ac.uk>
>>>>>> wrote:
>>>>>> 
>>>>>>> Is it not possible to somehow "get" that BCI? It doesn't seem like adding static method calls should be impossible when graph transformations are possible...
>>>>>>> 
>>>>>>> On 16 Jul 2013, at 14:14, Doug Simon <doug.simon at oracle.com>
>>>>>>> wrote:
>>>>>>> 
>>>>>>>> This is almost certainly due to the fact that an invoke node must be associated with the BCI of a real invoke bytecode instruction. Otherwise, where would the interpreter resume if there is a deoptimization  during the invocation?
>>>>>>>> 
>>>>>>>> On Jul 16, 2013, at 2:22 PM, ATKIN-GRANVILLE Chris <s1255753 at sms.ed.ac.uk> wrote:
>>>>>>>> 
>>>>>>>>> Hi there,
>>>>>>>>> 
>>>>>>>>> I'm trying to modify the graph to include an invoke node to a static function after certain node types. I'm modifying the graph at a high level before LoweringPhase.class (not a requirement, can change if required). However, I'm running into issues with JVM fatal errors. The code I have at the moment looks like this:
>>>>>>>>> 
>>>>>>>>> public class MyPhase extends Phase {
>>>>>>>>> 	public void run(StructuredGraph graph) {
>>>>>>>>> 		for (Node node: graph.getNode()) {
>>>>>>>>> 
>>>>>>>>> 			if ( node instanceof RandomFixedNode) {
>>>>>>>>> 				RandomFixedNode rfm = (RandomFixedNode) node;
>>>>>>>>> 				
>>>>>>>>> 				try {
>>>>>>>>> 					ResolvedJavaMethod method = getMethod(?);
>>>>>>>>> 					MethodCallTargetMode callTarget = graph.add(new MethodCallTargetNode(MethodCallTargetNode.InvokeKind.Static,
>>>>>>>>> 						method, new ValueNode[] {}, new HotSpotResolvedPrimitiveType(Kind.Void)));
>>>>>>>>> 
>>>>>>>>> 					InvokeNode invoke = graph.add(new InvokeNode(callTarget, FrameState.UNKNOWN_BCI));
>>>>>>>>> 					invoke.setStateAfter(graph.add(new FrameState(FrameState.UNKNOWN_BCI)));
>>>>>>>>> 					graph.addAfterFixed(rfm, invoke);
>>>>>>>>> 				
>>>>>>>>> 				} catch (Exception e) {
>>>>>>>>> 					e.printStackTrace();
>>>>>>>>> 				}
>>>>>>>>> 			}
>>>>>>>>> 
>>>>>>>>> 		}
>>>>>>>>> 	}
>>>>>>>>> }
>>>>>>>>> 
>>>>>>>>> I'm pretty sure the problem is do with the BCIs and/or the FrameStates, but I don't know how to fix it. The error that I get is:
>>>>>>>>> 
>>>>>>>>> Internal Error (/Volumes/Acme/Development/graal/src/share/vm/graal/graalCompilerToVM.cpp:44), pid=8466, tid=5379
>>>>>>>>> assert(hotspot_method != NULL && hotspot_method->is_a(HotSpotResolvedJavaMethod::klass())) failed: sanity
>>>>>>>>> 
>>>>>>>>> Does anyone have any ideas?
>>>>>>>>> 
>>>>>>>>> Thanks, Chris
>>>>>>>>> 
>>>>>>>>> -- 
>>>>>>>>> The University of Edinburgh is a charitable body, registered in
>>>>>>>>> Scotland, with registration number SC005336.
>>>>>>>>> 
>>>>>>> 
>>>>>>> -- 
>>>>>>> The University of Edinburgh is a charitable body, registered in
>>>>>>> Scotland, with registration number SC005336.
>>>>>>> 
>>>>>>> 
>>>>>> 
>>>>>> -- 
>>>>>> The University of Edinburgh is a charitable body, registered in
>>>>>> Scotland, with registration number SC005336.
>>>>>> 
>>>> 
>>>> -- 
>>>> The University of Edinburgh is a charitable body, registered in
>>>> Scotland, with registration number SC005336.
>>>> 
>> 
> 


From doug.simon at oracle.com  Tue Jul 16 10:39:43 2013
From: doug.simon at oracle.com (Doug Simon)
Date: Tue, 16 Jul 2013 19:39:43 +0200
Subject: Modifying graph to include InvokeNode
In-Reply-To: <3CDA627C-3530-4A97-9A53-88652E0CB7CC@oracle.com>
References: <917C3B2B-52B0-4B9F-A3A4-FAB598A2EA29@sms.ed.ac.uk>
	<920EF6F2-121B-4723-A760-9CA7FACC33D0@oracle.com>
	<C0E75C84-C04F-42CB-892E-C66E8D649EE8@sms.ed.ac.uk>
	<E2C4ACBD-0501-4E9A-A919-888C6BC04BE6@sms.ed.ac.uk>
	<50EF85C2-FF3F-4341-9169-46BAB0BC94A3@oracle.com>
	<51E55B90.3060205@ed.ac.uk>
	<DF5F8528-72B4-4F59-8042-F06232539537@oracle.com>
	<51E567C1.50302@univ-mlv.fr>
	<680474C2-27D9-4FD8-9AF9-E3690F29A923@oracle.com>
	<3CDA627C-3530-4A97-9A53-88652E0CB7CC@oracle.com>
Message-ID: <2F43BD10-87CC-451A-83F5-2D2992407D8F@oracle.com>

As much as C2? If so, that's a pleasant surprise (to me at least).

Sent from my iPhone

On Jul 16, 2013, at 7:31 PM, Thomas Wuerthinger <thomas.wuerthinger at oracle.com> wrote:

> Actually Graal fully supports and optimizes invokedynamic and JSR292 code.
> 
> - thomas
> 
> On Jul 16, 2013, at 9:03 AM, Doug Simon <doug.simon at oracle.com> wrote:
> 
>> 
>> On Jul 16, 2013, at 5:33 PM, Remi Forax <forax at univ-mlv.fr> wrote:
>> 
>>> On 07/16/2013 05:27 PM, Doug Simon wrote:
>>>> On Jul 16, 2013, at 4:41 PM, Christophe Dubach <christophe.dubach at ed.ac.uk> wrote:
>>>> 
>>>>> Dear Doug,
>>>>> 
>>>>> I'm currently supervising Chris with his work and have been following the discussion.
>>>>> 
>>>>> I am quite surprised that it is not possible to add an InvokeNode in a the graph of a method at runtime. When you say "We can only add static calls that are guaranteed to never be deoptimized" do you mean the callee or the caller? I am probably ignorant but I don't see what would be the difference between inserting an invokeNode to static method (not created dynamically) and an IntergerAdd node in the graph at runtime.
>>>> An invoke node (that doesn't get inlined) in method A that calls method B will result in a call in the generated code. During execution of B, something may happen to invalidate an assumption made when compiling A (e.g., class loading invalidating a class hierarchy speculation). This means A is now invalid and needs to be deoptimized upon return from B. In the current system, we rely on HotSpot's deoptimization infrastructure to continue execution at the return site of A in the interpreter. HotSpot only (currently) supports deoptimize-on-return for call sites that have the BCI of an invoke bytecode.
>>>> 
>>>> One could modify HotSpot to have more general deoptimization support or we could modify Graal to handle invokes inserted for instrumentation. However, both of these tasks are non-trivial. Since our current focus is not on making Graal an all purpose instrumentation framework, we probably won't invest much effort in them in the near future.
>>>> 
>>>>> Anyway, thanks for the suggestion of doing bytecode instrumentation. Is it possible to do this directly with Graal or where you talking about patching the method at class load time?
>>>> The latter. Although you could use Graal in conjunction with a bytecode instrumentation library such as ASM for building a graph from the bytecode and finding the loops.
>>>> 
>>>>> In our scenario, we want to limit our instrumentation to hot methods in order to further optimise them, therefore, we were aiming to do all this in the jit compiler.
>>>> What you really want is a Java interpreter based on Truffle[1][2]. We have gone someway down this path ourselves but don't yet have anything publicly available.
>>> 
>>> The other solution is to use invokedynamic, if Graal support it ?
>> 
>> It supports it but does not (yet) optimize it.
>> 
>> -Doug
>> 
>>> 
>>>>> Thanks,
>>>>> Christophe.
>>>>> 
>>>>> 
>>>>> On 16/07/13 14:43, Doug Simon wrote:
>>>>>> On Jul 16, 2013, at 3:27 PM, ATKIN-GRANVILLE Chris <s1255753 at sms.ed.ac.uk> wrote:
>>>>>> 
>>>>>>> Oh, that may have been a silly thing to say, I know you can't "get" the BCI of a method call that doesn't exist in the bytecode. Even still, it seems like quite a large omission from graal to not be able to add static method calls into a graph?
>>>>>> We can only add static calls that are guaranteed to never be deoptimized since there is no valid interpreter state to continue in for such invocations. I doubt that any bytecode compiler that relies on deoptimization could do any different?
>>>>>> 
>>>>>> For your use case, bytecode instrumentation is what you want. Especially since you (seem to) need complete dynamic coverage of the code patterns you are interested in instrumenting.
>>>>>> 
>>>>>> -Doug
>>>>>> 
>>>>>>> On 16 Jul 2013, at 14:19, ATKIN-GRANVILLE Chris <s1255753 at sms.ed.ac.uk>
>>>>>>> wrote:
>>>>>>> 
>>>>>>>> Is it not possible to somehow "get" that BCI? It doesn't seem like adding static method calls should be impossible when graph transformations are possible...
>>>>>>>> 
>>>>>>>> On 16 Jul 2013, at 14:14, Doug Simon <doug.simon at oracle.com>
>>>>>>>> wrote:
>>>>>>>> 
>>>>>>>>> This is almost certainly due to the fact that an invoke node must be associated with the BCI of a real invoke bytecode instruction. Otherwise, where would the interpreter resume if there is a deoptimization  during the invocation?
>>>>>>>>> 
>>>>>>>>> On Jul 16, 2013, at 2:22 PM, ATKIN-GRANVILLE Chris <s1255753 at sms.ed.ac.uk> wrote:
>>>>>>>>> 
>>>>>>>>>> Hi there,
>>>>>>>>>> 
>>>>>>>>>> I'm trying to modify the graph to include an invoke node to a static function after certain node types. I'm modifying the graph at a high level before LoweringPhase.class (not a requirement, can change if required). However, I'm running into issues with JVM fatal errors. The code I have at the moment looks like this:
>>>>>>>>>> 
>>>>>>>>>> public class MyPhase extends Phase {
>>>>>>>>>>    public void run(StructuredGraph graph) {
>>>>>>>>>>        for (Node node: graph.getNode()) {
>>>>>>>>>> 
>>>>>>>>>>            if ( node instanceof RandomFixedNode) {
>>>>>>>>>>                RandomFixedNode rfm = (RandomFixedNode) node;
>>>>>>>>>>                
>>>>>>>>>>                try {
>>>>>>>>>>                    ResolvedJavaMethod method = getMethod(?);
>>>>>>>>>>                    MethodCallTargetMode callTarget = graph.add(new MethodCallTargetNode(MethodCallTargetNode.InvokeKind.Static,
>>>>>>>>>>                        method, new ValueNode[] {}, new HotSpotResolvedPrimitiveType(Kind.Void)));
>>>>>>>>>> 
>>>>>>>>>>                    InvokeNode invoke = graph.add(new InvokeNode(callTarget, FrameState.UNKNOWN_BCI));
>>>>>>>>>>                    invoke.setStateAfter(graph.add(new FrameState(FrameState.UNKNOWN_BCI)));
>>>>>>>>>>                    graph.addAfterFixed(rfm, invoke);
>>>>>>>>>>                
>>>>>>>>>>                } catch (Exception e) {
>>>>>>>>>>                    e.printStackTrace();
>>>>>>>>>>                }
>>>>>>>>>>            }
>>>>>>>>>> 
>>>>>>>>>>        }
>>>>>>>>>>    }
>>>>>>>>>> }
>>>>>>>>>> 
>>>>>>>>>> I'm pretty sure the problem is do with the BCIs and/or the FrameStates, but I don't know how to fix it. The error that I get is:
>>>>>>>>>> 
>>>>>>>>>> Internal Error (/Volumes/Acme/Development/graal/src/share/vm/graal/graalCompilerToVM.cpp:44), pid=8466, tid=5379
>>>>>>>>>> assert(hotspot_method != NULL && hotspot_method->is_a(HotSpotResolvedJavaMethod::klass())) failed: sanity
>>>>>>>>>> 
>>>>>>>>>> Does anyone have any ideas?
>>>>>>>>>> 
>>>>>>>>>> Thanks, Chris
>>>>>>>>>> 
>>>>>>>>>> -- 
>>>>>>>>>> The University of Edinburgh is a charitable body, registered in
>>>>>>>>>> Scotland, with registration number SC005336.
>>>>>>>> 
>>>>>>>> -- 
>>>>>>>> The University of Edinburgh is a charitable body, registered in
>>>>>>>> Scotland, with registration number SC005336.
>>>>>>> 
>>>>>>> -- 
>>>>>>> The University of Edinburgh is a charitable body, registered in
>>>>>>> Scotland, with registration number SC005336.
>>>>> 
>>>>> -- 
>>>>> The University of Edinburgh is a charitable body, registered in
>>>>> Scotland, with registration number SC005336.
> 

From christian.thalinger at oracle.com  Tue Jul 16 11:00:14 2013
From: christian.thalinger at oracle.com (Christian Thalinger)
Date: Tue, 16 Jul 2013 11:00:14 -0700
Subject: Modifying graph to include InvokeNode
In-Reply-To: <2F43BD10-87CC-451A-83F5-2D2992407D8F@oracle.com>
References: <917C3B2B-52B0-4B9F-A3A4-FAB598A2EA29@sms.ed.ac.uk>
	<920EF6F2-121B-4723-A760-9CA7FACC33D0@oracle.com>
	<C0E75C84-C04F-42CB-892E-C66E8D649EE8@sms.ed.ac.uk>
	<E2C4ACBD-0501-4E9A-A919-888C6BC04BE6@sms.ed.ac.uk>
	<50EF85C2-FF3F-4341-9169-46BAB0BC94A3@oracle.com>
	<51E55B90.3060205@ed.ac.uk>
	<DF5F8528-72B4-4F59-8042-F06232539537@oracle.com>
	<51E567C1.50302@univ-mlv.fr>
	<680474C2-27D9-4FD8-9AF9-E3690F29A923@oracle.com>
	<3CDA627C-3530-4A97-9A53-88652E0CB7CC@oracle.com>
	<2F43BD10-87CC-451A-83F5-2D2992407D8F@oracle.com>
Message-ID: <7F129A6A-509E-4812-9B68-5062B14D9B6D@oracle.com>


On Jul 16, 2013, at 10:39 AM, Doug Simon <doug.simon at oracle.com> wrote:

> As much as C2? If so, that's a pleasant surprise (to me at least).

Yeah, I pushed the change some time ago based on the work from? sorry, I forgot his name.  Perhaps a Christian ;-)

Performance was a bit behind compared to C2, though.  Christian Haeubl did some inlining work but I think we are not there yet.

-- Chris

> 
> Sent from my iPhone
> 
> On Jul 16, 2013, at 7:31 PM, Thomas Wuerthinger <thomas.wuerthinger at oracle.com> wrote:
> 
>> Actually Graal fully supports and optimizes invokedynamic and JSR292 code.
>> 
>> - thomas
>> 
>> On Jul 16, 2013, at 9:03 AM, Doug Simon <doug.simon at oracle.com> wrote:
>> 
>>> 
>>> On Jul 16, 2013, at 5:33 PM, Remi Forax <forax at univ-mlv.fr> wrote:
>>> 
>>>> On 07/16/2013 05:27 PM, Doug Simon wrote:
>>>>> On Jul 16, 2013, at 4:41 PM, Christophe Dubach <christophe.dubach at ed.ac.uk> wrote:
>>>>> 
>>>>>> Dear Doug,
>>>>>> 
>>>>>> I'm currently supervising Chris with his work and have been following the discussion.
>>>>>> 
>>>>>> I am quite surprised that it is not possible to add an InvokeNode in a the graph of a method at runtime. When you say "We can only add static calls that are guaranteed to never be deoptimized" do you mean the callee or the caller? I am probably ignorant but I don't see what would be the difference between inserting an invokeNode to static method (not created dynamically) and an IntergerAdd node in the graph at runtime.
>>>>> An invoke node (that doesn't get inlined) in method A that calls method B will result in a call in the generated code. During execution of B, something may happen to invalidate an assumption made when compiling A (e.g., class loading invalidating a class hierarchy speculation). This means A is now invalid and needs to be deoptimized upon return from B. In the current system, we rely on HotSpot's deoptimization infrastructure to continue execution at the return site of A in the interpreter. HotSpot only (currently) supports deoptimize-on-return for call sites that have the BCI of an invoke bytecode.
>>>>> 
>>>>> One could modify HotSpot to have more general deoptimization support or we could modify Graal to handle invokes inserted for instrumentation. However, both of these tasks are non-trivial. Since our current focus is not on making Graal an all purpose instrumentation framework, we probably won't invest much effort in them in the near future.
>>>>> 
>>>>>> Anyway, thanks for the suggestion of doing bytecode instrumentation. Is it possible to do this directly with Graal or where you talking about patching the method at class load time?
>>>>> The latter. Although you could use Graal in conjunction with a bytecode instrumentation library such as ASM for building a graph from the bytecode and finding the loops.
>>>>> 
>>>>>> In our scenario, we want to limit our instrumentation to hot methods in order to further optimise them, therefore, we were aiming to do all this in the jit compiler.
>>>>> What you really want is a Java interpreter based on Truffle[1][2]. We have gone someway down this path ourselves but don't yet have anything publicly available.
>>>> 
>>>> The other solution is to use invokedynamic, if Graal support it ?
>>> 
>>> It supports it but does not (yet) optimize it.
>>> 
>>> -Doug
>>> 
>>>> 
>>>>>> Thanks,
>>>>>> Christophe.
>>>>>> 
>>>>>> 
>>>>>> On 16/07/13 14:43, Doug Simon wrote:
>>>>>>> On Jul 16, 2013, at 3:27 PM, ATKIN-GRANVILLE Chris <s1255753 at sms.ed.ac.uk> wrote:
>>>>>>> 
>>>>>>>> Oh, that may have been a silly thing to say, I know you can't "get" the BCI of a method call that doesn't exist in the bytecode. Even still, it seems like quite a large omission from graal to not be able to add static method calls into a graph?
>>>>>>> We can only add static calls that are guaranteed to never be deoptimized since there is no valid interpreter state to continue in for such invocations. I doubt that any bytecode compiler that relies on deoptimization could do any different?
>>>>>>> 
>>>>>>> For your use case, bytecode instrumentation is what you want. Especially since you (seem to) need complete dynamic coverage of the code patterns you are interested in instrumenting.
>>>>>>> 
>>>>>>> -Doug
>>>>>>> 
>>>>>>>> On 16 Jul 2013, at 14:19, ATKIN-GRANVILLE Chris <s1255753 at sms.ed.ac.uk>
>>>>>>>> wrote:
>>>>>>>> 
>>>>>>>>> Is it not possible to somehow "get" that BCI? It doesn't seem like adding static method calls should be impossible when graph transformations are possible...
>>>>>>>>> 
>>>>>>>>> On 16 Jul 2013, at 14:14, Doug Simon <doug.simon at oracle.com>
>>>>>>>>> wrote:
>>>>>>>>> 
>>>>>>>>>> This is almost certainly due to the fact that an invoke node must be associated with the BCI of a real invoke bytecode instruction. Otherwise, where would the interpreter resume if there is a deoptimization  during the invocation?
>>>>>>>>>> 
>>>>>>>>>> On Jul 16, 2013, at 2:22 PM, ATKIN-GRANVILLE Chris <s1255753 at sms.ed.ac.uk> wrote:
>>>>>>>>>> 
>>>>>>>>>>> Hi there,
>>>>>>>>>>> 
>>>>>>>>>>> I'm trying to modify the graph to include an invoke node to a static function after certain node types. I'm modifying the graph at a high level before LoweringPhase.class (not a requirement, can change if required). However, I'm running into issues with JVM fatal errors. The code I have at the moment looks like this:
>>>>>>>>>>> 
>>>>>>>>>>> public class MyPhase extends Phase {
>>>>>>>>>>>   public void run(StructuredGraph graph) {
>>>>>>>>>>>       for (Node node: graph.getNode()) {
>>>>>>>>>>> 
>>>>>>>>>>>           if ( node instanceof RandomFixedNode) {
>>>>>>>>>>>               RandomFixedNode rfm = (RandomFixedNode) node;
>>>>>>>>>>> 
>>>>>>>>>>>               try {
>>>>>>>>>>>                   ResolvedJavaMethod method = getMethod(?);
>>>>>>>>>>>                   MethodCallTargetMode callTarget = graph.add(new MethodCallTargetNode(MethodCallTargetNode.InvokeKind.Static,
>>>>>>>>>>>                       method, new ValueNode[] {}, new HotSpotResolvedPrimitiveType(Kind.Void)));
>>>>>>>>>>> 
>>>>>>>>>>>                   InvokeNode invoke = graph.add(new InvokeNode(callTarget, FrameState.UNKNOWN_BCI));
>>>>>>>>>>>                   invoke.setStateAfter(graph.add(new FrameState(FrameState.UNKNOWN_BCI)));
>>>>>>>>>>>                   graph.addAfterFixed(rfm, invoke);
>>>>>>>>>>> 
>>>>>>>>>>>               } catch (Exception e) {
>>>>>>>>>>>                   e.printStackTrace();
>>>>>>>>>>>               }
>>>>>>>>>>>           }
>>>>>>>>>>> 
>>>>>>>>>>>       }
>>>>>>>>>>>   }
>>>>>>>>>>> }
>>>>>>>>>>> 
>>>>>>>>>>> I'm pretty sure the problem is do with the BCIs and/or the FrameStates, but I don't know how to fix it. The error that I get is:
>>>>>>>>>>> 
>>>>>>>>>>> Internal Error (/Volumes/Acme/Development/graal/src/share/vm/graal/graalCompilerToVM.cpp:44), pid=8466, tid=5379
>>>>>>>>>>> assert(hotspot_method != NULL && hotspot_method->is_a(HotSpotResolvedJavaMethod::klass())) failed: sanity
>>>>>>>>>>> 
>>>>>>>>>>> Does anyone have any ideas?
>>>>>>>>>>> 
>>>>>>>>>>> Thanks, Chris
>>>>>>>>>>> 
>>>>>>>>>>> -- 
>>>>>>>>>>> The University of Edinburgh is a charitable body, registered in
>>>>>>>>>>> Scotland, with registration number SC005336.
>>>>>>>>> 
>>>>>>>>> -- 
>>>>>>>>> The University of Edinburgh is a charitable body, registered in
>>>>>>>>> Scotland, with registration number SC005336.
>>>>>>>> 
>>>>>>>> -- 
>>>>>>>> The University of Edinburgh is a charitable body, registered in
>>>>>>>> Scotland, with registration number SC005336.
>>>>>> 
>>>>>> -- 
>>>>>> The University of Edinburgh is a charitable body, registered in
>>>>>> Scotland, with registration number SC005336.
>> 


From tom.deneau at amd.com  Tue Jul 16 11:58:42 2013
From: tom.deneau at amd.com (Deneau, Tom)
Date: Tue, 16 Jul 2013 18:58:42 +0000
Subject: patch for additional graal HSAIL backend functionality
In-Reply-To: <18FCE83C-7E6E-465F-962F-819CEAA07F8E@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>
	<F52F166A-DACB-4724-81D7-EA8D97B252E0@oracle.com>
	<5DD1503F815BD14889DC81D28643E3A73D90E619@sausexdag06.amd.com>
	<4D9C9697-3403-450E-AEF6-190FA35E145F@oracle.com>
	<3ACAB77C-2869-4D59-B224-AEE840F2E70B@oracle.com>
	<79BF6EED-6F10-4C1D-AA29-0D870F68B323@oracle.com>
	<5DD1503F815BD14889DC81D28643E3A73D9117CB@sausexdag06.amd.com>
	<1231D68C-1019-43A5-8D08-8CFCF48E4ED5@oracle.com>
	<BC97738F8E7C8742BABED7F06FB9DF9145039D0C@sausexdag01.amd.com>
	<67EC7C6A-3A6D-4A08-BED4-3779C5E26F04@oracle.com>
	<BC97738F8E7C8742BABED7F06FB9DF9145039D78@sausexdag01.amd.com>
	<8B7AC96E-DA54-41FA-A371-4E63A4478B18@oracle.com>
	<BC97738F8E7C8742BABED7F06FB9DF914503A521@sausexdag01.amd.com>
	<8671FB33-4084-44C6-BB9A-C6B42C2FFBC! 1@oracle.com>
	<BC97738F8E7C8742BABED7F06FB9DF914504304E@sausexdag01.amd.com>
	<18FCE83C-7E6E-465F-962F-819CEAA07F8E@oracle.com>
Message-ID: <BC97738F8E7C8742BABED7F06FB9DF9145045AC7@sausexdag01.amd.com>

Doug --

Can you say a little more about what you meant by "Graal doesn't yet have proper support for multiple, configurable backends."

-- Tom

-----Original Message-----
From: Doug Simon [mailto:doug.simon at oracle.com] 
Sent: Monday, July 15, 2013 11:10 AM
To: Deneau, Tom
Cc: graal-dev at openjdk.java.net
Subject: Re: patch for additional graal HSAIL backend functionality


On Jul 15, 2013, at 2:38 PM, "Deneau, Tom" <tom.deneau at amd.com> wrote:

> Doug --
> 
> Yes, go ahead and make those fixes as part of your integration.
> With regards to the HSAILLIRGenerator, did you mean to say that the HSAILLIRGenerator should be in co.graal.compiler.hsail
> (like it is now) and there should be a new HSAILHotSpotLIRGenerator class in c.o.graal.hotspot.hsail?

Yes. However, I've realized that doing the proposed refactoring right now is a little premature given that Graal doesn't yet have proper support for multiple, configurable backends.

> For the original layout, I think Vasanth followed the way PTX was laid out

Ok, makes sense.

> Sorry for the eclipse errors I realize now I forgot to specify the JDT compiler on the mx command line.

You're not using Eclipse?! ;-)

-Doug

> $ find graal -print | grep LIRGenerator.java
> graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/gen/LIRGenerator.java
> graal/com.oracle.graal.hotspot.sparc/src/com/oracle/graal/hotspot/sparc/SPARCHotSpotLIRGenerator.java
> graal/com.oracle.graal.hotspot.amd64/src/com/oracle/graal/hotspot/amd64/AMD64HotSpotLIRGenerator.java
> graal/com.oracle.graal.compiler.ptx/src/com/oracle/graal/compiler/ptx/PTXLIRGenerator.java
> graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/HotSpotLIRGenerator.java
> graal/com.oracle.graal.compiler.amd64/src/com/oracle/graal/compiler/amd64/AMD64LIRGenerator.java
> graal/com.oracle.graal.compiler.sparc/src/com/oracle/graal/compiler/sparc/SPARCLIRGenerator.java
> graal/com.oracle.graal.compiler.hsail/src/com/oracle/graal/compiler/hsail/HSAILLIRGenerator.java
> 
> -----Original Message-----
> From: Doug Simon [mailto:doug.simon at oracle.com] 
> Sent: Monday, July 15, 2013 4:17 AM
> To: Deneau, Tom
> Cc: graal-dev at openjdk.java.net
> Subject: Re: patch for additional graal HSAIL backend functionality
> 
> - this patch contains Eclipse errors (2) and warnings (13)
> - ForeignCallNoOp0 -> ForeignCallNoArgOp
> - ForeignCallNoOp1 -> ForeignCall1ArgOp
> 
> To save turn around time, I can simply make these fixes as part of my integration.
> 
> I also noticed for the first time that the c.o.graal.compiler.hsail project depends on c.o.graal.hotspot.amd64. The dependencies and structure for the HSAIL backend should more closely follow that for the AMD64 backend. The HSAILLIRGenerator class should be in the c.o.graal.lir.hsail project and there should be a HSAILHotSpotLIRGenerator subclass in a c.o.graal.hotspot.hsail project. Only the latter should introduce any HotSpot dependencies. I'm happy to make these refactoring if want.
> 
> -Doug
> 
> On Jul 13, 2013, at 1:26 AM, "Deneau, Tom" <tom.deneau at amd.com> wrote:
> 
>> Please review the following webrev.  This webrev adds some new
>> features to the HSAIL backend, which are listed below:
>> 
>> -- Tom
>> 
>> http://cr.openjdk.java.net/~tdeneau/graal-webrevs/graal-webrev-3.0/
>> 
>> 
>> * stackslot mapping was incorrect when combinations of 32-bit and
>> 64-bit stores were generated.  StackSlot alignment in
>> HSAILTargetDescription set to 8.
>> 
>> * compressedOops support in various heap size configurations (with or
>> without either of shift or heap base).  So we don't need
>> XX:-UseCompressedOops anymore.
>> 
>> * some support for unsigned shifts, long shifts, logical ops for long
>> datatype.
>> 
>> * a new GraalOption, InlineEverything.  Some HSAIL targets are not
>> able to handle HSAIL function calls yet, plus we are still working
>> on emitting HSAIL function calls in the compiler.
>> 
>> * hack for emitForeignCall special cases of createOutOfBoundsException
>> or createNullPointerException.  (We just emit a comment.  Real
>> exception handling still pending).  These nodes came about when we
>> more aggressively inlined, although this has not been explained yet.
>> 
>> * support HSAILAddressValues as operands for arithmetic ops.  Use
>> HSAIL lda instruction to get address into a register.  Used in
>> particular for USHR for card-marking.
>> 
>> * Added some new junit tests. (some ported from their lambda versions)
>> 
>>  * StaticNBodyCallTest which would fail with default inlining (since
>>    we don't yet generate HSAIL calls).  It uses junit.assumeTrue and
>>    tests whether InlineEverything is set.  It (and also some
>>    lambda-based junit tests not part of this webrev) do pass nicely
>>    when InlineEverything is set true.
>> 
>>  * tests for storing an object, which test being able to handle the
>>    card-marking logic, as well as the encoding and decoding of a
>>    compressed oop.
>> 
>>  * some 2D matrix tests that showed a problem before the stackslot
>>    change above.  (have a mixture of 32-bit and 64-bit stackslot
>>    spills)
>> 
>> 
> 
> 
> 




From doug.simon at oracle.com  Tue Jul 16 12:10:54 2013
From: doug.simon at oracle.com (Doug Simon)
Date: Tue, 16 Jul 2013 21:10:54 +0200
Subject: patch for additional graal HSAIL backend functionality
In-Reply-To: <BC97738F8E7C8742BABED7F06FB9DF9145045AC7@sausexdag01.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>
	<F52F166A-DACB-4724-81D7-EA8D97B252E0@oracle.com>
	<5DD1503F815BD14889DC81D28643E3A73D90E619@sausexdag06.amd.com>
	<4D9C9697-3403-450E-AEF6-190FA35E145F@oracle.com>
	<3ACAB77C-2869-4D59-B224-AEE840F2E70B@oracle.com>
	<79BF6EED-6F10-4C1D-AA29-0D870F68B323@oracle.com>
	<5DD1503F815BD14889DC81D28643E3A73D9117CB@sausexdag06.amd.com>
	<1231D68C-1019-43A5-8D08-8CFCF48E4ED5@oracle.com>
	<BC97738F8E7C8742BABED7F06FB9DF9145039D0C@sausexdag01.amd.com>
	<67EC7C6A-3A6D-4A08-BED4-3779C5E26F04@oracle.com>
	<BC97738F8E7C8742BABED7F06FB9DF9145039D78@sausexdag01.amd.com>
	<8B7AC96E-DA54-41FA-A371-4E63A4478B18@oracle.com>
	<BC97738F8E7C8742BABED7F06FB9DF914503A521@sausexdag01.amd.com>
	<8671FB33-4084-44C6-BB9A-C6B42C2FFBC! ! 1@oracle.com>
	<BC97738F8E7C8742BABED7F06FB9DF914504304E@sausexdag01.amd.com>
	<18FCE83C-7E6E-465F-962F-819CEAA07F8E@oracle.com>
	<BC97738F8E7C8742BABED7F06FB9DF9145045AC7@sausexdag01.amd.com>
Message-ID: <D8B869BE-4B54-4C85-8864-BEE72C1D9ADD@oracle.com>


On Jul 16, 2013, at 8:58 PM, "Deneau, Tom" <tom.deneau at amd.com> wrote:

> Doug --
> 
> Can you say a little more about what you meant by "Graal doesn't yet have proper support for multiple, configurable backends."

Currently, there is a single Backend instance available via the Graal.getRequiredCapability() API. Ideally, we want something more flexible for a system that has multiple backends (e.g., an AMD64 backend and a HSAIL backend). It maybe something like an extra API method like:

    public static <T> T getRequiredCapability(Class<T> capability, Class<?>... extraCapabilities);

While returns an instance of the capability T that also implements some extra capabilities.

But there may be a better way - we don't want to do API design without some extra thought.

-Doug

> -----Original Message-----
> From: Doug Simon [mailto:doug.simon at oracle.com] 
> Sent: Monday, July 15, 2013 11:10 AM
> To: Deneau, Tom
> Cc: graal-dev at openjdk.java.net
> Subject: Re: patch for additional graal HSAIL backend functionality
> 
> 
> On Jul 15, 2013, at 2:38 PM, "Deneau, Tom" <tom.deneau at amd.com> wrote:
> 
>> Doug --
>> 
>> Yes, go ahead and make those fixes as part of your integration.
>> With regards to the HSAILLIRGenerator, did you mean to say that the HSAILLIRGenerator should be in co.graal.compiler.hsail
>> (like it is now) and there should be a new HSAILHotSpotLIRGenerator class in c.o.graal.hotspot.hsail?
> 
> Yes. However, I've realized that doing the proposed refactoring right now is a little premature given that Graal doesn't yet have proper support for multiple, configurable backends.
> 
>> For the original layout, I think Vasanth followed the way PTX was laid out
> 
> Ok, makes sense.
> 
>> Sorry for the eclipse errors I realize now I forgot to specify the JDT compiler on the mx command line.
> 
> You're not using Eclipse?! ;-)
> 
> -Doug
> 
>> $ find graal -print | grep LIRGenerator.java
>> graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/gen/LIRGenerator.java
>> graal/com.oracle.graal.hotspot.sparc/src/com/oracle/graal/hotspot/sparc/SPARCHotSpotLIRGenerator.java
>> graal/com.oracle.graal.hotspot.amd64/src/com/oracle/graal/hotspot/amd64/AMD64HotSpotLIRGenerator.java
>> graal/com.oracle.graal.compiler.ptx/src/com/oracle/graal/compiler/ptx/PTXLIRGenerator.java
>> graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/HotSpotLIRGenerator.java
>> graal/com.oracle.graal.compiler.amd64/src/com/oracle/graal/compiler/amd64/AMD64LIRGenerator.java
>> graal/com.oracle.graal.compiler.sparc/src/com/oracle/graal/compiler/sparc/SPARCLIRGenerator.java
>> graal/com.oracle.graal.compiler.hsail/src/com/oracle/graal/compiler/hsail/HSAILLIRGenerator.java
>> 
>> -----Original Message-----
>> From: Doug Simon [mailto:doug.simon at oracle.com] 
>> Sent: Monday, July 15, 2013 4:17 AM
>> To: Deneau, Tom
>> Cc: graal-dev at openjdk.java.net
>> Subject: Re: patch for additional graal HSAIL backend functionality
>> 
>> - this patch contains Eclipse errors (2) and warnings (13)
>> - ForeignCallNoOp0 -> ForeignCallNoArgOp
>> - ForeignCallNoOp1 -> ForeignCall1ArgOp
>> 
>> To save turn around time, I can simply make these fixes as part of my integration.
>> 
>> I also noticed for the first time that the c.o.graal.compiler.hsail project depends on c.o.graal.hotspot.amd64. The dependencies and structure for the HSAIL backend should more closely follow that for the AMD64 backend. The HSAILLIRGenerator class should be in the c.o.graal.lir.hsail project and there should be a HSAILHotSpotLIRGenerator subclass in a c.o.graal.hotspot.hsail project. Only the latter should introduce any HotSpot dependencies. I'm happy to make these refactoring if want.
>> 
>> -Doug
>> 
>> On Jul 13, 2013, at 1:26 AM, "Deneau, Tom" <tom.deneau at amd.com> wrote:
>> 
>>> Please review the following webrev.  This webrev adds some new
>>> features to the HSAIL backend, which are listed below:
>>> 
>>> -- Tom
>>> 
>>> http://cr.openjdk.java.net/~tdeneau/graal-webrevs/graal-webrev-3.0/
>>> 
>>> 
>>> * stackslot mapping was incorrect when combinations of 32-bit and
>>> 64-bit stores were generated.  StackSlot alignment in
>>> HSAILTargetDescription set to 8.
>>> 
>>> * compressedOops support in various heap size configurations (with or
>>> without either of shift or heap base).  So we don't need
>>> XX:-UseCompressedOops anymore.
>>> 
>>> * some support for unsigned shifts, long shifts, logical ops for long
>>> datatype.
>>> 
>>> * a new GraalOption, InlineEverything.  Some HSAIL targets are not
>>> able to handle HSAIL function calls yet, plus we are still working
>>> on emitting HSAIL function calls in the compiler.
>>> 
>>> * hack for emitForeignCall special cases of createOutOfBoundsException
>>> or createNullPointerException.  (We just emit a comment.  Real
>>> exception handling still pending).  These nodes came about when we
>>> more aggressively inlined, although this has not been explained yet.
>>> 
>>> * support HSAILAddressValues as operands for arithmetic ops.  Use
>>> HSAIL lda instruction to get address into a register.  Used in
>>> particular for USHR for card-marking.
>>> 
>>> * Added some new junit tests. (some ported from their lambda versions)
>>> 
>>> * StaticNBodyCallTest which would fail with default inlining (since
>>>   we don't yet generate HSAIL calls).  It uses junit.assumeTrue and
>>>   tests whether InlineEverything is set.  It (and also some
>>>   lambda-based junit tests not part of this webrev) do pass nicely
>>>   when InlineEverything is set true.
>>> 
>>> * tests for storing an object, which test being able to handle the
>>>   card-marking logic, as well as the encoding and decoding of a
>>>   compressed oop.
>>> 
>>> * some 2D matrix tests that showed a problem before the stackslot
>>>   change above.  (have a mixture of 32-bit and 64-bit stackslot
>>>   spills)
>>> 
>>> 
>> 
>> 
>> 
> 
> 
> 


From christophe.dubach at ed.ac.uk  Wed Jul 17 07:13:30 2013
From: christophe.dubach at ed.ac.uk (Christophe Dubach)
Date: Wed, 17 Jul 2013 15:13:30 +0100
Subject: Modifying graph to include InvokeNode
In-Reply-To: <EB2C2A5A-556E-4F01-8586-A2B268EDCC61@oracle.com>
References: <917C3B2B-52B0-4B9F-A3A4-FAB598A2EA29@sms.ed.ac.uk>
	<920EF6F2-121B-4723-A760-9CA7FACC33D0@oracle.com>
	<C0E75C84-C04F-42CB-892E-C66E8D649EE8@sms.ed.ac.uk>
	<E2C4ACBD-0501-4E9A-A919-888C6BC04BE6@sms.ed.ac.uk>
	<50EF85C2-FF3F-4341-9169-46BAB0BC94A3@oracle.com>
	<51E55B90.3060205@ed.ac.uk>
	<DF5F8528-72B4-4F59-8042-F06232539537@oracle.com>
	<51E56DBF.4000307@ed.ac.uk>
	<EB2C2A5A-556E-4F01-8586-A2B268EDCC61@oracle.com>
Message-ID: <51E6A68A.4070409@ed.ac.uk>

On 16/07/13 17:38, Doug Simon wrote:
> On Jul 16, 2013, at 5:58 PM, Christophe Dubach <christophe.dubach at ed.ac.uk> wrote:
>
>>> An invoke node (that doesn't get inlined) in method A that calls method B will result in a call in the generated code. During execution of B, something may happen to invalidate an assumption made when compiling A (e.g., class loading invalidating a class hierarchy speculation). This means A is now invalid and needs to be deoptimized upon return from B. In the current system, we rely on HotSpot's deoptimization infrastructure to continue execution at the return site of A in the interpreter. HotSpot only (currently) supports deoptimize-on-return for call sites that have the BCI of an invoke bytecode.
>> Thank you for the clarification, I think I see the problem.
>>
>> Is there a way we could add a new invokeNode in the graph and then force it to get inlined straight-away?
> This is essentially what we do with snippets which is the direction Chris was initially heading. The problem you can still not do anything (like allocating/expanding a data structure) that causes deoptimization in the transitively inlined methods calls.
>
> -Doug

Thanks I understand. This would would should move the problem a little 
further.

What about the use of invokedynamic as suggested by Remi? Would this 
help and if so how?

-- 
The University of Edinburgh is a charitable body, registered in
Scotland, with registration number SC005336.


From doug.simon at oracle.com  Wed Jul 17 09:16:55 2013
From: doug.simon at oracle.com (Doug Simon)
Date: Wed, 17 Jul 2013 18:16:55 +0200
Subject: Modifying graph to include InvokeNode
In-Reply-To: <51E6A68A.4070409@ed.ac.uk>
References: <917C3B2B-52B0-4B9F-A3A4-FAB598A2EA29@sms.ed.ac.uk>
	<920EF6F2-121B-4723-A760-9CA7FACC33D0@oracle.com>
	<C0E75C84-C04F-42CB-892E-C66E8D649EE8@sms.ed.ac.uk>
	<E2C4ACBD-0501-4E9A-A919-888C6BC04BE6@sms.ed.ac.uk>
	<50EF85C2-FF3F-4341-9169-46BAB0BC94A3@oracle.com>
	<51E55B90.3060205@ed.ac.uk>
	<DF5F8528-72B4-4F59-8042-F06232539537@oracle.com>
	<51E56DBF.4000307@ed.ac.uk>
	<EB2C2A5A-556E-4F01-8586-A2B268EDCC61@oracle.com>
	<51E6A68A.4070409@ed.ac.uk>
Message-ID: <0934D95D-D269-4774-A2F3-F87D0F2B0CCD@oracle.com>


On Jul 17, 2013, at 4:13 PM, Christophe Dubach <christophe.dubach at ed.ac.uk> wrote:

> On 16/07/13 17:38, Doug Simon wrote:
>> On Jul 16, 2013, at 5:58 PM, Christophe Dubach <christophe.dubach at ed.ac.uk> wrote:
>> 
>>>> An invoke node (that doesn't get inlined) in method A that calls method B will result in a call in the generated code. During execution of B, something may happen to invalidate an assumption made when compiling A (e.g., class loading invalidating a class hierarchy speculation). This means A is now invalid and needs to be deoptimized upon return from B. In the current system, we rely on HotSpot's deoptimization infrastructure to continue execution at the return site of A in the interpreter. HotSpot only (currently) supports deoptimize-on-return for call sites that have the BCI of an invoke bytecode.
>>> Thank you for the clarification, I think I see the problem.
>>> 
>>> Is there a way we could add a new invokeNode in the graph and then force it to get inlined straight-away?
>> This is essentially what we do with snippets which is the direction Chris was initially heading. The problem you can still not do anything (like allocating/expanding a data structure) that causes deoptimization in the transitively inlined methods calls.
>> 
>> -Doug
> 
> Thanks I understand. This would would should move the problem a little further.
> 
> What about the use of invokedynamic as suggested by Remi? Would this help and if so how?

I'll let Remi or Christian Thalinger address that question as I don't have any real experience with invokedynamic.

-Doug

From tom.deneau at amd.com  Wed Jul 17 10:27:46 2013
From: tom.deneau at amd.com (Deneau, Tom)
Date: Wed, 17 Jul 2013 17:27:46 +0000
Subject: HSAIL Backend: Register getting overwritten as part of Move To Phi
References: <20130715170157.A77A4480BF@hg.openjdk.java.net> 
Message-ID: <BC97738F8E7C8742BABED7F06FB9DF91469EFDC7@sausexdag01.amd.com>

The problem described below was first noticed last week but then I thought
it went away with the large number of checkins on July 15.  But now I see
that it is still there.

I am not sure how to debug this problem so looking for any suggestions.
To help you reproduce the problem on your side, I have a small webrev that
adds the failing test case.   The test case itself uses String.contains and so
needed the capability to properly handle accesses to char arrays and char fields,
so in addition to the failing test case there is a very small change to the HSAIL
backend to support the narrower object types like char.

The webrev can be found at
http://cr.openjdk.java.net/~tdeneau/graal-webrevs/graal-webrev4.0/

One other change in this webrev, I made a change to the okra library loading code
originally suggested by Doug.  Doug was suggesting a new environment variable pointing
to the native library so we wouldn't need the -Dsun.boot.library.path on the java command
line.  Instead I noticed that we were already requiring the directory to be in the PATH
environment variable, so the loading code just looks down the PATH.

In the webrev, this change is simply reflected in a change to the version
of the okra jar file (since the okra code is not part of graal proper).
The change is entirely in the java code, there is no need
to rebuild the actual native libraries.

Reproducing the failing test case...

With the patch applied, you should be able to get the test case failure with the following:

   * mx --vm server build product
   * mx --vm server unittest @-G:InlineEverything @-Dkerneltester.logLevel=INFO hsail.test.StringContainsAcceptTest

The logLevel=INFO dumps the generated HSAIL to stdout.  When run on my system, the problem
code starts at @L10.  We are reading the first char from each of the strings and
getting ready to compare them.

@L10:
	ld_global_u16 $s9, [$d0 + 24];
	ld_global_u16 $s10, [$d3 + 24];
	st_spill_s32 $s10, [%spillseg][24];
	mov_b32 $s9, 0;                          <<< problem       
	cmp_ne_b1_s32 $c0, $s9, $s10;


-- Tom Deneau



-----Original Message-----
From: Deneau, Tom 
Sent: Monday, July 15, 2013 4:05 PM
To: graal-dev at openjdk.java.net
Subject: RE: graal/graal: 107 new changesets

Doug or others --

I was about to ask for help on a codegen problem we were seeing but after updating to the latest default,
I see that it is gone (so I'm assuming it was not in our backend :) ).  Of course it is possible that the bug
is just being hidden by some unrelated change.   Anyway, here is a brief description,
maybe you can tell which of the many changesets below would have fixed this, if any.

We were using String.contains as our test case, which was being nicely inlined, and we generated the following 
HSAIL code which led to the problem

	ld_global_u16 $s8, [$d3 + 24];         // read a u16 char from the test String
	ld_global_u16 $s9, [$d1 + 24];         // read a u16 char from the pattern  
	st_spill_s32 $s9, [%spillseg][24];     // register spill
	mov_b32 $s8, 0;                        // <<<<--- This code was causing the problem 
	cmp_ne_b1_s32 $c0, $s8, $s9;           // compare the two chars but s8 has been clobbered


When I did a -G:TraceLIRGeneratorLevel=2, I could see that the problematic instruction
 "mov_b32 $s8, 0"
was generated as part of something called
       MOVE TO PHI from 276|EndNode to 277|LoopBegin

as part of PhiResolver.dispose, the part that is commented with
  // generate move for move from non variable to arbitrary destination

Does the above sound like something that was purposely fixed?

-- Tom Deneau




From s1255495 at sms.ed.ac.uk  Thu Jul 18 05:24:41 2013
From: s1255495 at sms.ed.ac.uk (SINGH Ranjeet)
Date: Thu, 18 Jul 2013 12:24:41 +0000
Subject: PhiNodes
Message-ID: <eadd8f5e86fe445582889c1f1b4cea03@DBXPR05MB030.eurprd05.prod.outlook.com>

Hi,

I'm trying to generate a high level programming language from the StructuredGraph of a method, I was wondering is there anyway way to eliminate the PhiNodes in a StructuredGraph so it goes back to non SSA form?

Thanks.
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: not available
Url: http://mail.openjdk.java.net/pipermail/graal-dev/attachments/20130718/b04d0f7d/attachment.ksh 

From doug.simon at oracle.com  Fri Jul 19 03:55:10 2013
From: doug.simon at oracle.com (Doug Simon)
Date: Fri, 19 Jul 2013 12:55:10 +0200
Subject: HSAIL Backend: Register getting overwritten as part of Move To Phi
In-Reply-To: <BC97738F8E7C8742BABED7F06FB9DF91469EFDC7@sausexdag01.amd.com>
References: <20130715170157.A77A4480BF@hg.openjdk.java.net>
	<BC97738F8E7C8742BABED7F06FB9DF91469EFDC7@sausexdag01.amd.com>
Message-ID: <1BA5F3BC-9486-440D-AB3A-E93B81478458@oracle.com>

Tom,

I found the bug and am pushing through a fix now.

The issue was that, until now, we've only had backends whose conditional branch instructions operate on a conditional flag set by a preceding (compare) instruction. As such, we never considered (input) operands when moving instructions from successors to in front of a conditional branch. This assumption does not apply to HSAIL (or to PTX?). I've made a change that disables the optimization for conditional branches that have operands.

-Doug

On Jul 17, 2013, at 7:27 PM, "Deneau, Tom" <tom.deneau at amd.com> wrote:

> The problem described below was first noticed last week but then I thought
> it went away with the large number of checkins on July 15.  But now I see
> that it is still there.
> 
> I am not sure how to debug this problem so looking for any suggestions.
> To help you reproduce the problem on your side, I have a small webrev that
> adds the failing test case.   The test case itself uses String.contains and so
> needed the capability to properly handle accesses to char arrays and char fields,
> so in addition to the failing test case there is a very small change to the HSAIL
> backend to support the narrower object types like char.
> 
> The webrev can be found at
> http://cr.openjdk.java.net/~tdeneau/graal-webrevs/graal-webrev4.0/
> 
> One other change in this webrev, I made a change to the okra library loading code
> originally suggested by Doug.  Doug was suggesting a new environment variable pointing
> to the native library so we wouldn't need the -Dsun.boot.library.path on the java command
> line.  Instead I noticed that we were already requiring the directory to be in the PATH
> environment variable, so the loading code just looks down the PATH.
> 
> In the webrev, this change is simply reflected in a change to the version
> of the okra jar file (since the okra code is not part of graal proper).
> The change is entirely in the java code, there is no need
> to rebuild the actual native libraries.
> 
> Reproducing the failing test case...
> 
> With the patch applied, you should be able to get the test case failure with the following:
> 
>   * mx --vm server build product
>   * mx --vm server unittest @-G:InlineEverything @-Dkerneltester.logLevel=INFO hsail.test.StringContainsAcceptTest
> 
> The logLevel=INFO dumps the generated HSAIL to stdout.  When run on my system, the problem
> code starts at @L10.  We are reading the first char from each of the strings and
> getting ready to compare them.
> 
> @L10:
> 	ld_global_u16 $s9, [$d0 + 24];
> 	ld_global_u16 $s10, [$d3 + 24];
> 	st_spill_s32 $s10, [%spillseg][24];
> 	mov_b32 $s9, 0;                          <<< problem       
> 	cmp_ne_b1_s32 $c0, $s9, $s10;
> 
> 
> -- Tom Deneau
> 
> 
> 
> -----Original Message-----
> From: Deneau, Tom 
> Sent: Monday, July 15, 2013 4:05 PM
> To: graal-dev at openjdk.java.net
> Subject: RE: graal/graal: 107 new changesets
> 
> Doug or others --
> 
> I was about to ask for help on a codegen problem we were seeing but after updating to the latest default,
> I see that it is gone (so I'm assuming it was not in our backend :) ).  Of course it is possible that the bug
> is just being hidden by some unrelated change.   Anyway, here is a brief description,
> maybe you can tell which of the many changesets below would have fixed this, if any.
> 
> We were using String.contains as our test case, which was being nicely inlined, and we generated the following 
> HSAIL code which led to the problem
> 
> 	ld_global_u16 $s8, [$d3 + 24];         // read a u16 char from the test String
> 	ld_global_u16 $s9, [$d1 + 24];         // read a u16 char from the pattern  
> 	st_spill_s32 $s9, [%spillseg][24];     // register spill
> 	mov_b32 $s8, 0;                        // <<<<--- This code was causing the problem 
> 	cmp_ne_b1_s32 $c0, $s8, $s9;           // compare the two chars but s8 has been clobbered
> 
> 
> When I did a -G:TraceLIRGeneratorLevel=2, I could see that the problematic instruction
> "mov_b32 $s8, 0"
> was generated as part of something called
>       MOVE TO PHI from 276|EndNode to 277|LoopBegin
> 
> as part of PhiResolver.dispose, the part that is commented with
>  // generate move for move from non variable to arbitrary destination
> 
> Does the above sound like something that was purposely fixed?
> 
> -- Tom Deneau
> 
> 
> 


From doug.simon at oracle.com  Fri Jul 19 04:28:03 2013
From: doug.simon at oracle.com (doug.simon at oracle.com)
Date: Fri, 19 Jul 2013 11:28:03 +0000
Subject: hg: graal/graal: 47 new changesets
Message-ID: <20130719113056.7FEB148213@hg.openjdk.java.net>

Changeset: 4e6d6122c558
Author:    twisti
Date:      2013-07-11 10:31 -0700
URL:       http://hg.openjdk.java.net/graal/graal/rev/4e6d6122c558

solaris-fastdebug build fixes.

! src/share/vm/graal/graalCompiler.cpp
! src/share/vm/graal/graalRuntime.hpp
! src/share/vm/graal/graalVMToCompiler.cpp

Changeset: ec8ee1c2ad7a
Author:    twisti
Date:      2013-07-12 10:10 -0700
URL:       http://hg.openjdk.java.net/graal/graal/rev/ec8ee1c2ad7a

Move non_oop_bits value up to Graal.

! 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/src/com/oracle/graal/hotspot/HotSpotVMConfig.java
! src/share/vm/graal/graalCodeInstaller.cpp
! src/share/vm/graal/graalCompilerToVM.cpp

Changeset: dfc4b73e79e8
Author:    twisti
Date:      2013-07-12 10:12 -0700
URL:       http://hg.openjdk.java.net/graal/graal/rev/dfc4b73e79e8

Merge

! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/HotSpotVMConfig.java
! src/share/vm/graal/graalCompilerToVM.cpp

Changeset: fbeda94727f8
Author:    twisti
Date:      2013-07-15 17:58 -0700
URL:       http://hg.openjdk.java.net/graal/graal/rev/fbeda94727f8

Merge


Changeset: 0f8d0c86611d
Author:    Christos Kotselidis <christos.kotselidis at oracle.com>
Date:      2013-07-16 14:10 +0200
URL:       http://hg.openjdk.java.net/graal/graal/rev/0f8d0c86611d

Augment WriteBarrierVerification phase to account for ArrayRange barriers

! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/phases/WriteBarrierVerificationPhase.java

Changeset: 0a8f1eefce51
Author:    Christos Kotselidis <christos.kotselidis at oracle.com>
Date:      2013-07-16 14:10 +0200
URL:       http://hg.openjdk.java.net/graal/graal/rev/0a8f1eefce51

Augment WriteBarrierVerificationTest with arrayCopy test case

! graal/com.oracle.graal.hotspot.test/src/com/oracle/graal/hotspot/test/WriteBarrierVerificationTest.java

Changeset: f587a69c63ae
Author:    Christos Kotselidis <christos.kotselidis at oracle.com>
Date:      2013-07-16 14:16 +0200
URL:       http://hg.openjdk.java.net/graal/graal/rev/f587a69c63ae

Minor refactoring

! graal/com.oracle.graal.hotspot.test/src/com/oracle/graal/hotspot/test/WriteBarrierVerificationTest.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/WriteBarrierVerificationPhase.java

Changeset: a8152db58394
Author:    Christos Kotselidis <christos.kotselidis at oracle.com>
Date:      2013-07-16 14:17 +0200
URL:       http://hg.openjdk.java.net/graal/graal/rev/a8152db58394

Fix typo

! graal/com.oracle.graal.lir.amd64/src/com/oracle/graal/lir/amd64/AMD64Move.java

Changeset: f0fdbb2b7135
Author:    Lukas Stadler <lukas.stadler at jku.at>
Date:      2013-07-16 15:07 +0200
URL:       http://hg.openjdk.java.net/graal/graal/rev/f0fdbb2b7135

fix IfNode simplification that tries to remove a previously deleted LoopExitNode

! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/IfNode.java

Changeset: c0ce8e825f30
Author:    Lukas Stadler <lukas.stadler at jku.at>
Date:      2013-07-16 15:08 +0200
URL:       http://hg.openjdk.java.net/graal/graal/rev/c0ce8e825f30

Merge


Changeset: b1f438bf1a40
Author:    Lukas Stadler <lukas.stadler at jku.at>
Date:      2013-07-16 15:08 +0200
URL:       http://hg.openjdk.java.net/graal/graal/rev/b1f438bf1a40

Merge


Changeset: c53544484645
Author:    Lukas Stadler <lukas.stadler at jku.at>
Date:      2013-07-16 16:23 +0200
URL:       http://hg.openjdk.java.net/graal/graal/rev/c53544484645

process FixedGuardNodes in ConditionalEliminationPhase

! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/ConditionalEliminationPhase.java

Changeset: 8a46f9081ea3
Author:    Lukas Stadler <lukas.stadler at jku.at>
Date:      2013-07-16 16:24 +0200
URL:       http://hg.openjdk.java.net/graal/graal/rev/8a46f9081ea3

rename ReadEliminationPE... to PEReadElimination...

+ graal/com.oracle.graal.virtual/src/com/oracle/graal/virtual/phases/ea/PEReadEliminationBlockState.java
+ graal/com.oracle.graal.virtual/src/com/oracle/graal/virtual/phases/ea/PEReadEliminationClosure.java
! graal/com.oracle.graal.virtual/src/com/oracle/graal/virtual/phases/ea/PartialEscapePhase.java
- graal/com.oracle.graal.virtual/src/com/oracle/graal/virtual/phases/ea/ReadEliminationPEBlockState.java
- graal/com.oracle.graal.virtual/src/com/oracle/graal/virtual/phases/ea/ReadEliminationPEClosure.java

Changeset: 2151364f2076
Author:    Lukas Stadler <lukas.stadler at jku.at>
Date:      2013-07-16 16:44 +0200
URL:       http://hg.openjdk.java.net/graal/graal/rev/2151364f2076

add EarlyReadEliminationPhase, including tests

+ graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/ea/EarlyReadEliminationTest.java
! graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/ea/PEAReadEliminationTest.java
+ graal/com.oracle.graal.virtual/src/com/oracle/graal/virtual/phases/ea/EarlyReadEliminationPhase.java
+ graal/com.oracle.graal.virtual/src/com/oracle/graal/virtual/phases/ea/ReadEliminationBlockState.java
+ graal/com.oracle.graal.virtual/src/com/oracle/graal/virtual/phases/ea/ReadEliminationClosure.java

Changeset: 0a306985c262
Author:    Lukas Stadler <lukas.stadler at jku.at>
Date:      2013-07-16 16:46 +0200
URL:       http://hg.openjdk.java.net/graal/graal/rev/0a306985c262

force substitution of Object.clone

! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/ObjectSubstitutions.java

Changeset: debb9d8e0282
Author:    Doug Simon <doug.simon at oracle.com>
Date:      2013-07-16 16:36 +0200
URL:       http://hg.openjdk.java.net/graal/graal/rev/debb9d8e0282

allow double fields in value number computation and thus, in floating nodes

! graal/com.oracle.graal.graph/src/com/oracle/graal/graph/NodeClass.java

Changeset: 745322b36359
Author:    Doug Simon <doug.simon at oracle.com>
Date:      2013-07-16 17:29 +0200
URL:       http://hg.openjdk.java.net/graal/graal/rev/745322b36359

added a field to LogicBinaryNode capturing the probability that the evaluation of the logic node is short-circuited (i.e. only the left input is evaluated)

! graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/ConditionalEliminationTest.java
! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/LogicBinaryNode.java
! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/LogicConjunctionNode.java
! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/LogicDisjunctionNode.java
! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/java/CheckCastNode.java
! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/ExpandLogicPhase.java

Changeset: 388fbd0dd4a4
Author:    Doug Simon <doug.simon at oracle.com>
Date:      2013-07-16 17:56 +0200
URL:       http://hg.openjdk.java.net/graal/graal/rev/388fbd0dd4a4

moved BranchNodeProbabilities to graal.nodes project

! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/ArrayCopySnippets.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/HotSpotReplacementsUtil.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/MonitorSnippets.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/ObjectCloneSnippets.java
! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/SystemSubstitutions.java
! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/TypeCheckSnippetUtils.java
! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/UnsafeArrayCopySnippets.java
! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/WriteBarrierSnippets.java
+ graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/extended/BranchProbabilityNode.java
! graal/com.oracle.graal.replacements.amd64/src/com/oracle/graal/replacements/amd64/AMD64ConvertSnippets.java
- graal/com.oracle.graal.replacements/src/com/oracle/graal/replacements/nodes/BranchProbabilityNode.java
! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/substitutions/CompilerDirectivesSubstitutions.java

Changeset: ac3cb56f47a0
Author:    Doug Simon <doug.simon at oracle.com>
Date:      2013-07-16 18:08 +0200
URL:       http://hg.openjdk.java.net/graal/graal/rev/ac3cb56f47a0

made use of symbolic constants for branch probabilities

! graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/ConditionalEliminationTest.java
! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/java/CheckCastNode.java

Changeset: ec4c7c33e8e5
Author:    Doug Simon <doug.simon at oracle.com>
Date:      2013-07-16 18:13 +0200
URL:       http://hg.openjdk.java.net/graal/graal/rev/ec4c7c33e8e5

rename: LogicBinaryNode -> ShortCircuitBooleanNode, Logic[Conjunction|Disjunction]Node -> ShortCircuit[And|Or]Node

! graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/ConditionalEliminationTest.java
- graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/LogicBinaryNode.java
- graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/LogicConjunctionNode.java
- graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/LogicDisjunctionNode.java
+ graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/ShortCircuitAndNode.java
+ graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/ShortCircuitBooleanNode.java
+ graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/ShortCircuitOrNode.java
! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/java/CheckCastNode.java
! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/java/InstanceOfNode.java
! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/ConditionalEliminationPhase.java
! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/ExpandLogicPhase.java
! graal/com.oracle.graal.replacements/src/com/oracle/graal/replacements/InstanceOfSnippetsTemplates.java

Changeset: 6d176112d162
Author:    Doug Simon <doug.simon at oracle.com>
Date:      2013-07-16 18:13 +0200
URL:       http://hg.openjdk.java.net/graal/graal/rev/6d176112d162

Merge.

! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/ConditionalEliminationPhase.java

Changeset: e2786e2c491a
Author:    Doug Simon <doug.simon at oracle.com>
Date:      2013-07-16 18:30 +0200
URL:       http://hg.openjdk.java.net/graal/graal/rev/e2786e2c491a

Merge.

- graal/com.oracle.graal.virtual/src/com/oracle/graal/virtual/phases/ea/ReadEliminationPEBlockState.java
- graal/com.oracle.graal.virtual/src/com/oracle/graal/virtual/phases/ea/ReadEliminationPEClosure.java

Changeset: 7a8d6ba83a04
Author:    twisti
Date:      2013-07-16 17:41 -0700
URL:       http://hg.openjdk.java.net/graal/graal/rev/7a8d6ba83a04

SPARC: fixes and more stuff works

! graal/com.oracle.graal.asm.sparc/src/com/oracle/graal/asm/sparc/SPARCAssembler.java
! graal/com.oracle.graal.asm.sparc/src/com/oracle/graal/asm/sparc/SPARCMacroAssembler.java
! graal/com.oracle.graal.compiler.sparc/src/com/oracle/graal/compiler/sparc/SPARCLIRGenerator.java
! graal/com.oracle.graal.hotspot.sparc/src/com/oracle/graal/hotspot/sparc/SPARCHotSpotBackend.java
! graal/com.oracle.graal.hotspot.sparc/src/com/oracle/graal/hotspot/sparc/SPARCHotSpotGraalRuntime.java
! graal/com.oracle.graal.hotspot.sparc/src/com/oracle/graal/hotspot/sparc/SPARCHotSpotLIRGenerator.java
! graal/com.oracle.graal.hotspot.sparc/src/com/oracle/graal/hotspot/sparc/SPARCHotSpotRegisterConfig.java
! graal/com.oracle.graal.hotspot.sparc/src/com/oracle/graal/hotspot/sparc/SPARCHotspotDirectStaticCallOp.java
+ graal/com.oracle.graal.hotspot.sparc/src/com/oracle/graal/hotspot/sparc/SPARCHotspotDirectVirtualCallOp.java
! graal/com.oracle.graal.hotspot.sparc/src/com/oracle/graal/hotspot/sparc/SPARCSafepointOp.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
! graal/com.oracle.graal.lir/src/com/oracle/graal/lir/asm/TargetMethodAssembler.java
! src/cpu/sparc/vm/graalCodeInstaller_sparc.hpp

Changeset: 6e12e0ace0d5
Author:    Andreas Woess <andreas.woess at jku.at>
Date:      2013-07-17 13:53 +0200
URL:       http://hg.openjdk.java.net/graal/graal/rev/6e12e0ace0d5

Truffle: add NodeUtil.countNodes overload that counts nodes of a specific type

! graal/com.oracle.truffle.api/src/com/oracle/truffle/api/nodes/NodeUtil.java

Changeset: 3fe325c3f31c
Author:    Andreas Woess <andreas.woess at jku.at>
Date:      2013-07-17 14:14 +0200
URL:       http://hg.openjdk.java.net/graal/graal/rev/3fe325c3f31c

Truffle: add InlinedCallSite interface and an InlinableCallSite method to query the inlined call target

! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/OptimizedCallTarget.java
! graal/com.oracle.truffle.api/src/com/oracle/truffle/api/impl/DefaultCallTarget.java
! graal/com.oracle.truffle.api/src/com/oracle/truffle/api/nodes/InlinableCallSite.java
+ graal/com.oracle.truffle.api/src/com/oracle/truffle/api/nodes/InlinedCallSite.java

Changeset: 6ac4cac7431f
Author:    Andreas Woess <andreas.woess at jku.at>
Date:      2013-07-17 14:52 +0200
URL:       http://hg.openjdk.java.net/graal/graal/rev/6ac4cac7431f

Truffle: detect inlined recursive calls and introduce depth limit

! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/OptimizedCallTarget.java
! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/TruffleCompilerOptions.java

Changeset: b84bb0de0092
Author:    Andreas Woess <andreas.woess at jku.at>
Date:      2013-07-17 16:05 +0200
URL:       http://hg.openjdk.java.net/graal/graal/rev/b84bb0de0092

Truffle: increase inlining maximum caller size

! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/TruffleCompilerOptions.java

Changeset: bb3cfaa7897c
Author:    Andreas Woess <andreas.woess at jku.at>
Date:      2013-07-17 18:02 +0200
URL:       http://hg.openjdk.java.net/graal/graal/rev/bb3cfaa7897c

Truffle: try out a new inlining policy

! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/OptimizedCallTarget.java
! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/TruffleCompilerOptions.java

Changeset: 7d3e74190a09
Author:    Christos Kotselidis <christos.kotselidis at oracle.com>
Date:      2013-07-17 19:30 +0200
URL:       http://hg.openjdk.java.net/graal/graal/rev/7d3e74190a09

Code refactoring and cleanup

! graal/com.oracle.graal.hotspot.test/src/com/oracle/graal/hotspot/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/replacements/HotSpotReplacementsUtil.java

Changeset: a84634196540
Author:    Christos Kotselidis <christos.kotselidis at oracle.com>
Date:      2013-07-17 19:31 +0200
URL:       http://hg.openjdk.java.net/graal/graal/rev/a84634196540

Remove unused node intrinsic

! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/extended/ReadNode.java

Changeset: 69e305a5cf09
Author:    Christos Kotselidis <christos.kotselidis at oracle.com>
Date:      2013-07-17 19:52 +0200
URL:       http://hg.openjdk.java.net/graal/graal/rev/69e305a5cf09

Introduce new read opcode that allows compressed oops and read barriers

! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/WriteBarrierSnippets.java
! 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: 4bfbd4be6e7a
Author:    Christos Kotselidis <christos.kotselidis at oracle.com>
Date:      2013-07-17 20:23 +0200
URL:       http://hg.openjdk.java.net/graal/graal/rev/4bfbd4be6e7a

Replace custom graph building with snippet for unsafe load lowering

! graal/com.oracle.graal.hotspot.test/src/com/oracle/graal/hotspot/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/replacements/UnsafeLoadSnippets.java

Changeset: e6bb7edcc66c
Author:    Lukas Stadler <lukas.stadler at jku.at>
Date:      2013-07-18 12:01 +0200
URL:       http://hg.openjdk.java.net/graal/graal/rev/e6bb7edcc66c

fix for ConditionalEliminationPhase.addNullness

! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/ConditionalEliminationPhase.java

Changeset: 4532725151cc
Author:    Lukas Stadler <lukas.stadler at jku.at>
Date:      2013-07-18 12:04 +0200
URL:       http://hg.openjdk.java.net/graal/graal/rev/4532725151cc

make MergeableState an abstract class instead of an interface

! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/ConditionalEliminationPhase.java
! graal/com.oracle.graal.phases/src/com/oracle/graal/phases/graph/ComputeProbabilityClosure.java
! graal/com.oracle.graal.phases/src/com/oracle/graal/phases/graph/MergeableState.java

Changeset: 32d93a799694
Author:    Lukas Stadler <lukas.stadler at jku.at>
Date:      2013-07-18 12:59 +0200
URL:       http://hg.openjdk.java.net/graal/graal/rev/32d93a799694

remove obsolete code from ValueAnchorNode

! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/extended/ValueAnchorNode.java

Changeset: 842166781ddb
Author:    Lukas Stadler <lukas.stadler at jku.at>
Date:      2013-07-18 13:15 +0200
URL:       http://hg.openjdk.java.net/graal/graal/rev/842166781ddb

always perform canonicalization at the beginning of MidTier

! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/phases/MidTier.java

Changeset: f272fe8a2f9a
Author:    Lukas Stadler <lukas.stadler at jku.at>
Date:      2013-07-18 13:16 +0200
URL:       http://hg.openjdk.java.net/graal/graal/rev/f272fe8a2f9a

move LockElimination to MidTier

! 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

Changeset: d3a677910eea
Author:    Lukas Stadler <lukas.stadler at jku.at>
Date:      2013-07-18 13:17 +0200
URL:       http://hg.openjdk.java.net/graal/graal/rev/d3a677910eea

new ValueAnchorCleanupPhase to make lock elimination work again, tests for lock elimination

+ graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/LockEliminationTest.java
! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/phases/MidTier.java
! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/extended/ValueAnchorNode.java
+ graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/ValueAnchorCleanupPhase.java

Changeset: 4278ab23c66f
Author:    Lukas Stadler <lukas.stadler at jku.at>
Date:      2013-07-18 14:34 +0200
URL:       http://hg.openjdk.java.net/graal/graal/rev/4278ab23c66f

new Option PrintGraphProbabilities to output probabilities during binary graph dumping

! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/util/NodesToDoubles.java
! graal/com.oracle.graal.phases/src/com/oracle/graal/phases/GraalOptions.java
! graal/com.oracle.graal.printer/src/com/oracle/graal/printer/BinaryGraphPrinter.java

Changeset: 438dd12ff25b
Author:    Lukas Stadler <lukas.stadler at jku.at>
Date:      2013-07-18 14:35 +0200
URL:       http://hg.openjdk.java.net/graal/graal/rev/438dd12ff25b

reset "permanent" flag on ValueAnchorNodes during inlining

! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/extended/ValueAnchorNode.java
! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/InliningUtil.java

Changeset: 4e1db4c9d4c5
Author:    Roland Schatz <roland.schatz at oracle.com>
Date:      2013-07-18 15:37 +0200
URL:       http://hg.openjdk.java.net/graal/graal/rev/4e1db4c9d4c5

Support data patches for values larger than long.

! graal/com.oracle.graal.api.code/src/com/oracle/graal/api/code/CompilationResult.java
! graal/com.oracle.graal.lir/src/com/oracle/graal/lir/asm/TargetMethodAssembler.java
! src/cpu/x86/vm/graalCodeInstaller_x86.hpp
! src/share/vm/graal/graalCodeInstaller.cpp
! src/share/vm/graal/graalJavaAccess.hpp

Changeset: 5fced75a7f57
Author:    Roland Schatz <roland.schatz at oracle.com>
Date:      2013-07-18 15:37 +0200
URL:       http://hg.openjdk.java.net/graal/graal/rev/5fced75a7f57

Unit test for raw data patch.

! graal/com.oracle.graal.asm.amd64.test/src/com/oracle/graal/asm/amd64/test/SimpleAssemblerTest.java

Changeset: dd95ee93c893
Author:    Lukas Stadler <lukas.stadler at jku.at>
Date:      2013-07-18 17:15 +0200
URL:       http://hg.openjdk.java.net/graal/graal/rev/dd95ee93c893

output only blocks with changes in EffectClosure tracing

! graal/com.oracle.graal.virtual/src/com/oracle/graal/virtual/phases/ea/EffectsClosure.java

Changeset: 3d6bd17da6e1
Author:    Lukas Stadler <lukas.stadler at jku.at>
Date:      2013-07-18 17:16 +0200
URL:       http://hg.openjdk.java.net/graal/graal/rev/3d6bd17da6e1

fix problem in PEReadEliminationClosure (could lead to unschedulable graph)

! graal/com.oracle.graal.virtual/src/com/oracle/graal/virtual/phases/ea/PEReadEliminationClosure.java

Changeset: 8b0c8fbbfa1c
Author:    Lukas Stadler <lukas.stadler at jku.at>
Date:      2013-07-18 17:18 +0200
URL:       http://hg.openjdk.java.net/graal/graal/rev/8b0c8fbbfa1c

make early read elimination work on read/write nodes (in addition to load/store)

! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/phases/MidTier.java
! graal/com.oracle.graal.virtual/src/com/oracle/graal/virtual/phases/ea/ReadEliminationBlockState.java
! graal/com.oracle.graal.virtual/src/com/oracle/graal/virtual/phases/ea/ReadEliminationClosure.java

Changeset: 825d37fcdc9e
Author:    Christian Wimmer <christian.wimmer at oracle.com>
Date:      2013-07-18 13:31 -0700
URL:       http://hg.openjdk.java.net/graal/graal/rev/825d37fcdc9e

Bugfix of stamp mask computation

! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/type/StampTool.java

Changeset: a61fa3e171e7
Author:    Doug Simon <doug.simon at oracle.com>
Date:      2013-07-19 12:45 +0200
URL:       http://hg.openjdk.java.net/graal/graal/rev/a61fa3e171e7

fixed bug in EdgeMoveOptimizer triggered by a backend (such as HSAIL) that has conditional branches with explicit input operands (as opposed to an implicit condition flags register)

! graal/com.oracle.graal.lir/src/com/oracle/graal/lir/EdgeMoveOptimizer.java


From doug.simon at oracle.com  Fri Jul 19 06:32:17 2013
From: doug.simon at oracle.com (Doug Simon)
Date: Fri, 19 Jul 2013 15:32:17 +0200
Subject: PhiNodes
In-Reply-To: <eadd8f5e86fe445582889c1f1b4cea03@DBXPR05MB030.eurprd05.prod.outlook.com>
References: <eadd8f5e86fe445582889c1f1b4cea03@DBXPR05MB030.eurprd05.prod.outlook.com>
Message-ID: <D4AD9986-0440-43A7-B4C7-D50E78EBF609@oracle.com>


On Jul 18, 2013, at 2:24 PM, SINGH Ranjeet <s1255495 at sms.ed.ac.uk> wrote:

> Hi,
> 
> I'm trying to generate a high level programming language from the StructuredGraph of a method, I was wondering is there anyway way to eliminate the PhiNodes in a StructuredGraph so it goes back to non SSA form?

No, not without moving to LIR (which is something you could consider).

-Doug

From tom.deneau at amd.com  Fri Jul 19 13:09:21 2013
From: tom.deneau at amd.com (Deneau, Tom)
Date: Fri, 19 Jul 2013 20:09:21 +0000
Subject: HSAIL Backend: Register getting overwritten as part of Move To Phi
In-Reply-To: <1BA5F3BC-9486-440D-AB3A-E93B81478458@oracle.com>
References: <20130715170157.A77A4480BF@hg.openjdk.java.net>
	<BC97738F8E7C8742BABED7F06FB9DF91469EFDC7@sausexdag01.amd.com>
	<1BA5F3BC-9486-440D-AB3A-E93B81478458@oracle.com>
Message-ID: <BC97738F8E7C8742BABED7F06FB9DF91469F3CDA@sausexdag01.amd.com>

Doug --

So I assume this is the following changeset which has already been pushed?

-- Tom

Changeset: a61fa3e171e7
Author:    Doug Simon <doug.simon at oracle.com>
Date:      2013-07-19 12:45 +0200
URL:       http://hg.openjdk.java.net/graal/graal/rev/a61fa3e171e7

fixed bug in EdgeMoveOptimizer triggered by a backend (such as HSAIL) that has conditional branches with explicit input operands (as opposed to an implicit condition flags register)

! graal/com.oracle.graal.lir/src/com/oracle/graal/lir/EdgeMoveOptimizer.java



-----Original Message-----
From: Doug Simon [mailto:doug.simon at oracle.com] 
Sent: Friday, July 19, 2013 5:55 AM
To: Deneau, Tom
Cc: graal-dev at openjdk.java.net
Subject: Re: HSAIL Backend: Register getting overwritten as part of Move To Phi

Tom,

I found the bug and am pushing through a fix now.

The issue was that, until now, we've only had backends whose conditional branch instructions operate on a conditional flag set by a preceding (compare) instruction. As such, we never considered (input) operands when moving instructions from successors to in front of a conditional branch. This assumption does not apply to HSAIL (or to PTX?). I've made a change that disables the optimization for conditional branches that have operands.

-Doug

On Jul 17, 2013, at 7:27 PM, "Deneau, Tom" <tom.deneau at amd.com> wrote:

> The problem described below was first noticed last week but then I thought
> it went away with the large number of checkins on July 15.  But now I see
> that it is still there.
> 
> I am not sure how to debug this problem so looking for any suggestions.
> To help you reproduce the problem on your side, I have a small webrev that
> adds the failing test case.   The test case itself uses String.contains and so
> needed the capability to properly handle accesses to char arrays and char fields,
> so in addition to the failing test case there is a very small change to the HSAIL
> backend to support the narrower object types like char.
> 
> The webrev can be found at
> http://cr.openjdk.java.net/~tdeneau/graal-webrevs/graal-webrev4.0/
> 
> One other change in this webrev, I made a change to the okra library loading code
> originally suggested by Doug.  Doug was suggesting a new environment variable pointing
> to the native library so we wouldn't need the -Dsun.boot.library.path on the java command
> line.  Instead I noticed that we were already requiring the directory to be in the PATH
> environment variable, so the loading code just looks down the PATH.
> 
> In the webrev, this change is simply reflected in a change to the version
> of the okra jar file (since the okra code is not part of graal proper).
> The change is entirely in the java code, there is no need
> to rebuild the actual native libraries.
> 
> Reproducing the failing test case...
> 
> With the patch applied, you should be able to get the test case failure with the following:
> 
>   * mx --vm server build product
>   * mx --vm server unittest @-G:InlineEverything @-Dkerneltester.logLevel=INFO hsail.test.StringContainsAcceptTest
> 
> The logLevel=INFO dumps the generated HSAIL to stdout.  When run on my system, the problem
> code starts at @L10.  We are reading the first char from each of the strings and
> getting ready to compare them.
> 
> @L10:
> 	ld_global_u16 $s9, [$d0 + 24];
> 	ld_global_u16 $s10, [$d3 + 24];
> 	st_spill_s32 $s10, [%spillseg][24];
> 	mov_b32 $s9, 0;                          <<< problem       
> 	cmp_ne_b1_s32 $c0, $s9, $s10;
> 
> 
> -- Tom Deneau
> 
> 
> 
> -----Original Message-----
> From: Deneau, Tom 
> Sent: Monday, July 15, 2013 4:05 PM
> To: graal-dev at openjdk.java.net
> Subject: RE: graal/graal: 107 new changesets
> 
> Doug or others --
> 
> I was about to ask for help on a codegen problem we were seeing but after updating to the latest default,
> I see that it is gone (so I'm assuming it was not in our backend :) ).  Of course it is possible that the bug
> is just being hidden by some unrelated change.   Anyway, here is a brief description,
> maybe you can tell which of the many changesets below would have fixed this, if any.
> 
> We were using String.contains as our test case, which was being nicely inlined, and we generated the following 
> HSAIL code which led to the problem
> 
> 	ld_global_u16 $s8, [$d3 + 24];         // read a u16 char from the test String
> 	ld_global_u16 $s9, [$d1 + 24];         // read a u16 char from the pattern  
> 	st_spill_s32 $s9, [%spillseg][24];     // register spill
> 	mov_b32 $s8, 0;                        // <<<<--- This code was causing the problem 
> 	cmp_ne_b1_s32 $c0, $s8, $s9;           // compare the two chars but s8 has been clobbered
> 
> 
> When I did a -G:TraceLIRGeneratorLevel=2, I could see that the problematic instruction
> "mov_b32 $s8, 0"
> was generated as part of something called
>       MOVE TO PHI from 276|EndNode to 277|LoopBegin
> 
> as part of PhiResolver.dispose, the part that is commented with
>  // generate move for move from non variable to arbitrary destination
> 
> Does the above sound like something that was purposely fixed?
> 
> -- Tom Deneau
> 
> 
> 




From doug.simon at oracle.com  Fri Jul 19 14:18:00 2013
From: doug.simon at oracle.com (Doug Simon)
Date: Fri, 19 Jul 2013 23:18:00 +0200
Subject: HSAIL Backend: Register getting overwritten as part of Move To Phi
In-Reply-To: <BC97738F8E7C8742BABED7F06FB9DF91469F3CDA@sausexdag01.amd.com>
References: <20130715170157.A77A4480BF@hg.openjdk.java.net>
	<BC97738F8E7C8742BABED7F06FB9DF91469EFDC7@sausexdag01.amd.com>
	<1BA5F3BC-9486-440D-AB3A-E93B81478458@oracle.com>
	<BC97738F8E7C8742BABED7F06FB9DF91469F3CDA@sausexdag01.amd.com>
Message-ID: <EDD96BF3-358B-4269-BB7D-0C482B543F3F@oracle.com>

Yep.

Sent from my iPhone

On Jul 19, 2013, at 10:09 PM, "Deneau, Tom" <tom.deneau at amd.com> wrote:

> Doug --
> 
> So I assume this is the following changeset which has already been pushed?
> 
> -- Tom
> 
> Changeset: a61fa3e171e7
> Author:    Doug Simon <doug.simon at oracle.com>
> Date:      2013-07-19 12:45 +0200
> URL:       http://hg.openjdk.java.net/graal/graal/rev/a61fa3e171e7
> 
> fixed bug in EdgeMoveOptimizer triggered by a backend (such as HSAIL) that has conditional branches with explicit input operands (as opposed to an implicit condition flags register)
> 
> ! graal/com.oracle.graal.lir/src/com/oracle/graal/lir/EdgeMoveOptimizer.java
> 
> 
> 
> -----Original Message-----
> From: Doug Simon [mailto:doug.simon at oracle.com] 
> Sent: Friday, July 19, 2013 5:55 AM
> To: Deneau, Tom
> Cc: graal-dev at openjdk.java.net
> Subject: Re: HSAIL Backend: Register getting overwritten as part of Move To Phi
> 
> Tom,
> 
> I found the bug and am pushing through a fix now.
> 
> The issue was that, until now, we've only had backends whose conditional branch instructions operate on a conditional flag set by a preceding (compare) instruction. As such, we never considered (input) operands when moving instructions from successors to in front of a conditional branch. This assumption does not apply to HSAIL (or to PTX?). I've made a change that disables the optimization for conditional branches that have operands.
> 
> -Doug
> 
> On Jul 17, 2013, at 7:27 PM, "Deneau, Tom" <tom.deneau at amd.com> wrote:
> 
>> The problem described below was first noticed last week but then I thought
>> it went away with the large number of checkins on July 15.  But now I see
>> that it is still there.
>> 
>> I am not sure how to debug this problem so looking for any suggestions.
>> To help you reproduce the problem on your side, I have a small webrev that
>> adds the failing test case.   The test case itself uses String.contains and so
>> needed the capability to properly handle accesses to char arrays and char fields,
>> so in addition to the failing test case there is a very small change to the HSAIL
>> backend to support the narrower object types like char.
>> 
>> The webrev can be found at
>> http://cr.openjdk.java.net/~tdeneau/graal-webrevs/graal-webrev4.0/
>> 
>> One other change in this webrev, I made a change to the okra library loading code
>> originally suggested by Doug.  Doug was suggesting a new environment variable pointing
>> to the native library so we wouldn't need the -Dsun.boot.library.path on the java command
>> line.  Instead I noticed that we were already requiring the directory to be in the PATH
>> environment variable, so the loading code just looks down the PATH.
>> 
>> In the webrev, this change is simply reflected in a change to the version
>> of the okra jar file (since the okra code is not part of graal proper).
>> The change is entirely in the java code, there is no need
>> to rebuild the actual native libraries.
>> 
>> Reproducing the failing test case...
>> 
>> With the patch applied, you should be able to get the test case failure with the following:
>> 
>>  * mx --vm server build product
>>  * mx --vm server unittest @-G:InlineEverything @-Dkerneltester.logLevel=INFO hsail.test.StringContainsAcceptTest
>> 
>> The logLevel=INFO dumps the generated HSAIL to stdout.  When run on my system, the problem
>> code starts at @L10.  We are reading the first char from each of the strings and
>> getting ready to compare them.
>> 
>> @L10:
>>    ld_global_u16 $s9, [$d0 + 24];
>>    ld_global_u16 $s10, [$d3 + 24];
>>    st_spill_s32 $s10, [%spillseg][24];
>>    mov_b32 $s9, 0;                          <<< problem       
>>    cmp_ne_b1_s32 $c0, $s9, $s10;
>> 
>> 
>> -- Tom Deneau
>> 
>> 
>> 
>> -----Original Message-----
>> From: Deneau, Tom 
>> Sent: Monday, July 15, 2013 4:05 PM
>> To: graal-dev at openjdk.java.net
>> Subject: RE: graal/graal: 107 new changesets
>> 
>> Doug or others --
>> 
>> I was about to ask for help on a codegen problem we were seeing but after updating to the latest default,
>> I see that it is gone (so I'm assuming it was not in our backend :) ).  Of course it is possible that the bug
>> is just being hidden by some unrelated change.   Anyway, here is a brief description,
>> maybe you can tell which of the many changesets below would have fixed this, if any.
>> 
>> We were using String.contains as our test case, which was being nicely inlined, and we generated the following 
>> HSAIL code which led to the problem
>> 
>>    ld_global_u16 $s8, [$d3 + 24];         // read a u16 char from the test String
>>    ld_global_u16 $s9, [$d1 + 24];         // read a u16 char from the pattern  
>>    st_spill_s32 $s9, [%spillseg][24];     // register spill
>>    mov_b32 $s8, 0;                        // <<<<--- This code was causing the problem 
>>    cmp_ne_b1_s32 $c0, $s8, $s9;           // compare the two chars but s8 has been clobbered
>> 
>> 
>> When I did a -G:TraceLIRGeneratorLevel=2, I could see that the problematic instruction
>> "mov_b32 $s8, 0"
>> was generated as part of something called
>>      MOVE TO PHI from 276|EndNode to 277|LoopBegin
>> 
>> as part of PhiResolver.dispose, the part that is commented with
>> // generate move for move from non variable to arbitrary destination
>> 
>> Does the above sound like something that was purposely fixed?
>> 
>> -- Tom Deneau
> 
> 
> 

From michael.haupt at oracle.com  Fri Jul 19 15:42:22 2013
From: michael.haupt at oracle.com (Michael Haupt)
Date: Fri, 19 Jul 2013 15:42:22 -0700 (PDT)
Subject: Graal wiki: Truffle FAQ and Guidelines
Message-ID: <AC2545C2-C727-4C53-8519-8B6AB0D45361@oracle.com>

Dear all,

see https://wiki.openjdk.java.net/display/Graal/Truffle+FAQ+and+Guidelines - this is intended to grow, so please ask more questions. :-)

Best regards,

Michael Haupt

-- 


Dr. Michael Haupt | Principal Member of Technical Staff
Phone: +49 331 200 7277 | Fax: +49 331 200 7561
Oracle Labs 
Oracle Deutschland B.V. & Co. KG, Schiffbauergasse 14 | 14467 Potsdam, Germany
	Oracle is committed to developing practices and products that help protect the environment


From miguelalfredo.garcia at epfl.ch  Sat Jul 20 09:49:38 2013
From: miguelalfredo.garcia at epfl.ch (Garcia Gutierrez Miguel Alfredo)
Date: Sat, 20 Jul 2013 16:49:38 +0000
Subject: merge of types in ConditionalPhaseElimination
Message-ID: <7E4228B446372948BBB2916FC53FA49E26DDDDF5@rexma.intranet.epfl.ch>


Still figuring out the workings of ConditionalEliminationPhase, I have a question regarding

        public boolean merge(MergeNode merge, List<State> withStates) {

which merges among other things the "known (object) types" over all incoming states:

            for (Map.Entry<ValueNode, ResolvedJavaType> entry : knownTypes.entrySet()) {
                ValueNode node = entry.getKey();
                ResolvedJavaType type = entry.getValue();

                for (State other : withStates) {
                    ResolvedJavaType otherType = other.getNodeType(node);
                    type = widen(type, otherType);
                    if (type == null) {
                        break;
                    }
                }
------------>   if (type == null && type != node.objectStamp().type()) {
                    newKnownTypes.put(node, type);
                }
            }

My reading of the above is:
  (1) fold the meet-operation across all incoming states.
  (2) Two cases:
      (2.a) the accumulated type is null (ie, there's no common ancestor, for example because some of the incoming states lack entries in "knownTypes").
      (2.b) non-null, and moreover a type more precise than Object has been inferred. That's the merged type we want to track in the merged state.

Getting to the code, there appears to be a typo (the arrow marks the spot). I guess the intention is adding an entry for the "accumulated type" to "newKnownTypes" (case 2.b). If so, that line should read:

                if (type != null && type != node.objectStamp().type()) {



Miguel

--
Miguel Garcia
Swiss Federal Institute of Technology
EPFL - IC - LAMP1 - INR 328 - Station 14
CH-1015 Lausanne - Switzerland
http://lamp.epfl.ch/~magarcia/

From doug.simon at oracle.com  Sat Jul 20 18:00:09 2013
From: doug.simon at oracle.com (doug.simon at oracle.com)
Date: Sun, 21 Jul 2013 01:00:09 +0000
Subject: hg: graal/graal: 10 new changesets
Message-ID: <20130721010058.D3D6248246@hg.openjdk.java.net>

Changeset: 2c9332a969d6
Author:    Doug Simon <doug.simon at oracle.com>
Date:      2013-07-19 17:47 +0200
URL:       http://hg.openjdk.java.net/graal/graal/rev/2c9332a969d6

made it possible to use enum constants in snippets

! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/UnsafeLoadSnippets.java
! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/WriteBarrierSnippets.java
! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/java/LoadFieldNode.java
! 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: 0a5cfcf27c35
Author:    Mick Jordan <mick.jordan at oracle.com>
Date:      2013-07-19 09:13 -0700
URL:       http://hg.openjdk.java.net/graal/graal/rev/0a5cfcf27c35

add condition accessor to GuardingPiNode

! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/GuardingPiNode.java

Changeset: 02222bffbe43
Author:    Mick Jordan <mick.jordan at oracle.com>
Date:      2013-07-19 09:30 -0700
URL:       http://hg.openjdk.java.net/graal/graal/rev/02222bffbe43

Merge


Changeset: f8fe0f7ee22a
Author:    twisti
Date:      2013-07-19 12:01 -0700
URL:       http://hg.openjdk.java.net/graal/graal/rev/f8fe0f7ee22a

added createLabelName override in AbstractHSAILAssembler; create a common label name in AbstractAssembler

! graal/com.oracle.graal.asm.hsail/src/com/oracle/graal/asm/hsail/AbstractHSAILAssembler.java
! graal/com.oracle.graal.asm.hsail/src/com/oracle/graal/asm/hsail/HSAILAssembler.java
! graal/com.oracle.graal.asm/src/com/oracle/graal/asm/AbstractAssembler.java

Changeset: 0910c930c66e
Author:    Christos Kotselidis <christos.kotselidis at oracle.com>
Date:      2013-07-19 22:10 +0200
URL:       http://hg.openjdk.java.net/graal/graal/rev/0910c930c66e

Method and variables' renaming

! graal/com.oracle.graal.compiler.hsail/src/com/oracle/graal/compiler/hsail/HSAILLIRGenerator.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/meta/HotSpotRuntime.java
! graal/com.oracle.graal.lir.amd64/src/com/oracle/graal/lir/amd64/AMD64Move.java
! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/HeapAccess.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.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: 78a4df8953a1
Author:    Christos Kotselidis <christos.kotselidis at oracle.com>
Date:      2013-07-19 22:14 +0200
URL:       http://hg.openjdk.java.net/graal/graal/rev/78a4df8953a1

Javadoc fixes

! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/HeapAccess.java

Changeset: 2e852e96f977
Author:    Christos Kotselidis <christos.kotselidis at oracle.com>
Date:      2013-07-19 22:18 +0200
URL:       http://hg.openjdk.java.net/graal/graal/rev/2e852e96f977

Method renaming

! graal/com.oracle.graal.hotspot.test/src/com/oracle/graal/hotspot/test/WriteBarrierAdditionTest.java

Changeset: d5a8a7054005
Author:    Christos Kotselidis <christos.kotselidis at oracle.com>
Date:      2013-07-19 22:21 +0200
URL:       http://hg.openjdk.java.net/graal/graal/rev/d5a8a7054005

Merge


Changeset: 081eac3646d5
Author:    Christian Humer <christian.humer at gmail.com>
Date:      2013-07-20 10:52 +0200
URL:       http://hg.openjdk.java.net/graal/graal/rev/081eac3646d5

Truffle-DSL: Made specializations reflectable at runtime.

! graal/com.oracle.truffle.api.dsl/src/com/oracle/truffle/api/dsl/Specialization.java

Changeset: 1eee97b26bb6
Author:    Christian Humer <christian.humer at gmail.com>
Date:      2013-07-20 10:57 +0200
URL:       http://hg.openjdk.java.net/graal/graal/rev/1eee97b26bb6

Truffle: Added early read elimination to TruffleCache.

! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/TruffleCache.java


From lukas.stadler at jku.at  Mon Jul 22 09:02:55 2013
From: lukas.stadler at jku.at (Lukas Stadler)
Date: Mon, 22 Jul 2013 18:02:55 +0200
Subject: merge of types in ConditionalPhaseElimination
In-Reply-To: <7E4228B446372948BBB2916FC53FA49E26DDDDF5@rexma.intranet.epfl.ch>
References: <7E4228B446372948BBB2916FC53FA49E26DDDDF5@rexma.intranet.epfl.ch>
Message-ID: <C807FE26-ED46-4160-AABC-DE448C63D115@jku.at>

Hi Miguel,

yes, this is a bug? thanks for the hint!

- Lukas

On Jul 20, 2013, at 6:49 PM, Garcia Gutierrez Miguel Alfredo <miguelalfredo.garcia at epfl.ch> wrote:

> 
> Still figuring out the workings of ConditionalEliminationPhase, I have a question regarding
> 
>        public boolean merge(MergeNode merge, List<State> withStates) {
> 
> which merges among other things the "known (object) types" over all incoming states:
> 
>            for (Map.Entry<ValueNode, ResolvedJavaType> entry : knownTypes.entrySet()) {
>                ValueNode node = entry.getKey();
>                ResolvedJavaType type = entry.getValue();
> 
>                for (State other : withStates) {
>                    ResolvedJavaType otherType = other.getNodeType(node);
>                    type = widen(type, otherType);
>                    if (type == null) {
>                        break;
>                    }
>                }
> ------------>   if (type == null && type != node.objectStamp().type()) {
>                    newKnownTypes.put(node, type);
>                }
>            }
> 
> My reading of the above is:
>  (1) fold the meet-operation across all incoming states.
>  (2) Two cases:
>      (2.a) the accumulated type is null (ie, there's no common ancestor, for example because some of the incoming states lack entries in "knownTypes").
>      (2.b) non-null, and moreover a type more precise than Object has been inferred. That's the merged type we want to track in the merged state.
> 
> Getting to the code, there appears to be a typo (the arrow marks the spot). I guess the intention is adding an entry for the "accumulated type" to "newKnownTypes" (case 2.b). If so, that line should read:
> 
>                if (type != null && type != node.objectStamp().type()) {
> 
> 
> 
> Miguel
> 
> --
> Miguel Garcia
> Swiss Federal Institute of Technology
> EPFL - IC - LAMP1 - INR 328 - Station 14
> CH-1015 Lausanne - Switzerland
> http://lamp.epfl.ch/~magarcia/


From christian.thalinger at oracle.com  Mon Jul 22 21:07:24 2013
From: christian.thalinger at oracle.com (Christian Thalinger)
Date: Mon, 22 Jul 2013 21:07:24 -0700
Subject: destroysCallerSavedRegisters and register reference map in DebugInfo
Message-ID: <2B171F5D-D883-4359-9912-115ADCFB6C6B@oracle.com>

Quick question about this code in LinearScan:

    private void computeDebugInfo(IntervalWalker iw, final LIRInstruction op, LIRFrameState info) {
        BitSet registerRefMap = op.destroysCallerSavedRegisters() ? null : frameMap.initRegisterRefMap();
        BitSet frameRefMap = frameMap.initFrameRefMap();
        computeOopMap(iw, op, registerRefMap, frameRefMap);

Why are we not creating a register reference map if we destroy caller saved registers?  I'm having trouble with this logic on SPARC because computeOopMap wants to store a register in the map (a local register).

Would there be a downside if we always would create and empty map and just pass it on except a little bit of overhead?  Or am I missing something here?

-- Chris

From doug.simon at oracle.com  Tue Jul 23 00:44:40 2013
From: doug.simon at oracle.com (Doug Simon)
Date: Tue, 23 Jul 2013 09:44:40 +0200
Subject: destroysCallerSavedRegisters and register reference map in
	DebugInfo
In-Reply-To: <2B171F5D-D883-4359-9912-115ADCFB6C6B@oracle.com>
References: <2B171F5D-D883-4359-9912-115ADCFB6C6B@oracle.com>
Message-ID: <8D12919B-8E9F-407F-BBBC-A5EF0245D6C8@oracle.com>


On Jul 23, 2013, at 6:07 AM, Christian Thalinger <christian.thalinger at oracle.com> wrote:

> Quick question about this code in LinearScan:
> 
>    private void computeDebugInfo(IntervalWalker iw, final LIRInstruction op, LIRFrameState info) {
>        BitSet registerRefMap = op.destroysCallerSavedRegisters() ? null : frameMap.initRegisterRefMap();
>        BitSet frameRefMap = frameMap.initFrameRefMap();
>        computeOopMap(iw, op, registerRefMap, frameRefMap);
> 
> Why are we not creating a register reference map if we destroy caller saved registers?

Because all live registers will be spilled around the call and so there are no live values in registers during the call.

>  I'm having trouble with this logic on SPARC because computeOopMap wants to store a register in the map (a local register).

Wouldn't we just ensure that op.destroysCallerSavedRegisters() returns false for all SPARC ops (given that local registers are never killed by a callee)? 

> Would there be a downside if we always would create and empty map and just pass it on except a little bit of overhead?  Or am I missing something here?

This should be easy to measure - remove the ternary and measure the difference in compilation time.

-Doug

From christian.thalinger at oracle.com  Tue Jul 23 08:50:32 2013
From: christian.thalinger at oracle.com (Christian Thalinger)
Date: Tue, 23 Jul 2013 08:50:32 -0700
Subject: destroysCallerSavedRegisters and register reference map in
	DebugInfo
In-Reply-To: <8D12919B-8E9F-407F-BBBC-A5EF0245D6C8@oracle.com>
References: <2B171F5D-D883-4359-9912-115ADCFB6C6B@oracle.com>
	<8D12919B-8E9F-407F-BBBC-A5EF0245D6C8@oracle.com>
Message-ID: <C475989D-753D-4B6C-8428-9197556F9A6B@oracle.com>


On Jul 23, 2013, at 12:44 AM, Doug Simon <doug.simon at oracle.com> wrote:

> 
> On Jul 23, 2013, at 6:07 AM, Christian Thalinger <christian.thalinger at oracle.com> wrote:
> 
>> Quick question about this code in LinearScan:
>> 
>>   private void computeDebugInfo(IntervalWalker iw, final LIRInstruction op, LIRFrameState info) {
>>       BitSet registerRefMap = op.destroysCallerSavedRegisters() ? null : frameMap.initRegisterRefMap();
>>       BitSet frameRefMap = frameMap.initFrameRefMap();
>>       computeOopMap(iw, op, registerRefMap, frameRefMap);
>> 
>> Why are we not creating a register reference map if we destroy caller saved registers?
> 
> Because all live registers will be spilled around the call and so there are no live values in registers during the call.

That's what I thought but I wanted to make sure.

> 
>> I'm having trouble with this logic on SPARC because computeOopMap wants to store a register in the map (a local register).
> 
> Wouldn't we just ensure that op.destroysCallerSavedRegisters() returns false for all SPARC ops (given that local registers are never killed by a callee)? 

We can do this (I actually tried this already).  Would this be the right way to it?

-- Chris

> 
>> Would there be a downside if we always would create and empty map and just pass it on except a little bit of overhead?  Or am I missing something here?
> 
> This should be easy to measure - remove the ternary and measure the difference in compilation time.
> 
> -Doug


From tom.deneau at amd.com  Tue Jul 23 11:42:04 2013
From: tom.deneau at amd.com (Deneau, Tom)
Date: Tue, 23 Jul 2013 18:42:04 +0000
Subject: HSAIL Backend: Register getting overwritten as part of Move To Phi
In-Reply-To: <1BA5F3BC-9486-440D-AB3A-E93B81478458@oracle.com>
References: <20130715170157.A77A4480BF@hg.openjdk.java.net>
	<BC97738F8E7C8742BABED7F06FB9DF91469EFDC7@sausexdag01.amd.com>
	<1BA5F3BC-9486-440D-AB3A-E93B81478458@oracle.com>
Message-ID: <BC97738F8E7C8742BABED7F06FB9DF91469F4C5D@sausexdag01.amd.com>

Doug --

Thanks for making this fix.
Is there anything holding up checking in the webrev I sent you?
(besides having a way to reproduce the bug it had some additional 
functionality that would be good to get into the trunk).

-- Tom

-----Original Message-----
From: Doug Simon [mailto:doug.simon at oracle.com] 
Sent: Friday, July 19, 2013 5:55 AM
To: Deneau, Tom
Cc: graal-dev at openjdk.java.net
Subject: Re: HSAIL Backend: Register getting overwritten as part of Move To Phi

Tom,

I found the bug and am pushing through a fix now.

The issue was that, until now, we've only had backends whose conditional branch instructions operate on a conditional flag set by a preceding (compare) instruction. As such, we never considered (input) operands when moving instructions from successors to in front of a conditional branch. This assumption does not apply to HSAIL (or to PTX?). I've made a change that disables the optimization for conditional branches that have operands.

-Doug

On Jul 17, 2013, at 7:27 PM, "Deneau, Tom" <tom.deneau at amd.com> wrote:

> The problem described below was first noticed last week but then I thought
> it went away with the large number of checkins on July 15.  But now I see
> that it is still there.
> 
> I am not sure how to debug this problem so looking for any suggestions.
> To help you reproduce the problem on your side, I have a small webrev that
> adds the failing test case.   The test case itself uses String.contains and so
> needed the capability to properly handle accesses to char arrays and char fields,
> so in addition to the failing test case there is a very small change to the HSAIL
> backend to support the narrower object types like char.
> 
> The webrev can be found at
> http://cr.openjdk.java.net/~tdeneau/graal-webrevs/graal-webrev4.0/
> 
> One other change in this webrev, I made a change to the okra library loading code
> originally suggested by Doug.  Doug was suggesting a new environment variable pointing
> to the native library so we wouldn't need the -Dsun.boot.library.path on the java command
> line.  Instead I noticed that we were already requiring the directory to be in the PATH
> environment variable, so the loading code just looks down the PATH.
> 
> In the webrev, this change is simply reflected in a change to the version
> of the okra jar file (since the okra code is not part of graal proper).
> The change is entirely in the java code, there is no need
> to rebuild the actual native libraries.
> 
> Reproducing the failing test case...
> 
> With the patch applied, you should be able to get the test case failure with the following:
> 
>   * mx --vm server build product
>   * mx --vm server unittest @-G:InlineEverything @-Dkerneltester.logLevel=INFO hsail.test.StringContainsAcceptTest
> 
> The logLevel=INFO dumps the generated HSAIL to stdout.  When run on my system, the problem
> code starts at @L10.  We are reading the first char from each of the strings and
> getting ready to compare them.
> 
> @L10:
> 	ld_global_u16 $s9, [$d0 + 24];
> 	ld_global_u16 $s10, [$d3 + 24];
> 	st_spill_s32 $s10, [%spillseg][24];
> 	mov_b32 $s9, 0;                          <<< problem       
> 	cmp_ne_b1_s32 $c0, $s9, $s10;
> 
> 
> -- Tom Deneau
> 
> 
> 
> -----Original Message-----
> From: Deneau, Tom 
> Sent: Monday, July 15, 2013 4:05 PM
> To: graal-dev at openjdk.java.net
> Subject: RE: graal/graal: 107 new changesets
> 
> Doug or others --
> 
> I was about to ask for help on a codegen problem we were seeing but after updating to the latest default,
> I see that it is gone (so I'm assuming it was not in our backend :) ).  Of course it is possible that the bug
> is just being hidden by some unrelated change.   Anyway, here is a brief description,
> maybe you can tell which of the many changesets below would have fixed this, if any.
> 
> We were using String.contains as our test case, which was being nicely inlined, and we generated the following 
> HSAIL code which led to the problem
> 
> 	ld_global_u16 $s8, [$d3 + 24];         // read a u16 char from the test String
> 	ld_global_u16 $s9, [$d1 + 24];         // read a u16 char from the pattern  
> 	st_spill_s32 $s9, [%spillseg][24];     // register spill
> 	mov_b32 $s8, 0;                        // <<<<--- This code was causing the problem 
> 	cmp_ne_b1_s32 $c0, $s8, $s9;           // compare the two chars but s8 has been clobbered
> 
> 
> When I did a -G:TraceLIRGeneratorLevel=2, I could see that the problematic instruction
> "mov_b32 $s8, 0"
> was generated as part of something called
>       MOVE TO PHI from 276|EndNode to 277|LoopBegin
> 
> as part of PhiResolver.dispose, the part that is commented with
>  // generate move for move from non variable to arbitrary destination
> 
> Does the above sound like something that was purposely fixed?
> 
> -- Tom Deneau
> 
> 
> 




From christian.thalinger at oracle.com  Tue Jul 23 14:09:56 2013
From: christian.thalinger at oracle.com (Christian Thalinger)
Date: Tue, 23 Jul 2013 14:09:56 -0700
Subject: RFR: NewInstanceStub reads InstanceKlass::_init_state as int but is u1
Message-ID: <FCA90C98-7EB6-4037-A176-C04D0CE3A86D@oracle.com>

_init_state is defined as u1 in InstanceKlass:

  u1              _init_state;                    // state of class

but is read as int in newInstance:

diff -r 6057d0168f47 graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/stubs/NewInstanceStub.java
--- a/graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/stubs/NewInstanceStub.java	Tue Jul 23 12:27:06 2013 -0700
+++ b/graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/stubs/NewInstanceStub.java	Tue Jul 23 14:06:49 2013 -0700
@@ -89,7 +89,7 @@ public class NewInstanceStub extends Sni
     private static Object newInstance(Word hub, @ConstantParameter Word intArrayHub) {
         int sizeInBytes = hub.readInt(klassInstanceSizeOffset(), LocationIdentity.FINAL_LOCATION);
         if (!forceSlowPath() && inlineContiguousAllocationSupported()) {
-            if (hub.readInt(klassStateOffset(), CLASS_STATE_LOCATION) == klassStateFullyInitialized()) {
+            if (hub.readByte(klassStateOffset(), CLASS_STATE_LOCATION) == klassStateFullyInitialized()) {
                 Word memory = refillAllocate(intArrayHub, sizeInBytes, logging());
                 if (memory.notEqual(0)) {
                     Word prototypeMarkWord = hub.readWord(prototypeMarkWordOffset(), PROTOTYPE_MARK_WORD_LOCATION);

-- Chris

From doug.simon at oracle.com  Tue Jul 23 14:27:58 2013
From: doug.simon at oracle.com (Doug Simon)
Date: Tue, 23 Jul 2013 23:27:58 +0200
Subject: HSAIL Backend: Register getting overwritten as part of Move To Phi
In-Reply-To: <BC97738F8E7C8742BABED7F06FB9DF91469F4C5D@sausexdag01.amd.com>
References: <20130715170157.A77A4480BF@hg.openjdk.java.net>
	<BC97738F8E7C8742BABED7F06FB9DF91469EFDC7@sausexdag01.amd.com>
	<1BA5F3BC-9486-440D-AB3A-E93B81478458@oracle.com>
	<BC97738F8E7C8742BABED7F06FB9DF91469F4C5D@sausexdag01.amd.com>
Message-ID: <3A7DE6F5-BDE6-4495-9BEA-363053EBE333@oracle.com>


On Jul 23, 2013, at 8:42 PM, "Deneau, Tom" <tom.deneau at amd.com> wrote:

> Doug --
> 
> Thanks for making this fix.
> Is there anything holding up checking in the webrev I sent you?
> (besides having a way to reproduce the bug it had some additional 
> functionality that would be good to get into the trunk).

I'm pushing it through now.

-Doug

> 
> -----Original Message-----
> From: Doug Simon [mailto:doug.simon at oracle.com] 
> Sent: Friday, July 19, 2013 5:55 AM
> To: Deneau, Tom
> Cc: graal-dev at openjdk.java.net
> Subject: Re: HSAIL Backend: Register getting overwritten as part of Move To Phi
> 
> Tom,
> 
> I found the bug and am pushing through a fix now.
> 
> The issue was that, until now, we've only had backends whose conditional branch instructions operate on a conditional flag set by a preceding (compare) instruction. As such, we never considered (input) operands when moving instructions from successors to in front of a conditional branch. This assumption does not apply to HSAIL (or to PTX?). I've made a change that disables the optimization for conditional branches that have operands.
> 
> -Doug
> 
> On Jul 17, 2013, at 7:27 PM, "Deneau, Tom" <tom.deneau at amd.com> wrote:
> 
>> The problem described below was first noticed last week but then I thought
>> it went away with the large number of checkins on July 15.  But now I see
>> that it is still there.
>> 
>> I am not sure how to debug this problem so looking for any suggestions.
>> To help you reproduce the problem on your side, I have a small webrev that
>> adds the failing test case.   The test case itself uses String.contains and so
>> needed the capability to properly handle accesses to char arrays and char fields,
>> so in addition to the failing test case there is a very small change to the HSAIL
>> backend to support the narrower object types like char.
>> 
>> The webrev can be found at
>> http://cr.openjdk.java.net/~tdeneau/graal-webrevs/graal-webrev4.0/
>> 
>> One other change in this webrev, I made a change to the okra library loading code
>> originally suggested by Doug.  Doug was suggesting a new environment variable pointing
>> to the native library so we wouldn't need the -Dsun.boot.library.path on the java command
>> line.  Instead I noticed that we were already requiring the directory to be in the PATH
>> environment variable, so the loading code just looks down the PATH.
>> 
>> In the webrev, this change is simply reflected in a change to the version
>> of the okra jar file (since the okra code is not part of graal proper).
>> The change is entirely in the java code, there is no need
>> to rebuild the actual native libraries.
>> 
>> Reproducing the failing test case...
>> 
>> With the patch applied, you should be able to get the test case failure with the following:
>> 
>>  * mx --vm server build product
>>  * mx --vm server unittest @-G:InlineEverything @-Dkerneltester.logLevel=INFO hsail.test.StringContainsAcceptTest
>> 
>> The logLevel=INFO dumps the generated HSAIL to stdout.  When run on my system, the problem
>> code starts at @L10.  We are reading the first char from each of the strings and
>> getting ready to compare them.
>> 
>> @L10:
>> 	ld_global_u16 $s9, [$d0 + 24];
>> 	ld_global_u16 $s10, [$d3 + 24];
>> 	st_spill_s32 $s10, [%spillseg][24];
>> 	mov_b32 $s9, 0;                          <<< problem       
>> 	cmp_ne_b1_s32 $c0, $s9, $s10;
>> 
>> 
>> -- Tom Deneau
>> 
>> 
>> 
>> -----Original Message-----
>> From: Deneau, Tom 
>> Sent: Monday, July 15, 2013 4:05 PM
>> To: graal-dev at openjdk.java.net
>> Subject: RE: graal/graal: 107 new changesets
>> 
>> Doug or others --
>> 
>> I was about to ask for help on a codegen problem we were seeing but after updating to the latest default,
>> I see that it is gone (so I'm assuming it was not in our backend :) ).  Of course it is possible that the bug
>> is just being hidden by some unrelated change.   Anyway, here is a brief description,
>> maybe you can tell which of the many changesets below would have fixed this, if any.
>> 
>> We were using String.contains as our test case, which was being nicely inlined, and we generated the following 
>> HSAIL code which led to the problem
>> 
>> 	ld_global_u16 $s8, [$d3 + 24];         // read a u16 char from the test String
>> 	ld_global_u16 $s9, [$d1 + 24];         // read a u16 char from the pattern  
>> 	st_spill_s32 $s9, [%spillseg][24];     // register spill
>> 	mov_b32 $s8, 0;                        // <<<<--- This code was causing the problem 
>> 	cmp_ne_b1_s32 $c0, $s8, $s9;           // compare the two chars but s8 has been clobbered
>> 
>> 
>> When I did a -G:TraceLIRGeneratorLevel=2, I could see that the problematic instruction
>> "mov_b32 $s8, 0"
>> was generated as part of something called
>>      MOVE TO PHI from 276|EndNode to 277|LoopBegin
>> 
>> as part of PhiResolver.dispose, the part that is commented with
>> // generate move for move from non variable to arbitrary destination
>> 
>> Does the above sound like something that was purposely fixed?
>> 
>> -- Tom Deneau
>> 
>> 
>> 
> 
> 
> 


From christian.thalinger at oracle.com  Tue Jul 23 18:23:11 2013
From: christian.thalinger at oracle.com (Christian Thalinger)
Date: Tue, 23 Jul 2013 18:23:11 -0700
Subject: RFR: NewInstanceStub reads InstanceKlass::_init_state as int but
	is u1
In-Reply-To: <FCA90C98-7EB6-4037-A176-C04D0CE3A86D@oracle.com>
References: <FCA90C98-7EB6-4037-A176-C04D0CE3A86D@oracle.com>
Message-ID: <108A2038-4249-41F3-87A6-299F9185EBE5@oracle.com>

Here are a couple more fixes to this code.  The threadAllocatedBytesOffset change is not really necessary but since it's defined as a long:

  jlong _allocated_bytes;                       // Cumulative number of bytes allocated on

we should read it as a long.

-- Chris

diff -r 6057d0168f47 graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/stubs/NewInstanceStub.java
--- a/graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/stubs/NewInstanceStub.java	Tue Jul 23 12:27:06 2013 -0700
+++ b/graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/stubs/NewInstanceStub.java	Tue Jul 23 18:20:38 2013 -0700
@@ -89,7 +89,7 @@ public class NewInstanceStub extends Sni
     private static Object newInstance(Word hub, @ConstantParameter Word intArrayHub) {
         int sizeInBytes = hub.readInt(klassInstanceSizeOffset(), LocationIdentity.FINAL_LOCATION);
         if (!forceSlowPath() && inlineContiguousAllocationSupported()) {
-            if (hub.readInt(klassStateOffset(), CLASS_STATE_LOCATION) == klassStateFullyInitialized()) {
+            if (hub.readByte(klassStateOffset(), CLASS_STATE_LOCATION) == klassStateFullyInitialized()) {
                 Word memory = refillAllocate(intArrayHub, sizeInBytes, logging());
                 if (memory.notEqual(0)) {
                     Word prototypeMarkWord = hub.readWord(prototypeMarkWordOffset(), PROTOTYPE_MARK_WORD_LOCATION);
@@ -137,21 +137,21 @@ public class NewInstanceStub extends Sni
         Word end = readTlabEnd(thread);
 
         // calculate amount of free space
-        Word tlabFreeSpaceInBytes = end.subtract(top);
+        long tlabFreeSpaceInBytes = end.subtract(top).rawValue();
 
         if (log) {
             printf("refillTLAB: thread=%p\n", thread.rawValue());
             printf("refillTLAB: top=%p\n", top.rawValue());
             printf("refillTLAB: end=%p\n", end.rawValue());
-            printf("refillTLAB: tlabFreeSpaceInBytes=%d\n", tlabFreeSpaceInBytes.rawValue());
+            printf("refillTLAB: tlabFreeSpaceInBytes=%ld\n", tlabFreeSpaceInBytes);
         }
 
-        Word tlabFreeSpaceInWords = tlabFreeSpaceInBytes.unsignedShiftRight(log2WordSize());
+        long tlabFreeSpaceInWords = tlabFreeSpaceInBytes >>> log2WordSize();
 
         // Retain TLAB and allocate object in shared space if
         // the amount free in the TLAB is too large to discard.
         Word refillWasteLimit = thread.readWord(tlabRefillWasteLimitOffset(), TLAB_REFILL_WASTE_LIMIT_LOCATION);
-        if (tlabFreeSpaceInWords.belowOrEqual(refillWasteLimit)) {
+        if (tlabFreeSpaceInWords <= refillWasteLimit.rawValue()) {
             if (tlabStats()) {
                 // increment number of refills
                 thread.writeInt(tlabNumberOfRefillsOffset(), thread.readInt(tlabNumberOfRefillsOffset(), TLAB_NOF_REFILLS_LOCATION) + 1, TLAB_NOF_REFILLS_LOCATION);
@@ -159,11 +159,11 @@ public class NewInstanceStub extends Sni
                     printf("thread: %p -- number_of_refills %d\n", thread.rawValue(), thread.readInt(tlabNumberOfRefillsOffset(), TLAB_NOF_REFILLS_LOCATION));
                 }
                 // accumulate wastage
-                Word wastage = thread.readWord(tlabFastRefillWasteOffset(), TLAB_FAST_REFILL_WASTE_LOCATION).add(tlabFreeSpaceInWords);
+                int wastage = thread.readInt(tlabFastRefillWasteOffset(), TLAB_FAST_REFILL_WASTE_LOCATION) + (int) tlabFreeSpaceInWords;
                 if (log) {
-                    printf("thread: %p -- accumulated wastage %d\n", thread.rawValue(), wastage.rawValue());
+                    printf("thread: %p -- accumulated wastage %d\n", thread.rawValue(), wastage);
                 }
-                thread.writeWord(tlabFastRefillWasteOffset(), wastage, TLAB_FAST_REFILL_WASTE_LOCATION);
+                thread.writeInt(tlabFastRefillWasteOffset(), wastage, TLAB_FAST_REFILL_WASTE_LOCATION);
             }
 
             // if TLAB is currently allocated (top or end != null) then
@@ -172,13 +172,13 @@ public class NewInstanceStub extends Sni
                 int headerSize = arrayBaseOffset(Kind.Int);
                 // just like the HotSpot assembler stubs, assumes that tlabFreeSpaceInInts fits in
                 // an int
-                int tlabFreeSpaceInInts = (int) tlabFreeSpaceInBytes.rawValue() >>> 2;
+                int tlabFreeSpaceInInts = (int) tlabFreeSpaceInBytes >>> 2;
                 int length = ((alignmentReserveInBytes - headerSize) >>> 2) + tlabFreeSpaceInInts;
                 NewObjectSnippets.formatArray(intArrayHub, -1, length, headerSize, top, intArrayMarkWord, false);
 
-                Word allocated = thread.readWord(threadAllocatedBytesOffset(), TLAB_THREAD_ALLOCATED_BYTES_LOCATION);
-                allocated = allocated.add(top.subtract(readTlabStart(thread)));
-                thread.writeWord(threadAllocatedBytesOffset(), allocated, TLAB_THREAD_ALLOCATED_BYTES_LOCATION);
+                long allocated = thread.readLong(threadAllocatedBytesOffset(), TLAB_THREAD_ALLOCATED_BYTES_LOCATION);
+                allocated = allocated + top.subtract(readTlabStart(thread)).rawValue();
+                thread.writeLong(threadAllocatedBytesOffset(), allocated, TLAB_THREAD_ALLOCATED_BYTES_LOCATION);
             }
 
             // refill the TLAB with an eden allocation

On Jul 23, 2013, at 2:09 PM, Christian Thalinger <christian.thalinger at oracle.com> wrote:

> _init_state is defined as u1 in InstanceKlass:
> 
>  u1              _init_state;                    // state of class
> 
> but is read as int in newInstance:
> 
> diff -r 6057d0168f47 graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/stubs/NewInstanceStub.java
> --- a/graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/stubs/NewInstanceStub.java	Tue Jul 23 12:27:06 2013 -0700
> +++ b/graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/stubs/NewInstanceStub.java	Tue Jul 23 14:06:49 2013 -0700
> @@ -89,7 +89,7 @@ public class NewInstanceStub extends Sni
>     private static Object newInstance(Word hub, @ConstantParameter Word intArrayHub) {
>         int sizeInBytes = hub.readInt(klassInstanceSizeOffset(), LocationIdentity.FINAL_LOCATION);
>         if (!forceSlowPath() && inlineContiguousAllocationSupported()) {
> -            if (hub.readInt(klassStateOffset(), CLASS_STATE_LOCATION) == klassStateFullyInitialized()) {
> +            if (hub.readByte(klassStateOffset(), CLASS_STATE_LOCATION) == klassStateFullyInitialized()) {
>                 Word memory = refillAllocate(intArrayHub, sizeInBytes, logging());
>                 if (memory.notEqual(0)) {
>                     Word prototypeMarkWord = hub.readWord(prototypeMarkWordOffset(), PROTOTYPE_MARK_WORD_LOCATION);
> 
> -- Chris


From doug.simon at oracle.com  Wed Jul 24 00:57:34 2013
From: doug.simon at oracle.com (Doug Simon)
Date: Wed, 24 Jul 2013 09:57:34 +0200
Subject: destroysCallerSavedRegisters and register reference map in
	DebugInfo
In-Reply-To: <C475989D-753D-4B6C-8428-9197556F9A6B@oracle.com>
References: <2B171F5D-D883-4359-9912-115ADCFB6C6B@oracle.com>
	<8D12919B-8E9F-407F-BBBC-A5EF0245D6C8@oracle.com>
	<C475989D-753D-4B6C-8428-9197556F9A6B@oracle.com>
Message-ID: <D6EA345A-CAA1-4878-AAC0-E7B0BE21C389@oracle.com>


On Jul 23, 2013, at 5:50 PM, Christian Thalinger <christian.thalinger at oracle.com> wrote:

> 
> On Jul 23, 2013, at 12:44 AM, Doug Simon <doug.simon at oracle.com> wrote:
> 
>> 
>> On Jul 23, 2013, at 6:07 AM, Christian Thalinger <christian.thalinger at oracle.com> wrote:
>> 
>>> Quick question about this code in LinearScan:
>>> 
>>>  private void computeDebugInfo(IntervalWalker iw, final LIRInstruction op, LIRFrameState info) {
>>>      BitSet registerRefMap = op.destroysCallerSavedRegisters() ? null : frameMap.initRegisterRefMap();
>>>      BitSet frameRefMap = frameMap.initFrameRefMap();
>>>      computeOopMap(iw, op, registerRefMap, frameRefMap);
>>> 
>>> Why are we not creating a register reference map if we destroy caller saved registers?
>> 
>> Because all live registers will be spilled around the call and so there are no live values in registers during the call.
> 
> That's what I thought but I wanted to make sure.
> 
>> 
>>> I'm having trouble with this logic on SPARC because computeOopMap wants to store a register in the map (a local register).
>> 
>> Wouldn't we just ensure that op.destroysCallerSavedRegisters() returns false for all SPARC ops (given that local registers are never killed by a callee)? 
> 
> We can do this (I actually tried this already).  Would this be the right way to it?

I'm not sure how register oop maps work for SPARC but I think this is the right way to do it. I assume the oop map will cover the registers automatically saved by SPARC register windowing mechanism. What does C2 do?

-Doug


From doug.simon at oracle.com  Wed Jul 24 02:09:23 2013
From: doug.simon at oracle.com (doug.simon at oracle.com)
Date: Wed, 24 Jul 2013 09:09:23 +0000
Subject: hg: graal/graal: 42 new changesets
Message-ID: <20130724091248.02F41482E1@hg.openjdk.java.net>

Changeset: da9d33c7b6de
Author:    Christian Humer <christian.humer at gmail.com>
Date:      2013-07-21 15:25 +0200
URL:       http://hg.openjdk.java.net/graal/graal/rev/da9d33c7b6de

Truffle: Increased TruffleCache maximum node count from 200 to 350.

! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/TruffleCompilerOptions.java

Changeset: b05e1ff3aac0
Author:    Christos Kotselidis <christos.kotselidis at oracle.com>
Date:      2013-07-21 19:15 +0200
URL:       http://hg.openjdk.java.net/graal/graal/rev/b05e1ff3aac0

Rename WriteBarrierType to BarrierType

! graal/com.oracle.graal.hotspot.test/src/com/oracle/graal/hotspot/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.hotspot/src/com/oracle/graal/hotspot/replacements/UnsafeLoadSnippets.java
! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/WriteBarrierSnippets.java
! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/HeapAccess.java
! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/debug/DynamicCounterNode.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/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: 761002c55728
Author:    Christos Kotselidis <christos.kotselidis at oracle.com>
Date:      2013-07-21 20:11 +0200
URL:       http://hg.openjdk.java.net/graal/graal/rev/761002c55728

Add new node for referent field read barrier (G1 GC)

! graal/com.oracle.graal.hotspot.test/src/com/oracle/graal/hotspot/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/replacements/WriteBarrierSnippets.java
+ graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/G1ReferentFieldReadBarrier.java

Changeset: 4c6df71db9e7
Author:    Christos Kotselidis <christos.kotselidis at oracle.com>
Date:      2013-07-21 20:11 +0200
URL:       http://hg.openjdk.java.net/graal/graal/rev/4c6df71db9e7

Merge


Changeset: 000ee2d0c518
Author:    Christos Kotselidis <christos.kotselidis at oracle.com>
Date:      2013-07-21 22:13 +0200
URL:       http://hg.openjdk.java.net/graal/graal/rev/000ee2d0c518

Method renaming

! graal/com.oracle.graal.compiler.hsail/src/com/oracle/graal/compiler/hsail/HSAILLIRGenerator.java
! graal/com.oracle.graal.hotspot.amd64/src/com/oracle/graal/hotspot/amd64/AMD64HotSpotLIRGenerator.java
! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/HeapAccess.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/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/java/CompareAndSwapNode.java

Changeset: 623accae20d1
Author:    Roland Schatz <roland.schatz at oracle.com>
Date:      2013-07-22 10:46 +0200
URL:       http://hg.openjdk.java.net/graal/graal/rev/623accae20d1

Leave null check at original node when adding G1ReferentFieldReadBarrier.

! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/phases/WriteBarrierAdditionPhase.java

Changeset: 079513fc609e
Author:    Roland Schatz <roland.schatz at oracle.com>
Date:      2013-07-22 10:54 +0200
URL:       http://hg.openjdk.java.net/graal/graal/rev/079513fc609e

Rename isInitialized to isInitialization (inverting semantics!).

! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/phases/WriteBarrierAdditionPhase.java
! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/UnsafeArrayCopyNode.java
! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/extended/ArrayRangeWriteNode.java
! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/extended/WriteNode.java
! graal/com.oracle.graal.word/src/com/oracle/graal/word/phases/WordTypeRewriterPhase.java

Changeset: 45ca31374e9f
Author:    Roland Schatz <roland.schatz at oracle.com>
Date:      2013-07-22 11:58 +0200
URL:       http://hg.openjdk.java.net/graal/graal/rev/45ca31374e9f

Documentation fixes.

! graal/com.oracle.graal.api.code/src/com/oracle/graal/api/code/CompilationResult.java
! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/extended/ArrayRangeWriteNode.java
! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/extended/WriteNode.java

Changeset: 04f817fb0456
Author:    Roland Schatz <roland.schatz at oracle.com>
Date:      2013-07-22 12:12 +0200
URL:       http://hg.openjdk.java.net/graal/graal/rev/04f817fb0456

Method to reconstruct array index from LocationNode.

! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotRuntime.java
! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/spi/GraalCodeCacheProvider.java

Changeset: ba2769b3a438
Author:    Christos Kotselidis <christos.kotselidis at oracle.com>
Date:      2013-07-22 13:28 +0200
URL:       http://hg.openjdk.java.net/graal/graal/rev/ba2769b3a438

Add Javadoc to G1ReferentFieldReadBarrier

! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/G1ReferentFieldReadBarrier.java

Changeset: 981c8a4d711a
Author:    Christos Kotselidis <christos.kotselidis at oracle.com>
Date:      2013-07-22 13:34 +0200
URL:       http://hg.openjdk.java.net/graal/graal/rev/981c8a4d711a

Make VerifyOopStub leaf call

! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotRuntime.java

Changeset: 02a5f5abd842
Author:    Christos Kotselidis <christos.kotselidis at oracle.com>
Date:      2013-07-22 13:35 +0200
URL:       http://hg.openjdk.java.net/graal/graal/rev/02a5f5abd842

Merge

! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotRuntime.java

Changeset: f3697f17f671
Author:    Lukas Stadler <lukas.stadler at jku.at>
Date:      2013-07-22 16:04 +0200
URL:       http://hg.openjdk.java.net/graal/graal/rev/f3697f17f671

small fixes for early read elimination

! graal/com.oracle.graal.virtual/src/com/oracle/graal/virtual/phases/ea/PEReadEliminationClosure.java
! graal/com.oracle.graal.virtual/src/com/oracle/graal/virtual/phases/ea/ReadEliminationClosure.java

Changeset: e43eb9fe98e5
Author:    Lukas Stadler <lukas.stadler at jku.at>
Date:      2013-07-22 16:04 +0200
URL:       http://hg.openjdk.java.net/graal/graal/rev/e43eb9fe98e5

check for one more case in ConditionalEliminationTest

! graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/ConditionalEliminationTest.java

Changeset: 020f63bfd781
Author:    Lukas Stadler <lukas.stadler at jku.at>
Date:      2013-07-22 16:18 +0200
URL:       http://hg.openjdk.java.net/graal/graal/rev/020f63bfd781

fix merging of types in ConditionalEliminationPhase
bug reported by Miguel Garcia <miguelalfredo.garcia at epfl.ch>

! 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: 63c3d7b5edd9
Author:    Lukas Stadler <lukas.stadler at jku.at>
Date:      2013-07-22 16:19 +0200
URL:       http://hg.openjdk.java.net/graal/graal/rev/63c3d7b5edd9

Merge


Changeset: 50f3f3958555
Author:    Andreas Woess <andreas.woess at jku.at>
Date:      2013-07-22 16:17 +0200
URL:       http://hg.openjdk.java.net/graal/graal/rev/50f3f3958555

Truffle: remove Node.EMPTY_ARRAY constant

! graal/com.oracle.truffle.api/src/com/oracle/truffle/api/nodes/Node.java

Changeset: 3cf5f371dc9f
Author:    Andreas Woess <andreas.woess at jku.at>
Date:      2013-07-22 16:20 +0200
URL:       http://hg.openjdk.java.net/graal/graal/rev/3cf5f371dc9f

Truffle: print inlined call target and rename profiling option.

! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/OptimizedCallTarget.java
! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/TruffleCompilerOptions.java

Changeset: e9248ebb1d79
Author:    Andreas Woess <andreas.woess at jku.at>
Date:      2013-07-22 17:29 +0200
URL:       http://hg.openjdk.java.net/graal/graal/rev/e9248ebb1d79

Truffle: ignore null children in NodeUtil.findNodeChildren; refactoring.

! graal/com.oracle.truffle.api/src/com/oracle/truffle/api/nodes/NodeUtil.java

Changeset: e87d56a51047
Author:    Andreas Woess <andreas.woess at jku.at>
Date:      2013-07-22 18:07 +0200
URL:       http://hg.openjdk.java.net/graal/graal/rev/e87d56a51047

Truffle: add Node.isReplaceable()

! graal/com.oracle.truffle.api/src/com/oracle/truffle/api/nodes/Node.java

Changeset: 669e3105804d
Author:    Andreas Woess <andreas.woess at jku.at>
Date:      2013-07-22 19:17 +0200
URL:       http://hg.openjdk.java.net/graal/graal/rev/669e3105804d

Always insert phi nodes using graph.add.

! graal/com.oracle.graal.java/src/com/oracle/graal/java/FrameStateBuilder.java
! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/InliningUtil.java

Changeset: 4da2141fc40f
Author:    Andreas Woess <andreas.woess at jku.at>
Date:      2013-07-22 19:12 +0200
URL:       http://hg.openjdk.java.net/graal/graal/rev/4da2141fc40f

Canonicalize final field loads from a phi of constant objects.

! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/java/LoadFieldNode.java

Changeset: 23a7cbee48d0
Author:    Christos Kotselidis <christos.kotselidis at oracle.com>
Date:      2013-07-22 22:03 +0200
URL:       http://hg.openjdk.java.net/graal/graal/rev/23a7cbee48d0

Add LoweredCompareAndSwapNode

+ graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/java/LoweredCompareAndSwapNode.java

Changeset: e7679ec4f27f
Author:    Christos Kotselidis <christos.kotselidis at oracle.com>
Date:      2013-07-22 22:03 +0200
URL:       http://hg.openjdk.java.net/graal/graal/rev/e7679ec4f27f

Lower CAS nodes to their lowered versions

! graal/com.oracle.graal.compiler.hsail/src/com/oracle/graal/compiler/hsail/HSAILLIRGenerator.java
! graal/com.oracle.graal.compiler.ptx/src/com/oracle/graal/compiler/ptx/PTXLIRGenerator.java
! graal/com.oracle.graal.compiler.sparc/src/com/oracle/graal/compiler/sparc/SPARCLIRGenerator.java
! graal/com.oracle.graal.hotspot.amd64/src/com/oracle/graal/hotspot/amd64/AMD64HotSpotLIRGenerator.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/java/CompareAndSwapNode.java
! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/spi/LIRGeneratorTool.java

Changeset: cea4beb67bfd
Author:    Christos Kotselidis <christos.kotselidis at oracle.com>
Date:      2013-07-22 22:04 +0200
URL:       http://hg.openjdk.java.net/graal/graal/rev/cea4beb67bfd

Merge


Changeset: df023d960636
Author:    twisti
Date:      2013-07-22 21:42 -0700
URL:       http://hg.openjdk.java.net/graal/graal/rev/df023d960636

Fixed comment typo.

! graal/com.oracle.graal.api.code/src/com/oracle/graal/api/code/DebugInfo.java

Changeset: 22baf2a69f6d
Author:    twisti
Date:      2013-07-22 21:43 -0700
URL:       http://hg.openjdk.java.net/graal/graal/rev/22baf2a69f6d

Reuse linkage.

! graal/com.oracle.graal.hotspot.amd64/src/com/oracle/graal/hotspot/amd64/AMD64HotSpotUnwindOp.java

Changeset: e1fcdda22831
Author:    twisti
Date:      2013-07-22 22:26 -0700
URL:       http://hg.openjdk.java.net/graal/graal/rev/e1fcdda22831

SPARC: can compile some stubs now but they don't work yet

! graal/com.oracle.graal.asm.sparc/src/com/oracle/graal/asm/sparc/SPARCAssembler.java
! graal/com.oracle.graal.asm.sparc/src/com/oracle/graal/asm/sparc/SPARCMacroAssembler.java
! graal/com.oracle.graal.compiler.sparc/src/com/oracle/graal/compiler/sparc/SPARCLIRGenerator.java
! graal/com.oracle.graal.hotspot.sparc/src/com/oracle/graal/hotspot/sparc/SPARCHotSpotBackend.java
+ graal/com.oracle.graal.hotspot.sparc/src/com/oracle/graal/hotspot/sparc/SPARCHotSpotDeoptimizeCallerOp.java
+ graal/com.oracle.graal.hotspot.sparc/src/com/oracle/graal/hotspot/sparc/SPARCHotSpotEpilogueOp.java
+ graal/com.oracle.graal.hotspot.sparc/src/com/oracle/graal/hotspot/sparc/SPARCHotSpotJumpToExceptionHandlerInCallerOp.java
! graal/com.oracle.graal.hotspot.sparc/src/com/oracle/graal/hotspot/sparc/SPARCHotSpotLIRGenerator.java
+ graal/com.oracle.graal.hotspot.sparc/src/com/oracle/graal/hotspot/sparc/SPARCHotSpotPatchReturnAddressOp.java
! graal/com.oracle.graal.hotspot.sparc/src/com/oracle/graal/hotspot/sparc/SPARCHotSpotRegisterConfig.java
! graal/com.oracle.graal.hotspot.sparc/src/com/oracle/graal/hotspot/sparc/SPARCHotSpotRuntime.java
+ graal/com.oracle.graal.hotspot.sparc/src/com/oracle/graal/hotspot/sparc/SPARCHotSpotUnwindOp.java
! graal/com.oracle.graal.lir.sparc/src/com/oracle/graal/lir/sparc/SPARCArithmetic.java
! graal/com.oracle.graal.lir.sparc/src/com/oracle/graal/lir/sparc/SPARCCall.java
! graal/com.oracle.graal.lir.sparc/src/com/oracle/graal/lir/sparc/SPARCControlFlow.java
! graal/com.oracle.graal.lir.sparc/src/com/oracle/graal/lir/sparc/SPARCMove.java
! graal/com.oracle.graal.sparc/src/com/oracle/graal/sparc/SPARC.java
! src/cpu/sparc/vm/graalCodeInstaller_sparc.hpp
! src/share/vm/graal/graalCodeInstaller.cpp

Changeset: d7f8a08c37c2
Author:    Roland Schatz <roland.schatz at oracle.com>
Date:      2013-07-22 13:33 +0200
URL:       http://hg.openjdk.java.net/graal/graal/rev/d7f8a08c37c2

Documentation fix.

! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/spi/GraalCodeCacheProvider.java

Changeset: a0401b1f7cc4
Author:    Roland Schatz <roland.schatz at oracle.com>
Date:      2013-07-23 09:45 +0200
URL:       http://hg.openjdk.java.net/graal/graal/rev/a0401b1f7cc4

Retry canonicalization after inferStamp.

! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/CanonicalizerPhase.java

Changeset: 94cf5df0727f
Author:    Andreas Woess <andreas.woess at jku.at>
Date:      2013-07-23 10:42 +0200
URL:       http://hg.openjdk.java.net/graal/graal/rev/94cf5df0727f

Backout changeset 4c12d3756015; ensure compiledCodeInvalidated() is never inlined.

! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/OptimizedCallTarget.java
! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/TruffleCompilerImpl.java
! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/substitutions/OptimizedCallTargetSubstitutions.java

Changeset: f2008a93ad54
Author:    Andreas Woess <andreas.woess at jku.at>
Date:      2013-07-23 11:19 +0200
URL:       http://hg.openjdk.java.net/graal/graal/rev/f2008a93ad54

Truffle: add invalidation count to call target profiling / trace compilation.

! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/OptimizedCallTarget.java

Changeset: 7a0ba9b20fec
Author:    Christian Humer <christian.humer at gmail.com>
Date:      2013-07-23 17:47 +0200
URL:       http://hg.openjdk.java.net/graal/graal/rev/7a0ba9b20fec

Truffle-DSL: fixed bug in rewriting of child arrays.

! graal/com.oracle.truffle.dsl.processor/src/com/oracle/truffle/dsl/processor/node/NodeCodeGenerator.java

Changeset: 1b11e3c8529c
Author:    Christian Humer <christian.humer at gmail.com>
Date:      2013-07-23 17:48 +0200
URL:       http://hg.openjdk.java.net/graal/graal/rev/1b11e3c8529c

Merge.


Changeset: 6872c61c1d3e
Author:    Roland Schatz <roland.schatz at oracle.com>
Date:      2013-07-23 18:23 +0200
URL:       http://hg.openjdk.java.net/graal/graal/rev/6872c61c1d3e

Fix null reference access when dumping raw data patches.

! graal/com.oracle.graal.api.code/src/com/oracle/graal/api/code/CompilationResult.java
! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/HotSpotCompiledRuntimeStub.java
! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotRuntime.java
! graal/com.oracle.graal.lir/src/com/oracle/graal/lir/asm/TargetMethodAssembler.java

Changeset: 8c570011b86f
Author:    Andreas Woess <andreas.woess at jku.at>
Date:      2013-07-23 19:05 +0200
URL:       http://hg.openjdk.java.net/graal/graal/rev/8c570011b86f

Truffle: when a node is replaced, notify optimized call target and delay compilation.

! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/OptimizedCallTarget.java
! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/TruffleCompilerOptions.java
+ graal/com.oracle.truffle.api/src/com/oracle/truffle/api/ReplaceObserver.java
! graal/com.oracle.truffle.api/src/com/oracle/truffle/api/nodes/Node.java

Changeset: 5404cde63c43
Author:    Christos Kotselidis <christos.kotselidis at oracle.com>
Date:      2013-07-23 17:48 +0200
URL:       http://hg.openjdk.java.net/graal/graal/rev/5404cde63c43

Remove redundant checks for loading compressed constants

! 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/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/ReadNode.java

Changeset: 6457dc4227e3
Author:    Christos Kotselidis <christos.kotselidis at oracle.com>
Date:      2013-07-23 19:51 +0200
URL:       http://hg.openjdk.java.net/graal/graal/rev/6457dc4227e3

Add compressed klass pointers in gate

! src/share/vm/runtime/arguments.cpp

Changeset: 740789178ad8
Author:    Christos Kotselidis <christos.kotselidis at oracle.com>
Date:      2013-07-23 19:53 +0200
URL:       http://hg.openjdk.java.net/graal/graal/rev/740789178ad8

Merge

! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotRuntime.java

Changeset: df4d86530e21
Author:    Christos Kotselidis <christos.kotselidis at oracle.com>
Date:      2013-07-23 21:21 +0200
URL:       http://hg.openjdk.java.net/graal/graal/rev/df4d86530e21

Fix disclaimer

! src/share/vm/runtime/arguments.cpp

Changeset: 4ead4f35b91f
Author:    Andreas Woess <andreas.woess at jku.at>
Date:      2013-07-23 21:42 +0200
URL:       http://hg.openjdk.java.net/graal/graal/rev/4ead4f35b91f

Truffle: use loopAndInvokeCounter for replace backoff.

! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/OptimizedCallTarget.java
! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/TruffleCompilerOptions.java

Changeset: fa2fe7dd7a54
Author:    Doug Simon <doug.simon at oracle.com>
Date:      2013-07-23 23:24 +0200
URL:       http://hg.openjdk.java.net/graal/graal/rev/fa2fe7dd7a54

HSAIL backend changes
Contributed-by: Tom Deneau <tom.deneau at amd.com>

! graal/com.oracle.graal.asm.hsail/src/com/oracle/graal/asm/hsail/HSAILAssembler.java
! graal/com.oracle.graal.compiler.hsail.test/src/com/oracle/graal/compiler/hsail/test/Float2DMatrixMultiplyTest.java
+ graal/com.oracle.graal.compiler.hsail.test/src/com/oracle/graal/compiler/hsail/test/StringContainsAcceptTest.java
+ graal/com.oracle.graal.compiler.hsail.test/src/com/oracle/graal/compiler/hsail/test/StringContainsTest.java
+ graal/com.oracle.graal.compiler.hsail.test/src/com/oracle/graal/compiler/hsail/test/StringIndexOfTest.java
! graal/com.oracle.graal.lir.hsail/src/com/oracle/graal/lir/hsail/HSAILMove.java
! mx/projects


From doug.simon at oracle.com  Wed Jul 24 02:16:45 2013
From: doug.simon at oracle.com (Doug Simon)
Date: Wed, 24 Jul 2013 11:16:45 +0200
Subject: RFR: NewInstanceStub reads InstanceKlass::_init_state as int but
	is u1
In-Reply-To: <108A2038-4249-41F3-87A6-299F9185EBE5@oracle.com>
References: <FCA90C98-7EB6-4037-A176-C04D0CE3A86D@oracle.com>
	<108A2038-4249-41F3-87A6-299F9185EBE5@oracle.com>
Message-ID: <2FCF564D-1E38-4625-9B5F-F40D2D9FF2BB@oracle.com>

Looks good.

On Jul 24, 2013, at 3:23 AM, Christian Thalinger <christian.thalinger at oracle.com> wrote:

> Here are a couple more fixes to this code.  The threadAllocatedBytesOffset change is not really necessary but since it's defined as a long:
> 
>  jlong _allocated_bytes;                       // Cumulative number of bytes allocated on
> 
> we should read it as a long.
> 
> -- Chris
> 
> diff -r 6057d0168f47 graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/stubs/NewInstanceStub.java
> --- a/graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/stubs/NewInstanceStub.java	Tue Jul 23 12:27:06 2013 -0700
> +++ b/graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/stubs/NewInstanceStub.java	Tue Jul 23 18:20:38 2013 -0700
> @@ -89,7 +89,7 @@ public class NewInstanceStub extends Sni
>     private static Object newInstance(Word hub, @ConstantParameter Word intArrayHub) {
>         int sizeInBytes = hub.readInt(klassInstanceSizeOffset(), LocationIdentity.FINAL_LOCATION);
>         if (!forceSlowPath() && inlineContiguousAllocationSupported()) {
> -            if (hub.readInt(klassStateOffset(), CLASS_STATE_LOCATION) == klassStateFullyInitialized()) {
> +            if (hub.readByte(klassStateOffset(), CLASS_STATE_LOCATION) == klassStateFullyInitialized()) {
>                 Word memory = refillAllocate(intArrayHub, sizeInBytes, logging());
>                 if (memory.notEqual(0)) {
>                     Word prototypeMarkWord = hub.readWord(prototypeMarkWordOffset(), PROTOTYPE_MARK_WORD_LOCATION);
> @@ -137,21 +137,21 @@ public class NewInstanceStub extends Sni
>         Word end = readTlabEnd(thread);
> 
>         // calculate amount of free space
> -        Word tlabFreeSpaceInBytes = end.subtract(top);
> +        long tlabFreeSpaceInBytes = end.subtract(top).rawValue();
> 
>         if (log) {
>             printf("refillTLAB: thread=%p\n", thread.rawValue());
>             printf("refillTLAB: top=%p\n", top.rawValue());
>             printf("refillTLAB: end=%p\n", end.rawValue());
> -            printf("refillTLAB: tlabFreeSpaceInBytes=%d\n", tlabFreeSpaceInBytes.rawValue());
> +            printf("refillTLAB: tlabFreeSpaceInBytes=%ld\n", tlabFreeSpaceInBytes);
>         }
> 
> -        Word tlabFreeSpaceInWords = tlabFreeSpaceInBytes.unsignedShiftRight(log2WordSize());
> +        long tlabFreeSpaceInWords = tlabFreeSpaceInBytes >>> log2WordSize();
> 
>         // Retain TLAB and allocate object in shared space if
>         // the amount free in the TLAB is too large to discard.
>         Word refillWasteLimit = thread.readWord(tlabRefillWasteLimitOffset(), TLAB_REFILL_WASTE_LIMIT_LOCATION);
> -        if (tlabFreeSpaceInWords.belowOrEqual(refillWasteLimit)) {
> +        if (tlabFreeSpaceInWords <= refillWasteLimit.rawValue()) {
>             if (tlabStats()) {
>                 // increment number of refills
>                 thread.writeInt(tlabNumberOfRefillsOffset(), thread.readInt(tlabNumberOfRefillsOffset(), TLAB_NOF_REFILLS_LOCATION) + 1, TLAB_NOF_REFILLS_LOCATION);
> @@ -159,11 +159,11 @@ public class NewInstanceStub extends Sni
>                     printf("thread: %p -- number_of_refills %d\n", thread.rawValue(), thread.readInt(tlabNumberOfRefillsOffset(), TLAB_NOF_REFILLS_LOCATION));
>                 }
>                 // accumulate wastage
> -                Word wastage = thread.readWord(tlabFastRefillWasteOffset(), TLAB_FAST_REFILL_WASTE_LOCATION).add(tlabFreeSpaceInWords);
> +                int wastage = thread.readInt(tlabFastRefillWasteOffset(), TLAB_FAST_REFILL_WASTE_LOCATION) + (int) tlabFreeSpaceInWords;
>                 if (log) {
> -                    printf("thread: %p -- accumulated wastage %d\n", thread.rawValue(), wastage.rawValue());
> +                    printf("thread: %p -- accumulated wastage %d\n", thread.rawValue(), wastage);
>                 }
> -                thread.writeWord(tlabFastRefillWasteOffset(), wastage, TLAB_FAST_REFILL_WASTE_LOCATION);
> +                thread.writeInt(tlabFastRefillWasteOffset(), wastage, TLAB_FAST_REFILL_WASTE_LOCATION);
>             }
> 
>             // if TLAB is currently allocated (top or end != null) then
> @@ -172,13 +172,13 @@ public class NewInstanceStub extends Sni
>                 int headerSize = arrayBaseOffset(Kind.Int);
>                 // just like the HotSpot assembler stubs, assumes that tlabFreeSpaceInInts fits in
>                 // an int
> -                int tlabFreeSpaceInInts = (int) tlabFreeSpaceInBytes.rawValue() >>> 2;
> +                int tlabFreeSpaceInInts = (int) tlabFreeSpaceInBytes >>> 2;
>                 int length = ((alignmentReserveInBytes - headerSize) >>> 2) + tlabFreeSpaceInInts;
>                 NewObjectSnippets.formatArray(intArrayHub, -1, length, headerSize, top, intArrayMarkWord, false);
> 
> -                Word allocated = thread.readWord(threadAllocatedBytesOffset(), TLAB_THREAD_ALLOCATED_BYTES_LOCATION);
> -                allocated = allocated.add(top.subtract(readTlabStart(thread)));
> -                thread.writeWord(threadAllocatedBytesOffset(), allocated, TLAB_THREAD_ALLOCATED_BYTES_LOCATION);
> +                long allocated = thread.readLong(threadAllocatedBytesOffset(), TLAB_THREAD_ALLOCATED_BYTES_LOCATION);
> +                allocated = allocated + top.subtract(readTlabStart(thread)).rawValue();
> +                thread.writeLong(threadAllocatedBytesOffset(), allocated, TLAB_THREAD_ALLOCATED_BYTES_LOCATION);
>             }
> 
>             // refill the TLAB with an eden allocation
> 
> On Jul 23, 2013, at 2:09 PM, Christian Thalinger <christian.thalinger at oracle.com> wrote:
> 
>> _init_state is defined as u1 in InstanceKlass:
>> 
>> u1              _init_state;                    // state of class
>> 
>> but is read as int in newInstance:
>> 
>> diff -r 6057d0168f47 graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/stubs/NewInstanceStub.java
>> --- a/graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/stubs/NewInstanceStub.java	Tue Jul 23 12:27:06 2013 -0700
>> +++ b/graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/stubs/NewInstanceStub.java	Tue Jul 23 14:06:49 2013 -0700
>> @@ -89,7 +89,7 @@ public class NewInstanceStub extends Sni
>>    private static Object newInstance(Word hub, @ConstantParameter Word intArrayHub) {
>>        int sizeInBytes = hub.readInt(klassInstanceSizeOffset(), LocationIdentity.FINAL_LOCATION);
>>        if (!forceSlowPath() && inlineContiguousAllocationSupported()) {
>> -            if (hub.readInt(klassStateOffset(), CLASS_STATE_LOCATION) == klassStateFullyInitialized()) {
>> +            if (hub.readByte(klassStateOffset(), CLASS_STATE_LOCATION) == klassStateFullyInitialized()) {
>>                Word memory = refillAllocate(intArrayHub, sizeInBytes, logging());
>>                if (memory.notEqual(0)) {
>>                    Word prototypeMarkWord = hub.readWord(prototypeMarkWordOffset(), PROTOTYPE_MARK_WORD_LOCATION);
>> 
>> -- Chris
> 


From java at stefan-marr.de  Wed Jul 24 09:16:44 2013
From: java at stefan-marr.de (Stefan Marr)
Date: Wed, 24 Jul 2013 18:16:44 +0200
Subject: Debugging NPE during CanonicalizerPhase
Message-ID: <291DC66B-3E46-4B44-BBD6-A7B3DEA828D3@stefan-marr.de>

Hi:

I am trying to debug an NPE I get while running TruffleSOM on top of Graal.

Would be great if someone could give me a hint, how to debug it.

For a bit of context, I got the latest Graal code checked out and compiled for debugging.
The invocation looks like this:
  /mx.sh -d --debug --vm server vm -G:+DumpOnError -Xbootclasspath/a:../som/build/classes som.vm.Universe -cp ../TruffleSOM/Smalltalk ../TruffleSOM/Examples/Benchmarks/Loop.som

With a connected Eclipse, I was able to figure out that a FrameGetNode has a value for `slot` that is a ConstantNode with the value null (i.e. slot.asConstant().isNull() == true).

Now I am a bit stuck, because it looks like the FrameGetNode is never actually instantiated with such a ConstantNode object for the slot field, so I assume, it is changed somewhere later. However, I have no clue where that might happen.

What also confuses me is that there is no setter for the slot field, and ConstantNode as well as Constant look rather immutable to me.

I have the feeling I am missing something rather basic here.
Any hints would be highly appreciated.

Thanks
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 christian.wimmer at oracle.com  Wed Jul 24 19:03:41 2013
From: christian.wimmer at oracle.com (Christian Wimmer)
Date: Wed, 24 Jul 2013 19:03:41 -0700
Subject: destroysCallerSavedRegisters and register reference map in
	DebugInfo
In-Reply-To: <8D12919B-8E9F-407F-BBBC-A5EF0245D6C8@oracle.com>
References: <2B171F5D-D883-4359-9912-115ADCFB6C6B@oracle.com>
	<8D12919B-8E9F-407F-BBBC-A5EF0245D6C8@oracle.com>
Message-ID: <51F0877D.8020004@oracle.com>

[summary of a chat with Chris today]

>> Quick question about this code in LinearScan:
>>
>>     private void computeDebugInfo(IntervalWalker iw, final LIRInstruction op, LIRFrameState info) {
>>         BitSet registerRefMap = op.destroysCallerSavedRegisters() ? null : frameMap.initRegisterRefMap();
>>         BitSet frameRefMap = frameMap.initFrameRefMap();
>>         computeOopMap(iw, op, registerRefMap, frameRefMap);
>>
>> Why are we not creating a register reference map if we destroy caller saved registers?
>
> Because all live registers will be spilled around the call and so there are no live values in registers during the call.

This is only true for X86, not for SPARC.

>>   I'm having trouble with this logic on SPARC because computeOopMap wants to store a register in the map (a local register).
>
> Wouldn't we just ensure that op.destroysCallerSavedRegisters() returns false for all SPARC ops (given that local registers are never killed by a callee)?

This does not work. destroysCallerSavedRegisters is the trigger in the 
register allocator to spill before a call: A short temporary life range 
is generated for every caller save register for every LIR instruction 
that returns true. If you return false, no register will be saved at the 
call site.

>> Would there be a downside if we always would create and empty map and just pass it on except a little bit of overhead?

For SPARC, are register reference map is needed for every call site.

So instead of

   BitSet registerRefMap = op.destroysCallerSavedRegisters() ? null : 
frameMap.initRegisterRefMap();

you need something like

   BitSet registerRefMap = op.destroysCallerSavedRegisters() && 
callKillsRegisters ? null : frameMap.initRegisterRefMap();

callKillsRegisters is defined in the LinearScanWalker, so that 
information is not too far away


-Christian

From doug.simon at oracle.com  Thu Jul 25 00:59:20 2013
From: doug.simon at oracle.com (Doug Simon)
Date: Thu, 25 Jul 2013 09:59:20 +0200
Subject: destroysCallerSavedRegisters and register reference map in
	DebugInfo
In-Reply-To: <51F0877D.8020004@oracle.com>
References: <2B171F5D-D883-4359-9912-115ADCFB6C6B@oracle.com>
	<8D12919B-8E9F-407F-BBBC-A5EF0245D6C8@oracle.com>
	<51F0877D.8020004@oracle.com>
Message-ID: <E905F4C2-C0C7-467D-8C5F-40FF53632A51@oracle.com>

Thanks Christian. I wasn't too sure about the right solution to handle SPARC correctly. We never got the SPARC backend done for C1X in Maxine so this is new territory for Graal.

-Doug

On Jul 25, 2013, at 4:03 AM, Christian Wimmer <christian.wimmer at oracle.com> wrote:

> [summary of a chat with Chris today]
> 
>>> Quick question about this code in LinearScan:
>>> 
>>>    private void computeDebugInfo(IntervalWalker iw, final LIRInstruction op, LIRFrameState info) {
>>>        BitSet registerRefMap = op.destroysCallerSavedRegisters() ? null : frameMap.initRegisterRefMap();
>>>        BitSet frameRefMap = frameMap.initFrameRefMap();
>>>        computeOopMap(iw, op, registerRefMap, frameRefMap);
>>> 
>>> Why are we not creating a register reference map if we destroy caller saved registers?
>> 
>> Because all live registers will be spilled around the call and so there are no live values in registers during the call.
> 
> This is only true for X86, not for SPARC.
> 
>>>  I'm having trouble with this logic on SPARC because computeOopMap wants to store a register in the map (a local register).
>> 
>> Wouldn't we just ensure that op.destroysCallerSavedRegisters() returns false for all SPARC ops (given that local registers are never killed by a callee)?
> 
> This does not work. destroysCallerSavedRegisters is the trigger in the register allocator to spill before a call: A short temporary life range is generated for every caller save register for every LIR instruction that returns true. If you return false, no register will be saved at the call site.
> 
>>> Would there be a downside if we always would create and empty map and just pass it on except a little bit of overhead?
> 
> For SPARC, are register reference map is needed for every call site.
> 
> So instead of
> 
>  BitSet registerRefMap = op.destroysCallerSavedRegisters() ? null : frameMap.initRegisterRefMap();
> 
> you need something like
> 
>  BitSet registerRefMap = op.destroysCallerSavedRegisters() && callKillsRegisters ? null : frameMap.initRegisterRefMap();
> 
> callKillsRegisters is defined in the LinearScanWalker, so that information is not too far away
> 
> 
> -Christian


From christian.thalinger at oracle.com  Thu Jul 25 09:07:38 2013
From: christian.thalinger at oracle.com (Christian Thalinger)
Date: Thu, 25 Jul 2013 09:07:38 -0700
Subject: destroysCallerSavedRegisters and register reference map in
	DebugInfo
In-Reply-To: <E905F4C2-C0C7-467D-8C5F-40FF53632A51@oracle.com>
References: <2B171F5D-D883-4359-9912-115ADCFB6C6B@oracle.com>
	<8D12919B-8E9F-407F-BBBC-A5EF0245D6C8@oracle.com>
	<51F0877D.8020004@oracle.com>
	<E905F4C2-C0C7-467D-8C5F-40FF53632A51@oracle.com>
Message-ID: <C9806B0D-6EDF-4E36-82E9-E7F579E0BC77@oracle.com>

Yes, thanks, Christian, for summing it up here.  I'm not sure yet how I get to callKillsRegisters; I might have to store it somewhere else.  With having a register reference map the allocations are good now.

-- Chris

On Jul 25, 2013, at 12:59 AM, Doug Simon <doug.simon at oracle.com> wrote:

> Thanks Christian. I wasn't too sure about the right solution to handle SPARC correctly. We never got the SPARC backend done for C1X in Maxine so this is new territory for Graal.
> 
> -Doug
> 
> On Jul 25, 2013, at 4:03 AM, Christian Wimmer <christian.wimmer at oracle.com> wrote:
> 
>> [summary of a chat with Chris today]
>> 
>>>> Quick question about this code in LinearScan:
>>>> 
>>>>   private void computeDebugInfo(IntervalWalker iw, final LIRInstruction op, LIRFrameState info) {
>>>>       BitSet registerRefMap = op.destroysCallerSavedRegisters() ? null : frameMap.initRegisterRefMap();
>>>>       BitSet frameRefMap = frameMap.initFrameRefMap();
>>>>       computeOopMap(iw, op, registerRefMap, frameRefMap);
>>>> 
>>>> Why are we not creating a register reference map if we destroy caller saved registers?
>>> 
>>> Because all live registers will be spilled around the call and so there are no live values in registers during the call.
>> 
>> This is only true for X86, not for SPARC.
>> 
>>>> I'm having trouble with this logic on SPARC because computeOopMap wants to store a register in the map (a local register).
>>> 
>>> Wouldn't we just ensure that op.destroysCallerSavedRegisters() returns false for all SPARC ops (given that local registers are never killed by a callee)?
>> 
>> This does not work. destroysCallerSavedRegisters is the trigger in the register allocator to spill before a call: A short temporary life range is generated for every caller save register for every LIR instruction that returns true. If you return false, no register will be saved at the call site.
>> 
>>>> Would there be a downside if we always would create and empty map and just pass it on except a little bit of overhead?
>> 
>> For SPARC, are register reference map is needed for every call site.
>> 
>> So instead of
>> 
>> BitSet registerRefMap = op.destroysCallerSavedRegisters() ? null : frameMap.initRegisterRefMap();
>> 
>> you need something like
>> 
>> BitSet registerRefMap = op.destroysCallerSavedRegisters() && callKillsRegisters ? null : frameMap.initRegisterRefMap();
>> 
>> callKillsRegisters is defined in the LinearScanWalker, so that information is not too far away
>> 
>> 
>> -Christian
> 


From christian.wimmer at oracle.com  Thu Jul 25 12:08:47 2013
From: christian.wimmer at oracle.com (Christian Wimmer)
Date: Thu, 25 Jul 2013 12:08:47 -0700
Subject: destroysCallerSavedRegisters and register reference map in
	DebugInfo
In-Reply-To: <C9806B0D-6EDF-4E36-82E9-E7F579E0BC77@oracle.com>
References: <2B171F5D-D883-4359-9912-115ADCFB6C6B@oracle.com>
	<8D12919B-8E9F-407F-BBBC-A5EF0245D6C8@oracle.com>
	<51F0877D.8020004@oracle.com>
	<E905F4C2-C0C7-467D-8C5F-40FF53632A51@oracle.com>
	<C9806B0D-6EDF-4E36-82E9-E7F579E0BC77@oracle.com>
Message-ID: <51F177BF.4040701@oracle.com>



On 07/25/2013 09:07 AM, Christian Thalinger wrote:
> Yes, thanks, Christian, for summing it up here.  I'm not sure yet how I get to callKillsRegisters; I might have to store it somewhere else.

Should be easy to move it from LinearScanWalker to LinearScan, to make 
it available everywhere.

-Christian

From christian.thalinger at oracle.com  Thu Jul 25 12:21:08 2013
From: christian.thalinger at oracle.com (Christian Thalinger)
Date: Thu, 25 Jul 2013 12:21:08 -0700
Subject: CTW OOM
Message-ID: <BB90C853-A2B6-4F34-A0F6-5CAAF54A7EAC@oracle.com>

This is something I haven't seen before.  Does anyone know where this is coming from?

cthaling at macbook:/tmp/graal$ java -XX:+CompileTheWorld -Xbootclasspath/p:$JAVA_HOME/jre/lib/rt.jar -XX:CompileTheWorldStopAt=10
Bootstrapping Graal......................................... in 51313 ms
CompileTheWorld : Compiling all classes in /Users/cthaling/build//tmp/graal/jdk-universal/jre/lib/rt.jar

CompileTheWorld (1) : WrapperGenerator$1
CompileTheWorld (2) : WrapperGenerator$AtomicType
CompileTheWorld (3) : WrapperGenerator$BaseType
CompileTheWorld (4) : WrapperGenerator$FunctionType
CompileTheWorld (5) : WrapperGenerator$StructType
CompileTheWorld (6) : WrapperGenerator
scope: Compiling.GraalCompiler.FrontEnd.ComputeLinearScanOrder.InterceptException
Exception occurred in scope: Compiling.GraalCompiler.FrontEnd.ComputeLinearScanOrder.InterceptException
Context obj java.lang.OutOfMemoryError: Java heap space
Context obj StructuredGraph:59280{HotSpotMethod<WrapperGenerator.writeFunctionCallWrapper(String, WrapperGenerator$FunctionType)>}
Use -G:+DumpOnError to enable dumping of graphs on this error
Context obj com.oracle.graal.hotspot.amd64.AMD64HotSpotRuntime at 48b03ec
Context obj DebugDumpScope[4337]
CompileTheWorld (7) : apple/applescript/AppleScriptEngine
CompileTheWorld (8) : apple/applescript/AppleScriptEngineFactory$1
CompileTheWorld (9) : apple/applescript/AppleScriptEngineFactory
CompileTheWorld (10) : apple/laf/AquaLookAndFeel
CompileTheWorld : Compiling all classes in /Users/cthaling/build/tmp/graal/jdk-universal/jre/lib/resources.jar


CompileTheWorld : Done (10 classes, 124 methods, 23597 ms)


From miguelalfredo.garcia at epfl.ch  Thu Jul 25 13:32:16 2013
From: miguelalfredo.garcia at epfl.ch (Garcia Gutierrez Miguel Alfredo)
Date: Thu, 25 Jul 2013 20:32:16 +0000
Subject: escapa analysis, packed objects
Message-ID: <7E4228B446372948BBB2916FC53FA49E26DDE258@rexma.intranet.epfl.ch>


Hi,

Escape analysis in Graal looks interesting. Are there any publications describing it? What I've heard about is:

  (1) Jong-Deok Shoi et al. https://wikis.oracle.com/display/HotSpotInternals/EscapeAnalysis

  (2) EA in the client compiler, http://ssw.jku.at/General/Staff/TK/Research/Publications/



Another question, this time looking into the future. Approaches have been put forward to support "structs in the JVM", things like:

  packed objects, http://www.slideshare.net/mmitran/ibm-java-packed-objects-mmit-20121120

  http://openjdk.java.net/jeps/169

What about Graal? For example, the use case "method returns a struct", would HotSpot stand in the way, or can LIR be tweaked to realize that? I know it's a slippery topic, but comments are welcome! :)


Miguel

--
Miguel Garcia
Swiss Federal Institute of Technology
EPFL - IC - LAMP1 - INR 328 - Station 14
CH-1015 Lausanne - Switzerland
http://lamp.epfl.ch/~magarcia/

From lukas.stadler at jku.at  Fri Jul 26 11:24:53 2013
From: lukas.stadler at jku.at (Lukas Stadler)
Date: Fri, 26 Jul 2013 11:24:53 -0700
Subject: escapa analysis, packed objects
In-Reply-To: <7E4228B446372948BBB2916FC53FA49E26DDE258@rexma.intranet.epfl.ch>
References: <7E4228B446372948BBB2916FC53FA49E26DDE258@rexma.intranet.epfl.ch>
Message-ID: <24AA1B5D-395F-45C9-B7AF-C4BCCE1F34A7@jku.at>

Hi Miguel,

unfortunately there's no documentation on Graal's partial escape analysis yet.
A short intro is available here: https://wiki.openjdk.java.net/display/Graal/Graal+Partial+Escape+Analysis
I'm currently working on a publication on this topic, I'd be happy to send you a version of it as soon as it's complete enough to make sense :-)
I also could give you an introduction over skype.

Concerning the "structs" proposals:
The IBM proposal seems to be mostly about how to interact with the C world, like a convenient wrapper around sun.misc.Unsafe.
I think that John Rose's proposal is more interesting, especially since the locking mechanism allows partial escape analysis to work much more efficiently.
(We actually already do a similar trick for boxing operations, so we could take advantage of this mechanism pretty quickly)

Much of this can be handled by the compiler, but of course it's only part of the picture. Allowing structs as return values means that this needs to be handled correctly by the interpreter, by deoptimization, by stack walking, in the debug interface, in jni code, etc.
I think it's too big a task (and too many VM changes) for us to do, but once this proposal gets picked up by the hotspot team, we can quickly provide efficient support for it.

- Lukas

On Jul 25, 2013, at 13:32 , Garcia Gutierrez Miguel Alfredo <miguelalfredo.garcia at epfl.ch> wrote:

> 
> Hi,
> 
> Escape analysis in Graal looks interesting. Are there any publications describing it? What I've heard about is:
> 
>  (1) Jong-Deok Shoi et al. https://wikis.oracle.com/display/HotSpotInternals/EscapeAnalysis
> 
>  (2) EA in the client compiler, http://ssw.jku.at/General/Staff/TK/Research/Publications/
> 
> 
> 
> Another question, this time looking into the future. Approaches have been put forward to support "structs in the JVM", things like:
> 
>  packed objects, http://www.slideshare.net/mmitran/ibm-java-packed-objects-mmit-20121120
> 
>  http://openjdk.java.net/jeps/169
> 
> What about Graal? For example, the use case "method returns a struct", would HotSpot stand in the way, or can LIR be tweaked to realize that? I know it's a slippery topic, but comments are welcome! :)
> 
> 
> Miguel
> 
> --
> Miguel Garcia
> Swiss Federal Institute of Technology
> EPFL - IC - LAMP1 - INR 328 - Station 14
> CH-1015 Lausanne - Switzerland
> http://lamp.epfl.ch/~magarcia/


From miguelalfredo.garcia at epfl.ch  Sat Jul 27 03:42:48 2013
From: miguelalfredo.garcia at epfl.ch (Garcia Gutierrez Miguel Alfredo)
Date: Sat, 27 Jul 2013 10:42:48 +0000
Subject: Escape Analysis and MH.invoke, MH.invokeExact
Message-ID: <7E4228B446372948BBB2916FC53FA49E26DDE397@rexma.intranet.epfl.ch>

Lukas,

Thanks for the link, that overview is quite helpful. For the moment I'm just wading through the info deluge of PEA and its interplay with inlining.

I was wondering whether it could pay off to make (Partial) EA handle specially the "escaping behavior" of a MethodHandle instance wrt invoke (resp. invokeExact). From what I've seen, the receiver of an instance-method invocation is deemed method-escaping. However it appears that (conceptually) the EA analysis could special-case MH.invoke() and MH.invokeExact() callsites, by not concluding "receiver escapes" for them. Perhaps this heuristic could enable other optimizations.

All of the above of course with the big disclaimer that I'm not that familiar with EA, and without knowing for sure whether an implementation of MH.invoke, MH.invokeExact could (somehow) let "this" escape.


Miguel
--
Miguel Garcia
Swiss Federal Institute of Technology
EPFL - IC - LAMP1 - INR 328 - Station 14
CH-1015 Lausanne - Switzerland
http://lamp.epfl.ch/~magarcia/

________________________________________
From: Lukas Stadler [lukas.stadler at jku.at]
Sent: Friday, July 26, 2013 8:24 PM
To: Garcia Gutierrez Miguel Alfredo
Cc: graal-dev at openjdk.java.net
Subject: Re: escapa analysis, packed objects

Hi Miguel,

unfortunately there's no documentation on Graal's partial escape analysis yet.
A short intro is available here: https://wiki.openjdk.java.net/display/Graal/Graal+Partial+Escape+Analysis
I'm currently working on a publication on this topic, I'd be happy to send you a version of it as soon as it's complete enough to make sense :-)
I also could give you an introduction over skype.

Concerning the "structs" proposals:
The IBM proposal seems to be mostly about how to interact with the C world, like a convenient wrapper around sun.misc.Unsafe.
I think that John Rose's proposal is more interesting, especially since the locking mechanism allows partial escape analysis to work much more efficiently.
(We actually already do a similar trick for boxing operations, so we could take advantage of this mechanism pretty quickly)

Much of this can be handled by the compiler, but of course it's only part of the picture. Allowing structs as return values means that this needs to be handled correctly by the interpreter, by deoptimization, by stack walking, in the debug interface, in jni code, etc.
I think it's too big a task (and too many VM changes) for us to do, but once this proposal gets picked up by the hotspot team, we can quickly provide efficient support for it.

- Lukas

On Jul 25, 2013, at 13:32 , Garcia Gutierrez Miguel Alfredo <miguelalfredo.garcia at epfl.ch> wrote:

>
> Hi,
>
> Escape analysis in Graal looks interesting. Are there any publications describing it? What I've heard about is:
>
>  (1) Jong-Deok Shoi et al. https://wikis.oracle.com/display/HotSpotInternals/EscapeAnalysis
>
>  (2) EA in the client compiler, http://ssw.jku.at/General/Staff/TK/Research/Publications/
>
>
>
> Another question, this time looking into the future. Approaches have been put forward to support "structs in the JVM", things like:
>
>  packed objects, http://www.slideshare.net/mmitran/ibm-java-packed-objects-mmit-20121120
>
>  http://openjdk.java.net/jeps/169
>
> What about Graal? For example, the use case "method returns a struct", would HotSpot stand in the way, or can LIR be tweaked to realize that? I know it's a slippery topic, but comments are welcome! :)
>
>
> Miguel
>
> --
> Miguel Garcia
> Swiss Federal Institute of Technology
> EPFL - IC - LAMP1 - INR 328 - Station 14
> CH-1015 Lausanne - Switzerland
> http://lamp.epfl.ch/~magarcia/


From doug.simon at oracle.com  Sat Jul 27 18:00:14 2013
From: doug.simon at oracle.com (doug.simon at oracle.com)
Date: Sun, 28 Jul 2013 01:00:14 +0000
Subject: hg: graal/graal: 31 new changesets
Message-ID: <20130728010219.27CB24841F@hg.openjdk.java.net>

Changeset: 3ad7c15c2623
Author:    twisti
Date:      2013-07-24 15:07 -0700
URL:       http://hg.openjdk.java.net/graal/graal/rev/3ad7c15c2623

Some Klass and InstanceKlass fields were read with a wrong size.

! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/stubs/NewInstanceStub.java

Changeset: 886c2df7a7e4
Author:    twisti
Date:      2013-07-24 16:19 -0700
URL:       http://hg.openjdk.java.net/graal/graal/rev/886c2df7a7e4

Stubs need both an outgoing and incoming calling convention.

! graal/com.oracle.graal.api.code/src/com/oracle/graal/api/code/ForeignCallLinkage.java
! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/gen/LIRGenerator.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/AMD64HotSpotRuntime.java
! graal/com.oracle.graal.hotspot.amd64/src/com/oracle/graal/hotspot/amd64/AMD64HotSpotUnwindOp.java
! graal/com.oracle.graal.hotspot.sparc/src/com/oracle/graal/hotspot/sparc/SPARCHotSpotLIRGenerator.java
! graal/com.oracle.graal.hotspot.sparc/src/com/oracle/graal/hotspot/sparc/SPARCHotSpotRuntime.java
! graal/com.oracle.graal.hotspot.sparc/src/com/oracle/graal/hotspot/sparc/SPARCHotSpotUnwindOp.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
! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/stubs/ForeignCallStub.java
! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/stubs/Stub.java

Changeset: c3b09d69dfde
Author:    twisti
Date:      2013-07-24 17:57 -0700
URL:       http://hg.openjdk.java.net/graal/graal/rev/c3b09d69dfde

SPARC: fixes and more implementation; can now allocate objects

! 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.asm.sparc/src/com/oracle/graal/asm/sparc/SPARCMacroAssembler.java
! graal/com.oracle.graal.compiler.sparc/src/com/oracle/graal/compiler/sparc/SPARCLIRGenerator.java
+ graal/com.oracle.graal.hotspot.sparc/src/com/oracle/graal/hotspot/sparc/SPARCDeoptimizeOp.java
+ graal/com.oracle.graal.hotspot.sparc/src/com/oracle/graal/hotspot/sparc/SPARCHotSpotCRuntimeCallEpilogueOp.java
+ graal/com.oracle.graal.hotspot.sparc/src/com/oracle/graal/hotspot/sparc/SPARCHotSpotCRuntimeCallPrologueOp.java
! graal/com.oracle.graal.hotspot.sparc/src/com/oracle/graal/hotspot/sparc/SPARCHotSpotLIRGenerator.java
! graal/com.oracle.graal.hotspot.sparc/src/com/oracle/graal/hotspot/sparc/SPARCHotSpotPatchReturnAddressOp.java
! graal/com.oracle.graal.hotspot.sparc/src/com/oracle/graal/hotspot/sparc/SPARCHotSpotRegisterConfig.java
! graal/com.oracle.graal.hotspot.sparc/src/com/oracle/graal/hotspot/sparc/SPARCSafepointOp.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/SPARCCall.java
! graal/com.oracle.graal.lir.sparc/src/com/oracle/graal/lir/sparc/SPARCControlFlow.java
! src/cpu/sparc/vm/graalCodeInstaller_sparc.hpp

Changeset: 33a2ca7c3bc8
Author:    Roland Schatz <roland.schatz at oracle.com>
Date:      2013-07-25 11:50 +0200
URL:       http://hg.openjdk.java.net/graal/graal/rev/33a2ca7c3bc8

Support for byte fields in LIR instructions.

! graal/com.oracle.graal.lir/src/com/oracle/graal/lir/LIRIntrospection.java

Changeset: de55425d3cf5
Author:    Doug Simon <doug.simon at oracle.com>
Date:      2013-07-25 11:34 +0200
URL:       http://hg.openjdk.java.net/graal/graal/rev/de55425d3cf5

small cleanups and extra documentation around foreign call linkage

! 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/AMD64HotSpotRuntime.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: 191a9e4a2d2c
Author:    Doug Simon <doug.simon at oracle.com>
Date:      2013-07-25 12:42 +0200
URL:       http://hg.openjdk.java.net/graal/graal/rev/191a9e4a2d2c

Merge.


Changeset: 27ba48dffab6
Author:    Christian Wirth <christian.wirth at oracle.com>
Date:      2013-07-25 13:52 +0200
URL:       http://hg.openjdk.java.net/graal/graal/rev/27ba48dffab6

Increase TruffleGraphMaxNodes to 15000

! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/TruffleCompilerOptions.java

Changeset: bf50b5daf874
Author:    Andreas Woess <andreas.woess at jku.at>
Date:      2013-07-25 19:22 +0200
URL:       http://hg.openjdk.java.net/graal/graal/rev/bf50b5daf874

FrameWithoutBoxing: make substitutions forced, use unsafeCast from CompilerDirectives.

! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/FrameWithoutBoxing.java
! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/substitutions/FrameWithoutBoxingSubstitutions.java

Changeset: b4e7f15cebe6
Author:    Lukas Stadler <lukas.stadler at jku.at>
Date:      2013-07-25 18:01 -0700
URL:       http://hg.openjdk.java.net/graal/graal/rev/b4e7f15cebe6

don't create InstanceOfNodes with different profiles during CheckCastNode lowering

! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/java/CheckCastNode.java

Changeset: d9fcc82766da
Author:    Lukas Stadler <lukas.stadler at jku.at>
Date:      2013-07-25 18:02 -0700
URL:       http://hg.openjdk.java.net/graal/graal/rev/d9fcc82766da

disable compilation statistics for benchmarks

! mx/sanitycheck.py

Changeset: d55f24eac4b1
Author:    Morris Meyer <morris.meyer at oracle.com>
Date:      2013-07-25 22:15 -0400
URL:       http://hg.openjdk.java.net/graal/graal/rev/d55f24eac4b1

PTX support for Linux

! graal/com.oracle.graal.compiler.ptx.test/src/com/oracle/graal/compiler/ptx/test/BasicPTXTest.java
! graal/com.oracle.graal.compiler.ptx/src/com/oracle/graal/compiler/ptx/PTXBackend.java
! make/bsd/makefiles/buildtree.make
! make/bsd/makefiles/vm.make
! make/linux/makefiles/buildtree.make
! make/linux/makefiles/vm.make
- src/gpu/ptx/gpu_ptx.cpp
- src/gpu/ptx/gpu_ptx.hpp
+ src/gpu/ptx/vm/gpu_ptx.cpp
+ src/gpu/ptx/vm/gpu_ptx.hpp
- src/os/bsd/vm/gpu_bsd.cpp
- src/os/bsd/vm/gpu_bsd.hpp
+ src/os_gpu/bsd_ptx/vm/gpu_bsd.cpp
+ src/os_gpu/bsd_ptx/vm/gpu_bsd.hpp
+ src/os_gpu/linux_ptx/vm/gpu_linux.cpp
+ src/os_gpu/linux_ptx/vm/gpu_linux.hpp
! src/share/vm/code/nmethod.cpp
! src/share/vm/graal/graalCompilerToGPU.cpp
! src/share/vm/graal/graalCompilerToVM.cpp
! src/share/vm/runtime/globals.hpp
! src/share/vm/runtime/gpu.cpp
! src/share/vm/runtime/gpu.hpp
! src/share/vm/runtime/thread.cpp

Changeset: 7bd19a37f764
Author:    Morris Meyer <morris.meyer at oracle.com>
Date:      2013-07-25 22:17 -0400
URL:       http://hg.openjdk.java.net/graal/graal/rev/7bd19a37f764

PTX support for Linux

! graal/com.oracle.graal.compiler.ptx/src/com/oracle/graal/compiler/ptx/PTXBackend.java

Changeset: f9215ee02538
Author:    Morris Meyer <morris.meyer at oracle.com>
Date:      2013-07-25 22:20 -0400
URL:       http://hg.openjdk.java.net/graal/graal/rev/f9215ee02538

PTX support for Linux

! graal/com.oracle.graal.compiler.ptx/src/com/oracle/graal/compiler/ptx/PTXBackend.java

Changeset: 6a2d65cb5d7d
Author:    Christian Wirth <christian.wirth at oracle.com>
Date:      2013-07-26 11:22 +0200
URL:       http://hg.openjdk.java.net/graal/graal/rev/6a2d65cb5d7d

fix: gpu_ptx.cpp did not compile on windows

! src/gpu/ptx/vm/gpu_ptx.cpp

Changeset: 5fcb30bcb90a
Author:    Roland Schatz <roland.schatz at oracle.com>
Date:      2013-07-26 11:47 +0200
URL:       http://hg.openjdk.java.net/graal/graal/rev/5fcb30bcb90a

Fix compilation without precompiled headers.

! src/gpu/ptx/vm/gpu_ptx.cpp

Changeset: fe49e5121768
Author:    Roland Schatz <roland.schatz at oracle.com>
Date:      2013-07-26 12:09 +0200
URL:       http://hg.openjdk.java.net/graal/graal/rev/fe49e5121768

Remove CUDA message at vm startup.

! src/gpu/ptx/vm/gpu_ptx.cpp

Changeset: 3f43462ce829
Author:    Roland Schatz <roland.schatz at oracle.com>
Date:      2013-07-26 12:10 +0200
URL:       http://hg.openjdk.java.net/graal/graal/rev/3f43462ce829

Work around missing support for boolean[] in junit.

! graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/GraalCompilerTest.java

Changeset: 1b800f44ac0c
Author:    Andreas Woess <andreas.woess at jku.at>
Date:      2013-07-26 16:53 +0200
URL:       http://hg.openjdk.java.net/graal/graal/rev/1b800f44ac0c

Make HotSpotNmethod class final and set it as declared type of OptimizedCallTarget.compiledMethod.

! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotNmethod.java
! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/OptimizedCallTarget.java

Changeset: f11a4e137aed
Author:    Doug Simon <doug.simon at oracle.com>
Date:      2013-07-26 19:48 +0200
URL:       http://hg.openjdk.java.net/graal/graal/rev/f11a4e137aed

fix spelling

! graal/com.oracle.graal.jtt/src/com/oracle/graal/jtt/JTTTest.java

Changeset: 406d9b8bf040
Author:    Doug Simon <doug.simon at oracle.com>
Date:      2013-07-26 19:49 +0200
URL:       http://hg.openjdk.java.net/graal/graal/rev/406d9b8bf040

made it possible for a MacroNode to be lowered via a standard method substitution

! graal/com.oracle.graal.replacements/src/com/oracle/graal/replacements/nodes/MacroNode.java

Changeset: a9225e3678aa
Author:    Doug Simon <doug.simon at oracle.com>
Date:      2013-07-26 19:49 +0200
URL:       http://hg.openjdk.java.net/graal/graal/rev/a9225e3678aa

added macro node for Class.isInstance

+ graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/nodes/ClassIsInstanceNode.java
! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/ClassSubstitutions.java
+ graal/com.oracle.graal.jtt/src/com/oracle/graal/jtt/lang/Class_isInstance07.java

Changeset: 2cdd22e1ac5e
Author:    Bernhard Urban <bernhard.urban at jku.at>
Date:      2013-07-26 20:18 +0200
URL:       http://hg.openjdk.java.net/graal/graal/rev/2cdd22e1ac5e

SchedulingPhase: check if fixed nodes have the same order before and after sorting a block

! graal/com.oracle.graal.phases/src/com/oracle/graal/phases/schedule/SchedulePhase.java

Changeset: 8c0ab217ed00
Author:    Bernhard Urban <bernhard.urban at jku.at>
Date:      2013-07-26 20:18 +0200
URL:       http://hg.openjdk.java.net/graal/graal/rev/8c0ab217ed00

Scheduling: remove dead code in addToLatestSorting

! graal/com.oracle.graal.phases/src/com/oracle/graal/phases/schedule/SchedulePhase.java

Changeset: caa8706c6202
Author:    Bernhard Urban <bernhard.urban at jku.at>
Date:      2013-07-26 20:18 +0200
URL:       http://hg.openjdk.java.net/graal/graal/rev/caa8706c6202

CFG: attach proxies to loop exits

! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/cfg/ControlFlowGraph.java
! graal/com.oracle.graal.phases/src/com/oracle/graal/phases/schedule/SchedulePhase.java

Changeset: 968215f13aad
Author:    Bernhard Urban <bernhard.urban at jku.at>
Date:      2013-07-26 20:18 +0200
URL:       http://hg.openjdk.java.net/graal/graal/rev/968215f13aad

MemoryScheduleTest: fix scope for CFG dumping

! graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/MemoryScheduleTest.java

Changeset: af441d477a40
Author:    Bernhard Urban <bernhard.urban at jku.at>
Date:      2013-07-26 20:18 +0200
URL:       http://hg.openjdk.java.net/graal/graal/rev/af441d477a40

SchedulingPhase: add option for new memory aware scheduling (GRAAL-159)

! graal/com.oracle.graal.phases/src/com/oracle/graal/phases/GraalOptions.java
! graal/com.oracle.graal.phases/src/com/oracle/graal/phases/schedule/SchedulePhase.java

Changeset: 0aba970c89f9
Author:    Bernhard Urban <bernhard.urban at jku.at>
Date:      2013-07-26 20:18 +0200
URL:       http://hg.openjdk.java.net/graal/graal/rev/0aba970c89f9

mx/ctw: disable new memory aware scheduling

! mx/sanitycheck.py

Changeset: 8106edbdeac9
Author:    Bernhard Urban <bernhard.urban at jku.at>
Date:      2013-07-26 20:18 +0200
URL:       http://hg.openjdk.java.net/graal/graal/rev/8106edbdeac9

add NewMemoryAwareScheduling (GRAAL-159)

! graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/GraphScheduleTest.java
! graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/MemoryScheduleTest.java
! graal/com.oracle.graal.phases/src/com/oracle/graal/phases/graph/ScheduledNodeIterator.java
! graal/com.oracle.graal.phases/src/com/oracle/graal/phases/schedule/SchedulePhase.java

Changeset: 9c4f90e48c60
Author:    twisti
Date:      2013-07-26 14:03 -0700
URL:       http://hg.openjdk.java.net/graal/graal/rev/9c4f90e48c60

read HotSpot VM options via HotSpotDiagnosticMXBean

! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/HotSpotVMConfig.java
! src/share/vm/graal/graalCompilerToVM.cpp

Changeset: ea308a63760b
Author:    twisti
Date:      2013-07-26 20:34 -0700
URL:       http://hg.openjdk.java.net/graal/graal/rev/ea308a63760b

added unalignedMemoryAccess to Architecture

! graal/com.oracle.graal.amd64/src/com/oracle/graal/amd64/AMD64.java
! graal/com.oracle.graal.api.code/src/com/oracle/graal/api/code/Architecture.java
! graal/com.oracle.graal.hsail/src/com/oracle/graal/hsail/HSAIL.java
! graal/com.oracle.graal.ptx/src/com/oracle/graal/ptx/PTX.java
! graal/com.oracle.graal.sparc/src/com/oracle/graal/sparc/SPARC.java

Changeset: d9656f8eede0
Author:    twisti
Date:      2013-07-26 20:34 -0700
URL:       http://hg.openjdk.java.net/graal/graal/rev/d9656f8eede0

solaris build fixed

! make/solaris/makefiles/buildtree.make
! make/solaris/makefiles/vm.make


From lukas.stadler at jku.at  Sun Jul 28 21:30:36 2013
From: lukas.stadler at jku.at (Lukas Stadler)
Date: Sun, 28 Jul 2013 21:30:36 -0700
Subject: Escape Analysis and MH.invoke, MH.invokeExact
In-Reply-To: <7E4228B446372948BBB2916FC53FA49E26DDE397@rexma.intranet.epfl.ch>
References: <7E4228B446372948BBB2916FC53FA49E26DDE397@rexma.intranet.epfl.ch>
Message-ID: <B2B80B6A-8411-4D14-97E0-9F4BF8445FE7@jku.at>

I'm not that familiar with the MethodHandle code, I have to admit.
Are you referring to the fact that the method handle itself is not actually used within the called code, because it's only used to determine what needs to be called?
I'd have to look into how the method handle calls are actually encoded... do you think that it happens a lot that method handles could be escape analyzed?

- Lukas

On Jul 27, 2013, at 3:42 , Garcia Gutierrez Miguel Alfredo <miguelalfredo.garcia at epfl.ch> wrote:

> Lukas,
> 
> Thanks for the link, that overview is quite helpful. For the moment I'm just wading through the info deluge of PEA and its interplay with inlining.
> 
> I was wondering whether it could pay off to make (Partial) EA handle specially the "escaping behavior" of a MethodHandle instance wrt invoke (resp. invokeExact). From what I've seen, the receiver of an instance-method invocation is deemed method-escaping. However it appears that (conceptually) the EA analysis could special-case MH.invoke() and MH.invokeExact() callsites, by not concluding "receiver escapes" for them. Perhaps this heuristic could enable other optimizations.
> 
> All of the above of course with the big disclaimer that I'm not that familiar with EA, and without knowing for sure whether an implementation of MH.invoke, MH.invokeExact could (somehow) let "this" escape.
> 
> 
> Miguel
> --
> Miguel Garcia
> Swiss Federal Institute of Technology
> EPFL - IC - LAMP1 - INR 328 - Station 14
> CH-1015 Lausanne - Switzerland
> http://lamp.epfl.ch/~magarcia/
> 
> ________________________________________
> From: Lukas Stadler [lukas.stadler at jku.at]
> Sent: Friday, July 26, 2013 8:24 PM
> To: Garcia Gutierrez Miguel Alfredo
> Cc: graal-dev at openjdk.java.net
> Subject: Re: escapa analysis, packed objects
> 
> Hi Miguel,
> 
> unfortunately there's no documentation on Graal's partial escape analysis yet.
> A short intro is available here: https://wiki.openjdk.java.net/display/Graal/Graal+Partial+Escape+Analysis
> I'm currently working on a publication on this topic, I'd be happy to send you a version of it as soon as it's complete enough to make sense :-)
> I also could give you an introduction over skype.
> 
> Concerning the "structs" proposals:
> The IBM proposal seems to be mostly about how to interact with the C world, like a convenient wrapper around sun.misc.Unsafe.
> I think that John Rose's proposal is more interesting, especially since the locking mechanism allows partial escape analysis to work much more efficiently.
> (We actually already do a similar trick for boxing operations, so we could take advantage of this mechanism pretty quickly)
> 
> Much of this can be handled by the compiler, but of course it's only part of the picture. Allowing structs as return values means that this needs to be handled correctly by the interpreter, by deoptimization, by stack walking, in the debug interface, in jni code, etc.
> I think it's too big a task (and too many VM changes) for us to do, but once this proposal gets picked up by the hotspot team, we can quickly provide efficient support for it.
> 
> - Lukas
> 
> On Jul 25, 2013, at 13:32 , Garcia Gutierrez Miguel Alfredo <miguelalfredo.garcia at epfl.ch> wrote:
> 
>> 
>> Hi,
>> 
>> Escape analysis in Graal looks interesting. Are there any publications describing it? What I've heard about is:
>> 
>> (1) Jong-Deok Shoi et al. https://wikis.oracle.com/display/HotSpotInternals/EscapeAnalysis
>> 
>> (2) EA in the client compiler, http://ssw.jku.at/General/Staff/TK/Research/Publications/
>> 
>> 
>> 
>> Another question, this time looking into the future. Approaches have been put forward to support "structs in the JVM", things like:
>> 
>> packed objects, http://www.slideshare.net/mmitran/ibm-java-packed-objects-mmit-20121120
>> 
>> http://openjdk.java.net/jeps/169
>> 
>> What about Graal? For example, the use case "method returns a struct", would HotSpot stand in the way, or can LIR be tweaked to realize that? I know it's a slippery topic, but comments are welcome! :)
>> 
>> 
>> Miguel
>> 
>> --
>> Miguel Garcia
>> Swiss Federal Institute of Technology
>> EPFL - IC - LAMP1 - INR 328 - Station 14
>> CH-1015 Lausanne - Switzerland
>> http://lamp.epfl.ch/~magarcia/
> 


From miguelalfredo.garcia at epfl.ch  Mon Jul 29 00:16:38 2013
From: miguelalfredo.garcia at epfl.ch (Garcia Gutierrez Miguel Alfredo)
Date: Mon, 29 Jul 2013 07:16:38 +0000
Subject: Escape Analysis and MH.invoke, MH.invokeExact
In-Reply-To: <B2B80B6A-8411-4D14-97E0-9F4BF8445FE7@jku.at>
References: <7E4228B446372948BBB2916FC53FA49E26DDE397@rexma.intranet.epfl.ch>,
	<B2B80B6A-8411-4D14-97E0-9F4BF8445FE7@jku.at>
Message-ID: <7E4228B446372948BBB2916FC53FA49E26DE2D01@REXMD.intranet.epfl.ch>

Lukas,

> Are you referring to the fact that the method handle itself is not actually used within the called code,
> because it's only used to determine what needs to be called?

Yes, that's the case I had in mind. Within that case there appear to be subcases, e.g. (a) the "payload" of the MH is a direct pointer to the target method; or (b) the MH contains in addition bound arguments, or in general composes other MHs.

> I'd have to look into how the method handle calls are actually encoded... 

I haven't looked into that aspect in Graal. Regarding the other HotSpot compilers, the description of MH implementation doesn't mention an interplay with EA:
https://wikis.oracle.com/display/HotSpotInternals/Method+handles+and+invokedynamic

> do you think that it happens a lot that method handles could be escape analyzed?

Well, it's only a hunch, but the argument goes as follows:
  (1) a method P receives (via some formal) different MH instances across invocations,
  (2) if the MH is just invoke'd or invokeExact'd and otherwise doesn't escape P,
  (3) then P could be inlined.
Perhaps I'm somewhat biased in that I believe the scenario above co-exists frequently with two additional boosters:
  (4) the MH is invoked repeatedly inside P (that's often the case for collection operations)
  (5) in spite of being inlined, no DeoptimizeNode appears to be needed (assuming, or better said *hoping* that the lowerings of invoke() and invokeExact() don't behave like invokevirtual)

That's the summary (ie, the "hunch" in words). Perhaps (4) and (5) are additional bonus, which don't degrade performance even if not present.


Miguel

--
Miguel Garcia
Swiss Federal Institute of Technology
EPFL - IC - LAMP1 - INR 328 - Station 14
CH-1015 Lausanne - Switzerland
http://lamp.epfl.ch/~magarcia/

________________________________________
From: Lukas Stadler [lukas.stadler at jku.at]
Sent: Monday, July 29, 2013 6:30 AM
To: Garcia Gutierrez Miguel Alfredo
Cc: graal-dev at openjdk.java.net
Subject: Re: Escape Analysis and MH.invoke, MH.invokeExact

I'm not that familiar with the MethodHandle code, I have to admit.
Are you referring to the fact that the method handle itself is not actually used within the called code, because it's only used to determine what needs to be called?
I'd have to look into how the method handle calls are actually encoded... do you think that it happens a lot that method handles could be escape analyzed?

- Lukas

On Jul 27, 2013, at 3:42 , Garcia Gutierrez Miguel Alfredo <miguelalfredo.garcia at epfl.ch> wrote:

> Lukas,
>
> Thanks for the link, that overview is quite helpful. For the moment I'm just wading through the info deluge of PEA and its interplay with inlining.
>
> I was wondering whether it could pay off to make (Partial) EA handle specially the "escaping behavior" of a MethodHandle instance wrt invoke (resp. invokeExact). From what I've seen, the receiver of an instance-method invocation is deemed method-escaping. However it appears that (conceptually) the EA analysis could special-case MH.invoke() and MH.invokeExact() callsites, by not concluding "receiver escapes" for them. Perhaps this heuristic could enable other optimizations.
>
> All of the above of course with the big disclaimer that I'm not that familiar with EA, and without knowing for sure whether an implementation of MH.invoke, MH.invokeExact could (somehow) let "this" escape.
>
>
> Miguel
> --
> Miguel Garcia
> Swiss Federal Institute of Technology
> EPFL - IC - LAMP1 - INR 328 - Station 14
> CH-1015 Lausanne - Switzerland
> http://lamp.epfl.ch/~magarcia/
>
> ________________________________________
> From: Lukas Stadler [lukas.stadler at jku.at]
> Sent: Friday, July 26, 2013 8:24 PM
> To: Garcia Gutierrez Miguel Alfredo
> Cc: graal-dev at openjdk.java.net
> Subject: Re: escapa analysis, packed objects
>
> Hi Miguel,
>
> unfortunately there's no documentation on Graal's partial escape analysis yet.
> A short intro is available here: https://wiki.openjdk.java.net/display/Graal/Graal+Partial+Escape+Analysis
> I'm currently working on a publication on this topic, I'd be happy to send you a version of it as soon as it's complete enough to make sense :-)
> I also could give you an introduction over skype.
>
> Concerning the "structs" proposals:
> The IBM proposal seems to be mostly about how to interact with the C world, like a convenient wrapper around sun.misc.Unsafe.
> I think that John Rose's proposal is more interesting, especially since the locking mechanism allows partial escape analysis to work much more efficiently.
> (We actually already do a similar trick for boxing operations, so we could take advantage of this mechanism pretty quickly)
>
> Much of this can be handled by the compiler, but of course it's only part of the picture. Allowing structs as return values means that this needs to be handled correctly by the interpreter, by deoptimization, by stack walking, in the debug interface, in jni code, etc.
> I think it's too big a task (and too many VM changes) for us to do, but once this proposal gets picked up by the hotspot team, we can quickly provide efficient support for it.
>
> - Lukas
>
> On Jul 25, 2013, at 13:32 , Garcia Gutierrez Miguel Alfredo <miguelalfredo.garcia at epfl.ch> wrote:
>
>>
>> Hi,
>>
>> Escape analysis in Graal looks interesting. Are there any publications describing it? What I've heard about is:
>>
>> (1) Jong-Deok Shoi et al. https://wikis.oracle.com/display/HotSpotInternals/EscapeAnalysis
>>
>> (2) EA in the client compiler, http://ssw.jku.at/General/Staff/TK/Research/Publications/
>>
>>
>>
>> Another question, this time looking into the future. Approaches have been put forward to support "structs in the JVM", things like:
>>
>> packed objects, http://www.slideshare.net/mmitran/ibm-java-packed-objects-mmit-20121120
>>
>> http://openjdk.java.net/jeps/169
>>
>> What about Graal? For example, the use case "method returns a struct", would HotSpot stand in the way, or can LIR be tweaked to realize that? I know it's a slippery topic, but comments are welcome! :)
>>
>>
>> Miguel
>>
>> --
>> Miguel Garcia
>> Swiss Federal Institute of Technology
>> EPFL - IC - LAMP1 - INR 328 - Station 14
>> CH-1015 Lausanne - Switzerland
>> http://lamp.epfl.ch/~magarcia/
>


From lukas.stadler at jku.at  Mon Jul 29 22:49:58 2013
From: lukas.stadler at jku.at (Lukas Stadler)
Date: Mon, 29 Jul 2013 22:49:58 -0700
Subject: Escape Analysis and MH.invoke, MH.invokeExact
In-Reply-To: <7E4228B446372948BBB2916FC53FA49E26DE2D01@REXMD.intranet.epfl.ch>
References: <7E4228B446372948BBB2916FC53FA49E26DDE397@rexma.intranet.epfl.ch>,
	<B2B80B6A-8411-4D14-97E0-9F4BF8445FE7@jku.at>
	<7E4228B446372948BBB2916FC53FA49E26DE2D01@REXMD.intranet.epfl.ch>
Message-ID: <9D980859-076F-4FD2-9380-A6B1EB022D78@jku.at>

Hey,

I'm going to talk to Chris (Thalinger) tomorrow, he's been working on the method handle implementation in Graal.
I don't think this is so specific to method handles - it should apply to other forms of "closures" as well.
Vlad also mentioned this at ECOOP - a higher order function should probably get a bonus when making an inlining decision.

- Lukas

On Jul 29, 2013, at 0:16 , Garcia Gutierrez Miguel Alfredo <miguelalfredo.garcia at epfl.ch> wrote:

> Lukas,
> 
>> Are you referring to the fact that the method handle itself is not actually used within the called code,
>> because it's only used to determine what needs to be called?
> 
> Yes, that's the case I had in mind. Within that case there appear to be subcases, e.g. (a) the "payload" of the MH is a direct pointer to the target method; or (b) the MH contains in addition bound arguments, or in general composes other MHs.
> 
>> I'd have to look into how the method handle calls are actually encoded... 
> 
> I haven't looked into that aspect in Graal. Regarding the other HotSpot compilers, the description of MH implementation doesn't mention an interplay with EA:
> https://wikis.oracle.com/display/HotSpotInternals/Method+handles+and+invokedynamic
> 
>> do you think that it happens a lot that method handles could be escape analyzed?
> 
> Well, it's only a hunch, but the argument goes as follows:
>  (1) a method P receives (via some formal) different MH instances across invocations,
>  (2) if the MH is just invoke'd or invokeExact'd and otherwise doesn't escape P,
>  (3) then P could be inlined.
> Perhaps I'm somewhat biased in that I believe the scenario above co-exists frequently with two additional boosters:
>  (4) the MH is invoked repeatedly inside P (that's often the case for collection operations)
>  (5) in spite of being inlined, no DeoptimizeNode appears to be needed (assuming, or better said *hoping* that the lowerings of invoke() and invokeExact() don't behave like invokevirtual)
> 
> That's the summary (ie, the "hunch" in words). Perhaps (4) and (5) are additional bonus, which don't degrade performance even if not present.
> 
> 
> Miguel
> 
> --
> Miguel Garcia
> Swiss Federal Institute of Technology
> EPFL - IC - LAMP1 - INR 328 - Station 14
> CH-1015 Lausanne - Switzerland
> http://lamp.epfl.ch/~magarcia/
> 
> ________________________________________
> From: Lukas Stadler [lukas.stadler at jku.at]
> Sent: Monday, July 29, 2013 6:30 AM
> To: Garcia Gutierrez Miguel Alfredo
> Cc: graal-dev at openjdk.java.net
> Subject: Re: Escape Analysis and MH.invoke, MH.invokeExact
> 
> I'm not that familiar with the MethodHandle code, I have to admit.
> Are you referring to the fact that the method handle itself is not actually used within the called code, because it's only used to determine what needs to be called?
> I'd have to look into how the method handle calls are actually encoded... do you think that it happens a lot that method handles could be escape analyzed?
> 
> - Lukas
> 
> On Jul 27, 2013, at 3:42 , Garcia Gutierrez Miguel Alfredo <miguelalfredo.garcia at epfl.ch> wrote:
> 
>> Lukas,
>> 
>> Thanks for the link, that overview is quite helpful. For the moment I'm just wading through the info deluge of PEA and its interplay with inlining.
>> 
>> I was wondering whether it could pay off to make (Partial) EA handle specially the "escaping behavior" of a MethodHandle instance wrt invoke (resp. invokeExact). From what I've seen, the receiver of an instance-method invocation is deemed method-escaping. However it appears that (conceptually) the EA analysis could special-case MH.invoke() and MH.invokeExact() callsites, by not concluding "receiver escapes" for them. Perhaps this heuristic could enable other optimizations.
>> 
>> All of the above of course with the big disclaimer that I'm not that familiar with EA, and without knowing for sure whether an implementation of MH.invoke, MH.invokeExact could (somehow) let "this" escape.
>> 
>> 
>> Miguel
>> --
>> Miguel Garcia
>> Swiss Federal Institute of Technology
>> EPFL - IC - LAMP1 - INR 328 - Station 14
>> CH-1015 Lausanne - Switzerland
>> http://lamp.epfl.ch/~magarcia/
>> 
>> ________________________________________
>> From: Lukas Stadler [lukas.stadler at jku.at]
>> Sent: Friday, July 26, 2013 8:24 PM
>> To: Garcia Gutierrez Miguel Alfredo
>> Cc: graal-dev at openjdk.java.net
>> Subject: Re: escapa analysis, packed objects
>> 
>> Hi Miguel,
>> 
>> unfortunately there's no documentation on Graal's partial escape analysis yet.
>> A short intro is available here: https://wiki.openjdk.java.net/display/Graal/Graal+Partial+Escape+Analysis
>> I'm currently working on a publication on this topic, I'd be happy to send you a version of it as soon as it's complete enough to make sense :-)
>> I also could give you an introduction over skype.
>> 
>> Concerning the "structs" proposals:
>> The IBM proposal seems to be mostly about how to interact with the C world, like a convenient wrapper around sun.misc.Unsafe.
>> I think that John Rose's proposal is more interesting, especially since the locking mechanism allows partial escape analysis to work much more efficiently.
>> (We actually already do a similar trick for boxing operations, so we could take advantage of this mechanism pretty quickly)
>> 
>> Much of this can be handled by the compiler, but of course it's only part of the picture. Allowing structs as return values means that this needs to be handled correctly by the interpreter, by deoptimization, by stack walking, in the debug interface, in jni code, etc.
>> I think it's too big a task (and too many VM changes) for us to do, but once this proposal gets picked up by the hotspot team, we can quickly provide efficient support for it.
>> 
>> - Lukas
>> 
>> On Jul 25, 2013, at 13:32 , Garcia Gutierrez Miguel Alfredo <miguelalfredo.garcia at epfl.ch> wrote:
>> 
>>> 
>>> Hi,
>>> 
>>> Escape analysis in Graal looks interesting. Are there any publications describing it? What I've heard about is:
>>> 
>>> (1) Jong-Deok Shoi et al. https://wikis.oracle.com/display/HotSpotInternals/EscapeAnalysis
>>> 
>>> (2) EA in the client compiler, http://ssw.jku.at/General/Staff/TK/Research/Publications/
>>> 
>>> 
>>> 
>>> Another question, this time looking into the future. Approaches have been put forward to support "structs in the JVM", things like:
>>> 
>>> packed objects, http://www.slideshare.net/mmitran/ibm-java-packed-objects-mmit-20121120
>>> 
>>> http://openjdk.java.net/jeps/169
>>> 
>>> What about Graal? For example, the use case "method returns a struct", would HotSpot stand in the way, or can LIR be tweaked to realize that? I know it's a slippery topic, but comments are welcome! :)
>>> 
>>> 
>>> Miguel
>>> 
>>> --
>>> Miguel Garcia
>>> Swiss Federal Institute of Technology
>>> EPFL - IC - LAMP1 - INR 328 - Station 14
>>> CH-1015 Lausanne - Switzerland
>>> http://lamp.epfl.ch/~magarcia/
>> 
> 


From miguelalfredo.garcia at epfl.ch  Tue Jul 30 05:35:16 2013
From: miguelalfredo.garcia at epfl.ch (Garcia Gutierrez Miguel Alfredo)
Date: Tue, 30 Jul 2013 12:35:16 +0000
Subject: oscillating "invalidate + recompile" due to closures: myth or reality?
Message-ID: <7E4228B446372948BBB2916FC53FA49E26DE3603@REXMD.intranet.epfl.ch>


The good thing is that I *might* be making some progress in understanding inlining. The bad thing is that I have another question.

An object allocation conveys an exact type. Such knowledge is useful whenever a callee contains callsites on the allocated object (yes, in a previous post I asked already about a similar situation). The idea is formulated in:

Next in line, please!: exploiting the indirect benefits of inlining by accurately predicting further inlining
A. Sewe, J. Jochem, M. Mezini
TU Darmstadt, Germany
http://dl.acm.org/citation.cfm?id=2095102

(for the purposes of that heuristic, a MethodHandle instance can also be regarded as determining an exact type for the host of the target method, because MHs are immutable).

(I promise I'll finally ask my question after just one more quotation, which serves as background.)

The heuristic above seems advantageous whenever our callees receive lambdas (either MHs or inner classes) because all callistes on such lambdas can be resolved to target implementations. That can only be good. My question rather is about those inlinings where the callee contains type-guarded callsites (in particular callsites on closures, whose exact type isn't known). In that case, the paper above mentions:

"If the guard test fails, dynamic dispatch is performed as a fall-back."

Question (finally!): Does that apply to code emitted by Graal? Isn't the fall-back actually a method invalidation + recompile?

(I haven't gathered any metrics, just thinking aloud)

If so, after inlining a lot of callees, it may well happen that "invalidation + recompile" oscillates a lot just because it suffices for a single type-guarded callsite to trigger another cycle of invalidation of *the whole method* followed by recompilation.

Not sure whether the sketched scenario can happen (frequently enough), comments are welcome.


Miguel
http://magarciaepfl.github.io/scala/


--
Miguel Garcia
Swiss Federal Institute of Technology
EPFL - IC - LAMP1 - INR 328 - Station 14
CH-1015 Lausanne - Switzerland
http://lamp.epfl.ch/~magarcia/

From miguelalfredo.garcia at epfl.ch  Tue Jul 30 06:00:26 2013
From: miguelalfredo.garcia at epfl.ch (Garcia Gutierrez Miguel Alfredo)
Date: Tue, 30 Jul 2013 13:00:26 +0000
Subject: can an object be allocated on the stack?
Message-ID: <7E4228B446372948BBB2916FC53FA49E26DE3624@REXMD.intranet.epfl.ch>


Sometimes it's safe to allocate an object on the stack, for example for the cases covered in Ch. 5 of http://ssw.jku.at/Research/Papers/Ko05b/

Can the Graal IR express such code idioms?

(I guess not, because if so then it would be possible to have a method return a struct, ie just let the caller allocate it on the stack and have the callee modify it via address + offset, the callee itself may be void-returning).

Or is it?


Miguel
http://magarciaepfl.github.io/scala/

--
Miguel Garcia
Swiss Federal Institute of Technology
EPFL - IC - LAMP1 - INR 328 - Station 14
CH-1015 Lausanne - Switzerland
http://lamp.epfl.ch/~magarcia/

From lukas.stadler at jku.at  Tue Jul 30 12:55:10 2013
From: lukas.stadler at jku.at (Lukas Stadler)
Date: Tue, 30 Jul 2013 12:55:10 -0700
Subject: can an object be allocated on the stack?
In-Reply-To: <7E4228B446372948BBB2916FC53FA49E26DE3624@REXMD.intranet.epfl.ch>
References: <7E4228B446372948BBB2916FC53FA49E26DE3624@REXMD.intranet.epfl.ch>
Message-ID: <1C2A0F30-6812-421A-87CF-E48C1E40CEEF@jku.at>

At the moment, we do not do this optimization.
I'ts not really a question of support in Graal (it would be rather easy to support in the compiler, because the necessary primitives are there), it's more a question of support in the VM.
We want to keep our native code delta to HotSpot small, and this would need extensive changes to the gc and debug infrastructure.

- Lukas

On Jul 30, 2013, at 6:00 , Garcia Gutierrez Miguel Alfredo <miguelalfredo.garcia at epfl.ch> wrote:

> 
> Sometimes it's safe to allocate an object on the stack, for example for the cases covered in Ch. 5 of http://ssw.jku.at/Research/Papers/Ko05b/
> 
> Can the Graal IR express such code idioms?
> 
> (I guess not, because if so then it would be possible to have a method return a struct, ie just let the caller allocate it on the stack and have the callee modify it via address + offset, the callee itself may be void-returning).
> 
> Or is it?
> 
> 
> Miguel
> http://magarciaepfl.github.io/scala/
> 
> --
> Miguel Garcia
> Swiss Federal Institute of Technology
> EPFL - IC - LAMP1 - INR 328 - Station 14
> CH-1015 Lausanne - Switzerland
> http://lamp.epfl.ch/~magarcia/


From lukas.stadler at jku.at  Tue Jul 30 20:41:39 2013
From: lukas.stadler at jku.at (Lukas Stadler)
Date: Tue, 30 Jul 2013 20:41:39 -0700
Subject: oscillating "invalidate + recompile" due to closures: myth or
	reality?
In-Reply-To: <7E4228B446372948BBB2916FC53FA49E26DE3603@REXMD.intranet.epfl.ch>
References: <7E4228B446372948BBB2916FC53FA49E26DE3603@REXMD.intranet.epfl.ch>
Message-ID: <DE3E7C48-BE65-4DB5-9BB7-4BDDC5229A18@jku.at>

Inlining is based on the type profile we get from HotSpot.
This tells us the first X (with X currently being 8) types and methods seen at a call site, and their probabilities.
Apart from that, it also tells us how many calls were outside these types/methods ("notRecordedProbability").

For call sites with notRecordedProbability == 0 Graal creates a deopt in the "other" case, but if notRecordedProbability > 0 is creates a real call as a fallback.
If the deopt fails it does a invalidate+reprofile, so that the profile should include the new, previously unknown type the next time the method is compiled.

We experience some recompiles from this, but overall the profiles stabilize rather quickly. We've not had problem with this so far.

- Lukas

On Jul 30, 2013, at 5:35 , Garcia Gutierrez Miguel Alfredo <miguelalfredo.garcia at epfl.ch> wrote:

> 
> The good thing is that I *might* be making some progress in understanding inlining. The bad thing is that I have another question.
> 
> An object allocation conveys an exact type. Such knowledge is useful whenever a callee contains callsites on the allocated object (yes, in a previous post I asked already about a similar situation). The idea is formulated in:
> 
> Next in line, please!: exploiting the indirect benefits of inlining by accurately predicting further inlining
> A. Sewe, J. Jochem, M. Mezini
> TU Darmstadt, Germany
> http://dl.acm.org/citation.cfm?id=2095102
> 
> (for the purposes of that heuristic, a MethodHandle instance can also be regarded as determining an exact type for the host of the target method, because MHs are immutable).
> 
> (I promise I'll finally ask my question after just one more quotation, which serves as background.)
> 
> The heuristic above seems advantageous whenever our callees receive lambdas (either MHs or inner classes) because all callistes on such lambdas can be resolved to target implementations. That can only be good. My question rather is about those inlinings where the callee contains type-guarded callsites (in particular callsites on closures, whose exact type isn't known). In that case, the paper above mentions:
> 
> "If the guard test fails, dynamic dispatch is performed as a fall-back."
> 
> Question (finally!): Does that apply to code emitted by Graal? Isn't the fall-back actually a method invalidation + recompile?
> 
> (I haven't gathered any metrics, just thinking aloud)
> 
> If so, after inlining a lot of callees, it may well happen that "invalidation + recompile" oscillates a lot just because it suffices for a single type-guarded callsite to trigger another cycle of invalidation of *the whole method* followed by recompilation.
> 
> Not sure whether the sketched scenario can happen (frequently enough), comments are welcome.
> 
> 
> Miguel
> http://magarciaepfl.github.io/scala/
> 
> 
> --
> Miguel Garcia
> Swiss Federal Institute of Technology
> EPFL - IC - LAMP1 - INR 328 - Station 14
> CH-1015 Lausanne - Switzerland
> http://lamp.epfl.ch/~magarcia/


From miguelalfredo.garcia at epfl.ch  Wed Jul 31 14:03:14 2013
From: miguelalfredo.garcia at epfl.ch (Garcia Gutierrez Miguel Alfredo)
Date: Wed, 31 Jul 2013 21:03:14 +0000
Subject: grokking CheckCastNode.canonical()
Message-ID: <7E4228B446372948BBB2916FC53FA49E26DE3741@REXMD.intranet.epfl.ch>


--------------- (1) ---------------

The javadoc for ConstantNode mentions it can represent an "address". Well, no, because a Constant can't represent an address.

/**
 * The {@code ConstantNode} represents a constant such as an integer value, long, float, object
 * reference, address, etc.
 */


--------------- (2) ---------------

In CheckCastNode.canonical() the following seems suspicious:

        // remove checkcast if next node is a more specific checkcast
        if (predecessor() instanceof CheckCastNode) {
            CheckCastNode ccn = (CheckCastNode) predecessor();
            if (ccn != null      &&
                ccn.type != null &&
------------>   ccn == object    &&
                ccn.forStoreCheck == forStoreCheck &&
                ccn.type.isAssignableFrom(type))
            {
                StructuredGraph graph = ccn.graph();
                CheckCastNode newccn = graph.add(new CheckCastNode(type, ccn.object, ccn.profile, ccn.forStoreCheck));
                graph.replaceFixedWithFixed(ccn, newccn);
                return newccn;
            }
        }

IMO, the line with the arrow should read:

                ccn.object == object    &&


--------------- (3) ---------------

I guess it's a matter of coding style, but anyway it would be great to hear other opinions on the following. The context is also CheckCastNode.canonical()

The case where the input is known to be null (reproduced below) is checked in third place, after two more expensive tests. What about making it first?

        if (object().objectStamp().alwaysNull()) {
            return object();
        }

Also in the snippet above, what's the advantage of returning object() vs. returning the uniquified null-node proper, say ConstantNode.forObject(null,...). Is it because of the additional information in the stamp() of object() ?


--
Miguel Garcia
Swiss Federal Institute of Technology
EPFL - IC - LAMP1 - INR 328 - Station 14
CH-1015 Lausanne - Switzerland
http://lamp.epfl.ch/~magarcia/

From miguelalfredo.garcia at epfl.ch  Wed Jul 31 15:07:05 2013
From: miguelalfredo.garcia at epfl.ch (Garcia Gutierrez Miguel Alfredo)
Date: Wed, 31 Jul 2013 22:07:05 +0000
Subject: grokking CheckCastNode.canonical()
In-Reply-To: <7E4228B446372948BBB2916FC53FA49E26DE3741@REXMD.intranet.epfl.ch>
References: <7E4228B446372948BBB2916FC53FA49E26DE3741@REXMD.intranet.epfl.ch>
Message-ID: <7E4228B446372948BBB2916FC53FA49E26DE475F@REXMD.intranet.epfl.ch>


Oh, wait. Forget about what I said under (3) below about returning null-node. The way it's done is correct, to preserve the side-effects of the computation denoted by object().

--
Miguel Garcia
Swiss Federal Institute of Technology
EPFL - IC - LAMP1 - INR 328 - Station 14
CH-1015 Lausanne - Switzerland
http://lamp.epfl.ch/~magarcia/

________________________________________
From: graal-dev-bounces at openjdk.java.net [graal-dev-bounces at openjdk.java.net] on behalf of Garcia Gutierrez Miguel Alfredo [miguelalfredo.garcia at epfl.ch]
Sent: Wednesday, July 31, 2013 11:03 PM
To: graal-dev at openjdk.java.net
Subject: grokking CheckCastNode.canonical()

--------------- (1) ---------------

The javadoc for ConstantNode mentions it can represent an "address". Well, no, because a Constant can't represent an address.

/**
 * The {@code ConstantNode} represents a constant such as an integer value, long, float, object
 * reference, address, etc.
 */


--------------- (2) ---------------

In CheckCastNode.canonical() the following seems suspicious:

        // remove checkcast if next node is a more specific checkcast
        if (predecessor() instanceof CheckCastNode) {
            CheckCastNode ccn = (CheckCastNode) predecessor();
            if (ccn != null      &&
                ccn.type != null &&
------------>   ccn == object    &&
                ccn.forStoreCheck == forStoreCheck &&
                ccn.type.isAssignableFrom(type))
            {
                StructuredGraph graph = ccn.graph();
                CheckCastNode newccn = graph.add(new CheckCastNode(type, ccn.object, ccn.profile, ccn.forStoreCheck));
                graph.replaceFixedWithFixed(ccn, newccn);
                return newccn;
            }
        }

IMO, the line with the arrow should read:

                ccn.object == object    &&


--------------- (3) ---------------

I guess it's a matter of coding style, but anyway it would be great to hear other opinions on the following. The context is also CheckCastNode.canonical()

The case where the input is known to be null (reproduced below) is checked in third place, after two more expensive tests. What about making it first?

        if (object().objectStamp().alwaysNull()) {
            return object();
        }

Also in the snippet above, what's the advantage of returning object() vs. returning the uniquified null-node proper, say ConstantNode.forObject(null,...). Is it because of the additional information in the stamp() of object() ?


--
Miguel Garcia
Swiss Federal Institute of Technology
EPFL - IC - LAMP1 - INR 328 - Station 14
CH-1015 Lausanne - Switzerland
http://lamp.epfl.ch/~magarcia/