What does a "instrumented Java Virtual Machine" mean?
An instrumented JVM is a JVM that is instrumented.
However, that is a fatuous definition, and I have not been able to find a clearly documented definition of what "instrumented" really means.
In fact, it potentially applies to (at least) any HotSpot JVM since Java 5.0. The current implementation of jps looks for instrumented JVMs as follows:
If you specify a hostid, jps attempts to contact an RMI service (jstatd) on the host to find out about the Java processes.
If you don't specify a hostid, jps finds Java processes by looking for /tmp/hsperfdata_<username> directories that are readable by the current user; see How do jps, jinfo, jstat, jmap and jstack get information about local Java processes?. A JVM will create one of these directories unless you launch the JVM with -XX:-UsePerfData or -XX:-PerfDisableSharedMem. (Thanks to @apangin for this information.)
But ultimately we still have a circular (working) definition: an "instrumented JVM" is one that jps is able to find.
Is a jps process a JVM process, by definition?
The current implementation of jps is a Java class that runs in a JVM created by a generic launcher (the jps executable). However, there is no "definition" that says that is has to be implemented this way.
Note that since jps without any arguments will find itself (at least on my system) that strongly (IMO) suggests that the current implementation uses an instrumented JVM.
jps is an ELF file, not a JVM bytecode program compiled from a Java program
That actually has nothing to do with it. A JVM is a thing (a virtual machine) that is executing a Java program. It is not relevant to "JVM-ness" how the program is launched, or even whether the program was represented as bytecodes at launch time.
With jlink (or older 3rd-party products) an ordinary Java (bytecode) program can be turned into a native executable. On Linux, jlink will produce an ELF file. Yet, when you run the ELF file, you will still have a JVM.
