Системное программирование *

Многие из нас ходят на конференции по Java только из-за хардкора. Это статья о том, что в этом плане изменилось за год.

Хардкор бывает нескольких видов. Можно выделить как минимум:

• перформансные оптимизации в любых проявлениях;
• внутренности достаточно сложных технологий (OpenJDK, GraalVM);
• компиляторы и рантаймы в целом;
• дизайн языков программирования;
• проблемы computer science и прикладной математики;
• и многое другое.

В чем разница между обычным докладом и хардкорным? Это как разница между статьей по квантовой гравитации и руководством по вкусной и здоровой пище. Правильно приготовить Spring — это, безусловно, очень сложная и интересная задача, которая для многих из нас является большой частью повседневных задач, и, соответственно, доклады Жени Борисова имеют большое практическое значение. Грубо говоря, это способ стать более хорошим специалистом и поднять больше денег. Но блеск далёких звезд находится не там.

Поэтому — только хардкор по заветам старой школы. Под катом небольшая заметка о том, как все это выглядит с точки зрения человека, который помешан на чтении статей, посещении докладов и отсмотру роликов на Ютубе, посвященных Java в широком смысле слова.

Добрый день!

Embox недавно принимал участие в IT-фестивале TechTrain.

Поток посетителей у нашего стенда был очень большим! А мы, к сожалению, не сделали раздаточные материалы с описанием нашего проекта. И некоторые ушли, не успев понять, что же у нас происходит. Нам задавали много однотипных вопросов, и мы решили опубликовать небольшую статью для того, чтобы на них ответить.

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

Данная статья в большей мере рассчитана на новичков в системном программировании и тех, кто просто хочет узнать немного больше о том, как работают процессы в Linux.

Команда разработчиков Rust рада сообщить о выпуске новой версии Rust: 1.29.0. Rust — это системный язык программирования, нацеленный на безопасность, скорость и параллельное выполнение кода.

Если у вас установлена предыдущая версия Rust с помощью Rustup, то для обновления Rust до версии 1.29.0 вам достаточно выполнить:

$ rustup update stable

Если у вас еще не установлен Rustup, вы можете установить его с соответствующей страницы нашего веб-сайта. С подробными примечаниями к выпуску Rust 1.29.0 можно ознакомиться на GitHub.

Что вошло в стабильную версию 1.29.0

1.29 привносит не очень много изменений. Ожидается что Rust 1.30 и 1.31 будут очень значительными, так что большая часть 1.29 итерации ушла на подготовку к будущим изменениям. Два самых заметных нововведения этого выпуска даже не касаются самого языка: это две новые возможности Cargo и обе они касаются предупреждений.

• cargo fix автоматически исправляет предупреждения в коде
• cargo clippy — статический анализатор Rust кода, помогающий поймать распространенные ошибки и просто улучшить код

cargo fix

С выпуском Rust 1.29 у Cargo появляется новая подкоманда: cargo fix. Если вы когда-либо писали на Rust, то скорее всего уже сталкивались с предупреждениями компилятора. Например, рассмотрим такой код:

fn do_something() {}

fn main() {
    for i in 0..100 {
        do_something();
    }
}

В нем мы вызываем do_something сто раз, но никогда не используем переменную i. Rust предупреждает нас об этом:

Язык C очень мощный и много где используется — особенно в ядре Linux — но при этом очень опасный. Один из разработчиков ядра Linux рассказал, как справиться с уязвимостями безопасности С.

Вы можете сделать практически любую вещь на С, но это не значит, что её нужно делать. Код C очень быстр, но несётся без ремней безопасности. Даже если вы эксперт, как большинство разработчиков ядра Linux, всё равно возможны убийственные ошибки.

Кроме подводных камней типа псевдонимов указателей, у языка C фундаментальные неисправленные ошибки, которые ждут своих жертв. Именно эти уязвимости Кейс Кук, инженер по безопасности ядра Google Linux, рассмотрел на конференции по безопасности Linux в Ванкувере.

Многие Go программисты знакомы с bytes.Buffer. Одно из его преимуществ состоит в том, что он позволяет избегать выделений памяти в куче по той же схеме, что и "оптимизация коротких строк" (small buffer/size optimization):

type Buffer struct {
    bootstrap [64]byte // для избежания аллокации малых слайсов в куче
    // ... другие поля
}

Есть только одна проблема. Эта оптимизация не работает.

К концу этой статьи вы узнаете, почему эта оптимизация не работает и что мы можем с этим сделать.

Добрый день! Сегодня я хочу рассказать вам как написать минимальную программу, которая запустится на ARM Cortex-M3 и при этом напечатает “Hello, World!”. Постараемся разобрать по шагам необходимый минимум, который нам для этого потребуется. Запускать будем на эмуляторе QEMU. Поэтому любой желающий может воспроизвести, даже если у него нет под рукой железки.

Итак, поехали!

На хабре уже есть новость об этой уязвимости, но, к сожалению, без технических деталей. Предлагаю заглянуть внутрь опубликованного архива (автор — SandboxEscaper).

Под катом расположен перевод документа-описания, находящегося в архиве.

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

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

Приступим.

В прошлой статье я обещал подробнее раскрыть некоторые детали, которые опустил во время расследования [подвисаний Gmail в Chrome под Windows — прим. пер.], включая таблицы страниц, блокировки, WMI и ошибку vmmap. Сейчас восполняю эти пробелы вместе с обновлёнными примерами кода. Но сначала вкратце изложим суть.

Речь шла о том, что процесс с поддержкой Control Flow Guard (CFG) выделяет исполняемую память, одновременно выделяя память CFG, которую Windows никогда не освобождает. Поэтому если вы продолжаете выделять и освобождать исполняемую память по разным адресам, то процесс накапливает произвольный объём памяти CFG. Браузер Chrome делает это, что приводит к практически неограниченной утечке памяти и подвисаниям на некоторых машинах.

Нужно заметить, что подвисаний трудно избежать, если VirtualAlloc начинает работать более чем в миллион раз медленнее, чем обычно.

Я не искал неприятностей. Не запускал процесс сборки Chrome тысячу раз за выходные, а только занимался самыми обычными задачами 21-го века — просто писал электронное письмо в 10:30 утра. И вдруг Gmail подвис. Я продолжал печатать несколько секунд, но на экране не появлялось никаких символов. Затем внезапно Gmail отвис — и я вернулся к своему очень важному письму. Но впоследствии всё повторилось, только на этот раз Gmail ещё дольше не отвечал запросы. Это странно…

Трудно устоять перед возможностью провести хорошее расследование, но в данном случае вызов особенно силён. Ведь я в Google работаю над улучшением производительности Chrome для Windows. Обнаружить причину зависания — моя работа. И после множества фальстартов и тяжёлых усилий мне всё-таки удалось выяснить, как Chrome, Gmail, Windows и наш IT-отдел вместе помешали мне набрать электронное письмо. По ходу дела нашёлся способ сэкономить значительное количество памяти для некоторых веб-страниц в Chrome.

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

Прошел год с тех пор, как удалась предыдущая выходка: опубликовать вместо поста ролик на YouTube. «Стыдный разговор о синглтонах» набрал 7к просмотров на YouTube и вдвое больше на самом Хабре в текстовой версии. Для статьи, написанной в совершенно упоротом состоянии и рассказывающей о древнейшем баяне — это что-то вроде успеха.

Сегодня я всю ночь монтировал новый выпуск. На этот раз тема куда более свежая: история коммита в экспериментальную технологию — SubstrateVM. А вот градус упоротости поднялся на новый уровень.



Очень жду ваших комментариев! Напоминаю, что если вы хотите действительно что-то улучшить в этом посте, то лучше всего зафайлить ишшую на Github. Хотел бы сказать «ставьте лайки и подписывайтесь на новый канал, но ведь все его выпуски и так будут у вас в хабе Java?

Технически: в видео есть одна склейка ближе к концу. Просто я писал несжатое видео, и мой m2 ssd размером всего в пятьсот гигабайт быстро переполнился. А ни один другой жесткий диск не смог выдержать такого напора данных. Поэтому пришлось отключиться на полчаса и изголившись найти дополнительные пятьдесят гигов на запись последних нескольких минут. Это было достигнуто удалением файлов собранного GoogleChrome. Мнение о записывающем софте отписал в ФБ прямо в момент записи, там очень много боли.

Ещё из технически интересного: YouTube почему-то заблокировало мне live streaming. При этом на аккаунте нет ни единого страйка и клейма. Будем надеяться, что это просто косяк, и через 90 дней всё вернут назад.

OMNeT++ (Objective Modular Network Testbed in C++) Discrete Event Simulator – это модульная, компонентно‑ориентированная C++ библиотека и фреймворк для дискретно‑событийного моделирования, используемая прежде всего для создания симуляторов сетей. Попросту говоря это “симулятор дискретных событий”, включающий: IDE для создания моделей, и сам симулятор (GUI).

INET Framework – “библиотека” сетевых моделей для OMNeT++.

Полная версия GIF (15.7 MiB)

В предыдущих частях…

0. Автоматическое определение топологии сети и неуправляемые коммутаторы. Миссия невыполнима? (+ classic Habrahabr UserCSS)

В этой части:

• создадим “свой первый” протокол (на примере LLTR Basic);
• выберем подходящий симулятор сити для отладки протокола (и создания его модели);
• познаем тонкости настройки окружения для симулятора и его IDE (конфигурирование, компиляция, линковка, тюнинг, патчинг, игнорирование устаревшей документации; и другие англицизмы в большом количестве);
• столкнемся со всем, с чем можно столкнуться, при создании своей первой модели своего первого протокола в не своем незнакомом симуляторе сети;
• пройдем весь путь вместе:
  • от счастья, принесенного успешной (наконец!) компиляции первого проекта с пустой сетью,
  • до полного погружения в эксперименты с функционирующей моделью протокола;
• tutorial, все описано в виде tutorial – мы будем учиться на ошибках – будем совершать их, и будем понимать их (природу), дабы элегантно/эффективно с ними справится;
• репозиторий (git ), в коммитах и тегах которого сохранены все шаги (“Add …”, “Fix …”, “Fix …”, “Modify …”, “Correct …”, …), от начала и до конца.

Note: дополнительная информация для читателей хаба “Mesh-сети”.

{ объем изображений: 2.2+(2.1) MiB; текста: 484 KiB; смайликов: 22 шт. }

В компании нашу команду по противостоянию DDoS-атакам называют «отбрасыватели пакетов» (the packet droppers — прим. пер). Пока все остальные команды делают клёвые штуки с проходящим через нашу сеть трафиком, мы развлекаемся поиском новых способом избавиться от него.


Фотография: Brian Evans, CC BY-SA 2.0

Умение быстро отбрасывать пакеты очень важно в противостоянии DDoS-атакам.

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

Команда разработчиков Rust рада сообщить о выпуске новой версии Rust: 1.28.0. Rust — это системный язык программирования, нацеленный на безопасность, скорость и параллельное выполнение кода.

Если у вас установлена предыдущая версия Rust с помощью rustup, то для обновления Rust до версии 1.28.0 вам достаточно выполнить:

$ rustup update stable

Если у вас еще не установлен rustup, вы можете установить его с соответствующей страницы нашего веб-сайта. С подробными примечаниями к выпуску Rust 1.28.0 можно ознакомиться на GitHub.

Что вошло в стабильную версию 1.28.0

Глобальные аллокаторы

С помощью аллокаторов программы на Rust получают память во время выполнения. Раньше Rust не позволял изменять способ распределения памяти, что ограничивало его использование в некоторых случаях.

Недавний пост о том как мы в Сбербанк-Технологиях разрабатываем Open Source раскрыл множество интересных подробностей о подходах, стремлениях и идеологии.

Сегодня я хочу рассказать о том реальном вкладе, который наша команда вносит в Open Source.

В данной статье я хочу рассмотреть практические аспекты создания простого гипервизора на основе технологии аппаратной виртуализации Intel VMX.

Аппаратная виртуализация достаточно узкоспециализированная область системного программирования и не имеет большого комьюнити, в России уж точно. Я надеюсь, что материал статьи поможет тем, кто захочет открыть для себя аппаратную виртуализацию и те возможности которые она предоставляет. Как было сказано в начале, я хочу рассмотреть именно практический аспект без погружения в теорию, поэтому предполагается что читатель знаком с архитектурой x86-64 и имеет хотя бы общее представление о механизмах VMX. Исходники к статье.

Начнем с постановки задач для гипервизора:

Файловая система proc (в дальнейшем просто procfs) является виртуальной файловой системой, которая предоставляет информацию о процессах. Она — “прекрасный” пример интерфейсов следующих парадигме “все является файлом”. Procfs была разработана очень давно: во времена, когда серверы в среднем обслуживали несколько десятков процессов, когда открыть файл и вычитать информацию о процессе не было проблемой. Однако время не стоит на месте, и сейчас серверы обслуживают сотни тысяч, а то и больше процессов одновременно. В таком контексте идея “открыть файл для каждого процесса, чтобы вычитать интересующие данные” уже не выглядит такой привлекательной, и первое что приходит на ум чтобы ускорить чтение — это получение информации о группе процессов за одну итерацию. В этой статье мы попробуем найти элементы procfs которые можно оптимизировать.

Привет, Хабр! В этой серии мы продолжаем усиленно дружить драйвер WinBtrfs с ReactOS.


А этот ваш Windows так умеет?

Фьютекс (futex — сокращение от «Fast userspace mutex») — это механизм, предложенный разработчиками Linux из IBM в 2002 году и вошедший в ядро в конце 2003 года. Основной идеей было предоставить более эффективный способ синхронизации пользовательских потоков с минимальным количеством обращений к ядру ОС.

В этой статье мы сделаем обзор фьютексов, попытаемся понять принципы их работы, а также используем их в качестве кирпичиков для построения более высокоуровневых (и знакомых нам) объектов синхронизации.

Важный момент: фьютексы — это достаточно низкоуровневый инструмент, напрямую его использовать стоит лишь при разработке фундаментальных библиотек, вроде стандартной библиотеки C/C++. Очень маловероятно, что вам понадобится использовать фьютексы в обычном прикладном приложении.