RFR (XL): 8019972: PPC64 (part 9): platform files for interpreter only VM.
David Holmes
david.holmes at oracle.com
Tue Jul 23 00:54:01 PDT 2013
On 23/07/2013 6:03 AM, Vladimir Kozlov wrote:
> On 7/22/13 11:03 AM, Lindenmaier, Goetz wrote:
>>
>> I don't really care about the guard. Just tell me what to do...
>
> To be safe leave guards with PPC64 check instead of _lp64 as you suggested.
Yes please do that. I think the guard is important as this is a
bit-neutral file. If/when someone creates a 32-bit PPC port we don't
want them to have to re-discover the atomicity bugs with jlong/jdouble
that were found on the existing platforms.
Thanks,
David
> Do you plan to implement ppc32 or ppc64+lp32 or you can't tell me :) ? :
>
> jniTypes_ppc.hpp:
>
> 48 #ifndef PPC64
> 49 #error "ppc32 support currently not implemented!!!"
> 50 #endif // PPC64
>
> Our reviews are based on assumption that this port only supports
> PPC64+LP64 combination. Is this correct assumption?
>
> Do you really need to check __APPLE__ in jni_ppc.h? Yes, I have old ppc
> based macbook pro. But do we need it in this port?
>
> Regards,
> Vladimir
>
>>
>> Best regards,
>> Goetz.
>>
>>
>>
>> -----Original Message-----
>> From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com]
>> Sent: Monday, July 22, 2013 6:48 PM
>> To: Lindenmaier, Goetz
>> Cc: David Holmes; ppc-aix-port-dev at openjdk.java.net;
>> hotspot-dev at openjdk.java.net
>> Subject: Re: RFR (XL): 8019972: PPC64 (part 9): platform files for
>> interpreter only VM.
>>
>> On 7/22/13 5:40 AM, Lindenmaier, Goetz wrote:
>>>> ??? Or do you propose to change both of them to PPC64?
>>> Yes, sure, I want to change both.
>>
>> Why do we need this error if this code is only for PPC64 port? We will
>> have other compilation errors if we try to use
>> these sources for something else as we found already. Do you have an
>> other usage so you need this guard?
>>
>>>> All of the existing 64-bit ports have a direct correspondence between
>>>> the 64-bit platform designator (sparcv9, amd64, x86_64) and LP64.
>>>
>>> I know. And obviously there is a correspondence, as no one will
>>> Implement an LG64 memory model on a 32 bit machine.
>>> But the usage intermingles different memory model and architecture:
>>>
>>> E.g., the register declaration in register_x86_hpp is fine:
>>>
>>> #ifdef AMD64
>>> CONSTANT_REGISTER_DECLARATION(Register, r8, (8));
>>>
>>> But I think this makes no sense (assembler_x86.hpp):
>>>
>>> #ifdef _LP64
>>> void movsbq(Register dst, Address src);
>>> void movsbq(Register dst, Register src);
>>> // Move signed 32bit immediate to 64bit extending sign
>>> void movslq(Address dst, int32_t imm64);
>>> void movslq(Register dst, int32_t imm64);
>>>
>>> and should be guarded by AMD64.
>>
>> Strictly speaking you are right. But we will never do ilp32 for AMD64
>> so using _LP64 works for us. Also using AMD64
>> sometimes rise questions about Intel x64. So using _LP64 is more neutral.
>>
>>> And I want to get the PPC port right in such matters.
>>
>> I agree with this since ppc is more flexible than x86, it seems.
>>
>>> I'm currently removing the ppc_ prefixes ... big fun:)
>>
>> Sorry about that.
>>
>> Regards,
>> Vladimir
>>
>>> Best regards,
>>>
>>> Goetz.
>>>
>>> -----Original Message-----
>>> From: David Holmes [mailto:david.holmes at oracle.com]
>>> Sent: Montag, 22. Juli 2013 13:38
>>> To: Lindenmaier, Goetz
>>> Cc: Vladimir Kozlov; ppc-aix-port-dev at openjdk.java.net;
>>> hotspot-dev at openjdk.java.net
>>> Subject: Re: RFR (XL): 8019972: PPC64 (part 9): platform files for
>>> interpreter only VM.
>>>
>>> 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
>>> <mailto:hotspot-dev at openjdk.java.net>; ppc-aix-port-dev at openjdk.java.net
>>> <mailto: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
>>> <mailto:hotspot-dev at openjdk.java.net>; ppc-aix-port-dev at openjdk.java.net
>>> <mailto: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.
>>>
>>> >>>
>>>
More information about the ppc-aix-port-dev
mailing list