Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Interpreter: volatile ldobj appears to have incorrect semantics? #34
Going by Ecma 335 III.4.13, it is my understanding that a sequence like
should produce a volatile load. While one could argue that it's a store (the spec says "copy the value stored at address
The relevant code:
The interpreter is not a production quality code - it is not enabled in shipping bits. It is only meant to be used for initial bring up of new platforms, until the JIT starts working. If you would like to play with it or fix bugs in it, it can be enabled in src\inc\switches.h.
referenced this issue
Feb 7, 2015
There is certainly a bug in any case. The issue is that for a load-acquire, the barrier must come after the load. Conversely, for a store-release, the barrier must come before the store. The interpreter gets this the wrong way around for
There is no bug with regards to atomicity. The issue is just the placement of the memory barriers.
Should the bug be fixed? Well, if the code is not really used, it might not be worth the effort. On the other hand, it can be quite misleading to people who come across this code and think that it's a good reference to base their work on. So, I don't know. It's up to the maintainers.
@alexrp thanks. Yes you're correct. This code is not used in production however and I don't believe there would be any issue on an Intel based architecture due to the strongly ordered memory architecture. ARM could have a problem however.
We should still fix the bug so let's leave this active.