Update Strategies for First Class Futures

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

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 Goal: Analysis of future update strategies Which is the best future update strategy?

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

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

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

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. 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. Table of Contents • Background & Related Work • Future Update Strategies • Semi-formal notation for modeling strategies • Cost analysis • Experimental evaluation • Conclusion & Future directions

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. Future Update Strategies: No partial replies and request a b Cannot Pass Future references between ActiveObjects delta.send(result) d

11. Future Update Strategies: First Class Futures a b Only operations that manipulate future value are blocking result = beta.get() delta.send(result) Result.bar() d g gamma.send(param)

12. Future Update Strategies: Forward-based a b delta.send(result) result.bar() result.bar() d g

13. Future Update Strategies: Forward-based a b delta.send(result) result.bar() result.bar() d g

14. Future Update Strategies: Forward-based a b Future updates follow the same path as future references delta.send(result) result.bar() result.bar() d g

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. Future Update Strategies: Message-based a b delta.send(result) result.bar() result.bar() d g

17. Future Update Strategies: Message-based a b delta.send(result) result.bar() result.bar() d g

18. Future Update Strategies: Message-based a b delta.send(result) result.bar() result.bar() d Future Registration Messages g

19. Future Update Strategies: Message-based(2) a b Additional Registration Messages required result = beta.get() delta.send(result) Result.bar() d g gamma.send(param)

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. Future Update Strategies: lazy(2) a b result = beta.get() delta.send(result) Result.bar() d g gamma.send(param)

22. Future Update Strategies: lazy(2) a b result = beta.get() delta.send(result) Result.bar() d g gamma.send(param)

23. Future Update Strategies: Lazy Future Updates a b “on demand” future update delta.send(result) result.bar() result.bar() d g

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. Table of Contents • Background & Related Work • Future Update Strategies • Semi-formal notation for modeling strategies • Cost analysis & Experimental evaluation • Conclusion & Future directions

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. Eager Message-based Strategy (semi-formal notation) Compromise between “readability” and precision

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

29. Comparison/Cost Analysis Simple model to allow reasoning about strategy selection at abstract lvl • “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

30. Experiment Result (1)

31. Experiment Results (2)

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

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. Merci ! 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

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

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. 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. Wait-by-necessity a b delta.send(result) d

39. Wait-by-necessity result.bar() a b delta.send(result) result.bar() d

40. Wait-by-necessity result.bar() a b delta.send(result) result.bar() d

41. Wait-by-necessity a b Futures updates can occur at any time result.bar() d