Андрей Мелихов - V8 под капотом 

58:50 *Кеширование байкода* Андрей ошибается. Кеширование откомпилированного кода существует с 2015 года с версии v8 4.2, в чем можно легко убедиться даже просто посмотрев в папку кеша Google Chrome где подобный байткод выделен в отдельную папку. Причем машинерия отвечающая за критерии подобного кеширование местами настолько странная что ничего кроме удивления не вызывает. Ниже чуть упрощенное описание этого процесса, акутальное на июнь 2021 года, достаточное чтобы знать все необходимое для понимания процесса кеширования байткода в Chrome. На текущий момент существует три разных вида поведения браузера приводящие к кешированию байт кода для случае Google Chrome. При этом для всех трех стратегий должны выполняться следующие условия: 1. *Это должен быть внешний файл. Inline код никогда не кешируется* 2. *Размер файла должен быть не менее 1 килобайта* 3. *Кодировка файла и страницы должна быть UTF8* В случае если кодировка не совпадает кеш байт кода не используется, но при этом может в некоторых случаях создаваться. *Стратегия 1* Самая распространенная модель поведения связана с типичной загрузкой Js файла: использования тега script для подключения файла кода. В рамках этой модели, существует три фазы через которые должен пройти код, чтобы его откомпилированная версия попала в кеш. При первом запросе JS файла, происходят все типичные процессы для запуска кода, при этом откомпилированная версия не сохраняется в кеше. Сохраняется только сам JS файл. В случае если осуществляется повторный запрос этого файла не позднее чем через 72 часа относительно первого запроса, его байт код версия, созданная в момент подключения, сохраняется в кеше. И в свою очередь при третьем запросе, который опять должен произойти не позднее чем через 72 часа, уже загружается и используется ранее сохраненная откомпилированная версия. *При этом следует знать* что современный V8 использует так называемую *ленивую компиляцию кода* которая выглядит следующим образом: на старте компилируется только то, что выполнялось в момент подключения JS файла (на самом деле все чуть сложнее, и откомпилирован может быть и мертвый на старте код, но зависит это все, в первую очередь, именно от того _что_ выполняется и _как_ выполняется при подключении). Весь прочий код файла остается в исходном виде. То есть только эта первая часть откомпилированного кода попадает в кеш. Даже если при последующей работе используется весь код из файла, в кеше будет лежать только его часть созданная на момент подключения JS файла. При этом в случае, если эта стартовая часть имеет какое либо ветвление, зависящее от каких то внешних факторов (то есть в одно время выполняется на старте одно а в другое - другое) то в кеш постоянно будет сохраняться то одна версия то вторая. Для примера, в случае загрузки jQuery версии 1.2 где обьем JS кода в несжатом виде составляет около 100кб, около его половины компилируется на старте и соотвественно попадет в кеш байт кода. *Стратегия 2* Вторая модель поведения связана с использованием Cache API. Если JS код запрашивается и подключается при помощи использования этого API, то все происходит ровно так же как и в стратегии 1, за исключением первой подфазы сохранения JS файла. То есть в случае использования Cache API мы ровно на один шаг ближе к цели. *Стратегия 3* Третья модель поведения связана с фазой Install у Service Workera. В этой фазе, все JS файлы которые присутствуют в списке предварительной загрузки, в отличии от двух предыдущих примеров, гарантировано проходят 100% компиляцию, и соотвественно 100% сохранение в кеш байт кода, в результате чего браузер уже при первом подключении использует 100% откомпилированную версию взятую из кеша байт кода. Исключением является ситуации когда, файл, получивший кеш таким образом, будет подключен как модуль. В этом случае кеш аннулируется и вместо него создается новый с использованием типичных механизмов ленивой компиляции. *Как контролировать/изучать процесс* Наблюдать за всеми этими процессами частично можно в DevTools во вкладке Perfomance фильтруя процессы загрузки по конкретному JS файлу. В подробном описании фазы, обязательно указывается откуда взят файл, в каком виде, и каков обьем байт код кешированной версии если взята она. Наиболее подробный отчет можно получить используя механизм записи трейса работы браузера.

Как же круто, отличный доклад

Круто.

Мегалайк и мегареспект Андрею!

Ок. До +- 2015 года доехали. Вопрос. Что было дальше. Как же развивался V8 дальше...

Почему Андрей на 20:01 говорит что язык асинхронный, если он синхронный?

38:00 Так может стоит признать что в данном ЯП не хватает типизации и не решать эту задачу налету перетягивая ответственость за написание кода на интерпретатор или компилятор?

на обложке он был еще студентом

js не совсем чисто интерпретируется. функции часто могут за компилироваться и использоваться так. не только функции, но чаще именно они. вообще если движок видит что что-то часто используется, он может это закомпилировать чтоб повысить производительность. и чаще всего это именно функции. как и то что многие говорят что node.js однопоточная. она никогда не была однопоточной! даже в первой версии в ней был многопоток.)))

А почему некоторые видео здесь (На канале HolyJS) доступны только по ссылке, а некоторые выложены в открытый доступ?

Большинство вопросов из зала - это капец...