As I know JVM before launching a Java application it allocates some piece of RAM for it, and this memory could be controlled by user before launching. But there is another problem when I launch an app it has a different time execution each time.
Here is a very simple example with for loop:
package timespent;
public class Main {
public static void main(String[] args) {
long startTime = System.nanoTime();
int j = 0;
for (int i = 0; i < 1.E6; i++) {
j = i + 1;
}
long endTime = System.nanoTime();
long duration = (endTime - startTime);
System.out.println("duration = " + duration);
}
}
It prints different results:
duration = 5720542
duration = 7331307
duration = 7737946
duration = 6899173
Let's say I want it to be executed exact 10,000,000 nanoseconds or 10 milliseconds.
What do I want?
I want java app to be executed with exact time execution.
Why do I need this?
When I launch an app I want to show exact execution time left on application startup window before it loads all components.
I suppose this is kind of CPU manipulation and I wanted to know if it is possible or not.
Q1: Is it possible in Java?
Q2: If it is not possible in Java then is there any way achieving this by accessing OS native methods. e.g. by prioritizing the Java application or something else?
Q3: How about saving the state of an application to the file and loading it into memory?
There are a number of sources of uncertainty in your time measurement. And all of these sources are not just influencing your measurements, it's the runtime itself that is uncertain. Among the sources of uncertainty are:
Cache usage (what parts of memory are cached within the CPU). Your data can be evicted from the cache by your CPU executing a background task.
Memory placement (is the memory directly connected to the executing CPU core?). This may change over time as your process may be migrated to another core at any time.
Software interrupts (your OS preempting your process to run a different one). Can be somewhat mitigated by running on a quiet machine, but there is no guarantee that you won't get interrupted.
Thermal throttling (your CPU decides that it's too hot and turns down its clock speed). There's really not much you can do about this unless you are prepared to work on some embedded processor with a fixed clock speed.
Hardware interrupts (your network connector received some data from another machine on the internet). You have no influence on when this strikes, whatsoever.
Unpredictable latencies (you are reading some data from disk, but first, the disk has to wait until the data arrives below the reading head). This may follow patterns when you are repeating the exact same actions over and over again, but once you get an unrelated hardware interrupt, this may cause an unexpected delay of
1/7200 rpm * 60 s/min = 8.3 ms.Garbage collection (you are asking about Java, so you have a GC running in the background). Even the best, most modern garbage collectors cannot fully avoid stopping the world from time to time. And even when they don't stop the world, they still run in the background, introducing runtime noise via the cache, memory placement, and software interrupts.
These are probably the most important sources, and there may be others. The point is, your process is never alone on the machine. Unless you run without an OS and disable all hardware interrupts, you just have to live with the fact that your run-times will vary from execution to execution, and there is simply no way to fix that.