harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gregory Shimansky <gshiman...@gmail.com>
Subject [drlvm] [jvmti] Implementation of SingleStep event through TRAP breakpoints
Date Mon, 04 Sep 2006 21:21:07 GMT

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 

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.


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

View raw message