In most of our installations we use the following parameter to specify the max heap size:
# LAX.NL.JAVA.OPTION.JAVA.HEAP.SIZE.MAX # ------------------------------------- # the maximum heap size for the Java VM lax.nl.java.option.java.heap.size.max=1024m
It has some strange behavior if it comes to higher values, following are some examples:
wrong behavior - passing on NO value: lax.nl.java.option.java.heap.size.max=2048m (and ongoing till 4096m) lax.nl.java.option.java.heap.size.max=4g cmd: "…\jre\bin\java.exe" -Xms10485760 -classpath …
wrong behavior - passing on wrong values: lax.nl.java.option.java.heap.size.max=4097m cmd: "…\jre\bin\java.exe" -Xms10485760 -Xmx1048576 -classpath… ongoing values passing on the value minus 4GB lax.nl.java.option.java.heap.size.max=4296015872 cmd: "…\jre\bin\java.exe" -Xms10485760 -Xmx2147483647 -classpath…all values over 2GB passing on 2GB
The following parameter has no problems with any of the above.
# LAX.NL.JAVA.OPTION.ADDITIONAL # ----------------------------- # Behebt eventuelle Probleme mit der 3D-Darstellung und PC-Anywhere
lax.nl.java.option.additional=-Xmx4g
Why is there a interpretation of the given value and not a simple passing through? Does the first parameter have any benefits or should we generally use the additional parameter?
Edit: Tested on a 64Bit machine with an pure 64Bit Windows Installer (also tested with 64Bit and 32Bit installer ... but there are obvious other limitations)
Yes this has confused me as well. Looks like the limit is the limit for a java int.
I think this should be fixed as a product defect. Either Abandon use of lax.nl.java.option.java.heap.size.max and lax.nl.java.option.java.heap.size.intial and expect the values set in lax.nl.java.option.additional Or Interpret the values properly and cope with "k", "K", "m", "M", "g" , "G" (as specified in the commands for java.exe) and have no upper limit.
