JDK-4965694 : Too many char[] allocations with sun.text.resources.LocaleElements
  • Type: Bug
  • Component: core-libs
  • Sub-Component: java.util:i18n
  • Affected Version: 5.0
  • Priority: P4
  • Status: Closed
  • Resolution: Cannot Reproduce
  • OS: solaris_8
  • CPU: sparc
  • Submitted: 2003-12-09
  • Updated: 2006-07-12
  • Resolved: 2006-07-12
Related Reports
Relates :  
JDK-5013088 - Restructure java.text and java.util locale data
Relates :  
JDK-4969995 - [Fmt-Nu] NumberFormat.setMaximumFractionDigits set to Integer.MAX_VALUE causes mem. leak
Description
Recently we integrated xsltc into Tiger and some of our tests throw OutOfMemory
error. I profiled the test using OptimizeIt and have found that sun.text.resources.LocaleElements.java has 887 allocations which is 38.24% of the allocations of the 2319 char[] allocations . The source code history shows that that bug 4819436  was fixed and integrated in tiger-beta b28. I am attaching the profiled information. This seems like a bug in the getContents().

http://javaweb.sfbay.sun.com/~bhakti/jaxp/data.html
Filing the bug as per discussion with Yuka.

===

Hi:
  Santiago narrowed down the problem to java.text.DecimalFormat class with a test program. He was able to reproduce the problem with small program. I am attaching that test program and raising priority to P2. Please change sub-category if needed.

-Ramesh
Comments
EVALUATION I have received no information from the submitter till now. I take that as the problem is no longer reproducible with Mustang.
12-07-2006
EVALUATION Name: nl37777 Date: 12/09/2003 The first time any locale dependent functionality in java.text or java.util is used, the complete LocaleElements for at least the root locale are loaded. These include the names of all countries and of all languages that have an ISO 639 two-letter code. Since these names are used much less often than, say, date and number formats, it might make sense to move them into a separate resource bundle. The bundle could be named sun.util.resources.LocaleNames. ====================================================================== Whenever LocaleElements.getContents method is called the 2 dimentional Char array which takes up lot of memory is created. This method is not a static method and also the Object[][] , so in the same VM multiple instances of the 2 dimentional array can exist. So this is serious problem. JAXP testsuite is not getting fully run because of this problem. We request you to consider this as a priority issue and provide fix for this asap. This is definitely P2 bug for us. For additional info please see Optimizeit log produced by Bhakti at http://javaweb.sfbay.sun.com/~bhakti/jaxp/data.html ###@###.### 2003-12-10 Santiago narrowed down the problem with small test program and is able to reproduce all the time. The problem turns out to be in java.text.DecimalFormat. Attaching test program developed by Santiago to the bug report. Please feel free to change subcategory. ###@###.### 2003-12-17 In Tiger, about 80 two-dimentional char arrays have been added to LocaleElements as language/country names. They should be put in separate resource bundle as the first evaluator said. Will fix in the next major update release. The bug in DecimalFormat is a different problem and is treated as 4969995. The attached test program is for 4969995. ###@###.### 2004-01-06 The locale data structure has been changed (cf. 5013088 Restructure java.text and java.util locale data), so those language and country names are no more allocated as string arrays in Mustang. Please let me know if there is still excess memory consumption in the locale data. ###@###.### 2005-07-21 00:37:54 GMT
21-07-2005