Master Thesis Research Advice. JIT

[Vladyslav Tkachuk]

Hello Vladimir,

Thank you for your reply.

I have considered all compiler levels from C1 and C2, but the main problem
was that the code produced by them has too many aspects that make it hard
to analyze.
The point of my task is Trivial Compiler Equivalence, meaning that I
literally compare the Asm code for a source class and mutants line by line
and I expect that the same Java code produced same Asm code. However, the
code produced by C1 contains many addresses which vary every time the code
is run.
That is why I switched to Opto-Asm which has much less "variability".

Best regards,
Vladyslav Tkachuk

чт, 16 квіт. 2020 о 12:26 Vladimir Ivanov <vladimir.x.ivanov at oracle.com>
пише:

> Hi Vladyslav,
>
> C2 has a number of aggressive optimizations which heavily rely on
> profiling data. It leads to numerous uncommon traps in the generated
> code. You can disable some of such optimizations, but there's no way to
> completely eliminate uncommon traps in the generated code: they are a
> core piece of the design.
>
> Have you tried switching to C1 instead? C1 doesn't rely on profiling
> data that much and use code patching techniques in place of uncommon
> traps. So, the generated code usually has complete coverage of the
> compiled method.
>
> Best regards,
> Vladimir Ivanov
>
> On 16.04.2020 01:05, Vladyslav Tkachuk wrote:
> > Hello,
> >
> > I am a Master's student at the University of Passau, Germany.
> > My master thesis research is concerned with detecting equivalent mutants
> in
> > Java.
> > The main research question is to use the Trivial Compiler Equivalency
> > technique. This means that we acquire Assembly code produced by Java JIT
> > compiler for initial and mutated source and then compare them.
> >
> > I have previously contacted Tobias Hartmann, who advised me to write here
> > regarding technical questions. I would like to ask you if there is any
> > solution to a problem I have.
> >
> > Last time Tobias recommended me to use Opto-Assembly to achieve my
> purpose.
> > It was a good hint and it helped me to get more precise data.
> > However, after doing some research I noticed that in some cases C2
> compiler
> > unloaded the method code which I expected to find in assembly. As I found
> > out this was a part of deoptimization and the method code was meant to be
> > executed by the interpreter.
> > Here is an example of what I mean:
> >
> > {method}
> >   - this oop:          0x000000000d2319c8
> >   - method holder:     'Rational'
> >   - constants:         0x000000000d230cf8 constant pool [85]
> > {0x000000000d230d00} for 'Rational' cache=0x000000000d231cd8
> >   - access:            0x81000001  public
> >   - name:              'toString'
> >   - signature:         '()Ljava/lang/String;'
> > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> > some setup code
> > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> > 02c    movq    RBP, RDX # spill
> > 02f    movl    RDX, #11 # int
> >        nop # 3 bytes pad for loops and calls
> > *037    call,static  wrapper for: uncommon_trap(reason='unloaded'
> > action='reinterpret' index='11')*
> > *        # Rational::toString @ bci:0  L[0]=RBP L[1]=_ L[2]=_ L[3]=_
> L[4]=_
> > L[5]=_ L[6]=_ L[7]=_*
> > *        # OopMap{rbp=Oop off=60}*
> > 03c    int3 # ShouldNotReachHere
> > 03c
> >
> >
> > This is a 'toString' method and as I could see and understand, there is
> no
> > actual method code, but only a call to it.
> >
> > I would like to know if it is possible to completely disable any
> > deoptimizations and consistently receive the full asm code? I consent
> that
> > it is not practical and hurts performance, but it is not a goal in this
> > scope. According to my observations, in most cases the method code is
> full,
> > but strangely here it did not work. I have tried to google any useful
> info,
> > unfortunately, I did not see anything helpful, despite the explanations
> > about what deoptimization is and its types.
> >
> > I would be grateful if you could shed some light on the issue.
> > Thanks in advance for any useful information.
> >
> > Best regards,
> > Vladyslav Tkachuk
> >
>