From akozlov at azul.com Fri Apr 1 10:41:12 2016 From: akozlov at azul.com (Anton Kozlov) Date: Fri, 1 Apr 2016 10:41:12 +0000 Subject: [8u] RFR: nativeInstruction atomicity and correctness of patching In-Reply-To: <56FCE4A9.7080903@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> Message-ID: <1459507244.10845.197.camel@azul.com> 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. Looks so. flush_cache_user_range calls __cpuc_coherent_user_range, which does that. But going deeper, I will consider ARMv7. __cpuc_coherent_user_range is v7_coherent_user_range, which does Data cache clean DCCMVAU and Instruction cache invalidate ICIMVAU. By Table B2-2 of ARMv7 manual, ICIMVAU invalidates all CPUs (in shareabillity domain) icaches. (Multiprocessing extension should be available, without it inter-processor interrupt is really required, section B2.2.5) ICIMVAU and DCCMVAU used also in synchonization sequence in "Concurrent modification and execution of instructions (A3.5.4)". It's DCCMVAU [instruction location] ; Clean data cache by MVA to point of unification DSB ; Ensure visibility of the data cleaned from the cache ICIMVAU [instruction location] ; Invalidate instruction cache by MVA to PoU BPIMVAU [instruction location] ; Invalidate branch predictor by MVA to PoU DSB ; Ensure completion of the invalidations for modifying site and ISB ; Synchronize fetched instruction stream This explicitly names 2 concurrently executing threads. If DCCMVAU/ICIMVAU not affects other CPU cache, then the sequence works for 1 thread only. Did I misunderstand the manual? And as far as I understand, without this behavior of DCCMVAU/ICIMVAU executing site will have to flush own icache everytime it executes instructions that may be patched, and we clearly don't do this. However, in my kernel sources, there is no Data cache invalidation, but I hoped it should be. Without data cache invalidation, trampoline could load old call target regardless if __clear_cache called or not, so really useless here, you're right. But then inconsistency remain, changes in code are observable by other CPUs immediatelly, and changes in trampoline target is not. I'd call DCCIMVAC (Data Cache Clean and Invalidate), which should affect all processors in the same shareability domain (Table B2-1), but it's unavailable in user space. I replaced ICache::invalidate with FIXME in the patch and not sure what should be done here. > > But for me it looks like if we drop cache maintance in > > NativeTrampolineCall::set_destination_mt_safe, we'll get race > > condition, and some thread could call old destination. > > Yes. Some thread could indeed call the old destination, but the key > is that it doesn't matter: the old routines are not evicted from the > code cache until at a safepoint, so they can still be called. > Indeed, > they may still be running on some cores. And we patch out the first > instruction so that it traps. I care more about code modifiers, like Runtime1::patch_code. After taking Patching_lock, we are checking instr_pc. If we are 2nd thread that came after patching occured, but our dcache have stale value for instr_pc, then we'll perform the code patching again, and this is not good. Thanks, Anton -------------- next part -------------- A non-text attachment was scrubbed... Name: nativeInstrRe2.patch Type: text/x-patch Size: 13659 bytes Desc: nativeInstrRe2.patch URL: From akashche at redhat.com Fri Apr 1 12:23:42 2016 From: akashche at redhat.com (Alex Kashchenko) Date: Fri, 1 Apr 2016 13:23:42 +0100 Subject: [8u] RFR: nativeInstruction atomicity and correctness of patching In-Reply-To: <1459342792.10845.130.camel@azul.com> References: <1459342792.10845.130.camel@azul.com> Message-ID: <56FE684E.9040305@redhat.com> Hi, On 03/30/2016 02:00 PM, Anton Kozlov wrote: > Hi, All! > > Could you review a patch that should fix nativeInst in several aspects? > > * macroassembler trampoline_call generates code, which loads call > target from memory just after trampoline. That constant could be > patched atomically and in mt_safe way. NativeTrampolineCall class was > introduced. > > * NativeGeneralJump not falls to undefined behavior conditions now, > only imm branches swapped with imm branches. It used only by C1 > patching facultiles, so there should be no harm that the implementation > depends on C1 implementation. It is a part of C1 patching that triggers > deoptimisation on aarch64, http://mail.openjdk.java.net/pipermail/aarch > 64-port-dev/2013-September/000273.html. Note, that quote about > concurrent modification and execution in discussion applies to aarch32 > as well. > > * Atomic::store, Atomic::load for jlongs made really atomic. > > Sorry for missing testcase. Small addition for jdk9, this bit in nativeInst_aarch32.hpp: #ifdef ASSERT StaticAssert<(int) NativeTrampolineCall::instruction_size <= (int) instruction_size> dummy1; StaticAssert dummy2; #endif compiles fine in jdk8u, but should be changed for jdk9 due to JDK-8067306 changes: #ifdef ASSERT STATIC_ASSERT_FAILURE<(int) NativeTrampolineCall::instruction_size <= (int) instruction_size> dummy1; STATIC_ASSERT_FAILURE dummy2; #endif -- -Alex From akozlov at azul.com Fri Apr 1 12:36:54 2016 From: akozlov at azul.com (Anton Kozlov) Date: Fri, 1 Apr 2016 12:36:54 +0000 Subject: [8u] RFR: Remove stop in interpreter ForceEarlyExit Message-ID: <1459514186.10845.211.camel@azul.com> Hi, All, interpreter ForceEarlyExit contain stop("Not tested this") call. In attach there is sample demo consisted from app and agent. App throws exception and prints message when it catched and when finally block executed. Agent catches same exception from application, and calls ForceEarlyExit on active thread. When no agent attached, there should be such messages: about to throw... catch! finally! exiting... When agent attached, now jvm crashes with "Not tested this" message. After removing stop (patch in attach), everything should work as expected, I see such messages: Hello from agent about to throw... called callbackException 3! exiting... Since stop is only reason this test fails, let's delete it? Thanks, Anton -------------- next part -------------- A non-text attachment was scrubbed... Name: jvmti-force-early-exit.patch Type: text/x-patch Size: 478 bytes Desc: jvmti-force-early-exit.patch URL: From aph at redhat.com Fri Apr 1 12:51:13 2016 From: aph at redhat.com (Andrew Haley) Date: Fri, 1 Apr 2016 13:51:13 +0100 Subject: [8u] RFR: nativeInstruction atomicity and correctness of patching In-Reply-To: <1459507244.10845.197.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> Message-ID: <56FE6EC1.9090202@redhat.com> Hi, On 04/01/2016 11:41 AM, Anton Kozlov wrote: > ICIMVAU and DCCMVAU used also in synchonization sequence in "Concurrent > modification and execution of instructions (A3.5.4)". > It's > DCCMVAU [instruction location] ; Clean data cache by MVA to > point of unification > DSB ; Ensure visibility of the data cleaned from the cache > ICIMVAU [instruction location] ; Invalidate instruction cache > by MVA to PoU > BPIMVAU [instruction location] ; Invalidate branch predictor by > MVA to PoU > DSB ; Ensure completion of the invalidations > for modifying site and > ISB ; Synchronize fetched instruction stream > > This explicitly names 2 concurrently executing threads. If > DCCMVAU/ICIMVAU not affects other CPU cache, then the sequence works > for 1 thread only. Did I misunderstand the manual? I think so. When you modify instruction memory you must clean the local dcache and then broadcast the icache clean message to all other cores. But they also must do some kind of memory barrier and ISB to update their local caches. > And as far as I understand, without this behavior of DCCMVAU/ICIMVAU > executing site will have to flush own icache everytime it executes > instructions that may be patched, and we clearly don't do this. I think we do enough. We evacuate the code cache at a safepoint, which is a synchronization event. Newly-generated code shouldn't be in anyone's icache, so isn't a problem. (By the way, I have recently discussed with an ARM engineer, and we think it's OK. However, he's going to discuss it with the architecture people to be sure.) > However, in my kernel sources, there is no Data cache invalidation, > but I hoped it should be. Data cache invalidation syncs the local cache with shared memory. It does not affect any other core's data cache. Other cores may still read stale data until they do some kind of memory barrier. > Without data cache invalidation, trampoline could load old call > target regardless if __clear_cache called or not, so really useless > here, you're right. That's right. And it doesn't matter. > I care more about code modifiers, like Runtime1::patch_code. After > taking Patching_lock, we are checking instr_pc. If we are 2nd thread > that came after patching occured, but our dcache have stale value > for instr_pc, then we'll perform the code patching again, and this > is not good. It's harmless IMO. Andrew. From akozlov at azul.com Fri Apr 1 13:01:19 2016 From: akozlov at azul.com (Anton Kozlov) Date: Fri, 1 Apr 2016 13:01:19 +0000 Subject: [8u] RFR: not use rthread as temporary in MethodHandle Message-ID: <1459515651.10845.230.camel@azul.com> Hi, All! MethodHandle uses r8 (rthread) as temporary register and not restores it after. This is the reason jtreg java/lang/invoke/PrivateInvokeTest.java failed in release mode with such message: # A fatal error has been detected by the Java Runtime Environment: # # SIGSEGV (0xb) at pc=0x75568878, pid=471, tid=1675060320 # # JRE version: OpenJDK Runtime Environment (8.0_60-b99) (build 1.8.0_60 -internal-b99) # Java VM: OpenJDK Client VM (25.60-b23 mixed mode linux-aarch32 ) # Problematic frame: # V [libjvm.so+0x129878] GrowableArray::append(Metadata* const&)+0x8 # I suggest just to not use rthread as temporary. Registers r5-r7 seems to be fine as temporary registers, as they holds cached values in interpreter mode and will be restored on enter to interpreter; and they are callee-saved and can't hold arguments in compiled/native calling conventions (however, r4 used in critical native code, so r5 is first). Thanks, Anton From jvanek at redhat.com Fri Apr 1 13:05:20 2016 From: jvanek at redhat.com (Jiri Vanek) Date: Fri, 1 Apr 2016 15:05:20 +0200 Subject: [REF] more often tagging or syncing with upstream In-Reply-To: <56F12D8D.3030206@redhat.com> References: <56EAE706.1000106@redhat.com> <45673724.10758208.1458235548198.JavaMail.zimbra@redhat.com> <56F12D8D.3030206@redhat.com> Message-ID: <56FE7210.5040401@redhat.com> On 03/22/2016 12:33 PM, Jiri Vanek wrote: > On 03/17/2016 06:25 PM, Andrew Hughes wrote: > > Ping? Ping ping? This would really help a lot! See laready runnign review: https://bugzilla.redhat.com/show_bug.cgi?id=1318988#c18 > > FYI - https://bugzilla.redhat.com/show_bug.cgi?id=1318988 I already started the wheels of destiny, and I'm pretty sure the not-reproducible tarball will be the reelase blocker :( > > J. >> ----- Original Message ----- >>> Hello! >>> >>> I would like to introduce the aarch32 project to Fedora arm repositories. >>> To create clearly reproducible source tarball I need some anchor. >>> I think you will agree that cloning "tip" do not cover the reproducibility. >>> Also I think you will agree that keeping somewhere list of changset ids used >>> for source tarball is >>> not exactly convenient. >>> >>> So I would like to kindly ask you for favour and to tag your project forest >>> once per day or at least >>> once per week or just when things look little bit more stable then yesterday >>> (eg tomorrow:) ) >>> >>> We had chosen this approach for aarch64 releases [1] by prefixing by >>> "aarch64" and incrementing >>> build. As upstream builds are not exactly continuous, it works fine. But of >>> course feel free to >>> chose whatever suits you. >>> >>> I think that having small fedora arm32 community in testing audience may be >>> just benefit for project. >>> >>> Thank you in advance! >>> >>> J. >>> >>> >>> >>> [1] >>> http://hg.openjdk.java.net/aarch64-port/jdk8u/ >>> 2 weeks ago andrew Added tag aarch64-jdk8u72-b16 for changeset >>> 92af9369869fdefault tip >>> 7 weeks ago andrew Added tag aarch64-jdk8u72-b15 for changeset >>> 618f7e7b68f4aarch64-jdk8u72-b16 >>> 7 weeks ago andrew Merge jdk8u72-b15aarch64-jdk8u72-b15 >>> 2 months ago asaha Merge >>> >>> >> >> I don't think it needs to be as often as "once per day" as I doubt >> the RPMs will be updated that frequently. It would however be good > > sure > >> to have a known good point to base Fedora RPMs on. This is beneficial >> to the AArch32 project as well, as it is then clear what is being used >> by these binaries out in the wild. >> >> Thanks, >> > From akozlov at azul.com Fri Apr 1 13:07:47 2016 From: akozlov at azul.com (Anton Kozlov) Date: Fri, 1 Apr 2016 13:07:47 +0000 Subject: [8u] RFR: not use rthread as temporary in MethodHandle In-Reply-To: <1459515651.10845.230.camel@azul.com> References: <1459515651.10845.230.camel@azul.com> Message-ID: <1459516039.10845.232.camel@azul.com> Missing patch attached, sorry, Anton On Fri, 2016-04-01 at 13:01 +0000, Anton Kozlov wrote: > Hi, All! > > MethodHandle uses r8 (rthread) as temporary register and not restores > it after. This is the reason jtreg > java/lang/invoke/PrivateInvokeTest.java failed in release mode with > such message: > > # A fatal error has been detected by the Java Runtime Environment: > # > # SIGSEGV (0xb) at pc=0x75568878, pid=471, tid=1675060320 > # > # JRE version: OpenJDK Runtime Environment (8.0_60-b99) (build > 1.8.0_60 > -internal-b99) > # Java VM: OpenJDK Client VM (25.60-b23 mixed mode linux-aarch32 ) > # Problematic frame: > # V [libjvm.so+0x129878] GrowableArray::append(Metadata* > const&)+0x8 > # > > I suggest just to not use rthread as temporary. Registers r5-r7 seems > to be fine as temporary registers, as they holds cached values in > interpreter mode and will be restored on enter to interpreter; and > they > are callee-saved and can't hold arguments in compiled/native calling > conventions (however, r4 used in critical native code, so r5 is > first). > > Thanks, > Anton -------------- next part -------------- A non-text attachment was scrubbed... Name: methodHandle.patch Type: text/x-patch Size: 1206 bytes Desc: methodHandle.patch URL: From akashche at redhat.com Fri Apr 1 13:44:00 2016 From: akashche at redhat.com (Alex Kashchenko) Date: Fri, 01 Apr 2016 14:44:00 +0100 Subject: [8u] RFR: assembler canonical modified imm encoding In-Reply-To: References: Message-ID: <56FE7B20.1020005@redhat.com> Hi, On 03/30/2016 09:23 PM, Anton Kozlov wrote: > Hi, All! > > In 'prec1' commit, modified imm encoding was changed to use constant amount of time for any immediate. > Sadly, new encoding became not canonical i.e. rotate value may be not minimal as possible, which is not recommended, but allowed by ARM. Start of -XX:+PrintInterpreter looks like > 0x72df8320: mov r3, sp > 0x72df8324: sub sp, sp, #88 ; 0x58 > 0x72df8328: str lr, [sp] > 0x72df832c: mov r2, r6 > 0x72df8330: mov r1, sl > 0x72df8334: str r5, [fp, #-32] ; 0xffffffe0 > 0x72df8338: ldr r9, [fp, #-12] > 0x72df833c: cmp r9, #0, 8 > 0x72df8340: beq 0x72df8374 > 0x72df8344: push {r0, r1, r2, r3, r4, r5, r6, r7, r8, r9, sl, fp, ip, lr} > 0x72df8348: add ip, sp, #224, 2 ; 0x38 > 0x72df834c: push {ip} ; (str ip, [sp, #-4]!) > 0x72df8350: movw r0, #33092 ; 0x8144 > 0x72df8354: movt r0, #30085 ; 0x7585 > 0x72df8358: mov r1, pc > 0x72df835c: sub r1, r1, #128, 4 > > Note instructions like > 0x72df833c: cmp r9, #0, 8 // zero encoded as 0 rotated at 8. > > The patch restores recommended encoding (still constant time encoding), after applying listing looks like > 0x72dae320: mov r3, sp > 0x72dae324: sub sp, sp, #88 ; 0x58 > 0x72dae328: str lr, [sp] > 0x72dae32c: mov r2, r6 > 0x72dae330: mov r1, sl > 0x72dae334: str r5, [fp, #-32] ; 0xffffffe0 > 0x72dae338: ldr r9, [fp, #-12] > 0x72dae33c: cmp r9, #0 > 0x72dae340: beq 0x72dae374 > 0x72dae344: push {r0, r1, r2, r3, r4, r5, r6, r7, r8, r9, sl, fp, ip, lr} > 0x72dae348: add ip, sp, #56 ; 0x38 > 0x72dae34c: push {ip} ; (str ip, [sp, #-4]!) > 0x72dae350: movw r0, #45548 ; 0xb1ec > 0x72dae354: movt r0, #30080 ; 0x7580 > 0x72dae358: mov r1, pc > 0x72dae35c: sub r1, r1, #8 > > Sorry for temporary inconvenience in debugging. Happy hacking again! For what it's worth, commented part of the change (first 3 hunks - commented aarch32ops disassembly) cannot be applied cleanly (looks like the whitespaces problem). Other part applies and compiles fine. -- -Alex From akozlov at azul.com Fri Apr 1 14:49:48 2016 From: akozlov at azul.com (Anton Kozlov) Date: Fri, 1 Apr 2016 14:49:48 +0000 Subject: [8u] RFR: assembler canonical modified imm encoding In-Reply-To: <56FE7B20.1020005@redhat.com> References: <56FE7B20.1020005@redhat.com> Message-ID: <1459522159.10845.236.camel@azul.com> Hi, Alex, you're right, seems that I sent wrong patch, new one with corrected whitespaces in attach. Thanks, Anton On Fri, 2016-04-01 at 14:44 +0100, Alex Kashchenko wrote: > Hi, > > On 03/30/2016 09:23 PM, Anton Kozlov wrote: > > Hi, All! > > > > In 'prec1' commit, modified imm encoding was changed to use > > constant amount of time for any immediate. > > Sadly, new encoding became not canonical i.e. rotate value may be > > not minimal as possible, which is not recommended, but allowed by > > ARM. Start of -XX:+PrintInterpreter looks like > > 0x72df8320: mov r3, sp > > 0x72df8324: sub sp, sp, #88 ; 0x58 > > 0x72df8328: str lr, [sp] > > 0x72df832c: mov r2, r6 > > 0x72df8330: mov r1, sl > > 0x72df8334: str r5, [fp, #-32] ; 0xffffffe0 > > 0x72df8338: ldr r9, [fp, #-12] > > 0x72df833c: cmp r9, #0, 8 > > 0x72df8340: beq 0x72df8374 > > 0x72df8344: push {r0, r1, r2, r3, r4, r5, r6, r7, r8, r9, > > sl, fp, ip, lr} > > 0x72df8348: add ip, sp, #224, 2 ; 0x38 > > 0x72df834c: push {ip} ; (str ip, [sp, #-4]!) > > 0x72df8350: movw r0, #33092 ; 0x8144 > > 0x72df8354: movt r0, #30085 ; 0x7585 > > 0x72df8358: mov r1, pc > > 0x72df835c: sub r1, r1, #128, 4 > > > > Note instructions like > > 0x72df833c: cmp r9, #0, 8 // zero encoded as 0 rotated at > > 8. > > > > The patch restores recommended encoding (still constant time > > encoding), after applying listing looks like > > 0x72dae320: mov r3, sp > > 0x72dae324: sub sp, sp, #88 ; 0x58 > > 0x72dae328: str lr, [sp] > > 0x72dae32c: mov r2, r6 > > 0x72dae330: mov r1, sl > > 0x72dae334: str r5, [fp, #-32] ; 0xffffffe0 > > 0x72dae338: ldr r9, [fp, #-12] > > 0x72dae33c: cmp r9, #0 > > 0x72dae340: beq 0x72dae374 > > 0x72dae344: push {r0, r1, r2, r3, r4, r5, r6, r7, r8, r9, > > sl, fp, ip, lr} > > 0x72dae348: add ip, sp, #56 ; 0x38 > > 0x72dae34c: push {ip} ; (str ip, [sp, #-4]!) > > 0x72dae350: movw r0, #45548 ; 0xb1ec > > 0x72dae354: movt r0, #30080 ; 0x7580 > > 0x72dae358: mov r1, pc > > 0x72dae35c: sub r1, r1, #8 > > > > Sorry for temporary inconvenience in debugging. Happy hacking > > again! > > For what it's worth, commented part of the change (first 3 hunks - > commented aarch32ops disassembly) cannot be applied cleanly (looks > like > the whitespaces problem). Other part applies and compiles fine. > > -------------- next part -------------- A non-text attachment was scrubbed... Name: imm-canon2.patch Type: text/x-patch Size: 6197 bytes Desc: imm-canon2.patch URL: From akozlov at azul.com Fri Apr 1 18:12:42 2016 From: akozlov at azul.com (Anton Kozlov) Date: Fri, 1 Apr 2016 18:12:42 +0000 Subject: [8u] RFR: nativeInstruction atomicity and correctness of patching In-Reply-To: <56FE6EC1.9090202@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> <56FE6EC1.9090202@redhat.com> Message-ID: <1459534334.10845.274.camel@azul.com> Hi, Life is simplier if we allow stale code observed. Then, we really not have to care about Multiprocessing Extensions, their presence and their affects on cache maintance operations. Thanks for responses! PS. I can't agree with some statements bellow, so I've added a couple of notes inline. Sorry if it's became offtopic. Thanks, Anton On Fri, 2016-04-01 at 13:51 +0100, Andrew Haley wrote: > Hi, > > On 04/01/2016 11:41 AM, Anton Kozlov wrote: > > ICIMVAU and DCCMVAU used also in synchonization sequence in > > "Concurrent > > modification and execution of instructions (A3.5.4)". > > It's > > DCCMVAU [instruction location] ; Clean data cache by MVA to > > point of unification > > DSB ; Ensure visibility of the data cleaned from the cache > > ICIMVAU [instruction location] ; Invalidate instruction > > cache > > by MVA to PoU > > BPIMVAU [instruction location] ; Invalidate branch > > predictor by > > MVA to PoU > > DSB ; Ensure completion of the invalidations > > for modifying site and > > ISB ; Synchronize fetched instruction stream > > > > This explicitly names 2 concurrently executing threads. If > > DCCMVAU/ICIMVAU not affects other CPU cache, then the sequence > > works > > for 1 thread only. Did I misunderstand the manual? > > I think so. When you modify instruction memory you must clean the > local dcache and then broadcast the icache clean message to all other > cores. But they also must do some kind of memory barrier and ISB to > update their local caches. As far as I understand, icache clean from modifying site will be applied eventually, regardless of barrier like dmb or dsb presence on executing site, and new instructions will be loaded from memory. Barrier will only stop the execution till clean be finished. It's required in general, if we have strict dependency on instruction modifications order, of course. > > And as far as I understand, without this behavior of > > DCCMVAU/ICIMVAU > > executing site will have to flush own icache everytime it executes > > instructions that may be patched, and we clearly don't do this. > > I think we do enough. We evacuate the code cache at a safepoint, > which is a synchronization event. Newly-generated code shouldn't be > in anyone's icache, so isn't a problem. > > (By the way, I have recently discussed with an ARM engineer, and we > think it's OK. However, he's going to discuss it with the > architecture > people to be sure.) > > > However, in my kernel sources, there is no Data cache invalidation, > > but I hoped it should be. > > Data cache invalidation syncs the local cache with shared memory. It > does not affect any other core's data cache. Other cores may still > read stale data until they do some kind of memory barrier. This is true in general, but I beleive that we could in theory invalidate other CPU dcache, if we have Multiprocessing Extensions implemented. Cite from "Effect of the Multiprocessing Extensions on operations to the point of coherency" section: The Multiprocessing Extensions add requirements for the scope of the following operations, that affect data and unified caches to the point of coherency: * invalidate data, or unified, cache line by MVA to the point of coherency, DCIMVAC For Normal memory that is not Inner Non-cacheable, Outer Non -cacheable, these instructions must affect the caches of other processors in the shareability domain described by the shareability attributes of the MVA supplied with the operation. It's unavailable in userspace on linux, however. > > Without data cache invalidation, trampoline could load old call > > target regardless if __clear_cache called or not, so really useless > > here, you're right. > > That's right. And it doesn't matter. > > > I care more about code modifiers, like Runtime1::patch_code. After > > taking Patching_lock, we are checking instr_pc. If we are 2nd > > thread > > that came after patching occured, but our dcache have stale value > > for instr_pc, then we'll perform the code patching again, and this > > is not good. > > It's harmless IMO. > > Andrew. From edward.nevill at gmail.com Sat Apr 2 07:25:25 2016 From: edward.nevill at gmail.com (Edward Nevill) Date: Sat, 2 Apr 2016 08:25:25 +0100 Subject: [REF] more often tagging or syncing with upstream In-Reply-To: <56FE7210.5040401@redhat.com> References: <56EAE706.1000106@redhat.com> <45673724.10758208.1458235548198.JavaMail.zimbra@redhat.com> <56F12D8D.3030206@redhat.com> <56FE7210.5040401@redhat.com> Message-ID: On 1 Apr 2016 14:05, "Jiri Vanek" wrote: > > On 03/22/2016 12:33 PM, Jiri Vanek wrote: >> >> On 03/17/2016 06:25 PM, Andrew Hughes wrote: >> >> Ping? > > > Ping ping? This would really help a lot! > > Hi, I am on holiday in Wales at the moment. I have no objections to the repo being tagged as required for RedHat releases. Andrew Haley: Could you tag the tree as it a little difficult for me as my internet is limited. Atb Ed From edward.nevill at gmail.com Tue Apr 5 09:08:50 2016 From: edward.nevill at gmail.com (Edward Nevill) Date: Tue, 05 Apr 2016 10:08:50 +0100 Subject: Using apcs frame layout In-Reply-To: <1459331330.10845.120.camel@azul.com> References: <1458913301.10845.24.camel@azul.com> <56F6D201.5010206@redhat.com> <1459151380.10845.64.camel@azul.com> <56F8F757.7010105@redhat.com> <1459158284.10845.76.camel@azul.com> <56FA5396.2060608@redhat.com> <1459249962.10845.96.camel@azul.com> <56FA8D02.9070309@redhat.com> <1459273695.10845.98.camel@azul.com> <56FB880E.5090709@redhat.com> <1459331330.10845.120.camel@azul.com> Message-ID: <1459847330.27492.24.camel@mylittlepony.linaroharston> Hi, Was there a conclusion on this? I am happy with a -XX:+APCSFrame or somesuch if it is the most expedient way of allowing perf / flame graphs provided that the code can be reasonably well contain and doesn't affect shared code. All the best, Ed. On Wed, 2016-03-30 at 09:49 +0000, Anton Kozlov wrote: > Hi, > > yes, unwind works because whole java uses standart layout. Perf > captures stacktraces in kernel mode, where no dwarf info available, and > standart layout assumed. > > GCC forced to generate standart layout for hotspot, -fno-omit-frame > -pointer used on linux platform and amd64 cpu > (hotspot/make/solaris/makefiles/amd64.make, > hotspot/make/linux/makefiles/gcc.make). > JNI code have to be compiled with -fno-omit-frame-pointer too, > otherwise perf can't catch proper stacktrace. > And java code uses standart layout. > > So, for java, dwarf info isn't used at all. > > Thanks, > Anton > > On Wed, 2016-03-30 at 09:02 +0100, Andrew Haley wrote: > > On 29/03/16 18:48, Anton Kozlov wrote: > > > Sorry, not quite undestand you, what can we do? Add apcs layout > > > option? > > > > I'm not sure exactly. Let me ask a clarifying question: with > > x86-64, how do flame graphs work with Java? Is it that Java > > uses the standard frame layout throughout? But x86-64 doesn't > > use a standard frame layout in GCC. It uses DWARF unwinder > > data. So how does x86-64 OpenJDK work with flame graphs? > > > > Andrew. > > > > From edward.nevill at gmail.com Tue Apr 5 09:25:44 2016 From: edward.nevill at gmail.com (Edward Nevill) Date: Tue, 05 Apr 2016 10:25:44 +0100 Subject: [8u] RFR: nativeInstruction atomicity and correctness of patching In-Reply-To: <1459507244.10845.197.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> Message-ID: <1459848344.27492.27.camel@mylittlepony.linaroharston> 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 Apr 5 10:02:25 2016 From: akozlov at azul.com (Anton Kozlov) Date: Tue, 5 Apr 2016 10:02:25 +0000 Subject: Using apcs frame layout In-Reply-To: <1459847330.27492.24.camel@mylittlepony.linaroharston> References: <1458913301.10845.24.camel@azul.com> <56F6D201.5010206@redhat.com> <1459151380.10845.64.camel@azul.com> <56F8F757.7010105@redhat.com> <1459158284.10845.76.camel@azul.com> <56FA5396.2060608@redhat.com> <1459249962.10845.96.camel@azul.com> <56FA8D02.9070309@redhat.com> <1459273695.10845.98.camel@azul.com> <56FB880E.5090709@redhat.com> <1459331330.10845.120.camel@azul.com> <1459847330.27492.24.camel@mylittlepony.linaroharston> Message-ID: <1459850516.10845.302.camel@azul.com> Hi, Ed, For me it looks like there is no objections, I'm preparing for implementation. I will try to do it the cleanest way possible, there are no reasons to modify shared code. Thanks, Anton On Tue, 2016-04-05 at 10:08 +0100, Edward Nevill wrote: > Hi, > > Was there a conclusion on this? > > I am happy with a -XX:+APCSFrame or somesuch if it is the most > expedient way of allowing perf / flame graphs provided that the code > can be reasonably well contain and doesn't affect shared code. > > All the best, > Ed. > > On Wed, 2016-03-30 at 09:49 +0000, Anton Kozlov wrote: > > Hi, > > > > yes, unwind works because whole java uses standart layout. Perf > > captures stacktraces in kernel mode, where no dwarf info available, > > and > > standart layout assumed. > > > > GCC forced to generate standart layout for hotspot, -fno-omit-frame > > -pointer used on linux platform and amd64 cpu > > (hotspot/make/solaris/makefiles/amd64.make, > > hotspot/make/linux/makefiles/gcc.make). > > JNI code have to be compiled with -fno-omit-frame-pointer too, > > otherwise perf can't catch proper stacktrace. > > And java code uses standart layout. > > > > So, for java, dwarf info isn't used at all. > > > > Thanks, > > Anton > > > > On Wed, 2016-03-30 at 09:02 +0100, Andrew Haley wrote: > > > On 29/03/16 18:48, Anton Kozlov wrote: > > > > Sorry, not quite undestand you, what can we do? Add apcs layout > > > > option? > > > > > > I'm not sure exactly. Let me ask a clarifying question: with > > > x86-64, how do flame graphs work with Java? Is it that Java > > > uses the standard frame layout throughout? But x86-64 doesn't > > > use a standard frame layout in GCC. It uses DWARF unwinder > > > data. So how does x86-64 OpenJDK work with flame graphs? > > > > > > Andrew. > > > > > > > > From edward.nevill at gmail.com Tue Apr 5 10:05:49 2016 From: edward.nevill at gmail.com (edward.nevill at gmail.com) Date: Tue, 05 Apr 2016 10:05:49 +0000 Subject: hg: aarch32-port/jdk8u/hotspot: 4 new changesets Message-ID: <201604051005.u35A5otA022885@aojmv0008.oracle.com> Changeset: 95ad4f39d1c3 Author: enevill Date: 2016-04-05 09:12 +0100 URL: http://hg.openjdk.java.net/aarch32-port/jdk8u/hotspot/rev/95ad4f39d1c3 8153493: aarch32: assembler generates non canonical form for mov imm instructions Reviewed-by: enevill Contributed-by: akozlov at azul.com ! src/cpu/aarch32/vm/assembler_aarch32.cpp Changeset: e83061931aee Author: enevill Date: 2016-04-05 09:18 +0100 URL: http://hg.openjdk.java.net/aarch32-port/jdk8u/hotspot/rev/e83061931aee 8153495: aarch32: remove redundant "Not tested this message" Reviewed-by: enevill Contributed-by: akozlov at azul.com ! src/cpu/aarch32/vm/templateInterpreter_aarch32.cpp Changeset: 633e95b3b94b Author: enevill Date: 2016-04-05 09:27 +0100 URL: http://hg.openjdk.java.net/aarch32-port/jdk8u/hotspot/rev/633e95b3b94b 8153496: aarch32: rthread corrupted in method handle dispatch Reviewed-by: enevill Contributed-by: akozlov at azul.com ! src/cpu/aarch32/vm/methodHandles_aarch32.cpp Changeset: 721c34089be7 Author: enevill Date: 2016-04-05 09:37 +0100 URL: http://hg.openjdk.java.net/aarch32-port/jdk8u/hotspot/rev/721c34089be7 8153497: aarch32: implement special case of moving +0.0 to double register Reviewed-by: enevill Contributed-by: fedor.burdun at azulsystems.com ! src/cpu/aarch32/vm/assembler_aarch32.cpp ! src/cpu/aarch32/vm/assembler_aarch32.hpp ! src/cpu/aarch32/vm/icache_aarch32.cpp ! src/cpu/aarch32/vm/templateTable_aarch32.cpp ! src/cpu/aarch32/vm/vm_version_aarch32.cpp ! src/cpu/aarch32/vm/vm_version_aarch32.hpp From edward.nevill at gmail.com Tue Apr 5 10:27:21 2016 From: edward.nevill at gmail.com (Edward Nevill) Date: Tue, 05 Apr 2016 11:27:21 +0100 Subject: [REF] more often tagging or syncing with upstream In-Reply-To: <56FE7210.5040401@redhat.com> References: <56EAE706.1000106@redhat.com> <45673724.10758208.1458235548198.JavaMail.zimbra@redhat.com> <56F12D8D.3030206@redhat.com> <56FE7210.5040401@redhat.com> Message-ID: <1459852041.3488.1.camel@mylittlepony.linaroharston> OK. I tried tagging the tree with jdk8u76-b00-aarch32-160405 But I get (trusty)ed at localhost:/work/ed/aarch32/jdk8u/hotspot$ hg push pushing to ssh://enevill at hg.openjdk.java.net/aarch32-port/jdk8u/hotspot running ssh enevill at hg.openjdk.java.net 'hg -R aarch32-port/jdk8u/hotspot serve --stdio' searching for changes 1 changesets found remote: adding changesets remote: adding manifests remote: adding file changes remote: added 1 changesets with 1 changes to 1 files remote: [jcheck d46eaf84b346 2015-12-01 13:15:54 -0800] remote: remote: Illegal tag name: jdk8u76-b00-aarch32-160405 remote: remote: transaction abort! remote: rollback completed remote: abort: pretxnchangegroup.0.jcheck hook failed So, it seems like there are upstream restrictions on the tags we can use. Does anyone know the correct syntax of a tag? All the best, Ed. On Fri, 2016-04-01 at 15:05 +0200, Jiri Vanek wrote: > On 03/22/2016 12:33 PM, Jiri Vanek wrote: > > On 03/17/2016 06:25 PM, Andrew Hughes wrote: > > > > Ping? > > Ping ping? This would really help a lot! > > See laready runnign review: https://bugzilla.redhat.com/show_bug.cgi?id=1318988#c18 > > > > > FYI - https://bugzilla.redhat.com/show_bug.cgi?id=1318988 I already started the wheels of destiny, and I'm pretty sure the not-reproducible tarball will be the reelase blocker :( > > > > J. > >> ----- Original Message ----- > >>> Hello! > >>> > >>> I would like to introduce the aarch32 project to Fedora arm repositories. > >>> To create clearly reproducible source tarball I need some anchor. > >>> I think you will agree that cloning "tip" do not cover the reproducibility. > >>> Also I think you will agree that keeping somewhere list of changset ids used > >>> for source tarball is > >>> not exactly convenient. > >>> > >>> So I would like to kindly ask you for favour and to tag your project forest > >>> once per day or at least > >>> once per week or just when things look little bit more stable then yesterday > >>> (eg tomorrow:) ) > >>> > >>> We had chosen this approach for aarch64 releases [1] by prefixing by > >>> "aarch64" and incrementing > >>> build. As upstream builds are not exactly continuous, it works fine. But of > >>> course feel free to > >>> chose whatever suits you. > >>> > >>> I think that having small fedora arm32 community in testing audience may be > >>> just benefit for project. > >>> > >>> Thank you in advance! > >>> > >>> J. > >>> > >>> > >>> > >>> [1] > >>> http://hg.openjdk.java.net/aarch64-port/jdk8u/ > >>> 2 weeks ago andrew Added tag aarch64-jdk8u72-b16 for changeset > >>> 92af9369869fdefault tip > >>> 7 weeks ago andrew Added tag aarch64-jdk8u72-b15 for changeset > >>> 618f7e7b68f4aarch64-jdk8u72-b16 > >>> 7 weeks ago andrew Merge jdk8u72-b15aarch64-jdk8u72-b15 > >>> 2 months ago asaha Merge > >>> > >>> > >> > >> I don't think it needs to be as often as "once per day" as I doubt > >> the RPMs will be updated that frequently. It would however be good > > > > sure > > > >> to have a known good point to base Fedora RPMs on. This is beneficial > >> to the AArch32 project as well, as it is then clear what is being used > >> by these binaries out in the wild. > >> > >> Thanks, > >> > > > From snazarkin at azul.com Tue Apr 5 10:34:41 2016 From: snazarkin at azul.com (Sergey Nazarkin) Date: Tue, 5 Apr 2016 10:34:41 +0000 Subject: [REF] more often tagging or syncing with upstream In-Reply-To: <1459852041.3488.1.camel@mylittlepony.linaroharston> References: <56EAE706.1000106@redhat.com> <45673724.10758208.1458235548198.JavaMail.zimbra@redhat.com> <56F12D8D.3030206@redhat.com> <56FE7210.5040401@redhat.com> <1459852041.3488.1.camel@mylittlepony.linaroharston> Message-ID: here is regexp from jcheck "tip$|jdk-([1-9]([0-9]*)(\.[0-9]){0,3})\+([0-9]+)$|jdk[4-9]( u\d{1,3})?-b\d{2,3}$|hs\d\d(\.\d{1,2})?-b\d\d$? as I can see it doesn?t accept port name and date. Sergey Nazarkin > On 05 Apr 2016, at 13:27, Edward Nevill wrote: > > OK. I tried tagging the tree with > > jdk8u76-b00-aarch32-160405 > > But I get > > (trusty)ed at localhost:/work/ed/aarch32/jdk8u/hotspot$ hg push > pushing to ssh://enevill at hg.openjdk.java.net/aarch32-port/jdk8u/hotspot > running ssh enevill at hg.openjdk.java.net 'hg -R aarch32-port/jdk8u/hotspot serve --stdio' > searching for changes > 1 changesets found > remote: adding changesets > remote: adding manifests > remote: adding file changes > remote: added 1 changesets with 1 changes to 1 files > remote: [jcheck d46eaf84b346 2015-12-01 13:15:54 -0800] > remote: > remote: Illegal tag name: jdk8u76-b00-aarch32-160405 > remote: > remote: transaction abort! > remote: rollback completed > remote: abort: pretxnchangegroup.0.jcheck hook failed > > So, it seems like there are upstream restrictions on the tags we can use. > > Does anyone know the correct syntax of a tag? > > All the best, > Ed. > > > On Fri, 2016-04-01 at 15:05 +0200, Jiri Vanek wrote: >> On 03/22/2016 12:33 PM, Jiri Vanek wrote: >>> On 03/17/2016 06:25 PM, Andrew Hughes wrote: >>> >>> Ping? >> >> Ping ping? This would really help a lot! >> >> See laready runnign review: https://bugzilla.redhat.com/show_bug.cgi?id=1318988#c18 >> >>> >>> FYI - https://bugzilla.redhat.com/show_bug.cgi?id=1318988 I already started the wheels of destiny, and I'm pretty sure the not-reproducible tarball will be the reelase blocker :( >>> >>> J. >>>> ----- Original Message ----- >>>>> Hello! >>>>> >>>>> I would like to introduce the aarch32 project to Fedora arm repositories. >>>>> To create clearly reproducible source tarball I need some anchor. >>>>> I think you will agree that cloning "tip" do not cover the reproducibility. >>>>> Also I think you will agree that keeping somewhere list of changset ids used >>>>> for source tarball is >>>>> not exactly convenient. >>>>> >>>>> So I would like to kindly ask you for favour and to tag your project forest >>>>> once per day or at least >>>>> once per week or just when things look little bit more stable then yesterday >>>>> (eg tomorrow:) ) >>>>> >>>>> We had chosen this approach for aarch64 releases [1] by prefixing by >>>>> "aarch64" and incrementing >>>>> build. As upstream builds are not exactly continuous, it works fine. But of >>>>> course feel free to >>>>> chose whatever suits you. >>>>> >>>>> I think that having small fedora arm32 community in testing audience may be >>>>> just benefit for project. >>>>> >>>>> Thank you in advance! >>>>> >>>>> J. >>>>> >>>>> >>>>> >>>>> [1] >>>>> http://hg.openjdk.java.net/aarch64-port/jdk8u/ >>>>> 2 weeks ago andrew Added tag aarch64-jdk8u72-b16 for changeset >>>>> 92af9369869fdefault tip >>>>> 7 weeks ago andrew Added tag aarch64-jdk8u72-b15 for changeset >>>>> 618f7e7b68f4aarch64-jdk8u72-b16 >>>>> 7 weeks ago andrew Merge jdk8u72-b15aarch64-jdk8u72-b15 >>>>> 2 months ago asaha Merge >>>>> >>>>> >>>> >>>> I don't think it needs to be as often as "once per day" as I doubt >>>> the RPMs will be updated that frequently. It would however be good >>> >>> sure >>> >>>> to have a known good point to base Fedora RPMs on. This is beneficial >>>> to the AArch32 project as well, as it is then clear what is being used >>>> by these binaries out in the wild. >>>> >>>> Thanks, From andrey.petushkov at gmail.com Tue Apr 5 16:06:35 2016 From: andrey.petushkov at gmail.com (Andrey Petushkov) Date: Tue, 5 Apr 2016 19:06:35 +0300 Subject: [REF] more often tagging or syncing with upstream In-Reply-To: <1459852041.3488.1.camel@mylittlepony.linaroharston> References: <56EAE706.1000106@redhat.com> <45673724.10758208.1458235548198.JavaMail.zimbra@redhat.com> <56F12D8D.3030206@redhat.com> <56FE7210.5040401@redhat.com> <1459852041.3488.1.camel@mylittlepony.linaroharston> Message-ID: <562E7B79-2BEA-4B84-884A-42AAF92D8561@gmail.com> Hi Ed, One question, if you don?t mind. I see you use u76 in the label, but it looks to me that the state of the repo mostly resembles the u60. May I presume there are plans to update the repo to u76 state some time soon? How you plan for aarch32 project to keep up with mainline progress? On Azul side we still using u60 as a baseline but feel we got to update soon, so it would be nice to minimise the discrepancy between our codebases Great thanks, Andrey > On 05 Apr 2016, at 13:27, Edward Nevill wrote: > > OK. I tried tagging the tree with > > jdk8u76-b00-aarch32-160405 > > But I get > > (trusty)ed at localhost:/work/ed/aarch32/jdk8u/hotspot$ hg push > pushing to ssh://enevill at hg.openjdk.java.net/aarch32-port/jdk8u/hotspot > running ssh enevill at hg.openjdk.java.net 'hg -R aarch32-port/jdk8u/hotspot serve --stdio' > searching for changes > 1 changesets found > remote: adding changesets > remote: adding manifests > remote: adding file changes > remote: added 1 changesets with 1 changes to 1 files > remote: [jcheck d46eaf84b346 2015-12-01 13:15:54 -0800] > remote: > remote: Illegal tag name: jdk8u76-b00-aarch32-160405 > remote: > remote: transaction abort! > remote: rollback completed > remote: abort: pretxnchangegroup.0.jcheck hook failed > > So, it seems like there are upstream restrictions on the tags we can use. > > Does anyone know the correct syntax of a tag? > > All the best, > Ed. > > > On Fri, 2016-04-01 at 15:05 +0200, Jiri Vanek wrote: >> On 03/22/2016 12:33 PM, Jiri Vanek wrote: >>> On 03/17/2016 06:25 PM, Andrew Hughes wrote: >>> >>> Ping? >> >> Ping ping? This would really help a lot! >> >> See laready runnign review: https://bugzilla.redhat.com/show_bug.cgi?id=1318988#c18 >> >>> >>> FYI - https://bugzilla.redhat.com/show_bug.cgi?id=1318988 I already started the wheels of destiny, and I'm pretty sure the not-reproducible tarball will be the reelase blocker :( >>> >>> J. >>>> ----- Original Message ----- >>>>> Hello! >>>>> >>>>> I would like to introduce the aarch32 project to Fedora arm repositories. >>>>> To create clearly reproducible source tarball I need some anchor. >>>>> I think you will agree that cloning "tip" do not cover the reproducibility. >>>>> Also I think you will agree that keeping somewhere list of changset ids used >>>>> for source tarball is >>>>> not exactly convenient. >>>>> >>>>> So I would like to kindly ask you for favour and to tag your project forest >>>>> once per day or at least >>>>> once per week or just when things look little bit more stable then yesterday >>>>> (eg tomorrow:) ) >>>>> >>>>> We had chosen this approach for aarch64 releases [1] by prefixing by >>>>> "aarch64" and incrementing >>>>> build. As upstream builds are not exactly continuous, it works fine. But of >>>>> course feel free to >>>>> chose whatever suits you. >>>>> >>>>> I think that having small fedora arm32 community in testing audience may be >>>>> just benefit for project. >>>>> >>>>> Thank you in advance! >>>>> >>>>> J. >>>>> >>>>> >>>>> >>>>> [1] >>>>> http://hg.openjdk.java.net/aarch64-port/jdk8u/ >>>>> 2 weeks ago andrew Added tag aarch64-jdk8u72-b16 for changeset >>>>> 92af9369869fdefault tip >>>>> 7 weeks ago andrew Added tag aarch64-jdk8u72-b15 for changeset >>>>> 618f7e7b68f4aarch64-jdk8u72-b16 >>>>> 7 weeks ago andrew Merge jdk8u72-b15aarch64-jdk8u72-b15 >>>>> 2 months ago asaha Merge >>>>> >>>>> >>>> >>>> I don't think it needs to be as often as "once per day" as I doubt >>>> the RPMs will be updated that frequently. It would however be good >>> >>> sure >>> >>>> to have a known good point to base Fedora RPMs on. This is beneficial >>>> to the AArch32 project as well, as it is then clear what is being used >>>> by these binaries out in the wild. >>>> >>>> Thanks, >>>> >>> >> > > From fedor.burdun at azulsystems.com Thu Apr 7 17:14:36 2016 From: fedor.burdun at azulsystems.com (Fedor Burdun) Date: Thu, 7 Apr 2016 17:14:36 +0000 Subject: [8u] RFR: fix of vtable self-patching routine Message-ID: <2C82F743BAC10D4D843822D7B0146F3B955AB192@MBX021-W3-CA-2.exch021.domain.local> Hi all, I would like to ask you several reviews of proposed fix of issue below. The problem is crash caused by using CDS. It occurs because c++ vtables self-patching routine (written in metaspaceShared_aarch32.cpp) corrupts r9 register, that can be used by c++ compiler to store locals. Usually it happens in Method::restore_vtable virtual call, that causes undefined behaviour (mostly crahes) in InstanceKlass::restore_unshareable_info function. Reproduction steps: # dump shared space $ java -Xint -XX:+UnlockDiagnosticVMOptions -XX:SharedArchiveFile=./sample.jsa -Xshare:dump # restore from CDS (crash happens here) $ java -Xint -XX:+UnlockDiagnosticVMOptions -XX:SharedArchiveFile=./sample.jsa -Xshare:on -version Fix is in attachement. Thanks, Fedor -------------- next part -------------- A non-text attachment was scrubbed... Name: CDS.patch Type: text/x-diff Size: 2513 bytes Desc: CDS.patch URL: From edward.nevill at gmail.com Fri Apr 8 10:44:01 2016 From: edward.nevill at gmail.com (edward.nevill at gmail.com) Date: Fri, 08 Apr 2016 10:44:01 +0000 Subject: hg: aarch32-port/jdk8u/hotspot: Set comments and tags to lax Message-ID: <201604081044.u38Ai2Ci019639@aojmv0008.oracle.com> Changeset: 25359ab27483 Author: enevill Date: 2016-04-08 11:43 +0100 URL: http://hg.openjdk.java.net/aarch32-port/jdk8u/hotspot/rev/25359ab27483 Set comments and tags to lax ! .jcheck/conf From edward.nevill at gmail.com Fri Apr 8 11:10:35 2016 From: edward.nevill at gmail.com (Edward Nevill) Date: Fri, 08 Apr 2016 12:10:35 +0100 Subject: [REF] more often tagging or syncing with upstream In-Reply-To: <05E8DC07-E194-4554-8B0A-D3768B8687A8@azul.com> References: <56EAE706.1000106@redhat.com> <45673724.10758208.1458235548198.JavaMail.zimbra@redhat.com> <56F12D8D.3030206@redhat.com> <56FE7210.5040401@redhat.com> <1459852041.3488.1.camel@mylittlepony.linaroharston> <05E8DC07-E194-4554-8B0A-D3768B8687A8@azul.com> Message-ID: <1460113835.13814.4.camel@mint> Hi, So, I tried changing the .jcheck/conf as suggested, and then I pushed that change http://hg.openjdk.java.net/aarch32-port/jdk8u/hotspot/rev/25359ab27483 I then tried pushing the tag change as before but it rejects it with the same error. There is some other magic going on upstream. I think we are hosed. Regards, Ed. On Fri, 2016-04-08 at 09:58 +0000, Sergey Nazarkin wrote: > Hi Edward, > > BTW, you can change jcheck setting at .jcheck/conf like > > project=jdk8 > bugids=dup > comments=lax > tags=lax > > Such config suppresses comments and tag name verification. > > > Sergey Nazarkin > > > > > > On 05 Apr 2016, at 13:34, Sergey Nazarkin wrote: > > > > here is regexp from jcheck > > > > "tip$|jdk-([1-9]([0-9]*)(\.[0-9]){0,3})\+([0-9]+)$|jdk[4-9]( u\d{1,3})?-b\d{2,3}$|hs\d\d(\.\d{1,2})?-b\d\d$? > > > > as I can see it doesn?t accept port name and date. > > > > Sergey Nazarkin > > > > > > > > > >> On 05 Apr 2016, at 13:27, Edward Nevill wrote: > >> > >> OK. I tried tagging the tree with > >> > >> jdk8u76-b00-aarch32-160405 > >> > >> But I get > >> > >> (trusty)ed at localhost:/work/ed/aarch32/jdk8u/hotspot$ hg push > >> pushing to ssh://enevill at hg.openjdk.java.net/aarch32-port/jdk8u/hotspot > >> running ssh enevill at hg.openjdk.java.net 'hg -R aarch32-port/jdk8u/hotspot serve --stdio' > >> searching for changes > >> 1 changesets found > >> remote: adding changesets > >> remote: adding manifests > >> remote: adding file changes > >> remote: added 1 changesets with 1 changes to 1 files > >> remote: [jcheck d46eaf84b346 2015-12-01 13:15:54 -0800] > >> remote: > >> remote: Illegal tag name: jdk8u76-b00-aarch32-160405 > >> remote: > >> remote: transaction abort! > >> remote: rollback completed > >> remote: abort: pretxnchangegroup.0.jcheck hook failed > >> > >> So, it seems like there are upstream restrictions on the tags we can use. > >> > >> Does anyone know the correct syntax of a tag? > >> > >> All the best, > >> Ed. > >> > >> > >> On Fri, 2016-04-01 at 15:05 +0200, Jiri Vanek wrote: > >>> On 03/22/2016 12:33 PM, Jiri Vanek wrote: > >>>> On 03/17/2016 06:25 PM, Andrew Hughes wrote: > >>>> > >>>> Ping? > >>> > >>> Ping ping? This would really help a lot! > >>> > >>> See laready runnign review: https://bugzilla.redhat.com/show_bug.cgi?id=1318988#c18 > >>> > >>>> > >>>> FYI - https://bugzilla.redhat.com/show_bug.cgi?id=1318988 I already started the wheels of destiny, and I'm pretty sure the not-reproducible tarball will be the reelase blocker :( > >>>> > >>>> J. > >>>>> ----- Original Message ----- > >>>>>> Hello! > >>>>>> > >>>>>> I would like to introduce the aarch32 project to Fedora arm repositories. > >>>>>> To create clearly reproducible source tarball I need some anchor. > >>>>>> I think you will agree that cloning "tip" do not cover the reproducibility. > >>>>>> Also I think you will agree that keeping somewhere list of changset ids used > >>>>>> for source tarball is > >>>>>> not exactly convenient. > >>>>>> > >>>>>> So I would like to kindly ask you for favour and to tag your project forest > >>>>>> once per day or at least > >>>>>> once per week or just when things look little bit more stable then yesterday > >>>>>> (eg tomorrow:) ) > >>>>>> > >>>>>> We had chosen this approach for aarch64 releases [1] by prefixing by > >>>>>> "aarch64" and incrementing > >>>>>> build. As upstream builds are not exactly continuous, it works fine. But of > >>>>>> course feel free to > >>>>>> chose whatever suits you. > >>>>>> > >>>>>> I think that having small fedora arm32 community in testing audience may be > >>>>>> just benefit for project. > >>>>>> > >>>>>> Thank you in advance! > >>>>>> > >>>>>> J. > >>>>>> > >>>>>> > >>>>>> > >>>>>> [1] > >>>>>> http://hg.openjdk.java.net/aarch64-port/jdk8u/ > >>>>>> 2 weeks ago andrew Added tag aarch64-jdk8u72-b16 for changeset > >>>>>> 92af9369869fdefault tip > >>>>>> 7 weeks ago andrew Added tag aarch64-jdk8u72-b15 for changeset > >>>>>> 618f7e7b68f4aarch64-jdk8u72-b16 > >>>>>> 7 weeks ago andrew Merge jdk8u72-b15aarch64-jdk8u72-b15 > >>>>>> 2 months ago asaha Merge > >>>>>> > >>>>>> > >>>>> > >>>>> I don't think it needs to be as often as "once per day" as I doubt > >>>>> the RPMs will be updated that frequently. It would however be good > >>>> > >>>> sure > >>>> > >>>>> to have a known good point to base Fedora RPMs on. This is beneficial > >>>>> to the AArch32 project as well, as it is then clear what is being used > >>>>> by these binaries out in the wild. > >>>>> > >>>>> Thanks, > From edward.nevill at gmail.com Mon Apr 11 10:57:59 2016 From: edward.nevill at gmail.com (Edward Nevill) Date: Mon, 11 Apr 2016 11:57:59 +0100 Subject: [8u] RFR: fix of vtable self-patching routine In-Reply-To: <2C82F743BAC10D4D843822D7B0146F3B955AB192@MBX021-W3-CA-2.exch021.domain.local> References: <2C82F743BAC10D4D843822D7B0146F3B955AB192@MBX021-W3-CA-2.exch021.domain.local> Message-ID: <570B8337.2070601@gmail.com> Hi Fedor, On 07/04/16 18:14, Fedor Burdun wrote: > I would like to ask you several reviews of proposed fix of issue below. > Looks good. Thanks for this. Will push shortly, Ed. From edward.nevill at gmail.com Tue Apr 12 16:17:05 2016 From: edward.nevill at gmail.com (edward.nevill at gmail.com) Date: Tue, 12 Apr 2016 16:17:05 +0000 Subject: hg: aarch32-port/jdk8u/hotspot: 8153958: aarch32: fix of vtable self-patching routine Message-ID: <201604121617.u3CGH5EC026670@aojmv0008.oracle.com> Changeset: 483350e18369 Author: enevill Date: 2016-04-11 11:56 +0100 URL: http://hg.openjdk.java.net/aarch32-port/jdk8u/hotspot/rev/483350e18369 8153958: aarch32: fix of vtable self-patching routine Reviewed-by: enevill Contributed-by: fedor.burdun at azulsystems.com ! src/cpu/aarch32/vm/metaspaceShared_aarch32.cpp From jvanek at redhat.com Thu Apr 14 13:51:37 2016 From: jvanek at redhat.com (Jiri Vanek) Date: Thu, 14 Apr 2016 15:51:37 +0200 Subject: [REF] more often tagging or syncing with upstream In-Reply-To: <1460113835.13814.4.camel@mint> References: <56EAE706.1000106@redhat.com> <45673724.10758208.1458235548198.JavaMail.zimbra@redhat.com> <56F12D8D.3030206@redhat.com> <56FE7210.5040401@redhat.com> <1459852041.3488.1.camel@mylittlepony.linaroharston> <05E8DC07-E194-4554-8B0A-D3768B8687A8@azul.com> <1460113835.13814.4.camel@mint> Message-ID: <570FA069.7000904@redhat.com> Hello good people! I used your tags and all is working for me. Thank you very much for help! J. On 04/08/2016 01:10 PM, Edward Nevill wrote: > Hi, > > So, I tried changing the .jcheck/conf as suggested, and then I pushed > that change > > http://hg.openjdk.java.net/aarch32-port/jdk8u/hotspot/rev/25359ab27483 > > I then tried pushing the tag change as before but it rejects it with the > same error. > > There is some other magic going on upstream. I think we are hosed. > > Regards, > Ed. > > On Fri, 2016-04-08 at 09:58 +0000, Sergey Nazarkin wrote: >> Hi Edward, >> >> BTW, you can change jcheck setting at .jcheck/conf like >> >> project=jdk8 >> bugids=dup >> comments=lax >> tags=lax >> >> Such config suppresses comments and tag name verification. >> >> >> Sergey Nazarkin >> >> >> >> >>> On 05 Apr 2016, at 13:34, Sergey Nazarkin wrote: >>> >>> here is regexp from jcheck >>> >>> "tip$|jdk-([1-9]([0-9]*)(\.[0-9]){0,3})\+([0-9]+)$|jdk[4-9]( u\d{1,3})?-b\d{2,3}$|hs\d\d(\.\d{1,2})?-b\d\d$? >>> >>> as I can see it doesn?t accept port name and date. >>> >>> Sergey Nazarkin >>> >>> >>> >>> >>>> On 05 Apr 2016, at 13:27, Edward Nevill wrote: >>>> >>>> OK. I tried tagging the tree with >>>> >>>> jdk8u76-b00-aarch32-160405 >>>> >>>> But I get >>>> >>>> (trusty)ed at localhost:/work/ed/aarch32/jdk8u/hotspot$ hg push >>>> pushing to ssh://enevill at hg.openjdk.java.net/aarch32-port/jdk8u/hotspot >>>> running ssh enevill at hg.openjdk.java.net 'hg -R aarch32-port/jdk8u/hotspot serve --stdio' >>>> searching for changes >>>> 1 changesets found >>>> remote: adding changesets >>>> remote: adding manifests >>>> remote: adding file changes >>>> remote: added 1 changesets with 1 changes to 1 files >>>> remote: [jcheck d46eaf84b346 2015-12-01 13:15:54 -0800] >>>> remote: >>>> remote: Illegal tag name: jdk8u76-b00-aarch32-160405 >>>> remote: >>>> remote: transaction abort! >>>> remote: rollback completed >>>> remote: abort: pretxnchangegroup.0.jcheck hook failed >>>> >>>> So, it seems like there are upstream restrictions on the tags we can use. >>>> >>>> Does anyone know the correct syntax of a tag? >>>> >>>> All the best, >>>> Ed. >>>> >>>> >>>> On Fri, 2016-04-01 at 15:05 +0200, Jiri Vanek wrote: >>>>> On 03/22/2016 12:33 PM, Jiri Vanek wrote: >>>>>> On 03/17/2016 06:25 PM, Andrew Hughes wrote: >>>>>> >>>>>> Ping? >>>>> >>>>> Ping ping? This would really help a lot! >>>>> >>>>> See laready runnign review: https://bugzilla.redhat.com/show_bug.cgi?id=1318988#c18 >>>>> >>>>>> >>>>>> FYI - https://bugzilla.redhat.com/show_bug.cgi?id=1318988 I already started the wheels of destiny, and I'm pretty sure the not-reproducible tarball will be the reelase blocker :( >>>>>> >>>>>> J. >>>>>>> ----- Original Message ----- >>>>>>>> Hello! >>>>>>>> >>>>>>>> I would like to introduce the aarch32 project to Fedora arm repositories. >>>>>>>> To create clearly reproducible source tarball I need some anchor. >>>>>>>> I think you will agree that cloning "tip" do not cover the reproducibility. >>>>>>>> Also I think you will agree that keeping somewhere list of changset ids used >>>>>>>> for source tarball is >>>>>>>> not exactly convenient. >>>>>>>> >>>>>>>> So I would like to kindly ask you for favour and to tag your project forest >>>>>>>> once per day or at least >>>>>>>> once per week or just when things look little bit more stable then yesterday >>>>>>>> (eg tomorrow:) ) >>>>>>>> >>>>>>>> We had chosen this approach for aarch64 releases [1] by prefixing by >>>>>>>> "aarch64" and incrementing >>>>>>>> build. As upstream builds are not exactly continuous, it works fine. But of >>>>>>>> course feel free to >>>>>>>> chose whatever suits you. >>>>>>>> >>>>>>>> I think that having small fedora arm32 community in testing audience may be >>>>>>>> just benefit for project. >>>>>>>> >>>>>>>> Thank you in advance! >>>>>>>> >>>>>>>> J. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> [1] >>>>>>>> http://hg.openjdk.java.net/aarch64-port/jdk8u/ >>>>>>>> 2 weeks ago andrew Added tag aarch64-jdk8u72-b16 for changeset >>>>>>>> 92af9369869fdefault tip >>>>>>>> 7 weeks ago andrew Added tag aarch64-jdk8u72-b15 for changeset >>>>>>>> 618f7e7b68f4aarch64-jdk8u72-b16 >>>>>>>> 7 weeks ago andrew Merge jdk8u72-b15aarch64-jdk8u72-b15 >>>>>>>> 2 months ago asaha Merge >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> I don't think it needs to be as often as "once per day" as I doubt >>>>>>> the RPMs will be updated that frequently. It would however be good >>>>>> >>>>>> sure >>>>>> >>>>>>> to have a known good point to base Fedora RPMs on. This is beneficial >>>>>>> to the AArch32 project as well, as it is then clear what is being used >>>>>>> by these binaries out in the wild. >>>>>>> >>>>>>> Thanks, >> > > From akashche at redhat.com Thu Apr 14 17:39:48 2016 From: akashche at redhat.com (Alex Kashchenko) Date: Thu, 14 Apr 2016 18:39:48 +0100 Subject: [REF] more often tagging or syncing with upstream In-Reply-To: <570FA069.7000904@redhat.com> References: <56EAE706.1000106@redhat.com> <45673724.10758208.1458235548198.JavaMail.zimbra@redhat.com> <56F12D8D.3030206@redhat.com> <56FE7210.5040401@redhat.com> <1459852041.3488.1.camel@mylittlepony.linaroharston> <05E8DC07-E194-4554-8B0A-D3768B8687A8@azul.com> <1460113835.13814.4.camel@mint> <570FA069.7000904@redhat.com> Message-ID: <570FD5E4.8040603@redhat.com> Hi, On 04/14/2016 02:51 PM, Jiri Vanek wrote: > Hello good people! > > I used your tags and all is working for me. > > Thank you very much for help! I think there were some confusion and old pre-aarch32 tag jdk8u76-b00 was confused with the new jdk8u76-b00-aarch32-160405 one that wasn't get through. If there is any way to investigate tag naming restrictions without having push access (to reach o.j.n ops for repo config changes if required etc) - I am ready to look into that. For example, can we use the same tag names as in aarch64 forest and ask ops to have the same config for aarch32 one? > > J. > On 04/08/2016 01:10 PM, Edward Nevill wrote: >> Hi, >> >> So, I tried changing the .jcheck/conf as suggested, and then I pushed >> that change >> >> http://hg.openjdk.java.net/aarch32-port/jdk8u/hotspot/rev/25359ab27483 >> >> I then tried pushing the tag change as before but it rejects it with the >> same error. >> >> There is some other magic going on upstream. I think we are hosed. >> >> Regards, >> Ed. >> >> On Fri, 2016-04-08 at 09:58 +0000, Sergey Nazarkin wrote: >>> Hi Edward, >>> >>> BTW, you can change jcheck setting at .jcheck/conf like >>> >>> project=jdk8 >>> bugids=dup >>> comments=lax >>> tags=lax >>> >>> Such config suppresses comments and tag name verification. >>> >>> >>> Sergey Nazarkin >>> >>> >>> >>> >>>> On 05 Apr 2016, at 13:34, Sergey Nazarkin wrote: >>>> >>>> here is regexp from jcheck >>>> >>>> "tip$|jdk-([1-9]([0-9]*)(\.[0-9]){0,3})\+([0-9]+)$|jdk[4-9]( >>>> u\d{1,3})?-b\d{2,3}$|hs\d\d(\.\d{1,2})?-b\d\d$? >>>> >>>> as I can see it doesn?t accept port name and date. >>>> >>>> Sergey Nazarkin >>>> >>>> >>>> >>>> >>>>> On 05 Apr 2016, at 13:27, Edward Nevill >>>>> wrote: >>>>> >>>>> OK. I tried tagging the tree with >>>>> >>>>> jdk8u76-b00-aarch32-160405 >>>>> >>>>> But I get >>>>> >>>>> (trusty)ed at localhost:/work/ed/aarch32/jdk8u/hotspot$ hg push >>>>> pushing to >>>>> ssh://enevill at hg.openjdk.java.net/aarch32-port/jdk8u/hotspot >>>>> running ssh enevill at hg.openjdk.java.net 'hg -R >>>>> aarch32-port/jdk8u/hotspot serve --stdio' >>>>> searching for changes >>>>> 1 changesets found >>>>> remote: adding changesets >>>>> remote: adding manifests >>>>> remote: adding file changes >>>>> remote: added 1 changesets with 1 changes to 1 files >>>>> remote: [jcheck d46eaf84b346 2015-12-01 13:15:54 -0800] >>>>> remote: >>>>> remote: Illegal tag name: jdk8u76-b00-aarch32-160405 >>>>> remote: >>>>> remote: transaction abort! >>>>> remote: rollback completed >>>>> remote: abort: pretxnchangegroup.0.jcheck hook failed >>>>> >>>>> So, it seems like there are upstream restrictions on the tags we >>>>> can use. >>>>> >>>>> Does anyone know the correct syntax of a tag? >>>>> >>>>> All the best, >>>>> Ed. >>>>> >>>>> >>>>> On Fri, 2016-04-01 at 15:05 +0200, Jiri Vanek wrote: >>>>>> On 03/22/2016 12:33 PM, Jiri Vanek wrote: >>>>>>> On 03/17/2016 06:25 PM, Andrew Hughes wrote: >>>>>>> >>>>>>> Ping? >>>>>> >>>>>> Ping ping? This would really help a lot! >>>>>> >>>>>> See laready runnign review: >>>>>> https://bugzilla.redhat.com/show_bug.cgi?id=1318988#c18 >>>>>> >>>>>>> >>>>>>> FYI - https://bugzilla.redhat.com/show_bug.cgi?id=1318988 I >>>>>>> already started the wheels of destiny, and I'm pretty sure the >>>>>>> not-reproducible tarball will be the reelase blocker :( >>>>>>> >>>>>>> J. >>>>>>>> ----- Original Message ----- >>>>>>>>> Hello! >>>>>>>>> >>>>>>>>> I would like to introduce the aarch32 project to Fedora arm >>>>>>>>> repositories. >>>>>>>>> To create clearly reproducible source tarball I need some anchor. >>>>>>>>> I think you will agree that cloning "tip" do not cover the >>>>>>>>> reproducibility. >>>>>>>>> Also I think you will agree that keeping somewhere list of >>>>>>>>> changset ids used >>>>>>>>> for source tarball is >>>>>>>>> not exactly convenient. >>>>>>>>> >>>>>>>>> So I would like to kindly ask you for favour and to tag your >>>>>>>>> project forest >>>>>>>>> once per day or at least >>>>>>>>> once per week or just when things look little bit more stable >>>>>>>>> then yesterday >>>>>>>>> (eg tomorrow:) ) >>>>>>>>> >>>>>>>>> We had chosen this approach for aarch64 releases [1] by >>>>>>>>> prefixing by >>>>>>>>> "aarch64" and incrementing >>>>>>>>> build. As upstream builds are not exactly continuous, it works >>>>>>>>> fine. But of >>>>>>>>> course feel free to >>>>>>>>> chose whatever suits you. >>>>>>>>> >>>>>>>>> I think that having small fedora arm32 community in testing >>>>>>>>> audience may be >>>>>>>>> just benefit for project. >>>>>>>>> >>>>>>>>> Thank you in advance! >>>>>>>>> >>>>>>>>> J. >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> [1] >>>>>>>>> http://hg.openjdk.java.net/aarch64-port/jdk8u/ >>>>>>>>> 2 weeks ago andrew Added tag aarch64-jdk8u72-b16 for >>>>>>>>> changeset >>>>>>>>> 92af9369869fdefault tip >>>>>>>>> 7 weeks ago andrew Added tag aarch64-jdk8u72-b15 for >>>>>>>>> changeset >>>>>>>>> 618f7e7b68f4aarch64-jdk8u72-b16 >>>>>>>>> 7 weeks ago andrew Merge jdk8u72-b15aarch64-jdk8u72-b15 >>>>>>>>> 2 months ago asaha Merge >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> I don't think it needs to be as often as "once per day" as I doubt >>>>>>>> the RPMs will be updated that frequently. It would however be good >>>>>>> >>>>>>> sure >>>>>>> >>>>>>>> to have a known good point to base Fedora RPMs on. This is >>>>>>>> beneficial >>>>>>>> to the AArch32 project as well, as it is then clear what is >>>>>>>> being used >>>>>>>> by these binaries out in the wild. >>>>>>>> >>>>>>>> Thanks, >>> >> >> > -- -Alex From edward.nevill at gmail.com Thu Apr 14 17:59:10 2016 From: edward.nevill at gmail.com (Edward Nevill) Date: Thu, 14 Apr 2016 18:59:10 +0100 Subject: [REF] more often tagging or syncing with upstream In-Reply-To: <570FD5E4.8040603@redhat.com> References: <56EAE706.1000106@redhat.com> <45673724.10758208.1458235548198.JavaMail.zimbra@redhat.com> <56F12D8D.3030206@redhat.com> <56FE7210.5040401@redhat.com> <1459852041.3488.1.camel@mylittlepony.linaroharston> <05E8DC07-E194-4554-8B0A-D3768B8687A8@azul.com> <1460113835.13814.4.camel@mint> <570FA069.7000904@redhat.com> <570FD5E4.8040603@redhat.com> Message-ID: <1460656750.14827.5.camel@mint> Hi Ops, Please could you remove the tag restrictions (tags=lax) on the aarch32 repos http://hg.openjdk.java.net/aarch32-port/jdk8u http://hg.openjdk.java.net/aarch32-port/jdk9 and all sub-repos. Thanks, Ed. On Thu, 2016-04-14 at 18:39 +0100, Alex Kashchenko wrote: > Hi, > If there is any way to investigate tag naming restrictions without > having push access (to reach o.j.n ops for repo config changes if > required etc) - I am ready to look into that. For example, can we use > the same tag names as in aarch64 forest and ask ops to have the same > config for aarch32 one? > From iris.clark at oracle.com Thu Apr 14 20:52:30 2016 From: iris.clark at oracle.com (Iris Clark) Date: Thu, 14 Apr 2016 13:52:30 -0700 (PDT) Subject: [REF] more often tagging or syncing with upstream In-Reply-To: <1460656750.14827.5.camel@mint> References: <56EAE706.1000106@redhat.com> <45673724.10758208.1458235548198.JavaMail.zimbra@redhat.com> <56F12D8D.3030206@redhat.com> <56FE7210.5040401@redhat.com> <1459852041.3488.1.camel@mylittlepony.linaroharston> <05E8DC07-E194-4554-8B0A-D3768B8687A8@azul.com> <1460113835.13814.4.camel@mint> <570FA069.7000904@redhat.com> <570FD5E4.8040603@redhat.com> <1460656750.14827.5.camel@mint> Message-ID: <619e10e6-a036-4acf-953b-926c83a18ce1@default> Hi, Ed. You're set. Thanks, iris -----Original Message----- From: Edward Nevill [mailto:edward.nevill at gmail.com] Sent: Thursday, April 14, 2016 10:59 AM To: Alex Kashchenko; ops at openjdk.java.net Cc: aarch32-port-dev at openjdk.java.net Subject: Re: [REF] more often tagging or syncing with upstream Hi Ops, Please could you remove the tag restrictions (tags=lax) on the aarch32 repos http://hg.openjdk.java.net/aarch32-port/jdk8u http://hg.openjdk.java.net/aarch32-port/jdk9 and all sub-repos. Thanks, Ed. On Thu, 2016-04-14 at 18:39 +0100, Alex Kashchenko wrote: > Hi, > If there is any way to investigate tag naming restrictions without > having push access (to reach o.j.n ops for repo config changes if > required etc) - I am ready to look into that. For example, can we use > the same tag names as in aarch64 forest and ask ops to have the same > config for aarch32 one? > From edward.nevill at gmail.com Fri Apr 15 10:20:02 2016 From: edward.nevill at gmail.com (edward.nevill at gmail.com) Date: Fri, 15 Apr 2016 10:20:02 +0000 Subject: hg: aarch32-port/jdk8u: Set comments and tags to lax Message-ID: <201604151020.u3FAK2iJ007698@aojmv0008.oracle.com> Changeset: 84a69380750b Author: enevill Date: 2016-04-08 11:43 +0100 URL: http://hg.openjdk.java.net/aarch32-port/jdk8u/rev/84a69380750b Set comments and tags to lax ! .jcheck/conf From edward.nevill at gmail.com Fri Apr 15 10:20:14 2016 From: edward.nevill at gmail.com (edward.nevill at gmail.com) Date: Fri, 15 Apr 2016 10:20:14 +0000 Subject: hg: aarch32-port/jdk8u/corba: Set comments and tags to lax Message-ID: <201604151020.u3FAKERS007948@aojmv0008.oracle.com> Changeset: 1df8c722621c Author: enevill Date: 2016-04-08 11:43 +0100 URL: http://hg.openjdk.java.net/aarch32-port/jdk8u/corba/rev/1df8c722621c Set comments and tags to lax ! .jcheck/conf From edward.nevill at gmail.com Fri Apr 15 10:20:33 2016 From: edward.nevill at gmail.com (edward.nevill at gmail.com) Date: Fri, 15 Apr 2016 10:20:33 +0000 Subject: hg: aarch32-port/jdk8u/jaxp: Set comments and tags to lax Message-ID: <201604151020.u3FAKXZj008259@aojmv0008.oracle.com> Changeset: d8312364571d Author: enevill Date: 2016-04-08 11:43 +0100 URL: http://hg.openjdk.java.net/aarch32-port/jdk8u/jaxp/rev/d8312364571d Set comments and tags to lax ! .jcheck/conf From edward.nevill at gmail.com Fri Apr 15 10:20:51 2016 From: edward.nevill at gmail.com (edward.nevill at gmail.com) Date: Fri, 15 Apr 2016 10:20:51 +0000 Subject: hg: aarch32-port/jdk8u/jaxws: Set comments and tags to lax Message-ID: <201604151020.u3FAKpNw008317@aojmv0008.oracle.com> Changeset: 72ffde0c2909 Author: enevill Date: 2016-04-08 11:43 +0100 URL: http://hg.openjdk.java.net/aarch32-port/jdk8u/jaxws/rev/72ffde0c2909 Set comments and tags to lax ! .jcheck/conf From edward.nevill at gmail.com Fri Apr 15 10:21:10 2016 From: edward.nevill at gmail.com (edward.nevill at gmail.com) Date: Fri, 15 Apr 2016 10:21:10 +0000 Subject: hg: aarch32-port/jdk8u/jdk: Set comments and tags to lax Message-ID: <201604151021.u3FALAOU008480@aojmv0008.oracle.com> Changeset: 345b14ed5e3f Author: enevill Date: 2016-04-08 11:43 +0100 URL: http://hg.openjdk.java.net/aarch32-port/jdk8u/jdk/rev/345b14ed5e3f Set comments and tags to lax ! .jcheck/conf From edward.nevill at gmail.com Fri Apr 15 10:21:23 2016 From: edward.nevill at gmail.com (edward.nevill at gmail.com) Date: Fri, 15 Apr 2016 10:21:23 +0000 Subject: hg: aarch32-port/jdk8u/langtools: Set comments and tags to lax Message-ID: <201604151021.u3FALNu5008602@aojmv0008.oracle.com> Changeset: be5dad85e567 Author: enevill Date: 2016-04-08 11:43 +0100 URL: http://hg.openjdk.java.net/aarch32-port/jdk8u/langtools/rev/be5dad85e567 Set comments and tags to lax ! .jcheck/conf From edward.nevill at gmail.com Fri Apr 15 10:21:37 2016 From: edward.nevill at gmail.com (edward.nevill at gmail.com) Date: Fri, 15 Apr 2016 10:21:37 +0000 Subject: hg: aarch32-port/jdk8u/nashorn: Set comments and tags to lax Message-ID: <201604151021.u3FALbba008699@aojmv0008.oracle.com> Changeset: a4b886b6684f Author: enevill Date: 2016-04-08 11:43 +0100 URL: http://hg.openjdk.java.net/aarch32-port/jdk8u/nashorn/rev/a4b886b6684f Set comments and tags to lax ! .jcheck/conf From edward.nevill at gmail.com Fri Apr 15 10:25:12 2016 From: edward.nevill at gmail.com (edward.nevill at gmail.com) Date: Fri, 15 Apr 2016 10:25:12 +0000 Subject: hg: aarch32-port/jdk8u: Added tag jdk8u76-b00-aarch32-160415 for changeset 84a69380750b Message-ID: <201604151025.u3FAPCQ6009835@aojmv0008.oracle.com> Changeset: 748d22a056d9 Author: enevill Date: 2016-04-15 11:22 +0100 URL: http://hg.openjdk.java.net/aarch32-port/jdk8u/rev/748d22a056d9 Added tag jdk8u76-b00-aarch32-160415 for changeset 84a69380750b ! .hgtags From edward.nevill at gmail.com Fri Apr 15 10:26:32 2016 From: edward.nevill at gmail.com (edward.nevill at gmail.com) Date: Fri, 15 Apr 2016 10:26:32 +0000 Subject: hg: aarch32-port/jdk8u/corba: Added tag jdk8u76-b00-aarch32-160415 for changeset 1df8c722621c Message-ID: <201604151026.u3FAQWQW010314@aojmv0008.oracle.com> Changeset: 6f9ec757be42 Author: enevill Date: 2016-04-15 11:22 +0100 URL: http://hg.openjdk.java.net/aarch32-port/jdk8u/corba/rev/6f9ec757be42 Added tag jdk8u76-b00-aarch32-160415 for changeset 1df8c722621c ! .hgtags From edward.nevill at gmail.com Fri Apr 15 10:26:47 2016 From: edward.nevill at gmail.com (edward.nevill at gmail.com) Date: Fri, 15 Apr 2016 10:26:47 +0000 Subject: hg: aarch32-port/jdk8u/hotspot: Added tag jdk8u76-b00-aarch32-160415 for changeset 483350e18369 Message-ID: <201604151026.u3FAQld4010454@aojmv0008.oracle.com> Changeset: 76987d598b33 Author: enevill Date: 2016-04-15 11:22 +0100 URL: http://hg.openjdk.java.net/aarch32-port/jdk8u/hotspot/rev/76987d598b33 Added tag jdk8u76-b00-aarch32-160415 for changeset 483350e18369 ! .hgtags From edward.nevill at gmail.com Fri Apr 15 10:27:21 2016 From: edward.nevill at gmail.com (edward.nevill at gmail.com) Date: Fri, 15 Apr 2016 10:27:21 +0000 Subject: hg: aarch32-port/jdk8u/jaxp: Added tag jdk8u76-b00-aarch32-160415 for changeset d8312364571d Message-ID: <201604151027.u3FARLwE010618@aojmv0008.oracle.com> Changeset: b5f4fc0ff722 Author: enevill Date: 2016-04-15 11:23 +0100 URL: http://hg.openjdk.java.net/aarch32-port/jdk8u/jaxp/rev/b5f4fc0ff722 Added tag jdk8u76-b00-aarch32-160415 for changeset d8312364571d ! .hgtags From edward.nevill at gmail.com Fri Apr 15 10:27:36 2016 From: edward.nevill at gmail.com (edward.nevill at gmail.com) Date: Fri, 15 Apr 2016 10:27:36 +0000 Subject: hg: aarch32-port/jdk8u/jaxws: Added tag jdk8u76-b00-aarch32-160415 for changeset 72ffde0c2909 Message-ID: <201604151027.u3FARaaK010683@aojmv0008.oracle.com> Changeset: e3218eeb146c Author: enevill Date: 2016-04-15 11:23 +0100 URL: http://hg.openjdk.java.net/aarch32-port/jdk8u/jaxws/rev/e3218eeb146c Added tag jdk8u76-b00-aarch32-160415 for changeset 72ffde0c2909 ! .hgtags From edward.nevill at gmail.com Fri Apr 15 10:27:51 2016 From: edward.nevill at gmail.com (edward.nevill at gmail.com) Date: Fri, 15 Apr 2016 10:27:51 +0000 Subject: hg: aarch32-port/jdk8u/jdk: Added tag jdk8u76-b00-aarch32-160415 for changeset 345b14ed5e3f Message-ID: <201604151027.u3FARqCg010747@aojmv0008.oracle.com> Changeset: 6970e7970d0e Author: enevill Date: 2016-04-15 11:23 +0100 URL: http://hg.openjdk.java.net/aarch32-port/jdk8u/jdk/rev/6970e7970d0e Added tag jdk8u76-b00-aarch32-160415 for changeset 345b14ed5e3f ! .hgtags From edward.nevill at gmail.com Fri Apr 15 10:28:08 2016 From: edward.nevill at gmail.com (edward.nevill at gmail.com) Date: Fri, 15 Apr 2016 10:28:08 +0000 Subject: hg: aarch32-port/jdk8u/langtools: Added tag jdk8u76-b00-aarch32-160415 for changeset be5dad85e567 Message-ID: <201604151028.u3FAS8VH010816@aojmv0008.oracle.com> Changeset: d39b744b7c8d Author: enevill Date: 2016-04-15 11:23 +0100 URL: http://hg.openjdk.java.net/aarch32-port/jdk8u/langtools/rev/d39b744b7c8d Added tag jdk8u76-b00-aarch32-160415 for changeset be5dad85e567 ! .hgtags From edward.nevill at gmail.com Fri Apr 15 10:28:22 2016 From: edward.nevill at gmail.com (edward.nevill at gmail.com) Date: Fri, 15 Apr 2016 10:28:22 +0000 Subject: hg: aarch32-port/jdk8u/nashorn: Added tag jdk8u76-b00-aarch32-160415 for changeset a4b886b6684f Message-ID: <201604151028.u3FASMv8010910@aojmv0008.oracle.com> Changeset: a51b06d1d0cc Author: enevill Date: 2016-04-15 11:23 +0100 URL: http://hg.openjdk.java.net/aarch32-port/jdk8u/nashorn/rev/a51b06d1d0cc Added tag jdk8u76-b00-aarch32-160415 for changeset a4b886b6684f ! .hgtags From fedor.burdun at azulsystems.com Fri Apr 15 14:30:52 2016 From: fedor.burdun at azulsystems.com (Fedor Burdun) Date: Fri, 15 Apr 2016 14:30:52 +0000 Subject: RFR: turn off critical jni Message-ID: <2C82F743BAC10D4D843822D7B0146F3B955B450E@MBX021-W3-CA-2.exch021.domain.local> Hi all, Since aarch32 has no support critical jni entries (a most of required routines are unimplemented). I would like to suggest to turn off this feature. The idea it to switching off this flag in VM_Version::initialize() although it is not the best place to do such things I can't find any better one. The good assumption is to disable it in globals_aarch32.hpp, but eventually CriticalJNINatives flag was not declared as platform dependant. Moreover the flag UseBiasedLocking seems not to be turned off in despite of confusing line "define_pd_global(bool, UseBiasedLocking, false);" in globals_aarch32.hpp The test case that reproduces problem is in attachement (src.tgz), however it looks like it affects only jit-ed code. Thanks, Fedor -------------- next part -------------- A non-text attachment was scrubbed... Name: criticalJni.patch Type: text/x-diff Size: 362 bytes Desc: criticalJni.patch URL: From aph at redhat.com Fri Apr 15 14:33:43 2016 From: aph at redhat.com (Andrew Haley) Date: Fri, 15 Apr 2016 15:33:43 +0100 Subject: RFR: turn off critical jni In-Reply-To: <2C82F743BAC10D4D843822D7B0146F3B955B450E@MBX021-W3-CA-2.exch021.domain.local> References: <2C82F743BAC10D4D843822D7B0146F3B955B450E@MBX021-W3-CA-2.exch021.domain.local> Message-ID: <5710FBC7.8070407@redhat.com> On 04/15/2016 03:30 PM, Fedor Burdun wrote: > Since aarch32 has no support critical jni entries (a most of required routines are unimplemented). > I would like to suggest to turn off this feature. > > The idea it to switching off this flag in VM_Version::initialize() > although it is not the best place to do such things I can't find any better one. OK, but we should probably think of this as temporary. Please add a FIXME comment. Andrew. From fedor.burdun at azulsystems.com Fri Apr 15 14:53:44 2016 From: fedor.burdun at azulsystems.com (Fedor Burdun) Date: Fri, 15 Apr 2016 14:53:44 +0000 Subject: RFR: turn off critical jni In-Reply-To: <5710FBC7.8070407@redhat.com> References: <2C82F743BAC10D4D843822D7B0146F3B955B450E@MBX021-W3-CA-2.exch021.domain.local>, <5710FBC7.8070407@redhat.com> Message-ID: <2C82F743BAC10D4D843822D7B0146F3B955B45D6@MBX021-W3-CA-2.exch021.domain.local> > > Since aarch32 has no support critical jni entries (a most of required routines are unimplemented). > > I would like to suggest to turn off this feature. > > > > The idea it to switching off this flag in VM_Version::initialize() > > although it is not the best place to do such things I can't find any better one. > > OK, but we should probably think of this as temporary. Please add > a FIXME comment. > > Andrew. The patch is updated. Also the patch removing confusing resetting of UseBiasedLocking flag is added. Fedor -------------- next part -------------- A non-text attachment was scrubbed... Name: criticalJni.patch Type: text/x-diff Size: 438 bytes Desc: criticalJni.patch URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: remove-confusing-UseBiasedLocking.patch Type: text/x-diff Size: 573 bytes Desc: remove-confusing-UseBiasedLocking.patch URL: From fedor.burdun at azulsystems.com Fri Apr 15 14:54:49 2016 From: fedor.burdun at azulsystems.com (Fedor Burdun) Date: Fri, 15 Apr 2016 14:54:49 +0000 Subject: [8] RFR: a little clean-up Message-ID: <2C82F743BAC10D4D843822D7B0146F3B955B4608@MBX021-W3-CA-2.exch021.domain.local> Hi all, I would like to suggest to replace several __ call_Unimplemented() macros with asserts as in other ports. (x86, sparc,...) <<<<<<<<<<<<<<>>>>>>>>>>>>> diff --git a/src/cpu/aarch32/vm/macroAssembler_aarch32.hpp b/src/cpu/aarch32/vm/macroAssembler_aarch32.hpp --- a/src/cpu/aarch32/vm/macroAssembler_aarch32.hpp +++ b/src/cpu/aarch32/vm/macroAssembler_aarch32.hpp @@ -456,7 +456,6 @@ void load_heap_oop_not_null(Register dst, Address src); void store_heap_oop(Address dst, Register src); - // currently unimplemented // Used for storing NULL. All other oop constants should be // stored using routines that take a jobject. void store_heap_oop_null(Address dst); diff --git a/src/cpu/aarch32/vm/templateTable_aarch32.cpp b/src/cpu/aarch32/vm/templateTable_aarch32.cpp --- a/src/cpu/aarch32/vm/templateTable_aarch32.cpp +++ b/src/cpu/aarch32/vm/templateTable_aarch32.cpp @@ -3172,9 +3172,9 @@ //----------------------------------------------------------------------------- // Calls -void TemplateTable::count_calls(Register method, Register temp) -{ - __ call_Unimplemented(); +void TemplateTable::count_calls(Register method, Register temp) { + // implemented elsewhere + ShouldNotReachHere(); } void TemplateTable::prepare_invoke(int byte_no, @@ -3338,10 +3338,10 @@ __ jump_from_interpreted(rmethod, r0); } -void TemplateTable::fast_invokevfinal(int byte_no) -{ - __ call_Unimplemented(); -} +void TemplateTable::fast_invokevfinal(int byte_no) { + transition(vtos, vtos); + assert(byte_no == f2_byte, "use this argument"); + __ stop("fast_invokevfinal not used on aarch32");} void TemplateTable::invokeinterface(int byte_no) { transition(vtos, vtos); <<<<<<<<<<<<<<>>>>>>>>>>>>> The patch is in attachment too. Thanks, Fedor -------------- next part -------------- A non-text attachment was scrubbed... Name: cleanup-unimplemented.patch Type: text/x-diff Size: 1545 bytes Desc: cleanup-unimplemented.patch URL: From andrey.petushkov at gmail.com Thu Apr 28 10:49:30 2016 From: andrey.petushkov at gmail.com (Andrey Petushkov) Date: Thu, 28 Apr 2016 13:49:30 +0300 Subject: RFR: JDK-8155618 aarch32: implement CRC32 intrinsics Message-ID: <10D9A421-5B64-41C2-8BA4-2D9674A0EBBE@gmail.com> Dear Ed, All, Please consider the below patch to implement intrinsics for CRC32 functionality All 3 possible implementations are provided: generic cpu, neon and crc32 ARM v8 instruction based. The evaluated performance gain of the calculation itself is the following: cortex a7 a8 a53 c 123.487 132.013 309.565 asm 131.755 7% 141.297 7% 307.401 -1% neon 118.91 -4% 159.718 21% 479.442 55% crc32 1361.446 343% As you can see there is no benefit in using neon on Cortex A7 (and presumably A5). So neon is turned on by default only on Cortex A8 and above The above numbers are for CRC calculation itself, so elimination of JNI overhead provides additional benefit. E.g. on Cortex A7 the generic asm implementation gives the below benefit: buffer size + ops/s Xint 128 20.56% 512 18.06% 1024 14.66% 1048576 5.52% Xcomp Xbatch 128 77.85% 512 32.63% 1024 20.53% 1048576 6.59% The patch is here: http://cr.openjdk.java.net/~snazarki/8155618/ Thanks in advance, Andrey From edward.nevill at gmail.com Thu Apr 28 16:09:11 2016 From: edward.nevill at gmail.com (Edward Nevill) Date: Thu, 28 Apr 2016 17:09:11 +0100 Subject: [8] RFR: a little clean-up In-Reply-To: <2C82F743BAC10D4D843822D7B0146F3B955B4608@MBX021-W3-CA-2.exch021.domain.local> References: <2C82F743BAC10D4D843822D7B0146F3B955B4608@MBX021-W3-CA-2.exch021.domain.local> Message-ID: <1461859751.23523.2.camel@mint> Hi Fedor, Thanks for this. I have merged this with your previous patch "turn off critical jni" and will push both shortly. All the best, Ed. On Fri, 2016-04-15 at 14:54 +0000, Fedor Burdun wrote: > Hi all, > > I would like to suggest to replace several __ call_Unimplemented() macros with asserts as in other ports. (x86, sparc,...) From akashche at redhat.com Thu Apr 28 22:34:05 2016 From: akashche at redhat.com (Alex Kashchenko) Date: Thu, 28 Apr 2016 23:34:05 +0100 Subject: RFR: JDK-8155618 aarch32: implement CRC32 intrinsics In-Reply-To: <10D9A421-5B64-41C2-8BA4-2D9674A0EBBE@gmail.com> References: <10D9A421-5B64-41C2-8BA4-2D9674A0EBBE@gmail.com> Message-ID: <57228FDD.2060109@redhat.com> Hi Andrey, On 04/28/2016 11:49 AM, Andrey Petushkov wrote: > Dear Ed, All, > > Please consider the below patch to implement intrinsics for CRC32 functionality > All 3 possible implementations are provided: generic cpu, neon and crc32 ARM v8 instruction based. > The evaluated performance gain of the calculation itself is the following: > cortex a7 a8 a53 > c 123.487 132.013 309.565 > asm 131.755 7% 141.297 7% 307.401 -1% > neon 118.91 -4% 159.718 21% 479.442 55% > crc32 1361.446 343% > As you can see there is no benefit in using neon on Cortex A7 (and presumably A5). So neon is turned on by default only on Cortex A8 and above > > The above numbers are for CRC calculation itself, so elimination of JNI overhead provides additional benefit. E.g. on Cortex A7 the generic asm implementation gives the below benefit: > > buffer size + ops/s > Xint 128 20.56% > > 512 18.06% > > 1024 14.66% > > 1048576 5.52% > > > > Xcomp Xbatch 128 77.85% > > 512 32.63% > > 1024 20.53% > > 1048576 6.59% > > The patch is here: > http://cr.openjdk.java.net/~snazarki/8155618/ I am getting the following error in bootcycle build with this patch on Raspberry Pi 3: - crash log: http://cr.openjdk.java.net/~akasko/aarch32/jdk8u/8155618/hs_err_pid13951.log - build log: http://cr.openjdk.java.net/~akasko/aarch32/jdk8u/8155618/201604280_rpi3_rpm.log.xz I don't have any more details now, builds on all other devices are still in progress. This is the first time I see any problems with the build after prec1 change, so it may well be an incorrect patching or a hardware glitch. -- -Alex From akashche at redhat.com Fri Apr 29 09:58:16 2016 From: akashche at redhat.com (Alex Kashchenko) Date: Fri, 29 Apr 2016 10:58:16 +0100 Subject: [REF] more often tagging or syncing with upstream In-Reply-To: <562E7B79-2BEA-4B84-884A-42AAF92D8561@gmail.com> References: <56EAE706.1000106@redhat.com> <45673724.10758208.1458235548198.JavaMail.zimbra@redhat.com> <56F12D8D.3030206@redhat.com> <56FE7210.5040401@redhat.com> <1459852041.3488.1.camel@mylittlepony.linaroharston> <562E7B79-2BEA-4B84-884A-42AAF92D8561@gmail.com> Message-ID: <57233038.4040204@redhat.com> Hi Andrey, On 04/05/2016 05:06 PM, Andrey Petushkov wrote: > Hi Ed, > > One question, if you don?t mind. I see you use u76 in the label, but it looks to me that the state of the repo mostly resembles the u60. May I presume there are plans to update the repo to u76 state some time soon? How you plan for aarch32 project to keep up with mainline progress? On Azul side we still using u60 as a baseline but feel we got to update soon, so it would be nice to minimise the discrepancy between our codebases Will it be okay for you to update aarch32-jdk8u forest to jdk8u91-b14 tag from mainline jdk8u? This tag is used in aarch64-jdk8u. I am currently testing this tag merged into aarch32-jdk8u. You are probably aware about the "Better byte behavior" CPU change in that update, maybe you'll have some comments on that change regarding aarch32? > > Great thanks, > Andrey > >> On 05 Apr 2016, at 13:27, Edward Nevill wrote: >> >> OK. I tried tagging the tree with >> >> jdk8u76-b00-aarch32-160405 >> >> But I get >> >> (trusty)ed at localhost:/work/ed/aarch32/jdk8u/hotspot$ hg push >> pushing to ssh://enevill at hg.openjdk.java.net/aarch32-port/jdk8u/hotspot >> running ssh enevill at hg.openjdk.java.net 'hg -R aarch32-port/jdk8u/hotspot serve --stdio' >> searching for changes >> 1 changesets found >> remote: adding changesets >> remote: adding manifests >> remote: adding file changes >> remote: added 1 changesets with 1 changes to 1 files >> remote: [jcheck d46eaf84b346 2015-12-01 13:15:54 -0800] >> remote: >> remote: Illegal tag name: jdk8u76-b00-aarch32-160405 >> remote: >> remote: transaction abort! >> remote: rollback completed >> remote: abort: pretxnchangegroup.0.jcheck hook failed >> >> So, it seems like there are upstream restrictions on the tags we can use. >> >> Does anyone know the correct syntax of a tag? >> >> All the best, >> Ed. >> >> >> On Fri, 2016-04-01 at 15:05 +0200, Jiri Vanek wrote: >>> On 03/22/2016 12:33 PM, Jiri Vanek wrote: >>>> On 03/17/2016 06:25 PM, Andrew Hughes wrote: >>>> >>>> Ping? >>> >>> Ping ping? This would really help a lot! >>> >>> See laready runnign review: https://bugzilla.redhat.com/show_bug.cgi?id=1318988#c18 >>> >>>> >>>> FYI - https://bugzilla.redhat.com/show_bug.cgi?id=1318988 I already started the wheels of destiny, and I'm pretty sure the not-reproducible tarball will be the reelase blocker :( >>>> >>>> J. >>>>> ----- Original Message ----- >>>>>> Hello! >>>>>> >>>>>> I would like to introduce the aarch32 project to Fedora arm repositories. >>>>>> To create clearly reproducible source tarball I need some anchor. >>>>>> I think you will agree that cloning "tip" do not cover the reproducibility. >>>>>> Also I think you will agree that keeping somewhere list of changset ids used >>>>>> for source tarball is >>>>>> not exactly convenient. >>>>>> >>>>>> So I would like to kindly ask you for favour and to tag your project forest >>>>>> once per day or at least >>>>>> once per week or just when things look little bit more stable then yesterday >>>>>> (eg tomorrow:) ) >>>>>> >>>>>> We had chosen this approach for aarch64 releases [1] by prefixing by >>>>>> "aarch64" and incrementing >>>>>> build. As upstream builds are not exactly continuous, it works fine. But of >>>>>> course feel free to >>>>>> chose whatever suits you. >>>>>> >>>>>> I think that having small fedora arm32 community in testing audience may be >>>>>> just benefit for project. >>>>>> >>>>>> Thank you in advance! >>>>>> >>>>>> J. >>>>>> >>>>>> >>>>>> >>>>>> [1] >>>>>> http://hg.openjdk.java.net/aarch64-port/jdk8u/ >>>>>> 2 weeks ago andrew Added tag aarch64-jdk8u72-b16 for changeset >>>>>> 92af9369869fdefault tip >>>>>> 7 weeks ago andrew Added tag aarch64-jdk8u72-b15 for changeset >>>>>> 618f7e7b68f4aarch64-jdk8u72-b16 >>>>>> 7 weeks ago andrew Merge jdk8u72-b15aarch64-jdk8u72-b15 >>>>>> 2 months ago asaha Merge >>>>>> >>>>>> >>>>> >>>>> I don't think it needs to be as often as "once per day" as I doubt >>>>> the RPMs will be updated that frequently. It would however be good >>>> >>>> sure >>>> >>>>> to have a known good point to base Fedora RPMs on. This is beneficial >>>>> to the AArch32 project as well, as it is then clear what is being used >>>>> by these binaries out in the wild. >>>>> >>>>> Thanks, >>>>> >>>> >>> >> >> > -- -Alex From fedor.burdun at azulsystems.com Fri Apr 29 12:16:43 2016 From: fedor.burdun at azulsystems.com (Fedor Burdun) Date: Fri, 29 Apr 2016 12:16:43 +0000 Subject: [8u] RFR: fix of next pc calculation in handle_unsafe_access() Message-ID: <2C82F743BAC10D4D843822D7B0146F3B955C3297@MBX021-W3-CA-2.exch021.domain.local> Hi all, Please review fix of crash occurring in regression test (java/nio/MappedByteBuffer/Truncate.java). The problem is caused by skipping extra instructions in handle_unsafe_access() function after catching SIGBUS signal. Meanwhile this routine should skip only one instruction (as we can see on other platforms) The patch is in attachment. Thanks, Fedor -------------- next part -------------- A non-text attachment was scrubbed... Name: unsafe-handler.patch Type: text/x-diff Size: 569 bytes Desc: unsafe-handler.patch URL: From andrey.petushkov at gmail.com Fri Apr 29 13:59:43 2016 From: andrey.petushkov at gmail.com (Andrey Petushkov) Date: Fri, 29 Apr 2016 16:59:43 +0300 Subject: [REF] more often tagging or syncing with upstream In-Reply-To: <57233038.4040204@redhat.com> References: <56EAE706.1000106@redhat.com> <45673724.10758208.1458235548198.JavaMail.zimbra@redhat.com> <56F12D8D.3030206@redhat.com> <56FE7210.5040401@redhat.com> <1459852041.3488.1.camel@mylittlepony.linaroharston> <562E7B79-2BEA-4B84-884A-42AAF92D8561@gmail.com> <57233038.4040204@redhat.com> Message-ID: Hi Alex, > On 29 Apr 2016, at 12:58, Alex Kashchenko wrote: > > Hi Andrey, > > On 04/05/2016 05:06 PM, Andrey Petushkov wrote: >> Hi Ed, >> >> One question, if you don?t mind. I see you use u76 in the label, but it looks to me that the state of the repo mostly resembles the u60. May I presume there are plans to update the repo to u76 state some time soon? How you plan for aarch32 project to keep up with mainline progress? On Azul side we still using u60 as a baseline but feel we got to update soon, so it would be nice to minimise the discrepancy between our codebases > > Will it be okay for you to update aarch32-jdk8u forest to jdk8u91-b14 tag from mainline jdk8u? This tag is used in aarch64-jdk8u. I am currently testing this tag merged into aarch32-jdk8u. That would be awesome to update the aarch32-8u to the latest jdk8 update. We?re currently using u77 internally so the discrepancy between openjdk and internal repos brings some pain? We?d be happy to make an update but not in the absence of Ed?s approval.. > > You are probably aware about the "Better byte behavior" CPU change in that update, maybe you'll have some comments on that change regarding aarch32? We planned to implement it for aarch32 in a nearest time, however at the moment we don?t have it on hands Thanks, Andrey > >> >> Great thanks, >> Andrey >> >>> On 05 Apr 2016, at 13:27, Edward Nevill wrote: >>> >>> OK. I tried tagging the tree with >>> >>> jdk8u76-b00-aarch32-160405 >>> >>> But I get >>> >>> (trusty)ed at localhost:/work/ed/aarch32/jdk8u/hotspot$ hg push >>> pushing to ssh://enevill at hg.openjdk.java.net/aarch32-port/jdk8u/hotspot >>> running ssh enevill at hg.openjdk.java.net 'hg -R aarch32-port/jdk8u/hotspot serve --stdio' >>> searching for changes >>> 1 changesets found >>> remote: adding changesets >>> remote: adding manifests >>> remote: adding file changes >>> remote: added 1 changesets with 1 changes to 1 files >>> remote: [jcheck d46eaf84b346 2015-12-01 13:15:54 -0800] >>> remote: >>> remote: Illegal tag name: jdk8u76-b00-aarch32-160405 >>> remote: >>> remote: transaction abort! >>> remote: rollback completed >>> remote: abort: pretxnchangegroup.0.jcheck hook failed >>> >>> So, it seems like there are upstream restrictions on the tags we can use. >>> >>> Does anyone know the correct syntax of a tag? >>> >>> All the best, >>> Ed. >>> >>> >>> On Fri, 2016-04-01 at 15:05 +0200, Jiri Vanek wrote: >>>> On 03/22/2016 12:33 PM, Jiri Vanek wrote: >>>>> On 03/17/2016 06:25 PM, Andrew Hughes wrote: >>>>> >>>>> Ping? >>>> >>>> Ping ping? This would really help a lot! >>>> >>>> See laready runnign review: https://bugzilla.redhat.com/show_bug.cgi?id=1318988#c18 >>>> >>>>> >>>>> FYI - https://bugzilla.redhat.com/show_bug.cgi?id=1318988 I already started the wheels of destiny, and I'm pretty sure the not-reproducible tarball will be the reelase blocker :( >>>>> >>>>> J. >>>>>> ----- Original Message ----- >>>>>>> Hello! >>>>>>> >>>>>>> I would like to introduce the aarch32 project to Fedora arm repositories. >>>>>>> To create clearly reproducible source tarball I need some anchor. >>>>>>> I think you will agree that cloning "tip" do not cover the reproducibility. >>>>>>> Also I think you will agree that keeping somewhere list of changset ids used >>>>>>> for source tarball is >>>>>>> not exactly convenient. >>>>>>> >>>>>>> So I would like to kindly ask you for favour and to tag your project forest >>>>>>> once per day or at least >>>>>>> once per week or just when things look little bit more stable then yesterday >>>>>>> (eg tomorrow:) ) >>>>>>> >>>>>>> We had chosen this approach for aarch64 releases [1] by prefixing by >>>>>>> "aarch64" and incrementing >>>>>>> build. As upstream builds are not exactly continuous, it works fine. But of >>>>>>> course feel free to >>>>>>> chose whatever suits you. >>>>>>> >>>>>>> I think that having small fedora arm32 community in testing audience may be >>>>>>> just benefit for project. >>>>>>> >>>>>>> Thank you in advance! >>>>>>> >>>>>>> J. >>>>>>> >>>>>>> >>>>>>> >>>>>>> [1] >>>>>>> http://hg.openjdk.java.net/aarch64-port/jdk8u/ >>>>>>> 2 weeks ago andrew Added tag aarch64-jdk8u72-b16 for changeset >>>>>>> 92af9369869fdefault tip >>>>>>> 7 weeks ago andrew Added tag aarch64-jdk8u72-b15 for changeset >>>>>>> 618f7e7b68f4aarch64-jdk8u72-b16 >>>>>>> 7 weeks ago andrew Merge jdk8u72-b15aarch64-jdk8u72-b15 >>>>>>> 2 months ago asaha Merge >>>>>>> >>>>>>> >>>>>> >>>>>> I don't think it needs to be as often as "once per day" as I doubt >>>>>> the RPMs will be updated that frequently. It would however be good >>>>> >>>>> sure >>>>> >>>>>> to have a known good point to base Fedora RPMs on. This is beneficial >>>>>> to the AArch32 project as well, as it is then clear what is being used >>>>>> by these binaries out in the wild. >>>>>> >>>>>> Thanks, >>>>>> >>>>> >>>> >>> >>> >> > > > -- > -Alex From akashche at redhat.com Fri Apr 29 14:18:44 2016 From: akashche at redhat.com (Alex Kashchenko) Date: Fri, 29 Apr 2016 15:18:44 +0100 Subject: [REF] more often tagging or syncing with upstream In-Reply-To: References: <56EAE706.1000106@redhat.com> <45673724.10758208.1458235548198.JavaMail.zimbra@redhat.com> <56F12D8D.3030206@redhat.com> <56FE7210.5040401@redhat.com> <1459852041.3488.1.camel@mylittlepony.linaroharston> <562E7B79-2BEA-4B84-884A-42AAF92D8561@gmail.com> <57233038.4040204@redhat.com> Message-ID: <57236D44.7020709@redhat.com> Hi Andrey, On 04/29/2016 02:59 PM, Andrey Petushkov wrote: > Hi Alex, > >> On 29 Apr 2016, at 12:58, Alex Kashchenko wrote: >> >> Hi Andrey, >> >> On 04/05/2016 05:06 PM, Andrey Petushkov wrote: >>> Hi Ed, >>> >>> One question, if you don?t mind. I see you use u76 in the label, but it looks to me that the state of the repo mostly resembles the u60. May I presume there are plans to update the repo to u76 state some time soon? How you plan for aarch32 project to keep up with mainline progress? On Azul side we still using u60 as a baseline but feel we got to update soon, so it would be nice to minimise the discrepancy between our codebases >> >> Will it be okay for you to update aarch32-jdk8u forest to jdk8u91-b14 tag from mainline jdk8u? This tag is used in aarch64-jdk8u. I am currently testing this tag merged into aarch32-jdk8u. > That would be awesome to update the aarch32-8u to the latest jdk8 update. We?re currently using u77 internally so the discrepancy between openjdk and internal repos brings some pain? We?d be happy to make an update but not in the absence of Ed?s approval.. So, if you prefer jdk8 tip - I'll try to merge/build/test it instead of jdk8u91-b14. I will wait for Edward's decision here before posting anything for review. >> >> You are probably aware about the "Better byte behavior" CPU change in that update, maybe you'll have some comments on that change regarding aarch32? > We planned to implement it for aarch32 in a nearest time, however at the moment we don?t have it on hands AFAIU that hotspot change doesn't block updates of non-hotspot parts. So I will proceed with non-hotspot merging. > > Thanks, > Andrey >> >>> >>> Great thanks, >>> Andrey >>> >>>> On 05 Apr 2016, at 13:27, Edward Nevill wrote: >>>> >>>> OK. I tried tagging the tree with >>>> >>>> jdk8u76-b00-aarch32-160405 >>>> >>>> But I get >>>> >>>> (trusty)ed at localhost:/work/ed/aarch32/jdk8u/hotspot$ hg push >>>> pushing to ssh://enevill at hg.openjdk.java.net/aarch32-port/jdk8u/hotspot >>>> running ssh enevill at hg.openjdk.java.net 'hg -R aarch32-port/jdk8u/hotspot serve --stdio' >>>> searching for changes >>>> 1 changesets found >>>> remote: adding changesets >>>> remote: adding manifests >>>> remote: adding file changes >>>> remote: added 1 changesets with 1 changes to 1 files >>>> remote: [jcheck d46eaf84b346 2015-12-01 13:15:54 -0800] >>>> remote: >>>> remote: Illegal tag name: jdk8u76-b00-aarch32-160405 >>>> remote: >>>> remote: transaction abort! >>>> remote: rollback completed >>>> remote: abort: pretxnchangegroup.0.jcheck hook failed >>>> >>>> So, it seems like there are upstream restrictions on the tags we can use. >>>> >>>> Does anyone know the correct syntax of a tag? >>>> >>>> All the best, >>>> Ed. >>>> >>>> >>>> On Fri, 2016-04-01 at 15:05 +0200, Jiri Vanek wrote: >>>>> On 03/22/2016 12:33 PM, Jiri Vanek wrote: >>>>>> On 03/17/2016 06:25 PM, Andrew Hughes wrote: >>>>>> >>>>>> Ping? >>>>> >>>>> Ping ping? This would really help a lot! >>>>> >>>>> See laready runnign review: https://bugzilla.redhat.com/show_bug.cgi?id=1318988#c18 >>>>> >>>>>> >>>>>> FYI - https://bugzilla.redhat.com/show_bug.cgi?id=1318988 I already started the wheels of destiny, and I'm pretty sure the not-reproducible tarball will be the reelase blocker :( >>>>>> >>>>>> J. >>>>>>> ----- Original Message ----- >>>>>>>> Hello! >>>>>>>> >>>>>>>> I would like to introduce the aarch32 project to Fedora arm repositories. >>>>>>>> To create clearly reproducible source tarball I need some anchor. >>>>>>>> I think you will agree that cloning "tip" do not cover the reproducibility. >>>>>>>> Also I think you will agree that keeping somewhere list of changset ids used >>>>>>>> for source tarball is >>>>>>>> not exactly convenient. >>>>>>>> >>>>>>>> So I would like to kindly ask you for favour and to tag your project forest >>>>>>>> once per day or at least >>>>>>>> once per week or just when things look little bit more stable then yesterday >>>>>>>> (eg tomorrow:) ) >>>>>>>> >>>>>>>> We had chosen this approach for aarch64 releases [1] by prefixing by >>>>>>>> "aarch64" and incrementing >>>>>>>> build. As upstream builds are not exactly continuous, it works fine. But of >>>>>>>> course feel free to >>>>>>>> chose whatever suits you. >>>>>>>> >>>>>>>> I think that having small fedora arm32 community in testing audience may be >>>>>>>> just benefit for project. >>>>>>>> >>>>>>>> Thank you in advance! >>>>>>>> >>>>>>>> J. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> [1] >>>>>>>> http://hg.openjdk.java.net/aarch64-port/jdk8u/ >>>>>>>> 2 weeks ago andrew Added tag aarch64-jdk8u72-b16 for changeset >>>>>>>> 92af9369869fdefault tip >>>>>>>> 7 weeks ago andrew Added tag aarch64-jdk8u72-b15 for changeset >>>>>>>> 618f7e7b68f4aarch64-jdk8u72-b16 >>>>>>>> 7 weeks ago andrew Merge jdk8u72-b15aarch64-jdk8u72-b15 >>>>>>>> 2 months ago asaha Merge >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> I don't think it needs to be as often as "once per day" as I doubt >>>>>>> the RPMs will be updated that frequently. It would however be good >>>>>> >>>>>> sure >>>>>> >>>>>>> to have a known good point to base Fedora RPMs on. This is beneficial >>>>>>> to the AArch32 project as well, as it is then clear what is being used >>>>>>> by these binaries out in the wild. >>>>>>> >>>>>>> Thanks, >>>>>>> >>>>>> >>>>> >>>> >>>> >>> >> >> >> -- >> -Alex > > -- -Alex From andrey.petushkov at gmail.com Fri Apr 29 14:22:34 2016 From: andrey.petushkov at gmail.com (Andrey Petushkov) Date: Fri, 29 Apr 2016 17:22:34 +0300 Subject: [REF] more often tagging or syncing with upstream In-Reply-To: <57236D44.7020709@redhat.com> References: <56EAE706.1000106@redhat.com> <45673724.10758208.1458235548198.JavaMail.zimbra@redhat.com> <56F12D8D.3030206@redhat.com> <56FE7210.5040401@redhat.com> <1459852041.3488.1.camel@mylittlepony.linaroharston> <562E7B79-2BEA-4B84-884A-42AAF92D8561@gmail.com> <57233038.4040204@redhat.com> <57236D44.7020709@redhat.com> Message-ID: <5235DB1D-72B4-405E-85E7-5E04A8A228E6@gmail.com> Hi Alex, > On 29 Apr 2016, at 17:18, Alex Kashchenko wrote: > > Hi Andrey, > > On 04/29/2016 02:59 PM, Andrey Petushkov wrote: >> Hi Alex, >> >>> On 29 Apr 2016, at 12:58, Alex Kashchenko wrote: >>> >>> Hi Andrey, >>> >>> On 04/05/2016 05:06 PM, Andrey Petushkov wrote: >>>> Hi Ed, >>>> >>>> One question, if you don?t mind. I see you use u76 in the label, but it looks to me that the state of the repo mostly resembles the u60. May I presume there are plans to update the repo to u76 state some time soon? How you plan for aarch32 project to keep up with mainline progress? On Azul side we still using u60 as a baseline but feel we got to update soon, so it would be nice to minimise the discrepancy between our codebases >>> >>> Will it be okay for you to update aarch32-jdk8u forest to jdk8u91-b14 tag from mainline jdk8u? This tag is used in aarch64-jdk8u. I am currently testing this tag merged into aarch32-jdk8u. >> That would be awesome to update the aarch32-8u to the latest jdk8 update. We?re currently using u77 internally so the discrepancy between openjdk and internal repos brings some pain? We?d be happy to make an update but not in the absence of Ed?s approval.. > > So, if you prefer jdk8 tip - I'll try to merge/build/test it instead of jdk8u91-b14. I will wait for Edward's decision here before posting anything for review. Pardon for obscure language, 8u91 is better but with me > >>> >>> You are probably aware about the "Better byte behavior" CPU change in that update, maybe you'll have some comments on that change regarding aarch32? >> We planned to implement it for aarch32 in a nearest time, however at the moment we don?t have it on hands > > AFAIU that hotspot change doesn't block updates of non-hotspot parts. So I will proceed with non-hotspot merging. Cool! Thanks a lot for that! Regards, Andrey > >> >> Thanks, >> Andrey >>> >>>> >>>> Great thanks, >>>> Andrey >>>> >>>>> On 05 Apr 2016, at 13:27, Edward Nevill wrote: >>>>> >>>>> OK. I tried tagging the tree with >>>>> >>>>> jdk8u76-b00-aarch32-160405 >>>>> >>>>> But I get >>>>> >>>>> (trusty)ed at localhost:/work/ed/aarch32/jdk8u/hotspot$ hg push >>>>> pushing to ssh://enevill at hg.openjdk.java.net/aarch32-port/jdk8u/hotspot >>>>> running ssh enevill at hg.openjdk.java.net 'hg -R aarch32-port/jdk8u/hotspot serve --stdio' >>>>> searching for changes >>>>> 1 changesets found >>>>> remote: adding changesets >>>>> remote: adding manifests >>>>> remote: adding file changes >>>>> remote: added 1 changesets with 1 changes to 1 files >>>>> remote: [jcheck d46eaf84b346 2015-12-01 13:15:54 -0800] >>>>> remote: >>>>> remote: Illegal tag name: jdk8u76-b00-aarch32-160405 >>>>> remote: >>>>> remote: transaction abort! >>>>> remote: rollback completed >>>>> remote: abort: pretxnchangegroup.0.jcheck hook failed >>>>> >>>>> So, it seems like there are upstream restrictions on the tags we can use. >>>>> >>>>> Does anyone know the correct syntax of a tag? >>>>> >>>>> All the best, >>>>> Ed. >>>>> >>>>> >>>>> On Fri, 2016-04-01 at 15:05 +0200, Jiri Vanek wrote: >>>>>> On 03/22/2016 12:33 PM, Jiri Vanek wrote: >>>>>>> On 03/17/2016 06:25 PM, Andrew Hughes wrote: >>>>>>> >>>>>>> Ping? >>>>>> >>>>>> Ping ping? This would really help a lot! >>>>>> >>>>>> See laready runnign review: https://bugzilla.redhat.com/show_bug.cgi?id=1318988#c18 >>>>>> >>>>>>> >>>>>>> FYI - https://bugzilla.redhat.com/show_bug.cgi?id=1318988 I already started the wheels of destiny, and I'm pretty sure the not-reproducible tarball will be the reelase blocker :( >>>>>>> >>>>>>> J. >>>>>>>> ----- Original Message ----- >>>>>>>>> Hello! >>>>>>>>> >>>>>>>>> I would like to introduce the aarch32 project to Fedora arm repositories. >>>>>>>>> To create clearly reproducible source tarball I need some anchor. >>>>>>>>> I think you will agree that cloning "tip" do not cover the reproducibility. >>>>>>>>> Also I think you will agree that keeping somewhere list of changset ids used >>>>>>>>> for source tarball is >>>>>>>>> not exactly convenient. >>>>>>>>> >>>>>>>>> So I would like to kindly ask you for favour and to tag your project forest >>>>>>>>> once per day or at least >>>>>>>>> once per week or just when things look little bit more stable then yesterday >>>>>>>>> (eg tomorrow:) ) >>>>>>>>> >>>>>>>>> We had chosen this approach for aarch64 releases [1] by prefixing by >>>>>>>>> "aarch64" and incrementing >>>>>>>>> build. As upstream builds are not exactly continuous, it works fine. But of >>>>>>>>> course feel free to >>>>>>>>> chose whatever suits you. >>>>>>>>> >>>>>>>>> I think that having small fedora arm32 community in testing audience may be >>>>>>>>> just benefit for project. >>>>>>>>> >>>>>>>>> Thank you in advance! >>>>>>>>> >>>>>>>>> J. >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> [1] >>>>>>>>> http://hg.openjdk.java.net/aarch64-port/jdk8u/ >>>>>>>>> 2 weeks ago andrew Added tag aarch64-jdk8u72-b16 for changeset >>>>>>>>> 92af9369869fdefault tip >>>>>>>>> 7 weeks ago andrew Added tag aarch64-jdk8u72-b15 for changeset >>>>>>>>> 618f7e7b68f4aarch64-jdk8u72-b16 >>>>>>>>> 7 weeks ago andrew Merge jdk8u72-b15aarch64-jdk8u72-b15 >>>>>>>>> 2 months ago asaha Merge >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> I don't think it needs to be as often as "once per day" as I doubt >>>>>>>> the RPMs will be updated that frequently. It would however be good >>>>>>> >>>>>>> sure >>>>>>> >>>>>>>> to have a known good point to base Fedora RPMs on. This is beneficial >>>>>>>> to the AArch32 project as well, as it is then clear what is being used >>>>>>>> by these binaries out in the wild. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> >>>>>>> >>>>>> >>>>> >>>>> >>>> >>> >>> >>> -- >>> -Alex >> >> > > > -- > -Alex From edward.nevill at gmail.com Fri Apr 29 14:36:46 2016 From: edward.nevill at gmail.com (Edward Nevill) Date: Fri, 29 Apr 2016 15:36:46 +0100 Subject: [REF] more often tagging or syncing with upstream In-Reply-To: <5235DB1D-72B4-405E-85E7-5E04A8A228E6@gmail.com> References: <56EAE706.1000106@redhat.com> <45673724.10758208.1458235548198.JavaMail.zimbra@redhat.com> <56F12D8D.3030206@redhat.com> <56FE7210.5040401@redhat.com> <1459852041.3488.1.camel@mylittlepony.linaroharston> <562E7B79-2BEA-4B84-884A-42AAF92D8561@gmail.com> <57233038.4040204@redhat.com> <57236D44.7020709@redhat.com> <5235DB1D-72B4-405E-85E7-5E04A8A228E6@gmail.com> Message-ID: <1461940606.12456.1.camel@mint> On Fri, 2016-04-29 at 17:22 +0300, Andrey Petushkov wrote: > > > That would be awesome to update the aarch32-8u to the latest jdk8 > > > update. We?re currently using u77 internally so the discrepancy > > > between openjdk and internal repos brings some pain? We?d be happy > > > to make an update but not in the absence of Ed?s approval.. > > > > So, if you prefer jdk8 tip - I'll try to merge/build/test it instead > > of jdk8u91-b14. I will wait for Edward's decision here before > > posting anything for review. > > > Pardon for obscure language, 8u91 is better but with me > > > > > > > > > > You are probably aware about the "Better byte behavior" CPU > > > > change in that update, maybe you'll have some comments on that > > > > change regarding aarch32? > > > We planned to implement it for aarch32 in a nearest time, however > > > at the moment we don?t have it on hands > > jdk8u91-b14 is fine by me. All the best, Ed. From andrey.petushkov at gmail.com Fri Apr 29 14:59:16 2016 From: andrey.petushkov at gmail.com (Andrey Petushkov) Date: Fri, 29 Apr 2016 17:59:16 +0300 Subject: RFR: JDK-8155618 aarch32: implement CRC32 intrinsics In-Reply-To: <57228FDD.2060109@redhat.com> References: <10D9A421-5B64-41C2-8BA4-2D9674A0EBBE@gmail.com> <57228FDD.2060109@redhat.com> Message-ID: <3DBDF50E-0881-4C79-8ADE-A0E77DE133F6@gmail.com> Hi Alex, In the meanwhile I?ve found one bug in the cc32-based implementation, which is exactly the one chosen on rpi3 by default. Could you please reapply the patch from the same location. Please let me know if the problem persists Great thanks, Andrey > On 29 Apr 2016, at 01:34, Alex Kashchenko wrote: > > Hi Andrey, > > On 04/28/2016 11:49 AM, Andrey Petushkov wrote: >> Dear Ed, All, >> >> Please consider the below patch to implement intrinsics for CRC32 functionality >> All 3 possible implementations are provided: generic cpu, neon and crc32 ARM v8 instruction based. >> The evaluated performance gain of the calculation itself is the following: >> cortex a7 a8 a53 >> c 123.487 132.013 309.565 >> asm 131.755 7% 141.297 7% 307.401 -1% >> neon 118.91 -4% 159.718 21% 479.442 55% >> crc32 1361.446 343% >> As you can see there is no benefit in using neon on Cortex A7 (and presumably A5). So neon is turned on by default only on Cortex A8 and above >> >> The above numbers are for CRC calculation itself, so elimination of JNI overhead provides additional benefit. E.g. on Cortex A7 the generic asm implementation gives the below benefit: >> >> buffer size + ops/s >> Xint 128 20.56% >> >> 512 18.06% >> >> 1024 14.66% >> >> 1048576 5.52% >> >> >> >> Xcomp Xbatch 128 77.85% >> >> 512 32.63% >> >> 1024 20.53% >> >> 1048576 6.59% >> >> The patch is here: >> http://cr.openjdk.java.net/~snazarki/8155618/ > > > I am getting the following error in bootcycle build with this patch on Raspberry Pi 3: > > - crash log: http://cr.openjdk.java.net/~akasko/aarch32/jdk8u/8155618/hs_err_pid13951.log > - build log: http://cr.openjdk.java.net/~akasko/aarch32/jdk8u/8155618/201604280_rpi3_rpm.log.xz > > I don't have any more details now, builds on all other devices are still in progress. This is the first time I see any problems with the build after prec1 change, so it may well be an incorrect patching or a hardware glitch. > > -- > -Alex From akashche at redhat.com Fri Apr 29 17:43:49 2016 From: akashche at redhat.com (Alex Kashchenko) Date: Fri, 29 Apr 2016 18:43:49 +0100 Subject: RFR: JDK-8155618 aarch32: implement CRC32 intrinsics In-Reply-To: <3DBDF50E-0881-4C79-8ADE-A0E77DE133F6@gmail.com> References: <10D9A421-5B64-41C2-8BA4-2D9674A0EBBE@gmail.com> <57228FDD.2060109@redhat.com> <3DBDF50E-0881-4C79-8ADE-A0E77DE133F6@gmail.com> Message-ID: <57239D55.6070105@redhat.com> Hi Andrey, On 04/29/2016 03:59 PM, Andrey Petushkov wrote: > Hi Alex, > > In the meanwhile I?ve found one bug in the cc32-based implementation, which is exactly the one chosen on rpi3 by default. Could you please reapply the patch from the same location. Please let me know if the problem persists I restarted the builds with the new patch. I haven't look at the details or a minimal reproducer yet - will wait for the new builds to finish. > > Great thanks, > Andrey > >> On 29 Apr 2016, at 01:34, Alex Kashchenko wrote: >> >> Hi Andrey, >> >> On 04/28/2016 11:49 AM, Andrey Petushkov wrote: >>> Dear Ed, All, >>> >>> Please consider the below patch to implement intrinsics for CRC32 functionality >>> All 3 possible implementations are provided: generic cpu, neon and crc32 ARM v8 instruction based. >>> The evaluated performance gain of the calculation itself is the following: >>> cortex a7 a8 a53 >>> c 123.487 132.013 309.565 >>> asm 131.755 7% 141.297 7% 307.401 -1% >>> neon 118.91 -4% 159.718 21% 479.442 55% >>> crc32 1361.446 343% >>> As you can see there is no benefit in using neon on Cortex A7 (and presumably A5). So neon is turned on by default only on Cortex A8 and above >>> >>> The above numbers are for CRC calculation itself, so elimination of JNI overhead provides additional benefit. E.g. on Cortex A7 the generic asm implementation gives the below benefit: >>> >>> buffer size + ops/s >>> Xint 128 20.56% >>> >>> 512 18.06% >>> >>> 1024 14.66% >>> >>> 1048576 5.52% >>> >>> >>> >>> Xcomp Xbatch 128 77.85% >>> >>> 512 32.63% >>> >>> 1024 20.53% >>> >>> 1048576 6.59% >>> >>> The patch is here: >>> http://cr.openjdk.java.net/~snazarki/8155618/ > >> >> I am getting the following error in bootcycle build with this patch on Raspberry Pi 3: >> >> - crash log: http://cr.openjdk.java.net/~akasko/aarch32/jdk8u/8155618/hs_err_pid13951.log >> - build log: http://cr.openjdk.java.net/~akasko/aarch32/jdk8u/8155618/201604280_rpi3_rpm.log.xz >> >> I don't have any more details now, builds on all other devices are still in progress. This is the first time I see any problems with the build after prec1 change, so it may well be an incorrect patching or a hardware glitch. >> >> -- >> -Alex > > -- -Alex From andrey.petushkov at gmail.com Fri Apr 29 20:01:12 2016 From: andrey.petushkov at gmail.com (Andrey Petushkov) Date: Fri, 29 Apr 2016 20:01:12 +0000 Subject: RFR: JDK-8155618 aarch32: implement CRC32 intrinsics In-Reply-To: <57239D55.6070105@redhat.com> References: <10D9A421-5B64-41C2-8BA4-2D9674A0EBBE@gmail.com> <57228FDD.2060109@redhat.com> <3DBDF50E-0881-4C79-8ADE-A0E77DE133F6@gmail.com> <57239D55.6070105@redhat.com> Message-ID: Great thanks! Indeed the problem was such that it could manifest itself in a random way. So hopefully it's fixed now Regards, Andrey On Fri, Apr 29, 2016 at 8:43 PM Alex Kashchenko wrote: > Hi Andrey, > > On 04/29/2016 03:59 PM, Andrey Petushkov wrote: > > Hi Alex, > > > > In the meanwhile I?ve found one bug in the cc32-based implementation, > which is exactly the one chosen on rpi3 by default. Could you please > reapply the patch from the same location. Please let me know if the problem > persists > > I restarted the builds with the new patch. I haven't look at the details > or a minimal reproducer yet - will wait for the new builds to finish. > > > > > Great thanks, > > Andrey > > > >> On 29 Apr 2016, at 01:34, Alex Kashchenko wrote: > >> > >> Hi Andrey, > >> > >> On 04/28/2016 11:49 AM, Andrey Petushkov wrote: > >>> Dear Ed, All, > >>> > >>> Please consider the below patch to implement intrinsics for CRC32 > functionality > >>> All 3 possible implementations are provided: generic cpu, neon and > crc32 ARM v8 instruction based. > >>> The evaluated performance gain of the calculation itself is the > following: > >>> cortex a7 a8 a53 > >>> c 123.487 132.013 309.565 > >>> asm 131.755 7% 141.297 7% 307.401 -1% > >>> neon 118.91 -4% 159.718 21% 479.442 55% > >>> crc32 1361.446 343% > >>> As you can see there is no benefit in using neon on Cortex A7 (and > presumably A5). So neon is turned on by default only on Cortex A8 and above > >>> > >>> The above numbers are for CRC calculation itself, so elimination of > JNI overhead provides additional benefit. E.g. on Cortex A7 the generic asm > implementation gives the below benefit: > >>> > >>> buffer size + ops/s > >>> Xint 128 20.56% > >>> > >>> 512 18.06% > >>> > >>> 1024 14.66% > >>> > >>> 1048576 5.52% > >>> > >>> > >>> > >>> Xcomp Xbatch 128 77.85% > >>> > >>> 512 32.63% > >>> > >>> 1024 20.53% > >>> > >>> 1048576 6.59% > >>> > >>> The patch is here: > >>> http://cr.openjdk.java.net/~snazarki/8155618/ < > http://cr.openjdk.java.net/~snazarki/8155618/> < > http://cr.openjdk.java.net/~snazarki/8155618/ < > http://cr.openjdk.java.net/~snazarki/8155618/>> > >> > >> I am getting the following error in bootcycle build with this patch on > Raspberry Pi 3: > >> > >> - crash log: > http://cr.openjdk.java.net/~akasko/aarch32/jdk8u/8155618/hs_err_pid13951.log > < > http://cr.openjdk.java.net/~akasko/aarch32/jdk8u/8155618/hs_err_pid13951.log > > > >> - build log: > http://cr.openjdk.java.net/~akasko/aarch32/jdk8u/8155618/201604280_rpi3_rpm.log.xz > < > http://cr.openjdk.java.net/~akasko/aarch32/jdk8u/8155618/201604280_rpi3_rpm.log.xz > > > >> > >> I don't have any more details now, builds on all other devices are > still in progress. This is the first time I see any problems with the build > after prec1 change, so it may well be an incorrect patching or a hardware > glitch. > >> > >> -- > >> -Alex > > > > > > > -- > -Alex >