RFR (M): 8036767 PPC64: Support for little endian execution model

[Erik Joelsson]

On 2015-02-23 19:57, Andrew Hughes wrote:
> ----- Original Message -----
>> I think the jdk changes with ppc64le as CPU make sense.
>>
>> Note that the changes to SoundDefs.h and SoundLibraries.gmk will be
>> obsolete with JDK-8072665 which is currently in the client forest.
>>
> Is it worth waiting on this to be promoted to jdk9 then?
Actually, I think the client people would prefer if a change to those 
files went through the client forest, but if you rebase there, then 
there is no change to client files. If it's alright with you, I would 
recommend either waiting or perhaps just skip out on that change and 
push early, as we expect it to go away in jdk9/dev in a week or so.

/Erik
> The change is rather silly in the existing code. X_ARCH doesn't seem
> to be actually used anywhere, and we've been building fine without
> a definition for PPC64 (big-endian)... If 8072665 finally gets rid of
> them, that's one barrier gone for introducing new arch and os ports.
>
>> /Erik
>>
>> On 2015-02-23 15:16, Andrew Hughes wrote:
>>> ----- Original Message -----
>>>> Apologies to Tiago as there were two webrevs and one got stripped from
>>>> the email. Here's Tiago's webrev:
>>>>
>>>> http://cr.openjdk.java.net/~dholmes/rh1191652-jdk9/webrev.00/
>>>>
>>>> David
>>>>
>>>> On 19/02/2015 2:22 PM, David Holmes wrote:
>>>>> Now hosted at:
>>>>>
>>>>> http://cr.openjdk.java.net/~dholmes/ahughes-rh1191652-jdk9-webrev/
>>>>>
>>>>> David
>>>>>
>>>>> On 19/02/2015 1:35 PM, David Holmes wrote:
>>>>>> Hi Tiago,
>>>>>>
>>>>>> Please email me the tar files and I will host it for you.
>>>>>>
>>>>>> Thanks,
>>>>>> David
>>>>>>
>>>>>> On 19/02/2015 1:02 PM, Tiago Sturmer Daitx wrote:
>>>>>>> On Wed, 2015-02-18 at 07:33 -0500, Andrew Hughes wrote:
>>>>>>>> I now have these changes working on 8u31:
>>>>>>>>
>>>>>>>> http://cr.openjdk.java.net/~andrew/rh1191652/root
>>>>>>>> http://cr.openjdk.java.net/~andrew/rh1191652/jdk
>>>>>>>>
>>>>>>>> I can re-base these onto whichever OpenJDK 9 tree is appropriate and
>>>>>>>> push when
>>>>>>>> reviewed under the same bug as used for the HotSpot side.
>>>>>>> Concurrently to Andrew I also worked on a fix for JDK9 and came up with
>>>>>>> a somewhat different approach (based on jdk9/dev):
>>>>>>>
>>>>>>> http://tdaitx.github.com/openjdk-webrev/rh1191652-jdk9/webrev.00/hotspot/
>>>>>>>
>>>>>>> http://tdaitx.github.com/openjdk-webrev/rh1191652-jdk9/webrev.00/root
>>>>>>>
>>>>>>> To make it easy I already rebased Andrew's JDK8u31 patches to jdk9/dev
>>>>>>> (due to that the webrev ended up with my username).
>>>>>>>
>>>>>>> http://tdaitx.github.com/openjdk-webrev/rh1191652-jdk9/ahughes-webrev.00/hotspot/
>>>>>>>
>>>>>>>
>>>>>>> http://tdaitx.github.com/openjdk-webrev/rh1191652-jdk9/ahughes-webrev.00/jdk
>>>>>>>
>>>>>>>
>>>>>>> http://tdaitx.github.com/openjdk-webrev/rh1191652-jdk9/ahughes-webrev.00/root
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> I tested both approaches by building Hadoop (which triggered some
>>>>>>> interesting bugs on various projects due to Jigsaw).
>>>>>>>
>>>>>>> Sorry for the github links, but I don't have an account at
>>>>>>> cr.openjdk.java.net that I can use. I can provide tar files if anyone
>>>>>>> is
>>>>>>> willing to host those webrevs.
>>>>>>>
>>>>>>> Regards,
>>>>>>> Tiago Daitx
>>>>>>>
>>> Where do we go with this next?
>>>
>>> I'm still in favour of my own patches on the JDK side, as I think hiding
>>> the
>>> architecture there is just asking for problems further down the line.
>>