search

mmoumi / jspf

Automatically exported from code.google.com/p/jspf
0 stars 0 forks source link

Profiling fails #24

Closed GoogleCodeExporter closed 8 years ago

GoogleCodeExporter commented 8 years ago 
Yesterday while profiling my application in NetBeans and VisualVM I discovered 
that no plugins classes profiled at all. They are invisible to profilers.
Possible due to separate classloader or some black magic during instantiating.

Are these results predictable or I just use wrong tools for profiling?

NetBeans 6.9, VisualVM 1.3
JSPF 0.9

Thanks,
Maxim

Original issue reported on code.google.com by McSe...@gmail.com on 24 Nov 2010 at 5:42

GoogleCodeExporter commented 8 years ago 
Whoops, completely missed this issue. Can confirm this issue after a brief 
check. Investigating.

Original comment by r.biedert on 11 Jan 2011 at 11:39

GoogleCodeExporter commented 8 years ago

Original comment by r.biedert on 11 Jan 2011 at 11:39

GoogleCodeExporter commented 8 years ago 

Appears to be a problem of VisualVM. In my test case, the app uses 100% CPU, 
VisualVM only reports 50%, but it clearly sees the "bigbang" thread eating all 
resources:

"Thread-18" daemon prio=5 tid=106afd000 nid=0x117f22000 runnable [117f20000]
   java.lang.Thread.State: RUNNABLE
    at sun.nio.cs.UTF_8.updatePositions(UTF_8.java:58)
    at sun.nio.cs.UTF_8$Encoder.encodeArrayLoop(UTF_8.java:392)
    at sun.nio.cs.UTF_8$Encoder.encodeLoop(UTF_8.java:447)
    at java.nio.charset.CharsetEncoder.encode(CharsetEncoder.java:544)
    at java.lang.StringCoding$StringEncoder.encode(StringCoding.java:240)
    at java.lang.StringCoding.encode(StringCoding.java:272)
    at java.lang.StringCoding.encode(StringCoding.java:284)
    at java.lang.String.getBytes(String.java:986)
    at java.lang.ProcessEnvironment$Variable.valueOfQueryOnly(ProcessEnvironment.java:148)
    at java.lang.ProcessEnvironment$Variable.valueOfQueryOnly(ProcessEnvironment.java:144)
    at java.lang.ProcessEnvironment$StringEnvironment.get(ProcessEnvironment.java:223)
    at java.lang.ProcessEnvironment$StringEnvironment.get(ProcessEnvironment.java:205)
    at java.util.Collections$UnmodifiableMap.get(Collections.java:1282)
    at java.lang.ProcessEnvironment.getenv(ProcessEnvironment.java:68)
    at java.lang.System.getenv(System.java:847)
    at net.xeoh.plugins.testplugins.testannotations.impl.TestAnnotationsAbtractImpl.bigbang(TestAnnotationsAbtractImpl.java:108)
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
    at java.lang.reflect.Method.invoke(Method.java:597)
    at net.xeoh.plugins.base.impl.spawning.Spawner$2.run(Spawner.java:380)
    at java.lang.Thread.run(Thread.java:680)

Original comment by r.biedert on 11 Jan 2011 at 11:48

GoogleCodeExporter commented 8 years ago 
Well, how do you profile then? Any advice?

Original comment by McSe...@gmail.com on 11 Jan 2011 at 11:52

GoogleCodeExporter commented 8 years ago 
Frankly, no idea. 

I played with VisualVM for some time now, and while it is able to see the 
actual thread, it does not take it into account for profiling. All in all, this 
looks like a VisualVM problem to me, not a JSPF one. 

Have you tried another profiler like YourKit? I once used their demo version on 
a JSPF project and it appeared to work without problems.

Original comment by r.biedert on 11 Jan 2011 at 12:02

GoogleCodeExporter commented 8 years ago 
Closed, does not appear to be a JSPF bug. Will be reopened in case we have new 
insights.

Original comment by r.biedert on 24 Feb 2011 at 10:31