On Tue, Mar 23, 2010 at 13:32, Xueming Shen <xueming.s...@sun.com> wrote: > 6937112: String.lastIndexOf confused by unpaired trailing surrogate > > Kinda guess that it might bring us some performance benefit to separate the > supplementary handling > code out into its own method (to help the not that smart hotspot:-)?), but > doubt it is really something > worth doing. At least you dont have to have the redundant > value/offset=this.value/offset.
Yes, this is an "extreme" optimization, but one that is used pervasively in java.util.concurrent (Doug Lea's influence) and suitable for performance-critical methods. It's only downside is the increase in size of source code. (bytecode is actually smaller) > Seems like you started to attach the "final" keyword to all > "constants"...guess it's a hint to help smart > vm for further optimization. Is the hotspot doing something special in > simple case like below? The "final" is there purely for software engineering reasons, so that people don't make the common mistake of modifying a field cached in a local, which would have no effect. Martin > -Sherman > > Martin Buchholz wrote: >> >> For a change, here's an actual plain old "incorrect result" bug fix >> for String.lastIndexOf >> >> Sherman, please file a bug and review. >> >> http://cr.openjdk.java.net/~martin/webrevs/openjdk7/lastIndexOf/ >> >> Also includes our usual performance-oriented fiddling. >> >> public class LastIndexOf { >> public static void main(String[] args) { >> int ch = 0x10042; >> char[] bug = new char[3]; >> Character.toChars(ch, bug, 0); >> bug[2] = bug[0]; >> System.out.println(new String(bug).lastIndexOf(ch)); >> bug[2] = '!'; >> System.out.println(new String(bug).lastIndexOf(ch)); >> } >> } >> ==> javac -source 1.6 -Xlint:all LastIndexOf.java >> ==> java -esa -ea LastIndexOf >> -1 >> 0 >> > >
