[POSSIBLY SPAM: SPF] hotspot-gc-use Digest, Vol 143, Issue 1

[Thomas Schatzl]

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