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/questions/29916995/intellij-idea-
> <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>
> <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/yongzhy/d65c26d39fe5d549d1b406c7c84e
> <https://gist.github.com/yongzhy/d65c26d39fe5d549d1b406c7c84e>
> acd4
>
> <https://gist.github.com/yongzhy/d65c26d39fe5d549d1b406c7c84
> <https://gist.github.com/yongzhy/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/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_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/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>>>>>
>
> <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
> <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),
>
>