> On Dec 9, 2020, at 1:02 PM, Geoff Garen via webkit-dev
> wrote:
>
>> - Make FontCache thread-safe, but do it via introducing a completely
>> separate thread-safe AtomString type and leave the current one as it is
>> (I don't have a good grasp of how difficult this would actually be)
>
> I had
>> 1. It’s not just ref counting.
>>
>> To make String thread-safe, you also need to address all other data
>> members. That means all state in m_hashAndFlags, including the
>> 8bit/16bit state.
>>
>> It appears that your testing strategy did not reveal this point so
>> far; so, you probably nee
>> Because it’s so expensive, and because we have a no regression policy for
>> performance, I don’t think there’s a way to land this change in pieces. It
>> has to be a mega-patch, so we can test its performance as a whole.
>
> Were you able to quantify anything additional about the performance
Hey Geoff and Chris,
> On Dec 1, 2020, at 9:21 AM, Geoff Garen via webkit-dev
> wrote:
>
> A few thoughts here:
>
> 1. It’s not just ref counting.
>
> To make String thread-safe, you also need to address all other data members.
> That means all state in m_hashAndFlags, including the 8bit/16
On 2020-12-01 18:21, Geoff Garen wrote:
> A few thoughts here:
>
> 1. It’s not just ref counting.
>
> To make String thread-safe, you also need to address all other data
> members. That means all state in m_hashAndFlags, including the
> 8bit/16bit state.
>
> It appears that your testing strateg
A few thoughts here:
1. It’s not just ref counting.
To make String thread-safe, you also need to address all other data members.
That means all state in m_hashAndFlags, including the 8bit/16bit state.
It appears that your testing strategy did not reveal this point so far; so, you
probably nee
6 matches
Mail list logo