[riot-devel] HotSpot JVM on RIOT-OS?
zharvey at pobox.com
Tue Aug 11 21:48:59 CEST 2015
A quick mid-day follow up here: From everything I’ve collected so far,
the RIOT-OS has no problem handling 32-bit (ARM-based) architectures,
and so there’d be nothing stopping me from getting it to run on, say,
the ARM SAM3X8E Cortex M3 MCU, yes? (Please correct me if I’m wrong!)
There is a 32-bit (i386) version of OpenJDK 7 available on lots of Linux
repos (check them out here: http://openjdk.java.net/install/). So, I
can’t imagine it would be too difficult to get a 32-bit, Open JDK 7
compiled and running on an ARM chip where RIOT-OS is its underlying OS.
Again, *please* correct me if I’m wrong, or if I’m overlooking some
obvious hurdles here!
On 8/11/15 9:54 AM, Zac Harvey wrote:
> Thanks for the thorough response Joakim.
> I actually think 32-bit is perfectly fine, at least for my needs.
> Specifically I'm looking to target the ARM SAM3X8E family (Cortex M3)
> which is 32-bit (most Java apps can - and arguably should run inside
> of 4GB).
> Your point about Java not being able to *truly* deliver real-time
> guarantees is spot-on. However, there are all sorts of tricks you can
> do so that major collections run very infrequently. And the
> Shenandoah/G1 "pauseless" GC coming in Java 9 or 10 promises to reduce
> actual pausetime down to <1ms. That's probably not impressive for you
> hardcore RTOS peoples, but in Java-land that is like...the best
> thing...of all time...ever.
> A lot of IoT-type devices do not need *hard* real-time guarantees, but
> could greatly benefit from running existing platforms, libraries and
> frameworks running in JVM/Python/Ruby/etc. lanaguages. How cool would
> it be to run Akka on a smart device? This is likely how Skynet will
> come to be self-aware and enslave us all. I guess my motivation would
> be to accept the current real-time shortcomings of the JVM, use those
> tricks to minimize GC, and hold out for a few years until improvements
> to the core JVM (such as Shenandoah) are released into the wild.
> I also think such an endeavor would spark a large community of non-C
> devs to get heavily interested in RIOT-OS, which from what I can tell,
> is best-in-show in the modern RTOS landscape.
> Thanks again for the solid input here - stay tuned!
> On 8/11/15 8:48 AM, Joakim Gebart wrote:
>> See my response inline below.
>> On Tue, Aug 11, 2015 at 11:58 AM, Zac Harvey <zharvey at pobox.com> wrote:
>>> Thanks for that Lejos link, Kaspar, I will definitely dig into it later
>>> You mentioned that RIOT *targets* devices that require a small
>>> but you didn't state that RIOT only supports devices with small RAM.
>>> What's the max size/RAM that RIOT can support, or that RIOT is
>>> for? What would be entailed with refactoring it to handle larger apps?
>> So far, RIOT does not support 64 bit systems (native included, it is
>> compiled as a 32 bit binary even on amd64 afaik), and it will take
>> some effort to add that support, because there may be hidden
>> assumptions in the code that some data type is 32 bit long.
>> The biggest problem, however, with porting to a larger system than a
>> microcontroller is that these larger systems have MMU (memory
>> management unit)-hardware which performs address space translations
>> between virtual addresses and physical addresses, and ensures that
>> each process has its own address space to run inside. This MMU must be
>> configured when booting in order to access all of the memory. My area
>> of expertise is constrained systems, such as the current RIOT
>> platforms, so I may have some factual errors in the above explanation,
>> please correct me if I am wrong about anything above.
>>> I ask this because to me, and for many others I'm sure, the main
>>> value in an
>>> RTOS (as opposed to Linux) is its deadline guarantees. When I run
>>> Java on
>>> Linux, the whole JVM process might come to a hault for a few seconds
>>> Linux flushes some stream. Or perhaps some system-level utility runs
>>> for a
>>> few minutes and bogs down everything on the server (including my
>>> Java app).
>>> So to me, the real appeal of RIOT is:
>>> 1. Its a legitimate real-time OS when hard deadlines, task execution
>>> guarantees, etc.; and
>> Can you really get any real-time guarantees on a Java VM? There are
>> background processes happening inside the Java VM which may cause
>> delays, for example memory garbage collection (this applies to Python
>> too and probably others, but I don't know any other interpreted
>> languages well enough to comment on them)
>>> 2. It's an OS where I can just deploy my app and I know that
>>> *nothing else*
>>> besides the OS is running
>>> So to me, if RIOT-OS can technically handle JVM apps (2GB - 4GB in
>>> then why not try to get a JVM like HotSpot to run on it? And if for
>>> reason it can't handle apps that size (e.g. perhaps the largest
>>> integer it
>>> can handle is only 65,536, etc.), then I'm wondering what level of
>>> refactoring would be required to enable it to handle
>>> Traditionally, the counter-argument here is: "Well then just write
>>> your apps
>>> in C." However, in 2015, all hobbyists, commercial and open source
>>> organizations have an enormous amount of time & effort ($$$)
>>> invested in
>>> existing software systems, which may be Java-based, Python-based,
>>> Ruby-based, Node-based, etc.
>>> I can't speak for anyone else, but I would argue that the ability to
>>> run a
>>> JVM app on a real-time OS is going to be of *enormous* utility,
>>> in this modern "Internet of Things" era we're careening towards. It
>>> also spawn up a whole subculture of getting other systems (again,
>>> Ruby, etc.) running in an embedded context. I'm just sayin'...!
>>> Thoughts? Criticisms? Hate mail?
>> By all means, go for it! Even if it may not give the same real-time
>> guarantees as running a process hand-coded in C on the bare metal
>> platform it is still a useful experiment and concept.
>> For anyone attempting this: I don't believe this is an easy task. You
>> will probably have to implement quite a large part of POSIX ioctl,
>> some improvements to the supervisor call handler (at leas if running
>> on ARM, to handle more than just task scheduling). You may also need
>> to write an adaptation layer between gnrc (the network stack) and
>> whatever network API is expected by the JVM. Filesystem storage may
>> not be strictly necessary, but probably mandatory for almost any apps
>> you want to run on this system.
>> Best regards,
>> devel mailing list
>> devel at riot-os.org
> devel mailing list
> devel at riot-os.org
More information about the devel