Maybe, but the problem is that we don't know what the next chip name
will be. The last generation was T5, so the letter may also change. I
think it's safer to go with what we know at this point.
/Erik
On 2016-08-03 13:26, Seán Coffey wrote:
One suggestion to future proof your fix might be to pattern match
against any CPU of M7 of greater perhaps. Something like SPARC-M[7+]
perhaps.
Regards,
Sean.
On 03/08/16 11:47, Erik Joelsson wrote:
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