Imported From: https://issues.scala-lang.org/browse/SI-7838?orig=1
Reporter: @retronym
Affected Versions: 2.10.0

@retronym said:
Rex, would you care to look into this one?

@Ichoran said:
I can, but I can't promise I'll come up with the best solution. The email thread seems pretty active; I'm happy to test supposed "best" solutions and pick the one that actually works the best.

@retronym said:
Rex: I'll mark this for 2.12. If the ML comes up with some stellar ideas we could consider 2.11, but I suppose we've lived with this for a long time, so this might be lower priority than other performance related work.

@Ichoran said:
Partial fix for List in new higher-performance map etc. methods in scala/scala#3498 (untested, though)

@retronym said:
Merging in the report of #8996

import scala.collection.immutable.$colon$colon;
import scala.collection.immutable.List;
import scala.collection.immutable.Nil$;
import scala.collection.immutable.WrappedString;
 
public class Lists {
  public static void main(String[] args) {
    Nil$ nil = Nil$.MODULE$;
    List<Object> list = new WrappedString("123456789").toList();
    System.out.println(list);
    $colon$colon $colon$colon = ($colon$colon) list;
    $colon$colon.tl_$eq(nil);
    System.out.println(list);
  }
}
Output:
List(1, 2, 3, 4, 5, 6, 7, 8, 9)
List(1)

@adriaanm said:
How about we give this @volatile tl proposal a shot? Could we do some JMH benchmarks?

@szeiger said:
Blocked on #8873

@SethTisue said (edited on Aug 12, 2016 2:18:52 AM UTC):
scala/scala#5323 documents the status quo

scala/scala#5316 was Stefan's attempt at a real fix, but was not merged. possibly to be revisited

@szeiger said:
From a comment on the PR:

You may want to mention JEP 193 and that the cheapest safe
way to pass a list to another thread is by the pair java.lang.invoke.VarHandle.setRelease
/ VarHandle.getAcquire (available in Unsafe on JDK8).
With standardization of these operations in JDK9 (Jep 193) programmers should have plenty of tools for safe concurrency.

@retronym said:
Here's a good overview of safe initialization: https://shipilev.net/blog/2014/safe-public-construction/

", we emit a trailing barrier ... A final field was written. Notice we do not care about what field was actually written, we unconditionally emit the barrier before exiting the (initializer) method"

This is a HotSpot implementation detail that makes regularly constructed lists (ie, not with tail mutation) safe to share in that VM (the write the the final field head emits the barrier). But we shouldn't rely on such details, so the documentation that "safe publication is up to the client of List" is suitable advice.

Also:

" Fastdebug build is needed to gain access to -XX:+StressLCM -XX:+StressGCM instruction scheduling fuzzers in Hotspot."

These flags have since been made available in release builds of Java 9. They are useful to avoid relying on implementation details of the compliler + processor:

"x86 is Total Store Order hardware, meaning the stores are visible for all processors in some total order. That is, if compiler actually presented the program stores in the same order to hardware, we may be reasonably sure the initializing stores of the instance fields would be visible before seeing the reference to the object itself. Even if your hardware is total-store-ordered, you can not be sure the compiler would not reorder within the allowed memory model spec. If you turn off -XX:+StressGCM -XX:+StressLCM in this experiment, all cases would appear correct since the compiler did not reorder much."

@Blaisorblade said:
Would a PR documenting this be accepted in the ScalaDocs for List be accepted?

@Ichoran said:
@Blaisorblade - Seems like a good idea to me, especially if it also covers Vector and any other affected immutable collections.

@Blaisorblade said:
Whoops — the documentation I had in mind is already in scala/scala#5323 for 2.12, and visible at http://www.scala-lang.org/api/current/scala/collection/immutable/List.html. Not sure why I missed that.

WIP PR scala/scala#6425, see also scala/collection-strawman#50

Should we remove or change Iterable comment ?

Yes!