We REALLY nead a NON-PCH build in JPRT NOW! (original) (raw)

Dmitry Samersoff dmitry.samersoff at oracle.com
Thu Apr 23 10:02:09 UTC 2015


On 2015-04-22 05:01, Daniel D. Daugherty wrote:

Personally, I like the idea of not adding any more new JPRT targets and reconfiguring to have fastdebug and/or debug builds run as non-PCH... It's a much simpler policy to explain:

If we support PCH builds with a particular toolset then product builds default to PCH and non-product builds default to no-PCH.

I'm second to it.

-Dmitry

On 2015-04-22 05:01, Daniel D. Daugherty wrote:

Magnus put this comment in the bug report about two weeks ago:

Is it possible to compile e.g. product builds with PCH and debug builds without, or vice versa? The impact of not using PCH will be not so great (since it's still used in 50% of the jobs), and we will get automatic testing both with and without PCH. David H followed with this comment: Certainly possible, but it won't give complete coverage of course (but nothing practical will give complete coverage).

Quickest fix for JPRT may be to just disable PCH for the embedded builds: product x86, fastdebug arm, to cover linux and minimal VM. Maybe throw in a couple of Windows builds (one product, one fastdebug) for good measure? Personally, I like the idea of not adding any more new JPRT targets and reconfiguring to have fastdebug and/or debug builds run as non-PCH... It's a much simpler policy to explain: If we support PCH builds with a particular toolset then product builds default to PCH and non-product builds default to no-PCH. Dan On 4/21/15 12:08 PM, Coleen Phillimore wrote: On 4/20/15, 9:31 PM, David Holmes wrote: On 21/04/2015 10:14 AM, Volker Simonis wrote: Hi Coleen,

the default is not to use PCH and I think that's probably OK for most people. If somebody plays with the include files, he should use the '--disable-precompiled-headers' configure option. The default depends on platform. For solaris we never use PCH. For the other platforms I think we always do. Yes, my motivation with this comment is that instead of adding JPRT targets or more work to do in JPRT is to simply make linux x64 at least default to non-PCH. It would break less frequently because that's the default and the side benefit is that when you're working and editing a header file, you don't get the whole JVM recompiled. IE. I would prefer if this were the default so I don't have to add yet another option to my configure script. Simply switching the default just creates a different problem. Engineers will use PCH locally and so may encounter issues if PCH has not been tested at integration time. It seems that the converse is more likely though. If something compiles without PCH it's very likely to compile with PCH. I'd prefer the default changed and not find whether I broke PCH with JPRT. thanks, Coleen I plan to fix this in JPRT by making a few configurations non-PCH. David ----- Making this option the default for the JPRT builds only will guard against the build errors described before while it still allows everybody to do local builds at full speed. Regards, Volker On 4/21/15, Coleen Phillimore <coleen.phillimore at oracle.com> wrote:

Can we just switch the default instead? Is that a simple makefile change? Coleen On 4/17/15, 6:35 AM, Lindenmaier, Goetz wrote: That would be great!!

Thanks David, Goetz. -----Original Message----- From: David Holmes [mailto:david.holmes at oracle.com] Sent: Freitag, 17. April 2015 12:23 To: Lindenmaier, Goetz; Volker Simonis; Andrew Dinn Cc: HotSpot Open Source Developers Subject: Re: We REALLY nead a NON-PCH build in JPRT NOW! On 17/04/2015 7:58 PM, Lindenmaier, Goetz wrote: Hi,

another occurance of this ... please, please add a non-pch build to jprt! https://bugs.openjdk.java.net/browse/JDK-8078048 I will. Unfortunately first I have some no-PCH issues to address. And unfortunately they are not top of my priority list right now. Hopefully next week sometime. David Best regards, Goetz.

-----Original Message----- From: hotspot-dev [mailto:hotspot-dev-bounces at openjdk.java.net] On Behalf Of Volker Simonis Sent: Donnerstag, 9. April 2015 11:35 To: Andrew Dinn Cc: HotSpot Open Source Developers Subject: Re: We REALLY nead a NON-PCH build in JPRT NOW! On Thu, Apr 9, 2015 at 10:10 AM, Andrew Dinn <adinn at redhat.com> wrote: On 09/04/15 09:02, Erik Joelsson wrote: I think that as long as we claim to support building both with and without PCH, the automatic testing should test both with and without PCH. By adding one or two build targets, or perhaps change an existing target, we could increase our test matrix to cover this easily. I think this restates Volker's original remarks in redux. No, not at all! I don't necessarily want to test more build configurations (that's another topic). My point is that PCH changes the compilation semantics and can hide real program errors. That's because with PCHs, every compilation unit sees the full precompiled header database (i.e. all the headers which are included in the "precompiled.hpp" PCH file). So if somebody forgets to include a dependency X.hpp in A.cpp, A.cpp may still compile with PCH because it includes the precompiled header file "precompiled.hpp" which in turn includes X.hpp. But the compilation of A.cpp will fail on platforms/configurations where we do not use precompiled headers. The two references I gave in my original mail are bugs that resulted from this problem. Besides program errors, the use of PCH can also lead to behavioral changes in the created binary when it comes to inlining. Because of PCHs some compilation units may be able to inline methods even if they do not explicitly include the files which contain the corresponding implementations because the implementation files are included in the PCH file. Without PCHs the compilers will simply emit calls to these functions (and, depending on the toolchain, emit a warning). I'm not familiar with ccache so I can not say if it has similar effects. So, given that we do need this (NOW! :-) is anyone able and willing to sponsor this? Yes, this question remains to be answered :) Regards, Volker regards,

Andrew Dinn -----------

-- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia



More information about the hotspot-dev mailing list