расскажу немного про то, что такое каракан внутри.

внутри это более‐менее стандартный компилятор в регистровую VM, написаный практически «по учебнику».

парзер сделан руками, и немного «шиворот‐навыворот»: вместо прямой рекурсии она отслеживается вручную, и парзер кладёт на стеки куски собраных AST для выражений и операторов. а потом из них строит AST повыше. сделано так для того, чтобы на устройствах, где со стеком напряг, не начинать rampage, когда всё становится плохо. внутри кода есть твики, указывающие максимальный уровень вложенности для парзера и подобное, поэтому поломать каракан очень‐очень глубокой глоткой нельзя (если в коде каракана нет ошибок, конечно ;-).

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

практически всё выделение памяти в лексере/парзере/компиляторе делается в отдельном пуле, который потом выкидывается. во‐вторых, так быстрее, а во‐первых, опять таки позволяет удобней контролировать, сколько движку позволено выжрать.

компилятор в процессе создания кода пытается отслеживать значения локальных переменных и делать constant folding. периодически у него это получается. однако любое использование try/catch/finally и/или with отрубает эту функциональность наглухо для всей функции. также каракан может отрубить оптимизатор, если посчитает, что вложеные функции слишком сложные (расплывчатое понятие, да).

по некоторым причинам значения аргументов функции не отслеживаются, даже если аргументу явно присваивается какое‐то значение и его можно отслеживать. так что заводите локальные переменные, когда пишете js-код для оперы. ;-)

for и while, у которых известно количество повторений, компилятор может unroll'нуть. он там как‐то считает весовые коэффициенты и выгоду, но я не смотрел, как именно. если честно, я вообще не уверен, что от этого есть большая выгода. впрочем, см. ниже. это тоже часть оптимизатора, и тоже будет отрублена, если вдруг.

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

код компилятора вполне читабельный. есть документация по командам VM: краткая, но вполне достаточная для справочника. авторы знали про паттерн visitor, и кое‐где его используют. однако стадии Prepare и Compile не «запатернены»: скорее всего, писались первыми, а потом просто не было глубокого смысла делать код «модным».

нативного дизассемблера нет (или я долблюсь в глаза), но дизасм VM есть, конечно. впрочем, он включается только для standalone jsshell, а сама опера собрана без него.

в целом — каракан оставляет очень приятное впечатление и вполне поддаётся разбору. с jit'ами чуть сложнее (потому что один jit больше всего компилятора в целом), но при беглом осмотре они тоже вполне адекватны.

остальные части кода я смотрел очень бегло, так что ничего особо интересного о них написать не могу пока.

примечание: в течение этой недели с хвостиком я честно использую оперу как основной браузер. работает, не падает. прямо как настоящая.

p.s.: есть какой‐то интересный исходник, который — по идее — должен сохранять на диск сгенерированый код для VM. однако судя по тому, что в этом исходнике можно прочитать — он всего лишь обломок футарка (предыдущего js-двигателя), и для каракана такой фичи попросту не планировалось.