From volker.simonis at gmail.com Mon Jun 8 18:31:41 2015 From: volker.simonis at gmail.com (Volker Simonis) Date: Mon, 8 Jun 2015 20:31:41 +0200 Subject: RFR(S): 8080684: PPC64: Fix little-endian build after "8077838: Recent developments for ppc" In-Reply-To: References: Message-ID: Hi Sasha, you're right - my fix was too complicated. I should have just used function_entry() instead of emit_fd() because function_entry() already wraps either emit_fd() or pc() depending on the platform. That's exactly what I've done in the new patch: http://cr.openjdk.java.net/~simonis/webrevs/2015/8080684.v2/ As a bonus I've also fixed the Power 8 detection which was broken because we issued an illegal 'lqarx' instruction to determine if we're on Power 8. Regards, Volker PS: I was actually able to test this change on a REAL ppc64le machine this time :) On Wed, May 20, 2015 at 3:25 AM, Alexander Smundak wrote: > It fails to compile because the code still references FileDescriptor, > even if ABI_ELFv2 is defined. > The revised patch which succeeds is here: > http://cr.openjdk.java.net/~asmundak/8080684/hotspot/webrev > (it's for jdk8u-dev branch) > but IMHO the proposed change isn't semantically right -- > if a method is called emit_fd, it should create a FileDescriptor. > I am not sure that rationale behind this patch is right -- a > compile-time error is usually easy to fix and verify that the semantics > is correct while fixing it, whereas runtime error usually requires > more effort. > > > On Tue, May 19, 2015 at 9:41 AM, Volker Simonis > wrote: >> Hi, >> >> can I please get a review for the following fix of the ppc64le build. >> >> @Sasha, Tiago: I would be also especially interested if somebody with >> a little-endian ppc64 system can check if the fix really works there >> as I have currently no access to such a system. >> >> https://bugs.openjdk.java.net/browse/JDK-8080684 >> http://cr.openjdk.java.net/~simonis/webrevs/2015/8080684/ >> >> Following the details: >> >> On big-endian ppc64 we need so called 'function descriptors' instead >> of simple pointers in order to call functions. That's why the >> Assembler class on ppc64 offers an 'emit_fd()' method which can be >> used to create such a function descriptor. >> >> On little-endian ppc64 the ABI was changed (i.e. ABI_ELFv2) and >> function descriptors have been removed. That's why the before >> mentioned 'emit_fd()' is being excluded from the build with the help >> of preprocessor macros if the HotSpot is being build in a little >> endian environment: >> >> #if !defined(ABI_ELFv2) >> inline address emit_fd(...) >> #endif >> >> The drawback of this approach is that every call site which uses >> 'emit_fd()' has to conditionally handle the case where 'emit_fd()' >> isn't present as well. This was exactly the problem with change >> "8077838: Recent developments for ppc" which introduced an >> unconditional call to 'emit_fd()' in 'VM_Version::config_dscr() which >> lead to a build failure on little endian. >> >> A better approach would be to make 'emit_fd()' available on both, >> little- and big-endian platforms and handle the difference internally, >> within the function itself. On little-endian, the function will just >> return the current PC without emitting any code at all while the >> big-endian variant emits the required function descriptor. >> >> Thank you and best regards, >> Volker From asmundak at google.com Tue Jun 9 02:49:49 2015 From: asmundak at google.com (Alexander Smundak) Date: Mon, 8 Jun 2015 19:49:49 -0700 Subject: RFR(S): 8080684: PPC64: Fix little-endian build after "8077838: Recent developments for ppc" In-Reply-To: References: Message-ID: Looks good to me. Regards, Sasha On Mon, Jun 8, 2015 at 11:31 AM, Volker Simonis wrote: > Hi Sasha, > > you're right - my fix was too complicated. I should have just used > function_entry() instead of emit_fd() because function_entry() already > wraps either emit_fd() or pc() depending on the platform. That's > exactly what I've done in the new patch: > > http://cr.openjdk.java.net/~simonis/webrevs/2015/8080684.v2/ > > As a bonus I've also fixed the Power 8 detection which was broken > because we issued an illegal 'lqarx' instruction to determine if we're > on Power 8. > > Regards, > Volker > > PS: I was actually able to test this change on a REAL ppc64le machine > this time :) > > > > On Wed, May 20, 2015 at 3:25 AM, Alexander Smundak wrote: >> It fails to compile because the code still references FileDescriptor, >> even if ABI_ELFv2 is defined. >> The revised patch which succeeds is here: >> http://cr.openjdk.java.net/~asmundak/8080684/hotspot/webrev >> (it's for jdk8u-dev branch) >> but IMHO the proposed change isn't semantically right -- >> if a method is called emit_fd, it should create a FileDescriptor. >> I am not sure that rationale behind this patch is right -- a >> compile-time error is usually easy to fix and verify that the semantics >> is correct while fixing it, whereas runtime error usually requires >> more effort. >> >> >> On Tue, May 19, 2015 at 9:41 AM, Volker Simonis >> wrote: >>> Hi, >>> >>> can I please get a review for the following fix of the ppc64le build. >>> >>> @Sasha, Tiago: I would be also especially interested if somebody with >>> a little-endian ppc64 system can check if the fix really works there >>> as I have currently no access to such a system. >>> >>> https://bugs.openjdk.java.net/browse/JDK-8080684 >>> http://cr.openjdk.java.net/~simonis/webrevs/2015/8080684/ >>> >>> Following the details: >>> >>> On big-endian ppc64 we need so called 'function descriptors' instead >>> of simple pointers in order to call functions. That's why the >>> Assembler class on ppc64 offers an 'emit_fd()' method which can be >>> used to create such a function descriptor. >>> >>> On little-endian ppc64 the ABI was changed (i.e. ABI_ELFv2) and >>> function descriptors have been removed. That's why the before >>> mentioned 'emit_fd()' is being excluded from the build with the help >>> of preprocessor macros if the HotSpot is being build in a little >>> endian environment: >>> >>> #if !defined(ABI_ELFv2) >>> inline address emit_fd(...) >>> #endif >>> >>> The drawback of this approach is that every call site which uses >>> 'emit_fd()' has to conditionally handle the case where 'emit_fd()' >>> isn't present as well. This was exactly the problem with change >>> "8077838: Recent developments for ppc" which introduced an >>> unconditional call to 'emit_fd()' in 'VM_Version::config_dscr() which >>> lead to a build failure on little endian. >>> >>> A better approach would be to make 'emit_fd()' available on both, >>> little- and big-endian platforms and handle the difference internally, >>> within the function itself. On little-endian, the function will just >>> return the current PC without emitting any code at all while the >>> big-endian variant emits the required function descriptor. >>> >>> Thank you and best regards, >>> Volker From goetz.lindenmaier at sap.com Tue Jun 9 06:21:01 2015 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Tue, 9 Jun 2015 06:21:01 +0000 Subject: RFR(S): 8080684: PPC64: Fix little-endian build after "8077838: Recent developments for ppc" In-Reply-To: References: Message-ID: <4295855A5C1DE049A61835A1887419CC2CFE508C@DEWDFEMB12A.global.corp.sap> HI Volker, the change looks good. Thanks for fixing this! Best regards, Goetz. -----Original Message----- From: hotspot-dev [mailto:hotspot-dev-bounces at openjdk.java.net] On Behalf Of Volker Simonis Sent: Montag, 8. Juni 2015 20:32 To: Alexander Smundak Cc: ppc-aix-port-dev at openjdk.java.net; HotSpot Open Source Developers; Tiago St?rmer Daitx Subject: Re: RFR(S): 8080684: PPC64: Fix little-endian build after "8077838: Recent developments for ppc" Hi Sasha, you're right - my fix was too complicated. I should have just used function_entry() instead of emit_fd() because function_entry() already wraps either emit_fd() or pc() depending on the platform. That's exactly what I've done in the new patch: http://cr.openjdk.java.net/~simonis/webrevs/2015/8080684.v2/ As a bonus I've also fixed the Power 8 detection which was broken because we issued an illegal 'lqarx' instruction to determine if we're on Power 8. Regards, Volker PS: I was actually able to test this change on a REAL ppc64le machine this time :) On Wed, May 20, 2015 at 3:25 AM, Alexander Smundak wrote: > It fails to compile because the code still references FileDescriptor, > even if ABI_ELFv2 is defined. > The revised patch which succeeds is here: > http://cr.openjdk.java.net/~asmundak/8080684/hotspot/webrev > (it's for jdk8u-dev branch) > but IMHO the proposed change isn't semantically right -- > if a method is called emit_fd, it should create a FileDescriptor. > I am not sure that rationale behind this patch is right -- a > compile-time error is usually easy to fix and verify that the semantics > is correct while fixing it, whereas runtime error usually requires > more effort. > > > On Tue, May 19, 2015 at 9:41 AM, Volker Simonis > wrote: >> Hi, >> >> can I please get a review for the following fix of the ppc64le build. >> >> @Sasha, Tiago: I would be also especially interested if somebody with >> a little-endian ppc64 system can check if the fix really works there >> as I have currently no access to such a system. >> >> https://bugs.openjdk.java.net/browse/JDK-8080684 >> http://cr.openjdk.java.net/~simonis/webrevs/2015/8080684/ >> >> Following the details: >> >> On big-endian ppc64 we need so called 'function descriptors' instead >> of simple pointers in order to call functions. That's why the >> Assembler class on ppc64 offers an 'emit_fd()' method which can be >> used to create such a function descriptor. >> >> On little-endian ppc64 the ABI was changed (i.e. ABI_ELFv2) and >> function descriptors have been removed. That's why the before >> mentioned 'emit_fd()' is being excluded from the build with the help >> of preprocessor macros if the HotSpot is being build in a little >> endian environment: >> >> #if !defined(ABI_ELFv2) >> inline address emit_fd(...) >> #endif >> >> The drawback of this approach is that every call site which uses >> 'emit_fd()' has to conditionally handle the case where 'emit_fd()' >> isn't present as well. This was exactly the problem with change >> "8077838: Recent developments for ppc" which introduced an >> unconditional call to 'emit_fd()' in 'VM_Version::config_dscr() which >> lead to a build failure on little endian. >> >> A better approach would be to make 'emit_fd()' available on both, >> little- and big-endian platforms and handle the difference internally, >> within the function itself. On little-endian, the function will just >> return the current PC without emitting any code at all while the >> big-endian variant emits the required function descriptor. >> >> Thank you and best regards, >> Volker From david.holmes at oracle.com Fri Jun 12 03:53:51 2015 From: david.holmes at oracle.com (David Holmes) Date: Fri, 12 Jun 2015 13:53:51 +1000 Subject: RFR [S]: 8079473: allow demangling to be optional in dll_address_to_function_name In-Reply-To: <55671D8C.2080208@oracle.com> References: <55671D8C.2080208@oracle.com> Message-ID: <557A57CF.1010107@oracle.com> Hi Bertrand, This all looks okay to me. Thanks for the detailed description. Thanks, David On 28/05/2015 11:52 PM, Bertrand Delsart wrote: > Hi all, > > Here is a webrev that add a 'demangle' argument to > dll_address_to_function_name so as to make the demangling optional. The > webrev also includes some limited cleanup and fixes an issue I noticed > on windows. > > https://bugs.openjdk.java.net/browse/JDK-8079473 > http://cr.openjdk.java.net/~bdelsart/8079473/ > > Fix is targeted at JDK9 and will be pushed through hs-rt. > > This enhancement is currently used only by some closed extensions. It > has been validated on linux and the fix is very similar on all platforms > except AIX. > > I've quickly implemented the AIX version but could not test it. Let me > know if you would prefer me to remove the AIX code and just ensure that > the 'demangle' argument is ignored on that platform. > > The cleanup is about optional arguments to decode, which were redefined > in the overridden versions for the different operating systems. To avoid > weird behaviors, the default values should be defined only in the > toplevel class AbstractDecoder, not the subclasses (but that was OK as > long as the default values were identical) > > On Windows, I discovered a bug while adding the non-demangling support. > This old code from WindowsDecoder::decode should not behave as expected > if really used: > if (demangle(pSymbol->Name, buf, buflen)) { > jio_snprintf(buf, buflen, "%s", pSymbol->Name); > } > The code is supposed to write in 'buf' the raw form when the demangling > fails. Hence, the jio_snprintf should be executed when demangle returns > false. The code above fails to properly set buf when the demangling > fails and also replaced the demangled form by the raw form when > demangling succeeded. > > It should have been "if (! demangle(...". With my extension, it now is > "if (!(demangle_name && demangle(...", like on other platforms. > > Best regards, > > Bertrand. From bertrand.delsart at oracle.com Fri Jun 12 06:28:48 2015 From: bertrand.delsart at oracle.com (Bertrand Delsart) Date: Fri, 12 Jun 2015 08:28:48 +0200 Subject: RFR [S]: 8079473: allow demangling to be optional in dll_address_to_function_name In-Reply-To: <557A57CF.1010107@oracle.com> References: <55671D8C.2080208@oracle.com> <557A57CF.1010107@oracle.com> Message-ID: <557A7C20.3060100@oracle.com> Thanks David, Reminder: this webrev includes trivial but untested AIX changes. Second reviewer need not be from the AIX porting team but feedback appreciated. Regards, Bertrand. On 12/06/2015 05:53, David Holmes wrote: > Hi Bertrand, > > This all looks okay to me. Thanks for the detailed description. > > Thanks, > David > > On 28/05/2015 11:52 PM, Bertrand Delsart wrote: >> Hi all, >> >> Here is a webrev that add a 'demangle' argument to >> dll_address_to_function_name so as to make the demangling optional. The >> webrev also includes some limited cleanup and fixes an issue I noticed >> on windows. >> >> https://bugs.openjdk.java.net/browse/JDK-8079473 >> http://cr.openjdk.java.net/~bdelsart/8079473/ >> >> Fix is targeted at JDK9 and will be pushed through hs-rt. >> >> This enhancement is currently used only by some closed extensions. It >> has been validated on linux and the fix is very similar on all platforms >> except AIX. >> >> I've quickly implemented the AIX version but could not test it. Let me >> know if you would prefer me to remove the AIX code and just ensure that >> the 'demangle' argument is ignored on that platform. >> >> The cleanup is about optional arguments to decode, which were redefined >> in the overridden versions for the different operating systems. To avoid >> weird behaviors, the default values should be defined only in the >> toplevel class AbstractDecoder, not the subclasses (but that was OK as >> long as the default values were identical) >> >> On Windows, I discovered a bug while adding the non-demangling support. >> This old code from WindowsDecoder::decode should not behave as expected >> if really used: >> if (demangle(pSymbol->Name, buf, buflen)) { >> jio_snprintf(buf, buflen, "%s", pSymbol->Name); >> } >> The code is supposed to write in 'buf' the raw form when the demangling >> fails. Hence, the jio_snprintf should be executed when demangle returns >> false. The code above fails to properly set buf when the demangling >> fails and also replaced the demangled form by the raw form when >> demangling succeeded. >> >> It should have been "if (! demangle(...". With my extension, it now is >> "if (!(demangle_name && demangle(...", like on other platforms. >> >> Best regards, >> >> Bertrand. -- Bertrand Delsart, Grenoble Engineering Center Oracle, 180 av. de l'Europe, ZIRST de Montbonnot 38330 Montbonnot Saint Martin, FRANCE bertrand.delsart at oracle.com Phone : +33 4 76 18 81 23 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ NOTICE: This email message is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ From volker.simonis at gmail.com Fri Jun 12 09:48:52 2015 From: volker.simonis at gmail.com (Volker Simonis) Date: Fri, 12 Jun 2015 11:48:52 +0200 Subject: RFR [S]: 8079473: allow demangling to be optional in dll_address_to_function_name In-Reply-To: <557A7C20.3060100@oracle.com> References: <55671D8C.2080208@oracle.com> <557A57CF.1010107@oracle.com> <557A7C20.3060100@oracle.com> Message-ID: Hi Bertrand, thanks for caring about the AIX port. The AIX changes look good and work perfectly. Regards, Volker On Fri, Jun 12, 2015 at 8:28 AM, Bertrand Delsart wrote: > Thanks David, > > Reminder: this webrev includes trivial but untested AIX changes. Second > reviewer need not be from the AIX porting team but feedback appreciated. > > Regards, > > Bertrand. > > > On 12/06/2015 05:53, David Holmes wrote: >> >> Hi Bertrand, >> >> This all looks okay to me. Thanks for the detailed description. >> >> Thanks, >> David >> >> On 28/05/2015 11:52 PM, Bertrand Delsart wrote: >>> >>> Hi all, >>> >>> Here is a webrev that add a 'demangle' argument to >>> dll_address_to_function_name so as to make the demangling optional. The >>> webrev also includes some limited cleanup and fixes an issue I noticed >>> on windows. >>> >>> https://bugs.openjdk.java.net/browse/JDK-8079473 >>> http://cr.openjdk.java.net/~bdelsart/8079473/ >>> >>> Fix is targeted at JDK9 and will be pushed through hs-rt. >>> >>> This enhancement is currently used only by some closed extensions. It >>> has been validated on linux and the fix is very similar on all platforms >>> except AIX. >>> >>> I've quickly implemented the AIX version but could not test it. Let me >>> know if you would prefer me to remove the AIX code and just ensure that >>> the 'demangle' argument is ignored on that platform. >>> >>> The cleanup is about optional arguments to decode, which were redefined >>> in the overridden versions for the different operating systems. To avoid >>> weird behaviors, the default values should be defined only in the >>> toplevel class AbstractDecoder, not the subclasses (but that was OK as >>> long as the default values were identical) >>> >>> On Windows, I discovered a bug while adding the non-demangling support. >>> This old code from WindowsDecoder::decode should not behave as expected >>> if really used: >>> if (demangle(pSymbol->Name, buf, buflen)) { >>> jio_snprintf(buf, buflen, "%s", pSymbol->Name); >>> } >>> The code is supposed to write in 'buf' the raw form when the demangling >>> fails. Hence, the jio_snprintf should be executed when demangle returns >>> false. The code above fails to properly set buf when the demangling >>> fails and also replaced the demangled form by the raw form when >>> demangling succeeded. >>> >>> It should have been "if (! demangle(...". With my extension, it now is >>> "if (!(demangle_name && demangle(...", like on other platforms. >>> >>> Best regards, >>> >>> Bertrand. > > > > -- > Bertrand Delsart, Grenoble Engineering Center > Oracle, 180 av. de l'Europe, ZIRST de Montbonnot > 38330 Montbonnot Saint Martin, FRANCE > bertrand.delsart at oracle.com Phone : +33 4 76 18 81 23 > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > NOTICE: This email message is for the sole use of the intended > recipient(s) and may contain confidential and privileged > information. Any unauthorized review, use, disclosure or > distribution is prohibited. If you are not the intended recipient, > please contact the sender by reply email and destroy all copies of > the original message. > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ From bertrand.delsart at oracle.com Fri Jun 12 10:01:21 2015 From: bertrand.delsart at oracle.com (Bertrand Delsart) Date: Fri, 12 Jun 2015 12:01:21 +0200 Subject: RFR [S]: 8079473: allow demangling to be optional in dll_address_to_function_name In-Reply-To: References: <55671D8C.2080208@oracle.com> <557A57CF.1010107@oracle.com> <557A7C20.3060100@oracle.com> Message-ID: <557AADF1.3070300@oracle.com> Thanks Volker, Bertrand. On 12/06/2015 11:48, Volker Simonis wrote: > Hi Bertrand, > > thanks for caring about the AIX port. > The AIX changes look good and work perfectly. > > Regards, > Volker > > > On Fri, Jun 12, 2015 at 8:28 AM, Bertrand Delsart > wrote: >> Thanks David, >> >> Reminder: this webrev includes trivial but untested AIX changes. Second >> reviewer need not be from the AIX porting team but feedback appreciated. >> >> Regards, >> >> Bertrand. >> >> >> On 12/06/2015 05:53, David Holmes wrote: >>> >>> Hi Bertrand, >>> >>> This all looks okay to me. Thanks for the detailed description. >>> >>> Thanks, >>> David >>> >>> On 28/05/2015 11:52 PM, Bertrand Delsart wrote: >>>> >>>> Hi all, >>>> >>>> Here is a webrev that add a 'demangle' argument to >>>> dll_address_to_function_name so as to make the demangling optional. The >>>> webrev also includes some limited cleanup and fixes an issue I noticed >>>> on windows. >>>> >>>> https://bugs.openjdk.java.net/browse/JDK-8079473 >>>> http://cr.openjdk.java.net/~bdelsart/8079473/ >>>> >>>> Fix is targeted at JDK9 and will be pushed through hs-rt. >>>> >>>> This enhancement is currently used only by some closed extensions. It >>>> has been validated on linux and the fix is very similar on all platforms >>>> except AIX. >>>> >>>> I've quickly implemented the AIX version but could not test it. Let me >>>> know if you would prefer me to remove the AIX code and just ensure that >>>> the 'demangle' argument is ignored on that platform. >>>> >>>> The cleanup is about optional arguments to decode, which were redefined >>>> in the overridden versions for the different operating systems. To avoid >>>> weird behaviors, the default values should be defined only in the >>>> toplevel class AbstractDecoder, not the subclasses (but that was OK as >>>> long as the default values were identical) >>>> >>>> On Windows, I discovered a bug while adding the non-demangling support. >>>> This old code from WindowsDecoder::decode should not behave as expected >>>> if really used: >>>> if (demangle(pSymbol->Name, buf, buflen)) { >>>> jio_snprintf(buf, buflen, "%s", pSymbol->Name); >>>> } >>>> The code is supposed to write in 'buf' the raw form when the demangling >>>> fails. Hence, the jio_snprintf should be executed when demangle returns >>>> false. The code above fails to properly set buf when the demangling >>>> fails and also replaced the demangled form by the raw form when >>>> demangling succeeded. >>>> >>>> It should have been "if (! demangle(...". With my extension, it now is >>>> "if (!(demangle_name && demangle(...", like on other platforms. >>>> >>>> Best regards, >>>> >>>> Bertrand. >> >> >> >> -- >> Bertrand Delsart, Grenoble Engineering Center >> Oracle, 180 av. de l'Europe, ZIRST de Montbonnot >> 38330 Montbonnot Saint Martin, FRANCE >> bertrand.delsart at oracle.com Phone : +33 4 76 18 81 23 >> >> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >> NOTICE: This email message is for the sole use of the intended >> recipient(s) and may contain confidential and privileged >> information. Any unauthorized review, use, disclosure or >> distribution is prohibited. If you are not the intended recipient, >> please contact the sender by reply email and destroy all copies of >> the original message. >> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -- Bertrand Delsart, Grenoble Engineering Center Oracle, 180 av. de l'Europe, ZIRST de Montbonnot 38330 Montbonnot Saint Martin, FRANCE bertrand.delsart at oracle.com Phone : +33 4 76 18 81 23 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ NOTICE: This email message is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ From coleen.phillimore at oracle.com Tue Jun 23 21:12:01 2015 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Tue, 23 Jun 2015 17:12:01 -0400 Subject: RFR (xs) 8129607: Incorrect GPL header In-Reply-To: <5589CA9D.1050202@oracle.com> References: <5589C96F.3090303@oracle.com> <5589CA9D.1050202@oracle.com> Message-ID: <5589CBA1.8040404@oracle.com> Also CC ppc-aix-port-dev as suggested by Vladimir. On 6/23/15 5:07 PM, Coleen Phillimore wrote: > Also, I need to make a backport request to 8u60 for this change. > Thanks, > Coleen > > On 6/23/15 5:02 PM, Coleen Phillimore wrote: >> Please review small fix to GPL header. >> >> open webrev at http://cr.openjdk.java.net/~coleenp/8129607/ >> >> Thanks, >> Coleen > From vladimir.kozlov at oracle.com Tue Jun 23 21:15:08 2015 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 23 Jun 2015 14:15:08 -0700 Subject: RFR (xs) 8129607: Incorrect GPL header In-Reply-To: <5589CBA1.8040404@oracle.com> References: <5589C96F.3090303@oracle.com> <5589CA9D.1050202@oracle.com> <5589CBA1.8040404@oracle.com> Message-ID: <5589CC5C.5030706@oracle.com> Looks fine. Thanks, Vladimir On 6/23/15 2:12 PM, Coleen Phillimore wrote: > Also CC ppc-aix-port-dev as suggested by Vladimir. > > On 6/23/15 5:07 PM, Coleen Phillimore wrote: >> Also, I need to make a backport request to 8u60 for this change. >> Thanks, >> Coleen >> >> On 6/23/15 5:02 PM, Coleen Phillimore wrote: >>> Please review small fix to GPL header. >>> >>> open webrev at http://cr.openjdk.java.net/~coleenp/8129607/ >>> >>> Thanks, >>> Coleen >> > From coleen.phillimore at oracle.com Tue Jun 23 21:37:44 2015 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Tue, 23 Jun 2015 17:37:44 -0400 Subject: RFR (xs) 8129607: Incorrect GPL header In-Reply-To: <5589CC5C.5030706@oracle.com> References: <5589C96F.3090303@oracle.com> <5589CA9D.1050202@oracle.com> <5589CBA1.8040404@oracle.com> <5589CC5C.5030706@oracle.com> Message-ID: <5589D1A8.6080507@oracle.com> Harold pointed out to me that many of the SAP copyright lines don't have the trailing comma, so I don't know why this file is so special. Waiting to find out. Sorry for the noise. thanks, Coleen On 6/23/15 5:15 PM, Vladimir Kozlov wrote: > Looks fine. > > Thanks, > Vladimir > > On 6/23/15 2:12 PM, Coleen Phillimore wrote: >> Also CC ppc-aix-port-dev as suggested by Vladimir. >> >> On 6/23/15 5:07 PM, Coleen Phillimore wrote: >>> Also, I need to make a backport request to 8u60 for this change. >>> Thanks, >>> Coleen >>> >>> On 6/23/15 5:02 PM, Coleen Phillimore wrote: >>>> Please review small fix to GPL header. >>>> >>>> open webrev at http://cr.openjdk.java.net/~coleenp/8129607/ >>>> >>>> Thanks, >>>> Coleen >>> >> From coleen.phillimore at oracle.com Tue Jun 23 23:23:24 2015 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Tue, 23 Jun 2015 19:23:24 -0400 Subject: RFR (xs) 8129607: Incorrect GPL header (second try) Message-ID: <5589EA6C.6090909@oracle.com> This was apparently the typo that caused the problem. I also need a backport to 8u60 approval because the typo is there also. open webrev at http://cr.openjdk.java.net/~coleenp/8129607/ Thanks, Coleen From vladimir.kozlov at oracle.com Tue Jun 23 23:42:38 2015 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 23 Jun 2015 16:42:38 -0700 Subject: RFR (xs) 8129607: Incorrect GPL header (second try) In-Reply-To: <5589EA6C.6090909@oracle.com> References: <5589EA6C.6090909@oracle.com> Message-ID: <5589EEEE.2040304@oracle.com> Good. Thanks, Vladimir On 6/23/15 4:23 PM, Coleen Phillimore wrote: > This was apparently the typo that caused the problem. I also need a > backport to 8u60 approval because the typo is there also. > > open webrev at http://cr.openjdk.java.net/~coleenp/8129607/ > > Thanks, > Coleen > From david.holmes at oracle.com Wed Jun 24 00:52:26 2015 From: david.holmes at oracle.com (David Holmes) Date: Wed, 24 Jun 2015 10:52:26 +1000 Subject: RFR (xs) 8129607: Incorrect GPL header (second try) In-Reply-To: <5589EA6C.6090909@oracle.com> References: <5589EA6C.6090909@oracle.com> Message-ID: <5589FF4A.8090802@oracle.com> On 24/06/2015 9:23 AM, Coleen Phillimore wrote: > This was apparently the typo that caused the problem. I also need a > backport to 8u60 approval because the typo is there also. > > open webrev at http://cr.openjdk.java.net/~coleenp/8129607/ Good for 9 and 8u60. Thanks, David > Thanks, > Coleen > From coleen.phillimore at oracle.com Wed Jun 24 00:57:29 2015 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Tue, 23 Jun 2015 20:57:29 -0400 Subject: RFR (xs) 8129607: Incorrect GPL header (second try) In-Reply-To: <5589FF4A.8090802@oracle.com> References: <5589EA6C.6090909@oracle.com> <5589FF4A.8090802@oracle.com> Message-ID: <558A0079.5080406@oracle.com> Thank you David and Vladimir. Coleen On 6/23/15 8:52 PM, David Holmes wrote: > On 24/06/2015 9:23 AM, Coleen Phillimore wrote: >> This was apparently the typo that caused the problem. I also need a >> backport to 8u60 approval because the typo is there also. >> >> open webrev at http://cr.openjdk.java.net/~coleenp/8129607/ > > Good for 9 and 8u60. > > Thanks, > David > >> Thanks, >> Coleen >> From volker.simonis at gmail.com Wed Jun 24 07:15:36 2015 From: volker.simonis at gmail.com (Volker Simonis) Date: Wed, 24 Jun 2015 09:15:36 +0200 Subject: RFR (xs) 8129607: Incorrect GPL header (second try) In-Reply-To: <558A0079.5080406@oracle.com> References: <5589EA6C.6090909@oracle.com> <5589FF4A.8090802@oracle.com> <558A0079.5080406@oracle.com> Message-ID: Hi Coleen, thanks for fixing this (apparently a day-one "bug"). Regards, Volker On Wed, Jun 24, 2015 at 2:57 AM, Coleen Phillimore wrote: > > Thank you David and Vladimir. > Coleen > > > On 6/23/15 8:52 PM, David Holmes wrote: >> >> On 24/06/2015 9:23 AM, Coleen Phillimore wrote: >>> >>> This was apparently the typo that caused the problem. I also need a >>> backport to 8u60 approval because the typo is there also. >>> >>> open webrev at http://cr.openjdk.java.net/~coleenp/8129607/ >> >> >> Good for 9 and 8u60. >> >> Thanks, >> David >> >>> Thanks, >>> Coleen >>> > From volker.simonis at gmail.com Wed Jun 24 07:18:37 2015 From: volker.simonis at gmail.com (Volker Simonis) Date: Wed, 24 Jun 2015 09:18:37 +0200 Subject: RFR (xs) 8129607: Incorrect GPL header In-Reply-To: <5589D1A8.6080507@oracle.com> References: <5589C96F.3090303@oracle.com> <5589CA9D.1050202@oracle.com> <5589CBA1.8040404@oracle.com> <5589CC5C.5030706@oracle.com> <5589D1A8.6080507@oracle.com> Message-ID: On Tue, Jun 23, 2015 at 11:37 PM, Coleen Phillimore wrote: > > Harold pointed out to me that many of the SAP copyright lines don't have the > trailing comma, so I don't know why this file is so special. Waiting to > find out. Sorry for the noise. > Hi Coleen, what "trailing comma" are you referring to and is this still a problem? Regards, Volker > thanks, > Coleen > > > On 6/23/15 5:15 PM, Vladimir Kozlov wrote: >> >> Looks fine. >> >> Thanks, >> Vladimir >> >> On 6/23/15 2:12 PM, Coleen Phillimore wrote: >>> >>> Also CC ppc-aix-port-dev as suggested by Vladimir. >>> >>> On 6/23/15 5:07 PM, Coleen Phillimore wrote: >>>> >>>> Also, I need to make a backport request to 8u60 for this change. >>>> Thanks, >>>> Coleen >>>> >>>> On 6/23/15 5:02 PM, Coleen Phillimore wrote: >>>>> >>>>> Please review small fix to GPL header. >>>>> >>>>> open webrev at http://cr.openjdk.java.net/~coleenp/8129607/ >>>>> >>>>> Thanks, >>>>> Coleen >>>> >>>> >>> >