| Message ID | 87txeq76fa.fsf@spicy.frobware.com |
|---|---|
| State | Accepted |
| Headers | show |
On 12/03/2013 07:14 AM, Andrew McDermott wrote: > As inlining all the changesets would make this email quite large I have > copied them to: OK, thanks. This looks reasonable. Do you have commit access? Andrew.
On 12/03/2013 07:14 AM, Andrew McDermott wrote: > Some of the errors are tests timing out. It appears that some tests are > leaving spinning JVM processes which exacerbates the problem. I haven't > looked into why this is. Are these regressions? Andrew.
On Tue, 2013-12-03 at 07:14 +0000, Andrew McDermott wrote: > Hi, > > The attached or referenced changesets merge the aarch64-port to > jdk8-b111. I have built both client and server and tested as follows: Hi Andrew, Thanks for doing this. The changes look fine. It would be useful to know how your test results compare with the test results before the merge. Are you seeing significantly more failures? Are you seeing the same problems with tests 'spinning'? All the best, Ed.
On 12/03/2013 10:28 AM, Andrew Haley wrote: > On 12/03/2013 07:14 AM, Andrew McDermott wrote: >> Some of the errors are tests timing out. It appears that some tests are >> leaving spinning JVM processes which exacerbates the problem. I haven't >> looked into why this is. > > Are these regressions? In case it wasn't clear: please hold off committing anything until you've answered this question. Andrew.
Hi, > On Tue, 2013-12-03 at 07:14 +0000, Andrew McDermott wrote: >> Hi, >> >> The attached or referenced changesets merge the aarch64-port to >> jdk8-b111. I have built both client and server and tested as follows: > > Hi Andrew, > > Thanks for doing this. The changes look fine. > > It would be useful to know how your test results compare with the test > results before the merge. Are you seeing significantly more failures? > Are you seeing the same problems with tests 'spinning'? I'm just running the same tests but with b110 and will let you know.
Hi, > On 12/03/2013 07:14 AM, Andrew McDermott wrote: >> As inlining all the changesets would make this email quite large I have >> copied them to: > > OK, thanks. This looks reasonable. Do you have commit access? No commit access.
Andrew Haley <aph@redhat.com> writes: > On 12/03/2013 10:28 AM, Andrew Haley wrote: >> On 12/03/2013 07:14 AM, Andrew McDermott wrote: >>> Some of the errors are tests timing out. It appears that some tests are >>> leaving spinning JVM processes which exacerbates the problem. I haven't >>> looked into why this is. >> >> Are these regressions? > > In case it wasn't clear: please hold off committing anything until > you've answered this question. Ack. Just running the same tests with b110 (client and server) to see if this is a regression.
Edward Nevill <edward.nevill@linaro.org> writes: > On Tue, 2013-12-03 at 07:14 +0000, Andrew McDermott wrote: >> Hi, >> >> The attached or referenced changesets merge the aarch64-port to >> jdk8-b111. I have built both client and server and tested as follows: > > Hi Andrew, > > Thanks for doing this. The changes look fine. > > It would be useful to know how your test results compare with the test > results before the merge. Are you seeing significantly more failures? Reporting results as I get them... This is for cross-compilation. b111: run 1: hotspot/client/fastdebug Test results: passed: 320; failed: 11; error: 8 run 2: hotspot/client/fastdebug Test results: passed: 321; failed: 10; error: 8 b110 run 1: hotspot/client/release Test results: passed: 325; failed: 14 run 2: hotspot/client/release Test results: passed: 325; failed: 14 > Are you seeing the same problems with tests 'spinning'? Running with b111 (-conc:3 -agentvm) I'm left with 3 processes spinning and introspecting those a little... $ jstack 4583 4583: Unable to open socket file: target process not responding or HotSpot VM not loaded $ strace -f -p 4583 Process 4583 attached with 7 threads [pid 4582] futex(0x7f974a6898, FUTEX_WAIT_PRIVATE, 0, NULL <unfinished ...> [pid 4581] futex(0x7f900f1764, FUTEX_WAIT_PRIVATE, 1, NULL <unfinished ...> [pid 4580] futex(0x7f900ef564, FUTEX_WAIT_PRIVATE, 1, NULL <unfinished ...> [pid 4579] restart_syscall(<... resuming interrupted call ...> <unfinished ...> [pid 4578] futex(0x7f9000d064, FUTEX_WAIT_PRIVATE, 13, NULL <unfinished ...> [pid 4577] futex(0x7f967842c0, FUTEX_WAIT, 4578, NULL <unfinished ...> [pid 4579] <... restart_syscall resumed> ) = -1 ETIMEDOUT (Connection timed out) [pid 4579] futex(0x7f900e5230, FUTEX_WAKE_PRIVATE, 1) = 0 [pid 4579] futex(0x7f900e5264, FUTEX_WAIT_BITSET_PRIVATE, 1, {6666, 20080160}, ffffffff) = -1 ETIMEDOUT (Connection timed out) [pid 4579] futex(0x7f900e5230, FUTEX_WAKE_PRIVATE, 1) = 0 ... the 'Connection timed out' repeats ... I do _not_ see this behaviour with b110. And I repeated the exercise twice to avoid a sample size of 1... HTH, Andy.
I experimented with a (b111) client/release build and ran the same tests. This time there were no errors reported, nor were there any processes left spinning. client/release/hotspot Test results: passed: 328; failed: 11 I'll rebase my changes as the tip has moved on -- there were some fixes for SEGVs during the week -- and then report back. On 3 December 2013 12:02, Andrew McDermott <andrew.mcdermott@linaro.org>wrote: > > Edward Nevill <edward.nevill@linaro.org> writes: > > > On Tue, 2013-12-03 at 07:14 +0000, Andrew McDermott wrote: > >> Hi, > >> > >> The attached or referenced changesets merge the aarch64-port to > >> jdk8-b111. I have built both client and server and tested as follows: > > > > Hi Andrew, > > > > Thanks for doing this. The changes look fine. > > > > It would be useful to know how your test results compare with the test > > results before the merge. Are you seeing significantly more failures? > > Reporting results as I get them... > > This is for cross-compilation. > > b111: > > run 1: hotspot/client/fastdebug Test results: passed: 320; failed: 11; > error: 8 > run 2: hotspot/client/fastdebug Test results: passed: 321; failed: 10; > error: 8 > > b110 > > run 1: hotspot/client/release Test results: passed: 325; failed: 14 > run 2: hotspot/client/release Test results: passed: 325; failed: 14 > > > Are you seeing the same problems with tests 'spinning'? > > Running with b111 (-conc:3 -agentvm) I'm left with 3 processes spinning > and introspecting those a little... > > $ jstack 4583 > > 4583: Unable to open socket file: target process not responding or > HotSpot VM not loaded > > $ strace -f -p 4583 > > Process 4583 attached with 7 threads > [pid 4582] futex(0x7f974a6898, FUTEX_WAIT_PRIVATE, 0, NULL > <unfinished ...> > [pid 4581] futex(0x7f900f1764, FUTEX_WAIT_PRIVATE, 1, NULL > <unfinished ...> > [pid 4580] futex(0x7f900ef564, FUTEX_WAIT_PRIVATE, 1, NULL > <unfinished ...> > [pid 4579] restart_syscall(<... resuming interrupted call ...> > <unfinished ...> > [pid 4578] futex(0x7f9000d064, FUTEX_WAIT_PRIVATE, 13, NULL > <unfinished ...> > [pid 4577] futex(0x7f967842c0, FUTEX_WAIT, 4578, NULL <unfinished ...> > [pid 4579] <... restart_syscall resumed> ) = -1 ETIMEDOUT (Connection > timed out) > [pid 4579] futex(0x7f900e5230, FUTEX_WAKE_PRIVATE, 1) = 0 > [pid 4579] futex(0x7f900e5264, FUTEX_WAIT_BITSET_PRIVATE, 1, {6666, > 20080160}, ffffffff) = -1 ETIMEDOUT (Connection timed out) > [pid 4579] futex(0x7f900e5230, FUTEX_WAKE_PRIVATE, 1) = 0 > ... the 'Connection timed out' repeats ... > > I do _not_ see this behaviour with b110. > > And I repeated the exercise twice to avoid a sample size of 1... > > HTH, > Andy. >
Andrew Haley <aph@redhat.com> writes: > On 12/03/2013 07:14 AM, Andrew McDermott wrote: >> Some of the errors are tests timing out. It appears that some tests are >> leaving spinning JVM processes which exacerbates the problem. I haven't >> looked into why this is. > > Are these regressions? I don't believe so. The spinning processes are coming from the `forever' loop in os::abort() which is not reachable for `release' builds. .../hotspot/src/os/linux/vm/os_linux.cpp: void os::abort(bool dump_core) { os::shutdown(); if (dump_core) { #ifndef PRODUCT fdStream out(defaultStream::output_fd()); out.print_raw("Current thread is "); char buf[16]; jio_snprintf(buf, sizeof(buf), UINTX_FORMAT, os::current_thread_id()); out.print_raw_cr(buf); out.print_raw_cr("Dumping core ..."); out.print_raw_cr("LOOPING..."); for (;;); #endif ::abort(); // dump core } ::exit(1); } I rebased the b111 patches I proposed onto yesterday's aarch64-port/hotspot tip and re-ran the hotspot tests using fastdebug and release builds. Results are as follows: cross compilation ================= NOTE: these invocations still had the `forever' code enabled, hence the errors. b111/client/fastdebug/hotspot passed: 320; failed: 11; error: 8 tip/client/fastdebug/hotspot passed: 322; failed: 9; error: 8 b111/client/release/hotspot passed: 328; failed: 11 tip/client/release/hotspot passed: 329; failed: 10 builtin simulator ================= b111/client/release/hotspot passed: 336; failed: 10; error: 2 tip/client/release/hotspot passed: 336; failed: 10; error: 2 b111/client/slowdebug/hotspot/sanity passed: 3 A refreshed tarball of all the patches may be downloaded from: http://people.linaro.org/~andrew.mcdermott/b111.tar.gz Here's a list of all the patches broken out per tree. Note only the hotspot-b111.patch and aarch64-hotspot-jdk8-b110-to-jdk8-b111.patch have actually changed. http://people.linaro.org/~andrew.mcdermott/b111/corba-b111.patch http://people.linaro.org/~andrew.mcdermott/b111/hotspot-b111.patch http://people.linaro.org/~andrew.mcdermott/b111/jaxp-b111.patch http://people.linaro.org/~andrew.mcdermott/b111/jaxws-b111.patch http://people.linaro.org/~andrew.mcdermott/b111/jdk-b111.patch http://people.linaro.org/~andrew.mcdermott/b111/jdk8-b111.patch http://people.linaro.org/~andrew.mcdermott/b111/langtools-b111.patch http://people.linaro.org/~andrew.mcdermott/b111/nashorn-b111.patch http://people.linaro.org/~andrew.mcdermott/b111/aarch64-hotspot-jdk8-b110-to-jdk8-b111.patch
Andrew McDermott <andrew.mcdermott@linaro.org> writes: > Andrew Haley <aph@redhat.com> writes: > >> On 12/03/2013 07:14 AM, Andrew McDermott wrote: >>> Some of the errors are tests timing out. It appears that some tests are >>> leaving spinning JVM processes which exacerbates the problem. I haven't >>> looked into why this is. >> >> Are these regressions? > > I don't believe so. The spinning processes are coming from the > `forever' loop in os::abort() which is not reachable for `release' > builds. > > .../hotspot/src/os/linux/vm/os_linux.cpp: > > void os::abort(bool dump_core) { > os::shutdown(); > if (dump_core) { > #ifndef PRODUCT > fdStream out(defaultStream::output_fd()); > out.print_raw("Current thread is "); > char buf[16]; > jio_snprintf(buf, sizeof(buf), UINTX_FORMAT, os::current_thread_id()); > out.print_raw_cr(buf); > out.print_raw_cr("Dumping core ..."); > out.print_raw_cr("LOOPING..."); > for (;;); > #endif > ::abort(); // dump core > } > > ::exit(1); > } > > I rebased the b111 patches I proposed onto yesterday's > aarch64-port/hotspot tip and re-ran the hotspot tests using fastdebug > and release builds. Results are as follows: > > cross compilation > ================= > > NOTE: these invocations still had the `forever' code enabled, hence the > errors. > > b111/client/fastdebug/hotspot > passed: 320; failed: 11; error: 8 > > tip/client/fastdebug/hotspot > passed: 322; failed: 9; error: 8 > > b111/client/release/hotspot > passed: 328; failed: 11 > > tip/client/release/hotspot > passed: 329; failed: 10 > > builtin simulator > ================= > > b111/client/release/hotspot > passed: 336; failed: 10; error: 2 > > tip/client/release/hotspot > passed: 336; failed: 10; error: 2 Correction for tip ^^^ passed: 334; failed: 33; error: 12 [ I cut and paste the "b111/client/release/hotspot", changed it to be "tip", but forgot to paste the results from that run before hitting send. ] > > b111/client/slowdebug/hotspot/sanity > passed: 3 > > A refreshed tarball of all the patches may be downloaded from: > > http://people.linaro.org/~andrew.mcdermott/b111.tar.gz > > Here's a list of all the patches broken out per tree. Note only the > hotspot-b111.patch and aarch64-hotspot-jdk8-b110-to-jdk8-b111.patch have > actually changed. > > http://people.linaro.org/~andrew.mcdermott/b111/corba-b111.patch > http://people.linaro.org/~andrew.mcdermott/b111/hotspot-b111.patch > http://people.linaro.org/~andrew.mcdermott/b111/jaxp-b111.patch > http://people.linaro.org/~andrew.mcdermott/b111/jaxws-b111.patch > http://people.linaro.org/~andrew.mcdermott/b111/jdk-b111.patch > http://people.linaro.org/~andrew.mcdermott/b111/jdk8-b111.patch > http://people.linaro.org/~andrew.mcdermott/b111/langtools-b111.patch > http://people.linaro.org/~andrew.mcdermott/b111/nashorn-b111.patch > http://people.linaro.org/~andrew.mcdermott/b111/aarch64-hotspot-jdk8-b110-to-jdk8-b111.patch
On 12/04/2013 07:12 PM, Andrew McDermott wrote: > > Andrew Haley <aph@redhat.com> writes: > >> On 12/03/2013 07:14 AM, Andrew McDermott wrote: >>> Some of the errors are tests timing out. It appears that some tests are >>> leaving spinning JVM processes which exacerbates the problem. I haven't >>> looked into why this is. >> >> Are these regressions? > > I don't believe so. The spinning processes are coming from the > `forever' loop in os::abort() which is not reachable for `release' > builds. Right, so this is a catastrophic failure. > NOTE: these invocations still had the `forever' code enabled, hence the > errors. No, the errors are not due to the `forever' code. They are due to the abort that triggered it. The idea is that you are supposed to attach a debugger and find out why. If you give me precise reproducer instructions I can have a look. Andrew.
Andrew Haley <aph@redhat.com> writes: > On 12/04/2013 07:12 PM, Andrew McDermott wrote: >> >> Andrew Haley <aph@redhat.com> writes: >> >>> On 12/03/2013 07:14 AM, Andrew McDermott wrote: >>>> Some of the errors are tests timing out. It appears that some tests are >>>> leaving spinning JVM processes which exacerbates the problem. I haven't >>>> looked into why this is. >>> >>> Are these regressions? >> >> I don't believe so. The spinning processes are coming from the >> `forever' loop in os::abort() which is not reachable for `release' >> builds. > > Right, so this is a catastrophic failure. > >> NOTE: these invocations still had the `forever' code enabled, hence the >> errors. > > No, the errors are not due to the `forever' code. They are due to > the abort that triggered it. The idea is that you are supposed to > attach a debugger and find out why. I was trying to answer the question "are these regressions?". There are tests on tip that fail catastrophically too. I'll list what JTREG tests fail for tip and b111. > If you give me precise reproducer instructions I can have a look. OK; have broken networking right now but will follow up with my jtreg invocations when access is restored.
Andrew Haley <aph@redhat.com> writes: > On 12/04/2013 07:12 PM, Andrew McDermott wrote: >> >> Andrew Haley <aph@redhat.com> writes: >> >>> On 12/03/2013 07:14 AM, Andrew McDermott wrote: >>>> Some of the errors are tests timing out. It appears that some tests are >>>> leaving spinning JVM processes which exacerbates the problem. I haven't >>>> looked into why this is. >>> >>> Are these regressions? >> >> I don't believe so. The spinning processes are coming from the >> `forever' loop in os::abort() which is not reachable for `release' >> builds. > > Right, so this is a catastrophic failure. > >> NOTE: these invocations still had the `forever' code enabled, hence the >> errors. > > No, the errors are not due to the `forever' code. They are due to > the abort that triggered it. The idea is that you are supposed to > attach a debugger and find out why. > > If you give me precise reproducer instructions I can have a look. # Using jtreg from: # http://www.java.net/download/openjdk/jtreg/promoted/4.1/b05/jtreg-4.1-bin-b05_29_nov_2012.zip $ PATH=/home/aim/jtreg-bin/linux/bin:$PATH $ ~/tip-linux-aarch64-client-release/j2sdk-image/bin/java -version openjdk version "1.8.0-internal" OpenJDK Runtime Environment (build 1.8.0-internal-aim_2013_12_03_15_17-b00) OpenJDK 64-Bit Client VM (build 25.0-b52, mixed mode) $ jtreg -version jtreg, version 4.1 fcs b05 Installed in /home/aim/jtreg-bin/lib/jtreg.jar Running on platform version 1.8.0-internal from /usr/lib/jvm/java-8-openjdk/jre. Built with Java(TM) 2 SDK, Version 1.5.0-b64 on November 29, 2012. Copyright (c) 1999, 2012, Oracle and/or its affiliates. All rights reserved. Use is subject to license terms. TestNG: version 6.7-201209281340 These are the failing tests from a run against 'hotspot': $ ls -l drwxr-xr-x 4 aim aim 4096 Dec 4 19:54 JTreport-client-release-tip drwxr-xr-x 11 aim aim 4096 Dec 4 19:54 JTwork-client-release-tip $ egrep '[^ ]+[ ]+(Failed|Error)\.' JTreport-client-release-tip/text/summary.txt | awk '{print $1}' | sort compiler/7116216/StackOverflow.java compiler/8010927/Test8010927.java gc/metaspace/TestPerfCountersAndMemoryPools.java runtime/7107135/Test7107135.sh runtime/NMT/PrintNMTStatistics.java runtime/SharedArchiveFile/CdsDifferentObjectAlignment.java runtime/SharedArchiveFile/CdsSameObjectAlignment.java runtime/SharedArchiveFile/SharedArchiveFile.java runtime/jsig/Test8017498.sh runtime/memory/ReserveMemory.java serviceability/attach/AttachWithStalePidFile.java Running these failing tests again, ensuring we get a core dump. $ ulimit -c unlimited $ rm -rf JTwork JTreport $ jtreg -v1 -a -ignore:quiet -retain:all \ -agentvm -conc:4 -J-client \ -vmoption:-client \ -jdk:/home/aim/tip-linux-aarch64-client-release/j2sdk-image \ -w:JTwork \ -r:JTreport \ compiler/7116216/StackOverflow.java \ compiler/8010927/Test8010927.java \ gc/metaspace/TestPerfCountersAndMemoryPools.java \ runtime/7107135/Test7107135.sh runtime/NMT/PrintNMTStatistics.java \ runtime/SharedArchiveFile/CdsDifferentObjectAlignment.java \ runtime/SharedArchiveFile/CdsSameObjectAlignment.java \ runtime/SharedArchiveFile/SharedArchiveFile.java \ runtime/jsig/Test8017498.sh runtime/memory/ReserveMemory.java \ serviceability/attach/AttachWithStalePidFile.java I've omitted the output because I want to highlight those tests that produce a core dump. $ find JTwork -name hs_err\*.log JTwork/runtime/7107135/Test7107135/hs_err_pid12022.log JTwork/compiler/8010927/Test8010927/hs_err_pid12098.log JTwork/compiler/7116216/StackOverflow/hs_err_pid12086.log Individual reproducers: $ rm -rf JTwork JTreport $ jtreg -va -J-client -vmoption:-client \ -jdk:/home/aim/tip-linux-aarch64-client-release/j2sdk-image \ -w:JTwork -r:JTreport \ runtime/7107135/Test7107135.sh $ rm -rf JTwork JTreport $ jtreg -va -J-client -vmoption:-client \ -jdk:/home/aim/tip-linux-aarch64-client-release/j2sdk-image \ -w:JTwork -r:JTreport \ compiler/8010927/Test8010927.java $ rm -rf JTwork JTreport $ jtreg -va -J-client -vmoption:-client \ -jdk:/home/aim/tip-linux-aarch64-client-release/j2sdk-image \ -w:JTwork -r:JTreport \ compiler/7116216/StackOverflow.java Please let me know if you want the output from my hs_err* logs. HTH -- andy
On 12/03/2013 07:14 AM, Andrew McDermott wrote: > http://people.linaro.org/~andrew.mcdermott/b111/corba-b111.patch > http://people.linaro.org/~andrew.mcdermott/b111/hotspot-b111.patch > http://people.linaro.org/~andrew.mcdermott/b111/jaxp-b111.patch > http://people.linaro.org/~andrew.mcdermott/b111/jaxws-b111.patch > http://people.linaro.org/~andrew.mcdermott/b111/jdk-b111.patch > http://people.linaro.org/~andrew.mcdermott/b111/jdk8-b111.patch > http://people.linaro.org/~andrew.mcdermott/b111/langtools-b111.patch > http://people.linaro.org/~andrew.mcdermott/b111/nashorn-b111.patch This is OK. I can't commit it myself right now because I am not at my desk. If anyone else with commit access wants to do so, feel free. Andrew.
Andrew Haley <aph@redhat.com> writes: > On 12/03/2013 07:14 AM, Andrew McDermott wrote: >> http://people.linaro.org/~andrew.mcdermott/b111/corba-b111.patch >> http://people.linaro.org/~andrew.mcdermott/b111/hotspot-b111.patch >> http://people.linaro.org/~andrew.mcdermott/b111/jaxp-b111.patch >> http://people.linaro.org/~andrew.mcdermott/b111/jaxws-b111.patch >> http://people.linaro.org/~andrew.mcdermott/b111/jdk-b111.patch >> http://people.linaro.org/~andrew.mcdermott/b111/jdk8-b111.patch >> http://people.linaro.org/~andrew.mcdermott/b111/langtools-b111.patch >> http://people.linaro.org/~andrew.mcdermott/b111/nashorn-b111.patch > > This is OK. > > I can't commit it myself right now because I am not at my desk. If > anyone else with commit access wants to do so, feel free. Just for clarification, there's also the additional patch file: http://people.linaro.org/~andrew.mcdermott/b111/aarch64-hotspot-jdk8-b110-to-jdk8-b111.patch which should be imported after the one listed above -- assuming there is consensus that this patch is OK too.
On 12/06/2013 02:10 PM, Andrew McDermott wrote: > > Andrew Haley <aph@redhat.com> writes: > >> On 12/03/2013 07:14 AM, Andrew McDermott wrote: >>> http://people.linaro.org/~andrew.mcdermott/b111/corba-b111.patch >>> http://people.linaro.org/~andrew.mcdermott/b111/hotspot-b111.patch >>> http://people.linaro.org/~andrew.mcdermott/b111/jaxp-b111.patch >>> http://people.linaro.org/~andrew.mcdermott/b111/jaxws-b111.patch >>> http://people.linaro.org/~andrew.mcdermott/b111/jdk-b111.patch >>> http://people.linaro.org/~andrew.mcdermott/b111/jdk8-b111.patch >>> http://people.linaro.org/~andrew.mcdermott/b111/langtools-b111.patch >>> http://people.linaro.org/~andrew.mcdermott/b111/nashorn-b111.patch >> >> This is OK. >> >> I can't commit it myself right now because I am not at my desk. If >> anyone else with commit access wants to do so, feel free. > > Just for clarification, there's also the additional patch file: > > http://people.linaro.org/~andrew.mcdermott/b111/aarch64-hotspot-jdk8-b110-to-jdk8-b111.patch > > which should be imported after the one listed above -- assuming there is > consensus that this patch is OK too. OK. Andrew.
diff -r 0cd6fb9aac13 -r 631358b867dc src/cpu/aarch64/vm/aarch64.ad --- a/src/cpu/aarch64/vm/aarch64.ad Fri Nov 29 09:19:25 2013 +0000 +++ b/src/cpu/aarch64/vm/aarch64.ad Fri Nov 29 17:41:29 2013 +0000 @@ -1701,6 +1701,16 @@ return RegMask(); } +const RegMask Matcher::mathExactI_result_proj_mask() { + ShouldNotReachHere(); + return RegMask(); +} + +const RegMask Matcher::mathExactI_flags_proj_mask() { + ShouldNotReachHere(); + return RegMask(); +} + // helper for encoding java_to_runtime calls on sim // // this is needed to compute the extra arguments required when @@ -4465,6 +4475,8 @@ greater_equal(0xa, "ge"); less_equal(0xd, "le"); greater(0xc, "gt"); + overflow(0x6, "vs"); + no_overflow(0x7, "vc"); %} %} @@ -4482,6 +4494,8 @@ greater_equal(0x2, "hs"); less_equal(0x9, "ls"); greater(0x8, "hi"); + overflow(0x6, "vs"); + no_overflow(0x7, "vc"); %} %} diff -r 0cd6fb9aac13 -r 631358b867dc src/cpu/aarch64/vm/c1_Runtime1_aarch64.cpp --- a/src/cpu/aarch64/vm/c1_Runtime1_aarch64.cpp Fri Nov 29 09:19:25 2013 +0000 +++ b/src/cpu/aarch64/vm/c1_Runtime1_aarch64.cpp Fri Nov 29 17:41:29 2013 +0000 @@ -1415,7 +1415,7 @@ case access_field_patching_id: *cpool_addr = patch_field_offset; break; case load_mirror_patching_id: - *cpool_addr = (uint64_t)mirror(); break; + *cpool_addr = cast_from_oop<uint64_t>(mirror()); break; case load_klass_patching_id: *cpool_addr = (uint64_t)load_klass(); break; default: diff -r 0cd6fb9aac13 -r 631358b867dc src/cpu/aarch64/vm/frame_aarch64.cpp --- a/src/cpu/aarch64/vm/frame_aarch64.cpp Fri Nov 29 09:19:25 2013 +0000 +++ b/src/cpu/aarch64/vm/frame_aarch64.cpp Fri Nov 29 17:41:29 2013 +0000 @@ -637,7 +637,7 @@ #ifdef CC_INTERP obj = istate->_oop_temp; #else - obj = (oop) at(interpreter_frame_oop_temp_offset); + obj = cast_to_oop(at(interpreter_frame_oop_temp_offset)); #endif // CC_INTERP } else { oop* obj_p = (oop*)tos_addr; diff -r 0cd6fb9aac13 -r 631358b867dc src/cpu/aarch64/vm/methodHandles_aarch64.cpp --- a/src/cpu/aarch64/vm/methodHandles_aarch64.cpp Fri Nov 29 09:19:25 2013 +0000 +++ b/src/cpu/aarch64/vm/methodHandles_aarch64.cpp Fri Nov 29 17:41:29 2013 +0000 @@ -100,6 +100,8 @@ void MethodHandles::jump_from_method_handle(MacroAssembler* _masm, Register method, Register temp, bool for_compiler_entry) { assert(method == rmethod, "interpreter calling convention"); + Label L_no_such_method; + __ cbz(rmethod, L_no_such_method); __ verify_method_ptr(method); if (!for_compiler_entry && JvmtiExport::can_post_interpreter_events()) { @@ -119,6 +121,8 @@ Method::from_interpreted_offset(); __ ldr(rscratch1,Address(method, entry_offset)); __ br(rscratch1); + __ bind(L_no_such_method); + __ b(RuntimeAddress(StubRoutines::throw_AbstractMethodError_entry())); } void MethodHandles::jump_to_lambda_form(MacroAssembler* _masm, --- cut here ---
Hi, The attached or referenced changesets merge the aarch64-port to jdk8-b111. I have built both client and server and tested as follows: Cross-compilation ================= client/fastdebug/hotspot Test results: passed: 321; failed: 10; error: 8 server/fastdebug/hotspot (*) Test results: passed: 312; failed: 21; error: 6 (*) The server/fastdebug/hotspot test used an older---Linaro OpenEmbedded 13.10---client/release as the test harness. Builtin Simulator builds ======================== server/fastdebug/hotspot Test results: passed: 216; failed: 4; error: 10 client/fastdebug/hotspot Test results: passed: 329; failed: 8; error: 11 Some of the errors are tests timing out. It appears that some tests are leaving spinning JVM processes which exacerbates the problem. I haven't looked into why this is. As inlining all the changesets would make this email quite large I have copied them to: http://people.linaro.org/~andrew.mcdermott/b111/corba-b111.patch http://people.linaro.org/~andrew.mcdermott/b111/hotspot-b111.patch http://people.linaro.org/~andrew.mcdermott/b111/jaxp-b111.patch http://people.linaro.org/~andrew.mcdermott/b111/jaxws-b111.patch http://people.linaro.org/~andrew.mcdermott/b111/jdk-b111.patch http://people.linaro.org/~andrew.mcdermott/b111/jdk8-b111.patch http://people.linaro.org/~andrew.mcdermott/b111/langtools-b111.patch http://people.linaro.org/~andrew.mcdermott/b111/nashorn-b111.patch A tarball of all the patches, including the following inline patch, may be downloaded from: http://people.linaro.org/~andrew.mcdermott/b111.tar.gz The inline changeset below represents the changes to the hotspot aarch64 specific code to bring it in line with jdk8-b111. --- cut here --- # HG changeset patch # User Andrew McDermott <andrew.mcdermott@linaro.org> # Date 1385746889 0 # Node ID 631358b867dc330d3d865c9d170daccf4c4df794 # Parent 0cd6fb9aac13f79ac7b7db23235a183bcc01f655 aarch64 specific changes for merge to jdk8-b111