Re: String.substring in JDK 1.7.0_6+
On 02.02.2013 23:46, Kevin McMurtrie wrote:
The original StringBuffer went to copy-on-write mode after calling
toString(). You can go read the old code for yourself. There was no
JVM trick involved.
Exactly.
Some future JVMs do have JIT tricks to improve String performance.
Even todays JVMs have vastly changed GC behavior vs. Java 1.4. From a
GC point of view the changed behavior might actually be advantageous
because a StringBuilder and StringBuffer are typically short lived
objects (i.e. used to create a String) and they as well as their
internal char[] will be collected quickly and with low overhead because
they usually never survive one young GC cycle. But the created String
might live longer and so it may actually make sense to have a char[] of
exactly the length needed for the String (vs. the char[] that was
allocated by the StringBuilder during construction which could be
significantly longer than the resulting String - especially if the
StringBuilder was used multiple times). If the String doesn't live
longer same reasoning as above applies - there is just a tad more
garbage created.
I have to say I trust engineers at Sun / Oracle to have done their
homework and measurements. I do not believe that these changes are done
so lightheartedly and so I also believe that there is not as much to
worry about as some debaters suggest.
It's
not clear how that would perform or what the side effects would be. One
proposed trick was to make the String(String) constructor a no-op. That
could have disastrous consequences. For example, the code below uses
specific object references as signals. If the String constructor was a
no-op, the signal references would be interned constants that are not
unique.
I believe it is a bad idea to use specific String objects for signaling.
An instance of Object is better IMHO. (Yeah, I know some nasty casts
will be needed. But at least you are sure that nothing weird happens
under the hood.)
Kind regards
robert
--
remember.guy do |as, often| as.you_can - without end
http://blog.rubybestpractices.com/