Adaptability: viewpoint from INRIA-Rennes and the UNIPI-INRIA joint-work

1. Adaptability:viewpoint from INRIA-Rennesand the UNIPI-INRIA joint-work CoreGrid WP3 Kraków meeting - June 2006 Françoise André & Jérémy Buisson Subtask 3.3 Research group on “Performance models and adaptivity”

2. Outline • Collaborative work UNIPI/INRIA • Leading to a common high-level model • UNIPI’s interpretation: ASSIST • INRIA’s interpretation: Dynaco/AFPAC

3. Dynamic adaptability • Ability of applications to modify themselves at runtime in order to adapt to their dynamically changing context • Many independent projects: ASSIST, Dynaco/AFPAC, GrADS , PCL, Safran, Plasma, AppLeS/AMWAT/APST, Active Harmony, …

4. Adaptability for grid computing • Platform: availability evolves dynamically • Not only faults • But also activities of concurrent users • And planned maintenance

5. Adaptability for grid computing • Example of announced maintenance operations • Table of planned events for the Grid5000 platform • Source: www.grid5000.fr, taken upon June the 7th • Should applications ignore those warnings?

6. Adaptability for grid computing • Applications • May experience long execution time • Usually longer than the mean time between platform changes • May have dynamic needs • E.g. data-driven behavior  Applications should adapt at runtime

7. Common schema • Aims at providing a high-level abstract model • Unifies the approaches of UNIPI (ASSIST) and INRIA-Rennes (Dynaco/AFPAC) • Applies to other approaches • Helps developers in designing and implementing adaptability

8. Common schema • Hierarchically splits the adaptation process in phases • Voluntarily under-specified • Two main phases at the higher level • Decide whether the application should adapt • Commit the decisions

9. Decide phase • Decides whether the application should adapt • Filters the changes that occur in the platform • Identify those that are significant enough • Discard the others • Determines a strategy for adapting the application • Two sub elements • Trigger: notification reception from the platform • Policy: specialization of the decide phase to the actual application

10. Commit phase • Applies a given strategy • Identifies the actions that should be performed • Executes those actions • Two sub elements • Plan: creation of an implementation of the strategy • Execute: execution of the plan • Split in turn into • Mechanisms: individual actions used to implement the strategy • Timing: scheduling and synchronization with the execution of the application

11. Approach of UNIPI • Compiler-based approach • Allows adaptability transparently to developers • Adaptation points placed by the compiler • Some adaptation mechanisms automatically generated • E.g. redistribution • Implemented in the ASSIST development environment for grid computing • Parmod skeleton is intrinsically adaptable • Changing the number of Virtual Processes Managers (VPM) executing the Virtual Processes (VP) • Redistributing VPs over VPMs • Parmod skeleton has a known performance model

12. ASSIST • Runtime support • Reflects the common abstract model • Control loop • Receive feedback from the trigger interface • Make decisions depending on the parmod skeleton performance model • Target only involved VPMs

13. Approach of INRIA-Rennes • Framework-based • Allows adaptability for legacy applications • Allows developers to design their own adaptability • May provide a runtime support for compiler-based approach/automatic adaptability generation • Split in two parts • Dynaco: generic adaptability framework • AFPAC: SPMD adaptable components

14. Dynaco • Defines an architecture for adaptability • Some key components • Monitor; Decider; Planner; Executor • Interactions and interfaces between those components • Concerns implemented by each of those components • Provides a reference implementation • Written in Java for the Julia implementation of Fractal • Gives some hints for binding adaptability to components • Using Fractal’s controllers and AOP

15. Dynaco framework • Reflects the common abstract model • Contains four major components, which model the four major phases and the four major concerns • Monitor the platform and resources • Decide whether the component should adapt • Plan how the component could be adapted • Execute the plan, which is composed of actions

16. AFPAC toolbox • One Dynaco component that wraps an SPMD code • With one special action that triggers SPMD actions, i.e. one action replicated in each process • One executor local to each process • Coordinates together the execution of local actions • Based upon developer-provided “adaptation points”

17. Connections to the GCM • Could be used to make GCM components adaptable • ASSIST adaptable parmods can be encapsulated into GCM components • Dynaco may allow to implement adaptability for GCM components

18. Requirements from GCM • Whatever the case, requires from GCM • Place-holder for adaptability • In a customizable controller/membrane/container? • Technology for integrating it • Aspect oriented programming? • Specialized structured programming paradigm?

19. Some web links • Research group on “Performance models and adaptivity”: http://www.di.unipi.it/~marcod/WP3homepage/RG_adaptivity/index.html • Assist website: http://www.di.unipi.it/Assist.html • Dynaco website: http://dynaco.gforge.inria.fr/ • Adaptability within the PARIS team: http://www.irisa.fr/paris/web/adapt.html