Re: Java profiling with systemtap

[fche at redhat dot com (Frank Ch. Eigler)]

=?ISO-8859-1?Q?Peter_S=FCttner?= <Peter.Suettner@mailbox.tu-dresden.de> writes:

> [...]
> I am currently involved in a project called CoolSoftware [...]

Sounds good.

> 1. To trace methods in Java, -XX+ExtendedDTraceProbes flag needs to be
> set at JVM start up.  They have a very high overhead, since probes
> seem to fire at every method call (and there are really a lot of them)
> made within the JVM process. I couldn't find a way to filter for
> specific method. Any suggestions?

Apparently, the Sun JVM instrumentation doesn't make this possible:
there is only one sdt.h-based activateable probe for all method
entries, and another one for exits.  Filtering after the fact is
indeed gross.

I believe the JVMTI run-time APIs allow more fine-grained control,
akin to your bytecode-rewriting work, but that is not accessible to
systemtap at this time.

It may be possible to have the JVM JIT expose data about the compiled
functions, and nominate for them individual breakpointable addresses
that e.g. systemtap could use, but this is a large chunk of work.


> 2. If the hotspot tapset is used, we are bound to a specific JVM,
> since the probe points are in the shared library of the JVM, aren't
> we?

The connection is not that tight.  The separate hotspot*.stp files
were necessary mainly because of the (former) absence of some features
in systemtap, such as wildcard-globbing in process("....") file names.


> So far, I am using a workaround. I am using bytecode instrumentation
> to inject something like
> 'System.out.println("Package.Class.Methodname.method_entry")' at
> method entry,
> and
> 'System.out.println("Package.Class.Methodname.method_exit")' at method
> return (only for methods we are interested in)
> This causes a write() syscall and it's argument is parsed in a
> systemtap script. In combination with the TID, it should be possible
> to connect specific resource usage to the currently executed
> method. That way I can keep track of a specific subset of methods and
> it is still independent of a specific JVM.

A clever hack, and for now, it may be about the best one can do.


- FChE