luckily many of the things which caused bugs on ARM where related to the weaker memory ordering and code having (invalid) implicit assumptions about stuff like memory barriers
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).
> 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
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.
It actually does, the devices might run ART, however the whole developer toolchain depends heavily on the JVM, Gradle, Android Studio/InteliJ, the pleothoara of little CLI tools to transform those .class files into .dex, desugar modern JVM bytecodes into JVM bytecodes that can actually be mapped into existing .dex ones (for pre-Android 12 devices), library calls that need to be polyfilled into something else,....
Stupid question: why does android use ART (and Dalvik before that)? I guess it's more performant for mobile phones, but then, is there a reason why other java apps don't use it outside of android? Has anyone tried using ART/Dalvik outside of the android ecosystem?
It's a bit of a question about what you define the term "JVM" as. For many people it just means the thing which runs bytecode java was compiled to, in which case the Android runtime (ART) is a JVM (it has AOT, JIT and can run bytecode prodced from Java if done so in the right way).
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.)
Which is a kind of nit picking for Google laywers, as the approach taken by Dalvik/ART has been quite common in the embeded space, see PTC, Aicas, Aonix, microEJ, Websphere Real Time,...
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.
they probably mean Sun(Oracle) JVM on ARM, as far as I remember there where tons of issues with that one
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
"and in general there where tons of issues with multi threaded code during the time Java did move to the "current" memory model"
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.
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).