[jira] Updated: (HARMONY-5163) [drlvm][stack] unreliable detection of lines in stack trace

["Mikhail Markov (JIRA)" <ji...@apache.org>]

     [ 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;
>     POINTER_SIZE_INT eff_ip = (POINTER_SIZE_INT)ip -
>                                 (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.