Efficient location-independent distributed active objects (actors)

Abstract

Described is a system for use in implementing a distributed actor architecture, the system comprising: an instance actor component comprising one or more instance receiver; one or more proxy actor component comprising: one or more proxy receiver configured to communicate with the instance receiver, wherein the instance actor component further comprises actor state information and message information, and is configured to control access to the instance data through the one or more proxy receiver.

Description

[0001] EFFICIENT LOCATION-INDEPENDENT DISTRIBUTED ACTIVE OBJECTS (ACTORS)

[0002] TECHNICAL FIELD

[0003] The present disclosure relates to a Location-Independent Distributed Actor architecture in distributed or cloud applications.

[0004] BACKGROUND

[0005] The actor model emerged in the early 1970s, largely from the work of Carl Hewitt, as a conceptual model for concurrent computation. While initially separate from object-oriented programming (OOP), the two paradigms soon influenced each other, especially through the concept of active objects. In the actor model, each actor can send and receive messages asynchronously, create new actors, and maintain private state. This natural encapsulation of behaviour and state is highly compatible with OOP, where objects also encapsulate state and behaviour, but traditionally interact synchronously.

[0006] In the 1970s and 1980s, object-oriented languages like Simula and Smalltalk began incorporating concepts related to concurrency and actors. Smalltalk-72, for example, allowed objects to communicate via message passing, an idea influenced by the actor model. This paved the way for a closer relationship between OOP and concurrency models.

[0007] The actor model was seen as an ideal fit for managing concurrency within OOP frameworks. The concept of active objects — objects that have their own thread of control and communicate via asynchronous messaging — grew out of this. In this context, active objects are like actors in that they manage their own state and behaviour while operating in a concurrent environment.

[0008] The 1980s and 1990s saw a growing emphasis on active objects in languages such as Ada and Java, which allowed for the modelling of concurrent systems. Ada introduced task objects, which can be seen as early instances of active objects, with built-in concurrency primitives to model distributed systems.

[0009] Meanwhile, the CORBA (Common Object Request Broker Architecture) standard, introduced in the early 1990s, promoted distributed object communication, although not inherently actor-based. CORBA’s focus on synchronous remote method invocations limited its scalability compared to asynchronous models. In contrast, languages inspired by the actor model, like Erlang (1986), found greater success in building highly scalable, fault-tolerant distributed systems, thanks to their use of lightweight actor-like processes.

[0010] While not an object-oriented language, Erlang heavily influenced the development of actor-based concurrent systems, particularly in fault-tolerant, distributed computing. In Erlang, each process behaves much like an active object, encapsulating state and communicating asynchronously through message passing. Erlang was designed for telecom systems, where massive concurrency and reliability are critical, and this model proved highly effective.

[0011] Erlang's influence grew beyond functional programming to inspire actor frameworks in OOP languages.

[0012] The Akka framework (2009) brought actor-based concurrency to the Scala programming language (an OOP and functional hybrid) and later to Java. Akka provided a robust model for building distributed, fault-tolerant systems within the JVM, treating actors as objects that encapsulate state and behaviour, communicating asynchronously via messages. This framework made actor-based systems accessible in OOP environments, using distributed actors to scale systems across multiple machines.

[0013] Akka's success demonstrated how the actor model could be integrated into object-oriented programming, with actors serving as lightweight, stateful, and distributed units of computation, similar to active objects in classical OOP. In 2014, Microsoft introduced Orleans, a distributed virtual actor model for building scalable cloud applications. Unlike traditional actors that require explicit management of actor lifecycles, Orleans provides virtual actors, which can be automatically created and distributed across a cloud infrastructure like Microsoft Azure. This made it easier to build highly scalable distributed systems using an actor-based approach in object-oriented languages like C#.

[0014] Orleans abstracts much of the complexity of managing distributed actors, offering a programming model that fits naturally with OOP and cloud-based distributed applications.

[0015] In 2021 , Swift introduced distributed actors as part of its effort to enhance concurrency and distributed computing capabilities. Swift’s distributed actor model allows actors to be distributed across multiple machines, while still using familiar object- oriented patterns. Distributed actors in Swift can encapsulate state and behaviour, but they are designed to work seamlessly in a distributed environment, abstracting away much of the complexity of networking and communication.

[0016] Swift's distributed actors build upon Swift's existing concurrency features (like async / await) and allow developers to mark actors as distributed. This enables the system to handle remote communication, serialization, and fault tolerance transparently. Distributed actors in Swift represent a modem blend of OO programming principles with the actor model, offering scalability and ease of use in distributed systems.

[0017] For example: distributed actor Greeter { distributed func sayHello() -> String { return "Hello from a distributed actor! "

[0018] }

[0019] }

[0020] This makes distributed programming accessible while maintaining the core principles of encapsulation and message-passing inherent to the actor model.

[0021] In the 2020s, the active object and actor models are integral to modem programming languages and distributed systems. Frameworks and languages such as: Elixir (based on Erlang’s VM), Akka (Scala / Java), Orleans (C#), and Swift's distributed actors, demonstrate how the actor model continues to influence the evolution of concurrent and distributed object-oriented systems.

[0022] These tools abstract much of the complexity of distributed computing, allowing developers to build scalable, fault-tolerant systems using asynchronous communication and the natural encapsulation of behaviour and state, blending the best of OOP and the actor model.

[0023] The present disclosure is therefore aimed towards providing methods and systems for solving at least the afore-mentioned problems.

[0024] SUMMARY

[0025] According to the present disclosure there is provided a system for use in implementing a distributed actor architecture, the system comprising: an instance actor component comprising one or more instance receiver; one or more proxy actor component comprising: one or more proxy receiver configured to communicate with the instance receiver, wherein the instance actor component further comprises actor state information and message information, and is configured to control access to the instance data through the one or more proxy receiver. This allows for location-independence to be supported and provides and encapsulated state in an OO programming model.

[0026] The system as described above, wherein the instance actor component and the one or more proxy actor component are located at distinct locations from each other. This allows the system to be distributed remotely and does not require the one or more proxies to be situated locally.

[0027] The system as described above, wherein the instance actor component and the one or more proxy actor component comprise instance information identifying the component, which is passed to the receiver of one or more other instance actor. This allows for the actors within the system to identify each other and communicate effectively.

[0028] The system as described above, wherein the instance actor component is further configured to determine the location of the one or more proxy actor components. This allows the system architecture to be known to both the one or more proxy and the instance actor.

[0029] The system as described above, wherein the system if further configured to: determine resource utilization in dependence on one or more of a load distribution, communication latency or communication throughput within the system; and redistribute the location of the instance actor components based on the determined load distribution without any detectable action by users of the one or more proxy actor component. This allows for effective migration during runtime of the instance actor components while maintaining location-independence.

[0030] The system as described above, wherein the one or more proxy actor component further comprises one or more proxy method configured to communicate with the one or more proxy receiver. This allows for communication within and between the one or more proxies.

[0031] The system as described above, wherein the one or more proxy actor component is collocated with the instance actor component; and wherein the one or more proxy actor component is configured to store customized and / or optimized code representing a remote or local interaction between the one or more proxy actor component and the instance actor component. This allows for the one or more proxy and the instance actor components to be located at the same physical location within the system and does not require the use of a network.

[0032] There is also provided a method for optimizing the implementation of a distributed actor system, the method comprising: receiving, at one or more proxy actor component, a method call from a program; outputting the method call as a message to a instance actor component; receiving at the instance actor component the output method call; and providing the one or more proxy actor component with data stored in the instance actor component based on the received method call; wherein the instance actor component is configured to control access to the stored data by the one or more proxy receiver. This allows for location-independence to be supported and provides and encapsulated state in an OO programming model.

[0033] The method as described above, wherein the instance actor component and the one or more proxy actor component are located at distinct locations from each other. This allows the system to be distributed remotely and does not require the one or more proxies to be situated locally.

[0034] The method as described above, wherein the instance actor component and the one or more proxy actor component comprise instance information identifying the component, which is passed to the receiver of one or more other instance actor. This allows for the actors within the system to identify each other and communicate effectively. The method as described above, wherein the instance actor component determines and uses the location of the one or more proxy actor components. This allows the system architecture to be known to both the one or more proxy and the instance actor.

[0035] The method as described above, wherein the method further comprises: determining resource utilization in dependence on one or more of a load distribution, communication latency or communication throughput within the system; and redistributing the location of the instance actor components based on the determined load distribution without any detectable action by users of the one or more proxy actor component. This allows for effective migration during runtime of the instance actor components while maintaining location-independence.

[0036] The method as described above, wherein the one or more proxy actor component further comprises one or more proxy method configured to communicate with the one or more proxy receiver. This allows for communication within and between the one or more proxies.

[0037] The method as described above, wherein the one or more proxy actor component is collocated with the instance actor component; and wherein the one or more proxy actor component is configured to store a customized and / or optimized code representing a remote or local interaction between the one or more proxy actor component and the instance actor component. This allows for the one or more proxy and the instance actor components to be located at the same physical location within the system and does not require the use of a network.

[0038] A computer program stored in stored in non-transitory form comprising a program code for performing the method as described above when executed on a computer. This allows the method to be implemented by a computer specifically as program code.

[0039] BRIEF DESCRIPTION OF THE DRAWINGS

[0040] The present disclosure is described by way of example, with reference to the accompanying drawings, in which:

[0041] Figure 1 illustrates an example of Location-Independent Distributed Actor architecture (LIDA);

[0042] Figure 2 illustrates an example of use of LIDA from two different locations;

[0043] Figure 3 illustrates an example of single-node efficient behaviour;

[0044] Figure 4 illustrates an example of instance runtime migration;

[0045] Figure 5 illustrates an example of the code implementation of the system and method of the present disclosure in programming language Cangjie.

[0046] DETAILED DESCRIPTION

[0047] The present disclosure is primarily concerned with means of implementing distributed or cloud applications, especially with the technical complications specific to such applications compared to single node (centralized) applications. In particular there are three aspects that are important when implementing such systems and applications disclosed herein. The first of these relates to location independence and preserving the behaviour of a software component relative to another software component no matter if they are located on the same node or on different nodes. A further consideration is runtime migration, which is the ability to move a software component between nodes in order to facilitate load balancing or resource minimization. Profiler- guided optimization (PGO) is also important and provides the ability to gather real application data and determine on the basis of it the best location for a software component. This requires location-independence as a prerequisite. Finally, it is beneficial to consider object-orientedness (OO), which describes the ability to write software in a style as close as possible to conventional OO programming.

[0048] There are many ways to create distributed or cloud software, however most of these solutions fail to consider and meet the important aspects described above.

[0049] For example, Java RMI fails location independence, as local objects are passed by when used as arguments to local calls but passed by copy (cloning) when used in remote calls, which produces different results. Various REST-ful frameworks do not present a conventional OO syntax to the programmer but are (at best) domain-specific languages with different syntax and semantics than the language in which they are embedded, making the concepts of location-independence (hence PGO) and runtime migration not applicable. Distributed Component Object Model (DCOM) is a standard for distributed objects that is only applicable to Microsoft Windows and does not support location independence or runtime migration, although they do present an OO programming model. Other conventional Actors do not support an OO programming model but are a lower- level model based on simple one-way messages rather the complex two-way communication required by OO methods.

[0050] Swift actors go some way to addressing the aspects described above however, these have a number of drawbacks. For example, Swift actors differentiate between local and distributed actors and are therefore not truly location independent. In contrast the solution of the present disclosure supports location independence fully. In addition, Swift Distributed Actors require a discovery mechanism which makes them different from local actors, which do not require them. The technical solution of this disclosure fully unifies local and distributed actors and thus it requires no discovery mechanism. Furthermore, Swift Distributed Actors are not migratable, because their discovery mechanism assumes they are pinned to a fixed location. Finally, CORBA is a standard rather than a concrete technical solution.

[0051] The present disclosure provides a system and method for solving the problems of location independence and runtime-migration while enabling profiler-guided optimization in an object-oriented model simultaneously.

[0052] The system and method of this disclosure will now be described in relation to the figures. The system of the present disclosure may implement a Location-Independent Distributed Actor architecture, as shown as an overview in Figure 1 , that comprises two distinct components which may reside at two different locations in the system. As shown in Figure 1, a program context 101 may issue call commands to the actor proxy 102 that in turn may communicate, via one or more proxy receiver 103, with an instance actor 104 that may comprise one or more instances receiver and stored data in the form of actor state information and / or message information. The instance actor component 104 will control access to instance data such as instance methods or additional data such that only authorised proxies 102 may access it. The instance actor shown in Figure 1 comprises a mailbox and message loop that receives the call over the network from the proxy 102 and the call propagates through the instance receiver to the stored instance methods of the instance actor. If access is granted the instance data information (members) may be accessed and relayed to the proxy 102 for use in the program context 101.

[0053] The first component may be an instance actor 104 which may hold the persistent state of an actor and a mailbox. The instance may have instance methods which have access to the state of the instance. The instance may also run a message loop that processes the message the actor receives. The instance state and methods may not be directly accessible by client programs. The instance actor component 104 may also comprise methods called instance receivers which can be accessed by the proxy via proxy receivers, as discussed below. The instance actor 104 component further comprises actor state information and message information, and is configured to control access to the instance data through the one or more proxy receiver. The control of access in Figure 1 may be achieved by the instance actor 104, which controls the stored data methods (instance methods) that may be called by the one or more proxy. Such stored data is restricted such that it is not stored by the one or more proxy.

[0054] The second component of the system may be one or more proxy 102 comprised of one or more proxy receiver configured to communicate with the instance receiver. In other words, the one or more proxy actor 102 may comprise (usually, but not necessarily, asynchronous) methods called proxy receivers which are visible by the program context. A proxy (proxy actor) 102 may also include proxy methods, which only have access to the one or more proxy receivers 103. The instance actor component 104 and the one or more proxy actor component comprise instance information identifying the component, which is passed to the receiver of one or more other instance actor component. The instance information may comprise instance reference information identifying the component. The instance actor component is further configured to determine the location of the one or more proxy actor components. In some examples, the one or more proxy actor component is configured to store customized and / or optimized code representing a remote or local interaction between the one or more proxy actor component and the instance actor component. This allows the system architecture to be known to both the one or more proxy and the instance actor.

[0055] There are several roles that the proxy receivers 103 perform. These are as follows and include that the one or more proxy receiver may be configured to receive a method call from the program context; marshal the method call (method name and arguments) in a message; serialize the message and send it over the network to the instance message loop; receive messages over the network from the instance; deserialize the message into local data formats. The one or more proxy receiver 103 may further be configured to provide the data to the program context as a return value of the methods call. The role of the message loop in Figure 1 is to place messages from the proxy actor 102 into the message loop and process messages in the message loop sequentially. The message loop of Figure 1 may also be used for each message call the correct instance receiver and serialize and send over the network 105 the return value of the instance receiver.

[0056] Figure 2 illustrates the use of LIDA from two different locations is illustrated below, illustrating how location-independence may be achieved. The system of the present disclosure may achieve this by identifying an actor by its instance. The instance may be unique to the actor and therefore can be used as an identifier. Alternatively, the actor may have multiple proxies located at different locations, which serve the same role as references. In Figure 2, locations A, B, and C may be different locations alternatively may be the same location. An instance actor 204 located at node C may be accessed in the same way from locations A and B via proxies 202 located at those nodes. This is possible because the one or more proxies 202 are stateless and may include only the one or more proxy receivers 203 and proxy methods which only use proxy receivers. As can be seen in Figure 2, each of the one or more proxies may have an associated program context 201 and may pass method calls via, the network 205 between each other, however it should be understood that such method calls will be copies of the original obtained by controlled access to the instance actor 204 by one or more of the proxies 202. In other words, if an actor is passed as argument to a method, what gets passed is a copy of the proxy actor 202, this is because the proxy actor 202 is stateless. The passing by-copy may be observably the same as passing it by-reference. The one or more proxies serve as references to the (same) instance, so passing copies of them around is same as passing instance reference around.

[0057] This disclosure also provides a method for optimizing the implementation of LIDA when the actor proxy and the actor instance are located on the same node, without changing the behaviour. Such a configuration can be seen in Figure 3 of this disclosure. In the example of Figure 3 it can be seen that the one or more proxy 302 comprising one or more proxy receiver 303 and the instance actor 304 are adapted to be located at the same node to allow efficient single node behaviour. Single node behaviour as shown in Figure 3 can be achieved using distributed actors that are implemented on the same node. In other words, the actors 302 and 304 are locally distributed. In this example, the one or more proxy receiver and the instance actor may communicate using marshalling / demarshalling, which therefore leads to increased efficiency of the network stack. In Figure 3, the single-node (local) behaviour can be optimized by having the proxy receivers 303 act on (communicate with) the instance actor mailbox directly and not over a network 305. This may be accomplished by a compiler generating special code for singlenode (local) behaviour that may be different from code used for genuinely distributed (remote) behaviour. In the example of Figure 3, each actor may be equipped with code for both remote and local proxy-instance interaction. It is important to note that local proxies and remote proxies may coexist without interfering which each other’s functionality.

[0058] To achieve efficient remote behaviour, this disclosure provides an example as set forth in Figure 4. Runtime migration of can be achieved as shown in Figure 4 to relocate an instance actor 404. There are a number of factors that may determine whether it is beneficial to perform instance migration at runtime. These are to achieve load balancing, access to resources within particularly locations, to manage network latency and delay or to resolve network or equipment failure. In some cases, the system of the present disclosure may determine resource utilisation, in other words where to locate the instance actor 404 or whether to perform instance migration, in dependence on one or more of these factors. The system may also determine each of these one or more factors determine resource utilization in dependence on one or more of a load distribution, communication latency or communication throughput within the system. The system may then be configured to redistribute the location of the instance actor component 404 based on the determined load distribution without any detectable action by users of the one or more proxy actor component. So long as the proxies 403 are updated with the new location of an instance actor component 404, an instance 404 can move from A to B at runtime transparently. During the migration the proxy receivers 403 must hold the messages in a local queue within the system. In order to prevent runtime errors in the example shown in Figure 4, the data members of the instance actor 404 must be self-contained and there should be no references from the data members into the local memory of A; and there should be no references from the local memory of A to the data members. In some cases, there may be a need for enforcement of encapsulation and there are a number of methods for performing such enforcement encapsulation. Such methods include but are not limited to static analysis, programmer discipline, ownership types.

[0059] This disclosure also provides a method for optimizing the implementation of a distributed actor system as described in the above-mentioned figures. The method may comprise receiving, at one or more proxy actor component, a method call from a program; outputting the method call as a message to a instance actor component; receiving at the instance actor component the output method call; and providing the one or more proxy actor component with data stored in the instance actor component based on the received method call; wherein the instance actor component is configured to control access to the stored data by the one or more proxy receiver. This method relates to the above-described figures and the messages within the system described above. There is also provided as part of this disclosure a computer program stored in stored in non-transitory form comprising a program code for performing the method when executed on a computer.

[0060] The system and the method of the present disclosure of the present disclosure are applicable in compilers for programming languages which support cloud or distributed computing either natively or via libraries and frameworks. As such, the products that implement the system and method of the present disclosure may be source code and programs that use those compilers or that are generated by those compilers.

[0061] As part of a compiler, it should be possible to determine if optimizations enabled by this disclosure are being used by looking at the output of the compiler. If the compiler is available as open source, which is a common situation, it is possible to also inspect the source code for detection of the system and method of the present disclosure.

[0062] Figure 5 provides one example of how the system and method of the present disclosure may be implemented. In the example of Figure 5 the system and method may be implemented in the Cangjie programming language although it should be understood that other programming languages could be used. Figure 5 illustrates the implementation of LIDA with code using the Cangjie programming language. This language is used for illustration only and because it is used as an implementation. Most programming languages can be equipped with support for LIDA. As shown in Figure 5 the one or more proxy actor, the one or more proxy receiver invocation is denoted by !”, which is the usual notation for an actor receiving a message. The code illustrated in Figure 5 is location independent in the sense that actor creation (al, a2, a3) may be parameterized by location, and the rest of the code does not change when the locations change. The behaviour of the code does not change when the locations change. Actor a3 may be migrated to another location. The runtime migration does not affect observable behaviour on the rest of the program and thus effective runtime migration can be achieved.

[0063] In a conventional object-oriented programming language the proxy and the instance must be specified together. The code for proxy receivers, message loop, and mailbox management can be automatically synthesised by a compiler. In the system of this disclosure no data members should reside on the proxy, and instance data members and methods may only be accessible, if the language offers the facility, from the same object instance. If not, it is the responsibility of the programmer to use the active object correctly. It may be convenient for efficiency purposes that the instance code runs concurrently with the other code at that location; however, the messages must be processed sequentially. Error management and recovery are outside of the scope of this patent application

[0064] The advantageous effects of the system and method of the present disclosure are therefore that novel architecture and algorithms for separating a distributed objects (actors) into stateless proxies and stateful instances are provided. These support location-independence. In addition, the described configuration of the system and method steps, restrict instance methods so they can only be used by receivers. In addition, it is therefore possible to restrict instance data members so they can be only accessed by instance methods and receivers. This provides an encapsulate state, which supports location-independence in an OO programming model. Multiple proxies may be used for the same instance which provides support location independence and runtime migration. The system and method of this disclosure may use dual remote / local receiver code that supports migration (runtime or PGO) efficiently. In addition, the use of proxies as instance references, which ensures that locationindependence is compatible with the OO programming model.

[0065] In the programming language Cangjie the encapsulation of the actor state is further supported by a static analysis that ensure that whenever data is used as argument to a receiver or actor constructor it is never an object reference, but always either elementary data (integers, characters, etc), or actors, or combination thereof.

[0066] Furthermore, the combination of location independence and OO, supporting Profiler-guided optimization (PGO) and runtime migration together have the following benefits. They significantly simplify the required code for cloud and distributed apps. They reduce or eliminate bugs due to inconsistent by-copy vs. by-reference method calls. They enable optimal deployment (e.g. via profiler-guided optimization) of cloud and distributed apps. They enable runtime redeployment (i.e. migration) of objects to manage costs and overheads. Finally, they optimize local-only behaviour by using dual proxies.

Claims

CLAIMS1. A system for use in implementing a distributed actor architecture, the system comprising: an instance actor component comprising one or more instance receiver; one or more proxy actor component comprising: one or more proxy receiver configured to communicate with the instance receiver, wherein the instance actor component further comprises actor state information and message information, and is configured to control access to the instance data through the one or more proxy receiver.

2. The system according to claim 1 , wherein the instance actor component and the one or more proxy actor component are located at distinct locations from each other.

3. The system according to claim 1 or 2, wherein the instance actor component and the one or more proxy actor component comprise instance information identifying the component, which is passed to the receiver of one or more other instance actor4. The system according to any preceding claim, wherein the instance actor component is further configured to determine the location of the one or more proxy actor components.

5. The system according to any preceding claim, wherein the system if further configured to: determine resource utilization in dependence on one or more of a load distribution, communication latency or communication throughput within the system; and redistribute the location of the instance actor components based on the determined load distribution without any detectable action by users of the one or more proxy actor component.

6. The system according to any preceding claim, wherein the one or more proxy actor component further comprises one or more proxy method configured to communicate with the one or more proxy receiver.

7. The system according to any preceding claim, wherein the one or more proxy actor component is collocated with the instance actor component; and wherein the one or more proxy actor component is configured to store customized and / or optimized code representing a remote or local interaction between the one or more proxy actor component and the instance actor component.

8. A method for optimizing the implementation of a distributed actor system, the method comprising: receiving, at one or more proxy actor component, a method call from a program; outputting the method call as a message to a instance actor component; receiving at the instance actor component the output method call; and providing the one or more proxy actor component with data stored in the instance actor component based on the received method call; wherein the instance actor component is configured to control access to the stored data by the one or more proxy receiver.

9. The method according to claim 8, wherein the instance actor component and the one or more proxy actor component are located at distinct locations from each other.

910. The method according to claim 8 or 9, wherein the instance actor component and the one or more proxy actor component comprise instance information identifying the component, which is passed to the receiver of one or more other instance actor.

11. The method according to any one of claims 8 to 10, wherein the instance actor component determines and uses the location of the one or more proxy actor components.

12. The method according to any one of claims 8 to 11, wherein the method further comprises: determining resource utilization in dependence on one or more of a load distribution, communication latency or communication throughput within the system; and redistributing the location of the instance actor components based on the determined load distribution without any detectable action by users of the one or more proxy actor component.

13. The method according to any one of claims 8 to 12, wherein the one or more proxy actor component further comprises one or more proxy method configured to communicate with the one or more proxy receiver.

14. The method according to any one of claims 8 to 13, wherein the one or more proxy actor component is collocated with the instance actor component; and wherein the one or more proxy actor component is configured to store a customized and / or optimized code representing a remote or local interaction between the one or more proxy actor component and the instance actor component.

15. A computer program stored in stored in non-transitory form comprising a program code for performing the method according to any one of claims 8 to 13 when executed on a computer.

Images