Don't use JSFunction's allocation profile when getting the prototype can be effectful

• Component: JavaScriptCore
• Status: RESOLVED FIXED

[Saam Barati]

...

[Saam Barati]

<rdar://problem/37584764>

[Saam Barati]

Created attachment 334202 [details]
patch

[Saam Barati]

Created attachment 334204 [details]
patch

[Mark Lam]

Comment on attachment 334204 [details]
patch

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

r=me

> Source/JavaScriptCore/ChangeLog:23
> +        the allocation profile when the prototype property is non-configurable
> +        and non-writable.

Per our offline discussion, non-writable is not applicable.

> Source/JavaScriptCore/runtime/JSFunction.h:135
> -    FunctionRareData* rareData(ExecState* exec, unsigned inlineCapacity)
> +    FunctionRareData* ensureRareDataAndAllocationProfile(ExecState* exec, unsigned inlineCapacity)
>      {
> +        ASSERT(canUseAllocationProfileNonInline());

You can move this function to Inlines.h and forego needing canUseAllocationProfileNonInline().

[Saam Barati]

Created attachment 334212 [details]
patch for landing

[EWS Watchlist]

Attachment 334212 [details] did not pass style-queue:


ERROR: Source/JavaScriptCore/runtime/JSFunction.h:133:  The parameter name "exec" adds no information, so it should be removed.  [readability/parameter_name] [5]
Total errors found: 1 in 8 files


If any of these errors are false positives, please file a bug against check-webkit-style.

[Saam Barati]

Created attachment 334213 [details]
patch for landing

[WebKit Commit Bot]

Comment on attachment 334213 [details]
patch for landing

Rejecting attachment 334213 [details] from commit-queue.

Failed to run "['/Volumes/Data/EWS/WebKit/Tools/Scripts/webkit-patch', '--status-host=webkit-queues.webkit.org', '--bot-id=webkit-cq-02', 'land-attachment', '--force-clean', '--non-interactive', '--parent-command=commit-queue', 334213, '--port=mac']" exit_code: 1 cwd: /Volumes/Data/EWS/WebKit

Last 500 characters of output:
rdparty/autoinstalled/mechanize/_urllib2_fork.py", line 332, in _call_chain
    result = func(*args)
  File "/Volumes/Data/EWS/WebKit/Tools/Scripts/webkitpy/thirdparty/autoinstalled/mechanize/_urllib2_fork.py", line 1170, in https_open
    return self.do_open(conn_factory, req)
  File "/Volumes/Data/EWS/WebKit/Tools/Scripts/webkitpy/thirdparty/autoinstalled/mechanize/_urllib2_fork.py", line 1118, in do_open
    raise URLError(err)
urllib2.URLError: <urlopen error [Errno 60] Operation timed out>

Full output: http://webkit-queues.webkit.org/results/6582814

[WebKit Commit Bot]

Comment on attachment 334213 [details]
patch for landing

Rejecting attachment 334213 [details] from commit-queue.

Failed to run "['/Volumes/Data/EWS/WebKit/Tools/Scripts/webkit-patch', '--status-host=webkit-queues.webkit.org', '--bot-id=webkit-cq-01', 'apply-attachment', '--no-update', '--non-interactive', 334213, '--port=mac']" exit_code: 2 cwd: /Volumes/Data/EWS/WebKit

Last 500 characters of output:
Hunk #1 FAILED at 130.
Hunk #2 succeeded at 149 with fuzz 2 (offset -4 lines).
Hunk #3 FAILED at 159.
Hunk #4 succeeded at 180 with fuzz 2 (offset -4 lines).
2 out of 4 hunks FAILED -- saving rejects to file Source/JavaScriptCore/runtime/JSFunction.h.rej
patching file Source/JavaScriptCore/runtime/JSFunctionInlines.h
Hunk #1 succeeded at 129 with fuzz 1 (offset 22 lines).

Failed to run "[u'/Volumes/Data/EWS/WebKit/Tools/Scripts/svn-apply', '--force']" exit_code: 1 cwd: /Volumes/Data/EWS/WebKit

Full output: http://webkit-queues.webkit.org/results/6585604

[David Kilzer (:ddkilzer)]

I think Saam landed this manually in:

Commit r228725:  <https://trac.webkit.org/changeset/228725>

[Saam Barati]

(In reply to David Kilzer (:ddkilzer) from comment #10)
> I think Saam landed this manually in:
> 
> Commit r228725:  <https://trac.webkit.org/changeset/228725>

Bizarre, I did not land it manually. I wonder how it got committed.

[Saam Barati]

(In reply to Saam Barati from comment #11)
> (In reply to David Kilzer (:ddkilzer) from comment #10)
> > I think Saam landed this manually in:
> > 
> > Commit r228725:  <https://trac.webkit.org/changeset/228725>
> 
> Bizarre, I did not land it manually. I wonder how it got committed.

Seems like the commit bot was messed up last night. I guess it must've just committed it even though it said it errored out?