company_banner
  • На спор: прочитав до конца, вы поймёте, как и почему именно так работает GC

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


      Другой вопрос, что мне субъективно не очень нравится, как объясняется его работа. Потому, предлагаю альтернативный подход, описанный в моей книге, .NET Platform Architecture.


      Если мы с вами будем досконально разбираться, почему были выбраны именно эти два алгоритма управления памятью: Sweep и Compact, нам для этого придётся рассматривать десятки алгоритмов управления памятью, которые существуют в мире: начиная обычными словарями, заканчивая очень сложными lock-free структурами. Вместо этого, оставив голову мыслям о полезном, мы просто обоснуем выбор и тем самым поймём, почему выбор был сделан именно таким. Мы более не смотрим в рекламный буклет ракеты-носителя: у нас на руках полный набор документации.


      Спор взаимовыгоден: если будет не понятно, я подправлю не ясные моменты в книге, маленькой частью которой является данный текст.


      Читать дальше →
    • Инструментарий для анализа и отладки .NET приложений

      • Перевод

      Заглянуть «под капот» кода или посмотреть на внутреннее устройство CLR можно с помощью множества инструментов. Этот пост родился из твита, и я должен поблагодарить всех, кто помог составить список подходящих инструментов. Если я пропустил какие-то из них, напишите в комментариях.


      Во-первых, я должен упомянуть, что хороший отладчик уже присутствует в Visual Studio и VSCode. Также существует множество хороших (коммерческих) профилировщиков .NET и инструментов мониторинга приложений, на которые стоит взглянуть. Например, недавно я попробовал поработать с Codetrack и был впечатлён его возможностями.


      Однако оставшийся пост посвящён инструментам для выполнения отдельных задач, которые позволят лучше понять, что происходит. Все инструменты имеют открытый исходный код.


      Читать дальше →
      • +41
      • 8,4k
      • 9
    • ConfigureAwait, кто виноват и что делать?

        В своей практике я часто встречаю, в различном окружении, код вроде того, что приведен ниже:


        [1] var x = FooWithResultAsync(/*...*/).Result;
        
        //или
        [2] FooAsync(/*...*/).Wait();
        
        //или
        [3] FooAsync(/*...*/).GetAwaiter().GetResult();
        
        //или
        [4] FooAsync(/*...*/)
            .ConfigureAwait(false)
            .GetAwaiter()
            .GetResult();
        
        //или
        [5] await FooAsync(/*...*/).ConfigureAwait(false)
        
        //или просто
        [6] await FooAsync(/*...*/)

        Из общения с авторами таких строк, стало ясно, что все они делятся на три группы:


        • Первая группа, это те, кому ничего не известно о возможных проблемах с вызовом Result/Wait/GetResult. Примеры (1-3) и, иногда, (6), типичны для программистов из этой группы;
        • Ко второй группе относятся программисты, которым известно о возможных проблемах, но они не знают причин их возникновения. Разработчики из этой группы, с одной стороны, стараются избегать строк вроде (1-3 и 6), но, с другой, злоупотребляют кодом вроде (4-5);
        • Третья группа, по моему опыту самая малочисленная, это те программисты, которые знают о том, как код (1-6) работает, и, поэтому, могут сделать осознанный выбор.

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


        Читать дальше →
      • Асинхронные Stream в C# 8

        • Перевод
        • Tutorial

        Функционал Async/Await появился в C# 5, чтобы улучшить скорость отклика пользовательского интерфейса и веб-доступ к ресурсам. Другими словами, асинхронные методы помогают разработчикам выполнять асинхронные операции, которые не блокируют потоки и возвращают один скалярный результат. После многочисленных попыток Microsoft упростить асинхронные операции, шаблон async/await завоевал хорошую репутацию среди разработчиков благодаря простому подходу.


        Существующие асинхронные методы значительно ограничены тем, что должны возвращать только одно значение. Давайте рассмотрим некий обычный для такого синтаксиса метод async Task<int> DoAnythingAsync(). Результатом его работы является некоторое одно значение. Из-за такого ограничения нельзя использовать эту функцию с ключевым словом yield и асинхронным интерфейсом IEnumerable<int> (чтобы вернуть результат асинхронного перечисления).


        Читать дальше →
      • CLRium #6: Concurrency & Parallelism. Два дня: от процессора до async/await




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


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


          Читать дальше →
        • Оптимизация программ под Garbage Collector

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


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


            Читать дальше →
            • +40
            • 7,3k
            • 4
          • CLRium #5 Garbage Collector: Питер — Sold Out

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


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


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


              Читать дальше →
              • +20
              • 1,5k
              • 4
            • Disposable ref structs в C# 8.0

              • Перевод

              Давайте посмотрим, что об этом сказано в блоге о предстоящих изменениях в С# 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()
                 {
                 }
              }

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

              Читать дальше →
            • CLRium #5: Garbage Collector. Крупнейший семинар по .NET

                Наш семинар уверенно набирает слушателей и постепенно перерастает офис компании 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 апреля — в Москве, а все подробности — под катом

                Читать дальше →
                • +29
                • 3,3k
                • 3
              • Как глубока кроличья нора? CLRium #5: Garbage Collector

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


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


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



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

                  Читать дальше →
                  • +23
                  • 4,5k
                  • 4
                • Не надо думать о памяти, говорили они… Семинар CLRium #5: Garbage Collector

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

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

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


                    Читать дальше →
                    • +22
                    • 4,5k
                    • 2
                  • CLRium #5: Всё-всё-всё о GC и не только. Питер и Москва


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


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


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


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

                      Читать дальше →
                    • Встреча .NET сообщества на CLRium #4 + онлайн

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


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


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



                        cool Примеры статей и полный список тем выступлений — под катом
                        Читать дальше →
                      • Встреча .Net сообщества на CLRium #4 + онлайн. Куда движутся CoreCLR и C#. Приглашаются все

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


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


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


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



                          cool Примеры статей и полный список тем выступлений — под катом
                          Читать дальше →
                          • +26
                          • 5,5k
                          • 8
                        • CLRium #4: Встреча .NET сообщества


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

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


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


                            • 19 октября в Санкт-Петербурге + online, в офисе компании Epam Systems
                            • 26 октября в Москве
                            Читать дальше →
                            • +17
                            • 2,7k
                            • 2
                          • CLRium #4: Встреча .Net сообщества




                              Темы: 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 октября в Москве
                              Читать дальше →
                              • +11
                              • 3,3k
                              • 2
                            • [DotNetBook] Время занимательных историй: исключительно исключительные ситуации

                              • Tutorial

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


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


                              ThreadAbortException


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


                              Примечание


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


                              Читать дальше →
                            • [DotNetBook] События об исключительных ситуациях и как на пустом месте получить StackOverflow и ExecutionEngineException

                              • Tutorial

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


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


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

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


                              Примечание


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


                              Читать дальше →
                              • +30
                              • 4,1k
                              • 3
                            • [DotNetBook] Span, Memory и ReadOnlyMemory

                              • Tutorial

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


                              Memory<T> и ReadOnlyMemory<T>


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


                              Примечание


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


                              Читать дальше →
                              • +38
                              • 7,5k
                              • 2
                            • [DotNetBook] Исключения: архитектура системы типов

                              • Tutorial

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


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


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


                              Примечание


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


                              Читать дальше →

                            Самое читаемое