Профилирование VisualVM зависает во время инструментирования классов

У меня странное поведение при попытке профилировать Java-приложение с помощью VisualVm.

Hostsystem = SUSE Linux Enterprise Server 10

Java JDK (то же самое, что и VisualVM, и приложение для профиля) = jdk1.8.0_40 64bit

Профилирование других приложений (например, Tomcat), работающих на хосте с тем же JDK, не имеет этой проблемы.

Профилирование моего приложения в Windows (работающее из Eclipse) также работает нормально.

После начала профилирования в журнале читаются следующие строки:

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 ...

Мое приложение имеет следующие параметры JVM (BTW. Я читал в какой-то другой момент, что есть проблемы с установкой tmp Dir, но удаление параметра тоже не помогает)

-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

Здесь вы найдете снимок экрана, показывающий проблему.


person dRoeder    schedule 08.10.2015    source источник


Ответы (1)


После некоторого исследования с отправкой sigterm (kill -3 pid) для создания stacktrace я обнаружил, что visualvm все еще анализирует возможные классы. После этого я заметил, что для этого процесса "." был в пути к классам. Я удалил это. Теперь все работает как положено.

person dRoeder    schedule 09.10.2015