Changes between Version 10 and Version 11 of EfficientStrings

Timestamp:

Dec 18, 2018, 1:57:24 PM (6 years ago)

Author:

Konstantin Tokarev

Comment:

Added clarification, what are (some of) "special considerations" of cross-thread usage of AtomicString

EfficientStrings

@@ -91 +91 @@
 * It’s very inexpensive to compare one atomic string with another. The cost is just a pointer comparison. The actual string length and data don’t need to be compared, because on any one thread no AtomicString can be equal to any other AtomicString.
 * If a particular string already exists in the atomic string table, allocating another string that is equal to it does not cost any additional memory. The atomic string is shared and the cost is looking it up in the per-thread atomic string hash table and incrementing its reference count.
-* There are special considerations if you want to use an atomic string on a thread other than the one it was created on since each thread has its own atomic string hash table.
+* There are special considerations if you want to use an atomic string on a thread other than the one it was created on since each thread has its own atomic string hash table. In particular, if internal StringImpl object is destroyed it will try to remove string from the wrong AtomicStringTable. Also, if String::isolatedCopy() is invoked for AtomicString, it will always create a copy, and internal reference counter is not thread safe.
 
 We use AtomicString to make string comparisons fast and to save memory when many equal strings are likely to be allocated. For example, we use AtomicString for HTML attribute names so we can compare them quickly, and for both HTML attribute names and values since it’s common to have many identical ones and we save memory.