[drlvm] [jvmti] Implementation of SingleStep event through TRAP breakpoints

[Gregory Shimansky <gs...@gmail.com>]

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

Re: [drlvm] [jvmti] Implementation of SingleStep event through TRAP breakpoints

[Gregory Shimansky <gs...@gmail.com>]

2006/9/13, Pavel Rebriy <pa...@gmail.com>:
>
> 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
>
>
Hello Pavel. Thanks a lot for your assistance. I like the interface for next
bytecode prediction and started to use it in my SingleStep implementation.
The current state of work looks like it is mostly done so I decided to
publish it in JIRA [1]. I've just made it to compile, so it may contain bugs
:) bug I decided to share the code since it looks like this work interests
other people.

[1] http://issues.apache.org/jira/browse/HARMONY-1455?page=all

-- 
Gregory Shimansky, Intel Middleware Products Division

Re: [drlvm] [jvmti] Implementation of SingleStep event through TRAP breakpoints

[Pavel Rebriy <pa...@gmail.com>]

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 <gs...@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 <gs...@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

Re: [drlvm] [jvmti] Implementation of SingleStep event through TRAP breakpoints

[Gregory Shimansky <gs...@gmail.com>]

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 <gs...@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

Re: [drlvm] [jvmti] Implementation of SingleStep event through TRAP breakpoints

[Weldon Washburn <we...@gmail.com>]

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 <gs...@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