[8u] RFR 8226288 - Upgrade to XCode 10+ for building JDK 8u and 11u

[Simon Tooke]

On 2020-02-27 3:47 p.m., Andrew Hughes wrote:
>
> On 27/02/2020 19:55, Simon Tooke wrote:
>> I have not heard back, and had put this on the back burner for a while.
>>
>>
>> Due to renewed interest expressed to me privately, I would like to
>> resubmit this RFR, updated to the latest JDK and macOS build environment.
>>
>>
>> Updated webrev:
>> http://cr.openjdk.java.net/~stooke/webrevs/jdk-8226288-jdk8u/01/
>>
>>
>> The result of this build does not perfectly pass jtreg tier1, but there
>> are only a few failures, which appear in more recent JDKs using the same
>> toolchain.
>>
>>
>> I would like to (and invite others to) address the tier 1 failures
>> separately; I suspect there will be more participation if the JDK builds
>> cleanly on Catalina using JDK 11.  Eventually, I hope it will even run
>> faster!.
>>
>>
>> Some of the upcoming RFRs (to address tier 1) appear in
>> https://github.com/stooke/jdk8u-xcode10/tree/master/jdk8u-patch
>>
>>
>> I know we are in rampdown now, but I think it's as good a time as any to
>> decide if this can get in for the following release.
>>
>>
>> Thank you for your time,
>>
>> -Simon
>>
>>
>>
> I recall this from the first time around.
>
> My immediate thought is that this seems to be a new bug that hasn't yet
> been applied anywhere. Does trunk not already work with XCode 10+? If
> so, we should be backporting appropriate changes from there, not
> creating something new for 8u.
>
> I believe part of the problem here is newer versions of CLang. Could
> some of that testing not be done with CLang on GNU/Linux, so more people
> can participate in getting this fixed?
A backport of 8019470, for example includes macos-specific code; notable 
a call to xcode-select, so a test on GNU/Linux would not work.  It's 
also unclear what internal changes Apple has made to their version of 
LLVM, and one of my fixes is definitely compiler-dependent.  In 
addition, future backports proposed will explicitly disable optimization 
of some files because of compiler bugs; this would be very 
version-dependent.
>
> A good starting point seems to be JDK-8019470 [0].  This is actually on
> the Oracle parity list for 8u252, but no-one seems to have attempted the
> backport.

I actually just tried the backport; it does solve a couple of issues, 
but doesn't remove all of the Xcode version checks (so a build won't 
happen), and based on prior experience, the JDK that comes out will 
crash due to other fixes not being present, fixes that are present in my 
patch.

The Oracle backport, therefore, probably has more changes than in a 
simple backport of 8019470, as does my patch.  What I would like to do 
is incorporate the default toolchain setting if Xcode version > 5.

If you want, I can submit my backport, then rebase my patch on top of that.

As for the other content of my webrev, it is pulled together from a 
series of partial webrevs in higher-level JDKs, and my own work.  
Backporting the entirety of some of those webrevs is infeasible - what 
was a one-liner becomes many hundreds of lines, for example in one 
case.  It is my belief that, although it is desirable to backport most 
fixes in their entirety, sometimes the less disruptive option is the 
better one.

(an example: my patch changes about 15 lines, taken from this changeset: 
http://hg.openjdk.java.net/jdk/jdk/rev/75aa3e39d02c)

I appreciate the intent, and in other cases have happily corrected 
patches to ensure increased compatiblity with future downport work, but 
I suspect in this case, the opposite is true.

Regards,

-Simon

>
> I'm not sure of the relevance of rampdown to this. This wouldn't be
> something approved for 8u252 at this stage.  8u-dev will be available
> for commits again as soon as the bug system is switched over & JFR is
> merged.
Yes, you're right.  It is irrelevant.
>
> [0] https://bugs.openjdk.java.net/browse/JDK-8019470
>
> Thanks,