1

Update Strategies for First Class Futures

Khan Muhammad, Ludovic HenrioINRIA, 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

Which is the best future update strategy?

Goal: Analysis of future update strategies

3

Table of Contents

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

4

Active Objects (Overview)

A

Message Queue

Activity thread

Membrane (Body)

Pending Requests

Passive Objects

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

JVM

Active Object

Future Object Request

Req. Queue

Thread

v1v2 ag

WBN!

Wait-By-Necessity is a Dataflow

Synchronization

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

delta.send(result)

Future Update Strategies: No partial replies and request

Cannot Pass Future references between ActiveObjects

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

delta.send(result)result.bar()result.bar()

Future Update Strategies: Forward-based

13

delta.send(result)result.bar()result.bar()

Future Update Strategies: Forward-based

14

delta.send(result)result.bar()result.bar()

Future Update Strategies: Forward-based

Future updates follow the same path as future references

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

delta.send(result)result.bar()result.bar()

Future Update Strategies: Message-based

17

delta.send(result)result.bar()result.bar()

Future Update Strategies: Message-based

18

delta.send(result)result.bar()result.bar()

Future Update Strategies: Message-based

Fu

ture

Reg

istr

atio

nM

essa

ges

19

Future Update Strategies: Message-based(2)

gamma.send(param)

result = beta.get()delta.send(result)

Result.bar()Additional Registration

Messages required

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)

gamma.send(param)

result = beta.get()delta.send(result)

Result.bar()

22

Future Update Strategies: lazy(2)

gamma.send(param)

result = beta.get()delta.send(result)

Result.bar()

23

delta.send(result)result.bar()result.bar()

Future Update Strategies: Lazy Future Updates

“on demand” future update

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

•“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

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

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

Experimental Setting

f f

f

Pipe of varying length

Trees of different heights

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

delta.send(result)

Wait-by-necessity

39

delta.send(result)result.bar()result.bar()

Wait-by-necessity

40

delta.send(result)result.bar()result.bar()

Wait-by-necessity

41

Wait-by-necessity

result.bar()Futures updates can occur at any time

Futures updates can occur at any time