RFR (XL): 8019972: PPC64 (part 9): platform files for interpreter only VM.

[David Holmes]

On 22/07/2013 5:14 PM, Lindenmaier, Goetz wrote:
> Hi David,
>
> PPC64: describes an instruction set / machine with all it's specialities.  And the instruction set
> 	we implemented the port for has an atomic 64-bit instruction.
> LP64 describes a memory model.  I.E, long == 64bit, int == 32bit , pointer == 64 bit.
> In contraditction to ILP64 (int == 64bit) etc, which you could as well implement with the
> PPC64 instruction set. You could also implement a system with ILP32 on PPC64, and then
> you would have an atomic 64-bit instruction.

That still doesn't explain why you think LP64 is okay for the atomic 
file but you want PPC64 for the orderAccess file. ??? Or do you propose 
to change both of them to PPC64?

All of the existing 64-bit ports have a direct correspondence between 
the 64-bit platform designator (sparcv9, amd64, x86_64) and LP64. LP64 
is the only 64-bit data model that the OpenJDK sources support.

> Compressed oops make sense to protect with LP64, because they are only helpful
> with 64 bit pointers.  While usage of LP64 is not exactly correct here, ILP64, SLP64
> etc would also use compressed oops.  But it's close enough I guess.

I'm not concerned about compressed oops. No idea where that came from ;-)

David
------

> Best regards,
>    Goetz.
>
> -----Original Message-----
> From: David Holmes [mailto:david.holmes at oracle.com]
> Sent: Montag, 22. Juli 2013 05:27
> To: Lindenmaier, Goetz
> Cc: hotspot-dev at openjdk.java.net; ppc-aix-port-dev at openjdk.java.net; Vladimir Kozlov
> Subject: Re: RFR (XL): 8019972: PPC64 (part 9): platform files for interpreter only VM.
>
> On 20/07/2013 5:47 AM, Lindenmaier, Goetz wrote:
>> Hi David,
>>
>>> I think orderAccess_linux_ppc.inline.hpp should have:
>>>      34 #ifndef _LP64
>>>      35 #error "Atomic currently only impleneted for PPC64"
>>>      36 #endif
>> You're right, I'll fix this.
>> If you don't object I'll guard it by PPC64 as it depends on the
>> processor architecture and not the memory model.
>
> Is there some case where _LP64 would be true but PPC64 would not be ???
> They seem effectively interchangeable but I don't know why you would use
> one in one file and the other in another file ??
>
> Thanks,
> David
>
>> If I will change the ppc_ prefixes that'll take a bit, especially
>> as I will have to adapt all the alignments :(.
>> But that does not matter, as we need to wait for your build
>> change anyways.
>>
>> Best regards,
>>     Goetz.
>>
>>
>>
>>
>>
>> -----Original Message-----
>> From: David Holmes [mailto:david.holmes at oracle.com]
>> Sent: Friday, July 19, 2013 7:29 AM
>> To: Lindenmaier, Goetz
>> Cc: hotspot-dev at openjdk.java.net; ppc-aix-port-dev at openjdk.java.net; Vladimir Kozlov
>> Subject: Re: RFR (XL): 8019972: PPC64 (part 9): platform files for interpreter only VM.
>>
>> Hi Goetz,
>>
>> Only a brief glance through ...
>>
>> I think orderAccess_linux_ppc.inline.hpp should have:
>>
>>      34 #ifndef _LP64
>>      35 #error "Atomic currently only impleneted for PPC64"
>>      36 #endif
>>
>> the same as in atomic_linux_ppc.inline.hpp (the jlong variants will only
>> be atomic on ppc64).
>>
>> BTW typo: 35 #error "Atomic currently only impleneted for PPC64"
>>
>> I also find the ppc_ prefix used in the assembly code somewhat redundant.
>>
>> David
>> -----
>>
>> On 18/07/2013 1:34 AM, Lindenmaier, Goetz wrote:
>>> Hi,
>>>
>>> This time with webrev. Sorry for the double mails.
>>>
>>> This change contains all the files in cpu/ppc and os_cpu/linux_ppc needed for
>>> the PPC64 interpreter port on linux.
>>>
>>> With this change you can do a core build on ppc64 and run the VM interpreter only.
>>> It executes simple programs as jvm98.
>>> The change requires
>>>
>>> *         8016697: Use stubs to implement safefetch
>>>
>>> *         8020059: The flag introduced by 8014972 is not defined ...
>>> which will arrive soon in the staging repository.
>>>
>>> I marked the change as XL as it contains a lot of code.  Nevertheless the
>>> code has no impact on the existing Oracle platforms.
>>>
>>> The change touches a single shared file, globals.hpp, removing a
>>> special case introduced for the port.  This is because we
>>> integrated some changes earlier than originally intended.
>>>
>>> Please review the change.  Does it need testing on Oracle side?
>>> http://cr.openjdk.java.net/~goetz/webrevs/8019972-ppc_files/
>>>
>>> Best regards,
>>>      Goetz.
>>>