Potential compiler bug
java at stefan-marr.de
Thu Nov 6 17:57:23 UTC 2014
While trying to identify the change that introduce the issue I see in Graal, I unfortunately ran into a dead end.
The miscompilation appears after the Truffle inlining changes of Christian on the 10th of October. Since I fear that they merely expose the issue but themselves are not related, I can’t point at anything more concrete.
Trying to investigate the issue with IGV doesn’t work unfortunately either.
It seems that the execution with IGV interferes with compilation in a way that the relevant method does not get compiled, or doesn’t get compiled under the same conditions. So, the miscompilation doesn’t appear.
Any hints of how I could further isolate what’s causing the issue are very much appreciated.
> On 03 Nov 2014, at 18:15, Stefan Marr <java at stefan-marr.de> wrote:
> Dear all:
> In an experiment I did to assess the impact of using a proper object layout on TruffleSOM, I am running into issues with the latest Graal version.
> As far as I can tell, stores to an array are not actually done. Simple writes get lost.
> In the experiment, I replaced my object layout implementation with just stores into an Object array.
> To reproduce the issue, the following branch and example can be used:
> git clone -b mt-vs-pe/without-object-layout --recursive https://github.com/smarr/TruffleSOM
> ../graal/mxtool/mx —vm server vm -G:-TraceTruffleInlining -G:-TraceTruffleCompilation -G:+TruffleSplitting -G:+TruffleCompilationExceptionsAreFatal -esa -ea -Xbootclasspath/a:build/classes:libs/truffle.jar som.vm.Universe -cp Smalltalk:Examples/Benchmarks/DeltaBlue Examples/Benchmarks/BenchmarkHarness.som Bounce 100 0 200
> The benchmark will abort with a wrong result. The culprit seems to be a compilation of the #next method in the Random class, which looks like this:
> next = (
> "seed print. ' ' print. (((seed * 1309) + 13849) & 65535) print. ' ' print."
> seed := ((seed * 1309) + 13849) & 65535.
> "seed println."
> The stuff in quotes are comments, and the output indicates that reading works nicely, but writing can just fail, i.e., the method returns the old value instead of the new one.
> I already had that branch working some weeks ago, so, I assume this is something that creeped into the codebase recently.
> Best regards
> Stefan Marr
> INRIA Lille - Nord Europe
INRIA Lille - Nord Europe
More information about the graal-dev