Можно например посмотреть компилируется ли функция которую ты вызываешь

А есть какой-нибудь гайд по такому дебагу? Или только опции со страницы выше, а дальше +- свободное плавание. Не очень хочется писать пример и ожидать его разбора, хочется самому поковыряться и понять лучше

Чисто из интереса: в граале есть поддержка -XX:+PrintAssembly?

Да

А как вызываешь метод? сначала eval всего кода, потом getMember && execute?

У меня жс может дергать котлиновские suspend функции, результат которых ожидает в виде промиса.
Вызываю eval всего кода, который возвращает промис, затем

i = 0
while (i < suspendeds.size) suspendeds[i++]()

Каждый такой вызов завершает очередной промис и либо создает новые (которые автоматически добавляются в этот же список и выполняются здесь же), либо ничего не создает, и мой главный промис завершается

eval это не то что нужно, eval нужно запустить один раз, далее вызывать уже твою функцию которая возвращает промис. У меня такая же ситуация только вызываю из скала кода
context.getBindings("js")
     .getMember(RENDER_FUNCTION_NAME) //JS function name
     .execute(params) //JS function params
     .invokeMember("then", callback.apply()) //() => Consumer[String]
     .invokeMember("catch", errorCallback.apply()) //() => Consumer[Throwable]

Почему не то, что нужно? Я его один раз и вызываю:

callDelayed - та штука с вайлом

Еще для я создаю N контекстов, каждый из них только один раз евалит код и много раз вызывает execute

У меня под каждый JS код тоже свой контекст (но общий Engine)

мне в свое время сильно помог вот этот примерчик https://github.com/graalvm/graalvm-demos/tree/master/js-java-async-helidon

вот тут тоже execute есть

Видел этот репозиторий, но здесь скорее показывают, какие подходы бывают. У меня ведь код все-таки полностью исполняется, вряд ли execute() спасет ситуацию.
А пока нагуглил cpusampler, вынес самые долгие функции из JS'a в котлин, стало несравнимо быстрее (TraceCompilation показывал, что эти функции компилируются, так что не знаю, что еще можно было сделать для грааля, чтобы в жсе оно работало быстро). Ну и проблему с while (await promise) решаю тем, что переписываю все на promise per batch, а не promise per element: посмотрю, спасет ли (но почти уверен, что да)

а js код во время выполнения дергает kotlin-функции? они тоже асинхронные?

Я eval js кода запускаю в корутине и из жса дергаю "как бы" suspend (исполняемые только в контексте корутин) функции котлина. На самом деле это выглядит так, что для каждой suspend функции у меня существует обычная (которую я уже и дергаю), а внутри нее нужная suspend функция кладется в тот самый список suspends, который исполняется после просчета eval'a: когда результирующий промис готов, но ждет выполнения этих самых suspend функций

По итогу все выполняется без блокировок и в одном потоке, как того хочет js, но с microtask event queue что-то явно не так, если промисов много (хотя в моменте мало)

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

Я делал так что js код дергает методы которые возвращают фьючу, перед возвратом трансформируя в js promise. С этим подходом все было ок, паралельное исполлнение и promise.all - все работает, только про синхронизацию не забывать