From roland.westrelin at oracle.com Fri Oct 2 14:04:51 2015 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Fri, 2 Oct 2015 16:04:51 +0200 Subject: [aarch64-port-dev ] RFR: aarch64: add support for vectorizing floating-point fabs & fneg In-Reply-To: <1443602324.20740.3.camel@mint> References: <5605792B.5000408@redhat.com> <56095AFD.9000405@redhat.com> <1443602324.20740.3.camel@mint> Message-ID: <5890687B-F5B9-4854-8878-5B1986875B83@oracle.com> > I have created a JIRA issue and webrev for this. > > https://bugs.openjdk.java.net/browse/JDK-8138583 > > http://cr.openjdk.java.net/~enevill/8138583/webrev/ > > As this modifies shared code could someone sponsor it and push it through JPRT. I?m pushing it. Roland. From hui.shi at linaro.org Mon Oct 5 13:14:45 2015 From: hui.shi at linaro.org (Hui Shi) Date: Mon, 5 Oct 2015 21:14:45 +0800 Subject: [aarch64-port-dev ] RFR: Elide more final field's write memory barrier with escape analysis result Message-ID: Would some one please help review and comments this change? MemBarRelease for final field write can be removed when its allocation doesn't escape thread, allocation node can be acquired from its MemBarNode::Precedent input. Currently, MemBarRelase's Precedent input is only added when eliminate_boxing is true and its owning object is primitive Box (see Parse::do_put_xxx and Parse::do_exits). Checking OpenJDK log, this is added for autoboxing elimination early. Now I suggest turn on this optimization for general object type, this can benefit RMO platform (like aarch64) performance. This patch is not trivial, so put it at http://people.linaro.org/~hui.shi/membar_precedent/membar_precedent.patch Patch removes constraints for set_alloc_with_final(obj) in do_put_xxx (parse3.cpp). This leads to adding Precedent input for all kind object's final field writes' MemBarRelase node. Then they have opportunities to get optimized. In TestString small case, String object is allocated but not escaped in bar. Checking TestString_base.txt and TestString_fix.txt. Without this patch, Memory barrier is not removed even object allocation is optimized out. http://people.linaro.org/~hui.shi/membar_precedent/TestString.java http://people.linaro.org/~hui.shi/membar_precedent/TestString_base.txt http://people.linaro.org/~hui.shi/membar_precedent/TestString_fix.txt All kind object's final/stable field store's MemBarRelease node has chance to be optimized when its allocation doesn't escape thread. It?s safe based on following 4 pre-conditions: 1. Only MemBarRelease created for final/stable field store has MemBarNode::Precedent input. 2. MemBarRelease nodes' MemBarNode::Precedent input is only used in MemBarNode.Ideal, removing MemBarRelease when allocation doesn't escape. 3. MemBarRelease's MemBarNode::Precedent input is correctly set with final/stable field's owning object allocation if exist. 4. Escape analysis result is correct. Extra changes in patch target the 3rd pre-condition. In Parse::do_put_xxx, alloc_with_final is set and used for both final and Stable fields write. As final field can only be written in owning class initializer, but Stable field can be written in any method. There might be issues when writing both final and Stable field (could be stable field from different allocation) in same initializer method. 1. Stable field and final field has different owning object, it trigger assertions in set_alloc_with_final (different allocation objs). 2. If final field's allocation doesn't escape and stable field's allocation is unknown, both MemBarRelased node will be removed as they use same final field's allocation as Precedent input. Above issues can be reproduced with http://people.linaro.org/~hui.shi/membar_precedent/TestStable.java These issue can't be reproduced with current implementation, because alloc_with_final is only set in primitive box type initializer and no final and stable field both written cases there. Issues become visible with my change. So I suggest re-factor final and stable field handling here. Add an alloc_with_stable field for stable field write's MemBarRelease Precedent input, initialize as NodeSentinel. If stable field's allocation node is conflict or unknown, set it as NULL. Another small issue for MemBarRelease node created for volatile field write on PPC64. Volatile field?s owning object might be different with final field?s allocation. When MemBarRelease is removed because final field's allocation doesn?t escape, still need keep MemBarRelease for volatile write. Solution is using NULL as MemBarRelase node precedent input when wrote volatile is true. Regards Shi Hui From aph at redhat.com Mon Oct 5 16:18:14 2015 From: aph at redhat.com (Andrew Haley) Date: Mon, 5 Oct 2015 17:18:14 +0100 Subject: [aarch64-port-dev ] RFR: Elide more final field's write memory barrier with escape analysis result In-Reply-To: References: Message-ID: <5612A2C6.5080108@redhat.com> I like this patch. It seems to do the right thing, although it'll be necessary to check with jcstress and perhaps write a few more jcstress test cases to make sure that the right thing happens in all cases. Andrew. From hui.shi at linaro.org Tue Oct 6 12:52:50 2015 From: hui.shi at linaro.org (Hui Shi) Date: Tue, 6 Oct 2015 20:52:50 +0800 Subject: [aarch64-port-dev ] RFR: Elide more final field's write memory barrier with escape analysis result In-Reply-To: <5612A2C6.5080108@redhat.com> References: <5612A2C6.5080108@redhat.com> Message-ID: Thanks Andrew! This patch modifies share code. Except jcstress, would someone help sponsor and run JPRT? create webrev for this change (just got my openjdk id) http://cr.openjdk.java.net/~hshi/8138956/webrev/ Small test shows patch enhancement *http://cr.openjdk.java.net/~hshi/8138956/TestString.java * *http://cr.openjdk.java.net/~hshi/8138956/TestString_base.txt * *http://cr.openjdk.java.net/~hshi/8138956/TestString_fix.txt * Example shows stable field write needs code refactoring http://cr.openjdk.java.net/~hshi/8138956/TestStable.java Regards Shi Hui On 6 October 2015 at 00:18, Andrew Haley wrote: > I like this patch. It seems to do the right thing, although it'll > be necessary to check with jcstress and perhaps write a few more > jcstress test cases to make sure that the right thing happens in > all cases. > > Andrew. > From edward.nevill at gmail.com Tue Oct 6 18:24:50 2015 From: edward.nevill at gmail.com (Edward Nevill) Date: Tue, 06 Oct 2015 19:24:50 +0100 Subject: [aarch64-port-dev ] RFR: Elide more final field's write memory barrier with escape analysis result In-Reply-To: References: <5612A2C6.5080108@redhat.com> Message-ID: <1444155890.7706.1.camel@mint> On Tue, 2015-10-06 at 20:52 +0800, Hui Shi wrote: > Thanks Andrew! > > This patch modifies share code. Except jcstress, would someone help sponsor and run JPRT? > Hi Hui Shi, I have tested this patch with jcstress on aarch64 partner HW with no errors. Looks good to me. All the best, Ed. From hui.shi at linaro.org Wed Oct 7 02:16:46 2015 From: hui.shi at linaro.org (Hui Shi) Date: Wed, 7 Oct 2015 10:16:46 +0800 Subject: [aarch64-port-dev ] RFR: Elide more final field's write memory barrier with escape analysis result In-Reply-To: <1444155890.7706.1.camel@mint> References: <5612A2C6.5080108@redhat.com> <1444155890.7706.1.camel@mint> Message-ID: Thanks Edward! Regards Shi Hui On 7 October 2015 at 02:24, Edward Nevill wrote: > On Tue, 2015-10-06 at 20:52 +0800, Hui Shi wrote: > > Thanks Andrew! > > > > This patch modifies share code. Except jcstress, would someone help > sponsor and run JPRT? > > > > Hi Hui Shi, > > I have tested this patch with jcstress on aarch64 partner HW with no > errors. Looks good to me. > > All the best, > Ed. > > > > From adinn at redhat.com Wed Oct 7 11:45:14 2015 From: adinn at redhat.com (Andrew Dinn) Date: Wed, 7 Oct 2015 12:45:14 +0100 Subject: [aarch64-port-dev ] RFR: 8139042: AARCH64: Correct regression introduced by 8080293 In-Reply-To: <5615012F.4090500@redhat.com> References: <5615012F.4090500@redhat.com> Message-ID: <561505CA.1020505@redhat.com> Oops. forgot to copy to aarch64-port-dev n.b. the patch is against the latest jdk9/hs--comp -------- Forwarded Message -------- Subject: RFR: 8139042: AARCH64: Correct regression introduced by 8080293 Date: Wed, 7 Oct 2015 12:25:35 +0100 From: Andrew Dinn To: hotspot compiler Could two reviewers please review this AArch64 only patch. http://cr.openjdk.java.net/~adinn/8139042/webrev.00/ The fix for issue JDK-8080293 (AARCH64: Remove unnecessary dmbs from generated CAS code) inadvertently disabled one step of the optimization process for unsafe volatile object gets. The result is that unsafe volatile get is successfully translated to ldar but generation of the trailing dmb ishld instruction is not inhibited. The patch for 8080293 extended predicate unnecessary_acquire to check for a MemBarAcquire associated with a CompareAndSwapX node. In doing so it changed the logic of a sanity check for MemBarAcquire introdcued as part of an unsafe volatile get. The patch modified the code to conditionally return true instead of return false. However the condition retained the original != where it should have employed ==. 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 Oct 7 15:04:57 2015 From: aph at redhat.com (Andrew Haley) Date: Wed, 7 Oct 2015 16:04:57 +0100 Subject: [aarch64-port-dev ] CFV: New aarch64-port Committer: Andrew Hughes In-Reply-To: <55FC1370.3060501@redhat.com> References: <55FC1370.3060501@redhat.com> Message-ID: <56153499.6020309@redhat.com> Voting for Andrew Hughes [1] is now closed. Yes: 4 Veto: 0 Abstain: 0 According to the Bylaws definition of Lazy Consensus, this is sufficient to approve the nomination. Andrew. [1] http://mail.openjdk.java.net/pipermail/aarch64-port-dev/2015-September/002806.html From adinn at redhat.com Wed Oct 7 16:31:02 2015 From: adinn at redhat.com (Andrew Dinn) Date: Wed, 7 Oct 2015 17:31:02 +0100 Subject: [aarch64-port-dev ] RFR: 8139042: AARCH64: Correct regression introduced by 8080293 In-Reply-To: <56152CBF.2090404@oracle.com> References: <5615012F.4090500@redhat.com> <56152CBF.2090404@oracle.com> Message-ID: <561548C6.10002@redhat.com> Thanks, Andrew and Vladimir for the reviews. Since this has had two reviews and is aarch64 only I have exercised my newly granted Committer status to push it to hs-comp! (yes, a whole 1 character got changed! :-) 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) On 07/10/15 15:31, Vladimir Kozlov wrote: > Good. > > Thanks, > Vladimir > > On 10/7/15 7:25 PM, Andrew Dinn wrote: >> Could two reviewers please review this AArch64 only patch. >> >> http://cr.openjdk.java.net/~adinn/8139042/webrev.00/ >> >> The fix for issue JDK-8080293 (AARCH64: Remove unnecessary dmbs from >> generated CAS code) inadvertently disabled one step of the optimization >> process for unsafe volatile object gets. The result is that unsafe >> volatile get is successfully translated to ldar but generation of the >> trailing dmb ishld instruction is not inhibited. >> >> The patch for 8080293 extended predicate unnecessary_acquire to check >> for a MemBarAcquire associated with a CompareAndSwapX node. In doing so >> it changed the logic of a sanity check for MemBarAcquire introdcued as >> part of an unsafe volatile get. The patch modified the code to >> conditionally return true instead of return false. However the condition >> retained the original != where it should have employed ==. >> >> 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 Thu Oct 8 11:51:11 2015 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Thu, 8 Oct 2015 13:51:11 +0200 Subject: [aarch64-port-dev ] RFR: Elide more final field's write memory barrier with escape analysis result In-Reply-To: References: <5612A2C6.5080108@redhat.com> Message-ID: > http://cr.openjdk.java.net/~hshi/8138956/webrev/ The code change looks good to me. The comments have a few typos and are a bit confusing. I'll tweak them before I push it. PPC folks, in case you missed it, parse1.cpp has a ppc related fix. Roland. From edward.nevill at gmail.com Thu Oct 8 14:23:45 2015 From: edward.nevill at gmail.com (Edward Nevill) Date: Thu, 08 Oct 2015 15:23:45 +0100 Subject: [aarch64-port-dev ] RFR: 8139043: aarch64: add support for adler32 intrinsic Message-ID: <1444314225.15616.12.camel@mylittlepony.linaroharston> Hi, Please review the following webrev http://cr.openjdk.java.net/~enevill/8139043/webrev/ Jira Issue: https://bugs.openjdk.java.net/browse/JDK-8139043 This webrev adds support for adler32 intrinsic on aarch64 in the same way that support for adler32 was added for Sparc recently (see https://bugs.openjdk.java.net/browse/JDK-8132081) Testing using TestAdler32.java from jtreg test suite shows between 60% and 155% improvement depending on the size of buffer. Tested with jtreg hotspot. Results the same before and after patch (Test results: passed: 896; failed: 6; error: 10) Thanks for your help, Ed From adinn at redhat.com Thu Oct 8 16:11:59 2015 From: adinn at redhat.com (Andrew Dinn) Date: Thu, 8 Oct 2015 17:11:59 +0100 Subject: [aarch64-port-dev ] RFR: backport volatile put/get and CAS optimization to JDK8 Message-ID: <561695CF.5040002@redhat.com> Here is a webrev against the latest aarch64-port-dev/jdk8/hotspot for review: http://cr.openjdk.java.net/~adinn/jdk8volcasopt/webrev.00 It backports the jdk9-aarch64 optimizations which use ldar and stlr for volatile gets and puts and unsafe CAS operations to jdk8-aarch64 So far, I have tested it (successfully) by eyeballing generated code for some hand cranked tests that use volatiles and CASes in all 5 relevant GC configurations (see below ***) and also running by netbeans and eyeballing generated hash table code. I am currently running jcstress to fully test it on a Mustang in all GC configs. Ed, would you be able to check that jcstress works fine on other hardware? *** GC configs are -XX:+UseConcMarkSweepGC -XX:+UseCondCardMark -XX:+UseConcMarkSweepGC -XX:-UseCondCardMark -XX:+UseG1GC -XX:+UseParallelGC -XX:+UseCondCardMark -XX:+UseParallelGC -XX:-UseCondCardMark regards, Andrew Dinn ----------- From adinn at redhat.com Thu Oct 8 16:24:18 2015 From: adinn at redhat.com (Andrew Dinn) Date: Thu, 8 Oct 2015 17:24:18 +0100 Subject: [aarch64-port-dev ] RFR: backport volatile put/get and CAS optimization to JDK8 In-Reply-To: <561695CF.5040002@redhat.com> References: <561695CF.5040002@redhat.com> Message-ID: <561698B2.5020009@redhat.com> Oops, wait a minute, ignore the previous post -- the webrev is thoroughly borked. The changeset looks ok but the diffs for file aarch64.ad include all sorts of patches to the pipeline classes which are not part of the changeset. I'll post a corrected version as soon as I can work out what went wrong. regards, Andrew Dinn ----------- On 08/10/15 17:11, Andrew Dinn wrote: > Here is a webrev against the latest aarch64-port-dev/jdk8/hotspot for > review: > > http://cr.openjdk.java.net/~adinn/jdk8volcasopt/webrev.00 > > It backports the jdk9-aarch64 optimizations which use ldar and stlr for > volatile gets and puts and unsafe CAS operations to jdk8-aarch64 > > So far, I have tested it (successfully) by eyeballing generated code for > some hand cranked tests that use volatiles and CASes in all 5 relevant > GC configurations (see below ***) and also running by netbeans and > eyeballing generated hash table code. > > I am currently running jcstress to fully test it on a Mustang in all GC > configs. > > Ed, would you be able to check that jcstress works fine on other hardware? > > *** GC configs are > -XX:+UseConcMarkSweepGC -XX:+UseCondCardMark > -XX:+UseConcMarkSweepGC -XX:-UseCondCardMark > -XX:+UseG1GC > -XX:+UseParallelGC -XX:+UseCondCardMark > -XX:+UseParallelGC -XX:-UseCondCardMark > > regards, > > > Andrew Dinn > ----------- > > From vladimir.kozlov at oracle.com Fri Oct 9 03:39:42 2015 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 9 Oct 2015 11:39:42 +0800 Subject: [aarch64-port-dev ] RFR: 8139043: aarch64: add support for adler32 intrinsic In-Reply-To: <1444314225.15616.12.camel@mylittlepony.linaroharston> References: <1444314225.15616.12.camel@mylittlepony.linaroharston> Message-ID: <561736FE.50702@oracle.com> Looks good. Thanks, Vladimir On 10/8/15 10:23 PM, Edward Nevill wrote: > Hi, > > Please review the following webrev > > http://cr.openjdk.java.net/~enevill/8139043/webrev/ > > Jira Issue: https://bugs.openjdk.java.net/browse/JDK-8139043 > > This webrev adds support for adler32 intrinsic on aarch64 in the same way that support for adler32 was added for Sparc recently (see https://bugs.openjdk.java.net/browse/JDK-8132081) > > Testing using TestAdler32.java from jtreg test suite shows between 60% and 155% improvement depending on the size of buffer. > > Tested with jtreg hotspot. Results the same before and after patch (Test results: passed: 896; failed: 6; error: 10) > > Thanks for your help, > Ed > > From edward.nevill at gmail.com Fri Oct 9 11:17:50 2015 From: edward.nevill at gmail.com (Edward Nevill) Date: Fri, 09 Oct 2015 12:17:50 +0100 Subject: [aarch64-port-dev ] RFR: 8139259: aarch64: jtreg test TestLogSum segvs after 8132207 Message-ID: <1444389470.23861.23.camel@mint> Hi, Please review the following webrev http://cr.openjdk.java.net/~enevill/8139259/webrev/ Jira issue: https://bugs.openjdk.java.net/browse/JDK-8139259 This fixes a SEGV which was introduced to the aarch64 port after the following patch http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/324ea1a2419a The problem is that the aarch64 port ends up calling StubRoutines::_dexp when it is initialised to NULL. The reason is the following lines --- src/share/vm/opto/library_call.cpp --- 1764 case vmIntrinsics::_dexp: 1765 return (UseSSE >= 2) ? runtime_math(OptoRuntime::Math_D_D_Type(), StubRoutines::dexp(), "dexp") : 1766 runtime_math(OptoRuntime::Math_D_D_Type(), FN_PTR(SharedRuntime::dexp), "EXP"); --- src/share/vm/runtime/globals.hpp 702 product(intx, UseSSE, 99, \ 703 "Highest supported SSE instructions set on x86/x64") \ --- src/share/vm/runtime/stubRoutines.cpp 151 address StubRoutines::_dexp = NULL; I could fix this by forcing UseSSE to 0 in vm_version_aarch64 however there are about 20 other places in C1 and C2 shared code where UseSSE is used and I would be changing the behaviour of all of these. So instead the patch above removes the usage of UseSSE in library_call above. At some time all the usages of UseSSE in shared code should be reviewed. This patch affects shared code so will need to be sponsored and pushed through JPRT Thanks for your help, Ed. From roland.westrelin at oracle.com Fri Oct 9 12:23:51 2015 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Fri, 9 Oct 2015 14:23:51 +0200 Subject: [aarch64-port-dev ] RFR: 8139259: aarch64: jtreg test TestLogSum segvs after 8132207 In-Reply-To: <1444389470.23861.23.camel@mint> References: <1444389470.23861.23.camel@mint> Message-ID: <8AF4C615-5E7A-425E-8883-5E7ECE2669E7@oracle.com> Hi Ed, > http://cr.openjdk.java.net/~enevill/8139259/webrev/ All 64 bit x86 cpus support sse2 so the new check in stubGenerator_x86_64.cpp is useless. Given in the interpreter and c1, we call the exp stub unconditionally, it didn?t really make sense that it was conditional on UseSSE in c2, anyway. Your library_call.cpp change looks good to me. I?ll sponsor it. Roland. From martin.doerr at sap.com Fri Oct 9 16:17:37 2015 From: martin.doerr at sap.com (Doerr, Martin) Date: Fri, 9 Oct 2015 16:17:37 +0000 Subject: [aarch64-port-dev ] RFR: Elide more final field's write memory barrier with escape analysis result In-Reply-To: References: <5612A2C6.5080108@redhat.com> Message-ID: <7C9B87B351A4BA4AA9EC95BB4181165672261165@DEWDFEMB19C.global.corp.sap> Hi, I basically like this change. Thanks for pointing me to it. But I don't like the extra code for PPC64. If the allocation does not escape globally it should be safe to elide the membar regardless of whether we wrote final or volatile fields. Please also note that PPC64_ONLY(...) NOT_PPC(...) is incorrect on PPC32. Actually, it's ugly that PPC64_ONLY was used here. Should better be (support_IRIW_for_not_multiple_copy_atomic_cpu && wrote_volatile()), but that's not the topic of this change. Best regards, Martin -----Original Message----- From: hotspot-compiler-dev [mailto:hotspot-compiler-dev-bounces at openjdk.java.net] On Behalf Of Roland Westrelin Sent: Donnerstag, 8. Oktober 2015 13:51 To: Hui Shi Cc: hotspot compiler; aarch64-port-dev at openjdk.java.net Subject: Re: RFR: Elide more final field's write memory barrier with escape analysis result > http://cr.openjdk.java.net/~hshi/8138956/webrev/ The code change looks good to me. The comments have a few typos and are a bit confusing. I'll tweak them before I push it. PPC folks, in case you missed it, parse1.cpp has a ppc related fix. Roland. From hui.shi at linaro.org Sat Oct 10 13:25:10 2015 From: hui.shi at linaro.org (Hui Shi) Date: Sat, 10 Oct 2015 21:25:10 +0800 Subject: [aarch64-port-dev ] RFR: Elide more final field's write memory barrier with escape analysis result In-Reply-To: <7C9B87B351A4BA4AA9EC95BB4181165672261165@DEWDFEMB19C.global.corp.sap> References: <5612A2C6.5080108@redhat.com> <7C9B87B351A4BA4AA9EC95BB4181165672261165@DEWDFEMB19C.global.corp.sap> Message-ID: Thanks Roland and Martin! Agree, it's better remove extra code for PPC64. new webrev http://cr.openjdk.java.net/~hshi/8138956/webrev_v2/ comments below Regards Shi Hui On 10 October 2015 at 00:17, Doerr, Martin wrote: > Hi, > > I basically like this change. Thanks for pointing me to it. > > But I don't like the extra code for PPC64. If the allocation does not > escape globally it should be safe to elide the membar regardless of whether > we wrote final or volatile fields. > > Difference is final field is always belonging to initializing object while volatile field isn't. It's reasonable to insert MemoryBarrier, when volatile field is written in its owning class' initializer method, like you example of AtomicInteger. In following example, class A initiailzer writes both final field and volatile field, suppose A instance doesn't escape. MemBarRelase is inserted because final and volatile field wirte. Writing b.vol in A's initializer is same with writing b.vol in none-initalizer method and doesn't need MemBarRelease in my understanding. 1. If final and volatile field from same allocation, elide MemBarRelase when allocation doesn't escape is safe. 2. If volatile field doesn't belong to final field's allocation object, MemBarRelase for volatile is not necessary. So it's safe to remove MemBarRelease when final field's allocation object doesn't escape. Class A { final int a; A(int val, B b) { a=val; b.vol = val; } } Class B { volatile int vol;} > Please also note that PPC64_ONLY(...) NOT_PPC(...) is incorrect on PPC32. > > Actually, it's ugly that PPC64_ONLY was used here. Should better be > (support_IRIW_for_not_multiple_copy_atomic_cpu && wrote_volatile()), but > that's not the topic of this change. > > Best regards, > Martin > > > -----Original Message----- > From: hotspot-compiler-dev [mailto: > hotspot-compiler-dev-bounces at openjdk.java.net] On Behalf Of Roland > Westrelin > Sent: Donnerstag, 8. Oktober 2015 13:51 > To: Hui Shi > Cc: hotspot compiler; aarch64-port-dev at openjdk.java.net > Subject: Re: RFR: Elide more final field's write memory barrier with > escape analysis result > > > http://cr.openjdk.java.net/~hshi/8138956/webrev/ > > The code change looks good to me. The comments have a few typos and are a > bit confusing. I'll tweak them before I push it. > > PPC folks, in case you missed it, parse1.cpp has a ppc related fix. > > Roland. > From martin.doerr at sap.com Mon Oct 12 09:39:16 2015 From: martin.doerr at sap.com (Doerr, Martin) Date: Mon, 12 Oct 2015 09:39:16 +0000 Subject: [aarch64-port-dev ] RFR: Elide more final field's write memory barrier with escape analysis result In-Reply-To: References: <5612A2C6.5080108@redhat.com> <7C9B87B351A4BA4AA9EC95BB4181165672261165@DEWDFEMB19C.global.corp.sap> Message-ID: <7C9B87B351A4BA4AA9EC95BB4181165672261384@DEWDFEMB19C.global.corp.sap> Hi Hui Shi, thanks for the update. Looks good for PPC64 as well, now. As you already explained, the MemBarRelease is only relevant for fields of the allocated object. Hence, the final and volatile cases can be handled the same way. Best regards, Martin From: Hui Shi [mailto:hui.shi at linaro.org] Sent: Samstag, 10. Oktober 2015 15:25 To: Doerr, Martin Cc: Roland Westrelin; hotspot compiler; aarch64-port-dev at openjdk.java.net Subject: Re: RFR: Elide more final field's write memory barrier with escape analysis result Thanks Roland and Martin! Agree, it's better remove extra code for PPC64. new webrev http://cr.openjdk.java.net/~hshi/8138956/webrev_v2/ comments below Regards Shi Hui On 10 October 2015 at 00:17, Doerr, Martin > wrote: Hi, I basically like this change. Thanks for pointing me to it. But I don't like the extra code for PPC64. If the allocation does not escape globally it should be safe to elide the membar regardless of whether we wrote final or volatile fields. Difference is final field is always belonging to initializing object while volatile field isn't. It's reasonable to insert MemoryBarrier, when volatile field is written in its owning class' initializer method, like you example of AtomicInteger. In following example, class A initiailzer writes both final field and volatile field, suppose A instance doesn't escape. MemBarRelase is inserted because final and volatile field wirte. Writing b.vol in A's initializer is same with writing b.vol in none-initalizer method and doesn't need MemBarRelease in my understanding. 1. If final and volatile field from same allocation, elide MemBarRelase when allocation doesn't escape is safe. 2. If volatile field doesn't belong to final field's allocation object, MemBarRelase for volatile is not necessary. So it's safe to remove MemBarRelease when final field's allocation object doesn't escape. Class A { final int a; A(int val, B b) { a=val; b.vol = val; } } Class B { volatile int vol;} Please also note that PPC64_ONLY(...) NOT_PPC(...) is incorrect on PPC32. Actually, it's ugly that PPC64_ONLY was used here. Should better be (support_IRIW_for_not_multiple_copy_atomic_cpu && wrote_volatile()), but that's not the topic of this change. Best regards, Martin -----Original Message----- From: hotspot-compiler-dev [mailto:hotspot-compiler-dev-bounces at openjdk.java.net] On Behalf Of Roland Westrelin Sent: Donnerstag, 8. Oktober 2015 13:51 To: Hui Shi Cc: hotspot compiler; aarch64-port-dev at openjdk.java.net Subject: Re: RFR: Elide more final field's write memory barrier with escape analysis result > http://cr.openjdk.java.net/~hshi/8138956/webrev/ The code change looks good to me. The comments have a few typos and are a bit confusing. I'll tweak them before I push it. PPC folks, in case you missed it, parse1.cpp has a ppc related fix. Roland. From adinn at redhat.com Mon Oct 12 13:20:55 2015 From: adinn at redhat.com (Andrew Dinn) Date: Mon, 12 Oct 2015 14:20:55 +0100 Subject: [aarch64-port-dev ] RFR: backport volatile put/get and CAS optimization to JDK8 In-Reply-To: <561695CF.5040002@redhat.com> References: <561695CF.5040002@redhat.com> Message-ID: <561BB3B7.6060009@redhat.com> I am reposting this patch against jdk8 for review with a caveat regarding use of the webrev. [briefly: I have stumbled into some weird behaviour in diff which causes it to report some non-existent differences; which means the webrev is slightly misleading as regards changes to file aarch64.ad diff was confused by the insertion of about 900 lines of ad rule predicates at line 960 of aarch64.ad. As a result it goes on to report some spurious differences in the pipe_class definitions between the old and new checkin version. The misleading reports conflate unchanged lines found in the sections from from the first pipe_class definition up to the start of the INSTRUCTIONS section with real changes adding add predicates to the rules matching LoadX and StoreX patterns. Luckily, these spurious changes are not reported in the hg changeset. So, it can be used to identify the changes actually made. ] So, could two AArch64 reviewers please review this fix using the change set embedded in the webrev to identify the changes to aarch64.ad: http://cr.openjdk.java.net/~adinn/jdk8volcasopt/webrev.00/hotspot.changeset The changes to other files can be still be viewed by referring to the webrev (or you can just stick with the webrev). Thanks. regards, Andrew Dinn ----------- On 08/10/15 17:11, Andrew Dinn wrote: > Here is a webrev against the latest aarch64-port-dev/jdk8/hotspot for > review: > > http://cr.openjdk.java.net/~adinn/jdk8volcasopt/webrev.00 > > It backports the jdk9-aarch64 optimizations which use ldar and stlr for > volatile gets and puts and unsafe CAS operations to jdk8-aarch64 > > So far, I have tested it (successfully) by eyeballing generated code for > some hand cranked tests that use volatiles and CASes in all 5 relevant > GC configurations (see below ***) and also running by netbeans and > eyeballing generated hash table code. > > I am currently running jcstress to fully test it on a Mustang in all GC > configs. > > Ed, would you be able to check that jcstress works fine on other hardware? > > *** GC configs are > -XX:+UseConcMarkSweepGC -XX:+UseCondCardMark > -XX:+UseConcMarkSweepGC -XX:-UseCondCardMark > -XX:+UseG1GC > -XX:+UseParallelGC -XX:+UseCondCardMark > -XX:+UseParallelGC -XX:-UseCondCardMark > > regards, > > > Andrew Dinn > ----------- From igor.veresov at oracle.com Mon Oct 12 20:45:49 2015 From: igor.veresov at oracle.com (Igor Veresov) Date: Mon, 12 Oct 2015 13:45:49 -0700 Subject: [aarch64-port-dev ] RFR: 8139259: aarch64: jtreg test TestLogSum segvs after 8132207 In-Reply-To: <8AF4C615-5E7A-425E-8883-5E7ECE2669E7@oracle.com> References: <1444389470.23861.23.camel@mint> <8AF4C615-5E7A-425E-8883-5E7ECE2669E7@oracle.com> Message-ID: <6E7C7761-DD7B-4CCB-AE6D-0ADA27385F83@oracle.com> This seems one of parts of the P1 blocker (https://bugs.openjdk.java.net/browse/JDK-8139454 ). Roland, could you please push this (at least the library_call.cpp part)? Thanks! igor > On Oct 9, 2015, at 5:23 AM, Roland Westrelin wrote: > > Hi Ed, > >> http://cr.openjdk.java.net/~enevill/8139259/webrev/ > > All 64 bit x86 cpus support sse2 so the new check in stubGenerator_x86_64.cpp is useless. Given in the interpreter and c1, we call the exp stub unconditionally, it didn?t really make sense that it was conditional on UseSSE in c2, anyway. Your library_call.cpp change looks good to me. I?ll sponsor it. > > Roland. From edward.nevill at gmail.com Tue Oct 13 15:19:21 2015 From: edward.nevill at gmail.com (Edward Nevill) Date: Tue, 13 Oct 2015 16:19:21 +0100 Subject: [aarch64-port-dev ] RFR: backport volatile put/get and CAS optimization to JDK8 In-Reply-To: <561695CF.5040002@redhat.com> References: <561695CF.5040002@redhat.com> Message-ID: <1444749561.25962.3.camel@mylittlepony.linaroharston> On Thu, 2015-10-08 at 17:11 +0100, Andrew Dinn wrote: > Ed, would you be able to check that jcstress works fine on other hardware? > > *** GC configs are > -XX:+UseConcMarkSweepGC -XX:+UseCondCardMark > -XX:+UseConcMarkSweepGC -XX:-UseCondCardMark > -XX:+UseG1GC > -XX:+UseParallelGC -XX:+UseCondCardMark > -XX:+UseParallelGC -XX:-UseCondCardMark All 5 configs tested fine on Cavium ThunderX. For the -XX:+UseG1GC run I had to use the following patch as well --- CUT HERE --- diff -r 2e58b602c89b src/share/vm/gc/g1/g1CodeCacheRemSet.cpp --- a/src/share/vm/gc/g1/g1CodeCacheRemSet.cpp Tue Sep 08 14:08:58 2015 +0100 +++ b/src/share/vm/gc/g1/g1CodeCacheRemSet.cpp Tue Sep 15 08:06:31 2015 +0000 @@ -197,7 +197,9 @@ } void G1CodeRootSet::allocate_small_table() { - _table = new CodeRootSetTable(SmallSize); + CodeRootSetTable* temp = new CodeRootSetTable(SmallSize); + + OrderAccess::release_store_ptr(&_table, temp); } void CodeRootSetTable::purge_list_append(CodeRootSetTable* table) { --- CUT HERE --- Should this be backported as well. Your patch is for jdk8, are we developing on jdk8 or jdk8u now? All the best, Ed. From roland.westrelin at oracle.com Tue Oct 13 16:00:46 2015 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Tue, 13 Oct 2015 18:00:46 +0200 Subject: [aarch64-port-dev ] RFR: 8139259: aarch64: jtreg test TestLogSum segvs after 8132207 In-Reply-To: <6E7C7761-DD7B-4CCB-AE6D-0ADA27385F83@oracle.com> References: <1444389470.23861.23.camel@mint> <8AF4C615-5E7A-425E-8883-5E7ECE2669E7@oracle.com> <6E7C7761-DD7B-4CCB-AE6D-0ADA27385F83@oracle.com> Message-ID: <26E9A4E5-3C55-4CB3-96FA-7783A02DBCDA@oracle.com> > This seems one of parts of the P1 blocker (https://bugs.openjdk.java.net/browse/JDK-8139454). Roland, could you please push this (at least the library_call.cpp part)? Sure. It?s in. Roland. From gnu.andrew at redhat.com Tue Oct 13 17:01:36 2015 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Tue, 13 Oct 2015 13:01:36 -0400 (EDT) Subject: [aarch64-port-dev ] CFV: New aarch64-port Committer: Andrew Hughes In-Reply-To: <56153499.6020309@redhat.com> References: <55FC1370.3060501@redhat.com> <56153499.6020309@redhat.com> Message-ID: <1314162665.30251650.1444755696287.JavaMail.zimbra@redhat.com> ----- Original Message ----- > Voting for Andrew Hughes [1] is now closed. > > Yes: 4 > Veto: 0 > Abstain: 0 > > According to the Bylaws definition of Lazy Consensus, this is > sufficient to approve the nomination. > > Andrew. > > [1] > http://mail.openjdk.java.net/pipermail/aarch64-port-dev/2015-September/002806.html > > > > > > Only just seen this; thanks :-) -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 PGP Key: rsa4096/248BDC07 (hkp://keys.gnupg.net) Fingerprint = EC5A 1F5E C0AD 1D15 8F1F 8F91 3B96 A578 248B DC07 From aph at redhat.com Tue Oct 13 17:14:33 2015 From: aph at redhat.com (aph at redhat.com) Date: Tue, 13 Oct 2015 17:14:33 +0000 Subject: [aarch64-port-dev ] hg: aarch64-port/jdk8u60/corba: Remove jcheck Message-ID: <201510131714.t9DHEXsl017329@aojmv0008.oracle.com> Changeset: b5b76162f723 Author: adinn Date: 2015-07-31 16:29 +0100 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u60/corba/rev/b5b76162f723 Remove jcheck - .jcheck/conf From aph at redhat.com Tue Oct 13 17:14:39 2015 From: aph at redhat.com (aph at redhat.com) Date: Tue, 13 Oct 2015 17:14:39 +0000 Subject: [aarch64-port-dev ] hg: aarch64-port/jdk8u60/jaxp: Remove jcheck Message-ID: <201510131714.t9DHEdhP017388@aojmv0008.oracle.com> Changeset: a58853121c57 Author: adinn Date: 2015-07-31 16:29 +0100 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u60/jaxp/rev/a58853121c57 Remove jcheck - .jcheck/conf From aph at redhat.com Tue Oct 13 17:14:46 2015 From: aph at redhat.com (aph at redhat.com) Date: Tue, 13 Oct 2015 17:14:46 +0000 Subject: [aarch64-port-dev ] hg: aarch64-port/jdk8u60/jaxws: Remove jcheck Message-ID: <201510131714.t9DHEk7F017449@aojmv0008.oracle.com> Changeset: 0b946a723bde Author: adinn Date: 2015-07-31 16:29 +0100 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u60/jaxws/rev/0b946a723bde Remove jcheck - .jcheck/conf From aph at redhat.com Tue Oct 13 17:14:52 2015 From: aph at redhat.com (aph at redhat.com) Date: Tue, 13 Oct 2015 17:14:52 +0000 Subject: [aarch64-port-dev ] hg: aarch64-port/jdk8u60/langtools: Remove jcheck Message-ID: <201510131714.t9DHEqjw017526@aojmv0008.oracle.com> Changeset: 780a4cdff52d Author: adinn Date: 2015-07-31 16:29 +0100 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u60/langtools/rev/780a4cdff52d Remove jcheck - .jcheck/conf From aph at redhat.com Tue Oct 13 17:14:58 2015 From: aph at redhat.com (aph at redhat.com) Date: Tue, 13 Oct 2015 17:14:58 +0000 Subject: [aarch64-port-dev ] hg: aarch64-port/jdk8u60/nashorn: Remove jcheck Message-ID: <201510131714.t9DHEw3X017601@aojmv0008.oracle.com> Changeset: f624fc4175eb Author: adinn Date: 2015-07-31 16:29 +0100 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u60/nashorn/rev/f624fc4175eb Remove jcheck - .jcheck/conf From aph at redhat.com Tue Oct 13 17:24:36 2015 From: aph at redhat.com (aph at redhat.com) Date: Tue, 13 Oct 2015 17:24:36 +0000 Subject: [aarch64-port-dev ] hg: aarch64-port/jdk8u60: 3 new changesets Message-ID: <201510131724.t9DHOajO019413@aojmv0008.oracle.com> Changeset: ef83b725647a Author: adinn Date: 2015-07-31 16:29 +0100 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u60/rev/ef83b725647a Remove jcheck - .jcheck/conf Changeset: d8f4022fe0cd Author: asaha Date: 2015-10-13 08:15 -0700 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u60/rev/d8f4022fe0cd Added tag jdk8u60-b28 for changeset 581a6452226f ! .hgtags Changeset: f4adb7396167 Author: aph Date: 2015-10-13 17:23 +0000 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u60/rev/f4adb7396167 Merge From aph at redhat.com Tue Oct 13 17:25:05 2015 From: aph at redhat.com (aph at redhat.com) Date: Tue, 13 Oct 2015 17:25:05 +0000 Subject: [aarch64-port-dev ] hg: aarch64-port/jdk8u60/hotspot: 2 new changesets Message-ID: <201510131725.t9DHP5v8019514@aojmv0008.oracle.com> Changeset: 37240c1019fd Author: asaha Date: 2015-10-13 08:16 -0700 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u60/hotspot/rev/37240c1019fd Added tag jdk8u60-b28 for changeset 621a3638fd8c ! .hgtags Changeset: 86939ae286e3 Author: aph Date: 2015-10-13 17:22 +0000 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u60/hotspot/rev/86939ae286e3 Merge ! .hgtags From aph at redhat.com Tue Oct 13 17:25:13 2015 From: aph at redhat.com (aph at redhat.com) Date: Tue, 13 Oct 2015 17:25:13 +0000 Subject: [aarch64-port-dev ] hg: aarch64-port/jdk8u60/jdk: 2 new changesets Message-ID: <201510131725.t9DHPD2s019569@aojmv0008.oracle.com> Changeset: 935758609767 Author: asaha Date: 2015-10-13 08:18 -0700 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u60/jdk/rev/935758609767 Added tag jdk8u60-b28 for changeset 48e79820c798 ! .hgtags Changeset: 03baff475f53 Author: aph Date: 2015-10-13 17:22 +0000 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u60/jdk/rev/03baff475f53 Merge ! .hgtags From aph at redhat.com Tue Oct 13 17:25:19 2015 From: aph at redhat.com (aph at redhat.com) Date: Tue, 13 Oct 2015 17:25:19 +0000 Subject: [aarch64-port-dev ] hg: aarch64-port/jdk8u60/corba: 2 new changesets Message-ID: <201510131725.t9DHPJwf019644@aojmv0008.oracle.com> Changeset: 594da4d5c1a2 Author: asaha Date: 2015-10-13 08:15 -0700 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u60/corba/rev/594da4d5c1a2 Added tag jdk8u60-b28 for changeset ded04a5df66c ! .hgtags Changeset: d08f09dbabea Author: aph Date: 2015-10-13 17:20 +0000 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u60/corba/rev/d08f09dbabea Merge From aph at redhat.com Tue Oct 13 17:25:25 2015 From: aph at redhat.com (aph at redhat.com) Date: Tue, 13 Oct 2015 17:25:25 +0000 Subject: [aarch64-port-dev ] hg: aarch64-port/jdk8u60/jaxp: 2 new changesets Message-ID: <201510131725.t9DHPPoE019699@aojmv0008.oracle.com> Changeset: 4dcdddcc8659 Author: asaha Date: 2015-10-13 08:17 -0700 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u60/jaxp/rev/4dcdddcc8659 Added tag jdk8u60-b28 for changeset c70d5a9bf4e0 ! .hgtags Changeset: 7573dfd0fcd2 Author: aph Date: 2015-10-13 17:20 +0000 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u60/jaxp/rev/7573dfd0fcd2 Merge From aph at redhat.com Tue Oct 13 17:25:31 2015 From: aph at redhat.com (aph at redhat.com) Date: Tue, 13 Oct 2015 17:25:31 +0000 Subject: [aarch64-port-dev ] hg: aarch64-port/jdk8u60/jaxws: 2 new changesets Message-ID: <201510131725.t9DHPVeb019776@aojmv0008.oracle.com> Changeset: 51bafda870a9 Author: asaha Date: 2015-10-13 08:17 -0700 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u60/jaxws/rev/51bafda870a9 Added tag jdk8u60-b28 for changeset b0fa9d6c0145 ! .hgtags Changeset: 42672f59c361 Author: aph Date: 2015-10-13 17:20 +0000 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u60/jaxws/rev/42672f59c361 Merge From aph at redhat.com Tue Oct 13 17:25:37 2015 From: aph at redhat.com (aph at redhat.com) Date: Tue, 13 Oct 2015 17:25:37 +0000 Subject: [aarch64-port-dev ] hg: aarch64-port/jdk8u60/langtools: 2 new changesets Message-ID: <201510131725.t9DHPbSk019834@aojmv0008.oracle.com> Changeset: b9abf5c3d057 Author: asaha Date: 2015-10-13 08:20 -0700 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u60/langtools/rev/b9abf5c3d057 Added tag jdk8u60-b28 for changeset d56703662c0f ! .hgtags Changeset: 355cd0bded7b Author: aph Date: 2015-10-13 17:20 +0000 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u60/langtools/rev/355cd0bded7b Merge From aph at redhat.com Tue Oct 13 17:25:43 2015 From: aph at redhat.com (aph at redhat.com) Date: Tue, 13 Oct 2015 17:25:43 +0000 Subject: [aarch64-port-dev ] hg: aarch64-port/jdk8u60/nashorn: 2 new changesets Message-ID: <201510131725.t9DHPhq3019885@aojmv0008.oracle.com> Changeset: 5a6f6f81ffdf Author: asaha Date: 2015-10-13 08:20 -0700 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u60/nashorn/rev/5a6f6f81ffdf Added tag jdk8u60-b28 for changeset cb42d6d091cd ! .hgtags Changeset: 722941ee8fbe Author: aph Date: 2015-10-13 17:20 +0000 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u60/nashorn/rev/722941ee8fbe Merge From hui.shi at linaro.org Wed Oct 14 12:48:25 2015 From: hui.shi at linaro.org (Hui Shi) Date: Wed, 14 Oct 2015 20:48:25 +0800 Subject: [aarch64-port-dev ] RFR: Elide more final field's write memory barrier with escape analysis result In-Reply-To: <7C9B87B351A4BA4AA9EC95BB4181165672261384@DEWDFEMB19C.global.corp.sap> References: <5612A2C6.5080108@redhat.com> <7C9B87B351A4BA4AA9EC95BB4181165672261165@DEWDFEMB19C.global.corp.sap> <7C9B87B351A4BA4AA9EC95BB4181165672261384@DEWDFEMB19C.global.corp.sap> Message-ID: Thanks Martin! Roland, would you please run JPRT test and sponsor this change? Regards Shi Hui On 12 October 2015 at 17:39, Doerr, Martin wrote: > Hi Hui Shi, > > > > thanks for the update. Looks good for PPC64 as well, now. > > As you already explained, the MemBarRelease is only relevant for fields of > the allocated object. Hence, the final and volatile cases can be handled > the same way. > > > > Best regards, > > Martin > > > > > > *From:* Hui Shi [mailto:hui.shi at linaro.org] > *Sent:* Samstag, 10. Oktober 2015 15:25 > *To:* Doerr, Martin > *Cc:* Roland Westrelin; hotspot compiler; > aarch64-port-dev at openjdk.java.net > > *Subject:* Re: RFR: Elide more final field's write memory barrier with > escape analysis result > > > > Thanks Roland and Martin! > > > > Agree, it's better remove extra code for PPC64. new webrev > http://cr.openjdk.java.net/~hshi/8138956/webrev_v2/ > > comments below > > > > Regards > > Shi Hui > > > > On 10 October 2015 at 00:17, Doerr, Martin wrote: > > Hi, > > I basically like this change. Thanks for pointing me to it. > > But I don't like the extra code for PPC64. If the allocation does not > escape globally it should be safe to elide the membar regardless of whether > we wrote final or volatile fields. > > > > Difference is final field is always belonging to initializing object while > volatile field isn't. It's reasonable to insert MemoryBarrier, when > volatile field is written in its owning class' initializer method, like you > example of AtomicInteger. > > > > In following example, class A initiailzer writes both final field and > volatile field, suppose A instance doesn't escape. MemBarRelase is inserted > because final and volatile field wirte. Writing b.vol in A's initializer is > same with writing b.vol in none-initalizer method and doesn't need > MemBarRelease in my understanding. > > > > 1. If final and volatile field from same allocation, > elide MemBarRelase when allocation doesn't escape is safe. > > 2. If volatile field doesn't belong to final field's allocation object, > MemBarRelase for volatile is not necessary. > > So it's safe to remove MemBarRelease when final field's allocation object > doesn't escape. > > > > Class A { > > final int a; > > A(int val, B b) { a=val; b.vol = val; } > > } > > > > Class B { volatile int vol;} > > > > > > Please also note that PPC64_ONLY(...) NOT_PPC(...) is incorrect on PPC32. > > Actually, it's ugly that PPC64_ONLY was used here. Should better be > (support_IRIW_for_not_multiple_copy_atomic_cpu && wrote_volatile()), but > that's not the topic of this change. > > Best regards, > Martin > > > > -----Original Message----- > From: hotspot-compiler-dev [mailto: > hotspot-compiler-dev-bounces at openjdk.java.net] On Behalf Of Roland > Westrelin > Sent: Donnerstag, 8. Oktober 2015 13:51 > To: Hui Shi > Cc: hotspot compiler; aarch64-port-dev at openjdk.java.net > Subject: Re: RFR: Elide more final field's write memory barrier with > escape analysis result > > > http://cr.openjdk.java.net/~hshi/8138956/webrev/ > > The code change looks good to me. The comments have a few typos and are a > bit confusing. I'll tweak them before I push it. > > PPC folks, in case you missed it, parse1.cpp has a ppc related fix. > > Roland. > > > From edward.nevill at gmail.com Wed Oct 14 13:50:48 2015 From: edward.nevill at gmail.com (Edward Nevill) Date: Wed, 14 Oct 2015 14:50:48 +0100 Subject: [aarch64-port-dev ] Project proposal: AArch32 port Message-ID: <1444830648.7802.34.camel@mylittlepony.linaroharston> Hi, I would like to propose the creation of a new project to port OpenJDK to ARM's aarch32 architecture. The aarch32 architecture is the 32 bit side of the ARMv8 architecture (the other side being aarch64). There is already a port for aarch64 which has been upstreamed into JDK9, thanks to the great work of Andrew Haley, Andrew Dinn and others however 32 bit support is missing. The aarch64 architecture is broadly compatible with ARMv7 with only a few minor differences most of which are not applicable to application level code. It is proposed that the aarch32 port will also support ARMv7. ARMv6 could also be supported, but this would depend on the level of community interest (ARMv6 is the architecture in the Raspberry Pi so there may be significant community interest and involvement if we were also to target ARMv6). We already have a complete template interpreter thanks to the excellent work of Joseph Joyce who presented his work at the recent Linaro Connect conference. A copy of his slides is available at http://openjdk.linaro.org/sfo15-openjdk-arm32.pdf I have created a JIRA issue and uploaded webrevs of this port based on JDK 9 to cr.openjdk.java.net. JIRA Issue: https://bugs.openjdk.java.net/browse/JDK-8139303 Webrevs: http://cr.openjdk.java.net/~enevill/8139303/webrev.hotspot/ http://cr.openjdk.java.net/~enevill/8139303/webrev.hs-comp/ http://cr.openjdk.java.net/~enevill/8139303/webrev.jdk/ The template interpreter is complete and runs a large variety of applications (eclipse, jedit, galaxians, javac, although sadly it cannot build itself as yet:-). It is intended that the port will be a complete port of OpenJDK to include Template Interpreter / C1 and possibly C2. Can I please request the support of the Porters Group as the Sponsoring Group with myself as project lead. Many thanks, Edward Nevill From adinn at redhat.com Wed Oct 14 14:13:54 2015 From: adinn at redhat.com (Andrew Dinn) Date: Wed, 14 Oct 2015 15:13:54 +0100 Subject: [aarch64-port-dev ] RFR: backport volatile put/get and CAS optimization to JDK8 In-Reply-To: <1444749561.25962.3.camel@mylittlepony.linaroharston> References: <561695CF.5040002@redhat.com> <1444749561.25962.3.camel@mylittlepony.linaroharston> Message-ID: <561E6322.9000000@redhat.com> On 13/10/15 16:19, Edward Nevill wrote: > On Thu, 2015-10-08 at 17:11 +0100, Andrew Dinn wrote: >> Ed, would you be able to check that jcstress works fine on other hardware? >> >> *** GC configs are >> -XX:+UseConcMarkSweepGC -XX:+UseCondCardMark >> -XX:+UseConcMarkSweepGC -XX:-UseCondCardMark >> -XX:+UseG1GC >> -XX:+UseParallelGC -XX:+UseCondCardMark >> -XX:+UseParallelGC -XX:-UseCondCardMark > > All 5 configs tested fine on Cavium ThunderX. All tests passed on my Mustang as well. So, I think we are ok to push this. > For the -XX:+UseG1GC run I had to use the following patch as well > > --- CUT HERE --- > diff -r 2e58b602c89b src/share/vm/gc/g1/g1CodeCacheRemSet.cpp > --- a/src/share/vm/gc/g1/g1CodeCacheRemSet.cpp Tue Sep 08 14:08:58 2015 +0100 > +++ b/src/share/vm/gc/g1/g1CodeCacheRemSet.cpp Tue Sep 15 08:06:31 2015 +0000 > @@ -197,7 +197,9 @@ > } > > void G1CodeRootSet::allocate_small_table() { > - _table = new CodeRootSetTable(SmallSize); > + CodeRootSetTable* temp = new CodeRootSetTable(SmallSize); > + > + OrderAccess::release_store_ptr(&_table, temp); > } > > void CodeRootSetTable::purge_list_append(CodeRootSetTable* table) { > --- CUT HERE --- > > Should this be backported as well. Yes, I guess so, since g1 needs it. I'll push the upstream patch as well as my patch so it doesn't cause any problems if we end up merging it from upstream later. > Your patch is for jdk8, are we developing on jdk8 or jdk8u now? I just reviewed this with Andrew Haley and the story is as follows. jdk8 is still being used as the development tree (yes, I know that's a bit confusing modulo how it works upstream but nevertheless ...). jdk8u will (soon) be set up to auto-merge upstream jdk8u updates daily. That way we can identify merge issues separate from development. So, this means that any changes which go into jdk8 should also -- at some point -- be backported into jdk8u. I expect that most of the time that will simply involve applying the same patch although, no doubt, in some cases we may need to wield the crowbar. regards, Andrew Dinn ----------- From gnu.andrew at redhat.com Wed Oct 14 15:52:26 2015 From: gnu.andrew at redhat.com (gnu.andrew at redhat.com) Date: Wed, 14 Oct 2015 15:52:26 +0000 Subject: [aarch64-port-dev ] hg: aarch64-port/jdk8u60: Added tag aarch64-jdk8u60-b28 for changeset f4adb7396167 Message-ID: <201510141552.t9EFqQDt029785@aojmv0008.oracle.com> Changeset: c2f56786db32 Author: andrew Date: 2015-10-14 16:50 +0100 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u60/rev/c2f56786db32 Added tag aarch64-jdk8u60-b28 for changeset f4adb7396167 ! .hgtags From gnu.andrew at redhat.com Wed Oct 14 15:52:33 2015 From: gnu.andrew at redhat.com (gnu.andrew at redhat.com) Date: Wed, 14 Oct 2015 15:52:33 +0000 Subject: [aarch64-port-dev ] hg: aarch64-port/jdk8u60/corba: Added tag aarch64-jdk8u60-b28 for changeset d08f09dbabea Message-ID: <201510141552.t9EFqXx6029860@aojmv0008.oracle.com> Changeset: 7be18fe52445 Author: andrew Date: 2015-10-14 16:50 +0100 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u60/corba/rev/7be18fe52445 Added tag aarch64-jdk8u60-b28 for changeset d08f09dbabea ! .hgtags From gnu.andrew at redhat.com Wed Oct 14 15:52:40 2015 From: gnu.andrew at redhat.com (gnu.andrew at redhat.com) Date: Wed, 14 Oct 2015 15:52:40 +0000 Subject: [aarch64-port-dev ] hg: aarch64-port/jdk8u60/jaxp: Added tag aarch64-jdk8u60-b28 for changeset 7573dfd0fcd2 Message-ID: <201510141552.t9EFqeR2029977@aojmv0008.oracle.com> Changeset: 4d1bd3458e64 Author: andrew Date: 2015-10-14 16:50 +0100 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u60/jaxp/rev/4d1bd3458e64 Added tag aarch64-jdk8u60-b28 for changeset 7573dfd0fcd2 ! .hgtags From gnu.andrew at redhat.com Wed Oct 14 15:52:45 2015 From: gnu.andrew at redhat.com (gnu.andrew at redhat.com) Date: Wed, 14 Oct 2015 15:52:45 +0000 Subject: [aarch64-port-dev ] hg: aarch64-port/jdk8u60/jaxws: Added tag aarch64-jdk8u60-b28 for changeset 42672f59c361 Message-ID: <201510141552.t9EFqjHS000046@aojmv0008.oracle.com> Changeset: 72dda8b5dbc8 Author: andrew Date: 2015-10-14 16:50 +0100 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u60/jaxws/rev/72dda8b5dbc8 Added tag aarch64-jdk8u60-b28 for changeset 42672f59c361 ! .hgtags From gnu.andrew at redhat.com Wed Oct 14 15:52:51 2015 From: gnu.andrew at redhat.com (gnu.andrew at redhat.com) Date: Wed, 14 Oct 2015 15:52:51 +0000 Subject: [aarch64-port-dev ] hg: aarch64-port/jdk8u60/langtools: Added tag aarch64-jdk8u60-b28 for changeset 355cd0bded7b Message-ID: <201510141552.t9EFqpUM000133@aojmv0008.oracle.com> Changeset: 0e15b15cfaae Author: andrew Date: 2015-10-14 16:50 +0100 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u60/langtools/rev/0e15b15cfaae Added tag aarch64-jdk8u60-b28 for changeset 355cd0bded7b ! .hgtags From gnu.andrew at redhat.com Wed Oct 14 15:52:57 2015 From: gnu.andrew at redhat.com (gnu.andrew at redhat.com) Date: Wed, 14 Oct 2015 15:52:57 +0000 Subject: [aarch64-port-dev ] hg: aarch64-port/jdk8u60/hotspot: Added tag aarch64-jdk8u60-b28 for changeset 86939ae286e3 Message-ID: <201510141552.t9EFqvOA000189@aojmv0008.oracle.com> Changeset: 023f3dbe93cb Author: andrew Date: 2015-10-14 16:50 +0100 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u60/hotspot/rev/023f3dbe93cb Added tag aarch64-jdk8u60-b28 for changeset 86939ae286e3 ! .hgtags From gnu.andrew at redhat.com Wed Oct 14 15:53:04 2015 From: gnu.andrew at redhat.com (gnu.andrew at redhat.com) Date: Wed, 14 Oct 2015 15:53:04 +0000 Subject: [aarch64-port-dev ] hg: aarch64-port/jdk8u60/jdk: Added tag aarch64-jdk8u60-b28 for changeset 03baff475f53 Message-ID: <201510141553.t9EFr4KM000243@aojmv0008.oracle.com> Changeset: b4a643648fa2 Author: andrew Date: 2015-10-14 16:50 +0100 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u60/jdk/rev/b4a643648fa2 Added tag aarch64-jdk8u60-b28 for changeset 03baff475f53 ! .hgtags From gnu.andrew at redhat.com Wed Oct 14 15:53:10 2015 From: gnu.andrew at redhat.com (gnu.andrew at redhat.com) Date: Wed, 14 Oct 2015 15:53:10 +0000 Subject: [aarch64-port-dev ] hg: aarch64-port/jdk8u60/nashorn: Added tag aarch64-jdk8u60-b28 for changeset 722941ee8fbe Message-ID: <201510141553.t9EFrBEu000297@aojmv0008.oracle.com> Changeset: a489d9ca618b Author: andrew Date: 2015-10-14 16:50 +0100 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u60/nashorn/rev/a489d9ca618b Added tag aarch64-jdk8u60-b28 for changeset 722941ee8fbe ! .hgtags From roland.westrelin at oracle.com Thu Oct 15 11:30:43 2015 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Thu, 15 Oct 2015 13:30:43 +0200 Subject: [aarch64-port-dev ] RFR: Elide more final field's write memory barrier with escape analysis result In-Reply-To: References: <5612A2C6.5080108@redhat.com> <7C9B87B351A4BA4AA9EC95BB4181165672261165@DEWDFEMB19C.global.corp.sap> <7C9B87B351A4BA4AA9EC95BB4181165672261384@DEWDFEMB19C.global.corp.sap> Message-ID: <2CCD93AB-716E-4D81-A5B1-C008BC61E0F9@oracle.com> > Roland, would you please run JPRT test and sponsor this change? It?s in. Roland. From edward.nevill at gmail.com Thu Oct 15 15:51:05 2015 From: edward.nevill at gmail.com (Edward Nevill) Date: Thu, 15 Oct 2015 16:51:05 +0100 Subject: [aarch64-port-dev ] RFR: 8139674: aarch64: guarantee failure in TestOptionsWithRanges.java Message-ID: <1444924265.30110.11.camel@mylittlepony.linaroharston> Hi, Please review the following webrev http://cr.openjdk.java.net/~enevill/8139674/webrev/ JIRA issue: https://bugs.openjdk.java.net/browse/JDK-8139674 The hotspot jtreg test runtime/CommandLine/OptionsValidation/TestOptionsWithRanges.java fails with a guarantee failure. # A fatal error has been detected by the Java Runtime Environment: # # Internal Error (assembler_aarch64.hpp:256), pid=22842, tid=22845 # guarantee(chk == -1 || chk == 0) failed: Field too big for insn What is happening is that the code in InterpreterMacroAssembler::profile_arguments_type adjusts mdp to point past the arguments and uses negative offsets to index fields at the start of the method data structure. However, negative ldr offsets are very limited on aarch64 (-256 bytes) so this easily overflows when TypeProfileArgsLimit is large (>=16). The solution is to defer incrementing mdp until we are finished with all the args and use positive offsets instead. Tested with hotspot jtreg Before: Test results: passed: 896; failed: 6; error: 10 After: Test results: passed: 896; failed: 5; error: 10 Thanks for your help, Ed. From vladimir.kozlov at oracle.com Fri Oct 16 00:53:27 2015 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 16 Oct 2015 08:53:27 +0800 Subject: [aarch64-port-dev ] RFR: 8139674: aarch64: guarantee failure in TestOptionsWithRanges.java In-Reply-To: <1444924265.30110.11.camel@mylittlepony.linaroharston> References: <1444924265.30110.11.camel@mylittlepony.linaroharston> Message-ID: <56204A87.7050105@oracle.com> I don't think removing next line is right: - add(mdp, mdp, to_add); it shifts to next metadata cell. Also both exit paths execute the same instruction: + add(rscratch1, mdp, off_to_args); may be you can simplify exit without them: bind(done); + add(mdp, mdp, off_to_args); Thanks, Vladimir On 10/15/15 11:51 PM, Edward Nevill wrote: > Hi, > > Please review the following webrev > > http://cr.openjdk.java.net/~enevill/8139674/webrev/ > > JIRA issue: https://bugs.openjdk.java.net/browse/JDK-8139674 > > > The hotspot jtreg test runtime/CommandLine/OptionsValidation/TestOptionsWithRanges.java fails with a guarantee failure. > > # A fatal error has been detected by the Java Runtime Environment: > # > # Internal Error (assembler_aarch64.hpp:256), pid=22842, tid=22845 > # guarantee(chk == -1 || chk == 0) failed: Field too big for insn > > What is happening is that the code in InterpreterMacroAssembler::profile_arguments_type adjusts mdp to point past the arguments and uses negative offsets to index fields at the start of the method data structure. > > However, negative ldr offsets are very limited on aarch64 (-256 bytes) so this easily overflows when TypeProfileArgsLimit is large (>=16). > > The solution is to defer incrementing mdp until we are finished with all the args and use positive offsets instead. > > Tested with hotspot jtreg > > Before: Test results: passed: 896; failed: 6; error: 10 > After: Test results: passed: 896; failed: 5; error: 10 > > Thanks for your help, > Ed. > > From roland.westrelin at oracle.com Fri Oct 16 09:02:01 2015 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Fri, 16 Oct 2015 11:02:01 +0200 Subject: [aarch64-port-dev ] RFR: 8139674: aarch64: guarantee failure in TestOptionsWithRanges.java In-Reply-To: <56204A87.7050105@oracle.com> References: <1444924265.30110.11.camel@mylittlepony.linaroharston> <56204A87.7050105@oracle.com> Message-ID: > I don't think removing next line is right: > > - add(mdp, mdp, to_add); > > it shifts to next metadata cell. Yes, we shift to the next argument slot. We also do: off_to_args += to_add; and then data in the slot is addressed with: in_bytes(TypeEntriesAtCall::stack_slot_offset(i))-off_to_args that is relative to the current argument slot. before the change. After the change, it?s adjusted to: in_bytes(TypeEntriesAtCall::stack_slot_offset(i)) that is relative to the beginning of the space allocated for all arguments. So I think it?s good. This said, this: >> What is happening is that the code in InterpreterMacroAssembler::profile_arguments_type adjusts mdp to point past the arguments and uses negative offsets to index fields at the start of the method data structure. is not correct I think. We don?t move past the arguments. We move to the beginning of the slot dedicated to the next argument, not past it. The only source of negative offsets I can see is: 1555 ldr(tmp, Address(mdp, in_bytes(TypeEntriesAtCall::cell_count_offset())-off_to_args)); Roland. From edward.nevill at gmail.com Fri Oct 16 09:12:41 2015 From: edward.nevill at gmail.com (Edward Nevill) Date: Fri, 16 Oct 2015 10:12:41 +0100 Subject: [aarch64-port-dev ] RFR: 8139674: aarch64: guarantee failure in TestOptionsWithRanges.java In-Reply-To: <56204A87.7050105@oracle.com> References: <1444924265.30110.11.camel@mylittlepony.linaroharston> <56204A87.7050105@oracle.com> Message-ID: <1444986761.22434.29.camel@mint> Hi Vladimir, Thanks for the review. On Fri, 2015-10-16 at 08:53 +0800, Vladimir Kozlov wrote: > I don't think removing next line is right: > > - add(mdp, mdp, to_add); > > it shifts to next metadata cell. I believe removal of this line is correct. The old code kept mdp pointing at the current metadata cell that it was processing. This is what lead to the large negative offsets when it was trying to index the two fields at the start of the metadata structure. So in the old code, to process each metatdata cell it did. Address mdo_arg_addr(mdp, in_bytes(TypeEntriesAtCall::argument_type_offset(i))-off_to_args); profile_obj_type(tmp, mdo_arg_addr); In the revised code it does Address mdo_arg_addr(mdp, in_bytes(TypeEntriesAtCall::argument_type_offset(i))); profile_obj_type(tmp, mdo_arg_addr); 'off_to_args' is updated by 'to_add' each time round the loop. off_to_args += to_add; So in the old code the address of the metadata cell was calculated as mdp + in_bytes(TypeEntriesAtCall::argument_type_offset(i))-off_to_args Note: 'in_bytes(TypeEntriesAtCall::argument_type_offset(i))-off_to_args' always evaluates to 0! In the revised code the address is calculated as 'in_bytes(TypeEntriesAtCall::argument_type_offset(i))' which evaluates to the same address since mdp is no longer offset by 'off_to_args'. > > Also both exit paths execute the same instruction: > > + add(rscratch1, mdp, off_to_args); > > may be you can simplify exit without them: > > bind(done); > + add(mdp, mdp, off_to_args); I don't believe the exit can be simplified. The reason is that 'off_to_args' is different for each iteration around the loop. So in assembler what we will have is add x8, x0, #8 // x0 == mdp, offset to arg 0 == 8 blt done ... add x8, x0, #0x18 // arg 1 offset = 0x18 blt done .... add x8, x0, #0x108 // fallthru case done: mov x0, x8 So, mdp is updated by a different immediate value in each case, so we cannot merge them into a single case done: add x0, x0, #N // N == ??? Thanks for your help, Ed. From adinn at redhat.com Fri Oct 16 09:43:44 2015 From: adinn at redhat.com (Andrew Dinn) Date: Fri, 16 Oct 2015 10:43:44 +0100 Subject: [aarch64-port-dev ] RFR: 8139674: aarch64: guarantee failure in TestOptionsWithRanges.java In-Reply-To: References: <1444924265.30110.11.camel@mylittlepony.linaroharston> <56204A87.7050105@oracle.com> Message-ID: <5620C6D0.3050704@redhat.com> On 16/10/15 10:02, Roland Westrelin wrote: >> I don't think removing next line is right: >> >> - add(mdp, mdp, to_add); >> >> it shifts to next metadata cell. > > Yes, we shift to the next argument slot. We also do: > > off_to_args += to_add; > > and then data in the slot is addressed with: > > in_bytes(TypeEntriesAtCall::stack_slot_offset(i))-off_to_args > > that is relative to the current argument slot. > > before the change. After the change, it?s adjusted to: > > in_bytes(TypeEntriesAtCall::stack_slot_offset(i)) > > that is relative to the beginning of the space allocated for all arguments. So I think it?s good. I agree with Roland that this change set is good. As he points out, in the new code off_to_args is being updated every time round the loop 1575 off_to_args += to_add; So, the add instructions generated at 1557 add(rscratch1, mdp, off_to_args); and 1583 add(rscratch1, mdp, off_to_args); will be inserting different positive constants into the generated instruction stream depending on the current value of off_to_args. > This said, this: > >>> What is happening is that the code in InterpreterMacroAssembler::profile_arguments_type adjusts mdp to point past the arguments and uses negative offsets to index fields at the start of the method data structure. > > is not correct I think. We don?t move past the arguments. We move to the beginning of the slot dedicated to the next argument, not past it. The only source of negative offsets I can see is: > > 1555 ldr(tmp, Address(mdp, in_bytes(TypeEntriesAtCall::cell_count_offset())-off_to_args)); What Ed said made sense to me. The old code executed 1550 add(mdp, mdp, off_to_args); before the loop i.e. it left mdp pointing just past the args. Subsequent ldr instructions then used a negative offset from this updated mdp register to address the arg slots which precede the slot addressed by mdp. Anyway, whatever the status regarding validity/clarity of the explanation Ed provided in the accompanying mail note the actual code changes look correct to me. 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 vladimir.kozlov at oracle.com Fri Oct 16 10:13:41 2015 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 16 Oct 2015 18:13:41 +0800 Subject: [aarch64-port-dev ] RFR: 8139674: aarch64: guarantee failure in TestOptionsWithRanges.java In-Reply-To: <1444986761.22434.29.camel@mint> References: <1444924265.30110.11.camel@mylittlepony.linaroharston> <56204A87.7050105@oracle.com> <1444986761.22434.29.camel@mint> Message-ID: <5620CDD5.6090301@oracle.com> On 10/16/15 5:12 PM, Edward Nevill wrote: > Hi Vladimir, > > Thanks for the review. > > On Fri, 2015-10-16 at 08:53 +0800, Vladimir Kozlov wrote: >> I don't think removing next line is right: >> >> - add(mdp, mdp, to_add); >> >> it shifts to next metadata cell. > > I believe removal of this line is correct. The old code kept mdp pointing at the current metadata cell that it was processing. This is what lead to the large negative offsets when it was trying to index the two fields at the start of the metadata structure. > > So in the old code, to process each metatdata cell it did. > > Address mdo_arg_addr(mdp, in_bytes(TypeEntriesAtCall::argument_type_offset(i))-off_to_args); > profile_obj_type(tmp, mdo_arg_addr); > > In the revised code it does > > Address mdo_arg_addr(mdp, in_bytes(TypeEntriesAtCall::argument_type_offset(i))); > profile_obj_type(tmp, mdo_arg_addr); > > 'off_to_args' is updated by 'to_add' each time round the loop. > > off_to_args += to_add; > > So in the old code the address of the metadata cell was calculated as > > mdp + in_bytes(TypeEntriesAtCall::argument_type_offset(i))-off_to_args > > Note: 'in_bytes(TypeEntriesAtCall::argument_type_offset(i))-off_to_args' always evaluates to 0! > > In the revised code the address is calculated as 'in_bytes(TypeEntriesAtCall::argument_type_offset(i))' which evaluates to the same address since mdp is no longer offset by 'off_to_args'. Make sense. Thank you for explanation. > >> >> Also both exit paths execute the same instruction: >> >> + add(rscratch1, mdp, off_to_args); >> >> may be you can simplify exit without them: >> >> bind(done); >> + add(mdp, mdp, off_to_args); > > I don't believe the exit can be simplified. > > The reason is that 'off_to_args' is different for each iteration around the loop. So in assembler what we will have is > > add x8, x0, #8 // x0 == mdp, offset to arg 0 == 8 > blt done > ... > add x8, x0, #0x18 // arg 1 offset = 0x18 > blt done > .... > > add x8, x0, #0x108 // fallthru case > done: > mov x0, x8 > > So, mdp is updated by a different immediate value in each case, so we cannot merge them into a single case Okay, I missed that off_to_args is changing. Looks good. Thanks, Vladimir > > done: > add x0, x0, #N // N == ??? > > Thanks for your help, > Ed. > > From roland.westrelin at oracle.com Fri Oct 16 14:00:25 2015 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Fri, 16 Oct 2015 16:00:25 +0200 Subject: [aarch64-port-dev ] RFR: Elide more final field's write memory barrier with escape analysis result In-Reply-To: <2CCD93AB-716E-4D81-A5B1-C008BC61E0F9@oracle.com> References: <5612A2C6.5080108@redhat.com> <7C9B87B351A4BA4AA9EC95BB4181165672261165@DEWDFEMB19C.global.corp.sap> <7C9B87B351A4BA4AA9EC95BB4181165672261384@DEWDFEMB19C.global.corp.sap> <2CCD93AB-716E-4D81-A5B1-C008BC61E0F9@oracle.com> Message-ID: Unfortunately that change caused a lot of failures during our nightly testing and we are backing it out. https://bugs.openjdk.java.net/browse/JDK-8139750 is the bug that cover those failures. I could reproduce one of those failures by running java/util/Map/Defaults.java with options: -server -Xcomp -XX:MaxRAMFraction=8 -XX:+CreateCoredumpOnCrash -ea -esa -XX:+TieredCompilation -XX:CompileThreshold=100 -XX:+UnlockExperimentalVMOptions -XX:+IgnoreUnrecognizedVMOptions -XX:+AggressiveOpts -XX:-UseBiasedLocking I created a redo issue in case this is resubmitted: https://bugs.openjdk.java.net/browse/JDK-8139758 Roland. From hui.shi at linaro.org Fri Oct 16 14:51:04 2015 From: hui.shi at linaro.org (Hui Shi) Date: Fri, 16 Oct 2015 22:51:04 +0800 Subject: [aarch64-port-dev ] RFR: Elide more final field's write memory barrier with escape analysis result In-Reply-To: References: <5612A2C6.5080108@redhat.com> <7C9B87B351A4BA4AA9EC95BB4181165672261165@DEWDFEMB19C.global.corp.sap> <7C9B87B351A4BA4AA9EC95BB4181165672261384@DEWDFEMB19C.global.corp.sap> <2CCD93AB-716E-4D81-A5B1-C008BC61E0F9@oracle.com> Message-ID: Thanks for help back out! This looks assertion in PhaseIdealLoop::compute_lca_of_uses when verify dominance, will look at this. Regards Shi Hui On 16 October 2015 at 22:00, Roland Westrelin wrote: > Unfortunately that change caused a lot of failures during our nightly > testing and we are backing it out. > > https://bugs.openjdk.java.net/browse/JDK-8139750 is the bug that cover > those failures. I could reproduce one of those failures by running > java/util/Map/Defaults.java with options: > -server -Xcomp -XX:MaxRAMFraction=8 -XX:+CreateCoredumpOnCrash -ea -esa > -XX:+TieredCompilation -XX:CompileThreshold=100 > -XX:+UnlockExperimentalVMOptions -XX:+IgnoreUnrecognizedVMOptions > -XX:+AggressiveOpts -XX:-UseBiasedLocking > > I created a redo issue in case this is resubmitted: > > https://bugs.openjdk.java.net/browse/JDK-8139758 > > Roland. From edward.nevill at gmail.com Tue Oct 20 15:49:39 2015 From: edward.nevill at gmail.com (Edward Nevill) Date: Tue, 20 Oct 2015 16:49:39 +0100 Subject: [aarch64-port-dev ] Changesets to backport to jdk8 Message-ID: <1445356179.20265.9.camel@mylittlepony.linaroharston> Hi, I would like to backport the changesets below from jdk9 to jdk8. Tested with jtreg hotspot and langtools, results before and after were Hotspot: Test results: passed: 675; failed: 17; error: 2 Langtools: Test results: passed: 3,089 A webrev of the changes is available at http://cr.openjdk.java.net/~enevill/jdk8-backports-1510/webrev OK to push? Ed. --- CUT HERE --- changeset: 8568:1c63a35618ff tag: tip user: ecaspole date: Mon Sep 21 10:36:36 2015 -0400 files: src/share/vm/gc_implementation/g1/g1CodeCacheRemSet.cpp description: 8131645: [ARM64] crash on Cavium when using G1 Summary: Add a fence when creating the CodeRootSetTable so the readers do not see invalid memory. Reviewed-by: aph, tschatzl changeset: 8567:25335f4d32fe user: enevill date: Thu Oct 15 15:33:54 2015 +0000 files: src/cpu/aarch64/vm/interp_masm_aarch64.cpp description: 8139674: aarch64: guarantee failure in TestOptionsWithRanges.java Summary: Fix negative overflow in instruction field Reviewed-by: kvn, roland, adinn, aph changeset: 8566:f65f72fac5ca user: aph date: Tue Sep 29 17:01:37 2015 +0000 files: src/cpu/aarch64/vm/macroAssembler_aarch64.cpp src/cpu/aarch64/vm/macroAssembler_aarch64.hpp description: 8138575: Improve generated code for profile counters Reviewed-by: kvn changeset: 8565:7ba6a229679d user: aph date: Wed Sep 30 13:23:46 2015 +0000 files: src/cpu/aarch64/vm/c2_globals_aarch64.hpp description: 8138641: Disable C2 peephole by default for aarch64 Reviewed-by: roland Contributed-by: felix.yang at linaro.org changeset: 8564:3327600b1bce user: aph date: Mon Sep 28 16:18:15 2015 +0000 files: src/cpu/aarch64/vm/sharedRuntime_aarch64.cpp description: 8136165: AARCH64: Tidy up compiled native calls Summary: Do some cleaning Reviewed-by: roland, kvn, enevill changeset: 8563:55aa493031fd user: enevill date: Wed Sep 16 13:50:57 2015 +0000 files: src/cpu/aarch64/vm/aarch64.ad description: 8136615: aarch64: elide DecodeN when followed by CmpP 0 Summary: remove DecodeN when comparing a narrow oop with 0 Reviewed-by: kvn, adinn changeset: 8562:bc7f582fc2e0 user: roland date: Mon Sep 21 10:51:33 2015 +0200 files: src/share/vm/opto/callnode.hpp src/share/vm/opto/macro.cpp src/share/vm/opto/memnode.cpp description: 8136596: Remove aarch64: MemBarRelease when final field's allocation is NoEscape or ArgEscape Summary: elide MemBar when AllocateNode _is_non_escaping Reviewed-by: kvn, roland Contributed-by: hui.shi at linaro.org changeset: 8561:e0ad611f5271 user: enevill date: Tue Sep 15 12:59:51 2015 +0000 files: src/cpu/aarch64/vm/macroAssembler_aarch64.cpp src/cpu/aarch64/vm/macroAssembler_aarch64.hpp src/cpu/aarch64/vm/sharedRuntime_aarch64.cpp description: 8136524: aarch64: test/compiler/runtime/7196199/Test7196199.java fails Summary: Fix safepoint handlers to save 128 bits on vector poll Reviewed-by: kvn Contributed-by: felix.yang at linaro.org changeset: 8560:d331b7dd3eb0 user: aph date: Tue Sep 08 14:08:58 2015 +0100 files: src/cpu/aarch64/vm/aarch64.ad src/cpu/aarch64/vm/macroAssembler_aarch64.hpp description: 8135157: DMB elimination in AArch64 C2 synchronization implementation Summary: Reduce memory barrier usage in C2 fast lock and unlock. Reviewed-by: kvn Contributed-by: wei.tang at linaro.org, aph at redhat.com changeset: 8559:b516036ba465 user: adinn date: Wed Aug 26 17:13:59 2015 +0100 files: src/cpu/aarch64/vm/aarch64.ad description: 8134322: AArch64: Fix several errors in C2 biased locking implementation Summary: Several errors in C2 biased locking require fixing Reviewed-by: kvn Contributed-by: hui.shi at linaro.org --- CUT HERE --- From aph at redhat.com Tue Oct 20 15:54:10 2015 From: aph at redhat.com (Andrew Haley) Date: Tue, 20 Oct 2015 16:54:10 +0100 Subject: [aarch64-port-dev ] Changesets to backport to jdk8 In-Reply-To: <1445356179.20265.9.camel@mylittlepony.linaroharston> References: <1445356179.20265.9.camel@mylittlepony.linaroharston> Message-ID: <562663A2.9070509@redhat.com> On 10/20/2015 04:49 PM, Edward Nevill wrote: > Hi, > > I would like to backport the changesets below from jdk9 to jdk8. > > Tested with jtreg hotspot and langtools, results before and after were > > Hotspot: Test results: passed: 675; failed: 17; error: 2 > Langtools: Test results: passed: 3,089 > > A webrev of the changes is available at > > http://cr.openjdk.java.net/~enevill/jdk8-backports-1510/webrev > > OK to push? 8135157 is a no: it's been backed out of master sources. Andrew. From edward.nevill at gmail.com Wed Oct 21 08:43:45 2015 From: edward.nevill at gmail.com (Edward Nevill) Date: Wed, 21 Oct 2015 09:43:45 +0100 Subject: [aarch64-port-dev ] Changesets to backport to jdk8 In-Reply-To: <562663A2.9070509@redhat.com> References: <1445356179.20265.9.camel@mylittlepony.linaroharston> <562663A2.9070509@redhat.com> Message-ID: <1445417025.20265.10.camel@mylittlepony.linaroharston> On Tue, 2015-10-20 at 16:54 +0100, Andrew Haley wrote: > On 10/20/2015 04:49 PM, Edward Nevill wrote: > > Hi, > 8135157 is a no: it's been backed out of master sources. OK. Thanks. I'll back that one out. Regards, Ed. From edward.nevill at gmail.com Wed Oct 21 13:04:02 2015 From: edward.nevill at gmail.com (edward.nevill at gmail.com) Date: Wed, 21 Oct 2015 13:04:02 +0000 Subject: [aarch64-port-dev ] hg: aarch64-port/jdk8/hotspot: 9 new changesets Message-ID: <201510211304.t9LD43no018999@aojmv0008.oracle.com> Changeset: b516036ba465 Author: adinn Date: 2015-08-26 17:13 +0100 URL: http://hg.openjdk.java.net/aarch64-port/jdk8/hotspot/rev/b516036ba465 8134322: AArch64: Fix several errors in C2 biased locking implementation Summary: Several errors in C2 biased locking require fixing Reviewed-by: kvn Contributed-by: hui.shi at linaro.org ! src/cpu/aarch64/vm/aarch64.ad Changeset: 4be0afa7fd02 Author: enevill Date: 2015-09-15 12:59 +0000 URL: http://hg.openjdk.java.net/aarch64-port/jdk8/hotspot/rev/4be0afa7fd02 8136524: aarch64: test/compiler/runtime/7196199/Test7196199.java fails Summary: Fix safepoint handlers to save 128 bits on vector poll Reviewed-by: kvn Contributed-by: felix.yang at linaro.org ! src/cpu/aarch64/vm/macroAssembler_aarch64.cpp ! src/cpu/aarch64/vm/macroAssembler_aarch64.hpp ! src/cpu/aarch64/vm/sharedRuntime_aarch64.cpp Changeset: dbab938afe28 Author: roland Date: 2015-09-21 10:51 +0200 URL: http://hg.openjdk.java.net/aarch64-port/jdk8/hotspot/rev/dbab938afe28 8136596: Remove aarch64: MemBarRelease when final field's allocation is NoEscape or ArgEscape Summary: elide MemBar when AllocateNode _is_non_escaping Reviewed-by: kvn, roland Contributed-by: hui.shi at linaro.org ! src/share/vm/opto/callnode.hpp ! src/share/vm/opto/macro.cpp ! src/share/vm/opto/memnode.cpp Changeset: ed6af9cfdd70 Author: enevill Date: 2015-09-16 13:50 +0000 URL: http://hg.openjdk.java.net/aarch64-port/jdk8/hotspot/rev/ed6af9cfdd70 8136615: aarch64: elide DecodeN when followed by CmpP 0 Summary: remove DecodeN when comparing a narrow oop with 0 Reviewed-by: kvn, adinn ! src/cpu/aarch64/vm/aarch64.ad Changeset: a06dd5987ae9 Author: aph Date: 2015-09-28 16:18 +0000 URL: http://hg.openjdk.java.net/aarch64-port/jdk8/hotspot/rev/a06dd5987ae9 8136165: AARCH64: Tidy up compiled native calls Summary: Do some cleaning Reviewed-by: roland, kvn, enevill ! src/cpu/aarch64/vm/sharedRuntime_aarch64.cpp Changeset: be6204a5856d Author: aph Date: 2015-09-30 13:23 +0000 URL: http://hg.openjdk.java.net/aarch64-port/jdk8/hotspot/rev/be6204a5856d 8138641: Disable C2 peephole by default for aarch64 Reviewed-by: roland Contributed-by: felix.yang at linaro.org ! src/cpu/aarch64/vm/c2_globals_aarch64.hpp Changeset: f50e867292b6 Author: aph Date: 2015-09-29 17:01 +0000 URL: http://hg.openjdk.java.net/aarch64-port/jdk8/hotspot/rev/f50e867292b6 8138575: Improve generated code for profile counters Reviewed-by: kvn ! src/cpu/aarch64/vm/macroAssembler_aarch64.cpp ! src/cpu/aarch64/vm/macroAssembler_aarch64.hpp Changeset: 5b75aaed29fc Author: enevill Date: 2015-10-15 15:33 +0000 URL: http://hg.openjdk.java.net/aarch64-port/jdk8/hotspot/rev/5b75aaed29fc 8139674: aarch64: guarantee failure in TestOptionsWithRanges.java Summary: Fix negative overflow in instruction field Reviewed-by: kvn, roland, adinn, aph ! src/cpu/aarch64/vm/interp_masm_aarch64.cpp Changeset: f9720c487762 Author: ecaspole Date: 2015-09-21 10:36 -0400 URL: http://hg.openjdk.java.net/aarch64-port/jdk8/hotspot/rev/f9720c487762 8131645: [ARM64] crash on Cavium when using G1 Summary: Add a fence when creating the CodeRootSetTable so the readers do not see invalid memory. Reviewed-by: aph, tschatzl ! src/share/vm/gc_implementation/g1/g1CodeCacheRemSet.cpp From gnu.andrew at redhat.com Wed Oct 21 16:39:16 2015 From: gnu.andrew at redhat.com (gnu.andrew at redhat.com) Date: Wed, 21 Oct 2015 16:39:16 +0000 Subject: [aarch64-port-dev ] hg: aarch64-port/jdk8u60: Added tag aarch64-jdk8u65-b17 for changeset c2f56786db32 Message-ID: <201510211639.t9LGdGOs003588@aojmv0008.oracle.com> Changeset: a22175eb6401 Author: andrew Date: 2015-10-15 03:31 +0100 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u60/rev/a22175eb6401 Added tag aarch64-jdk8u65-b17 for changeset c2f56786db32 ! .hgtags From gnu.andrew at redhat.com Wed Oct 21 16:39:21 2015 From: gnu.andrew at redhat.com (gnu.andrew at redhat.com) Date: Wed, 21 Oct 2015 16:39:21 +0000 Subject: [aarch64-port-dev ] hg: aarch64-port/jdk8u60/corba: 6 new changesets Message-ID: <201510211639.t9LGdMBR003646@aojmv0008.oracle.com> Changeset: befe28fdad7d Author: msheppar Date: 2015-06-25 13:56 +0100 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u60/corba/rev/befe28fdad7d 8076383: Better CORBA exception handling Reviewed-by: rriggs, coffeys, skoivu, ahgross ! src/share/classes/sun/rmi/rmic/iiop/StubGenerator.java Changeset: 176c73848409 Author: msheppar Date: 2015-07-14 18:03 +0100 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u60/corba/rev/176c73848409 8076387: Better CORBA value handling Reviewed-by: rriggs, coffeys, skoivu, ahgross ! src/share/classes/com/sun/corba/se/impl/io/IIOPInputStream.java ! src/share/classes/com/sun/corba/se/impl/io/IIOPOutputStream.java Changeset: 73ffb1ea7e45 Author: msheppar Date: 2015-07-14 16:49 +0100 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u60/corba/rev/73ffb1ea7e45 8076392: Improve IIOPInputStream consistency Reviewed-by: rriggs, coffeys, skoivu, ahgross ! src/share/classes/com/sun/corba/se/impl/io/IIOPInputStream.java Changeset: 581034aecf1b Author: mfang Date: 2015-08-17 10:05 -0700 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u60/corba/rev/581034aecf1b 8133357: 8u65 l10n resource file translation update Reviewed-by: yhuang ! src/share/classes/com/sun/corba/se/impl/orbutil/resources/sunorb_pt_BR.properties Changeset: fac750d8cb59 Author: andrew Date: 2015-10-15 02:30 +0100 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u60/corba/rev/fac750d8cb59 Merge jdk8u65-b17 Changeset: 5f71b77e0920 Author: andrew Date: 2015-10-15 03:31 +0100 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u60/corba/rev/5f71b77e0920 Added tag aarch64-jdk8u65-b17 for changeset fac750d8cb59 ! .hgtags From gnu.andrew at redhat.com Wed Oct 21 16:39:29 2015 From: gnu.andrew at redhat.com (gnu.andrew at redhat.com) Date: Wed, 21 Oct 2015 16:39:29 +0000 Subject: [aarch64-port-dev ] hg: aarch64-port/jdk8u60/jaxp: 9 new changesets Message-ID: <201510211639.t9LGdUT8003702@aojmv0008.oracle.com> Changeset: aecaecc6a02f Author: aefimov Date: 2015-04-28 15:04 +0300 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u60/jaxp/rev/aecaecc6a02f 8068842: Better JAXP data handling Reviewed-by: joehw, dfuchs, lancea ! src/com/sun/org/apache/xalan/internal/lib/ExsltSets.java ! src/com/sun/org/apache/xalan/internal/lib/Extensions.java ! src/com/sun/org/apache/xalan/internal/xslt/EnvironmentCheck.java ! src/com/sun/org/apache/xalan/internal/xsltc/DOM.java ! src/com/sun/org/apache/xalan/internal/xsltc/compiler/ApplyTemplates.java ! src/com/sun/org/apache/xalan/internal/xsltc/compiler/AttributeSet.java ! src/com/sun/org/apache/xalan/internal/xsltc/compiler/AttributeValueTemplate.java ! src/com/sun/org/apache/xalan/internal/xsltc/compiler/CastExpr.java ! src/com/sun/org/apache/xalan/internal/xsltc/compiler/Choose.java ! src/com/sun/org/apache/xalan/internal/xsltc/compiler/ForEach.java ! src/com/sun/org/apache/xalan/internal/xsltc/compiler/FunctionCall.java ! src/com/sun/org/apache/xalan/internal/xsltc/compiler/Import.java ! src/com/sun/org/apache/xalan/internal/xsltc/compiler/Include.java ! src/com/sun/org/apache/xalan/internal/xsltc/compiler/Key.java ! src/com/sun/org/apache/xalan/internal/xsltc/compiler/LiteralElement.java ! src/com/sun/org/apache/xalan/internal/xsltc/compiler/Mode.java ! src/com/sun/org/apache/xalan/internal/xsltc/compiler/Parser.java ! src/com/sun/org/apache/xalan/internal/xsltc/compiler/Stylesheet.java ! src/com/sun/org/apache/xalan/internal/xsltc/compiler/SymbolTable.java ! src/com/sun/org/apache/xalan/internal/xsltc/compiler/SyntaxTreeNode.java ! src/com/sun/org/apache/xalan/internal/xsltc/compiler/Template.java ! src/com/sun/org/apache/xalan/internal/xsltc/compiler/TestSeq.java ! src/com/sun/org/apache/xalan/internal/xsltc/compiler/UnsupportedElement.java ! src/com/sun/org/apache/xalan/internal/xsltc/compiler/XSLTC.java ! src/com/sun/org/apache/xalan/internal/xsltc/compiler/XslAttribute.java ! src/com/sun/org/apache/xalan/internal/xsltc/compiler/XslElement.java ! src/com/sun/org/apache/xalan/internal/xsltc/compiler/util/MethodGenerator.java ! src/com/sun/org/apache/xalan/internal/xsltc/compiler/util/MultiHashtable.java ! src/com/sun/org/apache/xalan/internal/xsltc/dom/AdaptiveResultTreeImpl.java ! src/com/sun/org/apache/xalan/internal/xsltc/dom/DOMAdapter.java ! src/com/sun/org/apache/xalan/internal/xsltc/dom/DOMWSFilter.java ! src/com/sun/org/apache/xalan/internal/xsltc/dom/DocumentCache.java ! src/com/sun/org/apache/xalan/internal/xsltc/dom/KeyIndex.java ! src/com/sun/org/apache/xalan/internal/xsltc/dom/MultiDOM.java ! src/com/sun/org/apache/xalan/internal/xsltc/dom/SAXImpl.java ! src/com/sun/org/apache/xalan/internal/xsltc/dom/SimpleResultTreeImpl.java ! src/com/sun/org/apache/xalan/internal/xsltc/runtime/AbstractTranslet.java ! src/com/sun/org/apache/xalan/internal/xsltc/runtime/BasisLibrary.java ! src/com/sun/org/apache/xalan/internal/xsltc/trax/DOM2SAX.java ! src/com/sun/org/apache/xalan/internal/xsltc/trax/StAXEvent2SAX.java ! src/com/sun/org/apache/xalan/internal/xsltc/trax/StAXStream2SAX.java ! src/com/sun/org/apache/xalan/internal/xsltc/trax/TemplatesImpl.java ! src/com/sun/org/apache/xalan/internal/xsltc/trax/TransformerFactoryImpl.java ! src/com/sun/org/apache/xalan/internal/xsltc/trax/TransformerImpl.java ! src/com/sun/org/apache/xerces/internal/dom/CoreDocumentImpl.java ! src/com/sun/org/apache/xerces/internal/dom/DeferredDocumentImpl.java ! src/com/sun/org/apache/xerces/internal/dom/DocumentImpl.java ! src/com/sun/org/apache/xerces/internal/dom/DocumentTypeImpl.java ! src/com/sun/org/apache/xerces/internal/dom/LCount.java ! src/com/sun/org/apache/xerces/internal/dom/NodeImpl.java ! src/com/sun/org/apache/xerces/internal/dom/ParentNode.java ! src/com/sun/org/apache/xerces/internal/impl/XMLEntityManager.java ! src/com/sun/org/apache/xerces/internal/impl/XMLErrorReporter.java ! src/com/sun/org/apache/xerces/internal/impl/XMLStreamReaderImpl.java ! src/com/sun/org/apache/xerces/internal/impl/dtd/DTDGrammar.java ! src/com/sun/org/apache/xerces/internal/impl/dtd/DTDGrammarBucket.java ! src/com/sun/org/apache/xerces/internal/impl/dv/DTDDVFactory.java ! src/com/sun/org/apache/xerces/internal/impl/dv/dtd/DTDDVFactoryImpl.java ! src/com/sun/org/apache/xerces/internal/impl/dv/dtd/XML11DTDDVFactoryImpl.java ! src/com/sun/org/apache/xerces/internal/impl/xpath/XPath.java ! src/com/sun/org/apache/xerces/internal/impl/xpath/regex/ParserForXMLSchema.java ! src/com/sun/org/apache/xerces/internal/impl/xpath/regex/Token.java ! src/com/sun/org/apache/xerces/internal/impl/xs/SubstitutionGroupHandler.java ! src/com/sun/org/apache/xerces/internal/impl/xs/XMLSchemaLoader.java ! src/com/sun/org/apache/xerces/internal/impl/xs/XMLSchemaValidator.java ! src/com/sun/org/apache/xerces/internal/impl/xs/XSGrammarBucket.java ! src/com/sun/org/apache/xerces/internal/impl/xs/traversers/XSAttributeChecker.java ! src/com/sun/org/apache/xerces/internal/impl/xs/traversers/XSDHandler.java ! src/com/sun/org/apache/xerces/internal/jaxp/DocumentBuilderFactoryImpl.java ! src/com/sun/org/apache/xerces/internal/jaxp/DocumentBuilderImpl.java ! src/com/sun/org/apache/xerces/internal/jaxp/SAXParserFactoryImpl.java ! src/com/sun/org/apache/xerces/internal/jaxp/SAXParserImpl.java ! src/com/sun/org/apache/xerces/internal/parsers/XMLGrammarPreparser.java ! src/com/sun/org/apache/xerces/internal/util/AugmentationsImpl.java ! src/com/sun/org/apache/xerces/internal/util/DOMErrorHandlerWrapper.java ! src/com/sun/org/apache/xerces/internal/util/DOMUtil.java ! src/com/sun/org/apache/xerces/internal/util/EncodingMap.java ! src/com/sun/org/apache/xerces/internal/util/SymbolHash.java ! src/com/sun/org/apache/xerces/internal/util/SymbolTable.java ! src/com/sun/org/apache/xerces/internal/util/XMLAttributesImpl.java ! src/com/sun/org/apache/xml/internal/dtm/ref/CustomStringPool.java ! src/com/sun/org/apache/xml/internal/dtm/ref/sax2dtm/SAX2DTM.java ! src/com/sun/org/apache/xml/internal/resolver/Catalog.java ! src/com/sun/org/apache/xml/internal/resolver/CatalogEntry.java ! src/com/sun/org/apache/xml/internal/resolver/helpers/BootstrapResolver.java ! src/com/sun/org/apache/xml/internal/resolver/readers/DOMCatalogReader.java ! src/com/sun/org/apache/xml/internal/resolver/readers/SAXCatalogReader.java ! src/com/sun/org/apache/xml/internal/serialize/BaseMarkupSerializer.java ! src/com/sun/org/apache/xml/internal/serialize/ElementState.java ! src/com/sun/org/apache/xml/internal/serialize/Encodings.java ! src/com/sun/org/apache/xml/internal/serialize/HTMLSerializer.java ! src/com/sun/org/apache/xml/internal/serialize/HTMLdtd.java ! src/com/sun/org/apache/xml/internal/serialize/SerializerFactory.java ! src/com/sun/org/apache/xml/internal/serialize/XMLSerializer.java ! src/com/sun/org/apache/xml/internal/serializer/AttributesImplSerializer.java ! src/com/sun/org/apache/xml/internal/serializer/EmptySerializer.java ! src/com/sun/org/apache/xml/internal/serializer/SerializerFactory.java ! src/com/sun/org/apache/xml/internal/serializer/utils/Utils.java ! src/com/sun/org/apache/xml/internal/utils/DOMHelper.java ! src/com/sun/org/apache/xml/internal/utils/ElemDesc.java ! src/com/sun/org/apache/xpath/internal/compiler/Keywords.java ! src/com/sun/xml/internal/stream/XMLEntityStorage.java ! src/com/sun/xml/internal/stream/dtd/nonvalidating/DTDGrammar.java ! src/org/xml/sax/helpers/NamespaceSupport.java Changeset: 9bf5504875c7 Author: aefimov Date: 2015-06-03 17:05 +0300 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u60/jaxp/rev/9bf5504875c7 8078427: More supportive home environment Reviewed-by: dfuchs, lancea, skoivu ! src/com/sun/org/apache/xml/internal/resolver/Catalog.java ! src/com/sun/org/apache/xml/internal/serializer/TreeWalker.java ! src/com/sun/org/apache/xml/internal/utils/TreeWalker.java Changeset: 121459a6fef9 Author: aefimov Date: 2015-04-28 16:07 +0300 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u60/jaxp/rev/121459a6fef9 8078822: 8068842 fix missed one new file PrimeNumberSequenceGenerator.java Reviewed-by: joehw, dfuchs, lancea - src/com/sun/org/apache/xalan/internal/xsltc/runtime/Hashtable.java + src/com/sun/org/apache/xerces/internal/util/PrimeNumberSequenceGenerator.java - src/com/sun/org/apache/xerces/internal/util/TypeInfoImpl.java - src/com/sun/org/apache/xml/internal/serializer/Utils.java - src/com/sun/org/apache/xml/internal/utils/NamespaceSupport2.java Changeset: f380fa60b4c1 Author: aefimov Date: 2015-05-15 11:24 +0300 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u60/jaxp/rev/f380fa60b4c1 8079323: Serialization compatibility for Templates: need to exclude Hashtable from serialization Reviewed-by: dfuchs, lancea, hawtin ! src/com/sun/org/apache/xalan/internal/xsltc/trax/TemplatesImpl.java Changeset: 6ef8b815a40e Author: aefimov Date: 2015-07-12 22:35 +0300 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u60/jaxp/rev/6ef8b815a40e 8086733: Improve namespace handling Reviewed-by: dfuchs, lancea, ahgross ! src/com/sun/org/apache/xalan/internal/utils/XMLSecurityManager.java ! src/com/sun/org/apache/xerces/internal/impl/XML11DocumentScannerImpl.java ! src/com/sun/org/apache/xerces/internal/impl/XML11EntityScanner.java ! src/com/sun/org/apache/xerces/internal/impl/XML11NSDocumentScannerImpl.java ! src/com/sun/org/apache/xerces/internal/impl/XMLDTDScannerImpl.java ! src/com/sun/org/apache/xerces/internal/impl/XMLDocumentFragmentScannerImpl.java ! src/com/sun/org/apache/xerces/internal/impl/XMLEntityManager.java ! src/com/sun/org/apache/xerces/internal/impl/XMLEntityScanner.java ! src/com/sun/org/apache/xerces/internal/impl/XMLNSDocumentScannerImpl.java ! src/com/sun/org/apache/xerces/internal/impl/XMLScanner.java ! src/com/sun/org/apache/xerces/internal/impl/XMLVersionDetector.java ! src/com/sun/org/apache/xerces/internal/impl/msg/XMLMessages.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/XMLSchemaMessages.properties ! src/com/sun/org/apache/xerces/internal/impl/xs/models/CMNodeFactory.java ! src/com/sun/org/apache/xerces/internal/impl/xs/traversers/XSAttributeChecker.java ! src/com/sun/org/apache/xerces/internal/utils/XMLLimitAnalyzer.java ! src/com/sun/org/apache/xerces/internal/utils/XMLSecurityManager.java ! src/com/sun/xml/internal/stream/Entity.java Changeset: 7212be9de56c Author: aefimov Date: 2015-07-15 18:40 +0300 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u60/jaxp/rev/7212be9de56c 8130078: Document better processing Reviewed-by: dfuchs, lancea, ahgross ! src/com/sun/org/apache/xerces/internal/impl/XMLDTDScannerImpl.java ! src/com/sun/org/apache/xerces/internal/impl/XMLDocumentScannerImpl.java ! src/com/sun/org/apache/xerces/internal/xni/parser/XMLDTDScanner.java Changeset: 727d13fe00e8 Author: mfang Date: 2015-08-17 10:06 -0700 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u60/jaxp/rev/727d13fe00e8 8133357: 8u65 l10n resource file translation update Reviewed-by: yhuang ! src/com/sun/org/apache/xalan/internal/xsltc/compiler/util/ErrorMessages_de.java ! src/com/sun/org/apache/xalan/internal/xsltc/runtime/ErrorMessages_sv.java ! src/com/sun/org/apache/xerces/internal/impl/msg/XMLMessages_de.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/XMLMessages_es.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/XMLMessages_fr.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/XMLMessages_it.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/XMLMessages_ja.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/XMLMessages_ko.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/XMLMessages_pt_BR.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/XMLMessages_sv.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/XMLMessages_zh_CN.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/XMLMessages_zh_TW.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/XMLSchemaMessages_de.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/XMLSchemaMessages_es.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/XMLSchemaMessages_fr.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/XMLSchemaMessages_it.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/XMLSchemaMessages_ja.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/XMLSchemaMessages_ko.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/XMLSchemaMessages_pt_BR.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/XMLSchemaMessages_sv.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/XMLSchemaMessages_zh_CN.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/XMLSchemaMessages_zh_TW.properties ! src/com/sun/org/apache/xpath/internal/res/XPATHErrorResources_de.java Changeset: 6dafc3701c68 Author: andrew Date: 2015-10-15 02:30 +0100 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u60/jaxp/rev/6dafc3701c68 Merge jdk8u65-b17 - src/com/sun/org/apache/xalan/internal/xsltc/runtime/Hashtable.java - src/com/sun/org/apache/xerces/internal/util/TypeInfoImpl.java - src/com/sun/org/apache/xml/internal/serializer/Utils.java - src/com/sun/org/apache/xml/internal/utils/NamespaceSupport2.java Changeset: 03c9468f0291 Author: andrew Date: 2015-10-15 03:31 +0100 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u60/jaxp/rev/03c9468f0291 Added tag aarch64-jdk8u65-b17 for changeset 6dafc3701c68 ! .hgtags From gnu.andrew at redhat.com Wed Oct 21 16:39:36 2015 From: gnu.andrew at redhat.com (gnu.andrew at redhat.com) Date: Wed, 21 Oct 2015 16:39:36 +0000 Subject: [aarch64-port-dev ] hg: aarch64-port/jdk8u60/jaxws: Added tag aarch64-jdk8u65-b17 for changeset 72dda8b5dbc8 Message-ID: <201510211639.t9LGdaY9003761@aojmv0008.oracle.com> Changeset: 3147672563e0 Author: andrew Date: 2015-10-15 03:31 +0100 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u60/jaxws/rev/3147672563e0 Added tag aarch64-jdk8u65-b17 for changeset 72dda8b5dbc8 ! .hgtags From gnu.andrew at redhat.com Wed Oct 21 16:39:43 2015 From: gnu.andrew at redhat.com (gnu.andrew at redhat.com) Date: Wed, 21 Oct 2015 16:39:43 +0000 Subject: [aarch64-port-dev ] hg: aarch64-port/jdk8u60/langtools: 3 new changesets Message-ID: <201510211639.t9LGdhQ9003832@aojmv0008.oracle.com> Changeset: 64538617d801 Author: mfang Date: 2015-08-17 10:07 -0700 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u60/langtools/rev/64538617d801 8133357: 8u65 l10n resource file translation update Reviewed-by: yhuang ! src/share/classes/com/sun/tools/doclets/formats/html/resources/standard_ja.properties ! src/share/classes/com/sun/tools/doclets/internal/toolkit/resources/doclets_ja.properties ! src/share/classes/com/sun/tools/doclets/internal/toolkit/resources/doclets_zh_CN.properties Changeset: 5365ca13395e Author: andrew Date: 2015-10-15 02:30 +0100 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u60/langtools/rev/5365ca13395e Merge jdk8u65-b17 Changeset: 1cedf93b3dba Author: andrew Date: 2015-10-15 03:31 +0100 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u60/langtools/rev/1cedf93b3dba Added tag aarch64-jdk8u65-b17 for changeset 5365ca13395e ! .hgtags From gnu.andrew at redhat.com Wed Oct 21 16:39:51 2015 From: gnu.andrew at redhat.com (gnu.andrew at redhat.com) Date: Wed, 21 Oct 2015 16:39:51 +0000 Subject: [aarch64-port-dev ] hg: aarch64-port/jdk8u60/hotspot: 3 new changesets Message-ID: <201510211639.t9LGdpJY003889@aojmv0008.oracle.com> Changeset: e586e8fbd1d0 Author: asaha Date: 2015-04-01 12:55 -0700 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u60/hotspot/rev/e586e8fbd1d0 8076505: Increment minor version of HSx for 8u65 and initialize the build number Reviewed-by: katleman ! make/hotspot_version Changeset: 1ac6501881b2 Author: andrew Date: 2015-10-15 02:30 +0100 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u60/hotspot/rev/1ac6501881b2 Merge jdk8u65-b17 ! make/hotspot_version Changeset: dbbde6b99709 Author: andrew Date: 2015-10-15 03:31 +0100 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u60/hotspot/rev/dbbde6b99709 Added tag aarch64-jdk8u65-b17 for changeset 1ac6501881b2 ! .hgtags From gnu.andrew at redhat.com Wed Oct 21 16:40:01 2015 From: gnu.andrew at redhat.com (gnu.andrew at redhat.com) Date: Wed, 21 Oct 2015 16:40:01 +0000 Subject: [aarch64-port-dev ] hg: aarch64-port/jdk8u60/jdk: 30 new changesets Message-ID: <201510211640.t9LGe22T003953@aojmv0008.oracle.com> Changeset: cfff0619688f Author: igerasim Date: 2015-08-03 22:36 +0300 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u60/jdk/rev/cfff0619688f 6854417: TESTBUG: java/util/regex/RegExTest.java fails intermittently Reviewed-by: sherman ! test/java/util/regex/RegExTest.java Changeset: 607ffdf44a8d Author: igerasim Date: 2015-07-31 17:18 +0300 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u60/jdk/rev/607ffdf44a8d 8005226: java/rmi/transport/pinClientSocketFactory/PinClientSocketFactory.java fails intermittently Reviewed-by: rriggs, smarks ! test/java/rmi/testlibrary/TestLibrary.java ! test/java/rmi/transport/pinClientSocketFactory/PinClientSocketFactory.java Changeset: 695e0aee5cee Author: weijun Date: 2015-05-25 09:42 +0800 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u60/jdk/rev/695e0aee5cee 8048030: Expectations should be consistent Reviewed-by: valeriep, mullan, ahgross ! src/share/classes/javax/security/auth/kerberos/KerberosPrincipal.java ! src/share/classes/javax/security/auth/kerberos/ServicePermission.java ! src/share/classes/sun/security/jgss/krb5/Krb5NameElement.java ! src/share/classes/sun/security/jgss/wrapper/GSSNameElement.java ! src/share/classes/sun/security/krb5/KrbServiceLocator.java ! src/share/classes/sun/security/krb5/PrincipalName.java ! src/share/classes/sun/security/krb5/Realm.java ! src/share/classes/sun/security/krb5/internal/ccache/CCacheInputStream.java ! test/sun/security/krb5/auto/KDC.java ! test/sun/security/krb5/auto/SSL.java ! test/sun/security/krb5/name/Constructors.java Changeset: c1a8b01ee201 Author: igerasim Date: 2015-07-31 00:48 +0300 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u60/jdk/rev/c1a8b01ee201 8076339: Better handling of remote object invocation Reviewed-by: asmotrak, igerasim, skoivu ! src/share/classes/java/rmi/server/RemoteObjectInvocationHandler.java Changeset: 99ad139df178 Author: igerasim Date: 2015-05-16 02:04 +0300 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u60/jdk/rev/99ad139df178 8076413: Better JRMP message handling Reviewed-by: smarks ! src/share/classes/sun/rmi/transport/DGCClient.java Changeset: 90037eb04072 Author: aefimov Date: 2015-06-03 17:06 +0300 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u60/jdk/rev/90037eb04072 8078427: More supportive home environment Reviewed-by: dfuchs, lancea, skoivu ! 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/java/lang/SecurityManager/CheckPackageAccess.java Changeset: 70be31156a38 Author: sjiang Date: 2015-05-07 09:37 +0200 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u60/jdk/rev/70be31156a38 8078440: Safer managed types Reviewed-by: dfuchs, ahgross ! src/share/classes/javax/management/openmbean/OpenMBeanAttributeInfoSupport.java Changeset: 0a84a86b697c Author: serb Date: 2015-05-23 02:49 +0300 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u60/jdk/rev/0a84a86b697c 8080541: More direct property handling Reviewed-by: prr, alexsch ! src/share/classes/java/beans/PropertyDescriptor.java Changeset: 5ca1f8de3686 Author: smarks Date: 2015-06-25 16:44 -0700 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u60/jdk/rev/5ca1f8de3686 8080688: Service for DGC services Reviewed-by: skoivu, igerasim, jeff ! src/share/classes/sun/rmi/transport/DGCImpl.java Changeset: 4bc6c49fdece Author: igerasim Date: 2015-07-02 03:44 +0300 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u60/jdk/rev/4bc6c49fdece 8081744: Clear out list corner case Reviewed-by: mullan, rhalade ! src/share/classes/sun/security/provider/certpath/RevocationChecker.java Changeset: 36c9e3cafb5d Author: xuelei Date: 2015-07-23 09:51 +0100 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u60/jdk/rev/36c9e3cafb5d 8081760: Better group dynamics Reviewed-by: coffeys, mullan, weijun, jnimeh, ahgross, asmotrak ! src/share/classes/sun/security/ssl/DHCrypt.java ! src/share/classes/sun/security/util/AbstractAlgorithmConstraints.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/ssl/com/sun/net/ssl/internal/ssl/DHKeyExchange/DHEKeySizing.java Changeset: 66db0792fe4c Author: prr Date: 2015-06-18 09:22 -0700 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u60/jdk/rev/66db0792fe4c 8086092: More palette improvements Reviewed-by: bae, serb ! make/lib/Awt2dLibraries.gmk Changeset: 2dd307af5d41 Author: aivanov Date: 2015-07-20 13:22 +0300 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u60/jdk/rev/2dd307af5d41 8087110: [TESTBUG] Test javax/swing/JFileChooser/8002077/bug8002077.java fails Reviewed-by: serb, alexsch ! test/javax/swing/JFileChooser/8002077/bug8002077.java Changeset: 1840651bad2a Author: aefimov Date: 2015-06-11 10:33 +0300 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u60/jdk/rev/1840651bad2a 8087118: Remove missing package from java.security files Reviewed-by: joehw ! 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/java/lang/SecurityManager/CheckPackageAccess.java Changeset: 4fe7c1719e1f Author: poonam Date: 2015-07-30 07:31 -0700 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u60/jdk/rev/4fe7c1719e1f 8087350: Improve array conversions Reviewed-by: jbachorik, kevinw ! src/share/classes/javax/management/openmbean/OpenMBeanAttributeInfoSupport.java Changeset: c35f467356ba Author: igerasim Date: 2015-06-30 15:53 +0300 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u60/jdk/rev/c35f467356ba 8103671: More objective stream classes Reviewed-by: rriggs, igerasim ! src/share/classes/java/io/ObjectStreamClass.java Changeset: 8db6602e3cd9 Author: prr Date: 2015-07-24 09:46 -0700 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u60/jdk/rev/8db6602e3cd9 8103675: Better Binary searches Reviewed-by: srl, serb, mschoene ! src/share/native/sun/font/layout/LookupTables.cpp Changeset: e4f2dc6b90ef Author: ptbrunet Date: 2015-06-29 16:12 -0500 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u60/jdk/rev/e4f2dc6b90ef 8129611: Accessbridge error handling improvement Reviewed-by: prr, ahgross, asmotrak Contributed-by: peter.brunet at oracle.com ! src/windows/native/sun/bridge/AccessBridgeDebug.cpp ! src/windows/native/sun/bridge/AccessBridgeDebug.h ! src/windows/native/sun/bridge/WinAccessBridge.cpp Changeset: 293161040829 Author: ptbrunet Date: 2015-07-14 22:51 -0500 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u60/jdk/rev/293161040829 8130185: More accessible access switch Reviewed-by: prr, ahgross, asmotrak Contributed-by: peter.brunet at oracle.com ! src/windows/native/sun/bridge/jabswitch.cpp Changeset: e68060332538 Author: michaelm Date: 2015-07-09 13:23 +0100 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u60/jdk/rev/e68060332538 8130193: Improve HTTP connections Reviewed-by: alanb ! src/share/classes/sun/net/www/protocol/http/HttpURLConnection.java Changeset: 417f92451977 Author: igerasim Date: 2015-07-03 17:50 +0300 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u60/jdk/rev/417f92451977 8130253: ObjectStreamClass.getFields too restrictive Reviewed-by: igerasim, skoivu ! src/share/classes/java/io/ObjectStreamClass.java Changeset: 0561d3165501 Author: xuelei Date: 2015-07-13 13:37 +0000 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u60/jdk/rev/0561d3165501 8130864: Better server identity handling Reviewed-by: jnimeh, asmotrak, ahgross ! src/share/classes/sun/security/ssl/ClientHandshaker.java Changeset: b9978edad408 Author: bpb Date: 2015-08-06 10:13 -0700 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u60/jdk/rev/b9978edad408 8130891: (bf) More direct buffering Summary: Improve non-byte direct buffering. Reviewed-by: alanb, jeff, ahgross, robm, rriggs ! src/share/classes/java/nio/Direct-X-Buffer.java.template Changeset: 25bc57d6db28 Author: igerasim Date: 2015-08-10 18:21 +0300 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u60/jdk/rev/25bc57d6db28 8131291: Perfect parameter patterning Reviewed-by: mullan ! src/share/classes/sun/security/provider/certpath/AlgorithmChecker.java Changeset: 9f385c41334c Author: prr Date: 2015-07-29 11:18 -0700 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u60/jdk/rev/9f385c41334c 8132042: Preserve layout presentation Reviewed-by: mschoene, srl, serb ! src/share/native/sun/font/layout/IndicRearrangementProcessor.cpp ! src/share/native/sun/font/layout/IndicRearrangementProcessor.h ! src/share/native/sun/font/layout/IndicRearrangementProcessor2.cpp ! src/share/native/sun/font/layout/IndicRearrangementProcessor2.h ! src/share/native/sun/font/layout/MorphTables.cpp ! src/share/native/sun/font/layout/MorphTables2.cpp ! src/share/native/sun/font/layout/SegmentArrayProcessor.cpp ! src/share/native/sun/font/layout/SegmentArrayProcessor2.cpp ! src/share/native/sun/font/layout/SegmentSingleProcessor2.cpp ! src/share/native/sun/font/layout/SimpleArrayProcessor2.cpp ! src/share/native/sun/font/layout/SingleTableProcessor.cpp Changeset: ce82d8358f47 Author: aefimov Date: 2015-08-18 14:43 +0300 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u60/jdk/rev/ce82d8358f47 8133321: (tz) Support tzdata2015f Reviewed-by: okutsu ! make/data/tzdata/VERSION ! make/data/tzdata/africa ! make/data/tzdata/asia ! make/data/tzdata/europe ! make/data/tzdata/leapseconds ! make/data/tzdata/northamerica ! make/data/tzdata/southamerica ! make/data/tzdata/zone.tab ! test/sun/util/calendar/zi/tzdata/VERSION ! test/sun/util/calendar/zi/tzdata/africa ! test/sun/util/calendar/zi/tzdata/asia ! 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: dea226ab3ca3 Author: mfang Date: 2015-08-17 10:06 -0700 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u60/jdk/rev/dea226ab3ca3 8133357: 8u65 l10n resource file translation update Reviewed-by: yhuang ! src/macosx/classes/com/apple/laf/resources/aqua_de.properties ! src/macosx/classes/com/apple/laf/resources/aqua_sv.properties ! src/share/classes/com/sun/swing/internal/plaf/basic/resources/basic_sv.properties ! src/share/classes/com/sun/swing/internal/plaf/metal/resources/metal_sv.properties ! src/share/classes/sun/awt/resources/awt_sv.properties ! src/share/classes/sun/launcher/resources/launcher_pt_BR.properties ! src/share/classes/sun/launcher/resources/launcher_sv.properties ! src/share/classes/sun/security/tools/keytool/Resources_sv.java ! src/share/classes/sun/tools/jar/resources/jar_de.properties ! src/share/classes/sun/tools/jar/resources/jar_pt_BR.properties Changeset: 3d1c3b0b73a3 Author: igerasim Date: 2015-09-08 22:31 +0300 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u60/jdk/rev/3d1c3b0b73a3 8135043: ObjectStreamClass.getField(String) too restrictive Reviewed-by: igerasim, chegar ! src/share/classes/java/io/ObjectStreamClass.java + test/java/io/ObjectInputStream/TestObjectStreamClass.java Changeset: 16b0f230ae87 Author: andrew Date: 2015-10-15 02:30 +0100 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u60/jdk/rev/16b0f230ae87 Merge jdk8u65-b17 ! make/data/tzdata/VERSION ! make/data/tzdata/africa ! make/data/tzdata/asia ! make/data/tzdata/europe ! make/data/tzdata/leapseconds ! make/data/tzdata/northamerica ! make/data/tzdata/southamerica ! make/data/tzdata/zone.tab ! make/lib/Awt2dLibraries.gmk ! src/share/classes/com/sun/swing/internal/plaf/basic/resources/basic_sv.properties ! src/share/classes/java/beans/PropertyDescriptor.java ! src/share/classes/java/io/ObjectStreamClass.java ! src/share/classes/javax/management/openmbean/OpenMBeanAttributeInfoSupport.java ! src/share/classes/sun/launcher/resources/launcher_pt_BR.properties ! src/share/classes/sun/net/www/protocol/http/HttpURLConnection.java ! src/share/classes/sun/security/jgss/krb5/Krb5NameElement.java ! src/share/classes/sun/security/krb5/Realm.java ! src/share/classes/sun/security/provider/certpath/RevocationChecker.java ! src/share/classes/sun/security/ssl/ClientHandshaker.java ! 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/java/lang/SecurityManager/CheckPackageAccess.java ! test/java/util/regex/RegExTest.java ! test/sun/security/krb5/auto/SSL.java ! test/sun/util/calendar/zi/tzdata/VERSION ! test/sun/util/calendar/zi/tzdata/africa ! test/sun/util/calendar/zi/tzdata/asia ! 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: d000047a2d36 Author: andrew Date: 2015-10-15 03:31 +0100 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u60/jdk/rev/d000047a2d36 Added tag aarch64-jdk8u65-b17 for changeset 16b0f230ae87 ! .hgtags From gnu.andrew at redhat.com Wed Oct 21 16:40:10 2015 From: gnu.andrew at redhat.com (gnu.andrew at redhat.com) Date: Wed, 21 Oct 2015 16:40:10 +0000 Subject: [aarch64-port-dev ] hg: aarch64-port/jdk8u60/nashorn: Added tag aarch64-jdk8u65-b17 for changeset a489d9ca618b Message-ID: <201510211640.t9LGeAHE004036@aojmv0008.oracle.com> Changeset: 34607c2a0230 Author: andrew Date: 2015-10-15 03:31 +0100 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u60/nashorn/rev/34607c2a0230 Added tag aarch64-jdk8u65-b17 for changeset a489d9ca618b ! .hgtags From dalibor.topic at oracle.com Thu Oct 22 09:01:06 2015 From: dalibor.topic at oracle.com (dalibor topic) Date: Thu, 22 Oct 2015 11:01:06 +0200 Subject: [aarch64-port-dev ] Project proposal: AArch32 port In-Reply-To: <1444830648.7802.34.camel@mylittlepony.linaroharston> References: <1444830648.7802.34.camel@mylittlepony.linaroharston> Message-ID: <5628A5D2.40909@oracle.com> Hi Edward, As the OpenJDK Porters Group Lead, I agree that the Porters Group would be a good fit for a sponsoring Group for this Project. Can you elaborate a bit on the initial set of Committers/Reviewers you would see participating in the Project - would it be just you & Joseph from Linaro (or somewhere else?) for the start? cheers, dalibor topic On 14.10.2015 15:50, Edward Nevill wrote: > Hi, > > I would like to propose the creation of a new project to port OpenJDK to > ARM's aarch32 architecture. The aarch32 architecture is the 32 bit side > of the ARMv8 architecture (the other side being aarch64). > > There is already a port for aarch64 which has been upstreamed into JDK9, > thanks to the great work of Andrew Haley, Andrew Dinn and others however > 32 bit support is missing. > > The aarch64 architecture is broadly compatible with ARMv7 with only a > few minor differences most of which are not applicable to application > level code. It is proposed that the aarch32 port will also support > ARMv7. > > ARMv6 could also be supported, but this would depend on the level of > community interest (ARMv6 is the architecture in the Raspberry Pi so > there may be significant community interest and involvement if we were > also to target ARMv6). > > We already have a complete template interpreter thanks to the excellent > work of Joseph Joyce who presented his work at the recent Linaro Connect > conference. A copy of his slides is available at > > http://openjdk.linaro.org/sfo15-openjdk-arm32.pdf > > I have created a JIRA issue and uploaded webrevs of this port based on > JDK 9 to cr.openjdk.java.net. > > JIRA Issue: https://bugs.openjdk.java.net/browse/JDK-8139303 > > Webrevs: > > http://cr.openjdk.java.net/~enevill/8139303/webrev.hotspot/ > http://cr.openjdk.java.net/~enevill/8139303/webrev.hs-comp/ > http://cr.openjdk.java.net/~enevill/8139303/webrev.jdk/ > > The template interpreter is complete and runs a large variety of > applications (eclipse, jedit, galaxians, javac, although sadly it cannot > build itself as yet:-). > > It is intended that the port will be a complete port of OpenJDK to > include Template Interpreter / C1 and possibly C2. > > Can I please request the support of the Porters Group as the Sponsoring > Group with myself as project lead. > > Many thanks, > Edward Nevill > > -- Dalibor Topic | Principal Product Manager Phone: +494089091214 | Mobile: +491737185961 ORACLE Deutschland B.V. & Co. KG | K?hneh?fe 5 | 22761 Hamburg ORACLE Deutschland B.V. & Co. KG Hauptverwaltung: Riesstr. 25, D-80992 M?nchen Registergericht: Amtsgericht M?nchen, HRA 95603 Komplement?rin: ORACLE Deutschland Verwaltung B.V. Hertogswetering 163/167, 3543 AS Utrecht, Niederlande Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697 Gesch?ftsf?hrer: Alexander van der Ven, Astrid Kepper, Val Maher Oracle is committed to developing practices and products that help protect the environment From edward.nevill at gmail.com Thu Oct 22 12:46:54 2015 From: edward.nevill at gmail.com (Edward Nevill) Date: Thu, 22 Oct 2015 13:46:54 +0100 Subject: [aarch64-port-dev ] Project proposal: AArch32 port In-Reply-To: <5628A5D2.40909@oracle.com> References: <1444830648.7802.34.camel@mylittlepony.linaroharston> <5628A5D2.40909@oracle.com> Message-ID: <1445518014.29998.4.camel@mylittlepony.linaroharston> On Thu, 2015-10-22 at 11:01 +0200, dalibor topic wrote: > Hi Edward, > > As the OpenJDK Porters Group Lead, I agree that the Porters Group would > be a good fit for a sponsoring Group for this Project. > > Can you elaborate a bit on the initial set of Committers/Reviewers you > would see participating in the Project - would it be just you & Joseph > from Linaro (or somewhere else?) for the start? > > cheers, > dalibor topic Hi Dalibor, The initial set of Committers I propose are Andrew Dinn ('adinn'), Andrew Haley ('aph') and myself to start with. I do not propose having any formal review on this project so there is no need for formal Reviewers. All the best, Ed. From edward.nevill at gmail.com Fri Oct 23 07:32:25 2015 From: edward.nevill at gmail.com (Edward Nevill) Date: Fri, 23 Oct 2015 08:32:25 +0100 Subject: [aarch64-port-dev ] JTREG, SPECjbb2013 and Hadoop/Terasort results for OpenJDK 8 on AArch64 Message-ID: <1445585545.28722.1.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/295/summary.html ------------------------------------------------------------------------------- client-release/hotspot ------------------------------------------------------------------------------- Build 0: aarch64/2015/mar/06 pass: 606; fail: 54; error: 2 Build 1: aarch64/2015/apr/17 pass: 605; fail: 55; error: 2 Build 2: aarch64/2015/may/29 pass: 605; fail: 55; error: 2 Build 3: aarch64/2015/jun/02 pass: 606; fail: 54; error: 2 Build 4: aarch64/2015/jul/02 pass: 636; fail: 45; error: 5 Build 5: aarch64/2015/jul/08 pass: 636; fail: 45; error: 5 Build 6: aarch64/2015/jul/21 pass: 637; fail: 45; error: 5 Build 7: aarch64/2015/sep/04 pass: 636; fail: 46; error: 5 Build 8: aarch64/2015/sep/08 pass: 636; fail: 46; error: 5 Build 9: aarch64/2015/oct/22 pass: 637; fail: 45; error: 5 ------------------------------------------------------------------------------- client-release/jdk ------------------------------------------------------------------------------- Build 0: aarch64/2015/mar/06 pass: 5,354; fail: 216; error: 18 Build 1: aarch64/2015/apr/17 pass: 5,359; fail: 208; error: 24 Build 2: aarch64/2015/may/29 pass: 5,350; fail: 217; error: 24 Build 3: aarch64/2015/jun/02 pass: 5,353; fail: 219; error: 19 Build 4: aarch64/2015/jul/02 pass: 5,499; fail: 230; error: 20 Build 5: aarch64/2015/jul/08 pass: 5,485; fail: 242; error: 22 Build 6: aarch64/2015/jul/21 pass: 5,502; fail: 233; error: 18 Build 7: aarch64/2015/sep/04 pass: 5,477; fail: 254; error: 22 Build 8: aarch64/2015/sep/08 pass: 5,477; fail: 254; error: 22 Build 9: aarch64/2015/oct/22 pass: 5,482; fail: 254; error: 17 1 fatal errors were detected; please follow the link above for more detail. ------------------------------------------------------------------------------- client-release/langtools ------------------------------------------------------------------------------- Build 0: aarch64/2015/mar/06 pass: 3,063; error: 10 Build 1: aarch64/2015/apr/17 pass: 3,063; error: 10 Build 2: aarch64/2015/may/29 pass: 3,062; error: 11 Build 3: aarch64/2015/jun/02 pass: 3,054; fail: 4; error: 15 Build 4: aarch64/2015/jul/02 pass: 3,076; error: 15 Build 5: aarch64/2015/jul/08 pass: 3,080; error: 11 Build 6: aarch64/2015/jul/21 pass: 3,081; error: 10 Build 7: aarch64/2015/sep/04 pass: 3,078; error: 13 Build 8: aarch64/2015/sep/08 pass: 3,078; error: 13 Build 9: aarch64/2015/oct/22 pass: 3,077; error: 14 ------------------------------------------------------------------------------- server-release/hotspot ------------------------------------------------------------------------------- Build 0: aarch64/2015/mar/06 pass: 626; fail: 32; error: 4 Build 1: aarch64/2015/apr/17 pass: 625; fail: 32; error: 5 Build 2: aarch64/2015/may/29 pass: 628; fail: 32; error: 2 Build 3: aarch64/2015/jun/02 pass: 626; fail: 33; error: 3 Build 4: aarch64/2015/jul/02 pass: 644; fail: 37; error: 5 Build 5: aarch64/2015/jul/08 pass: 644; fail: 37; error: 5 Build 6: aarch64/2015/jul/21 pass: 645; fail: 37; error: 5 Build 7: aarch64/2015/sep/04 pass: 645; fail: 37; error: 5 Build 8: aarch64/2015/sep/08 pass: 645; fail: 37; error: 5 Build 9: aarch64/2015/oct/22 pass: 644; fail: 38; error: 5 ------------------------------------------------------------------------------- server-release/jdk ------------------------------------------------------------------------------- Build 0: aarch64/2015/mar/06 pass: 5,348; fail: 207; error: 33 Build 1: aarch64/2015/apr/17 pass: 5,354; fail: 208; error: 29 Build 2: aarch64/2015/may/29 pass: 5,358; fail: 209; error: 24 Build 3: aarch64/2015/jun/02 pass: 5,357; fail: 213; error: 21 Build 4: aarch64/2015/jul/02 pass: 5,510; fail: 215; error: 24 Build 5: aarch64/2015/jul/08 pass: 5,506; fail: 221; error: 22 Build 6: aarch64/2015/jul/21 pass: 5,512; fail: 217; error: 24 Build 7: aarch64/2015/sep/04 pass: 5,471; fail: 257; error: 25 Build 8: aarch64/2015/sep/08 pass: 5,471; fail: 257; error: 25 Build 9: aarch64/2015/oct/22 pass: 5,489; fail: 241; error: 23 1 fatal errors were detected; please follow the link above for more detail. ------------------------------------------------------------------------------- server-release/langtools ------------------------------------------------------------------------------- Build 0: aarch64/2015/mar/06 pass: 3,065; error: 8 Build 1: aarch64/2015/apr/17 pass: 3,063; error: 10 Build 2: aarch64/2015/may/29 pass: 3,063; fail: 1; error: 9 Build 3: aarch64/2015/jun/02 pass: 3,064; error: 9 Build 4: aarch64/2015/jul/02 pass: 3,078; error: 13 Build 5: aarch64/2015/jul/08 pass: 3,083; error: 8 Build 6: aarch64/2015/jul/21 pass: 3,081; error: 10 Build 7: aarch64/2015/sep/04 pass: 3,078; error: 13 Build 8: aarch64/2015/sep/08 pass: 3,078; error: 13 Build 9: aarch64/2015/oct/22 pass: 3,082; fail: 2; error: 7 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.24x Relative performance: Server critical-jOPS (nc): 1.57x 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: 49.7, Server: 85.03 Client 49.7 / Client 2014-04-01 (43.00): 1.16x Server 85.03 / Server 2014-04-01 (71.00): 1.20x 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. 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/ 2015-05-29 pass rate: 11556/11556, results: http://openjdk.linaro.org/jcstress-nightly-runs/2015/149/results/ 2015-06-02 pass rate: 11556/11556, results: http://openjdk.linaro.org/jcstress-nightly-runs/2015/153/results/ 2015-07-02 pass rate: 11556/11556, results: http://openjdk.linaro.org/jcstress-nightly-runs/2015/183/results/ 2015-07-08 pass rate: 11556/11556, results: http://openjdk.linaro.org/jcstress-nightly-runs/2015/189/results/ 2015-07-21 pass rate: 11556/11556, results: http://openjdk.linaro.org/jcstress-nightly-runs/2015/202/results/ 2015-09-04 pass rate: 11555/11556, results: http://openjdk.linaro.org/jcstress-nightly-runs/2015/247/results/ 2015-09-08 pass rate: 11555/11556, results: http://openjdk.linaro.org/jcstress-nightly-runs/2015/251/results/ 2015-10-22 pass rate: 11558/11558, results: http://openjdk.linaro.org/jcstress-nightly-runs/2015/295/results/ For detailed information on the test output please refer to: http://openjdk.linaro.org/jcstress-nightly-runs/ From dalibor.topic at oracle.com Fri Oct 23 12:53:15 2015 From: dalibor.topic at oracle.com (dalibor topic) Date: Fri, 23 Oct 2015 14:53:15 +0200 Subject: [aarch64-port-dev ] Project proposal: AArch32 port In-Reply-To: <1445518014.29998.4.camel@mylittlepony.linaroharston> References: <1444830648.7802.34.camel@mylittlepony.linaroharston> <5628A5D2.40909@oracle.com> <1445518014.29998.4.camel@mylittlepony.linaroharston> Message-ID: <562A2DBB.9000404@oracle.com> On 22.10.2015 14:46, Edward Nevill wrote: > Hi Dalibor, > > The initial set of Committers I propose are > > Andrew Dinn ('adinn'), Andrew Haley ('aph') and myself to start with. Thanks, Edward. That's a very accomplished group! Since you're sending this e-mail from a non-Linaro account, while CC:ing a number of people at Linaro, I am wondering which OCAs would you and other Committers plan to make contributions under. Can you elaborate, please? > I do not propose having any formal review on this project so there is no > need for formal Reviewers. That sounds fine to me. I noticed that in your initial set of Committers Joseph Joyce is missing, while at the same time you seem to suggest using his externally developed code to jump-start this Project. That seems a bit unusual - typically the original author of a new feature would want to continue to be actively involved during that feature's further development in an OpenJDK Project, so I'm curious for the rationale behind doing things differently in this case. Can you and Joseph explain if you intend to use the template interpreter code you referenced in the new Project, and if so, how (i.e. under which OCA) it would be contributed to it? I'm asking since I don't see Joseph Joyce mentioned at [0], and slides you referenced unfortunately provide little information on that. Last but not least, is there anyone else who has contributed to the code beside yourself, Joseph? Is there any code (or other materials) taken from other third party or open source projects in it? cheers, dalibor topic [0] http://www.oracle.com/technetwork/community/oca-486395.html -- Dalibor Topic | Principal Product Manager Phone: +494089091214 | Mobile: +491737185961 ORACLE Deutschland B.V. & Co. KG | K?hneh?fe 5 | 22761 Hamburg ORACLE Deutschland B.V. & Co. KG Hauptverwaltung: Riesstr. 25, D-80992 M?nchen Registergericht: Amtsgericht M?nchen, HRA 95603 Komplement?rin: ORACLE Deutschland Verwaltung B.V. Hertogswetering 163/167, 3543 AS Utrecht, Niederlande Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697 Gesch?ftsf?hrer: Alexander van der Ven, Astrid Kepper, Val Maher Oracle is committed to developing practices and products that help protect the environment From edward.nevill at gmail.com Fri Oct 23 13:41:42 2015 From: edward.nevill at gmail.com (Edward Nevill) Date: Fri, 23 Oct 2015 14:41:42 +0100 Subject: [aarch64-port-dev ] Project proposal: AArch32 port In-Reply-To: <562A2DBB.9000404@oracle.com> References: <1444830648.7802.34.camel@mylittlepony.linaroharston> <5628A5D2.40909@oracle.com> <1445518014.29998.4.camel@mylittlepony.linaroharston> <562A2DBB.9000404@oracle.com> Message-ID: <1445607702.28722.19.camel@mint> On Fri, 2015-10-23 at 14:53 +0200, dalibor topic wrote: > On 22.10.2015 14:46, Edward Nevill wrote: > > Hi Dalibor, > > > > Andrew Dinn ('adinn'), Andrew Haley ('aph') and myself to start with. > > Thanks, Edward. That's a very accomplished group! Thanks:) > Since you're sending this e-mail from a non-Linaro account, while CC:ing > a number of people at Linaro, I am wondering which OCAs would you and > other Committers plan to make contributions under. Can you elaborate, > please? Andrew Dinn and Andrew Haley will make contributions under the RedHat OCA. I will make contributions under the Linaro OCA. I currently use my gmail address for contributing to JDK 9. > > I noticed that in your initial set of Committers Joseph Joyce is > missing, while at the same time you seem to suggest using his externally > developed code to jump-start this Project. Yes. Joseph worked as an intern at Linaro for 14 weeks over this summer and did a great job porting the template interpreter in that time. Unfortunately Joseph is no longer working for us. However Linaro owns the copyright of all the work he did while he was working for us and we can contribute it under the Linaro OCA. > > That seems a bit unusual - typically the original author of a new > feature would want to continue to be actively involved during that > feature's further development in an OpenJDK Project, so I'm curious for > the rationale behind doing things differently in this case. Joseph has indeed expressed an interest in continuing to contribute on a voluntary basis. However, to the best of my knowledge, Joseph has not signed the OCA in a personal capacity, therefore I did not include him in the list of initial committers. If Joseph does sign the OCA in the future then we would be happy to have him as a committer. > > Can you and Joseph explain if you intend to use the template interpreter > code you referenced in the new Project, and if so, how (i.e. under which > OCA) it would be contributed to it? I'm asking since I don't see Joseph > Joyce mentioned at [0], and slides you referenced unfortunately provide > little information on that. Yes, under the Linaro OCA. > > Last but not least, is there anyone else who has contributed to the code > beside yourself, Joseph? Is there any code (or other materials) taken > from other third party or open source projects in it? To the best of my knowledge no, but I didn't write it. Joseph: Would you be able to confirm this? Many thanks for your help Dalibor, All the best, Ed. From adinn at redhat.com Mon Oct 26 16:43:21 2015 From: adinn at redhat.com (adinn at redhat.com) Date: Mon, 26 Oct 2015 16:43:21 +0000 Subject: [aarch64-port-dev ] hg: aarch64-port/jdk8/hotspot: Backport optimization of volatile puts/gets and CAS to use ldar/stlr Message-ID: <201510261643.t9QGhLcP004817@aojmv0008.oracle.com> Changeset: 3ccdd3482827 Author: adinn Date: 2015-10-08 11:06 -0400 URL: http://hg.openjdk.java.net/aarch64-port/jdk8/hotspot/rev/3ccdd3482827 Backport optimization of volatile puts/gets and CAS to use ldar/stlr ! src/cpu/aarch64/vm/aarch64.ad ! src/cpu/aarch64/vm/globals_aarch64.hpp ! src/cpu/aarch64/vm/macroAssembler_aarch64.cpp ! src/cpu/aarch64/vm/macroAssembler_aarch64.hpp ! src/cpu/aarch64/vm/vm_version_aarch64.cpp ! src/share/vm/opto/graphKit.cpp From adinn at redhat.com Mon Oct 26 17:05:38 2015 From: adinn at redhat.com (Andrew Dinn) Date: Mon, 26 Oct 2015 17:05:38 +0000 Subject: [aarch64-port-dev ] Why is 8079315 only specific to x86? and why is it not in JDK8? Message-ID: <562E5D62.5080704@redhat.com> I noticed what looks to me like an anomaly when backporting the volatile object/CAS optimizations to JDK8 and wondered if someone could explain it to me. Why is the fix for 8079315: UseCondCardMark broken in conjunction with CMS precleaning on x86 only applied for x86? This JDK9 patch modifies the shared C1 and C2 code to plant a StoreLoad into the card mark code when UseCondCardMark is true and CMS is in use. It also modifies macroAssembler_x86.cpp to insert a StoreLoad inside routine store_check. However, store_check in macroAssembler_aarch64.cpp does not include a StoreLoad. Surely it ought to? n.b. the related patch for the interpreter 8078438: Interpreter should support conditional card marks (UseCondCardMark) on x86 and aarch64 includes modifications for both architectures. It looks to me like 8079315 (and 8078438) probably ought to be backported to JDK8 but it seems Oracle have not done so and hence that we have not done it either. This is relevant to the vol obj/CAS backport to jdk8-aarch64 because that patch includes special case handling for CMS to cope with the extra MemBarVolatile that may result from this patch being applied to C2. It copes ok if the MemBarVolatile is not generated because that can happen when e.g. a NULL value is written. But the extra case handling only really makes sense if 8079315 is backported to jdk8-aarch64 (I still prefer to leave it in just in case they do get backported otherwise the backprot will break the vol obj/CAS handling). regards, Andrew Dinn ----------- From edward.nevill at gmail.com Tue Oct 27 10:21:10 2015 From: edward.nevill at gmail.com (Edward Nevill) Date: Tue, 27 Oct 2015 10:21:10 +0000 Subject: [aarch64-port-dev ] RFR: 8140582: aarch64: jvm fails to initialise after 8078556 Message-ID: <1445941270.31480.9.camel@mint> Hi, Please review the following webrev http://cr.openjdk.java.net/~enevill/8140582/webrev/ JIRA Issue: https://bugs.openjdk.java.net/browse/JDK-8140582 The vm fails to initialises with the following error on aarch64 systems with 64K pagesize ed at arm64:~/jdk9-dev/hs-comp/hotspot$ /home/ed/images/jdk/bin/java intx StackYellowPages=1 is outside the allowed range [ 2 ... 7 ] intx StackShadowPages=1 is outside the allowed range [ 4 ... 34 ] Error: Could not create the Java Virtual Machine. Error: A fatal exception has occurred. Program will exit. The problem is the following code in src/os/linux/vm/os_linux.cpp // If the pagesize of the VM is greater than 8K determine the appropriate // number of initial guard pages. The user can change this with the // command line arguments, if needed. if (vm_page_size() > (int)Linux::vm_default_page_size()) { StackYellowPages = 1; StackRedPages = 1; StackShadowPages = round_to((StackShadowPages*Linux::vm_default_page_size()), vm_page_size()) / vm_page_size(); } My proposed fix is to set MIN_STACK_YELLOW_PAGES, MIN_STACK_RED_PAGES, and MIN_STACK_SHADOW_PAGES to 1 in globals_aarch64.hpp Thanks for the review, Ed. From hui.shi at linaro.org Tue Oct 27 14:49:27 2015 From: hui.shi at linaro.org (Hui Shi) Date: Tue, 27 Oct 2015 22:49:27 +0800 Subject: [aarch64-port-dev ] [REDO] Elide more final field's write memory barrier with escape analysis result Message-ID: Fixing regression https://bugs.openjdk.java.net/browse/JDK-8139750, root cause is stable field's allocation doesn't always dominate MemBarRelease node created for stable field write. Could someone help review and sponsor this changeset? bug: https://bugs.openjdk.java.net/browse/JDK-8139758 webrev: http://cr.openjdk.java.net/~hshi/8139758/webrev_v2/ Analyzing java/util/Map/Defaults.java Error message is "assert(!had_error) failed: bad dominance". Assertion fails because MemBarRelease's Precedent input (checkCastPP node) doesn't dominate MemBarRelease node. Checking fail compilation method java/lang/invoke/MethodType.makeImpl 1. early return when mt is not null. 2. stable field write is applied on newly created MethodType object. 3. MemBarRelease is created with Precedent input (allocation "new MethodType(rtype, ptypes, trusted)") 4. MemBarRelease is created at the exit of this method. As early return exits in this method, MemBarRealse is not dominated by its Precedent input. This problem doesn't show up before my early change, because Precedent input is only set for boxed type instance and no stable field in boxed type. MethodType makeImpl(Class rtype, Class[] ptypes, boolean trusted) { MethodType mt = internTable.get(new MethodType(ptypes, rtype)); if (mt != null) return mt; if (ptypes.length == 0) { ptypes = NO_PTYPES; trusted = true; } mt = new MethodType(rtype, ptypes, trusted); // promote the object to the Real Thing, and reprobe mt.form = MethodTypeForm.findForm(mt); // stable field write return internTable.add(mt); } For this reason, adding Precedent input for stable field store's MemBarRealse is skipped in new patch. For final field store, allocation always dominate MemBarRelease. Because allocation is immediately before initializer method and method has only one entry. New patch includes: 1. In do_put_xxx, set_alloc_with_final when filed is final and can find its allocation. Remove constrains for boxed type check. 2. Skip setting MemBarRelease's Precedent input for stable field write. There is no performance degradation here, before this change MemBarRelease precedent input isn't set as alloc_with_final is only update for boxed class and no stable field in boxed class. Early discussion about why these constrains need removed and can be removed is in http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2015-October/019196.html Regards Shi Hui From adinn at redhat.com Tue Oct 27 16:17:45 2015 From: adinn at redhat.com (Andrew Dinn) Date: Tue, 27 Oct 2015 16:17:45 +0000 Subject: [aarch64-port-dev ] RFR: 8140582: aarch64: jvm fails to initialise after 8078556 In-Reply-To: <1445941270.31480.9.camel@mint> References: <1445941270.31480.9.camel@mint> Message-ID: <562FA3A9.9030205@redhat.com> On 27/10/15 10:21, Edward Nevill wrote: > Please review the following webrev > > http://cr.openjdk.java.net/~enevill/8140582/webrev/ Looks good to me. regards, Andrew Dinn ----------- From edward.nevill at gmail.com Tue Oct 27 18:20:26 2015 From: edward.nevill at gmail.com (Edward Nevill) Date: Tue, 27 Oct 2015 18:20:26 +0000 Subject: [aarch64-port-dev ] RFR: 8140611: aarch64: jtreg test jdk/tools/pack200/UnpackerMemoryTest.java SEGVs Message-ID: <1445970026.31480.18.camel@mint> Hi, Please review the following webrev http://cr.openjdk.java.net/~enevill/8140611/webrev/ JIRA Issue: https://bugs.openjdk.java.net/browse/JDK-8140611 Summary: The UnpackerMemoryTest SEGVs in jni_GetStringUTFChars. The problem is that c_rarg3 is a really bad choice for a tmp register since at this point the native arguments have been loaded into registers. (I confess guilt for this). 'lr' is a much better choice for the tmp register. We know this is free because we are just about to do a 'rt_call' which clobbers lr in any case. Thanks for the review, Ed. From edward.nevill at gmail.com Tue Oct 27 19:12:42 2015 From: edward.nevill at gmail.com (Edward Nevill) Date: Tue, 27 Oct 2015 19:12:42 +0000 Subject: [aarch64-port-dev ] JTREG, SPECjbb2013 and Hadoop/Terasort results for OpenJDK 8 on AArch64 Message-ID: <1445973162.31480.21.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/300/summary.html ------------------------------------------------------------------------------- client-release/hotspot ------------------------------------------------------------------------------- Build 0: aarch64/2015/apr/17 pass: 605; fail: 55; error: 2 Build 1: aarch64/2015/may/29 pass: 605; fail: 55; error: 2 Build 2: aarch64/2015/jun/02 pass: 606; fail: 54; error: 2 Build 3: aarch64/2015/jul/02 pass: 636; fail: 45; error: 5 Build 4: aarch64/2015/jul/08 pass: 636; fail: 45; error: 5 Build 5: aarch64/2015/jul/21 pass: 637; fail: 45; error: 5 Build 6: aarch64/2015/sep/04 pass: 636; fail: 46; error: 5 Build 7: aarch64/2015/sep/08 pass: 636; fail: 46; error: 5 Build 8: aarch64/2015/oct/22 pass: 637; fail: 45; error: 5 Build 9: aarch64/2015/oct/27 pass: 637; fail: 45; error: 5 ------------------------------------------------------------------------------- client-release/jdk ------------------------------------------------------------------------------- Build 0: aarch64/2015/apr/17 pass: 5,359; fail: 208; error: 24 Build 1: aarch64/2015/may/29 pass: 5,350; fail: 217; error: 24 Build 2: aarch64/2015/jun/02 pass: 5,353; fail: 219; error: 19 Build 3: aarch64/2015/jul/02 pass: 5,499; fail: 230; error: 20 Build 4: aarch64/2015/jul/08 pass: 5,485; fail: 242; error: 22 Build 5: aarch64/2015/jul/21 pass: 5,502; fail: 233; error: 18 Build 6: aarch64/2015/sep/04 pass: 5,477; fail: 254; error: 22 Build 7: aarch64/2015/sep/08 pass: 5,477; fail: 254; error: 22 Build 8: aarch64/2015/oct/22 pass: 5,482; fail: 254; error: 17 Build 9: aarch64/2015/oct/27 pass: 5,472; fail: 259; error: 22 1 fatal errors were detected; please follow the link above for more detail. ------------------------------------------------------------------------------- client-release/langtools ------------------------------------------------------------------------------- Build 0: aarch64/2015/apr/17 pass: 3,063; error: 10 Build 1: aarch64/2015/may/29 pass: 3,062; error: 11 Build 2: aarch64/2015/jun/02 pass: 3,054; fail: 4; error: 15 Build 3: aarch64/2015/jul/02 pass: 3,076; error: 15 Build 4: aarch64/2015/jul/08 pass: 3,080; error: 11 Build 5: aarch64/2015/jul/21 pass: 3,081; error: 10 Build 6: aarch64/2015/sep/04 pass: 3,078; error: 13 Build 7: aarch64/2015/sep/08 pass: 3,078; error: 13 Build 8: aarch64/2015/oct/22 pass: 3,077; error: 14 Build 9: aarch64/2015/oct/27 pass: 3,081; error: 10 ------------------------------------------------------------------------------- server-release/hotspot ------------------------------------------------------------------------------- Build 0: aarch64/2015/apr/17 pass: 625; fail: 32; error: 5 Build 1: aarch64/2015/may/29 pass: 628; fail: 32; error: 2 Build 2: aarch64/2015/jun/02 pass: 626; fail: 33; error: 3 Build 3: aarch64/2015/jul/02 pass: 644; fail: 37; error: 5 Build 4: aarch64/2015/jul/08 pass: 644; fail: 37; error: 5 Build 5: aarch64/2015/jul/21 pass: 645; fail: 37; error: 5 Build 6: aarch64/2015/sep/04 pass: 645; fail: 37; error: 5 Build 7: aarch64/2015/sep/08 pass: 645; fail: 37; error: 5 Build 8: aarch64/2015/oct/22 pass: 644; fail: 38; error: 5 Build 9: aarch64/2015/oct/27 pass: 644; fail: 38; error: 5 ------------------------------------------------------------------------------- server-release/jdk ------------------------------------------------------------------------------- Build 0: aarch64/2015/apr/17 pass: 5,354; fail: 208; error: 29 Build 1: aarch64/2015/may/29 pass: 5,358; fail: 209; error: 24 Build 2: aarch64/2015/jun/02 pass: 5,357; fail: 213; error: 21 Build 3: aarch64/2015/jul/02 pass: 5,510; fail: 215; error: 24 Build 4: aarch64/2015/jul/08 pass: 5,506; fail: 221; error: 22 Build 5: aarch64/2015/jul/21 pass: 5,512; fail: 217; error: 24 Build 6: aarch64/2015/sep/04 pass: 5,471; fail: 257; error: 25 Build 7: aarch64/2015/sep/08 pass: 5,471; fail: 257; error: 25 Build 8: aarch64/2015/oct/22 pass: 5,489; fail: 241; error: 23 Build 9: aarch64/2015/oct/27 pass: 5,495; fail: 234; error: 24 1 fatal errors were detected; please follow the link above for more detail. ------------------------------------------------------------------------------- server-release/langtools ------------------------------------------------------------------------------- Build 0: aarch64/2015/apr/17 pass: 3,063; error: 10 Build 1: aarch64/2015/may/29 pass: 3,063; fail: 1; error: 9 Build 2: aarch64/2015/jun/02 pass: 3,064; error: 9 Build 3: aarch64/2015/jul/02 pass: 3,078; error: 13 Build 4: aarch64/2015/jul/08 pass: 3,083; error: 8 Build 5: aarch64/2015/jul/21 pass: 3,081; error: 10 Build 6: aarch64/2015/sep/04 pass: 3,078; error: 13 Build 7: aarch64/2015/sep/08 pass: 3,078; error: 13 Build 8: aarch64/2015/oct/22 pass: 3,082; fail: 2; error: 7 Build 9: aarch64/2015/oct/27 pass: 3,083; error: 8 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.15x Relative performance: Server critical-jOPS (nc): 1.52x 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: 50.05, Server: 82.54 Client 50.05 / Client 2014-04-01 (43.00): 1.16x Server 82.54 / Server 2014-04-01 (71.00): 1.16x 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. 2015-04-17 pass rate: 11555/11555, results: http://openjdk.linaro.org/jcstress-nightly-runs/2015/107/results/ 2015-05-29 pass rate: 11556/11556, results: http://openjdk.linaro.org/jcstress-nightly-runs/2015/149/results/ 2015-06-02 pass rate: 11556/11556, results: http://openjdk.linaro.org/jcstress-nightly-runs/2015/153/results/ 2015-07-02 pass rate: 11556/11556, results: http://openjdk.linaro.org/jcstress-nightly-runs/2015/183/results/ 2015-07-08 pass rate: 11556/11556, results: http://openjdk.linaro.org/jcstress-nightly-runs/2015/189/results/ 2015-07-21 pass rate: 11556/11556, results: http://openjdk.linaro.org/jcstress-nightly-runs/2015/202/results/ 2015-09-04 pass rate: 11555/11556, results: http://openjdk.linaro.org/jcstress-nightly-runs/2015/247/results/ 2015-09-08 pass rate: 11555/11556, results: http://openjdk.linaro.org/jcstress-nightly-runs/2015/251/results/ 2015-10-22 pass rate: 11558/11558, results: http://openjdk.linaro.org/jcstress-nightly-runs/2015/295/results/ 2015-10-27 pass rate: 11558/11558, results: http://openjdk.linaro.org/jcstress-nightly-runs/2015/300/results/ For detailed information on the test output please refer to: http://openjdk.linaro.org/jcstress-nightly-runs/ From vladimir.kozlov at oracle.com Wed Oct 28 02:59:36 2015 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 28 Oct 2015 10:59:36 +0800 Subject: [aarch64-port-dev ] RFR: 8140611: aarch64: jtreg test jdk/tools/pack200/UnpackerMemoryTest.java SEGVs In-Reply-To: <1445970026.31480.18.camel@mint> References: <1445970026.31480.18.camel@mint> Message-ID: <56303A18.2070306@oracle.com> Good. Thanks, Vladimir On 10/28/15 2:20 AM, Edward Nevill wrote: > Hi, > > Please review the following webrev > > http://cr.openjdk.java.net/~enevill/8140611/webrev/ > > JIRA Issue: https://bugs.openjdk.java.net/browse/JDK-8140611 > > Summary: The UnpackerMemoryTest SEGVs in jni_GetStringUTFChars. > > The problem is that c_rarg3 is a really bad choice for a tmp register since at this point the native arguments have been loaded into registers. (I confess guilt for this). > > 'lr' is a much better choice for the tmp register. We know this is free because we are just about to do a 'rt_call' which clobbers lr in any case. > > Thanks for the review, > Ed. > > From adinn at redhat.com Wed Oct 28 08:27:10 2015 From: adinn at redhat.com (Andrew Dinn) Date: Wed, 28 Oct 2015 08:27:10 +0000 Subject: [aarch64-port-dev ] RFR: 8140611: aarch64: jtreg test jdk/tools/pack200/UnpackerMemoryTest.java SEGVs In-Reply-To: <1445970026.31480.18.camel@mint> References: <1445970026.31480.18.camel@mint> Message-ID: <563086DE.3070200@redhat.com> On 27/10/15 18:20, Edward Nevill wrote: > Please review the following webrev > > http://cr.openjdk.java.net/~enevill/8140611/webrev/ > > JIRA Issue: https://bugs.openjdk.java.net/browse/JDK-8140611 > > Summary: The UnpackerMemoryTest SEGVs in jni_GetStringUTFChars. > > The problem is that c_rarg3 is a really bad choice for a tmp register > since at this point the native arguments have been loaded into > registers. (I confess guilt for this). > > 'lr' is a much better choice for the tmp register. We know this is > free because we are just about to do a 'rt_call' which clobbers lr in > any case. Looks ok to me. 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 gmail.com Wed Oct 28 09:09:57 2015 From: edward.nevill at gmail.com (Edward Nevill) Date: Wed, 28 Oct 2015 09:09:57 +0000 Subject: [aarch64-port-dev ] RFR: 8140611: aarch64: jtreg test jdk/tools/pack200/UnpackerMemoryTest.java SEGVs In-Reply-To: <563086DE.3070200@redhat.com> References: <1445970026.31480.18.camel@mint> <563086DE.3070200@redhat.com> Message-ID: <1446023397.31480.23.camel@mint> On Wed, 2015-10-28 at 08:27 +0000, Andrew Dinn wrote: > On 27/10/15 18:20, Edward Nevill wrote: > > Please review the following webrev > Looks ok to me. > > regards, Thanks for the review, OK to backport to jdk8 aarch64 project also. Regards, Ed. From adinn at redhat.com Wed Oct 28 10:53:58 2015 From: adinn at redhat.com (Andrew Dinn) Date: Wed, 28 Oct 2015 10:53:58 +0000 Subject: [aarch64-port-dev ] RFR: 8140611: aarch64: jtreg test jdk/tools/pack200/UnpackerMemoryTest.java SEGVs In-Reply-To: <1446023397.31480.23.camel@mint> References: <1445970026.31480.18.camel@mint> <563086DE.3070200@redhat.com> <1446023397.31480.23.camel@mint> Message-ID: <5630A946.8080208@redhat.com> On 28/10/15 09:09, Edward Nevill wrote: > On Wed, 2015-10-28 at 08:27 +0000, Andrew Dinn wrote: >> On 27/10/15 18:20, Edward Nevill wrote: >>> Please review the following webrev >> Looks ok to me. >> >> regards, > > Thanks for the review, OK to backport to jdk8 aarch64 project also. Sure. regards, Andrew Dinn ----------- From josephjoyce at gmx.com Wed Oct 28 13:58:21 2015 From: josephjoyce at gmx.com (Joseph Joyce) Date: Wed, 28 Oct 2015 13:58:21 +0000 Subject: [aarch64-port-dev ] Project proposal: AArch32 port In-Reply-To: <1445607702.28722.19.camel@mint> References: <1444830648.7802.34.camel@mylittlepony.linaroharston> <5628A5D2.40909@oracle.com> <1445518014.29998.4.camel@mylittlepony.linaroharston> <562A2DBB.9000404@oracle.com> <1445607702.28722.19.camel@mint> Message-ID: <1446040701.26259.11.camel@gmx.com> Hi Ed and Dalibor, There's no code in there from other open source projects. As far as I can remember the only code from elsewhere was an algorithm for division, which came from http://www.chiark.greenend.org.uk/~theom/riscos/docs/ultimate/a252div.txt The code was modified a bit to work for the assembler, the url from which it came is mentioned in the source (MacroAssembler::divide32). If this is a problem I can easily replace the code with a call out to a C (or Ed suggested using the algorithm from the ARM32-Microjit). I have now signed and sent the OCA (today) and would like to continue contributing to this project. If I could be added to the committers that would be great. Thanks Joseph On Fri, 2015-10-23 at 14:41 +0100, Edward Nevill wrote: > On Fri, 2015-10-23 at 14:53 +0200, dalibor topic wrote: > > On 22.10.2015 14:46, Edward Nevill wrote: > > > Hi Dalibor, > > > > > > Andrew Dinn ('adinn'), Andrew Haley ('aph') and myself to start with. > > > > Thanks, Edward. That's a very accomplished group! > > Thanks:) > > > Since you're sending this e-mail from a non-Linaro account, while CC:ing > > a number of people at Linaro, I am wondering which OCAs would you and > > other Committers plan to make contributions under. Can you elaborate, > > please? > > Andrew Dinn and Andrew Haley will make contributions under the RedHat > OCA. > > I will make contributions under the Linaro OCA. I currently use my gmail > address for contributing to JDK 9. > > > > > I noticed that in your initial set of Committers Joseph Joyce is > > missing, while at the same time you seem to suggest using his externally > > developed code to jump-start this Project. > > Yes. Joseph worked as an intern at Linaro for 14 weeks over this summer > and did a great job porting the template interpreter in that time. > > Unfortunately Joseph is no longer working for us. > > However Linaro owns the copyright of all the work he did while he was > working for us and we can contribute it under the Linaro OCA. > > > > > That seems a bit unusual - typically the original author of a new > > feature would want to continue to be actively involved during that > > feature's further development in an OpenJDK Project, so I'm curious for > > the rationale behind doing things differently in this case. > > Joseph has indeed expressed an interest in continuing to contribute on a > voluntary basis. However, to the best of my knowledge, Joseph has not > signed the OCA in a personal capacity, therefore I did not include him > in the list of initial committers. If Joseph does sign the OCA in the > future then we would be happy to have him as a committer. > > > > > Can you and Joseph explain if you intend to use the template interpreter > > code you referenced in the new Project, and if so, how (i.e. under which > > OCA) it would be contributed to it? I'm asking since I don't see Joseph > > Joyce mentioned at [0], and slides you referenced unfortunately provide > > little information on that. > > Yes, under the Linaro OCA. > > > > > Last but not least, is there anyone else who has contributed to the code > > beside yourself, Joseph? Is there any code (or other materials) taken > > from other third party or open source projects in it? > > To the best of my knowledge no, but I didn't write it. > > Joseph: Would you be able to confirm this? > > Many thanks for your help Dalibor, > > All the best, > Ed. > > From edward.nevill at gmail.com Wed Oct 28 18:12:20 2015 From: edward.nevill at gmail.com (edward.nevill at gmail.com) Date: Wed, 28 Oct 2015 18:12:20 +0000 Subject: [aarch64-port-dev ] hg: aarch64-port/jdk8/hotspot: 2 new changesets Message-ID: <201510281812.t9SICKh3000727@aojmv0008.oracle.com> Changeset: acaa2f3db91b Author: enevill Date: 2015-10-28 17:47 +0000 URL: http://hg.openjdk.java.net/aarch64-port/jdk8/hotspot/rev/acaa2f3db91b Fix thinko when backporting 8131645. Table ends up being allocated twice. ! src/share/vm/gc_implementation/g1/g1CodeCacheRemSet.cpp Changeset: e903061ac7ca Author: enevill Date: 2015-10-28 17:51 +0000 URL: http://hg.openjdk.java.net/aarch64-port/jdk8/hotspot/rev/e903061ac7ca 8140611: aarch64: jtreg test jdk/tools/pack200/UnpackerMemoryTest.java SEGVs Summary: Fix register usage on calling native synchronized methods Reviewed-by: kvn, adinn ! src/cpu/aarch64/vm/sharedRuntime_aarch64.cpp From roland.westrelin at oracle.com Fri Oct 30 16:04:28 2015 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Fri, 30 Oct 2015 17:04:28 +0100 Subject: [aarch64-port-dev ] [REDO] Elide more final field's write memory barrier with escape analysis result In-Reply-To: References: Message-ID: > webrev: http://cr.openjdk.java.net/~hshi/8139758/webrev_v2/ Thanks for re-submitting this. So you?re fixing an existing bug in the process. Nice. We usually need a test case for every bug fix. Can you write such a test case that triggers that bug. test/compiler/stable has example regression test cases for @Stable. Roland.