Здравствуйте, ·, Вы писали:
EP>>>>Об этом и речь — что по регионам, а не отдельным затронутым объектам. Поэтому я и сказал "малом количестве", а не в одном.
EP>>>>И то — это отслеживание имеет свою цену, которая размазывается по всему коду.
dot>>>Я уже упоминал, что gc плохо работает в случае большого числа короткоживущих и толпы долгоживущих. При наличии среднеживущих — производительность падает.
EP>>А как ты называешь объекты которые живут долго, но не до конца работы приложения?
dot>Old Gen. Данные этих объектов можно менять свободно, но не трогать сильно указатели.
Так они долгоживущие по твоей терминологии или нет?
dot>>>Это можно лечить настройкой GC, испоьзованием разных приёмов (flyweight или пулов например)
EP>>Причём тут flyweight? Объекты-то изменяются.
dot>Смотря как изменяются.
flyweight-ы обычно неизменяемые.
EP>>>>При логарифмической сложности между N=1000 и N=1000000 — разница примерно в два раза. А в случае же линейной сложности — примерно в тысячу раз 
EP>>>>Feel the paindifference.
dot>>>Бывает. Лечится. Алгоритмы — сила.
EP>>Конечно сила, о чём я тебе и говорю.
EP>>И при логарифмической сложности, и при линейной, чем больше N тем медленнее — но разница между ними колоссальная. И в результате ситуации совершенно разные, а ты говоришь "тоже не поздоровится"
dot>Так вот строгость ссылок явы позволяет применять гораздо более хитрые алгоритмы.
Например?
EP>>>>А зачем обмениваться практически мёртвыми объектами?
dot>>>В смысле? Какие уж есть.
EP>>Контекст потерял? Ещё раз.
EP>>У нас есть объект, счётчик ссылок которого ушёл в ноль. Так? Зачем обмениваться им с другими рабочими потоками?
dot>Так ты не знаешь в каком именно потоке и когда он уйдёт в ноль и что именно произойдёт в момент ухода в ноль. В этом и суть GC. Да, узнать можно, но это очень трудоёмко. Компьютер с этим справляется в подавляющем большинстве случаев лучше и надёжнее.
Ещё раз, зачем обмениваться практически мёртвыми объектами между рабочими потоками?
EP>>>>Критический поток поставит его в очередь, а сам удалять не будет.
dot>>>И возникнет та же проблема, которой ты меня мучил — а что если он будет ставить в очередь быстрее, чем эта очередь разгребаться?
EP>>Проблема вообще-то была в другом. Если по аналогии — в том что грубо говоря pop одного элемента очереди линейно зависит от её размера. Здесь же такой зависимости нет.
dot>Не одного элемента, а всей очереди. GC за цикл собирает не один объект.
Чтобы убрать малое колличество мусорных объектов, GC приходится обходить большое количество живых. И скорость сбора мусорных объектов зависит от количества живых. В этом и аналогия.
dot>>>>>>>Хорошо, не подзадача, а средство достижения заявленных характеристик.
EP>>>>>>Короче, не нужно сами эти средства называть GC. Другой пример — копирующий аллокатор может быть без GC.
dot>>>>>Я говорю это к тому, что эти средства уже доступны при использовании GC.
EP>>>>Аналогия: "когда нарезаешь массив на структуру, переизобретаешь C++"
dot>>>Не С++. Почему именно С++, а не С, не Алгол, не Фортран, не Паскаль, не ассемблер?
EP>>Аналогично — а почему тогда GC?
dot>Потому что управление памятью — трудоёмкий процесс в прикладных приложениях. Автоматизировать его — дело святое.
EP>>Какой объем реализации? На C++ — меньше ста строк.
dot>Ну вот... сейчас ещё начнём строки считать... увольте.
Достаточно грубой прикидки. Если объём отличается на порядки — то с тем же успехом можно и компилятор модифицировать.
EP>>Да и не сравнится ведь:
EP>>EP>>@m int meters = 5 * UnitsTools.m;
EP>>
EP>>vs
EP>>EP>>auto length = 5m;
EP>>
EP>>Да и нет интеграции в систему типов — например перегрузка не работает
dot>Перегрузка чего? Это же примитивы.
На C++ это отдельные типы. И по разным типам можно сделать разные перегрузки.
dot>И вообще, чего опять о языке, мы же о GC вроде? Ну возьми Скалу, там есть перегрузка.
Ты же сказал что "и прочие С++ фишки можно реализовать в java" — мы в этой ветке сейчас и находимся.
