RFR: JDK-8149479: Fix compare.sh to have a clean baseline with COMPARE_BUILD
erik.joelsson at oracle.com
Wed Feb 10 13:14:54 UTC 2016
On 2016-02-10 11:23, Magnus Ihse Bursie wrote:
> However, I'd like to use the opportunity to talk a bit about the
> compare script. :-)
> I think it is a very good initiative to fix the compare script so that
> two consequitive builds on the same machine should compare equal.
> Apparently, that's as close to a reproducible build we'll ever get at
> the moment.
> This patch does that, and that's good.
> However, the "naive" way to get to a clean compare is to stop
> comparing anything of value. :-) I'm not suggesting that you are doing
> that (or that you should do that), but in a less extreme form, that's
> my main worry. Or to phrase it differently, how can we tell that we're
> not hiding something important? For instance, all these "accepted size
> differences" on solaris. Are they still relevant?
I agree, it would be good to reevaluate a lot of the exceptions. I have
removed some that were obviously just working around differences between
build-infra and old build in JDK 8.
> Is there some way to run the compare script without the exceptions
> file (apart from hacking it)? If we do that, what would happen? Could
> we trim down the exception lists?
No, there isn't. Yes, at least some of those exceptions are needed. I'm
sure we can remove a bunch of them if we assume exact same output dir,
but not all.
> The dis filters seems a bit non-optimal too. We have a "global" dis
> filter in compare.sh (introduced by me when I didn't know about the
> specific dis filters in the exception file), and a specific dis filter
> per platform in the exception file. The main task for the dis filters
> is to remove differences in hexadecimal numbers, and I think that
> could be generalized enough to just be in the global part. Any highly
> platform specific filtering, like the "literal pool" stuff for macosx,
> could still live in the exception file.
Maybe, not sure. In some cases, the specialized filters also take local
variations on commands like sed into account.
> Finally, I still would like to get the string literal comparison into
> the configure script, now I run it manually using:
> objdump -s -j .rodata $LIBRARY | grep "^ " | xxd -r | strings
> (The main hurdle to do this is adding detection for xxd in configure,
> I think)
If you have more comparisons, please add them.
More information about the build-dev