jvm-hotspot

In benchmarking some Java code on a Solaris SPARC box, I noticed that the first time I call the benchmarked function it runs EXTREMELY slowly (10x difference): First | 1 | 25295.979 ms Second | 1 | 2256.990 ms Third | 1 | 2250.575 ms Why is this? I suspect the JIT compiler, is there any way to verify this? Edit: In light of some answers I wanted to clarify that this code is the simplest possible test-case I could find exhibiting this behavior. So my goal isn't to get it to run fast, but to understand what's going on so I can avoid it in my real benchmarks. Solved: Tom Hawtin correctly pointed

I've heard that JIT automatically inlines small methods, like getters (they have about 5 bytes). What is the boundary? Is there any JVM flag? HotSpot JIT inlining policy is rather complicated. It involves many heuristics like caller method size, callee method size, IR node count, inlining depth, invocation count, call site count, throw count, method signatures etc. Some limits are skipped for accessor methods (getters/setters) and for trivial methods (bytecode count less than 6). The related source code is mostly in bytecodeInfo.cpp . See InlineTree::try_to_inline , should_inline , should_not

When I run my timing test program in Java Hotspot client, I get consistent behavior. However, when I run it in Hotspot server, I get unexpected result. Essentially, the cost of polymorphism is unacceptably high in certain situations that I've tried to duplicate bellow. Is this a known issue/bug with Hotspot server, or am I doing something wrong? Test program and timing are given bellow: Intel i7, Windows 8 Java HotSpot(TM) 64-Bit Server VM (build 24.45-b08, mixed mode) Mine2: 0.387028831 <--- polymorphic call with expected timing Trivial: 1.545411765 <--- some more polymorphic calls Mine: 0

This question already has an answer here: How to see JIT-compiled code in JVM? 7 answers I'd like to have a better understanding of what optimizations HotSpot might generate for my Java code at run time. Is there a way to see the optimized code that HotSpot is using after it's been running for a while? You will need to start the JVM with the options -XX:+PrintAssembly and -XX:UnlockDiagnosticVMOptions , but PrintAssembly requires the JVM to have the hsdis binary (HotSpot disassembler). The hsdis binary is not distributed with the JVM due to license incompatibility, so you will need to compile

How large, in bytes, is a boxed primitive like java.lang.Integer or java.lang.Character in Java? An int is 4 bytes, a typical pointer is also 4 byte (if not compressed by the JVM). Is the cost for an Integer (without caching) thus 4 bytes + 4 bytes = 8 bytes ? Are there any more hidden fields within the box-object or additional overhead incurred regarding objects (i.e. is there a general cost for objects that I'm not aware of?). I'm not interested in caching issues. I know that Integers within a certain range are cached by the JVM. One could rephrase the question: What is the maximum factor to

I was recently reading about all the JVM arguments available in JRE 6 [ Java VM Options ] and saw this : -XX:+StringCache : Enables caching of commonly allocated strings. Now I was always under the impression that Java kept a pool of interned (correct word?) Strings and when doing something like String concatenation with literals it was not creating new objects, but pulling them from this pool. Has anyone ever used this argument, or can explain why it would be needed? EDIT: I attempted to run a benchmark, to see if this argument had any effect and was unable to get the Sun JVM to recognize it.

I have come across a few references regarding the JVM/JIT activity where there appears to be a distinction made between compiling bytecode and interpreting bytecode. The particular comment stated bytecode is interpreted for the first 10000 runs and compiled thereafter. What is the difference between "compiling" and "interpreting" bytecode? Interpreting byte code basically reads the bytecode line by line, doing no optimization or anything, and parsing it and executing it in realtime. This is notably inefficient for a number of reasons, including the issue that Java bytecode isn't designed to be