Is there any way to tell the JVM to optimize my code before processing?

Question

I have a method that takes a long time to execute for the first time. But after several calls, it takes about 30 times less time. Thus, in order for the application to respond more quickly to user interaction, I “knead” this method (5 times) with some data examples during application initialization. But this increases the launch time of the application.

I read that the JVM can optimize and compile my Java code for the native, thereby speeding up the work. I would like to know - maybe there is some way to explicitly tell the JVM that I want this method to be compiled when the application starts?

Answer 1

java.lang.Compiler.compileClass

Answer 2

JVM optimizes JiT (Just in Time) at runtime. This means that it can analyze how your code executes and do optimizations to improve performance at runtime. This happens at runtime. If you see that the method accelerates after several executions, this is probably due to JiT optimization (if your analysis is not corrupted and, say, the method becomes faster because the data becomes simpler). If you conduct the analysis correctly, compiling to media may harm you because you can no longer optimize the execution time.

Can I see the method? You may be able to do it faster without worrying about how the JVM works. You must pinpoint where the most expensive operations are. You should also make sure that this is not some sort of garbage collection problem. that is, perhaps this method is accurate, but GC occurs, which means chewing time, and when this is done, your method works at an acceptable speed.

Answer 3

JIT optimization works so well because they optimize what your code actually does, rather than what it can do in different cases.

It is even possible that the JIT code is different from different launches due to different input data. Or even this can be retested more than once when circumstances change.

In other words: without real data, the JVM will not do good performance optimization code. (i.e. it can only perform "static" optimizations)

But in the end, if you get such a high improvement (30x is a lot!), It is likely that he either

• not code, but something else (e.g. file caches or databases)
• very suboptimal code at the source level. (e.g. some heavy calculations that might come out of tight loops)

EDIT:

Looking at your code in a large loop on Literas.prepareLiteras() , you constantly call path.contains(p) with different points, but in the same way. SimplePath.contains() creates a bounding form every time it is called, so you create the same form again and again. This is a prime example of what needs to be pulled out of the inner loop.

I don’t think JIT can optimize this whole method, but in some extreme cases it can convert getShape() to something specialized for one path and recompile for the next path again. Bad use of JVM smarts, huh ??

Answer 4

If you use the Sun JVM, there are different thresholds for compiling the JIT, depending on whether you use the client or server JVM. For the client, this is 1,500 method calls, for the server 10,000. You can change this to a very low value using the JVM -XX:CompileThreshold=100 parameter -XX:CompileThreshold=100 .

Such a low threshold will not benefit your global productivity. I suggest using it only to check if performance improvement affects JIT warming up.

I have never seen a 30-odd improvement by warming up, which was due to JIT optimization. Yet. This has always been associated with some caches.

Answer 5

You can try running this on a 64-bit JVM if you have a 64-bit operating system.

In the Oracle implementation, two versions of the JVM are implemented: the client VM and the server VM. On 32-bit Windows, the default client virtual machine. On 64-bit Windows, VM is used by default.

The difference between the client and server VMs is how they are configured: the server VM does more aggressive optimization (and does it earlier) than the client VM. The server VM has optimized parameters for long-running processes. The client virtual machine has default settings that are optimized for use on a desktop computer: it does less front-end optimization, but starts faster.

I had big differences in speed in intensive computing programs; they sometimes run twice as fast on a 64-bit JVM compared to a 32-bit JVM.

Answer 6

Basically, I would like hvgotcodes, but it’s also possible that the problem is not JVM optimization, but after the first few runs through the data coming from the disk are now in the cache, or that the first few times it still loads and class initialization, but after that they are all in memory.