While testing a taglib library that allows javax.script languages to be used in JSPs one observation
was directed at garbage collection. It seems that Java's garbage collection in this particular use
case is carried out quite lazily (which is fine in the general case). There is however a use case
where resources are not only held (and visible) by Java, but also by native code which releases its
resources only after the Java garbage collection reclaimed the Java peer (employing
PhantomReferences and a cleaner as finalize() has been deprecated for removal).
In the course of stress tests there are hundreds of ScriptEngines created (each JSP request will
cause a ScriptEngine to be created per script language used in that JSP). It seems that the lazily
employed gc() allows situations where there are more than 100 unreferenced ScriptEngines tangling.
The implementation of a ScriptEngine that serves as the peer for a native programming language
instance would employ a System.gc() in the case that 100 or more such unreferenced ScriptEngines
exist in the currently running JVM.
The question: would you see a problem in employing System.gc() independent of the JVM and/or Tomcat?
Theoretically it may be invoked every second or two (unless of course the System's garbage collector
ran and allowed the unreferenced ScriptEngine resources to be cleaned). In practice (outside of
artificial stress tests) this may never be triggered as long as the JVM garbage collector runs from
time to time.
What do you think?
---rony
P.S.: If this question should rather be asked in the Tomcat user list please
let me know.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
