jvm-hotspot

问题 When profiling with async profiler and gperftools I noticed that jvmti->GetTag shows up quite a lot in the results for my agent. When I checked how it is implemented I found the following in the source of jvmitTagMap.cpp : jlong JvmtiTagMap::get_tag(jobject object) { MutexLocker ml(lock()); // resolve the object oop o = JNIHandles::resolve_non_null(object); // for Classes get the tag from the klassOop return tag_for(this, klassOop_if_java_lang_Class(o)); } Although my test only had one thread

问题 I'm using this Java version: java version "1.6.0_24" OpenJDK Runtime Environment (IcedTea6 1.11.3) (suse-9.1-x86_64) OpenJDK 64-Bit Server VM (build 20.0-b12, mixed mode) When I start a java program, e.g. java TestApp by default, will the JVM run in parallel ? If so, which parts run in parallel ? I am interested in this, because I found if I use taskset -c 0 java TestApp to bind TestApp running on processor 0 , the first running time is much slower than java TestApp . Does this imply

问题 Does anybody know if netbeans by default uses the hotspot server vm? I'm trying to figure out if that would be an option of not. Thanks! -roger- 回答1: It seems to be this option to make NetBeans run ' java -server ' instead of just java: netbeans -J-server Note: in term of raw performance though, this might not be the most important option to use. See Java Settings for Netbeans 6.8 on OSX 10.5.8 to avoid 100% cpu usage 来源： https://stackoverflow.com/questions/6003453/is-there-a-way-to-make

问题 We have an application running Wildfly app server in a clustered mode (6 nodes). We are seeing sometimes JVM freeze of 16secs when there is a GC triggered. The application is time sensitive and other nodes in the cluster thinks that node is dead (in which the JVM pause) if the heartbeat response is not received with in 15secs. So, The JVM freeze causing application instability. To understand what is going on during GC, we enabled hotspot, safepoint logs and see the following traces when there

问题 Curious if anyone could help out in regards to a Java HotSpot dump...saw some reference to head over to the Sun Forums, figured I would try here first...below is the dump... # # An unexpected error has been detected by Java Runtime Environment: # # EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x6d8c8f23, pid=2836, tid=5980 # # Java VM: Java HotSpot(TM) Client VM (11.2-b01 mixed mode, sharing windows-x86) # Problematic frame: # V [jvm.dll+0xc8f23] # # If you would like to submit a bug report,

问题 I'm looking into debugging an "OutOfMemoryError: Metaspace" error in my application. Right before the OOME I see the following in the gc logs: {Heap before GC invocations=6104 (full 39): par new generation total 943744K, used 0K [...) eden space 838912K, 0% used [...) from space 104832K, 0% used [...) to space 104832K, 0% used [...) concurrent mark-sweep generation total 2097152K, used 624109K [...) Metaspace used 352638K, capacity 487488K, committed 786432K, reserved 1775616K class space

问题 I'm trying to compile the hsdis-amd64.dll library that the JVM needs to disassemble JIT compiled code. I followed this accepted answer. I installed cygwin downloaded openjdk-7u40-fcs-src-b43-26_aug_2013.zip and downloaded binutils-2.24.tar.gz I created a folder structure like this: + +- hsdis // unzipped dir hotspot/src/share/tools/hsdis of openjdk zip +- binutils-2.24 // unzipped binutils-2.24.tar.gz First I tried to just compile it using: $ make OS=Linux MINGW=x86_64-w64-mingw32 BINUTILS=..

问题 If I run java from the command line on my windows box like this: "C:\Program Files (x86)\Java\jdk1.7.0_51\bin\java.exe" -XshowSettings:all -Xss=1m -Xmx256m I see this output: VM settings: Stack Size: 1.00M Max. Heap Size: 256.00M Ergonomics Machine Class: client Using VM: Java HotSpot(TM) Client VM The important part for me is "Stack Size: 1.00M", which is what I set it to be via the command line option "-Xss1m". But if I remove this option and let the VM run with the default stack size I get

问题 I have a Java app which shows different GC behaviors in different environments. In one environment, the heap usage graph is a slow sawtooth with major GCs every 10 hours or so, only when the heap is >90% full. In another environment, the JVM does major GCs every hour on the dot (the heap is normally between 10% and 30% at these times). My question is, what are the factors which cause the JVM to decide to do a major GC? Obviously it collects when the heap is nearly full, but there is some

问题 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