From claes.redestad at oracle.com Mon Jan 2 16:54:27 2017 From: claes.redestad at oracle.com (Claes Redestad) Date: Mon, 2 Jan 2017 17:54:27 +0100 Subject: RFR: 8172169: Re-examine String field optionality Message-ID: <8add97f8-8765-9ff1-e050-60e0e43bff4c@oracle.com> Hi, hash_offset and coder_offset are set up to be optional, although there is code that doesn't honor this (which would be a bug if the fields actually *were* optional). When the optionality is honored, there's a performance risk, especially on platforms with weak or no branch prediction. Since optional fields makes little sense in a world without hotspot express, I think these should simply be made non-optional. Webrev: http://cr.openjdk.java.net/~redestad/8172169/webrev.01 Bug: https://bugs.openjdk.java.net/browse/JDK-8172169 Testing: JPRT pass. Thanks! /Claes From claes.redestad at oracle.com Mon Jan 2 18:27:43 2017 From: claes.redestad at oracle.com (Claes Redestad) Date: Mon, 2 Jan 2017 19:27:43 +0100 Subject: RFR: 8171855: Move package name transformations during module bootstrap into VM Message-ID: <64772f1f-aac0-773d-a308-e01e355a9018@oracle.com> Hi, during jigsaw bootstrap, package names - represented in external form, "java.lang" - are transformed into VM internal form, "java/lang", before calling into the VM. This, however, can effectively be moved into the VM, which removes the need to generate a lot of short-lived strings during bootstrap and heat up various String.replace-related methods. This has a noticeable impact on startup metrics. Webrev: http://cr.openjdk.java.net/~redestad/8171855/ Bug: https://bugs.openjdk.java.net/browse/JDK-8171855 JPRT -testset hotspot pass, and I've prepared to push this into jdk9/hs if there are no objections. Char-based replace on a UTF-8 source should be correct as long as the from and to chars are ASCII (0x00 through 0x7F). A more general method would be needed to safely deal with char values above 0x7F, so adding some asserts to that effect should be considered. Thanks! /Claes From vladimir.kozlov at oracle.com Mon Jan 2 19:36:58 2017 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 2 Jan 2017 11:36:58 -0800 Subject: RFR: 8172169: Re-examine String field optionality In-Reply-To: <8add97f8-8765-9ff1-e050-60e0e43bff4c@oracle.com> References: <8add97f8-8765-9ff1-e050-60e0e43bff4c@oracle.com> Message-ID: Hi Claes, There should not be performance impact on compiled code since the check is done during compilation. And there could be a negligible effect in Interpreter. I agree that coder field should be not optional since jdk 9. I think it was made optional at the initial development phase of compact stings implementation (8141132) when we had both types of String class. I also remember there were tests (and customers .jar files) which put different implementation of String class on boot class path which failed if we don't check presence of these fields. But with modules in jdk 9 it may not relevant any more. Removing hash field optionality is fine since looking back on 6924259 changes - hash field was never removed from String class: http://hg.openjdk.java.net/jdk9/hs/jdk/rev/2c773daa825d http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/8f972594effc The only concern I have is testing. You need to run as many as possible jdk and Hotspot tests (use RBT). Thanks, Vladimir On 1/2/17 8:54 AM, Claes Redestad wrote: > Hi, > > hash_offset and coder_offset are set up to be optional, although there is > code that doesn't honor this (which would be a bug if the fields actually > *were* optional). When the optionality is honored, there's a performance > risk, especially on platforms with weak or no branch prediction. > > Since optional fields makes little sense in a world without hotspot express, > I think these should simply be made non-optional. > > Webrev: http://cr.openjdk.java.net/~redestad/8172169/webrev.01 > Bug: https://bugs.openjdk.java.net/browse/JDK-8172169 > > Testing: JPRT pass. > > Thanks! > > /Claes From claes.redestad at oracle.com Mon Jan 2 20:53:25 2017 From: claes.redestad at oracle.com (Claes Redestad) Date: Mon, 2 Jan 2017 21:53:25 +0100 Subject: RFR: 8172169: Re-examine String field optionality In-Reply-To: References: <8add97f8-8765-9ff1-e050-60e0e43bff4c@oracle.com> Message-ID: <2d3d34f8-b41c-f7ab-8d27-6fc05c37e48b@oracle.com> Hi, On 2017-01-02 20:36, Vladimir Kozlov wrote: > Hi Claes, > > There should not be performance impact on compiled code since the check > is done during compilation. > And there could be a negligible effect in Interpreter. the changes to opto will have negligible or no effect, yes, but there are also code paths taken by GC and other code which call java_lang_String::is_latin1 where the coder_offset check won't be removed. I don't expect to see any remarkable improvements, however. > > I agree that coder field should be not optional since jdk 9. I think it > was made optional at the initial development phase of compact stings > implementation (8141132) when we had both types of String class. > > I also remember there were tests (and customers .jar files) which put > different implementation of String class on boot class path which failed > if we don't check presence of these fields. But with modules in jdk 9 it > may not relevant any more. Replacing String will most likely have to be done differently in 9. > > Removing hash field optionality is fine since looking back on 6924259 > changes - hash field was never removed from String class: > > http://hg.openjdk.java.net/jdk9/hs/jdk/rev/2c773daa825d > > http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/8f972594effc Agree, this is what we concluded as well looking at the history here. > > The only concern I have is testing. You need to run as many as possible > jdk and Hotspot tests (use RBT). I've submitted a larger body of tests through RBT to try and see if there are any tests I've missed. Thanks! /Claes > > Thanks, > Vladimir > > On 1/2/17 8:54 AM, Claes Redestad wrote: >> Hi, >> >> hash_offset and coder_offset are set up to be optional, although there is >> code that doesn't honor this (which would be a bug if the fields actually >> *were* optional). When the optionality is honored, there's a performance >> risk, especially on platforms with weak or no branch prediction. >> >> Since optional fields makes little sense in a world without hotspot >> express, >> I think these should simply be made non-optional. >> >> Webrev: http://cr.openjdk.java.net/~redestad/8172169/webrev.01 >> Bug: https://bugs.openjdk.java.net/browse/JDK-8172169 >> >> Testing: JPRT pass. >> >> Thanks! >> >> /Claes From forax at univ-mlv.fr Mon Jan 2 23:06:11 2017 From: forax at univ-mlv.fr (Remi Forax) Date: Tue, 3 Jan 2017 00:06:11 +0100 (CET) Subject: RFR: 8171855: Move package name transformations during module bootstrap into VM In-Reply-To: <64772f1f-aac0-773d-a308-e01e355a9018@oracle.com> References: <64772f1f-aac0-773d-a308-e01e355a9018@oracle.com> Message-ID: <2117448444.239722.1483398371232.JavaMail.zimbra@u-pem.fr> Hi Claes, the whole replace dance should not be needed anymore with the latest revision of the spec, module names are not stored in internal form anymore. see http://cr.openjdk.java.net/~mr/jigsaw/spec/lang-vm.html#jigsaw-2.1 R?mi ----- Mail original ----- > De: "Claes Redestad" > ?: "jigsaw-dev" , hotspot-runtime-dev at openjdk.java.net > Envoy?: Lundi 2 Janvier 2017 19:27:43 > Objet: RFR: 8171855: Move package name transformations during module bootstrap into VM > Hi, > > during jigsaw bootstrap, package names - represented in external form, > "java.lang" - are transformed into VM internal form, "java/lang", > before calling into the VM. > > This, however, can effectively be moved into the VM, which removes the > need to generate a lot of short-lived strings during bootstrap and heat > up various String.replace-related methods. This has a noticeable impact > on startup metrics. > > Webrev: http://cr.openjdk.java.net/~redestad/8171855/ > Bug: https://bugs.openjdk.java.net/browse/JDK-8171855 > > JPRT -testset hotspot pass, and I've prepared to push this into jdk9/hs > if there are no objections. > > Char-based replace on a UTF-8 source should be correct as long as the > from and to chars are ASCII (0x00 through 0x7F). A more general method > would be needed to safely deal with char values above 0x7F, so adding > some asserts to that effect should be considered. > > Thanks! > > /Claes From claes.redestad at oracle.com Mon Jan 2 23:21:48 2017 From: claes.redestad at oracle.com (Claes Redestad) Date: Tue, 3 Jan 2017 00:21:48 +0100 Subject: RFR: 8171855: Move package name transformations during module bootstrap into VM In-Reply-To: <2117448444.239722.1483398371232.JavaMail.zimbra@u-pem.fr> References: <64772f1f-aac0-773d-a308-e01e355a9018@oracle.com> <2117448444.239722.1483398371232.JavaMail.zimbra@u-pem.fr> Message-ID: <8adc6248-acb7-26b6-5bda-32df8c75dab6@oracle.com> Hi R?mi, are you confusing package names with module names? From the linked specification: "Package names referenced from the Module attribute are stored in CONSTANT_Package_info entries in the constant pool. Such entries wrap CONSTANT_Utf8_info entries which represent package names encoded in internal form." This still appears necessary since loading the module establishes the symbol entries representing the referenced packages. Thanks! /Claes On 2017-01-03 00:06, Remi Forax wrote: > Hi Claes, > the whole replace dance should not be needed anymore with the latest revision of the spec, > module names are not stored in internal form anymore. > > see http://cr.openjdk.java.net/~mr/jigsaw/spec/lang-vm.html#jigsaw-2.1 > > R?mi > > ----- Mail original ----- >> De: "Claes Redestad" >> ?: "jigsaw-dev" , hotspot-runtime-dev at openjdk.java.net >> Envoy?: Lundi 2 Janvier 2017 19:27:43 >> Objet: RFR: 8171855: Move package name transformations during module bootstrap into VM > >> Hi, >> >> during jigsaw bootstrap, package names - represented in external form, >> "java.lang" - are transformed into VM internal form, "java/lang", >> before calling into the VM. >> >> This, however, can effectively be moved into the VM, which removes the >> need to generate a lot of short-lived strings during bootstrap and heat >> up various String.replace-related methods. This has a noticeable impact >> on startup metrics. >> >> Webrev: http://cr.openjdk.java.net/~redestad/8171855/ >> Bug: https://bugs.openjdk.java.net/browse/JDK-8171855 >> >> JPRT -testset hotspot pass, and I've prepared to push this into jdk9/hs >> if there are no objections. >> >> Char-based replace on a UTF-8 source should be correct as long as the >> from and to chars are ASCII (0x00 through 0x7F). A more general method >> would be needed to safely deal with char values above 0x7F, so adding >> some asserts to that effect should be considered. >> >> Thanks! >> >> /Claes From forax at univ-mlv.fr Mon Jan 2 23:30:21 2017 From: forax at univ-mlv.fr (forax at univ-mlv.fr) Date: Tue, 3 Jan 2017 00:30:21 +0100 (CET) Subject: RFR: 8171855: Move package name transformations during module bootstrap into VM In-Reply-To: <8adc6248-acb7-26b6-5bda-32df8c75dab6@oracle.com> References: <64772f1f-aac0-773d-a308-e01e355a9018@oracle.com> <2117448444.239722.1483398371232.JavaMail.zimbra@u-pem.fr> <8adc6248-acb7-26b6-5bda-32df8c75dab6@oracle.com> Message-ID: <240946354.240673.1483399821466.JavaMail.zimbra@u-pem.fr> Ok, I was sure to have seen java.base and not java.lang, past midnight here, time to crawle back to my bedroom :) R?mi ----- Mail original ----- > De: "Claes Redestad" > ?: "Remi Forax" > Cc: "jigsaw-dev" , hotspot-runtime-dev at openjdk.java.net > Envoy?: Mardi 3 Janvier 2017 00:21:48 > Objet: Re: RFR: 8171855: Move package name transformations during module bootstrap into VM > Hi R?mi, > > are you confusing package names with module names? > > From the linked specification: > > "Package names referenced from the Module attribute are stored in > CONSTANT_Package_info entries in the constant pool. Such entries wrap > CONSTANT_Utf8_info entries which represent package names encoded in > internal form." > > This still appears necessary since loading the module establishes the > symbol entries representing the referenced packages. > > Thanks! > > /Claes > > On 2017-01-03 00:06, Remi Forax wrote: >> Hi Claes, >> the whole replace dance should not be needed anymore with the latest revision of >> the spec, >> module names are not stored in internal form anymore. >> >> see http://cr.openjdk.java.net/~mr/jigsaw/spec/lang-vm.html#jigsaw-2.1 >> >> R?mi >> >> ----- Mail original ----- >>> De: "Claes Redestad" >>> ?: "jigsaw-dev" , >>> hotspot-runtime-dev at openjdk.java.net >>> Envoy?: Lundi 2 Janvier 2017 19:27:43 >>> Objet: RFR: 8171855: Move package name transformations during module bootstrap >>> into VM >> >>> Hi, >>> >>> during jigsaw bootstrap, package names - represented in external form, >>> "java.lang" - are transformed into VM internal form, "java/lang", >>> before calling into the VM. >>> >>> This, however, can effectively be moved into the VM, which removes the >>> need to generate a lot of short-lived strings during bootstrap and heat >>> up various String.replace-related methods. This has a noticeable impact >>> on startup metrics. >>> >>> Webrev: http://cr.openjdk.java.net/~redestad/8171855/ >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8171855 >>> >>> JPRT -testset hotspot pass, and I've prepared to push this into jdk9/hs >>> if there are no objections. >>> >>> Char-based replace on a UTF-8 source should be correct as long as the >>> from and to chars are ASCII (0x00 through 0x7F). A more general method >>> would be needed to safely deal with char values above 0x7F, so adding >>> some asserts to that effect should be considered. >>> >>> Thanks! >>> > >> /Claes From david.holmes at oracle.com Tue Jan 3 00:09:34 2017 From: david.holmes at oracle.com (David Holmes) Date: Tue, 3 Jan 2017 10:09:34 +1000 Subject: RFR(XXS): 8171960: Event-based tracing needs separate flag representation for Method In-Reply-To: <00b431e9-7b1d-4885-8248-23fe504f7966@default> References: <00b431e9-7b1d-4885-8248-23fe504f7966@default> Message-ID: <23bc088d-01e0-bbe2-407a-991ffa3d6bfa@oracle.com> Hi Markus, On 23/12/2016 9:29 PM, Markus Gronlund wrote: > Greetings, > > Kindly asking for reviews for the following fix: > > Bug: https://bugs.openjdk.java.net/browse/JDK-8171960 > > Webrev: http://cr.openjdk.java.net/~mgronlun/8171960/webrev01/ > > Summary: > > In order to fix a closed confidential bug, I would need to separate the > flag representation that is currently being used by the Event-based > tracing framework for Method. > > The separate flag representation will be non-existent by default; it > will only materialize under the conjunction (INCLUDE_TRACE AND > implementation available). > > The existing bit will be removed from the Flags enum with the associated > accessors. This looks good to me. It is nice to the the jfr specific logic no longer evident in the open code. Thanks, David ----- > > > Thank you > > Markus > > > > > > > > > From tobias.hartmann at oracle.com Tue Jan 3 09:38:42 2017 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Tue, 3 Jan 2017 10:38:42 +0100 Subject: RFR: 8172169: Re-examine String field optionality In-Reply-To: <8add97f8-8765-9ff1-e050-60e0e43bff4c@oracle.com> References: <8add97f8-8765-9ff1-e050-60e0e43bff4c@oracle.com> Message-ID: <586B7122.2000804@oracle.com> Hi Claes, On 02.01.2017 17:54, Claes Redestad wrote: > Hi, > > hash_offset and coder_offset are set up to be optional, although there is > code that doesn't honor this (which would be a bug if the fields actually > *were* optional). When the optionality is honored, there's a performance > risk, especially on platforms with weak or no branch prediction. > > Since optional fields makes little sense in a world without hotspot express, > I think these should simply be made non-optional. > > Webrev: http://cr.openjdk.java.net/~redestad/8172169/webrev.01 > Bug: https://bugs.openjdk.java.net/browse/JDK-8172169 This looks good to me! As Vladimir mentioned, we missed to remove this during Compact Strings development. Best regards, Tobias > > Testing: JPRT pass. > > Thanks! > > /Claes From marcus.larsson at oracle.com Tue Jan 3 09:40:30 2017 From: marcus.larsson at oracle.com (Marcus Larsson) Date: Tue, 3 Jan 2017 10:40:30 +0100 Subject: RFR(XS): 8170857: Typo in -Xlog:help output Message-ID: <3f744a35-6da6-d23a-c471-d37540457ce6@oracle.com> Hi, Please review the following trivial fix of a typo in the -Xlog:help output. Issue: https://bugs.openjdk.java.net/browse/JDK-8170857 Webrev: http://cr.openjdk.java.net/~mlarsson/8170857/webrev.00 Thanks, Marcus From claes.redestad at oracle.com Tue Jan 3 09:54:59 2017 From: claes.redestad at oracle.com (Claes Redestad) Date: Tue, 3 Jan 2017 10:54:59 +0100 Subject: RFR: 8172169: Re-examine String field optionality In-Reply-To: <586B7122.2000804@oracle.com> References: <8add97f8-8765-9ff1-e050-60e0e43bff4c@oracle.com> <586B7122.2000804@oracle.com> Message-ID: Hi Tobias, On 2017-01-03 10:38, Tobias Hartmann wrote: > Hi Claes, > > On 02.01.2017 17:54, Claes Redestad wrote: >> Hi, >> >> hash_offset and coder_offset are set up to be optional, although there is >> code that doesn't honor this (which would be a bug if the fields actually >> *were* optional). When the optionality is honored, there's a performance >> risk, especially on platforms with weak or no branch prediction. >> >> Since optional fields makes little sense in a world without hotspot express, >> I think these should simply be made non-optional. >> >> Webrev: http://cr.openjdk.java.net/~redestad/8172169/webrev.01 >> Bug: https://bugs.openjdk.java.net/browse/JDK-8172169 > > This looks good to me! As Vladimir mentioned, we missed to remove this during Compact Strings development. Thanks! I guess I will need a second opinion on the test results and selection, though: there are some new failures which all look like pre-existing or environment issues to me. See link in bug. /Claes > > Best regards, > Tobias > >> >> Testing: JPRT pass. >> >> Thanks! >> >> /Claes From tobias.hartmann at oracle.com Tue Jan 3 10:15:11 2017 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Tue, 3 Jan 2017 11:15:11 +0100 Subject: RFR: 8172169: Re-examine String field optionality In-Reply-To: References: <8add97f8-8765-9ff1-e050-60e0e43bff4c@oracle.com> <586B7122.2000804@oracle.com> Message-ID: <586B79AF.1050908@oracle.com> Hi Claes, On 03.01.2017 10:54, Claes Redestad wrote: > Hi Tobias, > > On 2017-01-03 10:38, Tobias Hartmann wrote: >> Hi Claes, >> >> On 02.01.2017 17:54, Claes Redestad wrote: >>> Hi, >>> >>> hash_offset and coder_offset are set up to be optional, although there is >>> code that doesn't honor this (which would be a bug if the fields actually >>> *were* optional). When the optionality is honored, there's a performance >>> risk, especially on platforms with weak or no branch prediction. >>> >>> Since optional fields makes little sense in a world without hotspot express, >>> I think these should simply be made non-optional. >>> >>> Webrev: http://cr.openjdk.java.net/~redestad/8172169/webrev.01 >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8172169 >> >> This looks good to me! As Vladimir mentioned, we missed to remove this during Compact Strings development. > > Thanks! > > I guess I will need a second opinion on the test results and selection, > though: there are some new failures which all look like pre-existing or > environment issues to me. See link in bug. Yes, I agree that the new failures are unrelated to your change. Best regards, Tobias > > /Claes > >> >> Best regards, >> Tobias >> >>> >>> Testing: JPRT pass. >>> >>> Thanks! >>> >>> /Claes From marcus.larsson at oracle.com Tue Jan 3 10:30:11 2017 From: marcus.larsson at oracle.com (Marcus Larsson) Date: Tue, 3 Jan 2017 11:30:11 +0100 Subject: RFR(S): 8170855: Example for -Xlog:help do not contain one with multiple tags Message-ID: <2ec7a003-7f5d-a59a-012d-8e7b89f4ab75@oracle.com> Hi, Please review the following patch to add more use case examples in the -Xlog:help output. Issue: https://bugs.openjdk.java.net/browse/JDK-8170855 Webrev: http://cr.openjdk.java.net/~mlarsson/8170855/webrev.00 Thanks, Marcus From david.holmes at oracle.com Tue Jan 3 11:03:43 2017 From: david.holmes at oracle.com (David Holmes) Date: Tue, 3 Jan 2017 21:03:43 +1000 Subject: RFR(XS): 8170857: Typo in -Xlog:help output In-Reply-To: <3f744a35-6da6-d23a-c471-d37540457ce6@oracle.com> References: <3f744a35-6da6-d23a-c471-d37540457ce6@oracle.com> Message-ID: Looks good Marcus. Plus push under trivial change rules. Thanks, David On 3/01/2017 7:40 PM, Marcus Larsson wrote: > Hi, > > Please review the following trivial fix of a typo in the -Xlog:help output. > > Issue: > https://bugs.openjdk.java.net/browse/JDK-8170857 > > Webrev: > http://cr.openjdk.java.net/~mlarsson/8170857/webrev.00 > > Thanks, > Marcus > From marcus.larsson at oracle.com Tue Jan 3 11:06:59 2017 From: marcus.larsson at oracle.com (Marcus Larsson) Date: Tue, 3 Jan 2017 12:06:59 +0100 Subject: RFR(XS): 8170857: Typo in -Xlog:help output In-Reply-To: References: <3f744a35-6da6-d23a-c471-d37540457ce6@oracle.com> Message-ID: On 01/03/2017 12:03 PM, David Holmes wrote: > Looks good Marcus. Plus push under trivial change rules. Thank you David. Will do! Marcus > > Thanks, > David > > On 3/01/2017 7:40 PM, Marcus Larsson wrote: >> Hi, >> >> Please review the following trivial fix of a typo in the -Xlog:help >> output. >> >> Issue: >> https://bugs.openjdk.java.net/browse/JDK-8170857 >> >> Webrev: >> http://cr.openjdk.java.net/~mlarsson/8170857/webrev.00 >> >> Thanks, >> Marcus >> From david.holmes at oracle.com Tue Jan 3 11:05:41 2017 From: david.holmes at oracle.com (David Holmes) Date: Tue, 3 Jan 2017 21:05:41 +1000 Subject: RFR(S): 8170855: Example for -Xlog:help do not contain one with multiple tags In-Reply-To: <2ec7a003-7f5d-a59a-012d-8e7b89f4ab75@oracle.com> References: <2ec7a003-7f5d-a59a-012d-8e7b89f4ab75@oracle.com> Message-ID: <7c2a6e50-17f3-dee0-4031-ed5a6d737266@oracle.com> Looks good Marcus! I think this also comes under trivial rules. Thanks, David On 3/01/2017 8:30 PM, Marcus Larsson wrote: > Hi, > > Please review the following patch to add more use case examples in the > -Xlog:help output. > > Issue: > https://bugs.openjdk.java.net/browse/JDK-8170855 > > Webrev: > http://cr.openjdk.java.net/~mlarsson/8170855/webrev.00 > > Thanks, > Marcus > From claes.redestad at oracle.com Tue Jan 3 11:16:25 2017 From: claes.redestad at oracle.com (Claes Redestad) Date: Tue, 3 Jan 2017 12:16:25 +0100 Subject: RFR: 8172169: Re-examine String field optionality In-Reply-To: <586B79AF.1050908@oracle.com> References: <8add97f8-8765-9ff1-e050-60e0e43bff4c@oracle.com> <586B7122.2000804@oracle.com> <586B79AF.1050908@oracle.com> Message-ID: <327860b7-0044-4aa2-7a56-7bd15c1b01fb@oracle.com> On 01/03/2017 11:15 AM, Tobias Hartmann wrote: > Hi Claes, > > On 03.01.2017 10:54, Claes Redestad wrote: >> Hi Tobias, >> >> On 2017-01-03 10:38, Tobias Hartmann wrote: >>> Hi Claes, >>> >>> On 02.01.2017 17:54, Claes Redestad wrote: >>>> Hi, >>>> >>>> hash_offset and coder_offset are set up to be optional, although there is >>>> code that doesn't honor this (which would be a bug if the fields actually >>>> *were* optional). When the optionality is honored, there's a performance >>>> risk, especially on platforms with weak or no branch prediction. >>>> >>>> Since optional fields makes little sense in a world without hotspot express, >>>> I think these should simply be made non-optional. >>>> >>>> Webrev: http://cr.openjdk.java.net/~redestad/8172169/webrev.01 >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8172169 >>> This looks good to me! As Vladimir mentioned, we missed to remove this during Compact Strings development. >> Thanks! >> >> I guess I will need a second opinion on the test results and selection, >> though: there are some new failures which all look like pre-existing or >> environment issues to me. See link in bug. > Yes, I agree that the new failures are unrelated to your change. Great, thanks! /Claes > > Best regards, > Tobias > >> /Claes >> >>> Best regards, >>> Tobias >>> >>>> Testing: JPRT pass. >>>> >>>> Thanks! >>>> >>>> /Claes From marcus.larsson at oracle.com Tue Jan 3 11:19:15 2017 From: marcus.larsson at oracle.com (Marcus Larsson) Date: Tue, 3 Jan 2017 12:19:15 +0100 Subject: RFR(S): 8170855: Example for -Xlog:help do not contain one with multiple tags In-Reply-To: <7c2a6e50-17f3-dee0-4031-ed5a6d737266@oracle.com> References: <2ec7a003-7f5d-a59a-012d-8e7b89f4ab75@oracle.com> <7c2a6e50-17f3-dee0-4031-ed5a6d737266@oracle.com> Message-ID: <14b2166a-8764-fcd2-fcff-ff2aed2cb78c@oracle.com> Great! Thanks again David. Marcus On 01/03/2017 12:05 PM, David Holmes wrote: > Looks good Marcus! I think this also comes under trivial rules. > > Thanks, > David > > On 3/01/2017 8:30 PM, Marcus Larsson wrote: >> Hi, >> >> Please review the following patch to add more use case examples in the >> -Xlog:help output. >> >> Issue: >> https://bugs.openjdk.java.net/browse/JDK-8170855 >> >> Webrev: >> http://cr.openjdk.java.net/~mlarsson/8170855/webrev.00 >> >> Thanks, >> Marcus >> From lois.foltan at oracle.com Tue Jan 3 15:56:43 2017 From: lois.foltan at oracle.com (Lois Foltan) Date: Tue, 03 Jan 2017 10:56:43 -0500 Subject: RFR: 8171855: Move package name transformations during module bootstrap into VM In-Reply-To: <64772f1f-aac0-773d-a308-e01e355a9018@oracle.com> References: <64772f1f-aac0-773d-a308-e01e355a9018@oracle.com> Message-ID: <586BC9BB.6020206@oracle.com> On 1/2/2017 1:27 PM, Claes Redestad wrote: > Hi, > > during jigsaw bootstrap, package names - represented in external form, > "java.lang" - are transformed into VM internal form, "java/lang", > before calling into the VM. > > This, however, can effectively be moved into the VM, which removes the > need to generate a lot of short-lived strings during bootstrap and heat > up various String.replace-related methods. This has a noticeable impact > on startup metrics. > > Webrev: http://cr.openjdk.java.net/~redestad/8171855/ > Bug: https://bugs.openjdk.java.net/browse/JDK-8171855 > > JPRT -testset hotspot pass, and I've prepared to push this into jdk9/hs > if there are no objections. > > Char-based replace on a UTF-8 source should be correct as long as the > from and to chars are ASCII (0x00 through 0x7F). A more general method > would be needed to safely deal with char values above 0x7F, so adding > some asserts to that effect should be considered. Hi Claes, I have some concerns about this change in that it will break the precedence that currently the only internal form of names that the VM deals with are binary names as they appear in class files, where the periods (.) have been replaced by forward slashes (/). I think I would like to discuss this with the runtime team before you proceed. As far as the actual changes go, if we do proceed with this, there are places in modules.cpp that have been missed. After line #535, #665, #749 (the replace should be moved before the verify of the package name occurs), #820. Thanks, Lois > > Thanks! > > /Claes > From claes.redestad at oracle.com Tue Jan 3 16:44:29 2017 From: claes.redestad at oracle.com (Claes Redestad) Date: Tue, 3 Jan 2017 17:44:29 +0100 Subject: RFR: 8171855: Move package name transformations during module bootstrap into VM In-Reply-To: <586BC9BB.6020206@oracle.com> References: <64772f1f-aac0-773d-a308-e01e355a9018@oracle.com> <586BC9BB.6020206@oracle.com> Message-ID: <007e88ab-fe13-58a5-3b5a-d4b8c10e8ada@oracle.com> On 01/03/2017 04:56 PM, Lois Foltan wrote: > > Hi Claes, > > I have some concerns about this change in that it will break the > precedence that currently the only internal form of names that the VM > deals with are binary names as they appear in class files, where the > periods (.) have been replaced by forward slashes (/). I think I would > like to discuss this with the runtime team before you proceed. Hi Lois, I have anticipated some controversy on this one. :-) > > As far as the actual changes go, if we do proceed with this, there are > places in modules.cpp that have been missed. After line #535, #665, > #749 (the replace should be moved before the verify of the package > name occurs), #820. Well spotted. I've updated all places: Hotspot: http://cr.openjdk.java.net/~redestad/8171855/hotspot.02 JDK: http://cr.openjdk.java.net/~redestad/8171855/jdk.01 get_module_by_package_name is only used by the whitebox API and it seems the test using this was already using internal form. JVM_GetModuleByPackageName appears to be unused. Could this be cleaned up? Thanks! /Claes > > Thanks, > Lois > >> >> Thanks! >> >> /Claes >> > From Alan.Bateman at oracle.com Tue Jan 3 17:00:14 2017 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 3 Jan 2017 17:00:14 +0000 Subject: RFR: 8171855: Move package name transformations during module bootstrap into VM In-Reply-To: <007e88ab-fe13-58a5-3b5a-d4b8c10e8ada@oracle.com> References: <64772f1f-aac0-773d-a308-e01e355a9018@oracle.com> <586BC9BB.6020206@oracle.com> <007e88ab-fe13-58a5-3b5a-d4b8c10e8ada@oracle.com> Message-ID: On 03/01/2017 16:44, Claes Redestad wrote: > : > > get_module_by_package_name is only used by the whitebox API and it > seems the test using this was already using internal form. > JVM_GetModuleByPackageName appears to be unused. Could this be cleaned > up? This may be a leftover from when we were working out the API changes for JVM TI, specifically what ended up as GetNamedModule to allow the callbacks for CLFH or class load get the Module object for a class that is being loaded. -Alan From karen.kinnear at oracle.com Tue Jan 3 18:08:30 2017 From: karen.kinnear at oracle.com (Karen Kinnear) Date: Tue, 3 Jan 2017 13:08:30 -0500 Subject: RFR: 8171855: Move package name transformations during module bootstrap into VM In-Reply-To: <007e88ab-fe13-58a5-3b5a-d4b8c10e8ada@oracle.com> References: <64772f1f-aac0-773d-a308-e01e355a9018@oracle.com> <586BC9BB.6020206@oracle.com> <007e88ab-fe13-58a5-3b5a-d4b8c10e8ada@oracle.com> Message-ID: <302691E6-CCBF-4820-84A4-2EB6B9EA0841@oracle.com> Claes, Thank you for all the good work you are doing identifying performance issues and making improvements. I strongly agree with Lois? concerns. We looked at other cases in which we have an interface from java to the VM that need to pass fully qualified names, e.g. Class.forName(). The model used there might be useful to you as an alternative way to get the same performance benefits. see Class.c - which uses some existing libjava utilities to do the conversion. So this has the benefit of not creating extra java strings, while keeping the JVM interface consistent. It also reduces the risk of missing locations. We are happy to have further discussions offline if you like. If you think this is a more general issue, and want to revisit JVM APIs, then we can look at that in a future release, in which we will have time to consistently modify the model, and create common utilities. thanks, Karen > On Jan 3, 2017, at 11:44 AM, Claes Redestad wrote: > > > On 01/03/2017 04:56 PM, Lois Foltan wrote: >> >> Hi Claes, >> >> I have some concerns about this change in that it will break the precedence that currently the only internal form of names that the VM deals with are binary names as they appear in class files, where the periods (.) have been replaced by forward slashes (/). I think I would like to discuss this with the runtime team before you proceed. > > Hi Lois, > > I have anticipated some controversy on this one. :-) > >> >> As far as the actual changes go, if we do proceed with this, there are places in modules.cpp that have been missed. After line #535, #665, #749 (the replace should be moved before the verify of the package name occurs), #820. > > Well spotted. I've updated all places: > > Hotspot: http://cr.openjdk.java.net/~redestad/8171855/hotspot.02 > JDK: http://cr.openjdk.java.net/~redestad/8171855/jdk.01 > > get_module_by_package_name is only used by the whitebox API and it seems the test using this was already using internal form. JVM_GetModuleByPackageName appears to be unused. Could this be cleaned up? > > Thanks! > > /Claes > >> >> Thanks, >> Lois >> >>> >>> Thanks! >>> >>> /Claes >>> >> > From claes.redestad at oracle.com Tue Jan 3 20:23:11 2017 From: claes.redestad at oracle.com (Claes Redestad) Date: Tue, 3 Jan 2017 21:23:11 +0100 Subject: RFR: 8171855: Move package name transformations during module bootstrap into VM In-Reply-To: <302691E6-CCBF-4820-84A4-2EB6B9EA0841@oracle.com> References: <64772f1f-aac0-773d-a308-e01e355a9018@oracle.com> <586BC9BB.6020206@oracle.com> <007e88ab-fe13-58a5-3b5a-d4b8c10e8ada@oracle.com> <302691E6-CCBF-4820-84A4-2EB6B9EA0841@oracle.com> Message-ID: On 2017-01-03 19:08, Karen Kinnear wrote: > Claes, > > Thank you for all the good work you are doing identifying performance issues and making improvements. > > I strongly agree with Lois? concerns. > > We looked at other cases in which we have an interface from java to the VM that need to > pass fully qualified names, e.g. Class.forName(). The model used there might be useful > to you as an alternative way to get the same performance benefits. > > see Class.c - which uses some existing libjava utilities to do the conversion. > > So this has the benefit of not creating extra java strings, while keeping the JVM interface consistent. > It also reduces the risk of missing locations. Yes, I had forgotten to consider that we could do this kind of conversion in the JDK native code. This will mean the interface would need to change more than through this patch, though, as we'd want to pass a transformed char* rather than a jstring through. I'll accept the challenge, of course. :-) Thanks! /Claes From coleen.phillimore at oracle.com Wed Jan 4 23:05:53 2017 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Wed, 4 Jan 2017 18:05:53 -0500 Subject: RFR (xs) 8172246: [TESTBUG] runtime/RedefineTests/RedefinePreviousVersions.java 'Class unloading: has_previous_vers,ions = true' missing from stdout/stderr Message-ID: <4c1e41bf-372d-d78e-9bb8-61fc3df2900c@oracle.com> Summary: add boolean to gate redefinition start open webrev at http://cr.openjdk.java.net/~coleenp/8172246/webrev bug link https://bugs.openjdk.java.net/browse/JDK-8172246 Tested multiple times with new better test code. Thanks, Coleen From ioi.lam at oracle.com Wed Jan 4 23:31:31 2017 From: ioi.lam at oracle.com (Ioi Lam) Date: Wed, 04 Jan 2017 15:31:31 -0800 Subject: RFR (xs): unloading archived shared class caused crash Message-ID: <586D85D3.7050503@oracle.com> Hi, Please review this small fix: https://bugs.openjdk.java.net/browse/JDK-8170959 http://cr.openjdk.java.net/~iklam/jdk9/8170959-archived-shared-class-unloading.v01/ Please note that this is a closed bug and it's related to unloading shared classes loaded by custom class loaders. The test case is in the closed repo. The bug happened with the following call stack "assert(!this->is_shared()) failed" in InstanceKlass::release_C_heap_structures () in InstanceKlass::release_C_heap_structures () in ClassLoaderData::classes_do (f=) in ClassLoaderData::~ClassLoaderData () in ClassLoaderDataGraph::purge () in G1CollectedHeap::do_full_collection () The fix is to avoid doing the clean up if the unloaded class is shared. Proper clean up is deferred to JDK 10 (bug JDK-8140287). Thanks - Ioi From ioi.lam at oracle.com Wed Jan 4 23:33:16 2017 From: ioi.lam at oracle.com (Ioi Lam) Date: Wed, 04 Jan 2017 15:33:16 -0800 Subject: RFR (xs): 8170959 unloading archived shared class caused crash In-Reply-To: <586D85D3.7050503@oracle.com> References: <586D85D3.7050503@oracle.com> Message-ID: <586D863C.2020208@oracle.com> Hi, Please review this small fix: https://bugs.openjdk.java.net/browse/JDK-8170959 http://cr.openjdk.java.net/~iklam/jdk9/8170959-archived-shared-class-unloading.v01/ Please note that this is a closed bug and it's related to unloading shared classes loaded by custom class loaders. The test case is in the closed repo. The bug happened with the following call stack "assert(!this->is_shared()) failed" in InstanceKlass::release_C_heap_structures () in InstanceKlass::release_C_heap_structures () in ClassLoaderData::classes_do (f=) in ClassLoaderData::~ClassLoaderData () in ClassLoaderDataGraph::purge () in G1CollectedHeap::do_full_collection () The fix is to avoid doing the clean up if the unloaded class is shared. Proper clean up is deferred to JDK 10 (bug JDK-8140287). Thanks - Ioi From serguei.spitsyn at oracle.com Wed Jan 4 23:35:50 2017 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Wed, 4 Jan 2017 15:35:50 -0800 Subject: RFR (xs) 8172246: [TESTBUG] runtime/RedefineTests/RedefinePreviousVersions.java 'Class unloading: has_previous_vers,ions = true' missing from stdout/stderr In-Reply-To: <4c1e41bf-372d-d78e-9bb8-61fc3df2900c@oracle.com> References: <4c1e41bf-372d-d78e-9bb8-61fc3df2900c@oracle.com> Message-ID: <0facef4c-a5b3-ef21-d280-11452d88100c@oracle.com> Coleen, The fix looks good. Thanks, Serguei On 1/4/17 15:05, Coleen Phillimore wrote: > Summary: add boolean to gate redefinition start > > open webrev at http://cr.openjdk.java.net/~coleenp/8172246/webrev > bug link https://bugs.openjdk.java.net/browse/JDK-8172246 > > Tested multiple times with new better test code. > > Thanks, > Coleen From coleen.phillimore at oracle.com Wed Jan 4 23:44:46 2017 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Wed, 4 Jan 2017 18:44:46 -0500 Subject: RFR (xs) 8172246: [TESTBUG] runtime/RedefineTests/RedefinePreviousVersions.java 'Class unloading: has_previous_vers,ions = true' missing from stdout/stderr In-Reply-To: <0facef4c-a5b3-ef21-d280-11452d88100c@oracle.com> References: <4c1e41bf-372d-d78e-9bb8-61fc3df2900c@oracle.com> <0facef4c-a5b3-ef21-d280-11452d88100c@oracle.com> Message-ID: <1398dae5-079d-f2f0-88d8-286123410651@oracle.com> Thanks, Serguei! Coleen On 1/4/17 6:35 PM, serguei.spitsyn at oracle.com wrote: > Coleen, > > The fix looks good. > > Thanks, > Serguei > > > On 1/4/17 15:05, Coleen Phillimore wrote: >> Summary: add boolean to gate redefinition start >> >> open webrev at http://cr.openjdk.java.net/~coleenp/8172246/webrev >> bug link https://bugs.openjdk.java.net/browse/JDK-8172246 >> >> Tested multiple times with new better test code. >> >> Thanks, >> Coleen > From coleen.phillimore at oracle.com Wed Jan 4 23:54:23 2017 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Wed, 4 Jan 2017 18:54:23 -0500 Subject: RFR (xs): 8170959 unloading archived shared class caused crash In-Reply-To: <586D863C.2020208@oracle.com> References: <586D85D3.7050503@oracle.com> <586D863C.2020208@oracle.com> Message-ID: <33f6cb6f-6e39-8ac5-94a6-179dce98655e@oracle.com> Hi Ioi, It seems like there would be leaks if you don't release some of these C_heap structures. Should the assert just be removed? Except the constant pool release_C_heap_structures unreferences symbols, and that shouldn't be done if the constant pool is shared. thanks, Coleen On 1/4/17 6:33 PM, Ioi Lam wrote: > Hi, > > Please review this small fix: > > https://bugs.openjdk.java.net/browse/JDK-8170959 > http://cr.openjdk.java.net/~iklam/jdk9/8170959-archived-shared-class-unloading.v01/ > > > Please note that this is a closed bug and it's related to unloading > shared classes loaded by custom class loaders. The test case is > in the closed repo. > > The bug happened with the following call stack > > "assert(!this->is_shared()) failed" > in InstanceKlass::release_C_heap_structures () > in InstanceKlass::release_C_heap_structures () > in ClassLoaderData::classes_do > (f=) > in ClassLoaderData::~ClassLoaderData () > in ClassLoaderDataGraph::purge () > in G1CollectedHeap::do_full_collection () > > The fix is to avoid doing the clean up if the unloaded class is shared. > Proper clean up is deferred to JDK 10 (bug JDK-8140287). > > Thanks > - Ioi From david.holmes at oracle.com Thu Jan 5 00:33:49 2017 From: david.holmes at oracle.com (David Holmes) Date: Thu, 5 Jan 2017 10:33:49 +1000 Subject: RFR (xs) 8172246: [TESTBUG] runtime/RedefineTests/RedefinePreviousVersions.java 'Class unloading: has_previous_vers,ions = true' missing from stdout/stderr In-Reply-To: <4c1e41bf-372d-d78e-9bb8-61fc3df2900c@oracle.com> References: <4c1e41bf-372d-d78e-9bb8-61fc3df2900c@oracle.com> Message-ID: Hi Coleen, On 5/01/2017 9:05 AM, Coleen Phillimore wrote: > Summary: add boolean to gate redefinition start > > open webrev at http://cr.openjdk.java.net/~coleenp/8172246/webrev > bug link https://bugs.openjdk.java.net/browse/JDK-8172246 Minor nit. Please change both: Thread.currentThread().sleep(10); to Thread.sleep(10); sleep() always applies to the current thread. Also, as it is a boolean variable style dictates that: while (Running.running != true) { be written as: while (!Running.running) { One related query with this test: are we guaranteed that the loop of System.gc() calls will trigger class unloading? Thanks, David > Tested multiple times with new better test code. > > Thanks, > Coleen From ioi.lam at oracle.com Thu Jan 5 01:09:07 2017 From: ioi.lam at oracle.com (Ioi Lam) Date: Wed, 04 Jan 2017 17:09:07 -0800 Subject: RFR (xs): 8170959 unloading archived shared class caused crash In-Reply-To: <33f6cb6f-6e39-8ac5-94a6-179dce98655e@oracle.com> References: <586D85D3.7050503@oracle.com> <586D863C.2020208@oracle.com> <33f6cb6f-6e39-8ac5-94a6-179dce98655e@oracle.com> Message-ID: <586D9CB3.2040902@oracle.com> Hi Coleen, Thanks for the suggestion. I've removed the assert. I needed to add a check for the _cached_class_file because for shared classes this field is not allocated from the C heap, but rather points into the shared archive. http://cr.openjdk.java.net/~iklam/jdk9/8170959-archived-shared-class-unloading.v02/ Thanks - Ioi On 1/4/17 3:54 PM, Coleen Phillimore wrote: > > Hi Ioi, > > It seems like there would be leaks if you don't release some of these > C_heap structures. Should the assert just be removed? > Except the constant pool release_C_heap_structures unreferences > symbols, and that shouldn't be done if the constant pool is shared. > thanks, > Coleen > > On 1/4/17 6:33 PM, Ioi Lam wrote: >> Hi, >> >> Please review this small fix: >> >> https://bugs.openjdk.java.net/browse/JDK-8170959 >> http://cr.openjdk.java.net/~iklam/jdk9/8170959-archived-shared-class-unloading.v01/ >> >> >> Please note that this is a closed bug and it's related to unloading >> shared classes loaded by custom class loaders. The test case is >> in the closed repo. >> >> The bug happened with the following call stack >> >> "assert(!this->is_shared()) failed" >> in InstanceKlass::release_C_heap_structures () >> in InstanceKlass::release_C_heap_structures () >> in ClassLoaderData::classes_do >> (f=) >> in ClassLoaderData::~ClassLoaderData () >> in ClassLoaderDataGraph::purge () >> in G1CollectedHeap::do_full_collection () >> >> The fix is to avoid doing the clean up if the unloaded class is shared. >> Proper clean up is deferred to JDK 10 (bug JDK-8140287). >> >> Thanks >> - Ioi > From coleen.phillimore at oracle.com Thu Jan 5 01:33:02 2017 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Wed, 4 Jan 2017 20:33:02 -0500 Subject: RFR (xs) 8172246: [TESTBUG] runtime/RedefineTests/RedefinePreviousVersions.java 'Class unloading: has_previous_vers,ions = true' missing from stdout/stderr In-Reply-To: References: <4c1e41bf-372d-d78e-9bb8-61fc3df2900c@oracle.com> Message-ID: <0c174658-d94a-b4c5-1b2a-c6546bc38c17@oracle.com> On 1/4/17 7:33 PM, David Holmes wrote: > Hi Coleen, > > On 5/01/2017 9:05 AM, Coleen Phillimore wrote: >> Summary: add boolean to gate redefinition start >> >> open webrev at http://cr.openjdk.java.net/~coleenp/8172246/webrev >> bug link https://bugs.openjdk.java.net/browse/JDK-8172246 > > Minor nit. Please change both: > > Thread.currentThread().sleep(10); > > to > > Thread.sleep(10); Sure, I'll change it. > > sleep() always applies to the current thread. > > Also, as it is a boolean variable style dictates that: > > while (Running.running != true) { > > be written as: > > while (!Running.running) { > ok. > One related query with this test: are we guaranteed that the loop of > System.gc() calls will trigger class unloading? > No, the test doesn't rely on that. I did the system.gc so that I could see it when running the test but it doesn't need to deallocate the previous versions of the class. And it doesn't deallocate them if the 'infinite' method has been compiled because it hangs out in the code cache for a long time. Thanks! Coleen > Thanks, > David > >> Tested multiple times with new better test code. >> >> Thanks, >> Coleen From coleen.phillimore at oracle.com Thu Jan 5 01:37:01 2017 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Wed, 4 Jan 2017 20:37:01 -0500 Subject: RFR (xs): 8170959 unloading archived shared class caused crash In-Reply-To: <586D9CB3.2040902@oracle.com> References: <586D85D3.7050503@oracle.com> <586D863C.2020208@oracle.com> <33f6cb6f-6e39-8ac5-94a6-179dce98655e@oracle.com> <586D9CB3.2040902@oracle.com> Message-ID: Yes, I think this looks a lot better. Thanks! Coleen On 1/4/17 8:09 PM, Ioi Lam wrote: > Hi Coleen, > > Thanks for the suggestion. I've removed the assert. I needed to add a > check for the _cached_class_file because for shared classes this field > is not allocated from the C heap, but rather points into the shared > archive. > > http://cr.openjdk.java.net/~iklam/jdk9/8170959-archived-shared-class-unloading.v02/ > > > Thanks > - Ioi > > On 1/4/17 3:54 PM, Coleen Phillimore wrote: >> >> Hi Ioi, >> >> It seems like there would be leaks if you don't release some of these >> C_heap structures. Should the assert just be removed? >> Except the constant pool release_C_heap_structures unreferences >> symbols, and that shouldn't be done if the constant pool is shared. >> thanks, >> Coleen >> >> On 1/4/17 6:33 PM, Ioi Lam wrote: >>> Hi, >>> >>> Please review this small fix: >>> >>> https://bugs.openjdk.java.net/browse/JDK-8170959 >>> http://cr.openjdk.java.net/~iklam/jdk9/8170959-archived-shared-class-unloading.v01/ >>> >>> >>> Please note that this is a closed bug and it's related to unloading >>> shared classes loaded by custom class loaders. The test case is >>> in the closed repo. >>> >>> The bug happened with the following call stack >>> >>> "assert(!this->is_shared()) failed" >>> in InstanceKlass::release_C_heap_structures () >>> in InstanceKlass::release_C_heap_structures () >>> in ClassLoaderData::classes_do >>> (f=) >>> in ClassLoaderData::~ClassLoaderData () >>> in ClassLoaderDataGraph::purge () >>> in G1CollectedHeap::do_full_collection () >>> >>> The fix is to avoid doing the clean up if the unloaded class is shared. >>> Proper clean up is deferred to JDK 10 (bug JDK-8140287). >>> >>> Thanks >>> - Ioi >> > From serguei.spitsyn at oracle.com Thu Jan 5 08:55:43 2017 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Thu, 5 Jan 2017 00:55:43 -0800 Subject: RFR (xs): 8170959 unloading archived shared class caused crash In-Reply-To: <586D9CB3.2040902@oracle.com> References: <586D85D3.7050503@oracle.com> <586D863C.2020208@oracle.com> <33f6cb6f-6e39-8ac5-94a6-179dce98655e@oracle.com> <586D9CB3.2040902@oracle.com> Message-ID: Hi Ioi, It looks good. Thanks, Serguei On 1/4/17 17:09, Ioi Lam wrote: > Hi Coleen, > > Thanks for the suggestion. I've removed the assert. I needed to add a > check for the _cached_class_file because for shared classes this field > is not allocated from the C heap, but rather points into the shared > archive. > > http://cr.openjdk.java.net/~iklam/jdk9/8170959-archived-shared-class-unloading.v02/ > > > Thanks > - Ioi > > On 1/4/17 3:54 PM, Coleen Phillimore wrote: >> >> Hi Ioi, >> >> It seems like there would be leaks if you don't release some of these >> C_heap structures. Should the assert just be removed? >> Except the constant pool release_C_heap_structures unreferences >> symbols, and that shouldn't be done if the constant pool is shared. >> thanks, >> Coleen >> >> On 1/4/17 6:33 PM, Ioi Lam wrote: >>> Hi, >>> >>> Please review this small fix: >>> >>> https://bugs.openjdk.java.net/browse/JDK-8170959 >>> http://cr.openjdk.java.net/~iklam/jdk9/8170959-archived-shared-class-unloading.v01/ >>> >>> >>> Please note that this is a closed bug and it's related to unloading >>> shared classes loaded by custom class loaders. The test case is >>> in the closed repo. >>> >>> The bug happened with the following call stack >>> >>> "assert(!this->is_shared()) failed" >>> in InstanceKlass::release_C_heap_structures () >>> in InstanceKlass::release_C_heap_structures () >>> in ClassLoaderData::classes_do >>> (f=) >>> in ClassLoaderData::~ClassLoaderData () >>> in ClassLoaderDataGraph::purge () >>> in G1CollectedHeap::do_full_collection () >>> >>> The fix is to avoid doing the clean up if the unloaded class is shared. >>> Proper clean up is deferred to JDK 10 (bug JDK-8140287). >>> >>> Thanks >>> - Ioi >> > From claes.redestad at oracle.com Thu Jan 5 16:47:20 2017 From: claes.redestad at oracle.com (Claes Redestad) Date: Thu, 5 Jan 2017 17:47:20 +0100 Subject: RFR: 8171855: Move package name transformations during module bootstrap into native code In-Reply-To: <64772f1f-aac0-773d-a308-e01e355a9018@oracle.com> References: <64772f1f-aac0-773d-a308-e01e355a9018@oracle.com> Message-ID: Hi, after a round of review comments I've now reworked this to do the transformations in the JNI layer rather than inside the VM, with similar - if not better - results. Webrevs: http://cr.openjdk.java.net/~redestad/8171855/hotspot.03/ http://cr.openjdk.java.net/~redestad/8171855/jdk.03/ Testing: RBT run in progress, all runtime/modules tests pass locally Thanks! /Claes On 01/02/2017 07:27 PM, Claes Redestad wrote: > Hi, > > during jigsaw bootstrap, package names - represented in external form, > "java.lang" - are transformed into VM internal form, "java/lang", > before calling into the VM. > > This, however, can effectively be moved into the VM, which removes the > need to generate a lot of short-lived strings during bootstrap and heat > up various String.replace-related methods. This has a noticeable impact > on startup metrics. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8171855 > From christian.tornqvist at oracle.com Thu Jan 5 17:41:50 2017 From: christian.tornqvist at oracle.com (Christian Tornqvist) Date: Thu, 5 Jan 2017 12:41:50 -0500 Subject: RFR(XS): 8172188 - JDI tests fail due to "permission denied" when creating temp file Message-ID: <46eb01d2677a$ffb29390$ff17bab0$@oracle.com> Hi everyone, Please review this small change that fixes an issue where the temp file for some of the JDI tests is being written to %SYSTEMROOT%, this is the \Windows folder where normal users are not able to (and shouldn't) write. When running these shell tests as non-admin, they fail with: C:/source/jdk9-hs/jdk/test/com/sun/jdi/ShellScaffold.sh: line 286: C:\WINDOWS/tmp.214820: Permission denied cat: 'C:\WINDOWS/tmp.214820': No such file or directory The correct place for these temp files are in %TEMP% , verified the fix locally on my Windows 10 machine by running the jdk/test/com/sun/jdi tests. Webrev: http://cr.openjdk.java.net/~ctornqvi/webrev/8172188/webrev.00/ Bug: https://bugs.openjdk.java.net/browse/JDK-8172188 Thanks, Christian From harold.seigel at oracle.com Thu Jan 5 17:44:30 2017 From: harold.seigel at oracle.com (harold seigel) Date: Thu, 5 Jan 2017 12:44:30 -0500 Subject: RFR(XS): 8172188 - JDI tests fail due to "permission denied" when creating temp file In-Reply-To: <46eb01d2677a$ffb29390$ff17bab0$@oracle.com> References: <46eb01d2677a$ffb29390$ff17bab0$@oracle.com> Message-ID: Looks good to me. Thanks, Harold On 1/5/2017 12:41 PM, Christian Tornqvist wrote: > Hi everyone, > > > > Please review this small change that fixes an issue where the temp file for > some of the JDI tests is being written to %SYSTEMROOT%, this is the \Windows > folder where normal users are not able to (and shouldn't) write. When > running these shell tests as non-admin, they fail with: > > > > C:/source/jdk9-hs/jdk/test/com/sun/jdi/ShellScaffold.sh: line 286: > C:\WINDOWS/tmp.214820: Permission denied > > cat: 'C:\WINDOWS/tmp.214820': No such file or directory > > > > The correct place for these temp files are in %TEMP% , verified the fix > locally on my Windows 10 machine by running the jdk/test/com/sun/jdi tests. > > > > Webrev: > > http://cr.openjdk.java.net/~ctornqvi/webrev/8172188/webrev.00/ > > > > Bug: > > https://bugs.openjdk.java.net/browse/JDK-8172188 > > > > Thanks, > Christian > From mikhailo.seledtsov at oracle.com Thu Jan 5 17:57:43 2017 From: mikhailo.seledtsov at oracle.com (mikhailo) Date: Thu, 5 Jan 2017 09:57:43 -0800 Subject: RFR(XS): 8172188 - JDI tests fail due to "permission denied" when creating temp file In-Reply-To: <46eb01d2677a$ffb29390$ff17bab0$@oracle.com> References: <46eb01d2677a$ffb29390$ff17bab0$@oracle.com> Message-ID: Change looks good to me. Misha On 01/05/2017 09:41 AM, Christian Tornqvist wrote: > Hi everyone, > > > > Please review this small change that fixes an issue where the temp file for > some of the JDI tests is being written to %SYSTEMROOT%, this is the \Windows > folder where normal users are not able to (and shouldn't) write. When > running these shell tests as non-admin, they fail with: > > > > C:/source/jdk9-hs/jdk/test/com/sun/jdi/ShellScaffold.sh: line 286: > C:\WINDOWS/tmp.214820: Permission denied > > cat: 'C:\WINDOWS/tmp.214820': No such file or directory > > > > The correct place for these temp files are in %TEMP% , verified the fix > locally on my Windows 10 machine by running the jdk/test/com/sun/jdi tests. > > > > Webrev: > > http://cr.openjdk.java.net/~ctornqvi/webrev/8172188/webrev.00/ > > > > Bug: > > https://bugs.openjdk.java.net/browse/JDK-8172188 > > > > Thanks, > Christian > From max.ockner at oracle.com Thu Jan 5 18:27:48 2017 From: max.ockner at oracle.com (Max Ockner) Date: Thu, 05 Jan 2017 13:27:48 -0500 Subject: RFR (xs): 8170959 unloading archived shared class caused crash In-Reply-To: References: <586D85D3.7050503@oracle.com> <586D863C.2020208@oracle.com> <33f6cb6f-6e39-8ac5-94a6-179dce98655e@oracle.com> <586D9CB3.2040902@oracle.com> Message-ID: <586E9024.3090303@oracle.com> Ioi, This looks good to me. Max On 1/4/2017 8:37 PM, Coleen Phillimore wrote: > > Yes, I think this looks a lot better. > Thanks! > Coleen > > On 1/4/17 8:09 PM, Ioi Lam wrote: >> Hi Coleen, >> >> Thanks for the suggestion. I've removed the assert. I needed to add a >> check for the _cached_class_file because for shared classes this >> field is not allocated from the C heap, but rather points into the >> shared archive. >> >> http://cr.openjdk.java.net/~iklam/jdk9/8170959-archived-shared-class-unloading.v02/ >> >> >> Thanks >> - Ioi >> >> On 1/4/17 3:54 PM, Coleen Phillimore wrote: >>> >>> Hi Ioi, >>> >>> It seems like there would be leaks if you don't release some of >>> these C_heap structures. Should the assert just be removed? >>> Except the constant pool release_C_heap_structures unreferences >>> symbols, and that shouldn't be done if the constant pool is shared. >>> thanks, >>> Coleen >>> >>> On 1/4/17 6:33 PM, Ioi Lam wrote: >>>> Hi, >>>> >>>> Please review this small fix: >>>> >>>> https://bugs.openjdk.java.net/browse/JDK-8170959 >>>> http://cr.openjdk.java.net/~iklam/jdk9/8170959-archived-shared-class-unloading.v01/ >>>> >>>> >>>> Please note that this is a closed bug and it's related to unloading >>>> shared classes loaded by custom class loaders. The test case is >>>> in the closed repo. >>>> >>>> The bug happened with the following call stack >>>> >>>> "assert(!this->is_shared()) failed" >>>> in InstanceKlass::release_C_heap_structures () >>>> in InstanceKlass::release_C_heap_structures () >>>> in ClassLoaderData::classes_do >>>> (f=) >>>> in ClassLoaderData::~ClassLoaderData () >>>> in ClassLoaderDataGraph::purge () >>>> in G1CollectedHeap::do_full_collection () >>>> >>>> The fix is to avoid doing the clean up if the unloaded class is >>>> shared. >>>> Proper clean up is deferred to JDK 10 (bug JDK-8140287). >>>> >>>> Thanks >>>> - Ioi >>> >> > From lois.foltan at oracle.com Thu Jan 5 21:19:28 2017 From: lois.foltan at oracle.com (Lois Foltan) Date: Thu, 05 Jan 2017 16:19:28 -0500 Subject: RFR: 8171855: Move package name transformations during module bootstrap into native code In-Reply-To: References: <64772f1f-aac0-773d-a308-e01e355a9018@oracle.com> Message-ID: <586EB860.4020106@oracle.com> On 1/5/2017 11:47 AM, Claes Redestad wrote: > Hi, > > after a round of review comments I've now reworked this to do the > transformations in the JNI layer rather than inside the VM, with > similar - if not better - results. > > Webrevs: > http://cr.openjdk.java.net/~redestad/8171855/hotspot.03/ > http://cr.openjdk.java.net/~redestad/8171855/jdk.03/ > > Testing: RBT run in progress, all runtime/modules tests pass locally Hi Claes, Thank you for reworking this. I think it looks good. A couple of comments in hotspot/src/share/vm/classfile/modules.cpp modules.cpp/Modules::define_module() line #278, I think it is important for the VM to validate the packages and num_packages parameters. An IllegalArgumentException should be thrown if: - num_packages is not >= 0 - if packages == NULL, then num_packages should be equal to 0, this will protect against erroneously entering the for loop at line #292 based solely on num_packages line #291 - Ideally, if num_packages is 0, there is no sense in allocating pkg_list Thanks, Lois > > Thanks! > > /Claes > > On 01/02/2017 07:27 PM, Claes Redestad wrote: >> Hi, >> >> during jigsaw bootstrap, package names - represented in external form, >> "java.lang" - are transformed into VM internal form, "java/lang", >> before calling into the VM. >> >> This, however, can effectively be moved into the VM, which removes the >> need to generate a lot of short-lived strings during bootstrap and heat >> up various String.replace-related methods. This has a noticeable impact >> on startup metrics. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8171855 >> > From mandy.chung at oracle.com Thu Jan 5 21:24:55 2017 From: mandy.chung at oracle.com (Mandy Chung) Date: Thu, 5 Jan 2017 13:24:55 -0800 Subject: RFR: 8171855: Move package name transformations during module bootstrap into native code In-Reply-To: References: <64772f1f-aac0-773d-a308-e01e355a9018@oracle.com> Message-ID: > On Jan 5, 2017, at 8:47 AM, Claes Redestad wrote: > > Hi, > > after a round of review comments I've now reworked this to do the > transformations in the JNI layer rather than inside the VM, with > similar - if not better - results. > > Webrevs: > http://cr.openjdk.java.net/~redestad/8171855/hotspot.03/ > http://cr.openjdk.java.net/~redestad/8171855/jdk.03/ > Happy to know the performance gain is comparable when pushing down the conversion to internal form in native instead of doing it in the VM. This is good work. src/java.base/share/native/libjava/Module.c This can be refactored e.g. adding a new function GetInternalPackageName that takes a jstring and returns const char*. GetStringUTFChars will return a copy of the utf-8 chars. That is an alternative to malloc, GetStringUTFLength, GetStringLength, GetStringUTFRegion calls. Use ReleaseStringUTFChars to free the copy after use. Nit: it may be clearer to rename pkgs_len to num_pkgs src/share/vm/classfile/modules.cpp 49 static bool verify_module_name(const char *module_name) { To be consistent with the convention in this file: const char* Otherwise, looks fine. Mandy From claes.redestad at oracle.com Fri Jan 6 02:36:45 2017 From: claes.redestad at oracle.com (Claes Redestad) Date: Fri, 6 Jan 2017 03:36:45 +0100 Subject: RFR: 8171855: Move package name transformations during module bootstrap into native code In-Reply-To: References: <64772f1f-aac0-773d-a308-e01e355a9018@oracle.com> Message-ID: Lois, Mandy, On 2017-01-05 22:19, Lois Foltan wrote: > > On 1/5/2017 11:47 AM, Claes Redestad wrote: >> Hi, >> >> after a round of review comments I've now reworked this to do the >> transformations in the JNI layer rather than inside the VM, with >> similar - if not better - results. >> >> Webrevs: >> http://cr.openjdk.java.net/~redestad/8171855/hotspot.03/ >> http://cr.openjdk.java.net/~redestad/8171855/jdk.03/ >> >> Testing: RBT run in progress, all runtime/modules tests pass locally > > Hi Claes, > > Thank you for reworking this. I think it looks good. A couple of > comments in hotspot/src/share/vm/classfile/modules.cpp > > modules.cpp/Modules::define_module() > line #278, I think it is important for the VM to validate the packages > and num_packages parameters. > An IllegalArgumentException should be thrown if: > - num_packages is not >= 0 > - if packages == NULL, then num_packages should be equal to 0, > this will protect against erroneously entering the for loop at > line #292 based solely on num_packages Done. > line #291 - Ideally, if num_packages is 0, there is no sense in > allocating pkg_list > > Thanks, > Lois There's plenty of code which assumes pkg_list is always allocated (even when num_packages is 0), so if you don't mind I'd like to defer this cleanup? There's only a handful of modules that doesn't define any packages, so I don't think it'll matter that much for startup. Thinking out loud: I'm more concerned about the fact we're scanning the growing pkg_list for duplicates on every insertion, which is effectively quadratic. It seems we could just as well skip this check and let the error be caught by the dupl_pkg_index checking later on (then scan the packages for duplicates in the error handling code to distinguish error messages). Would mean we could do away with the GrowableArray too.. On 2017-01-05 22:24, Mandy Chung wrote: > > Happy to know the performance gain is comparable when pushing down the conversion to internal form in native instead of doing it in the VM. This is good work. Thanks! > > src/java.base/share/native/libjava/Module.c > This can be refactored e.g. adding a new function GetInternalPackageName that takes a jstring and returns const char*. > > GetStringUTFChars will return a copy of the utf-8 chars. That is an alternative to malloc, GetStringUTFLength, GetStringLength, GetStringUTFRegion calls. Use ReleaseStringUTFChars to free the copy after use. GetStringUTFChars returns a const char*, so wouldn't work as we're mutating. I'll do as you suggest and refactor some common code to a new method GetInternalPackageName to reduce the boiler plate, though. > > Nit: it may be clearer to rename pkgs_len to num_pkgs Done. > > src/share/vm/classfile/modules.cpp > 49 static bool verify_module_name(const char *module_name) { > > To be consistent with the convention in this file: const char* New webrevs: http://cr.openjdk.java.net/~redestad/8171855/hotspot.04/ http://cr.openjdk.java.net/~redestad/8171855/jdk.04/ In addition to fixing comments I couldn't resist applying the technique used in Class.c to get rid of some mallocs in places where we can use a stack allocated char buf[128] instead, which seems to have a tiny, but measurable effect. Thanks! /Claes From ioi.lam at oracle.com Fri Jan 6 03:39:50 2017 From: ioi.lam at oracle.com (Ioi Lam) Date: Thu, 05 Jan 2017 19:39:50 -0800 Subject: RFR (xs): 8170959 unloading archived shared class caused crash In-Reply-To: <586E9024.3090303@oracle.com> References: <586D85D3.7050503@oracle.com> <586D863C.2020208@oracle.com> <33f6cb6f-6e39-8ac5-94a6-179dce98655e@oracle.com> <586D9CB3.2040902@oracle.com> <586E9024.3090303@oracle.com> Message-ID: <586F1186.50801@oracle.com> Coleen, Serguei & Max, Thanks for the reviews. I will push. - Ioi On 1/5/17 10:27 AM, Max Ockner wrote: > Ioi, > This looks good to me. > Max > > On 1/4/2017 8:37 PM, Coleen Phillimore wrote: >> >> Yes, I think this looks a lot better. >> Thanks! >> Coleen >> >> On 1/4/17 8:09 PM, Ioi Lam wrote: >>> Hi Coleen, >>> >>> Thanks for the suggestion. I've removed the assert. I needed to add >>> a check for the _cached_class_file because for shared classes this >>> field is not allocated from the C heap, but rather points into the >>> shared archive. >>> >>> http://cr.openjdk.java.net/~iklam/jdk9/8170959-archived-shared-class-unloading.v02/ >>> >>> >>> Thanks >>> - Ioi >>> >>> On 1/4/17 3:54 PM, Coleen Phillimore wrote: >>>> >>>> Hi Ioi, >>>> >>>> It seems like there would be leaks if you don't release some of >>>> these C_heap structures. Should the assert just be removed? >>>> Except the constant pool release_C_heap_structures unreferences >>>> symbols, and that shouldn't be done if the constant pool is shared. >>>> thanks, >>>> Coleen >>>> >>>> On 1/4/17 6:33 PM, Ioi Lam wrote: >>>>> Hi, >>>>> >>>>> Please review this small fix: >>>>> >>>>> https://bugs.openjdk.java.net/browse/JDK-8170959 >>>>> http://cr.openjdk.java.net/~iklam/jdk9/8170959-archived-shared-class-unloading.v01/ >>>>> >>>>> >>>>> Please note that this is a closed bug and it's related to unloading >>>>> shared classes loaded by custom class loaders. The test case is >>>>> in the closed repo. >>>>> >>>>> The bug happened with the following call stack >>>>> >>>>> "assert(!this->is_shared()) failed" >>>>> in InstanceKlass::release_C_heap_structures () >>>>> in InstanceKlass::release_C_heap_structures () >>>>> in ClassLoaderData::classes_do >>>>> (f=) >>>>> in ClassLoaderData::~ClassLoaderData () >>>>> in ClassLoaderDataGraph::purge () >>>>> in G1CollectedHeap::do_full_collection () >>>>> >>>>> The fix is to avoid doing the clean up if the unloaded class is >>>>> shared. >>>>> Proper clean up is deferred to JDK 10 (bug JDK-8140287). >>>>> >>>>> Thanks >>>>> - Ioi >>>> >>> >> > From peter.levart at gmail.com Fri Jan 6 08:46:16 2017 From: peter.levart at gmail.com (Peter Levart) Date: Fri, 6 Jan 2017 09:46:16 +0100 Subject: RFR: 8171855: Move package name transformations during module bootstrap into native code In-Reply-To: References: <64772f1f-aac0-773d-a308-e01e355a9018@oracle.com> Message-ID: Hi Claes, On 01/06/2017 03:36 AM, Claes Redestad wrote: > > New webrevs: > http://cr.openjdk.java.net/~redestad/8171855/hotspot.04/ > http://cr.openjdk.java.net/~redestad/8171855/jdk.04/ In Module.c, it seems you applied the "techinique" of conditional allocation (lines 49...57), but forgot to remove the old code (58...62): 49 if (len >= buf_size) { 50 utf_str = malloc(len + 1); 51 if (utf_str == NULL) { 52 JNU_ThrowOutOfMemoryError(env, NULL); 53 return NULL; 54 } 55 } else { 56 utf_str = buf; 57 } 58 utf_str = malloc(len + 1); 59 if (utf_str == NULL) { 60 JNU_ThrowOutOfMemoryError(env, NULL); 61 return NULL; 62 } Also, in line 84, you allocate pkgs array only when num_packages != 0: 84 if (num_packages != 0 && (pkgs = calloc(num_packages, sizeof(char*))) == NULL) { ...but you free it unconditionally (does free(NULL) work as no-op?): 110 free(pkgs); In multiple methods of Module.c, you repeatedly use the following idiom: 131 pkg_name = GetInternalPackageName(env, pkg, buf, (jsize)sizeof(buf)); 132 if (pkg_name == NULL) { 133 JNU_ThrowOutOfMemoryError(env, NULL); 134 } else { ...but there's no need to call JNU_ThrowOutOfMemoryError if GetInternalPackageName returns NULL since GetInternalPackageName already does it. Otherwise the jdk part looks good. Regards, Peter > > In addition to fixing comments I couldn't resist applying the technique > used in Class.c to get rid of some mallocs in places where we can use a > stack allocated char buf[128] instead, which seems to have a tiny, but > measurable effect. > > Thanks! > > /Claes From claes.redestad at oracle.com Fri Jan 6 13:18:03 2017 From: claes.redestad at oracle.com (Claes Redestad) Date: Fri, 6 Jan 2017 14:18:03 +0100 Subject: RFR: 8171855: Move package name transformations during module bootstrap into native code In-Reply-To: References: <64772f1f-aac0-773d-a308-e01e355a9018@oracle.com> Message-ID: <4ca38914-c8b2-bc93-d445-95835fefdc0f@oracle.com> Hi Peter, On 2017-01-06 09:46, Peter Levart wrote: > Hi Claes, > > On 01/06/2017 03:36 AM, Claes Redestad wrote: >> >> New webrevs: >> http://cr.openjdk.java.net/~redestad/8171855/hotspot.04/ >> http://cr.openjdk.java.net/~redestad/8171855/jdk.04/ > > In Module.c, it seems you applied the "techinique" of conditional > allocation (lines 49...57), but forgot to remove the old code (58...62): > > 49 if (len >= buf_size) { > 50 utf_str = malloc(len + 1); > 51 if (utf_str == NULL) { > 52 JNU_ThrowOutOfMemoryError(env, NULL); > 53 return NULL; > 54 } > 55 } else { > 56 utf_str = buf; > 57 } > 58 utf_str = malloc(len + 1); > 59 if (utf_str == NULL) { > 60 JNU_ThrowOutOfMemoryError(env, NULL); > 61 return NULL; > 62 } Ouch, this must have slipped back in during some final, late night edits. Thanks for spotting it! > > Also, in line 84, you allocate pkgs array only when num_packages != 0: > > 84 if (num_packages != 0 && (pkgs = calloc(num_packages, > sizeof(char*))) == NULL) { > > ...but you free it unconditionally (does free(NULL) work as no-op?): It appears the C specification has said for some time that free(NULL) is and should be a no-op, but that there might be (old) runtimes that could crash when you do it. As I don't know if any of the OpenJDK platforms might be affected or not I've added some checking. > > 110 free(pkgs); > > > In multiple methods of Module.c, you repeatedly use the following idiom: > > 131 pkg_name = GetInternalPackageName(env, pkg, buf, > (jsize)sizeof(buf)); > 132 if (pkg_name == NULL) { > 133 JNU_ThrowOutOfMemoryError(env, NULL); > 134 } else { > > ...but there's no need to call JNU_ThrowOutOfMemoryError if > GetInternalPackageName returns NULL since GetInternalPackageName already > does it. Yes, this allows for a nice cleanup of that code. Updated jdk webrev in-place: http://cr.openjdk.java.net/~redestad/8171855/jdk.04/ Thanks! /Claes > > > Otherwise the jdk part looks good. > > > Regards, Peter > >> >> In addition to fixing comments I couldn't resist applying the technique >> used in Class.c to get rid of some mallocs in places where we can use a >> stack allocated char buf[128] instead, which seems to have a tiny, but >> measurable effect. >> >> Thanks! >> >> /Claes > From Alan.Bateman at oracle.com Fri Jan 6 14:07:58 2017 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 6 Jan 2017 14:07:58 +0000 Subject: RFR: 8171855: Move package name transformations during module bootstrap into native code In-Reply-To: <4ca38914-c8b2-bc93-d445-95835fefdc0f@oracle.com> References: <64772f1f-aac0-773d-a308-e01e355a9018@oracle.com> <4ca38914-c8b2-bc93-d445-95835fefdc0f@oracle.com> Message-ID: On 06/01/2017 13:18, Claes Redestad wrote: > : > > Updated jdk webrev in-place: > > http://cr.openjdk.java.net/~redestad/8171855/jdk.04/ I looked through the latest webrev and it looks quite good. Part of me regrets introducing JNI code of course but this is startup motivated. In Module.c then I assume GetInternalPackageName should be static getInternalPackageName as the scope is just this file (no need for JNIEXPORT). Do we have tests that use package names > 128 to test cases where the buffer on the stack not large enough? -Alan From claes.redestad at oracle.com Fri Jan 6 14:23:39 2017 From: claes.redestad at oracle.com (Claes Redestad) Date: Fri, 6 Jan 2017 15:23:39 +0100 Subject: RFR: 8171855: Move package name transformations during module bootstrap into native code In-Reply-To: References: <64772f1f-aac0-773d-a308-e01e355a9018@oracle.com> <4ca38914-c8b2-bc93-d445-95835fefdc0f@oracle.com> Message-ID: On 2017-01-06 15:07, Alan Bateman wrote: > On 06/01/2017 13:18, Claes Redestad wrote: > >> : >> >> Updated jdk webrev in-place: >> >> http://cr.openjdk.java.net/~redestad/8171855/jdk.04/ > I looked through the latest webrev and it looks quite good. Part of me > regrets introducing JNI code of course but this is startup motivated. > > In Module.c then I assume GetInternalPackageName should be static > getInternalPackageName as the scope is just this file (no need for > JNIEXPORT). Done, will update in place. > > Do we have tests that use package names > 128 to test cases where the > buffer on the stack not large enough? I'm not sure; the malloc'ing path is exercised by DefineModule, but it would make sense to add a sanity test to each method I guess. /Claes From chris.plummer at oracle.com Fri Jan 6 23:14:41 2017 From: chris.plummer at oracle.com (Chris Plummer) Date: Fri, 6 Jan 2017 15:14:41 -0800 Subject: RFR(M) 8155980: ARM InterpreterMacroAssembler::get_method_counters() should not be saving callee saved registers Message-ID: Hello, Please review the following arm changes. They will be pushed to JDK 10 only (when it opens). https://bugs.openjdk.java.net/browse/JDK-8155980 http://cr.openjdk.java.net/~cjplummer/8155980/webrev.02/webrev.hotspot JDK-8012544 added a bunch of callee register saving to InterpreterMacroAssembler::get_method_counters() around the call_VM() call. The reason is because there are a couple of callers of get_method_counters() that need to have r0 and r3 preserved. get_method_counters() should not be responsible for having to save callee saved registers. It does not know which ones are in use when it is called, so it can't do this efficiently. In fact 2 of the 4 callers of get_method_counters() do not need any registers saved. For this reason the callee of get_method_counters() should be responsible for saving callee registers. This solution would have been been pretty straight forward, except that AARCH64 does not allow SP to go above extended_sp, so when setting up extended_sp I needed to make sure there will be room for the 2 registers that need to be pushed. extended_sp is mainly based on max_stack() for the method, plus an extra slot for jsr292 and exception handling (but not both at the same time). So the fix here is mostly about making sure there are always at least 2 extra slots for pushing the 2 registers. Here are the changes: interp_masm_arm.cpp -No longer save/restore registers in get_method_counters(): templateTable_arm.cpp: -Save/restore Rdisp and R3_bytecode to stack around calls to get_method_counters. abstractinterpreter__arm.cpp:: -Properly account for extra 2 slots needed on AARCH64 when creating a frame in layout_activation() -Note I switched to using method->constMethod()->max_stack() because method->max_stack() includes Method::extra_stack_entries(), and I want to account for Method::extra_stack_entries() separately. templateInterpreterGenerator_arm.cpp: -Properly account for extra 2 slots needed on AARCH64 when creating a frame in generate_normal_entry(). I've tested the following with -Xcomp and with -Xmixed on arm32 and arm64: Kitchensink vm.mlvm :jdk_svc :hotspot_runtime :hotspot_serviceability :hotspot_compiler :jdk_lang :jdk_util I also tested the test case from JDK-8012544. thanks, Chris From dean.long at oracle.com Fri Jan 6 23:57:28 2017 From: dean.long at oracle.com (dean.long at oracle.com) Date: Fri, 6 Jan 2017 15:57:28 -0800 Subject: RFR(M) 8155980: ARM InterpreterMacroAssembler::get_method_counters() should not be saving callee saved registers In-Reply-To: References: Message-ID: It looks good but you might want to add a comment in TemplateTable::branch() saying something like: // save and restore caller-saved registers that will be trashed by call_VM dl On 1/6/17 3:14 PM, Chris Plummer wrote: > Hello, > > Please review the following arm changes. They will be pushed to JDK 10 > only (when it opens). > > https://bugs.openjdk.java.net/browse/JDK-8155980 > http://cr.openjdk.java.net/~cjplummer/8155980/webrev.02/webrev.hotspot > > JDK-8012544 added a bunch of callee register saving to > InterpreterMacroAssembler::get_method_counters() around the call_VM() > call. The reason is because there are a couple of callers of > get_method_counters() that need to have r0 and r3 preserved. > get_method_counters() should not be responsible for having to save > callee saved registers. It does not know which ones are in use when it > is called, so it can't do this efficiently. In fact 2 of the 4 callers > of get_method_counters() do not need any registers saved. For this > reason the callee of get_method_counters() should be responsible for > saving callee registers. > > This solution would have been been pretty straight forward, except > that AARCH64 does not allow SP to go above extended_sp, so when > setting up extended_sp I needed to make sure there will be room for > the 2 registers that need to be pushed. extended_sp is mainly based on > max_stack() for the method, plus an extra slot for jsr292 and > exception handling (but not both at the same time). So the fix here is > mostly about making sure there are always at least 2 extra slots for > pushing the 2 registers. > > Here are the changes: > > interp_masm_arm.cpp > -No longer save/restore registers in get_method_counters(): > > templateTable_arm.cpp: > -Save/restore Rdisp and R3_bytecode to stack around calls to > get_method_counters. > > abstractinterpreter__arm.cpp:: > -Properly account for extra 2 slots needed on AARCH64 when creating > a frame > in layout_activation() > -Note I switched to using method->constMethod()->max_stack() because > method->max_stack() includes Method::extra_stack_entries(), and I > want to > account for Method::extra_stack_entries() separately. > > templateInterpreterGenerator_arm.cpp: > -Properly account for extra 2 slots needed on AARCH64 when creating > a frame > in generate_normal_entry(). > > I've tested the following with -Xcomp and with -Xmixed on arm32 and > arm64: > > Kitchensink > vm.mlvm > :jdk_svc > :hotspot_runtime > :hotspot_serviceability > :hotspot_compiler > :jdk_lang > :jdk_util > > I also tested the test case from JDK-8012544. > > thanks, > > Chris > > From mandy.chung at oracle.com Sat Jan 7 05:08:23 2017 From: mandy.chung at oracle.com (Mandy Chung) Date: Fri, 6 Jan 2017 21:08:23 -0800 Subject: RFR: 8171855: Move package name transformations during module bootstrap into native code In-Reply-To: <4ca38914-c8b2-bc93-d445-95835fefdc0f@oracle.com> References: <64772f1f-aac0-773d-a308-e01e355a9018@oracle.com> <4ca38914-c8b2-bc93-d445-95835fefdc0f@oracle.com> Message-ID: <2946E81E-5CB9-4C43-9873-EB0D8B3624DE@oracle.com> > On Jan 6, 2017, at 5:18 AM, Claes Redestad wrote: > > Updated jdk webrev in-place: > > http://cr.openjdk.java.net/~redestad/8171855/jdk.04/ Looks good to me. I assume you are adding a sanity test on the package name > 128 chars in this webrev? Mandy From serguei.spitsyn at oracle.com Mon Jan 9 08:11:51 2017 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Mon, 9 Jan 2017 00:11:51 -0800 Subject: RFR: 8171855: Move package name transformations during module bootstrap into native code In-Reply-To: References: <64772f1f-aac0-773d-a308-e01e355a9018@oracle.com> <4ca38914-c8b2-bc93-d445-95835fefdc0f@oracle.com> Message-ID: <3a683be4-c26a-7027-a064-890a786d2144@oracle.com> Hi Claes, It looks pretty good. One question on the following fragment: http://cr.openjdk.java.net/~redestad/8171855/jdk.04/src/java.base/share/native/libjava/Module.c.udiff.html + int valid = 1; + for (idx = 0; idx < num_packages; idx++) { + jstring pkg = (*env)->GetObjectArrayElement(env, packages, idx); + pkgs[idx] = GetInternalPackageName(env, pkg, NULL, 0); + if (pkgs[idx] == NULL) { + valid = 0; + break; + } + } + + if (valid != 0) { + JVM_DefineModule(env, module, is_open, version, location, + (const char* const*)pkgs, num_packages); + } + } It looks like the module won't be defined if there was an OOM in processing one of the package names. The malloc is used only if the supplied buffer size is not enough. Would it make sense to increase the buffer size from 128 to 256 (or even 512) at the lines: 119 char buf[128]; 140 char buf[128]; 161 char buf[128]; 181 char buf[128]; Nit: it is also better to use a named constant instead. Thanks, Serguei On 1/6/17 06:23, Claes Redestad wrote: > On 2017-01-06 15:07, Alan Bateman wrote: >> On 06/01/2017 13:18, Claes Redestad wrote: >>> : Updated jdk webrev in-place: >>> http://cr.openjdk.java.net/~redestad/8171855/jdk.04/ >> I looked through the latest webrev and it looks quite good. Part of >> me regrets introducing JNI code of course but this is startup >> motivated. In Module.c then I assume GetInternalPackageName should be >> static getInternalPackageName as the scope is just this file (no need >> for JNIEXPORT). > Done, will update in place. >> Do we have tests that use package names > 128 to test cases where the >> buffer on the stack not large enough? > I'm not sure; the malloc'ing path is exercised by DefineModule, but it > would make sense to add a sanity test to each method I guess. /Claes From claes.redestad at oracle.com Mon Jan 9 12:16:51 2017 From: claes.redestad at oracle.com (Claes Redestad) Date: Mon, 9 Jan 2017 13:16:51 +0100 Subject: RFR: 8171855: Move package name transformations during module bootstrap into native code In-Reply-To: <3a683be4-c26a-7027-a064-890a786d2144@oracle.com> References: <64772f1f-aac0-773d-a308-e01e355a9018@oracle.com> <4ca38914-c8b2-bc93-d445-95835fefdc0f@oracle.com> <3a683be4-c26a-7027-a064-890a786d2144@oracle.com> Message-ID: <7e5d0364-6d51-51ad-ee65-d10141e234f9@oracle.com> Hi Serguei, On 2017-01-09 09:11, serguei.spitsyn at oracle.com wrote: > Hi Claes, > > It looks pretty good. thanks, > > One question on the following fragment: > > http://cr.openjdk.java.net/~redestad/8171855/jdk.04/src/java.base/share/native/libjava/Module.c.udiff.html > > > + int valid = 1; > + for (idx = 0; idx < num_packages; idx++) { > + jstring pkg = (*env)->GetObjectArrayElement(env, packages, idx); > + pkgs[idx] = GetInternalPackageName(env, pkg, NULL, 0); > + if (pkgs[idx] == NULL) { > + valid = 0; > + break; > + } > + } > + > + if (valid != 0) { > + JVM_DefineModule(env, module, is_open, version, location, > + (const char* const*)pkgs, num_packages); > + } > + } > > > It looks like the module won't be defined if there was an OOM in > processing one of the package names. > The malloc is used only if the supplied buffer size is not enough. > Would it make sense to increase the buffer size from 128 to 256 (or > even 512) at the lines: > > 119 char buf[128]; 140 char buf[128]; > 161 char buf[128]; 181 char buf[128]; > > > Nit: it is also better to use a named constant instead. The 128 value was taken from similar code in Class.c, and since package names are always shorter I assumed there was no real need to evaluate other heuristics. How about re-visiting this for an enhancement in 10 and evaluate if a different value and a freshly introduced constant makes sense? Thanks! /Claes > > Thanks, Serguei On 1/6/17 06:23, Claes Redestad wrote: >> On 2017-01-06 15:07, Alan Bateman wrote: >>> On 06/01/2017 13:18, Claes Redestad wrote: >>>> : Updated jdk webrev in-place: >>>> http://cr.openjdk.java.net/~redestad/8171855/jdk.04/ >>> I looked through the latest webrev and it looks quite good. Part of >>> me regrets introducing JNI code of course but this is startup >>> motivated. In Module.c then I assume GetInternalPackageName should be >>> static getInternalPackageName as the scope is just this file (no need >>> for JNIEXPORT). >> Done, will update in place. >>> Do we have tests that use package names > 128 to test cases where the >>> buffer on the stack not large enough? >> I'm not sure; the malloc'ing path is exercised by DefineModule, but it >> would make sense to add a sanity test to each method I guess. /Claes From aph at redhat.com Mon Jan 9 15:16:25 2017 From: aph at redhat.com (Andrew Haley) Date: Mon, 9 Jan 2017 15:16:25 +0000 Subject: Another question about JEP 270: Reserved Stack Areas for Critical Sections Message-ID: <80a22901-d334-cc8b-b5dc-9a59ae7cfca5@redhat.com> In interp_masm_x86.cpp I see: void InterpreterMacroAssembler::remove_activation( ... cmpptr(rbx, Address(rthread, JavaThread::reserved_stack_activation_offset())); jcc(Assembler::lessEqual, no_reserved_zone_enabling); call_VM_leaf( CAST_FROM_FN_PTR(address, SharedRuntime::enable_stack_reserved_zone), rthread); push(rthread); call_VM(noreg, CAST_FROM_FN_PTR(address, InterpreterRuntime::throw_delayed_StackOverflowError)); should_not_reach_here(); What does push(rthread) do? Thanks, Andrew. From frederic.parain at oracle.com Mon Jan 9 15:31:14 2017 From: frederic.parain at oracle.com (Frederic Parain) Date: Mon, 9 Jan 2017 10:31:14 -0500 Subject: Another question about JEP 270: Reserved Stack Areas for Critical Sections In-Reply-To: <80a22901-d334-cc8b-b5dc-9a59ae7cfca5@redhat.com> References: <80a22901-d334-cc8b-b5dc-9a59ae7cfca5@redhat.com> Message-ID: <2c338f29-ba22-a346-bf15-2d7ac196e21e@oracle.com> Hi Andrew, I re-read this code a few days ago and I had the same question. I believe it is a useless left over. The throw_delayed_StackOverflowError entry has no additional argument, and because it unconditionally starts the propagation of an exception, the frame is destroyed and nobody can use this value on the stack. I think it is safe to remove but I'll run some tests to double check. Regards, Fred On 01/09/2017 10:16 AM, Andrew Haley wrote: > In interp_masm_x86.cpp I see: > > void InterpreterMacroAssembler::remove_activation( > ... > cmpptr(rbx, Address(rthread, JavaThread::reserved_stack_activation_offset())); > jcc(Assembler::lessEqual, no_reserved_zone_enabling); > > call_VM_leaf( > CAST_FROM_FN_PTR(address, SharedRuntime::enable_stack_reserved_zone), rthread); > push(rthread); > call_VM(noreg, CAST_FROM_FN_PTR(address, > InterpreterRuntime::throw_delayed_StackOverflowError)); > should_not_reach_here(); > > What does push(rthread) do? > > Thanks, > > Andrew. > From max.ockner at oracle.com Mon Jan 9 16:09:05 2017 From: max.ockner at oracle.com (Max Ockner) Date: Mon, 09 Jan 2017 11:09:05 -0500 Subject: RFR(M) 8155980: ARM InterpreterMacroAssembler::get_method_counters() should not be saving callee saved registers In-Reply-To: References: Message-ID: <5873B5A1.3040606@oracle.com> Hi Chris, This looks good to me. As a side note, and from the perspective of someone who has been digging in x86 rather than arm, I wonder if register saving can be rolled into call_VM as is done in x86. It would certainly smooth over some of the stylistic differences between the platforms. Thanks, Max On 1/6/2017 6:14 PM, Chris Plummer wrote: > Hello, > > Please review the following arm changes. They will be pushed to JDK 10 > only (when it opens). > > https://bugs.openjdk.java.net/browse/JDK-8155980 > http://cr.openjdk.java.net/~cjplummer/8155980/webrev.02/webrev.hotspot > > JDK-8012544 added a bunch of callee register saving to > InterpreterMacroAssembler::get_method_counters() around the call_VM() > call. The reason is because there are a couple of callers of > get_method_counters() that need to have r0 and r3 preserved. > get_method_counters() should not be responsible for having to save > callee saved registers. It does not know which ones are in use when it > is called, so it can't do this efficiently. In fact 2 of the 4 callers > of get_method_counters() do not need any registers saved. For this > reason the callee of get_method_counters() should be responsible for > saving callee registers. > > This solution would have been been pretty straight forward, except > that AARCH64 does not allow SP to go above extended_sp, so when > setting up extended_sp I needed to make sure there will be room for > the 2 registers that need to be pushed. extended_sp is mainly based on > max_stack() for the method, plus an extra slot for jsr292 and > exception handling (but not both at the same time). So the fix here is > mostly about making sure there are always at least 2 extra slots for > pushing the 2 registers. > > Here are the changes: > > interp_masm_arm.cpp > -No longer save/restore registers in get_method_counters(): > > templateTable_arm.cpp: > -Save/restore Rdisp and R3_bytecode to stack around calls to > get_method_counters. > > abstractinterpreter__arm.cpp:: > -Properly account for extra 2 slots needed on AARCH64 when creating > a frame > in layout_activation() > -Note I switched to using method->constMethod()->max_stack() because > method->max_stack() includes Method::extra_stack_entries(), and I > want to > account for Method::extra_stack_entries() separately. > > templateInterpreterGenerator_arm.cpp: > -Properly account for extra 2 slots needed on AARCH64 when creating > a frame > in generate_normal_entry(). > > I've tested the following with -Xcomp and with -Xmixed on arm32 and > arm64: > > Kitchensink > vm.mlvm > :jdk_svc > :hotspot_runtime > :hotspot_serviceability > :hotspot_compiler > :jdk_lang > :jdk_util > > I also tested the test case from JDK-8012544. > > thanks, > > Chris > > From chris.plummer at oracle.com Mon Jan 9 17:08:47 2017 From: chris.plummer at oracle.com (Chris Plummer) Date: Mon, 9 Jan 2017 09:08:47 -0800 Subject: RFR(M) 8155980: ARM InterpreterMacroAssembler::get_method_counters() should not be saving callee saved registers In-Reply-To: References: Message-ID: <70a61ffa-5d95-ae4f-2077-157f791675ec@oracle.com> Thanks Dean. Unfortunately I got a crash over the weekend when repeatedly running one of our test suites. Happens about 1 out of 10 times on both 32-bit and 64-bit. Looking into it now. Chris On 1/6/17 3:57 PM, dean.long at oracle.com wrote: > It looks good but you might want to add a comment in > TemplateTable::branch() saying something like: > > // save and restore caller-saved registers that will be trashed by > call_VM > > dl > > > On 1/6/17 3:14 PM, Chris Plummer wrote: >> Hello, >> >> Please review the following arm changes. They will be pushed to JDK >> 10 only (when it opens). >> >> https://bugs.openjdk.java.net/browse/JDK-8155980 >> http://cr.openjdk.java.net/~cjplummer/8155980/webrev.02/webrev.hotspot >> >> JDK-8012544 added a bunch of callee register saving to >> InterpreterMacroAssembler::get_method_counters() around the call_VM() >> call. The reason is because there are a couple of callers of >> get_method_counters() that need to have r0 and r3 preserved. >> get_method_counters() should not be responsible for having to save >> callee saved registers. It does not know which ones are in use when >> it is called, so it can't do this efficiently. In fact 2 of the 4 >> callers of get_method_counters() do not need any registers saved. For >> this reason the callee of get_method_counters() should be responsible >> for saving callee registers. >> >> This solution would have been been pretty straight forward, except >> that AARCH64 does not allow SP to go above extended_sp, so when >> setting up extended_sp I needed to make sure there will be room for >> the 2 registers that need to be pushed. extended_sp is mainly based >> on max_stack() for the method, plus an extra slot for jsr292 and >> exception handling (but not both at the same time). So the fix here >> is mostly about making sure there are always at least 2 extra slots >> for pushing the 2 registers. >> >> Here are the changes: >> >> interp_masm_arm.cpp >> -No longer save/restore registers in get_method_counters(): >> >> templateTable_arm.cpp: >> -Save/restore Rdisp and R3_bytecode to stack around calls to >> get_method_counters. >> >> abstractinterpreter__arm.cpp:: >> -Properly account for extra 2 slots needed on AARCH64 when creating >> a frame >> in layout_activation() >> -Note I switched to using method->constMethod()->max_stack() because >> method->max_stack() includes Method::extra_stack_entries(), and I >> want to >> account for Method::extra_stack_entries() separately. >> >> templateInterpreterGenerator_arm.cpp: >> -Properly account for extra 2 slots needed on AARCH64 when creating >> a frame >> in generate_normal_entry(). >> >> I've tested the following with -Xcomp and with -Xmixed on arm32 and >> arm64: >> >> Kitchensink >> vm.mlvm >> :jdk_svc >> :hotspot_runtime >> :hotspot_serviceability >> :hotspot_compiler >> :jdk_lang >> :jdk_util >> >> I also tested the test case from JDK-8012544. >> >> thanks, >> >> Chris >> >> > From chris.plummer at oracle.com Mon Jan 9 17:14:29 2017 From: chris.plummer at oracle.com (Chris Plummer) Date: Mon, 9 Jan 2017 09:14:29 -0800 Subject: RFR(M) 8155980: ARM InterpreterMacroAssembler::get_method_counters() should not be saving callee saved registers In-Reply-To: <5873B5A1.3040606@oracle.com> References: <5873B5A1.3040606@oracle.com> Message-ID: <50ddac69-5f18-a484-df48-e1e7f2272358@oracle.com> Hi Max, I took a quick look at the x86 call_VM() code and didn't see any register saving. Can you point me to it? thanks, Chris On 1/9/17 8:09 AM, Max Ockner wrote: > Hi Chris, > > This looks good to me. > > As a side note, and from the perspective of someone who has been > digging in x86 rather than arm, I wonder if register saving can be > rolled into call_VM as is done in x86. It would certainly smooth over > some of the stylistic differences between the platforms. > > Thanks, > Max > > On 1/6/2017 6:14 PM, Chris Plummer wrote: >> Hello, >> >> Please review the following arm changes. They will be pushed to JDK >> 10 only (when it opens). >> >> https://bugs.openjdk.java.net/browse/JDK-8155980 >> http://cr.openjdk.java.net/~cjplummer/8155980/webrev.02/webrev.hotspot >> >> JDK-8012544 added a bunch of callee register saving to >> InterpreterMacroAssembler::get_method_counters() around the call_VM() >> call. The reason is because there are a couple of callers of >> get_method_counters() that need to have r0 and r3 preserved. >> get_method_counters() should not be responsible for having to save >> callee saved registers. It does not know which ones are in use when >> it is called, so it can't do this efficiently. In fact 2 of the 4 >> callers of get_method_counters() do not need any registers saved. For >> this reason the callee of get_method_counters() should be responsible >> for saving callee registers. >> >> This solution would have been been pretty straight forward, except >> that AARCH64 does not allow SP to go above extended_sp, so when >> setting up extended_sp I needed to make sure there will be room for >> the 2 registers that need to be pushed. extended_sp is mainly based >> on max_stack() for the method, plus an extra slot for jsr292 and >> exception handling (but not both at the same time). So the fix here >> is mostly about making sure there are always at least 2 extra slots >> for pushing the 2 registers. >> >> Here are the changes: >> >> interp_masm_arm.cpp >> -No longer save/restore registers in get_method_counters(): >> >> templateTable_arm.cpp: >> -Save/restore Rdisp and R3_bytecode to stack around calls to >> get_method_counters. >> >> abstractinterpreter__arm.cpp:: >> -Properly account for extra 2 slots needed on AARCH64 when creating >> a frame >> in layout_activation() >> -Note I switched to using method->constMethod()->max_stack() because >> method->max_stack() includes Method::extra_stack_entries(), and I >> want to >> account for Method::extra_stack_entries() separately. >> >> templateInterpreterGenerator_arm.cpp: >> -Properly account for extra 2 slots needed on AARCH64 when creating >> a frame >> in generate_normal_entry(). >> >> I've tested the following with -Xcomp and with -Xmixed on arm32 and >> arm64: >> >> Kitchensink >> vm.mlvm >> :jdk_svc >> :hotspot_runtime >> :hotspot_serviceability >> :hotspot_compiler >> :jdk_lang >> :jdk_util >> >> I also tested the test case from JDK-8012544. >> >> thanks, >> >> Chris >> >> > From aph at redhat.com Mon Jan 9 17:23:25 2017 From: aph at redhat.com (Andrew Haley) Date: Mon, 9 Jan 2017 17:23:25 +0000 Subject: Another question about JEP 270: Reserved Stack Areas for Critical Sections In-Reply-To: <2c338f29-ba22-a346-bf15-2d7ac196e21e@oracle.com> References: <80a22901-d334-cc8b-b5dc-9a59ae7cfca5@redhat.com> <2c338f29-ba22-a346-bf15-2d7ac196e21e@oracle.com> Message-ID: <7d2a6479-23ac-170b-166a-04cca918e9f8@redhat.com> On 09/01/17 15:31, Frederic Parain wrote: > Hi Andrew, > > I re-read this code a few days ago and I had the same question. > I believe it is a useless left over. > The throw_delayed_StackOverflowError entry has no additional argument, > and because it unconditionally starts the propagation of an exception, > the frame is destroyed and nobody can use this value on the stack. > I think it is safe to remove but I'll run some tests to double check. While you're looking at that code, you might want to do this: diff --git a/src/share/vm/opto/compile.cpp b/src/share/vm/opto/compile.cpp --- a/src/share/vm/opto/compile.cpp +++ b/src/share/vm/opto/compile.cpp @@ -992,7 +992,8 @@ _print_inlining_output(NULL), _allowed_reasons(0), _interpreter_frame_size(0), - _max_node_limit(MaxNodeLimit) { + _max_node_limit(MaxNodeLimit), + _has_reserved_stack_access(false) { C = this; TraceTime t1(NULL, &_t_totalCompilation, CITime, false); As it stands, every opto runtime call is compiled with reserved stack access. Andrew. From aph at redhat.com Mon Jan 9 18:04:55 2017 From: aph at redhat.com (Andrew Haley) Date: Mon, 9 Jan 2017 18:04:55 +0000 Subject: RFR: 8172144: AArch64: Implement "JEP 270: Reserved Stack Areas for Critical Sections" Message-ID: <20fc8f92-9ea0-e853-a53c-b03d0c0f0beb@redhat.com> https://bugs.openjdk.java.net/browse/JDK-8172144 Needs a sponsor because it enables the test. http://cr.openjdk.java.net/~aph/8172144/ Andrew. From frederic.parain at oracle.com Mon Jan 9 18:34:43 2017 From: frederic.parain at oracle.com (Frederic Parain) Date: Mon, 9 Jan 2017 13:34:43 -0500 Subject: Another question about JEP 270: Reserved Stack Areas for Critical Sections In-Reply-To: <7d2a6479-23ac-170b-166a-04cca918e9f8@redhat.com> References: <80a22901-d334-cc8b-b5dc-9a59ae7cfca5@redhat.com> <2c338f29-ba22-a346-bf15-2d7ac196e21e@oracle.com> <7d2a6479-23ac-170b-166a-04cca918e9f8@redhat.com> Message-ID: <3aebf3db-0786-1157-c386-e6c8de953a0c@oracle.com> Thank you, I'll add this fix. Fred On 01/09/2017 12:23 PM, Andrew Haley wrote: > On 09/01/17 15:31, Frederic Parain wrote: >> Hi Andrew, >> >> I re-read this code a few days ago and I had the same question. >> I believe it is a useless left over. >> The throw_delayed_StackOverflowError entry has no additional argument, >> and because it unconditionally starts the propagation of an exception, >> the frame is destroyed and nobody can use this value on the stack. >> I think it is safe to remove but I'll run some tests to double check. > > While you're looking at that code, you might want to do this: > > diff --git a/src/share/vm/opto/compile.cpp b/src/share/vm/opto/compile.cpp > --- a/src/share/vm/opto/compile.cpp > +++ b/src/share/vm/opto/compile.cpp > @@ -992,7 +992,8 @@ > _print_inlining_output(NULL), > _allowed_reasons(0), > _interpreter_frame_size(0), > - _max_node_limit(MaxNodeLimit) { > + _max_node_limit(MaxNodeLimit), > + _has_reserved_stack_access(false) { > C = this; > > TraceTime t1(NULL, &_t_totalCompilation, CITime, false); > > As it stands, every opto runtime call is compiled with reserved > stack access. > > Andrew. > From serguei.spitsyn at oracle.com Mon Jan 9 19:20:59 2017 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Mon, 9 Jan 2017 11:20:59 -0800 Subject: RFR: 8171855: Move package name transformations during module bootstrap into native code In-Reply-To: <7e5d0364-6d51-51ad-ee65-d10141e234f9@oracle.com> References: <64772f1f-aac0-773d-a308-e01e355a9018@oracle.com> <4ca38914-c8b2-bc93-d445-95835fefdc0f@oracle.com> <3a683be4-c26a-7027-a064-890a786d2144@oracle.com> <7e5d0364-6d51-51ad-ee65-d10141e234f9@oracle.com> Message-ID: <38b7db2a-824b-1301-50af-01eb51a1bbfd@oracle.com> On 1/9/17 04:16, Claes Redestad wrote: > Hi Serguei, > > On 2017-01-09 09:11, serguei.spitsyn at oracle.com wrote: >> Hi Claes, >> >> It looks pretty good. > > thanks, > >> >> One question on the following fragment: >> >> http://cr.openjdk.java.net/~redestad/8171855/jdk.04/src/java.base/share/native/libjava/Module.c.udiff.html >> >> >> >> + int valid = 1; >> + for (idx = 0; idx < num_packages; idx++) { >> + jstring pkg = (*env)->GetObjectArrayElement(env, packages, idx); >> + pkgs[idx] = GetInternalPackageName(env, pkg, NULL, 0); >> + if (pkgs[idx] == NULL) { >> + valid = 0; >> + break; >> + } >> + } >> + >> + if (valid != 0) { >> + JVM_DefineModule(env, module, is_open, version, location, >> + (const char* const*)pkgs, num_packages); >> + } >> + } >> >> >> It looks like the module won't be defined if there was an OOM in >> processing one of the package names. >> The malloc is used only if the supplied buffer size is not enough. >> Would it make sense to increase the buffer size from 128 to 256 (or >> even 512) at the lines: >> >> 119 char buf[128]; 140 char buf[128]; >> 161 char buf[128]; 181 char buf[128]; >> >> >> Nit: it is also better to use a named constant instead. > > The 128 value was taken from similar code in Class.c, and since package > names are always shorter I assumed there was no real need to evaluate > other heuristics. > > How about re-visiting this for an enhancement in 10 and evaluate if > a different value and a freshly introduced constant makes sense? Sure. Thanks, Serguei > > Thanks! > > /Claes > >> >> Thanks, Serguei On 1/6/17 06:23, Claes Redestad wrote: >>> On 2017-01-06 15:07, Alan Bateman wrote: >>>> On 06/01/2017 13:18, Claes Redestad wrote: >>>>> : Updated jdk webrev in-place: >>>>> http://cr.openjdk.java.net/~redestad/8171855/jdk.04/ >>>> I looked through the latest webrev and it looks quite good. Part of >>>> me regrets introducing JNI code of course but this is startup >>>> motivated. In Module.c then I assume GetInternalPackageName should be >>>> static getInternalPackageName as the scope is just this file (no need >>>> for JNIEXPORT). >>> Done, will update in place. >>>> Do we have tests that use package names > 128 to test cases where the >>>> buffer on the stack not large enough? >>> I'm not sure; the malloc'ing path is exercised by DefineModule, but it >>> would make sense to add a sanity test to each method I guess. /Claes From frederic.parain at oracle.com Mon Jan 9 19:40:53 2017 From: frederic.parain at oracle.com (Frederic Parain) Date: Mon, 9 Jan 2017 14:40:53 -0500 Subject: RFR: 8172144: AArch64: Implement "JEP 270: Reserved Stack Areas for Critical Sections" In-Reply-To: <20fc8f92-9ea0-e853-a53c-b03d0c0f0beb@redhat.com> References: <20fc8f92-9ea0-e853-a53c-b03d0c0f0beb@redhat.com> Message-ID: I'll sponsor it. Thank you, Fred On 01/09/2017 01:04 PM, Andrew Haley wrote: > https://bugs.openjdk.java.net/browse/JDK-8172144 > > Needs a sponsor because it enables the test. > > http://cr.openjdk.java.net/~aph/8172144/ > > Andrew. > From max.ockner at oracle.com Mon Jan 9 19:43:36 2017 From: max.ockner at oracle.com (Max Ockner) Date: Mon, 09 Jan 2017 14:43:36 -0500 Subject: RFR(M) 8155980: ARM InterpreterMacroAssembler::get_method_counters() should not be saving callee saved registers In-Reply-To: <50ddac69-5f18-a484-df48-e1e7f2272358@oracle.com> References: <5873B5A1.3040606@oracle.com> <50ddac69-5f18-a484-df48-e1e7f2272358@oracle.com> Message-ID: <5873E7E8.2060307@oracle.com> Hi Chris, I may have misspoken. I was pretty convinced that there was a push_CPU_state() call somewhere in one of the call_VM* methods since I always see large blocks of register push and pop operations in the debugger. I checked the code and I couldn't find any such calls to push_CPU_state(). Max On 1/9/2017 12:14 PM, Chris Plummer wrote: > Hi Max, > > I took a quick look at the x86 call_VM() code and didn't see any > register saving. Can you point me to it? > > thanks, > > Chris > > On 1/9/17 8:09 AM, Max Ockner wrote: >> Hi Chris, >> >> This looks good to me. >> >> As a side note, and from the perspective of someone who has been >> digging in x86 rather than arm, I wonder if register saving can be >> rolled into call_VM as is done in x86. It would certainly smooth over >> some of the stylistic differences between the platforms. >> >> Thanks, >> Max >> >> On 1/6/2017 6:14 PM, Chris Plummer wrote: >>> Hello, >>> >>> Please review the following arm changes. They will be pushed to JDK >>> 10 only (when it opens). >>> >>> https://bugs.openjdk.java.net/browse/JDK-8155980 >>> http://cr.openjdk.java.net/~cjplummer/8155980/webrev.02/webrev.hotspot >>> >>> JDK-8012544 added a bunch of callee register saving to >>> InterpreterMacroAssembler::get_method_counters() around the >>> call_VM() call. The reason is because there are a couple of callers >>> of get_method_counters() that need to have r0 and r3 preserved. >>> get_method_counters() should not be responsible for having to save >>> callee saved registers. It does not know which ones are in use when >>> it is called, so it can't do this efficiently. In fact 2 of the 4 >>> callers of get_method_counters() do not need any registers saved. >>> For this reason the callee of get_method_counters() should be >>> responsible for saving callee registers. >>> >>> This solution would have been been pretty straight forward, except >>> that AARCH64 does not allow SP to go above extended_sp, so when >>> setting up extended_sp I needed to make sure there will be room for >>> the 2 registers that need to be pushed. extended_sp is mainly based >>> on max_stack() for the method, plus an extra slot for jsr292 and >>> exception handling (but not both at the same time). So the fix here >>> is mostly about making sure there are always at least 2 extra slots >>> for pushing the 2 registers. >>> >>> Here are the changes: >>> >>> interp_masm_arm.cpp >>> -No longer save/restore registers in get_method_counters(): >>> >>> templateTable_arm.cpp: >>> -Save/restore Rdisp and R3_bytecode to stack around calls to >>> get_method_counters. >>> >>> abstractinterpreter__arm.cpp:: >>> -Properly account for extra 2 slots needed on AARCH64 when >>> creating a frame >>> in layout_activation() >>> -Note I switched to using method->constMethod()->max_stack() because >>> method->max_stack() includes Method::extra_stack_entries(), and I >>> want to >>> account for Method::extra_stack_entries() separately. >>> >>> templateInterpreterGenerator_arm.cpp: >>> -Properly account for extra 2 slots needed on AARCH64 when >>> creating a frame >>> in generate_normal_entry(). >>> >>> I've tested the following with -Xcomp and with -Xmixed on arm32 and >>> arm64: >>> >>> Kitchensink >>> vm.mlvm >>> :jdk_svc >>> :hotspot_runtime >>> :hotspot_serviceability >>> :hotspot_compiler >>> :jdk_lang >>> :jdk_util >>> >>> I also tested the test case from JDK-8012544. >>> >>> thanks, >>> >>> Chris >>> >>> >> > From chris.plummer at oracle.com Mon Jan 9 20:18:37 2017 From: chris.plummer at oracle.com (Chris Plummer) Date: Mon, 9 Jan 2017 12:18:37 -0800 Subject: RFR(M) 8155980: ARM InterpreterMacroAssembler::get_method_counters() should not be saving callee saved registers In-Reply-To: <70a61ffa-5d95-ae4f-2077-157f791675ec@oracle.com> References: <70a61ffa-5d95-ae4f-2077-157f791675ec@oracle.com> Message-ID: <565d92d9-a254-3ffe-4775-64ad260b37a6@oracle.com> Sigh, there's a bug in the following: #ifdef AARCH64 __ stp(Rdisp, R3_bytecode, Address(Rstack_top, -2*wordSize, pre_indexed)); #else __ push(RegisterSet(Rdisp) | RegisterSet(R3_bytecode)); #endif __ get_method_counters(Rmethod, Rcounters, dispatch); #ifdef AARCH64 __ ldp(Rdisp, R3_bytecode, Address(Rstack_top, 2*wordSize, post_indexed)); #else __ pop(RegisterSet(Rdisp) | RegisterSet(R3_bytecode)); #endif Note that the "dispatch" label is passed to get_method_counters(), and it will generate code that branches to it, thus by passing the pop. Need to rethink this. I might need to introduce a new label just before the dispatch label that will do the pop. The other choice is possibly get_method_counters() should be told which registers to save. BTW, while looking over this code more carefully, it looks like for AARCH64, r5 also needs to be saved and restored. It's volatile on AARCH64, and is being used to store Rbumped_taken_count. Chris On 1/9/17 9:08 AM, Chris Plummer wrote: > Thanks Dean. Unfortunately I got a crash over the weekend when > repeatedly running one of our test suites. Happens about 1 out of 10 > times on both 32-bit and 64-bit. Looking into it now. > > Chris > > On 1/6/17 3:57 PM, dean.long at oracle.com wrote: >> It looks good but you might want to add a comment in >> TemplateTable::branch() saying something like: >> >> // save and restore caller-saved registers that will be trashed by >> call_VM >> >> dl >> >> >> On 1/6/17 3:14 PM, Chris Plummer wrote: >>> Hello, >>> >>> Please review the following arm changes. They will be pushed to JDK >>> 10 only (when it opens). >>> >>> https://bugs.openjdk.java.net/browse/JDK-8155980 >>> http://cr.openjdk.java.net/~cjplummer/8155980/webrev.02/webrev.hotspot >>> >>> JDK-8012544 added a bunch of callee register saving to >>> InterpreterMacroAssembler::get_method_counters() around the >>> call_VM() call. The reason is because there are a couple of callers >>> of get_method_counters() that need to have r0 and r3 preserved. >>> get_method_counters() should not be responsible for having to save >>> callee saved registers. It does not know which ones are in use when >>> it is called, so it can't do this efficiently. In fact 2 of the 4 >>> callers of get_method_counters() do not need any registers saved. >>> For this reason the callee of get_method_counters() should be >>> responsible for saving callee registers. >>> >>> This solution would have been been pretty straight forward, except >>> that AARCH64 does not allow SP to go above extended_sp, so when >>> setting up extended_sp I needed to make sure there will be room for >>> the 2 registers that need to be pushed. extended_sp is mainly based >>> on max_stack() for the method, plus an extra slot for jsr292 and >>> exception handling (but not both at the same time). So the fix here >>> is mostly about making sure there are always at least 2 extra slots >>> for pushing the 2 registers. >>> >>> Here are the changes: >>> >>> interp_masm_arm.cpp >>> -No longer save/restore registers in get_method_counters(): >>> >>> templateTable_arm.cpp: >>> -Save/restore Rdisp and R3_bytecode to stack around calls to >>> get_method_counters. >>> >>> abstractinterpreter__arm.cpp:: >>> -Properly account for extra 2 slots needed on AARCH64 when >>> creating a frame >>> in layout_activation() >>> -Note I switched to using method->constMethod()->max_stack() because >>> method->max_stack() includes Method::extra_stack_entries(), and I >>> want to >>> account for Method::extra_stack_entries() separately. >>> >>> templateInterpreterGenerator_arm.cpp: >>> -Properly account for extra 2 slots needed on AARCH64 when >>> creating a frame >>> in generate_normal_entry(). >>> >>> I've tested the following with -Xcomp and with -Xmixed on arm32 and >>> arm64: >>> >>> Kitchensink >>> vm.mlvm >>> :jdk_svc >>> :hotspot_runtime >>> :hotspot_serviceability >>> :hotspot_compiler >>> :jdk_lang >>> :jdk_util >>> >>> I also tested the test case from JDK-8012544. >>> >>> thanks, >>> >>> Chris >>> >>> >> > From chris.plummer at oracle.com Mon Jan 9 20:33:14 2017 From: chris.plummer at oracle.com (Chris Plummer) Date: Mon, 9 Jan 2017 12:33:14 -0800 Subject: RFR(M) 8155980: ARM InterpreterMacroAssembler::get_method_counters() should not be saving callee saved registers In-Reply-To: <5873E7E8.2060307@oracle.com> References: <5873B5A1.3040606@oracle.com> <50ddac69-5f18-a484-df48-e1e7f2272358@oracle.com> <5873E7E8.2060307@oracle.com> Message-ID: <848c4ec6-0141-8608-1d79-40e897508281@oracle.com> It's probably the following: void MacroAssembler::stop(const char* msg) { ExternalAddress message((address)msg); // push address of message pushptr(message.addr()); { Label L; call(L, relocInfo::none); bind(L); } // push eip pusha(); // push registers call(RuntimeAddress(CAST_FROM_FN_PTR(address, MacroAssembler::debug32))); hlt(); } This is called for what are effectively asm asserts. There is no corresponding pop. Chris On 1/9/17 11:43 AM, Max Ockner wrote: > Hi Chris, > I may have misspoken. I was pretty convinced that there was a > push_CPU_state() call somewhere in one of the call_VM* methods since I > always see large blocks of register push and pop operations in the > debugger. I checked the code and I couldn't find any such calls to > push_CPU_state(). > Max > > On 1/9/2017 12:14 PM, Chris Plummer wrote: >> Hi Max, >> >> I took a quick look at the x86 call_VM() code and didn't see any >> register saving. Can you point me to it? >> >> thanks, >> >> Chris >> >> On 1/9/17 8:09 AM, Max Ockner wrote: >>> Hi Chris, >>> >>> This looks good to me. >>> >>> As a side note, and from the perspective of someone who has been >>> digging in x86 rather than arm, I wonder if register saving can be >>> rolled into call_VM as is done in x86. It would certainly smooth >>> over some of the stylistic differences between the platforms. >>> >>> Thanks, >>> Max >>> >>> On 1/6/2017 6:14 PM, Chris Plummer wrote: >>>> Hello, >>>> >>>> Please review the following arm changes. They will be pushed to JDK >>>> 10 only (when it opens). >>>> >>>> https://bugs.openjdk.java.net/browse/JDK-8155980 >>>> http://cr.openjdk.java.net/~cjplummer/8155980/webrev.02/webrev.hotspot >>>> >>>> JDK-8012544 added a bunch of callee register saving to >>>> InterpreterMacroAssembler::get_method_counters() around the >>>> call_VM() call. The reason is because there are a couple of callers >>>> of get_method_counters() that need to have r0 and r3 preserved. >>>> get_method_counters() should not be responsible for having to save >>>> callee saved registers. It does not know which ones are in use when >>>> it is called, so it can't do this efficiently. In fact 2 of the 4 >>>> callers of get_method_counters() do not need any registers saved. >>>> For this reason the callee of get_method_counters() should be >>>> responsible for saving callee registers. >>>> >>>> This solution would have been been pretty straight forward, except >>>> that AARCH64 does not allow SP to go above extended_sp, so when >>>> setting up extended_sp I needed to make sure there will be room for >>>> the 2 registers that need to be pushed. extended_sp is mainly based >>>> on max_stack() for the method, plus an extra slot for jsr292 and >>>> exception handling (but not both at the same time). So the fix here >>>> is mostly about making sure there are always at least 2 extra slots >>>> for pushing the 2 registers. >>>> >>>> Here are the changes: >>>> >>>> interp_masm_arm.cpp >>>> -No longer save/restore registers in get_method_counters(): >>>> >>>> templateTable_arm.cpp: >>>> -Save/restore Rdisp and R3_bytecode to stack around calls to >>>> get_method_counters. >>>> >>>> abstractinterpreter__arm.cpp:: >>>> -Properly account for extra 2 slots needed on AARCH64 when >>>> creating a frame >>>> in layout_activation() >>>> -Note I switched to using method->constMethod()->max_stack() because >>>> method->max_stack() includes Method::extra_stack_entries(), and >>>> I want to >>>> account for Method::extra_stack_entries() separately. >>>> >>>> templateInterpreterGenerator_arm.cpp: >>>> -Properly account for extra 2 slots needed on AARCH64 when >>>> creating a frame >>>> in generate_normal_entry(). >>>> >>>> I've tested the following with -Xcomp and with -Xmixed on arm32 and >>>> arm64: >>>> >>>> Kitchensink >>>> vm.mlvm >>>> :jdk_svc >>>> :hotspot_runtime >>>> :hotspot_serviceability >>>> :hotspot_compiler >>>> :jdk_lang >>>> :jdk_util >>>> >>>> I also tested the test case from JDK-8012544. >>>> >>>> thanks, >>>> >>>> Chris >>>> >>>> >>> >> > From rwestrel at redhat.com Tue Jan 10 08:56:13 2017 From: rwestrel at redhat.com (Roland Westrelin) Date: Tue, 10 Jan 2017 09:56:13 +0100 Subject: RFR: 8172144: AArch64: Implement "JEP 270: Reserved Stack Areas for Critical Sections" In-Reply-To: <20fc8f92-9ea0-e853-a53c-b03d0c0f0beb@redhat.com> References: <20fc8f92-9ea0-e853-a53c-b03d0c0f0beb@redhat.com> Message-ID: > http://cr.openjdk.java.net/~aph/8172144/ That looks good to me. Roland. From robbin.ehn at oracle.com Tue Jan 10 10:14:39 2017 From: robbin.ehn at oracle.com (Robbin Ehn) Date: Tue, 10 Jan 2017 11:14:39 +0100 Subject: RFR: 8079441: Intermittent failures on Windows with "Unexpected exit from test [exit code: 1080890248]" (0x406d1388) Message-ID: <2b83c373-d196-58b7-d757-eaff2b8931e3@oracle.com> Hi all, please review. We still have exit code 1080890248/0x406d1388 on windows when running kitchensink. Since this is the same value as windows thread name exception: http://msdn.microsoft.com/en-us/library/xcb2z8hs.aspx and we are still suspicious about this. This is not a bug fix per se, but it will determine if this exception is the cause of this and if so only when a debugger is attached this failure can happen. Bug: https://bugs.openjdk.java.net/browse/JDK-8079441 Tested with windbg and passes winx64 hotspot_jprt. /Robbin --- a/src/os/windows/vm/os_windows.cpp Mon Jan 09 19:36:47 2017 +0000 +++ b/src/os/windows/vm/os_windows.cpp Tue Jan 10 11:00:45 2017 +0100 @@ -777,6 +777,11 @@ // Note that unfortunately this only works if the process // is already attached to a debugger; debugger must observe // the exception below to show the correct name. + + // If there is no debugger attached skip raising the exception + if (!IsDebuggerPresent()) { + return; + } const DWORD MS_VC_EXCEPTION = 0x406D1388; struct { From thomas.stuefe at gmail.com Tue Jan 10 10:42:48 2017 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Tue, 10 Jan 2017 11:42:48 +0100 Subject: RFR: 8079441: Intermittent failures on Windows with "Unexpected exit from test [exit code: 1080890248]" (0x406d1388) In-Reply-To: <2b83c373-d196-58b7-d757-eaff2b8931e3@oracle.com> References: <2b83c373-d196-58b7-d757-eaff2b8931e3@oracle.com> Message-ID: Hi all, sorry about this, I think I introduced setting the native windows thread name. Note that this coding is present in our VM since over two years and never caused any trouble. I did an extensive search in our (SAP) test protocol databases, but could not find any traces of such crashes. Nevertheless, I think the fix makes sense. If the error persists, it may also be advisable just to remove the functionality for Windows altogether. Although I like seeing the thread names in Visual Studio this feature is not worth crashing over. Kind Regards, Thomas On Tue, Jan 10, 2017 at 11:14 AM, Robbin Ehn wrote: > Hi all, please review. > > We still have exit code 1080890248/0x406d1388 on windows when running > kitchensink. > Since this is the same value as windows thread name exception: > http://msdn.microsoft.com/en-us/library/xcb2z8hs.aspx > and we are still suspicious about this. > > This is not a bug fix per se, but it will determine if this exception is > the cause of this > and if so only when a debugger is attached this failure can happen. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8079441 > > Tested with windbg and passes winx64 hotspot_jprt. > > /Robbin > > --- a/src/os/windows/vm/os_windows.cpp Mon Jan 09 19:36:47 2017 +0000 > +++ b/src/os/windows/vm/os_windows.cpp Tue Jan 10 11:00:45 2017 +0100 > @@ -777,6 +777,11 @@ > // Note that unfortunately this only works if the process > // is already attached to a debugger; debugger must observe > // the exception below to show the correct name. > + > + // If there is no debugger attached skip raising the exception > + if (!IsDebuggerPresent()) { > + return; > + } > > const DWORD MS_VC_EXCEPTION = 0x406D1388; > struct { > From robbin.ehn at oracle.com Tue Jan 10 13:49:06 2017 From: robbin.ehn at oracle.com (Robbin Ehn) Date: Tue, 10 Jan 2017 14:49:06 +0100 Subject: RFR: 8079441: Intermittent failures on Windows with "Unexpected exit from test [exit code: 1080890248]" (0x406d1388) In-Reply-To: References: <2b83c373-d196-58b7-d757-eaff2b8931e3@oracle.com> Message-ID: <93fc3ffb-3a34-b2ac-71bc-72b185b76bdd@oracle.com> Hi Thomas, On 01/10/2017 11:42 AM, Thomas St?fe wrote: > Hi all, > > sorry about this, I think I introduced setting the native windows thread name. Note that this coding is present in our VM since over two years and never caused any trouble. > I did an extensive search in our (SAP) test protocol databases, but could not find any traces of such crashes. > > Nevertheless, I think the fix makes sense. If the error persists, it may also be advisable just to remove the functionality for Windows altogether. Although I like seeing > the thread names in Visual Studio this feature is not worth crashing over. Ok, agreed, thanks for having a look! /Robbin > > Kind Regards, Thomas > > > On Tue, Jan 10, 2017 at 11:14 AM, Robbin Ehn > wrote: > > Hi all, please review. > > We still have exit code 1080890248/0x406d1388 on windows when running kitchensink. > Since this is the same value as windows thread name exception: > http://msdn.microsoft.com/en-us/library/xcb2z8hs.aspx > and we are still suspicious about this. > > This is not a bug fix per se, but it will determine if this exception is the cause of this > and if so only when a debugger is attached this failure can happen. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8079441 > > Tested with windbg and passes winx64 hotspot_jprt. > > /Robbin > > --- a/src/os/windows/vm/os_windows.cpp Mon Jan 09 19:36:47 2017 +0000 > +++ b/src/os/windows/vm/os_windows.cpp Tue Jan 10 11:00:45 2017 +0100 > @@ -777,6 +777,11 @@ > // Note that unfortunately this only works if the process > // is already attached to a debugger; debugger must observe > // the exception below to show the correct name. > + > + // If there is no debugger attached skip raising the exception > + if (!IsDebuggerPresent()) { > + return; > + } > > const DWORD MS_VC_EXCEPTION = 0x406D1388; > struct { > > From harold.seigel at oracle.com Tue Jan 10 15:02:38 2017 From: harold.seigel at oracle.com (harold seigel) Date: Tue, 10 Jan 2017 10:02:38 -0500 Subject: RFR(S) 8172288: Fix error message when trying to define an existing package to a module Message-ID: <7926a146-6005-5be0-dc8c-425ab8d5290f@oracle.com> Hi, Please review this small fix for JDK-8172288. Here's a sample of the new message: Package mypackage6 for module dupl.pkg.module is already in another module, Module_A, defined to the class loader Adding the class loader name to the message will be done as part of JDK-8169559 . Open Webrev: http://cr.openjdk.java.net/~hseigel/bug_8172288/webrev/index.html JBS Bug: https://bugs.openjdk.java.net/browse/JDK-8172288 The fix was tested with the JTreg hotspot, java/io, java/lang, java/util and other JTReg tests, and the NSK co-located and non-colocated tests. Thanks, Harold From Alan.Bateman at oracle.com Tue Jan 10 15:12:46 2017 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 10 Jan 2017 15:12:46 +0000 Subject: RFR(S) 8172288: Fix error message when trying to define an existing package to a module In-Reply-To: <7926a146-6005-5be0-dc8c-425ab8d5290f@oracle.com> References: <7926a146-6005-5be0-dc8c-425ab8d5290f@oracle.com> Message-ID: On 10/01/2017 15:02, harold seigel wrote: > Hi, > > Please review this small fix for JDK-8172288. Here's a sample of the > new message: > > Package mypackage6 for module dupl.pkg.module is already in another > module, Module_A, defined to the class loader > > Adding the class loader name to the message will be done as part of > JDK-8169559 . > > Open Webrev: > http://cr.openjdk.java.net/~hseigel/bug_8172288/webrev/index.html IllegalArgumentException isn't a good exception for these cases, is now the time to proposing this too? -Alan From harold.seigel at oracle.com Tue Jan 10 15:18:05 2017 From: harold.seigel at oracle.com (harold seigel) Date: Tue, 10 Jan 2017 10:18:05 -0500 Subject: RFR(S) 8172288: Fix error message when trying to define an existing package to a module In-Reply-To: References: <7926a146-6005-5be0-dc8c-425ab8d5290f@oracle.com> Message-ID: Yes. I'll modify the bug to include that. What exception should the JVM throw for this? Thanks, Harold On 1/10/2017 10:12 AM, Alan Bateman wrote: > On 10/01/2017 15:02, harold seigel wrote: > >> Hi, >> >> Please review this small fix for JDK-8172288. Here's a sample of the >> new message: >> >> Package mypackage6 for module dupl.pkg.module is already in another >> module, Module_A, defined to the class loader >> >> Adding the class loader name to the message will be done as part of >> JDK-8169559 . >> >> Open Webrev: >> http://cr.openjdk.java.net/~hseigel/bug_8172288/webrev/index.html > IllegalArgumentException isn't a good exception for these cases, is > now the time to proposing this too? > > -Alan From Alan.Bateman at oracle.com Tue Jan 10 16:10:50 2017 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 10 Jan 2017 16:10:50 +0000 Subject: RFR(S) 8172288: Fix error message when trying to define an existing package to a module In-Reply-To: References: <7926a146-6005-5be0-dc8c-425ab8d5290f@oracle.com> Message-ID: <7cb04a96-b257-2606-4e7d-8a31b3fa71e2@oracle.com> On 10/01/2017 15:18, harold seigel wrote: > Yes. I'll modify the bug to include that. > > What exception should the JVM throw for this? IllegalStateException might be okay for the cases where the package is already defined to another module. Note that you'll need to change Layer.java and run the tests the java/lang/module tests. We also have changes in jake that are going to have to change too. The other one is "Module java.base is already defined". If we ever get that then the JDK is seriously broken, meaning InternalError but I assume you'd prefer to throw IllegalStateException. -Alan From max.ockner at oracle.com Tue Jan 10 16:16:59 2017 From: max.ockner at oracle.com (Max Ockner) Date: Tue, 10 Jan 2017 11:16:59 -0500 Subject: RFR(S): 8139673: NMT stack traces in output should show mt component Message-ID: <587508FB.9010600@oracle.com> Hello, Please review this small enhancement to NMT detail report. I have added the memory type to the output for each NMT stacktrace. Bug: https://bugs.openjdk.java.net/browse/JDK-8139673 Webrev: http://cr.openjdk.java.net/~mockner/8139673/ The old stacktrace output looks like this: [0x00007f17135fdd93] OSThread::pd_initialize()+0x63 [0x00007f17135fdc7f] OSThread::OSThread(int (*)(void*), void*)+0x2f [0x00007f171360e020] os::create_thread(Thread*, os::ThreadType, unsigned long)+0x80 [0x00007f17139d1d3d] AbstractWorkGang::add_workers(unsigned int, bool)+0x18d (malloc=2KB #10) The new stacktrace output looks like this: [0x00007f17135fdd93] OSThread::pd_initialize()+0x63 [0x00007f17135fdc7f] OSThread::OSThread(int (*)(void*), void*)+0x2f [0x00007f171360e020] os::create_thread(Thread*, os::ThreadType, unsigned long)+0x80 [0x00007f17139d1d3d] AbstractWorkGang::add_workers(unsigned int, bool)+0x18d (malloc=2KB type=Internal #10) Tested with jtreg NMT tests. Thanks, Max From jiangli.zhou at Oracle.COM Tue Jan 10 17:14:39 2017 From: jiangli.zhou at Oracle.COM (Jiangli Zhou) Date: Tue, 10 Jan 2017 09:14:39 -0800 Subject: RFR(S): 8139673: NMT stack traces in output should show mt component In-Reply-To: <587508FB.9010600@oracle.com> References: <587508FB.9010600@oracle.com> Message-ID: <0CF85016-9727-47FB-A606-76BF2E4B9861@oracle.com> Hi Max, Just a few questions for the change. Any reason a new MemReporterBase::print_malloc() is added instead of just changing the existing MemReporterBase::print_malloc() API to include the extra ?flag? argument? The following check in MemDetailReporter::report_malloc_sites() makes me wonder why/when do you get an invalid flag. Should that be an assert? if (!(flag >= 0 && flag < (int)mt_number_of_types)) { flag = mtNone; } Thanks, Jiangli > On Jan 10, 2017, at 8:16 AM, Max Ockner wrote: > > Hello, > Please review this small enhancement to NMT detail report. I have added the memory type to the output for each NMT stacktrace. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8139673 > Webrev: http://cr.openjdk.java.net/~mockner/8139673/ > > The old stacktrace output looks like this: > > [0x00007f17135fdd93] OSThread::pd_initialize()+0x63 > [0x00007f17135fdc7f] OSThread::OSThread(int (*)(void*), void*)+0x2f > [0x00007f171360e020] os::create_thread(Thread*, os::ThreadType, unsigned long)+0x80 > [0x00007f17139d1d3d] AbstractWorkGang::add_workers(unsigned int, bool)+0x18d > (malloc=2KB #10) > > The new stacktrace output looks like this: > > [0x00007f17135fdd93] OSThread::pd_initialize()+0x63 > [0x00007f17135fdc7f] OSThread::OSThread(int (*)(void*), void*)+0x2f > [0x00007f171360e020] os::create_thread(Thread*, os::ThreadType, unsigned long)+0x80 > [0x00007f17139d1d3d] AbstractWorkGang::add_workers(unsigned int, bool)+0x18d > (malloc=2KB type=Internal #10) > > Tested with jtreg NMT tests. > > Thanks, > Max From zgu at redhat.com Tue Jan 10 18:02:09 2017 From: zgu at redhat.com (Zhengyu Gu) Date: Tue, 10 Jan 2017 13:02:09 -0500 Subject: RFR(S): 8139673: NMT stack traces in output should show mt component In-Reply-To: <587508FB.9010600@oracle.com> References: <587508FB.9010600@oracle.com> Message-ID: I don't think that this enhancement makes sense. NMT only records last part of call path that leads memory allocation, which can be shared by many allocation paths and from different sub systems. You are tagging the call site with the type of the first call, I think it can be misleading and incorrect. Thanks, -Zhengyu On 01/10/2017 11:16 AM, Max Ockner wrote: > Hello, > Please review this small enhancement to NMT detail report. I have > added the memory type to the output for each NMT stacktrace. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8139673 > Webrev: http://cr.openjdk.java.net/~mockner/8139673/ > > The old stacktrace output looks like this: > > [0x00007f17135fdd93] OSThread::pd_initialize()+0x63 > [0x00007f17135fdc7f] OSThread::OSThread(int (*)(void*), void*)+0x2f > [0x00007f171360e020] os::create_thread(Thread*, os::ThreadType, > unsigned long)+0x80 > [0x00007f17139d1d3d] AbstractWorkGang::add_workers(unsigned int, > bool)+0x18d > (malloc=2KB #10) > > The new stacktrace output looks like this: > > [0x00007f17135fdd93] OSThread::pd_initialize()+0x63 > [0x00007f17135fdc7f] OSThread::OSThread(int (*)(void*), void*)+0x2f > [0x00007f171360e020] os::create_thread(Thread*, os::ThreadType, > unsigned long)+0x80 > [0x00007f17139d1d3d] AbstractWorkGang::add_workers(unsigned int, > bool)+0x18d > (malloc=2KB type=Internal #10) > > Tested with jtreg NMT tests. > > Thanks, > Max From frederic.parain at oracle.com Tue Jan 10 18:50:54 2017 From: frederic.parain at oracle.com (Frederic Parain) Date: Tue, 10 Jan 2017 13:50:54 -0500 Subject: RFR: 8172144: AArch64: Implement "JEP 270: Reserved Stack Areas for Critical Sections" In-Reply-To: <20fc8f92-9ea0-e853-a53c-b03d0c0f0beb@redhat.com> References: <20fc8f92-9ea0-e853-a53c-b03d0c0f0beb@redhat.com> Message-ID: Changes look good to me. Thank you for implementing the feature on AArch64. Fred On 01/09/2017 01:04 PM, Andrew Haley wrote: > https://bugs.openjdk.java.net/browse/JDK-8172144 > > Needs a sponsor because it enables the test. > > http://cr.openjdk.java.net/~aph/8172144/ > > Andrew. > From stanislav.smirnov at oracle.com Tue Jan 10 18:57:44 2017 From: stanislav.smirnov at oracle.com (Stanislav Smirnov) Date: Tue, 10 Jan 2017 21:57:44 +0300 Subject: RFR: 8172144: AArch64: Implement "JEP 270: Reserved Stack Areas for Critical Sections" In-Reply-To: <20fc8f92-9ea0-e853-a53c-b03d0c0f0beb@redhat.com> References: <20fc8f92-9ea0-e853-a53c-b03d0c0f0beb@redhat.com> Message-ID: I am looking at this line and noticed a minor note, + (Platform.isPPC() || Platform.isS390x() || Platform.isX64() || Platform.isX86()) || Platform.isAArch64()) || shall Platform.isAArch64() be together with ppc/s390x/x64/x86 conditions? Because right now it is outside. Best regards, Stanislav Smirnov > On 09 Jan 2017, at 21:04, Andrew Haley wrote: > > https://bugs.openjdk.java.net/browse/JDK-8172144 > > Needs a sponsor because it enables the test. > > http://cr.openjdk.java.net/~aph/8172144/ > > Andrew. From aph at redhat.com Tue Jan 10 18:57:49 2017 From: aph at redhat.com (Andrew Haley) Date: Tue, 10 Jan 2017 18:57:49 +0000 Subject: RFR: 8172144: AArch64: Implement "JEP 270: Reserved Stack Areas for Critical Sections" In-Reply-To: References: <20fc8f92-9ea0-e853-a53c-b03d0c0f0beb@redhat.com> Message-ID: <909fe08a-58bc-3e26-2fb5-8112b31a66ec@redhat.com> On 10/01/17 18:57, Stanislav Smirnov wrote: > shall Platform.isAArch64() be together with ppc/s390x/x64/x86 conditions? Because right now it is outside. Thanks! Andrew. From ioi.lam at oracle.com Tue Jan 10 19:30:49 2017 From: ioi.lam at oracle.com (Ioi Lam) Date: Tue, 10 Jan 2017 11:30:49 -0800 Subject: RFR: 8079441: Intermittent failures on Windows with "Unexpected exit from test [exit code: 1080890248]" (0x406d1388) In-Reply-To: <2b83c373-d196-58b7-d757-eaff2b8931e3@oracle.com> References: <2b83c373-d196-58b7-d757-eaff2b8931e3@oracle.com> Message-ID: <58753669.7090500@oracle.com> Looks good to me. Thanks - Ioi On 1/10/17 2:14 AM, Robbin Ehn wrote: > Hi all, please review. > > We still have exit code 1080890248/0x406d1388 on windows when running > kitchensink. > Since this is the same value as windows thread name exception: > http://msdn.microsoft.com/en-us/library/xcb2z8hs.aspx > and we are still suspicious about this. > > This is not a bug fix per se, but it will determine if this exception > is the cause of this > and if so only when a debugger is attached this failure can happen. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8079441 > > Tested with windbg and passes winx64 hotspot_jprt. > > /Robbin > > --- a/src/os/windows/vm/os_windows.cpp Mon Jan 09 19:36:47 2017 +0000 > +++ b/src/os/windows/vm/os_windows.cpp Tue Jan 10 11:00:45 2017 +0100 > @@ -777,6 +777,11 @@ > // Note that unfortunately this only works if the process > // is already attached to a debugger; debugger must observe > // the exception below to show the correct name. > + > + // If there is no debugger attached skip raising the exception > + if (!IsDebuggerPresent()) { > + return; > + } > > const DWORD MS_VC_EXCEPTION = 0x406D1388; > struct { From chris.plummer at oracle.com Wed Jan 11 04:20:01 2017 From: chris.plummer at oracle.com (Chris Plummer) Date: Tue, 10 Jan 2017 20:20:01 -0800 Subject: RFR(S): 8139673: NMT stack traces in output should show mt component In-Reply-To: References: <587508FB.9010600@oracle.com> Message-ID: <72f921ca-ea9b-a367-67e6-435407df486d@oracle.com> Hi Zhengyu, I think in theory you are right, but in practice probably each call site is always using the same allocation type, as long as we are going at least 4 frames back. If 4 frames is not enough, then either we should be going back more frames, or we are not skipping enough frames in some cases. thanks, Chris On 1/10/17 10:02 AM, Zhengyu Gu wrote: > I don't think that this enhancement makes sense. NMT only records last > part of call path that leads memory allocation, which can be shared by > many allocation paths and from > different sub systems. > > You are tagging the call site with the type of the first call, I think > it can be misleading and incorrect. > > Thanks, > > -Zhengyu > > > > > > On 01/10/2017 11:16 AM, Max Ockner wrote: >> Hello, >> Please review this small enhancement to NMT detail report. I have >> added the memory type to the output for each NMT stacktrace. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8139673 >> Webrev: http://cr.openjdk.java.net/~mockner/8139673/ >> >> The old stacktrace output looks like this: >> >> [0x00007f17135fdd93] OSThread::pd_initialize()+0x63 >> [0x00007f17135fdc7f] OSThread::OSThread(int (*)(void*), void*)+0x2f >> [0x00007f171360e020] os::create_thread(Thread*, os::ThreadType, >> unsigned long)+0x80 >> [0x00007f17139d1d3d] AbstractWorkGang::add_workers(unsigned int, >> bool)+0x18d >> (malloc=2KB #10) >> >> The new stacktrace output looks like this: >> >> [0x00007f17135fdd93] OSThread::pd_initialize()+0x63 >> [0x00007f17135fdc7f] OSThread::OSThread(int (*)(void*), void*)+0x2f >> [0x00007f171360e020] os::create_thread(Thread*, os::ThreadType, >> unsigned long)+0x80 >> [0x00007f17139d1d3d] AbstractWorkGang::add_workers(unsigned int, >> bool)+0x18d >> (malloc=2KB type=Internal #10) >> >> Tested with jtreg NMT tests. >> >> Thanks, >> Max > From chris.plummer at oracle.com Wed Jan 11 04:26:41 2017 From: chris.plummer at oracle.com (Chris Plummer) Date: Tue, 10 Jan 2017 20:26:41 -0800 Subject: RFR(S): 8139673: NMT stack traces in output should show mt component In-Reply-To: <0CF85016-9727-47FB-A606-76BF2E4B9861@oracle.com> References: <587508FB.9010600@oracle.com> <0CF85016-9727-47FB-A606-76BF2E4B9861@oracle.com> Message-ID: Hi Max, Changes look good to me except for what Jiangli noted below, and also you need to update the copyrights. Also, I assume this is going in 10, not 9. thanks, Chris On 1/10/17 9:14 AM, Jiangli Zhou wrote: > Hi Max, > > Just a few questions for the change. > > Any reason a new MemReporterBase::print_malloc() is added instead of just changing the existing MemReporterBase::print_malloc() API to include the extra ?flag? argument? > > The following check in MemDetailReporter::report_malloc_sites() makes me wonder why/when do you get an invalid flag. Should that be an assert? > > if (!(flag >= 0 && flag < (int)mt_number_of_types)) { > flag = mtNone; > } > > Thanks, > Jiangli > >> On Jan 10, 2017, at 8:16 AM, Max Ockner wrote: >> >> Hello, >> Please review this small enhancement to NMT detail report. I have added the memory type to the output for each NMT stacktrace. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8139673 >> Webrev: http://cr.openjdk.java.net/~mockner/8139673/ >> >> The old stacktrace output looks like this: >> >> [0x00007f17135fdd93] OSThread::pd_initialize()+0x63 >> [0x00007f17135fdc7f] OSThread::OSThread(int (*)(void*), void*)+0x2f >> [0x00007f171360e020] os::create_thread(Thread*, os::ThreadType, unsigned long)+0x80 >> [0x00007f17139d1d3d] AbstractWorkGang::add_workers(unsigned int, bool)+0x18d >> (malloc=2KB #10) >> >> The new stacktrace output looks like this: >> >> [0x00007f17135fdd93] OSThread::pd_initialize()+0x63 >> [0x00007f17135fdc7f] OSThread::OSThread(int (*)(void*), void*)+0x2f >> [0x00007f171360e020] os::create_thread(Thread*, os::ThreadType, unsigned long)+0x80 >> [0x00007f17139d1d3d] AbstractWorkGang::add_workers(unsigned int, bool)+0x18d >> (malloc=2KB type=Internal #10) >> >> Tested with jtreg NMT tests. >> >> Thanks, >> Max From robbin.ehn at oracle.com Wed Jan 11 08:54:38 2017 From: robbin.ehn at oracle.com (Robbin Ehn) Date: Wed, 11 Jan 2017 09:54:38 +0100 Subject: RFR: 8079441: Intermittent failures on Windows with "Unexpected exit from test [exit code: 1080890248]" (0x406d1388) In-Reply-To: <58753669.7090500@oracle.com> References: <2b83c373-d196-58b7-d757-eaff2b8931e3@oracle.com> <58753669.7090500@oracle.com> Message-ID: Thanks Ioi! /Robbin On 01/10/2017 08:30 PM, Ioi Lam wrote: > Looks good to me. > > Thanks > - Ioi > > On 1/10/17 2:14 AM, Robbin Ehn wrote: >> Hi all, please review. >> >> We still have exit code 1080890248/0x406d1388 on windows when running kitchensink. >> Since this is the same value as windows thread name exception: >> http://msdn.microsoft.com/en-us/library/xcb2z8hs.aspx >> and we are still suspicious about this. >> >> This is not a bug fix per se, but it will determine if this exception is the cause of this >> and if so only when a debugger is attached this failure can happen. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8079441 >> >> Tested with windbg and passes winx64 hotspot_jprt. >> >> /Robbin >> >> --- a/src/os/windows/vm/os_windows.cpp Mon Jan 09 19:36:47 2017 +0000 >> +++ b/src/os/windows/vm/os_windows.cpp Tue Jan 10 11:00:45 2017 +0100 >> @@ -777,6 +777,11 @@ >> // Note that unfortunately this only works if the process >> // is already attached to a debugger; debugger must observe >> // the exception below to show the correct name. >> + >> + // If there is no debugger attached skip raising the exception >> + if (!IsDebuggerPresent()) { >> + return; >> + } >> >> const DWORD MS_VC_EXCEPTION = 0x406D1388; >> struct { > From zgu at redhat.com Wed Jan 11 12:55:20 2017 From: zgu at redhat.com (Zhengyu Gu) Date: Wed, 11 Jan 2017 07:55:20 -0500 Subject: RFR(S): 8139673: NMT stack traces in output should show mt component In-Reply-To: <72f921ca-ea9b-a367-67e6-435407df486d@oracle.com> References: <587508FB.9010600@oracle.com> <72f921ca-ea9b-a367-67e6-435407df486d@oracle.com> Message-ID: <6d625ae5-640f-bfb1-9a2f-c16a149b60e9@redhat.com> Hi Chris, I am not convinced that 4 frames is sufficient, and skipping more frames can result ambiguous path. Or you may want to consider "OR" the memory types in the allocation site record, so it at least can report all possible memory types at this particular site. Thanks, -Zhengyu On 01/10/2017 11:20 PM, Chris Plummer wrote: > Hi Zhengyu, > > I think in theory you are right, but in practice probably each call > site is always using the same allocation type, as long as we are going > at least 4 frames back. If 4 frames is not enough, then either we > should be going back more frames, or we are not skipping enough frames > in some cases. > > thanks, > > Chris > > On 1/10/17 10:02 AM, Zhengyu Gu wrote: >> I don't think that this enhancement makes sense. NMT only records >> last part of call path that leads memory allocation, which can be >> shared by many allocation paths and from >> different sub systems. >> >> You are tagging the call site with the type of the first call, I >> think it can be misleading and incorrect. >> >> Thanks, >> >> -Zhengyu >> >> >> >> >> >> On 01/10/2017 11:16 AM, Max Ockner wrote: >>> Hello, >>> Please review this small enhancement to NMT detail report. I have >>> added the memory type to the output for each NMT stacktrace. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8139673 >>> Webrev: http://cr.openjdk.java.net/~mockner/8139673/ >>> >>> The old stacktrace output looks like this: >>> >>> [0x00007f17135fdd93] OSThread::pd_initialize()+0x63 >>> [0x00007f17135fdc7f] OSThread::OSThread(int (*)(void*), void*)+0x2f >>> [0x00007f171360e020] os::create_thread(Thread*, os::ThreadType, >>> unsigned long)+0x80 >>> [0x00007f17139d1d3d] AbstractWorkGang::add_workers(unsigned int, >>> bool)+0x18d >>> (malloc=2KB #10) >>> >>> The new stacktrace output looks like this: >>> >>> [0x00007f17135fdd93] OSThread::pd_initialize()+0x63 >>> [0x00007f17135fdc7f] OSThread::OSThread(int (*)(void*), void*)+0x2f >>> [0x00007f171360e020] os::create_thread(Thread*, os::ThreadType, >>> unsigned long)+0x80 >>> [0x00007f17139d1d3d] AbstractWorkGang::add_workers(unsigned int, >>> bool)+0x18d >>> (malloc=2KB type=Internal #10) >>> >>> Tested with jtreg NMT tests. >>> >>> Thanks, >>> Max >> > From coleen.phillimore at oracle.com Wed Jan 11 14:13:44 2017 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Wed, 11 Jan 2017 09:13:44 -0500 Subject: RFR(S): 8139673: NMT stack traces in output should show mt component In-Reply-To: <6d625ae5-640f-bfb1-9a2f-c16a149b60e9@redhat.com> References: <587508FB.9010600@oracle.com> <72f921ca-ea9b-a367-67e6-435407df486d@oracle.com> <6d625ae5-640f-bfb1-9a2f-c16a149b60e9@redhat.com> Message-ID: <433f4c03-43ec-b0f4-8405-0f0b5db98e88@oracle.com> I wonder if you can lookup the memory type with the stack trace in the MallocSiteTable before creating a new one. Have the hash function include the mtType. Coleen On 1/11/17 7:55 AM, Zhengyu Gu wrote: > Hi Chris, > > I am not convinced that 4 frames is sufficient, and skipping more > frames can result ambiguous path. > > Or you may want to consider "OR" the memory types in the allocation > site record, so it at least can report all possible memory types at > this particular site. > > Thanks, > > -Zhengyu > > > On 01/10/2017 11:20 PM, Chris Plummer wrote: >> Hi Zhengyu, >> >> I think in theory you are right, but in practice probably each call >> site is always using the same allocation type, as long as we are >> going at least 4 frames back. If 4 frames is not enough, then either >> we should be going back more frames, or we are not skipping enough >> frames in some cases. >> >> thanks, >> >> Chris >> >> On 1/10/17 10:02 AM, Zhengyu Gu wrote: >>> I don't think that this enhancement makes sense. NMT only records >>> last part of call path that leads memory allocation, which can be >>> shared by many allocation paths and from >>> different sub systems. >>> >>> You are tagging the call site with the type of the first call, I >>> think it can be misleading and incorrect. >>> >>> Thanks, >>> >>> -Zhengyu >>> >>> >>> >>> >>> >>> On 01/10/2017 11:16 AM, Max Ockner wrote: >>>> Hello, >>>> Please review this small enhancement to NMT detail report. I have >>>> added the memory type to the output for each NMT stacktrace. >>>> >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8139673 >>>> Webrev: http://cr.openjdk.java.net/~mockner/8139673/ >>>> >>>> The old stacktrace output looks like this: >>>> >>>> [0x00007f17135fdd93] OSThread::pd_initialize()+0x63 >>>> [0x00007f17135fdc7f] OSThread::OSThread(int (*)(void*), void*)+0x2f >>>> [0x00007f171360e020] os::create_thread(Thread*, os::ThreadType, >>>> unsigned long)+0x80 >>>> [0x00007f17139d1d3d] AbstractWorkGang::add_workers(unsigned int, >>>> bool)+0x18d >>>> (malloc=2KB #10) >>>> >>>> The new stacktrace output looks like this: >>>> >>>> [0x00007f17135fdd93] OSThread::pd_initialize()+0x63 >>>> [0x00007f17135fdc7f] OSThread::OSThread(int (*)(void*), void*)+0x2f >>>> [0x00007f171360e020] os::create_thread(Thread*, os::ThreadType, >>>> unsigned long)+0x80 >>>> [0x00007f17139d1d3d] AbstractWorkGang::add_workers(unsigned int, >>>> bool)+0x18d >>>> (malloc=2KB type=Internal #10) >>>> >>>> Tested with jtreg NMT tests. >>>> >>>> Thanks, >>>> Max >>> >> > From zgu at redhat.com Wed Jan 11 14:48:29 2017 From: zgu at redhat.com (Zhengyu Gu) Date: Wed, 11 Jan 2017 09:48:29 -0500 Subject: RFR(S): 8139673: NMT stack traces in output should show mt component In-Reply-To: <433f4c03-43ec-b0f4-8405-0f0b5db98e88@oracle.com> References: <587508FB.9010600@oracle.com> <72f921ca-ea9b-a367-67e6-435407df486d@oracle.com> <6d625ae5-640f-bfb1-9a2f-c16a149b60e9@redhat.com> <433f4c03-43ec-b0f4-8405-0f0b5db98e88@oracle.com> Message-ID: <610ed1cf-8d85-e8b4-f02e-3878cacca5af@redhat.com> Yes, this can work! Thanks, -Zhengyu On 01/11/2017 09:13 AM, Coleen Phillimore wrote: > I wonder if you can lookup the memory type with the stack trace in the > MallocSiteTable before creating a new one. Have the hash function > include the mtType. > Coleen > > > On 1/11/17 7:55 AM, Zhengyu Gu wrote: >> Hi Chris, >> >> I am not convinced that 4 frames is sufficient, and skipping more >> frames can result ambiguous path. >> >> Or you may want to consider "OR" the memory types in the allocation >> site record, so it at least can report all possible memory types at >> this particular site. >> >> Thanks, >> >> -Zhengyu >> >> >> On 01/10/2017 11:20 PM, Chris Plummer wrote: >>> Hi Zhengyu, >>> >>> I think in theory you are right, but in practice probably each call >>> site is always using the same allocation type, as long as we are >>> going at least 4 frames back. If 4 frames is not enough, then either >>> we should be going back more frames, or we are not skipping enough >>> frames in some cases. >>> >>> thanks, >>> >>> Chris >>> >>> On 1/10/17 10:02 AM, Zhengyu Gu wrote: >>>> I don't think that this enhancement makes sense. NMT only records >>>> last part of call path that leads memory allocation, which can be >>>> shared by many allocation paths and from >>>> different sub systems. >>>> >>>> You are tagging the call site with the type of the first call, I >>>> think it can be misleading and incorrect. >>>> >>>> Thanks, >>>> >>>> -Zhengyu >>>> >>>> >>>> >>>> >>>> >>>> On 01/10/2017 11:16 AM, Max Ockner wrote: >>>>> Hello, >>>>> Please review this small enhancement to NMT detail report. I have >>>>> added the memory type to the output for each NMT stacktrace. >>>>> >>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8139673 >>>>> Webrev: http://cr.openjdk.java.net/~mockner/8139673/ >>>>> >>>>> The old stacktrace output looks like this: >>>>> >>>>> [0x00007f17135fdd93] OSThread::pd_initialize()+0x63 >>>>> [0x00007f17135fdc7f] OSThread::OSThread(int (*)(void*), void*)+0x2f >>>>> [0x00007f171360e020] os::create_thread(Thread*, os::ThreadType, >>>>> unsigned long)+0x80 >>>>> [0x00007f17139d1d3d] AbstractWorkGang::add_workers(unsigned int, >>>>> bool)+0x18d >>>>> (malloc=2KB #10) >>>>> >>>>> The new stacktrace output looks like this: >>>>> >>>>> [0x00007f17135fdd93] OSThread::pd_initialize()+0x63 >>>>> [0x00007f17135fdc7f] OSThread::OSThread(int (*)(void*), void*)+0x2f >>>>> [0x00007f171360e020] os::create_thread(Thread*, os::ThreadType, >>>>> unsigned long)+0x80 >>>>> [0x00007f17139d1d3d] AbstractWorkGang::add_workers(unsigned int, >>>>> bool)+0x18d >>>>> (malloc=2KB type=Internal #10) >>>>> >>>>> Tested with jtreg NMT tests. >>>>> >>>>> Thanks, >>>>> Max >>>> >>> >> > From rachel.protacio at oracle.com Wed Jan 11 15:25:17 2017 From: rachel.protacio at oracle.com (Rachel Protacio) Date: Wed, 11 Jan 2017 10:25:17 -0500 Subject: RFR: 8170821: Ensure access checks result in consistent answers In-Reply-To: <89aa93f3-3afd-9d01-49cd-893b1594c2a0@oracle.com> References: <9944787a-8e04-95c1-b1fc-5d718cadf873@oracle.com> <89aa93f3-3afd-9d01-49cd-893b1594c2a0@oracle.com> Message-ID: <68905b4b-68d5-78e9-a54a-57e3f20cd3c6@oracle.com> Hello! I've updated this changeset, if anyone wouldn't mind reviewing it again. http://cr.openjdk.java.net/~rprotacio/8170821.02 Changes: - updated AccessExportTwice.java (previously "AccessTwice.java") because of API changes - corrected some comments - added AccessReadTwice.java test that ensures constant answers when IAE is due to readability (AccessExportTwice checks for exportedness) Tested with JPRT. Thanks! Rachel On 12/9/2016 10:13 AM, Rachel Protacio wrote: > Thanks, Harold - > > New webrev: http://cr.openjdk.java.net/~rprotacio/8170821.01/ > > > On 12/9/2016 9:09 AM, harold seigel wrote: >> Hi Rachel, >> >> The test looks good, lots of good comments. Just a couple of questions. >> >> 1. Does the test need to be run with -Xlog:modules=debug ? > No, not really. It was there because it was helpful in the case that > the test fails, but you're right, it's extra effort/output now. I've > removed it. >> >> 2. Is -Xbootclasspath/a:. needed ? > Nope, deleted that too. > Thanks! > Rachel >> >> Thanks, Harold >> >> >> On 12/8/2016 4:18 PM, Rachel Protacio wrote: >>> Hello! >>> >>> Please review this change adding a jtreg test to ensure that access >>> check results are cached, so the same check produces the same answer >>> even if the user adds access in between. (Credit to Lois for the >>> actual workings of the test.) >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8170821 >>> Open webrev: http://cr.openjdk.java.net/~rprotacio/8170821.00/ >>> >>> Passes JPRT on all platforms. >>> >>> Thanks, >>> Rachel >>> >> > From chris.plummer at oracle.com Wed Jan 11 17:34:14 2017 From: chris.plummer at oracle.com (Chris Plummer) Date: Wed, 11 Jan 2017 09:34:14 -0800 Subject: RFR(S): 8139673: NMT stack traces in output should show mt component In-Reply-To: <6d625ae5-640f-bfb1-9a2f-c16a149b60e9@redhat.com> References: <587508FB.9010600@oracle.com> <72f921ca-ea9b-a367-67e6-435407df486d@oracle.com> <6d625ae5-640f-bfb1-9a2f-c16a149b60e9@redhat.com> Message-ID: <71f1bcc3-59d0-8817-5ec5-314e700d0082@oracle.com> Hi Zhengyu, My suggestion for skipping more frames wasn't intended to be generally applied to all cases. I suspect that if 4 frames is ever not enough, then likely that particular case where it is not enough should have additional frames skipped. In other words, it would be appropriate to skip additional frames, even if Max was not making this change. thanks, Chris On 1/11/17 4:55 AM, Zhengyu Gu wrote: > Hi Chris, > > I am not convinced that 4 frames is sufficient, and skipping more > frames can result ambiguous path. > > Or you may want to consider "OR" the memory types in the allocation > site record, so it at least can report all possible memory types at > this particular site. > > Thanks, > > -Zhengyu > > > On 01/10/2017 11:20 PM, Chris Plummer wrote: >> Hi Zhengyu, >> >> I think in theory you are right, but in practice probably each call >> site is always using the same allocation type, as long as we are >> going at least 4 frames back. If 4 frames is not enough, then either >> we should be going back more frames, or we are not skipping enough >> frames in some cases. >> >> thanks, >> >> Chris >> >> On 1/10/17 10:02 AM, Zhengyu Gu wrote: >>> I don't think that this enhancement makes sense. NMT only records >>> last part of call path that leads memory allocation, which can be >>> shared by many allocation paths and from >>> different sub systems. >>> >>> You are tagging the call site with the type of the first call, I >>> think it can be misleading and incorrect. >>> >>> Thanks, >>> >>> -Zhengyu >>> >>> >>> >>> >>> >>> On 01/10/2017 11:16 AM, Max Ockner wrote: >>>> Hello, >>>> Please review this small enhancement to NMT detail report. I have >>>> added the memory type to the output for each NMT stacktrace. >>>> >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8139673 >>>> Webrev: http://cr.openjdk.java.net/~mockner/8139673/ >>>> >>>> The old stacktrace output looks like this: >>>> >>>> [0x00007f17135fdd93] OSThread::pd_initialize()+0x63 >>>> [0x00007f17135fdc7f] OSThread::OSThread(int (*)(void*), void*)+0x2f >>>> [0x00007f171360e020] os::create_thread(Thread*, os::ThreadType, >>>> unsigned long)+0x80 >>>> [0x00007f17139d1d3d] AbstractWorkGang::add_workers(unsigned int, >>>> bool)+0x18d >>>> (malloc=2KB #10) >>>> >>>> The new stacktrace output looks like this: >>>> >>>> [0x00007f17135fdd93] OSThread::pd_initialize()+0x63 >>>> [0x00007f17135fdc7f] OSThread::OSThread(int (*)(void*), void*)+0x2f >>>> [0x00007f171360e020] os::create_thread(Thread*, os::ThreadType, >>>> unsigned long)+0x80 >>>> [0x00007f17139d1d3d] AbstractWorkGang::add_workers(unsigned int, >>>> bool)+0x18d >>>> (malloc=2KB type=Internal #10) >>>> >>>> Tested with jtreg NMT tests. >>>> >>>> Thanks, >>>> Max >>> >> > From chris.plummer at oracle.com Wed Jan 11 17:42:31 2017 From: chris.plummer at oracle.com (Chris Plummer) Date: Wed, 11 Jan 2017 09:42:31 -0800 Subject: RFR(S): 8139673: NMT stack traces in output should show mt component In-Reply-To: <433f4c03-43ec-b0f4-8405-0f0b5db98e88@oracle.com> References: <587508FB.9010600@oracle.com> <72f921ca-ea9b-a367-67e6-435407df486d@oracle.com> <6d625ae5-640f-bfb1-9a2f-c16a149b60e9@redhat.com> <433f4c03-43ec-b0f4-8405-0f0b5db98e88@oracle.com> Message-ID: <2e77dbcd-bab8-86e9-e43d-c5e39204fe1e@oracle.com> I would suggest doing a test run with a check to see if this is even needed. The call sites are static, so if you are sufficiently testing NMT, then you should hit every call site that uses NMT. Chris On 1/11/17 6:13 AM, Coleen Phillimore wrote: > I wonder if you can lookup the memory type with the stack trace in the > MallocSiteTable before creating a new one. Have the hash function > include the mtType. > Coleen > > > On 1/11/17 7:55 AM, Zhengyu Gu wrote: >> Hi Chris, >> >> I am not convinced that 4 frames is sufficient, and skipping more >> frames can result ambiguous path. >> >> Or you may want to consider "OR" the memory types in the allocation >> site record, so it at least can report all possible memory types at >> this particular site. >> >> Thanks, >> >> -Zhengyu >> >> >> On 01/10/2017 11:20 PM, Chris Plummer wrote: >>> Hi Zhengyu, >>> >>> I think in theory you are right, but in practice probably each call >>> site is always using the same allocation type, as long as we are >>> going at least 4 frames back. If 4 frames is not enough, then either >>> we should be going back more frames, or we are not skipping enough >>> frames in some cases. >>> >>> thanks, >>> >>> Chris >>> >>> On 1/10/17 10:02 AM, Zhengyu Gu wrote: >>>> I don't think that this enhancement makes sense. NMT only records >>>> last part of call path that leads memory allocation, which can be >>>> shared by many allocation paths and from >>>> different sub systems. >>>> >>>> You are tagging the call site with the type of the first call, I >>>> think it can be misleading and incorrect. >>>> >>>> Thanks, >>>> >>>> -Zhengyu >>>> >>>> >>>> >>>> >>>> >>>> On 01/10/2017 11:16 AM, Max Ockner wrote: >>>>> Hello, >>>>> Please review this small enhancement to NMT detail report. I have >>>>> added the memory type to the output for each NMT stacktrace. >>>>> >>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8139673 >>>>> Webrev: http://cr.openjdk.java.net/~mockner/8139673/ >>>>> >>>>> The old stacktrace output looks like this: >>>>> >>>>> [0x00007f17135fdd93] OSThread::pd_initialize()+0x63 >>>>> [0x00007f17135fdc7f] OSThread::OSThread(int (*)(void*), void*)+0x2f >>>>> [0x00007f171360e020] os::create_thread(Thread*, os::ThreadType, >>>>> unsigned long)+0x80 >>>>> [0x00007f17139d1d3d] AbstractWorkGang::add_workers(unsigned int, >>>>> bool)+0x18d >>>>> (malloc=2KB #10) >>>>> >>>>> The new stacktrace output looks like this: >>>>> >>>>> [0x00007f17135fdd93] OSThread::pd_initialize()+0x63 >>>>> [0x00007f17135fdc7f] OSThread::OSThread(int (*)(void*), void*)+0x2f >>>>> [0x00007f171360e020] os::create_thread(Thread*, os::ThreadType, >>>>> unsigned long)+0x80 >>>>> [0x00007f17139d1d3d] AbstractWorkGang::add_workers(unsigned int, >>>>> bool)+0x18d >>>>> (malloc=2KB type=Internal #10) >>>>> >>>>> Tested with jtreg NMT tests. >>>>> >>>>> Thanks, >>>>> Max >>>> >>> >> > From chris.plummer at oracle.com Wed Jan 11 17:53:47 2017 From: chris.plummer at oracle.com (Chris Plummer) Date: Wed, 11 Jan 2017 09:53:47 -0800 Subject: RFR(M) 8155980: ARM InterpreterMacroAssembler::get_method_counters() should not be saving callee saved registers In-Reply-To: <565d92d9-a254-3ffe-4775-64ad260b37a6@oracle.com> References: <70a61ffa-5d95-ae4f-2077-157f791675ec@oracle.com> <565d92d9-a254-3ffe-4775-64ad260b37a6@oracle.com> Message-ID: <21af92a7-7d33-eecf-5ae2-5b8871baf435@oracle.com> Here are a couple of different solutions: This first one uses an alternate branch label. It also adds saving Rbumped_taken_count on AARCH64. Changes since the first solution are only in templateTable_arm.cpp. http://cr.openjdk.java.net/~cjplummer/8155980/webrev.03/webrev.hotspot This second one moves the save/restore logic into get_method_counters(). The registers to save have to be passed in. It also adds saving Rbumped_taken_count on AARCH64. Changes since the first solution are in templateTable_arm.cpp, interp_masm_arm.cpp, and interp_masm_arm.hpp. http://cr.openjdk.java.net/~cjplummer/8155980/webrev.04/webrev.hotspot I think overall the second one looks cleaner. Save/restore logic is all in one place, and is only done if call_VM() generated code is actually executed. Possibly the handling of the Rbumped_taken_count could be better to make it clear it's just for AARCH64. Maybe I could use AARCH64_ONLY around the argument declaration and passing. thanks, Chris On 1/9/17 12:18 PM, Chris Plummer wrote: > Sigh, there's a bug in the following: > > #ifdef AARCH64 > __ stp(Rdisp, R3_bytecode, Address(Rstack_top, -2*wordSize, > pre_indexed)); > #else > __ push(RegisterSet(Rdisp) | RegisterSet(R3_bytecode)); > #endif > __ get_method_counters(Rmethod, Rcounters, dispatch); > #ifdef AARCH64 > __ ldp(Rdisp, R3_bytecode, Address(Rstack_top, 2*wordSize, > post_indexed)); > #else > __ pop(RegisterSet(Rdisp) | RegisterSet(R3_bytecode)); > #endif > > Note that the "dispatch" label is passed to get_method_counters(), and > it will generate code that branches to it, thus by passing the pop. > Need to rethink this. I might need to introduce a new label just > before the dispatch label that will do the pop. The other choice is > possibly get_method_counters() should be told which registers to save. > > BTW, while looking over this code more carefully, it looks like for > AARCH64, r5 also needs to be saved and restored. It's volatile on > AARCH64, and is being used to store Rbumped_taken_count. > > Chris > > On 1/9/17 9:08 AM, Chris Plummer wrote: >> Thanks Dean. Unfortunately I got a crash over the weekend when >> repeatedly running one of our test suites. Happens about 1 out of 10 >> times on both 32-bit and 64-bit. Looking into it now. >> >> Chris >> >> On 1/6/17 3:57 PM, dean.long at oracle.com wrote: >>> It looks good but you might want to add a comment in >>> TemplateTable::branch() saying something like: >>> >>> // save and restore caller-saved registers that will be trashed by >>> call_VM >>> >>> dl >>> >>> >>> On 1/6/17 3:14 PM, Chris Plummer wrote: >>>> Hello, >>>> >>>> Please review the following arm changes. They will be pushed to JDK >>>> 10 only (when it opens). >>>> >>>> https://bugs.openjdk.java.net/browse/JDK-8155980 >>>> http://cr.openjdk.java.net/~cjplummer/8155980/webrev.02/webrev.hotspot >>>> >>>> JDK-8012544 added a bunch of callee register saving to >>>> InterpreterMacroAssembler::get_method_counters() around the >>>> call_VM() call. The reason is because there are a couple of callers >>>> of get_method_counters() that need to have r0 and r3 preserved. >>>> get_method_counters() should not be responsible for having to save >>>> callee saved registers. It does not know which ones are in use when >>>> it is called, so it can't do this efficiently. In fact 2 of the 4 >>>> callers of get_method_counters() do not need any registers saved. >>>> For this reason the callee of get_method_counters() should be >>>> responsible for saving callee registers. >>>> >>>> This solution would have been been pretty straight forward, except >>>> that AARCH64 does not allow SP to go above extended_sp, so when >>>> setting up extended_sp I needed to make sure there will be room for >>>> the 2 registers that need to be pushed. extended_sp is mainly based >>>> on max_stack() for the method, plus an extra slot for jsr292 and >>>> exception handling (but not both at the same time). So the fix here >>>> is mostly about making sure there are always at least 2 extra slots >>>> for pushing the 2 registers. >>>> >>>> Here are the changes: >>>> >>>> interp_masm_arm.cpp >>>> -No longer save/restore registers in get_method_counters(): >>>> >>>> templateTable_arm.cpp: >>>> -Save/restore Rdisp and R3_bytecode to stack around calls to >>>> get_method_counters. >>>> >>>> abstractinterpreter__arm.cpp:: >>>> -Properly account for extra 2 slots needed on AARCH64 when >>>> creating a frame >>>> in layout_activation() >>>> -Note I switched to using method->constMethod()->max_stack() because >>>> method->max_stack() includes Method::extra_stack_entries(), and >>>> I want to >>>> account for Method::extra_stack_entries() separately. >>>> >>>> templateInterpreterGenerator_arm.cpp: >>>> -Properly account for extra 2 slots needed on AARCH64 when >>>> creating a frame >>>> in generate_normal_entry(). >>>> >>>> I've tested the following with -Xcomp and with -Xmixed on arm32 and >>>> arm64: >>>> >>>> Kitchensink >>>> vm.mlvm >>>> :jdk_svc >>>> :hotspot_runtime >>>> :hotspot_serviceability >>>> :hotspot_compiler >>>> :jdk_lang >>>> :jdk_util >>>> >>>> I also tested the test case from JDK-8012544. >>>> >>>> thanks, >>>> >>>> Chris >>>> >>>> >>> >> > From thomas.stuefe at gmail.com Thu Jan 12 09:23:27 2017 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Thu, 12 Jan 2017 10:23:27 +0100 Subject: RFR(m): 8170933: Cleanup Metaspace Chunk manager: Unify treatment of humongous and non-humongous chunks In-Reply-To: References: Message-ID: Could I have a review please? Or should I wait until jdk 10? Thanks and Kind Regards, Thomas On Thu, Dec 15, 2016 at 8:12 AM, Thomas St?fe wrote: > Dear all, > > please take a look at this change. > > Issue: https://bugs.openjdk.java.net/browse/JDK-8170933 > webrev: http://cr.openjdk.java.net/~stuefe/webrevs/8170933- > unify-treatment-of-humongous-and-non-humongous-chunks-on- > chunkmanager-return/webrev.00/webrev/ > > This is a change destined for the upcoming jdk10, but I nevertheless hope > to get some reviews in already. > > This is a follow up for a request by Mikael Gerdin when reviewing > JDK-8170520 "Make Metaspace ChunkManager counters non-atomic". He suggested > consolidating the chunk return process for humongous and non-humongous > chunks (see http://mail.openjdk.java.net/pipermail/hotspot-runtime- > dev/2016-November/021946.html) > > Before, humongous chunks were returned in ~SpaceManager to the > ChunkManager-internal dictionary. Non-Humongous chunk returns were already > handled by the ChunkManager itself. That was code duplication and also > required exposing ChunkManager internals to the outside. > > Now, the ChunkManager itself handles returning of both humongous and > non-humongous chunks. That allowed us to hide a lot of ChunkManager > internals from the outside: both freelists (for the non-humongous chunks) > and dictionary (for the humongous chunks) and their accessor methods are > now private. > > Note that this change preceedes my proposed change for JDK-8170520 in > order to make coding for JDK-8170520 simpler. So, this change should apply > to jdk9/hs without needing any preceeding patches. > > Implementation details: > > There are now two functions: ChunkManager::return_single_chunk() and > ChunkManager::return_chunk_list(). I split them because we have a place > where we return single chunks (when retiring VirtualSpaceNode) and because > it felt cleaner to separate chain handling and returning chunks. > > I would have actually preferred to get rid of the ChunkIndex parameter in > ChunkManager::return_single_chunk() and ::return_chunk_list() - just hand > down a Metachunk* or a chunk list and let the ChunkManager find out each > time the ChunkIndex for the returned chunk. That would have made the code > simpler in exchange for a little bit of performance loss. But because I > could not estimate the performance costs of determining the index for every > chunk instead of the chunk list, I refrained from this. > > In order to make the ChunkManager-internal freelists private, I added a > method ChunkManager::size_by_index(), which returns chunk size for a given > index. This is the reverse of the already existing > ChunkManager::list_index(), which returns index by chunk size. Would have > liked to rename list_index() to something like index_by_size() but wanted > to keep the change small. > > I attempted to preserve the logging where possible, and where I had to > change it, to make it better. So it will not look exactly the same as > before. In particular, it may be a bit more verbose. > > I added a number of gtests to test the ChunkManager return process. I > followed the pattern of previous authors by adding the test to the end of > metaspace.cpp, but I am not happy about this solution. Seems that > metaspace.cpp consists of a lot of test coding by now. It should be > possible to move the test code outside to hotspot/test/native without > exposing all metaspace internals to the world - eg. by using simple > facades. This would also make it possible to use the gtest ASSERT_.. macros > instead of using hotspot assert(). However, I decided to leave this for a > separate cleanup. > > Tests: > > I built and successfully ran the gtests on a linux x64, Windows x86 and > x64, Solaris sparc and AIX. Also, our nightly test runs (jtreg among > others) indicated no problem which could be attributed to my change. > > Thank you for reviewing, > > Thomas > > > > > From harold.seigel at oracle.com Thu Jan 12 13:50:17 2017 From: harold.seigel at oracle.com (harold seigel) Date: Thu, 12 Jan 2017 08:50:17 -0500 Subject: RFR(S) 8172288: Fix error message when trying to define an existing package to a module In-Reply-To: References: <7926a146-6005-5be0-dc8c-425ab8d5290f@oracle.com> Message-ID: Hi, Please review this updated webrev for this bug. The updated webrev includes a small JDK change and hotspot changes to throw the correct exceptions. New JDK webrev: http://cr.openjdk.java.net/~hseigel/bug_8172288.jdk.2/webrev/index.html New Hotspot webrev: http://cr.openjdk.java.net/~hseigel/bug_8172288.hs.2/ Note also that the bug has been re-titled to: Fix Jigsaw related module/package error messages and throw correct exceptions Thanks, Harold On 1/10/2017 10:18 AM, harold seigel wrote: > Yes. I'll modify the bug to include that. > > What exception should the JVM throw for this? > > Thanks, Harold > > > On 1/10/2017 10:12 AM, Alan Bateman wrote: >> On 10/01/2017 15:02, harold seigel wrote: >> >>> Hi, >>> >>> Please review this small fix for JDK-8172288. Here's a sample of >>> the new message: >>> >>> Package mypackage6 for module dupl.pkg.module is already in another >>> module, Module_A, defined to the class loader >>> >>> Adding the class loader name to the message will be done as part of >>> JDK-8169559 . >>> >>> Open Webrev: >>> http://cr.openjdk.java.net/~hseigel/bug_8172288/webrev/index.html >> IllegalArgumentException isn't a good exception for these cases, is >> now the time to proposing this too? >> >> -Alan > From george.triantafillou at oracle.com Thu Jan 12 14:18:05 2017 From: george.triantafillou at oracle.com (George Triantafillou) Date: Thu, 12 Jan 2017 09:18:05 -0500 Subject: RFR(S) 8172288: Fix error message when trying to define an existing package to a module In-Reply-To: References: <7926a146-6005-5be0-dc8c-425ab8d5290f@oracle.com> Message-ID: <80b3e7ca-92f8-5af4-21f0-8ea32c79737f@oracle.com> Hi Harold, src/share/vm/classfile/modules.cpp - lines 266, 449, and 806: Change "throw_dup_pkg_IAE" to "throw_dup_pkg_ISE". How was the change tested? Thanks. -George On 1/12/2017 8:50 AM, harold seigel wrote: > Hi, > > Please review this updated webrev for this bug. The updated webrev > includes a small JDK change and hotspot changes to throw the correct > exceptions. > > New JDK webrev: > http://cr.openjdk.java.net/~hseigel/bug_8172288.jdk.2/webrev/index.html > > New Hotspot webrev: http://cr.openjdk.java.net/~hseigel/bug_8172288.hs.2/ > > Note also that the bug has been re-titled to: Fix Jigsaw related > module/package error messages and throw correct exceptions > > Thanks, Harold > > On 1/10/2017 10:18 AM, harold seigel wrote: >> Yes. I'll modify the bug to include that. >> >> What exception should the JVM throw for this? >> >> Thanks, Harold >> >> >> On 1/10/2017 10:12 AM, Alan Bateman wrote: >>> On 10/01/2017 15:02, harold seigel wrote: >>> >>>> Hi, >>>> >>>> Please review this small fix for JDK-8172288. Here's a sample of >>>> the new message: >>>> >>>> Package mypackage6 for module dupl.pkg.module is already in another >>>> module, Module_A, defined to the class loader >>>> >>>> Adding the class loader name to the message will be done as part of >>>> JDK-8169559 . >>>> >>>> Open Webrev: >>>> http://cr.openjdk.java.net/~hseigel/bug_8172288/webrev/index.html >>> IllegalArgumentException isn't a good exception for these cases, is >>> now the time to proposing this too? >>> >>> -Alan >> > From Alan.Bateman at oracle.com Thu Jan 12 14:20:14 2017 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 12 Jan 2017 14:20:14 +0000 Subject: RFR(S) 8172288: Fix error message when trying to define an existing package to a module In-Reply-To: References: <7926a146-6005-5be0-dc8c-425ab8d5290f@oracle.com> Message-ID: <16f7168c-a662-2800-e211-efff4ff2ee9c@oracle.com> On 12/01/2017 13:50, harold seigel wrote: > Hi, > > Please review this updated webrev for this bug. The updated webrev > includes a small JDK change and hotspot changes to throw the correct > exceptions. > > New JDK webrev: > http://cr.openjdk.java.net/~hseigel/bug_8172288.jdk.2/webrev/index.html > > New Hotspot webrev: http://cr.openjdk.java.net/~hseigel/bug_8172288.hs.2/ The changes in the jdk repo looks okay. We'll need to adjust this further more it gets out of the hs forest. In the hotspot changes then throw_dup_pkg_IAE throws ISE so I assume the function can be renamed now. -Alan. From lois.foltan at oracle.com Thu Jan 12 14:25:17 2017 From: lois.foltan at oracle.com (Lois Foltan) Date: Thu, 12 Jan 2017 09:25:17 -0500 Subject: RFR(S) 8172288: Fix error message when trying to define an existing package to a module In-Reply-To: References: <7926a146-6005-5be0-dc8c-425ab8d5290f@oracle.com> Message-ID: <587791CD.5030407@oracle.com> Hi Harold, Looks good. Two comments in hotspot/src/share/vm/classfile/modules.cpp - The name of the new method throw_dup_pkg_IAE is incorrect since the method is throwing a IllegalStateException, how about method_throw_dup_pkg_expcetion? - I think you can do away with the local variable dup_pkg_index in Modules::define_modules in favor of the new existing_pkg flag. No sense in having both. Thanks, Lois On 1/12/2017 8:50 AM, harold seigel wrote: > Hi, > > Please review this updated webrev for this bug. The updated webrev > includes a small JDK change and hotspot changes to throw the correct > exceptions. > > New JDK webrev: > http://cr.openjdk.java.net/~hseigel/bug_8172288.jdk.2/webrev/index.html > > New Hotspot webrev: http://cr.openjdk.java.net/~hseigel/bug_8172288.hs.2/ > > Note also that the bug has been re-titled to: Fix Jigsaw related > module/package error messages and throw correct exceptions > > Thanks, Harold > > On 1/10/2017 10:18 AM, harold seigel wrote: >> Yes. I'll modify the bug to include that. >> >> What exception should the JVM throw for this? >> >> Thanks, Harold >> >> >> On 1/10/2017 10:12 AM, Alan Bateman wrote: >>> On 10/01/2017 15:02, harold seigel wrote: >>> >>>> Hi, >>>> >>>> Please review this small fix for JDK-8172288. Here's a sample of >>>> the new message: >>>> >>>> Package mypackage6 for module dupl.pkg.module is already in another >>>> module, Module_A, defined to the class loader >>>> >>>> Adding the class loader name to the message will be done as part of >>>> JDK-8169559 . >>>> >>>> Open Webrev: >>>> http://cr.openjdk.java.net/~hseigel/bug_8172288/webrev/index.html >>> IllegalArgumentException isn't a good exception for these cases, is >>> now the time to proposing this too? >>> >>> -Alan >> > From karen.kinnear at oracle.com Thu Jan 12 14:26:30 2017 From: karen.kinnear at oracle.com (Karen Kinnear) Date: Thu, 12 Jan 2017 09:26:30 -0500 Subject: RFR(S) 8172288: Fix error message when trying to define an existing package to a module In-Reply-To: <80b3e7ca-92f8-5af4-21f0-8ea32c79737f@oracle.com> References: <7926a146-6005-5be0-dc8c-425ab8d5290f@oracle.com> <80b3e7ca-92f8-5af4-21f0-8ea32c79737f@oracle.com> Message-ID: <16D97CCA-E12E-4626-B526-8090866EE0ED@oracle.com> Harold, Looks good - with the same minor comment George caught, perhaps throw_dup_pkg_exception? George - there are two tests attached. thanks, Karen > On Jan 12, 2017, at 9:18 AM, George Triantafillou wrote: > > Hi Harold, > > src/share/vm/classfile/modules.cpp - lines 266, 449, and 806: > > Change "throw_dup_pkg_IAE" to "throw_dup_pkg_ISE". > > How was the change tested? Thanks. > > -George > > On 1/12/2017 8:50 AM, harold seigel wrote: >> Hi, >> >> Please review this updated webrev for this bug. The updated webrev includes a small JDK change and hotspot changes to throw the correct exceptions. >> >> New JDK webrev: http://cr.openjdk.java.net/~hseigel/bug_8172288.jdk.2/webrev/index.html >> >> New Hotspot webrev: http://cr.openjdk.java.net/~hseigel/bug_8172288.hs.2/ >> >> Note also that the bug has been re-titled to: Fix Jigsaw related module/package error messages and throw correct exceptions >> >> Thanks, Harold >> >> On 1/10/2017 10:18 AM, harold seigel wrote: >>> Yes. I'll modify the bug to include that. >>> >>> What exception should the JVM throw for this? >>> >>> Thanks, Harold >>> >>> >>> On 1/10/2017 10:12 AM, Alan Bateman wrote: >>>> On 10/01/2017 15:02, harold seigel wrote: >>>> >>>>> Hi, >>>>> >>>>> Please review this small fix for JDK-8172288. Here's a sample of the new message: >>>>> >>>>> Package mypackage6 for module dupl.pkg.module is already in another module, Module_A, defined to the class loader >>>>> >>>>> Adding the class loader name to the message will be done as part of JDK-8169559 . >>>>> >>>>> Open Webrev: http://cr.openjdk.java.net/~hseigel/bug_8172288/webrev/index.html >>>> IllegalArgumentException isn't a good exception for these cases, is now the time to proposing this too? >>>> >>>> -Alan >>> >> > From george.triantafillou at oracle.com Thu Jan 12 14:30:54 2017 From: george.triantafillou at oracle.com (George Triantafillou) Date: Thu, 12 Jan 2017 09:30:54 -0500 Subject: RFR(S) 8172288: Fix error message when trying to define an existing package to a module In-Reply-To: <16D97CCA-E12E-4626-B526-8090866EE0ED@oracle.com> References: <7926a146-6005-5be0-dc8c-425ab8d5290f@oracle.com> <80b3e7ca-92f8-5af4-21f0-8ea32c79737f@oracle.com> <16D97CCA-E12E-4626-B526-8090866EE0ED@oracle.com> Message-ID: <785c4e8b-5288-2fb7-1ba8-e32374c7f29b@oracle.com> Hi Karen, On 1/12/2017 9:26 AM, Karen Kinnear wrote: > Harold, > > Looks good - with the same minor comment George caught, perhaps throw_dup_pkg_exception? > > George - there are two tests attached. Thanks, I saw the additions to test/runtime/modules/JVMDefineModule.java, but I wanted to know which hotspot tests were run with Harold's change. -George > > thanks, > Karen > >> On Jan 12, 2017, at 9:18 AM, George Triantafillou wrote: >> >> Hi Harold, >> >> src/share/vm/classfile/modules.cpp - lines 266, 449, and 806: >> >> Change "throw_dup_pkg_IAE" to "throw_dup_pkg_ISE". >> >> How was the change tested? Thanks. >> >> -George >> >> On 1/12/2017 8:50 AM, harold seigel wrote: >>> Hi, >>> >>> Please review this updated webrev for this bug. The updated webrev includes a small JDK change and hotspot changes to throw the correct exceptions. >>> >>> New JDK webrev: http://cr.openjdk.java.net/~hseigel/bug_8172288.jdk.2/webrev/index.html >>> >>> New Hotspot webrev: http://cr.openjdk.java.net/~hseigel/bug_8172288.hs.2/ >>> >>> Note also that the bug has been re-titled to: Fix Jigsaw related module/package error messages and throw correct exceptions >>> >>> Thanks, Harold >>> >>> On 1/10/2017 10:18 AM, harold seigel wrote: >>>> Yes. I'll modify the bug to include that. >>>> >>>> What exception should the JVM throw for this? >>>> >>>> Thanks, Harold >>>> >>>> >>>> On 1/10/2017 10:12 AM, Alan Bateman wrote: >>>>> On 10/01/2017 15:02, harold seigel wrote: >>>>> >>>>>> Hi, >>>>>> >>>>>> Please review this small fix for JDK-8172288. Here's a sample of the new message: >>>>>> >>>>>> Package mypackage6 for module dupl.pkg.module is already in another module, Module_A, defined to the class loader >>>>>> >>>>>> Adding the class loader name to the message will be done as part of JDK-8169559 . >>>>>> >>>>>> Open Webrev: http://cr.openjdk.java.net/~hseigel/bug_8172288/webrev/index.html >>>>> IllegalArgumentException isn't a good exception for these cases, is now the time to proposing this too? >>>>> >>>>> -Alan From harold.seigel at oracle.com Thu Jan 12 15:16:20 2017 From: harold.seigel at oracle.com (harold seigel) Date: Thu, 12 Jan 2017 10:16:20 -0500 Subject: RFR(S) 8172288: Fix error message when trying to define an existing package to a module In-Reply-To: <785c4e8b-5288-2fb7-1ba8-e32374c7f29b@oracle.com> References: <7926a146-6005-5be0-dc8c-425ab8d5290f@oracle.com> <80b3e7ca-92f8-5af4-21f0-8ea32c79737f@oracle.com> <16D97CCA-E12E-4626-B526-8090866EE0ED@oracle.com> <785c4e8b-5288-2fb7-1ba8-e32374c7f29b@oracle.com> Message-ID: <36b7bd52-8b2c-92e0-d89a-1f8bb5bda27a@oracle.com> Thanks everyone for all the reviews. I'll post a new webrev with the following changes, and testing details, once the re-testing completes. 1. Rename throw_dup_pkg_IAE() to throw_dup_pkg_exception() 2. Remove the package_name argument from throw_dup_pkg_exception() because the package name can be extracted from the existing_pkg argument. 2. Remove dupl_pk_index and use existing_pkg instead. Harold On 1/12/2017 9:30 AM, George Triantafillou wrote: > Hi Karen, > > On 1/12/2017 9:26 AM, Karen Kinnear wrote: >> Harold, >> >> Looks good - with the same minor comment George caught, perhaps >> throw_dup_pkg_exception? >> >> George - there are two tests attached. > Thanks, I saw the additions to > test/runtime/modules/JVMDefineModule.java, but I wanted to know which > hotspot tests were run with Harold's change. > > -George >> >> thanks, >> Karen >> >>> On Jan 12, 2017, at 9:18 AM, George Triantafillou >>> wrote: >>> >>> Hi Harold, >>> >>> src/share/vm/classfile/modules.cpp - lines 266, 449, and 806: >>> >>> Change "throw_dup_pkg_IAE" to "throw_dup_pkg_ISE". >>> >>> How was the change tested? Thanks. >>> >>> -George >>> >>> On 1/12/2017 8:50 AM, harold seigel wrote: >>>> Hi, >>>> >>>> Please review this updated webrev for this bug. The updated webrev >>>> includes a small JDK change and hotspot changes to throw the >>>> correct exceptions. >>>> >>>> New JDK webrev: >>>> http://cr.openjdk.java.net/~hseigel/bug_8172288.jdk.2/webrev/index.html >>>> >>>> >>>> New Hotspot webrev: >>>> http://cr.openjdk.java.net/~hseigel/bug_8172288.hs.2/ >>>> >>>> Note also that the bug has been re-titled to: Fix Jigsaw related >>>> module/package error messages and throw correct exceptions >>>> >>>> Thanks, Harold >>>> >>>> On 1/10/2017 10:18 AM, harold seigel wrote: >>>>> Yes. I'll modify the bug to include that. >>>>> >>>>> What exception should the JVM throw for this? >>>>> >>>>> Thanks, Harold >>>>> >>>>> >>>>> On 1/10/2017 10:12 AM, Alan Bateman wrote: >>>>>> On 10/01/2017 15:02, harold seigel wrote: >>>>>> >>>>>>> Hi, >>>>>>> >>>>>>> Please review this small fix for JDK-8172288. Here's a sample >>>>>>> of the new message: >>>>>>> >>>>>>> Package mypackage6 for module dupl.pkg.module is already in >>>>>>> another module, Module_A, defined to the class loader >>>>>>> >>>>>>> Adding the class loader name to the message will be done as part >>>>>>> of JDK-8169559 . >>>>>>> >>>>>>> Open Webrev: >>>>>>> http://cr.openjdk.java.net/~hseigel/bug_8172288/webrev/index.html >>>>>> IllegalArgumentException isn't a good exception for these cases, >>>>>> is now the time to proposing this too? >>>>>> >>>>>> -Alan > From harold.seigel at oracle.com Thu Jan 12 15:25:50 2017 From: harold.seigel at oracle.com (harold seigel) Date: Thu, 12 Jan 2017 10:25:50 -0500 Subject: RFR: 8170821: Ensure access checks result in consistent answers In-Reply-To: <68905b4b-68d5-78e9-a54a-57e3f20cd3c6@oracle.com> References: <9944787a-8e04-95c1-b1fc-5d718cadf873@oracle.com> <89aa93f3-3afd-9d01-49cd-893b1594c2a0@oracle.com> <68905b4b-68d5-78e9-a54a-57e3f20cd3c6@oracle.com> Message-ID: Hi Rachel, The tests look good. Could you just enhance some of the IllegalAccessError catch clauses to call e.getMessage() to ensure that the IllegalAccessError exceptions got thrown for the expected reasons? I don't need to see another webrev. Thanks, Harold On 1/11/2017 10:25 AM, Rachel Protacio wrote: > Hello! I've updated this changeset, if anyone wouldn't mind reviewing > it again. http://cr.openjdk.java.net/~rprotacio/8170821.02 > > Changes: > - updated AccessExportTwice.java (previously "AccessTwice.java") > because of API changes > - corrected some comments > - added AccessReadTwice.java test that ensures constant answers > when IAE is due to readability (AccessExportTwice checks for > exportedness) > > Tested with JPRT. > > Thanks! > Rachel > > On 12/9/2016 10:13 AM, Rachel Protacio wrote: >> Thanks, Harold - >> >> New webrev: http://cr.openjdk.java.net/~rprotacio/8170821.01/ >> >> >> On 12/9/2016 9:09 AM, harold seigel wrote: >>> Hi Rachel, >>> >>> The test looks good, lots of good comments. Just a couple of >>> questions. >>> >>> 1. Does the test need to be run with -Xlog:modules=debug ? >> No, not really. It was there because it was helpful in the case that >> the test fails, but you're right, it's extra effort/output now. I've >> removed it. >>> >>> 2. Is -Xbootclasspath/a:. needed ? >> Nope, deleted that too. >> Thanks! >> Rachel >>> >>> Thanks, Harold >>> >>> >>> On 12/8/2016 4:18 PM, Rachel Protacio wrote: >>>> Hello! >>>> >>>> Please review this change adding a jtreg test to ensure that access >>>> check results are cached, so the same check produces the same >>>> answer even if the user adds access in between. (Credit to Lois for >>>> the actual workings of the test.) >>>> >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8170821 >>>> Open webrev: http://cr.openjdk.java.net/~rprotacio/8170821.00/ >>>> >>>> Passes JPRT on all platforms. >>>> >>>> Thanks, >>>> Rachel >>>> >>> >> > From rachel.protacio at oracle.com Thu Jan 12 16:04:31 2017 From: rachel.protacio at oracle.com (Rachel Protacio) Date: Thu, 12 Jan 2017 11:04:31 -0500 Subject: RFR: 8170821: Ensure access checks result in consistent answers In-Reply-To: References: <9944787a-8e04-95c1-b1fc-5d718cadf873@oracle.com> <89aa93f3-3afd-9d01-49cd-893b1594c2a0@oracle.com> <68905b4b-68d5-78e9-a54a-57e3f20cd3c6@oracle.com> Message-ID: <4bc6d898-a94b-086f-17da-a896d4ca8cff@oracle.com> Thanks for the review, Harold! I'll add that. Rachel On 1/12/2017 10:25 AM, harold seigel wrote: > Hi Rachel, > > The tests look good. Could you just enhance some of the > IllegalAccessError catch clauses to call e.getMessage() to ensure that > the IllegalAccessError exceptions got thrown for the expected reasons? > > I don't need to see another webrev. > > Thanks, Harold > > > On 1/11/2017 10:25 AM, Rachel Protacio wrote: >> Hello! I've updated this changeset, if anyone wouldn't mind reviewing >> it again. http://cr.openjdk.java.net/~rprotacio/8170821.02 >> >> Changes: >> - updated AccessExportTwice.java (previously "AccessTwice.java") >> because of API changes >> - corrected some comments >> - added AccessReadTwice.java test that ensures constant answers >> when IAE is due to readability (AccessExportTwice checks for >> exportedness) >> >> Tested with JPRT. >> >> Thanks! >> Rachel >> >> On 12/9/2016 10:13 AM, Rachel Protacio wrote: >>> Thanks, Harold - >>> >>> New webrev: http://cr.openjdk.java.net/~rprotacio/8170821.01/ >>> >>> >>> On 12/9/2016 9:09 AM, harold seigel wrote: >>>> Hi Rachel, >>>> >>>> The test looks good, lots of good comments. Just a couple of >>>> questions. >>>> >>>> 1. Does the test need to be run with -Xlog:modules=debug ? >>> No, not really. It was there because it was helpful in the case that >>> the test fails, but you're right, it's extra effort/output now. I've >>> removed it. >>>> >>>> 2. Is -Xbootclasspath/a:. needed ? >>> Nope, deleted that too. >>> Thanks! >>> Rachel >>>> >>>> Thanks, Harold >>>> >>>> >>>> On 12/8/2016 4:18 PM, Rachel Protacio wrote: >>>>> Hello! >>>>> >>>>> Please review this change adding a jtreg test to ensure that >>>>> access check results are cached, so the same check produces the >>>>> same answer even if the user adds access in between. (Credit to >>>>> Lois for the actual workings of the test.) >>>>> >>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8170821 >>>>> Open webrev: http://cr.openjdk.java.net/~rprotacio/8170821.00/ >>>>> >>>>> Passes JPRT on all platforms. >>>>> >>>>> Thanks, >>>>> Rachel >>>>> >>>> >>> >> > From harold.seigel at oracle.com Thu Jan 12 19:18:34 2017 From: harold.seigel at oracle.com (harold seigel) Date: Thu, 12 Jan 2017 14:18:34 -0500 Subject: RFR(S) 8172288: Fix error message when trying to define an existing package to a module In-Reply-To: <36b7bd52-8b2c-92e0-d89a-1f8bb5bda27a@oracle.com> References: <7926a146-6005-5be0-dc8c-425ab8d5290f@oracle.com> <80b3e7ca-92f8-5af4-21f0-8ea32c79737f@oracle.com> <16D97CCA-E12E-4626-B526-8090866EE0ED@oracle.com> <785c4e8b-5288-2fb7-1ba8-e32374c7f29b@oracle.com> <36b7bd52-8b2c-92e0-d89a-1f8bb5bda27a@oracle.com> Message-ID: Hi, Please review this updated webrev: http://cr.openjdk.java.net/~hseigel/bug_8172288.hs.3/webrev/index.html It contains the three changes listed below. Only file modules.cpp has changed since the last webrev. This fix was tested with the JTreg hotspot, java/io, java/lang, java/util and other JTReg tests, with the JCK lang and VM tests, and with RBT tiers2 - tier5 tests on Linux X64. Thanks, Harold On 1/12/2017 10:16 AM, harold seigel wrote: > Thanks everyone for all the reviews. > > I'll post a new webrev with the following changes, and testing > details, once the re-testing completes. > > 1. Rename throw_dup_pkg_IAE() to throw_dup_pkg_exception() > > 2. Remove the package_name argument from throw_dup_pkg_exception() > because the package name can be extracted from the existing_pkg argument. > > 3. Remove dupl_pk_index and use existing_pkg instead. > > Harold > > > On 1/12/2017 9:30 AM, George Triantafillou wrote: >> Hi Karen, >> >> On 1/12/2017 9:26 AM, Karen Kinnear wrote: >>> Harold, >>> >>> Looks good - with the same minor comment George caught, perhaps >>> throw_dup_pkg_exception? >>> >>> George - there are two tests attached. >> Thanks, I saw the additions to >> test/runtime/modules/JVMDefineModule.java, but I wanted to know which >> hotspot tests were run with Harold's change. >> >> -George >>> >>> thanks, >>> Karen >>> >>>> On Jan 12, 2017, at 9:18 AM, George Triantafillou >>>> wrote: >>>> >>>> Hi Harold, >>>> >>>> src/share/vm/classfile/modules.cpp - lines 266, 449, and 806: >>>> >>>> Change "throw_dup_pkg_IAE" to "throw_dup_pkg_ISE". >>>> >>>> How was the change tested? Thanks. >>>> >>>> -George >>>> >>>> On 1/12/2017 8:50 AM, harold seigel wrote: >>>>> Hi, >>>>> >>>>> Please review this updated webrev for this bug. The updated >>>>> webrev includes a small JDK change and hotspot changes to throw >>>>> the correct exceptions. >>>>> >>>>> New JDK webrev: >>>>> http://cr.openjdk.java.net/~hseigel/bug_8172288.jdk.2/webrev/index.html >>>>> >>>>> >>>>> New Hotspot webrev: >>>>> http://cr.openjdk.java.net/~hseigel/bug_8172288.hs.2/ >>>>> >>>>> Note also that the bug has been re-titled to: Fix Jigsaw related >>>>> module/package error messages and throw correct exceptions >>>>> >>>>> Thanks, Harold >>>>> >>>>> On 1/10/2017 10:18 AM, harold seigel wrote: >>>>>> Yes. I'll modify the bug to include that. >>>>>> >>>>>> What exception should the JVM throw for this? >>>>>> >>>>>> Thanks, Harold >>>>>> >>>>>> >>>>>> On 1/10/2017 10:12 AM, Alan Bateman wrote: >>>>>>> On 10/01/2017 15:02, harold seigel wrote: >>>>>>> >>>>>>>> Hi, >>>>>>>> >>>>>>>> Please review this small fix for JDK-8172288. Here's a sample >>>>>>>> of the new message: >>>>>>>> >>>>>>>> Package mypackage6 for module dupl.pkg.module is already in >>>>>>>> another module, Module_A, defined to the class loader >>>>>>>> >>>>>>>> Adding the class loader name to the message will be done as >>>>>>>> part of JDK-8169559 >>>>>>>> . >>>>>>>> >>>>>>>> Open Webrev: >>>>>>>> http://cr.openjdk.java.net/~hseigel/bug_8172288/webrev/index.html >>>>>>> IllegalArgumentException isn't a good exception for these cases, >>>>>>> is now the time to proposing this too? >>>>>>> >>>>>>> -Alan >> > From lois.foltan at oracle.com Thu Jan 12 19:21:10 2017 From: lois.foltan at oracle.com (Lois Foltan) Date: Thu, 12 Jan 2017 14:21:10 -0500 Subject: RFR(S) 8172288: Fix error message when trying to define an existing package to a module In-Reply-To: References: <7926a146-6005-5be0-dc8c-425ab8d5290f@oracle.com> <80b3e7ca-92f8-5af4-21f0-8ea32c79737f@oracle.com> <16D97CCA-E12E-4626-B526-8090866EE0ED@oracle.com> <785c4e8b-5288-2fb7-1ba8-e32374c7f29b@oracle.com> <36b7bd52-8b2c-92e0-d89a-1f8bb5bda27a@oracle.com> Message-ID: <5877D726.1040705@oracle.com> Looks good, thank you for making those changes. Lois On 1/12/2017 2:18 PM, harold seigel wrote: > Hi, > > Please review this updated webrev: > http://cr.openjdk.java.net/~hseigel/bug_8172288.hs.3/webrev/index.html > > It contains the three changes listed below. Only file modules.cpp has > changed since the last webrev. > > This fix was tested with the JTreg hotspot, java/io, java/lang, > java/util and other JTReg tests, with the JCK lang and VM tests, and > with RBT tiers2 - tier5 tests on Linux X64. > > Thanks, Harold > > > On 1/12/2017 10:16 AM, harold seigel wrote: >> Thanks everyone for all the reviews. >> >> I'll post a new webrev with the following changes, and testing >> details, once the re-testing completes. >> >> 1. Rename throw_dup_pkg_IAE() to throw_dup_pkg_exception() >> >> 2. Remove the package_name argument from throw_dup_pkg_exception() >> because the package name can be extracted from the existing_pkg >> argument. >> >> 3. Remove dupl_pk_index and use existing_pkg instead. >> >> Harold >> >> >> On 1/12/2017 9:30 AM, George Triantafillou wrote: >>> Hi Karen, >>> >>> On 1/12/2017 9:26 AM, Karen Kinnear wrote: >>>> Harold, >>>> >>>> Looks good - with the same minor comment George caught, perhaps >>>> throw_dup_pkg_exception? >>>> >>>> George - there are two tests attached. >>> Thanks, I saw the additions to >>> test/runtime/modules/JVMDefineModule.java, but I wanted to know >>> which hotspot tests were run with Harold's change. >>> >>> -George >>>> >>>> thanks, >>>> Karen >>>> >>>>> On Jan 12, 2017, at 9:18 AM, George Triantafillou >>>>> wrote: >>>>> >>>>> Hi Harold, >>>>> >>>>> src/share/vm/classfile/modules.cpp - lines 266, 449, and 806: >>>>> >>>>> Change "throw_dup_pkg_IAE" to "throw_dup_pkg_ISE". >>>>> >>>>> How was the change tested? Thanks. >>>>> >>>>> -George >>>>> >>>>> On 1/12/2017 8:50 AM, harold seigel wrote: >>>>>> Hi, >>>>>> >>>>>> Please review this updated webrev for this bug. The updated >>>>>> webrev includes a small JDK change and hotspot changes to throw >>>>>> the correct exceptions. >>>>>> >>>>>> New JDK webrev: >>>>>> http://cr.openjdk.java.net/~hseigel/bug_8172288.jdk.2/webrev/index.html >>>>>> >>>>>> >>>>>> New Hotspot webrev: >>>>>> http://cr.openjdk.java.net/~hseigel/bug_8172288.hs.2/ >>>>>> >>>>>> Note also that the bug has been re-titled to: Fix Jigsaw related >>>>>> module/package error messages and throw correct exceptions >>>>>> >>>>>> Thanks, Harold >>>>>> >>>>>> On 1/10/2017 10:18 AM, harold seigel wrote: >>>>>>> Yes. I'll modify the bug to include that. >>>>>>> >>>>>>> What exception should the JVM throw for this? >>>>>>> >>>>>>> Thanks, Harold >>>>>>> >>>>>>> >>>>>>> On 1/10/2017 10:12 AM, Alan Bateman wrote: >>>>>>>> On 10/01/2017 15:02, harold seigel wrote: >>>>>>>> >>>>>>>>> Hi, >>>>>>>>> >>>>>>>>> Please review this small fix for JDK-8172288. Here's a sample >>>>>>>>> of the new message: >>>>>>>>> >>>>>>>>> Package mypackage6 for module dupl.pkg.module is already in >>>>>>>>> another module, Module_A, defined to the class loader >>>>>>>>> >>>>>>>>> Adding the class loader name to the message will be done as >>>>>>>>> part of JDK-8169559 >>>>>>>>> . >>>>>>>>> >>>>>>>>> Open Webrev: >>>>>>>>> http://cr.openjdk.java.net/~hseigel/bug_8172288/webrev/index.html >>>>>>>> IllegalArgumentException isn't a good exception for these >>>>>>>> cases, is now the time to proposing this too? >>>>>>>> >>>>>>>> -Alan >>> >> > From harold.seigel at oracle.com Thu Jan 12 19:22:59 2017 From: harold.seigel at oracle.com (harold seigel) Date: Thu, 12 Jan 2017 14:22:59 -0500 Subject: RFR(S) 8172288: Fix error message when trying to define an existing package to a module In-Reply-To: <5877D726.1040705@oracle.com> References: <7926a146-6005-5be0-dc8c-425ab8d5290f@oracle.com> <80b3e7ca-92f8-5af4-21f0-8ea32c79737f@oracle.com> <16D97CCA-E12E-4626-B526-8090866EE0ED@oracle.com> <785c4e8b-5288-2fb7-1ba8-e32374c7f29b@oracle.com> <36b7bd52-8b2c-92e0-d89a-1f8bb5bda27a@oracle.com> <5877D726.1040705@oracle.com> Message-ID: Thanks Lois! Harold On 1/12/2017 2:21 PM, Lois Foltan wrote: > Looks good, thank you for making those changes. > Lois > > On 1/12/2017 2:18 PM, harold seigel wrote: >> Hi, >> >> Please review this updated webrev: >> http://cr.openjdk.java.net/~hseigel/bug_8172288.hs.3/webrev/index.html >> >> It contains the three changes listed below. Only file modules.cpp >> has changed since the last webrev. >> >> This fix was tested with the JTreg hotspot, java/io, java/lang, >> java/util and other JTReg tests, with the JCK lang and VM tests, and >> with RBT tiers2 - tier5 tests on Linux X64. >> >> Thanks, Harold >> >> >> On 1/12/2017 10:16 AM, harold seigel wrote: >>> Thanks everyone for all the reviews. >>> >>> I'll post a new webrev with the following changes, and testing >>> details, once the re-testing completes. >>> >>> 1. Rename throw_dup_pkg_IAE() to throw_dup_pkg_exception() >>> >>> 2. Remove the package_name argument from throw_dup_pkg_exception() >>> because the package name can be extracted from the existing_pkg >>> argument. >>> >>> 3. Remove dupl_pk_index and use existing_pkg instead. >>> >>> Harold >>> >>> >>> On 1/12/2017 9:30 AM, George Triantafillou wrote: >>>> Hi Karen, >>>> >>>> On 1/12/2017 9:26 AM, Karen Kinnear wrote: >>>>> Harold, >>>>> >>>>> Looks good - with the same minor comment George caught, perhaps >>>>> throw_dup_pkg_exception? >>>>> >>>>> George - there are two tests attached. >>>> Thanks, I saw the additions to >>>> test/runtime/modules/JVMDefineModule.java, but I wanted to know >>>> which hotspot tests were run with Harold's change. >>>> >>>> -George >>>>> >>>>> thanks, >>>>> Karen >>>>> >>>>>> On Jan 12, 2017, at 9:18 AM, George Triantafillou >>>>>> wrote: >>>>>> >>>>>> Hi Harold, >>>>>> >>>>>> src/share/vm/classfile/modules.cpp - lines 266, 449, and 806: >>>>>> >>>>>> Change "throw_dup_pkg_IAE" to "throw_dup_pkg_ISE". >>>>>> >>>>>> How was the change tested? Thanks. >>>>>> >>>>>> -George >>>>>> >>>>>> On 1/12/2017 8:50 AM, harold seigel wrote: >>>>>>> Hi, >>>>>>> >>>>>>> Please review this updated webrev for this bug. The updated >>>>>>> webrev includes a small JDK change and hotspot changes to throw >>>>>>> the correct exceptions. >>>>>>> >>>>>>> New JDK webrev: >>>>>>> http://cr.openjdk.java.net/~hseigel/bug_8172288.jdk.2/webrev/index.html >>>>>>> >>>>>>> >>>>>>> New Hotspot webrev: >>>>>>> http://cr.openjdk.java.net/~hseigel/bug_8172288.hs.2/ >>>>>>> >>>>>>> Note also that the bug has been re-titled to: Fix Jigsaw related >>>>>>> module/package error messages and throw correct exceptions >>>>>>> >>>>>>> Thanks, Harold >>>>>>> >>>>>>> On 1/10/2017 10:18 AM, harold seigel wrote: >>>>>>>> Yes. I'll modify the bug to include that. >>>>>>>> >>>>>>>> What exception should the JVM throw for this? >>>>>>>> >>>>>>>> Thanks, Harold >>>>>>>> >>>>>>>> >>>>>>>> On 1/10/2017 10:12 AM, Alan Bateman wrote: >>>>>>>>> On 10/01/2017 15:02, harold seigel wrote: >>>>>>>>> >>>>>>>>>> Hi, >>>>>>>>>> >>>>>>>>>> Please review this small fix for JDK-8172288. Here's a sample >>>>>>>>>> of the new message: >>>>>>>>>> >>>>>>>>>> Package mypackage6 for module dupl.pkg.module is already in >>>>>>>>>> another module, Module_A, defined to the class loader >>>>>>>>>> >>>>>>>>>> Adding the class loader name to the message will be done as >>>>>>>>>> part of JDK-8169559 >>>>>>>>>> . >>>>>>>>>> >>>>>>>>>> Open Webrev: >>>>>>>>>> http://cr.openjdk.java.net/~hseigel/bug_8172288/webrev/index.html >>>>>>>>>> >>>>>>>>> IllegalArgumentException isn't a good exception for these >>>>>>>>> cases, is now the time to proposing this too? >>>>>>>>> >>>>>>>>> -Alan >>>> >>> >> > From lois.foltan at oracle.com Thu Jan 12 19:24:24 2017 From: lois.foltan at oracle.com (Lois Foltan) Date: Thu, 12 Jan 2017 14:24:24 -0500 Subject: RFR: 8170821: Ensure access checks result in consistent answers In-Reply-To: <4bc6d898-a94b-086f-17da-a896d4ca8cff@oracle.com> References: <9944787a-8e04-95c1-b1fc-5d718cadf873@oracle.com> <89aa93f3-3afd-9d01-49cd-893b1594c2a0@oracle.com> <68905b4b-68d5-78e9-a54a-57e3f20cd3c6@oracle.com> <4bc6d898-a94b-086f-17da-a896d4ca8cff@oracle.com> Message-ID: <5877D7E8.6090605@oracle.com> +1. Thanks for adding these tests Rachel! Lois On 1/12/2017 11:04 AM, Rachel Protacio wrote: > Thanks for the review, Harold! I'll add that. > > Rachel > > > On 1/12/2017 10:25 AM, harold seigel wrote: >> Hi Rachel, >> >> The tests look good. Could you just enhance some of the >> IllegalAccessError catch clauses to call e.getMessage() to ensure >> that the IllegalAccessError exceptions got thrown for the expected >> reasons? >> >> I don't need to see another webrev. >> >> Thanks, Harold >> >> >> On 1/11/2017 10:25 AM, Rachel Protacio wrote: >>> Hello! I've updated this changeset, if anyone wouldn't mind >>> reviewing it again. http://cr.openjdk.java.net/~rprotacio/8170821.02 >>> >>> Changes: >>> - updated AccessExportTwice.java (previously "AccessTwice.java") >>> because of API changes >>> - corrected some comments >>> - added AccessReadTwice.java test that ensures constant answers >>> when IAE is due to readability (AccessExportTwice checks for >>> exportedness) >>> >>> Tested with JPRT. >>> >>> Thanks! >>> Rachel >>> >>> On 12/9/2016 10:13 AM, Rachel Protacio wrote: >>>> Thanks, Harold - >>>> >>>> New webrev: http://cr.openjdk.java.net/~rprotacio/8170821.01/ >>>> >>>> >>>> On 12/9/2016 9:09 AM, harold seigel wrote: >>>>> Hi Rachel, >>>>> >>>>> The test looks good, lots of good comments. Just a couple of >>>>> questions. >>>>> >>>>> 1. Does the test need to be run with -Xlog:modules=debug ? >>>> No, not really. It was there because it was helpful in the case >>>> that the test fails, but you're right, it's extra effort/output >>>> now. I've removed it. >>>>> >>>>> 2. Is -Xbootclasspath/a:. needed ? >>>> Nope, deleted that too. >>>> Thanks! >>>> Rachel >>>>> >>>>> Thanks, Harold >>>>> >>>>> >>>>> On 12/8/2016 4:18 PM, Rachel Protacio wrote: >>>>>> Hello! >>>>>> >>>>>> Please review this change adding a jtreg test to ensure that >>>>>> access check results are cached, so the same check produces the >>>>>> same answer even if the user adds access in between. (Credit to >>>>>> Lois for the actual workings of the test.) >>>>>> >>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8170821 >>>>>> Open webrev: http://cr.openjdk.java.net/~rprotacio/8170821.00/ >>>>>> >>>>>> Passes JPRT on all platforms. >>>>>> >>>>>> Thanks, >>>>>> Rachel >>>>>> >>>>> >>>> >>> >> > From rachel.protacio at oracle.com Thu Jan 12 19:26:28 2017 From: rachel.protacio at oracle.com (Rachel Protacio) Date: Thu, 12 Jan 2017 14:26:28 -0500 Subject: RFR: 8170821: Ensure access checks result in consistent answers In-Reply-To: <5877D7E8.6090605@oracle.com> References: <9944787a-8e04-95c1-b1fc-5d718cadf873@oracle.com> <89aa93f3-3afd-9d01-49cd-893b1594c2a0@oracle.com> <68905b4b-68d5-78e9-a54a-57e3f20cd3c6@oracle.com> <4bc6d898-a94b-086f-17da-a896d4ca8cff@oracle.com> <5877D7E8.6090605@oracle.com> Message-ID: Thanks, Lois! I'll commit. Rachel On 1/12/2017 2:24 PM, Lois Foltan wrote: > +1. Thanks for adding these tests Rachel! > Lois > > On 1/12/2017 11:04 AM, Rachel Protacio wrote: >> Thanks for the review, Harold! I'll add that. >> >> Rachel >> >> >> On 1/12/2017 10:25 AM, harold seigel wrote: >>> Hi Rachel, >>> >>> The tests look good. Could you just enhance some of the >>> IllegalAccessError catch clauses to call e.getMessage() to ensure >>> that the IllegalAccessError exceptions got thrown for the expected >>> reasons? >>> >>> I don't need to see another webrev. >>> >>> Thanks, Harold >>> >>> >>> On 1/11/2017 10:25 AM, Rachel Protacio wrote: >>>> Hello! I've updated this changeset, if anyone wouldn't mind >>>> reviewing it again. http://cr.openjdk.java.net/~rprotacio/8170821.02 >>>> >>>> Changes: >>>> - updated AccessExportTwice.java (previously >>>> "AccessTwice.java") because of API changes >>>> - corrected some comments >>>> - added AccessReadTwice.java test that ensures constant answers >>>> when IAE is due to readability (AccessExportTwice checks for >>>> exportedness) >>>> >>>> Tested with JPRT. >>>> >>>> Thanks! >>>> Rachel >>>> >>>> On 12/9/2016 10:13 AM, Rachel Protacio wrote: >>>>> Thanks, Harold - >>>>> >>>>> New webrev: http://cr.openjdk.java.net/~rprotacio/8170821.01/ >>>>> >>>>> >>>>> On 12/9/2016 9:09 AM, harold seigel wrote: >>>>>> Hi Rachel, >>>>>> >>>>>> The test looks good, lots of good comments. Just a couple of >>>>>> questions. >>>>>> >>>>>> 1. Does the test need to be run with -Xlog:modules=debug ? >>>>> No, not really. It was there because it was helpful in the case >>>>> that the test fails, but you're right, it's extra effort/output >>>>> now. I've removed it. >>>>>> >>>>>> 2. Is -Xbootclasspath/a:. needed ? >>>>> Nope, deleted that too. >>>>> Thanks! >>>>> Rachel >>>>>> >>>>>> Thanks, Harold >>>>>> >>>>>> >>>>>> On 12/8/2016 4:18 PM, Rachel Protacio wrote: >>>>>>> Hello! >>>>>>> >>>>>>> Please review this change adding a jtreg test to ensure that >>>>>>> access check results are cached, so the same check produces the >>>>>>> same answer even if the user adds access in between. (Credit to >>>>>>> Lois for the actual workings of the test.) >>>>>>> >>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8170821 >>>>>>> Open webrev: http://cr.openjdk.java.net/~rprotacio/8170821.00/ >>>>>>> >>>>>>> Passes JPRT on all platforms. >>>>>>> >>>>>>> Thanks, >>>>>>> Rachel >>>>>>> >>>>>> >>>>> >>>> >>> >> > From karen.kinnear at oracle.com Thu Jan 12 20:46:47 2017 From: karen.kinnear at oracle.com (Karen Kinnear) Date: Thu, 12 Jan 2017 15:46:47 -0500 Subject: RFR(S) 8172288: Fix error message when trying to define an existing package to a module In-Reply-To: References: <7926a146-6005-5be0-dc8c-425ab8d5290f@oracle.com> <80b3e7ca-92f8-5af4-21f0-8ea32c79737f@oracle.com> <16D97CCA-E12E-4626-B526-8090866EE0ED@oracle.com> <785c4e8b-5288-2fb7-1ba8-e32374c7f29b@oracle.com> <36b7bd52-8b2c-92e0-d89a-1f8bb5bda27a@oracle.com> Message-ID: <3ACE7772-2ACE-44EE-90BF-9313F7EC8F14@oracle.com> Harold, This looks much cleaner! thanks, Karen > On Jan 12, 2017, at 2:18 PM, harold seigel wrote: > > Hi, > > Please review this updated webrev: http://cr.openjdk.java.net/~hseigel/bug_8172288.hs.3/webrev/index.html > > It contains the three changes listed below. Only file modules.cpp has changed since the last webrev. > > This fix was tested with the JTreg hotspot, java/io, java/lang, java/util and other JTReg tests, with the JCK lang and VM tests, and with RBT tiers2 - tier5 tests on Linux X64. > > Thanks, Harold > > > On 1/12/2017 10:16 AM, harold seigel wrote: >> Thanks everyone for all the reviews. >> >> I'll post a new webrev with the following changes, and testing details, once the re-testing completes. >> >> 1. Rename throw_dup_pkg_IAE() to throw_dup_pkg_exception() >> >> 2. Remove the package_name argument from throw_dup_pkg_exception() because the package name can be extracted from the existing_pkg argument. >> >> 3. Remove dupl_pk_index and use existing_pkg instead. >> >> Harold >> >> >> On 1/12/2017 9:30 AM, George Triantafillou wrote: >>> Hi Karen, >>> >>> On 1/12/2017 9:26 AM, Karen Kinnear wrote: >>>> Harold, >>>> >>>> Looks good - with the same minor comment George caught, perhaps throw_dup_pkg_exception? >>>> >>>> George - there are two tests attached. >>> Thanks, I saw the additions to test/runtime/modules/JVMDefineModule.java, but I wanted to know which hotspot tests were run with Harold's change. >>> >>> -George >>>> >>>> thanks, >>>> Karen >>>> >>>>> On Jan 12, 2017, at 9:18 AM, George Triantafillou wrote: >>>>> >>>>> Hi Harold, >>>>> >>>>> src/share/vm/classfile/modules.cpp - lines 266, 449, and 806: >>>>> >>>>> Change "throw_dup_pkg_IAE" to "throw_dup_pkg_ISE". >>>>> >>>>> How was the change tested? Thanks. >>>>> >>>>> -George >>>>> >>>>> On 1/12/2017 8:50 AM, harold seigel wrote: >>>>>> Hi, >>>>>> >>>>>> Please review this updated webrev for this bug. The updated webrev includes a small JDK change and hotspot changes to throw the correct exceptions. >>>>>> >>>>>> New JDK webrev: http://cr.openjdk.java.net/~hseigel/bug_8172288.jdk.2/webrev/index.html >>>>>> >>>>>> New Hotspot webrev: http://cr.openjdk.java.net/~hseigel/bug_8172288.hs.2/ >>>>>> >>>>>> Note also that the bug has been re-titled to: Fix Jigsaw related module/package error messages and throw correct exceptions >>>>>> >>>>>> Thanks, Harold >>>>>> >>>>>> On 1/10/2017 10:18 AM, harold seigel wrote: >>>>>>> Yes. I'll modify the bug to include that. >>>>>>> >>>>>>> What exception should the JVM throw for this? >>>>>>> >>>>>>> Thanks, Harold >>>>>>> >>>>>>> >>>>>>> On 1/10/2017 10:12 AM, Alan Bateman wrote: >>>>>>>> On 10/01/2017 15:02, harold seigel wrote: >>>>>>>> >>>>>>>>> Hi, >>>>>>>>> >>>>>>>>> Please review this small fix for JDK-8172288. Here's a sample of the new message: >>>>>>>>> >>>>>>>>> Package mypackage6 for module dupl.pkg.module is already in another module, Module_A, defined to the class loader >>>>>>>>> >>>>>>>>> Adding the class loader name to the message will be done as part of JDK-8169559 . >>>>>>>>> >>>>>>>>> Open Webrev: http://cr.openjdk.java.net/~hseigel/bug_8172288/webrev/index.html >>>>>>>> IllegalArgumentException isn't a good exception for these cases, is now the time to proposing this too? >>>>>>>> >>>>>>>> -Alan >>> >> > From harold.seigel at oracle.com Thu Jan 12 20:47:10 2017 From: harold.seigel at oracle.com (harold seigel) Date: Thu, 12 Jan 2017 15:47:10 -0500 Subject: RFR(S) 8172288: Fix error message when trying to define an existing package to a module In-Reply-To: <3ACE7772-2ACE-44EE-90BF-9313F7EC8F14@oracle.com> References: <7926a146-6005-5be0-dc8c-425ab8d5290f@oracle.com> <80b3e7ca-92f8-5af4-21f0-8ea32c79737f@oracle.com> <16D97CCA-E12E-4626-B526-8090866EE0ED@oracle.com> <785c4e8b-5288-2fb7-1ba8-e32374c7f29b@oracle.com> <36b7bd52-8b2c-92e0-d89a-1f8bb5bda27a@oracle.com> <3ACE7772-2ACE-44EE-90BF-9313F7EC8F14@oracle.com> Message-ID: Thanks Karen! Harold On 1/12/2017 3:46 PM, Karen Kinnear wrote: > Harold, > > This looks much cleaner! > > thanks, > Karen > >> On Jan 12, 2017, at 2:18 PM, harold seigel wrote: >> >> Hi, >> >> Please review this updated webrev: http://cr.openjdk.java.net/~hseigel/bug_8172288.hs.3/webrev/index.html >> >> It contains the three changes listed below. Only file modules.cpp has changed since the last webrev. >> >> This fix was tested with the JTreg hotspot, java/io, java/lang, java/util and other JTReg tests, with the JCK lang and VM tests, and with RBT tiers2 - tier5 tests on Linux X64. >> >> Thanks, Harold >> >> >> On 1/12/2017 10:16 AM, harold seigel wrote: >>> Thanks everyone for all the reviews. >>> >>> I'll post a new webrev with the following changes, and testing details, once the re-testing completes. >>> >>> 1. Rename throw_dup_pkg_IAE() to throw_dup_pkg_exception() >>> >>> 2. Remove the package_name argument from throw_dup_pkg_exception() because the package name can be extracted from the existing_pkg argument. >>> >>> 3. Remove dupl_pk_index and use existing_pkg instead. >>> >>> Harold >>> >>> >>> On 1/12/2017 9:30 AM, George Triantafillou wrote: >>>> Hi Karen, >>>> >>>> On 1/12/2017 9:26 AM, Karen Kinnear wrote: >>>>> Harold, >>>>> >>>>> Looks good - with the same minor comment George caught, perhaps throw_dup_pkg_exception? >>>>> >>>>> George - there are two tests attached. >>>> Thanks, I saw the additions to test/runtime/modules/JVMDefineModule.java, but I wanted to know which hotspot tests were run with Harold's change. >>>> >>>> -George >>>>> thanks, >>>>> Karen >>>>> >>>>>> On Jan 12, 2017, at 9:18 AM, George Triantafillou wrote: >>>>>> >>>>>> Hi Harold, >>>>>> >>>>>> src/share/vm/classfile/modules.cpp - lines 266, 449, and 806: >>>>>> >>>>>> Change "throw_dup_pkg_IAE" to "throw_dup_pkg_ISE". >>>>>> >>>>>> How was the change tested? Thanks. >>>>>> >>>>>> -George >>>>>> >>>>>> On 1/12/2017 8:50 AM, harold seigel wrote: >>>>>>> Hi, >>>>>>> >>>>>>> Please review this updated webrev for this bug. The updated webrev includes a small JDK change and hotspot changes to throw the correct exceptions. >>>>>>> >>>>>>> New JDK webrev: http://cr.openjdk.java.net/~hseigel/bug_8172288.jdk.2/webrev/index.html >>>>>>> >>>>>>> New Hotspot webrev: http://cr.openjdk.java.net/~hseigel/bug_8172288.hs.2/ >>>>>>> >>>>>>> Note also that the bug has been re-titled to: Fix Jigsaw related module/package error messages and throw correct exceptions >>>>>>> >>>>>>> Thanks, Harold >>>>>>> >>>>>>> On 1/10/2017 10:18 AM, harold seigel wrote: >>>>>>>> Yes. I'll modify the bug to include that. >>>>>>>> >>>>>>>> What exception should the JVM throw for this? >>>>>>>> >>>>>>>> Thanks, Harold >>>>>>>> >>>>>>>> >>>>>>>> On 1/10/2017 10:12 AM, Alan Bateman wrote: >>>>>>>>> On 10/01/2017 15:02, harold seigel wrote: >>>>>>>>> >>>>>>>>>> Hi, >>>>>>>>>> >>>>>>>>>> Please review this small fix for JDK-8172288. Here's a sample of the new message: >>>>>>>>>> >>>>>>>>>> Package mypackage6 for module dupl.pkg.module is already in another module, Module_A, defined to the class loader >>>>>>>>>> >>>>>>>>>> Adding the class loader name to the message will be done as part of JDK-8169559 . >>>>>>>>>> >>>>>>>>>> Open Webrev: http://cr.openjdk.java.net/~hseigel/bug_8172288/webrev/index.html >>>>>>>>> IllegalArgumentException isn't a good exception for these cases, is now the time to proposing this too? >>>>>>>>> >>>>>>>>> -Alan From chris.plummer at oracle.com Fri Jan 13 17:31:41 2017 From: chris.plummer at oracle.com (Chris Plummer) Date: Fri, 13 Jan 2017 09:31:41 -0800 Subject: RFR(M) 8155980: ARM InterpreterMacroAssembler::get_method_counters() should not be saving callee saved registers In-Reply-To: <21af92a7-7d33-eecf-5ae2-5b8871baf435@oracle.com> References: <70a61ffa-5d95-ae4f-2077-157f791675ec@oracle.com> <565d92d9-a254-3ffe-4775-64ad260b37a6@oracle.com> <21af92a7-7d33-eecf-5ae2-5b8871baf435@oracle.com> Message-ID: <0ac64d0e-25b9-7510-ebf1-b5d96f2f70c7@oracle.com> Here's an improvement on the second solution: http://cr.openjdk.java.net/~cjplummer/8155980/webrev.05/webrev.hotspot I make use of "noreg" to clean up handling the fact that 64-bit has to save a 3rd register and 32-bit does not. thanks, Chris On 1/11/17 9:53 AM, Chris Plummer wrote: > Here are a couple of different solutions: > > This first one uses an alternate branch label. It also adds saving > Rbumped_taken_count on AARCH64. Changes since the first solution are > only in templateTable_arm.cpp. > > http://cr.openjdk.java.net/~cjplummer/8155980/webrev.03/webrev.hotspot > > This second one moves the save/restore logic into > get_method_counters(). The registers to save have to be passed in. It > also adds saving Rbumped_taken_count on AARCH64. Changes since the > first solution are in templateTable_arm.cpp, interp_masm_arm.cpp, and > interp_masm_arm.hpp. > > http://cr.openjdk.java.net/~cjplummer/8155980/webrev.04/webrev.hotspot > > I think overall the second one looks cleaner. Save/restore logic is > all in one place, and is only done if call_VM() generated code is > actually executed. Possibly the handling of the Rbumped_taken_count > could be better to make it clear it's just for AARCH64. Maybe I could > use AARCH64_ONLY around the argument declaration and passing. > > thanks, > > Chris > > On 1/9/17 12:18 PM, Chris Plummer wrote: >> Sigh, there's a bug in the following: >> >> #ifdef AARCH64 >> __ stp(Rdisp, R3_bytecode, Address(Rstack_top, -2*wordSize, >> pre_indexed)); >> #else >> __ push(RegisterSet(Rdisp) | RegisterSet(R3_bytecode)); >> #endif >> __ get_method_counters(Rmethod, Rcounters, dispatch); >> #ifdef AARCH64 >> __ ldp(Rdisp, R3_bytecode, Address(Rstack_top, 2*wordSize, >> post_indexed)); >> #else >> __ pop(RegisterSet(Rdisp) | RegisterSet(R3_bytecode)); >> #endif >> >> Note that the "dispatch" label is passed to get_method_counters(), >> and it will generate code that branches to it, thus by passing the >> pop. Need to rethink this. I might need to introduce a new label >> just before the dispatch label that will do the pop. The other choice >> is possibly get_method_counters() should be told which registers to >> save. >> >> BTW, while looking over this code more carefully, it looks like for >> AARCH64, r5 also needs to be saved and restored. It's volatile on >> AARCH64, and is being used to store Rbumped_taken_count. >> >> Chris >> >> On 1/9/17 9:08 AM, Chris Plummer wrote: >>> Thanks Dean. Unfortunately I got a crash over the weekend when >>> repeatedly running one of our test suites. Happens about 1 out of 10 >>> times on both 32-bit and 64-bit. Looking into it now. >>> >>> Chris >>> >>> On 1/6/17 3:57 PM, dean.long at oracle.com wrote: >>>> It looks good but you might want to add a comment in >>>> TemplateTable::branch() saying something like: >>>> >>>> // save and restore caller-saved registers that will be trashed by >>>> call_VM >>>> >>>> dl >>>> >>>> >>>> On 1/6/17 3:14 PM, Chris Plummer wrote: >>>>> Hello, >>>>> >>>>> Please review the following arm changes. They will be pushed to >>>>> JDK 10 only (when it opens). >>>>> >>>>> https://bugs.openjdk.java.net/browse/JDK-8155980 >>>>> http://cr.openjdk.java.net/~cjplummer/8155980/webrev.02/webrev.hotspot >>>>> >>>>> >>>>> JDK-8012544 added a bunch of callee register saving to >>>>> InterpreterMacroAssembler::get_method_counters() around the >>>>> call_VM() call. The reason is because there are a couple of >>>>> callers of get_method_counters() that need to have r0 and r3 >>>>> preserved. get_method_counters() should not be responsible for >>>>> having to save callee saved registers. It does not know which ones >>>>> are in use when it is called, so it can't do this efficiently. In >>>>> fact 2 of the 4 callers of get_method_counters() do not need any >>>>> registers saved. For this reason the callee of >>>>> get_method_counters() should be responsible for saving callee >>>>> registers. >>>>> >>>>> This solution would have been been pretty straight forward, except >>>>> that AARCH64 does not allow SP to go above extended_sp, so when >>>>> setting up extended_sp I needed to make sure there will be room >>>>> for the 2 registers that need to be pushed. extended_sp is mainly >>>>> based on max_stack() for the method, plus an extra slot for jsr292 >>>>> and exception handling (but not both at the same time). So the fix >>>>> here is mostly about making sure there are always at least 2 extra >>>>> slots for pushing the 2 registers. >>>>> >>>>> Here are the changes: >>>>> >>>>> interp_masm_arm.cpp >>>>> -No longer save/restore registers in get_method_counters(): >>>>> >>>>> templateTable_arm.cpp: >>>>> -Save/restore Rdisp and R3_bytecode to stack around calls to >>>>> get_method_counters. >>>>> >>>>> abstractinterpreter__arm.cpp:: >>>>> -Properly account for extra 2 slots needed on AARCH64 when >>>>> creating a frame >>>>> in layout_activation() >>>>> -Note I switched to using method->constMethod()->max_stack() >>>>> because >>>>> method->max_stack() includes Method::extra_stack_entries(), and >>>>> I want to >>>>> account for Method::extra_stack_entries() separately. >>>>> >>>>> templateInterpreterGenerator_arm.cpp: >>>>> -Properly account for extra 2 slots needed on AARCH64 when >>>>> creating a frame >>>>> in generate_normal_entry(). >>>>> >>>>> I've tested the following with -Xcomp and with -Xmixed on arm32 >>>>> and arm64: >>>>> >>>>> Kitchensink >>>>> vm.mlvm >>>>> :jdk_svc >>>>> :hotspot_runtime >>>>> :hotspot_serviceability >>>>> :hotspot_compiler >>>>> :jdk_lang >>>>> :jdk_util >>>>> >>>>> I also tested the test case from JDK-8012544. >>>>> >>>>> thanks, >>>>> >>>>> Chris >>>>> >>>>> >>>> >>> >> > From rachel.protacio at oracle.com Fri Jan 13 21:39:06 2017 From: rachel.protacio at oracle.com (Rachel Protacio) Date: Fri, 13 Jan 2017 16:39:06 -0500 Subject: RFR(XS): 8170827: Correct errant "java.base" string to macro Message-ID: Hi! Please review this small bug fix, changing one remaining "java.base" string to the JAVA_BASE_NAME macro. Bug: https://bugs.openjdk.java.net/browse/JDK-8170827 Open webrev: http://cr.openjdk.java.net/~rprotacio/8170827.00/ Thanks! Rachel From coleen.phillimore at oracle.com Fri Jan 13 21:54:03 2017 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Fri, 13 Jan 2017 16:54:03 -0500 Subject: RFR(XS): 8170827: Correct errant "java.base" string to macro In-Reply-To: References: Message-ID: <6bda0001-66f5-d949-0b2e-370a3882aeb8@oracle.com> This looks good. Since it's a small cleanup of a jdk9 change, I think this should go in jdk9 also. Coleen On 1/13/17 4:39 PM, Rachel Protacio wrote: > Hi! > > Please review this small bug fix, changing one remaining "java.base" > string to the JAVA_BASE_NAME macro. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8170827 > Open webrev: http://cr.openjdk.java.net/~rprotacio/8170827.00/ > > Thanks! > Rachel From jiangli.zhou at oracle.com Fri Jan 13 21:54:18 2017 From: jiangli.zhou at oracle.com (Jiangli Zhou) Date: Fri, 13 Jan 2017 13:54:18 -0800 Subject: RFR(XS): 8170827: Correct errant "java.base" string to macro In-Reply-To: References: Message-ID: Hi Rachel, Looks good. Thanks, Jiangli > On Jan 13, 2017, at 1:39 PM, Rachel Protacio wrote: > > Hi! > > Please review this small bug fix, changing one remaining "java.base" string to the JAVA_BASE_NAME macro. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8170827 > Open webrev: http://cr.openjdk.java.net/~rprotacio/8170827.00/ > > Thanks! > Rachel From rachel.protacio at oracle.com Fri Jan 13 22:10:33 2017 From: rachel.protacio at oracle.com (Rachel Protacio) Date: Fri, 13 Jan 2017 17:10:33 -0500 Subject: RFR(XS): 8170827: Correct errant "java.base" string to macro In-Reply-To: <6bda0001-66f5-d949-0b2e-370a3882aeb8@oracle.com> References: <6bda0001-66f5-d949-0b2e-370a3882aeb8@oracle.com> Message-ID: <255e13b7-fd39-f19e-caba-dd9c57267566@oracle.com> Thanks, Jiangli and Coleen! I'll check it in since it's trivial. Rachel On 1/13/2017 4:54 PM, Coleen Phillimore wrote: > This looks good. Since it's a small cleanup of a jdk9 change, I think > this should go in jdk9 also. > > Coleen > > On 1/13/17 4:39 PM, Rachel Protacio wrote: >> Hi! >> >> Please review this small bug fix, changing one remaining "java.base" >> string to the JAVA_BASE_NAME macro. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8170827 >> Open webrev: http://cr.openjdk.java.net/~rprotacio/8170827.00/ >> >> Thanks! >> Rachel > From coleen.phillimore at oracle.com Tue Jan 17 18:49:17 2017 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Tue, 17 Jan 2017 13:49:17 -0500 Subject: RFR (S) 8144518: ClassVerboseTest crashes on Windows Message-ID: Summary: simplify Bytecode_tableswitch code so windows doesn't generate bad code for it. open webrev at http://cr.openjdk.java.net/~coleenp/8144518.01/webrev bug link https://bugs.openjdk.java.net/browse/JDK-8144518 Verified generated code does not have sign extended value that is subtracted, giving the wrong offset. Ran all rbt nightly tests. Ran some -Xcomp tests. See more info in bug https://bugs.openjdk.java.net/browse/JDK-8171968 Thanks, Coleen From christian.tornqvist at oracle.com Tue Jan 17 20:58:53 2017 From: christian.tornqvist at oracle.com (Christian Tornqvist) Date: Tue, 17 Jan 2017 15:58:53 -0500 Subject: RFR (S) 8144518: ClassVerboseTest crashes on Windows In-Reply-To: References: Message-ID: <034a01d27104$83a2d420$8ae87c60$@oracle.com> Hi Coleen, This looks like a good workaround. Thanks, Christian -----Original Message----- From: hotspot-runtime-dev [mailto:hotspot-runtime-dev-bounces at openjdk.java.net] On Behalf Of Coleen Phillimore Sent: Tuesday, January 17, 2017 1:49 PM To: hotspot-runtime-dev Subject: RFR (S) 8144518: ClassVerboseTest crashes on Windows Summary: simplify Bytecode_tableswitch code so windows doesn't generate bad code for it. open webrev at http://cr.openjdk.java.net/~coleenp/8144518.01/webrev bug link https://bugs.openjdk.java.net/browse/JDK-8144518 Verified generated code does not have sign extended value that is subtracted, giving the wrong offset. Ran all rbt nightly tests. Ran some -Xcomp tests. See more info in bug https://bugs.openjdk.java.net/browse/JDK-8171968 Thanks, Coleen From coleen.phillimore at oracle.com Tue Jan 17 21:35:28 2017 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Tue, 17 Jan 2017 16:35:28 -0500 Subject: RFR (S) 8144518: ClassVerboseTest crashes on Windows In-Reply-To: <034a01d27104$83a2d420$8ae87c60$@oracle.com> References: <034a01d27104$83a2d420$8ae87c60$@oracle.com> Message-ID: <76465ceb-9eb4-0d66-fa30-ab99781591f1@oracle.com> Thank you Christian! Thanks for the help with this bug and for making us suspicious in the first place, of the generated code. Coleen On 1/17/17 3:58 PM, Christian Tornqvist wrote: > Hi Coleen, > > This looks like a good workaround. > > Thanks, > Christian > > -----Original Message----- > From: hotspot-runtime-dev [mailto:hotspot-runtime-dev-bounces at openjdk.java.net] On Behalf Of Coleen Phillimore > Sent: Tuesday, January 17, 2017 1:49 PM > To: hotspot-runtime-dev > Subject: RFR (S) 8144518: ClassVerboseTest crashes on Windows > > Summary: simplify Bytecode_tableswitch code so windows doesn't generate bad code for it. > > open webrev at http://cr.openjdk.java.net/~coleenp/8144518.01/webrev > bug link https://bugs.openjdk.java.net/browse/JDK-8144518 > > Verified generated code does not have sign extended value that is subtracted, giving the wrong offset. Ran all rbt nightly tests. Ran some -Xcomp tests. > > See more info in bug https://bugs.openjdk.java.net/browse/JDK-8171968 > > Thanks, > Coleen > > > From jiangli.zhou at Oracle.COM Tue Jan 17 22:30:09 2017 From: jiangli.zhou at Oracle.COM (Jiangli Zhou) Date: Tue, 17 Jan 2017 14:30:09 -0800 Subject: RFR(M) 8155980: ARM InterpreterMacroAssembler::get_method_counters() should not be saving callee saved registers In-Reply-To: <0ac64d0e-25b9-7510-ebf1-b5d96f2f70c7@oracle.com> References: <70a61ffa-5d95-ae4f-2077-157f791675ec@oracle.com> <565d92d9-a254-3ffe-4775-64ad260b37a6@oracle.com> <21af92a7-7d33-eecf-5ae2-5b8871baf435@oracle.com> <0ac64d0e-25b9-7510-ebf1-b5d96f2f70c7@oracle.com> Message-ID: <230CD0F9-07D6-4B09-8898-4E494586FC68@oracle.com> Hi Chris, I like the second solution too. I?d suggest to add asserts in get_method_counters() to make sure reg1, reg2 and reg3 are valid registers (not noreg) when ?saveRegs? is true. In TemplateTable::branch(), why Bumped_taken_count is only save/restored for AARCH64? The following usage does not seem to be AARCH64 only. 2322 if (UseOnStackReplacement) { 2323 // check for overflow against Rbumped_taken_count, which is the MDO taken count 2324 const Address backward_branch_limit(Rcounters, in_bytes(MethodCounters::interpreter_backward_branch_limit_offset())); 2325 __ ldr_s32(Rtemp, backward_branch_limit); 2326 __ cmp(Rbumped_taken_count, Rtemp); 2327 __ b(dispatch, lo); Thanks, Jiangli > On Jan 13, 2017, at 9:31 AM, Chris Plummer wrote: > > Here's an improvement on the second solution: > > http://cr.openjdk.java.net/~cjplummer/8155980/webrev.05/webrev.hotspot > > I make use of "noreg" to clean up handling the fact that 64-bit has to save a 3rd register and 32-bit does not. > > thanks, > > Chris > > On 1/11/17 9:53 AM, Chris Plummer wrote: >> Here are a couple of different solutions: >> >> This first one uses an alternate branch label. It also adds saving Rbumped_taken_count on AARCH64. Changes since the first solution are only in templateTable_arm.cpp. >> >> http://cr.openjdk.java.net/~cjplummer/8155980/webrev.03/webrev.hotspot >> >> This second one moves the save/restore logic into get_method_counters(). The registers to save have to be passed in. It also adds saving Rbumped_taken_count on AARCH64. Changes since the first solution are in templateTable_arm.cpp, interp_masm_arm.cpp, and interp_masm_arm.hpp. >> >> http://cr.openjdk.java.net/~cjplummer/8155980/webrev.04/webrev.hotspot >> >> I think overall the second one looks cleaner. Save/restore logic is all in one place, and is only done if call_VM() generated code is actually executed. Possibly the handling of the Rbumped_taken_count could be better to make it clear it's just for AARCH64. Maybe I could use AARCH64_ONLY around the argument declaration and passing. >> >> thanks, >> >> Chris >> >> On 1/9/17 12:18 PM, Chris Plummer wrote: >>> Sigh, there's a bug in the following: >>> >>> #ifdef AARCH64 >>> __ stp(Rdisp, R3_bytecode, Address(Rstack_top, -2*wordSize, pre_indexed)); >>> #else >>> __ push(RegisterSet(Rdisp) | RegisterSet(R3_bytecode)); >>> #endif >>> __ get_method_counters(Rmethod, Rcounters, dispatch); >>> #ifdef AARCH64 >>> __ ldp(Rdisp, R3_bytecode, Address(Rstack_top, 2*wordSize, post_indexed)); >>> #else >>> __ pop(RegisterSet(Rdisp) | RegisterSet(R3_bytecode)); >>> #endif >>> >>> Note that the "dispatch" label is passed to get_method_counters(), and it will generate code that branches to it, thus by passing the pop. Need to rethink this. I might need to introduce a new label just before the dispatch label that will do the pop. The other choice is possibly get_method_counters() should be told which registers to save. >>> >>> BTW, while looking over this code more carefully, it looks like for AARCH64, r5 also needs to be saved and restored. It's volatile on AARCH64, and is being used to store Rbumped_taken_count. >>> >>> Chris >>> >>> On 1/9/17 9:08 AM, Chris Plummer wrote: >>>> Thanks Dean. Unfortunately I got a crash over the weekend when repeatedly running one of our test suites. Happens about 1 out of 10 times on both 32-bit and 64-bit. Looking into it now. >>>> >>>> Chris >>>> >>>> On 1/6/17 3:57 PM, dean.long at oracle.com wrote: >>>>> It looks good but you might want to add a comment in TemplateTable::branch() saying something like: >>>>> >>>>> // save and restore caller-saved registers that will be trashed by call_VM >>>>> >>>>> dl >>>>> >>>>> >>>>> On 1/6/17 3:14 PM, Chris Plummer wrote: >>>>>> Hello, >>>>>> >>>>>> Please review the following arm changes. They will be pushed to JDK 10 only (when it opens). >>>>>> >>>>>> https://bugs.openjdk.java.net/browse/JDK-8155980 >>>>>> http://cr.openjdk.java.net/~cjplummer/8155980/webrev.02/webrev.hotspot >>>>>> >>>>>> JDK-8012544 added a bunch of callee register saving to InterpreterMacroAssembler::get_method_counters() around the call_VM() call. The reason is because there are a couple of callers of get_method_counters() that need to have r0 and r3 preserved. get_method_counters() should not be responsible for having to save callee saved registers. It does not know which ones are in use when it is called, so it can't do this efficiently. In fact 2 of the 4 callers of get_method_counters() do not need any registers saved. For this reason the callee of get_method_counters() should be responsible for saving callee registers. >>>>>> >>>>>> This solution would have been been pretty straight forward, except that AARCH64 does not allow SP to go above extended_sp, so when setting up extended_sp I needed to make sure there will be room for the 2 registers that need to be pushed. extended_sp is mainly based on max_stack() for the method, plus an extra slot for jsr292 and exception handling (but not both at the same time). So the fix here is mostly about making sure there are always at least 2 extra slots for pushing the 2 registers. >>>>>> >>>>>> Here are the changes: >>>>>> >>>>>> interp_masm_arm.cpp >>>>>> -No longer save/restore registers in get_method_counters(): >>>>>> >>>>>> templateTable_arm.cpp: >>>>>> -Save/restore Rdisp and R3_bytecode to stack around calls to get_method_counters. >>>>>> >>>>>> abstractinterpreter__arm.cpp:: >>>>>> -Properly account for extra 2 slots needed on AARCH64 when creating a frame >>>>>> in layout_activation() >>>>>> -Note I switched to using method->constMethod()->max_stack() because >>>>>> method->max_stack() includes Method::extra_stack_entries(), and I want to >>>>>> account for Method::extra_stack_entries() separately. >>>>>> >>>>>> templateInterpreterGenerator_arm.cpp: >>>>>> -Properly account for extra 2 slots needed on AARCH64 when creating a frame >>>>>> in generate_normal_entry(). >>>>>> >>>>>> I've tested the following with -Xcomp and with -Xmixed on arm32 and arm64: >>>>>> >>>>>> Kitchensink >>>>>> vm.mlvm >>>>>> :jdk_svc >>>>>> :hotspot_runtime >>>>>> :hotspot_serviceability >>>>>> :hotspot_compiler >>>>>> :jdk_lang >>>>>> :jdk_util >>>>>> >>>>>> I also tested the test case from JDK-8012544. >>>>>> >>>>>> thanks, >>>>>> >>>>>> Chris >>>>>> >>>>>> >>>>> >>>> >>> >> > From jiangli.zhou at oracle.com Tue Jan 17 23:11:16 2017 From: jiangli.zhou at oracle.com (Jiangli Zhou) Date: Tue, 17 Jan 2017 15:11:16 -0800 Subject: RFR(M) 8155980: ARM InterpreterMacroAssembler::get_method_counters() should not be saving callee saved registers In-Reply-To: <4922621e-73cf-1f66-b635-84572e3ad59e@oracle.com> References: <70a61ffa-5d95-ae4f-2077-157f791675ec@oracle.com> <565d92d9-a254-3ffe-4775-64ad260b37a6@oracle.com> <21af92a7-7d33-eecf-5ae2-5b8871baf435@oracle.com> <0ac64d0e-25b9-7510-ebf1-b5d96f2f70c7@oracle.com> <230CD0F9-07D6-4B09-8898-4E494586FC68@oracle.com> <4922621e-73cf-1f66-b635-84572e3ad59e@oracle.com> Message-ID: Hi Chris, > On Jan 17, 2017, at 2:55 PM, Chris Plummer wrote: > > On 1/17/17 2:30 PM, Jiangli Zhou wrote: >> Hi Chris, >> >> I like the second solution too. I?d suggest to add asserts in get_method_counters() to make sure reg1, reg2 and reg3 are valid registers (not noreg) when ?saveRegs? is true. > Ok. >> >> In TemplateTable::branch(), why Bumped_taken_count is only save/restored for AARCH64? The following usage does not seem to be AARCH64 only. >> >> 2322 if (UseOnStackReplacement) { >> 2323 // check for overflow against Rbumped_taken_count, which is the MDO taken count >> 2324 const Address backward_branch_limit(Rcounters, in_bytes(MethodCounters::interpreter_backward_branch_limit_offset())); >> 2325 __ ldr_s32(Rtemp, backward_branch_limit); >> 2326 __ cmp(Rbumped_taken_count, Rtemp); >> 2327 __ b(dispatch, lo); > Because R5 is a callee saved registers for ARM32, but caller saved for ARM64. Ok. Can you please add above information in the comment in case someone has the same question when looking at the code in the future. Thanks, Jiangli > > thanks, > > Chris >> Thanks, >> Jiangli >> >>> On Jan 13, 2017, at 9:31 AM, Chris Plummer > wrote: >>> >>> Here's an improvement on the second solution: >>> >>> http://cr.openjdk.java.net/~cjplummer/8155980/webrev.05/webrev.hotspot >>> >>> I make use of "noreg" to clean up handling the fact that 64-bit has to save a 3rd register and 32-bit does not. >>> >>> thanks, >>> >>> Chris >>> >>> On 1/11/17 9:53 AM, Chris Plummer wrote: >>>> Here are a couple of different solutions: >>>> >>>> This first one uses an alternate branch label. It also adds saving Rbumped_taken_count on AARCH64. Changes since the first solution are only in templateTable_arm.cpp. >>>> >>>> http://cr.openjdk.java.net/~cjplummer/8155980/webrev.03/webrev.hotspot >>>> >>>> This second one moves the save/restore logic into get_method_counters(). The registers to save have to be passed in. It also adds saving Rbumped_taken_count on AARCH64. Changes since the first solution are in templateTable_arm.cpp, interp_masm_arm.cpp, and interp_masm_arm.hpp. >>>> >>>> http://cr.openjdk.java.net/~cjplummer/8155980/webrev.04/webrev.hotspot >>>> >>>> I think overall the second one looks cleaner. Save/restore logic is all in one place, and is only done if call_VM() generated code is actually executed. Possibly the handling of the Rbumped_taken_count could be better to make it clear it's just for AARCH64. Maybe I could use AARCH64_ONLY around the argument declaration and passing. >>>> >>>> thanks, >>>> >>>> Chris >>>> >>>> On 1/9/17 12:18 PM, Chris Plummer wrote: >>>>> Sigh, there's a bug in the following: >>>>> >>>>> #ifdef AARCH64 >>>>> __ stp(Rdisp, R3_bytecode, Address(Rstack_top, -2*wordSize, pre_indexed)); >>>>> #else >>>>> __ push(RegisterSet(Rdisp) | RegisterSet(R3_bytecode)); >>>>> #endif >>>>> __ get_method_counters(Rmethod, Rcounters, dispatch); >>>>> #ifdef AARCH64 >>>>> __ ldp(Rdisp, R3_bytecode, Address(Rstack_top, 2*wordSize, post_indexed)); >>>>> #else >>>>> __ pop(RegisterSet(Rdisp) | RegisterSet(R3_bytecode)); >>>>> #endif >>>>> >>>>> Note that the "dispatch" label is passed to get_method_counters(), and it will generate code that branches to it, thus by passing the pop. Need to rethink this. I might need to introduce a new label just before the dispatch label that will do the pop. The other choice is possibly get_method_counters() should be told which registers to save. >>>>> >>>>> BTW, while looking over this code more carefully, it looks like for AARCH64, r5 also needs to be saved and restored. It's volatile on AARCH64, and is being used to store Rbumped_taken_count. >>>>> >>>>> Chris >>>>> >>>>> On 1/9/17 9:08 AM, Chris Plummer wrote: >>>>>> Thanks Dean. Unfortunately I got a crash over the weekend when repeatedly running one of our test suites. Happens about 1 out of 10 times on both 32-bit and 64-bit. Looking into it now. >>>>>> >>>>>> Chris >>>>>> >>>>>> On 1/6/17 3:57 PM, dean.long at oracle.com wrote: >>>>>>> It looks good but you might want to add a comment in TemplateTable::branch() saying something like: >>>>>>> >>>>>>> // save and restore caller-saved registers that will be trashed by call_VM >>>>>>> >>>>>>> dl >>>>>>> >>>>>>> >>>>>>> On 1/6/17 3:14 PM, Chris Plummer wrote: >>>>>>>> Hello, >>>>>>>> >>>>>>>> Please review the following arm changes. They will be pushed to JDK 10 only (when it opens). >>>>>>>> >>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8155980 >>>>>>>> http://cr.openjdk.java.net/~cjplummer/8155980/webrev.02/webrev.hotspot >>>>>>>> >>>>>>>> JDK-8012544 added a bunch of callee register saving to InterpreterMacroAssembler::get_method_counters() around the call_VM() call. The reason is because there are a couple of callers of get_method_counters() that need to have r0 and r3 preserved. get_method_counters() should not be responsible for having to save callee saved registers. It does not know which ones are in use when it is called, so it can't do this efficiently. In fact 2 of the 4 callers of get_method_counters() do not need any registers saved. For this reason the callee of get_method_counters() should be responsible for saving callee registers. >>>>>>>> >>>>>>>> This solution would have been been pretty straight forward, except that AARCH64 does not allow SP to go above extended_sp, so when setting up extended_sp I needed to make sure there will be room for the 2 registers that need to be pushed. extended_sp is mainly based on max_stack() for the method, plus an extra slot for jsr292 and exception handling (but not both at the same time). So the fix here is mostly about making sure there are always at least 2 extra slots for pushing the 2 registers. >>>>>>>> >>>>>>>> Here are the changes: >>>>>>>> >>>>>>>> interp_masm_arm.cpp >>>>>>>> -No longer save/restore registers in get_method_counters(): >>>>>>>> >>>>>>>> templateTable_arm.cpp: >>>>>>>> -Save/restore Rdisp and R3_bytecode to stack around calls to get_method_counters. >>>>>>>> >>>>>>>> abstractinterpreter__arm.cpp:: >>>>>>>> -Properly account for extra 2 slots needed on AARCH64 when creating a frame >>>>>>>> in layout_activation() >>>>>>>> -Note I switched to using method->constMethod()->max_stack() because >>>>>>>> method->max_stack() includes Method::extra_stack_entries(), and I want to >>>>>>>> account for Method::extra_stack_entries() separately. >>>>>>>> >>>>>>>> templateInterpreterGenerator_arm.cpp: >>>>>>>> -Properly account for extra 2 slots needed on AARCH64 when creating a frame >>>>>>>> in generate_normal_entry(). >>>>>>>> >>>>>>>> I've tested the following with -Xcomp and with -Xmixed on arm32 and arm64: >>>>>>>> >>>>>>>> Kitchensink >>>>>>>> vm.mlvm >>>>>>>> :jdk_svc >>>>>>>> :hotspot_runtime >>>>>>>> :hotspot_serviceability >>>>>>>> :hotspot_compiler >>>>>>>> :jdk_lang >>>>>>>> :jdk_util >>>>>>>> >>>>>>>> I also tested the test case from JDK-8012544. >>>>>>>> >>>>>>>> thanks, >>>>>>>> >>>>>>>> Chris >>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> > From david.holmes at oracle.com Wed Jan 18 00:02:45 2017 From: david.holmes at oracle.com (David Holmes) Date: Wed, 18 Jan 2017 10:02:45 +1000 Subject: RFR (S) 8144518: ClassVerboseTest crashes on Windows In-Reply-To: References: Message-ID: Hi Coleen, The bug report does not explain the problem so it is unclear whether this workaround is minimal. Also some commentary somewhere would be useful else the bug might return inadvertently - more generally I'd like to understand what other code might be impacted by this. Thanks, David On 18/01/2017 8:49 AM, Coleen Phillimore wrote: > I should have also sent this to hotspot-dev, since Bytecode_tableswitch > is used by the compiler ci code. > thanks, > Coleen > > > On 1/17/17 1:49 PM, Coleen Phillimore wrote: >> Summary: simplify Bytecode_tableswitch code so windows doesn't >> generate bad code for it. >> >> open webrev at http://cr.openjdk.java.net/~coleenp/8144518.01/webrev >> bug link https://bugs.openjdk.java.net/browse/JDK-8144518 >> >> Verified generated code does not have sign extended value that is >> subtracted, giving the wrong offset. Ran all rbt nightly tests. Ran >> some -Xcomp tests. >> >> See more info in bug https://bugs.openjdk.java.net/browse/JDK-8171968 >> >> Thanks, >> Coleen >> >> > From coleen.phillimore at oracle.com Wed Jan 18 02:13:13 2017 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Tue, 17 Jan 2017 21:13:13 -0500 Subject: RFR (S) 8144518: ClassVerboseTest crashes on Windows In-Reply-To: References: Message-ID: On 1/17/17 7:02 PM, David Holmes wrote: > Hi Coleen, > > The bug report does not explain the problem so it is unclear whether > this workaround is minimal. Also some commentary somewhere would be > useful else the bug might return inadvertently - more generally I'd > like to understand what other code might be impacted by this. Christian and I spent a solid week looking for the windows Visual Studio bug that caused this but weren't able to find it. He verified that it's fixed in VS2015. I think that's in the bug report. The code generated is in the bug report with annotations of what lines the code it was executing and which instructions caused the truncation and sign extension leading to a negative offset from the start of _bcp. There's a small reproducer in the bug report for 8144518. I did a grep of all the "address.*-" and looked through the lines of code but I didn't generate windows assembly code to examine for all the pointer subtractions. I don't plan to do this. From the reproducer, there needed to be the swap_u4, even though the load that crashed was before the swap_u4 code. The scenario that caused this bug seems very specific and if it exists in any other places in the jvm, we can keep an eye out for it. This crash, while intermittent, was fairly consistent. We think it's best to get this workaround into jdk 9 before ZBB since this bug has been seen several times, and we finally narrowed down the problem and don't have to close it as not reproduceable again. There is a line above the dest_offset_at code which I was going to remove, since it's describing code I changed, which doesn't make for a good comment. Any further commentary or explanation of this bug will be vague, since we don't have the VS compiler to debug to find the real problem, and won't make sense in the source code. Did you look at the code? It's a simplification of the expression that was in the original, that would have been better from the start. Thanks, Coleen > > Thanks, > David > > On 18/01/2017 8:49 AM, Coleen Phillimore wrote: >> I should have also sent this to hotspot-dev, since Bytecode_tableswitch >> is used by the compiler ci code. >> thanks, >> Coleen >> >> >> On 1/17/17 1:49 PM, Coleen Phillimore wrote: >>> Summary: simplify Bytecode_tableswitch code so windows doesn't >>> generate bad code for it. >>> >>> open webrev at http://cr.openjdk.java.net/~coleenp/8144518.01/webrev >>> bug link https://bugs.openjdk.java.net/browse/JDK-8144518 >>> >>> Verified generated code does not have sign extended value that is >>> subtracted, giving the wrong offset. Ran all rbt nightly tests. Ran >>> some -Xcomp tests. >>> >>> See more info in bug https://bugs.openjdk.java.net/browse/JDK-8171968 >>> >>> Thanks, >>> Coleen >>> >>> >> From coleen.phillimore at oracle.com Wed Jan 18 02:24:01 2017 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Tue, 17 Jan 2017 21:24:01 -0500 Subject: RFR (S) 8144518: ClassVerboseTest crashes on Windows In-Reply-To: References: Message-ID: <8b8c90b7-92d7-8593-a20c-42038d95a982@oracle.com> Actually, I did look at Bytecodes::_tableswitch handling through the jvm and both other instances (verifier and relocator) that don't use Bytecode_tableswitch use different address calculation. They align the bcp to u4 first and then do get_Java_u4(). The relocator has the disturbing comment // We cannot use the Bytecode_tableswitch abstraction, since the padding might not be correct. This is because the code stream has had code inserted at this point. Coleen On 1/17/17 9:13 PM, Coleen Phillimore wrote: > > > On 1/17/17 7:02 PM, David Holmes wrote: >> Hi Coleen, >> >> The bug report does not explain the problem so it is unclear whether >> this workaround is minimal. Also some commentary somewhere would be >> useful else the bug might return inadvertently - more generally I'd >> like to understand what other code might be impacted by this. > > Christian and I spent a solid week looking for the windows Visual > Studio bug that caused this but weren't able to find it. He verified > that it's fixed in VS2015. I think that's in the bug report. The > code generated is in the bug report with annotations of what lines the > code it was executing and which instructions caused the truncation and > sign extension leading to a negative offset from the start of _bcp. > > There's a small reproducer in the bug report for 8144518. > > I did a grep of all the "address.*-" and looked through the lines of > code but I didn't generate windows assembly code to examine for all > the pointer subtractions. I don't plan to do this. From the > reproducer, there needed to be the swap_u4, even though the load that > crashed was before the swap_u4 code. The scenario that caused this > bug seems very specific and if it exists in any other places in the > jvm, we can keep an eye out for it. This crash, while intermittent, > was fairly consistent. > > We think it's best to get this workaround into jdk 9 before ZBB since > this bug has been seen several times, and we finally narrowed down the > problem and don't have to close it as not reproduceable again. > > There is a line above the dest_offset_at code which I was going to > remove, since it's describing code I changed, which doesn't make for a > good comment. Any further commentary or explanation of this bug will > be vague, since we don't have the VS compiler to debug to find the > real problem, and won't make sense in the source code. > > Did you look at the code? It's a simplification of the expression that > was in the original, that would have been better from the start. > > Thanks, > Coleen > >> >> Thanks, >> David >> >> On 18/01/2017 8:49 AM, Coleen Phillimore wrote: >>> I should have also sent this to hotspot-dev, since Bytecode_tableswitch >>> is used by the compiler ci code. >>> thanks, >>> Coleen >>> >>> >>> On 1/17/17 1:49 PM, Coleen Phillimore wrote: >>>> Summary: simplify Bytecode_tableswitch code so windows doesn't >>>> generate bad code for it. >>>> >>>> open webrev at http://cr.openjdk.java.net/~coleenp/8144518.01/webrev >>>> bug link https://bugs.openjdk.java.net/browse/JDK-8144518 >>>> >>>> Verified generated code does not have sign extended value that is >>>> subtracted, giving the wrong offset. Ran all rbt nightly tests. Ran >>>> some -Xcomp tests. >>>> >>>> See more info in bug https://bugs.openjdk.java.net/browse/JDK-8171968 >>>> >>>> Thanks, >>>> Coleen >>>> >>>> >>> > From david.holmes at oracle.com Wed Jan 18 02:57:34 2017 From: david.holmes at oracle.com (David Holmes) Date: Wed, 18 Jan 2017 12:57:34 +1000 Subject: RFR (S) 8144518: ClassVerboseTest crashes on Windows In-Reply-To: References: Message-ID: Hi Coleen, On 18/01/2017 12:13 PM, Coleen Phillimore wrote: > > > On 1/17/17 7:02 PM, David Holmes wrote: >> Hi Coleen, >> >> The bug report does not explain the problem so it is unclear whether >> this workaround is minimal. Also some commentary somewhere would be >> useful else the bug might return inadvertently - more generally I'd >> like to understand what other code might be impacted by this. > > Christian and I spent a solid week looking for the windows Visual Studio > bug that caused this but weren't able to find it. He verified that it's > fixed in VS2015. I think that's in the bug report. The code generated > is in the bug report with annotations of what lines the code it was > executing and which instructions caused the truncation and sign > extension leading to a negative offset from the start of _bcp. I'm not seeing that listing in the bug report. What code was generated versus what code should have been generated is precisely what I was looking for. And some idea of what problematic source code looks like. > There's a small reproducer in the bug report for 8144518. > > I did a grep of all the "address.*-" and looked through the lines of > code but I didn't generate windows assembly code to examine for all the > pointer subtractions. I don't plan to do this. From the reproducer, > there needed to be the swap_u4, even though the load that crashed was > before the swap_u4 code. The scenario that caused this bug seems very > specific and if it exists in any other places in the jvm, we can keep an > eye out for it. This crash, while intermittent, was fairly consistent. Very intermittent - so I guess we rarely hit the incorrectly compiled code path. > We think it's best to get this workaround into jdk 9 before ZBB since > this bug has been seen several times, and we finally narrowed down the > problem and don't have to close it as not reproduceable again. > > There is a line above the dest_offset_at code which I was going to > remove, since it's describing code I changed, which doesn't make for a > good comment. Any further commentary or explanation of this bug will be > vague, since we don't have the VS compiler to debug to find the real > problem, and won't make sense in the source code. > > Did you look at the code? It's a simplification of the expression that > was in the original, that would have been better from the start. Yes I looked at the code. AFAICS you now pass in an unaligned value and align it internally, while previously the caller had to do the alignment first - right? That inversion somehow bypasses the code that gets incorrectly compiled. Thanks, David ----- > Thanks, > Coleen > >> >> Thanks, >> David >> >> On 18/01/2017 8:49 AM, Coleen Phillimore wrote: >>> I should have also sent this to hotspot-dev, since Bytecode_tableswitch >>> is used by the compiler ci code. >>> thanks, >>> Coleen >>> >>> >>> On 1/17/17 1:49 PM, Coleen Phillimore wrote: >>>> Summary: simplify Bytecode_tableswitch code so windows doesn't >>>> generate bad code for it. >>>> >>>> open webrev at http://cr.openjdk.java.net/~coleenp/8144518.01/webrev >>>> bug link https://bugs.openjdk.java.net/browse/JDK-8144518 >>>> >>>> Verified generated code does not have sign extended value that is >>>> subtracted, giving the wrong offset. Ran all rbt nightly tests. Ran >>>> some -Xcomp tests. >>>> >>>> See more info in bug https://bugs.openjdk.java.net/browse/JDK-8171968 >>>> >>>> Thanks, >>>> Coleen >>>> >>>> >>> > From kim.barrett at oracle.com Wed Jan 18 04:03:51 2017 From: kim.barrett at oracle.com (Kim Barrett) Date: Tue, 17 Jan 2017 23:03:51 -0500 Subject: RFR (S) 8144518: ClassVerboseTest crashes on Windows In-Reply-To: References: Message-ID: <93DCB66B-7F04-48FC-B44A-083293B892DE@oracle.com> > On Jan 17, 2017, at 9:57 PM, David Holmes wrote: > > Hi Coleen, > > On 18/01/2017 12:13 PM, Coleen Phillimore wrote: >> >> >> On 1/17/17 7:02 PM, David Holmes wrote: >>> Hi Coleen, >>> >>> The bug report does not explain the problem so it is unclear whether >>> this workaround is minimal. Also some commentary somewhere would be >>> useful else the bug might return inadvertently - more generally I'd >>> like to understand what other code might be impacted by this. >> >> Christian and I spent a solid week looking for the windows Visual Studio >> bug that caused this but weren't able to find it. He verified that it's >> fixed in VS2015. I think that's in the bug report. The code generated >> is in the bug report with annotations of what lines the code it was >> executing and which instructions caused the truncation and sign >> extension leading to a negative offset from the start of _bcp. > > I'm not seeing that listing in the bug report. What code was generated versus what code should have been generated is precisely what I was looking for. And some idea of what problematic source code looks like. Some (most?) of the analysis and reproducer that Coleen is referring to are over in the duplicate https://bugs.openjdk.java.net/browse/JDK-8171968 From david.holmes at oracle.com Wed Jan 18 04:16:49 2017 From: david.holmes at oracle.com (David Holmes) Date: Wed, 18 Jan 2017 14:16:49 +1000 Subject: RFR (S) 8144518: ClassVerboseTest crashes on Windows In-Reply-To: <93DCB66B-7F04-48FC-B44A-083293B892DE@oracle.com> References: <93DCB66B-7F04-48FC-B44A-083293B892DE@oracle.com> Message-ID: <26c3e633-567e-1e4d-9d40-9bdfb4e06fcb@oracle.com> On 18/01/2017 2:03 PM, Kim Barrett wrote: >> On Jan 17, 2017, at 9:57 PM, David Holmes wrote: >> >> Hi Coleen, >> >> On 18/01/2017 12:13 PM, Coleen Phillimore wrote: >>> >>> >>> On 1/17/17 7:02 PM, David Holmes wrote: >>>> Hi Coleen, >>>> >>>> The bug report does not explain the problem so it is unclear whether >>>> this workaround is minimal. Also some commentary somewhere would be >>>> useful else the bug might return inadvertently - more generally I'd >>>> like to understand what other code might be impacted by this. >>> >>> Christian and I spent a solid week looking for the windows Visual Studio >>> bug that caused this but weren't able to find it. He verified that it's >>> fixed in VS2015. I think that's in the bug report. The code generated >>> is in the bug report with annotations of what lines the code it was >>> executing and which instructions caused the truncation and sign >>> extension leading to a negative offset from the start of _bcp. >> >> I'm not seeing that listing in the bug report. What code was generated versus what code should have been generated is precisely what I was looking for. And some idea of what problematic source code looks like. > > Some (most?) of the analysis and reproducer that Coleen is referring to are over in the duplicate > https://bugs.openjdk.java.net/browse/JDK-8171968 Ah! Thanks Kim. Coleen: all much clearer now. Reviewed. Thanks, David From thomas.stuefe at gmail.com Wed Jan 18 10:24:42 2017 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Wed, 18 Jan 2017 11:24:42 +0100 Subject: RFR: 8172964: [aix] AIX VM should not handle SIGDANGER Message-ID: Dear all, please review this bugfix for AIX. Issue https://bugs.openjdk.java.net/browse/JDK-8172964 Webrev: http://cr.openjdk.java.net/~stuefe/webrevs/8172964-AIX-SIGDANGER/webrev/ In short, this removes the handling for SIGDANGER from the hotspot. Handling SIGDANGER has almost no benefit for us but interferes with AIX OOM killing mechanism, making effects of ow-paging-space situations on AIX more severe than they would need to be. For more details, please see the bug report. Thanks & Kind Regards, Thomas From coleen.phillimore at oracle.com Wed Jan 18 13:21:13 2017 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Wed, 18 Jan 2017 08:21:13 -0500 Subject: RFR (S) 8144518: ClassVerboseTest crashes on Windows In-Reply-To: <26c3e633-567e-1e4d-9d40-9bdfb4e06fcb@oracle.com> References: <93DCB66B-7F04-48FC-B44A-083293B892DE@oracle.com> <26c3e633-567e-1e4d-9d40-9bdfb4e06fcb@oracle.com> Message-ID: <5e89afa9-c461-71c8-0e23-39835cae0a7e@oracle.com> On 1/17/17 11:16 PM, David Holmes wrote: > On 18/01/2017 2:03 PM, Kim Barrett wrote: >>> On Jan 17, 2017, at 9:57 PM, David Holmes >>> wrote: >>> >>> Hi Coleen, >>> >>> On 18/01/2017 12:13 PM, Coleen Phillimore wrote: >>>> >>>> >>>> On 1/17/17 7:02 PM, David Holmes wrote: >>>>> Hi Coleen, >>>>> >>>>> The bug report does not explain the problem so it is unclear whether >>>>> this workaround is minimal. Also some commentary somewhere would be >>>>> useful else the bug might return inadvertently - more generally I'd >>>>> like to understand what other code might be impacted by this. >>>> >>>> Christian and I spent a solid week looking for the windows Visual >>>> Studio >>>> bug that caused this but weren't able to find it. He verified that >>>> it's >>>> fixed in VS2015. I think that's in the bug report. The code >>>> generated >>>> is in the bug report with annotations of what lines the code it was >>>> executing and which instructions caused the truncation and sign >>>> extension leading to a negative offset from the start of _bcp. >>> >>> I'm not seeing that listing in the bug report. What code was >>> generated versus what code should have been generated is precisely >>> what I was looking for. And some idea of what problematic source >>> code looks like. >> >> Some (most?) of the analysis and reproducer that Coleen is referring >> to are over in the duplicate >> https://bugs.openjdk.java.net/browse/JDK-8171968 > > Ah! Thanks Kim. > > Coleen: all much clearer now. Reviewed. Thanks David. I thought I'd pointed to the other bug in my mail. I put the analysis there because it matched the symptoms in the other bug and I'd already started posting things in that one. Thanks for the review. Coleen > > Thanks, > David > From harold.seigel at oracle.com Wed Jan 18 15:05:54 2017 From: harold.seigel at oracle.com (harold seigel) Date: Wed, 18 Jan 2017 10:05:54 -0500 Subject: RFR 8171971: Fix timing bug in JVM management of package export lists Message-ID: Hi, Please review this fix for the package export timing holes discussed in JDK-8171971. The fix reduces the number of PackageEntry fields that are used to maintain a package's export state and uses the Module_lock to protect all access to these fields. Also, in cases where a package transitions from having qualified exports to being unqualifiedly exported, it fixes the cleanup of its qualified export list by removing the _exported_pending_delete field and using just is_unqual_exported() to determine when the qualified exports list can be purged (at a safepoint). Open Webrev: http://cr.openjdk.java.net/~hseigel/bug_8171971/webrev/ JBS Bug: https://bugs.openjdk.java.net/browse/JDK-8171971 The fix was tested with the hotspot, java/lang, java/util, java/io, JFR, and other JTReg tests, the JCK lang and VM tests, RBT tier2 - tier5 tests on LinuxX64, and the colocated and non-colocated NSK tests. Thanks, Harold From Alan.Bateman at oracle.com Wed Jan 18 15:16:46 2017 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 18 Jan 2017 15:16:46 +0000 Subject: RFR 8171971: Fix timing bug in JVM management of package export lists In-Reply-To: References: Message-ID: <15eabe90-6b41-3a12-e198-4b6ba49890fb@oracle.com> On 18/01/2017 15:05, harold seigel wrote: > Hi, > > Please review this fix for the package export timing holes discussed > in JDK-8171971. The fix reduces the number of PackageEntry fields > that are used to maintain a package's export state and uses the > Module_lock to protect all access to these fields. > > Also, in cases where a package transitions from having qualified > exports to being unqualifiedly exported, it fixes the cleanup of its > qualified export list by removing the _exported_pending_delete field > and using just is_unqual_exported() to determine when the qualified > exports list can be purged (at a safepoint). > > Open Webrev: http://cr.openjdk.java.net/~hseigel/bug_8171971/webrev/ Does this mean that everyone doing an access check needs Module_lock? BTW: There is no API support for changing a module to export a package unconditionally. Only qualified exports can be added at runtime. Just mentioning in case this helps to consider options that would avoid contention on the mutex during access checks. From harold.seigel at oracle.com Wed Jan 18 15:46:17 2017 From: harold.seigel at oracle.com (harold seigel) Date: Wed, 18 Jan 2017 10:46:17 -0500 Subject: RFR 8171971: Fix timing bug in JVM management of package export lists In-Reply-To: <15eabe90-6b41-3a12-e198-4b6ba49890fb@oracle.com> References: <15eabe90-6b41-3a12-e198-4b6ba49890fb@oracle.com> Message-ID: <686c1fcc-72b0-2d44-bb53-72dbff7413c6@oracle.com> Hi Alan, The VM was already lockng the Module_lock during an access check when doing a qualified exports check. This change expands the scope of the of that lock to also cover checking if the packing is unqualifiedly exported. Can JVMTI be used to change a package's export state from qualified to unqualified? Thanks, Harold On 1/18/2017 10:16 AM, Alan Bateman wrote: > > > On 18/01/2017 15:05, harold seigel wrote: >> Hi, >> >> Please review this fix for the package export timing holes discussed >> in JDK-8171971. The fix reduces the number of PackageEntry fields >> that are used to maintain a package's export state and uses the >> Module_lock to protect all access to these fields. >> >> Also, in cases where a package transitions from having qualified >> exports to being unqualifiedly exported, it fixes the cleanup of its >> qualified export list by removing the _exported_pending_delete field >> and using just is_unqual_exported() to determine when the qualified >> exports list can be purged (at a safepoint). >> >> Open Webrev: http://cr.openjdk.java.net/~hseigel/bug_8171971/webrev/ > Does this mean that everyone doing an access check needs Module_lock? > > BTW: There is no API support for changing a module to export a package > unconditionally. Only qualified exports can be added at runtime. Just > mentioning in case this helps to consider options that would avoid > contention on the mutex during access checks. From Alan.Bateman at oracle.com Wed Jan 18 15:48:27 2017 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 18 Jan 2017 15:48:27 +0000 Subject: RFR 8171971: Fix timing bug in JVM management of package export lists In-Reply-To: <686c1fcc-72b0-2d44-bb53-72dbff7413c6@oracle.com> References: <15eabe90-6b41-3a12-e198-4b6ba49890fb@oracle.com> <686c1fcc-72b0-2d44-bb53-72dbff7413c6@oracle.com> Message-ID: On 18/01/2017 15:46, harold seigel wrote: > Hi Alan, > > The VM was already lockng the Module_lock during an access check when > doing a qualified exports check. This change expands the scope of the > of that lock to also cover checking if the packing is unqualifiedly > exported. I hope it can be looked at again to make it lock-free some day. > > Can JVMTI be used to change a package's export state from qualified to > unqualified? No, qualified exports and opens only. -Alan From volker.simonis at gmail.com Wed Jan 18 16:58:52 2017 From: volker.simonis at gmail.com (Volker Simonis) Date: Wed, 18 Jan 2017 17:58:52 +0100 Subject: RFR: 8172964: [aix] AIX VM should not handle SIGDANGER In-Reply-To: References: Message-ID: Hi Thomas, aside from the copyright notices which have to be updated to 2017 now (no need for a new webrev however) your changes look good. Thanks for fixing, Volker On Wed, Jan 18, 2017 at 11:24 AM, Thomas St?fe wrote: > Dear all, > > please review this bugfix for AIX. > > Issue > https://bugs.openjdk.java.net/browse/JDK-8172964 > Webrev: > http://cr.openjdk.java.net/~stuefe/webrevs/8172964-AIX-SIGDANGER/webrev/ > > In short, this removes the handling for SIGDANGER from the hotspot. > Handling SIGDANGER has almost no benefit for us but interferes with AIX OOM > killing mechanism, making effects of ow-paging-space situations on AIX more > severe than they would need to be. > > For more details, please see the bug report. > > Thanks & Kind Regards, > > Thomas From thomas.stuefe at gmail.com Wed Jan 18 17:06:35 2017 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Wed, 18 Jan 2017 17:06:35 +0000 Subject: RFR: 8172964: [aix] AIX VM should not handle SIGDANGER In-Reply-To: References: Message-ID: Thank you, Volker! On Wed, 18 Jan 2017 at 17:58, Volker Simonis wrote: > Hi Thomas, > > > > aside from the copyright notices which have to be updated to 2017 now > > (no need for a new webrev however) your changes look good. > > > > Thanks for fixing, > > Volker > > > > > > On Wed, Jan 18, 2017 at 11:24 AM, Thomas St?fe > wrote: > > > Dear all, > > > > > > please review this bugfix for AIX. > > > > > > Issue > > > https://bugs.openjdk.java.net/browse/JDK-8172964 > > > Webrev: > > > http://cr.openjdk.java.net/~stuefe/webrevs/8172964-AIX-SIGDANGER/webrev/ > > > > > > In short, this removes the handling for SIGDANGER from the hotspot. > > > Handling SIGDANGER has almost no benefit for us but interferes with AIX > OOM > > > killing mechanism, making effects of ow-paging-space situations on AIX > more > > > severe than they would need to be. > > > > > > For more details, please see the bug report. > > > > > > Thanks & Kind Regards, > > > > > > Thomas > > From george.triantafillou at oracle.com Wed Jan 18 18:45:57 2017 From: george.triantafillou at oracle.com (George Triantafillou) Date: Wed, 18 Jan 2017 13:45:57 -0500 Subject: RFR JDK-8152206: Simplify jvmstat modules Message-ID: <15980f89-7495-767d-d664-322d181e5c21@oracle.com> Please review this fix for JDK-8152206. The module jdk.jvmstat.rmi was renamed to jdk.jstatd. All tests and makefiles were updated with the new module name. JBS Bug: https://bugs.openjdk.java.net/browse/JDK-8152206 Open Webrevs: http://cr.openjdk.java.net/~gtriantafill/8152206/webrev/top/webrev/ http://cr.openjdk.java.net/~gtriantafill/8152206/webrev/jdk/webrev/ http://cr.openjdk.java.net/~gtriantafill/8152206/webrev/hotspot/webrev/ The fix was tested with the hotspot_all test group on Linux x64. Thanks. -George From mandy.chung at oracle.com Wed Jan 18 19:04:46 2017 From: mandy.chung at oracle.com (Mandy Chung) Date: Wed, 18 Jan 2017 11:04:46 -0800 Subject: RFR JDK-8152206: Simplify jvmstat modules In-Reply-To: <15980f89-7495-767d-d664-322d181e5c21@oracle.com> References: <15980f89-7495-767d-d664-322d181e5c21@oracle.com> Message-ID: <3FF7E80F-2E14-4582-9764-BFF4BB62B1A8@oracle.com> The change looks fine. Do you know where the dependency on sun.jvmstat.monitor.* gets pulled in? I did a grep ?sun.jvmstat.monitor? on /test and hotspot/test and can?t explain why test depends on it. Mandy > On Jan 18, 2017, at 10:45 AM, George Triantafillou wrote: > > Please review this fix for JDK-8152206. The module jdk.jvmstat.rmi was renamed to jdk.jstatd. All tests and makefiles were updated with the new module name. > > JBS Bug: https://bugs.openjdk.java.net/browse/JDK-8152206 > Open Webrevs: > > http://cr.openjdk.java.net/~gtriantafill/8152206/webrev/top/webrev/ > http://cr.openjdk.java.net/~gtriantafill/8152206/webrev/jdk/webrev/ > http://cr.openjdk.java.net/~gtriantafill/8152206/webrev/hotspot/webrev/ > > The fix was tested with the hotspot_all test group on Linux x64. Thanks. > > -George > From Alan.Bateman at oracle.com Wed Jan 18 19:30:30 2017 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 18 Jan 2017 19:30:30 +0000 Subject: RFR JDK-8152206: Simplify jvmstat modules In-Reply-To: <15980f89-7495-767d-d664-322d181e5c21@oracle.com> References: <15980f89-7495-767d-d664-322d181e5c21@oracle.com> Message-ID: On 18/01/2017 18:45, George Triantafillou wrote: > Please review this fix for JDK-8152206. The module jdk.jvmstat.rmi > was renamed to jdk.jstatd. All tests and makefiles were updated with > the new module name. > > JBS Bug: https://bugs.openjdk.java.net/browse/JDK-8152206 > Open Webrevs: > > http://cr.openjdk.java.net/~gtriantafill/8152206/webrev/top/webrev/ > > http://cr.openjdk.java.net/~gtriantafill/8152206/webrev/jdk/webrev/ > > http://cr.openjdk.java.net/~gtriantafill/8152206/webrev/hotspot/webrev/ > > > > The fix was tested with the hotspot_all test group on Linux x64. Thanks. The rename looks okay to me. I assume you will also run the jdk_svc tests in the jdk repo. -Alan From harold.seigel at oracle.com Wed Jan 18 20:24:55 2017 From: harold.seigel at oracle.com (harold seigel) Date: Wed, 18 Jan 2017 15:24:55 -0500 Subject: RFR 8171971: Fix timing bug in JVM management of package export lists In-Reply-To: References: <15eabe90-6b41-3a12-e198-4b6ba49890fb@oracle.com> <686c1fcc-72b0-2d44-bb53-72dbff7413c6@oracle.com> Message-ID: <62cfa682-0b69-1d84-90f4-b9a523f562f2@oracle.com> Hi Alan, >> I hope it can be looked at again to make it lock-free some day. We plan to do this as part of JDK-10. Thanks, Harold On 1/18/2017 10:48 AM, Alan Bateman wrote: > > > On 18/01/2017 15:46, harold seigel wrote: >> Hi Alan, >> >> The VM was already lockng the Module_lock during an access check when >> doing a qualified exports check. This change expands the scope of >> the of that lock to also cover checking if the packing is >> unqualifiedly exported. > I hope it can be looked at again to make it lock-free some day. > >> >> Can JVMTI be used to change a package's export state from qualified >> to unqualified? > No, qualified exports and opens only. > > -Alan From george.triantafillou at oracle.com Wed Jan 18 21:24:39 2017 From: george.triantafillou at oracle.com (George Triantafillou) Date: Wed, 18 Jan 2017 16:24:39 -0500 Subject: RFR JDK-8152206: Simplify jvmstat modules In-Reply-To: References: <15980f89-7495-767d-d664-322d181e5c21@oracle.com> Message-ID: <13dfe6e7-5ca8-a26c-f559-5fd2fb631549@oracle.com> Hi Alan, I successfully ran jdk/test/:jdk_svc with RBT on Linux x64. Thanks for the review. -George On 1/18/2017 2:30 PM, Alan Bateman wrote: > > > On 18/01/2017 18:45, George Triantafillou wrote: >> Please review this fix for JDK-8152206. The module jdk.jvmstat.rmi >> was renamed to jdk.jstatd. All tests and makefiles were updated with >> the new module name. >> >> JBS Bug: https://bugs.openjdk.java.net/browse/JDK-8152206 >> Open Webrevs: >> >> http://cr.openjdk.java.net/~gtriantafill/8152206/webrev/top/webrev/ >> >> http://cr.openjdk.java.net/~gtriantafill/8152206/webrev/jdk/webrev/ >> >> http://cr.openjdk.java.net/~gtriantafill/8152206/webrev/hotspot/webrev/ >> >> >> >> The fix was tested with the hotspot_all test group on Linux x64. Thanks. > The rename looks okay to me. I assume you will also run the jdk_svc > tests in the jdk repo. > > -Alan From george.triantafillou at oracle.com Wed Jan 18 21:27:26 2017 From: george.triantafillou at oracle.com (George Triantafillou) Date: Wed, 18 Jan 2017 16:27:26 -0500 Subject: RFR JDK-8152206: Simplify jvmstat modules In-Reply-To: <3FF7E80F-2E14-4582-9764-BFF4BB62B1A8@oracle.com> References: <15980f89-7495-767d-d664-322d181e5c21@oracle.com> <3FF7E80F-2E14-4582-9764-BFF4BB62B1A8@oracle.com> Message-ID: <693c02b4-27d4-a1ee-eff0-2ea94f388903@oracle.com> Hi Mandy, Thanks for the review. On 1/18/2017 2:04 PM, Mandy Chung wrote: > The change looks fine. > > Do you know where the dependency on sun.jvmstat.monitor.* gets pulled in? I did a grep ?sun.jvmstat.monitor? on /test and hotspot/test and can?t explain why test depends on it. Harold said that he deleted "@modules jdk.jvmstat/sun.jvmstat.monitor" from a couple of the hotspot/runtime tests, re-ran them, and they passed. We can open a new bug to investigate which tests actually need "@modules sun.jvmstat.monitor ". -George > > Mandy > >> On Jan 18, 2017, at 10:45 AM, George Triantafillou wrote: >> >> Please review this fix for JDK-8152206. The module jdk.jvmstat.rmi was renamed to jdk.jstatd. All tests and makefiles were updated with the new module name. >> >> JBS Bug: https://bugs.openjdk.java.net/browse/JDK-8152206 >> Open Webrevs: >> >> http://cr.openjdk.java.net/~gtriantafill/8152206/webrev/top/webrev/ >> http://cr.openjdk.java.net/~gtriantafill/8152206/webrev/jdk/webrev/ >> http://cr.openjdk.java.net/~gtriantafill/8152206/webrev/hotspot/webrev/ >> >> The fix was tested with the hotspot_all test group on Linux x64. Thanks. >> >> -George >> From mandy.chung at oracle.com Wed Jan 18 21:52:04 2017 From: mandy.chung at oracle.com (Mandy Chung) Date: Wed, 18 Jan 2017 13:52:04 -0800 Subject: RFR JDK-8152206: Simplify jvmstat modules In-Reply-To: <693c02b4-27d4-a1ee-eff0-2ea94f388903@oracle.com> References: <15980f89-7495-767d-d664-322d181e5c21@oracle.com> <3FF7E80F-2E14-4582-9764-BFF4BB62B1A8@oracle.com> <693c02b4-27d4-a1ee-eff0-2ea94f388903@oracle.com> Message-ID: <0FEBCBA9-DBB7-4EF8-9722-87DCED46D1D2@oracle.com> > On Jan 18, 2017, at 1:27 PM, George Triantafillou wrote: > > Hi Mandy, > > Thanks for the review. > > On 1/18/2017 2:04 PM, Mandy Chung wrote: >> The change looks fine. >> >> Do you know where the dependency on sun.jvmstat.monitor.* gets pulled in? I did a grep ?sun.jvmstat.monitor? on /test and hotspot/test and can?t explain why test depends on it. > > Harold said that he deleted "@modules jdk.jvmstat/sun.jvmstat.monitor" from a couple of the hotspot/runtime tests, re-ran them, and they passed. > I guess it might come from the dependency from some test library that was probably updated and no longer have such dependency. > We can open a new bug to investigate which tests actually need "@modules sun.jvmstat.monitor ". Yes please file a bug. It?d be good to clean up @modules. You may want to check with Shura on his tool that detects if any test @modules needs update which is useful when looking into it. Mandy From david.holmes at oracle.com Wed Jan 18 22:44:56 2017 From: david.holmes at oracle.com (David Holmes) Date: Thu, 19 Jan 2017 08:44:56 +1000 Subject: RFR (S) 8144518: ClassVerboseTest crashes on Windows In-Reply-To: <5e89afa9-c461-71c8-0e23-39835cae0a7e@oracle.com> References: <93DCB66B-7F04-48FC-B44A-083293B892DE@oracle.com> <26c3e633-567e-1e4d-9d40-9bdfb4e06fcb@oracle.com> <5e89afa9-c461-71c8-0e23-39835cae0a7e@oracle.com> Message-ID: On 18/01/2017 11:21 PM, Coleen Phillimore wrote: > > > On 1/17/17 11:16 PM, David Holmes wrote: >> On 18/01/2017 2:03 PM, Kim Barrett wrote: >>>> On Jan 17, 2017, at 9:57 PM, David Holmes >>>> wrote: >>>> >>>> Hi Coleen, >>>> >>>> On 18/01/2017 12:13 PM, Coleen Phillimore wrote: >>>>> >>>>> >>>>> On 1/17/17 7:02 PM, David Holmes wrote: >>>>>> Hi Coleen, >>>>>> >>>>>> The bug report does not explain the problem so it is unclear whether >>>>>> this workaround is minimal. Also some commentary somewhere would be >>>>>> useful else the bug might return inadvertently - more generally I'd >>>>>> like to understand what other code might be impacted by this. >>>>> >>>>> Christian and I spent a solid week looking for the windows Visual >>>>> Studio >>>>> bug that caused this but weren't able to find it. He verified that >>>>> it's >>>>> fixed in VS2015. I think that's in the bug report. The code >>>>> generated >>>>> is in the bug report with annotations of what lines the code it was >>>>> executing and which instructions caused the truncation and sign >>>>> extension leading to a negative offset from the start of _bcp. >>>> >>>> I'm not seeing that listing in the bug report. What code was >>>> generated versus what code should have been generated is precisely >>>> what I was looking for. And some idea of what problematic source >>>> code looks like. >>> >>> Some (most?) of the analysis and reproducer that Coleen is referring >>> to are over in the duplicate >>> https://bugs.openjdk.java.net/browse/JDK-8171968 >> >> Ah! Thanks Kim. >> >> Coleen: all much clearer now. Reviewed. > > Thanks David. I thought I'd pointed to the other bug in my mail. I put You did - my bad - it didn't register as being a different bug report. David > the analysis there because it matched the symptoms in the other bug and > I'd already started posting things in that one. > > Thanks for the review. > Coleen >> >> Thanks, >> David >> > From david.holmes at oracle.com Thu Jan 19 01:04:12 2017 From: david.holmes at oracle.com (David Holmes) Date: Thu, 19 Jan 2017 11:04:12 +1000 Subject: RFR 8171971: Fix timing bug in JVM management of package export lists In-Reply-To: References: Message-ID: Hi Harold, Not a review but noticed the copyright updates are not correct - should now be "2016, 2017," for most of the files not just "2017," Thanks, David On 19/01/2017 1:05 AM, harold seigel wrote: > Hi, > > Please review this fix for the package export timing holes discussed in > JDK-8171971. The fix reduces the number of PackageEntry fields that are > used to maintain a package's export state and uses the Module_lock to > protect all access to these fields. > > Also, in cases where a package transitions from having qualified exports > to being unqualifiedly exported, it fixes the cleanup of its qualified > export list by removing the _exported_pending_delete field and using > just is_unqual_exported() to determine when the qualified exports list > can be purged (at a safepoint). > > Open Webrev: http://cr.openjdk.java.net/~hseigel/bug_8171971/webrev/ > > JBS Bug: https://bugs.openjdk.java.net/browse/JDK-8171971 > > The fix was tested with the hotspot, java/lang, java/util, java/io, JFR, > and other JTReg tests, the JCK lang and VM tests, RBT tier2 - tier5 > tests on LinuxX64, and the colocated and non-colocated NSK tests. > > Thanks, Harold > From coleen.phillimore at oracle.com Thu Jan 19 03:43:25 2017 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Wed, 18 Jan 2017 22:43:25 -0500 Subject: RFR (S) 8144518: ClassVerboseTest crashes on Windows In-Reply-To: References: Message-ID: Sorry I didn't see this. It went to the wrong folder. On 1/17/17 9:57 PM, David Holmes wrote: > Hi Coleen, > > On 18/01/2017 12:13 PM, Coleen Phillimore wrote: >> >> >> On 1/17/17 7:02 PM, David Holmes wrote: >>> Hi Coleen, >>> >>> The bug report does not explain the problem so it is unclear whether >>> this workaround is minimal. Also some commentary somewhere would be >>> useful else the bug might return inadvertently - more generally I'd >>> like to understand what other code might be impacted by this. >> >> Christian and I spent a solid week looking for the windows Visual Studio >> bug that caused this but weren't able to find it. He verified that it's >> fixed in VS2015. I think that's in the bug report. The code generated >> is in the bug report with annotations of what lines the code it was >> executing and which instructions caused the truncation and sign >> extension leading to a negative offset from the start of _bcp. > > I'm not seeing that listing in the bug report. What code was generated > versus what code should have been generated is precisely what I was > looking for. And some idea of what problematic source code looks like. > Kim answered this (the other bug). >> There's a small reproducer in the bug report for 8144518. >> >> I did a grep of all the "address.*-" and looked through the lines of >> code but I didn't generate windows assembly code to examine for all the >> pointer subtractions. I don't plan to do this. From the reproducer, >> there needed to be the swap_u4, even though the load that crashed was >> before the swap_u4 code. The scenario that caused this bug seems very >> specific and if it exists in any other places in the jvm, we can keep an >> eye out for it. This crash, while intermittent, was fairly consistent. > > Very intermittent - so I guess we rarely hit the incorrectly compiled > code path. > What happened was the addr_at(offset) went from some address 0x0000002e7fffffde to 0x0000002e8000000c where the sign bit if the lower word was set. This was pretty rare and seemed to happen more in the bytecodes copied into CHeap allocated memory for the compiler interface. >> We think it's best to get this workaround into jdk 9 before ZBB since >> this bug has been seen several times, and we finally narrowed down the >> problem and don't have to close it as not reproduceable again. >> >> There is a line above the dest_offset_at code which I was going to >> remove, since it's describing code I changed, which doesn't make for a >> good comment. Any further commentary or explanation of this bug will be >> vague, since we don't have the VS compiler to debug to find the real >> problem, and won't make sense in the source code. >> >> Did you look at the code? It's a simplification of the expression that >> was in the original, that would have been better from the start. > > Yes I looked at the code. AFAICS you now pass in an unaligned value > and align it internally, while previously the caller had to do the > alignment first - right? That inversion somehow bypasses the code that > gets incorrectly compiled. > Yes. Thanks, Coleen > Thanks, > David > ----- > >> Thanks, >> Coleen >> >>> >>> Thanks, >>> David >>> >>> On 18/01/2017 8:49 AM, Coleen Phillimore wrote: >>>> I should have also sent this to hotspot-dev, since >>>> Bytecode_tableswitch >>>> is used by the compiler ci code. >>>> thanks, >>>> Coleen >>>> >>>> >>>> On 1/17/17 1:49 PM, Coleen Phillimore wrote: >>>>> Summary: simplify Bytecode_tableswitch code so windows doesn't >>>>> generate bad code for it. >>>>> >>>>> open webrev at http://cr.openjdk.java.net/~coleenp/8144518.01/webrev >>>>> bug link https://bugs.openjdk.java.net/browse/JDK-8144518 >>>>> >>>>> Verified generated code does not have sign extended value that is >>>>> subtracted, giving the wrong offset. Ran all rbt nightly tests. Ran >>>>> some -Xcomp tests. >>>>> >>>>> See more info in bug https://bugs.openjdk.java.net/browse/JDK-8171968 >>>>> >>>>> Thanks, >>>>> Coleen >>>>> >>>>> >>>> >> From christoph.langer at sap.com Thu Jan 19 06:57:15 2017 From: christoph.langer at sap.com (Langer, Christoph) Date: Thu, 19 Jan 2017 06:57:15 +0000 Subject: RFR: 8172964: [aix] AIX VM should not handle SIGDANGER In-Reply-To: References: Message-ID: <9adebe1fd60f4fa5b1e51328eed27be1@derote13de46.global.corp.sap> Hi Thomas, +1 This really seems the right thing to do here. Best regards Christoph > -----Original Message----- > From: hotspot-runtime-dev [mailto:hotspot-runtime-dev- > bounces at openjdk.java.net] On Behalf Of Volker Simonis > Sent: Mittwoch, 18. Januar 2017 17:59 > To: Thomas St?fe > Cc: ppc-aix-port-dev at openjdk.java.net; hotspot-runtime-dev at openjdk.java.net > Subject: Re: RFR: 8172964: [aix] AIX VM should not handle SIGDANGER > > Hi Thomas, > > aside from the copyright notices which have to be updated to 2017 now > (no need for a new webrev however) your changes look good. > > Thanks for fixing, > Volker > > > On Wed, Jan 18, 2017 at 11:24 AM, Thomas St?fe > wrote: > > Dear all, > > > > please review this bugfix for AIX. > > > > Issue > > https://bugs.openjdk.java.net/browse/JDK-8172964 > > Webrev: > > http://cr.openjdk.java.net/~stuefe/webrevs/8172964-AIX- > SIGDANGER/webrev/ > > > > In short, this removes the handling for SIGDANGER from the hotspot. > > Handling SIGDANGER has almost no benefit for us but interferes with AIX > OOM > > killing mechanism, making effects of ow-paging-space situations on AIX more > > severe than they would need to be. > > > > For more details, please see the bug report. > > > > Thanks & Kind Regards, > > > > Thomas From thomas.stuefe at gmail.com Thu Jan 19 07:39:32 2017 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Thu, 19 Jan 2017 08:39:32 +0100 Subject: RFR: 8172964: [aix] AIX VM should not handle SIGDANGER In-Reply-To: <9adebe1fd60f4fa5b1e51328eed27be1@derote13de46.global.corp.sap> References: <9adebe1fd60f4fa5b1e51328eed27be1@derote13de46.global.corp.sap> Message-ID: Thanks Christoph! On Thu, Jan 19, 2017 at 7:57 AM, Langer, Christoph wrote: > Hi Thomas, > > +1 > > This really seems the right thing to do here. > > Best regards > Christoph > > > -----Original Message----- > > From: hotspot-runtime-dev [mailto:hotspot-runtime-dev- > > bounces at openjdk.java.net] On Behalf Of Volker Simonis > > Sent: Mittwoch, 18. Januar 2017 17:59 > > To: Thomas St?fe > > Cc: ppc-aix-port-dev at openjdk.java.net; hotspot-runtime-dev at openjdk. > java.net > > Subject: Re: RFR: 8172964: [aix] AIX VM should not handle SIGDANGER > > > > Hi Thomas, > > > > aside from the copyright notices which have to be updated to 2017 now > > (no need for a new webrev however) your changes look good. > > > > Thanks for fixing, > > Volker > > > > > > On Wed, Jan 18, 2017 at 11:24 AM, Thomas St?fe > > wrote: > > > Dear all, > > > > > > please review this bugfix for AIX. > > > > > > Issue > > > https://bugs.openjdk.java.net/browse/JDK-8172964 > > > Webrev: > > > http://cr.openjdk.java.net/~stuefe/webrevs/8172964-AIX- > > SIGDANGER/webrev/ > > > > > > In short, this removes the handling for SIGDANGER from the hotspot. > > > Handling SIGDANGER has almost no benefit for us but interferes with AIX > > OOM > > > killing mechanism, making effects of ow-paging-space situations on AIX > more > > > severe than they would need to be. > > > > > > For more details, please see the bug report. > > > > > > Thanks & Kind Regards, > > > > > > Thomas > From thomas.stuefe at gmail.com Thu Jan 19 08:27:47 2017 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Thu, 19 Jan 2017 09:27:47 +0100 Subject: RFR: 8172964: [aix] AIX VM should not handle SIGDANGER In-Reply-To: References: Message-ID: Hi, I still need a sponsor. Could someone from Oracle please review and sponsor the change? Thank you! Kind Regards, Thomas On Wed, Jan 18, 2017 at 11:24 AM, Thomas St?fe wrote: > Dear all, > > please review this bugfix for AIX. > > Issue > https://bugs.openjdk.java.net/browse/JDK-8172964 > Webrev: > http://cr.openjdk.java.net/~stuefe/webrevs/8172964-AIX-SIGDANGER/webrev/ > > In short, this removes the handling for SIGDANGER from the hotspot. > Handling SIGDANGER has almost no benefit for us but interferes with AIX OOM > killing mechanism, making effects of ow-paging-space situations on AIX more > severe than they would need to be. > > For more details, please see the bug report. > > Thanks & Kind Regards, > > Thomas > From thomas.stuefe at gmail.com Thu Jan 19 09:35:21 2017 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Thu, 19 Jan 2017 10:35:21 +0100 Subject: RFR: 8172964: [aix] AIX VM should not handle SIGDANGER In-Reply-To: References: Message-ID: ... Nevermind. Volker just reminded me that we can push AIX only changes ourself. Change was pushed. Kind Regards, Thomas On Thu, Jan 19, 2017 at 9:27 AM, Thomas St?fe wrote: > Hi, > > I still need a sponsor. Could someone from Oracle please review and > sponsor the change? Thank you! > > Kind Regards, Thomas > > On Wed, Jan 18, 2017 at 11:24 AM, Thomas St?fe > wrote: > >> Dear all, >> >> please review this bugfix for AIX. >> >> Issue >> https://bugs.openjdk.java.net/browse/JDK-8172964 >> Webrev: >> http://cr.openjdk.java.net/~stuefe/webrevs/8172964-AIX-SIGDANGER/webrev/ >> >> In short, this removes the handling for SIGDANGER from the hotspot. >> Handling SIGDANGER has almost no benefit for us but interferes with AIX OOM >> killing mechanism, making effects of ow-paging-space situations on AIX more >> severe than they would need to be. >> >> For more details, please see the bug report. >> >> Thanks & Kind Regards, >> >> Thomas >> > > From serguei.spitsyn at oracle.com Thu Jan 19 10:05:08 2017 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Thu, 19 Jan 2017 02:05:08 -0800 Subject: RFR 8171971: Fix timing bug in JVM management of package export lists In-Reply-To: References: Message-ID: <216c40d7-17b3-7273-e0dc-be95e127d456@oracle.com> Hi Harold, It looks pretty good to me. One question though. || src/share/vm/classfile/modules.cpp I wonder if a synchronization is needed for the functions like Modules::add_module_exports_to_all_unnamed. But this is unrelated to your particular fix. || Thanks, Serguei On 1/18/17 07:05, harold seigel wrote: > Hi, > > Please review this fix for the package export timing holes discussed > in JDK-8171971. The fix reduces the number of PackageEntry fields > that are used to maintain a package's export state and uses the > Module_lock to protect all access to these fields. > > Also, in cases where a package transitions from having qualified > exports to being unqualifiedly exported, it fixes the cleanup of its > qualified export list by removing the _exported_pending_delete field > and using just is_unqual_exported() to determine when the qualified > exports list can be purged (at a safepoint). > > Open Webrev: http://cr.openjdk.java.net/~hseigel/bug_8171971/webrev/ > > JBS Bug: https://bugs.openjdk.java.net/browse/JDK-8171971 > > The fix was tested with the hotspot, java/lang, java/util, java/io, > JFR, and other JTReg tests, the JCK lang and VM tests, RBT tier2 - > tier5 tests on LinuxX64, and the colocated and non-colocated NSK tests. > > Thanks, Harold > From harold.seigel at oracle.com Thu Jan 19 12:45:31 2017 From: harold.seigel at oracle.com (harold seigel) Date: Thu, 19 Jan 2017 07:45:31 -0500 Subject: RFR 8171971: Fix timing bug in JVM management of package export lists In-Reply-To: References: Message-ID: <8cace753-b271-83f4-29e1-69752a889fa8@oracle.com> Hi David, So if a file, such as modules.cpp, was added to the JVM for JDK-9, but written in 2016, then its copyright should be "2016, 2017," even though the file hasn't yet been part of an actual release? Thanks, Harold On 1/18/2017 8:04 PM, David Holmes wrote: > Hi Harold, > > Not a review but noticed the copyright updates are not correct - > should now be "2016, 2017," for most of the files not just "2017," > > Thanks, > David > > On 19/01/2017 1:05 AM, harold seigel wrote: >> Hi, >> >> Please review this fix for the package export timing holes discussed in >> JDK-8171971. The fix reduces the number of PackageEntry fields that are >> used to maintain a package's export state and uses the Module_lock to >> protect all access to these fields. >> >> Also, in cases where a package transitions from having qualified exports >> to being unqualifiedly exported, it fixes the cleanup of its qualified >> export list by removing the _exported_pending_delete field and using >> just is_unqual_exported() to determine when the qualified exports list >> can be purged (at a safepoint). >> >> Open Webrev: http://cr.openjdk.java.net/~hseigel/bug_8171971/webrev/ >> >> JBS Bug: https://bugs.openjdk.java.net/browse/JDK-8171971 >> >> The fix was tested with the hotspot, java/lang, java/util, java/io, JFR, >> and other JTReg tests, the JCK lang and VM tests, RBT tier2 - tier5 >> tests on LinuxX64, and the colocated and non-colocated NSK tests. >> >> Thanks, Harold >> From karen.kinnear at oracle.com Thu Jan 19 14:28:17 2017 From: karen.kinnear at oracle.com (Karen Kinnear) Date: Thu, 19 Jan 2017 09:28:17 -0500 Subject: RFR 8171971: Fix timing bug in JVM management of package export lists In-Reply-To: <8cace753-b271-83f4-29e1-69752a889fa8@oracle.com> References: <8cace753-b271-83f4-29e1-69752a889fa8@oracle.com> Message-ID: <0164797A-1723-4133-85C2-4EB8382B5696@oracle.com> Harold, that matches my understanding. Start with date when the file was created, and span any year that the file was modified. thanks, Karen > On Jan 19, 2017, at 7:45 AM, harold seigel wrote: > > Hi David, > > So if a file, such as modules.cpp, was added to the JVM for JDK-9, but written in 2016, then its copyright should be "2016, 2017," even though the file hasn't yet been part of an actual release? > > Thanks, Harold > > > On 1/18/2017 8:04 PM, David Holmes wrote: >> Hi Harold, >> >> Not a review but noticed the copyright updates are not correct - should now be "2016, 2017," for most of the files not just "2017," >> >> Thanks, >> David >> >> On 19/01/2017 1:05 AM, harold seigel wrote: >>> Hi, >>> >>> Please review this fix for the package export timing holes discussed in >>> JDK-8171971. The fix reduces the number of PackageEntry fields that are >>> used to maintain a package's export state and uses the Module_lock to >>> protect all access to these fields. >>> >>> Also, in cases where a package transitions from having qualified exports >>> to being unqualifiedly exported, it fixes the cleanup of its qualified >>> export list by removing the _exported_pending_delete field and using >>> just is_unqual_exported() to determine when the qualified exports list >>> can be purged (at a safepoint). >>> >>> Open Webrev: http://cr.openjdk.java.net/~hseigel/bug_8171971/webrev/ >>> >>> JBS Bug: https://bugs.openjdk.java.net/browse/JDK-8171971 >>> >>> The fix was tested with the hotspot, java/lang, java/util, java/io, JFR, >>> and other JTReg tests, the JCK lang and VM tests, RBT tier2 - tier5 >>> tests on LinuxX64, and the colocated and non-colocated NSK tests. >>> >>> Thanks, Harold >>> > From lois.foltan at oracle.com Thu Jan 19 15:14:29 2017 From: lois.foltan at oracle.com (Lois Foltan) Date: Thu, 19 Jan 2017 10:14:29 -0500 Subject: RFR 8171971: Fix timing bug in JVM management of package export lists In-Reply-To: References: Message-ID: <5880D7D5.2070100@oracle.com> On 1/18/2017 10:05 AM, harold seigel wrote: > Hi, > > Please review this fix for the package export timing holes discussed > in JDK-8171971. The fix reduces the number of PackageEntry fields > that are used to maintain a package's export state and uses the > Module_lock to protect all access to these fields. > > Also, in cases where a package transitions from having qualified > exports to being unqualifiedly exported, it fixes the cleanup of its > qualified export list by removing the _exported_pending_delete field > and using just is_unqual_exported() to determine when the qualified > exports list can be purged (at a safepoint). > > Open Webrev: http://cr.openjdk.java.net/~hseigel/bug_8171971/webrev/ > > JBS Bug: https://bugs.openjdk.java.net/browse/JDK-8171971 > > The fix was tested with the hotspot, java/lang, java/util, java/io, > JFR, and other JTReg tests, the JCK lang and VM tests, RBT tier2 - > tier5 tests on LinuxX64, and the colocated and non-colocated NSK tests. Hi Harold, Looks good! A couple of comments in src/share/vm/classfile/packageEntry.hpp: - line #133, the method has_qual_exports_list(). A comment should be added ahead of this method to indicate that even if the _qualified_exports list is empty the package is still considered qualifiedly exported and a similar comment should be added to PackageEntry::purge_qualified_exports(). During a GC safepoint, it could be the scenario that all modules on a given package's qualified export list die, thus leaving an allocated but empty _qualified_exports field. If the _qualified_exports GrowableArray was deleted in that scenario, then according to the new _exports_flag and a NULL value for _qualified_exports, the package would erroneously not be considered qualifiedly exported anymore. This can be reworked in the future to have the _exports_flag contain definitions for all possible states. Relying on the state of whether _qualified_exports field is NULL or not can be problematic, but I think your changes do improve upon ensuring a PackageEntry maintains a valid state. - line #86 - please add a blank line for readability - line #139 & #143 please out the return expression in parentheses. Thanks, Lois > > Thanks, Harold > From harold.seigel at oracle.com Thu Jan 19 15:19:55 2017 From: harold.seigel at oracle.com (harold seigel) Date: Thu, 19 Jan 2017 10:19:55 -0500 Subject: RFR JDK-8152206: Simplify jvmstat modules In-Reply-To: <15980f89-7495-767d-d664-322d181e5c21@oracle.com> References: <15980f89-7495-767d-d664-322d181e5c21@oracle.com> Message-ID: <5eb9dc32-479a-fdde-b9bb-de47e7fd78e6@oracle.com> Hi George, These changes look good. Thanks, Harold On 1/18/2017 1:45 PM, George Triantafillou wrote: > Please review this fix for JDK-8152206. The module jdk.jvmstat.rmi > was renamed to jdk.jstatd. All tests and makefiles were updated with > the new module name. > > JBS Bug: https://bugs.openjdk.java.net/browse/JDK-8152206 > Open Webrevs: > > http://cr.openjdk.java.net/~gtriantafill/8152206/webrev/top/webrev/ > > http://cr.openjdk.java.net/~gtriantafill/8152206/webrev/jdk/webrev/ > > http://cr.openjdk.java.net/~gtriantafill/8152206/webrev/hotspot/webrev/ > > > > The fix was tested with the hotspot_all test group on Linux x64. Thanks. > > -George > From george.triantafillou at oracle.com Thu Jan 19 15:49:32 2017 From: george.triantafillou at oracle.com (George Triantafillou) Date: Thu, 19 Jan 2017 10:49:32 -0500 Subject: RFR JDK-8152206: Simplify jvmstat modules In-Reply-To: <5eb9dc32-479a-fdde-b9bb-de47e7fd78e6@oracle.com> References: <15980f89-7495-767d-d664-322d181e5c21@oracle.com> <5eb9dc32-479a-fdde-b9bb-de47e7fd78e6@oracle.com> Message-ID: <242bf9b0-cda0-0e7c-fe6d-b059cdd3b1ea@oracle.com> Thanks Harold. -George On 1/19/2017 10:19 AM, harold seigel wrote: > Hi George, > > These changes look good. > > Thanks, Harold > > > On 1/18/2017 1:45 PM, George Triantafillou wrote: >> Please review this fix for JDK-8152206. The module jdk.jvmstat.rmi >> was renamed to jdk.jstatd. All tests and makefiles were updated with >> the new module name. >> >> JBS Bug: https://bugs.openjdk.java.net/browse/JDK-8152206 >> Open Webrevs: >> >> http://cr.openjdk.java.net/~gtriantafill/8152206/webrev/top/webrev/ >> >> http://cr.openjdk.java.net/~gtriantafill/8152206/webrev/jdk/webrev/ >> >> http://cr.openjdk.java.net/~gtriantafill/8152206/webrev/hotspot/webrev/ >> >> >> >> The fix was tested with the hotspot_all test group on Linux x64. Thanks. >> >> -George >> > From karen.kinnear at oracle.com Thu Jan 19 16:54:19 2017 From: karen.kinnear at oracle.com (Karen Kinnear) Date: Thu, 19 Jan 2017 11:54:19 -0500 Subject: RFR 8171971: Fix timing bug in JVM management of package export lists In-Reply-To: <5880D7D5.2070100@oracle.com> References: <5880D7D5.2070100@oracle.com> Message-ID: Harold, Thank you for doing this. And for the comments on the states. Looks good. I believe that the changes you have made have fixed the timing holes. Thank you. 1) packageEntry.hpp: 145: set_unqual_exported() It would be helpful to have a comment that this explicitly sets PKG_EXP_UNQUALIFIED and clears PKG_EXP_ALLUNNAMED. I realized my concept of states is slightly different, with AllUnnamed, NamedExports and AllUnnamed+NamedExports being different states. In future, when we rework this for performance, let?s revisit the states. > On Jan 19, 2017, at 10:14 AM, Lois Foltan wrote: > > > On 1/18/2017 10:05 AM, harold seigel wrote: >> Hi, >> >> Please review this fix for the package export timing holes discussed in JDK-8171971. The fix reduces the number of PackageEntry fields that are used to maintain a package's export state and uses the Module_lock to protect all access to these fields. >> >> Also, in cases where a package transitions from having qualified exports to being unqualifiedly exported, it fixes the cleanup of its qualified export list by removing the _exported_pending_delete field and using just is_unqual_exported() to determine when the qualified exports list can be purged (at a safepoint). >> >> Open Webrev: http://cr.openjdk.java.net/~hseigel/bug_8171971/webrev/ >> >> JBS Bug: https://bugs.openjdk.java.net/browse/JDK-8171971 >> >> The fix was tested with the hotspot, java/lang, java/util, java/io, JFR, and other JTReg tests, the JCK lang and VM tests, RBT tier2 - tier5 tests on LinuxX64, and the colocated and non-colocated NSK tests. > > Hi Harold, > > Looks good! A couple of comments in src/share/vm/classfile/packageEntry.hpp: > > - line #133, the method has_qual_exports_list(). A comment should be added ahead of this method to indicate that even if the _qualified_exports list is empty the package is still considered qualifiedly exported and a similar comment should be added to PackageEntry::purge_qualified_exports(). During a GC safepoint, it could be the scenario that all modules on a given package's qualified export list die, thus leaving an allocated but empty _qualified_exports field. If the _qualified_exports GrowableArray was deleted in that scenario, then according to the new _exports_flag and a NULL value for _qualified_exports, the package would erroneously not be considered qualifiedly exported anymore. So not deleting the GrowableArray today is deliberate, because the transition from qualifiedly exported to not exported is not currently valid. Agreed, we may want to revisit that in future. 2) Harold, could you possibly add that state change to the comment to the ?A package cannot transition from?, i.e. after line 58? > This can be reworked in the future to have the _exports_flag contain definitions for all possible states. Relying on the state of whether _qualified_exports field is NULL or not can be problematic, but I think your changes do improve upon ensuring a PackageEntry maintains a valid state. > > - line #86 - please add a blank line for readability > - line #139 & #143 please out the return expression in parentheses. > > Thanks, > Lois > >> >> Thanks, Harold thanks, Karen From lois.foltan at oracle.com Thu Jan 19 17:06:03 2017 From: lois.foltan at oracle.com (Lois Foltan) Date: Thu, 19 Jan 2017 12:06:03 -0500 Subject: RFR 8171971: Fix timing bug in JVM management of package export lists In-Reply-To: References: <5880D7D5.2070100@oracle.com> Message-ID: <5880F1FB.7000003@oracle.com> On 1/19/2017 11:54 AM, Karen Kinnear wrote: > Harold, > > Thank you for doing this. And for the comments on the states. > > Looks good. I believe that the changes you have made have fixed the > timing holes. Thank you. > > 1) packageEntry.hpp: 145: set_unqual_exported() > It would be helpful to have a comment that this explicitly sets > PKG_EXP_UNQUALIFIED and clears PKG_EXP_ALLUNNAMED. > > I realized my concept of states is slightly different, > with AllUnnamed, NamedExports and AllUnnamed+NamedExports being > different states. In future, when we rework this > for performance, let?s revisit the states. > >> On Jan 19, 2017, at 10:14 AM, Lois Foltan > > wrote: >> >> >> On 1/18/2017 10:05 AM, harold seigel wrote: >>> Hi, >>> >>> Please review this fix for the package export timing holes discussed >>> in JDK-8171971. The fix reduces the number of PackageEntry fields >>> that are used to maintain a package's export state and uses the >>> Module_lock to protect all access to these fields. >>> >>> Also, in cases where a package transitions from having qualified >>> exports to being unqualifiedly exported, it fixes the cleanup of its >>> qualified export list by removing the _exported_pending_delete field >>> and using just is_unqual_exported() to determine when the qualified >>> exports list can be purged (at a safepoint). >>> >>> Open Webrev: http://cr.openjdk.java.net/~hseigel/bug_8171971/webrev/ >>> >>> >>> JBS Bug: https://bugs.openjdk.java.net/browse/JDK-8171971 >>> >>> The fix was tested with the hotspot, java/lang, java/util, java/io, >>> JFR, and other JTReg tests, the JCK lang and VM tests, RBT tier2 - >>> tier5 tests on LinuxX64, and the colocated and non-colocated NSK tests. >> >> Hi Harold, >> >> Looks good! A couple of comments in >> src/share/vm/classfile/packageEntry.hpp: >> >> - line #133, the method has_qual_exports_list(). A comment should be >> added ahead of this method to indicate that even if the >> _qualified_exports list is empty the package is still considered >> qualifiedly exported and a similar comment should be added to >> PackageEntry::purge_qualified_exports(). During a GC safepoint, it >> could be the scenario that all modules on a given package's qualified >> export list die, thus leaving an allocated but empty >> _qualified_exports field. If the _qualified_exports GrowableArray >> was deleted in that scenario, then according to the new _exports_flag >> and a NULL value for _qualified_exports, the package would >> erroneously not be considered qualifiedly exported anymore. > So not deleting the GrowableArray today is deliberate, because the > transition from qualifiedly exported to not exported is not currently > valid. Yes it is deliberate and hotspot/test/runtime/modules/ModuleStress/ExportModuleStressTest.java is a good test of exactly this scenario. Lois > Agreed, we may want to revisit that in future. > > 2) Harold, could you possibly add that state change to the comment to > the ?A package cannot transition from?, i.e. after line 58? >> This can be reworked in the future to have the _exports_flag contain >> definitions for all possible states. Relying on the state of whether >> _qualified_exports field is NULL or not can be problematic, but I >> think your changes do improve upon ensuring a PackageEntry maintains >> a valid state. >> >> - line #86 - please add a blank line for readability >> - line #139 & #143 please out the return expression in parentheses. >> >> Thanks, >> Lois >> >>> >>> Thanks, Harold > > thanks, > Karen > From harold.seigel at oracle.com Thu Jan 19 18:07:04 2017 From: harold.seigel at oracle.com (harold seigel) Date: Thu, 19 Jan 2017 13:07:04 -0500 Subject: RFR 8171971: Fix timing bug in JVM management of package export lists In-Reply-To: <216c40d7-17b3-7273-e0dc-be95e127d456@oracle.com> References: <216c40d7-17b3-7273-e0dc-be95e127d456@oracle.com> Message-ID: Hi Serguei, Thanks for the review. I think that Modules::add_module_exports_to_all_unnamed() and similar functions are okay because the functions that they call to set the new export states take out the module lock. If you are concerned about them then maybe enter a new bug for them? Thanks, Harold On 1/19/2017 5:05 AM, serguei.spitsyn at oracle.com wrote: > Hi Harold, > > It looks pretty good to me. > > One question though. > > || src/share/vm/classfile/modules.cpp > > I wonder if a synchronization is needed for the functions like > Modules::add_module_exports_to_all_unnamed. > But this is unrelated to your particular fix. > || > > Thanks, > Serguei > > > > On 1/18/17 07:05, harold seigel wrote: >> Hi, >> >> Please review this fix for the package export timing holes discussed >> in JDK-8171971. The fix reduces the number of PackageEntry fields >> that are used to maintain a package's export state and uses the >> Module_lock to protect all access to these fields. >> >> Also, in cases where a package transitions from having qualified >> exports to being unqualifiedly exported, it fixes the cleanup of its >> qualified export list by removing the _exported_pending_delete field >> and using just is_unqual_exported() to determine when the qualified >> exports list can be purged (at a safepoint). >> >> Open Webrev: http://cr.openjdk.java.net/~hseigel/bug_8171971/webrev/ >> >> JBS Bug: https://bugs.openjdk.java.net/browse/JDK-8171971 >> >> The fix was tested with the hotspot, java/lang, java/util, java/io, >> JFR, and other JTReg tests, the JCK lang and VM tests, RBT tier2 - >> tier5 tests on LinuxX64, and the colocated and non-colocated NSK tests. >> >> Thanks, Harold >> > From harold.seigel at oracle.com Thu Jan 19 18:07:59 2017 From: harold.seigel at oracle.com (harold seigel) Date: Thu, 19 Jan 2017 13:07:59 -0500 Subject: RFR 8171971: Fix timing bug in JVM management of package export lists In-Reply-To: <0164797A-1723-4133-85C2-4EB8382B5696@oracle.com> References: <8cace753-b271-83f4-29e1-69752a889fa8@oracle.com> <0164797A-1723-4133-85C2-4EB8382B5696@oracle.com> Message-ID: <08bea1b3-9965-d6c3-acf5-41b43fec0a31@oracle.com> Thanks David, Karen. I changed the copyrights to reflect both 2016 and 2017. Harold On 1/19/2017 9:28 AM, Karen Kinnear wrote: > Harold, that matches my understanding. Start with date when the file was created, and span any year that the file was modified. > > thanks, > Karen > >> On Jan 19, 2017, at 7:45 AM, harold seigel wrote: >> >> Hi David, >> >> So if a file, such as modules.cpp, was added to the JVM for JDK-9, but written in 2016, then its copyright should be "2016, 2017," even though the file hasn't yet been part of an actual release? >> >> Thanks, Harold >> >> >> On 1/18/2017 8:04 PM, David Holmes wrote: >>> Hi Harold, >>> >>> Not a review but noticed the copyright updates are not correct - should now be "2016, 2017," for most of the files not just "2017," >>> >>> Thanks, >>> David >>> >>> On 19/01/2017 1:05 AM, harold seigel wrote: >>>> Hi, >>>> >>>> Please review this fix for the package export timing holes discussed in >>>> JDK-8171971. The fix reduces the number of PackageEntry fields that are >>>> used to maintain a package's export state and uses the Module_lock to >>>> protect all access to these fields. >>>> >>>> Also, in cases where a package transitions from having qualified exports >>>> to being unqualifiedly exported, it fixes the cleanup of its qualified >>>> export list by removing the _exported_pending_delete field and using >>>> just is_unqual_exported() to determine when the qualified exports list >>>> can be purged (at a safepoint). >>>> >>>> Open Webrev: http://cr.openjdk.java.net/~hseigel/bug_8171971/webrev/ >>>> >>>> JBS Bug: https://bugs.openjdk.java.net/browse/JDK-8171971 >>>> >>>> The fix was tested with the hotspot, java/lang, java/util, java/io, JFR, >>>> and other JTReg tests, the JCK lang and VM tests, RBT tier2 - tier5 >>>> tests on LinuxX64, and the colocated and non-colocated NSK tests. >>>> >>>> Thanks, Harold >>>> From harold.seigel at oracle.com Thu Jan 19 18:37:53 2017 From: harold.seigel at oracle.com (harold seigel) Date: Thu, 19 Jan 2017 13:37:53 -0500 Subject: RFR 8171971: Fix timing bug in JVM management of package export lists In-Reply-To: References: <5880D7D5.2070100@oracle.com> Message-ID: <0d47d0fd-459f-c44e-4eff-527bac1b3a21@oracle.com> Hi Karen, Lois, Thanks for the review! Please see comments in-line. Harold On 1/19/2017 11:54 AM, Karen Kinnear wrote: > Harold, > > Thank you for doing this. And for the comments on the states. > > Looks good. I believe that the changes you have made have fixed the > timing holes. Thank you. > > 1) packageEntry.hpp: 145: set_unqual_exported() > It would be helpful to have a comment that this explicitly sets > PKG_EXP_UNQUALIFIED and clears PKG_EXP_ALLUNNAMED. Done > > I realized my concept of states is slightly different, > with AllUnnamed, NamedExports and AllUnnamed+NamedExports being > different states. In future, when we rework this > for performance, let?s revisit the states. Agreed > >> On Jan 19, 2017, at 10:14 AM, Lois Foltan > > wrote: >> >> >> On 1/18/2017 10:05 AM, harold seigel wrote: >>> Hi, >>> >>> Please review this fix for the package export timing holes discussed >>> in JDK-8171971. The fix reduces the number of PackageEntry fields >>> that are used to maintain a package's export state and uses the >>> Module_lock to protect all access to these fields. >>> >>> Also, in cases where a package transitions from having qualified >>> exports to being unqualifiedly exported, it fixes the cleanup of its >>> qualified export list by removing the _exported_pending_delete field >>> and using just is_unqual_exported() to determine when the qualified >>> exports list can be purged (at a safepoint). >>> >>> Open Webrev: http://cr.openjdk.java.net/~hseigel/bug_8171971/webrev/ >>> >>> >>> JBS Bug: https://bugs.openjdk.java.net/browse/JDK-8171971 >>> >>> The fix was tested with the hotspot, java/lang, java/util, java/io, >>> JFR, and other JTReg tests, the JCK lang and VM tests, RBT tier2 - >>> tier5 tests on LinuxX64, and the colocated and non-colocated NSK tests. >> >> Hi Harold, >> >> Looks good! A couple of comments in >> src/share/vm/classfile/packageEntry.hpp: >> >> - line #133, the method has_qual_exports_list(). A comment should be >> added ahead of this method to indicate that even if the >> _qualified_exports list is empty the package is still considered >> qualifiedly exported and a similar comment should be added to >> PackageEntry::purge_qualified_exports(). During a GC safepoint, it >> could be the scenario that all modules on a given package's qualified >> export list die, thus leaving an allocated but empty >> _qualified_exports field. If the _qualified_exports GrowableArray >> was deleted in that scenario, then according to the new _exports_flag >> and a NULL value for _qualified_exports, the package would >> erroneously not be considered qualifiedly exported anymore. Good point. I added the comments. > So not deleting the GrowableArray today is deliberate, because the > transition from qualifiedly exported to not exported is not currently > valid. > Agreed, we may want to revisit that in future. > > 2) Harold, could you possibly add that state change to the comment to > the ?A package cannot transition from?, i.e. after line 58? Done >> This can be reworked in the future to have the _exports_flag contain >> definitions for all possible states. Relying on the state of whether >> _qualified_exports field is NULL or not can be problematic, but I >> think your changes do improve upon ensuring a PackageEntry maintains >> a valid state. >> >> - line #86 - please add a blank line for readability okay >> - line #139 & #143 please out the return expression in parentheses. (okay) >> >> Thanks, >> Lois >> >>> >>> Thanks, Harold > > thanks, > Karen > From serguei.spitsyn at oracle.com Thu Jan 19 21:04:14 2017 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Thu, 19 Jan 2017 13:04:14 -0800 Subject: RFR 8171971: Fix timing bug in JVM management of package export lists In-Reply-To: References: <216c40d7-17b3-7273-e0dc-be95e127d456@oracle.com> Message-ID: <610cfd93-2b40-ae6f-8f5f-f731820b363d@oracle.com> Hi Harold, On 1/19/17 10:07, harold seigel wrote: > Hi Serguei, > > Thanks for the review. > > I think that Modules::add_module_exports_to_all_unnamed() and similar > functions are okay because the functions that they call to set the new > export states take out the module lock. You are right. I've misread some fragment, sorry. > > If you are concerned about them then maybe enter a new bug for them? Never mind. Thanks, Serguei > > Thanks, Harold > > > On 1/19/2017 5:05 AM, serguei.spitsyn at oracle.com wrote: >> Hi Harold, >> >> It looks pretty good to me. >> >> One question though. >> >> || src/share/vm/classfile/modules.cpp >> >> I wonder if a synchronization is needed for the functions like >> Modules::add_module_exports_to_all_unnamed. >> But this is unrelated to your particular fix. >> || >> >> Thanks, >> Serguei >> >> >> >> On 1/18/17 07:05, harold seigel wrote: >>> Hi, >>> >>> Please review this fix for the package export timing holes discussed >>> in JDK-8171971. The fix reduces the number of PackageEntry fields >>> that are used to maintain a package's export state and uses the >>> Module_lock to protect all access to these fields. >>> >>> Also, in cases where a package transitions from having qualified >>> exports to being unqualifiedly exported, it fixes the cleanup of its >>> qualified export list by removing the _exported_pending_delete field >>> and using just is_unqual_exported() to determine when the qualified >>> exports list can be purged (at a safepoint). >>> >>> Open Webrev: http://cr.openjdk.java.net/~hseigel/bug_8171971/webrev/ >>> >>> JBS Bug: https://bugs.openjdk.java.net/browse/JDK-8171971 >>> >>> The fix was tested with the hotspot, java/lang, java/util, java/io, >>> JFR, and other JTReg tests, the JCK lang and VM tests, RBT tier2 - >>> tier5 tests on LinuxX64, and the colocated and non-colocated NSK tests. >>> >>> Thanks, Harold >>> >> > From david.holmes at oracle.com Thu Jan 19 23:20:21 2017 From: david.holmes at oracle.com (David Holmes) Date: Fri, 20 Jan 2017 09:20:21 +1000 Subject: RFR 8171971: Fix timing bug in JVM management of package export lists In-Reply-To: <8cace753-b271-83f4-29e1-69752a889fa8@oracle.com> References: <8cace753-b271-83f4-29e1-69752a889fa8@oracle.com> Message-ID: <12b65cc4-fa75-b867-0615-3c41ba5fd314@oracle.com> On 19/01/2017 10:45 PM, harold seigel wrote: > Hi David, > > So if a file, such as modules.cpp, was added to the JVM for JDK-9, but > written in 2016, then its copyright should be "2016, 2017," even though > the file hasn't yet been part of an actual release? Yes. The file's relation to a binary release is not relevant. Thanks, David > Thanks, Harold > > > On 1/18/2017 8:04 PM, David Holmes wrote: >> Hi Harold, >> >> Not a review but noticed the copyright updates are not correct - >> should now be "2016, 2017," for most of the files not just "2017," >> >> Thanks, >> David >> >> On 19/01/2017 1:05 AM, harold seigel wrote: >>> Hi, >>> >>> Please review this fix for the package export timing holes discussed in >>> JDK-8171971. The fix reduces the number of PackageEntry fields that are >>> used to maintain a package's export state and uses the Module_lock to >>> protect all access to these fields. >>> >>> Also, in cases where a package transitions from having qualified exports >>> to being unqualifiedly exported, it fixes the cleanup of its qualified >>> export list by removing the _exported_pending_delete field and using >>> just is_unqual_exported() to determine when the qualified exports list >>> can be purged (at a safepoint). >>> >>> Open Webrev: http://cr.openjdk.java.net/~hseigel/bug_8171971/webrev/ >>> >>> JBS Bug: https://bugs.openjdk.java.net/browse/JDK-8171971 >>> >>> The fix was tested with the hotspot, java/lang, java/util, java/io, JFR, >>> and other JTReg tests, the JCK lang and VM tests, RBT tier2 - tier5 >>> tests on LinuxX64, and the colocated and non-colocated NSK tests. >>> >>> Thanks, Harold >>> > From daniel.daugherty at oracle.com Thu Jan 19 23:38:32 2017 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Thu, 19 Jan 2017 16:38:32 -0700 Subject: XXXS RFR: 8173081 VM no longer prints "Picked up _JAVA_OPTIONS: " message Message-ID: <7f18661e-a1b4-0356-9f04-83dc702dea28@oracle.com> Greetings, This fix restores the following diagnostic message: Picked up _JAVA_OPTIONS: XXXX that was accidentally removed during the long journey for: JDK-8061999 Enhance VM option parsing to allow options to be specified in a file JDK-8173081 VM no longer prints "Picked up _JAVA_OPTONS: " message https://bugs.openjdk.java.net/browse/JDK-8173081 Webrev URL: http://cr.openjdk.java.net/~dcubed/8173081-webrev/0-jdk9-hs/ Testing: JPRT test job manual check of output when _JAVA_OPTIONS and JAVA_TOOL_OPTIONS are set in the environment Thanks, in advance, for a (R)eview or two... Dan From harold.seigel at oracle.com Thu Jan 19 23:38:48 2017 From: harold.seigel at oracle.com (harold seigel) Date: Thu, 19 Jan 2017 18:38:48 -0500 Subject: RFR 8171971: Fix timing bug in JVM management of package export lists In-Reply-To: <0d47d0fd-459f-c44e-4eff-527bac1b3a21@oracle.com> References: <5880D7D5.2070100@oracle.com> <0d47d0fd-459f-c44e-4eff-527bac1b3a21@oracle.com> Message-ID: Hi, Here is an updated webrev containing the changes that you suggested. http://cr.openjdk.java.net/~hseigel/bug_8171971.2/webrev/index.html Could you take another look? Thanks, Harold On 1/19/2017 1:37 PM, harold seigel wrote: > Hi Karen, Lois, > > Thanks for the review! Please see comments in-line. > > Harold > > > On 1/19/2017 11:54 AM, Karen Kinnear wrote: >> Harold, >> >> Thank you for doing this. And for the comments on the states. >> >> Looks good. I believe that the changes you have made have fixed the >> timing holes. Thank you. >> >> 1) packageEntry.hpp: 145: set_unqual_exported() >> It would be helpful to have a comment that this explicitly sets >> PKG_EXP_UNQUALIFIED and clears PKG_EXP_ALLUNNAMED. > Done >> >> I realized my concept of states is slightly different, >> with AllUnnamed, NamedExports and AllUnnamed+NamedExports being >> different states. In future, when we rework this >> for performance, let?s revisit the states. > Agreed >> >>> On Jan 19, 2017, at 10:14 AM, Lois Foltan >> > wrote: >>> >>> >>> On 1/18/2017 10:05 AM, harold seigel wrote: >>>> Hi, >>>> >>>> Please review this fix for the package export timing holes >>>> discussed in JDK-8171971. The fix reduces the number of >>>> PackageEntry fields that are used to maintain a package's export >>>> state and uses the Module_lock to protect all access to these fields. >>>> >>>> Also, in cases where a package transitions from having qualified >>>> exports to being unqualifiedly exported, it fixes the cleanup of >>>> its qualified export list by removing the _exported_pending_delete >>>> field and using just is_unqual_exported() to determine when the >>>> qualified exports list can be purged (at a safepoint). >>>> >>>> Open Webrev: >>>> http://cr.openjdk.java.net/~hseigel/bug_8171971/webrev/ >>>> >>>> >>>> JBS Bug: https://bugs.openjdk.java.net/browse/JDK-8171971 >>>> >>>> The fix was tested with the hotspot, java/lang, java/util, java/io, >>>> JFR, and other JTReg tests, the JCK lang and VM tests, RBT tier2 - >>>> tier5 tests on LinuxX64, and the colocated and non-colocated NSK >>>> tests. >>> >>> Hi Harold, >>> >>> Looks good! A couple of comments in >>> src/share/vm/classfile/packageEntry.hpp: >>> >>> - line #133, the method has_qual_exports_list(). A comment should >>> be added ahead of this method to indicate that even if the >>> _qualified_exports list is empty the package is still considered >>> qualifiedly exported and a similar comment should be added to >>> PackageEntry::purge_qualified_exports(). During a GC safepoint, it >>> could be the scenario that all modules on a given package's >>> qualified export list die, thus leaving an allocated but empty >>> _qualified_exports field. If the _qualified_exports GrowableArray >>> was deleted in that scenario, then according to the new >>> _exports_flag and a NULL value for _qualified_exports, the package >>> would erroneously not be considered qualifiedly exported anymore. > Good point. I added the comments. >> So not deleting the GrowableArray today is deliberate, because the >> transition from qualifiedly exported to not exported is not currently >> valid. >> Agreed, we may want to revisit that in future. >> >> 2) Harold, could you possibly add that state change to the comment to >> the ?A package cannot transition from?, i.e. after line 58? > Done >>> This can be reworked in the future to have the _exports_flag contain >>> definitions for all possible states. Relying on the state of >>> whether _qualified_exports field is NULL or not can be problematic, >>> but I think your changes do improve upon ensuring a PackageEntry >>> maintains a valid state. >>> >>> - line #86 - please add a blank line for readability > okay >>> - line #139 & #143 please out the return expression in parentheses. > (okay) >>> >>> Thanks, >>> Lois >>> >>>> >>>> Thanks, Harold >> >> thanks, >> Karen >> > From harold.seigel at oracle.com Thu Jan 19 23:40:40 2017 From: harold.seigel at oracle.com (harold seigel) Date: Thu, 19 Jan 2017 18:40:40 -0500 Subject: XXXS RFR: 8173081 VM no longer prints "Picked up _JAVA_OPTIONS: " message In-Reply-To: <7f18661e-a1b4-0356-9f04-83dc702dea28@oracle.com> References: <7f18661e-a1b4-0356-9f04-83dc702dea28@oracle.com> Message-ID: <0f319041-acea-cf70-6e90-3af0eba3fbf8@oracle.com> Hi Dan, The change looks good. Thanks, Harold On 1/19/2017 6:38 PM, Daniel D. Daugherty wrote: > Greetings, > > This fix restores the following diagnostic message: > > Picked up _JAVA_OPTIONS: XXXX > > that was accidentally removed during the long journey for: > > JDK-8061999 Enhance VM option parsing to allow options > to be specified in a file > > JDK-8173081 VM no longer prints "Picked up _JAVA_OPTONS: " message > https://bugs.openjdk.java.net/browse/JDK-8173081 > > Webrev URL: http://cr.openjdk.java.net/~dcubed/8173081-webrev/0-jdk9-hs/ > > Testing: JPRT test job > manual check of output when _JAVA_OPTIONS and JAVA_TOOL_OPTIONS > are set in the environment > > Thanks, in advance, for a (R)eview or two... > > Dan From daniel.daugherty at oracle.com Thu Jan 19 23:43:36 2017 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Thu, 19 Jan 2017 16:43:36 -0700 Subject: XXXS RFR: 8173081 VM no longer prints "Picked up _JAVA_OPTIONS: " message In-Reply-To: <0f319041-acea-cf70-6e90-3af0eba3fbf8@oracle.com> References: <7f18661e-a1b4-0356-9f04-83dc702dea28@oracle.com> <0f319041-acea-cf70-6e90-3af0eba3fbf8@oracle.com> Message-ID: Thanks for the lightning fast (R)eview! Dan On 1/19/17 4:40 PM, harold seigel wrote: > Hi Dan, > > The change looks good. > > Thanks, Harold > > > On 1/19/2017 6:38 PM, Daniel D. Daugherty wrote: >> Greetings, >> >> This fix restores the following diagnostic message: >> >> Picked up _JAVA_OPTIONS: XXXX >> >> that was accidentally removed during the long journey for: >> >> JDK-8061999 Enhance VM option parsing to allow options >> to be specified in a file >> >> JDK-8173081 VM no longer prints "Picked up _JAVA_OPTONS: " message >> https://bugs.openjdk.java.net/browse/JDK-8173081 >> >> Webrev URL: http://cr.openjdk.java.net/~dcubed/8173081-webrev/0-jdk9-hs/ >> >> Testing: JPRT test job >> manual check of output when _JAVA_OPTIONS and JAVA_TOOL_OPTIONS >> are set in the environment >> >> Thanks, in advance, for a (R)eview or two... >> >> Dan > From mandy.chung at oracle.com Thu Jan 19 23:46:17 2017 From: mandy.chung at oracle.com (Mandy Chung) Date: Thu, 19 Jan 2017 15:46:17 -0800 Subject: XXXS RFR: 8173081 VM no longer prints "Picked up _JAVA_OPTIONS: " message In-Reply-To: <7f18661e-a1b4-0356-9f04-83dc702dea28@oracle.com> References: <7f18661e-a1b4-0356-9f04-83dc702dea28@oracle.com> Message-ID: +1 Mandy > On Jan 19, 2017, at 3:38 PM, Daniel D. Daugherty wrote: > > Greetings, > > This fix restores the following diagnostic message: > > Picked up _JAVA_OPTIONS: XXXX > > that was accidentally removed during the long journey for: > > JDK-8061999 Enhance VM option parsing to allow options > to be specified in a file > > JDK-8173081 VM no longer prints "Picked up _JAVA_OPTONS: " message > https://bugs.openjdk.java.net/browse/JDK-8173081 > > Webrev URL: http://cr.openjdk.java.net/~dcubed/8173081-webrev/0-jdk9-hs/ > > Testing: JPRT test job > manual check of output when _JAVA_OPTIONS and JAVA_TOOL_OPTIONS > are set in the environment > > Thanks, in advance, for a (R)eview or two... > > Dan From daniel.daugherty at oracle.com Thu Jan 19 23:46:55 2017 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Thu, 19 Jan 2017 16:46:55 -0700 Subject: XXXS RFR: 8173081 VM no longer prints "Picked up _JAVA_OPTIONS: " message In-Reply-To: References: <7f18661e-a1b4-0356-9f04-83dc702dea28@oracle.com> Message-ID: Thanks for the fast review! Dan On 1/19/17 4:46 PM, Mandy Chung wrote: > +1 > > Mandy > >> On Jan 19, 2017, at 3:38 PM, Daniel D. Daugherty wrote: >> >> Greetings, >> >> This fix restores the following diagnostic message: >> >> Picked up _JAVA_OPTIONS: XXXX >> >> that was accidentally removed during the long journey for: >> >> JDK-8061999 Enhance VM option parsing to allow options >> to be specified in a file >> >> JDK-8173081 VM no longer prints "Picked up _JAVA_OPTONS: " message >> https://bugs.openjdk.java.net/browse/JDK-8173081 >> >> Webrev URL: http://cr.openjdk.java.net/~dcubed/8173081-webrev/0-jdk9-hs/ >> >> Testing: JPRT test job >> manual check of output when _JAVA_OPTIONS and JAVA_TOOL_OPTIONS >> are set in the environment >> >> Thanks, in advance, for a (R)eview or two... >> >> Dan From david.holmes at oracle.com Fri Jan 20 02:10:06 2017 From: david.holmes at oracle.com (David Holmes) Date: Fri, 20 Jan 2017 12:10:06 +1000 Subject: XXXS RFR: 8173081 VM no longer prints "Picked up _JAVA_OPTIONS: " message In-Reply-To: <7f18661e-a1b4-0356-9f04-83dc702dea28@oracle.com> References: <7f18661e-a1b4-0356-9f04-83dc702dea28@oracle.com> Message-ID: <9fa8c945-faf2-983a-9e44-9ca4335ffeca@oracle.com> Looks good to me! Thanks, David On 20/01/2017 9:38 AM, Daniel D. Daugherty wrote: > Greetings, > > This fix restores the following diagnostic message: > > Picked up _JAVA_OPTIONS: XXXX > > that was accidentally removed during the long journey for: > > JDK-8061999 Enhance VM option parsing to allow options > to be specified in a file > > JDK-8173081 VM no longer prints "Picked up _JAVA_OPTONS: " message > https://bugs.openjdk.java.net/browse/JDK-8173081 > > Webrev URL: http://cr.openjdk.java.net/~dcubed/8173081-webrev/0-jdk9-hs/ > > Testing: JPRT test job > manual check of output when _JAVA_OPTIONS and JAVA_TOOL_OPTIONS > are set in the environment > > Thanks, in advance, for a (R)eview or two... > > Dan From daniel.daugherty at oracle.com Fri Jan 20 02:17:06 2017 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Thu, 19 Jan 2017 19:17:06 -0700 Subject: XXXS RFR: 8173081 VM no longer prints "Picked up _JAVA_OPTIONS: " message In-Reply-To: <9fa8c945-faf2-983a-9e44-9ca4335ffeca@oracle.com> References: <7f18661e-a1b4-0356-9f04-83dc702dea28@oracle.com> <9fa8c945-faf2-983a-9e44-9ca4335ffeca@oracle.com> Message-ID: <5e4bafd4-8eb7-1ec3-f1d2-cf48bcd52d13@oracle.com> Thanks! Dan On 1/19/17 7:10 PM, David Holmes wrote: > Looks good to me! > > Thanks, > David > > On 20/01/2017 9:38 AM, Daniel D. Daugherty wrote: >> Greetings, >> >> This fix restores the following diagnostic message: >> >> Picked up _JAVA_OPTIONS: XXXX >> >> that was accidentally removed during the long journey for: >> >> JDK-8061999 Enhance VM option parsing to allow options >> to be specified in a file >> >> JDK-8173081 VM no longer prints "Picked up _JAVA_OPTONS: " message >> https://bugs.openjdk.java.net/browse/JDK-8173081 >> >> Webrev URL: http://cr.openjdk.java.net/~dcubed/8173081-webrev/0-jdk9-hs/ >> >> Testing: JPRT test job >> manual check of output when _JAVA_OPTIONS and JAVA_TOOL_OPTIONS >> are set in the environment >> >> Thanks, in advance, for a (R)eview or two... >> >> Dan From lois.foltan at oracle.com Fri Jan 20 13:55:41 2017 From: lois.foltan at oracle.com (Lois Foltan) Date: Fri, 20 Jan 2017 08:55:41 -0500 Subject: RFR 8171971: Fix timing bug in JVM management of package export lists In-Reply-To: References: <5880D7D5.2070100@oracle.com> <0d47d0fd-459f-c44e-4eff-527bac1b3a21@oracle.com> Message-ID: <588216DD.2060905@oracle.com> Looks good. Lois On 1/19/2017 6:38 PM, harold seigel wrote: > Hi, > > Here is an updated webrev containing the changes that you suggested. > > http://cr.openjdk.java.net/~hseigel/bug_8171971.2/webrev/index.html > > Could you take another look? > > Thanks, Harold > > On 1/19/2017 1:37 PM, harold seigel wrote: >> Hi Karen, Lois, >> >> Thanks for the review! Please see comments in-line. >> >> Harold >> >> >> On 1/19/2017 11:54 AM, Karen Kinnear wrote: >>> Harold, >>> >>> Thank you for doing this. And for the comments on the states. >>> >>> Looks good. I believe that the changes you have made have fixed the >>> timing holes. Thank you. >>> >>> 1) packageEntry.hpp: 145: set_unqual_exported() >>> It would be helpful to have a comment that this explicitly sets >>> PKG_EXP_UNQUALIFIED and clears PKG_EXP_ALLUNNAMED. >> Done >>> >>> I realized my concept of states is slightly different, >>> with AllUnnamed, NamedExports and AllUnnamed+NamedExports being >>> different states. In future, when we rework this >>> for performance, let?s revisit the states. >> Agreed >>> >>>> On Jan 19, 2017, at 10:14 AM, Lois Foltan >>> > wrote: >>>> >>>> >>>> On 1/18/2017 10:05 AM, harold seigel wrote: >>>>> Hi, >>>>> >>>>> Please review this fix for the package export timing holes >>>>> discussed in JDK-8171971. The fix reduces the number of >>>>> PackageEntry fields that are used to maintain a package's export >>>>> state and uses the Module_lock to protect all access to these fields. >>>>> >>>>> Also, in cases where a package transitions from having qualified >>>>> exports to being unqualifiedly exported, it fixes the cleanup of >>>>> its qualified export list by removing the _exported_pending_delete >>>>> field and using just is_unqual_exported() to determine when the >>>>> qualified exports list can be purged (at a safepoint). >>>>> >>>>> Open Webrev: >>>>> http://cr.openjdk.java.net/~hseigel/bug_8171971/webrev/ >>>>> >>>>> >>>>> JBS Bug: https://bugs.openjdk.java.net/browse/JDK-8171971 >>>>> >>>>> The fix was tested with the hotspot, java/lang, java/util, >>>>> java/io, JFR, and other JTReg tests, the JCK lang and VM tests, >>>>> RBT tier2 - tier5 tests on LinuxX64, and the colocated and >>>>> non-colocated NSK tests. >>>> >>>> Hi Harold, >>>> >>>> Looks good! A couple of comments in >>>> src/share/vm/classfile/packageEntry.hpp: >>>> >>>> - line #133, the method has_qual_exports_list(). A comment should >>>> be added ahead of this method to indicate that even if the >>>> _qualified_exports list is empty the package is still considered >>>> qualifiedly exported and a similar comment should be added to >>>> PackageEntry::purge_qualified_exports(). During a GC safepoint, it >>>> could be the scenario that all modules on a given package's >>>> qualified export list die, thus leaving an allocated but empty >>>> _qualified_exports field. If the _qualified_exports GrowableArray >>>> was deleted in that scenario, then according to the new >>>> _exports_flag and a NULL value for _qualified_exports, the package >>>> would erroneously not be considered qualifiedly exported anymore. >> Good point. I added the comments. >>> So not deleting the GrowableArray today is deliberate, because the >>> transition from qualifiedly exported to not exported is not >>> currently valid. >>> Agreed, we may want to revisit that in future. >>> >>> 2) Harold, could you possibly add that state change to the comment >>> to the ?A package cannot transition from?, i.e. after line 58? >> Done >>>> This can be reworked in the future to have the _exports_flag >>>> contain definitions for all possible states. Relying on the state >>>> of whether _qualified_exports field is NULL or not can be >>>> problematic, but I think your changes do improve upon ensuring a >>>> PackageEntry maintains a valid state. >>>> >>>> - line #86 - please add a blank line for readability >> okay >>>> - line #139 & #143 please out the return expression in parentheses. >> (okay) >>>> >>>> Thanks, >>>> Lois >>>> >>>>> >>>>> Thanks, Harold >>> >>> thanks, >>> Karen >>> >> > From harold.seigel at oracle.com Fri Jan 20 13:56:05 2017 From: harold.seigel at oracle.com (harold seigel) Date: Fri, 20 Jan 2017 08:56:05 -0500 Subject: RFR 8171971: Fix timing bug in JVM management of package export lists In-Reply-To: <588216DD.2060905@oracle.com> References: <5880D7D5.2070100@oracle.com> <0d47d0fd-459f-c44e-4eff-527bac1b3a21@oracle.com> <588216DD.2060905@oracle.com> Message-ID: Thanks! Harold On 1/20/2017 8:55 AM, Lois Foltan wrote: > Looks good. > Lois > > On 1/19/2017 6:38 PM, harold seigel wrote: >> Hi, >> >> Here is an updated webrev containing the changes that you suggested. >> >> http://cr.openjdk.java.net/~hseigel/bug_8171971.2/webrev/index.html >> >> Could you take another look? >> >> Thanks, Harold >> >> On 1/19/2017 1:37 PM, harold seigel wrote: >>> Hi Karen, Lois, >>> >>> Thanks for the review! Please see comments in-line. >>> >>> Harold >>> >>> >>> On 1/19/2017 11:54 AM, Karen Kinnear wrote: >>>> Harold, >>>> >>>> Thank you for doing this. And for the comments on the states. >>>> >>>> Looks good. I believe that the changes you have made have fixed the >>>> timing holes. Thank you. >>>> >>>> 1) packageEntry.hpp: 145: set_unqual_exported() >>>> It would be helpful to have a comment that this explicitly sets >>>> PKG_EXP_UNQUALIFIED and clears PKG_EXP_ALLUNNAMED. >>> Done >>>> >>>> I realized my concept of states is slightly different, >>>> with AllUnnamed, NamedExports and AllUnnamed+NamedExports being >>>> different states. In future, when we rework this >>>> for performance, let?s revisit the states. >>> Agreed >>>> >>>>> On Jan 19, 2017, at 10:14 AM, Lois Foltan >>>> > wrote: >>>>> >>>>> >>>>> On 1/18/2017 10:05 AM, harold seigel wrote: >>>>>> Hi, >>>>>> >>>>>> Please review this fix for the package export timing holes >>>>>> discussed in JDK-8171971. The fix reduces the number of >>>>>> PackageEntry fields that are used to maintain a package's export >>>>>> state and uses the Module_lock to protect all access to these >>>>>> fields. >>>>>> >>>>>> Also, in cases where a package transitions from having qualified >>>>>> exports to being unqualifiedly exported, it fixes the cleanup of >>>>>> its qualified export list by removing the >>>>>> _exported_pending_delete field and using just >>>>>> is_unqual_exported() to determine when the qualified exports list >>>>>> can be purged (at a safepoint). >>>>>> >>>>>> Open Webrev: >>>>>> http://cr.openjdk.java.net/~hseigel/bug_8171971/webrev/ >>>>>> >>>>>> >>>>>> JBS Bug: https://bugs.openjdk.java.net/browse/JDK-8171971 >>>>>> >>>>>> The fix was tested with the hotspot, java/lang, java/util, >>>>>> java/io, JFR, and other JTReg tests, the JCK lang and VM tests, >>>>>> RBT tier2 - tier5 tests on LinuxX64, and the colocated and >>>>>> non-colocated NSK tests. >>>>> >>>>> Hi Harold, >>>>> >>>>> Looks good! A couple of comments in >>>>> src/share/vm/classfile/packageEntry.hpp: >>>>> >>>>> - line #133, the method has_qual_exports_list(). A comment should >>>>> be added ahead of this method to indicate that even if the >>>>> _qualified_exports list is empty the package is still considered >>>>> qualifiedly exported and a similar comment should be added to >>>>> PackageEntry::purge_qualified_exports(). During a GC safepoint, >>>>> it could be the scenario that all modules on a given package's >>>>> qualified export list die, thus leaving an allocated but empty >>>>> _qualified_exports field. If the _qualified_exports GrowableArray >>>>> was deleted in that scenario, then according to the new >>>>> _exports_flag and a NULL value for _qualified_exports, the package >>>>> would erroneously not be considered qualifiedly exported anymore. >>> Good point. I added the comments. >>>> So not deleting the GrowableArray today is deliberate, because the >>>> transition from qualifiedly exported to not exported is not >>>> currently valid. >>>> Agreed, we may want to revisit that in future. >>>> >>>> 2) Harold, could you possibly add that state change to the comment >>>> to the ?A package cannot transition from?, i.e. after line 58? >>> Done >>>>> This can be reworked in the future to have the _exports_flag >>>>> contain definitions for all possible states. Relying on the state >>>>> of whether _qualified_exports field is NULL or not can be >>>>> problematic, but I think your changes do improve upon ensuring a >>>>> PackageEntry maintains a valid state. >>>>> >>>>> - line #86 - please add a blank line for readability >>> okay >>>>> - line #139 & #143 please out the return expression in parentheses. >>> (okay) >>>>> >>>>> Thanks, >>>>> Lois >>>>> >>>>>> >>>>>> Thanks, Harold >>>> >>>> thanks, >>>> Karen >>>> >>> >> > From serguei.spitsyn at oracle.com Fri Jan 20 14:47:23 2017 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Fri, 20 Jan 2017 06:47:23 -0800 Subject: RFR 8171971: Fix timing bug in JVM management of package export lists In-Reply-To: <588216DD.2060905@oracle.com> References: <5880D7D5.2070100@oracle.com> <0d47d0fd-459f-c44e-4eff-527bac1b3a21@oracle.com> <588216DD.2060905@oracle.com> Message-ID: <8f7103f4-631e-b1d3-d109-08b309ee739d@oracle.com> +1 Thanks, Serguei On 1/20/17 05:55, Lois Foltan wrote: > Looks good. > Lois > > On 1/19/2017 6:38 PM, harold seigel wrote: >> Hi, >> >> Here is an updated webrev containing the changes that you suggested. >> >> http://cr.openjdk.java.net/~hseigel/bug_8171971.2/webrev/index.html >> >> Could you take another look? >> >> Thanks, Harold >> >> On 1/19/2017 1:37 PM, harold seigel wrote: >>> Hi Karen, Lois, >>> >>> Thanks for the review! Please see comments in-line. >>> >>> Harold >>> >>> >>> On 1/19/2017 11:54 AM, Karen Kinnear wrote: >>>> Harold, >>>> >>>> Thank you for doing this. And for the comments on the states. >>>> >>>> Looks good. I believe that the changes you have made have fixed the >>>> timing holes. Thank you. >>>> >>>> 1) packageEntry.hpp: 145: set_unqual_exported() >>>> It would be helpful to have a comment that this explicitly sets >>>> PKG_EXP_UNQUALIFIED and clears PKG_EXP_ALLUNNAMED. >>> Done >>>> >>>> I realized my concept of states is slightly different, >>>> with AllUnnamed, NamedExports and AllUnnamed+NamedExports being >>>> different states. In future, when we rework this >>>> for performance, let?s revisit the states. >>> Agreed >>>> >>>>> On Jan 19, 2017, at 10:14 AM, Lois Foltan >>>> > wrote: >>>>> >>>>> >>>>> On 1/18/2017 10:05 AM, harold seigel wrote: >>>>>> Hi, >>>>>> >>>>>> Please review this fix for the package export timing holes >>>>>> discussed in JDK-8171971. The fix reduces the number of >>>>>> PackageEntry fields that are used to maintain a package's export >>>>>> state and uses the Module_lock to protect all access to these >>>>>> fields. >>>>>> >>>>>> Also, in cases where a package transitions from having qualified >>>>>> exports to being unqualifiedly exported, it fixes the cleanup of >>>>>> its qualified export list by removing the >>>>>> _exported_pending_delete field and using just >>>>>> is_unqual_exported() to determine when the qualified exports list >>>>>> can be purged (at a safepoint). >>>>>> >>>>>> Open Webrev: >>>>>> http://cr.openjdk.java.net/~hseigel/bug_8171971/webrev/ >>>>>> >>>>>> >>>>>> JBS Bug: https://bugs.openjdk.java.net/browse/JDK-8171971 >>>>>> >>>>>> The fix was tested with the hotspot, java/lang, java/util, >>>>>> java/io, JFR, and other JTReg tests, the JCK lang and VM tests, >>>>>> RBT tier2 - tier5 tests on LinuxX64, and the colocated and >>>>>> non-colocated NSK tests. >>>>> >>>>> Hi Harold, >>>>> >>>>> Looks good! A couple of comments in >>>>> src/share/vm/classfile/packageEntry.hpp: >>>>> >>>>> - line #133, the method has_qual_exports_list(). A comment should >>>>> be added ahead of this method to indicate that even if the >>>>> _qualified_exports list is empty the package is still considered >>>>> qualifiedly exported and a similar comment should be added to >>>>> PackageEntry::purge_qualified_exports(). During a GC safepoint, >>>>> it could be the scenario that all modules on a given package's >>>>> qualified export list die, thus leaving an allocated but empty >>>>> _qualified_exports field. If the _qualified_exports GrowableArray >>>>> was deleted in that scenario, then according to the new >>>>> _exports_flag and a NULL value for _qualified_exports, the package >>>>> would erroneously not be considered qualifiedly exported anymore. >>> Good point. I added the comments. >>>> So not deleting the GrowableArray today is deliberate, because the >>>> transition from qualifiedly exported to not exported is not >>>> currently valid. >>>> Agreed, we may want to revisit that in future. >>>> >>>> 2) Harold, could you possibly add that state change to the comment >>>> to the ?A package cannot transition from?, i.e. after line 58? >>> Done >>>>> This can be reworked in the future to have the _exports_flag >>>>> contain definitions for all possible states. Relying on the state >>>>> of whether _qualified_exports field is NULL or not can be >>>>> problematic, but I think your changes do improve upon ensuring a >>>>> PackageEntry maintains a valid state. >>>>> >>>>> - line #86 - please add a blank line for readability >>> okay >>>>> - line #139 & #143 please out the return expression in parentheses. >>> (okay) >>>>> >>>>> Thanks, >>>>> Lois >>>>> >>>>>> >>>>>> Thanks, Harold >>>> >>>> thanks, >>>> Karen >>>> >>> >> > From harold.seigel at oracle.com Fri Jan 20 15:27:29 2017 From: harold.seigel at oracle.com (harold seigel) Date: Fri, 20 Jan 2017 10:27:29 -0500 Subject: RFR 8171971: Fix timing bug in JVM management of package export lists In-Reply-To: <8f7103f4-631e-b1d3-d109-08b309ee739d@oracle.com> References: <5880D7D5.2070100@oracle.com> <0d47d0fd-459f-c44e-4eff-527bac1b3a21@oracle.com> <588216DD.2060905@oracle.com> <8f7103f4-631e-b1d3-d109-08b309ee739d@oracle.com> Message-ID: <26b24a9c-e91d-008c-83a9-98ee87e5fbc1@oracle.com> Thanks Seguei! Harold On 1/20/2017 9:47 AM, serguei.spitsyn at oracle.com wrote: > +1 > > Thanks, > Serguei > > > On 1/20/17 05:55, Lois Foltan wrote: >> Looks good. >> Lois >> >> On 1/19/2017 6:38 PM, harold seigel wrote: >>> Hi, >>> >>> Here is an updated webrev containing the changes that you suggested. >>> >>> http://cr.openjdk.java.net/~hseigel/bug_8171971.2/webrev/index.html >>> >>> Could you take another look? >>> >>> Thanks, Harold >>> >>> On 1/19/2017 1:37 PM, harold seigel wrote: >>>> Hi Karen, Lois, >>>> >>>> Thanks for the review! Please see comments in-line. >>>> >>>> Harold >>>> >>>> >>>> On 1/19/2017 11:54 AM, Karen Kinnear wrote: >>>>> Harold, >>>>> >>>>> Thank you for doing this. And for the comments on the states. >>>>> >>>>> Looks good. I believe that the changes you have made have fixed >>>>> the timing holes. Thank you. >>>>> >>>>> 1) packageEntry.hpp: 145: set_unqual_exported() >>>>> It would be helpful to have a comment that this explicitly sets >>>>> PKG_EXP_UNQUALIFIED and clears PKG_EXP_ALLUNNAMED. >>>> Done >>>>> >>>>> I realized my concept of states is slightly different, >>>>> with AllUnnamed, NamedExports and AllUnnamed+NamedExports being >>>>> different states. In future, when we rework this >>>>> for performance, let?s revisit the states. >>>> Agreed >>>>> >>>>>> On Jan 19, 2017, at 10:14 AM, Lois Foltan >>>>> > wrote: >>>>>> >>>>>> >>>>>> On 1/18/2017 10:05 AM, harold seigel wrote: >>>>>>> Hi, >>>>>>> >>>>>>> Please review this fix for the package export timing holes >>>>>>> discussed in JDK-8171971. The fix reduces the number of >>>>>>> PackageEntry fields that are used to maintain a package's export >>>>>>> state and uses the Module_lock to protect all access to these >>>>>>> fields. >>>>>>> >>>>>>> Also, in cases where a package transitions from having qualified >>>>>>> exports to being unqualifiedly exported, it fixes the cleanup of >>>>>>> its qualified export list by removing the >>>>>>> _exported_pending_delete field and using just >>>>>>> is_unqual_exported() to determine when the qualified exports >>>>>>> list can be purged (at a safepoint). >>>>>>> >>>>>>> Open Webrev: >>>>>>> http://cr.openjdk.java.net/~hseigel/bug_8171971/webrev/ >>>>>>> >>>>>>> >>>>>>> JBS Bug: https://bugs.openjdk.java.net/browse/JDK-8171971 >>>>>>> >>>>>>> The fix was tested with the hotspot, java/lang, java/util, >>>>>>> java/io, JFR, and other JTReg tests, the JCK lang and VM tests, >>>>>>> RBT tier2 - tier5 tests on LinuxX64, and the colocated and >>>>>>> non-colocated NSK tests. >>>>>> >>>>>> Hi Harold, >>>>>> >>>>>> Looks good! A couple of comments in >>>>>> src/share/vm/classfile/packageEntry.hpp: >>>>>> >>>>>> - line #133, the method has_qual_exports_list(). A comment >>>>>> should be added ahead of this method to indicate that even if the >>>>>> _qualified_exports list is empty the package is still considered >>>>>> qualifiedly exported and a similar comment should be added to >>>>>> PackageEntry::purge_qualified_exports(). During a GC safepoint, >>>>>> it could be the scenario that all modules on a given package's >>>>>> qualified export list die, thus leaving an allocated but empty >>>>>> _qualified_exports field. If the _qualified_exports >>>>>> GrowableArray was deleted in that scenario, then according to the >>>>>> new _exports_flag and a NULL value for _qualified_exports, the >>>>>> package would erroneously not be considered qualifiedly exported >>>>>> anymore. >>>> Good point. I added the comments. >>>>> So not deleting the GrowableArray today is deliberate, because the >>>>> transition from qualifiedly exported to not exported is not >>>>> currently valid. >>>>> Agreed, we may want to revisit that in future. >>>>> >>>>> 2) Harold, could you possibly add that state change to the comment >>>>> to the ?A package cannot transition from?, i.e. after line 58? >>>> Done >>>>>> This can be reworked in the future to have the _exports_flag >>>>>> contain definitions for all possible states. Relying on the >>>>>> state of whether _qualified_exports field is NULL or not can be >>>>>> problematic, but I think your changes do improve upon ensuring a >>>>>> PackageEntry maintains a valid state. >>>>>> >>>>>> - line #86 - please add a blank line for readability >>>> okay >>>>>> - line #139 & #143 please out the return expression in parentheses. >>>> (okay) >>>>>> >>>>>> Thanks, >>>>>> Lois >>>>>> >>>>>>> >>>>>>> Thanks, Harold >>>>> >>>>> thanks, >>>>> Karen >>>>> >>>> >>> >> > From karen.kinnear at oracle.com Fri Jan 20 16:13:14 2017 From: karen.kinnear at oracle.com (Karen Kinnear) Date: Fri, 20 Jan 2017 11:13:14 -0500 Subject: RFR 8171971: Fix timing bug in JVM management of package export lists In-Reply-To: References: <5880D7D5.2070100@oracle.com> <0d47d0fd-459f-c44e-4eff-527bac1b3a21@oracle.com> <588216DD.2060905@oracle.com> Message-ID: <28324A0B-DFD1-4974-BE38-B6AE00CDE313@oracle.com> Harold, Thank you for the review. Looks good. Can you possibly changed packageEntry.hpp lines 60->61 ?Because transitions are only allowed from less exposure to greater exposure, the transition from qualifiedly exported to not exported would be considered a backward direction. Therefore the implementation considers a package as qualifiedly exported even if its export-list exists but is empty." I believe that the forward transition restriction will make it cleaner for us to make these into lock-free snapshots going forward. thanks, Karen > On Jan 20, 2017, at 8:56 AM, harold seigel wrote: > > Thanks! > > Harold > > > On 1/20/2017 8:55 AM, Lois Foltan wrote: >> Looks good. >> Lois >> >> On 1/19/2017 6:38 PM, harold seigel wrote: >>> Hi, >>> >>> Here is an updated webrev containing the changes that you suggested. >>> >>> http://cr.openjdk.java.net/~hseigel/bug_8171971.2/webrev/index.html >>> >>> Could you take another look? >>> >>> Thanks, Harold >>> >>> On 1/19/2017 1:37 PM, harold seigel wrote: >>>> Hi Karen, Lois, >>>> >>>> Thanks for the review! Please see comments in-line. >>>> >>>> Harold >>>> >>>> >>>> On 1/19/2017 11:54 AM, Karen Kinnear wrote: >>>>> Harold, >>>>> >>>>> Thank you for doing this. And for the comments on the states. >>>>> >>>>> Looks good. I believe that the changes you have made have fixed the timing holes. Thank you. >>>>> >>>>> 1) packageEntry.hpp: 145: set_unqual_exported() >>>>> It would be helpful to have a comment that this explicitly sets PKG_EXP_UNQUALIFIED and clears PKG_EXP_ALLUNNAMED. >>>> Done >>>>> >>>>> I realized my concept of states is slightly different, >>>>> with AllUnnamed, NamedExports and AllUnnamed+NamedExports being different states. In future, when we rework this >>>>> for performance, let?s revisit the states. >>>> Agreed >>>>> >>>>>> On Jan 19, 2017, at 10:14 AM, Lois Foltan > wrote: >>>>>> >>>>>> >>>>>> On 1/18/2017 10:05 AM, harold seigel wrote: >>>>>>> Hi, >>>>>>> >>>>>>> Please review this fix for the package export timing holes discussed in JDK-8171971. The fix reduces the number of PackageEntry fields that are used to maintain a package's export state and uses the Module_lock to protect all access to these fields. >>>>>>> >>>>>>> Also, in cases where a package transitions from having qualified exports to being unqualifiedly exported, it fixes the cleanup of its qualified export list by removing the _exported_pending_delete field and using just is_unqual_exported() to determine when the qualified exports list can be purged (at a safepoint). >>>>>>> >>>>>>> Open Webrev: http://cr.openjdk.java.net/~hseigel/bug_8171971/webrev/ >>>>>>> >>>>>>> JBS Bug: https://bugs.openjdk.java.net/browse/JDK-8171971 >>>>>>> >>>>>>> The fix was tested with the hotspot, java/lang, java/util, java/io, JFR, and other JTReg tests, the JCK lang and VM tests, RBT tier2 - tier5 tests on LinuxX64, and the colocated and non-colocated NSK tests. >>>>>> >>>>>> Hi Harold, >>>>>> >>>>>> Looks good! A couple of comments in src/share/vm/classfile/packageEntry.hpp: >>>>>> >>>>>> - line #133, the method has_qual_exports_list(). A comment should be added ahead of this method to indicate that even if the _qualified_exports list is empty the package is still considered qualifiedly exported and a similar comment should be added to PackageEntry::purge_qualified_exports(). During a GC safepoint, it could be the scenario that all modules on a given package's qualified export list die, thus leaving an allocated but empty _qualified_exports field. If the _qualified_exports GrowableArray was deleted in that scenario, then according to the new _exports_flag and a NULL value for _qualified_exports, the package would erroneously not be considered qualifiedly exported anymore. >>>> Good point. I added the comments. >>>>> So not deleting the GrowableArray today is deliberate, because the transition from qualifiedly exported to not exported is not currently valid. >>>>> Agreed, we may want to revisit that in future. >>>>> >>>>> 2) Harold, could you possibly add that state change to the comment to the ?A package cannot transition from?, i.e. after line 58? >>>> Done >>>>>> This can be reworked in the future to have the _exports_flag contain definitions for all possible states. Relying on the state of whether _qualified_exports field is NULL or not can be problematic, but I think your changes do improve upon ensuring a PackageEntry maintains a valid state. >>>>>> >>>>>> - line #86 - please add a blank line for readability >>>> okay >>>>>> - line #139 & #143 please out the return expression in parentheses. >>>> (okay) >>>>>> >>>>>> Thanks, >>>>>> Lois >>>>>> >>>>>>> >>>>>>> Thanks, Harold >>>>> >>>>> thanks, >>>>> Karen >>>>> >>>> >>> >> > From harold.seigel at oracle.com Fri Jan 20 16:29:57 2017 From: harold.seigel at oracle.com (harold seigel) Date: Fri, 20 Jan 2017 11:29:57 -0500 Subject: RFR 8171971: Fix timing bug in JVM management of package export lists In-Reply-To: <28324A0B-DFD1-4974-BE38-B6AE00CDE313@oracle.com> References: <5880D7D5.2070100@oracle.com> <0d47d0fd-459f-c44e-4eff-527bac1b3a21@oracle.com> <588216DD.2060905@oracle.com> <28324A0B-DFD1-4974-BE38-B6AE00CDE313@oracle.com> Message-ID: Thanks Karen! I'll make the change before I push it. Harold On 1/20/2017 11:13 AM, Karen Kinnear wrote: > Harold, > > Thank you for the review. Looks good. > > Can you possibly changed packageEntry.hpp lines 60->61 > ?Because transitions are only allowed from less exposure to greater exposure, the transition from > qualifiedly exported to not exported would be considered a backward direction. Therefore the implementation > considers a package as qualifiedly exported even if its export-list exists but is empty." > > I believe that the forward transition restriction will make it cleaner for us to make these into lock-free snapshots > going forward. > > thanks, > Karen > >> On Jan 20, 2017, at 8:56 AM, harold seigel wrote: >> >> Thanks! >> >> Harold >> >> >> On 1/20/2017 8:55 AM, Lois Foltan wrote: >>> Looks good. >>> Lois >>> >>> On 1/19/2017 6:38 PM, harold seigel wrote: >>>> Hi, >>>> >>>> Here is an updated webrev containing the changes that you suggested. >>>> >>>> http://cr.openjdk.java.net/~hseigel/bug_8171971.2/webrev/index.html >>>> >>>> Could you take another look? >>>> >>>> Thanks, Harold >>>> >>>> On 1/19/2017 1:37 PM, harold seigel wrote: >>>>> Hi Karen, Lois, >>>>> >>>>> Thanks for the review! Please see comments in-line. >>>>> >>>>> Harold >>>>> >>>>> >>>>> On 1/19/2017 11:54 AM, Karen Kinnear wrote: >>>>>> Harold, >>>>>> >>>>>> Thank you for doing this. And for the comments on the states. >>>>>> >>>>>> Looks good. I believe that the changes you have made have fixed the timing holes. Thank you. >>>>>> >>>>>> 1) packageEntry.hpp: 145: set_unqual_exported() >>>>>> It would be helpful to have a comment that this explicitly sets PKG_EXP_UNQUALIFIED and clears PKG_EXP_ALLUNNAMED. >>>>> Done >>>>>> I realized my concept of states is slightly different, >>>>>> with AllUnnamed, NamedExports and AllUnnamed+NamedExports being different states. In future, when we rework this >>>>>> for performance, let?s revisit the states. >>>>> Agreed >>>>>>> On Jan 19, 2017, at 10:14 AM, Lois Foltan > wrote: >>>>>>> >>>>>>> >>>>>>> On 1/18/2017 10:05 AM, harold seigel wrote: >>>>>>>> Hi, >>>>>>>> >>>>>>>> Please review this fix for the package export timing holes discussed in JDK-8171971. The fix reduces the number of PackageEntry fields that are used to maintain a package's export state and uses the Module_lock to protect all access to these fields. >>>>>>>> >>>>>>>> Also, in cases where a package transitions from having qualified exports to being unqualifiedly exported, it fixes the cleanup of its qualified export list by removing the _exported_pending_delete field and using just is_unqual_exported() to determine when the qualified exports list can be purged (at a safepoint). >>>>>>>> >>>>>>>> Open Webrev: http://cr.openjdk.java.net/~hseigel/bug_8171971/webrev/ >>>>>>>> >>>>>>>> JBS Bug: https://bugs.openjdk.java.net/browse/JDK-8171971 >>>>>>>> >>>>>>>> The fix was tested with the hotspot, java/lang, java/util, java/io, JFR, and other JTReg tests, the JCK lang and VM tests, RBT tier2 - tier5 tests on LinuxX64, and the colocated and non-colocated NSK tests. >>>>>>> Hi Harold, >>>>>>> >>>>>>> Looks good! A couple of comments in src/share/vm/classfile/packageEntry.hpp: >>>>>>> >>>>>>> - line #133, the method has_qual_exports_list(). A comment should be added ahead of this method to indicate that even if the _qualified_exports list is empty the package is still considered qualifiedly exported and a similar comment should be added to PackageEntry::purge_qualified_exports(). During a GC safepoint, it could be the scenario that all modules on a given package's qualified export list die, thus leaving an allocated but empty _qualified_exports field. If the _qualified_exports GrowableArray was deleted in that scenario, then according to the new _exports_flag and a NULL value for _qualified_exports, the package would erroneously not be considered qualifiedly exported anymore. >>>>> Good point. I added the comments. >>>>>> So not deleting the GrowableArray today is deliberate, because the transition from qualifiedly exported to not exported is not currently valid. >>>>>> Agreed, we may want to revisit that in future. >>>>>> >>>>>> 2) Harold, could you possibly add that state change to the comment to the ?A package cannot transition from?, i.e. after line 58? >>>>> Done >>>>>>> This can be reworked in the future to have the _exports_flag contain definitions for all possible states. Relying on the state of whether _qualified_exports field is NULL or not can be problematic, but I think your changes do improve upon ensuring a PackageEntry maintains a valid state. >>>>>>> >>>>>>> - line #86 - please add a blank line for readability >>>>> okay >>>>>>> - line #139 & #143 please out the return expression in parentheses. >>>>> (okay) >>>>>>> Thanks, >>>>>>> Lois >>>>>>> >>>>>>>> Thanks, Harold >>>>>> thanks, >>>>>> Karen >>>>>> From coleen.phillimore at oracle.com Mon Jan 23 23:00:40 2017 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Mon, 23 Jan 2017 18:00:40 -0500 Subject: RFR (S) 8140685: Fix backtrace building to not rely on constant pool merging Message-ID: Summary: Store Symbol* for the name in the backtrace There was some thought that storing a u2 for cpref would be more memory efficient than storing Symbol* in the backtraces, but recent runs of Jetty show that this doesn't cause footprint increases or performance decreases. Storing the Symbol* for the method name guarantees it is there when creating the StackTraceElement, whereas cpref relies on constant pool merging for redefinition and is dependent on being an index in the right constant pool, which has been a source of bugs in the past. dev-submit performance testing was run with no regressions. Also, all hotspot jtreg tests were run. This is a change for JDK10 whenever that opens. open webrev at http://cr.openjdk.java.net/~coleenp/8140685.01/webrev bug link https://bugs.openjdk.java.net/browse/JDK-8140685 Thanks, Coleen From george.triantafillou at oracle.com Mon Jan 23 23:53:59 2017 From: george.triantafillou at oracle.com (George Triantafillou) Date: Mon, 23 Jan 2017 18:53:59 -0500 Subject: RFR (S) 8140685: Fix backtrace building to not rely on constant pool merging In-Reply-To: References: Message-ID: <043520e2-f6ec-f798-d1b1-93c260bd94d6@oracle.com> Hi Coleen, src/share/vm/classfile/javaClasses.cpp, change line 1694 to: // Note: this doesn't leak symbols because the mirror in the backtrace keeps the -George On 1/23/2017 6:00 PM, Coleen Phillimore wrote: > Summary: Store Symbol* for the name in the backtrace > > There was some thought that storing a u2 for cpref would be more > memory efficient than storing Symbol* in the backtraces, but recent > runs of Jetty show that this doesn't cause footprint increases or > performance decreases. Storing the Symbol* for the method name > guarantees it is there when creating the StackTraceElement, whereas > cpref relies on constant pool merging for redefinition and is > dependent on being an index in the right constant pool, which has been > a source of bugs in the past. > > dev-submit performance testing was run with no regressions. Also, all > hotspot jtreg tests were run. > > This is a change for JDK10 whenever that opens. > > open webrev at http://cr.openjdk.java.net/~coleenp/8140685.01/webrev > bug link https://bugs.openjdk.java.net/browse/JDK-8140685 > > Thanks, > Coleen From david.holmes at oracle.com Tue Jan 24 00:11:22 2017 From: david.holmes at oracle.com (David Holmes) Date: Tue, 24 Jan 2017 10:11:22 +1000 Subject: RFR (S) 8140685: Fix backtrace building to not rely on constant pool merging In-Reply-To: References: Message-ID: <6fc23c46-2ac9-ae2a-1ff1-85e8bed85ecb@oracle.com> Hi Coleen, On 24/01/2017 9:00 AM, Coleen Phillimore wrote: > Summary: Store Symbol* for the name in the backtrace > > There was some thought that storing a u2 for cpref would be more memory > efficient than storing Symbol* in the backtraces, but recent runs of > Jetty show that this doesn't cause footprint increases or performance > decreases. Storing the Symbol* for the method name guarantees it is > there when creating the StackTraceElement, whereas cpref relies on > constant pool merging for redefinition and is dependent on being an > index in the right constant pool, which has been a source of bugs in the > past. This all sounds reasonable. But I'm not very clear on the Symbol ref-counting protocol, so can't really say if this may leak them or not. > dev-submit performance testing was run with no regressions. Also, all > hotspot jtreg tests were run. > > This is a change for JDK10 whenever that opens. > > open webrev at http://cr.openjdk.java.net/~coleenp/8140685.01/webrev > bug link https://bugs.openjdk.java.net/browse/JDK-8140685 The bug refers to a method-id to Method* change, nothing about cpref to Symbol*. Can you update the bug so that it reflects the actual change please. Thanks, David > Thanks, > Coleen From kim.barrett at oracle.com Tue Jan 24 02:35:43 2017 From: kim.barrett at oracle.com (Kim Barrett) Date: Mon, 23 Jan 2017 21:35:43 -0500 Subject: RFR (S) 8140685: Fix backtrace building to not rely on constant pool merging In-Reply-To: References: Message-ID: <7C42364A-2813-4F67-8800-ECE332E0C7EE@oracle.com> > On Jan 23, 2017, at 6:00 PM, Coleen Phillimore wrote: > > Summary: Store Symbol* for the name in the backtrace > > There was some thought that storing a u2 for cpref would be more memory efficient than storing Symbol* in the backtraces, but recent runs of Jetty show that this doesn't cause footprint increases or performance decreases. Storing the Symbol* for the method name guarantees it is there when creating the StackTraceElement, whereas cpref relies on constant pool merging for redefinition and is dependent on being an index in the right constant pool, which has been a source of bugs in the past. > > dev-submit performance testing was run with no regressions. Also, all hotspot jtreg tests were run. > > This is a change for JDK10 whenever that opens. > > open webrev at http://cr.openjdk.java.net/~coleenp/8140685.01/webrev > bug link https://bugs.openjdk.java.net/browse/JDK-8140685 > > Thanks, > Coleen Looks good. Just a couple of minor nits. ------------------------------------------------------------------------------ src/share/vm/classfile/javaClasses.cpp 1631 assert(_methods->length() == _bcis->length() && 1632 _methods->length() == _mirrors->length(), Pre-existing: Shouldn't the _names (formerly _cprefs) length also be checked here? ------------------------------------------------------------------------------ src/share/vm/classfile/javaClasses.cpp 1694 // Note:this doesn't leaks symbols because the mirror in the backtrace keeps the s/leaks/leak ------------------------------------------------------------------------------ From lois.foltan at oracle.com Tue Jan 24 15:09:14 2017 From: lois.foltan at oracle.com (Lois Foltan) Date: Tue, 24 Jan 2017 10:09:14 -0500 Subject: RFR (S) 8140685: Fix backtrace building to not rely on constant pool merging In-Reply-To: References: Message-ID: <58876E1A.9030904@oracle.com> Looks good Coleen. Lois On 1/23/2017 6:00 PM, Coleen Phillimore wrote: > Summary: Store Symbol* for the name in the backtrace > > There was some thought that storing a u2 for cpref would be more > memory efficient than storing Symbol* in the backtraces, but recent > runs of Jetty show that this doesn't cause footprint increases or > performance decreases. Storing the Symbol* for the method name > guarantees it is there when creating the StackTraceElement, whereas > cpref relies on constant pool merging for redefinition and is > dependent on being an index in the right constant pool, which has been > a source of bugs in the past. > > dev-submit performance testing was run with no regressions. Also, all > hotspot jtreg tests were run. > > This is a change for JDK10 whenever that opens. > > open webrev at http://cr.openjdk.java.net/~coleenp/8140685.01/webrev > bug link https://bugs.openjdk.java.net/browse/JDK-8140685 > > Thanks, > Coleen From george.triantafillou at oracle.com Wed Jan 25 16:44:42 2017 From: george.triantafillou at oracle.com (George Triantafillou) Date: Wed, 25 Jan 2017 11:44:42 -0500 Subject: RFR JDK-8171115: Tests containing module names ending in digits need to change Message-ID: Please review this fix for JDK-8171115: JBS Bug: https://bugs.openjdk.java.net/browse/JDK-8171115 Open Webrev: http://cr.openjdk.java.net/~gtriantafill/8171115-webrev/webrev/ The tests were modified so that module names don't end in a digit. The module tests will continue to pass regardless of when this restriction is enforced. The fix was tested with the hotspot_all test group on Linux x64. Thanks. -George From george.triantafillou at oracle.com Wed Jan 25 17:09:52 2017 From: george.triantafillou at oracle.com (George Triantafillou) Date: Wed, 25 Jan 2017 12:09:52 -0500 Subject: RFR JDK-8171115: Tests containing module names ending in digits need to change In-Reply-To: References: Message-ID: <0d50e841-341e-a624-22a7-69204a3f3a9a@oracle.com> After an off-list discussion with Harold and Alan, the fix version was updated to 9-repo-jigsaw. Consider this review request withdrawn. Thanks. -George On 1/25/2017 11:44 AM, George Triantafillou wrote: > Please review this fix for JDK-8171115: > > JBS Bug: https://bugs.openjdk.java.net/browse/JDK-8171115 > Open Webrev: > http://cr.openjdk.java.net/~gtriantafill/8171115-webrev/webrev/ > > > The tests were modified so that module names don't end in a digit. > The module tests will continue to pass regardless of when this > restriction is enforced. > > The fix was tested with the hotspot_all test group on Linux x64. Thanks. > > -George > From calvin.cheung at oracle.com Wed Jan 25 20:06:05 2017 From: calvin.cheung at oracle.com (Calvin Cheung) Date: Wed, 25 Jan 2017 12:06:05 -0800 Subject: RFR(XS): 8173163: searching for a versioned entry in a multi-release jar in hotspot is inconsistent with java code Message-ID: <5889052D.5060201@oracle.com> Please review this simple bug fix for JDK 9. bug: https://bugs.openjdk.java.net/browse/JDK-8173163 webrev: http://cr.openjdk.java.net/~ccheung/8173163/webrev.00/ thanks, Calvin From ioi.lam at oracle.com Wed Jan 25 20:26:52 2017 From: ioi.lam at oracle.com (Ioi Lam) Date: Wed, 25 Jan 2017 12:26:52 -0800 Subject: RFR(XS): 8173163: searching for a versioned entry in a multi-release jar in hotspot is inconsistent with java code In-Reply-To: <5889052D.5060201@oracle.com> References: <5889052D.5060201@oracle.com> Message-ID: <58890A0C.1000204@oracle.com> Hi Calvin, the change looks good to me. Just a nit pick: 370 if (version < base_version) is_multi_ver = false; I think the usual HotSpot coding style is: 370 if (version < base_version) { is_multi_ver = false; } So it can be easily stepped over in a debugger. Thanks - Ioi On 1/25/17 12:06 PM, Calvin Cheung wrote: > Please review this simple bug fix for JDK 9. > > bug: https://bugs.openjdk.java.net/browse/JDK-8173163 > > webrev: http://cr.openjdk.java.net/~ccheung/8173163/webrev.00/ > > thanks, > Calvin From calvin.cheung at oracle.com Wed Jan 25 20:45:26 2017 From: calvin.cheung at oracle.com (Calvin Cheung) Date: Wed, 25 Jan 2017 12:45:26 -0800 Subject: RFR(XS): 8173163: searching for a versioned entry in a multi-release jar in hotspot is inconsistent with java code In-Reply-To: <58890A0C.1000204@oracle.com> References: <5889052D.5060201@oracle.com> <58890A0C.1000204@oracle.com> Message-ID: <58890E66.8000701@oracle.com> Thanks for your quick review, Ioi. I'll make the change before pushing the change. thanks, Calvin On 1/25/17, 12:26 PM, Ioi Lam wrote: > Hi Calvin, the change looks good to me. Just a nit pick: > > 370 if (version < base_version) is_multi_ver = false; > > I think the usual HotSpot coding style is: > > 370 if (version < base_version) { > is_multi_ver = false; > } > > So it can be easily stepped over in a debugger. > > Thanks > - Ioi > > > > On 1/25/17 12:06 PM, Calvin Cheung wrote: >> Please review this simple bug fix for JDK 9. >> >> bug: https://bugs.openjdk.java.net/browse/JDK-8173163 >> >> webrev: http://cr.openjdk.java.net/~ccheung/8173163/webrev.00/ >> >> thanks, >> Calvin > From serguei.spitsyn at oracle.com Wed Jan 25 20:51:25 2017 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Wed, 25 Jan 2017 12:51:25 -0800 Subject: RFR(XS): 8173163: searching for a versioned entry in a multi-release jar in hotspot is inconsistent with java code In-Reply-To: <5889052D.5060201@oracle.com> References: <5889052D.5060201@oracle.com> Message-ID: <1f42229c-9f3a-81eb-5e9e-0686e613e22e@oracle.com> Hi Calvin, Looks good. Nit: The comments in this file normally start from a capital letter. Thanks, Serguei On 1/25/17 12:06, Calvin Cheung wrote: > Please review this simple bug fix for JDK 9. > > bug: https://bugs.openjdk.java.net/browse/JDK-8173163 > > webrev: http://cr.openjdk.java.net/~ccheung/8173163/webrev.00/ > > thanks, > Calvin From jiangli.zhou at oracle.com Wed Jan 25 21:10:49 2017 From: jiangli.zhou at oracle.com (Jiangli Zhou) Date: Wed, 25 Jan 2017 13:10:49 -0800 Subject: RFR(XS): 8173163: searching for a versioned entry in a multi-release jar in hotspot is inconsistent with java code In-Reply-To: <5889052D.5060201@oracle.com> References: <5889052D.5060201@oracle.com> Message-ID: <91133121-7AB3-4F62-AF15-AB40206F3D95@oracle.com> Hi Calvin, With the change when 'version > cur_ver', the JVM prints a warning saying "the requested JDK version is not supported in multiple version jars" but uses the highest versioned entry instead of the base entry. The warning should be removed or be made more clear to also reflect the behavior change. Thanks, Jiangli > On Jan 25, 2017, at 12:06 PM, Calvin Cheung wrote: > > Please review this simple bug fix for JDK 9. > > bug: https://bugs.openjdk.java.net/browse/JDK-8173163 > > webrev: http://cr.openjdk.java.net/~ccheung/8173163/webrev.00/ > > thanks, > Calvin From coleen.phillimore at oracle.com Wed Jan 25 21:47:18 2017 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Wed, 25 Jan 2017 16:47:18 -0500 Subject: RFR (S) 8140685: Fix backtrace building to not rely on constant pool merging In-Reply-To: <043520e2-f6ec-f798-d1b1-93c260bd94d6@oracle.com> References: <043520e2-f6ec-f798-d1b1-93c260bd94d6@oracle.com> Message-ID: On 1/23/17 6:53 PM, George Triantafillou wrote: > Hi Coleen, > > src/share/vm/classfile/javaClasses.cpp, change line 1694 to: > > // Note: this doesn't leak symbols because the mirror in the backtrace > keeps the Thank you for the correction! Coleen > > -George > > On 1/23/2017 6:00 PM, Coleen Phillimore wrote: >> Summary: Store Symbol* for the name in the backtrace >> >> There was some thought that storing a u2 for cpref would be more >> memory efficient than storing Symbol* in the backtraces, but recent >> runs of Jetty show that this doesn't cause footprint increases or >> performance decreases. Storing the Symbol* for the method name >> guarantees it is there when creating the StackTraceElement, whereas >> cpref relies on constant pool merging for redefinition and is >> dependent on being an index in the right constant pool, which has >> been a source of bugs in the past. >> >> dev-submit performance testing was run with no regressions. Also, all >> hotspot jtreg tests were run. >> >> This is a change for JDK10 whenever that opens. >> >> open webrev at http://cr.openjdk.java.net/~coleenp/8140685.01/webrev >> bug link https://bugs.openjdk.java.net/browse/JDK-8140685 >> >> Thanks, >> Coleen > From coleen.phillimore at oracle.com Wed Jan 25 21:58:41 2017 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Wed, 25 Jan 2017 16:58:41 -0500 Subject: RFR (S) 8140685: Fix backtrace building to not rely on constant pool merging In-Reply-To: <6fc23c46-2ac9-ae2a-1ff1-85e8bed85ecb@oracle.com> References: <6fc23c46-2ac9-ae2a-1ff1-85e8bed85ecb@oracle.com> Message-ID: <34cca84f-01b1-a90d-0536-ae73fa8d833c@oracle.com> On 1/23/17 7:11 PM, David Holmes wrote: > Hi Coleen, > > On 24/01/2017 9:00 AM, Coleen Phillimore wrote: >> Summary: Store Symbol* for the name in the backtrace >> >> There was some thought that storing a u2 for cpref would be more memory >> efficient than storing Symbol* in the backtraces, but recent runs of >> Jetty show that this doesn't cause footprint increases or performance >> decreases. Storing the Symbol* for the method name guarantees it is >> there when creating the StackTraceElement, whereas cpref relies on >> constant pool merging for redefinition and is dependent on being an >> index in the right constant pool, which has been a source of bugs in the >> past. > > This all sounds reasonable. But I'm not very clear on the Symbol > ref-counting protocol, so can't really say if this may leak them or not. I tried to explain in the bug. > >> dev-submit performance testing was run with no regressions. Also, all >> hotspot jtreg tests were run. >> >> This is a change for JDK10 whenever that opens. >> >> open webrev at http://cr.openjdk.java.net/~coleenp/8140685.01/webrev >> bug link https://bugs.openjdk.java.net/browse/JDK-8140685 > > The bug refers to a method-id to Method* change, nothing about cpref > to Symbol*. Can you update the bug so that it reflects the actual > change please. Yes, sorry, I hadn't fixed the bug. I've changed the description now to be more accurate. Let me know if it makes sense to you or if there's some better rewording that I can do. Thanks, Coleen > > Thanks, > David > >> Thanks, >> Coleen From coleen.phillimore at oracle.com Wed Jan 25 22:01:48 2017 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Wed, 25 Jan 2017 17:01:48 -0500 Subject: RFR (S) 8140685: Fix backtrace building to not rely on constant pool merging In-Reply-To: <7C42364A-2813-4F67-8800-ECE332E0C7EE@oracle.com> References: <7C42364A-2813-4F67-8800-ECE332E0C7EE@oracle.com> Message-ID: <1170560c-9f77-d58a-f1b1-c5b88d7f2d5d@oracle.com> Kim, thank you for reviewing, and past almost endless discussions of this problem. On 1/23/17 9:35 PM, Kim Barrett wrote: >> On Jan 23, 2017, at 6:00 PM, Coleen Phillimore wrote: >> >> Summary: Store Symbol* for the name in the backtrace >> >> There was some thought that storing a u2 for cpref would be more memory efficient than storing Symbol* in the backtraces, but recent runs of Jetty show that this doesn't cause footprint increases or performance decreases. Storing the Symbol* for the method name guarantees it is there when creating the StackTraceElement, whereas cpref relies on constant pool merging for redefinition and is dependent on being an index in the right constant pool, which has been a source of bugs in the past. >> >> dev-submit performance testing was run with no regressions. Also, all hotspot jtreg tests were run. >> >> This is a change for JDK10 whenever that opens. >> >> open webrev at http://cr.openjdk.java.net/~coleenp/8140685.01/webrev >> bug link https://bugs.openjdk.java.net/browse/JDK-8140685 >> >> Thanks, >> Coleen > Looks good. Just a couple of minor nits. > > ------------------------------------------------------------------------------ > src/share/vm/classfile/javaClasses.cpp > 1631 assert(_methods->length() == _bcis->length() && > 1632 _methods->length() == _mirrors->length(), > > Pre-existing: Shouldn't the _names (formerly _cprefs) length also be > checked here? assert(_methods->length() == _bcis->length() && _methods->length() == _mirrors->length() && _mirrors->length() == _names->length(), "method and source information arrays should match"); Yes. > > ------------------------------------------------------------------------------ > src/share/vm/classfile/javaClasses.cpp > 1694 // Note:this doesn't leaks symbols because the mirror in the backtrace keeps the > > s/leaks/leak I corrected this also. Thanks! Coleen > ------------------------------------------------------------------------------ > From coleen.phillimore at oracle.com Wed Jan 25 22:02:41 2017 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Wed, 25 Jan 2017 17:02:41 -0500 Subject: RFR (S) 8140685: Fix backtrace building to not rely on constant pool merging In-Reply-To: <58876E1A.9030904@oracle.com> References: <58876E1A.9030904@oracle.com> Message-ID: On 1/24/17 10:09 AM, Lois Foltan wrote: > Looks good Coleen. Thank you! Coleen > Lois > > On 1/23/2017 6:00 PM, Coleen Phillimore wrote: >> Summary: Store Symbol* for the name in the backtrace >> >> There was some thought that storing a u2 for cpref would be more >> memory efficient than storing Symbol* in the backtraces, but recent >> runs of Jetty show that this doesn't cause footprint increases or >> performance decreases. Storing the Symbol* for the method name >> guarantees it is there when creating the StackTraceElement, whereas >> cpref relies on constant pool merging for redefinition and is >> dependent on being an index in the right constant pool, which has >> been a source of bugs in the past. >> >> dev-submit performance testing was run with no regressions. Also, all >> hotspot jtreg tests were run. >> >> This is a change for JDK10 whenever that opens. >> >> open webrev at http://cr.openjdk.java.net/~coleenp/8140685.01/webrev >> bug link https://bugs.openjdk.java.net/browse/JDK-8140685 >> >> Thanks, >> Coleen > From calvin.cheung at oracle.com Wed Jan 25 22:08:33 2017 From: calvin.cheung at oracle.com (Calvin Cheung) Date: Wed, 25 Jan 2017 14:08:33 -0800 Subject: RFR(XS): 8173163: searching for a versioned entry in a multi-release jar in hotspot is inconsistent with java code In-Reply-To: <91133121-7AB3-4F62-AF15-AB40206F3D95@oracle.com> References: <5889052D.5060201@oracle.com> <91133121-7AB3-4F62-AF15-AB40206F3D95@oracle.com> Message-ID: <588921E1.4010102@oracle.com> Hi Jiangli, Thanks for taking a look. On 1/25/17, 1:10 PM, Jiangli Zhou wrote: > Hi Calvin, > > With the change when 'version> cur_ver', the JVM prints a warning saying "the requested JDK version is not supported in multiple version jars" but uses the highest versioned entry instead of the base entry. The warning should be removed or be made more clear to also reflect the behavior change. As you've mentioned, before this change, the base entry will be used if version > cur_ver and the warning was there. I prefer not to change the warning at this point. thanks, Calvin > > Thanks, > Jiangli > >> On Jan 25, 2017, at 12:06 PM, Calvin Cheung wrote: >> >> Please review this simple bug fix for JDK 9. >> >> bug: https://bugs.openjdk.java.net/browse/JDK-8173163 >> >> webrev: http://cr.openjdk.java.net/~ccheung/8173163/webrev.00/ >> >> thanks, >> Calvin From calvin.cheung at oracle.com Wed Jan 25 22:44:21 2017 From: calvin.cheung at oracle.com (Calvin Cheung) Date: Wed, 25 Jan 2017 14:44:21 -0800 Subject: RFR(XS): 8173163: searching for a versioned entry in a multi-release jar in hotspot is inconsistent with java code In-Reply-To: <1f42229c-9f3a-81eb-5e9e-0686e613e22e@oracle.com> References: <5889052D.5060201@oracle.com> <1f42229c-9f3a-81eb-5e9e-0686e613e22e@oracle.com> Message-ID: <58892A45.6030708@oracle.com> Thanks Serguei for your review. Based on your and Ioi's review comment, the change looks like the following: + // If the specified version is lower than the base version, the base + // entry will be used; if the version is higher than the current + // jdk version, the highest versioned entry will be used. + if (version < base_version) { is_multi_ver = false; + } thanks, Calvin On 1/25/17, 12:51 PM, serguei.spitsyn at oracle.com wrote: > Hi Calvin, > > > Looks good. > Nit: The comments in this file normally start from a capital letter. > > Thanks, > Serguei > > > On 1/25/17 12:06, Calvin Cheung wrote: >> Please review this simple bug fix for JDK 9. >> >> bug: https://bugs.openjdk.java.net/browse/JDK-8173163 >> >> webrev: http://cr.openjdk.java.net/~ccheung/8173163/webrev.00/ >> >> thanks, >> Calvin > From serguei.spitsyn at oracle.com Wed Jan 25 22:50:24 2017 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Wed, 25 Jan 2017 14:50:24 -0800 Subject: RFR(XS): 8173163: searching for a versioned entry in a multi-release jar in hotspot is inconsistent with java code In-Reply-To: <58892A45.6030708@oracle.com> References: <5889052D.5060201@oracle.com> <1f42229c-9f3a-81eb-5e9e-0686e613e22e@oracle.com> <58892A45.6030708@oracle.com> Message-ID: <9b9ec911-e103-373a-40aa-13e51855985b@oracle.com> It is good. Thank you for the update, Serguei On 1/25/17 14:44, Calvin Cheung wrote: > Thanks Serguei for your review. > > Based on your and Ioi's review comment, the change looks like the > following: > + // If the specified version is lower than the base version, > the base > + // entry will be used; if the version is higher than the > current > + // jdk version, the highest versioned entry will be used. > + if (version < base_version) { > is_multi_ver = false; > + } > > thanks, > Calvin > > On 1/25/17, 12:51 PM, serguei.spitsyn at oracle.com wrote: >> Hi Calvin, >> >> >> Looks good. >> Nit: The comments in this file normally start from a capital letter. >> >> Thanks, >> Serguei >> >> >> On 1/25/17 12:06, Calvin Cheung wrote: >>> Please review this simple bug fix for JDK 9. >>> >>> bug: https://bugs.openjdk.java.net/browse/JDK-8173163 >>> >>> webrev: http://cr.openjdk.java.net/~ccheung/8173163/webrev.00/ >>> >>> thanks, >>> Calvin >> From david.buck at oracle.com Thu Jan 26 14:04:39 2017 From: david.buck at oracle.com (David Buck) Date: Thu, 26 Jan 2017 23:04:39 +0900 Subject: RFR: [8u] 8087342: crash in klassItable_initialize_itable_for_interface Message-ID: <588A01F7.5020801@oracle.com> Hi! Please review this backport of 8087342 to 8u-dev. bug report: https://bugs.openjdk.java.net/browse/JDK-8087342 JDK 9 push: http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/5e09f372116b JDK 9 review thread (2 parts): http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2015-July/015436.html http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2015-August/015602.html JDK 8u webrev: http://cr.openjdk.java.net/~dbuck/8087342_01/ The backport was relatively straightforward. The only minor complication was the refactoring done as part of 8067480 [0]. 8067480 itself did not need to be backported from 9 to 8u because that issue did not apply to 8u by the time it was fixed in 9. But the refactoring done for 8067480 seemed to be the only reasonable way to backport 8087342 and keep the code readable. (If I had just added yet another bool flag to each of these methods, it would have been *way* to easy to get parameters confused.) So the best way to look at this changeset is as a backport of both 8087342 and (most of) 8067480. [0] https://bugs.openjdk.java.net/browse/JDK-8067480 http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/d656b4c91d51 http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2015-January/013717.html Cheers, -Buck From david.holmes at oracle.com Fri Jan 27 00:22:56 2017 From: david.holmes at oracle.com (David Holmes) Date: Fri, 27 Jan 2017 10:22:56 +1000 Subject: RFR: [8u] 8087342: crash in klassItable_initialize_itable_for_interface In-Reply-To: <588A01F7.5020801@oracle.com> References: <588A01F7.5020801@oracle.com> Message-ID: Hi David, We don't allow private interface methods in Java 8 at the language level. So I'm not clear what should be expected here. ?? Thanks, David H. On 27/01/2017 12:04 AM, David Buck wrote: > Hi! > > Please review this backport of 8087342 to 8u-dev. > > bug report: https://bugs.openjdk.java.net/browse/JDK-8087342 > > JDK 9 push: http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/5e09f372116b > > JDK 9 review thread (2 parts): > > http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2015-July/015436.html > > > http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2015-August/015602.html > > > JDK 8u webrev: http://cr.openjdk.java.net/~dbuck/8087342_01/ > > The backport was relatively straightforward. The only minor complication > was the refactoring done as part of 8067480 [0]. 8067480 itself did not > need to be backported from 9 to 8u because that issue did not apply to > 8u by the time it was fixed in 9. But the refactoring done for 8067480 > seemed to be the only reasonable way to backport 8087342 and keep the > code readable. (If I had just added yet another bool flag to each of > these methods, it would have been *way* to easy to get parameters > confused.) > > So the best way to look at this changeset is as a backport of both > 8087342 and (most of) 8067480. > > [0] > https://bugs.openjdk.java.net/browse/JDK-8067480 > http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/d656b4c91d51 > http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2015-January/013717.html > > > Cheers, > -Buck From david.holmes at oracle.com Fri Jan 27 05:52:04 2017 From: david.holmes at oracle.com (David Holmes) Date: Fri, 27 Jan 2017 15:52:04 +1000 Subject: RFR (S) 8140685: Fix backtrace building to not rely on constant pool merging In-Reply-To: <34cca84f-01b1-a90d-0536-ae73fa8d833c@oracle.com> References: <6fc23c46-2ac9-ae2a-1ff1-85e8bed85ecb@oracle.com> <34cca84f-01b1-a90d-0536-ae73fa8d833c@oracle.com> Message-ID: <55f3bbc6-eafa-d744-222e-46f4191f1f26@oracle.com> Bug update looks good! Thanks, David On 26/01/2017 7:58 AM, Coleen Phillimore wrote: > > > On 1/23/17 7:11 PM, David Holmes wrote: >> Hi Coleen, >> >> On 24/01/2017 9:00 AM, Coleen Phillimore wrote: >>> Summary: Store Symbol* for the name in the backtrace >>> >>> There was some thought that storing a u2 for cpref would be more memory >>> efficient than storing Symbol* in the backtraces, but recent runs of >>> Jetty show that this doesn't cause footprint increases or performance >>> decreases. Storing the Symbol* for the method name guarantees it is >>> there when creating the StackTraceElement, whereas cpref relies on >>> constant pool merging for redefinition and is dependent on being an >>> index in the right constant pool, which has been a source of bugs in the >>> past. >> >> This all sounds reasonable. But I'm not very clear on the Symbol >> ref-counting protocol, so can't really say if this may leak them or not. > > I tried to explain in the bug. >> >>> dev-submit performance testing was run with no regressions. Also, all >>> hotspot jtreg tests were run. >>> >>> This is a change for JDK10 whenever that opens. >>> >>> open webrev at http://cr.openjdk.java.net/~coleenp/8140685.01/webrev >>> bug link https://bugs.openjdk.java.net/browse/JDK-8140685 >> >> The bug refers to a method-id to Method* change, nothing about cpref >> to Symbol*. Can you update the bug so that it reflects the actual >> change please. > > Yes, sorry, I hadn't fixed the bug. I've changed the description now to > be more accurate. Let me know if it makes sense to you or if there's > some better rewording that I can do. > > Thanks, > Coleen > >> >> Thanks, >> David >> >>> Thanks, >>> Coleen > From karen.kinnear at oracle.com Fri Jan 27 15:56:24 2017 From: karen.kinnear at oracle.com (Karen Kinnear) Date: Fri, 27 Jan 2017 10:56:24 -0500 Subject: RFR: [8u] 8087342: crash in klassItable_initialize_itable_for_interface In-Reply-To: References: <588A01F7.5020801@oracle.com> Message-ID: <36B4C3F3-860D-41F0-BE55-0B1CC6D40437@oracle.com> David Holmes, Java 8 allowed private interface methods in generated code. Specifically the lambda metafactory used them, so from a JVM perspective, they need to be supported. David Buck, Many thanks for back porting. It was a good idea to back port the 8067480 changes to keep the arguments consistent - the complexity was getting too messy. The code changes look great! Questions/Comments: 1) copyright in TestStaticAndInstance.java would now be 2015,2017 2) You said you back ported most of 8087342 - what part did you not back port? 3) testing - In addition to the specific test here, did you run the defmeth tests and the SelectionResolution tests? thanks, Karen > On Jan 26, 2017, at 7:22 PM, David Holmes wrote: > > Hi David, > > We don't allow private interface methods in Java 8 at the language level. So I'm not clear what should be expected here. ?? > > Thanks, > David H. > > On 27/01/2017 12:04 AM, David Buck wrote: >> Hi! >> >> Please review this backport of 8087342 to 8u-dev. >> >> bug report: https://bugs.openjdk.java.net/browse/JDK-8087342 >> >> JDK 9 push: http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/5e09f372116b >> >> JDK 9 review thread (2 parts): >> >> http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2015-July/015436.html >> >> >> http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2015-August/015602.html >> >> >> JDK 8u webrev: http://cr.openjdk.java.net/~dbuck/8087342_01/ >> >> The backport was relatively straightforward. The only minor complication >> was the refactoring done as part of 8067480 [0]. 8067480 itself did not >> need to be backported from 9 to 8u because that issue did not apply to >> 8u by the time it was fixed in 9. But the refactoring done for 8067480 >> seemed to be the only reasonable way to backport 8087342 and keep the >> code readable. (If I had just added yet another bool flag to each of >> these methods, it would have been *way* to easy to get parameters >> confused.) >> >> So the best way to look at this changeset is as a backport of both >> 8087342 and (most of) 8067480. >> >> [0] >> https://bugs.openjdk.java.net/browse/JDK-8067480 >> http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/d656b4c91d51 >> http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2015-January/013717.html >> >> >> Cheers, >> -Buck From coleen.phillimore at oracle.com Fri Jan 27 19:18:23 2017 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Fri, 27 Jan 2017 14:18:23 -0500 Subject: RFR (S) 8140685: Fix backtrace building to not rely on constant pool merging In-Reply-To: <55f3bbc6-eafa-d744-222e-46f4191f1f26@oracle.com> References: <6fc23c46-2ac9-ae2a-1ff1-85e8bed85ecb@oracle.com> <34cca84f-01b1-a90d-0536-ae73fa8d833c@oracle.com> <55f3bbc6-eafa-d744-222e-46f4191f1f26@oracle.com> Message-ID: <8b0291e9-e913-2a5f-15fd-60fb05fc6790@oracle.com> On 1/27/17 12:52 AM, David Holmes wrote: > Bug update looks good! Thank you, David. Coleen > > Thanks, > David > > On 26/01/2017 7:58 AM, Coleen Phillimore wrote: >> >> >> On 1/23/17 7:11 PM, David Holmes wrote: >>> Hi Coleen, >>> >>> On 24/01/2017 9:00 AM, Coleen Phillimore wrote: >>>> Summary: Store Symbol* for the name in the backtrace >>>> >>>> There was some thought that storing a u2 for cpref would be more >>>> memory >>>> efficient than storing Symbol* in the backtraces, but recent runs of >>>> Jetty show that this doesn't cause footprint increases or performance >>>> decreases. Storing the Symbol* for the method name guarantees it is >>>> there when creating the StackTraceElement, whereas cpref relies on >>>> constant pool merging for redefinition and is dependent on being an >>>> index in the right constant pool, which has been a source of bugs >>>> in the >>>> past. >>> >>> This all sounds reasonable. But I'm not very clear on the Symbol >>> ref-counting protocol, so can't really say if this may leak them or >>> not. >> >> I tried to explain in the bug. >>> >>>> dev-submit performance testing was run with no regressions. Also, all >>>> hotspot jtreg tests were run. >>>> >>>> This is a change for JDK10 whenever that opens. >>>> >>>> open webrev at http://cr.openjdk.java.net/~coleenp/8140685.01/webrev >>>> bug link https://bugs.openjdk.java.net/browse/JDK-8140685 >>> >>> The bug refers to a method-id to Method* change, nothing about cpref >>> to Symbol*. Can you update the bug so that it reflects the actual >>> change please. >> >> Yes, sorry, I hadn't fixed the bug. I've changed the description now to >> be more accurate. Let me know if it makes sense to you or if there's >> some better rewording that I can do. >> >> Thanks, >> Coleen >> >>> >>> Thanks, >>> David >>> >>>> Thanks, >>>> Coleen >> From mandy.chung at oracle.com Mon Jan 30 23:42:14 2017 From: mandy.chung at oracle.com (Mandy Chung) Date: Mon, 30 Jan 2017 15:42:14 -0800 Subject: Review Request: JDK-8173608: Separate JDK management agent from java.management module Message-ID: <1B41EF04-9D05-4B96-BB00-B6B14F0F69C0@oracle.com> java.management is the module for JMX and JMX remote API and java.lang.management. JDK management agent provides the JDK-specific out-of-the-box monitoring and management support and it?s cleaner for it to live in its own module. It is proposed to move it to a new module named `jdk.management.agent`. This change involves: 1) renaming of sun.management.Agent along with 3 other classes in sun.management package to jdk.internal.agent package 2) move sun.management.resources to jdk.internal.agent.resources 3) move sun.management.jmxremote and sun.management.jdp packages to jdk.management.agent module 4) move the configuration files under conf/management 5) sun/management/jmxremote/ConnectorBootstrap.java is updated to replace the use of the ClassLogger API with System.Logger. 6) change hotspot VM to add `jdk.management.agent` when -Dcom.sun.management.* system property is set as well as the Agent class rename Daniel is working on JDK-8173607 [1] that conflicts with this patch and require merges/coordination. We propose to integrate these changes to jdk9/dev unless there is any objection concerning that this trivial hotspot change might cause any issue. I have submitted a RBT on hotspot_runtime and hotspot_serviceability in addition to PIT test runs. thanks Mandy [1] https://bugs.openjdk.java.net/browse/JDK-8173607 From mandy.chung at oracle.com Mon Jan 30 23:48:18 2017 From: mandy.chung at oracle.com (Mandy Chung) Date: Mon, 30 Jan 2017 15:48:18 -0800 Subject: Review Request: JDK-8173608: Separate JDK management agent from java.management module In-Reply-To: <1B41EF04-9D05-4B96-BB00-B6B14F0F69C0@oracle.com> References: <1B41EF04-9D05-4B96-BB00-B6B14F0F69C0@oracle.com> Message-ID: <508D6511-7443-4F5D-93D2-79D535C3838C@oracle.com> Webrev at: http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8173608/webrev.00/index.html Mandy > On Jan 30, 2017, at 3:42 PM, Mandy Chung wrote: > > java.management is the module for JMX and JMX remote API and > java.lang.management. JDK management agent provides the JDK-specific > out-of-the-box monitoring and management support and it?s cleaner > for it to live in its own module. It is proposed to move it > to a new module named `jdk.management.agent`. > > This change involves: > 1) renaming of sun.management.Agent along with 3 other classes > in sun.management package to jdk.internal.agent package > > 2) move sun.management.resources to jdk.internal.agent.resources > > 3) move sun.management.jmxremote and sun.management.jdp packages > to jdk.management.agent module > > 4) move the configuration files under conf/management > > 5) sun/management/jmxremote/ConnectorBootstrap.java is updated > to replace the use of the ClassLogger API with System.Logger. > > 6) change hotspot VM to add `jdk.management.agent` when > -Dcom.sun.management.* system property is set as well as > the Agent class rename > > Daniel is working on JDK-8173607 [1] that conflicts with this > patch and require merges/coordination. > > We propose to integrate these changes to jdk9/dev unless > there is any objection concerning that this trivial hotspot change > might cause any issue. I have submitted a RBT on hotspot_runtime > and hotspot_serviceability in addition to PIT test runs. > > thanks > Mandy > [1] https://bugs.openjdk.java.net/browse/JDK-8173607 From david.holmes at oracle.com Tue Jan 31 07:00:38 2017 From: david.holmes at oracle.com (David Holmes) Date: Tue, 31 Jan 2017 17:00:38 +1000 Subject: Review Request: JDK-8173608: Separate JDK management agent from java.management module In-Reply-To: <508D6511-7443-4F5D-93D2-79D535C3838C@oracle.com> References: <1B41EF04-9D05-4B96-BB00-B6B14F0F69C0@oracle.com> <508D6511-7443-4F5D-93D2-79D535C3838C@oracle.com> Message-ID: <90abbd53-411e-645c-1c96-700bde19fd56@oracle.com> Hi Mandy, On 31/01/2017 9:48 AM, Mandy Chung wrote: > Webrev at: > http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8173608/webrev.00/index.html This all seems okay. But we have quite a few hotspot tests that include: @modules java.management/sun.management that would seem to need updating as well. Thanks, David ----- > Mandy > >> On Jan 30, 2017, at 3:42 PM, Mandy Chung wrote: >> >> java.management is the module for JMX and JMX remote API and >> java.lang.management. JDK management agent provides the JDK-specific >> out-of-the-box monitoring and management support and it?s cleaner >> for it to live in its own module. It is proposed to move it >> to a new module named `jdk.management.agent`. >> >> This change involves: >> 1) renaming of sun.management.Agent along with 3 other classes >> in sun.management package to jdk.internal.agent package >> >> 2) move sun.management.resources to jdk.internal.agent.resources >> >> 3) move sun.management.jmxremote and sun.management.jdp packages >> to jdk.management.agent module >> >> 4) move the configuration files under conf/management >> >> 5) sun/management/jmxremote/ConnectorBootstrap.java is updated >> to replace the use of the ClassLogger API with System.Logger. >> >> 6) change hotspot VM to add `jdk.management.agent` when >> -Dcom.sun.management.* system property is set as well as >> the Agent class rename >> >> Daniel is working on JDK-8173607 [1] that conflicts with this >> patch and require merges/coordination. >> >> We propose to integrate these changes to jdk9/dev unless >> there is any objection concerning that this trivial hotspot change >> might cause any issue. I have submitted a RBT on hotspot_runtime >> and hotspot_serviceability in addition to PIT test runs. >> >> thanks >> Mandy >> [1] https://bugs.openjdk.java.net/browse/JDK-8173607 > From erik.joelsson at oracle.com Tue Jan 31 08:20:00 2017 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Tue, 31 Jan 2017 09:20:00 +0100 Subject: Review Request: JDK-8173608: Separate JDK management agent from java.management module In-Reply-To: <508D6511-7443-4F5D-93D2-79D535C3838C@oracle.com> References: <1B41EF04-9D05-4B96-BB00-B6B14F0F69C0@oracle.com> <508D6511-7443-4F5D-93D2-79D535C3838C@oracle.com> Message-ID: <05c34397-9ba6-1cc5-048d-96d29f3af62e@oracle.com> Hello Mandy, In Lib-jdk.management.agent.gmk: OPENJDK_TARGET_OS and OPENJDK_TARGET_OS_TYPE are both "windows" on Windows platforms, so no need to treat Windows differently when defining the src dirs. The -DPSAPI_VERSION=1 seems to be copied from Lib-jdk.management.gmk and/or Lib-jdk.attach.gmk, but was not applied to the library from which the native src for this new lib was copied from. I just wonder if this is actually needed for this new library? Please remove the "LANG := C" parameter, it no longer has a meaning but it keeps reappearing due to copy pasting of old make code. Are all the libraries added to LIBS still needed for this breakout lib? And are all of them still needed for libmanagement.so from which this was split out? /Erik On 2017-01-31 00:48, Mandy Chung wrote: > Webrev at: > http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8173608/webrev.00/index.html > > Mandy > >> On Jan 30, 2017, at 3:42 PM, Mandy Chung wrote: >> >> java.management is the module for JMX and JMX remote API and >> java.lang.management. JDK management agent provides the JDK-specific >> out-of-the-box monitoring and management support and it?s cleaner >> for it to live in its own module. It is proposed to move it >> to a new module named `jdk.management.agent`. >> >> This change involves: >> 1) renaming of sun.management.Agent along with 3 other classes >> in sun.management package to jdk.internal.agent package >> >> 2) move sun.management.resources to jdk.internal.agent.resources >> >> 3) move sun.management.jmxremote and sun.management.jdp packages >> to jdk.management.agent module >> >> 4) move the configuration files under conf/management >> >> 5) sun/management/jmxremote/ConnectorBootstrap.java is updated >> to replace the use of the ClassLogger API with System.Logger. >> >> 6) change hotspot VM to add `jdk.management.agent` when >> -Dcom.sun.management.* system property is set as well as >> the Agent class rename >> >> Daniel is working on JDK-8173607 [1] that conflicts with this >> patch and require merges/coordination. >> >> We propose to integrate these changes to jdk9/dev unless >> there is any objection concerning that this trivial hotspot change >> might cause any issue. I have submitted a RBT on hotspot_runtime >> and hotspot_serviceability in addition to PIT test runs. >> >> thanks >> Mandy >> [1] https://bugs.openjdk.java.net/browse/JDK-8173607 From david.buck at oracle.com Tue Jan 31 12:19:11 2017 From: david.buck at oracle.com (David Buck) Date: Tue, 31 Jan 2017 21:19:11 +0900 Subject: RFR: [8u] 8087342: crash in klassItable_initialize_itable_for_interface In-Reply-To: <36B4C3F3-860D-41F0-BE55-0B1CC6D40437@oracle.com> References: <588A01F7.5020801@oracle.com> <36B4C3F3-860D-41F0-BE55-0B1CC6D40437@oracle.com> Message-ID: <589080BF.3020204@oracle.com> Hi David and Karen, Thank you both for looking at my backport! > 1) copyright in TestStaticAndInstance.java would now be 2015,2017 Fixed. Thank you for the catch! > 2) You said you back ported most of 8087342 - what part did you not back port? I assume you meant to ask about 8067480, I backported *all* of 8087342. For 8067480, the change in behavior (the actual fix) was already backported to 8u as part of 8064524 (a security fix), so the "functional" part of 8067480 was already done in 8u. So in a sense, in this backport, from 8067480 I only brought back the refactoring (in addition to 8087342 of course). Perhaps I could have chosen my wording better. The point is that once this change is pushed to 8u-dev, both 8067480 *and* 8087342 should be fixed; I was very careful not to unfix the work done in 8064524. > 3) testing - In addition to the specific test here, did you run the defmeth tests and the SelectionResolution tests? Thank you for helping me (off line) to run these tests! All of the SelectionResolution tests run and pass. As for the defmeth tests, I checked out the last revision of vmtestbase before JDK 9 build tags started being added (caf1bcbf8df9) and used that for testing. With this revision, a number of test cases fail OOTB without my change (162 out of 696). I tried several OracleJDK update releases (8u25 and 8u121) and they too also failed the exact same test cases. So I assume that the these are issues with the test cases themselves and not an indication of problems with the JDK/JVM being tested. Of course, with my backport only the same set of failures is seen; there is no sign of any regression as a result of the backport. Cheers, -Buck On 2017/01/28 0:56, Karen Kinnear wrote: > David Holmes, > > Java 8 allowed private interface methods in generated code. Specifically the lambda metafactory used > them, so from a JVM perspective, they need to be supported. > > David Buck, > > Many thanks for back porting. It was a good idea to back port the 8067480 changes to keep > the arguments consistent - the complexity was getting too messy. > > The code changes look great! > > Questions/Comments: > > > 1) copyright in TestStaticAndInstance.java would now be 2015,2017 > 2) You said you back ported most of 8087342 - what part did you not back port? > 3) testing - In addition to the specific test here, did you run the defmeth tests and the SelectionResolution tests? > > thanks, > Karen > > > >> On Jan 26, 2017, at 7:22 PM, David Holmes wrote: >> >> Hi David, >> >> We don't allow private interface methods in Java 8 at the language level. So I'm not clear what should be expected here. ?? >> >> Thanks, >> David H. >> >> On 27/01/2017 12:04 AM, David Buck wrote: >>> Hi! >>> >>> Please review this backport of 8087342 to 8u-dev. >>> >>> bug report: https://bugs.openjdk.java.net/browse/JDK-8087342 >>> >>> JDK 9 push: http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/5e09f372116b >>> >>> JDK 9 review thread (2 parts): >>> >>> http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2015-July/015436.html >>> >>> >>> http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2015-August/015602.html >>> >>> >>> JDK 8u webrev: http://cr.openjdk.java.net/~dbuck/8087342_01/ >>> >>> The backport was relatively straightforward. The only minor complication >>> was the refactoring done as part of 8067480 [0]. 8067480 itself did not >>> need to be backported from 9 to 8u because that issue did not apply to >>> 8u by the time it was fixed in 9. But the refactoring done for 8067480 >>> seemed to be the only reasonable way to backport 8087342 and keep the >>> code readable. (If I had just added yet another bool flag to each of >>> these methods, it would have been *way* to easy to get parameters >>> confused.) >>> >>> So the best way to look at this changeset is as a backport of both >>> 8087342 and (most of) 8067480. >>> >>> [0] >>> https://bugs.openjdk.java.net/browse/JDK-8067480 >>> http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/d656b4c91d51 >>> http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2015-January/013717.html >>> >>> >>> Cheers, >>> -Buck > From mandy.chung at oracle.com Tue Jan 31 14:57:40 2017 From: mandy.chung at oracle.com (Mandy Chung) Date: Tue, 31 Jan 2017 06:57:40 -0800 Subject: Review Request: JDK-8173608: Separate JDK management agent from java.management module In-Reply-To: <90abbd53-411e-645c-1c96-700bde19fd56@oracle.com> References: <1B41EF04-9D05-4B96-BB00-B6B14F0F69C0@oracle.com> <508D6511-7443-4F5D-93D2-79D535C3838C@oracle.com> <90abbd53-411e-645c-1c96-700bde19fd56@oracle.com> Message-ID: <0769A989-4EDE-4D8E-B3C5-9AE89EFD8529@oracle.com> > On Jan 30, 2017, at 11:00 PM, David Holmes wrote: > > Hi Mandy, > > On 31/01/2017 9:48 AM, Mandy Chung wrote: >> Webrev at: >> http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8173608/webrev.00/index.html > > This all seems okay. > Thanks for the review. > But we have quite a few hotspot tests that include: > > @modules java.management/sun.management > Only 4 classes in the java.management/sun.management are moved to jdk.management.agent/jdk.internal.agent. From my grep on hotspot tests, no test uses those renamed classes. Mandy > that would seem to need updating as well. > > Thanks, > David > ----- > >> Mandy >> >>> On Jan 30, 2017, at 3:42 PM, Mandy Chung wrote: >>> >>> java.management is the module for JMX and JMX remote API and >>> java.lang.management. JDK management agent provides the JDK-specific >>> out-of-the-box monitoring and management support and it?s cleaner >>> for it to live in its own module. It is proposed to move it >>> to a new module named `jdk.management.agent`. >>> >>> This change involves: >>> 1) renaming of sun.management.Agent along with 3 other classes >>> in sun.management package to jdk.internal.agent package >>> >>> 2) move sun.management.resources to jdk.internal.agent.resources >>> >>> 3) move sun.management.jmxremote and sun.management.jdp packages >>> to jdk.management.agent module >>> >>> 4) move the configuration files under conf/management >>> >>> 5) sun/management/jmxremote/ConnectorBootstrap.java is updated >>> to replace the use of the ClassLogger API with System.Logger. >>> >>> 6) change hotspot VM to add `jdk.management.agent` when >>> -Dcom.sun.management.* system property is set as well as >>> the Agent class rename >>> >>> Daniel is working on JDK-8173607 [1] that conflicts with this >>> patch and require merges/coordination. >>> >>> We propose to integrate these changes to jdk9/dev unless >>> there is any objection concerning that this trivial hotspot change >>> might cause any issue. I have submitted a RBT on hotspot_runtime >>> and hotspot_serviceability in addition to PIT test runs. >>> >>> thanks >>> Mandy >>> [1] https://bugs.openjdk.java.net/browse/JDK-8173607 >> From daniel.fuchs at oracle.com Tue Jan 31 15:35:30 2017 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Tue, 31 Jan 2017 15:35:30 +0000 Subject: Review Request: JDK-8173608: Separate JDK management agent from java.management module In-Reply-To: <508D6511-7443-4F5D-93D2-79D535C3838C@oracle.com> References: <1B41EF04-9D05-4B96-BB00-B6B14F0F69C0@oracle.com> <508D6511-7443-4F5D-93D2-79D535C3838C@oracle.com> Message-ID: <3e8ce8e6-2b0d-8791-9295-c633affef22a@oracle.com> Hi Mandy, Looks good to me in general. Suggestion: FileLoginModule.java 112 private static final String PASSWORD_FILE_NAME = "jmxremote.password"; Maybe the constant could be public, then it could be referred to by ConnectorBootstrap? I see that com.sun.jmx.remote.internal is already being exported to jdk.management.agent. FileSystem.java: I wonder if this functionality should have remained in java.management. It doesn't have any type to any specific protocol - and it seems to be something that anyone using the FileLoginModule above might also need. ConnectorBootstrap.java: I would normally discourage creating helper methods (such as config()) in a class that doesn't implement System.Logger, as that will make the 'config' method appear as the source of the log message (rather than the method that calls config()). In this specific case I don't think it matters much though. It's probably better to keep it like this so as not distract reviewers from the meaningful changes, and we can clean that up any time later in a separate changeset (and possibly not before 10). best regards, -- daniel On 30/01/17 23:48, Mandy Chung wrote: > Webrev at: > http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8173608/webrev.00/index.html > > Mandy > >> On Jan 30, 2017, at 3:42 PM, Mandy Chung wrote: >> >> java.management is the module for JMX and JMX remote API and >> java.lang.management. JDK management agent provides the JDK-specific >> out-of-the-box monitoring and management support and it?s cleaner >> for it to live in its own module. It is proposed to move it >> to a new module named `jdk.management.agent`. >> >> This change involves: >> 1) renaming of sun.management.Agent along with 3 other classes >> in sun.management package to jdk.internal.agent package >> >> 2) move sun.management.resources to jdk.internal.agent.resources >> >> 3) move sun.management.jmxremote and sun.management.jdp packages >> to jdk.management.agent module >> >> 4) move the configuration files under conf/management >> >> 5) sun/management/jmxremote/ConnectorBootstrap.java is updated >> to replace the use of the ClassLogger API with System.Logger. >> >> 6) change hotspot VM to add `jdk.management.agent` when >> -Dcom.sun.management.* system property is set as well as >> the Agent class rename >> >> Daniel is working on JDK-8173607 [1] that conflicts with this >> patch and require merges/coordination. >> >> We propose to integrate these changes to jdk9/dev unless >> there is any objection concerning that this trivial hotspot change >> might cause any issue. I have submitted a RBT on hotspot_runtime >> and hotspot_serviceability in addition to PIT test runs. >> >> thanks >> Mandy >> [1] https://bugs.openjdk.java.net/browse/JDK-8173607 > From mandy.chung at oracle.com Tue Jan 31 16:04:27 2017 From: mandy.chung at oracle.com (Mandy Chung) Date: Tue, 31 Jan 2017 08:04:27 -0800 Subject: Review Request: JDK-8173608: Separate JDK management agent from java.management module In-Reply-To: <05c34397-9ba6-1cc5-048d-96d29f3af62e@oracle.com> References: <1B41EF04-9D05-4B96-BB00-B6B14F0F69C0@oracle.com> <508D6511-7443-4F5D-93D2-79D535C3838C@oracle.com> <05c34397-9ba6-1cc5-048d-96d29f3af62e@oracle.com> Message-ID: > On Jan 31, 2017, at 12:20 AM, Erik Joelsson wrote: > > Hello Mandy, > > In Lib-jdk.management.agent.gmk: > > OPENJDK_TARGET_OS and OPENJDK_TARGET_OS_TYPE are both "windows" on Windows platforms, so no need to treat Windows differently when defining the src dirs. > Good to know. Thanks. > The -DPSAPI_VERSION=1 seems to be copied from Lib-jdk.management.gmk and/or Lib-jdk.attach.gmk, but was not applied to the library from which the native src for this new lib was copied from. I just wonder if this is actually needed for this new library? I was also wondering it and now track it down. jdk.management.agent doesn?t use PS api. I will take it out. > > Please remove the "LANG := C" parameter, it no longer has a meaning but it keeps reappearing due to copy pasting of old make code. > > Are all the libraries added to LIBS still needed for this breakout lib? And are all of them still needed for libmanagement.so from which this was split out? > Good catch. I updated Lib-jdk.management.agent.gmk with: LIBS := $(JDKLIB_LIBS), \ LIBS_windows := $(WIN_JAVA_LIB) advapi32.lib, \ We should examine the native code in both java.management and jdk.management and I suspect the makefile would need cleanup. Are you okay to follow up the makefile as a separate issue? As the native code in jdk.management.agent, it can be converted to use NIO 2 and hope to get to it in a near future so that jdk.management.agent will have java code only. Mandy > /Erik > > > On 2017-01-31 00:48, Mandy Chung wrote: >> Webrev at: >> http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8173608/webrev.00/index.html >> >> Mandy >> >>> On Jan 30, 2017, at 3:42 PM, Mandy Chung wrote: >>> >>> java.management is the module for JMX and JMX remote API and >>> java.lang.management. JDK management agent provides the JDK-specific >>> out-of-the-box monitoring and management support and it?s cleaner >>> for it to live in its own module. It is proposed to move it >>> to a new module named `jdk.management.agent`. >>> >>> This change involves: >>> 1) renaming of sun.management.Agent along with 3 other classes >>> in sun.management package to jdk.internal.agent package >>> >>> 2) move sun.management.resources to jdk.internal.agent.resources >>> >>> 3) move sun.management.jmxremote and sun.management.jdp packages >>> to jdk.management.agent module >>> >>> 4) move the configuration files under conf/management >>> >>> 5) sun/management/jmxremote/ConnectorBootstrap.java is updated >>> to replace the use of the ClassLogger API with System.Logger. >>> >>> 6) change hotspot VM to add `jdk.management.agent` when >>> -Dcom.sun.management.* system property is set as well as >>> the Agent class rename >>> >>> Daniel is working on JDK-8173607 [1] that conflicts with this >>> patch and require merges/coordination. >>> >>> We propose to integrate these changes to jdk9/dev unless >>> there is any objection concerning that this trivial hotspot change >>> might cause any issue. I have submitted a RBT on hotspot_runtime >>> and hotspot_serviceability in addition to PIT test runs. >>> >>> thanks >>> Mandy >>> [1] https://bugs.openjdk.java.net/browse/JDK-8173607 > From kirill.zhaldybin at oracle.com Tue Jan 31 16:11:48 2017 From: kirill.zhaldybin at oracle.com (Kirill Zhaldybin) Date: Tue, 31 Jan 2017 19:11:48 +0300 Subject: RFR(S): 8171848: ObjectMonitor verify() and print() methods are empty In-Reply-To: <0f2829ac-a404-b256-41fc-0bd6d1b56656@oracle.com> References: <585A5B15.80607@oracle.com> <83afe5b7-abb5-a960-b92b-655284a54531@oracle.com> <0f2829ac-a404-b256-41fc-0bd6d1b56656@oracle.com> Message-ID: <41183671-ebd6-312d-34d4-bbde9e950f70@oracle.com> David, Here are a new WebRev: http://cr.openjdk.java.net/~kzhaldyb/webrevs/JDK-8171848/webrev.01/ I deleted ObjectSynchronizer::verify too since I failed to find any calls to it. Could you please let me know your opinion? Thank you. Regards, Kirill On 21.12.2016 16:24, Kirill Zhaldybin wrote: > David, > > Thank you for review! > > On 21.12.2016 15:46, David Holmes wrote: >> Hi Kirill, >> >> This cleanup is considered an enhancement and as such is no longer >> acceptable in JDK 9 - sorry. The CR has been re-targetted to JDK 10. >> >> The removal itself seems okay. I wonder whether >> ObjectSynchronizer::verify is itself ever called? > I did not find any calls to it but it was after I sent WebRev. > I will double-check and will send new one if we can just delete > ObjectSynchronizer::verify. > > Regards, Kirill >> >> David >> >> On 21/12/2016 8:36 PM, Kirill Zhaldybin wrote: >>> Dear all, >>> >>> Could you please review this fix for 8171848? >>> I deleted both methods from ObjectMonitor and the code which was not >>> doing anything from ObjectSynchronizer::verify(). >>> I did local and rbt testing to be sure that I found all calls to >>> deleted >>> methods. >>> >>> WebRev: >>> http://cr.openjdk.java.net/~kzhaldyb/webrevs/JDK-8171848/webrev.00/ >>> CR: https://bugs.openjdk.java.net/browse/JDK-8171848 >>> >>> Thank you. >>> >>> Regards, Kirill > From mandy.chung at oracle.com Tue Jan 31 16:22:25 2017 From: mandy.chung at oracle.com (Mandy Chung) Date: Tue, 31 Jan 2017 08:22:25 -0800 Subject: Review Request: JDK-8173608: Separate JDK management agent from java.management module In-Reply-To: <3e8ce8e6-2b0d-8791-9295-c633affef22a@oracle.com> References: <1B41EF04-9D05-4B96-BB00-B6B14F0F69C0@oracle.com> <508D6511-7443-4F5D-93D2-79D535C3838C@oracle.com> <3e8ce8e6-2b0d-8791-9295-c633affef22a@oracle.com> Message-ID: > On Jan 31, 2017, at 7:35 AM, Daniel Fuchs wrote: > > Hi Mandy, > > Looks good to me in general. > > Suggestion: FileLoginModule.java > > 112 private static final String PASSWORD_FILE_NAME = "jmxremote.password"; > > Maybe the constant could be public, then it could be > referred to by ConnectorBootstrap? > I see that com.sun.jmx.remote.internal is already > being exported to jdk.management.agent. > You meant com.sun.jmx.remote.security. I?d leave these 2 constants as is. Some future closer look to the relationship between FileLoginModule and ConnectorBootstrap may help to determine if future clean up should be done. > FileSystem.java: > > I wonder if this functionality should have remained in > java.management. It doesn't have any type to any specific > protocol - and it seems to be something that anyone using > the FileLoginModule above might also need. > That was added for the management agent and solely internal. We should look into converting the native code with NIO 2. No one should depend on it. > ConnectorBootstrap.java: > > I would normally discourage creating helper methods > (such as config()) in a class that doesn't implement > System.Logger, as that will make the 'config' method > appear as the source of the log message (rather than > the method that calls config()). > In this specific case I don't think it matters much > though. It's probably better to keep it like this so > as not distract reviewers from the meaningful changes, > and we can clean that up any time later in a separate > changeset (and possibly not before 10). > This is just an expedient way to remove the dependency to ClassLogger since the source method isn?t significant in this case. Thanks for the review. Mandy > > best regards, > > -- daniel > > On 30/01/17 23:48, Mandy Chung wrote: >> Webrev at: >> http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8173608/webrev.00/index.html >> >> Mandy >> >>> On Jan 30, 2017, at 3:42 PM, Mandy Chung wrote: >>> >>> java.management is the module for JMX and JMX remote API and >>> java.lang.management. JDK management agent provides the JDK-specific >>> out-of-the-box monitoring and management support and it?s cleaner >>> for it to live in its own module. It is proposed to move it >>> to a new module named `jdk.management.agent`. >>> >>> This change involves: >>> 1) renaming of sun.management.Agent along with 3 other classes >>> in sun.management package to jdk.internal.agent package >>> >>> 2) move sun.management.resources to jdk.internal.agent.resources >>> >>> 3) move sun.management.jmxremote and sun.management.jdp packages >>> to jdk.management.agent module >>> >>> 4) move the configuration files under conf/management >>> >>> 5) sun/management/jmxremote/ConnectorBootstrap.java is updated >>> to replace the use of the ClassLogger API with System.Logger. >>> >>> 6) change hotspot VM to add `jdk.management.agent` when >>> -Dcom.sun.management.* system property is set as well as >>> the Agent class rename >>> >>> Daniel is working on JDK-8173607 [1] that conflicts with this >>> patch and require merges/coordination. >>> >>> We propose to integrate these changes to jdk9/dev unless >>> there is any objection concerning that this trivial hotspot change >>> might cause any issue. I have submitted a RBT on hotspot_runtime >>> and hotspot_serviceability in addition to PIT test runs. >>> >>> thanks >>> Mandy >>> [1] https://bugs.openjdk.java.net/browse/JDK-8173607 >> > From erik.joelsson at oracle.com Tue Jan 31 16:44:41 2017 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Tue, 31 Jan 2017 17:44:41 +0100 Subject: Review Request: JDK-8173608: Separate JDK management agent from java.management module In-Reply-To: References: <1B41EF04-9D05-4B96-BB00-B6B14F0F69C0@oracle.com> <508D6511-7443-4F5D-93D2-79D535C3838C@oracle.com> <05c34397-9ba6-1cc5-048d-96d29f3af62e@oracle.com> Message-ID: <108c0107-83cc-e763-5f76-723aeae2b8ff@oracle.com> On 2017-01-31 17:04, Mandy Chung wrote: > >> On Jan 31, 2017, at 12:20 AM, Erik Joelsson wrote: >> >> Are all the libraries added to LIBS still needed for this breakout lib? And are all of them still needed for libmanagement.so from which this was split out? >> > Good catch. I updated Lib-jdk.management.agent.gmk with: > > LIBS := $(JDKLIB_LIBS), \ > LIBS_windows := $(WIN_JAVA_LIB) advapi32.lib, \ > > We should examine the native code in both java.management and jdk.management and I suspect the makefile would need cleanup. Are you okay to follow up the makefile as a separate issue? As the native code in jdk.management.agent, it can be converted to use NIO 2 and hope to get to it in a near future so that jdk.management.agent will have java code only. The adjustment proposed here is fine with me. /Erik From daniel.daugherty at oracle.com Tue Jan 31 17:18:41 2017 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Tue, 31 Jan 2017 10:18:41 -0700 Subject: RFR (XXXS) 8173693 disable post_class_unload() for non JavaThread initiators Message-ID: <58758a09-fc40-1c56-37bf-607ccc67bb0a@oracle.com> Greetings, I have a very small work around for a JVM/TI event posting bug: JDK-8173693 disable post_class_unload() for non JavaThread initiators https://bugs.openjdk.java.net/browse/JDK-8173693 This work around disables the JVM/TI post_class_unload() function when the thread requesting the event is not a JavaThread. See: JDK-8173658 JvmtiExport::post_class_unload() is broken for non-JavaThread initiators https://bugs.openjdk.java.net/browse/JDK-8173658 for the gory details of what can (and has) gone wrong. Fixing JDK-8173658 is non-trivial so this work around is proposed to avoid allowing a Class Unload event to crash the VM or silently corrupt the non JavaThread that tried to post the event. Webrev URL: http://cr.openjdk.java.net/~dcubed/8173693-webrev/0-jdk9-hs/ Testing: Oracle internal VM/NSK JVM/TI test suite JPRT testing (in progress) Thanks, in advance, for any comments, questions or suggestions. Dan From serguei.spitsyn at oracle.com Tue Jan 31 18:28:58 2017 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Tue, 31 Jan 2017 10:28:58 -0800 Subject: RFR (XXXS) 8173693 disable post_class_unload() for non JavaThread initiators In-Reply-To: <58758a09-fc40-1c56-37bf-607ccc67bb0a@oracle.com> References: <58758a09-fc40-1c56-37bf-607ccc67bb0a@oracle.com> Message-ID: <81982068-af77-6114-b047-ebf55d45757f@oracle.com> Dan, It looks good. Thank you for the work around. Thanks, Serguei On 1/31/17 09:18, Daniel D. Daugherty wrote: > Greetings, > > I have a very small work around for a JVM/TI event posting bug: > > JDK-8173693 disable post_class_unload() for non JavaThread initiators > https://bugs.openjdk.java.net/browse/JDK-8173693 > > This work around disables the JVM/TI post_class_unload() function > when the thread requesting the event is not a JavaThread. See: > > JDK-8173658 JvmtiExport::post_class_unload() is broken for > non-JavaThread initiators > https://bugs.openjdk.java.net/browse/JDK-8173658 > > for the gory details of what can (and has) gone wrong. > > Fixing JDK-8173658 is non-trivial so this work around is proposed > to avoid allowing a Class Unload event to crash the VM or silently > corrupt the non JavaThread that tried to post the event. > > Webrev URL: http://cr.openjdk.java.net/~dcubed/8173693-webrev/0-jdk9-hs/ > > Testing: Oracle internal VM/NSK JVM/TI test suite > JPRT testing (in progress) > > > Thanks, in advance, for any comments, questions or suggestions. > > Dan From daniel.daugherty at oracle.com Tue Jan 31 18:32:55 2017 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Tue, 31 Jan 2017 11:32:55 -0700 Subject: RFR (XXXS) 8173693 disable post_class_unload() for non JavaThread initiators In-Reply-To: <81982068-af77-6114-b047-ebf55d45757f@oracle.com> References: <58758a09-fc40-1c56-37bf-607ccc67bb0a@oracle.com> <81982068-af77-6114-b047-ebf55d45757f@oracle.com> Message-ID: <6c6a1348-5593-f733-a687-47bd9e953ead@oracle.com> Serguei, Thanks for the fast review! Dan On 1/31/17 11:28 AM, serguei.spitsyn at oracle.com wrote: > Dan, > > It looks good. > Thank you for the work around. > > Thanks, > Serguei > > > On 1/31/17 09:18, Daniel D. Daugherty wrote: >> Greetings, >> >> I have a very small work around for a JVM/TI event posting bug: >> >> JDK-8173693 disable post_class_unload() for non JavaThread >> initiators >> https://bugs.openjdk.java.net/browse/JDK-8173693 >> >> This work around disables the JVM/TI post_class_unload() function >> when the thread requesting the event is not a JavaThread. See: >> >> JDK-8173658 JvmtiExport::post_class_unload() is broken for >> non-JavaThread initiators >> https://bugs.openjdk.java.net/browse/JDK-8173658 >> >> for the gory details of what can (and has) gone wrong. >> >> Fixing JDK-8173658 is non-trivial so this work around is proposed >> to avoid allowing a Class Unload event to crash the VM or silently >> corrupt the non JavaThread that tried to post the event. >> >> Webrev URL: http://cr.openjdk.java.net/~dcubed/8173693-webrev/0-jdk9-hs/ >> >> Testing: Oracle internal VM/NSK JVM/TI test suite >> JPRT testing (in progress) >> >> >> Thanks, in advance, for any comments, questions or suggestions. >> >> Dan > From gerald.thornbrugh at oracle.com Tue Jan 31 18:36:54 2017 From: gerald.thornbrugh at oracle.com (Gerald Thornbrugh) Date: Tue, 31 Jan 2017 11:36:54 -0700 Subject: RFR (XXXS) 8173693 disable post_class_unload() for non JavaThread initiators In-Reply-To: <58758a09-fc40-1c56-37bf-607ccc67bb0a@oracle.com> References: <58758a09-fc40-1c56-37bf-607ccc67bb0a@oracle.com> Message-ID: <6E9297B5-A110-4249-A268-A4598BD89C29@oracle.com> Hi Dan, Your changes look good. Thanks, Jerry > On Jan 31, 2017, at 10:18 AM, Daniel D. Daugherty wrote: > > Greetings, > > I have a very small work around for a JVM/TI event posting bug: > > JDK-8173693 disable post_class_unload() for non JavaThread initiators > https://bugs.openjdk.java.net/browse/JDK-8173693 > > This work around disables the JVM/TI post_class_unload() function > when the thread requesting the event is not a JavaThread. See: > > JDK-8173658 JvmtiExport::post_class_unload() is broken for non-JavaThread initiators > https://bugs.openjdk.java.net/browse/JDK-8173658 > > for the gory details of what can (and has) gone wrong. > > Fixing JDK-8173658 is non-trivial so this work around is proposed > to avoid allowing a Class Unload event to crash the VM or silently > corrupt the non JavaThread that tried to post the event. > > Webrev URL: http://cr.openjdk.java.net/~dcubed/8173693-webrev/0-jdk9-hs/ > > Testing: Oracle internal VM/NSK JVM/TI test suite > JPRT testing (in progress) > > > Thanks, in advance, for any comments, questions or suggestions. > > Dan From daniel.daugherty at oracle.com Tue Jan 31 18:37:35 2017 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Tue, 31 Jan 2017 11:37:35 -0700 Subject: RFR (XXXS) 8173693 disable post_class_unload() for non JavaThread initiators In-Reply-To: <6E9297B5-A110-4249-A268-A4598BD89C29@oracle.com> References: <58758a09-fc40-1c56-37bf-607ccc67bb0a@oracle.com> <6E9297B5-A110-4249-A268-A4598BD89C29@oracle.com> Message-ID: <2084e9dd-3a49-dd6a-e891-3167231ef637@oracle.com> Jerry, Thanks for the fast review! Dan On 1/31/17 11:36 AM, Gerald Thornbrugh wrote: > Hi Dan, > > Your changes look good. > > Thanks, > > Jerry >> On Jan 31, 2017, at 10:18 AM, Daniel D. Daugherty wrote: >> >> Greetings, >> >> I have a very small work around for a JVM/TI event posting bug: >> >> JDK-8173693 disable post_class_unload() for non JavaThread initiators >> https://bugs.openjdk.java.net/browse/JDK-8173693 >> >> This work around disables the JVM/TI post_class_unload() function >> when the thread requesting the event is not a JavaThread. See: >> >> JDK-8173658 JvmtiExport::post_class_unload() is broken for non-JavaThread initiators >> https://bugs.openjdk.java.net/browse/JDK-8173658 >> >> for the gory details of what can (and has) gone wrong. >> >> Fixing JDK-8173658 is non-trivial so this work around is proposed >> to avoid allowing a Class Unload event to crash the VM or silently >> corrupt the non JavaThread that tried to post the event. >> >> Webrev URL: http://cr.openjdk.java.net/~dcubed/8173693-webrev/0-jdk9-hs/ >> >> Testing: Oracle internal VM/NSK JVM/TI test suite >> JPRT testing (in progress) >> >> >> Thanks, in advance, for any comments, questions or suggestions. >> >> Dan From david.holmes at oracle.com Tue Jan 31 20:45:45 2017 From: david.holmes at oracle.com (David Holmes) Date: Wed, 1 Feb 2017 06:45:45 +1000 Subject: Review Request: JDK-8173608: Separate JDK management agent from java.management module In-Reply-To: <0769A989-4EDE-4D8E-B3C5-9AE89EFD8529@oracle.com> References: <1B41EF04-9D05-4B96-BB00-B6B14F0F69C0@oracle.com> <508D6511-7443-4F5D-93D2-79D535C3838C@oracle.com> <90abbd53-411e-645c-1c96-700bde19fd56@oracle.com> <0769A989-4EDE-4D8E-B3C5-9AE89EFD8529@oracle.com> Message-ID: <3ca0cbec-75d9-0517-6ede-5bcd46f377e1@oracle.com> On 1/02/2017 12:57 AM, Mandy Chung wrote: > >> On Jan 30, 2017, at 11:00 PM, David Holmes wrote: >> >> Hi Mandy, >> >> On 31/01/2017 9:48 AM, Mandy Chung wrote: >>> Webrev at: >>> http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8173608/webrev.00/index.html >> >> This all seems okay. >> > > Thanks for the review. > >> But we have quite a few hotspot tests that include: >> >> @modules java.management/sun.management >> > > Only 4 classes in the java.management/sun.management are moved to jdk.management.agent/jdk.internal.agent. > > From my grep on hotspot tests, no test uses those renamed classes. Ah I see. Thanks for clarifying. David > Mandy > >> that would seem to need updating as well. >> >> Thanks, >> David >> ----- >> >>> Mandy >>> >>>> On Jan 30, 2017, at 3:42 PM, Mandy Chung wrote: >>>> >>>> java.management is the module for JMX and JMX remote API and >>>> java.lang.management. JDK management agent provides the JDK-specific >>>> out-of-the-box monitoring and management support and it?s cleaner >>>> for it to live in its own module. It is proposed to move it >>>> to a new module named `jdk.management.agent`. >>>> >>>> This change involves: >>>> 1) renaming of sun.management.Agent along with 3 other classes >>>> in sun.management package to jdk.internal.agent package >>>> >>>> 2) move sun.management.resources to jdk.internal.agent.resources >>>> >>>> 3) move sun.management.jmxremote and sun.management.jdp packages >>>> to jdk.management.agent module >>>> >>>> 4) move the configuration files under conf/management >>>> >>>> 5) sun/management/jmxremote/ConnectorBootstrap.java is updated >>>> to replace the use of the ClassLogger API with System.Logger. >>>> >>>> 6) change hotspot VM to add `jdk.management.agent` when >>>> -Dcom.sun.management.* system property is set as well as >>>> the Agent class rename >>>> >>>> Daniel is working on JDK-8173607 [1] that conflicts with this >>>> patch and require merges/coordination. >>>> >>>> We propose to integrate these changes to jdk9/dev unless >>>> there is any objection concerning that this trivial hotspot change >>>> might cause any issue. I have submitted a RBT on hotspot_runtime >>>> and hotspot_serviceability in addition to PIT test runs. >>>> >>>> thanks >>>> Mandy >>>> [1] https://bugs.openjdk.java.net/browse/JDK-8173607 >>> >