harmony-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mikhail Markov (JIRA)" <j...@apache.org>
Subject [jira] Updated: (HARMONY-5163) [drlvm][stack] unreliable detection of lines in stack trace
Date Thu, 20 Dec 2007 13:39:43 GMT

     [ https://issues.apache.org/jira/browse/HARMONY-5163?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel

Mikhail Markov updated HARMONY-5163:

    Summary: [drlvm][stack] unreliable detection of lines in stack trace  (was: [drlvm] unreliable
detection of lines in stack trace)

> [drlvm][stack] unreliable detection of lines in stack trace
> -----------------------------------------------------------
>                 Key: HARMONY-5163
>                 URL: https://issues.apache.org/jira/browse/HARMONY-5163
>             Project: Harmony
>          Issue Type: Bug
>          Components: DRLVM
>            Reporter: Alexey Varlamov
>            Assignee: Alexey Varlamov
>         Attachments: BCMappingTest.java
> There is no well-documented contracts between VM and JIT on bytecode<>native mapping
APIs, and drlvm employs various hacks while creating or inspecting stack traces. In particular,
to get Java bytecode for an entered call site (i.e. "is_ip_past"==true), corresponding frame
IP is "fixed" to point at CALL instruction itself. Few examples:
> 1) jvmti_stack.cpp:148
>         // if ip points to next instruction
>         if (si_get_jit_context(si)->is_ip_past) {
>             ip = (NativeCodePtr) ((char*) ip - 1);
>         }
> 2) stack_trace.cpp: 59
> #if !defined(_IPF_) // appropriate callLength should be put here when IPF bc maping will
be implemented
>     POINTER_SIZE_INT callLength = 5;
>                                 (is_ip_past ? callLength : 0);
> You can see that different assumptions are used in the examples above, in 1st IP points
in the middle of a machine instruction and in 2nd IP is expected to point at the instruction
start, not always successfully though. 
> OTOH JITs also have different expectations on IP argument for bc mapping queries, and
may provide incorrect results if expextation are not met. Jitrino.OPT is very sensitive to
this, as it provides only exact mapping of real instruction start  IP to Java BC, as opposed
to JET which handles continuous IP regions. So in example 1) Jitrino.OPT will never return
valid result, and in example 2) both JITs may fail if CALL target is a register. Besides,
code patching after recompilation may shift CALL inst a bit so old mapping would become obsolete.
> So we need to:
> 1) settle an explicit contract for get_bc_location_for_native(), which IP JIT should
expect: either exact instruction IP or any value within code block;
> 2) Fix vmcore and Jitrino.OPT accordingly (JET impl is tolerant here).
> The symmetrical capability get_native_location_for_bc() probably means to provide real
IP address of a first related instruction (which is not documented unambiguously either),
this may also affect the solution.

This message is automatically generated by JIRA.
You can reply to this email to add a comment to the issue online.

View raw message