Erlang (1728/erl002)

Logo of ERLANG

Concurrent functional language 


both for A. K. Erlang (Danish mathematician) and ERicsson LANguage

Armstrong, Williams & Virding, Ellemtel, Sweden.

Concurrent functional programming language for large real-time systems.

Specifically designed to build fault-tolerant, distributed systems which can contain large numbers of current processes. Concurrent functional language for large industrial real-time systems. Dynamically typed, pattern matching syntax, recursive equations, explicit concurrency, and asynchronous message passing. Relatively free from side effects. Transparent cross-platform distribution. Primitives for detecting run-time errors. Real-time GC modules. Dynamic code replacement (change code in running real-time systems without stopping systems). Foreign language interface.  


Structures:
Samples:
References:
  • Armstrong, J., R. Virding, et al. (1993). Concurrent programming in ERLANG. New York, Prentice Hall. view details
  • Armstrong, J. "Concurrent programming in ERLANG" London; New York, Prentice Hall, 1996 view details
  • Armstrong, J. "The development of Erlang" view details
          in Proceedings of the 1997 ACM SIGPLAN International Conference on Functional Programming, (ICFP '97) June 1997 view details
  • Feeley, M. and M. Larose "Compiling Erlang to Scheme" in C. Palamidessi, H. Glaser, and K. Meinke, editors, Principles of Declarative Programming, LNCS 1490, pages 300{317. Springer-Verlag, Sept. 1998. view details
          in Proceedings of the 1997 ACM SIGPLAN International Conference on Functional Programming, (ICFP '97) June 1997 view details
  • Wadler, Philip "An angry half-dozen" view details
          in SIGPLAN Notices 33(2) February 1998 view details
  • Johansson, Erik; Pettersson, Mikael; Sagonas, Konstantinos "A high performance Erlang system" view details Abstract: Erlang is a concurrent functional programming language designed to ease the development of large-scale distributed soft real-time control applications. It has so far been quite successful in this application domain, despite the fact that its currently available implementations are emulators of virtual machines. In this paper, we improve on the performance aspects of Erlang implementations by presenting HiPE, an open-source native code compiler for Erlang. HiPE is a complete implementation of Erlang, offers exible integration
    between emulated and native code, and efficiently supports features crucial for Erlang's application domain such as concurrency. As our performance evaluations show, HiPE is currently the fastest among all Erlang implementations. Extract: Introduction
    INTRODUCTION

    The concurrent functional programming language Erlang was designed by Ericsson to address the needs of large-scale distributed soft real-time control applications [2]. Such applications routinely arise in products developed by the telecommunications industry. Erlang caters for these needs with a run-time system that provides many features often associated with an operating system rather than a programming language. These features include scheduling of lightweight concurrent processes, automatic memory management, networking, protection from deadlocks and programmer errors, and support for continuous operation even when performing software upgrades.

    After around a decade of existence, Erlang is generally considered as a "success-story" in declarative programming languages; see e.g. [25]. Users experience that Erlang allows telecommunication systems to be programmed with less effort and fewer errors than by using conventional programming language technology [1, 5]. It is worthwhile to note that such systems typically consist of several hundred thousand lines of source code (the size is partly due to the complexity of the telecommunication protocols), and rely heavily upon the concurrency capabilities of Erlang.

    The industry, besides Ericsson, is showing a growing interest in Erlang, but there is a very limited choice of compilers, partly due to Erlang's until recently exclusive "in-house" development. Also, as an implementor of these compilers publicly admits [1]: `performance has always been a major problem' and `we are (even) considering adding imperative features to the language to solve these (performance) problems'. Indeed, the performance of current implementations of Erlang is inferior to that of good implementations of other functional programming languages; see also [8, 11]. In the competitive market of telecommunications, however, the need for a high-performance implementation is sometimes pressing. As one such example, consider AXD 301, a new generation ATM switching system from Ericsson [5]. The major part of AXD 301's software is written in Erlang; it consists of about 480,000 lines of Erlang code, with about 95,000 of them constituting the time-critical modules of the system. Speeding up this time-critical part would be more than welcome by the AXD 301 engineering team, let alone Ericsson, because this speedup directly corresponds to the ATM switch being capable of servicing more requests; see also [5]. Currently, complete implementations of Erlang are based on emulators of virtual machines. This gives them good portability, but emulation incurs a performance penalty to Erlang programs which some users wish|and in some cases need to|avoid. Ways to avoid the performance problems caused by emulation are: 1) compile to a sufficiently low-level and fast language such as C or 2) use the recently proposed C-- [19] as a portable assembly language, 3) use a retargetable code generator such as ML-RISC [18] or 4) the gcc back-end [21], or 5) compile directly to native code. Each of these implementation choices has well-known pros and cons but one can roughly expect a decrease in portability and an increase in performance and implementation e ort for a higher choice number; see also the above references and the references therein.

    Perhaps another issue deserves attention: byte-code emulators usually result in smaller object code size than C-based or native code compilers. Although object code size is becoming less and less of a concern nowadays, it is still a potential problem when the source code of the application consists of several hundred thousand lines. Also, not paying attention to code size can result in poor I-cache behaviour leading to significant performance degradation. Ideally, a system should provide a seamless integration of emulated and native code execution, and allow its user to choose the execution mode individually for each application component based on the various space/time trade-offs that are involved. Information about these trade-offs should also be something that the system provides to its user.

    This paper presents our approach to the efficient execution of Erlang. We have developed a system, HiPE, which combines the performance characteristics of a native code compiler with the benefits of an emulated implementation. HiPE currently uses the JAM emulator [1] as a basis and allows selective compilation of whole modules or individual functions into native code, which is then executed directly by the underlying hardware. Besides fully describing the architecture of HiPE and the changes to the JAM run-time system needed to support native code execution, we discuss various technical issues that this emulated/native code integration entails in the context of Erlang and how we dealt with them. Extract: Introduction
    A BRIEF INTRODUCTION TO ERLANG
    Erlang is a dynamically typed, strict, concurrent functional programming language. It is possible to create closures in Erlang, but typical Erlang programs are mostly rst-order. Erlang's basic data types are atoms, numbers (integers with arbitrary precision and  oats), process identifiers, and references; compound data types are lists and tuples. There is no destructive assignment of variables and the rst occurrence of a variable is its binding instance. Function selection happens using pattern matching. Erlang's design inherits some ideas from concurrent constraint logic programming languages such as the use of  at guards in function clauses.

    Processes in Erlang are extremely light-weight, their number in typical applications is quite big, and their memory requirements vary dynamically. Erlang's concurrency primitives (spawn, "!" (send), and receive) allow a process to spawn new processes and communicate with other processes through asynchronous message passing. Any data value can be sent as a message and processes may be located on any machine. Each process has a mailbox, essentially a message queue, where each message sent to the process will arrive. Message selection from the mailbox occurs though pattern matching. There is no shared memory between processes and distribution is almost invisible in Erlang. To support robust systems, a process can register to receive a message if another one terminates.

    Erlang applications typically consist of a number of modules: an Erlang module defines a number of functions. Only explicitly exported functions may be called from other modules. Calling functions in di erent modules, called remote calls, is done through supplying name of the module of the called function. During execution of functions, tail call optimization is performed. As in other functional languages, Erlang's memorymanagement is automatic through garbage collection. The real-time concerns of the language call for bounded-time garbage collection techniques; see [24, 16]. In practice, garbage collection times are usually small as most processes are short-lived or small in size.

    To perform system upgrading while allowing continuous operation, an Erlang system needs to cater for the ability to change the code of a module while the system is running, so called hot-code loading. Processes that execute old code can continue to run, but are expected to eventually switch to the new version of the module by issuing a remote call (which will always invoke the most recent version of that module).

    Erlang provides mechanisms for allowing a process to timeout while waiting for messages and a catch/throw-style exception mechanism for error handling. The Erlang language was purposely designed to be small, but comes with libraries containing a large set of built-in functions (known as BIFs). With the Open Telecom Platform (OTP) middleware [23], Erlang is extended with standard solutions to common requirements of telecommunication applications (servers, state machines, process monitors, load balancing), standard interfaces (CORBA), and standard communication protocols such as HTTP and FTP.
          in Proceedings of the 2nd international ACM SIGPLAN conference on on Principles and practice of declarative programming, September 20-23, 2000, Montreal, Quebec, Canada view details
  • Library of Congress Subject Headings E75 view details
          in Proceedings of the 2nd international ACM SIGPLAN conference on on Principles and practice of declarative programming, September 20-23, 2000, Montreal, Quebec, Canada view details
    Resources