RFR (XL): 8019972: PPC64 (part 9): platform files for interpreter only VM.
david.holmes at oracle.com
Sun Jul 21 20:26:49 PDT 2013
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 ??
> 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,
> -----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; 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.
> On 18/07/2013 1:34 AM, Lindenmaier, Goetz wrote:
>> 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?
>> Best regards,
More information about the hotspot-dev