Re: Hotspot JVM GDBJIT plugin

[Kaushik Srenevasan <kaushik at twitter dot com>]

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