From: Andreas S. <se...@st...> - 2012-04-28 20:06:10
|
Hi all, I wrote: > And [DateFormatSymbols's] constructor has indeed changed between 0.97.2 and 0.99. It has > not changed substantially between 0.97.2 and 0.98, however, although > DateFormatSymbols did experience some other changes back than, so it > still seems like a likely suspect to me. > > Will dig some further, but not today anymore... Hit the treasure chest! Although it didn't quite contain what I expected... While DateFormatSymbols and friends have indeed undergone some changes between 0.97.2 and 0.99, these changes are not the primary cause of the observed performance regression. Its cause is much simpler -- and unfortunately also much less obvious for someone focused on code and compiler optimizations. :-( DateFormatSymbols.getZoneStrings splits the "zoneStrings" value found in the locale-appropriate gnu.java.locale.LocaleInformation ResourceBundle (FYI, DaCapo 2006-10-MR2 runs under a "en_US" locale). And for the "en" locale the "timeZone" value has significantly increased in both length and number of elements since the 0.97.2 release with the switch to CLDR 1.5.1 and 1.6.0 data, respectively. (See <http://git.savannah.gnu.org/cgit/classpath.git/log/resource/gnu/java/locale/LocaleInformation_en.properties>.) Reverting this property file to its 0.97.2 state fixes the performance problem. However, it's not clear whether this is the right thing to do. @Andii: Do you know whether the list of timezones a JRE is supposed to recognize is spelled out somewhere? in other words: Are we cheating if we use a shorter list? Anyways, I think there are two ways forward for Jikes RVM: 1.) Update to Classpath 0.99 with the 0.97.2 zone strings. 2.) Fix DateFormatSymbols in Classpath to cache the split "zoneStrings" value. (This could even improve performance above what option 1 offers.) Thoughts? Best wishes, Andreas |