Please look into having the jump table at the end of the generated optimized code instead of inside the constant pool.
http://codereview.chromium.org/7021007/diff/1/src/arm/assembler-arm.cc File src/arm/assembler-arm.cc (right): http://codereview.chromium.org/7021007/diff/1/src/arm/assembler-arm.cc#newcode2649 src/arm/assembler-arm.cc:2649: // Emit the deoptimization jump table. This emitting of the deopt-jump table in parts inside the constant pool looks a bit complicated. Also we didn't used to have code in the constant pool. How about placing the whole jump table at the end of the code instead of interleaving it inside the constant pools? We will have to limit the max size of the generated code for optimized functions, but I don't think that is a problem. http://codereview.chromium.org/7021007/diff/1/src/arm/assembler-arm.cc#newcode2669 src/arm/assembler-arm.cc:2669: ASSERT(is_int24(imm24)); Please use the CodePatcher class for this. CodePatcher patcher(pc, 1); patcher.masm()->b(...) http://codereview.chromium.org/7021007/diff/1/src/arm/lithium-codegen-arm.cc File src/arm/lithium-codegen-arm.cc (right): http://codereview.chromium.org/7021007/diff/1/src/arm/lithium-codegen-arm.cc#newcode605 src/arm/lithium-codegen-arm.cc:605: } else { The x64 also uses a jump table, which is emitted at the end of the generated code. It also tries to use the same table slot more than once, as there often are several deopts to the same entry. http://codereview.chromium.org/7021007/ -- v8-dev mailing list [email protected] http://groups.google.com/group/v8-dev
