RFR (XL): 8019972: PPC64 (part 9): platform files for interpreter only VM.
Lindenmaier, Goetz
goetz.lindenmaier at sap.com
Thu Jul 25 17:02:09 PDT 2013
Hi Vladimir,
thanks for testing!
We soon need to apply this to 0009:
diff -r 63458ae3c26f src/cpu/ppc/vm/frame_ppc.inline.hpp
--- a/src/cpu/ppc/vm/frame_ppc.inline.hpp Fri Jul 26 01:17:42 2013 +0200
+++ b/src/cpu/ppc/vm/frame_ppc.inline.hpp Fri Jul 26 01:56:10 2013 +0200
@@ -224,8 +224,8 @@
return &tos[offset + 1]; // prepushed tos
}
-inline JavaCallWrapper* frame::entry_frame_call_wrapper() const {
- return (JavaCallWrapper*)entry_frame_locals()->call_wrapper_address;
+inline JavaCallWrapper** frame::entry_frame_call_wrapper_addr() const {
+ return (JavaCallWrapper**)&entry_frame_locals()->call_wrapper_address;
}
inline oop frame::saved_oop_result(RegisterMap* map) const {
Probably the corresponding change will come with the build change.
David, thanks for fixing the build.
Best regards,
Goetz.
-----Original Message-----
From: ppc-aix-port-dev-bounces at openjdk.java.net [mailto:ppc-aix-port-dev-bounces at openjdk.java.net] On Behalf Of Vladimir Kozlov
Sent: Friday, July 26, 2013 1:38 AM
Cc: 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.
Hotspot JPRT testing passed.
I will push these changes into stage repo when David's changes reach it.
Thanks,
Vladimir
On 7/24/13 10:43 PM, Vladimir Kozlov wrote:
> Thank you, Goetz,
>
> This looks good.
>
> David pushed makefile changes (8020799) in group's repo. I will try to
> combine all these changes with staged sources and run JPRT test builds
> tomorrow.
>
> Thanks,
> Vladimir
>
> On 7/24/13 7: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?
>>
>> 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