Improve launcher parameters, remove unused and unnecessary ones

[deathbeam]

-XX:+UseConcMarkSweepGC

    Enables the use of the CMS garbage collector for the old generation. Oracle recommends that you use the CMS garbage collector when application latency requirements cannot be met by the throughput (-XX:+UseParallelGC) garbage collector. The G1 garbage collector (-XX:+UseG1GC) is another alternative.

    By default, this option is disabled and the collector is chosen automatically based on the configuration of the machine and type of the JVM. When this option is enabled, the -XX:+UseParNewGC option is automatically set and you should not disable it, because the following combination of options has been deprecated in JDK 8: -XX:+UseConcMarkSweepGC -XX:-UseParNewGC.

So, we can safely replace

"-XX:+UseConcMarkSweepGC",
"-XX:+UseParNewGC"

with -XX:+UseG1GC

These options were included in the previous release, but have since been considered unnecessary.

-Xincgc

    Enables incremental garbage collection. This option was deprecated in JDK 8 with no replacement.

This can be removed as well, G1 will be enough.

-Xsssize

    Sets the thread stack size (in bytes). Append the letter k or K to indicate KB, m or M to indicate MB, g or G to indicate GB. The default value depends on virtual memory.

I would say we can trust defaults?

-Xmx256m

Same here:
https://docs.oracle.com/javase/8/docs/technotes/guides/vm/gctuning/parallel.html#default_heap_size

Seems like with 1GB of memory it will be same result, and with more memory it will increase.

-XX:CompileThreshold=1500

-XX:CompileThreshold=invocations

    Sets the number of interpreted method invocations before compilation. By default, in the server JVM, the JIT compiler performs 10,000 interpreted method invocations to gather information for efficient compilation. For the client JVM, the default setting is 1,500 invocations. This option is ignored when tiered compilation is enabled; see the option -XX:+TieredCompilation. The following example shows how to set the number of interpreted method invocations to 5,000:

    -XX:CompileThreshold=5000

    You can completely disable interpretation of Java methods before compilation by specifying the -Xcomp option.

Based on that one the default value is already 1500, can be removed.

-Dsun.java2d.noddraw=true

https://www.reddit.com/r/2007scape/comments/6oflhm/how_to_improve_your_actual_fps_on_osrs_default/

Based on that, setting that to false is obvious choice. The issue what made the decision to switch it to true was rare scenario, and this affects larger portion of userbase.

[deathbeam]

For reference: https://docs.oracle.com/javase/8/docs/technotes/tools/windows/java.html

[abextm]

I'm not sure that we should be using the G1 collector. It seems to be tuned (by default) for larger (>20gb) heaps with pause times ~50ms. From some things I've read it seems we should keep using CMS/ParNew or try to tune G1 for lower (<5ms) latency on a newer JVM.

http://mail.openjdk.java.net/pipermail/jdk9-dev/2017-April/005744.html

[deathbeam]

By following that mailing thread it looks like there have been significant improvements to G1 in Java 9 and looks like there are plans to either deprecate or remove CMS in future and G1 should be it's full replacement, so might be worth looking into. I found this tuning guide that might be enough to optimize it for our use: https://docs.oracle.com/javase/9/gctuning/garbage-first-garbage-collector-tuning.htm

[abextm]

Researching more, Shenandoah looks very promising for our use case. We would have to build/update our own JRE, which is unfortunate though.