[E-Lang] Control Flow Debugging (was: E questions)

[Mark S. Miller]

At 08:03 AM Wednesday 7/18/01, Mark Seaborn wrote:

>"Mark S. Miller" <markm@caplet.com> writes:
>
>> Of course, I can only do data-level debugging of A.  Unlike KeyKOS,
>> I can't do control flow debugging for the reasons previously
>> explained.
>
>Which were:
>
>> I ended up in the current (unpleasant but tenable) position by realizing 
>> that, in order to preserve E's concurrency control guarantees (the executing 
>> turn/even has mutually exclusive access to everything it has synchronous 
>> access to -- all of which are therefore in this vat), a conventional 
>> control-flow debugger would have to seize control of the vat as a whole.  
>> Why?  Because while the current computation is suspended, eg, at a 
>> breakpoint, nothing else may proceed in that vat.  Therefore the debugger, 
>> and the person operating the debugger, are all parts of that vat's TCB.
>
>Surely A can already suspend the vat by looping indefinitely?  If the
>person debugging A also wrote A, there is not much to be gained by
>preventing them from halting them the vat if they could have done that
>anyway.

That is a good and disturbing point.  It would be too disturbing if they 
only had to be the one who wrote A (or, rather, holds A's Brand). However, 
given that they both have to hold A's Brand and hold A, perhaps this insight 
does point at the right way to go.  But it is disturbing -- it makes very 
stark how fully vulnerable a single vat is to denial of service by any of 
the objects it hosts.  (This is probably another argument for your 
suggestion.  Unpleasant truths should be made stark.)

The control flow debugging you get to by such reasoning would then be more 
like KeyKOS's (and presumably EROS's?) POLA-respecting control flow 
debugging (which is another argument in favor of this direction).  You 
wouldn't have a conventional debugger's eye view of the vat as a whole or 
even the stack. Rather, just as we'd use Brand-based (or can-opener-based) 
opening to open and manipulate  individual objects on the heap, we would do 
likewise to open and manipulate individual stack frames.

I believe the rule should be that a stack frame "belongs" to the object 
receiving the message that this stack frame is a reaction to.  Given a 
continuation to a stack frame and an opener to the object to which it 
"belongs", you should be able to open the stack frame itself.  This is 
mostly consistent both with the KeyKOS/EROS view, which bundles the 
"activation frame" notion, by default, with the receiving object (ie, 
domain), and with the notation on 
http://www.erights.org/elib/concurrency/msg-passing.html which shows a stack 
frame as a lightning bolt *within* the object.  This view is natural since 
the stack frame has access to its object's internal state.

In E terminology, a KeyKOS/EROS "domain" is an object when it's "ready" (or 
"available"?  I forget the terminology).  A "domain" is an object + a stack 
frame when it's "running" or "waiting".  In any state, the "start key" 
designates the domain as object.  When it's waiting, the "resume key" is a 
dynamic extent continuation that designates the domain as stack frame.

So the difference between the above possible view of E debugging and the 
KeyKOS/EROS notion is that access to the object does not give you access to 
its stack frame[s], though in both, access to a stack frame does give you 
access to the object.

What is a "breakpoint" in such a view?  Presumably, it would be something 
like the Keeper-based means of entering a debugger in KeyKOS/EROS.  Unclear.

Even if we did this, I'm still inclined to also provide a conventional 
IDE-style debugger that provides privileged access to the state of an entire 
vat.  I think both are useful, and, by compiling to JVM class files in the 
way I expect, we should be able to provide a conventional debugger 
essentially for free by hijacking stock Java debuggers.  (The debugging info 
defined by the JVM class file format looks fine for representing all the 
debugging info needed for source-level debugging of E.)  We would therefore 
probably be able to provide a quality conventional debugger much earlier 
than we could provide a KeyKOS/EROS-style control flow debugger.  Though 
when we do a multi-vat distributed debugger, we're probably much better off 
building on the latter.

Thanks for an excellent, counter-intuitive, and productive observation!


        Cheers,
        --MarkM