Не-а, отличие всё-таки принципиальное. Мне кажется, Францем предложен более совершенный способ трансляции, который решает, в основном, все проблемы, присущие VM. Перечислю их вкратце.
1. Более экономичное использование памяти (нету VM).
2. Slim binaries имеют качественно мощное представление промежуточного кода в виде двоичных деревьев, что гораздо лучше стекового байт-кода при генерации кода для регистровых архитектур (каковыми является подавляющее большинство процессоров), достаточное для дальнейшей оптимизации или даже перетрансляции в другой ЯП. Также эти бинарники очень компактны, значительно компактнее любого машинного кода или стекового байт-кода (надеюсь, у гугля хватит ума передрать и древовидное представление. Без него, блин, уже слегка не та будет петрушка).
3. Кодогенерирующий загрузчик может на лету оптимизировать код для установленного процессора. Т.е. одна программа на Slim Binaries будет оттранслирована максимально эффективно в код i386, и также в код PIII с архитектурой IA64. Это всё достигается и с помощью JIT-компиляции (в .NET и JVM), но значительно более дорогой ценой. Высокие показатели оптимальности кода на тестовых испытаниях оборачиваются на практике реальнейшим кошмаром. VM жрут сотни мегабайт памяти оверхеда по сравнению с нативом, а софт неслабо тормозит, в сравнении с аналогичным, но статически слинкованным в натив. Если бы не было современных процессоров, он бы вообще не работал. Но если для десктопов это ещё как-то терпят (ибо высокий штандарт давно и накрепко задан мелким и мягким большим сэмом), то на планшетах у них, видать, тормозит. Меня ещё тогда порадовало, что Dalvik регистровый. Ведь ежу понятно, что стековая VM ещё тормознее, и не только на процессорах архитектуры ARM.
Никак не могу углубленно прокомментировать это, но у меня подход с VM вызвал отторжение с того самого дня, как я о нём узнал. И нынче приемлю их только в эмуляторах других платформ. Там это неизбежность. А вот подход Франца сразу же поразил в плане совершенства. И я рассказывал о нём мэйнстримщикам, самые умные из которых сказали: "ну подождём, что из этого выйдет".
Не будем увязать в терминологии: "статическая" или "динамическая" кодогенерация достигнута у Франца, но, похоже, что и такая, и такая, ибо в фазе "статической" (в твоей терминологии) кодогенерирующий загрузчик порождает натив из плоского бинарника в момент загрузки, и не нужно уводить нас в сторону тем, что, дескать, слим берётся не из файла. Неважно откуда. Хоть из сети. А в "динамической" (в твоей терминологии) фазе дооптимизация достижима и на лету (а вот это уже способ, реализованный в JIT-компиляторах, но серьёзно облагороженный Францем, что хорошо описано в статьях по ссылкам выше). И никакого тяжёлого наследия в виде VM, которые несомненно уйдут в прошлое, как когда-то пи-код, с развитием подхода кодогенерирующих загрузчиков.