[Webkit-unassigned] [Bug 216172] [JSC] Use symbols as identifiers for class fields computed names storage

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=216172

--- Comment #10 from Caio Lima <ticaiolima at gmail.com> ---
(In reply to Xan Lopez from comment #9)
> (In reply to Caio Lima from comment #8)
> 
> > It sounds more correct if we have a less fine grain API to create/retrieve
> > private identifier on `identifierArena` called `makePrivateIdentifier(VM&
> > vm, unsigned identifier)`. This way, we would be able to avoid a heap
> > allocation (removing `Symbol::create`) and have full control of SymbolImpl
> > lifetime.
> 
> This makes a lot of sense, even more so because the pending bytecode cache
> failures are also related to this! So we need a better API than wrapping
> things with a heap Symbol.
> 
> > 
> > > Source/WTF/wtf/text/SymbolRegistry.h:91
> > > +    HashSet<SymbolRegistryKey> m_privateTable;
> > 
> > I don't think we need to include a `m_privateTable` on SymbolRegistry. I
> > think this concept of private/public is more on the client side of this API
> > than on SymbolRegistry itself. The alternative I'd propose here is to have a
> > new SymbolRegistry on `VM` that store private symbols. This way we would be
> > achieving the same goal we want with current `SymbolRegistry` API we have.
> 
> Cool. What do you think about adding some code in SymbolRegistry so that it
> can be configured to store public or private symbols, but never both?

I personally would avoid including any info into SymbolRegistry for this change. We could definitely do that in the future, if we think it's necessary. I can see the advantage of this on cases where we don't want to mix Private and Public Symbols.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-unassigned/attachments/20201020/6bf00127/attachment-0001.htm>