¿Por qué StringBuilder # append (int) es más rápido en Java 7 que en Java 8?

Mientras investigaba para un pequeño debate w. r. t. usando "" + n y Integer.toString(int) para convertir un entero primitivo a una cadena escribí esto JMH microbenchmark:

@Fork(1)
@OutputTimeUnit(TimeUnit.MILLISECONDS)
@State(Scope.Benchmark)
public class IntStr {
    protected int counter;


    @GenerateMicroBenchmark
    public String integerToString() {
        return Integer.toString(this.counter++);
    }

    @GenerateMicroBenchmark
    public String stringBuilder0() {
        return new StringBuilder().append(this.counter++).toString();
    }

    @GenerateMicroBenchmark
    public String stringBuilder1() {
        return new StringBuilder().append("").append(this.counter++).toString();
    }

    @GenerateMicroBenchmark
    public String stringBuilder2() {
        return new StringBuilder().append("").append(Integer.toString(this.counter++)).toString();
    }

    @GenerateMicroBenchmark
    public String stringFormat() {
        return String.format("%d", this.counter++);
    }

    @Setup(Level.Iteration)
    public void prepareIteration() {
        this.counter = 0;
    }
}

Lo ejecuté con las opciones predeterminadas de JMH con ambas máquinas virtuales Java que existen en mi máquina Linux (Mageia 4 de 64 bits actualizada, CPU Intel i7-3770, 32 GB de RAM). La primera JVM fue la suministrada con Oracle JDK 8u5 64-bit:

java version "1.8.0_05"
Java(TM) SE Runtime Environment (build 1.8.0_05-b13)
Java HotSpot(TM) 64-Bit Server VM (build 25.5-b02, mixed mode)

Con esta JVM tengo más o menos lo que esperado:

Benchmark                    Mode   Samples         Mean   Mean error    Units
b.IntStr.integerToString    thrpt        20    32317.048      698.703   ops/ms
b.IntStr.stringBuilder0     thrpt        20    28129.499      421.520   ops/ms
b.IntStr.stringBuilder1     thrpt        20    28106.692     1117.958   ops/ms
b.IntStr.stringBuilder2     thrpt        20    20066.939     1052.937   ops/ms
b.IntStr.stringFormat       thrpt        20     2346.452       37.422   ops/ms

Es decir, usar la clase StringBuilder es más lento debido a la sobrecarga adicional de crear el objeto StringBuilder y agregar una cadena vacía. Usar String.format(String, ...) es aún más lento, por un orden de magnitud más o menos.

El compilador proporcionado por la distribución, por otro lado, se basa en OpenJDK 1.7:

java version "1.7.0_55"
OpenJDK Runtime Environment (mageia-2.4.7.1.mga4-x86_64 u55-b13)
OpenJDK 64-Bit Server VM (build 24.51-b03, mixed mode)

Los resultados aquí fueron interesantes :

Benchmark                    Mode   Samples         Mean   Mean error    Units
b.IntStr.integerToString    thrpt        20    31249.306      881.125   ops/ms
b.IntStr.stringBuilder0     thrpt        20    39486.857      663.766   ops/ms
b.IntStr.stringBuilder1     thrpt        20    41072.058      484.353   ops/ms
b.IntStr.stringBuilder2     thrpt        20    20513.913      466.130   ops/ms
b.IntStr.stringFormat       thrpt        20     2068.471       44.964   ops/ms

¿Por qué StringBuilder.append(int) aparece mucho más rápido con esta JVM? Mirando el código fuente de la clase StringBuilder no reveló nada particularmente interesante-el método en cuestión es casi idéntico a Integer#toString(int). Curiosamente, agregar el resultado de Integer.toString(int) (el stringBuilder2 microbenchmark) no parece ser más rápido.

¿Es esta discrepancia de rendimiento un problema con el arnés de prueba? ¿O mi JVM OpenJDK contiene optimizaciones que afectarían a este código en particular (anti)-patrón?

EDITAR:

Para una comparación más sencilla, instalé Oracle JDK 1. 7u55:

java version "1.7.0_55"
Java(TM) SE Runtime Environment (build 1.7.0_55-b13)
Java HotSpot(TM) 64-Bit Server VM (build 24.55-b03, mixed mode)

Los resultados son similares a los de OpenJDK:

Benchmark                    Mode   Samples         Mean   Mean error    Units
b.IntStr.integerToString    thrpt        20    32502.493      501.928   ops/ms
b.IntStr.stringBuilder0     thrpt        20    39592.174      428.967   ops/ms
b.IntStr.stringBuilder1     thrpt        20    40978.633      544.236   ops/ms

Parece que este es un problema más general de Java 7 vs Java 8. Tal vez Java 7 tenía optimizaciones de cadenas más agresivas?

EDITAR 2:

Para completar, aquí están las opciones de VM relacionadas con cadenas para ambas JVM:

Para Oracle JDK 8u5:

$ /usr/java/default/bin/java -XX:+PrintFlagsFinal 2>/dev/null | grep String
     bool OptimizeStringConcat                      = true            {C2 product}
     intx PerfMaxStringConstLength                  = 1024            {product}
     bool PrintStringTableStatistics                = false           {product}
    uintx StringTableSize                           = 60013           {product}

Para OpenJDK 1.7:

$ java -XX:+PrintFlagsFinal 2>/dev/null | grep String
     bool OptimizeStringConcat                      = true            {C2 product}        
     intx PerfMaxStringConstLength                  = 1024            {product}           
     bool PrintStringTableStatistics                = false           {product}           
    uintx StringTableSize                           = 60013           {product}           
     bool UseStringCache                            = false           {product}   

La opción UseStringCache se eliminó en Java 8 sin reemplazo, por lo que duda que hace alguna diferencia. El resto de las opciones parecen tener la misma configuración.

EDITAR 3:

Una comparación lado a lado del código fuente de la AbstractStringBuilder, StringBuilder y Integer clases del archivo src.zip de no revela nada noteworty. Aparte de una gran cantidad de cambios cosméticos y de documentación, Integer ahora tiene soporte para enteros sin signo y StringBuilder ha sido ligeramente refactorizado para compartir más código con StringBuffer. Ninguno de estos cambios parece afectar la rutas de código utilizadas por StringBuilder#append(int), aunque puede que me haya perdido algo.

Una comparación del código ensamblador generado para IntStr#integerToString() y IntStr#stringBuilder0() es mucho más interesante. El diseño básico del código generado para IntStr#integerToString() era similar para ambas JVM, aunque Oracle JDK 8u5 parecía ser más agresivo w.r.t. insertando algunas llamadas dentro del código Integer#toString(int). Había una correspondencia clara con el código fuente de Java, incluso para alguien con experiencia mínima en ensamblado.

El código de ensamblaje para IntStr#stringBuilder0(), sin embargo, era radicalmente diferente. El código generado por Oracle JDK 8u5 estaba una vez más directamente relacionado con el código fuente de Java - pude reconocer fácilmente el mismo diseño. Por el contrario, el código generado por OpenJDK 7 era casi irreconocible para el ojo inexperto (como el mío). La llamada new StringBuilder() fue aparentemente eliminada, al igual que la creación del array en el constructor StringBuilder. Además, el complemento desensamblador no fue capaz de proporcionar tantas referencias al código fuente como lo hizo en JDK 8.

Asumo que esto es el resultado de un pase de optimización mucho más agresivo en OpenJDK 7, o más probablemente el resultado de insertar código de bajo nivel escrito a mano para ciertas operaciones StringBuilder. No estoy seguro de por qué esta optimización no ocurre en mi implementación de JVM 8 o por qué las mismas optimizaciones no se implementaron para Integer#toString(int) en JVM 7. Supongo que alguien familiarizado con las partes relacionadas del código fuente de JRE tendría que responder a estas preguntas...