Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.java.programmer > #22042

Re: String.substring in JDK 1.7.0_6+

Show all headers | View raw

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/

Back to comp.lang.java.programmer | Previous | Next — Previous in thread | Find similar | Unroll thread

Thread

String.substring in JDK 1.7.0_6+ jlp <jlp@jlp.com> - 2013-02-01 19:33 +0100
  Re: String.substring in JDK 1.7.0_6+ markspace <markspace@nospam.nospam> - 2013-02-01 10:38 -0800
    Re: String.substring in JDK 1.7.0_6+ jlp <jlp@jlp.com> - 2013-02-01 19:42 +0100
      Re: String.substring in JDK 1.7.0_6+ markspace <markspace@nospam.nospam> - 2013-02-01 10:45 -0800
        Re: String.substring in JDK 1.7.0_6+ jlp <jlp@jlp.com> - 2013-02-01 19:57 +0100
          Re: String.substring in JDK 1.7.0_6+ markspace <markspace@nospam.nospam> - 2013-02-01 11:20 -0800
  Re: String.substring in JDK 1.7.0_6+ Jan Burse <janburse@fastmail.fm> - 2013-02-01 20:34 +0100
  Re: String.substring in JDK 1.7.0_6+ Kevin McMurtrie <mcmurtrie@pixelmemory.us> - 2013-02-01 20:58 -0800
    Re: String.substring in JDK 1.7.0_6+ markspace <markspace@nospam.nospam> - 2013-02-01 22:55 -0800
      Re: String.substring in JDK 1.7.0_6+ Kevin McMurtrie <mcmurtrie@pixelmemory.us> - 2013-02-02 08:43 -0800
        Re: String.substring in JDK 1.7.0_6+ markspace <markspace@nospam.nospam> - 2013-02-02 10:56 -0800
          Re: String.substring in JDK 1.7.0_6+ Kevin McMurtrie <mcmurtrie@pixelmemory.us> - 2013-02-02 14:46 -0800
            Re: String.substring in JDK 1.7.0_6+ markspace <markspace@nospam.nospam> - 2013-02-02 15:31 -0800
            Re: String.substring in JDK 1.7.0_6+ Robert Klemme <shortcutter@googlemail.com> - 2013-02-03 15:09 +0100

csiph-web