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

Joakim Gebart joakim.gebart at eistec.se
Tue Aug 11 22:05:05 CEST 2015


On Tue, Aug 11, 2015 at 9:48 PM, Zac Harvey <zharvey at pobox.com> wrote:
> 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!)

Yes, the SAM3X8E is already supported in RIOT [1]. It is used by the
udoo and arduino-due boards.

>
> 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!

The OpenJDK would probably require many megabytes of both ROM and RAM,
this means it will not run on the sam3x8e, even if you add all the
support functions that are required by the program to get it to run
inside RIOT. A more realistic approach would be to take a serious look
at the embedded JVMs that were suggested earlier in this thread
(Darjeeling, and the LLVM based one).

BR,
Joakim

[1]: https://github.com/RIOT-OS/RIOT/tree/master/cpu/sam3

>
> Best,
> Zac
>
>
> 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
>
>
> _______________________________________________
> devel mailing list
> devel at riot-os.org
> https://lists.riot-os.org/mailman/listinfo/devel


More information about the devel mailing list