From thomas.schatzl at oracle.com Thu Jul 1 08:30:48 2021 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Thu, 1 Jul 2021 10:30:48 +0200 Subject: [POSSIBLY SPAM: SPF] hotspot-gc-use Digest, Vol 143, Issue 1 In-Reply-To: <522d25f8-ab23-f5f7-f674-84e6688c217a@freigmbh.de> References: <423c6654-8895-29bc-32dd-9d01248ceab2@freigmbh.de> <522d25f8-ab23-f5f7-f674-84e6688c217a@freigmbh.de> Message-ID: Hi, On 29.06.21 14:57, Thorsten wrote: > Hello, > > Basicly System.gc will no longer be able compact your memory or free up > as much as possible. You or a customer or a thirdparty may have a > usecase where thats desirable and now they can no longer do this. Whether desirable or not, the specification of System.gc() call explicitly states that it does not give any guarantees to do anything. So there is no difference than before - the code relies on undocumented behavior. Coincidentally there has been a clarification to the spec wrt to java.lang.ref.References if it were not clear enough (from https://github.com/openjdk/jdk17/pull/183/files): * There is no guarantee that this effort will recycle any particular * number of unused objects, reclaim any particular amount of space, or * complete at any particular time, if at all, before the method returns or ever. + * There is also no guarantee that this effort will determine + * the change of reachability in any particular number of objects, + * or that any particular number of {@link java.lang.ref.Reference Reference} + * objects will be cleared and enqueued. DirectByteBuffers use phantom references for "handling" native memory. > > https://ionutbalosin.com/2020/01/hotspot-jvm-performance-tuning-guidelines/ > So anything this guide states about System.gc() used for cleaning up external resources is just relying on incidental garbage collector specific behavior which may change with different collectors and different JDKs. A garbage collector only manages the Java objects on the Java heap. For any external resources (file handles, directbytebuffers, ...) the application is responsible to manage them. There is this safety net baked in, but try to avoid as it's a safety net. Searching e.g. stackoverflow shows several answers that show how to clear native memory of DBBs yourselves. > Also mentions something about native buffers, I dont know how accurate > this is, how it works with concurrent, and how relevant it is for your > application. > > Just like Thomas I would recommend to use another garbage collector > (Your usecase is basicly the reason they exist) and or analyze your > problem correctly (collect gc logs) ||//Basicly try to solve the problem > and and? not to just hide the symptoms. I would not go that far by changing the garbage collector, but setting goals and measuring whether they are adequately met is always good. > > I am not an expert in that matter but setting |-XX:-G1UseAdaptiveIHOP| > and |-XX:InitiatingHeapOccupancyPercent| to something very low like 15 > might be a better alternative to call System.gc in a loop.|| I do not recommend that. Please have a look at the JEP 346 functionality mentioned earlier that seems to be a better fit for this use case, and may possibly be configured appropriately for that case with the huge performance hit you are suggesting. Thanks, Thomas