[code-reflection] RFR: Lambda model uniqueness [v4]

[Maurizio Cimadamore]

On Tue, 6 May 2025 11:24:50 GMT, Mourad Abbay <mabbay at openjdk.org> wrote:

> > It seems to me this patch is doing several things at once. While sharing the model instance in a new static field, I'm less sure about the fact that the lazy initialization of the `Quoted` object is worth the extra code complexity (e.g. double checked locking) -- after all, computing the `Quoted` instance in the constructor of the generated class should not mess up with uniqueness (as there will still be a new instance of `Quoted` per new instance of the generated class?)
> 
> The end goal is to lazily invoke `opMethod`. This saves space as the model is in memory when needed. It also saves time. Quoted object depends on the result of opMethod, so Quoted object must be initialized lazily.

Maybe I'm reading the code wrong -- but it seems to me that we cache the FuncOp in a static field. This static field is initialized with the lambda class (in the static initializer), so there's no laziness there -- but the same `FuncOp` can be shared across all instances of the lambda class. Then there is the method to create the `Quoted` object; this method needs the `FuncOp` as well as the captured value -- and pass everything to the interpreter -- this is done in `QuotedHelper`. It seems to me that the new code is lazily computing the quoted instance -- e.g. if nobody wants the `Quoted` object, then we won't try to compute it eagerly when the lambda instance is constructed.

So, it seems to me that opMethod is always called eagerly in the class initializer. The only thing that is lazy is the interpreter code to generated the `Quoted`. Am I reading incorrectly?

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

PR Comment: https://git.openjdk.org/babylon/pull/420#issuecomment-2855331142