How is VisualVM better than using internal OS utilities to profile anapplication?

[lbrtchx]

Hi,
~
when you profile an application you are profiling it in reference to
its OS/hardware
~
The reason I think using your OS is better, is that, say, when you
make a JDBC call the actual DB process is involved. Since the OS's
very job is administering these processes, it keeps registries of all
of them ...
~
How could a java VisualVM do a better job at it?
~
I don't think that this is what java was designed for, why is it now
part of the jdk?
~
thanks
lbrtchx
~
comp.lang.java.programmer
~

 

[Lew]

when you profile an application you are profiling it in reference to
its OS/hardware
Sometimes.

The reason I think using your OS is better, is that, say, when you
make a JDBC call the actual DB process is involved. Since the OS's

So are internals of the JVM or Java app server.

very job is administering these processes, it keeps registries of all
of them ...
Huh?

How could a java [sic] VisualVM do a better job at it?

Depends. Do you want to know what Java thinks of the resources, or what the
resources think of Java?

The OS isn't going to know shite about GC, for example. It won't know diddly
about Eden, Java threads, in-flight transactions, time within methods, ...

I don't think that this is what java [sic] was designed for, why is it now
part of the jdk?

Because others thought differently. Anyway, you have it backwards. Java
wasn't designed for VisualVM, VisualVM was designed for Java.

<https://visualvm.dev.java.net/>
will have answers to many of your questions, if not all of them.

 

[lbrtchx]

Thank you, I think I did generally get your points, but for example,
when you say:
~

The OS isn't going to know shite about GC, for example.

~
What do you mean? Isn't the OS be aware of some java process grabbing
inordinate amounts of memory or releasing it?
~
Also, what is the point of "knowing" about GC if you can't really
control it anyway? Sure you can change your coding strategies, but
this is pretty much there is to it
~

Java wasn't designed for VisualVM, VisualVM was designed for Java.

~
I meant Java was not design as a replacement for OS jobs and AFAIK
the java VM had always had a way to run it in profile/debug mode
anyway.
~
I am not sure I see the benefit of a huge /lib/visualvm trunk right
in the jdk
~
lbrtchx

 

[Lew]

Thank you, I think I did generally get your points, but for example,
when you say:
~
~
What do you mean? Isn't the OS be aware of some java process grabbing
inordinate amounts of memory or releasing it?

No.

GC occurs within the JVM, and the OS doesn't have a view inside the JVM.

Also, what is the point of "knowing" about GC if you can't really
control it anyway? Sure you can change your coding strategies, but
this is pretty much there is to it

You can, and should, control GC. Check out the -XX parameters. You can do
parallel GC, short-pause GC, high-throughput GC, control the ratios of Eden to
tenured generation - there are literally dozens of ways to control GC.

Java wasn't designed for VisualVM, VisualVM was designed for Java.

~
I meant Java was not design as a replacement for OS jobs and AFAIK
the java [sic] VM had always had a way to run it in profile/debug mode
anyway.

Oh, but VisualVM does so much more. Did you read the site?

I am not sure I see the benefit of a huge /lib/visualvm trunk right
in the jdk

That is clear.

 

[lbrtchx]

No.

GC occurs within the JVM, and the OS doesn't have a view inside the JVM.

~
I see
~

You can, and should, control GC. Check out the -XX parameters. You can do
parallel GC, short-pause GC, high-throughput GC, control the ratios of Eden to
tenured generation - there are literally dozens of ways to control GC.

~
What I can't still see is why was such a huge package included as
part of the jdk if this is only helpful to profile code, which happens
during development and prior to production. Once you functionally case
and stress test your code it isn't really needed (as I rightly and/or
wrongly understand things). Why wasn't it included as some sort of
profiling package?
~

Java wasn't designed for VisualVM, VisualVM was designed for Java.

~
I meant Java was not design as a replacement for OS jobs and AFAIK
the java [sic] VM had always had a way to run it in profile/debug mode
anyway.

Oh, but VisualVM does so much more. Did you read the site?

~
I did read some of it, but technical reasons aren't really -
scientific- ones and there is a tendency to accompany it with lots of
persuasive bs
~

That is clear.

~
well, at least something is ;-)
~
Thanks
lbrtchx

 

[alexandre_paterson]

The OS isn't going to know shite about GC, for example. It won't know diddly
about Eden, Java threads, in-flight transactions, time within methods, ...

Not completely related to the OP but it depends on your OS

If your OS supports DTrace (like (Open)Solaris or MacOS X ?) they
inserted lots of probe into Java and you can easily monitor a great
many interesting things, including GC.

Here's a DTrace example talking about GC, Eden, threads, etc.
that can all be monitored in real-time using dtrace:

http://raymondtay.blogspot.com/2008/06/monitoring-jvm-javase6-activity-using.html

As I understand it when the probes are unused the penalty on
the system is close to nil and even when they're in use the
penalty is very low.

Alex

 

[John B. Matthews]

Not completely related to the OP but it depends on your OS

If your OS supports DTrace (like (Open)Solaris or MacOS X ?) they
inserted lots of probe into Java and you can easily monitor a great
many interesting things, including GC.

If I may amplify, Mac OS 10.5 added DTrace support:

<http://www.apple.com/macosx/technology/unix.html>
<http://en.wikipedia.org/wiki/Instruments_(application)>

 

[Lew]

 What I can't still see is why was such a huge package included as
part of the jdk if this is only helpful to profile code, which happens
during development and prior to production. Once you functionally case
and stress test your code it isn't really needed (as I rightly and/or
wrongly understand things).

The JDK is *for* development. Including development tools with the
JDK is therefore entirely reasonable. Where else would one include
development tools but the development environment?

Why wasn't it included as some sort of profiling package?

It *is* "some sort of profiling package*, with a whole lot more
functionality besides.

On the one hand you complain that VisualVM shouldn't be included in
the developmnent environment, then on the other you call for the
functionality of VisualVM to be included in the development
environment. Which way do you really want it?

 

[lbrtchx]

The JDK is *for* development. Including development tools with the
JDK is therefore entirely reasonable. Where else would one include
development tools but the development environment?


It *is* "some sort of profiling package*, with a whole lot more
functionality besides.

On the one hand you complain that VisualVM shouldn't be included in
the developmnent environment, then on the other you call for the
functionality of VisualVM to be included in the development
environment. Which way do you really want it?

~
OK, my wording was not the clearest one on earth, but generally my
basic point/matter-of-fact intuition has been confirmed to some true
extent
~
Roughly speaking I think "development" (or this is at least the way I
myself and most developers I have met code) has two phases, one in
which coding iterations and baseline user trials are more important
and towards the end of the dev. cycle in which profiling and thorough
case and stress testing become more important
~
Also I am working on, JLive, a flexible CD-based (like knoppix) java
development environment , which goal is making java developers life
easier. One of the objectives is including at least the last three
jdks that sun keeps current and easily switch among them
~
There are package trunks in the jdk such a visualvm that I am planing
to let people include as an option at start up as an extra instead of
by default. That would be -nice- to the general working of JLive
~
lbrtchx