ScopeDescs incorrect in Java 8

[David Griffiths]

I've managed to fix it in PCDesc.getRealPC but am a bit baffled as to the
nature of the fix. In the bad case (7.0) we have a constants area at the
start like this:

 Decoding compiled method 0x00007fe077bf56d0:
 Code:
 [Constants]
   0x00007fe077bf5880 (offset:    0): 0x00000000   0x401c000000000000
   0x00007fe077bf5884 (offset:    4): 0x401c0000
   0x00007fe077bf5888 (offset:    8): 0xf4f4f4f4   0xf4f4f4f4f4f4f4f4
   0x00007fe077bf588c (offset:   12): 0xf4f4f4f4
   0x00007fe077bf5890 (offset:   16): 0xf4f4f4f4   0xf4f4f4f4f4f4f4f4
   0x00007fe077bf5894 (offset:   20): 0xf4f4f4f4
   0x00007fe077bf5898 (offset:   24): 0xf4f4f4f4   0xf4f4f4f4f4f4f4f4
   0x00007fe077bf589c (offset:   28): 0xf4f4f4f4
 [Disassembling for mach='i386:x86-64']
 [Entry Point]
 [Verified Entry Point]
   # {method} {0x00007fe07292c790} 'topMethod' '(II)V' in
'io/undo/test/GetStateTest'
   # parm0:    rsi       = int
   # parm1:    rdx       = int
   #           [sp+0x60]  (sp of caller)
   0x00007fe077bf58a0: mov    %eax,-0x14000(%rsp)  ;   {no_reloc}
   0x00007fe077bf58a7: push   %rbp
   0x00007fe077bf58a8: sub    $0x50,%rsp         ;*iload_0
                                                 ; -
io.undo.test.GetStateTest::topMethod at 0 (line 17)

the problem is that the PCDesc.getRealPC returns the pc offset plus
codeBegin(). But in this case codeBegin points at the constants area
(0x00007fe077bf5880) not the entry point (0x00007fe077bf58a0) and so all
the PCDescs are incorrect. Simply changing PCDesc.getRealPC to use
code.getEntryPoint() instead fixes the problem.

Ah... wait... found it. There is a bug in CodeBlob:

  public Address codeBegin() {
    return headerBegin().addOffsetTo(contentOffsetField.getValue(addr));
  }

That should be codeOffsetField!

On Thu, 8 Oct 2020 at 18:09, David Griffiths <dgriffiths at undo.io> wrote:

> Ok, will do. I noticed a mismatch between the assembler produced by my use
> of HTMLGenerator and that from -XX:CompileCommand=print so need to figure
> out if I'm doing something stupid first (e.g. I see the use of "7.0"
> results in a constant section being produced and codeBegin() !=
> getEntryPoint() so could be something related to that).
>
> Cheers,
>
> David
>
> On Thu, 8 Oct 2020 at 15:25, Andrew Haley <aph at redhat.com> wrote:
>
>> On 08/10/2020 15:11, David Griffiths wrote:
>> > I'm running with the options "-XX:-Inline -XX:TieredStopAtLevel=1"
>> (there
>> > is a reason for this). The method (called enough times to JIT compile)
>> is:
>> >
>> >   16     static void topMethod(int a, int b) {
>> >   17         int c = a + 1;
>> >   18         int d = iMethodA(a) + iMethodB(a);
>> >   19         int e = iMethodA(a) * (iMethodA(b) - iMethodB(b));
>> >   20         vMethod(a);
>> >   21         testArgs(7.0);
>> >   22     }
>> >
>> > Simply changing the last line to testArgs(a) results in the ScopeDescs
>> > being ok! The called methods are trivial one liners. This is the bad
>> > compile info (nops and blank lines removed):
>>
>> Please send us a full test case.
>>
>> --
>> Andrew Haley  (he/him)
>> Java Platform Lead Engineer
>> Red Hat UK Ltd. <https://www.redhat.com>
>> https://keybase.io/andrewhaley
>> EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671
>>
>>
>
> --
> David Griffiths, Senior Software Engineer
>
> Undo <https://undo.io> | Accelerate software defect resolution by
> eliminating the guesswork in failure diagnosis
>


-- 
David Griffiths, Senior Software Engineer

Undo <https://undo.io> | Accelerate software defect resolution by
eliminating the guesswork in failure diagnosis