harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Weldon Washburn" <weldon...@gmail.com>
Subject Re: [drlvm] [jvmti] Implementation of SingleStep event through TRAP breakpoints
Date Wed, 06 Sep 2006 20:55:40 GMT
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?  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.



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
>
>


-- 
Weldon Washburn
Intel Middleware Products Division

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