Java virtual machine
A Java virtual machine is a virtual machine that enables a computer to run Java programs as well as programs written in other languages that are compiled to Java bytecode. The JVM is detailed by a specification that formally describes what is required of a JVM implementation. Having a specification ensures interoperability of Java programs across different implementations so that program authors using the Java Development Kit need not worry about idiosyncrasies of the underlying hardware platform; the JVM reference implementation is developed by the OpenJDK project as open source code and includes a JIT compiler called HotSpot. The commercially supported Java releases available from Oracle Corporation are based on the OpenJDK runtime. Eclipse OpenJ9 is another open source JVM for OpenJDK; the Java virtual machine is an abstract computer defined by a specification. The garbage-collection algorithm used and any internal optimization of the Java virtual machine instructions are not specified; the main reason for this omission is to not unnecessarily constrain implementers.
Any Java application can be run only inside some concrete implementation of the abstract specification of the Java virtual machine. Starting with Java Platform, Standard Edition 5.0, changes to the JVM specification have been developed under the Java Community Process as JSR 924. As of 2006, changes to specification to support changes proposed to the class file format are being done as a maintenance release of JSR 924; the specification for the JVM was published as the blue book, The preface states: We intend that this specification should sufficiently document the Java Virtual Machine to make possible compatible clean-room implementations. Oracle provides tests that verify the proper operation of implementations of the Java Virtual Machine. One of Oracle's JVMs is named the other, inherited from BEA Systems is JRockit. Clean-room Java implementations include Kaffe, IBM J9 and Skelmir's CEE-J. Oracle owns the Java trademark and may allow its use to certify implementation suites as compatible with Oracle's specification.
One of the organizational units of JVM byte code is a class. A class loader implementation must be able to recognize and load anything that conforms to the Java class file format. Any implementation is free to recognize other binary forms besides class files, but it must recognize class files; the class loader performs three basic activities in this strict order: Loading: finds and imports the binary data for a type Linking: performs verification and resolution Verification: ensures the correctness of the imported type Preparation: allocates memory for class variables and initializing the memory to default values Resolution: transforms symbolic references from the type into direct references. Initialization: invokes Java code that initializes class variables to their proper starting values. In general, there are two types of class loader: bootstrap class loader and user defined class loader; every Java virtual machine implementation must have a bootstrap class loader, capable of loading trusted classes.
The Java virtual machine specification doesn't specify. The JVM operates on primitive references; the JVM is fundamentally a 32-bit machine. Long and double types, which are 64-bits, are supported natively, but consume two units of storage in a frame's local variables or operand stack, since each unit is 32 bits. Boolean, byte and char types are all sign-extended and operated on as 32-bit integers, the same as int types; the smaller types only have a few type-specific instructions for loading and type conversion. Boolean is operated on with 0 representing false and 1 representing true; the JVM has a garbage-collected heap for storing arrays. Code and other class data are stored in the "method area"; the method area is logically part of the heap, but implementations may treat the method area separately from the heap, for example might not garbage collect it. Each JVM thread has its own call stack, which stores frames. A new frame is created each time a method is called, the frame is destroyed when that method exits.
Each frame provides an "operand stack" and an array of "local variables". The operand stack is used for operands to computations and for receiving the return value of a called method, while local variables serve the same purpose as registers and are used to pass method arguments. Thus, the JVM is both a register machine; the JVM has instructions for the following groups of tasks: The aim is binary compatibility. Each particular host operating system needs its own implementation of the runtime; these JVMs interpret the bytecode semantically the same way, but the actual implementation may be different. More complex than just emulating bytecode is compatibly and efficiently im
Inferno (operating system)
Inferno is a distributed operating system started at Bell Labs and now developed and maintained by Vita Nuova Holdings as free software. Inferno was based on the experience gained with Plan 9 from Bell Labs, the further research of Bell Labs into operating systems, languages, on-the-fly compilers, security and portability; the name of the operating system and many of its associated programs, as well as that of the current company, were inspired by Dante Alighieri's Divine Comedy. Inferno programs are portable across a broad mix of hardware and environments, it defines a virtual machine, known as Dis, that can be implemented on any real machine, provides Limbo, a type-safe language, compiled to portable byte code, more it includes a virtual operating system that supplies the same interfaces whether Inferno runs natively on hardware or runs as a user program on top of another operating system. A communications protocol called Styx is applied uniformly to access both local and remote resources, which programs use by calling standard file operations, read and close.
As of the fourth edition of Inferno, Styx is identical to Plan 9's newer version of its hallmark 9P protocol, 9P2000. Inferno was created in 1995 by members of Bell Labs' Computer Science Research division to bring ideas of Plan 9 from Bell Labs to a wider range of devices and networks. Inferno is a distributed operating system based on three basic principles drawn from Plan 9: Resources as files: all resources are represented as files within a hierarchical file system Namespaces: a program's view of the network is a single, coherent namespace that appears as a hierarchical file system but may represent physically separated resources Standard communication protocol: a standard protocol, called Styx, is used to access all resources, both local and remoteTo handle the diversity of network environments it was intended to be used in, the designers decided a virtual machine was a necessary component of the system; this is the same conclusion of the Oak project that arrived at independently. The Dis virtual machine is a register machine intended to match the architecture it runs on, as opposed to the stack machine of the Java Virtual Machine.
An advantage of this approach is the relative simplicity of creating a just-in-time compiler for new architectures. The virtual machine provides memory management designed to be efficient on devices with as little as 1 MiB of memory and without memory-mapping hardware, its garbage collector is a hybrid of reference counting and a real-time coloring collector that gathers cyclic data. The Inferno kernel contains the virtual machine, on-the-fly compiler, devices, protocol stacks, the name space evaluator for each process' file name space, the root of the file system hierarchy; the kernel includes some built-in modules that provide interfaces of the virtual operating system, such as system calls, graphics and math modules. The Bell Labs Technical Journal paper introducing Inferno listed several dimensions of portability and versatility provided by the OS: Portability across processors: it runs on ARM, SGI MIPS, HP PA-RISC, IBM PowerPC, Sun SPARC, Intel x86 architectures and is portable to others.
Portability across environments: it runs as a stand-alone operating system on small terminals, as a user application under Bell Plan 9, MS Windows NT, Windows 95, Unix. In all of these environments, Inferno programs see an identical interface. Distributed design: the identical environment is established at the user's terminal and at the server, each may import the resources of the other. Aided by the communications facilities of the run-time system, programs may be split between client and server. Minimal hardware requirements: it runs useful applications stand-alone on machines with as little as 1 MiB of memory, does not require memory-mapping hardware. Portable programs: Inferno programs are written in the type-safe language Limbo and compiled to Dis bytecode, which can be run without modifications on all Inferno platforms. Dynamic adaptability: programs may, depending on the hardware or other resources available, load different program modules to perform a specific function. For example, a video player might use any of several different decoder modules.
These design choices were directed to provide standard interfaces that free content and service providers from concern of the details of diverse hardware and networks over which their content is delivered. Inferno is a descendant of Plan 9, shares many design concepts and source code in the kernel around devices and the Styx/9P2000 protocol. Inferno shares with Plan 9 the Unix heritage from the Unix philosophy. Many of the command line tools in Inferno were Plan 9 tools. In the mid-1990s, Plan 9 development was set aside in favor of Inferno; the new system's existence was leaked by Dennis Ritchie in early 1996, after less than a year of development on the system, publicly presented that year as a competitor to Java. At the same time, Bell Labs' parent company AT&T licensed Java technology from Sun Microsystems. In March–April 1997 IEEE Internet Computing included an advertisement for Inferno networking software, it claimed that various devices could communicate over "any network" including the Internet, telecommunications and LANs.
The advertisement stated that video games could talk to computers,–a PlayStation was pictured–cell phones could access email and voice mail was available via TV. Lucent used
MacOS is a series of graphical operating systems developed and marketed by Apple Inc. since 2001. It is the primary operating system for Apple's Mac family of computers. Within the market of desktop and home computers, by web usage, it is the second most used desktop OS, after Microsoft Windows.macOS is the second major series of Macintosh operating systems. The first is colloquially called the "classic" Mac OS, introduced in 1984, the final release of, Mac OS 9 in 1999; the first desktop version, Mac OS X 10.0, was released in March 2001, with its first update, 10.1, arriving that year. After this, Apple began naming its releases after big cats, which lasted until OS X 10.8 Mountain Lion. Since OS X 10.9 Mavericks, releases have been named after locations in California. Apple shortened the name to "OS X" in 2012 and changed it to "macOS" in 2016, adopting the nomenclature that they were using for their other operating systems, iOS, watchOS, tvOS; the latest version is macOS Mojave, publicly released in September 2018.
Between 1999 and 2009, Apple sold. The initial version, Mac OS X Server 1.0, was released in 1999 with a user interface similar to Mac OS 8.5. After this, new versions were introduced concurrently with the desktop version of Mac OS X. Beginning with Mac OS X 10.7 Lion, the server functions were made available as a separate package on the Mac App Store.macOS is based on technologies developed between 1985 and 1997 at NeXT, a company that Apple co-founder Steve Jobs created after leaving the company. The "X" in Mac OS X and OS X is pronounced as such; the X was a prominent part of the operating system's brand identity and marketing in its early years, but receded in prominence since the release of Snow Leopard in 2009. UNIX 03 certification was achieved for the Intel version of Mac OS X 10.5 Leopard and all releases from Mac OS X 10.6 Snow Leopard up to the current version have UNIX 03 certification. MacOS shares its Unix-based core, named Darwin, many of its frameworks with iOS, tvOS and watchOS.
A modified version of Mac OS X 10.4 Tiger was used for the first-generation Apple TV. Releases of Mac OS X from 1999 to 2005 ran on the PowerPC-based Macs of that period. After Apple announced that they were switching to Intel CPUs from 2006 onwards, versions were released for 32-bit and 64-bit Intel-based Macs. Versions from Mac OS X 10.7 Lion run on 64-bit Intel CPUs, in contrast to the ARM architecture used on iOS and watchOS devices, do not support PowerPC applications. The heritage of what would become macOS had originated at NeXT, a company founded by Steve Jobs following his departure from Apple in 1985. There, the Unix-like NeXTSTEP operating system was developed, launched in 1989; the kernel of NeXTSTEP is based upon the Mach kernel, developed at Carnegie Mellon University, with additional kernel layers and low-level user space code derived from parts of BSD. Its graphical user interface was built on top of an object-oriented GUI toolkit using the Objective-C programming language. Throughout the early 1990s, Apple had tried to create a "next-generation" OS to succeed its classic Mac OS through the Taligent and Gershwin projects, but all of them were abandoned.
This led Apple to purchase NeXT in 1996, allowing NeXTSTEP called OPENSTEP, to serve as the basis for Apple's next generation operating system. This purchase led to Steve Jobs returning to Apple as an interim, the permanent CEO, shepherding the transformation of the programmer-friendly OPENSTEP into a system that would be adopted by Apple's primary market of home users and creative professionals; the project was first code named "Rhapsody" and officially named Mac OS X. Mac OS X was presented as the tenth major version of Apple's operating system for Macintosh computers. Previous Macintosh operating systems were named using Arabic numerals, as with Mac OS 8 and Mac OS 9; the letter "X" in Mac OS X's name refers to a Roman numeral. It is therefore pronounced "ten" in this context. However, it is commonly pronounced like the letter "X"; the first version of Mac OS X, Mac OS X Server 1.0, was a transitional product, featuring an interface resembling the classic Mac OS, though it was not compatible with software designed for the older system.
Consumer releases of Mac OS X included more backward compatibility. Mac OS applications could be rewritten to run natively via the Carbon API; the consumer version of Mac OS X was launched in 2001 with Mac OS X 10.0. Reviews were variable, with extensive praise for its sophisticated, glossy Aqua interface but criticizing it for sluggish performance. With Apple's popularity at a low, the makers of several classic Mac applications such as FrameMaker and PageMaker declined to develop new versions of their software for Mac OS X. Ars Technica columnist John Siracusa, who reviewed every major OS X release up to 10.10, described the early releases in retrospect as'dog-slow, feature poor' and Aqua as'unbearably slow and a huge resource hog'. Apple developed several new releases of Mac OS X. Siracusa's review of version 10.3, noted "It's strange to have gone from years of uncertainty and vaporware to a steady annual supply of major new operating system releases." Version 10.4, Tiger shocked executives at Microsoft by offering a number of features, such as fast file s
Dalvik is a discontinued process virtual machine in Google's Android operating system that executes applications written for Android. Dalvik was an integral part of the Android software stack in the Android versions 4.4 "KitKat" and earlier, which were used on mobile devices such as mobile phones and tablet computers, more in some devices such as smart TVs and wearables. Dalvik is open-source software written by Dan Bornstein, who named it after the fishing village of Dalvík in Eyjafjörður, Iceland. Programs for Android are written in Java and compiled to bytecode for the Java virtual machine, translated to Dalvik bytecode and stored in.dex and.odex files. The compact Dalvik Executable format is designed for systems that are constrained in terms of memory and processor speed; the successor of Dalvik is Android Runtime, which uses the same bytecode and.dex files, with the succession aiming at performance improvements transparent to the end users. The new runtime environment was included for the first time in Android 4.4 "KitKat" as a technology preview, replaced Dalvik in versions.
Unlike Java VMs, which are stack machines, the Dalvik VM uses a register-based architecture that requires fewer more complex, virtual machine instructions. Dalvik programs are written in Java using the Android application programming interface, compiled to Java bytecode, converted to Dalvik instructions as necessary. A tool called. Multiple classes are included in a single.dex file. Duplicate strings and other constants used in multiple class files are included only once in the.dex output to conserve space. Java bytecode is converted into an alternative instruction set used by the Dalvik VM. An uncompressed.dex file is a few percent smaller in size than a compressed Java archive derived from the same.class files. The Dalvik executables may be modified again. In order to gain further optimizations, byte order may be swapped in certain data, simple data structures and function libraries may be linked inline, empty class objects may be short-circuited, for example. Being optimized for low memory requirements, Dalvik has some specific characteristics that differentiate it from other standard VMs: The VM was slimmed down to use less space.
The constant pool has been modified to use only 32-bit indices to simplify the interpreter. Standard Java bytecode executes 8-bit stack instructions. Local variables must be copied to or from the operand stack by separate instructions. Dalvik instead uses its own 16-bit instruction set; the local variable is picked by a 4-bit "virtual register" field. This raises its interpreter speed. According to Google, the design of Dalvik permits a device to run multiple instances of the VM efficiently. Android 2.2 "Froyo" brought trace-based just-in-time compilation into Dalvik, optimizing the execution of applications by continually profiling applications each time they run and dynamically compiling executed short segments of their bytecode into native machine code. While Dalvik interprets the rest of application's bytecode, native execution of those short bytecode segments, called "traces", provides significant performance improvements; the relative merits of stack machines versus register-based approaches are a subject of ongoing debate.
Stack-based machines must use instructions to load data on the stack and manipulate that data, thus, require more instructions than register machines to implement the same high-level code, but the instructions in a register machine must encode the source and destination registers and, tend to be larger. This difference is of importance to VM interpreters, for which opcode dispatch tends to be expensive, along with other factors relevant to just-in-time compilation. Tests performed on ARMv7 devices in 2010 by Oracle with standard non-graphical Java benchmarks showed the HotSpot VM of Java SE embedded to be 2–3 times faster than the JIT-based Dalvik VM of Android 2.2. In 2012, academic benchmarks confirmed the factor of 3 between HotSpot and Dalvik on the same Android board noting that Dalvik code was not smaller than Hotspot. Furthermore, as of March 2014, benchmarks performed on an Android device still show up to a factor 100 between native applications and a Dalvik application on the same Android device.
Upon running benchmarks using the early interpreter of 2009, both Java Native Interface and native code showed an order of magnitude speedup. Dalvik is published under the terms of the Apache License 2.0. Some say that Dalvik is a clean-room implementation rather than a development on top of a standard Java runtime, which would mean it does not inherit copyright-based license restrictions from either the standard-edition or open-source-edition Java runtimes. Oracle and some reviewers dispute this. On August 12, 2010, which acquired Sun Microsystems in April 2009 and therefore owns the rights to Java, sued Google over claimed infringement of copyrights and patents. Oracle alleged that Google, in developing Android, knowingly and infringed Oracle's Java-related intellectual property. In May 20
In computer science, computer engineering and programming language implementations, a stack machine is a type of computer. In some cases, the term refers to a software scheme; the main difference from other computers is that most of its instructions operate on a pushdown stack of numbers rather than numbers in registers. Most computer systems link to subroutines; this does not make these computers stack machines. The common alternative to a stack machine is a register machine, in which each instruction explicitly names specific registers for its operands and result. A "stack machine" is a computer that uses a last-in, first-out stack to hold short-lived temporary values. Most of its instructions assume that operands will be from the stack, results placed in the stack. For a typical instruction such as Add the computer takes both operands from the topmost values of the stack; the computer replaces those two values with the sum, which the computer calculates when it performs the Add instruction. The instruction's operands are "popped" off the stack, its result are "pushed" back onto the stack, ready for the next instruction.
Most stack instructions have only an opcode commanding an operation, with no additional fields to identify a constant, register or memory cell. The stack holds more than two inputs or more than one result, so a richer set of operations can be computed. Integer constant operands are pushed by separate Load Immediate instructions. Memory is accessed by separate Load or Store instructions containing a memory address or calculating the address from values in the stack. For speed, a stack machine implements some part of its stack with registers. To execute operands of the arithmetic logic unit may be the top two registers of the stack and the result from the ALU is stored in the top register of the stack; some stack machines have a stack of limited size, implemented as a register file. The ALU will access this with an index; some machines have a stack of unlimited size, implemented as an array in RAM accessed by a "top of stack" address register. This is slower, but the number of flip-flops is less, making a less-expensive, more compact CPU.
Its topmost N values may be cached for speed. A few machines have both an expression stack in a separate register stack. In this case, software, or an interrupt may move data between them; the instruction set carries out most ALU actions with postfix operations that work only on the expression stack, not on data registers or main memory cells. This can be convenient for executing high-level languages, because most arithmetic expressions can be translated into postfix notation. In contrast, register machines hold temporary values in a fast array of registers. Accumulator machines have only one general-purpose register. Belt machines use a FIFO queue to hold temporary values. Memory-to-memory machines do not have any temporary registers usable by a programmer. Stack machines may have their expression stack and their call-return stack separated or as one integrated structure. If they are separated, the instructions of the stack machine can be pipelined with fewer interactions and less design complexity.
It can run faster. Some technical handheld calculators use reverse Polish notation in their keyboard interface, instead of having parenthesis keys; this is a form of stack machine. The Plus key relies on its two operands being at the correct topmost positions of the user-visible stack. Stack machines have much smaller instructions than the other styles of machines. Loads and stores to memory are separate and so stack code requires twice as many instructions as the equivalent code for register machines; the total code size is still less for stack machines. In stack machine code, the most frequent instructions consist of just an opcode selecting the operation; this can fit in 6 bits or less. Branches, load immediates, load/store instructions require an argument field, but stack machines arrange that the frequent cases of these still fit together with the opcode into a compact group of bits; the selection of operands from prior results is done implicitly by ordering the instructions. In contrast, register machines require two or three register-number fields per ALU instruction to select operands.
The instructions for accumulator or memory-to-memory machines are not padded out with multiple register fields. Instead, they use compiler-managed anonymous variables for subexpression values; these temporary locations require extra memory reference instructions which take more code space than for the stack machine, or compact register machines. All practical stack machines have variants of the load–store opcodes for accessing local variables and formal parameters without explicit address calculations; this can be by offsets from the current top-of-stack address, or by offsets from a stable frame-base register. Register machines handle this with a register + use a wider offset field. Dense machine code was valuable in the 1960s, when main memory was expensive and limited on mainframes, it became important again on the initially-tiny memories of minicomputers and microprocessors. Density remains important today, for smartphone applications, applications downloaded into browsers over slow Internet connections, in ROMs for embedded applications.
A more general advantage of increased density is improved effectiveness of caches and instruction prefetch. Some of the density of Burroughs B6700 code was due to moving vital operand information elsewhere