On 7/17/19 9:06 AM, Andriy Plokhotnyuk wrote:
> 1) Using of release (and sometime store-store) fences in all constructors in 
> GraalVM:
> https://github.com/oracle/graal/blob/e9dbc9d6d3080daf22dec38ce8c234417e1a8e3c/compiler/src/org.graalvm.compiler.replacements/src/org/graalvm/compiler/replacements/DefaultJavaLoweringProvider.java#L925

I don't follow. It puts LoadStore for all constructors that store final fields 
(as expected), and
StoreStore for everything else (as expected). StoreStore is needed to protect 
the recently allocated
object metadata from the races. Note that you can see the "default" values of 
Java fields because
publishing the reference to the object may appear "before" constructor stores 
are observed. But the
same thing would be catastrophic for "metadata" stores like initial mark and 
klass words: in the
_best_ case scenario, JVM would just crash.

Graal is not alone in this, see e.g. 
https://bugs.openjdk.java.net/browse/JDK-8032481

> 2) Using of release fences in constructors or builders of immutable 
> collections in Scala 2.13:
> https://github.com/scala/scala/search?q=releaseFence%28%29&type=Code

I vaguely remember this being discussed, but cannot remember the conclusion. It 
tries to emulate
final fields without declaring them final? It does not work completely without 
LoadLoad on the
reader side 
(https://shipilev.net/blog/2014/all-fields-are-final/#_implementation_support), 
but it
is safer than not doing the release stores at all.

> The question is: Why all these fences cannot be moved to places which work 
> with concurrency
> immediately: GCs, static field initializers, concurrent data structures and 
> APIs like futures,
> actors, etc.?

I don't follow this suggestion. These fences are about surviving races (this is 
what finals are
for), and thus every follow-up access to the object is exposed on every path, 
including those that
do not deal with concurrency "immediately".     

-Aleksey

-- 
You received this message because you are subscribed to the Google Groups 
"mechanical-sympathy" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
To view this discussion on the web, visit 
https://groups.google.com/d/msgid/mechanical-sympathy/3cca63d5-0085-2387-13c1-b5dfe2d26158%40gmail.com.

Attachment: signature.asc
Description: OpenPGP digital signature

Reply via email to