Multilingual Debugging Support for Data-driven Parallel Languages Parthasarathy Ramachandran Laxmikant Kale Parallel Programming Laboratory Dept. of Computer Science University of Illinois at Urbana Champaign

Data driven execution: motivation Latency –openMP: remote access –MPI: a blocking receive Response delay: remote processor may be busy Latency Tolerance: –Basic idea: have multiple items on your agenda –Overlap “wait for data” with useful computation

Data driven systems Data flow machines Functional and Logic languages (1983-) –Rediflow (Keller/Lindstrom),.. –Prolog: Conery, Kale,.. Actors Charm/Chare Kernel: 1987 –first implementation on parallel machines Multipol, Cid, Chant, Tulip,..

What is data driven execution Multiple entities per processor –Objects, threads, handlers, … Scheduled based on availability of data

Data driven execution Scheduler Message Q

Data driven execution Existence of scheduler : DDE pre-requisite Implicit control transfer –e.g. when a thread blocks for a recv, control transfers to a module of system’s choice

Data driven execution Advantages: –Adaptive overlap of useful computation with idle time –Multiple modules: efficiency and modularity overlap idle time in one module with useful computation from another MPI/PVM modules can’t do this (as well), without sacrificing modularity

Debugging problem Implicit control transfer leads to debugging difficulties –Unpredictable “jumps” –Need to observe scheduler’s queue –Need to use scheduling quanta I.e. step to the next event Here: –A general purpose framework for debugging data-driven programs

Converse Many data-driven languages/paradigms –Which one is “right”? –Acceptance barriers –Coexistence with monsters (MPI/openMP) Our solution: interoperability –Not the same as C++/Fortran interoperabilty –Ability to integrate modules written in different paradigms in a single program –E.g. MPI, Charm++, Chant

Converse Supports multi-paradigm programming Provides portability Makes it easy to implement RTS for new paradigms Several languages/libraries: –Charm++, Java, threaded MPI, PVM, md-perl, pc++, Nexus, Path, Tempo, Cid, CC++,.. –More info:

Example application:

Debugging Multi-paradigm Multi-lingual Programs New problems: –Scheduler entities belong to different languages –Need ability to set language specific breakpoints Also: –Integration with “normal” debugging methods Source level debugging: e.g. gdb –Need to freeze execution properly

Inadequacy of current methods Can we use gdb? (for example) –Scheduler code inaccessible –Cannot focus on specific breakpoints If we set a breakpoint in the scheduler –Scheduler entities belong to different languages How to view them uniformly? Need support for language implementors

Converse debugging framework Freeze and Thaw: –External intervention –Freeze schedulers (on one or all processors) –Ensure bookkeeping tasks continue –Scheduler processes debugging commands only Scheduler level language-specific breakpoints Language-specific viewing –of scheduler entries (e.g. method invocation, msg) –of resident entities (e.g. objects, threads)

Architecture Uses converse’ client-server interface –Can inject messages into running programs –Can send responses via TCP sockets –Used for other purposes as well: E.g. Web based submission/monitoring

Architecture Debugger client: –Java based, GUI/communication Debugger runtime library –A module in Converse runtime –Provides hooks for languages/libraries GDB interface –Integrates source level debugging –Can customize for other debuggers

Viewing multilingual entities Scheduler’s view: –Each entry –The header contains a handler index –Handlers are registered by languages Language runtimes register callback functions showHeader: returns a short string showContent: returns a long string with newLines –On “freeze” scheduler sends list of headers –On demand, sends the result of showContent headergibberish

Non scheduler entities Objects and other data structures –Not in the scheduler’s queue –But still important to view –Same problem: multiple languages Solution –Each language registers each of its objects –For C++ object, use virtual inheritance –For others, registered callbacks

Breakpoints Are language specific –Charm++: list of remotely invokable methods –Multipol: handler function names, Chant: Code Each language supplies –A list of breakpoints (names and indices) –RTS maintains list of set breakpoints –note: a handler may represent multiple breakpoints –Given a scheduler entry, language RTS identifies breakpoint number

Optimizations Data transfer between the runtime and client –Chunking: send only a viewable screenful of information at a time –Caching: use idle time while user inspects data to collect and prepare information

Summary Debugger is in operational use on –Workstation clusters –Parallel machines (Origin 2000, T3E) Complements source level debuggers Provides a useful functionality for all data- driven languages/libraries If you use Converse for your RTS, you will get this functionality for free…