We REALLY nead a NON-PCH build in JPRT NOW!

[Daniel D. Daugherty]

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
>>>>>>> -----------
>>>>>>>
>>>>
>>>>
>
>
>