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

Erik Joelsson erik.joelsson at oracle.com
Thu Mar 27 10:42:26 UTC 2014

Oops, sent this unfinished. See answers inline instead:

On 2014-03-27 11:30, Erik Joelsson wrote:
> On 2014-03-27 09:36, Volker Simonis wrote:
>> On Thu, Mar 27, 2014 at 9:05 AM, Erik Joelsson 
>> <erik.joelsson at oracle.com> wrote:
>>> There are unfortunately legal complications surrounding updating these
>>> files. We can initiate the approval dance, but it will take time to go
>>> through (weeks at least). This is the reason Magnus added the 
>>> wrapper around
>>> config.guess, so that we could get functional updates to it faster.
>> OK, but as I wrote, config.guess currently only maps some recognized
>> systems to different names. This case is different because for ppc64le
>> the output of 'autoconf-config.guess' would be an emtpy string and a
>> quite big error message on stderr. Do you really want that we make
>> Linux/ppc64le the default fallback in config.guess if
>> 'autoconf-config.guess' can not detect a system?
Why does it need to be the only fallback? Couldn't you do some sanity 
uname check as well?
>> Or should we exceptionally just patch 'autoconf-config.guess' if we
>> know that we will update it anyway with a new version within a few
>> weeks? I think I'd prefer this solution, because this is just one
>> change which will be automatically removed once we integrate the new
>> 'autoconf-config.guess' version. If we just hack 'config.guess' we
>> would have to manually take that change back once we get the new
>> 'autoconf-config.guess' version.
It's unclear to us if we are allowed to make edits in these files.

I also suspect that the current wrapper file would need to be changed 
after an update anyway.
>> In any case I'd kindly ask you to start the 'legal approval dance' :)
Working on it. Is this for JDK9 only or are you planning backports?


More information about the hotspot-dev mailing list