RFR: JDK-8149479: Fix compare.sh to have a clean baseline with COMPARE_BUILD

Erik Joelsson 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 mailing list