А как у нас предполагается утечки управляемой памяти искать?

никак

во всяком случае я незнаю как еще

> но как только он встроенные хэши Щито?

некоторые выявил просто сделав соответствующие урезанные тесткейсы

> но как только он встроенные хэши Щито?

ага, у нас тоже челюсти отвисли

Вообще не понял о чём ты)

toHash?

Вообще не понял о чём ты)

не, я коряво выразился

он в программе заменил один из встроенных ассоциативных масивов на обертку вокруг std.container.rbtree

Аа

олдфажное название "хэш" для ассоциативных массивов

раньше тоже так говорил но никто меня не понимал)

олдфажное название "хэш" для ассоциативных массивов

правильнее хэш-таблица

и это существенно

когда только-только появился шаблон такой в С++ кажетя то все стали так их называть

ну и от этого путаница пошла

когда только-только появился шаблон такой в С++ кажетя то все стали так их называть

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

а плюсовой std::map - не хэш-таблица, а бинарное дерево

ну ок

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

читаешь такой текст а там из-за этих хэшей ничего не понятно.

(о вреде неправильных определений, короч)

есть такое

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

попробовал - вроде нормальный лог

если оставить наподольше то явно будет видно что же там навыделялось в таких объёмах

если оставить наподольше то явно будет видно что же там навыделялось в таких объёмах

К сожалению не возможно понять убранно ли выделенное в таких объемах или продолжает висеть в памяти.

а, действительно, в логе только количество выделений

почему-то

могли бы и количество уничтожений добавить

допустим я увидел в первой строке, что у меня миллион раз выделился объект A. Значит ли это что течет этот объект? А вот нихрена.

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

нелогично как-то

а, цель другая! профилировка - она про скорость

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

нужно иметь возможность снимать какой-то "мгновенный дамп"

нужно какой-то специальный аллокатор написать который всё сможет подсчитать и выдать

Есть аллокатор который ведет статистику по другим аллокаторам stat или что-то в этом роде.

а, цель другая! профилировка - она про скорость

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

да не, я про причину рассуждал просто. логично же добавить было бы 2 столбик

да не, я про причину рассуждал просто. логично же добавить было бы 2 столбик

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

https://forum.dlang.org/thread/pjbughflpznzdsamlqbx@forum.dlang.org поднял некропостом

https://habrahabr.ru/post/350844/

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

По сути то всё - давно известное конфигурирование сборки.

Может, более объектное и удобное.

А может и менее, смотря как сделать)

Да не, я не спорю, что на С макросоми это будет тот ещё хоррор. Но легко написать теплейт, которой будешь понимать только ты, в первую очередь из-за того, что best practices нигде не закреплены

Мне даже кажется, при таком подходе ответветственность за поведение класса выносится за пределы класса.

Не всегда это хорошо

Денис, а почему может быть так что GC что то не освобождает?

Не всегда это хорошо

Обычно это плохо.

Денис, а почему может быть так что GC что то не освобождает?

Может быть из-за взаимных ссылок?

Несовершенство механизмов сборки мусора, короче

Кстати, а в D есть аналоги WeakMap/WeakSet, которые позволяют GC собирать их содержимое?

Обычно это плохо.

Бывает полезно, но в целом, да, плохо

Денис, а почему может быть так что GC что то не освобождает?

2 варианта: баг в GC или баг в нашем коде. Оба варианта надо иметь возможность дебажить

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

Элементарно: при аллокации мы обычно знаем тип данных, под который выделяем память. А при освобождении уже чаще всего нет, GC видит лишь примерный размер куска памяти и все. (Не считая классов с финализаторами. Но для строк и многих других популярных типов финализатлров нет)

К сожалению не возможно понять убранно ли выделенное в таких объемах или продолжает висеть в памяти.

А не пробовали как-то постепенно отключать часть кода сервиса пока утечки не перестанут появляться?

Элементарно: при аллокации мы обычно знаем тип данных, под который выделяем память. А при освобождении уже чаще всего нет, GC видит лишь примерный размер куска памяти и все. (Не считая классов с финализаторами. Но для строк и многих других популярных типов финализатлров нет)

А нельзя сделать как в шарпе, при аллокации прикрепляем метку типа и все

Куда ты ее будешь тем же строкам прикреплять?

К началу выделенной памяти, не?

Может быть из-за взаимных ссылок?

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

Если написать свою альтернативную реализацию GC, где иначе устроить кучу, тогда да, там можно будет хранить доп. инфу о типах.

Если написать свою альтернативную реализацию GC, где иначе устроить кучу, тогда да, там можно будет хранить доп. инфу о типах.

А какая текущая реализация GC?

> при аллокации прикрепляем метку типа Подозреваю, это часть их "ассемблера"

А не пробовали как-то постепенно отключать часть кода сервиса пока утечки не перестанут появляться?

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

http://progcode.ru/2017/06/24/dconf-2017-под-капотом-мусорщика-ди-дмитрий-ол/

ERROR: S client not available

О

Ща глянем

Ну так там таблицы и метаданные уже и так есть, не вижу огромных проблем добавить хотя бы байт на метку типа

Байта маловато. Но да, я и говорю, если всю схему аллокации поменять, то можно.

А почему сразу же - всю схему?

Ну сравни как сейчас char[] хранится и как будет.

Элементарно: при аллокации мы обычно знаем тип данных, под который выделяем память. А при освобождении уже чаще всего нет, GC видит лишь примерный размер куска памяти и все. (Не считая классов с финализаторами. Но для строк и многих других популярных типов финализатлров нет)

Не уверен что не gc не знает тип данных которые он освобождает. У него есть информация о типе и что нужно для освобождения

Не уверен что не gc не знает тип данных которые он освобождает. У него есть информация о типе и что нужно для освобождения

Только размер

Ну сравни как сейчас char[] хранится и как будет.

Как будет? Так же, просто добавим еще пару байтов на метадату

Только размер

А как тогда вызывать деструктор?

А как тогда вызывать деструктор?

А вот об этом я не подумал

gc имеет указатель на typeinfo

А почему тогда нельзя запрофилировать деаллокацию?!

указатель на ClassInfo есть в каждом объекте, он для вызова финализатора и используется. Но не каждый кусок данных в куче - объект класса.

Т.е. массив структур от простой строки GC уже не отличит.

Как вариант можно было бы сделать через version() профилирующие вставки, пусть они отжирают ресурсов но можно было бы сделать хорошую профилирующую сборку и быстро найти в чем проблема

Т.е. массив структур от простой строки GC уже не отличит.

эм, вообще-то отличает. он же вызывает деструкторы, когда массив уничтожается

А как gc узнаёт что он смотрит на структуру в куче не на класс?

А GC это знать не нужно же

Не?

А как gc узнаёт что он смотрит на структуру в куче не на класс?

не знаю, но оно работает - https://glot.io/snippets/ez2iguvjlg

и было бы странно если бы не работало

Ну да, я и говорю что он видит информацию о типе

Не только классе

Но точного механизма я не знаю, поэтому могу врать

а, ты видимо не мне отвечал

полагаю в TypeInfo масссива есть инфа о типе который он содержит

где о типе? он просто запускает деструктор пофиг чего

деструктор массива?

элементов

на которые он ссылки хранит

и он знает тип элементов