jvm-hotspot

When running a Java 1.6 (1.6.0_03-b05) app I've added the -XX:+PrintCompilation flag. On the output for some methods, in particular some of those that I know are getting called a lot, I see the text made not entrant and made zombie . What do these mean? Best guess is that it's a decompilation step before recompiling either that method or a dependency with greater optimisation. Is that true? Why "zombie" and "entrant"? Example, with quite a bit of time between some of these lines: [... near the beginning] 42 jsr166y.LinkedTransferQueue::xfer (294 bytes) [... much later] 42 made not entrant

So I decided that the "easiest" way to answer my other question is to "simply" look at the implementation of the unsafe in C/C++. ( In a nutshell, I have an Object base and a long offset in Java, that I'm passing to C/C++ by means of the Java Native Interface (JNI), from where I want to execute the C/C++ equivalent of unsafe.setInt(base,offset,1) ) Such an implementation is provided, for example, by the OpenJDK: unsafe.cpp I don't care about most that's in there, I just want a direct access to values. So looking at the implementation, I see #define SET_FIELD(obj, offset, type_name, x) \ oop p

I'm working with a system where a number of jobs, implemented as Java applications, can be started simultaneously. Each job runs in a separate JVM. Some of these jobs require bigger permgen size than others. However, it is not feasible to allow all jobs to use the maximum value, as the OS memory is limited. Therefore, I want to specify -XX:MaxPermSize for every job. Currently, the jobs are running without any -XX:MaxPermSize argument, so they must be using the default value. But how can I find out what the default value is? I have seen Default values for Xmx, Xms, MaxPermSize on non-server

I am debugging code that has in it expr1 & expr2 where expr1 has a side effect that affects expr2 evaluation result. I suspect that expr2 gets evaluated before expr1 , since JLS guarantees left-to-right evaluation for && , but not necessarily for & . I also suspect that change of evaluation order may be a result of optimization performed by HotSpot (we're running Java 6u20). Do you know if HotSpot can make such an optimization? Better yet, provide any pointers to documentation that either support or eliminate the suspicion. Thanks in advance. EDIT: Thanks for those suggesting to rewrite the

Can anyone tell me if either Hotspot or Dalvik is smart enough to inline calls to a final method returning a constant (static final) int value? Ideally the method call would be replaced by the constant. This might either be at class load time or through JIT. This has implications in the design of some code I'm working on. I would think that the answer is "no, optimization will not happen because of absence or presence of the final keyword", at least on the HotSpot VM. But optimization will likely happen because of other factors. Here's what Brian Goetz says in this article (sorry for the long

An OutOfMemoryError occurs when the heap does not have enough memory to create new objects. If the heap does not have enough memory, where is the OutOfMemoryError object created. I am trying to understand this, please advise. Of course, this is an implementation-dependent behavior. HotSpot has some heap memory inaccessible for ordinary allocations, the JVM can use to construct an OutOfMemoryError in. However, since Java allows an arbitrary number of threads, an arbitrary number of threads may hit the wall at the same time, so there is no guaranty that the memory is enough for constructing a

After upgrading to Java 1.8.0_20 our test system reported errors, but the code was not changed. I found out, that Math.pow() called with exactly the same input parameters yields different results upon repreated calls. In Java 1.8.0_11 it behaves as expected and returns always the same value, but with Java 1.8.0_20 and above it sometimes returns slightly different values. This is similar to the question Math.pow yields different result depending on java version , but different because the results of pow() differ within one VM. The following JUint test fails when run under Java 1.8.0_20 and