Имеется в виду ситуация, когда оба объекта — и StringByReference и Memory уже недоступны из root-ов, но один из них ссылается на другого.
В этот момент уже пора вызывать финализаторы, т.к. уже пора собирать оба эти объекта. Иначе мы бы столкнулись с проблемой циклического мусора: могла бы быть пара объектов A <-> B, ссылающихся друг на друга, но ниоткуда больше недоступных. Если ждать, пока ссылки пропадут совсем, то они так навсегда и осядут в куче, ведь ссылки на каждый из этих объектов будут всегда. Трассирующие GC как раз решают эту проблему, проверяя достижимость от корневых объектов.
1) если подсчет Фибоначчи оставить в Java, то получаем 509.744 ops/us (вызовов нет, а код хорошо специализировался).
2) если вынести подсчет в другой Java метод, повесить на него @CompilerControl(Mode.DONT_INLINE) (ну, чтобы немного уравнять шансы), то получаем уже всего 52 ops/us.
3) ну и вызов натива остается 45 ops/us.
Мерю все на Intel Core i7-7700 @ 3.60 GHz, т.е. на x64.
В принципе можно перемерить на арме, но что-то мне подсказывает, что там все будет хуже.
да, во второй части будет немного про Panama и в том числе про Foreign Memory.
но это будет буквально пара абзацев и бенчи, поэтому про эту тему рекомендую расшифровку большого доклада Вовы Иванова про всю Panama. И еще его же доклад именно про Foreign Memory (его расшифровки, к сожалению, пока нет).
На данный момент комментировать эту ситуацию мы, к сожалению, все еще не можем.
Замечу, что доклад был на нейтральную тему: о проблемах с GC вообще, а не в какой-то конкретной JVM. Поэтому ситуация вокруг Excelsior на него особо не повлияла.
Производительность же реального приложения зависит от множества факторов: плоский или нет профиль, насколько большая нагрузка на GC, какой размер кучи, важна нам производительность на старте или после прогрева, готовы ли мы использовать PGO и т.д.
Поэтому у нас нет какого-то публичного набора бенчей, который бы мы всем демонстрировали (приватные, конечно, есть, используем их для контроля изменения производительности во время разработки). Вместо этого мы всегда предлагаем людям взять свое приложение, скомпилировать JET-ом, прогнать типичный сценарий и посмотреть, что с производительностью. В зависимости от характера приложения производительность может улучшаться или ухудшаться по сравнению, например, с HS.
назовите 3 книги по JAVA где написано, что область действия переменной НЕРАВНА области видимости
JLS считается за такую книжку? Думаю, ее можно засчитать за три. Вот там в параграфе 12.6.1 (спасибо @shipilev за наводку) сказано:
Optimizing transformations of a program can be designed that reduce the number of objects that are reachable to be less than those which would naively be considered reachable. For example, a Java compiler or code generator may choose to set a variable or parameter that will no longer be used to null to cause the storage for such an object to be potentially reclaimable sooner.
Лично мне не совсем понятно, почему Вы считаете, что выживание переменных в области видимости, — это какой-то «принцип» или «концепция», которую бессовестно сломали при реализации. Так сделано в C++, например, но нас то это ни к чему не обязывает.
В этот момент уже пора вызывать финализаторы, т.к. уже пора собирать оба эти объекта. Иначе мы бы столкнулись с проблемой циклического мусора: могла бы быть пара объектов A <-> B, ссылающихся друг на друга, но ниоткуда больше недоступных. Если ждать, пока ссылки пропадут совсем, то они так навсегда и осядут в куче, ведь ссылки на каждый из этих объектов будут всегда. Трассирующие GC как раз решают эту проблему, проверяя достижимость от корневых объектов.
Скоро еще планирую написать пост «behind the scenes». В нем расскажу про всякие интересные наблюдения, которые я сделал, пока все это мерил и изучал.
У меня в этой части посыл скорее, что не нужно думать, натив прям принесет счастье и гарантированное ускорение, на самом деле не все так просто.
Ну и да, на самом деле JNI то не так плох в плане производительности, как некоторые библиотеки, которые на нем базируются. Про это во второй части.
1) если подсчет Фибоначчи оставить в Java, то получаем 509.744 ops/us (вызовов нет, а код хорошо специализировался).
2) если вынести подсчет в другой Java метод, повесить на него @CompilerControl(Mode.DONT_INLINE) (ну, чтобы немного уравнять шансы), то получаем уже всего 52 ops/us.
3) ну и вызов натива остается 45 ops/us.
Мерю все на Intel Core i7-7700 @ 3.60 GHz, т.е. на x64.
В принципе можно перемерить на арме, но что-то мне подсказывает, что там все будет хуже.
Отвечу цифрами, которые есть под рукой (из второй части доклада):
Вызов пустого натива — 119 ops/us,
Вызов натива, в котором считается 100-ое число Фибоначчи — 45 ops/us.
Т.е. видно, что просадка уже в 2.5 раза, но вызов натива здесь все еще играет большую роль.
В целом, конечно, чем больше операций в нативном методе, тем меньшую роль играет переход из Java конекста в Native (и обратно).
но это будет буквально пара абзацев и бенчи, поэтому про эту тему рекомендую расшифровку большого доклада Вовы Иванова про всю Panama. И еще его же доклад именно про Foreign Memory (его расшифровки, к сожалению, пока нет).
вообще, на мой взгляд именно для связи с C++ кодом javacpp — это лучше, что есть сейчас.
Замечу, что доклад был на нейтральную тему: о проблемах с GC вообще, а не в какой-то конкретной JVM. Поэтому ситуация вокруг Excelsior на него особо не повлияла.
Производительность же реального приложения зависит от множества факторов: плоский или нет профиль, насколько большая нагрузка на GC, какой размер кучи, важна нам производительность на старте или после прогрева, готовы ли мы использовать PGO и т.д.
Поэтому у нас нет какого-то публичного набора бенчей, который бы мы всем демонстрировали (приватные, конечно, есть, используем их для контроля изменения производительности во время разработки). Вместо этого мы всегда предлагаем людям взять свое приложение, скомпилировать JET-ом, прогнать типичный сценарий и посмотреть, что с производительностью. В зависимости от характера приложения производительность может улучшаться или ухудшаться по сравнению, например, с HS.
JLS считается за такую книжку? Думаю, ее можно засчитать за три. Вот там в параграфе 12.6.1 (спасибо @shipilev за наводку) сказано:
Лично мне не совсем понятно, почему Вы считаете, что выживание переменных в области видимости, — это какой-то «принцип» или «концепция», которую бессовестно сломали при реализации. Так сделано в C++, например, но нас то это ни к чему не обязывает.