again on megamorphic problems

[Jochen Theodorou]

Am 21.12.2012 12:28, schrieb MacGregor, Duncan (GE Energy Management):
> I've been thinking about this due to the extensive mixin hierarchy in our
> runtime presenting some potential problems with the number of types being
> seen by some areas of code in some applications. It's going to be hard to
> magic this problem away at the JVM level due to the restrictions stated in
> the JVM specification for invokeDynamic, specifically, "The result of
> successful call site specifier resolution is a call site object which is
> _permanently_ bound to the dynamic call site." In order for the JVM to
> create specialised version of methods, and for them to get their own call
> sites (to avoid the megamorphic problems) that restriction would have to
> be relaxed and it could potentially break the semantics for some languages.

the call site object should not be copied, yes

> For example, Charles, how do you handle the creation of literals /
> constants when building specialised methods? Are the literals instantiated
> by two specialised versions identical or simply equal?

I must confess, I didn't even think about this yet. That could indeed 
cause problems. simply copying the bytecode of the method would maybe 
not be ok then

bye blackdrag

-- 
Jochen "blackdrag" Theodorou - Groovy Project Tech Lead
blog: http://blackdragsview.blogspot.com/
german groovy discussion newsgroup: de.comp.lang.misc
For Groovy programming sources visit http://groovy-lang.org