Re: [rvm-core] Updating to GNU Classpath 0.99?

[Andreas S. <se...@st...>]

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