Short term JSON eval cache

Short term JSON eval cache
BUG=none
TEST=none

[ulan, 2012-09-28 14:26:22]

High level comments first.

I see that you have a run-time function to query the cache stats. Did you run
experiments with popular websites? I wonder if the json cache improves
real-world performance.

I did a quick experiment by adding hit/query counters and browsed gmail and
nytimes, but didn't notice improvement in eval cache hits.

eval cache gmail:   133 (135) / 345 count, 66739 (66750) / 5327426 size
eval cache nytimes:   0 (116) / 343 count,     0 (23096) / 113576 size

The output format here is: "json cache hits" ("total eval cache hits") / ("total
queries").

Total eval cache hits for these websites were the same with and without this CL.
Maybe you have an example of a popular website except SunSpider, where the json
cache helps?

http://codereview.chromium.org/10990076/diff/1/src/v8.cc
File src/v8.cc (right):

http://codereview.chromium.org/10990076/diff/1/src/v8.cc#newcode195
src/v8.cc:195: return HEAP->IdleNotification(hint) &&
This concerns me. The embedder is not required to call IdleNotification. Our
heuristics should not rely on it. I think in normal Chrome browsing sessions,
IdleNotification rarely returns true. So the json eval cache will probably be
full most of the time. This could consume couple of MB in the worst case (512KB
of source + generated code for it).

[Jay Conrod, 2012-09-29 22:27:46]

We mainly focused on seeing performance improvement on Sunspider and ensuring
that other cases are at least neutral (no degradation) if there is no noticeable
improvement. Unfortunately for some of these changes we were limited to only
evaluating performance for the benchmarks.

w.r.t. IdleNotification, we need to ensure cache entries are maintained across
iterations of SunSpider in order for this to be useful. Maybe there's some other
way to tweak how caches are aged? IdleNotifications trigger a major GC after
every test in SunSpider. What do you think?