Skip to content

CAUTION: This site hosts draft documentation for the next release. For published content of the latest release, visit eclipse.dev/openj9/docs

-Xconcurrentslack

This option specifies an absolute amount of free space or headroom (in bytes) in the tenure space on top of the automatic concurrent kickoff point. By using this option, you can trigger the concurrent global garbage collection (GC) cycle earlier than the GC heuristic computed kickoff point.

Syntax

    -Xconcurrentslack<size>
See Using -X command-line options for more information about the <size> parameter.

Explanation

Ideally, concurrent GC needs to complete its operation before application consumes all free memory. Otherwise, GC will transition into the stop-the-world (STW) mode, which means longer pauses. Due to fluctuations in application characteristics such as allocation rate, object survival rate, CPU utilization, GC might mis-predict the concurrent GC kickoff point, and start it too late or progress too slowly.

To compensate for such fluctuations, you can specify this option so that the VM starts concurrent GC operations earlier to try to keep free heap space available.

Starting concurrent GC operations earlier can reduce pause times, but it might increase frequency because of suboptimal use of free memory.

The default value is 0, which is optimal for most applications.

Note: This option is not supported by the following GC policies:

How free space is interpreted

The meaning of free space depends on the GC policy in use.

Optimize for average pause time (optavgpause) policy

In this policy, application threads and the concurrent GC kickoff heuristic measure free space in the same way. Therefore, the -Xconcurrentslack value can be used directly.

Generational concurrent (gencon) policy

The <size> value that you specify for -Xconcurrentslack corresponds to additional free space for allocation. But, in gencon policy, application threads and the concurrent GC kickoff heuristic do not measure free space in the same way. Application threads allocate mostly in nursery space, but the concurrent GC kickoff heuristic monitors free memory in tenure space.

Because the concurrent GC kickoff heuristic monitors tenure space rather than nursery space, the <size> value does not map directly to the free space seen by allocating threads.

Therefore, in gencon policy, the amount of headroom is calculated as follows:

Headroom = (<size> ÷ Average promotion rate) × Average application allocation rate

where:

  • <size> is the free memory in tenure space that is specified in the -Xconcurrentslack option.
  • Average promotion rate is the average rate at which objects are promoted from nursery space into tenure space.
  • Average application allocation rate is the average allocation rate from nursery.

Note: The average promotion rate and average application allocation rate can be derived from verbose GC logs. But, in a typical generational workload, the promotion rate is approximately ten times lesser than the allocation rate. Hence, the formula can be approximated with <size> * 10.

In the case of gencon policy, use the -Xgc:concurrentKickoffTenuringHeadroom option instead of the -Xconcurrentslack option for ease.

See also