5 ms·

Yup, Java with it's strong memory model introduced with jsr 133 gave a whole lot of different headaches to people implementing the JVM on ARM. I'm still not sur

Yup, Java with it's strong memory model introduced with jsr 133 gave a whole lot of different headaches to people implementing the JVM on ARM. I'm still not sure if it's 100% reliable compared to the x86 impl. My friends' practical experiences suggest it's still bugged here and there. Edit: you gotta love how people on HN will down-vote you for sharing factual information on a topic. Are we levelling down to Reddit's standards?

lwouis 5y ago
I must say as a non expert on the topic, i don't understand the downvotes. I wish people who downvoted would take a moment and explain what they disliked
- bullen 5y ago
  Maybe you could force a comment on downvotes or you loose karma?
bullen 5y ago
I'm running a Java server that is heavily concurrent on ARM, what bugs did he mention in particular?
vlovich123 5y ago
Can you please elaborate? SW running against a strong memory model is actually simpler and less buggy than SW written against a weak memory model. In a weak memory model, each atomic operation has 5 modes whereas in strong they’re all equivalent. Most programmers can barely write simple atomic code and the weak memory model is trickier to wrap one’s head around (at least I still struggle to properly understand it vs using high level shortcut heuristics). A strong memory model is also trivial to implement on a weak memory system whereas the reverse is impossible. I can believe that Java on ARM can have bugs (fewer customers, relatively newer than x86, etc). It can also have bugs due to someone writing weak operations that were only tested on a strong memory model machine (ie latent bugs that wouldn’t be discovered on a weak memory model machine). Or heck. It can have bugs precisely because someone wants to somehow leverage weak operations for performance butt it did so incorrectly. Side note: The M1 is an interesting CPU because it implements both strong and weak memory models directly in HW. I don’t know why you got downvotes but what you provided was more of an opinion than fact (my post too is opinion).
- bitcharmer 5y ago
  > SW running against a strong memory model is actually simpler and less buggy than SW written against a weak memory model This is exactly what my comment is implying. On x86 you have a very strong memory ordering consistency in the form of TSO. This not only helps implementing synchronisation primitives but also in practice enables techniques such as synchronisation piggybacking which isnt safe on weaker models such as ARM's. > what you provided was more of an opinion than fact Don't really know how to respond to that beyond if the differences between memory models are a matter of opinion rather than facts than the following wiki page shouldn't even exist https://en.m.wikipedia.org/wiki/Memory_ordering https://en.m.wikipedia.org/wiki/Memory_ordering
  - vlovich123 5y ago
    I think you misunderstood what I was saying. Implementing a strong memory model on a weak memory model system is trivial. I’m not sure what point you’re trying to make that Java somehow using a strong memory model for the language causes problems for porting the VM to ARM with a weaker model. Any porting issues would result from them trying to eke out more performance and trying to take advantage of weaker atomic ops in the C implementation of the VM (a strong memory model by the way is widely accepted as being an incorrect abstraction for the HW because it leaves so much room on the floor - x86 is stuck due to back compat reasons). None of this would be visible to running Java programs themselves and arguable Java choosing a strong consistency model is the right choice considering how much of a foot gun a weak memory model implies. A factual post might try to back up the claim with specific bugs or more detailed analysis that has been done.

lwouis 5y ago

I must say as a non expert on the topic, i don't understand the downvotes. I wish people who downvoted would take a moment and explain what they disliked

bullen 5y ago
Maybe you could force a comment on downvotes or you loose karma?

bullen 5y ago

I'm running a Java server that is heavily concurrent on ARM, what bugs did he mention in particular?

vlovich123 5y ago

Can you please elaborate? SW running against a strong memory model is actually simpler and less buggy than SW written against a weak memory model. In a weak memory model, each atomic operation has 5 modes whereas in strong they’re all equivalent. Most programmers can barely write simple atomic code and the weak memory model is trickier to wrap one’s head around (at least I still struggle to properly understand it vs using high level shortcut heuristics). A strong memory model is also trivial to implement on a weak memory system whereas the reverse is impossible. I can believe that Java on ARM can have bugs (fewer customers, relatively newer than x86, etc). It can also have bugs due to someone writing weak operations that were only tested on a strong memory model machine (ie latent bugs that wouldn’t be discovered on a weak memory model machine). Or heck. It can have bugs precisely because someone wants to somehow leverage weak operations for performance butt it did so incorrectly. Side note: The M1 is an interesting CPU because it implements both strong and weak memory models directly in HW. I don’t know why you got downvotes but what you provided was more of an opinion than fact (my post too is opinion).

bitcharmer 5y ago
> SW running against a strong memory model is actually simpler and less buggy than SW written against a weak memory model This is exactly what my comment is implying. On x86 you have a very strong memory ordering consistency in the form of TSO. This not only helps implementing synchronisation primitives but also in practice enables techniques such as synchronisation piggybacking which isnt safe on weaker models such as ARM's. > what you provided was more of an opinion than fact Don't really know how to respond to that beyond if the differences between memory models are a matter of opinion rather than facts than the following wiki page shouldn't even exist https://en.m.wikipedia.org/wiki/Memory_ordering https://en.m.wikipedia.org/wiki/Memory_ordering
- vlovich123 5y ago
  I think you misunderstood what I was saying. Implementing a strong memory model on a weak memory model system is trivial. I’m not sure what point you’re trying to make that Java somehow using a strong memory model for the language causes problems for porting the VM to ARM with a weaker model. Any porting issues would result from them trying to eke out more performance and trying to take advantage of weaker atomic ops in the C implementation of the VM (a strong memory model by the way is widely accepted as being an incorrect abstraction for the HW because it leaves so much room on the floor - x86 is stuck due to back compat reasons). None of this would be visible to running Java programs themselves and arguable Java choosing a strong consistency model is the right choice considering how much of a foot gun a weak memory model implies. A factual post might try to back up the claim with specific bugs or more detailed analysis that has been done.