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

Vladimir Kozlov vladimir.kozlov at oracle.com
Mon Jul 22 13:03:48 PDT 2013 

On 7/22/13 11:03 AM, Lindenmaier, Goetz wrote:
> Hi,
>
> I updated the webrev.  The code is not without ppc_ and PPC_
> prefixes.
> http://cr.openjdk.java.net/~goetz/webrevs/8019972-ppc_files/
> You can have a look at it, and if you have further comments regarding
> the style it would be nice to get them early.  I still have to adapt all
> the remaining changes in the patch queue, and then test it with the
> compiler.  With that I obviously can run more tests.

In general it is good. Few notes.

MacroAssembler::encode_klass_not_null() is wrong. LogKlassAlignmentInBytes should be used or 
Universe::narrow_klass_shift() in hs25 since klasses were moved to metaspace.
Try to run tests with LogMinObjAlignmentInBytes=16 (=32).

BTW, the new implementation is coming which will have separate base for compressed classes: 8003424. There was review 
sent last week. So using r30 unconditionally will be incorrect.

>
> 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.

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