Hi @kaupovoormansik and thanks @gnwiii for the exhaustive explanations.
Some more comments from me (one of the developers of SNAP).
The options intended to be used for Java VM should go into vmoptions file. For example the Xms and Xmx options can’t be set on the command line. The specific gpt options like c and q must be given on the command line and can not be specified the vmoptions file.
But there are other ways to set tile cache size and the parallelisation.
In the etc folder of the SNAP installation directory you find the snap.properties file. Inside you finde sever properties to configure the behaviour of SNAP. The properties can also be specified in the <userdir>/.snap/etc/snap.properties files. The properties int the userdir override the system properties in the installation directory. The same properties can also be specified on the command line when calling gpt, e.g. -DpropertyName=value.
A list of properties can be found in our wiki.
From my experience you can increase the cache size to a value of 75% of the max memory (Xmx) value. Depending on the actual processing the value might vary. In some cases it can be increased up to 90% and sometime a value of 60% is already the limit.
The caching mechanism is pretty simple. If the cache size reaches the limit, the oldest tiles are removed. I think, till a fill level of 70% is reached (not sure about this). That’s roughly how it works. The implementation is not ours. We are using JAI.
If you have enough memory to keep a whole line of tiles it will not have negative effects. But this might change from product type to product type. Some are bigger than others.
This only influence how the VM will try to optimise the compiler output. Several parameters of this type are described on this page. But I usually don’t care much about these very special settings.