Serviio not runs with latest java 8u65

System info:

Linux NSA310 2.6.31.8 #2 Fri Aug 2 11:21:44 CST 2013 armv5tel GNU/Linux
Processor : Feroceon 88FR131 rev 1 (v5l)
BogoMIPS : 1199.30
Features : swp half thumb fastmult edsp
CPU implementer : 0x56
CPU architecture: 5TE
CPU variant : 0x2
CPU part : 0x131
CPU revision : 1

Hardware : Feroceon-KW
Revision : 0000
Serial : 0000000000000000

java version "1.8.0_65"
Java(TM) SE Embedded Runtime Environment (build 1.8.0_65-b17, headless)
Java HotSpot(TM) Embedded Client VM (build 25.65-b01, mixed mode)

Problematic are these serviio command line args:
1. -XX:+UseG1GC
This one lets serviio to run, but generates warning:

Java HotSpot(TM) Embedded Client VM warning: G1 GC is disabled in this release.

2. -Xshare:on
This one prevents serviio from starting and generates error:

Error occurred during initialization of VM
Unable to use shared archive

Any suggestions? Temporary workaround for me is to remove -XX:+UseG1GC totally from serviio command args and change -Xshare:on to -Xshare:auto.

Edit: nevermind regarding -Xshare:on. Solved it with

  Code:

java -Xshare:dump

http://docs.oracle.com/javase/8/docs/technotes/guides/vm/class-data-sharing.html#skip2content
But the question, regarding what garbage collector should be used in Embedded Client VM, is still open

The same issue was reported here:
http://forum.serviio.org/viewtopic.php?f=5&t=21223

[jhb50]

It runs fine with java 8 R66 on windows. Linux R66 is here. https://www.java.com/en/download/manual.jsp

Thanks for links my friend, but you have misread, what I wrote.
Embedded java is platform specific (in my case it is armv5 softfloat) and has different release plans comparing with x86 or x64 architecture platforms.
It is arm based NAS, not windows, with specific java softfloat arm version (btw-Linux, so partly you hit) running.
8u65 is latest version for my architecture at the moment. And believe me, I know where and how to download it.

Hi barmalej

No problems here. I am running the latest Oracle Java SE Embedded Version 8 Update 65 ejdk-8u65-linux-arm-sflt.tar.gz. Please can you try the java build process using jrecreate as per outlined here: http://forum.nas-central.org/viewtopic.php?f=249&t=16763 and let me know you results. I am guessing that your jre install is not complete. Thanks

[jhb50]

Ah so maybe title should read...

Hi norm,

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)

Taken from:
http://docs.oracle.com/javase/8/docs/technotes/guides/vm/class-data-sharing.html#skip2content
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:

  Code:

java -XX:+UseG1GC -version

@jhb50. You are right. Topic title doesn't corresponds conversation anymore. I would be glad, if I could change it. I just wanted to attract ZIP 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.

By the way, G1GC used by serviio start script in not available in ejdk-8u65-linux-arm-sflt.tar.gz release.
Check yourself norm:

  Code:

java -XX:+UseG1GC -version

Hi Barmalej

Glad to hear that your figured out what was going wrong. Yes you are correct java -XX:+UseG1GC -version produces the same error message from java

  Code:

Java HotSpot(TM) Embedded Client VM warning: G1 GC is disabled in this release.

Perhaps we should log an Issue in Bitbucket and let Zip look in to it . We aren't going to be only people using Oracle Java SE Embedded Version 8 on ARM, there will be Synology and QNAP NAS' running ARM, this will affect them too.

I don't think it is neccessary Norm. You can safely remove -XX:+UseG1GC from start script and let java VM to choose auto garbage collector. I just wanted to know, which one garbage collector is preffered and best to use with serviio, when G1GC is not available.

Java HotSpot(TM) Embedded Client VM warning: G1 GC is disabled in this release.

This is just warning not error.
The true evil is -Xshare:on, which can prevent serviio from starting in some cases, when shared archive for class data sharing is not regenerated. And this not my case specific. Google and you will see, that even some linux distro had problems with java class data sharing. Imho, it should be -Xshare:auto, which is default setting for java. In this way, it will not prevent serviio startup, even shared archive for class data sharing is not regenerated.