Develop Reference

VisualVM shows "Not supported for this JVM"

I am trying to profile a remote JVM with VisualVM 1.4. I am running macOS High Sierra 10.13.6 locally, with the following OpenJDK version:
java -version
openjdk version "1.8.0_181"
OpenJDK Runtime Environment (AdoptOpenJDK)(build 1.8.0_181-b13)
OpenJDK 64-Bit Server VM (AdoptOpenJDK)(build 25.181-b13, mixed mode)
The server runs Debian Stretch with the following OpenJDK:
java -version
openjdk version "1.8.0_181"
OpenJDK Runtime Environment (build 1.8.0_181-8u181-b13-2~deb9u1-b13)
OpenJDK 64-Bit Server VM (build 25.181-b13, mixed mode)
When I monitor a JVM process locally, I see all these tabs and the profiling works just fine.
However, if I do that remotely, I see something like this:
Note the CPU window that says "Not supported for this JVM" and the reduced tabs, not including "Profiler". However, as you can see, I do see some data.
I am connecting via jstatd. On the server, following this article, I am running
jstatd -J-Djava.security.policy=/home/brandwatch/jstatd.all.policy -J-Djava.rmi.server.hostname=10.2.156.160 -Djava.rmi.server.logCalltrue
Answers like this indicate that this might be due to different JVM versions, however, mine appear to be the same, despite one of them running on MacOS and one of them on Debian.

Missing CPU usage information has nothing to do with with different JDK versions. You don't see CPU usage data because jvmstat (exported via jstatd) does not provide such information. If you want to see CPU usage, you need to use JMX connection. JMX will also allow you to do CPU and Memory sampling. Profiling is supported for local applications only.

Because, as Tomas Hurka's answer correctly indicates, remote profiling does not work with VisualVM, I have used a little hack to still make it work: I have installed VisualVM on the remote server and accessed it via X-forwarding. That way, VisualVM can access the process locally an thus profile it.
ssh into the server with the -X flag
ssh -C -X <user>#<host>
download [VisualVM 1.4][8]
wget https://github.com/visualvm/visualvm.src/releases/download/1.4/visualvm_14.zip
unzip the archive
unzip visualvm_14.zip
run VisualVM
./visualvm_14/bin/visualvm
After a few seconds you should see a VisualVM window pop up. It's not very fast (just because x-forwarding is not), but for my use case it was alright.
Another way of achieving this might be using VNC, but I haven't tried that. The downside would be that you have to install all the desktop packages, which one might not want on a server.

Invoking jMeter from the command line with 64-bit directive loses the class

We were running 32-bit JDK and jMeter 2.6, and were running into heap memory issues when simulating 8000 users spread out over the course of an hour.
We upgraded to 64-bit Java, and jMeter 2.12.
Java(TM) SE Runtime Environment (build 1.7.0_79-b15)
Java HotSpot(TM) 64-Bit Server VM (build 24.79-b02, mixed mode)
When we run from the command line requesting a 4Gb heap (the server has 32Gb), we receive the message that the initial heap size is too large.
set JVM_ARGS="-Xms4G -Xmx4G -XX:NewSize=512m -XX:MaxNewSize=1G" jmeter.sh
When we add the option -d64 to JVM_ARGS, we no longer receive the error about the heap size, but it no longer finds the class
set JVM_ARGS="-d64 -Xms4G -Xmx4G -XX:NewSize=512m -XX:MaxNewSize=1G" jmeter.sh
Pointing it to the directory seems to have no effect
set JVM_ARGS="-d64 -Xms4G -Xmx4G -XX:NewSize=512m -XX:MaxNewSize=1G -cp mypath" jmeter.sh

Looking into jmeter.sh it seems you're trying to run JMeter on Linux or MacOSX. I believe you need to remove set word (or replace it with export)
Given you have correct java executable in PATH providing -d64 option shouldn't be required. Something like:
JAVA_HOME=/path/to/64-bit/jdk && export JAVA_HOME
PATH=$JAVA_HOME/bin:$PATH && export PATH
You can edit jmeter script and amend the following lines:
HEAP="-Xms512m -Xmx512m"
NEW="-XX:NewSize=128m -XX:MaxNewSize=128m"
"Telling" Jmeter to use Concurrent Mark Sweep (CMS) Garbage Collector can also improve JMeter-side performance greatly. The relevant line is:
-XX:+UseConcMarkSweepGC
See 9 Easy Solutions for a JMeter Load Test “Out of Memory” Failure article for more information on getting the most from your JMeter installation.

Could not create the Java virtual machine OSX10.9

Can't seem to find an answer to this.
If I type java -version I get
java version "1.6.0_65"
Java(TM) SE Runtime Environment (build 1.6.0_65-b14-462-11M4609)
Java HotSpot(TM) 64-Bit Server VM (build 20.65-b04-462, mixed mode)
I'm trying to run PMD to analyse an iOS project. When I run the command in Terminal however, I get:
Could not create the Java virtual machine.
Anyone have any idea what is causing this?

This could be due to installation issue. Check whether you have installed correct JRE for your platform(bit pattern etc.). If its fine try changing memory settings.
This link will help you to set memory settings in Java

java on "server" linux: Is there any way to run in client mode?

I'm running a java web server as an internal component of another project, and unfortunately java insists on running in server mode (i.e. fast, and huge memory footprint), even when I pass the -client switch.
This is a problem because java takes up so much memory that my whole project is killed by the server.
I'm running java with the command:
java -client -classpath /home/marcintustin/webapps/django/oneclickcosvirt/oneclickcos/java:/home/marcintustin/webapps/django/oneclickcosvirt/oneclickcos/java/commons-fileupload-1.2.2.jar:/home/marcintustin/webapps/django/oneclickcosvirt/oneclickcos/java/fop-20120125.jar:/home/marcintustin/webapps/django/oneclickcosvirt/oneclickcos/java/xmlgraphics-commons-1.5svn.jar:/home/marcintustin/webapps/django/oneclickcosvirt/oneclickcos/java/batik-all.jar:/home/marcintustin/webapps/django/oneclickcosvirt/oneclickcos/java/docx4j-nightly-20120105.jar:/home/marcintustin/webapps/django/oneclickcosvirt/oneclickcos/java/spark-0.9.9.3-SNAPSHOT.jar:/home/marcintustin/webapps/django/oneclickcosvirt/oneclickcos/java/slf4j-log4j12-1.6.1.jar:/home/marcintustin/webapps/django/oneclickcosvirt/oneclickcos/java/slf4j-api-1.6.1.jar:/home/marcintustin/webapps/django/oneclickcosvirt/oneclickcos/java/jetty-webapp-7.3.0.v20110203.jar:/home/marcintustin/webapps/django/oneclickcosvirt/oneclickcos/java/servlet-api-3.0.pre4.jar:/home/marcintustin/webapps/django/oneclickcosvirt/oneclickcos/java/antlr-2.7.7.jar:/home/marcintustin/webapps/django/oneclickcosvirt/oneclickcos/java/commons-codec-1.6.jar:/home/marcintustin/webapps/django/oneclickcosvirt/oneclickcos/java/docx4j-2.7.1.jar:/home/marcintustin/webapps/django/oneclickcosvirt/oneclickcos/java/poi-scratchpad-3.8-beta4.jar:/home/marcintustin/webapps/django/oneclickcosvirt/oneclickcos/java/xalan-2.7.1.jar:/home/marcintustin/webapps/django/oneclickcosvirt/oneclickcos/java/antlr-runtime-3.3.jar:/home/marcintustin/webapps/django/oneclickcosvirt/oneclickcos/java/commons-io-2.1.jar:/home/marcintustin/webapps/django/oneclickcosvirt/oneclickcos/java/serializer-2.7.1.jar:/home/marcintustin/webapps/django/oneclickcosvirt/oneclickcos/java/xml-apis-1.3.04.jar:/home/marcintustin/webapps/django/oneclickcosvirt/oneclickcos/java/avalon-framework-api-4.3.1.jar:/home/marcintustin/webapps/django/oneclickcosvirt/oneclickcos/java/commons-lang-2.4.jar:/home/marcintustin/webapps/django/oneclickcosvirt/oneclickcos/java/log4j-1.2.15.jar:/home/marcintustin/webapps/django/oneclickcosvirt/oneclickcos/java/stringtemplate-3.2.1.jar:/home/marcintustin/webapps/django/oneclickcosvirt/oneclickcos/java/avalon-framework-impl-4.3.1.jar:/home/marcintustin/webapps/django/oneclickcosvirt/oneclickcos/java/commons-logging-1.1.1.jar:/home/marcintustin/webapps/django/oneclickcosvirt/oneclickcos/java/poi-3.8-beta4.jar:/home/marcintustin/webapps/django/oneclickcosvirt/oneclickcos/java/wmf2svg-0.9.0.jar: Transcoder
java -version reports:
java version "1.7.0"
Java(TM) SE Runtime Environment (build 1.7.0-b147)
Java HotSpot(TM) 64-Bit Server VM (build 21.0-b17, mixed mode)
As I'm on a shared host, I can't install 32-bit compatibility libraries, so I can't use the 32-bit JRE. This turns out to be a problem because as confirmed by #birryree in the comments (thanks!), 64-bit JRE always runs in server mode.
Is there a way to force java to run in normal client mode?

Based on comments received (and testing), it seems that the 64bit JVM ALWAYS runs in server mode, which means that it is VERY profligate with memory.
The work-arounds are:
Get the 32bit JVM (and appropriate compatibility libraries if on Linux); or
Use the -X options to limit memory to a certain maximum.

jconsole memory tab

I am connecting to remote jboss server with jconsole. For some reason all tabs except MBean are disabled, how can I setup jboss run configuration to allow remote memory monitoring?
I am connecting to jboss with the following link (I have taken it from jboss startup log):
service:jmx:rmi://hostAddr/jndi/rmi://hostAddr:1190/jmxconnector
What am I doing wrong?
UPD
Java version on the server (there is application running which I want to monitor):
java version "1.6.0_18"
Java(TM) SE Runtime Environment (build 1.6.0_18-b07)
Java HotSpot(TM) 64-Bit Server VM (build 16.0-b13, mixed mode)
Java version on client (I start jconsole here):
java version "1.6.0_26"
Java(TM) SE Runtime Environment (build 1.6.0_26-b03)
Java HotSpot(TM) 64-Bit Server VM (build 20.1-b02, mixed mode)

Had the same problems.
Solution is
Set JBoss Java Options for example:
-Dcom.sun.management.jmxremote
-Dcom.sun.management.jmxremote.authenticate=false
-Dcom.sun.management.jmxremote.ssl=false
-Dcom.sun.management.jmxremote.port=9999
Environment variables
"TEMP" and
"TMP"
need to be set manually to an empty directory (i.e. C:\Temp). If this is not done, the tabs Memory, Threads ... are disabled.
JConsole needs to be started with the same user as the JVM. This could be "system".
This can be done with psexec
PsExec.exe -s -i "%java_home%\bin\jconsole.exe"
Then connect to "localhost:9999"