RFR (XL): 8019972: PPC64 (part 9): platform files for interpreter only VM.
Lindenmaier, Goetz
goetz.lindenmaier at sap.com
Thu Jul 25 23:16:42 PDT 2013
Hi Vladimir,
the change will be necessary once
8016131: nsk/sysdict/vm/stress/chain tests crash the VM in 'entry_frame_is_first()'
arrives in the stage repository. So I'd like to test 0009 once more before you
push it, and adapt it accordingly.
This should not invalidate your tests, as it's in a ppc file.
Best regards,
Goetz.
-----Original Message-----
From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com]
Sent: Freitag, 26. Juli 2013 02:13
To: Lindenmaier, Goetz
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.
Hi Goetz,
On 7/25/13 5:02 PM, Lindenmaier, Goetz wrote:
> Hi Vladimir,
>
> thanks for testing!
> We soon need to apply this to 0009:
What do you mean "soon"?
Do you ask me to fix it in your latest ppcfiles-3-hotspot.changeset
before pushing? Or it will be separate changeset?
thanks,
Vladimir
>
> 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