I want to modify the default jvm setting, like gc policy and Xmx.
Because of some reason, I can't modify the starting command of java program to add these setting.
Is there any ways to do that?
Thanks.
[updated]
Sorry I didn't describe it clearly.
It is something like server side job program which is started from another server program. Because of the default Xmx is too big(on 64 bit server), minor GC time is too long, almost 1 second. So I want to change the default GC policy to test.
And for now, the server program can't be modified.
You can have the Java program relaunch itself. You can have a bootstrap main which is called first. It then does a Runtime.exec(...) with the command line option you require running a different Class.main() which is the actual program.
Short answer: with your requirements you can't do this.
Theoretically you have 2 possibilities:
Provide settings via comand line options:
I can't modify the starting command of java program to add these setting
Change settings at run time:
But it's impossible
Related
I have situation where I start JDK18 jvm from c++ code to produce vst plugin goal being to implement audio signal algorithms in java side with added value of full java GUI api. My framework works very smoothly apart from the repeatable state where my audio streaming crashes after 14 hours. So I thought this is good place to start learning JFR. My jvm starting parameters are in xml file and relevant part is:
<param>
-XX:StartFlightRecording,dumponexit=true,filename=c:/out/blackbox.jfr
</param>
Even when application exits that named file keeps empty. So what is the idea of filename parameter if it stays empty and how to use it?
The recording is dumped in a Java shutdown hook. If you terminate the C++ application with exit(status), the Java hook never gets a chance to run.
Not sure how to best run the shutdown hooks, but you could perhaps invoke System.exit(status) from native using CallStaticVoidMethod?
My solution with JDK 18 and flight recorder is not to use JVM startup options at all but instead use jcmd's JFR commands. This is due to incompatible JVM options at startup and lacking documentation. Available documentation is clearly for some older versions of JVM. Here is the available documentation:https://docs.oracle.com/javacomponents/jmc-5-5/jfr-command-reference/toc.htm which proposes use of -XX:+UnlockCommercialFeatures which has been long gone. What is current state of command line options is not achieveable for average programmer.
But "jcmd JFR.start" is example of things that work. I got things working observing with "jcmd PID JFR.check" . It is obvious that JFR api is also little bit broken and needs to addressed in a certain way to get the wanted results. There must have been very hurry when implementing it because the order of parameters is very crucial. And there is a nag that "name" must not be a number even it uses it as number. Now I know it is sensitive. So the way I want it to function is to sample and dump periodic chunks so that differences reveal them selves. Now I have the solution to that but it needs another question with no stupid complaints. Baseline is that jcmd with JFR parameter must be used as it comes out of the box in the way which is not obvious.
Is there a way to identify the JVM's default time zone without running a Java program on it? Are there any commands available using which I can take a look at it?
Yeah we all know what jvm is , but maybe author want to know what is a default timzeone of running jvm without restarting it and deploying code on it.
In such case you could maybe check command line of java process for properties (user.timezone) or connect to jvm via some tool like visual vm and check this property, I am not sure if there is some other way to do that.
If you have remote debugging enabled then it should be easier as you can connect via your favourite ide/tool and just evaluate default timezone.
I would like to modify/set JVM flags as soon as my program starts. I cannot do it on the command line, because I work with people who don't even know that exists. So it has to be automatically done in the program.
I am particularly interested by these three flags: -Xms4G -Xmx8G -noverify
I found in this discussion (or that one) that it is possible to modify some flags using the Interface HotSpotDiagnosticMXBean. And this code shows how to modify the flags. Unfortunately, the flags Xms or just ms are not recognized and then an exception is thrown.
I've also found that capsule may do the work, but it seems pretty heavy to use.
Is there any easy way to do it?
You need to write two programs: one that is just a launcher to provide the correct parameters to run your other program. This is how Eclipse works, and Jitsi, and the now-end-of-life InstallShield Multiplatform launchers. It may be that you can write a trivial (eg one line or close to it) shell, .bat, or VBS script to do the job.
Hi I need to see eclipse's running configuration in a simple java project. for example print them as key value pairs at console would be enough
[EDIT]: the reason for this
I added a parameter to eclipse.ini but I'm not sure about the value whether it is passed as I expect or not
and the parameter I'm looking for is
-Dorg.eclipse.swt.browser.XULRunnerPath=xulrunner
You have two ways for getting the details
http://www.mkyong.com/java/how-to-list-all-system-properties-key-and-value-in-java/
In case it is java parameters
Read Java JVM startup parameters (eg -Xmx)
From your updated response.
I will suggest that you check your memory manager.
In windows that will be task manager
mac that will be Activity Monitor
on linux you can fire top command from command line
Still not satisfied, check over this StackOverflow thread
Monitoring own memory usage by Java application
Still not satisfied. I would suggest profiling of the application using yourkit profiler or any other java profiler.
When you start yourkit it shows the java applications running. Simply click on one of it and it will initate profiling for you.
Eclipse runs on a JVM, which is not the same JVM where your program will run.
It would be easier to find the configuration file (eclipse.ini I guess is what you are looking for), since they will not be environment settings for the JVM where your code will run.
all runtime configuration endsup being a java argument or a system property passed
so you can print all the commandline argument passed in to java + all the System properties and its values (may be with filtered set of key value based on your interest)
I have an application that has a license for a set number of cpus and I want to be able to set the number of cpus that java runs in to 1 before the check is done. I am running Solaris and have looked at pbind but thought that if I started the application and then used pbind it would have checked the license before it had set the number of CPUs that java could use.
Does anyone know a way of starting an application with a set number of CPUs on Solaris?
It is a workaround, but using Solaris 10 you could set up a zone with a single CPU available and then run the application inside that zone.
If you want to do testing without running the full application, this bit of Java is most likely what they are using to get the number of CPU's:
Runtime runtime = Runtime.getRuntime();
int nrOfProcessors = runtime.availableProcessors();
A full example here.
This isn't a complete solution, but might be enough to develop into one. There's definitely a point at which the java process exists (and thus can be controlled by pbind) and at which point it hasn't yet run the code to do the processor check. If you could pause the launch of the application itself until pbind had done its work, this should be OK (assuming that the pbind idea will work from the CPU-checking point of view).
One way to do this that should definitely pause the JVM at an appropriate place is the socket attach for remote debuggers and starting with suspend mode. If you pass the following arguments to the java invocation:
-Xdebug -Xrunjdwp:transport=dt_socket,address=8000,suspend=y,server=y
then the JVM will pause after starting the java process but before executing the main class, until a debugger/agent is attached to port 8000.
So perhaps it would be possible to use a wrapper script to start the program in the background with these parameters, sleep for a second or so, use pbind to set the number of processors to one for the java process, then attach and detach some agent to port 8000 (which will be enough to get Java to proceed with execution).
Flaws or potential hiccoughs in this idea would be whether running in debug mode would notably affect performance of your app (it doesn't seem to have a big impact in general), whether you can control some kind of no-op JDWP agent from the command line, and whether you're able to open ports on the machine. It's not something I've tried to automate before (though I've used something broadly similar in a manual way to increase the niceness of a Java process before letting it loose), so there might be other issues I've overlooked.
I think the most direct answer to your question is to use pbind to bind the running shell process, and then start Java from that shell. According to the man page the effects of pbind are inherited by processes that are created from a bound process. Try this:
% pbind -b 0 $$
% java ...
Googling over, I found that you are right, pbind binds processes to processors.
More info and examples at: http://docs.sun.com/app/docs/doc/816-5166/pbind-1m?a=view