From adinn at redhat.com  Wed Apr  1 14:09:49 2015
From: adinn at redhat.com (Andrew Dinn)
Date: Wed, 01 Apr 2015 15:09:49 +0100
Subject: [aarch64-port-dev ] Proposed patch for C2 volatile generation
 (resent)
In-Reply-To: <551ACD21.4070608@redhat.com>
References: <55158471.4050009@redhat.com>
	<5515916D.9010703@redhat.com>	<551912F2.4020204@redhat.com>
	<551ACD21.4070608@redhat.com>
Message-ID: <551BFC2D.8080601@redhat.com>

Apologies, the last note included the original rather than the updated
patch.

Attached this time is the latest work in progress -- a slight advance on
the one I was meant to send.

  it modifies the unnecessary_volatile rule to generate a dmb when
UseBarriersForVolatile is true

 it allows for an optional MemBarCPUOrder in the volatile write signature

 it provides two extra predicates needed to avoid generation of
ldar/stlr unless we see the volatile read/write signatures

n.b. The two new predicates are still only stubs in this version. They
don't yet recognise when an unordered store belongs to something other
than a non-volatile load. I should have a complete version ready later
today.

Also, I still need to deal with

  the possibility of a MemBarCPUOrder between the LoadX and
MemBarCPUOVolatile when an unsafe volatile read is inlined

  the possibility of an if-else-then store pair rather than a simple
store in the middle of a volatile write.

regards,


Andrew Dinn
-----------

-------------- next part --------------
A non-text attachment was scrubbed...
Name: 7991.patch
Type: text/x-patch
Size: 27888 bytes
Desc: not available
URL: <http://mail.openjdk.java.net/pipermail/aarch64-port-dev/attachments/20150401/6f195f36/7991-0001.patch>

From adinn at redhat.com  Wed Apr  1 15:45:25 2015
From: adinn at redhat.com (Andrew Dinn)
Date: Wed, 01 Apr 2015 16:45:25 +0100
Subject: [aarch64-port-dev ] Proposed patch for C2 volatile generation
 (resent)
In-Reply-To: <551BFC2D.8080601@redhat.com>
References: <55158471.4050009@redhat.com>	<5515916D.9010703@redhat.com>	<551912F2.4020204@redhat.com>	<551ACD21.4070608@redhat.com>
	<551BFC2D.8080601@redhat.com>
Message-ID: <551C1295.2040809@redhat.com>

Here is a further update.

This time predicates needs_acquiring_load and needs-releasing_store are
fully implemented. That means we should now:

  only generate an ldar<x> when we elide the membar acquire for a
volatile load

  only generate an stlr<x> when we elide the membar release/volatile for
a volatile store

I have checked this for several inlined cases where acquire and release
membars are generated (e.g. Unsafe.getAndSetInt) and it correctly uses
ldr<x> and stlr<x> along with dmbs for those cases while still inserting
ldar<x> and stlr<x> for the volatile cases.

Next step is to add special case handling for the extra MemBarCPUOrder
added when an unsafe volatile read is inlined. I'll validate that
against netbeans before dealing with the if-then-else store pair which
arises with inlined unsafe volatile object writes.

regards,


Andrew Dinn
-----------
Senior Principal Software Engineer
Red Hat UK Ltd
Registered in UK and Wales under Company Registration No. 3798903
Directors: Michael Cunningham (USA), Matt Parson (USA), Charlie Peters
(USA), Michael O'Neill (Ireland)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 7991.patch
Type: text/x-patch
Size: 30789 bytes
Desc: not available
URL: <http://mail.openjdk.java.net/pipermail/aarch64-port-dev/attachments/20150401/1a67f909/7991-0001.patch>

From edward.nevill at linaro.org  Wed Apr  1 16:28:04 2015
From: edward.nevill at linaro.org (Edward Nevill)
Date: Wed, 01 Apr 2015 17:28:04 +0100
Subject: [aarch64-port-dev ] RFR: AARCH64: jdk9 fails to build from source
Message-ID: <1427905684.1631.12.camel@mylittlepony.linaroharston>

Hi,

The following webrev fixes a build failure in jdk9/aarch64

http://cr.openjdk.java.net/~enevill/8076488/webrev/

Issue report here

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

Please review and push if appropriate.

Thanks,
Ed.



From vladimir.kozlov at oracle.com  Wed Apr  1 17:51:09 2015
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Wed, 01 Apr 2015 10:51:09 -0700
Subject: [aarch64-port-dev ] RFR: 8076488: AARCH64: jdk9 fails to build
	from source
In-Reply-To: <1427905684.1631.12.camel@mylittlepony.linaroharston>
References: <1427905684.1631.12.camel@mylittlepony.linaroharston>
Message-ID: <551C300D.2090005@oracle.com>

Looks good to me.

Edward, please, include bug id into mail's Subject (I added it this time).

Thanks,
Vladimir

On 4/1/15 9:28 AM, Edward Nevill wrote:
> Hi,
>
> The following webrev fixes a build failure in jdk9/aarch64
>
> http://cr.openjdk.java.net/~enevill/8076488/webrev/
>
> Issue report here
>
> https://bugs.openjdk.java.net/browse/JDK-8076488
>
> Please review and push if appropriate.
>
> Thanks,
> Ed.
>
>

From aph at redhat.com  Thu Apr  2 09:27:51 2015
From: aph at redhat.com (Andrew Haley)
Date: Thu, 02 Apr 2015 10:27:51 +0100
Subject: [aarch64-port-dev ] RFR: 8075860: aarch64: jdk9/dev fails to
	build
In-Reply-To: <5512F192.9060401@oracle.com>
References: <1427275648.7353.8.camel@mylittlepony.linaroharston>
	<5512F192.9060401@oracle.com>
Message-ID: <551D0B97.2010608@redhat.com>

On 03/25/2015 05:34 PM, Vladimir Kozlov wrote:
> Looks good.
> 
> It is in JPRT queue for push.

I don't see it.  What happened?

Thanks,
Andrew.


From vladimir.kozlov at oracle.com  Thu Apr  2 16:21:03 2015
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Thu, 02 Apr 2015 09:21:03 -0700
Subject: [aarch64-port-dev ] RFR: 8075860: aarch64: jdk9/dev fails to
	build
In-Reply-To: <551D0B97.2010608@redhat.com>
References: <1427275648.7353.8.camel@mylittlepony.linaroharston>
	<5512F192.9060401@oracle.com> <551D0B97.2010608@redhat.com>
Message-ID: <551D6C6F.3090401@oracle.com>

I accidentally pushed it into hs/ instead of hs-comp/:

http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/21ea7a2e3afc

Should be synced to all repos at the end of this week.

Regards,
Vladimir

On 4/2/15 2:27 AM, Andrew Haley wrote:
> On 03/25/2015 05:34 PM, Vladimir Kozlov wrote:
>> Looks good.
>>
>> It is in JPRT queue for push.
>
> I don't see it.  What happened?
>
> Thanks,
> Andrew.
>

From tavarageri at reservoir.com  Mon Apr  6 13:37:17 2015
From: tavarageri at reservoir.com (Sanket Tavarageri)
Date: Mon, 6 Apr 2015 09:37:17 -0400
Subject: [aarch64-port-dev ] Missing tar balls in 15-03 release of JDK7
Message-ID: <CAK_A9iUESw70sG-Wkp_H6mQ-GpJkmFrmT6moJ3LfZZ+iNXf3vQ@mail.gmail.com>

Hi,

The following files are missing in the latest release of JDK7:
http://openjdk.linaro.org/releases/jdk7-src-1503.tar.xz :
corba.tar.bz2  hotspot.tar.bz2  jaxp.tar.bz2  jaxws.tar.bz2  jdk.tar.bz2
 langtools.tar.bz2  openjdk.tar.bz2

If you could please make a new release available with these files, or point
to locations where these may be available, that will be great.

Thank you.

Best regards,
Sanket

From tavarageri at reservoir.com  Mon Apr  6 13:32:53 2015
From: tavarageri at reservoir.com (Sanket Tavarageri)
Date: Mon, 6 Apr 2015 09:32:53 -0400
Subject: [aarch64-port-dev ] Missing tar balls in 15-03 release of JDK7
Message-ID: <CAK_A9iWftR06jYWdSygqaqaggu6NxF+WPnfHN4Te2uWEe2610w@mail.gmail.com>

Hi,

The following files are missing in the latest release of JDK7:
http://openjdk.linaro.org/releases/jdk7-src-1503.tar.xz :
corba.tar.bz2  hotspot.tar.bz2  jaxp.tar.bz2  jaxws.tar.bz2  jdk.tar.bz2
 langtools.tar.bz2  openjdk.tar.bz2

If you could please make a new release available with these files, or point
to locations where these may be available, that will be great.

Thank you.

Best regards,
Sanket

From edward.nevill at linaro.org  Mon Apr  6 20:41:19 2015
From: edward.nevill at linaro.org (Edward Nevill)
Date: Mon, 6 Apr 2015 21:41:19 +0100
Subject: [aarch64-port-dev ] Missing tar balls in 15-03 release of JDK7
In-Reply-To: <CAK_A9iWftR06jYWdSygqaqaggu6NxF+WPnfHN4Te2uWEe2610w@mail.gmail.com>
References: <CAK_A9iWftR06jYWdSygqaqaggu6NxF+WPnfHN4Te2uWEe2610w@mail.gmail.com>
Message-ID: <CAEf2cjeQWJW1zK5AGJTE33pPz1XoOeAPEGe6qqpcU+gRrQJb1A@mail.gmail.com>

Hi Sankat,

On 6 April 2015 at 14:32, Sanket Tavarageri <tavarageri at reservoir.com>
wrote:

> Hi,
>
> The following files are missing in the latest release of JDK7:
> http://openjdk.linaro.org/releases/jdk7-src-1503.tar.xz :
> corba.tar.bz2  hotspot.tar.bz2  jaxp.tar.bz2  jaxws.tar.bz2  jdk.tar.bz2
>  langtools.tar.bz2  openjdk.tar.bz2
>
> If you could please make a new release available with these files, or point
> to locations where these may be available, that will be great.
>

Thanks for pointing this out. I have updated the release.

All the best,
Ed.

From qun.wang at sap.com  Thu Apr  9 03:57:58 2015
From: qun.wang at sap.com (Wang, Qun)
Date: Thu, 9 Apr 2015 03:57:58 +0000
Subject: [aarch64-port-dev ] A question about how to install RedHat OpenJDK
	on Linux-aarch64
Message-ID: <14340B47B36F4F45AA620B220F3FB9F3A61B0ABB@DEWDFEMB17B.global.corp.sap>

Hello,

I am installing RedHat OpenJDK on Linux-aarch64 (aarch64-port-jdk8-aarch64-992-b128.tar.tar) according to your README, but encountered an issue. When I run bash ./configure, I see the following error message.

configure: Found potential Boot JDK using java(c) in PATH
configure: Potential Boot JDK found at /home/qun/jdk8/jdk1.8.0_40 is incorrect JDK version (./common/autoconf/generated-configure.sh: line 12448: /home/qun/jdk8/jdk1.8.0_40/bin/java: cannot execute binary file); ignoring
configure: (Your Boot JDK must be version 7 or 8)
configure: Could not find a valid Boot JDK.
configure: This might be fixed by explicitely setting --with-boot-jdk
configure: error: Cannot continue
configure exiting with result code 1

What I don't understand is I have installed latest Oracle JDK 8 for Linux-x64 and have updated my $PATH to point to the directory. However ./configure still complains that the jdk version is not correct and the binary file cannot be executed. It is expected that the binary file cannot be executed, right? The reason is the binary file is for Linux-x64 (The jdk8 for Linux-aarch64 developed by Oracle is not available yet) rather than Linux-aarch64.
[qun at asearm1 jdk8_redhat]$ echo $PATH
/home/qun/jdk8/jdk1.8.0_40/bin:/home/qun/remote/tst_inst/archives/ocs/csi/tools/linuxa
rm64:/home/qun/remote/tst_inst/archives/ocs/csi/tools/generic/apache-ant-1.7.1/bin:/ho
me/qun/remote/tst_inst/archives/ocs/csi/java/linuxarm64/jdk1.7.0_60/bin:.:/bin:/sbin:/
usr/bin:/usr/sbin:/usr/bin/X11:/usr/local/bin
[qun at asearm1 jdk8_redhat]$ ls /home/qun/jdk8
jdk-8u40-linux-x64.tar.gz  jdk1.8.0_40/
[qun at asearm1 jdk8_redhat]$

Any idea please?

Thanks,
Qun


From aph at redhat.com  Thu Apr  9 06:56:21 2015
From: aph at redhat.com (Andrew Haley)
Date: Thu, 09 Apr 2015 07:56:21 +0100
Subject: [aarch64-port-dev ] A question about how to install RedHat
 OpenJDK on Linux-aarch64
In-Reply-To: <14340B47B36F4F45AA620B220F3FB9F3A61B0ABB@DEWDFEMB17B.global.corp.sap>
References: <14340B47B36F4F45AA620B220F3FB9F3A61B0ABB@DEWDFEMB17B.global.corp.sap>
Message-ID: <55262295.3010203@redhat.com>

Hi,

On 09/04/15 04:57, Wang, Qun wrote:

> I am installing RedHat OpenJDK on Linux-aarch64 (aarch64-port-jdk8-aarch64-992-b128.tar.tar) according to your README, but encountered an issue. When I run bash ./configure, I see the following error message.
> 
> configure: Found potential Boot JDK using java(c) in PATH
> configure: Potential Boot JDK found at /home/qun/jdk8/jdk1.8.0_40 is incorrect JDK version (./common/autoconf/generated-configure.sh: line 12448: /home/qun/jdk8/jdk1.8.0_40/bin/java: cannot execute binary file); ignoring
> configure: (Your Boot JDK must be version 7 or 8)
> configure: Could not find a valid Boot JDK.
> configure: This might be fixed by explicitely setting --with-boot-jdk
> configure: error: Cannot continue
> configure exiting with result code 1
> 
> What I don't understand is I have installed latest Oracle JDK 8 for
> Linux-x64 and have updated my $PATH to point to the
> directory. However ./configure still complains that the jdk version
> is not correct and the binary file cannot be executed. It is
> expected that the binary file cannot be executed, right?

Yes.

> The reason is the binary file is for Linux-x64 (The jdk8 for
> Linux-aarch64 developed by Oracle is not available yet) rather than
> Linux-aarch64.

> [qun at asearm1 jdk8_redhat]$ echo $PATH
> /home/qun/jdk8/jdk1.8.0_40/bin:/home/qun/remote/tst_inst/archives/ocs/csi/tools/linuxa
> rm64:/home/qun/remote/tst_inst/archives/ocs/csi/tools/generic/apache-ant-1.7.1/bin:/ho
> me/qun/remote/tst_inst/archives/ocs/csi/java/linuxarm64/jdk1.7.0_60/bin:.:/bin:/sbin:/
> usr/bin:/usr/sbin:/usr/bin/X11:/usr/local/bin [qun at asearm1
> jdk8_redhat]$ ls /home/qun/jdk8 jdk-8u40-linux-x64.tar.gz
> jdk1.8.0_40/ [qun at asearm1 jdk8_redhat]$
> 
> Any idea please?

If you have any version of Linux from Red Hat, OpenJDK is part of the
operating system.  You should install that first, the same way as you
install any other software.

Andrew.

From aph at redhat.com  Thu Apr  9 08:35:22 2015
From: aph at redhat.com (Andrew Haley)
Date: Thu, 09 Apr 2015 09:35:22 +0100
Subject: [aarch64-port-dev ] A question about how to install RedHat
 OpenJDK on Linux-aarch64
In-Reply-To: <14340B47B36F4F45AA620B220F3FB9F3A61B0B60@DEWDFEMB17B.global.corp.sap>
References: <14340B47B36F4F45AA620B220F3FB9F3A61B0ABB@DEWDFEMB17B.global.corp.sap>
	<55262295.3010203@redhat.com>
	<14340B47B36F4F45AA620B220F3FB9F3A61B0B60@DEWDFEMB17B.global.corp.sap>
Message-ID: <552639CA.8080507@redhat.com>

On 04/09/2015 08:32 AM, Wang, Qun wrote:
> Hi Andrew,
> 
> Thanks so much for your quick response. 
> 
>> If you have any version of Linux from Red Hat, OpenJDK is part of the
>> operating system.  You should install that first, the same way as you
>> install any other software.
> 
> I am confused about this. We do have platforms installed Linux from
> Red Hat. However I could not see any relationship between those
> installations of OpenSDK and my installation on Linux-aarch64. Do
> you mean I update my $PATH on Linux-aarch64 platform to point to an
> OpenDSK installation on a Red Hat Linux machine? If so, my case is
> my Linux-aarch64 platform cannot easily access the OpenDSK
> installation on my Red Hat Linux platform.

Where did you get your Linux-aarch64 platform?  It should include
OpenJDK.

If it doesn't you may be able to get one from
http://openjdk.linaro.org/

Andrew.

From aph at redhat.com  Thu Apr  9 08:46:52 2015
From: aph at redhat.com (Andrew Haley)
Date: Thu, 09 Apr 2015 09:46:52 +0100
Subject: [aarch64-port-dev ] A question about how to install RedHat
 OpenJDK on Linux-aarch64
In-Reply-To: <14340B47B36F4F45AA620B220F3FB9F3A61B0C00@DEWDFEMB17B.global.corp.sap>
References: <14340B47B36F4F45AA620B220F3FB9F3A61B0ABB@DEWDFEMB17B.global.corp.sap>
	<55262295.3010203@redhat.com>
	<14340B47B36F4F45AA620B220F3FB9F3A61B0B60@DEWDFEMB17B.global.corp.sap>
	<552639CA.8080507@redhat.com>
	<14340B47B36F4F45AA620B220F3FB9F3A61B0C00@DEWDFEMB17B.global.corp.sap>
Message-ID: <55263C7C.50407@redhat.com>

On 04/09/2015 09:40 AM, Wang, Qun wrote:
> 
> I downloaded aarch64-port-jdk8-aarch64-992-b128.tar.tar from
> http://developerblog.redhat.com/2014/03/14/openjdk-on-aarch64-released/.
> Uncompressed the file and follow the steps in the README file.
> 
> And this is a part of the README file.
> Simple Build Instructions:
> 
>   0. Get the necessary system software/packages installed on your system, see
>      http://hg.openjdk.java.net/jdk8/jdk8/raw-file/tip/README-builds.html
> 
>   1. If you don't have a jdk7u7 or newer jdk, download and install it from
>      http://java.sun.com/javase/downloads/index.jsp
>      Add the /bin directory of this installation to your PATH environment
>      variable.
> 
>   2. Configure the build:
>        bash ./configure
> 
>   3. Build the OpenJDK:
>        make all
>      The resulting JDK image should be found in build/*/images/j2sdk-image

Right, but that's the source code.  You need Java installed already to
build a new Java.

Andrew.

From edward.nevill at linaro.org  Thu Apr  9 09:31:13 2015
From: edward.nevill at linaro.org (Edward Nevill)
Date: Thu, 09 Apr 2015 10:31:13 +0100
Subject: [aarch64-port-dev ] RFR: 8075930: AARCH64: Use FP Register in C2
In-Reply-To: <5512B817.3080802@oracle.com>
References: <1427288528.7353.25.camel@mylittlepony.linaroharston>
	<5512B817.3080802@oracle.com>
Message-ID: <1428571873.26527.24.camel@mylittlepony.linaroharston>

Hi Zolt?n,

Thanks for the review. I have updated the patch to take account of your comments. New patch at

http://cr.openjdk.java.net/~enevill/8075930/webrev.02/

Could someone please review this patch and if approved push.

See inline comments below.

On Wed, 2015-03-25 at 14:28 +0100, Zolt?n Maj? wrote:
> On 03/25/2015 02:02 PM, Edward Nevill wrote:
> > Hi,
> >
> > The aarch64 C2 compiler makes no use of the FP register even though this register is saved on entry and restored on exit and is therefore always available for allocation.
> 
> It seems to me that the C2 compiler currently saves the SP into FP on 
> method handle invokes. This functionality is encoded by 
> aarch64_enc_java_handle_call in aarch64.ad. C1 does the same (see usages 
> of FrameMap::method_handle_invoke_SP_save_opr()).

So, this is an issue for C2 only, since my proposed patch does not affect register usage in C1, so C1 will continue to keep FP as unallocated.

The change required for C2 is to let the register allocator know that FP will be killed by a methodhandle call. This is accomplished by the following change in aarch64.ad

 const RegMask Matcher::method_handle_invoke_SP_save_mask() {
-  return RegMask();
+  return FP_REG_mask();
 }

> 
> Stack walking relies on having the SP saved into FP for method handle 
> invokes (e.g., in frame::adjust_unextended_sp()).
> 
> Saving the SP into FP is not needed on some architectures (e.g., x86). 
> I'm currently working on an enhancement that disables saving the SP into 
> FP on x86 (see JDK-8068945). Maybe that could work for aarch64 as well.
> 
> Does your change consider this aspect? Maybe running the tests in 
> jdk/test/java/lang/invoke/ could trigger some failures that are caused 
> by the FP not containing the SP of the caller of a method handle invocation.
> 

I have run the jdk/test/java/lang/invoke tests both with and without the
proposed patch. In bot cases 62 tests out of 62 passed.

I have also rerun JTreg hotspot and langtools with the following
results:-

Before:-

Hotspot: Test results: passed: 596; failed: 190; error: 26
Langtools: Test results: passed: 3,237; error: 9

After:-

Hotspot: Test results: passed: 596; failed: 190; error: 26
Langtools: Test results: passed: 3,238; error: 8

All the best,
Ed.





From vladimir.kozlov at oracle.com  Thu Apr  9 17:32:33 2015
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Thu, 09 Apr 2015 10:32:33 -0700
Subject: [aarch64-port-dev ] RFR: 8075930: AARCH64: Use FP Register in C2
In-Reply-To: <1428571873.26527.24.camel@mylittlepony.linaroharston>
References: <1427288528.7353.25.camel@mylittlepony.linaroharston>	<5512B817.3080802@oracle.com>
	<1428571873.26527.24.camel@mylittlepony.linaroharston>
Message-ID: <5526B7B1.7000702@oracle.com>

Hi Edward,

In frame() I think check !defined(COMPILER2) is useless because COMPILER2 is always defined in 64-bit Server Hotspot VM. 
Unless you have configuration without C2. I think it should be dynamic check after you find who generated this _cb.
Can you explain what this code does (there is not comment):

   80 #ifndef PRODUCT
   81   if (fp)
   82     if (sp > fp || (fp - sp > 0x100000))
   83       for(;;)
   84         asm("nop");
   85 #endif

Thanks,
Vladimir

On 4/9/15 2:31 AM, Edward Nevill wrote:
> Hi Zolt?n,
>
> Thanks for the review. I have updated the patch to take account of your comments. New patch at
>
> http://cr.openjdk.java.net/~enevill/8075930/webrev.02/
>
> Could someone please review this patch and if approved push.
>
> See inline comments below.
>
> On Wed, 2015-03-25 at 14:28 +0100, Zolt?n Maj? wrote:
>> On 03/25/2015 02:02 PM, Edward Nevill wrote:
>>> Hi,
>>>
>>> The aarch64 C2 compiler makes no use of the FP register even though this register is saved on entry and restored on exit and is therefore always available for allocation.
>>
>> It seems to me that the C2 compiler currently saves the SP into FP on
>> method handle invokes. This functionality is encoded by
>> aarch64_enc_java_handle_call in aarch64.ad. C1 does the same (see usages
>> of FrameMap::method_handle_invoke_SP_save_opr()).
>
> So, this is an issue for C2 only, since my proposed patch does not affect register usage in C1, so C1 will continue to keep FP as unallocated.
>
> The change required for C2 is to let the register allocator know that FP will be killed by a methodhandle call. This is accomplished by the following change in aarch64.ad
>
>   const RegMask Matcher::method_handle_invoke_SP_save_mask() {
> -  return RegMask();
> +  return FP_REG_mask();
>   }
>
>>
>> Stack walking relies on having the SP saved into FP for method handle
>> invokes (e.g., in frame::adjust_unextended_sp()).
>>
>> Saving the SP into FP is not needed on some architectures (e.g., x86).
>> I'm currently working on an enhancement that disables saving the SP into
>> FP on x86 (see JDK-8068945). Maybe that could work for aarch64 as well.
>>
>> Does your change consider this aspect? Maybe running the tests in
>> jdk/test/java/lang/invoke/ could trigger some failures that are caused
>> by the FP not containing the SP of the caller of a method handle invocation.
>>
>
> I have run the jdk/test/java/lang/invoke tests both with and without the
> proposed patch. In bot cases 62 tests out of 62 passed.
>
> I have also rerun JTreg hotspot and langtools with the following
> results:-
>
> Before:-
>
> Hotspot: Test results: passed: 596; failed: 190; error: 26
> Langtools: Test results: passed: 3,237; error: 9
>
> After:-
>
> Hotspot: Test results: passed: 596; failed: 190; error: 26
> Langtools: Test results: passed: 3,238; error: 8
>
> All the best,
> Ed.
>
>
>
>

From aph at redhat.com  Thu Apr  9 17:55:40 2015
From: aph at redhat.com (Andrew Haley)
Date: Thu, 09 Apr 2015 18:55:40 +0100
Subject: [aarch64-port-dev ] RFR: 8075930: AARCH64: Use FP Register in C2
In-Reply-To: <5526B7B1.7000702@oracle.com>
References: <1427288528.7353.25.camel@mylittlepony.linaroharston>	<5512B817.3080802@oracle.com>	<1428571873.26527.24.camel@mylittlepony.linaroharston>
	<5526B7B1.7000702@oracle.com>
Message-ID: <5526BD1C.6040406@redhat.com>

On 04/09/2015 06:32 PM, Vladimir Kozlov wrote:
> Can you explain what this code does (there is not comment):
> 
>    80 #ifndef PRODUCT
>    81   if (fp)
>    82     if (sp > fp || (fp - sp > 0x100000))
>    83       for(;;)
>    84         asm("nop");
>    85 #endif

It's mine.  It's a simple sanity check I put in way before the dawn of
time which allows a debugger to be attached to see a corrupt stack..
It was tremendously useful.  It can go if it's no longer needed.

Andrew.

From zoltan.majo at oracle.com  Fri Apr 10 06:31:39 2015
From: zoltan.majo at oracle.com (=?UTF-8?B?Wm9sdMOhbiBNYWrDsw==?=)
Date: Fri, 10 Apr 2015 08:31:39 +0200
Subject: [aarch64-port-dev ] RFR: 8075930: AARCH64: Use FP Register in C2
In-Reply-To: <1428571873.26527.24.camel@mylittlepony.linaroharston>
References: <1427288528.7353.25.camel@mylittlepony.linaroharston>	
	<5512B817.3080802@oracle.com>
	<1428571873.26527.24.camel@mylittlepony.linaroharston>
Message-ID: <55276E4B.6000604@oracle.com>

Hi Ed,


this looks good to me (not a *R*eviewer).

Thank you and best regards,


Zoltan


On 04/09/2015 11:31 AM, Edward Nevill wrote:
> Hi Zolt?n,
>
> Thanks for the review. I have updated the patch to take account of your comments. New patch at
>
> http://cr.openjdk.java.net/~enevill/8075930/webrev.02/
>
> Could someone please review this patch and if approved push.
>
> See inline comments below.
>
> On Wed, 2015-03-25 at 14:28 +0100, Zolt?n Maj? wrote:
>> On 03/25/2015 02:02 PM, Edward Nevill wrote:
>>> Hi,
>>>
>>> The aarch64 C2 compiler makes no use of the FP register even though this register is saved on entry and restored on exit and is therefore always available for allocation.
>> It seems to me that the C2 compiler currently saves the SP into FP on
>> method handle invokes. This functionality is encoded by
>> aarch64_enc_java_handle_call in aarch64.ad. C1 does the same (see usages
>> of FrameMap::method_handle_invoke_SP_save_opr()).
> So, this is an issue for C2 only, since my proposed patch does not affect register usage in C1, so C1 will continue to keep FP as unallocated.
>
> The change required for C2 is to let the register allocator know that FP will be killed by a methodhandle call. This is accomplished by the following change in aarch64.ad
>
>   const RegMask Matcher::method_handle_invoke_SP_save_mask() {
> -  return RegMask();
> +  return FP_REG_mask();
>   }
>
>> Stack walking relies on having the SP saved into FP for method handle
>> invokes (e.g., in frame::adjust_unextended_sp()).
>>
>> Saving the SP into FP is not needed on some architectures (e.g., x86).
>> I'm currently working on an enhancement that disables saving the SP into
>> FP on x86 (see JDK-8068945). Maybe that could work for aarch64 as well.
>>
>> Does your change consider this aspect? Maybe running the tests in
>> jdk/test/java/lang/invoke/ could trigger some failures that are caused
>> by the FP not containing the SP of the caller of a method handle invocation.
>>
> I have run the jdk/test/java/lang/invoke tests both with and without the
> proposed patch. In bot cases 62 tests out of 62 passed.
>
> I have also rerun JTreg hotspot and langtools with the following
> results:-
>
> Before:-
>
> Hotspot: Test results: passed: 596; failed: 190; error: 26
> Langtools: Test results: passed: 3,237; error: 9
>
> After:-
>
> Hotspot: Test results: passed: 596; failed: 190; error: 26
> Langtools: Test results: passed: 3,238; error: 8
>
> All the best,
> Ed.
>
>
>
>


From edward.nevill at linaro.org  Fri Apr 10 08:54:59 2015
From: edward.nevill at linaro.org (Edward Nevill)
Date: Fri, 10 Apr 2015 09:54:59 +0100
Subject: [aarch64-port-dev ] RFR: 8075930: AARCH64: Use FP Register in C2
In-Reply-To: <5526B7B1.7000702@oracle.com>
References: <1427288528.7353.25.camel@mylittlepony.linaroharston>
	<5512B817.3080802@oracle.com>
	<1428571873.26527.24.camel@mylittlepony.linaroharston>
	<5526B7B1.7000702@oracle.com>
Message-ID: <1428656099.13172.10.camel@mylittlepony.linaroharston>

Hi Vladimir,

On Thu, 2015-04-09 at 10:32 -0700, Vladimir Kozlov wrote:
> Hi Edward,
> 
> In frame() I think check !defined(COMPILER2) is useless because COMPILER2 is always defined in 64-bit Server Hotspot VM. 
> Unless you have configuration without C2. I think it should be dynamic check after you find who generated this _cb.
> Can you explain what this code does (there is not comment):

We do build without C2 as part of our testing. However, as Andrew Haley said, this is old debug code, so I propose simply removing it. Its usefulness is rather limited once fp can be allocated as a general purpose register.

> 
>    80 #ifndef PRODUCT
>    81   if (fp)
>    82     if (sp > fp || (fp - sp > 0x100000))
>    83       for(;;)
>    84         asm("nop");
>    85 #endif

New webrev removing this code @

http://cr.openjdk.java.net/~enevill/8075930/webrev.03/

All the best,
Ed.



From aph at redhat.com  Fri Apr 10 08:58:07 2015
From: aph at redhat.com (Andrew Haley)
Date: Fri, 10 Apr 2015 09:58:07 +0100
Subject: [aarch64-port-dev ] RFR: 8075930: AARCH64: Use FP Register in C2
In-Reply-To: <1428656099.13172.10.camel@mylittlepony.linaroharston>
References: <1427288528.7353.25.camel@mylittlepony.linaroharston>	<5512B817.3080802@oracle.com>	<1428571873.26527.24.camel@mylittlepony.linaroharston>	<5526B7B1.7000702@oracle.com>
	<1428656099.13172.10.camel@mylittlepony.linaroharston>
Message-ID: <5527909F.70105@redhat.com>

On 04/10/2015 09:54 AM, Edward Nevill wrote:
> In frame() I think check !defined(COMPILER2) is useless because COMPILER2 is always defined in 64-bit Server Hotspot VM. 

I've never really understood the reason for this limitation.  With a few
lines of code it's possible to build a perfectly good client VM.  Why
should 64-bit systems not be able to build a client VM?

Andrew.


From vladimir.kozlov at oracle.com  Fri Apr 10 14:44:09 2015
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Fri, 10 Apr 2015 07:44:09 -0700
Subject: [aarch64-port-dev ] RFR: 8075930: AARCH64: Use FP Register in C2
In-Reply-To: <1428656099.13172.10.camel@mylittlepony.linaroharston>
References: <1427288528.7353.25.camel@mylittlepony.linaroharston>		<5512B817.3080802@oracle.com>	
	<1428571873.26527.24.camel@mylittlepony.linaroharston>	
	<5526B7B1.7000702@oracle.com>
	<1428656099.13172.10.camel@mylittlepony.linaroharston>
Message-ID: <5527E1B9.5030109@oracle.com>

Looks good.

Thanks,
Vladimir

On 4/10/15 1:54 AM, Edward Nevill wrote:
> Hi Vladimir,
>
> On Thu, 2015-04-09 at 10:32 -0700, Vladimir Kozlov wrote:
>> Hi Edward,
>>
>> In frame() I think check !defined(COMPILER2) is useless because COMPILER2 is always defined in 64-bit Server Hotspot VM.
>> Unless you have configuration without C2. I think it should be dynamic check after you find who generated this _cb.
>> Can you explain what this code does (there is not comment):
>
> We do build without C2 as part of our testing. However, as Andrew Haley said, this is old debug code, so I propose simply removing it. Its usefulness is rather limited once fp can be allocated as a general purpose register.
>
>>
>>     80 #ifndef PRODUCT
>>     81   if (fp)
>>     82     if (sp > fp || (fp - sp > 0x100000))
>>     83       for(;;)
>>     84         asm("nop");
>>     85 #endif
>
> New webrev removing this code @
>
> http://cr.openjdk.java.net/~enevill/8075930/webrev.03/
>
> All the best,
> Ed.
>
>

From vladimir.kozlov at oracle.com  Fri Apr 10 14:53:50 2015
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Fri, 10 Apr 2015 07:53:50 -0700
Subject: [aarch64-port-dev ] RFR: 8075930: AARCH64: Use FP Register in C2
In-Reply-To: <5527909F.70105@redhat.com>
References: <1427288528.7353.25.camel@mylittlepony.linaroharston>	<5512B817.3080802@oracle.com>	<1428571873.26527.24.camel@mylittlepony.linaroharston>	<5526B7B1.7000702@oracle.com>
	<1428656099.13172.10.camel@mylittlepony.linaroharston>
	<5527909F.70105@redhat.com>
Message-ID: <5527E3FE.1030707@oracle.com>

On 4/10/15 1:58 AM, Andrew Haley wrote:
> On 04/10/2015 09:54 AM, Edward Nevill wrote:
>> In frame() I think check !defined(COMPILER2) is useless because COMPILER2 is always defined in 64-bit Server Hotspot VM.
>
> I've never really understood the reason for this limitation.  With a few
> lines of code it's possible to build a perfectly good client VM.  Why
> should 64-bit systems not be able to build a client VM?
>
> Andrew.

Yes, from technical point of view it could be done.
But from financial - we don't see the need to support this configuration (for now).
For the same reason, as you noticed, we removed support of 32-bit VM from Solaris (x86 and Sparc). You still can build 
it but eventually it will rot.

Regards,
Vladimir



From c_ejohns at qti.qualcomm.com  Fri Apr 10 16:44:09 2015
From: c_ejohns at qti.qualcomm.com (Johnson, E Andrew)
Date: Fri, 10 Apr 2015 16:44:09 +0000
Subject: [aarch64-port-dev ] JDK-8076488
Message-ID: <4bcb0a43e3a1445e8e2100ddaae4549d@nasanexm02f.na.qualcomm.com>

A patch for this problem was posted back on April 1, 2015, but it still hasn't been incorporated into jdk9/dev.  Was it posted to another branch instead?  It's not in jdk9/hs either.  It is required for successful builds of linux-aarch64.

-AndyJ


From c_ejohns at qti.qualcomm.com  Mon Apr 13 15:13:30 2015
From: c_ejohns at qti.qualcomm.com (Johnson, E Andrew)
Date: Mon, 13 Apr 2015 15:13:30 +0000
Subject: [aarch64-port-dev ] Review, please
Message-ID: <1428938016626.50820@qti.qualcomm.com>

I have discovered a number of places where both the aarch64-port/jdk7 and aarch64-port/jdk8 sources have conditionals which include "defined(AARCH64)" that are not in the jdk9/dev sources.  One of these, in hotspot/src/share/vm/runtime/advancedThresholdPolicy.cpp, causes a regression in the performance of the SPECjvm2008 benchmark scimark.monte_carlo, since a method which had been been expanded inline in both jdk7 and jdk8 is not inlined in jdk9.  Because of the number of calls made to this method, the calling overhead reduces the score to 1/6 of the score reported when the method is expanded inline.  I am sure that other benchmarks, as well as other applications, are impacted by this.


Several of the places where I discovered missing conditionals are in c1 sources.  While the default build is for the server compiler, I see JTREG results posted routinely on the Linaro OpenJDK site for both the client and server builds, so I believe that the client compiler should be kept up-to-date as much as possible until it is officially dropped from all 64-bit ports.


I will be submitting a bug report and a webrev which includes these patches.  However, since the principal developers of the aarch64-port are on this email list, I figured it would be worthwhile to get a "sanity check" on these changes.  If there are good reasons why any of these should not be propagated into jdk9/dev, I will be happy to remove them from the proposed patches.  If indeed, these are all "errors of omission", then I will submit the entire set of patches.


See the attached file for the proposed patches.


-AndyJ

-------------- next part --------------
A non-text attachment was scrubbed...
Name: aarch64.patch
Type: text/x-diff
Size: 5166 bytes
Desc: aarch64.patch
URL: <http://mail.openjdk.java.net/pipermail/aarch64-port-dev/attachments/20150413/41a121ea/aarch64.patch>

From aph at redhat.com  Mon Apr 13 17:05:53 2015
From: aph at redhat.com (Andrew Haley)
Date: Mon, 13 Apr 2015 18:05:53 +0100
Subject: [aarch64-port-dev ] Review, please
In-Reply-To: <1428938016626.50820@qti.qualcomm.com>
References: <1428938016626.50820@qti.qualcomm.com>
Message-ID: <552BF771.2010605@redhat.com>

On 04/13/2015 04:13 PM, Johnson, E Andrew wrote:

> I have discovered a number of places where both the
> aarch64-port/jdk7 and aarch64-port/jdk8 sources have conditionals
> which include "defined(AARCH64)" that are not in the jdk9/dev
> sources.  One of these, in
> hotspot/src/share/vm/runtime/advancedThresholdPolicy.cpp, causes a
> regression in the performance of the SPECjvm2008 benchmark
> scimark.monte_carlo, since a method which had been been expanded
> inline in both jdk7 and jdk8 is not inlined in jdk9.  Because of the
> number of calls made to this method, the calling overhead reduces
> the score to 1/6 of the score reported when the method is expanded
> inline.  I am sure that other benchmarks, as well as other
> applications, are impacted by this.

Ah, that's very interesting.  Thanks.

> I will be submitting a bug report and a webrev which includes these
> patches.  However, since the principal developers of the
> aarch64-port are on this email list, I figured it would be
> worthwhile to get a "sanity check" on these changes.  If there are
> good reasons why any of these should not be propagated into
> jdk9/dev, I will be happy to remove them from the proposed patches.
> If indeed, these are all "errors of omission", then I will submit
> the entire set of patches.

Sure.  Ed, can you look at this?

Thanks,
Andrew.

From edward.nevill at linaro.org  Tue Apr 14 09:21:29 2015
From: edward.nevill at linaro.org (Edward Nevill)
Date: Tue, 14 Apr 2015 10:21:29 +0100
Subject: [aarch64-port-dev ] Review, please
In-Reply-To: <1428938016626.50820@qti.qualcomm.com>
References: <1428938016626.50820@qti.qualcomm.com>
Message-ID: <1429003289.3242.27.camel@mylittlepony.linaroharston>

On Mon, 2015-04-13 at 15:13 +0000, Johnson, E Andrew wrote:

> 
> See the attached file for the proposed patches.

Hi Andy,

Thanks for this patch.

I don't think a patch like this will be accepted upstream as is. Each case where there is a #if defined(AARCH64) needs to be separated out and a justification given for why it needs to be conditionalised on AARCH64.

Expect pushback on each case. These are changes to shared code and introduce conditionalised changes on a specific architecture which the upstream maintainers/reviewers really hate.

Start with the specific case you found which causes the performance regression.

  // Some inlining tuning
#if defined(X86) || defined(AARCH64)
  if (FLAG_IS_DEFAULT(InlineSmallCode)) {
    FLAG_SET_DEFAULT(InlineSmallCode, 2000);
  }
#endif

#ifdef SPARC
  if (FLAG_IS_DEFAULT(InlineSmallCode)) {
    FLAG_SET_DEFAULT(InlineSmallCode, 2500);
  }
#endif

The first question I would have as a reviewer (which I am not) is why are the defaults being modified here and why dont we simply set the correct defaults in globals_XXX.hpp

InlineSmallCode is declared product_pd in globals.hpp and has the following definitions in globals_XXX.hpp

hotspot/src/cpu/aarch64/vm/globals_aarch64.hpp:define_pd_global(intx, InlineSmallCode,          1000);
hotspot/src/cpu/ppc/vm/globals_ppc.hpp:define_pd_global(intx, InlineSmallCode,       1500);
hotspot/src/cpu/x86/vm/globals_x86.hpp:define_pd_global(intx, InlineSmallCode,          1000);
hotspot/src/cpu/zero/vm/globals_zero.hpp:define_pd_global(intx,  InlineSmallCode,      1000 );
hotspot/src/cpu/sparc/vm/globals_sparc.hpp:define_pd_global(intx, InlineSmallCode,       1500);


WRT most of the other #if defined(AARCH64) changes they were introduced to jdk8 in changeset 4754

changeset:   4754:961994affa01
user:        Edward Nevill ed at camswl.com
date:        Mon Jul 22 12:15:52 2013 +0100
files:       make/linux/platform_aarch64 src/os/linux/vm/os_linux.cpp src/share/vm/adlc/output_c.cpp src/share/vm/c1/c1_LIR.cpp src/share/vm/c1/c1_LIR.hpp src/share/vm/c1/c1_LIRAssembler.cpp src/share/vm/c1/c1_LIRGenerator.cpp src/share/vm/c1/c1_LinearScan.cpp src/share/vm/interpreter/interpreterRuntime.cpp src/share/vm/interpreter/interpreterRuntime.hpp src/share/vm/memory/allocation.inline.hpp src/share/vm/opto/machnode.hpp src/share/vm/prims/unsafe.cpp src/share/vm/runtime/advancedThresholdPolicy.cpp src/share/vm/runtime/vframeArray.cpp
description:
Remove -DAMD64 from sysdefs in platform_aarch64

So, initially for the builtin sim we had -DAMD64 in platform_aarch64. In fact I think it read -DAARCH64 -DAMD64. This was obviously broken, but it made sense at the time. In this changeset I added defined(AARCH64) to all #ifdef X86 statements that I thought were relevant at the time.

If these changes are to be pushed upstream a testcase will need for be found for each one which demonstrates that the conditionalisation is still necessary.

The other case in the changes you list was

--- a/src/share/vm/utilities/elfFile.cpp        Thu Apr 09 17:38:28 2015 -0700
+++ b/src/share/vm/utilities/elfFile.cpp        Fri Apr 10 15:06:38 2015 -0400
@@ -261,7 +261,12 @@
       }
     }
   }
+// x86 defaults to execstack, AARCH64 defaults to noexecstack
+#ifdef AARCH64
+  return true;
+#else
   return false;
+#endif
 }
 #endif

This was introduced in changeset 6668

changeset:   6668:0303ccd7b68d
user:        Edward Nevill edward.nevill at linaro.org
date:        Fri Feb 28 14:25:21 2014 +0000
files:       src/share/vm/utilities/elfFile.cpp
description:
Fix runtime/7107135/Test7107135 - problems with execstack

So, here the change was introduced to fix a specific test failure. Is the test still failing on jdk9? Does the above change still fix the test?

All the best,
Ed.



From c_ejohns at qti.qualcomm.com  Tue Apr 14 12:53:15 2015
From: c_ejohns at qti.qualcomm.com (Johnson, E Andrew)
Date: Tue, 14 Apr 2015 12:53:15 +0000
Subject: [aarch64-port-dev ] Review, please
In-Reply-To: <1429003289.3242.27.camel@mylittlepony.linaroharston>
References: <1428938016626.50820@qti.qualcomm.com>,
	<1429003289.3242.27.camel@mylittlepony.linaroharston>
Message-ID: <1429016015060.30993@qti.qualcomm.com>

Thanks, Ed.  I will check out each individual patch and verify that (a) it is necessary, and (b) can't possibly be solved another way in the specific architecture files.  Thanks for the advice.

It is a curiosity why the override for inlineSmallCode exists for other architectures.  It looks like these were introduced as a "quick fix" that somehow persisted.

-AndyJ
________________________________________
From: Edward Nevill <edward.nevill at linaro.org>
Sent: Tuesday, April 14, 2015 5:21 AM
To: Johnson, E Andrew
Cc: aarch64-port-dev at openjdk.java.net
Subject: Re: [aarch64-port-dev ] Review, please

On Mon, 2015-04-13 at 15:13 +0000, Johnson, E Andrew wrote:

>
> See the attached file for the proposed patches.

Hi Andy,

Thanks for this patch.

I don't think a patch like this will be accepted upstream as is. Each case where there is a #if defined(AARCH64) needs to be separated out and a justification given for why it needs to be conditionalised on AARCH64.

Expect pushback on each case. These are changes to shared code and introduce conditionalised changes on a specific architecture which the upstream maintainers/reviewers really hate.

Start with the specific case you found which causes the performance regression.

  // Some inlining tuning
#if defined(X86) || defined(AARCH64)
  if (FLAG_IS_DEFAULT(InlineSmallCode)) {
    FLAG_SET_DEFAULT(InlineSmallCode, 2000);
  }
#endif

#ifdef SPARC
  if (FLAG_IS_DEFAULT(InlineSmallCode)) {
    FLAG_SET_DEFAULT(InlineSmallCode, 2500);
  }
#endif

The first question I would have as a reviewer (which I am not) is why are the defaults being modified here and why dont we simply set the correct defaults in globals_XXX.hpp

InlineSmallCode is declared product_pd in globals.hpp and has the following definitions in globals_XXX.hpp

hotspot/src/cpu/aarch64/vm/globals_aarch64.hpp:define_pd_global(intx, InlineSmallCode,          1000);
hotspot/src/cpu/ppc/vm/globals_ppc.hpp:define_pd_global(intx, InlineSmallCode,       1500);
hotspot/src/cpu/x86/vm/globals_x86.hpp:define_pd_global(intx, InlineSmallCode,          1000);
hotspot/src/cpu/zero/vm/globals_zero.hpp:define_pd_global(intx,  InlineSmallCode,      1000 );
hotspot/src/cpu/sparc/vm/globals_sparc.hpp:define_pd_global(intx, InlineSmallCode,       1500);


WRT most of the other #if defined(AARCH64) changes they were introduced to jdk8 in changeset 4754

changeset:   4754:961994affa01
user:        Edward Nevill ed at camswl.com
date:        Mon Jul 22 12:15:52 2013 +0100
files:       make/linux/platform_aarch64 src/os/linux/vm/os_linux.cpp src/share/vm/adlc/output_c.cpp src/share/vm/c1/c1_LIR.cpp src/share/vm/c1/c1_LIR.hpp src/share/vm/c1/c1_LIRAssembler.cpp src/share/vm/c1/c1_LIRGenerator.cpp src/share/vm/c1/c1_LinearScan.cpp src/share/vm/interpreter/interpreterRuntime.cpp src/share/vm/interpreter/interpreterRuntime.hpp src/share/vm/memory/allocation.inline.hpp src/share/vm/opto/machnode.hpp src/share/vm/prims/unsafe.cpp src/share/vm/runtime/advancedThresholdPolicy.cpp src/share/vm/runtime/vframeArray.cpp
description:
Remove -DAMD64 from sysdefs in platform_aarch64

So, initially for the builtin sim we had -DAMD64 in platform_aarch64. In fact I think it read -DAARCH64 -DAMD64. This was obviously broken, but it made sense at the time. In this changeset I added defined(AARCH64) to all #ifdef X86 statements that I thought were relevant at the time.

If these changes are to be pushed upstream a testcase will need for be found for each one which demonstrates that the conditionalisation is still necessary.

The other case in the changes you list was

--- a/src/share/vm/utilities/elfFile.cpp        Thu Apr 09 17:38:28 2015 -0700
+++ b/src/share/vm/utilities/elfFile.cpp        Fri Apr 10 15:06:38 2015 -0400
@@ -261,7 +261,12 @@
       }
     }
   }
+// x86 defaults to execstack, AARCH64 defaults to noexecstack
+#ifdef AARCH64
+  return true;
+#else
   return false;
+#endif
 }
 #endif

This was introduced in changeset 6668

changeset:   6668:0303ccd7b68d
user:        Edward Nevill edward.nevill at linaro.org
date:        Fri Feb 28 14:25:21 2014 +0000
files:       src/share/vm/utilities/elfFile.cpp
description:
Fix runtime/7107135/Test7107135 - problems with execstack

So, here the change was introduced to fix a specific test failure. Is the test still failing on jdk9? Does the above change still fix the test?

All the best,
Ed.



From aph at redhat.com  Tue Apr 14 12:56:28 2015
From: aph at redhat.com (Andrew Haley)
Date: Tue, 14 Apr 2015 13:56:28 +0100
Subject: [aarch64-port-dev ] Review, please
In-Reply-To: <1429016015060.30993@qti.qualcomm.com>
References: <1428938016626.50820@qti.qualcomm.com>,
	<1429003289.3242.27.camel@mylittlepony.linaroharston>
	<1429016015060.30993@qti.qualcomm.com>
Message-ID: <552D0E7C.5020301@redhat.com>

On 04/14/2015 01:53 PM, Johnson, E Andrew wrote:

> Thanks, Ed.  I will check out each individual patch and verify that
> (a) it is necessary, and (b) can't possibly be solved another way in
> the specific architecture files.  Thanks for the advice.

One thing which would really help us if if you could find out what inlining
threshold really is best.  Can you try a few different values around that area
and tell us what happens to SPECjvm?  We really don't know what it should be.

Thanks,
Andrew.


From adinn at redhat.com  Tue Apr 14 15:45:15 2015
From: adinn at redhat.com (Andrew Dinn)
Date: Tue, 14 Apr 2015 16:45:15 +0100
Subject: [aarch64-port-dev ] Proposed patch for C2 volatile generation
 (resent)
In-Reply-To: <551C1295.2040809@redhat.com>
References: <55158471.4050009@redhat.com>	<5515916D.9010703@redhat.com>	<551912F2.4020204@redhat.com>	<551ACD21.4070608@redhat.com>	<551BFC2D.8080601@redhat.com>
	<551C1295.2040809@redhat.com>
Message-ID: <552D360B.5080902@redhat.com>

Attached is a further update to the C2 volatile generation code.

Firstly, it includes updates to the predicates unnecessary_acquire and
needs_acquiring_load which detect MemBarAcquire and LoadX nodes that
have inserted as a result of an inlined unsafe volatile read.

Secondly, it factors out some of the common graph traversal operations
into two auxiliary helper functions, has_parent_membar and has_child_membar.

I have also cleaned up the comments to explain what is being looked for
more clearly as well as to include the new case of inlined unsafe
volatile read.

I have checked this in two ways

1) running netbeans and dumping then eyeballing the assembly code
generated for j.u.c class ConcurrentHashMap methods

2) running jcstress

The results are not clear cut:

1) netbeans ran fine and all the code I have eyeballed so far looks like
it has correctly removed unneeded membars and only unneeded membars
(there are still some obviously redundant dmbs which it would also be
good to remove but I have not pinned them down yet). I have not yet
compared every case against the corresponding case when the optimization
is disabled.

2) jcstress saw a fail on one test

org.openjdk.jcstress.tests.interrupt
   ObjectWaitInfiniteTest

TERMINATED 	6 	ACCEPTABLE 	The thread had sucessfully terminated.
STALE 	1 	FORBIDDEN 	Thread had failed to respond.

I have no idea what this means.

jcstress also saw some VM crashes

org.openjdk.jcstress.tests.interrupt
   ObjectWaitInfiniteTest

Exception in thread "main" java.lang.NoSuchMethodError:
sun.misc.Unsafe.fieldOffset(Ljava/lang/reflect/Field;)I
    . . .

I assume this is because recent jdk9 jigsaw changes have hidden this method?

The other VM crashes occurred in various tests

org.openjdk.jcstress.tests.seqcst.volatiles 	  	  	  	  	
   L1_L1__L2_S2_S1__S1__Test
   L1_L2_L1_S2__S1_L2__Test
   . . .

org.openjdk.jcstress.tests.memeffects.basic.atomicupdaters.AtomicIntegerFieldUpdater
	  	  	  	  	
   atomic_addAndGet_incrementAndGet_long
   . . .

org.openjdk.jcstress.tests.memeffects.basic.atomicupdaters.AtomicLongFieldUpdater
	  	  	  	  	
   atomic_CAS_CAS_short
   . . .

n.b. when I reran just these specific tests the crashes did not recur.

In all these cases the crash happened underneath a VM callout to
~RuntimeStub::resolve_virtual_call. Of course, that method has nothing
directly to do with the changes I made. It might be that the weaker sync
between Java threads is leading to synchronization errors between Java
and JVM code.

I am not sure that my changes are the cause of this error though. I
reverted the current patch to emulate the previous patch by omitting the
checks for inlined unsafe volatile gets (there's a const bool setting
which turns this extra check on or off). When I reran jcstress with that
tweak I still saw an error (once again underneath a VM callout to
~RuntimeStub::resolve_virtual_call). I am wondering if this might be a
problem with my machine's config, specifically the version of gcc
installed on my machine (4.8.2-16).

I am still waiting for the jcstress tests to complete. When they do I
will revert all my changes and see whether I still get crashes.
Meanwhile, Ed, could you try running jcstress with the attached patch to
see if the problem is my setup?

regards,


Andrew Dinn
-----------
Senior Principal Software Engineer
Red Hat UK Ltd
Registered in UK and Wales under Company Registration No. 3798903
Directors: Michael Cunningham (USA), Matt Parson (USA), Charlie Peters
(USA), Michael O'Neill (Ireland)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 7991.patch
Type: text/x-patch
Size: 38314 bytes
Desc: not available
URL: <http://mail.openjdk.java.net/pipermail/aarch64-port-dev/attachments/20150414/45c16822/7991-0001.patch>

From c_ejohns at qti.qualcomm.com  Tue Apr 14 18:13:39 2015
From: c_ejohns at qti.qualcomm.com (Johnson, E Andrew)
Date: Tue, 14 Apr 2015 18:13:39 +0000
Subject: [aarch64-port-dev ] Review, please
In-Reply-To: <552D0E7C.5020301@redhat.com>
References: <1428938016626.50820@qti.qualcomm.com>,
	<1429003289.3242.27.camel@mylittlepony.linaroharston>
	<1429016015060.30993@qti.qualcomm.com> <552D0E7C.5020301@redhat.com>
Message-ID: <6c0b0b4d9dcb44aa91101b5178d12666@nasanexm02f.na.qualcomm.com>

The inlining threshold setting in globals_XXX.hpp is a default setting for all compilation policies.  The override in AdvancedCompilationPolicy is strictly for Tiered Compilation.  That's why the machine-specific conditionals are in the initialize method, since the static defaults have been found to be too small when Tiered Compilation is in effect.  That being said, the default value set in globals_aarch64.hpp is probably too small, since it isn't consistent with the settings for other 64-bit architectures (e.g. PPC & Sparc).  I would recommend setting the global default value to 1500.  

In running some experiments with different benchmarks, turning on and turning off tiered compilation, and turning on "compile all", the minimum value to give the best performance was 1200.  I am recommending 1500 because that is the default setting for PPC and Sparc.  If there was a separate set of globals for x86_64 (aka amd64), it would probably be 1500 there as well.

I find it interesting that the default inlining threshold value for both X86 and Sparc (both architectures supported by Oracle) is increased by 1000 when Tiered Compilation is enabled.  If I had to guess, I would imagine that these values were arrived at by similar experiments by the Java Performance Team.  Note that the overrides only happen if there was no user-specified:
-XX:InlineSmallCode=<value>

-AndyJ

-----Original Message-----
From: Andrew Haley [mailto:aph at redhat.com] 
Sent: Tuesday, April 14, 2015 8:56 AM
To: Johnson, E Andrew; Edward Nevill
Cc: aarch64-port-dev at openjdk.java.net
Subject: Re: [aarch64-port-dev ] Review, please

On 04/14/2015 01:53 PM, Johnson, E Andrew wrote:

> Thanks, Ed.  I will check out each individual patch and verify that
> (a) it is necessary, and (b) can't possibly be solved another way in 
> the specific architecture files.  Thanks for the advice.

One thing which would really help us if if you could find out what inlining threshold really is best.  Can you try a few different values around that area and tell us what happens to SPECjvm?  We really don't know what it should be.

Thanks,
Andrew.


From aph at redhat.com  Wed Apr 15 07:37:45 2015
From: aph at redhat.com (Andrew Haley)
Date: Wed, 15 Apr 2015 08:37:45 +0100
Subject: [aarch64-port-dev ] Review, please
In-Reply-To: <6c0b0b4d9dcb44aa91101b5178d12666@nasanexm02f.na.qualcomm.com>
References: <1428938016626.50820@qti.qualcomm.com>,
	<1429003289.3242.27.camel@mylittlepony.linaroharston>
	<1429016015060.30993@qti.qualcomm.com>
	<552D0E7C.5020301@redhat.com>
	<6c0b0b4d9dcb44aa91101b5178d12666@nasanexm02f.na.qualcomm.com>
Message-ID: <552E1549.4020004@redhat.com>

On 14/04/15 19:13, Johnson, E Andrew wrote:

> In running some experiments with different benchmarks, turning on
> and turning off tiered compilation, and turning on "compile all",
> the minimum value to give the best performance was 1200.  I am
> recommending 1500 because that is the default setting for PPC and
> Sparc.

Hmm.  This is the size of compiled code, right?  x86_64 has better
code density than SPARC and PPC, so I'd expect it to be a bit smaller.
AArch64 code density is better than either of those but (as far as I
can see) not as good as x86_64.  I haven't seen any real measurements
for either, though, so all this should not be taken very seriously.

> If there was a separate set of globals for x86_64 (aka amd64), it
> would probably be 1500 there as well.
> 
> I find it interesting that the default inlining threshold value for
> both X86 and Sparc (both architectures supported by Oracle) is
> increased by 1000 when Tiered Compilation is enabled.

So do I.  I don't know why tiered compilation makes a difference.  It
may simply be that C2-compiled code is much denser than C1-compiled,
but that would be a C2 vs. C1 thing rather than a tiered versus
non-tiered.

Andrew.

From edward.nevill at linaro.org  Wed Apr 15 09:37:00 2015
From: edward.nevill at linaro.org (Edward Nevill)
Date: Wed, 15 Apr 2015 10:37:00 +0100
Subject: [aarch64-port-dev ] Proposed patch for C2 volatile generation
 (resent)
In-Reply-To: <552D360B.5080902@redhat.com>
References: <55158471.4050009@redhat.com>	<5515916D.9010703@redhat.com>
	<551912F2.4020204@redhat.com>	<551ACD21.4070608@redhat.com>
	<551BFC2D.8080601@redhat.com> <551C1295.2040809@redhat.com>
	<552D360B.5080902@redhat.com>
Message-ID: <1429090620.7465.13.camel@mylittlepony.linaroharston>

On Tue, 2015-04-14 at 16:45 +0100, Andrew Dinn wrote:

> I am still waiting for the jcstress tests to complete. When they do I
> will revert all my changes and see whether I still get crashes.
> Meanwhile, Ed, could you try running jcstress with the attached patch to
> see if the problem is my setup?

OK. I have run it on another of our partners A57 hw with -XX:-TieredCompilation.

There were no failures. There was 1 VM error

Exception in thread "main" java.lang.NoSuchMethodError: sun.misc.Unsafe.fieldOffset(Ljava/lang/reflect/Field;)I

But I don't believe this is anything to do with the patch.

Results and log at

http://openjdk.linaro.org/jcstress/a57

I'll start a run without TieredCompilation now.

All the best,
Ed.



From adinn at redhat.com  Wed Apr 15 14:51:22 2015
From: adinn at redhat.com (Andrew Dinn)
Date: Wed, 15 Apr 2015 15:51:22 +0100
Subject: [aarch64-port-dev ] Proposed patch for C2 volatile generation
 (resent)
In-Reply-To: <1429090620.7465.13.camel@mylittlepony.linaroharston>
References: <55158471.4050009@redhat.com>	<5515916D.9010703@redhat.com>		<551912F2.4020204@redhat.com>	<551ACD21.4070608@redhat.com>		<551BFC2D.8080601@redhat.com>
	<551C1295.2040809@redhat.com>	 <552D360B.5080902@redhat.com>
	<1429090620.7465.13.camel@mylittlepony.linaroharston>
Message-ID: <552E7AEA.3060907@redhat.com>

On 15/04/15 10:37, Edward Nevill wrote:
> On Tue, 2015-04-14 at 16:45 +0100, Andrew Dinn wrote:
> 
>> I am still waiting for the jcstress tests to complete. When they do I
>> will revert all my changes and see whether I still get crashes.
>> Meanwhile, Ed, could you try running jcstress with the attached patch to
>> see if the problem is my setup?
> 
> OK. I have run it on another of our partners A57 hw with -XX:-TieredCompilation.
> 
> There were no failures. There was 1 VM error
> 
> Exception in thread "main" java.lang.NoSuchMethodError: sun.misc.Unsafe.fieldOffset(Ljava/lang/reflect/Field;)I
> 
> But I don't believe this is anything to do with the patch.
> 
> Results and log at
> 
> http://openjdk.linaro.org/jcstress/a57

Thanks Ed. It looks like the patch is ok.

I think the problem is my old hardware (or possibly OS). I am seeing
occasional VM crashes under resolve_virtual_call even without my patch.
I believe this is probably due to some hw problem to do with
icache/dcache syncing.

Also, I think we can disregard the VM crash for UnsafeBusyLoopTest. I
think this is happening because jdk9 has (very recently) hidden
sun.misc.Unsafe from everything not included in java.base. The jcstress
test harness does not add the jcstress jar to the bootstrap path for the
forked JVM . This appears to be so even if you add it on the command
line to the bootstrap path for the main JVM when you run jcstress.

java -jar jcstress.jar --help suggests you can use -jvmArgs to add
options for the forked JVM which might resolve this.

So, it seems the latest patch is looking good as a fix to make volatile
reads/writes use ldar<x>/stlr<x>. Andrew Haley, what else do we need to
do in order to proceed to commit?

Meanwhile, I'll continue eyeballing the output of ConcurrentHashMap to
see if I can see any other signature membar sequences I can detect and
safely elide dmb generation for (e.g. the dmb ish; dmb ishst pair I
noticed which seem to relate to inlined new operations).

regards,


Andrew Dinn
-----------
Senior Principal Software Engineer
Red Hat UK Ltd
Registered in UK and Wales under Company Registration No. 3798903
Directors: Michael Cunningham (USA), Matt Parson (USA), Charlie Peters
(USA), Michael O'Neill (Ireland)

From aph at redhat.com  Wed Apr 15 14:53:10 2015
From: aph at redhat.com (Andrew Haley)
Date: Wed, 15 Apr 2015 15:53:10 +0100
Subject: [aarch64-port-dev ] Proposed patch for C2 volatile generation
 (resent)
In-Reply-To: <552E7AEA.3060907@redhat.com>
References: <55158471.4050009@redhat.com>	<5515916D.9010703@redhat.com>		<551912F2.4020204@redhat.com>	<551ACD21.4070608@redhat.com>		<551BFC2D.8080601@redhat.com>
	<551C1295.2040809@redhat.com>	 <552D360B.5080902@redhat.com>
	<1429090620.7465.13.camel@mylittlepony.linaroharston>
	<552E7AEA.3060907@redhat.com>
Message-ID: <552E7B56.7030200@redhat.com>

On 04/15/2015 03:51 PM, Andrew Dinn wrote:
> So, it seems the latest patch is looking good as a fix to make volatile
> reads/writes use ldar<x>/stlr<x>. Andrew Haley, what else do we need to
> do in order to proceed to commit?

OK, if you think it's sound, I'll kick it for a while.

I'd like it to be complete and correct, if at all possible.

Thanks,
Andrew.


From adinn at redhat.com  Wed Apr 15 15:02:41 2015
From: adinn at redhat.com (Andrew Dinn)
Date: Wed, 15 Apr 2015 16:02:41 +0100
Subject: [aarch64-port-dev ] Proposed patch for C2 volatile generation
 (resent)
In-Reply-To: <552E7B56.7030200@redhat.com>
References: <55158471.4050009@redhat.com>	<5515916D.9010703@redhat.com>		<551912F2.4020204@redhat.com>	<551ACD21.4070608@redhat.com>		<551BFC2D.8080601@redhat.com>
	<551C1295.2040809@redhat.com>	 <552D360B.5080902@redhat.com>
	<1429090620.7465.13.camel@mylittlepony.linaroharston>
	<552E7AEA.3060907@redhat.com> <552E7B56.7030200@redhat.com>
Message-ID: <552E7D91.4050808@redhat.com>

On 15/04/15 15:53, Andrew Haley wrote:
> On 04/15/2015 03:51 PM, Andrew Dinn wrote:
>> So, it seems the latest patch is looking good as a fix to make volatile
>> reads/writes use ldar<x>/stlr<x>. Andrew Haley, what else do we need to
>> do in order to proceed to commit?
> 
> OK, if you think it's sound, I'll kick it for a while.
> 
> I'd like it to be complete and correct, if at all possible.

I'm feeling very good about correct. Complete is a more complex matter.

There are clearly a lot of other cases where we generate dmb
instructions that are redundant. That includes various inlined unsafe
sequences as well as e.g. inlined allocations. So, there is still a lot
of room for the predicates that guard the 3 membar generation rules and
the ldar/stlr rules to be extended to detect other signature input node
sequences.

I don't yet know if we can detect unique node signatures for all cases
nor how easy it will be to make the predicates detect them. How
important each such addition is in terms of performance is also another
issue. I'll look into this to get some idea of what reward we can expect
from any expended effort (just say no to the phrase 'low hanging fruit' :-).

regards,


Andrew Dinn
-----------
Senior Principal Software Engineer
Red Hat UK Ltd
Registered in UK and Wales under Company Registration No. 3798903
Directors: Michael Cunningham (USA), Matt Parson (USA), Charlie Peters
(USA), Michael O'Neill (Ireland)

From aph at redhat.com  Wed Apr 15 15:04:41 2015
From: aph at redhat.com (Andrew Haley)
Date: Wed, 15 Apr 2015 16:04:41 +0100
Subject: [aarch64-port-dev ] Proposed patch for C2 volatile generation
 (resent)
In-Reply-To: <552E7D91.4050808@redhat.com>
References: <55158471.4050009@redhat.com>	<5515916D.9010703@redhat.com>		<551912F2.4020204@redhat.com>	<551ACD21.4070608@redhat.com>		<551BFC2D.8080601@redhat.com>
	<551C1295.2040809@redhat.com>	 <552D360B.5080902@redhat.com>
	<1429090620.7465.13.camel@mylittlepony.linaroharston>
	<552E7AEA.3060907@redhat.com> <552E7B56.7030200@redhat.com>
	<552E7D91.4050808@redhat.com>
Message-ID: <552E7E09.5080509@redhat.com>

On 04/15/2015 04:02 PM, Andrew Dinn wrote:
> There are clearly a lot of other cases where we generate dmb
> instructions that are redundant. That includes various inlined unsafe
> sequences as well as e.g. inlined allocations. So, there is still a lot
> of room for the predicates that guard the 3 membar generation rules and
> the ldar/stlr rules to be extended to detect other signature input node
> sequences.

OK.  For allocations we're fine, I think.  I'd really like all forms of
CAS to use ldaxr/stlxr.

Andrew.


From aph at redhat.com  Wed Apr 15 16:36:48 2015
From: aph at redhat.com (Andrew Haley)
Date: Wed, 15 Apr 2015 17:36:48 +0100
Subject: [aarch64-port-dev ] Proposed patch for C2 volatile generation
 (resent)
In-Reply-To: <552E7E09.5080509@redhat.com>
References: <55158471.4050009@redhat.com>	<5515916D.9010703@redhat.com>		<551912F2.4020204@redhat.com>	<551ACD21.4070608@redhat.com>		<551BFC2D.8080601@redhat.com>
	<551C1295.2040809@redhat.com>	 <552D360B.5080902@redhat.com>
	<1429090620.7465.13.camel@mylittlepony.linaroharston>
	<552E7AEA.3060907@redhat.com> <552E7B56.7030200@redhat.com>
	<552E7D91.4050808@redhat.com> <552E7E09.5080509@redhat.com>
Message-ID: <552E93A0.7040705@redhat.com>

Looks pretty good.

There is one remaining dmb(Assembler::SY).  Please make it
dmb(Assembler::ISH).

It would be super-nice also to fix getObjectVolatile and its friends
at the same time.  But you might prefer to address those with a
different patch.

compareAndSwapObject is really fugly.  I would love, LOVE, to see
it fixed to use ldaxr/stlxr.  :-)

I see this in ConcurrentHashMap::transfer:

  0x000003ffa51f5f68: dmb	ish
  0x000003ffa51f5f6c: lsr	x10, x0, #9
  0x000003ffa51f5f70: str	w17, [x0,#20]
  0x000003ffa51f5f74: adrp	x17, word_map_base  ;   {external_word}
  0x000003ffa51f5f78: strb	wzr, [x17,x10,lsl #0]
  0x000003ffa51f5f7c: dmb	ish             ;*putfield val
                                                ; - java.util.concurrent.ConcurrentHashMap$Node::<init>@16 (line 628)
                                                ; - java.util.concurrent.ConcurrentHashMap::transfer at 505 (line 2452)

  0x000003ffa51f5f80: dmb	ish
  0x000003ffa51f5f84: mov	x10, x5
  0x000003ffa51f5f88: lsr	x17, x0, #9
  0x000003ffa51f5f8c: str	w10, [x0,#24]
  0x000003ffa51f5f90: adrp	x10, word_map_base  ;   {external_word}
  0x000003ffa51f5f94: strb	wzr, [x10,x17,lsl #0]
  0x000003ffa51f5f98: dmb	ish             ;*putfield next
                                                ; - java.util.concurrent.ConcurrentHashMap$Node::<init>@22 (line 629)
                                                ; - java.util.concurrent.ConcurrentHashMap::transfer at 505 (line 2452)

  0x000003ffa51f5f9c: dmb	ish             ;*aload
                                                ; - java.util.concurrent.ConcurrentHashMap::transfer at 510 (line 2447)

That does look like a lot of DMBs!

In fact, much of ConcurrentHashMap::transfer looks pretty grim.  Many
redundant barriers.  I think this is all to do with the mix of
Unsafe operations and volatile fields.

There's a bug in C2 where elided constructors have a memory barrier which
doesn't get elided.  That bug is supposed to have been fixed, but I
can still see its effect.  It's unrelated to what you're doing here,
but it does lead to a lot of mysterious DMBs.

Andrew.


From aph at redhat.com  Wed Apr 15 17:12:52 2015
From: aph at redhat.com (Andrew Haley)
Date: Wed, 15 Apr 2015 18:12:52 +0100
Subject: [aarch64-port-dev ] Proposed patch for C2 volatile generation
 (resent)
In-Reply-To: <552E93A0.7040705@redhat.com>
References: <55158471.4050009@redhat.com>	<5515916D.9010703@redhat.com>		<551912F2.4020204@redhat.com>	<551ACD21.4070608@redhat.com>		<551BFC2D.8080601@redhat.com>	<551C1295.2040809@redhat.com>	
	<552D360B.5080902@redhat.com>	<1429090620.7465.13.camel@mylittlepony.linaroharston>	<552E7AEA.3060907@redhat.com>
	<552E7B56.7030200@redhat.com>	<552E7D91.4050808@redhat.com>
	<552E7E09.5080509@redhat.com> <552E93A0.7040705@redhat.com>
Message-ID: <552E9C14.9000907@redhat.com>

To run jcstress with the correct WhiteBox libs:

cd /local/aarch64/dev/test/

find . -name *.java | xargs javac

/local/aarch64/dev/build/linux-aarch64-normal-server-release/jdk/bin/java -XX:+UnlockDiagnosticVMOptions -XX:+WhiteBoxAPI -XX:-RestrictContended -Xbootclasspath/a:/local/aarch64/dev/test/lib/:tests-all/target/jcstress.jar -jar tests-all/target/jcstress.jar

Andrew.

From adinn at redhat.com  Thu Apr 16 08:43:59 2015
From: adinn at redhat.com (Andrew Dinn)
Date: Thu, 16 Apr 2015 09:43:59 +0100
Subject: [aarch64-port-dev ] Proposed patch for C2 volatile generation
 (resent)
In-Reply-To: <552E9C14.9000907@redhat.com>
References: <55158471.4050009@redhat.com>	<5515916D.9010703@redhat.com>		<551912F2.4020204@redhat.com>	<551ACD21.4070608@redhat.com>		<551BFC2D.8080601@redhat.com>	<551C1295.2040809@redhat.com>	
	<552D360B.5080902@redhat.com>	<1429090620.7465.13.camel@mylittlepony.linaroharston>	<552E7AEA.3060907@redhat.com>
	<552E7B56.7030200@redhat.com>	<552E7D91.4050808@redhat.com>
	<552E7E09.5080509@redhat.com> <552E93A0.7040705@redhat.com>
	<552E9C14.9000907@redhat.com>
Message-ID: <552F764F.7080509@redhat.com>

On 15/04/15 18:12, Andrew Haley wrote:
> To run jcstress with the correct WhiteBox libs:
> 
> cd /local/aarch64/dev/test/
> 
> find . -name *.java | xargs javac
> 
> /local/aarch64/dev/build/linux-aarch64-normal-server-release/jdk/bin/java -XX:+UnlockDiagnosticVMOptions -XX:+WhiteBoxAPI -XX:-RestrictContended -Xbootclasspath/a:/local/aarch64/dev/test/lib/:tests-all/target/jcstress.jar -jar tests-all/target/jcstress.jar

Ah, ok . . . where

  "/local/aarch64/dev"

should be replaced with the relevant jdk9 hg checkout top level dir.

regards,


Andrew Dinn
-----------


From edward.nevill at linaro.org  Thu Apr 16 09:05:27 2015
From: edward.nevill at linaro.org (Edward Nevill)
Date: Thu, 16 Apr 2015 10:05:27 +0100
Subject: [aarch64-port-dev ] vectorisation experiment
Message-ID: <1429175127.4866.25.camel@mylittlepony.linaroharston>

Hi,

I have been experimenting with adding vectorisation to aarch64 jdk9. So I started with LoadVector, AddV, StoreVector and Replicate as in the attached patch.

The following show a simple test case and the resultant asm output (I have highlighted the vector instructions with <<<<<)

  static void test_addv(long[] a0, long[] a1, long b) {
    for (int i = 0; i < a0.length; i+=1) {
      a0[i] = (long)(a1[i]+b);
    }
  }

  0x000003ffad0ea070: sbfiz     x10, x11, #3, #32
  0x000003ffad0ea074: add       x12, x2, x10
  0x000003ffad0ea078: add       x12, x12, #0x10
  0x000003ffad0ea07c: ld1       {v17.16b}, [x12]           <<<<<
  0x000003ffad0ea080: sbfiz     x12, x11, #3, #32
  0x000003ffad0ea084: add       x13, x2, x12
  0x000003ffad0ea088: add       v17.2d, v17.2d, v16.2d     <<<<<
  0x000003ffad0ea08c: add       x14, x13, #0x20
  0x000003ffad0ea090: ld1       {v18.16b}, [x14]           <<<<<
  0x000003ffad0ea094: add       x10, x1, x10
  0x000003ffad0ea098: add       x10, x10, #0x10
  0x000003ffad0ea09c: add       v18.2d, v18.2d, v16.2d     <<<<<
  0x000003ffad0ea0a0: add       x14, x13, #0x30
  0x000003ffad0ea0a4: ld1       {v19.16b}, [x14]           <<<<<
  0x000003ffad0ea0a8: add       x12, x1, x12
  0x000003ffad0ea0ac: add       x14, x12, #0x20
  0x000003ffad0ea0b0: add       x13, x13, #0x40
  0x000003ffad0ea0b4: add       v19.2d, v19.2d, v16.2d     <<<<<
  0x000003ffad0ea0b8: ld1       {v20.16b}, [x13]  ;*laload <<<<<
                                                ; - TestLongVect::test_addv at 16 (line 869)

  0x000003ffad0ea0bc: st1       {v17.16b}, [x10]           <<<<<
  0x000003ffad0ea0c0: st1       {v18.16b}, [x14]           <<<<<
  0x000003ffad0ea0c4: add       x10, x12, #0x30
  0x000003ffad0ea0c8: st1       {v19.16b}, [x10]           <<<<<
  0x000003ffad0ea0cc: add       v17.2d, v20.2d, v16.2d     <<<<<
  0x000003ffad0ea0d0: add       x10, x12, #0x40
  0x000003ffad0ea0d4: st1       {v17.16b}, [x10]  ;*lastore<<<<<
                                                ; - TestLongVect::test_addv at 19 (line 869)

  0x000003ffad0ea0d8: add       w11, w11, #0x8  ;*iinc
                                                ; - TestLongVect::test_addv at 20 (line 868)

  0x000003ffad0ea0dc: cmp       w11, w16
  0x000003ffad0ea0e0: b.lt      0x000003ffad0ea070  ;*if_icmpge


Now at the moment this just using single vector register load/store. Eg.

  0x000003ffad0ea090: ld1       {v18.16b}, [x14]
..
  0x000003ffad0ea0bc: st1       {v17.16b}, [x10]           <<<<<

However aarch64 is capable of loading/storing up to 4 vector registers at a time. Eg.

 ld1    {v18,v19,v20,v21}, [x14]
 st1    {v17,v18,v19.v20}, [x10]

In these instructions the 4 registers must be sequential (ie. {v(N), v(N+1), v(N+2), v(N+3) }

It would obviously improve the above loop greatly if we could use these.

My idea for doing this is to express this as a single 512 bit vector register.

My question is how can I define this using 'reg_def' and 'reg_class' in aarch64.ad.

I need some way to say to regalloc that if it allocates v(N) it must also allocate v(N+1), v(N+2), v(N+3).

x86 has 256 bit XMM registers, eg.

reg_def XMM0 ( SOC, SOC, Op_RegF, 0, xmm0->as_VMReg());
reg_def XMM0b( SOC, SOC, Op_RegF, 0, xmm0->as_VMReg()->next(1));
reg_def XMM0c( SOC, SOC, Op_RegF, 0, xmm0->as_VMReg()->next(2));
reg_def XMM0d( SOC, SOC, Op_RegF, 0, xmm0->as_VMReg()->next(3));
reg_def XMM0e( SOC, SOC, Op_RegF, 0, xmm0->as_VMReg()->next(4));
reg_def XMM0f( SOC, SOC, Op_RegF, 0, xmm0->as_VMReg()->next(5));
reg_def XMM0g( SOC, SOC, Op_RegF, 0, xmm0->as_VMReg()->next(6));
reg_def XMM0h( SOC, SOC, Op_RegF, 0, xmm0->as_VMReg()->next(7));

reg_class vectory_reg(XMM0,  XMM0b,  XMM0c,  XMM0d,  XMM0e,  XMM0f,  XMM0g,  XMM0h,
...

but this is not what I need. This is a single register 256 bits long, whereas I need a sort of virtual register which uses 4 physical registers.

Thanks for any help, the documentation on this is not great!
Ed.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: vector.patch
Type: text/x-patch
Size: 6542 bytes
Desc: not available
URL: <http://mail.openjdk.java.net/pipermail/aarch64-port-dev/attachments/20150416/26fa8ee0/vector.patch>

From edward.nevill at linaro.org  Thu Apr 16 15:12:41 2015
From: edward.nevill at linaro.org (Edward Nevill)
Date: Thu, 16 Apr 2015 16:12:41 +0100
Subject: [aarch64-port-dev ] RFR: merge jdk8 up to jdk8u45-b14
Message-ID: <1429197161.19033.15.camel@mylittlepony.linaroharston>

Hi,

The following webrevs merge the the aarch64 jdk8 tree up to jdk8u45-b14.

http://openjdk.linaro.org/merge_u45_b14/corba/webrev/
http://openjdk.linaro.org/merge_u45_b14/hotspot/webrev/
http://openjdk.linaro.org/merge_u45_b14/jaxp/webrev/
http://openjdk.linaro.org/merge_u45_b14/jaxws/webrev/
http://openjdk.linaro.org/merge_u45_b14/jdk/webrev/
http://openjdk.linaro.org/merge_u45_b14/jdk8/webrev/
http://openjdk.linaro.org/merge_u45_b14/langtools/webrev/


Tested with jtreg hotspot and langtools

Before:

hotspot: Test results: passed: 662; failed: 7
langtools: Test results: passed: 3,069; error: 4

After

hotspot: Test results: passed: 662; failed: 7
langtools: Test results: passed: 3,069; error: 4

I have also built and smoke tested the following build options:-

- client
- zero
- fastdebug
- slowdebug
- builtin sim
- cross compile
- native

The changes below are the aarch64 specific changes

OK to push?
Ed.

--- jdk changes --------------------------------------------------------
# HG changeset patch
# User enevill
# Date 1429193152 -3600
#      Thu Apr 16 15:05:52 2015 +0100
# Node ID 2627c4dba1df9a09a76663d2fdf7cac8b20b191e
# Parent  8ee42e32cba3a252cd6d7a79b5016bf414d34080
Fix build for aarch64.

diff -r 8ee42e32cba3 -r 2627c4dba1df src/share/native/sun/awt/libpng/pngpriv.h
--- a/src/share/native/sun/awt/libpng/pngpriv.h	Thu Apr 16 11:37:04 2015 +0100
+++ b/src/share/native/sun/awt/libpng/pngpriv.h	Thu Apr 16 15:05:52 2015 +0100
@@ -151,8 +151,8 @@
     * Note that gcc-4.9 defines __ARM_NEON instead of __ARM_NEON__, so we
     * check both variants.
     */
-#  if (defined(__ARM_NEON__) || defined(__ARM_NEON)) && \
-   defined(PNG_ALIGNED_MEMORY_SUPPORTED)
+#  if ((defined(__ARM_NEON__) || defined(__ARM_NEON)) && \
+   defined(PNG_ALIGNED_MEMORY_SUPPORTED)) && defined(__arm__)
 #     define PNG_ARM_NEON_OPT 2
 #  else
 #     define PNG_ARM_NEON_OPT 0
--------------------------------------------------------------------------

Support has been added for ARM_NEON, but aarch64 gcc also defines ARM_NEON so add __arm__ to the condition to make it build for aarch64.

--- hotspot changes ------------------------------------------------------
# HG changeset patch
# User enevill
# Date 1429193191 -3600
#      Thu Apr 16 15:06:31 2015 +0100
# Node ID 70d4f640f9311882a0ac04b0c8903f627fd9f866
# Parent  de82c08da80610a07f8922a33a94e56527f2006a
Fix build for aarch64/zero

diff -r de82c08da806 -r 70d4f640f931 src/share/vm/interpreter/interpreterRuntime.cpp
--- a/src/share/vm/interpreter/interpreterRuntime.cpp	Thu Apr 16 11:36:19 2015 +0100
+++ b/src/share/vm/interpreter/interpreterRuntime.cpp	Thu Apr 16 15:06:31 2015 +0100
@@ -401,6 +401,7 @@
   int                handler_bci;
   int                current_bci = bci(thread);
 
+#ifndef CC_INTERP
   if (thread->frames_to_pop_failed_realloc() > 0) {
     // Allocation of scalar replaced object used in this frame
     // failed. Unconditionally pop the frame.
@@ -412,6 +413,7 @@
     thread->set_do_not_unlock_if_synchronized(true);
     return Interpreter::remove_activation_entry();
   }
+#endif
 
   // Need to do this check first since when _do_not_unlock_if_synchronized
   // is set, we don't want to trigger any classloading which may make calls
--------------------------------------------------------------------------

remove_activation_entry is undefined in zero so conditionalise this section of code out. this section of code is only executed after deopt so cannot happen on zero.




From aph at redhat.com  Thu Apr 16 15:21:18 2015
From: aph at redhat.com (Andrew Haley)
Date: Thu, 16 Apr 2015 16:21:18 +0100
Subject: [aarch64-port-dev ] RFR: merge jdk8 up to jdk8u45-b14
In-Reply-To: <1429197161.19033.15.camel@mylittlepony.linaroharston>
References: <1429197161.19033.15.camel@mylittlepony.linaroharston>
Message-ID: <552FD36E.3010003@redhat.com>

OK, thanks.

Andrew.

From edward.nevill at gmail.com  Thu Apr 16 15:26:07 2015
From: edward.nevill at gmail.com (edward.nevill at gmail.com)
Date: Thu, 16 Apr 2015 15:26:07 +0000
Subject: [aarch64-port-dev ] hg: aarch64-port/jdk8: 50 new changesets
Message-ID: <201504161526.t3GFQ7aC003278@aojmv0008>

Changeset: 291438571a1e
Author:    asaha
Date:      2014-10-07 08:39 -0700
URL:       http://hg.openjdk.java.net/aarch64-port/jdk8/rev/291438571a1e

Merge

! .hgtags

Changeset: 3b367702e163
Author:    asaha
Date:      2014-10-09 12:06 -0700
URL:       http://hg.openjdk.java.net/aarch64-port/jdk8/rev/3b367702e163

Added tag jdk8u45-b00 for changeset ec4bcc6e4dcf

! .hgtags

Changeset: cfb62cf941e1
Author:    asaha
Date:      2014-10-09 13:16 -0700
URL:       http://hg.openjdk.java.net/aarch64-port/jdk8/rev/cfb62cf941e1

Merge

! .hgtags

Changeset: 288e406a25ca
Author:    asaha
Date:      2014-10-14 11:37 -0700
URL:       http://hg.openjdk.java.net/aarch64-port/jdk8/rev/288e406a25ca

Merge

! .hgtags

Changeset: 27436b422886
Author:    asaha
Date:      2014-10-20 23:00 -0700
URL:       http://hg.openjdk.java.net/aarch64-port/jdk8/rev/27436b422886

Merge

! .hgtags

Changeset: a676d2d8af0d
Author:    asaha
Date:      2014-10-24 17:04 -0700
URL:       http://hg.openjdk.java.net/aarch64-port/jdk8/rev/a676d2d8af0d

Merge

! .hgtags

Changeset: e6b1b800663d
Author:    asaha
Date:      2014-11-06 09:38 -0800
URL:       http://hg.openjdk.java.net/aarch64-port/jdk8/rev/e6b1b800663d

Merge

! .hgtags

Changeset: 07f2cc0146b1
Author:    asaha
Date:      2014-11-19 14:54 -0800
URL:       http://hg.openjdk.java.net/aarch64-port/jdk8/rev/07f2cc0146b1

Merge

! .hgtags

Changeset: 4d7cb7c9be8c
Author:    asaha
Date:      2014-12-01 11:27 -0800
URL:       http://hg.openjdk.java.net/aarch64-port/jdk8/rev/4d7cb7c9be8c

Merge

! .hgtags

Changeset: 635ba0c81b89
Author:    asaha
Date:      2014-12-12 14:27 -0800
URL:       http://hg.openjdk.java.net/aarch64-port/jdk8/rev/635ba0c81b89

Merge

! .hgtags

Changeset: 5b4bcd8fb45c
Author:    asaha
Date:      2014-12-15 15:37 -0800
URL:       http://hg.openjdk.java.net/aarch64-port/jdk8/rev/5b4bcd8fb45c

Added tag jdk8u45-b01 for changeset 635ba0c81b89

! .hgtags

Changeset: 9688cf673d02
Author:    asaha
Date:      2014-12-17 09:10 -0800
URL:       http://hg.openjdk.java.net/aarch64-port/jdk8/rev/9688cf673d02

Merge

! .hgtags

Changeset: 09578f5efb22
Author:    asaha
Date:      2014-12-22 09:23 -0800
URL:       http://hg.openjdk.java.net/aarch64-port/jdk8/rev/09578f5efb22

Merge

! .hgtags

Changeset: ec5219b942d2
Author:    katleman
Date:      2014-11-19 11:27 -0800
URL:       http://hg.openjdk.java.net/aarch64-port/jdk8/rev/ec5219b942d2

Added tag jdk8u25-b32 for changeset cc8541804eb4

! .hgtags

Changeset: e3dd9d54a8f3
Author:    asaha
Date:      2014-12-03 09:22 -0800
URL:       http://hg.openjdk.java.net/aarch64-port/jdk8/rev/e3dd9d54a8f3

Merge

! .hgtags

Changeset: adf189416769
Author:    asaha
Date:      2014-12-12 08:45 -0800
URL:       http://hg.openjdk.java.net/aarch64-port/jdk8/rev/adf189416769

Merge

! .hgtags

Changeset: d241e568a9d8
Author:    asaha
Date:      2014-12-18 14:18 -0800
URL:       http://hg.openjdk.java.net/aarch64-port/jdk8/rev/d241e568a9d8

Merge

! .hgtags

Changeset: d66f9edec2fc
Author:    asaha
Date:      2014-12-17 08:42 -0800
URL:       http://hg.openjdk.java.net/aarch64-port/jdk8/rev/d66f9edec2fc

Added tag jdk8u25-b33 for changeset ec5219b942d2

! .hgtags

Changeset: a198f93b1e0b
Author:    asaha
Date:      2014-12-18 14:27 -0800
URL:       http://hg.openjdk.java.net/aarch64-port/jdk8/rev/a198f93b1e0b

Merge

! .hgtags

Changeset: 801c65bb74b7
Author:    asaha
Date:      2014-12-22 12:08 -0800
URL:       http://hg.openjdk.java.net/aarch64-port/jdk8/rev/801c65bb74b7

Merge

! .hgtags

Changeset: a6e7aa9b35a7
Author:    asaha
Date:      2014-12-22 13:59 -0800
URL:       http://hg.openjdk.java.net/aarch64-port/jdk8/rev/a6e7aa9b35a7

Added tag jdk8u45-b02 for changeset 801c65bb74b7

! .hgtags

Changeset: f9d660ee02c5
Author:    asaha
Date:      2014-12-29 14:42 -0800
URL:       http://hg.openjdk.java.net/aarch64-port/jdk8/rev/f9d660ee02c5

Merge

! .hgtags

Changeset: 727eaf7fd774
Author:    asaha
Date:      2015-01-05 09:25 -0800
URL:       http://hg.openjdk.java.net/aarch64-port/jdk8/rev/727eaf7fd774

Merge

! .hgtags

Changeset: a1682688c9ae
Author:    asaha
Date:      2015-01-05 09:54 -0800
URL:       http://hg.openjdk.java.net/aarch64-port/jdk8/rev/a1682688c9ae

Merge

! .hgtags

Changeset: 99c79d831525
Author:    asaha
Date:      2015-01-12 06:47 -0800
URL:       http://hg.openjdk.java.net/aarch64-port/jdk8/rev/99c79d831525

Added tag jdk8u31-b31 for changeset a198f93b1e0b

! .hgtags

Changeset: 7d11a7eee8c0
Author:    asaha
Date:      2015-01-12 06:54 -0800
URL:       http://hg.openjdk.java.net/aarch64-port/jdk8/rev/7d11a7eee8c0

Merge

! .hgtags

Changeset: 9d36d975bb20
Author:    asaha
Date:      2015-01-12 13:48 -0800
URL:       http://hg.openjdk.java.net/aarch64-port/jdk8/rev/9d36d975bb20

Added tag jdk8u45-b03 for changeset 7d11a7eee8c0

! .hgtags

Changeset: 16f78e229a52
Author:    asaha
Date:      2015-01-19 12:25 -0800
URL:       http://hg.openjdk.java.net/aarch64-port/jdk8/rev/16f78e229a52

Merge

! .hgtags

Changeset: cf4ebf474139
Author:    asaha
Date:      2015-01-20 09:53 -0800
URL:       http://hg.openjdk.java.net/aarch64-port/jdk8/rev/cf4ebf474139

Added tag jdk8u31-b32 for changeset 99c79d831525

! .hgtags

Changeset: 3d79ef8a102f
Author:    asaha
Date:      2015-01-20 10:04 -0800
URL:       http://hg.openjdk.java.net/aarch64-port/jdk8/rev/3d79ef8a102f

Merge

! .hgtags

Changeset: 5ecad11d91de
Author:    asaha
Date:      2015-01-20 12:28 -0800
URL:       http://hg.openjdk.java.net/aarch64-port/jdk8/rev/5ecad11d91de

Added tag jdk8u45-b04 for changeset 3d79ef8a102f

! .hgtags

Changeset: 45f8fc9d3002
Author:    asaha
Date:      2015-01-22 15:38 -0800
URL:       http://hg.openjdk.java.net/aarch64-port/jdk8/rev/45f8fc9d3002

Merge

! .hgtags

Changeset: 84337249a520
Author:    asaha
Date:      2015-01-26 11:59 -0800
URL:       http://hg.openjdk.java.net/aarch64-port/jdk8/rev/84337249a520

Added tag jdk8u45-b05 for changeset 45f8fc9d3002

! .hgtags

Changeset: 9a5843fdd2cf
Author:    asaha
Date:      2015-01-28 15:24 -0800
URL:       http://hg.openjdk.java.net/aarch64-port/jdk8/rev/9a5843fdd2cf

Merge

! .hgtags

Changeset: 3d0f3761d32a
Author:    asaha
Date:      2015-02-02 13:28 -0800
URL:       http://hg.openjdk.java.net/aarch64-port/jdk8/rev/3d0f3761d32a

Added tag jdk8u45-b06 for changeset 9a5843fdd2cf

! .hgtags

Changeset: 74ef61db0fe0
Author:    asaha
Date:      2015-02-04 13:08 -0800
URL:       http://hg.openjdk.java.net/aarch64-port/jdk8/rev/74ef61db0fe0

Merge

! .hgtags

Changeset: 47da174904ee
Author:    asaha
Date:      2015-02-09 09:05 -0800
URL:       http://hg.openjdk.java.net/aarch64-port/jdk8/rev/47da174904ee

Added tag jdk8u45-b07 for changeset 74ef61db0fe0

! .hgtags

Changeset: 0c10bc335563
Author:    asaha
Date:      2015-02-11 14:09 -0800
URL:       http://hg.openjdk.java.net/aarch64-port/jdk8/rev/0c10bc335563

Merge

! .hgtags

Changeset: 733d16eb42cb
Author:    asaha
Date:      2015-02-16 11:04 -0800
URL:       http://hg.openjdk.java.net/aarch64-port/jdk8/rev/733d16eb42cb

Added tag jdk8u45-b08 for changeset 0c10bc335563

! .hgtags

Changeset: 9a343fd13810
Author:    asaha
Date:      2015-02-23 14:47 -0800
URL:       http://hg.openjdk.java.net/aarch64-port/jdk8/rev/9a343fd13810

Added tag jdk8u45-b09 for changeset 733d16eb42cb

! .hgtags

Changeset: 31638fdf1ae4
Author:    asaha
Date:      2015-03-02 11:13 -0800
URL:       http://hg.openjdk.java.net/aarch64-port/jdk8/rev/31638fdf1ae4

Added tag jdk8u45-b10 for changeset 9a343fd13810

! .hgtags

Changeset: 12deacac8257
Author:    asaha
Date:      2015-03-07 10:24 -0800
URL:       http://hg.openjdk.java.net/aarch64-port/jdk8/rev/12deacac8257

Added tag jdk8u40-b26 for changeset 7a552439756e

! .hgtags

Changeset: 6738b8755c80
Author:    asaha
Date:      2015-03-07 16:24 -0800
URL:       http://hg.openjdk.java.net/aarch64-port/jdk8/rev/6738b8755c80

Merge

! .hgtags

Changeset: 9c9f663f6633
Author:    asaha
Date:      2015-03-09 12:34 -0700
URL:       http://hg.openjdk.java.net/aarch64-port/jdk8/rev/9c9f663f6633

Added tag jdk8u45-b11 for changeset 6738b8755c80

! .hgtags

Changeset: 8b0ee2956b4d
Author:    asaha
Date:      2015-03-10 15:33 -0700
URL:       http://hg.openjdk.java.net/aarch64-port/jdk8/rev/8b0ee2956b4d

8074662: Update 3rd party readme and license for LibPNG v 1.6.16
Reviewed-by: jeff

! THIRD_PARTY_README

Changeset: bb24fbcc546f
Author:    asaha
Date:      2015-03-12 20:15 -0700
URL:       http://hg.openjdk.java.net/aarch64-port/jdk8/rev/bb24fbcc546f

Added tag jdk8u40-b27 for changeset 12deacac8257

! .hgtags

Changeset: 54709b761404
Author:    asaha
Date:      2015-03-16 09:11 -0700
URL:       http://hg.openjdk.java.net/aarch64-port/jdk8/rev/54709b761404

Merge

! .hgtags

Changeset: 6b2f1bf5c728
Author:    asaha
Date:      2015-03-16 11:19 -0700
URL:       http://hg.openjdk.java.net/aarch64-port/jdk8/rev/6b2f1bf5c728

Added tag jdk8u45-b12 for changeset 54709b761404

! .hgtags

Changeset: 15b679d327da
Author:    asaha
Date:      2015-03-17 11:22 -0700
URL:       http://hg.openjdk.java.net/aarch64-port/jdk8/rev/15b679d327da

Added tag jdk8u45-b13 for changeset 6b2f1bf5c728

! .hgtags

Changeset: e9afe4de1efe
Author:    enevill
Date:      2015-04-16 11:35 +0100
URL:       http://hg.openjdk.java.net/aarch64-port/jdk8/rev/e9afe4de1efe

Merge up to jdk8u45-b14

! .hgtags


From edward.nevill at gmail.com  Thu Apr 16 15:26:32 2015
From: edward.nevill at gmail.com (edward.nevill at gmail.com)
Date: Thu, 16 Apr 2015 15:26:32 +0000
Subject: [aarch64-port-dev ] hg: aarch64-port/jdk8/corba: 50 new changesets
Message-ID: <201504161526.t3GFQWsl003392@aojmv0008>

Changeset: 9eca1673008a
Author:    asaha
Date:      2014-10-07 08:40 -0700
URL:       http://hg.openjdk.java.net/aarch64-port/jdk8/corba/rev/9eca1673008a

Merge

! .hgtags

Changeset: 99318f8b0d2b
Author:    asaha
Date:      2014-10-09 12:06 -0700
URL:       http://hg.openjdk.java.net/aarch64-port/jdk8/corba/rev/99318f8b0d2b

Added tag jdk8u45-b00 for changeset 5761efbc739f

! .hgtags

Changeset: 392b308ab176
Author:    asaha
Date:      2014-10-09 13:16 -0700
URL:       http://hg.openjdk.java.net/aarch64-port/jdk8/corba/rev/392b308ab176

Merge

! .hgtags

Changeset: 835263663f74
Author:    asaha
Date:      2014-10-14 11:37 -0700
URL:       http://hg.openjdk.java.net/aarch64-port/jdk8/corba/rev/835263663f74

Merge

! .hgtags

Changeset: e60c0a6d6330
Author:    asaha
Date:      2014-10-20 23:00 -0700
URL:       http://hg.openjdk.java.net/aarch64-port/jdk8/corba/rev/e60c0a6d6330

Merge

! .hgtags

Changeset: ef278f51b59f
Author:    asaha
Date:      2014-10-24 17:05 -0700
URL:       http://hg.openjdk.java.net/aarch64-port/jdk8/corba/rev/ef278f51b59f

Merge

! .hgtags

Changeset: ef001b9debf4
Author:    asaha
Date:      2014-11-06 09:38 -0800
URL:       http://hg.openjdk.java.net/aarch64-port/jdk8/corba/rev/ef001b9debf4

Merge

! .hgtags

Changeset: 449190e46be9
Author:    asaha
Date:      2014-11-19 14:55 -0800
URL:       http://hg.openjdk.java.net/aarch64-port/jdk8/corba/rev/449190e46be9

Merge

! .hgtags

Changeset: d86e1a7e2d74
Author:    asaha
Date:      2014-12-01 11:27 -0800
URL:       http://hg.openjdk.java.net/aarch64-port/jdk8/corba/rev/d86e1a7e2d74

Merge

! .hgtags

Changeset: 6a52852476c9
Author:    asaha
Date:      2014-12-12 14:27 -0800
URL:       http://hg.openjdk.java.net/aarch64-port/jdk8/corba/rev/6a52852476c9

Merge

! .hgtags

Changeset: 310ad4a9c136
Author:    asaha
Date:      2014-12-15 15:37 -0800
URL:       http://hg.openjdk.java.net/aarch64-port/jdk8/corba/rev/310ad4a9c136

Added tag jdk8u45-b01 for changeset 6a52852476c9

! .hgtags

Changeset: ce00072d4361
Author:    asaha
Date:      2014-12-17 09:10 -0800
URL:       http://hg.openjdk.java.net/aarch64-port/jdk8/corba/rev/ce00072d4361

Merge

! .hgtags

Changeset: bd15bc486b21
Author:    asaha
Date:      2014-12-22 09:23 -0800
URL:       http://hg.openjdk.java.net/aarch64-port/jdk8/corba/rev/bd15bc486b21

Merge

! .hgtags

Changeset: c123ac2adfdc
Author:    katleman
Date:      2014-11-19 11:27 -0800
URL:       http://hg.openjdk.java.net/aarch64-port/jdk8/corba/rev/c123ac2adfdc

Added tag jdk8u25-b32 for changeset 6617e1de7aa5

! .hgtags

Changeset: af03ebe52440
Author:    asaha
Date:      2014-12-03 09:22 -0800
URL:       http://hg.openjdk.java.net/aarch64-port/jdk8/corba/rev/af03ebe52440

Merge

! .hgtags

Changeset: dcbfa47c44af
Author:    asaha
Date:      2014-12-12 08:45 -0800
URL:       http://hg.openjdk.java.net/aarch64-port/jdk8/corba/rev/dcbfa47c44af

Merge

! .hgtags

Changeset: 4ebcff02c641
Author:    asaha
Date:      2014-12-18 14:19 -0800
URL:       http://hg.openjdk.java.net/aarch64-port/jdk8/corba/rev/4ebcff02c641

Merge

! .hgtags

Changeset: 0e6a9a245ca3
Author:    asaha
Date:      2014-12-17 08:42 -0800
URL:       http://hg.openjdk.java.net/aarch64-port/jdk8/corba/rev/0e6a9a245ca3

Added tag jdk8u25-b33 for changeset c123ac2adfdc

! .hgtags

Changeset: 705d3a4298f4
Author:    asaha
Date:      2014-12-18 14:28 -0800
URL:       http://hg.openjdk.java.net/aarch64-port/jdk8/corba/rev/705d3a4298f4

Merge

! .hgtags

Changeset: 3b9d342f9f58
Author:    asaha
Date:      2014-12-22 12:09 -0800
URL:       http://hg.openjdk.java.net/aarch64-port/jdk8/corba/rev/3b9d342f9f58

Merge

! .hgtags

Changeset: d803709763bd
Author:    asaha
Date:      2014-12-22 14:00 -0800
URL:       http://hg.openjdk.java.net/aarch64-port/jdk8/corba/rev/d803709763bd

Added tag jdk8u45-b02 for changeset 3b9d342f9f58

! .hgtags

Changeset: f731ed01021f
Author:    asaha
Date:      2014-12-29 14:42 -0800
URL:       http://hg.openjdk.java.net/aarch64-port/jdk8/corba/rev/f731ed01021f

Merge

! .hgtags

Changeset: b367d1f93783
Author:    asaha
Date:      2015-01-05 09:25 -0800
URL:       http://hg.openjdk.java.net/aarch64-port/jdk8/corba/rev/b367d1f93783

Merge

! .hgtags

Changeset: 72d116eea419
Author:    asaha
Date:      2015-01-05 09:54 -0800
URL:       http://hg.openjdk.java.net/aarch64-port/jdk8/corba/rev/72d116eea419

Merge

! .hgtags

Changeset: 072d325a052a
Author:    asaha
Date:      2015-01-12 06:48 -0800
URL:       http://hg.openjdk.java.net/aarch64-port/jdk8/corba/rev/072d325a052a

Added tag jdk8u31-b31 for changeset 705d3a4298f4

! .hgtags

Changeset: d3678799ed35
Author:    asaha
Date:      2015-01-12 06:55 -0800
URL:       http://hg.openjdk.java.net/aarch64-port/jdk8/corba/rev/d3678799ed35

Merge

! .hgtags

Changeset: 0035f7ab98d1
Author:    asaha
Date:      2015-01-12 13:48 -0800
URL:       http://hg.openjdk.java.net/aarch64-port/jdk8/corba/rev/0035f7ab98d1

Added tag jdk8u45-b03 for changeset d3678799ed35

! .hgtags

Changeset: cca877060ab7
Author:    asaha
Date:      2015-01-19 12:25 -0800
URL:       http://hg.openjdk.java.net/aarch64-port/jdk8/corba/rev/cca877060ab7

Merge

! .hgtags

Changeset: bfd820cde577
Author:    asaha
Date:      2015-01-20 09:53 -0800
URL:       http://hg.openjdk.java.net/aarch64-port/jdk8/corba/rev/bfd820cde577

Added tag jdk8u31-b32 for changeset 072d325a052a

! .hgtags

Changeset: 9dd8c8e1b0fa
Author:    asaha
Date:      2015-01-20 10:06 -0800
URL:       http://hg.openjdk.java.net/aarch64-port/jdk8/corba/rev/9dd8c8e1b0fa

Merge

! .hgtags

Changeset: ccfe354e5268
Author:    asaha
Date:      2015-01-20 12:28 -0800
URL:       http://hg.openjdk.java.net/aarch64-port/jdk8/corba/rev/ccfe354e5268

Added tag jdk8u45-b04 for changeset 9dd8c8e1b0fa

! .hgtags

Changeset: b82ecb056ae3
Author:    asaha
Date:      2015-01-22 15:39 -0800
URL:       http://hg.openjdk.java.net/aarch64-port/jdk8/corba/rev/b82ecb056ae3

Merge

! .hgtags

Changeset: 8fb014b1f16e
Author:    asaha
Date:      2015-01-26 11:59 -0800
URL:       http://hg.openjdk.java.net/aarch64-port/jdk8/corba/rev/8fb014b1f16e

Added tag jdk8u45-b05 for changeset b82ecb056ae3

! .hgtags

Changeset: f538a9334f09
Author:    asaha
Date:      2015-01-28 15:25 -0800
URL:       http://hg.openjdk.java.net/aarch64-port/jdk8/corba/rev/f538a9334f09

Merge

! .hgtags

Changeset: 0791b2c0b68d
Author:    asaha
Date:      2015-02-02 13:28 -0800
URL:       http://hg.openjdk.java.net/aarch64-port/jdk8/corba/rev/0791b2c0b68d

Added tag jdk8u45-b06 for changeset f538a9334f09

! .hgtags

Changeset: 4dec7b828f1e
Author:    asaha
Date:      2015-02-04 13:09 -0800
URL:       http://hg.openjdk.java.net/aarch64-port/jdk8/corba/rev/4dec7b828f1e

Merge

! .hgtags

Changeset: bd142a6618e8
Author:    asaha
Date:      2015-02-09 09:05 -0800
URL:       http://hg.openjdk.java.net/aarch64-port/jdk8/corba/rev/bd142a6618e8

Added tag jdk8u45-b07 for changeset 4dec7b828f1e

! .hgtags

Changeset: 16cb989c8b62
Author:    asaha
Date:      2015-02-11 14:10 -0800
URL:       http://hg.openjdk.java.net/aarch64-port/jdk8/corba/rev/16cb989c8b62

Merge

! .hgtags

Changeset: ace36a054b7f
Author:    asaha
Date:      2015-02-16 11:04 -0800
URL:       http://hg.openjdk.java.net/aarch64-port/jdk8/corba/rev/ace36a054b7f

Added tag jdk8u45-b08 for changeset 16cb989c8b62

! .hgtags

Changeset: b9ef43c59b42
Author:    asaha
Date:      2015-02-23 14:47 -0800
URL:       http://hg.openjdk.java.net/aarch64-port/jdk8/corba/rev/b9ef43c59b42

Added tag jdk8u45-b09 for changeset ace36a054b7f

! .hgtags

Changeset: 5251f3e06a95
Author:    asaha
Date:      2015-03-02 11:13 -0800
URL:       http://hg.openjdk.java.net/aarch64-port/jdk8/corba/rev/5251f3e06a95

Added tag jdk8u45-b10 for changeset b9ef43c59b42

! .hgtags

Changeset: bd0186cd2419
Author:    asaha
Date:      2015-03-07 10:24 -0800
URL:       http://hg.openjdk.java.net/aarch64-port/jdk8/corba/rev/bd0186cd2419

Added tag jdk8u40-b26 for changeset cab2b99c6bb2

! .hgtags

Changeset: 08c2ce4b6d59
Author:    asaha
Date:      2015-03-07 16:25 -0800
URL:       http://hg.openjdk.java.net/aarch64-port/jdk8/corba/rev/08c2ce4b6d59

Merge

! .hgtags

Changeset: e7479ac875bd
Author:    asaha
Date:      2015-03-09 12:34 -0700
URL:       http://hg.openjdk.java.net/aarch64-port/jdk8/corba/rev/e7479ac875bd

Added tag jdk8u45-b11 for changeset 08c2ce4b6d59

! .hgtags

Changeset: 5658a075180c
Author:    asaha
Date:      2015-03-10 15:33 -0700
URL:       http://hg.openjdk.java.net/aarch64-port/jdk8/corba/rev/5658a075180c

8074662: Update 3rd party readme and license for LibPNG v 1.6.16
Reviewed-by: jeff

! THIRD_PARTY_README

Changeset: 6a3e237a9534
Author:    asaha
Date:      2015-03-12 20:15 -0700
URL:       http://hg.openjdk.java.net/aarch64-port/jdk8/corba/rev/6a3e237a9534

Added tag jdk8u40-b27 for changeset bd0186cd2419

! .hgtags

Changeset: c9bf2543c0c0
Author:    asaha
Date:      2015-03-16 09:11 -0700
URL:       http://hg.openjdk.java.net/aarch64-port/jdk8/corba/rev/c9bf2543c0c0

Merge

! .hgtags

Changeset: 326f02235e7a
Author:    asaha
Date:      2015-03-16 11:19 -0700
URL:       http://hg.openjdk.java.net/aarch64-port/jdk8/corba/rev/326f02235e7a

Added tag jdk8u45-b12 for changeset c9bf2543c0c0

! .hgtags

Changeset: 50fb9bed64c9
Author:    asaha
Date:      2015-03-17 11:22 -0700
URL:       http://hg.openjdk.java.net/aarch64-port/jdk8/corba/rev/50fb9bed64c9

Added tag jdk8u45-b13 for changeset 326f02235e7a

! .hgtags

Changeset: b56fb8bb2bc7
Author:    enevill
Date:      2015-04-16 11:36 +0100
URL:       http://hg.openjdk.java.net/aarch64-port/jdk8/corba/rev/b56fb8bb2bc7

Merge up to jdk8u45-b14

! .hgtags


From edward.nevill at gmail.com  Thu Apr 16 15:26:46 2015
From: edward.nevill at gmail.com (edward.nevill at gmail.com)
Date: Thu, 16 Apr 2015 15:26:46 +0000
Subject: [aarch64-port-dev ] hg: aarch64-port/jdk8/hotspot: 66 new changesets
Message-ID: <201504161526.t3GFQlkb003541@aojmv0008>

Changeset: ca67affe23b5
Author:    asaha
Date:      2014-10-07 08:42 -0700
URL:       http://hg.openjdk.java.net/aarch64-port/jdk8/hotspot/rev/ca67affe23b5

Merge

! .hgtags

Changeset: bfa6d6eeebfe
Author:    asaha
Date:      2014-10-09 12:07 -0700
URL:       http://hg.openjdk.java.net/aarch64-port/jdk8/hotspot/rev/bfa6d6eeebfe

Added tag jdk8u45-b00 for changeset b95f13f05f55

! .hgtags

Changeset: 5d639ca68cf1
Author:    asaha
Date:      2014-10-09 13:16 -0700
URL:       http://hg.openjdk.java.net/aarch64-port/jdk8/hotspot/rev/5d639ca68cf1

Merge

! .hgtags

Changeset: cf78930a882a
Author:    asaha
Date:      2014-10-09 13:22 -0700
URL:       http://hg.openjdk.java.net/aarch64-port/jdk8/hotspot/rev/cf78930a882a

8060073: Increment minor version of HSx for 8u45 and initialize the build number
Reviewed-by: jcoomes

! make/hotspot_version

Changeset: 0366a71eda74
Author:    jmasa
Date:      2014-09-26 17:48 -0400
URL:       http://hg.openjdk.java.net/aarch64-port/jdk8/hotspot/rev/0366a71eda74

8047125: (ref) More phantom object references
Reviewed-by: mchung, dfuchs, ahgross, jmasa, brutisso, mgerdin
Contributed-by: kim.barrett at oracle.com

! src/share/vm/classfile/systemDictionary.cpp
! src/share/vm/classfile/systemDictionary.hpp
! src/share/vm/classfile/vmSymbols.hpp
! src/share/vm/memory/referenceProcessor.cpp
! src/share/vm/memory/referenceProcessor.hpp
! src/share/vm/memory/referenceType.hpp
! src/share/vm/runtime/vmStructs.cpp

Changeset: 22ac20a25842
Author:    mgerdin
Date:      2014-10-09 15:42 +0200
URL:       http://hg.openjdk.java.net/aarch64-port/jdk8/hotspot/rev/22ac20a25842

8055479: TLAB stability
Reviewed-by: brutisso, stefank, ahgross

! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp
! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.hpp
! src/share/vm/gc_implementation/shared/parGCAllocBuffer.hpp
! src/share/vm/memory/threadLocalAllocBuffer.cpp
! src/share/vm/memory/threadLocalAllocBuffer.hpp

Changeset: d25a7e8695dc
Author:    asaha
Date:      2014-10-14 11:38 -0700
URL:       http://hg.openjdk.java.net/aarch64-port/jdk8/hotspot/rev/d25a7e8695dc

Merge

! .hgtags

Changeset: 9c5134750f1d
Author:    jmasa
Date:      2014-10-19 21:00 -0700
URL:       http://hg.openjdk.java.net/aarch64-port/jdk8/hotspot/rev/9c5134750f1d

8059064: Better G1 log caching
Reviewed-by: jmasa, ahgross
Contributed-by: sangheon.kim at oracle.com

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

Changeset: 5f07d936a14e
Author:    hseigel
Date:      2014-10-20 15:14 -0400
URL:       http://hg.openjdk.java.net/aarch64-port/jdk8/hotspot/rev/5f07d936a14e

8058982: Better verification of an exceptional invokespecial
Summary: Throw VerifyError for illegal accesses
Reviewed-by: acorn, ahgross, coleenp

! src/share/vm/classfile/verifier.cpp
! src/share/vm/classfile/verifier.hpp

Changeset: 37179dcf830a
Author:    asaha
Date:      2014-10-20 23:02 -0700
URL:       http://hg.openjdk.java.net/aarch64-port/jdk8/hotspot/rev/37179dcf830a

Merge

! .hgtags
! make/hotspot_version

Changeset: 60a992c821f8
Author:    hseigel
Date:      2014-10-24 15:02 -0400
URL:       http://hg.openjdk.java.net/aarch64-port/jdk8/hotspot/rev/60a992c821f8

8050807: Better performing performance data handling
Reviewed-by: dcubed, dholmes, pnauman, ctornqvi, mschoene
Contributed-by: gerald.thornbrugh at oracle.com

! src/os/bsd/vm/perfMemory_bsd.cpp
! src/os/linux/vm/perfMemory_linux.cpp
! src/os/solaris/vm/perfMemory_solaris.cpp
! src/share/vm/utilities/vmError.cpp

Changeset: 12478c5eb000
Author:    asaha
Date:      2014-10-24 17:09 -0700
URL:       http://hg.openjdk.java.net/aarch64-port/jdk8/hotspot/rev/12478c5eb000

Merge

! .hgtags
- agent/src/share/classes/sun/jvm/hotspot/gc_implementation/g1/HeapRegionSeq.java
! make/hotspot_version
- src/share/vm/gc_implementation/g1/heapRegionSeq.cpp
- src/share/vm/gc_implementation/g1/heapRegionSeq.hpp
- src/share/vm/gc_implementation/g1/heapRegionSeq.inline.hpp
! src/share/vm/runtime/arguments.cpp
- src/share/vm/services/memPtr.cpp
- src/share/vm/services/memPtr.hpp
- src/share/vm/services/memPtrArray.hpp
- src/share/vm/services/memRecorder.cpp
- src/share/vm/services/memRecorder.hpp
- src/share/vm/services/memSnapshot.cpp
- src/share/vm/services/memSnapshot.hpp
- src/share/vm/services/memTrackWorker.cpp
- src/share/vm/services/memTrackWorker.hpp
- test/compiler/intrinsics/mathexact/sanity/Verifier.java
- test/testlibrary/com/oracle/java/testlibrary/DynamicVMOptionChecker.java
- test/testlibrary/com/oracle/java/testlibrary/TestDynamicVMOption.java

Changeset: 5ca2ea5eeff0
Author:    asaha
Date:      2014-10-31 17:09 -0700
URL:       http://hg.openjdk.java.net/aarch64-port/jdk8/hotspot/rev/5ca2ea5eeff0

Merge

! src/os/bsd/vm/perfMemory_bsd.cpp
! src/os/linux/vm/perfMemory_linux.cpp
! src/os/solaris/vm/perfMemory_solaris.cpp
! src/share/vm/utilities/vmError.cpp

Changeset: b1cf34d57e78
Author:    asaha
Date:      2014-11-06 09:39 -0800
URL:       http://hg.openjdk.java.net/aarch64-port/jdk8/hotspot/rev/b1cf34d57e78

Merge

! .hgtags
! make/hotspot_version
! src/share/vm/runtime/arguments.cpp
! src/share/vm/utilities/vmError.cpp

Changeset: fb677d6aebea
Author:    asaha
Date:      2014-11-10 09:47 -0800
URL:       http://hg.openjdk.java.net/aarch64-port/jdk8/hotspot/rev/fb677d6aebea

8062675: jmap is unable to display information about java processes and prints only pids
Summary: backout fix 8050808 which caused this regression and as requested.
Reviewed-by: hseigel

! src/os/bsd/vm/perfMemory_bsd.cpp
! src/os/linux/vm/perfMemory_linux.cpp
! src/os/solaris/vm/perfMemory_solaris.cpp
! src/share/vm/utilities/vmError.cpp

Changeset: 9a227eaac2dc
Author:    gthornbr
Date:      2014-11-17 15:51 -0500
URL:       http://hg.openjdk.java.net/aarch64-port/jdk8/hotspot/rev/9a227eaac2dc

8050807: Better performing performance data handling
Reviewed-by: dcubed, pnauman, ctornqvi, dholmes, mschoene
Contributed-by: gerald.thornbrugh at oracle.com

! src/os/bsd/vm/perfMemory_bsd.cpp
! src/os/linux/vm/perfMemory_linux.cpp
! src/os/solaris/vm/perfMemory_solaris.cpp
! src/share/vm/utilities/vmError.cpp

Changeset: b7e8193d0b53
Author:    asaha
Date:      2014-11-19 15:02 -0800
URL:       http://hg.openjdk.java.net/aarch64-port/jdk8/hotspot/rev/b7e8193d0b53

Merge

! .hgtags
! make/hotspot_version

Changeset: d5b74c583ec1
Author:    drchase
Date:      2014-12-01 13:06 -0500
URL:       http://hg.openjdk.java.net/aarch64-port/jdk8/hotspot/rev/d5b74c583ec1

8064524: Compiler code generation improvements
Reviewed-by: jrose, acorn, vlivanov

! src/share/vm/code/dependencies.cpp
! src/share/vm/code/dependencies.hpp
! src/share/vm/interpreter/linkResolver.cpp
! src/share/vm/oops/instanceKlass.cpp
! src/share/vm/oops/instanceKlass.hpp

Changeset: f3ffb37f88a6
Author:    asaha
Date:      2014-12-01 11:29 -0800
URL:       http://hg.openjdk.java.net/aarch64-port/jdk8/hotspot/rev/f3ffb37f88a6

Merge

! .hgtags
! make/hotspot_version
- make/solaris/makefiles/add_gnu_debuglink.make
- make/solaris/makefiles/fix_empty_sec_hdr_flags.make
! src/os/bsd/vm/perfMemory_bsd.cpp
! src/os/linux/vm/perfMemory_linux.cpp
- src/os/solaris/add_gnu_debuglink/add_gnu_debuglink.c
- src/os/solaris/fix_empty_sec_hdr_flags/fix_empty_sec_hdr_flags.c
! src/os/solaris/vm/perfMemory_solaris.cpp
! src/share/vm/runtime/arguments.cpp
! src/share/vm/utilities/vmError.cpp
- test/runtime/NMT/UnsafeMallocLimit.java
- test/runtime/NMT/UnsafeMallocLimit2.java

Changeset: d6a05415f1f4
Author:    asaha
Date:      2014-12-01 19:09 -0800
URL:       http://hg.openjdk.java.net/aarch64-port/jdk8/hotspot/rev/d6a05415f1f4

Merge


Changeset: 41c3c456e326
Author:    asaha
Date:      2014-12-12 14:39 -0800
URL:       http://hg.openjdk.java.net/aarch64-port/jdk8/hotspot/rev/41c3c456e326

Merge

! .hgtags
! make/hotspot_version
- make/jprt.properties
! src/share/vm/code/dependencies.cpp
! src/share/vm/oops/instanceKlass.cpp
! src/share/vm/oops/instanceKlass.hpp
! src/share/vm/runtime/arguments.cpp

Changeset: 01850e3a5b06
Author:    asaha
Date:      2014-12-15 15:37 -0800
URL:       http://hg.openjdk.java.net/aarch64-port/jdk8/hotspot/rev/01850e3a5b06

Added tag jdk8u45-b01 for changeset 41c3c456e326

! .hgtags

Changeset: 7622232b7efa
Author:    asaha
Date:      2014-12-17 09:10 -0800
URL:       http://hg.openjdk.java.net/aarch64-port/jdk8/hotspot/rev/7622232b7efa

Merge

! .hgtags
! make/hotspot_version
! src/share/vm/code/dependencies.cpp
! src/share/vm/code/dependencies.hpp
! src/share/vm/oops/instanceKlass.cpp
! src/share/vm/oops/instanceKlass.hpp

Changeset: 02e2c04a3289
Author:    acorn
Date:      2014-12-18 17:59 -0800
URL:       http://hg.openjdk.java.net/aarch64-port/jdk8/hotspot/rev/02e2c04a3289

8065366: Better private method resolution
Reviewed-by: hseigel, lfoltan, coleenp, ahgross

! src/share/vm/classfile/defaultMethods.cpp
! src/share/vm/oops/klassVtable.cpp

Changeset: eff80b90c3ad
Author:    asaha
Date:      2014-12-22 09:27 -0800
URL:       http://hg.openjdk.java.net/aarch64-port/jdk8/hotspot/rev/eff80b90c3ad

Merge

! .hgtags
! make/hotspot_version

Changeset: 4e1f52384f9f
Author:    katleman
Date:      2014-11-19 11:27 -0800
URL:       http://hg.openjdk.java.net/aarch64-port/jdk8/hotspot/rev/4e1f52384f9f

Added tag jdk8u25-b32 for changeset 631f0c7b49c0

! .hgtags

Changeset: 34c37aa6e21a
Author:    asaha
Date:      2014-12-03 09:23 -0800
URL:       http://hg.openjdk.java.net/aarch64-port/jdk8/hotspot/rev/34c37aa6e21a

Merge

! .hgtags

Changeset: bb70ade0e378
Author:    asaha
Date:      2014-12-12 08:46 -0800
URL:       http://hg.openjdk.java.net/aarch64-port/jdk8/hotspot/rev/bb70ade0e378

Merge

! .hgtags

Changeset: 9c70224816c3
Author:    asaha
Date:      2014-12-18 14:19 -0800
URL:       http://hg.openjdk.java.net/aarch64-port/jdk8/hotspot/rev/9c70224816c3

Merge

! .hgtags

Changeset: f1c0847f2df3
Author:    asaha
Date:      2014-12-17 08:43 -0800
URL:       http://hg.openjdk.java.net/aarch64-port/jdk8/hotspot/rev/f1c0847f2df3

Added tag jdk8u25-b33 for changeset 4e1f52384f9f

! .hgtags

Changeset: b517d3a9aebf
Author:    asaha
Date:      2014-12-18 14:30 -0800
URL:       http://hg.openjdk.java.net/aarch64-port/jdk8/hotspot/rev/b517d3a9aebf

Merge

! .hgtags

Changeset: 626fd8c2eec6
Author:    asaha
Date:      2014-12-22 12:10 -0800
URL:       http://hg.openjdk.java.net/aarch64-port/jdk8/hotspot/rev/626fd8c2eec6

Merge

! .hgtags

Changeset: 004db83e0211
Author:    asaha
Date:      2014-12-22 14:00 -0800
URL:       http://hg.openjdk.java.net/aarch64-port/jdk8/hotspot/rev/004db83e0211

Added tag jdk8u45-b02 for changeset 626fd8c2eec6

! .hgtags

Changeset: 5363902eb0cc
Author:    asaha
Date:      2014-12-29 14:42 -0800
URL:       http://hg.openjdk.java.net/aarch64-port/jdk8/hotspot/rev/5363902eb0cc

Merge

! .hgtags

Changeset: a925e0c7d991
Author:    asaha
Date:      2015-01-05 09:26 -0800
URL:       http://hg.openjdk.java.net/aarch64-port/jdk8/hotspot/rev/a925e0c7d991

Merge

! .hgtags

Changeset: b22b01407a81
Author:    asaha
Date:      2015-01-05 09:56 -0800
URL:       http://hg.openjdk.java.net/aarch64-port/jdk8/hotspot/rev/b22b01407a81

Merge

! .hgtags

Changeset: 15d8108258cb
Author:    asaha
Date:      2015-01-12 06:48 -0800
URL:       http://hg.openjdk.java.net/aarch64-port/jdk8/hotspot/rev/15d8108258cb

Added tag jdk8u31-b31 for changeset b517d3a9aebf

! .hgtags

Changeset: f41aa01b0a04
Author:    asaha
Date:      2015-01-12 06:56 -0800
URL:       http://hg.openjdk.java.net/aarch64-port/jdk8/hotspot/rev/f41aa01b0a04

Merge

! .hgtags

Changeset: b79c4b34d157
Author:    asaha
Date:      2015-01-12 13:48 -0800
URL:       http://hg.openjdk.java.net/aarch64-port/jdk8/hotspot/rev/b79c4b34d157

Added tag jdk8u45-b03 for changeset f41aa01b0a04

! .hgtags

Changeset: 9f5afbcc45ce
Author:    asaha
Date:      2015-01-19 12:28 -0800
URL:       http://hg.openjdk.java.net/aarch64-port/jdk8/hotspot/rev/9f5afbcc45ce

Merge

! .hgtags
! make/hotspot_version

Changeset: 26b1dc6891c4
Author:    asaha
Date:      2015-01-20 09:53 -0800
URL:       http://hg.openjdk.java.net/aarch64-port/jdk8/hotspot/rev/26b1dc6891c4

Added tag jdk8u31-b32 for changeset 15d8108258cb

! .hgtags

Changeset: 2f586e3c4b6d
Author:    asaha
Date:      2015-01-20 10:09 -0800
URL:       http://hg.openjdk.java.net/aarch64-port/jdk8/hotspot/rev/2f586e3c4b6d

Merge

! .hgtags

Changeset: 64bad154d3b9
Author:    asaha
Date:      2015-01-20 12:29 -0800
URL:       http://hg.openjdk.java.net/aarch64-port/jdk8/hotspot/rev/64bad154d3b9

Added tag jdk8u45-b04 for changeset 2f586e3c4b6d

! .hgtags

Changeset: 344ff6e45a1e
Author:    asaha
Date:      2015-01-22 15:41 -0800
URL:       http://hg.openjdk.java.net/aarch64-port/jdk8/hotspot/rev/344ff6e45a1e

Merge

! .hgtags
! make/hotspot_version

Changeset: 70b6e09935c1
Author:    asaha
Date:      2015-01-26 11:59 -0800
URL:       http://hg.openjdk.java.net/aarch64-port/jdk8/hotspot/rev/70b6e09935c1

Added tag jdk8u45-b05 for changeset 344ff6e45a1e

! .hgtags

Changeset: 3afa9cc6e8d5
Author:    asaha
Date:      2015-01-28 15:25 -0800
URL:       http://hg.openjdk.java.net/aarch64-port/jdk8/hotspot/rev/3afa9cc6e8d5

Merge

! .hgtags

Changeset: 1de069db4560
Author:    asaha
Date:      2015-02-02 13:28 -0800
URL:       http://hg.openjdk.java.net/aarch64-port/jdk8/hotspot/rev/1de069db4560

Added tag jdk8u45-b06 for changeset 3afa9cc6e8d5

! .hgtags

Changeset: 5871f3dd9b4a
Author:    asaha
Date:      2015-02-04 13:10 -0800
URL:       http://hg.openjdk.java.net/aarch64-port/jdk8/hotspot/rev/5871f3dd9b4a

Merge

! .hgtags

Changeset: 884bf4977cf4
Author:    asaha
Date:      2015-02-09 09:06 -0800
URL:       http://hg.openjdk.java.net/aarch64-port/jdk8/hotspot/rev/884bf4977cf4

Added tag jdk8u45-b07 for changeset 5871f3dd9b4a

! .hgtags

Changeset: c826f6c6a4bf
Author:    asaha
Date:      2015-02-11 14:14 -0800
URL:       http://hg.openjdk.java.net/aarch64-port/jdk8/hotspot/rev/c826f6c6a4bf

Merge

! .hgtags

Changeset: 80ce7fc26d44
Author:    asaha
Date:      2015-02-16 07:19 -0800
URL:       http://hg.openjdk.java.net/aarch64-port/jdk8/hotspot/rev/80ce7fc26d44

8073223: Increment the build value to b02 for hs25.45 in 8u45-b08
Reviewed-by: coffeys

! make/hotspot_version

Changeset: 4b2830dcf178
Author:    zmajo
Date:      2015-01-30 10:40 +0100
URL:       http://hg.openjdk.java.net/aarch64-port/jdk8/hotspot/rev/4b2830dcf178

8071818: Incorrect addressing mode used for ldf in SPARC assembler
Summary: Update MacroAssembler::ldf to select addressing mode depending on Address parameter.
Reviewed-by: kvn, dlong

! src/cpu/sparc/vm/macroAssembler_sparc.inline.hpp

Changeset: 35c7330b68e2
Author:    kbarrett
Date:      2015-02-09 13:30 -0500
URL:       http://hg.openjdk.java.net/aarch64-port/jdk8/hotspot/rev/35c7330b68e2

8071931: Return of the phantom menace
Reviewed-by: mchung, dfuchs, ahgross, brutisso

! src/share/vm/memory/referenceProcessor.cpp

Changeset: 35d8318de0b6
Author:    asaha
Date:      2015-02-16 11:05 -0800
URL:       http://hg.openjdk.java.net/aarch64-port/jdk8/hotspot/rev/35d8318de0b6

Added tag jdk8u45-b08 for changeset 35c7330b68e2

! .hgtags

Changeset: a9f578607920
Author:    asaha
Date:      2015-02-23 14:47 -0800
URL:       http://hg.openjdk.java.net/aarch64-port/jdk8/hotspot/rev/a9f578607920

Added tag jdk8u45-b09 for changeset 35d8318de0b6

! .hgtags

Changeset: 6a04585197c7
Author:    asaha
Date:      2015-03-02 11:14 -0800
URL:       http://hg.openjdk.java.net/aarch64-port/jdk8/hotspot/rev/6a04585197c7

Added tag jdk8u45-b10 for changeset a9f578607920

! .hgtags

Changeset: 6824e2475e04
Author:    asaha
Date:      2015-03-07 10:25 -0800
URL:       http://hg.openjdk.java.net/aarch64-port/jdk8/hotspot/rev/6824e2475e04

Added tag jdk8u40-b26 for changeset f39b6944ad44

! .hgtags

Changeset: f4822d122041
Author:    asaha
Date:      2015-03-07 16:26 -0800
URL:       http://hg.openjdk.java.net/aarch64-port/jdk8/hotspot/rev/f4822d122041

Merge

! .hgtags

Changeset: e44b10693a44
Author:    asaha
Date:      2015-03-09 12:35 -0700
URL:       http://hg.openjdk.java.net/aarch64-port/jdk8/hotspot/rev/e44b10693a44

Added tag jdk8u45-b11 for changeset f4822d122041

! .hgtags

Changeset: 005fa3e7c752
Author:    asaha
Date:      2015-03-10 15:33 -0700
URL:       http://hg.openjdk.java.net/aarch64-port/jdk8/hotspot/rev/005fa3e7c752

8074662: Update 3rd party readme and license for LibPNG v 1.6.16
Reviewed-by: jeff

! THIRD_PARTY_README

Changeset: 68577993c7db
Author:    asaha
Date:      2015-03-12 20:15 -0700
URL:       http://hg.openjdk.java.net/aarch64-port/jdk8/hotspot/rev/68577993c7db

Added tag jdk8u40-b27 for changeset 6824e2475e04

! .hgtags

Changeset: dc29108bcbcb
Author:    asaha
Date:      2015-03-16 09:13 -0700
URL:       http://hg.openjdk.java.net/aarch64-port/jdk8/hotspot/rev/dc29108bcbcb

Merge

! .hgtags

Changeset: efbf340fc7f5
Author:    asaha
Date:      2015-03-16 11:19 -0700
URL:       http://hg.openjdk.java.net/aarch64-port/jdk8/hotspot/rev/efbf340fc7f5

Added tag jdk8u45-b12 for changeset dc29108bcbcb

! .hgtags

Changeset: 5321d26956b2
Author:    asaha
Date:      2015-03-17 11:22 -0700
URL:       http://hg.openjdk.java.net/aarch64-port/jdk8/hotspot/rev/5321d26956b2

Added tag jdk8u45-b13 for changeset efbf340fc7f5

! .hgtags

Changeset: de82c08da806
Author:    enevill
Date:      2015-04-16 11:36 +0100
URL:       http://hg.openjdk.java.net/aarch64-port/jdk8/hotspot/rev/de82c08da806

Merge up to jdk8u45-b14

! .hgtags
! THIRD_PARTY_README
! make/hotspot_version
! src/share/vm/classfile/defaultMethods.cpp
! src/share/vm/code/dependencies.cpp
! src/share/vm/memory/referenceProcessor.cpp
! src/share/vm/oops/instanceKlass.cpp
! src/share/vm/oops/instanceKlass.hpp
! src/share/vm/oops/klassVtable.cpp
! src/share/vm/runtime/arguments.cpp
! src/share/vm/utilities/vmError.cpp

Changeset: 70d4f640f931
Author:    enevill
Date:      2015-04-16 15:06 +0100
URL:       http://hg.openjdk.java.net/aarch64-port/jdk8/hotspot/rev/70d4f640f931

Fix build for aarch64/zero

! src/share/vm/interpreter/interpreterRuntime.cpp


From edward.nevill at gmail.com  Thu Apr 16 15:27:01 2015
From: edward.nevill at gmail.com (edward.nevill at gmail.com)
Date: Thu, 16 Apr 2015 15:27:01 +0000
Subject: [aarch64-port-dev ] hg: aarch64-port/jdk8/jaxp: 52 new changesets
Message-ID: <201504161527.t3GFR2Nk003599@aojmv0008>

Changeset: e7b7f59d3640
Author:    asaha
Date:      2014-10-07 08:49 -0700
URL:       http://hg.openjdk.java.net/aarch64-port/jdk8/jaxp/rev/e7b7f59d3640

Merge

! .hgtags

Changeset: 13ff8e6b6fce
Author:    asaha
Date:      2014-10-09 12:08 -0700
URL:       http://hg.openjdk.java.net/aarch64-port/jdk8/jaxp/rev/13ff8e6b6fce

Added tag jdk8u45-b00 for changeset 9286acc600a7

! .hgtags

Changeset: efd206cdeeb6
Author:    asaha
Date:      2014-10-09 13:18 -0700
URL:       http://hg.openjdk.java.net/aarch64-port/jdk8/jaxp/rev/efd206cdeeb6

Merge

! .hgtags

Changeset: dad49d9cc1cd
Author:    asaha
Date:      2014-10-14 11:42 -0700
URL:       http://hg.openjdk.java.net/aarch64-port/jdk8/jaxp/rev/dad49d9cc1cd

Merge

! .hgtags

Changeset: ffcc0060704a
Author:    asaha
Date:      2014-10-20 23:04 -0700
URL:       http://hg.openjdk.java.net/aarch64-port/jdk8/jaxp/rev/ffcc0060704a

Merge

! .hgtags

Changeset: 155dbe19c0d9
Author:    asaha
Date:      2014-10-24 17:13 -0700
URL:       http://hg.openjdk.java.net/aarch64-port/jdk8/jaxp/rev/155dbe19c0d9

Merge

! .hgtags

Changeset: d95550886c67
Author:    asaha
Date:      2014-11-06 09:42 -0800
URL:       http://hg.openjdk.java.net/aarch64-port/jdk8/jaxp/rev/d95550886c67

Merge

! .hgtags

Changeset: 97032057f9f7
Author:    asaha
Date:      2014-11-19 15:25 -0800
URL:       http://hg.openjdk.java.net/aarch64-port/jdk8/jaxp/rev/97032057f9f7

Merge

! .hgtags

Changeset: e0a586ac8d41
Author:    asaha
Date:      2014-12-01 11:34 -0800
URL:       http://hg.openjdk.java.net/aarch64-port/jdk8/jaxp/rev/e0a586ac8d41

Merge

! .hgtags

Changeset: 9fded65e1d36
Author:    asaha
Date:      2014-12-12 14:42 -0800
URL:       http://hg.openjdk.java.net/aarch64-port/jdk8/jaxp/rev/9fded65e1d36

Merge

! .hgtags

Changeset: 06118bf2d36d
Author:    asaha
Date:      2014-12-15 15:38 -0800
URL:       http://hg.openjdk.java.net/aarch64-port/jdk8/jaxp/rev/06118bf2d36d

Added tag jdk8u45-b01 for changeset 9fded65e1d36

! .hgtags

Changeset: b712dc277958
Author:    asaha
Date:      2014-12-17 09:12 -0800
URL:       http://hg.openjdk.java.net/aarch64-port/jdk8/jaxp/rev/b712dc277958

Merge

! .hgtags

Changeset: de6e69ca909d
Author:    asaha
Date:      2014-12-22 10:07 -0800
URL:       http://hg.openjdk.java.net/aarch64-port/jdk8/jaxp/rev/de6e69ca909d

Merge

! .hgtags

Changeset: 1c17ffddb766
Author:    katleman
Date:      2014-11-19 11:27 -0800
URL:       http://hg.openjdk.java.net/aarch64-port/jdk8/jaxp/rev/1c17ffddb766

Added tag jdk8u25-b32 for changeset b4231e682f98

! .hgtags

Changeset: 4bd853ba6979
Author:    asaha
Date:      2014-12-03 09:26 -0800
URL:       http://hg.openjdk.java.net/aarch64-port/jdk8/jaxp/rev/4bd853ba6979

Merge

! .hgtags

Changeset: 348bc3298ddb
Author:    asaha
Date:      2014-12-12 08:46 -0800
URL:       http://hg.openjdk.java.net/aarch64-port/jdk8/jaxp/rev/348bc3298ddb

Merge

! .hgtags

Changeset: 0830bdf1ca09
Author:    asaha
Date:      2014-12-18 14:20 -0800
URL:       http://hg.openjdk.java.net/aarch64-port/jdk8/jaxp/rev/0830bdf1ca09

Merge

! .hgtags

Changeset: 756fb61c6afd
Author:    asaha
Date:      2014-12-17 08:43 -0800
URL:       http://hg.openjdk.java.net/aarch64-port/jdk8/jaxp/rev/756fb61c6afd

Added tag jdk8u25-b33 for changeset 1c17ffddb766

! .hgtags

Changeset: dcc563c9db9e
Author:    asaha
Date:      2014-12-18 14:32 -0800
URL:       http://hg.openjdk.java.net/aarch64-port/jdk8/jaxp/rev/dcc563c9db9e

Merge

! .hgtags

Changeset: 62566a3dbe59
Author:    asaha
Date:      2014-12-22 12:14 -0800
URL:       http://hg.openjdk.java.net/aarch64-port/jdk8/jaxp/rev/62566a3dbe59

Merge

! .hgtags

Changeset: 23776c7759b8
Author:    asaha
Date:      2014-12-22 14:01 -0800
URL:       http://hg.openjdk.java.net/aarch64-port/jdk8/jaxp/rev/23776c7759b8

Added tag jdk8u45-b02 for changeset 62566a3dbe59

! .hgtags

Changeset: eca9efb6ea34
Author:    asaha
Date:      2014-12-29 14:44 -0800
URL:       http://hg.openjdk.java.net/aarch64-port/jdk8/jaxp/rev/eca9efb6ea34

Merge

! .hgtags

Changeset: 4f2d54d5caf7
Author:    asaha
Date:      2015-01-05 09:27 -0800
URL:       http://hg.openjdk.java.net/aarch64-port/jdk8/jaxp/rev/4f2d54d5caf7

Merge

! .hgtags

Changeset: ef437e576e36
Author:    asaha
Date:      2015-01-05 10:00 -0800
URL:       http://hg.openjdk.java.net/aarch64-port/jdk8/jaxp/rev/ef437e576e36

Merge

! .hgtags

Changeset: 119f4ae3151f
Author:    asaha
Date:      2015-01-12 06:48 -0800
URL:       http://hg.openjdk.java.net/aarch64-port/jdk8/jaxp/rev/119f4ae3151f

Added tag jdk8u31-b31 for changeset dcc563c9db9e

! .hgtags

Changeset: 629096783c27
Author:    asaha
Date:      2015-01-12 07:01 -0800
URL:       http://hg.openjdk.java.net/aarch64-port/jdk8/jaxp/rev/629096783c27

Merge

! .hgtags

Changeset: 8dbdb8662c9a
Author:    asaha
Date:      2015-01-12 13:49 -0800
URL:       http://hg.openjdk.java.net/aarch64-port/jdk8/jaxp/rev/8dbdb8662c9a

Added tag jdk8u45-b03 for changeset 629096783c27

! .hgtags

Changeset: 43dd0b9ecb97
Author:    asaha
Date:      2015-01-19 12:31 -0800
URL:       http://hg.openjdk.java.net/aarch64-port/jdk8/jaxp/rev/43dd0b9ecb97

Merge

! .hgtags

Changeset: d8a594fd8507
Author:    asaha
Date:      2015-01-20 09:54 -0800
URL:       http://hg.openjdk.java.net/aarch64-port/jdk8/jaxp/rev/d8a594fd8507

Added tag jdk8u31-b32 for changeset 119f4ae3151f

! .hgtags

Changeset: 85585012b976
Author:    asaha
Date:      2015-01-20 10:17 -0800
URL:       http://hg.openjdk.java.net/aarch64-port/jdk8/jaxp/rev/85585012b976

Merge

! .hgtags

Changeset: 419d4d8884b9
Author:    asaha
Date:      2015-01-20 12:29 -0800
URL:       http://hg.openjdk.java.net/aarch64-port/jdk8/jaxp/rev/419d4d8884b9

Added tag jdk8u45-b04 for changeset 85585012b976

! .hgtags

Changeset: da025bade645
Author:    asaha
Date:      2015-01-22 15:52 -0800
URL:       http://hg.openjdk.java.net/aarch64-port/jdk8/jaxp/rev/da025bade645

Merge

! .hgtags

Changeset: 4570f67a7168
Author:    asaha
Date:      2015-01-26 12:00 -0800
URL:       http://hg.openjdk.java.net/aarch64-port/jdk8/jaxp/rev/4570f67a7168

Added tag jdk8u45-b05 for changeset da025bade645

! .hgtags

Changeset: 41ffc4cb1486
Author:    asaha
Date:      2015-01-28 15:28 -0800
URL:       http://hg.openjdk.java.net/aarch64-port/jdk8/jaxp/rev/41ffc4cb1486

Merge

! .hgtags

Changeset: 49bc5472ded4
Author:    aefimov
Date:      2015-01-26 22:44 +0300
URL:       http://hg.openjdk.java.net/aarch64-port/jdk8/jaxp/rev/49bc5472ded4

8062923: XSL: Run-time internal error in 'substring()'
8062924: XSL: wrong answer from substring() function
Reviewed-by: joehw

! src/com/sun/org/apache/xalan/internal/xsltc/runtime/BasisLibrary.java

Changeset: 7ae4c653ff6f
Author:    asaha
Date:      2015-02-02 13:29 -0800
URL:       http://hg.openjdk.java.net/aarch64-port/jdk8/jaxp/rev/7ae4c653ff6f

Added tag jdk8u45-b06 for changeset 49bc5472ded4

! .hgtags

Changeset: 061930bd7d8f
Author:    asaha
Date:      2015-02-04 13:14 -0800
URL:       http://hg.openjdk.java.net/aarch64-port/jdk8/jaxp/rev/061930bd7d8f

Merge

! .hgtags

Changeset: 3d3da8944992
Author:    asaha
Date:      2015-02-09 09:07 -0800
URL:       http://hg.openjdk.java.net/aarch64-port/jdk8/jaxp/rev/3d3da8944992

Added tag jdk8u45-b07 for changeset 061930bd7d8f

! .hgtags

Changeset: 50fba38f3a29
Author:    asaha
Date:      2015-02-11 14:17 -0800
URL:       http://hg.openjdk.java.net/aarch64-port/jdk8/jaxp/rev/50fba38f3a29

Merge

! .hgtags

Changeset: f893d8b9a0d1
Author:    asaha
Date:      2015-02-16 11:05 -0800
URL:       http://hg.openjdk.java.net/aarch64-port/jdk8/jaxp/rev/f893d8b9a0d1

Added tag jdk8u45-b08 for changeset 50fba38f3a29

! .hgtags

Changeset: 4de18a629048
Author:    asaha
Date:      2015-02-23 14:48 -0800
URL:       http://hg.openjdk.java.net/aarch64-port/jdk8/jaxp/rev/4de18a629048

Added tag jdk8u45-b09 for changeset f893d8b9a0d1

! .hgtags

Changeset: f8edfdc185ba
Author:    asaha
Date:      2015-03-02 11:15 -0800
URL:       http://hg.openjdk.java.net/aarch64-port/jdk8/jaxp/rev/f8edfdc185ba

Added tag jdk8u45-b10 for changeset 4de18a629048

! .hgtags

Changeset: 56f6ca79467d
Author:    asaha
Date:      2015-03-07 10:26 -0800
URL:       http://hg.openjdk.java.net/aarch64-port/jdk8/jaxp/rev/56f6ca79467d

Added tag jdk8u40-b26 for changeset f693ef62c207

! .hgtags

Changeset: cd077759cd75
Author:    asaha
Date:      2015-03-07 16:28 -0800
URL:       http://hg.openjdk.java.net/aarch64-port/jdk8/jaxp/rev/cd077759cd75

Merge

! .hgtags

Changeset: d4042340fe0a
Author:    aefimov
Date:      2015-03-05 19:34 +0300
URL:       http://hg.openjdk.java.net/aarch64-port/jdk8/jaxp/rev/d4042340fe0a

8040228: TransformerConfigurationException occurs with security manager, FSP and XSLT Ext
Reviewed-by: joehw, lancea, ahgross

! src/com/sun/org/apache/xalan/internal/XalanConstants.java
! src/com/sun/org/apache/xalan/internal/xsltc/compiler/FunctionCall.java
! src/com/sun/org/apache/xalan/internal/xsltc/compiler/XSLTC.java
! src/com/sun/org/apache/xalan/internal/xsltc/compiler/util/ErrorMessages.java
! src/com/sun/org/apache/xalan/internal/xsltc/compiler/util/ErrorMsg.java
! src/com/sun/org/apache/xalan/internal/xsltc/trax/TemplatesImpl.java
! src/com/sun/org/apache/xalan/internal/xsltc/trax/TransformerFactoryImpl.java

Changeset: a08c8ea8a1c9
Author:    asaha
Date:      2015-03-09 12:37 -0700
URL:       http://hg.openjdk.java.net/aarch64-port/jdk8/jaxp/rev/a08c8ea8a1c9

Added tag jdk8u45-b11 for changeset d4042340fe0a

! .hgtags

Changeset: 1980188f47a4
Author:    asaha
Date:      2015-03-10 15:34 -0700
URL:       http://hg.openjdk.java.net/aarch64-port/jdk8/jaxp/rev/1980188f47a4

8074662: Update 3rd party readme and license for LibPNG v 1.6.16
Reviewed-by: jeff

! THIRD_PARTY_README

Changeset: 3b87ddc799d4
Author:    asaha
Date:      2015-03-12 20:16 -0700
URL:       http://hg.openjdk.java.net/aarch64-port/jdk8/jaxp/rev/3b87ddc799d4

Added tag jdk8u40-b27 for changeset 56f6ca79467d

! .hgtags

Changeset: 91d1102264e9
Author:    asaha
Date:      2015-03-16 09:15 -0700
URL:       http://hg.openjdk.java.net/aarch64-port/jdk8/jaxp/rev/91d1102264e9

Merge

! .hgtags

Changeset: a15025742f20
Author:    asaha
Date:      2015-03-16 11:20 -0700
URL:       http://hg.openjdk.java.net/aarch64-port/jdk8/jaxp/rev/a15025742f20

Added tag jdk8u45-b12 for changeset 91d1102264e9

! .hgtags

Changeset: e0167ec9d759
Author:    asaha
Date:      2015-03-17 11:23 -0700
URL:       http://hg.openjdk.java.net/aarch64-port/jdk8/jaxp/rev/e0167ec9d759

Added tag jdk8u45-b13 for changeset a15025742f20

! .hgtags

Changeset: 8fa029d6d749
Author:    enevill
Date:      2015-04-16 11:36 +0100
URL:       http://hg.openjdk.java.net/aarch64-port/jdk8/jaxp/rev/8fa029d6d749

Merge up to jdk8u45-b14

! .hgtags
! src/com/sun/org/apache/xalan/internal/XalanConstants.java
! src/com/sun/org/apache/xalan/internal/xsltc/compiler/FunctionCall.java
! src/com/sun/org/apache/xalan/internal/xsltc/compiler/XSLTC.java
! src/com/sun/org/apache/xalan/internal/xsltc/compiler/util/ErrorMessages.java
! src/com/sun/org/apache/xalan/internal/xsltc/trax/TransformerFactoryImpl.java


From edward.nevill at gmail.com  Thu Apr 16 15:27:15 2015
From: edward.nevill at gmail.com (edward.nevill at gmail.com)
Date: Thu, 16 Apr 2015 15:27:15 +0000
Subject: [aarch64-port-dev ] hg: aarch64-port/jdk8/jaxws: 51 new changesets
Message-ID: <201504161527.t3GFRGlb003710@aojmv0008>

Changeset: 31bf0dfe20d6
Author:    asaha
Date:      2014-10-09 12:08 -0700
URL:       http://hg.openjdk.java.net/aarch64-port/jdk8/jaxws/rev/31bf0dfe20d6

Added tag jdk8u45-b00 for changeset 667a4aee3720

! .hgtags

Changeset: d1b8a1d3b853
Author:    asaha
Date:      2014-10-09 13:18 -0700
URL:       http://hg.openjdk.java.net/aarch64-port/jdk8/jaxws/rev/d1b8a1d3b853

Merge

! .hgtags

Changeset: 14d680f8d80d
Author:    asaha
Date:      2014-10-14 11:42 -0700
URL:       http://hg.openjdk.java.net/aarch64-port/jdk8/jaxws/rev/14d680f8d80d

Merge

! .hgtags

Changeset: e044bd1da6b8
Author:    asaha
Date:      2014-10-20 23:05 -0700
URL:       http://hg.openjdk.java.net/aarch64-port/jdk8/jaxws/rev/e044bd1da6b8

Merge

! .hgtags

Changeset: a14efa699f0f
Author:    mkos
Date:      2014-10-24 15:02 +0200
URL:       http://hg.openjdk.java.net/aarch64-port/jdk8/jaxws/rev/a14efa699f0f

8054367: More references for endpoints
Summary: fix also reviewed by Iaroslav.Savytskyi at oracle.com, Alexander.Fomin at oracle.com
Reviewed-by: mullan, skoivu

! src/share/jaxws_classes/com/sun/tools/internal/xjc/model/nav/Utils.java
! src/share/jaxws_classes/com/sun/xml/internal/bind/api/Utils.java
! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/model/impl/RuntimeBuiltinLeafInfoImpl.java
! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/model/impl/Utils.java
! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/runtime/Utils.java
! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/runtime/property/Utils.java
! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/runtime/reflect/Utils.java
! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/util/XmlFactory.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/model/Utils.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/spi/ProviderImpl.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/spi/db/Utils.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/util/xml/XmlUtil.java

Changeset: d9f451ee4b85
Author:    asaha
Date:      2014-10-24 17:22 -0700
URL:       http://hg.openjdk.java.net/aarch64-port/jdk8/jaxws/rev/d9f451ee4b85

Merge

! .hgtags

Changeset: eee054dcc880
Author:    asaha
Date:      2014-11-06 09:43 -0800
URL:       http://hg.openjdk.java.net/aarch64-port/jdk8/jaxws/rev/eee054dcc880

Merge

! .hgtags

Changeset: be10e382f35d
Author:    asaha
Date:      2014-11-19 15:27 -0800
URL:       http://hg.openjdk.java.net/aarch64-port/jdk8/jaxws/rev/be10e382f35d

Merge

! .hgtags

Changeset: 677690c4efd3
Author:    asaha
Date:      2014-12-01 11:37 -0800
URL:       http://hg.openjdk.java.net/aarch64-port/jdk8/jaxws/rev/677690c4efd3

Merge

! .hgtags

Changeset: cb6added4913
Author:    asaha
Date:      2014-12-12 14:43 -0800
URL:       http://hg.openjdk.java.net/aarch64-port/jdk8/jaxws/rev/cb6added4913

Merge

! .hgtags

Changeset: 8c6b5758692a
Author:    asaha
Date:      2014-12-15 15:38 -0800
URL:       http://hg.openjdk.java.net/aarch64-port/jdk8/jaxws/rev/8c6b5758692a

Added tag jdk8u45-b01 for changeset cb6added4913

! .hgtags

Changeset: a140eb0caf04
Author:    asaha
Date:      2014-12-17 09:12 -0800
URL:       http://hg.openjdk.java.net/aarch64-port/jdk8/jaxws/rev/a140eb0caf04

Merge

! .hgtags

Changeset: 5cd2b7e1836f
Author:    asaha
Date:      2014-12-22 10:07 -0800
URL:       http://hg.openjdk.java.net/aarch64-port/jdk8/jaxws/rev/5cd2b7e1836f

Merge

! .hgtags

Changeset: da8457217afd
Author:    katleman
Date:      2014-11-19 11:27 -0800
URL:       http://hg.openjdk.java.net/aarch64-port/jdk8/jaxws/rev/da8457217afd

Added tag jdk8u25-b32 for changeset 90b0097a98f1

! .hgtags

Changeset: 2be64fe05df0
Author:    asaha
Date:      2014-12-03 09:26 -0800
URL:       http://hg.openjdk.java.net/aarch64-port/jdk8/jaxws/rev/2be64fe05df0

Merge

! .hgtags

Changeset: 86111e41a15d
Author:    asaha
Date:      2014-12-12 08:47 -0800
URL:       http://hg.openjdk.java.net/aarch64-port/jdk8/jaxws/rev/86111e41a15d

Merge

! .hgtags

Changeset: 69635d2cc55e
Author:    asaha
Date:      2014-12-18 14:20 -0800
URL:       http://hg.openjdk.java.net/aarch64-port/jdk8/jaxws/rev/69635d2cc55e

Merge

! .hgtags

Changeset: d681964dac4f
Author:    asaha
Date:      2014-12-17 08:44 -0800
URL:       http://hg.openjdk.java.net/aarch64-port/jdk8/jaxws/rev/d681964dac4f

Added tag jdk8u25-b33 for changeset da8457217afd

! .hgtags

Changeset: 49e91817cbe1
Author:    asaha
Date:      2014-12-18 14:33 -0800
URL:       http://hg.openjdk.java.net/aarch64-port/jdk8/jaxws/rev/49e91817cbe1

Merge

! .hgtags

Changeset: 855a7b930205
Author:    asaha
Date:      2014-12-22 12:15 -0800
URL:       http://hg.openjdk.java.net/aarch64-port/jdk8/jaxws/rev/855a7b930205

Merge

! .hgtags

Changeset: b187f2fd6ad5
Author:    asaha
Date:      2014-12-22 14:01 -0800
URL:       http://hg.openjdk.java.net/aarch64-port/jdk8/jaxws/rev/b187f2fd6ad5

Added tag jdk8u45-b02 for changeset 855a7b930205

! .hgtags

Changeset: f00fd201f6b5
Author:    asaha
Date:      2014-12-29 14:44 -0800
URL:       http://hg.openjdk.java.net/aarch64-port/jdk8/jaxws/rev/f00fd201f6b5

Merge

! .hgtags

Changeset: 01713bfc1e12
Author:    asaha
Date:      2015-01-05 09:27 -0800
URL:       http://hg.openjdk.java.net/aarch64-port/jdk8/jaxws/rev/01713bfc1e12

Merge

! .hgtags

Changeset: 74aae7549ef8
Author:    asaha
Date:      2015-01-05 10:01 -0800
URL:       http://hg.openjdk.java.net/aarch64-port/jdk8/jaxws/rev/74aae7549ef8

Merge

! .hgtags

Changeset: 9e20c5acb448
Author:    asaha
Date:      2015-01-12 06:49 -0800
URL:       http://hg.openjdk.java.net/aarch64-port/jdk8/jaxws/rev/9e20c5acb448

Added tag jdk8u31-b31 for changeset 49e91817cbe1

! .hgtags

Changeset: 698a88182586
Author:    asaha
Date:      2015-01-12 07:02 -0800
URL:       http://hg.openjdk.java.net/aarch64-port/jdk8/jaxws/rev/698a88182586

Merge

! .hgtags

Changeset: bc4101726a49
Author:    asaha
Date:      2015-01-12 13:49 -0800
URL:       http://hg.openjdk.java.net/aarch64-port/jdk8/jaxws/rev/bc4101726a49

Added tag jdk8u45-b03 for changeset 698a88182586

! .hgtags

Changeset: 1dc4a0770577
Author:    asaha
Date:      2015-01-19 12:32 -0800
URL:       http://hg.openjdk.java.net/aarch64-port/jdk8/jaxws/rev/1dc4a0770577

Merge

! .hgtags

Changeset: ea23d583e363
Author:    asaha
Date:      2015-01-20 09:54 -0800
URL:       http://hg.openjdk.java.net/aarch64-port/jdk8/jaxws/rev/ea23d583e363

Added tag jdk8u31-b32 for changeset 9e20c5acb448

! .hgtags

Changeset: c7307f75843b
Author:    asaha
Date:      2015-01-20 10:18 -0800
URL:       http://hg.openjdk.java.net/aarch64-port/jdk8/jaxws/rev/c7307f75843b

Merge

! .hgtags

Changeset: b5e9639af6d6
Author:    asaha
Date:      2015-01-20 12:30 -0800
URL:       http://hg.openjdk.java.net/aarch64-port/jdk8/jaxws/rev/b5e9639af6d6

Added tag jdk8u45-b04 for changeset c7307f75843b

! .hgtags

Changeset: 6bd873f17e03
Author:    asaha
Date:      2015-01-22 15:52 -0800
URL:       http://hg.openjdk.java.net/aarch64-port/jdk8/jaxws/rev/6bd873f17e03

Merge

! .hgtags

Changeset: 12f4795e2ad0
Author:    asaha
Date:      2015-01-26 12:00 -0800
URL:       http://hg.openjdk.java.net/aarch64-port/jdk8/jaxws/rev/12f4795e2ad0

Added tag jdk8u45-b05 for changeset 6bd873f17e03

! .hgtags

Changeset: 5944c1915aa1
Author:    asaha
Date:      2015-01-28 15:28 -0800
URL:       http://hg.openjdk.java.net/aarch64-port/jdk8/jaxws/rev/5944c1915aa1

Merge

! .hgtags

Changeset: a5e99f4d067e
Author:    aefimov
Date:      2015-01-26 22:36 +0300
URL:       http://hg.openjdk.java.net/aarch64-port/jdk8/jaxws/rev/a5e99f4d067e

8046817: JDK 8 schemagen tool does not generate xsd files for enum types
Reviewed-by: joehw, mkos

! src/share/jaxws_classes/com/sun/tools/internal/jxc/ap/SchemaGenerator.java

Changeset: d8faea5e290e
Author:    asaha
Date:      2015-02-02 13:29 -0800
URL:       http://hg.openjdk.java.net/aarch64-port/jdk8/jaxws/rev/d8faea5e290e

Added tag jdk8u45-b06 for changeset a5e99f4d067e

! .hgtags

Changeset: 145ea6d2899f
Author:    asaha
Date:      2015-02-04 13:14 -0800
URL:       http://hg.openjdk.java.net/aarch64-port/jdk8/jaxws/rev/145ea6d2899f

Merge

! .hgtags

Changeset: 92a8559af833
Author:    asaha
Date:      2015-02-09 09:07 -0800
URL:       http://hg.openjdk.java.net/aarch64-port/jdk8/jaxws/rev/92a8559af833

Added tag jdk8u45-b07 for changeset 145ea6d2899f

! .hgtags

Changeset: f3d678fe58e7
Author:    asaha
Date:      2015-02-11 14:18 -0800
URL:       http://hg.openjdk.java.net/aarch64-port/jdk8/jaxws/rev/f3d678fe58e7

Merge

! .hgtags

Changeset: 8f2e51101518
Author:    asaha
Date:      2015-02-16 11:06 -0800
URL:       http://hg.openjdk.java.net/aarch64-port/jdk8/jaxws/rev/8f2e51101518

Added tag jdk8u45-b08 for changeset f3d678fe58e7

! .hgtags

Changeset: 5cf887e3e136
Author:    asaha
Date:      2015-02-23 14:48 -0800
URL:       http://hg.openjdk.java.net/aarch64-port/jdk8/jaxws/rev/5cf887e3e136

Added tag jdk8u45-b09 for changeset 8f2e51101518

! .hgtags

Changeset: 2e21fbbf73ca
Author:    asaha
Date:      2015-03-02 11:15 -0800
URL:       http://hg.openjdk.java.net/aarch64-port/jdk8/jaxws/rev/2e21fbbf73ca

Added tag jdk8u45-b10 for changeset 5cf887e3e136

! .hgtags

Changeset: a5f2cdedb940
Author:    asaha
Date:      2015-03-07 10:26 -0800
URL:       http://hg.openjdk.java.net/aarch64-port/jdk8/jaxws/rev/a5f2cdedb940

Added tag jdk8u40-b26 for changeset 1bcb30bdd988

! .hgtags

Changeset: 855fd9dfcbee
Author:    asaha
Date:      2015-03-07 16:28 -0800
URL:       http://hg.openjdk.java.net/aarch64-port/jdk8/jaxws/rev/855fd9dfcbee

Merge

! .hgtags

Changeset: 2057d1f02b4d
Author:    asaha
Date:      2015-03-09 12:37 -0700
URL:       http://hg.openjdk.java.net/aarch64-port/jdk8/jaxws/rev/2057d1f02b4d

Added tag jdk8u45-b11 for changeset 855fd9dfcbee

! .hgtags

Changeset: 6b7c53099eb1
Author:    asaha
Date:      2015-03-10 15:34 -0700
URL:       http://hg.openjdk.java.net/aarch64-port/jdk8/jaxws/rev/6b7c53099eb1

8074662: Update 3rd party readme and license for LibPNG v 1.6.16
Reviewed-by: jeff

! THIRD_PARTY_README

Changeset: 4df88e579f83
Author:    asaha
Date:      2015-03-12 20:16 -0700
URL:       http://hg.openjdk.java.net/aarch64-port/jdk8/jaxws/rev/4df88e579f83

Added tag jdk8u40-b27 for changeset a5f2cdedb940

! .hgtags

Changeset: 3f6c3f48179a
Author:    asaha
Date:      2015-03-16 09:16 -0700
URL:       http://hg.openjdk.java.net/aarch64-port/jdk8/jaxws/rev/3f6c3f48179a

Merge

! .hgtags

Changeset: 15fb2359f5f8
Author:    asaha
Date:      2015-03-16 11:20 -0700
URL:       http://hg.openjdk.java.net/aarch64-port/jdk8/jaxws/rev/15fb2359f5f8

Added tag jdk8u45-b12 for changeset 3f6c3f48179a

! .hgtags

Changeset: bad02ac45d59
Author:    asaha
Date:      2015-03-17 11:23 -0700
URL:       http://hg.openjdk.java.net/aarch64-port/jdk8/jaxws/rev/bad02ac45d59

Added tag jdk8u45-b13 for changeset 15fb2359f5f8

! .hgtags

Changeset: 8c4a2f136a99
Author:    enevill
Date:      2015-04-16 11:36 +0100
URL:       http://hg.openjdk.java.net/aarch64-port/jdk8/jaxws/rev/8c4a2f136a99

Merge up to jdk8u45-b14

! .hgtags


From edward.nevill at gmail.com  Thu Apr 16 15:27:32 2015
From: edward.nevill at gmail.com (edward.nevill at gmail.com)
Date: Thu, 16 Apr 2015 15:27:32 +0000
Subject: [aarch64-port-dev ] hg: aarch64-port/jdk8/jdk: 80 new changesets
Message-ID: <201504161527.t3GFRZQ9003773@aojmv0008>

Changeset: a74459126708
Author:    asaha
Date:      2014-10-09 12:08 -0700
URL:       http://hg.openjdk.java.net/aarch64-port/jdk8/jdk/rev/a74459126708

Added tag jdk8u45-b00 for changeset 1ecc234bd389

! .hgtags

Changeset: 19efcc2739ba
Author:    asaha
Date:      2014-10-09 13:18 -0700
URL:       http://hg.openjdk.java.net/aarch64-port/jdk8/jdk/rev/19efcc2739ba

Merge

! .hgtags

Changeset: 4dc8cbe8ea77
Author:    asaha
Date:      2014-10-14 11:43 -0700
URL:       http://hg.openjdk.java.net/aarch64-port/jdk8/jdk/rev/4dc8cbe8ea77

Merge

! .hgtags

Changeset: f9d3b1e83fea
Author:    smarks
Date:      2014-10-15 15:41 -0700
URL:       http://hg.openjdk.java.net/aarch64-port/jdk8/jdk/rev/f9d3b1e83fea

8055309: RMI needs better transportation considerations
Reviewed-by: alanb, igerasim, skoivu, msheppar

! src/share/classes/sun/rmi/transport/Transport.java
! src/share/classes/sun/rmi/transport/tcp/TCPTransport.java

Changeset: 1d973a19ef7c
Author:    michaelm
Date:      2014-10-20 10:29 +0100
URL:       http://hg.openjdk.java.net/aarch64-port/jdk8/jdk/rev/1d973a19ef7c

8048035: Ensure proper proxy protocols
Reviewed-by: chegar, coffeys

! src/share/classes/sun/net/www/protocol/http/HttpURLConnection.java

Changeset: ca4865cc7bea
Author:    asaha
Date:      2014-10-20 23:06 -0700
URL:       http://hg.openjdk.java.net/aarch64-port/jdk8/jdk/rev/ca4865cc7bea

Merge

! .hgtags

Changeset: 3dfe6ebbfc51
Author:    weijun
Date:      2014-10-16 11:09 +0800
URL:       http://hg.openjdk.java.net/aarch64-port/jdk8/jdk/rev/3dfe6ebbfc51

8060474: Resolve more parsing ambiguity
Reviewed-by: mullan, ahgross

! src/share/classes/sun/security/jgss/GSSHeader.java
! src/share/classes/sun/security/jgss/GSSNameImpl.java
! src/share/classes/sun/security/jgss/wrapper/GSSNameElement.java
! src/share/classes/sun/security/krb5/internal/ccache/CCacheInputStream.java
! src/share/classes/sun/security/krb5/internal/ccache/FileCredentialsCache.java
! src/share/classes/sun/security/krb5/internal/ktab/KeyTabInputStream.java
! src/share/classes/sun/security/krb5/internal/util/KrbDataInputStream.java

Changeset: e7caa9e7149d
Author:    weijun
Date:      2014-10-23 07:07 +0800
URL:       http://hg.openjdk.java.net/aarch64-port/jdk8/jdk/rev/e7caa9e7149d

8061826: Part of JDK-8060474 should be reverted
Reviewed-by: mullan, ahgross

! src/share/classes/sun/security/krb5/internal/ktab/KeyTabInputStream.java
! src/share/classes/sun/security/krb5/internal/util/KrbDataInputStream.java

Changeset: e4066947e8fe
Author:    xuelei
Date:      2014-10-24 11:49 +0000
URL:       http://hg.openjdk.java.net/aarch64-port/jdk8/jdk/rev/e4066947e8fe

8061210: Issues in TLS
Reviewed-by: jnimeh, mullan, wetmore, ahgross, asmotrak

! src/share/classes/sun/security/ssl/Handshaker.java
! src/share/classes/sun/security/ssl/ProtocolVersion.java
! src/share/classes/sun/security/ssl/SSLAlgorithmConstraints.java
! src/share/classes/sun/security/ssl/SSLContextImpl.java
! src/share/lib/security/java.security-aix
! src/share/lib/security/java.security-linux
! src/share/lib/security/java.security-macosx
! src/share/lib/security/java.security-solaris
! src/share/lib/security/java.security-windows
! test/sun/security/ec/TestEC.java
! test/sun/security/pkcs11/sslecc/ClientJSSEServerJSSE.java
! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/ProtocolVersion/HttpsProtocols.java
! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLContextImpl/CustomizedDefaultProtocols.java
! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLContextImpl/DefaultEnabledProtocols.java
! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLContextImpl/NoOldVersionContext.java
! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLEngineImpl/DelegatedTaskWrongException.java
! test/sun/security/ssl/javax/net/ssl/NewAPIs/testEnabledProtocols.java
! test/sun/security/ssl/javax/net/ssl/ServerName/SSLEngineExplorer.java
! test/sun/security/ssl/javax/net/ssl/ServerName/SSLSocketExplorer.java
! test/sun/security/ssl/sanity/interop/ClientJSSEServerJSSE.java

Changeset: baaaf9b8a9a5
Author:    alexsch
Date:      2014-10-31 20:17 +0400
URL:       http://hg.openjdk.java.net/aarch64-port/jdk8/jdk/rev/baaaf9b8a9a5

8062561: Test bug8055304 fails if file system default directory has read access
Reviewed-by: serb

! src/share/classes/sun/swing/FilePane.java
! src/windows/classes/sun/awt/shell/Win32ShellFolderManager2.java
+ test/javax/swing/JFileChooser/8062561/bug8062561.java
+ test/javax/swing/JFileChooser/8062561/security.policy
+ test/javax/swing/JFileChooser/8062561/security2.policy

Changeset: da56587ffb26
Author:    asaha
Date:      2014-10-27 14:09 -0700
URL:       http://hg.openjdk.java.net/aarch64-port/jdk8/jdk/rev/da56587ffb26

Merge

! .hgtags
- src/share/classes/com/sun/jarsigner/package.html
- src/share/classes/sun/awt/image/MultiResolutionBufferedImage.java
! src/share/classes/sun/security/jgss/GSSNameImpl.java
! src/share/classes/sun/security/krb5/internal/ccache/CCacheInputStream.java
! src/share/classes/sun/security/krb5/internal/ccache/FileCredentialsCache.java
! src/share/classes/sun/security/ssl/Handshaker.java
- src/solaris/classes/java/lang/UNIXProcess.java.aix
- src/solaris/classes/java/lang/UNIXProcess.java.bsd
- src/solaris/classes/java/lang/UNIXProcess.java.linux
- src/solaris/classes/java/lang/UNIXProcess.java.solaris
- src/solaris/native/sun/awt/awt_Plugin.c
- src/solaris/native/sun/awt/awt_Plugin.h
- src/solaris/native/sun/util/locale/provider/HostLocaleProviderAdapter_md.c
- test/sun/jvmstat/monitor/MonitoredVm/MonitorVmStartTerminate.sh
- test/sun/jvmstat/testlibrary/JavaProcess.java
- test/sun/security/krb5/TimeInCCache.java

Changeset: 240ae8272509
Author:    asaha
Date:      2014-10-31 17:10 -0700
URL:       http://hg.openjdk.java.net/aarch64-port/jdk8/jdk/rev/240ae8272509

Merge


Changeset: 9e4a935c5181
Author:    asaha
Date:      2014-11-06 09:47 -0800
URL:       http://hg.openjdk.java.net/aarch64-port/jdk8/jdk/rev/9e4a935c5181

Merge

! .hgtags
- src/share/demo/jfc/Font2DTest/resources/TextResources.properties
- src/share/demo/jfc/Font2DTest/resources/TextResources_de.properties
- src/share/demo/jfc/Font2DTest/resources/TextResources_en.properties
- src/share/demo/jfc/Font2DTest/resources/TextResources_en_GB.properties
- src/share/demo/jfc/Font2DTest/resources/TextResources_ja.properties
- src/share/demo/jfc/Font2DTest/resources/TextResources_ko.properties
- src/share/demo/jfc/Font2DTest/resources/TextResources_zh_CN.properties
- src/share/demo/jfc/Font2DTest/resources/resource.data
- test/java/security/cert/CertificateFactory/invalidEncodedCerts/invalidcert.pem

Changeset: 57c71d39ee11
Author:    azvegint
Date:      2014-11-11 17:41 +0300
URL:       http://hg.openjdk.java.net/aarch64-port/jdk8/jdk/rev/57c71d39ee11

8060461: Fix for JDK-8042609 uncovers additional issue
Reviewed-by: ahgross, prr, serb

! src/solaris/native/sun/awt/splashscreen/splashscreen_sys.c

Changeset: 42143c36af71
Author:    smarks
Date:      2014-11-06 14:28 -0800
URL:       http://hg.openjdk.java.net/aarch64-port/jdk8/jdk/rev/42143c36af71

8062807: Exporting RMI objects fails when run under restrictive SecurityManager
Reviewed-by: dfuchs, skoivu, igerasim, msheppar

! src/share/classes/sun/rmi/transport/tcp/TCPTransport.java

Changeset: 8425e4fb182c
Author:    asaha
Date:      2014-11-19 15:29 -0800
URL:       http://hg.openjdk.java.net/aarch64-port/jdk8/jdk/rev/8425e4fb182c

Merge

! .hgtags
! src/solaris/native/sun/awt/splashscreen/splashscreen_sys.c

Changeset: 19e02e44f2c8
Author:    asaha
Date:      2014-12-01 11:37 -0800
URL:       http://hg.openjdk.java.net/aarch64-port/jdk8/jdk/rev/19e02e44f2c8

Merge

! .hgtags
! src/share/classes/sun/security/ssl/Handshaker.java

Changeset: e0c7864bbca3
Author:    asaha
Date:      2015-04-09 12:57 -0700
URL:       http://hg.openjdk.java.net/aarch64-port/jdk8/jdk/rev/e0c7864bbca3

Merge

! .hgtags
- test/javax/swing/JComboBox/ConsumedEscTest/ConsumedEscTest.java

Changeset: b28b9f4d597b
Author:    asaha
Date:      2015-04-09 13:01 -0700
URL:       http://hg.openjdk.java.net/aarch64-port/jdk8/jdk/rev/b28b9f4d597b

Added tag jdk8u45-b01 for changeset e0c7864bbca3

! .hgtags

Changeset: 287e3219f3f5
Author:    asaha
Date:      2015-01-23 10:36 -0800
URL:       http://hg.openjdk.java.net/aarch64-port/jdk8/jdk/rev/287e3219f3f5

Added tag jdk8u31-b14 for changeset 367c7f061c58

! .hgtags

Changeset: a66fa02f1cef
Author:    asaha
Date:      2015-02-09 13:30 -0800
URL:       http://hg.openjdk.java.net/aarch64-port/jdk8/jdk/rev/a66fa02f1cef

Added tag jdk8u31-b15 for changeset 287e3219f3f5

! .hgtags

Changeset: 8007f5d79312
Author:    asaha
Date:      2015-04-09 13:04 -0700
URL:       http://hg.openjdk.java.net/aarch64-port/jdk8/jdk/rev/8007f5d79312

Merge

! .hgtags

Changeset: 4b83d5a90ed6
Author:    prr
Date:      2014-12-18 11:18 -0800
URL:       http://hg.openjdk.java.net/aarch64-port/jdk8/jdk/rev/4b83d5a90ed6

8065286: Fewer subtable substitutions
Reviewed-by: bae, srl, mschoene

! src/share/native/sun/font/layout/MultipleSubstSubtables.cpp

Changeset: 691af7ed6c3a
Author:    prr
Date:      2014-12-18 11:19 -0800
URL:       http://hg.openjdk.java.net/aarch64-port/jdk8/jdk/rev/691af7ed6c3a

8065291: Improved font lookups
Reviewed-by: bae, srl, mschoene

! src/share/native/sun/font/layout/LookupProcessor.cpp

Changeset: d02988beec6a
Author:    prr
Date:      2014-12-18 11:19 -0800
URL:       http://hg.openjdk.java.net/aarch64-port/jdk8/jdk/rev/d02988beec6a

8067050: Better font consistency checking
Reviewed-by: bae, srl, mschoene

! src/share/native/sun/font/layout/LETableReference.h
! src/share/native/sun/font/layout/LigatureSubstSubtables.cpp

Changeset: 21256885aaef
Author:    juh
Date:      2014-12-19 15:39 -0800
URL:       http://hg.openjdk.java.net/aarch64-port/jdk8/jdk/rev/21256885aaef

8066479: Better certificate chain validation
Reviewed-by: mullan

! src/share/classes/sun/security/pkcs12/PKCS12KeyStore.java

Changeset: 9505c0392cdd
Author:    asaha
Date:      2015-04-09 13:13 -0700
URL:       http://hg.openjdk.java.net/aarch64-port/jdk8/jdk/rev/9505c0392cdd

Merge

! .hgtags

Changeset: 67577775a34f
Author:    asaha
Date:      2015-04-09 13:15 -0700
URL:       http://hg.openjdk.java.net/aarch64-port/jdk8/jdk/rev/67577775a34f

Added tag jdk8u45-b02 for changeset 9505c0392cdd

! .hgtags

Changeset: 30351be78299
Author:    asaha
Date:      2015-04-09 13:20 -0700
URL:       http://hg.openjdk.java.net/aarch64-port/jdk8/jdk/rev/30351be78299

Merge

! .hgtags

Changeset: 437ced8e94a3
Author:    prr
Date:      2015-01-07 13:27 -0800
URL:       http://hg.openjdk.java.net/aarch64-port/jdk8/jdk/rev/437ced8e94a3

8067684: Better font substitutions
Reviewed-by: bae, srl, mschoene

! src/share/native/sun/font/layout/MultipleSubstSubtables.cpp

Changeset: afefb260f8f0
Author:    katleman
Date:      2014-11-19 11:27 -0800
URL:       http://hg.openjdk.java.net/aarch64-port/jdk8/jdk/rev/afefb260f8f0

Added tag jdk8u25-b32 for changeset 5c06b8274d27

! .hgtags

Changeset: 599e53ff3189
Author:    asaha
Date:      2014-12-03 09:28 -0800
URL:       http://hg.openjdk.java.net/aarch64-port/jdk8/jdk/rev/599e53ff3189

Merge

! .hgtags

Changeset: d55c202b2b8e
Author:    asaha
Date:      2014-12-12 08:47 -0800
URL:       http://hg.openjdk.java.net/aarch64-port/jdk8/jdk/rev/d55c202b2b8e

Merge

! .hgtags

Changeset: 21888626b77e
Author:    asaha
Date:      2014-12-18 14:21 -0800
URL:       http://hg.openjdk.java.net/aarch64-port/jdk8/jdk/rev/21888626b77e

Merge

! .hgtags

Changeset: d867ae62cc87
Author:    asaha
Date:      2014-12-17 08:44 -0800
URL:       http://hg.openjdk.java.net/aarch64-port/jdk8/jdk/rev/d867ae62cc87

Added tag jdk8u25-b33 for changeset afefb260f8f0

! .hgtags

Changeset: ced84cf3eebc
Author:    asaha
Date:      2014-12-18 14:34 -0800
URL:       http://hg.openjdk.java.net/aarch64-port/jdk8/jdk/rev/ced84cf3eebc

Merge

! .hgtags

Changeset: 17af4523dfc7
Author:    asaha
Date:      2015-04-09 13:24 -0700
URL:       http://hg.openjdk.java.net/aarch64-port/jdk8/jdk/rev/17af4523dfc7

Merge

! .hgtags

Changeset: ac97b69b88e3
Author:    asaha
Date:      2015-04-09 13:24 -0700
URL:       http://hg.openjdk.java.net/aarch64-port/jdk8/jdk/rev/ac97b69b88e3

Added tag jdk8u45-b03 for changeset 17af4523dfc7

! .hgtags

Changeset: 0f3413e0bb06
Author:    prr
Date:      2015-01-15 09:50 -0800
URL:       http://hg.openjdk.java.net/aarch64-port/jdk8/jdk/rev/0f3413e0bb06

8067699: Better glyph storage
Reviewed-by: srl, bae, mschoene

! src/share/native/sun/font/layout/LigatureSubstProc.cpp
! src/share/native/sun/font/layout/LigatureSubstProc2.cpp

Changeset: c407e143c5a6
Author:    serb
Date:      2015-01-19 12:26 +0300
URL:       http://hg.openjdk.java.net/aarch64-port/jdk8/jdk/rev/c407e143c5a6

8068320: Limit applet requests
Reviewed-by: prr, skoivu, art

! make/data/swingbeaninfo/SwingBeanInfo.template
! src/share/classes/java/beans/Beans.java
! src/share/classes/java/beans/SimpleBeanInfo.java

Changeset: 52022313ee3e
Author:    azvegint
Date:      2015-01-19 20:12 +0300
URL:       http://hg.openjdk.java.net/aarch64-port/jdk8/jdk/rev/52022313ee3e

8069198: Upgrade image library
Reviewed-by: ahgross, bae, mschoene, serb

! src/share/native/sun/awt/libpng/CHANGES
! src/share/native/sun/awt/libpng/LICENSE
! src/share/native/sun/awt/libpng/README
! src/share/native/sun/awt/libpng/png.c
! src/share/native/sun/awt/libpng/png.h
! src/share/native/sun/awt/libpng/pngconf.h
! src/share/native/sun/awt/libpng/pngdebug.h
! src/share/native/sun/awt/libpng/pngerror.c
! src/share/native/sun/awt/libpng/pngget.c
! src/share/native/sun/awt/libpng/pnginfo.h
! src/share/native/sun/awt/libpng/pnglibconf.h
! src/share/native/sun/awt/libpng/pngmem.c
! src/share/native/sun/awt/libpng/pngpread.c
! src/share/native/sun/awt/libpng/pngpriv.h
! src/share/native/sun/awt/libpng/pngread.c
! src/share/native/sun/awt/libpng/pngrio.c
! src/share/native/sun/awt/libpng/pngrtran.c
! src/share/native/sun/awt/libpng/pngrutil.c
! src/share/native/sun/awt/libpng/pngset.c
! src/share/native/sun/awt/libpng/pngstruct.h
! src/share/native/sun/awt/libpng/pngtest.c
! src/share/native/sun/awt/libpng/pngtrans.c
! src/share/native/sun/awt/libpng/pngwio.c
! src/share/native/sun/awt/libpng/pngwrite.c
! src/share/native/sun/awt/libpng/pngwtran.c
! src/share/native/sun/awt/libpng/pngwutil.c

Changeset: 77702cc5ab9b
Author:    asaha
Date:      2015-04-09 13:30 -0700
URL:       http://hg.openjdk.java.net/aarch64-port/jdk8/jdk/rev/77702cc5ab9b

Merge

! .hgtags

Changeset: 46338075c426
Author:    asaha
Date:      2015-01-12 06:49 -0800
URL:       http://hg.openjdk.java.net/aarch64-port/jdk8/jdk/rev/46338075c426

Added tag jdk8u31-b31 for changeset ced84cf3eebc

! .hgtags

Changeset: e5c49cf05c3a
Author:    asaha
Date:      2015-04-09 13:32 -0700
URL:       http://hg.openjdk.java.net/aarch64-port/jdk8/jdk/rev/e5c49cf05c3a

Merge

! .hgtags

Changeset: a26b2f5bc729
Author:    serb
Date:      2014-12-16 19:46 +0000
URL:       http://hg.openjdk.java.net/aarch64-port/jdk8/jdk/rev/a26b2f5bc729

8065373: [macosx] jdk8, jdk7u60 Regression in Graphics2D drawing of derived Fonts
Reviewed-by: bae, prr

! src/macosx/native/sun/font/AWTStrike.m
+ test/java/awt/Graphics2D/DrawString/DrawRotatedStringUsingRotatedFont.java

Changeset: 81a162833f4d
Author:    asaha
Date:      2015-04-09 13:34 -0700
URL:       http://hg.openjdk.java.net/aarch64-port/jdk8/jdk/rev/81a162833f4d

Added tag jdk8u45-b04 for changeset a26b2f5bc729

! .hgtags

Changeset: 71d9467e14c7
Author:    asaha
Date:      2015-04-09 13:39 -0700
URL:       http://hg.openjdk.java.net/aarch64-port/jdk8/jdk/rev/71d9467e14c7

Merge

! .hgtags
! src/share/classes/sun/security/ssl/Handshaker.java

Changeset: 4d95b1faad78
Author:    mcherkas
Date:      2015-01-23 01:46 +0400
URL:       http://hg.openjdk.java.net/aarch64-port/jdk8/jdk/rev/4d95b1faad78

8065709: Deadlock in awt/logging apparently introduced by 8019623
Reviewed-by: ant, serb

! src/share/classes/java/awt/EventQueue.java

Changeset: 7e4bf1e7a2fe
Author:    asaha
Date:      2015-04-09 13:40 -0700
URL:       http://hg.openjdk.java.net/aarch64-port/jdk8/jdk/rev/7e4bf1e7a2fe

Added tag jdk8u45-b05 for changeset 4d95b1faad78

! .hgtags

Changeset: d3cfac8ed6ed
Author:    igerasim
Date:      2015-01-26 14:29 +0300
URL:       http://hg.openjdk.java.net/aarch64-port/jdk8/jdk/rev/d3cfac8ed6ed

8055045: StringIndexOutOfBoundsException while reading krb5.conf
Reviewed-by: mullan

! src/share/classes/sun/security/krb5/Config.java
! test/sun/security/krb5/ParseConfig.java
! test/sun/security/krb5/krb5.conf

Changeset: 4cc9179f6fce
Author:    asaha
Date:      2015-04-09 13:45 -0700
URL:       http://hg.openjdk.java.net/aarch64-port/jdk8/jdk/rev/4cc9179f6fce

Merge

! .hgtags

Changeset: 165947f5448a
Author:    sherman
Date:      2015-01-19 13:30 -0800
URL:       http://hg.openjdk.java.net/aarch64-port/jdk8/jdk/rev/165947f5448a

8064601: Improve jar file handling
Reviewed-by: alanb, ahgross

! src/share/classes/sun/tools/jar/Main.java
! src/share/classes/sun/tools/jar/resources/jar.properties

Changeset: 09d1946d3a2a
Author:    aefimov
Date:      2015-01-26 22:37 +0300
URL:       http://hg.openjdk.java.net/aarch64-port/jdk8/jdk/rev/09d1946d3a2a

8046817: JDK 8 schemagen tool does not generate xsd files for enum types
Reviewed-by: joehw, mkos

+ test/javax/xml/ws/8046817/GenerateEnumSchema.java
+ test/javax/xml/ws/8046817/TestClassType.java
+ test/javax/xml/ws/8046817/TestEnumType.java

Changeset: 85ffe9aa18ac
Author:    aefimov
Date:      2015-01-26 22:45 +0300
URL:       http://hg.openjdk.java.net/aarch64-port/jdk8/jdk/rev/85ffe9aa18ac

8062923: XSL: Run-time internal error in 'substring()'
8062924: XSL: wrong answer from substring() function
Reviewed-by: joehw

+ test/javax/xml/jaxp/transform/8062923/XslSubstringTest.java

Changeset: 60b032710816
Author:    asaha
Date:      2015-04-09 13:47 -0700
URL:       http://hg.openjdk.java.net/aarch64-port/jdk8/jdk/rev/60b032710816

Added tag jdk8u45-b06 for changeset 85ffe9aa18ac

! .hgtags

Changeset: cbf9979d67f8
Author:    asaha
Date:      2015-04-09 13:52 -0700
URL:       http://hg.openjdk.java.net/aarch64-port/jdk8/jdk/rev/cbf9979d67f8

Merge

! .hgtags

Changeset: cdf1a9436aec
Author:    aefimov
Date:      2015-02-06 18:42 +0300
URL:       http://hg.openjdk.java.net/aarch64-port/jdk8/jdk/rev/cdf1a9436aec

8072042: (tz) Support tzdata2015a
Reviewed-by: coffeys, okutsu

! make/data/tzdata/VERSION
! make/data/tzdata/antarctica
! make/data/tzdata/asia
! make/data/tzdata/backward
! make/data/tzdata/europe
! make/data/tzdata/leapseconds
! make/data/tzdata/northamerica
! make/data/tzdata/southamerica
! make/data/tzdata/zone.tab
! src/share/classes/sun/util/resources/TimeZoneNames.java
! src/share/classes/sun/util/resources/de/TimeZoneNames_de.java
! src/share/classes/sun/util/resources/es/TimeZoneNames_es.java
! src/share/classes/sun/util/resources/fr/TimeZoneNames_fr.java
! src/share/classes/sun/util/resources/it/TimeZoneNames_it.java
! src/share/classes/sun/util/resources/ja/TimeZoneNames_ja.java
! src/share/classes/sun/util/resources/ko/TimeZoneNames_ko.java
! src/share/classes/sun/util/resources/pt/TimeZoneNames_pt_BR.java
! src/share/classes/sun/util/resources/sv/TimeZoneNames_sv.java
! src/share/classes/sun/util/resources/zh/TimeZoneNames_zh_CN.java
! src/share/classes/sun/util/resources/zh/TimeZoneNames_zh_TW.java
! test/sun/util/calendar/zi/tzdata/VERSION
! test/sun/util/calendar/zi/tzdata/antarctica
! test/sun/util/calendar/zi/tzdata/asia
! test/sun/util/calendar/zi/tzdata/backward
! test/sun/util/calendar/zi/tzdata/europe
! test/sun/util/calendar/zi/tzdata/leapseconds
! test/sun/util/calendar/zi/tzdata/northamerica
! test/sun/util/calendar/zi/tzdata/southamerica
! test/sun/util/calendar/zi/tzdata/zone.tab

Changeset: d081a4a5c15b
Author:    asaha
Date:      2015-04-09 13:54 -0700
URL:       http://hg.openjdk.java.net/aarch64-port/jdk8/jdk/rev/d081a4a5c15b

Added tag jdk8u45-b07 for changeset cdf1a9436aec

! .hgtags

Changeset: 26878b00ab4e
Author:    asaha
Date:      2015-04-09 14:02 -0700
URL:       http://hg.openjdk.java.net/aarch64-port/jdk8/jdk/rev/26878b00ab4e

Merge

! .hgtags

Changeset: 021e89e04bb0
Author:    vinnie
Date:      2014-10-05 14:24 +0100
URL:       http://hg.openjdk.java.net/aarch64-port/jdk8/jdk/rev/021e89e04bb0

8041740: Test sun/security/tools/keytool/ListKeychainStore.sh fails on Mac
Reviewed-by: mullan

! test/sun/security/tools/keytool/ListKeychainStore.sh

Changeset: 6656dca5d059
Author:    robm
Date:      2015-02-10 23:32 +0000
URL:       http://hg.openjdk.java.net/aarch64-port/jdk8/jdk/rev/6656dca5d059

8065553: Failed Java web start via IPv6 (Java7u71 or later)
Reviewed-by: xuelei

! src/share/classes/sun/security/util/HostnameChecker.java
! test/sun/security/util/HostnameMatcher/TestHostnameChecker.java
+ test/sun/security/util/HostnameMatcher/cert5.crt

Changeset: 22e3fd13afe5
Author:    asaha
Date:      2015-04-09 14:04 -0700
URL:       http://hg.openjdk.java.net/aarch64-port/jdk8/jdk/rev/22e3fd13afe5

Added tag jdk8u45-b08 for changeset 6656dca5d059

! .hgtags

Changeset: 1083da8a8ec1
Author:    valeriep
Date:      2015-02-14 01:18 +0000
URL:       http://hg.openjdk.java.net/aarch64-port/jdk8/jdk/rev/1083da8a8ec1

8071726: Better RSA optimizations
Summary: Added a check when RSA signature is generated with a RSAPrivateCRTKey object.
Reviewed-by: mullan

! src/share/classes/com/sun/crypto/provider/RSACipher.java
! src/share/classes/sun/security/rsa/RSACore.java
! src/share/classes/sun/security/rsa/RSASignature.java

Changeset: 086130c691e5
Author:    asaha
Date:      2015-04-09 14:07 -0700
URL:       http://hg.openjdk.java.net/aarch64-port/jdk8/jdk/rev/086130c691e5

Added tag jdk8u45-b09 for changeset 1083da8a8ec1

! .hgtags

Changeset: 3edfbb32b3c0
Author:    coffeys
Date:      2015-02-25 11:44 +0000
URL:       http://hg.openjdk.java.net/aarch64-port/jdk8/jdk/rev/3edfbb32b3c0

7178362: Socket impls should ignore unsupported proxy types rather than throwing
Reviewed-by: chegar

! src/share/classes/java/net/SocksSocketImpl.java
+ test/java/net/Socks/BadProxySelector.java

Changeset: d5c563f5a3d2
Author:    asaha
Date:      2015-04-09 14:10 -0700
URL:       http://hg.openjdk.java.net/aarch64-port/jdk8/jdk/rev/d5c563f5a3d2

Added tag jdk8u45-b10 for changeset 3edfbb32b3c0

! .hgtags

Changeset: 04cda5b7a3c1
Author:    igerasim
Date:      2015-02-20 14:55 +0300
URL:       http://hg.openjdk.java.net/aarch64-port/jdk8/jdk/rev/04cda5b7a3c1

8068720: Better certificate options checking
Reviewed-by: mullan

! src/share/classes/sun/security/provider/certpath/DistributionPointFetcher.java
! src/share/classes/sun/security/x509/KeyUsageExtension.java
! src/share/classes/sun/security/x509/NetscapeCertTypeExtension.java
! src/share/classes/sun/security/x509/ReasonFlags.java

Changeset: fb21543dce39
Author:    asaha
Date:      2015-03-07 10:26 -0800
URL:       http://hg.openjdk.java.net/aarch64-port/jdk8/jdk/rev/fb21543dce39

Added tag jdk8u40-b26 for changeset 97f258823d7d

! .hgtags

Changeset: 7bdb5c7ea5d6
Author:    asaha
Date:      2015-04-09 14:14 -0700
URL:       http://hg.openjdk.java.net/aarch64-port/jdk8/jdk/rev/7bdb5c7ea5d6

Merge

! .hgtags

Changeset: c669323bd55a
Author:    asaha
Date:      2015-03-09 10:33 -0700
URL:       http://hg.openjdk.java.net/aarch64-port/jdk8/jdk/rev/c669323bd55a

8074662: Update 3rd party readme and license for LibPNG v 1.6.16
Reviewed-by: jeff

! THIRD_PARTY_README

Changeset: 9692664b2bc9
Author:    asaha
Date:      2015-04-09 14:15 -0700
URL:       http://hg.openjdk.java.net/aarch64-port/jdk8/jdk/rev/9692664b2bc9

Added tag jdk8u45-b11 for changeset c669323bd55a

! .hgtags

Changeset: d4453d784fb6
Author:    serb
Date:      2015-03-12 10:06 -0700
URL:       http://hg.openjdk.java.net/aarch64-port/jdk8/jdk/rev/d4453d784fb6

8074668: [macosx] Mac 10.10: Application run with splash screen has focus issues
Reviewed-by: prr, ant, alexsch

! src/macosx/native/sun/awt/splashscreen/splashscreen_sys.m
! test/java/awt/SplashScreen/MultiResolutionSplash/MultiResolutionSplashTest.java

Changeset: c7bbaa04eaa8
Author:    asaha
Date:      2015-03-12 20:17 -0700
URL:       http://hg.openjdk.java.net/aarch64-port/jdk8/jdk/rev/c7bbaa04eaa8

Added tag jdk8u40-b27 for changeset d4453d784fb6

! .hgtags

Changeset: 6a8f9512afa6
Author:    asaha
Date:      2015-04-09 14:19 -0700
URL:       http://hg.openjdk.java.net/aarch64-port/jdk8/jdk/rev/6a8f9512afa6

Merge

! .hgtags

Changeset: d464f2263fb4
Author:    asaha
Date:      2015-04-09 14:20 -0700
URL:       http://hg.openjdk.java.net/aarch64-port/jdk8/jdk/rev/d464f2263fb4

Added tag jdk8u45-b12 for changeset 6a8f9512afa6

! .hgtags

Changeset: 55a75b0db876
Author:    igerasim
Date:      2015-03-17 00:09 +0300
URL:       http://hg.openjdk.java.net/aarch64-port/jdk8/jdk/rev/55a75b0db876

8075040: Need a test to cover FREAK (BugDB 20647631)
Reviewed-by: wetmore

! src/share/classes/sun/security/ssl/ClientHandshaker.java

Changeset: 0460d0b4b168
Author:    asaha
Date:      2015-04-09 14:24 -0700
URL:       http://hg.openjdk.java.net/aarch64-port/jdk8/jdk/rev/0460d0b4b168

Added tag jdk8u45-b13 for changeset 55a75b0db876

! .hgtags

Changeset: 20e6cadfac43
Author:    sla
Date:      2015-02-05 13:00 +0100
URL:       http://hg.openjdk.java.net/aarch64-port/jdk8/jdk/rev/20e6cadfac43

8072458: jdk/test/Makefile references (to be removed) win32 directory in jtreg
Reviewed-by: alanb

! test/Makefile

Changeset: 8ee42e32cba3
Author:    enevill
Date:      2015-04-16 11:37 +0100
URL:       http://hg.openjdk.java.net/aarch64-port/jdk8/jdk/rev/8ee42e32cba3

Merge up to jdk8u45-b14

! .hgtags
! make/data/tzdata/VERSION
! make/data/tzdata/antarctica
! make/data/tzdata/asia
! make/data/tzdata/backward
! make/data/tzdata/europe
! make/data/tzdata/leapseconds
! make/data/tzdata/northamerica
! make/data/tzdata/southamerica
! make/data/tzdata/zone.tab
! src/share/classes/java/awt/EventQueue.java
! src/share/classes/java/beans/Beans.java
! src/share/classes/java/net/SocksSocketImpl.java
! src/share/classes/sun/security/krb5/Config.java
! src/share/classes/sun/security/ssl/ClientHandshaker.java
! src/share/classes/sun/security/ssl/Handshaker.java
! src/share/classes/sun/security/util/HostnameChecker.java
! src/share/classes/sun/tools/jar/Main.java
! src/share/classes/sun/tools/jar/resources/jar.properties
! src/share/classes/sun/util/resources/TimeZoneNames.java
! src/share/classes/sun/util/resources/de/TimeZoneNames_de.java
! src/share/classes/sun/util/resources/es/TimeZoneNames_es.java
! src/share/classes/sun/util/resources/fr/TimeZoneNames_fr.java
! src/share/classes/sun/util/resources/it/TimeZoneNames_it.java
! src/share/classes/sun/util/resources/ja/TimeZoneNames_ja.java
! src/share/classes/sun/util/resources/ko/TimeZoneNames_ko.java
! src/share/classes/sun/util/resources/pt/TimeZoneNames_pt_BR.java
! src/share/classes/sun/util/resources/sv/TimeZoneNames_sv.java
! src/share/classes/sun/util/resources/zh/TimeZoneNames_zh_CN.java
! src/share/classes/sun/util/resources/zh/TimeZoneNames_zh_TW.java
! src/share/native/sun/awt/libpng/CHANGES
! src/share/native/sun/awt/libpng/png.h
! src/share/native/sun/awt/libpng/pngconf.h
! src/share/native/sun/awt/libpng/pngpriv.h
! src/share/native/sun/awt/libpng/pngrutil.c
! test/Makefile
! test/sun/security/tools/keytool/ListKeychainStore.sh
! test/sun/util/calendar/zi/tzdata/VERSION
! test/sun/util/calendar/zi/tzdata/antarctica
! test/sun/util/calendar/zi/tzdata/asia
! test/sun/util/calendar/zi/tzdata/backward
! test/sun/util/calendar/zi/tzdata/europe
! test/sun/util/calendar/zi/tzdata/leapseconds
! test/sun/util/calendar/zi/tzdata/northamerica
! test/sun/util/calendar/zi/tzdata/southamerica
! test/sun/util/calendar/zi/tzdata/zone.tab

Changeset: 2627c4dba1df
Author:    enevill
Date:      2015-04-16 15:05 +0100
URL:       http://hg.openjdk.java.net/aarch64-port/jdk8/jdk/rev/2627c4dba1df

Fix build for aarch64.

! src/share/native/sun/awt/libpng/pngpriv.h


From edward.nevill at gmail.com  Thu Apr 16 15:27:50 2015
From: edward.nevill at gmail.com (edward.nevill at gmail.com)
Date: Thu, 16 Apr 2015 15:27:50 +0000
Subject: [aarch64-port-dev ] hg: aarch64-port/jdk8/langtools: 50 new
	changesets
Message-ID: <201504161527.t3GFRos8003856@aojmv0008>

Changeset: 0b599186b383
Author:    asaha
Date:      2014-10-07 08:52 -0700
URL:       http://hg.openjdk.java.net/aarch64-port/jdk8/langtools/rev/0b599186b383

Merge

! .hgtags

Changeset: 89596e168f2f
Author:    asaha
Date:      2014-10-09 12:10 -0700
URL:       http://hg.openjdk.java.net/aarch64-port/jdk8/langtools/rev/89596e168f2f

Added tag jdk8u45-b00 for changeset dbae37f50c43

! .hgtags

Changeset: 89cd4673dc32
Author:    asaha
Date:      2014-10-09 13:20 -0700
URL:       http://hg.openjdk.java.net/aarch64-port/jdk8/langtools/rev/89cd4673dc32

Merge

! .hgtags

Changeset: a78a2a8b0086
Author:    asaha
Date:      2014-10-14 11:46 -0700
URL:       http://hg.openjdk.java.net/aarch64-port/jdk8/langtools/rev/a78a2a8b0086

Merge

! .hgtags

Changeset: 59265b02b828
Author:    asaha
Date:      2014-10-20 23:08 -0700
URL:       http://hg.openjdk.java.net/aarch64-port/jdk8/langtools/rev/59265b02b828

Merge

! .hgtags

Changeset: 5b374f8ee3c3
Author:    asaha
Date:      2014-10-27 14:35 -0700
URL:       http://hg.openjdk.java.net/aarch64-port/jdk8/langtools/rev/5b374f8ee3c3

Merge

! .hgtags
- test/tools/javac/varargs/6313164/T6313164.out

Changeset: f89d4eaa6484
Author:    asaha
Date:      2014-11-06 09:49 -0800
URL:       http://hg.openjdk.java.net/aarch64-port/jdk8/langtools/rev/f89d4eaa6484

Merge

! .hgtags

Changeset: e2c6204e7ed1
Author:    asaha
Date:      2014-11-19 16:25 -0800
URL:       http://hg.openjdk.java.net/aarch64-port/jdk8/langtools/rev/e2c6204e7ed1

Merge

! .hgtags

Changeset: d4c7822e9d64
Author:    asaha
Date:      2014-12-01 11:39 -0800
URL:       http://hg.openjdk.java.net/aarch64-port/jdk8/langtools/rev/d4c7822e9d64

Merge

! .hgtags

Changeset: 244e6dc77287
Author:    asaha
Date:      2014-12-12 14:57 -0800
URL:       http://hg.openjdk.java.net/aarch64-port/jdk8/langtools/rev/244e6dc77287

Merge

! .hgtags

Changeset: 9939fda7ed45
Author:    asaha
Date:      2014-12-15 15:39 -0800
URL:       http://hg.openjdk.java.net/aarch64-port/jdk8/langtools/rev/9939fda7ed45

Added tag jdk8u45-b01 for changeset 244e6dc77287

! .hgtags

Changeset: c6fe82e540ce
Author:    asaha
Date:      2014-12-17 09:14 -0800
URL:       http://hg.openjdk.java.net/aarch64-port/jdk8/langtools/rev/c6fe82e540ce

Merge

! .hgtags

Changeset: 9b4b05686ce8
Author:    asaha
Date:      2014-12-22 10:12 -0800
URL:       http://hg.openjdk.java.net/aarch64-port/jdk8/langtools/rev/9b4b05686ce8

Merge

! .hgtags
- test/lib/annotations/annotations/classfile/ClassfileInspector.java
- test/tools/javac/annotations/SyntheticParameters.java
- test/tools/javac/annotations/typeAnnotations/classfile/SyntheticParameters.java

Changeset: b72a49d88cc3
Author:    katleman
Date:      2014-11-19 11:27 -0800
URL:       http://hg.openjdk.java.net/aarch64-port/jdk8/langtools/rev/b72a49d88cc3

Added tag jdk8u25-b32 for changeset a2a922ccc00f

! .hgtags

Changeset: 0a8e28b99cc4
Author:    asaha
Date:      2014-12-03 09:34 -0800
URL:       http://hg.openjdk.java.net/aarch64-port/jdk8/langtools/rev/0a8e28b99cc4

Merge

! .hgtags

Changeset: f124c0e96762
Author:    asaha
Date:      2014-12-12 08:48 -0800
URL:       http://hg.openjdk.java.net/aarch64-port/jdk8/langtools/rev/f124c0e96762

Merge

! .hgtags

Changeset: 3e4c476ecda8
Author:    asaha
Date:      2014-12-18 14:22 -0800
URL:       http://hg.openjdk.java.net/aarch64-port/jdk8/langtools/rev/3e4c476ecda8

Merge

! .hgtags

Changeset: d8f73bf3808a
Author:    asaha
Date:      2014-12-17 08:45 -0800
URL:       http://hg.openjdk.java.net/aarch64-port/jdk8/langtools/rev/d8f73bf3808a

Added tag jdk8u25-b33 for changeset b72a49d88cc3

! .hgtags

Changeset: b813a76f1091
Author:    asaha
Date:      2014-12-18 14:36 -0800
URL:       http://hg.openjdk.java.net/aarch64-port/jdk8/langtools/rev/b813a76f1091

Merge

! .hgtags

Changeset: 401ec7688762
Author:    asaha
Date:      2014-12-22 12:16 -0800
URL:       http://hg.openjdk.java.net/aarch64-port/jdk8/langtools/rev/401ec7688762

Merge

! .hgtags

Changeset: eb60995deeb0
Author:    asaha
Date:      2014-12-22 14:02 -0800
URL:       http://hg.openjdk.java.net/aarch64-port/jdk8/langtools/rev/eb60995deeb0

Added tag jdk8u45-b02 for changeset 401ec7688762

! .hgtags

Changeset: c75d27bc0368
Author:    asaha
Date:      2014-12-29 14:45 -0800
URL:       http://hg.openjdk.java.net/aarch64-port/jdk8/langtools/rev/c75d27bc0368

Merge

! .hgtags

Changeset: 82f61074191f
Author:    asaha
Date:      2015-01-05 09:28 -0800
URL:       http://hg.openjdk.java.net/aarch64-port/jdk8/langtools/rev/82f61074191f

Merge

! .hgtags

Changeset: ac1c3ae88463
Author:    asaha
Date:      2015-01-05 10:04 -0800
URL:       http://hg.openjdk.java.net/aarch64-port/jdk8/langtools/rev/ac1c3ae88463

Merge

! .hgtags

Changeset: 8dc0c7e42d90
Author:    asaha
Date:      2015-01-12 06:50 -0800
URL:       http://hg.openjdk.java.net/aarch64-port/jdk8/langtools/rev/8dc0c7e42d90

Added tag jdk8u31-b31 for changeset b813a76f1091

! .hgtags

Changeset: 79d31ae9990e
Author:    asaha
Date:      2015-01-12 07:47 -0800
URL:       http://hg.openjdk.java.net/aarch64-port/jdk8/langtools/rev/79d31ae9990e

Merge

! .hgtags

Changeset: 45b96d038dd9
Author:    asaha
Date:      2015-01-12 13:51 -0800
URL:       http://hg.openjdk.java.net/aarch64-port/jdk8/langtools/rev/45b96d038dd9

Added tag jdk8u45-b03 for changeset 79d31ae9990e

! .hgtags

Changeset: d8ce0450b95d
Author:    asaha
Date:      2015-01-19 12:36 -0800
URL:       http://hg.openjdk.java.net/aarch64-port/jdk8/langtools/rev/d8ce0450b95d

Merge

! .hgtags

Changeset: f75e26a5c3ac
Author:    asaha
Date:      2015-01-20 09:56 -0800
URL:       http://hg.openjdk.java.net/aarch64-port/jdk8/langtools/rev/f75e26a5c3ac

Added tag jdk8u31-b32 for changeset 8dc0c7e42d90

! .hgtags

Changeset: 47292f3c0da7
Author:    asaha
Date:      2015-01-20 10:22 -0800
URL:       http://hg.openjdk.java.net/aarch64-port/jdk8/langtools/rev/47292f3c0da7

Merge

! .hgtags

Changeset: a09fd5eb6340
Author:    asaha
Date:      2015-01-20 12:31 -0800
URL:       http://hg.openjdk.java.net/aarch64-port/jdk8/langtools/rev/a09fd5eb6340

Added tag jdk8u45-b04 for changeset 47292f3c0da7

! .hgtags

Changeset: 77d7dd7f35d6
Author:    asaha
Date:      2015-01-22 15:55 -0800
URL:       http://hg.openjdk.java.net/aarch64-port/jdk8/langtools/rev/77d7dd7f35d6

Merge

! .hgtags

Changeset: 3b96b8cbcc34
Author:    asaha
Date:      2015-01-26 12:02 -0800
URL:       http://hg.openjdk.java.net/aarch64-port/jdk8/langtools/rev/3b96b8cbcc34

Added tag jdk8u45-b05 for changeset 77d7dd7f35d6

! .hgtags

Changeset: 22cc48973eae
Author:    asaha
Date:      2015-01-28 15:33 -0800
URL:       http://hg.openjdk.java.net/aarch64-port/jdk8/langtools/rev/22cc48973eae

Merge

! .hgtags

Changeset: 72ef38be1bc0
Author:    asaha
Date:      2015-02-02 13:31 -0800
URL:       http://hg.openjdk.java.net/aarch64-port/jdk8/langtools/rev/72ef38be1bc0

Added tag jdk8u45-b06 for changeset 22cc48973eae

! .hgtags

Changeset: 460238ab73ce
Author:    asaha
Date:      2015-02-04 13:18 -0800
URL:       http://hg.openjdk.java.net/aarch64-port/jdk8/langtools/rev/460238ab73ce

Merge

! .hgtags

Changeset: 7bafab244463
Author:    asaha
Date:      2015-02-09 09:09 -0800
URL:       http://hg.openjdk.java.net/aarch64-port/jdk8/langtools/rev/7bafab244463

Added tag jdk8u45-b07 for changeset 460238ab73ce

! .hgtags

Changeset: 6dd7fd9f027b
Author:    asaha
Date:      2015-02-11 14:23 -0800
URL:       http://hg.openjdk.java.net/aarch64-port/jdk8/langtools/rev/6dd7fd9f027b

Merge

! .hgtags

Changeset: db16aa5c73c9
Author:    asaha
Date:      2015-02-16 11:07 -0800
URL:       http://hg.openjdk.java.net/aarch64-port/jdk8/langtools/rev/db16aa5c73c9

Added tag jdk8u45-b08 for changeset 6dd7fd9f027b

! .hgtags

Changeset: 572895f19937
Author:    asaha
Date:      2015-02-23 14:49 -0800
URL:       http://hg.openjdk.java.net/aarch64-port/jdk8/langtools/rev/572895f19937

Added tag jdk8u45-b09 for changeset db16aa5c73c9

! .hgtags

Changeset: 02590504016c
Author:    asaha
Date:      2015-03-02 11:16 -0800
URL:       http://hg.openjdk.java.net/aarch64-port/jdk8/langtools/rev/02590504016c

Added tag jdk8u45-b10 for changeset 572895f19937

! .hgtags

Changeset: 83eca922346e
Author:    asaha
Date:      2015-03-07 10:27 -0800
URL:       http://hg.openjdk.java.net/aarch64-port/jdk8/langtools/rev/83eca922346e

Added tag jdk8u40-b26 for changeset 2904142783dd

! .hgtags

Changeset: 0547ef2be3b3
Author:    asaha
Date:      2015-03-07 16:32 -0800
URL:       http://hg.openjdk.java.net/aarch64-port/jdk8/langtools/rev/0547ef2be3b3

Merge

! .hgtags

Changeset: 61d3a434fe63
Author:    asaha
Date:      2015-03-09 12:41 -0700
URL:       http://hg.openjdk.java.net/aarch64-port/jdk8/langtools/rev/61d3a434fe63

Added tag jdk8u45-b11 for changeset 0547ef2be3b3

! .hgtags

Changeset: 40af410251eb
Author:    asaha
Date:      2015-03-10 15:34 -0700
URL:       http://hg.openjdk.java.net/aarch64-port/jdk8/langtools/rev/40af410251eb

8074662: Update 3rd party readme and license for LibPNG v 1.6.16
Reviewed-by: jeff

! THIRD_PARTY_README

Changeset: 113fb26bd39f
Author:    asaha
Date:      2015-03-12 20:18 -0700
URL:       http://hg.openjdk.java.net/aarch64-port/jdk8/langtools/rev/113fb26bd39f

Added tag jdk8u40-b27 for changeset 83eca922346e

! .hgtags

Changeset: 4f89bbda7b45
Author:    asaha
Date:      2015-03-16 09:18 -0700
URL:       http://hg.openjdk.java.net/aarch64-port/jdk8/langtools/rev/4f89bbda7b45

Merge

! .hgtags

Changeset: 5ce022bca792
Author:    asaha
Date:      2015-03-16 11:21 -0700
URL:       http://hg.openjdk.java.net/aarch64-port/jdk8/langtools/rev/5ce022bca792

Added tag jdk8u45-b12 for changeset 4f89bbda7b45

! .hgtags

Changeset: 847af465a542
Author:    asaha
Date:      2015-03-17 11:25 -0700
URL:       http://hg.openjdk.java.net/aarch64-port/jdk8/langtools/rev/847af465a542

Added tag jdk8u45-b13 for changeset 5ce022bca792

! .hgtags

Changeset: ba2b96e342fc
Author:    enevill
Date:      2015-04-16 11:37 +0100
URL:       http://hg.openjdk.java.net/aarch64-port/jdk8/langtools/rev/ba2b96e342fc

Merge up to jdk8u45-b14

! .hgtags


From edward.nevill at gmail.com  Thu Apr 16 15:28:03 2015
From: edward.nevill at gmail.com (edward.nevill at gmail.com)
Date: Thu, 16 Apr 2015 15:28:03 +0000
Subject: [aarch64-port-dev ] hg: aarch64-port/jdk8/nashorn: 50 new changesets
Message-ID: <201504161528.t3GFS3kZ003928@aojmv0008>

Changeset: 4f50cc615f4f
Author:    asaha
Date:      2014-10-07 08:52 -0700
URL:       http://hg.openjdk.java.net/aarch64-port/jdk8/nashorn/rev/4f50cc615f4f

Merge

! .hgtags

Changeset: 5f55fc1cdd89
Author:    asaha
Date:      2014-10-09 12:10 -0700
URL:       http://hg.openjdk.java.net/aarch64-port/jdk8/nashorn/rev/5f55fc1cdd89

Added tag jdk8u45-b00 for changeset 05a3614ed527

! .hgtags

Changeset: e1ffa500f0d8
Author:    asaha
Date:      2014-10-09 13:20 -0700
URL:       http://hg.openjdk.java.net/aarch64-port/jdk8/nashorn/rev/e1ffa500f0d8

Merge

! .hgtags

Changeset: 4c44c000d62e
Author:    asaha
Date:      2014-10-14 11:47 -0700
URL:       http://hg.openjdk.java.net/aarch64-port/jdk8/nashorn/rev/4c44c000d62e

Merge

! .hgtags

Changeset: cf8a0b40b754
Author:    asaha
Date:      2014-10-20 23:09 -0700
URL:       http://hg.openjdk.java.net/aarch64-port/jdk8/nashorn/rev/cf8a0b40b754

Merge

! .hgtags

Changeset: fd5d4ebfe7db
Author:    asaha
Date:      2014-10-27 14:36 -0700
URL:       http://hg.openjdk.java.net/aarch64-port/jdk8/nashorn/rev/fd5d4ebfe7db

Merge

! .hgtags
- bin/checkintest.sh
- bin/dump_octane_code.sh
- bin/fixorphantests.sh
! bin/fixwhitespace.sh
- bin/jjs
- bin/jjs.bat
- bin/jjssecure
- bin/jjssecure.bat
- bin/nashorn
- bin/nashorn.bat
- bin/nashornsecure
- bin/nashornsecure.bat
- bin/rm-non-tracked.sh
- bin/verbose_octane.bat
- bin/verbose_octane.sh
- src/jdk/nashorn/api/scripting/resources/engine.js
- src/jdk/nashorn/internal/codegen/Attr.java
- src/jdk/nashorn/internal/codegen/FinalizeTypes.java
- src/jdk/nashorn/internal/codegen/RangeAnalyzer.java
- src/jdk/nashorn/internal/codegen/types/Range.java
- src/jdk/nashorn/internal/ir/TemporarySymbols.java
- src/jdk/nashorn/internal/objects/annotations/SpecializedConstructor.java
- src/jdk/nashorn/internal/runtime/CompiledFunctions.java
- src/jdk/nashorn/internal/runtime/CompiledScript.java
- src/jdk/nashorn/internal/runtime/DebugLogger.java
- src/jdk/nashorn/internal/runtime/Logging.java
- test/script/basic/JDK-8010697.js
- test/script/basic/JDK-8010697.js.EXPECTED
- test/script/basic/arraysIntKey.js
- test/script/basic/arraysIntKey.js.EXPECTED
- test/script/basic/compile-octane.js.EXPECTED
- test/script/basic/ranges_disabled.js
- test/script/basic/ranges_disabled.js.EXPECTED
- test/script/basic/ranges_enabled.js
- test/script/basic/ranges_enabled.js.EXPECTED
- test/script/basic/ranges_payload.js
- test/script/basic/runsunspider-eager.js
- test/script/basic/runsunspider-lazy.js
- test/script/basic/runsunspider-lazy.js.EXPECTED
- test/script/maptests/property_delete.js

Changeset: 72c7148acf87
Author:    asaha
Date:      2014-11-06 09:50 -0800
URL:       http://hg.openjdk.java.net/aarch64-port/jdk8/nashorn/rev/72c7148acf87

Merge

! .hgtags
- src/jdk/nashorn/internal/codegen/SplitMethodEmitter.java
- src/jdk/nashorn/internal/runtime/arrays/NoTypeArrayData.java

Changeset: 7b05a206ec6a
Author:    asaha
Date:      2014-11-19 16:35 -0800
URL:       http://hg.openjdk.java.net/aarch64-port/jdk8/nashorn/rev/7b05a206ec6a

Merge

! .hgtags

Changeset: b54270ace5e5
Author:    asaha
Date:      2014-12-01 11:40 -0800
URL:       http://hg.openjdk.java.net/aarch64-port/jdk8/nashorn/rev/b54270ace5e5

Merge

! .hgtags

Changeset: 21ec16eb7e63
Author:    asaha
Date:      2014-12-12 14:58 -0800
URL:       http://hg.openjdk.java.net/aarch64-port/jdk8/nashorn/rev/21ec16eb7e63

Merge

! .hgtags
- src/jdk/nashorn/internal/runtime/linker/BoundDynamicMethod.java
- src/jdk/nashorn/internal/runtime/linker/BoundDynamicMethodLinker.java

Changeset: 95ab924f3a47
Author:    asaha
Date:      2014-12-15 15:39 -0800
URL:       http://hg.openjdk.java.net/aarch64-port/jdk8/nashorn/rev/95ab924f3a47

Added tag jdk8u45-b01 for changeset 21ec16eb7e63

! .hgtags

Changeset: acb6d1468f2f
Author:    asaha
Date:      2014-12-17 09:14 -0800
URL:       http://hg.openjdk.java.net/aarch64-port/jdk8/nashorn/rev/acb6d1468f2f

Merge

! .hgtags

Changeset: 7b12e3b9f274
Author:    asaha
Date:      2014-12-22 10:13 -0800
URL:       http://hg.openjdk.java.net/aarch64-port/jdk8/nashorn/rev/7b12e3b9f274

Merge

! .hgtags

Changeset: a8526abf70a8
Author:    katleman
Date:      2014-11-19 11:27 -0800
URL:       http://hg.openjdk.java.net/aarch64-port/jdk8/nashorn/rev/a8526abf70a8

Added tag jdk8u25-b32 for changeset be20e9a00818

! .hgtags

Changeset: de0bd397806e
Author:    asaha
Date:      2014-12-03 09:44 -0800
URL:       http://hg.openjdk.java.net/aarch64-port/jdk8/nashorn/rev/de0bd397806e

Merge

! .hgtags

Changeset: fe5f9ef3841d
Author:    asaha
Date:      2014-12-12 08:48 -0800
URL:       http://hg.openjdk.java.net/aarch64-port/jdk8/nashorn/rev/fe5f9ef3841d

Merge

! .hgtags

Changeset: 859979ea4fa0
Author:    asaha
Date:      2014-12-18 14:22 -0800
URL:       http://hg.openjdk.java.net/aarch64-port/jdk8/nashorn/rev/859979ea4fa0

Merge

! .hgtags

Changeset: e7860689fbca
Author:    asaha
Date:      2014-12-17 08:45 -0800
URL:       http://hg.openjdk.java.net/aarch64-port/jdk8/nashorn/rev/e7860689fbca

Added tag jdk8u25-b33 for changeset a8526abf70a8

! .hgtags

Changeset: 34a64e22b81b
Author:    asaha
Date:      2014-12-18 14:37 -0800
URL:       http://hg.openjdk.java.net/aarch64-port/jdk8/nashorn/rev/34a64e22b81b

Merge

! .hgtags

Changeset: 37b3ef9a0732
Author:    asaha
Date:      2014-12-22 12:16 -0800
URL:       http://hg.openjdk.java.net/aarch64-port/jdk8/nashorn/rev/37b3ef9a0732

Merge

! .hgtags

Changeset: 0c9f6ee8f6e4
Author:    asaha
Date:      2014-12-22 14:02 -0800
URL:       http://hg.openjdk.java.net/aarch64-port/jdk8/nashorn/rev/0c9f6ee8f6e4

Added tag jdk8u45-b02 for changeset 37b3ef9a0732

! .hgtags

Changeset: 3b12cf144e83
Author:    asaha
Date:      2014-12-29 14:46 -0800
URL:       http://hg.openjdk.java.net/aarch64-port/jdk8/nashorn/rev/3b12cf144e83

Merge

! .hgtags

Changeset: 9184dad8f01c
Author:    asaha
Date:      2015-01-05 09:28 -0800
URL:       http://hg.openjdk.java.net/aarch64-port/jdk8/nashorn/rev/9184dad8f01c

Merge

! .hgtags

Changeset: 2d1c01990ebd
Author:    asaha
Date:      2015-01-05 10:04 -0800
URL:       http://hg.openjdk.java.net/aarch64-port/jdk8/nashorn/rev/2d1c01990ebd

Merge

! .hgtags

Changeset: d2b5784a3452
Author:    asaha
Date:      2015-01-12 06:50 -0800
URL:       http://hg.openjdk.java.net/aarch64-port/jdk8/nashorn/rev/d2b5784a3452

Added tag jdk8u31-b31 for changeset 34a64e22b81b

! .hgtags

Changeset: ed3a4177da50
Author:    asaha
Date:      2015-01-12 07:48 -0800
URL:       http://hg.openjdk.java.net/aarch64-port/jdk8/nashorn/rev/ed3a4177da50

Merge

! .hgtags

Changeset: 518a959bcf1c
Author:    asaha
Date:      2015-01-12 13:51 -0800
URL:       http://hg.openjdk.java.net/aarch64-port/jdk8/nashorn/rev/518a959bcf1c

Added tag jdk8u45-b03 for changeset ed3a4177da50

! .hgtags

Changeset: d515b79027a1
Author:    asaha
Date:      2015-01-19 12:37 -0800
URL:       http://hg.openjdk.java.net/aarch64-port/jdk8/nashorn/rev/d515b79027a1

Merge

! .hgtags

Changeset: c6dd08613a44
Author:    asaha
Date:      2015-01-20 09:56 -0800
URL:       http://hg.openjdk.java.net/aarch64-port/jdk8/nashorn/rev/c6dd08613a44

Added tag jdk8u31-b32 for changeset d2b5784a3452

! .hgtags

Changeset: 65f24dedfd29
Author:    asaha
Date:      2015-01-20 10:24 -0800
URL:       http://hg.openjdk.java.net/aarch64-port/jdk8/nashorn/rev/65f24dedfd29

Merge

! .hgtags

Changeset: d4bbd8278cb2
Author:    asaha
Date:      2015-01-20 12:32 -0800
URL:       http://hg.openjdk.java.net/aarch64-port/jdk8/nashorn/rev/d4bbd8278cb2

Added tag jdk8u45-b04 for changeset 65f24dedfd29

! .hgtags

Changeset: de2ee4c1341f
Author:    asaha
Date:      2015-01-22 15:56 -0800
URL:       http://hg.openjdk.java.net/aarch64-port/jdk8/nashorn/rev/de2ee4c1341f

Merge

! .hgtags

Changeset: e2fb963e644d
Author:    asaha
Date:      2015-01-26 12:02 -0800
URL:       http://hg.openjdk.java.net/aarch64-port/jdk8/nashorn/rev/e2fb963e644d

Added tag jdk8u45-b05 for changeset de2ee4c1341f

! .hgtags

Changeset: cf0097b8987d
Author:    asaha
Date:      2015-01-28 15:33 -0800
URL:       http://hg.openjdk.java.net/aarch64-port/jdk8/nashorn/rev/cf0097b8987d

Merge

! .hgtags

Changeset: 7a04ae4abff0
Author:    asaha
Date:      2015-02-02 13:31 -0800
URL:       http://hg.openjdk.java.net/aarch64-port/jdk8/nashorn/rev/7a04ae4abff0

Added tag jdk8u45-b06 for changeset cf0097b8987d

! .hgtags

Changeset: bb112473c731
Author:    asaha
Date:      2015-02-04 13:19 -0800
URL:       http://hg.openjdk.java.net/aarch64-port/jdk8/nashorn/rev/bb112473c731

Merge

! .hgtags

Changeset: 7b0a28d2d0d0
Author:    asaha
Date:      2015-02-09 09:09 -0800
URL:       http://hg.openjdk.java.net/aarch64-port/jdk8/nashorn/rev/7b0a28d2d0d0

Added tag jdk8u45-b07 for changeset bb112473c731

! .hgtags

Changeset: 8ab14ee47c8b
Author:    asaha
Date:      2015-02-11 14:23 -0800
URL:       http://hg.openjdk.java.net/aarch64-port/jdk8/nashorn/rev/8ab14ee47c8b

Merge

! .hgtags

Changeset: 397ea4a1bff8
Author:    asaha
Date:      2015-02-16 11:08 -0800
URL:       http://hg.openjdk.java.net/aarch64-port/jdk8/nashorn/rev/397ea4a1bff8

Added tag jdk8u45-b08 for changeset 8ab14ee47c8b

! .hgtags

Changeset: c650c13d2bdf
Author:    asaha
Date:      2015-02-23 14:50 -0800
URL:       http://hg.openjdk.java.net/aarch64-port/jdk8/nashorn/rev/c650c13d2bdf

Added tag jdk8u45-b09 for changeset 397ea4a1bff8

! .hgtags

Changeset: 072b761784dc
Author:    asaha
Date:      2015-03-02 11:16 -0800
URL:       http://hg.openjdk.java.net/aarch64-port/jdk8/nashorn/rev/072b761784dc

Added tag jdk8u45-b10 for changeset c650c13d2bdf

! .hgtags

Changeset: c2dd88e89edc
Author:    asaha
Date:      2015-03-07 10:27 -0800
URL:       http://hg.openjdk.java.net/aarch64-port/jdk8/nashorn/rev/c2dd88e89edc

Added tag jdk8u40-b26 for changeset b142a2d8e35e

! .hgtags

Changeset: 6ae873ddbe19
Author:    asaha
Date:      2015-03-07 16:32 -0800
URL:       http://hg.openjdk.java.net/aarch64-port/jdk8/nashorn/rev/6ae873ddbe19

Merge

! .hgtags

Changeset: 410d06e53e41
Author:    asaha
Date:      2015-03-09 12:42 -0700
URL:       http://hg.openjdk.java.net/aarch64-port/jdk8/nashorn/rev/410d06e53e41

Added tag jdk8u45-b11 for changeset 6ae873ddbe19

! .hgtags

Changeset: 308f37006951
Author:    asaha
Date:      2015-03-10 15:34 -0700
URL:       http://hg.openjdk.java.net/aarch64-port/jdk8/nashorn/rev/308f37006951

8074662: Update 3rd party readme and license for LibPNG v 1.6.16
Reviewed-by: jeff

! THIRD_PARTY_README

Changeset: b2b88f368f0a
Author:    asaha
Date:      2015-03-12 20:18 -0700
URL:       http://hg.openjdk.java.net/aarch64-port/jdk8/nashorn/rev/b2b88f368f0a

Added tag jdk8u40-b27 for changeset c2dd88e89edc

! .hgtags

Changeset: 9b9fee0f99cd
Author:    asaha
Date:      2015-03-16 09:19 -0700
URL:       http://hg.openjdk.java.net/aarch64-port/jdk8/nashorn/rev/9b9fee0f99cd

Merge

! .hgtags

Changeset: 6fda38586f73
Author:    asaha
Date:      2015-03-16 11:22 -0700
URL:       http://hg.openjdk.java.net/aarch64-port/jdk8/nashorn/rev/6fda38586f73

Added tag jdk8u45-b12 for changeset 9b9fee0f99cd

! .hgtags

Changeset: d5477c6d1678
Author:    asaha
Date:      2015-03-17 11:25 -0700
URL:       http://hg.openjdk.java.net/aarch64-port/jdk8/nashorn/rev/d5477c6d1678

Added tag jdk8u45-b13 for changeset 6fda38586f73

! .hgtags

Changeset: c64a4a81f6e6
Author:    enevill
Date:      2015-04-16 11:37 +0100
URL:       http://hg.openjdk.java.net/aarch64-port/jdk8/nashorn/rev/c64a4a81f6e6

Merge up to jdk8u45-b14

! .hgtags


From aph at redhat.com  Fri Apr 17 09:15:06 2015
From: aph at redhat.com (Andrew Haley)
Date: Fri, 17 Apr 2015 10:15:06 +0100
Subject: [aarch64-port-dev ] Proposed patch for C2 volatile generation
 (resent)
In-Reply-To: <552E93A0.7040705@redhat.com>
References: <55158471.4050009@redhat.com>	<5515916D.9010703@redhat.com>		<551912F2.4020204@redhat.com>	<551ACD21.4070608@redhat.com>		<551BFC2D.8080601@redhat.com>	<551C1295.2040809@redhat.com>	
	<552D360B.5080902@redhat.com>	<1429090620.7465.13.camel@mylittlepony.linaroharston>	<552E7AEA.3060907@redhat.com>
	<552E7B56.7030200@redhat.com>	<552E7D91.4050808@redhat.com>
	<552E7E09.5080509@redhat.com> <552E93A0.7040705@redhat.com>
Message-ID: <5530CF1A.3000208@redhat.com>

OK, we're good to go.  I've got 100% on jcstress.

Please prepare a submission for hotspot-dev.  It has to be clear
but brief, please!

Thanks,
Andrew.

From adinn at redhat.com  Fri Apr 17 09:35:14 2015
From: adinn at redhat.com (Andrew Dinn)
Date: Fri, 17 Apr 2015 10:35:14 +0100
Subject: [aarch64-port-dev ] RFR: 8076488: AARCH64: jdk9 fails to build
	from source
In-Reply-To: <551C300D.2090005@oracle.com>
References: <1427905684.1631.12.camel@mylittlepony.linaroharston>
	<551C300D.2090005@oracle.com>
Message-ID: <5530D3D2.5090505@redhat.com>

On 01/04/15 18:51, Vladimir Kozlov wrote:
> Looks good to me.

As a 2nd review***, yes this patch is good. Is that enough for it to be
pushed to jdk9?

***n.b. I am not a JDK9 committer or reviewer but this is AArch64 only
and I /am/ an aarch64-port committer/reviewer.

regards,


Andrew Dinn
-----------
Senior Principal Software Engineer
Red Hat UK Ltd
Registered in UK and Wales under Company Registration No. 3798903
Directors: Michael Cunningham (USA), Matt Parson (USA), Charlie Peters
(USA), Michael O'Neill (Ireland)


From roland.westrelin at oracle.com  Fri Apr 17 09:39:17 2015
From: roland.westrelin at oracle.com (Roland Westrelin)
Date: Fri, 17 Apr 2015 11:39:17 +0200
Subject: [aarch64-port-dev ] RFR: 8076488: AARCH64: jdk9 fails to build
	from source
In-Reply-To: <5530D3D2.5090505@redhat.com>
References: <1427905684.1631.12.camel@mylittlepony.linaroharston>
	<551C300D.2090005@oracle.com> <5530D3D2.5090505@redhat.com>
Message-ID: <183BF40D-554A-4318-8C5D-6070CBEF65FF@oracle.com>

>> Looks good to me.
> 
> As a 2nd review***, yes this patch is good. Is that enough for it to be
> pushed to jdk9?
> 
> ***n.b. I am not a JDK9 committer or reviewer but this is AArch64 only
> and I /am/ an aarch64-port committer/reviewer.

In case another review helps: that looks good to me. 

Roland.

From aph at redhat.com  Fri Apr 17 09:40:17 2015
From: aph at redhat.com (Andrew Haley)
Date: Fri, 17 Apr 2015 10:40:17 +0100
Subject: [aarch64-port-dev ] RFR: 8076488: AARCH64: jdk9 fails to build
	from source
In-Reply-To: <183BF40D-554A-4318-8C5D-6070CBEF65FF@oracle.com>
References: <1427905684.1631.12.camel@mylittlepony.linaroharston>	<551C300D.2090005@oracle.com>
	<5530D3D2.5090505@redhat.com>
	<183BF40D-554A-4318-8C5D-6070CBEF65FF@oracle.com>
Message-ID: <5530D501.1010004@redhat.com>

On 04/17/2015 10:39 AM, Roland Westrelin wrote:
>>> Looks good to me.
>>
>> As a 2nd review***, yes this patch is good. Is that enough for it to be
>> pushed to jdk9?
>>
>> ***n.b. I am not a JDK9 committer or reviewer but this is AArch64 only
>> and I /am/ an aarch64-port committer/reviewer.
> 
> In case another review helps: that looks good to me. 

OK, I'll push it.

Andrew.



From aph at redhat.com  Fri Apr 17 09:43:03 2015
From: aph at redhat.com (Andrew Haley)
Date: Fri, 17 Apr 2015 10:43:03 +0100
Subject: [aarch64-port-dev ] RFR: 8076488: AARCH64: jdk9 fails to build
	from source
In-Reply-To: <5530D501.1010004@redhat.com>
References: <1427905684.1631.12.camel@mylittlepony.linaroharston>	<551C300D.2090005@oracle.com>
	<5530D3D2.5090505@redhat.com>
	<183BF40D-554A-4318-8C5D-6070CBEF65FF@oracle.com>
	<5530D501.1010004@redhat.com>
Message-ID: <5530D5A7.90105@redhat.com>

On 04/17/2015 10:40 AM, Andrew Haley wrote:
> On 04/17/2015 10:39 AM, Roland Westrelin wrote:
>>>> Looks good to me.
>>>
>>> As a 2nd review***, yes this patch is good. Is that enough for it to be
>>> pushed to jdk9?
>>>
>>> ***n.b. I am not a JDK9 committer or reviewer but this is AArch64 only
>>> and I /am/ an aarch64-port committer/reviewer.
>>
>> In case another review helps: that looks good to me. 
> 
> OK, I'll push it.

Ah, no I won't.  My patch already fixed this, and (IMO) in a much better
way.  This patch is already in jprt, and will emerge soon, I hope.

diff -r 9c916db4bf3b -r 6463e57d9761 src/cpu/aarch64/vm/interp_masm_aarch64.hpp
--- a/src/cpu/aarch64/vm/interp_masm_aarch64.hpp        Thu Apr 09 17:38:28 2015 -0700
+++ b/src/cpu/aarch64/vm/interp_masm_aarch64.hpp        Tue Apr 14 11:43:18 2015 +0100
@@ -1,6 +1,6 @@
 /*
  * Copyright (c) 2003, 2011, Oracle and/or its affiliates. All rights reserved.
- * Copyright (c) 2014, Red Hat Inc. All rights reserved.
+ * Copyright (c) 2014, 2015, Red Hat Inc. All rights reserved.
  * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
  *
  * This code is free software; you can redistribute it and/or modify it
@@ -40,6 +40,8 @@

  protected:
   // Interpreter specific version of call_VM_base
+  using MacroAssembler::call_VM_leaf_base;
+
   virtual void call_VM_leaf_base(address entry_point,
                                  int number_of_arguments);

Andrew.



From vladimir.kozlov at oracle.com  Fri Apr 17 16:50:19 2015
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Fri, 17 Apr 2015 09:50:19 -0700
Subject: [aarch64-port-dev ] RFR: 8076488: AARCH64: jdk9 fails to build
	from source
In-Reply-To: <5530D5A7.90105@redhat.com>
References: <1427905684.1631.12.camel@mylittlepony.linaroharston>	<551C300D.2090005@oracle.com>
	<5530D3D2.5090505@redhat.com>
	<183BF40D-554A-4318-8C5D-6070CBEF65FF@oracle.com>
	<5530D501.1010004@redhat.com> <5530D5A7.90105@redhat.com>
Message-ID: <553139CB.8090303@oracle.com>

 > Ah, no I won't.  My patch already fixed this, and (IMO) in a much better
 > way.  This patch is already in jprt, and will emerge soon, I hope.

Andrew, do you mean the change pushed few days ago as part of 8077615 changes?:

http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/2a6c4bd248cf

Thanks,
Vladimir

On 4/17/15 2:43 AM, Andrew Haley wrote:
> On 04/17/2015 10:40 AM, Andrew Haley wrote:
>> On 04/17/2015 10:39 AM, Roland Westrelin wrote:
>>>>> Looks good to me.
>>>>
>>>> As a 2nd review***, yes this patch is good. Is that enough for it to be
>>>> pushed to jdk9?
>>>>
>>>> ***n.b. I am not a JDK9 committer or reviewer but this is AArch64 only
>>>> and I /am/ an aarch64-port committer/reviewer.
>>>
>>> In case another review helps: that looks good to me.
>>
>> OK, I'll push it.
>
> Ah, no I won't.  My patch already fixed this, and (IMO) in a much better
> way.  This patch is already in jprt, and will emerge soon, I hope.
>
> diff -r 9c916db4bf3b -r 6463e57d9761 src/cpu/aarch64/vm/interp_masm_aarch64.hpp
> --- a/src/cpu/aarch64/vm/interp_masm_aarch64.hpp        Thu Apr 09 17:38:28 2015 -0700
> +++ b/src/cpu/aarch64/vm/interp_masm_aarch64.hpp        Tue Apr 14 11:43:18 2015 +0100
> @@ -1,6 +1,6 @@
>   /*
>    * Copyright (c) 2003, 2011, Oracle and/or its affiliates. All rights reserved.
> - * Copyright (c) 2014, Red Hat Inc. All rights reserved.
> + * Copyright (c) 2014, 2015, Red Hat Inc. All rights reserved.
>    * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
>    *
>    * This code is free software; you can redistribute it and/or modify it
> @@ -40,6 +40,8 @@
>
>    protected:
>     // Interpreter specific version of call_VM_base
> +  using MacroAssembler::call_VM_leaf_base;
> +
>     virtual void call_VM_leaf_base(address entry_point,
>                                    int number_of_arguments);
>
> Andrew.
>
>

From aph at redhat.com  Fri Apr 17 17:08:50 2015
From: aph at redhat.com (Andrew Haley)
Date: Fri, 17 Apr 2015 18:08:50 +0100
Subject: [aarch64-port-dev ] RFR: 8076488: AARCH64: jdk9 fails to build
	from source
In-Reply-To: <553139CB.8090303@oracle.com>
References: <1427905684.1631.12.camel@mylittlepony.linaroharston>	<551C300D.2090005@oracle.com>
	<5530D3D2.5090505@redhat.com>
	<183BF40D-554A-4318-8C5D-6070CBEF65FF@oracle.com>
	<5530D501.1010004@redhat.com> <5530D5A7.90105@redhat.com>
	<553139CB.8090303@oracle.com>
Message-ID: <55313E22.1000800@redhat.com>

On 04/17/2015 05:50 PM, Vladimir Kozlov wrote:
>  > Ah, no I won't.  My patch already fixed this, and (IMO) in a much better
>  > way.  This patch is already in jprt, and will emerge soon, I hope.
> 
> Andrew, do you mean the change pushed few days ago as part of 8077615 changes?:
> 
> http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/2a6c4bd248cf

Yes.

Andrew.



From edward.nevill at gmail.com  Fri Apr 17 18:25:28 2015
From: edward.nevill at gmail.com (Edward Nevill)
Date: Fri, 17 Apr 2015 19:25:28 +0100
Subject: [aarch64-port-dev ] JTREG,
 SPECjbb2013 and Hadoop/Terasort results for OpenJDK 8 on AArch64
Message-ID: <1429295128.21937.2.camel@mint>

This is a summary of the JTREG test results
===========================================

The build and test results are cycled every 10 days.

For detailed information on the test output please refer to:

  http://openjdk.linaro.org/openjdk8-jtreg-nightly-tests/summary/2015/107/summary.html

-------------------------------------------------------------------------------
client-release/hotspot
-------------------------------------------------------------------------------
Build 0: aarch64/2014/nov/28 pass: 584; fail: 53; error: 1
Build 1: aarch64/2014/dec/05 pass: 584; fail: 53; error: 1
Build 2: aarch64/2014/dec/12 pass: 586; fail: 51; error: 1
Build 3: aarch64/2014/dec/16 pass: 585; fail: 52; error: 1
Build 4: aarch64/2015/jan/08 pass: 584; fail: 53; error: 1
Build 5: aarch64/2015/jan/09 pass: 584; fail: 53; error: 1
Build 6: aarch64/2015/feb/05 pass: 605; fail: 55; error: 2
Build 7: aarch64/2015/feb/13 pass: 605; fail: 55; error: 2
Build 8: aarch64/2015/mar/06 pass: 606; fail: 54; error: 2
Build 9: aarch64/2015/apr/17 pass: 605; fail: 55; error: 2

-------------------------------------------------------------------------------
client-release/jdk
-------------------------------------------------------------------------------
Build 0: aarch64/2014/nov/28 pass: 5,324; fail: 216; error: 20
Build 1: aarch64/2014/dec/05 pass: 5,323; fail: 217; error: 20
Build 2: aarch64/2014/dec/12 pass: 5,334; fail: 206; error: 20
Build 3: aarch64/2014/dec/16 pass: 5,332; fail: 205; error: 23
Build 4: aarch64/2015/jan/08 pass: 5,327; fail: 211; error: 22
Build 5: aarch64/2015/jan/09 pass: 5,330; fail: 212; error: 18
Build 6: aarch64/2015/feb/05 pass: 5,347; fail: 222; error: 19
Build 7: aarch64/2015/feb/13 pass: 5,357; fail: 215; error: 16
Build 8: aarch64/2015/mar/06 pass: 5,354; fail: 216; error: 18
Build 9: aarch64/2015/apr/17 pass: 5,359; fail: 208; error: 24

-------------------------------------------------------------------------------
client-release/langtools
-------------------------------------------------------------------------------
Build 0: aarch64/2014/nov/28 pass: 3,034; error: 14
Build 1: aarch64/2014/dec/05 pass: 3,037; error: 11
Build 2: aarch64/2014/dec/12 pass: 3,036; error: 12
Build 3: aarch64/2014/dec/16 pass: 3,039; error: 9
Build 4: aarch64/2015/jan/08 pass: 3,038; error: 10
Build 5: aarch64/2015/jan/09 pass: 3,037; error: 11
Build 6: aarch64/2015/feb/05 pass: 3,059; error: 14
Build 7: aarch64/2015/feb/13 pass: 3,064; error: 9
Build 8: aarch64/2015/mar/06 pass: 3,063; error: 10
Build 9: aarch64/2015/apr/17 pass: 3,063; error: 10

-------------------------------------------------------------------------------
server-release/hotspot
-------------------------------------------------------------------------------
Build 0: aarch64/2014/nov/28 pass: 601; fail: 36; error: 1
Build 1: aarch64/2014/dec/05 pass: 599; fail: 38; error: 1
Build 2: aarch64/2014/dec/12 pass: 599; fail: 38; error: 1
Build 3: aarch64/2014/dec/16 pass: 602; fail: 35; error: 1
Build 4: aarch64/2015/jan/08 pass: 599; fail: 38; error: 1
Build 5: aarch64/2015/jan/09 pass: 599; fail: 38; error: 1
Build 6: aarch64/2015/feb/05 pass: 624; fail: 32; error: 6
Build 7: aarch64/2015/feb/13 pass: 626; fail: 32; error: 4
Build 8: aarch64/2015/mar/06 pass: 626; fail: 32; error: 4
Build 9: aarch64/2015/apr/17 pass: 625; fail: 32; error: 5

-------------------------------------------------------------------------------
server-release/jdk
-------------------------------------------------------------------------------
Build 0: aarch64/2014/nov/28 pass: 5,116; fail: 424; error: 20
Build 1: aarch64/2014/dec/05 pass: 5,337; fail: 198; error: 25
Build 2: aarch64/2014/dec/12 pass: 5,318; fail: 218; error: 24
Build 3: aarch64/2014/dec/16 pass: 5,331; fail: 205; error: 24
Build 4: aarch64/2015/jan/08 pass: 5,330; fail: 202; error: 28
Build 5: aarch64/2015/jan/09 pass: 5,339; fail: 201; error: 20
Build 6: aarch64/2015/feb/05 pass: 5,349; fail: 209; error: 30
Build 7: aarch64/2015/feb/13 pass: 5,344; fail: 210; error: 34
Build 8: aarch64/2015/mar/06 pass: 5,348; fail: 207; error: 33
Build 9: aarch64/2015/apr/17 pass: 5,354; fail: 208; error: 29

-------------------------------------------------------------------------------
server-release/langtools
-------------------------------------------------------------------------------
Build 0: aarch64/2014/nov/28 pass: 3,039; error: 9
Build 1: aarch64/2014/dec/05 pass: 3,041; error: 7
Build 2: aarch64/2014/dec/12 pass: 3,040; error: 8
Build 3: aarch64/2014/dec/16 pass: 3,036; error: 12
Build 4: aarch64/2015/jan/08 pass: 3,038; fail: 1; error: 9
Build 5: aarch64/2015/jan/09 pass: 3,038; error: 10
Build 6: aarch64/2015/feb/05 pass: 3,062; error: 11
Build 7: aarch64/2015/feb/13 pass: 3,064; error: 9
Build 8: aarch64/2015/mar/06 pass: 3,065; error: 8
Build 9: aarch64/2015/apr/17 pass: 3,063; error: 10

Previous results can be found here:

  http://openjdk.linaro.org/openjdk8-jtreg-nightly-tests/index.html


SPECjbb2013 composite regression test completed
===============================================

This test measures the relative performance of the server
compiler running the SPECjbb2013 composite tests and compares
the performance against the baseline performance of the server
compiler taken on 2014-04-01.

In accordance with [1], the SPECjbb2013 tests are run on a system
which is not production ready and does not meet all the
requirements for publishing compliant results. The numbers below
shall be treated as non-compliant (nc) and are for experimental
purposes only.

Relative performance: Server max-jOPS (nc): 1.26x
Relative performance: Server critical-jOPS (nc): 1.55x

Details of the test setup and historical results may be found here:

    http://openjdk.linaro.org/SPECjbb2013-1.00-results/

[1] http://www.spec.org/fairuse.html#Academic

Regression test Hadoop-Terasort completed
=========================================

This test measures the performance of the server and client compilers
running Hadoop sorting a 1GB file using Terasort and compares
the performance against the baseline performance of the Zero interpreter
and against the baseline performance of the client and server compilers
on 2014-04-01.

Relative performance: Zero: 1.0, Client: 48.84, Server: 81.59

Client 48.84 / Client 2014-04-01 (43.00): 1.14x
Server 81.59 / Server 2014-04-01 (71.00): 1.15x

Details of the test setup and historical results may be found here:

    http://openjdk.linaro.org/hadoop-terasort-benchmark-results/

This is a summary of the jcstress test results
==============================================

The build and test results are cycled every 10 days.

2014-11-28 pass rate: 11550/11550, results: http://openjdk.linaro.org/jcstress-nightly-runs/2014/332/results/
2014-12-05 pass rate: 11550/11550, results: http://openjdk.linaro.org/jcstress-nightly-runs/2014/339/results/
2014-12-12 pass rate: 11550/11550, results: http://openjdk.linaro.org/jcstress-nightly-runs/2014/346/results/
2014-12-16 pass rate: 11550/11550, results: http://openjdk.linaro.org/jcstress-nightly-runs/2014/350/results/
2015-01-08 pass rate: 11550/11550, results: http://openjdk.linaro.org/jcstress-nightly-runs/2015/008/results/
2015-01-09 pass rate: 11550/11550, results: http://openjdk.linaro.org/jcstress-nightly-runs/2015/009/results/
2015-02-05 pass rate: 11551/11551, results: http://openjdk.linaro.org/jcstress-nightly-runs/2015/036/results/
2015-02-13 pass rate: 11551/11551, results: http://openjdk.linaro.org/jcstress-nightly-runs/2015/044/results/
2015-03-06 pass rate: 11551/11551, results: http://openjdk.linaro.org/jcstress-nightly-runs/2015/065/results/
2015-04-17 pass rate: 11555/11555, results: http://openjdk.linaro.org/jcstress-nightly-runs/2015/107/results/

For detailed information on the test output please refer to:

  http://openjdk.linaro.org/jcstress-nightly-runs/



From adinn at redhat.com  Mon Apr 20 07:39:18 2015
From: adinn at redhat.com (Andrew Dinn)
Date: Mon, 20 Apr 2015 08:39:18 +0100
Subject: [aarch64-port-dev ] vectorisation experiment
In-Reply-To: <1429175127.4866.25.camel@mylittlepony.linaroharston>
References: <1429175127.4866.25.camel@mylittlepony.linaroharston>
Message-ID: <5534AD26.7070306@redhat.com>

Hi Ed,

On 16/04/15 10:05, Edward Nevill wrote:
> I have been experimenting with adding vectorisation to aarch64 jdk9. 
> ...
> 
> but this is not what I need. This is a single register 256 bits long,
> whereas I need a sort of virtual register which uses 4 physical
> registers.
> 
> Thanks for any help, the documentation on this is not great! Ed.

Just to let you know I have not been ignoring this -- rather I have no
idea how to get adlc and the register allocator to do what you want.

regards,


Andrew Dinn
-----------

From adinn at redhat.com  Mon Apr 20 09:03:40 2015
From: adinn at redhat.com (Andrew Dinn)
Date: Mon, 20 Apr 2015 10:03:40 +0100
Subject: [aarch64-port-dev ] RFR: AArch64 -- patch to make volatile reads
	and stores use ldar/stlr
Message-ID: <5534C0EC.1070005@redhat.com>

The following webrev is submitted for review (n.b. I am not an OpenJDK
committer so the patch does not yet have an associated JIRA).

  http://cr.openjdk.java.net/~adinn/volatilefix/webrev.00

The patch modifies the AArch64 ad file rules to implement volatile loads
and stores using load acquire (ldar<x>) and store release (stlr<x>)
instructions. The memory barriers normally associated with volatile
loads and stores are elided in these cases.

  http://cr.openjdk.java.net/~adinn/volatilefix/webrev.00/

Just to summarise what is happening here:

The patch employs rule predicates to detect specific sequences of membar
and memory nodes which are unique to volatile loads and stores.

  Two predicates control generation of normal vs acquiring loads and
normal vs releasing stores.

  Three predicates control generation vs elision of memory barriers.

The comments documenting these predicates provides a full explanation of
which node sequences may arise as a result of a volatile load or store,
how they can be detected and what alternative instruction encodings may
be generated.

The patch has successfully passed jcstress on two different AArch64
platforms. It has also successfully run javac and netbeans.

regards,


Andrew Dinn
-----------
Senior Principal Software Engineer
Red Hat UK Ltd
Registered in UK and Wales under Company Registration No. 3798903
Directors: Michael Cunningham (USA), Matt Parson (USA), Charlie Peters
(USA), Michael O'Neill (Ireland)

From edward.nevill at linaro.org  Tue Apr 21 09:16:37 2015
From: edward.nevill at linaro.org (Edward Nevill)
Date: Tue, 21 Apr 2015 10:16:37 +0100
Subject: [aarch64-port-dev ] aarch64: jdk9: 8078245: fails to build from
	source
Message-ID: <1429607797.4116.11.camel@mylittlepony.linaroharston>

Hi,

The current jdk9 tip fails to build from source on aarch64 with the following error message 

/home/ed/build/1504/dev/build/linux-aarch64-normal-server-release/support/native/java.desktop/libsplashscreen/pngrutil.o: In function `png_init_filter_functions': 
/home/ed/build/1504/dev/jdk/src/java.desktop/share/native/libsplashscreen/libpng/pngrutil.c:3947: undefined reference to `png_init_filter_functions_neon' 
collect2: error: ld returned 1 exit status 

The following webrev gets it building again.

http://cr.openjdk.java.net/~enevill/8078245/webrev.00/

Please review and if approved push. See comments below.

Thanks,
Ed.


This was introduced at changeset 11769

changeset:   11769:cb75299d5933
user:        azvegint
date:        Mon Jan 19 20:02:31 2015 +0300
files:       src/java.desktop/share/native/libsplashscreen/libpng/CHANGES src/java.desktop/share/native/libsplashscreen/libpng/LICENSE src/java.desktop/share/native/libsplashscreen/libpng/README src/java.desktop/share/native/libsplashscreen/libpng/png.c src/java.desktop/share/native/libsplashscreen/libpng/png.h src/java.desktop/share/native/libsplashscreen/libpng/pngconf.h src/java.desktop/share/native/libsplashscreen/libpng/pngdebug.h src/java.desktop/share/native/libsplashscreen/libpng/pngerror.c src/java.desktop/share/native/libsplashscreen/libpng/pngget.c src/java.desktop/share/native/libsplashscreen/libpng/pnginfo.h src/java.desktop/share/native/libsplashscreen/libpng/pnglibconf.h src/java.desktop/share/native/libsplashscreen/libpng/pngmem.c src/java.desktop/share/native/libsplashscreen/libpng/pngpread.c src/java.desktop/share/native/libsplashscreen/libpng/pngpriv.h src/java.desktop/share/native/libsplashscreen/libpng/pngread.c src/java.desktop/share/native/libsplashscreen/libpng/pngrio.c src/java.desktop/share/native/libsplashscreen/libpng/pngrtran.c src/java.desktop/share/native/libsplashscreen/libpng/pngrutil.c src/java.desktop/share/native/libsplashscreen/libpng/pngset.c src/java.desktop/share/native/libsplashscreen/libpng/pngstruct.h src/java.desktop/share/native/libsplashscreen/libpng/pngtest.c src/java.desktop/share/native/libsplashscreen/libpng/pngtrans.c src/java.desktop/share/native/libsplashscreen/libpng/pngwio.c src/java.desktop/share/native/libsplashscreen/libpng/pngwrite.c src/java.desktop/share/native/libsplashscreen/libpng/pngwtran.c src/java.desktop/share/native/libsplashscreen/libpng/pngwutil.c
description:
8069198: Upgrade image library
Reviewed-by: ahgross, bae, mschoene, serb

This changeset seems to introduce some ARM Neon optimisations, however I cannot seem to access the associated bug report JDK-8069198 as it seems I do not have suitable privileges to read the report.

The problem is that it is also attempting to build this code for AARCH64 resulting in the above undefined symbol.

The above webrev fixes this by ensuring that it only attempts to compile this code if defined(__arm__)



From edward.nevill at linaro.org  Tue Apr 21 09:20:38 2015
From: edward.nevill at linaro.org (Edward Nevill)
Date: Tue, 21 Apr 2015 10:20:38 +0100
Subject: [aarch64-port-dev ] RFR: 8075930: AARCH64: Use FP Register in C2
In-Reply-To: <5527E1B9.5030109@oracle.com>
References: <1427288528.7353.25.camel@mylittlepony.linaroharston>
	<5512B817.3080802@oracle.com>
	<1428571873.26527.24.camel@mylittlepony.linaroharston>
	<5526B7B1.7000702@oracle.com>
	<1428656099.13172.10.camel@mylittlepony.linaroharston>
	<5527E1B9.5030109@oracle.com>
Message-ID: <1429608038.4116.13.camel@mylittlepony.linaroharston>

Hi,

If everyone is happy with this patch could someone push it please,

Thanks,
Ed.

On Fri, 2015-04-10 at 07:44 -0700, Vladimir Kozlov wrote:
> Looks good.
> 
> Thanks,
> Vladimir
> 
> On 4/10/15 1:54 AM, Edward Nevill wrote:
> > Hi Vladimir,
> >
> > On Thu, 2015-04-09 at 10:32 -0700, Vladimir Kozlov wrote:
> >> Hi Edward,
> >>
> >> In frame() I think check !defined(COMPILER2) is useless because COMPILER2 is always defined in 64-bit Server Hotspot VM.
> >> Unless you have configuration without C2. I think it should be dynamic check after you find who generated this _cb.
> >> Can you explain what this code does (there is not comment):
> >
> > We do build without C2 as part of our testing. However, as Andrew Haley said, this is old debug code, so I propose simply removing it. Its usefulness is rather limited once fp can be allocated as a general purpose register.
> >
> >>
> >>     80 #ifndef PRODUCT
> >>     81   if (fp)
> >>     82     if (sp > fp || (fp - sp > 0x100000))
> >>     83       for(;;)
> >>     84         asm("nop");
> >>     85 #endif
> >
> > New webrev removing this code @
> >
> > http://cr.openjdk.java.net/~enevill/8075930/webrev.03/
> >
> > All the best,
> > Ed.
> >
> >



From aph at redhat.com  Tue Apr 21 10:20:21 2015
From: aph at redhat.com (Andrew Haley)
Date: Tue, 21 Apr 2015 11:20:21 +0100
Subject: [aarch64-port-dev ] RFR: 8075930: AARCH64: Use FP Register in C2
In-Reply-To: <1429608038.4116.13.camel@mylittlepony.linaroharston>
References: <1427288528.7353.25.camel@mylittlepony.linaroharston>	<5512B817.3080802@oracle.com>	<1428571873.26527.24.camel@mylittlepony.linaroharston>	<5526B7B1.7000702@oracle.com>	<1428656099.13172.10.camel@mylittlepony.linaroharston>	<5527E1B9.5030109@oracle.com>
	<1429608038.4116.13.camel@mylittlepony.linaroharston>
Message-ID: <55362465.2080805@redhat.com>

On 04/21/2015 10:20 AM, Edward Nevill wrote:
> If everyone is happy with this patch could someone push it please,

I'll do it.

Andrew.


From aph at redhat.com  Tue Apr 21 12:53:03 2015
From: aph at redhat.com (Andrew Haley)
Date: Tue, 21 Apr 2015 13:53:03 +0100
Subject: [aarch64-port-dev ] RFR: AArch64 -- patch to make volatile
	reads and stores use ldar/stlr
In-Reply-To: <5534C0EC.1070005@redhat.com>
References: <5534C0EC.1070005@redhat.com>
Message-ID: <5536482F.3020104@redhat.com>

On 04/20/2015 10:03 AM, Andrew Dinn wrote:
> The following webrev is submitted for review (n.b. I am not an OpenJDK
> committer so the patch does not yet have an associated JIRA).

The patch looks good to me.

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

Andrew.


From edward.nevill at gmail.com  Tue Apr 21 13:04:24 2015
From: edward.nevill at gmail.com (Edward Nevill)
Date: Tue, 21 Apr 2015 14:04:24 +0100
Subject: [aarch64-port-dev ] RFR: AArch64 -- patch to make volatile
 reads and stores use ldar/stlr
In-Reply-To: <5536482F.3020104@redhat.com>
References: <5534C0EC.1070005@redhat.com> <5536482F.3020104@redhat.com>
Message-ID: <1429621464.4116.19.camel@mylittlepony.linaroharston>

On Tue, 2015-04-21 at 13:53 +0100, Andrew Haley wrote:
> On 04/20/2015 10:03 AM, Andrew Dinn wrote:
> > The following webrev is submitted for review (n.b. I am not an OpenJDK
> > committer so the patch does not yet have an associated JIRA).
> 
> The patch looks good to me.
> 
> https://bugs.openjdk.java.net/browse/JDK-8078263
> 

+1 from me also. I have tested with jtreg hotspot and langtools and
there are no regressions.

All the best,
Ed.



From adinn at redhat.com  Tue Apr 21 13:43:04 2015
From: adinn at redhat.com (Andrew Dinn)
Date: Tue, 21 Apr 2015 14:43:04 +0100
Subject: [aarch64-port-dev ] RFR: AArch64 -- patch to make volatile
	reads and stores use ldar/stlr
In-Reply-To: <5536482F.3020104@redhat.com>
References: <5534C0EC.1070005@redhat.com> <5536482F.3020104@redhat.com>
Message-ID: <553653E8.4020301@redhat.com>

On 21/04/15 13:53, Andrew Haley wrote:
> On 04/20/2015 10:03 AM, Andrew Dinn wrote:
>> The following webrev is submitted for review (n.b. I am not an OpenJDK
>> committer so the patch does not yet have an associated JIRA).
> 
> The patch looks good to me.
> 
> https://bugs.openjdk.java.net/browse/JDK-8078263

A new webrev with the commit in standard format (listing JIRA#, sumamry
and reviewer) and placed at:

  http://cr.openjdk.java.net/~adinn/8078263/webrev.01/

regards,


Andrew Dinn
-----------


From aph at redhat.com  Tue Apr 21 15:11:04 2015
From: aph at redhat.com (Andrew Haley)
Date: Tue, 21 Apr 2015 16:11:04 +0100
Subject: [aarch64-port-dev ] RFR: 8075930: AARCH64: Use FP Register in C2
In-Reply-To: <1429608038.4116.13.camel@mylittlepony.linaroharston>
References: <1427288528.7353.25.camel@mylittlepony.linaroharston>	<5512B817.3080802@oracle.com>	<1428571873.26527.24.camel@mylittlepony.linaroharston>	<5526B7B1.7000702@oracle.com>	<1428656099.13172.10.camel@mylittlepony.linaroharston>	<5527E1B9.5030109@oracle.com>
	<1429608038.4116.13.camel@mylittlepony.linaroharston>
Message-ID: <55366888.2040409@redhat.com>

On 04/21/2015 10:20 AM, Edward Nevill wrote:

> If everyone is happy with this patch could someone push it please,

I'm a bit concerned about deoptimization.

Here is a call to uncommon_trap before your patch:

308   	strw  R0, [sp, #0]	# spill
30c + 	strw  R24, [sp, #4]	# spill
310   	call,static 0x000003ffa807f080 	// ==>  wrapper for: uncommon_trap(reason='unstable_if' action='reinterpret')
        # Pressure::poo @ bci:482  L[0]=_ L[1]=_ L[2]=_ L[3]=_ L[4]=_ L[5]=_ L[6]=_ L[7]=_ L[8]=_ L[9]=_ L[10]=_ L[11]=_ L[12]=_ L[13]=_ L[14]=_ L[15]=_ L[16]=_ L[17]=_ L[18]=_ L[19]=_ L[20]=_ L[21]=_ L[22]=_ L[23]=sp + #0 STK[0]=sp + #4

and after:

300   	movw  R29, R0	# shuffle
304 + 	strw  R25, [sp, #0]	# spill
308   	call,static 0x000003ffa807f080 	// ==>  wrapper for: uncommon_trap(reason='unstable_if' action='reinterpret')
        # Pressure::poo @ bci:482  L[0]=_ L[1]=_ L[2]=_ L[3]=_ L[4]=_ L[5]=_ L[6]=_ L[7]=_ L[8]=_ L[9]=_ L[10]=_ L[11]=_ L[12]=_ L[13]=_ L[14]=_ L[15]=_ L[16]=_ L[17]=_ L[18]=_ L[19]=_ L[20]=_ L[21]=_ L[22]=_ L[23]=R29 STK[0]=sp + #0

R29 (i.e. rfp) is marked Save-On-Entry.  It is the only allocatable
general-purpose register which is.  I'm a bit worried that
deoptimization might not restore this register correctly if it hasn't
been spilled.  Maybe we should mark R29 as SOC.

On the other hand, if it does work it will be a nice performance
improvement: there will be one less spill to the stack at most calls.
But AFAIK deoptimization expects everything to be saved in the stack
frame.

Vladimir, is that right?

Andrew.

From aph at redhat.com  Tue Apr 21 15:15:47 2015
From: aph at redhat.com (Andrew Haley)
Date: Tue, 21 Apr 2015 16:15:47 +0100
Subject: [aarch64-port-dev ] RFR: 8075930: AARCH64: Use FP Register in C2
In-Reply-To: <55366888.2040409@redhat.com>
References: <1427288528.7353.25.camel@mylittlepony.linaroharston>	<5512B817.3080802@oracle.com>	<1428571873.26527.24.camel@mylittlepony.linaroharston>	<5526B7B1.7000702@oracle.com>	<1428656099.13172.10.camel@mylittlepony.linaroharston>	<5527E1B9.5030109@oracle.com>	<1429608038.4116.13.camel@mylittlepony.linaroharston>
	<55366888.2040409@redhat.com>
Message-ID: <553669A3.8070205@redhat.com>

On 04/21/2015 04:11 PM, Andrew Haley wrote:
> R29 (i.e. rfp) is marked Save-On-Entry.  It is the only allocatable
> general-purpose register which is.  I'm a bit worried that
> deoptimization might not restore this register correctly if it hasn't
> been spilled.  Maybe we should mark R29 as SOC.

On the gripping hand, x86_64 marks RBP, RSI and RDI as SOE registers.
So I think I'm worrying about nothing.

Andrew.


From vladimir.kozlov at oracle.com  Tue Apr 21 17:03:33 2015
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Tue, 21 Apr 2015 10:03:33 -0700
Subject: [aarch64-port-dev ] RFR: AArch64 -- patch to make volatile
	reads and stores use ldar/stlr
In-Reply-To: <553653E8.4020301@redhat.com>
References: <5534C0EC.1070005@redhat.com> <5536482F.3020104@redhat.com>
	<553653E8.4020301@redhat.com>
Message-ID: <553682E5.9000001@oracle.com>

Would it help if we add a new flag to NodeFlags to indicate volatile memory node?

Vladimir

On 4/21/15 6:43 AM, Andrew Dinn wrote:
> On 21/04/15 13:53, Andrew Haley wrote:
>> On 04/20/2015 10:03 AM, Andrew Dinn wrote:
>>> The following webrev is submitted for review (n.b. I am not an OpenJDK
>>> committer so the patch does not yet have an associated JIRA).
>>
>> The patch looks good to me.
>>
>> https://bugs.openjdk.java.net/browse/JDK-8078263
>
> A new webrev with the commit in standard format (listing JIRA#, sumamry
> and reviewer) and placed at:
>
>    http://cr.openjdk.java.net/~adinn/8078263/webrev.01/
>
> regards,
>
>
> Andrew Dinn
> -----------
>

From aleksey.shipilev at oracle.com  Tue Apr 21 18:18:22 2015
From: aleksey.shipilev at oracle.com (Aleksey Shipilev)
Date: Tue, 21 Apr 2015 21:18:22 +0300
Subject: [aarch64-port-dev ] RFR: AArch64 -- patch to make volatile
	reads and stores use ldar/stlr
In-Reply-To: <553682E5.9000001@oracle.com>
References: <5534C0EC.1070005@redhat.com>
	<5536482F.3020104@redhat.com>	<553653E8.4020301@redhat.com>
	<553682E5.9000001@oracle.com>
Message-ID: <5536946E.6020809@oracle.com>

There is also a pending idea for x86: try to replace volatile stores
with "xchg", instead of "mov + lock addl". It would be nice to make sure
the way AArch64 does the replacement would help the future x86 code.

Thanks,
-Aleksey

On 21.04.2015 20:03, Vladimir Kozlov wrote:
> Would it help if we add a new flag to NodeFlags to indicate volatile
> memory node?
> 
> Vladimir
> 
> On 4/21/15 6:43 AM, Andrew Dinn wrote:
>> On 21/04/15 13:53, Andrew Haley wrote:
>>> On 04/20/2015 10:03 AM, Andrew Dinn wrote:
>>>> The following webrev is submitted for review (n.b. I am not an OpenJDK
>>>> committer so the patch does not yet have an associated JIRA).
>>>
>>> The patch looks good to me.
>>>
>>> https://bugs.openjdk.java.net/browse/JDK-8078263
>>
>> A new webrev with the commit in standard format (listing JIRA#, sumamry
>> and reviewer) and placed at:
>>
>>    http://cr.openjdk.java.net/~adinn/8078263/webrev.01/
>>
>> regards,
>>
>>
>> Andrew Dinn
>> -----------
>>



From dean.long at oracle.com  Tue Apr 21 19:17:48 2015
From: dean.long at oracle.com (Dean Long)
Date: Tue, 21 Apr 2015 12:17:48 -0700
Subject: [aarch64-port-dev ] RFR: 8075930: AARCH64: Use FP Register in C2
In-Reply-To: <553669A3.8070205@redhat.com>
References: <1427288528.7353.25.camel@mylittlepony.linaroharston>	<5512B817.3080802@oracle.com>	<1428571873.26527.24.camel@mylittlepony.linaroharston>	<5526B7B1.7000702@oracle.com>	<1428656099.13172.10.camel@mylittlepony.linaroharston>	<5527E1B9.5030109@oracle.com>	<1429608038.4116.13.camel@mylittlepony.linaroharston>	<55366888.2040409@redhat.com>
	<553669A3.8070205@redhat.com>
Message-ID: <5536A25C.7060402@oracle.com>

On 4/21/2015 8:15 AM, Andrew Haley wrote:
> On 04/21/2015 04:11 PM, Andrew Haley wrote:
>> R29 (i.e. rfp) is marked Save-On-Entry.  It is the only allocatable
>> general-purpose register which is.  I'm a bit worried that
>> deoptimization might not restore this register correctly if it hasn't
>> been spilled.  Maybe we should mark R29 as SOC.
> On the gripping hand, x86_64 marks RBP, RSI and RDI as SOE registers.
> So I think I'm worrying about nothing.
>
> Andrew.
>

Does frame::update_map_with_saved_link() take care of R29 if it hasn't 
been explicitly spilled?  If so, R29 could probably remain marked as NS 
like before.

dl

From adinn at redhat.com  Wed Apr 22 09:00:08 2015
From: adinn at redhat.com (Andrew Dinn)
Date: Wed, 22 Apr 2015 10:00:08 +0100
Subject: [aarch64-port-dev ] RFR: AArch64 -- patch to make volatile
	reads and stores use ldar/stlr
In-Reply-To: <553682E5.9000001@oracle.com>
References: <5534C0EC.1070005@redhat.com> <5536482F.3020104@redhat.com>
	<553653E8.4020301@redhat.com> <553682E5.9000001@oracle.com>
Message-ID: <55376318.7070604@redhat.com>

Hi Vladimir,

Thanks for responding.

On 21/04/15 18:03, Vladimir Kozlov wrote:
> Would it help if we add a new flag to NodeFlags to indicate volatile
> memory node?

Yes, I think this would provide some benefit although I don't know if it
will justify cost of implementing and testing the necessary shared code
changes given that the benefit is only partial. Even with such a flag we
would still need to do some of the work that this patch does. Also, the
flag would not help with a the next optimization we are planning
(removing unnecessary barriers from CAS sequences).

Your suggestion will /simplify/ the predicates for LoadX/StoreX but will
not make much difference to execution time. The current predicates for
these nodes, needs_acquiring_load() and needs_releasing_store(), check
immediately whether a LoadX is acquiring or a StoreX is releasing. So,
we have a quick filter for the /common path/ case where we simply
generate an ldr<x> or stlr<x> (I assume volatile ops are relatively rare).

However, we cannot rely solely on these existing flags as they are
sometimes set in other (non-volatile) cases. Currently, if the acquiring
or releasing flag is set the predicates go on to investigate the nodes
around the LoadX/StoreX looking for a specific configuration of
MemBar_XXX nodes. Adding the volatile flag would remove the need to do
this extra work in the /uncommon/ case.

Unfortunately, the other half of the patch involves eliding generation
of dmb instructions for the MemBar_XXX nodes associated with the a LoadX
or StoreX. Three other predicates are used for this purpose,
unnecesary_membar_acquire, unnecesary_membar_release and
unnecesary_membar_volatile. They search the ideal graph around the
membar to see whether it belongs to a signature sequence containing an
acquiring load or releasing store.

The check involves i) finding a related LoadX or StoreX, ii) checking it
is acquiring or releasing and ii) ensuring it is either tailed or
bracketed by a node group with a 'signature' shape which includes the
MemBar we started from. A volatile flag would not really speed up this
check and would not do much to simplify it.

The current predicates test for very specific signature configurations.
So, in cases where the MemBar node is /not/ part of a signature volatile
sequence they detect this very rapidly. In the common case the predicate
immediately fails to find the required sort of parent/child node in the
tree surrounding the initial MemBar (i.e. one which is not a
LoadX/StoreX, Proj or MemBar). If we do arrive at a LoadX/StoreX in the
node tree we could, perhaps, check the volatile flag and short-circuit
any further graph traversal but the bulk of the work involves traversing
from the initial MemBar to the LoadX/StoreX.

n.b. I say perhaps because I am not yet certain that we just test the
volatile flag. I don't know for sure that we could not arrive at the
memory node from a MemBar which was not part of the signature sequence
(I /am/ very confident that the current checks correctly identify
volatile node sequences and only those sequences).

Could we punt this question of providing the volatile flag, considering
it as a potential follow-up improvement? I'd prefer to get this
AArch64-only change in as is -- or, at least, with some tweaking --
before going on to consider something which requires changes to shared code.

Also, I mentioned the CAS case above because that is what I am looking
at next and it extends the technique used in the current patch.
Currently CAS operations translate to something which looks like this

  dmb
  ...
retry:
  ldaxr
  ...
  stlxr
  cbz retry
  ...
  dmb

The ldaxr/stlxr pair are generated in response to a CompareAndSwapX node
and the dmb instructions arise from MemBar nodes. For a CAS AArch64 can
safely elide the dmb instructions. So, the next improvement will be to
extend the unnecessary_membar_xxx predicates to elide the dmb generation
when a suitable configuration of MemBar_XXX and CompareAndSwapX nodes is
seen. Of course, this test will not be helped at all by provision of a
volatile flag.

regards,


Andrew Dinn
-----------
Senior Principal Software Engineer
Red Hat UK Ltd
Registered in UK and Wales under Company Registration No. 3798903
Directors: Michael Cunningham (USA), Matt Parson (USA), Charlie Peters
(USA), Michael O'Neill (Ireland)

From adinn at redhat.com  Wed Apr 22 09:05:02 2015
From: adinn at redhat.com (Andrew Dinn)
Date: Wed, 22 Apr 2015 10:05:02 +0100
Subject: [aarch64-port-dev ] RFR: AArch64 -- patch to make volatile
	reads and stores use ldar/stlr
In-Reply-To: <55376318.7070604@redhat.com>
References: <5534C0EC.1070005@redhat.com>
	<5536482F.3020104@redhat.com>	<553653E8.4020301@redhat.com>
	<553682E5.9000001@oracle.com> <55376318.7070604@redhat.com>
Message-ID: <5537643E.5070404@redhat.com>



On 22/04/15 10:00, Andrew Dinn wrote:
> Hi Vladimir,
> 
> Thanks for responding.
> 
> On 21/04/15 18:03, Vladimir Kozlov wrote:
>> Would it help if we add a new flag to NodeFlags to indicate volatile
>> memory node?
> 
> Yes, I think this would provide some benefit although I don't know if it
> will justify cost of implementing and testing the necessary shared code
> changes given that the benefit is only partial. Even with such a flag we
> would still need to do some of the work that this patch does. Also, the
> flag would not help with a the next optimization we are planning
> (removing unnecessary barriers from CAS sequences).
> 
> Your suggestion will /simplify/ the predicates for LoadX/StoreX but will
> not make much difference to execution time. The current predicates for
> these nodes, needs_acquiring_load() and needs_releasing_store(), check
> immediately whether a LoadX is acquiring or a StoreX is releasing. So,
> we have a quick filter for the /common path/ case where we simply
> generate an ldr<x> or stlr<x> (I assume volatile ops are relatively rare).

  oops        ldr<x> or str<x>  !!!

> However, we cannot rely solely on these existing flags as they are
> sometimes set in other (non-volatile) cases. Currently, if the acquiring
> or releasing flag is set the predicates go on to investigate the nodes
> around the LoadX/StoreX looking for a specific configuration of
> MemBar_XXX nodes. Adding the volatile flag would remove the need to do
> this extra work in the /uncommon/ case.
> 
> Unfortunately, the other half of the patch involves eliding generation
> of dmb instructions for the MemBar_XXX nodes associated with the a LoadX
> or StoreX. Three other predicates are used for this purpose,
> unnecesary_membar_acquire, unnecesary_membar_release and
> unnecesary_membar_volatile. They search the ideal graph around the
> membar to see whether it belongs to a signature sequence containing an
> acquiring load or releasing store.
> 
> The check involves i) finding a related LoadX or StoreX, ii) checking it
> is acquiring or releasing and ii) ensuring it is either tailed or
> bracketed by a node group with a 'signature' shape which includes the
> MemBar we started from. A volatile flag would not really speed up this
> check and would not do much to simplify it.
> 
> The current predicates test for very specific signature configurations.
> So, in cases where the MemBar node is /not/ part of a signature volatile
> sequence they detect this very rapidly. In the common case the predicate
> immediately fails to find the required sort of parent/child node in the
> tree surrounding the initial MemBar (i.e. one which is not a
> LoadX/StoreX, Proj or MemBar). If we do arrive at a LoadX/StoreX in the
> node tree we could, perhaps, check the volatile flag and short-circuit
> any further graph traversal but the bulk of the work involves traversing
> from the initial MemBar to the LoadX/StoreX.
> 
> n.b. I say perhaps because I am not yet certain that we just test the
> volatile flag. I don't know for sure that we could not arrive at the
> memory node from a MemBar which was not part of the signature sequence
> (I /am/ very confident that the current checks correctly identify
> volatile node sequences and only those sequences).
> 
> Could we punt this question of providing the volatile flag, considering
> it as a potential follow-up improvement? I'd prefer to get this
> AArch64-only change in as is -- or, at least, with some tweaking --
> before going on to consider something which requires changes to shared code.
> 
> Also, I mentioned the CAS case above because that is what I am looking
> at next and it extends the technique used in the current patch.
> Currently CAS operations translate to something which looks like this
> 
>   dmb
>   ...
> retry:
>   ldaxr
>   ...
>   stlxr
>   cbz retry
>   ...
>   dmb
> 
> The ldaxr/stlxr pair are generated in response to a CompareAndSwapX node
> and the dmb instructions arise from MemBar nodes. For a CAS AArch64 can
> safely elide the dmb instructions. So, the next improvement will be to
> extend the unnecessary_membar_xxx predicates to elide the dmb generation
> when a suitable configuration of MemBar_XXX and CompareAndSwapX nodes is
> seen. Of course, this test will not be helped at all by provision of a
> volatile flag.
> 
> regards,
> 
> 
> Andrew Dinn
> -----------
> Senior Principal Software Engineer
> Red Hat UK Ltd
> Registered in UK and Wales under Company Registration No. 3798903
> Directors: Michael Cunningham (USA), Matt Parson (USA), Charlie Peters
> (USA), Michael O'Neill (Ireland)
> 
> 

-- 
regards,


Andrew Dinn
-----------
Senior Principal Software Engineer
Red Hat UK Ltd
Registered in UK and Wales under Company Registration No. 3798903
Directors: Michael Cunningham (USA), Matt Parson (USA), Charlie Peters
(USA), Michael O'Neill (Ireland)

From adinn at redhat.com  Wed Apr 22 09:12:10 2015
From: adinn at redhat.com (Andrew Dinn)
Date: Wed, 22 Apr 2015 10:12:10 +0100
Subject: [aarch64-port-dev ] RFR: AArch64 -- patch to make volatile
	reads and stores use ldar/stlr
In-Reply-To: <5536946E.6020809@oracle.com>
References: <5534C0EC.1070005@redhat.com>
	<5536482F.3020104@redhat.com>	<553653E8.4020301@redhat.com>
	<553682E5.9000001@oracle.com> <5536946E.6020809@oracle.com>
Message-ID: <553765EA.5060009@redhat.com>

On 21/04/15 19:18, Aleksey Shipilev wrote:
> There is also a pending idea for x86: try to replace volatile
> stores with "xchg", instead of "mov + lock addl". It would be nice
> to make sure the way AArch64 does the replacement would help the
> future x86 code.

I don't know for sure if this is going to be susceptible to the same
sort of implementation as I have provided but I think it is very likely.

As I understand it the x86 code generates the lock addl instruction in
response to a MemBarVolatile node. So, a predicate something like the
one I provided could be used to identify that the MemBarVolatile
belongs to a volatile load or store and hence that the lock addl can
be elided.

Similarly, I suspect the rules which generate the mov for normal
stores could probably be duplicated and a lower cost variant could use
a predicate similar to my needs_releasing_store() and plant an xchg
instead of a mov if the predicate decided the store was volatile.

regards,


Andrew Dinn
-----------
Senior Principal Software Engineer
Red Hat UK Ltd
Registered in UK and Wales under Company Registration No. 3798903
Directors: Michael Cunningham (USA), Matt Parson (USA), Charlie Peters
(USA), Michael O'Neill (Ireland)

From aph at redhat.com  Wed Apr 22 09:15:44 2015
From: aph at redhat.com (Andrew Haley)
Date: Wed, 22 Apr 2015 10:15:44 +0100
Subject: [aarch64-port-dev ] RFR: 8076488: AARCH64: jdk9 fails to build
	from source
In-Reply-To: <55313E22.1000800@redhat.com>
References: <1427905684.1631.12.camel@mylittlepony.linaroharston>	<551C300D.2090005@oracle.com>	<5530D3D2.5090505@redhat.com>	<183BF40D-554A-4318-8C5D-6070CBEF65FF@oracle.com>	<5530D501.1010004@redhat.com>
	<5530D5A7.90105@redhat.com>	<553139CB.8090303@oracle.com>
	<55313E22.1000800@redhat.com>
Message-ID: <553766C0.1000007@redhat.com>

On 04/17/2015 06:08 PM, Andrew Haley wrote:
> On 04/17/2015 05:50 PM, Vladimir Kozlov wrote:
>>  > Ah, no I won't.  My patch already fixed this, and (IMO) in a much better
>>  > way.  This patch is already in jprt, and will emerge soon, I hope.
>>
>> Andrew, do you mean the change pushed few days ago as part of 8077615 changes?:
>>
>> http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/2a6c4bd248cf
> 
> Yes.

How does this work?  Is it that changes are pushed to hs-comp (by
JPRT?) tested, and then manually merged at some point in the future?

I'm thinking about the workflow.  It's now Apr 22, and the patch
"Intrinsify ByteBuffer.put" went into hs-comp on Mar 31.  This seems
like a very long time to wait while developing.  It's particularly
awkward if we have a bug which breaks the build.

I'm not asking for anything to be changed, just trying to understand
how I (and other external contributors) should best interact with the
HotSpot workflow.

Thanks,
Andrew.

From edward.nevill at linaro.org  Wed Apr 22 09:40:57 2015
From: edward.nevill at linaro.org (Edward Nevill)
Date: Wed, 22 Apr 2015 10:40:57 +0100
Subject: [aarch64-port-dev ] RFR: 8075930: AARCH64: Use FP Register in C2
In-Reply-To: <5536A25C.7060402@oracle.com>
References: <1427288528.7353.25.camel@mylittlepony.linaroharston>
	<5512B817.3080802@oracle.com>
	<1428571873.26527.24.camel@mylittlepony.linaroharston>
	<5526B7B1.7000702@oracle.com>
	<1428656099.13172.10.camel@mylittlepony.linaroharston>
	<5527E1B9.5030109@oracle.com>
	<1429608038.4116.13.camel@mylittlepony.linaroharston>
	<55366888.2040409@redhat.com> <553669A3.8070205@redhat.com>
	<5536A25C.7060402@oracle.com>
Message-ID: <1429695657.29680.7.camel@mylittlepony.linaroharston>

On Tue, 2015-04-21 at 12:17 -0700, Dean Long wrote:
> On 4/21/2015 8:15 AM, Andrew Haley wrote:
> > On 04/21/2015 04:11 PM, Andrew Haley wrote:
> >> R29 (i.e. rfp) is marked Save-On-Entry.  It is the only allocatable
> >> general-purpose register which is.  I'm a bit worried that
> >> deoptimization might not restore this register correctly if it hasn't
> >> been spilled.  Maybe we should mark R29 as SOC.
> > On the gripping hand, x86_64 marks RBP, RSI and RDI as SOE registers.
> > So I think I'm worrying about nothing.
> >
> > Andrew.
> >
> 
> Does frame::update_map_with_saved_link() take care of R29 if it hasn't 
> been explicitly spilled?  If so, R29 could probably remain marked as NS 
> like before.

Hi Dean,

Yes, update_map_with_saved_link does take care of R29 and I have stepped through it in gdb to ensure that link_addr is in fact pointing at the saved fp.

I made R29 SOE rather than NS because I simply copied what was done on x86 where RBP is marked as SOE.

I don't believe it makes any difference to the code generation since we don't support callee saved registers, therefore it won't attempt to save R29 on entry even if it is marked as SOE. However, it may be clearer to mark it as NS.

If there is no other feedback shall I prepare a revised patch with R29 marked NS?

All the best,
Ed.



From aph at redhat.com  Wed Apr 22 09:54:26 2015
From: aph at redhat.com (Andrew Haley)
Date: Wed, 22 Apr 2015 10:54:26 +0100
Subject: [aarch64-port-dev ] RFR: 8075930: AARCH64: Use FP Register in C2
In-Reply-To: <1429695657.29680.7.camel@mylittlepony.linaroharston>
References: <1427288528.7353.25.camel@mylittlepony.linaroharston>		<5512B817.3080802@oracle.com>		<1428571873.26527.24.camel@mylittlepony.linaroharston>		<5526B7B1.7000702@oracle.com>		<1428656099.13172.10.camel@mylittlepony.linaroharston>		<5527E1B9.5030109@oracle.com>		<1429608038.4116.13.camel@mylittlepony.linaroharston>		<55366888.2040409@redhat.com>
	<553669A3.8070205@redhat.com>	 <5536A25C.7060402@oracle.com>
	<1429695657.29680.7.camel@mylittlepony.linaroharston>
Message-ID: <55376FD2.5000403@redhat.com>

On 04/22/2015 10:40 AM, Edward Nevill wrote:

> Yes, update_map_with_saved_link does take care of R29 and I have
> stepped through it in gdb to ensure that link_addr is in fact
> pointing at the saved fp.
> 
> I made R29 SOE rather than NS because I simply copied what was done
> on x86 where RBP is marked as SOE.
> 
> I don't believe it makes any difference to the code generation since
> we don't support callee saved registers, therefore it won't attempt
> to save R29 on entry even if it is marked as SOE. However, it may be
> clearer to mark it as NS.
> 
> If there is no other feedback shall I prepare a revised patch with
> R29 marked NS?

I really want to understand this properly.  Are we sure that when
deoptimization happens (or when the stack is scanned for GC roots
during a safepoint) the R29 saved by our callee (which may be native
code) will be correctly processed?

As I understand it, garbage collection would have to rewrite the R29
saved by a native code prologue for this to work.  But we don't even
know where in the frame native functions save FP, so I don't see how
this can possibly work.

Andrew.

From aph at redhat.com  Wed Apr 22 16:58:01 2015
From: aph at redhat.com (Andrew Haley)
Date: Wed, 22 Apr 2015 17:58:01 +0100
Subject: [aarch64-port-dev ] RFR: 8075930: AARCH64: Use FP Register in C2
In-Reply-To: <55376FD2.5000403@redhat.com>
References: <1427288528.7353.25.camel@mylittlepony.linaroharston>		<5512B817.3080802@oracle.com>		<1428571873.26527.24.camel@mylittlepony.linaroharston>		<5526B7B1.7000702@oracle.com>		<1428656099.13172.10.camel@mylittlepony.linaroharston>		<5527E1B9.5030109@oracle.com>		<1429608038.4116.13.camel@mylittlepony.linaroharston>		<55366888.2040409@redhat.com>	<553669A3.8070205@redhat.com>	
	<5536A25C.7060402@oracle.com>	<1429695657.29680.7.camel@mylittlepony.linaroharston>
	<55376FD2.5000403@redhat.com>
Message-ID: <5537D319.4010207@redhat.com>

Looking at this thread:

http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2014-December/016477.html
https://bugs.openjdk.java.net/browse/JDK-8068945

I'm wondering if we should keep FP as a frame pointer.  We'd have a
slightly more complex method entry sequence, but the profiling and
debugging advantages look to be quite considerable.

Andrew.

From edward.nevill at linaro.org  Wed Apr 22 18:58:37 2015
From: edward.nevill at linaro.org (Edward Nevill)
Date: Wed, 22 Apr 2015 19:58:37 +0100
Subject: [aarch64-port-dev ] RFR: 8075930: AARCH64: Use FP Register in C2
In-Reply-To: <5537D319.4010207@redhat.com>
References: <1427288528.7353.25.camel@mylittlepony.linaroharston>
	<5512B817.3080802@oracle.com>
	<1428571873.26527.24.camel@mylittlepony.linaroharston>
	<5526B7B1.7000702@oracle.com>
	<1428656099.13172.10.camel@mylittlepony.linaroharston>
	<5527E1B9.5030109@oracle.com>
	<1429608038.4116.13.camel@mylittlepony.linaroharston>
	<55366888.2040409@redhat.com> <553669A3.8070205@redhat.com>
	<5536A25C.7060402@oracle.com>
	<1429695657.29680.7.camel@mylittlepony.linaroharston>
	<55376FD2.5000403@redhat.com> <5537D319.4010207@redhat.com>
Message-ID: <CAEf2cjduOuGq8YtZ-BqOQ3K1aO0+s4tDvF-FMd=RawBYuf3+xQ@mail.gmail.com>

On 22 April 2015 at 17:58, Andrew Haley <aph at redhat.com> wrote:

> Looking at this thread:
>
>
> http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2014-December/016477.html
> https://bugs.openjdk.java.net/browse/JDK-8068945
>
> I'm wondering if we should keep FP as a frame pointer.  We'd have a
> slightly more complex method entry sequence, but the profiling and
> debugging advantages look to be quite considerable.
>
> Andrew.
>

Hi,

The two are not incompatible. Zolt?n Maj? has been working on a patch to
use RBP as a proper frame pointer on x86. See

http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2015-April/017715.html

This provides a new flag -XX:+PreserveFramePointer which uses RBP as a
proper frame pointer and -XX:-PreserveFramePointer which uses RBP as a
general purpose register.

I have prepared a mirror patch for this for aarch64. See

http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2015-March/017543.html

Once Zolt?n's patch goes in, I can update this for any recent changes and
post a RFR.

All the best,
Ed.

From vladimir.kozlov at oracle.com  Wed Apr 22 22:48:02 2015
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Wed, 22 Apr 2015 15:48:02 -0700
Subject: [aarch64-port-dev ] RFR: 8076488: AARCH64: jdk9 fails to build
	from source
In-Reply-To: <553766C0.1000007@redhat.com>
References: <1427905684.1631.12.camel@mylittlepony.linaroharston>	<551C300D.2090005@oracle.com>	<5530D3D2.5090505@redhat.com>	<183BF40D-554A-4318-8C5D-6070CBEF65FF@oracle.com>	<5530D501.1010004@redhat.com>
	<5530D5A7.90105@redhat.com>	<553139CB.8090303@oracle.com>
	<55313E22.1000800@redhat.com> <553766C0.1000007@redhat.com>
Message-ID: <55382522.5010100@oracle.com>

Best case scenario:

1. Changes pushed into a Hotspot groups repos (jdk9/hs-comp) using JPRT 
and we do Nightly testing on them.

2. Each week on Thursday all changes which passed at least one Nightly 
testing are pushed from all groups repos into main repo (jdk9/hs) using 
JPRT.

3. Hotspot gatekeeper creates bundles for all platforms from main repo 
(jdk9/hs) and start PIT testing which is going whole weekend.

4. Monday-Tuesday SQE analyze PIT results and give yes (or no) on merge 
to jdk9/dev. If 'yes' Hotspot gatekeeper pushes changes to jdk9/dev.

So usually it takes one/one-and-half weeks for changes propagate from 
jdk9/hs-comp to jdk9/dev.


What happened in last weeks. As you may notice no Hotspot changes were 
pushed into jdk9/dev since April 6:

http://mail.openjdk.java.net/pipermail/jdk9-dev-changes/2015-April/003119.html

We had severe failures on Windows systems and SQE gave 'no' on merge to 
jdk9/dev.

And jdk9/hs-comp was not merged to jdk9/hs between March 31 and April 6 
because we had regression in Nightly testing.

Note, this and next week there will be no merge to jdk9/dev due to 
technical issues (we will not be able to run PIT testing).

Most likely you will see "Intrinsify ByteBuffer.put" changes in jdk9/dev 
only in May.

My suggestion would be to use one of Hotspot group's repo as base for 
your work if it includes Hotspot changes.

Regards,
Vladimir

On 4/22/15 2:15 AM, Andrew Haley wrote:
> On 04/17/2015 06:08 PM, Andrew Haley wrote:
>> On 04/17/2015 05:50 PM, Vladimir Kozlov wrote:
>>>   > Ah, no I won't.  My patch already fixed this, and (IMO) in a much better
>>>   > way.  This patch is already in jprt, and will emerge soon, I hope.
>>>
>>> Andrew, do you mean the change pushed few days ago as part of 8077615 changes?:
>>>
>>> http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/2a6c4bd248cf
>>
>> Yes.
>
> How does this work?  Is it that changes are pushed to hs-comp (by
> JPRT?) tested, and then manually merged at some point in the future?
>
> I'm thinking about the workflow.  It's now Apr 22, and the patch
> "Intrinsify ByteBuffer.put" went into hs-comp on Mar 31.  This seems
> like a very long time to wait while developing.  It's particularly
> awkward if we have a bug which breaks the build.
>
> I'm not asking for anything to be changed, just trying to understand
> how I (and other external contributors) should best interact with the
> HotSpot workflow.
>
> Thanks,
> Andrew.
>

From vladimir.kozlov at oracle.com  Wed Apr 22 22:59:02 2015
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Wed, 22 Apr 2015 15:59:02 -0700
Subject: [aarch64-port-dev ] RFR: AArch64 -- patch to make volatile
	reads and stores use ldar/stlr
In-Reply-To: <55376318.7070604@redhat.com>
References: <5534C0EC.1070005@redhat.com> <5536482F.3020104@redhat.com>
	<553653E8.4020301@redhat.com> <553682E5.9000001@oracle.com>
	<55376318.7070604@redhat.com>
Message-ID: <553827B6.9000800@oracle.com>

First, I am fine with your changes. I thought that may be adding some 
shared code (flag?) will simplify (reduce) your change. But based on 
your answer it is not the case. So I am fine with you changes.

Thanks,
Vladimir

On 4/22/15 2:00 AM, Andrew Dinn wrote:
> Hi Vladimir,
>
> Thanks for responding.
>
> On 21/04/15 18:03, Vladimir Kozlov wrote:
>> Would it help if we add a new flag to NodeFlags to indicate volatile
>> memory node?
>
> Yes, I think this would provide some benefit although I don't know if it
> will justify cost of implementing and testing the necessary shared code
> changes given that the benefit is only partial. Even with such a flag we
> would still need to do some of the work that this patch does. Also, the
> flag would not help with a the next optimization we are planning
> (removing unnecessary barriers from CAS sequences).
>
> Your suggestion will /simplify/ the predicates for LoadX/StoreX but will
> not make much difference to execution time. The current predicates for
> these nodes, needs_acquiring_load() and needs_releasing_store(), check
> immediately whether a LoadX is acquiring or a StoreX is releasing. So,
> we have a quick filter for the /common path/ case where we simply
> generate an ldr<x> or stlr<x> (I assume volatile ops are relatively rare).
>
> However, we cannot rely solely on these existing flags as they are
> sometimes set in other (non-volatile) cases. Currently, if the acquiring
> or releasing flag is set the predicates go on to investigate the nodes
> around the LoadX/StoreX looking for a specific configuration of
> MemBar_XXX nodes. Adding the volatile flag would remove the need to do
> this extra work in the /uncommon/ case.
>
> Unfortunately, the other half of the patch involves eliding generation
> of dmb instructions for the MemBar_XXX nodes associated with the a LoadX
> or StoreX. Three other predicates are used for this purpose,
> unnecesary_membar_acquire, unnecesary_membar_release and
> unnecesary_membar_volatile. They search the ideal graph around the
> membar to see whether it belongs to a signature sequence containing an
> acquiring load or releasing store.
>
> The check involves i) finding a related LoadX or StoreX, ii) checking it
> is acquiring or releasing and ii) ensuring it is either tailed or
> bracketed by a node group with a 'signature' shape which includes the
> MemBar we started from. A volatile flag would not really speed up this
> check and would not do much to simplify it.
>
> The current predicates test for very specific signature configurations.
> So, in cases where the MemBar node is /not/ part of a signature volatile
> sequence they detect this very rapidly. In the common case the predicate
> immediately fails to find the required sort of parent/child node in the
> tree surrounding the initial MemBar (i.e. one which is not a
> LoadX/StoreX, Proj or MemBar). If we do arrive at a LoadX/StoreX in the
> node tree we could, perhaps, check the volatile flag and short-circuit
> any further graph traversal but the bulk of the work involves traversing
> from the initial MemBar to the LoadX/StoreX.
>
> n.b. I say perhaps because I am not yet certain that we just test the
> volatile flag. I don't know for sure that we could not arrive at the
> memory node from a MemBar which was not part of the signature sequence
> (I /am/ very confident that the current checks correctly identify
> volatile node sequences and only those sequences).
>
> Could we punt this question of providing the volatile flag, considering
> it as a potential follow-up improvement? I'd prefer to get this
> AArch64-only change in as is -- or, at least, with some tweaking --
> before going on to consider something which requires changes to shared code.
>
> Also, I mentioned the CAS case above because that is what I am looking
> at next and it extends the technique used in the current patch.
> Currently CAS operations translate to something which looks like this
>
>    dmb
>    ...
> retry:
>    ldaxr
>    ...
>    stlxr
>    cbz retry
>    ...
>    dmb
>
> The ldaxr/stlxr pair are generated in response to a CompareAndSwapX node
> and the dmb instructions arise from MemBar nodes. For a CAS AArch64 can
> safely elide the dmb instructions. So, the next improvement will be to
> extend the unnecessary_membar_xxx predicates to elide the dmb generation
> when a suitable configuration of MemBar_XXX and CompareAndSwapX nodes is
> seen. Of course, this test will not be helped at all by provision of a
> volatile flag.
>
> regards,
>
>
> Andrew Dinn
> -----------
> Senior Principal Software Engineer
> Red Hat UK Ltd
> Registered in UK and Wales under Company Registration No. 3798903
> Directors: Michael Cunningham (USA), Matt Parson (USA), Charlie Peters
> (USA), Michael O'Neill (Ireland)
>

From aph at redhat.com  Thu Apr 23 07:40:45 2015
From: aph at redhat.com (Andrew Haley)
Date: Thu, 23 Apr 2015 08:40:45 +0100
Subject: [aarch64-port-dev ] RFR: 8075930: AARCH64: Use FP Register in C2
In-Reply-To: <1429695657.29680.7.camel@mylittlepony.linaroharston>
References: <1427288528.7353.25.camel@mylittlepony.linaroharston>		<5512B817.3080802@oracle.com>		<1428571873.26527.24.camel@mylittlepony.linaroharston>		<5526B7B1.7000702@oracle.com>		<1428656099.13172.10.camel@mylittlepony.linaroharston>		<5527E1B9.5030109@oracle.com>		<1429608038.4116.13.camel@mylittlepony.linaroharston>		<55366888.2040409@redhat.com>
	<553669A3.8070205@redhat.com>	 <5536A25C.7060402@oracle.com>
	<1429695657.29680.7.camel@mylittlepony.linaroharston>
Message-ID: <5538A1FD.3060504@redhat.com>

On 22/04/15 10:40, Edward Nevill wrote:
> If there is no other feedback shall I prepare a revised patch with R29 marked NS?

I think you should.  I'm as certain as I can be that the GC root-
finding code won't find an OOP saved in R29 and then pushed by
native code.

Andrew.


From edward.nevill at linaro.org  Thu Apr 23 10:07:57 2015
From: edward.nevill at linaro.org (Edward Nevill)
Date: Thu, 23 Apr 2015 11:07:57 +0100
Subject: [aarch64-port-dev ] JDK9 Hotspot test failures (was RE: One other
	thing)
In-Reply-To: <840A7E9DC095B04FA87BF37DDD9D1CF984A6BF@HQ-MS1.office.auriga.msk>
References: <840A7E9DC095B04FA87BF37DDD9D1CF984A05C@HQ-MS1.office.auriga.msk>
	<55364490.4000906@redhat.com>
	<840A7E9DC095B04FA87BF37DDD9D1CF984A237@HQ-MS1.office.auriga.msk>
	<CAEf2cjctjXiecC6+1hEbioa3tyWO3SX8HpWuOvdvUDea-PLTjA@mail.gmail.com>
	<840A7E9DC095B04FA87BF37DDD9D1CF984A507@HQ-MS1.office.auriga.msk>
	<1429722387.30593.9.camel@mylittlepony.linaroharston>
	<840A7E9DC095B04FA87BF37DDD9D1CF984A5CC@HQ-MS1.office.auriga.msk>
	,<CAEf2cjd3e5t9Cg7wHFtU3pYw1fX2qzA-0F6K8bz5N6f=E-siTA@mail.gmail.com>
	<840A7E9DC095B04FA87BF37DDD9D1CF984A6BF@HQ-MS1.office.auriga.msk>
Message-ID: <1429783677.13276.15.camel@mylittlepony.linaroharston>

Hi Alexander,

I have moved this discussion to aarch-port-dev.

On Wed, 2015-04-22 at 19:51 +0000, Alexeev, Alexander wrote:
> Again no luck 
> 
> Test results: passed: 772; failed: 34; error: 22
> 
> hg clone http://hg.openjdk.java.net/jdk9/dev
> hg clone http://hg.openjdk.java.net/jdk9/dev/hotspot
> ...
> + subfolders
> 

Sorry, my bad. I am now seeing

Test results: passed: 778; failed: 33; error: 1

Of the 33 failures most of these seem to be test failures rather than hotspot failures.

For example, I believe I fixed all of these in jdk8

FAILED: compiler/stable/TestStableBoolean.java
FAILED: compiler/stable/TestStableByte.java
FAILED: compiler/stable/TestStableDouble.java
FAILED: compiler/stable/TestStableChar.java
FAILED: compiler/stable/TestStableLong.java
FAILED: compiler/stable/TestStableInt.java
FAILED: compiler/stable/TestStableShort.java
FAILED: compiler/stable/TestStableObject.java
FAILED: compiler/stable/TestStableFloat.java

>From the jdk8 log

changeset:   7554:68cf8e406ce5
user:        Edward Nevill edward.nevill at linaro.org
date:        Wed Sep 24 12:56:10 2014 +0100
files:       test/compiler/stable/StableConfiguration.java
description:
Fix failing TestStable tests

However, it would seem these changes did not make it through to jdk9.

If you feel like going through the remaining 33 failures and preparing a patch or patches for submission to jdk9 that would be most useful, otherwise I will add it to my todo list.

For reference here is the list of test failures I am now seeing. The ones marked (*) I believe were fixed in jdk8.

FAILED: compiler/codegen/7184394/TestAESMain.java
FAILED: compiler/intrinsics/classcast/NullCheckDroppingsTest.java
* FAILED: compiler/intrinsics/mathexact/sanity/MultiplyExactIntTest.java
* FAILED: compiler/intrinsics/mathexact/sanity/IncrementExactIntTest.java
* FAILED: compiler/intrinsics/mathexact/sanity/DecrementExactIntTest.java
* FAILED: compiler/intrinsics/mathexact/sanity/AddExactIntTest.java
* FAILED: compiler/intrinsics/mathexact/sanity/DecrementExactLongTest.java
* FAILED: compiler/intrinsics/mathexact/sanity/MultiplyExactLongTest.java
* FAILED: compiler/intrinsics/mathexact/sanity/NegateExactIntTest.java
* FAILED: compiler/intrinsics/mathexact/sanity/IncrementExactLongTest.java
* FAILED: compiler/intrinsics/mathexact/sanity/SubtractExactIntTest.java
* FAILED: compiler/intrinsics/mathexact/sanity/AddExactLongTest.java
* FAILED: compiler/intrinsics/mathexact/sanity/NegateExactLongTest.java
* FAILED: compiler/intrinsics/mathexact/sanity/SubtractExactLongTest.java
* FAILED: compiler/intrinsics/sha/cli/TestUseSHA256IntrinsicsOptionOnUnsupportedCPU.java
* FAILED: compiler/intrinsics/sha/cli/TestUseSHAOptionOnUnsupportedCPU.java
* FAILED: compiler/intrinsics/sha/cli/TestUseSHA1IntrinsicsOptionOnUnsupportedCPU.java
* FAILED: compiler/intrinsics/sha/sanity/TestSHA1MultiBlockIntrinsics.java
* FAILED: compiler/intrinsics/sha/sanity/TestSHA1Intrinsics.java
* FAILED: compiler/intrinsics/sha/sanity/TestSHA256Intrinsics.java
* FAILED: compiler/intrinsics/sha/sanity/TestSHA256MultiBlockIntrinsics.java
* FAILED: compiler/stable/TestStableBoolean.java
* FAILED: compiler/stable/TestStableByte.java
* FAILED: compiler/stable/TestStableDouble.java
* FAILED: compiler/stable/TestStableChar.java
* FAILED: compiler/stable/TestStableLong.java
* FAILED: compiler/stable/TestStableInt.java
* FAILED: compiler/stable/TestStableShort.java
* FAILED: compiler/stable/TestStableObject.java
* FAILED: compiler/stable/TestStableFloat.java
FAILED: compiler/whitebox/DeoptimizeFramesTest.java
FAILED: runtime/CommandLine/TestVMOptions.java
FAILED: testlibrary_tests/TestMutuallyExclusivePlatformPredicates.java



From adinn at redhat.com  Thu Apr 23 11:37:35 2015
From: adinn at redhat.com (Andrew Dinn)
Date: Thu, 23 Apr 2015 12:37:35 +0100
Subject: [aarch64-port-dev ] RFR: AArch64 -- patch to make volatile
	reads and stores use ldar/stlr
In-Reply-To: <553827B6.9000800@oracle.com>
References: <5534C0EC.1070005@redhat.com> <5536482F.3020104@redhat.com>
	<553653E8.4020301@redhat.com> <553682E5.9000001@oracle.com>
	<55376318.7070604@redhat.com> <553827B6.9000800@oracle.com>
Message-ID: <5538D97F.8080003@redhat.com>

On 22/04/15 23:59, Vladimir Kozlov wrote:
> First, I am fine with your changes. I thought that may be adding some
> shared code (flag?) will simplify (reduce) your change. But based on
> your answer it is not the case. So I am fine with you changes.

Thanks Vladimir.

Andrew (Haley), since this has been reviewed by you as well and is an
AArch64 only change does that mean you can now push a patch?

regards,


Andrew Dinn
-----------
Senior Principal Software Engineer
Red Hat UK Ltd
Registered in UK and Wales under Company Registration No. 3798903
Directors: Michael Cunningham (USA), Matt Parson (USA), Charlie Peters
(USA), Michael O'Neill (Ireland)

From aph at redhat.com  Thu Apr 23 11:57:02 2015
From: aph at redhat.com (Andrew Haley)
Date: Thu, 23 Apr 2015 12:57:02 +0100
Subject: [aarch64-port-dev ] RFR: AArch64 -- patch to make volatile
	reads and stores use ldar/stlr
In-Reply-To: <5538D97F.8080003@redhat.com>
References: <5534C0EC.1070005@redhat.com>
	<5536482F.3020104@redhat.com>	<553653E8.4020301@redhat.com>
	<553682E5.9000001@oracle.com>	<55376318.7070604@redhat.com>
	<553827B6.9000800@oracle.com> <5538D97F.8080003@redhat.com>
Message-ID: <5538DE0E.4090205@redhat.com>

On 04/23/2015 12:37 PM, Andrew Dinn wrote:
> On 22/04/15 23:59, Vladimir Kozlov wrote:
>> First, I am fine with your changes. I thought that may be adding some
>> shared code (flag?) will simplify (reduce) your change. But based on
>> your answer it is not the case. So I am fine with you changes.
> 
> Thanks Vladimir.
> 
> Andrew (Haley), since this has been reviewed by you as well and is an
> AArch64 only change does that mean you can now push a patch?

Yes, I will.

Andrew.



From alexander.alexeev at auriga.com  Thu Apr 23 13:06:47 2015
From: alexander.alexeev at auriga.com (Alexeev, Alexander)
Date: Thu, 23 Apr 2015 13:06:47 +0000
Subject: [aarch64-port-dev ] JDK9 Hotspot test failures (was RE: One
	other thing)
In-Reply-To: <1429783677.13276.15.camel@mylittlepony.linaroharston>
References: <840A7E9DC095B04FA87BF37DDD9D1CF984A05C@HQ-MS1.office.auriga.msk>
	<55364490.4000906@redhat.com>
	<840A7E9DC095B04FA87BF37DDD9D1CF984A237@HQ-MS1.office.auriga.msk>
	<CAEf2cjctjXiecC6+1hEbioa3tyWO3SX8HpWuOvdvUDea-PLTjA@mail.gmail.com>
	<840A7E9DC095B04FA87BF37DDD9D1CF984A507@HQ-MS1.office.auriga.msk>
	<1429722387.30593.9.camel@mylittlepony.linaroharston>
	<840A7E9DC095B04FA87BF37DDD9D1CF984A5CC@HQ-MS1.office.auriga.msk>
	,<CAEf2cjd3e5t9Cg7wHFtU3pYw1fX2qzA-0F6K8bz5N6f=E-siTA@mail.gmail.com>
	<840A7E9DC095B04FA87BF37DDD9D1CF984A6BF@HQ-MS1.office.auriga.msk>,
	<1429783677.13276.15.camel@mylittlepony.linaroharston>
Message-ID: <840A7E9DC095B04FA87BF37DDD9D1CF984A741@HQ-MS1.office.auriga.msk>

 > If you feel like going through the remaining 33 failures and preparing a patch or patches for submission to jdk9 that would be most useful, otherwise I will add it to my todo list.

I will do that.
________________________________________
From: Edward Nevill [edward.nevill at linaro.org]
Sent: 23 April 2015 13:07
To: aarch64-port-dev at openjdk.java.net
Cc: Andrew Haley; Jasty, Ananth; Alexeev, Alexander
Subject: JDK9 Hotspot test failures (was RE: One other thing)

Hi Alexander,

I have moved this discussion to aarch-port-dev.

On Wed, 2015-04-22 at 19:51 +0000, Alexeev, Alexander wrote:
> Again no luck
>
> Test results: passed: 772; failed: 34; error: 22
>
> hg clone http://hg.openjdk.java.net/jdk9/dev
> hg clone http://hg.openjdk.java.net/jdk9/dev/hotspot
> ...
> + subfolders
>

Sorry, my bad. I am now seeing

Test results: passed: 778; failed: 33; error: 1

Of the 33 failures most of these seem to be test failures rather than hotspot failures.

For example, I believe I fixed all of these in jdk8

FAILED: compiler/stable/TestStableBoolean.java
FAILED: compiler/stable/TestStableByte.java
FAILED: compiler/stable/TestStableDouble.java
FAILED: compiler/stable/TestStableChar.java
FAILED: compiler/stable/TestStableLong.java
FAILED: compiler/stable/TestStableInt.java
FAILED: compiler/stable/TestStableShort.java
FAILED: compiler/stable/TestStableObject.java
FAILED: compiler/stable/TestStableFloat.java

>From the jdk8 log

changeset:   7554:68cf8e406ce5
user:        Edward Nevill edward.nevill at linaro.org
date:        Wed Sep 24 12:56:10 2014 +0100
files:       test/compiler/stable/StableConfiguration.java
description:
Fix failing TestStable tests

However, it would seem these changes did not make it through to jdk9.

If you feel like going through the remaining 33 failures and preparing a patch or patches for submission to jdk9 that would be most useful, otherwise I will add it to my todo list.

For reference here is the list of test failures I am now seeing. The ones marked (*) I believe were fixed in jdk8.

FAILED: compiler/codegen/7184394/TestAESMain.java
FAILED: compiler/intrinsics/classcast/NullCheckDroppingsTest.java
* FAILED: compiler/intrinsics/mathexact/sanity/MultiplyExactIntTest.java
* FAILED: compiler/intrinsics/mathexact/sanity/IncrementExactIntTest.java
* FAILED: compiler/intrinsics/mathexact/sanity/DecrementExactIntTest.java
* FAILED: compiler/intrinsics/mathexact/sanity/AddExactIntTest.java
* FAILED: compiler/intrinsics/mathexact/sanity/DecrementExactLongTest.java
* FAILED: compiler/intrinsics/mathexact/sanity/MultiplyExactLongTest.java
* FAILED: compiler/intrinsics/mathexact/sanity/NegateExactIntTest.java
* FAILED: compiler/intrinsics/mathexact/sanity/IncrementExactLongTest.java
* FAILED: compiler/intrinsics/mathexact/sanity/SubtractExactIntTest.java
* FAILED: compiler/intrinsics/mathexact/sanity/AddExactLongTest.java
* FAILED: compiler/intrinsics/mathexact/sanity/NegateExactLongTest.java
* FAILED: compiler/intrinsics/mathexact/sanity/SubtractExactLongTest.java
* FAILED: compiler/intrinsics/sha/cli/TestUseSHA256IntrinsicsOptionOnUnsupportedCPU.java
* FAILED: compiler/intrinsics/sha/cli/TestUseSHAOptionOnUnsupportedCPU.java
* FAILED: compiler/intrinsics/sha/cli/TestUseSHA1IntrinsicsOptionOnUnsupportedCPU.java
* FAILED: compiler/intrinsics/sha/sanity/TestSHA1MultiBlockIntrinsics.java
* FAILED: compiler/intrinsics/sha/sanity/TestSHA1Intrinsics.java
* FAILED: compiler/intrinsics/sha/sanity/TestSHA256Intrinsics.java
* FAILED: compiler/intrinsics/sha/sanity/TestSHA256MultiBlockIntrinsics.java
* FAILED: compiler/stable/TestStableBoolean.java
* FAILED: compiler/stable/TestStableByte.java
* FAILED: compiler/stable/TestStableDouble.java
* FAILED: compiler/stable/TestStableChar.java
* FAILED: compiler/stable/TestStableLong.java
* FAILED: compiler/stable/TestStableInt.java
* FAILED: compiler/stable/TestStableShort.java
* FAILED: compiler/stable/TestStableObject.java
* FAILED: compiler/stable/TestStableFloat.java
FAILED: compiler/whitebox/DeoptimizeFramesTest.java
FAILED: runtime/CommandLine/TestVMOptions.java
FAILED: testlibrary_tests/TestMutuallyExclusivePlatformPredicates.java



From edward.nevill at linaro.org  Thu Apr 23 15:13:50 2015
From: edward.nevill at linaro.org (Edward Nevill)
Date: Thu, 23 Apr 2015 16:13:50 +0100
Subject: [aarch64-port-dev ] RFR: 8075930: AARCH64: Use FP Register in C2
In-Reply-To: <5538A1FD.3060504@redhat.com>
References: <1427288528.7353.25.camel@mylittlepony.linaroharston>
	<5512B817.3080802@oracle.com>
	<1428571873.26527.24.camel@mylittlepony.linaroharston>
	<5526B7B1.7000702@oracle.com>
	<1428656099.13172.10.camel@mylittlepony.linaroharston>
	<5527E1B9.5030109@oracle.com>
	<1429608038.4116.13.camel@mylittlepony.linaroharston>
	<55366888.2040409@redhat.com> <553669A3.8070205@redhat.com>
	<5536A25C.7060402@oracle.com>
	<1429695657.29680.7.camel@mylittlepony.linaroharston>
	<5538A1FD.3060504@redhat.com>
Message-ID: <1429802030.17540.37.camel@mylittlepony.linaroharston>

On Thu, 2015-04-23 at 08:40 +0100, Andrew Haley wrote:
> On 22/04/15 10:40, Edward Nevill wrote:
> > If there is no other feedback shall I prepare a revised patch with R29 marked NS?
> 
> I think you should.  I'm as certain as I can be that the GC root-
> finding code won't find an OOP saved in R29 and then pushed by
> native code.

Done.

http://cr.openjdk.java.net/~enevill/8075930/webrev.04/

However I don't believe it makes any difference to the code generated. C2 will still use R29 as a general purpose register, and will still not spill it on a method call (I have checked).

I think that in order to do a GC root scan it must be at a safe point and I don't believe it can be at a safe point in native code.

In compiled code it uses the OopMaps, unwinds the stack and finds the OOP in R29.

This works for x86. It does exactly the same thing. RBP is available as a general purpose register and RBP is marked as SOE.

All the best,
Ed.



From aph at redhat.com  Thu Apr 23 16:46:28 2015
From: aph at redhat.com (Andrew Haley)
Date: Thu, 23 Apr 2015 17:46:28 +0100
Subject: [aarch64-port-dev ] RFR: 8075930: AARCH64: Use FP Register in C2
In-Reply-To: <1429802030.17540.37.camel@mylittlepony.linaroharston>
References: <1427288528.7353.25.camel@mylittlepony.linaroharston>			<5512B817.3080802@oracle.com>			<1428571873.26527.24.camel@mylittlepony.linaroharston>			<5526B7B1.7000702@oracle.com>			<1428656099.13172.10.camel@mylittlepony.linaroharston>			<5527E1B9.5030109@oracle.com>			<1429608038.4116.13.camel@mylittlepony.linaroharston>			<55366888.2040409@redhat.com>
	<553669A3.8070205@redhat.com>		 <5536A25C.7060402@oracle.com>	
	<1429695657.29680.7.camel@mylittlepony.linaroharston>	
	<5538A1FD.3060504@redhat.com>
	<1429802030.17540.37.camel@mylittlepony.linaroharston>
Message-ID: <553921E4.5090408@redhat.com>

On 04/23/2015 04:13 PM, Edward Nevill wrote:
> On Thu, 2015-04-23 at 08:40 +0100, Andrew Haley wrote:
>> On 22/04/15 10:40, Edward Nevill wrote:
>>> If there is no other feedback shall I prepare a revised patch with R29 marked NS?
>>
>> I think you should.  I'm as certain as I can be that the GC root-
>> finding code won't find an OOP saved in R29 and then pushed by
>> native code.
> 
> Done.
> 
> http://cr.openjdk.java.net/~enevill/8075930/webrev.04/

Please run webrev after committing, so that the webrev is a proper
changeset.  Please make sure that the jcheck extension is enabled.

http://openjdk.java.net/projects/code-tools/jcheck/

> However I don't believe it makes any difference to the code
> generated. C2 will still use R29 as a general purpose register, and
> will still not spill it on a method call (I have checked).
> 
> I think that in order to do a GC root scan it must be at a safe
> point and I don't believe it can be at a safe point in native code.

Sure it can.  Native methods are always safepoints, as are calls to
the runtime to allocate objects, etc.  But all such calls have a
wrapper, and it pushes FP, it has an OopMap, so it should be fine.

> In compiled code it uses the OopMaps, unwinds the stack and finds
> the OOP in R29.

Okay, I see.

Thanks,
Andrew.

From aph at redhat.com  Thu Apr 23 16:54:14 2015
From: aph at redhat.com (Andrew Haley)
Date: Thu, 23 Apr 2015 17:54:14 +0100
Subject: [aarch64-port-dev ] 8078263: AARCH64: Volatile fields should be
 accessed with ldar and stlr
In-Reply-To: <553653E8.4020301@redhat.com>
References: <5534C0EC.1070005@redhat.com> <5536482F.3020104@redhat.com>
	<553653E8.4020301@redhat.com>
Message-ID: <553923B6.3030407@redhat.com>

On 04/21/2015 02:43 PM, Andrew Dinn wrote:
> On 21/04/15 13:53, Andrew Haley wrote:
>> On 04/20/2015 10:03 AM, Andrew Dinn wrote:
>>> The following webrev is submitted for review (n.b. I am not an OpenJDK
>>> committer so the patch does not yet have an associated JIRA).
>>
>> The patch looks good to me.
>>
>> https://bugs.openjdk.java.net/browse/JDK-8078263
> 
> A new webrev with the commit in standard format (listing JIRA#, sumamry
> and reviewer) and placed at:
> 
>   http://cr.openjdk.java.net/~adinn/8078263/webrev.01/

I'm surprised this got past jcheck:


[jcheck 81464834db37 2014-06-05 14:03:52 -0700]

> Changeset: 8074:671ecf42ede2
> Author:    adinn
> Date:      2015-04-21 14:40
>
> 8078263 AARCH64: Volatile fields should be accessed with ldar and stlr
> Summary: ad file rules now generate load acquire and store release for volatile accesses
> Reviewed-by: aph

Incomplete comment: Missing bugid line
Incomplete comment: Missing reviewer attribution
Extraneous text in comment

transaction abort!
rollback completed



From dean.long at oracle.com  Thu Apr 23 19:01:01 2015
From: dean.long at oracle.com (Dean Long)
Date: Thu, 23 Apr 2015 12:01:01 -0700
Subject: [aarch64-port-dev ] RFR: 8075930: AARCH64: Use FP Register in C2
In-Reply-To: <553921E4.5090408@redhat.com>
References: <1427288528.7353.25.camel@mylittlepony.linaroharston>			<5512B817.3080802@oracle.com>			<1428571873.26527.24.camel@mylittlepony.linaroharston>			<5526B7B1.7000702@oracle.com>			<1428656099.13172.10.camel@mylittlepony.linaroharston>			<5527E1B9.5030109@oracle.com>			<1429608038.4116.13.camel@mylittlepony.linaroharston>			<55366888.2040409@redhat.com>
	<553669A3.8070205@redhat.com>		 <5536A25C.7060402@oracle.com>	
	<1429695657.29680.7.camel@mylittlepony.linaroharston>	
	<5538A1FD.3060504@redhat.com>
	<1429802030.17540.37.camel@mylittlepony.linaroharston>
	<553921E4.5090408@redhat.com>
Message-ID: <5539416D.8000306@oracle.com>

On 4/23/2015 9:46 AM, Andrew Haley wrote:
> On 04/23/2015 04:13 PM, Edward Nevill wrote:
>> On Thu, 2015-04-23 at 08:40 +0100, Andrew Haley wrote:
>>> On 22/04/15 10:40, Edward Nevill wrote:
>>>> If there is no other feedback shall I prepare a revised patch with R29 marked NS?
>>> I think you should.  I'm as certain as I can be that the GC root-
>>> finding code won't find an OOP saved in R29 and then pushed by
>>> native code.
>> Done.
>>
>> http://cr.openjdk.java.net/~enevill/8075930/webrev.04/
> Please run webrev after committing, so that the webrev is a proper
> changeset.  Please make sure that the jcheck extension is enabled.
>
> http://openjdk.java.net/projects/code-tools/jcheck/
>
>> However I don't believe it makes any difference to the code
>> generated. C2 will still use R29 as a general purpose register, and
>> will still not spill it on a method call (I have checked).
>>
>> I think that in order to do a GC root scan it must be at a safe
>> point and I don't believe it can be at a safe point in native code.
> Sure it can.  Native methods are always safepoints, as are calls to
> the runtime to allocate objects, etc.  But all such calls have a
> wrapper, and it pushes FP, it has an OopMap, so it should be fine.

What happens at a safepoint polling point in a loop?  Will C2 try to 
keep an oop value
in R29 live across the safepoint?  If so, I assume the oopmap takes care 
of that case as
well.

dl

>> In compiled code it uses the OopMaps, unwinds the stack and finds
>> the OOP in R29.
> Okay, I see.
>
> Thanks,
> Andrew.


From david.holmes at oracle.com  Fri Apr 24 07:11:10 2015
From: david.holmes at oracle.com (David Holmes)
Date: Fri, 24 Apr 2015 17:11:10 +1000
Subject: [aarch64-port-dev ] aarch64: jdk9: 8078245: fails to build from
	source
In-Reply-To: <1429607797.4116.11.camel@mylittlepony.linaroharston>
References: <1429607797.4116.11.camel@mylittlepony.linaroharston>
Message-ID: <5539EC8E.1060507@oracle.com>

Hi Ed,

On 21/04/2015 7:16 PM, Edward Nevill wrote:
> Hi,
>
> The current jdk9 tip fails to build from source on aarch64 with the following error message
>
> /home/ed/build/1504/dev/build/linux-aarch64-normal-server-release/support/native/java.desktop/libsplashscreen/pngrutil.o: In function `png_init_filter_functions':
> /home/ed/build/1504/dev/jdk/src/java.desktop/share/native/libsplashscreen/libpng/pngrutil.c:3947: undefined reference to `png_init_filter_functions_neon'
> collect2: error: ld returned 1 exit status
>
> The following webrev gets it building again.
>
> http://cr.openjdk.java.net/~enevill/8078245/webrev.00/

Shouldn't the guard be Aarch64 specific rather than just __arm__ ? I'm 
also wondering how we would get __ARM_NEON defined but not __arm__?

And looking closer at the original code:

154 #  if (defined(__ARM_NEON__) || defined(__ARM_NEON)) && \

we seem to have a stray ) that might be the cause of the problem?

Cheers,
David


Thanks,
David

> Please review and if approved push. See comments below.
>
> Thanks,
> Ed.
>
>
> This was introduced at changeset 11769
>
> changeset:   11769:cb75299d5933
> user:        azvegint
> date:        Mon Jan 19 20:02:31 2015 +0300
> files:       src/java.desktop/share/native/libsplashscreen/libpng/CHANGES src/java.desktop/share/native/libsplashscreen/libpng/LICENSE src/java.desktop/share/native/libsplashscreen/libpng/README src/java.desktop/share/native/libsplashscreen/libpng/png.c src/java.desktop/share/native/libsplashscreen/libpng/png.h src/java.desktop/share/native/libsplashscreen/libpng/pngconf.h src/java.desktop/share/native/libsplashscreen/libpng/pngdebug.h src/java.desktop/share/native/libsplashscreen/libpng/pngerror.c src/java.desktop/share/native/libsplashscreen/libpng/pngget.c src/java.desktop/share/native/libsplashscreen/libpng/pnginfo.h src/java.desktop/share/native/libsplashscreen/libpng/pnglibconf.h src/java.desktop/share/native/libsplashscreen/libpng/pngmem.c src/java.desktop/share/native/libsplashscreen/libpng/pngpread.c src/java.desktop/share/native/libsplashscreen/libpng/pngpriv.h src/java.desktop/share/native/libsplashscreen/libpng/pngread.c src/java.desktop/share/native/libsplashs!
 creen/li
bpng/pngrio.c src/java.desktop/share/native/libsplashscreen/libpng/pngrtran.c src/java.desktop/share/native/libsplashscreen/libpng/pngrutil.c src/java.desktop/share/native/libsplashscreen/libpng/pngset.c src/java.desktop/share/native/libsplashscreen/libpng/pngstruct.h src/java.desktop/share/native/libsplashscreen/libpng/pngtest.c src/java.desktop/share/native/libsplashscreen/libpng/pngtrans.c src/java.desktop/share/native/libsplashscreen/libpng/pngwio.c src/java.desktop/share/native/libsplashscreen/libpng/pngwrite.c src/java.desktop/share/native/libsplashscreen/libpng/pngwtran.c src/java.desktop/share/native/libsplashscreen/libpng/pngwutil.c
> description:
> 8069198: Upgrade image library
> Reviewed-by: ahgross, bae, mschoene, serb
>
> This changeset seems to introduce some ARM Neon optimisations, however I cannot seem to access the associated bug report JDK-8069198 as it seems I do not have suitable privileges to read the report.
>
> The problem is that it is also attempting to build this code for AARCH64 resulting in the above undefined symbol.
>
> The above webrev fixes this by ensuring that it only attempts to compile this code if defined(__arm__)
>
>

From david.holmes at oracle.com  Fri Apr 24 07:15:38 2015
From: david.holmes at oracle.com (David Holmes)
Date: Fri, 24 Apr 2015 17:15:38 +1000
Subject: [aarch64-port-dev ] aarch64: jdk9: 8078245: fails to build from
	source
In-Reply-To: <5539EC8E.1060507@oracle.com>
References: <1429607797.4116.11.camel@mylittlepony.linaroharston>
	<5539EC8E.1060507@oracle.com>
Message-ID: <5539ED9A.5030704@oracle.com>

On 24/04/2015 5:11 PM, David Holmes wrote:
> Hi Ed,
>
> On 21/04/2015 7:16 PM, Edward Nevill wrote:
>> Hi,
>>
>> The current jdk9 tip fails to build from source on aarch64 with the
>> following error message
>>
>> /home/ed/build/1504/dev/build/linux-aarch64-normal-server-release/support/native/java.desktop/libsplashscreen/pngrutil.o:
>> In function `png_init_filter_functions':
>> /home/ed/build/1504/dev/jdk/src/java.desktop/share/native/libsplashscreen/libpng/pngrutil.c:3947:
>> undefined reference to `png_init_filter_functions_neon'
>> collect2: error: ld returned 1 exit status
>>
>> The following webrev gets it building again.
>>
>> http://cr.openjdk.java.net/~enevill/8078245/webrev.00/
>
> Shouldn't the guard be Aarch64 specific rather than just __arm__ ? I'm
> also wondering how we would get __ARM_NEON defined but not __arm__?
>
> And looking closer at the original code:
>
> 154 #  if (defined(__ARM_NEON__) || defined(__ARM_NEON)) && \
>
> we seem to have a stray ) that might be the cause of the problem?

No that's just my eyes playing tricks on me at the end of the week.

David

> Cheers,
> David
>
>
> Thanks,
> David
>
>> Please review and if approved push. See comments below.
>>
>> Thanks,
>> Ed.
>>
>>
>> This was introduced at changeset 11769
>>
>> changeset:   11769:cb75299d5933
>> user:        azvegint
>> date:        Mon Jan 19 20:02:31 2015 +0300
>> files:
>> src/java.desktop/share/native/libsplashscreen/libpng/CHANGES
>> src/java.desktop/share/native/libsplashscreen/libpng/LICENSE
>> src/java.desktop/share/native/libsplashscreen/libpng/README
>> src/java.desktop/share/native/libsplashscreen/libpng/png.c
>> src/java.desktop/share/native/libsplashscreen/libpng/png.h
>> src/java.desktop/share/native/libsplashscreen/libpng/pngconf.h
>> src/java.desktop/share/native/libsplashscreen/libpng/pngdebug.h
>> src/java.desktop/share/native/libsplashscreen/libpng/pngerror.c
>> src/java.desktop/share/native/libsplashscreen/libpng/pngget.c
>> src/java.desktop/share/native/libsplashscreen/libpng/pnginfo.h
>> src/java.desktop/share/native/libsplashscreen/libpng/pnglibconf.h
>> src/java.desktop/share/native/libsplashscreen/libpng/pngmem.c
>> src/java.desktop/share/native/libsplashscreen/libpng/pngpread.c
>> src/java.desktop/share/native/libsplashscreen/libpng/pngpriv.h
>> src/java.desktop/share/native/libsplashscreen/libpng/pngread.c
>> src/java.desktop/share/native/libsplashs!
> creen/li
> bpng/pngrio.c
> src/java.desktop/share/native/libsplashscreen/libpng/pngrtran.c
> src/java.desktop/share/native/libsplashscreen/libpng/pngrutil.c
> src/java.desktop/share/native/libsplashscreen/libpng/pngset.c
> src/java.desktop/share/native/libsplashscreen/libpng/pngstruct.h
> src/java.desktop/share/native/libsplashscreen/libpng/pngtest.c
> src/java.desktop/share/native/libsplashscreen/libpng/pngtrans.c
> src/java.desktop/share/native/libsplashscreen/libpng/pngwio.c
> src/java.desktop/share/native/libsplashscreen/libpng/pngwrite.c
> src/java.desktop/share/native/libsplashscreen/libpng/pngwtran.c
> src/java.desktop/share/native/libsplashscreen/libpng/pngwutil.c
>> description:
>> 8069198: Upgrade image library
>> Reviewed-by: ahgross, bae, mschoene, serb
>>
>> This changeset seems to introduce some ARM Neon optimisations, however
>> I cannot seem to access the associated bug report JDK-8069198 as it
>> seems I do not have suitable privileges to read the report.
>>
>> The problem is that it is also attempting to build this code for
>> AARCH64 resulting in the above undefined symbol.
>>
>> The above webrev fixes this by ensuring that it only attempts to
>> compile this code if defined(__arm__)
>>
>>

From aph at redhat.com  Fri Apr 24 08:33:04 2015
From: aph at redhat.com (Andrew Haley)
Date: Fri, 24 Apr 2015 09:33:04 +0100
Subject: [aarch64-port-dev ] RFR: 8075930: AARCH64: Use FP Register in C2
In-Reply-To: <5539416D.8000306@oracle.com>
References: <1427288528.7353.25.camel@mylittlepony.linaroharston>			<5512B817.3080802@oracle.com>			<1428571873.26527.24.camel@mylittlepony.linaroharston>			<5526B7B1.7000702@oracle.com>			<1428656099.13172.10.camel@mylittlepony.linaroharston>			<5527E1B9.5030109@oracle.com>			<1429608038.4116.13.camel@mylittlepony.linaroharston>			<55366888.2040409@redhat.com>
	<553669A3.8070205@redhat.com>		 <5536A25C.7060402@oracle.com>	
	<1429695657.29680.7.camel@mylittlepony.linaroharston>	
	<5538A1FD.3060504@redhat.com>
	<1429802030.17540.37.camel@mylittlepony.linaroharston>
	<553921E4.5090408@redhat.com> <5539416D.8000306@oracle.com>
Message-ID: <5539FFC0.6080302@redhat.com>

On 23/04/15 20:01, Dean Long wrote:
> On 4/23/2015 9:46 AM, Andrew Haley wrote:
>> On 04/23/2015 04:13 PM, Edward Nevill wrote:
>>>
>>> I think that in order to do a GC root scan it must be at a safe
>>> point and I don't believe it can be at a safe point in native code.
>> Sure it can.  Native methods are always safepoints, as are calls to
>> the runtime to allocate objects, etc.  But all such calls have a
>> wrapper, and it pushes FP, it has an OopMap, so it should be fine.
> 
> What happens at a safepoint polling point in a loop?  Will C2 try to 
> keep an oop value
> in R29 live across the safepoint?  If so, I assume the oopmap takes care 
> of that case as
> well.

I guess so.  Ed's argument that this is the same as EBP on x86 is quite
persuasive to me.

Andrew.



From adinn at redhat.com  Fri Apr 24 08:48:37 2015
From: adinn at redhat.com (Andrew Dinn)
Date: Fri, 24 Apr 2015 09:48:37 +0100
Subject: [aarch64-port-dev ] 8078263: AARCH64: Volatile fields should be
 accessed with ldar and stlr
In-Reply-To: <553923B6.3030407@redhat.com>
References: <5534C0EC.1070005@redhat.com> <5536482F.3020104@redhat.com>
	<553653E8.4020301@redhat.com> <553923B6.3030407@redhat.com>
Message-ID: <553A0365.8080109@redhat.com>

On 23/04/15 17:54, Andrew Haley wrote:
> On 04/21/2015 02:43 PM, Andrew Dinn wrote:
>> On 21/04/15 13:53, Andrew Haley wrote:
>>> On 04/20/2015 10:03 AM, Andrew Dinn wrote:
>>>> The following webrev is submitted for review (n.b. I am not an OpenJDK
>>>> committer so the patch does not yet have an associated JIRA).
>>>
>>> The patch looks good to me.
>>>
>>> https://bugs.openjdk.java.net/browse/JDK-8078263
>>
>> A new webrev with the commit in standard format (listing JIRA#, sumamry
>> and reviewer) and placed at:
>>
>>   http://cr.openjdk.java.net/~adinn/8078263/webrev.01/
> 
> I'm surprised this got past jcheck:

Ah yes, jcheck . . . ahem [enables jcheck]

New webrev which passes jcheck

  http://cr.openjdk.java.net/~adinn/8078263/webrev.02/

regards,


Andrew Dinn
-----------
Senior Principal Software Engineer
Red Hat UK Ltd
Registered in UK and Wales under Company Registration No. 3798903
Directors: Michael Cunningham (USA), Matt Parson (USA), Charlie Peters
(USA), Michael O'Neill (Ireland)

From aph at redhat.com  Fri Apr 24 09:23:12 2015
From: aph at redhat.com (Andrew Haley)
Date: Fri, 24 Apr 2015 10:23:12 +0100
Subject: [aarch64-port-dev ] 8078263: AARCH64: Volatile fields should be
 accessed with ldar and stlr
In-Reply-To: <553A0365.8080109@redhat.com>
References: <5534C0EC.1070005@redhat.com> <5536482F.3020104@redhat.com>
	<553653E8.4020301@redhat.com> <553923B6.3030407@redhat.com>
	<553A0365.8080109@redhat.com>
Message-ID: <553A0B80.801@redhat.com>

On 24/04/15 09:48, Andrew Dinn wrote:
> Ah yes, jcheck . . . ahem [enables jcheck]
> 
> New webrev which passes jcheck
> 
>   http://cr.openjdk.java.net/~adinn/8078263/webrev.02/

'salright, I already pushed it.  :-)

Andrew.


From edward.nevill at linaro.org  Fri Apr 24 11:10:33 2015
From: edward.nevill at linaro.org (Edward Nevill)
Date: Fri, 24 Apr 2015 12:10:33 +0100
Subject: [aarch64-port-dev ] RFR: 8075930: AARCH64: Use FP Register in C2
In-Reply-To: <553921E4.5090408@redhat.com>
References: <1427288528.7353.25.camel@mylittlepony.linaroharston>
	<5512B817.3080802@oracle.com>
	<1428571873.26527.24.camel@mylittlepony.linaroharston>
	<5526B7B1.7000702@oracle.com>
	<1428656099.13172.10.camel@mylittlepony.linaroharston>
	<5527E1B9.5030109@oracle.com>
	<1429608038.4116.13.camel@mylittlepony.linaroharston>
	<55366888.2040409@redhat.com> <553669A3.8070205@redhat.com>
	<5536A25C.7060402@oracle.com>
	<1429695657.29680.7.camel@mylittlepony.linaroharston>
	<5538A1FD.3060504@redhat.com>
	<1429802030.17540.37.camel@mylittlepony.linaroharston>
	<553921E4.5090408@redhat.com>
Message-ID: <CAEf2cjeEbFP7keT+ErScv15Q+b73GR+nZgLN58KSz3rc9P7ahA@mail.gmail.com>

On 23 April 2015 at 17:46, Andrew Haley <aph at redhat.com> wrote:

> On 04/23/2015 04:13 PM, Edward Nevill wrote:
> > On Thu, 2015-04-23 at 08:40 +0100, Andrew Haley wrote:
> >> On 22/04/15 10:40, Edward Nevill wrote:
> >>> If there is no other feedback shall I prepare a revised patch with R29
> marked NS?
> >
> > http://cr.openjdk.java.net/~enevill/8075930/webrev.04/
>
> Please run webrev after committing, so that the webrev is a proper
> changeset.  Please make sure that the jcheck extension is enabled.
>
> http://openjdk.java.net/projects/code-tools/jcheck/
>

Done. New webrev @

http://cr.openjdk.java.net/~enevill/8075930/webrev.05

All the best,
Ed.

From edward.nevill at linaro.org  Fri Apr 24 11:35:31 2015
From: edward.nevill at linaro.org (Edward Nevill)
Date: Fri, 24 Apr 2015 12:35:31 +0100
Subject: [aarch64-port-dev ] RFR: 8075930: AARCH64: Use FP Register in C2
In-Reply-To: <5539416D.8000306@oracle.com>
References: <1427288528.7353.25.camel@mylittlepony.linaroharston>
	<5512B817.3080802@oracle.com>
	<1428571873.26527.24.camel@mylittlepony.linaroharston>
	<5526B7B1.7000702@oracle.com>
	<1428656099.13172.10.camel@mylittlepony.linaroharston>
	<5527E1B9.5030109@oracle.com>
	<1429608038.4116.13.camel@mylittlepony.linaroharston>
	<55366888.2040409@redhat.com> <553669A3.8070205@redhat.com>
	<5536A25C.7060402@oracle.com>
	<1429695657.29680.7.camel@mylittlepony.linaroharston>
	<5538A1FD.3060504@redhat.com>
	<1429802030.17540.37.camel@mylittlepony.linaroharston>
	<553921E4.5090408@redhat.com> <5539416D.8000306@oracle.com>
Message-ID: <CAEf2cjdHz-ZnfFVCROo4U+-YFskX6XTeTS7Cd8Kv2x_-xASNgA@mail.gmail.com>

On 23 April 2015 at 20:01, Dean Long <dean.long at oracle.com> wrote:

>
> What happens at a safepoint polling point in a loop?  Will C2 try to keep
> an oop value
> in R29 live across the safepoint?  If so, I assume the oopmap takes care
> of that case as
> well.


Yes. Here is an example of an OopMap at a safepoint in a loop

   0x000003ff710efa1c: adrp      x10, 0x000003ff79830000
                                                ; OopMap{r14=Oop off=160}
                                                ;*goto
                                                ; - MethodAtom::execute at 46
(line 35)
                                                ;   {poll}
  0x000003ff710efa20: ldr       wzr, [x10]      ;*goto
                                                ; - MethodAtom::execute at 46
(line 35)
                                                ;   {poll}
  0x000003ff710efa24: ldr       w10, [x14,#16]
  0x000003ff710efa28: cmp       w16, w10
  0x000003ff710efa2c: b.ge      0x000003ff710efb74  ;*aload_0
                                                ; - MethodAtom::execute at 12
(line 37)

All the best,
Ed.

From dean.long at oracle.com  Fri Apr 24 22:22:41 2015
From: dean.long at oracle.com (Dean Long)
Date: Fri, 24 Apr 2015 15:22:41 -0700
Subject: [aarch64-port-dev ] RFR: 8075930: AARCH64: Use FP Register in C2
In-Reply-To: <CAEf2cjdHz-ZnfFVCROo4U+-YFskX6XTeTS7Cd8Kv2x_-xASNgA@mail.gmail.com>
References: <1427288528.7353.25.camel@mylittlepony.linaroharston>	<5512B817.3080802@oracle.com>	<1428571873.26527.24.camel@mylittlepony.linaroharston>	<5526B7B1.7000702@oracle.com>	<1428656099.13172.10.camel@mylittlepony.linaroharston>	<5527E1B9.5030109@oracle.com>	<1429608038.4116.13.camel@mylittlepony.linaroharston>	<55366888.2040409@redhat.com>	<553669A3.8070205@redhat.com>	<5536A25C.7060402@oracle.com>	<1429695657.29680.7.camel@mylittlepony.linaroharston>	<5538A1FD.3060504@redhat.com>	<1429802030.17540.37.camel@mylittlepony.linaroharston>	<553921E4.5090408@redhat.com>	<5539416D.8000306@oracle.com>
	<CAEf2cjdHz-ZnfFVCROo4U+-YFskX6XTeTS7Cd8Kv2x_-xASNgA@mail.gmail.com>
Message-ID: <553AC231.4090103@oracle.com>

On 4/24/2015 4:35 AM, Edward Nevill wrote:
>
>
> On 23 April 2015 at 20:01, Dean Long <dean.long at oracle.com 
> <mailto:dean.long at oracle.com>> wrote:
>
>
>     What happens at a safepoint polling point in a loop?  Will C2 try
>     to keep an oop value
>     in R29 live across the safepoint?  If so, I assume the oopmap
>     takes care of that case as
>     well.
>
>
> Yes. Here is an example of an OopMap at a safepoint in a loop
>
>    0x000003ff710efa1c: adrp      x10, 0x000003ff79830000
>                                                 ; OopMap{r14=Oop off=160}
>                                                 ;*goto
>                                                 ; - 
> MethodAtom::execute at 46 (line 35)
>                                                 ;   {poll}
>   0x000003ff710efa20: ldr       wzr, [x10]      ;*goto
>                                                 ; - 
> MethodAtom::execute at 46 (line 35)
>                                                 ;   {poll}
>   0x000003ff710efa24: ldr       w10, [x14,#16]
>   0x000003ff710efa28: cmp       w16, w10
>   0x000003ff710efa2c: b.ge <http://b.ge>      0x000003ff710efb74 ;*aload_0
>                                                 ; - 
> MethodAtom::execute at 12 (line 37)
>
> All the best,
> Ed.
>

I was expecting to see r29=Oop, but if it works for x86 I don't see why 
it wouldn't work for aarch64.

dl

From alexander.alexeev at auriga.com  Mon Apr 27 14:56:30 2015
From: alexander.alexeev at auriga.com (Alexeev, Alexander)
Date: Mon, 27 Apr 2015 14:56:30 +0000
Subject: [aarch64-port-dev ] JDK9 Hotspot test failures (was RE:
	One	other thing)
In-Reply-To: <840A7E9DC095B04FA87BF37DDD9D1CF984A741@HQ-MS1.office.auriga.msk>
References: <840A7E9DC095B04FA87BF37DDD9D1CF984A05C@HQ-MS1.office.auriga.msk>
	<55364490.4000906@redhat.com>
	<840A7E9DC095B04FA87BF37DDD9D1CF984A237@HQ-MS1.office.auriga.msk>
	<CAEf2cjctjXiecC6+1hEbioa3tyWO3SX8HpWuOvdvUDea-PLTjA@mail.gmail.com>
	<840A7E9DC095B04FA87BF37DDD9D1CF984A507@HQ-MS1.office.auriga.msk>
	<1429722387.30593.9.camel@mylittlepony.linaroharston>
	<840A7E9DC095B04FA87BF37DDD9D1CF984A5CC@HQ-MS1.office.auriga.msk>
	,<CAEf2cjd3e5t9Cg7wHFtU3pYw1fX2qzA-0F6K8bz5N6f=E-siTA@mail.gmail.com>
	<840A7E9DC095B04FA87BF37DDD9D1CF984A6BF@HQ-MS1.office.auriga.msk>,
	<1429783677.13276.15.camel@mylittlepony.linaroharston>,
	<840A7E9DC095B04FA87BF37DDD9D1CF984A741@HQ-MS1.office.auriga.msk>
Message-ID: <840A7E9DC095B04FA87BF37DDD9D1CF984AAC9@HQ-MS1.office.auriga.msk>

Ed, for majority of tests fixes are ready, only six left. I will do that later. 
The current questions are:
- Should it be single bug/patch or several, one for every type of problem?
- Should your fix from JDK8 ported somehow specially or just as ordinary patch?
- Who will open bugs and be a sponsor if necessary?
- While I am skeptical that this fix affect x86 somehow, bu anyway should I rerun teststuite on x86?  
 
Patch that includes all fixes is attached. It is mainly trivial. But anyway I believe there are room for feedback.

Regards,
Alexander
________________________________________
From: aarch64-port-dev [aarch64-port-dev-bounces at openjdk.java.net] on behalf of Alexeev, Alexander [alexander.alexeev at auriga.com]
Sent: 23 April 2015 16:06
To: edward.nevill at linaro.org; aarch64-port-dev at openjdk.java.net
Cc: Jasty, Ananth
Subject: Re: [aarch64-port-dev ] JDK9 Hotspot test failures (was RE: One        other thing)

 > If you feel like going through the remaining 33 failures and preparing a patch or patches for submission to jdk9 that would be most useful, otherwise I will add it to my todo list.

I will do that.
________________________________________
From: Edward Nevill [edward.nevill at linaro.org]
Sent: 23 April 2015 13:07
To: aarch64-port-dev at openjdk.java.net
Cc: Andrew Haley; Jasty, Ananth; Alexeev, Alexander
Subject: JDK9 Hotspot test failures (was RE: One other thing)

Hi Alexander,

I have moved this discussion to aarch-port-dev.

On Wed, 2015-04-22 at 19:51 +0000, Alexeev, Alexander wrote:
> Again no luck
>
> Test results: passed: 772; failed: 34; error: 22
>
> hg clone http://hg.openjdk.java.net/jdk9/dev
> hg clone http://hg.openjdk.java.net/jdk9/dev/hotspot
> ...
> + subfolders
>

Sorry, my bad. I am now seeing

Test results: passed: 778; failed: 33; error: 1

Of the 33 failures most of these seem to be test failures rather than hotspot failures.

For example, I believe I fixed all of these in jdk8

FAILED: compiler/stable/TestStableBoolean.java
FAILED: compiler/stable/TestStableByte.java
FAILED: compiler/stable/TestStableDouble.java
FAILED: compiler/stable/TestStableChar.java
FAILED: compiler/stable/TestStableLong.java
FAILED: compiler/stable/TestStableInt.java
FAILED: compiler/stable/TestStableShort.java
FAILED: compiler/stable/TestStableObject.java
FAILED: compiler/stable/TestStableFloat.java

>From the jdk8 log

changeset:   7554:68cf8e406ce5
user:        Edward Nevill edward.nevill at linaro.org
date:        Wed Sep 24 12:56:10 2014 +0100
files:       test/compiler/stable/StableConfiguration.java
description:
Fix failing TestStable tests

However, it would seem these changes did not make it through to jdk9.

If you feel like going through the remaining 33 failures and preparing a patch or patches for submission to jdk9 that would be most useful, otherwise I will add it to my todo list.

For reference here is the list of test failures I am now seeing. The ones marked (*) I believe were fixed in jdk8.

FAILED: compiler/codegen/7184394/TestAESMain.java
FAILED: compiler/intrinsics/classcast/NullCheckDroppingsTest.java
* FAILED: compiler/intrinsics/mathexact/sanity/MultiplyExactIntTest.java
* FAILED: compiler/intrinsics/mathexact/sanity/IncrementExactIntTest.java
* FAILED: compiler/intrinsics/mathexact/sanity/DecrementExactIntTest.java
* FAILED: compiler/intrinsics/mathexact/sanity/AddExactIntTest.java
* FAILED: compiler/intrinsics/mathexact/sanity/DecrementExactLongTest.java
* FAILED: compiler/intrinsics/mathexact/sanity/MultiplyExactLongTest.java
* FAILED: compiler/intrinsics/mathexact/sanity/NegateExactIntTest.java
* FAILED: compiler/intrinsics/mathexact/sanity/IncrementExactLongTest.java
* FAILED: compiler/intrinsics/mathexact/sanity/SubtractExactIntTest.java
* FAILED: compiler/intrinsics/mathexact/sanity/AddExactLongTest.java
* FAILED: compiler/intrinsics/mathexact/sanity/NegateExactLongTest.java
* FAILED: compiler/intrinsics/mathexact/sanity/SubtractExactLongTest.java
* FAILED: compiler/intrinsics/sha/cli/TestUseSHA256IntrinsicsOptionOnUnsupportedCPU.java
* FAILED: compiler/intrinsics/sha/cli/TestUseSHAOptionOnUnsupportedCPU.java
* FAILED: compiler/intrinsics/sha/cli/TestUseSHA1IntrinsicsOptionOnUnsupportedCPU.java
* FAILED: compiler/intrinsics/sha/sanity/TestSHA1MultiBlockIntrinsics.java
* FAILED: compiler/intrinsics/sha/sanity/TestSHA1Intrinsics.java
* FAILED: compiler/intrinsics/sha/sanity/TestSHA256Intrinsics.java
* FAILED: compiler/intrinsics/sha/sanity/TestSHA256MultiBlockIntrinsics.java
* FAILED: compiler/stable/TestStableBoolean.java
* FAILED: compiler/stable/TestStableByte.java
* FAILED: compiler/stable/TestStableDouble.java
* FAILED: compiler/stable/TestStableChar.java
* FAILED: compiler/stable/TestStableLong.java
* FAILED: compiler/stable/TestStableInt.java
* FAILED: compiler/stable/TestStableShort.java
* FAILED: compiler/stable/TestStableObject.java
* FAILED: compiler/stable/TestStableFloat.java
FAILED: compiler/whitebox/DeoptimizeFramesTest.java
FAILED: runtime/CommandLine/TestVMOptions.java
FAILED: testlibrary_tests/TestMutuallyExclusivePlatformPredicates.java



From alexander.alexeev at auriga.com  Mon Apr 27 18:44:58 2015
From: alexander.alexeev at auriga.com (Alexeev, Alexander)
Date: Mon, 27 Apr 2015 18:44:58 +0000
Subject: [aarch64-port-dev ] JDK9 Hotspot test failures (was
	RE:	One	other thing)
In-Reply-To: <840A7E9DC095B04FA87BF37DDD9D1CF984AAC9@HQ-MS1.office.auriga.msk>
References: <840A7E9DC095B04FA87BF37DDD9D1CF984A05C@HQ-MS1.office.auriga.msk>
	<55364490.4000906@redhat.com>
	<840A7E9DC095B04FA87BF37DDD9D1CF984A237@HQ-MS1.office.auriga.msk>
	<CAEf2cjctjXiecC6+1hEbioa3tyWO3SX8HpWuOvdvUDea-PLTjA@mail.gmail.com>
	<840A7E9DC095B04FA87BF37DDD9D1CF984A507@HQ-MS1.office.auriga.msk>
	<1429722387.30593.9.camel@mylittlepony.linaroharston>
	<840A7E9DC095B04FA87BF37DDD9D1CF984A5CC@HQ-MS1.office.auriga.msk>
	,<CAEf2cjd3e5t9Cg7wHFtU3pYw1fX2qzA-0F6K8bz5N6f=E-siTA@mail.gmail.com>
	<840A7E9DC095B04FA87BF37DDD9D1CF984A6BF@HQ-MS1.office.auriga.msk>,
	<1429783677.13276.15.camel@mylittlepony.linaroharston>,
	<840A7E9DC095B04FA87BF37DDD9D1CF984A741@HQ-MS1.office.auriga.msk>,
	<840A7E9DC095B04FA87BF37DDD9D1CF984AAC9@HQ-MS1.office.auriga.msk>
Message-ID: <840A7E9DC095B04FA87BF37DDD9D1CF984ABD3@HQ-MS1.office.auriga.msk>

The second attempt to send attach. 
________________________________________
From: aarch64-port-dev [aarch64-port-dev-bounces at openjdk.java.net] on behalf of Alexeev, Alexander [alexander.alexeev at auriga.com]
Sent: 27 April 2015 17:56
To: edward.nevill at linaro.org; aarch64-port-dev at openjdk.java.net
Subject: Re: [aarch64-port-dev ] JDK9 Hotspot test failures (was RE:    One     other thing)

Ed, for majority of tests fixes are ready, only six left. I will do that later.
The current questions are:
- Should it be single bug/patch or several, one for every type of problem?
- Should your fix from JDK8 ported somehow specially or just as ordinary patch?
- Who will open bugs and be a sponsor if necessary?
- While I am skeptical that this fix affect x86 somehow, bu anyway should I rerun teststuite on x86?

Patch that includes all fixes is attached. It is mainly trivial. But anyway I believe there are room for feedback.

Regards,
Alexander
________________________________________
From: aarch64-port-dev [aarch64-port-dev-bounces at openjdk.java.net] on behalf of Alexeev, Alexander [alexander.alexeev at auriga.com]
Sent: 23 April 2015 16:06
To: edward.nevill at linaro.org; aarch64-port-dev at openjdk.java.net
Cc: Jasty, Ananth
Subject: Re: [aarch64-port-dev ] JDK9 Hotspot test failures (was RE: One        other thing)

 > If you feel like going through the remaining 33 failures and preparing a patch or patches for submission to jdk9 that would be most useful, otherwise I will add it to my todo list.

I will do that.
________________________________________
From: Edward Nevill [edward.nevill at linaro.org]
Sent: 23 April 2015 13:07
To: aarch64-port-dev at openjdk.java.net
Cc: Andrew Haley; Jasty, Ananth; Alexeev, Alexander
Subject: JDK9 Hotspot test failures (was RE: One other thing)

Hi Alexander,

I have moved this discussion to aarch-port-dev.

On Wed, 2015-04-22 at 19:51 +0000, Alexeev, Alexander wrote:
> Again no luck
>
> Test results: passed: 772; failed: 34; error: 22
>
> hg clone http://hg.openjdk.java.net/jdk9/dev
> hg clone http://hg.openjdk.java.net/jdk9/dev/hotspot
> ...
> + subfolders
>

Sorry, my bad. I am now seeing

Test results: passed: 778; failed: 33; error: 1

Of the 33 failures most of these seem to be test failures rather than hotspot failures.

For example, I believe I fixed all of these in jdk8

FAILED: compiler/stable/TestStableBoolean.java
FAILED: compiler/stable/TestStableByte.java
FAILED: compiler/stable/TestStableDouble.java
FAILED: compiler/stable/TestStableChar.java
FAILED: compiler/stable/TestStableLong.java
FAILED: compiler/stable/TestStableInt.java
FAILED: compiler/stable/TestStableShort.java
FAILED: compiler/stable/TestStableObject.java
FAILED: compiler/stable/TestStableFloat.java

>From the jdk8 log

changeset:   7554:68cf8e406ce5
user:        Edward Nevill edward.nevill at linaro.org
date:        Wed Sep 24 12:56:10 2014 +0100
files:       test/compiler/stable/StableConfiguration.java
description:
Fix failing TestStable tests

However, it would seem these changes did not make it through to jdk9.

If you feel like going through the remaining 33 failures and preparing a patch or patches for submission to jdk9 that would be most useful, otherwise I will add it to my todo list.

For reference here is the list of test failures I am now seeing. The ones marked (*) I believe were fixed in jdk8.

FAILED: compiler/codegen/7184394/TestAESMain.java
FAILED: compiler/intrinsics/classcast/NullCheckDroppingsTest.java
* FAILED: compiler/intrinsics/mathexact/sanity/MultiplyExactIntTest.java
* FAILED: compiler/intrinsics/mathexact/sanity/IncrementExactIntTest.java
* FAILED: compiler/intrinsics/mathexact/sanity/DecrementExactIntTest.java
* FAILED: compiler/intrinsics/mathexact/sanity/AddExactIntTest.java
* FAILED: compiler/intrinsics/mathexact/sanity/DecrementExactLongTest.java
* FAILED: compiler/intrinsics/mathexact/sanity/MultiplyExactLongTest.java
* FAILED: compiler/intrinsics/mathexact/sanity/NegateExactIntTest.java
* FAILED: compiler/intrinsics/mathexact/sanity/IncrementExactLongTest.java
* FAILED: compiler/intrinsics/mathexact/sanity/SubtractExactIntTest.java
* FAILED: compiler/intrinsics/mathexact/sanity/AddExactLongTest.java
* FAILED: compiler/intrinsics/mathexact/sanity/NegateExactLongTest.java
* FAILED: compiler/intrinsics/mathexact/sanity/SubtractExactLongTest.java
* FAILED: compiler/intrinsics/sha/cli/TestUseSHA256IntrinsicsOptionOnUnsupportedCPU.java
* FAILED: compiler/intrinsics/sha/cli/TestUseSHAOptionOnUnsupportedCPU.java
* FAILED: compiler/intrinsics/sha/cli/TestUseSHA1IntrinsicsOptionOnUnsupportedCPU.java
* FAILED: compiler/intrinsics/sha/sanity/TestSHA1MultiBlockIntrinsics.java
* FAILED: compiler/intrinsics/sha/sanity/TestSHA1Intrinsics.java
* FAILED: compiler/intrinsics/sha/sanity/TestSHA256Intrinsics.java
* FAILED: compiler/intrinsics/sha/sanity/TestSHA256MultiBlockIntrinsics.java
* FAILED: compiler/stable/TestStableBoolean.java
* FAILED: compiler/stable/TestStableByte.java
* FAILED: compiler/stable/TestStableDouble.java
* FAILED: compiler/stable/TestStableChar.java
* FAILED: compiler/stable/TestStableLong.java
* FAILED: compiler/stable/TestStableInt.java
* FAILED: compiler/stable/TestStableShort.java
* FAILED: compiler/stable/TestStableObject.java
* FAILED: compiler/stable/TestStableFloat.java
FAILED: compiler/whitebox/DeoptimizeFramesTest.java
FAILED: runtime/CommandLine/TestVMOptions.java
FAILED: testlibrary_tests/TestMutuallyExclusivePlatformPredicates.java



From edward.nevill at linaro.org  Tue Apr 28 09:44:16 2015
From: edward.nevill at linaro.org (Edward Nevill)
Date: Tue, 28 Apr 2015 10:44:16 +0100
Subject: [aarch64-port-dev ] JDK9 Hotspot test failures (was RE: One
 other thing)
In-Reply-To: <840A7E9DC095B04FA87BF37DDD9D1CF984AAC9@HQ-MS1.office.auriga.msk>
References: <840A7E9DC095B04FA87BF37DDD9D1CF984A05C@HQ-MS1.office.auriga.msk>
	<55364490.4000906@redhat.com>
	<840A7E9DC095B04FA87BF37DDD9D1CF984A237@HQ-MS1.office.auriga.msk>
	<CAEf2cjctjXiecC6+1hEbioa3tyWO3SX8HpWuOvdvUDea-PLTjA@mail.gmail.com>
	<840A7E9DC095B04FA87BF37DDD9D1CF984A507@HQ-MS1.office.auriga.msk>
	<1429722387.30593.9.camel@mylittlepony.linaroharston>
	<840A7E9DC095B04FA87BF37DDD9D1CF984A5CC@HQ-MS1.office.auriga.msk>
	,<CAEf2cjd3e5t9Cg7wHFtU3pYw1fX2qzA-0F6K8bz5N6f=E-siTA@mail.gmail.com>
	<840A7E9DC095B04FA87BF37DDD9D1CF984A6BF@HQ-MS1.office.auriga.msk>
	, <1429783677.13276.15.camel@mylittlepony.linaroharston>
	,<840A7E9DC095B04FA87BF37DDD9D1CF984A741@HQ-MS1.office.auriga.msk>
	<840A7E9DC095B04FA87BF37DDD9D1CF984AAC9@HQ-MS1.office.auriga.msk>
Message-ID: <1430214256.5304.18.camel@mylittlepony.linaroharston>

On Mon, 2015-04-27 at 14:56 +0000, Alexeev, Alexander wrote:
> Ed, for majority of tests fixes are ready, only six left. I will do that later. 
> The current questions are:
> - Should it be single bug/patch or several, one for every type of problem?

Lets try to push them all through in one go. If anyone objects we can
split out any problematical ones.

> - Should your fix from JDK8 ported somehow specially or just as ordinary patch?

Use webrev. See below.

> - Who will open bugs and be a sponsor if necessary?

I will. I have created a JIRA issue

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

> - While I am skeptical that this fix affect x86 somehow, bu anyway should I rerun teststuite on x86?

Yes.
 
> Patch that includes all fixes is attached. It is mainly trivial. But anyway I believe there are room for feedback.

You cannot post attachments to the mailing list. Please use webrev to create your patch. See

http://openjdk.java.net/guide/webrevHelp.html

Commit your patch before using webrev. Then you should just be able to do

webrev -c <bugid>

where <bugid> is the JIRA bug id, in this case 8078738.

When committing your changeset please ensure the comment follows the correct format. See

http://openjdk.java.net/guide/producingChangeset.html#changesetComment

Finally, please enable jcheck. This will ensure that everything is formatted correctly in the patch. See

http://openjdk.java.net/projects/code-tools/jcheck/

Once your webrev is ready for review you should push it to cr.openjdk.java.net. See

http://openjdk.java.net/guide/codeReview.html

You will need to create an account on cr.openjdk.java.net. I believe you should be able to create an account. If not, put the webrev somewhere else, or email it to me and I will push it.

All the best,
Ed.



From edward.nevill at linaro.org  Tue Apr 28 14:43:45 2015
From: edward.nevill at linaro.org (Edward Nevill)
Date: Tue, 28 Apr 2015 15:43:45 +0100
Subject: [aarch64-port-dev ] RFR: 8075930: AARCH64: Use FP Register in C2
In-Reply-To: <553AC231.4090103@oracle.com>
References: <1427288528.7353.25.camel@mylittlepony.linaroharston>
	<5512B817.3080802@oracle.com>
	<1428571873.26527.24.camel@mylittlepony.linaroharston>
	<5526B7B1.7000702@oracle.com>
	<1428656099.13172.10.camel@mylittlepony.linaroharston>
	<5527E1B9.5030109@oracle.com>
	<1429608038.4116.13.camel@mylittlepony.linaroharston>
	<55366888.2040409@redhat.com>	<553669A3.8070205@redhat.com>
	<5536A25C.7060402@oracle.com>
	<1429695657.29680.7.camel@mylittlepony.linaroharston>
	<5538A1FD.3060504@redhat.com>
	<1429802030.17540.37.camel@mylittlepony.linaroharston>
	<553921E4.5090408@redhat.com>	<5539416D.8000306@oracle.com>
	<CAEf2cjdHz-ZnfFVCROo4U+-YFskX6XTeTS7Cd8Kv2x_-xASNgA@mail.gmail.com>
	<553AC231.4090103@oracle.com>
Message-ID: <1430232225.8394.23.camel@mylittlepony.linaroharston>

On Fri, 2015-04-24 at 15:22 -0700, Dean Long wrote:
> On 4/24/2015 4:35 AM, Edward Nevill wrote:
> > 
> > 
> > On 23 April 2015 at 20:01, Dean Long <dean.long at oracle.com> wrote:

> I was expecting to see r29=Oop, but if it works for x86 I don't see why it wouldn't work for aarch64.
> 
> dl

Hi Dean,

Thanks for this. It was just an example of an OopMap at a safepoint.

However, when I tried to generate a case where it would put R29 into an OopMap and I found I could not. On investigation I found a separate 'reg_class' in aarch64.ad

// Class for all non_special pointer registers
reg_class no_special_ptr_reg(
...
);

which is used for all normal pointers. Unfortunately I had not included R29 in this reg_class, therefore it was never using R29 for a pointer, only for integral values. When I put R29 in this reg_class I get for example.

  0x000003ffa83d7ba4: mov       x29, x13
  0x000003ffa83d7ba8: mov       x1, x13
  0x000003ffa83d7bac: mov       x2, x11
  0x000003ffa83d7bb0: mov       w3, wzr
  0x000003ffa83d7bb4: ldr       w4, [sp,#4]
  0x000003ffa83d7bb8: bl        0x000003ffa80b2300  ; OopMap{rfp=Oop [8]=Oop off=636}
-------------------------------------------------------------^^^^^^^
                                                ;*invokespecial get
                                                ; - java.nio.DirectByteBuffer::get at 117 (line 285)
                                                ; - java.nio.ByteBuffer::get at 5 (line 715)
                                                ; - jdk.internal.jimage.ImageStrings::get at 117 (line 90)
                                                ;   {optimized virtual_call}
  0x000003ffa83d7bbc: mov       x12, x29
  0x000003ffa83d7bc0: ldr       w10, [x12,#12]  ;*getfield mark

It would seem that the patch has already been pushed so I will raise a new JIRA issue and a new patch to include R29 in the no_special_ptr_reg class.

Thanks for your help spotting this!,
Ed.



From dean.long at oracle.com  Tue Apr 28 17:07:07 2015
From: dean.long at oracle.com (Dean Long)
Date: Tue, 28 Apr 2015 10:07:07 -0700
Subject: [aarch64-port-dev ] RFR: 8075930: AARCH64: Use FP Register in C2
In-Reply-To: <1430232225.8394.23.camel@mylittlepony.linaroharston>
References: <1427288528.7353.25.camel@mylittlepony.linaroharston>		<5512B817.3080802@oracle.com>		<1428571873.26527.24.camel@mylittlepony.linaroharston>		<5526B7B1.7000702@oracle.com>		<1428656099.13172.10.camel@mylittlepony.linaroharston>		<5527E1B9.5030109@oracle.com>		<1429608038.4116.13.camel@mylittlepony.linaroharston>		<55366888.2040409@redhat.com>	<553669A3.8070205@redhat.com>		<5536A25C.7060402@oracle.com>		<1429695657.29680.7.camel@mylittlepony.linaroharston>		<5538A1FD.3060504@redhat.com>		<1429802030.17540.37.camel@mylittlepony.linaroharston>		<553921E4.5090408@redhat.com>	<5539416D.8000306@oracle.com>	
	<CAEf2cjdHz-ZnfFVCROo4U+-YFskX6XTeTS7Cd8Kv2x_-xASNgA@mail.gmail.com>	
	<553AC231.4090103@oracle.com>
	<1430232225.8394.23.camel@mylittlepony.linaroharston>
Message-ID: <553FBE3B.8030802@oracle.com>

On 4/28/2015 7:43 AM, Edward Nevill wrote:
> On Fri, 2015-04-24 at 15:22 -0700, Dean Long wrote:
>> On 4/24/2015 4:35 AM, Edward Nevill wrote:
>>>
>>> On 23 April 2015 at 20:01, Dean Long <dean.long at oracle.com> wrote:
>> I was expecting to see r29=Oop, but if it works for x86 I don't see why it wouldn't work for aarch64.
>>
>> dl
> Hi Dean,
>
> Thanks for this. It was just an example of an OopMap at a safepoint.
>
> However, when I tried to generate a case where it would put R29 into an OopMap and I found I could not. On investigation I found a separate 'reg_class' in aarch64.ad
>
> // Class for all non_special pointer registers
> reg_class no_special_ptr_reg(
> ...
> );
>
> which is used for all normal pointers. Unfortunately I had not included R29 in this reg_class, therefore it was never using R29 for a pointer, only for integral values. When I put R29 in this reg_class I get for example.
>
>    0x000003ffa83d7ba4: mov       x29, x13
>    0x000003ffa83d7ba8: mov       x1, x13
>    0x000003ffa83d7bac: mov       x2, x11
>    0x000003ffa83d7bb0: mov       w3, wzr
>    0x000003ffa83d7bb4: ldr       w4, [sp,#4]
>    0x000003ffa83d7bb8: bl        0x000003ffa80b2300  ; OopMap{rfp=Oop [8]=Oop off=636}
> -------------------------------------------------------------^^^^^^^
>                                                  ;*invokespecial get
>                                                  ; - java.nio.DirectByteBuffer::get at 117 (line 285)
>                                                  ; - java.nio.ByteBuffer::get at 5 (line 715)
>                                                  ; - jdk.internal.jimage.ImageStrings::get at 117 (line 90)
>                                                  ;   {optimized virtual_call}
>    0x000003ffa83d7bbc: mov       x12, x29
>    0x000003ffa83d7bc0: ldr       w10, [x12,#12]  ;*getfield mark
>
> It would seem that the patch has already been pushed so I will raise a new JIRA issue and a new patch to include R29 in the no_special_ptr_reg class.
>
> Thanks for your help spotting this!,
> Ed.
>

Sounds good.

dl



From aph at redhat.com  Tue Apr 28 17:09:04 2015
From: aph at redhat.com (Andrew Haley)
Date: Tue, 28 Apr 2015 18:09:04 +0100
Subject: [aarch64-port-dev ] RFR: 8075930: AARCH64: Use FP Register in C2
In-Reply-To: <1430232225.8394.23.camel@mylittlepony.linaroharston>
References: <1427288528.7353.25.camel@mylittlepony.linaroharston>		<5512B817.3080802@oracle.com>		<1428571873.26527.24.camel@mylittlepony.linaroharston>		<5526B7B1.7000702@oracle.com>		<1428656099.13172.10.camel@mylittlepony.linaroharston>		<5527E1B9.5030109@oracle.com>		<1429608038.4116.13.camel@mylittlepony.linaroharston>		<55366888.2040409@redhat.com>	<553669A3.8070205@redhat.com>		<5536A25C.7060402@oracle.com>		<1429695657.29680.7.camel@mylittlepony.linaroharston>		<5538A1FD.3060504@redhat.com>		<1429802030.17540.37.camel@mylittlepony.linaroharston>		<553921E4.5090408@redhat.com>	<5539416D.8000306@oracle.com>	
	<CAEf2cjdHz-ZnfFVCROo4U+-YFskX6XTeTS7Cd8Kv2x_-xASNgA@mail.gmail.com>	
	<553AC231.4090103@oracle.com>
	<1430232225.8394.23.camel@mylittlepony.linaroharston>
Message-ID: <553FBEB0.9040907@redhat.com>

On 04/28/2015 03:43 PM, Edward Nevill wrote:
> It would seem that the patch has already been pushed so I will raise a new JIRA issue and a new patch to include R29 in the no_special_ptr_reg class.

And this means the first patch has never really been tested.  We'll see
what happens...

Andrew.


From edward.nevill at linaro.org  Wed Apr 29 10:52:30 2015
From: edward.nevill at linaro.org (Edward Nevill)
Date: Wed, 29 Apr 2015 11:52:30 +0100
Subject: [aarch64-port-dev ] aarch64: jdk9: 8078245: fails to build from
	source
In-Reply-To: <5539EC8E.1060507@oracle.com>
References: <1429607797.4116.11.camel@mylittlepony.linaroharston>
	<5539EC8E.1060507@oracle.com>
Message-ID: <1430304750.8394.56.camel@mylittlepony.linaroharston>

On Fri, 2015-04-24 at 17:11 +1000, David Holmes wrote:
> Hi Ed,
> 
> On 21/04/2015 7:16 PM, Edward Nevill wrote:
> > Hi,
> >
> > The current jdk9 tip fails to build from source on aarch64 with the following error message
> >
> > /home/ed/build/1504/dev/build/linux-aarch64-normal-server-release/support/native/java.desktop/libsplashscreen/pngrutil.o: In function `png_init_filter_functions':
> > /home/ed/build/1504/dev/jdk/src/java.desktop/share/native/libsplashscreen/libpng/pngrutil.c:3947: undefined reference to `png_init_filter_functions_neon'
> > collect2: error: ld returned 1 exit status
> >
> > The following webrev gets it building again.
> >
> > http://cr.openjdk.java.net/~enevill/8078245/webrev.00/
> 
> Shouldn't the guard be Aarch64 specific rather than just __arm__ ? I'm 
> also wondering how we would get __ARM_NEON defined but not __arm__?

On arm 32 bit gcc defines the symbol __ARM_NEON if the flag -mfpu=neon is specified. Since this is not specified as part of the OpenJDK build the symbol is not defined and the build succeeds.

On aarch64 the symbol __ARM_NEON is always defined (the theory being that aarch64 always supports Neon). Personally I think this is borken as it causes builds to fail (and not just OpenJDK, several other projects have had the same build failure - try googling the above error message). But we are stuck with gcc as it is.

However, I don't like the above fix because it not only modifies the jdk, it modifies an external component which is pulled into jdk, which means every time a new revision of linpng is pulled in, the patch will have to be applied again.

A better approach I think is to define the symbol PNG_ARM_NEON_OPT=0 in the build (only if aarch64).

The failing code in pngpriv.h reads

#ifndef PNG_ARM_NEON_OPT

...

#  if (defined(__ARM_NEON__) || defined(__ARM_NEON)) && \
   defined(PNG_ALIGNED_MEMORY_SUPPORTED)
#     define PNG_ARM_NEON_OPT 2
#  else
#     define PNG_ARM_NEON_OPT 0
#  endif
#endif

So, if we just predefine PNG_ARM_NEON=0 in the build this will have the same effect as adding defined(__arm__) or !defined(__aarch64__) above.

The following patch webrev does this:-

http://cr.openjdk.java.net/~enevill/8078245/webrev.01/

If you are happy with this and if I could have another reviewer I will push this.

All the best,
Ed.



From claudio.fontana at huawei.com  Wed Apr 29 13:01:41 2015
From: claudio.fontana at huawei.com (Claudio Fontana)
Date: Wed, 29 Apr 2015 15:01:41 +0200
Subject: [aarch64-port-dev ] Java HotSpot Options for JIT generated native
	code disassembly support
Message-ID: <5540D635.2040400@huawei.com>

Hello,

what is the state of basic support for AArch64 of the

+PrintAssembly, +PrintInterpreter, +PrintNativeMethods, ...

options?

Is the hsdis plugin already working for AArch64?
Are some binaries available or should one rebuild it from source?

Thank you,

Claudio Fontana

-- 
Claudio Fontana
Server Virtualization Architect
Huawei Technologies Duesseldorf GmbH
Riesstra?e 25 - 80992 M?nchen

From aph at redhat.com  Wed Apr 29 13:05:27 2015
From: aph at redhat.com (Andrew Haley)
Date: Wed, 29 Apr 2015 14:05:27 +0100
Subject: [aarch64-port-dev ] Java HotSpot Options for JIT generated
 native code disassembly support
In-Reply-To: <5540D635.2040400@huawei.com>
References: <5540D635.2040400@huawei.com>
Message-ID: <5540D717.7000409@redhat.com>

On 04/29/2015 02:01 PM, Claudio Fontana wrote:

> what is the state of basic support for AArch64 of the
> 
> +PrintAssembly, +PrintInterpreter, +PrintNativeMethods, ...
> 
> options?

It all works.

> Is the hsdis plugin already working for AArch64?
> Are some binaries available or should one rebuild it from source?

You'll have to rebuild it from source.  There are some interesting legal
issues with making a binary available.

Andrew.


From xerxes at zafena.se  Wed Apr 29 13:23:46 2015
From: xerxes at zafena.se (=?UTF-8?B?WGVyeGVzIFLDpW5ieQ==?=)
Date: Wed, 29 Apr 2015 15:23:46 +0200
Subject: [aarch64-port-dev ] Java HotSpot Options for JIT generated
 native code disassembly support
In-Reply-To: <5540D717.7000409@redhat.com>
References: <5540D635.2040400@huawei.com> <5540D717.7000409@redhat.com>
Message-ID: <5540DB62.9070505@zafena.se>



Den 2015-04-29 15:05, Andrew Haley skrev:
> On 04/29/2015 02:01 PM, Claudio Fontana wrote:
>
>> Is the hsdis plugin already working for AArch64?
>> Are some binaries available or should one rebuild it from source?
> You'll have to rebuild it from source.  There are some interesting legal
> issues with making a binary available.
>
> Andrew.
>
What kind of legal issues do you refer to?
Publishing binary's originating from the GPLv2 licensed sources is safe 
as long as you follow the requirements of the GPLv2.

Xerxes

From springer at reservoir.com  Thu Apr 30 04:55:28 2015
From: springer at reservoir.com (Jonathan Springer)
Date: Wed, 29 Apr 2015 23:55:28 -0500
Subject: [aarch64-port-dev ] ZeroTLAB in aarch64 jdk7u
Message-ID: <5541B5C0.3030806@reservoir.com>

Hi all,

AArch64 jdk7u tip is broken with -XX:+ZeroTLAB - it crashes on "hello
world."  I think this is probably the same bug as
https://bugs.openjdk.java.net/browse/JDK-8073641 but that was fixed
incidentally and the cause never identified.  I realize 7u isn't getting
any more attention, but does anyone happen to know what the problem
might have been?  Thanks,

Jonathan

-- 
Jonathan Springer     |  (212) 780-0527 x301
Reservoir Labs, Inc.  |  http://www.reservoir.com/

From david.holmes at oracle.com  Thu Apr 30 05:26:34 2015
From: david.holmes at oracle.com (David Holmes)
Date: Thu, 30 Apr 2015 15:26:34 +1000
Subject: [aarch64-port-dev ] aarch64: jdk9: 8078245: fails to build from
	source
In-Reply-To: <1430304750.8394.56.camel@mylittlepony.linaroharston>
References: <1429607797.4116.11.camel@mylittlepony.linaroharston>	
	<5539EC8E.1060507@oracle.com>
	<1430304750.8394.56.camel@mylittlepony.linaroharston>
Message-ID: <5541BD0A.3090305@oracle.com>

Hi Nevill,

Just realized this was sent to hotspot-dev (attempting bcc) but is not a 
hotspot issue. With your new approach this is a build issue so cc'ing 
build-dev.

The new approach seems better to me but build folk need to confirm the 
placement.

Thanks,
David

On 29/04/2015 8:52 PM, Edward Nevill wrote:
> On Fri, 2015-04-24 at 17:11 +1000, David Holmes wrote:
>> Hi Ed,
>>
>> On 21/04/2015 7:16 PM, Edward Nevill wrote:
>>> Hi,
>>>
>>> The current jdk9 tip fails to build from source on aarch64 with the following error message
>>>
>>> /home/ed/build/1504/dev/build/linux-aarch64-normal-server-release/support/native/java.desktop/libsplashscreen/pngrutil.o: In function `png_init_filter_functions':
>>> /home/ed/build/1504/dev/jdk/src/java.desktop/share/native/libsplashscreen/libpng/pngrutil.c:3947: undefined reference to `png_init_filter_functions_neon'
>>> collect2: error: ld returned 1 exit status
>>>
>>> The following webrev gets it building again.
>>>
>>> http://cr.openjdk.java.net/~enevill/8078245/webrev.00/
>>
>> Shouldn't the guard be Aarch64 specific rather than just __arm__ ? I'm
>> also wondering how we would get __ARM_NEON defined but not __arm__?
>
> On arm 32 bit gcc defines the symbol __ARM_NEON if the flag -mfpu=neon is specified. Since this is not specified as part of the OpenJDK build the symbol is not defined and the build succeeds.
>
> On aarch64 the symbol __ARM_NEON is always defined (the theory being that aarch64 always supports Neon). Personally I think this is borken as it causes builds to fail (and not just OpenJDK, several other projects have had the same build failure - try googling the above error message). But we are stuck with gcc as it is.
>
> However, I don't like the above fix because it not only modifies the jdk, it modifies an external component which is pulled into jdk, which means every time a new revision of linpng is pulled in, the patch will have to be applied again.
>
> A better approach I think is to define the symbol PNG_ARM_NEON_OPT=0 in the build (only if aarch64).
>
> The failing code in pngpriv.h reads
>
> #ifndef PNG_ARM_NEON_OPT
>
> ...
>
> #  if (defined(__ARM_NEON__) || defined(__ARM_NEON)) && \
>     defined(PNG_ALIGNED_MEMORY_SUPPORTED)
> #     define PNG_ARM_NEON_OPT 2
> #  else
> #     define PNG_ARM_NEON_OPT 0
> #  endif
> #endif
>
> So, if we just predefine PNG_ARM_NEON=0 in the build this will have the same effect as adding defined(__arm__) or !defined(__aarch64__) above.
>
> The following patch webrev does this:-
>
> http://cr.openjdk.java.net/~enevill/8078245/webrev.01/
>
> If you are happy with this and if I could have another reviewer I will push this.
>
> All the best,
> Ed.
>
>

From david.holmes at oracle.com  Thu Apr 30 05:34:22 2015
From: david.holmes at oracle.com (David Holmes)
Date: Thu, 30 Apr 2015 15:34:22 +1000
Subject: [aarch64-port-dev ] aarch64: jdk9: 8078245: fails to build from
	source
In-Reply-To: <5541BD0A.3090305@oracle.com>
References: <1429607797.4116.11.camel@mylittlepony.linaroharston>		<5539EC8E.1060507@oracle.com>	<1430304750.8394.56.camel@mylittlepony.linaroharston>
	<5541BD0A.3090305@oracle.com>
Message-ID: <5541BEDE.6020501@oracle.com>

On 30/04/2015 3:26 PM, David Holmes wrote:
> Hi Nevill,

Sorry Ed!

David

> Just realized this was sent to hotspot-dev (attempting bcc) but is not a
> hotspot issue. With your new approach this is a build issue so cc'ing
> build-dev.
>
> The new approach seems better to me but build folk need to confirm the
> placement.
>
> Thanks,
> David
>
> On 29/04/2015 8:52 PM, Edward Nevill wrote:
>> On Fri, 2015-04-24 at 17:11 +1000, David Holmes wrote:
>>> Hi Ed,
>>>
>>> On 21/04/2015 7:16 PM, Edward Nevill wrote:
>>>> Hi,
>>>>
>>>> The current jdk9 tip fails to build from source on aarch64 with the
>>>> following error message
>>>>
>>>> /home/ed/build/1504/dev/build/linux-aarch64-normal-server-release/support/native/java.desktop/libsplashscreen/pngrutil.o:
>>>> In function `png_init_filter_functions':
>>>> /home/ed/build/1504/dev/jdk/src/java.desktop/share/native/libsplashscreen/libpng/pngrutil.c:3947:
>>>> undefined reference to `png_init_filter_functions_neon'
>>>> collect2: error: ld returned 1 exit status
>>>>
>>>> The following webrev gets it building again.
>>>>
>>>> http://cr.openjdk.java.net/~enevill/8078245/webrev.00/
>>>
>>> Shouldn't the guard be Aarch64 specific rather than just __arm__ ? I'm
>>> also wondering how we would get __ARM_NEON defined but not __arm__?
>>
>> On arm 32 bit gcc defines the symbol __ARM_NEON if the flag -mfpu=neon
>> is specified. Since this is not specified as part of the OpenJDK build
>> the symbol is not defined and the build succeeds.
>>
>> On aarch64 the symbol __ARM_NEON is always defined (the theory being
>> that aarch64 always supports Neon). Personally I think this is borken
>> as it causes builds to fail (and not just OpenJDK, several other
>> projects have had the same build failure - try googling the above
>> error message). But we are stuck with gcc as it is.
>>
>> However, I don't like the above fix because it not only modifies the
>> jdk, it modifies an external component which is pulled into jdk, which
>> means every time a new revision of linpng is pulled in, the patch will
>> have to be applied again.
>>
>> A better approach I think is to define the symbol PNG_ARM_NEON_OPT=0
>> in the build (only if aarch64).
>>
>> The failing code in pngpriv.h reads
>>
>> #ifndef PNG_ARM_NEON_OPT
>>
>> ...
>>
>> #  if (defined(__ARM_NEON__) || defined(__ARM_NEON)) && \
>>     defined(PNG_ALIGNED_MEMORY_SUPPORTED)
>> #     define PNG_ARM_NEON_OPT 2
>> #  else
>> #     define PNG_ARM_NEON_OPT 0
>> #  endif
>> #endif
>>
>> So, if we just predefine PNG_ARM_NEON=0 in the build this will have
>> the same effect as adding defined(__arm__) or !defined(__aarch64__)
>> above.
>>
>> The following patch webrev does this:-
>>
>> http://cr.openjdk.java.net/~enevill/8078245/webrev.01/
>>
>> If you are happy with this and if I could have another reviewer I will
>> push this.
>>
>> All the best,
>> Ed.
>>
>>

From aph at redhat.com  Thu Apr 30 08:59:54 2015
From: aph at redhat.com (Andrew Haley)
Date: Thu, 30 Apr 2015 09:59:54 +0100
Subject: [aarch64-port-dev ] ZeroTLAB in aarch64 jdk7u
In-Reply-To: <5541B5C0.3030806@reservoir.com>
References: <5541B5C0.3030806@reservoir.com>
Message-ID: <5541EF0A.5040802@redhat.com>

On 30/04/15 05:55, Jonathan Springer wrote:
> AArch64 jdk7u tip is broken with -XX:+ZeroTLAB - it crashes on "hello
> world."  I think this is probably the same bug as
> https://bugs.openjdk.java.net/browse/JDK-8073641 but that was fixed
> incidentally and the cause never identified.  I realize 7u isn't getting
> any more attention, but does anyone happen to know what the problem
> might have been?  Thanks,

No idea; GDB is your friend!  I think we will continue with JDK7u for
some time yet but I don't think anyone has decided how long AARch64 7u
will continue for.  It's in pretty good shape.

Andrew.


From edward.nevill at linaro.org  Thu Apr 30 09:11:37 2015
From: edward.nevill at linaro.org (Edward Nevill)
Date: Thu, 30 Apr 2015 10:11:37 +0100
Subject: [aarch64-port-dev ] ZeroTLAB in aarch64 jdk7u
In-Reply-To: <5541B5C0.3030806@reservoir.com>
References: <5541B5C0.3030806@reservoir.com>
Message-ID: <1430385097.3970.7.camel@mylittlepony.linaroharston>

On Wed, 2015-04-29 at 23:55 -0500, Jonathan Springer wrote:
> Hi all,
> 
> AArch64 jdk7u tip is broken with -XX:+ZeroTLAB - it crashes on "hello
> world."  I think this is probably the same bug as
> https://bugs.openjdk.java.net/browse/JDK-8073641 but that was fixed
> incidentally and the cause never identified.  I realize 7u isn't getting
> any more attention, but does anyone happen to know what the problem
> might have been?  Thanks,

Hi Jonathan,

Try the 1503 build @

http://openjdk.linaro.org/releases/jdk7-server-release-1503.tar.xz

I have tried to replicate with this but I cannot.

I will be doing a 1504 build shortly, probably tomorrow (yes, I know its
May tomorrow:)

All the best,
Ed.



From springer at reservoir.com  Thu Apr 30 16:33:10 2015
From: springer at reservoir.com (Jonathan Springer)
Date: Thu, 30 Apr 2015 11:33:10 -0500
Subject: [aarch64-port-dev ] ZeroTLAB in aarch64 jdk7u
In-Reply-To: <1430385097.3970.7.camel@mylittlepony.linaroharston>
References: <5541B5C0.3030806@reservoir.com>
	<1430385097.3970.7.camel@mylittlepony.linaroharston>
Message-ID: <55425946.3060404@reservoir.com>

On 4/30/2015 4:11 AM, Edward Nevill wrote:
> On Wed, 2015-04-29 at 23:55 -0500, Jonathan Springer wrote:
>> Hi all,
>>
>> AArch64 jdk7u tip is broken with -XX:+ZeroTLAB - it crashes on "hello
>> world."  I think this is probably the same bug as
>> https://bugs.openjdk.java.net/browse/JDK-8073641 but that was fixed
>> incidentally and the cause never identified.  I realize 7u isn't getting
>> any more attention, but does anyone happen to know what the problem
>> might have been?  Thanks,
> 
> Hi Jonathan,
> 
> Try the 1503 build @
> 
> http://openjdk.linaro.org/releases/jdk7-server-release-1503.tar.xz
> 
> I have tried to replicate with this but I cannot.
> 
> I will be doing a 1504 build shortly, probably tomorrow (yes, I know its
> May tomorrow:)
> 
> All the best,
> Ed.

Thanks, 1503 +ZeroTLAB does work on hello world.  I'll try it on some
longer programs to make sure the issue is really gone.

Looking forward to 1504!

Jonathan

-- 
Jonathan Springer     |  (212) 780-0527 x301
Reservoir Labs, Inc.  |  http://www.reservoir.com/

From claudio.fontana at huawei.com  Wed Apr 29 13:08:25 2015
From: claudio.fontana at huawei.com (Claudio Fontana)
Date: Wed, 29 Apr 2015 15:08:25 +0200
Subject: [aarch64-port-dev ] [thank you] Java HotSpot Options for JIT
 generated native code disassembly support
In-Reply-To: <5540D717.7000409@redhat.com>
References: <5540D635.2040400@huawei.com> <5540D717.7000409@redhat.com>
Message-ID: <5540D7C9.5030909@huawei.com>

On 29.04.2015 15:05, Andrew Haley wrote:
> On 04/29/2015 02:01 PM, Claudio Fontana wrote:
> 
>> what is the state of basic support for AArch64 of the
>>
>> +PrintAssembly, +PrintInterpreter, +PrintNativeMethods, ...
>>
>> options?
> 
> It all works.
> 
>> Is the hsdis plugin already working for AArch64?
>> Are some binaries available or should one rebuild it from source?
> 
> You'll have to rebuild it from source.  There are some interesting legal
> issues with making a binary available.
> 
> Andrew.
> 

That's excellent, thank you for your answer.

Claudio