From masayoshi.okutsu at oracle.com Fri Jul 1 07:15:20 2016 From: masayoshi.okutsu at oracle.com (Masayoshi Okutsu) Date: Fri, 1 Jul 2016 16:15:20 +0900 Subject: RFR: 8159943: JavaTimeSupplementary resource bundles need update Message-ID: <4d473844-d464-f6a0-0210-242435abea43@oracle.com> Hi, Please review the fix for JDK-8159943. There were some problems in a tool to generate resource bundles. In addition, src/java.base/share/classes/sun/util/resources/LocaleData.java was fixed to look up resource bundles in java.base correctly. Issue: https://bugs.openjdk.java.net/browse/JDK-8159943 Webrev: http://cr.openjdk.java.net/~okutsu/9/8159943/webrev.02 Thanks, Masayoshi From naoto.sato at oracle.com Fri Jul 1 16:20:28 2016 From: naoto.sato at oracle.com (Naoto Sato) Date: Fri, 1 Jul 2016 09:20:28 -0700 Subject: RFR: 8159943: JavaTimeSupplementary resource bundles need update In-Reply-To: <4d473844-d464-f6a0-0210-242435abea43@oracle.com> References: <4d473844-d464-f6a0-0210-242435abea43@oracle.com> Message-ID: <0523285d-1a20-f757-4f11-f9004f83f9f0@oracle.com> Looks fine. Naoto On 7/1/16 12:15 AM, Masayoshi Okutsu wrote: > Hi, > > Please review the fix for JDK-8159943. There were some problems in a > tool to generate resource bundles. In addition, > src/java.base/share/classes/sun/util/resources/LocaleData.java was fixed > to look up resource bundles in java.base correctly. > > Issue: > https://bugs.openjdk.java.net/browse/JDK-8159943 > > Webrev: > http://cr.openjdk.java.net/~okutsu/9/8159943/webrev.02 > > Thanks, > Masayoshi > From masayoshi.okutsu at oracle.com Tue Jul 5 03:57:59 2016 From: masayoshi.okutsu at oracle.com (Masayoshi Okutsu) Date: Tue, 5 Jul 2016 12:57:59 +0900 Subject: RFR: 8136356: Add time zone mappings on Windows Message-ID: Hi, Please review the fix for JDK-8136356. This fix addresses time zone changes of KB3039024, KB3148851, KB914387, and KB3162835. Issue: https://bugs.openjdk.java.net/browse/JDK-8136356 Webrev: http://cr.openjdk.java.net/~okutsu/9/8136356/webrev.00 Thanks, Masayoshi From yuka.kamiya at oracle.com Tue Jul 5 04:15:38 2016 From: yuka.kamiya at oracle.com (Yuka Kamiya) Date: Tue, 5 Jul 2016 13:15:38 +0900 Subject: RFR: 8136356: Add time zone mappings on Windows In-Reply-To: References: Message-ID: <461af1cc-d982-486f-9c86-57ec4731ebbc@oracle.com> Hi, The fix looks good to me. Thanks, -- Yuka On 2016/07/05 12:57, Masayoshi Okutsu wrote: > Hi, > > Please review the fix for JDK-8136356. This fix addresses time zone > changes of KB3039024, KB3148851, KB914387, and KB3162835. > > Issue: > https://bugs.openjdk.java.net/browse/JDK-8136356 > > Webrev: > http://cr.openjdk.java.net/~okutsu/9/8136356/webrev.00 > > Thanks, > Masayoshi > From nishit.jain at oracle.com Thu Jul 7 07:17:25 2016 From: nishit.jain at oracle.com (Nishit Jain) Date: Thu, 7 Jul 2016 12:47:25 +0530 Subject: Review Request for JDK-8055900: j.t.SimpleDateFormat spec needs to be clarified regarding month patterns Message-ID: Hi, Please review the fix for JDK-8055900 Bug: https://bugs.openjdk.java.net/browse/JDK-8055900 Webrev: http://cr.openjdk.java.net/~nishjain/8055900/webrev.02/ Fix: A clarification regarding the context sensitivity of the month pattern is added in the java.text.SimpleDateFormat specification. A typo is corrected in the java.text.DateFormatSymbols.java Regards, Nishit Jain From yuka.kamiya at oracle.com Thu Jul 7 08:07:02 2016 From: yuka.kamiya at oracle.com (Yuka Kamiya) Date: Thu, 7 Jul 2016 17:07:02 +0900 Subject: Review Request for JDK-8055900: j.t.SimpleDateFormat spec needs to be clarified regarding month patterns In-Reply-To: References: Message-ID: <0c48bc22-e3d1-20da-d109-ff0a572bda23@oracle.com> Hi, The fix looks okay to me. Thanks, -- Yuka On 2016/07/07 16:17, Nishit Jain wrote: > Hi, > > Please review the fix for JDK-8055900 > > Bug: https://bugs.openjdk.java.net/browse/JDK-8055900 > Webrev: http://cr.openjdk.java.net/~nishjain/8055900/webrev.02/ > > Fix: A clarification regarding the context sensitivity of the month > pattern is added in the java.text.SimpleDateFormat specification. A > typo is corrected in the java.text.DateFormatSymbols.java > > Regards, > Nishit Jain From masayoshi.okutsu at oracle.com Thu Jul 7 08:12:07 2016 From: masayoshi.okutsu at oracle.com (Masayoshi Okutsu) Date: Thu, 7 Jul 2016 17:12:07 +0900 Subject: Review Request for JDK-8055900: j.t.SimpleDateFormat spec needs to be clarified regarding month patterns In-Reply-To: <0c48bc22-e3d1-20da-d109-ff0a572bda23@oracle.com> References: <0c48bc22-e3d1-20da-d109-ff0a572bda23@oracle.com> Message-ID: <204e833e-d29c-cbfb-9a61-82b1bcb2d68a@oracle.com> +1 Masayoshi On 7/7/2016 5:07 PM, Yuka Kamiya wrote: > Hi, > > The fix looks okay to me. > > Thanks, > -- > Yuka > > > On 2016/07/07 16:17, Nishit Jain wrote: >> Hi, >> >> Please review the fix for JDK-8055900 >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8055900 >> Webrev: http://cr.openjdk.java.net/~nishjain/8055900/webrev.02/ >> >> Fix: A clarification regarding the context sensitivity of the month >> pattern is added in the java.text.SimpleDateFormat specification. A >> typo is corrected in the java.text.DateFormatSymbols.java >> >> Regards, >> Nishit Jain > From ramanand.patil at oracle.com Tue Jul 12 09:27:42 2016 From: ramanand.patil at oracle.com (Ramanand Patil) Date: Tue, 12 Jul 2016 02:27:42 -0700 (PDT) Subject: RFR: 8159684: (tz) Support tzdata2016f Message-ID: <2c87fb50-c44c-42fc-8189-093c265814d0@default> Hi all, Please review the latest TZDATA integration (tzdata2016f) to JDK9. Bug: https://bugs.openjdk.java.net/browse/JDK-8159684 Webrev: http://cr.openjdk.java.net/~rpatil/8159684/webrev.00/ All the TimeZone related tests are passed after this integration. Regards, Ramanand. From masayoshi.okutsu at oracle.com Wed Jul 13 06:43:34 2016 From: masayoshi.okutsu at oracle.com (Masayoshi Okutsu) Date: Wed, 13 Jul 2016 15:43:34 +0900 Subject: RFR: 8159684: (tz) Support tzdata2016f In-Reply-To: <2c87fb50-c44c-42fc-8189-093c265814d0@default> References: <2c87fb50-c44c-42fc-8189-093c265814d0@default> Message-ID: I don't think it's appropriate to add 8159684 to TimeZoneTest.java which doesn't test the data changes of 2016e/f at all. I think there should be a time zone data test in java.time to confirm the tzdata changes. Otherwise, the changes look good to me. Thanks, Masayoshi On 7/12/2016 6:27 PM, Ramanand Patil wrote: > Hi all, > > Please review the latest TZDATA integration (tzdata2016f) to JDK9. > Bug: https://bugs.openjdk.java.net/browse/JDK-8159684 > Webrev: http://cr.openjdk.java.net/~rpatil/8159684/webrev.00/ > > All the TimeZone related tests are passed after this integration. > > Regards, > Ramanand. From rachna.goel at oracle.com Wed Jul 13 09:01:27 2016 From: rachna.goel at oracle.com (Rachna Goel) Date: Wed, 13 Jul 2016 14:31:27 +0530 Subject: Review Request-JDK-8154797:Localization data for "GMT" Message-ID: Hi, Please review fix for JDK-8154797. Bug: https://bugs.openjdk.java.net/browse/JDK-8154797 webrev: http://cr.openjdk.java.net/~rgoel/JDK-8154797/webrev.04/ fix summary: Added support for GMT Localization resources (GmtFormat and hourFormat). For more info: http://unicode.org/repos/cldr/trunk/specs/ldml/tr35-dates.html#Using_Time_Zone_Names -- Thanks, Rachna From naoto.sato at oracle.com Wed Jul 13 15:34:59 2016 From: naoto.sato at oracle.com (Naoto Sato) Date: Wed, 13 Jul 2016 08:34:59 -0700 Subject: Review Request-JDK-8154797:Localization data for "GMT" In-Reply-To: References: Message-ID: Hi Rachna, Did you intend to use Locale.GERMANY/JAPAN/US, instead of Locale.GERMAN/JAPANESE/ENGLISH in Bug8154797.java? You can also use Locale.FRANCE and Locale.UK constants in the test case. Otherwise it looks good. Naoto On 7/13/16 2:01 AM, Rachna Goel wrote: > Hi, > > Please review fix for JDK-8154797. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8154797 > > webrev: http://cr.openjdk.java.net/~rgoel/JDK-8154797/webrev.04/ > > fix summary: Added support for GMT Localization resources (GmtFormat and > hourFormat). > For more info: > http://unicode.org/repos/cldr/trunk/specs/ldml/tr35-dates.html#Using_Time_Zone_Names > > From rachna.goel at oracle.com Wed Jul 13 17:14:35 2016 From: rachna.goel at oracle.com (Rachna Goel) Date: Wed, 13 Jul 2016 22:44:35 +0530 Subject: Review Request-JDK-8154797:Localization data for "GMT" In-Reply-To: References:

Message-ID: Hi Naoto, Thanks for the review. Please have a look at updated webrev : http://cr.openjdk.java.net/~rgoel/JDK-8154797/webrev.05/ Thanks, Rachna On 7/13/2016 9:04 PM, Naoto Sato wrote: > Hi Rachna, > > Did you intend to use Locale.GERMANY/JAPAN/US, instead of > Locale.GERMAN/JAPANESE/ENGLISH in Bug8154797.java? You can also use > Locale.FRANCE and Locale.UK constants in the test case. > > Otherwise it looks good. > > Naoto > > On 7/13/16 2:01 AM, Rachna Goel wrote: >> Hi, >> >> Please review fix for JDK-8154797. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8154797 >> >> webrev: http://cr.openjdk.java.net/~rgoel/JDK-8154797/webrev.04/ >> >> fix summary: Added support for GMT Localization resources (GmtFormat and >> hourFormat). >> For more info: >> http://unicode.org/repos/cldr/trunk/specs/ldml/tr35-dates.html#Using_Time_Zone_Names >> >> >> -- Thanks, Rachna From naoto.sato at oracle.com Wed Jul 13 17:15:27 2016 From: naoto.sato at oracle.com (Naoto Sato) Date: Wed, 13 Jul 2016 10:15:27 -0700 Subject: Review Request-JDK-8154797:Localization data for "GMT" In-Reply-To: References:

Message-ID: +1 Naoto On 7/13/16 10:14 AM, Rachna Goel wrote: > Hi Naoto, > > Thanks for the review. > Please have a look at updated webrev : > http://cr.openjdk.java.net/~rgoel/JDK-8154797/webrev.05/ > > Thanks, > Rachna > > On 7/13/2016 9:04 PM, Naoto Sato wrote: >> Hi Rachna, >> >> Did you intend to use Locale.GERMANY/JAPAN/US, instead of >> Locale.GERMAN/JAPANESE/ENGLISH in Bug8154797.java? You can also use >> Locale.FRANCE and Locale.UK constants in the test case. >> >> Otherwise it looks good. >> >> Naoto >> >> On 7/13/16 2:01 AM, Rachna Goel wrote: >>> Hi, >>> >>> Please review fix for JDK-8154797. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8154797 >>> >>> webrev: http://cr.openjdk.java.net/~rgoel/JDK-8154797/webrev.04/ >>> >>> fix summary: Added support for GMT Localization resources (GmtFormat and >>> hourFormat). >>> For more info: >>> http://unicode.org/repos/cldr/trunk/specs/ldml/tr35-dates.html#Using_Time_Zone_Names >>> >>> >>> > From masayoshi.okutsu at oracle.com Wed Jul 13 23:25:47 2016 From: masayoshi.okutsu at oracle.com (Masayoshi Okutsu) Date: Thu, 14 Jul 2016 08:25:47 +0900 Subject: Review Request-JDK-8154797:Localization data for "GMT" In-Reply-To: References:

Message-ID: <3834d122-65de-5d09-1279-43aa97ab711c@oracle.com> +1 Masayoshi On 7/14/2016 2:15 AM, Naoto Sato wrote: > +1 > > Naoto > > On 7/13/16 10:14 AM, Rachna Goel wrote: >> Hi Naoto, >> >> Thanks for the review. >> Please have a look at updated webrev : >> http://cr.openjdk.java.net/~rgoel/JDK-8154797/webrev.05/ >> >> Thanks, >> Rachna >> >> On 7/13/2016 9:04 PM, Naoto Sato wrote: >>> Hi Rachna, >>> >>> Did you intend to use Locale.GERMANY/JAPAN/US, instead of >>> Locale.GERMAN/JAPANESE/ENGLISH in Bug8154797.java? You can also use >>> Locale.FRANCE and Locale.UK constants in the test case. >>> >>> Otherwise it looks good. >>> >>> Naoto >>> >>> On 7/13/16 2:01 AM, Rachna Goel wrote: >>>> Hi, >>>> >>>> Please review fix for JDK-8154797. >>>> >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8154797 >>>> >>>> webrev: http://cr.openjdk.java.net/~rgoel/JDK-8154797/webrev.04/ >>>> >>>> fix summary: Added support for GMT Localization resources >>>> (GmtFormat and >>>> hourFormat). >>>> For more info: >>>> http://unicode.org/repos/cldr/trunk/specs/ldml/tr35-dates.html#Using_Time_Zone_Names >>>> >>>> >>>> >>>> >> From naoto.sato at oracle.com Thu Jul 14 12:42:57 2016 From: naoto.sato at oracle.com (Naoto Sato) Date: Thu, 14 Jul 2016 05:42:57 -0700 Subject: [9] RFR: 8159214: jlink --include-locales problems Message-ID: Hello, Please review the fix to the following issue: https://bugs.openjdk.java.net/browse/JDK-8159214 The fix is located at: http://cr.openjdk.java.net/~naoto/8159214/webrev.04/ Naoto From ramanand.patil at oracle.com Fri Jul 15 06:49:00 2016 From: ramanand.patil at oracle.com (Ramanand Patil) Date: Thu, 14 Jul 2016 23:49:00 -0700 (PDT) Subject: RFR: 8159684: (tz) Support tzdata2016f In-Reply-To: References: <2c87fb50-c44c-42fc-8189-093c265814d0@default> Message-ID: Hi Masayoshi, The reason for adding bugId(8159684) to TimeZoneTest.java was, it actually tests the major change in the releases tzdata2016e and tzdata2016f. tzdata2016e: "Africa/Cairo observes DST in 2016 from July 7 to the end of October." tzdata201f: The Egyptian government changed its mind on short notice, and Africa/Cairo will not introduce DST starting 2016-07-07 after all. After integrating, tzdata2016e, TimeZoneTest.java was failing because at line no. 123 DST was false which should be true. (new ZoneDescriptor("ART", 120, false)) And integrating tzdata2016f has again made the DST false in the test case. Since the bug covers both the changes, I kept the bugID in the test case. Please let me know if I still need to remove the bugID from test case. Regards, Ramanand. -----Original Message----- From: Masayoshi Okutsu Sent: Wednesday, July 13, 2016 12:14 PM To: Ramanand Patil; i18n-dev at openjdk.java.net Cc: core-libs-dev at openjdk.java.net Subject: Re: RFR: 8159684: (tz) Support tzdata2016f I don't think it's appropriate to add 8159684 to TimeZoneTest.java which doesn't test the data changes of 2016e/f at all. I think there should be a time zone data test in java.time to confirm the tzdata changes. Otherwise, the changes look good to me. Thanks, Masayoshi On 7/12/2016 6:27 PM, Ramanand Patil wrote: > Hi all, > > Please review the latest TZDATA integration (tzdata2016f) to JDK9. > Bug: https://bugs.openjdk.java.net/browse/JDK-8159684 > Webrev: http://cr.openjdk.java.net/~rpatil/8159684/webrev.00/ > > All the TimeZone related tests are passed after this integration. > > Regards, > Ramanand. From naoto.sato at oracle.com Mon Jul 18 15:54:56 2016 From: naoto.sato at oracle.com (Naoto Sato) Date: Mon, 18 Jul 2016 08:54:56 -0700 Subject: [9] RFR: 8159214: jlink --include-locales problems In-Reply-To: References: Message-ID: <71d5d09c-5c8a-766e-30d3-1cf707282345@oracle.com> Ping. On 7/14/16 5:42 AM, Naoto Sato wrote: > Hello, > > Please review the fix to the following issue: > > https://bugs.openjdk.java.net/browse/JDK-8159214 > > The fix is located at: > > http://cr.openjdk.java.net/~naoto/8159214/webrev.04/ > > Naoto From masayoshi.okutsu at oracle.com Thu Jul 21 04:14:37 2016 From: masayoshi.okutsu at oracle.com (Masayoshi Okutsu) Date: Thu, 21 Jul 2016 13:14:37 +0900 Subject: RFR: 8161203: ResourceBundle.getBundle performance regression Message-ID: <7fc61181-7c3c-ea1c-d07a-90a2e712844c@oracle.com> Hi, Please review the fix for JDK-8161203. The fix is to lazily load ResourceBundleProviders. It's not necessary to load providers before cache look-up. Issue: https://bugs.openjdk.java.net/browse/JDK-8161203 Webrev: http://cr.openjdk.java.net/~okutsu/9/8161203/webrev.01 Thanks, Masayoshi From Alan.Bateman at oracle.com Thu Jul 21 07:14:21 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 21 Jul 2016 08:14:21 +0100 Subject: RFR: 8161203: ResourceBundle.getBundle performance regression In-Reply-To: <7fc61181-7c3c-ea1c-d07a-90a2e712844c@oracle.com> References: <7fc61181-7c3c-ea1c-d07a-90a2e712844c@oracle.com> Message-ID: <861eb77e-2dcc-cf15-4e80-5996735189bc@oracle.com> On 21/07/2016 05:14, Masayoshi Okutsu wrote: > Hi, > > Please review the fix for JDK-8161203. The fix is to lazily load > ResourceBundleProviders. It's not necessary to load providers before > cache look-up. > > Issue: > https://bugs.openjdk.java.net/browse/JDK-8161203 > > Webrev: > http://cr.openjdk.java.net/~okutsu/9/8161203/webrev.01 > > Thanks, > Masayoshi > This change looks okay to me. In passing, I can't quite tell if using CacheKey::providers is safe or not - this may be something to look into. -Alan From peter.levart at gmail.com Thu Jul 21 13:13:02 2016 From: peter.levart at gmail.com (Peter Levart) Date: Thu, 21 Jul 2016 15:13:02 +0200 Subject: RFR: 8161203: ResourceBundle.getBundle performance regression In-Reply-To: <7fc61181-7c3c-ea1c-d07a-90a2e712844c@oracle.com> References: <7fc61181-7c3c-ea1c-d07a-90a2e712844c@oracle.com> Message-ID: Hi Masayoshi, Previously the CacheKey::clone() method cleared a reference to 'providers' in the clone making the provides unreachable from the clone and making the clone unable to obtain providers. Now you also reset the 'providersChecked' flag which makes the clone be able to re-obtain the providers. This is dangerous as the clone is used as a key in the cache and is strongly reachable from the cache. A slight future modification of code could unintentionally produce a class loader leak. To prevent that, I would somehow mark the clone so that any attempt to invoke getProviders() on the clone would throw IllegalStateException. Regards, Peter On 07/21/2016 06:14 AM, Masayoshi Okutsu wrote: > Hi, > > Please review the fix for JDK-8161203. The fix is to lazily load > ResourceBundleProviders. It's not necessary to load providers before > cache look-up. > > Issue: > https://bugs.openjdk.java.net/browse/JDK-8161203 > > Webrev: > http://cr.openjdk.java.net/~okutsu/9/8161203/webrev.01 > > Thanks, > Masayoshi > From masayoshi.okutsu at oracle.com Fri Jul 22 04:07:15 2016 From: masayoshi.okutsu at oracle.com (Masayoshi Okutsu) Date: Fri, 22 Jul 2016 13:07:15 +0900 Subject: RFR: 8161203: ResourceBundle.getBundle performance regression In-Reply-To: References: <7fc61181-7c3c-ea1c-d07a-90a2e712844c@oracle.com> Message-ID: <5991183a-8d2a-967d-74ec-c99e7d1636f3@oracle.com> Hi Peter, Thank you for your suggestion. Actually CacheKey is used for storing information required to load resource bundles during a ResourceBundle.getBundle call. The current CacheKey usage may be too tricky and cause some maintenance problems. I will file a separate issue on that problem. I wanted to work on some clean up of the CacheKey usage, but I haven't had a chance. Thanks, Masayoshi On 7/21/2016 10:13 PM, Peter Levart wrote: > Hi Masayoshi, > > Previously the CacheKey::clone() method cleared a reference to > 'providers' in the clone making the provides unreachable from the > clone and making the clone unable to obtain providers. Now you also > reset the 'providersChecked' flag which makes the clone be able to > re-obtain the providers. This is dangerous as the clone is used as a > key in the cache and is strongly reachable from the cache. A slight > future modification of code could unintentionally produce a class > loader leak. To prevent that, I would somehow mark the clone so that > any attempt to invoke getProviders() on the clone would throw > IllegalStateException. > > Regards, Peter > > On 07/21/2016 06:14 AM, Masayoshi Okutsu wrote: >> Hi, >> >> Please review the fix for JDK-8161203. The fix is to lazily load >> ResourceBundleProviders. It's not necessary to load providers before >> cache look-up. >> >> Issue: >> https://bugs.openjdk.java.net/browse/JDK-8161203 >> >> Webrev: >> http://cr.openjdk.java.net/~okutsu/9/8161203/webrev.01 >> >> Thanks, >> Masayoshi >> > From peter.levart at gmail.com Fri Jul 22 08:46:16 2016 From: peter.levart at gmail.com (Peter Levart) Date: Fri, 22 Jul 2016 10:46:16 +0200 Subject: RFR: 8161203: ResourceBundle.getBundle performance regression In-Reply-To: <5991183a-8d2a-967d-74ec-c99e7d1636f3@oracle.com> References: <7fc61181-7c3c-ea1c-d07a-90a2e712844c@oracle.com> <5991183a-8d2a-967d-74ec-c99e7d1636f3@oracle.com> Message-ID: Hi Masayoshi, Thinking of how the ResourceBundle caching is implemented, I think it has a serious flaw. The cache is currently the following: private static final ConcurrentMap cacheList ...where the CacheKey is an object which contains WeakReference(s) to the caller's ClassLoader and Module. This is OK. BundleReference, OTOH, is a SoftReference. The problem is ResourceBundle(s) can be arbitrary user subclasses, which means that they may have an implicit reference to the ClassLoader that appears in the CacheKey. The consequence is that such cache can prevent GC-ing of the ClassLoader for arbitrary amount of time (SoftReferences are cleared on memory pressure). Luckily there might be a solution. If the ResourceBundle subclasses are always resolvable from the ClassLoader that appears in the CacheKey, then there is a utility class that I created recently: java.lang.reflect.ClassLoaderValue. This a package-private class as it is currently used only in java.lang.reflect.Proxy for caching of dynamic Proxy classes, but could be made public and moved to some jdk.internal... package. Basing ResourceBundle caching on this utility class could also simplify the implementation as you wouldn't have to deal with WeakReference(s) to ClassLoader and Module objects. You could still have a BundleReference extending SoftReference to release the bundles on memory pressure but since such SoftReference(s) would be anchored in the particular ClassLoader instance that can resolve the ResourceBundle subclasses, it would not prevent such ClassLoader from being GCed immediately. I can prototype such caching if you like. Regards, Peter On 07/22/2016 06:07 AM, Masayoshi Okutsu wrote: > Hi Peter, > > Thank you for your suggestion. Actually CacheKey is used for storing > information required to load resource bundles during a > ResourceBundle.getBundle call. The current CacheKey usage may be too > tricky and cause some maintenance problems. I will file a separate > issue on that problem. I wanted to work on some clean up of the > CacheKey usage, but I haven't had a chance. > > Thanks, > Masayoshi > > > On 7/21/2016 10:13 PM, Peter Levart wrote: >> Hi Masayoshi, >> >> Previously the CacheKey::clone() method cleared a reference to >> 'providers' in the clone making the provides unreachable from the >> clone and making the clone unable to obtain providers. Now you also >> reset the 'providersChecked' flag which makes the clone be able to >> re-obtain the providers. This is dangerous as the clone is used as a >> key in the cache and is strongly reachable from the cache. A slight >> future modification of code could unintentionally produce a class >> loader leak. To prevent that, I would somehow mark the clone so that >> any attempt to invoke getProviders() on the clone would throw >> IllegalStateException. >> >> Regards, Peter >> >> On 07/21/2016 06:14 AM, Masayoshi Okutsu wrote: >>> Hi, >>> >>> Please review the fix for JDK-8161203. The fix is to lazily load >>> ResourceBundleProviders. It's not necessary to load providers before >>> cache look-up. >>> >>> Issue: >>> https://bugs.openjdk.java.net/browse/JDK-8161203 >>> >>> Webrev: >>> http://cr.openjdk.java.net/~okutsu/9/8161203/webrev.01 >>> >>> Thanks, >>> Masayoshi >>> >> > From peter.levart at gmail.com Fri Jul 22 13:13:02 2016 From: peter.levart at gmail.com (Peter Levart) Date: Fri, 22 Jul 2016 15:13:02 +0200 Subject: RFR: 8161203: ResourceBundle.getBundle performance regression In-Reply-To: References: <7fc61181-7c3c-ea1c-d07a-90a2e712844c@oracle.com> <5991183a-8d2a-967d-74ec-c99e7d1636f3@oracle.com> Message-ID: <884a78a8-ebfb-a15d-a036-37b9fd377401@gmail.com> On 07/22/2016 10:46 AM, Peter Levart wrote: > Hi Masayoshi, Here's a preview of work to migrate ResourceBundle caching to using ClassLoaderValue utility: http://cr.openjdk.java.net/~plevart/jdk9-dev/ResourceBundle.cleanup/webrev.04/ The changes are very straightforward. They preserve the general structure of the logic. I renamed the CacheKey nested class to LoadSession as it now only functions as a mutable object passed around the methods while executing the getBundle() process. LoadSession is now a factory for ClassLoaderValue cache key. I moved the loadTime and expirationTime fields from LoadSession (old CacheKey) to ResourceBundle. As each cached entry must maintain it's own loadTime/expirationTime, I changed the NONEXISTENT_BUNDLE constant into a private subclass of ResourceBundle. The back-link from ResourceBundle to CacheKey is not needed any more. There is a backlink from BundleReference to ClassLoaderValue key and the associated ClassLoader to enable expunging. All 41 java/util/ResourceBundle tests pass with this change applied. Including the ReferenceTest which I had to modify a little to remove a dependency on ResourceBundle.cacheList field which is only used in test to report the size of the Map. It is not possible to obtain the size of the Map any more with this change applied, since the entries are distributed to multiple Map(s) - one Map per ClassLoader instance. The following comment in ReferenceTest could now be removed: * This test relies on the current behavior of the garbage collector and is * therefore no clear indicator of whether the fix for 4405807 works. * If the test fails, it might indicate a regression, or it might just mean * that a less aggressive garbage collector is used. ...as the ClassLoader(s) unloading does not depend on eagerness of SoftReference(s) clearing or any other activity any more. What do you think? Regards, Peter > > Thinking of how the ResourceBundle caching is implemented, I think it > has a serious flaw. The cache is currently the following: > > private static final ConcurrentMap cacheList > > ...where the CacheKey is an object which contains WeakReference(s) to > the caller's ClassLoader and Module. This is OK. > > BundleReference, OTOH, is a SoftReference. The problem > is ResourceBundle(s) can be arbitrary user subclasses, which means > that they may have an implicit reference to the ClassLoader that > appears in the CacheKey. The consequence is that such cache can > prevent GC-ing of the ClassLoader for arbitrary amount of time > (SoftReferences are cleared on memory pressure). > > Luckily there might be a solution. If the ResourceBundle subclasses > are always resolvable from the ClassLoader that appears in the > CacheKey, then there is a utility class that I created recently: > java.lang.reflect.ClassLoaderValue. This a package-private class as it > is currently used only in java.lang.reflect.Proxy for caching of > dynamic Proxy classes, but could be made public and moved to some > jdk.internal... package. > > Basing ResourceBundle caching on this utility class could also > simplify the implementation as you wouldn't have to deal with > WeakReference(s) to ClassLoader and Module objects. You could still > have a BundleReference extending SoftReference to > release the bundles on memory pressure but since such SoftReference(s) > would be anchored in the particular ClassLoader instance that can > resolve the ResourceBundle subclasses, it would not prevent such > ClassLoader from being GCed immediately. > > I can prototype such caching if you like. > > Regards, Peter > > On 07/22/2016 06:07 AM, Masayoshi Okutsu wrote: >> Hi Peter, >> >> Thank you for your suggestion. Actually CacheKey is used for storing >> information required to load resource bundles during a >> ResourceBundle.getBundle call. The current CacheKey usage may be too >> tricky and cause some maintenance problems. I will file a separate >> issue on that problem. I wanted to work on some clean up of the >> CacheKey usage, but I haven't had a chance. >> >> Thanks, >> Masayoshi >> >> >> On 7/21/2016 10:13 PM, Peter Levart wrote: >>> Hi Masayoshi, >>> >>> Previously the CacheKey::clone() method cleared a reference to >>> 'providers' in the clone making the provides unreachable from the >>> clone and making the clone unable to obtain providers. Now you also >>> reset the 'providersChecked' flag which makes the clone be able to >>> re-obtain the providers. This is dangerous as the clone is used as a >>> key in the cache and is strongly reachable from the cache. A slight >>> future modification of code could unintentionally produce a class >>> loader leak. To prevent that, I would somehow mark the clone so that >>> any attempt to invoke getProviders() on the clone would throw >>> IllegalStateException. >>> >>> Regards, Peter >>> >>> On 07/21/2016 06:14 AM, Masayoshi Okutsu wrote: >>>> Hi, >>>> >>>> Please review the fix for JDK-8161203. The fix is to lazily load >>>> ResourceBundleProviders. It's not necessary to load providers >>>> before cache look-up. >>>> >>>> Issue: >>>> https://bugs.openjdk.java.net/browse/JDK-8161203 >>>> >>>> Webrev: >>>> http://cr.openjdk.java.net/~okutsu/9/8161203/webrev.01 >>>> >>>> Thanks, >>>> Masayoshi >>>> >>> >> > From Alan.Bateman at oracle.com Sun Jul 24 09:35:47 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sun, 24 Jul 2016 10:35:47 +0100 Subject: RFR: 8161203: ResourceBundle.getBundle performance regression In-Reply-To: <884a78a8-ebfb-a15d-a036-37b9fd377401@gmail.com> References: <7fc61181-7c3c-ea1c-d07a-90a2e712844c@oracle.com> <5991183a-8d2a-967d-74ec-c99e7d1636f3@oracle.com> <884a78a8-ebfb-a15d-a036-37b9fd377401@gmail.com> Message-ID: On 22/07/2016 14:13, Peter Levart wrote: > : > > The changes are very straightforward. They preserve the general > structure of the logic. I renamed the CacheKey nested class to > LoadSession as it now only functions as a mutable object passed around > the methods while executing the getBundle() process. LoadSession is > now a factory for ClassLoaderValue cache key. I moved the loadTime and > expirationTime fields from LoadSession (old CacheKey) to > ResourceBundle. As each cached entry must maintain it's own > loadTime/expirationTime, I changed the NONEXISTENT_BUNDLE constant > into a private subclass of ResourceBundle. The back-link from > ResourceBundle to CacheKey is not needed any more. There is a backlink > from BundleReference to ClassLoaderValue key and the associated > ClassLoader to enable expunging. Not a comment on the the ResourceBundle changes but I think it would be generally useful if we moved CLV jdk.internal. so that it can be used by other code in java.base. I had cause to do this recently when prototyping something in a completely different area recently. -Alan. From masayoshi.okutsu at oracle.com Mon Jul 25 06:08:55 2016 From: masayoshi.okutsu at oracle.com (Masayoshi Okutsu) Date: Mon, 25 Jul 2016 15:08:55 +0900 Subject: RFR: 8161203: ResourceBundle.getBundle performance regression In-Reply-To: <884a78a8-ebfb-a15d-a036-37b9fd377401@gmail.com> References: <7fc61181-7c3c-ea1c-d07a-90a2e712844c@oracle.com> <5991183a-8d2a-967d-74ec-c99e7d1636f3@oracle.com> <884a78a8-ebfb-a15d-a036-37b9fd377401@gmail.com> Message-ID: <2b8eb9f2-7b81-512b-6dde-0631d2c01c39@oracle.com> Hi Peter, The change (ResourceBundle part) looks very good to me. There's a simple workaround for the problem -- call ResourceBundle.clearCache(ClassLoader). So I don't know how serious the problem is, though. I still like this change. Yes, the comment in ReferenceTest should be removed. Thanks, Masayoshi On 7/22/2016 10:13 PM, Peter Levart wrote: > On 07/22/2016 10:46 AM, Peter Levart wrote: >> Hi Masayoshi, > > Here's a preview of work to migrate ResourceBundle caching to using > ClassLoaderValue utility: > > http://cr.openjdk.java.net/~plevart/jdk9-dev/ResourceBundle.cleanup/webrev.04/ > > > The changes are very straightforward. They preserve the general > structure of the logic. I renamed the CacheKey nested class to > LoadSession as it now only functions as a mutable object passed around > the methods while executing the getBundle() process. LoadSession is > now a factory for ClassLoaderValue cache key. I moved the loadTime and > expirationTime fields from LoadSession (old CacheKey) to > ResourceBundle. As each cached entry must maintain it's own > loadTime/expirationTime, I changed the NONEXISTENT_BUNDLE constant > into a private subclass of ResourceBundle. The back-link from > ResourceBundle to CacheKey is not needed any more. There is a backlink > from BundleReference to ClassLoaderValue key and the associated > ClassLoader to enable expunging. > > All 41 java/util/ResourceBundle tests pass with this change applied. > Including the ReferenceTest which I had to modify a little to remove a > dependency on ResourceBundle.cacheList field which is only used in > test to report the size of the Map. It is not possible to obtain the > size of the Map any more with this change applied, since the entries > are distributed to multiple Map(s) - one Map per ClassLoader instance. > The following comment in ReferenceTest could now be removed: > > * This test relies on the current behavior of the garbage collector > and is > * therefore no clear indicator of whether the fix for 4405807 works. > * If the test fails, it might indicate a regression, or it might just > mean > * that a less aggressive garbage collector is used. > > ...as the ClassLoader(s) unloading does not depend on eagerness of > SoftReference(s) clearing or any other activity any more. > > What do you think? > > Regards, Peter > >> >> Thinking of how the ResourceBundle caching is implemented, I think it >> has a serious flaw. The cache is currently the following: >> >> private static final ConcurrentMap cacheList >> >> ...where the CacheKey is an object which contains WeakReference(s) to >> the caller's ClassLoader and Module. This is OK. >> >> BundleReference, OTOH, is a SoftReference. The >> problem is ResourceBundle(s) can be arbitrary user subclasses, which >> means that they may have an implicit reference to the ClassLoader >> that appears in the CacheKey. The consequence is that such cache can >> prevent GC-ing of the ClassLoader for arbitrary amount of time >> (SoftReferences are cleared on memory pressure). >> >> Luckily there might be a solution. If the ResourceBundle subclasses >> are always resolvable from the ClassLoader that appears in the >> CacheKey, then there is a utility class that I created recently: >> java.lang.reflect.ClassLoaderValue. This a package-private class as >> it is currently used only in java.lang.reflect.Proxy for caching of >> dynamic Proxy classes, but could be made public and moved to some >> jdk.internal... package. >> >> Basing ResourceBundle caching on this utility class could also >> simplify the implementation as you wouldn't have to deal with >> WeakReference(s) to ClassLoader and Module objects. You could still >> have a BundleReference extending SoftReference to >> release the bundles on memory pressure but since such >> SoftReference(s) would be anchored in the particular ClassLoader >> instance that can resolve the ResourceBundle subclasses, it would not >> prevent such ClassLoader from being GCed immediately. >> >> I can prototype such caching if you like. >> >> Regards, Peter >> >> On 07/22/2016 06:07 AM, Masayoshi Okutsu wrote: >>> Hi Peter, >>> >>> Thank you for your suggestion. Actually CacheKey is used for storing >>> information required to load resource bundles during a >>> ResourceBundle.getBundle call. The current CacheKey usage may be too >>> tricky and cause some maintenance problems. I will file a separate >>> issue on that problem. I wanted to work on some clean up of the >>> CacheKey usage, but I haven't had a chance. >>> >>> Thanks, >>> Masayoshi >>> >>> >>> On 7/21/2016 10:13 PM, Peter Levart wrote: >>>> Hi Masayoshi, >>>> >>>> Previously the CacheKey::clone() method cleared a reference to >>>> 'providers' in the clone making the provides unreachable from the >>>> clone and making the clone unable to obtain providers. Now you also >>>> reset the 'providersChecked' flag which makes the clone be able to >>>> re-obtain the providers. This is dangerous as the clone is used as >>>> a key in the cache and is strongly reachable from the cache. A >>>> slight future modification of code could unintentionally produce a >>>> class loader leak. To prevent that, I would somehow mark the clone >>>> so that any attempt to invoke getProviders() on the clone would >>>> throw IllegalStateException. >>>> >>>> Regards, Peter >>>> >>>> On 07/21/2016 06:14 AM, Masayoshi Okutsu wrote: >>>>> Hi, >>>>> >>>>> Please review the fix for JDK-8161203. The fix is to lazily load >>>>> ResourceBundleProviders. It's not necessary to load providers >>>>> before cache look-up. >>>>> >>>>> Issue: >>>>> https://bugs.openjdk.java.net/browse/JDK-8161203 >>>>> >>>>> Webrev: >>>>> http://cr.openjdk.java.net/~okutsu/9/8161203/webrev.01 >>>>> >>>>> Thanks, >>>>> Masayoshi >>>>> >>>> >>> >> > From rachna.goel at oracle.com Fri Jul 29 06:16:44 2016 From: rachna.goel at oracle.com (Rachna Goel) Date: Fri, 29 Jul 2016 11:46:44 +0530 Subject: Review Request : JDK-8066652 : Default TimeZone is GMT not local if user.timezone is invalid on Mac OS Message-ID: <66d02394-289b-5fe0-6d7c-b7a65d2491f7@oracle.com> Hi, Please review the fix for JDK-8066652. Bug : https://bugs.openjdk.java.net/browse/JDK-8066652 Webrev: http://cr.openjdk.java.net/~rgoel/JDK-8066652/webrev.01/ Fix : 1. Used thread safe function localtime_r() to retrieve system timezone. 2. timezone retrieved should be "GMT" if system timezone is "GMT" and user specifies a fake timezone using user.timezone system property. Earlier it used to be "GMT+00:00" which is wrong. -- Thanks, Rachna From christoph.langer at sap.com Fri Jul 29 11:05:00 2016 From: christoph.langer at sap.com (Langer, Christoph) Date: Fri, 29 Jul 2016 11:05:00 +0000 Subject: Review Request : JDK-8066652 : Default TimeZone is GMT not local if user.timezone is invalid on Mac OS In-Reply-To: <66d02394-289b-5fe0-6d7c-b7a65d2491f7@oracle.com> References: <66d02394-289b-5fe0-6d7c-b7a65d2491f7@oracle.com> Message-ID: <5acc8b7b9b9c4d9a821d24cc4003199b@DEWDFE13DE11.global.corp.sap> Hi Rachna, In general, the fix looks good to me. However, there are a few indentation flaws, in lines 830, 831 and 834 - 841. Please make sure you use 4 chars indentation. And you should remove the blank between the cast to (time_t) and the variable in line 832. Also, please note that I'm no reviewer. Best regards, Christoph > -----Original Message----- > From: i18n-dev [mailto:i18n-dev-bounces at openjdk.java.net] On Behalf Of > Rachna Goel > Sent: Freitag, 29. Juli 2016 08:17 > To: i18n-dev at openjdk.java.net > Subject: Review Request : JDK-8066652 : Default TimeZone is GMT > not local if user.timezone is invalid on Mac OS > > Hi, > > Please review the fix for JDK-8066652. > > Bug : https://bugs.openjdk.java.net/browse/JDK-8066652 > > Webrev: http://cr.openjdk.java.net/~rgoel/JDK-8066652/webrev.01/ > > Fix : 1. Used thread safe function localtime_r() to retrieve system > timezone. > 2. timezone retrieved should be "GMT" if system timezone is > "GMT" and user specifies a fake timezone using user.timezone system > property. > Earlier it used to be "GMT+00:00" which is wrong. > > -- > Thanks, > Rachna From rachna.goel at oracle.com Sun Jul 31 17:46:59 2016 From: rachna.goel at oracle.com (Rachna Goel) Date: Sun, 31 Jul 2016 23:16:59 +0530 Subject: Review Request : JDK-8066652 : Default TimeZone is GMT not local if user.timezone is invalid on Mac OS In-Reply-To: <5acc8b7b9b9c4d9a821d24cc4003199b@DEWDFE13DE11.global.corp.sap> References: <66d02394-289b-5fe0-6d7c-b7a65d2491f7@oracle.com> <5acc8b7b9b9c4d9a821d24cc4003199b@DEWDFE13DE11.global.corp.sap> Message-ID: Hi, Thanks for the review. Please have a look at updated web rev at : http://cr.openjdk.java.net/~rgoel/JDK-8066652/webrev.02/ Thanks, Rachna > On Jul 29, 2016, at 4:35 PM, Langer, Christoph wrote: > > Hi Rachna, > > In general, the fix looks good to me. > > However, there are a few indentation flaws, in lines 830, 831 and 834 - 841. Please make sure you use 4 chars indentation. > And you should remove the blank between the cast to (time_t) and the variable in line 832. > > Also, please note that I'm no reviewer. > > Best regards, > Christoph > >> -----Original Message----- >> From: i18n-dev [mailto:i18n-dev-bounces at openjdk.java.net] On Behalf Of >> Rachna Goel >> Sent: Freitag, 29. Juli 2016 08:17 >> To: i18n-dev at openjdk.java.net >> Subject: Review Request : JDK-8066652 : Default TimeZone is GMT >> not local if user.timezone is invalid on Mac OS >> >> Hi, >> >> Please review the fix for JDK-8066652. >> >> Bug : https://bugs.openjdk.java.net/browse/JDK-8066652 >> >> Webrev: http://cr.openjdk.java.net/~rgoel/JDK-8066652/webrev.01/ >> >> Fix : 1. Used thread safe function localtime_r() to retrieve system >> timezone. >> 2. timezone retrieved should be "GMT" if system timezone is >> "GMT" and user specifies a fake timezone using user.timezone system >> property. >> Earlier it used to be "GMT+00:00" which is wrong. >> >> -- >> Thanks, >> Rachna > From christoph.langer at sap.com Sun Jul 31 21:40:55 2016 From: christoph.langer at sap.com (Langer, Christoph) Date: Sun, 31 Jul 2016 21:40:55 +0000 Subject: Review Request : JDK-8066652 : Default TimeZone is GMT not local if user.timezone is invalid on Mac OS In-Reply-To: References: <66d02394-289b-5fe0-6d7c-b7a65d2491f7@oracle.com> <5acc8b7b9b9c4d9a821d24cc4003199b@DEWDFE13DE11.global.corp.sap> Message-ID: <00c25acdf99440609c3d10ee426dede7@DEWDFE13DE11.global.corp.sap> Thanks Rachna, that's fine now :) > -----Original Message----- > From: i18n-dev [mailto:i18n-dev-bounces at openjdk.java.net] On Behalf Of > Rachna Goel > Sent: Sonntag, 31. Juli 2016 19:47 > To: i18n-dev at openjdk.java.net > Subject: Re: Review Request : JDK-8066652 : Default TimeZone is > GMT not local if user.timezone is invalid on Mac OS > > Hi, > > Thanks for the review. > Please have a look at updated web rev at : > > http://cr.openjdk.java.net/~rgoel/JDK-8066652/webrev.02/ > > > Thanks, > Rachna > > > On Jul 29, 2016, at 4:35 PM, Langer, Christoph > wrote: > > > > Hi Rachna, > > > > In general, the fix looks good to me. > > > > However, there are a few indentation flaws, in lines 830, 831 and 834 - 841. > Please make sure you use 4 chars indentation. > > And you should remove the blank between the cast to (time_t) and the > variable in line 832. > > > > Also, please note that I'm no reviewer. > > > > Best regards, > > Christoph > > > >> -----Original Message----- > >> From: i18n-dev [mailto:i18n-dev-bounces at openjdk.java.net] On Behalf Of > >> Rachna Goel > >> Sent: Freitag, 29. Juli 2016 08:17 > >> To: i18n-dev at openjdk.java.net > >> Subject: Review Request : JDK-8066652 : Default TimeZone is > GMT > >> not local if user.timezone is invalid on Mac OS > >> > >> Hi, > >> > >> Please review the fix for JDK-8066652. > >> > >> Bug : https://bugs.openjdk.java.net/browse/JDK-8066652 > >> > >> Webrev: http://cr.openjdk.java.net/~rgoel/JDK-8066652/webrev.01/ > >> > >> Fix : 1. Used thread safe function localtime_r() to retrieve system > >> timezone. > >> 2. timezone retrieved should be "GMT" if system timezone is > >> "GMT" and user specifies a fake timezone using user.timezone system > >> property. > >> Earlier it used to be "GMT+00:00" which is wrong. > >> > >> -- > >> Thanks, > >> Rachna > >