grimmerm
commented
6 years ago can you trace the deoptimization and point me to the place where the deop happens?
Closed pointhi closed 6 years ago
grimmerm
commented
6 years ago can you trace the deoptimization and point me to the place where the deop happens?
pointhi
commented
6 years ago Similar problem:
https://github.com/swenson/sort
export LLVM_COMPILER=clang
CC=wllvm make multidemo
extract-bc multidemo
mx --jdk jvmci --dynamicimports=/compiler lli multidemo.bc -Dgraal.TraceTruffleCompilation=true -Dgraal.TraceTruffleCompilation=true$ uname -a
Linux JKU-SSW-Thomas 4.15.3-1-ARCH #1 SMP PREEMPT Mon Feb 12 23:01:17 UTC 2018 x86_64 GNU/Linux$ clang -v
clang version 5.0.1 (tags/RELEASE_501/final)
Target: x86_64-unknown-linux-gnuSulong, Graal, Truffle, JVMCI all updated to the current version
rschatz
commented
6 years ago I have identified the problem: It seems due to inlining, it's possible that the same SSA value has two different debug types at the same time.
Currently Sulong assumes that any value in bitcode has a single compile-time constant type. The deoptimizations come from the fact that it's always "toggling" between two types, so it's not compile-time constant anymore. I'd rather not drop the requirement for this to be compile-time constant, because that would incur runtime cost. We'll have to somehow associate the type with the code position to make it constant again. I'll look into that, but it might take a bit.
A workaround until this is fixed properly would be to compile the bitcode with debug information disabled.
zapster
commented
6 years ago This is solved by commit bb2850fbb4d2863f1ae9a80394ce3bbba6c7d449.
How to Reproduce
(you need wllvm installed)
Example output
It can be seen, there is a continues flow of optimizations and deoptimizations slowing down the program by a big amount. It's expected that a more generic version of compiled code is used after some time to prevent continuous optimization and deoptimization of running code.