[riot-devel] HotSpot JVM on RIOT-OS?

Zac Harvey 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
>>> today.
>>> You mentioned that RIOT *targets* devices that require a small 
>>> footprint,
>>> 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 
>>> addressable
>>> 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 
>>> while
>>> 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 
>>> size),
>>> then why not try to get a JVM like HotSpot to run on it? And if for 
>>> some
>>> 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 
>>> beefier/server-like
>>> apps.
>>> 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, 
>>> especially
>>> in this modern "Internet of Things" era we're careening towards.  It 
>>> might
>>> also spawn up a whole subculture of getting other systems (again, 
>>> Python,
>>> 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,
>> Joakim
>> _______________________________________________
>> devel mailing list
>> devel at riot-os.org
>> https://lists.riot-os.org/mailman/listinfo/devel
> _______________________________________________
> devel mailing list
> devel at riot-os.org
> https://lists.riot-os.org/mailman/listinfo/devel

More information about the devel mailing list