RFR (XL): 8019972: PPC64 (part 9): platform files for interpreter only VM.
Volker Simonis
volker.simonis at gmail.com
Fri Aug 2 08:15:25 PDT 2013
Hi Vladimir,
thank you for syncing our hotspot forest in the staging repository.
I have now applied the changes mentioned by Goetz to his webrev:
http://cr.openjdk.java.net/~simonis/webrevs/8019972/
It builds and runs fine on Linux/ppc64.
Can you please try JPRT and push it if everything works out fine?
Thank you and best regards,
Volker
On Fri, Jul 26, 2013 at 8:57 AM, Vladimir Kozlov
<vladimir.kozlov at oracle.com> wrote:
> 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