VisualVM profiling hangs while instrumenting classes

I have a strange behavior while trying to profile a Java Application with VisualVm.

Hostsystem = SUSE Linux Enterprise Server 10

Java JDK (same is running VisualVM and Application to profile) = jdk1.8.0_40 64bit

Profiling other applications (e.g. Tomcat) running on the host with the same JDK do not have this Problem.

Profiling my Application on Windows (running from Eclipse) also works fine.

After starting the profiling the log reads the following lines:

INFO [org.netbeans.ui.metrics.profiler]: Profiler Attach
INFO [org.netbeans.ui.metrics.profiler]: Profiler Settings
*** Profiler warning (Thu Oct 08 14:36:10 CEST 2015): class java/lang /UNIXProcess$$Lambda$9/1156856411, ldr = 0 not found anywhere
*** Profiler warning (Thu Oct 08 14:36:10 CEST 2015): class java/lang/invoke/LambdaForm$DMH/1131480230, ldr = 0 not found anywhere
*** Profiler warning (Thu Oct 08 14:36:10 CEST 2015): class java/lang/invoke/LambdaForm$MH/1901642836, ldr = 0 not found anywhere
*** Profiler warning (Thu Oct 08 14:36:10 CEST 2015): class java/lang
... and so on, stopping after 60 lines with similar output ...

My Application has the following JVM Parameters (BTW. I read at some other point, that there are problems with setting tmp Dir, but removing the parameter doesn't help either)

-XX:-UseLWPSynchronization
-XX:+UseConcMarkSweepGC
-Djava.rmi.server.hostname=<removed>
-Duser.timezone=Europe/Berlin
-Dcom.sun.management.config.file=/global/ECAS_TESTAS/ecastest/ecas/conf/management.properties
-Dsun.rmi.transport.tcp.handshakeTimeout=180000
-Dsun.rmi.dgc.client.gcInterval=600000
-Dsun.rmi.dgc.server.gcInterval=600000
-verbose:gc
-XX:CompileCommand=exclude,ecas/logik/ELogikKomponentenVersion.doBerechnen
-XX:CICompilerCount=2
-Djava.io.tmpdir=/global/ECAS_TESTAS/ecastest/ecas/tmp
-XX:NewSize=2100m
-XX:SurvivorRatio=20
-Xms10000m
-Xmx10000m
-XX:MaxPermSize=120m

Here you find a Screenshot showing the problem.

Solution

After some research with sending sigterm (kill -3 pid) to produce stacktrace I found out, that visualvm was still parsing possible classes. After that, I noticed that for this process "." was in classpath. So I removed it. Now it works as expected.