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

[Mourad Abbay]

On Tue, 6 May 2025 17:09:26 GMT, Maurizio Cimadamore <mcimadamore 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?

You are right. In a previous comment, I said that the end goal is to invoke opMethod lazily. I am still working to achieve that goal.

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

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