Walk stack in signal handler

Roman Kovalenko rmnkvlnk at gmail.com
Thu Feb 25 09:49:37 UTC 2016


Hi,

This flag is very helpful. But yes, I could not figure out how to access
locals, so I found some more dirty workaround (based on bytecode
instrumentation) to perform my initial task. It looks convenient for now
and maybe I will stick to it.

Thank you for attention.

On Thu, Feb 18, 2016 at 7:33 PM, Volker Simonis <volker.simonis at gmail.com>
wrote:

> You can use -XX:+PrintOptoAssembly. This option will print out an
> abstract assembly for the code it will generate. For every safepoint
> (e.g. function call) it will show you the information the JIT has
> recorded (i.e. which locals are alive and where they are stored). If
> you are not at a safepoint, you can not reliably access a local
> variable.
>
> On Thu, Feb 18, 2016 at 4:53 PM, Roman Kovalenko <rmnkvlnk at gmail.com>
> wrote:
> > Hi,
> >
> > Thank you for the reference. I was already a little familiar with
> > PreserveFramePointer but after reading the related mailing list thread I
> > have better understanding and it will definitely help me in my future
> > researches. The main problem for me for now is that I have poor
> knowledge of
> > where to look for locals of frame that is already found by
> AsyncGetCallTrace
> > and its helpers, because I cannot access locals (or access just 'this'
> which
> > is enough) with calls that are used for same purpose within safepoint
> (e. g.
> > JVMTI GetLocalInstance etc.). I have tried some random workarounds as
> well,
> > but without deeper knowledge they had no success yet. Maybe there was a
> > discussion about the stack state outside safepoint? :) Something like
> that
> > would help me a lot, since I have difficulties to get right direction for
> > source code reading.
> >
> > Thanks.
> >
> > On Wed, Feb 17, 2016 at 7:40 PM, Volker Simonis <
> volker.simonis at gmail.com>
> > wrote:
> >>
> >> Hi Roman,
> >>
> >> you should definitely use -XX:+PreserveFramePointer and you should
> >> also have a look at the discussion on bug "8068945: Use RBP register
> >> as proper frame pointer in JIT compiled code on x86" which discuss
> >> some of the difficulties related to native stack walking in hotspot:
> >>
> >> https://bugs.openjdk.java.net/browse/JDK-8068945
> >>
> >> Regards,
> >> Volker
> >>
> >>
> >> On Wed, Feb 17, 2016 at 6:28 PM, Roman Kovalenko <rmnkvlnk at gmail.com>
> >> wrote:
> >> > Hi,
> >> >
> >> > Looks like that I am able to get 'this' for native frame with
> >> > frame::get_native_receiver() but I cannot do anything with any other
> >> > frame
> >> > type.
> >> > How can I find out what is permitted to be used outside safepoint?
> Also,
> >> > what can happen to frame outside safepoint, because of what is it hard
> >> > to
> >> > walk it? May be I should look in some precise source code locations?
> >> >
> >> > Thanks.
> >> >
> >> > On Fri, Feb 12, 2016 at 11:48 AM, Andrew Haley <aph at redhat.com>
> wrote:
> >> >
> >> >> On 11/02/16 17:54, Roman Kovalenko wrote:
> >> >>
> >> >> > I would like to profile application by interrupting it with signals
> >> >> > and
> >> >> > using AsyncGetCallTrace then. This works well, but also I want to
> >> >> > collect
> >> >> > every 'this' for any object method frame that is walkable by AGCT.
> I
> >> >> looked
> >> >> > around (forte.cpp and related) but had no success.
> >> >> >
> >> >> > Is it even possible?
> >> >>
> >> >> It's difficult.  The compilers move values around and things are
> >> >> really only stable at safepoints.
> >> >>
> >> >>
> >> >
> >> >
> >> > --
> >> > -rmnk-
> >
> >
> >
> >
> > --
> > -rmnk-
>



-- 
-rmnk-


More information about the hotspot-runtime-dev mailing list