Multilingual Debugging Support for Data-driven Parallel Languages Parthasarathy Ramachandran Laxmikant Kale Parallel Programming Laboratory Dept. of Computer.

Multilingual Debugging Support for Data-driven Parallel Languages

Parthasarathy Ramachandran

Laxmikant KaleParallel 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 Scheduler

Message Q 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: http://charm.cs.uiuc.edu

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

header

gibberish

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…

http://charm.cs.uiuc.edu