Skip to main content

disable JIT Compiler when using reflection?

4 replies [Last post]
jeremygwa
Offline
Joined: 2006-01-17

hello all

I am writing a long running application(server) which uses a lot of reflection for every transaction. Would I get any performance boost by disabling the JIT Compiler?

From my understanding of JIT Compiler, it optimizes methods on the first run slowing things down, after this, it runs faster, as it uses the new native code.

If I am using reflection, will the JIT Compiler optimize reflected calls? Will the JIT Compiler optimize repeatedly on these calls, thus, being a cost to performance?

Thanks in advance for your input
-Jer A

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
linuxhippy
Offline
Joined: 2004-01-07

> From my understanding of JIT Compiler, it optimizes
> methods on the first run slowing things down, after
> this, it runs faster, as it uses the new native
> code.
This has been true a few years ago, before Sun released their Hotspot compiler.
This thing profiles method till a invokation threshold is reached (15.000 calls for the server-jvm) and then compiles the code. This way only methods which are often called become compiled.

> If I am using reflection, will the JIT Compiler
> optimize reflected calls? Will the JIT Compiler
> optimize repeatedly on these calls, thus, being a
> cost to performance?
As far as I understand the new refelction implementation (implemented with java-1.4 and higher) does not differ a lot compared to calling a method directly.
I am sure that the JIT will not compile more often (+ accessors will be compiled too) than when calling the method directly.
I would leave it on, really ;)

However although calls via reflection can be fast, searching methods or classes is (compared) slow.
So if possible cache Method and Class-Objects as much as possible, they are thread-safe anyway.

lg Clemens

briand
Offline
Joined: 2005-07-11

If you ever find a case where turning off the JIT results in better performance, then there's a bug in the JIT and you should let us know about it by submitting a bug or posting something on this forum (former preferred). We can't fix things that we don't know about.

That said, all the standard microbenchmarking cautions and advice apply. It's better to measure using your application than with hand crafted microbenchmarks as it's actually a bit more difficult to write the latter that you might think.

tackline
Offline
Joined: 2003-06-19

I guess the java.lang.Compiler class and java.awt.Toolkit.getToolkit method are a bit misleading.

briand
Offline
Joined: 2005-07-11

With the HotSpot JVM, all the methods of j.l.Compiler are ignored. They are basically stubs, but if you run with
-XX:PrintJVMWarnings, a warning message will be output on each call to each of these methods.

To select which compiler to use with HotSpot, use the command line arguments:

-server -- sever runtime and JIT. Optimized for performance, with the typical time/space tradeoffs that come with such optimizations. -server is the default on server class machines. see: http://java.sun.com/j2se/1.5.0/docs/guide/vm/server-class.html

-client -- client runtime and JIT. Optimized for startup and footprint. -client is the default on 32-bit windows and on client class machines.

-Xint -- interpreter runtime and JIT. Never the default. I would only use this for diagnostic and relative comparison purposes.

Brian