Нет, будет так же как на СЕ

Если использовать С2 или грааль который включён в jdk то будет медленнее, он немного старее чем мастер граальвм

Но там компилятор из граальвм подставляется в modulepath

Но просто GraalVM сборки конечно надёжнее, меньше двигающихся частей

Truffle просто нужно от компилятора некоторые вещи которые граль умеет хорошо делать. Без граля или с более старым гралем, будет медленнее.

С ЕЕ гралем в GraalVM EE будет ещё быстрее

Ну так пример про Java 11. Который выше. А грааль судя по гитхабу ещё не умеет в совместимость с ней

Граль компилятор умеет про java11. Он же даже включён туда как эксперимантельная опция. У нас просто сборок пока нет потому что там другие вещи не работают, например native image

Про кэш там непонятно немного из документации
> if a source instance of your program is no longer referenced, then the cache will be freed automatically
значит ли это если я из какого-то своего рантайм кэша скриптов удалю ссылку на Source он просто приберется GC после цикла?

Или вот момент
у меня есть скрипт который только определяет функции, которые я потом в java хочу позвать
выглядит так что каждый раз контекст создавать не очень выгодно
потому что произойдет eval скрипта, даже если он не парсится
Еще вторая проблема что с нашорном на весь engine можно было расшарить какие-то либы в GLOBAL_SCOPE, а тут GLOBAL_SCOPE я так понял нет, есть только область Context'а.

Да

Я так понимаю что контекстов где он загружен тоже не должно быть

Context это топ левел

Ну вышло что контексты проще кэшировать, если на каждый реквест по контексту создавать то много памяти начинаем аллоцировать
в javadoc к контексту где-то пробегало, что кэширование идет через сам Engine, просто если я создаю новый source и делаю eval в контексте он тоже где-то там осядет, судя по тому как ты говоришь

Контекст на тред будет нормально? Они будут закэшированы

Просто 1 engine для них всех

да, у меня сейчас как раз по контексту на тред в пуле и 1 engine для них всех

Совсем глобальный стэйт мне кажется нельзя сделать, и это правильно потому что там могут быть необъяснимые гонки в multithreaded системах. Можешь описать подробнее юскейс?

юзкейс такой
есть сторонние ребята, который пишут js код, используя определенный API через либы, которые у нас написаны на java (у нас свой require реализован просто)
В js скрипты передаются входные данные используя унифицированный API
Скриптов  этих пару тысяч
На нашорне система была какая
Есть объектный пул из ScriptEngine с блокирующим доступом.
Во время выполнения колла получаем объект ScriptEngine и смотрим, компилировали ли мы уже текущий скрипт, если нет, то компилируем,
Дабы не было пересечения по глобальным переменным каждый скрипт прогоняется через парочку регулярок которые оборачивают весь скрипт в неймспейс и и заменяют глобальные переменные на переменные неймспейса
Потом уже во время выполнения мы просто делаем callMember на ScriptObjectMirror полученного для неймспейса, тогда нам не нужено каждый раз прогонять скрипт
С граалем я попробовал вообще упростить систему и избавиться от пула, т.к Context не имеет глобальной области видимости, но при высокой нагрузке очень быстро заполняется хип
поэтому оставил как есть, просто заменил нашорн на грааль

мой джуновский мозг 💥💣💥

Мне нужно подумать