Здравствуйте, Serginio1, Вы писали:

S>>> Я могу использовать манакед GC и нативный менеджер памяти. Это расширяет возможности.
S>·>Можешь ровно до того момента как ты не столкнёшься в LL-задачей.
S> Ну вот тебе на это кстати vdimas приводит примеры.
Он какие-то странные примеры приводит. В одном примере так вообще производительность pure-java оказалась близкой к C++.

S>·>С текущей реализацией GC ты не можешь решить эту задачу с использованием dotnet managed GC.
S> Можно. И кстати та же самая статья говорит, что можно.
Цитату плз.

S>>>На обычных задачах GC справляется.
S>·>В реальном приложении всегда есть что собирать. Он справляется, но он не гарантирует задержек меньше 10мс. Azul — гарантирует.
S> Ну вот статья то как раз говорит, что может на нормальных данных.
Цитату плз.

S>·>На джаве тоже можешь написать код с копированием. Но суть теста в том, что он создаёт мусор, который нужно собирать. И во время сборки stop-the-world не должен тормозить работающие треды на время большее 10мс.
S> А вот в примере данные данные не будут менять ссылок. И по сути вся сборка мусора сводится к переносу начала кучи. Ничего дефрагментировать не надо.
Ты хочешь сказать, что можно взять любой код и легко переписать его таким образом, что дефрагметация не будет происходить?
Ещё раз — тест призван выяснить — что происходит, когда таки gc должен собрать мусор и дефрагментировать.