After talking with several people (Doug Lea, Josh Bloch), I have
tentatively decided to try supporting Goal 2 (making things easier
for people writing optimizing JVM), and not supporting Goal 1 (making
the existing StringBuffer and String code thread safe).
Of course, in order to do this, we must be able to do so without a
noticeable performance penalty. Disallowing the existing code will
mean that a copy of the character array will have to be made when a
StringBuffer is converted into a String.
There are three steps to this:
* Try the simple, naive fix and see what the performance impact is. Obviously,
we will try both Spec JVM98 and Spec JBB. Any other suggestions? As we move
further down the line, we will be trying some of Sun's internal benchmarks,
but it would be nice to have some open benchmarks to start with.
* Look at introducing a new unsynchronized string buffer class and changing
javac to use the new class (and a couple of other improvements, to do things
like minimize the number of times the unsynchronized string buffer
is resized.
Although it would effect only newly compiled code, I suspect we could get
enough performance gains to overcome any loss from the copying.
* Investigate JVM transformations that, when a StringBuffer was thread local,
could use the unsynchronized version and eliminate the copy of the
character array.
We will be investigating all three of these. Anyone else who wants to
get involved, let us know.
Bill
At 12:07 PM -0500 4/4/02, Bill Pugh wrote:
>OK, we have figured out that two of the goals for the Java memory
>model are mutually exclusive in any reasonable memory model
>
>* Goal 1: Make the existing Sun JDK code for StringBuffers and String thread
> safe by changing the fields of String to final. In the existing code,
> all StringBuffer methods are synchronized, and there is a boolean
> that says whether the backing char[] is read only. When a StringBuffer
> is turned into a String, the String reuses the existing char [],
> but the StringBuffer now knows that the char[] is read only, and
> does a copy on write if needed.
>
>* Goal 2: Allow the compiler to do standard compiler optimization techniques.
>
> Specifically, the compiler should be able to transform:
>
>
> Point p1 = Foo.p;
> int x1 = p1.x;
> Point p2 = Foo.p;
> if (p1 == p2) {
> int x2 = p2.x;
> ...
> }
>
> into
>
> Point p1 = Foo.p;
> int x1 = p1.x;
> Point p2 = Foo.p;
> if (p1 == p2) {
> int x2 = x1;
> ...
> }
>
> More generally, assume that within a thread there are
> two reads, r1 and r2, of the same variable v (i.e., reads of the same
> heap memory location; a field or an array element). Unless
>there is some
> kind of synchronization between r1 and r2 that would force v to be
> reloaded, Cliff wants full freedom to reuse the value of r1 for the
> value of r2. Since synchronization never forces a final field to be
> reloaded, he should always be able to do this reuse of v is final.
-------------------------------
JavaMemoryModel mailing list - http://www.cs.umd.edu/~pugh/java/memoryModel
This archive was generated by hypermail 2b29 : Thu Oct 13 2005 - 07:00:39 EDT