> * 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.
An unsynchronized string buffer would be useful on its own.
See this technical article "65% Faster Java(tm) String Buffer Implementation"
http://dsportal.eservices.hp.com/dspp/tech/tech_TechDocumentDetailPage_IDX/1,1701,2488,00.html
Btw, I am not sure if this string problem is such a big deal.
On architectures where an optimization that would cause string to fail,
I would imagine the optimization would be 'fixed' so strings do not fail.
Also, refresh my memory about how should we write immutable object source
codes now? (under the new memory model)
Regards.
-Thomas Wang
wang@cup.hp.com
-------------------------------
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