Just realized a problem, currently we use a loading cache for goja.Runtime caching keyed by ctx. However that means the caching is per transform. We had scenarios in the past where a service handles many concurrent requests, each of which contains a tiny payload that needs to be parsed and transformed. In that situation, the goja.Runtime caching is completely ineffective.

Instead, we want to share goja.Runtime across different transforms, as long as javascript() are not called at the same time. Thus the introduction of resource pool. We will adaptively create a number of goja.Runtime in the resource pool, and each of the transforms, concurrent or not, requests a runtime from the pool. The hope is the resource pool eventually grow to certain size that any concurrent requests would be satisfied. The pool is also configured to have a minimum idling runtimes, so that when eviction kicks in, it won't completely clear up the cache.

Extensive benchmarks created and verified the new design. With this, now javascript is truly performant enough to fully replace eval.

[update] - given my simple use case of the resource pool: no max limit, no blocking, etc. there is simply no reason to use this full featured resource pool - instead use the much simpler and more performant sync.Pool. And benchmark proved it's much faster and now javascript is nearly on par with eval; and concurrent performance is much better than the full-fledged resource pool usage.