From yuanxiang4 at huawei.com Thu Sep 1 01:35:54 2016 From: yuanxiang4 at huawei.com (yuanxiang (F)) Date: Thu, 1 Sep 2016 01:35:54 +0000 Subject: [Patch] JTreg case FiniteGCLatency.java failed randomly when using Serial GC. In-Reply-To: <57C6E185.40503@redhat.com> References: <57C6E185.40503@redhat.com> Message-ID: Hi, I sent these two mails last Friday, and haven't seen them until this week. I think there may be something wrong with my mail system, so I resent them... ( But I haven't received all of them from aarch32-port-dev at openjdk.java.net until now. ) Sorry for the repetitive mails in the mail list. These two bugs are hard to reproduce... To the case FiniteGCLatency.java, we tested it on about 10 arm boards, and only 2 boards can reproduce it. On one of the 2 boards, one use accord can reproduce, while other one can't. May be this is because the proper uninitialized values are hard to get. And to the case TransformationWarningsTest, it needs many runs to reproduce. On a 2-core board, we ran it more than 10,000 times to reproduces. On ARM JUNO boards, it also needs more than 1,000 times to reproduce. May be this is because the error scenario is very hard to occur. It needs one thread to write to the constant pool cache, and another thread is reading the same entry at the same time. Best Wishes! Xiang Yuan 09/01/2016 ---------------------------------------------------------------------------- On 8/31/2016 21:54, Alex wrote: Hi, On 08/26/2016 10:42 AM, yuanxiang (F) wrote: > HI, all: > We found than JTReg test case jdk/test/java/rmi/server/Unreferenced/finiteGCLatency/FiniteGCLatency.java may fail sometimes. > > It reported: > /*******************************************/ > > Regression test for bug 4164696 > > exported remote object > created registry > bound remote object in registry > unbound remote object from registry; waiting for unreferenced() callback... > java.lang.RuntimeException: TEST FAILED: unrefereced() not invoked after 50.0 seconds > at FiniteGCLatency.main(FiniteGCLatency.java:97) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:498) > at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:110) > at java.lang.Thread.run(Thread.java:745) > > JavaTest Message: Test threw exception: java.lang.RuntimeException: > TEST FAILED: unrefereced() not invoked after 50.0 seconds JavaTest > Message: shutting down test > /*******************************************/ > > Test command: > jtreg -va -nr ./jdk8u-aarch32/jdk/test/java/rmi/server/Unreferenced/finiteGCLatency/FiniteGCLatency.java > (Use Serial GC.) > > This bug is random, and we may need to test it on different account or machine to reproduce. Just for the record, I cannot reproduce neither this nor the TransformationWarningsTest failures on 3 different arm boards. It probably requires a bigger machine to reproduce this. > > We found the root cause is that the field _time_of_last_gc of class Generation is not initialized. > > > This case sets RMI GC interval to 6s, and waits for method Unreferenced to be invoked in 50s. > In the failed cases, method Unreferenced didn't been invoked. > > And this is because: > (1) test case sets 6000ms to sun.rmi.dgc.client.gcInterval > (2) DGCClient.lookup() creates a new GC$LatencyRequest object to set the new interval. > (3) And the following method calls are: > constructor GC$LatencyRequest() --> GC$LatencyRequest.adjustLatencyIfNeeded() --> GC$Daemon.setLatencyTarget() --> > create or notify thread GC$Daemon --> GC$Daemon.run() --> > GC.maxObjectInspectionAge() --> GenCollectedHeap::millis_since_last_gc() --> > GenCollectedHead::generation_iterate() --> GenTimeOfLastGCClosure.do_generation() --> > Generation.time_of_last_gc() > (4) Generation.time_of_last_gc() returns the static field _time_of_last_gc, however it hasn't been initialized. > (5) If the value of _time_of_last_gc is very big, the test case fails. > > The analysis above takes Serial GC as example. > According to the codes, CMS GC may have the same problem. Parallel GC initializes the field _time_of_last_gc and is OK. > > > Following is the patch to fix this problem. > /*******************************Patch Begin**********************************/ > Index: hotspot/src/share/vm/memory/generation.cpp > =================================================================== > --- hotspot/src/share/vm/memory/generation.cpp > +++ hotspot/src/share/vm/memory/generation.cpp > @@ -46,6 +46,7 @@ > PRAGMA_FORMAT_MUTE_WARNINGS_FOR_GCC > > Generation::Generation(ReservedSpace rs, size_t initial_size, int level) : > + _time_of_last_gc(0L), > _level(level), > _ref_processor(NULL) { > if (!_virtual_space.initialize(rs, initial_size)) { > Index: hotspot/src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp > =================================================================== > --- hotspot/src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp > +++ hotspot/src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp > @@ -553,6 +553,7 @@ > CMSCollector::CMSCollector(ConcurrentMarkSweepGeneration* cmsGen, > CardTableRS* ct, > ConcurrentMarkSweepPolicy* cp): > + _time_of_last_gc(0L), > _cmsGen(cmsGen), > _ct(ct), > _ref_processor(NULL), // will be set later > /*******************************Patch End**********************************/ > > > > Best Regrards! > > > Xiang Yuan > 8/26/2016 > > > > -- -Alex From edward.nevill at gmail.com Fri Sep 2 11:01:52 2016 From: edward.nevill at gmail.com (Edward Nevill) Date: Fri, 02 Sep 2016 12:01:52 +0100 Subject: RFR: 8164652: c1 port In-Reply-To: References: Message-ID: <1472814112.960.9.camel@gmail.com> Hi Andrey, Now that I have got back from holiday I have had a chance to try this. The following is what I tried. - Initial C1 build. - Rebuild using C1 above - Build 'core' to check this still works - Run jtreg hotspot and langtools - Build a fastdebug version - Run jtreg hotspot and langtools using the fastdebug vsn The only problem I noticed was there were a couple of assertion failures running jtreg hotspot with the fastdebug version. Apart from that it seems pretty solid. I also did some benchmarking. I am not going to disclose the results on the list, but I was very pleased with the results, >> 50X performance improvement over template interpreter. If there are no objections I will tag the current state of the tree and push this within the next day or so. Do you have a list of all the contributors at Azul so I can add them to the commit? Thanks for this. This will make a lot of people very happy. Ed. On Fri, 2016-08-26 at 13:29 +0300, Andrey Petushkov wrote: > Dear All, > > Please consider the following patch which brings the port of C1 > compiler to the aarch32 platform. The effort is done by Azul Systems > and takes the roots from AArch64 implementation. > There are very few cosmetic changes which are not directly related to > the port. In addition there is a change to the behaviour of branch > emission logic. It does not emit far branch even for occasions > subject to relocation (unless far_branches()). Of course the proper > implementation of the patching code is in place > > The webrev is here http://cr.openjdk.java.net/~apetushkov/8164652/web > rev/ > > Regards, > Andrey From edward.nevill at gmail.com Fri Sep 2 11:14:59 2016 From: edward.nevill at gmail.com (Edward Nevill) Date: Fri, 02 Sep 2016 12:14:59 +0100 Subject: [8u] RFR: JDK-8164041: support old pre-c++11 toolchains and ucLibc In-Reply-To: <4846EE4A-4867-4569-A8EC-19412838F11E@gmail.com> References: <87EC928A-0411-4AF6-9E25-5F4C77FEF5E1@gmail.com> <3e28bb50-1957-52a7-8b0e-11e5b602ff33@redhat.com> <57BDC69D.8030309@redhat.com> <1472212395.2756.6.camel@gmail.com> <4846EE4A-4867-4569-A8EC-19412838F11E@gmail.com> Message-ID: <1472814899.960.19.camel@gmail.com> ?? On Fri, 2016-08-26 at 16:01 +0300, Andrey Petushkov wrote: > Hi Ed, > > Thank you for response! It?s though not quite clear to me if it?s possible to use generated code there since these functions are inline, so having them as generated incur indirect call, which likely alleviates any performance gain (so for universal binary it?s easier to just build against the lowest supported CPU anyway) Yes, of course, the fact that it cannot inline the dynamic calls leads to a performance hit. Two possible solutions to this 1) Do a static test. ? ?if (has_ldrexd()) do_ldrexd; else do_somethingelse; This can then be inlined and reduces the cost to a single static test and a predicted branch. 2) Generate 2 versions of libjvm.so (say libjvm.so and libjvm_ldrexd.so) and have the loader select the correct version in a similar way to the way it selects the client ot server vm. This would have no performance overhead, but is considerably more complex and would require a JEP if it were to be accepted upstream. I do think there is value in having a single image which works across all variants of ARMs. All the best, Ed. From adinn at redhat.com Fri Sep 2 11:41:43 2016 From: adinn at redhat.com (Andrew Dinn) Date: Fri, 2 Sep 2016 12:41:43 +0100 Subject: RFR: 8164652: c1 port In-Reply-To: <1472814112.960.9.camel@gmail.com> References: <1472814112.960.9.camel@gmail.com> Message-ID: On 02/09/16 12:01, Edward Nevill wrote: > The only problem I noticed was there were a couple of assertion > failures running jtreg hotspot with the fastdebug version. > > Apart from that it seems pretty solid. > > I also did some benchmarking. I am not going to disclose the results on > the list, but I was very pleased with the results, >> 50X performance > improvement over template interpreter. Nice! Congratulations to the Andrey and the rest of C1 team. regards, Andrew Dinn ----------- From andrey.petushkov at gmail.com Fri Sep 2 13:46:20 2016 From: andrey.petushkov at gmail.com (Andrey Petushkov) Date: Fri, 2 Sep 2016 16:46:20 +0300 Subject: [8u] RFR: JDK-8164041: support old pre-c++11 toolchains and ucLibc In-Reply-To: <1472814899.960.19.camel@gmail.com> References: <87EC928A-0411-4AF6-9E25-5F4C77FEF5E1@gmail.com> <3e28bb50-1957-52a7-8b0e-11e5b602ff33@redhat.com> <57BDC69D.8030309@redhat.com> <1472212395.2756.6.camel@gmail.com> <4846EE4A-4867-4569-A8EC-19412838F11E@gmail.com> <1472814899.960.19.camel@gmail.com> Message-ID: <2E9C6425-629D-45D3-928A-6E0F18217B05@gmail.com> Dear Ed, >> Hi Ed, >> >> Thank you for response! It?s though not quite clear to me if it?s possible to use generated code there since these functions are inline, so having them as generated incur indirect call, which likely alleviates any performance gain (so for universal binary it?s easier to just build against the lowest supported CPU anyway) > > > Yes, of course, the fact that it cannot inline the dynamic calls leads > to a performance hit. > > Two possible solutions to this > > 1) Do a static test. > > if (has_ldrexd()) do_ldrexd; else do_somethingelse; > > This can then be inlined and reduces the cost to a single static test > and a predicted branch. Well, that is right. However we have found that making even a simple check against the global variable is really expensive in such places. You can see by ?UseMembar? change in the c1 patch. We have observed that eliminating the check and effectively executing barrier instruction even when unnecessary is still faster compared to checking the variable and not executing the barrier.. So it takes to play and measure a bit.. > > 2) Generate 2 versions of libjvm.so (say libjvm.so and > libjvm_ldrexd.so) and have the loader select the correct version in a > similar way to the way it selects the client ot server vm. > > This would have no performance overhead, but is considerably more > complex and would require a JEP if it were to be accepted upstream. Fully agree. Less maintainable in addition > > I do think there is value in having a single image which works across > all variants of ARMs. Yes, I do think the same. Although the deeper to go the more it takes to support it. Do you have any feeling of what is the lowest/oldest ARM version it makes sense to support in the aarch32 port? Thank you, Andrey > > All the best, > Ed. > From andrey.petushkov at gmail.com Fri Sep 2 14:19:36 2016 From: andrey.petushkov at gmail.com (Andrey Petushkov) Date: Fri, 2 Sep 2016 17:19:36 +0300 Subject: RFR: 8164652: c1 port In-Reply-To: <1472814112.960.9.camel@gmail.com> References: <1472814112.960.9.camel@gmail.com> Message-ID: <86A54E3B-4433-48F1-91D4-EE9AF99B3D1C@gmail.com> Hi Ed, > On 02 Sep 2016, at 14:01, Edward Nevill wrote: > > Hi Andrey, > > Now that I have got back from holiday I have had a chance to try this. > > The following is what I tried. > > - Initial C1 build. > - Rebuild using C1 above > - Build 'core' to check this still works > - Run jtreg hotspot and langtools > - Build a fastdebug version > - Run jtreg hotspot and langtools using the fastdebug vsn > > The only problem I noticed was there were a couple of assertion > failures running jtreg hotspot with the fastdebug version. Thank you, we did not check fastdebug thoroughly. Will take a look > > Apart from that it seems pretty solid. > > I also did some benchmarking. I am not going to disclose the results on > the list, but I was very pleased with the results, >> 50X performance > improvement over template interpreter. > > If there are no objections I will tag the current state of the tree and > push this within the next day or so. Do you have a list of all the > contributors at Azul so I can add them to the commit? The developers of the c1 port is the following: Andrey Petushkov / andrey.petushkov at gmail.com / apetushkov Anton Kozlov / akozlov at azul.com Fedor Burdun / fedor.burdun at azulsystems.com Sergey Nazarkin / snazarkin at azul.com / snazarki Alexey Bakhtin / alexey.bakhtin at gmail.com > > Thanks for this. This will make a lot of people very happy. :) Thanks to you for leading the effort! Regards, Andrey > > Ed. > > On Fri, 2016-08-26 at 13:29 +0300, Andrey Petushkov wrote: >> Dear All, >> >> Please consider the following patch which brings the port of C1 >> compiler to the aarch32 platform. The effort is done by Azul Systems >> and takes the roots from AArch64 implementation. >> There are very few cosmetic changes which are not directly related to >> the port. In addition there is a change to the behaviour of branch >> emission logic. It does not emit far branch even for occasions >> subject to relocation (unless far_branches()). Of course the proper >> implementation of the patching code is in place >> >> The webrev is here http://cr.openjdk.java.net/~apetushkov/8164652/web >> rev/ >> >> Regards, >> Andrey From aph at redhat.com Sun Sep 4 07:43:00 2016 From: aph at redhat.com (Andrew Haley) Date: Sun, 4 Sep 2016 08:43:00 +0100 Subject: RFR: 8164652: c1 port, code patching In-Reply-To: <2262cf97-394c-8a3a-e6dc-a6053d928a3c@redhat.com> References: <1472211998.2756.2.camel@gmail.com> <2262cf97-394c-8a3a-e6dc-a6053d928a3c@redhat.com> Message-ID: <97c9c7cb-0a12-4dfc-93fe-281684c5b6bc@redhat.com> On 31/08/16 17:58, Andrew Haley wrote: > [ As an aside: I don't think that the trampolines on AArch64 are > vulnerable in the same way ... Having said that, perhaps we need > an acquiring load in this AArch64 stub instead of a simple LDR. ] I realized [remembered?] that this isn't really a problem. The worst that can happen is that we see a pointer to the old version of our callee and jump to it. That's OK because the old version is still a correct execution, but it'll probably trap because it's marked as non-entrant. Andrew. From edward.nevill at gmail.com Sun Sep 4 20:43:59 2016 From: edward.nevill at gmail.com (edward.nevill at gmail.com) Date: Sun, 04 Sep 2016 20:43:59 +0000 Subject: hg: aarch32-port/jdk8u: Added tag jdk8u-core-final for changeset 2c56ff57079c Message-ID: <201609042043.u84KhxB8015460@aojmv0008.oracle.com> Changeset: ff89301f2430 Author: enevill Date: 2016-09-04 20:31 +0100 URL: http://hg.openjdk.java.net/aarch32-port/jdk8u/rev/ff89301f2430 Added tag jdk8u-core-final for changeset 2c56ff57079c ! .hgtags From edward.nevill at gmail.com Sun Sep 4 20:44:19 2016 From: edward.nevill at gmail.com (edward.nevill at gmail.com) Date: Sun, 04 Sep 2016 20:44:19 +0000 Subject: hg: aarch32-port/jdk8u/corba: Added tag jdk8u-core-final for changeset 329c59a861cf Message-ID: <201609042044.u84KiJwT015537@aojmv0008.oracle.com> Changeset: a50ef9c31e38 Author: enevill Date: 2016-09-04 20:31 +0100 URL: http://hg.openjdk.java.net/aarch32-port/jdk8u/corba/rev/a50ef9c31e38 Added tag jdk8u-core-final for changeset 329c59a861cf ! .hgtags From edward.nevill at gmail.com Sun Sep 4 20:44:36 2016 From: edward.nevill at gmail.com (edward.nevill at gmail.com) Date: Sun, 04 Sep 2016 20:44:36 +0000 Subject: hg: aarch32-port/jdk8u/hotspot: 2 new changesets Message-ID: <201609042044.u84Kib00015692@aojmv0008.oracle.com> Changeset: c1fe55b6bb62 Author: enevill Date: 2016-09-04 20:32 +0100 URL: http://hg.openjdk.java.net/aarch32-port/jdk8u/hotspot/rev/c1fe55b6bb62 Added tag jdk8u-core-final for changeset 186d445bec04 ! .hgtags Changeset: 80b7b526cffb Author: enevill Date: 2016-09-04 20:52 +0100 URL: http://hg.openjdk.java.net/aarch32-port/jdk8u/hotspot/rev/80b7b526cffb 8164652: aarch32: C1 port Reviewed-by: enevill Contributed-by: Andrey Petushkov , Anton Kozlov , Fedor Burdun , Sergey Nazarkin , Alexey Bakhtin ! src/cpu/aarch32/vm/assembler_aarch32.cpp ! src/cpu/aarch32/vm/assembler_aarch32.hpp + src/cpu/aarch32/vm/c1_CodeStubs_aarch32.cpp + src/cpu/aarch32/vm/c1_Defs_aarch32.hpp + src/cpu/aarch32/vm/c1_FpuStackSim_aarch32.cpp + src/cpu/aarch32/vm/c1_FpuStackSim_aarch32.hpp + src/cpu/aarch32/vm/c1_FrameMap_aarch32.cpp + src/cpu/aarch32/vm/c1_FrameMap_aarch32.hpp + src/cpu/aarch32/vm/c1_LIRAssembler_aarch32.cpp + src/cpu/aarch32/vm/c1_LIRAssembler_aarch32.hpp + src/cpu/aarch32/vm/c1_LIRGenerator_aarch32.cpp + src/cpu/aarch32/vm/c1_LinearScan_aarch32.cpp + src/cpu/aarch32/vm/c1_LinearScan_aarch32.hpp + src/cpu/aarch32/vm/c1_MacroAssembler_aarch32.cpp + src/cpu/aarch32/vm/c1_MacroAssembler_aarch32.hpp + src/cpu/aarch32/vm/c1_Runtime1_aarch32.cpp + src/cpu/aarch32/vm/c1_globals_aarch32.hpp ! src/cpu/aarch32/vm/globals_aarch32.hpp ! src/cpu/aarch32/vm/icBuffer_aarch32.cpp ! src/cpu/aarch32/vm/macroAssembler_aarch32.cpp ! src/cpu/aarch32/vm/macroAssembler_aarch32.hpp ! src/cpu/aarch32/vm/nativeInst_aarch32.cpp ! src/cpu/aarch32/vm/relocInfo_aarch32.cpp ! src/cpu/aarch32/vm/sharedRuntime_aarch32.cpp ! src/cpu/aarch32/vm/stubGenerator_aarch32.cpp ! src/cpu/aarch32/vm/templateInterpreter_aarch32.cpp ! src/share/vm/c1/c1_LIR.hpp ! src/share/vm/c1/c1_LinearScan.cpp ! src/share/vm/c1/c1_Runtime1.cpp ! src/share/vm/runtime/globals.hpp From edward.nevill at gmail.com Sun Sep 4 20:45:03 2016 From: edward.nevill at gmail.com (edward.nevill at gmail.com) Date: Sun, 04 Sep 2016 20:45:03 +0000 Subject: hg: aarch32-port/jdk8u/jaxp: Added tag jdk8u-core-final for changeset 26a14181abe1 Message-ID: <201609042045.u84Kj3Pq015851@aojmv0008.oracle.com> Changeset: d35588c5ead1 Author: enevill Date: 2016-09-04 20:32 +0100 URL: http://hg.openjdk.java.net/aarch32-port/jdk8u/jaxp/rev/d35588c5ead1 Added tag jdk8u-core-final for changeset 26a14181abe1 ! .hgtags From edward.nevill at gmail.com Sun Sep 4 20:45:19 2016 From: edward.nevill at gmail.com (edward.nevill at gmail.com) Date: Sun, 04 Sep 2016 20:45:19 +0000 Subject: hg: aarch32-port/jdk8u/jaxws: Added tag jdk8u-core-final for changeset bdb0785f9799 Message-ID: <201609042045.u84KjJux015922@aojmv0008.oracle.com> Changeset: d74a9313dbba Author: enevill Date: 2016-09-04 20:32 +0100 URL: http://hg.openjdk.java.net/aarch32-port/jdk8u/jaxws/rev/d74a9313dbba Added tag jdk8u-core-final for changeset bdb0785f9799 ! .hgtags From edward.nevill at gmail.com Sun Sep 4 20:45:44 2016 From: edward.nevill at gmail.com (edward.nevill at gmail.com) Date: Sun, 04 Sep 2016 20:45:44 +0000 Subject: hg: aarch32-port/jdk8u/jdk: 2 new changesets Message-ID: <201609042045.u84Kjigi016144@aojmv0008.oracle.com> Changeset: 9987239a4a4b Author: enevill Date: 2016-09-04 20:32 +0100 URL: http://hg.openjdk.java.net/aarch32-port/jdk8u/jdk/rev/9987239a4a4b Added tag jdk8u-core-final for changeset 80f4d01c3ad0 ! .hgtags Changeset: c5fd893fea79 Author: enevill Date: 2016-09-04 20:56 +0100 URL: http://hg.openjdk.java.net/aarch32-port/jdk8u/jdk/rev/c5fd893fea79 8164652: aarch32: C1 port Reviewed-by: enevill Contributed-by: Andrey Petushkov ! make/CopyFiles.gmk From edward.nevill at gmail.com Sun Sep 4 20:46:04 2016 From: edward.nevill at gmail.com (edward.nevill at gmail.com) Date: Sun, 04 Sep 2016 20:46:04 +0000 Subject: hg: aarch32-port/jdk8u/langtools: Added tag jdk8u-core-final for changeset 71509c80dcbd Message-ID: <201609042046.u84Kk4cF016386@aojmv0008.oracle.com> Changeset: 7ba3a5b99199 Author: enevill Date: 2016-09-04 20:32 +0100 URL: http://hg.openjdk.java.net/aarch32-port/jdk8u/langtools/rev/7ba3a5b99199 Added tag jdk8u-core-final for changeset 71509c80dcbd ! .hgtags From edward.nevill at gmail.com Sun Sep 4 20:46:22 2016 From: edward.nevill at gmail.com (edward.nevill at gmail.com) Date: Sun, 04 Sep 2016 20:46:22 +0000 Subject: hg: aarch32-port/jdk8u/nashorn: Added tag jdk8u-core-final for changeset d8550d9adef9 Message-ID: <201609042046.u84KkMA4016488@aojmv0008.oracle.com> Changeset: 29176d349783 Author: enevill Date: 2016-09-04 20:33 +0100 URL: http://hg.openjdk.java.net/aarch32-port/jdk8u/nashorn/rev/29176d349783 Added tag jdk8u-core-final for changeset d8550d9adef9 ! .hgtags From simon at cjnash.com Tue Sep 6 23:24:35 2016 From: simon at cjnash.com (Simon Nash) Date: Wed, 07 Sep 2016 00:24:35 +0100 Subject: Problem building the current source Message-ID: <57CF5033.10403@cjnash.com> I am trying to build the current source using the instructions on this page: http://hg.openjdk.java.net/jdk8/jdk8/raw-file/tip/README-builds.html While running the "make all" step, I got the following errors: .... Compiling /sd1/aarch32/hotspot/src/share/vm/adlc/adlparse.cpp Compiling /sd1/aarch32/hotspot/src/share/vm/adlc/archDesc.cpp Compiling /sd1/aarch32/hotspot/src/share/vm/adlc/arena.cpp Compiling /sd1/aarch32/hotspot/src/share/vm/adlc/dfa.cpp Compiling /sd1/aarch32/hotspot/src/share/vm/adlc/dict2.cpp Compiling /sd1/aarch32/hotspot/src/share/vm/adlc/filebuff.cpp Compiling /sd1/aarch32/hotspot/src/share/vm/adlc/forms.cpp Compiling /sd1/aarch32/hotspot/src/share/vm/adlc/formsopt.cpp Compiling /sd1/aarch32/hotspot/src/share/vm/adlc/formssel.cpp Compiling /sd1/aarch32/hotspot/src/share/vm/adlc/main.cpp Compiling /sd1/aarch32/hotspot/src/share/vm/opto/opcodes.cpp Compiling /sd1/aarch32/hotspot/src/share/vm/adlc/output_c.cpp Compiling /sd1/aarch32/hotspot/src/share/vm/adlc/output_h.cpp Making adlc make[6]: *** No rule to make target '/sd1/aarch32/hotspot/src/cpu/aarch32/vm/aarch32.ad', needed by '../generated/adfiles/linux_aarch32.ad'. Stop. make[5]: *** [ad_stuff] Error 2 /sd1/aarch32/hotspot/make/linux/makefiles/top.make:91: recipe for target 'ad_stuff' failed /sd1/aarch32/hotspot/make/linux/Makefile:297: recipe for target 'product' failed make[4]: *** [product] Error 2 make[3]: *** [generic_build2] Error 2 Makefile:230: recipe for target 'generic_build2' failed make[2]: *** [product] Error 2 Makefile:177: recipe for target 'product' failed make[1]: *** [/sd1/aarch32/build/linux-aarch32-normal-server-release/hotspot/_hotspot.timestamp] Error 2 HotspotWrapper.gmk:44: recipe for target '/sd1/aarch32/build/linux-aarch32-normal-server-release/hotspot/_hotspot.timestamp' failed /sd1/aarch32//make/Main.gmk:108: recipe for target 'hotspot-only' failed make: *** [hotspot-only] Error 2 Any pointers for how to solve this would be much appreciated. Many thanks, Simon Nash From yangyongyong at huawei.com Wed Sep 7 01:32:50 2016 From: yangyongyong at huawei.com (yangyongyong) Date: Wed, 7 Sep 2016 01:32:50 +0000 Subject: =?gb2312?B?tPC4tDogUHJvYmxlbSBidWlsZGluZyB0aGUgY3VycmVudCBzb3VyY2U=?= In-Reply-To: <57CF5033.10403@cjnash.com> References: <57CF5033.10403@cjnash.com> Message-ID: Hi, Simon, please check the options used for configuration, make sure "--with-jvm-variants=client" is present. Probably your problem will be resolved. Regards. -----????----- ???: aarch32-port-dev [mailto:aarch32-port-dev-bounces at openjdk.java.net] ?? Simon Nash ????: 2016?9?7? 7:25 ???: aarch32-port-dev at openjdk.java.net ??: Problem building the current source I am trying to build the current source using the instructions on this page: http://hg.openjdk.java.net/jdk8/jdk8/raw-file/tip/README-builds.html While running the "make all" step, I got the following errors: .... Compiling /sd1/aarch32/hotspot/src/share/vm/adlc/adlparse.cpp Compiling /sd1/aarch32/hotspot/src/share/vm/adlc/archDesc.cpp Compiling /sd1/aarch32/hotspot/src/share/vm/adlc/arena.cpp Compiling /sd1/aarch32/hotspot/src/share/vm/adlc/dfa.cpp Compiling /sd1/aarch32/hotspot/src/share/vm/adlc/dict2.cpp Compiling /sd1/aarch32/hotspot/src/share/vm/adlc/filebuff.cpp Compiling /sd1/aarch32/hotspot/src/share/vm/adlc/forms.cpp Compiling /sd1/aarch32/hotspot/src/share/vm/adlc/formsopt.cpp Compiling /sd1/aarch32/hotspot/src/share/vm/adlc/formssel.cpp Compiling /sd1/aarch32/hotspot/src/share/vm/adlc/main.cpp Compiling /sd1/aarch32/hotspot/src/share/vm/opto/opcodes.cpp Compiling /sd1/aarch32/hotspot/src/share/vm/adlc/output_c.cpp Compiling /sd1/aarch32/hotspot/src/share/vm/adlc/output_h.cpp Making adlc make[6]: *** No rule to make target '/sd1/aarch32/hotspot/src/cpu/aarch32/vm/aarch32.ad', needed by '../generated/adfiles/linux_aarch32.ad'. Stop. make[5]: *** [ad_stuff] Error 2 /sd1/aarch32/hotspot/make/linux/makefiles/top.make:91: recipe for target 'ad_stuff' failed /sd1/aarch32/hotspot/make/linux/Makefile:297: recipe for target 'product' failed make[4]: *** [product] Error 2 make[3]: *** [generic_build2] Error 2 Makefile:230: recipe for target 'generic_build2' failed make[2]: *** [product] Error 2 Makefile:177: recipe for target 'product' failed make[1]: *** [/sd1/aarch32/build/linux-aarch32-normal-server-release/hotspot/_hotspot.timestamp] Error 2 HotspotWrapper.gmk:44: recipe for target '/sd1/aarch32/build/linux-aarch32-normal-server-release/hotspot/_hotspot.timestamp' failed /sd1/aarch32//make/Main.gmk:108: recipe for target 'hotspot-only' failed make: *** [hotspot-only] Error 2 Any pointers for how to solve this would be much appreciated. Many thanks, Simon Nash From simon at cjnash.com Fri Sep 9 06:13:31 2016 From: simon at cjnash.com (Simon Nash) Date: Fri, 09 Sep 2016 07:13:31 +0100 Subject: =?GB2312?B?tPC4tDogUHJvYmxlbSBidWlsZGluZyB0aGUgY3VycmVudCBzbw==?= =?GB2312?B?dXJjZQ==?= In-Reply-To: References: <57CF5033.10403@cjnash.com> Message-ID: <57D2530B.3040305@cjnash.com> yangyongyong wrote: > Hi, Simon, please check the options used for configuration, make sure "--with-jvm-variants=client" is present. > Probably your problem will be resolved. > > Regards. > Thanks for this. I have now been able to build the code successfully. Simon > -----????----- > ???: aarch32-port-dev [mailto:aarch32-port-dev-bounces at openjdk.java.net] ?? Simon Nash > ????: 2016?9?7? 7:25 > ???: aarch32-port-dev at openjdk.java.net > ??: Problem building the current source > > I am trying to build the current source using the instructions on this page: > http://hg.openjdk.java.net/jdk8/jdk8/raw-file/tip/README-builds.html > > While running the "make all" step, I got the following errors: > > .... > Compiling /sd1/aarch32/hotspot/src/share/vm/adlc/adlparse.cpp > Compiling /sd1/aarch32/hotspot/src/share/vm/adlc/archDesc.cpp > Compiling /sd1/aarch32/hotspot/src/share/vm/adlc/arena.cpp > Compiling /sd1/aarch32/hotspot/src/share/vm/adlc/dfa.cpp > Compiling /sd1/aarch32/hotspot/src/share/vm/adlc/dict2.cpp > Compiling /sd1/aarch32/hotspot/src/share/vm/adlc/filebuff.cpp > Compiling /sd1/aarch32/hotspot/src/share/vm/adlc/forms.cpp > Compiling /sd1/aarch32/hotspot/src/share/vm/adlc/formsopt.cpp > Compiling /sd1/aarch32/hotspot/src/share/vm/adlc/formssel.cpp > Compiling /sd1/aarch32/hotspot/src/share/vm/adlc/main.cpp > Compiling /sd1/aarch32/hotspot/src/share/vm/opto/opcodes.cpp > Compiling /sd1/aarch32/hotspot/src/share/vm/adlc/output_c.cpp > Compiling /sd1/aarch32/hotspot/src/share/vm/adlc/output_h.cpp > Making adlc > make[6]: *** No rule to make target '/sd1/aarch32/hotspot/src/cpu/aarch32/vm/aarch32.ad', needed by '../generated/adfiles/linux_aarch32.ad'. Stop. > make[5]: *** [ad_stuff] Error 2 > /sd1/aarch32/hotspot/make/linux/makefiles/top.make:91: recipe for target 'ad_stuff' failed > /sd1/aarch32/hotspot/make/linux/Makefile:297: recipe for target 'product' failed > make[4]: *** [product] Error 2 > make[3]: *** [generic_build2] Error 2 > Makefile:230: recipe for target 'generic_build2' failed > make[2]: *** [product] Error 2 > Makefile:177: recipe for target 'product' failed > make[1]: *** [/sd1/aarch32/build/linux-aarch32-normal-server-release/hotspot/_hotspot.timestamp] Error 2 > HotspotWrapper.gmk:44: recipe for target '/sd1/aarch32/build/linux-aarch32-normal-server-release/hotspot/_hotspot.timestamp' failed > /sd1/aarch32//make/Main.gmk:108: recipe for target 'hotspot-only' failed > make: *** [hotspot-only] Error 2 > > Any pointers for how to solve this would be much appreciated. > > Many thanks, > Simon Nash From yangyongyong at huawei.com Fri Sep 9 10:57:12 2016 From: yangyongyong at huawei.com (yangyongyong) Date: Fri, 9 Sep 2016 10:57:12 +0000 Subject: RFR: tune native call site check Message-ID: Roughly there are 3 kinds of native call site checked by nativeCall_before(): 1. Native-Trampoline-Call takes the form of: add lr, pc, #4 ldr pc, [pc, -4] 0x???????? # call_destination #return_address: Some_insn 2. Native-Imm-Call bl imm # call_destination #return_address: Some_insn 3. Native-Reg-Call movw regx, #call_destination movt regx, #call_destination bl regx # call destination #return_address: Some_insn Current check logic incurs a problem if the encoding of the call destination of type 1 can by any chance be disassembled as a ?bl imm? instruction. And thus the call address is calculated improperly and then the relocation info will not be found, which causes assert failure in CompiledIC::CompiledIC(nmethod* nm, NativeCall* call): assert(ret == true, "relocInfo must exist at this address"); This failure can be reproduced simply by ?java -Xcomp -XX:ReservedCodeCacheSize=xx?. Please tune xx and make sure some of the JITed code is placed at address 0x?B??????. The attached patch improves the check logic: ----------------- patch begins ---------------- diff -r 80b7b526cffb src/cpu/aarch32/vm/nativeInst_aarch32.cpp --- a/src/cpu/aarch32/vm/nativeInst_aarch32.cpp Sun Sep 04 20:52:43 2016 +0100 +++ b/src/cpu/aarch32/vm/nativeInst_aarch32.cpp Fri Sep 09 17:38:34 2016 +0800 @@ -132,14 +132,14 @@ } bool NativeCall::is_at(address addr) { - if (NativeImmCall::is_at(addr)) { + if (NativeTrampolineCall::is_at(addr)) { return true; } else if (NativeMovConstReg::is_at(addr)) { NativeMovConstReg *nm = NativeMovConstReg::from(addr); address next_instr = nm->next_instruction_address(); return NativeRegCall::is_at(next_instr) && NativeRegCall::from(next_instr)->destination() == nm->destination(); - } else if (NativeTrampolineCall::is_at(addr)) { + } else if (NativeImmCall::is_at(addr)) { return true; } return false; diff -r 80b7b526cffb src/cpu/aarch32/vm/nativeInst_aarch32.hpp --- a/src/cpu/aarch32/vm/nativeInst_aarch32.hpp Sun Sep 04 20:52:43 2016 +0100 +++ b/src/cpu/aarch32/vm/nativeInst_aarch32.hpp Fri Sep 09 17:38:34 2016 +0800 @@ -306,10 +306,10 @@ inline NativeCall* nativeCall_before(address return_address) { address call_addr = NULL; - if (NativeCall::is_at(return_address - NativeBranchType::instruction_size)) { + if (NativeCall::is_at(return_address - NativeCall::instruction_size)) { + call_addr = return_address - NativeCall::instruction_size; + } else if (NativeCall::is_at(return_address - NativeBranchType::instruction_size)) { call_addr = return_address - NativeBranchType::instruction_size; - } else if (NativeCall::is_at(return_address - NativeCall::instruction_size)) { - call_addr = return_address - NativeCall::instruction_size; } else { ShouldNotReachHere(); } ----------------- patch ends ---------------- From akozlov at azul.com Fri Sep 9 12:34:52 2016 From: akozlov at azul.com (Anton Kozlov) Date: Fri, 9 Sep 2016 12:34:52 +0000 Subject: RFR: tune native call site check In-Reply-To: References: Message-ID: <1473424512.19778.42.camel@azul.com> Hi! Thanks for finding this! You're right, this is a bug. However, if NativeCall::is_at will be fixed like suggested, then the long instruction sequence will be checked before short one. And now consider situation, when this call is the last instruction of last method in CodeCache, unluckily placed at end of page. "Long" check will try to read next page of CodeCache (forbidden for r/w/x) and will trigger segfault, which is not expected and not handled by JVM. Actually, we've seen that =) There is a suggestion to fix only nativeCall_before, by explicitly checking NativeImmCall, NativeTrampolineCall, NativeRegCall there with appropriate offsets. Actually, it looks more correct instead of trying to find any of these 3 Native* at offset 4 and then at offset 12. Thanks, Anton On Fri, 2016-09-09 at 10:57 +0000, yangyongyong wrote: > Roughly there are 3 kinds of native call site checked by nativeCall_before(): > > 1.???????Native-Trampoline-Call takes the form of: > > add?????lr, pc, #4 > ldr?????pc, [pc, -4] > 0x????????????# call_destination > #return_address: > ? Some_insn > > > 2.???????Native-Imm-Call > > bl imm??# call_destination > #return_address: > ? Some_insn > > > 3.???????Native-Reg-Call > > > ???movw regx, #call_destination > > ???movt regx, #call_destination > bl regx????# call destination > #return_address: > ? Some_insn > > Current check logic incurs a problem if the encoding of the call destination > of type 1 can by any chance be disassembled as a ?bl imm? instruction. > And thus the call address is calculated improperly and then the relocation > info will not be found, which causes assert failure in > CompiledIC::CompiledIC(nmethod* nm, NativeCall* call): > assert(ret == true, "relocInfo must exist at this address"); > > This failure can be reproduced simply by ?java -Xcomp > -XX:ReservedCodeCacheSize=xx?. Please tune xx and make sure some of the JITed > code is placed at address 0x?B??????. > The attached patch improves the check logic: > ----------------- patch begins ---------------- > diff -r 80b7b526cffb src/cpu/aarch32/vm/nativeInst_aarch32.cpp > --- a/src/cpu/aarch32/vm/nativeInst_aarch32.cpp?????????Sun Sep 04 20:52:43 > 2016 +0100 > +++ b/src/cpu/aarch32/vm/nativeInst_aarch32.cpp??????Fri Sep 09 17:38:34 2016 > +0800 > @@ -132,14 +132,14 @@ > } > ?bool NativeCall::is_at(address addr) { > -??if (NativeImmCall::is_at(addr)) { > +??if (NativeTrampolineCall::is_at(addr)) { > ?????return true; > ???} else if (NativeMovConstReg::is_at(addr)) { > ?????NativeMovConstReg *nm = NativeMovConstReg::from(addr); > ?????address next_instr = nm->next_instruction_address(); > ?????return NativeRegCall::is_at(next_instr) && > ???????NativeRegCall::from(next_instr)->destination() == nm->destination(); > -??} else if (NativeTrampolineCall::is_at(addr)) { > +??} else if (NativeImmCall::is_at(addr)) { > ?????return true; > ???} > ???return false; > diff -r 80b7b526cffb src/cpu/aarch32/vm/nativeInst_aarch32.hpp > --- a/src/cpu/aarch32/vm/nativeInst_aarch32.hpp?????????Sun Sep 04 20:52:43 > 2016 +0100 > +++ b/src/cpu/aarch32/vm/nativeInst_aarch32.hpp??????Fri Sep 09 17:38:34 2016 > +0800 > @@ -306,10 +306,10 @@ > ?inline NativeCall* nativeCall_before(address return_address) { > ???address call_addr = NULL; > -??if (NativeCall::is_at(return_address - NativeBranchType::instruction_size)) > { > +??if (NativeCall::is_at(return_address - NativeCall::instruction_size)) { > +????call_addr = return_address - NativeCall::instruction_size; > +??} else if (NativeCall::is_at(return_address - > NativeBranchType::instruction_size)) { > ?????call_addr = return_address - NativeBranchType::instruction_size; > -??} else if (NativeCall::is_at(return_address - > NativeCall::instruction_size)) { > -????call_addr = return_address - NativeCall::instruction_size; > ???} else { > ?????ShouldNotReachHere(); > ???} > ----------------- patch ends ---------------- > From yangyongyong at huawei.com Sat Sep 10 07:14:45 2016 From: yangyongyong at huawei.com (yangyongyong) Date: Sat, 10 Sep 2016 07:14:45 +0000 Subject: RFR: tune native call site check In-Reply-To: <1473424512.19778.42.camel@azul.com> References: <1473424512.19778.42.camel@azul.com> Message-ID: Thank you, Anton, My patch *improves* the check logic a little but it does not handle the situation you mentioned. How is it reproduced? Do you have a patch at hand already? Your suggestion seems more rational. The check logic should better not mix up the situations of offset -4 and -12. Meanwhile, please note that NativeCall::is_at() is invoked somewhere else, so perhaps some minor modification of nativeCall_before() is not enough. -----Original Message----- From: Anton Kozlov [mailto:akozlov at azul.com] Sent: Friday, September 09, 2016 8:35 PM To: yangyongyong; aarch32-port-dev at openjdk.java.net Subject: Re: RFR: tune native call site check Hi! Thanks for finding this! You're right, this is a bug. However, if NativeCall::is_at will be fixed like suggested, then the long instruction sequence will be checked before short one. And now consider situation, when this call is the last instruction of last method in CodeCache, unluckily placed at end of page. "Long" check will try to read next page of CodeCache (forbidden for r/w/x) and will trigger segfault, which is not expected and not handled by JVM. Actually, we've seen that =) There is a suggestion to fix only nativeCall_before, by explicitly checking NativeImmCall, NativeTrampolineCall, NativeRegCall there with appropriate offsets. Actually, it looks more correct instead of trying to find any of these 3 Native* at offset 4 and then at offset 12. Thanks, Anton On Fri, 2016-09-09 at 10:57 +0000, yangyongyong wrote: > Roughly there are 3 kinds of native call site checked by nativeCall_before(): > > 1.???????Native-Trampoline-Call takes the form of: > > add?????lr, pc, #4 > ldr?????pc, [pc, -4] > 0x????????????# call_destination > #return_address: > ? Some_insn > > > 2.???????Native-Imm-Call > > bl imm??# call_destination > #return_address: > ? Some_insn > > > 3.???????Native-Reg-Call > > > ???movw regx, #call_destination > > ???movt regx, #call_destination > bl regx????# call destination > #return_address: > ? Some_insn > > Current check logic incurs a problem if the encoding of the call > destination of type 1 can by any chance be disassembled as a ?bl imm? instruction. > And thus the call address is calculated improperly and then the > relocation info will not be found, which causes assert failure in > CompiledIC::CompiledIC(nmethod* nm, NativeCall* call): > assert(ret == true, "relocInfo must exist at this address"); > > This failure can be reproduced simply by ?java -Xcomp > -XX:ReservedCodeCacheSize=xx?. Please tune xx and make sure some of > the JITed code is placed at address 0x?B??????. > The attached patch improves the check logic: > ----------------- patch begins ---------------- diff -r 80b7b526cffb > src/cpu/aarch32/vm/nativeInst_aarch32.cpp > --- a/src/cpu/aarch32/vm/nativeInst_aarch32.cpp?????????Sun Sep 04 > 20:52:43 > 2016 +0100 > +++ b/src/cpu/aarch32/vm/nativeInst_aarch32.cpp??????Fri Sep 09 > +++ 17:38:34 2016 > +0800 > @@ -132,14 +132,14 @@ > } > ?bool NativeCall::is_at(address addr) { > -??if (NativeImmCall::is_at(addr)) { > +??if (NativeTrampolineCall::is_at(addr)) { > ?????return true; > ???} else if (NativeMovConstReg::is_at(addr)) { > ?????NativeMovConstReg *nm = NativeMovConstReg::from(addr); > ?????address next_instr = nm->next_instruction_address(); > ?????return NativeRegCall::is_at(next_instr) && > ???????NativeRegCall::from(next_instr)->destination() == > nm->destination(); > -??} else if (NativeTrampolineCall::is_at(addr)) { > +??} else if (NativeImmCall::is_at(addr)) { > ?????return true; > ???} > ???return false; > diff -r 80b7b526cffb src/cpu/aarch32/vm/nativeInst_aarch32.hpp > --- a/src/cpu/aarch32/vm/nativeInst_aarch32.hpp?????????Sun Sep 04 > 20:52:43 > 2016 +0100 > +++ b/src/cpu/aarch32/vm/nativeInst_aarch32.hpp??????Fri Sep 09 > +++ 17:38:34 2016 > +0800 > @@ -306,10 +306,10 @@ > ?inline NativeCall* nativeCall_before(address return_address) { > ???address call_addr = NULL; > -??if (NativeCall::is_at(return_address - > NativeBranchType::instruction_size)) > { > +??if (NativeCall::is_at(return_address - > +NativeCall::instruction_size)) { > +????call_addr = return_address - NativeCall::instruction_size; > +??} else if (NativeCall::is_at(return_address - > NativeBranchType::instruction_size)) { > ?????call_addr = return_address - NativeBranchType::instruction_size; > -??} else if (NativeCall::is_at(return_address - > NativeCall::instruction_size)) { > -????call_addr = return_address - NativeCall::instruction_size; > ???} else { > ?????ShouldNotReachHere(); > ???} > ----------------- patch ends ---------------- > From akozlov at azul.com Mon Sep 12 12:33:53 2016 From: akozlov at azul.com (Anton Kozlov) Date: Mon, 12 Sep 2016 12:33:53 +0000 Subject: RFR: tune native call site check In-Reply-To: References: <1473424512.19778.42.camel@azul.com> Message-ID: <1473683653.19778.74.camel@azul.com> Hi, Yang (sorry, is it correct?), I can't remember well, it reproduced on some jtreg test. But it also should be reproduced in release mode by specifying small values for?InitialCodeCacheSize and?CodeCacheExpansionSize JVM options, like 4K. We've prepared another patch after your email with suggestions implemented (Andrey Petushkov), in attach and below. I think that nativeCall_before should be enough. The problem is that nativeCall_before is not sure where instruction sequence is started, but it calls NativeCall::is_at() anyway. NativeCall::is_at is supposed to be called on start of instruction sequence; with this precondition, I see no possibilities for is_at to misdecode target address. Please, correct me if I'm wrong. Thanks, Anton ***** patch begin ****** diff --git a/src/cpu/aarch32/vm/nativeInst_aarch32.hpp b/src/cpu/aarch32/vm/nativeInst_aarch32.hpp --- a/src/cpu/aarch32/vm/nativeInst_aarch32.hpp +++ b/src/cpu/aarch32/vm/nativeInst_aarch32.hpp @@ -303,20 +303,6 @@ ???return NativeCall::from(address); ?} ? -inline NativeCall* nativeCall_before(address return_address) { -??address call_addr = NULL; -??if (NativeCall::is_at(return_address - NativeBranchType::instruction_size)) { -????call_addr = return_address - NativeBranchType::instruction_size; -??} else if (NativeCall::is_at(return_address - NativeCall::instruction_size)) { -????call_addr = return_address - NativeCall::instruction_size; -??} else { -????ShouldNotReachHere(); -??} - -??return NativeCall::from(call_addr); -} - - ?// An interface for accessing/manipulating native moves of the form: ?//??????mov[b/w/l/q] [reg + offset], reg???(instruction_code_reg2mem) ?//??????mov[b/w/l/q] reg, [reg+offset]?????(instruction_code_mem2reg @@ -505,4 +491,27 @@ ?inline bool NativeInstruction::is_imm_jump() const??????{ return NativeImmJump::is_at(addr()); } ?inline bool NativeInstruction::is_reg_jump() const??????{ return NativeRegJump::is_at(addr()); } ? +inline NativeCall* nativeCall_before(address return_address) { +??address call_addr = NULL; +??if (NativeTrampolineCall::is_at(return_address - NativeCall::instruction_size)) { +????call_addr = return_address - NativeCall::instruction_size; +??} else if (NativeMovConstReg::is_at(return_address - NativeCall::instruction_size)) { +????NativeMovConstReg *nm = NativeMovConstReg::from(return_address - NativeCall::instruction_size); +????address next_instr = nm->next_instruction_address(); +????if (NativeRegCall::is_at(next_instr) && +????????????NativeRegCall::from(next_instr)->destination() == nm->destination()) { +??????call_addr = return_address - NativeCall::instruction_size; +????} +??} +??if (!call_addr) { +????if (NativeImmCall::is_at(return_address - NativeBranchType::instruction_size)) { +??????call_addr = return_address - NativeBranchType::instruction_size; +????} else { +??????ShouldNotReachHere(); +????} +??} + +??return NativeCall::from(call_addr); +} + ?#endif // CPU_AARCH32_VM_NATIVEINST_AARCH32_HPP ***** patch end ****** On Sat, 2016-09-10 at 07:14 +0000, yangyongyong wrote: > Thank you, Anton, > > My patch *improves* the check logic a little but it does not handle the > situation you mentioned. > How is it reproduced? Do you have a patch at hand already? > > Your suggestion seems more rational. The check logic should better not mix up > the situations of offset -4 and -12. > > Meanwhile, please note that NativeCall::is_at() is invoked somewhere else, so > perhaps some minor modification of nativeCall_before() is not enough. > > -----Original Message----- > From: Anton Kozlov [mailto:akozlov at azul.com]? > Sent: Friday, September 09, 2016 8:35 PM > To: yangyongyong; aarch32-port-dev at openjdk.java.net > Subject: Re: RFR: tune native call site check > > Hi! > > Thanks for finding this! You're right, this is a bug. > > However, if NativeCall::is_at will be fixed like suggested, then the long > instruction sequence will be checked before short one. And now consider > situation, when this call is the last instruction of last method in CodeCache, > unluckily placed at end of page. "Long" check will try to read next page of > CodeCache (forbidden for r/w/x) and will trigger segfault, which is not > expected and not handled by JVM. Actually, we've seen that =) > > There is a suggestion to fix only nativeCall_before, by explicitly checking > NativeImmCall, NativeTrampolineCall, NativeRegCall there with appropriate > offsets. Actually, it looks more correct instead of trying to find any of > these > 3 Native* at offset 4 and then at offset 12. > > Thanks, > Anton > > On Fri, 2016-09-09 at 10:57 +0000, yangyongyong wrote: > > > > Roughly there are 3 kinds of native call site checked by > > nativeCall_before(): > > > > 1.???????Native-Trampoline-Call takes the form of: > > > > add?????lr, pc, #4 > > ldr?????pc, [pc, -4] > > 0x????????????# call_destination > > #return_address: > > ? Some_insn > > > > > > 2.???????Native-Imm-Call > > > > bl imm??# call_destination > > #return_address: > > ? Some_insn > > > > > > 3.???????Native-Reg-Call > > > > > > ???movw regx, #call_destination > > > > ???movt regx, #call_destination > > bl regx????# call destination > > #return_address: > > ? Some_insn > > > > Current check logic incurs a problem if the encoding of the call? > > destination of type 1 can by any chance be disassembled as a ?bl imm? > > instruction. > > And thus the call address is calculated improperly and then the? > > relocation info will not be found, which causes assert failure in > > CompiledIC::CompiledIC(nmethod* nm, NativeCall* call): > > assert(ret == true, "relocInfo must exist at this address"); > > > > This failure can be reproduced simply by ?java -Xcomp? > > -XX:ReservedCodeCacheSize=xx?. Please tune xx and make sure some of? > > the JITed code is placed at address 0x?B??????. > > The attached patch improves the check logic: > > ----------------- patch begins ---------------- diff -r 80b7b526cffb? > > src/cpu/aarch32/vm/nativeInst_aarch32.cpp > > --- a/src/cpu/aarch32/vm/nativeInst_aarch32.cpp?????????Sun Sep 04? > > 20:52:43 > > 2016 +0100 > > +++ b/src/cpu/aarch32/vm/nativeInst_aarch32.cpp??????Fri Sep 09? > > +++ 17:38:34 2016 > > +0800 > > @@ -132,14 +132,14 @@ > > } > > ?bool NativeCall::is_at(address addr) { > > -??if (NativeImmCall::is_at(addr)) { > > +??if (NativeTrampolineCall::is_at(addr)) { > > ?????return true; > > ???} else if (NativeMovConstReg::is_at(addr)) { > > ?????NativeMovConstReg *nm = NativeMovConstReg::from(addr); > > ?????address next_instr = nm->next_instruction_address(); > > ?????return NativeRegCall::is_at(next_instr) && > > ???????NativeRegCall::from(next_instr)->destination() ==? > > nm->destination(); > > -??} else if (NativeTrampolineCall::is_at(addr)) { > > +??} else if (NativeImmCall::is_at(addr)) { > > ?????return true; > > ???} > > ???return false; > > diff -r 80b7b526cffb src/cpu/aarch32/vm/nativeInst_aarch32.hpp > > --- a/src/cpu/aarch32/vm/nativeInst_aarch32.hpp?????????Sun Sep 04? > > 20:52:43 > > 2016 +0100 > > +++ b/src/cpu/aarch32/vm/nativeInst_aarch32.hpp??????Fri Sep 09? > > +++ 17:38:34 2016 > > +0800 > > @@ -306,10 +306,10 @@ > > ?inline NativeCall* nativeCall_before(address return_address) { > > ???address call_addr = NULL; > > -??if (NativeCall::is_at(return_address -? > > NativeBranchType::instruction_size)) > > { > > +??if (NativeCall::is_at(return_address -? > > +NativeCall::instruction_size)) { > > +????call_addr = return_address - NativeCall::instruction_size; > > +??} else if (NativeCall::is_at(return_address - > > NativeBranchType::instruction_size)) { > > ?????call_addr = return_address - NativeBranchType::instruction_size; > > -??} else if (NativeCall::is_at(return_address - > > NativeCall::instruction_size)) { > > -????call_addr = return_address - NativeCall::instruction_size; > > ???} else { > > ?????ShouldNotReachHere(); > > ???} > > ----------------- patch ends ---------------- > > -------------- next part -------------- A non-text attachment was scrubbed... Name: nativeInstr_before.patch Type: text/x-patch Size: 2197 bytes Desc: nativeInstr_before.patch URL: From yangyongyong at huawei.com Mon Sep 12 13:37:48 2016 From: yangyongyong at huawei.com (yangyongyong) Date: Mon, 12 Sep 2016 13:37:48 +0000 Subject: RFR: tune native call site check In-Reply-To: <1473683653.19778.74.camel@azul.com> References: <1473424512.19778.42.camel@azul.com> <1473683653.19778.74.camel@azul.com> Message-ID: Yes, please. Yang is my surname and of course you can call me that. I think NativeCall* nativeCall_before() is ok now. However it seems that NativeCall::is_call_before() would incur a similar crash as you mentioned in an earlier email. Regards. -----Original Message----- From: Anton Kozlov [mailto:akozlov at azul.com] Sent: Monday, September 12, 2016 8:34 PM To: yangyongyong; aarch32-port-dev at openjdk.java.net Subject: Re: RFR: tune native call site check Hi, Yang (sorry, is it correct?), I can't remember well, it reproduced on some jtreg test. But it also should be reproduced in release mode by specifying small values for?InitialCodeCacheSize and?CodeCacheExpansionSize JVM options, like 4K. We've prepared another patch after your email with suggestions implemented (Andrey Petushkov), in attach and below. I think that nativeCall_before should be enough. The problem is that nativeCall_before is not sure where instruction sequence is started, but it calls NativeCall::is_at() anyway. NativeCall::is_at is supposed to be called on start of instruction sequence; with this precondition, I see no possibilities for is_at to misdecode target address. Please, correct me if I'm wrong. Thanks, Anton ***** patch begin ****** diff --git a/src/cpu/aarch32/vm/nativeInst_aarch32.hpp b/src/cpu/aarch32/vm/nativeInst_aarch32.hpp --- a/src/cpu/aarch32/vm/nativeInst_aarch32.hpp +++ b/src/cpu/aarch32/vm/nativeInst_aarch32.hpp @@ -303,20 +303,6 @@ ???return NativeCall::from(address); ?} ? -inline NativeCall* nativeCall_before(address return_address) { -??address call_addr = NULL; -??if (NativeCall::is_at(return_address - NativeBranchType::instruction_size)) { -????call_addr = return_address - NativeBranchType::instruction_size; -??} else if (NativeCall::is_at(return_address - NativeCall::instruction_size)) { -????call_addr = return_address - NativeCall::instruction_size; -??} else { -????ShouldNotReachHere(); -??} - -??return NativeCall::from(call_addr); -} - - ?// An interface for accessing/manipulating native moves of the form: ?//??????mov[b/w/l/q] [reg + offset], reg???(instruction_code_reg2mem) ?//??????mov[b/w/l/q] reg, [reg+offset]?????(instruction_code_mem2reg @@ -505,4 +491,27 @@ ?inline bool NativeInstruction::is_imm_jump() const??????{ return NativeImmJump::is_at(addr()); } ?inline bool NativeInstruction::is_reg_jump() const??????{ return NativeRegJump::is_at(addr()); } ? +inline NativeCall* nativeCall_before(address return_address) { +??address call_addr = NULL; +??if (NativeTrampolineCall::is_at(return_address - +NativeCall::instruction_size)) { +????call_addr = return_address - NativeCall::instruction_size; +??} else if (NativeMovConstReg::is_at(return_address - +NativeCall::instruction_size)) { +????NativeMovConstReg *nm = NativeMovConstReg::from(return_address - +NativeCall::instruction_size); +????address next_instr = nm->next_instruction_address(); +????if (NativeRegCall::is_at(next_instr) && +????????????NativeRegCall::from(next_instr)->destination() == +nm->destination()) { +??????call_addr = return_address - NativeCall::instruction_size; +????} +??} +??if (!call_addr) { +????if (NativeImmCall::is_at(return_address - +NativeBranchType::instruction_size)) { +??????call_addr = return_address - NativeBranchType::instruction_size; +????} else { +??????ShouldNotReachHere(); +????} +??} + +??return NativeCall::from(call_addr); +} + ?#endif // CPU_AARCH32_VM_NATIVEINST_AARCH32_HPP ***** patch end ****** On Sat, 2016-09-10 at 07:14 +0000, yangyongyong wrote: > Thank you, Anton, > > My patch *improves* the check logic a little but it does not handle > the situation you mentioned. > How is it reproduced? Do you have a patch at hand already? > > Your suggestion seems more rational. The check logic should better not > mix up the situations of offset -4 and -12. > > Meanwhile, please note that NativeCall::is_at() is invoked somewhere > else, so perhaps some minor modification of nativeCall_before() is not enough. > > -----Original Message----- > From: Anton Kozlov [mailto:akozlov at azul.com] > Sent: Friday, September 09, 2016 8:35 PM > To: yangyongyong; aarch32-port-dev at openjdk.java.net > Subject: Re: RFR: tune native call site check > > Hi! > > Thanks for finding this! You're right, this is a bug. > > However, if NativeCall::is_at will be fixed like suggested, then the > long instruction sequence will be checked before short one. And now > consider situation, when this call is the last instruction of last > method in CodeCache, unluckily placed at end of page. "Long" check > will try to read next page of CodeCache (forbidden for r/w/x) and will > trigger segfault, which is not expected and not handled by JVM. > Actually, we've seen that =) > > There is a suggestion to fix only nativeCall_before, by explicitly > checking NativeImmCall, NativeTrampolineCall, NativeRegCall there with > appropriate offsets. Actually, it looks more correct instead of trying > to find any of these > 3 Native* at offset 4 and then at offset 12. > > Thanks, > Anton > > On Fri, 2016-09-09 at 10:57 +0000, yangyongyong wrote: > > > > Roughly there are 3 kinds of native call site checked by > > nativeCall_before(): > > > > 1.???????Native-Trampoline-Call takes the form of: > > > > add?????lr, pc, #4 > > ldr?????pc, [pc, -4] > > 0x????????????# call_destination > > #return_address: > > ? Some_insn > > > > > > 2.???????Native-Imm-Call > > > > bl imm??# call_destination > > #return_address: > > ? Some_insn > > > > > > 3.???????Native-Reg-Call > > > > > > ???movw regx, #call_destination > > > > ???movt regx, #call_destination > > bl regx????# call destination > > #return_address: > > ? Some_insn > > > > Current check logic incurs a problem if the encoding of the call > > destination of type 1 can by any chance be disassembled as a ?bl imm? > > instruction. > > And thus the call address is calculated improperly and then the > > relocation info will not be found, which causes assert failure in > > CompiledIC::CompiledIC(nmethod* nm, NativeCall* call): > > assert(ret == true, "relocInfo must exist at this address"); > > > > This failure can be reproduced simply by ?java -Xcomp > > -XX:ReservedCodeCacheSize=xx?. Please tune xx and make sure some of > > the JITed code is placed at address 0x?B??????. > > The attached patch improves the check logic: > > ----------------- patch begins ---------------- diff -r 80b7b526cffb > > src/cpu/aarch32/vm/nativeInst_aarch32.cpp > > --- a/src/cpu/aarch32/vm/nativeInst_aarch32.cpp?????????Sun Sep 04 > > 20:52:43 > > 2016 +0100 > > +++ b/src/cpu/aarch32/vm/nativeInst_aarch32.cpp??????Fri Sep 09 > > +++ 17:38:34 2016 > > +0800 > > @@ -132,14 +132,14 @@ > > } > > ?bool NativeCall::is_at(address addr) { > > -??if (NativeImmCall::is_at(addr)) { > > +??if (NativeTrampolineCall::is_at(addr)) { > > ?????return true; > > ???} else if (NativeMovConstReg::is_at(addr)) { > > ?????NativeMovConstReg *nm = NativeMovConstReg::from(addr); > > ?????address next_instr = nm->next_instruction_address(); > > ?????return NativeRegCall::is_at(next_instr) && > > ???????NativeRegCall::from(next_instr)->destination() == > > nm->destination(); > > -??} else if (NativeTrampolineCall::is_at(addr)) { > > +??} else if (NativeImmCall::is_at(addr)) { > > ?????return true; > > ???} > > ???return false; > > diff -r 80b7b526cffb src/cpu/aarch32/vm/nativeInst_aarch32.hpp > > --- a/src/cpu/aarch32/vm/nativeInst_aarch32.hpp?????????Sun Sep 04 > > 20:52:43 > > 2016 +0100 > > +++ b/src/cpu/aarch32/vm/nativeInst_aarch32.hpp??????Fri Sep 09 > > +++ 17:38:34 2016 > > +0800 > > @@ -306,10 +306,10 @@ > > ?inline NativeCall* nativeCall_before(address return_address) { > > ???address call_addr = NULL; > > -??if (NativeCall::is_at(return_address - > > NativeBranchType::instruction_size)) > > { > > +??if (NativeCall::is_at(return_address - > > +NativeCall::instruction_size)) { > > +????call_addr = return_address - NativeCall::instruction_size; > > +??} else if (NativeCall::is_at(return_address - > > NativeBranchType::instruction_size)) { > > ?????call_addr = return_address - > > NativeBranchType::instruction_size; > > -??} else if (NativeCall::is_at(return_address - > > NativeCall::instruction_size)) { > > -????call_addr = return_address - NativeCall::instruction_size; > > ???} else { > > ?????ShouldNotReachHere(); > > ???} > > ----------------- patch ends ---------------- > > From akozlov at azul.com Mon Sep 12 15:49:37 2016 From: akozlov at azul.com (Anton Kozlov) Date: Mon, 12 Sep 2016 15:49:37 +0000 Subject: RFR: tune native call site check In-Reply-To: References: <1473424512.19778.42.camel@azul.com> <1473683653.19778.74.camel@azul.com> Message-ID: <1473695400.19778.83.camel@azul.com> Oh, I see. Agree, is_call_before is incorrect same way as nativeCall_before prior 1st patch; and if no single instruction will be found on offset (-4), it will try to find 3-instruction sequence there, possibly going beyound CodeCache boundary. Thanks! I suggest second version of patch. Yang, could you check it still works for you? Anton ***** patch start ***** diff --git a/src/cpu/aarch32/vm/nativeInst_aarch32.cpp b/src/cpu/aarch32/vm/nativeInst_aarch32.cpp --- a/src/cpu/aarch32/vm/nativeInst_aarch32.cpp +++ b/src/cpu/aarch32/vm/nativeInst_aarch32.cpp @@ -104,8 +104,16 @@ ?} ? ?bool NativeCall::is_call_before(address return_address) { -??return is_at(return_address - NativeImmCall::instruction_size) || -????is_at(return_address - NativeCall::instruction_size); +??if (NativeTrampolineCall::is_at(return_address - NativeCall::instruction_size)) { +????return true; +??} else if (NativeMovConstReg::is_at(return_address - NativeCall::instruction_size)) { +????NativeMovConstReg *nm = NativeMovConstReg::from(return_address - NativeCall::instruction_size); +????address next_instr = nm->next_instruction_address(); +????return NativeRegCall::is_at(next_instr) && NativeRegCall::from(next_instr)->destination() == nm->destination(); +??} else if (NativeImmCall::is_at(return_address - NativeBranchType::instruction_size)) { +????return true; +??} +??return false; ?} ? ?address NativeCall::next_instruction_address() const { diff --git a/src/cpu/aarch32/vm/nativeInst_aarch32.hpp b/src/cpu/aarch32/vm/nativeInst_aarch32.hpp --- a/src/cpu/aarch32/vm/nativeInst_aarch32.hpp +++ b/src/cpu/aarch32/vm/nativeInst_aarch32.hpp @@ -303,20 +303,6 @@ ???return NativeCall::from(address); ?} ? -inline NativeCall* nativeCall_before(address return_address) { -??address call_addr = NULL; -??if (NativeCall::is_at(return_address - NativeBranchType::instruction_size)) { -????call_addr = return_address - NativeBranchType::instruction_size; -??} else if (NativeCall::is_at(return_address - NativeCall::instruction_size)) { -????call_addr = return_address - NativeCall::instruction_size; -??} else { -????ShouldNotReachHere(); -??} - -??return NativeCall::from(call_addr); -} - - ?// An interface for accessing/manipulating native moves of the form: ?//??????mov[b/w/l/q] [reg + offset], reg???(instruction_code_reg2mem) ?//??????mov[b/w/l/q] reg, [reg+offset]?????(instruction_code_mem2reg @@ -505,4 +491,27 @@ ?inline bool NativeInstruction::is_imm_jump() const??????{ return NativeImmJump::is_at(addr()); } ?inline bool NativeInstruction::is_reg_jump() const??????{ return NativeRegJump::is_at(addr()); } ? +inline NativeCall* nativeCall_before(address return_address) { +??address call_addr = NULL; +??if (NativeTrampolineCall::is_at(return_address - NativeCall::instruction_size)) { +????call_addr = return_address - NativeCall::instruction_size; +??} else if (NativeMovConstReg::is_at(return_address - NativeCall::instruction_size)) { +????NativeMovConstReg *nm = NativeMovConstReg::from(return_address - NativeCall::instruction_size); +????address next_instr = nm->next_instruction_address(); +????if (NativeRegCall::is_at(next_instr) && +????????????NativeRegCall::from(next_instr)->destination() == nm->destination()) { +??????call_addr = return_address - NativeCall::instruction_size; +????} +??} +??if (!call_addr) { +????if (NativeImmCall::is_at(return_address - NativeBranchType::instruction_size)) { +??????call_addr = return_address - NativeBranchType::instruction_size; +????} else { +??????ShouldNotReachHere(); +????} +??} + +??return NativeCall::from(call_addr); +} + ?#endif // CPU_AARCH32_VM_NATIVEINST_AARCH32_HPP ***** patch end ****** On Mon, 2016-09-12 at 13:37 +0000, yangyongyong wrote: > Yes, please. Yang is my surname and of course you can call me that. > > I think NativeCall* nativeCall_before() is ok now. > However it seems that NativeCall::is_call_before() would incur a similar crash > as you mentioned in an earlier email. > > Regards. > > -----Original Message----- > From: Anton Kozlov [mailto:akozlov at azul.com]? > Sent: Monday, September 12, 2016 8:34 PM > To: yangyongyong; aarch32-port-dev at openjdk.java.net > Subject: Re: RFR: tune native call site check > > Hi, Yang (sorry, is it correct?), > > I can't remember well, it reproduced on some jtreg test. But it also should be > reproduced in release mode by specifying small values for?InitialCodeCacheSize > and?CodeCacheExpansionSize JVM options, like 4K. > > We've prepared another patch after your email with suggestions implemented > (Andrey Petushkov), in attach and below. > > I think that nativeCall_before should be enough. The problem is that > nativeCall_before is not sure where instruction sequence is started, but it > calls NativeCall::is_at() anyway. NativeCall::is_at is supposed to be called > on start of instruction sequence; with this precondition, I see no > possibilities for is_at to misdecode target address. Please, correct me if I'm > wrong. > > Thanks, > Anton > > ***** patch begin ****** > diff --git a/src/cpu/aarch32/vm/nativeInst_aarch32.hpp > b/src/cpu/aarch32/vm/nativeInst_aarch32.hpp > --- a/src/cpu/aarch32/vm/nativeInst_aarch32.hpp > +++ b/src/cpu/aarch32/vm/nativeInst_aarch32.hpp > @@ -303,20 +303,6 @@ > ???return NativeCall::from(address); > ?} > ? > -inline NativeCall* nativeCall_before(address return_address) { > -??address call_addr = NULL; > -??if (NativeCall::is_at(return_address - NativeBranchType::instruction_size)) > { > -????call_addr = return_address - NativeBranchType::instruction_size; > -??} else if (NativeCall::is_at(return_address - > NativeCall::instruction_size)) { > -????call_addr = return_address - NativeCall::instruction_size; > -??} else { > -????ShouldNotReachHere(); > -??} > - > -??return NativeCall::from(call_addr); > -} > - > - > ?// An interface for accessing/manipulating native moves of the form: > ?//??????mov[b/w/l/q] [reg + offset], reg???(instruction_code_reg2mem) > ?//??????mov[b/w/l/q] reg, [reg+offset]?????(instruction_code_mem2reg @@ > -505,4 +491,27 @@ > ?inline bool NativeInstruction::is_imm_jump() const??????{ return > NativeImmJump::is_at(addr()); } > ?inline bool NativeInstruction::is_reg_jump() const??????{ return > NativeRegJump::is_at(addr()); } > ? > +inline NativeCall* nativeCall_before(address return_address) { > +??address call_addr = NULL; > +??if (NativeTrampolineCall::is_at(return_address -? > +NativeCall::instruction_size)) { > +????call_addr = return_address - NativeCall::instruction_size; > +??} else if (NativeMovConstReg::is_at(return_address -? > +NativeCall::instruction_size)) { > +????NativeMovConstReg *nm = NativeMovConstReg::from(return_address -? > +NativeCall::instruction_size); > +????address next_instr = nm->next_instruction_address(); > +????if (NativeRegCall::is_at(next_instr) && > +????????????NativeRegCall::from(next_instr)->destination() ==? > +nm->destination()) { > +??????call_addr = return_address - NativeCall::instruction_size; > +????} > +??} > +??if (!call_addr) { > +????if (NativeImmCall::is_at(return_address -? > +NativeBranchType::instruction_size)) { > +??????call_addr = return_address - NativeBranchType::instruction_size; > +????} else { > +??????ShouldNotReachHere(); > +????} > +??} > + > +??return NativeCall::from(call_addr); > +} > + > ?#endif // CPU_AARCH32_VM_NATIVEINST_AARCH32_HPP > > ***** patch end ****** > > On Sat, 2016-09-10 at 07:14 +0000, yangyongyong wrote: > > > > Thank you, Anton, > > > > My patch *improves* the check logic a little but it does not handle? > > the situation you mentioned. > > How is it reproduced? Do you have a patch at hand already? > > > > Your suggestion seems more rational. The check logic should better not? > > mix up the situations of offset -4 and -12. > > > > Meanwhile, please note that NativeCall::is_at() is invoked somewhere? > > else, so perhaps some minor modification of nativeCall_before() is not > > enough. > > > > -----Original Message----- > > From: Anton Kozlov [mailto:akozlov at azul.com] > > Sent: Friday, September 09, 2016 8:35 PM > > To: yangyongyong; aarch32-port-dev at openjdk.java.net > > Subject: Re: RFR: tune native call site check > > > > Hi! > > > > Thanks for finding this! You're right, this is a bug. > > > > However, if NativeCall::is_at will be fixed like suggested, then the? > > long instruction sequence will be checked before short one. And now? > > consider situation, when this call is the last instruction of last? > > method in CodeCache, unluckily placed at end of page. "Long" check? > > will try to read next page of CodeCache (forbidden for r/w/x) and will? > > trigger segfault, which is not expected and not handled by JVM.? > > Actually, we've seen that =) > > > > There is a suggestion to fix only nativeCall_before, by explicitly? > > checking NativeImmCall, NativeTrampolineCall, NativeRegCall there with? > > appropriate offsets. Actually, it looks more correct instead of trying? > > to find any of these > > 3 Native* at offset 4 and then at offset 12. > > > > Thanks, > > Anton > > > > On Fri, 2016-09-09 at 10:57 +0000, yangyongyong wrote: > > > > > > > > > Roughly there are 3 kinds of native call site checked by > > > nativeCall_before(): > > > > > > 1.???????Native-Trampoline-Call takes the form of: > > > > > > add?????lr, pc, #4 > > > ldr?????pc, [pc, -4] > > > 0x????????????# call_destination > > > #return_address: > > > ? Some_insn > > > > > > > > > 2.???????Native-Imm-Call > > > > > > bl imm??# call_destination > > > #return_address: > > > ? Some_insn > > > > > > > > > 3.???????Native-Reg-Call > > > > > > > > > ???movw regx, #call_destination > > > > > > ???movt regx, #call_destination > > > bl regx????# call destination > > > #return_address: > > > ? Some_insn > > > > > > Current check logic incurs a problem if the encoding of the call? > > > destination of type 1 can by any chance be disassembled as a ?bl imm? > > > instruction. > > > And thus the call address is calculated improperly and then the? > > > relocation info will not be found, which causes assert failure in > > > CompiledIC::CompiledIC(nmethod* nm, NativeCall* call): > > > assert(ret == true, "relocInfo must exist at this address"); > > > > > > This failure can be reproduced simply by ?java -Xcomp? > > > -XX:ReservedCodeCacheSize=xx?. Please tune xx and make sure some of? > > > the JITed code is placed at address 0x?B??????. > > > The attached patch improves the check logic: > > > ----------------- patch begins ---------------- diff -r 80b7b526cffb? > > > src/cpu/aarch32/vm/nativeInst_aarch32.cpp > > > --- a/src/cpu/aarch32/vm/nativeInst_aarch32.cpp?????????Sun Sep 04 > > > 20:52:43 > > > 2016 +0100 > > > +++ b/src/cpu/aarch32/vm/nativeInst_aarch32.cpp??????Fri Sep 09 > > > +++ 17:38:34 2016 > > > +0800 > > > @@ -132,14 +132,14 @@ > > > } > > > ?bool NativeCall::is_at(address addr) { > > > -??if (NativeImmCall::is_at(addr)) { > > > +??if (NativeTrampolineCall::is_at(addr)) { > > > ?????return true; > > > ???} else if (NativeMovConstReg::is_at(addr)) { > > > ?????NativeMovConstReg *nm = NativeMovConstReg::from(addr); > > > ?????address next_instr = nm->next_instruction_address(); > > > ?????return NativeRegCall::is_at(next_instr) && > > > ???????NativeRegCall::from(next_instr)->destination() == > > > nm->destination(); > > > -??} else if (NativeTrampolineCall::is_at(addr)) { > > > +??} else if (NativeImmCall::is_at(addr)) { > > > ?????return true; > > > ???} > > > ???return false; > > > diff -r 80b7b526cffb src/cpu/aarch32/vm/nativeInst_aarch32.hpp > > > --- a/src/cpu/aarch32/vm/nativeInst_aarch32.hpp?????????Sun Sep 04 > > > 20:52:43 > > > 2016 +0100 > > > +++ b/src/cpu/aarch32/vm/nativeInst_aarch32.hpp??????Fri Sep 09 > > > +++ 17:38:34 2016 > > > +0800 > > > @@ -306,10 +306,10 @@ > > > ?inline NativeCall* nativeCall_before(address return_address) { > > > ???address call_addr = NULL; > > > -??if (NativeCall::is_at(return_address - > > > NativeBranchType::instruction_size)) > > > { > > > +??if (NativeCall::is_at(return_address - > > > +NativeCall::instruction_size)) { > > > +????call_addr = return_address - NativeCall::instruction_size; > > > +??} else if (NativeCall::is_at(return_address - > > > NativeBranchType::instruction_size)) { > > > ?????call_addr = return_address -? > > > NativeBranchType::instruction_size; > > > -??} else if (NativeCall::is_at(return_address - > > > NativeCall::instruction_size)) { > > > -????call_addr = return_address - NativeCall::instruction_size; > > > ???} else { > > > ?????ShouldNotReachHere(); > > > ???} > > > ----------------- patch ends ---------------- > > > -------------- next part -------------- A non-text attachment was scrubbed... Name: nativeInstr_before2.patch Type: text/x-patch Size: 3264 bytes Desc: nativeInstr_before2.patch URL: From bob.vandette at oracle.com Wed Sep 14 14:32:56 2016 From: bob.vandette at oracle.com (Bob Vandette) Date: Wed, 14 Sep 2016 10:32:56 -0400 Subject: Open sourcing ARM ports status In-Reply-To: References: <9691CB41-A445-4E50-934A-FACBEFBC56CA@oracle.com> <95104355-a46f-48ad-9a99-de4be74832a1@redhat.com> <7CD42CEA-3FFA-4C1E-A2D8-F17D76849EF1@oracle.com> <2f4a15e9-1342-e4c8-51e8-92caed195a48@redhat.com> <3B0DEB48-8121-42A6-99C4-260589BFBFE2@oracle.com> <0de9e6ba-0dd7-7f00-0e2a-2a52803f8088@redhat.com> <3b1753de-5616-8450-8d70-abddd476f5cb@redhat.com> Message-ID: <6B7A4616-7D35-4D9A-83FA-4743833D3B27@oracle.com> Here?s the status of the open sourcing of the Oracle 32/64 ARM Ports. I?ve completed the moved of all of the necessary sources and Makefile logic and can now build both arm and aarch64 binaries from our sources. I?m close to completing our internal reviews. The reviews are only to ensure that I?m not exposing anything that?s commercial value and that I?ve got the correct copyrights. Ed, could you setup a temporary repository under the aarch32 project where I could push the forest once I?ve completed our internal reviews? Bob. From edward.nevill at gmail.com Wed Sep 14 15:57:07 2016 From: edward.nevill at gmail.com (Edward Nevill) Date: Wed, 14 Sep 2016 16:57:07 +0100 Subject: Open sourcing ARM ports status In-Reply-To: <6B7A4616-7D35-4D9A-83FA-4743833D3B27@oracle.com> References: <9691CB41-A445-4E50-934A-FACBEFBC56CA@oracle.com> <95104355-a46f-48ad-9a99-de4be74832a1@redhat.com> <7CD42CEA-3FFA-4C1E-A2D8-F17D76849EF1@oracle.com> <2f4a15e9-1342-e4c8-51e8-92caed195a48@redhat.com> <3B0DEB48-8121-42A6-99C4-260589BFBFE2@oracle.com> <0de9e6ba-0dd7-7f00-0e2a-2a52803f8088@redhat.com> <3b1753de-5616-8450-8d70-abddd476f5cb@redhat.com> <6B7A4616-7D35-4D9A-83FA-4743833D3B27@oracle.com> Message-ID: <1473868627.5135.16.camel@gmail.com> On Wed, 2016-09-14 at 10:32 -0400, Bob Vandette wrote: > Here?s the status of the open sourcing of the Oracle 32/64 ARM Ports. > > I?ve completed the moved of all of the necessary sources and Makefile logic and can now > build both arm and aarch64 binaries from our sources.?? > > I?m close to completing our internal reviews.??The reviews are only to ensure that I?m not > exposing anything that?s commercial value and that I?ve got the correct copyrights.?? > Ed, could you setup a temporary repository under the aarch32 project where I could push > the forest once I?ve completed our internal reviews??? Hi Bob, I'm not sure this is something I can do. I think it needs to be done by ops (on cc). Generally the way it has worked for creating the existing jdk8u and jdk9 repos is that ops have prepopulated the repo with some revision of jdk8u/jdk9 from the main dev, and then we have just pushed diffs to make that into what we want. What revision of jdk8u is your port based on? ops could prepopulate the repo with than revision then you could just push your diffs. Alternatively, I'm sure if you were to point ops at a mercurial repo somewhere they could populate it with that. Ops: could you advise. Thanks, Ed. From bob.vandette at oracle.com Wed Sep 14 16:38:04 2016 From: bob.vandette at oracle.com (Bob Vandette) Date: Wed, 14 Sep 2016 12:38:04 -0400 Subject: Open sourcing ARM ports status In-Reply-To: <1473868627.5135.16.camel@gmail.com> References: <9691CB41-A445-4E50-934A-FACBEFBC56CA@oracle.com> <95104355-a46f-48ad-9a99-de4be74832a1@redhat.com> <7CD42CEA-3FFA-4C1E-A2D8-F17D76849EF1@oracle.com> <2f4a15e9-1342-e4c8-51e8-92caed195a48@redhat.com> <3B0DEB48-8121-42A6-99C4-260589BFBFE2@oracle.com> <0de9e6ba-0dd7-7f00-0e2a-2a52803f8088@redhat.com> <3b1753de-5616-8450-8d70-abddd476f5cb@redhat.com> <6B7A4616-7D35-4D9A-83FA-4743833D3B27@oracle.com> <1473868627.5135.16.camel@gmail.com> Message-ID: <12568816-4ED1-4BE4-8B25-68E0A9C16A07@oracle.com> > On Sep 14, 2016, at 11:57 AM, Edward Nevill wrote: > > On Wed, 2016-09-14 at 10:32 -0400, Bob Vandette wrote: >> Here?s the status of the open sourcing of the Oracle 32/64 ARM Ports. >> >> I?ve completed the moved of all of the necessary sources and Makefile logic and can now >> build both arm and aarch64 binaries from our sources. >> >> I?m close to completing our internal reviews. The reviews are only to ensure that I?m not >> exposing anything that?s commercial value and that I?ve got the correct copyrights. >> Ed, could you setup a temporary repository under the aarch32 project where I could push >> the forest once I?ve completed our internal reviews? > > Hi Bob, > > I'm not sure this is something I can do. I think it needs to be done by ops (on cc). I realize that you can?t do this yourself, but as the lead, you need to request this. > > Generally the way it has worked for creating the existing jdk8u and jdk9 repos is that ops have prepopulated the repo with some revision of jdk8u/jdk9 from the main dev, and then we have just pushed diffs to make that into what we want. > > What revision of jdk8u is your port based on? ops could prepopulate the repo with than revision then you could just push your diffs. My patch is based on jdk-9+132 and jdk9/dev is working on 136. I can sync up with whatever revision is created prior to pushing anything. > > Alternatively, I'm sure if you were to point ops at a mercurial repo somewhere they could populate it with that. We could do that but I?m still going through the approval process for opening up these sources. I assumed it would take a bit to get the forest setup. This is why I suggested that we start the process now. Bob. > > Ops: could you advise. > > Thanks, > Ed. > From aph at redhat.com Thu Sep 15 07:30:22 2016 From: aph at redhat.com (Andrew Haley) Date: Thu, 15 Sep 2016 08:30:22 +0100 Subject: Open sourcing ARM ports status In-Reply-To: <6B7A4616-7D35-4D9A-83FA-4743833D3B27@oracle.com> References: <9691CB41-A445-4E50-934A-FACBEFBC56CA@oracle.com> <95104355-a46f-48ad-9a99-de4be74832a1@redhat.com> <7CD42CEA-3FFA-4C1E-A2D8-F17D76849EF1@oracle.com> <2f4a15e9-1342-e4c8-51e8-92caed195a48@redhat.com> <3B0DEB48-8121-42A6-99C4-260589BFBFE2@oracle.com> <0de9e6ba-0dd7-7f00-0e2a-2a52803f8088@redhat.com> <3b1753de-5616-8450-8d70-abddd476f5cb@redhat.com> <6B7A4616-7D35-4D9A-83FA-4743833D3B27@oracle.com> Message-ID: On 14/09/16 15:32, Bob Vandette wrote: > I?ve completed the moved of all of the necessary sources and Makefile logic and can now > build both arm and aarch64 binaries from our sources. > > I?m close to completing our internal reviews. The reviews are only to ensure that I?m not > exposing anything that?s commercial value and that I?ve got the correct copyrights. Hi, >From the AArch64 side, we'll compare and contrast the two ports and come up with an opinion. This will of course take some time, so if you don't see a response quickly it's not because we are ignoring you. Thanks, Andrew. From edward.nevill at gmail.com Thu Sep 15 14:29:07 2016 From: edward.nevill at gmail.com (Edward Nevill) Date: Thu, 15 Sep 2016 15:29:07 +0100 Subject: CFV: New Port: AArch32 Committer Bob Vandette Message-ID: <1473949747.3576.19.camel@gmail.com> I hereby nominate Bob Vandette to Port: AArch32 Committer. Bob is project lead for the mobile project and is committer/reviewer for a number of other OpenJDK projects [3]. Bob is also leading the effort to open source the Oracle port for ARM 32/64. Votes are due by Thu Sep 29 14:30:00 UTC 2016. Only current Port: AArch32 Committers [1] are eligible to vote on this nomination.??Votes must be cast in the open by replying? to this mailing list. For Lazy Consensus voting instructions, see [2]. Edward Nevill [1] http://openjdk.java.net/census [2] http://openjdk.java.net/projects/#committer-vote [3]?http://openjdk.java.net/census#bobv From adinn at redhat.com Thu Sep 15 15:37:41 2016 From: adinn at redhat.com (Andrew Dinn) Date: Thu, 15 Sep 2016 16:37:41 +0100 Subject: CFV: New Port: AArch32 Committer Bob Vandette In-Reply-To: <1473949747.3576.19.camel@gmail.com> References: <1473949747.3576.19.camel@gmail.com> Message-ID: <321b28fa-1cdd-09c3-5d7e-d01d7337c854@redhat.com> Vote yes On 15/09/16 15:29, Edward Nevill wrote: > I hereby nominate Bob Vandette to Port: AArch32 Committer. > > Bob is project lead for the mobile project and is committer/reviewer for a number of other OpenJDK projects [3]. > > Bob is also leading the effort to open source the Oracle port for ARM 32/64. > > Votes are due by Thu Sep 29 14:30:00 UTC 2016. > > Only current Port: AArch32 Committers [1] are eligible to vote > on this nomination. Votes must be cast in the open by replying > to this mailing list. > > For Lazy Consensus voting instructions, see [2]. > > Edward Nevill > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#committer-vote > [3] http://openjdk.java.net/census#bobv > > -- regards, Andrew Dinn ----------- Senior Principal Software Engineer Red Hat UK Ltd Registered in England and Wales under Company Registration No. 03798903 Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander From bob.vandette at oracle.com Thu Sep 15 18:59:14 2016 From: bob.vandette at oracle.com (Bob Vandette) Date: Thu, 15 Sep 2016 14:59:14 -0400 Subject: JavaOne next week Message-ID: <0B60E08F-7F39-4CCE-BC43-DAF1CB28F684@oracle.com> In case anyone interested in the aarch32 project would like to get together to discuss the potential Oracle ARM port contributions to this project, I?ll be in San Fran next week for JavaOne. You can either flag me down after one of my two talks on Monday or email me and we?ll setup a time. ? Options for Developing Mobile Applications with Java [CON6157] Bob Vandette, Java SE Embedded and Mobile Lead, Oracle Monday, Sep 19, 4:00 p.m. - 5:00 p.m. | Hilton - Golden Gate 6/7/8 ? Creating Smaller Java Runtimes in JDK 9 with jlink [CON6153] Bob Vandette, Java SE Embedded and Mobile Lead, Oracle Monday, Sep 19, 11:00 a.m. - 12:00 p.m. | Hilton - Golden Gate 6/7/8 Hope to see you then, Bob. From aph at redhat.com Sat Sep 17 06:51:13 2016 From: aph at redhat.com (Andrew Haley) Date: Sat, 17 Sep 2016 07:51:13 +0100 Subject: CFV: New Port: AArch32 Committer Bob Vandette In-Reply-To: <321b28fa-1cdd-09c3-5d7e-d01d7337c854@redhat.com> References: <1473949747.3576.19.camel@gmail.com> <321b28fa-1cdd-09c3-5d7e-d01d7337c854@redhat.com> Message-ID: Vote:yes Andrew. From simon at cjnash.com Sun Sep 25 18:58:54 2016 From: simon at cjnash.com (Simon Nash) Date: Sun, 25 Sep 2016 19:58:54 +0100 Subject: Relationship of aarch32-port to jdk8u Message-ID: <57E81E6E.20407@cjnash.com> If I build the current source in aarch32-port, what level of jdk8u am I getting? I presume this is a snapshot from some point in the past but I'm not sure how to find out how long ago the snapshot was taken. Is there (or might there be in the future) a mechanism for aarch32-port to track and merge changes applied to jdk8u? If I wanted to build (for example) an aarch32 C1 version of jdk8u101-b13, would it possible/practical for me to put together the correct combination of source files needed to do this? Many thanks, Simon From edward.nevill at gmail.com Sun Sep 25 20:10:54 2016 From: edward.nevill at gmail.com (Edward Nevill) Date: Sun, 25 Sep 2016 21:10:54 +0100 Subject: Relationship of aarch32-port to jdk8u In-Reply-To: <57E81E6E.20407@cjnash.com> References: <57E81E6E.20407@cjnash.com> Message-ID: <1474834254.2203.23.camel@gmail.com> Hi Simon, On Sun, 2016-09-25 at 19:58 +0100, Simon Nash wrote: > If I build the current source in aarch32-port, what level of jdk8u > am I getting???I presume this is a snapshot from some point in the past > but I'm not sure how to find out how long ago the snapshot was taken. The aarch32 port is merged up to jdk8u102-b14, whereas the jdk8u-dev tip is at jdk8u22-b01. > > Is there (or might there be in the future) a mechanism for aarch32-port > to track and merge changes applied to jdk8u? There is no formal mechanism. Every so often we will merge up to the latest tip although this has not been done for some months. > If I wanted to build (for example) an aarch32 C1 version of jdk8u101-b13, > would it possible/practical for me to put together the correct combination > of source files needed to do this? The C1 changes were only applied to jdk8u102-b14, so what you would need to do is - diff the aarch32 tip against jdk8u102-b14 - apply those diff to jdk8u101-b13 This should be clean as we have kept changes outside the aarch32 specific code to a minimum. All the best, Ed. From simon at cjnash.com Sun Sep 25 20:29:41 2016 From: simon at cjnash.com (Simon Nash) Date: Sun, 25 Sep 2016 21:29:41 +0100 Subject: Relationship of aarch32-port to jdk8u In-Reply-To: <1474834254.2203.23.camel@gmail.com> References: <57E81E6E.20407@cjnash.com> <1474834254.2203.23.camel@gmail.com> Message-ID: <57E833B5.7040500@cjnash.com> Edward Nevill wrote: > Hi Simon, > > On Sun, 2016-09-25 at 19:58 +0100, Simon Nash wrote: >> If I build the current source in aarch32-port, what level of jdk8u >> am I getting? I presume this is a snapshot from some point in the past >> but I'm not sure how to find out how long ago the snapshot was taken. > > The aarch32 port is merged up to jdk8u102-b14, whereas the jdk8u-dev tip is at jdk8u22-b01. > >> Is there (or might there be in the future) a mechanism for aarch32-port >> to track and merge changes applied to jdk8u? > > There is no formal mechanism. Every so often we will merge up to the latest tip although this has not been done for some months. > >> If I wanted to build (for example) an aarch32 C1 version of jdk8u101-b13, >> would it possible/practical for me to put together the correct combination >> of source files needed to do this? > > The C1 changes were only applied to jdk8u102-b14, so what you would need to do is > > - diff the aarch32 tip against jdk8u102-b14 > - apply those diff to jdk8u101-b13 > > This should be clean as we have kept changes outside the aarch32 specific code to a minimum. > > All the best, > Ed. > > Hi Ed, Thanks for the quick and very helpful reply. I had chosen jdk8u101-b13 as an example. As the code is already at a later level than this, I would not want to go backwards. :) Simon From akashche at redhat.com Mon Sep 26 08:53:17 2016 From: akashche at redhat.com (Alex Kashchenko) Date: Mon, 26 Sep 2016 09:53:17 +0100 Subject: Relationship of aarch32-port to jdk8u In-Reply-To: <57E833B5.7040500@cjnash.com> References: <57E81E6E.20407@cjnash.com> <1474834254.2203.23.camel@gmail.com> <57E833B5.7040500@cjnash.com> Message-ID: <57E8E1FD.3030707@redhat.com> Hi Simon, On 09/25/2016 09:29 PM, Simon Nash wrote: > Edward Nevill wrote: >> Hi Simon, >> >> On Sun, 2016-09-25 at 19:58 +0100, Simon Nash wrote: >>> If I build the current source in aarch32-port, what level of jdk8u >>> am I getting? I presume this is a snapshot from some point in the past >>> but I'm not sure how to find out how long ago the snapshot was taken. >> >> The aarch32 port is merged up to jdk8u102-b14, whereas the jdk8u-dev >> tip is at jdk8u22-b01. >> >>> Is there (or might there be in the future) a mechanism for aarch32-port >>> to track and merge changes applied to jdk8u? >> >> There is no formal mechanism. Every so often we will merge up to the >> latest tip although this has not been done for some months. >> >>> If I wanted to build (for example) an aarch32 C1 version of >>> jdk8u101-b13, >>> would it possible/practical for me to put together the correct >>> combination >>> of source files needed to do this? >> >> The C1 changes were only applied to jdk8u102-b14, so what you would >> need to do is >> >> - diff the aarch32 tip against jdk8u102-b14 >> - apply those diff to jdk8u101-b13 >> >> This should be clean as we have kept changes outside the aarch32 >> specific code to a minimum. >> >> All the best, >> Ed. >> >> > Hi Ed, > Thanks for the quick and very helpful reply. I had chosen jdk8u101-b13 > as an > example. As the code is already at a later level than this, I would not > want > to go backwards. :) Just FYI, up to date aarch32-port RPM builds are available in Fedora - https://lists.fedoraproject.org/archives/list/users at lists.fedoraproject.org/thread/5OM4ADQQG5MUD56BYASUCZWZJ4XIZSNH/ -- -Alex From bob.vandette at oracle.com Wed Sep 28 14:07:59 2016 From: bob.vandette at oracle.com (Bob Vandette) Date: Wed, 28 Sep 2016 10:07:59 -0400 Subject: Webrev of Oracle ARM & AARCH64 Sources Message-ID: <5A08C4A6-2B69-4D29-80F5-1CE11E350283@oracle.com> I?m am please to announce that I have completed our internal reviews and can now open up the sources to our ARM 32 & 64 bit implementations of JDK9. Here is a webrev that includes a patch that can be applied on top of the (http://hg.openjdk.java.net/aarch32-port/jdk9-arm3264/ ) forest. http://cr.openjdk.java.net/~bobv/arm3264/webrev Notes: 1. Counter to my initial email announcing the open sourcing effort, the pregenerated interpreter is not included in the provided patch. AOT is our long term solution for increased performance on Mobile and it was decided that we do not want to support the static interpreter beyond JDK 8. 2. In order to allow building the two different 64-bit ARM sources, I overloaded a new configure option ?abi-profile to allow for the selection of the Oracle 64-bit ARM port. We need a better solution before this support can be integrated into the mainline. To use the Oracle sources for an aarch64 build, select ?abi-profile=arm64. 3. The scripts provided below allows for the creation of the minimal, client and server VMs for the Oracle aarch64 build, however, the jvm.cfg file is not automatically updated during the build. To run a non server VM, this file will need to be updated. 4. In order to make it easier to keep the new open sources up to date with their closed counterparts in jdk9, I have added a comment in hotspot/src/cpu/arm/vm/vm_version_ext_arm.hpp which contains the mercurial revision that I last merged with. This will make it easier to produce patches to bring the new open files up to the latest version. /* ARM sources Merged up to hotspot/src/closed changeset 2316:b247a2ea70e4 */ Build Scripts: Here are a set of scripts that demonstrate how to build the three ARM configurations. We typically cross compile our ARM builds so these scripts will have to be adjusted in order to build natively on an ARM system. http://cr.openjdk.java.net/~bobv/arm3264/scripts/ aarch64.csh Builds the current open version of aarch64 binaries arm64.csh Builds the Oracle aarch64 binaries arm.csh Builds 32-bit ARM binaries My next step is to push this changeset into the jdk9-arm3264 forest assuming I achieve committer status for the aarch32 project this week. Bob Vandette From edward.nevill at gmail.com Wed Sep 28 15:34:43 2016 From: edward.nevill at gmail.com (Edward Nevill) Date: Wed, 28 Sep 2016 16:34:43 +0100 Subject: CFV: New Port: AArch32 Committer Bob Vandette In-Reply-To: <1473949747.3576.19.camel@gmail.com> References: <1473949747.3576.19.camel@gmail.com> Message-ID: <1475076883.2221.0.camel@gmail.com> Vote: yes Ed. From bob.vandette at oracle.com Wed Sep 28 18:46:21 2016 From: bob.vandette at oracle.com (Bob Vandette) Date: Wed, 28 Sep 2016 14:46:21 -0400 Subject: Webrev of Oracle ARM & AARCH64 Sources In-Reply-To: References: <5A08C4A6-2B69-4D29-80F5-1CE11E350283@oracle.com> Message-ID: > On Sep 28, 2016, at 1:55 PM, Volker Simonis wrote: > > Hi Bob, > > congratulations! I'm pretty sure this was a pretty huge amount of > paper and programming work to reach this point :) > > My general question is how is this code contribution supposed to work > together with the current ARM ports in the OpenJDK. Currently we have > a full-blown, supported arm64 bit port in the jdk9 main-line > (contributed and maintained by RedHat). The aarch32 project has a > full-blown implementation for arm32 for jdk8u contributed by Azul. I didn?t think the arm32 project had a C2 server VM yet? > > Is your new port intended to live and be maintained alongside these > already available ports? At this point we are simply offering to contribute our ARM implementations to the community and no decisions on consolidation of ports has been decided. > Where does your port differ from the available ports in terms of > functionality and performance? The primary reason for putting the webrev out in the open is to allow for the review of our implementation by the aarch32 project team. ARM32 Our 32-bit ARM port is very mature and has been around for over 8 years. These sources support several 32-bit ARM architecture versions including ARMv5, ARMv6 and ARMv7 with VFP hard-float, soft-fp and full soft-float floating point support. Both 32 and 64 bit ARM ports support the building of the minimal, client and server hotspot VMs. We also support the compilation of native binaries with thumb2. AARCH64 Our AARCH64 bit port is fully functional and supports the same three VM combinations. MAINTAINABILITY As you can see from the sources, we designed the ARM ports to share as much of the sources for 32 and 64 bit ARM support as possible making it easier to maintain and add CPU specific features to hotspot. This design philosophy is consistent with our sparc and x86 ports. PERFORMANCE I have not done a performance comparison of the existing open ports. Note: Some of the Oracle commercial features may not be fully supported on some of the ARM platforms. > Is Oracle committed to support the new ports? Oracle is committed to producing 32 & 64 bit ARM binaries for at least the JDK 9 product life cycle. We will be producing our ARM binaries from our closed sources for JDK 9.0. > And finally, do you expect to integrate these ports into JDK 9 mainline? I would like to work with the aarch32 project team towards that goal. Bob. > Thanks a lot and best regards, > Volker > > > On Wed, Sep 28, 2016 at 4:07 PM, Bob Vandette wrote: >> I?m am please to announce that I have completed our internal reviews and can now >> open up the sources to our ARM 32 & 64 bit implementations of JDK9. >> >> Here is a webrev that includes a patch that can be applied on top of the >> (http://hg.openjdk.java.net/aarch32-port/jdk9-arm3264/ ) forest. >> >> http://cr.openjdk.java.net/~bobv/arm3264/webrev >> >> Notes: >> >> 1. Counter to my initial email announcing the open sourcing effort, the >> pregenerated interpreter is not included in the provided patch. AOT is >> our long term solution for increased performance on Mobile and it was decided >> that we do not want to support the static interpreter beyond JDK 8. >> >> 2. In order to allow building the two different 64-bit ARM sources, I overloaded >> a new configure option ?abi-profile to allow for the selection of the Oracle >> 64-bit ARM port. We need a better solution before this support can be >> integrated into the mainline. To use the Oracle sources for an aarch64 build, >> select ?abi-profile=arm64. >> >> 3. The scripts provided below allows for the creation of the minimal, client and >> server VMs for the Oracle aarch64 build, however, the jvm.cfg file is not >> automatically updated during the build. To run a non server VM, this file >> will need to be updated. >> >> 4. In order to make it easier to keep the new open sources up to date with >> their closed counterparts in jdk9, I have added a comment in >> hotspot/src/cpu/arm/vm/vm_version_ext_arm.hpp which contains the mercurial >> revision that I last merged with. This will make it easier to produce patches >> to bring the new open files up to the latest version. >> >> /* ARM sources Merged up to hotspot/src/closed changeset 2316:b247a2ea70e4 */ >> >> Build Scripts: >> >> Here are a set of scripts that demonstrate how to build the three ARM >> configurations. We typically cross compile our ARM builds so these >> scripts will have to be adjusted in order to build natively on an ARM system. >> >> http://cr.openjdk.java.net/~bobv/arm3264/scripts/ >> >> aarch64.csh Builds the current open version of aarch64 binaries >> arm64.csh Builds the Oracle aarch64 binaries >> arm.csh Builds 32-bit ARM binaries >> >> My next step is to push this changeset into the jdk9-arm3264 forest assuming I >> achieve committer status for the aarch32 project this week. >> >> Bob Vandette >> >> >> >> From aph at redhat.com Wed Sep 28 19:15:06 2016 From: aph at redhat.com (Andrew Haley) Date: Wed, 28 Sep 2016 20:15:06 +0100 Subject: [aarch64-port-dev ] Webrev of Oracle ARM & AARCH64 Sources In-Reply-To: References: <5A08C4A6-2B69-4D29-80F5-1CE11E350283@oracle.com> Message-ID: <7ea0939d-4aa1-05fc-1eac-f1da849920f4@redhat.com> On 28/09/16 18:55, Volker Simonis wrote: > My general question is how is this code contribution supposed to work > together with the current ARM ports in the OpenJDK. Currently we have > a full-blown, supported arm64 bit port in the jdk9 main-line > (contributed and maintained by RedHat). The aarch32 project has a > full-blown implementation for arm32 for jdk8u contributed by Azul. > > Is your new port intended to live and be maintained alongside these > already available ports? > Where does your port differ from the available ports in terms of > functionality and performance? > Is Oracle committed to support the new ports? > And finally, do you expect to integrate these port into JDK 9 mainline? We have to decide this by consensus. Azul seem to be happy enough to drop their own port and work on this one from Oracle: their work is new and rather immature, so it makes sense. In the case of AArch64, the situation is much less clear. We have a fairly mature and solid community-written (not just Red Hat!) implementation, and there's no obvious reason to push that implementation aside. It is the official AArch64 port of OpenJDK. I'll be posting more in the coming weeks. Andrew. From kostya at azul.com Wed Sep 28 19:22:20 2016 From: kostya at azul.com (Kostya Zolotnikov) Date: Wed, 28 Sep 2016 19:22:20 +0000 Subject: [aarch64-port-dev ] Webrev of Oracle ARM & AARCH64 Sources In-Reply-To: <7ea0939d-4aa1-05fc-1eac-f1da849920f4@redhat.com> References: <5A08C4A6-2B69-4D29-80F5-1CE11E350283@oracle.com> , <7ea0939d-4aa1-05fc-1eac-f1da849920f4@redhat.com> Message-ID: Hi, Andrew Not sure who told You about Azul's view. For us it is not that clear what make sense for You. Regards Kostya ?????????? ?? ????????? Sony Xperia? ----???????????? Andrew Haley ??????? ---- On 28/09/16 18:55, Volker Simonis wrote: > My general question is how is this code contribution supposed to work > together with the current ARM ports in the OpenJDK. Currently we have > a full-blown, supported arm64 bit port in the jdk9 main-line > (contributed and maintained by RedHat). The aarch32 project has a > full-blown implementation for arm32 for jdk8u contributed by Azul. > > Is your new port intended to live and be maintained alongside these > already available ports? > Where does your port differ from the available ports in terms of > functionality and performance? > Is Oracle committed to support the new ports? > And finally, do you expect to integrate these port into JDK 9 mainline? We have to decide this by consensus. Azul seem to be happy enough to drop their own port and work on this one from Oracle: their work is new and rather immature, so it makes sense. In the case of AArch64, the situation is much less clear. We have a fairly mature and solid community-written (not just Red Hat!) implementation, and there's no obvious reason to push that implementation aside. It is the official AArch64 port of OpenJDK. I'll be posting more in the coming weeks. Andrew. From volker.simonis at gmail.com Wed Sep 28 17:55:18 2016 From: volker.simonis at gmail.com (Volker Simonis) Date: Wed, 28 Sep 2016 19:55:18 +0200 Subject: Webrev of Oracle ARM & AARCH64 Sources In-Reply-To: <5A08C4A6-2B69-4D29-80F5-1CE11E350283@oracle.com> References: <5A08C4A6-2B69-4D29-80F5-1CE11E350283@oracle.com> Message-ID: Hi Bob, congratulations! I'm pretty sure this was a pretty huge amount of paper and programming work to reach this point :) My general question is how is this code contribution supposed to work together with the current ARM ports in the OpenJDK. Currently we have a full-blown, supported arm64 bit port in the jdk9 main-line (contributed and maintained by RedHat). The aarch32 project has a full-blown implementation for arm32 for jdk8u contributed by Azul. Is your new port intended to live and be maintained alongside these already available ports? Where does your port differ from the available ports in terms of functionality and performance? Is Oracle committed to support the new ports? And finally, do you expect to integrate these port into JDK 9 mainline? Thanks a lot and best regards, Volker On Wed, Sep 28, 2016 at 4:07 PM, Bob Vandette wrote: > I?m am please to announce that I have completed our internal reviews and can now > open up the sources to our ARM 32 & 64 bit implementations of JDK9. > > Here is a webrev that includes a patch that can be applied on top of the > (http://hg.openjdk.java.net/aarch32-port/jdk9-arm3264/ ) forest. > > http://cr.openjdk.java.net/~bobv/arm3264/webrev > > Notes: > > 1. Counter to my initial email announcing the open sourcing effort, the > pregenerated interpreter is not included in the provided patch. AOT is > our long term solution for increased performance on Mobile and it was decided > that we do not want to support the static interpreter beyond JDK 8. > > 2. In order to allow building the two different 64-bit ARM sources, I overloaded > a new configure option ?abi-profile to allow for the selection of the Oracle > 64-bit ARM port. We need a better solution before this support can be > integrated into the mainline. To use the Oracle sources for an aarch64 build, > select ?abi-profile=arm64. > > 3. The scripts provided below allows for the creation of the minimal, client and > server VMs for the Oracle aarch64 build, however, the jvm.cfg file is not > automatically updated during the build. To run a non server VM, this file > will need to be updated. > > 4. In order to make it easier to keep the new open sources up to date with > their closed counterparts in jdk9, I have added a comment in > hotspot/src/cpu/arm/vm/vm_version_ext_arm.hpp which contains the mercurial > revision that I last merged with. This will make it easier to produce patches > to bring the new open files up to the latest version. > > /* ARM sources Merged up to hotspot/src/closed changeset 2316:b247a2ea70e4 */ > > Build Scripts: > > Here are a set of scripts that demonstrate how to build the three ARM > configurations. We typically cross compile our ARM builds so these > scripts will have to be adjusted in order to build natively on an ARM system. > > http://cr.openjdk.java.net/~bobv/arm3264/scripts/ > > aarch64.csh Builds the current open version of aarch64 binaries > arm64.csh Builds the Oracle aarch64 binaries > arm.csh Builds 32-bit ARM binaries > > My next step is to push this changeset into the jdk9-arm3264 forest assuming I > achieve committer status for the aarch32 project this week. > > Bob Vandette > > > > From aph at redhat.com Thu Sep 29 08:50:54 2016 From: aph at redhat.com (Andrew Haley) Date: Thu, 29 Sep 2016 09:50:54 +0100 Subject: [aarch64-port-dev ] Webrev of Oracle ARM & AARCH64 Sources In-Reply-To: References: <5A08C4A6-2B69-4D29-80F5-1CE11E350283@oracle.com> <7ea0939d-4aa1-05fc-1eac-f1da849920f4@redhat.com> Message-ID: <36626b7a-cb53-b13b-b529-d9c43ed28d0f@redhat.com> On 28/09/16 20:22, Kostya Zolotnikov wrote: > > Not sure who told You about Azul's view. > For us it is not that clear what make sense for You. I'm not quite sure what you mean by this, but I can only go by what Azul representatives have posted here. If I've got anything wrong, I am happy to be corrected. Andrew. From andrey.petushkov at gmail.com Thu Sep 29 10:13:47 2016 From: andrey.petushkov at gmail.com (Andrey Petushkov) Date: Thu, 29 Sep 2016 13:13:47 +0300 Subject: [aarch64-port-dev ] Webrev of Oracle ARM & AARCH64 Sources In-Reply-To: <36626b7a-cb53-b13b-b529-d9c43ed28d0f@redhat.com> References: <5A08C4A6-2B69-4D29-80F5-1CE11E350283@oracle.com> <7ea0939d-4aa1-05fc-1eac-f1da849920f4@redhat.com> <36626b7a-cb53-b13b-b529-d9c43ed28d0f@redhat.com> Message-ID: <9ECF7394-3D91-4A11-840C-37318CBA0CBF@gmail.com> Dear Andrew, Pardon, I?m too puzzled by your statement. To my best knowledge no one from Azul considers this port as immature and wishes to drop it. Nor AFAIK anyone from Azul has expressed that on the maillist. In addition, aarch32 port shares much in common with RH?s aarch64 implementation so well, if you keep aarch64 in main openjdk repos it?s much easier to merge aarch32 into it, rather than merge with Sun/Oracle?s arm implementation. And yes, aarch32 is missing c2 port, but this should not make any difference long-term, right? Regards, Andrey > On 29 Sep 2016, at 11:50, Andrew Haley wrote: > > On 28/09/16 20:22, Kostya Zolotnikov wrote: >> >> Not sure who told You about Azul's view. >> For us it is not that clear what make sense for You. > > I'm not quite sure what you mean by this, but I can only go by what > Azul representatives have posted here. If I've got anything wrong, > I am happy to be corrected. > > Andrew. > From aph at redhat.com Thu Sep 29 10:43:36 2016 From: aph at redhat.com (Andrew Haley) Date: Thu, 29 Sep 2016 11:43:36 +0100 Subject: [aarch64-port-dev ] Webrev of Oracle ARM & AARCH64 Sources In-Reply-To: <9ECF7394-3D91-4A11-840C-37318CBA0CBF@gmail.com> References: <5A08C4A6-2B69-4D29-80F5-1CE11E350283@oracle.com> <7ea0939d-4aa1-05fc-1eac-f1da849920f4@redhat.com> <36626b7a-cb53-b13b-b529-d9c43ed28d0f@redhat.com> <9ECF7394-3D91-4A11-840C-37318CBA0CBF@gmail.com> Message-ID: <8fa2ec4d-3f6a-7d47-72f4-cafa1964d61a@redhat.com> On 29/09/16 11:13, Andrey Petushkov wrote: > Pardon, I?m too puzzled by your statement. To my best knowledge no > one from Azul considers this port as immature and wishes to drop > it. Nor AFAIK anyone from Azul has expressed that on the > maillist. My mistake, then. I should have waited for you to speak. I apologize. > In addition, aarch32 port shares much in common with RH?s aarch64 > implementation so well, if you keep aarch64 in main openjdk repos > it?s much easier to merge aarch32 into it, rather than merge with > Sun/Oracle?s arm implementation. There is no good technical reason for AArch64 to merge with AArch32, and IMO it would create a mess. AArch64 is a clean-sheet design which shares some of its DNA with AArch32, but that is all. It's not like x86-64, which is a 64-bit extension of x86. > And yes, aarch32 is missing c2 port, but this should not make any > difference long-term, right? I guess not, if a C2 port is forthcoming. Andrew. From aph at redhat.com Thu Sep 29 10:51:45 2016 From: aph at redhat.com (Andrew Haley) Date: Thu, 29 Sep 2016 11:51:45 +0100 Subject: RFR: 8164652: c1 port, code patching In-Reply-To: <2262cf97-394c-8a3a-e6dc-a6053d928a3c@redhat.com> References: <1472211998.2756.2.camel@gmail.com> <2262cf97-394c-8a3a-e6dc-a6053d928a3c@redhat.com> Message-ID: <004c65a0-dcfd-9f8d-97de-e3d916bfc8ba@redhat.com> There has still not been a reply to this that I can find. It is a serious issue that should be addressed. Andrew. On 31/08/16 17:58, Andrew Haley wrote: > It all looks pretty good. > > I now understand how the C1 patching code works, and it's not as bad > as I'd feared. :-) > > I'm think that it'll work on existing ARM processors, given that none > of the copying of code buffers which x86 does is used at all. > > For the benefit of onlookers: when we have to patch, say, an > instruction of the form > > mov r2, #nn > > but nn is unknown at compilation time, we lay down a stub of the form > > stub0: > movw r2, #0 > movt r2, #0 > nop > b back > > and at the "call site" we do > > b > nop > nop > back: > > Patching code first fixes up the stub: > > stub0: > movw r2, #088 > movt r2, #0 > nop > b back > > and then the call site to jump to the stub: > > b stub0 > nop > nop > back: > > With all of the icache flushing done in the correct order I think this > is OK. > > Having said that, I want to sound a note of caution. > > There is a compatibility problem in that the architecture > specification says > > ...once the modified instructions are observable, each PE that is > executing the modified instructions *must* (my emphasis) issue the > following instruction to ensure execution of the modified > instructions: > > ISB; Synchronize fetched instruction stream > > But we are not doing that on all PEs. For strict correctness we > should execute an ISB on every PE after a stub has been written and > before it is executed. In practice I don't think that it matters > because the instruction cache on the other PEs probably won't already > contain a stale copy of the stub. But it is possible: with a long > instruction cache it may do if the line has already been fetched for > an adjacent stub. Without an ISB the PE may not re-fetch its icache > line and may then execute the stale stub code. > > The patching doesn't need to be done in this way. It could have been > done as > > b > ldr r2, > > and the fixup could have initialized the constant pool entry and then > overwritten the b to a NOP . > > [ As an aside: I don't think that the trampolines on AArch64 are > vulnerable in the same way because the stubs are of the form > > ldr r2, data0 > b r2 > data0: > xword 0 > > the patching code does not modify an instruction except for the branch > at the call site, so it is legal. Having said that, perhaps we need > an acquiring load in this AArch64 stub instead of a simple LDR. ] > > Andrew. > From andrey.petushkov at gmail.com Thu Sep 29 10:54:07 2016 From: andrey.petushkov at gmail.com (Andrey Petushkov) Date: Thu, 29 Sep 2016 13:54:07 +0300 Subject: [aarch64-port-dev ] Webrev of Oracle ARM & AARCH64 Sources In-Reply-To: <8fa2ec4d-3f6a-7d47-72f4-cafa1964d61a@redhat.com> References: <5A08C4A6-2B69-4D29-80F5-1CE11E350283@oracle.com> <7ea0939d-4aa1-05fc-1eac-f1da849920f4@redhat.com> <36626b7a-cb53-b13b-b529-d9c43ed28d0f@redhat.com> <9ECF7394-3D91-4A11-840C-37318CBA0CBF@gmail.com> <8fa2ec4d-3f6a-7d47-72f4-cafa1964d61a@redhat.com> Message-ID: <15B7B9FF-A282-4687-B847-ED17B0F7AC0E@gmail.com> > On 29 Sep 2016, at 13:43, Andrew Haley wrote: > > On 29/09/16 11:13, Andrey Petushkov wrote: > >> Pardon, I?m too puzzled by your statement. To my best knowledge no >> one from Azul considers this port as immature and wishes to drop >> it. Nor AFAIK anyone from Azul has expressed that on the >> maillist. > > My mistake, then. I should have waited for you to speak. I > apologize. > >> In addition, aarch32 port shares much in common with RH?s aarch64 >> implementation so well, if you keep aarch64 in main openjdk repos >> it?s much easier to merge aarch32 into it, rather than merge with >> Sun/Oracle?s arm implementation. > > There is no good technical reason for AArch64 to merge with AArch32, > and IMO it would create a mess. AArch64 is a clean-sheet design which > shares some of its DNA with AArch32, but that is all. It's not like > x86-64, which is a 64-bit extension of x86. Well, it?s AArch32 which is not clean-sheet design but rather borrows from AArch64 :) I admit that there are much more difference between architectures than for x86 so you might be right that the difference in the code could be too big. I just have a feeling it?s not. I can mistake of course, I did not diff specifically > >> And yes, aarch32 is missing c2 port, but this should not make any >> difference long-term, right? > > I guess not, if a C2 port is forthcoming. My idea here that Oracle?s Graal can make c2 obsolete and it might not worth to port c2 only for Java 9 Andrey > > Andrew. From aph at redhat.com Thu Sep 29 11:04:26 2016 From: aph at redhat.com (Andrew Haley) Date: Thu, 29 Sep 2016 12:04:26 +0100 Subject: [aarch64-port-dev ] Webrev of Oracle ARM & AARCH64 Sources In-Reply-To: <15B7B9FF-A282-4687-B847-ED17B0F7AC0E@gmail.com> References: <5A08C4A6-2B69-4D29-80F5-1CE11E350283@oracle.com> <7ea0939d-4aa1-05fc-1eac-f1da849920f4@redhat.com> <36626b7a-cb53-b13b-b529-d9c43ed28d0f@redhat.com> <9ECF7394-3D91-4A11-840C-37318CBA0CBF@gmail.com> <8fa2ec4d-3f6a-7d47-72f4-cafa1964d61a@redhat.com> <15B7B9FF-A282-4687-B847-ED17B0F7AC0E@gmail.com> Message-ID: <91d5a8c4-26e8-13a5-d45f-1f24be595361@redhat.com> On 29/09/16 11:54, Andrey Petushkov wrote: > >> On 29 Sep 2016, at 13:43, Andrew Haley wrote: >> >> On 29/09/16 11:13, Andrey Petushkov wrote: >> >>> In addition, aarch32 port shares much in common with RH?s aarch64 >>> implementation so well, if you keep aarch64 in main openjdk repos >>> it?s much easier to merge aarch32 into it, rather than merge with >>> Sun/Oracle?s arm implementation. >> >> There is no good technical reason for AArch64 to merge with AArch32, >> and IMO it would create a mess. AArch64 is a clean-sheet design which >> shares some of its DNA with AArch32, but that is all. It's not like >> x86-64, which is a 64-bit extension of x86. > > Well, it?s AArch32 which is not clean-sheet design but rather > borrows from AArch64 :) I meant to say: the AArch64 hardware architecture is a clean-sheet design which shares some of its DNA with AArch32, but that is all. > I admit that there are much more difference between architectures > than for x86 so you might be right that the difference in the code > could be too big. I just have a feeling it?s not. I can mistake of > course, I did not diff specifically Possibly. I don't really want to make the port a mess of #ifdefs and suchlike, so I'd fight pretty hard against it. It is possible to do some macro trickery to write common runtime routines, but with sufficient such trickery it'd be possible to do that with any two unrelated arches. While it might save some time, it adds another layer of complexity and makes it harder to write efficient and idiomatic code. In particular things such as predicated instructions, which are an important part of the AArch32 ISA, are absent on AArch64. Andrew. From andrey.petushkov at gmail.com Thu Sep 29 11:10:29 2016 From: andrey.petushkov at gmail.com (Andrey Petushkov) Date: Thu, 29 Sep 2016 14:10:29 +0300 Subject: [aarch64-port-dev ] Webrev of Oracle ARM & AARCH64 Sources In-Reply-To: <91d5a8c4-26e8-13a5-d45f-1f24be595361@redhat.com> References: <5A08C4A6-2B69-4D29-80F5-1CE11E350283@oracle.com> <7ea0939d-4aa1-05fc-1eac-f1da849920f4@redhat.com> <36626b7a-cb53-b13b-b529-d9c43ed28d0f@redhat.com> <9ECF7394-3D91-4A11-840C-37318CBA0CBF@gmail.com> <8fa2ec4d-3f6a-7d47-72f4-cafa1964d61a@redhat.com> <15B7B9FF-A282-4687-B847-ED17B0F7AC0E@gmail.com> <91d5a8c4-26e8-13a5-d45f-1f24be595361@redhat.com> Message-ID: <8441C732-88C4-4D7C-A6CA-3FB06C20FB55@gmail.com> > On 29 Sep 2016, at 14:04, Andrew Haley wrote: > > On 29/09/16 11:54, Andrey Petushkov wrote: >> >>> On 29 Sep 2016, at 13:43, Andrew Haley wrote: >>> >>> On 29/09/16 11:13, Andrey Petushkov wrote: >>> >>>> In addition, aarch32 port shares much in common with RH?s aarch64 >>>> implementation so well, if you keep aarch64 in main openjdk repos >>>> it?s much easier to merge aarch32 into it, rather than merge with >>>> Sun/Oracle?s arm implementation. >>> >>> There is no good technical reason for AArch64 to merge with AArch32, >>> and IMO it would create a mess. AArch64 is a clean-sheet design which >>> shares some of its DNA with AArch32, but that is all. It's not like >>> x86-64, which is a 64-bit extension of x86. >> >> Well, it?s AArch32 which is not clean-sheet design but rather >> borrows from AArch64 :) > > I meant to say: the AArch64 hardware architecture is a clean-sheet > design which shares some of its DNA with AArch32, but that is all. Ok, git it. Sorry for misunderstanding > >> I admit that there are much more difference between architectures >> than for x86 so you might be right that the difference in the code >> could be too big. I just have a feeling it?s not. I can mistake of >> course, I did not diff specifically > > Possibly. I don't really want to make the port a mess of #ifdefs and > suchlike, so I'd fight pretty hard against it. > > It is possible to do some macro trickery to write common runtime > routines, but with sufficient such trickery it'd be possible to do > that with any two unrelated arches. While it might save some time, it > adds another layer of complexity and makes it harder to write > efficient and idiomatic code. In particular things such as predicated > instructions, which are an important part of the AArch32 ISA, are > absent on AArch64. Very much possible. I don?t want to propose it now, was just mentioning the probability. Ok it?s low, let?s dismiss it > > Andrew. From bob.vandette at oracle.com Thu Sep 29 12:33:32 2016 From: bob.vandette at oracle.com (Bob Vandette) Date: Thu, 29 Sep 2016 08:33:32 -0400 Subject: [aarch64-port-dev ] Webrev of Oracle ARM & AARCH64 Sources In-Reply-To: <8441C732-88C4-4D7C-A6CA-3FB06C20FB55@gmail.com> References: <5A08C4A6-2B69-4D29-80F5-1CE11E350283@oracle.com> <7ea0939d-4aa1-05fc-1eac-f1da849920f4@redhat.com> <36626b7a-cb53-b13b-b529-d9c43ed28d0f@redhat.com> <9ECF7394-3D91-4A11-840C-37318CBA0CBF@gmail.com> <8fa2ec4d-3f6a-7d47-72f4-cafa1964d61a@redhat.com> <15B7B9FF-A282-4687-B847-ED17B0F7AC0E@gmail.com> <91d5a8c4-26e8-13a5-d45f-1f24be595361@redhat.com> <8441C732-88C4-4D7C-A6CA-3FB06C20FB55@gmail.com> Message-ID: <7F31BDA8-F324-4CAB-826D-D3054EE8CE43@oracle.com> > On Sep 29, 2016, at 7:10 AM, Andrey Petushkov wrote: > > >> On 29 Sep 2016, at 14:04, Andrew Haley wrote: >> >> On 29/09/16 11:54, Andrey Petushkov wrote: >>> >>>> On 29 Sep 2016, at 13:43, Andrew Haley wrote: >>>> >>>> On 29/09/16 11:13, Andrey Petushkov wrote: >>>> >>>>> In addition, aarch32 port shares much in common with RH?s aarch64 >>>>> implementation so well, if you keep aarch64 in main openjdk repos >>>>> it?s much easier to merge aarch32 into it, rather than merge with >>>>> Sun/Oracle?s arm implementation. >>>> >>>> There is no good technical reason for AArch64 to merge with AArch32, >>>> and IMO it would create a mess. AArch64 is a clean-sheet design which >>>> shares some of its DNA with AArch32, but that is all. It's not like >>>> x86-64, which is a 64-bit extension of x86. >>> >>> Well, it?s AArch32 which is not clean-sheet design but rather >>> borrows from AArch64 :) >> >> I meant to say: the AArch64 hardware architecture is a clean-sheet >> design which shares some of its DNA with AArch32, but that is all. > Ok, git it. Sorry for misunderstanding >> >>> I admit that there are much more difference between architectures >>> than for x86 so you might be right that the difference in the code >>> could be too big. I just have a feeling it?s not. I can mistake of >>> course, I did not diff specifically >> >> Possibly. I don't really want to make the port a mess of #ifdefs and >> suchlike, so I'd fight pretty hard against it. >> >> It is possible to do some macro trickery to write common runtime >> routines, but with sufficient such trickery it'd be possible to do >> that with any two unrelated arches. While it might save some time, it >> adds another layer of complexity and makes it harder to write >> efficient and idiomatic code. In particular things such as predicated >> instructions, which are an important part of the AArch32 ISA, are >> absent on AArch64. > Very much possible. I don?t want to propose it now, was just mentioning the probability. Ok it?s low, let?s dismiss it It is more that just possible. I have provided you with an implementation that does just that. I don?t think you should be so fast to dismiss it. Bob. >> >> Andrew. > From edward.nevill at gmail.com Thu Sep 29 14:43:59 2016 From: edward.nevill at gmail.com (Edward Nevill) Date: Thu, 29 Sep 2016 15:43:59 +0100 Subject: Result: New aarch32-port Committer Bob Vandette Message-ID: <1475160239.2221.7.camel@gmail.com> Voting for Bob Vandette (bobv) [1] is now closed. Yes: 3 Veto: 0 Abstain: 0 According to the Bylaws definition of Lazy Consensus, this is sufficient to approve the nomination. Edward Nevill [1]?http://mail.openjdk.java.net/pipermail/aarch32-port-dev/2016-September/000467.html From akozlov at azul.com Fri Sep 30 09:55:05 2016 From: akozlov at azul.com (Anton Kozlov) Date: Fri, 30 Sep 2016 09:55:05 +0000 Subject: RFR: 8164652: c1 port, code patching In-Reply-To: <004c65a0-dcfd-9f8d-97de-e3d916bfc8ba@redhat.com> References: <1472211998.2756.2.camel@gmail.com> <2262cf97-394c-8a3a-e6dc-a6053d928a3c@redhat.com>, <004c65a0-dcfd-9f8d-97de-e3d916bfc8ba@redhat.com> Message-ID: Hi, Andrew, sorry for delay. > With all of the icache flushing done in the correct order I think this > is OK. > > Having said that, I want to sound a note of caution. > > There is a compatibility problem in that the architecture > specification says > > ...once the modified instructions are observable, each PE that is > executing the modified instructions *must* (my emphasis) issue the > following instruction to ensure execution of the modified > instructions: > > ISB; Synchronize fetched instruction stream > ARM ARM for v7 states: The ARMv7 architecture limits the set of instructions that can be executed by one thread of execution as they are being modified by another thread of execution without requiring explicit synchronization. Except for the instructions identified in this section, the effect of the concurrent modification and execution of an instruction is UNPREDICTABLE . For the following instructions only, the architecture guarantees that, after modification of the instruction, behavior is consistent with execution of either: ? The instruction originally fetched. ? A fetch of the new instruction. That is, a fetch of the instruction that results from the modification. The instructions to which this guarantee applies are: In the ARM instruction set The B , BL , NOP , BKPT , SVC , HVC , and SMC instructions. For all other instructions, to avoid UNPREDICTABLE behavior, instruction modifications must be explicitly synchronized before they are executed. The required synchronization is as follows: 1 ... 2 ..once the modified instructions are observable, ... We are patching branches only, that aren't require explicit synchronization. You cited step 2 from explicit synchronization sequence. > But we are not doing that on all PEs. For strict correctness we > should execute an ISB on every PE after a stub has been written and > before it is executed. In practice I don't think that it matters > because the instruction cache on the other PEs probably won't already > contain a stale copy of the stub. But it is possible: with a long > instruction cache it may do if the line has already been fetched for > an adjacent stub. Without an ISB the PE may not re-fetch its icache > line and may then execute the stale stub code. I'm a bit confused with this. Could you clarify your thought about icache problem? ISB is pipeline flush. Let's suppose ISB is required after branch patch. >From my point of view, then, number of executed instructions from point of patching to point of execution of patched instructions matter. ISB could be required by ARM, but in practice bad things will happen if second point is reached in less than (pipeline-length) instructions. And we are patching deeply in runtime, there are a lot of branching, mutex release,.. But yes, in case ISB required it should be added. Thanks, Anton From edward.nevill at gmail.com Fri Sep 30 10:32:01 2016 From: edward.nevill at gmail.com (Edward Nevill) Date: Fri, 30 Sep 2016 11:32:01 +0100 Subject: Webrev of Oracle ARM & AARCH64 Sources In-Reply-To: <5A08C4A6-2B69-4D29-80F5-1CE11E350283@oracle.com> References: <5A08C4A6-2B69-4D29-80F5-1CE11E350283@oracle.com> Message-ID: <1475231521.14313.29.camel@gmail.com> Hi Bob, On Wed, 2016-09-28 at 10:07 -0400, Bob Vandette wrote: > I?m am please to announce that I have completed our internal reviews and can now > open up the sources to our ARM 32 & 64 bit implementations of JDK9. Great news. > > Here is a webrev that includes a patch that can be applied on top of the > (http://hg.openjdk.java.net/aarch32-port/jdk9-arm3264/ ) forest.?? > > ?????http://cr.openjdk.java.net/~bobv/arm3264/webrev I have built this natively on armv7 and aarch64 without problems. In both cases I built the minimal,client,server combination. I have also tested the server build with JTreg hotspot & langtools. On aarch64 I got the following results:- hotspot: Test results: passed: 1,280; failed: 8; error: 43 langtools: Test results: passed: 3,700; failed: 1; error: 29 This is fairly typical, for example, using the Linaro 1609 build I get hotspot: Test results: passed: 1,271; failed: 17; error: 43 langtools: Test results: passed: 3,715; failed: 3; error: 12 On armv7 I first of all had to pin the jvm.cfg to use -server as it kept on using the client as I was not running on a 'server class machine' (since my armv7 device is a Samsung Chromebook this is fair enough). However, I then had problems with the test harness crashing with the error #??Internal Error (synchronizer.cpp:1576), pid=6533, tid=6542 #??guarantee(mid->header()->is_neutral()) failed: invariant (hs_err here?http://cr.openjdk.java.net/~enevill/aarch32/hs_err_pid6533.log) On a subsequent run the test harness locked up after 85 tests. It looks like there might be a problem with locks breaking with G1GC. I will keep investigating. I ran it again using the template interpreter for the test harness and the server for the jdk under test and it ran successfully. On armv7 I got hotspot: Test results: passed: 1,202; failed: 11; error: 36 langtools: Test results: passed: 3,718; failed: 5; error: 8 I also did some limited benchmarking which I am not going to share on a public forum. Lets just say the performance of the server JIT on armv7 was pleasing. Thanks for all your work getting to this stage. It looks good to push and you should shortly have committeer rights, if you don't get them within a few days ping me and I will give ops a nudge. All the best, Ed. From david.holmes at oracle.com Fri Sep 30 11:23:30 2016 From: david.holmes at oracle.com (David Holmes) Date: Fri, 30 Sep 2016 21:23:30 +1000 Subject: Webrev of Oracle ARM & AARCH64 Sources In-Reply-To: <1475231521.14313.29.camel@gmail.com> References: <5A08C4A6-2B69-4D29-80F5-1CE11E350283@oracle.com> <1475231521.14313.29.camel@gmail.com> Message-ID: <187f08d2-2f6d-a4f6-8662-7e8ac85308f7@oracle.com> Hi Ed, On 30/09/2016 8:32 PM, Edward Nevill wrote: > Hi Bob, > > On Wed, 2016-09-28 at 10:07 -0400, Bob Vandette wrote: >> I?m am please to announce that I have completed our internal reviews and can now >> open up the sources to our ARM 32 & 64 bit implementations of JDK9. > > Great news. > >> >> Here is a webrev that includes a patch that can be applied on top of the >> (http://hg.openjdk.java.net/aarch32-port/jdk9-arm3264/ ) forest. >> >> http://cr.openjdk.java.net/~bobv/arm3264/webrev > > I have built this natively on armv7 and aarch64 without problems. In both cases I built the minimal,client,server combination. > > I have also tested the server build with JTreg hotspot & langtools. > > On aarch64 I got the following results:- > > hotspot: Test results: passed: 1,280; failed: 8; error: 43 > langtools: Test results: passed: 3,700; failed: 1; error: 29 > > This is fairly typical, for example, using the Linaro 1609 build I get > > hotspot: Test results: passed: 1,271; failed: 17; error: 43 > langtools: Test results: passed: 3,715; failed: 3; error: 12 So most of the "errors" are probably tests that are ignored. > On armv7 I first of all had to pin the jvm.cfg to use -server as it kept on using the client as I was not running on a 'server class machine' (since my armv7 device is a Samsung Chromebook this is fair enough). > > However, I then had problems with the test harness crashing with the error > > # Internal Error (synchronizer.cpp:1576), pid=6533, tid=6542 > # guarantee(mid->header()->is_neutral()) failed: invariant > > (hs_err here http://cr.openjdk.java.net/~enevill/aarch32/hs_err_pid6533.log) Strange - that looks like our closed bug: https://bugs.openjdk.java.net/browse/JDK-8071540 which should be fixed. It was a missing memory barrier issue. Aside: we're going to have to figure out how to deal with currently closed bug reports. David ----- > On a subsequent run the test harness locked up after 85 tests. > > It looks like there might be a problem with locks breaking with G1GC. I will keep investigating. > > I ran it again using the template interpreter for the test harness and the server for the jdk under test and it ran successfully. > > On armv7 I got > > hotspot: Test results: passed: 1,202; failed: 11; error: 36 > langtools: Test results: passed: 3,718; failed: 5; error: 8 > > I also did some limited benchmarking which I am not going to share on a public forum. Lets just say the performance of the server JIT on armv7 was pleasing. > > Thanks for all your work getting to this stage. It looks good to push and you should shortly have committeer rights, if you don't get them within a few days ping me and I will give ops a nudge. > > All the best, > Ed. > > From aph at redhat.com Fri Sep 30 13:25:33 2016 From: aph at redhat.com (Andrew Haley) Date: Fri, 30 Sep 2016 14:25:33 +0100 Subject: Webrev of Oracle ARM & AARCH64 Sources In-Reply-To: <5A08C4A6-2B69-4D29-80F5-1CE11E350283@oracle.com> References: <5A08C4A6-2B69-4D29-80F5-1CE11E350283@oracle.com> Message-ID: <5feeb9a0-b4cf-5536-97cf-8e9b6f87ffe4@redhat.com> On 28/09/16 15:07, Bob Vandette wrote: > I?m am please to announce that I have completed our internal reviews and can now > open up the sources to our ARM 32 & 64 bit implementations of JDK9. > > Here is a webrev that includes a patch that can be applied on top of the > (http://hg.openjdk.java.net/aarch32-port/jdk9-arm3264/ ) forest. > > http://cr.openjdk.java.net/~bobv/arm3264/webrev I had to make this change to prevent an AARch64 assert in debug builds: diff --git a/src/cpu/arm/vm/stubGenerator_arm.cpp b/src/cpu/arm/vm/stubGenerator_arm.cpp --- a/src/cpu/arm/vm/stubGenerator_arm.cpp +++ b/src/cpu/arm/vm/stubGenerator_arm.cpp @@ -4450,6 +4450,12 @@ StubRoutines::_throw_AbstractMethodError_entry = generate_throw_exception("AbstractMethodError throw_exception", CAST_FROM_FN_PTR(address, SharedRuntime::throw_AbstractMethodError)); StubRoutines::_throw_NullPointerException_at_call_entry= generate_throw_exception("NullPointerException at call throw_exception", CAST_FROM_FN_PTR(address, SharedRuntime::throw_NullPointerException_at_call)); + StubRoutines::_throw_IncompatibleClassChangeError_entry = + generate_throw_exception("IncompatibleClassChangeError throw_exception", + CAST_FROM_FN_PTR(address, + SharedRuntime:: + throw_IncompatibleClassChangeError)); + //------------------------------------------------------------------------------------------------------------------------ // entry points that are platform specific Andrew. From bob.vandette at oracle.com Fri Sep 30 13:33:02 2016 From: bob.vandette at oracle.com (Bob Vandette) Date: Fri, 30 Sep 2016 09:33:02 -0400 Subject: Webrev of Oracle ARM & AARCH64 Sources In-Reply-To: <5feeb9a0-b4cf-5536-97cf-8e9b6f87ffe4@redhat.com> References: <5A08C4A6-2B69-4D29-80F5-1CE11E350283@oracle.com> <5feeb9a0-b4cf-5536-97cf-8e9b6f87ffe4@redhat.com> Message-ID: <24DCD61A-68AC-482C-90E2-8151DFE4858F@oracle.com> That was my fault. I botched the removal of some conditional code. I?ll fix that when I push to jdk9-arm3264. Bob. > On Sep 30, 2016, at 9:25 AM, Andrew Haley wrote: > > On 28/09/16 15:07, Bob Vandette wrote: >> I?m am please to announce that I have completed our internal reviews and can now >> open up the sources to our ARM 32 & 64 bit implementations of JDK9. >> >> Here is a webrev that includes a patch that can be applied on top of the >> (http://hg.openjdk.java.net/aarch32-port/jdk9-arm3264/ ) forest. >> >> http://cr.openjdk.java.net/~bobv/arm3264/webrev > > I had to make this change to prevent an AARch64 assert in debug builds: > > diff --git a/src/cpu/arm/vm/stubGenerator_arm.cpp b/src/cpu/arm/vm/stubGenerator_arm.cpp > --- a/src/cpu/arm/vm/stubGenerator_arm.cpp > +++ b/src/cpu/arm/vm/stubGenerator_arm.cpp > @@ -4450,6 +4450,12 @@ > StubRoutines::_throw_AbstractMethodError_entry = generate_throw_exception("AbstractMethodError throw_exception", CAST_FROM_FN_PTR(address, SharedRuntime::throw_AbstractMethodError)); > StubRoutines::_throw_NullPointerException_at_call_entry= generate_throw_exception("NullPointerException at call throw_exception", CAST_FROM_FN_PTR(address, SharedRuntime::throw_NullPointerException_at_call)); > > + StubRoutines::_throw_IncompatibleClassChangeError_entry = > + generate_throw_exception("IncompatibleClassChangeError throw_exception", > + CAST_FROM_FN_PTR(address, > + SharedRuntime:: > + throw_IncompatibleClassChangeError)); > + > //------------------------------------------------------------------------------------------------------------------------ > // entry points that are platform specific > > Andrew. > From bob.vandette at oracle.com Fri Sep 30 13:58:55 2016 From: bob.vandette at oracle.com (Bob Vandette) Date: Fri, 30 Sep 2016 09:58:55 -0400 Subject: Webrev of Oracle ARM & AARCH64 Sources In-Reply-To: <187f08d2-2f6d-a4f6-8662-7e8ac85308f7@oracle.com> References: <5A08C4A6-2B69-4D29-80F5-1CE11E350283@oracle.com> <1475231521.14313.29.camel@gmail.com> <187f08d2-2f6d-a4f6-8662-7e8ac85308f7@oracle.com> Message-ID: <7561C178-318F-47D1-B22D-CEB73F4E2F7A@oracle.com> > On Sep 30, 2016, at 7:23 AM, David Holmes wrote: > > Hi Ed, > > On 30/09/2016 8:32 PM, Edward Nevill wrote: >> Hi Bob, >> >> On Wed, 2016-09-28 at 10:07 -0400, Bob Vandette wrote: >>> I?m am please to announce that I have completed our internal reviews and can now >>> open up the sources to our ARM 32 & 64 bit implementations of JDK9. >> >> Great news. >> >>> >>> Here is a webrev that includes a patch that can be applied on top of the >>> (http://hg.openjdk.java.net/aarch32-port/jdk9-arm3264/ ) forest. >>> >>> http://cr.openjdk.java.net/~bobv/arm3264/webrev >> >> I have built this natively on armv7 and aarch64 without problems. In both cases I built the minimal,client,server combination. >> >> I have also tested the server build with JTreg hotspot & langtools. >> >> On aarch64 I got the following results:- >> >> hotspot: Test results: passed: 1,280; failed: 8; error: 43 >> langtools: Test results: passed: 3,700; failed: 1; error: 29 >> >> This is fairly typical, for example, using the Linaro 1609 build I get >> >> hotspot: Test results: passed: 1,271; failed: 17; error: 43 >> langtools: Test results: passed: 3,715; failed: 3; error: 12 > > So most of the "errors" are probably tests that are ignored. > >> On armv7 I first of all had to pin the jvm.cfg to use -server as it kept on using the client as I was not running on a 'server class machine' (since my armv7 device is a Samsung Chromebook this is fair enough). >> >> However, I then had problems with the test harness crashing with the error >> >> # Internal Error (synchronizer.cpp:1576), pid=6533, tid=6542 >> # guarantee(mid->header()->is_neutral()) failed: invariant >> >> (hs_err here http://cr.openjdk.java.net/~enevill/aarch32/hs_err_pid6533.log) > > Strange - that looks like our closed bug: > > https://bugs.openjdk.java.net/browse/JDK-8071540 > > which should be fixed. It was a missing memory barrier issue. I checked and this fix was applied but later a newer implementation was added. The memory barriers were moved to cas_for_lock_acquire with optimized versions for aarch64. Be aware that G1 support on 32-bit ARM is not fully supported by the GC team. It?s experimental. This means that there was an attempt to implement it but it has not undergone the same level of testing as other platforms. I?ll forward this issue to the GC team. Bob. > > Aside: we're going to have to figure out how to deal with currently closed bug reports. > > David > ----- > >> On a subsequent run the test harness locked up after 85 tests. >> >> It looks like there might be a problem with locks breaking with G1GC. I will keep investigating. >> >> I ran it again using the template interpreter for the test harness and the server for the jdk under test and it ran successfully. >> >> On armv7 I got >> >> hotspot: Test results: passed: 1,202; failed: 11; error: 36 >> langtools: Test results: passed: 3,718; failed: 5; error: 8 >> >> I also did some limited benchmarking which I am not going to share on a public forum. Lets just say the performance of the server JIT on armv7 was pleasing. >> >> Thanks for all your work getting to this stage. It looks good to push and you should shortly have committeer rights, if you don't get them within a few days ping me and I will give ops a nudge. >> >> All the best, >> Ed. >> >> From bob.vandette at oracle.com Fri Sep 30 14:03:10 2016 From: bob.vandette at oracle.com (Bob Vandette) Date: Fri, 30 Sep 2016 10:03:10 -0400 Subject: Webrev of Oracle ARM & AARCH64 Sources In-Reply-To: <1475231521.14313.29.camel@gmail.com> References: <5A08C4A6-2B69-4D29-80F5-1CE11E350283@oracle.com> <1475231521.14313.29.camel@gmail.com> Message-ID: <25E205BE-9EE9-488A-9D08-DED365288D7F@oracle.com> Ed, Could you try the 32-bit ARM binaries from the early access page to see if the G1GC problem reproduces? https://jdk9.java.net/download/ Bob. > On Sep 30, 2016, at 6:32 AM, Edward Nevill wrote: > > Hi Bob, > > On Wed, 2016-09-28 at 10:07 -0400, Bob Vandette wrote: >> I?m am please to announce that I have completed our internal reviews and can now >> open up the sources to our ARM 32 & 64 bit implementations of JDK9. > > Great news. > >> >> Here is a webrev that includes a patch that can be applied on top of the >> (http://hg.openjdk.java.net/aarch32-port/jdk9-arm3264/ ) forest. >> >> http://cr.openjdk.java.net/~bobv/arm3264/webrev > > I have built this natively on armv7 and aarch64 without problems. In both cases I built the minimal,client,server combination. > > I have also tested the server build with JTreg hotspot & langtools. > > On aarch64 I got the following results:- > > hotspot: Test results: passed: 1,280; failed: 8; error: 43 > langtools: Test results: passed: 3,700; failed: 1; error: 29 > > This is fairly typical, for example, using the Linaro 1609 build I get > > hotspot: Test results: passed: 1,271; failed: 17; error: 43 > langtools: Test results: passed: 3,715; failed: 3; error: 12 > > On armv7 I first of all had to pin the jvm.cfg to use -server as it kept on using the client as I was not running on a 'server class machine' (since my armv7 device is a Samsung Chromebook this is fair enough). > > However, I then had problems with the test harness crashing with the error > > # Internal Error (synchronizer.cpp:1576), pid=6533, tid=6542 > # guarantee(mid->header()->is_neutral()) failed: invariant > > (hs_err here http://cr.openjdk.java.net/~enevill/aarch32/hs_err_pid6533.log) > > On a subsequent run the test harness locked up after 85 tests. > > It looks like there might be a problem with locks breaking with G1GC. I will keep investigating. > > I ran it again using the template interpreter for the test harness and the server for the jdk under test and it ran successfully. > > On armv7 I got > > hotspot: Test results: passed: 1,202; failed: 11; error: 36 > langtools: Test results: passed: 3,718; failed: 5; error: 8 > > I also did some limited benchmarking which I am not going to share on a public forum. Lets just say the performance of the server JIT on armv7 was pleasing. > > Thanks for all your work getting to this stage. It looks good to push and you should shortly have committeer rights, if you don't get them within a few days ping me and I will give ops a nudge. > > All the best, > Ed. > > From cthalinger at twitter.com Fri Sep 30 22:42:18 2016 From: cthalinger at twitter.com (Christian Thalinger) Date: Fri, 30 Sep 2016 12:42:18 -1000 Subject: [aarch64-port-dev ] Webrev of Oracle ARM & AARCH64 Sources In-Reply-To: <15B7B9FF-A282-4687-B847-ED17B0F7AC0E@gmail.com> References: <5A08C4A6-2B69-4D29-80F5-1CE11E350283@oracle.com> <7ea0939d-4aa1-05fc-1eac-f1da849920f4@redhat.com> <36626b7a-cb53-b13b-b529-d9c43ed28d0f@redhat.com> <9ECF7394-3D91-4A11-840C-37318CBA0CBF@gmail.com> <8fa2ec4d-3f6a-7d47-72f4-cafa1964d61a@redhat.com> <15B7B9FF-A282-4687-B847-ED17B0F7AC0E@gmail.com> Message-ID: <7FFCC804-286B-4CDF-94A7-A8B46DCFC812@twitter.com> > On Sep 29, 2016, at 12:54 AM, Andrey Petushkov wrote: > >> >> On 29 Sep 2016, at 13:43, Andrew Haley wrote: >> >> On 29/09/16 11:13, Andrey Petushkov wrote: >> >>> Pardon, I?m too puzzled by your statement. To my best knowledge no >>> one from Azul considers this port as immature and wishes to drop >>> it. Nor AFAIK anyone from Azul has expressed that on the >>> maillist. >> >> My mistake, then. I should have waited for you to speak. I >> apologize. >> >>> In addition, aarch32 port shares much in common with RH?s aarch64 >>> implementation so well, if you keep aarch64 in main openjdk repos >>> it?s much easier to merge aarch32 into it, rather than merge with >>> Sun/Oracle?s arm implementation. >> >> There is no good technical reason for AArch64 to merge with AArch32, >> and IMO it would create a mess. AArch64 is a clean-sheet design which >> shares some of its DNA with AArch32, but that is all. It's not like >> x86-64, which is a 64-bit extension of x86. > Well, it?s AArch32 which is not clean-sheet design but rather borrows from AArch64 :) > I admit that there are much more difference between architectures than for x86 so you might be right that the difference in the code could be too big. I just have a feeling it?s not. I can mistake of course, I did not diff specifically >> >>> And yes, aarch32 is missing c2 port, but this should not make any >>> difference long-term, right? >> >> I guess not, if a C2 port is forthcoming. > My idea here that Oracle?s Graal can make c2 obsolete and it might not worth to port c2 only for Java 9 Listen to this man :-)