From aph at redhat.com  Tue Nov  1 16:40:34 2016
From: aph at redhat.com (Andrew Haley)
Date: Tue, 1 Nov 2016 16:40:34 +0000
Subject: Bug fixes
Message-ID: <6d51b1fb-fdbf-cb72-d381-de8cec53dca8@redhat.com>

I have a bunch of fixes for Aarch64 Graal.

Hat's the process for getting them in?  Do you create bug reports
and webrevs just like other OpenJDK projects, or what?

Thanks,

Andrew.

From thomas.wuerthinger at oracle.com  Tue Nov  1 17:44:36 2016
From: thomas.wuerthinger at oracle.com (Thomas Wuerthinger)
Date: Tue, 1 Nov 2016 18:44:36 +0100
Subject: Bug fixes
In-Reply-To: <6d51b1fb-fdbf-cb72-d381-de8cec53dca8@redhat.com>
References: <6d51b1fb-fdbf-cb72-d381-de8cec53dca8@redhat.com>
Message-ID: <1F201687-B2B7-4D1D-927B-E99FE4E43A04@oracle.com>

We accept pull requests at https://github.com/graalvm/graal-core/pulls <https://github.com/graalvm/graal-core/pulls>.

Regards, thomas


> On 01 Nov 2016, at 17:40, Andrew Haley <aph at redhat.com> wrote:
> 
> I have a bunch of fixes for Aarch64 Graal.
> 
> Hat's the process for getting them in?  Do you create bug reports
> and webrevs just like other OpenJDK projects, or what?
> 
> Thanks,
> 
> Andrew.


From aph at redhat.com  Thu Nov  3 14:18:23 2016
From: aph at redhat.com (Andrew Haley)
Date: Thu, 3 Nov 2016 14:18:23 +0000
Subject: How to dump the IR for a named method?
Message-ID: <cb6687bb-ce0c-cd15-bc52-ac9c7097f551@redhat.com>

DumpOnError works, but what if there is no error?

Thanks,

Andrew.

From josef.eisl at jku.at  Thu Nov  3 14:27:48 2016
From: josef.eisl at jku.at (Josef Eisl)
Date: Thu, 3 Nov 2016 15:27:48 +0100
Subject: How to dump the IR for a named method?
In-Reply-To: <cb6687bb-ce0c-cd15-bc52-ac9c7097f551@redhat.com>
References: <cb6687bb-ce0c-cd15-bc52-ac9c7097f551@redhat.com>
Message-ID: <d1a9ec35-06a2-8c6d-b785-0616d51e5c7b@jku.at>

On 03/11/16 15:18, Andrew Haley wrote:
> DumpOnError works, but what if there is no error?

You can use `-Dgraal.Dump=` to enable dumping and
`-Dgraal.MethodFilter=myMethodName` to restrict its output [1].

- Josef

[1]:
https://github.com/graalvm/graal-core/blob/master/docs/Debugging.md#method-filtering

From aph at redhat.com  Thu Nov  3 17:01:44 2016
From: aph at redhat.com (Andrew Haley)
Date: Thu, 3 Nov 2016 17:01:44 +0000
Subject: Sub-word comparisons
Message-ID: <b08602c9-9e1a-6ca4-63ff-ae48ce63761b@redhat.com>

I've got a tricky bug that I can't figure out how to fix.

I'm seeing comparisons of mixed types, and I can't figure out how to
generate decent code for them.

For example, I see a

  CompareNode(x: i8, y: i8)

which gets lowered to

  Compare(PlatformKind = BYTE, left: v59|DWORD, right: byte[0|0x0])

so I guess I'm supposed only to be comparing the bottom 8 bits of the
register.  But I can't do that: I can only compare 32- or 64-bit
quantities.  It would be possible but extremely ugly to do it by
shifting both quantities left and then doing the comparison.

It would be extremely nice if I could tell Graal that I can't do
subword arithmetic of any kind.  Is anything like that possible?

Andrew.

From doug.simon at oracle.com  Thu Nov  3 19:18:36 2016
From: doug.simon at oracle.com (Doug Simon)
Date: Thu, 3 Nov 2016 20:18:36 +0100
Subject: Sub-word comparisons
In-Reply-To: <b08602c9-9e1a-6ca4-63ff-ae48ce63761b@redhat.com>
References: <b08602c9-9e1a-6ca4-63ff-ae48ce63761b@redhat.com>
Message-ID: <AC90BEF5-39BB-4542-AAA5-9915ED68966B@oracle.com>

The lowering of a CompareNode to a CompareOp is AArch64 specific as far as I can see. This originates from the AArch64 implementations of LIRGenerator.emitCompareBranch and LIRGenerator.emitConditionalMove. You?ll have to change those methods to generate LIR ops that AArch64 actually supports.

-Doug

> On 3 Nov 2016, at 18:01, Andrew Haley <aph at redhat.com> wrote:
> 
> I've got a tricky bug that I can't figure out how to fix.
> 
> I'm seeing comparisons of mixed types, and I can't figure out how to
> generate decent code for them.
> 
> For example, I see a
> 
>  CompareNode(x: i8, y: i8)
> 
> which gets lowered to
> 
>  Compare(PlatformKind = BYTE, left: v59|DWORD, right: byte[0|0x0])
> 
> so I guess I'm supposed only to be comparing the bottom 8 bits of the
> register.  But I can't do that: I can only compare 32- or 64-bit
> quantities.  It would be possible but extremely ugly to do it by
> shifting both quantities left and then doing the comparison.
> 
> It would be extremely nice if I could tell Graal that I can't do
> subword arithmetic of any kind.  Is anything like that possible?
> 
> Andrew.


From aph at redhat.com  Thu Nov  3 19:24:17 2016
From: aph at redhat.com (Andrew Haley)
Date: Thu, 3 Nov 2016 19:24:17 +0000
Subject: Sub-word comparisons
In-Reply-To: <AC90BEF5-39BB-4542-AAA5-9915ED68966B@oracle.com>
References: <b08602c9-9e1a-6ca4-63ff-ae48ce63761b@redhat.com>
	<AC90BEF5-39BB-4542-AAA5-9915ED68966B@oracle.com>
Message-ID: <ea4cf236-8c06-41a8-b7e6-4561a79bf68f@redhat.com>

On 03/11/16 19:18, Doug Simon wrote:

> The lowering of a CompareNode to a CompareOp is AArch64 specific as
> far as I can see. This originates from the AArch64 implementations
> of LIRGenerator.emitCompareBranch and
> LIRGenerator.emitConditionalMove. You?ll have to change those
> methods to generate LIR ops that AArch64 actually supports.

Oh sure, I can do that, but that wasn't my problem, it was how to stop
Graal from creating sub-word comparisons in the first place.  Such
operations aren't part of the JVM at all, but are generated when the
bytecode is canonicalized.  I can generate code for sub-word
comparisons, but it won't be good code.  AArch64 is designed to work
well for languages like C and Java, which don't have any arithmetic
operations on sub-word types.

Andrew.


From tom.rodriguez at oracle.com  Thu Nov  3 19:49:45 2016
From: tom.rodriguez at oracle.com (Tom Rodriguez)
Date: Thu, 3 Nov 2016 12:49:45 -0700
Subject: Sub-word comparisons
In-Reply-To: <ea4cf236-8c06-41a8-b7e6-4561a79bf68f@redhat.com>
References: <b08602c9-9e1a-6ca4-63ff-ae48ce63761b@redhat.com>
	<AC90BEF5-39BB-4542-AAA5-9915ED68966B@oracle.com>
	<ea4cf236-8c06-41a8-b7e6-4561a79bf68f@redhat.com>
Message-ID: <F141A2A9-4E45-48EF-885E-66268358130C@oracle.com>


> On Nov 3, 2016, at 12:24 PM, Andrew Haley <aph at redhat.com> wrote:
> 
> On 03/11/16 19:18, Doug Simon wrote:
> 
>> The lowering of a CompareNode to a CompareOp is AArch64 specific as
>> far as I can see. This originates from the AArch64 implementations
>> of LIRGenerator.emitCompareBranch and
>> LIRGenerator.emitConditionalMove. You?ll have to change those
>> methods to generate LIR ops that AArch64 actually supports.
> 
> Oh sure, I can do that, but that wasn't my problem, it was how to stop
> Graal from creating sub-word comparisons in the first place.  Such
> operations aren't part of the JVM at all, but are generated when the
> bytecode is canonicalized.  I can generate code for sub-word
> comparisons, but it won't be good code.  AArch64 is designed to work
> well for languages like C and Java, which don't have any arithmetic
> operations on sub-word types.

I think SPARC has the same restrictions so it should be possible to make it work.  Can find you find the equivalent path in the SPARC sources?  For instance I can see that com.oracle.graal.compiler.sparc.SPARCLIRGenerator.emitCompareBranch asserts that the actual compares are with WORD or XWORD which is 4 or 8 bytes respectively.

Roland might be able to give a better answer for this.  I thought we?d stamped out the sub word operations are while back.

tom

From doug.simon at oracle.com  Thu Nov  3 19:51:50 2016
From: doug.simon at oracle.com (Doug Simon)
Date: Thu, 3 Nov 2016 20:51:50 +0100
Subject: Sub-word comparisons
In-Reply-To: <ea4cf236-8c06-41a8-b7e6-4561a79bf68f@redhat.com>
References: <b08602c9-9e1a-6ca4-63ff-ae48ce63761b@redhat.com>
	<AC90BEF5-39BB-4542-AAA5-9915ED68966B@oracle.com>
	<ea4cf236-8c06-41a8-b7e6-4561a79bf68f@redhat.com>
Message-ID: <438B9323-91C6-468C-8415-2BCF114C7D9A@oracle.com>


> On 3 Nov 2016, at 20:24, Andrew Haley <aph at redhat.com> wrote:
> 
> On 03/11/16 19:18, Doug Simon wrote:
> 
>> The lowering of a CompareNode to a CompareOp is AArch64 specific as
>> far as I can see. This originates from the AArch64 implementations
>> of LIRGenerator.emitCompareBranch and
>> LIRGenerator.emitConditionalMove. You?ll have to change those
>> methods to generate LIR ops that AArch64 actually supports.
> 
> Oh sure, I can do that, but that wasn't my problem, it was how to stop
> Graal from creating sub-word comparisons in the first place.  Such
> operations aren't part of the JVM at all, but are generated when the
> bytecode is canonicalized.  I can generate code for sub-word
> comparisons, but it won't be good code.  AArch64 is designed to work
> well for languages like C and Java, which don't have any arithmetic
> operations on sub-word types.

I?m not sure where (or if) Graal generates sub-word comparisons nowadays so am not sure where we?d have to add a capability check. Have you seen it occur? I?ve just run all our unit tests as well as a bootstrap and never saw it occur.

-Doug

From tom.rodriguez at oracle.com  Thu Nov  3 19:58:58 2016
From: tom.rodriguez at oracle.com (Tom Rodriguez)
Date: Thu, 3 Nov 2016 12:58:58 -0700
Subject: Sub-word comparisons
In-Reply-To: <438B9323-91C6-468C-8415-2BCF114C7D9A@oracle.com>
References: <b08602c9-9e1a-6ca4-63ff-ae48ce63761b@redhat.com>
	<AC90BEF5-39BB-4542-AAA5-9915ED68966B@oracle.com>
	<ea4cf236-8c06-41a8-b7e6-4561a79bf68f@redhat.com>
	<438B9323-91C6-468C-8415-2BCF114C7D9A@oracle.com>
Message-ID: <8C0FEDDB-E316-4176-98EA-BD2A742F157E@oracle.com>


> On Nov 3, 2016, at 12:51 PM, Doug Simon <doug.simon at oracle.com> wrote:
> 
> 
>> On 3 Nov 2016, at 20:24, Andrew Haley <aph at redhat.com> wrote:
>> 
>> On 03/11/16 19:18, Doug Simon wrote:
>> 
>>> The lowering of a CompareNode to a CompareOp is AArch64 specific as
>>> far as I can see. This originates from the AArch64 implementations
>>> of LIRGenerator.emitCompareBranch and
>>> LIRGenerator.emitConditionalMove. You?ll have to change those
>>> methods to generate LIR ops that AArch64 actually supports.
>> 
>> Oh sure, I can do that, but that wasn't my problem, it was how to stop
>> Graal from creating sub-word comparisons in the first place.  Such
>> operations aren't part of the JVM at all, but are generated when the
>> bytecode is canonicalized.  I can generate code for sub-word
>> comparisons, but it won't be good code.  AArch64 is designed to work
>> well for languages like C and Java, which don't have any arithmetic
>> operations on sub-word types.
> 
> I?m not sure where (or if) Graal generates sub-word comparisons nowadays so am not sure where we?d have to add a capability check. Have you seen it occur? I?ve just run all our unit tests as well as a bootstrap and never saw it occur.

I believe they can fall out of other transformations like the stripping of conversions, like Compare(ZeroExtend(x), ZeroExtend(y)) -> Compare(x, y).  I suspect the way this is supposed to work is that the if your backend doesn?t really support sub word types then it should never produce them.  So even if x is an i8 at the Node level the LIR operation should produce a word in the platform kind.  And LIR generation should be driven by the LIR types, not by the types in the HIR.  I suspect that AArch64 is just slightly out of date with that change.

tom

From aph at redhat.com  Fri Nov  4 11:46:52 2016
From: aph at redhat.com (Andrew Haley)
Date: Fri, 4 Nov 2016 11:46:52 +0000
Subject: Sub-word comparisons
In-Reply-To: <8C0FEDDB-E316-4176-98EA-BD2A742F157E@oracle.com>
References: <b08602c9-9e1a-6ca4-63ff-ae48ce63761b@redhat.com>
	<AC90BEF5-39BB-4542-AAA5-9915ED68966B@oracle.com>
	<ea4cf236-8c06-41a8-b7e6-4561a79bf68f@redhat.com>
	<438B9323-91C6-468C-8415-2BCF114C7D9A@oracle.com>
	<8C0FEDDB-E316-4176-98EA-BD2A742F157E@oracle.com>
Message-ID: <19225c0e-587c-322e-dc26-70f5ccc783a1@redhat.com>

On 03/11/16 19:58, Tom Rodriguez wrote:
> 
> I believe they can fall out of other transformations like the
> stripping of conversions, like Compare(ZeroExtend(x), ZeroExtend(y))
> -> Compare(x, y). 

Exactly so.

> I suspect the way this is supposed to work is that the if your
> backend doesn?t really support sub word types then it should never
> produce them.  So even if x is an i8 at the Node level the LIR
> operation should produce a word in the platform kind.

I get that, but how?  I'm trying to figure out a good way to generate
LIR to produce a word in the platform kind.

I was thinking about this in AArch64LIRGenerator.emitCompare but it's
ugly:

     if (size != 32 && size != 64) {
         Variable left1 = newVariable(LIRKind.value(target().arch.getWordKind()));
         Variable right1 = newVariable(LIRKind.value(target().arch.getWordKind()));
         append(new AArch64SignExtendOp(left1, load(a), size, 64));
         append(new AArch64SignExtendOp(right1, load(b), size, 64));
         a = left1;
         b = right1;
     }

(I need to be a bit more clever about sign-extending constants, but
more detail would obfuscate the point.)

Ah, I just looked at SPARC, and it does the exact same thing:

        int compareBytes = cmpKind.getSizeInBytes();
        // SPARC compares 32 or 64 bits
        if (compareBytes < left.getPlatformKind().getSizeInBytes()) {
            left = arithmeticLIRGen.emitSignExtend(left, compareBytes * 8, XWORD.getSizeInBytes() * 8);
        }
        if (compareBytes < right.getPlatformKind().getSizeInBytes()) {
            right = arithmeticLIRGen.emitSignExtend(right, compareBytes * 8, XWORD.getSizeInBytes() * 8);
        }

OK, I give up.  That must be the only way to do it.

Andrew.

From roland.schatz at oracle.com  Fri Nov  4 12:16:16 2016
From: roland.schatz at oracle.com (Roland Schatz)
Date: Fri, 4 Nov 2016 13:16:16 +0100
Subject: Sub-word comparisons
In-Reply-To: <19225c0e-587c-322e-dc26-70f5ccc783a1@redhat.com>
References: <b08602c9-9e1a-6ca4-63ff-ae48ce63761b@redhat.com>
	<AC90BEF5-39BB-4542-AAA5-9915ED68966B@oracle.com>
	<ea4cf236-8c06-41a8-b7e6-4561a79bf68f@redhat.com>
	<438B9323-91C6-468C-8415-2BCF114C7D9A@oracle.com>
	<8C0FEDDB-E316-4176-98EA-BD2A742F157E@oracle.com>
	<19225c0e-587c-322e-dc26-70f5ccc783a1@redhat.com>
Message-ID: <95539f00-f41e-ac3d-b4f2-cbb10f67970e@oracle.com>

On 11/04/2016 12:46 PM, Andrew Haley wrote:
> Ah, I just looked at SPARC, and it does the exact same thing:
>
>          int compareBytes = cmpKind.getSizeInBytes();
>          // SPARC compares 32 or 64 bits
>          if (compareBytes < left.getPlatformKind().getSizeInBytes()) {
>              left = arithmeticLIRGen.emitSignExtend(left, compareBytes * 8, XWORD.getSizeInBytes() * 8);
>          }
>          if (compareBytes < right.getPlatformKind().getSizeInBytes()) {
>              right = arithmeticLIRGen.emitSignExtend(right, compareBytes * 8, XWORD.getSizeInBytes() * 8);
>          }
>
> OK, I give up.  That must be the only way to do it.
Yes, unfortunately that's the only way to do it right now.

The issue comes from the x86 backend, where doing sub-word comparisons 
sometimes makes code faster. In hindsight, the decision to do this 
optimization in the platform independent code was wrong. When this code 
was written, there was only the x86 backend, and it was easier to do it 
that way.

In general, the convention in graal is that if a platform doesn't 
support some operation, then this operation should not exist in the 
final high-level graph. Most of the time, we're doing this with platform 
specific phases or lowerings.
In this particular case, I think the best fix is to move the 
optimization that produces the sub-word compares to x86-specific code, 
i.e., never produce them on platforms that don't support them instead of 
having to back out after the fact.

Since we already have two backends that stumble over it, I think it's 
time to look into fixing this ;)
I think it shouldn't be too hard. In the meantime, you can just copy the 
SPARC workaround.

- Roland
>
> Andrew.



From roland.schatz at oracle.com  Mon Nov  7 10:34:27 2016
From: roland.schatz at oracle.com (Roland Schatz)
Date: Mon, 7 Nov 2016 11:34:27 +0100
Subject: Sub-word comparisons
In-Reply-To: <95539f00-f41e-ac3d-b4f2-cbb10f67970e@oracle.com>
References: <b08602c9-9e1a-6ca4-63ff-ae48ce63761b@redhat.com>
	<AC90BEF5-39BB-4542-AAA5-9915ED68966B@oracle.com>
	<ea4cf236-8c06-41a8-b7e6-4561a79bf68f@redhat.com>
	<438B9323-91C6-468C-8415-2BCF114C7D9A@oracle.com>
	<8C0FEDDB-E316-4176-98EA-BD2A742F157E@oracle.com>
	<19225c0e-587c-322e-dc26-70f5ccc783a1@redhat.com>
	<95539f00-f41e-ac3d-b4f2-cbb10f67970e@oracle.com>
Message-ID: <4a0aef64-b839-639b-680f-b931fb27b327@oracle.com>

On 11/04/2016 01:16 PM, Roland Schatz wrote:
> On 11/04/2016 12:46 PM, Andrew Haley wrote:
>> Ah, I just looked at SPARC, and it does the exact same thing:
>>
>>          int compareBytes = cmpKind.getSizeInBytes();
>>          // SPARC compares 32 or 64 bits
>>          if (compareBytes < left.getPlatformKind().getSizeInBytes()) {
>>              left = arithmeticLIRGen.emitSignExtend(left, 
>> compareBytes * 8, XWORD.getSizeInBytes() * 8);
>>          }
>>          if (compareBytes < right.getPlatformKind().getSizeInBytes()) {
>>              right = arithmeticLIRGen.emitSignExtend(right, 
>> compareBytes * 8, XWORD.getSizeInBytes() * 8);
>>          }
>>
>> OK, I give up.  That must be the only way to do it.
> Yes, unfortunately that's the only way to do it right now.
>
> The issue comes from the x86 backend, where doing sub-word comparisons 
> sometimes makes code faster. In hindsight, the decision to do this 
> optimization in the platform independent code was wrong. When this 
> code was written, there was only the x86 backend, and it was easier to 
> do it that way.
>
> In general, the convention in graal is that if a platform doesn't 
> support some operation, then this operation should not exist in the 
> final high-level graph. Most of the time, we're doing this with 
> platform specific phases or lowerings.
> In this particular case, I think the best fix is to move the 
> optimization that produces the sub-word compares to x86-specific code, 
> i.e., never produce them on platforms that don't support them instead 
> of having to back out after the fact.
>
> Since we already have two backends that stumble over it, I think it's 
> time to look into fixing this ;)
> I think it shouldn't be too hard. In the meantime, you can just copy 
> the SPARC workaround.
Should be fixed 
(https://github.com/graalvm/graal-core/commit/e276a1dc73876559f2ada69797dcb961076b51f0).

- Roland
>
> - Roland
>>
>> Andrew.
>
>


From aph at redhat.com  Mon Nov  7 12:09:11 2016
From: aph at redhat.com (Andrew Haley)
Date: Mon, 7 Nov 2016 12:09:11 +0000
Subject: Sub-word comparisons
In-Reply-To: <4a0aef64-b839-639b-680f-b931fb27b327@oracle.com>
References: <b08602c9-9e1a-6ca4-63ff-ae48ce63761b@redhat.com>
	<AC90BEF5-39BB-4542-AAA5-9915ED68966B@oracle.com>
	<ea4cf236-8c06-41a8-b7e6-4561a79bf68f@redhat.com>
	<438B9323-91C6-468C-8415-2BCF114C7D9A@oracle.com>
	<8C0FEDDB-E316-4176-98EA-BD2A742F157E@oracle.com>
	<19225c0e-587c-322e-dc26-70f5ccc783a1@redhat.com>
	<95539f00-f41e-ac3d-b4f2-cbb10f67970e@oracle.com>
	<4a0aef64-b839-639b-680f-b931fb27b327@oracle.com>
Message-ID: <710d1ee0-6cd1-38b7-62a0-73984fe27e40@redhat.com>

On 07/11/16 10:34, Roland Schatz wrote:
> Should be fixed 
> (https://github.com/graalvm/graal-core/commit/e276a1dc73876559f2ada69797dcb961076b51f0).

Lovely!

Thanks,

Andrew.


From doug.simon at oracle.com  Tue Nov  8 14:31:08 2016
From: doug.simon at oracle.com (Doug Simon)
Date: Tue, 8 Nov 2016 15:31:08 +0100
Subject: Graal now works with JDK 9 Early Access Release
Message-ID: <FBFB37E4-3182-4633-8B77-6D0D078D932F@oracle.com>

Hi all,

As of https://github.com/graalvm/graal-core/commit/be67a0e8c94ae01f7076bd76d244d84b120c571f, Graal works with build 143 or later of a JDK9 Early Access Release[1].

Please file issues at https://github.com/graalvm/graal-core/issues if you run into problem running Graal on JDK9.

-Doug

[1] https://jdk9.java.net/download/




From raffaello.giulietti at supsi.ch  Tue Nov  8 14:58:44 2016
From: raffaello.giulietti at supsi.ch (Raffaello Giulietti)
Date: Tue, 8 Nov 2016 15:58:44 +0100
Subject: Graal now works with JDK 9 Early Access Release
In-Reply-To: <FBFB37E4-3182-4633-8B77-6D0D078D932F@oracle.com>
References: <FBFB37E4-3182-4633-8B77-6D0D078D932F@oracle.com>
Message-ID: <47a8258c-a7a0-7844-3977-0ecb9815a35f@supsi.ch>

Great!
Will this be the case even with the Jigsaw build 143 when it becomes 
available at https://jdk9.java.net/jigsaw/ ?

Raffaello


On 2016-11-08 15:31, Doug Simon wrote:
> Hi all,
>
> As of https://github.com/graalvm/graal-core/commit/be67a0e8c94ae01f7076bd76d244d84b120c571f, Graal works with build 143 or later of a JDK9 Early Access Release[1].
>
> Please file issues at https://github.com/graalvm/graal-core/issues if you run into problem running Graal on JDK9.
>
> -Doug
>
> [1] https://jdk9.java.net/download/
>
>
>


From doug.simon at oracle.com  Tue Nov  8 15:23:15 2016
From: doug.simon at oracle.com (Doug Simon)
Date: Tue, 8 Nov 2016 16:23:15 +0100
Subject: Graal now works with JDK 9 Early Access Release
In-Reply-To: <47a8258c-a7a0-7844-3977-0ecb9815a35f@supsi.ch>
References: <FBFB37E4-3182-4633-8B77-6D0D078D932F@oracle.com>
	<47a8258c-a7a0-7844-3977-0ecb9815a35f@supsi.ch>
Message-ID: <829700C4-E27E-43D0-BAC2-33D9E67C880A@oracle.com>

Sorry, I have no idea about whether it will work with the Jigsaw EA builds (I was not aware these EA builds still existed!).

Please let us know on this list if you try these EA builds and they work (or not).

-Doug

> On 8 Nov 2016, at 15:58, Raffaello Giulietti <raffaello.giulietti at supsi.ch> wrote:
> 
> Great!
> Will this be the case even with the Jigsaw build 143 when it becomes available at https://jdk9.java.net/jigsaw/ ?
> 
> Raffaello
> 
> 
> On 2016-11-08 15:31, Doug Simon wrote:
>> Hi all,
>> 
>> As of https://github.com/graalvm/graal-core/commit/be67a0e8c94ae01f7076bd76d244d84b120c571f, Graal works with build 143 or later of a JDK9 Early Access Release[1].
>> 
>> Please file issues at https://github.com/graalvm/graal-core/issues if you run into problem running Graal on JDK9.
>> 
>> -Doug
>> 
>> [1] https://jdk9.java.net/download/
>> 
>> 
>> 
> 


From raffaello.giulietti at supsi.ch  Tue Nov  8 15:43:58 2016
From: raffaello.giulietti at supsi.ch (Raffaello Giulietti)
Date: Tue, 8 Nov 2016 16:43:58 +0100
Subject: Graal now works with JDK 9 Early Access Release
In-Reply-To: <829700C4-E27E-43D0-BAC2-33D9E67C880A@oracle.com>
References: <FBFB37E4-3182-4633-8B77-6D0D078D932F@oracle.com>
	<47a8258c-a7a0-7844-3977-0ecb9815a35f@supsi.ch>
	<829700C4-E27E-43D0-BAC2-33D9E67C880A@oracle.com>
Message-ID: <ce85e895-7334-5b81-c414-9fb7d899d617@supsi.ch>

OK, I'll give it a try once available.


On 2016-11-08 16:23, Doug Simon wrote:
> Sorry, I have no idea about whether it will work with the Jigsaw EA builds (I was not aware these EA builds still existed!).
>
> Please let us know on this list if you try these EA builds and they work (or not).
>
> -Doug
>
>> On 8 Nov 2016, at 15:58, Raffaello Giulietti <raffaello.giulietti at supsi.ch> wrote:
>>
>> Great!
>> Will this be the case even with the Jigsaw build 143 when it becomes available at https://jdk9.java.net/jigsaw/ ?
>>
>> Raffaello
>>
>>
>> On 2016-11-08 15:31, Doug Simon wrote:
>>> Hi all,
>>>
>>> As of https://github.com/graalvm/graal-core/commit/be67a0e8c94ae01f7076bd76d244d84b120c571f, Graal works with build 143 or later of a JDK9 Early Access Release[1].
>>>
>>> Please file issues at https://github.com/graalvm/graal-core/issues if you run into problem running Graal on JDK9.
>>>
>>> -Doug
>>>
>>> [1] https://jdk9.java.net/download/
>>>
>>>
>>>
>>
>


From doug.simon at oracle.com  Tue Nov  8 22:18:38 2016
From: doug.simon at oracle.com (Doug Simon)
Date: Tue, 8 Nov 2016 23:18:38 +0100
Subject: Graal now works with JDK 9 Early Access Release
In-Reply-To: <FBFB37E4-3182-4633-8B77-6D0D078D932F@oracle.com>
References: <FBFB37E4-3182-4633-8B77-6D0D078D932F@oracle.com>
Message-ID: <ACCC8BE1-956E-433D-A4AA-E90F301A8E90@oracle.com>

In case you are new to Graal, please follow the directions at https://github.com/graalvm/graal-core/blob/master/README.md#building-graal to see how to use JDK9 with Graal.

Due to the extra compile and run time options required to build and deploy Graal (and Truffle) as modules on JDK9, using mx is highly recommended. If you want to avoid using mx to launch the VM, run your command once with mx and the -v option to see the type of java launcher command you will need to use. For example:

dsimon at kurz-2 ~/h/graal-core> mx -v vm -XX:+BootstrapJVMCI -XX:+UseJVMCICompiler -version
...
/Library/Java/JavaVirtualMachines/labsjdk-9-ea+143/bin/java -server -XX:+UnlockExperimentalVMOptions -XX:+EnableJVMCI -d64 --add-exports=java.base/jdk.internal.module=com.oracle.graal.graal_core --module-path=/Users/dsimon/hs/truffle/mxbuild/modules/com.oracle.truffle.truffle_api.jar:/Users/dsimon/hs/graal-core/mxbuild/modules/com.oracle.graal.graal_core.jar -XX:+BootstrapJVMCI -XX:+UseJVMCICompiler -version
Bootstrapping JVMCI.......................... in 9433 ms (compiled 2608 methods)
java version "9-ea"
Java(TM) SE Runtime Environment (build 9-ea+143)
Java HotSpot(TM) 64-Bit Server VM (build 9-ea+143, mixed mode)

-Doug

> On 8 Nov 2016, at 15:31, Doug Simon <doug.simon at oracle.com> wrote:
> 
> Hi all,
> 
> As of https://github.com/graalvm/graal-core/commit/be67a0e8c94ae01f7076bd76d244d84b120c571f, Graal works with build 143 or later of a JDK9 Early Access Release[1].
> 
> Please file issues at https://github.com/graalvm/graal-core/issues if you run into problem running Graal on JDK9.
> 
> -Doug
> 
> [1] https://jdk9.java.net/download/
> 
> 
> 


From christian.humer at gmail.com  Wed Nov  9 18:34:17 2016
From: christian.humer at gmail.com (Christian Humer)
Date: Wed, 09 Nov 2016 18:34:17 +0000
Subject: GraalVM 0.18 release
Message-ID: <emecf14ecd-e0be-47d2-a2db-e724365caf5b@grashalm-work>

Hi guys,

GraalVM 0.18 with the latest bits of Graal, Truffle, Graal.JS, 
Ruby+Truffle and FastR just landed on OTN.

Besides the latest bits, we have added builds for the Solaris SPARC 
platform.

The bits are based on Truffle 0.19 and LabsJDK 8 with JVMCI 0.22.

Get it here:
http://www.oracle.com/technetwork/oracle-labs/program-languages/downloads/index.html

Next release is planned for early December.

Cheers,
Christian Humer


From aph at redhat.com  Thu Nov 10 18:48:43 2016
From: aph at redhat.com (Andrew Haley)
Date: Thu, 10 Nov 2016 18:48:43 +0000
Subject: Missing membar for constructors
Message-ID: <2441be06-a3d9-074d-0b71-4e78e613c60b@redhat.com>

I've been getting some weird crashes, and tracked it down to a missing
membar in constructors, where a final field can be published unsafely.
Patch appended.  I found this very surprising, but there doesn't seem
to be any code anywhere in Graal to handle this correctly.

Andrew.

diff --git a/graal/com.oracle.graal.java/src/com/oracle/graal/java/BytecodeParser.java b/graal/com.oracle.graal.java/src/com/oracle/graal/java/BytecodeParser.java
index e51910c..a01be9e 100644
--- a/graal/com.oracle.graal.java/src/com/oracle/graal/java/BytecodeParser.java
+++ b/graal/com.oracle.graal.java/src/com/oracle/graal/java/BytecodeParser.java
@@ -239,6 +239,8 @@ import static com.oracle.graal.java.BytecodeParserOptions.TraceParserPlugins;
 import static com.oracle.graal.nodes.graphbuilderconf.IntrinsicContext.CompilationContext.INLINE_DURING_PARSING;
 import static com.oracle.graal.nodes.type.StampTool.isPointerNonNull;
 import static java.lang.String.format;
+import static jdk.vm.ci.code.MemoryBarriers.LOAD_STORE;
+import static jdk.vm.ci.code.MemoryBarriers.STORE_STORE;
 import static jdk.vm.ci.meta.DeoptimizationAction.InvalidateRecompile;
 import static jdk.vm.ci.meta.DeoptimizationAction.InvalidateReprofile;
 import static jdk.vm.ci.meta.DeoptimizationReason.JavaSubroutineMismatch;
@@ -360,6 +362,7 @@ import com.oracle.graal.nodes.extended.BytecodeExceptionNode;
 import com.oracle.graal.nodes.extended.GuardedNode;
 import com.oracle.graal.nodes.extended.GuardingNode;
 import com.oracle.graal.nodes.extended.IntegerSwitchNode;
+import com.oracle.graal.nodes.extended.MembarNode;
 import com.oracle.graal.nodes.extended.ValueAnchorNode;
 import com.oracle.graal.nodes.graphbuilderconf.GraphBuilderConfiguration;
 import com.oracle.graal.nodes.graphbuilderconf.GraphBuilderConfiguration.BytecodeExceptionMode;
@@ -587,6 +590,8 @@ public class BytecodeParser implements GraphBuilderContext {

     private int lastBCI; // BCI of lastInstr. This field is for resolving instrumentation target.

+    private boolean needsReturnMembar = false; // Constructor has write to final field.
+
     protected BytecodeParser(GraphBuilderPhase.Instance graphBuilderInstance, StructuredGraph graph, BytecodeParser parent, ResolvedJavaMethod method,
                     int entryBCI, IntrinsicContext intrinsicContext) {
         this.code = intrinsicContext == null ? new ResolvedJavaMethodBytecode(method) : intrinsicContext.getBytecodeProvider().getBytecode(method);
@@ -606,6 +611,7 @@ public class BytecodeParser implements GraphBuilderContext {
         this.entryBCI = entryBCI;
         this.parent = parent;
         this.lastBCI = -1;
+        this.needsReturnMembar = false;

         assert code.getCode() != null : "method must contain bytecodes: " + method;

@@ -1216,6 +1222,9 @@ public class BytecodeParser implements GraphBuilderContext {
         StoreFieldNode storeFieldNode = new StoreFieldNode(receiver, field, value);
         append(storeFieldNode);
         storeFieldNode.setStateAfter(this.createFrameState(stream.nextBCI(), storeFieldNode));
+        if (field.isFinal() && method.isConstructor()) {
+            needsReturnMembar = true;
+        }
     }

     /**
@@ -1794,20 +1803,27 @@ public class BytecodeParser implements GraphBuilderContext {
     }

     private void beforeReturn(ValueNode x, JavaKind kind) {
-        if (graph.method() != null && graph.method().isJavaLangObjectInit()) {
-            /*
-             * Get the receiver from the initial state since bytecode rewriting could do arbitrary
-             * things to the state of the locals.
-             */
-            ValueNode receiver = graph.start().stateAfter().localAt(0);
-            assert receiver != null && receiver.getStackKind() == JavaKind.Object;
-            if (RegisterFinalizerNode.mayHaveFinalizer(receiver, graph.getAssumptions())) {
-                append(new RegisterFinalizerNode(receiver));
+        if (graph.method() != null) {
+            if (needsReturnMembar) {
+                // append(new MembarNode(LOAD_STORE | STORE_STORE));
             }
-        }
-        genInfoPointNode(InfopointReason.METHOD_END, x);

-        synchronizedEpilogue(BytecodeFrame.AFTER_BCI, x, kind);
+            if (graph.method().isJavaLangObjectInit()) {
+                /*
+                 * Get the receiver from the initial state since bytecode rewriting could do
+                 * arbitrary things to the state of the locals.
+                 */
+                ValueNode receiver = graph.start().stateAfter().localAt(0);
+                assert receiver != null && receiver.getStackKind() == JavaKind.Object;
+                if (RegisterFinalizerNode.mayHaveFinalizer(receiver, graph.getAssumptions())) {
+                    append(new RegisterFinalizerNode(receiver));
+                }
+
+                genInfoPointNode(InfopointReason.METHOD_END, x);
+
+                synchronizedEpilogue(BytecodeFrame.AFTER_BCI, x, kind);
+            }
+        }
     }

     protected MonitorEnterNode createMonitorEnterNode(ValueNode x, MonitorIdNode monitorId) {


From aph at redhat.com  Thu Nov 10 18:59:06 2016
From: aph at redhat.com (Andrew Haley)
Date: Thu, 10 Nov 2016 18:59:06 +0000
Subject: Missing membar for constructors
Message-ID: <f916365d-65e8-d209-caed-a43cb96fd094@redhat.com>

[Sorry, previous patch was wrong.]


I've been getting some weird crashes, and tracked it down to a missing
membar in constructors, where a final field can be published unsafely.
Patch appended.  I found this very surprising, but there doesn't seem
to be any code anywhere in Graal to handle this correctly.

Andrew.

diff --git a/graal/com.oracle.graal.java/src/com/oracle/graal/java/BytecodeParser.java b/graal/com.oracle.graal.java/src/com/oracle/graal/java/BytecodeParser.java
index e51910c..a01be9e 100644
--- a/graal/com.oracle.graal.java/src/com/oracle/graal/java/BytecodeParser.java
+++ b/graal/com.oracle.graal.java/src/com/oracle/graal/java/BytecodeParser.java
@@ -239,6 +239,8 @@ import static com.oracle.graal.java.BytecodeParserOptions.TraceParserPlugins;
 import static com.oracle.graal.nodes.graphbuilderconf.IntrinsicContext.CompilationContext.INLINE_DURING_PARSING;
 import static com.oracle.graal.nodes.type.StampTool.isPointerNonNull;
 import static java.lang.String.format;
+import static jdk.vm.ci.code.MemoryBarriers.LOAD_STORE;
+import static jdk.vm.ci.code.MemoryBarriers.STORE_STORE;
 import static jdk.vm.ci.meta.DeoptimizationAction.InvalidateRecompile;
 import static jdk.vm.ci.meta.DeoptimizationAction.InvalidateReprofile;
 import static jdk.vm.ci.meta.DeoptimizationReason.JavaSubroutineMismatch;
@@ -360,6 +362,7 @@ import com.oracle.graal.nodes.extended.BytecodeExceptionNode;
 import com.oracle.graal.nodes.extended.GuardedNode;
 import com.oracle.graal.nodes.extended.GuardingNode;
 import com.oracle.graal.nodes.extended.IntegerSwitchNode;
+import com.oracle.graal.nodes.extended.MembarNode;
 import com.oracle.graal.nodes.extended.ValueAnchorNode;
 import com.oracle.graal.nodes.graphbuilderconf.GraphBuilderConfiguration;
 import com.oracle.graal.nodes.graphbuilderconf.GraphBuilderConfiguration.BytecodeExceptionMode;
@@ -587,6 +590,8 @@ public class BytecodeParser implements GraphBuilderContext {

     private int lastBCI; // BCI of lastInstr. This field is for resolving instrumentation target.

+    private boolean needsReturnMembar = false; // Constructor has write to final field.
+
     protected BytecodeParser(GraphBuilderPhase.Instance graphBuilderInstance, StructuredGraph graph, BytecodeParser parent, ResolvedJavaMethod method,
                     int entryBCI, IntrinsicContext intrinsicContext) {
         this.code = intrinsicContext == null ? new ResolvedJavaMethodBytecode(method) : intrinsicContext.getBytecodeProvider().getBytecode(method);
@@ -606,6 +611,7 @@ public class BytecodeParser implements GraphBuilderContext {
         this.entryBCI = entryBCI;
         this.parent = parent;
         this.lastBCI = -1;
+        this.needsReturnMembar = false;

         assert code.getCode() != null : "method must contain bytecodes: " + method;

@@ -1216,6 +1222,9 @@ public class BytecodeParser implements GraphBuilderContext {
         StoreFieldNode storeFieldNode = new StoreFieldNode(receiver, field, value);
         append(storeFieldNode);
         storeFieldNode.setStateAfter(this.createFrameState(stream.nextBCI(), storeFieldNode));
+        if (field.isFinal() && method.isConstructor()) {
+            needsReturnMembar = true;
+        }
     }

     /**
@@ -1794,20 +1803,27 @@ public class BytecodeParser implements GraphBuilderContext {
     }

     private void beforeReturn(ValueNode x, JavaKind kind) {
-        if (graph.method() != null && graph.method().isJavaLangObjectInit()) {
-            /*
-             * Get the receiver from the initial state since bytecode rewriting could do arbitrary
-             * things to the state of the locals.
-             */
-            ValueNode receiver = graph.start().stateAfter().localAt(0);
-            assert receiver != null && receiver.getStackKind() == JavaKind.Object;
-            if (RegisterFinalizerNode.mayHaveFinalizer(receiver, graph.getAssumptions())) {
-                append(new RegisterFinalizerNode(receiver));
+        if (graph.method() != null) {
+            if (needsReturnMembar) {
+                append(new MembarNode(LOAD_STORE | STORE_STORE));
             }
-        }
-        genInfoPointNode(InfopointReason.METHOD_END, x);

-        synchronizedEpilogue(BytecodeFrame.AFTER_BCI, x, kind);
+            if (graph.method().isJavaLangObjectInit()) {
+                /*
+                 * Get the receiver from the initial state since bytecode rewriting could do
+                 * arbitrary things to the state of the locals.
+                 */
+                ValueNode receiver = graph.start().stateAfter().localAt(0);
+                assert receiver != null && receiver.getStackKind() == JavaKind.Object;
+                if (RegisterFinalizerNode.mayHaveFinalizer(receiver, graph.getAssumptions())) {
+                    append(new RegisterFinalizerNode(receiver));
+                }
+
+                genInfoPointNode(InfopointReason.METHOD_END, x);
+
+                synchronizedEpilogue(BytecodeFrame.AFTER_BCI, x, kind);
+            }
+        }
     }

     protected MonitorEnterNode createMonitorEnterNode(ValueNode x, MonitorIdNode monitorId) {


From cthalinger at twitter.com  Thu Nov 10 19:51:20 2016
From: cthalinger at twitter.com (Christian Thalinger)
Date: Thu, 10 Nov 2016 11:51:20 -0800
Subject: Graal now works with JDK 9 Early Access Release
In-Reply-To: <FBFB37E4-3182-4633-8B77-6D0D078D932F@oracle.com>
References: <FBFB37E4-3182-4633-8B77-6D0D078D932F@oracle.com>
Message-ID: <7752F315-03D2-4F3E-ACA7-3E837D3CF0DE@twitter.com>


> On Nov 8, 2016, at 6:31 AM, Doug Simon <doug.simon at oracle.com> wrote:
> 
> Hi all,
> 
> As of https://github.com/graalvm/graal-core/commit/be67a0e8c94ae01f7076bd76d244d84b120c571f, Graal works with build 143 or later of a JDK9 Early Access Release[1].

Excellent!

> 
> Please file issues at https://github.com/graalvm/graal-core/issues if you run into problem running Graal on JDK9.
> 
> -Doug
> 
> [1] https://jdk9.java.net/download/
> 
> 
> 


From doug.simon at oracle.com  Thu Nov 10 20:02:27 2016
From: doug.simon at oracle.com (Doug Simon)
Date: Thu, 10 Nov 2016 21:02:27 +0100
Subject: Missing membar for constructors
In-Reply-To: <f916365d-65e8-d209-caed-a43cb96fd094@redhat.com>
References: <f916365d-65e8-d209-caed-a43cb96fd094@redhat.com>
Message-ID: <2386DB2F-BB55-4EA3-A859-7D36CE84F8F1@oracle.com>

Thanks Andrew, this is indeed an unfortunate bug - thanks for tracking it down.

Could you please submit your patch as a pull request at https://github.com/graalvm/graal-core so we can review/discuss it there.

-Doug

> On 10 Nov 2016, at 19:59, Andrew Haley <aph at redhat.com> wrote:
> 
> [Sorry, previous patch was wrong.]
> 
> 
> I've been getting some weird crashes, and tracked it down to a missing
> membar in constructors, where a final field can be published unsafely.
> Patch appended.  I found this very surprising, but there doesn't seem
> to be any code anywhere in Graal to handle this correctly.
> 
> Andrew.
> 
> diff --git a/graal/com.oracle.graal.java/src/com/oracle/graal/java/BytecodeParser.java b/graal/com.oracle.graal.java/src/com/oracle/graal/java/BytecodeParser.java
> index e51910c..a01be9e 100644
> --- a/graal/com.oracle.graal.java/src/com/oracle/graal/java/BytecodeParser.java
> +++ b/graal/com.oracle.graal.java/src/com/oracle/graal/java/BytecodeParser.java
> @@ -239,6 +239,8 @@ import static com.oracle.graal.java.BytecodeParserOptions.TraceParserPlugins;
> import static com.oracle.graal.nodes.graphbuilderconf.IntrinsicContext.CompilationContext.INLINE_DURING_PARSING;
> import static com.oracle.graal.nodes.type.StampTool.isPointerNonNull;
> import static java.lang.String.format;
> +import static jdk.vm.ci.code.MemoryBarriers.LOAD_STORE;
> +import static jdk.vm.ci.code.MemoryBarriers.STORE_STORE;
> import static jdk.vm.ci.meta.DeoptimizationAction.InvalidateRecompile;
> import static jdk.vm.ci.meta.DeoptimizationAction.InvalidateReprofile;
> import static jdk.vm.ci.meta.DeoptimizationReason.JavaSubroutineMismatch;
> @@ -360,6 +362,7 @@ import com.oracle.graal.nodes.extended.BytecodeExceptionNode;
> import com.oracle.graal.nodes.extended.GuardedNode;
> import com.oracle.graal.nodes.extended.GuardingNode;
> import com.oracle.graal.nodes.extended.IntegerSwitchNode;
> +import com.oracle.graal.nodes.extended.MembarNode;
> import com.oracle.graal.nodes.extended.ValueAnchorNode;
> import com.oracle.graal.nodes.graphbuilderconf.GraphBuilderConfiguration;
> import com.oracle.graal.nodes.graphbuilderconf.GraphBuilderConfiguration.BytecodeExceptionMode;
> @@ -587,6 +590,8 @@ public class BytecodeParser implements GraphBuilderContext {
> 
>     private int lastBCI; // BCI of lastInstr. This field is for resolving instrumentation target.
> 
> +    private boolean needsReturnMembar = false; // Constructor has write to final field.
> +
>     protected BytecodeParser(GraphBuilderPhase.Instance graphBuilderInstance, StructuredGraph graph, BytecodeParser parent, ResolvedJavaMethod method,
>                     int entryBCI, IntrinsicContext intrinsicContext) {
>         this.code = intrinsicContext == null ? new ResolvedJavaMethodBytecode(method) : intrinsicContext.getBytecodeProvider().getBytecode(method);
> @@ -606,6 +611,7 @@ public class BytecodeParser implements GraphBuilderContext {
>         this.entryBCI = entryBCI;
>         this.parent = parent;
>         this.lastBCI = -1;
> +        this.needsReturnMembar = false;
> 
>         assert code.getCode() != null : "method must contain bytecodes: " + method;
> 
> @@ -1216,6 +1222,9 @@ public class BytecodeParser implements GraphBuilderContext {
>         StoreFieldNode storeFieldNode = new StoreFieldNode(receiver, field, value);
>         append(storeFieldNode);
>         storeFieldNode.setStateAfter(this.createFrameState(stream.nextBCI(), storeFieldNode));
> +        if (field.isFinal() && method.isConstructor()) {
> +            needsReturnMembar = true;
> +        }
>     }
> 
>     /**
> @@ -1794,20 +1803,27 @@ public class BytecodeParser implements GraphBuilderContext {
>     }
> 
>     private void beforeReturn(ValueNode x, JavaKind kind) {
> -        if (graph.method() != null && graph.method().isJavaLangObjectInit()) {
> -            /*
> -             * Get the receiver from the initial state since bytecode rewriting could do arbitrary
> -             * things to the state of the locals.
> -             */
> -            ValueNode receiver = graph.start().stateAfter().localAt(0);
> -            assert receiver != null && receiver.getStackKind() == JavaKind.Object;
> -            if (RegisterFinalizerNode.mayHaveFinalizer(receiver, graph.getAssumptions())) {
> -                append(new RegisterFinalizerNode(receiver));
> +        if (graph.method() != null) {
> +            if (needsReturnMembar) {
> +                append(new MembarNode(LOAD_STORE | STORE_STORE));
>             }
> -        }
> -        genInfoPointNode(InfopointReason.METHOD_END, x);
> 
> -        synchronizedEpilogue(BytecodeFrame.AFTER_BCI, x, kind);
> +            if (graph.method().isJavaLangObjectInit()) {
> +                /*
> +                 * Get the receiver from the initial state since bytecode rewriting could do
> +                 * arbitrary things to the state of the locals.
> +                 */
> +                ValueNode receiver = graph.start().stateAfter().localAt(0);
> +                assert receiver != null && receiver.getStackKind() == JavaKind.Object;
> +                if (RegisterFinalizerNode.mayHaveFinalizer(receiver, graph.getAssumptions())) {
> +                    append(new RegisterFinalizerNode(receiver));
> +                }
> +
> +                genInfoPointNode(InfopointReason.METHOD_END, x);
> +
> +                synchronizedEpilogue(BytecodeFrame.AFTER_BCI, x, kind);
> +            }
> +        }
>     }
> 
>     protected MonitorEnterNode createMonitorEnterNode(ValueNode x, MonitorIdNode monitorId) {
> 


From tom.rodriguez at oracle.com  Thu Nov 10 20:13:51 2016
From: tom.rodriguez at oracle.com (Tom Rodriguez)
Date: Thu, 10 Nov 2016 12:13:51 -0800
Subject: Missing membar for constructors
In-Reply-To: <2386DB2F-BB55-4EA3-A859-7D36CE84F8F1@oracle.com>
References: <f916365d-65e8-d209-caed-a43cb96fd094@redhat.com>
	<2386DB2F-BB55-4EA3-A859-7D36CE84F8F1@oracle.com>
Message-ID: <E8147F37-3C0B-4F93-A0AF-47FFB8AA3EAC@oracle.com>


> On Nov 10, 2016, at 12:02 PM, Doug Simon <doug.simon at oracle.com> wrote:
> 
> Thanks Andrew, this is indeed an unfortunate bug - thanks for tracking it down.
> 
> Could you please submit your patch as a pull request at https://github.com/graalvm/graal-core so we can review/discuss it there.

I suspect this isn?t sufficient.  We?ll also need a barrier when we materialize CommitAllocations that include stores to final fields.  And hopefully this new barrier won?t interfere with EA.  We might need a special node to represent this so we can optimize it properly.

tom

> 
> -Doug
> 
>> On 10 Nov 2016, at 19:59, Andrew Haley <aph at redhat.com> wrote:
>> 
>> [Sorry, previous patch was wrong.]
>> 
>> 
>> I've been getting some weird crashes, and tracked it down to a missing
>> membar in constructors, where a final field can be published unsafely.
>> Patch appended.  I found this very surprising, but there doesn't seem
>> to be any code anywhere in Graal to handle this correctly.
>> 
>> Andrew.
>> 
>> diff --git a/graal/com.oracle.graal.java/src/com/oracle/graal/java/BytecodeParser.java b/graal/com.oracle.graal.java/src/com/oracle/graal/java/BytecodeParser.java
>> index e51910c..a01be9e 100644
>> --- a/graal/com.oracle.graal.java/src/com/oracle/graal/java/BytecodeParser.java
>> +++ b/graal/com.oracle.graal.java/src/com/oracle/graal/java/BytecodeParser.java
>> @@ -239,6 +239,8 @@ import static com.oracle.graal.java.BytecodeParserOptions.TraceParserPlugins;
>> import static com.oracle.graal.nodes.graphbuilderconf.IntrinsicContext.CompilationContext.INLINE_DURING_PARSING;
>> import static com.oracle.graal.nodes.type.StampTool.isPointerNonNull;
>> import static java.lang.String.format;
>> +import static jdk.vm.ci.code.MemoryBarriers.LOAD_STORE;
>> +import static jdk.vm.ci.code.MemoryBarriers.STORE_STORE;
>> import static jdk.vm.ci.meta.DeoptimizationAction.InvalidateRecompile;
>> import static jdk.vm.ci.meta.DeoptimizationAction.InvalidateReprofile;
>> import static jdk.vm.ci.meta.DeoptimizationReason.JavaSubroutineMismatch;
>> @@ -360,6 +362,7 @@ import com.oracle.graal.nodes.extended.BytecodeExceptionNode;
>> import com.oracle.graal.nodes.extended.GuardedNode;
>> import com.oracle.graal.nodes.extended.GuardingNode;
>> import com.oracle.graal.nodes.extended.IntegerSwitchNode;
>> +import com.oracle.graal.nodes.extended.MembarNode;
>> import com.oracle.graal.nodes.extended.ValueAnchorNode;
>> import com.oracle.graal.nodes.graphbuilderconf.GraphBuilderConfiguration;
>> import com.oracle.graal.nodes.graphbuilderconf.GraphBuilderConfiguration.BytecodeExceptionMode;
>> @@ -587,6 +590,8 @@ public class BytecodeParser implements GraphBuilderContext {
>> 
>>    private int lastBCI; // BCI of lastInstr. This field is for resolving instrumentation target.
>> 
>> +    private boolean needsReturnMembar = false; // Constructor has write to final field.
>> +
>>    protected BytecodeParser(GraphBuilderPhase.Instance graphBuilderInstance, StructuredGraph graph, BytecodeParser parent, ResolvedJavaMethod method,
>>                    int entryBCI, IntrinsicContext intrinsicContext) {
>>        this.code = intrinsicContext == null ? new ResolvedJavaMethodBytecode(method) : intrinsicContext.getBytecodeProvider().getBytecode(method);
>> @@ -606,6 +611,7 @@ public class BytecodeParser implements GraphBuilderContext {
>>        this.entryBCI = entryBCI;
>>        this.parent = parent;
>>        this.lastBCI = -1;
>> +        this.needsReturnMembar = false;
>> 
>>        assert code.getCode() != null : "method must contain bytecodes: " + method;
>> 
>> @@ -1216,6 +1222,9 @@ public class BytecodeParser implements GraphBuilderContext {
>>        StoreFieldNode storeFieldNode = new StoreFieldNode(receiver, field, value);
>>        append(storeFieldNode);
>>        storeFieldNode.setStateAfter(this.createFrameState(stream.nextBCI(), storeFieldNode));
>> +        if (field.isFinal() && method.isConstructor()) {
>> +            needsReturnMembar = true;
>> +        }
>>    }
>> 
>>    /**
>> @@ -1794,20 +1803,27 @@ public class BytecodeParser implements GraphBuilderContext {
>>    }
>> 
>>    private void beforeReturn(ValueNode x, JavaKind kind) {
>> -        if (graph.method() != null && graph.method().isJavaLangObjectInit()) {
>> -            /*
>> -             * Get the receiver from the initial state since bytecode rewriting could do arbitrary
>> -             * things to the state of the locals.
>> -             */
>> -            ValueNode receiver = graph.start().stateAfter().localAt(0);
>> -            assert receiver != null && receiver.getStackKind() == JavaKind.Object;
>> -            if (RegisterFinalizerNode.mayHaveFinalizer(receiver, graph.getAssumptions())) {
>> -                append(new RegisterFinalizerNode(receiver));
>> +        if (graph.method() != null) {
>> +            if (needsReturnMembar) {
>> +                append(new MembarNode(LOAD_STORE | STORE_STORE));
>>            }
>> -        }
>> -        genInfoPointNode(InfopointReason.METHOD_END, x);
>> 
>> -        synchronizedEpilogue(BytecodeFrame.AFTER_BCI, x, kind);
>> +            if (graph.method().isJavaLangObjectInit()) {
>> +                /*
>> +                 * Get the receiver from the initial state since bytecode rewriting could do
>> +                 * arbitrary things to the state of the locals.
>> +                 */
>> +                ValueNode receiver = graph.start().stateAfter().localAt(0);
>> +                assert receiver != null && receiver.getStackKind() == JavaKind.Object;
>> +                if (RegisterFinalizerNode.mayHaveFinalizer(receiver, graph.getAssumptions())) {
>> +                    append(new RegisterFinalizerNode(receiver));
>> +                }
>> +
>> +                genInfoPointNode(InfopointReason.METHOD_END, x);
>> +
>> +                synchronizedEpilogue(BytecodeFrame.AFTER_BCI, x, kind);
>> +            }
>> +        }
>>    }
>> 
>>    protected MonitorEnterNode createMonitorEnterNode(ValueNode x, MonitorIdNode monitorId) {
>> 
> 


From doug.simon at oracle.com  Thu Nov 10 20:15:30 2016
From: doug.simon at oracle.com (Doug Simon)
Date: Thu, 10 Nov 2016 21:15:30 +0100
Subject: Missing membar for constructors
In-Reply-To: <E8147F37-3C0B-4F93-A0AF-47FFB8AA3EAC@oracle.com>
References: <f916365d-65e8-d209-caed-a43cb96fd094@redhat.com>
	<2386DB2F-BB55-4EA3-A859-7D36CE84F8F1@oracle.com>
	<E8147F37-3C0B-4F93-A0AF-47FFB8AA3EAC@oracle.com>
Message-ID: <743CD17D-BBF5-4FB7-B175-56260C4858BD@oracle.com>

We should move discussion of this patch to the github pull request once it exists.

> On 10 Nov 2016, at 21:13, Tom Rodriguez <tom.rodriguez at oracle.com> wrote:
> 
> 
>> On Nov 10, 2016, at 12:02 PM, Doug Simon <doug.simon at oracle.com> wrote:
>> 
>> Thanks Andrew, this is indeed an unfortunate bug - thanks for tracking it down.
>> 
>> Could you please submit your patch as a pull request at https://github.com/graalvm/graal-core so we can review/discuss it there.
> 
> I suspect this isn?t sufficient.  We?ll also need a barrier when we materialize CommitAllocations that include stores to final fields.  And hopefully this new barrier won?t interfere with EA.  We might need a special node to represent this so we can optimize it properly.
> 
> tom
> 
>> 
>> -Doug
>> 
>>> On 10 Nov 2016, at 19:59, Andrew Haley <aph at redhat.com> wrote:
>>> 
>>> [Sorry, previous patch was wrong.]
>>> 
>>> 
>>> I've been getting some weird crashes, and tracked it down to a missing
>>> membar in constructors, where a final field can be published unsafely.
>>> Patch appended.  I found this very surprising, but there doesn't seem
>>> to be any code anywhere in Graal to handle this correctly.
>>> 
>>> Andrew.
>>> 
>>> diff --git a/graal/com.oracle.graal.java/src/com/oracle/graal/java/BytecodeParser.java b/graal/com.oracle.graal.java/src/com/oracle/graal/java/BytecodeParser.java
>>> index e51910c..a01be9e 100644
>>> --- a/graal/com.oracle.graal.java/src/com/oracle/graal/java/BytecodeParser.java
>>> +++ b/graal/com.oracle.graal.java/src/com/oracle/graal/java/BytecodeParser.java
>>> @@ -239,6 +239,8 @@ import static com.oracle.graal.java.BytecodeParserOptions.TraceParserPlugins;
>>> import static com.oracle.graal.nodes.graphbuilderconf.IntrinsicContext.CompilationContext.INLINE_DURING_PARSING;
>>> import static com.oracle.graal.nodes.type.StampTool.isPointerNonNull;
>>> import static java.lang.String.format;
>>> +import static jdk.vm.ci.code.MemoryBarriers.LOAD_STORE;
>>> +import static jdk.vm.ci.code.MemoryBarriers.STORE_STORE;
>>> import static jdk.vm.ci.meta.DeoptimizationAction.InvalidateRecompile;
>>> import static jdk.vm.ci.meta.DeoptimizationAction.InvalidateReprofile;
>>> import static jdk.vm.ci.meta.DeoptimizationReason.JavaSubroutineMismatch;
>>> @@ -360,6 +362,7 @@ import com.oracle.graal.nodes.extended.BytecodeExceptionNode;
>>> import com.oracle.graal.nodes.extended.GuardedNode;
>>> import com.oracle.graal.nodes.extended.GuardingNode;
>>> import com.oracle.graal.nodes.extended.IntegerSwitchNode;
>>> +import com.oracle.graal.nodes.extended.MembarNode;
>>> import com.oracle.graal.nodes.extended.ValueAnchorNode;
>>> import com.oracle.graal.nodes.graphbuilderconf.GraphBuilderConfiguration;
>>> import com.oracle.graal.nodes.graphbuilderconf.GraphBuilderConfiguration.BytecodeExceptionMode;
>>> @@ -587,6 +590,8 @@ public class BytecodeParser implements GraphBuilderContext {
>>> 
>>>   private int lastBCI; // BCI of lastInstr. This field is for resolving instrumentation target.
>>> 
>>> +    private boolean needsReturnMembar = false; // Constructor has write to final field.
>>> +
>>>   protected BytecodeParser(GraphBuilderPhase.Instance graphBuilderInstance, StructuredGraph graph, BytecodeParser parent, ResolvedJavaMethod method,
>>>                   int entryBCI, IntrinsicContext intrinsicContext) {
>>>       this.code = intrinsicContext == null ? new ResolvedJavaMethodBytecode(method) : intrinsicContext.getBytecodeProvider().getBytecode(method);
>>> @@ -606,6 +611,7 @@ public class BytecodeParser implements GraphBuilderContext {
>>>       this.entryBCI = entryBCI;
>>>       this.parent = parent;
>>>       this.lastBCI = -1;
>>> +        this.needsReturnMembar = false;
>>> 
>>>       assert code.getCode() != null : "method must contain bytecodes: " + method;
>>> 
>>> @@ -1216,6 +1222,9 @@ public class BytecodeParser implements GraphBuilderContext {
>>>       StoreFieldNode storeFieldNode = new StoreFieldNode(receiver, field, value);
>>>       append(storeFieldNode);
>>>       storeFieldNode.setStateAfter(this.createFrameState(stream.nextBCI(), storeFieldNode));
>>> +        if (field.isFinal() && method.isConstructor()) {
>>> +            needsReturnMembar = true;
>>> +        }
>>>   }
>>> 
>>>   /**
>>> @@ -1794,20 +1803,27 @@ public class BytecodeParser implements GraphBuilderContext {
>>>   }
>>> 
>>>   private void beforeReturn(ValueNode x, JavaKind kind) {
>>> -        if (graph.method() != null && graph.method().isJavaLangObjectInit()) {
>>> -            /*
>>> -             * Get the receiver from the initial state since bytecode rewriting could do arbitrary
>>> -             * things to the state of the locals.
>>> -             */
>>> -            ValueNode receiver = graph.start().stateAfter().localAt(0);
>>> -            assert receiver != null && receiver.getStackKind() == JavaKind.Object;
>>> -            if (RegisterFinalizerNode.mayHaveFinalizer(receiver, graph.getAssumptions())) {
>>> -                append(new RegisterFinalizerNode(receiver));
>>> +        if (graph.method() != null) {
>>> +            if (needsReturnMembar) {
>>> +                append(new MembarNode(LOAD_STORE | STORE_STORE));
>>>           }
>>> -        }
>>> -        genInfoPointNode(InfopointReason.METHOD_END, x);
>>> 
>>> -        synchronizedEpilogue(BytecodeFrame.AFTER_BCI, x, kind);
>>> +            if (graph.method().isJavaLangObjectInit()) {
>>> +                /*
>>> +                 * Get the receiver from the initial state since bytecode rewriting could do
>>> +                 * arbitrary things to the state of the locals.
>>> +                 */
>>> +                ValueNode receiver = graph.start().stateAfter().localAt(0);
>>> +                assert receiver != null && receiver.getStackKind() == JavaKind.Object;
>>> +                if (RegisterFinalizerNode.mayHaveFinalizer(receiver, graph.getAssumptions())) {
>>> +                    append(new RegisterFinalizerNode(receiver));
>>> +                }
>>> +
>>> +                genInfoPointNode(InfopointReason.METHOD_END, x);
>>> +
>>> +                synchronizedEpilogue(BytecodeFrame.AFTER_BCI, x, kind);
>>> +            }
>>> +        }
>>>   }
>>> 
>>>   protected MonitorEnterNode createMonitorEnterNode(ValueNode x, MonitorIdNode monitorId) {
>>> 
>> 
> 


From aph at redhat.com  Thu Nov 10 20:37:21 2016
From: aph at redhat.com (Andrew Haley)
Date: Thu, 10 Nov 2016 20:37:21 +0000
Subject: Missing membar for constructors
In-Reply-To: <743CD17D-BBF5-4FB7-B175-56260C4858BD@oracle.com>
References: <f916365d-65e8-d209-caed-a43cb96fd094@redhat.com>
	<2386DB2F-BB55-4EA3-A859-7D36CE84F8F1@oracle.com>
	<E8147F37-3C0B-4F93-A0AF-47FFB8AA3EAC@oracle.com>
	<743CD17D-BBF5-4FB7-B175-56260C4858BD@oracle.com>
Message-ID: <0af01dc3-7171-4994-4a0d-12ddc4f81c5f@redhat.com>

On 10/11/16 20:15, Doug Simon wrote:
> We should move discussion of this patch to the github pull request once it exists.

OK.  My experience of github (and indeed git) is basically zero, so
you'll need to have some patience with me.

Andrew.


From sidbreaks at protonmail.com  Thu Nov 10 20:43:32 2016
From: sidbreaks at protonmail.com (Sidharth)
Date: Thu, 10 Nov 2016 15:43:32 -0500
Subject: mx build error
Message-ID: <woZ4FsYBrGdy6SIc42SiMqjQKSWpjdcG7taREkxeWl9tbSLwjsHzKUx4nPHipjqEtRJVaGxgDU8XnEcdHNBBKQl6IpipvZ0eM8PNvgpC39k=@protonmail.com>

Hello All Graal Developers,

I am new to mailing lists so bear with me if I have made some kind of a mistake in posting the issue I am facing currently.

I have set JVMCI_VERSION_CHECK=ignore and am using java-9-openjdk-amd64 in a ubuntu 64 bit OS.

running 'mx build' is throwing this error

javac: invalid flag: --add-exports java.base/jdk.internal.module=ALL-UNNAMED
Usage: javac <options> <source files>
use -help for a list of possible options
javac: no source files
Usage: javac <options> <source files>
use -help for a list of possible options
failed to compile:/media/sanjai/7A84227E84223D4F/graal/mx/ListModules.java

Can someone help me with this, I am stuck here for sometime.

Regards,
Sid

From doug.simon at oracle.com  Thu Nov 10 20:56:08 2016
From: doug.simon at oracle.com (Doug Simon)
Date: Thu, 10 Nov 2016 21:56:08 +0100
Subject: Missing membar for constructors
In-Reply-To: <0af01dc3-7171-4994-4a0d-12ddc4f81c5f@redhat.com>
References: <f916365d-65e8-d209-caed-a43cb96fd094@redhat.com>
	<2386DB2F-BB55-4EA3-A859-7D36CE84F8F1@oracle.com>
	<E8147F37-3C0B-4F93-A0AF-47FFB8AA3EAC@oracle.com>
	<743CD17D-BBF5-4FB7-B175-56260C4858BD@oracle.com>
	<0af01dc3-7171-4994-4a0d-12ddc4f81c5f@redhat.com>
Message-ID: <C10F0BF1-1B2C-47C0-8D3E-39B6664A022B@oracle.com>


> On 10 Nov 2016, at 21:37, Andrew Haley <aph at redhat.com> wrote:
> 
> On 10/11/16 20:15, Doug Simon wrote:
>> We should move discussion of this patch to the github pull request once it exists.
> 
> OK.  My experience of github (and indeed git) is basically zero, so
> you'll need to have some patience with me.

No problem - a lot of us on the team sympathize with the learning curve having switched to git only somewhat recently.

The github documentation is fairly comprehensive but if you have any questions, feel free to ask here or in the graal-core Gitter room (https://gitter.im/graalvm/graal-core).

-Doug

From doug.simon at oracle.com  Thu Nov 10 20:59:22 2016
From: doug.simon at oracle.com (Doug Simon)
Date: Thu, 10 Nov 2016 21:59:22 +0100
Subject: mx build error
In-Reply-To: <woZ4FsYBrGdy6SIc42SiMqjQKSWpjdcG7taREkxeWl9tbSLwjsHzKUx4nPHipjqEtRJVaGxgDU8XnEcdHNBBKQl6IpipvZ0eM8PNvgpC39k=@protonmail.com>
References: <woZ4FsYBrGdy6SIc42SiMqjQKSWpjdcG7taREkxeWl9tbSLwjsHzKUx4nPHipjqEtRJVaGxgDU8XnEcdHNBBKQl6IpipvZ0eM8PNvgpC39k=@protonmail.com>
Message-ID: <3CA902F2-3BA4-4F4D-BD40-76B24A4A52CD@oracle.com>


> On 10 Nov 2016, at 21:43, Sidharth <sidbreaks at protonmail.com> wrote:
> 
> Hello All Graal Developers,
> 
> I am new to mailing lists so bear with me if I have made some kind of a mistake in posting the issue I am facing currently.
> 
> I have set JVMCI_VERSION_CHECK=ignore and am using java-9-openjdk-amd64 in a ubuntu 64 bit OS.

It appears as though that java-9 binary is too old. Keep in mind that jdk9 is still under development and so backwards compatibility with earlier builds is not guaranteed. As such, I recommend using the jdk 9 Early Access Releases from https://jdk9.java.net/download/ as of build 143.

-Doug

From aph at redhat.com  Fri Nov 11 09:35:30 2016
From: aph at redhat.com (Andrew Haley)
Date: Fri, 11 Nov 2016 09:35:30 +0000
Subject: Missing membar for constructors
In-Reply-To: <C10F0BF1-1B2C-47C0-8D3E-39B6664A022B@oracle.com>
References: <f916365d-65e8-d209-caed-a43cb96fd094@redhat.com>
	<2386DB2F-BB55-4EA3-A859-7D36CE84F8F1@oracle.com>
	<E8147F37-3C0B-4F93-A0AF-47FFB8AA3EAC@oracle.com>
	<743CD17D-BBF5-4FB7-B175-56260C4858BD@oracle.com>
	<0af01dc3-7171-4994-4a0d-12ddc4f81c5f@redhat.com>
	<C10F0BF1-1B2C-47C0-8D3E-39B6664A022B@oracle.com>
Message-ID: <b41024cd-e5fe-9eee-8f49-10ff72fd4666@redhat.com>

On 10/11/16 20:56, Doug Simon wrote:

> The github documentation is fairly comprehensive but if you have any
> questions, feel free to ask here or in the graal-core Gitter room
> (https://gitter.im/graalvm/graal-core).

Okay.  It all sounds amazingly complicated, but I guess it can't be as
bad as it seems or people wouldn't use GitHub.

I think I have to:

  Create a branch in the Graal repo on GitHub

  Push my change to it

  Create a new pull request

Is that right?

Some questions arise in my mind.  Should this newly-created branch be
unique to this bug?  What sort of name should it have?  What branch
should this pull request be based on?

It would help me tremendously if someone could talk me through the
creation of this branch.

Thanks,

Andrew.

From eregontp at gmail.com  Fri Nov 11 12:23:16 2016
From: eregontp at gmail.com (Benoit Daloze)
Date: Fri, 11 Nov 2016 13:23:16 +0100
Subject: Missing membar for constructors
In-Reply-To: <b41024cd-e5fe-9eee-8f49-10ff72fd4666@redhat.com>
References: <f916365d-65e8-d209-caed-a43cb96fd094@redhat.com>
	<2386DB2F-BB55-4EA3-A859-7D36CE84F8F1@oracle.com>
	<E8147F37-3C0B-4F93-A0AF-47FFB8AA3EAC@oracle.com>
	<743CD17D-BBF5-4FB7-B175-56260C4858BD@oracle.com>
	<0af01dc3-7171-4994-4a0d-12ddc4f81c5f@redhat.com>
	<C10F0BF1-1B2C-47C0-8D3E-39B6664A022B@oracle.com>
	<b41024cd-e5fe-9eee-8f49-10ff72fd4666@redhat.com>
Message-ID: <CANLTa0DesT=6z6jzwob=7o3PS5NpZKj5trq6g4L5NpF8Fvmizg@mail.gmail.com>

Hello Andrew,

in your local git clone of graal-core, you can do:

# Creates the branch and switches to it
$ git checkout -b final_membar
# Create a commit of the changes
$ git commit -av

Now you need to click "Fork" on https://github.com/graalvm/graal-core.
Once done, get your repository URL under "Clone or download".
$ git remote add mine <URL>
$ git push -u mine final_membar

Go to https://github.com/graalvm/graal-core and create a Pull Request
(there should be a green button "Compare and create Pull Request" to do it
directly).

Hope it helps,
Benoit

On Fri, Nov 11, 2016 at 10:35 AM, Andrew Haley <aph at redhat.com> wrote:

> On 10/11/16 20:56, Doug Simon wrote:
>
> > The github documentation is fairly comprehensive but if you have any
> > questions, feel free to ask here or in the graal-core Gitter room
> > (https://gitter.im/graalvm/graal-core).
>
> Okay.  It all sounds amazingly complicated, but I guess it can't be as
> bad as it seems or people wouldn't use GitHub.
>
> I think I have to:
>
>   Create a branch in the Graal repo on GitHub
>
>   Push my change to it
>
>   Create a new pull request
>
> Is that right?
>
> Some questions arise in my mind.  Should this newly-created branch be
> unique to this bug?  What sort of name should it have?  What branch
> should this pull request be based on?
>
> It would help me tremendously if someone could talk me through the
> creation of this branch.
>
> Thanks,
>
> Andrew.
>

From doug.simon at oracle.com  Fri Nov 11 13:35:02 2016
From: doug.simon at oracle.com (Doug Simon)
Date: Fri, 11 Nov 2016 14:35:02 +0100
Subject: Missing membar for constructors
In-Reply-To: <CANLTa0DesT=6z6jzwob=7o3PS5NpZKj5trq6g4L5NpF8Fvmizg@mail.gmail.com>
References: <f916365d-65e8-d209-caed-a43cb96fd094@redhat.com>
	<2386DB2F-BB55-4EA3-A859-7D36CE84F8F1@oracle.com>
	<E8147F37-3C0B-4F93-A0AF-47FFB8AA3EAC@oracle.com>
	<743CD17D-BBF5-4FB7-B175-56260C4858BD@oracle.com>
	<0af01dc3-7171-4994-4a0d-12ddc4f81c5f@redhat.com>
	<C10F0BF1-1B2C-47C0-8D3E-39B6664A022B@oracle.com>
	<b41024cd-e5fe-9eee-8f49-10ff72fd4666@redhat.com>
	<CANLTa0DesT=6z6jzwob=7o3PS5NpZKj5trq6g4L5NpF8Fvmizg@mail.gmail.com>
Message-ID: <DB43F74A-21DF-4087-B66E-C634B604D7D6@oracle.com>

Andrew,

I created a short screen recording of the process for cloning graal-core and submitting a pull request:

https://youtu.be/A_OczfY-YSg

-Doug

> On 11 Nov 2016, at 13:23, Benoit Daloze <eregontp at gmail.com> wrote:
> 
> Hello Andrew,
> 
> in your local git clone of graal-core, you can do:
> 
> # Creates the branch and switches to it
> $ git checkout -b final_membar
> # Create a commit of the changes
> $ git commit -av
> 
> Now you need to click "Fork" on https://github.com/graalvm/graal-core.
> Once done, get your repository URL under "Clone or download".
> $ git remote add mine <URL>
> $ git push -u mine final_membar
> 
> Go to https://github.com/graalvm/graal-core and create a Pull Request
> (there should be a green button "Compare and create Pull Request" to do it
> directly).
> 
> Hope it helps,
> Benoit
> 
> On Fri, Nov 11, 2016 at 10:35 AM, Andrew Haley <aph at redhat.com> wrote:
> 
>> On 10/11/16 20:56, Doug Simon wrote:
>> 
>>> The github documentation is fairly comprehensive but if you have any
>>> questions, feel free to ask here or in the graal-core Gitter room
>>> (https://gitter.im/graalvm/graal-core).
>> 
>> Okay.  It all sounds amazingly complicated, but I guess it can't be as
>> bad as it seems or people wouldn't use GitHub.
>> 
>> I think I have to:
>> 
>>  Create a branch in the Graal repo on GitHub
>> 
>>  Push my change to it
>> 
>>  Create a new pull request
>> 
>> Is that right?
>> 
>> Some questions arise in my mind.  Should this newly-created branch be
>> unique to this bug?  What sort of name should it have?  What branch
>> should this pull request be based on?
>> 
>> It would help me tremendously if someone could talk me through the
>> creation of this branch.
>> 
>> Thanks,
>> 
>> Andrew.
>> 


From doug.simon at oracle.com  Fri Nov 11 13:39:59 2016
From: doug.simon at oracle.com (Doug Simon)
Date: Fri, 11 Nov 2016 14:39:59 +0100
Subject: Missing membar for constructors
In-Reply-To: <b41024cd-e5fe-9eee-8f49-10ff72fd4666@redhat.com>
References: <f916365d-65e8-d209-caed-a43cb96fd094@redhat.com>
	<2386DB2F-BB55-4EA3-A859-7D36CE84F8F1@oracle.com>
	<E8147F37-3C0B-4F93-A0AF-47FFB8AA3EAC@oracle.com>
	<743CD17D-BBF5-4FB7-B175-56260C4858BD@oracle.com>
	<0af01dc3-7171-4994-4a0d-12ddc4f81c5f@redhat.com>
	<C10F0BF1-1B2C-47C0-8D3E-39B6664A022B@oracle.com>
	<b41024cd-e5fe-9eee-8f49-10ff72fd4666@redhat.com>
Message-ID: <10F63E8D-B299-4FDC-AE4C-2D5A74B2C939@oracle.com>


> On 11 Nov 2016, at 10:35, Andrew Haley <aph at redhat.com> wrote:
> 
> On 10/11/16 20:56, Doug Simon wrote:
> 
>> The github documentation is fairly comprehensive but if you have any
>> questions, feel free to ask here or in the graal-core Gitter room
>> (https://gitter.im/graalvm/graal-core).
> 
> Okay.  It all sounds amazingly complicated, but I guess it can't be as
> bad as it seems or people wouldn't use GitHub.
> 
> I think I have to:
> 
>  Create a branch in the Graal repo on GitHub
> 
>  Push my change to it
> 
>  Create a new pull request
> 
> Is that right?
> 
> Some questions arise in my mind.  Should this newly-created branch be
> unique to this bug?

Yes. Branches in git are typically short lived and represent a single logical item of work (that can be made up of more than one commit).

Once your branch is merged into the master branch, you (typically) delete the branch on your fork:

> git branch -d final_membar

>  What sort of name should it have?

Something short like Benoit suggested.

>  What branch
> should this pull request be based on?

On the master branch.

> It would help me tremendously if someone could talk me through the
> creation of this branch.

Sure. Let us know if you have further questions.

-Doug

From aph at redhat.com  Fri Nov 11 18:38:12 2016
From: aph at redhat.com (Andrew Haley)
Date: Fri, 11 Nov 2016 18:38:12 +0000
Subject: A baffling bug...
Message-ID: <331d1ead-c030-f54b-4648-99319f9cd36f@redhat.com>

I've been having some problems with my tests, which include one
failure I can't explain.

What happens is that Graal-generated code tries to re-lock an object
which is already locked in this method using a stack slot for the
displaced header which is already in use for the same object.  This
should not be possible if locks are correctly nested.

The code roughly looks like this:

    public final int readUnsignedShort() throws IOException {
        int ch1 = in.read();
        int ch2 = in.read();
        ...

where read is():

    public synchronized int read() throws IOException {
        if (pos >= count) {
            fill();
            if (pos >= count)
                return -1;
        }
        return getBufIfOpen()[pos++] & 0xff;

It's extremely hard to tell exactly what is going on because the
generated code has very convoluted control flow.  However, my guess is
that Graal has tried to coalesce two monitor regions into one but got
it wrong.  (These two monitor regions are for the two synchronized
calls to in.read().)

So, my questions:

Does Graal try to coalesce monitor regions?  If so, is there some way
to turn that off?

Does anyone have any other suggestions?

Or want to look at the generated code?  ;-)

Andrew.


From thomas.wuerthinger at oracle.com  Fri Nov 11 19:01:41 2016
From: thomas.wuerthinger at oracle.com (Thomas Wuerthinger)
Date: Fri, 11 Nov 2016 20:01:41 +0100
Subject: A baffling bug...
In-Reply-To: <331d1ead-c030-f54b-4648-99319f9cd36f@redhat.com>
References: <331d1ead-c030-f54b-4648-99319f9cd36f@redhat.com>
Message-ID: <FE1C1D19-5313-4C05-A7A5-70911A91641E@oracle.com>

Andrew,

Thanks for the report! Best way for us to look at this in more detail would be to get access to the compiler graphs. You can get these graphs sent to the IdealGraphVisualizer by running -Dgraal.Dump=:1 and -Dgraal.MethodFilter=Foo.bar. The IGV then has an option to export the graphs to a file.

- thomas


> On 11 Nov 2016, at 19:38, Andrew Haley <aph at redhat.com> wrote:
> 
> I've been having some problems with my tests, which include one
> failure I can't explain.
> 
> What happens is that Graal-generated code tries to re-lock an object
> which is already locked in this method using a stack slot for the
> displaced header which is already in use for the same object.  This
> should not be possible if locks are correctly nested.
> 
> The code roughly looks like this:
> 
>    public final int readUnsignedShort() throws IOException {
>        int ch1 = in.read();
>        int ch2 = in.read();
>        ...
> 
> where read is():
> 
>    public synchronized int read() throws IOException {
>        if (pos >= count) {
>            fill();
>            if (pos >= count)
>                return -1;
>        }
>        return getBufIfOpen()[pos++] & 0xff;
> 
> It's extremely hard to tell exactly what is going on because the
> generated code has very convoluted control flow.  However, my guess is
> that Graal has tried to coalesce two monitor regions into one but got
> it wrong.  (These two monitor regions are for the two synchronized
> calls to in.read().)
> 
> So, my questions:
> 
> Does Graal try to coalesce monitor regions?  If so, is there some way
> to turn that off?
> 
> Does anyone have any other suggestions?
> 
> Or want to look at the generated code?  ;-)
> 
> Andrew.
> 


From doug.simon at oracle.com  Fri Nov 11 19:06:36 2016
From: doug.simon at oracle.com (Doug Simon)
Date: Fri, 11 Nov 2016 20:06:36 +0100
Subject: A baffling bug...
In-Reply-To: <FE1C1D19-5313-4C05-A7A5-70911A91641E@oracle.com>
References: <331d1ead-c030-f54b-4648-99319f9cd36f@redhat.com>
	<FE1C1D19-5313-4C05-A7A5-70911A91641E@oracle.com>
Message-ID: <47BA3C1C-1AA0-4351-A030-AB34D8A23D1C@oracle.com>


> On 11 Nov 2016, at 20:01, Thomas Wuerthinger <thomas.wuerthinger at oracle.com> wrote:
> 
> Andrew,
> 
> Thanks for the report! Best way for us to look at this in more detail would be to get access to the compiler graphs. You can get these graphs sent to the IdealGraphVisualizer by running -Dgraal.Dump=:1 and -Dgraal.MethodFilter=Foo.bar. The IGV then has an option to export the graphs to a file.

You can also dump the graphs directly to a file with -Dgraal.PrintIdealGraphFile=true.

BTW, Graal has com.oracle.graal.phases.common.LockEliminationPhase. Does LockEliminationTest pass for you:

mx unittest LockEliminationTest

-Doug

> 
> - thomas
> 
> 
>> On 11 Nov 2016, at 19:38, Andrew Haley <aph at redhat.com> wrote:
>> 
>> I've been having some problems with my tests, which include one
>> failure I can't explain.
>> 
>> What happens is that Graal-generated code tries to re-lock an object
>> which is already locked in this method using a stack slot for the
>> displaced header which is already in use for the same object.  This
>> should not be possible if locks are correctly nested.
>> 
>> The code roughly looks like this:
>> 
>>   public final int readUnsignedShort() throws IOException {
>>       int ch1 = in.read();
>>       int ch2 = in.read();
>>       ...
>> 
>> where read is():
>> 
>>   public synchronized int read() throws IOException {
>>       if (pos >= count) {
>>           fill();
>>           if (pos >= count)
>>               return -1;
>>       }
>>       return getBufIfOpen()[pos++] & 0xff;
>> 
>> It's extremely hard to tell exactly what is going on because the
>> generated code has very convoluted control flow.  However, my guess is
>> that Graal has tried to coalesce two monitor regions into one but got
>> it wrong.  (These two monitor regions are for the two synchronized
>> calls to in.read().)
>> 
>> So, my questions:
>> 
>> Does Graal try to coalesce monitor regions?  If so, is there some way
>> to turn that off?
>> 
>> Does anyone have any other suggestions?
>> 
>> Or want to look at the generated code?  ;-)
>> 
>> Andrew.
>> 
> 


From aph at redhat.com  Mon Nov 14 17:57:46 2016
From: aph at redhat.com (Andrew Haley)
Date: Mon, 14 Nov 2016 17:57:46 +0000
Subject: Missing membar for constructors
In-Reply-To: <CANLTa0DesT=6z6jzwob=7o3PS5NpZKj5trq6g4L5NpF8Fvmizg@mail.gmail.com>
References: <f916365d-65e8-d209-caed-a43cb96fd094@redhat.com>
	<2386DB2F-BB55-4EA3-A859-7D36CE84F8F1@oracle.com>
	<E8147F37-3C0B-4F93-A0AF-47FFB8AA3EAC@oracle.com>
	<743CD17D-BBF5-4FB7-B175-56260C4858BD@oracle.com>
	<0af01dc3-7171-4994-4a0d-12ddc4f81c5f@redhat.com>
	<C10F0BF1-1B2C-47C0-8D3E-39B6664A022B@oracle.com>
	<b41024cd-e5fe-9eee-8f49-10ff72fd4666@redhat.com>
	<CANLTa0DesT=6z6jzwob=7o3PS5NpZKj5trq6g4L5NpF8Fvmizg@mail.gmail.com>
Message-ID: <a718cfa4-62ec-4120-2458-e56cba9d4952@redhat.com>

On 11/11/16 12:23, Benoit Daloze wrote:
> git push -u mine final_membar

So close...

error: The requested URL returned error: 403 Forbidden while accessing https://github.com/theRealAph/graal-core.git/info/refs

fatal: HTTP request failed

Thanks,

Andrew.


From doug.simon at oracle.com  Mon Nov 14 18:04:05 2016
From: doug.simon at oracle.com (Doug Simon)
Date: Mon, 14 Nov 2016 19:04:05 +0100
Subject: Missing membar for constructors
In-Reply-To: <a718cfa4-62ec-4120-2458-e56cba9d4952@redhat.com>
References: <f916365d-65e8-d209-caed-a43cb96fd094@redhat.com>
	<2386DB2F-BB55-4EA3-A859-7D36CE84F8F1@oracle.com>
	<E8147F37-3C0B-4F93-A0AF-47FFB8AA3EAC@oracle.com>
	<743CD17D-BBF5-4FB7-B175-56260C4858BD@oracle.com>
	<0af01dc3-7171-4994-4a0d-12ddc4f81c5f@redhat.com>
	<C10F0BF1-1B2C-47C0-8D3E-39B6664A022B@oracle.com>
	<b41024cd-e5fe-9eee-8f49-10ff72fd4666@redhat.com>
	<CANLTa0DesT=6z6jzwob=7o3PS5NpZKj5trq6g4L5NpF8Fvmizg@mail.gmail.com>
	<a718cfa4-62ec-4120-2458-e56cba9d4952@redhat.com>
Message-ID: <A37EAE9E-2D2A-4C4F-A300-D5D6B93939E2@oracle.com>


> On 14 Nov 2016, at 18:57, Andrew Haley <aph at redhat.com> wrote:
> 
> On 11/11/16 12:23, Benoit Daloze wrote:
>> git push -u mine final_membar
> 
> So close...
> 
> error: The requested URL returned error: 403 Forbidden while accessing https://github.com/theRealAph/graal-core.git/info/refs
> 
> fatal: HTTP request failed
> 

Can you try pushing with ssh instead:

git push ssh://git at github.com:theRealAph/graal-core.git

(you?ll need to add your public key to your github account[1])

-Doug

[1] https://help.github.com/articles/which-remote-url-should-i-use/#cloning-with-ssh-urls

From doug.simon at oracle.com  Thu Nov 17 12:59:00 2016
From: doug.simon at oracle.com (Doug Simon)
Date: Thu, 17 Nov 2016 13:59:00 +0100
Subject: Documenting Graal use cases
Message-ID: <13DCF6DD-7A16-47DA-9FCE-86FD5EFF4148@oracle.com>

Hi,

We?ve started a document for describing common use cases of Graal in terms of options to set:

https://github.com/graalvm/graal-core/blob/master/docs/Examples.md

In an effort to expand this document, we encourage you to open issues on github or send suggestions/questions to this list.

-Doug

From aph at redhat.com  Thu Nov 17 13:32:40 2016
From: aph at redhat.com (Andrew Haley)
Date: Thu, 17 Nov 2016 13:32:40 +0000
Subject: Running jcstress
Message-ID: <08c05a1d-72ce-ae9a-9faf-c80916bd57e9@redhat.com>

How do you run jcstress with Graal?  I have no way to know if the Graal-
generated code is actually being tested.

Thanks,

Andrew.

From doug.simon at oracle.com  Thu Nov 17 14:21:47 2016
From: doug.simon at oracle.com (Doug Simon)
Date: Thu, 17 Nov 2016 15:21:47 +0100
Subject: Running jcstress
In-Reply-To: <08c05a1d-72ce-ae9a-9faf-c80916bd57e9@redhat.com>
References: <08c05a1d-72ce-ae9a-9faf-c80916bd57e9@redhat.com>
Message-ID: <33F4F0D2-A6D2-4B3A-B169-BD4FA2B86E71@oracle.com>

Something like this should work:

mx vm -XX:+UseJVMCICompiler -jar $HOME/jcstress/tests-custom/target/jcstress.jar

To double check that Graal is compiling the relevant methods:

mx vm -XX:+UseJVMCICompiler -Dgraal.PrintCompilation=true -jar $HOME/jcstress/tests-custom/target/jcstress.jar

And, as always, to see the java launcher command being issued by mx, use the -v option:

mx -v vm -XX:+UseJVMCICompiler -jar $HOME/jcstress/tests-custom/target/jcstress.jar

-Doug

> On 17 Nov 2016, at 14:32, Andrew Haley <aph at redhat.com> wrote:
> 
> How do you run jcstress with Graal?  I have no way to know if the Graal-
> generated code is actually being tested.
> 
> Thanks,
> 
> Andrew.


From aph at redhat.com  Thu Nov 17 14:33:59 2016
From: aph at redhat.com (Andrew Haley)
Date: Thu, 17 Nov 2016 14:33:59 +0000
Subject: Running jcstress
In-Reply-To: <33F4F0D2-A6D2-4B3A-B169-BD4FA2B86E71@oracle.com>
References: <08c05a1d-72ce-ae9a-9faf-c80916bd57e9@redhat.com>
	<33F4F0D2-A6D2-4B3A-B169-BD4FA2B86E71@oracle.com>
Message-ID: <d0e21725-2b1f-6a33-6b4b-1cd23f18c7ff@redhat.com>

On 17/11/16 14:21, Doug Simon wrote:
> mx vm -XX:+UseJVMCICompiler -jar $HOME/jcstress/tests-custom/target/jcstress.jar
> 
> To double check that Graal is compiling the relevant methods:
> 
> mx vm -XX:+UseJVMCICompiler -Dgraal.PrintCompilation=true -jar $HOME/jcstress/tests-custom/target/jcstress.jar

Ah.  That doesn't work because jcstress swallows the output of the subprocess.
So you never see any jcstress methods compiled.

> And, as always, to see the java launcher command being issued by mx, use the -v option:
> 
> mx -v vm -XX:+UseJVMCICompiler -jar $HOME/jcstress/tests-custom/target/jcstress.jar

Sure.

Thanks,

Andrew.


From aph at redhat.com  Fri Nov 18 15:45:53 2016
From: aph at redhat.com (Andrew Haley)
Date: Fri, 18 Nov 2016 15:45:53 +0000
Subject: Unsafe.storeFence produces a floating fence
Message-ID: <1a3df2c3-94d2-e10e-a242-edb71dc26f31@redhat.com>

Here's a jcstress test:

public class ShortFencedTest {

    Shell shell;

    public static class Shell {
        short x;

        public Shell() {
            this.x = (short) 0xFFFF;
            UnsafeHolder.U.storeFence();
        }
    }

    @Actor
    public void actor1() {
        shell = new Shell();
    }

    @Actor
    public void actor2(ShortResult1 r) {
        Shell sh = shell;
        r.r1 = (sh == null) ? 42 : sh.x;
    }

}

the problem is that the call to storeFence() floats above the store to
this.x in Shell().  In fact, it even floats past the object creation.

Here's the generated assembly code for actor1.  The storeFence has floated past
the creation of the object, all the way to the entry point of actor1:

[Verified Entry Point]
  0x0000007fa5593900: nop
  0x0000007fa5593904: sub	x8, sp, #0x4, lsl #12
  0x0000007fa5593908: str	xzr, [x8]
  0x0000007fa559390c: sub	sp, sp, #0x30
  0x0000007fa5593910: stp	x29, x30, [sp,#32]
  0x0000007fa5593914: dmb	ish             ;*invokevirtual storeFence {reexecute=0 rethrow=0 return_oop=0}
                                                ; - sun.misc.Unsafe::storeFence at 3 (line 1215)
                                                ; - org.openjdk.jcstress.tests.init.primitives.fenced.ShortFencedTest$Shell::<init>@12 (line 47)
                                                ; - org.openjdk.jcstress.tests.init.primitives.fenced.ShortFencedTest::actor1 at 5 (line 53)

  0x0000007fa5593918: orr	x0, xzr, #0x60
  0x0000007fa559391c: ldr	x2, [x28,x0]
  0x0000007fa5593920: orr	x3, xzr, #0x70
  0x0000007fa5593924: ldr	x3, [x28,x3]
  0x0000007fa5593928: add	x4, x2, #0x10
  0x0000007fa559392c: cmp	x4, x3
  0x0000007fa5593930: b.hi	0x0000007fa55939bc
  0x0000007fa5593934: str	x4, [x28,x0]
  0x0000007fa5593938: orr	x0, xzr, #0x180
  0x0000007fa559393c: nop
  0x0000007fa5593940: mov	x0, xzr
  0x0000007fa5593944: orr	x3, xzr, #0x1
  0x0000007fa5593948: str	x3, [x2,x0]
  0x0000007fa559394c: orr	x0, xzr, #0x8
  0x0000007fa5593950: mov	x3, #0xd0000               	// #851968
                                                ;   {metadata('org/openjdk/jcstress/tests/init/primitives/fenced/ShortFencedTest$Shell')}
  0x0000007fa5593954: movk	x3, #0x83f8
  0x0000007fa5593958: str	w3, [x2,x0]
  0x0000007fa559395c: orr	x0, xzr, #0xc
  0x0000007fa5593960: str	wzr, [x2,x0]
  0x0000007fa5593964: dmb	ish
  0x0000007fa5593968: mov	x0, x2
  0x0000007fa559396c: orr	x2, xzr, #0xc
  0x0000007fa5593970: orr	x3, xzr, #0xffff
  0x0000007fa5593974: strh	w3, [x0,x2]
  0x0000007fa5593978: orr	x2, xzr, #0xc
  0x0000007fa559397c: lsr	x0, x0, #3
  0x0000007fa5593980: str	w0, [x1,x2]     ;*putfield shell {reexecute=0 rethrow=0 return_oop=0}
                                                ; - org.openjdk.jcstress.tests.init.primitives.fenced.ShortFencedTest::actor1 at 8 (line 53)

  0x0000007fa5593984: lsr	x1, x1, #9
  0x0000007fa5593988: mov	x0, #0xf000                	// #61440
  0x0000007fa559398c: movk	x0, #0xafe5, lsl #16
  0x0000007fa5593990: movk	x0, #0x7f, lsl #32
  0x0000007fa5593994: add	x1, x1, x0
  0x0000007fa5593998: mov	x0, xzr
  0x0000007fa559399c: strb	wzr, [x1,x0]
  0x0000007fa55939a0: ldp	x29, x30, [sp,#32]
  0x0000007fa55939a4: add	sp, sp, #0x30
  0x0000007fa55939a8: mov	x8, #0x5000                	// #20480
                                                ;   {poll_return}
  0x0000007fa55939ac: movk	x8, #0xb4fd, lsl #16
  0x0000007fa55939b0: movk	x8, #0x7f, lsl #32
  0x0000007fa55939b4: ldr	wzr, [x8]       ;   {poll_return}
  0x0000007fa55939b8: ret                       ;*return {reexecute=0 rethrow=0 return_oop=0}
                                                ; - org.openjdk.jcstress.tests.init.primitives.fenced.ShortFencedTest::actor1 at 11 (line 54)

UnsafeFencePlugin looks like:

    public static class UnsafeFencePlugin implements InvocationPlugin {

        private final int barriers;

        public UnsafeFencePlugin(int barriers) {
            this.barriers = barriers;
        }

        @Override
        public boolean apply(GraphBuilderContext b, ResolvedJavaMethod targetMethod, Receiver unsafe) {
            // Emits a null-check for the otherwise unused receiver
            unsafe.get();
            b.add(new MembarNode(barriers));
            return true;
        }
    }

MembarNode is a FixedWithNextNode, but in this case it's simply added to the
graph.

I'd love to have an opportunity to fix this bug, but I'd like some guidance.

Andrew.


From doug.simon at oracle.com  Fri Nov 18 16:17:13 2016
From: doug.simon at oracle.com (Doug Simon)
Date: Fri, 18 Nov 2016 17:17:13 +0100
Subject: Unsafe.storeFence produces a floating fence
In-Reply-To: <1a3df2c3-94d2-e10e-a242-edb71dc26f31@redhat.com>
References: <1a3df2c3-94d2-e10e-a242-edb71dc26f31@redhat.com>
Message-ID: <1A571AAF-11F4-49FD-9FC2-C64AFC89F4A8@oracle.com>

Hi Andrew,

Can you please create an issue on github for this.

-Doug

> On 18 Nov 2016, at 16:45, Andrew Haley <aph at redhat.com> wrote:
> 
> Here's a jcstress test:
> 
> public class ShortFencedTest {
> 
>    Shell shell;
> 
>    public static class Shell {
>        short x;
> 
>        public Shell() {
>            this.x = (short) 0xFFFF;
>            UnsafeHolder.U.storeFence();
>        }
>    }
> 
>    @Actor
>    public void actor1() {
>        shell = new Shell();
>    }
> 
>    @Actor
>    public void actor2(ShortResult1 r) {
>        Shell sh = shell;
>        r.r1 = (sh == null) ? 42 : sh.x;
>    }
> 
> }
> 
> the problem is that the call to storeFence() floats above the store to
> this.x in Shell().  In fact, it even floats past the object creation.
> 
> Here's the generated assembly code for actor1.  The storeFence has floated past
> the creation of the object, all the way to the entry point of actor1:
> 
> [Verified Entry Point]
>  0x0000007fa5593900: nop
>  0x0000007fa5593904: sub	x8, sp, #0x4, lsl #12
>  0x0000007fa5593908: str	xzr, [x8]
>  0x0000007fa559390c: sub	sp, sp, #0x30
>  0x0000007fa5593910: stp	x29, x30, [sp,#32]
>  0x0000007fa5593914: dmb	ish             ;*invokevirtual storeFence {reexecute=0 rethrow=0 return_oop=0}
>                                                ; - sun.misc.Unsafe::storeFence at 3 (line 1215)
>                                                ; - org.openjdk.jcstress.tests.init.primitives.fenced.ShortFencedTest$Shell::<init>@12 (line 47)
>                                                ; - org.openjdk.jcstress.tests.init.primitives.fenced.ShortFencedTest::actor1 at 5 (line 53)
> 
>  0x0000007fa5593918: orr	x0, xzr, #0x60
>  0x0000007fa559391c: ldr	x2, [x28,x0]
>  0x0000007fa5593920: orr	x3, xzr, #0x70
>  0x0000007fa5593924: ldr	x3, [x28,x3]
>  0x0000007fa5593928: add	x4, x2, #0x10
>  0x0000007fa559392c: cmp	x4, x3
>  0x0000007fa5593930: b.hi	0x0000007fa55939bc
>  0x0000007fa5593934: str	x4, [x28,x0]
>  0x0000007fa5593938: orr	x0, xzr, #0x180
>  0x0000007fa559393c: nop
>  0x0000007fa5593940: mov	x0, xzr
>  0x0000007fa5593944: orr	x3, xzr, #0x1
>  0x0000007fa5593948: str	x3, [x2,x0]
>  0x0000007fa559394c: orr	x0, xzr, #0x8
>  0x0000007fa5593950: mov	x3, #0xd0000               	// #851968
>                                                ;   {metadata('org/openjdk/jcstress/tests/init/primitives/fenced/ShortFencedTest$Shell')}
>  0x0000007fa5593954: movk	x3, #0x83f8
>  0x0000007fa5593958: str	w3, [x2,x0]
>  0x0000007fa559395c: orr	x0, xzr, #0xc
>  0x0000007fa5593960: str	wzr, [x2,x0]
>  0x0000007fa5593964: dmb	ish
>  0x0000007fa5593968: mov	x0, x2
>  0x0000007fa559396c: orr	x2, xzr, #0xc
>  0x0000007fa5593970: orr	x3, xzr, #0xffff
>  0x0000007fa5593974: strh	w3, [x0,x2]
>  0x0000007fa5593978: orr	x2, xzr, #0xc
>  0x0000007fa559397c: lsr	x0, x0, #3
>  0x0000007fa5593980: str	w0, [x1,x2]     ;*putfield shell {reexecute=0 rethrow=0 return_oop=0}
>                                                ; - org.openjdk.jcstress.tests.init.primitives.fenced.ShortFencedTest::actor1 at 8 (line 53)
> 
>  0x0000007fa5593984: lsr	x1, x1, #9
>  0x0000007fa5593988: mov	x0, #0xf000                	// #61440
>  0x0000007fa559398c: movk	x0, #0xafe5, lsl #16
>  0x0000007fa5593990: movk	x0, #0x7f, lsl #32
>  0x0000007fa5593994: add	x1, x1, x0
>  0x0000007fa5593998: mov	x0, xzr
>  0x0000007fa559399c: strb	wzr, [x1,x0]
>  0x0000007fa55939a0: ldp	x29, x30, [sp,#32]
>  0x0000007fa55939a4: add	sp, sp, #0x30
>  0x0000007fa55939a8: mov	x8, #0x5000                	// #20480
>                                                ;   {poll_return}
>  0x0000007fa55939ac: movk	x8, #0xb4fd, lsl #16
>  0x0000007fa55939b0: movk	x8, #0x7f, lsl #32
>  0x0000007fa55939b4: ldr	wzr, [x8]       ;   {poll_return}
>  0x0000007fa55939b8: ret                       ;*return {reexecute=0 rethrow=0 return_oop=0}
>                                                ; - org.openjdk.jcstress.tests.init.primitives.fenced.ShortFencedTest::actor1 at 11 (line 54)
> 
> UnsafeFencePlugin looks like:
> 
>    public static class UnsafeFencePlugin implements InvocationPlugin {
> 
>        private final int barriers;
> 
>        public UnsafeFencePlugin(int barriers) {
>            this.barriers = barriers;
>        }
> 
>        @Override
>        public boolean apply(GraphBuilderContext b, ResolvedJavaMethod targetMethod, Receiver unsafe) {
>            // Emits a null-check for the otherwise unused receiver
>            unsafe.get();
>            b.add(new MembarNode(barriers));
>            return true;
>        }
>    }
> 
> MembarNode is a FixedWithNextNode, but in this case it's simply added to the
> graph.
> 
> I'd love to have an opportunity to fix this bug, but I'd like some guidance.
> 
> Andrew.
> 


From aph at redhat.com  Fri Nov 18 16:20:24 2016
From: aph at redhat.com (Andrew Haley)
Date: Fri, 18 Nov 2016 16:20:24 +0000
Subject: Unsafe.storeFence produces a floating fence
In-Reply-To: <1A571AAF-11F4-49FD-9FC2-C64AFC89F4A8@oracle.com>
References: <1a3df2c3-94d2-e10e-a242-edb71dc26f31@redhat.com>
	<1A571AAF-11F4-49FD-9FC2-C64AFC89F4A8@oracle.com>
Message-ID: <ea7ecd6f-7f50-ce95-9125-c76a66fd3054@redhat.com>

On 18/11/16 16:17, Doug Simon wrote:
> Can you please create an issue on github for this.

Oh no, something else to learn!  OK.  :-)

Andrew.


From doug.simon at oracle.com  Fri Nov 18 16:27:06 2016
From: doug.simon at oracle.com (Doug Simon)
Date: Fri, 18 Nov 2016 17:27:06 +0100
Subject: Unsafe.storeFence produces a floating fence
In-Reply-To: <ea7ecd6f-7f50-ce95-9125-c76a66fd3054@redhat.com>
References: <1a3df2c3-94d2-e10e-a242-edb71dc26f31@redhat.com>
	<1A571AAF-11F4-49FD-9FC2-C64AFC89F4A8@oracle.com>
	<ea7ecd6f-7f50-ce95-9125-c76a66fd3054@redhat.com>
Message-ID: <5AB9AC45-0AC8-4B98-B018-91E99E7D1BE4@oracle.com>


> On 18 Nov 2016, at 17:20, Andrew Haley <aph at redhat.com> wrote:
> 
> On 18/11/16 16:17, Doug Simon wrote:
>> Can you please create an issue on github for this.
> 
> Oh no, something else to learn!  OK.  :-)

Thanks - we like using modern tools as well as email ;-)

-Doug

From aph at redhat.com  Fri Nov 18 16:42:12 2016
From: aph at redhat.com (Andrew Haley)
Date: Fri, 18 Nov 2016 16:42:12 +0000
Subject: Unsafe.storeFence produces a floating fence
In-Reply-To: <5AB9AC45-0AC8-4B98-B018-91E99E7D1BE4@oracle.com>
References: <1a3df2c3-94d2-e10e-a242-edb71dc26f31@redhat.com>
	<1A571AAF-11F4-49FD-9FC2-C64AFC89F4A8@oracle.com>
	<ea7ecd6f-7f50-ce95-9125-c76a66fd3054@redhat.com>
	<5AB9AC45-0AC8-4B98-B018-91E99E7D1BE4@oracle.com>
Message-ID: <f246743b-6130-639b-9a41-c7905608e89b@redhat.com>

On 18/11/16 16:27, Doug Simon wrote:
> 
>> On 18 Nov 2016, at 17:20, Andrew Haley <aph at redhat.com> wrote:
>>
>> On 18/11/16 16:17, Doug Simon wrote:
>>> Can you please create an issue on github for this.
>>
>> Oh no, something else to learn!  OK.  :-)
> 
> Thanks - we like using modern tools as well as email ;-)

Ah, the kids these days...

Anyway, I'd quite like to discuss this general issue.  If you're
generating code, either with a Snippet or parsing bytecode, how do you
go about creating a node that can't be moved?  You don't necessarily
know where your immediate successors or predecessors are.  I guess you
could search the graph and find something, but in the case of a memory
fence all you'd like the graph builder to do is insert an immovable
node.

Andrew.


From gilles.m.duboscq at oracle.com  Fri Nov 18 17:53:11 2016
From: gilles.m.duboscq at oracle.com (Gilles Duboscq)
Date: Fri, 18 Nov 2016 18:53:11 +0100
Subject: Unsafe.storeFence produces a floating fence
In-Reply-To: <f246743b-6130-639b-9a41-c7905608e89b@redhat.com>
References: <1a3df2c3-94d2-e10e-a242-edb71dc26f31@redhat.com>
	<1A571AAF-11F4-49FD-9FC2-C64AFC89F4A8@oracle.com>
	<ea7ecd6f-7f50-ce95-9125-c76a66fd3054@redhat.com>
	<5AB9AC45-0AC8-4B98-B018-91E99E7D1BE4@oracle.com>
	<f246743b-6130-639b-9a41-c7905608e89b@redhat.com>
Message-ID: <0e78f888-7323-da8f-f707-cb2e1cdeafd1@oracle.com>

Hi Andrew,

>From what i see, GraphBuilderContext.add already takes care of adding the node to the control-flow.
If you want to see how that happens, follow this call chain:
GraphBuilderContext.add -> BytecodeParser.append -> BytecodeParser.updateLastInstruction

So i think the MembarNode is correctly added in the control-flow at the point where you expect it.
I don't think that the store floats anywhere, it's fixed.

Looking at the code of actor1 i think what happens is rather the allocation of the Shell object and the initialization of x that moves down to the end of actor1 because of escape analysis.

Checking the graph in IGV might help understanding what happens.

 Gilles

On 18/11/16 17:42, Andrew Haley wrote:
> On 18/11/16 16:27, Doug Simon wrote:
>>
>>> On 18 Nov 2016, at 17:20, Andrew Haley <aph at redhat.com> wrote:
>>>
>>> On 18/11/16 16:17, Doug Simon wrote:
>>>> Can you please create an issue on github for this.
>>>
>>> Oh no, something else to learn!  OK.  :-)
>>
>> Thanks - we like using modern tools as well as email ;-)
> 
> Ah, the kids these days...
> 
> Anyway, I'd quite like to discuss this general issue.  If you're
> generating code, either with a Snippet or parsing bytecode, how do you
> go about creating a node that can't be moved?  You don't necessarily
> know where your immediate successors or predecessors are.  I guess you
> could search the graph and find something, but in the case of a memory
> fence all you'd like the graph builder to do is insert an immovable
> node.
> 
> Andrew.
> 

From tom.rodriguez at oracle.com  Fri Nov 18 18:14:14 2016
From: tom.rodriguez at oracle.com (Tom Rodriguez)
Date: Fri, 18 Nov 2016 10:14:14 -0800
Subject: Unsafe.storeFence produces a floating fence
In-Reply-To: <0e78f888-7323-da8f-f707-cb2e1cdeafd1@oracle.com>
References: <1a3df2c3-94d2-e10e-a242-edb71dc26f31@redhat.com>
	<1A571AAF-11F4-49FD-9FC2-C64AFC89F4A8@oracle.com>
	<ea7ecd6f-7f50-ce95-9125-c76a66fd3054@redhat.com>
	<5AB9AC45-0AC8-4B98-B018-91E99E7D1BE4@oracle.com>
	<f246743b-6130-639b-9a41-c7905608e89b@redhat.com>
	<0e78f888-7323-da8f-f707-cb2e1cdeafd1@oracle.com>
Message-ID: <66510D19-36A5-4FCC-B541-0B845413E7B2@oracle.com>

For reference https://github.com/graalvm/graal-core/issues/222 <https://github.com/graalvm/graal-core/issues/222> is the issue filed for this.

tom

> On Nov 18, 2016, at 9:53 AM, Gilles Duboscq <gilles.m.duboscq at oracle.com> wrote:
> 
> Hi Andrew,
> 
> From what i see, GraphBuilderContext.add already takes care of adding the node to the control-flow.
> If you want to see how that happens, follow this call chain:
> GraphBuilderContext.add -> BytecodeParser.append -> BytecodeParser.updateLastInstruction
> 
> So i think the MembarNode is correctly added in the control-flow at the point where you expect it.
> I don't think that the store floats anywhere, it's fixed.
> 
> Looking at the code of actor1 i think what happens is rather the allocation of the Shell object and the initialization of x that moves down to the end of actor1 because of escape analysis.
> 
> Checking the graph in IGV might help understanding what happens.
> 
> Gilles
> 
> On 18/11/16 17:42, Andrew Haley wrote:
>> On 18/11/16 16:27, Doug Simon wrote:
>>> 
>>>> On 18 Nov 2016, at 17:20, Andrew Haley <aph at redhat.com> wrote:
>>>> 
>>>> On 18/11/16 16:17, Doug Simon wrote:
>>>>> Can you please create an issue on github for this.
>>>> 
>>>> Oh no, something else to learn!  OK.  :-)
>>> 
>>> Thanks - we like using modern tools as well as email ;-)
>> 
>> Ah, the kids these days...
>> 
>> Anyway, I'd quite like to discuss this general issue.  If you're
>> generating code, either with a Snippet or parsing bytecode, how do you
>> go about creating a node that can't be moved?  You don't necessarily
>> know where your immediate successors or predecessors are.  I guess you
>> could search the graph and find something, but in the case of a memory
>> fence all you'd like the graph builder to do is insert an immovable
>> node.
>> 
>> Andrew.
>> 


From aph at redhat.com  Fri Nov 18 18:14:15 2016
From: aph at redhat.com (Andrew Haley)
Date: Fri, 18 Nov 2016 18:14:15 +0000
Subject: ...and another one
Message-ID: <636917a2-fc83-e58f-022e-7248995db303@redhat.com>

I think this one is even more interesting than the store barrier
problem.

    public volatile Object referent;
    public final WeakReference<Object> ref;
    public final ReferenceQueue<Object> refQueue;

    public WeakReferenceTest() {
        referent = new Object();
        refQueue = new ReferenceQueue<>();
        ref = new WeakReference<>(referent, refQueue);
    }

    @Actor
    public void actor1() {
        while (ref.get() != null) {
            // burn!
        }
    }

So, actor1 is spinning in a loop, waiting for ref.get() to become
null.  This won't happen until a GC, and this will be a safepoint.
However, the code Graal generates is:

  0x0000007f8546e5f0: mov	x0, #0x7000                	// #28672
                                                ;   {poll}
  0x0000007f8546e5f4: movk	x0, #0x926b, lsl #16
  0x0000007f8546e5f8: movk	x0, #0x7f, lsl #32  ; ImmutableOopMap{c_rarg1=Oop }
                                                ;*aload_0 {reexecute=1 rethrow=0 return_oop=0}
                                                ; - org.openjdk.jcstress.tests.interrupt.WeakReferenceTest::actor1 at 0 (line 63)

  0x0000007f8546e5fc: ldr	wzr, [x0]       ;   {poll}
  0x0000007f8546e600: b	0x0000007f8546e5f0

Wow!  This is an infinite loop with a safepoint check in the middle.
Graal apparently doesn't believe that values can change from non-null
at a safepoint.  C2 seems to treat safepoints specially in this
regard.

Yes, I'll file a bug report.  Is it the case that effectively all of
the discussion about Graal bugs goes into the Github bug discussions?

Andrew.

From aph at redhat.com  Fri Nov 18 18:16:08 2016
From: aph at redhat.com (Andrew Haley)
Date: Fri, 18 Nov 2016 18:16:08 +0000
Subject: Unsafe.storeFence produces a floating fence
In-Reply-To: <0e78f888-7323-da8f-f707-cb2e1cdeafd1@oracle.com>
References: <1a3df2c3-94d2-e10e-a242-edb71dc26f31@redhat.com>
	<1A571AAF-11F4-49FD-9FC2-C64AFC89F4A8@oracle.com>
	<ea7ecd6f-7f50-ce95-9125-c76a66fd3054@redhat.com>
	<5AB9AC45-0AC8-4B98-B018-91E99E7D1BE4@oracle.com>
	<f246743b-6130-639b-9a41-c7905608e89b@redhat.com>
	<0e78f888-7323-da8f-f707-cb2e1cdeafd1@oracle.com>
Message-ID: <0170f80f-3a8c-ef22-da1d-b13991e608a3@redhat.com>

On 18/11/16 17:53, Gilles Duboscq wrote:

> From what i see, GraphBuilderContext.add already takes care of
> adding the node to the control-flow.

> If you want to see how that happens, follow this call chain:
> 
> GraphBuilderContext.add -> BytecodeParser.append -> BytecodeParser.updateLastInstruction
> 
> So i think the MembarNode is correctly added in the control-flow at
> the point where you expect it.
> I don't think that the store floats anywhere, it's fixed.

Yeah, I thought it did, but then this...

> Looking at the code of actor1 i think what happens is rather the
> allocation of the Shell object and the initialization of x that
> moves down to the end of actor1 because of escape analysis.

OK, got that.  Thanks everybody.

Andrew.

From eregontp at gmail.com  Fri Nov 18 18:33:22 2016
From: eregontp at gmail.com (Benoit Daloze)
Date: Fri, 18 Nov 2016 19:33:22 +0100
Subject: ...and another one
In-Reply-To: <636917a2-fc83-e58f-022e-7248995db303@redhat.com>
References: <636917a2-fc83-e58f-022e-7248995db303@redhat.com>
Message-ID: <CANLTa0CCy7PDkGTPSfVoPu4F=ZYtfGAE4SvUJv1MPfCUR5tUAg@mail.gmail.com>

Just curious, did you run the full jcstress suite?
I guess it would reveal a few problems due to missing barriers currently.

On Fri, Nov 18, 2016 at 7:14 PM, Andrew Haley <aph at redhat.com> wrote:

> I think this one is even more interesting than the store barrier
> problem.
>
>     public volatile Object referent;
>     public final WeakReference<Object> ref;
>     public final ReferenceQueue<Object> refQueue;
>
>     public WeakReferenceTest() {
>         referent = new Object();
>         refQueue = new ReferenceQueue<>();
>         ref = new WeakReference<>(referent, refQueue);
>     }
>
>     @Actor
>     public void actor1() {
>         while (ref.get() != null) {
>             // burn!
>         }
>     }
>
> So, actor1 is spinning in a loop, waiting for ref.get() to become
> null.  This won't happen until a GC, and this will be a safepoint.
> However, the code Graal generates is:
>
>   0x0000007f8546e5f0: mov       x0, #0x7000                     // #28672
>                                                 ;   {poll}
>   0x0000007f8546e5f4: movk      x0, #0x926b, lsl #16
>   0x0000007f8546e5f8: movk      x0, #0x7f, lsl #32  ;
> ImmutableOopMap{c_rarg1=Oop }
>                                                 ;*aload_0 {reexecute=1
> rethrow=0 return_oop=0}
>                                                 ; -
> org.openjdk.jcstress.tests.interrupt.WeakReferenceTest::actor1 at 0 (line 63)
>
>   0x0000007f8546e5fc: ldr       wzr, [x0]       ;   {poll}
>   0x0000007f8546e600: b 0x0000007f8546e5f0
>
> Wow!  This is an infinite loop with a safepoint check in the middle.
> Graal apparently doesn't believe that values can change from non-null
> at a safepoint.  C2 seems to treat safepoints specially in this
> regard.
>
> Yes, I'll file a bug report.  Is it the case that effectively all of
> the discussion about Graal bugs goes into the Github bug discussions?
>
> Andrew.
>

From aph at redhat.com  Fri Nov 18 18:42:08 2016
From: aph at redhat.com (Andrew Haley)
Date: Fri, 18 Nov 2016 18:42:08 +0000
Subject: ...and another one
In-Reply-To: <CANLTa0CCy7PDkGTPSfVoPu4F=ZYtfGAE4SvUJv1MPfCUR5tUAg@mail.gmail.com>
References: <636917a2-fc83-e58f-022e-7248995db303@redhat.com>
	<CANLTa0CCy7PDkGTPSfVoPu4F=ZYtfGAE4SvUJv1MPfCUR5tUAg@mail.gmail.com>
Message-ID: <74cec9d3-f260-7aa3-4738-3b0ab20b9e12@redhat.com>

On 18/11/16 18:33, Benoit Daloze wrote:
> Just curious, did you run the full jcstress suite?
> I guess it would reveal a few problems due to missing barriers currently.

It does, but I have file a bug report for one of those: fix that bug,
and the other jcstress bugs should be fixed as well.  I'm not going to
report any more similar failures.

Andrew.


From raffaello.giulietti at supsi.ch  Fri Nov 18 21:05:50 2016
From: raffaello.giulietti at supsi.ch (Raffaello Giulietti)
Date: Fri, 18 Nov 2016 21:05:50 +0000
Subject: Building on JDK9 EA build 144/Windows, try #1
Message-ID: <f4c0766a-4358-d261-eed3-36191187522d@supsi.ch>

Hi guys,

I guess few of you usually work on Windows.

Nevertheless, since starting with build 143 the JDK 9 EA release now
supports JVMCI, I decided to give some tries building a Truffle/Graal
environment on Windows 10 (64 bit).

***
If you feel this makes no sense at this stage of maturity of both JDK 9
and Graal, please let me know.
***

The reasoning is that by using JDK 9 with JVMCI, I can avoid the complex
and weakly documented procedure to build a JDK with JVMCI from scratch
on Windows. The hope is that building only Graal and Truffle, which
afaik are pure Java projects, is easier when targeting this platform.

So, along with JDK 9b144, I also installed Git
(https://git-scm.com/download/win) and Python 2.7
(https://www.python.org/downloads/release/python-2712/). Git for Windows
comes with a bash and some basic Unix commands.

Then, following the instruction for building Graal
(https://github.com/graalvm/graal-core), when it comes to the first
  $mx.cmd build
I stumble across a first error about the impossibility of creating a
file that already exists (see the 1st trace below)

If I insist and immediately issue another
  $mx.cmd build
I now stumble across Java related errors (2nd trace below).

I repeated this a couple of times taking care of removing the graal root
folder and starting from scratch with the building instructions.

If anybody could direct me on what I should look at in more details,
that would be a great help. I have no clues and, I confess, not much
willingness to delve into the scripts.

FYI, here's the java -version
java version "9-ea"
Java(TM) SE Runtime Environment (build 9-ea+144)
Java HotSpot(TM) 64-Bit Server VM (build 9-ea+144, mixed mode)

Sorry for the long and boring traces, but I can't decide what's
important to you and what's not.

Greetings
Raffaello



1st trace
---------
Compiling com.oracle.mxtool.compilerserver with javac...
[C:\Users\Raffaello\graal\mx\mxbuild\java\com.oracle.mxtoo
l.compilerserver\bin\com\oracle\mxtool\compilerserver\CompilerDaemon.class
does not exist]
warning: [options] bootstrap class path not set in conjunction with
-source 1.7
C:\Users\Raffaello\graal\mx\java\com.oracle.mxtool.compilerserver\src\com\oracle\mxtool\compilerserver\JavacDaemon.
      java:31: warning: [deprecation] newInstance() in Class has been
deprecated
            final Object receiver = javacMainClass.newInstance();
                                                  ^
  where T is a type-variable:
    T extends Object declared in class Class
2 warnings
Compiling com.oracle.truffle.api with javac-daemon...
[C:\Users\Raffaello\graal\truffle\mxbuild\truffle\com.oracle.
truffle.api\bin\com\oracle\truffle\api\Assumption.class does not exist]
warning: [options] bootstrap class path not set in conjunction with
-source 1.7
C:\Users\Raffaello\graal\truffle\truffle\com.oracle.truffle.api\src\com\oracle\truffle\api\Truffle.java:68:
warning       : [deprecation] newInstance() in Class has been deprecated
                        return (TruffleRuntime) runtimeClass.newInstance();
                                                            ^
  where T is a type-variable:
    T extends Object declared in class Class
C:\Users\Raffaello\graal\truffle\truffle\com.oracle.truffle.api\src\com\oracle\truffle\api\nodes\GraphPrintVisitor.
      java:565: warning: [deprecation] newInstance() in Class has been
deprecated
            return customHandlerClass.newInstance();
                                     ^
  where T is a type-variable:
    T extends Object declared in class Class
3 warnings
Compiling com.oracle.truffle.api.dsl with javac-daemon... [dependency
com.oracle.truffle.api updated]
warning: [options] bootstrap class path not set in conjunction with
-source 1.7
1 warning
Compiling com.oracle.truffle.api.interop with javac-daemon...
[dependency com.oracle.truffle.api updated]
warning: [options] bootstrap class path not set in conjunction with
-source 1.7
C:\Users\Raffaello\graal\truffle\truffle\com.oracle.truffle.api.interop\src\com\oracle\truffle\api\interop\Message.
      java:526: warning: [deprecation] newInstance() in Class has been
deprecated
                    return (Message) Class.forName(message, false,
l).newInstance();
                                                                     ^
  where T is a type-variable:
    T extends Object declared in class Class
2 warnings
Compiling com.oracle.truffle.api.instrumentation with javac-daemon...
[dependency com.oracle.truffle.api updated]
warning: [options] bootstrap class path not set in conjunction with
-source 1.7
C:\Users\Raffaello\graal\truffle\truffle\com.oracle.truffle.api.instrumentation\src\com\oracle\truffle\api\instrume
      ntation\InstrumentationHandler.java:384: warning: [deprecation]
newInstance() in Class has been deprecated
            wrapper = ((InstrumentableFactory<Node>)
factory.newInstance()).createWrapper(instrumentableNode, probe       );
                                                            ^
  where T is a type-variable:
    T extends Object declared in class Class
C:\Users\Raffaello\graal\truffle\truffle\com.oracle.truffle.api.instrumentation\src\com\oracle\truffle\api\instrume
      ntation\InstrumentationHandler.java:759: warning: [deprecation]
newInstance() in Class has been deprecated
                this.instrument = (TruffleInstrument)
instrumentClass.newInstance();
                                                                     ^
  where T is a type-variable:
    T extends Object declared in class Class
3 warnings
Compiling com.oracle.truffle.dsl.processor with javac-daemon...
[dependency com.oracle.truffle.api.dsl updated]
warning: [options] bootstrap class path not set in conjunction with
-source 1.7
1 warning
Compiling com.oracle.truffle.api.object with javac-daemon... [dependency
com.oracle.truffle.api.interop updated]
warning: [options] bootstrap class path not set in conjunction with
-source 1.7
C:\Users\Raffaello\graal\truffle\truffle\com.oracle.truffle.api.object\src\com\oracle\truffle\api\object\Layout.jav
      a:142: warning: [deprecation] newInstance() in Class has been
deprecated
                bestLayoutFactory = (LayoutFactory) clazz.newInstance();
                                                         ^
  where T is a type-variable:
    T extends Object declared in class Class
2 warnings
Compiling com.oracle.truffle.api.object.dsl with javac-daemon...
[dependency com.oracle.truffle.api.object updated]
warning: [options] bootstrap class path not set in conjunction with
-source 1.7
1 warning
Compiling com.oracle.truffle.object.dsl.processor with javac-daemon...
[dependency com.oracle.truffle.api.object.ds       l updated]
warning: [options] bootstrap class path not set in conjunction with
-source 1.7
1 warning
Archiving TRUFFLE_DSL_PROCESSOR_INTERNAL... [dependency
com.oracle.truffle.dsl.processor updated]
C:/Users/Raffaello/graal/mx/mx.py:1058: UserWarning: Duplicate name:
'META-INF/services/javax.annotation.processing       .Processor'
  arc.zf.writestr(arcname, contents)
C:/Users/Raffaello/graal/mx/mx.py:6654: UserWarning: Duplicate name:
'META-INF/services/javax.annotation.processing       .Processor'
  arc.zf.writestr(arcname, '\n'.join(dist.definedAnnotationProcessors) +
'\n')
Traceback (most recent call last):
  File "C:/Users/Raffaello/graal/mx/mx.py", line 14468, in <module>
    main()
  File "C:/Users/Raffaello/graal/mx/mx.py", line 14452, in main
    retcode = c(command_args)
  File "C:/Users/Raffaello/graal/mx/mx.py", line 9577, in build
    t.execute()
  File "C:/Users/Raffaello/graal/mx/mx.py", line 669, in execute
    self.build()
  File "C:/Users/Raffaello/graal/mx/mx.py", line 1212, in build
    self.subject.make_archive()
  File "C:/Users/Raffaello/graal/mx/mx.py", line 1161, in make_archive
    self.notify_updated()
  File "C:/Users/Raffaello/graal/mx/mx.py", line 783, in notify_updated
    l(self)
  File "C:/Users/Raffaello/graal/mx/mx.py", line 6656, in
_refineAnnotationProcessorServiceConfig
    arc.zf.writestr(arcname, lp.read(arcname))
  File "C:/Users/Raffaello/graal/mx/mx.py", line 9976, in __exit__
    SafeFileCreation.__exit__(self, exc_type, exc_value, traceback)
  File "C:/Users/Raffaello/graal/mx/mx.py", line 9949, in __exit__
    os.rename(self.tmpPath, self.path)
WindowsError: [Error 183] Cannot create a file when that file already exists
java.net.SocketException: Connection reset
        at
java.base/java.net.SocketInputStream.read(SocketInputStream.java:209)
        at
java.base/java.net.SocketInputStream.read(SocketInputStream.java:141)
        at
java.base/sun.nio.cs.StreamDecoder.readBytes(StreamDecoder.java:284)
        at
java.base/sun.nio.cs.StreamDecoder.implRead(StreamDecoder.java:326)
        at java.base/sun.nio.cs.StreamDecoder.read(StreamDecoder.java:178)
        at
java.base/java.io.InputStreamReader.read(InputStreamReader.java:185)
        at java.base/java.io.BufferedReader.fill(BufferedReader.java:161)
        at
java.base/java.io.BufferedReader.readLine(BufferedReader.java:325)
        at
java.base/java.io.BufferedReader.readLine(BufferedReader.java:390)
        at
com.oracle.mxtool.compilerserver.CompilerDaemon$Connection.run(CompilerDaemon.java:133)
        at
java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:514)
        at
java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
        at
java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1161)
        at
java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635)
        at java.base/java.lang.Thread.run(Thread.java:844)


		
		

		
		
2nd trace
---------
Compiling com.oracle.truffle.api.interop.java with javac-daemon...
[C:\Users\Raffaello\graal\truffle\mxbuild\truffle\com.oracle.truffle.api.interop.java\bin\com\oracle\truffle\api\interop\java\ArrayWriteNode.class
does not exist]
warning: [options] bootstrap class path not set in conjunction with
-source 1.7
C:\Users\Raffaello\graal\truffle\truffle\com.oracle.truffle.api.interop.java\src\com\oracle\truffle\api\interop\java\JavaObject.java:44:
error: cannot find symbol
        return JavaObjectMessageResolutionForeign.createAccess();
               ^
  symbol:   variable JavaObjectMessageResolutionForeign
  location: class JavaObject
C:\Users\Raffaello\graal\truffle\truffle\com.oracle.truffle.api.interop.java\src\com\oracle\truffle\api\interop\java\JavaFunctionMessageResolution.java:62:
error: cannot find symbol
                    this.toJava[i] = ToJavaNodeGen.create();
                                     ^
  symbol:   variable ToJavaNodeGen
  location: class DoExecuteNode
C:\Users\Raffaello\graal\truffle\truffle\com.oracle.truffle.api.interop.java\src\com\oracle\truffle\api\interop\java\JavaFunctionObject.java:47:
error: cannot find symbol
        return JavaFunctionMessageResolutionForeign.createAccess();
               ^
  symbol:   variable JavaFunctionMessageResolutionForeign
  location: class JavaFunctionObject
C:\Users\Raffaello\graal\truffle\truffle\com.oracle.truffle.api.interop.java\src\com\oracle\truffle\api\interop\java\JavaInterop.java:151:
error: cannot find symbol
        RootNode root = new TemporaryConvertRoot(TruffleLanguage.class,
ToJavaNodeGen.create(), foreignObject, type);
                                                                        ^
  symbol:   variable ToJavaNodeGen
  location: class JavaInterop
C:\Users\Raffaello\graal\truffle\truffle\com.oracle.truffle.api.interop.java\src\com\oracle\truffle\api\interop\java\JavaInterop.java:257:
error: cannot find symbol
        RootNode root = new TemporaryConvertRoot(TruffleLanguage.class,
ToJavaNodeGen.create(), function, functionalType);
                                                                        ^
  symbol:   variable ToJavaNodeGen
  location: class JavaInterop
C:\Users\Raffaello\graal\truffle\truffle\com.oracle.truffle.api.interop.java\src\com\oracle\truffle\api\interop\java\JavaObjectMessageResolution.java:177:
error: cannot find symbol
        @Child private ArrayReadNode read = ArrayReadNodeGen.create();
                                            ^
  symbol:   variable ArrayReadNodeGen
  location: class ReadFieldNode
C:\Users\Raffaello\graal\truffle\truffle\com.oracle.truffle.api.interop.java\src\com\oracle\truffle\api\interop\java\JavaObjectMessageResolution.java:222:
error: cannot find symbol
        @Child private ToJavaNode toJava = ToJavaNodeGen.create();
                                           ^
  symbol:   variable ToJavaNodeGen
  location: class WriteFieldNode
C:\Users\Raffaello\graal\truffle\truffle\com.oracle.truffle.api.interop.java\src\com\oracle\truffle\api\interop\java\JavaObjectMessageResolution.java:250:
error: cannot find symbol
        @Child private ArrayWriteNode write = ArrayWriteNodeGen.create();
                                              ^
  symbol:   variable ArrayWriteNodeGen
  location: class WriteFieldNode
8 errors
1 warning


From jaroslav.tulach at oracle.com  Mon Nov 21 11:16:47 2016
From: jaroslav.tulach at oracle.com (Jaroslav Tulach)
Date: Mon, 21 Nov 2016 12:16:47 +0100
Subject: Updating truffle in graal-core
Message-ID: <2207788.E2qz5kc5hV@pracovni>

Hi.
I'd like to update the truffle dependency in graal-core to 
https://github.com/graalvm/truffle/commit/
f7a3ac94326a030806fc6c091fe545dd0c8498cb
it contains many robustness improvements in Java/Truffle interop and I consider 
it important for all projects to get them.

-jt

PS: Once in I will be able to remove at least one hack in downstream projects.


From aph at redhat.com  Tue Nov 22 14:40:35 2016
From: aph at redhat.com (Andrew Haley)
Date: Tue, 22 Nov 2016 14:40:35 +0000
Subject: AArch64 fixes
Message-ID: <29eb1377-34d6-d380-2420-420c8c87c67d@redhat.com>

I have many fixes to the AArch64 port, some big, most small.

I am looking for the best way to contribute them.  I do not want to
spend a great deal of time creating bug reports for all of them.  I
was wondering if it might be a good idea to create a couple of reports
for the big-ticket items, and then an "AArch64 miscellany" report for
the little ones.

Andrew.

From doug.simon at oracle.com  Tue Nov 22 15:19:03 2016
From: doug.simon at oracle.com (Doug Simon)
Date: Tue, 22 Nov 2016 16:19:03 +0100
Subject: AArch64 fixes
In-Reply-To: <29eb1377-34d6-d380-2420-420c8c87c67d@redhat.com>
References: <29eb1377-34d6-d380-2420-420c8c87c67d@redhat.com>
Message-ID: <F5253EA3-D58D-41F5-9B58-05FD7FEE344F@oracle.com>


> On 22 Nov 2016, at 15:40, Andrew Haley <aph at redhat.com> wrote:
> 
> I have many fixes to the AArch64 port, some big, most small.
> 
> I am looking for the best way to contribute them.  I do not want to
> spend a great deal of time creating bug reports for all of them.  I
> was wondering if it might be a good idea to create a couple of reports
> for the big-ticket items, and then an "AArch64 miscellany" report for
> the little ones.

You can directly create pull requests instead of opening issues if you already have the fixes. The granularity is up to you keeping in mind that isolating complex/risky changes in a separate PR makes reviewing easier as well as identifying gate breakage they may cause.

-Doug

From aph at redhat.com  Tue Nov 22 15:20:20 2016
From: aph at redhat.com (Andrew Haley)
Date: Tue, 22 Nov 2016 15:20:20 +0000
Subject: AArch64 fixes
In-Reply-To: <F5253EA3-D58D-41F5-9B58-05FD7FEE344F@oracle.com>
References: <29eb1377-34d6-d380-2420-420c8c87c67d@redhat.com>
	<F5253EA3-D58D-41F5-9B58-05FD7FEE344F@oracle.com>
Message-ID: <c85b8fd4-4eda-c508-3400-b20d1166d7ed@redhat.com>

On 22/11/16 15:19, Doug Simon wrote:

> You can directly create pull requests instead of opening issues if
> you already have the fixes. The granularity is up to you keeping in
> mind that isolating complex/risky changes in a separate PR makes
> reviewing easier as well as identifying gate breakage they may
> cause.

OK.  I'll do some experimenting to see what works best.

Andrew.

From doug.simon at oracle.com  Wed Nov 23 20:07:31 2016
From: doug.simon at oracle.com (Doug Simon)
Date: Wed, 23 Nov 2016 21:07:31 +0100
Subject: JVMCI 0.23 released
Message-ID: <FB7FF5A6-D627-4C84-B736-3A369A200528@oracle.com>

JVMCI 0.23 updates the base JDK to 8u111 which includes at least one change that may be relevant:

https://bugs.openjdk.java.net/browse/JDK-8156254

It also includes some new JVMCI API:

https://bugs.openjdk.java.net/browse/JDK-8168915
https://bugs.openjdk.java.net/browse/JDK-8169331

The complete set of changes can be seen at http://hg.openjdk.java.net/graal/graal-jvmci-8/log?revcount=200&rev=ancestors%28%27jvmci-0.23%27%29+-+ancestors%28%27jvmci-0.22%27%29

OpenJDK based binaries are already available on GitHub[1]. The OTN binaries[2] should also be available in the next 24 hours.

You will need these binaries (or need to build your own[3]) once you pull https://github.com/graalvm/graal-core/commit/9a4743cd28d58ae567d84cda9ee3260e0989d24c.

-Doug

[1] https://github.com/dougxc/openjdk8-jvmci-builder/releases/tag/jvmci-0.23
[2] labsjdk-8u111-jvmci-0.23-*.tar.gz at http://www.oracle.com/technetwork/oracle-labs/program-languages/downloads/index.html
[3] https://github.com/graalvm/graal-core#building-jvmci-jdk8

From aph at redhat.com  Mon Nov 28 17:34:41 2016
From: aph at redhat.com (Andrew Haley)
Date: Mon, 28 Nov 2016 17:34:41 +0000
Subject: AArch64: what now?
Message-ID: <b479e1f1-e430-a061-c28a-a1bf847dcae1@redhat.com>

I've got to a point where I think the AArch64 Graal port is basically
decent.

However, there are some core Graal bugs which are blocking testing and
other progress.

These are:

 Constructors with final fields need a release memory barrier. #221

 Unsafe.storeFence is moved by Partial Escape Analysis #222

 WeakReference::get() read is elminated from a loop #223

I'd really appreciate help here.  221 has a baffling test failure, and
I've asked for clarification.  222, Partial Escape Analysis is more
than I really want to tackle right now.  223, I have asked for
clarification about whether a MembarNode(0) is an appropriate fix.

Thanks,

Andrew.

From tom.rodriguez at oracle.com  Mon Nov 28 19:03:24 2016
From: tom.rodriguez at oracle.com (Tom Rodriguez)
Date: Mon, 28 Nov 2016 11:03:24 -0800
Subject: AArch64: what now?
In-Reply-To: <b479e1f1-e430-a061-c28a-a1bf847dcae1@redhat.com>
References: <b479e1f1-e430-a061-c28a-a1bf847dcae1@redhat.com>
Message-ID: <A90FE3B1-05C2-41D9-A628-580131B45D4C@oracle.com>


> On Nov 28, 2016, at 9:34 AM, Andrew Haley <aph at redhat.com> wrote:
> 
> I've got to a point where I think the AArch64 Graal port is basically
> decent.
> 
> However, there are some core Graal bugs which are blocking testing and
> other progress.
> 
> These are:
> 
> Constructors with final fields need a release memory barrier. #221

I?m preparing a fix for this.  The test failure is because of the extra MemBar in the graph which isn?t actually needed because the object is non-escaping.  So you can?t simply insert a raw MemBar at the beginning.  It has to be something which is understood by EA so it can be eliminated too.  C2 doesn?t something similar with it?s MemBarNodes.

> 
> Unsafe.storeFence is moved by Partial Escape Analysis #222

Fixing this will require a bit more work since it exposes a general question of the interaction between EA and memory barriers.  Are you actually hitting real failures because of this change?  I mean if the final barriers and the barriers for allocation were being done properly what would be failing?  The Unsafe fence intrinsics don?t seemed to be used very much in the JDK so it wasn?t clear where you were hitting this.

> 
> WeakReference::get() read is elminated from a loop #223

Has been fixed.

tom

> 
> I'd really appreciate help here.  221 has a baffling test failure, and
> I've asked for clarification.  222, Partial Escape Analysis is more
> than I really want to tackle right now.  223, I have asked for
> clarification about whether a MembarNode(0) is an appropriate fix.
> 
> Thanks,
> 
> Andrew.


From aph at redhat.com  Tue Nov 29 11:53:28 2016
From: aph at redhat.com (Andrew Haley)
Date: Tue, 29 Nov 2016 11:53:28 +0000
Subject: testing Graal on JDK 9
Message-ID: <5e90ef58-bbfb-03d0-6ee3-2f4e6943916f@redhat.com>

I get

aph at arm64:/nfs/zebedee/home/graal/clean/graal-core$ JVMCI_VERSION_CHECK=ignore mx -v --strict-compliance gate --strict-mode --tags test
...
project named com.oracle.mxtool.junit was not found:
  project com.oracle.mxtool.junit was removed as Java compliance 1.8 cannot be satisfied by configured JDKs

So I guess I can't run the compliance tests on JDK 9?

Andrew.

From roland.schatz at oracle.com  Tue Nov 29 12:16:18 2016
From: roland.schatz at oracle.com (Roland Schatz)
Date: Tue, 29 Nov 2016 13:16:18 +0100
Subject: testing Graal on JDK 9
In-Reply-To: <5e90ef58-bbfb-03d0-6ee3-2f4e6943916f@redhat.com>
References: <5e90ef58-bbfb-03d0-6ee3-2f4e6943916f@redhat.com>
Message-ID: <eb0fe851-5d14-3680-9c94-2b0eb4344e8d@oracle.com>

Hi Andrew,


On 11/29/2016 12:53 PM, Andrew Haley wrote:
> I get
>
> aph at arm64:/nfs/zebedee/home/graal/clean/graal-core$ JVMCI_VERSION_CHECK=ignore mx -v --strict-compliance gate --strict-mode --tags test
> ...
> project named com.oracle.mxtool.junit was not found:
>    project com.oracle.mxtool.junit was removed as Java compliance 1.8 cannot be satisfied by configured JDKs
>
> So I guess I can't run the compliance tests on JDK 9?

The "--strict-compliance" flag tells mx that it should build each 
project with exactly the jdk version specified in the suites.py file. 
For that to work, you have to give it a path to a jdk 8 in EXTRA_JAVA_HOMES.

You can just remove the "--strict-compliance" flag, then mx will be 
happy with just a jdk 9 and "downgrade" it using the "-source" and 
"-target" flags. It shouldn't really make a difference.

- Roland
>
> Andrew.



From aph at redhat.com  Tue Nov 29 14:24:14 2016
From: aph at redhat.com (Andrew Haley)
Date: Tue, 29 Nov 2016 14:24:14 +0000
Subject: How to run a specific Graal test?
Message-ID: <6d01f1c5-0b55-e39f-55e9-8296ee948674@redhat.com>

"mx -v  gate --tags test" is failing one test.  I'd like to run that one
test case.  How do I do that?

Thanks,

Andrew.

From doug.simon at oracle.com  Tue Nov 29 14:44:01 2016
From: doug.simon at oracle.com (Doug Simon)
Date: Tue, 29 Nov 2016 15:44:01 +0100
Subject: How to run a specific Graal test?
In-Reply-To: <6d01f1c5-0b55-e39f-55e9-8296ee948674@redhat.com>
References: <6d01f1c5-0b55-e39f-55e9-8296ee948674@redhat.com>
Message-ID: <CEF91CCE-25E1-4ED0-B40E-5DD3C6A618F0@oracle.com>

Something like this should work:

mx unittest <class name of test>

If you post the failing stack trace, I could give you more info.

-Doug

> On 29 Nov 2016, at 15:24, Andrew Haley <aph at redhat.com> wrote:
> 
> "mx -v  gate --tags test" is failing one test.  I'd like to run that one
> test case.  How do I do that?
> 
> Thanks,
> 
> Andrew.


From aph at redhat.com  Tue Nov 29 15:08:51 2016
From: aph at redhat.com (Andrew Haley)
Date: Tue, 29 Nov 2016 15:08:51 +0000
Subject: How to run a specific Graal test?
In-Reply-To: <CEF91CCE-25E1-4ED0-B40E-5DD3C6A618F0@oracle.com>
References: <6d01f1c5-0b55-e39f-55e9-8296ee948674@redhat.com>
	<CEF91CCE-25E1-4ED0-B40E-5DD3C6A618F0@oracle.com>
Message-ID: <70445639-61ea-49f3-ada0-17c04eb05cab@redhat.com>

On 29/11/16 14:44, Doug Simon wrote:
> If you post the failing stack trace, I could give you more info.

Attached: it's a VM crash.  As soon as I can duplicate the test in a
debugger I'll be able to fix it.

I find it very difficult to run juinit tests because they don't really
expose what the VM is doing, and it's very hard to run them in a
single test in a debugger.  I'm sure they're not deliberately making
it hard, but it sometimes seems that way.

Thanks,

Andrew.



com.oracle.graal.replacements.test.NewMultiArrayTest started
  test1: #
# A fatal error has been detected by the Java Runtime Environment:
#
#  SIGILL (0x4) at pc=0x0000007f79983dd8, pid=46366, tid=46367
#
# JRE version: OpenJDK Runtime Environment (9.0) (build 9-internal+0-2016-11-28-162713.aph.hs)
# Java VM: OpenJDK 64-Bit Server VM (9-internal+0-2016-11-28-162713.aph.hs, mixed mode, tiered, jvmci, compressed oops, g1 gc, linux-aarch64)
# Problematic frame:
# C  0x0000007f79983dd8
#
# No core dump will be written. Core dumps have been disabled. To enable core dumping, try "ulimit -c unlimited" before starting Java again
#
# An error report file with more information is saved as:
# /nfs/zebedee/home/graal/clean/graal-core/hs_err_pid46366.log
#
# If you would like to submit a bug report, please visit:
#   http://bugreport.java.com/bugreport/crash.jsp
#
[exit code: -6]
  File "/nfs/zebedee/home/graal/clean/mx/mx.py", line 14608, in <module>
    main()
  File "/nfs/zebedee/home/graal/clean/mx/mx.py", line 14592, in main
    retcode = c(command_args)
  File "/nfs/zebedee/home/graal/clean/mx/mx_gate.py", line 347, in gate
    runner(args, tasks)
  File "/nfs/zebedee/home/graal/clean/graal-core/mx.graal-core/mx_graal_core.py", line 474, in _graal_gate_runner
    compiler_gate_runner(['graal-core', 'truffle'], graal_unit_test_runs, graal_bootstrap_tests, tasks, args.extra_vm_argument)
  File "/nfs/zebedee/home/graal/clean/graal-core/mx.graal-core/mx_graal_core.py", line 377, in compiler_gate_runner
    r.run(suites, tasks, ['-XX:-UseJVMCICompiler'] + _remove_empty_entries(extraVMarguments))
  File "/nfs/zebedee/home/graal/clean/graal-core/mx.graal-core/mx_graal_core.py", line 290, in run
    if t: unittest(['--suite', suite, '--fail-fast'] + extra_args + self.args + _remove_empty_entries(extraVMarguments))
  File "/nfs/zebedee/home/graal/clean/mx/mx_unittest.py", line 369, in unittest
    _unittest(args, ['@Test', '@Parameters'], **parsed_args.__dict__)
  File "/nfs/zebedee/home/graal/clean/mx/mx_unittest.py", line 257, in _unittest
    _run_tests(args, harness, vmLauncher, annotations, testfile, blacklist, whitelist, regex, mx.suite(suite) if suite else None)
  File "/nfs/zebedee/home/graal/clean/mx/mx_unittest.py", line 166, in _run_tests
    harness(depsContainingTests, vmLauncher, vmArgs)
  File "/nfs/zebedee/home/graal/clean/mx/mx_unittest.py", line 247, in harness
    vmLauncher.launcher(*config)
  File "/nfs/zebedee/home/graal/clean/graal-core/mx.graal-core/mx_graal_core.py", line 495, in _unittest_vm_launcher
    run_vm(vmArgs + [mainClass] + mainClassArgs)
  File "/nfs/zebedee/home/graal/clean/graal-core/mx.graal-core/mx_graal_core.py", line 775, in run_vm
    return run_java(args, nonZeroIsFatal=nonZeroIsFatal, out=out, err=err, cwd=cwd, timeout=timeout)
  File "/nfs/zebedee/home/graal/clean/graal-core/mx.graal-core/mx_graal_core.py", line 750, in run_java
    return mx.run(cmd, nonZeroIsFatal=nonZeroIsFatal, out=out, err=err, cwd=cwd, env=env)
  File "/nfs/zebedee/home/graal/clean/mx/mx.py", line 8772, in run
    abort(retcode)
  File "/nfs/zebedee/home/graal/clean/mx/mx.py", line 9393, in abort
    traceback.print_stack()
gate: 29 Nov 2016 14:19:40: END:   UnitTests: hosted-product graal-core [0:02:46.926390] [disk (free/total): 24.5GB/618.0GB]
Traceback (most recent call last):
  File "/nfs/zebedee/home/graal/clean/mx/mx_gate.py", line 347, in gate
    runner(args, tasks)
  File "/nfs/zebedee/home/graal/clean/graal-core/mx.graal-core/mx_graal_core.py", line 474, in _graal_gate_runner
    compiler_gate_runner(['graal-core', 'truffle'], graal_unit_test_runs, graal_bootstrap_tests, tasks, args.extra_vm_argument)
  File "/nfs/zebedee/home/graal/clean/graal-core/mx.graal-core/mx_graal_core.py", line 377, in compiler_gate_runner
    r.run(suites, tasks, ['-XX:-UseJVMCICompiler'] + _remove_empty_entries(extraVMarguments))
  File "/nfs/zebedee/home/graal/clean/graal-core/mx.graal-core/mx_graal_core.py", line 290, in run
    if t: unittest(['--suite', suite, '--fail-fast'] + extra_args + self.args + _remove_empty_entries(extraVMarguments))
  File "/nfs/zebedee/home/graal/clean/mx/mx_unittest.py", line 369, in unittest
    _unittest(args, ['@Test', '@Parameters'], **parsed_args.__dict__)
  File "/nfs/zebedee/home/graal/clean/mx/mx_unittest.py", line 257, in _unittest
    _run_tests(args, harness, vmLauncher, annotations, testfile, blacklist, whitelist, regex, mx.suite(suite) if suite else None)
  File "/nfs/zebedee/home/graal/clean/mx/mx_unittest.py", line 166, in _run_tests
    harness(depsContainingTests, vmLauncher, vmArgs)
  File "/nfs/zebedee/home/graal/clean/mx/mx_unittest.py", line 247, in harness
    vmLauncher.launcher(*config)
  File "/nfs/zebedee/home/graal/clean/graal-core/mx.graal-core/mx_graal_core.py", line 495, in _unittest_vm_launcher
    run_vm(vmArgs + [mainClass] + mainClassArgs)
  File "/nfs/zebedee/home/graal/clean/graal-core/mx.graal-core/mx_graal_core.py", line 775, in run_vm
    return run_java(args, nonZeroIsFatal=nonZeroIsFatal, out=out, err=err, cwd=cwd, timeout=timeout)
  File "/nfs/zebedee/home/graal/clean/graal-core/mx.graal-core/mx_graal_core.py", line 750, in run_java
    return mx.run(cmd, nonZeroIsFatal=nonZeroIsFatal, out=out, err=err, cwd=cwd, env=env)
  File "/nfs/zebedee/home/graal/clean/mx/mx.py", line 8772, in run
    abort(retcode)
  File "/nfs/zebedee/home/graal/clean/mx/mx.py", line 9409, in abort
    raise SystemExit(codeOrMessage)
SystemExit: -6

From roland.schatz at oracle.com  Tue Nov 29 15:31:03 2016
From: roland.schatz at oracle.com (Roland Schatz)
Date: Tue, 29 Nov 2016 16:31:03 +0100
Subject: How to run a specific Graal test?
In-Reply-To: <70445639-61ea-49f3-ada0-17c04eb05cab@redhat.com>
References: <6d01f1c5-0b55-e39f-55e9-8296ee948674@redhat.com>
	<CEF91CCE-25E1-4ED0-B40E-5DD3C6A618F0@oracle.com>
	<70445639-61ea-49f3-ada0-17c04eb05cab@redhat.com>
Message-ID: <63eb8f24-bbfa-3f17-a786-27683b1208c4@oracle.com>

On 11/29/2016 04:08 PM, Andrew Haley wrote:
> On 29/11/16 14:44, Doug Simon wrote:
>> If you post the failing stack trace, I could give you more info.
> Attached: it's a VM crash.  As soon as I can duplicate the test in a
> debugger I'll be able to fix it.
>
> I find it very difficult to run juinit tests because they don't really
> expose what the VM is doing, and it's very hard to run them in a
> single test in a debugger.  I'm sure they're not deliberately making
> it hard, but it sometimes seems that way.
One thing you could try is "mx --gdb <something>" to run the VM inside 
gdb. If you need something more flexible, you can use "--vmprefix 
<something>" to prefix the "java" command with something ("--gdb" is 
just a convenience shortcut for "--vmprefix 'gdb --args'").

- Roland

>
> Thanks,
>
> Andrew.
>
>
>
> com.oracle.graal.replacements.test.NewMultiArrayTest started
>    test1: #
> # A fatal error has been detected by the Java Runtime Environment:
> #
> #  SIGILL (0x4) at pc=0x0000007f79983dd8, pid=46366, tid=46367
> #
> # JRE version: OpenJDK Runtime Environment (9.0) (build 9-internal+0-2016-11-28-162713.aph.hs)
> # Java VM: OpenJDK 64-Bit Server VM (9-internal+0-2016-11-28-162713.aph.hs, mixed mode, tiered, jvmci, compressed oops, g1 gc, linux-aarch64)
> # Problematic frame:
> # C  0x0000007f79983dd8
> #
> # No core dump will be written. Core dumps have been disabled. To enable core dumping, try "ulimit -c unlimited" before starting Java again
> #
> # An error report file with more information is saved as:
> # /nfs/zebedee/home/graal/clean/graal-core/hs_err_pid46366.log
> #
> # If you would like to submit a bug report, please visit:
> #   http://bugreport.java.com/bugreport/crash.jsp
> #
> [exit code: -6]
>    File "/nfs/zebedee/home/graal/clean/mx/mx.py", line 14608, in <module>
>      main()
>    File "/nfs/zebedee/home/graal/clean/mx/mx.py", line 14592, in main
>      retcode = c(command_args)
>    File "/nfs/zebedee/home/graal/clean/mx/mx_gate.py", line 347, in gate
>      runner(args, tasks)
>    File "/nfs/zebedee/home/graal/clean/graal-core/mx.graal-core/mx_graal_core.py", line 474, in _graal_gate_runner
>      compiler_gate_runner(['graal-core', 'truffle'], graal_unit_test_runs, graal_bootstrap_tests, tasks, args.extra_vm_argument)
>    File "/nfs/zebedee/home/graal/clean/graal-core/mx.graal-core/mx_graal_core.py", line 377, in compiler_gate_runner
>      r.run(suites, tasks, ['-XX:-UseJVMCICompiler'] + _remove_empty_entries(extraVMarguments))
>    File "/nfs/zebedee/home/graal/clean/graal-core/mx.graal-core/mx_graal_core.py", line 290, in run
>      if t: unittest(['--suite', suite, '--fail-fast'] + extra_args + self.args + _remove_empty_entries(extraVMarguments))
>    File "/nfs/zebedee/home/graal/clean/mx/mx_unittest.py", line 369, in unittest
>      _unittest(args, ['@Test', '@Parameters'], **parsed_args.__dict__)
>    File "/nfs/zebedee/home/graal/clean/mx/mx_unittest.py", line 257, in _unittest
>      _run_tests(args, harness, vmLauncher, annotations, testfile, blacklist, whitelist, regex, mx.suite(suite) if suite else None)
>    File "/nfs/zebedee/home/graal/clean/mx/mx_unittest.py", line 166, in _run_tests
>      harness(depsContainingTests, vmLauncher, vmArgs)
>    File "/nfs/zebedee/home/graal/clean/mx/mx_unittest.py", line 247, in harness
>      vmLauncher.launcher(*config)
>    File "/nfs/zebedee/home/graal/clean/graal-core/mx.graal-core/mx_graal_core.py", line 495, in _unittest_vm_launcher
>      run_vm(vmArgs + [mainClass] + mainClassArgs)
>    File "/nfs/zebedee/home/graal/clean/graal-core/mx.graal-core/mx_graal_core.py", line 775, in run_vm
>      return run_java(args, nonZeroIsFatal=nonZeroIsFatal, out=out, err=err, cwd=cwd, timeout=timeout)
>    File "/nfs/zebedee/home/graal/clean/graal-core/mx.graal-core/mx_graal_core.py", line 750, in run_java
>      return mx.run(cmd, nonZeroIsFatal=nonZeroIsFatal, out=out, err=err, cwd=cwd, env=env)
>    File "/nfs/zebedee/home/graal/clean/mx/mx.py", line 8772, in run
>      abort(retcode)
>    File "/nfs/zebedee/home/graal/clean/mx/mx.py", line 9393, in abort
>      traceback.print_stack()
> gate: 29 Nov 2016 14:19:40: END:   UnitTests: hosted-product graal-core [0:02:46.926390] [disk (free/total): 24.5GB/618.0GB]
> Traceback (most recent call last):
>    File "/nfs/zebedee/home/graal/clean/mx/mx_gate.py", line 347, in gate
>      runner(args, tasks)
>    File "/nfs/zebedee/home/graal/clean/graal-core/mx.graal-core/mx_graal_core.py", line 474, in _graal_gate_runner
>      compiler_gate_runner(['graal-core', 'truffle'], graal_unit_test_runs, graal_bootstrap_tests, tasks, args.extra_vm_argument)
>    File "/nfs/zebedee/home/graal/clean/graal-core/mx.graal-core/mx_graal_core.py", line 377, in compiler_gate_runner
>      r.run(suites, tasks, ['-XX:-UseJVMCICompiler'] + _remove_empty_entries(extraVMarguments))
>    File "/nfs/zebedee/home/graal/clean/graal-core/mx.graal-core/mx_graal_core.py", line 290, in run
>      if t: unittest(['--suite', suite, '--fail-fast'] + extra_args + self.args + _remove_empty_entries(extraVMarguments))
>    File "/nfs/zebedee/home/graal/clean/mx/mx_unittest.py", line 369, in unittest
>      _unittest(args, ['@Test', '@Parameters'], **parsed_args.__dict__)
>    File "/nfs/zebedee/home/graal/clean/mx/mx_unittest.py", line 257, in _unittest
>      _run_tests(args, harness, vmLauncher, annotations, testfile, blacklist, whitelist, regex, mx.suite(suite) if suite else None)
>    File "/nfs/zebedee/home/graal/clean/mx/mx_unittest.py", line 166, in _run_tests
>      harness(depsContainingTests, vmLauncher, vmArgs)
>    File "/nfs/zebedee/home/graal/clean/mx/mx_unittest.py", line 247, in harness
>      vmLauncher.launcher(*config)
>    File "/nfs/zebedee/home/graal/clean/graal-core/mx.graal-core/mx_graal_core.py", line 495, in _unittest_vm_launcher
>      run_vm(vmArgs + [mainClass] + mainClassArgs)
>    File "/nfs/zebedee/home/graal/clean/graal-core/mx.graal-core/mx_graal_core.py", line 775, in run_vm
>      return run_java(args, nonZeroIsFatal=nonZeroIsFatal, out=out, err=err, cwd=cwd, timeout=timeout)
>    File "/nfs/zebedee/home/graal/clean/graal-core/mx.graal-core/mx_graal_core.py", line 750, in run_java
>      return mx.run(cmd, nonZeroIsFatal=nonZeroIsFatal, out=out, err=err, cwd=cwd, env=env)
>    File "/nfs/zebedee/home/graal/clean/mx/mx.py", line 8772, in run
>      abort(retcode)
>    File "/nfs/zebedee/home/graal/clean/mx/mx.py", line 9409, in abort
>      raise SystemExit(codeOrMessage)
> SystemExit: -6



From doug.simon at oracle.com  Tue Nov 29 15:46:22 2016
From: doug.simon at oracle.com (Doug Simon)
Date: Tue, 29 Nov 2016 16:46:22 +0100
Subject: How to run a specific Graal test?
In-Reply-To: <70445639-61ea-49f3-ada0-17c04eb05cab@redhat.com>
References: <6d01f1c5-0b55-e39f-55e9-8296ee948674@redhat.com>
	<CEF91CCE-25E1-4ED0-B40E-5DD3C6A618F0@oracle.com>
	<70445639-61ea-49f3-ada0-17c04eb05cab@redhat.com>
Message-ID: <15AD278C-E1E3-43CC-9DBB-D769DE77B32C@oracle.com>


> On 29 Nov 2016, at 16:08, Andrew Haley <aph at redhat.com> wrote:
> 
> On 29/11/16 14:44, Doug Simon wrote:
>> If you post the failing stack trace, I could give you more info.
> 
> Attached: it's a VM crash.  As soon as I can duplicate the test in a
> debugger I'll be able to fix it.
> 
> I find it very difficult to run juinit tests because they don't really
> expose what the VM is doing, and it's very hard to run them in a
> single test in a debugger.  I'm sure they're not deliberately making
> it hard, but it sometimes seems that way.

I assume that you?re talking about a native debugger, not a Java debugger. In that case, it can be useful to run *only* the crashing test. Assuming the test that fails is NewMultiArrayTest.test1, you can run:

mx -v unittest NewMultiArrayTest#test1

On my Mac, the output includes:

/Library/Java/JavaVirtualMachines/labsjdk1.8.0_111-jvmci-0.23/bin/java -server -XX:+UnlockExperimentalVMOptions -XX:+EnableJVMCI -d64 -Djvmci.class.path.append=/Users/dsimon/graal/graal-core/mxbuild/dists/graal.jar -Xbootclasspath/a:/Users/dsimon/graal/truffle/mxbuild/dists/truffle-api.jar -esa -ea -Djava.awt.headless=true -cp /Users/dsimon/.mx/cache/HAMCREST_42a25dc3219429f0e5d060061f71acb49bf010a0.jar:/Users/dsimon/.mx/cache/JUNIT_4e031bb61df09069aeb2bffb4019e7a5034a4ee0.jar:/Users/dsimon/Dropbox/mx/mxbuild/java/com.oracle.mxtool.junit/bin:/Library/Java/JavaVirtualMachines/labsjdk1.8.0_111-jvmci-0.23/jre/lib/jvmci-services.jar:/Library/Java/JavaVirtualMachines/labsjdk1.8.0_111-jvmci-0.23/jre/lib/jvmci/jvmci-api.jar:/Users/dsimon/graal/graal-core/mxbuild/graal/com.oracle.graal.test/bin:/Users/dsimon/graal/graal-core/mxbuild/graal/com.oracle.graal.api.test/bin:/Users/dsimon/graal/graal-core/mxbuild/graal/com.oracle.graal.graph.test/bin:/Users/dsimon/.mx/cache/JAVA_ALLOCATION_INSTRUMENTER_476d9a44cd19d6b55f81571077dfa972a4f8a083.jar:/Users/dsimon/graal/graal-core/mxbuild/graal/com.oracle.graal.compiler.test/bin:/Users/dsimon/graal/graal-core/mxbuild/graal/com.oracle.graal.replacements.test/bin -XX:-UseJVMCIClassLoader com.oracle.mxtool.junit.MxJUnitWrapper -JUnitEagerStackTrace 'com.oracle.graal.replacements.test.NewMultiArrayTest#test1?

Now I can debug this in lldb as follows:

dsimon at kurz-3 ~/g/graal-core> lldb /Library/Java/JavaVirtualMachines/labsjdk1.8.0_111-jvmci-0.23/bin/java
(lldb) target create "/Library/Java/JavaVirtualMachines/labsjdk1.8.0_111-jvmci-0.23/bin/java"
Current executable set to '/Library/Java/JavaVirtualMachines/labsjdk1.8.0_111-jvmci-0.23/bin/java' (x86_64).
(lldb) run -server -XX:+UnlockExperimentalVMOptions -XX:+EnableJVMCI -d64 -Djvmci.class.path.append=/Users/dsimon/graal/graal-core/mxbuild/dists/graal.jar -Xbootclasspath/a:/Users/dsimon/graal/truffle/mxbuild/dists/truffle-api.jar -esa -ea -Djava.awt.headless=true -cp /Users/dsimon/.mx/cache/HAMCREST_42a25dc3219429f0e5d060061f71acb49bf010a0.jar:/Users/dsimon/.mx/cache/JUNIT_4e031bb61df09069aeb2bffb4019e7a5034a4ee0.jar:/Users/dsimon/Dropbox/mx/mxbuild/java/com.oracle.mxtool.junit/bin:/Library/Java/JavaVirtualMachines/labsjdk1.8.0_111-jvmci-0.23/jre/lib/jvmci-services.jar:/Library/Java/JavaVirtualMachines/labsjdk1.8.0_111-jvmci-0.23/jre/lib/jvmci/jvmci-api.jar:/Users/dsimon/graal/graal-core/mxbuild/graal/com.oracle.graal.test/bin:/Users/dsimon/graal/graal-core/mxbuild/graal/com.oracle.graal.api.test/bin:/Users/dsimon/graal/graal-core/mxbuild/graal/com.oracle.graal.graph.test/bin:/Users/dsimon/.mx/cache/JAVA_ALLOCATION_INSTRUMENTER_476d9a44cd19d6b55f81571077dfa972a4f8a083.jar:/Users/dsimon/graal/graal-core/mxbuild/graal/com.oracle.graal.compiler.test/bin:/Users/dsimon/graal/graal-core/mxbuild/graal/com.oracle.graal.replacements.test/bin -XX:-UseJVMCIClassLoader com.oracle.mxtool.junit.MxJUnitWrapper -JUnitEagerStackTrace 'com.oracle.graal.replacements.test.NewMultiArrayTest#test1'
Process 45997 launched: '/Library/Java/JavaVirtualMachines/labsjdk1.8.0_111-jvmci-0.23/bin/java' (x86_64)

Hope that helps.

-Doug

> 
> Thanks,
> 
> Andrew.
> 
> 
> 
> com.oracle.graal.replacements.test.NewMultiArrayTest started
>  test1: #
> # A fatal error has been detected by the Java Runtime Environment:
> #
> #  SIGILL (0x4) at pc=0x0000007f79983dd8, pid=46366, tid=46367
> #
> # JRE version: OpenJDK Runtime Environment (9.0) (build 9-internal+0-2016-11-28-162713.aph.hs)
> # Java VM: OpenJDK 64-Bit Server VM (9-internal+0-2016-11-28-162713.aph.hs, mixed mode, tiered, jvmci, compressed oops, g1 gc, linux-aarch64)
> # Problematic frame:
> # C  0x0000007f79983dd8
> #
> # No core dump will be written. Core dumps have been disabled. To enable core dumping, try "ulimit -c unlimited" before starting Java again
> #
> # An error report file with more information is saved as:
> # /nfs/zebedee/home/graal/clean/graal-core/hs_err_pid46366.log
> #
> # If you would like to submit a bug report, please visit:
> #   http://bugreport.java.com/bugreport/crash.jsp
> #
> [exit code: -6]
>  File "/nfs/zebedee/home/graal/clean/mx/mx.py", line 14608, in <module>
>    main()
>  File "/nfs/zebedee/home/graal/clean/mx/mx.py", line 14592, in main
>    retcode = c(command_args)
>  File "/nfs/zebedee/home/graal/clean/mx/mx_gate.py", line 347, in gate
>    runner(args, tasks)
>  File "/nfs/zebedee/home/graal/clean/graal-core/mx.graal-core/mx_graal_core.py", line 474, in _graal_gate_runner
>    compiler_gate_runner(['graal-core', 'truffle'], graal_unit_test_runs, graal_bootstrap_tests, tasks, args.extra_vm_argument)
>  File "/nfs/zebedee/home/graal/clean/graal-core/mx.graal-core/mx_graal_core.py", line 377, in compiler_gate_runner
>    r.run(suites, tasks, ['-XX:-UseJVMCICompiler'] + _remove_empty_entries(extraVMarguments))
>  File "/nfs/zebedee/home/graal/clean/graal-core/mx.graal-core/mx_graal_core.py", line 290, in run
>    if t: unittest(['--suite', suite, '--fail-fast'] + extra_args + self.args + _remove_empty_entries(extraVMarguments))
>  File "/nfs/zebedee/home/graal/clean/mx/mx_unittest.py", line 369, in unittest
>    _unittest(args, ['@Test', '@Parameters'], **parsed_args.__dict__)
>  File "/nfs/zebedee/home/graal/clean/mx/mx_unittest.py", line 257, in _unittest
>    _run_tests(args, harness, vmLauncher, annotations, testfile, blacklist, whitelist, regex, mx.suite(suite) if suite else None)
>  File "/nfs/zebedee/home/graal/clean/mx/mx_unittest.py", line 166, in _run_tests
>    harness(depsContainingTests, vmLauncher, vmArgs)
>  File "/nfs/zebedee/home/graal/clean/mx/mx_unittest.py", line 247, in harness
>    vmLauncher.launcher(*config)
>  File "/nfs/zebedee/home/graal/clean/graal-core/mx.graal-core/mx_graal_core.py", line 495, in _unittest_vm_launcher
>    run_vm(vmArgs + [mainClass] + mainClassArgs)
>  File "/nfs/zebedee/home/graal/clean/graal-core/mx.graal-core/mx_graal_core.py", line 775, in run_vm
>    return run_java(args, nonZeroIsFatal=nonZeroIsFatal, out=out, err=err, cwd=cwd, timeout=timeout)
>  File "/nfs/zebedee/home/graal/clean/graal-core/mx.graal-core/mx_graal_core.py", line 750, in run_java
>    return mx.run(cmd, nonZeroIsFatal=nonZeroIsFatal, out=out, err=err, cwd=cwd, env=env)
>  File "/nfs/zebedee/home/graal/clean/mx/mx.py", line 8772, in run
>    abort(retcode)
>  File "/nfs/zebedee/home/graal/clean/mx/mx.py", line 9393, in abort
>    traceback.print_stack()
> gate: 29 Nov 2016 14:19:40: END:   UnitTests: hosted-product graal-core [0:02:46.926390] [disk (free/total): 24.5GB/618.0GB]
> Traceback (most recent call last):
>  File "/nfs/zebedee/home/graal/clean/mx/mx_gate.py", line 347, in gate
>    runner(args, tasks)
>  File "/nfs/zebedee/home/graal/clean/graal-core/mx.graal-core/mx_graal_core.py", line 474, in _graal_gate_runner
>    compiler_gate_runner(['graal-core', 'truffle'], graal_unit_test_runs, graal_bootstrap_tests, tasks, args.extra_vm_argument)
>  File "/nfs/zebedee/home/graal/clean/graal-core/mx.graal-core/mx_graal_core.py", line 377, in compiler_gate_runner
>    r.run(suites, tasks, ['-XX:-UseJVMCICompiler'] + _remove_empty_entries(extraVMarguments))
>  File "/nfs/zebedee/home/graal/clean/graal-core/mx.graal-core/mx_graal_core.py", line 290, in run
>    if t: unittest(['--suite', suite, '--fail-fast'] + extra_args + self.args + _remove_empty_entries(extraVMarguments))
>  File "/nfs/zebedee/home/graal/clean/mx/mx_unittest.py", line 369, in unittest
>    _unittest(args, ['@Test', '@Parameters'], **parsed_args.__dict__)
>  File "/nfs/zebedee/home/graal/clean/mx/mx_unittest.py", line 257, in _unittest
>    _run_tests(args, harness, vmLauncher, annotations, testfile, blacklist, whitelist, regex, mx.suite(suite) if suite else None)
>  File "/nfs/zebedee/home/graal/clean/mx/mx_unittest.py", line 166, in _run_tests
>    harness(depsContainingTests, vmLauncher, vmArgs)
>  File "/nfs/zebedee/home/graal/clean/mx/mx_unittest.py", line 247, in harness
>    vmLauncher.launcher(*config)
>  File "/nfs/zebedee/home/graal/clean/graal-core/mx.graal-core/mx_graal_core.py", line 495, in _unittest_vm_launcher
>    run_vm(vmArgs + [mainClass] + mainClassArgs)
>  File "/nfs/zebedee/home/graal/clean/graal-core/mx.graal-core/mx_graal_core.py", line 775, in run_vm
>    return run_java(args, nonZeroIsFatal=nonZeroIsFatal, out=out, err=err, cwd=cwd, timeout=timeout)
>  File "/nfs/zebedee/home/graal/clean/graal-core/mx.graal-core/mx_graal_core.py", line 750, in run_java
>    return mx.run(cmd, nonZeroIsFatal=nonZeroIsFatal, out=out, err=err, cwd=cwd, env=env)
>  File "/nfs/zebedee/home/graal/clean/mx/mx.py", line 8772, in run
>    abort(retcode)
>  File "/nfs/zebedee/home/graal/clean/mx/mx.py", line 9409, in abort
>    raise SystemExit(codeOrMessage)
> SystemExit: -6
> <hs_err_pid46366.log>


From aph at redhat.com  Tue Nov 29 16:05:23 2016
From: aph at redhat.com (Andrew Haley)
Date: Tue, 29 Nov 2016 16:05:23 +0000
Subject: How to run a specific Graal test?
In-Reply-To: <15AD278C-E1E3-43CC-9DBB-D769DE77B32C@oracle.com>
References: <6d01f1c5-0b55-e39f-55e9-8296ee948674@redhat.com>
	<CEF91CCE-25E1-4ED0-B40E-5DD3C6A618F0@oracle.com>
	<70445639-61ea-49f3-ada0-17c04eb05cab@redhat.com>
	<15AD278C-E1E3-43CC-9DBB-D769DE77B32C@oracle.com>
Message-ID: <78342b2d-7fc8-d911-80ed-43ca414cf090@redhat.com>

On 29/11/16 15:46, Doug Simon wrote:
> I assume that you?re talking about a native debugger, not a Java debugger. In that case, it can be useful to run *only* the crashing test. Assuming the test that fails is NewMultiArrayTest.test1, you can run:
> 
> mx -v unittest NewMultiArrayTest#test1
> ... etc

Sweeeeet!  That works perfectly.

Thanks,

Andrew.



From aph at redhat.com  Wed Nov 30 13:04:48 2016
From: aph at redhat.com (Andrew Haley)
Date: Wed, 30 Nov 2016 13:04:48 +0000
Subject: Graal and JDK 8
Message-ID: <a6efd2b5-ee0c-4e12-f609-25cbc3f01927@redhat.com>

Am I allowed to use lambdas?  Or does this all have to run on 7?

Thanks,

Andrew.

From doug.simon at oracle.com  Wed Nov 30 13:52:35 2016
From: doug.simon at oracle.com (Doug Simon)
Date: Wed, 30 Nov 2016 14:52:35 +0100
Subject: Graal and JDK 8
In-Reply-To: <a6efd2b5-ee0c-4e12-f609-25cbc3f01927@redhat.com>
References: <a6efd2b5-ee0c-4e12-f609-25cbc3f01927@redhat.com>
Message-ID: <F8E29CDA-3000-42E5-94EB-CA232F42B34B@oracle.com>

Lambdas should be avoided in all but test code. The cost of bytecode generation required for bootstrapping lambdas is something we?d like to avoid. Unfortunately, we came to this realization after having already put lambdas in some non-test code. It?s a background task to revisit these parts of the code and remove the use of lambdas. When/if we get there, we?ll use Jackpot[1] to enforce the absence of lambdas in non-test code.

-Doug

[1] http://wiki.netbeans.org/Jackpot

> On 30 Nov 2016, at 14:04, Andrew Haley <aph at redhat.com> wrote:
> 
> Am I allowed to use lambdas?  Or does this all have to run on 7?
> 
> Thanks,
> 
> Andrew.


From aph at redhat.com  Wed Nov 30 15:20:13 2016
From: aph at redhat.com (Andrew Haley)
Date: Wed, 30 Nov 2016 15:20:13 +0000
Subject: Graal and JDK 8
In-Reply-To: <F8E29CDA-3000-42E5-94EB-CA232F42B34B@oracle.com>
References: <a6efd2b5-ee0c-4e12-f609-25cbc3f01927@redhat.com>
	<F8E29CDA-3000-42E5-94EB-CA232F42B34B@oracle.com>
Message-ID: <47950678-5150-abf4-c32c-a90bbc560983@redhat.com>

OK, thanks.

Andrew.

From aph at redhat.com  Wed Nov 30 19:03:55 2016
From: aph at redhat.com (Andrew Haley)
Date: Wed, 30 Nov 2016 19:03:55 +0000
Subject: BitScanForwardNode: LongBits test failure
Message-ID: <3c15d3d3-c033-c0d7-8a6b-ad6a920c2300@redhat.com>

I have test failure which baffles me.  BitScanForwardNode has a comment at
the top:

/**
 * Determines the index of the least significant "1" bit. Note that the result is undefined if the
 * input is zero.
 */

But BitScanForwardNode.tryFold sometimes is called with the constant zero.

What seems to happen is that tryFold() fails, so foldStamp() is
called, again with the constant zero.  Some rather tortured logic is
executed and the result is that the stamp becomes -1 ... -1, so the
constant -1 is substituted; this is wrong for
Long.numberOfTrailingZeros(0);

A fix is obvious: correct tryFold() so that it works for 0.  But I
don't understand how Long.numberOfTrailingZeros(0) works on other
processors; yet presumably this test (LongBits) does pass there.

Andrew.

From tom.rodriguez at oracle.com  Wed Nov 30 19:14:06 2016
From: tom.rodriguez at oracle.com (Tom Rodriguez)
Date: Wed, 30 Nov 2016 11:14:06 -0800
Subject: BitScanForwardNode: LongBits test failure
In-Reply-To: <3c15d3d3-c033-c0d7-8a6b-ad6a920c2300@redhat.com>
References: <3c15d3d3-c033-c0d7-8a6b-ad6a920c2300@redhat.com>
Message-ID: <B0A0C6AE-B921-4E21-8436-471AF61F0B35@oracle.com>


> On Nov 30, 2016, at 11:03 AM, Andrew Haley <aph at redhat.com> wrote:
> 
> I have test failure which baffles me.  BitScanForwardNode has a comment at
> the top:
> 
> /**
> * Determines the index of the least significant "1" bit. Note that the result is undefined if the
> * input is zero.
> */
> 
> But BitScanForwardNode.tryFold sometimes is called with the constant zero.
> 
> What seems to happen is that tryFold() fails, so foldStamp() is
> called, again with the constant zero.  Some rather tortured logic is
> executed and the result is that the stamp becomes -1 ... -1, so the
> constant -1 is substituted; this is wrong for
> Long.numberOfTrailingZeros(0);
> 
> A fix is obvious: correct tryFold() so that it works for 0.  But I
> don't understand how Long.numberOfTrailingZeros(0) works on other
> processors; yet presumably this test (LongBits) does pass there.

AArch64 seems to have it?s own version of numberOfTrailingZeros instead of using the default one.  The other uses of BitScanForwardNode are explicitly protected from 0.  That being said foldStamp should probably handle the case of 0 properly.  BitScanForwardNode is sort of x86 dependent which is why it has the weird specification.

tom


> 
> Andrew.


From aph at redhat.com  Wed Nov 30 19:52:41 2016
From: aph at redhat.com (Andrew Haley)
Date: Wed, 30 Nov 2016 19:52:41 +0000
Subject: BitScanForwardNode: LongBits test failure
In-Reply-To: <B0A0C6AE-B921-4E21-8436-471AF61F0B35@oracle.com>
References: <3c15d3d3-c033-c0d7-8a6b-ad6a920c2300@redhat.com>
	<B0A0C6AE-B921-4E21-8436-471AF61F0B35@oracle.com>
Message-ID: <e760c652-0c68-9b34-1c49-e5652c55149d@redhat.com>

On 30/11/16 19:14, Tom Rodriguez wrote:
> AArch64 seems to have it?s own version of numberOfTrailingZeros instead of using the default one.  The other uses of BitScanForwardNode are explicitly protected from 0.  That being said foldStamp should probably handle the case of 0 properly.  BitScanForwardNode is sort of x86 dependent which is why it has the weird specification.

Okay, thanks.  So, I could look at getting rid of AArch64's
numberOfTrailingZeros, but I don't think there is anything wrong
there.

I can see that AMD64GraphBuilderPlugins has its own version of
numberOfTrailingZeros too; unless you are talking about something
else.  I can't see that AArch64 does anything significantly different
to AMD64.  If you can see that it does, I'd be grateful if you could
point me at the code.

Thanks,

Andrew.

From tom.rodriguez at oracle.com  Wed Nov 30 20:19:49 2016
From: tom.rodriguez at oracle.com (Tom Rodriguez)
Date: Wed, 30 Nov 2016 12:19:49 -0800
Subject: BitScanForwardNode: LongBits test failure
In-Reply-To: <e760c652-0c68-9b34-1c49-e5652c55149d@redhat.com>
References: <3c15d3d3-c033-c0d7-8a6b-ad6a920c2300@redhat.com>
	<B0A0C6AE-B921-4E21-8436-471AF61F0B35@oracle.com>
	<e760c652-0c68-9b34-1c49-e5652c55149d@redhat.com>
Message-ID: <E451803F-38BC-47B0-93CB-5D17DF6777B3@oracle.com>


> On Nov 30, 2016, at 11:52 AM, Andrew Haley <aph at redhat.com> wrote:
> 
> On 30/11/16 19:14, Tom Rodriguez wrote:
>> AArch64 seems to have it?s own version of numberOfTrailingZeros instead of using the default one.  The other uses of BitScanForwardNode are explicitly protected from 0.  That being said foldStamp should probably handle the case of 0 properly.  BitScanForwardNode is sort of x86 dependent which is why it has the weird specification.
> 
> Okay, thanks.  So, I could look at getting rid of AArch64's
> numberOfTrailingZeros, but I don't think there is anything wrong
> there.
> 
> I can see that AMD64GraphBuilderPlugins has its own version of
> numberOfTrailingZeros too; unless you are talking about something
> else.  I can't see that AArch64 does anything significantly different
> to AMD64.  If you can see that it does, I'd be grateful if you could
> point me at the code.

The only other use of BitScanForwardNode is in the Long substitution and that?s explicitly protected from 0.  The other AMD64 plugin uses a platform dependent node AMD64CountTrailingZerosNode which presumably doesn?t have the same problem with 0 as the BitScanForwardNode.  So I think AArch64 needs it own platform dependent node for this.  It would probably make sense to make BitScanForwardNode have straightforward semantics and just require the back to deal with the undefined nature 0 for the actual instruction.

tom

> 
> Thanks,
> 
> Andrew.