GROOVY-12023 invokednymic improvements maybe

Hi all,

I spend a lot of time recently on trying to improve indy and well, the 
current architecture makes it difficult to solve problems. Right now I 
am stuck in a test that uses an in groovy written AST transform that 
fails under certain conditions to fire the right exception... So I am 
thinking of throwing away most of the branch. But there are some 
take-aways that I will probably put into a new pull request.

* DefaultTypeTransformation can have some fastpaths by simply reducing 
the method size by handling the common case and fall back to a new 
method for more complex cases
* dgm helpers are strictly seen not needed in Indy actually. But I can 
also not easily remove them from the build. I think static groovy 
compiles directly against them. But what I will do is store a 
MethodHandle in them, that I will then use in Indy, instead
* the cache in IndyInterface is in my eyes more a megamorphic cache. I 
experimented with an alternate key mechanism, I think I will also keep that.

None of these change will make indy dramatically faster. The DTT change 
will actually benefit everything that uses DTT.

There is more, more difficult things.

One is checking the metaclass for a change. So in the old callsite logic 
if I change the metaclass of X then a callsite on Y is not affected by 
it. If we change the ExpandoMetaClass, it will also not change the 
callsite with Y as receiver. In indy we use the switchpoint logic, which 
invalidates all callsites. That worked for getting things done, but is 
too much for code that makes rapid changes to meta classes. So I am 
considering giving up  on the switchpoint and instead do a check similar 
to what the old callsite caching does with checking for an identical 
metaclass and its version. Or I start with the switchpoint, try to 
recognize if there are too many changes and fall back to the old logic. 
The switchpoint is cheap as check.

Another point is when we have to catch a GroovyRuntimeException to 
unwrap it, because the GroovyRuntimeException is in some cases used to 
control the MOP. That is what got me stuck on my branch, so it will try 
again in a clean and isolated approach

I also tried to make a small inline cache where the fallback will just 
forward to an older handle for the callsite to allow 3-4 changes to the 
callsite before it needs different treatment. I may try this again in 
the future, since I think this may help. I also tried in there to have 
only one switchpoint for the whole PIC, but as I said, the switchpoint 
is relatively fast. Having only one exception unwrap in there would 
probably have better results. The less checks the handle have to perform 
individually the better.

But frankly for this kind of information we would have to collect 
something like a profile, which I consider doing, but that could result 
in changing IndyInterface and Selector a lot. There is small gains, like 
moving some information about the callsite, that is not changing on the 
actual callsite instead of carrying them around in bound handles. That 
looks small, but reduces method signatures.

in fact for the future I am considering having IndyInterface really only 
as a entry point for the profile and then let different profiles handle 
the details, including handing over to a different profile. No exact 
plans here yet. But I think that can allow us doing some complex and 
specialized strategies without loosing  - it... really... the errors I 
had to deal with where driving me mad.

Then there was also the idea of a slow path, where we can avoid more 
checks and just invoke via meta class. I think here I will also have to 
try again. I think having a simple path for highly mutating callsites 
and also for the initial callsites might be of advantage.

Finally I think I have to add something that allows better debugging of 
Indy. Maybe something where I can register a set of origin classes and 
keep a structure for their callsites, that is accessible from a Groovy 
script. Then a test could test its callsite state without writing tests 
for invoking methods through IndyInterface. Not sure yet.

Will make any of this Grails faster? Maybe. The metaclass churn and the 
exception handling overhead are both hot candidates for performance 
improvements in a Grails environment.

Well, any thoughts and ideas are welcome

bye Jochen