A Java virtual machine (JVM) is a virtual machine that enables a computer to run Java programs.

 The Java Virtual Machine (JVM) forms the heart of the Java Runtime Environment (JRE). It enables Java applications to execute on any device or operating system without needing to be rewritten or recompiled—delivering the well-known "Write Once, Run Anywhere" (WORA) promise. Here’s how the process typically works:

• Developers write Java code in .java source files  

• The javac compiler translates this code into platform-independent bytecode stored in .class files  
• The JVM then takes over: it loads the bytecode, performs verification and linking, and begins execution  
• During runtime, the JVM can either interpret the bytecode instruction by instruction or use a Just-In-Time (JIT) compiler to translate frequently executed (“hot”) code into fast native machine instructions  

• FIG.1: Inside the Java Virtual Machine for BD-J

  In parallel, the JVM’s garbage collector automatically frees up memory occupied by objects that are no longer reachable

This combination of bytecode portability, dynamic optimization, and automatic memory management is what makes Java both flexible and efficient across diverse hardware environments.

The BD-J version of the virtual machine is built upon the Connected Device Configuration (CDC) and Personal Basis Profile (PBP) of Java ME, customized specifically for Blu-ray Disc players to run Java-based applications smoothly on devices with limited processing power and memory. It adheres to standards like GEM 1.0.2 and Java TV 1.1, and uses class files compatible with Java 1.3. This VM starts up once for each disc insertion (or title/session), managed by the player's runtime environment. 

This virtual machine is launched once per disc session by the player's runtime system, ensuring isolation for each Blu-ray title and preventing interference between applications from different discs.

Blu-ray player manufacturers make their own implementations of the JVM, and Oracle/BDA certifies the device's Java implementation that meets the spec and uses Java technology legitimately.

The Java virtual machine loads the xlet program that constitutes an application onto the work memory, decodes the Xlet program, and controls the lower layers based on the decoding results. More specifically, in the control of the lower layers, the Java virtual machine issues a Java Media Framework (JMF) method to a BD middleware (not illustrated) so that a function call corresponding to the BD playback device replaces the existent function call, and issues the function call after replacement to the playback control engine. BD-J also incorporates APIs from HAVi for UI rendering and org.bluray/davic packages for resource and media control. 

User Class Loader

The user class loader retrieves class files from JAR archives located in the JAR directory—either from local memory or equivalent storage—and loads them into the method area of the Java virtual machine.This class loading process is triggered when the application manager instructs the user class loader to load a specific class file by providing its file path.  

•  If the specified path points to local memory, the user class loader reads the class file directly from the corresponding JAR file that makes up the application and transfers it into work memory.  
• If the path refers to a location within the virtual file system, the user class loader retrieves the class file from a JAR archive stored on the BD-ROM or in local storage and copies it into work memory.

In both cases, the user class loader handles the actual reading and initial placement of the class file into runtime memory.

Method Area

The method area stores the class files read by the user class loader from the local memory.

Work Memory

The work memory functions as the heap area in the Java runtime environment, where instances of classes are dynamically allocated and stored during program execution.

Within this heap reside two permanently loaded (resident) system components: the application manager and the event listener manager, both of which remain in memory throughout the lifetime of the BD-J application environment (for disc-bound components).

In addition to these resident objects, the work memory holds runtime instances created from the class files previously loaded into the method area. These instances primarily consist of Xlet objects—the executable components that make up individual BD-J applications.

Once the necessary Xlet instances have been instantiated and placed in the work memory, the corresponding application reaches a state where it is fully prepared for execution.

Java Threads

Java Threads (or Threads) serve as the logical units of execution within the Java virtual machine. They are responsible for running the methods (code) whose instances reside in the work memory (heap).

Each thread performs computations by taking operands from:

• the local variable array of its current frame, or
• the operand stack of that frame.

After performing the operation, the thread stores the result back into either the local variables or the operand stack, depending on the instruction.

(The application manager and event listener manager, being long-lived objects, are executed by threads in the same way as any other instances.)

The number of concurrent threads is limited by the player's hardware resources, such as memory and CPU capabilities, rather than a fixed hard limit.

As long as resources allow, the system is free to:

• create new threads when needed, or
• terminate existing ones.

During normal operation of the Java virtual machine, the number of active threads can therefore rise or fall dynamically. 

This ability to spawn additional threads on demand makes it possible to execute a single object’s methods (or different parts of the same application logic) in parallel across multiple threads, which can significantly improve performance and responsiveness.

Java Stacks

Each Java thread is associated with its own dedicated Java stack on a one-to-one basis. Every Java stack contains a program counter and a sequence of frames.

• The program counter points to the currently executing instruction within a method instance.
• A frame is created for each method invocation and pushed onto the stack. Each frame consists of two main components:
  • an operand stack, which holds temporary values such as method arguments and intermediate computation results;
  • a local variable array, which stores the method’s local variables.

Because a new frame is pushed onto the Java stack for every method call—including recursive calls to the same method—the stack grows to reflect the current call chain.

When a JMF player instance invokes one of its playback methods, or when the application executes a JumpTitle API call, a corresponding frame is pushed onto the Java stack. Among the information passed as arguments and stored in the operand stack of these frames are:

• (i) the filenames of  .mpls playlist files that the playback method is instructed to reproduce;
• (ii) the title IDs specifying the target titles for JumpTitle operations;
• and similar control data required for playback or navigation.

This mechanism ensures that method parameters related to Blu-ray disc playback and title jumping are properly managed within the Java runtime environment.

How the Application Manager Operates within the JVM

When the module manager emits an activate(bobj_id) event to request activation of the BD-J Object identified by bobj_id, the application manager—a resident instance residing in work memory—immediately designates the BD-J Object matching that bobj_id as the current one.

The application manager then compares:

• the execution status of applications in the branch source Title, and  
• the run attributes and lifecycle bindings defined for applications in the current BD-J Object.

From this comparison, it decides two things:
(i) which applications must be automatically started, and
(ii) which applications must be automatically terminated.

① Auto-start determination
The application manager scans the application management table (AMT) of the current BD-J Object, looking for any apli_id_ref that satisfies both conditions:  

• the application is not running in the source Title, and  
• it has the AutoRun attribute in the current Title.

When such an apli_id_ref is found, the application manager directs the user class loader to load the relevant class files from the application’s JAR archive(s). This causes the corresponding Xlet instances to be created in work memory, preparing the application—whose lifecycle is bound to the current Title—for execution. Actual startup occurs when threads begin invoking the application’s methods.

② Auto-termination determination
Similarly, the application manager searches the same table for any apli_id_ref where:  

• the application is currently running in the source Title, but  
• has no lifecycle defined in the current Title.

Upon locating such an entry, the application manager forces termination of the corresponding Xlet program. This action frees up critical resources previously consumed by the terminated application, including:  

• occupied regions in work memory, and  
• frames on the Java stacks that were allocated during method execution.

Through this coordinated process, the application manager ensures that only the appropriate applications are active after each title boundary crossing, maintaining efficient resource usage and correct behavior across the BD-J title structure.

How the PLMT Processor Operates within the JVM (Patented Enhancement)

Note: The following describes a proprietary enhancement from U.S. Patent US7627233B2 (Panasonic), which is not part of the standard BD-J specification. In core BD-J, playlist control is typically handled manually by applications via APIs, without automatic table-based management. This patented system adds reliability by automating playlist transitions, especially to handle app loading delays or failures.

The PLMT processor, a dedicated sub-component of the application manager, evaluates the playback state from the branch source Title alongside the playback attributes recorded for playlists in the current Title. From this comparison, it decides two actions:

• (i) which PlayList should be automatically started, and
• (ii) which PlayList should be automatically stopped.

① Auto-play determination
The PLMT processor scans the PlayList Management Table (PLMT) of the current Title, searching for any PlayList that meets both of the following criteria:  

• it is not currently playing in the source Title, and  
• it carries the AutoPlay attribute in the current Title.

When such a PlayList is identified (via its Pl_id_ref), the PLMT processor issues a playback function call (typically PlayPL) to the playback control engine, passing the matching Pl_id_ref as an argument.  

This function call results in:  

• a new frame being pushed onto the Java stack(s), with the Pl_id_ref stored in the frame’s operand stack as an argument;  
• the active thread(s) executing the playback method;  
• the presentation engine receiving the instruction and commencing playback of the designated PlayList.

② Auto-stop determination
Conversely, the PLMT processor searches the same PlayList Management Table for any PlayList that: 

• is actively playing in the branch source Title, but  
• is not listed at all in the PlayList Management Table of the current Title (i.e., has no lifecycle or playback binding in the destination Title).

Upon locating such a PlayList, the PLMT processor:  

• issues a stop playback function call to halt reproduction of that PlayList, and  
• removes the corresponding playback-related frames (those created for the PlayPL invocation) from the Java stacks, thereby freeing the associated stack memory.

Through these coordinated checks and function calls, the PLMT processor ensures seamless and correct PlayList transitions whenever control moves from one Title to another during BD-J disc playback.

Author(s) : Æ Firestone