What is the most costly operation on the JVM?

I remember that my professor said that new operation is the most costly operation on JVM. Is this true? I mean, more expensive than opening a file? And how can I know the cost of any operation in Java? For开发者_如何学运维 example, finding the difference between

int a;
Integer b;
Integer c = new Integer(1);
int[] d = new int[10];
Integer[] e = new Integer[10];

This is extremely implementation-specific. Chances are that on a modern JVM, none of these actually have any cost whatsoever. When just-in-time compiling, some JVMs will detect that your objects don't escape the scope of your function and will allocate them "for free" on the stack.

You can't really measure the most expensive operation on a JVM. If something is known to be expensive, probably that anyways, someone at SunOracle is working on making it less expensive, and next thing you know it's gonna be constant-time.

The only thing regarded as expensive in any programming should be your algorithms.

Can't really say what is the most expensive, but I'm pretty certain it's not new (of course your constructor can be heavy, if it does a lot of things):

The common code path for new Object() in HotSpot 1.4.2 and later is approximately 10 machine instructions (data provided by Sun; see Resources), whereas the best performing malloc implementations in C require on average between 60 and 100 instructions per call (Detlefs, et. al.; see Resources). And allocation performance is not a trivial component of overall performance -- benchmarks show that many real-world C and C++ programs, such as Perl and Ghostscript, spend 20 to 30 percent of their total execution time in malloc and free -- far more than the allocation and garbage collection overhead of a healthy Java application

Taken from this article, note that it talks about JVM 1.4.2 (article was published in 2005). Here's another one from 2003, talking about some Java performance myths still circling. And newer JVM's should be considerably faster than the versions from back those days.

what is the costly operation on JVM ?

This is probably not a meaningful or quantifiable thing:

• You haven't said what an "operation" is.
• Depending on what you mean by "operation", the "cost" most likely depends on the context. For instance while (i < 999) i++; probably has ZERO cost once the JIT compiler has optimized it.

I remember that my professor said that new() operation is the most costly operation on JVM. Is it true?

Probably not.

I mean, than opening a file?

Certainly not. The process of opening a file will create a number of objects.

But if you call opening a file an "operation", how small or big can an operation be?

and how can I know the cost of any operation in Java?

It is very difficult to write a benchmark that isolates and measures the cost of a given operation. And it is generally pointless too, because the JVM optimizes sequences of operations.

For example, the difference between ...

Even your example is difficult to measure. For example:

• Part of the cost of those statements needs to be amortized with the cost of running the garbage collector.

• The JIT compiler may decide that some or all of those statements don't effect the outcome of the computation, and optimize them away completely.

The most costly operation is likely going to vary between JVM implementations and target platforms, and therefore is not going to have a very exact answer.

Some of the more "costly" operations are certainly file/socket I/O and synchronize().

Garbage Collection is rather expensive too (thought that's not an operation your code directly invokes, the way your code is written can affect how often this cost is incurred).

Almost certainly false. Especially if you are talking about comparing it with things like "opening a file" (which is certainly more than one JVM operation) it's nowhere near the most expensive thing you can do.

If you're talking pure wall time, things like a socket read() could be measured on the order of seconds. If you want something that is intensive in terms of work done, you could map a native ByteByffer and that would take a galactic age compared to new()

Opening a file would be an OS operation, not a JVM one. By operation, your instructor must have meant Java bytecode instructions. new() is costly since it requires the JVM to allocate memory and cause a chain reaction to initialize the object hierarchy. It can also have long term effects on the GC, etc. See Java performance tuning.

The most costly operation then would be a

while(true){}

, but to get a general understanding about costs you have to use a profiler, or a benchmark. But beware, Microbenchmarks in Java often lead to false results, because the JVM is very very good in optimizing the code and removing unnessecary statements.

Costly compared to what? And what is the 'currency' of the cost for you? A lot of times the JVM will amortize the cost of profiling and optimizing a piece of code over many calls, so the situation might be even more complex than you think.

As general guidelines, you could run any of these things 10000 times and measure time and memory to get a feeling for the relative cost of things.