JDK-4294620 : improve performance in string classes by removing unnecessary synchronizations
  • Type: Enhancement
  • Component: core-libs
  • Sub-Component: java.lang
  • Affected Version: 1.3.0,1.3.1,1.4.0
  • Priority: P4
  • Status: Closed
  • Resolution: Duplicate
  • OS: generic
  • CPU: generic
  • Submitted: 1999-11-25
  • Updated: 2003-02-14
  • Resolved: 2003-02-14
Related Reports
Duplicate :  
Description

Name: ml70278			Date: 11/24/99


To improve performance in string classes, we will recommend to remove 
unnecessary synchronizations. For instance, the processing of "a" +"b" + "c" 
uses 3 synchronizations in Java2. In this example, none is really required. 

======================================================================

Name: yyT116575			Date: 05/24/2001


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


StringBuffer (as documented in the API docs) uses a dumb space optimization, a simple copy-on-write form which allows a String to be efficiently constructed from a StringBuffer.  Unfortunately this makes many StringBuffer operations require synchronization to avoid corrupting Strings, and as a consequence StringBuffer is slow in all applications in which I've tested it compared to a simplified version which does not use the sharing flag.
(Review ID: 125011)
======================================================================

Name: krC82822			Date: 07/30/2001


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


StringBuffer is a very useful class but it is not as fast as it could be because
it sacrifices speed for safety, security and ease of use, e.g. it is
synchronized and a reference to the internal array cannot be retrieved, you can
only get a copy of it and it is final so cannot be extended.

It would be really nice if there was another class, e.g. FastStringBuffer which
sacrificed ease of use and safety for speed, e.g. it would be unsynchronized,
a reference to the internal array would be available and it would not be final.
(Review ID: 129054)
======================================================================

Comments
EVALUATION As reported, this is really a compiler issue, but, since the compiler relies on StringBuffer.Append and the like, the library changes are needed. william.maddox@Eng 1999-12-17 Need a discussion with the Hotspot group as to which synchronizations can be automatically detected by Hotspot. david.biagini@Eng 2000-01-13 Work is being contemplated for Merlin that would improve this situation. michael.mccloskey@eng 2000-03-27
13-01-2000