RFR(S): 8016491: PPC64 (part 2): Clean up PPC defines.
David Holmes
david.holmes at oracle.com
Thu Jun 13 23:07:32 PDT 2013
Hi Goetz,
I think having platform_ppc define PPC32, and platform_ppc64 define
PPC64, with macros.hpp doing
#if defined(PPC32) | defined(PPC64)
#infdef PPC
#define PPC
is the right way to do this. It echoes what we do for x86.
I was concerned that ppc32 was going to propagate everywhere but it
appears that we would still use "ppc" to reflect a 32-bit PPC build eg
as the ARCH and BUILD_ARCH value, in platform_ppc, and in
TARGET_ARCH_ppc etc. I assume your port (I hate this 'yours', 'ours'
business :( ) uses ppc64 ?
A few places where PPC has become PPC32 indicate where cleanup is needed
anyway:
- os_xxx.cpp: the cpu_arch[] strings should not be hardwired in the file
given they represent values we already define in the platform_xxx file.
- vm_version.cpp. The #define for CPU again should be handled via a
variable passed by make; or at a minimum could be inside the platform
specific vm_version_xxx.hpp files! The FLOAT_ARCH strings are
superfluous now as we always set FLOAT_ARCH via the build - this should
be cleaned up.
The change in os_xxx_zero.hpp seems unnecessary but harmless.
The change in frame.h/cpp is indeed strange. I have no idea why our PPC
port needs to do something in a completely different way to our other 3
platforms. I will raise this with the team and see what can be done.
Similarly for sharedRuntime.h/cpp. I would expect this to be conditional
on the FP support.
So this all seems okay to me.
Thanks,
David
On 14/06/2013 7:36 AM, Lindenmaier, Goetz wrote:
> Hi,
>
> Thanks for the bugid, Vladimir, I updated the webrev.
> http://cr.openjdk.java.net/~goetz/webrevs/8016491-PPC_defines/
>
> I think defining PPC in macro.hpp makes it a bit more clear that
> it's meant for all, as it's coded in the #if. Also if I read code, I would
> more easily find it there than in platform_ppcXX.
> But the other way is OK, too.
> The #ifndef is not nice, I agree. Maybe a general #undef PPC
> before the #if?
>
> Best regards,
> Goetz.
>
> PS: About the JBS, I got the mail for the first change, but not for
> the second.
>
>
>
>
> -----Original Message-----
> From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com]
> Sent: Thursday, June 13, 2013 11:11 PM
> To: Lindenmaier, Goetz
> Cc: 'David Holmes'; 'Chris Plummer'; 'ppc-aix-port-dev at openjdk.java.net'; 'hotspot-dev at openjdk.java.net'
> Subject: Re: JEP 175 - Review comments
>
> On 6/13/13 1:25 PM, Lindenmaier, Goetz wrote:
>> Hi Vladimir,
>>
>> I made a webrev with the changes you proposed:
>> http://cr.openjdk.java.net/~goetz/webrevs/PPC_defines/
>
> I am not sure about what is the best solution for #define PPC, with
> #ifdef check in macros.hpp or, as Chris suggested, remove it from
> macros.hpp and add -DPPC in platform_ppc and platform_ppc64.
>
> And we need to wait what David can suggest for frame.cpp (may be comment
> should be enough).
>
>> Unfortunately I didn't get the JBS mail with the bugid yet.
>> If I have that, I'll update the webrev change message.
>
> Sorry. It means I have to send Bug ID each time I created one :(
> For this one it is:
>
> 8016491: PPC64 (part 2): Clean up PPC defines.
>
> Please, resend request for review in separate mail as you did for first
> 8016476.
>
> I also filed next bug:
>
> 8016586: PPC64 (part 3): basic changes for PPC64
>
> Thanks,
> Vladimir
>
>>
>> Best regards,
>> Goetz.
>>
>>
>>
>> -----Original Message-----
>> From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com]
>> Sent: Thursday, June 13, 2013 7:24 PM
>> To: Lindenmaier, Goetz
>> Cc: David Holmes; Chris Plummer; ppc-aix-port-dev at openjdk.java.net; hotspot-dev at openjdk.java.net
>> Subject: Re: JEP 175 - Review comments
>>
>> Hi,
>>
>> With next changes in make/linux/platform_ppc
>>
>> -sysdefs = -DLINUX -D_GNU_SOURCE -DPPC
>> +sysdefs = -DLINUX -D_GNU_SOURCE -DPPC32
>>
>> g++ still doesn't like it:
>>
>> /opt/jprt/T/P1/154912.vkozlov/s/src/share/vm/utilities/macros.hpp:344:1:
>> error: "PPC" redefined
>> <built-in>: error: this is the location of the previous definition
>>
>> I have to do next changes in macros.hpp to pass it:
>>
>> #if defined(PPC32) || defined(PPC64)
>> +#ifndef PPC
>> #define PPC
>> +#endif
>> #define PPC_ONLY(code) code
>> #define NOT_PPC(code)
>> #else
>> +#undef PPC
>> #define PPC_ONLY(code)
>> #define NOT_PPC(code) code
>> #endif
>>
>> Please, fix your patch accordingly (it is all open sources).
>>
>> Thanks,
>> Vladimir
>>
>> On 6/13/13 5:29 AM, Lindenmaier, Goetz wrote:
>>> Hi David,
>>>
>>> I understand there are three cases:
>>> 1.) A real 32-bit processor/instruction set
>>> 2.) A real 64-bit processor/instruction set using 64-bit addresses etc.
>>> 3.) A 64-bit processor/instruction set using 32-bit addresses etc.
>>
>> Is 3) theoretical combination or you are doing it?
>>
>>>
>>> My naming is the following:
>>> 1.) PPC32
>>> 2.) PPC64 & LP64
>>> 3.) PPC64 & !LP64.
>>> PPC should be valid for all.
>>>
>>> I understood your port is of kind 1., but I really don’t know that.
>>> Thus I changed the existing PPC guards to PPC32 where we don't
>>> need the guarded code.
>>>
>>> This distinction seems to me to fit well in
>>> os_bsd_zero.hpp
>>> os_linux_zero.hpp
>>> sharedRuntime.cpp
>>> sharedRuntime.hpp
>>> vm_version.cpp / FLOAT_ARCH_STR
>>>
>>> You are right for the defines in
>>> frame.hpp/frame.cpp
>>> Here I guard what is probably an implementation detail of your port and
>>> not a restriction of the architecture. But maybe you can clean up this
>>> piece of code, or tell me by what else I should guard this.
>>>
>>> In patch 0008 you see the libarch adaption:
>>> LIBARCH/ppc64 = ppc64
>>> LIBARCH/ppc = ppc
>>> I'm happy to adapt the naming of your port however you want to.
>>>
>>> Best regards,
>>> Goetz.
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> yes, I changed PPC to PPC32 wherever we don't need the
>>> special case in our port. I do not know why you implemented
>>> the special cases, and maybe you need a define that is more
>>> verbose about the reason.
>>>
>>> -----Original Message-----
>>> From: David Holmes [mailto:david.holmes at oracle.com]
>>> Sent: Donnerstag, 13. Juni 2013 12:27
>>> To: Lindenmaier, Goetz
>>> Cc: Chris Plummer; Vladimir Kozlov; ppc-aix-port-dev at openjdk.java.net; hotspot-dev at openjdk.java.net
>>> Subject: Re: JEP 175 - Review comments
>>>
>>> Hi Goetz,
>>>
>>> On 13/06/2013 5:25 PM, Lindenmaier, Goetz wrote:
>>>> Hi,
>>>>
>>>> @Chris: -DPPC32 needs to be set in make/<os>/platform_ppc32.
>>>
>>> I think BUILD_ARCH would also need to be ppc32 to pick that up - but
>>> then we would need to change LIB_ARCH back to ppc. Is the 64-bit port
>>> using ppc64 as the LIB_ARCH?
>>>
>>>> @David: That's not true. Platform_i486 sets -DIA32, platform_amd64 sets -DAMD64,
>>>> and in macros.hpp you find
>>>
>>> Okay I confess, it was a bad idea to generalize that given that out of
>>> the four platforms we support in the Oracle JDK, two are 32-bit only, so
>>> we only have sparc and x86 as examples. On sparc we only use SPARC and
>>> _LP64=1 to indicate things (and obviously in sparc specific files
>>> anything not in _LP64=1 is implicitly 32-bit).
>>>
>>> For x86 .... well x86 is a bit of a historical mess. So yes all those
>>> defines exist but the predominant form in shared code is X86 and AMD64
>>> (as a synonym for LP64=1). IA32 exists but is barely used and arguably
>>> most of the places it remains are relics from before the 32-bit and
>>> 64-bit x86 code merge took place. So we have some historical baggage there.
>>>
>>> My main concern with the PPC, PPC32, PPC64 proposal is that the patch I
>>> saw:
>>>
>>> http://hg.openjdk.java.net/ppc-aix-port/jdk8/hotspot/file/df79d76c17ab/ppc_patches/0002_PPC_defines.patch
>>>
>>> seemed to use PPC32 in places I would not expect. I'm starting to feel
>>> that this is not 32 vs 64 per-se, but that PPC32 is being used as a way
>>> to flag "PPC Oracle" in a way that excludes it from use by the PPC64
>>> port. If that is the case, and I can understand that it may well be
>>> given the existing PPC specific code was indeed put in place to support
>>> Oracle's PPC port, then perhaps we can look at ways of dealing with that
>>> without using what seems to me to be an artificial 32 vs 64-bit distinction?
>>>
>>> Aside: I would greatly prefer if ARM and PPC were never mentioned in the
>>> (existing) openjdk code, but that would require a level of refactoring
>>> in places that no-one unfortunately has the time to do. That said
>>> perhaps there are some places where a cleaner separation is possible.
>>> There are also places where compiler defines could be used to set string
>>> values rather than using the cpu ifdefs ie:
>>>
>>> #ifdef PPC
>>> #define CPU "ppc"
>>> etc
>>>
>>> David
>>> -----
>>>
>>>>
>>>> #if defined(IA32) || defined(AMD64)
>>>> #define X86
>>>> #define X86_ONLY(code) code
>>>> #define NOT_X86(code)
>>>> #else
>>>> #undef X86
>>>> #define X86_ONLY(code)
>>>> #define NOT_X86(code) code
>>>> #endif
>>>>
>>>> It's just not that obvious as the names of these platforms
>>>> are messed up. On PPC I wanted to follow a clean approach.
>>>>
>>>> Best regards,
>>>> Goetz.
>>>>
>>>>
>>>>
>>>>
>>>> -----Original Message-----
>>>> From: David Holmes [mailto:david.holmes at oracle.com]
>>>> Sent: Donnerstag, 13. Juni 2013 04:46
>>>> To: Lindenmaier, Goetz
>>>> Cc: Chris Plummer; Vladimir Kozlov; ppc-aix-port-dev at openjdk.java.net; hotspot-dev at openjdk.java.net
>>>> Subject: Re: JEP 175 - Review comments
>>>>
>>>> Just adding my 2c from what was an internal discussion but is not in any
>>>> way confidential:
>>>>
>>>> We don't use 3 architecture designators on other platforms to
>>>> distinguish between "common", 32-bit and 64-bit, so why do we need to do
>>>> so for PPC ?
>>>>
>>>> The normal approach would be to add _LP64=1 specific ifdefs within an
>>>> architectural ifdef.
>>>>
>>>> This change (PPC32 usage) seems to be introducing unnecessary changes
>>>> and inconsistency with how 32-bit vs 64-bit is generally handled.
>>>>
>>>> Further, it is far from obvious from the patch that code now flagged as
>>>> PPC32 is indeed 32-bit specific rather than common!
>>>>
>>>> David
>>>> -----
>>>>
>>>> On 13/06/2013 5:54 AM, Chris Plummer wrote:
>>>>> Hi Goetz,
>>>>>
>>>>> Regarding the change to use PPC32 and PPC64 instead of PPC, I don't see
>>>>> PPC32 being defined anywhere. Perhaps it belongs in "sysdefs" in
>>>>> make/linux/platform_ppc.
>>>>>
>>>>> There are a lot of PPC references in c1 that don't appear to have been
>>>>> addressed.
>>>>>
>>>>> Is there a reason that PPC is not also defined for both PPC32 and PPC64,
>>>>> allowing you to use
>>>>>
>>>>> #ifdef PPC
>>>>>
>>>>> rather than
>>>>>
>>>>> #if defined(PPC32) || defined(PPC64)
>>>>>
>>>>> best regards,
>>>>>
>>>>> Chris
>>>>>
>>>>> On 6/12/13 7:44 AM, Lindenmaier, Goetz wrote:
>>>>>> Hi,
>>>>>>
>>>>>> With my recent changes I removed some of the problems Vladimir mentioned.
>>>>>>
>>>>>> I also added the patches queue I maintain into our jdk8/hotspot
>>>>>> repository,
>>>>>> at hotspot/ppc_patches.
>>>>>> Applied to the staging hotspot directory, the linuxppc and aixppc
>>>>>> hotspots
>>>>>> can be built.
>>>>>>
>>>>>> The queue contains the changes proposed by me before, with minor
>>>>>> changes due
>>>>>> to recent development:
>>>>>>
>>>>>> 1-9 linuxppc C-interpreter port (In our plan milestone M2.1)
>>>>>> 11-15 aixppc C-interpreter port (In our plan milestone M2.2)
>>>>>> 101-107 C-interpreter improvements
>>>>>> 111-122 ppc C2 compiler port leading to a vm rudimentarily working
>>>>>> 200-217 C2 compiler fixes, extensions etc needed for a stable and
>>>>>> performant ppc port.
>>>>>> Altogether currently 49 changes.
>>>>>>
>>>>>> Our plan was to propose the changes in the order of the queue for
>>>>>> review. I'm happy to create webrevs for any of them.
>>>>>>
>>>>>> Vladimir, maybe the queue simplifies reviewing the port, as the changes
>>>>>> are more complete. They include all later improvements by fixes or
>>>>>> adaptions in merge changes.
>>>>>> For why and where I renamed PPC to PPC32 see the second change in the
>>>>>> queue.
>>>>>>
>>>>>> Best regards,
>>>>>> Goetz.
>>>>>>
>>>>>>
>>>>>> PS: This can be used as the invokedynamic repository:
>>>>>> hg clone http://hg.openjdk.java.net/ppc-aix-port/jdk8/hotspot
>>>>>> ppc-hotspot
>>>>>> hg clone http://hg.openjdk.java.net/ppc-aix-port/stage/hotspot
>>>>>> stage-hotspot
>>>>>> cd stage-hotspot
>>>>>> ln -s .../ppc-hotspot/ppc_patches/ .hg/patches
>>>>>> hg qpush -a
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> -----Original Message-----
>>>>>> From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com]
>>>>>> Sent: Dienstag, 11. Juni 2013 18:34
>>>>>> To: Lindenmaier, Goetz
>>>>>> Cc: Volker Simonis; Azeem Jiva; Chris Plummer
>>>>>> Subject: Re: JEP 175 - Review comments
>>>>>>
>>>>>> Here is result of my first attempt to build/test ppc changes together
>>>>>> with our closed sources.
>>>>>>
>>>>>> Small problems:
>>>>>>
>>>>>> src/share/vm/memory/allocation.hpp:209: Trailing whitespace
>>>>>> src/share/vm/memory/allocation.inline.hpp:121: Trailing whitespace
>>>>>> src/share/vm/opto/escape.cpp:2207: Trailing whitespace
>>>>>> src/share/vm/memory/allocation.hpp:212: Trailing whitespace
>>>>>> src/share/vm/opto/escape.cpp:2214: Trailing whitespace
>>>>>>
>>>>>> Build on MacOS:
>>>>>>
>>>>>> src/share/vm/opto/callGenerator.cpp: In member function 'virtual
>>>>>> JVMState* VirtualCallGenerator::generate(JVMState*)':
>>>>>> src/share/vm/opto/callGenerator.cpp:204: error:
>>>>>> 'zero_page_read_protected' is not a member of 'os'
>>>>>>
>>>>>> agent/src/os/bsd/MacosxDebuggerLocal.m:54:2: error: #error
>>>>>> UNSUPPORTED_ARCH
>>>>>> agent/src/os/bsd/MacosxDebuggerLocal.m:167:4: error: #error
>>>>>> UNSUPPORTED_ARCH
>>>>>> agent/src/os/bsd/MacosxDebuggerLocal.m:591:2: error: #error
>>>>>> UNSUPPORTED_ARCH
>>>>>>
>>>>>>
>>>>>> We have several conflict with closed sources builds:
>>>>>>
>>>>>> src/share/vm/utilities/elfSymbolTable.cpp: In member function 'bool
>>>>>> ElfSymbolTable::lookup(unsigned char*, int*, int*, int*)':
>>>>>> src/share/vm/utilities/elfSymbolTable.cpp:97: error: comparison between
>>>>>> signed and unsigned integer expressions
>>>>>> src/share/vm/utilities/elfSymbolTable.cpp:124: error: comparison between
>>>>>> signed and unsigned integer expressions
>>>>>>
>>>>>> error: no 'oopDesc** frame::interpreter_frame_mirror_addr() const'
>>>>>> member function declared in class 'frame'
>>>>>>
>>>>>> error: no matching function for call to
>>>>>> 'SharedRuntime::c_calling_convention(BasicType*&, VMRegPair*&, uint&)'
>>>>>>
>>>>>> I think it is due to changes like next:
>>>>>>
>>>>>> -#ifdef PPC
>>>>>> +#ifdef PPC32
>>>>>> oop* interpreter_frame_mirror_addr() const;
>>>>>>
>>>>>>
>>>>>> Next is easy fix in our closed sources but it requires efforts from our
>>>>>> side:
>>>>>>
>>>>>> src/share/vm/prims/methodHandles.cpp: In static member function 'static
>>>>>> void MethodHandles::generate_adapters()':
>>>>>> src/share/vm/prims/methodHandles.cpp:68: error: 'adapter_code_size'
>>>>>> cannot be used as a function
>>>>>> src/share/vm/prims/methodHandles.cpp:70: error: 'adapter_code_size'
>>>>>> cannot be used as a function
>>>>>>
>>>>>>
>>>>>> I would suggest to do such shared changes which affects different builds
>>>>>> later after initial push.
>>>>>>
>>>>>>
>>>>>> Thanks,
>>>>>> Vladimir
>>>>>>
>>>>>> On 6/7/13 3:20 AM, Lindenmaier, Goetz wrote:
>>>>>>> Hi Vladimir,
>>>>>>>
>>>>>>> I updated the repo to jdk8-b92. Our nightly tests built and
>>>>>>> tested it successfully. In case you experience any problems
>>>>>>> please tell me the details so I can fix them.
>>>>>>>
>>>>>>> Best regards,
>>>>>>> Goetz.
>>>>>>>
>>>>>>> http://cr.openjdk.java.net/~simonis/ppc-aix-port/index.html
>>>>>>>
>>>>>>>
>>>>>>> -----Original Message-----
>>>>>>> From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com]
>>>>>>> Sent: Dienstag, 4. Juni 2013 20:58
>>>>>>> To: Simonis, Volker
>>>>>>> Cc: Iris Clark; Wintergerst, Michael; Lindenmaier, Goetz; Bernard
>>>>>>> Traversat; Jeannette Hung; Azeem Jiva; David Therkelsen; Mikael
>>>>>>> Vidstedt; Neil Richards; Steve Poole; luchsh at cn.ibm.com; Tim Ellison;
>>>>>>> Alan Bateman
>>>>>>> Subject: Re: JEP 175 - Review comments
>>>>>>>
>>>>>>> Volker,
>>>>>>>
>>>>>>> Can you or someone update
>>>>>>> http://hg.openjdk.java.net/ppc-aix-port/jdk8/hotspot to match latest
>>>>>>> sources in http://hg.openjdk.java.net/jdk8/jdk8/hotspot?
>>>>>>> I just tried to merge them and build Hotspot on x86 without success.
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Vladimir
>>>>>>>
>>>>>>> On 6/4/13 7:04 AM, Simonis, Volker wrote:
>>>>>>>> We intentionally used 'porters-dev' rather than'ppc-aix-port-dev' in
>>>>>>>> the
>>>>>>>> beginning to address a broader audience for the initial discussions.
>>>>>>>>
>>>>>>>> But I'm happy to change that back to 'ppc-aix-port-dev' now.
>>>>>>>>
>>>>>>>> Regards,
>>>>>>>> Volker
>>>>>>>>
>>>>>>>>
>>>>>>>> ------------------------------------------------------------------------
>>>>>>>>
>>>>>>>> *From:* Iris Clark [iris.clark at oracle.com]
>>>>>>>> *Sent:* Tuesday, June 04, 2013 3:50 PM
>>>>>>>> *To:* Simonis, Volker; Wintergerst, Michael; Lindenmaier, Goetz;
>>>>>>>> Bernard
>>>>>>>> Traversat; Jeannette Hung; Azeem Jiva; David Therkelsen; Mikael
>>>>>>>> Vidstedt; Neil Richards; Steve Poole; luchsh at cn.ibm.com; Tim Ellison;
>>>>>>>> iris.clark at oracle.com
>>>>>>>> *Cc:* Alan Bateman; Vladimir Kozlov
>>>>>>>> *Subject:* RE: JEP 175 - Review comments
>>>>>>>>
>>>>>>>> Hi, Volker.
>>>>>>>>
>>>>>>>> Sorry about this, one more thing about the JEP...
>>>>>>>>
>>>>>>>> I think that the "Discussion" list probably needs to be updated to be
>>>>>>>> your Project's mailing list (ppc-aix-port-dev). Right now it's listed
>>>>>>>> as porters-dev.
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>>
>>>>>>>> iris
>>>>>>>>
>>>>>>>> *From:*Simonis, Volker [mailto:volker.simonis at sap.com]
>>>>>>>> *Sent:* Tuesday, June 04, 2013 12:12 AM
>>>>>>>> *To:* Iris Clark; Wintergerst, Michael; Lindenmaier, Goetz; Bernard
>>>>>>>> Traversat; Jeannette Hung; Azeem Jiva; David Therkelsen; Mikael
>>>>>>>> Vidstedt; Neil Richards; Steve Poole; luchsh at cn.ibm.com; Tim Ellison
>>>>>>>> *Cc:* Alan Bateman; Vladimir Kozlov
>>>>>>>> *Subject:* RE: JEP 175 - Review comments
>>>>>>>>
>>>>>>>> Hi Iris,
>>>>>>>>
>>>>>>>> you're right, the title is too clumsy - I just couldn't come up with
>>>>>>>> something better yesterday in the evening.
>>>>>>>>
>>>>>>>> "PowerPC/AIX Port" sounds good to me. If nobody complains, I'll take
>>>>>>>> it.
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>> Volker
>>>>>>>>
>>>>>>>> ------------------------------------------------------------------------
>>>>>>>>
>>>>>>>>
>>>>>>>> *From:*Iris Clark [iris.clark at oracle.com]
>>>>>>>> *Sent:* Tuesday, June 04, 2013 2:57 AM
>>>>>>>> *To:* Simonis, Volker; Wintergerst, Michael; Lindenmaier, Goetz;
>>>>>>>> Bernard
>>>>>>>> Traversat; Jeannette Hung; Azeem Jiva; David Therkelsen; Mikael
>>>>>>>> Vidstedt; Neil Richards; Steve Poole; luchsh at cn.ibm.com
>>>>>>>> <mailto:luchsh at cn.ibm.com>; Tim Ellison
>>>>>>>> *Cc:* Alan Bateman; Vladimir Kozlov; iris.clark at oracle.com
>>>>>>>> <mailto:iris.clark at oracle.com>
>>>>>>>> *Subject:* RE: JEP 175 - Review comments
>>>>>>>>
>>>>>>>> Hi, Volker.
>>>>>>>>
>>>>>>>> I've just updated the JEP according to your suggestions.
>>>>>>>>
>>>>>>>> I'm not a Reviewer however, I think that the phrase "OpenJDK master
>>>>>>>> repositories" in the revised title is not ideal:
>>>>>>>>
>>>>>>>> --- a/jep-175.md Mon May 27 23:22:51 2013 +0400
>>>>>>>>
>>>>>>>> +++ b/jep-175.md Mon Jun 03 18:51:18 2013 +0200
>>>>>>>>
>>>>>>>> @@ -1,5 +1,5 @@
>>>>>>>>
>>>>>>>> JEP: 175
>>>>>>>>
>>>>>>>> -Title: Integrate PowerPC/AIX Port into JDK 8
>>>>>>>>
>>>>>>>> +Title: Integrate the PowerPC/AIX Port into the OpenJDK master
>>>>>>>> repositories
>>>>>>>>
>>>>>>>> Author: Volker Simonis
>>>>>>>>
>>>>>>>> Organization: SAP AG
>>>>>>>>
>>>>>>>> Created: 2013/1/11
>>>>>>>>
>>>>>>>> Thinking out loud, what about just "PowerPC/AIX Port"? JEPs are all
>>>>>>>> about adding features to JDK Release Projects. There are lots of
>>>>>>>> examples of JEPs [1] which don't begin with verbs, e.g. "133: Unicode
>>>>>>>> 6.2", "148: Small VM", "172: DocLint", etc. The JEP itself contains
>>>>>>>> additional details.
>>>>>>>>
>>>>>>>> Perhaps others have suggestions?
>>>>>>>>
>>>>>>>> Am I right with my assumption that the targeted release will still be
>>>>>>>> JDK 8 (or 9/8u respectively) but that the targeted release will be set
>>>>>>>> in the "Release" header field of the JEP by the OpenJDK Lead (as
>>>>>>>> specified in the JEP specification)?
>>>>>>>>
>>>>>>>> Yes. Once that field is populated, the value will appear in the JEP
>>>>>>>> index [1], see the third column.
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>>
>>>>>>>> Iris
>>>>>>>>
>>>>>>>> [1]: http://openjdk.java.net/jeps/0
>>>>>>>>
>>>>>>>> *From:*Simonis, Volker [mailto:volker.simonis at sap.com]
>>>>>>>> *Sent:* Monday, June 03, 2013 10:10 AM
>>>>>>>> *To:* Iris Clark; Wintergerst, Michael; Lindenmaier, Goetz; Bernard
>>>>>>>> Traversat; Jeannette Hung; Azeem Jiva; David Therkelsen; Mikael
>>>>>>>> Vidstedt; Neil Richards; Steve Poole; luchsh at cn.ibm.com
>>>>>>>> <mailto:luchsh at cn.ibm.com>; Tim Ellison
>>>>>>>> *Cc:* Alan Bateman; Vladimir Kozlov
>>>>>>>> *Subject:* RE: JEP 175 - Review comments
>>>>>>>>
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>> I've just updated the JEP according to your suggestions. Please find
>>>>>>>> the new version attached to this mail (I haven't checked the new
>>>>>>>> version
>>>>>>>> in until now to give everybody a chance to comment on the changes).
>>>>>>>>
>>>>>>>> Am I right with my assumption that the targeted release will still be
>>>>>>>> JDK 8 (or 9/8u respectively) but that the targeted release will be set
>>>>>>>> in the "Release" header field of the JEP by the OpenJDK Lead (as
>>>>>>>> specified in the JEP specification)?
>>>>>>>>
>>>>>>>> In addition to the changes proposed by you I've added the contents of
>>>>>>>> the "Approach" section from Azeems "PPCAIX plan" to the "Description"
>>>>>>>> section of the JEP. I've also added links to the new "PowerPC/AIX Port
>>>>>>>> Integration Plan" [2] of our "PowerPC/AIX Port OpenJDK Wiki Space" [3]
>>>>>>>> to the JEP.
>>>>>>>>
>>>>>>>> The "PowerPC/AIX Port Integration Plan" in the Wiki is intended to hold
>>>>>>>> Azeems "PPCAIX plan" document.
>>>>>>>>
>>>>>>>> @Iris: could you please somehow arrange to give Azeem editing rights to
>>>>>>>> that page?
>>>>>>>>
>>>>>>>> @Azeem: could you please be so kind to past the contents of the "PPCAIX
>>>>>>>> plan" into that page (once you have the appropriate rights)? I saw that
>>>>>>>> the document is created from an Atlassian Confluence Wiki anyway and in
>>>>>>>> my unlimited naivety I imagine this could be a simple copy-and-paste
>>>>>>>> operation:) If that doesn't work so easily, please let me know how I
>>>>>>>> could help.
>>>>>>>>
>>>>>>>> If there are no objections I plan to checkin the new version of the JEP
>>>>>>>> tomorrow after our telephone call.
>>>>>>>>
>>>>>>>> Thank you and best regards,
>>>>>>>> Volker
>>>>>>>>
>>>>>>>> [2]:
>>>>>>>> https://wiki.openjdk.java.net/pages/viewpage.action?pageId=13729959
>>>>>>>> [3]: https://wiki.openjdk.java.net/display/PPCAIXPort
>>>>>>>>
>>>>>>>> ------------------------------------------------------------------------
>>>>>>>>
>>>>>>>>
>>>>>>>> *From:*Iris Clark [iris.clark at oracle.com]
>>>>>>>> *Sent:* Friday, May 31, 2013 8:48 PM
>>>>>>>> *To:* Wintergerst, Michael; Simonis, Volker; Lindenmaier, Goetz;
>>>>>>>> Bernard
>>>>>>>> Traversat; Jeannette Hung; Azeem Jiva; David Therkelsen; Mikael
>>>>>>>> Vidstedt; Neil Richards; Steve Poole; luchsh at cn.ibm.com
>>>>>>>> <mailto:luchsh at cn.ibm.com>; Tim Ellison
>>>>>>>> *Cc:* iris.clark at oracle.com <mailto:iris.clark at oracle.com>; Alan
>>>>>>>> Bateman; Vladimir Kozlov
>>>>>>>> *Subject:* JEP 175 - Review comments
>>>>>>>>
>>>>>>>> Hi, Volker.
>>>>>>>>
>>>>>>>> JEP 175: Integrate PowerPC/AIX Port into JDK 8
>>>>>>>>
>>>>>>>> http://openjdk.java.net/jeps/175
>>>>>>>>
>>>>>>>> We're actively working to get your JEP to Funded. We had a few
>>>>>>>> comments:
>>>>>>>>
>>>>>>>> -Recommend that "8" be removed from the JEP title, etc.
>>>>>>>>
>>>>>>>> -Recommend that the first Motivation bullet clearly indicate that it is
>>>>>>>> only covering PPC/AIX.
>>>>>>>>
>>>>>>>> -Recommend that the second Motivation bullet be modified to make it
>>>>>>>> clear that it applies to Hotspot only.
>>>>>>>>
>>>>>>>> (Instructions for editing the JEP may be found in the "Mechanics"
>>>>>>>> section at the bottom of JEP 1 [1].)
>>>>>>>>
>>>>>>>> Vladimir Kozlov (VM) and Alan Bateman (Core Libraries) are lined up to
>>>>>>>> be the JEP's reviewers. Once they're satisfied with your
>>>>>>>> changes/feedback they'll add themselves to the JEP's "Reviewed-by"
>>>>>>>> line.
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>>
>>>>>>>> Iris Clark
>>>>>>>>
>>>>>>>> [1]: http://openjdk.java.net/jeps/1
>>>>>>>>
>>>>>
More information about the ppc-aix-port-dev
mailing list