RFR(S): 8016491: PPC64 (part 2): Clean up PPC defines.
Vladimir Kozlov
vladimir.kozlov at oracle.com
Fri Jun 14 21:25:14 PDT 2013
These changes (part 2) passed testing on ppc. Thumb up for push.
Thanks,
Vladimir
On 6/13/13 11:07 PM, David Holmes wrote:
> 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