Avoid constant pool blocking for too long
authorsgjesse@chromium.org <sgjesse@chromium.org@ce2b1a6d-e550-0410-aec6-3dcde31c8c00>
Tue, 27 Apr 2010 09:09:51 +0000 (09:09 +0000)
committersgjesse@chromium.org <sgjesse@chromium.org@ce2b1a6d-e550-0410-aec6-3dcde31c8c00>
Tue, 27 Apr 2010 09:09:51 +0000 (09:09 +0000)
commitdaf1ea3970cde3d196c8c9e1058c056a3affdc81
tree971d6618a55efb7ebc98ebf575579dece6255464
parente35fbc93c28053855b5e7d032211a1a32e64380a
Avoid constant pool blocking for too long

The generation of the deferred code for named property load where the load was inlined did a constant pool blocking for the whole deferred code. Having large numbers of this type of deferred code generated one ofter the other effectively blocked the constant pool for all the deferred code causing

Removed the BeforeGenerate/AfterGenerate for the deferred code and made macro assembler StartBlockConstPool/EndBlockConstPool non-public. Re-introduced BlockConstPoolFor instead to use with BlockConstPoolScope to block some more instructions cross function calls.

Also handle the use of native code counters for inlined named property load.
Review URL: http://codereview.chromium.org/1787005

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@4507 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
src/arm/assembler-arm.cc
src/arm/assembler-arm.h
src/arm/codegen-arm.cc
src/codegen.cc
src/codegen.h