Questions on new Debugger API

[Christian Humer]

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.
I agree we probably need Java breakpoint conditions (if that is what you 
mean).

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.

[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/
>
>
>