Hotspot JVM GDBJIT plugin

Hotspot JVM GDBJIT plugin

[Kaushik Srenevasan]

I've been working on a Hotspot JVM JIT plugin for GDB and noticed that
there was some interest about this earlier [1]. I currently have mixed
mode stack traces working [2] and plan to at least add file and
line number support in the future.

I'm writing to see if there is any interest in pulling the
changes [3] I've had to make to GDB, to get this to work. I also
intend to ping the OpenJDK folks to try to get the GDBJIT hooks into
the official distribution.

The first of these changes [3] is a simple fix to a crash while trying to
display the return type of a JIT frame (say on 'finish'.)

The second (frame based symbol handler) is a feature added to help GDB
understand frames created by Hotspot's "template" interpreter. Hotspot
generates expansions for bytecodes from templates (once) into a buffer
and uses jump tables to handle dispatch. The same code range thus
corresponds to different functions, with the only differentiating
factor being metadata in stack frames. Neither ELF symbol tables nor
callbacks work in this case and hence the need for frame based symbol
resolution.

This adds an additional callback that the reader may choose to
implement to return the name (file path or line number) of the function
executing in the frame in question. GDB's stack walk code consults this
handler if it can't find a symbol in its global symbol table. The JIT
host inserts itself as a handler and simply forwards the call to the
reader. Symbols are only ever created lazily; when the unwinder finds
the frame on the stack. I also want to add support to display
inlined frames which I can't imagine being realized without frame
based handlers. [3] is only a rough implementation that I intend to
complete based on feedback I get from this list.

Thanks,
   -Kaushik

[1] http://sources.redhat.com/ml/gdb/2012-02/msg00025.html
[2] http://sysenter.org/~ks/gdb/gdb-jvm.png
[3] https://github.com/kaushiks/GDB/commit/98d8b224c3f48639368e91f0a531394124596a2e

Re: Hotspot JVM GDBJIT plugin

[Tom Tromey]

>>>>> "Kaushik" == Kaushik Srenevasan <kaushik@twitter.com> writes:

Kaushik> I've been working on a Hotspot JVM JIT plugin for GDB

Very cool.

Kaushik> I'm writing to see if there is any interest in pulling the
Kaushik> changes [3] I've had to make to GDB, to get this to work.

Sure.  Just send individual patches following the contribution
instructions...

Kaushik> The first of these changes [3] is a simple fix to a crash while
Kaushik> trying to display the return type of a JIT frame (say on
Kaushik> 'finish'.)

Sounds good.

Kaushik> The second (frame based symbol handler) is a feature added to
Kaushik> help GDB understand frames created by Hotspot's "template"
Kaushik> interpreter.

Kaushik> This adds an additional callback that the reader may choose to
Kaushik> implement to return the name (file path or line number) of the
Kaushik> function executing in the frame in question.

Phil has been working on a related feature in gdb, called "frame
filters".  Frame filters let you write Python code to modify frames as
they are being displayed; you can change nearly any aspect of a frame,
and even insert and delete frames.  The primary use case for this
feature is displaying better stack traces in interpreters.

So, you might consider just waiting for this and writing your frame
logic in Python.

If you'd rather press on, that is fine too.

Tom

Re: Hotspot JVM GDBJIT plugin

[Kaushik Srenevasan]

On Fri, May 25, 2012 at 7:36 AM, Tom Tromey <tromey@redhat.com> wrote:
> Sure.  Just send individual patches following the contribution
> instructions...
>
Will do.

> Phil has been working on a related feature in gdb, called "frame
> filters".  Frame filters let you write Python code to modify frames as
> they are being displayed; you can change nearly any aspect of a frame,
> and even insert and delete frames.  The primary use case for this
> feature is displaying better stack traces in interpreters.
>
This was exactly what I was looking for when I started and since Python scripts
couldn't do it at the time, I wrote a JIT reader. I have a few questions though:

With frame filters, would JIT readers still be necessary to unwind the
frame or is
that done from Python too?
If they're not, are JIT readers going to be supported going forward?
When is this expected to hit trunk?

   -Kaushik

Re: Hotspot JVM GDBJIT plugin

[Tom Tromey]

>>>>> "Kaushik" == Kaushik Srenevasan <kaushik@twitter.com> writes:

Kaushik> With frame filters, would JIT readers still be necessary to
Kaushik> unwind the frame or is that done from Python too?

You would still need a JIT reader to do the unwinding.

The Python feature is really just about massaging the display of frames
already found by gdb.  At least in the first revision there won't be a
way to hook into the unwinding process.  We haven't even really
discussed letting people write unwinders in Python; I guess it could be
done.

Kaushik> If they're not, are JIT readers going to be supported going forward?

Yes, they will be.

Kaushik> When is this expected to hit trunk?

Phil?

Tom

Re: Hotspot JVM GDBJIT plugin

[Phil Muldoon]

On 05/25/2012 10:03 PM, Tom Tromey wrote:
>>>>>> "Kaushik" == Kaushik Srenevasan <kaushik@twitter.com> writes:
> 
> Kaushik> With frame filters, would JIT readers still be necessary to
> Kaushik> unwind the frame or is that done from Python too?
> 
> You would still need a JIT reader to do the unwinding.
> 
> The Python feature is really just about massaging the display of frames
> already found by gdb.  At least in the first revision there won't be a
> way to hook into the unwinding process.  We haven't even really
> discussed letting people write unwinders in Python; I guess it could be
> done.
> 
> Kaushik> If they're not, are JIT readers going to be supported going forward?
> 
> Yes, they will be.
> 
> Kaushik> When is this expected to hit trunk?
> 
> Phil?

The field substitution stuff is all there, I am currently working on
the "elide" API which allows you to merge frames.  As for trunk, I
intend to submit it for review at the end of next week if I can.  Then
it is a matter of the usual review process after that.

Cheers,

Phil

Re: Hotspot JVM GDBJIT plugin

[Kaushik Srenevasan]

On Wed, May 30, 2012 at 11:13 AM, Phil Muldoon <pmuldoon@redhat.com> wrote:
>>
>> The Python feature is really just about massaging the display of frames
>> already found by gdb.  At least in the first revision there won't be a
>> way to hook into the unwinding process.  We haven't even really
>> discussed letting people write unwinders in Python; I guess it could be
>> done.
>>
>
> The field substitution stuff is all there, I am currently working on
> the "elide" API which allows you to merge frames.  As for trunk, I
> intend to submit it for review at the end of next week if I can.  Then
> it is a matter of the usual review process after that.
>

Tom, Phil,
Thanks for the update. While it does seem like there is overlap, I
believe it'd be easier to implement both unwinding and symbol
resolution for frames in the same plugin - which could be the reader
or a python script. So, I'll go ahead and submit the frame based
symbol handler code I have for review.

   -Kaushik

Re: Hotspot JVM GDBJIT plugin

[Daniel Jacobowitz]

On Thu, May 24, 2012 at 7:03 AM, Kaushik Srenevasan <kaushik@twitter.com> wrote:
> I've been working on a Hotspot JVM JIT plugin for GDB and noticed that
> there was some interest about this earlier [1]. I currently have mixed
> mode stack traces working [2] and plan to at least add file and
> line number support in the future.

Awesome!  Thanks again for working on this.

> The first of these changes [3] is a simple fix to a crash while trying to
> display the return type of a JIT frame (say on 'finish'.)

Does 'finish' reliably work?  It seems like we'd have to get pretty
lucky (in general) with the VM's implementation of stack frames.  e.g.
if JIT compilation triggered during an interpreted function, I wonder
if it would still return to the same place.

> The second (frame based symbol handler) is a feature added to help GDB
> understand frames created by Hotspot's "template" interpreter. Hotspot
> generates expansions for bytecodes from templates (once) into a buffer
> and uses jump tables to handle dispatch. The same code range thus
> corresponds to different functions, with the only differentiating
> factor being metadata in stack frames. Neither ELF symbol tables nor
> callbacks work in this case and hence the need for frame based symbol
> resolution.
>
> This adds an additional callback that the reader may choose to
> implement to return the name (file path or line number) of the function
> executing in the frame in question. GDB's stack walk code consults this
> handler if it can't find a symbol in its global symbol table.

It would be nice if this code could be shared with the existing inline
frame support, which returns an alternative symbol based on the frame
id.

-- 
Thanks,
Daniel

Re: Hotspot JVM GDBJIT plugin

[Kaushik Srenevasan]

Daniel Jacobowitz <drow@false.org> writes:
> Does 'finish' reliably work?  It seems like we'd have to get pretty
> lucky (in general) with the VM's implementation of stack frames.  e.g.
> if JIT compilation triggered during an interpreted function, I wonder
> if it would still return to the same place.
>

You are right. I'd imagine it might not, in the case of
on-stack-replacement; depending on how GDB implements finish. Non-OSR
compilation replaces the entry point allowing newer invocations to use
compiled code. Code already executing in an active frame is stable.

>
> It would be nice if this code could be shared with the existing inline
> frame support, which returns an alternative symbol based on the frame
> id.

I agree. I didn't realize that simply returning different frame ids is
all that is required, at the time. However, I'd like to see 'JIT
symbols' be more 'dynamic' than what the current JIT reader model
allows. Hotspot needs to be able to return different symbols for the
same (template interpreter) code range, replace symbols if it has been
configured to reclaim code once the code cache fills up. That's why it
might be better to let the reader participate in symbol resolution
rather than having it communicate with GDB using statically generated
data. I'd imagined this to be in the form of frame based symbol
handlers, but I like frame filters the more I think about it (which is
also why I want to play with it first, before I submit my changes.)

   -Kaushik

Re: Hotspot JVM GDBJIT plugin

[Tom Tromey]

>>>>> "Kaushik" == Kaushik Srenevasan <kaushik@twitter.com> writes:

Kaushik> I've been working on a Hotspot JVM JIT plugin for GDB and noticed that
Kaushik> there was some interest about this earlier [1]. I currently have mixed
Kaushik> mode stack traces working [2] and plan to at least add file and
Kaushik> line number support in the future.

Kaushik> I'm writing to see if there is any interest in pulling the
Kaushik> changes [3] I've had to make to GDB, to get this to work. I also
Kaushik> intend to ping the OpenJDK folks to try to get the GDBJIT hooks into
Kaushik> the official distribution.

BTW, let me also recommend trying to push it into IcedTea:

http://icedtea.classpath.org/wiki/Main_Page

I think it would be simpler to get it there, and would give it some
exposure while upstream is looking at it.  My impression, anyway, is
that OpenJDK is pretty slow to accept things...

Tom