[graalvm-users] General application of Graal/Truffle outside of language implementation.

[Gilles Duboscq]

Hi Eli,

Indeed, the pattern is more general than just programming language interpreter.
You could also say that it's simply the concept of interpreter that goes beyond what is typically considered a programming language.

In general the question is:
- Is the system applying some "configurable" computation?
- Are some "configurations" repeatedly re-used in a performance critical part of the system?

If yes then you can use Truffle (or any form of partial evaluation) to create specialized versions of your configurable computation.
In the case of a typical programming language interpreter, the "configuration" is the AST and the computation is the interpretation of an AST given some input/environment.
Most programs repeatedly use the same ASTs to it's worth making specialized code to handle those ASTs.

I imagine a RxJava pipeline could also be considered such a "configuration".
If the system encourages short-lived instances, if those instances often have the same "shape", that can also be exploited.


Truffle also goes somehow beyond that by allowing you to take advantage of the following:
- Are your computations usually contextually biased to particular cases?

If yes you can use truffle to profile these biases and exploit them to simplify/optimize your computations.
In a programming language interpreter, these would typically be branch or type profiles.

  Gilles

On 08/04/2019 11:46, Elias N Vasylenko wrote:
> Hello
> 
> So it strikes me that interpreters for programming languages are not
> the only place in which we abstract over logic with AST-like structures
> that might benefit from JIT compilation. Have other applications of
> Graal/Truffle outside of language implementations been explored? Do
> they even make sense?
> 
> Take for instance something like RxJava, where a pipeline of operations
> is built dynamically and then applied to a possibly-unbounded series of
> messages. Even the Java Stream API is a similar pattern, though
> instances tend to be short-lived over discrete, relatively-small data
> sets so may not be good candidates. Could that kind of system benefit
> from internally representing/processing operations via a truffle-based
> AST/interpreter?
> 
> I hope this is a sensible question, I am only a casual observer.
> 
> Eli