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

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