anchor.diff:        value: ssl
   ----
   
  +For more information about the `jvmOptions`, see the xref:type-JvmOptions-reference[`JvmOptions` schema reference].
   
   [id='con-common-configuration-garbage-collection-{context}']
   === Garbage collector logging
  
positive.code: 
  You can specify the following options in your configuration:
  
  `-Xms`:: Minimum initial allocation heap size when the JVM starts.
  `-Xmx`:: Maximum heap size.
  `-XX`:: Advanced runtime options for the JVM.
  `javaSystemProperties`:: Additional system properties.
  `gcLoggingEnabled`:: xref:con-common-configuration-garbage-collection-{context}[Enables garbage collector logging].
  
  The full schema of `jvmOptions` is described in xref:type-JvmOptions-reference[`JvmOptions` schema reference].
  
  NOTE: The units accepted by JVM settings, such as `-Xmx` and `-Xms`, are the same units accepted by the JDK `java` binary in the corresponding image.
  Therefore, `1g` or `1G` means 1,073,741,824 bytes, and `Gi` is not a valid unit suffix.
  This is different from the units used for xref:con-common-configuration-resources-reference[memory requests and limits], which follow the Kubernetes convention where `1G` means 1,000,000,000 bytes, and `1Gi` means 1,073,741,824 bytes
  
  .`-Xms` and `-Xmx` options
  
  The default values used for `-Xms` and `-Xmx` depend on whether there is a xref:con-common-configuration-resources-reference[memory request] limit configured for the container.
  
  * If there is a memory limit, the JVM's minimum and maximum memory is set to a value corresponding to the limit.
  * If there is no memory limit, the JVM's minimum memory is set to `128M`. The JVM's maximum memory is not defined to allow the memory to increase as needed. This is ideal for single node environments in test and development.
  
  Before setting `-Xmx` explicitly, consider the following:
  
  * Total JVM memory usage can be a lot more than the maximum heap size. Try experimenting to find a value for `-Xmx` that makes the best use of the container's memory request without exceeding it.
  * Setting an appropriate Kubernetes memory request.
  ** Kubernetes might kill the container if there is pressure on memory from other pods running on the node.
  ** Kubernetes might schedule the container to a node with insufficient memory.
  If `-Xms` is set to `-Xmx`, the container will crash immediately; if not, the container will crash at a later time.
  
  It is _recommended_ to:
  
  * Set the memory request and the memory limit to the same value
  * Use a memory request that is at least 4.5 × the `-Xmx`
  * Consider setting `-Xms` to the same value as `-Xmx`
  
  In this example, the JVM uses 2 GiB (=2,147,483,648 bytes) for its heap.
  Its total memory usage is approximately 8GiB.
  
negative.code:   trustedCertificates: []
  ----
  
  For information on configuring TLS client authentication, see the xref:type-KafkaClientAuthenticationTls-reference[`KafkaClientAuthenticationTls` schema reference].
  
  [id='con-common-configuration-resources-{context}']
  === `resources`
  