Так, а что здесь будет? Хороший вопрос!
Основной моей соц. сетью последние очень много лет является твиттер (если вы вдруг не там, то вот: https://x.com/dbg_nsk). Я его нежно люблю, считаю одним из лучших форматов вообще, всех там рад видеть и все такое. Более того, мне нравится твиттер именно старой школы - с ограничением символов на каждый твит (ладно уж, пусть 280 символов, а не 140, но точно не больше). Лично для меня твиттер - это место для коротких и метких панчей, а еще, конечно, прекрасных, нажористых срачей в реплаях.
Здесь же я хочу писать относительно длинные посты, как на технические темы (ха-ха, какие технические темы? ты же под NDA!), так и просто о жизни: организаторской, преподавательской, семейной, наконец.
—
Другая проблема тви, что многовато там стало людей, которые на любой пост желают тебе мучительной смерти из-за твоего гражданства. Я все понимаю, но от этого чуть устаешь, здесь, надеюсь, получится собрать людей, у которых такой цели не будет.
—
Значит ли все это, что здесь будут только вдумчивые технические лонгриды? Абсолютно нет! Вот захочется мне рассказать про software barriers, расскажу. Захочется скинуть вам дегенератский мем - скину. А как вам история про то, как яспиздил дом из под носа у судебного пристава? Есть и такая, может когда-нибудь расскажу и ее.
Будет всякое, посмотрим, какое будет настроение, и как вообще пойдет. В любом случае, добро пожаловать!
Основной моей соц. сетью последние очень много лет является твиттер (если вы вдруг не там, то вот: https://x.com/dbg_nsk). Я его нежно люблю, считаю одним из лучших форматов вообще, всех там рад видеть и все такое. Более того, мне нравится твиттер именно старой школы - с ограничением символов на каждый твит (ладно уж, пусть 280 символов, а не 140, но точно не больше). Лично для меня твиттер - это место для коротких и метких панчей, а еще, конечно, прекрасных, нажористых срачей в реплаях.
Здесь же я хочу писать относительно длинные посты, как на технические темы (ха-ха, какие технические темы? ты же под NDA!), так и просто о жизни: организаторской, преподавательской, семейной, наконец.
—
Другая проблема тви, что многовато там стало людей, которые на любой пост желают тебе мучительной смерти из-за твоего гражданства. Я все понимаю, но от этого чуть устаешь, здесь, надеюсь, получится собрать людей, у которых такой цели не будет.
—
Значит ли все это, что здесь будут только вдумчивые технические лонгриды? Абсолютно нет! Вот захочется мне рассказать про software barriers, расскажу. Захочется скинуть вам дегенератский мем - скину. А как вам история про то, как я
Будет всякое, посмотрим, какое будет настроение, и как вообще пойдет. В любом случае, добро пожаловать!
X (formerly Twitter)
Иван Углянский (@dbg_nsk) on X
JVM engineer. Work for Excelsior @ Huawei on JVMs, compilers and new programming languages. Opinions are my own.
@jugnsk leader and @snowone_conf PC member.
@jugnsk leader and @snowone_conf PC member.
🔥20❤6🫡1
И какое удивительное совпадение: именно сегодня вышел выпуск Битовых масок, в котором я был гостем!
В этом выпуске мы 2.5 часа говорим приблизительно обо всем: AOT vs JIT, всякое про Java; про то, на чем можно писать рантаймы; про образование и сиспро.
Один только 60-секундный тизер в начале чего стоит (прости меня, Гвидо, это чуть вырвано из контекста!!!).
В общем, welcome! И подписывайтесь на канал ребят, чтобы не пропускать новые выпуски, подкаст отличный)
В этом выпуске мы 2.5 часа говорим приблизительно обо всем: AOT vs JIT, всякое про Java; про то, на чем можно писать рантаймы; про образование и сиспро.
Один только 60-секундный тизер в начале чего стоит (прости меня, Гвидо, это чуть вырвано из контекста!!!).
В общем, welcome! И подписывайтесь на канал ребят, чтобы не пропускать новые выпуски, подкаст отличный)
YouTube
Java Runtime / Интероперабельность в Java / Как учить системных программистов
Новый гость подкаста «Битовые маски» — Иван Углянский, известный разработчик JVM, член программного комитета Java-конференции SnowOne и один из создателей профиля «Системное программирование» в НГУ. Он соприкоснулся с процессом разработки компиляторов и рантаймов…
🔥15👍1
Сегодня закончился семестровый курс по плюсам, который я в этом семестре читал на сиспро.
Так то это не первое мое родео, половину времени из 10 лет преподавания на мехмате я читал именно плюсы. Но боже, какой же это был детский сад по сравнению с тем, что вышло теперь (хотя было то тоже неплохо!).
1) По содержанию: получилось дать приблизительно все, что всегда хотелось и, как мне кажется, в правильном порядке и объеме. Т.е. не просто бегло упомянуть move семантику, а довольно рано поговорить про value categories и использовать это во всех последующих темах; не просто показать шаблоны, а обсудить двухфазное разрешение имен, SFINAE, enable_if и эволюцию до концептов; не просто показать auto, но показать связь с теми же шаблонами и аккуратно выйти на universal references и perfect forwarding.
2) По формату практики: на этом курсе чуть отошел от формата "мини задачки после каждой лекции + несколько больших задач на семестр", т.к. это банально приелось. Миньки в целом то остались, хоть и стали крупнее (теперь они назывались NSTTs - not so tiny task, хехе), а вот место больших задач были большие семестровые проекты, темы для которых студенты выбирали сами. Получились: эмулятор и отладчик кода на асме для RISC-V, файловая система в юзерспейсе, своя реализация Python без GIL, в общем, очень круто.
Одной из целей здесь было научить студентов очерчивать реалистичный скоуп дел к дедлайну, а потом нести ответственность за свои факапы. Думаю, получилось.
3) По языку: курс читался полностью на английском (так было нужно). Лекции, обсуждения, прием задач, ревью, прием проектов, ответы на вопросы (и сами вопросы), экзамен. Только английский язык. Это было супер непривычно и даже тяжеловато в начале, но потом я привык и особо уже не напрягался. Чуть-чуть падает темп повествования, особенно в конце лекции, но в остальном - вполне комфортно.
--
Из минусов: подготовка такого курса, очевидно, плохо влияет на психическое здоровье (возможно и прохождение этого курса тоже, но надеюсь, что не сильно!).
Я всегда стараюсь сделать так, чтобы лекция исчерпывающе отвечала на все возникающие по ходу вопросы, и уж точно у меня самого не должно оставаться вопросов.
И вот в контексте плюсов это огромная ловушка. Потому, что а) тогда лекции просто не закончатся, слишком много деталей, б) кучу раз во время подготовки лекции у меня возникал вопрос: "хм, ну все так, конечно, но почему так? почему именно такое дизайн решение в этом языке приняли?". И поиск ответа на этот вопрос в архивах интернета, всяких старых переписках или постах затягивал меня до утра. Более того, ответ то зачастую разочаровывает - оказывается, что решение было сомнительным, это теперь все понимают, но чтож поделать.
На работе поговаривают, что у меня в этом семестре особо безумный взгляд по понедельникам, но уже вполне покорно подходят смотреть на очередные пазлеры на плюсах.
В общем, было весело! В дурку пока не уехал. Жду теперь фидбек от студентов, надеюсь, они там тоже не совсем погибли. Если читаете, можете писать фидбек в комментарии тоже)
Материалы можно глянуть здесь.
#the_real_science
Так то это не первое мое родео, половину времени из 10 лет преподавания на мехмате я читал именно плюсы. Но боже, какой же это был детский сад по сравнению с тем, что вышло теперь (хотя было то тоже неплохо!).
1) По содержанию: получилось дать приблизительно все, что всегда хотелось и, как мне кажется, в правильном порядке и объеме. Т.е. не просто бегло упомянуть move семантику, а довольно рано поговорить про value categories и использовать это во всех последующих темах; не просто показать шаблоны, а обсудить двухфазное разрешение имен, SFINAE, enable_if и эволюцию до концептов; не просто показать auto, но показать связь с теми же шаблонами и аккуратно выйти на universal references и perfect forwarding.
2) По формату практики: на этом курсе чуть отошел от формата "мини задачки после каждой лекции + несколько больших задач на семестр", т.к. это банально приелось. Миньки в целом то остались, хоть и стали крупнее (теперь они назывались NSTTs - not so tiny task, хехе), а вот место больших задач были большие семестровые проекты, темы для которых студенты выбирали сами. Получились: эмулятор и отладчик кода на асме для RISC-V, файловая система в юзерспейсе, своя реализация Python без GIL, в общем, очень круто.
Одной из целей здесь было научить студентов очерчивать реалистичный скоуп дел к дедлайну, а потом нести ответственность за свои факапы. Думаю, получилось.
3) По языку: курс читался полностью на английском (так было нужно). Лекции, обсуждения, прием задач, ревью, прием проектов, ответы на вопросы (и сами вопросы), экзамен. Только английский язык. Это было супер непривычно и даже тяжеловато в начале, но потом я привык и особо уже не напрягался. Чуть-чуть падает темп повествования, особенно в конце лекции, но в остальном - вполне комфортно.
--
Из минусов: подготовка такого курса, очевидно, плохо влияет на психическое здоровье (возможно и прохождение этого курса тоже, но надеюсь, что не сильно!).
Я всегда стараюсь сделать так, чтобы лекция исчерпывающе отвечала на все возникающие по ходу вопросы, и уж точно у меня самого не должно оставаться вопросов.
И вот в контексте плюсов это огромная ловушка. Потому, что а) тогда лекции просто не закончатся, слишком много деталей, б) кучу раз во время подготовки лекции у меня возникал вопрос: "хм, ну все так, конечно, но почему так? почему именно такое дизайн решение в этом языке приняли?". И поиск ответа на этот вопрос в архивах интернета, всяких старых переписках или постах затягивал меня до утра. Более того, ответ то зачастую разочаровывает - оказывается, что решение было сомнительным, это теперь все понимают, но чтож поделать.
На работе поговаривают, что у меня в этом семестре особо безумный взгляд по понедельникам, но уже вполне покорно подходят смотреть на очередные пазлеры на плюсах.
В общем, было весело! В дурку пока не уехал. Жду теперь фидбек от студентов, надеюсь, они там тоже не совсем погибли. Если читаете, можете писать фидбек в комментарии тоже)
Материалы можно глянуть здесь.
#the_real_science
ВКонтакте
Системное программирование ММФ НГУ
https://education.nsu.ru/syspro/
❤🔥21
Про software-barriers (часть 1)
Недавно у нас во внутреннем тестировании стали происходить спорадичные развалы в части рантайма, где уже очень давно все было прекрасно отлажено и работало, как часы. Точнее не скажу, чтобы не нарушать NDA, да это и не так важно.
Но что интересно: случаться они стали на новом тестовом сервере, который совсем недавно пришел (12th Gen Intel(R) Core i7-12700). А что еще интереснее: авторы этого модуля в рантайме не очень удивились, отреагировали буквально: "Что же, это все-таки случилось, ожидаемо. Чиним". Стоит ли говорить, что я был жутко заинтригован, когда это услышал! (совершенно был не в контексте этого куска кода).
--
Поспрашивал у ребят, потом почитал сам, и вот что выяснилось.
Довольно известный факт, что написанные подряд машинные инструкции могут исполнится в "переставленном" порядке. Процессор имеет на это право в некоторых случаях, а уж особенно интересными становятся инструкции работающие с памятью. Гарантируется ли вам, что значение, которое вы записали по некоторому адресу, будет видно при последующих чтениях? Все не так просто при наличии многих CPU. Про такую вещь, как store buffering рассказывал Саша Филатов на последнем SnowOne, вот здесь (рекомендую весь доклад к просмотру, он отличный). Этим особенно славятся слабые модели памяти (привет, ARM), хотя и на интеле это тоже вполне себе встречается:
8.2.3.4 Loads May Be Reordered with Earlier Stores to Different Locations
Но, как видите, некоторые гарантии все-таки имеются: load-ы не будут поменяны со store-ами в одну и туже память (звучит, конечно, очень логично).
Однако, тут возникает интересный вопрос: а что, если наши чтения и запись оперируют с разными размерами? Допустим, есть у вас адрес, вы туда сначала пишите байт, а потом читаете машинной слово:
И еще интереснее, а что, если мы запишем нижний байт по этому адресу, а потом прочитаем все слово (т.е. по факту даже адрес будет отличаться):
Можно консервативно предположить, что такие инструкции могут быть переставлены (обратного в спеке не сказано). Тогда здесь мы просто обязаны вставлять тяжелые хардверные барьеры (типа
Но по факту то в спеке не сказано и того, что такие инструкции могут переставляться. И вот мы в некой серой зоне, и тут то и начинается самое интересное!
--
Оказывается, есть некое тайное знание, что хоть спека явного этого и не гарантирует, интеловское железо обычно устроено так, что на это можно полагаться. Такой трюк как раз и называется software barriers (вы вместо тяжелых машинных инструкций для барьера просто генерируете специальный легковесный паттерн в коде, который дает такую же семантику).
Вот здесь можно наблюдать косвенные признаки такого поведения в виде отсутствия store to load forwarding. Кроме того, это поведение упоминалось в Intel VTune мануале (чуваки явно что-то знали). Наконец, в статье про похожую на нашу часть рантайма от 2004 года упоминалось, что бенчи были померены именно в предположении такого поведения процессора, а еще похожий трюк использовался в рантайме OpenJ9 VM.
При этом, если заглянуть чуть глубже в устройство процессора, вспомнить про протоколы когерентностей кэшей, а именно MESI, то станет понятно, что никаких гарантий тут быть не может. Подробный разбор есть в первых двух прекрасных ответах на вот этот вопрос на StackOverflow.
Итого, на лицо ситуация:по всем законам аэродинамики шмель летать не может, но ему об этом сказать забыли по всей науке реордеринг возможен, но на практике его вроде как нет. Точнее не было. На новом железе такое с завидным постоянством происходит. Вероятно, это заметили не только мы, но и, например, в IBM, т.к. в OpenJ9 кода, опирающегося на этот трюк, больше нет, и даже следов его не осталось.
Недавно у нас во внутреннем тестировании стали происходить спорадичные развалы в части рантайма, где уже очень давно все было прекрасно отлажено и работало, как часы. Точнее не скажу, чтобы не нарушать NDA, да это и не так важно.
Но что интересно: случаться они стали на новом тестовом сервере, который совсем недавно пришел (12th Gen Intel(R) Core i7-12700). А что еще интереснее: авторы этого модуля в рантайме не очень удивились, отреагировали буквально: "Что же, это все-таки случилось, ожидаемо. Чиним". Стоит ли говорить, что я был жутко заинтригован, когда это услышал! (совершенно был не в контексте этого куска кода).
--
Поспрашивал у ребят, потом почитал сам, и вот что выяснилось.
Довольно известный факт, что написанные подряд машинные инструкции могут исполнится в "переставленном" порядке. Процессор имеет на это право в некоторых случаях, а уж особенно интересными становятся инструкции работающие с памятью. Гарантируется ли вам, что значение, которое вы записали по некоторому адресу, будет видно при последующих чтениях? Все не так просто при наличии многих CPU. Про такую вещь, как store buffering рассказывал Саша Филатов на последнем SnowOne, вот здесь (рекомендую весь доклад к просмотру, он отличный). Этим особенно славятся слабые модели памяти (привет, ARM), хотя и на интеле это тоже вполне себе встречается:
8.2.3.4 Loads May Be Reordered with Earlier Stores to Different Locations
The Intel-64 memory-ordering model allows a load to be reordered with an earlier store to a different location. However, loads are not reordered with stores to the same location.
Но, как видите, некоторые гарантии все-таки имеются: load-ы не будут поменяны со store-ами в одну и туже память (звучит, конечно, очень логично).
Однако, тут возникает интересный вопрос: а что, если наши чтения и запись оперируют с разными размерами? Допустим, есть у вас адрес, вы туда сначала пишите байт, а потом читаете машинной слово:
mov byte [rcx], 1
mov eax, qword [rcx]
И еще интереснее, а что, если мы запишем нижний байт по этому адресу, а потом прочитаем все слово (т.е. по факту даже адрес будет отличаться):
mov byte [rcx + 8], 1
mov eax, qword [rcx]
Можно консервативно предположить, что такие инструкции могут быть переставлены (обратного в спеке не сказано). Тогда здесь мы просто обязаны вставлять тяжелые хардверные барьеры (типа
mfence), если хотим этого избежать. Что очень грустно, ведь это резко просадит производительность такого кода.Но по факту то в спеке не сказано и того, что такие инструкции могут переставляться. И вот мы в некой серой зоне, и тут то и начинается самое интересное!
--
Оказывается, есть некое тайное знание, что хоть спека явного этого и не гарантирует, интеловское железо обычно устроено так, что на это можно полагаться. Такой трюк как раз и называется software barriers (вы вместо тяжелых машинных инструкций для барьера просто генерируете специальный легковесный паттерн в коде, который дает такую же семантику).
Вот здесь можно наблюдать косвенные признаки такого поведения в виде отсутствия store to load forwarding. Кроме того, это поведение упоминалось в Intel VTune мануале (чуваки явно что-то знали). Наконец, в статье про похожую на нашу часть рантайма от 2004 года упоминалось, что бенчи были померены именно в предположении такого поведения процессора, а еще похожий трюк использовался в рантайме OpenJ9 VM.
При этом, если заглянуть чуть глубже в устройство процессора, вспомнить про протоколы когерентностей кэшей, а именно MESI, то станет понятно, что никаких гарантий тут быть не может. Подробный разбор есть в первых двух прекрасных ответах на вот этот вопрос на StackOverflow.
Итого, на лицо ситуация:
YouTube
Александр Филатов: !concurrent,worldHello или многопоточность глазами VM-инженера
Многопоточность — это просто! Написал "myStream.parallel()" и всё ускорилось в 10 раз.
Многопоточность — это сложно! Каждый день что-то не работает, то дедлоки, то гонки, то вообще ABA-проблема.
Многопоточность — это актуально! Закон Мура нарушился, новые…
Многопоточность — это сложно! Каждый день что-то не работает, то дедлоки, то гонки, то вообще ABA-проблема.
Многопоточность — это актуально! Закон Мура нарушился, новые…
🆒16
Про software-barriers (часть 2, последняя)
Что же касается нас, то мы, как говорится, не ждали, а готовились. Заранее был подготовлен специальный тест, который должен был бы подсветить проблему, если вдруг настанет день X. Что собственно и произошло: тест был запущен в день первого развала на новом тестовом сервере, он указал на проблемную строчку в коде, над которой был комментарий с описанием всей этой ситуации и инструкцией, что делать дальше.
Так что естественно, и мы у себя этот трюк использовать перестали, чтобы не затачиваться на по факту старое уже железо.
—
Ко всей это ситуации у меня очень двоякое отношение. С одной стороны, я восхищен тем, как научные статьи, боевые реализации JVM и Intel-специфичные тулы использовали по сути трюк, основанный на таком джентельменском соглашении, что процессор не будет переупорядочивать соответственные инструкции. Есть в этом несомненный дух авантюризма, что-то дерзкое и крутое, что-то в стиле дикого запада (пусть и подготовленным путем отхода). С другой стороны, я, конечно, испытываю хтонический ужас от того, какая же это была огромная пороховая бочка, которая по факту все-таки взорвалась.
—
P.S. кстати, основанную на этом трюке оптимизацию предлагали использовать в ядре Linux, для более эффективной реализации фьютексов. Но Торвальдс ответил вполне в своей манере. Не могу его здесь осуждать.
P.P.S. спасибо большое Саше Филатову за ревью этого поста и разъяснения!
#дух_машины
Что же касается нас, то мы, как говорится, не ждали, а готовились. Заранее был подготовлен специальный тест, который должен был бы подсветить проблему, если вдруг настанет день X. Что собственно и произошло: тест был запущен в день первого развала на новом тестовом сервере, он указал на проблемную строчку в коде, над которой был комментарий с описанием всей этой ситуации и инструкцией, что делать дальше.
Так что естественно, и мы у себя этот трюк использовать перестали, чтобы не затачиваться на по факту старое уже железо.
—
Ко всей это ситуации у меня очень двоякое отношение. С одной стороны, я восхищен тем, как научные статьи, боевые реализации JVM и Intel-специфичные тулы использовали по сути трюк, основанный на таком джентельменском соглашении, что процессор не будет переупорядочивать соответственные инструкции. Есть в этом несомненный дух авантюризма, что-то дерзкое и крутое, что-то в стиле дикого запада (пусть и подготовленным путем отхода). С другой стороны, я, конечно, испытываю хтонический ужас от того, какая же это была огромная пороховая бочка, которая по факту все-таки взорвалась.
—
P.S. кстати, основанную на этом трюке оптимизацию предлагали использовать в ядре Linux, для более эффективной реализации фьютексов. Но Торвальдс ответил вполне в своей манере. Не могу его здесь осуждать.
P.P.S. спасибо большое Саше Филатову за ревью этого поста и разъяснения!
#дух_машины
🔥19🆒3💯2👍1
Стоит, наверное, уравновешивать лонгриды контентом полегче, поэтому запощу одно из своих любимых видео в интернете, как раз про Торвальдса, (не)принимающего идею software barriers в реализации фьютексов.
Спасибо Антону, что помог его найти, а то я уж думал, что никогда его больше не увижу.
https://www.tgoop.com/ithueti/13072
#деградировать_пришел
Спасибо Антону, что помог его найти, а то я уж думал, что никогда его больше не увижу.
https://www.tgoop.com/ithueti/13072
#деградировать_пришел
Telegram
🦖 Айти Тудэй 🦥
😁11👍1🏆1
Празднуем завершение (с точностью до сессии) второго года сиспро!
У нас все получается, ребят, продолжаем. Так мы сделаем мир лучше.
#the_real_science
У нас все получается, ребят, продолжаем. Так мы сделаем мир лучше.
#the_real_science
🔥33🥴1
До того, как мы присоединились к корпорации Ху, был у Excelsior свой технический блог, где мы как раз писали технические лонгриды на английском языке.
Одним из условий сделки было закрытие блога, т.к. мы зачем-то переходили в режим тотальной скрытности (ну, может на то и были причины, но до сих пор вспоминаю это, как самое стыдное время в своей карьере).
По поводу закрытия блога я переживал особо, т.к. был его инициатором и автором многих постов. По ощущением для меня это было что-то сродни потери Александрийской библиотеки, настолько я ценил усилия, потраченные мною и моими коллегами при написании и редактуре. Ну и материал там был действительно уникальным, это была жесткая (но интересная) изнанка разработки необычной JVM.
—
Прошло пять лет, и вот мы здесь. Сегодня я подумал, а почему бы не воскресить часть старых постов в новом формате и не запостить их здесь? С точностью до языка (английский использовать для этого больше не хочу) и стиля (редактура там мой стиль жестко резала, конечно). По крайней мере думаю проделать это именно с моими личными постами, где я был единственным автором.
—
Что думаете, стоит оно того? Или лучше оставить стюардессу закопанной?
Одним из условий сделки было закрытие блога, т.к. мы зачем-то переходили в режим тотальной скрытности (ну, может на то и были причины, но до сих пор вспоминаю это, как самое стыдное время в своей карьере).
По поводу закрытия блога я переживал особо, т.к. был его инициатором и автором многих постов. По ощущением для меня это было что-то сродни потери Александрийской библиотеки, настолько я ценил усилия, потраченные мною и моими коллегами при написании и редактуре. Ну и материал там был действительно уникальным, это была жесткая (но интересная) изнанка разработки необычной JVM.
—
Прошло пять лет, и вот мы здесь. Сегодня я подумал, а почему бы не воскресить часть старых постов в новом формате и не запостить их здесь? С точностью до языка (английский использовать для этого больше не хочу) и стиля (редактура там мой стиль жестко резала, конечно). По крайней мере думаю проделать это именно с моими личными постами, где я был единственным автором.
—
Что думаете, стоит оно того? Или лучше оставить стюардессу закопанной?
👍32🔥8🆒1
да это же я тот медведь!
*смотрю на список ревью на мне, вздыхаю и вместо них иду отлаживать баги. Начнем день с чего-нибудь более приятного*
#деградировать_пришел
*смотрю на список ревью на мне, вздыхаю и вместо них иду отлаживать баги. Начнем день с чего-нибудь более приятного*
#деградировать_пришел
👾7
The Folder of God (часть 1)
В рамках раскапывания стюардессы потравлю байку из прошлой жизни, которую я уже где только не рассказывал (вот и в подкасте тоже), но изначально то это был пост, пусть в таком виде она и останется. Речь о Папке Бога.
У нас в Excelsior была такая передающаяся должность: саппортер. Мы ведь тогда делали Продукт, а значит у нас были живые пользователи, у них что-то и сломаться может. Контора маленькая, поэтому каждый инженер время от времени отправлялся на вахту: становился саппортером, отвечающим на письма клиентов. Если проблема небольшая, саппортер разбирался с ней сам, иначе создавал ишуй, который уже чинили в плановом порядке. Может звучит и не очень, но по факту это был отличный отрезвляющий опыт: оказывалось, клиентам не очень то интересны инновационные GC, им важно, чтобы все работало. Именно на саппорте я чувствовал, что делаю что-то полезное, т.к. вот же - живые люди, которые на нашей JVM делают свой бизнес, это очень воодушевляет.
Так вот, сижу я как-то на саппорте... ↓
В рамках раскапывания стюардессы потравлю байку из прошлой жизни, которую я уже где только не рассказывал (вот и в подкасте тоже), но изначально то это был пост, пусть в таком виде она и останется. Речь о Папке Бога.
У нас в Excelsior была такая передающаяся должность: саппортер. Мы ведь тогда делали Продукт, а значит у нас были живые пользователи, у них что-то и сломаться может. Контора маленькая, поэтому каждый инженер время от времени отправлялся на вахту: становился саппортером, отвечающим на письма клиентов. Если проблема небольшая, саппортер разбирался с ней сам, иначе создавал ишуй, который уже чинили в плановом порядке. Может звучит и не очень, но по факту это был отличный отрезвляющий опыт: оказывалось, клиентам не очень то интересны инновационные GC, им важно, чтобы все работало. Именно на саппорте я чувствовал, что делаю что-то полезное, т.к. вот же - живые люди, которые на нашей JVM делают свой бизнес, это очень воодушевляет.
Так вот, сижу я как-то на саппорте... ↓
❤9👍1
The Folder of God (часть 2)
Так вот, сижу я как-то на саппорте, и тут приходит письмо с жалобой: дескать мое приложение постоянно крэшается при запуске на вашей JVM. Почините!
Смотрю крэшлог, а там все плохо: какой-то развал в mscvcr100.dll (дело было на Windows), какой-то странный стектрейс, который уходит в нативы awt, ничего непонятно. Попробовал запустить у себя - конечно же не воспроизводится. Ну и знаете, создавалось четкое впечатление, что это висяк - скорее всего у пользователя есть какие-то свои нативы, там JNI misuse, на Hotspot не проявится, найти проблему в нативах будет очень трудно, на удаленную отладку он скорее всего не согласится...
Но тут меня посетила очень странная идея - погуглить кусочек крэшлога, а именно адрес развала в mscvcr100.dll. Обычно это абсолютно бесполезно, но есть мизерный шанс, что развалы не специфичны нашей JVM. Чем черт не шутит, почему бы не попробовать? Без особого энтузиазма гуглю и тут... БИНГО! Такие же точно развалы есть и на Hotspot! Нахожу целых два свежих ишуя в багтрекере, а еще, что гораздо интереснее, тред про аналогичный развал на сайте саппорта микрософта.
И что же я выяснил:
1) Проблема проявляется только на Windows 10 Creators Update v1703 (Криэйтором, Вава, криэйтором).
2) Обязательно нужен Windows look and feel (крэши всегда происходили в GUI приложениях, именно с этим LAF)
3) И самое главное... на рабочем столе должна быть создана папка GodMode.{ED7BA470-8E54-465E-825C-99712043E01C}
Вот только при этих трех условиях Hotspot (а на самом деле и JET) разваливались в труху. Стоп, какая-какая папка??
GodMode.{ED7BA470-8E54-465E-825C-99712043E01C} - это та самая Папка Бога и названия поста. Это такой странный способ в Windows сделать шорткат для панели управления: создаете такую папку, при открытии будете получать доступ к настройкам системы. Если у вас Windows, можете попробовать, это все еще работает.
Далее у меня была самая странная переписка с клиентом в моей жизни:
— Спасибо за ваше обращение, начали изучать проблему. Маленькое уточнение: а у вас случайно нет на рабочем столе папки GodMode.{ED7BA470-8E54-465E-825C-99712043E01C}?
— Эм... да, есть такая... а откуда вы знаете?
*тут стоит уточнить, что ровно в этот момент разгонялась вся эта история про русских хакеров, поэтому клиенту из Европы, получившему такое письмо от человека по имени Иван, объяснимо стало очень тревожно*
— Да так, просто догадка. А можете ее удалить и запустить свое приложение еще раз?
— Это... помогло!!! ЧТО?? КАК??? ↓
Так вот, сижу я как-то на саппорте, и тут приходит письмо с жалобой: дескать мое приложение постоянно крэшается при запуске на вашей JVM. Почините!
Смотрю крэшлог, а там все плохо: какой-то развал в mscvcr100.dll (дело было на Windows), какой-то странный стектрейс, который уходит в нативы awt, ничего непонятно. Попробовал запустить у себя - конечно же не воспроизводится. Ну и знаете, создавалось четкое впечатление, что это висяк - скорее всего у пользователя есть какие-то свои нативы, там JNI misuse, на Hotspot не проявится, найти проблему в нативах будет очень трудно, на удаленную отладку он скорее всего не согласится...
Но тут меня посетила очень странная идея - погуглить кусочек крэшлога, а именно адрес развала в mscvcr100.dll. Обычно это абсолютно бесполезно, но есть мизерный шанс, что развалы не специфичны нашей JVM. Чем черт не шутит, почему бы не попробовать? Без особого энтузиазма гуглю и тут... БИНГО! Такие же точно развалы есть и на Hotspot! Нахожу целых два свежих ишуя в багтрекере, а еще, что гораздо интереснее, тред про аналогичный развал на сайте саппорта микрософта.
И что же я выяснил:
1) Проблема проявляется только на Windows 10 Creators Update v1703 (Криэйтором, Вава, криэйтором).
2) Обязательно нужен Windows look and feel (крэши всегда происходили в GUI приложениях, именно с этим LAF)
3) И самое главное... на рабочем столе должна быть создана папка GodMode.{ED7BA470-8E54-465E-825C-99712043E01C}
Вот только при этих трех условиях Hotspot (а на самом деле и JET) разваливались в труху. Стоп, какая-какая папка??
GodMode.{ED7BA470-8E54-465E-825C-99712043E01C} - это та самая Папка Бога и названия поста. Это такой странный способ в Windows сделать шорткат для панели управления: создаете такую папку, при открытии будете получать доступ к настройкам системы. Если у вас Windows, можете попробовать, это все еще работает.
Далее у меня была самая странная переписка с клиентом в моей жизни:
— Спасибо за ваше обращение, начали изучать проблему. Маленькое уточнение: а у вас случайно нет на рабочем столе папки GodMode.{ED7BA470-8E54-465E-825C-99712043E01C}?
— Эм... да, есть такая... а откуда вы знаете?
*тут стоит уточнить, что ровно в этот момент разгонялась вся эта история про русских хакеров, поэтому клиенту из Европы, получившему такое письмо от человека по имени Иван, объяснимо стало очень тревожно*
— Да так, просто догадка. А можете ее удалить и запустить свое приложение еще раз?
— Это... помогло!!! ЧТО?? КАК??? ↓
❤11
The Folder of God (часть 3, последняя)
Ну что же, и правда стоит пояснить, что произошло, следите за руками:
1) В
2) в JDK, в части связанной с awt, есть нативный метод
3) Так, а что у нас, это ведь другая виртуальная машина? Тут интересно: мы в JET реализовали полностью работающий JNI, а значит все нативы работают из коробки. Зачем же нам тогда писать свои реализации сишных нативов для работы с GUI? Вместо этого мы просто переиспользовали нативы из JDK (это не запрещено). Соответственно, проблему с
Так что не сказать, что мы прям были виноваты. Скорее почувствовали божественное вмешательство, по-другому это историю и не назовешь!
—
Все это я рассказал и клиенту, чтобы немного унять его переживания по поводу русских хакеров, он был в восторге) Проблему же починили в следующем минорном апдейте JDK, так что она автоматически починилась и у нас.
Вот такой получился эффект бабочки: маленькая правка и изменение поведения в коде виндовой библиотеки привела к нетривиальным развалам в абсолютно разных JVM. Так и живем, друзья! С божьей помощью.
#откопали_стюардессу
Ну что же, и правда стоит пояснить, что произошло, следите за руками:
1) В
shell32.dll есть такой замечательный метод IShellFolder::GetDisplayNameOf(...), он, как нетрудно догадаться из названия, возвращает имя папки или файла для показа в GUI. Так вот для нашей божественной папки именно в Windows 10 Creators Update этот метод стал себя вести странно: все еще возвращает S_OK, т.е. вызов вроде как успешен, но вот вместо строчки STRRET возвращает NULL. 2) в JDK, в части связанной с awt, есть нативный метод
sun.awt.shell.Win32ShellFolder2.getDisplayNameOf который дергает IShellFolder::GetDisplayNameOf при использовании Windows LAF. И вот никто в этом методе не был готов к тому, что от системы вернется S_OK, но строчка при этом не вернется. Поэтому никто не проверял этот параметр STRRET, а значит очень быстро случалось разыменование NULL и развал. Этим и объясняются развалы на HotSpot-е, которые я нагуглил.3) Так, а что у нас, это ведь другая виртуальная машина? Тут интересно: мы в JET реализовали полностью работающий JNI, а значит все нативы работают из коробки. Зачем же нам тогда писать свои реализации сишных нативов для работы с GUI? Вместо этого мы просто переиспользовали нативы из JDK (это не запрещено). Соответственно, проблему с
getDisplayNameOf мы тоже унаследовали.Так что не сказать, что мы прям были виноваты. Скорее почувствовали божественное вмешательство, по-другому это историю и не назовешь!
—
Все это я рассказал и клиенту, чтобы немного унять его переживания по поводу русских хакеров, он был в восторге) Проблему же починили в следующем минорном апдейте JDK, так что она автоматически починилась и у нас.
Вот такой получился эффект бабочки: маленькая правка и изменение поведения в коде виндовой библиотеки привела к нетривиальным развалам в абсолютно разных JVM. Так и живем, друзья! С божьей помощью.
#откопали_стюардессу
🔥23