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

[Maurizio Cimadamore]

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

>> 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.

(I have no objection to this PR going ahead as is -- what I find mildly strange is that we tied this PR with the addition of these two new API functions in `CoreOp`, even though we ultimately don't have a definite answer on how to reuse said functions from the original code in this PR).

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

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