Learn how easy it is to sync an existing GitHub or Google Code repo to a SourceForge project! See Demo
I *really* like the ability to indicate min/max heap as a % of memory. It is a very important feature for our application. However I just discovered a major problem with it: It does not take into account the Windows XP 2GB-per-process maximum.
So if you have a machine with over 2GB of memory (e.g. 4GB, which is common with our customers) & specify a large max heap % (e.g. 80%), when you try to launch the exe the process will be immediately killed by Windows with no warnings/errors/notice.
On the other hand, if you specify a smaller %, it will seriously limit the heap available on machines with 2GB or less...
Net net, it should really be "% of memory up to the per-process maximum (heap + runtime combined)"
Note: I already know about the 3GB-per-process Windows switch. This is not a universal solution since it causes problems on some machines (e.g. video driver conflicts).
Any chance this could get fixed relatively quickly??
I fixed it, though the maximum heap size for 32-bit JREs (1500 MB) might require some tweaking. On Vista x64 I was able to set -Xmx1516m for all runtime versions. The 64-bit JRE 1.6.0_10 accepted any value so the limit is applied only to 32-bit. You can see the results using --l4j-debug command line option.
You'll have to get the head directory with the object files from CVS before the release.
Thank you for Launch4j! It is great, but this issue is still here in v. 3.0.1 in year 2010.
Now in 2010 many people have a google of RAM (more than 2-3 Gb of memory as am I), and this issue is very actual.
if you have fixed this issue, maybe you can build and release Launch4j 3.0.2? It's very important for many applications.
Hi! This was added to the 3.0.2 release, use the debug option to verify it.
The <maxHeapPercent> element is a great idea! I tried it with a value of 100 under a Windows XP PC with 4GB of RAM.
Miserably, my application couldn't run under JRE 1.6.0_43. After trying various -Xmx values in the accompanying l4j.ini file, I found out that the upper limit was 1474 and not 1500. Could you check again if 1500 is supposed to always work? Maybe it's an issue with recent JREs.
Thanks again for your great product. :-)
Fixed in 3.1.0-beta2, this limit was reduced to 1GB.
After doing more tests on my side, I discovered that my application could run safely in 32 bit only if -Xmx is set to a value around 700 MB (I used 640 MB for more safety). This is probably due to the use of Java 3D native DLLs coming with the program.
To avoid you to adjust the 32 bit limit again and and as this may depend on the application, could you add a new <maxHeapSize32bit> element in launch4j configuration file?
For less work, I don't mind if the value of this element is not editable through the user interface.
Yes, it seems this is the only way out of it.
I moved this to the feature request so it doesn't get lost.