|Optimization for OOP firstname.lastname@example.org (2008-05-03)|
|Re: Optimization for OOP email@example.com (2008-05-05)|
|Re: Optimization for OOP firstname.lastname@example.org (Dmitry A. Kazakov) (2008-05-05)|
|Re: Optimization for OOP email@example.com (Tony Finch) (2008-05-05)|
|Re: Optimization for OOP firstname.lastname@example.org (email@example.com) (2008-05-05)|
|Re: Optimization for OOP firstname.lastname@example.org (Dmitry A. Kazakov) (2008-05-06)|
|Re: Optimization for OOP email@example.com (2008-05-06)|
|From:||firstname.lastname@example.org (Torben =?iso-8859-1?Q?=C6gidius?= Mogensen)|
|Date:||Mon, 05 May 2008 09:45:24 +0200|
|Organization:||Department of Computer Science, University of Copenhagen|
|Posted-Date:||05 May 2008 11:12:01 EDT|
> I'm in the beginning of writing an optimizer for an object oriented
> programming language. At the moment I'm working on developing a list
> of possible optimizations that can be performed on the code. The
> language runs on a virtual machine.
The most important optimisation is to get rid of dynamic method calls.
This can, however, be quite tricky as you can't tell if a method can
be overridden without knowing the whole program, so it plays havoc
with separate compilation. A compromise is to allow methods to be
declared "final", which ensures it is never overridden.
If you design your own language, you can make "final" the default, so
you would have to write explicitly if a method is allowed to be
overridden. In many cases, methods are final, but the programmers are
just to lazy to declare this, or think "yeah, maybe, I will in the
future override this, so I'll just leave this possibility open", and
then they never override it anyway.
Return to the
Search the comp.compilers archives again.