LINUX.ORG.RU

сборка мусора - зацените идейку


1

0

Доброго!

Как я понял, поколенческая сборка мусора требует некоторых дополнительных действий при каждом создании или изменении ссылки, чтобы отследить ссылки старого объекта на молодой. Почему бы тогда не обобщить понятие «поколения» на понятие «область хранения» и не позволить пользователю явно управлять областями? Например, ввести глобальную (поточную) переменную «текущая область хранения» и всё выделение по умолчанию вести в этой области. Или добавить параметр в конструктор (хотя это требует переделки языка). Области могут быть упорядочены в иерархию и тогда нужно будет отслеживать только ссылки «старших» на «младших» по иерархии. Или они могут составлять произвольный граф и тогда нужно отслеживать все ссылки. Причём, можно отслеживать ссылки как тонко (на уровне объектов), так и грубо (на уровне областей). Например, мы знаем, что область A ссылается на область B. Тогда, чтобы собрать мусор в области B, нам нужно искать корни также в области А. Самое главное, если на область B вообще никто не ссылается, то мы можем одним махом убить все объекты в области B.

Например, если у нас есть какое-то чисто функциональное вычисление, которое порождает много промежуточных объектов, а потом возвращает небольшую часть этих объектов в качестве результата, мы можем создать для этого вычисления временную область X и проводить вычисления в ней (на неё никто не ссылается). А когда результат будет получен, мы скопируем его в другую область Y и уничтожим всю область X.

★★★★★
Ответ на: комментарий от kemm

Есть такой диалог:
-Объясните мне зачем нужен GC? Чем смарт поинтеры хуже?

-опять двадцать пять. тебе не нужен. иди дальше лабай на своем недоязычке.

Откуда здесь следует, что «недоязычек» это именно С++? Скорее отсюда следует, что к «недоязычкам» относятся языки без GC, так как ответ был сделан в единственном числе «тебе не нужен» и значит отностится к первому вопросу про GC. И значит огромная масса замечательных программ на C/C++ и прочих языках без GC написана на «недоязычках».

BOEHKOM
()
Ответ на: комментарий от BOEHKOM

Или это свидетельствует о неспособности программеров с GC ясно выражать свои мысли. Может быть это следствие использования GC.

BOEHKOM
()
Ответ на: комментарий от BOEHKOM

> Откуда здесь следует, что «недоязычек» это именно С++?

Назови ещё один распространённый язык без GC и со смартпойнтерами.

kemm
()
Ответ на: комментарий от BOEHKOM

> И значит огромная масса замечательных программ на C/C++ и прочих языках без GC написана на «недоязычках»

Того, кто пишет «C/C++», на костер.

anonymous
()
Ответ на: комментарий от kemm

>Назови ещё один распространённый язык без GC и со смартпойнтерами.
Смартпоинтеры необязательно должны явно присутствовать.

Booster ★★
()
Ответ на: комментарий от Booster

> Смартпоинтеры необязательно должны явно присутствовать.

Да-да, а ещё GC не обязательно должен отсутствовать. И вообще вы там об альтернативной реальности рассуждаете...

kemm
()
Ответ на: комментарий от kemm

Пишет человек :«Объясните мне зачем нужен GC? Чем смарт поинтеры хуже?»
Он пишет программы, например, на Делфи или С и задумывается об автоматизации работы с памятью и переходе на другой язык. Думает, что возможно лучшей альтернативой GC будет «смарт поинтеры». Где тут нашли С++?

BOEHKOM
()
Ответ на: комментарий от BOEHKOM

В смартпойнтерах. Множество распространённых языков без GC и со смартпойнтерами состояит из одного элемента. Утверждение о том, что автор вопроса пишет именно на нём, возможно, было сделано неправомерно, но правомерность этого высказывания никак не влияет на весь остальной бред по треду, последовавший за ним.

kemm
()
Ответ на: комментарий от kemm

>Множество распространённых языков без GC и со смартпойнтерами состояит из одного элемента.
А как же Perl?

Booster ★★
()
Ответ на: комментарий от Booster

Упоминание про С++ из слов про «смарт поинтеры» было оговоркой по Фрейду :))))) Тайные фанаты С++ себя выдали.

BOEHKOM
()
Ответ на: комментарий от Booster

> А как же Perl?

У него есть смартпойнтеры? У него GC на подсчёте ссылок. Это, всё-таки, разные случаи. Смартпойнтеры предполагают ручное оборачивание нужных вещей в них.

kemm
()
Ответ на: комментарий от Booster

> В соседнем треде писали о Vala и Gene. Значит всё же не один.

Я сказал — распрстранённые. Я даже не знаю, что там у Вали и у Жени — GC на тупом подсчёте ссылок или действительно смартпойнтеры, но в любом случае распространёнными их пока назвать нельзя.

kemm
()
Ответ на: комментарий от anonymous

>Того, кто пишет «C/C++», на костер.

Количества файлов

Firefox 3.5.6

*.c    1490
*.cpp  3850
*.h    4116

VirtualBox 3.1.2 OSE

*.c   1450
*.cpp 1464
*.h   4989
*.hpp 115

BOEHKOM
()
Ответ на: комментарий от BOEHKOM

>Количества файлов

И что? Да, эти программы написаны на двух разных языках с общим корнем.

legolegs ★★★★★
()
Ответ на: комментарий от kemm

>У него есть смартпойнтеры? У него GC на подсчёте ссылок. Это, всё-таки, разные случаи. Смартпойнтеры предполагают ручное оборачивание нужных вещей в них.
По-моему вы не правы. Смартпоинтеры это разновидность автоматического управления памятью. GC это это тоже одна из форм автоматического управления памятью, код который периодически освобождает память, удаляя объекты, которые уже не востребованы приложением. Так пишет вики и мне нет повода не доверять этому. А явно или нет реализованы смартпоинтеры это уже детали.

Booster ★★
()
Ответ на: комментарий от Booster

Нет, имхо. Смартпойнтеры можно (с натяжкой) обозвать вариантом GC, GC на подсчёте ссылок обозвать смартпойнтерами нельзя.

kemm
()
Ответ на: комментарий от kemm

Уборщик это именно что-то отдельное. Если все за собой убирают, то вряд ли всех можно назвать уборщиками. Так можно всех назвать и поварами и продавцами и чем угодно. Но всё же главное занятие у всех одно, два. Так и под GC подразумевают вполне конкретное понятие.

Booster ★★
()
Ответ на: комментарий от Booster

Да, и это понятие — сборка мусора. В перле есть сборщик мусора. В перле нет умных указателей. Точка.

kemm
()
Ответ на: комментарий от kemm

В перле есть автоматическое управление памятью на неявных смартпоинтерах. Сборщика мусора там нет. ^) Давайте придержживаться принятой терминологии.

Booster ★★
()
Ответ на: комментарий от Booster

>В перле есть автоматическое управление памятью на неявных смартпоинтерах. Сборщика мусора там нет. ^) Давайте придержживаться принятой терминологии.

Ну...

1) Ты сперва пойди в соседней теме разберись с вопросом. Так как из того обсуждения ясно, что ты не в теме.

2)Согласно общепринятой терминологии, в перле есть сборщик мусора. Плохой, но есть. Точка.

Waterlaz ★★★★★
()
Ответ на: комментарий от Love5an

> под GC обычно понимают отслеживающий сборщик.

Под сборщиком мусора обычно понимают сборщик мусора. В перле GC на подсчёте ссылок, менее сборщиком или менее мусора он этого не становится. Т.е. это, конечно, в некотором смысле хреновый GC, но это GC, а не НЁХ или смартпойнтер.

kemm
()
Ответ на: комментарий от Booster

> В перле есть автоматическое управление памятью на неявных смартпоинтерах. Сборщика мусора там нет.

Где там смартпойнтеры?! Где?! Чтобы могли быть _смарт_пойнтеры, должны быть обычные, под которые НЁХ под названием смартпойнтер и пытается мимикрировать. Где в перле указатели?

В перле — сборщик мусора. Синхронный, на основе подсчёта ссылок.

Давайте придержживаться принятой терминологии.

Давайте. В рамках общепризнанной терминологии в перле есть сборщик мусора и нет умных указателей.

kemm
()
Ответ на: комментарий от Waterlaz

> 1) Ты сперва пойди в соседней теме разберись с вопросом.

Заглянул в соседнюю тему... Мда. На этом я общение с данным специалистом, пожалуй, закончу. 8))) Лопнет же, бедолага. 8)))

kemm
()
Ответ на: комментарий от kemm

Употреблять понятие «сборщик мусора» по отношению к reference counting некорректно, т.к. это не какая-то отдельная специальная подсистема.
Можно говорить «сборка мусора с помощью подсчета ссылок».
Но, еще раз, когда говорят GC в 90% случаев имеют ввиду именно tracing gc, т.е. то, что свою родословную ведет от gc лисп-системы Маккарти
вон в русской википедии вся статья про gc, например, только про него.

Love5an
()
Ответ на: комментарий от Waterlaz

>Ты сперва пойди в соседней теме разберись с вопросом. Так как из того обсуждения ясно, что ты не в теме.

Я так чувствую у нас сейчас будут циклические связи и мы войдём в бесконечный цикл.

2)Согласно общепринятой терминологии, в перле есть сборщик мусора. Плохой, но есть. Точка.


Пруф в студию пожалста.
Вот мой - http://en.wikipedia.org/wiki/Garbage_collection_(computer_science)


Booster ★★
()
Ответ на: комментарий от Love5an

> Употреблять понятие «сборщик мусора» по отношению к reference counting некорректно, т.к. это не какая-то отдельная специальная подсистема.

На основании чего будем делить на какие-то отдельные подсистемы? Лексический, синтаксический разбор и компиляция в байт-код — это сколько отдельных подсистем, одна, две или три? 8))

Да, GC такого типа тупой и до безобразия маленький, но это всё-таки GC в бОльшей степени, чем умный указатель (в отсутствии в языке понятия «указатель» как такового).

Но, еще раз, когда говорят GC в 90% случаев имеют ввиду именно tracing gc

Отлично, сейчас случай как раз из оставшихся 10%. 8)) Консенсус? 8))

kemm
()
Ответ на: комментарий от Waterlaz

>Ты хоть читай свои пруф линки, а?
Хочешь сказать счётчики ссылок не могу использоваться в GC? Нонсенс.
И не нужно предёргивать, Love5an уже написал, что сборка мусора(освобождение памяти) может быть на счётчиках. Но под GC понимают именно отдельную подсистему, занимающейся уборкой.

Booster ★★
()
Ответ на: комментарий от kemm

> Но, еще раз, когда говорят GC в 90% случаев имеют ввиду именно tracing gc

Отлично, сейчас случай как раз из оставшихся 10%. 8)) Консенсус? 8))


Потому-что некоторые понимают не то, что понимает большенство. ^)

Booster ★★
()
Ответ на: комментарий от den73

> Так, ну, похоже, по теме тут не с кем разговаривать. Жаль.

Что ты хотел? Мусор возбуждает местную илиту и ынтерпрайз не хуже, чем GNOME - хомячка.

mannaz
()
Ответ на: комментарий от den73

По какой теме?

Почему бы тогда не обобщить понятие «поколения» на понятие «область хранения» и не позволить пользователю явно управлять областями?


Это же бред.

если у нас есть какое-то чисто функциональное вычисление, которое порождает много промежуточных объектов, а потом возвращает небольшую часть этих объектов в качестве результата, мы можем создать для этого вычисления временную область X и проводить вычисления в ней (на неё никто не ссылается). А когда результат будет получен, мы скопируем его в другую область Y и уничтожим всю область X.


И чего ради весь этот гимморой? Никогда не известно, сколько именно памяти потребуется для конкретного вычисления. Нет никакой гарантии, что мы вернем некое вычисленное значение, не ссылку на объект в этом самом регионе.

Твоё предложение - это закат вручную велосипеда с квадратными колесами.

Нужно тебе явное выделение памяти, которую потом можно одним махом сбросить - есть тебе malloc().

LamerOk ★★★★★
()
Ответ на: комментарий от LamerOk

>Это же бред.
Да, неясно, что хуже - отсутствие собеседников вообще, или такие, непонимающие собеседники с заранее готовым негативным мнением. Что же, долго разжёвывать не буду, но минимальные усилия предприму.

Нет никакой гарантии, что мы вернем некое вычисленное значение, не ссылку на объект в этом самом регионе

Читай внимательнее, что я предложил. На последнем этапе можно скопировать результат в другую область. Даже если это дерево. А если это число - то тем более.

Никогда не известно, сколько именно памяти потребуется для конкретного вычисления

Иногда известно. Например, в случае сортировки. И даже если общее количество неизвестно, то может оказаться известным, что нет смысла собирать мусор до завершения вычисления. Например, типичный компилятор выделяет не слишком много памяти на каждый файл. Можно создавать новую область под временные данные компилятора для каждого вновь компилируемого файла.
Далее, рассмотрим процесс обработки запросов к вебу в языках типа PHP. Как правило, программа не велика и она выгружается полностью после исполнения одного запроса (бывает, конечно, что экземпляры PHP кешируются, но не всегда). Значит, это как раз аналог того, что я называю «областью», при этом, возвращаемое значение - это код ошибки ОС. Берём PHP. Переводим на лисп, образ которого постоянно крутится. Под каждый новый запрос создаём область, делаем в ней всё, что делает соответствующая программа на PHP, потом удаляем эту область.

den73 ★★★★★
() автор топика
Ответ на: комментарий от Booster

Booster, если ты имеешь в виду

2. Определять, как размещаются вновь создаваемые объекты по областям


то, насколько я понимаю, при поколенческой сборке мусора это не так. Все новые объекты кладутся в первую область. Может быть, я что-то не знаю?

den73 ★★★★★
() автор топика
Ответ на: комментарий от den73

> Подсчёт ссылок - это НЕ сборщик мусора. Точка.

Сам придумал? Молодец, возьми с полки пирожок. Подсчёт ссылок — это не сборщик мусора. Съешь пирожок только после того, как осознаешь, что сборщик мусора на подсчёте ссылок — это сборщик мусора. Свободен.

kemm
()
Ответ на: комментарий от kemm

То, что автор Перла приврал и назвал вещи не своими именами, не делает счётчик ссылок сборкой мусора. Вот, первая ссылка из Яндекса на эту тему

http://www.michurin.com.ru/python-vs-perl.shtml

То, что в Perl называется «механизмом сборки мусора», в Python называется гораздо скромнее — «механизм подсчёта ссылок». Эти механизмы работают одинаково и не способны, на пример, удалять циклические ссылки. Вот пример программы на Perl, вызывающей утечку памяти, так как здесь подсчёт ссылок бессилен:

while(1) { my $x; $x=\$x; }

Создать подобную утечку памяти в Python практически невозможно, так как Python имеет второй механизм сборки мусора (он-то и называется в Python «механизмом сборки мусора»). Он способен удалить циклические ссылки или вернуть программисту указатели на эти потерянные структуры с целью их корректного удаления. Этот механизм можно включать, выключить и запускать принудительно, когда это необходимо.

Если бы ты не начал хамить, я бы промолчал. Но теперь придётся предоставить тебе неширокий выбор. Выбирай, кто ты - троль или ламер.

den73 ★★★★★
() автор топика
Ответ на: комментарий от den73

>то, насколько я понимаю, при поколенческой сборке мусора это не так. >Все новые объекты кладутся в первую область. Может быть, я что-то не знаю?
Я имел ввиду уничтожение временных переменных. Хотя может я вырвал это из контекста и не правильно понял? Честно говоря не совсем понял про что тут и для чего. Для чего отслеживать ссылки старого объекта на молодой?

Booster ★★
()
Ответ на: комментарий от den73

> То, что автор Перла приврал и назвал вещи не своими именами, не делает счётчик ссылок сборкой мусора.

А заодно и все остальные, кто рассматривает подсчёт ссылок как один из механизмов сборки мусора. Очень удобная позиция — все, кто не подтверждает мою точку зрения, называются лжецами.

Вот, первая ссылка из Яндекса на эту тему

Ты б ещё у тумбочки спросил. почти (с)

То, что в Perl называется «механизмом сборки мусора», в Python называется гораздо скромнее — «механизм подсчёта ссылок».

Клёва. Оттого, что в питоне что-то по-другому обозвали, оно сразу становится тем и только тем, чем его в питоне обозвали. Феерично, ничего не скажешь.

Python имеет _второй_ механизм сборки мусора: ...

Ой, какая досада. Т.е. подсчёт ссылок — это тоже механизм сборки мусора? А распинались-то...

Выбирай, кто ты - троль или ламер.

Ты — точно тролль. Может, ещё и ламер, но тут сказать ничего не могу.

kemm
()
Ответ на: комментарий от den73

как можно подсчет ссылок выкинуть и не называть сборкой мусора? Только потому, что это слишком просто?

Waterlaz ★★★★★
()
Ответ на: комментарий от Booster

> Для чего отслеживать ссылки старого объекта на молодой?
Смысл поколенческой сборки мусора (хотя это и википедии можно прочитать): все объекты делятся на поколения.
Допустим, на 4 (так во многих лиспах). 1-е поколение - самое молодое, 2-е - постарше и т.п. Есть несколько разновидностей сборок мусора.
Чаще всего делается сборка только в 1-м поколении.
Чуть реже - в 1-м и втором
Ещё реже - в 1-м, 2-м и третьем
Совсем редко - во всей куче.

Долгоживущие объекты со временем переносятся из 1-го поколения во второе, потом в третье и т.п. Это происходит при соответствующем виде сборки мусора.

Смысл тут в том, что если объектов много, но меняются они редко, то эти объекты попадают в 4-е поколение и сборка мусора по ним проходит редко. Значит, в целом, время на сборку мусора сокращается.

Если объекты не меняются, то объекты i-го поколения ссылаются только на объекты из поколений [i..4] Но. Если объект из 3-его поколения поменялся, он теперь может ссылаться на объект из 1-го. И может так оказаться, что больше на этот объект никто не ссылается. Если эту ссылку не учесть, то сборка мусора 1-го поколения может уничтожить живой объект 1-го поколения. Значит, нужно отследить конкретно эту ссылку в какой-то таблице. Это усложняет логику создания ссылок и увеличивает требования к памяти.
И, при неблагоприятном раскладе (например, большая хеш-таблица с данными, которая живёт всю жизнь и регулярно меняется), смысл поколенческой сборки начинает размываться.

Именно против этого размывания и направлены мои предложения: можно построить свою конфигурацию «поколений» и назвать их просто «областями». Например, заливать объект сразу в 3-е поколение, иметь кучи, не ссылающиеся друг на друга и т.п. Накладные расходы, по сравнению с обычной поколенческой сборкой мусора при этом точно такие же (ну, почти такие же). А возможностей настройки быстродействия - гораздо больше.

den73 ★★★★★
() автор топика
Ответ на: комментарий от Love5an

> Сборщик это отдельная подсистема рантайма. Подсчет ссылок - нет.

Ы-ы-ы-ы-ы-ы-ы-ы!!! Счётчик ссылок это отдельная подсистема рантайма, сборка мусора — нет. Ну логично, что подсистема и процесс — это немного разные вещи, не находишь?

Границы деления на подсистемы в семействе продуктов весьма условны. Я уже спрашивал — лексический, синтаксический анализатор и компилятор в байт-код — это сколько подсистем, одна, две или три?

Если в тупой подсчёт ссылок добавить отслеживание кольцевых зависимостей, которое будет выполняться периодически, а не на каждое уменьшение счётчика — это резко станет сборщиком мусора?

kemm
()
Ответ на: комментарий от Waterlaz

Ладно, с терминологической (если смотреть на англоязычную терминологию) я не прав. kemm, мои извинения :) Тем не менее, reference counting слабее, чем tracing garbage collection, вряд ли кто-то будет с этим спорить. Потому что не убирает циклические ссылки, и для их удаления нужны либо усилия на уровне кода, либо, опять же, приделать tracing garbage collection (случай Питона). Значит, tracing garbage collection и reference-counting - это принципиально разные вещи. У кого какие квалифицированные предложения по терминологии? Как называть эти вещи по Русски, чтобы можно было понять, что мы говорим о разном. Я всегда считал, что сборка мусора - это tracing garbage collection, а подсчёт ссылок - это reference counting.

Ну а если вернуться к существу вопроса и посмотреть на шутаут, можно заметить, что языки с tracing garbage collection - быстрые (лисп, ява, окамль), а языки с reference-counting - примерно в 30 раз медленнее (Perl,Python,PHP). Отсюда напрашиваются выводы...

den73 ★★★★★
() автор топика
Ответ на: комментарий от Waterlaz

Вот же вы любители переливать из пустого в порожнее.

«управляемый» подсчет ссылок - не ГК. «Неуправляемый» - кривой и не полноценный ГК.

LamerOk ★★★★★
()
Ответ на: комментарий от den73

>Ну а если вернуться к существу вопроса и посмотреть на шутаут, можно заметить, что языки с tracing garbage collection - быстрые (лисп, ява, окамль), а языки с reference-counting - примерно в 30 раз медленнее (Perl,Python,PHP). Отсюда напрашиваются выводы...

Я думаю, что тут скорее играет роль тот факт, что окамль компилируемый, лисп в общем тоже, а яве хорошая ВМ да и JIT.

Waterlaz ★★★★★
()
Ответ на: комментарий от den73

> kemm, мои извинения :)

Принято. 8))

Тем не менее, reference counting слабее, чем tracing garbage collection, вряд ли кто-то будет с этим спорить.

Тяжело спорить с очевидным, да. 8))

У кого какие квалифицированные предложения по терминологии?

Если принципиально — один раз обозвать полным названием, потом употреблять «сборка мусора». Кому надо — поймут гарантированно правильно (ну, либо будет достаточно одного указания на начало текста).

Отсюда напрашиваются выводы...

Эмн... Думаешь, связано именно со способом сборки мусора? Не уверен я что-то...

kemm
()
Ответ на: комментарий от den73

> неясно, что хуже - отсутствие собеседников вообще, или такие, непонимающие собеседники

Так ты пиши по-русски, а не выливай поток сознания. Как можно понять вот это:

типичный компилятор выделяет не слишком много памяти на каждый файл.


На какой еще файл? Что ты хотел сказать? Один телепат недавно был в /д/, но я думаю, опять ушел в отпуск.

с заранее готовым негативным мнением.


Это какбе _норма_. Если хочешь, чтобы твою идею одобрили - докажи/покажи её состоятельность. Или ты сюда не критику пришел послушать, а липовые восторги на тему «гениальности идеи»?

рассмотрим процесс обработки запросов к вебу в языках типа PHP ... при этом, возвращаемое значение - это код ошибки ОС


Щито?

Берём PHP. Переводим на лисп


......

LamerOk ★★★★★
()
Ответ на: комментарий от kemm

> ...все остальные, кто рассматривает подсчёт ссылок как один из механизмов сборки мусора

Тут даже такой терпеливый читатель, как я, не выдержал. Ты хочешь сказать, что если в C++ полностью полагаться на некий фреймворк, все объекты которого инкапсулируют подсчет ссылок, основанный на смартпоинтерах, таким образом, что никогда не приходится удалять объекты самостоятельно, то можно будет считать, что в программе используется «механизм сборки мусора»?

mannaz
()
Ответ на: комментарий от mannaz

> в программе используется «механизм сборки мусора»?

Да, в программе используется один из механизмов сборки мусора. Что тебя смущает?

kemm
()
Ответ на: комментарий от den73

>То, что в Perl называется «механизмом сборки мусора», в Python называется гораздо скромнее — «механизм подсчёта ссылок»

Вот объясни мне, каким образом «правильный GC» позволяет избегать ошибок, если на перле написано астрономическое число программ и при этом в нём убогий протекающий счётчик ссылок вместо православного GC и об этом ещё и не все перлеры знают, а глючат, тормозят и жрут память программы на питоне (все три с половиной)? Как так получается?

legolegs ★★★★★
()
Ответ на: комментарий от LamerOk

>> рассмотрим процесс обработки запросов к вебу в языках типа PHP ... при этом, возвращаемое значение - это код ошибки ОС

Щито?

А то. Что ещё может вернуть процесс? То, что он пишет в поток - это не объекты на куче.

На какой еще файл? Что ты хотел сказать?

Ессно, на каждый компилируемый файл. Их же может быть много за один запуск компилятора :)

den73 ★★★★★
() автор топика
Ответ на: комментарий от mannaz

> GC?

Шо «GC?»?

Что сказать-то хотел? Что подсчёт ссылок не является одним из возможных механизмов сборки мусора (уже разжевали вроде) или что ещё? Не понимаю.

kemm
()
Ответ на: комментарий от legolegs

>Вот объясни мне, каким образом «правильный GC» позволяет избегать ошибок, если на перле написано астрономическое число программ и при этом в нём убогий протекающий счётчик ссылок

В перле вообще освобождать память не обязательно если это простой сценарий из одного цикла или форкующийся сервер, что покрывает 90% применений перла. Похапе до 1.5 вон вообще память не чистил.

Absurd ★★★
()
Ответ на: комментарий от kemm

> Что сказать-то хотел?

Является ли подобная реализация «одного из механизмов сборки мусора» GC? С твоей точки зрения.

mannaz
()
Ответ на: комментарий от Absurd

> В перле вообще освобождать память не обязательно если это простой сценарий из одного цикла или форкующийся сервер, что покрывает 90% применений перла.

По твоей логике в жабовских сервлетах GC тоже может спать спокойно, что покрывает 64% оправданных применений жабы. Т.е. GC скорее не нужен, чем нужен?

mannaz
()
Ответ на: комментарий от mannaz

> Является ли подобная реализация «одного из механизмов сборки мусора» GC? С твоей точки зрения.

С моей точки зрения: если гарантируется соблюдение этих условий (никакой явной игры с памятью в обход фреймворка) — то является, пожалуй. Но единственной гарантией будет использование либо своего компилятора, либо специфического препроцессора, из чего следует, что язык уже не совсем «C++», а какой-то «C++++» в лучшем случае, а то и Ocaml ненароком получиться может. 8))

Без гарантий — ХЗ, но я бы не называл. Да, я не могу дать строгого и однозначного определения GC, если ты об этом.

kemm
()
Ответ на: комментарий от mannaz

>Является ли подобная реализация «одного из механизмов сборки мусора» GC?

Ну там сам активный тред при выходе из скопа ходит по графу объектов и расставляет чанкам бит «unused». С GC блуждание по деревьям объектов и расставление бита «unused» происходило бы асинхронно. Об этом речь?

Absurd ★★★
()
Ответ на: комментарий от mannaz

>> В перле вообще освобождать память не обязательно если это простой сценарий из одного цикла или форкующийся сервер, что покрывает 90% применений перла.

По твоей логике в жабовских сервлетах GC тоже может спать спокойно, что покрывает 64% оправданных применений жабы.

Весь жабовский сервер вместе с сервлетами всегда живет в рамках одного процесса.

Absurd ★★★
()
Ответ на: комментарий от Absurd

> С GC блуждание по деревьям объектов и расставление бита «unused» происходило бы асинхронно.

Требований к асинхронности GC нигде не предъявляется, вроде. В lua, емнип, GC синхронный. В перле не уверен.

kemm
()
Ответ на: комментарий от Absurd

> Весь жабовский сервер вместе с сервлетами всегда живет в рамках одного процесса.

Да, не подумал. Хотя есть еще вариант с выполнением JSP на лету.

mannaz
()
Ответ на: комментарий от mannaz

>> Весь жабовский сервер вместе с сервлетами всегда живет в рамках одного процесса.

Да, не подумал. Хотя есть еще вариант с выполнением JSP на лету.

Насколько я понимаю он их компилирует в .class и грузит класслодером в активную (свою собственную) JVM.

Absurd ★★★
()
Ответ на: комментарий от den73

>>> рассмотрим процесс обработки запросов к вебу в языках типа PHP ... при этом, возвращаемое значение - это код ошибки ОС

Щито?

А то. Что ещё может вернуть процесс? То, что он пишет в поток - это не объекты на куче.


Пилять, как тебе удается путать возвращаемое глибцы errno («код ошибки ОС») с возвращаемым значением процесса ?!? Или ты почётно именуешь возвращаемое значение процесса «кодом ошибки»? Тогда почему «кодом ОС» и как быть, если был возвращен код успеха? ;)))

типичный компилятор выделяет не слишком много памяти на каждый файл.

На какой еще файл? Что ты хотел сказать?

Ессно, на каждый компилируемый файл.


Ну так ты пиши по-русски - на единицу трансляции. Для нормальных людей совсем не очевидно, что «компилятор выделяет память для файлов». Обычно принято считать, что компилятор выделяет её в совсем других целях.

Тебе прежде чем создавать исскуственные языки хотя бы с одним естественным не мешало бы разобраться. ;))) И я не про синтаксис с пунктуацией, нет. %))

LamerOk ★★★★★
()
Ответ на: комментарий от LamerOk

Так, ладно, никто не хрена не понимает, и все норовят обхамить. Надоели. До свидания.

den73 ★★★★★
() автор топика
Ответ на: комментарий от legolegs

>Никогда не известно, сколько именно памяти потребуется для конкретного вычисления

$^&$улся?


Ну зачем так резко. В общем случае неизвесно. Вычисление может иметь древовидную структуру (которая выясняется лишь в процессе вычисления, не как FFT) и пока вычисление не дойдёт до терминальных вершин, оно само не знает, сколько же ему надо было памяти и времени на всё на это. Заранее определить не может, ибо это есть часть самого вычисления: последующие ходы вычисления зависят от результатов, полученных на предыдущих.

BOEHKOM
()
Ответ на: комментарий от den73

Я спросил, как сборка мусора в первом поколении может уничтожить объект, если в другом поколении кто-то на него ссылается? Можно мне на это ответить?

Booster ★★
()
Ответ на: комментарий от den73

Ну нахамить тебе пока не особо хотят (вроде), ибо ты источник ценных лулзов. %))

Но мысли надо учиться выражать. Хотя бы письменно, если не устно.

LamerOk ★★★★★
()
Ответ на: комментарий от LamerOk

Да и вообще хорошие треды создаешь. Нынче этого не хватает.

LamerOk ★★★★★
()
Ответ на: комментарий от den73

>Так, ладно, никто не хрена не понимает, и все норовят обхамить

Добро пожаловать в интернет :D

legolegs ★★★★★
()
Ответ на: комментарий от BOEHKOM

>Ну зачем так резко.

Потому-что из-за идиотов, которые пишут «Никогда не известно» вместо «изредка не известно» мы и наблюдаем повсюду тормозной быдлокод. Наболело.

Вычисление может иметь древовидную структуру

На практике в таком случае часто есть верхняя оценка. Ну и средняя всегда есть. А ещё есть куча других случаев, в которых оценка даётся буквально тремя движениями извилин и ещё пятком её можно понизить.

legolegs ★★★★★
()
Ответ на: комментарий от Booster

И снова здравствуйте.

Я спросил, как сборка мусора в первом поколении может уничтожить объект, если в другом поколении кто-то на него ссылается? Можно мне на это ответить?

Сборка мусора в первом поколении и корни ищет только в первом поколении. Только поэтому она и может быть быстрой. Во всяком случае, мне это казалось настолько очевидным, что я всегда так думал. Может быть, я не прав, но вряд ли я сейчас полезу в исходники SBCL, чтобы это проверить. Хотя... Ладно, 5 минут можно уделить.

den73 ★★★★★
() автор топика
Ответ на: комментарий от LamerOk

>> На практике в таком случае часто есть

У тебя очень маленькая практика. :3

Ну конечно, Вашество (:

А если серьёзно, по какой причине тебе в твоей практике (она ведь есть, да?) не удавалось определить максимальное время выполнение функции, либо, на худой конец, её O(f(n))? Ведь этой причиной не могла быть лень, верно? :D

legolegs ★★★★★
()
Ответ на: комментарий от den73

>Сборка мусора в первом поколении и корни ищет только в первом поколении. Только поэтому она и может быть быстрой. Во всяком случае, мне это казалось настолько очевидным, что я всегда так думал.
Да, но я не понял что конкретно предлагается. Как понимаю предлагается некая область, которая эквивалентна поколению. Но что это даёт?

Booster ★★
()
Ответ на: комментарий от legolegs

> не удавалось определить максимальное время выполнение функции, либо, на худой конец, её O(f(n))?

При чём тут время? Мы об объёме памяти говорим. )))

Объём потребляемой программой памяти в общем случае зависит от объема входных данных, в частном - еще и от значений входных данных.

Заведомо известный объем входных данных может быть почти исключительно на лабах в школе/вузе. ;)

LamerOk ★★★★★
()
Ответ на: комментарий от legolegs

Пример, когда невозможно определить максимальное время. Это когда выполняется функция «сидеть в интернете». Может продлиться 5 минут, а может выполняться 48 часов для особо запущенных случаев.

BOEHKOM
()
Ответ на: комментарий от den73

Короче, в сорсах не смог разобраться, но они там дают ссылку на статью
uniprocessor garbage collection techniques, где всё так и написано. В общем, вроде я правильно написал.

den73 ★★★★★
() автор топика
Ответ на: комментарий от kemm

> Без гарантий — ХЗ, но я бы не называл. Да, я не могу дать строгого и однозначного определения GC, если ты об этом.

Просто стало интересно, начиная с какого «момента», на твой взгляд, некоторая схема управления памятью становится Garbage Collector'ом. Вопрос снят.

mannaz
()
Ответ на: комментарий от Booster

> Как понимаю предлагается некая область, которая эквивалентна поколению. Но что это даёт?
Не совсем эквивалентна поколению. Эквивалентна только в том смысле, что используются те же механизмы отслеживания взаимных ссылок между областями, как и между поколениями. Примеры, когда это может пригодиться, я приводил. Например, мы считаем факториал на бигнумах. Бигнумы обычно живут в куче. Заведомо известно, что никакие промежуточные резлультаты, кроме собственно результата вычисления, не понадобятся потом. Значит, все промежуточные вычисления можно делать во временной куче, потом скопировать результат в нормальную кучу и удалить временную кучу целиком. Получится, что мы породили в основной куче совсем мало мусора, и тем самым, мы отсрочили момент сборки мусора в основной куче.

den73 ★★★★★
() автор топика
Ответ на: комментарий от den73

А если из области много других и рекурсивных вызовов? Пока мы доберёмся до первой очиски, мы породим кучу куч, между которыми нужно будет делать копирования и всё равно следить за памятью?

Booster ★★
()
Ответ на: комментарий от Booster

> А если из области много других и рекурсивных вызовов?
Тогда нам не повезло.

Пока мы доберёмся до первой очиски, мы породим кучу куч, между которыми нужно будет делать копирования и всё равно следить за памятью?


Сами области тоже живут в куче и подвержены сборке мусора. Видимо, будет жить глобальная таблица областей, подобная пакету (таблице известных символов) в лиспе. Удаление области - это всего лишь намерение её удалить, а не вызов free(). Удаляя область из этой таблицы, мы всего лишь лишаем её надежного указателя, который удерживает её в памяти. А само удаление происходит в ходе обычной сборки мусора. Область удаляется (с помощью free()), когда на неё и на её данные никто не ссылается. Если мы не скопировали, а вернули данные из старой области непосредственно, то временная область не будет удалена, потому что будут замечены и записаны указатели на её данные из других областей, точно так же, как лисп замечает ссылки из старых поколений на новые.

den73 ★★★★★
() автор топика
Ответ на: комментарий от den73

В принципе интересно. По идее можно полностью заменить GC этой штукой.

Booster ★★
()
Ответ на: комментарий от den73

Но серъёзный минус это копирование возвращаемого значения, если у нас большая глубина вызовов/рекурсии, то возращать здоровенный объект копированием это ахтунг.

Booster ★★
()
Ответ на: комментарий от Booster

Ну я же не говорю, что эта вещь универсальна. Я думал не столько о функциональщине, а вот о чём. У нас есть два вычисления, которые по большей части независимы и которые порождают мусор с очень разной скоростью.

Если поместить их в одну кучу, то они будут друг другу мешать из-за того, что сборщик будет «старить» объекты более медленного вычисления, даже если они по своей сути временные. Если же поместить эти вычисления в две разные области, то они будут мешать друг другу гораздо меньше.

Или, допустим, у нас есть какая-то нить, которая должна выполняться в реальном времени. Мы можем запустить в ней сборку мусора. А в другой в это время в другой нити работает, скажем, текстовый редактор. Тогда, при условии, что редактор и вычисление реального времени не ссылаются друг на друга данными, можно запустить сборку мусора в текстовом редакторе. А гарантировать отсутствие ссылок ведь можно и средствами компилятора, наложив на язык ограничения.

Короче, о. Сборка мусора и параллельность. Вот из этой области. Хотя, при такой постановке задачи моё решение становится первым, что приходит на ум...

den73 ★★★★★
() автор топика
Ответ на: комментарий от den73

Блин, опять очепятка. Не «мы можем запустить сборку мусора», а «мы можем запретить сборку мусора» в нити реального времени.

Впрочем, конечно же, всё это можно приблизить несколькими отдельными программами, в каждой из которых своя сборка мусора. А данные копировать по IPC. Но это не будет не так быстро...

den73 ★★★★★
() автор топика
Ответ на: комментарий от den73

Ещё немного поразмыслил как можно организовать сборку мусора на основе данной идеи. А что если отказаться от gc, сделав всё на основе смартпоинтеров и областей видимости? В каждой области видимости хранить массив указателей на объекты, которые принадлежат данной области. В самих объектах будет счётчик ссылок областей. Когда объект создался, то он принадлежит данной области, значит заносим указатель на данный объект в массив указателей области и ставим ссылку в объекте в 1. Если кто-то из другой области ссылается на этот объект, то также заносим указатель на него в массив той другой области и увеличиваем ссылку в объекте. В итоге никаких проблем с циклическими ссылками. Так же есть экономия, если на объект из одной области ссылается много ссылок, то указатель в массиве всё равно один, так как объект принадлежит сразу всей области, а не каждой ссылке на него.

Booster ★★
()
Ответ на: комментарий от Booster

Так, я не понял, нужно два массива? Один «кто ссылается на нас» и второй - «на кого ссылаемся мы»?

den73 ★★★★★
() автор топика
Ответ на: комментарий от den73

Массив в каждой области видимости, в них указатели на объекты, в самих объектах счётчики ссылок. Понятие смартпоинтер расширяется до области видимости. Когда выходим из области видимости, то пробегаемся по массиву и уменьшаем счётчики. GC становится не нужен и нет проблем с циклическими ссылками, так как никто друг на друга не ссылается. Единственно что можно оставить это дефрагментатор памяти. Когда фрагментация памяти становится достаточной большой можно её уплотнить.

Booster ★★
()
Ответ на: комментарий от Booster

Ну, во-первых, почему не могут быть циклические ссылки внутри области? Во-вторых, какой именно смартпоинтер имеется в виду? Отношения владения? А то википедия говорит, что это понятие неоднозначное. В-третьих, я всё-таки не понял, вот у нас две области видимости, A и Б. В области А тогда массив чего? Массив указателей из области Б на объекты внутри области А? Или просто массив, содержащий указатель на каждый объект из области А? А, наверное последний вариант.

Ну всё равно непонятно. Вот у нас объект б в области Б ссылается на объект а в области А. Добавляем ещё одну ссылку из области Б на объект а. Как мы узнаем, что не нужно увеличивать счётчик ссылок на объекте а?

den73 ★★★★★
() автор топика
Ответ на: комментарий от den73

Согласен, этот способ не спасает от циклических ссылок. Ведь если один объект ссылается на другой, а в свою очередь второй ссылается на первый, то в областях первого и второго будут циклические ссылки. Что этот метод даёт, так это только некоторую экономию памяти в сравнении с обычными смартпоинтерами. Но с другой стороны можно отличить когда на объект ссылаются из чистой области видимости и из другого объекта. И когда ссылаются только из других объектов, то заносить указазатель на него в отдельный массив для дальнейшего анализа. Но тут уже без GC не обойтись.
В общем получается некий симбиоз GC и смартпоинтеров. Смарты по возможности очищают, а если не могут, то очищает GC.

Booster ★★
()
Ответ на: комментарий от Booster

Да ну, по-моему, чистый GC ничем не хуже. Главное, что если у нас области независимы, то мы можем делать GC в одной области и в то же время другая область будет работать в риалтайме. Этакий получится змей-горыныч,у которого головы спят поочерёдно.

den73 ★★★★★
() автор топика
Ответ на: комментарий от den73

А как в твоей идее быть с циклическими ссылками? К примеру у нас есть локальное дерево и где-то сбоку ссылка из внешнего объекта. То есть локальное дерево переплелось с основным. Как тут быть? Запускать обход дерева?

Booster ★★
()
Ответ на: комментарий от Booster

Если сюда ещё кто-нибудь заходит...
Ну этот вопрос стандартно решается в сборке мусора - в какой-то момент должна быть сделана совместная сборка мусора в обоих областях. В остальное время ссылка сбоку является корнем для сборщика мусора.

den73 ★★★★★
() автор топика
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.