Does sun.misc.Unsafe give access to the system or just the JVM?

Question

Please note: Although this question involves microcontrollers, it is at its core, a Java question, and so I believe it can be answered by any battle-weary Java guru.

I stumbled accross this blog talking about sun.misc.Unsafe and was trying to understand its full capabilities to see if it was appropriate for a hobby project of mine.

At the 30,000 foot view, I am trying to program an ARM chip (Arduino Due - an ARM SAM3X8E MCU) to drive some IO peripherals (flash some LEDs, drive servos, etc.) on a simple electronics device. For good sport, I would love to do this in pure Java if at all possible. Up until reading that article, I didn't even think this was possible, and figured I'd have to do most if not all the programming in C. Because this flavor of ARM can support Linux, especially a stripped down "unikernel-style" of Linux, I'd like to write my controller program entirely in Java, and deploy it to a location (say /opt/myapp) on a Linux image that I can then flash to the ARM chip. With a little tinkering/hacking, I should be able to get the ARM chip to run the Java app when the device powers up.

My question

To drive my device's IO peripherals, I need to access specific memory addresses that will exist outside the JVM process running my app. Up until now I was under the impression that JVMs "sandbox" their resident apps, disallowing them to access anything in system memory directly. And so my plan was to write a bunch of C code (which actually drives the peripherals, flashes LEDs, etc.) and then have my app invoke that C code through JNI.

But if I'm reading that blog correctly, it seems that sun.misc.Unsafe gives me acess to system memory outside of the JVM. If this is true, then technically I don't need any C code. Of course, I am committing all sorts of security no-no's, making my code non-portable, etc. But that's fine: this is just a hobby project running on a specific platform that I don't intend to change.

So I ask: am I understanding Unsafe correctly, and if so, are there any other caveats/restrictions/limitations I should be considering while using it?

Answer 1

sun.misc.Unsafe isn't part of the Java standard. Thus, your very first task will be determining whether the Java implementation you will be running on the ARM chip supports it.

If the answer to the above is yes, you have to ask yourself whether the I/O addresses you need to access are mapped within the JVM process. Unsafe lets you escape the usual Java memory model, but it doesn't have any facility to escape the JVM process's address space. It would not be unusual for hardware I/O addresses to only be writable from kernel address space, but your platform may be different.

Assuming you have the I/O addresses mapped in the JVM process, then the last hurdle is checking whether all the protocols you plan to use are slow enough or flexible enough with time that you can drive them from a Java process, which may be subject to stop-the-world garbage collection and other factors that make it not-even-remotely-real-time.

If all that checks out, it sounds like an interesting project.

Oh wait, you also have to figure out a way to fit Linux and a JVM in 512KB of flash memory ... and run them in 100KB of RAM. It sounds like you would need to upgrade to a significantly more powerful chip to carry out this concept, probably one with a DRAM controller to be able to attach sensible amounts of RAM.

Answer 2

If you want to program a cheap (32 bits) ARM chip in Java (which is probably not a good idea) and if you accept to code against an old version of the Java programming language, you might consider using gcj, the Java ahead-of-time compiler inside some versions of GCC.

^{(Beware, Java support in GCC seems phased out in 2015, or at least is becoming less important to the GCC community)}

However, you may want to use some other language. If garbage collection is significant to you, you could use D, or Go, or even perhaps use (perhaps by porting it to the bare metal) the Boehm conservative garbage collector in C (or even in C++, see this) - which is used by gcj. You could also consider coding in Ocaml, see MirageOS. And Rust is not garbage collected but might be useful on a small ARM chip.

Read also wikipage on real-time Java