This website uses cookies. By clicking Accept, you consent to the use of cookies. Click Here to learn more about how we use cookies.
Turn on suggestions
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
- Revenera Community
- :
- InstallAnywhere
- :
- InstallAnywhere Forum
- :
- Lax Files - Java Max Heap Configuration
Subscribe
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Subscribe
- Mute
- Printer Friendly Page
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
Jul 05, 2014
04:37 AM
Lax Files - Java Max Heap Configuration
Hello there,
In most of our installations we use the following parameter to specify the max heap size:
It has some strange behavior if it comes to higher values, following are some examples:
Works fine:
lax.nl.java.option.java.heap.size.max=1024m
cmd: "…\jre\bin\java.exe" -Xms10485760 -Xmx1073741824 -classpath …
lax.nl.java.option.java.heap.size.max=2047m
cmd: "…\jre\bin\java.exe" -Xms10485760 -Xmx2146435072 -classpath …
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.
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)
Greetings
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:
Works fine:
lax.nl.java.option.java.heap.size.max=1024m
cmd: "…\jre\bin\java.exe" -Xms10485760 -Xmx1073741824 -classpath …
lax.nl.java.option.java.heap.size.max=2047m
cmd: "…\jre\bin\java.exe" -Xms10485760 -Xmx2146435072 -classpath …
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)
Greetings
(1) Reply
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
Mar 13, 2015
05:32 AM
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.
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.