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

Zac Harvey zharvey at pobox.com
Tue Aug 11 15:54:45 CEST 2015

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 

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

More information about the devel mailing list