JDK version

[sghpjuikit]

Currently supporting JDK 11 and JDK 12.

Ideally we would move to JDK13 only, but Gradle does not support it yet.

We can move to JDK12 only, but I need to be sure the Linux support is there. @Xerus2000 Could you confirm for me JDK12 Linux x64 Hotspot works for you?

Most importantly there are OpenJ9 builds that claim dramatic memory consumption improvements, which is worth checking out. However OpenJ9 does not support VM diagnostics the way we are using them (I had a hunch it was bad idea to go for it...). I'll disable the features locally and test how it works for us.

[xeruf]

unfortunately I have a few other projects on my plate. I do look at your updates, but I can't really contribute rn ;)

[sghpjuikit]

Its enough if you can confirm the JDK to be working for you. For any project.

[sghpjuikit]

Testing of AdoptOpenJDK12Hotspot vs AdoptOpenJDK12OpenJ9

Keep in mind hotspot was run with aggressive settings of "-XX:MinHeapFreeRatio=5" and "-XX:MaxHeapFreeRatio=10". OpenJ9 was left to default gc settings.

1 application memory consumption after starting and running for a while with active playlist/playback

hotspot: 340MB
openJ9: 310MB
openJ9 ("-XX:+CompactStrings"): 275MB

2 application memory consumption after 1 + changing songs few times

openJ9 ("-XX:+CompactStrings"): 345MB, calling gc had no effect
hotspot: oscilating 400-420MB, but seemed to want to go down and after calling gc stable 345MB, though eventually it went up a bit

3 application memory consumption after 1 + browsing through 1000 pictures

openJ9 ("-XX:+CompactStrings"): 500MB, calling gc had no effect
hotspot: 800MB, after gc 600-670MB

Observations:

• great OpenJ9 startup memory consumption.
• OpenJ9 working with images is much easier on memory
• OpenJ9 either does not run gc on System.gc or already has nothing to do
• OpenJ9 gc seems to 'work' out of the box without any aggressive tuning
• OpenJ9 consumes less memory, particularly without calling gc manually, the difference in spikes can be as much as 500MB vs 800MB

[sghpjuikit]

I have decided to remove runtime editing of vm options (VMOptionsPane.kt) as it is not something user should or would be bothered with and because it prevents the use of OpenJ9. a35d509

I have decided to roll with AdopOpenJDK12/13OpenJ9 for the next release, as the memory improvements seem to be worth a lot. 81a8493

I will be dropping JDK11 support. If a problem gets reported where the application can not run/build on Linux with AdoptOpenJDK, this issue will be revisited. This change will be implemented along with fixing the build JVM check *. 81a8493

(*) There is an issue if JAVA_HOME points to unsupported JDK and setting up the projects gets messy, if not impossible. It should be possible to set up a custom JDK for the build in gradle.properties, however this property is ignored in linkJDK task. Fixed in 81a8493

[sghpjuikit]

Nothing is ever easy.

-XX:+CompactStrings (OpenJ9) causes us weird issues with encoding resulting in files with unicode characters not discovered when cmd dir is used. I haven't traced the root of problem, but with Hotspot everything works. This is not cmd related (cmd does return the entries and both /u with UTF-16LE and chcp 65001 with UTF-8 work fine), as the behavior is the same if I redirect cmd to file and read its contents (which is correct), rather the entries get filtered out somewhere in our code, although I'm afraid it will get traced to File.exists calls or wrong hashing.

The paths do get corrupted somewhere, probably unicode characters get interpreted as sets of two characters due to being saved in Latin1 in underlying Stirng array, but why I have no idea... Truly peculiar...