Отличное видео для того что бы разобраться с GC в Go новичку (ИМХО лучшее!). Для подготовки к собеседованию самое оно. Какие-то прям тонкости и нюансы уже можно добрать с других ресурсов, например статей на хабре. Но по факту и этого одного видео достаточно, что бы отбить все вопросики. Большое спасибо Дмитрию и Evrone Dev.
чем-то мне эта лекция напоминает студенческие годы - когда ты со шпоры все списал - все правильно и хорошо, но как это все работает - ты вообще не понимаешь )
Очень много разбирался со сбором мусора и было много непонятных моментов, но почти на все мои вопросы в этом видео я получил ответ Дмитрий, больше спасибо!
Насколько это вообще нормальная идея построить хранилище для большого объема данных на хэш таблицах. Получается при каждом запуске GC будет обходить их все и конкурировать с основной программой, что для высоконагруженного сервиса будет катастрофой. Решаема ли такая задача в принципе. Может можно как-то спрятать эти таблицы от GC.
Вы прежде чем других учить прочли бы хоть какую-нибудь базовую книжецу по Go) В первом же примере косяк, т.к обе переменные stackVar и heapVar будут размещены в стеке. Дальше смотреть не стал
Почему на 22 слайде включение write barrier и start the world стоят вместе? Вроде бы выше было сказано, что write barrier включается именно при stop the wrold.
На слайде со стеком и кучей не совсем понятно, я где-то прочитал и был уверен, что голанг сам решает, где создать переменную, скрывая это от программиста. Насколько я могу быть неправ?
есть определенные правила, по которым компилятор решает, где выделять память, при инициализация переменная проходит некоторые "проверки" и если она не прошла хоть один из так званых тестов, то память аллоцируется на куче, иначе в стеке )
2:30 В С++ есть подход RAII, который позволяет обойтись без ручного высвобождения ресурсов. Если писать код с учётом нескольких простых правил, то в С++ стандартных проблем, - когда забыл вызвать `delete`, - с утечками памяти не возникнет.
Удивительно, что умные указатели (работающие по принципу RAII) появились ещё в 11 стандарте (если кто не в курсе 11 он назван в честь года выхода - 2011), а мифы об утечках из-за забытого delete всё ещё всплывают. За время работы на плюсах практически не встречал ручного высвобождения ресурсов, только в легаси.
@@olegusov1621 К сожалению, ручное освобождение ресурсов встречается не только в легаси. У многих в голову слишком въелся подход "не платить за то, что не требуется", который они воспринимают через чур строго, и такие люди не собираются разбираться в умных указателях просто потому, что у плюсов есть обычные указатели, которые самые лучшие и самые быстрые на свете (unique_ptr : "Да да, пошёл я нафиг")
По поводу LIFO оговорка. Правильно будет последним пришёл - первым ушёл. Last In, First Out
тоже завис на этом моменте
@@A1es1 я с вами, пх
Отличное видео для того что бы разобраться с GC в Go новичку (ИМХО лучшее!).
Для подготовки к собеседованию самое оно. Какие-то прям тонкости и нюансы уже можно добрать с других ресурсов, например статей на хабре. Но по факту и этого одного видео достаточно, что бы отбить все вопросики.
Большое спасибо Дмитрию и Evrone Dev.
чем-то мне эта лекция напоминает студенческие годы - когда ты со шпоры все списал - все правильно и хорошо, но как это все работает - ты вообще не понимаешь )
Стек не очищается - просто смещается указатель на вершину стека.
После стека и lifo не стал смотреть дальше
Большое спасибо! Очень доходчиво. За трюк с балластом отдельный плюс❤️
Очень много разбирался со сбором мусора и было много непонятных моментов, но почти на все мои вопросы в этом видео я получил ответ
Дмитрий, больше спасибо!
Чел как будто не готовился к докладу, постоянно ошибки в речи
Насколько это вообще нормальная идея построить хранилище для большого объема данных на хэш таблицах.
Получается при каждом запуске GC будет обходить их все и конкурировать с основной программой, что для высоконагруженного сервиса будет катастрофой.
Решаема ли такая задача в принципе. Может можно как-то спрятать эти таблицы от GC.
Куча ошибок ! Текст по листочку. Что за срань ? Если он так и программирует - плакать хочется.
Очень по верхам, хотелось бы подробнее. Потому что эту информацию можно и в обычной статье прочитать с точно такой же подачей
Не поверхностно посмотри исходный код в гитхабе
@@zoomer0just read the docs, bro 😂😂😂
Аллокатор памяти в Go основан на допиленном TCMalloc. Проблема фрагментации памяти больше не проблема.
А откуда сборщик мусора берёт список объектов? При вызове new какая-то информация сохраняется?
Вы прежде чем других учить прочли бы хоть какую-нибудь базовую книжецу по Go) В первом же примере косяк, т.к обе переменные stackVar и heapVar будут размещены в стеке. Дальше смотреть не стал
Почему на 22 слайде включение write barrier и start the world стоят вместе? Вроде бы выше было сказано, что write barrier включается именно при stop the wrold.
А в чем несоответствие? Нигде же не говорилось, что write barrier работает только при stop the world. STW нужен только для его включения.
Про балласт. А как обойти ругню компилятора на неиспользуемую переменную?
_ = make([]byte, 10
LIFO - ПОСЛЕДНИЙ пришел первый вышел
Last in first out
LIFO - это последний пришел первый вышел
вебка IA буд то бы сгенерирована
0:57 стэк первый пришел первый вышел? Нет же, последний первым выходит
Сколько сегментов в хипе?
На слайде со стеком и кучей не совсем понятно, я где-то прочитал и был уверен, что голанг сам решает, где создать переменную, скрывая это от программиста. Насколько я могу быть неправ?
Так и есть, в примере кода на видео stackVar будет убегать в кучу, стек горутин динамический (может менять размер)
есть определенные правила, по которым компилятор решает, где выделять память, при инициализация переменная проходит некоторые "проверки" и если она не прошла хоть один из так званых тестов, то память аллоцируется на куче, иначе в стеке )
10
Разве в го не динамический стек ?
Спасибо. Все подробно и по делу! Ждем новых докладов/видео от Дмитрия!
Великолепно! Спасибо!
отличный доклад! в первом публичном представлении казался чуть скучным, но пересмотрев, понравился больше.
помянул ситимобил :(
Спасибо за доклад!
Отличный доклад, спасибо!
2:30 В С++ есть подход RAII, который позволяет обойтись без ручного высвобождения ресурсов. Если писать код с учётом нескольких простых правил, то в С++ стандартных проблем, - когда забыл вызвать `delete`, - с утечками памяти не возникнет.
Удивительно, что умные указатели (работающие по принципу RAII) появились ещё в 11 стандарте (если кто не в курсе 11 он назван в честь года выхода - 2011), а мифы об утечках из-за забытого delete всё ещё всплывают.
За время работы на плюсах практически не встречал ручного высвобождения ресурсов, только в легаси.
@@olegusov1621 К сожалению, ручное освобождение ресурсов встречается не только в легаси. У многих в голову слишком въелся подход "не платить за то, что не требуется", который они воспринимают через чур строго, и такие люди не собираются разбираться в умных указателях просто потому, что у плюсов есть обычные указатели, которые самые лучшие и самые быстрые на свете (unique_ptr : "Да да, пошёл я нафиг")