Involvement of the compiler in generation of code model

[Maurizio Cimadamore]

HI Andrii,
the code model put forward by Babylon is relatively language-neutral, 
and inspired from MLIR:

https://mlir.llvm.org

The basic idea is to model everything as a group of basic blocks, where 
blocks can point to each other (via branches). In each block we find a 
sequence of operations, typically a function call that returns some 
value that can then reused later on in the block.

As you can notice, there's nothing too Java specific in the above 
formulation. It is true that, currently, we are working towards hacking 
the javac compiler to generate code models for the Java methods it 
compiles. But this doesn't mean that a different language, say Kotlin, 
has to first lower into Java to produce a model. Kotlin can create its 
own "dialect", with its own set of relevant of operations and types, and 
the Kotlin compiler can emit a model based on that dialect. All the 
interfaces in the code model are extensible, and we already have many 
different code models "dialects" geared towards different use cases. For 
instance, in this article Paul explains how one can define a code model 
dialect to reason about Triton kernels:

https://openjdk.org/projects/babylon/articles/triton

DIfferent VM languages can define their own dialects in pretty much the 
same fashion.

Cheers
Maurizio

On 30/04/2024 07:00, Andrii Lomakin wrote:
> Hi guys.
>
> Did I understand correctly that the compiler should be involved in 
> generating the code model for code reflection API?
>
> So other JVM-based languages, like Kotlin, should either convert their 
> model to the Java language-compatible model or sacrifice interoperability.