>From owner-simulators Wed Aug 16 13:39:15 1995 Received: from meitner.cs.washington.edu (meitner.cs.washington.edu [128.95.2.104]) by june.cs.washington.edu (8.6.12/7.2ju) with ESMTP id NAA28606; Wed, 16 Aug 1995 13:39:15 -0700 Received: from localhost (localhost [127.0.0.1]) by meitner.cs.washington.edu (8.6.12/7.2ws+) with SMTP id NAA30750; Wed, 16 Aug 1995 13:39:14 -0700 Message-Id: <199508162039.NAA30750@meitner.cs.washington.edu> To: rtcg@cs, simulators@cs Subject: Colusa Omniware -- dynamic compilation of 3-address VM code + SFI Date: Wed, 16 Aug 1995 13:39:14 PDT From: " pardo@cs.washington.edu" X-Message-Id: simulators@cs.washington.edu, message #1995-08-008 X-Unsubscribe: e-mail `majordomo@cs.washington.edu', body `unsubscribe simulators' X-URL: `pending' [Summary: 3-address VM code with optional static register allocation is dynamically compiled to native machine code and runs in a software-enforced protetection domain. Compilation and domain code rewriting is fast, and the resulting code is asymptotically 5% slower than native machine code.] %Q Colusa Software %T Omniware: A Universial Substrate for Mobile Code %R Colusa Software White Paper, available via WWW URL ``http://www.colusa.com/html/omni_www.html'' as of August 1995 %D 1995 %P 13 %X ``Omniware'' defines a virtual machine code and API for executing code on a variety of machines. Virtual machine code is dynamically checked to ensure safety and dynamically compiled to host machine native code. Goal is to make portable anything that can be compiled to machine code or which (transitively) has a machine code interpreter. On a SPARC, benchmarks are about 10% slower than unchecked optimized dynamically-linked C. RTCG interest: dynamic compilation of VM code to achieve portability, software protection domains for safety. 3-address VM code, static register allocation allowed but not required to reduce runtime register allocation overhead. Small compile times, probably due to close match between VM and host n-code. Asymptoticly 5% slower than unchecked nonportable code, possibly due to close match between VM and host n-code. ABSTRACT: ``... Omniware [is] a system for producing and executing mobile code [which] will be used ... to specify dynamic behavior in Web pages, implement new Web protocols and data formats, and dynamically distribute computations between servers and browsers. Like all mobile code systems, Omniware provides portability and safety. The same compiled Omniware module can be executed transparently on different machines, and a module's access to host resources can be precisely controlled. ... Omniware has two unique features. First, Omniware is open [supporting] standard programming languages, enabling Web developers to leverage the vast store of existing software and programming expertiese [and it is] a straightfoward compilation target for a large variety of source languages. Second, Omniware is fast [and on a SPARCstation 5, 5 SPEC92 benchmarks plus lcc, Tcl and TeX benchmarks] ran within 9% of native performance [compared to dyanmically-linked equivalents compiled to native machine code; they are also an average 40% smaller.]'' (pg 2) OmniVM executes arbitrary programs, so programmers don't need to learn new languages, and programmers can incorporate ``legacy'' code. (pg 3) Applications use Omniware by statically linking to the ORE runtime environment [Why statically and not dynamically? -Pardo], which provides an API for loading, unloading, executing and controlling Omniware modules. Omniware modules are built by standard compilers, targeted for OmniVM. The application explicity exports resources to the Omniware modules using ORE; all exported routines should check all arguments [and, presumably, data structures exported writably should assume they may be updated at any time -Pardo]. (pg 4) Currently compiler for K&R C, ANSI C, C++ targeted to OmniVM. (pg 4) Interpreted languages can use an interpreter that is compiled as an Omniware module [But since they use SFI and SFI doesn't currently handle instruction-space changes, can't interepreters that are implemented as dynamic compilers. -Pardo]. (pg 5-7) OmniVM instruction-set architecture (ISA) is a RISC with infinite pseudoregisters, complex addressing modes (used only by load/store instructions) plus a few CISCy instructions like `mov.b', a memory-to-meory block move. (pg 7) The static compiler may perform register allocation to a fixed number of registers (e.g. 24), freeing the dynamic compiler from register allocation except for host machines with fewer physical registers (e.g., the iX86 family). Floating-point is IEEE. (pg 6) Goal: if an Omniware program runs correctly on one platform it should run correctly on all platforms. Thus, data formats are fixed across all machines. Byte order is undefined but can use OmniVM instructions and/or predefined (environment) globals to discover the byte order. (pg 7-8) Protection via a segmented architecture. Segement size depends on the host. ORE interface commands let an application dictate where Omniware modules will be loaded. A host can thus load multiple modules into one segment (protection domain) so they all share access permissions. [Presumably, one module can have access to multiple segments. -Pardo] Segments are implemented using SFI [Wahbe et al. 91: Software-Based Fault Isolation]. (pg 9) Compare size and performance of Omniware modules against dynamically-linked SPARC binaries compiled using SUNPRO at highest level of optimization. Benchmarks are SPEC92 alvinn, ear, compress, exlisp and gcc. Also use lcc, tcl and TeX. (pg 9-10) Sizes: unweighted average 38% smaller. [However, guessing based on [Lucco, et al. 94: Adaptable Binary Programs] Omniware probably uses compression, so the whole binary will see less compression than would the SPARC binary. -Pardo] (pg 9-10) Benchmark running times 4-1000s, Omniware average 10% slower, including dynamic compile and SFI time. [The OmniVM code was probably compiled using register allocation; on an iX86 the dynamic compiler would also need to reallocate registers. Given the OmniVM instruction set, compilation on the SPARC probably amounts to sophisticated transliteration. Some compilation costs are masked by dynamic linking overheads on the SPARC version. Under SunOS 4.1.x, dynamic linking adds about 150,000 instructions to whole-program startup and each new link traversal costs about 4,500 instructions. Unclear to Pardo which costs are being measured. -Pardo] For the 3 longest-running programs (50, 300 and 1,000 seconds) the average slowdown is smaller, only 5%. (pg 11) Related work includes: ``[C]urrent estimates are that Java programs run 1200% to 3000% ... slower than native code. ... Certain features of the virtual machine, such as array bounds checking, stack based operations, and garbage collection will make it difficult to implement efficiently [even using dynamic compilation] [GC84, GC93, Bounds92, Interp77]''; Java can be compiled to OmniVM instructions and/or the Java interpreter could be compiled to OmniVM. The Guile project at Cygnus [Guile95]; Telescript [Telescript93]; Safe-Python, a modified version of Python; Safe-Tcl [Safe-Tcl94]. [Bounds92] J. L. Stefen, ``Adding Run-Time Checking to the Portable C Compiler,'' Software-Practice anad Experience, April 1992, vol. 22, no. 4, pp. 305-16. [GC84] R. Brooks, ``Trading Data Space for Reduced Time and Code Space in Real-Time Garbage Collection on Stock Hardware,'' ACM Software Engineering Symposium on Practical Software Development Environments, 1984, pp. 256-262. [GC93] B. Zorn, ``The Measured Cost of Conservative Garbage Collection,'' Software-Practice and Experience, vol. 23, no. 7, July 1993, pp. 733-56. [Guile95] T. Lord, ``The Guile Architecture for Ubiquitous Computing,'' to appear in Usenix Tcl/Tk Workshop, 1995 [Interp77] J. P. Fitch and A. C. Norman, ``Implementing LISP in a High-Level Language,'' Software-Practice and Experience, vol. 7, 1977, pp. 713-725. [Safe-Tcl94] N. S. Borenstein. ``Email With a Mind of its Own: The Safe-Tcl Language for Enabled Mail,'' IFIP International Conference, Barcelona, Spain, June 1994. [Telescript93] ``Telescript Technology: The Foundation for the Electronic Marketplace,'' General Magic: Sunnyvale, CA, 1993.