у вас ссылки не работают на странице с документацией.
local a = ujit.immutable(value) а вот это просто делает его read-only, но как только оно выйдет из скоупа либо a = nil соберётся gc?

и ещё у вас везде используется api через ujit, а проект LuaVela - неконсистентно))

Это всё-таки не отвечает на мои вопросы (ещё раз):

* А в каком состоянии по вашему мнению Майк Полл забросил разработку?
* И что такое по вашему мнению 10%?

Но я тем не менее как-то попробую ответить.

Во-первых, бетой в 2019 году по-прежнему является ветка  2.1, а 2.0 – stable. Сравнивая 2.1 и LuaVela, я не берусь утверждать, что LuaVela – это bugless code, но я хотя бы могу сказать, что она крутится с 2017 года в боевом окружении, обрабатывая сотни миллиардов запросов ежесуточно (я не преувеличиваю). А про LuaJIT 2.1 у меня проверенной информации нет. При этом, возвращаясь к стабильной ветке 2.0: она просто не умеет работать со всей виртуальной памятью на 64-битной платформе на Линуксах, а LuaVela (как потомок стабильной 2.0) – умеет. Да, 2.1 имеет режим LJ_GC64, но, насколько я помню доклад Питера на митапе в Лондоне (смотрели?), этот режим стабилизировался только к 2017 году.

Далее, не JIT-ом единым живы реализации Lua. Например, ещё хочется эффективно использовать память в бизнес-приложениях. Для этой цели и была добавлена функциональность силинга (о ней см. в анонсе) и DataState (забыл упомянуть об этом, это возможность задёшево разделять read-only данные между несколькими экземплярами VM). В этот момент мы бесплатным бонусом получаем возможность делать какие-то данные иммутабельными (как я рассказывал на докладе в прошлом году, ujit.immutable(_G) спасает нас от проблем опечаток в именах переменных).

Но если мы говорим о JIT-е:

* В LuaVela затащено очень многое из того, что есть в LuaJIT 2.1. Из крупного, что не сделано – trace stitching для "компиляции" вызовов Lua C API;
* В LuaVela есть расширения стандартной бибилиотеки, в которых собраны некоторые полезные на наш взгляд функции общего назначения. Они написаны на C, и многие из них JIT-компилируются;
* В LuaVela появились оптимизации, которые помогают улучшить работу машинного кода при обилии с операциями с памятью (это очень частый случай при скриптовании бизнес-логики, и вот тут оригинальный JIT ведёт себя не очень хорошо – безусловно делая всех в чисто вычислительных задачах).

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

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

Но утверждение про 10% – это выглядит как-то непонятно.

И это тоже верно. Мы поправим, спасибо!

Что нового в 5.4 я не очень знаю но даже 5.3 поддержки нет и не планируется

потом будем экспериментировать дальше:
function foo()    

  mt = {}

  mt.__close = function() print("close a") end
  mt.__gc = function() print("gc a") end

  local <toclose> a = {}
  setmetatable(a, mt)

  return a
end

local d = foo()

print("======")
Должно быть:
close a
=======
gc a

Все что описано типа поддержки ппмяти больше 2 гиг читать смешно и странно

Есть (прошу прощения, не у компа)

make prepare_benchmarks
cd tests
./run_benchmarks.sh

Все что описано типа поддержки ппмяти больше 2 гиг читать смешно и странно

А что в этом смешного и что странного?

оформите новость на IT ресурсах: habr, opennet, tproger, linux.org.ru