October 2014 - aarch64-port-dev

icedtea7-aarch64 port changeset 5662 : make static stubs load methodOop in cpool to avoid problems at GC
by Andrew Dinn 11 Nov '14

11 Nov '14

# HG changeset patch # User adinn # Date 1413452611 -3600 # Thu Oct 16 10:43:31 2014 +0100 # Node ID 32975889f68331dd94b3a6bb1d44c31596e77a12 # Parent efb9bd97f6ec88d213ac0b546c7806ef1300b015 make static stubs load methodOop in cpool to avoid problems at GC jdk7 needs to insert method oops for static/virtual calls using movoop instead of movptr. the same applies for static stubs. we would like to use a simple mov immediate with no oop record to do the patching but that falls foul of the reloc code. we can use a mov immediate /with/ an oop record for the static/virtual call. however if we do that for the stub load then the oop does not get updated and a GC causes the patched stub oop to be reverted to movz/k 0x0000. in order to avoid this we have to do the stub oop load via the cpool using a ldr. diff -r efb9bd97f6ec -r 32975889f683 src/cpu/aarch64/vm/aarch64.ad --- a/src/cpu/aarch64/vm/aarch64.ad Tue Oct 14 15:23:46 2014 +0100 +++ b/src/cpu/aarch64/vm/aarch64.ad Thu Oct 16 10:43:31 2014 +0100 @@ -1395,8 +1395,12 @@ // static stub relocation stores the instruction address of the call const RelocationHolder &rspec = static_stub_Relocation::spec(mark); __ relocate(rspec); + // !!! FIXME AARCH64 // static stub relocation also tags the methodOop in the code-stream. - __ movoop(rmethod, (jobject) NULL, /*immediate*/true); + // for jdk7 we have to use movoop and locate the oop in the cpool + // if we use an immediate then patching fails to update the pool + // oop and GC overwrites the patch with movk/z 0x0000 again + __ movoop(rmethod, (jobject) NULL); // This is recognized as unresolved by relocs/nativeinst/ic code __ b(__ pc()); @@ -2842,7 +2846,8 @@ MacroAssembler _masm(&cbuf); address entry = (address)$meth$$method; RelocationHolder rh = virtual_call_Relocation::spec(__ pc()); - __ movptr(rscratch2, (uintptr_t)Universe::non_oop_word()); + // we use movoop here as per emit_java_to_interp and c1's ic_call + __ movoop(rscratch2, (jobject)Universe::non_oop_word(), /*immediate*/true); __ bl(Address(entry, rh)); %} diff -r efb9bd97f6ec -r 32975889f683 src/cpu/aarch64/vm/c1_LIRAssembler_aarch64.cpp --- a/src/cpu/aarch64/vm/c1_LIRAssembler_aarch64.cpp Tue Oct 14 15:23:46 2014 +0100 +++ b/src/cpu/aarch64/vm/c1_LIRAssembler_aarch64.cpp Thu Oct 16 10:43:31 2014 +0100 @@ -1986,8 +1986,12 @@ int start = __ offset(); __ relocate(static_stub_Relocation::spec(call_pc)); - // n.b. pass immediate = true because we want to be able to patch this - __ movoop(rmethod, (jobject)NULL, /*immediate*/true); + // !!! FIXME AARCH64 + // static stub relocation also tags the methodOop in the code-stream. + // for jdk7 we have to use movoop and locate the oop in the cpool + // if we use an immediate then patching fails to update the pool + // oop and GC overwrites the patch with movk/z 0x0000 again + __ movoop(rmethod, (jobject)NULL); __ b(__ pc()); assert(__ offset() - start <= call_stub_size, "stub too big");

2 5

RFR: Add support for pipeline scheduling
by Edward Nevill 03 Nov '14

03 Nov '14

Hi, The following webrev is a first pass at adding pipeline scheduling to JDK8. The pipeline implementation is modeled on A53. http://openjdk.linaro.org/webrev/141031/hotspot/ - The model only models 4 stages ISS1, EX1, EX2 and WR. It does not model the additional 4 stages in the fetch and decode stages of the pipeline because these are fixed and therefore make no difference to the scheduling. - The A53 pipeline is dual issue and this is modeled by having 2 dummy resources 'INS0' and 'INS1' and a combined resource 'INS01' which means an instruction can issue as either instruction 0 or instruction 1. The resource INS0, INS1 or INS01 is used in the ISS stage. - The different A53 pipelines (ALU0, ALU1, MAC, DIV, STORE & BRANCH) are modeled as resources (ALU, MAC, DEV, BRANCH, LDST) which are used in the final stage of the pipeline - ie. the stage where the result could be forwarded. - I have made no attempt to model Late and Early pipeline stage. IE if a result can be available in Late_ISS I require it to be available in ISS and similarly if a result can be forwarded in Early_WR I say it is available at WR. - I have not modeled the Neon pipeline. These are simply fixed latency. The following is the performance improvement I see on A53 on a selection of benchmarks. Grinderbench Parallel: +16% kXML: +1% PNG: +2% Chess: +4% Crypto: +6% SpecJVM2008 compiler.compiler: +5% compress: +3% crypto.aes: +26% crypto.rsa: +2% crypto.signverify: +6% derby: -1% mpegaudio: +5% scimark.fft.large: +12% scimark.lu.large: +0% scimark.sor.large: -1% scimark.sparse.large: +28% scimark.fft.small: +2% scimark.lu.small: +8% scimark.sor.small: -1% scimark.sparse.small: +0% scimark.monte_carlo: +9% serial: +1% sunflow: +3% xml.transform: +5% xml.validation: +2% There is quite a large variation on these results and I would be suspect about some of the larger improvements (+16%, +26%, +28%) however it does seem to offer a consistent improvement. In the webrev I have turned the default for pipeline scheduling ('OptoScheduling'). It may be that we want to refine this and only turn it on for In-Order cores (not sure what you do about Big-Little). However for the moment I would like to make it the default so the overnight tests will run with it switched on. OK to push to JDK8? All the best, Ed.

2 3

hg: aarch64-port/jdk8/hotspot: Add support for pipeline scheduling
by ed＠camswl.com 31 Oct '14

31 Oct '14

Changeset: 788f964d727f Author: Edward Nevill <ed(a)camswl.com> Date: 2014-10-31 21:04 +0000 URL: http://hg.openjdk.java.net/aarch64-port/jdk8/hotspot/rev/788f964d727f Add support for pipeline scheduling ! src/cpu/aarch64/vm/aarch64.ad ! src/cpu/aarch64/vm/aarch64_ad.m4 ! src/cpu/aarch64/vm/vm_version_aarch64.cpp

1 0

/hg/icedtea7-forest-aarch64/hotspot: allow for 0x400 aligned off...
by Andrew Dinn 31 Oct '14

31 Oct '14

forwarding bounced check-in message Return-path: <adinn(a)icedtea.classpath.org> Received: from localhost ([127.0.0.1] helo=icedtea.classpath.org) by icedtea.classpath.org with esmtp (Exim 4.69) (envelope-from <adinn(a)icedtea.classpath.org>) id 1XkEsf-00007V-SI for aarch64-port-dev(a)openjdk.java.net; Fri, 31 Oct 2014 16:16:54 +0000 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Date: Fri, 31 Oct 2014 16:16:53 +0000 Subject: /hg/icedtea7-forest-aarch64/hotspot: allow for 0x400 aligned off... From: adinn(a)icedtea.classpath.org X-Hg-Notification: changeset 1759697c36a4 Message-Id: <hg.1759697c36a4.1414772213.-5017525213744097322(a)icedtea.classpath.org> To: aarch64-port-dev(a)openjdk.java.net changeset 1759697c36a4 in /hg/icedtea7-forest-aarch64/hotspot details: http://icedtea.classpath.org/hg/icedtea7-forest-aarch64/hotspot?cmd=changes… author: adinn date: Fri Oct 31 12:08:03 2014 -0400 allow for 0x400 aligned offsets for byte_map_base this reverts change set: 5664 SHA1 id: eff2294b2b17 which fixed the same problem as this fix but only at the cost of padding up to 1.5 extra Mbs between heap regions. That stopped jtreg running some of its tests with -Xms8Mb. That might, admittedly, be considered unimportant but we don't want to make it hard for anyone to run standard tests. diffstat: src/cpu/aarch64/vm/aarch64.ad | 7 ++- src/cpu/aarch64/vm/assembler_aarch64.cpp | 28 ++++++--- src/cpu/aarch64/vm/c1_Runtime1_aarch64.cpp | 7 ++- src/share/vm/gc_implementation/parallelScavenge/parallelScavengeHeap.hpp | 5 - 4 files changed, 31 insertions(+), 16 deletions(-) diffs (104 lines): diff -r 99a0ed4de8a1 -r 1759697c36a4 src/cpu/aarch64/vm/aarch64.ad --- a/src/cpu/aarch64/vm/aarch64.ad Fri Oct 31 14:50:26 2014 +0000 +++ b/src/cpu/aarch64/vm/aarch64.ad Fri Oct 31 12:08:03 2014 -0400 @@ -2589,7 +2589,12 @@ Register dst_reg = as_Register($dst$$reg); unsigned long off; __ adrp(dst_reg, ExternalAddress(page), off); - assert(off == 0, "assumed offset == 0"); + assert((off & 0x3ffL) == 0, "assumed offset aligned to 0x400"); + // n.b. intra-page offset will never change even if this gets + // relocated so it is safe to omit the lea when off == 0 + if (off != 0) { + __ lea(dst_reg, Address(dst_reg, off)); + } %} enc_class aarch64_enc_mov_n(iRegN dst, immN src) %{ diff -r 99a0ed4de8a1 -r 1759697c36a4 src/cpu/aarch64/vm/assembler_aarch64.cpp --- a/src/cpu/aarch64/vm/assembler_aarch64.cpp Fri Oct 31 14:50:26 2014 +0000 +++ b/src/cpu/aarch64/vm/assembler_aarch64.cpp Fri Oct 31 12:08:03 2014 -0400 @@ -1609,15 +1609,22 @@ // 2 - adrp Rx, target_page // add Ry, Rx, #offset_in_page // 3 - adrp Rx, target_page (page aligned reloc, offset == 0) - // In the first 2 cases we must check that Rx is the same in the adrp and the - // subsequent ldr/str or add instruction. Otherwise we could accidentally end - // up treating a type 3 relocation as a type 1 or 2 just because it happened - // to be followed by a random unrelated ldr/str or add instruction. // - // In the case of a type 3 relocation, we know that these are only generated - // for the safepoint polling page, or for the card type byte map base so we - // assert as much and of course that the offset is 0. + // In the first 2 cases we must check that Rx is the same in the + // adrp and the subsequent ldr/str or add instruction. Otherwise + // we could accidentally end up treating a type 3 relocation as + // a type 1 or 2 just because it happened to be followed by a + // random unrelated ldr/str or add instruction. // + // In the case of a type 3 relocation, we know that these are + // only generated for the safepoint polling page, the crc table + // base or the card type byte map base so we assert as much + // and of course that the offset is 0. + // + // In jdk7 the card type byte map base is aligned on a 1K + // boundary which may fail to be 4K aligned. In that case the + // card table load will fall into category 2. + unsigned insn2 = ((unsigned*)branch)[1]; if (Instruction_aarch64::extract(insn2, 29, 24) == 0b111001 && Instruction_aarch64::extract(insn, 4, 0) == @@ -1631,6 +1638,9 @@ Instruction_aarch64::extract(insn, 4, 0) == Instruction_aarch64::extract(insn2, 4, 0)) { // add (immediate) + assert (((jbyte *)target != + ((CardTableModRefBS*)(Universe::heap()->barrier_set()))->byte_map_base) || + (offset_lo & 0x3FFl) == 0, "offset must be 0x400 aligned for crc_table"); Instruction_aarch64::patch(branch + sizeof (unsigned), 21, 10, offset_lo); } else { @@ -1638,8 +1648,8 @@ ((CardTableModRefBS*)(Universe::heap()->barrier_set()))->byte_map_base || target == StubRoutines::crc_table_addr() || (address)target == os::get_polling_page(), - "adrp must be polling page or byte map base"); - assert(offset_lo == 0, "offset must be 0 for polling page or byte map base"); + "adrp must be polling page, crc_table or byte map base"); + assert(offset_lo == 0, "offset must be 0 for polling page, crc_table or byte map base"); } } int offset_lo = offset & 3; diff -r 99a0ed4de8a1 -r 1759697c36a4 src/cpu/aarch64/vm/c1_Runtime1_aarch64.cpp --- a/src/cpu/aarch64/vm/c1_Runtime1_aarch64.cpp Fri Oct 31 14:50:26 2014 +0000 +++ b/src/cpu/aarch64/vm/c1_Runtime1_aarch64.cpp Fri Oct 31 12:08:03 2014 -0400 @@ -1235,7 +1235,12 @@ __ lsr(card_addr, card_addr, CardTableModRefBS::card_shift); unsigned long offset; __ adrp(rscratch1, cardtable, offset); - assert(offset == 0, "assumed offset == 0"); + assert((offset & 0x3ffL) == 0, "assumed offset aligned to 0x400"); + // n.b. intra-page offset will never change even if this gets + // relocated so it is safe to omit the lea when offset == 0 + if (offset != 0) { + __ lea(rscratch1, Address(rscratch1, offset)); + } __ add(card_addr, card_addr, rscratch1); __ ldrb(rscratch1, Address(card_addr, offset)); __ cmpw(rscratch1, (int)G1SATBCardTableModRefBS::g1_young_card_val()); diff -r 99a0ed4de8a1 -r 1759697c36a4 src/share/vm/gc_implementation/parallelScavenge/parallelScavengeHeap.hpp --- a/src/share/vm/gc_implementation/parallelScavenge/parallelScavengeHeap.hpp Fri Oct 31 14:50:26 2014 +0000 +++ b/src/share/vm/gc_implementation/parallelScavenge/parallelScavengeHeap.hpp Fri Oct 31 12:08:03 2014 -0400 @@ -129,12 +129,7 @@ // The alignment used for eden and survivors within the young gen // and for boundary between young gen and old gen. -#ifdef TARGET_ARCH_aarch64 - // ensure byte_map_base can be loaded using adrp with no following ldr - size_t intra_heap_alignment() const { return 256 * K * HeapWordSize; } -#else size_t intra_heap_alignment() const { return 64 * K * HeapWordSize; } -#endif size_t capacity() const; size_t used() const;

1 0

/hg/icedtea7-forest-aarch64/hotspot: ensure rmethod is reloaded ...
by Andrew Dinn 31 Oct '14

31 Oct '14

[forwarding bounced checking message] Return-path: <adinn(a)icedtea.classpath.org> Received: from localhost ([127.0.0.1] helo=icedtea.classpath.org) by icedtea.classpath.org with esmtp (Exim 4.69) (envelope-from <adinn(a)icedtea.classpath.org>) id 1XkDXR-0008QP-HV for aarch64-port-dev(a)openjdk.java.net; Fri, 31 Oct 2014 14:50:53 +0000 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Date: Fri, 31 Oct 2014 14:50:53 +0000 Subject: /hg/icedtea7-forest-aarch64/hotspot: ensure rmethod is reloaded ... From: adinn(a)icedtea.classpath.org X-Hg-Notification: changeset 99a0ed4de8a1 Message-Id: <hg.99a0ed4de8a1.1414767053.-5017525213744097322(a)icedtea.classpath.org> To: aarch64-port-dev(a)openjdk.java.net changeset 99a0ed4de8a1 in /hg/icedtea7-forest-aarch64/hotspot details: http://icedtea.classpath.org/hg/icedtea7-forest-aarch64/hotspot?cmd=changes… author: adinn date: Fri Oct 31 14:50:26 2014 +0000 ensure rmethod is reloaded from stack when interpreter makes non leaf VM call n.b. we always push and pop rmethod around VM calls because it is volatile. this is redundant for calls from the interpreter and it would be godo to be able to avoid it. there is a FIXME comment in the code as a reminder. diffstat: src/cpu/aarch64/vm/assembler_aarch64.cpp | 3 +++ src/cpu/aarch64/vm/interp_masm_aarch64.cpp | 3 +++ 2 files changed, 6 insertions(+), 0 deletions(-) diffs (33 lines): diff -r eff2294b2b17 -r 99a0ed4de8a1 src/cpu/aarch64/vm/assembler_aarch64.cpp --- a/src/cpu/aarch64/vm/assembler_aarch64.cpp Thu Oct 30 10:46:37 2014 -0400 +++ b/src/cpu/aarch64/vm/assembler_aarch64.cpp Fri Oct 31 14:50:26 2014 +0000 @@ -2687,6 +2687,9 @@ Label *retaddr) { Label E, L; + // !!! FIXME AARCH64 we normally need to save rmethod as it is + // volatile. however we don't need to when calling from the + // interpreter. stp(rscratch1, rmethod, Address(pre(sp, -2 * wordSize))); // We add 1 to number_of_arguments because the thread in arg0 is diff -r eff2294b2b17 -r 99a0ed4de8a1 src/cpu/aarch64/vm/interp_masm_aarch64.cpp --- a/src/cpu/aarch64/vm/interp_masm_aarch64.cpp Thu Oct 30 10:46:37 2014 -0400 +++ b/src/cpu/aarch64/vm/interp_masm_aarch64.cpp Fri Oct 31 14:50:26 2014 +0000 @@ -1413,6 +1413,7 @@ // Note: No need to save/restore rbcp & rlocals pointer since these // are callee saved registers and no blocking/ GC can happen // in leaf calls. + // also no need to restore method register #ifdef ASSERT { Label L; @@ -1456,6 +1457,8 @@ entry_point, number_of_arguments, check_exceptions); // interpreter specific + // method oop may have moved so reload from interpreter stack frame + get_method(rmethod); restore_bcp(); restore_locals(); // reload the constant pool cache in case a PermGen GC moved it

1 0

/hg/icedtea7-forest-aarch64/hotspot: ensure byte_map_base can be...
by adinn＠icedtea.classpath.org 31 Oct '14

31 Oct '14

changeset eff2294b2b17 in /hg/icedtea7-forest-aarch64/hotspot details: http://icedtea.classpath.org/hg/icedtea7-forest-aarch64/hotspot?cmd=changes… author: adinn date: Thu Oct 30 10:46:37 2014 -0400 ensure byte_map_base can be loaded using adrp with no need for following ldr on AArch64 we want the card table base to be aligned to 4K so we can load using a single adrp with no need to load an offset. this means the heap needs to be aligned at 2Mb (i.e 256K heapwords). that's because byte_map_base is calculated as (byte_map - (heap_base >> 9)) diffstat: src/cpu/aarch64/vm/c1_Runtime1_aarch64.cpp | 1 + src/share/vm/gc_implementation/parallelScavenge/parallelScavengeHeap.hpp | 6 +++++- 2 files changed, 6 insertions(+), 1 deletions(-) diffs (28 lines): diff -r 5b7dcf16fe5d -r eff2294b2b17 src/cpu/aarch64/vm/c1_Runtime1_aarch64.cpp --- a/src/cpu/aarch64/vm/c1_Runtime1_aarch64.cpp Tue Oct 21 05:09:50 2014 -0400 +++ b/src/cpu/aarch64/vm/c1_Runtime1_aarch64.cpp Thu Oct 30 10:46:37 2014 -0400 @@ -1235,6 +1235,7 @@ __ lsr(card_addr, card_addr, CardTableModRefBS::card_shift); unsigned long offset; __ adrp(rscratch1, cardtable, offset); + assert(offset == 0, "assumed offset == 0"); __ add(card_addr, card_addr, rscratch1); __ ldrb(rscratch1, Address(card_addr, offset)); __ cmpw(rscratch1, (int)G1SATBCardTableModRefBS::g1_young_card_val()); diff -r 5b7dcf16fe5d -r eff2294b2b17 src/share/vm/gc_implementation/parallelScavenge/parallelScavengeHeap.hpp --- a/src/share/vm/gc_implementation/parallelScavenge/parallelScavengeHeap.hpp Tue Oct 21 05:09:50 2014 -0400 +++ b/src/share/vm/gc_implementation/parallelScavenge/parallelScavengeHeap.hpp Thu Oct 30 10:46:37 2014 -0400 @@ -129,8 +129,12 @@ // The alignment used for eden and survivors within the young gen // and for boundary between young gen and old gen. +#ifdef TARGET_ARCH_aarch64 + // ensure byte_map_base can be loaded using adrp with no following ldr + size_t intra_heap_alignment() const { return 256 * K * HeapWordSize; } +#else size_t intra_heap_alignment() const { return 64 * K * HeapWordSize; } - +#endif size_t capacity() const; size_t used() const;

3 3

jdk7 port: Patch to avoid RMI stub generation failure when using the newly generated JVM
by Andrew Dinn 30 Oct '14

30 Oct '14

I tweaked jdk/make/com/sun/jmx/Makefile during development so that it used the bootstrap JVM to generate the RMI stubs. this was needed in order to get the build to complete. WHowever, when Ed tried to do a full build from scratch without this tweak a weird heap alignment issue in jdk7 (but not present in jdk8) caused an assert when trying to load the card table byte map base. The heap alignment for the jdk7 JVM is 0x80000 and passing -Xms512M -Xmx512M appears always to result in the base being allocated at an odd multiple. Of course, that is exactly what the RMI stub generate command passes, something I managed to miss. The problem arises as follows. The card table base address, byte_map, is aligned to 0x1000 but the base address _byte_map_base is computed as _byte_map_base = (byte_map - (heap_start >> 9)) i.e. it is aligned to min(0x1000, 0x80000 >> 9) = 0x400 n.b. the original heap alignment is determined by this definition at gc_implementation/parallelScavenge/parallelScavengeHeap.hpp size_t intra_heap_alignment() const { return 64 * K * HeapWordSize; } That has disappeared from jdk8. The assert which Ed hit occurs in MacroAssembler::pd_patch_instruction in file assembler_aarch64.cpp. The offset for a patched adrp instruction is assumed always to be 0x0. This assert covers two cases where we generate an adrp without a following ldr in aarch64.ad:2589 in the encoding rule for aarch64_enc_mov_byte_map_base Register dst_reg = as_Register($dst$$reg); unsigned long off; __ adrp(dst_reg, ExternalAddress(page), off); assert(off == 0, "assumed offset == 0"); in c1_Runtime_aarch64.cpp:1235 in method Runtime1::generate_code_for(StubID id, StubAssembler* sasm) when id == case g1_post_barrier_slow_id __ lsr(card_addr, card_addr, CardTableModRefBS::card_shift); unsigned long offset; __ adrp(rscratch1, cardtable, offset); __ add(card_addr, card_addr, rscratch1); __ ldrb(rscratch1, Address(card_addr, offset)); (n.b. no actual assert there) Now in order to fix this we have two choices: change intra_heap_alignment() to ensure the correct alignment (we can make this arch-specific so it only affects AArch64) change the code which generates the adrp to check the offset and, if it is non-zero, to plant a following ldr. n.b. the offset value will never change so with the latter option the patching code still only needs to update the adrp, whether or not there is a following ldr. We would need to change the assert so that it allowed for a multiple of 0x400 offset but only when the address is for the card table. In that case we ought also to assert that the next instruction is indeed an ldr. Personally I think choice 1 is simpler and better -- it is essentially what JDK8 does. We lose a bit more heap but we avoid the possibility of having to plant the trailing ldr after the adrp. Anyone have an opinion? regards, Andrew Dinn -----------

3 4

CFV: New aarch64-port Committer: Roland Westrelin
by Andrew Haley 30 Oct '14

30 Oct '14

I hereby nominate Roland Westrelin to <project name> Committer. Roland is a very experienced engineer at Oracle, and I hope he will help us move this project upstream. Votes are due by 24 Oct. Only current aarch64-port Committers [1] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. For Lazy Consensus voting instructions, see [2]. Andrew. [1] http://openjdk.java.net/census [2] http://openjdk.java.net/projects/#committer-vote

3 4

CFV: New aarch64-port Committer: Vladimir Kozlov
by Andrew Haley 30 Oct '14

30 Oct '14

I hereby nominate Vladimir Kozlov to <project name> Committer. Vladimir is a very experienced engineer at Oracle, and I hope he will help us move this project upstream. Votes are due by 24 Oct. Only current aarch64-port Committers [1] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. For Lazy Consensus voting instructions, see [2]. Andrew. [1] http://openjdk.java.net/census [2] http://openjdk.java.net/projects/#committer-vote

3 4

CFV: New aarch64-port Committer: Dean Long
by Andrew Haley 30 Oct '14

30 Oct '14

I hereby nominate Dean Long to <project name> Committer. Dean is a very experienced engineer at Oracle, and I hope he will help us move this project upstream. Votes are due by 24 Oct. Only current aarch64-port Committers [1] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. For Lazy Consensus voting instructions, see [2]. Andrew. [1] http://openjdk.java.net/census [2] http://openjdk.java.net/projects/#committer-vote

3 4