Reviewers: danno, fschneider, Paul Lind, kisg,
Message:
We noticed that you changed the deoptimization table size to 8k.
Unfortunately
this change causes problems on MIPS, because this way the table becomes
larger
than the maximum possible direct jump offset. We see no regressions if we
change
this value back to the original 4k for the MIPS architecture. Could you
please
explain why this change was made, and whether you think it would be OK to
keep
using the old 4k size for 3.8? We are prepared to make changes to this
system
for future releases, but we feel that for the upcoming 3.8 release it is
probably better to just use the old, proven method, as long as it doesn't
cause
any problems.
Description:
MIPS: Reverted the number of deopt entries to 4096.
On MIPS we cannot double the number of deoptimization entries easily
because the generated code would contain long branches (>128K) and we use
BlockTrampolinePoolScope in the
Deoptimizer::TableEntryGenerator::GeneratePrologue method.
Also, we cannot use the Jr instruction here because the
Deoptimizer::CreateCode
method asserts
that the generated code does not contain reloc information.
BUG=
TEST=
Please review this at http://codereview.chromium.org/9169079/
Affected files:
M src/deoptimizer.h
Index: src/deoptimizer.h
diff --git a/src/deoptimizer.h b/src/deoptimizer.h
index
e2cf05367bdfc5c306e06cc97b29380dee4fd0d3..8b1152d52957a7da6e37ecb56c4a07d17767accd
100644
--- a/src/deoptimizer.h
+++ b/src/deoptimizer.h
@@ -267,7 +267,11 @@ class Deoptimizer : public Malloced {
int ConvertJSFrameIndexToFrameIndex(int jsframe_index);
private:
+#ifdef V8_TARGET_ARCH_MIPS
+ static const int kNumberOfEntries = 4096;
+#else
static const int kNumberOfEntries = 8192;
+#endif
Deoptimizer(Isolate* isolate,
JSFunction* function,
--
v8-dev mailing list
[email protected]
http://groups.google.com/group/v8-dev