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

Всем привет. Возможно, вы помните меня по статьям об изменениях в C++ и о фреймворке 🐙 userver, поэтому сразу к делу. 27 июля я выступаю на конференции C++ Zero Cost Conf, которая пройдёт в Москве и Ереване. Там я поделюсь новостями со встречи Международного комитета по стандартизации языка в Сент-Луисе и расскажу о наших планах на C++26 и C++29. А ещё отвечу на ваши вопросы. Приходите в гости!

Помимо меня, вас также будут ждать: 

• Константин Владимиров, руководитель отдела компиляторов и средств разработки Syntacore. Покажет развитие архитектуры сложного LLVM-based-C++-проекта и конкретные задачи, возникающие при его развитии.

• Андрей Аксёнов, руководитель разработки инфраструктуры поиска Авито/Sphinx. Расскажет историю из продакшена с One Billion Row Challenge, парсингом гигабайтов TSV’шек, десятью странными оптимизациями и боттлнеками вообще везде.

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

• Константин Облаков, старший разработчик браузера Яндекс Поиска и Рекламных технологий. Покажет на практике, как GDB позволяет добиться результатов, недоступных другими методами.

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

Если не получится прийти лично, подключайтесь дистанционно.

Готов HTML и EPUB книги об учебной операционной системе xv6.

Яндекс.Диск:

• Книга об xv6 на русском языке в формате PDF

• Книга об xv6 на русском языке в формате EPUB

• Книга об xv6 на русском языке в формате HTML

Google.Drive: https://drive.google.com/drive/folders/1Rt7hcHysWAilDn64uf-RpLACuJ39YKaR

25.03.2024 года «Лаборатория программно‑аппаратных комплексов с искусственным интеллектом» при финансовой поддержке ООО «НИЦ ЦТ» организовала первый семинар, посвящённый системному программированию.

Докладчики: сотрудники МЦСТ Александр Ермолицкий, Мурад Нейман‑заде. Предварительная тема: «Обзор оптимизаций компилятора LCC».

Запись мероприятия доступна по этой ссылке.

Откуда берётся мусор?

Рассмотрим следующую программу:

#include <stdio.h>
int main () {
  int a [100];
  int i;
  for (i=0; i<100; i++)
    printf ("%d ", a[i]);
  return 0;
}

При компиляции без оптимизации и вызове в Linux она выдаст некоторые числа, являющиеся мусорным содержимым памяти. Кто-нибудь в состоянии объяснить, откуда конкретно они берутся, и почему каждый раз разные при последовательных запусках программы?

Казалось бы, если это просто содержимое адресов, на которые приходится соответствующая секция исполняемого модуля, то оно должно бы сохраняться от запуска к запуску?

Объяснение в стиле “потому что виртуальные адреса мапируются на реальные рандомно” я и сам могу дать, хочется более глубокого понимания. Компьютер – вещь детерминированная, в нём случайность – это не познанная закономерность.

Upd: ответ дан уважаемым @alexvangog в закреплённом комментарии.

Утечки памяти преследовали программы на языке С с тех пор, как существует этот язык. Было предложено множество решений, вплоть до идеи переписать программы на языке C на других языках. Но есть лучший способ.

Здесь представлено простое решение, которое устранит утечки памяти в каждой программе на языке C. Используйте этот модуль с вашей программой, и утечки памяти останутся в прошлом.

#include <dlfcn.h>
#include <stdio.h>

struct leaksaver {
        struct leaksaver *next;
        void *pointer;
} *bigbucket;

void *
malloc(size_t len)
{
        static void *(*nextmalloc)(size_t);
        nextmalloc = dlsym(RTLD_NEXT, "malloc");
        void *ptr = nextmalloc(len);
        if (ptr) {
                struct leaksaver *saver = nextmalloc(sizeof(*saver));
                saver->pointer = ptr;
                saver->next = bigbucket;
                bigbucket = saver;
        }
        return ptr;

Пояснение автора кода в оригинале:

Every allocated pointer is saved in the big bucket, where it remains accessible. Even if no other references to the pointer exist in the program, the pointer has not leaked.

It is now entirely optional to call free. If you don’t call free, memory usage will increase over time, but technically, it’s not a leak. As an optimization, you may choose to call free to reduce memory, but again, strictly optional.

Problem sovled!