Questions on new Debugger API

[Christian Humer]

Hi Stefan,

Thanks for your questions.
Please find my answers inline.


On 05.09.2016 20:03:54, "Stefan Marr" <java at stefan-marr.de> wrote:

>Hi:
>
>I started to look at the new Debugger API introduced in Truffle 0.17.
>
>I am a little unsure about how it is intended to be used.
>
>Should I request a DebuggerSession as late or as early as possible?
Create creating an empty DebuggerSession without breakpoints and no 
suspensions will not cause any peak performance degradation. It will 
however create wrappers for statements that were executed once. This 
means that having a debugger session open will cause overhead in memory 
consumption and first-execution/interpreter performance. If there is a 
chance that the session will not be used, then I would open it as late 
as possible. If you are going to need it anyway, then I would open it as 
early as possible.


>
>
>The JavaDoc mentions that it is possible to have multiple sessions, 
>which I assume, I can use to handle different entities 
>actors/threads/what-ever separately from each other.
It might not make much sense to have multiple interactive debugging 
sessions, but the debugging framework is not limited to interactive 
debugging. Also automated tools that use the debugging framework can 
coexist with an interactive debugger. That's what sessions were designed 
for. Also since the Debugger is a singleton for a PolyglotEngine, we 
isolate users from each other using sessions.

>
>Let’s assume an actor-based language, and that I got a debugger, which 
>allows me to set line breakpoints (without any qualification/scoping). 
>The intended breakpoint behavior here is that all actors executing that 
>line are supposed to stop.
>To realize that, should I have one global session on which I register 
>the breakpoint?
Yes.


>
>I am not really sure how the debugger sessions are mapped to execution 
>entities either. So, how do I ’scope’ a session?
>Or should I create a session for each actor, probably when I 
>instantiate the actor?
You should use only one session, but register multiple breakpoints with 
different conditions that scope your breakpoint. You can use 
SuspendedEvent#getBreakpoints() to find out which breakpoints were 
actually hit.

>
>And then the next step would be to have breakpoints local to an actor. 
>For guess, I’d need to create a separate session, and then set the 
>breakpoint there. However, I still haven’t seen how I could make sure 
>the mapping between execution and actor could be done, especially since 
>a single actor can over time be scheduled on different threads (in a 
>pool).
Would multiple breakpoints and SuspendedEvent#getBreakpoints() help 
here?


-- Christian Humer