Renamed "symbols" to "internalized strings" throughout the code base,

Renamed "symbols" to "internalized strings" throughout the code base,
in preparation of the introduction of ES6 'symbols' (aka private/unique names).

The SymbolTable became the StringTable. I also made sure to adapt all comments. The only remaining use of the term "symbol" (other than unrelated uses in the parser and such) is now 'NewSymbol' in the API and the 'V8.KeyedLoadGenericSymbol' counter, changing which might break embedders.

The one functional change in this CL is that I removed the former 'empty_string' constant, since it is redundant given the 'empty_symbol' constant that we also had (and both were used inconsistently).

R=yangguo@chromium.org
BUG=

Committed: http://code.google.com/p/v8/source/detail?r=13781

[Yang, 2013-02-11 12:26:36]

I don't feel too strongly about this, but I'd prefer not omitting "string" from
"internalized string", for example in StringShape::IsInternalized,
kIsInternalizedMask and kIsInternalizedTag.

Missing renames in:
- v8-counters.h
- ast.h (comments)
- v8.h and api.cc, but I guess there is not much we can do without changing the
API
- d8.cc
- json-parser.h

I don't think gdb-jit.cc needs to be changed as the notion of symbol there is
not in V8's context.

https://codereview.chromium.org/12210083/diff/1/src/arm/code-stubs-arm.cc
File src/arm/code-stubs-arm.cc (right):

https://codereview.chromium.org/12210083/diff/1/src/arm/code-stubs-arm.cc#new...
src/arm/code-stubs-arm.cc:1750: // We could be strict about internalized/string
here, but as long as
suggest to change to "... about internatilized/non-internalized string here..."

https://codereview.chromium.org/12210083/diff/1/src/arm/ic-arm.cc
File src/arm/ic-arm.cc (right):

https://codereview.chromium.org/12210083/diff/1/src/arm/ic-arm.cc#newcode1076
src/arm/ic-arm.cc:1076: isolate->counters()->keyed_load_generic_symbol(), 1, r2,
r3);
forgot to change this?

https://codereview.chromium.org/12210083/diff/1/src/bootstrapper.cc
File src/bootstrapper.cc (right):

https://codereview.chromium.org/12210083/diff/1/src/bootstrapper.cc#newcode1393
src/bootstrapper.cc:1393:
factory()->InternalizeOneByteString(STATIC_ASCII_VECTOR(name));          \
You could re-align this new-line escape :)

https://codereview.chromium.org/12210083/diff/1/src/gdb-jit.cc
File src/gdb-jit.cc (right):

https://codereview.chromium.org/12210083/diff/1/src/gdb-jit.cc#newcode855
src/gdb-jit.cc:855: class ELFStringTable : public ELFSection {
I was thinking that this use of "symbol" has nothing to do with V8... and you
didn't change the ELFSymbol class, so changing this here makes little sense.

https://codereview.chromium.org/12210083/diff/1/src/objects.h
File src/objects.h (right):

https://codereview.chromium.org/12210083/diff/1/src/objects.h#newcode410
src/objects.h:410: V(EXTERNAL_INTERNALIZED_STRING_TYPE,                         
               \
sort of funny... :)

[rossberg, 2013-02-11 13:30:16]

Thanks for taking the pain. :)

On 2013/02/11 12:26:36, Yang wrote:
> I don't feel too strongly about this, but I'd prefer not omitting "string"
from
> "internalized string", for example in StringShape::IsInternalized,
> kIsInternalizedMask and kIsInternalizedTag.

This is the only place where I omitted it, because it's an additional attribute
bit that augments an instance_type that already denotes a string.

> Missing renames in:
> - v8.h and api.cc, but I guess there is not much we can do without changing
the
> API

Yes, unfortunately.

> - v8-counters.h

As discussed off-line, this was intentional, as mentioned in the change
description. It is visible externally and also corresponds to the API
terminology we cannot change.

> - ast.h (comments)

Intentional: this actually refers to parsing symbols, not internalized strings.

> - d8.cc

Intentional, as this is implemented purely on top of the API, which still uses
the Symbol terminology.

> - json-parser.h

Done. (I thought this is about symbols in the parsing sense, but you are right,
it isn't).

> I don't think gdb-jit.cc needs to be changed as the notion of symbol there is
> not in V8's context.

Right, reverted.

https://codereview.chromium.org/12210083/diff/1/src/arm/code-stubs-arm.cc
File src/arm/code-stubs-arm.cc (right):

https://codereview.chromium.org/12210083/diff/1/src/arm/code-stubs-arm.cc#new...
src/arm/code-stubs-arm.cc:1750: // We could be strict about internalized/string
here, but as long as
On 2013/02/11 12:26:36, Yang wrote:
> suggest to change to "... about internatilized/non-internalized string
here..."

Done.

https://codereview.chromium.org/12210083/diff/1/src/arm/ic-arm.cc
File src/arm/ic-arm.cc (right):

https://codereview.chromium.org/12210083/diff/1/src/arm/ic-arm.cc#newcode1076
src/arm/ic-arm.cc:1076: isolate->counters()->keyed_load_generic_symbol(), 1, r2,
r3);
On 2013/02/11 12:26:36, Yang wrote:
> forgot to change this?

Intentional, see above.

https://codereview.chromium.org/12210083/diff/1/src/bootstrapper.cc
File src/bootstrapper.cc (right):

https://codereview.chromium.org/12210083/diff/1/src/bootstrapper.cc#newcode1393
src/bootstrapper.cc:1393:
factory()->InternalizeOneByteString(STATIC_ASCII_VECTOR(name));          \
On 2013/02/11 12:26:36, Yang wrote:
> You could re-align this new-line escape :)

Oops, done.

https://codereview.chromium.org/12210083/diff/1/src/gdb-jit.cc
File src/gdb-jit.cc (right):

https://codereview.chromium.org/12210083/diff/1/src/gdb-jit.cc#newcode855
src/gdb-jit.cc:855: class ELFStringTable : public ELFSection {
On 2013/02/11 12:26:36, Yang wrote:
> I was thinking that this use of "symbol" has nothing to do with V8... and you
> didn't change the ELFSymbol class, so changing this here makes little sense.

Indeed, reverted.

[Yang, 2013-02-11 13:31:20]

On 2013/02/11 13:30:16, rossberg wrote:
> Thanks for taking the pain. :)
> 
> On 2013/02/11 12:26:36, Yang wrote:
> > I don't feel too strongly about this, but I'd prefer not omitting "string"
> from
> > "internalized string", for example in StringShape::IsInternalized,
> > kIsInternalizedMask and kIsInternalizedTag.
> 
> This is the only place where I omitted it, because it's an additional
attribute
> bit that augments an instance_type that already denotes a string.
> 
> > Missing renames in:
> > - v8.h and api.cc, but I guess there is not much we can do without changing
> the
> > API
> 
> Yes, unfortunately.
> 
> > - v8-counters.h
> 
> As discussed off-line, this was intentional, as mentioned in the change
> description. It is visible externally and also corresponds to the API
> terminology we cannot change.
> 
> > - ast.h (comments)
> 
> Intentional: this actually refers to parsing symbols, not internalized
strings.
> 
> > - d8.cc
> 
> Intentional, as this is implemented purely on top of the API, which still uses
> the Symbol terminology.
> 
> > - json-parser.h
> 
> Done. (I thought this is about symbols in the parsing sense, but you are
right,
> it isn't).
> 
> > I don't think gdb-jit.cc needs to be changed as the notion of symbol there
is
> > not in V8's context.
> 
> Right, reverted.
> 
> https://codereview.chromium.org/12210083/diff/1/src/arm/code-stubs-arm.cc
> File src/arm/code-stubs-arm.cc (right):
> 
>
https://codereview.chromium.org/12210083/diff/1/src/arm/code-stubs-arm.cc#new...
> src/arm/code-stubs-arm.cc:1750: // We could be strict about
internalized/string
> here, but as long as
> On 2013/02/11 12:26:36, Yang wrote:
> > suggest to change to "... about internatilized/non-internalized string
> here..."
> 
> Done.
> 
> https://codereview.chromium.org/12210083/diff/1/src/arm/ic-arm.cc
> File src/arm/ic-arm.cc (right):
> 
> https://codereview.chromium.org/12210083/diff/1/src/arm/ic-arm.cc#newcode1076
> src/arm/ic-arm.cc:1076: isolate->counters()->keyed_load_generic_symbol(), 1,
r2,
> r3);
> On 2013/02/11 12:26:36, Yang wrote:
> > forgot to change this?
> 
> Intentional, see above.
> 
> https://codereview.chromium.org/12210083/diff/1/src/bootstrapper.cc
> File src/bootstrapper.cc (right):
> 
>
https://codereview.chromium.org/12210083/diff/1/src/bootstrapper.cc#newcode1393
> src/bootstrapper.cc:1393:
> factory()->InternalizeOneByteString(STATIC_ASCII_VECTOR(name));          \
> On 2013/02/11 12:26:36, Yang wrote:
> > You could re-align this new-line escape :)
> 
> Oops, done.
> 
> https://codereview.chromium.org/12210083/diff/1/src/gdb-jit.cc
> File src/gdb-jit.cc (right):
> 
> https://codereview.chromium.org/12210083/diff/1/src/gdb-jit.cc#newcode855
> src/gdb-jit.cc:855: class ELFStringTable : public ELFSection {
> On 2013/02/11 12:26:36, Yang wrote:
> > I was thinking that this use of "symbol" has nothing to do with V8... and
you
> > didn't change the ELFSymbol class, so changing this here makes little sense.
> 
> Indeed, reverted.

LGTM.