[code-reflection] RFR: Replace the use of Interpreter to create Quoted instance with specialized code [v4]
Maurizio Cimadamore
mcimadamore at openjdk.org
Wed May 28 11:46:05 UTC 2025
On Wed, 28 May 2025 10:48:04 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:
>> CoreOp.quoteOp result is different from what javac produces. For instance, CoreOp.quoteOp doesn't keep captured constants in the model. We can update it to do so, but then the goal of such as method was to take an operation from its original context by representing its captured values and operands as parameters.
>
> 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.
-------------
PR Review Comment: https://git.openjdk.org/babylon/pull/424#discussion_r2111640598
More information about the babylon-dev
mailing list