----- Original Message -----
> >> 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?
> > IMHO we should try to fix the problem in GNU Classpath.
> > I think that we should also try to send all changes that we need to
> > make
> > against GNU Classpath to the GNU Classpath developers. If we get
> > our
> > fixes included, we can remove the patches for the fix with the next
> > classpath release. This keeps our patch sets small.
> > Moreover, all of Classpath's clients (e.g. Jato VM, Kaffe) will
> > profit
> > from the fixes.
> yes, fixing Classpath is the right thing to do. The big fix (caching
> least the zoneStrings), however, requires somewhat larger changes to
> I did come up with two patches to do just that (one patch sets the
> by refactoring DateFormatSymbols, the other implements the actual
> caching), but would really like someone from the Classpath team to
> a look as my implementation of a cache is rather naive; in
> entries don't expire and there's synchronization rather than a
> ConcurrentHashMap. But maybe there's already an established coding
> pattern for caches in Classpath that I simply don't know about.
> Andii, can you have a look at the attached two patches? Also, there's
> one further issue: Shouldn't DateFormatSymbols.getZoneStrings copy
> array before passing it to the outside world? (At least OpenJDK does
> That being said, a small fix (caching the compiled Pattern instances)
> has already been submitted to the Classpath bug tracker:
> <http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53171>. This already
> improves performance of the 2006-10-MR2 luindex by more than 2% on
> Classpath 0.99.
This class is turning into something of a nightmare...
The reason there are now lists of bundles was due to a fix I added in 0.99.
Prior to that, the names of the days and months were incomplete for a number
of locales because it would just try and use the most specific one, leading to
undersized arrays containing just one or two names which were translated for
a specific locale. I did spot that zone names was already doing something
similar but didn't get chance to refactor it. As that's basically what your
first patch does, it looks ok.
It also finds another bug:
ResourceBundle res = bundles.get(bundles.size() - 1); // TODO Least specific bundle. Correct?
This is what the current logic does, but it's incorrect. It looks like there's
a regression in 0.99 that means that all locales now get the same date/time formats e.g.
-Date formats: [yyyy年M月d日EEEE, yyyy年M月d日, yyyy-M-d, yy-M-d]
-Time formats: [zah时mm分ss秒, zah时mm分ss秒, ah:mm:ss, ah:mm]
+Date formats: [EEEE, yyyy MMMM dd, yyyy MMMM d, yyyy MMM d, yyyy-MM-dd]
+Time formats: [HH:mm:ss z, HH:mm:ss z, HH:mm:ss, HH:mm]
Top is from gij 4.7 which still uses 0.98, and the bottom is 0.99. So that needs fixing also.
I'm thinking of adding a more extensive fix:
1. Use Pattern.compile and Pattern.split rather than String.split (the patch on that bug)
2. Replace the lookup for dateFormats/timeFormats/localPatternChars so they also use bundles
(we're missing a getString equivalent of getStringArray/getZoneStrings).
3. Add a cache for system locale data (i.e. not just zone names, but the other strings too)
and copy over the arrays to new instances. (an extension of the two patches here)
Let me know what you think. I'll commit the regex patch (1) now.
> Together, these patches improve luindex performance of GNU Classpath
> 0.99 *over* version 0.97 by more than 7%. (This also highlights that
> having a common class library, i.e., OpenJDK is really desirable from
> scientific evaluation point of view.)
GNU Classpath was the common class library for many VMs prior to OpenJDK.
> Best wishes,
Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)
PGP Key: 248BDC07 (https://keys.indymedia.org/)
Fingerprint = EC5A 1F5E C0AD 1D15 8F1F 8F91 3B96 A578 248B DC07