One more: Method invalidation for strange example code

Andreas Woess andreas.woess at
Mon Jan 27 12:17:00 PST 2014

Hi Stefan,

I was able to reproduce the problem. Apparently, the compiled code is
garbage collected in response to the System.gc() in your benchmark
harness. The obvious workaround is not to call System.gc() until this is

- andreas

On 23.01.2014 12:28, Stefan Marr wrote:
> Hi Andreas:
> On 23 Jan 2014, at 12:15, Andreas Woess <andreas.woess at> wrote:
>> No uncommon trap? Interesting... I will look into it. What should I run?
>> Richards? Small tests to reproduce are always good.
> I just pushed the minor test case ‘FieldWrite’. Richards is probably to large, but also has the problem, as well as Bounce, Fannkuch, and others.
> To execute, both the TruffleSOM code and the core-lib need to be current. For instance with:
>   git clone --recursive som
> Then, I usually execute it from the graal directory:
>  ./ --vm server vm -XX:+UnlockDiagnosticVMOptions -XX:+LogCompilation -G:+TraceTruffleExpansion -G:+TraceTruffleExpansionSource -XX:+TraceDeoptimization -G:-TruffleBackgroundCompilation -G:+TraceTruffleCompilationDetails -Xbootclasspath/a:../som/build/classes:../som/libs/truffle.jar som.vm.Universe -cp ../som/Smalltalk ../som/Examples/Benchmarks/BenchmarkHarness.som FieldWrite 200 10 100
> With my instrumented version of graal, I get barely the following output:
> [truffle] optimized Method FieldWrite>>#benchmark:../som/Examples/Benchmarks//FieldWrite.som:6 at 704d6e83 3830410e |Nodes      21 |Time    41(  14+27  )ms |Nodes   176/  699 |CodeSize 3080
> FieldWrite: iterations=1 runtime: 62100us
> OptCallTarget InvalidInstalledCodeException
> OptCallTarget invalidated
> [truffle] invalidated Method FieldWrite>>#benchmark:../som/Examples/Benchmarks//FieldWrite.som:6 at 704d6e83 |Inv# 73                                     |Replace# 11
> Thanks
> Stefan
>> - andreas
>> On 23.01.2014 10:44, Stefan Marr wrote:
>>> Hi:
>>> On 22 Jan 2014, at 14:11, Stefan Marr <java at> wrote:
>>>> Any hints how I could track what causes the invalidation? All invalidations done in TruffleSOM directly are tracked, in my version locally, I think.
>>> Just to give an idea what I mean with that:
>>> This sprinkles printlns into all the relevant places I could identify.
>>> And with that, I am kind of sure that nothing directly from the Truffle level is causing the invalidations.
>>> So, is there any way to attach more information to an InvalidInstalledCodeException?
>>> The invalidation reason is not showing up in the hotspot log, and it’s not an uncommon trap either.
>>> Beside guessing and applying random changes, I am really a little helpless here.
>>> Perhaps, there is a way to add more debugging information into the generated native code?
>>> Could someone point me perhaps in the main direction for what I could be looking in the Graal code base?
>>> Thanks
>>> Stefan
>>> PS: and there is another issue with non-local returns I think. But I wasn’t able yet to produce a condensed test case.

More information about the graal-dev mailing list