Potential compiler bug
java at stefan-marr.de
Fri Nov 7 13:05:57 UTC 2014
I think, I found the place where the optimizer does something that is potentially wrong.
Further investigating the issue made me realize that when IGV is used, it takes time until the compiled method gets installed. It seems, it is only used after IGV finished loading/receiving all the information.
The main benchmark method is of course too large, so I tried to find the smallest method that has the issue when being compiled, and that seems to be Ball class’ initializer:
mx --vm server vm -G:TruffleCompileOnly="Ball>>#initialize" -G:Dump=Truffle,TruffleTree -Xbootclasspath/a:build/classes:libs/truffle.jar som.vm.Universe -cp Smalltalk Examples/Benchmarks/BenchmarkHarness.som Bounce 1500 0 200
So, the characteristic I looked for in the graph is the Random number generator. The constants 1309 and 13849 are easily found after the inlining of the Random methods.
In IGV, it is the first subtree of OCT::callRoot. The Random methods are inlined in step 146.
The results look fine, and step 156 “After phase DeadCodeElimination” is still correct. The next Canonicalizer step however reduces the random number computation to a constant. On the Smalltalk level, I don’t understand why that would be possible. The initializer of the Random class with it’s constant does not seem to be inlined. So, the value of Random’s seed field is not merely a data dependency.
On the program level, each Ball is initialize independently, and the ‘global’ seed value is changed after each new Ball object is created.
So, I think, that’s where something is going wrong.
Would be great if someone with more knowledge of the optimizer could have a look at this.
The relevant TruffleSOM code can be obtained by:
git clone -b mt-vs-pe/without-object-layout --recursive https://github.com/smarr/TruffleSOM
INRIA Lille - Nord Europe
More information about the graal-dev