чт, 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. > > 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. 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. 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. > > 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. Best regards, Konstantin Kolinko --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
