Как вы уже заметили, формат семинара эволюционировал и принял новую форму: каждый последующий семинар теперь посвящается целиком и полностью какой-либо теме. Пятый был посвящен теме Garbage Collector и за 10 часов раскрыл всё, что только возможно, оставив за скобками совсем уж частные вопросы. А его кульминацией был доклад про практическое применение (вопрос, который интересует каждого — "зачем всё это знать??")

Второй вопрос, который, как мне кажется, хочется знать всем, но на это, как правило, нет времени — это вопрос работы в многопоточном коде и вопрос планирования и поддержки его архитектуры. Вопросы эти — достаточно сложные, пугающие, а зачастую — вообще отталкивающие. И ровно поэтому дальше простейших конструкций синхронизации обычный разработчик не уходит. А ведь вокруг столько всего интересного :)

Не так давно на Хабре появилась прекрасная статья Оптимизация сборки мусора в высоконагруженном .NET сервисе. Эта статья очень интересна тем, что авторы, вооружившись теорией сделали ранее невозможное: оптимизировали свое приложение, используя знания о работе GC. И если ранее мы не имели ни малейшего понятия, как этот самый GC работает, то теперь он нам представлен на блюдечке стараниями Конрада Кокоса в его книге Pro .NET Memory Management. Какие выводы почерпнул для себя я? Давайте составим список проблемных областей и подумаем, как их можно решить.

На недавно прошедшем семинаре CLRium #5: Garbage Collector мы проговорили про GC весь день. Однако, один доклад я решил опубликовать с текстовой расшифровкой. Это доклад про выводы относительно оптимизации приложений.

13 апреля в Санкт-Петербурге (оффлайн и онлайн) и 20 апреля — в Москве (только оффлайн) пройдет самый крупный семинар CLRium#5 за всё время его существования.

Прокопав дебри алгоритмов управления памятью я теперь могу, наконец, ответить на извечный вопрос: "а зачем это знать?". Раньше кроме как just for fun до этого момета мне сложно было что-то ответить по одной простой причине: по-хорошему мы ничего не знали о том, как работает память в .NET. Мы знали что есть GC, что есть в целях оптимизации три поколения. Кто-то из нас даже знал про эфимерные сегменты и карточный стол. Но это выглядело скорее как буклет к чему-то более сложному, что никак не описано. И теперь, когда есть и исходники и люди, в них копающиеся, мы, наконец можем ответить на этот вопрос.

Мы приглашаем вас всех на этот семинар и в течении которого с 10:00 до 20:00 с перерывами на снять напряжение с головы будет рассказано очень и очень многое о том, как же всё-таки всё устроено.

Давайте посмотрим, что об этом сказано в блоге о предстоящих изменениях в С# 8.0 (версия Visual Studio 2019 Preview 2):

«stack-only структуры появились в С# 7.2. Они чрезвычайно полезны, но при этом их использование тесно связано с ограничениями, например невозможностью реализовывать интерфейсы. Теперь ссылочные структуры можно очищать с помощью метода Dispose внутри них без использования интерфейса IDisposable».

Так и есть: stack-only ref структуры не реализуют интерфейсы, иначе возникала бы вероятность их упаковки. Следовательно, они не могут реализовывать IDisposable, и мы не можем использовать эти структуры в операторе using:

class Program
{
   static void Main(string[] args)
   {
      using (var book = new Book())
      {
         Console.WriteLine("Hello World!");
      }
   }
}

ref struct Book : IDisposable
{
   public void Dispose()
   {
   }
}

Попытка запустить этот код приведёт к ошибке компиляции

Наш семинар уверенно набирает слушателей и постепенно перерастает офис компании EPAM в Петербурге: мы планируем набрать до 250 разработчиков под одной крышей как в Петербурге, так и в Москве. А всё почему?

Когда-то я выступал с докладом по работе Garbage Collector и доклад этот хоть и был длиной в 45 минут, он покрывал все известные на тот момент темы. Вы наверняка его видели: ведь он был и на CLRium #2 и на конференции .NEXT, где являлся кей-ноутом. Докладом, открывающим конференцию (огромное спасибо 23derevo и real_ales за возможность). Кроме моего и многих других докладов в свет вышла книга Under the Hood of .NET Memory Management, проливающая свет на алгоритмы работы подкапотного пространства платформы .NET. И примерно в тот период времени, когда к движку CLR так вырос интерес, на собеседованиях начали появляться вопросы про этот самый GC. Не поверхностные вопросы, а с некоторым уклоном в "расскажите поподробнее". И хоть такие вопросы и вызывали бурю возмущения у специалистов, те люди, которые рассказывали о ядре подробно, были без проблем устроены на работу. Зачастую, с хорошим повышением оклада.

Сегодня у вас есть по сути два пути, чтобы стать приоритетом #1 для работодателя:

1. Найти месяц-два времени и прочитать книгу Pro .NET Memory Management
2. Сходить на наш семинар и за один день понять вообще всё. Плюс получить видеозаписи для того чтобы потом освежить память

CLRium #5: Garbage Collector пройдет 13 апреля в Санкт-Петербурге и 20 апреля — в Москве, а все подробности — под катом

Мир несется вперед, движимый прогрессом и конкуренцией. Нам с вами нереально повезло: ведь для нас работают величайшие умы, создавая поистине серъезные механизмы: компиляторы, IDE, базы данных. Делают их так, что мы получаем истинное удовольствие, используя их.

Один из этих механизмов — это работа подсистемы управления памятью платформы .NET. И если раньше никто не имел ни малейшего понятия как оно работает, то теперь, когда у нас есть исходники, все секреты открыты. Теперь видно абсолютно все подробности работы ядра платформы: и это действительно завораживает. Например, если ранее мы думали, что выделение памяти — это просто сдвинуть указатель, то теперь стало ясно что все несколько сложнее и интереснее. Это выверенный, прекрасный алгоритм, не оставляющий вопросов: а почему сделано именно так.

Второй очень важный момент — полное отсутствие времени между работой и семьей чтобы всё выучить и понять: разобраться с аспектами работы платформы. Так вот данный семинар — прекрасная возможность не тратя десятки часов на вычитку блогов и книг раз и навсегда разобраться, как же всё функционирует. И поверьте, я очень постараюсь чтобы каждый момент был ясен всем

CLRium #5: Garbage Collector пройдет 13 и 14 апреля в Санкт-Петербурге и 20 апреля — в Москве, а все подробности — под катом

13 и 14 апреля в Санкт-Петербурге, а 20 апреля в Москве будет проведен семинар CLRium #5, целиком и полностью посвященный подсистемам ядра CoreCLR и .NET Framework.

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

10 докладов. Исключительно про ядро. 6 из них — только про подсистему управления памятью.

За окном бушует весна и гололед, а мы решили провести семинар CLRium #5, который на этот раз будет посвящен целиком и полностью самому низкому уровню: подсистемой управления памятью.

Я, Станислав Сидристый, автор книги .NET Platform Architecture, решился объединить разрозненную по всему интернету информацию и сделать большой семинар, который будет почти полностью посвящен теме управления памятью. Поверьте: можно смело назначать собеседования сразу после семинара. Вопросы, которые будут касаться управлением памятью вы ответите очень глубоко.

Шесть из десяти докладов раскроют тему управления памятью, алгоритмов и причин выбора алгоритмов работы GC так глубоко, как не сможет раскрыть ни одна конференция: ведь ни на одной конференции никто не даст выступить с докладом на 4,5 часа (6 докладов по 45 минут)

Ну и как заведено: все подробности под катом

Вы любите продуктовые доклады? Я — нет. А вы любите доклады, не относящиеся к теме конференции? Я — категорически нет. Складывается ощущение что я плачу за чужие амбиции и отсутствие контента. Потому мы делаем CLRium 4: где собираем все самое последнее, полезное… И самое главное — кишочки!

Теперь, помимо докладов будет жаркая дискуссия между спикерами по возможностям C# 8.0, которые полны неоднозначных моментов. И поверьте, будет жара: я многие моменты не приемлю, а вот второй спикер, Александр Кугушев уверяет что они так полезны, что хоть завтра — в прод. Наталия Цвилих придерживается смешанной точки зрения… Интереснейшая получится беседа, я вам обещаю.

Почитать и зарегистрироваться

• Ссылка на регистрацию в Питере+онлайн, 19 октября
• Ссылка на регистрацию в Москве, 26 октября

Примеры статей и полный список тем выступлений — под катом

Я не люблю заезженное слово «конференция». Это — встреча разработчиков с общими интересами, которые хотят послушать о будущем своей любимой платформы, а также о трюках, которые позволяют обходить правила, установленные в .NET Framework. Формат встречи — это десять слотов, которые заполнены только выжимкой самого современного, иногда даже еще не вышедшего функционала. Это как раз тот самый формат, когда нет необходимости забивать сетку докладами, которые не имеют никакого отношения к теме конференции. Наборот: идет плотная работа над отсевом не перспективных не относящихся к нашей платформе тем.

Я надеюсь, в вашей памяти теплятся еще прошлые версии CLRium. Я помню и время от времени поглядываю на ваши многочисленные отзывы, которые греют мое желание провести все еще раз. Причем на этот раз — с уклоном в будущее. А у меня по поводу будущего есть спойлер: .NET Framework будет закрыт в угоду Core CLR. Почему? Приходите и по цене одной заправки автомобиля вы все узнаете сами.

Почему я приглашаю всех? Темы встречи все как на подбор и позволяют окунуться в настоящее нашей opensource платформы. Вот честно, я бы сам сходил: разбираем эволюцию функционала CoreCLR: от 2.0 от 3.0, отладку при помощи самописного отладчика, богатейшие и очень спорные возможности C# 7.*, 8.0, Garbage Collector API, новые средства наделения свойствами управляемости неуправляемых ресурсов и многое другое.

Почитать и зарегистрироваться

• Ссылка на регистрацию в Питере+онлайн, 19 октября
• Ссылка на регистрацию в Москве, 26 октября

Примеры статей и полный список тем выступлений — под катом

GC API, C# 8.0, Global Tools, Span, Memory, System.IO.Pipeline, чего ждать в будущем

Рассуждая с коллегами о вопросах развития технологий, мы как-то пришли к выводу что в тот момент, когда выныриваешь из кода и прочих задач и бросаешь взгляд либо в сторону Хабра, либо в сторону бесконечных тематических лент Телеграма возникает странное чувство, что что-то пропустил. И чувство это знакомо каждому: профессия у нас такая, что не дает расслабиться. Причем даже если подписаться на каналы, RSS ленты и прочие источники, возникнет другая проблема: чувство усталости от потока информации (зачастую, мусорной). Как успеть за прогрессом, не теряя драгоценного времени?

Темой четвертой серии CLRium станут как обычно — самые последние последние наработки из мира .NET: мы в течении одного дня расскажем подробнее о том, что уже можно потрогать и бегло о том — что только планируется. Посещение данного мероприятия — прекрасный способ освежить понимание вектора развития нашей прекрасной платформы и узнать то, на что обычно не хватает времени и решить для себя что-нибудь попробовать в ближайшем будущем.

• 19 октября в Санкт-Петербурге + online, в офисе компании Epam Systems
• 26 октября в Москве

Темы: C# 8.0, .NET Core 2.2 и .NET Core 3.0, CLR

Вы успеваете отслеживать все свежее в мире .NET, что происходит в последнее время? C# 8.0? Span/Memory? ValueTasks? System.IO.Pipeline? CLI API & Global Tools? Если нет, то лучший способ наверстать упущенное — сходить на профильное мероприятие и ровно за один день понять сразу все темы вместе взятые и решить для себя, что будет полезным, а что должно выдержать еще одну проверку временем.

Темой четвертой серии CLRium станут как обычно — самые последние последние наработки из мира .NET: мы расскажем подробнее о том, что уже можно потрогать и бегло о том, что только планируется. Посещение данного мероприятия — прекрасный способ освежить понимание вектора развития нашей прекрасной платформы и узнать то, на что обычно не хватает времени и решить для себя что-нибудь попробовать в ближайшем будущем.

В этом году мы решили захватить лучшие практики прошлых лет:

• Доклады без продуктового какие мы классные маркетинга, только ядро платформы
• Полный апгрейд знаний до версии .NET Core 3.0
• Где возможно — максимальный хардкор (вы меня знаете)
• Прекрасная цена в 3,000 рублей за день. Все еще по цене полутора заправок
• Классные, удобные, современные залы

Интересно? Милости просим под кат!

• 19 октября в Санкт-Петербурге, в офисе компании Epam Systems
• 26 октября в Москве

Существует ряд исключительных ситуаций, которые скажем так… Несколько более исключительны чем другие. Причем если попытаться их классифицировать, то как и было сказано в самом начале главы, есть исключения родом из самого .NET приложения, а есть исключения родом из unsafe мира. Их в свою очередь можно разделить на две подкатегории: иcключительные ситуации ядра CLR (которое по своей сути — unsafe) и любой unsafe код внешних библиотек.

Давайте поговорим про эти особые исключительные ситуации.

ThreadAbortException

Вообще, это может показаться не очевидным, но существует четыре типа Thread Abort.

Примечание

Глава, опубликованная на Хабре не обновляется и возможно, уже несколько устарела. А потому, прошу обратиться за более свежим текстом к оригиналу:

• CLR Book: GitHub, оглавление
• CLR Book: GitHub, глава
• Релиз 0.5.2 книги, PDF: GitHub Release

События об исключительных ситуациях

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

try {
    // ...
} catch {
    // do nothing, just to make code call more safe
}

В такой ситуации может оказаться что выполнение кода уже не так безопасно как выглядит, но сообщений о том что произошли какие-то проблемы мы не имеем. Второй вариант — когда приложение глушит некоторое, пусть даже легальное, исключение. А результат — следующее исключение в случайном месте вызовет падение приложения в некотором будущем от случайной казалось бы ошибки. Тут хотелось бы иметь представление, какая была предыстория этой ошибки. Каков ход событий привел к такой ситуации. И один из способов сделать это возможным — использовать дополнительные события, которые относятся к исключительным ситуациям: AppDomain.FirstChanceException и AppDomain.UnhandledException.

Примечание

Глава, опубликованная на Хабре не обновляется и возможно, уже несколько устарела. А потому, прошу обратиться за более свежим текстом к оригиналу:

• CLR Book: GitHub, оглавление
• CLR Book: GitHub, глава
• Релиз 0.5.2 книги, PDF: GitHub Release

Этой статьей я продолжаю публиковать целую серию статей, результатом которой будет книга по работе .NET CLR, и .NET в целом. За ссылками — добро пожаловать под кат.

Memory<T> и ReadOnlyMemory<T>

Визуальных отличий Memory<T> от Span<T> два. Первое — тип Memory<T> не содержит ограничения ref в заголовке типа. Т.е., другими словами, тип Memory<T> имеет право находиться не только на стеке, являясь либо локальной переменной либо параметром метода либо его возвращаемым значением, но и находиться в куче, ссылаясь оттуда на некоторые данные в памяти. Однако эта маленькая разница создает огромную разницу в поведении и возможностях Memory<T> в сравнении с Span<T>. В отличии от Span<T>, который представляет собой средство пользования неким буфером данных для некоторых методов, тип Memory<T> предназначен для хранения информации о буфере, а не для работы с ним.

Примечание

Глава, опубликованная на Хабре не обновляется и возможно, уже несколько устарела. А потому, прошу обратиться за более свежим текстом к оригиналу:

• CLR Book: GitHub, оглавление
• CLR Book: GitHub, глава
• Релиз 0.5.2 книги, PDF: GitHub Release

С этой статьей я продолжаю публиковать целую серию статей, результатом которой будет книга по работе .NET CLR, и .NET в целом. За ссылками — добро пожаловать под кат.

Архитектура исключительной ситуации

Наверное, один из самых важных вопросов, который касается темы исключений — это вопрос построения архитектуры исключений в вашем приложении. Этот вопрос интересен по многим причинам. Как по мне так основная — это видимая простота, с которой не всегда очевидно, что делать. Это свойство присуще всем базовым конструкциям, которые используются повсеместно: это и IEnumerable, и IDisposable и IObservable и прочие-прочие. С одной стороны, своей простотой они манят, вовлекают в использование себя в самых разных ситуациях. А с другой стороны, они полны омутов и бродов, из которых, не зная, как иной раз и не выбраться вовсе. И, возможно, глядя на будущий объем у вас созрел вопрос: так что же такого в исключительных ситуациях?

Примечание

Глава, опубликованная на Хабре не обновляется и возможно, уже несколько устарела. А потому, прошу обратиться за более свежим текстом к оригиналу:

• CLR Book: GitHub, оглавление
• CLR Book: GitHub, глава
• Релиз 0.5.2 книги, PDF: GitHub Release

С этой статьей я продолжаю публиковать целую серию статей, результатом которой будет книга по работе .NET CLR, и .NET в целом (уже готово около 200 страниц книги, так что добро пожаловать в конец статьи за ссылками).

Как язык, так и платформа существуют уже много лет: и все это время существовало множество средств для работы с неуправляемым кодом. Так почему же сейчас выходит очередной API для работы с неуправляемым кодом если по сути он существовал уже много-много лет? Для того чтобы ответить на этот вопрос достаточно понять чего не хватало нам раньше.

Разработчики платформы и раньше пытались нам помочь скрасить будни разработки с использованием неуправляемых ресурсов: это и автоматические врапперы для импортируемых методов. И маршаллинг, который в большинстве случаев работатет автоматически. Это также инструкция stackallloc, о которой говорится в главе про стек потока. Однако, как по мне если ранние разработчики с использованием языка C# приходили из мира C++ (как сделал это и я), то сейчас они приходят из более высокоуровневых языков (я, например, знаю разработчика, который пришел из JavaScript). А что это означает? Это означает что люди со все большим подозрением начинают относиться к неуправляемым ресурсам и конструкциям, близким по духу к C/C++ и уж тем более — к языку Ассемблера.

Примечание

Глава, опубликованная на Хабре не обновляется и возможно, уже несколько устарела. А потому, прошу обратиться за более свежим текстом к оригиналу:

• CLR Book: GitHub, оглавление
• CLR Book: GitHub, глава
• Релиз 0.5.2 книги, PDF: GitHub Release

С этой статьей я продолжаю публиковать целую серию статей, результатом которой будет книга по работе .NET CLR, и .NET в целом. Вся книга будет доступна на GitHub (ссылка в конце статьи).

В C# существует достаточно интересное и очень редко используемое ключевое слово stackalloc. Оно настолько редко встречается в коде (тут я даже со словом «редко» преуменьшил. Скорее, «никогда»), что найти подходящий пример его использования достаточно трудно а уж придумать тем более трудно: ведь если что-то редко используется, то и опыт работы с ним слишком мал. А все почему? Потому что для тех, кто наконец решается выяснить, что делает эта команда, stackalloc становится более пугающим чем полезным: темная сторона stackalloc — unsafe код. Тот результат, что он возвращает не является managed указателем: значение — обычный указатель на участок не защищенной памяти. Причем если по этому адресу сделать запись уже после того как метод завершил работу, вы начнете писать либо в локальные переменные некоторого метода или же вообще перетрете адрес возврата из метода, после чего приложение закончит работу с ошибкой. Однако наша задача — проникнуть в самые уголки и разобраться, что в них скрыто. И понять, в частности, что если нам дали этот инструмент, то не просто же так, чтобы мы смогли найти секретные грабли и наступить на них со всего маху. Наоборот: нам дали этот инструмент чтобы мы смогли им воспользоваться и делать поистине быстрый софт. Я, надеюсь, вдохновил вас? Тогда начнем.

Примечание

Глава, опубликованная на Хабре не обновляется и возможно, уже несколько устарела. А потому, прошу обратиться за более свежим текстом к оригиналу:

• CLR Book: GitHub, оглавление
• CLR Book: GitHub, глава, ссылка на часть `Выделение памяти на стеке: stackalloc`
• Релиз 0.5.2 книги, PDF: GitHub Release

С этой статьей я продолжаю публиковать целую серию статей, результатом которой будет книга по работе .NET CLR, и .NET в целом. Вся книга будет доступна на GitHub (ссылка в конце статьи). Так что Issues и Pull Requests как всегда приветствуются :)

Существует область памяти, про которую редко заходит разговор. Однако эта область является, возможно, основной в работе приложения. Самой часто используемой, достаточно ограниченной с моментальным выделением и освобождением памяти. Область эта называется «стек потока». Причем поскольку указатель на него кодируется по своей сути регистрами процессора, которые входят в контекст потока, то в рамках исполнения любого потока стек потока свой. Зачем же он необходим? Давайте вместе окунемся в мир низкоуровневых структур, на основе которых работает все: начиная от DOS программ и заканчивая .NET Framework, установленным поверх Windows 10.

Итак, разберем элементарный пример кода:

void Method1()
{
    Method2(123);
}

void Method2(int arg)
{
    // ...
}

В данном коде не происходит ничего примечательного, однако не будем его пропускать, а наоборот: посмотрим на него максимально внимательно.

Примечание

Глава, опубликованная на Хабре не обновляется и возможно, уже несколько устарела. А потому, прошу обратиться за более свежим текстом к оригиналу:

• CLR Book: GitHub, оглавление
• CLR Book: GitHub, глава
• Релиз 0.5.2 книги, PDF: GitHub Release

С этой статьей я продолжаю публиковать целую серию статей, результатом которой будет книга по работе .NET CLR, и .NET в целом.

Вся книга будет доступна на GitHub: CLR Book. Так что Issues и Pull Requests приветствуются :)

Это — выжимка из главы про структуру типов и их VMT.

Структура объектов в памяти

До сих, говоря про разницу между значимыми и ссылочными типами, мы затрагивали эту тему с высоты конечного разработчика. Т.е. мы не смотрели на то как они в реальности устроены на уровне CLR, как сделаны те или иные механики внутри каждого из них. Мы смотрели фактически на конечный результат. Однако, чтобы понимать суть вещей глубже и чтобы отбросить в сторону последние оставшиеся мысли о какой-либо магии, происходящей внутри CLR стоит заглянуть в самые ее потроха.

Примечание

Глава, опубликованная на Хабре не обновляется и возможно, уже несколько устарела. А потому, прошу обратиться за более свежим текстом к оригиналу:

• CLR Book: GitHub, оглавление
• CLR Book: GitHub, глава
• Релиз 0.5.2 книги, PDF: GitHub Release