Dependency leaks and embedded Java
Stephan Erbs Korsholm (SEK)
SEK at VIAUC.DK
Mon Oct 22 06:37:54 PDT 2012
To jigsaw-dev,
Just want to let you know about our research project called the HVM,
which is an effort to (re)enable the Java SE Platform for low-end
embedded devices. The targets we have in mind are micro-controllers
with approx. 8kB (or more) RAM and approx 64 kB (or more) ROM (see
http://icelab.dk).
On such devices the monolithic nature of most Java execution platforms
is obviously a challenge. Using some tricks we are able to execute
code like e.g the following on low-end embedded devices:
ArrayList<String> list = new ArrayList<String>();
list.add("foo");
list.add("horse");
list.add("fish");
list.add("London");
list.add("Jack");
Object[] array = list.toArray();
Arrays.sort(array);
Most other embedded Java environments seek to get around the
monolithic JDK problem by developing their own JDKs. The goal of the
HVM is to actually allow developers to use e.g. Java 6 or 7 to run
code like above on low-end embedded devices.
We use static program analysis to calculate a conservative
approximation to the set of classes and methods that may be required
to execute the code above. This set we call the 'dependency extent' of
the program. The method applied to do program specialization (the act
of shrinking a given application to contain only actual dependencies)
is an instance of the k-CFA algorithm and also known as variable-type
analysis (VTA).
Code like above can be analyzed and results in a manageable dependency
extent, but code like e.g. System.out.println("Hello") cannot. For
'HelloWorld' the dependency extent becomes impractical for low-end
embedded devices. For the 'HelloWorld' scenario we say that a
'dependency leak' has been introduced.
An interesting observation that we have made is that for Java 6, many
of the collection classes and other utility class like e.g. String and
StringBuffer, the dependency extent is reasonable, but for Java 7 the
same classes leak a lot more, and classes that we could previously
handle can no longer be part of our embedded programs :-(
I find the jigsaw project very interesting in relation to our efforts, and look
forward to eventually explore the dependency extents of our programs
based on a modularized JDK.
To ease the use of Java for embedded devices a modularized JDK (and
VM) would definitely be attractive.
Since we base the HVM program specialization on static program
analysis we have to preclude the use of dynamic class-loading. Other
similar efforts exists e.g. ProGuard.
Kind regards,
- Stephan Korsholm, VIAUC, DK
More information about the jigsaw-dev
mailing list