OSR entry: delay outer-loop compilation when at inner-loop
[WebKit-https.git] / Source / JavaScriptCore / ChangeLog
1 2017-01-26  JF Bastien  <jfbastien@apple.com>
2
3         OSR entry: delay outer-loop compilation when at inner-loop
4         https://bugs.webkit.org/show_bug.cgi?id=167149
5
6         Reviewed by Filip Pizlo.
7
8         As of https://bugs.webkit.org/show_bug.cgi?id=155217 OSR
9         compilation can be kicked off for an entry into an outer-loop,
10         while executing an inner-loop. This is desirable because often the
11         codegen from an inner-entry isn't as good as the codegen from an
12         outer-entry, but execution from an inner-loop is often pretty hot
13         and likely to kick off compilation. This approach provided nice
14         speedups on Kraken because we'd select to enter to the outer-loop
15         very reliably, which reduces variability (the inner-loop was
16         selected roughly 1/5 times from my unscientific measurements).
17
18         When compilation starts we take a snapshot of the JSValues at the
19         current execution state using OSR's recovery mechanism. These
20         values are passed to the compiler and are used as way to perform
21         type profiling, and could be used to observe cell types as well as
22         to perform predictions such as through constant propagation.
23
24         It's therefore desired to enter from the outer-loop when we can,
25         but we need to be executing from that location to capture the
26         right JSValues, otherwise we're confusing the compiler and giving
27         it inaccurate JSValues which can lead it to predict the wrong
28         things, leading to suboptimal code or recompilation due to
29         misprediction, or in super-corner-cases a crash.
30
31         These effects are pretty hard to measure: Fil points out that
32         marsalis-osr-entry really needs mustHandleValues (the JSValues
33         from the point of execution) because right now it just happens to
34         correctly guess int32. I tried removing mustHandleValues entirely
35         and saw no slowdowns, but our benchmarks probably aren't
36         sufficient to reliably find issues, sometimes because we happen to
37         have sufficient mitigations.
38
39         DFG tier-up was added here:
40         https://bugs.webkit.org/show_bug.cgi?id=112838
41
42         * JavaScriptCore.xcodeproj/project.pbxproj:
43         * dfg/DFGJITCode.h:
44         * dfg/DFGJITCompiler.cpp:
45         (JSC::DFG::JITCompiler::JITCompiler):
46         * dfg/DFGOSREntry.cpp:
47         (JSC::DFG::prepareOSREntry):
48         * dfg/DFGOSREntry.h:
49         (JSC::DFG::prepareOSREntry):
50         * dfg/DFGOperations.cpp:
51         * dfg/DFGOperations.h:
52         * dfg/DFGSpeculativeJIT64.cpp:
53         (JSC::DFG::SpeculativeJIT::compile):
54         * dfg/DFGTierUpEntryTrigger.h: Copied from Source/JavaScriptCore/ftl/FTLOSREntry.h.
55         * dfg/DFGToFTLForOSREntryDeferredCompilationCallback.cpp:
56         (JSC::DFG::ToFTLForOSREntryDeferredCompilationCallback::ToFTLForOSREntryDeferredCompilationCallback):
57         (JSC::DFG::Ref<ToFTLForOSREntryDeferredCompilationCallback>ToFTLForOSREntryDeferredCompilationCallback::create):
58         (JSC::DFG::ToFTLForOSREntryDeferredCompilationCallback::compilationDidBecomeReadyAsynchronously):
59         (JSC::DFG::ToFTLForOSREntryDeferredCompilationCallback::compilationDidComplete):
60         * dfg/DFGToFTLForOSREntryDeferredCompilationCallback.h:
61         * ftl/FTLOSREntry.cpp:
62         (JSC::FTL::prepareOSREntry):
63         * ftl/FTLOSREntry.h:
64         * jit/JITOperations.cpp:
65
66 2017-01-25  Saam Barati  <sbarati@apple.com>
67
68         WebAssembly JS API: coerce return values from imports
69         https://bugs.webkit.org/show_bug.cgi?id=165480
70         <rdar://problem/29760318>
71
72         Reviewed by Yusuke Suzuki.
73
74         This patch does proper coercion for all possible
75         JSValue return types from an imported function.
76         
77         It also adds the spec-compliant code to throw an exception
78         when calling an import that has an i64 parameter or return
79         value.
80
81         * jit/AssemblyHelpers.cpp:
82         (JSC::AssemblyHelpers::emitJumpIfException):
83         * jit/AssemblyHelpers.h:
84         * wasm/WasmB3IRGenerator.cpp:
85         * wasm/WasmBinding.cpp:
86         (JSC::Wasm::wasmToJs):
87
88 2017-01-25  Filip Pizlo  <fpizlo@apple.com>
89
90         jsc.cpp should have the $.agent stuff for testing SAB
91         https://bugs.webkit.org/show_bug.cgi?id=167431
92
93         Reviewed by Saam Barati.
94         
95         This adds some stuff that the SAB branch of test262 needs. None of this is exposed except for our
96         own tests and the SAB branch of test262. We now pass all of the Atomics tests in the SAB branch
97         of test262.
98         
99         * jsc.cpp:
100         (Message::releaseContents):
101         (Message::index):
102         (GlobalObject::finishCreation):
103         (GlobalObject::addFunction):
104         (Message::Message):
105         (Message::~Message):
106         (Worker::Worker):
107         (Worker::~Worker):
108         (Worker::send):
109         (Worker::receive):
110         (Worker::current):
111         (Worker::currentWorker):
112         (Workers::Workers):
113         (Workers::~Workers):
114         (Workers::broadcast):
115         (Workers::report):
116         (Workers::tryGetReport):
117         (Workers::getReport):
118         (Workers::singleton):
119         (functionDollarCreateRealm):
120         (functionDollarDetachArrayBuffer):
121         (functionDollarEvalScript):
122         (functionDollarAgentStart):
123         (functionDollarAgentReceiveBroadcast):
124         (functionDollarAgentReport):
125         (functionDollarAgentSleep):
126         (functionDollarAgentBroadcast):
127         (functionDollarAgentGetReport):
128         (functionWaitForReport):
129         (checkException):
130         (runWithScripts):
131         (runJSC):
132         (jscmain):
133         * runtime/JSArrayBuffer.h:
134
135 2017-01-25  Filip Pizlo  <fpizlo@apple.com>
136
137         ARM/ARM64 stress/atomics-store-return.js fails
138         <rdar://problem/30192652>
139
140         Reviewed by Michael Saboff.
141         
142         The problem was relying on double->int casts for anything. We need to use toInt32().
143
144         * runtime/AtomicsObject.cpp:
145         (JSC::atomicsFuncCompareExchange):
146         (JSC::atomicsFuncExchange):
147         (JSC::atomicsFuncStore):
148
149 2017-01-25  Ryosuke Niwa  <rniwa@webkit.org>
150
151         collectMatchingElementsInFlatTree should not find elements inside an user agent shadow tree
152         https://bugs.webkit.org/show_bug.cgi?id=167409
153
154         Reviewed by Antti Koivisto.
155
156         Added matchingElementInFlatTree as a common identifier since it's required in the bindings code.
157
158         * runtime/CommonIdentifiers.h:
159
160 2017-01-24  Joseph Pecoraro  <pecoraro@apple.com>
161
162         Fold USER_TIMING into WEB_TIMING and make it a RuntimeEnabledFeature
163         https://bugs.webkit.org/show_bug.cgi?id=167394
164
165         Reviewed by Ryosuke Niwa.
166
167         * Configurations/FeatureDefines.xcconfig:
168         * runtime/CommonIdentifiers.h:
169
170 2017-01-24  Filip Pizlo  <fpizlo@apple.com>
171
172         Atomics.store should return the int-converted value according to toInteger
173         https://bugs.webkit.org/show_bug.cgi?id=167399
174
175         Reviewed by Saam Barati.
176         
177         I keep getting this wrong, but I think I've finally done it right. What we want is for
178         Atomics.store to return the value it was passed after toInteger, which doesn't clip the value to
179         any kind of range. It does get truncated to double.
180         
181         This changes the code to pass those "integers" as doubles. It doesn't matter that this is slow,
182         since all of these code paths are slow due to their need to check everything. We'll take care of
183         that by making them intrinsic later.
184
185         * runtime/AtomicsObject.cpp:
186         (JSC::atomicsFuncAdd):
187         (JSC::atomicsFuncAnd):
188         (JSC::atomicsFuncCompareExchange):
189         (JSC::atomicsFuncExchange):
190         (JSC::atomicsFuncLoad):
191         (JSC::atomicsFuncOr):
192         (JSC::atomicsFuncStore):
193         (JSC::atomicsFuncSub):
194         (JSC::atomicsFuncXor):
195
196 2017-01-24  Yusuke Suzuki  <utatane.tea@gmail.com>
197
198         [JSC] Optimize Number#toString with Int52
199         https://bugs.webkit.org/show_bug.cgi?id=167303
200
201         Reviewed by Sam Weinig.
202
203         In kraken crypto-sha256-iterative, we frequently call Number.prototype.toString with
204         Int52. In that case, toString handles it in the generic double path. But we should
205         have a fast path for this since it can be represented in int64_t.
206
207         The stanford-crypto-sha256-iterative shows 1.6% performance improvement (on Linux machine hanayamata).
208
209             Collected 100 samples per benchmark/VM, with 100 VM invocations per benchmark. Emitted a call to gc() between
210             sample measurements. Used 1 benchmark iteration per VM invocation for warm-up. Used the jsc-specific preciseTime()
211             function to get microsecond-level timing. Reporting benchmark execution times with 95% confidence intervals in
212             milliseconds.
213
214                                                        baseline                  patched
215
216             stanford-crypto-sha256-iterative        32.853+-0.075      ^      32.325+-0.055         ^ definitely 1.0163x faster
217
218         * runtime/JSCJSValue.h:
219         * runtime/NumberPrototype.cpp:
220         (JSC::int52ToStringWithRadix):
221         (JSC::toStringWithRadix):
222
223 2017-01-24  Michael Saboff  <msaboff@apple.com>
224
225         InferredTypeTable entry manipulation is not TOCTOU race safe
226         https://bugs.webkit.org/show_bug.cgi?id=167344
227
228         Reviewed by Filip Pizlo.
229
230         Made the accesses to table values safe from Time of Check,
231         Time of Use races with local temporary values.
232
233         Fixed point that we set an entry in the table to access the
234         current table entry instead of using the local entry.  In that case,
235         we reload the now changed entry.
236
237         * runtime/InferredTypeTable.cpp:
238         (JSC::InferredTypeTable::visitChildren):
239         (JSC::InferredTypeTable::get):
240         (JSC::InferredTypeTable::willStoreValue):
241         (JSC::InferredTypeTable::makeTop):
242
243 2017-01-24  Filip Pizlo  <fpizlo@apple.com>
244
245         Atomics.store should return the int-converted value, not the value that it stored
246         https://bugs.webkit.org/show_bug.cgi?id=167395
247
248         Reviewed by Saam Barati.
249         
250         Previously the code was based around passing a lambda that operated over the native type of the
251         operation (so for example int8_t if we were doing things to Int8Arrays). But to support this
252         behavior of store, we need it to be able to control how it converts its result to JSValue and it
253         needs to see its argument as an int32_t. It turns out that it's easy for all of the functions in
254         AtomicsObject.cpp to also adopt this protocol since the conversion to JSValue is just jsNumber()
255         from the native type in those cases, and the conversion from int32_t is done for free in
256         std::atomic.
257
258         * runtime/AtomicsObject.cpp:
259         (JSC::atomicsFuncAdd):
260         (JSC::atomicsFuncAnd):
261         (JSC::atomicsFuncCompareExchange):
262         (JSC::atomicsFuncExchange):
263         (JSC::atomicsFuncLoad):
264         (JSC::atomicsFuncOr):
265         (JSC::atomicsFuncStore):
266         (JSC::atomicsFuncSub):
267         (JSC::atomicsFuncXor):
268
269 2017-01-24  Filip Pizlo  <fpizlo@apple.com>
270
271         -0 is a valid array index and AtomicsObject should know this
272         https://bugs.webkit.org/show_bug.cgi?id=167386
273
274         Reviewed by Mark Lam.
275
276         * runtime/AtomicsObject.cpp: The bug title really says it all.
277
278 2017-01-24  Commit Queue  <commit-queue@webkit.org>
279
280         Unreviewed, rolling out r211091.
281         https://bugs.webkit.org/show_bug.cgi?id=167384
282
283         introduces a subtle bug in InferredTypeTable, huge
284         Octane/deltablue regression (Requested by pizlo on #webkit).
285
286         Reverted changeset:
287
288         "InferredTypeTable entry manipulation is not TOCTOU race safe"
289         https://bugs.webkit.org/show_bug.cgi?id=167344
290         http://trac.webkit.org/changeset/211091
291
292 2017-01-24  Filip Pizlo  <fpizlo@apple.com>
293
294         Enable the stochastic space-time scheduler on the larger multicores
295         https://bugs.webkit.org/show_bug.cgi?id=167382
296         <rdar://problem/30173375>
297
298         Rubber stamped by Saam Barati
299         
300         This looks like a 1.3% JetStream speed-up thanks to a 28% splay-latency improvement. This new
301         scheduler seems to prevent all of the same pathologies as the old one prevented. But instead of
302         periodically suspending the mutator, this new one will only suspend after an iteration of the
303         constraint fixpoint. The length of that suspension length is random with the distribution being
304         governed by mutatorUtilization. Once resumed, the mutator gets to run unimpeded until draining
305         stalls.
306         
307         I'm enabling it on platforms as I benchmark those platforms. It's possible that we will want to
308         use a different scheduler on different platforms.
309
310         * runtime/Options.cpp:
311         (JSC::overrideDefaults):
312
313 2017-01-24  Michael Saboff  <msaboff@apple.com>
314
315         JSArray::tryCreateUninitialized should be called JSArray::tryCreateForInitializationPrivate
316         https://bugs.webkit.org/show_bug.cgi?id=167334
317
318         Rubber-stamped by Filip Pizlo.
319
320         * dfg/DFGOperations.cpp:
321         * ftl/FTLOperations.cpp:
322         (JSC::FTL::operationMaterializeObjectInOSR):
323         * runtime/ArrayPrototype.cpp:
324         (JSC::arrayProtoFuncSplice):
325         (JSC::arrayProtoPrivateFuncConcatMemcpy):
326         * runtime/CommonSlowPaths.cpp:
327         (JSC::SLOW_PATH_DECL):
328         * runtime/JSArray.cpp:
329         (JSC::JSArray::tryCreateForInitializationPrivate):
330         (JSC::JSArray::fastSlice):
331         (JSC::JSArray::tryCreateUninitialized): Deleted.
332         * runtime/JSArray.h:
333         (JSC::JSArray::tryCreateForInitializationPrivate):
334         (JSC::constructArray):
335         (JSC::constructArrayNegativeIndexed):
336         (JSC::JSArray::tryCreateUninitialized): Deleted.
337         * runtime/RegExpMatchesArray.cpp:
338         (JSC::createEmptyRegExpMatchesArray):
339         * runtime/RegExpMatchesArray.h:
340         (JSC::createRegExpMatchesArray):
341
342 2017-01-23  Michael Saboff  <msaboff@apple.com>
343
344         InferredTypeTable entry manipulation is not TOCTOU race safe
345         https://bugs.webkit.org/show_bug.cgi?id=167344
346
347         Reviewed by Filip Pizlo.
348
349         Made the accesses to table values safe from Time of Check,
350         Time of Use races with local temporary values.
351
352         * runtime/InferredTypeTable.cpp:
353         (JSC::InferredTypeTable::visitChildren):
354         (JSC::InferredTypeTable::get):
355         (JSC::InferredTypeTable::willStoreValue):
356         (JSC::InferredTypeTable::makeTop):
357
358 2017-01-23  Joseph Pecoraro  <pecoraro@apple.com>
359
360         Web Inspector: Provide a way to trigger a Garbage Collection
361         https://bugs.webkit.org/show_bug.cgi?id=167345
362         <rdar://problem/30102853>
363
364         Reviewed by Timothy Hatcher.
365
366         * inspector/protocol/Console.json:
367         * inspector/protocol/Debugger.json:
368         * inspector/protocol/Heap.json:
369         * inspector/protocol/Runtime.json:
370         These domains are supported by Worker backends. Label them.
371
372         * inspector/scripts/codegen/generate_js_backend_commands.py:
373         (JSBackendCommandsGenerator.generate_domain):
374         * inspector/scripts/codegen/models.py:
375         (Protocol.parse_domain):
376         (Domain.__init__):
377         (Domains):
378         Parse "workerSupported" and include a line in BackendCommands.js
379         that calls to InspectorBackend.workerSupportedDomain().
380
381         * inspector/scripts/tests/generic/domain-availability.json: Added.
382         * inspector/scripts/tests/generic/expected/domain-availability.json-result: Added.
383         * inspector/scripts/tests/generic/expected/worker-supported-domains.json-result: Added.
384         * inspector/scripts/tests/generic/worker-supported-domains.json: Added.
385         Tests for domain "workerSupported" and "availability" properties.
386
387 2017-01-23  Saam Barati  <sbarati@apple.com>
388
389         https://bugs.webkit.org/show_bug.cgi?id=167247
390         JSC: operationSpreadGeneric uses the wrong global object for the builtin function and slow_path_spread consults the wrong global object to prove if the iterator protocol is unobservable
391         <rdar://problem/30121809>
392
393         Reviewed by Filip Pizlo.
394
395         There were two bugs in the different tiers with respect to how
396         spread handled global objects.
397         
398         The first was in the LLInt/baseline inside slow_path_spread:
399         
400         We consulted the lexical global object instead of the thing we're
401         spreading's global object to determine if the array iterator protocol
402         is unobservable. This is wrong if the incoming array is from a different
403         global object. We must consult the incoming array's global object
404         to determine if it can be spread using the fast path.
405         
406         The second was in operationSpreadGeneric in the DFG/FTL:
407         
408         We were always using the incoming array's global object, even
409         when going down the slow path. This is wrong because we were
410         fetching the builtin iteration function helper from the incoming
411         array's global object, which meant that if the iterator function
412         were to throw an exception, it could leak objects from a different
413         global object. We should be executing the iterator function with
414         the lexical global object.
415
416         * dfg/DFGOperations.cpp:
417         * jsc.cpp:
418         (GlobalObject::finishCreation):
419         (functionGlobalObjectForObject):
420         * runtime/CommonSlowPaths.cpp:
421         (JSC::SLOW_PATH_DECL):
422         * runtime/JSArray.h:
423         * runtime/JSArrayInlines.h:
424         (JSC::JSArray::isIteratorProtocolFastAndNonObservable):
425
426 2017-01-22  Filip Pizlo  <fpizlo@apple.com>
427
428         Land the stochastic space-time scheduler disabled
429         https://bugs.webkit.org/show_bug.cgi?id=167249
430
431         Reviewed by Saam Barati.
432         
433         The space-time scheduler is pretty weird. It uses a periodic scheduler where the next period is
434         simply determined by an integer multiple of time since when the scheduler last snapped phase. It
435         snaps phase after constraint solving. Both the snapping of the phase after constraint solving and
436         the periodicity appear to be necessary for good performance. For example, if the space-time
437         scheduler decided that it was in the resume part of the phase just by virtue of having just
438         resumed, then it would be empirically worse than our scheduler which asks "what time is it?" to
439         decide whether it should be suspended or resumed even if it just suspended or resumed. I've spent
440         a lot of time wondering why these two features are essential, and I think I found a reason.
441         
442         What's happening is that sometimes the GC has an overrun and its increment takes longer than it
443         should have. The current scheduler forgives overruns when constraint solving, which seems to
444         make sense because it cannot control whether constraint solving runs with the mutator resumed or
445         suspended. It has to be suspended currently. Snapping phase after constraint solving accomplishes
446         this. What's more surprising is how important it is to manage deadline misses during draining.
447         The relevant kind of deadline miss is when doing mutator-suspended draining to catch up to the
448         retreating wavefront. Deadline misses while doing this can happen systematically in some
449         workloads, like JetStream/hash-map and some test in Speedometer. It's because they have some
450         ginormous object and it takes like ~3ms+-1.5ms just to scan it. The space-time scheduler's use
451         of time to decide what to do saves the day here: after the deadline miss, the scheduler will
452         initially realize that it missed its deadline to resume the mutator. But as soon as it does this
453         it asks: "based on current time since phase snap, what should I do?". In the case of a deadline
454         miss, this question is essentially a weighted coin flip because of the high noise in the amount
455         of time that it takes to do things in the GC. If you overrun, you will probably overrun by
456         multiple milliseconds, which is enough that where you land in the space-time scheduler's timeline
457         is random. The likelihood that you land in the "resume mutator" part of the timeline has a
458         probability that is roughly the same as what the space-time scheduler calls mutator utilization.
459         This is a super weird property. I did not intend for it to have this property, but it appears to
460         be the most important property of this scheduler.
461         
462         Based on this, it seems that the fact that the space-time scheduler could suspend the mutator
463         before draining runs out of work doesn't accomplish anything. As soon as you resume the
464         mutator, you have a retreating wavefront to worry about. But if the collector is happily scanning
465         things then it's almost certain that the collector will outpace the mutator. Also, anything that
466         the mutator asks us to revisit is deferred anyway.
467         
468         In the past I've tried to replace the scheduler in one patch and this turned out to be annoying
469         because even a poorly conceived scheduler should be iterated on. This patch lands a new scheduler
470         called the StochasticSpaceTime scheduler. It replaces two of the known-good features of the old
471         scheduler: (1) it forgives constraint pauses and (2) after deadline overrun its choice is random,
472         weighted by the mutator utilization target. Unlike the old scheduler, this one will only suspend
473         the mutator when the draining terminates, but it may pause for any amount of time after an
474         iteration of constraint solving. It computes the targetPause by measuring constraint solving time
475         and multiplying by the pauseScale (0.3 by default). If smaller then minimumPause (0.3ms by
476         default), then it uses minimumPause instead. The stochastic scheduler will then definitely do at
477         least targetPause worth of suspended draining after the constraint solving iteration, and then
478         it will decide whether or not to do another one at random. The probability that it will choose to
479         resume is exactly mutatorUtilization, which is computed exactly as before. Therefore, the
480         probability of resumption starts at 0.7 and goes down as memory usage rises. Conversely, the
481         probability that we will stay suspended starts at 0.3 and goes up from there.
482         
483         This new scheduler looks like it might be a 25% improvement on splay-latency. It also looks like
484         a small progression on hash-map. Hash-map is a great test of one of the worst cases of retreating
485         wavefront, since it is repeatedly storing to a ginormous array. This array is sure to take a
486         while to scan, and to complete, the GC must be smart enough to visit any new objects it finds
487         while scanning the array immediately after scanning that array. This new scheduler means that
488         after scanning the array, the probability that you will scan whatever you found in it starts at
489         0.3 and rises as the program allocates. It's sure to be 0.3, and not 0.3^k, because after the
490         wavefront stops advancing, the only object on the mark stack after a constraint iteration will be
491         that array. Since there is sure to be a 0.3ms or longer pause, the GC will be sure to start
492         visiting this object. The GC can then complete if it just allows enough time after this to scan
493         whatever new objects it finds. If scanning the array overruns the deadline (and it almost
494         certainly will) then the probability that the GC keeps the mutator suspended is simply
495         1 - mutatorUtilization.
496         
497         This scheduler is disabled by default. You can enable it with
498         --useStochasticMutatorScheduler=true.
499
500         * CMakeLists.txt:
501         * JavaScriptCore.xcodeproj/project.pbxproj:
502         * heap/Heap.cpp:
503         (JSC::Heap::Heap):
504         (JSC::Heap::markToFixpoint):
505         * heap/Heap.h:
506         * heap/MarkingConstraintSet.cpp:
507         (JSC::MarkingConstraintSet::didStartMarking):
508         (JSC::MarkingConstraintSet::executeConvergenceImpl):
509         (JSC::MarkingConstraintSet::resetStats): Deleted.
510         (JSC::MarkingConstraintSet::executeBootstrap): Deleted.
511         * heap/MarkingConstraintSet.h:
512         * heap/MutatorScheduler.cpp:
513         (JSC::MutatorScheduler::didReachTermination):
514         (JSC::MutatorScheduler::synchronousDrainingDidStall):
515         * heap/MutatorScheduler.h:
516         * heap/SlotVisitor.cpp:
517         (JSC::SlotVisitor::didReachTermination):
518         (JSC::SlotVisitor::drainFromShared):
519         * heap/StochasticSpaceTimeMutatorScheduler.cpp: Added.
520         (JSC::StochasticSpaceTimeMutatorScheduler::Snapshot::Snapshot):
521         (JSC::StochasticSpaceTimeMutatorScheduler::Snapshot::now):
522         (JSC::StochasticSpaceTimeMutatorScheduler::Snapshot::bytesAllocatedThisCycle):
523         (JSC::StochasticSpaceTimeMutatorScheduler::StochasticSpaceTimeMutatorScheduler):
524         (JSC::StochasticSpaceTimeMutatorScheduler::~StochasticSpaceTimeMutatorScheduler):
525         (JSC::StochasticSpaceTimeMutatorScheduler::state):
526         (JSC::StochasticSpaceTimeMutatorScheduler::beginCollection):
527         (JSC::StochasticSpaceTimeMutatorScheduler::didStop):
528         (JSC::StochasticSpaceTimeMutatorScheduler::willResume):
529         (JSC::StochasticSpaceTimeMutatorScheduler::didReachTermination):
530         (JSC::StochasticSpaceTimeMutatorScheduler::didExecuteConstraints):
531         (JSC::StochasticSpaceTimeMutatorScheduler::synchronousDrainingDidStall):
532         (JSC::StochasticSpaceTimeMutatorScheduler::timeToStop):
533         (JSC::StochasticSpaceTimeMutatorScheduler::timeToResume):
534         (JSC::StochasticSpaceTimeMutatorScheduler::log):
535         (JSC::StochasticSpaceTimeMutatorScheduler::endCollection):
536         (JSC::StochasticSpaceTimeMutatorScheduler::setResumeTime):
537         (JSC::StochasticSpaceTimeMutatorScheduler::bytesAllocatedThisCycleImpl):
538         (JSC::StochasticSpaceTimeMutatorScheduler::bytesSinceBeginningOfCycle):
539         (JSC::StochasticSpaceTimeMutatorScheduler::maxHeadroom):
540         (JSC::StochasticSpaceTimeMutatorScheduler::headroomFullness):
541         (JSC::StochasticSpaceTimeMutatorScheduler::mutatorUtilization):
542         * heap/StochasticSpaceTimeMutatorScheduler.h: Added.
543         * runtime/Options.cpp:
544         (JSC::overrideDefaults):
545         * runtime/Options.h:
546
547 2017-01-23  Mark Lam  <mark.lam@apple.com>
548
549         Added a comment to clarify an assertion.
550
551         Rubber-stamped by Filip Pizlo.
552
553         * runtime/JSCellInlines.h:
554         (JSC::JSCell::classInfo):
555
556 2017-01-23  Filip Pizlo  <fpizlo@apple.com>
557
558         SharedArrayBuffer plus WebGL should not equal CRASH
559         https://bugs.webkit.org/show_bug.cgi?id=167329
560
561         Reviewed by Saam Barati.
562         
563         DOM unwrapping methods should return null rather than crashing. The code expects an
564         unshared buffer, so we should return null when it's shared. The caller can then decide
565         if they like null or not.
566
567         * runtime/JSArrayBufferViewInlines.h:
568         (JSC::JSArrayBufferView::toWrapped):
569
570 2017-01-23  Mark Lam  <mark.lam@apple.com>
571
572         ObjCCallbackFunction::destroy() should not use jsCast().
573         https://bugs.webkit.org/show_bug.cgi?id=167322
574
575         Reviewed by Filip Pizlo.
576
577         Since r210829, it is no longer correct for object destructors to use jsCast().
578         Fixed ObjCCallbackFunction::destroy() to use a static_cast instead.
579
580         * API/ObjCCallbackFunction.mm:
581         (JSC::ObjCCallbackFunction::destroy):
582
583 2017-01-23  Michael Saboff  <msaboff@apple.com>
584
585         IntlObject uses JSArray::tryCreateUninitialized in an unsafe way
586         https://bugs.webkit.org/show_bug.cgi?id=167288
587
588         Reviewed by Filip Pizlo.
589
590         Refactored the following "create" methods into a "tryCreate" method and a
591         "create" wrapper: JSArray::create(), Butterfly::create() and
592         createArrayButterfly().
593
594         Changed IntlObject.cpp to use JSArray::tryCreate() as it is simpler to use
595         by not requiring the caller to be GC savey.  The performance benefits of
596         tryCreateUninitialized() are not needed by the IntlObject c++ code.
597
598         Did not add a new test as the bug caused LayoutTests/js/intl.html to fail
599         reliably with the JSC option values scribbleFreeCells=true,
600         collectContinuously=true and JSC_useGenerationalGC=false.
601
602         * runtime/Butterfly.h:
603         * runtime/ButterflyInlines.h:
604         (JSC::Butterfly::tryCreate): Added.
605         (JSC::Butterfly::create):
606         * runtime/IntlObject.cpp:
607         (JSC::canonicalizeLocaleList):
608         (JSC::lookupSupportedLocales):
609         (JSC::intlObjectFuncGetCanonicalLocales):
610         * runtime/JSArray.h:
611         (JSC::createContiguousArrayButterfly): Deleted.
612         (JSC::tryCreateArrayButterfly): Added.
613         (JSC::createArrayButterfly):
614         (JSC::JSArray::tryCreate): Added.
615         (JSC::JSArray::create):
616
617 2017-01-23  Joseph Pecoraro  <pecoraro@apple.com>
618
619         JavaScriptCore has a weak external symbol in it
620         https://bugs.webkit.org/show_bug.cgi?id=167282
621
622         Reviewed by Yusuke Suzuki.
623
624         * debugger/Debugger.cpp:
625         (JSC::Debugger::ProfilingClient::~ProfilingClient):
626         * debugger/Debugger.h:
627         Avoid possible weak external symbol.
628
629 2017-01-21  Chris Dumez  <cdumez@apple.com>
630
631         JavaScript for-of does not work on a lot of collection types (e.g. HTMLCollection)
632         https://bugs.webkit.org/show_bug.cgi?id=167091
633
634         Reviewed by Darin Adler.
635
636         Update Array methods to throw a TypeError when (this === null || this === undefined)
637         instead of when (this == null). This is because (this == null) returns true for types
638         that masquerades as undefined (such as document.all) and this prevented use of the
639         Array API on such types. The specification only stays to use ToObject(), which throws
640         when the input is undefined or null.
641
642         The corresponding specification is at:
643         - https://www.ecma-international.org/ecma-262/7.0/index.html#sec-array.prototype.values
644         - https://www.ecma-international.org/ecma-262/7.0/index.html#sec-toobject
645
646         * builtins/ArrayPrototype.js:
647         (values):
648         (keys):
649         (entries):
650         (reduce):
651         (reduceRight):
652         (every):
653         (forEach):
654         (filter):
655         (map):
656         (some):
657         (fill):
658         (find):
659         (findIndex):
660         (includes):
661         (sort):
662         (concatSlowPath):
663         (copyWithin):
664
665 2017-01-21  Yusuke Suzuki  <utatane.tea@gmail.com>
666
667         [JSC] export JSC::importModule API for WebCore dynamic import
668         https://bugs.webkit.org/show_bug.cgi?id=167099
669
670         Reviewed by Darin Adler.
671
672         We newly expose JSC::importModule API. This can be used later
673         from WebCore to implement WebCore side dynamic import.
674         And JSC shell also uses this API.
675
676         And this patch also cleans up module loader a bit:
677         Dropping requestInstantiateAll.
678
679         * builtins/BuiltinNames.h:
680         * builtins/ModuleLoaderPrototype.js:
681         (requestLink):
682         (requestImportModule):
683         (requestInstantiateAll): Deleted.
684         (importModule): Deleted.
685         * jsc.cpp:
686         (GlobalObject::moduleLoaderImportModule):
687         * runtime/Completion.cpp:
688         (JSC::importModule):
689         * runtime/Completion.h:
690         * runtime/JSModuleLoader.cpp:
691         (JSC::JSModuleLoader::requestImportModule):
692         * runtime/JSModuleLoader.h:
693         * runtime/ModuleLoaderPrototype.cpp:
694
695 2017-01-21  Yusuke Suzuki  <utatane.tea@gmail.com>
696
697         dynamic import is ambiguous with import declaration at module code
698         https://bugs.webkit.org/show_bug.cgi?id=167098
699
700         Reviewed by Darin Adler.
701
702         This patch fixes two syntax issues related to dynamic import.
703
704         1. Fix member expression parsing with dynamic import results
705
706         We should not return import expression immediately after parsing
707         it in parseMemberExpression. This prohibits us to parse the following
708         code,
709
710             import("...").then(function () {
711             });
712
713         2. dynamic import with import declaration under the module context
714
715         Before this patch, we always attempt to parse IMPORT as import declaration
716         under the module context. It means that import call in the top level
717         expression statement fails to be parsed since the parser attempts to parse
718         it as import declaration.
719
720             import("...")  // module top level statement.
721
722         In this patch, we check the condition `[lookahead != (]` before starting
723         parsing import declaration. This allows us to put import call in the module
724         top level statement.
725
726         * parser/Parser.cpp:
727         (JSC::Parser<LexerType>::parseModuleSourceElements):
728         (JSC::Parser<LexerType>::parseMemberExpression):
729
730 2017-01-20  Joseph Pecoraro  <pecoraro@apple.com>
731
732         Remove outdated ENABLE(CSP_NEXT) build flag
733         https://bugs.webkit.org/show_bug.cgi?id=167252
734
735         Reviewed by Brent Fulgham.
736
737         * Configurations/FeatureDefines.xcconfig:
738
739 2017-01-20  Saam Barati  <sbarati@apple.com>
740
741         We should flash a safepoint before each DFG/FTL phase
742         https://bugs.webkit.org/show_bug.cgi?id=167234
743
744         Reviewed by Filip Pizlo.
745
746         The recent GC changes caused us to regress Kraken because of a
747         longstanding issue that happened to be hit with higher frequency because
748         of a change in timing between when a particular GC was happening and 
749         when a particular FTL compilation was happening. The regression is caused
750         by the GC was waiting for a large function to make it through the DFG portion
751         of an FTL compilation. This was taking 20ms-30ms and started happened during a
752         particular test with much higher frequency.
753         
754         This means that anytime the GC waits for this compilation, the test ran at least
755         ~20ms slower because the GC waits for the compiler threads the mutator is stopped.
756         
757         It's good that we have such an easily reproducible case of this performance
758         issue because it will effect many real JS programs, especially ones with
759         large functions that get hot.
760         
761         The most straight forward solution to fix this is to flash a safepoint before
762         each phase, allowing the GC to suspend the compiler if needed. In my testing,
763         this progresses Kraken in the browser, and doesn't regress anything else. This
764         solution also makes the most sense. I did some analysis on the compilation time
765         of this function that took ~20-30ms to pass through the DFG phases, and
766         the phase times were mostly evenly distributed. Some took longer than others,
767         but no phase was longer than 3ms. Most were in the 0.25ms to 1.5ms range.
768
769         * dfg/DFGPlan.cpp:
770         (JSC::DFG::Plan::compileInThreadImpl):
771         * dfg/DFGSafepoint.cpp:
772         (JSC::DFG::Safepoint::begin):
773         * runtime/Options.h:
774
775 2017-01-20  Skachkov Oleksandr  <gskachkov@gmail.com>
776
777         Super property access in base class constructor doesn't work
778         https://bugs.webkit.org/show_bug.cgi?id=166665
779
780         Reviewed by Ryosuke Niwa.
781
782         Allow to use super inside of the constructor for classes 
783         without parent class.
784         Parser checks if super used within the constructor and 
785         add this information to function metedata, and later it is used
786         during byte code generation.
787
788         * bytecompiler/NodesCodegen.cpp:
789         (JSC::ClassExprNode::emitBytecode):
790         * parser/Parser.cpp:
791         (JSC::Parser<LexerType>::parseFunctionBody):
792         (JSC::Parser<LexerType>::parseFunctionInfo):
793         * parser/Parser.h:
794         (JSC::Scope::usesEval):
795         (JSC::Scope::fillParametersForSourceProviderCache):
796         (JSC::Scope::restoreFromSourceProviderCache):
797         (JSC::Parser::adjustSuperBindingForBaseConstructor):
798         * parser/SourceProviderCacheItem.h:
799         (JSC::SourceProviderCacheItem::SourceProviderCacheItem):
800
801 2017-01-19  Chris Dumez  <cdumez@apple.com>
802
803         iterable<> should be enabled on WK1
804         https://bugs.webkit.org/show_bug.cgi?id=167221
805         <rdar://problem/30108531>
806
807         Reviewed by Youenn Fablet.
808
809         * runtime/CommonIdentifiers.h:
810
811 2017-01-19  Filip Pizlo  <fpizlo@apple.com>
812
813         Structure::pin() needs to be called while holding a lock
814         https://bugs.webkit.org/show_bug.cgi?id=167220
815
816         Reviewed by Saam Barati.
817
818         Imagine this race: the mutator calls pin() and the collector calls visitChildren(),
819         on the same Structure at the same time. In trunk pin() does not require a lock to be
820         held and it doesn't grab any locks. Meanwhile visitChildren() grabs the lock, checks
821         if the structure is pinned, and if not, it removes it by overwriting with zero. Now
822         imagine how this plays out when pin() runs. Since pin() grabs no locks, it is
823         irrelevant that visitChildren() grabs any locks. So, visitChildren() might check if
824         the table is pinned before pin() pins it, and then clear the table after it was
825         already pinned.
826
827         The problem here is that pin() should be holding a lock. We could either make pin()
828         grab that lock by itself, or what this patch does is makes the caller grab the lock.
829         This is great because it means that sometimes we don't have to introduce any new
830         locking.
831
832         This fixes a materializePropertyTable() checkOffsetConsistency() crash that happens
833         very rarely, but I was able to get it to reproduce with run-webkit-tests and
834         aggressive GC settings.
835
836         * runtime/ConcurrentJSLock.h:
837         * runtime/Structure.cpp:
838         (JSC::Structure::materializePropertyTable):
839         (JSC::Structure::changePrototypeTransition):
840         (JSC::Structure::attributeChangeTransition):
841         (JSC::Structure::toDictionaryTransition):
842         (JSC::Structure::nonPropertyTransition):
843         (JSC::Structure::pin):
844         (JSC::Structure::pinForCaching):
845         (JSC::Structure::add):
846         * runtime/Structure.h:
847         * runtime/StructureInlines.h:
848         (JSC::Structure::checkOffsetConsistency):
849         (JSC::Structure::add):
850         (JSC::Structure::addPropertyWithoutTransition):
851
852 2017-01-19  Filip Pizlo  <fpizlo@apple.com>
853
854         The mutator needs to fire a barrier after memmoving stuff around in an object that the GC scans
855         https://bugs.webkit.org/show_bug.cgi?id=167208
856
857         Reviewed by Saam Barati.
858         
859         It used to be that if you moved a value from one place to another in the same object
860         then there is no need for a barrier because the generational GC would have no need to
861         know that some old object still continues to refer to the same other old object.
862
863         But the concurrent GC might scan that object as the mutator moves pointers around in
864         it. If the ordering is right, this could mean that the collector never sees some of
865         those pointers. This can be fixed by adding a barrier.
866
867         This fixes the most obvious cases I found. There may be more and I'll continue to
868         audit. Most of the other memmove users seem to already use some kind of synchronization
869         to prevent this. For example, this can also be fixed by just holding the cell lock
870         around the memmove since we're dealing with indexing storage and the GC reads that
871         under the cell lock.
872
873         * runtime/JSArray.cpp:
874         (JSC::JSArray::shiftCountWithAnyIndexingType):
875         (JSC::JSArray::unshiftCountWithAnyIndexingType):
876
877 2017-01-19  Myles C. Maxfield  <mmaxfield@apple.com>
878
879         [Cocoa] Variation fonts are erroneously disabled on iOS
880         https://bugs.webkit.org/show_bug.cgi?id=167172
881
882         Reviewed by Simon Fraser.
883
884         OpenSource builders don't seem to understand sdk=embedded*.
885
886         * Configurations/FeatureDefines.xcconfig:
887
888 2017-01-19  Skachkov Oleksandr  <gskachkov@gmail.com>
889
890         "this" missing after await in async arrow function
891         https://bugs.webkit.org/show_bug.cgi?id=166919
892
893         Reviewed by NOBODY Saam Barati.
894
895         This patch fixed issue in async arrow function. Issue appears because in arrow
896         function _this_ is loaded from arrow function virtual scope. 
897         Async arrow function can be suspended and when resuming should be used _this_ from 
898         virtual scope, to allow this we load _this_ from virtual scope before store it to 
899         generator.generatorThis property 
900
901         * bytecompiler/NodesCodegen.cpp:
902         (JSC::FunctionNode::emitBytecode):
903
904 2017-01-18  Yusuke Suzuki  <utatane.tea@gmail.com>
905
906         [B3] B3 strength reduction could encounter Value without owner in PureCSE
907         https://bugs.webkit.org/show_bug.cgi?id=167161
908
909         Reviewed by Filip Pizlo.
910
911         PureCSE relies on the fact that all the stored Values have owner member.
912         This assumption is broken when you execute specializeSelect in B3ReduceStrength phase.
913         It clears owner of Values which are in between Select and Check to clone them to then/else
914         blocks. If these cleared Values are already stored in PureCSE map, this map poses a Value
915         with nullptr owner in PureCSE.
916
917         This patch changes PureCSE to ignore stored Values tha have nullptr owner. This even means
918         that a client of PureCSE could deliberately null the owner if they wanted to signal the
919         Value should be ignored.
920
921         While PureCSE ignores chance for optimization if Value's owner is nullptr, in the current
922         strength reduction algorithm, this does not hurt optimization because CSE will be eventually
923         applied since the strength reduction phase want to reach fixed point. But even without
924         this iterations, our result itself is valid since PureCSE is allowed to be conservative.
925
926         * b3/B3PureCSE.cpp:
927         (JSC::B3::PureCSE::findMatch):
928         (JSC::B3::PureCSE::process):
929         * b3/testb3.cpp:
930         (JSC::B3::testCheckSelectAndCSE):
931         (JSC::B3::run):
932
933 2017-01-18  Filip Pizlo  <fpizlo@apple.com>
934
935         JSSegmentedVariableObject and its subclasses should have a sane destruction story
936         https://bugs.webkit.org/show_bug.cgi?id=167193
937
938         Reviewed by Saam Barati.
939         
940         Prior to this change, JSSegmentedVariableObjects' subclasses install finalizers that call
941         destroy. They did this in random ways, which sometimes resulted in
942         JSSegmentedVariableObject::~JSSegmentedVariableObject executing more than once (which worked
943         because of the way that ~SegmentedVector is written). Maybe this works now, but it's a disaster
944         waiting to happen.
945
946         Fortunately we can now just give those things their own Subspace and teach it its own protocol of
947         destruction. This change introduces JSSegmentedVariableObjectSubspace and stashes a m_classInfo
948         in JSSegmentedVariableObject. Now, subclasses of JSSegmentedVariableObject are destructible in
949         much the same way as JSDestructibleObject without having to be subclasses of
950         JSDestructibleObject.
951
952         * API/JSCallbackObject.cpp:
953         (JSC::JSCallbackObject<JSGlobalObject>::create):
954         * CMakeLists.txt:
955         * JavaScriptCore.xcodeproj/project.pbxproj:
956         * jsc.cpp:
957         (GlobalObject::create):
958         * runtime/JSGlobalLexicalEnvironment.h:
959         (JSC::JSGlobalLexicalEnvironment::create):
960         * runtime/JSGlobalObject.cpp:
961         (JSC::JSGlobalObject::create):
962         (JSC::JSGlobalObject::finishCreation):
963         * runtime/JSGlobalObject.h:
964         (JSC::JSGlobalObject::create): Deleted.
965         (JSC::JSGlobalObject::finishCreation): Deleted.
966         * runtime/JSSegmentedVariableObject.cpp:
967         (JSC::JSSegmentedVariableObject::destroy):
968         (JSC::JSSegmentedVariableObject::JSSegmentedVariableObject):
969         (JSC::JSSegmentedVariableObject::~JSSegmentedVariableObject):
970         (JSC::JSSegmentedVariableObject::finishCreation):
971         * runtime/JSSegmentedVariableObject.h:
972         (JSC::JSSegmentedVariableObject::subspaceFor):
973         (JSC::JSSegmentedVariableObject::classInfo):
974         (JSC::JSSegmentedVariableObject::JSSegmentedVariableObject): Deleted.
975         (JSC::JSSegmentedVariableObject::finishCreation): Deleted.
976         * runtime/JSSegmentedVariableObjectSubspace.cpp: Added.
977         (JSC::JSSegmentedVariableObjectSubspace::JSSegmentedVariableObjectSubspace):
978         (JSC::JSSegmentedVariableObjectSubspace::~JSSegmentedVariableObjectSubspace):
979         (JSC::JSSegmentedVariableObjectSubspace::finishSweep):
980         (JSC::JSSegmentedVariableObjectSubspace::destroy):
981         * runtime/JSSegmentedVariableObjectSubspace.h: Added.
982         * runtime/VM.cpp:
983         (JSC::VM::VM):
984         * runtime/VM.h:
985         * testRegExp.cpp:
986         (GlobalObject::create):
987
988 2017-01-18  Joseph Pecoraro  <pecoraro@apple.com>
989
990         Web Inspector: console.table only works for the first 5 properties
991         https://bugs.webkit.org/show_bug.cgi?id=167175
992
993         Reviewed by Timothy Hatcher.
994
995         * inspector/InjectedScriptSource.js:
996         (InjectedScript.prototype.wrapTable):
997         (InjectedScript.RemoteObject.createObjectPreviewForValue):
998         (InjectedScript.RemoteObject.prototype._appendPropertyPreviews):
999         Pass through secondLevelKeys. Though the keys are themselves ignored, the
1000         existence is a signal that we should send more than the first 5 properties.
1001
1002 2017-01-18  Antti Koivisto  <antti@apple.com>
1003
1004         Only delete source provider caches on full collection
1005         https://bugs.webkit.org/show_bug.cgi?id=167173
1006
1007         Reviewed by Andreas Kling.
1008
1009         They are currently often wiped and recreated during page loading due to eden collections.
1010
1011         It is not clear that tying the lifetime of these caches to gc makes sense at all but this
1012         should at least help some.
1013
1014         * heap/Heap.cpp:
1015         (JSC::Heap::deleteSourceProviderCaches):
1016
1017 2017-01-18  Filip Pizlo  <fpizlo@apple.com>
1018
1019         JSObjectSetPrivate should not use jsCast<>
1020         rdar://problem/30069096
1021
1022         Reviewed by Keith Miller.
1023
1024         * API/JSObjectRef.cpp:
1025         (JSObjectSetPrivate):
1026
1027 2017-01-18  Brian Burg  <bburg@apple.com>
1028
1029         Web Inspector: remove an unnecessary include in generated Objective-C Inspector protocol code
1030         https://bugs.webkit.org/show_bug.cgi?id=167156
1031
1032         Rubber-stamped by Geoffrey Garen.
1033
1034         * inspector/scripts/codegen/objc_generator_templates.py:
1035         This include of config.h doesn't make sense when using the code generator
1036         outside of JavaScriptCore/WebKit. It is not necessary either, so remove it.
1037
1038         * inspector/scripts/tests/all/expected/definitions-with-mac-platform.json-result:
1039         * inspector/scripts/tests/generic/expected/commands-with-async-attribute.json-result:
1040         * inspector/scripts/tests/generic/expected/commands-with-optional-call-return-parameters.json-result:
1041         * inspector/scripts/tests/generic/expected/definitions-with-mac-platform.json-result:
1042         * inspector/scripts/tests/generic/expected/domains-with-varying-command-sizes.json-result:
1043         * inspector/scripts/tests/generic/expected/enum-values.json-result:
1044         * inspector/scripts/tests/generic/expected/events-with-optional-parameters.json-result:
1045         * inspector/scripts/tests/generic/expected/generate-domains-with-feature-guards.json-result:
1046         * inspector/scripts/tests/generic/expected/same-type-id-different-domain.json-result:
1047         * inspector/scripts/tests/generic/expected/shadowed-optional-type-setters.json-result:
1048         * inspector/scripts/tests/generic/expected/type-declaration-aliased-primitive-type.json-result:
1049         * inspector/scripts/tests/generic/expected/type-declaration-array-type.json-result:
1050         * inspector/scripts/tests/generic/expected/type-declaration-enum-type.json-result:
1051         * inspector/scripts/tests/generic/expected/type-declaration-object-type.json-result:
1052         * inspector/scripts/tests/generic/expected/type-requiring-runtime-casts.json-result:
1053         * inspector/scripts/tests/ios/expected/definitions-with-mac-platform.json-result:
1054         * inspector/scripts/tests/mac/expected/definitions-with-mac-platform.json-result:
1055         Rebaseline test results.
1056
1057 2017-01-18  Csaba Osztrogon√°c  <ossy@webkit.org>
1058
1059         Fix the JSCOnly build after r210844
1060         https://bugs.webkit.org/show_bug.cgi?id=167155
1061
1062         Unreviewed buildfix.
1063
1064         * heap/EdenGCActivityCallback.cpp:
1065
1066 2017-01-16  Filip Pizlo  <fpizlo@apple.com>
1067
1068         Make opaque root scanning truly constraint-based
1069         https://bugs.webkit.org/show_bug.cgi?id=165760
1070
1071         Reviewed by Geoffrey Garen.
1072
1073         We have bugs when visitChildren() changes its mind about what opaque root to add, since
1074         we don't have barriers on opaque roots. This supposedly once worked for generational GC,
1075         and I started adding more barriers to support concurrent GC. But I think that the real
1076         bug here is that we want the JSObject->OpaqueRoot to be evaluated as a constraint that
1077         participates in the fixpoint. I like to think of this as an *output* constraint, because it
1078         is concerned with outgoing edges in the heap from the object that registered the constraint.
1079         An *input* constraint is like what Weak<> does when deciding whether the thing it points to
1080         should be live.
1081
1082         Whether or not an object has output constraints depends on its type. So, we want the GC to
1083         have a feature where we rapidly call some function on all marked objects of some type.
1084         
1085         It's easy to rapidly scan all marked objects in a MarkedBlock. So, we want to allocate all
1086         objects that have output constraints in their own MarkedBlocks and we want to track the set
1087         of MarkedBlocks with output constraints.
1088         
1089         This patch makes it easy to have clients of JSC's internal C++ APIs create a Subspace - like
1090         what we used to call MarkedSpace::Subspace but now it's in the JSC namespace - which is
1091         a collection of objects that you can easily scan during GC from a MarkingConstraint. It's
1092         now possible for internal C++ API clients to register their own MarkingConstraints. The DOM
1093         now uses this to create two Subspaces (more on why two below) and it calls
1094         JSCell::visitOutputConstraints() on all of the marked objects in those subspaces using a new
1095         MarkingConstraint. That MarkingConstraint uses a new style of volatility, called
1096         SeldomGreyed, which is like GreyedByExecution except it is opportunistically not executed
1097         as roots in the hopes that their sole execution will be the snapshot-at-the-end. I also
1098         converted the CodeBlock rescan constraint to SeldomGreyed, since that's also an output
1099         constraint.
1100         
1101         This patch also uses Subspace for something pretty obvious: knowing how to call the
1102         destructor. Subspaces can specialize the sweep for their way of invoking destructors. We
1103         have the following subspaces:
1104         
1105         - auxiliary
1106         - cell
1107         - destructibleCell - for JSCell subclasses that have destructors and StructureIsImmortal
1108         - stringSpace - inlines ~JSString into the sweep, making string allocation 7% faster
1109         - destructibleObjectSpace - for JSDestructibleObject subclasses
1110         
1111         And WebCore adds:
1112         
1113         - outputConstraint - for JSDOMObjects that have a visitAdditionalChildren
1114         - globalObjectOutputConstraint - for JSDOMGlobalObjects that have a visitAdditionalChildren,
1115           since JSDOMGlobalObjects are not JSDestructibleObjects
1116         
1117         The Subspace for a type is selected by saying JSC::subspaceFor<Type>(vm). This calls
1118         Type::subspaceFor<Type>(vm). This allows cell classes to override subspaceFor<> and it
1119         allows any subspaceFor<> implementation to query static flags in the type. This is how
1120         JSCell::subspaceFor<> can select either cellSpace or destructibleCellSpace.
1121         
1122         This patch is mostly about:
1123         
1124         - Moving MarkedSpace::Subspace out of MarkedSpace and making it a nice class with a nice
1125           API. Almost all of its functionality is just taken out of MarkedSpace.
1126         - Converting users of the old API for allocating objects and getting MarkedAllocators, like
1127           heap.allocatorForObjectWithoutDestructor() and its friends. That would now say
1128           vm.cellSpace.allocatorFor().
1129         
1130         Altogether, this means that we only have a small regression on Dromaeo. The regression is
1131         due to the fact that we scan output constraints. Before the Subspace optimizations (see
1132         r209766, which was rolled out in r209812), this regression on Dromaeo/jslib was 2x but after
1133         the optimizations in this patch it's only 1.12x. Note that Dromaeo/jslib creats gigabytes of
1134         DOM nodes. Compared to web pages, this is a very extreme synthetic microbenchmark. Still, we
1135         like optimizing these because we don't want to presume what web pages will look like.
1136         
1137         The use of Subspaces to specialize destructors happened not because it's super necessary but
1138         because I wanted to introduce a single unified way of communicating to the GC how to treat
1139         different types. Any Subspace feature that allowed us to collect some types together would
1140         have to be mindful of the destructorness of objects. I could have turned this into a
1141         liability where each Subspace has two subsubspaces - one for destructor objects and one for
1142         non-destructor objects, which would have allowed me to keep the old sweep specialization
1143         code. Just days prior, mlam wanted to do something that was hard because of that old sweep
1144         specializer, so I decided to take the opportunity to fix the sweep specializer while also
1145         making Subspace be the one true way of teaching the GC about types. To validate that this
1146         actually does things, I added a JSStringSubspace and a test that shows that this is a 7%
1147         string allocation progression.
1148         
1149         In bug 167066, I'm getting rid of the rest of the code in JSC that would special-case for
1150         JSDestructibleObject vs StructureIsImmortal by using the GC's DestructionMode. After that,
1151         Subspace will be only mechanism by which JSC uses the GC to encode types.
1152         
1153         Prior to this change, having multiple MarkedSpace::Subspaces would have been expensive
1154         because they create a bunch of MarkedAllocators upfront. We now have the ability to create
1155         MarkedAllocators lazily. We create them on the first allocation from that size class or when
1156         a JIT asks for the MarkedAllocator. The concurrent JITs can ask for MarkedAllocators because
1157         their creation is under a lock.
1158         
1159         On my machine, this might be a 1.1% JetStream speed-up with 87% confidence and it might be
1160         a 0.4% PLT3 slow-down with 92% confidence. Note that 0.4% on PLT3 is the level of systematic
1161         error on PLT3 on my computer: I've seen definite 0.4% speed-ups and slow-downs that were not
1162         confirmed by any bot. Let's see what the bots say.
1163         
1164         * CMakeLists.txt:
1165         * JavaScriptCore.xcodeproj/project.pbxproj:
1166         * bytecode/ObjectAllocationProfile.h:
1167         (JSC::ObjectAllocationProfile::initialize):
1168         * bytecode/PolymorphicAccess.cpp:
1169         (JSC::AccessCase::generateImpl):
1170         * dfg/DFGSpeculativeJIT.cpp:
1171         (JSC::DFG::SpeculativeJIT::emitAllocateRawObject):
1172         (JSC::DFG::SpeculativeJIT::compileMakeRope):
1173         (JSC::DFG::SpeculativeJIT::compileAllocatePropertyStorage):
1174         (JSC::DFG::SpeculativeJIT::compileReallocatePropertyStorage):
1175         (JSC::DFG::SpeculativeJIT::compileNewTypedArray):
1176         (JSC::DFG::SpeculativeJIT::emitAllocateButterfly):
1177         * dfg/DFGSpeculativeJIT64.cpp:
1178         (JSC::DFG::SpeculativeJIT::compile):
1179         * ftl/FTLAbstractHeapRepository.h:
1180         * ftl/FTLLowerDFGToB3.cpp:
1181         (JSC::FTL::DFG::LowerDFGToB3::compileNewTypedArray):
1182         (JSC::FTL::DFG::LowerDFGToB3::compileMakeRope):
1183         (JSC::FTL::DFG::LowerDFGToB3::compileMaterializeNewObject):
1184         (JSC::FTL::DFG::LowerDFGToB3::allocatePropertyStorageWithSizeImpl):
1185         (JSC::FTL::DFG::LowerDFGToB3::allocateObject):
1186         (JSC::FTL::DFG::LowerDFGToB3::allocatorForSize):
1187         (JSC::FTL::DFG::LowerDFGToB3::allocateVariableSizedObject):
1188         (JSC::FTL::DFG::LowerDFGToB3::allocateVariableSizedCell):
1189         (JSC::FTL::DFG::LowerDFGToB3::allocateJSArray):
1190         * heap/AllocatorAttributes.h:
1191         (JSC::AllocatorAttributes::AllocatorAttributes):
1192         * heap/ConstraintVolatility.h: Added.
1193         (WTF::printInternal):
1194         * heap/GCActivityCallback.cpp:
1195         * heap/Heap.cpp:
1196         (JSC::Heap::Heap):
1197         (JSC::Heap::lastChanceToFinalize):
1198         (JSC::Heap::markToFixpoint):
1199         (JSC::Heap::updateObjectCounts):
1200         (JSC::Heap::collectAllGarbage):
1201         (JSC::Heap::collectInThread):
1202         (JSC::Heap::stopTheWorld):
1203         (JSC::Heap::updateAllocationLimits):
1204         (JSC::Heap::bytesVisited):
1205         (JSC::Heap::addCoreConstraints):
1206         (JSC::Heap::addMarkingConstraint):
1207         (JSC::Heap::notifyIsSafeToCollect):
1208         (JSC::Heap::preventCollection):
1209         (JSC::Heap::allowCollection):
1210         (JSC::Heap::setMutatorShouldBeFenced):
1211         (JSC::Heap::buildConstraintSet): Deleted.
1212         (JSC::Heap::writeBarrierOpaqueRootSlow): Deleted.
1213         (JSC::Heap::addMutatorShouldBeFencedCache): Deleted.
1214         * heap/Heap.h:
1215         (JSC::Heap::mutatorExecutionVersion):
1216         (JSC::Heap::numOpaqueRoots):
1217         (JSC::Heap::vm): Deleted.
1218         (JSC::Heap::subspaceForObjectWithoutDestructor): Deleted.
1219         (JSC::Heap::subspaceForObjectDestructor): Deleted.
1220         (JSC::Heap::subspaceForAuxiliaryData): Deleted.
1221         (JSC::Heap::allocatorForObjectWithoutDestructor): Deleted.
1222         (JSC::Heap::allocatorForObjectWithDestructor): Deleted.
1223         (JSC::Heap::allocatorForAuxiliaryData): Deleted.
1224         * heap/HeapInlines.h:
1225         (JSC::Heap::vm):
1226         (JSC::Heap::allocateWithDestructor): Deleted.
1227         (JSC::Heap::allocateWithoutDestructor): Deleted.
1228         (JSC::Heap::allocateObjectOfType): Deleted.
1229         (JSC::Heap::subspaceForObjectOfType): Deleted.
1230         (JSC::Heap::allocatorForObjectOfType): Deleted.
1231         (JSC::Heap::allocateAuxiliary): Deleted.
1232         (JSC::Heap::tryAllocateAuxiliary): Deleted.
1233         (JSC::Heap::tryReallocateAuxiliary): Deleted.
1234         (JSC::Heap::ascribeOwner): Deleted.
1235         (JSC::Heap::writeBarrierOpaqueRoot): Deleted.
1236         * heap/LargeAllocation.cpp:
1237         (JSC::LargeAllocation::tryCreate):
1238         (JSC::LargeAllocation::LargeAllocation):
1239         (JSC::LargeAllocation::~LargeAllocation):
1240         (JSC::LargeAllocation::sweep):
1241         * heap/LargeAllocation.h:
1242         * heap/MarkedAllocator.cpp:
1243         (JSC::MarkedAllocator::MarkedAllocator):
1244         (JSC::MarkedAllocator::tryAllocateWithoutCollecting):
1245         (JSC::MarkedAllocator::tryAllocateIn):
1246         (JSC::MarkedAllocator::allocateSlowCaseImpl):
1247         (JSC::MarkedAllocator::tryAllocateBlock):
1248         (JSC::MarkedAllocator::shrink):
1249         (JSC::MarkedAllocator::markedSpace):
1250         * heap/MarkedAllocator.h:
1251         (JSC::MarkedAllocator::nextAllocatorInSubspace):
1252         (JSC::MarkedAllocator::setNextAllocatorInSubspace):
1253         (JSC::MarkedAllocator::subspace):
1254         (JSC::MarkedAllocator::tryAllocate): Deleted.
1255         (JSC::MarkedAllocator::allocate): Deleted.
1256         (JSC::MarkedAllocator::forEachBlock): Deleted.
1257         * heap/MarkedAllocatorInlines.h: Added.
1258         (JSC::MarkedAllocator::tryAllocate):
1259         (JSC::MarkedAllocator::allocate):
1260         (JSC::MarkedAllocator::forEachBlock):
1261         (JSC::MarkedAllocator::forEachNotEmptyBlock):
1262         * heap/MarkedBlock.cpp:
1263         (JSC::MarkedBlock::Handle::subspace):
1264         (JSC::MarkedBlock::Handle::sweep):
1265         (JSC::MarkedBlock::Handle::specializedSweep): Deleted.
1266         (JSC::MarkedBlock::Handle::sweepHelperSelectScribbleMode): Deleted.
1267         (JSC::MarkedBlock::Handle::sweepHelperSelectEmptyMode): Deleted.
1268         (JSC::MarkedBlock::Handle::sweepHelperSelectHasNewlyAllocated): Deleted.
1269         (JSC::MarkedBlock::Handle::sweepHelperSelectSweepMode): Deleted.
1270         (JSC::MarkedBlock::Handle::sweepHelperSelectMarksMode): Deleted.
1271         * heap/MarkedBlock.h:
1272         (JSC::MarkedBlock::Handle::visitWeakSet):
1273         * heap/MarkedBlockInlines.h:
1274         (JSC::MarkedBlock::Handle::isNewlyAllocatedStale):
1275         (JSC::MarkedBlock::Handle::hasAnyNewlyAllocated):
1276         (JSC::MarkedBlock::heap):
1277         (JSC::MarkedBlock::space):
1278         (JSC::MarkedBlock::Handle::space):
1279         (JSC::MarkedBlock::Handle::specializedSweep):
1280         (JSC::MarkedBlock::Handle::finishSweepKnowingSubspace):
1281         (JSC::MarkedBlock::Handle::sweepDestructionMode):
1282         (JSC::MarkedBlock::Handle::emptyMode):
1283         (JSC::MarkedBlock::Handle::scribbleMode):
1284         (JSC::MarkedBlock::Handle::newlyAllocatedMode):
1285         (JSC::MarkedBlock::Handle::marksMode):
1286         (JSC::MarkedBlock::Handle::forEachMarkedCell):
1287         * heap/MarkedSpace.cpp:
1288         (JSC::MarkedSpace::initializeSizeClassForStepSize):
1289         (JSC::MarkedSpace::MarkedSpace):
1290         (JSC::MarkedSpace::lastChanceToFinalize):
1291         (JSC::MarkedSpace::addMarkedAllocator):
1292         (JSC::MarkedSpace::allocate): Deleted.
1293         (JSC::MarkedSpace::tryAllocate): Deleted.
1294         (JSC::MarkedSpace::allocateLarge): Deleted.
1295         (JSC::MarkedSpace::tryAllocateLarge): Deleted.
1296         * heap/MarkedSpace.h:
1297         (JSC::MarkedSpace::heap):
1298         (JSC::MarkedSpace::allocatorLock):
1299         (JSC::MarkedSpace::subspaceForObjectsWithDestructor): Deleted.
1300         (JSC::MarkedSpace::subspaceForObjectsWithoutDestructor): Deleted.
1301         (JSC::MarkedSpace::subspaceForAuxiliaryData): Deleted.
1302         (JSC::MarkedSpace::allocatorFor): Deleted.
1303         (JSC::MarkedSpace::destructorAllocatorFor): Deleted.
1304         (JSC::MarkedSpace::auxiliaryAllocatorFor): Deleted.
1305         (JSC::MarkedSpace::allocateWithoutDestructor): Deleted.
1306         (JSC::MarkedSpace::allocateWithDestructor): Deleted.
1307         (JSC::MarkedSpace::allocateAuxiliary): Deleted.
1308         (JSC::MarkedSpace::tryAllocateAuxiliary): Deleted.
1309         (JSC::MarkedSpace::forEachSubspace): Deleted.
1310         * heap/MarkingConstraint.cpp:
1311         (JSC::MarkingConstraint::MarkingConstraint):
1312         * heap/MarkingConstraint.h:
1313         (JSC::MarkingConstraint::volatility):
1314         * heap/MarkingConstraintSet.cpp:
1315         (JSC::MarkingConstraintSet::resetStats):
1316         (JSC::MarkingConstraintSet::add):
1317         (JSC::MarkingConstraintSet::executeConvergenceImpl):
1318         * heap/MarkingConstraintSet.h:
1319         * heap/SlotVisitor.cpp:
1320         (JSC::SlotVisitor::visitChildren):
1321         (JSC::SlotVisitor::visitAsConstraint):
1322         (JSC::SlotVisitor::drain):
1323         (JSC::SlotVisitor::addOpaqueRoot):
1324         (JSC::SlotVisitor::mergeIfNecessary):
1325         (JSC::SlotVisitor::mergeOpaqueRootsIfNecessary): Deleted.
1326         * heap/SlotVisitor.h:
1327         (JSC::SlotVisitor::setIgnoreNewOpaqueRoots):
1328         * heap/SlotVisitorInlines.h:
1329         (JSC::SlotVisitor::reportExtraMemoryVisited):
1330         (JSC::SlotVisitor::reportExternalMemoryVisited):
1331         * heap/Subspace.cpp: Added.
1332         (JSC::Subspace::Subspace):
1333         (JSC::Subspace::~Subspace):
1334         (JSC::Subspace::finishSweep):
1335         (JSC::Subspace::destroy):
1336         (JSC::Subspace::allocate):
1337         (JSC::Subspace::tryAllocate):
1338         (JSC::Subspace::allocatorForSlow):
1339         (JSC::Subspace::allocateSlow):
1340         (JSC::Subspace::tryAllocateSlow):
1341         * heap/Subspace.h: Added.
1342         (JSC::Subspace::tryAllocatorFor):
1343         (JSC::Subspace::allocatorFor):
1344         * heap/SubspaceInlines.h: Added.
1345         (JSC::Subspace::forEachMarkedBlock):
1346         (JSC::Subspace::forEachNotEmptyMarkedBlock):
1347         (JSC::Subspace::forEachLargeAllocation):
1348         (JSC::Subspace::forEachMarkedCell):
1349         * heap/WeakBlock.cpp:
1350         (JSC::WeakBlock::specializedVisit):
1351         * heap/WeakBlock.h:
1352         * heap/WeakSet.h:
1353         (JSC::WeakSet::visit):
1354         * jit/AssemblyHelpers.h:
1355         (JSC::AssemblyHelpers::emitAllocateJSObjectWithKnownSize):
1356         (JSC::AssemblyHelpers::emitAllocateVariableSized):
1357         (JSC::AssemblyHelpers::emitAllocateVariableSizedCell):
1358         * jit/JITOpcodes.cpp:
1359         (JSC::JIT::emit_op_new_object):
1360         * jsc.cpp:
1361         * runtime/ButterflyInlines.h:
1362         (JSC::Butterfly::createUninitialized):
1363         (JSC::Butterfly::growArrayRight):
1364         * runtime/ClassInfo.h:
1365         * runtime/ClonedArguments.cpp:
1366         (JSC::ClonedArguments::createEmpty):
1367         * runtime/DirectArguments.cpp:
1368         (JSC::DirectArguments::overrideThings):
1369         * runtime/GenericArgumentsInlines.h:
1370         (JSC::GenericArguments<Type>::initModifiedArgumentsDescriptor):
1371         * runtime/HashMapImpl.h:
1372         (JSC::HashMapBuffer::create):
1373         * runtime/JSArray.cpp:
1374         (JSC::JSArray::tryCreateUninitialized):
1375         (JSC::JSArray::unshiftCountSlowCase):
1376         * runtime/JSArrayBufferView.cpp:
1377         (JSC::JSArrayBufferView::ConstructionContext::ConstructionContext):
1378         * runtime/JSCell.h:
1379         (JSC::subspaceFor):
1380         * runtime/JSCellInlines.h:
1381         (JSC::JSCell::visitOutputConstraints):
1382         (JSC::JSCell::subspaceFor):
1383         (JSC::allocateCell):
1384         * runtime/JSDestructibleObject.h:
1385         (JSC::JSDestructibleObject::subspaceFor):
1386         * runtime/JSDestructibleObjectSubspace.cpp: Added.
1387         (JSC::JSDestructibleObjectSubspace::JSDestructibleObjectSubspace):
1388         (JSC::JSDestructibleObjectSubspace::~JSDestructibleObjectSubspace):
1389         (JSC::JSDestructibleObjectSubspace::finishSweep):
1390         (JSC::JSDestructibleObjectSubspace::destroy):
1391         * runtime/JSDestructibleObjectSubspace.h: Added.
1392         * runtime/JSObject.h:
1393         (JSC::JSObject::JSObject):
1394         * runtime/JSObjectInlines.h:
1395         * runtime/JSSegmentedVariableObject.h:
1396         * runtime/JSString.h:
1397         (JSC::JSString::subspaceFor):
1398         * runtime/JSStringSubspace.cpp: Added.
1399         (JSC::JSStringSubspace::JSStringSubspace):
1400         (JSC::JSStringSubspace::~JSStringSubspace):
1401         (JSC::JSStringSubspace::finishSweep):
1402         (JSC::JSStringSubspace::destroy):
1403         * runtime/JSStringSubspace.h: Added.
1404         * runtime/RegExpMatchesArray.h:
1405         (JSC::tryCreateUninitializedRegExpMatchesArray):
1406         * runtime/VM.cpp:
1407         (JSC::VM::VM):
1408         * runtime/VM.h:
1409
1410 2017-01-17  Michael Saboff  <msaboff@apple.com>
1411
1412         Nested parenthesized regular expressions with non-zero minimum counts appear to hang and use lots of memory
1413         https://bugs.webkit.org/show_bug.cgi?id=167125
1414
1415         Reviewed by Filip Pizlo.
1416
1417         Changed Yarr to handle nested parenthesized subexpressions where the minimum count is
1418         not 0 directly in the Yarr interpreter.  Previously we'd factor an expression like
1419         (a|b)+ into (a|b)(a|b)* with special handling for captures.  This factoring was done
1420         using a deep copy that doubled the size of the resulting expresion for each nested 
1421         parenthesized subexpression.  Now the Yarr interpreter can directly process a regexp
1422         like (a|b){2,42}.  
1423
1424         The parser will allow one level of nested, non-zero minimum, counted parenthesis using
1425         the old copy method.  After one level, it will generate parenthesis terms with a non-zero
1426         minimum.   Such an expression wasn't handled by the Yarr JIT before the change, so this
1427         change isn't a performance regression.
1428
1429         Added a minimum count to the YarrPattern and ByteTerm classes, and then factored that
1430         minimum into the interpreter.  A non-zero minimum is only handled by the Yarr interpreter.
1431         If the Yarr JIT see such a term, it punts back to the interpreter.
1432
1433         * yarr/YarrInterpreter.cpp:
1434         (JSC::Yarr::Interpreter::backtrackPatternCharacter):
1435         (JSC::Yarr::Interpreter::backtrackPatternCasedCharacter):
1436         (JSC::Yarr::Interpreter::matchCharacterClass):
1437         (JSC::Yarr::Interpreter::backtrackCharacterClass):
1438         (JSC::Yarr::Interpreter::matchBackReference):
1439         (JSC::Yarr::Interpreter::backtrackBackReference):
1440         (JSC::Yarr::Interpreter::matchParenthesesOnceBegin):
1441         (JSC::Yarr::Interpreter::matchParenthesesOnceEnd):
1442         (JSC::Yarr::Interpreter::backtrackParenthesesOnceBegin):
1443         (JSC::Yarr::Interpreter::backtrackParenthesesOnceEnd):
1444         (JSC::Yarr::Interpreter::matchParenthesesTerminalBegin):
1445         (JSC::Yarr::Interpreter::backtrackParenthesesTerminalBegin):
1446         (JSC::Yarr::Interpreter::matchParentheticalAssertionBegin):
1447         (JSC::Yarr::Interpreter::matchParentheticalAssertionEnd):
1448         (JSC::Yarr::Interpreter::backtrackParentheticalAssertionBegin):
1449         (JSC::Yarr::Interpreter::backtrackParentheticalAssertionEnd):
1450         (JSC::Yarr::Interpreter::matchParentheses):
1451         (JSC::Yarr::Interpreter::backtrackParentheses):
1452         (JSC::Yarr::Interpreter::matchDisjunction):
1453         (JSC::Yarr::ByteCompiler::atomPatternCharacter):
1454         (JSC::Yarr::ByteCompiler::atomCharacterClass):
1455         (JSC::Yarr::ByteCompiler::atomBackReference):
1456         (JSC::Yarr::ByteCompiler::atomParentheticalAssertionEnd):
1457         (JSC::Yarr::ByteCompiler::atomParenthesesSubpatternEnd):
1458         (JSC::Yarr::ByteCompiler::atomParenthesesOnceEnd):
1459         (JSC::Yarr::ByteCompiler::atomParenthesesTerminalEnd):
1460         (JSC::Yarr::ByteCompiler::emitDisjunction):
1461         * yarr/YarrInterpreter.h:
1462         (JSC::Yarr::ByteTerm::ByteTerm):
1463         * yarr/YarrJIT.cpp:
1464         (JSC::Yarr::YarrGenerator::generatePatternCharacterOnce):
1465         (JSC::Yarr::YarrGenerator::generatePatternCharacterFixed):
1466         (JSC::Yarr::YarrGenerator::generatePatternCharacterGreedy):
1467         (JSC::Yarr::YarrGenerator::backtrackPatternCharacterNonGreedy):
1468         (JSC::Yarr::YarrGenerator::generateCharacterClassFixed):
1469         (JSC::Yarr::YarrGenerator::generateCharacterClassGreedy):
1470         (JSC::Yarr::YarrGenerator::backtrackCharacterClassNonGreedy):
1471         (JSC::Yarr::YarrGenerator::generateTerm):
1472         (JSC::Yarr::YarrGenerator::backtrackTerm):
1473         (JSC::Yarr::YarrGenerator::generate):
1474         (JSC::Yarr::YarrGenerator::backtrack):
1475         (JSC::Yarr::YarrGenerator::opCompileParenthesesSubpattern):
1476         * yarr/YarrPattern.cpp:
1477         (JSC::Yarr::YarrPatternConstructor::copyTerm):
1478         (JSC::Yarr::YarrPatternConstructor::quantifyAtom):
1479         (JSC::Yarr::YarrPatternConstructor::checkForTerminalParentheses):
1480         (JSC::Yarr::YarrPattern::YarrPattern):
1481         * yarr/YarrPattern.h:
1482         (JSC::Yarr::PatternTerm::PatternTerm):
1483         (JSC::Yarr::PatternTerm::quantify):
1484         (JSC::Yarr::YarrPattern::reset):
1485
1486 2017-01-17  Joseph Pecoraro  <pecoraro@apple.com>
1487
1488         ENABLE(USER_TIMING) Not Defined for Apple Windows or OS X Ports
1489         https://bugs.webkit.org/show_bug.cgi?id=116551
1490         <rdar://problem/13949830>
1491
1492         Reviewed by Alex Christensen.
1493
1494         * Configurations/FeatureDefines.xcconfig:
1495
1496 2017-01-16  Filip Pizlo  <fpizlo@apple.com>
1497
1498         JSCell::classInfo() shouldn't have a bunch of mitigations for being called during destruction
1499         https://bugs.webkit.org/show_bug.cgi?id=167066
1500
1501         Reviewed by Keith Miller and Michael Saboff.
1502         
1503         This reduces the size of JSCell::classInfo() by half and removes some checks that
1504         this function previously had to do in case it was called from destructors.
1505         
1506         I changed all of the destructors so that they don't call JSCell::classInfo() and I
1507         added an assertion to JSCell::classInfo() to catch cases where someone called it
1508         from a destructor accidentally.
1509         
1510         This means that we only have one place in destruction that needs to know the class:
1511         the sweeper's call to the destructor.
1512         
1513         One of the trickiest outcomes of this is the need to support inherits() tests in
1514         JSObjectGetPrivate(), when it is called from the destructor callback on the object
1515         being destructed. JSObjectGetPrivate() is undefined behavior anyway if you use it
1516         on any dead-but-not-destructed object other than the one being destructed right
1517         now. The purpose of the inherits() tests is to distinguish between different kinds
1518         of CallbackObjects, which may have different kinds of base classes. I think that
1519         this was always subtly wrong - for example, if the object being destructed is a
1520         JSGlobalObject then it's not a DestructibleObject, is not in a destructor block,
1521         but does not have an immortal Structure - so classInfo() is not valid. This fixes
1522         the issue by having ~JSCallbackObject know its classInfo. It now stashes its
1523         classInfo in VM so that JSObjectGetPrivate can use that classInfo if it detects
1524         that it's being used on a currently-destructing object.
1525         
1526         That was the only really weird part of this patch. The rest is mostly removing
1527         illegal uses of jsCast<> in destructors. There were a few other genuine uses of
1528         classInfo() but they were in code that already knew how to get its classInfo()
1529         using other means:
1530         
1531         - You can still say structure()->classInfo(), and I use this form in code that
1532           knows that its StructureIsImmortal.
1533         
1534         - You can use this->classInfo() if it's overridden, like in subclasses of
1535           JSDestructibleObject.
1536         
1537         Rolling this back in because I think I fixed the crashes.
1538
1539         * API/JSAPIWrapperObject.mm:
1540         (JSAPIWrapperObjectHandleOwner::finalize):
1541         * API/JSCallbackObject.h:
1542         * API/JSCallbackObjectFunctions.h:
1543         (JSC::JSCallbackObject<Parent>::~JSCallbackObject):
1544         (JSC::JSCallbackObject<Parent>::init):
1545         * API/JSObjectRef.cpp:
1546         (classInfoPrivate):
1547         (JSObjectGetPrivate):
1548         (JSObjectSetPrivate):
1549         * bytecode/EvalCodeBlock.cpp:
1550         (JSC::EvalCodeBlock::destroy):
1551         * bytecode/FunctionCodeBlock.cpp:
1552         (JSC::FunctionCodeBlock::destroy):
1553         * bytecode/ModuleProgramCodeBlock.cpp:
1554         (JSC::ModuleProgramCodeBlock::destroy):
1555         * bytecode/ProgramCodeBlock.cpp:
1556         (JSC::ProgramCodeBlock::destroy):
1557         * bytecode/UnlinkedEvalCodeBlock.cpp:
1558         (JSC::UnlinkedEvalCodeBlock::destroy):
1559         * bytecode/UnlinkedFunctionCodeBlock.cpp:
1560         (JSC::UnlinkedFunctionCodeBlock::destroy):
1561         * bytecode/UnlinkedFunctionExecutable.cpp:
1562         (JSC::UnlinkedFunctionExecutable::destroy):
1563         * bytecode/UnlinkedModuleProgramCodeBlock.cpp:
1564         (JSC::UnlinkedModuleProgramCodeBlock::destroy):
1565         * bytecode/UnlinkedProgramCodeBlock.cpp:
1566         (JSC::UnlinkedProgramCodeBlock::destroy):
1567         * heap/CodeBlockSet.cpp:
1568         (JSC::CodeBlockSet::lastChanceToFinalize):
1569         (JSC::CodeBlockSet::deleteUnmarkedAndUnreferenced):
1570         * heap/MarkedAllocator.cpp:
1571         (JSC::MarkedAllocator::allocateSlowCaseImpl):
1572         * heap/MarkedBlock.cpp:
1573         (JSC::MarkedBlock::Handle::sweep):
1574         * jit/JITThunks.cpp:
1575         (JSC::JITThunks::finalize):
1576         * runtime/AbstractModuleRecord.cpp:
1577         (JSC::AbstractModuleRecord::destroy):
1578         * runtime/ExecutableBase.cpp:
1579         (JSC::ExecutableBase::clearCode):
1580         * runtime/JSCellInlines.h:
1581         (JSC::JSCell::classInfo):
1582         (JSC::JSCell::callDestructor):
1583         * runtime/JSLock.h:
1584         (JSC::JSLock::ownerThread):
1585         * runtime/JSModuleNamespaceObject.cpp:
1586         (JSC::JSModuleNamespaceObject::destroy):
1587         * runtime/JSModuleRecord.cpp:
1588         (JSC::JSModuleRecord::destroy):
1589         * runtime/JSPropertyNameEnumerator.cpp:
1590         (JSC::JSPropertyNameEnumerator::destroy):
1591         * runtime/JSSegmentedVariableObject.h:
1592         * runtime/SymbolTable.cpp:
1593         (JSC::SymbolTable::destroy):
1594         * runtime/VM.h:
1595         * wasm/js/JSWebAssemblyCallee.cpp:
1596         (JSC::JSWebAssemblyCallee::destroy):
1597         * wasm/js/WebAssemblyModuleRecord.cpp:
1598         (JSC::WebAssemblyModuleRecord::destroy):
1599         * wasm/js/WebAssemblyToJSCallee.cpp:
1600         (JSC::WebAssemblyToJSCallee::WebAssemblyToJSCallee):
1601         (JSC::WebAssemblyToJSCallee::destroy):
1602
1603 2017-01-17  Filip Pizlo  <fpizlo@apple.com>
1604
1605         Unreviewed, roll out http://trac.webkit.org/changeset/210821
1606         It was causing crashes.
1607
1608         * API/JSAPIWrapperObject.mm:
1609         (JSAPIWrapperObjectHandleOwner::finalize):
1610         * API/JSCallbackObject.h:
1611         * API/JSCallbackObjectFunctions.h:
1612         (JSC::JSCallbackObject<Parent>::~JSCallbackObject):
1613         (JSC::JSCallbackObject<Parent>::init):
1614         * API/JSObjectRef.cpp:
1615         (JSObjectGetPrivate):
1616         (JSObjectSetPrivate):
1617         (classInfoPrivate): Deleted.
1618         * bytecode/EvalCodeBlock.cpp:
1619         (JSC::EvalCodeBlock::destroy):
1620         * bytecode/FunctionCodeBlock.cpp:
1621         (JSC::FunctionCodeBlock::destroy):
1622         * bytecode/ModuleProgramCodeBlock.cpp:
1623         (JSC::ModuleProgramCodeBlock::destroy):
1624         * bytecode/ProgramCodeBlock.cpp:
1625         (JSC::ProgramCodeBlock::destroy):
1626         * bytecode/UnlinkedEvalCodeBlock.cpp:
1627         (JSC::UnlinkedEvalCodeBlock::destroy):
1628         * bytecode/UnlinkedFunctionCodeBlock.cpp:
1629         (JSC::UnlinkedFunctionCodeBlock::destroy):
1630         * bytecode/UnlinkedFunctionExecutable.cpp:
1631         (JSC::UnlinkedFunctionExecutable::destroy):
1632         * bytecode/UnlinkedModuleProgramCodeBlock.cpp:
1633         (JSC::UnlinkedModuleProgramCodeBlock::destroy):
1634         * bytecode/UnlinkedProgramCodeBlock.cpp:
1635         (JSC::UnlinkedProgramCodeBlock::destroy):
1636         * heap/CodeBlockSet.cpp:
1637         (JSC::CodeBlockSet::lastChanceToFinalize):
1638         (JSC::CodeBlockSet::deleteUnmarkedAndUnreferenced):
1639         * heap/MarkedAllocator.cpp:
1640         (JSC::MarkedAllocator::allocateSlowCaseImpl):
1641         * heap/MarkedBlock.cpp:
1642         (JSC::MarkedBlock::Handle::sweep):
1643         * jit/JITThunks.cpp:
1644         (JSC::JITThunks::finalize):
1645         * runtime/AbstractModuleRecord.cpp:
1646         (JSC::AbstractModuleRecord::destroy):
1647         * runtime/ExecutableBase.cpp:
1648         (JSC::ExecutableBase::clearCode):
1649         * runtime/JSCellInlines.h:
1650         (JSC::JSCell::classInfo):
1651         (JSC::JSCell::callDestructor):
1652         * runtime/JSLock.h:
1653         (JSC::JSLock::exclusiveThread):
1654         (JSC::JSLock::ownerThread): Deleted.
1655         * runtime/JSModuleNamespaceObject.cpp:
1656         (JSC::JSModuleNamespaceObject::destroy):
1657         * runtime/JSModuleRecord.cpp:
1658         (JSC::JSModuleRecord::destroy):
1659         * runtime/JSPropertyNameEnumerator.cpp:
1660         (JSC::JSPropertyNameEnumerator::destroy):
1661         * runtime/JSSegmentedVariableObject.h:
1662         * runtime/SymbolTable.cpp:
1663         (JSC::SymbolTable::destroy):
1664         * runtime/VM.h:
1665         * wasm/js/JSWebAssemblyCallee.cpp:
1666         (JSC::JSWebAssemblyCallee::destroy):
1667         * wasm/js/WebAssemblyModuleRecord.cpp:
1668         (JSC::WebAssemblyModuleRecord::destroy):
1669         * wasm/js/WebAssemblyToJSCallee.cpp:
1670         (JSC::WebAssemblyToJSCallee::WebAssemblyToJSCallee):
1671         (JSC::WebAssemblyToJSCallee::destroy):
1672
1673 2017-01-16  Filip Pizlo  <fpizlo@apple.com>
1674
1675         JSCell::classInfo() shouldn't have a bunch of mitigations for being called during destruction
1676         https://bugs.webkit.org/show_bug.cgi?id=167066
1677
1678         Reviewed by Keith Miller and Michael Saboff.
1679         
1680         This reduces the size of JSCell::classInfo() by half and removes some checks that
1681         this function previously had to do in case it was called from destructors.
1682         
1683         I changed all of the destructors so that they don't call JSCell::classInfo() and I
1684         added an assertion to JSCell::classInfo() to catch cases where someone called it
1685         from a destructor accidentally.
1686         
1687         This means that we only have one place in destruction that needs to know the class:
1688         the sweeper's call to the destructor.
1689         
1690         One of the trickiest outcomes of this is the need to support inherits() tests in
1691         JSObjectGetPrivate(), when it is called from the destructor callback on the object
1692         being destructed. JSObjectGetPrivate() is undefined behavior anyway if you use it
1693         on any dead-but-not-destructed object other than the one being destructed right
1694         now. The purpose of the inherits() tests is to distinguish between different kinds
1695         of CallbackObjects, which may have different kinds of base classes. I think that
1696         this was always subtly wrong - for example, if the object being destructed is a
1697         JSGlobalObject then it's not a DestructibleObject, is not in a destructor block,
1698         but does not have an immortal Structure - so classInfo() is not valid. This fixes
1699         the issue by having ~JSCallbackObject know its classInfo. It now stashes its
1700         classInfo in VM so that JSObjectGetPrivate can use that classInfo if it detects
1701         that it's being used on a currently-destructing object.
1702         
1703         That was the only really weird part of this patch. The rest is mostly removing
1704         illegal uses of jsCast<> in destructors. There were a few other genuine uses of
1705         classInfo() but they were in code that already knew how to get its classInfo()
1706         using other means:
1707         
1708         - You can still say structure()->classInfo(), and I use this form in code that
1709           knows that its StructureIsImmortal.
1710         
1711         - You can use this->classInfo() if it's overridden, like in subclasses of
1712           JSDestructibleObject.
1713
1714         * API/JSAPIWrapperObject.mm:
1715         (JSAPIWrapperObjectHandleOwner::finalize):
1716         * API/JSCallbackObject.h:
1717         * API/JSCallbackObjectFunctions.h:
1718         (JSC::JSCallbackObject<Parent>::~JSCallbackObject):
1719         (JSC::JSCallbackObject<Parent>::init):
1720         * API/JSObjectRef.cpp:
1721         (classInfoPrivate):
1722         (JSObjectGetPrivate):
1723         (JSObjectSetPrivate):
1724         * bytecode/EvalCodeBlock.cpp:
1725         (JSC::EvalCodeBlock::destroy):
1726         * bytecode/FunctionCodeBlock.cpp:
1727         (JSC::FunctionCodeBlock::destroy):
1728         * bytecode/ModuleProgramCodeBlock.cpp:
1729         (JSC::ModuleProgramCodeBlock::destroy):
1730         * bytecode/ProgramCodeBlock.cpp:
1731         (JSC::ProgramCodeBlock::destroy):
1732         * bytecode/UnlinkedEvalCodeBlock.cpp:
1733         (JSC::UnlinkedEvalCodeBlock::destroy):
1734         * bytecode/UnlinkedFunctionCodeBlock.cpp:
1735         (JSC::UnlinkedFunctionCodeBlock::destroy):
1736         * bytecode/UnlinkedFunctionExecutable.cpp:
1737         (JSC::UnlinkedFunctionExecutable::destroy):
1738         * bytecode/UnlinkedModuleProgramCodeBlock.cpp:
1739         (JSC::UnlinkedModuleProgramCodeBlock::destroy):
1740         * bytecode/UnlinkedProgramCodeBlock.cpp:
1741         (JSC::UnlinkedProgramCodeBlock::destroy):
1742         * heap/CodeBlockSet.cpp:
1743         (JSC::CodeBlockSet::lastChanceToFinalize):
1744         (JSC::CodeBlockSet::deleteUnmarkedAndUnreferenced):
1745         * heap/MarkedAllocator.cpp:
1746         (JSC::MarkedAllocator::allocateSlowCaseImpl):
1747         * heap/MarkedBlock.cpp:
1748         (JSC::MarkedBlock::Handle::sweep):
1749         * jit/JITThunks.cpp:
1750         (JSC::JITThunks::finalize):
1751         * runtime/AbstractModuleRecord.cpp:
1752         (JSC::AbstractModuleRecord::destroy):
1753         * runtime/ExecutableBase.cpp:
1754         (JSC::ExecutableBase::clearCode):
1755         * runtime/JSCellInlines.h:
1756         (JSC::JSCell::classInfo):
1757         (JSC::JSCell::callDestructor):
1758         * runtime/JSLock.h:
1759         (JSC::JSLock::ownerThread):
1760         * runtime/JSModuleNamespaceObject.cpp:
1761         (JSC::JSModuleNamespaceObject::destroy):
1762         * runtime/JSModuleRecord.cpp:
1763         (JSC::JSModuleRecord::destroy):
1764         * runtime/JSPropertyNameEnumerator.cpp:
1765         (JSC::JSPropertyNameEnumerator::destroy):
1766         * runtime/JSSegmentedVariableObject.h:
1767         * runtime/SymbolTable.cpp:
1768         (JSC::SymbolTable::destroy):
1769         * runtime/VM.h:
1770         * wasm/js/JSWebAssemblyCallee.cpp:
1771         (JSC::JSWebAssemblyCallee::destroy):
1772         * wasm/js/WebAssemblyModuleRecord.cpp:
1773         (JSC::WebAssemblyModuleRecord::destroy):
1774         * wasm/js/WebAssemblyToJSCallee.cpp:
1775         (JSC::WebAssemblyToJSCallee::WebAssemblyToJSCallee):
1776         (JSC::WebAssemblyToJSCallee::destroy):
1777
1778 2017-01-16  Joseph Pecoraro  <pecoraro@apple.com>
1779
1780         Remove the REQUEST_ANIMATION_FRAME flag
1781         https://bugs.webkit.org/show_bug.cgi?id=156980
1782         <rdar://problem/25906849>
1783
1784         Reviewed by Simon Fraser.
1785
1786         * Configurations/FeatureDefines.xcconfig:
1787
1788 2017-01-14  Yusuke Suzuki  <utatane.tea@gmail.com>
1789
1790         WebAssembly: Suppress warnings & errors in GCC
1791         https://bugs.webkit.org/show_bug.cgi?id=167049
1792
1793         Reviewed by Sam Weinig.
1794
1795         * wasm/WasmFunctionParser.h:
1796         Add missing { } after the switch. Ideally, it is not necessary.
1797         But in GCC, it is required. Since this function is fairly large,
1798         I think the code generated by this does not cause performance
1799         regression.
1800
1801         * wasm/WasmPageCount.h:
1802         UINT_MAX is defined in limits.h.
1803
1804         * wasm/generateWasmValidateInlinesHeader.py:
1805         On the other hand, we use this suppress pragma here to solve the
1806         same problem in wasm/WasmFunctionParser.h. Since the load function
1807         is fairly small, the additional `return { };` may generate some
1808         suboptimal code. See bug 150794 for more detail.
1809
1810 2017-01-14  Yusuke Suzuki  <utatane.tea@gmail.com>
1811
1812         Reserve capacity for StringBuilder in unescape
1813         https://bugs.webkit.org/show_bug.cgi?id=167008
1814
1815         Reviewed by Sam Weinig.
1816
1817         `unescape` function is frequently called in Kraken sha256-iterative.
1818         This patch just reserves the capacity for the StringBuilder.
1819
1820         Currently, we select the length of the string for the reserved capacity.
1821         It improves the performance 2.73%.
1822
1823             Benchmark report for Kraken on sakura-trick.
1824
1825             VMs tested:
1826             "baseline" at /home/yusukesuzuki/dev/WebKit/WebKitBuild/untot/Release/bin/jsc
1827             "patched" at /home/yusukesuzuki/dev/WebKit/WebKitBuild/un/Release/bin/jsc
1828
1829             Collected 100 samples per benchmark/VM, with 100 VM invocations per benchmark. Emitted a call to gc() between
1830             sample measurements. Used 1 benchmark iteration per VM invocation for warm-up. Used the jsc-specific preciseTime()
1831             function to get microsecond-level timing. Reporting benchmark execution times with 95% confidence intervals in
1832             milliseconds.
1833
1834                                                        baseline                  patched
1835
1836             stanford-crypto-sha256-iterative        51.609+-0.672             50.237+-0.860           might be 1.0273x faster
1837
1838             <arithmetic>                            51.609+-0.672             50.237+-0.860           might be 1.0273x faster
1839
1840         * runtime/JSGlobalObjectFunctions.cpp:
1841         (JSC::globalFuncUnescape):
1842
1843 2017-01-13  Joseph Pecoraro  <pecoraro@apple.com>
1844
1845         Remove ENABLE(DETAILS_ELEMENT) guards
1846         https://bugs.webkit.org/show_bug.cgi?id=167042
1847
1848         Reviewed by Alex Christensen.
1849
1850         * Configurations/FeatureDefines.xcconfig:
1851
1852 2017-01-11  Darin Adler  <darin@apple.com>
1853
1854         Remove PassRefPtr from more of "platform"
1855         https://bugs.webkit.org/show_bug.cgi?id=166809
1856
1857         Reviewed by Sam Weinig.
1858
1859         * inspector/JSInjectedScriptHost.h:
1860         (Inspector::JSInjectedScriptHost::impl): Simplified code since we don't need a
1861         const_cast here any more.
1862         * runtime/PrivateName.h:
1863         (JSC::PrivateName::uid): Ditto.
1864
1865 2017-01-13  Ryan Haddad  <ryanhaddad@apple.com>
1866
1867         Unreviewed, rolling out r210735.
1868
1869         This change introduced LayoutTest and JSC test flakiness.
1870
1871         Reverted changeset:
1872
1873         "Reserve capacity for StringBuilder in unescape"
1874         https://bugs.webkit.org/show_bug.cgi?id=167008
1875         http://trac.webkit.org/changeset/210735
1876
1877 2017-01-13  Saam Barati  <sbarati@apple.com>
1878
1879         Initialize the ArraySpecies watchpoint as Clear and transition to IsWatched once slice is called for the first time
1880         https://bugs.webkit.org/show_bug.cgi?id=167017
1881         <rdar://problem/30019309>
1882
1883         Reviewed by Keith Miller and Filip Pizlo.
1884
1885         This patch is to reverse the JSBench regression from r210695.
1886         
1887         The new state diagram for the array species watchpoint is as
1888         follows:
1889         
1890         1. On GlobalObject construction, it starts life out as ClearWatchpoint.
1891         2. When slice is called for the first time, we observe the state
1892         of the world, and either transition it to IsWatched if we were able
1893         to set up the object property conditions, or to IsInvalidated if we
1894         were not.
1895         3. The DFG compiler will now only lower slice as an intrinsic if
1896         it observed the speciesWatchpoint.state() as IsWatched.
1897         4. The IsWatched => IsInvalidated transition happens only when
1898         one of the object property condition watchpoints fire.
1899
1900         * dfg/DFGByteCodeParser.cpp:
1901         (JSC::DFG::ByteCodeParser::handleIntrinsicCall):
1902         * runtime/ArrayPrototype.cpp:
1903         (JSC::speciesWatchpointIsValid):
1904         (JSC::speciesConstructArray):
1905         (JSC::arrayProtoPrivateFuncConcatMemcpy):
1906         (JSC::ArrayPrototype::tryInitializeSpeciesWatchpoint):
1907         (JSC::ArrayPrototype::initializeSpeciesWatchpoint): Deleted.
1908         * runtime/ArrayPrototype.h:
1909         * runtime/JSGlobalObject.cpp:
1910         (JSC::JSGlobalObject::JSGlobalObject):
1911         (JSC::JSGlobalObject::init):
1912
1913 2017-01-13  Yusuke Suzuki  <utatane.tea@gmail.com>
1914
1915         Reserve capacity for StringBuilder in unescape
1916         https://bugs.webkit.org/show_bug.cgi?id=167008
1917
1918         Reviewed by Sam Weinig.
1919
1920         `unescape` function is frequently called in Kraken sha256-iterative.
1921         This patch just reserves the capacity for the StringBuilder.
1922
1923         Currently, we select the length of the string for the reserved capacity.
1924         It improves the performance 2.73%.
1925
1926             Benchmark report for Kraken on sakura-trick.
1927
1928             VMs tested:
1929             "baseline" at /home/yusukesuzuki/dev/WebKit/WebKitBuild/untot/Release/bin/jsc
1930             "patched" at /home/yusukesuzuki/dev/WebKit/WebKitBuild/un/Release/bin/jsc
1931
1932             Collected 100 samples per benchmark/VM, with 100 VM invocations per benchmark. Emitted a call to gc() between
1933             sample measurements. Used 1 benchmark iteration per VM invocation for warm-up. Used the jsc-specific preciseTime()
1934             function to get microsecond-level timing. Reporting benchmark execution times with 95% confidence intervals in
1935             milliseconds.
1936
1937                                                        baseline                  patched
1938
1939             stanford-crypto-sha256-iterative        51.609+-0.672             50.237+-0.860           might be 1.0273x faster
1940
1941             <arithmetic>                            51.609+-0.672             50.237+-0.860           might be 1.0273x faster
1942
1943         * runtime/JSGlobalObjectFunctions.cpp:
1944         (JSC::globalFuncUnescape):
1945
1946 2017-01-12  Saam Barati  <sbarati@apple.com>
1947
1948         Add a slice intrinsic to the DFG/FTL
1949         https://bugs.webkit.org/show_bug.cgi?id=166707
1950         <rdar://problem/29913445>
1951
1952         Reviewed by Filip Pizlo.
1953
1954         The gist of this patch is to inline Array.prototype.slice
1955         into the DFG/FTL. The implementation in the DFG-backend
1956         and FTLLowerDFGToB3 is just a straight forward implementation
1957         of what the C function is doing. The more interesting bits
1958         of this patch are setting up the proper watchpoints and conditions
1959         in the executing code to prove that its safe to skip all of the
1960         observable JS actions that Array.prototype.slice normally does.
1961         
1962         We perform the following proofs:
1963         1. Array.prototype.constructor has not changed (via a watchpoint).
1964         2. That Array.prototype.constructor[Symbol.species] has not changed (via a watchpoint).
1965         3. The global object is not having a bad time.
1966         4. The array that is being sliced has an original array structure.
1967         5. Array.prototype/Object.prototype have not transitioned.
1968         
1969         Conditions 1, 2, and 3 are strictly required.
1970         
1971         4 is ensuring a couple things:
1972         1. That a "constructor" property hasn't been added to the array
1973         we're slicing since we're supposed to perform a Get(array, "constructor").
1974         2. That we're not slicing an instance of a subclass of Array.
1975         
1976         We could relax 4.1 in the future if we find other ways to test if
1977         the incoming array hasn't changed the "constructor" property. We
1978         would probably use TryGetById to do this.
1979         
1980         I'm seeing a 5% speedup on crypto-pbkdf2 and often a 1% speedup on
1981         the total benchmark (the results are sometimes noisy).
1982
1983         * dfg/DFGAbstractInterpreterInlines.h:
1984         (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
1985         * dfg/DFGByteCodeParser.cpp:
1986         (JSC::DFG::ByteCodeParser::handleIntrinsicCall):
1987         * dfg/DFGCallArrayAllocatorSlowPathGenerator.h:
1988         (JSC::DFG::CallArrayAllocatorWithVariableStructureVariableSizeSlowPathGenerator::CallArrayAllocatorWithVariableStructureVariableSizeSlowPathGenerator):
1989         * dfg/DFGClobberize.h:
1990         (JSC::DFG::clobberize):
1991         * dfg/DFGDoesGC.cpp:
1992         (JSC::DFG::doesGC):
1993         * dfg/DFGFixupPhase.cpp:
1994         (JSC::DFG::FixupPhase::fixupNode):
1995         * dfg/DFGNodeType.h:
1996         * dfg/DFGPredictionPropagationPhase.cpp:
1997         * dfg/DFGSafeToExecute.h:
1998         (JSC::DFG::safeToExecute):
1999         * dfg/DFGSpeculativeJIT.cpp:
2000         (JSC::DFG::SpeculativeJIT::compileArraySlice):
2001         (JSC::DFG::SpeculativeJIT::emitAllocateButterfly):
2002         * dfg/DFGSpeculativeJIT.h:
2003         * dfg/DFGSpeculativeJIT32_64.cpp:
2004         (JSC::DFG::SpeculativeJIT::compile):
2005         (JSC::DFG::SpeculativeJIT::emitInitializeButterfly):
2006         (JSC::DFG::SpeculativeJIT::compileAllocateNewArrayWithSize):
2007         * dfg/DFGSpeculativeJIT64.cpp:
2008         (JSC::DFG::SpeculativeJIT::compile):
2009         (JSC::DFG::SpeculativeJIT::emitInitializeButterfly):
2010         (JSC::DFG::SpeculativeJIT::compileAllocateNewArrayWithSize):
2011         * ftl/FTLAbstractHeapRepository.h:
2012         * ftl/FTLCapabilities.cpp:
2013         (JSC::FTL::canCompile):
2014         * ftl/FTLLowerDFGToB3.cpp:
2015         (JSC::FTL::DFG::LowerDFGToB3::compileNode):
2016         (JSC::FTL::DFG::LowerDFGToB3::compileArraySlice):
2017         (JSC::FTL::DFG::LowerDFGToB3::compileNewArrayWithSize):
2018         (JSC::FTL::DFG::LowerDFGToB3::compileMaterializeNewObject):
2019         (JSC::FTL::DFG::LowerDFGToB3::initializeArrayElements):
2020         (JSC::FTL::DFG::LowerDFGToB3::storeStructure):
2021         (JSC::FTL::DFG::LowerDFGToB3::allocateCell):
2022         (JSC::FTL::DFG::LowerDFGToB3::allocateObject):
2023         (JSC::FTL::DFG::LowerDFGToB3::allocateJSArray):
2024         (JSC::FTL::DFG::LowerDFGToB3::allocateUninitializedContiguousJSArray):
2025         * jit/AssemblyHelpers.cpp:
2026         (JSC::AssemblyHelpers::emitLoadStructure):
2027         * runtime/ArrayPrototype.cpp:
2028         (JSC::ArrayPrototype::finishCreation):
2029         (JSC::speciesWatchpointIsValid):
2030         (JSC::speciesConstructArray):
2031         (JSC::arrayProtoFuncSlice):
2032         (JSC::arrayProtoPrivateFuncConcatMemcpy):
2033         (JSC::ArrayPrototype::initializeSpeciesWatchpoint):
2034         (JSC::ArrayPrototypeAdaptiveInferredPropertyWatchpoint::handleFire):
2035         (JSC::speciesWatchpointsValid): Deleted.
2036         (JSC::ArrayPrototype::attemptToInitializeSpeciesWatchpoint): Deleted.
2037         * runtime/ArrayPrototype.h:
2038         (JSC::ArrayPrototype::speciesWatchpointStatus): Deleted.
2039         (): Deleted.
2040         * runtime/Intrinsic.h:
2041         * runtime/JSGlobalObject.cpp:
2042         (JSC::JSGlobalObject::JSGlobalObject):
2043         (JSC::JSGlobalObject::init):
2044         * runtime/JSGlobalObject.h:
2045         (JSC::JSGlobalObject::arraySpeciesWatchpoint):
2046         * runtime/Structure.h:
2047
2048 2017-01-12  Saam Barati  <sbarati@apple.com>
2049
2050         Concurrent GC has a bug where we would detect a race but fail to rescan the object
2051         https://bugs.webkit.org/show_bug.cgi?id=166960
2052         <rdar://problem/29983526>
2053
2054         Reviewed by Filip Pizlo and Mark Lam.
2055
2056         We have code like this in JSC:
2057         
2058         ```
2059         Butterfly* butterfly = allocateMoreOutOfLineStorage(vm, oldOutOfLineCapacity, newOutOfLineCapacity);
2060         nukeStructureAndSetButterfly(vm, structureID, butterfly);
2061         structure->setLastOffset(newLastOffset);
2062         WTF::storeStoreFence();
2063         setStructureIDDirectly(structureID);
2064         ```
2065         
2066         Note that the collector could detect a race here, which sometimes
2067         incorrectly caused us to not visit the object again.
2068         
2069         Mutator Thread: M, Collector Thread: C, assuming sequential consistency via
2070         proper barriers:
2071         
2072         M: allocate new butterfly
2073         M: Set nuked structure ID
2074         M: Set butterfly (this does a barrier)
2075         C: Start scanning O
2076         C: load structure ID
2077         C: See it's nuked and bail, (we used to rely on a write barrier to rescan).
2078         
2079         We sometimes never rescanned here because we were calling
2080         setStructureIDDirectly which doesn't do a write barrier.
2081         (Note, the places that do this but call setStructure were
2082         OK because setStructure will perform a write barrier.)
2083         
2084         (This same issue also existed in places where the collector thread
2085         detected races for Structure::m_offset, but places that changed
2086         Structure::m_offset didn't perform a write barrier on the object
2087         after changing its Structure's m_offset.)
2088         
2089         To prevent such code from requiring every call site to perform
2090         a write barrier on the object, I've changed the collector code
2091         to keep a stack of cells to be revisited due to races. This stack
2092         is then consulted when we do marking. Because such races are rare,
2093         we have a single stack on Heap that is guarded by a lock.
2094
2095         * heap/Heap.cpp:
2096         (JSC::Heap::Heap):
2097         (JSC::Heap::~Heap):
2098         (JSC::Heap::markToFixpoint):
2099         (JSC::Heap::endMarking):
2100         (JSC::Heap::buildConstraintSet):
2101         (JSC::Heap::addToRaceMarkStack):
2102         * heap/Heap.h:
2103         (JSC::Heap::collectorSlotVisitor):
2104         (JSC::Heap::mutatorMarkStack): Deleted.
2105         * heap/SlotVisitor.cpp:
2106         (JSC::SlotVisitor::didRace):
2107         * heap/SlotVisitor.h:
2108         (JSC::SlotVisitor::didRace):
2109         (JSC::SlotVisitor::didNotRace): Deleted.
2110         * heap/SlotVisitorInlines.h:
2111         (JSC::SlotVisitor::didNotRace): Deleted.
2112         * runtime/JSObject.cpp:
2113         (JSC::JSObject::visitButterfly):
2114         (JSC::JSObject::visitButterflyImpl):
2115         * runtime/JSObjectInlines.h:
2116         (JSC::JSObject::prepareToPutDirectWithoutTransition):
2117         * runtime/Structure.cpp:
2118         (JSC::Structure::flattenDictionaryStructure):
2119
2120 2017-01-12  Chris Dumez  <cdumez@apple.com>
2121
2122         Add KEYBOARD_KEY_ATTRIBUTE / KEYBOARD_CODE_ATTRIBUTE to FeatureDefines.xcconfig
2123         https://bugs.webkit.org/show_bug.cgi?id=166995
2124
2125         Reviewed by Jer Noble.
2126
2127         Add KEYBOARD_KEY_ATTRIBUTE / KEYBOARD_CODE_ATTRIBUTE to FeatureDefines.xcconfig
2128         as some people are having trouble building without it.
2129
2130         * Configurations/FeatureDefines.xcconfig:
2131
2132 2017-01-12  Yusuke Suzuki  <utatane.tea@gmail.com>
2133
2134         Implement InlineClassicScript
2135         https://bugs.webkit.org/show_bug.cgi?id=166925
2136
2137         Reviewed by Ryosuke Niwa.
2138
2139         Add ScriptFetcher field for SourceOrigin.
2140
2141         * runtime/SourceOrigin.h:
2142         (JSC::SourceOrigin::SourceOrigin):
2143         (JSC::SourceOrigin::fetcher):
2144
2145 2017-01-11  Andreas Kling  <akling@apple.com>
2146
2147         Crash when WebCore's GC heap grows way too large.
2148         <https://webkit.org/b/166875>
2149         <rdar://problem/27896585>
2150
2151         Reviewed by Mark Lam.
2152
2153         Add a simple API to JSC::Heap that allows setting a hard limit on the amount
2154         of live bytes. If this is exceeded, we crash with a recognizable signature.
2155         By default there is no limit.
2156
2157         * heap/Heap.cpp:
2158         (JSC::Heap::didExceedMaxLiveSize):
2159         (JSC::Heap::updateAllocationLimits):
2160         * heap/Heap.h:
2161         (JSC::Heap::setMaxLiveSize):
2162
2163 2017-01-11  Yusuke Suzuki  <utatane.tea@gmail.com>
2164
2165         Decouple module loading initiator from ScriptElement
2166         https://bugs.webkit.org/show_bug.cgi?id=166888
2167
2168         Reviewed by Saam Barati and Ryosuke Niwa.
2169
2170         Add ScriptFetcher and JSScriptFetcher.
2171
2172         * CMakeLists.txt:
2173         * JavaScriptCore.xcodeproj/project.pbxproj:
2174         * builtins/ModuleLoaderPrototype.js:
2175         (requestFetch):
2176         (requestInstantiate):
2177         (requestSatisfy):
2178         (requestInstantiateAll):
2179         (requestLink):
2180         (moduleEvaluation):
2181         (loadAndEvaluateModule):
2182         (importModule):
2183         * llint/LLIntData.cpp:
2184         (JSC::LLInt::Data::performAssertions):
2185         * llint/LowLevelInterpreter.asm:
2186         * runtime/Completion.cpp:
2187         (JSC::loadAndEvaluateModule):
2188         (JSC::loadModule):
2189         (JSC::linkAndEvaluateModule):
2190         * runtime/Completion.h:
2191         * runtime/JSModuleLoader.cpp:
2192         (JSC::JSModuleLoader::loadAndEvaluateModule):
2193         (JSC::JSModuleLoader::loadModule):
2194         (JSC::JSModuleLoader::linkAndEvaluateModule):
2195         (JSC::JSModuleLoader::resolve):
2196         (JSC::JSModuleLoader::fetch):
2197         (JSC::JSModuleLoader::instantiate):
2198         (JSC::JSModuleLoader::evaluate):
2199         * runtime/JSModuleLoader.h:
2200         * runtime/JSScriptFetcher.cpp: Copied from Source/WebCore/dom/LoadableScript.cpp.
2201         (JSC::JSScriptFetcher::destroy):
2202         * runtime/JSScriptFetcher.h: Added.
2203         (JSC::JSScriptFetcher::createStructure):
2204         (JSC::JSScriptFetcher::create):
2205         (JSC::JSScriptFetcher::fetcher):
2206         (JSC::JSScriptFetcher::JSScriptFetcher):
2207         * runtime/JSType.h:
2208         * runtime/ScriptFetcher.h: Copied from Source/WebCore/dom/LoadableScript.cpp.
2209         (JSC::ScriptFetcher::~ScriptFetcher):
2210         * runtime/VM.cpp:
2211         (JSC::VM::VM):
2212         * runtime/VM.h:
2213
2214 2017-01-10  Yusuke Suzuki  <utatane.tea@gmail.com>
2215
2216         Implement JSSourceCode to propagate SourceCode in module pipeline
2217         https://bugs.webkit.org/show_bug.cgi?id=166861
2218
2219         Reviewed by Saam Barati.
2220
2221         Instead of propagating source code string, we propagate JSSourceCode
2222         cell in the module pipeline. This allows us to attach a metadata
2223         to the propagated source code string. In particular, it propagates
2224         SourceOrigin through the module pipeline.
2225
2226         And it also fixes JSC shell to use Module source type for module source code.
2227
2228         * CMakeLists.txt:
2229         * JavaScriptCore.xcodeproj/project.pbxproj:
2230         * builtins/ModuleLoaderPrototype.js:
2231         (fulfillFetch):
2232         (requestFetch):
2233         * jsc.cpp:
2234         (GlobalObject::moduleLoaderFetch):
2235         (runWithScripts):
2236         * llint/LLIntData.cpp:
2237         (JSC::LLInt::Data::performAssertions):
2238         * llint/LowLevelInterpreter.asm:
2239         * runtime/Completion.cpp:
2240         (JSC::loadAndEvaluateModule):
2241         (JSC::loadModule):
2242         * runtime/JSModuleLoader.cpp:
2243         (JSC::JSModuleLoader::provide):
2244         * runtime/JSModuleLoader.h:
2245         * runtime/JSSourceCode.cpp: Added.
2246         (JSC::JSSourceCode::destroy):
2247         * runtime/JSSourceCode.h: Added.
2248         (JSC::JSSourceCode::createStructure):
2249         (JSC::JSSourceCode::create):
2250         (JSC::JSSourceCode::sourceCode):
2251         (JSC::JSSourceCode::JSSourceCode):
2252         * runtime/JSType.h:
2253         * runtime/ModuleLoaderPrototype.cpp:
2254         (JSC::moduleLoaderPrototypeParseModule):
2255         * runtime/VM.cpp:
2256         (JSC::VM::VM):
2257         * runtime/VM.h:
2258
2259 2017-01-10  Commit Queue  <commit-queue@webkit.org>
2260
2261         Unreviewed, rolling out r210052.
2262         https://bugs.webkit.org/show_bug.cgi?id=166915
2263
2264         "breaks web compatability" (Requested by keith_miller on
2265         #webkit).
2266
2267         Reverted changeset:
2268
2269         "Add support for global"
2270         https://bugs.webkit.org/show_bug.cgi?id=165171
2271         http://trac.webkit.org/changeset/210052
2272
2273 2017-01-10  Sam Weinig  <sam@webkit.org>
2274
2275         [WebIDL] Remove most of the custom bindings for the WebGL code
2276         https://bugs.webkit.org/show_bug.cgi?id=166834
2277
2278         Reviewed by Alex Christensen.
2279
2280         * runtime/ArrayPrototype.h:
2281         * runtime/ObjectPrototype.h:
2282         Export the ClassInfo so it can be used from WebCore.
2283
2284 2017-01-09  Filip Pizlo  <fpizlo@apple.com>
2285
2286         Streamline the GC barrier slowpath
2287         https://bugs.webkit.org/show_bug.cgi?id=166878
2288
2289         Reviewed by Geoffrey Garen and Saam Barati.
2290         
2291         This implements two optimizations to the barrier:
2292         
2293         - Removes the write barrier buffer. This was just overhead.
2294         
2295         - Teaches the slow path how to white an object that was black but unmarked, ensuring that
2296           we don't take slow path for this object again.
2297
2298         * JavaScriptCore.xcodeproj/project.pbxproj:
2299         * dfg/DFGSpeculativeJIT.cpp:
2300         (JSC::DFG::SpeculativeJIT::compileStoreBarrier):
2301         * ftl/FTLLowerDFGToB3.cpp:
2302         (JSC::FTL::DFG::LowerDFGToB3::emitStoreBarrier):
2303         * heap/CellState.h:
2304         * heap/Heap.cpp:
2305         (JSC::Heap::Heap):
2306         (JSC::Heap::markToFixpoint):
2307         (JSC::Heap::addToRememberedSet):
2308         (JSC::Heap::stopTheWorld):
2309         (JSC::Heap::writeBarrierSlowPath):
2310         (JSC::Heap::buildConstraintSet):
2311         (JSC::Heap::flushWriteBarrierBuffer): Deleted.
2312         * heap/Heap.h:
2313         (JSC::Heap::writeBarrierBuffer): Deleted.
2314         * heap/SlotVisitor.cpp:
2315         (JSC::SlotVisitor::appendJSCellOrAuxiliary):
2316         (JSC::SlotVisitor::setMarkedAndAppendToMarkStack):
2317         (JSC::SlotVisitor::appendToMarkStack):
2318         (JSC::SlotVisitor::visitChildren):
2319         * heap/WriteBarrierBuffer.cpp: Removed.
2320         * heap/WriteBarrierBuffer.h: Removed.
2321         * jit/JITOperations.cpp:
2322         * jit/JITOperations.h:
2323         * runtime/JSCellInlines.h:
2324         (JSC::JSCell::JSCell):
2325         * runtime/StructureIDBlob.h:
2326         (JSC::StructureIDBlob::StructureIDBlob):
2327
2328 2017-01-10  Mark Lam  <mark.lam@apple.com>
2329
2330         Property setters should not be called for bound arguments list entries.
2331         https://bugs.webkit.org/show_bug.cgi?id=165631
2332
2333         Reviewed by Filip Pizlo.
2334
2335         * builtins/FunctionPrototype.js:
2336         (bind):
2337         - use @putByValDirect to set the bound arguments so that we don't consult the
2338           prototype chain for setters.
2339
2340         * runtime/IntlDateTimeFormatPrototype.cpp:
2341         (JSC::IntlDateTimeFormatPrototypeGetterFormat):
2342         * runtime/IntlNumberFormatPrototype.cpp:
2343         (JSC::IntlNumberFormatPrototypeGetterFormat):
2344         - no need to create a bound arguments array because these bound functions binds
2345           no arguments according to the spec.
2346
2347 2017-01-10  Skachkov Oleksandr  <gskachkov@gmail.com>
2348
2349         Calling async arrow function which is in a class's member function will cause error
2350         https://bugs.webkit.org/show_bug.cgi?id=166879
2351
2352         Reviewed by Saam Barati.
2353
2354         Current patch fixed loading 'super' in async arrow function. Errored appear becuase 
2355         super was loaded always nevertherless if it used in async arrow function or not, but bytecompiler
2356         put to arrow function context only if it used within arrow function. So to fix this issue we need to 
2357         check if super was used in arrow function. 
2358
2359         * bytecompiler/BytecodeGenerator.h:
2360         * bytecompiler/NodesCodegen.cpp:
2361         (JSC::FunctionNode::emitBytecode):
2362
2363 2017-01-10  Commit Queue  <commit-queue@webkit.org>
2364
2365         Unreviewed, rolling out r210537.
2366         https://bugs.webkit.org/show_bug.cgi?id=166903
2367
2368         This change introduced JSC test failures (Requested by
2369         ryanhaddad on #webkit).
2370
2371         Reverted changeset:
2372
2373         "Implement JSSourceCode to propagate SourceCode in module
2374         pipeline"
2375         https://bugs.webkit.org/show_bug.cgi?id=166861
2376         http://trac.webkit.org/changeset/210537
2377
2378 2017-01-10  Commit Queue  <commit-queue@webkit.org>
2379
2380         Unreviewed, rolling out r210540.
2381         https://bugs.webkit.org/show_bug.cgi?id=166896
2382
2383         too crude for non-WebCore clients (Requested by kling on
2384         #webkit).
2385
2386         Reverted changeset:
2387
2388         "Crash when GC heap grows way too large."
2389         https://bugs.webkit.org/show_bug.cgi?id=166875
2390         http://trac.webkit.org/changeset/210540
2391
2392 2017-01-09  Filip Pizlo  <fpizlo@apple.com>
2393
2394         JSArray has some object scanning races
2395         https://bugs.webkit.org/show_bug.cgi?id=166874
2396
2397         Reviewed by Mark Lam.
2398         
2399         This fixes two separate bugs, both of which I detected by running
2400         array-splice-contiguous.js in extreme anger:
2401         
2402         1) Some of the paths of shifting and unshifting were not grabbing the internal cell
2403            lock. This was causing the array storage scan to crash, even though it was well
2404            synchronized (the scan does hold the lock). The fix is just to hold the lock anywhere
2405            that memmoves the innards of the butterfly.
2406         
2407         2) Out of line property scanning was synchronized using double collect snapshot. Array
2408            storage scanning was synchronized using locks. But what if array storage
2409            transformations messed up the out of line properties? It turns out that we actually
2410            need to hoist the array storage scanner's locking up into the double collect
2411            snapshot.
2412         
2413         I don't know how to write a test that does any better of a job of catching this than
2414         array-splice-contiguous.js.
2415
2416         * heap/DeferGC.h: Make DisallowGC usable even if NDEBUG.
2417         * runtime/JSArray.cpp:
2418         (JSC::JSArray::unshiftCountSlowCase):
2419         (JSC::JSArray::shiftCountWithArrayStorage):
2420         (JSC::JSArray::unshiftCountWithArrayStorage):
2421         * runtime/JSObject.cpp:
2422         (JSC::JSObject::visitButterflyImpl):
2423
2424 2017-01-10  Andreas Kling  <akling@apple.com>
2425
2426         Crash when GC heap grows way too large.
2427         <https://webkit.org/b/166875>
2428         <rdar://problem/27896585>
2429
2430         Reviewed by Mark Lam.
2431
2432         Hard cap the JavaScript heap at 4GB of live objects (determined post-GC.)
2433         If we go past this limit, crash with a recognizable signature.
2434
2435         * heap/Heap.cpp:
2436         (JSC::Heap::didExceedHeapSizeLimit):
2437         (JSC::Heap::updateAllocationLimits):
2438
2439 2017-01-09  Yusuke Suzuki  <utatane.tea@gmail.com>
2440
2441         Implement JSSourceCode to propagate SourceCode in module pipeline
2442         https://bugs.webkit.org/show_bug.cgi?id=166861
2443
2444         Reviewed by Saam Barati.
2445
2446         Instead of propagating source code string, we propagate JSSourceCode
2447         cell in the module pipeline. This allows us to attach a metadata
2448         to the propagated source code string. In particular, it propagates
2449         SourceOrigin through the module pipeline.
2450
2451         * CMakeLists.txt:
2452         * JavaScriptCore.xcodeproj/project.pbxproj:
2453         * builtins/ModuleLoaderPrototype.js:
2454         (fulfillFetch):
2455         (requestFetch):
2456         * jsc.cpp:
2457         (GlobalObject::moduleLoaderFetch):
2458         * llint/LLIntData.cpp:
2459         (JSC::LLInt::Data::performAssertions):
2460         * llint/LowLevelInterpreter.asm:
2461         * runtime/Completion.cpp:
2462         (JSC::loadAndEvaluateModule):
2463         (JSC::loadModule):
2464         * runtime/JSModuleLoader.cpp:
2465         (JSC::JSModuleLoader::provide):
2466         * runtime/JSModuleLoader.h:
2467         * runtime/JSSourceCode.cpp: Added.
2468         (JSC::JSSourceCode::destroy):
2469         * runtime/JSSourceCode.h: Added.
2470         (JSC::JSSourceCode::createStructure):
2471         (JSC::JSSourceCode::create):
2472         (JSC::JSSourceCode::sourceCode):
2473         (JSC::JSSourceCode::JSSourceCode):
2474         * runtime/JSType.h:
2475         * runtime/ModuleLoaderPrototype.cpp:
2476         (JSC::moduleLoaderPrototypeParseModule):
2477         * runtime/VM.cpp:
2478         (JSC::VM::VM):
2479         * runtime/VM.h:
2480
2481 2017-01-09  Yusuke Suzuki  <utatane.tea@gmail.com>
2482
2483         REGRESSION (r210522): ASSERTION FAILED: divot.offset >= divotStart.offset seen with stress/import-basic.js and stress/import-from-eval.js
2484         https://bugs.webkit.org/show_bug.cgi?id=166873
2485
2486         Reviewed by Saam Barati.
2487
2488         The divot should be the end of `import` token.
2489
2490         * parser/Parser.cpp:
2491         (JSC::Parser<LexerType>::parseMemberExpression):
2492
2493 2017-01-09  Filip Pizlo  <fpizlo@apple.com>
2494
2495         Unreviewed, fix cloop.
2496
2497         * dfg/DFGPlanInlines.h:
2498
2499 2017-01-09  Yusuke Suzuki  <utatane.tea@gmail.com>
2500
2501         [JSC] Prototype dynamic-import
2502         https://bugs.webkit.org/show_bug.cgi?id=165724
2503
2504         Reviewed by Saam Barati.
2505
2506         In this patch, we implement stage3 dynamic-import proposal[1].
2507         This patch adds a new special operator `import`. And by using it, we can import
2508         the module dynamically from modules and scripts. Before this feature, the module
2509         is always imported statically and before executing the modules, importing the modules
2510         needs to be done. And especially, the module can only be imported from the module.
2511         So the classic script cannot import and use the modules. This dynamic-import relaxes
2512         the above restrictions.
2513
2514         The typical dynamic-import form is the following.
2515
2516             import("...").then(function (namespace) { ... });
2517
2518         You can pass any AssignmentExpression for the import operator. So you can determine
2519         the importing modules dynamically.
2520
2521             import(value).then(function (namespace) { ... });
2522
2523         And previously the module import declaration is only allowed in the top level statements.
2524         But this import operator is just an expression. So you can use it in the function.
2525         And you can use it conditionally.
2526
2527             async function go(cond)
2528             {
2529                 if (cond)
2530                     return import("...");
2531                 return undefined;
2532             }
2533             await go(true);
2534
2535         Currently, this patch just implements this feature only for the JSC shell.
2536         JSC module loader requires a new hook, `importModule`. And the JSC shell implements
2537         this hook. So, for now, this dynamic-import is not available in the browser side.
2538         If you write this `import` call, it always returns the rejected promise.
2539
2540         import is implemented like a special operator similar to `super`.
2541         This is because import is context-sensitive. If you call the `import`, the module
2542         key resolution is done based on the caller's running context.
2543
2544         For example, if you are running the script which filename is "./ok/hello.js", the module
2545         key for the call`import("./resource/syntax.js")` becomes `"./ok/resource/syntax.js"`.
2546         But if you write the completely same import form in the script "./error/hello.js", the
2547         key becomes "./error/resource/syntax.js". So exposing this feature as the `import`
2548         function is misleading: this function becomes caller's context-sensitive. That's why
2549         dynamic-import is specified as a special operator.
2550
2551         To resolve the module key, we need the caller's context information like the filename of
2552         the caller. This is provided by the SourceOrigin implemented in r210149.
2553         In the JSC shell implementation, this SourceOrigin holds the filename of the caller. So
2554         based on this implementation, the module loader resolve the module key.
2555         In the near future, we will extend this SourceOrigin to hold more information needed for
2556         the browser-side import implementation.
2557
2558         [1]: https://tc39.github.io/proposal-dynamic-import/
2559
2560         * builtins/ModuleLoaderPrototype.js:
2561         (importModule):
2562         * bytecompiler/BytecodeGenerator.cpp:
2563         (JSC::BytecodeGenerator::emitGetTemplateObject):
2564         (JSC::BytecodeGenerator::emitGetGlobalPrivate):
2565         * bytecompiler/BytecodeGenerator.h:
2566         * bytecompiler/NodesCodegen.cpp:
2567         (JSC::ImportNode::emitBytecode):
2568         * jsc.cpp:
2569         (absolutePath):
2570         (GlobalObject::moduleLoaderImportModule):
2571         (functionRun):
2572         (functionLoad):
2573         (functionCheckSyntax):
2574         (runWithScripts):
2575         * parser/ASTBuilder.h:
2576         (JSC::ASTBuilder::createImportExpr):
2577         * parser/NodeConstructors.h:
2578         (JSC::ImportNode::ImportNode):
2579         * parser/Nodes.h:
2580         (JSC::ExpressionNode::isImportNode):
2581         * parser/Parser.cpp:
2582         (JSC::Parser<LexerType>::parseMemberExpression):
2583         * parser/SyntaxChecker.h:
2584         (JSC::SyntaxChecker::createImportExpr):
2585         * runtime/JSGlobalObject.cpp:
2586         (JSC::JSGlobalObject::init):
2587         * runtime/JSGlobalObject.h:
2588         * runtime/JSGlobalObjectFunctions.cpp:
2589         (JSC::globalFuncImportModule):
2590         * runtime/JSGlobalObjectFunctions.h:
2591         * runtime/JSModuleLoader.cpp:
2592         (JSC::JSModuleLoader::importModule):
2593         (JSC::JSModuleLoader::getModuleNamespaceObject):
2594         * runtime/JSModuleLoader.h:
2595         * runtime/ModuleLoaderPrototype.cpp:
2596         (JSC::moduleLoaderPrototypeGetModuleNamespaceObject):
2597
2598 2017-01-08  Filip Pizlo  <fpizlo@apple.com>
2599
2600         Make the collector's fixpoint smart about scheduling work
2601         https://bugs.webkit.org/show_bug.cgi?id=165910
2602
2603         Reviewed by Keith Miller.
2604         
2605         Prior to this change, every time the GC would run any constraints in markToFixpoint, it
2606         would run all of the constraints. It would always run them in the same order. That means
2607         that so long as any one constraint was generating new work, we'd pay the price of all
2608         constraints. This is usually OK because most constraints are cheap but it artificially
2609         inflates the cost of slow constraints - especially ones that are expensive but usually
2610         generate no new work.
2611         
2612         This patch redoes how the GC runs constraints by applying ideas from data flow analysis.
2613         The GC now builds a MarkingConstraintSet when it boots up, and this contains all of the
2614         constraints as well as some meta-data about them. Now, markToFixpoint just calls into
2615         MarkingConstraintSet to execute constraints. Because constraint execution and scheduling
2616         need to be aware of each other, I rewrote markToFixpoint in such a way that it's more
2617         obvious how the GC goes between constraint solving, marking with stopped mutator, and
2618         marking with resumed mutator. This also changes the scheduler API in such a way that a
2619         synchronous stop-the-world collection no longer needs to do fake stop/resume - instead we
2620         just swap the space-time scheduler for the stop-the-world scheduler.
2621         
2622         This is a big streamlining of the GC. This is a speed-up in GC-heavy tests because we
2623         now execute most constraints exactly twice regardless of how many total fixpoint
2624         iterations we do. Now, when we run out of marking work, the constraint solver will just
2625         run the constraint that is most likely to generate new visiting work, and if it does
2626         generate work, then the GC now goes back to marking. Before, it would run *all*
2627         constraints and then go back to marking. The constraint solver is armed with three
2628         information signals that it uses to sort the constraints in order of descending likelihood
2629         to generate new marking work. Then it runs them in that order until it there is new
2630         marking work. The signals are:
2631         
2632         1) Whether the constraint is greyed by marking or execution. We call this the volatility
2633            of the constraint. For example, weak reference constraints have GreyedByMarking as
2634            their volatility because they are most likely to have something to say after we've done
2635            some marking. On the other hand, conservative roots have GreyedByExecution as their
2636            volatility because they will give new information anytime we let the mutator run. The
2637            constraint solver will only run GreyedByExecution constraints as roots and after the
2638            GreyedByMarking constraints go silent. This ensures that we don't try to scan
2639            conservative roots every time we need to re-run weak references and vice-versa.
2640            
2641            Another way to look at it is that the constraint solver tries to predict if the
2642            wavefront is advancing or retreating. The wavefront is almost certainly advancing so
2643            long as the mark stacks are non-empty or so long as at least one of the GreyedByMarking
2644            constraints is still producing work. Otherwise the wavefront is almost certainly
2645            retreating. It's most profitable to run GreyedByMarking constraints when the wavefront
2646            is advancing, and most profitable to run GreyedByExecution constraints when the
2647            wavefront is retreating.
2648            
2649            We use the predicted wavefront direction and the volatility of constraints as a
2650            first-order signal of constraint profitability.
2651         
2652         2) How much visiting work was created the last time the constraint ran. The solver
2653            remembers the lastVisitCount, and uses it to predict how much work the constraint will
2654            generate next time. In practice this means we will keep re-running the one interesting
2655            constraint until it shuts up.
2656         
2657         3) Optional work predictors for some constraints. The constraint that shuffles the mutator
2658            mark stack into the main SlotVisitor's mutator mark stack always knows exactly how much
2659            work it will create.
2660            
2661            The sum of (2) and (3) are used as a second-order signal of constraint profitability.
2662         
2663         The constraint solver will always run all of the GreyedByExecution constraints at GC
2664         start, since these double as the GC's roots. The constraint solver will always run all of
2665         the GreyedByMarking constraints the first time that marking stalls. Other than that, the
2666         solver will keep running constraints, sorted according to their likelihood to create work,
2667         until either work is created or we run out of constraints to run. GC termination happens
2668         when we run out of constraints to run.
2669         
2670         This new infrastructure means that we have a much better chance of dealing with worst-case
2671         DOM pathologies. If we can intelligently factor different evil DOM things into different
2672         constraints with the right work predictions then this could reduce the cost of those DOM
2673         things by a factor of N where N is the number of fixpoint iterations the GC typically
2674         does. N is usually around 5-6 even for simple heaps.
2675         
2676         My perf measurements say:
2677         
2678         PLT3: 0.02% faster with 5.3% confidence.
2679         JetStream: 0.15% faster with 17% confidence.
2680         Speedometer: 0.58% faster with 82% confidence.
2681         
2682         Here are the details from JetStream:
2683         
2684         splay: 1.02173x faster with 0.996841 confidence
2685         splay-latency: 1.0617x faster with 0.987462 confidence
2686         towers.c: 1.01852x faster with 0.92128 confidence
2687         crypto-md5: 1.06058x faster with 0.482363 confidence
2688         score: 1.00152x faster with 0.16892 confidence
2689         
2690         I think that Speedometer is legitimately benefiting from this change based on looking at
2691         --logGC=true output. We are now spending less time reexecuting expensive constraints. I
2692         think that JetStream/splay is also benefiting, because although the constraints it sees
2693         are cheap, it spends 30% of its time in GC so even small improvements matter.
2694
2695         * CMakeLists.txt:
2696         * JavaScriptCore.xcodeproj/project.pbxproj:
2697         * dfg/DFGPlan.cpp:
2698         (JSC::DFG::Plan::markCodeBlocks): Deleted.
2699         (JSC::DFG::Plan::rememberCodeBlocks): Deleted.
2700         * dfg/DFGPlan.h:
2701         * dfg/DFGPlanInlines.h: Added.
2702         (JSC::DFG::Plan::iterateCodeBlocksForGC):
2703         * dfg/DFGWorklist.cpp:
2704         (JSC::DFG::Worklist::markCodeBlocks): Deleted.
2705         (JSC::DFG::Worklist::rememberCodeBlocks): Deleted.
2706         (JSC::DFG::rememberCodeBlocks): Deleted.
2707         * dfg/DFGWorklist.h:
2708         * dfg/DFGWorklistInlines.h: Added.
2709         (JSC::DFG::iterateCodeBlocksForGC):
2710         (JSC::DFG::Worklist::iterateCodeBlocksForGC):
2711         * heap/CodeBlockSet.cpp:
2712         (JSC::CodeBlockSet::writeBarrierCurrentlyExecuting): Deleted.
2713         * heap/CodeBlockSet.h:
2714         (JSC::CodeBlockSet::iterate): Deleted.
2715         * heap/CodeBlockSetInlines.h:
2716         (JSC::CodeBlockSet::iterate):
2717         (JSC::CodeBlockSet::iterateCurrentlyExecuting):
2718         * heap/Heap.cpp:
2719         (JSC::Heap::Heap):
2720         (JSC::Heap::iterateExecutingAndCompilingCodeBlocks):
2721         (JSC::Heap::iterateExecutingAndCompilingCodeBlocksWithoutHoldingLocks):
2722         (JSC::Heap::assertSharedMarkStacksEmpty):
2723         (JSC::Heap::markToFixpoint):
2724         (JSC::Heap::endMarking):
2725         (JSC::Heap::collectInThread):
2726         (JSC::Heap::stopIfNecessarySlow):
2727         (JSC::Heap::acquireAccessSlow):
2728         (JSC::Heap::collectIfNecessaryOrDefer):
2729         (JSC::Heap::buildConstraintSet):
2730         (JSC::Heap::notifyIsSafeToCollect):
2731         (JSC::Heap::ResumeTheWorldScope::ResumeTheWorldScope): Deleted.
2732         (JSC::Heap::ResumeTheWorldScope::~ResumeTheWorldScope): Deleted.
2733         (JSC::Heap::harvestWeakReferences): Deleted.
2734         (JSC::Heap::visitConservativeRoots): Deleted.
2735         (JSC::Heap::visitCompilerWorklistWeakReferences): Deleted.
2736         * heap/Heap.h:
2737         * heap/MarkingConstraint.cpp: Added.
2738         (JSC::MarkingConstraint::MarkingConstraint):
2739         (JSC::MarkingConstraint::~MarkingConstraint):
2740         (JSC::MarkingConstraint::resetStats):
2741         (JSC::MarkingConstraint::execute):
2742         * heap/MarkingConstraint.h: Added.
2743         (JSC::MarkingConstraint::index):
2744         (JSC::MarkingConstraint::abbreviatedName):
2745         (JSC::MarkingConstraint::name):
2746         (JSC::MarkingConstraint::lastVisitCount):
2747         (JSC::MarkingConstraint::quickWorkEstimate):
2748         (JSC::MarkingConstraint::workEstimate):
2749         (JSC::MarkingConstraint::volatility):
2750         * heap/MarkingConstraintSet.cpp: Added.
2751         (JSC::MarkingConstraintSet::ExecutionContext::ExecutionContext):
2752         (JSC::MarkingConstraintSet::ExecutionContext::didVisitSomething):
2753         (JSC::MarkingConstraintSet::ExecutionContext::shouldTimeOut):
2754         (JSC::MarkingConstraintSet::ExecutionContext::drain):
2755         (JSC::MarkingConstraintSet::ExecutionContext::didExecute):
2756         (JSC::MarkingConstraintSet::ExecutionContext::execute):
2757         (JSC::MarkingConstraintSet::MarkingConstraintSet):
2758         (JSC::MarkingConstraintSet::~MarkingConstraintSet):
2759         (JSC::MarkingConstraintSet::resetStats):
2760         (JSC::MarkingConstraintSet::add):
2761         (JSC::MarkingConstraintSet::executeBootstrap):
2762         (JSC::MarkingConstraintSet::executeConvergence):
2763         (JSC::MarkingConstraintSet::isWavefrontAdvancing):
2764         (JSC::MarkingConstraintSet::executeConvergenceImpl):
2765         (JSC::MarkingConstraintSet::executeAll):
2766         * heap/MarkingConstraintSet.h: Added.
2767         (JSC::MarkingConstraintSet::isWavefrontRetreating):
2768         * heap/MutatorScheduler.cpp: Added.
2769         (JSC::MutatorScheduler::MutatorScheduler):
2770         (JSC::MutatorScheduler::~MutatorScheduler):
2771         (JSC::MutatorScheduler::didStop):
2772         (JSC::MutatorScheduler::willResume):
2773         (JSC::MutatorScheduler::didExecuteConstraints):
2774         (JSC::MutatorScheduler::log):
2775         (JSC::MutatorScheduler::shouldStop):
2776         (JSC::MutatorScheduler::shouldResume):
2777         * heap/MutatorScheduler.h: Added.
2778         * heap/OpaqueRootSet.h:
2779         (JSC::OpaqueRootSet::add):
2780         * heap/SlotVisitor.cpp:
2781         (JSC::SlotVisitor::visitAsConstraint):
2782         (JSC::SlotVisitor::drain):
2783         (JSC::SlotVisitor::didReachTermination):
2784         (JSC::SlotVisitor::hasWork):
2785         (JSC::SlotVisitor::drainFromShared):
2786         (JSC::SlotVisitor::drainInParallelPassively):
2787         (JSC::SlotVisitor::addOpaqueRoot):
2788         * heap/SlotVisitor.h:
2789         (JSC::SlotVisitor::addToVisitCount):
2790         * heap/SpaceTimeMutatorScheduler.cpp: Copied from Source/JavaScriptCore/heap/SpaceTimeScheduler.cpp.
2791         (JSC::SpaceTimeMutatorScheduler::Snapshot::Snapshot):
2792         (JSC::SpaceTimeMutatorScheduler::Snapshot::now):
2793         (JSC::SpaceTimeMutatorScheduler::Snapshot::bytesAllocatedThisCycle):
2794         (JSC::SpaceTimeMutatorScheduler::SpaceTimeMutatorScheduler):
2795         (JSC::SpaceTimeMutatorScheduler::~SpaceTimeMutatorScheduler):
2796         (JSC::SpaceTimeMutatorScheduler::state):
2797         (JSC::SpaceTimeMutatorScheduler::beginCollection):
2798         (JSC::SpaceTimeMutatorScheduler::didStop):
2799         (JSC::SpaceTimeMutatorScheduler::willResume):
2800         (JSC::SpaceTimeMutatorScheduler::didExecuteConstraints):
2801         (JSC::SpaceTimeMutatorScheduler::timeToStop):
2802         (JSC::SpaceTimeMutatorScheduler::timeToResume):
2803         (JSC::SpaceTimeMutatorScheduler::log):
2804         (JSC::SpaceTimeMutatorScheduler::endCollection):
2805         (JSC::SpaceTimeMutatorScheduler::bytesAllocatedThisCycleImpl):
2806         (JSC::SpaceTimeMutatorScheduler::bytesSinceBeginningOfCycle):
2807         (JSC::SpaceTimeMutatorScheduler::maxHeadroom):
2808         (JSC::SpaceTimeMutatorScheduler::headroomFullness):
2809         (JSC::SpaceTimeMutatorScheduler::mutatorUtilization):
2810         (JSC::SpaceTimeMutatorScheduler::collectorUtilization):
2811         (JSC::SpaceTimeMutatorScheduler::elapsedInPeriod):
2812         (JSC::SpaceTimeMutatorScheduler::phase):
2813         (JSC::SpaceTimeMutatorScheduler::shouldBeResumed):
2814         (JSC::SpaceTimeScheduler::Decision::targetMutatorUtilization): Deleted.
2815         (JSC::SpaceTimeScheduler::Decision::targetCollectorUtilization): Deleted.
2816         (JSC::SpaceTimeScheduler::Decision::elapsedInPeriod): Deleted.
2817         (JSC::SpaceTimeScheduler::Decision::phase): Deleted.
2818         (JSC::SpaceTimeScheduler::Decision::shouldBeResumed): Deleted.
2819         (JSC::SpaceTimeScheduler::Decision::timeToResume): Deleted.
2820         (JSC::SpaceTimeScheduler::Decision::timeToStop): Deleted.
2821         (JSC::SpaceTimeScheduler::SpaceTimeScheduler): Deleted.
2822         (JSC::SpaceTimeScheduler::snapPhase): Deleted.
2823         (JSC::SpaceTimeScheduler::currentDecision): Deleted.
2824         * heap/SpaceTimeMutatorScheduler.h: Copied from Source/JavaScriptCore/heap/SpaceTimeScheduler.h.
2825         (JSC::SpaceTimeScheduler::Decision::operator bool): Deleted.
2826         * heap/SpaceTimeScheduler.cpp: Removed.
2827         * heap/SpaceTimeScheduler.h: Removed.
2828         * heap/SynchronousStopTheWorldMutatorScheduler.cpp: Added.
2829         (JSC::SynchronousStopTheWorldMutatorScheduler::SynchronousStopTheWorldMutatorScheduler):
2830         (JSC::SynchronousStopTheWorldMutatorScheduler::~SynchronousStopTheWorldMutatorScheduler):
2831         (JSC::SynchronousStopTheWorldMutatorScheduler::state):
2832         (JSC::SynchronousStopTheWorldMutatorScheduler::beginCollection):
2833         (JSC::SynchronousStopTheWorldMutatorScheduler::timeToStop):
2834         (JSC::SynchronousStopTheWorldMutatorScheduler::timeToResume):
2835         (JSC::SynchronousStopTheWorldMutatorScheduler::endCollection):
2836         * heap/SynchronousStopTheWorldMutatorScheduler.h: Added.
2837         * heap/VisitingTimeout.h: Added.
2838         (JSC::VisitingTimeout::VisitingTimeout):
2839         (JSC::VisitingTimeout::visitCount):
2840         (JSC::VisitingTimeout::didVisitSomething):
2841         (JSC::VisitingTimeout::shouldTimeOut):
2842         * runtime/Options.h:
2843
2844 2017-01-09  Commit Queue  <commit-queue@webkit.org>
2845
2846         Unreviewed, rolling out r210476.
2847         https://bugs.webkit.org/show_bug.cgi?id=166859
2848
2849         "4% JSBench regression" (Requested by keith_mi_ on #webkit).
2850
2851         Reverted changeset:
2852
2853         "Add a slice intrinsic to the DFG/FTL"
2854         https://bugs.webkit.org/show_bug.cgi?id=166707
2855         http://trac.webkit.org/changeset/210476
2856
2857 2017-01-08  Andreas Kling  <akling@apple.com>
2858
2859         Inject MarkedSpace size classes for a few more high-volume objects.
2860         <https://webkit.org/b/166815>
2861
2862         Reviewed by Darin Adler.
2863
2864         Add the following classes to the list of manually injected size classes:
2865
2866             - JSString
2867             - JSFunction
2868             - PropertyTable
2869             - Structure
2870
2871         Only Structure actually ends up with a new size class, the others already
2872         can't get any tighter due to the current MarkedBlock::atomSize being 16.
2873         I've put them in anyway to ensure that we have optimally carved-out cells
2874         for them in the future, should they grow.
2875
2876         With this change, Structures get allocated in 128-byte cells instead of
2877         160-byte cells, giving us 25% more Structures per MarkedBlock.
2878
2879         * heap/MarkedSpace.cpp:
2880
2881 2017-01-06  Saam Barati  <sbarati@apple.com>
2882
2883         Add a slice intrinsic to the DFG/FTL
2884         https://bugs.webkit.org/show_bug.cgi?id=166707
2885
2886         Reviewed by Filip Pizlo.
2887
2888         The gist of this patch is to inline Array.prototype.slice
2889         into the DFG/FTL. The implementation in the DFG-backend
2890         and FTLLowerDFGToB3 is just a straight forward implementation
2891         of what the C function is doing. The more interesting bits
2892         of this patch are setting up the proper watchpoints and conditions
2893         in the executing code to prove that its safe to skip all of the
2894         observable JS actions that Array.prototype.slice normally does.
2895         
2896         We perform the following proofs:
2897         1. Array.prototype.constructor has not changed (via a watchpoint).
2898         2. That Array.prototype.constructor[Symbol.species] has not changed (via a watchpoint).
2899         3. The global object is not having a bad time.
2900         3. The array that is being sliced has an original array structure.
2901         5. Array.prototype/Object.prototype have not transitioned.
2902         
2903         Conditions 1, 2, and 3 are strictly required.
2904         
2905         4 is ensuring a couple things:
2906         1. That a "constructor" property hasn't been added to the array
2907         we're slicing since we're supposed to perform a Get(array, "constructor").
2908         2. That we're not slicing an instance of a subclass of Array.
2909         
2910         We could relax 4.1 in the future if we find other ways to test if
2911         the incoming array hasn't changed the "constructor" property.
2912         
2913         I'm seeing a 5% speedup on crypto-pbkdf2 and often a 1% speedup on
2914         the total benchmark (the results are sometimes noisy).
2915
2916         * bytecode/ExitKind.cpp:
2917         (JSC::exitKindToString):
2918         * bytecode/ExitKind.h:
2919         * dfg/DFGAbstractInterpreterInlines.h:
2920         (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
2921         * dfg/DFGByteCodeParser.cpp:
2922         (JSC::DFG::ByteCodeParser::handleIntrinsicCall):
2923         * dfg/DFGClobberize.h:
2924         (JSC::DFG::clobberize):
2925         * dfg/DFGDoesGC.cpp:
2926         (JSC::DFG::doesGC):
2927         * dfg/DFGFixupPhase.cpp:
2928         (JSC::DFG::FixupPhase::fixupNode):
2929         * dfg/DFGNode.h:
2930         (JSC::DFG::Node::hasHeapPrediction):
2931         (JSC::DFG::Node::hasArrayMode):
2932         * dfg/DFGNodeType.h:
2933         * dfg/DFGPredictionPropagationPhase.cpp:
2934         * dfg/DFGSafeToExecute.h:
2935         (JSC::DFG::safeToExecute):
2936         * dfg/DFGSpeculativeJIT.cpp:
2937         (JSC::DFG::SpeculativeJIT::compileArraySlice):
2938         * dfg/DFGSpeculativeJIT.h:
2939         * dfg/DFGSpeculativeJIT32_64.cpp:
2940         (JSC::DFG::SpeculativeJIT::compile):
2941         * dfg/DFGSpeculativeJIT64.cpp:
2942         (JSC::DFG::SpeculativeJIT::compile):
2943         * ftl/FTLCapabilities.cpp:
2944         (JSC::FTL::canCompile):
2945         * ftl/FTLLowerDFGToB3.cpp:
2946         (JSC::FTL::DFG::LowerDFGToB3::compileNode):
2947         (JSC::FTL::DFG::LowerDFGToB3::compileArraySlice):
2948         * jit/AssemblyHelpers.cpp:
2949         (JSC::AssemblyHelpers::emitLoadStructure):
2950         * runtime/ArrayPrototype.cpp:
2951         (JSC::ArrayPrototype::finishCreation):
2952         (JSC::speciesWatchpointIsValid):
2953         (JSC::speciesConstructArray):
2954         (JSC::arrayProtoFuncSlice):
2955         (JSC::arrayProtoPrivateFuncConcatMemcpy):
2956         (JSC::ArrayPrototype::initializeSpeciesWatchpoint):
2957         (JSC::ArrayPrototypeAdaptiveInferredPropertyWatchpoint::handleFire):
2958         (JSC::speciesWatchpointsValid): Deleted.
2959         (JSC::ArrayPrototype::attemptToInitializeSpeciesWatchpoint): Deleted.
2960         * runtime/ArrayPrototype.h:
2961         (JSC::ArrayPrototype::speciesWatchpointStatus): Deleted.
2962         (): Deleted.
2963         * runtime/Intrinsic.h:
2964         * runtime/JSGlobalObject.cpp:
2965         (JSC::JSGlobalObject::JSGlobalObject):
2966         (JSC::JSGlobalObject::init):
2967         * runtime/JSGlobalObject.h:
2968         (JSC::JSGlobalObject::arraySpeciesWatchpoint):
2969
2970 2017-01-06  Mark Lam  <mark.lam@apple.com>
2971
2972         The ObjC API's JSVirtualMachine's map tables need to be guarded by a lock.
2973         https://bugs.webkit.org/show_bug.cgi?id=166778
2974         <rdar://problem/29761198>
2975
2976         Reviewed by Filip Pizlo.
2977
2978         Now that we have a concurrent GC, access to JSVirtualMachine's
2979         m_externalObjectGraph and m_externalRememberedSet need to be guarded by a lock
2980         since both the GC marker thread and the mutator thread may access them at the
2981         same time.
2982
2983         * API/JSVirtualMachine.mm:
2984         (-[JSVirtualMachine addExternalRememberedObject:]):
2985         (-[JSVirtualMachine addManagedReference:withOwner:]):
2986         (-[JSVirtualMachine removeManagedReference:withOwner:]):
2987         (-[JSVirtualMachine externalDataMutex]):
2988         (scanExternalObjectGraph):
2989         (scanExternalRememberedSet):
2990
2991         * API/JSVirtualMachineInternal.h:
2992         - Deleted externalObjectGraph method.  There's no need to expose this.
2993
2994 2017-01-06  Michael Saboff  <msaboff@apple.com>
2995
2996         @putByValDirect in Array.of and Array.from overwrites non-writable/configurable properties
2997         https://bugs.webkit.org/show_bug.cgi?id=153486
2998
2999         Reviewed by Saam Barati.
3000
3001         Moved read only check in putDirect() to all paths.
3002
3003         * runtime/SparseArrayValueMap.cpp:
3004         (JSC::SparseArrayValueMap::putDirect):
3005
3006 2016-12-30  Filip Pizlo  <fpizlo@apple.com>
3007
3008         DeferGC::~DeferGC should be super cheap
3009         https://bugs.webkit.org/show_bug.cgi?id=166626
3010
3011         Reviewed by Saam Barati.
3012         
3013         Right now, ~DeferGC requires running the collector's full collectIfNecessaryOrDefer()
3014         hook, which is super big. Normally, that hook would only be called from GC slow paths,
3015         so it ought to be possible to add complex logic to it. It benefits the GC algorithm to
3016         make that code smart, not necessarily fast.
3017
3018         The right thing for it to do is to have ~DeferGC check a boolean to see if
3019         collectIfNecessaryOrDefer() had previously deferred anything, and only call it if that
3020         is true. That's what this patch does.
3021         
3022         Unfortunately, this means that we lose the collectAccordingToDeferGCProbability mode,
3023         which we used for two tests. Since I could only see two tests that used this mode, I
3024         felt that it was better to enhance the GC than to keep the tests. I filed bug 166627 to
3025         bring back something like that mode.
3026         
3027         Although this patch does make some paths faster, its real goal is to ensure that bug
3028         165963 can add more logic to collectIfNecessaryOrDefer() without introducing a big
3029         regression. Until then, I wouldn't be surprised if this patch was a progression, but I'm
3030         not betting on it.
3031
3032         * heap/Heap.cpp:
3033         (JSC::Heap::collectIfNecessaryOrDefer):
3034         (JSC::Heap::decrementDeferralDepthAndGCIfNeededSlow):
3035         (JSC::Heap::canCollect): Deleted.
3036         (JSC::Heap::shouldCollectHeuristic): Deleted.
3037         (JSC::Heap::shouldCollect): Deleted.
3038         (JSC::Heap::collectAccordingToDeferGCProbability): Deleted.
3039         (JSC::Heap::decrementDeferralDepthAndGCIfNeeded): Deleted.
3040         * heap/Heap.h:
3041         * heap/HeapInlines.h:
3042         (JSC::Heap::incrementDeferralDepth):
3043         (JSC::Heap::decrementDeferralDepth):
3044         (JSC::Heap::decrementDeferralDepthAndGCIfNeeded):
3045         (JSC::Heap::mayNeedToStop):
3046         (JSC::Heap::stopIfNecessary):
3047         * runtime/Options.h:
3048
3049 2017-01-05  Filip Pizlo  <fpizlo@apple.com>
3050
3051         AutomaticThread timeout shutdown leaves a small window where notify() would think that the thread is still running
3052         https://bugs.webkit.org/show_bug.cgi?id=166742
3053
3054         Reviewed by Geoffrey Garen.
3055         
3056         Update to new AutomaticThread API.
3057
3058         * dfg/DFGWorklist.cpp:
3059
3060 2017-01-05  Per Arne Vollan  <pvollan@apple.com>
3061
3062         [Win] Compile error.
3063         https://bugs.webkit.org/show_bug.cgi?id=166726
3064
3065         Reviewed by Alex Christensen.
3066
3067         Add include folder.
3068
3069         * CMakeLists.txt:
3070
3071 2016-12-21  Brian Burg  <bburg@apple.com>
3072
3073         Web Inspector: teach the protocol generator about platform-specific types, events, and commands
3074         https://bugs.webkit.org/show_bug.cgi?id=166003
3075         <rdar://problem/28718990>
3076
3077         Reviewed by Joseph Pecoraro.
3078
3079         This patch implements parser, model, and generator-side changes to account for
3080         platform-specific types, events, and commands. The 'platform' property is parsed
3081         for top-level definitions and assumed to be the 'generic' platform if none is specified.
3082
3083         Since the generator's platform setting acts to filter definitions with an incompatible platform,
3084         all generators must be modified to consult a list of filtered types/commands/events for
3085         a domain instead of directly accessing Domain.{type_declarations, commands, events}. To prevent
3086         accidental misuse, hide those fields behind accessors (e.g., `all_type_declarations()`) so that they
3087         are still accessible if truly necessary, but not used by default and caused an error if not migrated.
3088
3089         * inspector/scripts/codegen/generate_cpp_alternate_backend_dispatcher_header.py:
3090         (CppAlternateBackendDispatcherHeaderGenerator._generate_handler_declarations_for_domain):
3091         * inspector/scripts/codegen/generate_cpp_backend_dispatcher_header.py:
3092         (CppBackendDispatcherHeaderGenerator.domains_to_generate):
3093         (CppBackendDispatcherHeaderGenerator._generate_handler_declarations_for_domain):
3094         (CppBackendDispatcherHeaderGenerator._generate_dispatcher_declarations_for_domain):
3095         * inspector/scripts/codegen/generate_cpp_backend_dispatcher_implementation.py:
3096         (CppBackendDispatcherImplementationGenerator.domains_to_generate):
3097         (CppBackendDispatcherImplementationGenerator._generate_dispatcher_implementations_for_domain):
3098         (CppBackendDispatcherImplementationGenerator._generate_small_dispatcher_switch_implementation_for_domain):
3099         (CppBackendDispatcherImplementationGenerator._generate_large_dispatcher_switch_implementation_for_domain):
3100         * inspector/scripts/codegen/generate_cpp_frontend_dispatcher_header.py:
3101         (CppFrontendDispatcherHeaderGenerator.domains_to_generate):
3102         (CppFrontendDispatcherHeaderGenerator._generate_dispatcher_declarations_for_domain):
3103         * inspector/scripts/codegen/generate_cpp_frontend_dispatcher_implementation.py:
3104         (CppFrontendDispatcherImplementationGenerator.domains_to_generate):
3105         (CppFrontendDispatcherImplementationGenerator._generate_dispatcher_implementations_for_domain):
3106         * inspector/scripts/codegen/generate_cpp_protocol_types_header.py:
3107         (CppProtocolTypesHeaderGenerator._generate_forward_declarations):
3108         (_generate_typedefs_for_domain):
3109         (_generate_builders_for_domain):
3110         (_generate_forward_declarations_for_binding_traits):
3111         (_generate_declarations_for_enum_conversion_methods):
3112         * inspector/scripts/codegen/generate_cpp_protocol_types_implementation.py:
3113         (CppProtocolTypesImplementationGenerator._generate_enum_conversion_methods_for_domain):
3114         (CppProtocolTypesImplementationGenerator._generate_open_field_names):
3115         (CppProtocolTypesImplementationGenerator._generate_builders_for_domain):
3116         * inspector/scripts/codegen/generate_js_backend_commands.py:
3117         (JSBackendCommandsGenerator.should_generate_domain):
3118         (JSBackendCommandsGenerator.domains_to_generate):
3119         (JSBackendCommandsGenerator.generate_domain):
3120         (JSBackendCommandsGenerator.domains_to_generate.should_generate_domain): Deleted.
3121         * inspector/scripts/codegen/generate_objc_backend_dispatcher_header.py:
3122         (ObjCBackendDispatcherHeaderGenerator.domains_to_generate):
3123         (ObjCBackendDispatcherHeaderGenerator._generate_objc_forward_declarations):
3124         (ObjCBackendDispatcherHeaderGenerator._generate_objc_handler_declarations_for_domain):
3125         * inspector/scripts/codegen/generate_objc_backend_dispatcher_implementation.py:
3126         (ObjCBackendDispatcherImplementationGenerator):
3127         (ObjCBackendDispatcherImplementationGenerator.domains_to_generate):
3128         (ObjCBackendDispatcherImplementationGenerator._generate_handler_implementation_for_domain):
3129         (ObjCConfigurationImplementationGenerator): Deleted.
3130         (ObjCConfigurationImplementationGenerator.__init__): Deleted.
3131         (ObjCConfigurationImplementationGenerator.output_filename): Deleted.
3132         (ObjCConfigurationImplementationGenerator.domains_to_generate): Deleted.
3133         (ObjCConfigurationImplementationGenerator.generate_output): Deleted.
3134         (ObjCConfigurationImplementationGenerator._generate_handler_implementation_for_domain): Deleted.
3135         (ObjCConfigurationImplementationGenerator._generate_handler_implementation_for_command): Deleted.
3136         (ObjCConfigurationImplementationGenerator._generate_success_block_for_command): Deleted.
3137         (ObjCConfigurationImplementationGenerator._generate_success_block_for_command.and): Deleted.
3138         (ObjCConfigurationImplementationGenerator._generate_conversions_for_command): Deleted.
3139         (ObjCConfigurationImplementationGenerator._generate_conversions_for_command.in_param_expression): Deleted.
3140         (ObjCConfigurationImplementationGenerator._generate_invocation_for_command): Deleted.
3141         * inspector/scripts/codegen/generate_objc_configuration_header.py:
3142         (ObjCConfigurationHeaderGenerator.generate_output):
3143         (ObjCConfigurationHeaderGenerator._generate_properties_for_domain):
3144         * inspector/scripts/codegen/generate_objc_configuration_implementation.py:
3145         (ObjCConfigurationImplementationGenerator):
3146         (ObjCConfigurationImplementationGenerator.generate_output):
3147         (ObjCConfigurationImplementationGenerator._generate_configuration_implementation_for_domains):
3148         (ObjCConfigurationImplementationGenerator._generate_ivars):
3149         (ObjCConfigurationImplementationGenerator._generate_dealloc):
3150         (ObjCBackendDispatcherImplementationGenerator): Deleted.
3151         (ObjCBackendDispatcherImplementationGenerator.__init__): Deleted.
3152         (ObjCBackendDispatcherImplementationGenerator.output_filename): Deleted.
3153         (ObjCBackendDispatcherImplementationGenerator.generate_output): Deleted.
3154         (ObjCBackendDispatcherImplementationGenerator._generate_configuration_implementation_for_domains): Deleted.
3155         (ObjCBackendDispatcherImplementationGenerator._generate_ivars): Deleted.
3156         (ObjCBackendDispatcherImplementationGenerator._generate_dealloc): Deleted.
3157         (ObjCBackendDispatcherImplementationGenerator._generate_handler_setter_for_domain): Deleted.
3158         (ObjCBackendDispatcherImplementationGenerator._generate_event_dispatcher_getter_for_domain): Deleted.
3159         (ObjCBackendDispatcherImplementationGenerator._variable_name_prefix_for_domain): Deleted.
3160         * inspector/scripts/codegen/generate_objc_frontend_dispatcher_implementation.py:
3161         (ObjCFrontendDispatcherImplementationGenerator.domains_to_generate):
3162         (ObjCFrontendDispatcherImplementationGenerator._generate_event_dispatcher_implementations):
3163         * inspector/scripts/codegen/generate_objc_header.py:
3164         (ObjCHeaderGenerator.generate_output):
3165         (ObjCHeaderGenerator._generate_forward_declarations):
3166         (ObjCHeaderGenerator._generate_enums):
3167         (ObjCHeaderGenerator._generate_types):
3168         (ObjCHeaderGenerator._generate_command_protocols):
3169         (ObjCHeaderGenerator._generate_event_interfaces):
3170         * inspector/scripts/codegen/generate_objc_internal_header.py:
3171         (ObjCInternalHeaderGenerator.generate_output):
3172         (ObjCInternalHeaderGenerator._generate_event_dispatcher_private_interfaces):
3173         * inspector/scripts/codegen/generate_objc_protocol_type_conversions_header.py:
3174         (ObjCProtocolTypeConversionsHeaderGenerator.domains_to_generate):
3175         (ObjCProtocolTypeConversionsHeaderGenerator._generate_enum_conversion_functions):
3176         * inspector/scripts/codegen/generate_objc_protocol_type_conversions_implementation.py:
3177         (ObjCProtocolTypeConversionsImplementationGenerator.domains_to_generate):
3178         (ObjCProtocolTypeConversionsImplementationGenerator._generate_type_factory_category_interface):
3179         (ObjCProtocolTypeConversionsImplementationGenerator._generate_type_factory_category_implementation):
3180         * inspector/scripts/codegen/generate_objc_protocol_types_implementation.py:
3181         (ObjCProtocolTypesImplementationGenerator.domains_to_generate):
3182         (ObjCProtocolTypesImplementationGenerator.generate_type_implementations):
3183
3184         * inspector/scripts/codegen/generator.py:
3185         (Generator.can_generate_platform):
3186         (Generator):
3187         (Generator.type_declarations_for_domain):
3188         (Generator.commands_for_domain):
3189         (Generator.events_for_domain):
3190         These are the core methods for computing whether a definition can be used given a target platform.
3191
3192         (Generator.calculate_types_requiring_shape_assertions):
3193         (Generator._traverse_and_assign_enum_values):
3194         * inspector/scripts/codegen/models.py:
3195         (Protocol.parse_type_declaration):
3196         (Protocol.parse_command):
3197         (Protocol.parse_event):
3198         (Protocol.resolve_types):
3199
3200         (Domain.__init__):
3201         (Domain):
3202         (Domain.all_type_declarations):
3203         (Domain.all_commands):
3204         (Domain.all_events):
3205         Hide fields behind these accessors so it's really obvious when we are ignoring platform filtering.
3206
3207         (Domain.resolve_type_references):
3208         (TypeDeclaration.__init__):
3209         (Command.__init__):
3210         (Event.__init__):
3211         * inspector/scripts/codegen/objc_generator.py:
3212         (ObjCGenerator.should_generate_types_for_domain):
3213         (ObjCGenerator):
3214         (ObjCGenerator.should_generate_commands_for_domain):
3215         (ObjCGenerator.should_generate_events_for_domain):
3216         (ObjCGenerator.should_generate_domain_types_filter): Deleted.
3217         (ObjCGenerator.should_generate_domain_types_filter.should_generate_domain_types): Deleted.
3218         (ObjCGenerator.should_generate_domain_command_handler_filter): Deleted.
3219         (ObjCGenerator.should_generate_domain_command_handler_filter.should_generate_domain_command_handler): Deleted.
3220         (ObjCGenerator.should_generate_domain_event_dispatcher_filter): Deleted.
3221         (ObjCGenerator.should_generate_domain_event_dispatcher_filter.should_generate_domain_event_dispatcher): Deleted.
3222         Clean up some messy code that essentially did the same definition filtering as we must do for platforms.
3223         This will be enhanced in a future patch so that platform filtering will take priority over the target framework.
3224
3225         The results above need rebaselining because the class names for two generators were swapped by accident.
3226         Fixing the names causes the order of generated files to change, and this generates ugly diffs because every
3227         generated file includes the same copyright block at the top.
3228
3229         * inspector/scripts/tests/generic/expected/commands-with-async-attribute.json-result:
3230         * inspector/scripts/tests/generic/expected/commands-with-optional-call-return-parameters.json-result:
3231         * inspector/scripts/tests/generic/expected/domains-with-varying-command-sizes.json-result:
3232         * inspector/scripts/tests/generic/expected/enum-values.json-result:
3233         * inspector/scripts/tests/generic/expected/events-with-optional-parameters.json-result:
3234         * inspector/scripts/tests/generic/expected/generate-domains-with-feature-guards.json-result:
3235         * inspector/scripts/tests/generic/expected/same-type-id-different-domain.json-result:
3236         * inspector/scripts/tests/generic/expected/shadowed-optional-type-setters.json-result:
3237         * inspector/scripts/tests/generic/expected/type-declaration-aliased-primitive-type.json-result:
3238         * inspector/scripts/tests/generic/expected/type-declaration-array-type.json-result:
3239         * inspector/scripts/tests/generic/expected/type-declaration-enum-type.json-result:
3240         * inspector/scripts/tests/generic/expected/type-declaration-object-type.json-result:
3241         * inspector/scripts/tests/generic/expected/type-requiring-runtime-casts.json-result:
3242
3243         * inspector/scripts/tests/generic/expected/fail-on-command-with-invalid-platform.json-error: Added.
3244         * inspector/scripts/tests/generic/expected/fail-on-type-with-invalid-platform.json-error: Added.
3245         * inspector/scripts/tests/generic/fail-on-command-with-invalid-platform.json: Added.
3246         * inspector/scripts/tests/generic/fail-on-type-with-invalid-platform.json: Added.
3247
3248         Add error test cases for invalid platforms in commands, types, and events.
3249
3250         * inspector/scripts/tests/generic/definitions-with-mac-platform.json: Added.
3251         * inspector/scripts/tests/generic/expected/definitions-with-mac-platform.json-result: Added.
3252         * inspector/scripts/tests/all/definitions-with-mac-platform.json: Added.
3253         * inspector/scripts/tests/all/expected/definitions-with-mac-platform.json-result: Added.
3254         * inspector/scripts/tests/ios/definitions-with-mac-platform.json: Added.
3255         * inspector/scripts/tests/ios/expected/definitions-with-mac-platform.json-result: Added.
3256         * inspector/scripts/tests/mac/definitions-with-mac-platform.json: Added.
3257         * inspector/scripts/tests/mac/expected/definitions-with-mac-platform.json-result: Added.
3258
3259         Add a basic 4-way test that generates code for each platform from the same specification.
3260         With 'macos' platform for each definition, only 'all' and 'mac' generate anything interesting.
3261
3262 2017-01-03  Brian Burg  <bburg@apple.com>
3263
3264         Web Inspector: teach the protocol generator about platform-specific types, events, and commands
3265         https://bugs.webkit.org/show_bug.cgi?id=166003