Questions on new Debugger API

[Stefan Marr]

Hi Christian:

> On 06 Sep 2016, at 20:23, Christian Humer <christian.humer at gmail.com> wrote:
> 
>> 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.

Ok, good to know.


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

Hm, ok, I see, I think, I’ll need to do most of the checking whether a breakpoint applies myself anyway. So, indeed, the benefit of multiple sessions seems minimal for my scenario.

>> 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?

Hm, well, yes, partially.

Since Breakpoint is not extensible, I’ll actually need to manage language-specific breakpoint classes on top of that, which implement the additional semantics. So, yes, getBreakpoints() gives me some of what I need, but, I also need to manage another map to get the language-specific breakpoints.

I can’t say I am a fan of that particular aspect of the design.
Is extensibility really making it so much harder to design for maintainability?

Oh well…

Thanks
Stefan

-- 
Stefan Marr
Johannes Kepler Universität Linz
http://stefan-marr.de/research/