Glossary

This page gives working definitions for common terms that we use in the JNode documentation. While we will try to be consistent with terminology used in other places, we reserve the right to be inconsistent.

Java Virtual Machine

A Java Virtual Machine (JVM) is an execution engine for Java programs. A JVM 'executes' bytecodes using various techniques including bytecode interpretation and compilation to / execution of native code.

Native Code Compiler

A native code compiler is a compiler that translates a program to native code; i.e. instructions in the instruction set of a physical machine. In the JNode context, the input to the native compiler consists of Java bytecode files.

Native Compiler

Short for "native code compiler".

Bytecode Compiler

A bytecode compiler is a compiler that translates to Java bytecode files. The input to a bytecode compiler could be Java source code or (in theory) source code in some other programming language.

JIT Compiler

A JIT compiler or "Just-in-time" compiler is a native compiler that compiles code at or after class load time. The JNode native code compilers operate as JIT compilers when they run on JNode, and as ahead-of-time (non-JIT) compilers when they used in the build environment to compile code for the JNode boot image.

Hotspot (tm)

Hotspot is the name of a family of Sun Java virtual machines; see this Wikipedia page.

Hotspot

A hotspot is method or section of code that is determined (by profiling) to be executed very frequently. A profiler-based JIT compiler will typically focus on compiling hotspot methods to native code.

Boot Image

This is the memory image loaded by a bootstrap loader to start an operating system such as JNode.

Boot Image Builder

The JNode boot image builder creates the JNode boot image as described on the Build Process page.

Garbage Collector

The system component that is responsible for reclaiming memory resources for Java objects that have become unreachable.

Plugin

An assembly of related classes that are loaded and unloaded together. JNode's plugin mechanism is described in the Plugin Framework page.

Plugin descriptor

An XML file that defines the metadata for a plugin and lists its dependencies and exports. A plugin descriptor may also list security permissions granted to classes in the plugin, command aliases and syntaxes, and various plugin-specific configuration information.

Driver

A driver is an operating system component that adapts an abstract service API to a particular technology. In JNode, we have "device drivers" that adapt the Device API to hardware devices, file system drivers that adapt the FileSystem APIs for specific file system types, network drivers, frame-buffer drivers and so on.

Binary Device Driver

JNode does not support vendor-supplied binary device drivers as a matter of principle. So don't bother asking!

Service

A service is a JNode object that performs some important operating system level function. JNode services are typically located using the InitialNamingService.

Manager

A manager is a JNode service that manages a collection of resources. For example, the DeviceManager manages the Device instances that have been configured.

Console

A console is an abstraction that combines a keyboard and a character oriented display to provide an analog for an old-style "terminal".

Console mode

This describes the system state where the (PC) display is in VGA mode, showing an array of (typically) 24x80 fixed width characters.

Virtual console

In console mode, JNode supports a number of virtual consoles that are mapped to the physical keyboard and the display. ALT-Fn is used to switch between virtual consoles.

Shell

A shell is a JNode object that provides a keyboard-oriented interface for entering commands to be run.

Command class

A command class is a Java class with an entry point method that allows a Java application to be run from a command line or script.

Command Interpreter

A command interpreter is an object that a JNode shell uses to split command input (and scripts) into commands, and manage their execution. JNode supports multiple command interpreters with different levels of functionality. Command interpreters variously handle such things as stream redirection, setting and expansion of shell variables, file pattern expansion, compound command handling and shell function execution.

Command Invoker

A command invoker is an object that a JNode shell uses to run a command class. There are a number of different invokers that run commands in different ways; e.g. in a new Java Thread, a new Proclet or a new Isolate.

Isolate

The Isolate mechanism allows applications to be run in JNode that shields them from unwanted affects of other applications. A command or application that is run an isolate appears to be running in its own JVM. Isolates can be safely suspended, resumed and killed. JNode's implementation of Isolates is not yet complete.

Proclet

The Proclet mechanism is a JNode specific alternative to Isolates that tries to provide applications with the illusion that they "own" some key bits of global state; i.e. the System.in,out,err streams, the System Properties object and the System Environment object. Since, the illusion is not perfect, we are likely to de-support proclets when the isolate implementation is completed.

Alias

An alias is a short name for a command class that is used run it from the command line. For example, "cat" is an alias for "org.jnode.shell.command.CatCommand". Aliases are typically defined in the plugin descriptor file for the command classes plugin.

Command Syntax

JNode native commands typically rely on the Command Syntax subsystem to parse the arguments passed to the command. A command registers an abstract syntax for its arguments, and a concrete syntax is defined as a separate XML fragment / file. Common libraries do the work of parsing the arguments, and also provide context sensitive argument completion and command help.

Unsafe

Unsafe is a special JNode class (implemented in assembler) that performs certain low-level tasks such as reading and writing to hardware IO ports, and handling low-level 'debug' output; see "kdb".

Magic

Magic classes are special classes recognized by the JNode native compiler. These classes typically circumvent the Java type system in some way.

MagicPermission

Only classes that are granted this permission may call methods on Magic classes. Examples of classes that require magic permission include hardware device drivers and the heap managers.

NanoKernel

This term is historically used to refer to that tiny part of the JNode core which is implemented in x86 assembler. This code mostly deals with bootstrapping and writing to the serial port. The JNode NanoKernel is not a real "nano-kernel" in the conventional sense of the word.

kdb

The "kdb" or Kernel DeBugger is JNode NanoKernel functionality that redirects all output from "Unsafe.debug(...)" calls to the serial port. It is used for debugging via low-level system trace-prints and for capturing output from kernel panics. (It is not really a debugger in the conventional sense.)

Multiboot

The Multiboot specification is defacto standard for booting operating systems that is supported by many boot loaders and operating systems. JNode's boot image is multiboot compatible.

Please feel free to add extra terms or offer better definitions as comments.