|What is a restructuring compiler? firstname.lastname@example.org (2004-10-21)|
|Re: What is a restructuring compiler? email@example.com (2004-10-23)|
|Re: What is a restructuring compiler? firstname.lastname@example.org (2004-10-25)|
|Re: What is a restructuring compiler? email@example.com (2004-10-30)|
|Re: What is a restructuring compiler? firstname.lastname@example.org (Silvius Rus) (2004-10-30)|
|Re: What is a restructuring compiler? email@example.com (A Pietu Pohjalainen) (2004-10-30)|
|Re: What is a restructuring compiler? firstname.lastname@example.org (M Wolfe) (2004-11-29)|
|From:||A Pietu Pohjalainen <email@example.com>|
|Date:||30 Oct 2004 22:46:23 -0400|
|Organization:||University of Helsinki|
|References:||04-10-143 04-10-164 04-10-178|
|Posted-Date:||30 Oct 2004 22:46:22 EDT|
hzmonte <firstname.lastname@example.org> wrote:
> I assume this restructuring is for optimization; so, a restructuring
> compiler is one kind of an optimizing compiler? If that's the case,
> why would there exist a restructuring compiler by itself? I mean, an
> optimizing compiler would not limit its optimization techniques to
> restructuring alone; that is, there would not be a compiler that does
> restructuring alone.
> [Actually, there are. They rewrite programs to make them more amenable
> to other kinds of optimization. -John]
Also, applying post-compilation time optimizations are a place for
compilers that do only restructuring. For example, doing link-time
optimizations, such as merging of module's interfaces and
implementations propsed by M.Fernandez is an example of this kind of
restructuring optimization: once the whole type hierarchy of a program
is known, there might no more be a need for carrying explicit
interface definitions with the object code.
For Java, I've been thinking of doing a similar kind of
optimization. In the general case, the possibility of programmer to
define dynamic class loaders makes it impossible to do whole-program
analysis; but if we take a closed-world assumption, which says that
all classes that are used in the program are available to the
analysis, we could similarily merge interfaces and classes and also
abstract classes and classes in order to reduce the number of class
files in the program's deployment package.
This would be beneficial in mobile Java environments where the size of
the deployment package is restricted. Does anybody have any recent
references of such work?
Return to the
Search the comp.compilers archives again.