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

[Maurizio Cimadamore]

On Tue, 6 May 2025 18:13:07 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?
> 
> 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.

I guess the reason I'm confused is that this PR is called "lambda model uniqueness". IMHO, caching the call to opMethod in a static field (like you do in this PR) is enough to achieve "model uniqueness". If you also want to tackle laziness, that's ok, but I feel (and perhaps Paul's comment goes in this direction), that it would be better to do that in a separate PR?

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

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