All of lore.kernel.org
 help / color / mirror / Atom feed
From: Steve MacLean <Steve.MacLean@microsoft.com>
To: Ian Rogers <irogers@google.com>
Cc: Steve MacLean <steve.maclean@linux.microsoft.com>,
	Peter Zijlstra <peterz@infradead.org>,
	Ingo Molnar <mingo@redhat.com>,
	Arnaldo Carvalho de Melo <acme@kernel.org>,
	Mark Rutland <mark.rutland@arm.com>,
	Alexander Shishkin <alexander.shishkin@linux.intel.com>,
	Jiri Olsa <jolsa@redhat.com>, Namhyung Kim <namhyung@kernel.org>,
	Stephane Eranian <eranian@google.com>,
	LKML <linux-kernel@vger.kernel.org>
Subject: RE: [EXTERNAL] Re: [PATCH v4] perf inject --jit: Remove //anon mmap events
Date: Fri, 29 May 2020 18:48:51 +0000	[thread overview]
Message-ID: <MN2PR21MB1518D07AD29D0E744E2D4EA2F78F0@MN2PR21MB1518.namprd21.prod.outlook.com> (raw)
In-Reply-To: <CAP-5=fV7F4u66388HC-q8btOYWKxtb1gTTi4LK_Besb-zE25Rw@mail.gmail.com>

> I've been trying variants of:
>
> Before:
>/tmp/perf/perf record -k 1 -e cycles:u -o /tmp/perf.data java -agentpath:/tmp/perf/libperf-jvmti.so -XX:+PreserveFramePointer -XX:InitialCodeCacheSize=20M -XX:ReservedCodeCacheSize=1G -jar dacapo-9.12-bach.jar jython /tmp/perf/perf inject -i /tmp/perf.data -o /tmp/perf-jit.data -j /tmp/perf/perf report -i /tmp/perf-jit.data |grep class\ |wc -l
> 578
> /tmp/perf/perf report -i /tmp/perf-jit.data |grep unknown |wc -l
> 6
> 
> After:
> /tmp/perf/perf record -k 1 -e cycles:u -o /tmp/perf.data java -agentpath:/tmp/perf/libperf-jvmti.so -XX:+PreserveFramePointer -XX:InitialCodeCacheSize=20M -XX:ReservedCodeCacheSize=1G -jar dacapo-9.12-bach.jar jython /tmp/perf/perf inject -i /tmp/perf.data -o /tmp/perf-jit.data -j /tmp/perf/perf report -i /tmp/perf-jit.data |grep class\ |wc -l
> 589
> /tmp/perf/perf report -i /tmp/perf-jit.data |grep unknown |wc -l
> 60
>
> So maybe the jit cache isn't behaving the way that the patch cures, the uptick in unknowns appears consistent in my testing though. I expect user error, is there an obvious explanation I'm missing?

That is certainly disturbing. I don't see an obvious user error, but I haven't played with java jitdump

Couple of ideas come to mind.

+ When I was drafting .NET jitdump support, I looked briefly at the java agent.  My impression was the java agent support wasn't thread safe.  The jitdump file format requires that certain records are collocated to simplify the reader.  I wasn't sure how that was being accomplished by the writer if JAVA's JIT was multithreaded (like CoreCLR JIT is).

+ The way I implemented jitdump on CoreCLR was to hook into the existing system to write perf-map files.  So I am pretty confident there is a 1:1 correspondence of perf-map records with jitdump records.  Is it possible that Java choose to only emit interesting jitdump records?  Perhaps skipping thunks/stubs/trampolines?  

+ There are still some `unknown` records in CoreCLR, but I don't believe there is an increase.  I am pretty sure some of our stubs are not being generated.  They were present in our before case too.

+ Your methodology would be more repeatable if you record once, and analyze multiple times.  record, report, inject / report, inject / report

+ I was focusing on eliminating duplicate symbols for the same address.  So having the module name in the report allowed me to see if the symbol was from jitdump or from perf-map.  In the before case I could see duplicate symbols for the same address.  This was how the problem was first observed.

+ I would be more interested in looking at the diff of the reports.  Possibly sorted by address.  Probably with zero context.

If I were to guess, I would think Java choose to optimize jitdump and only record interesting code.

So if we need to support that scenario the approach of this patch wouldn't work.

We would need to use a different approach.  Ideas...
+ Keep anon mappings from overwriting jitdump mappings.  Introduce a weak add map method, that would only fill empty/anon.
+ Move the anon mapping timestamp to the beginning of time, so they are processed first
+ Fix the kernel perf map events
+ Keep the anon mappings in a separate fall back map

I kind of like the add weak map approach.

  reply	other threads:[~2020-05-29 18:48 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-05-27  1:51 [PATCH v4] perf inject --jit: Remove //anon mmap events Steve MacLean
2020-05-27 19:00 ` Ian Rogers
2020-05-27 19:27   ` [EXTERNAL] " Steve MacLean
2020-05-27 20:59     ` Ian Rogers
2020-05-28  9:32       ` Ian Rogers
2020-05-29 18:48         ` Steve MacLean [this message]
2020-05-29 21:44           ` Steve MacLean
2020-06-01  6:17         ` Nick Gasson
2020-06-01  8:53           ` Ian Rogers
2020-06-01 10:02             ` Nick Gasson
2020-06-12 19:00               ` Steve MacLean
2020-06-12 19:33                 ` Ian Rogers

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=MN2PR21MB1518D07AD29D0E744E2D4EA2F78F0@MN2PR21MB1518.namprd21.prod.outlook.com \
    --to=steve.maclean@microsoft.com \
    --cc=acme@kernel.org \
    --cc=alexander.shishkin@linux.intel.com \
    --cc=eranian@google.com \
    --cc=irogers@google.com \
    --cc=jolsa@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mark.rutland@arm.com \
    --cc=mingo@redhat.com \
    --cc=namhyung@kernel.org \
    --cc=peterz@infradead.org \
    --cc=steve.maclean@linux.microsoft.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.