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

[Adrian Hunter]

On 16/02/15 22:22, Stephane Eranian wrote:
> On Mon, Feb 16, 2015 at 2:01 AM, Adrian Hunter <adrian.hunter@xxxxxxxxx> 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@xxxxxxxxxx>
>>> ---

[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@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/