From dms at samersoff.net  Thu Feb  1 16:01:30 2018
From: dms at samersoff.net (Dmitry Samersoff)
Date: Thu, 1 Feb 2018 19:01:30 +0300
Subject: StringSubstitutions are disabled in 1.9
Message-ID: <dd697c41-20f1-e62e-eb8f-d001fbecab01@samersoff.net>

Hi Everybody,

1.
I found following remark in StringSubstitutionTest.java

if (!Java8OrEarlier) {
   // StringSubstitutions are disabled in 1.9
    return;
}


What is the reason for disabling StringSubstitutions in jdk9 and should
we enable it for jdk11?

2.
StringSubstitutionTest.testSubstitution method is almost identical to
one in its baseclass, MethodSubstitutionTest.testSubstitution.

What is the reason of that slight diverge?

Should we create more specific StringSubstitutionTest class?

Regards,
-Dmitry


From doug.simon at oracle.com  Thu Feb  1 16:17:43 2018
From: doug.simon at oracle.com (Doug Simon)
Date: Thu, 1 Feb 2018 17:17:43 +0100
Subject: StringSubstitutions are disabled in 1.9
In-Reply-To: <dd697c41-20f1-e62e-eb8f-d001fbecab01@samersoff.net>
References: <dd697c41-20f1-e62e-eb8f-d001fbecab01@samersoff.net>
Message-ID: <CDA5118B-3FFF-45BA-BAAD-FCBD674F5471@oracle.com>



> On 1 Feb 2018, at 17:01, Dmitry Samersoff <dms at samersoff.net> wrote:
> 
> Hi Everybody,
> 
> 1.
> I found following remark in StringSubstitutionTest.java
> 
> if (!Java8OrEarlier) {
>   // StringSubstitutions are disabled in 1.9
>    return;
> }
> 
> 
> What is the reason for disabling StringSubstitutions in jdk9 and should
> we enable it for jdk11?

The reason is was disabled is because String internals changed in JDK 9 (http://openjdk.java.net/jeps/254).
That should have been in the comment about them being disabled.
New substitutions would be needed to support the compact strings. And they would have to be enabled in org.graalvm.compiler.replacements.StandardGraphBuilderPlugins.registerStringPlugins.

> 
> 2.
> StringSubstitutionTest.testSubstitution method is almost identical to
> one in its baseclass, MethodSubstitutionTest.testSubstitution.
> 
> What is the reason of that slight diverge?

I'm not sure why MethodSubstitutionTest.testSubstitution was not modified to accommodate StringSubstitutionTest's requirements. Cleaning that up would be preferable.

> 
> Should we create more specific StringSubstitutionTest class?

Why? If it's to test compact string substitutions (when they are added), then I would just modify StringSubstitutionTest.

-Doug

From teshull at gmail.com  Tue Feb  6 16:14:51 2018
From: teshull at gmail.com (Tom Shull)
Date: Tue, 6 Feb 2018 10:14:51 -0600
Subject: Substrate VM Questions
Message-ID: <0b430006-00d0-9255-c9ea-10dba15b9972@gmail.com>

Hi,

     I am interested in using Substrate VM for a project in which I plan 
to make some changes to the internal JVM object layout. I would like to 
use a metacircular VM, as I feel they are much more amenable to these 
types of changes as compared to HotSpot.  Looking at its GitHub page, 
there currently seems to be very little  documentation relating to 
Substrate VM. I have appreciated the many publications/talks covering 
both Truffle and Graal, but there does not yet seem to be any for 
Substrate VM. Do you plan to include more documentation and/or publish 
papers in the near future?

Also, from what I can tell, it appears that unless Substrate VM is used 
with Truffle, it does not JIT-compile code. Is this correct? Do you plan 
to change this in the near future, by either adding JIT support to 
Substrate VM or including a Java/JVM implementation in Truffle? Would I 
be better off using Maxine VM instead? Ideally I would like JIT 
capabilities so that I can also add some profile-guided speculative 
optimizations.

Thanks
-Tom


From christian.wimmer at oracle.com  Tue Feb  6 22:07:52 2018
From: christian.wimmer at oracle.com (Christian Wimmer)
Date: Tue, 6 Feb 2018 14:07:52 -0800
Subject: Substrate VM Questions
In-Reply-To: <0b430006-00d0-9255-c9ea-10dba15b9972@gmail.com>
References: <0b430006-00d0-9255-c9ea-10dba15b9972@gmail.com>
Message-ID: <719c2ce8-169e-9b19-2f9c-64d329f82f69@oracle.com>

Hi Tom,

On 02/06/2018 08:14 AM, Tom Shull wrote:
> Hi,
> 
>  ??? I am interested in using Substrate VM for a project in which I plan 
> to make some changes to the internal JVM object layout. I would like to 
> use a metacircular VM, as I feel they are much more amenable to these 
> types of changes as compared to HotSpot.? Looking at its GitHub page, 
> there currently seems to be very little? documentation relating to 
> Substrate VM. I have appreciated the many publications/talks covering 
> both Truffle and Graal, but there does not yet seem to be any for 
> Substrate VM. Do you plan to include more documentation and/or publish 
> papers in the near future?

We plan to add more documentation, but it will take us some time to ramp 
it up. In the meantime, feel free to ask questions here on the mailing list.

> Also, from what I can tell, it appears that unless Substrate VM is used 
> with Truffle, it does not JIT-compile code. Is this correct? Do you plan 
> to change this in the near future, by either adding JIT support to 
> Substrate VM or including a Java/JVM implementation in Truffle? Would I 
> be better off using Maxine VM instead? Ideally I would like JIT 
> capabilities so that I can also add some profile-guided speculative 
> optimizations.

You are correct that Substrate VM does not JIT compile Java code. This 
is part of the overall design and the main differentiator of Substrate 
VM compared to Maxine VM or HotSpot VM. So dynamic class loading and JIT 
compilation (which would only be useful with dynamic class loading) are 
not coming to Substrate VM.

There is an academic prototype of a Truffle based Java implementation. 
This is independent of Substrate VM, i.e., you can run Truffle/Java on 
the HotSpot VM of course too. I do not think there are plans to make 
Truffle/Java public anytime soon, and it would probably be too limited 
right now anyway to base research on it.

Maxine VM is a good choice if you want to experiment with a full Java 
VM. It has JIT compilation, and already some profile-guided speculative 
optimizations.

So the decision Substrate VM vs. Maxine VM depends on the direction of 
the research you want to do. Both have their advantages and disadvantages:
* The closed-world assumption and static analysis of Substrate VM allows 
you to do global optimizations and global transformations. You do not 
need speculation because you have complete static knowledge.
* The open-world assumption of Maxine VM allows you to implement 
speculative feedback-directed optimizations. You need speculation 
because you do not have any static knowledge.

-Christian

From Christos.Kotselidis at manchester.ac.uk  Tue Feb  6 22:19:22 2018
From: Christos.Kotselidis at manchester.ac.uk (Christos-efthymios Kotselidis)
Date: Tue, 6 Feb 2018 22:19:22 +0000
Subject: Substrate VM Questions
In-Reply-To: <719c2ce8-169e-9b19-2f9c-64d329f82f69@oracle.com>
References: <0b430006-00d0-9255-c9ea-10dba15b9972@gmail.com>
 <719c2ce8-169e-9b19-2f9c-64d329f82f69@oracle.com>
Message-ID: <648812ED-0697-40FF-A285-1D74564FAAB8@manchester.ac.uk>

Hi Tom,

Just a bit of extra information regarding Maxine VM.
If you are interested in exploring Truffle with a research VM, there are plans to implement JVMCI and provide Graal/Truffle interoperability to Maxine by EOY.
Also regarding object-layout optimisations, the complementary MaxSim platform has been developed to also accommodate such experiments.

Regards

Christos

> On 6 Feb 2018, at 22:07, Christian Wimmer <christian.wimmer at oracle.com> wrote:
> 
> Hi Tom,
> 
> On 02/06/2018 08:14 AM, Tom Shull wrote:
>> Hi,
>>     I am interested in using Substrate VM for a project in which I plan to make some changes to the internal JVM object layout. I would like to use a metacircular VM, as I feel they are much more amenable to these types of changes as compared to HotSpot.  Looking at its GitHub page, there currently seems to be very little  documentation relating to Substrate VM. I have appreciated the many publications/talks covering both Truffle and Graal, but there does not yet seem to be any for Substrate VM. Do you plan to include more documentation and/or publish papers in the near future?
> 
> We plan to add more documentation, but it will take us some time to ramp it up. In the meantime, feel free to ask questions here on the mailing list.
> 
>> Also, from what I can tell, it appears that unless Substrate VM is used with Truffle, it does not JIT-compile code. Is this correct? Do you plan to change this in the near future, by either adding JIT support to Substrate VM or including a Java/JVM implementation in Truffle? Would I be better off using Maxine VM instead? Ideally I would like JIT capabilities so that I can also add some profile-guided speculative optimizations.
> 
> You are correct that Substrate VM does not JIT compile Java code. This is part of the overall design and the main differentiator of Substrate VM compared to Maxine VM or HotSpot VM. So dynamic class loading and JIT compilation (which would only be useful with dynamic class loading) are not coming to Substrate VM.
> 
> There is an academic prototype of a Truffle based Java implementation. This is independent of Substrate VM, i.e., you can run Truffle/Java on the HotSpot VM of course too. I do not think there are plans to make Truffle/Java public anytime soon, and it would probably be too limited right now anyway to base research on it.
> 
> Maxine VM is a good choice if you want to experiment with a full Java VM. It has JIT compilation, and already some profile-guided speculative optimizations.
> 
> So the decision Substrate VM vs. Maxine VM depends on the direction of the research you want to do. Both have their advantages and disadvantages:
> * The closed-world assumption and static analysis of Substrate VM allows you to do global optimizations and global transformations. You do not need speculation because you have complete static knowledge.
> * The open-world assumption of Maxine VM allows you to implement speculative feedback-directed optimizations. You need speculation because you do not have any static knowledge.
> 
> -Christian


From teshull at gmail.com  Wed Feb  7 06:22:58 2018
From: teshull at gmail.com (Tom Shull)
Date: Wed, 7 Feb 2018 00:22:58 -0600
Subject: Substrate VM Questions
Message-ID: <3f30da06-06a2-dedc-4386-4f4a05c27d8a@gmail.com>

Thank you for the responses. Given this information I think I'll stick 
with Maxine VM for the time being. However, I hope I can find a reason 
to use Truffle in the near future.

Thanks,
Tom

 >Hi Tom,
 >
 >Just a bit of extra information regarding Maxine VM.
 >If you are interested in exploring Truffle with a research VM, there 
are plans to implement JVMCI and provide Graal/Truffle interoperability 
to Maxine by EOY.
 >Also regarding object-layout optimisations, the complementary MaxSim 
platform has been developed to also accommodate such experiments.
 >
 >Regards
 >
 >Christos
 >
 >> On 6 Feb 2018, at 22:07, Christian Wimmer <christian.wimmer at 
oracle.com> wrote:
 >>
 >> Hi Tom,
 >>
 >> On 02/06/2018 08:14 AM, Tom Shull wrote:
 >>> Hi,
 >>>     I am interested in using Substrate VM for a project in which I 
plan to make some changes to the internal JVM object layout. I would 
like to use a metacircular VM, as I feel they are much more amenable to 
these types of changes as compared to HotSpot.  Looking at its GitHub 
page, there currently seems to be very little  documentation relating to 
Substrate VM. I have appreciated the many publications/talks covering 
both Truffle and Graal, but there does not yet seem to be any for 
Substrate VM. Do you plan to include more documentation and/or publish 
papers in the near future?
 >>
 >> We plan to add more documentation, but it will take us some time to 
ramp it up. In the meantime, feel free to ask questions here on the 
mailing list.
 >>
 >>> Also, from what I can tell, it appears that unless Substrate VM is 
used with Truffle, it does not JIT-compile code. Is this correct? Do you 
plan to change this in the near future, by either adding JIT support to 
Substrate VM or including a Java/JVM implementation in Truffle? Would I 
be better off using Maxine VM instead? Ideally I would like JIT 
capabilities so that I can also add some profile-guided speculative 
optimizations.
 >>
 >> You are correct that Substrate VM does not JIT compile Java code. 
This is part of the overall design and the main differentiator of 
Substrate VM compared to Maxine VM or HotSpot VM. So dynamic class 
loading and JIT compilation (which would only be useful with dynamic 
class loading) are not coming to Substrate VM.
 >>
 >> There is an academic prototype of a Truffle based Java 
implementation. This is independent of Substrate VM, i.e., you can run 
Truffle/Java on the HotSpot VM of course too. I do not think there are 
plans to make Truffle/Java public anytime soon, and it would probably be 
too limited right now anyway to base research on it.
 >>
 >> Maxine VM is a good choice if you want to experiment with a full 
Java VM. It has JIT compilation, and already some profile-guided 
speculative optimizations.
 >>
 >> So the decision Substrate VM vs. Maxine VM depends on the direction 
of the research you want to do. Both have their advantages and 
disadvantages:
 >> * The closed-world assumption and static analysis of Substrate VM 
allows you to do global optimizations and global transformations. You do 
not need speculation because you have complete static knowledge.
 >> * The open-world assumption of Maxine VM allows you to implement 
speculative feedback-directed optimizations. You need speculation 
because you do not have any static knowledge.
 >>
 >> -Christian


From stewartd.qdt at qualcommdatacenter.com  Fri Feb  9 21:59:24 2018
From: stewartd.qdt at qualcommdatacenter.com (stewartd.qdt)
Date: Fri, 9 Feb 2018 21:59:24 +0000
Subject: SPECjvm2008 benchmark numbers for AArch64 
Message-ID: <e071fc64ba9f4c69b64b59ed6d0406d1@NASANEXM01E.na.qualcomm.com>

I had mentioned to Andrew Haley I had been doing some benchmark tests of SPECjvm2008 under an AArch64 system. He indicated that sharing these results may be beneficial to the larger community. So below please find a table of ratios of SPECjvm2008 sub-benchmarks scores run under Graal to the same sub-benchmark scores run under Hotspot. For the numbers below I used the Graal from Github, with the tip commit id of 666d33ad82cdbf26bd30f99ea09b058177d56c4d. I also have run the numbers using the Graal that comes with OpenJDK (as of commit id 48816:120d6893f32f). There are not many differences between these two versions and there were not any substantial changes between the two sets of numbers.

For the table below, numbers greater than 1 indicate the benchmark performed better using Graal, and numbers below 1 indicate that Hotspot performed better.
I have not done the same tests under an x86 system.

| Benchmark            | Graal/Hotspot |
|----------------------|---------------|
| compress             | 1.0330840508  |
| crypto.aes           | 1.3930506076  |
| crypto.rsa           | 0.9685673726  |
| crypto.signverify    | 1.0279897496  |
| derby                | 0.8528705952  |
| mpegaudio            | 0.8677143536  |
| scimark.fft.large    | 0.9931398804  |
| scimark.lu.large     | 0.9947762493  |
| scimark.sor.large    | 0.7137096774  |
| scimark.sparse.large | 1.0176137761  |
| scimark.fft.small    | 0.9699580705  |
| scimark.lu.small     | 0.7400088047  |
| scimark.sor.small    | 0.6226693059  |
| scimark.sparse.small | 0.7469722941  |
| scimark.monte_carlo  | 0.1778036443  |
| serial               | 0.8416132562  |
| sunflow              | 1.0235484652  |
| xml.transform        | 0.7971206314  |
| xml.validation       | 0.9315428534  |


Regards,
Daniel Stewart

From aph at redhat.com  Sat Feb 10 17:01:03 2018
From: aph at redhat.com (Andrew Haley)
Date: Sat, 10 Feb 2018 17:01:03 +0000
Subject: SPECjvm2008 benchmark numbers for AArch64
In-Reply-To: <e071fc64ba9f4c69b64b59ed6d0406d1@NASANEXM01E.na.qualcomm.com>
References: <e071fc64ba9f4c69b64b59ed6d0406d1@NASANEXM01E.na.qualcomm.com>
Message-ID: <f696adaf-c29c-d1c9-9928-fc81d251317d@redhat.com>

On 09/02/18 21:59, stewartd.qdt wrote:

> For the table below, numbers greater than 1 indicate the benchmark
> performed better using Graal, and numbers below 1 indicate that
> Hotspot performed better.

Fascinating.  Thanks for that: it's more of a spread that I expected,
for sure.  The scimark.small benchmarks always were a bit weird and
show large shifts in performance.

> I have not done the same tests under an x86 system.

That'll be interesting too.  I'm not wondering how much of this
is due to the Graal high-level code analysis.

-- 
Andrew Haley
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671

From aph at redhat.com  Mon Feb 12 10:48:42 2018
From: aph at redhat.com (Andrew Haley)
Date: Mon, 12 Feb 2018 10:48:42 +0000
Subject: SPECjvm2008 benchmark numbers for AArch64
In-Reply-To: <f696adaf-c29c-d1c9-9928-fc81d251317d@redhat.com>
References: <e071fc64ba9f4c69b64b59ed6d0406d1@NASANEXM01E.na.qualcomm.com>
 <f696adaf-c29c-d1c9-9928-fc81d251317d@redhat.com>
Message-ID: <767a0c0e-cd31-fa50-23d6-c2b287d89e20@redhat.com>

On 10/02/18 17:01, Andrew Haley wrote:
> That'll be interesting too.  I'm not wondering how much of this
> is due to the Graal high-level code analysis.

Sorry, that typo made no sense!  I'm *now* wondering how much of this is
due to the Graal high-level code analysis.  I'm particularly baffled
by the difference in the speed of crypto.rsa and crypto.aes, given
that they're hand-coded intrinsics, so the compiler should make little
difference.

-- 
Andrew Haley
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671

From foivos.zakkak at manchester.ac.uk  Mon Feb 12 15:20:20 2018
From: foivos.zakkak at manchester.ac.uk (Foivos Zakkak)
Date: Mon, 12 Feb 2018 17:20:20 +0200
Subject: Building Graal with JVMCI JDK8 on Aarch64
Message-ID: <87po5a6xqj.fsf@manchester.ac.uk>

Hello all,

We are trying to build Graal on top of JVMCI JDK8 on Aarch64, but we
fail to get JVMCI JDK8 to build.

We use:
1. the latest mx (11c0b3dab35110bcef853e30ca9ee18615451fe0) from github.
2. Oracle's jdk8u151 for aarch64 jdk-8u151-linux-arm64-vfp-hflt.tar.gz
3. gcc (Ubuntu/Linaro 5.4.0-6ubuntu1~16.04.6) 5.4.0 20160609

When running:
hg clone http://hg.openjdk.java.net/graal/graal-jvmci-8
cd graal-jvmci-8
mx --java-home /path/to/jdk8 build

We get:

WARNING: No platform-specific definition is available for distribution JVM_PRODUCT_SERVER for your architecture (aarch64)

and later the error:

Generating precompiled header precompiled.hpp.gch
g++: error: unrecognized command line option '-m64'

Does JVMCI JDK8 support Aarch64? Are we doing something wrong?

Kind regards
--
Foivos Zakkak                            Research Associate
School of Computer Science     The University of Manchester

From petr.tuma at d3s.mff.cuni.cz  Mon Feb 12 15:30:13 2018
From: petr.tuma at d3s.mff.cuni.cz (=?UTF-8?Q?Petr_T=c5=afma?=)
Date: Mon, 12 Feb 2018 16:30:13 +0100
Subject: SPECjvm2008 benchmark numbers for AArch64
In-Reply-To: <f696adaf-c29c-d1c9-9928-fc81d251317d@redhat.com>
References: <e071fc64ba9f4c69b64b59ed6d0406d1@NASANEXM01E.na.qualcomm.com>
 <f696adaf-c29c-d1c9-9928-fc81d251317d@redhat.com>
Message-ID: <e2c1f75f-29c8-00bb-d94d-ff2032d1131c@d3s.mff.cuni.cz>

Hello,

>> I have not done the same tests under an x86 system.
> That'll be interesting too.

FWIIW, this is the kind of ratios we get on our (slightly modified) 
SPECjvm2008 runs, Github Graal vs OpenJDK vs Oracle JDK (baseline), all 
1.8.0, builds from around end of year:

---                 Github Graal    OpenJDK
compress             0.9511590     0.9883032
crypto.aes           1.3176631     0.9793367
crypto.rsa           4.1464020     0.9600780
crypto.signverify    1.3656185     1.1123288
derby                1.2369832     0.9961086
mpegaudio            1.2829063     1.0164686
scimark.fft.large    0.9846439     1.0307498
scimark.lu.large     1.9127555     1.0249192
scimark.monte_carlo  2.2114020     1.0217201
scimark.sor.large    1.2000043     1.0155251
scimark.sparse.large 1.6860926     1.0442726
serial               1.0336566     1.0413808
sunflow              0.8692992     0.9902927
xml.transform        0.8981167     1.1286714
xml.validation       0.9969519     0.9885531

I wouldn't take the crypto benchmarks at face value without checking 
that all platforms involved use the same security provider.

Petr

From aph at redhat.com  Mon Feb 12 15:31:04 2018
From: aph at redhat.com (Andrew Haley)
Date: Mon, 12 Feb 2018 15:31:04 +0000
Subject: Building Graal with JVMCI JDK8 on Aarch64
In-Reply-To: <87po5a6xqj.fsf@manchester.ac.uk>
References: <87po5a6xqj.fsf@manchester.ac.uk>
Message-ID: <ff0cec8a-a830-51ae-79bb-e9c561bcba7d@redhat.com>

On 12/02/18 15:20, Foivos Zakkak wrote:
> We use:
> 1. the latest mx (11c0b3dab35110bcef853e30ca9ee18615451fe0) from github.
> 2. Oracle's jdk8u151 for aarch64 jdk-8u151-linux-arm64-vfp-hflt.tar.gz
> 3. gcc (Ubuntu/Linaro 5.4.0-6ubuntu1~16.04.6) 5.4.0 20160609
> 
> When running:
> hg clone http://hg.openjdk.java.net/graal/graal-jvmci-8
> cd graal-jvmci-8
> mx --java-home /path/to/jdk8 build
> 
> We get:
> 
> WARNING: No platform-specific definition is available for distribution JVM_PRODUCT_SERVER for your architecture (aarch64)

That'll never work.  Download JDK9 and run that: if you're on Linux
your system's JDK 9 should be fine.

-- 
Andrew Haley
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671

From doug.simon at oracle.com  Mon Feb 12 16:06:24 2018
From: doug.simon at oracle.com (Doug Simon)
Date: Mon, 12 Feb 2018 17:06:24 +0100
Subject: SPECjvm2008 benchmark numbers for AArch64
In-Reply-To: <767a0c0e-cd31-fa50-23d6-c2b287d89e20@redhat.com>
References: <e071fc64ba9f4c69b64b59ed6d0406d1@NASANEXM01E.na.qualcomm.com>
 <f696adaf-c29c-d1c9-9928-fc81d251317d@redhat.com>
 <767a0c0e-cd31-fa50-23d6-c2b287d89e20@redhat.com>
Message-ID: <BB4F91DB-8CA5-4719-A968-76CCAA1A8D77@oracle.com>



> On 12 Feb 2018, at 11:48, Andrew Haley <aph at redhat.com> wrote:
> 
> On 10/02/18 17:01, Andrew Haley wrote:
>> That'll be interesting too.  I'm not wondering how much of this
>> is due to the Graal high-level code analysis.
> 
> Sorry, that typo made no sense!  I'm *now* wondering how much of this is
> due to the Graal high-level code analysis.  I'm particularly baffled
> by the difference in the speed of crypto.rsa and crypto.aes, given
> that they're hand-coded intrinsics, so the compiler should make little
> difference.

There are a few crypto intrinsics not yet implemented by Graal. In particular:

https://github.com/oracle/graal/blob/51ab3471e7e0c305e65ebf97df6a9ac6d27c5410/compiler/src/org.graalvm.compiler.hotspot.test/src/org/graalvm/compiler/hotspot/test/CheckGraalIntrinsics.java#L258-L261

This should be addressed by https://bugs.openjdk.java.net/browse/JDK-8193241.

-Doug

From aph at redhat.com  Mon Feb 12 16:17:02 2018
From: aph at redhat.com (Andrew Haley)
Date: Mon, 12 Feb 2018 16:17:02 +0000
Subject: SPECjvm2008 benchmark numbers for AArch64
In-Reply-To: <e2c1f75f-29c8-00bb-d94d-ff2032d1131c@d3s.mff.cuni.cz>
References: <e071fc64ba9f4c69b64b59ed6d0406d1@NASANEXM01E.na.qualcomm.com>
 <f696adaf-c29c-d1c9-9928-fc81d251317d@redhat.com>
 <e2c1f75f-29c8-00bb-d94d-ff2032d1131c@d3s.mff.cuni.cz>
Message-ID: <1d42f8ce-dfd7-401a-457a-7363d99a1140@redhat.com>

On 12/02/18 15:30, Petr T?ma wrote:
> FWIIW, this is the kind of ratios we get on our (slightly modified) 
> SPECjvm2008 runs, Github Graal vs OpenJDK vs Oracle JDK (baseline), all 
> 1.8.0, builds from around end of year:
> 
> ---                 Github Graal    OpenJDK
> compress             0.9511590     0.9883032
> crypto.aes           1.3176631     0.9793367
> crypto.rsa           4.1464020     0.9600780
> crypto.signverify    1.3656185     1.1123288
> derby                1.2369832     0.9961086
> mpegaudio            1.2829063     1.0164686
> scimark.fft.large    0.9846439     1.0307498
> scimark.lu.large     1.9127555     1.0249192
> scimark.monte_carlo  2.2114020     1.0217201
> scimark.sor.large    1.2000043     1.0155251
> scimark.sparse.large 1.6860926     1.0442726
> serial               1.0336566     1.0413808
> sunflow              0.8692992     0.9902927
> xml.transform        0.8981167     1.1286714
> xml.validation       0.9969519     0.9885531
> 
> I wouldn't take the crypto benchmarks at face value without checking 
> that all platforms involved use the same security provider.

I would surely hope that the exact same JVM should be used for Graal
and C2 compiler runs, otherwise the test is completely invalid.

-- 
Andrew Haley
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671

From vladimir.kozlov at oracle.com  Mon Feb 12 16:50:29 2018
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Mon, 12 Feb 2018 08:50:29 -0800
Subject: SPECjvm2008 benchmark numbers for AArch64
In-Reply-To: <BB4F91DB-8CA5-4719-A968-76CCAA1A8D77@oracle.com>
References: <e071fc64ba9f4c69b64b59ed6d0406d1@NASANEXM01E.na.qualcomm.com>
 <f696adaf-c29c-d1c9-9928-fc81d251317d@redhat.com>
 <767a0c0e-cd31-fa50-23d6-c2b287d89e20@redhat.com>
 <BB4F91DB-8CA5-4719-A968-76CCAA1A8D77@oracle.com>
Message-ID: <f72e27f4-0b1e-eb3c-dfb6-5574c9c4d90f@oracle.com>

Hi,

We, Oracle Java org, had similar performance investigation on linux-x86 
of Graal as JIT, which is new experimental feature in JDK 10.

Numbers are similar.

Several Graal's RFEs were filed to track these performance issues. As we 
understand, it is mostly due to some missing loop optimizations and 
missing intrinsics.

https://bugs.openjdk.java.net/browse/JDK-8190979
https://bugs.openjdk.java.net/browse/JDK-8191708
https://bugs.openjdk.java.net/browse/JDK-8194313

Benchmarks names are cryptic because of licensing issue :(

Regards,
Vladimir

On 2/12/18 8:06 AM, Doug Simon wrote:
> 
> 
>> On 12 Feb 2018, at 11:48, Andrew Haley <aph at redhat.com> wrote:
>>
>> On 10/02/18 17:01, Andrew Haley wrote:
>>> That'll be interesting too.  I'm not wondering how much of this
>>> is due to the Graal high-level code analysis.
>>
>> Sorry, that typo made no sense!  I'm *now* wondering how much of this is
>> due to the Graal high-level code analysis.  I'm particularly baffled
>> by the difference in the speed of crypto.rsa and crypto.aes, given
>> that they're hand-coded intrinsics, so the compiler should make little
>> difference.
> 
> There are a few crypto intrinsics not yet implemented by Graal. In particular:
> 
> https://github.com/oracle/graal/blob/51ab3471e7e0c305e65ebf97df6a9ac6d27c5410/compiler/src/org.graalvm.compiler.hotspot.test/src/org/graalvm/compiler/hotspot/test/CheckGraalIntrinsics.java#L258-L261
> 
> This should be addressed by https://bugs.openjdk.java.net/browse/JDK-8193241.
> 
> -Doug
> 

From petr.tuma at d3s.mff.cuni.cz  Mon Feb 12 20:06:23 2018
From: petr.tuma at d3s.mff.cuni.cz (=?UTF-8?Q?Petr_T=c5=afma?=)
Date: Mon, 12 Feb 2018 21:06:23 +0100
Subject: SPECjvm2008 benchmark numbers for AArch64
In-Reply-To: <1d42f8ce-dfd7-401a-457a-7363d99a1140@redhat.com>
References: <e071fc64ba9f4c69b64b59ed6d0406d1@NASANEXM01E.na.qualcomm.com>
 <f696adaf-c29c-d1c9-9928-fc81d251317d@redhat.com>
 <e2c1f75f-29c8-00bb-d94d-ff2032d1131c@d3s.mff.cuni.cz>
 <1d42f8ce-dfd7-401a-457a-7363d99a1140@redhat.com>
Message-ID: <ccd7d0b6-23b1-8675-9ea2-81e0b5679c38@d3s.mff.cuni.cz>

Hi Andrew,

> I would surely hope that the exact same JVM should be used for Graal
> and C2 compiler runs, otherwise the test is completely invalid.

The JVM was not exactly the same. For the numbers I posted, HotSpot was 
1.8.0-162 for x86_64 which Oracle makes available on their web. Graal 
was running on top of HotSpot 1.8.0-151 with JVMCI 0.38 again from 
Oracle web. The OpenJDK build was completely different of course.

I would not go as far as call the test "completely invalid". It was not 
done to compare Graal against C2 with strict isolation of as many other 
factors as possible. It was simply a small subset of measurements we use 
to track changes in Graal performance, which can give some idea of what 
ranges of values to expect on the benchmarks.

Hope this explains things.

Petr

From dmitry.samersoff at bell-sw.com  Tue Feb 13 07:38:52 2018
From: dmitry.samersoff at bell-sw.com (Dmitry Samersoff)
Date: Tue, 13 Feb 2018 10:38:52 +0300
Subject: Building Graal with JVMCI JDK8 on Aarch64
In-Reply-To: <87po5a6xqj.fsf@manchester.ac.uk>
References: <87po5a6xqj.fsf@manchester.ac.uk>
Message-ID: <3b6cb78d-b3d4-1aea-09a4-065a22b245b7@bell-sw.com>

I can confirm that recent openjdk (11) works fine with Graal on AARH64,
never tried jdk8 though.

-Dmitry

On 12.02.2018 18:20, Foivos Zakkak wrote:
> Hello all,
> 
> We are trying to build Graal on top of JVMCI JDK8 on Aarch64, but we
> fail to get JVMCI JDK8 to build.
> 
> We use:
> 1. the latest mx (11c0b3dab35110bcef853e30ca9ee18615451fe0) from github.
> 2. Oracle's jdk8u151 for aarch64 jdk-8u151-linux-arm64-vfp-hflt.tar.gz
> 3. gcc (Ubuntu/Linaro 5.4.0-6ubuntu1~16.04.6) 5.4.0 20160609
> 
> When running:
> hg clone http://hg.openjdk.java.net/graal/graal-jvmci-8
> cd graal-jvmci-8
> mx --java-home /path/to/jdk8 build
> 
> We get:
> 
> WARNING: No platform-specific definition is available for distribution JVM_PRODUCT_SERVER for your architecture (aarch64)
> 
> and later the error:
> 
> Generating precompiled header precompiled.hpp.gch
> g++: error: unrecognized command line option '-m64'
> 
> Does JVMCI JDK8 support Aarch64? Are we doing something wrong?
> 
> Kind regards
> --
> Foivos Zakkak                            Research Associate
> School of Computer Science     The University of Manchester
> 


-- 
Dmitry Samersoff
http://devnull.samersoff.net
* There will come soft rains ...


From aph at redhat.com  Tue Feb 13 09:18:28 2018
From: aph at redhat.com (Andrew Haley)
Date: Tue, 13 Feb 2018 09:18:28 +0000
Subject: SPECjvm2008 benchmark numbers for AArch64
In-Reply-To: <ccd7d0b6-23b1-8675-9ea2-81e0b5679c38@d3s.mff.cuni.cz>
References: <e071fc64ba9f4c69b64b59ed6d0406d1@NASANEXM01E.na.qualcomm.com>
 <f696adaf-c29c-d1c9-9928-fc81d251317d@redhat.com>
 <e2c1f75f-29c8-00bb-d94d-ff2032d1131c@d3s.mff.cuni.cz>
 <1d42f8ce-dfd7-401a-457a-7363d99a1140@redhat.com>
 <ccd7d0b6-23b1-8675-9ea2-81e0b5679c38@d3s.mff.cuni.cz>
Message-ID: <5de77dea-8c6e-dd75-3c20-5ef8cfd74bfa@redhat.com>

Hi,

On 12/02/18 20:06, Petr T?ma wrote:

>> I would surely hope that the exact same JVM should be used for Graal
>> and C2 compiler runs, otherwise the test is completely invalid.
> 
> The JVM was not exactly the same. For the numbers I posted, HotSpot was 
> 1.8.0-162 for x86_64 which Oracle makes available on their web. Graal 
> was running on top of HotSpot 1.8.0-151 with JVMCI 0.38 again from 
> Oracle web. The OpenJDK build was completely different of course.
> 
> I would not go as far as call the test "completely invalid". It was not 
> done to compare Graal against C2 with strict isolation of as many other 
> factors as possible. It was simply a small subset of measurements we use 
> to track changes in Graal performance, which can give some idea of what 
> ranges of values to expect on the benchmarks.

Sure, but at least in the case of the crypto benchmarks we're looking
at the possible impact caused by using different providers and therefore
running completely different code.  That's very useful to know.

-- 
Andrew Haley
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671

From amp at cs.utexas.edu  Sun Feb 18 20:21:41 2018
From: amp at cs.utexas.edu (Arthur Peters)
Date: Sun, 18 Feb 2018 14:21:41 -0600
Subject: SIGSEGV in GraalVM 0.31
Message-ID: <a4fb47f7-6809-1b48-72ad-0737c33c3dd4@cs.utexas.edu>

I have run into a Graal VM crash (SIGSEGV) when executing compiled Scala
code. The problem occurs before Truffle initializes and only seems to
happen when UseJVMCICompiler is turned on. Currently reproducing this
crash requires running the entire Orc compiler
(https://github.com/orc-lang/orc) and the crash is non-deterministic
(occasionally the program runs much longer before crashing). Adding
-XX:JVMCIThreads=1 works around the crash. I'm pretty sure it's a
concurrency race somewhere in Graal that our Scala parser code can trigger.

I have a couple of questions:

 1. How can I determine what part of the Orc code is causing the crash?
    I want to be able to create a minimal test case for you all.
 2. For future issues like this, is it possible to disable the JVMCI
    last-tier compiler for some packages (or jars) but not others? That
    would make it easy to enable Graal on the packages that need it and
    disable it for others.

Below is a trimmed version of one of the core dumps (well information I
extracted from it). A number of compete dumps are at:
https://gist.github.com/arthurp/9e725864d1c211e4238677cc787f6ba4

Thanks!!

-Arthur

GDB bt output:

Program terminated with signal SIGSEGV, Segmentation fault.

Thread 1 (Thread 0x7f67d232d700 (LWP 29881)):
#0? 0x00007f67d106f8ca in SharedRuntime::get_poll_stub(unsigned char*)
() from /home/amp/shared/graalvm/graalvm-0.31/jre/lib/amd64/server/libjvm.so
#1? 0x00007f67d0fcd8d9 in JVM_handle_linux_signal () from
/home/amp/shared/graalvm/graalvm-0.31/jre/lib/amd64/server/libjvm.so
#2? 0x00007f67d0fc1b48 in signalHandler(int, siginfo*, void*) () from
/home/amp/shared/graalvm/graalvm-0.31/jre/lib/amd64/server/libjvm.so
#3? <signal handler called>
#4 0x00007f67b8087a1b in ?? ()
[...]

jstack output:

Thread 29881: (state = IN_JAVA)

(this is not cut, the crashed thread always shows IN_JAVA and no stack.)


From amp at cs.utexas.edu  Sun Feb 18 20:55:26 2018
From: amp at cs.utexas.edu (Arthur Peters)
Date: Sun, 18 Feb 2018 14:55:26 -0600
Subject: SIGSEGV in GraalVM 0.31
In-Reply-To: <a4fb47f7-6809-1b48-72ad-0737c33c3dd4@cs.utexas.edu>
References: <a4fb47f7-6809-1b48-72ad-0737c33c3dd4@cs.utexas.edu>
Message-ID: <d9679c8d-ff0c-af1f-2b0a-6e8b8f321096@cs.utexas.edu>

I said -XX:JVMCIThreads=1 worked around the crash. I was wrong. It just
makes the crash a bit less likely. So I am in need of a work around
(ideally not -UseJVMCICompiler).

-Arthur


On 02/18/2018 02:21 PM, Arthur Peters wrote:
>
> I have run into a Graal VM crash (SIGSEGV) when executing compiled
> Scala code. The problem occurs before Truffle initializes and only
> seems to happen when UseJVMCICompiler is turned on. Currently
> reproducing this crash requires running the entire Orc compiler
> (https://github.com/orc-lang/orc) and the crash is non-deterministic
> (occasionally the program runs much longer before crashing). Adding
> -XX:JVMCIThreads=1 works around the crash. I'm pretty sure it's a
> concurrency race somewhere in Graal that our Scala parser code can
> trigger.
>
> I have a couple of questions:
>
>  1. How can I determine what part of the Orc code is causing the
>     crash? I want to be able to create a minimal test case for you all.
>  2. For future issues like this, is it possible to disable the JVMCI
>     last-tier compiler for some packages (or jars) but not others?
>     That would make it easy to enable Graal on the packages that need
>     it and disable it for others.
>
> Below is a trimmed version of one of the core dumps (well information
> I extracted from it). A number of compete dumps are at:
> https://gist.github.com/arthurp/9e725864d1c211e4238677cc787f6ba4
>
> Thanks!!
>
> -Arthur
>
> GDB bt output:
>
> Program terminated with signal SIGSEGV, Segmentation fault.
>
> Thread 1 (Thread 0x7f67d232d700 (LWP 29881)):
> #0? 0x00007f67d106f8ca in SharedRuntime::get_poll_stub(unsigned char*)
> () from
> /home/amp/shared/graalvm/graalvm-0.31/jre/lib/amd64/server/libjvm.so
> #1? 0x00007f67d0fcd8d9 in JVM_handle_linux_signal () from
> /home/amp/shared/graalvm/graalvm-0.31/jre/lib/amd64/server/libjvm.so
> #2? 0x00007f67d0fc1b48 in signalHandler(int, siginfo*, void*) () from
> /home/amp/shared/graalvm/graalvm-0.31/jre/lib/amd64/server/libjvm.so
> #3? <signal handler called>
> #4 0x00007f67b8087a1b in ?? ()
> [...]
>
> jstack output:
>
> Thread 29881: (state = IN_JAVA)
>
> (this is not cut, the crashed thread always shows IN_JAVA and no stack.)
>


From doug.simon at oracle.com  Sun Feb 18 21:08:40 2018
From: doug.simon at oracle.com (Doug Simon)
Date: Sun, 18 Feb 2018 22:08:40 +0100
Subject: SIGSEGV in GraalVM 0.31
In-Reply-To: <a4fb47f7-6809-1b48-72ad-0737c33c3dd4@cs.utexas.edu>
References: <a4fb47f7-6809-1b48-72ad-0737c33c3dd4@cs.utexas.edu>
Message-ID: <4ECC2ECD-CC45-4B8A-BE23-A3013D3D2594@oracle.com>

Hi Arthur,

To begin with, thanks for another useful and well submitted bug report.

> On 18 Feb 2018, at 21:21, Arthur Peters <amp at cs.utexas.edu> wrote:
> 
> I have run into a Graal VM crash (SIGSEGV) when executing compiled Scala
> code. The problem occurs before Truffle initializes and only seems to
> happen when UseJVMCICompiler is turned on. Currently reproducing this
> crash requires running the entire Orc compiler
> (https://github.com/orc-lang/orc) and the crash is non-deterministic
> (occasionally the program runs much longer before crashing). Adding
> -XX:JVMCIThreads=1 works around the crash. I'm pretty sure it's a
> concurrency race somewhere in Graal that our Scala parser code can trigger.
> 
> I have a couple of questions:
> 
> 1. How can I determine what part of the Orc code is causing the crash?
>    I want to be able to create a minimal test case for you all.

The most useful piece of information you can provide is the hs_err file that HotSpot (almost always) produces on a crash. If we're lucky, it will show a stack trace for the crashing thread. If not, we at least see the methods most recently JIT compiled.

> 2. For future issues like this, is it possible to disable the JVMCI
>    last-tier compiler for some packages (or jars) but not others? That
>    would make it easy to enable Graal on the packages that need it and
>    disable it for others.

There is the -Dgraal.GraalCompileOnly option which takes a method filter in the same format[1] as the -Dgraal.MethodFilter option. For example, -Dgraal.GraalCompileOnly=orc.run.extensions.*.*,orc.run.porce.call.*.* will restrict Graal compilation to all packages starting with "orc.run.extensions." and "orc.run.porce.call.". Note that this option does not force a method to be compiled by Graal (or compiled at all). It is only applied to a method the VM has already selected for compilation by Graal.

> 
> Below is a trimmed version of one of the core dumps (well information I
> extracted from it). A number of compete dumps are at:
> https://gist.github.com/arthurp/9e725864d1c211e4238677cc787f6ba4

Thanks for the copious info! However, the best starting point would be a hs_err file - I'm assuming one is produced by the crash?

-Doug

[1] https://raw.githubusercontent.com/oracle/graal/d242032a2fa1757b4f14df3e8b42d3354f7da03c/compiler/src/org.graalvm.compiler.debug/src/org/graalvm/compiler/debug/MethodFilterHelp.txt

> GDB bt output:
> 
> Program terminated with signal SIGSEGV, Segmentation fault.
> 
> Thread 1 (Thread 0x7f67d232d700 (LWP 29881)):
> #0  0x00007f67d106f8ca in SharedRuntime::get_poll_stub(unsigned char*)
> () from /home/amp/shared/graalvm/graalvm-0.31/jre/lib/amd64/server/libjvm.so
> #1  0x00007f67d0fcd8d9 in JVM_handle_linux_signal () from
> /home/amp/shared/graalvm/graalvm-0.31/jre/lib/amd64/server/libjvm.so
> #2  0x00007f67d0fc1b48 in signalHandler(int, siginfo*, void*) () from
> /home/amp/shared/graalvm/graalvm-0.31/jre/lib/amd64/server/libjvm.so
> #3  <signal handler called>
> #4 0x00007f67b8087a1b in ?? ()
> [...]
> 
> jstack output:
> 
> Thread 29881: (state = IN_JAVA)
> 
> (this is not cut, the crashed thread always shows IN_JAVA and no stack.)
> 


From amp at cs.utexas.edu  Sun Feb 18 21:49:19 2018
From: amp at cs.utexas.edu (Arthur Peters)
Date: Sun, 18 Feb 2018 15:49:19 -0600
Subject: SIGSEGV in GraalVM 0.31
In-Reply-To: <4ECC2ECD-CC45-4B8A-BE23-A3013D3D2594@oracle.com>
References: <a4fb47f7-6809-1b48-72ad-0737c33c3dd4@cs.utexas.edu>
 <4ECC2ECD-CC45-4B8A-BE23-A3013D3D2594@oracle.com>
Message-ID: <b81a37a8-93f6-2985-deaf-1278e6a962a0@cs.utexas.edu>

I wish I could provide the hs_err file, but as far as I can tell it's
not being generated. I checked all the normal places and I tried
specifying a path with XX:ErrorFile and no files ever appeared after the
crash. Is there some way to help it generate the file or make sure it
doesn't decide not to write the file?

My command line is below in case it has any issues. The most notable
part is that I use -XX:-UseJVMCIClassLoader since my language currently
uses a non-polyglot launcher. But I cannot see how that would be causing
this kind of problem.

-Dgraal.GraalCompileOnly=orc.run.*.* (and similar) seems to work around
the problem (I'm still running tests to make sure). From what I can tell
this causes everything else to be compiled to C1 at best instead of
being compiled with the HotSpot C2 compiler. Is that correct? (Just so I
can estimate the effect on performance.)

Thanks a lot for your quick weekend response.

-Arthur

graalvm-0.31/jre/bin/java -XX:-UseJVMCIClassLoader -XX:+UseJVMCICompiler
-XX:JVMCIThreads=1 -Dorc.numerics.preferLP=true -Xmx6000m
-Xbootclasspath:graalvm-0.31/jre/lib/resources.jar:graalvm-0.31/jre/lib/rt.jar:graalvm-0.31/jre/lib/jsse.jar:graalvm-0.31/jre/lib/jce.jar:graalvm-0.31/jre/lib/charsets.jar:graalvm-0.31/jre/lib/jfr.jar:graalvm-0.31/jre/lib/jvmci-services.jar:graalvm-0.31/jre/lib/boot/graaljs-scriptengine.jar:graalvm-0.31/jre/lib/boot/graal-sdk.jar:graalvm-0.31/jre/lib/boot/graal-sdk.src.zip:graalvm-0.31/jre/lib/jvmci/graal.jar:graalvm-0.31/jre/lib/truffle/truffle-api.jar:/home/amp/LocalInstalls/eclipse/plugins/org.scala-lang.scala-library_2.12.3.v20170725-052526-VFINAL-6ac6da8.jar:/home/amp/LocalInstalls/eclipse/plugins/org.scala-lang.scala-reflect_2.12.3.v20170725-052526-VFINAL-6ac6da8.jar
-classpath $ORCCLASSPATH orc.Main $ORCARGS

(I removed the absolute path from graalvm-0.31 for clarity, but all the
paths are actually absolute.)

ORCCLASSPATH=/home/amp/shared/orc/OrcScala/lib/scala-parser-combinators_2.12-1.0.6.jar:/home/amp/shared/orc/OrcScala/lib/scala-xml_2.12-1.0.6.jar:/home/amp/shared/orc/OrcTests/tools/junit-4.5.jar:/home/amp/shared/orc/OrcScala/lib/swivel_2.12-0.0.2.jar:/home/amp/shared/orc/OrcScala/build/classes:/home/amp/shared/orc/OrcSites/lib/axis-1.4.jar:/home/amp/shared/orc/OrcSites/lib/axis-jaxrpc-1.4.jar:/home/amp/shared/orc/OrcSites/lib/htmlparser.jar:/home/amp/shared/orc/OrcSites/lib/javax.mail-1.5.5.jar:/home/amp/shared/orc/OrcSites/lib/mimepull-1.9.6.jar:/home/amp/shared/orc/OrcSites/lib/smack.jar:/home/amp/shared/orc/OrcSites/lib/smackx.jar:/home/amp/shared/orc/OrcSites/lib/wsdl4j-1.6.3.jar:/home/amp/shared/orc/OrcSites/lib/jettison-1.3.7.jar:/home/amp/shared/orc/OrcSites/lib/oauth-20100527.jar:/home/amp/shared/orc/OrcSites/lib/oauth-consumer-20100527.jar:/home/amp/shared/orc/OrcSites/lib/oauth-httpclient3-20090617.jar:/home/amp/shared/orc/OrcSites/lib/oauth-provider-20100527.jar:/home/amp/shared/orc/OrcSites/lib/joda-time-1.5.2.jar:/home/amp/shared/orc/OrcSites/lib/ecj-4.5.2.jar:/home/amp/shared/orc/OrcSites/lib/commons-httpclient-3.1.jar:/home/amp/shared/orc/OrcSites/lib/commons-codec-1.3.jar:/home/amp/shared/orc/OrcSites/lib/commons-discovery-0.5.jar:/home/amp/shared/orc/OrcSites/lib/commons-logging-1.2.jar:/home/amp/shared/orc/OrcSites/lib/twitter4j-core-4.0.4.jar:/home/amp/shared/orc/OrcSites/lib/twitter4j-stream-4.0.4.jar:/home/amp/shared/orc/OrcSites/lib/jetty-all-9.3.11.v20160721-uber.jar:/home/amp/shared/orc/OrcSites/build/classes:/home/amp/shared/orc/OrcTests/build:/home/amp/shared/orc/PorcE/build/classes

ORCARGS=--backend porc -O 3 -I
/home/amp/shared/orc/OrcTests/src/orc/lib/includes
/home/amp/shared/orc/OrcTests/test_data/performance/black-scholes/black-scholes-scala-compute-partitioned-seq.orc


On 02/18/2018 03:08 PM, Doug Simon wrote:
> Hi Arthur,
>
> To begin with, thanks for another useful and well submitted bug report.
>
>> On 18 Feb 2018, at 21:21, Arthur Peters <amp at cs.utexas.edu> wrote:
>>
>> I have run into a Graal VM crash (SIGSEGV) when executing compiled Scala
>> code. The problem occurs before Truffle initializes and only seems to
>> happen when UseJVMCICompiler is turned on. Currently reproducing this
>> crash requires running the entire Orc compiler
>> (https://github.com/orc-lang/orc) and the crash is non-deterministic
>> (occasionally the program runs much longer before crashing). Adding
>> -XX:JVMCIThreads=1 works around the crash. I'm pretty sure it's a
>> concurrency race somewhere in Graal that our Scala parser code can trigger.
>>
>> I have a couple of questions:
>>
>> 1. How can I determine what part of the Orc code is causing the crash?
>>    I want to be able to create a minimal test case for you all.
> The most useful piece of information you can provide is the hs_err file that HotSpot (almost always) produces on a crash. If we're lucky, it will show a stack trace for the crashing thread. If not, we at least see the methods most recently JIT compiled.
>
>> 2. For future issues like this, is it possible to disable the JVMCI
>>    last-tier compiler for some packages (or jars) but not others? That
>>    would make it easy to enable Graal on the packages that need it and
>>    disable it for others.
> There is the -Dgraal.GraalCompileOnly option which takes a method filter in the same format[1] as the -Dgraal.MethodFilter option. For example, -Dgraal.GraalCompileOnly=orc.run.extensions.*.*,orc.run.porce.call.*.* will restrict Graal compilation to all packages starting with "orc.run.extensions." and "orc.run.porce.call.". Note that this option does not force a method to be compiled by Graal (or compiled at all). It is only applied to a method the VM has already selected for compilation by Graal.
>
>> Below is a trimmed version of one of the core dumps (well information I
>> extracted from it). A number of compete dumps are at:
>> https://gist.github.com/arthurp/9e725864d1c211e4238677cc787f6ba4
> Thanks for the copious info! However, the best starting point would be a hs_err file - I'm assuming one is produced by the crash?
>
> -Doug
>
> [1] https://raw.githubusercontent.com/oracle/graal/d242032a2fa1757b4f14df3e8b42d3354f7da03c/compiler/src/org.graalvm.compiler.debug/src/org/graalvm/compiler/debug/MethodFilterHelp.txt
>
>> GDB bt output:
>>
>> Program terminated with signal SIGSEGV, Segmentation fault.
>>
>> Thread 1 (Thread 0x7f67d232d700 (LWP 29881)):
>> #0  0x00007f67d106f8ca in SharedRuntime::get_poll_stub(unsigned char*)
>> () from /home/amp/shared/graalvm/graalvm-0.31/jre/lib/amd64/server/libjvm.so
>> #1  0x00007f67d0fcd8d9 in JVM_handle_linux_signal () from
>> /home/amp/shared/graalvm/graalvm-0.31/jre/lib/amd64/server/libjvm.so
>> #2  0x00007f67d0fc1b48 in signalHandler(int, siginfo*, void*) () from
>> /home/amp/shared/graalvm/graalvm-0.31/jre/lib/amd64/server/libjvm.so
>> #3  <signal handler called>
>> #4 0x00007f67b8087a1b in ?? ()
>> [...]
>>
>> jstack output:
>>
>> Thread 29881: (state = IN_JAVA)
>>
>> (this is not cut, the crashed thread always shows IN_JAVA and no stack.)
>>



From doug.simon at oracle.com  Mon Feb 19 11:36:17 2018
From: doug.simon at oracle.com (Doug Simon)
Date: Mon, 19 Feb 2018 12:36:17 +0100
Subject: SIGSEGV in GraalVM 0.31
In-Reply-To: <b81a37a8-93f6-2985-deaf-1278e6a962a0@cs.utexas.edu>
References: <a4fb47f7-6809-1b48-72ad-0737c33c3dd4@cs.utexas.edu>
 <4ECC2ECD-CC45-4B8A-BE23-A3013D3D2594@oracle.com>
 <b81a37a8-93f6-2985-deaf-1278e6a962a0@cs.utexas.edu>
Message-ID: <B0A820C0-0ABB-4218-AEF7-43C8E398BA38@oracle.com>

Hi Arthur,

> On 18 Feb 2018, at 22:49, Arthur Peters <amp at cs.utexas.edu> wrote:
> 
> I wish I could provide the hs_err file, but as far as I can tell it's
> not being generated. I checked all the normal places and I tried
> specifying a path with XX:ErrorFile and no files ever appeared after the
> crash. Is there some way to help it generate the file or make sure it
> doesn't decide not to write the file?

I don't know why the hs_err file is not showing up and why ErrorFile is not working. It's very rare that the VM crashes this hard.

We're currently deploying debug versions of the JVMCI JDK8 binaries available at http://www.oracle.com/technetwork/oracle-labs/program-languages/downloads/index.html. They should be available in the next 24 hours. Once you can get one of those, then you should be able to drop the libjvm.so file into your GraalVM installation and we might learn more.

> 
> My command line is below in case it has any issues. The most notable
> part is that I use -XX:-UseJVMCIClassLoader since my language currently
> uses a non-polyglot launcher. But I cannot see how that would be causing
> this kind of problem.

You're right - that should not cause an issue. BTW, it seems like you could use -Xbootclasspath/a: instead of -Xbootclasspath. That is, you only need to append to the boot class path.

> 
> -Dgraal.GraalCompileOnly=orc.run.*.* (and similar) seems to work around
> the problem (I'm still running tests to make sure). From what I can tell
> this causes everything else to be compiled to C1 at best instead of
> being compiled with the HotSpot C2 compiler. Is that correct? (Just so I
> can estimate the effect on performance.)

Yes, that is correct.

-Doug

> graalvm-0.31/jre/bin/java -XX:-UseJVMCIClassLoader -XX:+UseJVMCICompiler
> -XX:JVMCIThreads=1 -Dorc.numerics.preferLP=true -Xmx6000m
> -Xbootclasspath:graalvm-0.31/jre/lib/resources.jar:graalvm-0.31/jre/lib/rt.jar:graalvm-0.31/jre/lib/jsse.jar:graalvm-0.31/jre/lib/jce.jar:graalvm-0.31/jre/lib/charsets.jar:graalvm-0.31/jre/lib/jfr.jar:graalvm-0.31/jre/lib/jvmci-services.jar:graalvm-0.31/jre/lib/boot/graaljs-scriptengine.jar:graalvm-0.31/jre/lib/boot/graal-sdk.jar:graalvm-0.31/jre/lib/boot/graal-sdk.src.zip:graalvm-0.31/jre/lib/jvmci/graal.jar:graalvm-0.31/jre/lib/truffle/truffle-api.jar:/home/amp/LocalInstalls/eclipse/plugins/org.scala-lang.scala-library_2.12.3.v20170725-052526-VFINAL-6ac6da8.jar:/home/amp/LocalInstalls/eclipse/plugins/org.scala-lang.scala-reflect_2.12.3.v20170725-052526-VFINAL-6ac6da8.jar
> -classpath $ORCCLASSPATH orc.Main $ORCARGS
> 
> (I removed the absolute path from graalvm-0.31 for clarity, but all the
> paths are actually absolute.)
> 
> ORCCLASSPATH=/home/amp/shared/orc/OrcScala/lib/scala-parser-combinators_2.12-1.0.6.jar:/home/amp/shared/orc/OrcScala/lib/scala-xml_2.12-1.0.6.jar:/home/amp/shared/orc/OrcTests/tools/junit-4.5.jar:/home/amp/shared/orc/OrcScala/lib/swivel_2.12-0.0.2.jar:/home/amp/shared/orc/OrcScala/build/classes:/home/amp/shared/orc/OrcSites/lib/axis-1.4.jar:/home/amp/shared/orc/OrcSites/lib/axis-jaxrpc-1.4.jar:/home/amp/shared/orc/OrcSites/lib/htmlparser.jar:/home/amp/shared/orc/OrcSites/lib/javax.mail-1.5.5.jar:/home/amp/shared/orc/OrcSites/lib/mimepull-1.9.6.jar:/home/amp/shared/orc/OrcSites/lib/smack.jar:/home/amp/shared/orc/OrcSites/lib/smackx.jar:/home/amp/shared/orc/OrcSites/lib/wsdl4j-1.6.3.jar:/home/amp/shared/orc/OrcSites/lib/jettison-1.3.7.jar:/home/amp/shared/orc/OrcSites/lib/oauth-20100527.jar:/home/amp/shared/orc/OrcSites/lib/oauth-consumer-20100527.jar:/home/amp/shared/orc/OrcSites/lib/oauth-httpclient3-20090617.jar:/home/amp/shared/orc/OrcSites/lib/oauth-provider-20100527.jar:/home/amp/shared/orc/OrcSites/lib/joda-time-1.5.2.jar:/home/amp/shared/orc/OrcSites/lib/ecj-4.5.2.jar:/home/amp/shared/orc/OrcSites/lib/commons-httpclient-3.1.jar:/home/amp/shared/orc/OrcSites/lib/commons-codec-1.3.jar:/home/amp/shared/orc/OrcSites/lib/commons-discovery-0.5.jar:/home/amp/shared/orc/OrcSites/lib/commons-logging-1.2.jar:/home/amp/shared/orc/OrcSites/lib/twitter4j-core-4.0.4.jar:/home/amp/shared/orc/OrcSites/lib/twitter4j-stream-4.0.4.jar:/home/amp/shared/orc/OrcSites/lib/jetty-all-9.3.11.v20160721-uber.jar:/home/amp/shared/orc/OrcSites/build/classes:/home/amp/shared/orc/OrcTests/build:/home/amp/shared/orc/PorcE/build/classes
> 
> ORCARGS=--backend porc -O 3 -I
> /home/amp/shared/orc/OrcTests/src/orc/lib/includes
> /home/amp/shared/orc/OrcTests/test_data/performance/black-scholes/black-scholes-scala-compute-partitioned-seq.orc
> 
> 
> On 02/18/2018 03:08 PM, Doug Simon wrote:
>> Hi Arthur,
>> 
>> To begin with, thanks for another useful and well submitted bug report.
>> 
>>> On 18 Feb 2018, at 21:21, Arthur Peters <amp at cs.utexas.edu> wrote:
>>> 
>>> I have run into a Graal VM crash (SIGSEGV) when executing compiled Scala
>>> code. The problem occurs before Truffle initializes and only seems to
>>> happen when UseJVMCICompiler is turned on. Currently reproducing this
>>> crash requires running the entire Orc compiler
>>> (https://github.com/orc-lang/orc) and the crash is non-deterministic
>>> (occasionally the program runs much longer before crashing). Adding
>>> -XX:JVMCIThreads=1 works around the crash. I'm pretty sure it's a
>>> concurrency race somewhere in Graal that our Scala parser code can trigger.
>>> 
>>> I have a couple of questions:
>>> 
>>> 1. How can I determine what part of the Orc code is causing the crash?
>>>   I want to be able to create a minimal test case for you all.
>> The most useful piece of information you can provide is the hs_err file that HotSpot (almost always) produces on a crash. If we're lucky, it will show a stack trace for the crashing thread. If not, we at least see the methods most recently JIT compiled.
>> 
>>> 2. For future issues like this, is it possible to disable the JVMCI
>>>   last-tier compiler for some packages (or jars) but not others? That
>>>   would make it easy to enable Graal on the packages that need it and
>>>   disable it for others.
>> There is the -Dgraal.GraalCompileOnly option which takes a method filter in the same format[1] as the -Dgraal.MethodFilter option. For example, -Dgraal.GraalCompileOnly=orc.run.extensions.*.*,orc.run.porce.call.*.* will restrict Graal compilation to all packages starting with "orc.run.extensions." and "orc.run.porce.call.". Note that this option does not force a method to be compiled by Graal (or compiled at all). It is only applied to a method the VM has already selected for compilation by Graal.
>> 
>>> Below is a trimmed version of one of the core dumps (well information I
>>> extracted from it). A number of compete dumps are at:
>>> https://gist.github.com/arthurp/9e725864d1c211e4238677cc787f6ba4
>> Thanks for the copious info! However, the best starting point would be a hs_err file - I'm assuming one is produced by the crash?
>> 
>> -Doug
>> 
>> [1] https://raw.githubusercontent.com/oracle/graal/d242032a2fa1757b4f14df3e8b42d3354f7da03c/compiler/src/org.graalvm.compiler.debug/src/org/graalvm/compiler/debug/MethodFilterHelp.txt
>> 
>>> GDB bt output:
>>> 
>>> Program terminated with signal SIGSEGV, Segmentation fault.
>>> 
>>> Thread 1 (Thread 0x7f67d232d700 (LWP 29881)):
>>> #0  0x00007f67d106f8ca in SharedRuntime::get_poll_stub(unsigned char*)
>>> () from /home/amp/shared/graalvm/graalvm-0.31/jre/lib/amd64/server/libjvm.so
>>> #1  0x00007f67d0fcd8d9 in JVM_handle_linux_signal () from
>>> /home/amp/shared/graalvm/graalvm-0.31/jre/lib/amd64/server/libjvm.so
>>> #2  0x00007f67d0fc1b48 in signalHandler(int, siginfo*, void*) () from
>>> /home/amp/shared/graalvm/graalvm-0.31/jre/lib/amd64/server/libjvm.so
>>> #3  <signal handler called>
>>> #4 0x00007f67b8087a1b in ?? ()
>>> [...]
>>> 
>>> jstack output:
>>> 
>>> Thread 29881: (state = IN_JAVA)
>>> 
>>> (this is not cut, the crashed thread always shows IN_JAVA and no stack.)
>>> 
> 
> 


From dms at samersoff.net  Mon Feb 19 12:25:00 2018
From: dms at samersoff.net (Dmitry Samersoff)
Date: Mon, 19 Feb 2018 15:25:00 +0300
Subject: SIGSEGV in GraalVM 0.31
In-Reply-To: <a4fb47f7-6809-1b48-72ad-0737c33c3dd4@cs.utexas.edu>
References: <a4fb47f7-6809-1b48-72ad-0737c33c3dd4@cs.utexas.edu>
Message-ID: <e897d0e0-7d84-cac8-4ebc-3ad86748d5d9@samersoff.net>

Arthur,

It looks like the crash always happens in get_poll_stub method.

see:
http://hg.openjdk.java.net/jdk8/jdk8/hotspot/file/tip/src/share/vm/runtime/sharedRuntime.cpp

Could you provide a disassembler around crash point?

Is it possible to try fastdebug version of JVM?

-Dmitry

On 18.02.2018 23:21, Arthur Peters wrote:
> I have run into a Graal VM crash (SIGSEGV) when executing compiled Scala
> code. The problem occurs before Truffle initializes and only seems to
> happen when UseJVMCICompiler is turned on. Currently reproducing this
> crash requires running the entire Orc compiler
> (https://github.com/orc-lang/orc) and the crash is non-deterministic
> (occasionally the program runs much longer before crashing). Adding
> -XX:JVMCIThreads=1 works around the crash. I'm pretty sure it's a
> concurrency race somewhere in Graal that our Scala parser code can trigger.
> 
> I have a couple of questions:
> 
>  1. How can I determine what part of the Orc code is causing the crash?
>     I want to be able to create a minimal test case for you all.
>  2. For future issues like this, is it possible to disable the JVMCI
>     last-tier compiler for some packages (or jars) but not others? That
>     would make it easy to enable Graal on the packages that need it and
>     disable it for others.
> 
> Below is a trimmed version of one of the core dumps (well information I
> extracted from it). A number of compete dumps are at:
> https://gist.github.com/arthurp/9e725864d1c211e4238677cc787f6ba4
> 
> Thanks!!
> 
> -Arthur
> 
> GDB bt output:
> 
> Program terminated with signal SIGSEGV, Segmentation fault.
> 
> Thread 1 (Thread 0x7f67d232d700 (LWP 29881)):
> #0? 0x00007f67d106f8ca in SharedRuntime::get_poll_stub(unsigned char*)
> () from /home/amp/shared/graalvm/graalvm-0.31/jre/lib/amd64/server/libjvm.so
> #1? 0x00007f67d0fcd8d9 in JVM_handle_linux_signal () from
> /home/amp/shared/graalvm/graalvm-0.31/jre/lib/amd64/server/libjvm.so
> #2? 0x00007f67d0fc1b48 in signalHandler(int, siginfo*, void*) () from
> /home/amp/shared/graalvm/graalvm-0.31/jre/lib/amd64/server/libjvm.so
> #3? <signal handler called>
> #4 0x00007f67b8087a1b in ?? ()
> [...]
> 
> jstack output:
> 
> Thread 29881: (state = IN_JAVA)
> 
> (this is not cut, the crashed thread always shows IN_JAVA and no stack.)
> 


-- 
Dmitry Samersoff
http://devnull.samersoff.net
* There will come soft rains ...


From doug.simon at oracle.com  Mon Feb 19 12:41:27 2018
From: doug.simon at oracle.com (Doug Simon)
Date: Mon, 19 Feb 2018 13:41:27 +0100
Subject: SIGSEGV in GraalVM 0.31
In-Reply-To: <e897d0e0-7d84-cac8-4ebc-3ad86748d5d9@samersoff.net>
References: <a4fb47f7-6809-1b48-72ad-0737c33c3dd4@cs.utexas.edu>
 <e897d0e0-7d84-cac8-4ebc-3ad86748d5d9@samersoff.net>
Message-ID: <B3A93650-39A6-40D3-BFAE-5C3D35818209@oracle.com>

Hi Arthur,

Could you please open an issue for this crash at https://github.com/oracle/graal/issues. We trying to move to GitHub as the primary point for handling Graal issues. I'll update that issue once a debug JVM binary is available.

-Doug

> On 19 Feb 2018, at 13:25, Dmitry Samersoff <dms at samersoff.net> wrote:
> 
> Arthur,
> 
> It looks like the crash always happens in get_poll_stub method.
> 
> see:
> http://hg.openjdk.java.net/jdk8/jdk8/hotspot/file/tip/src/share/vm/runtime/sharedRuntime.cpp
> 
> Could you provide a disassembler around crash point?
> 
> Is it possible to try fastdebug version of JVM?
> 
> -Dmitry
> 
> On 18.02.2018 23:21, Arthur Peters wrote:
>> I have run into a Graal VM crash (SIGSEGV) when executing compiled Scala
>> code. The problem occurs before Truffle initializes and only seems to
>> happen when UseJVMCICompiler is turned on. Currently reproducing this
>> crash requires running the entire Orc compiler
>> (https://github.com/orc-lang/orc) and the crash is non-deterministic
>> (occasionally the program runs much longer before crashing). Adding
>> -XX:JVMCIThreads=1 works around the crash. I'm pretty sure it's a
>> concurrency race somewhere in Graal that our Scala parser code can trigger.
>> 
>> I have a couple of questions:
>> 
>> 1. How can I determine what part of the Orc code is causing the crash?
>>    I want to be able to create a minimal test case for you all.
>> 2. For future issues like this, is it possible to disable the JVMCI
>>    last-tier compiler for some packages (or jars) but not others? That
>>    would make it easy to enable Graal on the packages that need it and
>>    disable it for others.
>> 
>> Below is a trimmed version of one of the core dumps (well information I
>> extracted from it). A number of compete dumps are at:
>> https://gist.github.com/arthurp/9e725864d1c211e4238677cc787f6ba4
>> 
>> Thanks!!
>> 
>> -Arthur
>> 
>> GDB bt output:
>> 
>> Program terminated with signal SIGSEGV, Segmentation fault.
>> 
>> Thread 1 (Thread 0x7f67d232d700 (LWP 29881)):
>> #0  0x00007f67d106f8ca in SharedRuntime::get_poll_stub(unsigned char*)
>> () from /home/amp/shared/graalvm/graalvm-0.31/jre/lib/amd64/server/libjvm.so
>> #1  0x00007f67d0fcd8d9 in JVM_handle_linux_signal () from
>> /home/amp/shared/graalvm/graalvm-0.31/jre/lib/amd64/server/libjvm.so
>> #2  0x00007f67d0fc1b48 in signalHandler(int, siginfo*, void*) () from
>> /home/amp/shared/graalvm/graalvm-0.31/jre/lib/amd64/server/libjvm.so
>> #3  <signal handler called>
>> #4 0x00007f67b8087a1b in ?? ()
>> [...]
>> 
>> jstack output:
>> 
>> Thread 29881: (state = IN_JAVA)
>> 
>> (this is not cut, the crashed thread always shows IN_JAVA and no stack.)
>> 
> 
> 
> -- 
> Dmitry Samersoff
> http://devnull.samersoff.net
> * There will come soft rains ...
> 


From aph at redhat.com  Fri Feb 23 13:59:24 2018
From: aph at redhat.com (Andrew Haley)
Date: Fri, 23 Feb 2018 13:59:24 +0000
Subject: A new merge into mainline JDK?
Message-ID: <e253423b-947b-4b2f-d9eb-b9e356388887@redhat.com>

Is a new merge into JDK expected any time soon?  I'm working on AOT
for AArch64.

-- 
Andrew Haley
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671

From doug.simon at oracle.com  Fri Feb 23 14:07:14 2018
From: doug.simon at oracle.com (Doug Simon)
Date: Fri, 23 Feb 2018 15:07:14 +0100
Subject: A new merge into mainline JDK?
In-Reply-To: <e253423b-947b-4b2f-d9eb-b9e356388887@redhat.com>
References: <e253423b-947b-4b2f-d9eb-b9e356388887@redhat.com>
Message-ID: <CD60E417-D2BF-4C49-B11C-F9837228D7D8@oracle.com>

Adding hotspot list as the hotspot team is responsible for these merges.

-Doug

> On 23 Feb 2018, at 14:59, Andrew Haley <aph at redhat.com> wrote:
> 
> Is a new merge into JDK expected any time soon?  I'm working on AOT
> for AArch64.
> 
> -- 
> Andrew Haley
> Java Platform Lead Engineer
> Red Hat UK Ltd. <https://www.redhat.com>
> EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671


From vladimir.kozlov at oracle.com  Fri Feb 23 17:51:25 2018
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Fri, 23 Feb 2018 09:51:25 -0800
Subject: A new merge into mainline JDK?
In-Reply-To: <CD60E417-D2BF-4C49-B11C-F9837228D7D8@oracle.com>
References: <e253423b-947b-4b2f-d9eb-b9e356388887@redhat.com>
 <CD60E417-D2BF-4C49-B11C-F9837228D7D8@oracle.com>
Message-ID: <fc3d6dfa-2f5c-9016-4766-0a8ea8139a8b@oracle.com>

We usually do monthly update. Last one was on Feb 2:
http://hg.openjdk.java.net/jdk/hs/rev/47f19ff9903c

Andrew, what do you want?

Do you want the merge before you push AOT changes or we should wait after? We can do either way.

Thanks,
Vladimir

On 2/23/18 6:07 AM, Doug Simon wrote:
> Adding hotspot list as the hotspot team is responsible for these merges.
> 
> -Doug
> 
>> On 23 Feb 2018, at 14:59, Andrew Haley <aph at redhat.com> wrote:
>>
>> Is a new merge into JDK expected any time soon?  I'm working on AOT
>> for AArch64.
>>
>> -- 
>> Andrew Haley
>> Java Platform Lead Engineer
>> Red Hat UK Ltd. <https://www.redhat.com>
>> EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671
> 

From aph at redhat.com  Fri Feb 23 18:53:16 2018
From: aph at redhat.com (Andrew Haley)
Date: Fri, 23 Feb 2018 18:53:16 +0000
Subject: A new merge into mainline JDK?
In-Reply-To: <fc3d6dfa-2f5c-9016-4766-0a8ea8139a8b@oracle.com>
References: <e253423b-947b-4b2f-d9eb-b9e356388887@redhat.com>
 <CD60E417-D2BF-4C49-B11C-F9837228D7D8@oracle.com>
 <fc3d6dfa-2f5c-9016-4766-0a8ea8139a8b@oracle.com>
Message-ID: <c1d3a491-c612-1435-d0c4-f361c5d265f2@redhat.com>

On 23/02/18 17:51, Vladimir Kozlov wrote:
> We usually do monthly update. Last one was on Feb 2:
> http://hg.openjdk.java.net/jdk/hs/rev/47f19ff9903c
> 
> Andrew, what do you want?
> 
> Do you want the merge before you push AOT changes or we should wait after? We can do either way.

Probably after is best, but it depends on when I get it done.  :-)

I'll do a few more days' work on it next week and get back to you.
Thanks.

-- 
Andrew Haley
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671

From dms at samersoff.net  Tue Feb 27 18:45:11 2018
From: dms at samersoff.net (Dmitry Samersoff)
Date: Tue, 27 Feb 2018 21:45:11 +0300
Subject: AArch64Address.lea missed BASE_REGISTER_ONLY case
Message-ID: <8567ced2-0aef-7fb6-b5aa-7fab1feee203@samersoff.net>

Hi Everybody,

AArch64Address.lea missed BASE_REGISTER_ONLY case. Is it a bug?

Bellow is a fragment of AArch64Address.lea:

 public void lea(AArch64MacroAssembler masm, Register r) {
        switch (addressingMode) {
            case IMMEDIATE_UNSCALED:
                if (immediate == 0 && base.equals(r)) { // it's a nop
                    break;
                }
                masm.add(64, r, base, immediate);
                break;
            case REGISTER_OFFSET:
                masm.add(64, r, base, offset);
                break;
           ...

BASE_REGISTER_ONLY case is missing and

masm.lea(array1, AArch64Address.createBaseRegisterOnlyAddress(array1));

cause an assert.

Is it a bug? If yes, I'll create a pull requires with the fix.

-Dmitry

-- 
Dmitry Samersoff
http://devnull.samersoff.net
* There will come soft rains ...


From adinn at redhat.com  Wed Feb 28 10:21:00 2018
From: adinn at redhat.com (Andrew Dinn)
Date: Wed, 28 Feb 2018 10:21:00 +0000
Subject: AArch64Address.lea missed BASE_REGISTER_ONLY case
In-Reply-To: <8567ced2-0aef-7fb6-b5aa-7fab1feee203@samersoff.net>
References: <8567ced2-0aef-7fb6-b5aa-7fab1feee203@samersoff.net>
Message-ID: <8fbf6c4b-9ad4-1471-03bc-35b323ac24eb@redhat.com>

Hi Dimitry,

On 27/02/18 18:45, Dmitry Samersoff wrote:
> Is it a bug? If yes, I'll create a pull requires with the fix.
Sorry, but no. lea means load effective address. It is there to compute
an address from a base address provided in some given register combined
with an offset. The latter is provided either via another register or as
a constant which can be encoded as an immediate. Essentially, it does an
add.

If you just have a base register with no offset to add then lea would
simply reduce to a register copy. In which case . . . this is not the
instruction you were looking for. Throwing a Graal shouldNotReachHere
error is the correct response.

At present the only place where AArch64ddress.lea gets called in from
MacroAssembler.lea and that only ever gets called from
AArch64ArrayEqualsOp with either a register offset address or an
unscaled immediate address. So, all is well.

regards,


Andrew Dinn
-----------
Senior Principal Software Engineer
Red Hat UK Ltd
Registered in England and Wales under Company Registration No. 03798903
Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander

From dms at samersoff.net  Wed Feb 28 17:52:03 2018
From: dms at samersoff.net (Dmitry Samersoff)
Date: Wed, 28 Feb 2018 20:52:03 +0300
Subject: AArch64Address.lea missed BASE_REGISTER_ONLY case
In-Reply-To: <8fbf6c4b-9ad4-1471-03bc-35b323ac24eb@redhat.com>
References: <8567ced2-0aef-7fb6-b5aa-7fab1feee203@samersoff.net>
 <8fbf6c4b-9ad4-1471-03bc-35b323ac24eb@redhat.com>
Message-ID: <c5b2ee6f-e659-85af-af16-baac7bdf725c@samersoff.net>

Hi Andrew,

Thank you for a detailed explanation. I understand the rationally behind
this error, but couldn't say that API is consistent.

Four constructions below do essentially the same but (a) and (b) works,
when (c) and (d) cause an assert.

It might be better to handle BASE_REGISTER_ONLY the same way as
IMMEDIATE_UNSCALED i.e.:

 case BASE_REGISTER_ONLY:
   if (base.equals(r)) { // it's a nop
      break;
   }

   masm.mov(64, r, base);
   break;


a)
masm.lea(reg,
      AArch64Address.createUnscaledImmediateAddress(array1, 0));

b)
masm.mov(64, tmp, zr);
masm.lea(reg,
    AArch64Address.createRegisterOffsetAddress(array1, tmp, false));

c)
masm.lea(reg,
    AArch64Address.createRegisterOffsetAddress(array1, zr, false));
d)
masm.lea(reg,
     AArch64Address.createBaseRegisterOnlyAddress(array1));

-Dmitry

On 02/28/2018 01:21 PM, Andrew Dinn wrote:
> Hi Dimitry,
> 
> On 27/02/18 18:45, Dmitry Samersoff wrote:
>> Is it a bug? If yes, I'll create a pull requires with the fix.
> Sorry, but no. lea means load effective address. It is there to compute
> an address from a base address provided in some given register combined
> with an offset. The latter is provided either via another register or as
> a constant which can be encoded as an immediate. Essentially, it does an
> add.
> 
> If you just have a base register with no offset to add then lea would
> simply reduce to a register copy. In which case . . . this is not the
> instruction you were looking for. Throwing a Graal shouldNotReachHere
> error is the correct response.
> 
> At present the only place where AArch64ddress.lea gets called in from
> MacroAssembler.lea and that only ever gets called from
> AArch64ArrayEqualsOp with either a register offset address or an
> unscaled immediate address. So, all is well.
> 
> regards,
> 
> 
> Andrew Dinn
> -----------
> Senior Principal Software Engineer
> Red Hat UK Ltd
> Registered in England and Wales under Company Registration No. 03798903
> Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander
> 


-- 
Dmitry Samersoff
http://devnull.samersoff.net
* There will come soft rains ...