Implement memory effects of volatiles

[intrigus]

volatiles have certain memory effects when being read or when being written to.
For this we have to use some low-level stuff to implement the needed memory barriers.

See

• http://gee.cs.oswego.edu/dl/jmm/cookbook.html
• https://github.com/ReadyTalk/avian/blob/cbcc15bf7455bb10ae280a2813c00f4d4bb262d7/src/avian/x86.h#L245
• https://github.com/ReadyTalk/avian/blob/cbcc15bf7455bb10ae280a2813c00f4d4bb262d7/src/avian/arm.h#L101
• Hotspot? Not sure where they define which barriers to use.
• Robovm? https://github.com/MobiVM/robovm/blob/45b1de02cad5d857918d7604414404323c75f715/compiler/vm/core/include/robovm/atomic.h
• DalvikVM?
• Android Runtime?

[soywiz]

What about replacing field access by a couple of synthetic synchronized methods getter/setter and implement it as a programfeature for targets that do not implement volatile in a more performant way?

[intrigus]

To be honest I don't really care about haxe or other targets. (Except maybe C# and c++)
That's why I'm not sure whether haxe does support synchronized.
It may be theoretically possible to replace volatile with synchronized but there are other parts of the Java Memory Model which have certain memory effects, e.g. writing to a final field.

So I'd like to ask how you intend to implement synchronized for the haxe target?
I don't want to be negative but I don't think that haxe can implement this part of the JMM or the JMM at all.

[soywiz]

The most basic primitive is the enter/exit monitor. The idea is to provide those two functions in N native class and use defines to chose the right implementation (when suitable). Javascript for example doesnt require it. But c++ can use it.
http://api.haxe.org/cpp/vm/Mutex.html
Until C++ target is mature (for example tools to target ios and or android native), we need to use Haxe/C++ for it.
For me, the most important targets are Js, C++ and C# and the usefulness of other targets are to be able to run java libraries in other languages.

[ghost]

For me not general language, for me need iOs, tvOS, windows native, Android, we spend 6 mouths and after 1 months we will be release... And we can not spend time for non Haxecpp targets, and very very need sync in jtransc. Thanks.

[intrigus]

What do you mean with "tools to target ios and or android native"?
Which tools do you think are needed to mature the cpp target?

[soywiz]

Yep thats why i want to support haxe target too. Until all that effort is backported we need to support haxe too. But even later i dont see problems supporting haxe too. Libgdx+libs like payments working on those platforms without modified code, providing app icons, one command for deploying... Those things. After implementing these required things + full java8 support i can help with toolchains to get the same experience with pure c++ target which should be supperior in runtime performance, compilation time and executable size. And if we can run original libgdx unmodified that would be even better! But it will take some months to achieve that and Sergey doesnt have that time for his release