The purpose of internalized strings is to have a canonical, unique
representation of a string. So yes if strings are internalized that
are duplicates of already internalized values, we "throw away"/discard that
duplicate and point them to the unique string instead (i.e. the string
becomes a ThinString).
If you want to take ownership of the buffer of an internalized string, you
can by externalizing the internalized string (as opposed to internalizing
an external string).
Maybe you can tell us what your intent is? Because you mentioned "add some
external data to x" I am not sure if external strings are really what you
are looking for. The purpose of external strings is only to allow embedders
to have ownership of the string buffer, not to attach arbitrary data to
strings.
On Mon, Apr 17, 2023 at 4:30 PM Bruce MacNaughton <bmacnaugh...@gmail.com>
wrote:
> "(either one or two byte) because defaulting to throw away the external
> data" should be "(either one or two byte) BEFORE defaulting to throw away
> the external data"
>
> On Monday, April 17, 2023 at 7:12:19 AM UTC-7 Bruce MacNaughton wrote:
>
>> This is my first relatively deep dive into v8 strings; if I
>> misinterpreted what's going on, please correct me.
>>
>> When a string is used as a key:
>>
>> const x = 'xyzzy';
>> // add some external data to x
>> const obj = { [x]: 1234 };
>>
>> the external data is lost because StringTable:::LookupKey() finds an
>> entry (data->FindEntry()) and returns a Handle<String> to it. That String
>> is *not* internalized, so
>> String::MakeThin() is called on the original string (as 'this') with the
>> Handle<String> returned by FindEntry(). MakeThin() finds
>> this->IsExternalString() true so calls MigrateExternalString(),
>> internalized is *not* an External string, so FinalizeExternalString() is
>> called, discarding the external data.
>>
>> whew.
>>
>> It seems like, to propagate the external data that, in LookupString(), if
>> string->IsExternal() and !result->IsExternal() then result should be
>> reconstructed as an External string.
>>
>> It may be that the way it works is intended, but it's not clear because
>> MigrateExternalString() in string.cc checks to see if 'internalized' is an
>> external string (either one or two byte) because defaulting to throw away
>> the external data.
>>
>> But maybe there are considerations with the shared heap that I have yet
>> to understand.
>>
>> Basic question: is this is a bug or intentional design?
>>
>>
>> --
> --
> v8-users mailing list
> v8-users@googlegroups.com
> http://groups.google.com/group/v8-users
> ---
> You received this message because you are subscribed to the Google Groups
> "v8-users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to v8-users+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/v8-users/e88c1553-4a78-435f-bc75-cc42f0b3f147n%40googlegroups.com
> <https://groups.google.com/d/msgid/v8-users/e88c1553-4a78-435f-bc75-cc42f0b3f147n%40googlegroups.com?utm_medium=email&utm_source=footer>
> .
>
--
--
v8-users mailing list
v8-users@googlegroups.com
http://groups.google.com/group/v8-users
---
You received this message because you are subscribed to the Google Groups
"v8-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to v8-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/v8-users/CAKhjTa_g29udODmNn8MkP6xXKQU1WcHzJ4mkO1jz0bdzgX7d3g%40mail.gmail.com.
