Почему StringBuilder#append (int) быстрее в Java 7, чем в Java 8?

во время расследования для спор w. r. t. using "" + n и Integer.toString(int) чтобы преобразовать целочисленный примитив в строку, я написал это 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;

    }

}

я запустил его с параметрами JMH по умолчанию с обоими виртуальными машинами Java, которые существуют на моей машине Linux (современный Mageia 4 64-бит, Процессор Intel i7-3770, 32 ГБ оперативной памяти). Первая Java-машина была одна поставляется с Oracle версии JDK
8u5 64-разрядная:

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)

С этим JVM я получил в значительной степени то, что я ожидал:

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

то есть с помощью StringBuilder класс медленнее из-за дополнительных накладных расходов на создание StringBuilder объект и добавление пустой строки. Используя String.format(String, ...) еще медленнее, на порядок или около того.

компилятор, предоставляемый дистрибутивом, с другой стороны, основан на 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)

результаты здесь были интересные:

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

почему StringBuilder.append(int) появляются намного быстрее с этим JVM? Глядя на StringBuilder исходный код класса не выявил ничего особенно интересного-метод, о котором идет речь, почти идентичен Integer#toString(int). Что интересно, добавляя результат Integer.toString(int) (the stringBuilder2 microbenchmark) не кажется, чтобы быть быстрее.

является ли это несоответствие производительности проблемой с тестовым жгутом? Или мой OpenJDK JVM содержит оптимизации, которые повлияют на этот конкретный код (анти)-шаблон?

EDIT:

для более прямого сравнения я установил 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)

результаты аналогичны результатам 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

кажется, что это более общая проблема Java 7 против Java 8. Возможно, Java 7 имела более агрессивную оптимизацию строк?

EDIT 2:

для полноты описания ниже приведены параметры виртуальной машины, связанные со строками оба эти СПМ:

для 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}

Для 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}   

The UseStringCache опция была удалена в Java 8 без замены, поэтому я сомневаюсь, что это имеет какое-либо значение. Остальные параметры имеют одинаковые параметры.

EDIT 3:

параллельное сравнение исходного кода AbstractStringBuilder,StringBuilder и Integer классы src.zip файл ничего не показывает примечательно. Помимо целого ряда косметических и документальных изменений,Integer теперь есть некоторая поддержка для целых чисел без знака и StringBuilder был немного переработан, чтобы поделиться больше кода с StringBuffer. Ни одно из этих изменений не влияет на пути кода, используемые StringBuilder#append(int), хотя я что-то пропустил.

сравнение кода сборки, созданного для IntStr#integerToString() и IntStr#stringBuilder0() гораздо интереснее. Основной макет кода, сгенерированного для IntStr#integerToString() был похож на обе виртуальные машины, хотя Oracle версии JDK 8u5, казалось, быть более агрессивным Вт.Р.Т. встраивание некоторые звонки внутри Integer#toString(int) код. Было четкое соответствие с исходным кодом Java, даже для кого-то с минимальным опытом сборки.

код сборки для IntStr#stringBuilder0(), однако, было радикально иначе. Код, сгенерированный Oracle JDK 8u5, снова был напрямую связан с исходным кодом Java - я мог легко распознать тот же макет. Напротив, код, сгенерированный OpenJDK 7 был почти неузнаваем для нетренированного глаза (как и мой). Элемент new StringBuilder() вызов был, казалось бы, удален, как и создание массива в StringBuilder конструктор. Кроме того, плагин дизассемблера не смог предоставить столько ссылок на исходный код, как это было в JDK 8.

я предполагаю, что это либо результат гораздо более агрессивного прохода оптимизации в OpenJDK 7, либо, скорее всего, результат вставки рукописного кода низкого уровня для некоторых StringBuilder оперативный. Я не уверен, почему эта оптимизация не происходит в моей реализации JVM 8 или почему те же оптимизации не были реализованы для Integer#toString(int) в JVM 7. Я думаю, что кто-то, знакомый с соответствующими частями исходного кода JRE, должен был бы ответить на эти вопросы...