Call for Dicussion: JEP: Java Expression Trees API

[Paul Sandoz]

Hi Konstantin,

For some reason I lost the nested quoting…


> On May 8, 2024, at 3:23 AM, Konstantin Triger <kostat at gmail.com> wrote:
> 
> Hi Paul,
> 
> On Mon, May 6, 2024 at 8:50 PM Paul Sandoz <paul.sandoz at oracle.com> wrote:
> Hi Konstantin,
> 
> > On May 4, 2024, at 4:06 AM, Konstantin Triger <kostat at gmail.com> wrote:
> > 
> > Hi Paul,
> > 
> > > I don’t think we should embed specific profiles of code into the platform.
> > This makes sense depending on what you mean by "embed". Today there is no way to specify anything. How will a library be able to know what profile @CodeReflection annotated method or Quoted lambda should conform to?
> > 
> 
> A library consuming code models specifies constraints on the Java programming model and the developer passing reflected code to that library is aware of those constraints. It may be possible in some cases for composition (code models in, code models out), for example a machine learning library could potentially leverage an auto-diff library. It’s still early days so it will be interesting to see how this plays out.
> 
> 
> Potentially we misunderstood each other. I'm referring to the design/compile time ability to report errors. Previously you mentioned that you need to work out how a Java library can participate in analyzing models at compile time. I think this is a must have feature and an expectation from a statically compiled language.
>  

Ah, yes, it's a very important feature. IMO it’s too early tell whether it’s a feature we absolutely need in any first revision.


> > --
> > Code Model analysis thoughts.
> > The current design defines a very lean set of Core ops and allows extensions (Extended ops), which basically go after language (e.g. Java) features. My understanding is that other eco languages should define their respective Extended ops.
> 
> “Core” and “Extended” are poorly named, eventually we will find better names. The core and extended operations are designed to support the modeling of Java programs. Other "eco languages" do not need to depend on core ops. I think it depends on the use case and the target environment. They can also define their own distinct set of operations (e.g., see the Triton example), so they would depend on the meta-code model.
> 
> I don't really like this approach. This means "no guarantee for anything" for the analyzing library. But at the end there is JBC, so if Core ops would provide wrappers for the JBC instructions (and they do based on my observation), it should be always possible to lower to that level. I'd recommend that any non-Core op to be lowerable to the Core ops, (potentially in more than one hop).
> With this "guarantee" the analyzing library can be made generic.
>  

For a JVM-based language it could certainly makes sense. But there are also many possible routes from a Java code model to non-Java code model, where the use of core operations in the latter may not make sense. I was reluctant to lean into the granularity and generality that MLIR provides, and instead we focus on modeling Java code where a model with core operations can be compiled to bytecode (and lifted back).


> You make an interesting point about lowering and I have been wondering about that myself. But, I am wary of moving outside the domain of Java. We (Babylon team) need to keep very focused, otherwise the problem space becomes very large, and it’s already large! The meta-code model provides generic modeling of control flow (connected basic blocks), so for Java’s modeling purposes I did not see the need to add more abstract operations, such as a more general (lowerable) loop operation. I was thinking other’s can define their own operations for such purposes, or reinterpret the Java operations.
> (Note that in the Triton example we translate the for loop operation to a SSA-based counted loop. In an earlier design I tried to model Java high-level language constructs in SSA form. This quickly became complex, so backed off.)
> 
> However, even if we keep a Java focus perhaps there are more intermediate (perhaps optional steps) in this regard to make analysis of Java programs easier, which just so happens to be more generally useful, just like the meta-code model is I think more generally useful. Lowering to generic (further lower able) operations would make a great example and test case.
> 
> I totally understand your time and resource constraints. Probably it is impossible to provide a "perfect" intermediate op layer from the first shot.

Or even the N’th shot :-) For now I would prefer to stay focused on modeling Java code, we still have much work to do in that area.

Paul.

> But you already assumed that others could reinterpret Java ops. So why not take some Java ops (slightly simplified/generalized) and put them into generic "ExtendedCore"? I think that messaging here is the important part. I.e. what is the API the analysis libraries should work with?
>