I was trying to profile my spark application (that uses the G1 GC) using jprofiler. I came across their website where they mention that jprofiler remote profiling works reliably only with the standard garbage collector:
http://resources.ej-technologies.com/jprofiler/help/doc/index.html
(Under section Probe Settings/Starting Remote Sessions)
"Please note that the profiling interface JVMTI only runs reliably with the standard garbage collector. If you have VM parameters on your command line that change the garbage collector type such as
-Xincgc
-XX:+UseParallelGC
-XX:+UseConcMarkSweepGC
-XX:+UseParNewGC
please make sure to remove them. It might be a good idea to remove all -XX options if you have problems with profiling."
Is this true for the latest version of jprofiler as well (9.0) ? Does this affect cpu profiling as well ?
I am able to do a memory profiling with visualVM, just wondering why this limitation (if at all) with jprofiler.
It's not a limitation, it's just advice. Some of the alternative GCs are not well tested with the JVMTI (the profiling interface of the JVM). G1 GC will become the standard GC, so there the situation is different.
Related
App A, ran from IntelliJ, has CPU usage and I can look at threads. App B has no Threads tab and CPU usage shows "Not supported for this JVM". Both apps are ran with same JVM. Why / what happened?
JVM: Java HotSpot(TM) 64-Bit Server VM (25.101-b13, mixed mode)
Java: version 1.8.0_101, vendor Oracle Corporation
Java Home: /usr/lib/jvm/java-8-oracle/jre
I can take a thread dump with jstack.
Apps are simple command-line programs, not larger than 10 classes. One app uses finalization, if it matters.
I started both apps from IntelliJ Idea, via Run. App A when started from CLI (via java FinalizerTest) and looked at with jvisualvm had Threads and CPU usage, despite not having it previously. This is still the same JVM that runs it, so I guess this is Intellij problem?
If I can provide more information, freely ask.
I've seen suggestions to improve the performance of intellij putting the flag -server on idea.exe.vmoptions (or idea64.exe.vmoptions), what is the benefit of using -server flag on intellij 14 ?
How can I decide if enable this flag?
These .vmoptions files specify options for the JVM on which IDEA runs.
So for the -server parameter the official Java documentation states that:
Selects the Java HotSpot Server VM
http://docs.oracle.com/javase/8/docs/technotes/tools/windows/java.html
and
In general, the server VM starts up more slowly than the client VM, but over time runs more quickly.
http://docs.oracle.com/javase/8/docs/technotes/guides/vm/server-class.html
However, it is explicitly mentioned that:
The 64-bit version of the JDK supports only the Server VM, so in that case the option is implicit.
In other words when using the "server" flag, IDEA may start up more slowly, but may perform better. However specifying it makes sense only if you're using a 32-bit java to run IDEA.
Note that idea.sh or idea.bat have logic in them which tries first to find 64 bit java on the machine and if such is not found, tries to locate 32-bit one. If you're starting it on Windows with idea.exe, always 32 bit java will be used. If you're starting it on Windows with idea64.exe, always 64 bit java will be used.
We have a Java EE application that runs in JBoss 7.1.1, and, we must run it in VirtualMachines (such as VMWare ESXI).
The thing is, when we run our app in the VM, the performance is dropped by 50% approx.
Seems like the GC goes crazy... as far I can tell, when GC runs, it take much more longer
than normal to "end", and block the application meanwhile.
Have anyone else had a experience like that? Any tips, tunning or a light that I can follow?
Thanks in advance.
EDIT
JVM has Xmx and Xms = 1Gb
VM has 4Gb RAM
Ubuntu Server 64
oracle JVM 64
I would say that before moving your app to VM with configuration you posted it was running on 32bit system and 32bit jvm and using same jvm parameters.
Trick is that you moved to 64bit with 64bit java but still assigned same amount of heap size for your application, what has happened in reality is that you app now has half the memory available that it used to have.
Every object on 64bit jvm is twice the size of the one of 32bit jvm.
Given configuration you have I would suggest few solutions:
increase heap size to 2G
or use compressed oops
or install 32bit jvm
Given that your application does not have more than 1.3G assigned it think best performance would be achieved by installing 32bit jvm and running with -Xms1300m -Xmx1300m.
You can go even step futher and have 32bit VM with 32bit linux installation.
64bit jvm is only useful if you need more than 1.3G of heap otherwise it just adds too much overhead.
Also you can run jvm with
-verbose:gc -XX:+PrintGCDetails
that will show you what is happening with GC, this can further help you tune your jvm.
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 something?
There are a number of single threaded tasks which have a thread of their own.
the main thread which runs you program
the background byte code to native compiler
the finalizer thread (to call finalize() on objects)
the GC thread pool
Your code will only use as many threads as you create (plus "main" which created for you)
The JVM has native threads and no Global Lock, if that's what you're asking.
The first running time is probably largely JITing the bytecode to machine code. I would suspect very strongly that process is optimized for parallel scenarios.
As i know java programs are able to run on any Operating System.
and there are JVM's for any kind of machines.
I need a JVM that runs on my PC stand alone, and not on my OS (windows or any thing else).
I mean a JVM that acts like a boot, instead of the OS boot
i searched for all versions of JVM on "www.java.com/en/download/manual.jsp", but i did not get the suitable JVM.
the following link helped me a little but that was not enough
http://java-virtual-machine.net/other.html#jvm
my PC CPU is AMD Athlon(tm) 64X2 Dual Core Processor 5200 + 2.69 GHz
any body can help me to find the suitable jvm version ?!
Sure, have a look at JRockit Virtual Edition. As I understand it it's basically a micro kernel especially tailored for the JRockit VM.
From this page:
Java without the OS: JRockit Virtual Edition (VE)
Am I the only one that's never heard of this before? The Oracle JRockit team is looking at eliminating the OS from the stack required to run Java. This product will be called JRockit VE (not out yet)
JavaOS
Good lucking getting hold of it, though, it's nothing more than a historical curiosity.
There are two JVMs that I am aware of, which have this property:
The Fiji WM: http://www.fiji-systems.com/index.html
According to http://rtjava.blogspot.com/2009/11/new-real-time-vm-was-born-fiji-vm.html it also runs on bare metal.
The next possibility is JNode: an open source operating system where most parts are written in Java (the rest in assembly): http://www.jnode.org/
JNode is still beta, though.
No.
There was an idea of making a machine that could run a JVM as an actual machine (non virtualized), similiar to LISP machines, but that idea never took off...
You need a host OS to run a JVM.
Googling "java real machine" might give you some interesting articles.
I've found two: one from 2004, talking about how such a machine could be built and another one, talking about how JVM runs as a real machine on hardware such as mobile devices.
Still, no dice with a plain PC.