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 <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
-- Weldon Washburn Intel Middleware Products Division
