Title: [240740] trunk
- Revision
- 240740
- Author
- [email protected]
- Date
- 2019-01-30 16:49:26 -0800 (Wed, 30 Jan 2019)
Log Message
Object.keys can now lead to a PhantomNewArrayBuffer, OSR exit from the FTL should know how to materialize a NewArrayBuffer in that case
https://bugs.webkit.org/show_bug.cgi?id=194050
<rdar://problem/47595592>
JSTests:
Reviewed by Yusuke Suzuki.
* stress/object-keys-osr-exit.js: Added.
(foo):
(catch):
Source/_javascript_Core:
Following https://bugs.webkit.org/show_bug.cgi?id=190047, PhantomNewArrayBuffer is no longer guaranteed to originate from a NewArrayBuffer in the baseline jit.
It can now come from Object.keys, which is a function call. We must teach the FTL how to OSR exit in that case.
Reviewed by Yusuke Suzuki.
* ftl/FTLOperations.cpp:
(JSC::FTL::operationMaterializeObjectInOSR):
Modified Paths
Added Paths
Diff
Modified: trunk/JSTests/ChangeLog (240739 => 240740)
--- trunk/JSTests/ChangeLog 2019-01-31 00:46:59 UTC (rev 240739)
+++ trunk/JSTests/ChangeLog 2019-01-31 00:49:26 UTC (rev 240740)
@@ -1,3 +1,15 @@
+2019-01-30 Robin Morisset <[email protected]>
+
+ Object.keys can now lead to a PhantomNewArrayBuffer, OSR exit from the FTL should know how to materialize a NewArrayBuffer in that case
+ https://bugs.webkit.org/show_bug.cgi?id=194050
+ <rdar://problem/47595592>
+
+ Reviewed by Yusuke Suzuki.
+
+ * stress/object-keys-osr-exit.js: Added.
+ (foo):
+ (catch):
+
2019-01-29 Mark Lam <[email protected]>
ValueRecovery::recover() should purify NaN values it recovers.
Added: trunk/JSTests/stress/object-keys-osr-exit.js (0 => 240740)
--- trunk/JSTests/stress/object-keys-osr-exit.js (rev 0)
+++ trunk/JSTests/stress/object-keys-osr-exit.js 2019-01-31 00:49:26 UTC (rev 240740)
@@ -0,0 +1,22 @@
+//@ runDefault("--forceEagerCompilation=1", "--useConcurrentJIT=0")
+
+function foo(x) {
+ if (x) {
+ return;
+ }
+ let obj = {
+ a: 0,
+ b: 0
+ };
+ foo(1);
+ let keys = Object.keys(obj);
+ foo();
+ keys.length
+}
+
+try {
+ foo();
+} catch(e) {
+ if (e != "RangeError: Maximum call stack size exceeded.")
+ throw "FAILED";
+}
Modified: trunk/Source/_javascript_Core/ChangeLog (240739 => 240740)
--- trunk/Source/_javascript_Core/ChangeLog 2019-01-31 00:46:59 UTC (rev 240739)
+++ trunk/Source/_javascript_Core/ChangeLog 2019-01-31 00:49:26 UTC (rev 240740)
@@ -1,3 +1,17 @@
+2019-01-30 Robin Morisset <[email protected]>
+
+ Object.keys can now lead to a PhantomNewArrayBuffer, OSR exit from the FTL should know how to materialize a NewArrayBuffer in that case
+ https://bugs.webkit.org/show_bug.cgi?id=194050
+ <rdar://problem/47595592>
+
+ Following https://bugs.webkit.org/show_bug.cgi?id=190047, PhantomNewArrayBuffer is no longer guaranteed to originate from a NewArrayBuffer in the baseline jit.
+ It can now come from Object.keys, which is a function call. We must teach the FTL how to OSR exit in that case.
+
+ Reviewed by Yusuke Suzuki.
+
+ * ftl/FTLOperations.cpp:
+ (JSC::FTL::operationMaterializeObjectInOSR):
+
2019-01-30 Tadeu Zagallo <[email protected]>
Remove assertion that CachedSymbolTables should have no RareData
Modified: trunk/Source/_javascript_Core/ftl/FTLOperations.cpp (240739 => 240740)
--- trunk/Source/_javascript_Core/ftl/FTLOperations.cpp 2019-01-31 00:46:59 UTC (rev 240739)
+++ trunk/Source/_javascript_Core/ftl/FTLOperations.cpp 2019-01-31 00:49:26 UTC (rev 240740)
@@ -475,7 +475,13 @@
// and PhantomNewArrayBuffer are always bound to a specific op_new_array_buffer.
CodeBlock* codeBlock = baselineCodeBlockForOriginAndBaselineCodeBlock(materialization->origin(), exec->codeBlock()->baselineAlternative());
const Instruction* currentInstruction = codeBlock->instructions().at(materialization->origin().bytecodeIndex).ptr();
- RELEASE_ASSERT(currentInstruction->is<OpNewArrayBuffer>());
+ if (!currentInstruction->is<OpNewArrayBuffer>()) {
+ // This case can happen if Object.keys, an OpCall is first converted into a NewArrayBuffer which is then converted into a PhantomNewArrayBuffer.
+ // There is no need to update the array allocation profile in that case.
+ RELEASE_ASSERT(currentInstruction->is<OpCall>());
+ Structure* structure = exec->lexicalGlobalObject()->arrayStructureForIndexingTypeDuringAllocation(immutableButterfly->indexingMode());
+ return CommonSlowPaths::allocateNewArrayBuffer(vm, structure, immutableButterfly);
+ }
auto newArrayBuffer = currentInstruction->as<OpNewArrayBuffer>();
ArrayAllocationProfile* profile = ""
_______________________________________________
webkit-changes mailing list
[email protected]
https://lists.webkit.org/mailman/listinfo/webkit-changes
