1

When you have a BreakpointEvent or StepEvent in JDI (Java Debug Interface), what happens is that the currently executing program(debugee) is suspended until the debugger processes the breakpoint event and resumes the debugee. But if you have many breakpoints this becomes slow, even if the debugger resumes the debugee immediately each time it receives a breakpoint event (communication between debugger and debugee is over sockets or shared memory which is not instant).

But if you'd like to build a tool where you just need the events' information to store them and process them later (e.g. when building a profiler etc.) how can you set these breakpoints not to suspend the program? Or in other words, how can stack traces and variable information be extracted from the running program in an asynchronous way?

Nfff3
  • 321
  • 8
  • 24
  • 1
    Inject the desired action instead of setting breakpoints. – Holger May 05 '20 at 07:43
  • @Holger do you mean, by using bytecode instrumentation? – Nfff3 May 05 '20 at 17:40
  • 1
    I'm not @Holger but that Is what I assume they meant, and what I would suggest as well. – PiRocks May 05 '20 at 18:14
  • 2
    Yes, Instrumentation. That’s how existing profilers (those without access to proprietary interfaces) work. – Holger May 06 '20 at 08:17
  • @Holger also what do you think about JVTMI? JDI is build on top of it, but I've heard that it has serious overhead. Does Bytecode Instrumentation cause less overhead? – Nfff3 May 06 '20 at 08:30
  • 1
    It depends on how often you change the code. Normally, you inject your action once and then, the resulting code runs regardless of how it was created, i.e. without any performance drawbacks. – Holger May 06 '20 at 08:39

0 Answers0