Рубрика «clrium»

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

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

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

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

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

Читать полностью »

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

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

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

Инструментарий для анализа и отладки .NET приложений - 1

Читать полностью »

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

[1] var x = FooWithResultAsync(/*...*/).Result;

//или
[2] FooAsync(/*...*/).Wait();

//или
[3] FooAsync(/*...*/).GetAwaiter().GetResult();

//или
[4] FooAsync(/*...*/)
    .ConfigureAwait(false)
    .GetAwaiter()
    .GetResult();

//или
[5] await FooAsync(/*...*/).ConfigureAwait(false)

//или просто
[6] awiat FooAsync(/*...*/)

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

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

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

ConfigureAwait, кто виноват и что делать? - 1

Читать полностью »

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

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

Асинхронные Stream в C# 8 - 1

Читать полностью »

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

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

Читать полностью »

13 апреля в Санкт-Петербурге (оффлайн и онлайн) и 20 апреля — в Москве (только оффлайн) пройдет самый крупный семинар CLRium#5 за всё время его существования. До Sold-Out Питера осталось всего лишь 30 мест! А видеозаписи получат владельцы всех типов билетов.

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

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

CLRium #5 Garbage Collector: полное погружение в омут памяти - 1

Читать полностью »

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

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

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

Как глубока кроличья нора? CLRium #5: Garbage Collector - 1

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

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

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

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

Не надо думать о памяти, говорили они… Семинар CLRium #5: Garbage Collector - 1
Читать полностью »

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

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

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

Встреча .NET сообщества на CLRium #4 + онлайн - 2

cool Примеры статей и полный список тем выступлений — под катомЧитать полностью »

Встреча .Net сообщества на CLRium #4 + онлайн. Куда движутся CoreCLR и C#. Приглашаются все - 1Я не люблю заезженное слово «конференция». Это — встреча разработчиков с общими интересами, которые хотят послушать о будущем своей любимой платформы, а также о трюках, которые позволяют обходить правила, установленные в .NET Framework. Формат встречи — это десять слотов, которые заполнены только выжимкой самого современного, иногда даже еще не вышедшего функционала. Это как раз тот самый формат, когда нет необходимости забивать сетку докладами, которые не имеют никакого отношения к теме конференции. Наборот: идет плотная работа над отсевом не перспективных не относящихся к нашей платформе тем.

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

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

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

Встреча .Net сообщества на CLRium #4 + онлайн. Куда движутся CoreCLR и C#. Приглашаются все - 2

cool Примеры статей и полный список тем выступлений — под катомЧитать полностью »