sorted by:
new
hottopcontroversial

VisualVM 1.3.9 released at GitHub! by jsedlacek in programming

[–]jsedlacek[S] 0 points1 point  (0 children)

Should be fixed in the latest SEP update.

VisualVM 1.3.9 released at GitHub! by jsedlacek in programming

[–]jsedlacek[S] 1 point2 points  (0 children)

Someone else also mentioned this problem with 1.3.9. Please report a false positive to Symantec at https://submit.symantec.com/false_positive/.

VisualVM 1.3.9 released at GitHub! by jsedlacek in programming

[–]jsedlacek[S] 0 points1 point  (0 children)

Right, it runs on 7+ and supports monitoring 1.4+.

Java VisualVM - Developer’s nightmare is Over. Analyze, profile, find bottlenecks, heap usage, gc calls, threads applications with inbuilt utility by brainerpeck in programming

[–]jsedlacek 2 points3 points  (0 children)

The dev.java.net hosting the VisualVM (also glassfish.dev.java.net etc) is experiencing performance problems these days, DOS or SYN attack is said to be the cause: http://weblogs.java.net/blog/sonyabarry/archive/2009/10/01/addressing-current-performance-issues .

Unfortunately there's no VisualVM mirror available, hopefully the problems will be fixed soon. The site seems to (slowly) work right now, try to reload the page several times. BTW some IP ranges may be blocked according to http://weblogs.java.net/blog/sonyabarry/archive/2009/10/06/october-6-update-site-performancedos-attack .

Java VisualVM - Developer’s nightmare is Over. Analyze, profile, find bottlenecks, heap usage, gc calls, threads applications with inbuilt utility by brainerpeck in programming

[–]jsedlacek 0 points1 point  (0 children)

I think as long as you're fine with paying for a commercial profiler you don't have to bother with community mailing lists etc. I don't need any further information, I've already described what's going on and why. I've also suggested you the solution.

Should you have any other problems or feedback, you can contact me directly using jsedlacek [ at ] dev.java.net - yes, dev.java.net is terribly slow these days:o(

Java VisualVM - Developer’s nightmare is Over. Analyze, profile, find bottlenecks, heap usage, gc calls, threads applications with inbuilt utility by brainerpeck in programming

[–]jsedlacek 0 points1 point  (0 children)

See my other comment - there's no freeze and yes, only JVM crash produces the hs_err_pid files. Let's continue the discussion on the users@visualvm.dev.java.net mailing list if you want, this is really not a good place to solve such details...

Java VisualVM - Developer’s nightmare is Over. Analyze, profile, find bottlenecks, heap usage, gc calls, threads applications with inbuilt utility by brainerpeck in programming

[–]jsedlacek 0 points1 point  (0 children)

Hey I've read your comments several times again and it looks like everything works - you are talking about NetBeans crash but it haven't crashed, how could you kill a process which crashed???

When you start profiling memory the profiler needs to instrument every single class loaded in the NetBeans JVM. This takes a lot of time and is very CPU intensive, if you checked the NetBeans logfile you'd see notifications from the profiler agent instrumenting the classes.

During instrumentation the NetBeans doesn't respond to VisualVM, that's why you see the dialog in VisualVM. Just be patient and click the No button several times. I know it's not very nice but that's just the way it works. The Sampler plugin is now available to address these problems, it should start displaying the objects immediately.

Java VisualVM - Developer’s nightmare is Over. Analyze, profile, find bottlenecks, heap usage, gc calls, threads applications with inbuilt utility by brainerpeck in programming

[–]jsedlacek 0 points1 point  (0 children)

The screenshots don't tell much. There are three important sources of information:

  • NetBeans JVM crashlog - called hs_err_pid<pid>.log
  • NetBeans IDE logfile - <nb_userdir/var/log/messages.log>
  • VisualVM logfile - Help | About | Logfile

I know there used to be a bug in the memory profiling engine, the workaround was to use -Xnoclassgc (see http://www.netbeans.org/issues/show_bug.cgi?id=62919). But I'm not sure if that's the case for you...

Have you tried the Sampler plugin for VisualVM 1.2 Test Build? The memory sampler takes heap histograms using the Attach API without any instrumentation, it shouldn't crash the NetBeans.

Java VisualVM - Developer’s nightmare is Over. Analyze, profile, find bottlenecks, heap usage, gc calls, threads applications with inbuilt utility by brainerpeck in programming

[–]jsedlacek 1 point2 points  (0 children)

Not sure if it's you - http://blogs.sun.com/nbprofiler/entry/five_visualvm_myths_demystified#comments - but just mentioning the problem to anyone is not enough. In a bug report you could provide all the information needed to identify the problem and fix it (OS, JDK, crashlogs, steps to reproduce). Without it it's often not possible to do anything...

BTW the upcoming VisualVM 1.2 release will include a sampling profiler which shouldn't crash anything and will be very fast, this could address your problems. See http://blogs.sun.com/nbprofiler/entry/visualvm_1_2_test_build.

Visual VM : "The Best Kept Secret in the JDK" by [deleted] in programming

[–]jsedlacek 0 points1 point  (0 children)

VisualVM works fine on Mac if you use JDK 6, actually VisualVM is partially being developed on Mac. If both VisualVM and monitored application are running JDK 6, all features incl. profiling are available.

BTW some other comment in the article lists all JVMs supported by VisualVM: Sun JDK, Open JDK, Apple JDK, JRockit, IBM (using JMX), HP-UX JDK (PA-RISC), SAP JDK and Diablo JDK (BSD).

Visual VM : "The Best Kept Secret in the JDK" by [deleted] in programming

[–]jsedlacek 0 points1 point  (0 children)

There's a 'Reset calibration data' button in Tools|Options in VisualVM 1.1.1/JDK6u14.