Question ad using System.gc()

["Rony G. Flatscher (Apache)" <ro...@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.

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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org

Re: Question ad using System.gc()

["Rony G. Flatscher (Apache)" <ro...@apache.org>]

On 04.08.2022 15:17, Konstantin Kolinko wrote:
> чт, 4 авг. 2022 г. в 14:45, Rony G. Flatscher (Apache) <ro...@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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org

Re: Question ad using System.gc()

[Konstantin Kolinko <kn...@gmail.com>]

чт, 4 авг. 2022 г. в 14:45, Rony G. Flatscher (Apache) <ro...@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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org