Oracle Hotspot JVM: typically, which operations are especially valuable to the CPU?

Question

I would like to understand what types of operations contribute disproportionately to the CPU and also develop intuition regarding the relative cost of common operations. To minimize generalization, suppose the Oracle 7 HotSpot JVM.

For instance:

• builds a lot of objects the cost of the CPU (I understand that it costs memory :-))?
• Does monitor content cost a processor? those. if we have several threads trying to enter the same synchronized block, do blocked threads also consume processor cycles?
• relative cost of the above operations? For example, "a new object for one object costs the same CPU as iterating over an array of X-elements"

Any tips on developing intuition regarding the cost of the CPU for typical operations?

Any good readings on a topic that you could recommend?

Thank you,

EXPLANATION

thanks for the early answers, but pay attention to I:

• I am not asking why my application is slower.
• understand that using a profiler will help identify problems in a particular application, and for example, a GC can eat a processor or that a ten-generation GC'ing is more expensive than an Eden space.
• understand that most operating systems become expensive only if they run a lot (that is, practically no op is expensive if used sparingly)

Instead, I'm looking for guidance on the cost of the CPU, especially wrt above operations (suppose the web-scale application uses all the options mentioned by the equal amount - a lot).

For example, I already now that:

• long chains of method calls do not make a significant contribution to the CPU load (therefore, as a rule, this is convenient for using method delegation liberally).
• throwing exception is more expensive than using conditional expressions (thus, the latter is usually preferable for flow control in high-performance code)

... but what about instantiating new objects or content for the monitor? Will any of these ops be a significant (dominant) processor load participant (let's say I don't care about latency or heap size) in scale?

Answer 1

I think that among you the relative CPU consumption is written:

1) array indexing; it's fast; he just refers to

2) monitor - slower; paused and pending threads do not consume a processor; switching consumes very little CPU, but more than indexing

3) the creation of an object can be slow if the object is complex and causes the creation of sub-objects; creating a single new Object() bit slower than switching threads; but maybe I'm wrong, and it's one and the same thing; comparable in any case

4) throw / catch an exception VERY slowly; it is 10-100 times slower than creating an object

Answer 2

One operation is always fast. Measured CPU utilization, the operation is performed several thousand times, or even a million or a billion times. Therefore, you want to keep track of all kinds of loops and highly recursive calls.

It is often not obvious that something executes a million times, because the obvious loop only executes a hundred times. But it calls a function that performs something a hundred times, which contains another function that performs the operation a hundred times. So you end up with something running a million times. And in a web application, it is multiplied by the number of simultaneous requests.

Since it’s not easy for you to discover real “hot spots”, you probably want to use a special Java performance analysis tool to examine your application. This way you will find out which patterns have processor intensity and which don't.

Another thing in Java, if you allocate a lot of memory (be it a few large pieces and many small pieces) that cannot be quickly released, then garbage collection can become a processor swamp. Using a ton of string (for example, when processing XML) may be such a reason.

But it is best to use a tool for analysis.

Answer 3

Throwing an exception can be very cheap. The dear part is usually the creation of an exception object, because it calls fillInStackTrace() , which is expensive. If you omit this, the rest will be fast (it can be as fast as goto in C).

Source: https://blogs.oracle.com/jrose/entry/longjumps_considered_inexpensive

Below is a page with internal OpenJDK JVM data that contains performance information for more information.