Name: krC82822 Date: 05/23/2001


java version "1.3.0"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.3.0-C)
Java HotSpot(TM) Client VM (build 1.3.0-C, mixed mode)

This problem is similar to 4165204 which has been reported fixed. However this
problem still persists in the most recent JDK.

The basic problem is that ObjectStreamClass.lookupInternal has a global
synchronization lock. This lock is contended upon by all threads doing
serialization. On a multi-cpu machine this can be a big performance issue.

Compounding the issue is the amount of time spent within the critical section
guarded by the above synchronization lock. The lock guards a cache implemented
as a hashtable of ObjectStreamClass objects keyed by Class. The hashtable uses
chaining to resolve collisions. The chains are constructed with SoftReferences
to allow collection when a low memory condition is encountered. The hashtable
has no rehash mechanism. As the hashtable does not resize the chains can grow
quite long requiring linear search. Additionally since the chains are
implemented with SoftReferences this traversal is quite a bit more expensive
than it would otherwise be. Finally all of this is implemented against non-
final and static variables which are quite a bit slower to access on most VMs
than are final or instance variables.

The most unfortunate thing about this is that because there is no rehashing and
because the chaining is implemented as a linked list and is updated in an
atomic manner reads needn't contend with writes to the cache. If the
sychronization was removed from lookupInternal and moved to insertDescriptorFor
the system would still be correct and would be much more efficient. On
occasion a duplicate ObjectStreamClass object would be instantiated only to be
thrown away by the check in insertDescriptor for (which currently adds a third
hashtable lookup to the insert path, but could be implemented such that it
didn't), but the class would still operate correctly and would not exhibit
nearly as much contention.
(Review ID: 124078)
======================================================================