Download Long Version

Document related concepts
no text concepts found
Transcript
Embedded Java Research
Geoffrey Beers
Peter Jantz
December 18, 2001
General Java Overview
Robust object-oriented language developed
by Sun Microsystems in 1995.
 Basic idea was to create a language that can
run on any platform

– Even early Java models and development
considered the future of embedded system
programming.

“Write-once, run anywhere” ideology.
Typical Hardware View of Java Applications
ApplicationProgram.java
Java API
Java Virtual Machine
Hardware-Based Platform
}
Java
Platform
Embedded Java Application Environment
Taken from Sun Microsystems
Embedded Java Application
Environment

Unlike traditional Java packages, the
Embedded Java environment is far more
configurable.
– Do we really need I/O?
– What packages do we really need?
– Is a GUI required?

Ability to have all standard JDK
components (except Applet), with the
ability to only use what is necessary.
Advantages of the Java
Technology Model

Simplicity
– Easier language to learn than traditional C/C++ and still
has object-oriented methodology.

Security and Safety
– Java programs have more robust security checking,
with the RTE creating a “sandbox” where applications
can run safely.
– Lack of pointers eliminates direct memory access

Portability and Robust Distribution
– Applications can be easily developed on desktop
systems and ported, with minimal effort, to target
device.
– “Write-once, run anywhere” mentality.
Disadvantages of Embedded Java

Huge speed disadvantage. Interpreted Java code is
still 5-10 times slower than a similar C
application.
– Improvements made to JVM technology have enhanced
this over the years.
– Often based on how the application is written
» A well-written Java program can out-perform a poorly written
C program
– For embedded applications do we really need to
interpret code, or can we use native-compiled code?
Disadvantages of Embedded Java


Embedded Java technology still relatively new and
industry support has been slow to catch-on.
Biggest disadvantage: Lack of RTOS support or
standard
– Early embedded Java applications were very similar to
conventional desktop programs. Fine for some apps,
but deadline control and interrupt handling are
necessary.
– Great improvement in this genre since 1998.
Pouring Java into Embedded
Device Development
Some of the features that have made Java an excellent
choice for desktop programming cause problems on an
embedded system. Most of these problems have
solutions as well as trade-offs.
Problem
Solution
Trade-off
Not as fast as C
or Assembly
Native-compiled code (AOT Loss of portability
compiler)
Unpredictable
timing
New garbage collection
More control
algorithm and better memory means more
management control.*
responsibility
Cannot directly
control hardware
Native hardware interfaces
Development may
require multiple
languages
*Support for this has been greatly improved through RTSJ
Challenges of Embedded Java
Memory Requirements
 Execution speed
 Garbage collection and memory
management
 Real-time OS support

Typical Memory Requirements of
Java Systems
Minimum
Medium
High-end
Processor
< 100 MHz
< 8K I/D cache
100 – 200 MHz
< 8K I/D cache
200 MHz +
32K + I/D cache
Memory
2 MB ROM
2 MB RAM
2-4 MB ROM
4-8 MB RAM
> 8 MB ROM
> 16 MB RAM
Real-time Java Issues
Necessary to handle hard and soft deadline
constraints.
 Support for timely execution of tasks and
interrupt routines
 Thread priorities and locking
 Garbage collection and the embedded
model.

– How do we know we’re not going to use the
dynamic memory again?
Garbage Collection



Garbage collection (GC) is great idea for larger
system development, but can create major
problems in an embedded environment.
Major problem for hard real-time systems.
Early solution: Avoid GC altogether.
– Allocate memory dynamically, but never delete. If it’s
not needed again, waste space, but will be available if
needed.

PERC handles GC rather well; RTJS also defines a
GC standard.
Early Real-Time Considerations
Although Java had enormous potential as an
embedded system development tool, the
real-time issues were still a reality.
 Ideally, needed a way to control garbage
collection and optimize memory.
 Considerations for real-time threads and
scheduling models.
 These considerations introduced as early as
1995.

Real-Time Specification for Java



Real-time embedded issues invoked need for RT
Java specification.
PERC has been developing real-time Java API
extensions since 1997, but still a need for
organized structure and universal standard.
Java Community Process formed in 1998 to
resolve some of the real-time issues and come to a
standard.
– Standard known as Real-Time Specification for Java
(RTSJ), and was officially completed in Nov. 2001
RTSJ Guiding Principles

Applicability to particular Java environments.
– Do not include specs that restrict use to a particular
Java environment.

Backward compatibility
– RTSJ shall not prevent existing, non real-time Java
programs, from executing on implementations of the
RTSJ.

“Write once, run anywhere” mentality should be
followed as much as possible.
RTSJ Guiding Principles (cont.)


RTSJ should address real-time system practice and
allow for the incorporation of advanced features in
the future.
Predictable execution as first priority in all
tradeoffs.
– May come at expense of general-computing
performance, but will allow for greater real-time
integration.

No syntactic extension
– RTSJ will not introduce new keywords or other
syntactic extension to the Java language.
Real-Time Specification for Java
Finalized in November 2001.
 Standard specification for garbage
collection, memory management, and
task/thread control.
 Additional classes and extensions to
standard Java JDK.

– However, no new syntax was necessary.
javax.realtime Package
Real-time specification provides
modifications to the Java Language Spec.
and JVM Spec.
 New APIs to enable the creation,
verification, analysis, execution, and
management of real-time Java threads.
 New APIs in a standard extension package,
javax.realtime.

Seven Areas of Enhancement
Thread scheduling and dispatching
 Memory management
 Synchronization and resource sharing
 Asynchronous event handling
 Asynchronous transfer of control
 Thread termination
 Physical memory access

Thread Scheduling and Dispatching


Programmatic assignment of parameters
appropriate for the underlying scheduling
mechanism in use.
Creation, management, admittance, and
termination of real-time Java threads.
– Threads are constructed as instances of class
javax.realtime.RealtimeThread, which extends
java.lang.Thread.

Flexibility in thread scheduling framework allows
future specifications to build on the RTSJ.
Thread Scheduling (Cont.)
Base-scheduling mechanism is preemptive,
priority-based FIFO.
 At least 28 unique priority levels.
 Threads waiting to acquire a resource must
do so in execution eligibility order.

Memory Management

RTSJ introduces concept of memory area.
– Area of memory used for the allocation of objects.


Some memory areas exist outside of the heap and
place restrictions on what the system and garbage
collector may do with objects allocated within.
Objects in some memory areas are never garbage
collected.
– Garbage collector must be capable of scanning these
memory areas for references to any object within the
heap to preserve the integrity of the heap.
Four Memory Areas

Scoped Memory
– Objects have lifetime defined by syntactic scope.

Physical Memory
– Objects created within specific physical memory
regions having certain characteristics.

Immortal Memory
– Objects cannot be destroyed; once allocated they stay
until the end of the application.

Heap Memory
– Objects represent an area of memory on the heap.
Memory Class Hierarchy
VTMemory
Object
HeapMemory
LTMemory
MemoryArea
ScopedMemory
ScopedPhysicalMemory
ImmortalMemory
ImmortalPhysicalMemory
PhysicalMemoryFactory
RawMemoryAcess
RawMemoryFloatAcess
Taken from Prof. Insup Lee, Univ. Penn.
Memory Management

Immortal Memory Area
– One ImmortalMemory object per JVM.
– Used for sharing between real-time threads.
– No control in the program can ever leave the
immortal memory.

Scoped Memory Area
– Associated with one or more scopes.
– Scopes may have more than one associated
memory area.
Synchronization and Resource Sharing
Implementations of the current keyword
“synchronized” include one or more
algorithms that prevent or bound execution
eligibility inversion among real-time Java
threads that share the resource.
 Priority inheritance provided by default,
with optional ceiling emulation.

Asynchronous Events

Some internal or external event that
happens.
– Not all real-life events are predictable in time
and frequency.

System needs to respond to the changing
environment.
– Ability of real-time systems to react to the
events requires reliable asynchrony techniques.
Asynch. Event Class Hierarchy
Runnable (I)
Object
Schedulable (I)
AsyncEvent
AsyncEventHandler behaves like
Thread. It has a run() method.
BoundAsynchronousHandler can
be used for added timeliness by
binding each handler to a dedicated
thread.
AsyncEventHandler
BoundAsyncEventHandler
Taken from Prof. Insup Lee, Univ. Penn.
Asynchronous Event Handling


AsyncEvent is an object that is programmatically
bound to an AsyncEventHandler. The
AsyncEventHandler class implements Runnable,
and the overridden run() method is executed when
the AsyncEvent is triggered.
Handlers execute with the semantics of a real-time
thread.
– RTSJ does not require that the handlers be implemented
as threads, only that they execute as if they were.
Asynchronous Event Handling
import javax.realtime.*;
public class HardwareEventExample extends AsyncEvent {
private in interruptNum;
// construct new HW Event for given interrupt
public HardwareEventExample(int num) {
interruptNum = num;
}
// bind handler to interrupt
public void setHandler(AsyncEventHandler h) {
super.setHandler(h);
Hardware.bind(interruptNum,h);
}
}
class HardwareEventHandler extends AsyncEventHandler {
private int interruptCount = 0;
// interrupt handler method
public void handleAsyncEvent() {
interruptCount++;
// driver code follows
}
}
Asynchronous Transfer of
Control
Change in environment needs immediate
attention.
 Abandon current execution and take
appropriate action.

Asynchronous Transfer of
Control

Methods that have throws clause, including
AsynchronouslyInterruptedException (AIE)
in their signature will have that exception
raised by the JVM when the interrupt()
method for their thread is called.
AIE (AsynchronouslyInterruptedException)
Class Hierarchy
Object
Throwable
Exception
Interruptible (I)
InterruptedException
AsynchronouslyInterruptedException
Parameter for
AIE.doInterruptible()
Timed
Taken from Prof. Insup Lee, Univ. Penn.
Asynchronous Thread
Termination
Asynchronous Event Handling and ATC
provides ways to manage execution in a
real-time environment asynchronously.
 By implementing these two together, we can
achieve asynchronous thread termination.

Physical Memory Access
RTSJ defines a class that allows byte-level
access to physical memory.
 Also a class that allows construction of Java
objects at particular address locations in
physical memory.

PERC and Embedded Java
PERC (Portable Executive for Reliable
Control) – developed by NewMonics
 Virtual Machine specifically for embedded
systems
 Implements language extensions
specifically designed to handle real-time
activities

PERC and OS Support
Available for wide variety of platforms
 JDK 1.3 compatibility
 VxWorks, VxSim, OSE, OSE Softkernel,
Linux, and WinNT support
 Will be interesting to see PERC’s future
now that RTSJ has been created.

Java technologies from Sun
Architecture - contains libraries, JVM and
SDK
 Configuration - Virtual Machine and
minimal set of API’s
 Profile - adds more API’s to make a
complete specification for a device

Architectures

J2EE (Enterprise Edition)
– Used in Embedded Server Applications

J2SE (Standard Edition)
– For writing Applets and other applications

J2ME (Micro Edition)
– For Embedded Systems
J2ME and Java Card Hierarchy
J2ME
Edition =
Java Card
J2ME CDC Libraries
J2ME CDLC Libraries
Java Card API
CVM
KVM
Java Card VM
Core Libraries
+ VM
Profiles
Personal
Profile
MIDP
Profile
GSM
Profile
Open Platform
Profile
Configurations

CDC (Connected Device Configuration)
– For next generation devices (car navigations
systems)
– Coupled with CVM

CDLC (Connected Device Limited
Configuration)
– For smaller devices with limited memory (cell
phones, PDA’s)
– Coupled with KVM
Virtual Machines

Older JVM’s
– Personal Java
– Embedded Java
– Java Card

Current JVM’s
– CVM
– KVM
Personal Java
pJava is a modified version of the standard
Java virtual machine (version 1.1)
 Uses a minimum of 8 MB RAM
 Contains the full AWT implementation
 Includes tools for building compressed
ROM images of class files

Embedded Java
More of a licensing tool to let companies
choose which features companies want for
their devices.
 Java Filter takes list of class dependencies
and removes unused libraries.
 Java Check reassures that the correct API’s
are used.

Java Card
Specialized compiler and API’s for running
Java on smart cards.
 Examples of smart cards

– Memory cards can only retrieve data. Phone
cards are one example.
– Cards with microprocessors and less than 8K
memory. Mostly used for storing money and
security purposes.
C Virtual Machine (CVM)
Uses Java 2 feature set
 Built on Java 1.2 specifications
 For devices that have at least 2 MB of
memory and 16 or 32 bit processors

K Virtual Machine (KVM)
Runs on systems with as low as 160KB
total memory
 Object code is 50K – 80K
 Can run on 16 bit processors clocked to as
low as 25 MHz
 Implemented in native code for
performance

Profiles
MIDP (Mobile Information Device Profile)
 Foundation Profile
 PDAP (Personal Digital Assistant Profile)

– Extends the CDLC to take advantage of PDA’s
– Currently under development
Foundation Profile
Base profile that other profiles can build
from
 For devices with network connectivity and
no GUI

MIDP
Adds user interface, database and
networking to the CLDC
 MIDP devices control MIDlets (similar to
applets) through software.

Other Technologies
JavaTV API
 Jini – a Network API
 Java Embedded Server
 JTAPI – Telephony API, Java Speech, many
others

Major Platforms Supported

Operating Systems
– Windows CE
– Linux

Processors
–
–
–
–
PicoJava – Sun’s Java Processor
StrongArm
MIPs
Intel
Java and Embedded Linux
Java does I/O by opening files which are the
Linux device drivers (ex: /dev/mem). Java
can seek in addition to read, write and open.
 Bootstrapping allows Linux to load
necessary drivers and networking files and
start running the JVM.
 Standard Linux distributions with
networking support require lots of memory.

Improving Performance
Java bytecode programs are typically 10
times slower than programs written in C or
C++.
 How well the program is written is more
important. A well-written Java program can
equal the efficiency of an average-written
C/C++ program.
 Interpreting code uses less ROM.

Compilation into Native Code
AOT (Ahead of time)
 JIT (Just in time)
 Dynamic Compilation

AOT Compilation
Similar to C compilers
 Tends to create large executables
 Need to re-compile for different platforms
or when loading a different class
 Can compile everything including class
libraries

JIT Compilation
Machine independent
 Higher startup cost
 Not ideal for embedded systems

– Requires fast CPU, lots of virtual memory and
a fast disk drive for paging
Dynamic Compilation
Dynamically compiles code that is being
used more frequently
 Typically uses JIT compilers
 Doesn’t require virtual memory, adaptable
to available system memory
 Isn’t guaranteed to meet timing constraints

– Applications can change the compiler’s thread
priority for greater predictability
Other Methods to improve
Performance
Static Linking - place bytecode into ROM
 Re-write bytecode interpreter in assembly
language
 Use a Java Chip

Java Chips
Coprocessors work in tandem with
microprocessors. They work similar to
Graphic accelerators.
 Microprocessors that are optimized for Java

– Only programs written in Java can be used.
– Contain more registers for stack use
Applications of Embedded Java

JVM’s and Compilers
– Embeddable J2EE application server
(Macromedia)
– Visual Age Micro Edition (IBM)
– Jbed is a JVM for PDA’s mobile phones and
Internet appliances.
» Has a RTOS
» Runs everything natively
» Can use less than 10KB RAM
Jbed in detail

Task Objects (sub-class of Java thread)
– Tasks can be executed on a regular interval or
on an interrupt
– Jbed guarantees a task will meet its deadline if
given its estimated runtime.
– Tasks get time-slices and are preempted on a
timer interrupt. After the task runs for its
duration, the task with the closest deadline runs.
Jbed (cont.)
Tasks can only be scheduled after the
minimum time slice (~1ms).
 Traditional interrupts preempt threads and
tasks but may not allow tasks to meet their
deadlines.
 There is functions built into the OS for
memory access.

Other uses for Embedded Java
Browsers
 GUIs
 Database software
 E-mail clients

Conclusions and Summaries



Recent advances in embedded Java technology
and the advent of RTSJ are allowing real-time
capabilities and possibilities in the Java world.
Many current embedded Java systems are non
real-time or a limited subset of RTSJ principles.
Sun’s advancements and broad range of
distribution environments make embedded Java
programming much simpler and more robust.