Комментарии 6
В Java 11 тоже воспроизводится (естественно), но при запуске в режиме single-file (который без компиляции в файл) обходной манёвр с -XDstringConcat=inline уже не сработает:
$ java -XDstringConcat=inline Disturbed.java
Unrecognized option: -XDstringConcat=inline Error: Could not create the Java Virtual Machine. Error: A fatal exception has occurred. Program will exit.
In source-file mode, any additional command-line options are processed as follows:
The launcher scans the options specified before the source file for any that are relevant in order to compile the source file.
- This includes:
--class-path,--module-path,--add-exports,--add-modules,--limit-modules,--patch-module,--upgrade-module-path, and any variant forms of those options. It also includes the new--enable-previewoption, described in JEP 12.- No provision is made to pass any additional options to the compiler, such as
-processoror-Werror.
Источник: The java Command
Целью было сделать возможной оптимизацию конкатенации строк без необходимости перекомпиляции программ из исходников. Обновил JDK — увеличил производительность.
Вот этот момент непонятен. Из остального текста статьи как раз следует, что при компиляции разными версиями получаем разную логику в байткоде. А если просто обновил JDK и запускаю старый байткод -- ничего не поменяется же?
На байткод, использующий StringBuilder без перекомпиляции этот не повлияет, да.
Задумка в том, что новые версии классов мы компилируем уже с использованием механизма из JEP 280. Это логичное допущение, т. к. кругом Continuous Integration и классы перекомпилируются часто.
Этот механизм через invokedynamic вызывает код стандартной библиотеки (тот самый java.lang.invoke.StringConcatFactory), а уже его реализацию можно улучшать и оптимизировать, не требуя перекомпиляции использующих его классов.
И его действительно время от времени дорабатывают: History for StringConcatFactory.java
Большое спасибо за статью!
Сюрпризы конкатенации