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,
