Greetings, xenadu!
Your application sounds very interesting!
Actually, without multiple V8 runtime instances there can be no concurrency. V8 runtimes are not thread-safe and explicitly block multithreaded access.
That sounds good, but again, in order to support concurrent script execution, your worker threads must not share V8 runtimes. This also means that they can't share compiled scripts.
Sure. A V8 compiled script will eventually be garbage-collected if it's no longer referenced. At that time it'll release its unmanaged counterpart, making it available to V8's garbage collector.
Yes, and this is why it sometimes makes sense to instantiate
A V8 compiled script is bound to a single V8 runtime instance. It is therefore incapable of concurrent execution. It is also immutable. Its advantage over plain-text JavaScript is that it can be re-executed more efficiently and reused across engines that share the runtime.
V8 resource constraints are applied at the runtime level, but nothing prevents you from creating a separate runtime for a given engine instance. In fact, that's exactly what happens when you invoke a
Thanks for your questions, and good luck!
Your application sounds very interesting!
One V8Runtime instance [...]
Under what scenario would you even want multiple V8Runtime instances?
Actually, without multiple V8 runtime instances there can be no concurrency. V8 runtimes are not thread-safe and explicitly block multithreaded access.
3.When a request comes in on a worker thread that has no existing V8ScriptEngine instance assigned, a new instance will be created from the V8Runtime.CreateScriptEngine method.
That sounds good, but again, in order to support concurrent script execution, your worker threads must not share V8 runtimes. This also means that they can't share compiled scripts.
Is it possible to eventually allow the compiled script to be collected if nothing has a reference to it anymore?
Sure. A V8 compiled script will eventually be garbage-collected if it's no longer referenced. At that time it'll release its unmanaged counterpart, making it available to V8's garbage collector.
Presumably if we needed a higher safety mode we could dump the V8ScriptEngine and create a new instance, correct?
Yes, and this is why it sometimes makes sense to instantiate
V8Runtime and call V8Runtime.CreateScriptEngine() even if you don't plan to share the runtime. This way, if you need a clean execution environment, you can spin up a new engine instance efficiently and reuse previously compiled scripts.
A big question is whether the compiled script can be re-used among V8ScriptEngine instances simultaneously, or if there are thread issues or locks involved. Could someone mutate the compiled script and introduce threading issues
A V8 compiled script is bound to a single V8 runtime instance. It is therefore incapable of concurrent execution. It is also immutable. Its advantage over plain-text JavaScript is that it can be re-executed more efficiently and reused across engines that share the runtime.
Another question relates to resource usage... are the limits enforced on the entire runtime or on each V8ScriptEngine instance
V8 resource constraints are applied at the runtime level, but nothing prevents you from creating a separate runtime for a given engine instance. In fact, that's exactly what happens when you invoke a
V8ScriptEngine constructor.
Thanks for your questions, and good luck!
