короче, рантайм НЕ знает тип

короче, рантайм НЕ знает тип

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

может и так, я внутренности рантайма почти не знаю.

Встроеный в D сборщик мусора не боится циклических ссылок.

Зато его все боятся) Запомним.

Интересный вопрос, а деструкторы вызываются при удалении объекта из памяти или нет?

Зато его все боятся) Запомним.

Сборщика мусора или циклических ссылок?

Сборщика мусора или циклических ссылок?

Сборщика конечно. Потому что он циклических ссылок не боится, он вообще ничего не боится, только вот работает не идеально :)

Скорее, вроде работает, но никто не может объянить, за счет чего

Интересный вопрос, а деструкторы вызываются при удалении объекта из памяти или нет?

Да, при чистке мусора

Зато его все боятся) Запомним.

Ну он на самом деле чистит... обычно... когда звезды правильно расположены... Пруф https://glot.io/snippets/ez2ji2cmzh

Техномагия

Техномагия

хде?

Я про твой код

ты про очистку стека?

Ага

Вообще, навеяло эту статью http://lurkmore.to/%D0%A4%D0%B0%D0%B7%D0%B0_%D0%9B%D1%83%D0%BD%D1%8B

короче, рантайм НЕ знает тип

не знаю какой рантайм имеется ввиду, но если посмотреть код core/memory.d он содержит куски типа * ti = TypeInfo to describe the full memory block. The GC might use * this information to improve scanning for pointers or to * call finalizers.

и ссылки на TypeInfo в https://github.com/dlang/druntime/blob/master/src/gc/impl/conservative/gc.d

TypeInfo это точно тип? может там несколько видов смещений для деструкторов лежит и всё?

TypeInfo это точно тип? может там несколько видов смещений для деструкторов лежит и всё?

Не только, там еще название, и инициализаторы есть.

не знаю какой рантайм имеется ввиду, но если посмотреть код core/memory.d он содержит куски типа * ti = TypeInfo to describe the full memory block. The GC might use * this information to improve scanning for pointers or to * call finalizers.

это для add/removeRange

https://github.com/dlang/druntime/blob/633976f1b2619974e8b3b415e0052b38d1a8e2fb/src/rt/util/typeinfo.d

а вот в BlkAttr и BlkInfo я не нашел никакой инфы о типах

Это где ты увидел?

копался в исходниках

думаю оно там для другого и не вкомпиливается в релизный код если не юзать это в коде своём

думаю оно там для другого и не вкомпиливается в релизный код если не юзать это в коде своём

похоже на то, в свойствах блока только инфа о финализаторах

https://github.com/dlang/druntime/blob/2f4ed262b2bc28190685f3347cc2e083bf05d4f7/src/core/memory.d#L133 Даже меньше

https://github.com/dlang/druntime/blob/master/src/core/memory.d#L225

NO_MOVE интересный атрибут

Получается, GC действительно двигает блоки, что бы они были теснее?

на практике нет, но может в теории

не должна ли функциональность GC быть реализована на уровне ОС?

В каком смысле?

В ядре или в стандартных библиотеках?

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

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

Деструктор что-то должно вызвать

да это понятно, тут же о другом. GC работает после деструктора

А что от ОС требуется тут?

побыстрее выдавать новые блоки

Ээээ

Я вообще не понимаю, что ты от ОС хочешь

зачем нужен GC?

По факту, в задаче "убрать память" в GC только два пункта: 1. Вызвать деструктор, если надо 2. Пометить блок как свободный в своих таблицах или вообще убрать его Что, в данном случае требуется переложить на ОС?

> По факту, в задаче "убрать память" в GC только два пункта Задача так не стоит вообще

задача стоит "управление памятью", чтобы она не фрагментировалась (большие объекты чтоб влазили) и чтобы можно было быстро находить свободные места

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

Речь шла об вот этом

не должна ли функциональность GC быть реализована на уровне ОС?

я тоже думал над этим, но ведь механизм действия гц, подсчета ссылок и зания о внутренностях очень сильно специфичны для каждого языка поэтому ос не сможет всем этим управлять.

Зато можно было бы от виртуальной памяти избавиться

Зато можно было бы от виртуальной памяти избавиться

За счет чего?

ОС могла бы выделять "реальную" память

бОльшими кусками. раз уж она её коллектит

Грубо говоря, в ОС есть механизмы управления памятью, которые работаю на манер GC. Но они на уровне процессов

ОС могла бы выделять "реальную" память

А в чем плюсы?

> Грубо говоря, в ОС есть механизмы управления памятью Не в ОС а в процессоре

А в чем плюсы?

минус одна конвертация адресов из виртуальных в реальные

да фигня, конечно. память нужна мелкими кусками а ОС сможет только крупные давать

> Грубо говоря, в ОС есть механизмы управления памятью Не в ОС а в процессоре

В процессоре есть возможность отображать память. Выделением памяти для процесса занимается ОС. Там очень много мозгоебли с сегментами, страницами и т.п., так что я могу ошибаться.

минус одна конвертация адресов из виртуальных в реальные

то что ты щас описываешь чем то похоже на то как это делает(раньше делал) прекрасный php))

Угу. Это специфично для распространённых процессоров, которые внезапно бывают разные.

там никакой мусор не собирался, скрипт отработал, умер - вся память от него почистилась разом.

Так что если хочешь опробовать действительно крутой, гибкий, эффективный, элегантный и популярный язык - добро пожаловать в PHP!

?

минус одна конвертация адресов из виртуальных в реальные

Тут есть очень хороший "подвох". Допустим, мы взяли адрес на объект, попали в своп и были выгружены на диск. А потом нам надо вернуть страницу обратно и внезапно нас загрузили в память вместо другой страницы.

Решение?

страницы ненужны будут

загрузили тебя в адрес х - там и сиди

ERROR: S client not available

А своп?

Даа

а что своп?

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

а как она сейчас делается? ровно так же

А она сейчас работает за счет того, что страницы выгружаются-загружаются

а будет работать за счёт того что загружаются-выгружаются другие блобы

Процессы целиком, что ли?

любую систкему деления на куски можно использовать же

Можно

Но

Как бы сказать

Мы не можем двигать процессы с реального адреса

Не, не так

Мы не можем двигать процессы с реального адреса

а зачем вам надо их двигать?

Допустим, у нас есть частоиспользуемый блоб А и нечастоиспользуемый блоб Б

а, понял - маппинг так и так остаётся

ну да, верно

так что тут два в одном

Что два в одном?

ну маппинг всё равно ведь не девается никуда - памяти реальной меньше чем потребляют все загруженные софтины

так что да

https://stackoverflow.com/questions/26325759/why-doesnt-the-os-have-a-garbage-collector

Microsoft Windows DCOM is OS provided distributed reference counting garbage collector.

Интересно, как он считает ссылки?

Или это требуется от ЯПа?

в явовский ассемблер недавно глядел - там есть прямо вызовы типа "создать класс"

и всё, машина их создаёт и ессно считает ссылки

Дык там байткод

а в шарпе не?

В шарпе IL

А что делать тем, кто не на нем?