30 May, 2020

1 commit

  • For each PC/BCI pair in the JVMTI compiler inlining record table, the
    jitdump plugin emits debug line table entries for every source line in
    the method preceding that BCI. Instead only emit one source line per
    PC/BCI pair. Reported by Ian Rogers. This reduces the .dump size for
    SPECjbb from ~230MB to ~40MB.

    Signed-off-by: Nick Gasson
    Acked-by: Ian Rogers
    Cc: Jiri Olsa
    Cc: Peter Zijlstra
    Cc: Stephane Eranian
    Link: http://lore.kernel.org/lkml/20200528054049.13662-1-nick.gasson@arm.com
    Signed-off-by: Arnaldo Carvalho de Melo

    Nick Gasson
     

28 May, 2020

2 commits

  • If the Java sources are compiled with -g:none to disable debug
    information the perf JVMTI plugin reports a lot of errors like:

    java: GetLineNumberTable failed with JVMTI_ERROR_ABSENT_INFORMATION
    java: GetLineNumberTable failed with JVMTI_ERROR_ABSENT_INFORMATION
    java: GetLineNumberTable failed with JVMTI_ERROR_ABSENT_INFORMATION
    java: GetLineNumberTable failed with JVMTI_ERROR_ABSENT_INFORMATION
    java: GetLineNumberTable failed with JVMTI_ERROR_ABSENT_INFORMATION

    Instead if GetLineNumberTable returns JVMTI_ERROR_ABSENT_INFORMATION
    simply skip emitting line number information for that method. Unlike the
    previous patch these errors don't affect the jitdump generation, they
    just generate a lot of noise.

    Similarly for native methods which also don't have line tables.

    Signed-off-by: Nick Gasson
    Reviewed-by: Ian Rogers
    Tested-by: Ian Rogers
    Cc: Alexander Shishkin
    Cc: Jiri Olsa
    Cc: Mark Rutland
    Cc: Namhyung Kim
    Cc: Peter Zijlstra
    Link: http://lore.kernel.org/lkml/20200427061520.24905-3-nick.gasson@arm.com
    [ Moved || operator to the end of the line, not at the start of 2nd if condition ]
    Signed-off-by: Arnaldo Carvalho de Melo

    Nick Gasson
     
  • If a Java class is compiled with -g:none to omit debug information, the
    JVMTI plugin won't write jitdump entries for any method in this class
    and prints a lot of errors like:

    java: GetSourceFileName failed with JVMTI_ERROR_ABSENT_INFORMATION

    The call to GetSourceFileName is used to derive the file name `fn`, but
    this value is not actually used since commit ca58d7e64bdf ("perf jvmti:
    Generate correct debug information for inlined code") which moved the
    file name lookup into fill_source_filenames(). So the call to
    GetSourceFileName and related code can be safely removed.

    Signed-off-by: Nick Gasson
    Reviewed-by: Ian Rogers
    Tested-by: Ian Rogers
    Cc: Alexander Shishkin
    Cc: Jiri Olsa
    Cc: Mark Rutland
    Cc: Namhyung Kim
    Cc: Peter Zijlstra
    Link: http://lore.kernel.org/lkml/20200427061520.24905-2-nick.gasson@arm.com
    Signed-off-by: Arnaldo Carvalho de Melo

    Nick Gasson
     

15 Oct, 2019

1 commit

  • The build of file libperf-jvmti.so succeeds but the resulting
    object fails to load:

    # ~/linux/tools/perf/perf record -k mono -- java \
    -XX:+PreserveFramePointer \
    -agentpath:/root/linux/tools/perf/libperf-jvmti.so \
    hog 100000 123450
    Error occurred during initialization of VM
    Could not find agent library /root/linux/tools/perf/libperf-jvmti.so
    in absolute path, with error:
    /root/linux/tools/perf/libperf-jvmti.so: undefined symbol: _ctype

    Add the missing _ctype symbol into the build script.

    Fixes: 79743bc927f6 ("perf jvmti: Link against tools/lib/string.o to have weak strlcpy()")
    Signed-off-by: Thomas Richter
    Cc: Heiko Carstens
    Cc: Vasily Gorbik
    Link: http://lore.kernel.org/lkml/20191008093841.59387-1-tmricht@linux.ibm.com
    Signed-off-by: Arnaldo Carvalho de Melo

    Thomas Richter
     

20 Sep, 2019

1 commit

  • That is needed in systems such some S/390 distros.

    $ readelf -s /tmp/build/perf/jvmti/jvmti-in.o | grep strlcpy
    452: 0000000000002990 125 FUNC WEAK DEFAULT 119 strlcpy
    $

    Thanks to Jiri Olsa for fixing up my initial stab at this, I forgot how
    Makefiles are picky about spaces versus tabs.

    Reported-by: Thomas Richter
    Cc: Adrian Hunter
    Cc: Andreas Krebbel
    Cc: Jiri Olsa
    Cc: Namhyung Kim
    Cc: Sergey Melnikov
    Link: https://lkml.kernel.org/n/tip-x8vg9sffgb2t1tzqmhkrulh7@git.kernel.org
    Signed-off-by: Arnaldo Carvalho de Melo

    Arnaldo Carvalho de Melo
     

18 Jun, 2019

1 commit

  • Laura reported that the perf build failed in fedora when we got a glibc
    that provides gettid(), which I reproduced using fedora rawhide with the
    glibc-devel-2.29.9000-26.fc31.x86_64 package.

    Add a feature check to avoid providing a gettid() helper in such
    systems.

    On a fedora rawhide system with this patch applied we now get:

    [root@7a5f55352234 perf]# grep gettid /tmp/build/perf/FEATURE-DUMP
    feature-gettid=1
    [root@7a5f55352234 perf]# cat /tmp/build/perf/feature/test-gettid.make.output
    [root@7a5f55352234 perf]# ldd /tmp/build/perf/feature/test-gettid.bin
    linux-vdso.so.1 (0x00007ffc6b1f6000)
    libc.so.6 => /lib64/libc.so.6 (0x00007f04e0a74000)
    /lib64/ld-linux-x86-64.so.2 (0x00007f04e0c47000)
    [root@7a5f55352234 perf]# nm /tmp/build/perf/feature/test-gettid.bin | grep -w gettid
    U gettid@@GLIBC_2.30
    [root@7a5f55352234 perf]#

    While on a fedora:29 system:

    [acme@quaco perf]$ grep gettid /tmp/build/perf/FEATURE-DUMP
    feature-gettid=0
    [acme@quaco perf]$ cat /tmp/build/perf/feature/test-gettid.make.output
    test-gettid.c: In function ‘main’:
    test-gettid.c:8:9: error: implicit declaration of function ‘gettid’; did you mean ‘getgid’? [-Werror=implicit-function-declaration]
    return gettid();
    ^~~~~~
    getgid
    cc1: all warnings being treated as errors
    [acme@quaco perf]$

    Reported-by: Laura Abbott
    Tested-by: Laura Abbott
    Acked-by: Jiri Olsa
    Cc: Adrian Hunter
    Cc: Florian Weimer
    Cc: Namhyung Kim
    Cc: Stephane Eranian
    Link: https://lkml.kernel.org/n/tip-yfy3ch53agmklwu9o7rlgf9c@git.kernel.org
    Signed-off-by: Arnaldo Carvalho de Melo

    Arnaldo Carvalho de Melo
     

05 Jun, 2019

1 commit

  • We are getting false positive gcc warning when we compile with gcc9 (9.1.1):

    CC jvmti/libjvmti.o
    In file included from /usr/include/string.h:494,
    from jvmti/libjvmti.c:5:
    In function ‘strncpy’,
    inlined from ‘copy_class_filename.constprop’ at jvmti/libjvmti.c:166:3:
    /usr/include/bits/string_fortified.h:106:10: error: ‘__builtin_strncpy’ specified bound depends on the length of the source argument [-Werror=stringop-overflow=]
    106 | return __builtin___strncpy_chk (__dest, __src, __len, __bos (__dest));
    | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    jvmti/libjvmti.c: In function ‘copy_class_filename.constprop’:
    jvmti/libjvmti.c:165:26: note: length computed here
    165 | size_t file_name_len = strlen(file_name);
    | ^~~~~~~~~~~~~~~~~
    cc1: all warnings being treated as errors

    As per Arnaldo's suggestion use strlcpy(), which does the same thing and keeps
    gcc silent.

    Suggested-by: Arnaldo Carvalho de Melo
    Signed-off-by: Jiri Olsa
    Cc: Alexander Shishkin
    Cc: Ben Gainey
    Cc: Namhyung Kim
    Cc: Peter Zijlstra
    Cc: Stephane Eranian
    Link: http://lkml.kernel.org/r/20190531131321.GB1281@krava
    Signed-off-by: Arnaldo Carvalho de Melo

    Jiri Olsa
     

22 Nov, 2018

1 commit

  • The Compiled Method Load Record (cmlr) is JDK specific interface to
    access JVM stack info. This makes the jvmti agent code not compile under
    another jdk, which does not support that.

    Separating jvmti cmlr check into special feature check, and adding
    HAVE_JVMTI_CMLR macro to indicate that.

    Mark cmlr code in jvmti/libjvmti.c with HAVE_JVMTI_CMLR, so we can
    compile it on system without cmlr support.

    This change makes the jvmti compile with java-1.8.0-ibm package. It's
    without the line numbers support, but the rest works.

    Adding NO_JVMTI_CMLR compile variable for testing.

    Signed-off-by: Jiri Olsa
    Cc: Alexander Shishkin
    Cc: Ben Gainey
    Cc: Gustavo Luiz Duarte
    Cc: Namhyung Kim
    Cc: Peter Zijlstra
    Cc: Stephane Eranian
    Link: http://lkml.kernel.org/r/20181121154341.21521-1-jolsa@kernel.org
    Signed-off-by: Arnaldo Carvalho de Melo

    Jiri Olsa
     

06 Nov, 2018

1 commit

  • Currently jvmti agent can not be used because function scnprintf is not
    present in the agent libperf-jvmti.so. As a result the JVM when using
    such agent to record JITed code profiling information will fail on
    looking up scnprintf:

    java: symbol lookup error: lib/libperf-jvmti.so: undefined symbol: scnprintf

    This commit fixes that by reverting to the use of snprintf, that can be
    looked up, instead of scnprintf, adding a proper check for the returned
    value in order to print a better error message when the jitdump file
    pathname is too long. Checking the returned value also helps to comply
    with some recent gcc versions, like gcc8, which will fail due to
    truncated writing checks related to the -Werror=format-truncation= flag.

    Signed-off-by: Gustavo Romero
    Acked-by: Jiri Olsa
    LPU-Reference: 1541117601-18937-2-git-send-email-gromero@linux.vnet.ibm.com
    Link: https://lkml.kernel.org/n/tip-mvpxxxy7wnzaj74cq75muw3f@git.kernel.org
    Signed-off-by: Arnaldo Carvalho de Melo

    Gustavo Romero
     

11 Jul, 2018

1 commit

  • We are getting following warnings on gcc8 that break compilation:

    $ make
    CC jvmti/jvmti_agent.o
    jvmti/jvmti_agent.c: In function ‘jvmti_open’:
    jvmti/jvmti_agent.c:252:35: error: ‘/jit-’ directive output may be truncated \
    writing 5 bytes into a region of size between 1 and 4096 [-Werror=format-truncation=]
    snprintf(dump_path, PATH_MAX, "%s/jit-%i.dump", jit_path, getpid());

    There's no point in checking the result of snprintf call in
    jvmti_open, the following open call will fail in case the
    name is mangled or too long.

    Using tools/lib/ function scnprintf that touches the return value from
    the snprintf() calls and thus get rid of those warnings.

    $ make DEBUG=1
    CC arch/x86/util/perf_regs.o
    arch/x86/util/perf_regs.c: In function ‘arch_sdt_arg_parse_op’:
    arch/x86/util/perf_regs.c:229:4: error: ‘strncpy’ output truncated before terminating nul
    copying 2 bytes from a string of the same length [-Werror=stringop-truncation]
    strncpy(prefix, "+0", 2);
    ^~~~~~~~~~~~~~~~~~~~~~~~

    Using scnprintf instead of the strncpy (which we know is safe in here)
    to get rid of that warning.

    Signed-off-by: Jiri Olsa
    Cc: Alexander Shishkin
    Cc: David Ahern
    Cc: Namhyung Kim
    Cc: Peter Zijlstra
    Link: http://lkml.kernel.org/r/20180702134202.17745-1-jolsa@kernel.org
    Signed-off-by: Arnaldo Carvalho de Melo

    Jiri Olsa
     

18 Dec, 2017

1 commit

  • tools/perf/jvmti is broken in so far as it generates incorrect debug
    information. Specifically it attributes all debug lines to the original
    method being output even in the case that some code is being inlined
    from elsewhere. This patch fixes the issue.

    To test (from within linux/tools/perf):

    export JDIR=/usr/lib/jvm/java-8-openjdk-amd64/
    make
    cat << __EOF > Test.java
    public class Test
    {
    private StringBuilder b = new StringBuilder();

    private void loop(int i, String... args)
    {
    for (String a : args)
    b.append(a);

    long hc = b.hashCode() * System.nanoTime();

    b = new StringBuilder();
    b.append(hc);

    System.out.printf("Iteration %d = %d\n", i, hc);
    }

    public void run(String... args)
    {
    for (int i = 0; i < 10000; ++i)
    {
    loop(i, args);
    }
    }

    public static void main(String... args)
    {
    Test t = new Test();
    t.run(args);
    }
    }
    __EOF
    $JDIR/bin/javac Test.java
    ./perf record -F 10000 -g -k mono $JDIR/bin/java -agentpath:`pwd`/libperf-jvmti.so Test
    ./perf inject --jit -i perf.data -o perf.data.jitted
    ./perf annotate -i perf.data.jitted --stdio | grep Test\.java: | sort -u

    Before this patch, Test.java line numbers get reported that are greater
    than the number of lines in the Test.java file. They come from the
    source file of the inlined function, e.g. java/lang/String.java:1085.
    For further validation one can examine those lines in the JDK source
    distribution and confirm that they map to inlined functions called by
    Test.java.

    After this patch, the filename of the inlined function is output
    rather than the incorrect original source filename.

    Signed-off-by: Ben Gainey
    Tested-by: Arnaldo Carvalho de Melo
    Tested-by: Stephane Eranian
    Cc: Alexander Shishkin
    Cc: Ben Gainey
    Cc: Colin King
    Cc: Darren Hart
    Cc: Jiri Olsa
    Cc: Namhyung Kim
    Cc: Peter Zijlstra
    Cc: Thomas Gleixner
    Fixes: 598b7c6919c7 ("perf jit: add source line info support")
    Link: http://lkml.kernel.org/r/20171122182541.d25599a3eb1ada3480d142fa@arm.com
    Signed-off-by: Kim Phillips
    Signed-off-by: Arnaldo Carvalho de Melo

    Ben Gainey
     

02 Nov, 2017

1 commit

  • Many source files in the tree are missing licensing information, which
    makes it harder for compliance tools to determine the correct license.

    By default all files without license information are under the default
    license of the kernel, which is GPL version 2.

    Update the files which contain no license information with the 'GPL-2.0'
    SPDX license identifier. The SPDX identifier is a legally binding
    shorthand, which can be used instead of the full boiler plate text.

    This patch is based on work done by Thomas Gleixner and Kate Stewart and
    Philippe Ombredanne.

    How this work was done:

    Patches were generated and checked against linux-4.14-rc6 for a subset of
    the use cases:
    - file had no licensing information it it.
    - file was a */uapi/* one with no licensing information in it,
    - file was a */uapi/* one with existing licensing information,

    Further patches will be generated in subsequent months to fix up cases
    where non-standard license headers were used, and references to license
    had to be inferred by heuristics based on keywords.

    The analysis to determine which SPDX License Identifier to be applied to
    a file was done in a spreadsheet of side by side results from of the
    output of two independent scanners (ScanCode & Windriver) producing SPDX
    tag:value files created by Philippe Ombredanne. Philippe prepared the
    base worksheet, and did an initial spot review of a few 1000 files.

    The 4.13 kernel was the starting point of the analysis with 60,537 files
    assessed. Kate Stewart did a file by file comparison of the scanner
    results in the spreadsheet to determine which SPDX license identifier(s)
    to be applied to the file. She confirmed any determination that was not
    immediately clear with lawyers working with the Linux Foundation.

    Criteria used to select files for SPDX license identifier tagging was:
    - Files considered eligible had to be source code files.
    - Make and config files were included as candidates if they contained >5
    lines of source
    - File already had some variant of a license header in it (even if
    Reviewed-by: Philippe Ombredanne
    Reviewed-by: Thomas Gleixner
    Signed-off-by: Greg Kroah-Hartman

    Greg Kroah-Hartman
     

27 Jun, 2017

1 commit

  • Trivial fix to typo in jvmti_close() warnx warning message.

    Signed-off-by: Colin King
    Cc: Alexander Shishkin
    Cc: Dan Carpenter
    Cc: Peter Zijlstra
    Cc: Stephane Eranian
    Link: http://lkml.kernel.org/r/20170627124917.19151-1-colin.king@canonical.com
    Signed-off-by: Arnaldo Carvalho de Melo

    Colin Ian King
     

20 Jun, 2017

1 commit


14 Nov, 2016

2 commits

  • Now when jvmti compilation is plugged into Makefile.perf, there's no
    need for this makefile.

    Signed-off-by: Jiri Olsa
    Acked-by: Stephane Eranian
    Cc: Andi Kleen
    Cc: David Ahern
    Cc: Jiri Olsa
    Cc: Namhyung Kim
    Cc: Peter Zijlstra
    Cc: William Cohen
    Link: http://lkml.kernel.org/r/20161112121016.GA17194@krava
    Signed-off-by: Arnaldo Carvalho de Melo

    Jiri Olsa
     
  • Compile jvmti agent as part of the perf build. The agent library is
    called libperf-jvmti.so and is installed in default place together with
    other files:

    $ make libperf-jvmti.so
    BUILD: Doing 'make -j4' parallel build
    ...
    CC jvmti/libjvmti.o
    CC jvmti/jvmti_agent.o
    LD jvmti/jvmti-in.o
    LINK libperf-jvmti.so

    $ make DESTDIR=/tmp/krava/ install-bin
    ...
    $ find /tmp/krava/ | grep libperf
    /tmp/krava/lib64/libperf-jvmti.so
    /tmp/krava/lib64/libperf-gtk.so

    Signed-off-by: Jiri Olsa
    Tested-by: Arnaldo Carvalho de Melo
    Tested-by: Stephane Eranian
    Cc: Andi Kleen
    Cc: David Ahern
    Cc: Namhyung Kim
    Cc: Peter Zijlstra
    Cc: William Cohen
    Link: http://lkml.kernel.org/r/1478093749-5602-4-git-send-email-jolsa@kernel.org
    Signed-off-by: Arnaldo Carvalho de Melo

    Jiri Olsa
     

24 Oct, 2016

2 commits

  • This patch removes all the string padding generated in the jitdump file.
    They are not necessary and were adding unnecessary complexity. Modern
    processors can handle unaligned accesses quite well. The perf.data/
    jitdump file are always post-processed, no need to add extra complexity
    for no real gain.

    Signed-off-by: Stephane Eranian
    Cc: Anton Blanchard
    Cc: Jiri Olsa
    Cc: Namhyung Kim
    Cc: Peter Zijlstra
    Link: http://lkml.kernel.org/r/1476356383-30100-4-git-send-email-eranian@google.com
    Signed-off-by: Arnaldo Carvalho de Melo

    Stephane Eranian
     
  • This patch improves the usefulness of error messages generated by the
    JVMTI interfac.e This can help identify the root cause of a problem by
    printing the actual error code. The patch adds a new helper function
    called print_error().

    Signed-off-by: Stephane Eranian
    Cc: Anton Blanchard
    Cc: Jiri Olsa
    Cc: Namhyung Kim
    Cc: Nilay Vaish
    Cc: Peter Zijlstra
    Link: http://lkml.kernel.org/r/1476356383-30100-2-git-send-email-eranian@google.com
    [ Handle failure to convert numeric error to a string in print_error() ]
    Signed-off-by: Arnaldo Carvalho de Melo

    Stephane Eranian
     

17 Oct, 2016

1 commit

  • When building on Ubuntu 16.04, I get the following error:

    Makefile:49: *** the openjdk development package appears to me missing, install and try again. Stop.

    The problem is that update-java-alternatives has multiple spaces between
    fields, and cut treats each space as a new delimiter:

    java-1.8.0-openjdk-ppc64el 1081 /usr/lib/jvm/java-1.8.0-openjdk-ppc64el

    Fix this by using awk, which handles this fine.

    Signed-off-by: Anton Blanchard
    Reviewed-by: Stephane Eranian
    Cc: Alexander Shishkin
    Cc: Peter Zijlstra
    Link: http://lkml.kernel.org/r/1476325243-15788-1-git-send-email-anton@ozlabs.org
    Signed-off-by: Arnaldo Carvalho de Melo

    Anton Blanchard
     

18 Jul, 2016

2 commits

  • The 'info.e_machine' struct member is an uint16_t so 'm' is never less
    than zero. It looks like this was maybe left over code from earlier
    versions so I've just removed it.

    Signed-off-by: Dan Carpenter
    Cc: Adrian Hunter
    Cc: Alexander Shishkin
    Cc: Peter Zijlstra
    Cc: Stephane Eranian
    Cc: kernel-janitors@vger.kernel.org
    Link: http://lkml.kernel.org/r/20160715210836.GB19522@mwanda
    Signed-off-by: Arnaldo Carvalho de Melo

    Dan Carpenter
     
  • It doesn't change the runtime behavior, but my static checker complains
    that curly braces were intended.

    Signed-off-by: Dan Carpenter
    Cc: Adrian Hunter
    Cc: Alexander Shishkin
    Cc: Peter Zijlstra
    Cc: Stephane Eranian
    Cc: kernel-janitors@vger.kernel.org
    Link: http://lkml.kernel.org/r/20160715210712.GA19522@mwanda
    Signed-off-by: Arnaldo Carvalho de Melo

    Dan Carpenter
     

02 Apr, 2016

1 commit

  • Intel PT uses TSC as a timestamp, so add support for using TSC instead
    of the monotonic clock. Use of TSC is selected by an environment
    variable "JITDUMP_USE_ARCH_TIMESTAMP" and flagged in the jitdump file
    with flag JITDUMP_FLAGS_ARCH_TIMESTAMP.

    Signed-off-by: Adrian Hunter
    Cc: Alexander Shishkin
    Cc: He Kuang
    Cc: Jiri Olsa
    Cc: Josh Poimboeuf
    Cc: Peter Zijlstra
    Cc: Stephane Eranian
    Cc: Sukadev Bhattiprolu
    Cc: Wang Nan
    Link: http://lkml.kernel.org/r/1457426330-30226-1-git-send-email-adrian.hunter@intel.com
    [ Added the fixup from He Kuang to make it build on other arches, ]
    [ such as aarch64, to avoid inserting this bisectiong breakage upstream ]
    Link: http://lkml.kernel.org/r/1459482572-129494-1-git-send-email-hekuang@huawei.com
    Signed-off-by: Arnaldo Carvalho de Melo

    Adrian Hunter
     

25 Feb, 2016

1 commit

  • This patch improves the error message given by jvmti Makefile when the
    alternatives command cannot be found. It now suggests the user locates
    the root of their Java installation and pass it with JDIR=

    Signed-off-by: Stephane Eranian
    Cc: Adrian Hunter
    Cc: Andi Kleen
    Cc: Jiri Olsa
    Cc: Kan Liang
    Cc: Namhyung Kim
    Cc: Peter Zijlstra
    Link: http://lkml.kernel.org/r/1456378056-18812-1-git-send-email-eranian@google.com
    Signed-off-by: Arnaldo Carvalho de Melo

    Stephane Eranian
     

17 Feb, 2016

1 commit

  • This patch modifies the jvmti makefile to check if the
    /usr/sbin/java-update-alternatives utility is present. If so, then use
    it, if not then use the altenatives command.

    This helps handle the difference between Ubuntu and Fedora Linux
    distributions.

    Signed-off-by: Stephane Eranian
    Tested-by: Arnaldo Carvalho de Melo
    Cc: Adrian Hunter
    Cc: Andi Kleen
    Cc: David Ahern
    Cc: Jiri Olsa
    Cc: Kan Liang
    Cc: Namhyung Kim
    Cc: Peter Zijlstra
    Link: http://lkml.kernel.org/r/1455604661-9357-1-git-send-email-eranian@google.com
    Signed-off-by: Arnaldo Carvalho de Melo

    Stephane Eranian
     

05 Feb, 2016

2 commits

  • This patch adds source line information support to perf for jitted code.

    The source line info must be emitted by the runtime, such as JVMTI.

    Perf injects extract the source line info from the jitdump file and adds
    the corresponding .debug_lines section in the ELF image generated for
    each jitted function.

    The source line enables matching any address in the profile with a
    source file and line number.

    The improvement is visible in perf annotate with the source code
    displayed alongside the assembly code.

    The dwarf code leverages the support from OProfile which is also
    released under GPLv2. Copyright 2007 OProfile authors.

    Signed-off-by: Stephane Eranian
    Cc: Adrian Hunter
    Cc: Andi Kleen
    Cc: Carl Love
    Cc: David Ahern
    Cc: Jiri Olsa
    Cc: John McCutchan
    Cc: Namhyung Kim
    Cc: Pawel Moll
    Cc: Peter Zijlstra
    Cc: Sonny Rao
    Cc: Sukadev Bhattiprolu
    Link: http://lkml.kernel.org/r/1448874143-7269-5-git-send-email-eranian@google.com
    Signed-off-by: Arnaldo Carvalho de Melo

    Stephane Eranian
     
  • This is a standalone JVMTI library to help profile Java jitted code with perf
    record/perf report. The library is not installed or compiled automatically by
    perf Makefile. It is not used directly by perf. It is arch agnostic and has
    been tested on X86 and ARM. It needs to be used with a Java runtime, such as
    OpenJDK, as follows:

    $ java -agentpath:libjvmti.so .......

    See the "Committer Notes" below on how to build it.

    When used this way, java will generate a jitdump binary file in
    $HOME/.debug/java/jit/java-jit-*

    This binary dump file contains information to help symbolize and
    annotate jitted code.

    The jitdump information must be injected into the perf.data file
    using:

    $ perf inject --jit -i perf.data -o perf.data.jitted

    This injects the MMAP records to cover the jitted code and also generates
    one ELF image for each jitted function. The ELF images are created in the
    same subdir as the jitdump file. The MMAP records point there too.

    Then, to visualize the function or asm profile, simply use the regular
    perf commands:

    $ perf report -i perf.data.jitted

    or

    $ perf annotate -i perf.data.jitted

    JVMTI agent code adapted from the OProfile's opagent code.

    This version of the JVMTI agent is using the CLOCK_MONOTONIC as the time
    source to timestamp jit samples. To correlate with perf_events samples,
    it needs to run on kernel 4.0.0-rc5+ or later with the following commit
    from Peter Zijlstra:

    34f439278cef ("perf: Add per event clockid support")

    With this patch recording jitted code is done as follows:

    $ perf record -k mono -- java -agentpath:libjvmti.so .......

    --------------------------------------------------------------------------

    Committer Notes:

    Extended testing instructions:

    $ cd tools/perf/jvmti/
    $ dnf install java-devel
    $ make

    Then, create some simple java stuff to record some samples:

    $ cat hello.java
    public class hello {
    public static void main(String[] args) {
    System.out.println("Hello, World");
    }
    }
    $ javac hello.java
    $ java hello
    Hello, World
    $

    And then record it using this jvmti thing:

    $ perf record -k mono java -agentpath:/home/acme/git/linux/tools/perf/jvmti/libjvmti.so hello
    java: jvmti: jitdump in /home/acme/.debug/jit/java-jit-20160205.XXWIEDls/jit-1908.dump
    Hello, World
    [ perf record: Woken up 1 times to write data ]
    [ perf record: Captured and wrote 0.030 MB perf.data (268 samples) ]
    $

    Now lets insert the PERF_RECORD_MMAP2 records to point jitted mmaps to
    files created by the agent:

    $ perf inject --jit -i perf.data -o perf.data.jitted

    And finally see that it did its job:

    $ perf report -D -i perf.data.jitted | grep PERF_RECORD_MMAP2 | tail -5
    79197149129422 0xfe10 [0xa0]: PERF_RECORD_MMAP2 1908/1923: [0x7f172428bd60(0x80) @ 0x40 fd:02 1840554 1]: --xs /home/acme/.debug/jit/java-jit-20160205.XXWIEDls/jitted-1908-283.so
    79197149235701 0xfeb0 [0xa0]: PERF_RECORD_MMAP2 1908/1923: [0x7f172428ba60(0x180) @ 0x40 fd:02 1840555 1]: --xs /home/acme/.debug/jit/java-jit-20160205.XXWIEDls/jitted-1908-284.so
    79197149250558 0xff50 [0xa0]: PERF_RECORD_MMAP2 1908/1923: [0x7f172428b860(0x180) @ 0x40 fd:02 1840556 1]: --xs /home/acme/.debug/jit/java-jit-20160205.XXWIEDls/jitted-1908-285.so
    79197149714746 0xfff0 [0xa0]: PERF_RECORD_MMAP2 1908/1923: [0x7f172428b660(0x180) @ 0x40 fd:02 1840557 1]: --xs /home/acme/.debug/jit/java-jit-20160205.XXWIEDls/jitted-1908-286.so
    79197149806558 0x10090 [0xa0]: PERF_RECORD_MMAP2 1908/1923: [0x7f172428b460(0x180) @ 0x40 fd:02 1840558 1]: --xs /home/acme/.debug/jit/java-jit-20160205.XXWIEDls/jitted-1908-287.so
    $

    So:

    $ perf report -D -i perf.data | grep PERF_RECORD_MMAP2 | wc -l
    Failed to open /tmp/perf-1908.map, continuing without symbols
    21
    $ perf report -D -i perf.data.jitted | grep PERF_RECORD_MMAP2 | wc -l
    307
    $ echo $((307 - 21))
    286
    $

    286 extra PERF_RECORD_MMAP2 records.

    All for thise tiny, with just one function, ELF files:

    $ file /home/acme/.debug/jit/java-jit-20160205.XXWIEDls/jitted-1908-9.so
    /home/acme/.debug/jit/java-jit-20160205.XXWIEDls/jitted-1908-9.so: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), corrupted program header size, BuildID[sha1]=ae54a2ebc3ecf0ba547bfc8cabdea1519df5203f, not stripped
    $ readelf -sw /home/acme/.debug/jit/java-jit-20160205.XXWIEDls/jitted-1908-9.so

    Symbol table '.symtab' contains 2 entries:
    Num: Value Size Type Bind Vis Ndx Name
    0: 0000000000000000 0 NOTYPE LOCAL DEFAULT UND
    1: 0000000000000040 9 FUNC LOCAL DEFAULT 1 atomic_cmpxchg_long
    $

    Inserted into the build-id cache:

    $ ls -la ~/.debug/.build-id/ae/54a2ebc3ecf0ba547bfc8cabdea1519df5203f
    lrwxrwxrwx. 1 acme acme 111 Feb 5 11:30 /home/acme/.debug/.build-id/ae/54a2ebc3ecf0ba547bfc8cabdea1519df5203f -> ../../home/acme/.debug/jit/java-jit-20160205.XXWIEDls/jitted-1908-9.so/ae54a2ebc3ecf0ba547bfc8cabdea1519df5203f

    Note: check why 'file' reports that 'corrupted program header size'.

    With a stupid java hog to do some profiling:

    $ cat hog.java
    public class hog {
    private static double do_something_else(int i) {
    double total = 0;
    while (i > 0) {
    total += Math.log(i--);
    }
    return total;
    }
    private static double do_something(int i) {
    double total = 0;
    while (i > 0) {
    total += Math.sqrt(i--) + do_something_else(i / 100);
    }
    return total;
    }
    public static void main(String[] args) {
    System.out.println(String.format("%s=%f & %f", args[0],
    do_something(Integer.parseInt(args[0])),
    do_something_else(Integer.parseInt(args[1]))));
    }
    }
    $ javac hog.java
    $ perf record -F 10000 -g -k mono java -agentpath:/home/acme/git/linux/tools/perf/jvmti/libjvmti.so hog 100000 2345000
    java: jvmti: jitdump in /home/acme/.debug/jit/java-jit-20160205.XX4sqd14/jit-8670.dump
    100000=291561592.669602 & 32050989.778714
    [ perf record: Woken up 6 times to write data ]
    [ perf record: Captured and wrote 1.536 MB perf.data (12538 samples) ]
    $ perf inject --jit -i perf.data -o perf.data.jitted

    Looking at the 'perf report' TUI, at one expanded callchain leading
    to the jitted code:

    $ perf report --no-children -i perf.data.jitted

    Samples: 12K of event 'cycles:pp', Event count (approx.): 3829569932
    Overhead Comm Shared Object Symbol
    - 93.38% java jitted-8670-291.so [.] class hog.do_something_else(int)
    class hog.do_something_else(int)
    - Interpreter
    - 75.86% call_stub
    JavaCalls::call_helper
    jni_invoke_static
    jni_CallStaticVoidMethod
    JavaMain
    start_thread
    - 17.52% JavaCalls::call_helper
    jni_invoke_static
    jni_CallStaticVoidMethod
    JavaMain
    start_thread

    Signed-off-by: Stephane Eranian
    Tested-by: Arnaldo Carvalho de Melo
    Cc: Adrian Hunter
    Cc: Andi Kleen
    Cc: Carl Love
    Cc: David Ahern
    Cc: Jiri Olsa
    Cc: John McCutchan
    Cc: Namhyung Kim
    Cc: Pawel Moll
    Cc: Peter Zijlstra
    Cc: Sonny Rao
    Cc: Sukadev Bhattiprolu
    Link: http://lkml.kernel.org/r/1448874143-7269-4-git-send-email-eranian@google.com
    [ Made it build on fedora23, added some build/usage instructions ]
    [ Check if filename != NULL in compiled_method_load_cb, fixing segfault ]
    Signed-off-by: Arnaldo Carvalho de Melo

    Stephane Eranian