Каким-то образом за полтора дня поездки умудрился перестроиться на GMT+3. Теперь первую половину дня я абсолютный невдупленыш, а в себя прихожу и начинаю соображать только к вечеру 🦉
❤9
В следующий четверг потрещим с Сашей за преподавание и не только, присоединяйтесь!
❤6👍2
Forwarded from Ivan Ugliansky
А следующий эпизод будет в четверг: 24.10.24, в 21:00 по Нск/19:00 по Екб/17:00 по Мск, вот здесь:
https://www.youtube.com/live/KIvIlGxGhx0
Кроме ютьюба постараемся и напрямую сюда сделать трансляцию, а то с ним нынче бывает трудно.
Гостей не будет, будем мы с Сашей сидеть, трещать за жизнь и преподавание под пиво. Обсудим, что поменялось за последнее время и вообще "how it started, how it's going". Приходите послушать и/или составить нам компанию)
https://www.youtube.com/live/KIvIlGxGhx0
Кроме ютьюба постараемся и напрямую сюда сделать трансляцию, а то с ним нынче бывает трудно.
Гостей не будет, будем мы с Сашей сидеть, трещать за жизнь и преподавание под пиво. Обсудим, что поменялось за последнее время и вообще "how it started, how it's going". Приходите послушать и/или составить нам компанию)
YouTube
Вторая пересдача #16
❤🔥11👍6❤1
Стой под стрелой
Удивительное устройство Эпл Воч. Они уже месяц ежедневно предупреждают меня, что ночью будут ставить обновление, но поскольку основной их юз-кейс — трекинг сна, то ночью они обычно на руке и никакого обновления не ставят (не подключен к питанию). И не то…
Возможно, это рассчитано на таких, как я: людей, которые не использую Эпл Воч для трекинга сна (а то потом придется статистику прочитать, да и сами часы что-нибудь недоброе скажут, типа "кажется, вы забыли лечь спать, постарайтесь так больше не делать", зачем такой стресс?).
Возможно, внутри Эпл за это отвечают такие же дурачки, как я, в этом и разгадка. Но вообще, да, проблема скорее системная: у меня что айфон, что часы нифига не обновляются по ночам, хотя стоят на зарядке, их прям упрашивать надо. Я лично всегда думал, что это разработчики опять с таймзонами не справились.
Эх, если бы внутри Эпл был кто-то, кто бы сообразил, что часы-трекер сна не должны ставить обновления по ночам. Этот человек сразу на пару ступеней повышение бы получил.
Возможно, внутри Эпл за это отвечают такие же дурачки, как я, в этом и разгадка. Но вообще, да, проблема скорее системная: у меня что айфон, что часы нифига не обновляются по ночам, хотя стоят на зарядке, их прям упрашивать надо. Я лично всегда думал, что это разработчики опять с таймзонами не справились.
❤2
Подумалось: насколько фаззинг (в данном контексте - генерация случайным образом корректных входных программ) хорош для поиска компиляторных багов, но настолько же он бесполезен для поиска проблем в рантайме (багов в GC, синхронизации и т.д.).
Это, конечно, очень понятно: компилятор (хороший) стабилен и всегда работает одинаково на одних и тех же входных данных, чтобы найти проблемы вам нужно добавить случайности именно в то, что вы компилируете. Фаззер здесь божественен.
Рантайм же по своей сути работает со случайными событиями. Как именно операционная система выдавала вашим тредам кванты для работы? Кто из потоков в результате выиграл гонку за lock? Как это повлияло на скорость аллокации объектов? А это в свою очередь на момент, в которой случилась сборка мусора, и на расположение объектов в памяти к этому моменту. Это я еще не говорю про влияние других процессов, которое, конечно, тоже есть: GC вполне может ориентироваться на общее потребление памяти в системе, да и опять таки, кванты то им тоже выдаются, т.е. общая загруженность системы может радикально повлиять на всю картину происходящего в рантайме.
Конечно же, можно сказать, что все это в конце концов детерминировано, просто влияющих факторов очень много. Но какая разница, если при каждом новом запуске мы получаем все новые события? Все это напоминает старый, как жизнь, спор: "существует ли у человека свобода выбора или любой наш выбор предрешен, пусть и огромным количеством факторов?". Лично для меня здесь нет никакого противоречия: глобальный детерминизм логичен, но в условиях невозможности наблюдения всех первопричин это не имеет никакого значения, а значит можно считать, что свобода выбора существует. Вот и получается, что GC с рантаймом - тоже в определенном смысле наделены такой свободой, характером и удачей.
Ну и какой же тут может быть толк от фаззера? Случайность, которую он порождает на порядок меньше той, с которой мы сталкиваемся в рантайме при прокачке гигабайтов памяти средним таким приложением на спринге. Гораздо полезнее для нас варировать паттерны поведения операционной системы, например, рандомно менять приоритеты тредам, как в chaos mode чудесного отладчика rr, или же полностью подменить планировщик на свой, как это сделано в Hermit, и уже в него добавлять свою, контролируемую случайность. Вот это и правда может вскрыть очень сложные, спорадичные баги в рантайме, т.к. путь исполнения будет максимально нетипичен, даже для такой хаотичной системы.
Забавно, что вот эти chaos моды добавляют тулы, которые как раз создавались для уменьшения недетерменизма и помощи в отладке (чтобы дать стабильный способ воспроизведения спорадичной проблемы). Но оказывается, что когда борешься с хаосом, со временем начинаешь неплохо понимать, как его можно создавать самостоятельно. Нахожу это очень поэтичным.
#дух_машины
Это, конечно, очень понятно: компилятор (хороший) стабилен и всегда работает одинаково на одних и тех же входных данных, чтобы найти проблемы вам нужно добавить случайности именно в то, что вы компилируете. Фаззер здесь божественен.
Рантайм же по своей сути работает со случайными событиями. Как именно операционная система выдавала вашим тредам кванты для работы? Кто из потоков в результате выиграл гонку за lock? Как это повлияло на скорость аллокации объектов? А это в свою очередь на момент, в которой случилась сборка мусора, и на расположение объектов в памяти к этому моменту. Это я еще не говорю про влияние других процессов, которое, конечно, тоже есть: GC вполне может ориентироваться на общее потребление памяти в системе, да и опять таки, кванты то им тоже выдаются, т.е. общая загруженность системы может радикально повлиять на всю картину происходящего в рантайме.
Конечно же, можно сказать, что все это в конце концов детерминировано, просто влияющих факторов очень много. Но какая разница, если при каждом новом запуске мы получаем все новые события? Все это напоминает старый, как жизнь, спор: "существует ли у человека свобода выбора или любой наш выбор предрешен, пусть и огромным количеством факторов?". Лично для меня здесь нет никакого противоречия: глобальный детерминизм логичен, но в условиях невозможности наблюдения всех первопричин это не имеет никакого значения, а значит можно считать, что свобода выбора существует. Вот и получается, что GC с рантаймом - тоже в определенном смысле наделены такой свободой, характером и удачей.
Ну и какой же тут может быть толк от фаззера? Случайность, которую он порождает на порядок меньше той, с которой мы сталкиваемся в рантайме при прокачке гигабайтов памяти средним таким приложением на спринге. Гораздо полезнее для нас варировать паттерны поведения операционной системы, например, рандомно менять приоритеты тредам, как в chaos mode чудесного отладчика rr, или же полностью подменить планировщик на свой, как это сделано в Hermit, и уже в него добавлять свою, контролируемую случайность. Вот это и правда может вскрыть очень сложные, спорадичные баги в рантайме, т.к. путь исполнения будет максимально нетипичен, даже для такой хаотичной системы.
Забавно, что вот эти chaos моды добавляют тулы, которые как раз создавались для уменьшения недетерменизма и помощи в отладке (чтобы дать стабильный способ воспроизведения спорадичной проблемы). Но оказывается, что когда борешься с хаосом, со временем начинаешь неплохо понимать, как его можно создавать самостоятельно. Нахожу это очень поэтичным.
#дух_машины
Wikipedia
Фаззинг
Фа́ззинг (англ. fuzzing или англ. fuzz testing, буквально «испытание пушинками/волосинками», от англ. fuzz — с изначальным значением «делать неопрятным», «с прилипшими волосками», затем переносным «затуманивать», «путать»), также тестирование мусорными данными…
🔥16
This media is not supported in your browser
VIEW IN TELEGRAM
Про Линуса уже только ленивый не написал, конечно, но как такое игнорировать?
Другими словами: "вы мне еще за русско-финскую ответите, суки" и "опенсорс, он кому надо опенсорс, понятно?".
As to sending me a revert patch - please use whatever mush you call brains. I'm Finnish. Did you think I'd be *supporting* Russian aggression? Apparently it's not just lack of real news, it's lack of history knowledge too.
Другими словами: "вы мне еще за русско-финскую ответите, суки" и "опенсорс, он кому надо опенсорс, понятно?".
😁25🍌3💯1
погнали на вторую пересдачу: https://www.youtube.com/live/KIvIlGxGhx0
YouTube
Вторая пересдача #16
❤7
Forwarded from Кулешов разгоняет
Так, с мест передают смешное, кто-то пытается выпилить Линуса из Линукса.
😁9🤣2👍1🤩1
Забежал в универ мимоходом в нетипичное для себя время, а тут просто огромная концентрация сиспрошников разных курсов на квадратный метр. Приятно ☺️
Хорошего всем дня!
Хорошего всем дня!
❤24❤🔥3👍1
Наконец, важный вопрос. Может мне бороду сбрить?
Anonymous Poll
23%
Бороду долой
36%
Ни в коем случае
41%
Поспорить с кем-то, поставив на кон бороду, а дальше все решит случай
Обещал тут порассказывать про свои самые злые кранчи. Кажется, сегодня просто идеально подходящий для этого вечер! (начинающаяся осенняя хандра, временное состояние отца-одиночки и просто миллион дел на эту неделю - атмосфера что надо).
---
Итак, кранч первый, пост-студенческий.
Немного контекста: в универе у меня был диплом про то, как сделать из консервативного сборщика мусора точный. В JVM со странным рантаймом, лишь наполовину написанном на managed языке, чём-то типа Java.
Опишу суть в паре предложений. Если супер упростить, то трассирующая сборка мусора в managed языке - это такой DFS: нужно выбрать объекты, которые 100% живы, и найти всех достижимых из них по ссылкам. Все, что вы не нашли - это и есть мусор. Есть небольшая проблемка: граф большеват - миллионы объектов, а обойти его нужно очень быстро - за миллисекунды. Отсюда и куча классных алгоритмов, как это делать эффективно, или по кускам, или параллельно с работой приложения, или еще как.
Но есть еще вопрос с тем, что такое "выбрать объекты, которые 100% живы". Как собственно это сделать? Ну, вот, например, локалы, которые еще будут использовать в будущем: ссылки в них то всяко живы, объекты, на которые они ссылаются - тоже. А как их найти в скомпилированном коде? На каких они регистрах, в каких стековых слотах? Тут есть два подхода:
1) Спросить у компилятора, он точно знает (он же этот код сгенерил!). Он вам может записать структуры данных, в которых будет сказано: "вот в этой точке в коде на rdx лежит ссылка на живой объект, начинай-ка разметку с нее". Понятны с этим проблемы: нужно тормозить треды только в этих специальных точках, а не где попало, для этих точек генерить какую-то метаинфу (а она ведь место занимает), и уже по ней GC будет находить гарантированно живые объекты,
2) Забить на компилятор. Консервативно предполагать, что любой регистр и любой стековый слот содержит указатель на объект, а потом (зная структуру памяти и особенности работы аллокатора) отсеивать всякий мусор. Так делают, когда хотят прикрутить GC к C++, например (там то откуда вам знать: лежит ли у вас на стеке просто чиселко или указатель, приходится падать в консерватизм).
Тут плюсы и минусы тоже понятны: с одной стороны никакой тебе метаинфы лишней и тормози треды (почти) где хочешь, с другой - консерватизм чреват ошибками. Объекты, которые давно померли могут быть признаны живыми, а это потенциально может привести к бесконечному потреблению памяти. Ну, как "потенциально", именно это и случалось у некоторых наших клиентов.
Собственно, что мне нужно было сделать: перейти от подхода консервативного GC, который по историческим причинам был у нас сделан, к точному GC. При этом постараться не слишком драматично просадить производительность, но главное - добиться корректности.
Это в свою очередь было не так просто в том числе и из-за хитрого рантайма, который лишь наполовину был написан на managed языке (там не так то просто гарантировать, что исполнение дойдет до safe-point за разумное время).
Ну и дополнительной сложностью было то, что такой работой никто в общем-то не занимается. Ну т.е. да, есть классические статьи Ole Agesen, где в общих чертах описано все, что нужно сделать. Но там a) нет кучи технических деталей, б) там рантайм то обычный, т.е. со многими основательными проблемами реализации никто и не сталкивался раньше (в SubstrateVM столкнулись, но у нас с ними получились прям разные решения).
Короче, задача то в целом довольно инженерная, совсем не rocket science, но чтобы ее сделать нужно просто огромный масштаб изменений провести в рамках кодовой базы JVM, прям с нуля ввести концепции, которых раньше в этой кодовой базе никогда и не было (хотя бы даже safe-points).
Так что в сумме (с перерывами на поход в enterprise и поиск себя) ушло у меня на это дело полтора года: половину на прототипирование (так появляется диплом бакалавра), половину на продуктизацию и решения проблем с рантаймом (так появляется диплом магистра).
Что-то не получилось рассказать контекст за пару предложений, но что поделать) Давайте переходить к кранчу ↓
#дух_машины
---
Итак, кранч первый, пост-студенческий.
Немного контекста: в универе у меня был диплом про то, как сделать из консервативного сборщика мусора точный. В JVM со странным рантаймом, лишь наполовину написанном на managed языке, чём-то типа Java.
Опишу суть в паре предложений. Если супер упростить, то трассирующая сборка мусора в managed языке - это такой DFS: нужно выбрать объекты, которые 100% живы, и найти всех достижимых из них по ссылкам. Все, что вы не нашли - это и есть мусор. Есть небольшая проблемка: граф большеват - миллионы объектов, а обойти его нужно очень быстро - за миллисекунды. Отсюда и куча классных алгоритмов, как это делать эффективно, или по кускам, или параллельно с работой приложения, или еще как.
Но есть еще вопрос с тем, что такое "выбрать объекты, которые 100% живы". Как собственно это сделать? Ну, вот, например, локалы, которые еще будут использовать в будущем: ссылки в них то всяко живы, объекты, на которые они ссылаются - тоже. А как их найти в скомпилированном коде? На каких они регистрах, в каких стековых слотах? Тут есть два подхода:
1) Спросить у компилятора, он точно знает (он же этот код сгенерил!). Он вам может записать структуры данных, в которых будет сказано: "вот в этой точке в коде на rdx лежит ссылка на живой объект, начинай-ка разметку с нее". Понятны с этим проблемы: нужно тормозить треды только в этих специальных точках, а не где попало, для этих точек генерить какую-то метаинфу (а она ведь место занимает), и уже по ней GC будет находить гарантированно живые объекты,
2) Забить на компилятор. Консервативно предполагать, что любой регистр и любой стековый слот содержит указатель на объект, а потом (зная структуру памяти и особенности работы аллокатора) отсеивать всякий мусор. Так делают, когда хотят прикрутить GC к C++, например (там то откуда вам знать: лежит ли у вас на стеке просто чиселко или указатель, приходится падать в консерватизм).
Тут плюсы и минусы тоже понятны: с одной стороны никакой тебе метаинфы лишней и тормози треды (почти) где хочешь, с другой - консерватизм чреват ошибками. Объекты, которые давно померли могут быть признаны живыми, а это потенциально может привести к бесконечному потреблению памяти. Ну, как "потенциально", именно это и случалось у некоторых наших клиентов.
Собственно, что мне нужно было сделать: перейти от подхода консервативного GC, который по историческим причинам был у нас сделан, к точному GC. При этом постараться не слишком драматично просадить производительность, но главное - добиться корректности.
Это в свою очередь было не так просто в том числе и из-за хитрого рантайма, который лишь наполовину был написан на managed языке (там не так то просто гарантировать, что исполнение дойдет до safe-point за разумное время).
Ну и дополнительной сложностью было то, что такой работой никто в общем-то не занимается. Ну т.е. да, есть классические статьи Ole Agesen, где в общих чертах описано все, что нужно сделать. Но там a) нет кучи технических деталей, б) там рантайм то обычный, т.е. со многими основательными проблемами реализации никто и не сталкивался раньше (в SubstrateVM столкнулись, но у нас с ними получились прям разные решения).
Короче, задача то в целом довольно инженерная, совсем не rocket science, но чтобы ее сделать нужно просто огромный масштаб изменений провести в рамках кодовой базы JVM, прям с нуля ввести концепции, которых раньше в этой кодовой базе никогда и не было (хотя бы даже safe-points).
Так что в сумме (с перерывами на поход в enterprise и поиск себя) ушло у меня на это дело полтора года: половину на прототипирование (так появляется диплом бакалавра), половину на продуктизацию и решения проблем с рантаймом (так появляется диплом магистра).
Что-то не получилось рассказать контекст за пару предложений, но что поделать) Давайте переходить к кранчу ↓
#дух_машины
🔥10👍3