November 2013 - aarch64-port-dev

hg: aarch64-port/jdk8/hotspot: 4 new changesets
by aph＠redhat.com 28 Nov '13

28 Nov '13

Changeset: 8cfedf8584d3 Author: aph Date: 2013-11-26 17:11 +0000 URL: http://hg.openjdk.java.net/aarch64-port/jdk8/hotspot/rev/8cfedf8584d3 Fix stack overflow check. ! src/cpu/aarch64/vm/templateInterpreter_aarch64.cpp Changeset: 0b8324236823 Author: aph Date: 2013-11-26 13:18 -0500 URL: http://hg.openjdk.java.net/aarch64-port/jdk8/hotspot/rev/0b8324236823 Merge Changeset: 513a27ec96c9 Author: aph Date: 2013-11-26 14:11 -0500 URL: http://hg.openjdk.java.net/aarch64-port/jdk8/hotspot/rev/513a27ec96c9 Trivial comment change only ! src/cpu/aarch64/vm/aarch64.ad ! src/cpu/aarch64/vm/c1_MacroAssembler_aarch64.cpp Changeset: 791011ac5498 Author: aph Date: 2013-11-28 07:13 -0500 URL: http://hg.openjdk.java.net/aarch64-port/jdk8/hotspot/rev/791011ac5498 Correct SafeFetch stubs. ! src/cpu/aarch64/vm/stubGenerator_aarch64.cpp

1 0

Correct SafeFetch stubs
by Andrew Haley 28 Nov '13

28 Nov '13

The SafeFetch stubs aren't correct for the non-builtin sim case. Andrew. # HG changeset patch # User aph # Date 1385640816 18000 # Thu Nov 28 07:13:36 2013 -0500 # Node ID 791011ac54983caec771944e5ee7750f029b60d8 # Parent 513a27ec96c9fe6ca9c61c1ccdf16606bde7aa4d Correct SafeFetch stubs. diff -r 513a27ec96c9 -r 791011ac5498 src/cpu/aarch64/vm/stubGenerator_aarch64.cpp --- a/src/cpu/aarch64/vm/stubGenerator_aarch64.cpp Tue Nov 26 14:11:58 2013 -0500 +++ b/src/cpu/aarch64/vm/stubGenerator_aarch64.cpp Thu Nov 28 07:13:36 2013 -0500 @@ -1884,11 +1884,11 @@ switch (size) { case 4: // int32_t - __ ldrw(c_rarg0, Address(c_rarg0, 0)); + __ ldrw(c_rarg1, Address(c_rarg0, 0)); break; case 8: // int64_t - __ ldr(c_rarg0, Address(c_rarg0, 0)); + __ ldr(c_rarg1, Address(c_rarg0, 0)); break; default: ShouldNotReachHere(); @@ -1896,6 +1896,7 @@ // return errValue or *adr *continuation_pc = __ pc(); + __ mov(r0, c_rarg1); __ ret(lr); } #endif

1 0

SEGVs in C1 compiler with langtools test
by Edward Nevill 28 Nov '13

28 Nov '13

Hi, I am seeing SEGVs in the langtools section of the JTReg tests with the client compiler. These are provoked when I run the tests with a high level of concurrency (ie -conc:50) and are also provoked more frequently when I disable thread local allocation. The SEGVs only occur with the C1 compiler, not with C2 and not with -Xint. The following is the command I used to provoke it /work/images/j2sdk-client-release/bin/java -client -XX:-UseTLAB -XX:-UseCompilerSafepoints -jar lib/jtreg.jar -timeout:10 -othervm -conc:50 -vmoption:-Xint -v1 -a -ignore:quiet -w:work_langtools/JTwork -r:report_langtools/JTreport -jdk:/work/images/j2sdk-client-release langtools/test Note that I am running the actual tests -Xint (-vmoption:-Xint) so it is the test harness that is generating the SEGV. The typical symptom is that within 30sec of starting the test I get Directory "report_langtools/JTreport" not found: creating Directory "work_langtools/JTwork" not found: creating Directory "work_langtools/JTwork/scratch" not found: creating # # A fatal error has been detected by the Java Runtime Environment: # # SIGSEGV (0xb) at pc=0x00007f7fd1b34b69, pid=26426, tid=140186555778816 # # JRE version: OpenJDK Runtime Environment (8.0) (build 1.8.0-internal-ed_2013_11_27_09_54-b00) # Java VM: OpenJDK 64-Bit Client VM (25.0-b52 mixed mode linux-aarch64 ) # Problematic frame: # V [libjvm.so+0x21ab69] DefNewGeneration::copy_to_survivor_space(oopDesc*)+0xe9 If it gets to the stage where it completes the first test the test suit then usually runs to completion. The problem is more common with the release version, although I have seen it on the slowdebug version as well. It also happens on both the builtin sim and on the RTSM model. Note that in order to provoke it the work and report directories (ie work_langtools and report_langtools) must be removed prior to running the test. If there are preexisting work and report directories lying around from a previous test then the problem does not seem to occur. The actual routine that the SEGV occurs in varies, I have seen SEGVs in FastScanClosure::do_oop(oopDesc**) DefNewGeneration::copy_to_survivor_space(oopDesc*) markOopDesc::displaced_mark_helper(...) MarkSweep::follow_stack() but copy_to_survivor_space seems the most common. I have tried modifying eden_allocate to allocate an extra 8 bytes and place a guard word (0xdeadbeaf) 8 bytes before the object. This seems to make the problem go away. I then tried modifying the builting sim to trap any overwrites of the guard word. These were not trapped, but it seemed that the guard word was still overwritten. This seems to indicate that it is been overwritten in native C code. I have timed out on this having been looking at it for the best part of a week and would appreciate some fresh input. I have placed a tar file at http://people.linaro.org/~edward.nevill/jtreg_segv.tgz Within this there is a 'do_langtools' shell script which should provoke the above. If the fault does not happen within about 30 sec then it is not going to occur at all. Sorry this is not much of a reproducer, but some bugs just don't lend themselves to being reproduced. All the best, Ed.

2 1

hg: aarch64-port/jdk8/jdk: Modify GetAltJvmType to use -server if no client compiler
by ed＠camswl.com 26 Nov '13

26 Nov '13

Changeset: a4a0229fd36a Author: Edward Nevill edward.nevill(a)linaro.org Date: 2013-11-26 15:52 +0000 URL: http://hg.openjdk.java.net/aarch64-port/jdk8/jdk/rev/a4a0229fd36a Modify GetAltJvmType to use -server if no client compiler ! src/share/bin/java.c

1 0

hg: aarch64-port/jdk8/hotspot: 2 new changesets
by aph＠redhat.com 26 Nov '13

26 Nov '13

Changeset: e9f4f09746dc Author: aph Date: 2013-11-26 17:09 +0000 URL: http://hg.openjdk.java.net/aarch64-port/jdk8/hotspot/rev/e9f4f09746dc Rewrite object initialization. ! src/cpu/aarch64/vm/c1_MacroAssembler_aarch64.cpp Changeset: f33b0ad876b7 Author: aph Date: 2013-11-26 17:11 +0000 URL: http://hg.openjdk.java.net/aarch64-port/jdk8/hotspot/rev/f33b0ad876b7 Fix stack overflow check. ! src/cpu/aarch64/vm/templateInterpreter_aarch64.cpp

1 0

Rewrite object initialization
by Andrew Haley 26 Nov '13

26 Nov '13

This replaces the object initialization code in C1 with the much slicker code used by C2. Andrew. # HG changeset patch # User aph # Date 1385485750 0 # Node ID e9f4f09746dcd90b945525a3ed0abb9115dcca02 # Parent 3390e44a940f942ebdd245831951b09148248c51 Rewrite object initialization. diff -r 3390e44a940f -r e9f4f09746dc src/cpu/aarch64/vm/c1_MacroAssembler_aarch64.cpp --- a/src/cpu/aarch64/vm/c1_MacroAssembler_aarch64.cpp Tue Nov 26 11:16:12 2013 +0000 +++ b/src/cpu/aarch64/vm/c1_MacroAssembler_aarch64.cpp Tue Nov 26 17:09:10 2013 +0000 @@ -221,57 +221,46 @@ block_comment("zero memory"); #endif - Label finished; + Label loop; + Label entry; + +// Algorithm: +// +// scratch1 = cnt & 7; +// cnt -= scratch1; +// p += scratch1; +// switch (scratch1) { +// do { +// cnt -= 8; +// case 7: +// p[-7] = 0; +// case 6: +// p[-6] = 0; +// // ... +// case 1: +// p[-1] = 0; +// case 0: +// p += 8; +// } while (cnt); +// } + + const int unroll = 8; // Number of str(zr) instructions we'll unroll lsr(len, len, LogBytesPerWord); - mov(rscratch1, addr); - - // The algorithm first zeroes words until the number of words - // remaining is a multiple of 8, then enters a loop that writes 8 - // words at a time. The idea is to get small arrays done quickly - // because these are the common case. Also, we don't want to bloat - // the VM with a lot of code: it's a compromise between speed and - // size. We should really emit the large block out of line. - - Label is_even; - tst(len, 1); - br(Assembler::EQ, is_even); - str(zr, Address(post(rscratch1, wordSize))); - sub(len, len, 1); - bind(is_even); - - // len is now a multiple of 2 - - { - // Initialize the first few words. This loop iterates at most 3 - // times. - - Label bottom, loop; - mov(t1, zr); - b(bottom); - - bind(loop); - stp(zr, t1, Address(post(rscratch1, 2 * wordSize))); - sub(len, len, 2); - bind(bottom); - tst(len, 7); - br(NE, loop); - } - - // len is now a multiple of 8 - - cbz(len, finished); - - Label top; - bind(top); - stp(zr, t1, Address(post(rscratch1, 2 * wordSize))); - stp(zr, t1, Address(post(rscratch1, 2 * wordSize))); - stp(zr, t1, Address(post(rscratch1, 2 * wordSize))); - stp(zr, t1, Address(post(rscratch1, 2 * wordSize))); - sub(len, len, 8); - cbnz(len, top); - - bind(finished); + andr(rscratch1, len, unroll - 1); // tmp1 = cnt % unroll + sub(len, len, rscratch1); // cnt -= unroll + // t1 always points to the end of the region we're about to zero + add(t1, addr, rscratch1, Assembler::LSL, LogBytesPerWord); + adr(rscratch2, entry); + sub(rscratch2, rscratch2, rscratch1, Assembler::LSL, 2); + br(rscratch2); + bind(loop); + sub(len, len, unroll); + for (int i = -unroll; i < 0; i++) + str(zr, Address(t1, i * wordSize)); + bind(entry); + add(t1, t1, unroll * wordSize); + cbnz(len, loop); } // preserves obj, destroys len_in_bytes @@ -323,7 +312,7 @@ // clear rest of allocated space const Register index = t2; - const int threshold = 8 * BytesPerWord; // approximate break even point for code size (see comments below) + const int threshold = 16 * BytesPerWord; // approximate break even point for code size (see comments below) if (var_size_in_bytes != noreg) { mov(index, var_size_in_bytes); initialize_body(obj, index, hdr_size_in_bytes, t1); @@ -334,44 +323,34 @@ str(zr, Address(obj, i)); i += BytesPerWord; } - if (i < con_size_in_bytes) { - mov(t1, zr); - } for (; i < con_size_in_bytes; i += 2 * BytesPerWord) - stp(zr, t1, Address(obj, i)); + stp(zr, zr, Address(obj, i)); } else if (con_size_in_bytes > hdr_size_in_bytes) { block_comment("zero memory"); // use loop to null out the fields - // initialize last object field first if odd number of fields + int words = (con_size_in_bytes - hdr_size_in_bytes) / BytesPerWord; mov(index, words / 8); - lea(rscratch1, Address(obj, (con_size_in_bytes & - ((2 * BytesPerWord)-1)))); - // initialize last object field if constant size is odd - if ((words % 2) != 0) { - str(zr, Address(obj, con_size_in_bytes - (1*BytesPerWord))); - words--; + + const int unroll = 8; // Number of str(zr) instructions we'll unroll + int remainder = words % unroll; + lea(rscratch1, Address(obj, hdr_size_in_bytes + remainder * BytesPerWord)); + + Label entry_point, loop; + b(entry_point); + + bind(loop); + sub(index, index, 1); + for (int i = -unroll; i < 0; i++) { + if (-i == remainder) + bind(entry_point); + str(zr, Address(rscratch1, i * wordSize)); } - // initialize remaining object fields - mov(t1, zr); - { - Label top, entry_point; + if (remainder == 0) + bind(entry_point); + add(rscratch1, rscratch1, unroll * wordSize); + cbnz(index, loop); - int remainder = words % 8; - if (remainder != 0) - b(entry_point); - - bind(top); - sub(index, index, 1); - stp(zr, t1, pre(rscratch1, -2 * BytesPerWord)); - if (remainder == 6) bind(entry_point); - stp(zr, t1, pre(rscratch1, -2 * BytesPerWord)); - if (remainder == 4) bind(entry_point); - stp(zr, t1, pre(rscratch1, -2 * BytesPerWord)); - if (remainder == 2) bind(entry_point); - stp(zr, t1, pre(rscratch1, -2 * BytesPerWord)); - - cbnz(index, top); - } } if (CURRENT_ENV->dtrace_alloc_probes()) {

1 0

Correct setting of carry flag after subs instruction
by Andrew Haley 26 Nov '13

26 Nov '13

The carry flag is the wrong way up after a SUBS (extended register). Fixed thusly. Note that you must patch simulator and HotSpot. Andrew. # HG changeset patch # User aph # Date 1385485688 0 # Node ID 0bb5cbbe1dbeb042d987be41c8834aa54fe447b7 # Parent 93e88ac7ba615034ef57e058a7e768ff2dcc6135 Correct setting of carry flag after subs instruction diff -r 93e88ac7ba61 -r 0bb5cbbe1dbe simulator.cpp --- a/simulator.cpp Thu Nov 21 18:22:10 2013 +0000 +++ b/simulator.cpp Tue Nov 26 17:08:08 2013 +0000 @@ -6288,8 +6288,7 @@ u_int32_t value2 = extreg32(16, extension) << shift; u_int64_t x86flags; - asm ("SUB %2,%0\n\tPUSHF\t\nPOP %1" : "+r" (value), "=r" (x86flags) : "r" (value2)); - xreg(0, NO_SP) = value; + xreg(0, NO_SP) = subs(value, value2, x86flags); cpuState.setCPSRRegisterFromX86(x86flags); } @@ -6301,8 +6300,7 @@ u_int64_t value2 = extreg(16, extension) << shift; u_int64_t x86flags; - asm ("SUB %2,%0\n\tPUSHF\t\nPOP %1" : "+r" (value), "=r" (x86flags) : "r" (value2)); - xreg(0, NO_SP) = value; + xreg(0, NO_SP) = subs(value, value2, x86flags); cpuState.setCPSRRegisterFromX86(x86flags); } # HG changeset patch # User aph # Date 1385485862 0 # Node ID f33b0ad876b7bfd40d05a698af42df7035db33d3 # Parent e9f4f09746dcd90b945525a3ed0abb9115dcca02 Fix stack overflow check. diff -r e9f4f09746dc -r f33b0ad876b7 src/cpu/aarch64/vm/templateInterpreter_aarch64.cpp --- a/src/cpu/aarch64/vm/templateInterpreter_aarch64.cpp Tue Nov 26 17:09:10 2013 +0000 +++ b/src/cpu/aarch64/vm/templateInterpreter_aarch64.cpp Tue Nov 26 17:11:02 2013 +0000 @@ -520,7 +520,7 @@ // check against the current stack bottom __ cmp(sp, r0); - __ br(Assembler::LO, after_frame_check); + __ br(Assembler::HI, after_frame_check); // Note: the restored frame is not necessarily interpreted. // Use the shared runtime version of the StackOverflowError.

1 0

Fix assertion failure in x86 build
by Edward Nevill 26 Nov '13

26 Nov '13

Hi, The following patch fixes an assertion failure "no relocInfo found for pc" on a pure x86 build (ie x86 target). This doesn't benefit aarch64 in any way, but it is useful to be able to continue to build x86 from the same tree. Regards, Ed. --- CUT HERE --- # HG changeset patch # User Edward Nevill edward.nevill(a)linaro.org # Date 1385383118 0 # Mon Nov 25 12:38:38 2013 +0000 # Node ID 36a829ad1cdd5fb34eae3f369e49f5b21d5b8ae8 # Parent 0460e912b30024c5fbecc84c1ac438be3098db47 Fix assertion failure "no relocInfo found for pc" in x86 build diff -r 0460e912b300 -r 36a829ad1cdd src/share/vm/c1/c1_Runtime1.cpp --- a/src/share/vm/c1/c1_Runtime1.cpp Mon Nov 25 12:06:41 2013 +0000 +++ b/src/share/vm/c1/c1_Runtime1.cpp Mon Nov 25 12:38:38 2013 +0000 @@ -1141,7 +1141,7 @@ if (load_klass_or_mirror_patch_id || stub_id == Runtime1::load_appendix_patching_id - || stub_id == Runtime1::access_field_patching_id) { + AARCH64_ONLY(|| stub_id == Runtime1::access_field_patching_id)) { relocInfo::relocType rtype; switch(stub_id) { case Runtime1::load_klass_patching_id: --- CUT HERE ---

1 0

Remove bogus call to find_free_reg in c1_LinearCsan
by Edward Nevill 26 Nov '13

26 Nov '13

Hi, This patch removes a bogus duplicate call to find_free_reg in c1_LinearScan. Regards, Ed. --- CUT HERE --- # HG changeset patch # User Edward Nevill edward.nevill(a)linaro.org # Date 1385381201 0 # Mon Nov 25 12:06:41 2013 +0000 # Node ID 0460e912b30024c5fbecc84c1ac438be3098db47 # Parent 1f7a7cdf58818a3344d55dfcb1dd6417c889ea9e Remove bogus call to find_free_reg diff -r 1f7a7cdf5881 -r 0460e912b300 src/share/vm/c1/c1_LinearScan.cpp --- a/src/share/vm/c1/c1_LinearScan.cpp Fri Nov 22 17:41:16 2013 +0000 +++ b/src/share/vm/c1/c1_LinearScan.cpp Mon Nov 25 12:06:41 2013 +0000 @@ -5414,8 +5414,6 @@ split_pos = MIN2(_use_pos[reg], _use_pos[regHi]); } else { - // ECN: FIXME --- this is very odd - reg = find_free_reg(reg_needed_until, interval_to, hint_reg, any_reg, &need_split); reg = find_free_reg(reg_needed_until, interval_to, hint_reg, any_reg, &need_split); if (reg == any_reg) { return false; --- CUT HERE ---

1 0

Server build for simulator
by Andy Johnson 26 Nov '13

26 Nov '13

I am still getting this message: Error: missing `client' JVM at `.../build/linux-aarch64-normal-server-slowdebug/images/j2sdk-image/jre/lib/aarch64/client/libjvm.so'. from .../build/linux-aarch64-normal-server-slowdebug/images/j2sdk-image/ whenever I try to run any of the following commands: javac, javadoc, javah, javap, jdeps. As a workaround, I just created a symbolic link from the "server" directory to "client", but this should really be fixed in the build. Also, there is no build of j2sdk-image/jre/lib/aarch64/hsdis-aarch64.so with a server build, which is necessary to support the -XX:+PrintAssembly option. I am trying to chase down several JTREG failures that only happen with the server compiler: compiler/6340864/TestByteVect.java compiler/6340864/TestShortVect.java compiler/7048332/Test7048332.java compiler/8001183/TestCharVect.java The Test*Vect tests all seem to have a common thread, and I suspect one patch will solve all three issues.

2 1