The Wonka VM

Presentation for FOSDEM 2003

Brussels, 8 Feb 2003

Copyright © Chris Gray 2003

Contents

Where we came from Where we are now Some Wonka internals Where we are going

Origins of Wonka

ACUNIA founded in 1996 as SmartMove Dedicated to telematics, using Java™ Central product is Open Telematics

Framework™ (OTF) = server “middleware”

Developed supporting hardware, VM, to have own option for demos, contracts

Origins of Wonka, continued

Back in 1998/99 Sun's VM too expensive Kaffe not mature, Transvirtual unable to

give much support SmartMove CTO Steven Buytaert is gung-

ho

ÞSteven & Chris start work on “Willy Wonka and the Object Factory”

Taking Wonka Open Source

By Summer 2001, Wonka is pretty usable. What to do?

Market as closed-source product We need a marketing team! 8-0

For internal use only Will always be a cost-centre

Make open-source product Get help Make friends Make some money too?

The Licence Question

Three kinds of licence: GPL - the best known BSD/MIT - the simplest “Community” licences

We chose for “revised” BSD

Why not GPL?

GPL is well-known, and has served GNU and Linux well. But it is problematic when OS, HW support and application are all linked together.

2 versions (proprietary/GPL) means code can only flow one way (OK for Ghostscript)

1 version + GPL “buy-out” is saying “GPL sucks, that's why we use it”

Community Licences

Give one party special rights Help to prevent forking, but forking is a

fundamental human right. :-) (See e.g. E. S. Raymond, “Homesteading the Noosphere”)

Sun SCSL is the Awful Example

Wonka Public Licence

See http://wonka.acunia.com/licence.html

“Revised” BSD, i. e. no “advertising” clause (that was last century ...)

No Apache-style “trademark” clause But ACUNIA owns Wonka trademark

and copyright in source code

Wonka Project Aims

Complete and Correct Java2, OSGi RFC 26 J2ME CDC/FC

Portable High Availability Real-time friendly Efficient

Where we are now

Version 0.9.5 in preparation For RFC 26, lack only

java.lang.reflect.Proxy (work-in-progress) Also miss java.beans, java.rmi.activation Very conformant, stable Fast interpreter, adaptive JIT is w-i-p Runs on linux, netbsd, eCos for arm, x86 Ports in progress to MIPS, BeOS WinCE would be great ...

Wonka Developer Community

Still mostly developed in ACUNIA: team has gone from 2 to 6, soon back to 3

50-60 subscribers to wonka-developers list

Many contributions and bugfixes since Oct 2001

ACUNIA team has built strong, quality basis

More input welcome

Wonka Internals

String treatment Object layout Garbage collector Class loading Bytecode execution Threading Visual interface

Wonka String Handling

String constant, instance of String each point to a w_String

w_String contains ref count, 8/16-bit flag, length, chars

All-Latin1 strings stored 8 bits/char, others stored 16 bits/char

Never have two identical strings in memory, are always “canonicalised”

Wonka Object Layout

No handles: class ptr, flags directly precede field “slots”

Currently each field occupies 1 or 2 words. Considering move to store e.g. bytes and booleans byte-aligned (time/space tradeoff)

Recent change: all reference fields at end, with “negative” offset (nice for GC)

Wonka Garbage Collection

Non-moving, mark & sweep Take snapshot before mark, used during

sweep - no interference between mutator threads and sweep

References created/destroyed during mark need special treatment - use “grey” list, moving to safepoints/maps

Any thread can be asked to do GC when it allocates (polluter pays), scavenger thread adapts to heap size and collection rate

Wonka Class Loading

Java class libs are ginormous, strongly connected: transitive hull of java.lang.Object is > 200 classes!

Wonka loading is very lazy, keep references symbolic (name + classloader) as long as possible

Also very resistant to spoofing, without using “constraints”

see Staerk, Schmid, Boerger, “Java and the Java Virtual Machine”

Bytecode Execution

Optimised direct-threaded interpreter (written in GNU C)

Adaptive JIT compiler in preparation (already works on x86 and arm, but needs new GC interface to be fast)

Threads in Wonka

All code uses the OSwald API (typical RTOS primitives, e.g. x_thread_create(), x_mutex_lock())

Can run OSwald as native OS or as host of linux, netbsd, ... (standard configuration)

Or can map Oswald API onto underlying RTOS primitives (eCos port) or pthreads (O4P) for maximum portability

Wonka Visuals

Rudolph operates on framebuffer (/dev/fb) or in an X11 window (simulated framebuffer)

Uses own peers and internal WNI interface, by standardising peers and using JNI we could exchange peers with e. g. Classpath

But - requires effort, no obvious payoff for ACUNIA, and

Wonka/Classpath licences are compatible, but different. Classpath can freely import Wonka code, but not v. v.

The Future

Growing user/developer community Fill holes, add more useful stuff Specific projects:

J-spot adaptive JIT, bytecode verification Security review WinCE port Modularisation More target CPUs, OS's

Projects (1)

J-spot Adaptive JIT, based on principle that 95% of

time is spent in 5% of code Produce optimised code, not just a string of

templates

Security review Check all checks are performed Devise test suite, including known attacks Great project for somebody :)

Projects (2)

WinCE port Would be great to have Why so @#$% hard?

Windoze compilers don't support C99 features, e. g. varyadic macros

Bizarre threading, memory models Developers' fear and loathing

Projects (3)

Modularisation Currently Wonka contains everything bar the

kitchen sink -> powerful but big Need to add more configuration options to

omit functionality not needed for a project, the way we now omit e. g. AWT

More ports Problem of finding one big sucker to fund/do

development - need to find ways to integrate many smaller suckers

Summary

Just do it!