Questions on new Debugger API

[Stefan Marr]

Hi Christian:

> On 07 Sep 2016, at 14:17, Christian Humer <christian.humer at gmail.com> wrote:
> 
> Hi Stefan,
> 
> I don't see what breakpoint extensibility gets you.  Could you elaborate?
> If you want to add information to a breakpoint, just wrap it. I don’t see the need for a map.

Hm, well, wrapping is uni-directional, how do I get from the Breakpoint that I get in a suspended event back to a language-level breakpoint object? I would need a map for that, no? I can’t put a pointer to my own breakpoint representation in the Truffle `Breakpoint` object?

> I agree we probably need Java breakpoint conditions (if that is what you mean).

Yeah, I definitely need that. And, I used an interface for that. So, in such condition objects, I am actually also able to maintain a connection to my language-level breakpoint representation.

> Yes, abstract classes are a lot harder to evolve than final classes. You should not mix API and SPI in the same class[1] when designing for longer term support.
> So if we would make breakpoints extensible, we would probably do it with a separate class.

Yeah, well, I perfectly understand your motivation to close things down. That doesn’t mean I need to like it, right? ;) I am just ranting as usual… sorry.

Thanks
Stefan

> 
> [1] http://wiki.apidesign.org/index.php?title=APIvsSPI
> 
> Cheers,
> 
> - Christian Humer
> 
> 
> On 06.09.2016 23:45:49, "Stefan Marr" <java at stefan-marr.de> wrote:
> 
>> 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/
>> 
>> 
>> 
>