Oracle Hotspot JVM: generally, what operations are especially CPU-costly?

Question

I'd like to understand of what types of operations contribute disproportionately to CPU load as well as develop an intuition on relative cost of common operations. To minimize generalizations, please assume Oracle 7 HotSpot JVM.

For example:

• does constructing lots of objects cost CPU (I understand it costs memory :-) )?
• does contenting for a monitor cost CPU? ie if we have multiple threads attempting to enter the same synchronized block, do blocked threads also consume CPU cycles?
• relative cost of above operations? For example, "new'ing a single object costs the same CPU as iterating over a X-element array"

Any tips on developing an intuition of relative CPU cost of typical operations?

Any good reads on the subject you could recommend?

thank you,

CLARIFICATION

thanks for early responses, but please note I:

• am NOT asking 'why is my app slow'
• understand that using a profiler will help identify problems in a specific app and that for example, GC can eat up CPU or that GC'ing tenured generation is more costly than Eden space
• understand that most ops become costly only if executed a lot (ie virtually no op is expensive if used sparingly)

Instead, I am looking for guidance of relative CPU cost, especially w.r.t. above operations (let's assume a 'web-scale' app uses all ops mentioned equal amount - a lot).

For example I already now that:

• long method call chains do not contribute significantly to CPU load (so it's generally OK to use method delegation liberally)
• throwing exceptions is more expensive than using conditionals (thus latter is generally preferred for flow-control in highly performance-sensitive code)

...but what about instantiating new objects or contenting for a monitor? Would either of these ops be significant (dominant?) contributors to CPU load (let's say I don't care about latency or heap size) at scale?

Answer 1

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

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

Here is a page with internals about the OpenJDK JVM that lists information about performance for further information.

Answer 2

I think that among you wrote the relative CPU consumption is follows:

1) indexing of an array; it's fast; it's just addressing

2) monitor -- slower; suspended and waiting threads do not consume CPU, switching consumes very little CPU, but more than indexing

3) creating an object may be slow if an object is complex and causes sub-objects creation; creating a single new Object() just slightly slower than thread switching; but may be I am wrong and it is the same; anyway comparable

4) throwing/catching an exception is VERY slow; it is 10-100 times slower that creating an object

Answer 3

A single operation is always fast. A measurable CPU load an operation is executed several thousand times or even a million or billion times. So you want to watch out for all kinds of loop and heavily recursive calls.

Often, it's not obvious that that something is executed a million time because the obvious loop is only executed a hundred times. But it calls a function that executes something a hundred times, which contains another function executing an operation a hundred time. That way you end up with something being run a million times. And in a web app, it's multiplied with the number of concurrent requests.

Since it's not easy to spot the real hot spots, you probably want to use a special performance analysis tool for Java to investigate your application. That way you learn what patterns are CPU-intensive and what patterns are not.

Another thing in Java, if you allocate a lot of memory (be it few large chunks and many small chunks) that cannot quickly be release, then garbage collection can become a CPU hog. Using tons of string (e.g. when processing XML) can be such a cause.

But the best thing really is to use a tool for analysis.