Optimization Thresholds?

[Stefan Marr]

Hi:

I am running into a strange issue when optimizing some reflective operations.
Don’t think it is related to the operations themselves, but rather the way the optimizations/Graal works.

If benchmarked separately, I see, as desired, the same performance results for direct and reflective operations.
So, I assume that my specializations are sufficient to please the optimizer.
Concretely, that is reflective method invocation via Smalltalk’s #perform: as well as intercepting undefined methods with #doesNotUnderstand:.

However, if both reflective mechanisms are used in combination to implement something like dynamic proxies, runtime nearly doubles compared to what I would expect.

I have been experimenting with the various thresholds in TruffleCompilerOptions, but without any luck.
Since the benchmarks are still microbenchmarks, I don’t think I am really hitting any of those anyway.
The fully inlined tree has something like 220 nodes. That’s the number I see in the error output after setting TruffleGraphMaxNodes to a very small number. And, that’s just about 20 more than what I get reported for the non-reflective, i.e., direct benchmark.

What would be a good approach to figure out what’s going wrong here?

Thanks
Stefan

To reporduce:

git clone --recursive https://github.com/SOM-st/TruffleSOM.git
ant jar
ant test
./graal.sh -cp Smalltalk:Examples/Benchmarks/DoesNotUnderstand Examples/Benchmarks/BenchmarkHarness.som DirectAdd 20 0 1000
./graal.sh -cp Smalltalk:Examples/Benchmarks/DoesNotUnderstand Examples/Benchmarks/BenchmarkHarness.som ProxyAdd 20 0 1000

-- 
Stefan Marr
INRIA Lille - Nord Europe
http://stefan-marr.de/research/