We now have the exception for jdk.compiler, which builds with "legacy" concat.
This is done to test JDK first, without risking breaking a compiler itself. We may want to reconsider this going forward, after ISC stabilizes.
Comments
The counter-argument is, why use a really complicated mechanism when something really simple will do just as well.
24-05-2016
I actually think in reverse: the less special cased build steps (e.g. compiling product javac with special options), the better. So, if there is no perf regression, then we are better off using defaults. This is not a pressing issue, since no performance / functionality is on stake here.
24-05-2016
So if there is no significant difference, does that mean there's no significant motivation to change?
24-05-2016
javac benchmarks show no significant difference with ISC enabled:
Baseline: 40.719 ± 0.929 s/op
ISC enabled: 40.756 ± 1.015 s/op
ISC enabled + MH_INLINE_SIZED_EXACT (JDK-8148604): 40.968 ± 1.151 s/op
16-05-2016
Take care to distinguish compilation of the "interim javac", used to build JDK itself while running on the boot JDK, from the "product javac" put into the final product.