The document below is reproduced from ACUNIA's internal website with only minor changes. These were the goals when Wonka was still an internal project, and they are still valid as a statement of our aims now that Wonka has gone public.
Goals of Project Wonka
The aim of the project is to create an implementation of JavaTM suitable for use in embedded systems. This must be a complete and correct implementation, readily portable to a wide range of devices, characterised by a high level of availability, usable in systems which have real-time requirements, and it must make efficient use of limited resources.
Wonka should be the VM of choice for embedding Java in consumer products.
Complete and Correct
Everything we claim to implement should be there, and should work according to spec.
There is a wealth of information available about how a Java implementation should behave. Study it.
Portability
Keep it clean.
Porting the implementation to a new environment must be a straightforward operation, and should result in a high degree of confidence that the ported version will function correctly. The keys to portability are well-defined interfaces and clean code.
The interface to the memory management and scheduling functions
is defined in rtos.h
.
Avoid making direct calls to functions of a
particular [RT]OS, even "universal" functions such as
malloc()
or free()
:
on some platforms we might need to make wrapper functions,
e.g. because the standard malloc()
is not thread-safe.
Interfaces to physical devices must be
isolated either by packaging them in JNI libraries or by using
the Virtual Device Interface defined in vdi.h
.
We only allow the following deviations from ANSI C:
- the
inline
directive; - the
//
form of comment.
The ANSI standard allows compilers to implement the standard
data types char, int, long,
etc. in different ways;
therefore the data types w_char, w_int
etc.
should always be used. We assume that a C pointer
(e.g. void *
) fits into a w_word
,
because this is pretty well hard-wired into the Java language.
Apart from that, nothing should be assumed beyond the letter
of the ANSI standard. Ill-defined constructs such as bitfields
must be avoided, as must non-standard features or "extensions"
to standard library functions, however seductive.
High Availabilty
24/7/365/1000
The system should be capable of running "forever", without degradation of performance. That means that leakage of memory or other resources is simply unacceptable, as are "rare" race conditions or other causes of unpredictable behaviour. It also means that data structures and algorithms should be designed to tend to an acceptable steady state over time, without the need for major maintenance.
Real-time Friendly
As real-time as its environment allows
We don't really expect the most time-critical parts of an embedded system to be implemented using Java. However it must be possible to use the JVM in systems where there are real-time requirements, and for subsystems which use Java to have predictable response times. Some consequences ot this are:
- The Garbage Collector is not allowed to block the system other than for strictly limited periods. Blocking includes both locking access to the heap and running at highest priority.
- When running in an environment which schedules threads strictly according to their priority, the VM synchronisation operations must respect these priorities. The VM must not introduce unwanted serialisation of actions.
Efficient
A question of balance
Efficiency is the ratio of output produced to resources consumed.
Time is an important resource, but it is not the only one:
other resources such as memory and communications bandwidth
can also be important. A system can be called efficient when
it succeeds in balancing its use of resources to obtain an
optimal result.