JDK-5056445 : improve static cache performance by using ConcurrentHashMap
  • Type: Enhancement
  • Component: core-libs
  • Sub-Component: java.io:serialization
  • Affected Version: 5.0
  • Priority: P4
  • Status: Resolved
  • Resolution: Fixed
  • OS: generic
  • CPU: generic
  • Submitted: 2004-06-02
  • Updated: 2005-11-30
  • Resolved: 2005-09-20
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
Other JDK 6
5.0u7Fixed 6 betaFixed
Description
From http://www.theserverside.com/news/thread.tss?thread_id=25538:

> I ran into scalability problems with Object streams when writing a custom
> transport for JBoss. It boils down to some static variables being
> synchronized within java.io.ObjectStreamClass
>
>     /** cache mapping local classes -> descriptors */
>     private static final SoftCache localDescs = new SoftCache(10);
>     /** cache mapping field group/local desc pairs -> field reflectors */
>     private static final SoftCache reflectors = new SoftCache(10);
>
> I walked through some hoops to change the use of SoftCache to a
> ConcurrentReaderHashMap and throughput started increasing 20-40% depending on
> how many threads you run through

Now that ConcurrentHashMap is part of the JDK, this change can be considered
for serialization.
Comments
EVALUATION This suggestion could be worthwhile if it indeed yields the claimed performance gain. A few changes would be necessary to the serialization code that deals with the localDescs and reflectors fields: - Values (class descriptors) placed in the ConcurrentHashMap would need to be held by soft references, and the corresponding entries cleared upon expiration of the soft references. This could be handled by a wrapper class around ConcurrentHashMap, similar to the way that SoftCache wraps around an underlying HashMap. One might even envision modifying SoftCache to accept a caller-specified underlying Map implementation, except that it might also need to provide access to ConcurrentMap operations (see next item). - The idiom used by the current serialization code of calling get() followed by put() inside of a synchronized block would need to be reworked to use ConcurrentMap operations (most likely, putIfAbsent()). ###@###.### 2004-06-02
02-06-2004