Optimized Java bytecode scheme for embedded devices
There exist interesting research related to reducing the resource demands of Java runtimes. Squawk takes this to the extreme by providing an almost completely standards-compliant implementation of the CLDC, the smallest configuration of J2ME, on which MIDP is layered.
It's also of importance to note, that the source is almost entirely written in Java itself! They have worked around the issue of implementing lower level routines by falling back to a common subset of Java and C for those parts. That's a nifty trick, and I wanted to blog about something similar long time ago. It's a good thing that I'm not dreaming all the time and many of my ideas can be realized in practice.
A complete runtime including the interpreter and the garbage collectors of the said takes up 25KiB of ROM. The standard CLDC library takes up a further 146KiB of ROM when uncompressed, or 64KiB if compressed. To execute the null program, it needs about half a kilobyte of RAM for the Java heap and another half a kilobyte for the native data and stack.
I have browsed through their paper and had to conclude that they've come up with a very elegant solution for a massive code size optimization and being memory friendly. Their techniques result in a typical 62% reduction of uncompressed code size, which at the same time greatly aids reducing runtime memory footprint of code.
It would make a great operating system for my 386 if it had a MIDP profile implementation. Just imagine all the games it could play!
A little teaser: compressed size for Space Invaders is 9KiB, while a tiling block puzzle takes up a mere 4KiB, both written in high level standard Java! I wonder how using the Scala programming language would alter this picture. This is one of the newest projects on my to-do list.
It's also of importance to note, that the source is almost entirely written in Java itself! They have worked around the issue of implementing lower level routines by falling back to a common subset of Java and C for those parts. That's a nifty trick, and I wanted to blog about something similar long time ago. It's a good thing that I'm not dreaming all the time and many of my ideas can be realized in practice.
A complete runtime including the interpreter and the garbage collectors of the said takes up 25KiB of ROM. The standard CLDC library takes up a further 146KiB of ROM when uncompressed, or 64KiB if compressed. To execute the null program, it needs about half a kilobyte of RAM for the Java heap and another half a kilobyte for the native data and stack.
I have browsed through their paper and had to conclude that they've come up with a very elegant solution for a massive code size optimization and being memory friendly. Their techniques result in a typical 62% reduction of uncompressed code size, which at the same time greatly aids reducing runtime memory footprint of code.
It would make a great operating system for my 386 if it had a MIDP profile implementation. Just imagine all the games it could play!
A little teaser: compressed size for Space Invaders is 9KiB, while a tiling block puzzle takes up a mere 4KiB, both written in high level standard Java! I wonder how using the Scala programming language would alter this picture. This is one of the newest projects on my to-do list.
Comments
Post a Comment