[code-reflection] RFR: Replace the use of Interpreter to create Quoted instance with specialized code [v4]

[Maurizio Cimadamore]

On Wed, 28 May 2025 11:43:43 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> I'm a bit confused -- if the new `CoreOp` methods cannot be used in javac/`QuotedHelper` -- then why are they in this PR? @PaulSandoz did you intend for the new methods to be the official way to deal with quoted models both in javac and elsewhere -- or was that just an API suggestion unrelated from the goal of this PR? (I'm a bit confused)
>
> I checked back javac code, and javac generates a `funcOp` which more or less adheres to the characteristics described here -- more specifically, the entry block of the func generated by javac has N vars and N block parameters. The only discrepancy is that javac needs to deal with cases where the referred captured symbol is a constant (e.g. `final String s = "hello"`). In such cases, the generated code for the lambda still relies on a variable -- but that variable is _not_ initialized with a block parameter of the generated func -- it is instead initialized to a constant value. IMHO generalizing the new function to deal with such "local" vars could be useful (and will make javac generated code compliant with the rules we set).
> 
> When implementing support for captured constants, we debated this a bit -- the alternative would have been to just "inline" the reference to the constant into the lambda body -- but that seemed a less transparent approach, so we decided to keep the reference to an enclosing var there -- so that e.g. the name of the capture symbol is still visible. If we still feel this is important, then I'd say the new functions should support this idiom.

To be clear: I think using `CoreOp::quoteOp` inside javac is a no-go. Javac has a lot of special code to allow to generate the model for a lambda "in isolation" -- this involves computing all the captures upfront, and then setting up a block with enough `Var` to satisfy the generation of the lambda body. References to captured symbols inside the lambda body are replaced with reference to such generated `Var`s -- this is roughly what `CoreOp::quoteOp` does -- but that method assumes we have an `Op` to begin with -- whereas javac is trying to generate that op as well, so I think what javac does looks ok.

What seems more doable (and desirable IMHO) is to replace `QuotedHelper` with the other function -- `CoreOp::quotedOp` -- but to do this, `CoreOp::quotedOp` needs to relax some of its checks to tolerate (local) `Var` initialized with an (immediately preceding) constant op.

-------------

PR Review Comment: https://git.openjdk.org/babylon/pull/424#discussion_r2111668620