1. 1 Update Strategies for First Class Futures Khan Muhammad, Ludovic Henrio INRIA, Univ. Nice Sophia Antipolis,CNRS

2. 2 Introduction / Contributions Semi-formal event-like notation  Compromise between easy to read and precision Cost analysis of the strategies  Cost in terms of message exchanges Experimental Evaluation  Verifying the results of the cost analysis Which is the best future update strategy? Goal: Analysis of future update strategies

3. 3 Table of Contents Background & Related Work Future Update Strategies Semi-formal notation for modeling strategies Cost analysis & Experimental evaluation Conclusion & Future directions

4. 4 Active Objects (Overview) A Message Queue Activity thread Membrane (Body) Pending Requests Passive Objects

5. 5 A Active objects,Futures & WBN Proxy Java Object A ag = newActive (“A”, […], VirtualNode) V v1 = ag.foo (param); V v2 = ag.bar (param);... v1.bar(); //Wait-By-Necessity V JVM A Active Object Future Object Request Req. Queue Thread v1 v2 ag WBN! Wait-By-Necessity is a Dataflow Synchronization

6. 6 Context Active Objects  Single Activity Thread: no shared memory  Message Queue Futures  Creation: Explicit/implicit  Access: Explicit vs transparent  First class futures: transmit futures between AO »Increases parallelism  Wait by necessity (Strict operations) »Data flow synchronization

7. 7 Related Work Lambda Calculus, Multi-Lisp, ABCL/f  Not first class futures Creol  Explicit future Creation  Explicit access Ambient Talk  Future access is asynchronous  No synchronization

8. 8 Table of Contents Background & Related Work Future Update Strategies Semi-formal notation for modeling strategies Cost analysis Experimental evaluation Conclusion & Future directions

9. 9 Future update strategies Can be divided in two categories  Eager  Future updated as soon as result is available  Lazy  On demand / “need to know” future update Eager Strategies  Eager forward-based  Eager message-based Lazy  Lazy message-based No Partial Replies & requests  No First-class futures

10. 10 delta.send( result )    Future Update Strategies: No partial replies and request Cannot Pass Future references between ActiveObjects

11. 11    Future Update Strategies: First Class Futures  gamma.send(param) result = beta.get() delta.send(result) Result.bar() Only operations that manipulate future value are blocking

12. 12 delta.send(result)result.bar()    Future Update Strategies: Forward-based 

13. 13 delta.send(result)result.bar()    Future Update Strategies: Forward-based 

14. 14 delta.send(result)result.bar()    Future Update Strategies: Forward-based  Future updates follow the same path as future references

15. 15 Future Update Strategies: Forward-based (summary) All futures references are eventually updated Future update starts as soon as value is computed Each AO is responsible for updating futures it has forwarded Future updates follow the same path as futures  Future value may need to pass through “n” intermediate hops Future value is serialized and de-serialized at each intermediate node Once the value is updated, no need to store it further

16. 16 delta.send(result)result.bar()    Future Update Strategies: Message-based 

17. 17 delta.send(result)result.bar()    Future Update Strategies: Message-based 

18. 18 delta.send(result)result.bar()    Future Update Strategies: Message-based  Future Registration Messages

19. 19    Future Update Strategies: Message-based(2)  gamma.send(param) result = beta.get() delta.send(result) Result.bar() Additional Registration Messages required

20. 20 Future Update Strategies: Message-based (Summary) Centralized future updates  All updates are performed by “Home” node Future update starts as soon as value is computed Additional “future registration” messages needed One-to-many communication to avoid multiple serializations Computed results are stored until all futures have been updated

21. 21    Future Update Strategies: lazy(2)  gamma.send(param) result = beta.get() delta.send(result) Result.bar()

22. 22    Future Update Strategies: lazy(2)  gamma.send(param) result = beta.get() delta.send(result) Result.bar()

23. 23 delta.send(result)result.bar()    Future Update Strategies: Lazy Future Updates  “on demand” future update

24. 24 Future Update Strategies: Lazy Strategy (Summary) Centralized future update Least number of messages exchanged (unless Worst case) On demand registration and update Additional delay Good when only some nodes need the future value  No need to update intermediate nodes

25. 25 Table of Contents Background & Related Work Future Update Strategies Semi-formal notation for modeling strategies Cost analysis & Experimental evaluation Conclusion & Future directions

26. 26 Semi-formal notation for strategies Modeled as combination of operations & events  Operations  Register future (Reg)  Locally update future with value (Update)  Clear future from list (Clear)  Send future value (SendValue)  Events  Create future (Create)  Send future reference (SendRef)  Future Computed (FutureComputed)  Wait by necessity (Wait)

27. 27 Eager Message-based Strategy (semi-formal notation) Compromise between “readability” and precision

28. 28 Table of Contents Background & Related Work Future Update Strategies Semi-formal notation for modeling strategies Cost analysis & Experimental evaluation Conclusion & Future directions

29. 29 Comparison/Cost Analysis “Computation time” is not taken into account (application dependent) Only “time to update future” Assumes that result has been computed when the registration request is received Simple model to allow reasoning about strategy selection at abstract lvl

30. 30 Experiment Result (1)

31. 31 Experiment Results (2)

32. 32 Table of Contents Background & Related Work Future Update Strategies Semi-formal notation for modeling strategies Cost analysis & Experimental evaluation Conclusion & Future directions

33. 33 Conclusion & Future directions (1) Selection of a strategy depends on application nature (and configuration) Eager forward-based:  Most nodes actually require future value  Small number of intermediate nodes  Size of transferred data is “not huge” Message-based:  Most nodes actually require future value  No network constraints  Constant future update time needed (single hop) Lazy message-based:  Only few nodes actually require future value  Future value is “too large”  Long term storage of values is not a concern

34. 34 Conclusion & Future directions (2) Garbage Collection of computed Futures for message- based strategies Protocol for “cancel future update” for objects not interested in future value (a un-register message) Canceling a request Migration: for message-based strategies Merci !

35. 35 Experimental Setting ff f Pipe of varying length Trees of different heights ff f

36. 36 Experimental Setting Exp (1) Tree configuration (varying height & degree) Fixed future size of (20 MB) Tree of 30 nodes Only leaf nodes (8 max) a perform strict operation Cluster of 10 physical Nodes (university of sannio) Exp (2) Pipe of varying length Only last node in pipe makes a strict operation Fixed future size (20 MB)

37. 37 Current implementation status Currently a prototype implementation with university of sannio  Does not fit well with current AC mechanism  Does not reuse ProActive’s AC mechanisms  Functionality is spread over different classes -> Need to be brought in-line with the AC mechanism of ProActive.  No garbage collection for computed results +registration requests  Home-based strategies are implemented using a “reference to home” (body) in FutureProxy (will cause problems for migration)  Additional class “RequestForFuture.java added to implement registration  Implementing a multi-threaded future update mechanism with unique-serialization

38. 38 delta.send(result)    Wait-by-necessity

39. 39 delta.send(result) result.bar()    Wait-by-necessity

40. 40 delta.send(result) result.bar()    Wait-by-necessity

41. 41    Wait-by-necessity result.bar() Futures updates can occur at any time Futures updates can occur at any time