again on megamorphic problems

[Jochen Theodorou]

Am 20.12.2012 22:35, schrieb Mark Roos:
[...]
> I see the same for my Smalltalk implementation.  In looking at my
> problem  it seems that the
> megamorphic problem is temporal.  In other words over a short time
> period the site is monomorphic
> then becomes megamorphic as more code runs.

yes, that is what I expect. A callsite could be monomorphic for a long 
time, then be megamorphic and then turn monomorphic again.

> Currently I detect the depth of the call site and drop its target chain
> when it gets too deep. Now this
> site starts over.  I am sure the JIT is not thrilled and it is not a
> general solution but for now it seems
> OK.

well, looking at what I said before, this approach has a good chance of 
"cleaning" a call site. That is why I tihnk this approach is surely not 
bad. How many targets do you usually keep in the chain before dropping?

> Longer term I was thinking of a way to determine if a site is
> megamorphic and if it is replace the callsite
> GWT with something tailored.  In my case the code is usually the same
> for all receivers so it would
> be interesting to find a way to use the same method code and only look
> for the receivers where the
> code changes.

hmm... for Groovy I don't think I can really tailor something down all 
that much. If I can, then I didn't see it yet.

> Another thought I had was to determine if a method has megamorphic call
> sites internally and if so
> then creating new methods during my lookup rather than caching the
> existing ones.  This would move
> the specialization up one level but the internal sites would now be
> monomorphic

ignoring that I cannot easily do that, this surely is an approach, but I 
am worried about memory here. For one you would have a tendency to keep 
references to class you may garbage collect otherwise, for the other 
your class would grow and grow...

bye Jochen