saneex.c: try/catch/finally на базе setjmp/longjmp (C99) быстрее стандартных исключений C++¹

Квалификатор volatile

Решение проблемы «летучих переменных» — квалификатор volatile (дословно — «летучий»). Он заставляет компилятор всегда помещать переменную в стек, поэтому наш код будет работать, как ожидается, при любом уровне оптимизаций:

volatile int i;

Единственное изменение при -O1 будет в теле if:

; было:
  call    _rand
  mov     esi, eax
; стало:
  call    _rand
  mov     [rsp+E8h-DCh], eax
  mov     esi, [rsp+E8h-DCh]
; или можно переписать так:
  call    _rand
  mov     esi, eax
  mov     [rsp+E8h-DCh], eax

Как видим, компилятор продублировал присвоение в стек (сравните):

if (setjmp(jmp) == 0) {
  ESI = stack[i] = rand();

Случаи использования IRL

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

• Википедия предлагает использовать их для реализации корутин в Си (я бы не стал — как бы чего не вышло, хотя ldir такую технику тоже упоминал)
• на Хабре alexkalmuk писал про юнит-тесты в Эльбрусе на основе SJLJ (+ вторая статья), а dzeban — про профилирование в Linux
• также местные писали про быстрый интерпретатор (осторожно: очень сильное колдунство от Atakua), про обработку ошибок в x86emu (NWOcs) и в libpng (в libjpeg-turbo аналогично)
• в 2017 Skapix писал про pthreads, а kutelev — про прыжки из обработчиков сигналов
• тут пишут, что эта парочка использовалась в Symbian
• а в Quake World она использовалась совершенно точно — см. перевод археологических раскопок от PatientZero и, собственно, исходники (там есть и пара других мест)

Последний пример, на мой взгляд, наиболее хрестоматийный — это обработка ошибок и других состояний, когда нужно выйти «вот прямо сейчас», с любого уровня, при этом вставлять везде проверки на выход утомительно, а где-то и не возможно (библиотеки). Кстати, еще один пример был описан в проекте DrMefistO.

Конкретно в Quake World запускается бесконечный цикл в WinMain(), где каждая новая итерация устанавливает jmp_buf, а несколько функций могут в него прыгать, таким образом реализуя «глубокий continue»:

// WinQuake/host.c
jmp_buf         host_abortserver;

void Host_EndGame (char *message, ...)
{
  ...

  if (cls.demonum != -1)
    CL_NextDemo ();
  else
    CL_Disconnect ();

  longjmp (host_abortserver, 1);
}

void Host_Error (char *error, ...)
{
  ...

  if (cls.state == ca_dedicated)
    Sys_Error ("Host_Error: %s\n",string);  // dedicated servers exit

  CL_Disconnect ();
  cls.demonum = -1;

  inerror = false;

  longjmp (host_abortserver, 1);
}

void _Host_Frame (float time)
{
  static double           time1 = 0;
  static double           time2 = 0;
  static double           time3 = 0;
  int                     pass1, pass2, pass3;

  if (setjmp (host_abortserver) )
    return;                 // something bad happened, or the server disconnected

  ...
}

// QW/client/sys_win.c
int WINAPI WinMain (...)
{
  ...

  while (1)
  {
    ...
    newtime = Sys_DoubleTime ();
    time = newtime - oldtime;
    Host_Frame (time);
    oldtime = newtime;
  }

  /* return success of application */
  return TRUE;
}

Производительность

Один из доводов, который приводят против использования исключений — их отрицательное влияние на производительность. И действительно, в исходниках setjmp() в glibc видно, что сохраняются почти все регистры общего назначения ЦП. Тем не менее:

• само собой разумеется, что ни исключения в общем, ни SJLJ/saneex.c в частности и не предполагаются к применению во внутренностях числодробилок
• современные те-кхе…кхе-нологии (извиняюсь, электрон в горло попал) таковы, что сохранение лишнего десятка-другого регистров — это самая малая из проблем, которые они в себе несут
• если скорость критична, а исключений хочется — есть механизмы zero-cost exceptions (или, точнее, zero-cost try), которые радикально снижают нагрузку при входе в блок try, оставляя всю грязную работу на момент обработки (выброса) — а так как исключения это не goto и должны использоваться, гм, в исключительных ситуациях, то на производительности такой «перекос» сказывается, э-э, исключительно положительно

«Честные» zero-cost exceptions особенно полезны в том плане, что избавляют от более медленных volatile-переменных, которые иначе размещаются в стеке, а не в регистрах (именно поэтому они и не затираются longjmp()). Тем не менее, их поддержка это уже задача для компилятора и платформы:

• В Windows есть SEH и VEH, последний подвезли в XP.
• В gcc было несколько разных вариантов — вначале на основе SJLJ, потом DWARF, коего на сегодняшний день было пять версий (DWARF применяется и в clang). На эту тему см. отменные статьи zzeng: тыц и тыц, и сайт dwarfstd.org.
• В комментарии к другой статье камрад nuit дал наводку на интересный проект libunwind, но использовать его только ради исключений — это как стрелять из воробьев по пушкам (больно большой).

И, хотя saneex.c не претендует на пальму zero-cost (ее пальма — это переносимость), так ли уж страшен setjmp(), как его малюют? Может, это суеверие? Чтобы не быть голословными — померяем.

Тестовая среда

Я набросал два бенчмарка «на коленке», которые в main() в цикле 100 тысяч раз входят в блок try/catch и делают или не делают throw().

Исходник бенчмарка на C:

#include <stdio.h>
#include <time.h>
#include "saneex.h"

int main(void) {
  for (int i = 0; i < 100000; i++) {
    try {
      // либо ("выброс" = да):
      throw(msgex("A quick fox jumped over a red dog and a nyancat was spawned"));
      // либо ("выброс" = нет):
      time(NULL);
    } catchall {
      fprintf(stderr, "%s\n", curex().message);
    } endtry
  }
}

Исходник на С++ (я адаптировал пример с Википедии, вынеся объявление вектора за цикл и заменив cerr << на fprintf()):

#include <iostream>
#include <vector>
#include <stdexcept>
#include <time.h>

int main() {
  std::vector<int> vec{ 3, 4, 3, 1 };

  for (int i = 0; i < 100000; i++) {
    try {
      // либо ("выброс" = да):
      int i{ vec.at(4) };
      // либо ("выброс" = нет):
      time(NULL);
    }
    catch (std::out_of_range & e) {
      // << вместо fprintf() вызывает замедление цикла на 25-50%
      //std::cerr << "Accessing a non-existent element: " << e.what() << '\n';
      fprintf(stderr, "%s\n", e.what());
    }
    catch (std::exception & e) {
      //std::cerr << "Exception thrown: " << e.what() << '\n';
      fprintf(stderr, "%s\n", e.what());
    }
    catch (...) {
      //std::cerr << "Some fatal error\n";
      fprintf(stderr, "Some fatal error");
    }
  }

  return 0;
}

Тестировалось все на одной машине в двух ОС (обе 64-битные):

• Windows 10 2019 LTSC под PowerShell с помощью Measure-Command { test.exe 2>$null }
• последний Live CD Ubuntu с помощью встроенной time

Также я попробовал замерить исключения в Windows через расширения __try/__except, взяв другой пример с Википедии:

#include <windows.h>
#include <stdio.h>
#include <vector>

int filterExpression(EXCEPTION_POINTERS* ep) {
  ep->ContextRecord->Eip += 8;
  return EXCEPTION_EXECUTE_HANDLER;
}

int main() {
  static int zero;
  for (int i = 0; i < 100000; i++) {
    __try {
      zero = 1 / zero;
      __asm {
        nop
        nop
        nop
        nop
        nop
        nop
        nop
      }
      printf("Past the exception.\n");
    }
    __except (filterExpression(GetExceptionInformation())) {
      printf("Handler called.\n");
    }
  }
}

Однако вектор включить в цикл не вышло — компилятор сообщил, что:

error C2712: Cannot use __try in functions that require object unwinding

Так как накладываемые ограничения на код идут вразрез с принципом привычности, о котором я говорил в начале, я не внес эти результаты в таблицу ниже. Ориентировочно это 1100-1300 мс (Debug или Release, x86) — быстрее, чем стандартные исключения в VS, но все равно медленнее, чем они же в g++.

Результаты

№   Компилятор        Конфиг    Платф Механизм  Выброс  Время (мс)¹           saneex медленнее

1.  VS 2019 v16.0.0   Debug     x64   saneex.c  да      9713  / 8728  = 1.1   в 1.8 / 1.8
2.  VS 2019 v16.0.0   Debug     x64   saneex.c  нет     95    / 46    = 2     в 4.5 / 2.3
3.  VS 2019 v16.0.0   Debug     x64   C++       да      5449  / 4750² = 1.6
4.  VS 2019 v16.0.0   Debug     x64   C++       нет     21    / 20    = 1
5.  VS 2019 v16.0.0   Release   x64   saneex.c  да      8542³ / 182   = 47    в 1.8 / 0.4
6.  VS 2019 v16.0.0   Release   x64   saneex.c  нет     80³   / 23    = 3.5   в 8   / 1.8
7.  VS 2019 v16.0.0   Release   x64   C++       да      4669³ / 420   = 11
8.  VS 2019 v16.0.0   Release   x64   C++       нет     10³   / 13    = 0.8
9.  gcc 9.2.1         -O0       x64   saneex.c  да      71    / 351   = 0.2   в 0.2 / 0.6
10. gcc 9.2.1         -O0       x64   saneex.c  нет     6     / 39    = 0.2   в 1.5 / 1.1
11. g++ 9.2.1         -O0       x64   C++       да      378   / 630   = 0.6
12. g++ 9.2.1         -O0       x64   C++       нет     4     / 37    = 0.1
13. gcc 9.2.1         -O3       x64   saneex.c  да      66    / 360   = 0.2   в 0.2 / 0.6
14. gcc 9.2.1         -O3       x64   saneex.c  нет     5     / 23    = 0.2   в 1   / 0.6
15. g++ 9.2.1         -O3       x64   C++       да      356   / 605   = 0.6
16. g++ 9.2.1         -O3       x64   C++       нет     5     / 38    = 0.1

Результаты получились… интересные:

• Показатели сильно плавают на разных машинах и/или окружениях и особенно «чудит» VS. Чем это вызвано — непонятно.
• Использование cerr << вместо fprintf() в паре с выбросом исключения в VS в отладочной сборке ускоряет цикл в 3-4 раза (строка 3). ЧЯДНТ?
• Во всех случаях расходы на блок try в отсутствие throw — мизерные (4-28 мс на 100 тысяч итераций).
• Не считая «разогнанного» Debug в VS, выброс исключений в saneex.c быстрее, чем во встроенных языковых конструкциях (в 2.3 раза быстрее VS, в 5 раз быстрее gcc/g++), а try без throw — помедленнее, но речь идет о единицах миллисекунд. Вот это поворот!

Что тут можно сказать… Есть о чем похоливарить. Добро пожаловать в комментарии!

Для меня самый важный use-case — это много блоков try с крайне редкими throw («лови много, бросай мало»), а он зависит практически только от скорости setjmp(), причем производительность последнего, судя по таблице, далеко не так плоха, как часто думают. Косвенно это подтверждается и вот этой статьей, где автор после замеров делает вывод, что один вызов setjmp() равен двум вызовам пустых функций в OpenBSD и полутора (1.45) — в Solaris. Причем эта статья от 2005 года. Единственное «но» — сохранять нужно без сигнальной маски, но она обычно и не интересна.

Ну, а напоследок…

Виновник торжества — saneex.c

Библиотека, чей пример был на КДПВ:

• может компилироваться даже в Visual Studio
• поддерживает любую вложенность блоков, throw() из любого места, finally и несколько catch на блок (по коду исключения)
• не выделяет память и не использует указатели (все в static)
• опционально-многопоточная (__thread/_Thread_local)
• в public domain (CC0)

Интересующиеся могут найти ее исходники на GitHub. Ниже я кратко на одном примере покажу, как ей пользоваться и какие есть подводные камни. Код примера из saneex-demo.c в репозитории:

01.    #include <stdio.h>
02.    #include "saneex.h"
03.
04.    int main(void) {
05.      sxTag = "SaneC's Exceptions Demo";
06.
07.      try {
08.        printf("Enter a message to fail with: [] [1] [2] [!] ");
09.
10.        char msg[50];
11.        thrif(!fgets(msg, sizeof(msg), stdin), "fgets() error");
12.
13.        int i = strlen(msg) - 1;
14.        while (i >= 0 && msg[i] <= ' ') { msg[i--] = 0; }
15.
16.        if (msg[0]) {
17.          errno = atoi(msg);
18.          struct SxTraceEntry e = newex();
19.          e = sxprintf(e, "Your message: %s", msg);
20.          e.uncatchable = msg[0] == '!';
21.          throw(e);
22.        }
23.
24.        puts("End of try body");
25.
26.      } catch (1) {
27.        puts("Caught in catch (1)");
28.        sxPrintTrace();
29.
30.      } catch (2) {
31.        puts("Caught in catch (2)");
32.        errno = 123;
33.        rethrow(msgex("calling rethrow() with code 123"));
34.
35.      } catchall {
36.        printf("Caught in catchall, message is: %s\n", curex().message);
37.
38.      } finally {
39.        puts("Now in finally");
40.
41.      } endtry
42.
43.      puts("End of main()");
44.    }

Программа выше читает сообщение, бросает исключение и обрабатывает его в зависимости от пользовательского ввода:

• если ничего не ввести — исключение выброшено не будет, и мы увидим:

End of try body
Now in finally
End of main()

• если ввести текст, начинающийся с единицы, то будет создано исключение с этим кодом (1), оно будет поймано в первом блоке catch (1) (26.), а на экране появится:

Caught in catch (1)
Your message: 1 hello, habr!
    ...at saneex-demo.c:18, code 1
Now in finally
End of main()

• если ввести двойку, то исключение будет поймано (30.), выброшено новое (со своим кодом, текстом и прочим) с сохранением предыдущей информации в цепочке (33.), дойдет до внешнего обработчика и программа завершится:

Caught in catch (2)
Now in finally

Uncaught exception (code 123) - terminating. Tag: SaneC's Exceptions Demo
Your message: 2 TM! kak tam blok4ain?
    ...at saneex-demo.c:18, code 2
calling rethrow() with code 123
    ...at saneex-demo.c:33, code 123
rethrown by ENDTRY
    ...at saneex-demo.c:41, code 123

• если ввести !, то исключение получится «неуловимым» (uncatchable; 20.) — оно пройдет сквозь все блоки try выше по стеку, вызывая их обработчики (как catch, так и finally), пока не дойдет до внешнего и не завершит процесс — гуманный аналог abort():

Caught in catch (1)
Your message: ! it is a good day to die
    ...UNCATCHABLE at saneex-demo.c:18, code 0
Now in finally

Uncaught exception (code 0) - terminating. Tag: SaneC's Exceptions Demo
Your message: ! it is a good day to die
    ...UNCATCHABLE at saneex-demo.c:18, code 0
UNCATCHABLE rethrown by ENDTRY
    ...at saneex-demo.c:41, code 0

• наконец, если ввести тройку, то исключение попадет в catchall (35.), где просто будет выведено его сообщение:

Caught in catchall, message is: Your message: 3 we need more gold
Now in finally
End of main()

Остальные «фичи»

Потокобезопасность. По умолчанию ее нет, но если у вас нормальный компилятор (не MSVC¹), то C11 спасет отца народов за счет помещения важных переменных в локальную область потока (TLS):

#define SX_THREAD_LOCAL _Thread_local

¹ Последние годы у Microsoft имеются какие-то подвижки на почве open source, но всем по дело идет медленно, хотя и лучше, чем 8 лет назад, так что мы пока держимся.

sxTag (05.) — строка, которая выводится вместе с непойманным исключением в stderr. По умолчанию — дата и время компиляции (__DATE__ __TIME__).

Создание SxTraceEntry (записи в stack trace). Есть несколько полезных макросов — оберток над (struct SxTraceEntry) {...}:

• newex() — этот был в примере; присваивает __FILE__, __LINE__ и код ошибки = errno (что удобно после проверки результата вызова системной функции, как в примере после fgets(); 11.)
  
  • код меньше 1 становится 1 (ибо setjmp() возвращает 0 только при первом вызове), поэтому catch (0) никогда не сработает
• msgex(m) — как newex(), но также устанавливает текст ошибки (константное выражение)
• exex(m, e) — как msgex(), но также прицепляет к исключению произвольный указатель; его память будет освобождена через free() автоматически:

try {
  TimeoutException *e = malloc(sizeof(*e));
  e->elapsed = timeElapsed;
  e->limit = MAX_TIMEOUT;
  errno = 146;
  throw(exex("Connection timed out", e));
} catch (146) {
  printf("%s after %d\n", curex().message,
    // читаем через void *SxTraceEntry.extra:
    ((TimeoutException *) curex().extra)->elapsed);
} endtry

И, конечно, есть мои любимые designated initializers из все того же C99 (работают в Visual Studio 2013+):

throw( (struct SxTraceEntry) {.message = "kaboom!"} );

Выброс исключения:

• throw(e) — бросает готовый SxTraceEntry
• rethrow(e) — аналогично throw(), но не очищает текущий stack trace; может использоваться только внутри catch/catchall
• thrif(x, m) — макрос; при if (x) создает SxTraceEntry с текстом x + m и «выбрасывает» его
• thri(x) — как thrif(), только с пустым m

Макросы нужны для удобного «преобразования» результата типичного библиотечного вызова в исключение — как в примере с fgets() (11.), если функция не смогла прочитать ничего. Конкретно с fgets() это не обязательно обозначает ошибку (это может быть просто EOF: ./a.out </dev/null), но других подходящих функций в том примере не используется. Вот более жизненный:

thri(read(0xBaaD, buf, nbyte));
// errno = 9, "Bad file descriptor"
// Assertion error: read(0xBaaD, buf, nbyte);

…И «особенности реализации»

Их всего две с половиной (но зато какие!):

• блок обязан заканчиваться на endtry — здесь происходит завершение процесса при отсутствии обработчика (блока try) выше по стеку
  
  • эту ошибку компилятор, скорее всего, поймает, ибо try открывает три {, а endtry их закрывает
• нельзя делать return между try и endtry — это самый жирный минус, но моя фантазия не нашла способов отловить эту ситуацию; принимаются идеи и PR
  
  • естественно, goto внутрь и наружу тоже под запретом, но разве его кто-то использует? </sarcasm>

Что касается «половины», то это уже разобранный ранее volatile. «Прием» исключения — это повторный вход в середину функции (см. longjmp()), поэтому, если значение переменной было изменено внутри тела try, то такая переменная не должна использоваться в catch/catchall/finally и после endtry, если она не объявлена как volatile. Компилятор заботливо предупредит о такой проблеме. Вот наглядный пример:

int foo = 1;
try {
  foo = 2;
  // здесь можно использовать foo
} catchall {
  // а здесь уже нет!
} finally {
  // и здесь тоже!
} endtry
// и здесь нельзя!

С volatile переменную можно использовать где угодно:

volatile int foo = 1;
try {
  ...

Итог: как это работает

У каждого потока есть два статически-выделенных (глобальных) массива:

• struct SxTryContext — информация о блоках try, внутри которых мы сейчас находимся — в частности, jmp_buf на каждый из них; например, здесь их два:

try {
  try {
    // мы здесь
  } endtry
} endtry

• struct SxTraceEntry — текущий stack trace, то есть объекты, переданные кодом снаружи для идентификации исключений; их может быть больше или меньше, чем блоков try:

try {         // один SxTryContext
  try {       // два SxTryContext
              // ноль SxTraceEntry
    throw(msgex("Первый пошел!"));
              // один SxTraceEntry
  } catchall {
              // один SxTraceEntry
    rethrow(msgex("Второй к бою готов!"));
              // два SxTraceEntry (*)
  } endtry
} endtry

Если в коде выше вместо rethrow() использовать throw(), то объектов SxTraceEntry (*) будет не два, а один — предыдущей будет удален (stack trace будет очищен). Кроме того, можно вручную добавить элемент в цепочку через sxAddTraceEntry(e).

try и другие элементы конструкции суть макросы (— ваш К. О.). Скобки { } после них не обязательны. В итоге, все это сводится к следующему псевдокоду:

try {                             int _sxLastJumpCode = setjmp(add_context()¹);
                                  bool handled = false;
                                  if (_sxLastJumpCode == 0) {
  throw(msgex("Mama mia!"));        clearTrace();
                                    sxAddTraceEntry(msgex(...));
                                    if (count_contexts() == 0) {
                                      fprintf(stderr, "Shurik, vsё propalo!");
                                      sxPrintTrace();
                                      exit(curex().code);
                                    } else {
                                      longjmp(top_context());
                                    }
} catch (9000) {                  } else if (_sxLastJumpCode == 9000) {
                                    handled = true;
} catchall {                      } else {
                                    handled = true;
} finally {                       }
                                  // здесь действия в finally { }
} endtry                          remove_context();
                                  if (!handled) {
                                    // как выше с throw()
                                  }

¹ Имена с _ в библиотеке не используются, это абстракции.

Думаю, после подробных объяснений, как работает SJLJ, что-то еще здесь комментировать излишне, а потому позвольте откланяться и предоставить слово уже вам.