Re: precompiled headers and includeDB*

tom fogal wrote:
> 
> While we're on the subject, is there a compelling reason for the
> includeDB system in general?  I guess I don't really understand that
> aspect of the build system very well.  It exists because of a potential
> performance gain in build times through the use of precompiled headers,
> correct?

No that is not the reason it exists at all. The original reason it 
existed was because the original developers of hotspot intended to 
license different parts of the source base as different products. 
includeDB was the database used to manage which pieces were sent with 
which products.

Nowadays it generates the project files for Visual Studio and will 
likely generate the project files for NetBeans in addition to generating 
the dependencies for make.

> 
> As far as I know, the system uses these includeDB files and MakeDep to
> somehow build a single giant include file, which gets precompiled.
> Then all files end up including this precompiled header.
> 
> This seems like a lot of trouble to go through however, and I'm not
> convinced of the performance gain.  In this scheme, compilation of
> file.C won't have to parse its include of file.h, but it still has to
> read 1 giant precompiled header file from disk.  It would seem that
> reading + parsing a small number of includes wouldn't be that much
> slower (or maybe even faster) then just a read of one large precompiled
> header.  Unless most headers really need to get included in a
> significant portion of the JDK, which seems unlikely but possible.

since precompiled headers weren't the reason behind includeDB whether 
they are faster or not wasn't exactly the issue. On the platforms where 
precompiled headers exist the compilation is much faster though.

> 
> So, making the unreasonable assumption that I understand things
> correctly, then dependencies && includes could be done in a more
> traditional way.  Performance would hopefully be similar, and that
> could deprecate `MakeDeps', making OpenJDK one step closer to not
> requiring a bootstrap JDK (I'm not sure if thats a reasonable eventual
> goal, but from posts it seems like that would be nice).

What would you do about jvmti? It needs something to transform all that 
xml into code.

We have very recently had this issue come up internally at Sun. I think 
the consensus view is that if we didn't have MakeDeps we wouldn't go out 
and invent it. My view was that if MakeDeps is removed we make a large 
change to the system that only makes the system different not better. 
I'd rather see changes that made the system better. For example the 
earlier question about why is there a linux and solaris directory and 
not a shared unix directory. Refactoring that code would be a lot higher 
on my list.

--

-- 
Steve