Hi Stefan,
On 29.06.21 14:04, Stefan Reich wrote:
Hi Thorsten,
yes I used to call System.gc() once a minute. I just like to see correct
heap usages. However, for the server, I removed the call because I
didn't like the delays (they are around or slightly above 2 seconds BTW
- actually measured this tiime :).
I have just tried XX:+ExplicitGCInvokesConcurrent. I think it's good;
seems to do the job. So my problem may actually be solved. I'll keep
monitoring.
> Setting /ExplicitGCInvokesConcurrent /may or may not have some
unintended side effects.
Please elaborate, what could those be? I am not aware of any side
effects. I need concrete information.
Afaik there are no (unknown) side effects (and I should know :)), only
that this will instead of a fully stw pause that collects everything
force the start of a reclamation phase in G1 (with concurrent marking,
and any reclamation needed in small steps).
The only "unintended" side effects could be applications expecting that
after the call the heap is actually immediately compacted (typically
what is expected is that all kinds of java.lang.ref.Reference are looked
at again and cleaned up).
Note that this is a fallacy: System.gc() may be ignored completely by
the system as per specification. Please do not rely on that.
Also some benchmarks use a system.gc() call to instantly "reset" the
heap to a known good state regardless of overhead. This is actually what
you do not want anyway.
A question from another email:
Am 28/06/2021 um 19:39 schrieb Stefan Reich:
Hi Thorsten!
Does MaxGCPauseMillis apply to System.gc() too? I thought this was
for the incremental collections.
MaxGCPauseMillis does not apply to a full(y compacting) gc typically
called by System.gc(). Note that with -XX:+ExplicitGCInvokesConcurrent
any gc pauses caused by this invocation respect the pause time goal.
Thanks,
Thomas
_______________________________________________
hotspot-gc-use mailing list
hotspot-gc-use@openjdk.java.net
https://mail.openjdk.java.net/mailman/listinfo/hotspot-gc-use
