RFR(S): 8191049: Add alternate version of pns() that is callable from within hotspot source

classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

RFR(S): 8191049: Add alternate version of pns() that is callable from within hotspot source

Chris Plummer
Hi,

Please review the following:

https://bugs.openjdk.java.net/browse/JDK-8191049

diff --git a/src/hotspot/share/utilities/debug.cpp
b/src/hotspot/share/utilities/debug.cpp
--- a/src/hotspot/share/utilities/debug.cpp
+++ b/src/hotspot/share/utilities/debug.cpp
@@ -631,6 +631,24 @@
    VMError::print_native_stack(tty, fr, t, buf, sizeof(buf));
  }

+//
+// This version of pns() will not work when called from the debugger,
but is
+// useful when called from within hotspot code. The advantages over pns()
+// are not having to pass in any arguments, and it will work on
Windows/x64.
+//
+extern "C" void pns2() { // print native stack
+  Command c("pns2");
+  static char buf[O_BUFLEN];
+  if (os::platform_print_native_stack(tty, NULL, buf, sizeof(buf))) {
+    // We have printed the native stack in platform-specific code,
+    // so nothing else to do in this case.
+  } else {
+    Thread* t = Thread::current_or_null();
+    frame fr = os::current_frame();
+    VMError::print_native_stack(tty, fr, t, buf, sizeof(buf));
+  }
+}
+
  #endif // !PRODUCT

There is also a pre-existing thread with some discussion:

http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2017-November/025134.html

thanks,

Chris

Reply | Threaded
Open this post in threaded view
|

Re: RFR(S): 8191049: Add alternate version of pns() that is callable from within hotspot source

Thomas Stüfe-2
Hi Chris,

looks fine as a debugging aid.

But it occurred to me that it may be a bit dangerous to call this from
non-errorhandler settings. I recall seeing quite a few secondary crashes in
VMError::print_native_stack() in hs-err files over time. Especially for
native non-java threads. Usually this did not matter that much because
these crashes are handled by secondary error handling when printing the
hs-err file. But if we call it outside of error handling, we are on our own.

So. IMHO, to use this functions as a debugging aid is fine, if one can
accept a slight risk of crashing the VM. If this is not acceptable, may we
need some more tests for this function?

Kind Regards, Thomas



On Thu, Nov 9, 2017 at 9:29 PM, Chris Plummer <[hidden email]>
wrote:

> Hi,
>
> Please review the following:
>
> https://bugs.openjdk.java.net/browse/JDK-8191049
>
> diff --git a/src/hotspot/share/utilities/debug.cpp
> b/src/hotspot/share/utilities/debug.cpp
> --- a/src/hotspot/share/utilities/debug.cpp
> +++ b/src/hotspot/share/utilities/debug.cpp
> @@ -631,6 +631,24 @@
>    VMError::print_native_stack(tty, fr, t, buf, sizeof(buf));
>  }
>
> +//
> +// This version of pns() will not work when called from the debugger, but
> is
> +// useful when called from within hotspot code. The advantages over pns()
> +// are not having to pass in any arguments, and it will work on
> Windows/x64.
> +//
> +extern "C" void pns2() { // print native stack
> +  Command c("pns2");
> +  static char buf[O_BUFLEN];
> +  if (os::platform_print_native_stack(tty, NULL, buf, sizeof(buf))) {
> +    // We have printed the native stack in platform-specific code,
> +    // so nothing else to do in this case.
> +  } else {
> +    Thread* t = Thread::current_or_null();
> +    frame fr = os::current_frame();
> +    VMError::print_native_stack(tty, fr, t, buf, sizeof(buf));
> +  }
> +}
> +
>  #endif // !PRODUCT
>
> There is also a pre-existing thread with some discussion:
>
> http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2
> 017-November/025134.html
>
> thanks,
>
> Chris
>
>
Reply | Threaded
Open this post in threaded view
|

Re: RFR(S): 8191049: Add alternate version of pns() that is callable from within hotspot source

Thomas Stüfe-2
Hi Chris,

Thank you. Yes, a comment may make sense, and/or restricting this function
to not product. Otherwise the change is fine and useful, I’ll use it
probably before long.

Thanks, Thomas

On Fri 10. Nov 2017 at 21:55, Chris Plummer <[hidden email]>
wrote:

> Hi Thomas,
>
> There's certainly no intent to leave in place any calls someone might add
> to pns2(). It's meant as a temporary debugging aide only. So if it were to
> fail for any reason, IMO that's no different than adding any other sort of
> temporary debugging code that could possibly crash. You fix your mistake
> and resume your debugging. If you want I can add comments that include such
> a warning.
>
> thanks,
>
> Chris
>
>
>
> On 11/10/17 12:11 AM, Thomas Stüfe wrote:
>
> Hi Chris,
>
> looks fine as a debugging aid.
>
> But it occurred to me that it may be a bit dangerous to call this from
> non-errorhandler settings. I recall seeing quite a few secondary crashes in
> VMError::print_native_stack() in hs-err files over time. Especially for
> native non-java threads. Usually this did not matter that much because
> these crashes are handled by secondary error handling when printing the
> hs-err file. But if we call it outside of error handling, we are on our own.
>
> So. IMHO, to use this functions as a debugging aid is fine, if one can
> accept a slight risk of crashing the VM. If this is not acceptable, may we
> need some more tests for this function?
>
> Kind Regards, Thomas
>
>
>
> On Thu, Nov 9, 2017 at 9:29 PM, Chris Plummer <[hidden email]>
> wrote:
>
>> Hi,
>>
>> Please review the following:
>>
>> https://bugs.openjdk.java.net/browse/JDK-8191049
>>
>> diff --git a/src/hotspot/share/utilities/debug.cpp
>> b/src/hotspot/share/utilities/debug.cpp
>> --- a/src/hotspot/share/utilities/debug.cpp
>> +++ b/src/hotspot/share/utilities/debug.cpp
>> @@ -631,6 +631,24 @@
>>    VMError::print_native_stack(tty, fr, t, buf, sizeof(buf));
>>  }
>>
>> +//
>> +// This version of pns() will not work when called from the debugger,
>> but is
>> +// useful when called from within hotspot code. The advantages over pns()
>> +// are not having to pass in any arguments, and it will work on
>> Windows/x64.
>> +//
>> +extern "C" void pns2() { // print native stack
>> +  Command c("pns2");
>> +  static char buf[O_BUFLEN];
>> +  if (os::platform_print_native_stack(tty, NULL, buf, sizeof(buf))) {
>> +    // We have printed the native stack in platform-specific code,
>> +    // so nothing else to do in this case.
>> +  } else {
>> +    Thread* t = Thread::current_or_null();
>> +    frame fr = os::current_frame();
>> +    VMError::print_native_stack(tty, fr, t, buf, sizeof(buf));
>> +  }
>> +}
>> +
>>  #endif // !PRODUCT
>>
>> There is also a pre-existing thread with some discussion:
>>
>>
>> http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2017-November/025134.html
>>
>> thanks,
>>
>> Chris
>>
>>
>
>
Reply | Threaded
Open this post in threaded view
|

Re: RFR(S): 8191049: Add alternate version of pns() that is callable from within hotspot source

Thomas Stüfe-2
Oh, you are right, I should have seen this. Knowing this, forget my worries
about stability. Sorry for the noise :)

..Thomas

On Fri, Nov 10, 2017 at 11:47 PM, Chris Plummer <[hidden email]>
wrote:

> It's already restricted to non-product builds, but I'll add a comment also.
>
> thanks,
>
> Chris
>
>
> On 11/10/17 1:27 PM, Thomas Stüfe wrote:
>
> Hi Chris,
>
> Thank you. Yes, a comment may make sense, and/or restricting this function
> to not product. Otherwise the change is fine and useful, I’ll use it
> probably before long.
>
> Thanks, Thomas
>
> On Fri 10. Nov 2017 at 21:55, Chris Plummer <[hidden email]>
> wrote:
>
>> Hi Thomas,
>>
>> There's certainly no intent to leave in place any calls someone might add
>> to pns2(). It's meant as a temporary debugging aide only. So if it were to
>> fail for any reason, IMO that's no different than adding any other sort of
>> temporary debugging code that could possibly crash. You fix your mistake
>> and resume your debugging. If you want I can add comments that include such
>> a warning.
>>
>> thanks,
>>
>> Chris
>>
>>
>>
>> On 11/10/17 12:11 AM, Thomas Stüfe wrote:
>>
>> Hi Chris,
>>
>> looks fine as a debugging aid.
>>
>> But it occurred to me that it may be a bit dangerous to call this from
>> non-errorhandler settings. I recall seeing quite a few secondary crashes in
>> VMError::print_native_stack() in hs-err files over time. Especially for
>> native non-java threads. Usually this did not matter that much because
>> these crashes are handled by secondary error handling when printing the
>> hs-err file. But if we call it outside of error handling, we are on our own.
>>
>> So. IMHO, to use this functions as a debugging aid is fine, if one can
>> accept a slight risk of crashing the VM. If this is not acceptable, may we
>> need some more tests for this function?
>>
>> Kind Regards, Thomas
>>
>>
>>
>> On Thu, Nov 9, 2017 at 9:29 PM, Chris Plummer <[hidden email]>
>> wrote:
>>
>>> Hi,
>>>
>>> Please review the following:
>>>
>>> https://bugs.openjdk.java.net/browse/JDK-8191049
>>>
>>> diff --git a/src/hotspot/share/utilities/debug.cpp
>>> b/src/hotspot/share/utilities/debug.cpp
>>> --- a/src/hotspot/share/utilities/debug.cpp
>>> +++ b/src/hotspot/share/utilities/debug.cpp
>>> @@ -631,6 +631,24 @@
>>>    VMError::print_native_stack(tty, fr, t, buf, sizeof(buf));
>>>  }
>>>
>>> +//
>>> +// This version of pns() will not work when called from the debugger,
>>> but is
>>> +// useful when called from within hotspot code. The advantages over
>>> pns()
>>> +// are not having to pass in any arguments, and it will work on
>>> Windows/x64.
>>> +//
>>> +extern "C" void pns2() { // print native stack
>>> +  Command c("pns2");
>>> +  static char buf[O_BUFLEN];
>>> +  if (os::platform_print_native_stack(tty, NULL, buf, sizeof(buf))) {
>>> +    // We have printed the native stack in platform-specific code,
>>> +    // so nothing else to do in this case.
>>> +  } else {
>>> +    Thread* t = Thread::current_or_null();
>>> +    frame fr = os::current_frame();
>>> +    VMError::print_native_stack(tty, fr, t, buf, sizeof(buf));
>>> +  }
>>> +}
>>> +
>>>  #endif // !PRODUCT
>>>
>>> There is also a pre-existing thread with some discussion:
>>>
>>> http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/
>>> 2017-November/025134.html
>>>
>>> thanks,
>>>
>>> Chris
>>>
>>>
>>
>>
>
Reply | Threaded
Open this post in threaded view
|

Re: RFR(S): 8191049: Add alternate version of pns() that is callable from within hotspot source

Chris Plummer
[Resending. Didn't seem to get posted first time.]

Hi Thomas,

Thanks for the review.

Can I get one more reviewer please?

thanks,

Chris

On 11/10/17 11:35 PM, Thomas Stüfe wrote:

> Oh, you are right, I should have seen this. Knowing this, forget my
> worries about stability. Sorry for the noise :)
>
> ..Thomas
>
> On Fri, Nov 10, 2017 at 11:47 PM, Chris Plummer
> <[hidden email] <mailto:[hidden email]>> wrote:
>
>     It's already restricted to non-product builds, but I'll add a
>     comment also.
>
>     thanks,
>
>     Chris
>
>
>     On 11/10/17 1:27 PM, Thomas Stüfe wrote:
>>     Hi Chris,
>>
>>     Thank you. Yes, a comment may make sense, and/or restricting this
>>     function to not product. Otherwise the change is fine and useful,
>>     I’ll use it probably before long.
>>
>>     Thanks, Thomas
>>
>>     On Fri 10. Nov 2017 at 21:55, Chris Plummer
>>     <[hidden email] <mailto:[hidden email]>> wrote:
>>
>>         Hi Thomas,
>>
>>         There's certainly no intent to leave in place any calls
>>         someone might add to pns2(). It's meant as a temporary
>>         debugging aide only. So if it were to fail for any reason,
>>         IMO that's no different than adding any other sort of
>>         temporary debugging code that could possibly crash. You fix
>>         your mistake and resume your debugging. If you want I can add
>>         comments that include such a warning.
>>
>>         thanks,
>>
>>         Chris
>>
>>
>>
>>         On 11/10/17 12:11 AM, Thomas Stüfe wrote:
>>>         Hi Chris,
>>>
>>>         looks fine as a debugging aid.
>>>
>>>         But it occurred to me that it may be a bit dangerous to call
>>>         this from non-errorhandler settings. I recall seeing quite a
>>>         few secondary crashes in VMError::print_native_stack() in
>>>         hs-err files over time. Especially for native non-java
>>>         threads. Usually this did not matter that much because these
>>>         crashes are handled by secondary error handling when
>>>         printing the hs-err file. But if we call it outside of error
>>>         handling, we are on our own.
>>>
>>>         So. IMHO, to use this functions as a debugging aid is fine,
>>>         if one can accept a slight risk of crashing the VM. If this
>>>         is not acceptable, may we need some more tests for this
>>>         function?
>>>
>>>         Kind Regards, Thomas
>>>
>>>
>>>
>>>         On Thu, Nov 9, 2017 at 9:29 PM, Chris Plummer
>>>         <[hidden email] <mailto:[hidden email]>>
>>>         wrote:
>>>
>>>             Hi,
>>>
>>>             Please review the following:
>>>
>>>             https://bugs.openjdk.java.net/browse/JDK-8191049
>>>             <https://bugs.openjdk.java.net/browse/JDK-8191049>
>>>
>>>             diff --git a/src/hotspot/share/utilities/debug.cpp
>>>             b/src/hotspot/share/utilities/debug.cpp
>>>             --- a/src/hotspot/share/utilities/debug.cpp
>>>             +++ b/src/hotspot/share/utilities/debug.cpp
>>>             @@ -631,6 +631,24 @@
>>>                VMError::print_native_stack(tty, fr, t, buf,
>>>             sizeof(buf));
>>>              }
>>>
>>>             +//
>>>             +// This version of pns() will not work when called from
>>>             the debugger, but is
>>>             +// useful when called from within hotspot code. The
>>>             advantages over pns()
>>>             +// are not having to pass in any arguments, and it will
>>>             work on Windows/x64.
>>>             +//
>>>             +extern "C" void pns2() { // print native stack
>>>             +  Command c("pns2");
>>>             +  static char buf[O_BUFLEN];
>>>             +  if (os::platform_print_native_stack(tty, NULL, buf,
>>>             sizeof(buf))) {
>>>             +    // We have printed the native stack in
>>>             platform-specific code,
>>>             +    // so nothing else to do in this case.
>>>             +  } else {
>>>             +    Thread* t = Thread::current_or_null();
>>>             +    frame fr = os::current_frame();
>>>             + VMError::print_native_stack(tty, fr, t, buf, sizeof(buf));
>>>             +  }
>>>             +}
>>>             +
>>>              #endif // !PRODUCT
>>>
>>>             There is also a pre-existing thread with some discussion:
>>>
>>>             http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2017-November/025134.html
>>>             <http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2017-November/025134.html>
>>>
>>>             thanks,
>>>
>>>             Chris
>>>
>>>
>>
>
>


Reply | Threaded
Open this post in threaded view
|

Re: RFR(S): 8191049: Add alternate version of pns() that is callable from within hotspot source

Gerald Thornbrugh
Hi Chris,

Your changes look good to me.

Jerry

> On Nov 14, 2017, at 1:44 PM, Chris Plummer <[hidden email]> wrote:
>
> [Resending. Didn't seem to get posted first time.]
>
> Hi Thomas,
>
> Thanks for the review.
>
> Can I get one more reviewer please?
>
> thanks,
>
> Chris
>
> On 11/10/17 11:35 PM, Thomas Stüfe wrote:
>> Oh, you are right, I should have seen this. Knowing this, forget my worries about stability. Sorry for the noise :)
>>
>> ..Thomas
>>
>> On Fri, Nov 10, 2017 at 11:47 PM, Chris Plummer <[hidden email] <mailto:[hidden email]>> wrote:
>>
>>    It's already restricted to non-product builds, but I'll add a
>>    comment also.
>>
>>    thanks,
>>
>>    Chris
>>
>>
>>    On 11/10/17 1:27 PM, Thomas Stüfe wrote:
>>>    Hi Chris,
>>>
>>>    Thank you. Yes, a comment may make sense, and/or restricting this
>>>    function to not product. Otherwise the change is fine and useful,
>>>    I’ll use it probably before long.
>>>
>>>    Thanks, Thomas
>>>
>>>    On Fri 10. Nov 2017 at 21:55, Chris Plummer
>>>    <[hidden email] <mailto:[hidden email]>> wrote:
>>>
>>>        Hi Thomas,
>>>
>>>        There's certainly no intent to leave in place any calls
>>>        someone might add to pns2(). It's meant as a temporary
>>>        debugging aide only. So if it were to fail for any reason,
>>>        IMO that's no different than adding any other sort of
>>>        temporary debugging code that could possibly crash. You fix
>>>        your mistake and resume your debugging. If you want I can add
>>>        comments that include such a warning.
>>>
>>>        thanks,
>>>
>>>        Chris
>>>
>>>
>>>
>>>        On 11/10/17 12:11 AM, Thomas Stüfe wrote:
>>>>        Hi Chris,
>>>>
>>>>        looks fine as a debugging aid.
>>>>
>>>>        But it occurred to me that it may be a bit dangerous to call
>>>>        this from non-errorhandler settings. I recall seeing quite a
>>>>        few secondary crashes in VMError::print_native_stack() in
>>>>        hs-err files over time. Especially for native non-java
>>>>        threads. Usually this did not matter that much because these
>>>>        crashes are handled by secondary error handling when
>>>>        printing the hs-err file. But if we call it outside of error
>>>>        handling, we are on our own.
>>>>
>>>>        So. IMHO, to use this functions as a debugging aid is fine,
>>>>        if one can accept a slight risk of crashing the VM. If this
>>>>        is not acceptable, may we need some more tests for this
>>>>        function?
>>>>
>>>>        Kind Regards, Thomas
>>>>
>>>>
>>>>
>>>>        On Thu, Nov 9, 2017 at 9:29 PM, Chris Plummer
>>>>        <[hidden email] <mailto:[hidden email]>>
>>>>        wrote:
>>>>
>>>>            Hi,
>>>>
>>>>            Please review the following:
>>>>
>>>>            https://bugs.openjdk.java.net/browse/JDK-8191049
>>>>            <https://bugs.openjdk.java.net/browse/JDK-8191049>
>>>>
>>>>            diff --git a/src/hotspot/share/utilities/debug.cpp
>>>>            b/src/hotspot/share/utilities/debug.cpp
>>>>            --- a/src/hotspot/share/utilities/debug.cpp
>>>>            +++ b/src/hotspot/share/utilities/debug.cpp
>>>>            @@ -631,6 +631,24 @@
>>>>               VMError::print_native_stack(tty, fr, t, buf,
>>>>            sizeof(buf));
>>>>             }
>>>>
>>>>            +//
>>>>            +// This version of pns() will not work when called from
>>>>            the debugger, but is
>>>>            +// useful when called from within hotspot code. The
>>>>            advantages over pns()
>>>>            +// are not having to pass in any arguments, and it will
>>>>            work on Windows/x64.
>>>>            +//
>>>>            +extern "C" void pns2() { // print native stack
>>>>            +  Command c("pns2");
>>>>            +  static char buf[O_BUFLEN];
>>>>            +  if (os::platform_print_native_stack(tty, NULL, buf,
>>>>            sizeof(buf))) {
>>>>            +    // We have printed the native stack in
>>>>            platform-specific code,
>>>>            +    // so nothing else to do in this case.
>>>>            +  } else {
>>>>            +    Thread* t = Thread::current_or_null();
>>>>            +    frame fr = os::current_frame();
>>>>            + VMError::print_native_stack(tty, fr, t, buf, sizeof(buf));
>>>>            +  }
>>>>            +}
>>>>            +
>>>>             #endif // !PRODUCT
>>>>
>>>>            There is also a pre-existing thread with some discussion:
>>>>
>>>>            http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2017-November/025134.html
>>>>            <http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2017-November/025134.html>
>>>>
>>>>            thanks,
>>>>
>>>>            Chris
>>>>
>>>>
>>>
>>
>>
>
>

Reply | Threaded
Open this post in threaded view
|

Re: RFR(S): 8191049: Add alternate version of pns() that is callable from within hotspot source

Chris Plummer
Thanks Jerry!

On 11/14/17 12:57 PM, Gerald Thornbrugh wrote:

> Hi Chris,
>
> Your changes look good to me.
>
> Jerry
>
>> On Nov 14, 2017, at 1:44 PM, Chris Plummer <[hidden email]> wrote:
>>
>> [Resending. Didn't seem to get posted first time.]
>>
>> Hi Thomas,
>>
>> Thanks for the review.
>>
>> Can I get one more reviewer please?
>>
>> thanks,
>>
>> Chris
>>
>> On 11/10/17 11:35 PM, Thomas Stüfe wrote:
>>> Oh, you are right, I should have seen this. Knowing this, forget my worries about stability. Sorry for the noise :)
>>>
>>> ..Thomas
>>>
>>> On Fri, Nov 10, 2017 at 11:47 PM, Chris Plummer <[hidden email] <mailto:[hidden email]>> wrote:
>>>
>>>     It's already restricted to non-product builds, but I'll add a
>>>     comment also.
>>>
>>>     thanks,
>>>
>>>     Chris
>>>
>>>
>>>     On 11/10/17 1:27 PM, Thomas Stüfe wrote:
>>>>     Hi Chris,
>>>>
>>>>     Thank you. Yes, a comment may make sense, and/or restricting this
>>>>     function to not product. Otherwise the change is fine and useful,
>>>>     I’ll use it probably before long.
>>>>
>>>>     Thanks, Thomas
>>>>
>>>>     On Fri 10. Nov 2017 at 21:55, Chris Plummer
>>>>     <[hidden email] <mailto:[hidden email]>> wrote:
>>>>
>>>>         Hi Thomas,
>>>>
>>>>         There's certainly no intent to leave in place any calls
>>>>         someone might add to pns2(). It's meant as a temporary
>>>>         debugging aide only. So if it were to fail for any reason,
>>>>         IMO that's no different than adding any other sort of
>>>>         temporary debugging code that could possibly crash. You fix
>>>>         your mistake and resume your debugging. If you want I can add
>>>>         comments that include such a warning.
>>>>
>>>>         thanks,
>>>>
>>>>         Chris
>>>>
>>>>
>>>>
>>>>         On 11/10/17 12:11 AM, Thomas Stüfe wrote:
>>>>>         Hi Chris,
>>>>>
>>>>>         looks fine as a debugging aid.
>>>>>
>>>>>         But it occurred to me that it may be a bit dangerous to call
>>>>>         this from non-errorhandler settings. I recall seeing quite a
>>>>>         few secondary crashes in VMError::print_native_stack() in
>>>>>         hs-err files over time. Especially for native non-java
>>>>>         threads. Usually this did not matter that much because these
>>>>>         crashes are handled by secondary error handling when
>>>>>         printing the hs-err file. But if we call it outside of error
>>>>>         handling, we are on our own.
>>>>>
>>>>>         So. IMHO, to use this functions as a debugging aid is fine,
>>>>>         if one can accept a slight risk of crashing the VM. If this
>>>>>         is not acceptable, may we need some more tests for this
>>>>>         function?
>>>>>
>>>>>         Kind Regards, Thomas
>>>>>
>>>>>
>>>>>
>>>>>         On Thu, Nov 9, 2017 at 9:29 PM, Chris Plummer
>>>>>         <[hidden email] <mailto:[hidden email]>>
>>>>>         wrote:
>>>>>
>>>>>             Hi,
>>>>>
>>>>>             Please review the following:
>>>>>
>>>>>             https://bugs.openjdk.java.net/browse/JDK-8191049
>>>>>             <https://bugs.openjdk.java.net/browse/JDK-8191049>
>>>>>
>>>>>             diff --git a/src/hotspot/share/utilities/debug.cpp
>>>>>             b/src/hotspot/share/utilities/debug.cpp
>>>>>             --- a/src/hotspot/share/utilities/debug.cpp
>>>>>             +++ b/src/hotspot/share/utilities/debug.cpp
>>>>>             @@ -631,6 +631,24 @@
>>>>>                VMError::print_native_stack(tty, fr, t, buf,
>>>>>             sizeof(buf));
>>>>>              }
>>>>>
>>>>>             +//
>>>>>             +// This version of pns() will not work when called from
>>>>>             the debugger, but is
>>>>>             +// useful when called from within hotspot code. The
>>>>>             advantages over pns()
>>>>>             +// are not having to pass in any arguments, and it will
>>>>>             work on Windows/x64.
>>>>>             +//
>>>>>             +extern "C" void pns2() { // print native stack
>>>>>             +  Command c("pns2");
>>>>>             +  static char buf[O_BUFLEN];
>>>>>             +  if (os::platform_print_native_stack(tty, NULL, buf,
>>>>>             sizeof(buf))) {
>>>>>             +    // We have printed the native stack in
>>>>>             platform-specific code,
>>>>>             +    // so nothing else to do in this case.
>>>>>             +  } else {
>>>>>             +    Thread* t = Thread::current_or_null();
>>>>>             +    frame fr = os::current_frame();
>>>>>             + VMError::print_native_stack(tty, fr, t, buf, sizeof(buf));
>>>>>             +  }
>>>>>             +}
>>>>>             +
>>>>>              #endif // !PRODUCT
>>>>>
>>>>>             There is also a pre-existing thread with some discussion:
>>>>>
>>>>>             http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2017-November/025134.html
>>>>>             <http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2017-November/025134.html>
>>>>>
>>>>>             thanks,
>>>>>
>>>>>             Chris
>>>>>
>>>>>
>>>
>>