J2ME: Design, Performance and Efficiency With WSDD

Randy Faust Embedded Java ActivistIBM OTI Labs PhoenixIBM OTI Labs Zürich

2

Past, Present, and (near) Future.

What’s happened so far? Why have people failed? Where do we go from here?

What to consider. Best practices. Tools and Tuning.

Questions?

3

What’s Happened So Far. False starts:

Personal Java, Embedded Java, Micro Java, Pico Java

IBM builds J9. IBM invents custom class libraries:

Extreme, Core, Max

IBM is on its 9th embedded Java release: VAES 1.0, VAME 1.0-1.4, WSDD 4.0-5.5

J2ME is created: Configurations, profiles, WME, WCE

“Java powered” and TCK

4

Why Have People Failed? Not enough hardware. 5 developers == 5 boards Little or No “in field” development. Not enough testing throughout the project lifecycle. Failing to appreciate system constraints. Embedded guys trying to do Java. Java guys trying to do embedded.

5

Why Have People Failed? Having insufficient knowledge of the OS. Believing WORA in the embedded space. Trying to extend the ‘good-enough’ approach. Creating too many threads. Forgetting that Java heap isn’t the only memory required.

The VM is an application which also uses memory. How much can depend a good deal on how many classes you load.

6

Where Do We Go From Here? Greatest use of Java in the embedded space. More and better choices for embedded graphics. Faster VMs. Faster chips, cheaper memory, lower power. Plugins for WSDD from Eclipse or WSWB enabled 3rd

parties.

7

What to consider. OS, Processor, Tools (self hosted or X-compiled, debugger) Hardware configuration

memory, processor speed, interfaces (serial, ethernet, MOST, flash)

Java feature set Class libs, Frameworks, UI, big Int, zip support, compressed zips,

verification, one-shot or command-line, JIT, AOT

Development cycle turn-around time time = generate + build + download + run

Available documentation and support

8

Best Practices (This is all a lie)

Choose the right parts to code in Java. Device drivers are usually not good candidates.

Beware Vector. Fastest is ArrayList, although its unsynchronized. Stack just extends Vector.

Be smart about GCs. Tune the app, and ask for GC’s yourself.

Reuse existing objects. Take the effort to reinitialize their values.

Take into account the connectivity of your platform. Don’t forget the background traffic use cases.

Know the fastest possible startup time, before you run a single line of code.

9

Best Practices (This is also a lie)

Avoid method calls as loop termination criteria. for (int i= 0; i < str.length(); i++)

Avoid synchronization JIT may be able to remove sync blocks, but don’t count on it

Avoid monster objects. Avoid finally() blocks. Avoid String concatenation. Use StringBuffer objects instead.

10

Best Practices (Yet more lies)

The amount of code is bytecodes, not the size of your source.

Message sends are costly. In-line small methods, getters/setters, use JIT in-lining.

Always ask yourself, “Does this make sense? Is it easy to understand? Could we make it simpler?”

Bigger methods take a longer time to inline and cost more memory. Small methods JIT faster, but large methods give you more value when they’re JITted.

Don’t optimize too early. Optimizing 5% usually yields most of the potential improvement.

Use Lazy Initialization.

11

Best Practices (Some truth here)

Erase code. Manage your resources carefully. Version control your use cases and requirements. Hard writing makes for easy reading. The easiest way is probably the best way. Save time for certification. Objects die young.

12

Tools and Tuning: The J9 VM Bottom-up design, Cleanroom JDK 1.3 compliant Fast interpreter written in assembler using register based

calling convention Multi-VM, JVMP, JDWP, INL Pluggable class libraries Mixed-mode execution: AOT/JIT/interpreter New GC: accurate, incremental, compacting Statically or dynamically linked Native threads, widgets and memory management Thin port layer to isolate use of OS

13

Tools and Tuning: Configuring the VM Three configuration levels:

At runtime using command options– changing default memory settings or garbage collector

characteristics– JIT

At integration time by selecting the desired set of modules– removing shared objects (math, dbg, zip, jxe, etc.)

At build time by changing the VM-OS code or Application code– Jxe– AOT– changing the thread model or scheduler

14

Tools and Tuning: Jxes “Java Executable”. Split representation of Java classes WHY?

Organized more thoroughly than .class files. Future: JSR-202? Reduces memory footprint Faster execution as class loading time is reduced Allows sharing of class libraries, user code

– Multi-VM size reductions for servers and handheld No file system or network required Allows Execution in Place (XIP) from Flash Classes loaded on demand, not all at once

15

Tools and Tuning: VM Memory Tuning

-Xmca<x> Set RAM class segment increment to <x>

-Xmco<x> Set ROM class segment increment to <x>

-Xmx<x> Set memory maximum to <x>

16

Tools and Tuning: The Garbage Collector

-Xmn<x> Set new space size to <x>

-Xms<x>, -Xmo<x> Set old space size to <x>

-Xmoi<x> Set old space increment to <x>

-Xmx<x> Set maximum memory to <x>

-Xmr<x> Set remembered set size to <x>

17

Tools and Tuning: JIT and AOT JIT compiled code is better than AOT compiled code

because it will use runtime profiling information. AOT is typically more useful when you have prior information

about the runtime characteristics of the application. Adaptive recompilation is possible on certain platforms. Code is never un-JITed. There’s almost never a reason for

this. AOT and JIT can be mixed in jxe files.

18

Tools and Tuning: JIT and AOT Use a limit file after profiling when you know what you want

to JIT. Big methods take a longer time to compile or inline and will

use more memory. High optimization level of JIT are often best left for

benchmarks. X-compiler for x86. Dumptrucks only go a little faster with turbo.

19

Tools and Tuning: Smartlinker Preprocesses Java classes into target executable form (jxe) Splits code into RAM/ROM format Reduces code by removing unused classes, methods, fields Creates jxe file in target platform endian and addressing Supports XIP by prelocating jxe for ROM addressing

20

Tools and Tuning: Smartlinker Package jxe with preverification info Precompile methods Segment the jxe Obfuscate method and class names Specify the startup class if applicable Create component jxes

21

Tools and Tuning: MicroAnalyzer Capture and timestamp key events with low overhead ~5% Target or Workstation triggering and tracing options Measure time between user events Measure memory usage See context switch events between threads

22

Tools and Tuning: Remote Debugging Implements 1.4.0 JDWP wire protocol, including “hot code

replace” Runs over a proxy to save space on the target -verbose

class, jni, gc, dynload, stack, debug

-memorycheck– all: Lots of checking, slow– quick: Minimal checking, fairly fast– nofree: Don’t free any of the memory– failat= X:Fail allocation X– skipto= X:Only start memory checking at X

Use a “friendlier” platform

23

Questions?