PC updates while interpreting bytecode

[Tom Tromey]

>>>>> "Kyle" == Kyle Galloway <kgallowa@redhat.com> writes:

Kyle> I was wondering about updates to the pc while interpreting bytecodes.
Kyle> I  know that the actual pc is a local variable to the particular
Kyle> instance of _Jv_InterpMethod::run (or run_debug), but I was wondering
Kyle> how often frame_desc.pc is updated.

It is updated any time code outside the method may need to know it --
i.e., before we do something that may potentially cause an exception.
Look for uses of the SAVE_PC macro.

The reason we do this lazily is the belief that it saves some cycles
by letting the pc be in a register.  AFAIK nobody has ever actually
looked at this or tried to measure it, though.

Kyle> I have thought of a couple of solutions to this, and I was wondering
Kyle> what opinions there are on this.  The first is to update the pc inside
Kyle> NEXT_INSN in the debug case, though I think this is still less that
Kyle> ideal since there is a race there if the thread is suspended after the
Kyle> local pc has changed but before the frame info pc is updated.

We can suspend a thread at an arbitrary point and then try to make a
stack trace?  I must not have realized that.

If it is just breakpoints, those happen synchronously WRT pc updates,
I think, and that would make this the preferred approach.

Kyle> The
Kyle> second is to pin the PC with a pointer inside the frame structure in
Kyle> the debug case like this:

Yeah, perhaps with gross macro hackery so that it only happens for the
debug interpreter.

Tom