It is good to know, that is working for you. I have no doubts, that you used recommended by oracle and prefered way to install java for your system. Still it doesn't means that my jre incomplete or something like that. More likely is vice versa. By installing as per oracle instructions, you have more targeted and likely less in size jre. As you might suspected, I have extracted jre from oracle distributed tarball release ejdk-8u65-linux-arm-sflt.tar.gz. This way I have full jre, with all possible VM's. I just missed to regenerate shared archive after extraction, which is a part of standart installation procedure.
When the JRE is installed using the installer, the installer loads a set of classes from the system jar file into a private internal representation, and dumps that representation to a file, called a "shared archive". If the JRE installer is not being used, this can be done manually, as explained below. java -Xshare:dump (for record)
The benefit of my method is that I can install java on my NAS in less than 30 seconds, instead of dowloading it to host PC, build java there and then copy to NAS. Plus I always have full jre.
It doesn't matter after all how do I install java. It runs and I can run serviio. What matters is that serviio uses two command line arguments, which contrary to each other.
From the same oracle link above:
Class data sharing is supported only with the Java HotSpot Client VM, and only with the serial garbage collector
So, it seems wrong way to use both -XX:+UseG1GC and -Xshare:on at the same time.
That is why I leaved question regarding garbage collection open. By the way, G1GC used by serviio start script in not available in ejdk-8u65-linux-arm-sflt.tar.gz release.
Check yourself norm:
java -XX:+UseG1GC -version
I just wanted to attract serviio developer attention, that G1GC garbage collector is not available for softfloat armv5 and -Xshare:on is useless when -XX:+UseG1GC is used. -Xshare:auto is more generic way, because -Xshare:on can prevent serviio from starting in some cases.
P.S. This might be not related with killeriq serviio startup issue. As I said already, the second reason can be missing dependencies:ffmpeg and so on.