Modify JVM args from inside the JVM

Question

Is there a way to modify the jvm args from inside of the jvm? Specifically, I want to be able to change the maximum heap size of the jvm from inside of it. Is this possibl

Answer 1

(Years later), I found a library that accomplishes what I needed at the time I posted. Akuma is a library for daemonizing Java processes. It allows restarting the JVM with new arguments.

The difference between using this and launching a new process with a bootstrap is that stdin/stdout and other file descriptors are automatically shared.

Answer 2

Specifically, I want to be able to change the maximum heap size of the jvm from inside of it. Is this possible?

No.

Answer 3

This is a halfway-serious, completely-off-the-wall hack-thought:

...what if you spawned a new instance of java (with the new settings) from the current jvm then killed the old process from the new? I have no idea if this will help or not (or even work)...

Answer 4

With JRockit you can at least suggest a heap size.

JVMFactory.getJVM().getMemorySystem().suggestHeapSize(100*1000*1000);

See JMAPI for more information

Answer 5

As noted by others, this is generally only possible by having a bootstrap program (Java or other language) that invokes the main JVM with the right parameters.

That said, are you sure this is necessary? You mention "maximum heap size". If you are referring to the -Xmx parameter: This is just a limit the VM may never exceed. It does not mean the VM will really use that much, it will do with less if it can.

So you can always set -Xmx to the maximum the system can handle, and let the JVM decide how much it really needs. Why do you think you need to set it dynamically?

Answer 6

Dynamically setting -Xmx for instance would be very helpful for controlling projected system resources (primarily footprint) for long running runtimes. One of many ramifications of course is bigger/longer GC overhead.

I know several large server machines running dozens and dozens of 1G+ heap JVMs. If these runtimes could have their high water mark scaled back during low-use times then you could hard manage your system resources much better.