Оптимизация памяти в JavaScript при проверке индексов массивов

Добавив в benchmark, в качестве которого служит сам транслятор, исполнение версий на Java и JavaScript, обнаружил, что для последнего при включённых проверках индексов массивов происходит ~ 8-кратный перерасход памяти по сравнению с выключенными проверками, что было незаметно на небольших программах. Расход памяти, в свою очередь, приводит и к ощутимо большему времени исполнения, чего, опять-таки, не было в простых тестах.

Перерасход был вызван, в основном, тем, что методы доступа к элементам массива находились в самом массиве, что было сделано в расчёте на потенциально высокую возможность оптимизации при JIT-исполнении и без учёта влияния на занимаемую память. Замеры показали всё, как есть - и неоправдавшиеся надежды на оптимизации, и ужасы накладных расходов на сборку мусора.

Оптимальным по всем параметрам решением оказалось добавление методов доступа непосредственно классу Array вместо создания дополнительных обёрток.

Дополнительно в JavaScript была устранена генерация проверок индекса для простых случаев, когда статически известно о гарантиях корректного обращения к массиву. Также, была усовершенствована пометка переменных, которые участвуют в вызовах подпрограмм в качестве VAR-параметров, что в Java и JavaScript имитируется через массивы. Это позволило устранить превращение в массивы переменных в вызовах NEW, PACK, UNPK.

Версия 0.0.5

Выпущено обновление транслятора и библиотеки.

• Исправлена возможность отключения проверки индекса массива для JavaScript.
• Улучшена генерация C, уменьшающая количество предупреждений, выдаваемых трансляторами С, и устранено обращение к первому члену структуры через нулевой указатель для получения адреса, что с некоторых пор и в gcc трактуется как неопределённое поведение.
• Исправлен вывод русских сообщений в случае, если кодировка задана как utf8, а не UTF-8, что встречается в дистрибутивах наподобие Alt Linux.
• Устранено падение при разборе суммы константных значений некорректного типа.

Версия 0.0.4

Зафиксировал новые версии трансляторов и библиотеки. Со времени прошлого выпуска прошло больше года. Помимо исправления ошибок была усовершенствована генерация JavaScript-кода, а также был добавлен генератор Oberon-кода, позволяющий компилировать результат трансляторами Component Pascal и Active Oberon.

Telegram бот

Вдобавок к демо-серверу, позволяющему в браузере запускать код на Обероне, сделал telegram-бота, позволяющего схожим образом запускать код прямо в чате.

В сообщении можно отсылать как текст модуля, который будет выполнен, так и скрипт с отдельными вызовами процедур. Чтобы бот получил сообщение в общем чате, в начало сообщения необходимо добавить косую черту, а для скриптового кода нужно указать ещё и сокращённое название языка программирования - /O7:. В индивидуальном чате с ботом дополнительных знаков не нужно.

Поддерживаются 2-е дополнительные команды:

1. /LIST выводит список доступных модулей, правда, большинство из которых в режиме песочницы выступают лишь заглушками
2. /INFO Module выводит список экспортированных процедур модуля

Проверка арифметического переполнения и инициализированности в JavaScript

Поправил до уровня работоспособности генерацию кода JavaScript для проверки арифметических ошибок и состояния инициализированности переменных. Генерация проверок включается и выключается отдельно для каждого вида, но они не являются полностью независимыми, так как проверка арифметики может быть выполнена заодно с инициализированностью.

Например:

r = a * b;
if (-0x80000000 < r && r < 0x80000000) {
...

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

Проверка границ массива в JavaScript

Добавил проверку индекса на выход за границы массива для кода, сгенерированного в JavaScript, что было анонсировано почти 2-а года назад. Применённая модель проверки, естественно, замедляет выполнение, но всё же не приводит к взрывной деградации скорости в современных браузерах и в node.js, как это бывает с исполнителями JavaScript.

Был применён такой подход:

array = new Array(len);
this.at = function(index) {
  if (0 <= index && index < len) {
    return array[index];
  } else {
    throw new RangeError();
  }
};

..

a = arr.at(i);

len находится в контексте объемлющей функции и не меняется после установления, что позволяет jit-компилятору оптимизировать проверки вплоть до сравнения с константами, что может быть очень эффективным. Впрочем, накладные расходы на методы никуда не деваются, а Object.freeze для обеспечения гарантии отсутствия подмены методов и гипотетической возможности их встраивания не помог для оптимизации.

Создание rpm пакетов

Добавил в систему сборки возможность собирать rpm пакеты. Для пакетирования нужен установленный rpmbuild, который доступен не только в дистрибутивах, основанных на rpm, но и в Debian. В чистом каталоге проекта достаточно выполнить 3-и команды:

./init.sh && result/bs-ost run make.Build -infr . -m source
result/ost run make.Rpm -infr . -m source

Сборка, как минимум, работает в Ubuntu 20.04 и в Alt Linux 9

Кроме установки в Alt попробовал устанавливать rpm пакеты и в Ubuntu. С помощью утилиты alien успешно преобразовал собранные rpm в deb. Полученные пакеты устанавливаются, и всё работает. Правда, у пакетов теряются прописанные зависимости, поэтому появляется возможность установить без них, что может отрицательно сказаться на работоспособности. К сожалению, надежда на возможность сборки только rpm-пакетов с последующим преобразованием в deb оправдалась не полностью.

В целом, rpm формат показался куда более проработанным, чем deb. Не удивительно, что его выбрали стандартом. Но до действительно хорошего уровня формату тоже далеко.