RFR (XL): 8019972: PPC64 (part 9): platform files for interpreter only VM.
David Holmes
david.holmes at oracle.com
Wed Jul 24 22:22:46 PDT 2013
On 25/07/2013 12:46 AM, Lindenmaier, Goetz wrote:
> Hi,
>
> I updated the webrev once more.
> http://cr.openjdk.java.net/~goetz/webrevs/8019972-ppc_files/
>
> - I fixed encode_klass_not_null()
> - I cleaned up jni_ppc.h
> - added the guard in copy_ppc.hpp.
>
> Further there were problems on aix.
> I had to rename the condition code registers from CR0-7 to CCR0-7,
> as CR0-3 is defined in an AIX system header.
>
> David, can I mark the change as reviewed by you?
I only looked at handful of files.
David
> Best regards,
> Goetz.
>
> -----Original Message-----
> From: David Holmes [mailto:david.holmes at oracle.com]
> Sent: Dienstag, 23. Juli 2013 09:59
> 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.
>
> PS. Seems src/cpu/ppc/vm/copy_ppc.hpp has the same issue. The atomic
> copies for jlong are only correct on 64-bit.
>
> Is there other code in "bit-neutral" ppc files that is really only
> correct on 64-bit?
>
> David
> -----
>
> On 23/07/2013 5:54 PM, David Holmes wrote:
>> 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