Transcript Wonka_Presentation

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 Y 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
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!