CODEWITHSUNDEEP
javajvmjit
ZiviMagic
ZiviMagic

Reputation: 1054

Dynamically loading Jar file in java

I have been reading a lot about the JIT and the JVM and I am trying to figure out something, I hope someone can help.

When we write a java program that includes an external JAR, For example: ExternalJar.jar containing:

ClassA.class
ClassB.class
ClassC.class

Questions:

  1. If the JAR is never used: Will the JIT still compile the classes contained in the JAR to machine code in the initialization phase (first phase of the JVM running the app)? Or like DLLs the JARs are loaded during run time only if we actually called a method from one of the classes in the JAR?

  2. If the answer to 1. was when we actually called a method from one of the classes in the JAR: What is then the benefit of using the JIT then? The JIT is supposed to improve run time by doing the heavy lifting during the application start up phase.

  3. Does the JIT has to compile all the classes in the JAR, for example if we use:

    ClassB.MethodB();

will ClassA and ClassC will be compiled as well because they are in the same JAR?

  1. What about the rt.jar containing the basic java framework classes: for example if I call:

    System.out.println("");

Will the System.class also be compiled to machine code (whether at start up at run time or when we actually call the method during run time) or is there some sort of already cached machine code for these classes?

Thanks

Upvotes: 3

Views: 1286

Answers (2)

Jamsheed
Jamsheed

Reputation: 47

If the JAR is never used: Will the JIT still compile the classes contained in the JAR to machine code in the initialization phase (first phase of the JVM running the app)? Or like DLLs the JARs are loaded during run time only if we actually called a method from one of the classes in the JAR?

ANS:JARs are loaded run time only, even class from JAR is loaded first time the class in referenced. method compilation usually happen based on hotspot principle.

If the answer to 1. was when we actually called a method from one of the classes in the JAR: What is then the benefit of using the JIT then? The JIT is supposed to improve run time by doing the heavy lifting during the application start up phase.

ANS:JIT usually compile heavily used method. this heavy usage is determined from runtime information. JIT dosent decrease startup time.

Does the JIT has to compile all the classes in the JAR, for example if we use:

ANS: NO

ClassB.MethodB(); will ClassA and ClassC will be compiled as well because they are in the same JAR?

ANS NO

What about the rt.jar containing the basic java framework classes: for example if I call:

System.out.println(""); Will the System.class also be compiled to machine code (whether at start up at run time or when we actually call the method during run time) or is there some sort of already cached machine code for these classes?

ANS: NO, JIT Compile only highly used method. it doesn't compile all other method in same class.

Upvotes: 0

BillRobertson42
BillRobertson42

Reputation: 12883

In past experience, the JVM will not attempt to compile a class until needed. If a class refers to another class then that other class will also be compiled. Where it is located in the classpath, Jar A or Jar B is not relevant to compilation. Despite the long history of changes to how things work in the JVM, I think this is still true today.

Classes like System are pretty central, so they will end up being compiled pretty much straight away. JVM startup time isn't as bad as many make it out to be, but that doesn't mean that the applications that they're running have good startup time.

In the traditional JIT (the client VM), the JVM would only ever execute code that had been JIT compiled, and it did not need to compile the entire application to begin execution (JIT stands for Just in Time). The JIT compiler produced decent executable code, but not great executable code.

Then hotspot came along (the server VM). The JVM would begin by interpreting bytecode and also begin analyzing conditions at runtime to figure out what to compile. Because it did not need to compile code to run it, it could begin execution more quickly, and since it did not need to wait for compilation and because it was aware of runtime conditions, it could afford to be more aggressive with optimizations. So the hotspot compiler produces faster code. The downside is that in the beginning it executed more slowly because it was executing interpreted code. Hotspot continues to analyze after compilation so methods that get called a lot (hotter ones), can be compiled again with yet more aggressive optimizations.

For a long time, the JVM would start by default in client mode, and you had to explicitly start it in server mode. Some JRE's did not even ship with a server mode (e.g. windows) though their corresponding JDK's did. As machines got more powerful this did not make sense any more, so the JVM would use some heuristics to figure out if it should start in server mode or client mode.

Then, beginning in Java 7, Oracle introduced mixed mode. Which allowed, as far as I understand, would allow it to JIT compile code in the beginning (making for better start up performance), and then Hotspot would kick in as needed.

As to whether or not there is a cache of system classes. I think they experimented with this feature at some point in the past, but it did not make things faster, so AFAIK this does not occur.

edit It looks like class sharing is still a thing. http://docs.oracle.com/javase/6/docs/technotes/guides/vm/class-data-sharing.html

Upvotes: 3

Related Questions