On Sat, Feb 12, 2005 at 04:45:43PM +0100, Philippe
> On Mon, 07 Feb 2005 at 17:04 +0000, Scott T Jones wrote:
> > This patch adds two new functions to OProfile. First, it
adds the ability
> > to resolve addresses in anonymous processes, by integrating libopjdl.so
> > into OProfile. This builds upon the patch previously provided
> > Cohen. Second, it provides a Java profiler, libopjan.so,
> > the names of Java jitted methods, when combined with the first
> > This implements the following proposal on the oprofile-list:
> > http://sourceforge.net/mailarchive/forum.php?thread_id=5641225&forum_id=3252
> There is some minor things to change before applying it.
> - replace all msdos CR/LF in newly created file (e.g. op_jdl_bfd.c)
> - many s/return (xx);/return xx;/
Both of these items have been fixed.
> - patch contains some chunk diffing only by space, I prefer we avoid
> - some global var in new .c can be made static afaics
Could you give me one example of each of these?
> - Will Cohen patch must be updated and submitted to lkml:
> I get a look to the our current code and I don't think running a kernel
> with Will patch and an old oprofile version can hurt, cookie lookup
> NO_COOKIE will fail but the cookie will be hashed and no other lookup
> will occur, sample file open for cookie == 0 will fail silently but
> lost for these mapping will be accounted.
> The following can be addressed after applying the patch unless John
> - configure.in :
> +if ! ( test -f libopjan/jvmpi.h ) ; then
> + if test -f $JDKDIR/include/jvmpi.h ; then
> + cp -p $JDKDIR/include/jvmpi.h libopjan
> + else
> + echo You must copy jvmpi.h from your Java include directory
> + echo to the libopjan directory to use Java profiling.
> + fi
> this must be done only if --enable-opjan is given on command line
This check for jvmpi.h will be moved to libopjan/Makefile.am,
which already checks the --enable-opjan flag.
> - use of dso like:
> + ../libopjdl/.libs/libopjdl.so \
> + /usr/lib/libbfd.so \
> must be done conditionnaly or by building an empty dso and link with
I do not understand this. These DSOs are
always used, they are not
conditional. They provide support for identifying
even if --enable-opjan is not specified.
> - I don't understand why libopjdl.so must be linked with pp tools
I can understand that you do not want to possibly
taint your pp tools
with regressions. We only called libopjdl.so
from opreport to minimize
the window in which new addresses could be identified
in anonymous code.
We will create a stand-alone routine that can call
before invoking opreport. We had only hoped
to eliminate the possibility
that the user would omit this call.
> - I dunno if we want to create file under /tmp/oprofile or
> /var/lib/oprofile/sample/vm/java/, I prefer the second option.
At John Levon's request, the file will be created
> - later we will need to support multiple jitted source by getting
> interface from the tgid
This will be done.
> A question about unload method vs unload class. Can a class be unloaded
> w/o all of these methods unloaded first ?
I do not know. It may be JVM specific. However,
our code will automatically
unload all of the methods associated with a class
when the class is unloaded.
> What's the rationale behind the valid flag vs the removal of class
> method ? Is it to allow reuse a class or method after an unload then
> load event ?
It was implemented that way for ease of debugging. We can easily
code to delete these control blocks when classes
and methods are unloaded.
> John, I think we need to release oprofile 0.8.2 before appyling this
> > A compatible level of jvmpi.h (IBM or Sun 1.3 or above) must
be copied to
> > the libopjan directory before libopjan.so can be successfully
> > new configure script will copy this file from $JDKDIR/include
> > JDKDIR
> > environment variable has been set to the directory of the active
> > Note that libopjan.so is built using libtool, the presence of
> > tested at configure time.
> Looking at the code I see we need to compile oprofile for a specific
> either sun or ibm. People will prefer probably we support both of
> to figure out the right at runtime. Something to think about, not
> for the present patch
It was never our intention to require any specific
JVM. Our current code will
successfully build with the jvmpi.h from either
IBM or Sun and the version built
with the Sun jvmpi.h will work with either JVM.
However, it is true that a
version built with the IBM jvmpi.h will only work
with an IBM JVM. Therefore,
we will modify our code to ensure that all versions
work on any JVM.
> Philippe Elie
Thank you for your helpful comments.
Scott T Jones
WBI Performance II
IBM Corp, Austin, TX
Reply to: email@example.com
Phone: (512) 838-4758, T/L: 678-4758