What I understand is;
Aside from V8 Engine's garbage collection, does it mean that any memory used by foxx is garbage collected as soon as the response is made?
If above question's answer is yes, is there a way to disable V8 Engine's garbage collector, and if I disable V8 Engine's GC, can I expect a better latency?
Please let me know if I'm getting it wrong.
In contrast to many other interpreters, javascript interpreters have a special feature. They need to be run for several browser windows, and one Window shouldn't know about the other.
Thus the interpreters operation set is strictly separated from its general logic. In
V8 this concept is implemented under the name Isolate.
ArangoDB spawns several Isolates, each one context that Foxx can run in. ArangoDBs infrastructure has hooks into the Isolates that can signal i.e. new collections are available. However, there is no such hook that could be used in Foxx.
ArangoDB is multi-threaded. The request-broker will read the request, and if it finds out that it should execute a Foxx-Request (instead of i.e. a direct AQL invocation) it will pick one of the Isolates from the pool, and continue execution within that V8 Context. So there is neither a warranty you reach the same worker thread, nor that it will pick the same Isolate on subsequent requests.
Each of these Isolates can be garbage collected individual, without blocking the execution in other Isolates. ArangoDB Exposes statistics about these contexts , so you can see there that Isolates can be tagged dirty which means they should be garbage collected. You can use require("internal").wait(<seconds>, true) to manually invoke the garbage collection. The number of contexts spawned depends on the numbers of CPUs your system has. However, these settings can be configured. So you see that the tactics are quite different from tuning the Java GC.
Foxx itself will discard structures allocated by services after the request. They will then be unavailable in subsequent requests, and once the garbage collection runs their memory will be returned to the system.
Usually you should strive to make your Foxx Services a thin layer around the AQL you execute. While performance should be considered as a feature, you usually start looking at it once your code has reached a certain grade of maturity. We explained howto create usage scenarios and measure and optimize possible throughputs in our blog post series; while Foxx services aren't mentioned there directly, the tactics used there can be applied to Foxx as well.