Client heap will not grow over init heap size

[Florian_Marquardt]

Hi.

We have the following line in our JNLPX Files
<j2se version="17.0*" initial-heap-size="64m" max-heap-size="2g" java-vm-args="-XX:+UseShenandoahGC -XX:ShenandoahGCHeuristics=compact -XX:ConcGCThreads=2 --add-opens=java.desktop/java.awt.dnd=ALL-UNNAMED" />

And we are tracking the client side memory. The Initial Heap size work but the heap is not growing. This means in a lot of cases the Client will run GC Cycles in order to maintain the Heap lvl.

I found in the documentation this:
java-vm-args=" -Xmx512m -Xms128m

Should it be better done this way?

Thanks
Florian

[Janak Mulani]

OWS translates initial-heap-size to -Xms and max-heap-size to -Xmx.

OWS ignores all jvm args specified in the jnlp if anyone of them is not in the list of its secured jvm args or in the jvm args whitelist specified in the deployment.properties file. You can check the OWS stage1 log for a message indicating if OWS found an illegal jvm arg and hence it is ignoring all args.

You can see the jvm args with which OWS starts the JVM that will run the Jnlp application towards the end of the OWS stage1 logfile.

[Florian_Marquardt]

ok found it. there is looks good
"C:\Program Files\Eclipse Adoptium\jre-17-ows\bin\java.exe" "-Xbootclasspath/a:C:\Program Files\OpenWebStart\openwebstart.jar" -Dicedtea-web.bin.location=C:\Program Files\OpenWebStart\javaws -Xms64m -Xmx2g -XX:+UseShenandoahGC -XX:ShenandoahGCHeuristics=compact -XX:ConcGCThreads=2 --add-exports=java.base/sun.net.www.protocol.jar=ALL-UNNAMED,java.desktop --add-exports=java.base/jdk.internal.util.jar=ALL-UNNAMED,java.desktop --add-exports=java.base/com.sun.net.ssl.internal.ssl=ALL-UNNAMED,java.desktop --add-reads=java.naming=ALL-UNNAMED,java.desktop --add-exports=java.desktop/sun.awt.X11=ALL-UNNAMED,java.desktop --add-exports=java.desktop/sun.applet=ALL-UNNAMED,java.desktop,jdk.jsobject --add-exports=java.base/sun.security.action=ALL-UNNAMED,java.desktop --add-reads=java.base=ALL-UNNAMED,java.desktop --add-exports=java.base/sun.net.www.protocol.http=ALL-UNNAMED,java.desktop --add-exports=java.naming/com.sun.jndi.toolkit.url=ALL-UNNAMED,java.desktop --add-exports=java.base/sun.security.util=ALL-UNNAMED,java.desktop --add-reads=java.desktop=ALL-UNNAMED,java.naming --add-exports=java.desktop/sun.awt=ALL-UNNAMED,java.desktop --add-opens=java.desktop/java.awt.dnd=ALL-UNNAMED --add-exports=java.base/sun.security.x509=ALL-UNNAMED,java.desktop --add-exports=java.desktop/javax.jnlp=ALL-UNNAMED,java.desktop --add-exports=java.base/sun.security.provider=ALL-UNNAMED,java.desktop --add-exports=java.base/sun.security.validator=ALL-UNNAMED,java.desktop net.sourceforge.jnlp.runtime.Boot -Xnofork jnlps://.....

But did you ever had such a case, that the heap refuses to grow?

[Janak Mulani]

Hi Florian,

Firstly you can post on the private forum for Dachser: viewforum.php?f=35

No one has reported a case like yours where the heap does not grow. Do you see this problem with your app when you start the app from command line using the command in your above post and the profiling the jvm?

.

[Florian_Marquardt]

Hi Florian,

Firstly you can post on the private forum for Dachser: viewforum.php?f=35

No one has reported a case like yours where the heap does not grow. Do you see this problem with your app when you start the app from command line using the command in your above post and the profiling the jvm?

.

i will try