|
|
Re: CLR Design Choices
|
Posted: Feb 5, 2004 3:02 AM
|
|
> I would appear to me that you only need to know the set of
> possible concrete classes that could by called by that
> method invocation.
>
> So if you know the complete set of classes that object
> could be, and they all share an implementation of
> doSomething, then you can inline it.
The trouble is that in dynamic runtimes like Java or .NET, you are usually not certain you know all the types that will ever be loaded. Types that provide new implementations can in general be loaded dynamically later. I assume that's why Anders said you can never inline virtual methods, because sometime later, a new implementation could show up.
The way that I had heard this inlining is done in adaptive optimizing VMs involved a type check before entering the inlined code, just to make sure it was the expected type. This does cost some time to check the type, but one would imagine far less time than an actual method call.
But what was most interesting to me about this technique was something I heard Terence Parr describe at a Java users group talk I attended many years ago. He said that in practice in running apps, the vast majority of virtual method invocations turn out to be "monomorphic" or "bimorphic". By monomorphic, he meant only one implementation of a virtual method is ever called. By bimorphic, he meant only two implementations of the virtual method are ever called. He suggested that only a rather small percentage of virtual method invocations turn out to be "megamorphic," where lots of different implementations are called.
So chances are apparently good that only one or two implementations of a virtual method will ever actually be called as the program runs. In those monomorphic and bimorphic cases, one would imagine that it would be advantageous -- in the parts of the code that are being executed most of the time -- to inline those one or two implementations in use and check the type before plowing ahead.
And this actually speaks to everyday Java programming practice. Anders had mentioned performance (as well as versioning) concerns when I asked him why non-virtual was the default method access level in C#, and said that Java programmers forget to mark their methods final and that hurts performance. Well, my understanding is that that with modern VMs there isn't much correlation between final marking and performance. You shouldn't be marking methods final in Java just to achieve performance, because it probably won't help.
|
|
Previous Topic
