harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Pavel Rebriy" <pavel.reb...@gmail.com>
Subject Re: [drlvm] [jvmti] Implementation of SingleStep event through TRAP breakpoints
Date Wed, 13 Sep 2006 05:34:12 GMT
I'm starting the implementation of Single Step event for JIT mode.
The initial draft is filed in H-1422 [1]. The implemented function
jvmti_SingleStepLocation predicts the next execution bytecode which can be
used from Single Step event.

[1]
http://issues.apache.org/jira/browse/HARMONY-1422

On 07/09/06, Gregory Shimansky <gshimansky@gmail.com> wrote:
>
> On Thursday 07 September 2006 00:55 Weldon Washburn wrote:
> > Gregory,
> >
> > The below seems like a reasonable place to start.  Some observations.
> > Regular native code debuggers also like to use int 3.  Do you plan to
> > somehow chain onto int 3 exception handler so that regular native code
> > debugger also works while java debugger is in use?
>
> Debugging the debugger is never an easy task and it won't be easy I think.
> On
> windows (XP) using VEH handler chains it is already implemented in
> HARMONY-1363 that breakpoits which are not handled by JVMTI should be
> handled
> by the other handler in chain. On Linux when SIGTRAP is caught and the
> address is not known by JVMTI I think it should crash just like for other
> unknown signal/locations values.
>
> But when the program is ran under debugger, be it VS.NET Studio or gdb, of
> course int3 is caught by the debugger first. When executing the program
> under
> VS.NET and int3 is encountered stepping over it doesn't result in
> exception
> which has to th trigger a breakpoint. When executing the program on linux
> gdb
> allows SIGTRAP to be caught by the program after it catches it first.
>
> I think mixing debugging VM and debugger is very subtle if possible at
> all. I
> don't think it is possible to make it easier.
>
> > The threading model is
> > somewhat vague.  For example, when thread A hits a breakpoint, the
> > remaining threads could be forced to suspend at a GC safepoint by the
> VM.
> > This would allow the java debugger to swich thread context and
> read/wriite
> > local variables (a very handy feature).  Allowing other Java threads to
> > continue executing once a breakpoint has been hit can cause all sorts of
> > hard to reason about problems.
>
> The interaction between thread stopped on breakpoint and other if done
> through
> standard thread manager capabilities. It is up to the user and the JVMTI
> agent to allow or not the other threads to run when some thread is stopped
> on
> breakpoint. I think that debugging scenarios usually stop all of the
> threads.
> Profiling will probably not, but they won't access the variables also.
>
> >
> > On 9/4/06, Gregory Shimansky <gshimansky@gmail.com> wrote:
> > > Hello
> > >
> > > Now that DRLVM has some basic implementation of breakpoints in JIT
> mode
> > > as HARMONY-1363 has been created I've decided the same mechanism may
> be
> > > used for
> > > implementation of SingleStep JVMTI event [1].
> > >
> > > I've thought of some draft design for SingleStep implementation using
> > > just int3 breakpoints which are already written in HARMONY-1363. It
> seems
> > > to be enough to satisfy JVMTI spec requirements.
> > >
> > > The way how I think SingleStep could be implemented is setting a new
> > > breakpoint on every new bytecode in compiled code. The breakpoint
> handler
> > > would remove SingleStep breakpoints instrumentation from compiled code
> > > and set new ones for the next executable location.
> > >
> > > The tricky parts is to find the next executable location have the
> > > following
> > > points
> > >
> > > 1. Turning SingleStep event state on. When this state is turned on all
> > > threads
> > > should be switched into SingleStep mode. All of them have to have the
> > > next after currently executed bytecode marked with SingleStep type
> > > breakpoint. 2. New threads when started and SingleStep state is on
> have
> > > to mark the first
> > > bytecode marked with SingleStep breakpoint.
> > > 3. Any native to Java transition have to mark first executable
> bytecode
> > > of the
> > > method with SingleStep type breakpoint.
> > > 4. When exception occurs the SingleStep breakpoints have to be removed
> > > from
> > > the places of the next executable location and set to exception
> handler
> > > starting address instead.
> > > 5. Breakpoints handler which would handle SingleStep type breakpoints
> as
> > > well
> > > has to distinguish agent set Breakpoints and synthetic SingleStep
> ones.
> > > 6. When SingleStep state is turned off all breakpoints for the next
> > > bytecode
> > > in all threads have to be deleted.
> > >
> > > The implementation would require "next bytecode predictor" which would
> > > allow
> > > the handler of breakpoints to set them on the next bytecode to be
> > > executed.
> > > For conditional situations it is easiest to have a set of possibly
> > > executable
> > > locations, or otherwise it would require parsing current Java stack
> > > state. The breakpoints predicted for the next bytecode should
> certainly
> > > be kept in
> > > TLS for every thread.
> > >
> > > There is going to be some subtle logic for distinguishing plain
> > > breakpoints
> > > and synthetic SingleStep ones and turning SingleStep on/off while in
> > > SingleStep and/or Breakpoint callback.
> > >
> > > So in places like #4, #5 and #6 "predicted" breakpoints would have to
> be
> > > added
> > > and removed in sets potentially with more than one target address.
> > >
> > > At the moment I don't see any flaws in this simple design and I'm
> going
> > > to start working on its implementation. Let me know what you think
> about
> > > it. Surely it is a subject for improvement.
> > >
> > > I am mostly keeping the whole idea in my head and never tried to write
> it
> > > down
> > > completely, I may miss describing some nuances since I may think of
> them
> > > as
> > > obvious so feel free to ask me.
> > >
> > > [1]
> > > http://java.sun.com/j2se/1.5.0/docs/guide/jvmti/jvmti.html#SingleStep
> > >
> > > --
> > > Gregory Shimansky, Intel Middleware Products Division
> > >
> > > ---------------------------------------------------------------------
> > > Terms of use : http://incubator.apache.org/harmony/mailing.html
> > > To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
> > > For additional commands, e-mail: harmony-dev-help@incubator.apache.org
>
> --
> Gregory Shimansky, Intel Middleware Products Division
>
> ---------------------------------------------------------------------
> Terms of use : http://incubator.apache.org/harmony/mailing.html
> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
>
>
-- 
Best regards,
Pavel Rebriy

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message