Fwd: cross compile OpenJDK-9+158 minimal variant failed when link libjvm.so
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$ARM_FLOAT_TYPE" = xvfp-sflt; then
>> ARM_FLOAT_TYPE_FLAGS='-mfloat-abi=softfp -mfpu=vfp
>> -DFLOAT_ARCH=-vfp-sflt'
>> elif test "x$ARM_FLOAT_TYPE" = xvfp-hflt; then
>> ARM_FLOAT_TYPE_FLAGS='-mfloat-abi=hard -mfpu=vfp
>> -DFLOAT_ARCH=-vfp-hflt'
>> elif test "x$ARM_FLOAT_TYPE" = xsflt; then
>> ARM_FLOAT_TYPE_FLAGS='-msoft-float -mfpu=vfp'
>> fi
>>
>> BTW, for the arm-sflt case, FLOAT_ARCH 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
>> JVM_EXCLUDE_FILES
>> need to add
>> additional 3
>> generated
>> files (they appeared
>> in
>> _BUILD_LIBJVM_objectfilenames.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
>> INCLUDE_JVMTI, 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
>> @@
>>
>> VM_GetMultipleStackTraces::all
>> ocate_and_fill_stacks(jint
>> thread_count) {
>> "the last
>> copied frame
>> info must be
>> the last
>> record");
>> }
>>
>> +void
>>
>> +VM_UpdateForPopTopFrame::doit() {
>> + JavaThread* jt =
>> _state->get_thread();
>> + if
>> (Threads::includes(jt) &&
>> !jt->is_exiting() &&
>> jt->threadObj() !=
>> NULL) {
>> +
>> _state->update_for_pop_top_fra
>> me();
>> + } else {
>> + _result =
>> JVMTI_ERROR_THREAD_NOT_ALIVE;
>> + }
>> +}
>> +
>> +void
>>
>> +VM_SetFramePop::doit() {
>> + JavaThread* jt =
>> _state->get_thread();
>> + if
>> (Threads::includes(jt) &&
>> !jt->is_exiting() &&
>> jt->threadObj() !=
>> NULL) {
>> + int
>> frame_number =
>> _state->count_frames() -
>> _depth;
>> +
>>
>>
>>
>>
>> _state->env_thread_state((Jvm
>> tiEnvBase*)_env)->set_frame_
>> pop(frame_number);
>>
>> + } else {
>> + _result =
>> JVMTI_ERROR_THREAD_NOT_ALIVE;
>> + }
>> +}
>> +
>> +void
>>
>> +VM_GetOwnedMonitorInfo::doit() {
>> + _result =
>> JVMTI_ERROR_THREAD_NOT_ALIVE;
>> + if
>> (Threads::includes(_java_thread) &&
>>
>> !_java_thread->is_exiting()
>> +
>> &&
>>
>> _java_thread->threadObj() !=
>> NULL) {
>> + _result =
>> ((JvmtiEnvBase
>>
>> *)_env)->get_owned_monitors(_calling_thread,
>> _java_thread,
>> +
>>
>> _owned_monitors_list);
>> + }
>> +}
>> +
>> +void
>>
>> +VM_GetObjectMonitorUsage::doit() {
>> + _result =
>> ((JvmtiEnvBase*)
>>
>>
>> _env)->get_object_monitor_usage(_calling_thread,
>> _object,
>> _info_ptr);
>> +}
>> +
>> +void
>>
>> +VM_GetCurrentContendedMonitor::doit()
>> {
>> + _result =
>> JVMTI_ERROR_THREAD_NOT_ALIVE;
>> + if
>> (Threads::includes(_java_thread) &&
>>
>> !_java_thread->is_exiting() &&
>> +
>> _java_thread->threadObj() !=
>> NULL) {
>> + _result =
>> ((JvmtiEnvBase
>>
>>
>>
>>
>> *)_env)->get_current_contended_monitor(_calling_thread,_
>> java_thread,_owned_monitor_ptr);
>>
>> + }
>> +}
>> +
>> +void
>>
>> +VM_GetStackTrace::doit() {
>> + _result =
>> JVMTI_ERROR_THREAD_NOT_ALIVE;
>> + if
>> (Threads::includes(_java_thread) &&
>>
>> !_java_thread->is_exiting()
>> +
>> &&
>>
>> _java_thread->threadObj() !=
>> NULL) {
>> + _result =
>> ((JvmtiEnvBase
>>
>> *)_env)->get_stack_trace(_java_thread,
>> +
>> _start_depth,
>> _max_count,
>> +
>> _frame_buffer,
>> _count_ptr);
>> + }
>> +}
>> +
>> +void
>>
>> +VM_GetFrameCount::doit() {
>> + _result =
>> JVMTI_ERROR_THREAD_NOT_ALIVE;
>> + JavaThread* jt =
>> _state->get_thread();
>> + if
>> (Threads::includes(jt) &&
>> !jt->is_exiting() &&
>> jt->threadObj() !=
>> NULL) {
>> + _result =
>> ((JvmtiEnvBase*)_env)->get_
>> fra
>> me_count(_state,
>> _count_ptr);
>> + }
>> +}
>> +
>> +void
>>
>> +VM_GetFrameLocation::doit() {
>> + _result =
>> JVMTI_ERROR_THREAD_NOT_ALIVE;
>> + if
>> (Threads::includes(_java_thread) &&
>>
>> !_java_thread->is_exiting() &&
>> +
>> _java_thread->threadObj() !=
>> NULL) {
>> + _result =
>>
>> ((JvmtiEnvBase*)_env)->get_fra
>> me_location(_java_thread,
>> _depth,
>> +
>> _method_ptr,
>> _location_ptr);
>> + }
>> +}
>>
>> void
>>
>> VM_GetThreadListStackTraces::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:
>> }
>> VMOp_Type type()
>> const { return
>> VMOp_UpdateForPopTopFrame; }
>> jvmtiError
>> result() { return
>> _result; }
>> - void doit() {
>> - JavaThread* jt =
>> _state->get_thread();
>> - if
>> (Threads::includes(jt) &&
>> !jt->is_exiting() &&
>> jt->threadObj()
>> != NULL) {
>> -
>> _state->update_for_pop_top_frame();
>> - } else {
>> - _result =
>
>
More information about the hotspot-dev
mailing list