WebKit Bugzilla
New
Browse
Log In
×
Sign in with GitHub
or
Remember my login
Create Account
·
Forgot Password
Forgotten password account recovery
RESOLVED FIXED
143919
Merge WeakMapData into JSWeakMap and JSWeakSet
https://bugs.webkit.org/show_bug.cgi?id=143919
Summary
Merge WeakMapData into JSWeakMap and JSWeakSet
Yusuke Suzuki
Reported
2015-04-18 11:50:22 PDT
Integrate WeakMapData into WeakMap / WeakSet as inlined member
Attachments
Patch
(41.25 KB, patch)
2017-08-23 19:26 PDT
,
Yusuke Suzuki
no flags
Details
Formatted Diff
Diff
Patch
(41.22 KB, patch)
2017-08-23 19:30 PDT
,
Yusuke Suzuki
no flags
Details
Formatted Diff
Diff
Patch
(41.22 KB, patch)
2017-08-23 22:17 PDT
,
Yusuke Suzuki
darin
: review+
Details
Formatted Diff
Diff
Show Obsolete
(2)
View All
Add attachment
proposed patch, testcase, etc.
Yusuke Suzuki
Comment 1
2017-08-23 19:26:45 PDT
Created
attachment 318955
[details]
Patch
Yusuke Suzuki
Comment 2
2017-08-23 19:30:09 PDT
Created
attachment 318958
[details]
Patch
Yusuke Suzuki
Comment 3
2017-08-23 22:17:31 PDT
Created
attachment 318969
[details]
Patch
Darin Adler
Comment 4
2017-08-25 20:42:35 PDT
Comment on
attachment 318969
[details]
Patch View in context:
https://bugs.webkit.org/attachment.cgi?id=318969&action=review
I’m not a big fan of the abbreviation “Impl” as in “WeakMapImpl”; I would have used the word “Base” instead and called it “WeakMapBase”, I think.
> Source/JavaScriptCore/runtime/WeakMapImpl.cpp:47 > +void WeakMapImpl::finishCreation(VM& vm) > +{ > + Base::finishCreation(vm); > +}
Do we really need this function?
> Source/JavaScriptCore/runtime/WeakMapImpl.cpp:56 > + WeakMapImpl* thisObj = jsCast<WeakMapImpl*>(cell);
I would use auto* here since the type name is already there. I also would use the word “object”, not the abbreviation “obj”. But these are changes to code that was already here, I guess. And of course I would use a reference instead of a pointer, but I think the people who normally work on JavaScriptCore strongly reject this preference of mine.
> Source/JavaScriptCore/runtime/WeakMapImpl.cpp:63 > + WeakMapImpl* thisObj = jsCast<WeakMapImpl*>(cell);
Ditto.
> Source/JavaScriptCore/runtime/WeakMapImpl.cpp:95 > + auto iter = m_map.find(key); > + if (iter == m_map.end()) > + return false; > + > + m_map.remove(iter); > + return true;
This entire sequence of code does the same thing as: return m_map.remove(key);
> Source/JavaScriptCore/runtime/WeakMapImpl.cpp:118 > + RELEASE_ASSERT(m_liveKeyCount <= impl->m_map.size());
Very strange to use RELEASE_ASSERT here. There is no chance this assertion will fail, given the way the loop above is written, so why include the code in release builds? A normal ASSERT makes way more sense to me.
> Source/JavaScriptCore/runtime/WeakMapImpl.cpp:123 > + WeakMapImpl* impl = target();
I would call this map, or weakMap, not impl. Words preferred over abbreviations.
> Source/JavaScriptCore/runtime/WeakMapImpl.h:47 > + typedef HashMap<JSObject*, WriteBarrier<Unknown>> MapType;
In new code we should us "using" rather than "typedef".
> Source/JavaScriptCore/runtime/WeakMapImpl.h:51 > + int size() const { return m_map.size(); }
The choice of "int" for the type here is peculiar. HashMap uses "unsigned".
> Source/JavaScriptCore/runtime/WeakMapImpl.h:58 > + void finishCreation(VM&);
Strange to override the public function in the base class with a protected function. Maybe we should be inheriting protected instead of public?
> Source/JavaScriptCore/runtime/WeakMapImpl.h:65 > + DeadKeyCleaner(WeakMapImpl* impl) > + { > + ASSERT_UNUSED(impl, impl == target()); > + }
I think we should just assert this in the WeakMapImpl constructor after constructing the DeadKeyCleaner. Seems like overkill to write this constructor here in this header file just so we can put the assertion here.
> Source/JavaScriptCore/runtime/WeakMapImpl.h:70 > + WeakMapImpl* target() > + { > + return bitwise_cast<WeakMapImpl*>(bitwise_cast<char*>(this) - OBJECT_OFFSETOF(WeakMapImpl, m_deadKeyCleaner)); > + }
I suggest putting this function body inside the cpp file rather than here in the header. It can still be marked inline, but since it will only be called inside the cpp file we should not have to put it here. We can still define the function here.
Darin Adler
Comment 5
2017-08-25 21:12:14 PDT
Comment on
attachment 318969
[details]
Patch View in context:
https://bugs.webkit.org/attachment.cgi?id=318969&action=review
>> Source/JavaScriptCore/runtime/WeakMapImpl.h:70 >> + } > > I suggest putting this function body inside the cpp file rather than here in the header. It can still be marked inline, but since it will only be called inside the cpp file we should not have to put it here. We can still define the function here.
We can still *declare* the function here, I mean.
Yusuke Suzuki
Comment 6
2017-08-26 01:01:36 PDT
Committed
r221223
: <
http://trac.webkit.org/changeset/221223
>
Radar WebKit Bug Importer
Comment 7
2017-08-26 01:02:43 PDT
<
rdar://problem/34096516
>
Yusuke Suzuki
Comment 8
2017-08-26 01:03:17 PDT
Comment on
attachment 318969
[details]
Patch View in context:
https://bugs.webkit.org/attachment.cgi?id=318969&action=review
>> Source/JavaScriptCore/runtime/WeakMapImpl.cpp:47 >> +} > > Do we really need this function?
OK, dropped.
>> Source/JavaScriptCore/runtime/WeakMapImpl.cpp:56 >> + WeakMapImpl* thisObj = jsCast<WeakMapImpl*>(cell); > > I would use auto* here since the type name is already there. I also would use the word “object”, not the abbreviation “obj”. But these are changes to code that was already here, I guess. And of course I would use a reference instead of a pointer, but I think the people who normally work on JavaScriptCore strongly reject this preference of mine.
OK, here, jsCast<> explicitly describes the type. So auto* would be nice. Changed.
>> Source/JavaScriptCore/runtime/WeakMapImpl.cpp:63 >> + WeakMapImpl* thisObj = jsCast<WeakMapImpl*>(cell); > > Ditto.
Fixed.
>> Source/JavaScriptCore/runtime/WeakMapImpl.cpp:95 >> + return true; > > This entire sequence of code does the same thing as: > > return m_map.remove(key);
Nice. Right. Fixed.
>> Source/JavaScriptCore/runtime/WeakMapImpl.cpp:118 >> + RELEASE_ASSERT(m_liveKeyCount <= impl->m_map.size()); > > Very strange to use RELEASE_ASSERT here. There is no chance this assertion will fail, given the way the loop above is written, so why include the code in release builds? A normal ASSERT makes way more sense to me.
Make sense. Changed to ASSERT.
>> Source/JavaScriptCore/runtime/WeakMapImpl.cpp:123 >> + WeakMapImpl* impl = target(); > > I would call this map, or weakMap, not impl. Words preferred over abbreviations.
Changed.
>> Source/JavaScriptCore/runtime/WeakMapImpl.h:47 >> + typedef HashMap<JSObject*, WriteBarrier<Unknown>> MapType; > > In new code we should us "using" rather than "typedef".
Changed.
>> Source/JavaScriptCore/runtime/WeakMapImpl.h:51 >> + int size() const { return m_map.size(); } > > The choice of "int" for the type here is peculiar. HashMap uses "unsigned".
Changed it to unsigned.
>> Source/JavaScriptCore/runtime/WeakMapImpl.h:58 >> + void finishCreation(VM&); > > Strange to override the public function in the base class with a protected function. Maybe we should be inheriting protected instead of public?
OK, aligned them to the base class's policy. destroy is protected. estimatedSize and visitChildren are public.
>> Source/JavaScriptCore/runtime/WeakMapImpl.h:65 >> + } > > I think we should just assert this in the WeakMapImpl constructor after constructing the DeadKeyCleaner. Seems like overkill to write this constructor here in this header file just so we can put the assertion here.
Sounds nice. Fixed.
>>> Source/JavaScriptCore/runtime/WeakMapImpl.h:70 >>> + } >> >> I suggest putting this function body inside the cpp file rather than here in the header. It can still be marked inline, but since it will only be called inside the cpp file we should not have to put it here. We can still define the function here. > > We can still *declare* the function here, I mean.
Sounds very nice. Fixed.
Note
You need to
log in
before you can comment on or make changes to this bug.
Top of Page
Format For Printing
XML
Clone This Bug