again on megamorphic problems

[Mark Roos]

>From Jochen

If I understood right, then the call site in foo will become 
megamorphic, making it impossible to inline bar into the place from 
where foo is called. foo becomes like a inlining barrier so to say.

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.

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.

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.

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

regards
mark
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/mlvm-dev/attachments/20121220/a5e0be2d/attachment.html