Questions on new Debugger API

Christian Humer christian.humer at
Wed Sep 7 12:17:37 UTC 2016

Hi Stefan,

I don't see what breakpoint extensibility gets you.  Could you 
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 

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.



- Christian Humer

On 06.09.2016 23:45:49, "Stefan Marr" <java at> wrote:

>Hi Christian:
>>  On 06 Sep 2016, at 20:23, Christian Humer <christian.humer at> 
>>>  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 
>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 
>Oh well…
>Stefan Marr
>Johannes Kepler Universität Linz

More information about the graal-dev mailing list