linux-kernel - Re: [PATCH 4/4] perf tools: add JVMTI agent library

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <54E450B4.6060100@intel.com>
Date:	Wed, 18 Feb 2015 10:43:32 +0200
From:	Adrian Hunter <adrian.hunter@...el.com>
To:	Stephane Eranian <eranian@...gle.com>
CC:	LKML <linux-kernel@...r.kernel.org>,
	Arnaldo Carvalho de Melo <acme@...hat.com>,
	Peter Zijlstra <peterz@...radead.org>,
	"mingo@...e.hu" <mingo@...e.hu>,
	"ak@...ux.intel.com" <ak@...ux.intel.com>,
	Jiri Olsa <jolsa@...hat.com>,
	Namhyung Kim <namhyung@...nel.org>,
	Rose Belcher <cel@...ibm.com>,
	Sukadev Bhattiprolu <sukadev@...ux.vnet.ibm.com>,
	Sonny Rao <sonnyrao@...omium.org>,
	John Mccutchan <johnmccutchan@...gle.com>
Subject: Re: [PATCH 4/4] perf tools: add JVMTI agent library

On 16/02/15 22:22, Stephane Eranian wrote:
> On Mon, Feb 16, 2015 at 2:01 AM, Adrian Hunter <adrian.hunter@...el.com> wrote:
>> On 11/02/15 01:42, Stephane Eranian wrote:
>>> 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 .......
>>>
>>> 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 next step is to inject the jitdump information into the
>>> perf.data file:
>>> $ perf inject -j $HOME/.debug/java/jit/java-jit-XXXX/jit-ZZZ.dump \
>>>               -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 OProfile's opagent code.
>>>
>>> Signed-off-by: Stephane Eranian <eranian@...gle.com>
>>> ---

[snip]

>>> +
>>> +int jvmti_write_code(void *agent, char const *sym,
>>> +     uint64_t vma, void const *code, unsigned int const size)
>>> +{
>>> +     static int code_generation = 1;
>>> +     struct jr_code_load rec;
>>> +     size_t sym_len;
>>> +     size_t padding_count;
>>> +     FILE *fp = agent;
>>> +     int ret = -1;
>>> +
>>> +     /* don't care about 0 length function, no samples */
>>> +     if (size == 0)
>>> +             return 0;
>>> +
>>> +     if (!fp) {
>>> +             warnx("jvmti: invalid fd in write_native_code");
>>> +             return -1;
>>> +     }
>>> +
>>> +     sym_len = strlen(sym) + 1;
>>> +
>>> +     rec.p.id           = JIT_CODE_LOAD;
>>> +     rec.p.total_size   = sizeof(rec) + sym_len;
>>> +     padding_count      = PADDING_8ALIGNED(rec.p.total_size);
>>> +     rec.p. total_size += padding_count;
>>> +     rec.p.timestamp    = perf_get_timestamp(perf_fd);
>>
>> Do you know whether the JVM is guaranteed not to start executing the
>> generated code before the return of compiled_method_load_cb(), otherwise the
>> timestamp will be too late?
>>
> I don't know that. I did not check.
> But are you saying the callback may be asynchronous with the JIT compiler?

Possibly, although it seems unlikely. But perhaps there are other threads
waiting for the code and it lets them go at the same time. I guess we can
assume that doesn't happen. When we use it with Intel PT it will show up if
the timestamp isn't before the first execution, because there will be
decoder errors.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/