Java/JVM on ARM/M1 had an enormous amount of bugs for the first several years, fyi. Source: I encountered many of them, which eventually got fixed.
luckily because this has mostly been fixed and is also the biggest stumbling block when going from x86 => RISC-V
Through there was something about the specific LR/SC definition which I found quite problematic when it comes to implementing certain atomic patterns. But that was 2?? years or so ago and I don't remember the details at all.
Eitherway theoretically if you have a correct C++ standard compatible program without UB it should "just work" on RISK-V by now, but then I don't think such a thing exists (/s/j).
0. https://buildd.debian.org/status/architecture.php?a=riscv64&...
Fortunately, what does exist is programs that have been ported to work on arm64 (or are native there), which will Just Work on RISC-V which has a slightly stronger memory model than Arm.
Note that ART as it is now is the third implementation, first it was Dalvik, then ART pure AOT, and now ART interpreter/JIT/AOT.
Nokia and Sony-Ericsson already had relatively good J2ME implementations for Symbian, and Blackberry OS was powered by Java, when Android came out.
Unfortunately it didn't went for Google the same way, as it did for Microsoft.
Gosling interview on the matter,
https://www.youtube.com/watch?v=ZYw3X4RZv6Y&feature=youtu.be...
But a more nit-picky/correct definition would expect the JVM to follow various specs (e.g. expect the bytecode the have exact the same format, features etc. as the one you find in a classical java application) and have various features which do not apply to the ART at all.
Or in other words, people which have nothing to do with java might call the ART a JVM in a generic way but people which do might be for good reason very insistent that this isn't the case. (Also Google lawyer will be VERY insistent it's no a JVM.)
Not all of them are available, however all of them do support AOT compilation, and their own bytecode format more optmized for their use cases than regular .class files.
The big difference between them and Google, is that they always played by the Sun/Oracle rules regarding Java licensing.
and in general there where tons of issues with multi threaded code during the time Java did move to the "current" memory model (was that in Java 1.5 or Java 1.6? I don't remember), through Sun(Oracle) JVM having issues on ARM was still a think after a huge part of the ecosystem moved to Java 1.6+ but I think wasn't anymore much of an issue when Java 1.8 was approaching but uh that was many years ago the my memory is a bit vague
I wrote code or managed Java development teams from around 1996 to ~2010 and I don't remember any problems with multi threaded code or memory models. But of course you might be right if you did run Java on an ARM mobile like the Nokia.
The only challenge I remember with two high load (thousands of write transactions/sec - back then) websites were GC pauses, where we had to hire consultants to help with tuning the GCs on different machines for the high load.