RFR (XL): 8019972: PPC64 (part 9): platform files for interpreter only VM.
Lindenmaier, Goetz
goetz.lindenmaier at sap.com
Wed Jul 24 07:46:11 PDT 2013
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?
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