set -Xmx at run time?

[Kevin]

Hi,

I am thinking whether is that possible (and how to do it) to set the
Xmx at run time?

The reason is:
Since I'd like to distribute the .exe executable rather than the .jar
files, when creating the .exe file (I am using JBuilder, under MS
Win32), it needs to hard code the Xmx parameter. The problem is: I
think it would be very bad to set it to 1000M if the .exe will be used
on a machine with only 512M physical memory (I think Java's lazy memory
collection will wait until it use ups all the 1000M memory before it
starts to collect memory, right?).

So is there any way to "inform" the VM the correct Xmx to use at run
time?

Thanks.
Kevin

 

[Roedy Green]

So is there any way to "inform" the VM the correct Xmx to use at run
time?

This question has come up several times in the recent past. You might
see if you can find the original threads.

the simplest solution is to use JAWS. You can then specify the parms
individually for each version of the JVM.
see http://mindprod.com/jgloss/javawebstart.html

You can use bat file or small C file kicker.
See http://mindprod.com/projects/kicker.html

 

[Andrew Thompson]

The reason is:
Since I'd like to distribute the .exe executable rather than the .jar
files,

That is a rather poor reason, as it happens.

..when creating the .exe file (I am using JBuilder, under MS
Win32),

Are every one of your end users using MS/Win 32?

..NET is an excellent development environment for that
particular combination.

Whereas if you wish to support a single (or more)
Linux/Mac user, now, or at some ill defined point
in the future, an X-plat language such as Java
is the obvious choice - with the obvious (and better
than a '.exe') deployment method of JWS (Java Webstart).

Not only does JWS deploy to end users directly off the net,
it also lowers mainenance costs by ensuring the users are
always getting the latest version of the application.

..it needs to hard code the Xmx parameter. The problem is: I
think it would be very bad to set it to 1000M if the .exe will be used
on a machine with only 512M physical memory (I think Java's lazy memory
collection will wait until it use ups all the 1000M memory before it
starts to collect memory, right?).

You can offer JNLP files with a variety of minimum
memory specified (one per JNLP file) - then you can
leave it to the end user to 'select the option' that
works for them.

Easy peasy.

...Roedy mentioned it, I just thought I'd expand on why JWS
makes so much sense for deployment of the vast majority of
Java based software.