Is there a state variable in Java with zero startup time (without recompiling)?

I am looking for a way to provide the fastest (I mean zero time - compilation / loading of classes / time with JIT delay) maybe on / off flag for if state. Of course, this condition will be changed only once per application launch - at startup.

I know that the "compile-time constant if conditions" can be compiled with the condition, and the whole state can be removed from the code. But what is the fastest (and possibly simplest) alternative without having to recompile sources?

Is it possible to move a condition to separate .jar into one class and a method with a condition where I create two versions of this .jar , and will these versions swtich in the classpath when the application starts? Will JIT delete a method call in a separate .jar if it detects that this method is empty ?

Can I do this by providing two classes in the classpath that implement "ClassWithMyCondition", where one of these classes will have a real implementation, and the second will only have an empty method and instantiate one of them using Class.forName and .newInstance() ? JIT removes an empty method call from my main looped method?

What could be the simplest bytecode management solution for this problem?

+6
source share
5 answers

You can pass custom values โ€‹โ€‹on the command line and then check that value once. So there is something like this in your code:

 final static boolean customProp = "true".equalsIgnoreCase(System.getProperty("customProp")); 

Depending on the command line options, the static final value will change. This will set to true :

 java -DcustomProp="true" -jar app.jar 

So far, this value will be set to false :

 java -jar app.jar 

This gives you the benefits of static final boolean , but allows you to change the value without recompiling.


[change]

As pointed out in the comments, this approach does not optimize compilation time. The static final boolean value is set on class loading and does not change from there. The "normal" byte code execution will probably need to be evaluated by each if (customProp) . However, JIT occurs at runtime by compiling the bytecode to its own code. At this point, since the bytecode has a run-time value, more aggressive optimizations are possible, such as embedding or excluding code. Please note that you cannot accurately predict whether or not there will be JIT.

+3
source

The standard way to do this logic is to create an interface for the required functions, and then create two (or more) implementations for this function. Only one of the implementations will be loaded into your runtime, and this implementation can make the assumptions necessary to completely eliminate the if condition.

This has the advantage that each implementation is mutually exclusive, and things like the JIT compiler can ignore all useless code for this particular run.

+11
source

Here is the simplest solution. Do not make excessive efforts for yourself.

Just put the final static boolean , which is not a compile-time constant (as defined in JLS), and reference it wherever you want conditional compilation. The JVM will evaluate it the first time it sees it, and by the time the code receives a JIT, the JVM will know that the value will not change and can then delete the check, and if false , block.

Some sources: Oracle has a wiki page in performance techniques that states that it is possible to use constants (note that the JVM / JIT compiler is in this context, so the final field is considered constant, even if it is not a JLS standards compile time constant) . This page refers to a tactical index adopted by the JIT, which mentions techniques such as constantly folding and rewriting a stream, including removing dead code.

+7
source

you must load the value from the properties file so that you cannot recompile every time it cahnges. Just update the text file and the next time you start the program, it uses the new value. Here is an example I wrote a long time ago:

https://github.com/SnakeDoc/JUtils/blob/master/src/net/snakedoc/jutils/Config.java

+1
source

JIT recompiles the code every time it runs. You do it already, whether you know it or not. This means that if you have a field that, according to JIT, has not been changed (it does not even have to be final), it will be included, and the verification and code will be optimized.

Trying to exit smart JIT is becoming more difficult over time.

0
source

Source: https://habr.com/ru/post/956671/


All Articles