Re: Indy churning through LambdaForm classes

On 10.08.23 13:49, Gillespie, Oli wrote:
> Thanks Jochen.
>
> Not sure if I fully understood, are you suggesting that the current LRU cache which is keyed only on receiver could be effectively extended with a more complex key based on arguments and other guards?
> That seems reasonable to me.

not a key. Instead I would let the guards check directly and reorder
according to the last invocation... I mean if you count invocations you
can be quite creative in what you use as the "first" handle we compare with.


> One other thought, would using MethodHandle.invoke instead of invokeExact be useful for my second example? I think the sameClasses guard is maybe too strict here, both arguments would be accepted to a MethodHandle.invoke() which is expecting type List.
>
> (I don't know this area well at all so take those with a big pinch of salt.)


I this example the guard is too strict, but assume the following version

```
   def foo(LinkedList x) {}
   def foo(List<String> x) {  }
   def bar(List<String> x) { foo(x) }

List<String> l1 = new ArrayList();
List<String> l2 = new LinkedList();
while (true) {
      bar(l1)
      127.times { bar(l2) }
}
```

Unlike Java Groovy does not ignore subclasses having more specific
methods. That means foo(LinkedList) is called for l2 but not for l1.
Looking at the list of methods named foo to check if any of those is
possibly more specific is not a cheap operation. I would consider it for
a "self optimization". For example if multiple handles end up calling
the same method and/or after a certain amount of invocations.

> Anyway I'll be interested to follow any developments if you do decide to make some changes.

sadly time is the limiting factor.

bye Jochen