JDK-8081736 : Figure out the best code shape for a kill switch
  • Type: Sub-task
  • Component: core-libs
  • Sub-Component: java.lang
  • Priority: P4
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2015-06-02
  • Updated: 2015-07-08
  • Resolved: 2015-07-08
Related Reports
Relates :  
JDK-8130273 - multiply -> shift reduction fails with complex control flow
Relates :  
JDK-8087309 - Constant folding "static final boolean" in boolean expressions is incomplete
Description
There should be an option that turns off the compact Strings functionality.

I.e. when user provides -XX:-ForceUTF16Strings, the implementation should default to UTF-16 unconditionally. This should serve as the safety net for users who experience performance regressions with compact strings. We have to investigate what is the best code shape for this kill switch to work in a performant way for both "on" and "off" modes.
Comments
Committed by Sherman: http://hg.openjdk.java.net/jdk9/sandbox/jdk/rev/b0a49f07847d http://hg.openjdk.java.net/jdk9/sandbox/hotspot/rev/387da3650bc3
08-07-2015
Update: http://cr.openjdk.java.net/~shade/8081736/webrev.hotspot/ http://cr.openjdk.java.net/~shade/8081736/webrev.jdk/ Passes jtreg tests now.
30-06-2015
Prototyped the change, see here: http://cr.openjdk.java.net/~shade/8081736/hotspot.patch http://cr.openjdk.java.net/~shade/8081736/jdk.patch Observations: *) It makes sense to follow usual practice, and call the flag (Use)CompactStrings, with default = true. *) One cannot make "static final" constant in String, and overwrite it with a VM call: if that constant participates in expression, javac would (and does) fold it; VM comes too late; *) Some trickery is required to init a "static final" constant in String, since it is a primordial class. So far the best choice is to make the call into VM (but that requires new VM interface method...) *) It makes sense to set coder == UTF16 everywhere, to cover all the code cases around JDK, otherwise we would be wasting time conditionalizing coder selections. *) In some selected places, it makes sense to put the flag right into condition, to let compiler fold it. *) Until JDK-8087309 is fixed, one should be very careful with the code shape to use. We are using "if (FLAG && pred)" and "if (FLAG || pred)" conditions, that are folded nicely. More (still not carefully explained) performance data, taking String::equals as the example are here: http://cr.openjdk.java.net/~shade/8081736/notes.txt
25-06-2015
JDK-8087309 gets in the way, and needs to be addressed.
12-06-2015