string sharing (possible bug?)

Blanchard, Tod tod.blanchard at kanisa.com
Thu Dec 10 01:01:39 UTC 1998


FWIW, C compilers can share string literals too and the exact same problem
can result.

void foo()
{
   char* b = "abc";
   printf("%s\n",b);
   b[1] = 'd';
}

void main()
{
   foo(); // prints abc
   foo(); // prints abd
}

Java also shares equivalent strings but lacks this problem because strings
are always immutable (mods produce new strings).

Todd Blanchard


> -----Original Message-----
> From:	glenn [SMTP:krasner at objectshare.com]
> Sent:	Wednesday, December 09, 1998 1:08 PM
> To:	squeak at cs.uiuc.edu
> Subject:	RE: string sharing (possible bug?)
> 
> At 03:04 PM 12/9/98 -0500, Adam P. Jenkins wrote:
> >> The problem is independent of duplication. Say you have a method that
> says
> >>
> >> foo
> >> 	| b |
> >> 	b := 'abc'.
> >> 	Transcript space; show: b.
> >> 	b at: 2 put: $d
> >>
> >> What prints the second time you send #foo? Because the literal (copied
> or
> >> not) is stored with the compiled method and not the activation, the
> second
> >> time aroud b is 'adc' even though it's right after the assignment
> >> of 'abc'.
> >
> >Yuck!  I assume from what you say below that this problem wouldn't occur
> >with VisualWorks.  Is that true?
> 
> No, the problem occurs. With VisualWorks 'abc' prints the first time and
> 'adc' prints the second time because the strings are generated at
> compile-time and are mutable.
> 
> >> For VisualWorks, we got rid of the sharing but not the mutability.
> >
> >This seems like the best solution to me.  I can't imagine that sharing is
> >useful very often.  How often are there really identical string or array
> >literals in the same method?  And in general a literal is going to be
> small,
> >since you have to type it in, so the memory savings by sharing are also
> >small.
> 
> Who says code has to be typed in? VisualWorks, for example, has a number
> of
> code-generating subsystems, and I wouldn't be surprised if there were many
> in Squeak land as well. In particular, our window painter produces
> representations of window layout that are encoded as literal arrays.
> 
> >The simplest method is to just create a new object every time a
> >literal is encountered.
> 
> And, for example in the case of our window builder, suffer a large
> performance penalty every time you open a window. And that penalty would
> be
> paid by everyone just so that the few people who accidentally store into a
> literal array or string would have a better time of it. That's not the
> tradeoff we decided to make, and I suspect that this would also be a worse
> choice for Squeak.
> 
> If this upsets your sensibilities ("Yuck" is a clue), I think you're more
> likely to find a better path by making immutability cheap in Squeak, than
> by removing compile-time literal construction.
> 
> >If a programmer wants them to be shared, they can
> >just do
> >
> >a := 'hello'.
> >b := a.
> >c := a.
> 
> Unlike compile-time object creation,I don't know of cases where sharing
> would be an important issue, although it may be my lack of imagination.
> 
> glenn
> 





More information about the Squeak-dev mailing list