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

[Dmitry Samersoff]

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
* I would love to change the world, but they won't give me the sources.