RFR (XL): 8019972: PPC64 (part 9): platform files for interpreter only VM.
Vladimir Kozlov
vladimir.kozlov at oracle.com
Thu Jul 25 23:57:08 PDT 2013
Thank you for explanation. I assume you will prepare a new 8019972 patch when 8016131 is pushed into stage repo (should
be next week (crossing fingers)). And I want to push this 8019972 changes using JPRT.
Regards,
Vladimir
On 7/25/13 11:16 PM, Lindenmaier, Goetz wrote:
> 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