On 04.08.2022 15:17, Konstantin Kolinko wrote:
чт, 4 авг. 2022 г. в 14:45, Rony G. Flatscher (Apache) <r...@apache.org>:
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.
If resources are hard to initialize or hard to clean up it might be a
good idea to pool them.
Is it possible to release those resources, e.g. by implementing a
Tag.release() method? Making use of tag handler pooling provided by
the JSP specification / Tag Extension API for "classical" tag
handlers.
This would work only for BSF script engines (the Apache scripting framework that predates the
official Java scripting framework javax.script a.k.a. jsr223) as there terminate() is available.
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.
Problems may be
a) Overheating the Planet, by doing useless work.
:)
That is what bitcoin miners already do somewhere, so I do not think
that your use case adds much.
Indeed.
If you do a "resource.close()" call to release a resource, you are
specifically doing some required work. If you call a GC (via
System.gc() or maybe explicitly via JMX), some work performed by GC is
useless (not resulting in any memory being freed) and some is useful.
What is the balance between the useless and useful work and whether
the JVM can be configured to make the balance better is what
determines whether calling the GC is a good idea in your use case.
E.g. it might occur that it would be cheaper to just kill the whole
JVM once the memory is full and start over with a new instance.
Still have to arrive at that point.
b) Getting less of performance / throughput than you desire.
That is what those stress tests are supposed to let you to estimate.
Just rigging the tests might be a bad idea (as VW engineers found
through the Dieselgate), as it may hide a problem that may be observed
by real users.
+1
P.S.: If this question should rather be asked in the Tomcat user list please
let me know.
We do discuss "[OT]" (offtopic) questions here sometimes.
And this question looks to be more related to Taglibs (a set of tag
library projects under Tomcat PMC) rather than to Tomcat itself. Their
development is discussed here.
Thank you very much for your thoughts and efforts, Konstantin!
---rony
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
