Fwd: cross compile OpenJDK-9+158 minimal variant failed when link libjvm.so
Zhu Yong
zhuyong.me at gmail.com
Tue Mar 14 02:10:18 UTC 2017
I confirmed the floating point issue is due to the solution I applied for
https://bugs.openjdk.java.net/browse/JDK-8175567
If I use the initial version of solution, can see the floating point issue,
if use the final solution won't see.
Thank you very much for helping.
On Thu, Mar 9, 2017 at 10:17 AM, Zhu Yong <zhuyong.me at gmail.com> wrote:
> 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_contende
>>> d_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