Manisha,
On 12/30/24 8:21 AM, Manisha Subramanian wrote:
We're not tearing down the entire application. The HTTP server is
just one part of our application (all part of the same JVM), and
that is why calling the System.gc() on the teardown of the HTTP
server may be harmful to the rest of the application since it would
be handling other types of traffic, and a stop-the-world GC is not
OK at this point.
Is a stop-the-world collection ever acceptable? There is no guarantee
that System.gc will trigger a stop-the-world event. If the GC is going
to stop-the-world, it's going to do it, anyway. Yes, calling System.gc
may tip things over the edge, but NOT calling System.gc is only going to
delay any such stop-the-world... and not for long.
Even the link that you shared as reference does say that it is a red
flag to call explicitly use System.gc() in the code.
That link was shared by another poster, not me.
This addition of System.gc was added to solve a very specific problem
that can take-down the whole JVM and not just during unit tests. If you
disable System.gc using -XX:+DisableExplicitGC then you run the risk of
crashing your JVM.
I went looking for modern performance comparisons of JSSE without
OpenSSL versus JSSE+OpenSSL and I didn't find what I was looking for.
If you are concerned about both JVM stability and GC pauses, you might
want to remove your dependency on these native components. You may,
however, pay a performance penalty. OpenSSL has historically proven
faster than the JVM-provider cryptographic provider, but my
understanding was that it was a JVM bug preventing it from using
hardware-based AES and that bug was fixed ~ Java 17 or so.
So I would say "run your own benchmarks to see if it matters to you".
I would also make the same recommendation vis-a-vis System.gc to see if
it really does represent a threat to your application's throughput.
If you can show that there is a reasonable threat to GC performance,
here, then we could make this call optional based upon configuration,
etc. but my guess is that it's an important call for JVM stability and
should not be disabled.
-chris
________________________________
From: Christopher Schultz <ch...@christopherschultz.net>
Sent: Friday, December 27, 2024 11:10:32 PM
To: users@tomcat.apache.org <users@tomcat.apache.org>
Subject: Re: System.gc() call in Tomcat 9.0.96
[You don't often get email from ch...@christopherschultz.net. Learn why this is
important at https://aka.ms/LearnAboutSenderIdentification ]
Markus,
On 12/27/24 12:16 PM, i...@flyingfischer.ch.INVALID wrote:
Manisha
you may be able to disable explicit System.gc() via the java argument -
XX:+DisableExplicitGC.
https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.baeldung.com%2Fjava-system-gc&data=05%7C02%7Cmanisha.subramanian%40ericsson.com%7C436c9760409b45d1915208dd269da14e%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C638709180636317993%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=Abo3vFypYK2JNApVSr%2B7PT45Gl6HyYvYVg%2BYtZd%2FmF8%3D&reserved=0<https://www.baeldung.com/java-system-gc>
But ... WHY?
This is a situation that should really only occur once during the
application lifecycle (when it's being shut-down). Typically at
shut-down you really don't care if a GC is going to happen.
Also, tearing-down an application typically generates ... a lot of
garbage. So a GC is likely to happen, anyway, naturally. If your
application is big and there is memory pressure (unlikely, since
everything is coming down) or if the GC sees large de-allocations and
takes an opportunity to tidy-up the heap, then you may even get a FULL
GC when this is all happening.
Finally, it's in there to avoid a JVM crash which is pretty much the
worst thing that can happen to your application, even if it is shutting
down.
-chris
Am 27.12.24 um 17:55 schrieb Christopher Schultz:
Manisha,
On 12/27/24 2:45 AM, Manisha Subramanian wrote:
Details of our application are given below:
OS: RHEL 8.x [OpenSSL version: 1.1.1]
Configuration: We're using Tomcat as an HTTP Server, but it is
embedded as part of our application
Java version: Java 8u381
We're using Apache Tomcat 9.0.86 and are considering an update to
9.0.98. During the update, we noticed this commit, where we saw a
System.gc() call:
Avoid possible crashes with OpenSSL * apache/tomcat@bb4a5a0 *
GitHub<https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Ftomcat%2Fcommit%2F&data=05%7C02%7Cmanisha.subramanian%40ericsson.com%7C436c9760409b45d1915208dd269da14e%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C638709180636334448%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=EvBbX0hyEOssdnENeIoOne62f%2FhRS6Lvc%2F5Qx8CfI7A%3D&reserved=0
bb4a5a08603d8e1d67b4249fe8c634571a6ec852>.
If we choose to stop our HTTP server [and the JVM chooses to honor
this System.gc() call] it will not just affect Tomcat, but the entire
JVM and may cause issues to our application.
The commit message says it'll occur mostly with the Tomcat test suite
but the impacts of the gc call may affect the entire application.
I would think that taking down Tomcat and/or its connectors (which is
what you would be doing when AprLifecycleListener.terminateAPR is
called) would have a much bigger impact on your application (like
STOPPING it) than requesting garbage-collection (which happens all the
time).
We were wondering why this System.gc() was added. Request you to
share your views.
The gc() call was added to attempt to force the cleanup of resources
that have an impact on native-library resources before terminating the
native library (OpenSSL). It is intended to prevent native crashes
(which typically terminate the JVM) in some edge cases.
-chris
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
