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 _______________________________________________ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
