From akozlov at azul.com Tue Jul 5 17:51:39 2016 From: akozlov at azul.com (Anton Kozlov) Date: Tue, 5 Jul 2016 17:51:39 +0000 Subject: [8u] RFR: nativeInstruction atomicity and correctness of patching In-Reply-To: <1459848344.27492.27.camel@mylittlepony.linaroharston> References: <1459342792.10845.130.camel@azul.com> <56FBD058.1070606@redhat.com> <1459350908.10845.143.camel@azul.com> <56FBEFE9.9060701@redhat.com> <56FCE4A9.7080903@redhat.com> <1459507244.10845.197.camel@azul.com> <1459848344.27492.27.camel@mylittlepony.linaroharston> Message-ID: <1467741124.3307.2.camel@azul.com> Hi, All! Andrew, let me clarify, the concern is in cores cache coherence after executing NativeTrampolineCall::set_destination_mt_safe? From my point of view, since > > > looking at linux/arch/arm/include/asm/cacheflush.h and I can't see > > > anything like that.??All I see is that do_cache_op calls > > > __flush_cache_user_range, and all that does is ensure that the I and > > > D > > > caches are coherent. > after any case from 1) instruction modification and ICache::flush 2) NativeTrampolineCall::set_destination_mt_safe and no data flush we came to the same state, when new data is in the dcache of single core. NativeTrampolineCall::set_destination_mt_safe is not different from any other instruction modification methods. And we both agree that it's OK to call old destination even after modification. And eventually data change will land to other core dchache, because there is fence on executing site, which you've mentioned.?? set_destination_mt_safe is called when PatchingLock is taken, so it's followed by release. Executing thread could see only 2 options, since patch is word-aligned single word data chage: 1) new data. Then everything is OK, just call new destination 2) old data. Then execution stream should go to same patching code, c1_Runtime, which takes same PatchingLock,? and therefore executes acquire. Then it should see new data, perform no patching, leave patching routine and call new destination. Thanks, Anton On Tue, 2016-04-05 at 10:25 +0100, Edward Nevill wrote: > Hi, > > Was there a conclusion on this? > > Are you happy with Anton's rev2 patch? > > All the best, > Ed. > > On Fri, 2016-04-01 at 10:41 +0000, Anton Kozlov wrote: > > > > Hi, Andrew, > > > > On Thu, 2016-03-31 at 09:49 +0100, Andrew Haley wrote: > > > > > > On 30/03/16 20:53, Anton Kozlov wrote: > > > > > > > > > > > On Wed, 2016-03-30 at 16:25 +0100, Andrew Haley wrote: > > > > > > > > > > On 03/30/2016 04:15 PM, Anton Kozlov wrote: > > > > > > > > > > > > ICache::invalidate_word used here not to provide coherency > > > > > > between > > > > > > Icache and Dcache, but to maintain in-order visibillity of code > > > > > > modification. > > > > > What exactly are you trying to synchronize? > > > > > > > > ICache::invalidate ensures that all CPUs see modifications of code. > > > > Data modification in trampoline should be visible in the same way, > > > > same time as code modification would. For this ICache::invalidate > > > > used, as it by implementation should synchornize dcaches among > > > > CPUs. > > > I don't think so.??In order for this to work, the *reader* would have > > > to execute some kind of fence too.??I don't think that's possible > > > without an inter-processor interrupt across all cores, and I think > > > that __clear_cache doesn't do that.??I certainly hope not. > > > > > > > > > > > > > > > > > > > > > > > > This is achieved by implementation of ICache::invalidate_word, > > > > > > which is just call to __clear_cache syscall wrapper. > > > > > I don't think there's any point.??It's not instructions but data, > > > > > so > > > > > ICache::invalidate_word is inappropriate. > > > > Agree, ICache is bad name for that. How about direct __clear_cache > > > > call? > > > > > > > > Also, I will try to study implementation of __clear_cache to know, > > > > how exactly it's done. > > > I think you will find that it does not do what you think it does.? > > > ?I'm > > > looking at linux/arch/arm/include/asm/cacheflush.h and I can't see > > > anything like that.??All I see is that do_cache_op calls > > > __flush_cache_user_range, and all that does is ensure that the I and > > > D > > > caches are coherent. > From akozlov at azul.com Tue Jul 5 18:01:11 2016 From: akozlov at azul.com (Anton Kozlov) Date: Tue, 5 Jul 2016 18:01:11 +0000 Subject: Question about non-integrated patches In-Reply-To: <57695869.90106@redhat.com> References: <5759757C.6060608@redhat.com> <1466518328.2080.10.camel@gmail.com> <57695869.90106@redhat.com> Message-ID: <1467741695.3307.10.camel@azul.com> Hi, Andrew, I'm very surprised to hear "just wrong", without arguments. In that long discussion we've talked about?NativeTrampolineCall, is there a mistake here? Let's continue technical discussion in that thread http://mail.openjdk.java.net/pipermail/aarch32-port-dev/2016-July/000364.html Thanks, Anton On Tue, 2016-06-21 at 16:08 +0100, Andrew Haley wrote: > On 21/06/16 15:12, Edward Nevill wrote: > > > > > > > > http://mail.openjdk.java.net/pipermail/aarch32-port-dev/2016-March/000183. > > > html > > There was a lengthy review with Andrew Haley which did not reach any > > conclusion. > NativeGeneralJump::replace_mt_safe() was just wrong.??There's no > safe way to do what that patch was trying to do, which is why we > ended up using trampolines in AArch64. > > Andrew. > From aph at redhat.com Tue Jul 5 18:47:08 2016 From: aph at redhat.com (Andrew Haley) Date: Tue, 5 Jul 2016 19:47:08 +0100 Subject: [8u] RFR: nativeInstruction atomicity and correctness of patching In-Reply-To: <1467741124.3307.2.camel@azul.com> References: <1459342792.10845.130.camel@azul.com> <56FBD058.1070606@redhat.com> <1459350908.10845.143.camel@azul.com> <56FBEFE9.9060701@redhat.com> <56FCE4A9.7080903@redhat.com> <1459507244.10845.197.camel@azul.com> <1459848344.27492.27.camel@mylittlepony.linaroharston> <1467741124.3307.2.camel@azul.com> Message-ID: <577C00AC.6020705@redhat.com> On 05/07/16 18:51, Anton Kozlov wrote: > > Hi, All! > > Andrew, let me clarify, the concern is in cores cache coherence after executing > NativeTrampolineCall::set_destination_mt_safe? > > From my point of view, since > >>>> looking at linux/arch/arm/include/asm/cacheflush.h and I can't see >>>> anything like that. All I see is that do_cache_op calls >>>> __flush_cache_user_range, and all that does is ensure that the I and >>>> D >>>> caches are coherent. >> > > after any case from > 1) instruction modification and ICache::flush > 2) NativeTrampolineCall::set_destination_mt_safe and no data flush > we came to the same state, when new data is in the dcache of single core. We don't know that: the data is at least in the local dcache. Some of the data may be in other caches too. > NativeTrampolineCall::set_destination_mt_safe is not different from any other > instruction modification methods. It's not wrong, but it does a pointless ICache::invalidate_word(). It's pointless because the word at addr() + 8 isn't an instruction, as far as I can see. > And we both agree that it's OK to call old destination even after modification. Yes. > And eventually data change will land to other core dchache, because there is > fence on executing site, which you've mentioned. > set_destination_mt_safe is called when PatchingLock is taken, so it's followed > by release. > Executing thread could see only 2 options, since patch is word-aligned single > word data chage: > 1) new data. Then everything is OK, just call new destination > 2) old data. Then execution stream should go to same patching code, c1_Runtime, > which takes same PatchingLock, > and therefore executes acquire. Then it should see new data, perform no > patching, leave patching routine and call new destination. There is never any problem patching a single word. That can be done MT-safe if it's a word of data or it is a single patchable instruction. Both of these are guaranteed: nothing else is. This is the code that smells bad: void NativeGeneralJump::replace_mt_safe(address instr_addr, address code_buffer) { - ShouldNotCallThis(); + // FIXME NativeCall from patching_epilog nops filling + const int bytes_to_copy = NativeCall::instruction_size; + const address patching_switch_addr = code_buffer + bytes_to_copy; + NativeImmJump* patching_switch = NativeImmJump::from(patching_switch_addr); + assert(patching_switch->destination() == patching_switch_addr + NativeInstruction::arm_insn_sz, + "switch should be branch to next instr at this point"); + patching_switch->set_destination(instr_addr + bytes_to_copy); + ICache::invalidate_word(patching_switch_addr); + + NativeImmJump* nj = NativeImmJump::from(instr_addr); // checking that it is a jump + nj->set_destination(code_buffer); + ICache::invalidate_word(instr_addr); + } I don't think this is MT-safe. I don't know why you call ICache::invalidate_word twice. As far as I can see the only place where NativeGeneralJump::replace_mt_safe is used is in the C1 patching code, but that multiple-instruction patching relies on ordering guarantees we don't have on ARM. It's hoping that if you patch things in a certain order they will be seen by other cores in the same order. Andrew. From aph at redhat.com Tue Jul 5 19:00:30 2016 From: aph at redhat.com (Andrew Haley) Date: Tue, 5 Jul 2016 20:00:30 +0100 Subject: Question about non-integrated patches In-Reply-To: <1467741695.3307.10.camel@azul.com> References: <5759757C.6060608@redhat.com> <1466518328.2080.10.camel@gmail.com> <57695869.90106@redhat.com> <1467741695.3307.10.camel@azul.com> Message-ID: <577C03CE.9020500@redhat.com> On 05/07/16 19:01, Anton Kozlov wrote: > Andrew, I'm very surprised to hear "just wrong", without arguments. I already replied in the thread, with details, months ago. Andrew. From akozlov at azul.com Wed Jul 6 13:01:58 2016 From: akozlov at azul.com (Anton Kozlov) Date: Wed, 6 Jul 2016 13:01:58 +0000 Subject: [8u] RFR: nativeInstruction atomicity and correctness of patching In-Reply-To: <577C00AC.6020705@redhat.com> References: <1459342792.10845.130.camel@azul.com> <56FBD058.1070606@redhat.com> <1459350908.10845.143.camel@azul.com> <56FBEFE9.9060701@redhat.com> <56FCE4A9.7080903@redhat.com> <1459507244.10845.197.camel@azul.com> <1459848344.27492.27.camel@mylittlepony.linaroharston> <1467741124.3307.2.camel@azul.com> <577C00AC.6020705@redhat.com> Message-ID: <1467810142.6899.40.camel@azul.com> Andrew, thanks for reply, On Tue, 2016-07-05 at 19:47 +0100, Andrew Haley wrote: > > NativeTrampolineCall::set_destination_mt_safe is not different from any > > other > > instruction modification methods. > It's not wrong, but it does a pointless ICache::invalidate_word(). > It's pointless because the word at addr() + 8 isn't an instruction, > as far as I can see. > Agree. I've removed ICache::invalidate_word in?NativeTrampolineCall in second revision of the patch. > > And eventually data change will land to other core dchache, because there is > > fence on executing site, which you've mentioned.?? > > set_destination_mt_safe is called when PatchingLock is taken, so it's > > followed > > by release. > > > > Executing thread could see only 2 options, since patch is word-aligned > > single > > word data chage: > > 1) new data. Then everything is OK, just call new destination > > 2) old data. Then execution stream should go to same patching code, > > c1_Runtime, > > which takes same PatchingLock,? > > and therefore executes acquire. Then it should see new data, perform no > > patching, leave patching routine and call new destination. > There is never any problem patching a single word.??That can be done > MT-safe if it's a word of data or it is a single patchable > instruction.??Both of these are guaranteed: nothing else is. > > This is the code that smells bad: > > ?void NativeGeneralJump::replace_mt_safe(address instr_addr, address > code_buffer) { > -??ShouldNotCallThis(); > +??// FIXME NativeCall from patching_epilog nops filling > +??const int bytes_to_copy = NativeCall::instruction_size; > +??const address patching_switch_addr = code_buffer + bytes_to_copy; > +??NativeImmJump* patching_switch = NativeImmJump::from(patching_switch_addr); > +??assert(patching_switch->destination() == patching_switch_addr + > NativeInstruction::arm_insn_sz, > +?????????"switch should be branch to next instr at this point"); > +??patching_switch->set_destination(instr_addr + bytes_to_copy); > +??ICache::invalidate_word(patching_switch_addr); > + > +??NativeImmJump* nj = NativeImmJump::from(instr_addr); // checking that it is > a jump > +??nj->set_destination(code_buffer); > +??ICache::invalidate_word(instr_addr); > + > ?} > > I don't think this is MT-safe.??I don't know why you call > ICache::invalidate_word twice. > > As far as I can see the only place where > NativeGeneralJump::replace_mt_safe is used is in the C1 patching code, > but that multiple-instruction patching relies on ordering guarantees > we don't have on ARM.??It's hoping that if you patch things in a > certain order they will be seen by other cores in the same order. > Aha, yes, NativeGeneralJump::replace_mt_safe is tricky one. This code assumes it's only used in C1 patching, and for our tip, it's true C1 patching relies on abillity to replace jump to patching stub with some code like long jump(movw+movt+bl), constant loading (movw+movt). Yes, this unallowed to do on ARM without fences like instruction pipeline flush. We make a trick from the fact, that PatchingStub have a copy of code that will be overwritten with. We will make that code executable when it patching happened by replacing method branch to patching stub with branch to patched copy. In contrast, on x86 method branch will be replaced with patched copy itself. You can assure that only allowed instruction modification preformed, since?NativeImmJump recognize only `b ADDR` instruction. `b ADDR1` replaced? with `b ADDR2` here. Actually, PatchingStub have one extra branch, compared with other platforms. It's required because C1 itself also uses the patching copy of code as executable in some cases. This extra branch is called patching_switch In case 2 instruction modifications reordered on executing site, it will lead to entry to c1 pathing routine, which does nothing if patching already occured? I know it's hard to reason about code you can't see. In case NativeGeneralJump still is not good, this patch could be postponed and reviewed together with C1 when published. Thanks, Anton From aph at redhat.com Wed Jul 6 13:10:40 2016 From: aph at redhat.com (Andrew Haley) Date: Wed, 6 Jul 2016 14:10:40 +0100 Subject: [8u] RFR: nativeInstruction atomicity and correctness of patching In-Reply-To: <1467810142.6899.40.camel@azul.com> References: <1459342792.10845.130.camel@azul.com> <56FBD058.1070606@redhat.com> <1459350908.10845.143.camel@azul.com> <56FBEFE9.9060701@redhat.com> <56FCE4A9.7080903@redhat.com> <1459507244.10845.197.camel@azul.com> <1459848344.27492.27.camel@mylittlepony.linaroharston> <1467741124.3307.2.camel@azul.com> <577C00AC.6020705@redhat.com> <1467810142.6899.40.camel@azul.com> Message-ID: <577D0350.3050403@redhat.com> On 06/07/16 14:01, Anton Kozlov wrote: > I know it's hard to reason about code you can't see. In case > NativeGeneralJump still is not good, this patch could be postponed > and reviewed together with C1 when published. Perhaps it should be. It ought to be possible to do the NativeGeneralJump in a way that doesn't require any deep magic or undefined behaviour, even if it ends up being slightly slower. I don't want to get in your way, but I have to say when I'm not convinced. I'll withdraw my objection now because I know that this code won't be called from anywhere, but we must revisit this with the C1 patch. Andrew. From andrey.petushkov at gmail.com Thu Jul 14 15:30:07 2016 From: andrey.petushkov at gmail.com (Andrey Petushkov) Date: Thu, 14 Jul 2016 18:30:07 +0300 Subject: armv6k support Message-ID: <0CFAFCB6-ED55-4331-BB34-40A489689921@gmail.com> Dear Ed, I?ve finished implementation of ARM v6K support and is ready to publish it. However there is a problem that the patch significantly depends on not yet integrated changes by Anton (see the thread named ?[8u] RFR: nativeInstruction atomicity and correctness of patching?). So please let me know if you consider consensus reached (at least temporarily) between Andrew and Anton and if Anton?s patch could be integrated soon. I?ll pend on it then. Otherwise I have to revisit the implementation to correspond to current state of aarch32-jdk8u repo (which of course I?d like to avoid if possible) Thank you, Andrey From aph at redhat.com Thu Jul 14 15:32:48 2016 From: aph at redhat.com (Andrew Haley) Date: Thu, 14 Jul 2016 16:32:48 +0100 Subject: armv6k support In-Reply-To: <0CFAFCB6-ED55-4331-BB34-40A489689921@gmail.com> References: <0CFAFCB6-ED55-4331-BB34-40A489689921@gmail.com> Message-ID: <5787B0A0.8000508@redhat.com> On 14/07/16 16:30, Andrey Petushkov wrote: > I?ve finished implementation of ARM v6K support and is ready to > publish it. However there is a problem that the patch significantly > depends on not yet integrated changes by Anton (see the thread named > ?[8u] RFR: nativeInstruction atomicity and correctness of > patching?). So please let me know if you consider consensus reached > (at least temporarily) between Andrew and Anton and if Anton?s patch > could be integrated soon. I?ll pend on it then. Otherwise I have to > revisit the implementation to correspond to current state of > aarch32-jdk8u repo (which of course I?d like to avoid if possible) Great. Yes, that's OK for the time being. We can review the correctness of the patching when you publish the rest. Andrew. From andrey.petushkov at gmail.com Thu Jul 14 15:38:58 2016 From: andrey.petushkov at gmail.com (Andrey Petushkov) Date: Thu, 14 Jul 2016 15:38:58 +0000 Subject: armv6k support In-Reply-To: <5787B0A0.8000508@redhat.com> References: <0CFAFCB6-ED55-4331-BB34-40A489689921@gmail.com> <5787B0A0.8000508@redhat.com> Message-ID: Hi Andrew, Thank you! I will need some hand with pushing of Anton's changes indeed, since Sergey Nazarkin is on vacation Regards, Andrey On Thu, Jul 14, 2016 at 6:32 PM Andrew Haley wrote: > On 14/07/16 16:30, Andrey Petushkov wrote: > > > I?ve finished implementation of ARM v6K support and is ready to > > publish it. However there is a problem that the patch significantly > > depends on not yet integrated changes by Anton (see the thread named > > ?[8u] RFR: nativeInstruction atomicity and correctness of > > patching?). So please let me know if you consider consensus reached > > (at least temporarily) between Andrew and Anton and if Anton?s patch > > could be integrated soon. I?ll pend on it then. Otherwise I have to > > revisit the implementation to correspond to current state of > > aarch32-jdk8u repo (which of course I?d like to avoid if possible) > > Great. Yes, that's OK for the time being. We can review the > correctness of the patching when you publish the rest. > > Andrew. > From abrygin at azul.com Fri Jul 15 14:35:58 2016 From: abrygin at azul.com (abrygin at azul.com) Date: Fri, 15 Jul 2016 14:35:58 +0000 Subject: hg: aarch32-port/jdk8u/hotspot: 8161482: aarch32: nativeInstruction atomicity and correctness of patching Message-ID: <201607151435.u6FEZwhL016053@aojmv0008.oracle.com> Changeset: 317e3cb2c7d6 Author: bae Date: 2016-07-15 17:34 +0300 URL: http://hg.openjdk.java.net/aarch32-port/jdk8u/hotspot/rev/317e3cb2c7d6 8161482: aarch32: nativeInstruction atomicity and correctness of patching Reviewed-by: aph Contributed-by: Anton Kozlov ! src/cpu/aarch32/vm/compiledIC_aarch32.cpp ! src/cpu/aarch32/vm/macroAssembler_aarch32.cpp ! src/cpu/aarch32/vm/nativeInst_aarch32.cpp ! src/cpu/aarch32/vm/nativeInst_aarch32.hpp ! src/os_cpu/linux_aarch32/vm/atomic_linux_aarch32.inline.hpp From andrey.petushkov at gmail.com Fri Jul 15 15:52:14 2016 From: andrey.petushkov at gmail.com (Andrey Petushkov) Date: Fri, 15 Jul 2016 18:52:14 +0300 Subject: RFR: JDK-8161495: Fix patching, that may be occured twice (because patching checked by jump presence, which remain after patching in aarch32) Message-ID: Dear All, The notorious patch from Anton Kozlov is indeed missing a few more lines in order to function properly. The logic should be added to protect from trying to patch the site again when it?s already patched. Unfortunately the shared code is impacted because the decision to patch is made there and in terms which are far too much platform dependent, and happen to be unsuitable for the scheme we have chosen. The changes are by courtesy of Anton himself (I just happen need them in order to apply my v6k patch..) http://cr.openjdk.java.net/~apetushkov/8161495/webrev/ Thanks, Andrey From snazarkin at azul.com Thu Jul 21 09:46:59 2016 From: snazarkin at azul.com (snazarkin at azul.com) Date: Thu, 21 Jul 2016 09:46:59 +0000 Subject: hg: aarch32-port/jdk8u/hotspot: 8161495: aarch32: avoid patching site which is already patched Message-ID: <201607210946.u6L9kxff021783@aojmv0008.oracle.com> Changeset: d37140bc27f3 Author: snazarki Date: 2016-07-20 18:57 +0300 URL: http://hg.openjdk.java.net/aarch32-port/jdk8u/hotspot/rev/d37140bc27f3 8161495: aarch32: avoid patching site which is already patched Reviewed-by: aph Contributed-by: Anton Kozlov ! src/cpu/aarch32/vm/nativeInst_aarch32.cpp ! src/cpu/aarch32/vm/nativeInst_aarch32.hpp ! src/share/vm/c1/c1_Runtime1.cpp From snazarkin at azul.com Thu Jul 21 14:41:30 2016 From: snazarkin at azul.com (Sergey Nazarkin) Date: Thu, 21 Jul 2016 14:41:30 +0000 Subject: RFR: JDK-8162111: Invalid TOS2 value is printed by tracebytecodes Message-ID: <185C6622-06FA-4352-B7EA-EE473F0D287D@azul.com> Hi! Please review small fix for verbose mode of tracebytecodes Test class: public class LongSquare { public static long square(long d) { return d*d; } public static void main(String[] args) { System.out.println(square(Long.MAX_VALUE/10)); } } Before fix: [20880] static jlong LongSquare.square(jlong) [20880] 509428 0 0x00000009 0x00000000 lload_0 [20880] 509429 1 0xcccccccc 0x00000000 lload_0 [20880] 509430 2 0xcccccccc 0x00000000 lmul After fix: [26258] static jlong LongSquare.square(jlong) [26258] 509428 0 0x00000009 0x0ccccccc lload_0 [26258] 509429 1 0xcccccccc 0x0ccccccc lload_0 [26258] 509430 2 0xcccccccc 0x0ccccccc lmul Issue: https://bugs.openjdk.java.net/browse/JDK-8162111 Webrev: http://cr.openjdk.java.net/~snazarki/8162111/ Sergey Nazarkin From snazarkin at azul.com Fri Jul 22 10:51:05 2016 From: snazarkin at azul.com (Sergey Nazarkin) Date: Fri, 22 Jul 2016 10:51:05 +0000 Subject: RFR: JDK-8162381: ldrd/strd from unaligned address results in low performance Message-ID: <2388536D-1B83-4CE6-B9A6-223E4291DC4A@azul.com> Hi! Please review performance improvement patch. Pref profile on SPECjvm2088 xml.transform without call graph shows next hot methods: 5.72% java [kernel.kallsyms] [k] do_alignment 1.32% java [kernel.kallsyms] [k] do_alignment_ldrdstrd This mean that kernel is makes memory accesses when address is not aligned and reduces performance dramatically Issue: https://bugs.openjdk.java.net/browse/JDK-8162381 Review: http://cr.openjdk.java.net/~snazarki/8162381/ Sergey Nazarkin From snazarkin at azul.com Fri Jul 22 11:25:49 2016 From: snazarkin at azul.com (Sergey Nazarkin) Date: Fri, 22 Jul 2016 11:25:49 +0000 Subject: RFR: JDK-8162391: Check for DTrace flags only when dtrace enabled Message-ID: <02E6953F-97E2-4541-B03F-C711E3CA1FF3@azul.com> Hi! Please review small changeset that is part of performance improvement activity issue: https://bugs.openjdk.java.net/browse/JDK-8162391 review: http://cr.openjdk.java.net/~snazarki/8162391/ Sergey Nazarkin From akashche at redhat.com Fri Jul 22 11:44:04 2016 From: akashche at redhat.com (Alex Kashchenko) Date: Fri, 22 Jul 2016 14:44:04 +0300 Subject: [9] RFC: aarch32 changes for JDK-8143608: Don't 64-bit align start of InstanceKlass vtable, itable, and nonstatic_oopmap on 32-bit systems Message-ID: <57920704.5030101@redhat.com> Hi, This change is a part of the merge of aarch32-jdk9 with jdk-9+109 mainline tag. - mainline issue: https://bugs.openjdk.java.net/browse/JDK-8143608 - discussion thread: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2015-December/017005.html - aarch32 patch: http://cr.openjdk.java.net/~akasko/aarch32/jdk9/tag_109/aarch32_8143608.patch Without this change jdk-9+109 will fail on startup with the following error: Error occurred during initialization of VM java.lang.IncompatibleClassChangeError at java.lang.StackStreamFactory.init(StackStreamFactory.java:1066) at java.lang.StackStreamFactory.(StackStreamFactory.java:71) at java.lang.Throwable.fillInStackTrace(Throwable.java:783) at java.lang.Throwable.(Throwable.java:251) at java.lang.Error.(Error.java:58) at java.lang.LinkageError.(LinkageError.java:45) at java.lang.IncompatibleClassChangeError.(IncompatibleClassChangeError.java:45) at sun.reflect.Reflection.(Reflection.java:48) at jdk.internal.misc.Unsafe.(Unsafe.java:52) at jdk.internal.misc.SharedSecrets.(SharedSecrets.java:45) at java.lang.ref.Reference.(Reference.java:237) -- -Alex From akashche at redhat.com Fri Jul 22 11:44:15 2016 From: akashche at redhat.com (Alex Kashchenko) Date: Fri, 22 Jul 2016 14:44:15 +0300 Subject: [9] RFC: aarch32 changes for JDK-8147461: Use byte offsets for vtable start and vtable length offsets Message-ID: <5792070F.8000205@redhat.com> Hi, This change is a part of the merge of aarch32-jdk9 with jdk-9+109 mainline tag. - mainline issue: https://bugs.openjdk.java.net/browse/JDK-8147461 - discussion thread: http://mail.openjdk.java.net/pipermail/hotspot-dev/2016-January/021416.html - aarch32 patch: http://cr.openjdk.java.net/~akasko/aarch32/jdk9/tag_109/aarch32_8147461.patch -- -Alex From snazarkin at azul.com Fri Jul 22 13:26:47 2016 From: snazarkin at azul.com (Sergey Nazarkin) Date: Fri, 22 Jul 2016 13:26:47 +0000 Subject: RFR: JDK-8162400: ProfileInterpreter crashes vm Message-ID: <50433475-DFE6-4CC0-BD0A-59D56E5F9BD8@azul.com> Hi! Please review the AARCH32 specific fix for vm crash when ProfileInterpreter is issued. Please note that bug [1] is still observed. issue: https://bugs.openjdk.java.net/browse/JDK-8162400 review: http://cr.openjdk.java.net/~snazarki/8162400/ [1] https://bugs.openjdk.java.net/browse/JDK-8068765 Sergey Nazarkin From akozlov at azul.com Fri Jul 22 16:55:47 2016 From: akozlov at azul.com (Anton Kozlov) Date: Fri, 22 Jul 2016 16:55:47 +0000 Subject: [8u] RFR: Fix trivial errors in aarch32: signed vs unsigned compare, constant not fit Message-ID: <1469206582.25784.46.camel@azul.com> Hi, All! Could you review next patch, which fixes trivial build errors found when compiling with gcc 4.4? It's in attach, for review convinience it's inlined here too. Thanks, Anton === PATCH START === diff -r d37140bc27f3 -r 7adc56f3c2e3 src/cpu/aarch32/vm/nativeInst_aarch32.cpp --- a/src/cpu/aarch32/vm/nativeInst_aarch32.cpp Wed Jul 20 18:57:34 2016 +0300 +++ b/src/cpu/aarch32/vm/nativeInst_aarch32.cpp Fri Jul 22 04:27:03 2016 +0300 @@ -492,7 +492,7 @@ ???bool a2 = Instruction_aarch32::extract(uint_at(0), 15, 12) == (unsigned)dst; ???bool a3 = Instruction_aarch32::extract(uint_at(0), 11, 0) == ((unsigned)imm & 0xfff); ???bool a4 = Instruction_aarch32::extract(uint_at(0), 19, 16) == ((unsigned)imm >> 12); -??bool a5 = Instruction_aarch32::extract(uint_at(0), 31, 28) == cond; +??bool a5 = Instruction_aarch32::extract(uint_at(0), 31, 28) == (unsigned)cond; ? ???return a1 && a2 && a3 && a4 && a5; ?} @@ -502,7 +502,7 @@ ???bool a2 = Instruction_aarch32::extract(uint_at(0), 15, 12) == (unsigned)dst; ???bool a3 = Instruction_aarch32::extract(uint_at(0), 11, 0) == ((unsigned)imm & 0xfff); ???bool a4 = Instruction_aarch32::extract(uint_at(0), 19, 16) == ((unsigned)imm >> 12); -??bool a5 = Instruction_aarch32::extract(uint_at(0), 31, 28) == cond; +??bool a5 = Instruction_aarch32::extract(uint_at(0), 31, 28) == (unsigned)cond; ? ???return a1 && a2 && a3 && a4 && a5; ?} @@ -525,7 +525,7 @@ ?????bool a3 = Instruction_aarch32::extract(uint_at(0), 20, 20) == 1; ?????bool a4 = Instruction_aarch32::extract(uint_at(0), 22, 22) == 0; ?????bool a5 = Instruction_aarch32::extract(uint_at(0), 27, 25) == 0b010; -????bool a6 = Instruction_aarch32::extract(uint_at(0), 31, 28) == cond; +????bool a6 = Instruction_aarch32::extract(uint_at(0), 31, 28) == (unsigned)cond; ? ?????return a1 && a2 && a3 && a4 && a5 && a6; ?} diff -r d37140bc27f3 -r 7adc56f3c2e3 src/os_cpu/linux_aarch32/vm/os_linux_aarch32.cpp --- a/src/os_cpu/linux_aarch32/vm/os_linux_aarch32.cpp??Wed Jul 20 18:57:34 2016 +0300 +++ b/src/os_cpu/linux_aarch32/vm/os_linux_aarch32.cpp??Fri Jul 22 04:27:03 2016 +0300 @@ -94,7 +94,7 @@ ???// even in its subfields (as defined by the CPU immediate fields, ???// if the CPU splits constants across multiple instructions). ? -??return (char*) 0xffffffffffff; +??return (char*) 0xfffffffful; ?} ? ?void os::initialize_thread(Thread *thr) { === PATCH END === -------------- next part -------------- A non-text attachment was scrubbed... Name: trivial_build_errors.patch Type: text/x-patch Size: 2450 bytes Desc: trivial_build_errors.patch URL: