Fwd: cross compile OpenJDK-9+158 minimal variant failed when link libjvm.so
Zhu Yong
zhuyong.me at gmail.com
Thu Mar 9 01:25:30 UTC 2017
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).
On Tue, Mar 7, 2017 at 5:54 AM, Chris Plummer <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>
>> 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/questions/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>> 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
>>>> acd4
>>>> <https://gist.github.com/yong
>>>> zhy/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>>> 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>>>> 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/>>>), 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>>>,
>>>> 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>>>>> 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/share/vm/prims/jvmtiEnvBase.cpp
>>>>
>>>>
>>>> b/hotspot-9211c2e89c1c/src/share/vm/prims/jvmtiEnvBase.cpp
>>>> old mode 100644
>>>> new mode 100755
>>>> index dd241a0..e5832ba
>>>> ---
>>>>
>>>> a/hotspot-9211c2e89c1c/src/share/vm/prims/jvmtiEnvBase.cpp
>>>> +++
>>>>
>>>> b/hotspot-9211c2e89c1c/src/share/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((JvmtiEnvBase*)_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_GetCurrentContendedMonito
>>>> r::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::d
>>>> oit()
>>>> {
>>>> diff --git
>>>>
>>>>
>>>> a/hotspot-9211c2e89c1c/src/share/vm/prims/jvmtiEnvBase.hpp
>>>>
>>>>
>>>> b/hotspot-9211c2e89c1c/src/share/vm/prims/jvmtiEnvBase.hpp
>>>> old mode 100644
>>>> new mode 100755
>>>> index 04e6869..00b9890
>>>> ---
>>>>
>>>> a/hotspot-9211c2e89c1c/src/share/vm/prims/jvmtiEnvBase.hpp
>>>> +++
>>>>
>>>> b/hotspot-9211c2e89c1c/src/share/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 =
>>>> JVMTI_ERROR_THREAD_NOT_ALIVE;
>>>> - }
>>>> - }
>>>> + void doit();
>>>> };
>>>>
>>>> // VM operation to set frame pop.
>>>> @@ -389,15 +382,7 @@ public:
>>>> bool
>>>> allow_nested_vm_operations()
>>>> const {
>>>> return true; }
>>>> VMOp_Type type() const { return
>>>> VMOp_SetFramePop; }
>>>> jvmtiError result() { return
>>>> _result; }
>>>> - void 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((JvmtiEnvBase*)_env)->set_frame_
>>>> pop(frame_number);
>>>>
>>>> - } else {
>>>> - _result =
>>>> JVMTI_ERROR_THREAD_NOT_ALIVE;
>>>> - }
>>>> - }
>>>> + void doit();
>>>> };
>>>>
>>>>
>>>> @@ -421,14 +406,7 @@ public:
>>>> _result = JVMTI_ERROR_NONE;
>>>> }
>>>> VMOp_Type type() const { return
>>>> VMOp_GetOwnedMonitorInfo; }
>>>> - void 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 doit();
>>>> jvmtiError result() { return
>>>> _result; }
>>>> };
>>>>
>>>> @@ -451,10 +429,7 @@ public:
>>>> }
>>>> VMOp_Type type() const { return
>>>> VMOp_GetObjectMonitorUsage; }
>>>> jvmtiError result() { return
>>>> _result; }
>>>> - void doit() {
>>>> - _result = ((JvmtiEnvBase*)
>>>>
>>>> _env)->get_object_monitor_usage(_calling_thread,
>>>> _object,
>>>> _info_ptr);
>>>> - }
>>>> -
>>>> + void doit();
>>>> };
>>>>
>>>> // VM operation to get current
>>>> contended
>>>> monitor.
>>>> @@ -475,13 +450,7 @@ public:
>>>> }
>>>> VMOp_Type type() const { return
>>>> VMOp_GetCurrentContendedMonitor; }
>>>> jvmtiError result() { return
>>>> _result; }
>>>> - void 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 doit();
>>>> };
>>>>
>>>> // VM operation to get stack trace
>>>> at safepoint.
>>>> @@ -508,15 +477,7 @@ public:
>>>> }
>>>> jvmtiError result() { return
>>>> _result; }
>>>> VMOp_Type type() const { return
>>>> VMOp_GetStackTrace; }
>>>> - void 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 doit();
>>>> };
>>>>
>>>> // forward declaration
>>>> @@ -606,13 +567,7 @@ public:
>>>> }
>>>> VMOp_Type type() const { return
>>>> VMOp_GetFrameCount; }
>>>> jvmtiError result() { return
>>>> _result; }
>>>> - void 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 doit();
>>>> };
>>>>
>>>> // VM operation to frame location
>>>> at safepoint.
>>>> @@ -636,14 +591,7 @@ public:
>>>> }
>>>> VMOp_Type type() const { return
>>>> VMOp_GetFrameLocation; }
>>>> jvmtiError result() { return
>>>> _result; }
>>>> - void 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 doit();
>>>> };
>>>>
>>>>
>>>> --
>>>> 2.1.4
>>>>
>>>>
>>>> On Tue, Feb 28, 2017 at 6:11 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 28/02/2017 7:35 PM, David
>>>> Holmes wrote:
>>>>
>>>> On 28/02/2017 6:51 PM, Zhu
>>>> Yong wrote:
>>>>
>>>> Dear All,
>>>>
>>>> I am testing cross
>>>> compile
>>>> OpenJDK-9+158 for our
>>>> embedded
>>>> system using
>>>> buildroot, I can build
>>>> server and
>>>> client
>>>> variants
>>>> successfully, but the
>>>> output compact1 profile
>>>> file size
>>>> is too
>>>> big, then I
>>>> tried
>>>> to build
>>>> minimal
>>>> variant, failed when
>>>> linking
>>>> libjvm.so.
>>>>
>>>> I checked
>>>>
>>>>
>>>>
>>>>
>>>> build/linux-arm-normal-minimal-release/hotspot/variant-
>>>> minimal/
>>>>
>>>> libjvm/objs/_BUILD_LIBJVM_objectfilenames.txt,
>>>> jvmtiEnvBase.o
>>>> and
>>>> jvmtiEnvThreadState.o are not
>>>> listed in
>>>> the file
>>>> (which
>>>> is required
>>>> from the error message
>>>> below).
>>>>
>>>>
>>>> Right - JVM TI is not part
>>>> of the
>>>> Minimal VM. At the
>>>> moment it looks
>>>> like some service has
>>>> either
>>>> been
>>>> enabled when
>>>> it should not
>>>> have been,
>>>> or has not been correctly
>>>> if'def in the
>>>> source.
>>>>
>>>>
>>>> As far as I can see your error
>>>> messages are
>>>> complaining about
>>>> missing functions that are
>>>> called from the
>>>> same
>>>> sources as the
>>>> functions that are missing! ie.
>>>>
>>>> undefined reference to
>>>>
>>>>
>>>> `JvmtiEnvBase::get_current_contended_monitor(JavaThread*,
>>>> JavaThread*,
>>>> _jobject**)'
>>>> /tmp/cc27HS5M.ltrans0.ltrans.
>>>> o:
>>>> In function
>>>> `VM_GetOwnedMonitorInfo::
>>>> doit()
>>>>
>>>> but VM_GetOwnedMonitorInfo is
>>>> defined in
>>>> jvmtiEnv.cpp which
>>>> should
>>>> be included or excluded the
>>>> same
>>>> as
>>>> jvmtiEnBase.cpp.
>>>> Here's the
>>>> logic in the makefile that
>>>> controls this:
>>>>
>>>> ifneq ($(call
>>>> check-jvm-feature,
>>>> jvmti),
>>>
>>>
More information about the hotspot-dev
mailing list