Bug 161796 - HashMapImpl needs to m_buffer.clear() in its constructor
Summary: HashMapImpl needs to m_buffer.clear() in its constructor
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: JavaScriptCore (show other bugs)
Version: WebKit Nightly Build
Hardware: All All
: P2 Normal
Assignee: Filip Pizlo
URL:
Keywords:
: 161797 (view as bug list)
Depends on:
Blocks:
 
Reported: 2016-09-09 08:55 PDT by Filip Pizlo
Modified: 2016-10-05 10:32 PDT (History)
6 users (show)

See Also:


Attachments
possible patch (2.31 KB, patch)
2016-09-09 09:03 PDT, Filip Pizlo
keith_miller: review+
Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Filip Pizlo 2016-09-09 08:55:42 PDT
Patch forthcoming.
Comment 1 Ryan Haddad 2016-09-09 09:02:26 PDT
*** Bug 161797 has been marked as a duplicate of this bug. ***
Comment 2 Filip Pizlo 2016-09-09 09:03:59 PDT
Created attachment 288405 [details]
possible patch
Comment 3 WebKit Commit Bot 2016-09-09 09:37:16 PDT
Attachment 288405 [details] did not pass style-queue:


ERROR: Source/JavaScriptCore/runtime/AuxiliaryBarrier.h:40:  Should be indented on a separate line, with the colon or comma first on that line.  [whitespace/indent] [4]
Total errors found: 1 in 2 files


If any of these errors are false positives, please file a bug against check-webkit-style.
Comment 4 Keith Miller 2016-09-09 09:50:30 PDT
Comment on attachment 288405 [details]
possible patch

r=me.
Comment 5 Filip Pizlo 2016-09-09 09:52:40 PDT
Landed in https://trac.webkit.org/changeset/205746
Comment 6 Mark Lam 2016-09-09 10:07:28 PDT
Comment on attachment 288405 [details]
possible patch

View in context: https://bugs.webkit.org/attachment.cgi?id=288405&action=review

> Source/JavaScriptCore/ChangeLog:3
> +        HashMapImpl needs to m_buffer.clear() in its constructor

It's strange that the bug/patch description doesn't seem to match what is being changed.  Am I missing some context here?
Comment 7 Darin Adler 2016-10-05 10:32:26 PDT
Comment on attachment 288405 [details]
possible patch

View in context: https://bugs.webkit.org/attachment.cgi?id=288405&action=review

> Source/JavaScriptCore/ChangeLog:10
> +        This is the second time that I'm fixing a bug because AuxiliaryBarrier does not initialize
> +        itself. That seemed like a good idea because maybe sometimes the user knows better how to
> +        initialize it. But, it's not worth it if it's a constant source of bugs.

One design that allows you to keep the optimization but make the class less error-prone to use is to add a default constructor and a separate constructor that does not initialize that you can invoke explicitly. Something like this:

    enum DoNotInitializeType { DoNotInitialize };

    class AuxiliaryBarrier {
    public:
        AuxiliaryBarrier();
        explicit AuxiliaryBarrier(DoNotInitializeType);
        ...
    };