harmony-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alexey Varlamov (JIRA)" <j...@apache.org>
Subject [jira] Created: (HARMONY-5163) [drlvm] unreliable detection of lines in stack trace
Date Wed, 21 Nov 2007 12:46:43 GMT
[drlvm] 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

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
    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