RFR: JDK-8162354: Unable to build JDK 9 on a Sparc T7-1 with default boot-jdk 8.0

[Erik Joelsson]

Followup on this. I did a compare build on Solaris with 8GA and 8u20. 
There is a slight difference for these class files:

/jdk.compiler/com/sun/tools/javac/resources/CompilerProperties$Errors.class
/jdk.compiler/com/sun/tools/javac/resources/CompilerProperties$Fragments.class
/jdk.compiler/com/sun/tools/javac/resources/CompilerProperties$Notes.class
/jdk.compiler/com/sun/tools/javac/resources/CompilerProperties$Warnings.class
/jdk.compiler/com/sun/tools/javac/resources/CompilerProperties.class

The source file is generated and also differs. Without digging deeper, 
it looks like it's just ordering of methods, fields and/or inner 
classes, which is caused by the generator program not specifying the 
order, likely by using an unordered collection to store them during 
generation. While this is most likely fine, it's good practice to have 
the build more deterministic.

/Erik


On 2016-08-03 11:11, Erik Joelsson wrote:
> New webrev: http://cr.openjdk.java.net/~erikj/8162354/webrev.02/
>
> I found that the first working update was 8u20 and changed to use that 
> instead for minimal impact.
>
> /Erik
>
> On 2016-08-03 09:08, Erik Joelsson wrote:
>>
>>
>> On 2016-08-03 04:20, David Holmes wrote:
>>> Hi Erik,
>>>
>>> On 3/08/2016 1:11 AM, Erik Joelsson wrote:
>>>> Hello,
>>>>
>>>> The default bootjdk for 9 is JDK 8. Unfortunately JDK 8 does not 
>>>> work on
>>>> newer M7 sparc hardware. This has of course been fixed in an update.
>>>> This patch changes the Jib profile configuration to use 8u102 as 
>>>> bootjdk
>>>> on Solaris sparc if the cpu is of the M7 type.
>>>
>>> Isn't 8u102 a bit too recent to use - shouldn't we use the oldest 
>>> version that works on M7?
>>>
>> That is a good point. Either go with latest greatest when changing or 
>> try to find the minimum change. We had a similar problem in JDK 8 
>> where 7GA did not work on macosx. At that time we took the first 
>> working version. I will see if I can figure out which one it is at 
>> least.
>>> Does this actually affect official builds (do they use M7) or does 
>>> this simply enable use of M7 in the other build processes (JPRT etc)?
>>>
>> Unclear. The new hardware we received is M7, so without a change we 
>> can't use that hardware for any builds, which would be sad since the 
>> machine is very fast. I suspect that down the line we will want to 
>> use this class of hardware in all types of build scenarios. IMO, we 
>> get adequate testing that the 8GA as boot (which is the defined 
>> bootjdk) works on all the other platforms.
>>
>> /Erik
>>
>