From ningsheng.jian at linaro.org  Thu Sep  8 07:57:52 2016
From: ningsheng.jian at linaro.org (Ningsheng Jian)
Date: Thu, 8 Sep 2016 15:57:52 +0800
Subject: [aarch64-port-dev ] RFR: AArch64: Fix JNI floating point argument
	handling
Message-ID: <CACO5V=Z6i0tqCrEOjSeOxhq9vBePOCNu9E0fsk17+Mgt2Ushyw@mail.gmail.com>

Hi,

The jtreg test failure of

hotspot/test/compiler/floatingpoint/Test15FloatJNIArgs.java

is caused by incorrect floating point argument handling in JNI native wrapper.

The following patch:

http://people.linaro.org/~ningsheng.jian/jni-fix/webrev.00/

can fix this bug.

I also updated the test case (and renamed to TestFloatJNIArgs.java),
which exposes more issues in jni floating point args handling. (Need
to update the fake bug-id in the test java source, as I don't have
access right to JBS). Those issues can also be fixed by the patch.

Could someone please help to review and process the patch?

Thanks,
Ningsheng

From aph at redhat.com  Thu Sep  8 08:05:58 2016
From: aph at redhat.com (Andrew Haley)
Date: Thu, 8 Sep 2016 09:05:58 +0100
Subject: [aarch64-port-dev ] RFR: AArch64: Fix JNI floating point
 argument handling
In-Reply-To: <CACO5V=Z6i0tqCrEOjSeOxhq9vBePOCNu9E0fsk17+Mgt2Ushyw@mail.gmail.com>
References: <CACO5V=Z6i0tqCrEOjSeOxhq9vBePOCNu9E0fsk17+Mgt2Ushyw@mail.gmail.com>
Message-ID: <1d9d7d75-a20e-4145-dfe6-e8ff8e3aea7c@redhat.com>

This is https://bugs.openjdk.java.net/browse/JDK-8165673

Andrew.


From ningsheng.jian at linaro.org  Thu Sep  8 09:20:56 2016
From: ningsheng.jian at linaro.org (Ningsheng Jian)
Date: Thu, 8 Sep 2016 17:20:56 +0800
Subject: [aarch64-port-dev ] RFR: AArch64: Fix JNI floating point
	argument handling
In-Reply-To: <1d9d7d75-a20e-4145-dfe6-e8ff8e3aea7c@redhat.com>
References: <CACO5V=Z6i0tqCrEOjSeOxhq9vBePOCNu9E0fsk17+Mgt2Ushyw@mail.gmail.com>
	<1d9d7d75-a20e-4145-dfe6-e8ff8e3aea7c@redhat.com>
Message-ID: <CACO5V=YMYK37qSm+ot1s=tuOzXWn5rhUU3KztxQcX==NPMbBzA@mail.gmail.com>

Thank you Andrew!

I have updated the webrev at:

http://people.linaro.org/~ningsheng.jian/jni-fix/webrev.01/

Please help to review it. It passed jtreg tests on my arm server with
fastdebug build.

Thanks,
Ningsheng


On 8 September 2016 at 16:05, Andrew Haley <aph at redhat.com> wrote:
> This is https://bugs.openjdk.java.net/browse/JDK-8165673
>
> Andrew.
>

From adinn at redhat.com  Fri Sep  9 08:34:52 2016
From: adinn at redhat.com (Andrew Dinn)
Date: Fri, 9 Sep 2016 09:34:52 +0100
Subject: [aarch64-port-dev ] RFR: AArch64: Fix JNI floating point
 argument handling
In-Reply-To: <CACO5V=YMYK37qSm+ot1s=tuOzXWn5rhUU3KztxQcX==NPMbBzA@mail.gmail.com>
References: <CACO5V=Z6i0tqCrEOjSeOxhq9vBePOCNu9E0fsk17+Mgt2Ushyw@mail.gmail.com>
	<1d9d7d75-a20e-4145-dfe6-e8ff8e3aea7c@redhat.com>
	<CACO5V=YMYK37qSm+ot1s=tuOzXWn5rhUU3KztxQcX==NPMbBzA@mail.gmail.com>
Message-ID: <8f6113af-fd97-08c1-776d-f37b289be060@redhat.com>

Hi Ningsheng,

On 08/09/16 10:20, Ningsheng Jian wrote:
> I have updated the webrev at:
> 
> http://people.linaro.org/~ningsheng.jian/jni-fix/webrev.01/
> 
> Please help to review it. It passed jtreg tests on my arm server with
> fastdebug build.

Andrew Haley is on holiday at the moment so I have reviewed this patch.
It looks fine and the test passes on my patched build.

This will need a sponsor from Oracle to get it supplied with the
necessary exemption for jdk9 and committed -- any takers from the [in
cc] compiler dev list?

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 aph at redhat.com  Fri Sep  9 10:10:23 2016
From: aph at redhat.com (Andrew Haley)
Date: Fri, 9 Sep 2016 11:10:23 +0100
Subject: [aarch64-port-dev ] RFR: AArch64: Fix JNI floating point
 argument handling
In-Reply-To: <8f6113af-fd97-08c1-776d-f37b289be060@redhat.com>
References: <CACO5V=Z6i0tqCrEOjSeOxhq9vBePOCNu9E0fsk17+Mgt2Ushyw@mail.gmail.com>
	<1d9d7d75-a20e-4145-dfe6-e8ff8e3aea7c@redhat.com>
	<CACO5V=YMYK37qSm+ot1s=tuOzXWn5rhUU3KztxQcX==NPMbBzA@mail.gmail.com>
	<8f6113af-fd97-08c1-776d-f37b289be060@redhat.com>
Message-ID: <0e8ac5bb-0ab7-1120-a1d3-a15bf786c6da@redhat.com>

On 09/09/16 09:34, Andrew Dinn wrote:
> Hi Ningsheng,
> 
> On 08/09/16 10:20, Ningsheng Jian wrote:
>> I have updated the webrev at:
>>
>> http://people.linaro.org/~ningsheng.jian/jni-fix/webrev.01/
>>
>> Please help to review it. It passed jtreg tests on my arm server with
>> fastdebug build.
> 
> Andrew Haley is on holiday at the moment so I have reviewed this patch.
> It looks fine and the test passes on my patched build.

It's good.  I'm surprised (not to say appalled) that we never noticed
this before now.

Andrew.


From adinn at redhat.com  Fri Sep  9 12:59:11 2016
From: adinn at redhat.com (Andrew Dinn)
Date: Fri, 9 Sep 2016 13:59:11 +0100
Subject: [aarch64-port-dev ] RFR: AArch64: Fix JNI floating point
 argument handling
In-Reply-To: <0e8ac5bb-0ab7-1120-a1d3-a15bf786c6da@redhat.com>
References: <CACO5V=Z6i0tqCrEOjSeOxhq9vBePOCNu9E0fsk17+Mgt2Ushyw@mail.gmail.com>
	<1d9d7d75-a20e-4145-dfe6-e8ff8e3aea7c@redhat.com>
	<CACO5V=YMYK37qSm+ot1s=tuOzXWn5rhUU3KztxQcX==NPMbBzA@mail.gmail.com>
	<8f6113af-fd97-08c1-776d-f37b289be060@redhat.com>
	<0e8ac5bb-0ab7-1120-a1d3-a15bf786c6da@redhat.com>
Message-ID: <3f7844ac-8bd6-207d-cd81-ae93c8391dcf@redhat.com>

On 09/09/16 11:10, Andrew Haley wrote:
> On 09/09/16 09:34, Andrew Dinn wrote:
>> Hi Ningsheng,
>>
>> On 08/09/16 10:20, Ningsheng Jian wrote:
>>> I have updated the webrev at:
>>>
>>> http://people.linaro.org/~ningsheng.jian/jni-fix/webrev.01/
>>>
>>> Please help to review it. It passed jtreg tests on my arm server with
>>> fastdebug build.
>>
>> Andrew Haley is on holiday at the moment so I have reviewed this patch.
>> It looks fine and the test passes on my patched build.
> 
> It's good.  I'm surprised (not to say appalled) that we never noticed
> this before now.

Yeah, I was going to run hg blame on the jdk8 tree to see who wrote such
obviously broken code -- but I think it was me so I decided not to bother!

Do we still need someone from Oracle to sponsor this and provide it with
an exemption before it can go into JDK9? Or can you commit it?

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 aph at redhat.com  Fri Sep  9 13:30:39 2016
From: aph at redhat.com (Andrew Haley)
Date: Fri, 9 Sep 2016 14:30:39 +0100
Subject: [aarch64-port-dev ] RFR: AArch64: Fix JNI floating point
 argument handling
In-Reply-To: <3f7844ac-8bd6-207d-cd81-ae93c8391dcf@redhat.com>
References: <CACO5V=Z6i0tqCrEOjSeOxhq9vBePOCNu9E0fsk17+Mgt2Ushyw@mail.gmail.com>
	<1d9d7d75-a20e-4145-dfe6-e8ff8e3aea7c@redhat.com>
	<CACO5V=YMYK37qSm+ot1s=tuOzXWn5rhUU3KztxQcX==NPMbBzA@mail.gmail.com>
	<8f6113af-fd97-08c1-776d-f37b289be060@redhat.com>
	<0e8ac5bb-0ab7-1120-a1d3-a15bf786c6da@redhat.com>
	<3f7844ac-8bd6-207d-cd81-ae93c8391dcf@redhat.com>
Message-ID: <da622fdf-b8cb-749a-6c7b-ad79debdbc08@redhat.com>

On 09/09/16 13:59, Andrew Dinn wrote:
> Yeah, I was going to run hg blame on the jdk8 tree to see who wrote such
> obviously broken code -- but I think it was me so I decided not to bother!
> 
> Do we still need someone from Oracle to sponsor this and provide it with
> an exemption before it can go into JDK9? Or can you commit it?

This is a serious bug so it must go in.  We need sponsorship for
the test case.  If we don't get that sponsorship we can commit into
the aarch64 dir, but let's try for sponsorship first.

Andrew.


From stuart.monteith at linaro.org  Thu Sep 15 17:15:53 2016
From: stuart.monteith at linaro.org (Stuart Monteith)
Date: Thu, 15 Sep 2016 18:15:53 +0100
Subject: [aarch64-port-dev ] JCStress Failure -WCAS_WCAS
Message-ID: <CAEGA6kb02LGb8Go7UHiEXSKzW+wKZekdXoems2PheKm-QaR7Cg@mail.gmail.com>

Hello,
  I've been testing aarch64 JDK 9, and have come across the following failures:

org.openjdk.jcstress.tests.atomics.longs.AtomicLongPairwiseTests.WCAS_WCAS:
Observed forbidden state: 1, 10
org.openjdk.jcstress.tests.atomics.integer.AtomicIntegerPairwiseTests.WCAS_WCAS:
Observed forbidden state: 1, 10
org.openjdk.jcstress.tests.atomics.integer.AtomicIntegerPairwiseTests.WCAS_WCAS:
Observed forbidden state: 1, 10
org.openjdk.jcstress.tests.atomics.booleans.AtomicBooleanPairwiseTests.WCAS_WCAS:
Observed forbidden state: 0, 0
org.openjdk.jcstress.tests.atomics.longs.AtomicLongPairwiseTests.WCAS_WCAS:
Observed forbidden state: 1, 10
org.openjdk.jcstress.tests.atomics.integer.AtomicIntegerArrayPairwiseTests.WCAS_WCAS:
Observed forbidden state: 1, 10
org.openjdk.jcstress.tests.atomics.integer.AtomicIntegerPairwiseTests.WCAS_WCAS:
Observed forbidden state: 1, 10
org.openjdk.jcstress.tests.atomics.booleans.AtomicBooleanPairwiseTests.WCAS_WCAS:
Observed forbidden state: 0, 0
org.openjdk.jcstress.tests.atomics.integer.AtomicIntegerArrayPairwiseTests.WCAS_WCAS:
Observed forbidden state: 1, 10
org.openjdk.jcstress.tests.atomics.longs.AtomicLongArrayPairwiseTests.WCAS_WCAS:
Observed forbidden state: 1, 10
org.openjdk.jcstress.tests.atomics.integer.AtomicIntegerPairwiseTests.WCAS_WCAS:
Observed forbidden state: 1, 10
org.openjdk.jcstress.tests.atomics.booleans.AtomicBooleanPairwiseTests.WCAS_WCAS:
Observed forbidden state: 0, 0
org.openjdk.jcstress.tests.atomics.integer.AtomicIntegerArrayPairwiseTests.WCAS_WCAS:
Observed forbidden state: 1, 10
org.openjdk.jcstress.tests.atomics.longs.AtomicLongArrayPairwiseTests.WCAS_WCAS:
Observed forbidden state: 1, 10

These failures indicate that both actor's calls to weakCompareAndSet
are failing. However, as the test cases don't test for that they are
marked as "FORBIDDEN".

I don't believe that that is correct. Because the compare and sets are
weak, they will be subject to spurious failures, and that is what I'll
be seeing.

Would it be appropriate to set the testcases to something like the following?

    @Outcome(id = "1, 10", expect = Expect.ACCEPTABLE_SPEC, desc = "T1
& T2 spurious failure")

and for boolean:

    @Outcome(id = "0, 0", expect = Expect.ACCEPTABLE, desc = "T1 & T2
failed spuriously")


I might have submitted a patch, but currently I'm unable to build
JCStress. This patch in langtools has cause the use of
"-Xmodule:jdk.unsupported" in tests-chapter-1a/pom.xml to no longer
work:

8164745: javac -Xmodule compiles the module in a way that reads the
unnamed module Summary: Ensuring proper separation between named
modules the unnamed module when using -Xmodule

In addition, "weakCompareAndSetVolatile" has been changed to
"weakCompareAndSetPlain" which requires more changes to jcstress.


Best regards,
   Stuart

From shade at redhat.com  Fri Sep 16 11:10:29 2016
From: shade at redhat.com (Aleksey Shipilev)
Date: Fri, 16 Sep 2016 13:10:29 +0200
Subject: [aarch64-port-dev ] JCStress Failure -WCAS_WCAS
In-Reply-To: <CAEGA6kb02LGb8Go7UHiEXSKzW+wKZekdXoems2PheKm-QaR7Cg@mail.gmail.com>
References: <CAEGA6kb02LGb8Go7UHiEXSKzW+wKZekdXoems2PheKm-QaR7Cg@mail.gmail.com>
Message-ID: <fea34658-498d-ce94-cc5f-b672cab9d8b0@redhat.com>

Hi Stuart,

On 09/15/2016 07:15 PM, Stuart Monteith wrote:
> These failures indicate that both actor's calls to weakCompareAndSet
> are failing. However, as the test cases don't test for that they are
> marked as "FORBIDDEN".
> 
> I don't believe that that is correct. Because the compare and sets are
> weak, they will be subject to spurious failures, and that is what I'll
> be seeing.
> 
> Would it be appropriate to set the testcases to something like the following?
> 
>     @Outcome(id = "1, 10", expect = Expect.ACCEPTABLE_SPEC, desc = "T1
> & T2 spurious failure")
> 
> and for boolean:
> 
>     @Outcome(id = "0, 0", expect = Expect.ACCEPTABLE, desc = "T1 & T2
> failed spuriously")

Agreed. This is the error in test grading. Both suggestions look fine, I
did this change:
  http://hg.openjdk.java.net/code-tools/jcstress/rev/3040c983b52c


> I might have submitted a patch, but currently I'm unable to build
> JCStress. This patch in langtools has cause the use of
> "-Xmodule:jdk.unsupported" in tests-chapter-1a/pom.xml to no longer
> work:
> 
> 8164745: javac -Xmodule compiles the module in a way that reads the
> unnamed module Summary: Ensuring proper separation between named
> modules the unnamed module when using -Xmodule

Yes, thanks. The day of reckoning is upon us for using that
Jigsaw-specific hack. Rewritten to avoid dealing with Jigsaw:
  http://hg.openjdk.java.net/code-tools/jcstress/rev/5938d81bff44


> In addition, "weakCompareAndSetVolatile" has been changed to
> "weakCompareAndSetPlain" which requires more changes to jcstress.

This, and other API fixes for VarHandles are done now. jcstress should
now be buildable with JDK 9b135 (latest EA):
  http://hg.openjdk.java.net/code-tools/jcstress/rev/162fe8f8a34c

Please let me know if you run into more problems. We would need to dust
off the VarHandles testing in jcstress pretty soon anyway.

Thanks,
-Aleksey


From stuart.monteith at linaro.org  Fri Sep 16 12:52:01 2016
From: stuart.monteith at linaro.org (Stuart Monteith)
Date: Fri, 16 Sep 2016 13:52:01 +0100
Subject: [aarch64-port-dev ] JCStress Failure -WCAS_WCAS
In-Reply-To: <fea34658-498d-ce94-cc5f-b672cab9d8b0@redhat.com>
References: <CAEGA6kb02LGb8Go7UHiEXSKzW+wKZekdXoems2PheKm-QaR7Cg@mail.gmail.com>
	<fea34658-498d-ce94-cc5f-b672cab9d8b0@redhat.com>
Message-ID: <CAEGA6kYmp-VJnraQk2LUGvf1k+DbRn2F8UEsr-MP7znDE0LCJQ@mail.gmail.com>

Thanks Aleksey,
   I've have tests-chapter-1a compiling by generating a jar to use
"--add-patch" against so that @sun.misc.Contended will apparently be
in the jdk.unsupported module, but of course, that's not the problem
once you actually try to run.

Your changes look good to me, with the exception of the Padding. There
is an Aarch64 system that requires 128 bytes of padding to avoid
contention. If I interpret what you've written correctly, the booleans
you use for padding will be 64 bytes in length. Am I correct in
thinking booleans are 4 bytes in Hotspot fields?  The @Contended flag
has the correct behaviour as it can query the appropriate granule
size.

I guess it would be possible run launch java with
"-XX:+PrintFlagsFinal" and parse out:
     intx ContendedPaddingWidth                    = 128
                       {product} {default}

or take a property to configure JCStress explicitly. Or just have the
largest known value for everyone.

I'll have a go with your patches.

Thanks again,
   Stuart

On 16 September 2016 at 12:10, Aleksey Shipilev <shade at redhat.com> wrote:
> Hi Stuart,
>
> On 09/15/2016 07:15 PM, Stuart Monteith wrote:
>> These failures indicate that both actor's calls to weakCompareAndSet
>> are failing. However, as the test cases don't test for that they are
>> marked as "FORBIDDEN".
>>
>> I don't believe that that is correct. Because the compare and sets are
>> weak, they will be subject to spurious failures, and that is what I'll
>> be seeing.
>>
>> Would it be appropriate to set the testcases to something like the following?
>>
>>     @Outcome(id = "1, 10", expect = Expect.ACCEPTABLE_SPEC, desc = "T1
>> & T2 spurious failure")
>>
>> and for boolean:
>>
>>     @Outcome(id = "0, 0", expect = Expect.ACCEPTABLE, desc = "T1 & T2
>> failed spuriously")
>
> Agreed. This is the error in test grading. Both suggestions look fine, I
> did this change:
>   http://hg.openjdk.java.net/code-tools/jcstress/rev/3040c983b52c
>
>
>> I might have submitted a patch, but currently I'm unable to build
>> JCStress. This patch in langtools has cause the use of
>> "-Xmodule:jdk.unsupported" in tests-chapter-1a/pom.xml to no longer
>> work:
>>
>> 8164745: javac -Xmodule compiles the module in a way that reads the
>> unnamed module Summary: Ensuring proper separation between named
>> modules the unnamed module when using -Xmodule
>
> Yes, thanks. The day of reckoning is upon us for using that
> Jigsaw-specific hack. Rewritten to avoid dealing with Jigsaw:
>   http://hg.openjdk.java.net/code-tools/jcstress/rev/5938d81bff44
>
>
>> In addition, "weakCompareAndSetVolatile" has been changed to
>> "weakCompareAndSetPlain" which requires more changes to jcstress.
>
> This, and other API fixes for VarHandles are done now. jcstress should
> now be buildable with JDK 9b135 (latest EA):
>   http://hg.openjdk.java.net/code-tools/jcstress/rev/162fe8f8a34c
>
> Please let me know if you run into more problems. We would need to dust
> off the VarHandles testing in jcstress pretty soon anyway.
>
> Thanks,
> -Aleksey
>

From shade at redhat.com  Fri Sep 16 15:02:06 2016
From: shade at redhat.com (Aleksey Shipilev)
Date: Fri, 16 Sep 2016 17:02:06 +0200
Subject: [aarch64-port-dev ] JCStress Failure -WCAS_WCAS
In-Reply-To: <CAEGA6kYmp-VJnraQk2LUGvf1k+DbRn2F8UEsr-MP7znDE0LCJQ@mail.gmail.com>
References: <CAEGA6kb02LGb8Go7UHiEXSKzW+wKZekdXoems2PheKm-QaR7Cg@mail.gmail.com>
	<fea34658-498d-ce94-cc5f-b672cab9d8b0@redhat.com>
	<CAEGA6kYmp-VJnraQk2LUGvf1k+DbRn2F8UEsr-MP7znDE0LCJQ@mail.gmail.com>
Message-ID: <6100baf4-60c5-52fc-ec18-96aa1369652f@redhat.com>

Hi Stuart,

On 09/16/2016 02:52 PM, Stuart Monteith wrote:
>    I've have tests-chapter-1a compiling by generating a jar to use
> "--add-patch" against so that @sun.misc.Contended will apparently be
> in the jdk.unsupported module, but of course, that's not the problem
> once you actually try to run.

Yes, but I would prefer to have all these little Jigsaw pummeling
options out, if possible.

> Your changes look good to me, with the exception of the Padding. There
> is an Aarch64 system that requires 128 bytes of padding to avoid
> contention. If I interpret what you've written correctly, the booleans
> you use for padding will be 64 bytes in length. Am I correct in
> thinking booleans are 4 bytes in Hotspot fields? 

No. Booleans are 1-byte fields in HotSpot. But Padding plus two classes
generates 16x16 = 256 booleans on each side of the protected field,
which yields 256 bytes around it. See e.g.:

$ java --add-exports java.base/jdk.internal.vm.annotation=ALL-UNNAMED
-jar jol-cli.jar internals -cp tests-custom/target/jcstress.jar
org.openjdk.jcstress.infra.results.CharResult1_jcstress

org.openjdk.jcstress.infra.results.CharResult1_jcstress object internals:
 OFFSET  SIZE    TYPE DESCRIPTION                    VALUE
      0     4         (object header)                ...
      4     4         (object header)                ...
      8     4         (object header)                ...
     12     2    char CharResult1.r1                 \00
     14     2         (alignment/padding gap)        N/A
     16     1 boolean CharResult1_jcstress_c2.p000   false
     17     1 boolean CharResult1_jcstress_c2.p001   false
     18     1 boolean CharResult1_jcstress_c2.p002   false
...
    270     1 boolean CharResult1_jcstress_c2.p254   false
    271     1 boolean CharResult1_jcstress_c2.p255   false
    272     4     int CharResult1_jcstress_c1.trap   0
    276     1 boolean CharResult1_jcstress.p000      false
    277     1 boolean CharResult1_jcstress.p001      false
...
    530     1 boolean CharResult1_jcstress.p254      false
    531     1 boolean CharResult1_jcstress.p255      false
    532     4         (loss due to the next object alignment)
Instance size: 536 bytes


> The @Contended flag has the correct behaviour as it can query the
> appropriate granule size.

Yes, I know about the benefits of @Contended. Alas, using it in
compatible manner outside JDK is a nuisance. Granted, this is partially
my own fault for not pressing this hard enough during the original
development, but hey, I *was* suggesting java.util.concurrent.Contended
:) Hierarchy trick is the next best thing.

Thanks,
-Aleksey


From stuart.monteith at linaro.org  Fri Sep 16 15:49:34 2016
From: stuart.monteith at linaro.org (Stuart Monteith)
Date: Fri, 16 Sep 2016 16:49:34 +0100
Subject: [aarch64-port-dev ] JCStress Failure -WCAS_WCAS
In-Reply-To: <6100baf4-60c5-52fc-ec18-96aa1369652f@redhat.com>
References: <CAEGA6kb02LGb8Go7UHiEXSKzW+wKZekdXoems2PheKm-QaR7Cg@mail.gmail.com>
	<fea34658-498d-ce94-cc5f-b672cab9d8b0@redhat.com>
	<CAEGA6kYmp-VJnraQk2LUGvf1k+DbRn2F8UEsr-MP7znDE0LCJQ@mail.gmail.com>
	<6100baf4-60c5-52fc-ec18-96aa1369652f@redhat.com>
Message-ID: <CAEGA6kbpG5hdSb=6cY8VN6bQsZMcm9dYPUz6dWLEit96MBZHmw@mail.gmail.com>

Thanks for that Aleksey - I'm new to this OpenJDK thing, so that's all
good to know.

I do wonder what the case is for "-XX:-RestrictContended" if Jigsaw
restricts access anyway.

On 16 September 2016 at 16:02, Aleksey Shipilev <shade at redhat.com> wrote:
> Hi Stuart,
>
> On 09/16/2016 02:52 PM, Stuart Monteith wrote:
>>    I've have tests-chapter-1a compiling by generating a jar to use
>> "--add-patch" against so that @sun.misc.Contended will apparently be
>> in the jdk.unsupported module, but of course, that's not the problem
>> once you actually try to run.
>
> Yes, but I would prefer to have all these little Jigsaw pummeling
> options out, if possible.
>
>> Your changes look good to me, with the exception of the Padding. There
>> is an Aarch64 system that requires 128 bytes of padding to avoid
>> contention. If I interpret what you've written correctly, the booleans
>> you use for padding will be 64 bytes in length. Am I correct in
>> thinking booleans are 4 bytes in Hotspot fields?
>
> No. Booleans are 1-byte fields in HotSpot. But Padding plus two classes
> generates 16x16 = 256 booleans on each side of the protected field,
> which yields 256 bytes around it. See e.g.:
>
> $ java --add-exports java.base/jdk.internal.vm.annotation=ALL-UNNAMED
> -jar jol-cli.jar internals -cp tests-custom/target/jcstress.jar
> org.openjdk.jcstress.infra.results.CharResult1_jcstress
>
> org.openjdk.jcstress.infra.results.CharResult1_jcstress object internals:
>  OFFSET  SIZE    TYPE DESCRIPTION                    VALUE
>       0     4         (object header)                ...
>       4     4         (object header)                ...
>       8     4         (object header)                ...
>      12     2    char CharResult1.r1                 \00
>      14     2         (alignment/padding gap)        N/A
>      16     1 boolean CharResult1_jcstress_c2.p000   false
>      17     1 boolean CharResult1_jcstress_c2.p001   false
>      18     1 boolean CharResult1_jcstress_c2.p002   false
> ...
>     270     1 boolean CharResult1_jcstress_c2.p254   false
>     271     1 boolean CharResult1_jcstress_c2.p255   false
>     272     4     int CharResult1_jcstress_c1.trap   0
>     276     1 boolean CharResult1_jcstress.p000      false
>     277     1 boolean CharResult1_jcstress.p001      false
> ...
>     530     1 boolean CharResult1_jcstress.p254      false
>     531     1 boolean CharResult1_jcstress.p255      false
>     532     4         (loss due to the next object alignment)
> Instance size: 536 bytes
>
>
>> The @Contended flag has the correct behaviour as it can query the
>> appropriate granule size.
>
> Yes, I know about the benefits of @Contended. Alas, using it in
> compatible manner outside JDK is a nuisance. Granted, this is partially
> my own fault for not pressing this hard enough during the original
> development, but hey, I *was* suggesting java.util.concurrent.Contended
> :) Hierarchy trick is the next best thing.
>
> Thanks,
> -Aleksey
>

From shade at redhat.com  Mon Sep 19 13:17:52 2016
From: shade at redhat.com (Aleksey Shipilev)
Date: Mon, 19 Sep 2016 15:17:52 +0200
Subject: [aarch64-port-dev ] JCStress Failure -WCAS_WCAS
In-Reply-To: <CAEGA6kbpG5hdSb=6cY8VN6bQsZMcm9dYPUz6dWLEit96MBZHmw@mail.gmail.com>
References: <CAEGA6kb02LGb8Go7UHiEXSKzW+wKZekdXoems2PheKm-QaR7Cg@mail.gmail.com>
	<fea34658-498d-ce94-cc5f-b672cab9d8b0@redhat.com>
	<CAEGA6kYmp-VJnraQk2LUGvf1k+DbRn2F8UEsr-MP7znDE0LCJQ@mail.gmail.com>
	<6100baf4-60c5-52fc-ec18-96aa1369652f@redhat.com>
	<CAEGA6kbpG5hdSb=6cY8VN6bQsZMcm9dYPUz6dWLEit96MBZHmw@mail.gmail.com>
Message-ID: <9f502d48-7adb-ac25-22a2-5a2d89b294e1@redhat.com>

On 09/16/2016 05:49 PM, Stuart Monteith wrote:
> I do wonder what the case is for "-XX:-RestrictContended" if Jigsaw
> restricts access anyway.

This flag used to restrict @Contended in JDK 8, when there are no module
boundaries to protect its use. Since jcstress still (and will be, for
some foreseable future) run on JDK 8, we keep it intact.

Thanks,
-Aleksey


From ningsheng.jian at linaro.org  Tue Sep 20 10:09:45 2016
From: ningsheng.jian at linaro.org (Ningsheng Jian)
Date: Tue, 20 Sep 2016 18:09:45 +0800
Subject: [aarch64-port-dev ] RFR: AArch64: SEGV in stub code
	cipherBlockChaining_decryptAESCrypt
Message-ID: <CACO5V=bSada8eSU+89DwbyAOCwENFxPW1aCRyZApciwDMA7tVA@mail.gmail.com>

Hi,

Jtreg test jdk/test/com/sun/crypto/provider/Cipher/CTS/CTSMode.java
failed with SIGSEGV on option "-Xcomp -XX:-TieredCompilation".

The crash happens at stub code cipherBlockChaining_decryptAESCrypt.

Checking the jdk source code CipherTextStealing.decryptFinal and its
callee CipherBlockChaining.decrypt/implDecrypt, we can see that
cipherLen which is passed to the stub code can be 0. The unexpected
len_reg value makes the load from invalid address.

The following patch could fix this issue:

http://people.linaro.org/~ningsheng.jian/webrev/cbc-stub-fix/webrev.00/

It aligns with the Java code implementation and passed JTreg tests. To
make code consistent, I also update the encrypt part.

Could someone please help to take a look at it?

Thanks,
Ningsheng

From stuart.monteith at linaro.org  Tue Sep 20 16:28:21 2016
From: stuart.monteith at linaro.org (Stuart Monteith)
Date: Tue, 20 Sep 2016 17:28:21 +0100
Subject: [aarch64-port-dev ] RFR: AArch64: SEGV in stub code
	cipherBlockChaining_decryptAESCrypt
In-Reply-To: <CACO5V=bSada8eSU+89DwbyAOCwENFxPW1aCRyZApciwDMA7tVA@mail.gmail.com>
References: <CACO5V=bSada8eSU+89DwbyAOCwENFxPW1aCRyZApciwDMA7tVA@mail.gmail.com>
Message-ID: <CAEGA6kaZNwStmXv-LsfBcrZvcfK-QBZZFQWcT_SJyPfO6wEyNA@mail.gmail.com>

LGTM

On 20 September 2016 at 11:09, Ningsheng Jian <ningsheng.jian at linaro.org> wrote:
> Hi,
>
> Jtreg test jdk/test/com/sun/crypto/provider/Cipher/CTS/CTSMode.java
> failed with SIGSEGV on option "-Xcomp -XX:-TieredCompilation".
>
> The crash happens at stub code cipherBlockChaining_decryptAESCrypt.
>
> Checking the jdk source code CipherTextStealing.decryptFinal and its
> callee CipherBlockChaining.decrypt/implDecrypt, we can see that
> cipherLen which is passed to the stub code can be 0. The unexpected
> len_reg value makes the load from invalid address.
>
> The following patch could fix this issue:
>
> http://people.linaro.org/~ningsheng.jian/webrev/cbc-stub-fix/webrev.00/
>
> It aligns with the Java code implementation and passed JTreg tests. To
> make code consistent, I also update the encrypt part.
>
> Could someone please help to take a look at it?
>
> Thanks,
> Ningsheng

From ningsheng.jian at linaro.org  Wed Sep 21 04:45:36 2016
From: ningsheng.jian at linaro.org (Ningsheng Jian)
Date: Wed, 21 Sep 2016 12:45:36 +0800
Subject: [aarch64-port-dev ] RFR: 8163014: Mysterious/wrong value for
 "long" frame local variable on 64-bit
In-Reply-To: <57D6D293.3000208@oracle.com>
References: <57CF363F.7020600@oracle.com>
	<320d43ac-6279-705e-3582-89c16a82f807@oracle.com>
	<57D19146.5020608@oracle.com> <57D2E89F.9000209@oracle.com>
	<38ccb369-24c0-367b-633b-36d481f186f4@oracle.com>
	<57D6D293.3000208@oracle.com>
Message-ID: <CACO5V=buBGyO0Z=EAnMYgxt+ytez1J7LrStd6mhebG7LaO3Snw@mail.gmail.com>

Hi Max,

This patch breaks aarch64 build with:

error: ?wordsize? was not declared in this scope

I think it is a typo for "wordSize" at line below:

 330   str(r, pre(esp, -wordsize));

Thanks,
Ningsheng


On 13 September 2016 at 00:06, Max Ockner <max.ockner at oracle.com> wrote:
> New webrev: http://cr.openjdk.java.net/~mockner/8163014.hotspot.04/
>  Comments below.
> -Max
> On 9/9/2016 1:54 PM, dean.long at oracle.com wrote:
>>
>>
>>   614   movq(Address(rsp, 0), r);
>>   615   movptr(Address(rsp, Interpreter::expr_offset_in_bytes(1)),
>> NULL_WORD );
>> I wish these two looked more similar.  I guess movq is the same as movprt,
>> and
>> Interpreter::expr_offset_in_bytes(0)
>> could be used at 614?
>
>
> Yes. I have made this change.
>>
>>
>>   329   str(zr, pre(esp, -wordSize));
>>   330   str(r, pre(esp, -wordsize));
>>
>> Do you want to use a single stp here?
>>
> The current patch is a working code suggestion from Andrew Dinn.  If it is
> important to change, I will see if I can build on aarch64 before submitting.
>
>
>> dl
>>
>> On 9/9/16 9:51 AM, Max Ockner wrote:
>>>
>>> Oops. Here is version 2:
>>> http://cr.openjdk.java.net/~mockner/8163014.hotspot.03/
>>>
>>> Max
>>>
>>> On 9/8/2016 12:26 PM, Max Ockner wrote:
>>>>
>>>> Here is version 2 of this fix.
>>>>  - Added copyright to LocalLongHelper.java
>>>>  - Switched LocalLongTest.java to run with -Xint instead of -Xcomp, and
>>>> cleaned up some copypaste garbage.
>>>>  - changed the test directory name from locallong to LocalLong.
>>>>
>>>> Reran test with -Xint.
>>>>
>>>> Thanks,
>>>> Max
>>>>
>>>> On 9/7/2016 9:47 AM, Coleen Phillimore wrote:
>>>>>
>>>>>
>>>>> Max,
>>>>>
>>>>>
>>>>> http://cr.openjdk.java.net/~mockner/8163014.01/test/runtime/locallong/LocalLongHelper.java.html
>>>>>
>>>>> There's a lot in this test, but I can't think of a different way to
>>>>> inspect the stack to find out if the long unused slot is zeroed. This file
>>>>> is missing a copyright, and I think the directory should be LocalLong (I
>>>>> think our new convention of test directory names is capitalized).  I think
>>>>> we should keep the test in the hotspot repository even though it uses the
>>>>> StackWalk API because otherwise it won't be run with hotspot changes on an
>>>>> ad-hoc or nightly basis.
>>>>>
>>>>>
>>>>> http://cr.openjdk.java.net/~mockner/8163014.01/test/runtime/locallong/LocalLongTest.java.html
>>>>>
>>>>> I thought the idea was to run this with -Xint not -Xcomp?
>>>>>
>>>>> The interpreter changes look good.
>>>>>
>>>>> Coleen
>>>>>
>>>>> On 9/6/16 5:33 PM, Max Ockner wrote:
>>>>>>
>>>>>> Hello,
>>>>>> Please review this multi-platform fix for the stack walk API.
>>>>>>
>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8163014
>>>>>> Webrev: http://cr.openjdk.java.net/~mockner/8163014.01/
>>>>>>
>>>>>> In 64 bits, long values can fit into a single slot, but two slots are
>>>>>> still used. The high slot contains garbage. This normally wouldn't matter
>>>>>> since it is never read from but the stack walk API expects to display useful
>>>>>> information. This is an issue when displaying longs from local variables, so
>>>>>> this means we can kill any garbage off by zeroing it when it is pushed to
>>>>>> the stack in the previous frame. This solution zeroes the high byte of a
>>>>>> long value when it is being pushed to the stack (in push_l).
>>>>>>
>>>>>> This applies to x86, aarch64, and sparc. This change does not apply to
>>>>>> ppc, though the bug almost certainly does affect it. I have left ppc
>>>>>> untouched since I don't have access to the hardware required to reproduce
>>>>>> the bug and test the fix.
>>>>>>
>>>>>> I have adapted the reproducer from the bug into a test. It is curently
>>>>>> sitting in runtime/locallong, but I believe there must be a better place for
>>>>>> it.
>>>>>>
>>>>>> Thanks,
>>>>>> Max
>>>>>
>>>>>
>>>>
>>>
>>
>

From david.holmes at oracle.com  Wed Sep 21 06:47:01 2016
From: david.holmes at oracle.com (David Holmes)
Date: Wed, 21 Sep 2016 16:47:01 +1000
Subject: [aarch64-port-dev ] RFR: 8163014: Mysterious/wrong value for
 "long" frame local variable on 64-bit
In-Reply-To: <CACO5V=buBGyO0Z=EAnMYgxt+ytez1J7LrStd6mhebG7LaO3Snw@mail.gmail.com>
References: <57CF363F.7020600@oracle.com>
	<320d43ac-6279-705e-3582-89c16a82f807@oracle.com>
	<57D19146.5020608@oracle.com> <57D2E89F.9000209@oracle.com>
	<38ccb369-24c0-367b-633b-36d481f186f4@oracle.com>
	<57D6D293.3000208@oracle.com>
	<CACO5V=buBGyO0Z=EAnMYgxt+ytez1J7LrStd6mhebG7LaO3Snw@mail.gmail.com>
Message-ID: <8c7e1fc6-3a47-97ca-8f78-23bb07edb440@oracle.com>

Thanks for that report. I have filed:

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

David

On 21/09/2016 2:45 PM, Ningsheng Jian wrote:
> Hi Max,
>
> This patch breaks aarch64 build with:
>
> error: ?wordsize? was not declared in this scope
>
> I think it is a typo for "wordSize" at line below:
>
>  330   str(r, pre(esp, -wordsize));
>
> Thanks,
> Ningsheng
>
>
> On 13 September 2016 at 00:06, Max Ockner <max.ockner at oracle.com> wrote:
>> New webrev: http://cr.openjdk.java.net/~mockner/8163014.hotspot.04/
>>  Comments below.
>> -Max
>> On 9/9/2016 1:54 PM, dean.long at oracle.com wrote:
>>>
>>>
>>>   614   movq(Address(rsp, 0), r);
>>>   615   movptr(Address(rsp, Interpreter::expr_offset_in_bytes(1)),
>>> NULL_WORD );
>>> I wish these two looked more similar.  I guess movq is the same as movprt,
>>> and
>>> Interpreter::expr_offset_in_bytes(0)
>>> could be used at 614?
>>
>>
>> Yes. I have made this change.
>>>
>>>
>>>   329   str(zr, pre(esp, -wordSize));
>>>   330   str(r, pre(esp, -wordsize));
>>>
>>> Do you want to use a single stp here?
>>>
>> The current patch is a working code suggestion from Andrew Dinn.  If it is
>> important to change, I will see if I can build on aarch64 before submitting.
>>
>>
>>> dl
>>>
>>> On 9/9/16 9:51 AM, Max Ockner wrote:
>>>>
>>>> Oops. Here is version 2:
>>>> http://cr.openjdk.java.net/~mockner/8163014.hotspot.03/
>>>>
>>>> Max
>>>>
>>>> On 9/8/2016 12:26 PM, Max Ockner wrote:
>>>>>
>>>>> Here is version 2 of this fix.
>>>>>  - Added copyright to LocalLongHelper.java
>>>>>  - Switched LocalLongTest.java to run with -Xint instead of -Xcomp, and
>>>>> cleaned up some copypaste garbage.
>>>>>  - changed the test directory name from locallong to LocalLong.
>>>>>
>>>>> Reran test with -Xint.
>>>>>
>>>>> Thanks,
>>>>> Max
>>>>>
>>>>> On 9/7/2016 9:47 AM, Coleen Phillimore wrote:
>>>>>>
>>>>>>
>>>>>> Max,
>>>>>>
>>>>>>
>>>>>> http://cr.openjdk.java.net/~mockner/8163014.01/test/runtime/locallong/LocalLongHelper.java.html
>>>>>>
>>>>>> There's a lot in this test, but I can't think of a different way to
>>>>>> inspect the stack to find out if the long unused slot is zeroed. This file
>>>>>> is missing a copyright, and I think the directory should be LocalLong (I
>>>>>> think our new convention of test directory names is capitalized).  I think
>>>>>> we should keep the test in the hotspot repository even though it uses the
>>>>>> StackWalk API because otherwise it won't be run with hotspot changes on an
>>>>>> ad-hoc or nightly basis.
>>>>>>
>>>>>>
>>>>>> http://cr.openjdk.java.net/~mockner/8163014.01/test/runtime/locallong/LocalLongTest.java.html
>>>>>>
>>>>>> I thought the idea was to run this with -Xint not -Xcomp?
>>>>>>
>>>>>> The interpreter changes look good.
>>>>>>
>>>>>> Coleen
>>>>>>
>>>>>> On 9/6/16 5:33 PM, Max Ockner wrote:
>>>>>>>
>>>>>>> Hello,
>>>>>>> Please review this multi-platform fix for the stack walk API.
>>>>>>>
>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8163014
>>>>>>> Webrev: http://cr.openjdk.java.net/~mockner/8163014.01/
>>>>>>>
>>>>>>> In 64 bits, long values can fit into a single slot, but two slots are
>>>>>>> still used. The high slot contains garbage. This normally wouldn't matter
>>>>>>> since it is never read from but the stack walk API expects to display useful
>>>>>>> information. This is an issue when displaying longs from local variables, so
>>>>>>> this means we can kill any garbage off by zeroing it when it is pushed to
>>>>>>> the stack in the previous frame. This solution zeroes the high byte of a
>>>>>>> long value when it is being pushed to the stack (in push_l).
>>>>>>>
>>>>>>> This applies to x86, aarch64, and sparc. This change does not apply to
>>>>>>> ppc, though the bug almost certainly does affect it. I have left ppc
>>>>>>> untouched since I don't have access to the hardware required to reproduce
>>>>>>> the bug and test the fix.
>>>>>>>
>>>>>>> I have adapted the reproducer from the bug into a test. It is curently
>>>>>>> sitting in runtime/locallong, but I believe there must be a better place for
>>>>>>> it.
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Max
>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>

From adinn at redhat.com  Wed Sep 21 09:13:22 2016
From: adinn at redhat.com (Andrew Dinn)
Date: Wed, 21 Sep 2016 10:13:22 +0100
Subject: [aarch64-port-dev ] RFR: 8163014: Mysterious/wrong value for
 "long" frame local variable on 64-bit
In-Reply-To: <CACO5V=buBGyO0Z=EAnMYgxt+ytez1J7LrStd6mhebG7LaO3Snw@mail.gmail.com>
References: <57CF363F.7020600@oracle.com>
	<320d43ac-6279-705e-3582-89c16a82f807@oracle.com>
	<57D19146.5020608@oracle.com> <57D2E89F.9000209@oracle.com>
	<38ccb369-24c0-367b-633b-36d481f186f4@oracle.com>
	<57D6D293.3000208@oracle.com>
	<CACO5V=buBGyO0Z=EAnMYgxt+ytez1J7LrStd6mhebG7LaO3Snw@mail.gmail.com>
Message-ID: <100e9b65-7f42-593c-f482-05895aeb3c76@redhat.com>

On 21/09/16 05:45, Ningsheng Jian wrote:
> Hi Max,
> 
> This patch breaks aarch64 build with:
> 
> error: ?wordsize? was not declared in this scope
> 
> I think it is a typo for "wordSize" at line below:
> 
>  330   str(r, pre(esp, -wordsize));

Apologies for this -- it is my fault. I introduced the spelling mistake
when I transcribed my revision of Max's patch into email. I guess I
should have sent him a webrev but I merely wanted to highlight the error
in the AArch64 part of the patch.

n.b. Before replying to Max I applied the patch lines as shown above
except with correct spelling as wordSize and the corresponding test
passed on AArch64. So, correcting this typo should correct the problem.

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 adinn at redhat.com  Wed Sep 21 09:35:22 2016
From: adinn at redhat.com (Andrew Dinn)
Date: Wed, 21 Sep 2016 10:35:22 +0100
Subject: [aarch64-port-dev ] RFR: AArch64: SEGV in stub code
 cipherBlockChaining_decryptAESCrypt
In-Reply-To: <CACO5V=bSada8eSU+89DwbyAOCwENFxPW1aCRyZApciwDMA7tVA@mail.gmail.com>
References: <CACO5V=bSada8eSU+89DwbyAOCwENFxPW1aCRyZApciwDMA7tVA@mail.gmail.com>
Message-ID: <92c29040-7a82-3b73-7079-6b23b781dcd2@redhat.com>

On 20/09/16 11:09, Ningsheng Jian wrote:
> Jtreg test jdk/test/com/sun/crypto/provider/Cipher/CTS/CTSMode.java
> failed with SIGSEGV on option "-Xcomp -XX:-TieredCompilation".
> 
> The crash happens at stub code cipherBlockChaining_decryptAESCrypt.
> 
> Checking the jdk source code CipherTextStealing.decryptFinal and its
> callee CipherBlockChaining.decrypt/implDecrypt, we can see that
> cipherLen which is passed to the stub code can be 0. The unexpected
> len_reg value makes the load from invalid address.
> 
> The following patch could fix this issue:
> 
> http://people.linaro.org/~ningsheng.jian/webrev/cbc-stub-fix/webrev.00/
> 
> It aligns with the Java code implementation and passed JTreg tests. To
> make code consistent, I also update the encrypt part.
> 
> Could someone please help to take a look at it?

I think this patch looks like it will suffice to fix the AArch64 code.
However, I don't understand why this is only an AArch64 issue. For
example, it looks to me as if the x86_64 code is also susceptible to the
same problem should input value 0 be passed in len_reg (c_rarg4). So,
this might need fixing for all archs. Alternatively, it might be better
fixed in the jdk (Java) code.

Could someone from the hotspot compiler/runtime team confirm:

 i) whether an input len_reg value of zero will cause a problem on x86
(or, indeed, other archs)?

 ii) whether that case should be caught in Java code or stub code?

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 ningsheng.jian at linaro.org  Thu Sep 22 03:40:58 2016
From: ningsheng.jian at linaro.org (Ningsheng Jian)
Date: Thu, 22 Sep 2016 11:40:58 +0800
Subject: [aarch64-port-dev ] RFR: 8163014: Mysterious/wrong value for
 "long" frame local variable on 64-bit
In-Reply-To: <100e9b65-7f42-593c-f482-05895aeb3c76@redhat.com>
References: <57CF363F.7020600@oracle.com>
	<320d43ac-6279-705e-3582-89c16a82f807@oracle.com>
	<57D19146.5020608@oracle.com> <57D2E89F.9000209@oracle.com>
	<38ccb369-24c0-367b-633b-36d481f186f4@oracle.com>
	<57D6D293.3000208@oracle.com>
	<CACO5V=buBGyO0Z=EAnMYgxt+ytez1J7LrStd6mhebG7LaO3Snw@mail.gmail.com>
	<100e9b65-7f42-593c-f482-05895aeb3c76@redhat.com>
Message-ID: <CACO5V=ayqOWnOgyFpRf7G+5ASP4M0J_=wdx16J22M2odro1M+A@mail.gmail.com>

On 21 September 2016 at 17:13, Andrew Dinn <adinn at redhat.com> wrote:
> On 21/09/16 05:45, Ningsheng Jian wrote:
>> Hi Max,
>>
>> This patch breaks aarch64 build with:
>>
>> error: ?wordsize? was not declared in this scope
>>
>> I think it is a typo for "wordSize" at line below:
>>
>>  330   str(r, pre(esp, -wordsize));
>
> Apologies for this -- it is my fault. I introduced the spelling mistake
> when I transcribed my revision of Max's patch into email. I guess I
> should have sent him a webrev but I merely wanted to highlight the error
> in the AArch64 part of the patch.
>
> n.b. Before replying to Max I applied the patch lines as shown above
> except with correct spelling as wordSize and the corresponding test
> passed on AArch64. So, correcting this typo should correct the problem.

Yes, correcting the typo can fix the issue.

>
> 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 ningsheng.jian at linaro.org  Thu Sep 22 05:28:00 2016
From: ningsheng.jian at linaro.org (Ningsheng Jian)
Date: Thu, 22 Sep 2016 13:28:00 +0800
Subject: [aarch64-port-dev ] RFR: AArch64: SEGV in stub code
	cipherBlockChaining_decryptAESCrypt
In-Reply-To: <92c29040-7a82-3b73-7079-6b23b781dcd2@redhat.com>
References: <CACO5V=bSada8eSU+89DwbyAOCwENFxPW1aCRyZApciwDMA7tVA@mail.gmail.com>
	<92c29040-7a82-3b73-7079-6b23b781dcd2@redhat.com>
Message-ID: <CACO5V=YGQodcFh3k6Qr4KXG+egrhzw2Y2M4mZt7qwC3fKwdy6Q@mail.gmail.com>

On 21 September 2016 at 17:35, Andrew Dinn <adinn at redhat.com> wrote:
> On 20/09/16 11:09, Ningsheng Jian wrote:
>> Jtreg test jdk/test/com/sun/crypto/provider/Cipher/CTS/CTSMode.java
>> failed with SIGSEGV on option "-Xcomp -XX:-TieredCompilation".
>>
>> The crash happens at stub code cipherBlockChaining_decryptAESCrypt.
>>
>> Checking the jdk source code CipherTextStealing.decryptFinal and its
>> callee CipherBlockChaining.decrypt/implDecrypt, we can see that
>> cipherLen which is passed to the stub code can be 0. The unexpected
>> len_reg value makes the load from invalid address.
>>
>> The following patch could fix this issue:
>>
>> http://people.linaro.org/~ningsheng.jian/webrev/cbc-stub-fix/webrev.00/
>>
>> It aligns with the Java code implementation and passed JTreg tests. To
>> make code consistent, I also update the encrypt part.
>>
>> Could someone please help to take a look at it?
>
> I think this patch looks like it will suffice to fix the AArch64 code.
> However, I don't understand why this is only an AArch64 issue. For
> example, it looks to me as if the x86_64 code is also susceptible to the
> same problem should input value 0 be passed in len_reg (c_rarg4). So,
> this might need fixing for all archs. Alternatively, it might be better
> fixed in the jdk (Java) code.
>
> Could someone from the hotspot compiler/runtime team confirm:
>
>  i) whether an input len_reg value of zero will cause a problem on x86
> (or, indeed, other archs)?

I cannot see this issue on x86. Not sure for other archs.


Thanks,
Ningsheng

From bob.vandette at oracle.com  Wed Sep 28 14:07:59 2016
From: bob.vandette at oracle.com (Bob Vandette)
Date: Wed, 28 Sep 2016 10:07:59 -0400
Subject: [aarch64-port-dev ] Webrev of Oracle ARM & AARCH64 Sources
Message-ID: <5A08C4A6-2B69-4D29-80F5-1CE11E350283@oracle.com>

I?m am please to announce that I have completed our internal reviews and can now
open up the sources to our ARM 32 & 64 bit implementations of JDK9.

Here is a webrev that includes a patch that can be applied on top of the
(http://hg.openjdk.java.net/aarch32-port/jdk9-arm3264/ <http://hg.openjdk.java.net/aarch32-port/jdk9-arm3264/>) forest.  

     http://cr.openjdk.java.net/~bobv/arm3264/webrev <http://cr.openjdk.java.net/~bobv/arm3264/webrev>

Notes:

1. Counter to my initial email announcing the open sourcing effort,  the 
pregenerated interpreter is not included in the provided patch.  AOT is
our long term solution for increased performance on Mobile and it was decided
that we do not want to support the static interpreter beyond JDK 8.

2. In order to allow building the two different 64-bit ARM sources, I overloaded
a new configure option ?abi-profile to allow for the selection of the Oracle 
64-bit ARM port.  We need a better solution before this support can be
integrated into the mainline.  To use the Oracle sources for an aarch64 build,
select ?abi-profile=arm64.

3. The scripts provided below allows for the creation of the minimal, client and
server VMs for the Oracle aarch64 build, however, the jvm.cfg file is not 
automatically updated during the build.  To run a non server VM, this file 
will need to be updated.

4. In order to make it easier to keep the new open sources up to date with
their closed counterparts in jdk9, I have added a comment in 
hotspot/src/cpu/arm/vm/vm_version_ext_arm.hpp which contains the mercurial
revision that I last merged with.  This will make it easier to produce patches
to bring the new open files up to the latest version.

/* ARM sources Merged up to hotspot/src/closed changeset 2316:b247a2ea70e4 */

Build Scripts:

Here are a set of scripts that demonstrate how to build the three ARM
configurations.  We typically cross compile our ARM builds so these
scripts will have to be adjusted in order to build natively on an ARM system.

http://cr.openjdk.java.net/~bobv/arm3264/scripts/ <http://cr.openjdk.java.net/~bobv/arm3264/scripts/>

  aarch64.csh 	Builds the current open version of aarch64 binaries
  arm64.csh 	Builds the Oracle aarch64 binaries
  arm.csh 	Builds 32-bit ARM binaries

My next step is to push this changeset into the jdk9-arm3264 forest assuming I
achieve committer status for the aarch32 project this week.

Bob Vandette





From volker.simonis at gmail.com  Wed Sep 28 17:55:18 2016
From: volker.simonis at gmail.com (Volker Simonis)
Date: Wed, 28 Sep 2016 19:55:18 +0200
Subject: [aarch64-port-dev ] Webrev of Oracle ARM & AARCH64 Sources
In-Reply-To: <5A08C4A6-2B69-4D29-80F5-1CE11E350283@oracle.com>
References: <5A08C4A6-2B69-4D29-80F5-1CE11E350283@oracle.com>
Message-ID: <CA+3eh13SxW5cA0Eh9PyHgq1RjNCnt7TNc6uQ9GfQb8u==iXU+Q@mail.gmail.com>

Hi Bob,

congratulations! I'm pretty sure this was a pretty huge amount of
paper and programming work to reach this point :)

My general question is how is this code contribution supposed to work
together with the current ARM ports in the OpenJDK. Currently we have
a full-blown, supported arm64 bit port in the jdk9 main-line
(contributed and maintained by RedHat). The aarch32 project has a
full-blown implementation for arm32 for jdk8u contributed by Azul.

Is your new port intended to live and be maintained alongside these
already available ports?
Where does your port differ from the available ports in terms of
functionality and performance?
Is Oracle committed to support the new ports?
And finally, do you expect to integrate these port into JDK 9 mainline?

Thanks a lot and best regards,
Volker


On Wed, Sep 28, 2016 at 4:07 PM, Bob Vandette <bob.vandette at oracle.com> wrote:
> I?m am please to announce that I have completed our internal reviews and can now
> open up the sources to our ARM 32 & 64 bit implementations of JDK9.
>
> Here is a webrev that includes a patch that can be applied on top of the
> (http://hg.openjdk.java.net/aarch32-port/jdk9-arm3264/ <http://hg.openjdk.java.net/aarch32-port/jdk9-arm3264/>) forest.
>
>      http://cr.openjdk.java.net/~bobv/arm3264/webrev <http://cr.openjdk.java.net/~bobv/arm3264/webrev>
>
> Notes:
>
> 1. Counter to my initial email announcing the open sourcing effort,  the
> pregenerated interpreter is not included in the provided patch.  AOT is
> our long term solution for increased performance on Mobile and it was decided
> that we do not want to support the static interpreter beyond JDK 8.
>
> 2. In order to allow building the two different 64-bit ARM sources, I overloaded
> a new configure option ?abi-profile to allow for the selection of the Oracle
> 64-bit ARM port.  We need a better solution before this support can be
> integrated into the mainline.  To use the Oracle sources for an aarch64 build,
> select ?abi-profile=arm64.
>
> 3. The scripts provided below allows for the creation of the minimal, client and
> server VMs for the Oracle aarch64 build, however, the jvm.cfg file is not
> automatically updated during the build.  To run a non server VM, this file
> will need to be updated.
>
> 4. In order to make it easier to keep the new open sources up to date with
> their closed counterparts in jdk9, I have added a comment in
> hotspot/src/cpu/arm/vm/vm_version_ext_arm.hpp which contains the mercurial
> revision that I last merged with.  This will make it easier to produce patches
> to bring the new open files up to the latest version.
>
> /* ARM sources Merged up to hotspot/src/closed changeset 2316:b247a2ea70e4 */
>
> Build Scripts:
>
> Here are a set of scripts that demonstrate how to build the three ARM
> configurations.  We typically cross compile our ARM builds so these
> scripts will have to be adjusted in order to build natively on an ARM system.
>
> http://cr.openjdk.java.net/~bobv/arm3264/scripts/ <http://cr.openjdk.java.net/~bobv/arm3264/scripts/>
>
>   aarch64.csh   Builds the current open version of aarch64 binaries
>   arm64.csh     Builds the Oracle aarch64 binaries
>   arm.csh       Builds 32-bit ARM binaries
>
> My next step is to push this changeset into the jdk9-arm3264 forest assuming I
> achieve committer status for the aarch32 project this week.
>
> Bob Vandette
>
>
>
>

From bob.vandette at oracle.com  Wed Sep 28 18:46:21 2016
From: bob.vandette at oracle.com (Bob Vandette)
Date: Wed, 28 Sep 2016 14:46:21 -0400
Subject: [aarch64-port-dev ] Webrev of Oracle ARM & AARCH64 Sources
In-Reply-To: <CA+3eh13SxW5cA0Eh9PyHgq1RjNCnt7TNc6uQ9GfQb8u==iXU+Q@mail.gmail.com>
References: <5A08C4A6-2B69-4D29-80F5-1CE11E350283@oracle.com>
	<CA+3eh13SxW5cA0Eh9PyHgq1RjNCnt7TNc6uQ9GfQb8u==iXU+Q@mail.gmail.com>
Message-ID: <DF18F315-B45E-41E2-8FBE-9E1BB19158CF@oracle.com>


> On Sep 28, 2016, at 1:55 PM, Volker Simonis <volker.simonis at gmail.com> wrote:
> 
> Hi Bob,
> 
> congratulations! I'm pretty sure this was a pretty huge amount of
> paper and programming work to reach this point :)
> 
> My general question is how is this code contribution supposed to work
> together with the current ARM ports in the OpenJDK. Currently we have
> a full-blown, supported arm64 bit port in the jdk9 main-line
> (contributed and maintained by RedHat). The aarch32 project has a
> full-blown implementation for arm32 for jdk8u contributed by Azul.
I didn?t think the arm32 project had a C2 server VM yet?
> 
> Is your new port intended to live and be maintained alongside these
> already available ports?
At this point we are simply offering to contribute our ARM implementations to the
community and no decisions on consolidation of ports has been decided.

> Where does your port differ from the available ports in terms of
> functionality and performance?
The primary reason for putting the webrev out in the open is to allow for the
review of our implementation by the aarch32 project team.

ARM32

Our 32-bit ARM port is very mature and has been around for over 8 years.
These sources support several 32-bit ARM architecture versions including
ARMv5, ARMv6 and ARMv7 with VFP hard-float, soft-fp and full soft-float
floating point support.

Both 32 and 64 bit ARM ports support the building of the minimal, client and server 
hotspot VMs.

We also support the compilation of native binaries with thumb2.

AARCH64

Our AARCH64 bit port is fully functional and supports the same three VM combinations.

MAINTAINABILITY

As you can see from the sources, we designed the ARM ports to share as much of 
the sources for 32 and 64 bit ARM support as possible making it easier to maintain 
and add CPU specific features to hotspot.  This design philosophy is consistent with
our sparc and x86 ports.

PERFORMANCE

I have not done a performance comparison of the existing open ports. 

Note: Some of the Oracle commercial features may not be fully supported on some of the ARM platforms.

> Is Oracle committed to support the new ports?
Oracle is committed to producing 32 & 64 bit ARM binaries for at least the
JDK 9 product life cycle.  We will be producing our ARM binaries from our
closed sources for JDK 9.0.  

> And finally, do you expect to integrate these ports into JDK 9 mainline?
I would like to work with the aarch32 project team towards that goal.

Bob.


> Thanks a lot and best regards,
> Volker
> 
> 
> On Wed, Sep 28, 2016 at 4:07 PM, Bob Vandette <bob.vandette at oracle.com> wrote:
>> I?m am please to announce that I have completed our internal reviews and can now
>> open up the sources to our ARM 32 & 64 bit implementations of JDK9.
>> 
>> Here is a webrev that includes a patch that can be applied on top of the
>> (http://hg.openjdk.java.net/aarch32-port/jdk9-arm3264/ <http://hg.openjdk.java.net/aarch32-port/jdk9-arm3264/>) forest.
>> 
>>     http://cr.openjdk.java.net/~bobv/arm3264/webrev <http://cr.openjdk.java.net/~bobv/arm3264/webrev>
>> 
>> Notes:
>> 
>> 1. Counter to my initial email announcing the open sourcing effort,  the
>> pregenerated interpreter is not included in the provided patch.  AOT is
>> our long term solution for increased performance on Mobile and it was decided
>> that we do not want to support the static interpreter beyond JDK 8.
>> 
>> 2. In order to allow building the two different 64-bit ARM sources, I overloaded
>> a new configure option ?abi-profile to allow for the selection of the Oracle
>> 64-bit ARM port.  We need a better solution before this support can be
>> integrated into the mainline.  To use the Oracle sources for an aarch64 build,
>> select ?abi-profile=arm64.
>> 
>> 3. The scripts provided below allows for the creation of the minimal, client and
>> server VMs for the Oracle aarch64 build, however, the jvm.cfg file is not
>> automatically updated during the build.  To run a non server VM, this file
>> will need to be updated.
>> 
>> 4. In order to make it easier to keep the new open sources up to date with
>> their closed counterparts in jdk9, I have added a comment in
>> hotspot/src/cpu/arm/vm/vm_version_ext_arm.hpp which contains the mercurial
>> revision that I last merged with.  This will make it easier to produce patches
>> to bring the new open files up to the latest version.
>> 
>> /* ARM sources Merged up to hotspot/src/closed changeset 2316:b247a2ea70e4 */
>> 
>> Build Scripts:
>> 
>> Here are a set of scripts that demonstrate how to build the three ARM
>> configurations.  We typically cross compile our ARM builds so these
>> scripts will have to be adjusted in order to build natively on an ARM system.
>> 
>> http://cr.openjdk.java.net/~bobv/arm3264/scripts/ <http://cr.openjdk.java.net/~bobv/arm3264/scripts/>
>> 
>>  aarch64.csh   Builds the current open version of aarch64 binaries
>>  arm64.csh     Builds the Oracle aarch64 binaries
>>  arm.csh       Builds 32-bit ARM binaries
>> 
>> My next step is to push this changeset into the jdk9-arm3264 forest assuming I
>> achieve committer status for the aarch32 project this week.
>> 
>> Bob Vandette
>> 
>> 
>> 
>> 


From aph at redhat.com  Wed Sep 28 19:15:06 2016
From: aph at redhat.com (Andrew Haley)
Date: Wed, 28 Sep 2016 20:15:06 +0100
Subject: [aarch64-port-dev ] Webrev of Oracle ARM & AARCH64 Sources
In-Reply-To: <CA+3eh13SxW5cA0Eh9PyHgq1RjNCnt7TNc6uQ9GfQb8u==iXU+Q@mail.gmail.com>
References: <5A08C4A6-2B69-4D29-80F5-1CE11E350283@oracle.com>
	<CA+3eh13SxW5cA0Eh9PyHgq1RjNCnt7TNc6uQ9GfQb8u==iXU+Q@mail.gmail.com>
Message-ID: <7ea0939d-4aa1-05fc-1eac-f1da849920f4@redhat.com>

On 28/09/16 18:55, Volker Simonis wrote:
> My general question is how is this code contribution supposed to work
> together with the current ARM ports in the OpenJDK. Currently we have
> a full-blown, supported arm64 bit port in the jdk9 main-line
> (contributed and maintained by RedHat). The aarch32 project has a
> full-blown implementation for arm32 for jdk8u contributed by Azul.
> 
> Is your new port intended to live and be maintained alongside these
> already available ports?
> Where does your port differ from the available ports in terms of
> functionality and performance?
> Is Oracle committed to support the new ports?
> And finally, do you expect to integrate these port into JDK 9 mainline?

We have to decide this by consensus.  Azul seem to be happy enough to
drop their own port and work on this one from Oracle: their work is
new and rather immature, so it makes sense.  In the case of AArch64,
the situation is much less clear.  We have a fairly mature and solid
community-written (not just Red Hat!) implementation, and there's no
obvious reason to push that implementation aside.  It is the official
AArch64 port of OpenJDK.

I'll be posting more in the coming weeks.

Andrew.

From aph at redhat.com  Thu Sep 29 08:50:54 2016
From: aph at redhat.com (Andrew Haley)
Date: Thu, 29 Sep 2016 09:50:54 +0100
Subject: [aarch64-port-dev ] Webrev of Oracle ARM & AARCH64 Sources
In-Reply-To: <e52rgb4co8bb2pf7lh0jfvr2.1475090540028@email.android.com>
References: <5A08C4A6-2B69-4D29-80F5-1CE11E350283@oracle.com>
	<CA+3eh13SxW5cA0Eh9PyHgq1RjNCnt7TNc6uQ9GfQb8u==iXU+Q@mail.gmail.com>
	<7ea0939d-4aa1-05fc-1eac-f1da849920f4@redhat.com>
	<e52rgb4co8bb2pf7lh0jfvr2.1475090540028@email.android.com>
Message-ID: <36626b7a-cb53-b13b-b529-d9c43ed28d0f@redhat.com>

On 28/09/16 20:22, Kostya Zolotnikov wrote:
> 
> Not sure who told You about Azul's view.
> For us it is not that clear what make sense for You.

I'm not quite sure what you mean by this, but I can only go by what
Azul representatives have posted here.  If I've got anything wrong,
I am happy to be corrected.

Andrew.


From andrey.petushkov at gmail.com  Thu Sep 29 10:13:47 2016
From: andrey.petushkov at gmail.com (Andrey Petushkov)
Date: Thu, 29 Sep 2016 13:13:47 +0300
Subject: [aarch64-port-dev ] Webrev of Oracle ARM & AARCH64 Sources
In-Reply-To: <36626b7a-cb53-b13b-b529-d9c43ed28d0f@redhat.com>
References: <5A08C4A6-2B69-4D29-80F5-1CE11E350283@oracle.com>
	<CA+3eh13SxW5cA0Eh9PyHgq1RjNCnt7TNc6uQ9GfQb8u==iXU+Q@mail.gmail.com>
	<7ea0939d-4aa1-05fc-1eac-f1da849920f4@redhat.com>
	<e52rgb4co8bb2pf7lh0jfvr2.1475090540028@email.android.com>
	<36626b7a-cb53-b13b-b529-d9c43ed28d0f@redhat.com>
Message-ID: <9ECF7394-3D91-4A11-840C-37318CBA0CBF@gmail.com>

Dear Andrew,

Pardon, I?m too puzzled by your statement. To my best knowledge no one from Azul considers this port as immature and wishes to drop it. Nor AFAIK anyone from Azul has expressed that on the maillist. In addition, aarch32 port shares much in common with RH?s aarch64 implementation so well, if you keep aarch64 in main openjdk repos it?s much easier to merge aarch32 into it, rather than merge with Sun/Oracle?s arm implementation. And yes, aarch32 is missing c2 port, but this should not make any difference long-term, right?

Regards,
Andrey

> On 29 Sep 2016, at 11:50, Andrew Haley <aph at redhat.com> wrote:
> 
> On 28/09/16 20:22, Kostya Zolotnikov wrote:
>> 
>> Not sure who told You about Azul's view.
>> For us it is not that clear what make sense for You.
> 
> I'm not quite sure what you mean by this, but I can only go by what
> Azul representatives have posted here.  If I've got anything wrong,
> I am happy to be corrected.
> 
> Andrew.
> 


From aph at redhat.com  Thu Sep 29 10:43:36 2016
From: aph at redhat.com (Andrew Haley)
Date: Thu, 29 Sep 2016 11:43:36 +0100
Subject: [aarch64-port-dev ] Webrev of Oracle ARM & AARCH64 Sources
In-Reply-To: <9ECF7394-3D91-4A11-840C-37318CBA0CBF@gmail.com>
References: <5A08C4A6-2B69-4D29-80F5-1CE11E350283@oracle.com>
	<CA+3eh13SxW5cA0Eh9PyHgq1RjNCnt7TNc6uQ9GfQb8u==iXU+Q@mail.gmail.com>
	<7ea0939d-4aa1-05fc-1eac-f1da849920f4@redhat.com>
	<e52rgb4co8bb2pf7lh0jfvr2.1475090540028@email.android.com>
	<36626b7a-cb53-b13b-b529-d9c43ed28d0f@redhat.com>
	<9ECF7394-3D91-4A11-840C-37318CBA0CBF@gmail.com>
Message-ID: <8fa2ec4d-3f6a-7d47-72f4-cafa1964d61a@redhat.com>

On 29/09/16 11:13, Andrey Petushkov wrote:

> Pardon, I?m too puzzled by your statement. To my best knowledge no
> one from Azul considers this port as immature and wishes to drop
> it. Nor AFAIK anyone from Azul has expressed that on the
> maillist.

My mistake, then.  I should have waited for you to speak.  I
apologize.

> In addition, aarch32 port shares much in common with RH?s aarch64
> implementation so well, if you keep aarch64 in main openjdk repos
> it?s much easier to merge aarch32 into it, rather than merge with
> Sun/Oracle?s arm implementation.

There is no good technical reason for AArch64 to merge with AArch32,
and IMO it would create a mess.  AArch64 is a clean-sheet design which
shares some of its DNA with AArch32, but that is all.  It's not like
x86-64, which is a 64-bit extension of x86.

> And yes, aarch32 is missing c2 port, but this should not make any
> difference long-term, right?

I guess not, if a C2 port is forthcoming.

Andrew.

From andrey.petushkov at gmail.com  Thu Sep 29 10:54:07 2016
From: andrey.petushkov at gmail.com (Andrey Petushkov)
Date: Thu, 29 Sep 2016 13:54:07 +0300
Subject: [aarch64-port-dev ] Webrev of Oracle ARM & AARCH64 Sources
In-Reply-To: <8fa2ec4d-3f6a-7d47-72f4-cafa1964d61a@redhat.com>
References: <5A08C4A6-2B69-4D29-80F5-1CE11E350283@oracle.com>
	<CA+3eh13SxW5cA0Eh9PyHgq1RjNCnt7TNc6uQ9GfQb8u==iXU+Q@mail.gmail.com>
	<7ea0939d-4aa1-05fc-1eac-f1da849920f4@redhat.com>
	<e52rgb4co8bb2pf7lh0jfvr2.1475090540028@email.android.com>
	<36626b7a-cb53-b13b-b529-d9c43ed28d0f@redhat.com>
	<9ECF7394-3D91-4A11-840C-37318CBA0CBF@gmail.com>
	<8fa2ec4d-3f6a-7d47-72f4-cafa1964d61a@redhat.com>
Message-ID: <15B7B9FF-A282-4687-B847-ED17B0F7AC0E@gmail.com>


> On 29 Sep 2016, at 13:43, Andrew Haley <aph at redhat.com> wrote:
> 
> On 29/09/16 11:13, Andrey Petushkov wrote:
> 
>> Pardon, I?m too puzzled by your statement. To my best knowledge no
>> one from Azul considers this port as immature and wishes to drop
>> it. Nor AFAIK anyone from Azul has expressed that on the
>> maillist.
> 
> My mistake, then.  I should have waited for you to speak.  I
> apologize.
> 
>> In addition, aarch32 port shares much in common with RH?s aarch64
>> implementation so well, if you keep aarch64 in main openjdk repos
>> it?s much easier to merge aarch32 into it, rather than merge with
>> Sun/Oracle?s arm implementation.
> 
> There is no good technical reason for AArch64 to merge with AArch32,
> and IMO it would create a mess.  AArch64 is a clean-sheet design which
> shares some of its DNA with AArch32, but that is all.  It's not like
> x86-64, which is a 64-bit extension of x86.
Well, it?s AArch32 which is not clean-sheet design but rather borrows from AArch64 :)
I admit that there are much more difference between architectures than for x86 so you might be right that the difference in the code could be too big. I just have a feeling it?s not. I can mistake of course, I did not diff specifically
> 
>> And yes, aarch32 is missing c2 port, but this should not make any
>> difference long-term, right?
> 
> I guess not, if a C2 port is forthcoming.
My idea here that Oracle?s Graal can make c2 obsolete and it might not worth to port c2 only for Java 9

Andrey
> 
> Andrew.


From aph at redhat.com  Thu Sep 29 11:04:26 2016
From: aph at redhat.com (Andrew Haley)
Date: Thu, 29 Sep 2016 12:04:26 +0100
Subject: [aarch64-port-dev ] Webrev of Oracle ARM & AARCH64 Sources
In-Reply-To: <15B7B9FF-A282-4687-B847-ED17B0F7AC0E@gmail.com>
References: <5A08C4A6-2B69-4D29-80F5-1CE11E350283@oracle.com>
	<CA+3eh13SxW5cA0Eh9PyHgq1RjNCnt7TNc6uQ9GfQb8u==iXU+Q@mail.gmail.com>
	<7ea0939d-4aa1-05fc-1eac-f1da849920f4@redhat.com>
	<e52rgb4co8bb2pf7lh0jfvr2.1475090540028@email.android.com>
	<36626b7a-cb53-b13b-b529-d9c43ed28d0f@redhat.com>
	<9ECF7394-3D91-4A11-840C-37318CBA0CBF@gmail.com>
	<8fa2ec4d-3f6a-7d47-72f4-cafa1964d61a@redhat.com>
	<15B7B9FF-A282-4687-B847-ED17B0F7AC0E@gmail.com>
Message-ID: <91d5a8c4-26e8-13a5-d45f-1f24be595361@redhat.com>

On 29/09/16 11:54, Andrey Petushkov wrote:
> 
>> On 29 Sep 2016, at 13:43, Andrew Haley <aph at redhat.com> wrote:
>>
>> On 29/09/16 11:13, Andrey Petushkov wrote:
>>
>>> In addition, aarch32 port shares much in common with RH?s aarch64
>>> implementation so well, if you keep aarch64 in main openjdk repos
>>> it?s much easier to merge aarch32 into it, rather than merge with
>>> Sun/Oracle?s arm implementation.
>>
>> There is no good technical reason for AArch64 to merge with AArch32,
>> and IMO it would create a mess.  AArch64 is a clean-sheet design which
>> shares some of its DNA with AArch32, but that is all.  It's not like
>> x86-64, which is a 64-bit extension of x86.
>
> Well, it?s AArch32 which is not clean-sheet design but rather
> borrows from AArch64 :)

I meant to say: the AArch64 hardware architecture is a clean-sheet
design which shares some of its DNA with AArch32, but that is all.

> I admit that there are much more difference between architectures
> than for x86 so you might be right that the difference in the code
> could be too big. I just have a feeling it?s not. I can mistake of
> course, I did not diff specifically

Possibly.  I don't really want to make the port a mess of #ifdefs and
suchlike, so I'd fight pretty hard against it.

It is possible to do some macro trickery to write common runtime
routines, but with sufficient such trickery it'd be possible to do
that with any two unrelated arches.  While it might save some time, it
adds another layer of complexity and makes it harder to write
efficient and idiomatic code.  In particular things such as predicated
instructions, which are an important part of the AArch32 ISA, are
absent on AArch64.

Andrew.

From andrey.petushkov at gmail.com  Thu Sep 29 11:10:29 2016
From: andrey.petushkov at gmail.com (Andrey Petushkov)
Date: Thu, 29 Sep 2016 14:10:29 +0300
Subject: [aarch64-port-dev ] Webrev of Oracle ARM & AARCH64 Sources
In-Reply-To: <91d5a8c4-26e8-13a5-d45f-1f24be595361@redhat.com>
References: <5A08C4A6-2B69-4D29-80F5-1CE11E350283@oracle.com>
	<CA+3eh13SxW5cA0Eh9PyHgq1RjNCnt7TNc6uQ9GfQb8u==iXU+Q@mail.gmail.com>
	<7ea0939d-4aa1-05fc-1eac-f1da849920f4@redhat.com>
	<e52rgb4co8bb2pf7lh0jfvr2.1475090540028@email.android.com>
	<36626b7a-cb53-b13b-b529-d9c43ed28d0f@redhat.com>
	<9ECF7394-3D91-4A11-840C-37318CBA0CBF@gmail.com>
	<8fa2ec4d-3f6a-7d47-72f4-cafa1964d61a@redhat.com>
	<15B7B9FF-A282-4687-B847-ED17B0F7AC0E@gmail.com>
	<91d5a8c4-26e8-13a5-d45f-1f24be595361@redhat.com>
Message-ID: <8441C732-88C4-4D7C-A6CA-3FB06C20FB55@gmail.com>


> On 29 Sep 2016, at 14:04, Andrew Haley <aph at redhat.com> wrote:
> 
> On 29/09/16 11:54, Andrey Petushkov wrote:
>> 
>>> On 29 Sep 2016, at 13:43, Andrew Haley <aph at redhat.com> wrote:
>>> 
>>> On 29/09/16 11:13, Andrey Petushkov wrote:
>>> 
>>>> In addition, aarch32 port shares much in common with RH?s aarch64
>>>> implementation so well, if you keep aarch64 in main openjdk repos
>>>> it?s much easier to merge aarch32 into it, rather than merge with
>>>> Sun/Oracle?s arm implementation.
>>> 
>>> There is no good technical reason for AArch64 to merge with AArch32,
>>> and IMO it would create a mess.  AArch64 is a clean-sheet design which
>>> shares some of its DNA with AArch32, but that is all.  It's not like
>>> x86-64, which is a 64-bit extension of x86.
>> 
>> Well, it?s AArch32 which is not clean-sheet design but rather
>> borrows from AArch64 :)
> 
> I meant to say: the AArch64 hardware architecture is a clean-sheet
> design which shares some of its DNA with AArch32, but that is all.
Ok, git it. Sorry for misunderstanding
> 
>> I admit that there are much more difference between architectures
>> than for x86 so you might be right that the difference in the code
>> could be too big. I just have a feeling it?s not. I can mistake of
>> course, I did not diff specifically
> 
> Possibly.  I don't really want to make the port a mess of #ifdefs and
> suchlike, so I'd fight pretty hard against it.
> 
> It is possible to do some macro trickery to write common runtime
> routines, but with sufficient such trickery it'd be possible to do
> that with any two unrelated arches.  While it might save some time, it
> adds another layer of complexity and makes it harder to write
> efficient and idiomatic code.  In particular things such as predicated
> instructions, which are an important part of the AArch32 ISA, are
> absent on AArch64.
Very much possible. I don?t want to propose it now, was just mentioning the probability. Ok it?s low, let?s dismiss it
> 
> Andrew.


From bob.vandette at oracle.com  Thu Sep 29 12:33:32 2016
From: bob.vandette at oracle.com (Bob Vandette)
Date: Thu, 29 Sep 2016 08:33:32 -0400
Subject: [aarch64-port-dev ] Webrev of Oracle ARM & AARCH64 Sources
In-Reply-To: <8441C732-88C4-4D7C-A6CA-3FB06C20FB55@gmail.com>
References: <5A08C4A6-2B69-4D29-80F5-1CE11E350283@oracle.com>
	<CA+3eh13SxW5cA0Eh9PyHgq1RjNCnt7TNc6uQ9GfQb8u==iXU+Q@mail.gmail.com>
	<7ea0939d-4aa1-05fc-1eac-f1da849920f4@redhat.com>
	<e52rgb4co8bb2pf7lh0jfvr2.1475090540028@email.android.com>
	<36626b7a-cb53-b13b-b529-d9c43ed28d0f@redhat.com>
	<9ECF7394-3D91-4A11-840C-37318CBA0CBF@gmail.com>
	<8fa2ec4d-3f6a-7d47-72f4-cafa1964d61a@redhat.com>
	<15B7B9FF-A282-4687-B847-ED17B0F7AC0E@gmail.com>
	<91d5a8c4-26e8-13a5-d45f-1f24be595361@redhat.com>
	<8441C732-88C4-4D7C-A6CA-3FB06C20FB55@gmail.com>
Message-ID: <7F31BDA8-F324-4CAB-826D-D3054EE8CE43@oracle.com>


> On Sep 29, 2016, at 7:10 AM, Andrey Petushkov <andrey.petushkov at gmail.com> wrote:
> 
> 
>> On 29 Sep 2016, at 14:04, Andrew Haley <aph at redhat.com> wrote:
>> 
>> On 29/09/16 11:54, Andrey Petushkov wrote:
>>> 
>>>> On 29 Sep 2016, at 13:43, Andrew Haley <aph at redhat.com> wrote:
>>>> 
>>>> On 29/09/16 11:13, Andrey Petushkov wrote:
>>>> 
>>>>> In addition, aarch32 port shares much in common with RH?s aarch64
>>>>> implementation so well, if you keep aarch64 in main openjdk repos
>>>>> it?s much easier to merge aarch32 into it, rather than merge with
>>>>> Sun/Oracle?s arm implementation.
>>>> 
>>>> There is no good technical reason for AArch64 to merge with AArch32,
>>>> and IMO it would create a mess.  AArch64 is a clean-sheet design which
>>>> shares some of its DNA with AArch32, but that is all.  It's not like
>>>> x86-64, which is a 64-bit extension of x86.
>>> 
>>> Well, it?s AArch32 which is not clean-sheet design but rather
>>> borrows from AArch64 :)
>> 
>> I meant to say: the AArch64 hardware architecture is a clean-sheet
>> design which shares some of its DNA with AArch32, but that is all.
> Ok, git it. Sorry for misunderstanding
>> 
>>> I admit that there are much more difference between architectures
>>> than for x86 so you might be right that the difference in the code
>>> could be too big. I just have a feeling it?s not. I can mistake of
>>> course, I did not diff specifically
>> 
>> Possibly.  I don't really want to make the port a mess of #ifdefs and
>> suchlike, so I'd fight pretty hard against it.
>> 
>> It is possible to do some macro trickery to write common runtime
>> routines, but with sufficient such trickery it'd be possible to do
>> that with any two unrelated arches.  While it might save some time, it
>> adds another layer of complexity and makes it harder to write
>> efficient and idiomatic code.  In particular things such as predicated
>> instructions, which are an important part of the AArch32 ISA, are
>> absent on AArch64.
> Very much possible. I don?t want to propose it now, was just mentioning the probability. Ok it?s low, let?s dismiss it
It is more that just possible.  I have provided you with an implementation that does just that.  
I don?t think you should be so fast to dismiss it.  

Bob.

>> 
>> Andrew.
> 


From edward.nevill at gmail.com  Fri Sep 30 10:32:01 2016
From: edward.nevill at gmail.com (Edward Nevill)
Date: Fri, 30 Sep 2016 11:32:01 +0100
Subject: [aarch64-port-dev ] Webrev of Oracle ARM & AARCH64 Sources
In-Reply-To: <5A08C4A6-2B69-4D29-80F5-1CE11E350283@oracle.com>
References: <5A08C4A6-2B69-4D29-80F5-1CE11E350283@oracle.com>
Message-ID: <1475231521.14313.29.camel@gmail.com>

Hi Bob,

On Wed, 2016-09-28 at 10:07 -0400, Bob Vandette wrote:
> I?m am please to announce that I have completed our internal reviews and can now
> open up the sources to our ARM 32 & 64 bit implementations of JDK9.

Great news.

> 
> Here is a webrev that includes a patch that can be applied on top of the
> (http://hg.openjdk.java.net/aarch32-port/jdk9-arm3264/ ) forest.??
> 
> ?????http://cr.openjdk.java.net/~bobv/arm3264/webrev <http://cr.openjdk.java.net/~bobv/arm3264/webrev>

I have built this natively on armv7 and aarch64 without problems. In both cases I built the minimal,client,server combination.

I have also tested the server build with JTreg hotspot & langtools.

On aarch64 I got the following results:-

hotspot: Test results: passed: 1,280; failed: 8; error: 43
langtools: Test results: passed: 3,700; failed: 1; error: 29

This is fairly typical, for example, using the Linaro 1609 build I get

hotspot: Test results: passed: 1,271; failed: 17; error: 43
langtools: Test results: passed: 3,715; failed: 3; error: 12

On armv7 I first of all had to pin the jvm.cfg to use -server as it kept on using the client as I was not running on a 'server class machine' (since my armv7 device is a Samsung Chromebook this is fair enough).

However, I then had problems with the test harness crashing with the error

#??Internal Error (synchronizer.cpp:1576), pid=6533, tid=6542
#??guarantee(mid->header()->is_neutral()) failed: invariant

(hs_err here?http://cr.openjdk.java.net/~enevill/aarch32/hs_err_pid6533.log)

On a subsequent run the test harness locked up after 85 tests.

It looks like there might be a problem with locks breaking with G1GC. I will keep investigating.

I ran it again using the template interpreter for the test harness and the server for the jdk under test and it ran successfully.

On armv7 I got

hotspot: Test results: passed: 1,202; failed: 11; error: 36
langtools: Test results: passed: 3,718; failed: 5; error: 8

I also did some limited benchmarking which I am not going to share on a public forum. Lets just say the performance of the server JIT on armv7 was pleasing.

Thanks for all your work getting to this stage. It looks good to push and you should shortly have committeer rights, if you don't get them within a few days ping me and I will give ops a nudge.

All the best,
Ed.



From david.holmes at oracle.com  Fri Sep 30 11:23:30 2016
From: david.holmes at oracle.com (David Holmes)
Date: Fri, 30 Sep 2016 21:23:30 +1000
Subject: [aarch64-port-dev ] Webrev of Oracle ARM & AARCH64 Sources
In-Reply-To: <1475231521.14313.29.camel@gmail.com>
References: <5A08C4A6-2B69-4D29-80F5-1CE11E350283@oracle.com>
	<1475231521.14313.29.camel@gmail.com>
Message-ID: <187f08d2-2f6d-a4f6-8662-7e8ac85308f7@oracle.com>

Hi Ed,

On 30/09/2016 8:32 PM, Edward Nevill wrote:
> Hi Bob,
>
> On Wed, 2016-09-28 at 10:07 -0400, Bob Vandette wrote:
>> I?m am please to announce that I have completed our internal reviews and can now
>> open up the sources to our ARM 32 & 64 bit implementations of JDK9.
>
> Great news.
>
>>
>> Here is a webrev that includes a patch that can be applied on top of the
>> (http://hg.openjdk.java.net/aarch32-port/jdk9-arm3264/ ) forest.
>>
>>      http://cr.openjdk.java.net/~bobv/arm3264/webrev <http://cr.openjdk.java.net/~bobv/arm3264/webrev>
>
> I have built this natively on armv7 and aarch64 without problems. In both cases I built the minimal,client,server combination.
>
> I have also tested the server build with JTreg hotspot & langtools.
>
> On aarch64 I got the following results:-
>
> hotspot: Test results: passed: 1,280; failed: 8; error: 43
> langtools: Test results: passed: 3,700; failed: 1; error: 29
>
> This is fairly typical, for example, using the Linaro 1609 build I get
>
> hotspot: Test results: passed: 1,271; failed: 17; error: 43
> langtools: Test results: passed: 3,715; failed: 3; error: 12

So most of the "errors" are probably tests that are ignored.

> On armv7 I first of all had to pin the jvm.cfg to use -server as it kept on using the client as I was not running on a 'server class machine' (since my armv7 device is a Samsung Chromebook this is fair enough).
>
> However, I then had problems with the test harness crashing with the error
>
> #  Internal Error (synchronizer.cpp:1576), pid=6533, tid=6542
> #  guarantee(mid->header()->is_neutral()) failed: invariant
>
> (hs_err here http://cr.openjdk.java.net/~enevill/aarch32/hs_err_pid6533.log)

Strange - that looks like our closed bug:

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

which should be fixed. It was a missing memory barrier issue.

Aside: we're going to have to figure out how to deal with currently 
closed bug reports.

David
-----

> On a subsequent run the test harness locked up after 85 tests.
>
> It looks like there might be a problem with locks breaking with G1GC. I will keep investigating.
>
> I ran it again using the template interpreter for the test harness and the server for the jdk under test and it ran successfully.
>
> On armv7 I got
>
> hotspot: Test results: passed: 1,202; failed: 11; error: 36
> langtools: Test results: passed: 3,718; failed: 5; error: 8
>
> I also did some limited benchmarking which I am not going to share on a public forum. Lets just say the performance of the server JIT on armv7 was pleasing.
>
> Thanks for all your work getting to this stage. It looks good to push and you should shortly have committeer rights, if you don't get them within a few days ping me and I will give ops a nudge.
>
> All the best,
> Ed.
>
>

From aph at redhat.com  Fri Sep 30 13:25:33 2016
From: aph at redhat.com (Andrew Haley)
Date: Fri, 30 Sep 2016 14:25:33 +0100
Subject: [aarch64-port-dev ] Webrev of Oracle ARM & AARCH64 Sources
In-Reply-To: <5A08C4A6-2B69-4D29-80F5-1CE11E350283@oracle.com>
References: <5A08C4A6-2B69-4D29-80F5-1CE11E350283@oracle.com>
Message-ID: <5feeb9a0-b4cf-5536-97cf-8e9b6f87ffe4@redhat.com>

On 28/09/16 15:07, Bob Vandette wrote:
> I?m am please to announce that I have completed our internal reviews and can now
> open up the sources to our ARM 32 & 64 bit implementations of JDK9.
> 
> Here is a webrev that includes a patch that can be applied on top of the
> (http://hg.openjdk.java.net/aarch32-port/jdk9-arm3264/ <http://hg.openjdk.java.net/aarch32-port/jdk9-arm3264/>) forest.  
> 
>      http://cr.openjdk.java.net/~bobv/arm3264/webrev <http://cr.openjdk.java.net/~bobv/arm3264/webrev>

I had to make this change to prevent an AARch64 assert in debug builds:

diff --git a/src/cpu/arm/vm/stubGenerator_arm.cpp b/src/cpu/arm/vm/stubGenerator_arm.cpp
--- a/src/cpu/arm/vm/stubGenerator_arm.cpp
+++ b/src/cpu/arm/vm/stubGenerator_arm.cpp
@@ -4450,6 +4450,12 @@
     StubRoutines::_throw_AbstractMethodError_entry         = generate_throw_exception("AbstractMethodError throw_exception",          CAST_FROM_FN_PTR(address, SharedRuntime::throw_AbstractMethodError));
     StubRoutines::_throw_NullPointerException_at_call_entry= generate_throw_exception("NullPointerException at call throw_exception", CAST_FROM_FN_PTR(address, SharedRuntime::throw_NullPointerException_at_call));

+    StubRoutines::_throw_IncompatibleClassChangeError_entry =
+      generate_throw_exception("IncompatibleClassChangeError throw_exception",
+                               CAST_FROM_FN_PTR(address,
+                                                SharedRuntime::
+                                                throw_IncompatibleClassChangeError));
+
     //------------------------------------------------------------------------------------------------------------------------
     // entry points that are platform specific

Andrew.


From bob.vandette at oracle.com  Fri Sep 30 13:33:02 2016
From: bob.vandette at oracle.com (Bob Vandette)
Date: Fri, 30 Sep 2016 09:33:02 -0400
Subject: [aarch64-port-dev ] Webrev of Oracle ARM & AARCH64 Sources
In-Reply-To: <5feeb9a0-b4cf-5536-97cf-8e9b6f87ffe4@redhat.com>
References: <5A08C4A6-2B69-4D29-80F5-1CE11E350283@oracle.com>
	<5feeb9a0-b4cf-5536-97cf-8e9b6f87ffe4@redhat.com>
Message-ID: <24DCD61A-68AC-482C-90E2-8151DFE4858F@oracle.com>

That was my fault.  I botched the removal of some conditional code.
I?ll fix that when I push to jdk9-arm3264.

Bob.

> On Sep 30, 2016, at 9:25 AM, Andrew Haley <aph at redhat.com> wrote:
> 
> On 28/09/16 15:07, Bob Vandette wrote:
>> I?m am please to announce that I have completed our internal reviews and can now
>> open up the sources to our ARM 32 & 64 bit implementations of JDK9.
>> 
>> Here is a webrev that includes a patch that can be applied on top of the
>> (http://hg.openjdk.java.net/aarch32-port/jdk9-arm3264/ <http://hg.openjdk.java.net/aarch32-port/jdk9-arm3264/>) forest.  
>> 
>>     http://cr.openjdk.java.net/~bobv/arm3264/webrev <http://cr.openjdk.java.net/~bobv/arm3264/webrev>
> 
> I had to make this change to prevent an AARch64 assert in debug builds:
> 
> diff --git a/src/cpu/arm/vm/stubGenerator_arm.cpp b/src/cpu/arm/vm/stubGenerator_arm.cpp
> --- a/src/cpu/arm/vm/stubGenerator_arm.cpp
> +++ b/src/cpu/arm/vm/stubGenerator_arm.cpp
> @@ -4450,6 +4450,12 @@
>     StubRoutines::_throw_AbstractMethodError_entry         = generate_throw_exception("AbstractMethodError throw_exception",          CAST_FROM_FN_PTR(address, SharedRuntime::throw_AbstractMethodError));
>     StubRoutines::_throw_NullPointerException_at_call_entry= generate_throw_exception("NullPointerException at call throw_exception", CAST_FROM_FN_PTR(address, SharedRuntime::throw_NullPointerException_at_call));
> 
> +    StubRoutines::_throw_IncompatibleClassChangeError_entry =
> +      generate_throw_exception("IncompatibleClassChangeError throw_exception",
> +                               CAST_FROM_FN_PTR(address,
> +                                                SharedRuntime::
> +                                                throw_IncompatibleClassChangeError));
> +
>     //------------------------------------------------------------------------------------------------------------------------
>     // entry points that are platform specific
> 
> Andrew.
> 


From bob.vandette at oracle.com  Fri Sep 30 13:58:55 2016
From: bob.vandette at oracle.com (Bob Vandette)
Date: Fri, 30 Sep 2016 09:58:55 -0400
Subject: [aarch64-port-dev ] Webrev of Oracle ARM & AARCH64 Sources
In-Reply-To: <187f08d2-2f6d-a4f6-8662-7e8ac85308f7@oracle.com>
References: <5A08C4A6-2B69-4D29-80F5-1CE11E350283@oracle.com>
	<1475231521.14313.29.camel@gmail.com>
	<187f08d2-2f6d-a4f6-8662-7e8ac85308f7@oracle.com>
Message-ID: <7561C178-318F-47D1-B22D-CEB73F4E2F7A@oracle.com>


> On Sep 30, 2016, at 7:23 AM, David Holmes <David.Holmes at oracle.com> wrote:
> 
> Hi Ed,
> 
> On 30/09/2016 8:32 PM, Edward Nevill wrote:
>> Hi Bob,
>> 
>> On Wed, 2016-09-28 at 10:07 -0400, Bob Vandette wrote:
>>> I?m am please to announce that I have completed our internal reviews and can now
>>> open up the sources to our ARM 32 & 64 bit implementations of JDK9.
>> 
>> Great news.
>> 
>>> 
>>> Here is a webrev that includes a patch that can be applied on top of the
>>> (http://hg.openjdk.java.net/aarch32-port/jdk9-arm3264/ ) forest.
>>> 
>>>     http://cr.openjdk.java.net/~bobv/arm3264/webrev <http://cr.openjdk.java.net/~bobv/arm3264/webrev>
>> 
>> I have built this natively on armv7 and aarch64 without problems. In both cases I built the minimal,client,server combination.
>> 
>> I have also tested the server build with JTreg hotspot & langtools.
>> 
>> On aarch64 I got the following results:-
>> 
>> hotspot: Test results: passed: 1,280; failed: 8; error: 43
>> langtools: Test results: passed: 3,700; failed: 1; error: 29
>> 
>> This is fairly typical, for example, using the Linaro 1609 build I get
>> 
>> hotspot: Test results: passed: 1,271; failed: 17; error: 43
>> langtools: Test results: passed: 3,715; failed: 3; error: 12
> 
> So most of the "errors" are probably tests that are ignored.
> 
>> On armv7 I first of all had to pin the jvm.cfg to use -server as it kept on using the client as I was not running on a 'server class machine' (since my armv7 device is a Samsung Chromebook this is fair enough).
>> 
>> However, I then had problems with the test harness crashing with the error
>> 
>> #  Internal Error (synchronizer.cpp:1576), pid=6533, tid=6542
>> #  guarantee(mid->header()->is_neutral()) failed: invariant
>> 
>> (hs_err here http://cr.openjdk.java.net/~enevill/aarch32/hs_err_pid6533.log)
> 
> Strange - that looks like our closed bug:
> 
> https://bugs.openjdk.java.net/browse/JDK-8071540
> 
> which should be fixed. It was a missing memory barrier issue.

I checked and this fix was applied but later a newer implementation
was added.  The memory barriers were moved to cas_for_lock_acquire
with optimized versions for aarch64.

Be aware that G1 support on 32-bit ARM is not fully supported by the GC team.
It?s experimental.  This means that there was an attempt to implement it but it
has not undergone the same level of testing as other platforms.  I?ll forward this
issue to the GC team.

Bob.


> 
> Aside: we're going to have to figure out how to deal with currently closed bug reports.
> 
> David
> -----
> 
>> On a subsequent run the test harness locked up after 85 tests.
>> 
>> It looks like there might be a problem with locks breaking with G1GC. I will keep investigating.
>> 
>> I ran it again using the template interpreter for the test harness and the server for the jdk under test and it ran successfully.
>> 
>> On armv7 I got
>> 
>> hotspot: Test results: passed: 1,202; failed: 11; error: 36
>> langtools: Test results: passed: 3,718; failed: 5; error: 8
>> 
>> I also did some limited benchmarking which I am not going to share on a public forum. Lets just say the performance of the server JIT on armv7 was pleasing.
>> 
>> Thanks for all your work getting to this stage. It looks good to push and you should shortly have committeer rights, if you don't get them within a few days ping me and I will give ops a nudge.
>> 
>> All the best,
>> Ed.
>> 
>> 


From bob.vandette at oracle.com  Fri Sep 30 14:03:10 2016
From: bob.vandette at oracle.com (Bob Vandette)
Date: Fri, 30 Sep 2016 10:03:10 -0400
Subject: [aarch64-port-dev ] Webrev of Oracle ARM & AARCH64 Sources
In-Reply-To: <1475231521.14313.29.camel@gmail.com>
References: <5A08C4A6-2B69-4D29-80F5-1CE11E350283@oracle.com>
	<1475231521.14313.29.camel@gmail.com>
Message-ID: <25E205BE-9EE9-488A-9D08-DED365288D7F@oracle.com>

Ed,

Could you try the 32-bit ARM binaries from the early access page to see if the
G1GC problem reproduces? 

https://jdk9.java.net/download/ <https://jdk9.java.net/download/>

Bob.

> On Sep 30, 2016, at 6:32 AM, Edward Nevill <edward.nevill at gmail.com> wrote:
> 
> Hi Bob,
> 
> On Wed, 2016-09-28 at 10:07 -0400, Bob Vandette wrote:
>> I?m am please to announce that I have completed our internal reviews and can now
>> open up the sources to our ARM 32 & 64 bit implementations of JDK9.
> 
> Great news.
> 
>> 
>> Here is a webrev that includes a patch that can be applied on top of the
>> (http://hg.openjdk.java.net/aarch32-port/jdk9-arm3264/ ) forest.  
>> 
>>      http://cr.openjdk.java.net/~bobv/arm3264/webrev <http://cr.openjdk.java.net/~bobv/arm3264/webrev>
> 
> I have built this natively on armv7 and aarch64 without problems. In both cases I built the minimal,client,server combination.
> 
> I have also tested the server build with JTreg hotspot & langtools.
> 
> On aarch64 I got the following results:-
> 
> hotspot: Test results: passed: 1,280; failed: 8; error: 43
> langtools: Test results: passed: 3,700; failed: 1; error: 29
> 
> This is fairly typical, for example, using the Linaro 1609 build I get
> 
> hotspot: Test results: passed: 1,271; failed: 17; error: 43
> langtools: Test results: passed: 3,715; failed: 3; error: 12
> 
> On armv7 I first of all had to pin the jvm.cfg to use -server as it kept on using the client as I was not running on a 'server class machine' (since my armv7 device is a Samsung Chromebook this is fair enough).
> 
> However, I then had problems with the test harness crashing with the error
> 
> #  Internal Error (synchronizer.cpp:1576), pid=6533, tid=6542
> #  guarantee(mid->header()->is_neutral()) failed: invariant
> 
> (hs_err here http://cr.openjdk.java.net/~enevill/aarch32/hs_err_pid6533.log)
> 
> On a subsequent run the test harness locked up after 85 tests.
> 
> It looks like there might be a problem with locks breaking with G1GC. I will keep investigating.
> 
> I ran it again using the template interpreter for the test harness and the server for the jdk under test and it ran successfully.
> 
> On armv7 I got
> 
> hotspot: Test results: passed: 1,202; failed: 11; error: 36
> langtools: Test results: passed: 3,718; failed: 5; error: 8
> 
> I also did some limited benchmarking which I am not going to share on a public forum. Lets just say the performance of the server JIT on armv7 was pleasing.
> 
> Thanks for all your work getting to this stage. It looks good to push and you should shortly have committeer rights, if you don't get them within a few days ping me and I will give ops a nudge.
> 
> All the best,
> Ed.
> 
>