Re: Dynamic Binding

Erik Ernst <eernst@cs.auc.dk>
19 Jan 2000 01:16:37 -0500

          From comp.compilers

Related articles
Dynamic Binding raugfer@uol.com.br (Rodrigo Augusto B. Ferreira) (2000-01-15)
Re: Dynamic Binding anton@mips.complang.tuwien.ac.at (2000-01-19)
Re: Dynamic Binding scorp@btinternet.com (2000-01-19)
Re: Dynamic Binding eernst@cs.auc.dk (Erik Ernst) (2000-01-19)
| List of all articles for this month |

From: Erik Ernst <eernst@cs.auc.dk>
Newsgroups: comp.compilers
Date: 19 Jan 2000 01:16:37 -0500
Organization: Department of Computer Science, University of Aalborg, Denmark
References: 00-01-055
Keywords: OOP, code

Rodrigo Augusto B Ferreira <raugfer@uol.com.br> writes:


> Hi, The best known technique to implement dynamic binding is using
> method tables. [..] I was wondering if using dynamic type
> resolution, by compiling a lookup switch statement for each virtual
> call, would be valuable to increase the possibility of optimization.


> I know that, although this technique transforms virtual calls in
> switch + static calls, it has some weak points like being slower and
> requiring the type hierarchy to be known at compile time. But I
> suspect that in some cases it may be worth trying.


Your "switch + static calls" approach might have something in common
with message splitting:


    Craig Chambers and David Ungar: Iterative Type Analysis and Extended
    Message Splitting: Optimizing Dynamically-Typed Object-Oriented
    Programs


available via


    <URL:http://www.sun.com/research/self/papers/iterative-type-analysis.html>


Message splitting is the technique of creating several single-type
versions of a piece of code, as opposed to the original version of the
code which works on objects of multiple types. To choose from that
set of single-type variants you'd essentially need a switch at the
call site (perhaps a switch for the two most common cases and a
slower, general lookup for the rest).


In the above paper they take the next logical step and inline the body
of the statically known method, since that improves the opportunities
for optimizations. Since this might cause an unbounded explosion in
code size (consider two methods calling each other), they must of
course apply this technique in a restricted manner.




    regards,
--
Erik Ernst eernst@cs.auc.dk
Department of Computer Science, University of Aalborg, Denmark


Post a followup to this message

Return to the comp.compilers page.
Search the comp.compilers archives again.