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

[Volker Simonis]

On Fri, May 8, 2015 at 5:01 PM, Stefan Karlsson
<stefan.karlsson at oracle.com> wrote:
> Volker,
>
>
> On 2015-05-08 16:42, Volker Simonis wrote:
>>
>> On Thu, Apr 23, 2015 at 1:42 AM, Coleen Phillimore
>> <coleen.phillimore at oracle.com> wrote:
>>>
>>> On 4/22/15, 3:57 AM, Andrew Haley wrote:
>>>>
>>>> On 22/04/15 03: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.
>>>>
>>>> But the debug builds are used in development all the time.  It's
>>>> these that really benefit from PCH.
>>>
>>>
>>> I feel like PCH makes development slower.  I change a header file and all
>>> the files in the system are recompiled because it happens to be in the
>>> precompiled file.  I wouldn't miss it for debug mode.
>>>
>> While working on the new HotSpot build (in the build-infra project)
>> I've just realized the we are currently using the option '-fpch-deps'.
>>
>> Citing from the gcc man-page: "When using precompiled headers, this
>> flag will cause the dependency-output flags to also list the files
>> from the precompiled header's dependencies.  If not specified only the
>> precompiled header would be listed and not the files that were used to
>> create it because those files are not consulted when a precompiled
>> header is used."
>>
>> This actually means that a .cpp file which uses PCH will depend on all
>> the headers in the PCH-file while while it should actually only depend
>> an the header files it explicitly includes itself. So this is probably
>> the reason why with PCH the change of a single header unnecessarily
>> triggers the recompilation of most of the
>> .cpp files. That said we of course still have certain header which are
>> included in all compilation units so there's nothing we can make once
>> such a file is changed.
>
>
> Yes, I think you found that running without -fpch-deps was broken:
> http://mail.openjdk.java.net/pipermail/hotspot-dev/2012-June/006016.html
>
> :)
>

Oh my good - I completely forgot about this change!
I though about doing  a 'hg annotate' before posting to see who
introduced it but than I forgot about it :)

So we should really check for the mentioned compiler bug before
dropping '-fpch-deps' in the new HotSpot build.

Thanks for the link,
Volker

> StefanK
>
>>
>>
>>> Coleen
>>>
>>>> Andrew.
>>>>
>