Fwd: cross compile OpenJDK-9+158 minimal variant failed when link libjvm.so (original) (raw)

Zhu Yong zhuyong.me at gmail.com
Thu Mar 9 02:17:38 UTC 2017

Yes, it's easy to test.

I am doing benchmark (SciMark and SPECjvm2008) on target system with the newly built server, client and minimal VM.

After done the benchmarks, I will build a test code and update again.

On Thu, Mar 9, 2017 at 9:49 AM, David Holmes <david.holmes at oracle.com> wrote:

On 9/03/2017 11:25 AM, Zhu Yong wrote:

Here is my latest update with good news

Yesterday pulled tips code from jdk9-dev and built with my current toolchain (no change), this time client and minimal VM finished the test code without any issue. The issue might relate to https://bugs.openjdk.java.net/browse/JDK-8175567, the final solution in http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/d6a0fe7ae0e8 is different from the very initial proposed solution (which I used in my previous build). Easy enough to test that theory. :) Glad things are now working. David ----- On Tue, Mar 7, 2017 at 5:54 AM, Chris Plummer <chris.plummer at oracle.com_ _<mailto:chris.plummer at oracle.com>> wrote: I haven't been following this too closely, but one thing to consider is that you are not getting proper floating point calling conventions. You mentioned your configure target ABI is arm-vfp-sflt. This means you have VFP support, but use the old softfloat calling conventions (FP values passed in GPRs). Most platforms these days with VFP support use the new hardfloat calling conventions (FP values passed in FPRs). So this could simply be the case of building the wrong binary for your platform. - Use arm-vfp-hflt is you have VFP support and want to use hard float calling conventions. - Use arm-vfp-sflt if you have VFP support and want to use the older soft float calling conventions. - Use arm-sflt is you have a true soft float platform. There's also a very old arm sflt ABI that I don't think we support. The main difference from arm-sflt is the word endianess of of 64-bit values. I believe the presence of -mfpu=vfp is what is used to get the more modern endianess, which to say the least is very non-obvious option for doing this, but is the reason you will see -mfpu=vfp for all our supported arm platforms (arm-vfp-hflt, arm-vfp-sflt, and arm-sflt). Here's the logic from the configure script: if test "x$ARMFLOATTYPE" = xvfp-sflt; then ARMFLOATTYPEFLAGS='-mfloat-abi=softfp -mfpu=vfp -DFLOATARCH=-vfp-sflt' elif test "x$ARMFLOATTYPE" = xvfp-hflt; then ARMFLOATTYPEFLAGS='-mfloat-abi=hard -mfpu=vfp -DFLOATARCH=-vfp-hflt' elif test "x$ARMFLOATTYPE" = xsflt; then ARMFLOATTYPEFLAGS='-msoft-float -mfpu=vfp' fi BTW, for the arm-sflt case, FLOATARCH gets set internally to "-sflt". I'm not sure why for arm-sflt it's handled in the source and the other two platforms set it in the configure script. cheers, Chris

On 3/5/17 8:30 PM, Zhu Yong wrote: Sometime later this week, I might get newer version of Marvell toolchain, I will do a build and test again then. I will update this thread when I get result. Thank you very much for helping. On Mon, Mar 6, 2017 at 9:09 AM, David Holmes <david.holmes at oracle.com <mailto:david.holmes at oracle.com>> wrote: On 3/03/2017 6:59 PM, Zhu Yong wrote: Thank you very much for helping. Today I tried to debug the test code, but without luck, still can't figure out why. First, I followed the instruction http://stackoverflow.com/quest ions/29916995/intellij-idea- <http://stackoverflow.com/ques_ _tions/29916995/intellij-idea-> remotely-debug-java-console-program, changed suspend=y because the test code is short, it will exit before debug start if not suspend first. Unfortunately, with remote debug, I was not able to reproduce the issue. Same class file, directly run, will produce the issue, remote debug won't. Then, I tried *jdb *from my OpenJDK9 client vm, run directly on my target system to debug the code. If I set breakpoint, program run without issue, however, if don't set breakpoint, just "run" in jdb, problem reproduced. This suggests to me that a floating-point register is not being preserved when needed. When you run with the breakpoint you will get full save/restore of all the register state. Just a theory. Next, I tried to use *javap *to decompile the output class file, run OpenJDK9 client vm javap and host side javap on same class file, the output is same for getTime function. It is a native code issue not a bytecode issue, so javap wont help here. One interesting point I noticed today is the output like below when problem happen, 2nd call of getTime() has value of 1st call result / 1000. Looks like 2nd call getTime(), double variable q was not updated startTime: 284092.063000 endTime: 284.092063 runTime: -283807.970937 What should I do so that I can come a conclusion that it's due to compiler issue? Can you get access to a different gcc to build with? David ----- On Thu, Mar 2, 2017 at 12:32 PM, David Holmes <david.holmes at oracle.com <mailto:david.holmes at oracle.com> <mailto:david.holmes at oracle.com_ _<mailto:david.holmes at oracle.com>>> wrote: I built your sample program with latest JDK 9 for arm-vfp-sflt and ran on an emulator I have available, and I had no issues. So I still have concerns this may be a build/compiler issue. David On 2/03/2017 12:51 PM, David Holmes wrote: I've moved this discussion over to hotspot-dev as this seems no longer a build issue but a C1 soft-float issue. David On 2/03/2017 12:35 PM, Zhu Yong wrote: If run with -Xint, it works. I have created simplified FP test by remove all non-related code from Whetstone test code. The test code is here: https://gist.github.com/yongz hy/d65c26d39fe5d549d1b406c7c84e <https://gist.github.com/yongz_ _hy/d65c26d39fe5d549d1b406c7c84e> acd4 <https://gist.github.com/yong_ _zhy/d65c26d39fe5d549d1b406c7c84_ _<https://gist.github.com/yongz_ _hy/d65c26d39fe5d549d1b406c7c84> eacd4> I am not sure if the test code can help or not. The behaviour is weird : - If I print both itime and q, program will run OK - inside condition block if(q<1.0f), if I_ _use exit code_ _2,3,4,5, problem_ _appears, however, if I use exit code >=6, program run OK. I always get exit code 5, the line q = (double)itime is wrong? public static double getTime() { double q; long itime; itime = System.currentTimeMillis(); if(itime<1000000) { System.exit(1); } //System.out.printf("time long value %d\n", itime); q = (double) itime; if(q < 1.0f) { System.exit(5); // I always get exit code 5 } //System.out.printf("time float value %f\n", q); return q / 1000.0; }

On Wed, Mar 1, 2017 at 5:31 PM, David Holmes <david.holmes at oracle.com_ _<mailto:david.holmes at oracle.com> <mailto:david.holmes at oracle.com_ _<mailto:david.holmes at oracle.com>> <mailto:david.holmes at oracle.com_ _<mailto:david.holmes at oracle.com> <mailto:david.holmes at oracle.com_ _<mailto:david.holmes at oracle.com>>>> wrote: On 1/03/2017 6:45 PM, Zhu Yong wrote: OK, for the Whetstone Benchmark, I added debug printing and found it's due to function getTime(), it only get good value on 1st call, all following calls get 0s. Debug printing of itime value is correct. So reason should be the return division line. Could it because toolchain's floating point operation??? But why server VM Ok? Server and client implement FP logic differently, and particularly as this is soft-fp, they may well not be in sync. Does -Xint work? Can you isolate to a simple FP test? David public static double getTime() { double q; long itime; itime = System.currentTimeMillis(); q = (double) itime; return q / 1000.0; } On Wed, Mar 1, 2017 at 3:14 PM, David Holmes <david.holmes at oracle.com_ _<mailto:david.holmes at oracle.com> <mailto:david.holmes at oracle.com_ _<mailto:david.holmes at oracle.com>> <mailto:david.holmes at oracle.com_ _<mailto:david.holmes at oracle.com> <mailto:david.holmes at oracle.com_ _<mailto:david.holmes at oracle.com>>> <mailto:david.holmes at oracle.com_ _<mailto:david.holmes at oracle.com> <mailto:david.holmes at oracle.com_ _<mailto:david.holmes at oracle.com>> <mailto:david.holmes at oracle.com_ _<mailto:david.holmes at oracle.com> <mailto:david.holmes at oracle.com_ _<mailto:david.holmes at oracle.com>>>>> wrote: On 1/03/2017 4:26 PM, Zhu Yong wrote: We use armv7-marvell-linux-gnueabi-softfp toolchain gcc version 4.6.4 (Marvell GCC release 20150204-c4af733b 64K MAXPAGESIZE ALIGN CVE-2015-0235) Is this toolchain too old? I am asking because I saw other strange issues as well: We last used gcc 4.7.2. I can't really say if 4.6.4 is "too old". I have successfully build server, client and minimal VM, when I run Dhrystone benchmark file (the same jar file from http://www.okayan.jp/DhrystoneApplet/ <http://www.okayan.jp/DhrystoneApplet/> <http://www.okayan.jp/DhrystoneApplet/_ _<http://www.okayan.jp/DhrystoneApplet/>> <http://www.okayan.jp/DhrystoneApplet/_ _<http://www.okayan.jp/DhrystoneApplet/> <http://www.okayan.jp/DhrystoneApplet/_ _<http://www.okayan.jp/DhrystoneApplet/>>> <http://www.okayan.jp/DhrystoneApplet/_ _<http://www.okayan.jp/DhrystoneApplet/> <http://www.okayan.jp/DhrystoneApplet/_ _<http://www.okayan.jp/DhrystoneApplet/>> <http://www.okayan.jp/DhrystoneApplet/_ _<http://www.okayan.jp/DhrystoneApplet/> <http://www.okayan.jp/DhrystoneApplet/_ _<http://www.okayan.jp/DhrystoneApplet/>>>>), the performance from server VM is much better than client and minimal VM. (minimal: 1629852, client: 1615508, server: 2338871 ) That's expected. The server VM is high performance. And when run Whetstone Benchmark from http://www.roylongbottom.org.uk/online/whetjava2.html <http://www.roylongbottom.org.uk/online/whetjava2.html> <http://www.roylongbottom.org.uk/online/whetjava2.html_ _<http://www.roylongbottom.org.uk/online/whetjava2.html>> <http://www.roylongbottom.org.uk/online/whetjava2.html_ _<http://www.roylongbottom.org.uk/online/whetjava2.html> <http://www.roylongbottom.org.uk/online/whetjava2.html_ _<http://www.roylongbottom.org.uk/online/whetjava2.html>>> <http://www.roylongbottom.org.uk/online/whetjava2.html_ _<http://www.roylongbottom.org.uk/online/whetjava2.html> <http://www.roylongbottom.org.uk/online/whetjava2.html_ _<http://www.roylongbottom.org.uk/online/whetjava2.html>> <http://www.roylongbottom.org.uk/online/whetjava2.html_ _<http://www.roylongbottom.org.uk/online/whetjava2.html> <http://www.roylongbottom.org.uk/online/whetjava2.html_ _<http://www.roylongbottom.org.uk/online/whetjava2.html_ _>>>>, server VM finished with good result, client and minimal VM not able to finish (program stuck there forever after print 1st line of output). That needs investigating. You need to try and generate a stackdump to see where things are stuck. David On Wed, Mar 1, 2017 at 1:56 PM, David Holmes <david.holmes at oracle.com_ _<mailto:david.holmes at oracle.com> <mailto:david.holmes at oracle.com_ _<mailto:david.holmes at oracle.com>> <mailto:david.holmes at oracle.com_ _<mailto:david.holmes at oracle.com> <mailto:david.holmes at oracle.com_ _<mailto:david.holmes at oracle.com>>> <mailto:david.holmes at oracle.com_ _<mailto:david.holmes at oracle.com> <mailto:_ _david.holmes at oracle.com <mailto:david.holmes at oracle.com>> <mailto:david.holmes at oracle.com_ _<mailto:david.holmes at oracle.com> <mailto:david.holmes at oracle.com_ _<mailto:david.holmes at oracle.com>>>> <mailto:david.holmes at oracle.com_ _<mailto:david.holmes at oracle.com> <mailto:david.holmes at oracle.com_ _<mailto:david.holmes at oracle.com>> <mailto:david.holmes at oracle.com_ _<mailto:david.holmes at oracle.com> <mailto:david.holmes at oracle.com_ _<mailto:david.holmes at oracle.com>>> <mailto:david.holmes at oracle.com_ _<mailto:david.holmes at oracle.com> <mailto:david.holmes at oracle.com_ _<mailto:david.holmes at oracle.com>> <mailto:david.holmes at oracle.com_ _<mailto:david.holmes at oracle.com> <mailto:david.holmes at oracle.com_ _<mailto:david.holmes at oracle.com>>>>>> wrote: On 1/03/2017 3:39 PM, Zhu Yong wrote: Thank you for the information, I managed to make minimal build pass now. Initially I though JVMEXCLUDEFILES need to add additional 3 generated files (they appeared in BUILDLIBJVMobjectfilenames.txt) : bytecodeInterpreterWithChecks.cpp jvmtiEnter.cpp jvmtiEnterTrace.cpp But build still fail with same error message. Finally I figured out it's due to those 8 doit() functions implementation in jvmtiEnvBase.hpp file. After move all those 8 doit() implementations to jvmtiEnvBase.cpp, build of minimal VM passed without any issue. That seems to be a compiler issue. jvmtiEnvBase.hpp is unconditionally included in a couple of places because we have to have enough of the JVMTI code to say JVMTI is not available. Those doit() implementations, though arguably could be conditional on INCLUDEJVMTI, are not referenced by any called code and so should not linked in. But in your case it seems they are. What toolchain are you using? David ----- Changes appended ============= --- .../src/share/vm/prims/jvmtiE nvBase.cpp | 74 ++++++++++++++++++++++ .../src/share/vm/prims/jvmtiE nvBase.hpp | 68 +++----------------- 2 files changed, 82 insertions(+), 60 deletions(-) mode change 100644 => 100755 hotspot-9211c2e89c1c/src/share /vm/prims/jvmtiEnvBase.cpp mode change 100644 => 100755 hotspot-9211c2e89c1c/src/share /vm/prims/jvmtiEnvBase.hpp diff --git a/hotspot-9211c2e89c1c/src/sh are/vm/prims/jvmtiEnvBase.cpp b/hotspot-9211c2e89c1c/src/sh are/vm/prims/jvmtiEnvBase.cpp old mode 100644 new mode 100755 index dd241a0..e5832ba --- a/hotspot-9211c2e89c1c/src/sh are/vm/prims/jvmtiEnvBase.cpp +++ b/hotspot-9211c2e89c1c/src/sh are/vm/prims/jvmtiEnvBase.cpp @@ -1283,6 +1283,80 @@ VMGetMultipleStackTraces::all ocateandfillstacks(jint threadcount) { "the last copied frame info must be the last record"); } +void +VMUpdateForPopTopFrame::doit() { + JavaThread* jt = state->getthread(); + if (Threads::includes(jt) && !jt->isexiting() && jt->threadObj() != NULL) { + state->updateforpoptopfra me(); + } else { + result = JVMTIERRORTHREADNOTALIVE; + } +} + +void +VMSetFramePop::doit() { + JavaThread* jt = state->getthread(); + if (Threads::includes(jt) && !jt->isexiting() && jt->threadObj() != NULL) { + int framenumber = state->countframes() - depth; +

state->envthreadstate((Jvm tiEnvBase*)env)->setframe pop(framenumber); + } else { + result = JVMTIERRORTHREADNOTALIVE; + } +} + +void +VMGetOwnedMonitorInfo::doit() { + result = JVMTIERRORTHREADNOTALIVE; + if (Threads::includes(javathread) && !javathread->isexiting() + && javathread->threadObj() != NULL) { + result = ((JvmtiEnvBase *)env)->getownedmonitors(callingthread, javathread, + ownedmonitorslist); + } +} + +void +VMGetObjectMonitorUsage::doit() { + result = ((JvmtiEnvBase*) env)->getobjectmonitorusage(callingthread, object, infoptr); +} + +void +VMGetCurrentContendedMonitor::doit() { + result = JVMTIERRORTHREADNOTALIVE; + if (Threads::includes(javathread) && !javathread->isexiting() && + javathread->threadObj() != NULL) { + result = ((JvmtiEnvBase *)env)->getcurrentcontendedmonitor(callingthread, javathread,ownedmonitorptr); + } +} + +void +VMGetStackTrace::doit() { + result = JVMTIERRORTHREADNOTALIVE; + if (Threads::includes(javathread) && !javathread->isexiting() + && javathread->threadObj() != NULL) { + result = ((JvmtiEnvBase *)env)->getstacktrace(javathread, + startdepth, maxcount, + framebuffer, countptr); + } +} + +void +VMGetFrameCount::doit() { + result = JVMTIERRORTHREADNOTALIVE; + JavaThread* jt = state->getthread(); + if (Threads::includes(jt) && !jt->isexiting() && jt->threadObj() != NULL) { + result = ((JvmtiEnvBase*)env)->get fra mecount(state, countptr); + } +} + +void +VMGetFrameLocation::doit() { + result = JVMTIERRORTHREADNOTALIVE; + if (Threads::includes(javathread) && !javathread->isexiting() && + javathread->threadObj() != NULL) { + result = ((JvmtiEnvBase*)env)->getfra melocation(javathread, depth, + methodptr, locationptr); + } +} void VMGetThreadListStackTraces::doit() { diff --git a/hotspot-9211c2e89c1c/src/sh are/vm/prims/jvmtiEnvBase.hpp b/hotspot-9211c2e89c1c/src/sh are/vm/prims/jvmtiEnvBase.hpp old mode 100644 new mode 100755 index 04e6869..00b9890 --- a/hotspot-9211c2e89c1c/src/sh are/vm/prims/jvmtiEnvBase.hpp +++ b/hotspot-9211c2e89c1c/src/sh are/vm/prims/jvmtiEnvBase.hpp @@ -359,14 +359,7 @@ public: } VMOpType type() const { return VMOpUpdateForPopTopFrame; } jvmtiError result() { return result; } - void doit() { - JavaThread* jt = state->getthread(); - if (Threads::includes(jt) && !jt->isexiting() && jt->threadObj() != NULL) { - state->updateforpoptopframe(); - } else { - result =

More information about the hotspot-dev mailing list