P4
The goal is to use GC logs from training runs of an application to determine optimal values for GC configuration JVM options, in particular memory pool sizes.
GC logs from an application run can be used to understand its behavior and its performance bottlenecks. GC metrics and statistics can provide meaningful information about GC and the application, such as GC frequency, Full GCs, their causes, heap and metaspace usage, pause times and so on. Correlation between various metrics can help guide tuning of GC configuration parameters like the sizes of memory spaces or pause time goals.
We can also devise a mechanism (a new JVM option) for users to specify the performance goal during training runs. The performance goal could be to achieve either improved latency or throughput for production runs. The determination of flag values is performed in accordance with the specified performance goal.
The optimal values of GC parameters determined from one application run can be passed over to a subsequent run with a goal of achieving better performance in terms of throughput or latency. The determined flag values can be simply saved in a text file in a newline separated `<JVM option>=<value>` format. This file can be used with @argfile option to launch the successive application run.
This is how the process would look like:
1. Specify a performance goal while launching training runs - latency or throughput
2. Collect GC data from training runs. Understand and analyze GC data and determine optimal values for GC configuration options in accordance with the specified performance goal. Save the GC options and their values in a text file.
3. Launch the successive application run (i.e. production run) including the saved JVM-options text file as an @ argument
`java @jvm-options.txt application`
GC logs from an application run can be used to understand its behavior and its performance bottlenecks. GC metrics and statistics can provide meaningful information about GC and the application, such as GC frequency, Full GCs, their causes, heap and metaspace usage, pause times and so on. Correlation between various metrics can help guide tuning of GC configuration parameters like the sizes of memory spaces or pause time goals.
We can also devise a mechanism (a new JVM option) for users to specify the performance goal during training runs. The performance goal could be to achieve either improved latency or throughput for production runs. The determination of flag values is performed in accordance with the specified performance goal.
The optimal values of GC parameters determined from one application run can be passed over to a subsequent run with a goal of achieving better performance in terms of throughput or latency. The determined flag values can be simply saved in a text file in a newline separated `<JVM option>=<value>` format. This file can be used with @argfile option to launch the successive application run.
This is how the process would look like:
1. Specify a performance goal while launching training runs - latency or throughput
2. Collect GC data from training runs. Understand and analyze GC data and determine optimal values for GC configuration options in accordance with the specified performance goal. Save the GC options and their values in a text file.
3. Launch the successive application run (i.e. production run) including the saved JVM-options text file as an @ argument
`java @jvm-options.txt application`