GNU Classpath 0.98 causes performance regression in luindex

There's no obvious candidate for this from the NEWS:

• Native support for BigInteger is now provided using the GMP
  library. A new option, --enable/disable-gmp is provided, and
  the option is enabled by default if GMP is found.
• Classpath now makes use of a new StringBuilder implementation
  internally called CPStringBuilder. In addition to being
  unsynchronised, like StringBuilder, this also avoids copying the
  array when toString or substring is called. While StringBuffer/Builder
  always retain their own array, which is only altered during resizing,
  CPStringBuilder gives away its array when the result is generated
  by toString()/substring() and starts afresh. The default capacity of
  CPStringBuilder can also be configured using the
  gnu.classpath.cpstringbuilder.capacity property. (PR21869)
• gjdoc is now built as part of tools.zip.
• Import of the Java Activation Framework from ClasspathX to provide
  javax.activation (part of 1.6).
• Preliminary version of java.util.Scanner (PR30436)
• Reduce cost of ThreadLocal(s) to improve Jython performance (PR33690)
• Updated to use CLDR 1.5.1 (PR35237)
• Many bug fixes including:

• PR22851: zoneStrings in gnu/java/locale/LocaleInformation*
• PR31895: setCurrency(Currency) does not actually change the currency.
• PR32028: Make fails at gjdoc
• PR34840: Mismatch between Sun and Classpath's java.lang.Appendable
• PR35487: gcj causes ConcurrentModificationException during tomcat5
• PR35690: javax.tools.FileObject.toUri is in wrong case
• PR36085: java.util.regex escape-sequence handling
• PR36147: Apache Tomcat fails to read descriptors using GNU XML
• PR36219: gnu.xml.transform.SortKey isn't subclass
• PR36220: NPEs in gnu.xml.transform.* clone methods
• PR36221: DomDOMException running SPEC jvm 2008 xml.transform
• PR36477: OOME in CPStringBuilder when running Eclipse
• PR36522: Policy file is not read at all
• PR36636: gjar -u doesn't work
• PR36637: --without-fastjar doesn't wor
• PR36677: Omission bug in JDWP VirtualMachineCommandSet
• PR38417: gnu.java.security.util.PRNG produces easily predictable values
• PR38473: Segmentation fault in retrieving font outline decomposition
• PR38861: Support XULRunner 1.9.1.
• PR38912: XMLParser not interning element names

CPStringBuilder sounds suspicious. The slowdown is due to loads of extra allocation, mostly of int arrays, char arrays, and regular expression related junk. While there is a 4-5 fold increase in the number of gcs, the total gc time increase is minimal, suggesting that most of the allocated objects are collected by the nursery ...

The types with the 5 largest number of allocators on luindex before the change:

1382143.00 Lorg/apache/lucene/analysis/standard/Token;
1386335.00 Lorg/apache/lucene/analysis/Token;
2032325.00 [I
2946683.00 Ljava/lang/String;
3206024.00 [C

and after:

1386335.00 Lorg/apache/lucene/analysis/Token;
4065076.00 Lgnu/java/lang/CPStringBuilder;
8803358.00 Lgnu/java/util/regex/REMatch;
10426018.00 Ljava/lang/String;
12033205.00 [C
27114401.00 [I

I have attached full runs with more statistics.

Could this just be that our performance was down to buggy RegEx in Classpath that's now fixed? Could you run:

rvm -X:aos:gather_profile_data=true -X:aos:final_report_level=1 -jar dacapo.jar -n 10 luindex 2>&1 | egrep "^[0-9].[0-9] (" | sort -n | grep -v OBSOLETE |tail -n 20;

for the two builds so we can see what the change in the hottest methods is?

With nightly CVS head regressions the exact patch for Classpath would have shown up. There are one years worth of patches to Classpath that could have led to performance regressions.

http://cvs.savannah.gnu.org/viewvc/classpath/classpath/java/lang/String.java?r1=1.88.2.1&r2=1.91
http://cvs.savannah.gnu.org/viewvc/classpath/classpath/gnu/java/util/regex/REMatch.java?r1=1.4&r2=1.2

The only changes in these classes relate to the switch to CPStringBuilder and a slight refactoring of String to support the two new 1.6 constructors. I thought JikesRVM had been applying such patches beforehand. Performance should be being tracked on CVS Classpath; there is about a year of possible patches that could have caused this.

One immediate observation is that they've followed the same Jikes RVM unfriendly coding pattern in CPStringBuilder as we corrected in previous patches for java.util.Vector and java.util.ArrayList. There's exception raising code that needs to be outlined so we can inline the common code paths of key methods. I suspect this is blocking scalar replacement of the CPStringBuilder objects.

Will work on a patch to fix CPStringBuilder and see if it helps overall performance.

At least one major issue is that CPStringBuilder isn't in the primoridials, but the regex code is. Therefore, we generate code in the bootimage that is full of unresolved news, etc. to CPStringBuilder.

Still validating that this fixes the problem, but am optimistic.....the key methods in the actual Regex package don't seem to have changes that much between 97.2 and 98.0.

bulk defer open issues to 3.1.2

Bulk defer to 3.1.3; not essential to address for 3.1.2.

bulk defer issues to 3.1.4