This is the mail archive of the java@gcc.gnu.org mailing list for the Java project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: class initialization check overhead


> On Thu, 2002-10-24 at 02:10, C. van Reeuwijk wrote:
> > - If a class has an empty init, change it to a superclass init (repeat).
> > - Eliminate inits of java.lang.Object (since it's empty).
> > - Within a method, keep track of the classes already initialized,
> > and don't initialize a class again if you know for sure that it, or a
> > subclass, has already been initialized.
> 
> I know we used to do this (without the subclass trick), by generating
> something like the following for "x = foo.bar.y"...
> 
>   int _foo_bar__initialized_p = 0; // once per method
> 
>   if (! _foo_bar__initialized_p)  // each reference would do this
>   {
>     initialize foo.bar
>     _foo_bar_initialized_p = 1;
>   }
>   x = foo.bar.y;
> 
> The compiler's normal optimizations will remove useless initializations,
> and even eliminate _foo_bar__initialized_p from the final output. 
> However, I believe this was changed somehow since the original
> implementation.  To what, I don't recall.

I've considered this for my compiler, since it would have saved me quite
some work, but there were some arguments against it:

- Other passes in our compilation path (e.g. our parallelization engines)
  were not happy about all this code.
- Since I generate C++ code, all target C++ compilers must be able to
  eliminate this in most cases I would, even though analysis of C code is
  more difficult than Java code.
- It would make the code at each insertion point slightly larger, because
  otherwise you can move the _foo_bar_initalized_p = 1 to the init method.

I don't know the details of the GCJ compiler, but the second point
may also apply. The third one does apply, and is mainly relevant because
of instruction cache pollution.

> apbianco once suggested also annotating the .class files with notes on
> which classes each method guaranteed to initialize.

That would be equivalent with the interprocedural analysis I mentioned.
However, inspection of a .class file can also reveal whether its init
is empty (right? I'm not too familiar with .class files), which is the
most interesting piece of information.

-- 
Kees van Reeuwijk, Delft University of Technology
http://www.pds.twi.tudelft.nl/~reeuwijk


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]