optimize command-line flag checking in compiler using ConstantCallSite

[adriaanm]

@retronym suggests we use https://community.oracle.com/blogs/forax/2011/12/17/jsr-292-goodness-almost-static-final-field to hide our instrumentation better from the JIT.

A lot of compiler settings are constant false in most compiler runs, yet they must be checked all the time. We could help the JIT using the above technique.

(See e.g., https://github.com/scala/scala/pull/5204)

[DarkDimius]

@retronym, smart idea!

[retronym]

Aside from super hot methods, I don't hold out too much hope that we'll see big gains over and above what HotSpot would do for a conditional with a 100% biased profile. I do think we can see some gains in how fast we warm up by making sure that seldom chosen branches just delegate to a method, rather than directly contain the code.

if (usuallyTrue) { foo; bar; baz } else {rarelycalled() }

[sjrd]

Just pointing out that this will make it harder to compile scalac with non-JVM backends (duh, I can't just write "Scala.js" in those cases anymore ^^). It would be good if the way this is implemented is well isolated somewhere where it is easy to change the implementation for different platforms. (as opposed to spread this implementation detail all over the place)

[adriaanm]

Definitely!

[som-snytt]

In REPL, user would like to turn options on and off, from line to line. But you never know if a flag is cached.

Sample anti-pattern https://github.com/som-snytt/scala/blob/b462e5a97b499bc91222014e45ec2439f56b46b7/src/repl/scala/tools/nsc/interpreter/ILoop.scala#L955

[adriaanm]

Yep, whatever mechanism we come up with should support embedded scenarios (as in your REPL improvement)

[som-snytt]

That was of course in response to an exigent need (https://gitter.im/scala/scala?at=5751ddff9be9c5b637f03d13)