[MUD-Dev] [TECH] String Classes, Memory Management, and Fragm entation

[Daniel.Harman at barclayscapital.com]

> -----Original Message-----
> From: Adam Martin [mailto:amsm2 at cam.ac.uk]
> ----- Original Message -----
> From: <Daniel.Harman at barclayscapital.com>

>> In java at least you shouldn't reuse the Stringbuffer objects
>> either. If I recall correctly, Java Stringbuffers grow, but they
>> don't shrink :) This is a real problem if you are using a string
>> buffer that has grown a lot, as when you copy it to a string, it
>> copies the whole buffer, not just the bit you think is
>> populates. You then end up with some very large padded strings.
>> So you end up having to create lots of string buffer objects,
>> which takes you back to the first problem I mentioned! (That last
>> bit about copying the whole buffer not just the data you think is
>> in it, I am 98% sure is accurate, but I don't have time to check
>> for now, and its how I remember it).

> Could you please explain that a bit further? I understand the
> problems with the immutable String objects w.r.t GC, but I'd not
> noticed problems with StringBuffer's, and I can't understand how
> what you describe would work?

> The bit in particular where you say "as when you copy it to a
> string, it copies the whole buffer, not just the bit you think it
> populates. You then end up with some very large padded strings." -
> Surely, if the resulting String is any larger than it should be,
> then it will not be the correct String, and the result is
> incorrect?

> Sorry if I'm missing something obvious!

Well my point was a little confused as I couldn't quite remember
what I was talking about. It comes down to the fact that you can't
shrink a StringBuffer, this in conjunction with both Strings and
StringBuffers having reference counted char arrays that contain the
actual data can lead you into a messy situation. Let me copy the
example from the book and at a few more comments :

  // Assume buffer is a previously instantiated string buffer of size 5000
  
  String s1 = buffer.toString();      // s1 and buffer now share the same char
  array
                                      // - this saves on a copy. They just up
  the ref count
                                      // of the array.
  
  // Now we want to reuse the buffer for something else. So we set
  // the buffers length to 0
  
  buffer.setLength( 0 );              // We now have two buffers of size 5000.
  One referenced
                                      // by s1 and one referenced by buffer.
  Remember StringBuffers
                                      // don't ever shrink.
  
  // Now put a few characters into the buffer
  
  buffer.append( "cat" );
  buffer.append( "dog" );
  
  // put the buffer into a new string
  
  String s2 = buffer.toString();
  
  // now as soon as you reassign or change buffer you s2 gets left
  // with the 5000 char array...
  
  buffer.setLength( 0 );
  
  // uh oh we now have 3 x 5000 char arrays.
  
Anyway the book goes on to say the moral of the story is to not
reuse string buffers because both they and strings reference hidden
character buffers.
  
The book I'm referencing is 'Java 2 performance and idiom guide' by
Craig Larman and Rhett Guthrie.
  
Sorry if this isn't clear - I'm a bit rushed at the moment as its
lunch break from a C# course :)
  
Oh, as an aside, Kwon mentions using s1 = buffer.subString(0, len )
as a way of forcing the creation of a new correctly sized character
array for s1. At least thats how I understood it.
  
Dan
  
_______________________________________________
MUD-Dev mailing list
MUD-Dev at kanga.nu
https://www.kanga.nu/lists/listinfo/mud-dev